【AUTOSAR】Main部分
对象文档为AUTOSAR 4.0中的AUTOSAR_RS_Main.pdg
--------------------------------------------------------------------------------------------------------------------------------------------------
Main400
AUTOSAR应该提供一个分层的软件架构。用来划分软件组件，运行时环境和基础软件。运行时环境和基础软件应该提供一个虚拟层来隔离软件，使得软件具有可移植性。
Main130
MCAL层应该隔离硬件，使得其他基础软件可以从硬件特性上独立开，使得软件向其他平台移植时不会出现大规模修改。也就说驱动应该和大多数的基础软件分离，比如和OS分离。和Main400的区别是，400规定APP层不仅仅要和硬件独立，还要和数据独立。仅仅使用标准API开工作，专注于业务。
Main150
AUTOSAR需要提供方法让软件组件具有再部署的方法。让他们可以独立的发布到别的ECU中。
Main60
AUTOSAR需要提供组件之间标准的IF。从软件组件的角度来看，通用标准的接口必须具备可识别，独立的属性。无论他在什么地方运行。简单的说必须符合如下4个环境。
同一个ECU的相同CORE。
同一个ECU的不同CORE。
同一个ECU的不同CPU。
不同的ECU。
Main140
AUTOSAR应提供独立于下层通信设备的运行环境。各个软件组件都不应该依赖底层的通信模块。简单的说，APP不应该知道底层使用的是CAN还是FlexRay就能相互通信。
Main410
AUTOSAR应提供常用的公共库。
Main190
AUTOSAR应支持非AUTOSAR软件在同一个ECU上工作。也就说目前的软件在AUTOSAR中不会出现不能使用的情况。
Main210
AUTOSAR应支持非AUTOSAR软件在同一个NET上工作。也就说，新旧ECU可以在相同的车上运行。这意味着AUTOSAR的网络通信不能有太多自己独有的方式。
Main330
AUTOSAR应该支持信息隐藏。也就说AUTOSAR应该支持非源代码发布。
Main230
AUTOSAR应该支持含有gateway，桥等设备连接起来的网络拓扑结构。
Main100
AUTOSAR应该提供标准的基础软件。基础软件应包括在一个ECU上运行的基础功能，但具体细节不能公开给用户。为了支持再发布，软件组件仅仅只能使用基础软件所提供的服务，而不是直接使用底层的资源。
Main420
AUTOSAR应该统一汽车领域的基础软件的功能，制定一个统一的标准。各种不同的解决方案都应该被归纳并整理成一个标准。
Main430
AUTOSAR应该至少支持如下几种通信方式。
CAN，LIN，FlexRay，Ethernet
Main435
AUTOSAR的MCAL应该只是常用的MCU硬件。
Digital I/O
Pulse-width modulation
Analog/Digital converter
Bus controllers for CAN, LIN, FlexRay, Ethernet
Multicore
Memory protection units
Flash
Main440
AUTOSAR应该提供一个标准的访问内存的接口。并能对其进行管理，检查错误等。
Main450
AUTOSAR应提供一个标准的访问通用I/O的接口。类似温度传感器一类的入力设备和电机一类的出力设备。
Main460
AUTOSAR应该提供一个标准的mode管理器。因为大多数软件组件都严重依赖模式，所以一个通用的模式管理器对软件的跨ECU移植有很大帮助。
Main170
AUTOSAR应该提供一种安全操作ECU的方法。包括上下行的数据，软件等。
Main260
AUTOSAR应该提供一种针对ECU的标准的异常检查模块，类似ISO14229或者OBD一类的诊断能力。对异常的处理是必须对应的。
Main280
AUTOSAR应该针对娱乐信息系统提供一套通信IF。
Main10
AUTOSAR应该提供一套软件平台来开发安全相关的系统。这套系统应支持常用的安全开发机能。但我无法判断是IDE工具还是安全OS一类的直接插入ECU的软件。
Main11
AUTOSAR应该支持可靠系统的开发。起码应该提供针对“避免错误”，“检查错误”，“处理错误”三个问题的手段。
Main160
AUTOSAR应该提供针对整个系统的IF及其描述。用以满足ECU整体上能够实现再颁布，再利用的目的。在IF级别上的分解软件开发和核心。
Main180
AUTOSAR应该保护软件的机密性，同一个产品可能牵扯到多个开发商的情况也要良好的给予保护。
Main300
AUTOSAR应该提供一种通用的数据交换格式，用来解决常驻开发和非常驻开发间的数据交换问题。
Main80
AUTOSAR应该提供一种方法来描述应用软件的模式。包括代码，目标文件等的描述，以及关于代码功能上的分割等。
Main310
AUTOSAR应该支持分层设计方法。
Main320
任何针对整合性的需求，AUTOSAR都必须提供正式的描述。比如APP应该描述他对运行时环境的全部需求，这样才能为他的运行做好准备。而实际上来说，一个开发应用软件的OEM在发布自己的软件时确实需要详细并且标准的API描述。
Main340
AUTOSAR必须支持时序控制需求，这在实时系统中是必须的。这包含数据流和控制流两个方面的时序需求。
Main360
AUTOSAR应该支持汽车软件的多样化管理。针对自己的合作伙伴开发的可用的汽车版软件进行的管理使得软件的正式检查成为可能，并能够在整合阶段针对这些软件进行跟踪和评价。尤其是针对跨ECU的软件移植时，这种可评价的状态非常重要。
Main250
AUTOSAR要针对共同开发模式，提供一种角色模型。在开发设计过程中，共同开发需要可视的，并且是大家都能理解的角色和动作。角色可以是整车设计师，域设计师，ECU系统集成师，功能设计师，也可以是和各个规矩相关的东西联系在一起，比如静态架构，动态架构，通信架构等。而典型的动作则是软件本身，或者软件包，ECU的软件分布图，BSW的配置信息等。
Main251
AUTOSAR应提供在合作开发中角色和角色相应的权利的描述。
Main200
AUTOSAR应允许资源的有效利用。尤其是RAM，ROM，计算力等有限资源。
Main220
AUTOSAR的接口应规定为C90。
Main270
AUTOSAR应对新版本采取平缓的策略。也就是说下一个版本的AUTOSAR应该是支持上一个版本的标准的。
Main120
AUTOSAR应该提供一种方法来保证AUTOSAR的实现版本在软件层和BUS层上的协调性。AUTOSAR应提供一种测试case已经一种核心的测试方法来保证应用软件和数据BUS在ICC1层上的适用性。
Main30
针对安全相关的系统，AUTOSAR应支持开发流程。尤其是ISO26262技能安全规定。
Main490
AUTOSAR依存于ISO26262
Main290
AUTOSAR支持对他自己的修改
Main350
AUTOSAR文档应具备可分析，可证实的。
Main480
AUTOSAR的实现是可以测试的。