下载掌阅APP，畅读海量书库
立即打开
AUTOSAR是Automotive Open System Architecture（汽车开放系统架构）的缩写，是一个专注于制定汽车电子软件标准的联盟。AUTOSAR是由全球汽车制造商、零部件供应商及其他电子、半导体和软件系统公司联合建立，各成员企业之间保持开发合作伙伴关系。自2003年起，各伙伴公司携手合作，致力于为汽车工业开发一个开放的、标准化的软件架构。AUTOSAR有利于车辆电子系统软件之间的交换与更新，并为高效管理愈来愈复杂的车辆电子、软件系统提供平台。AUTOSAR在确保产品及服务质量的同时，提高了成本效率。
整车软件系统可通过AUTOSAR对车载网络、系统内存及总线的诊断功能进行深度管理，改善了系统的可靠性和稳定性。目前支持AUTOSAR标准的工具和软件供应商都已经推出相应的产品，提供需求管理、系统描述、软件构建算法模型验证、软件构建算法建模、软件构建代码生成、运行时环境（Run Time Environment, RTE）生成、ECU配置以及基础软件和操作系统等服务，帮助软件系统提供商实现无缝的系统软件架构开发流程。
传统的ECU架构有以下两个缺点：抽象程度低；基础软件模块少。针对上述问题，AUTOSAR规范提出了抽象程度更高的解决措施，划分出更多的基础模块。为了实现应用软件和硬件模块的解耦，汽车电子软件架构被抽象成4层，如图3-11所示，由上至下依次为应用层（Application Layer）、运行时环境（Run Time Environment, RTE）、基础软件层（Basic Software, BSW）以及微控制器（Micro controller）。应用层完全独立于硬件，只有基础软件层与硬件相关，而通过RTE实现这两者的隔离。这样以来，一方面厂商可专注于开发特定的、有竞争力的应用层软件（位于RTE之上），另一方面它使厂商所不关心的基础软件层（位于RTE之下）得到标准化。
图3-11 AUTOSAR层面图
作为汽车电子行业的新兴标准，国内外对AUTOSAR规范的研究成为热点，并一致选择将原有符合OSEK/VDX规范的操作系统平滑升级至符合AUTOSAR规范的版本。面对AUTOSAR规范正逐步取代OSEK/VDX规范的趋势，国内业界急需对AUTOSAR操作系统规范进行深入研究。AUTOSAR组织规定的目标以及它所囊括的功能领域如图3-12所示。
为了达到上述目标，针对在汽车电子行业中遇到的问题，AUTOSAR采用的解决方案及其优点可以概述如表3-1所示。
图3-12 AUTOSAR功能图
表3-1 AUTOSAR采用的解决方案及其优点
AUTOSAR架构改善了汽车电子系统软件的更新与交换，同时更快捷有效地管理日趋复杂的汽车电子软件系统。AUTOSAR让不同结构的电子控制单元的接口特征标准化，应用软件具备良好的可扩展性和可移植性，很大程度缩短了开发周期。AUTOSAR提倡“在标准上合作，在实现上竞争”的原则，其核心思想是“统一标准、分散实施、集中配置”。
AUTOSAR的分层式设计，用于支持完整的软件和硬件模块的独立性，中间RTE作为虚拟功能总线（Virtual Functional Bus, VFB）的实现，隔离了上层的应用软件层（Application Layer）与下层的基础软件层（Basic Software），摆脱了以往ECU软件开发与验证时对硬件系统的依赖，如图3-13所示。
图3-13 AUTOSAR体系架构分层标准
对于厂商及供应商而言，软硬件分离的分层设计提高了系统的整合能力，特别是标准化交互接口以及软件组件模型的定义提高了各层软件的复用能力，从而降低了开发成本，提高了系统集成与产品推出的速度。
应用层中的功能由各软件组件（Software Component, SWC）实现，组件中封装了部分或者全部汽车电子功能，如图3-14所示。其中包括对其具体功能的实现以及对应描述，如控制前照灯、空调等部件的运作，但与汽车硬件系统没有连接。
图3-14 应用层的组成
软件组件由最小逻辑单元（Atomic Component）组成。最小逻辑单元有Application和Sensor/Actuator两种类型。其中Application是算法实现类型，能在各ECU上自由映射；Sensor/Actuator是为Application提供I/O端口类型，用于与ECU绑定，但不像Application那样能在各ECU上自由映射。数个SWC逻辑集合组成Composition。图3-15是SWC组成实例图。
图3-15 SWC的组成
端口用来和其他SWC通信。通信内容分为Data Elements与Operations。其中，Data Elements用发送端/接收端（Sender/Receiver）通信方式，Operations用客户端/服务器端（Client/Server）通信方式，如图3-16所示。
图3-16 端口通信方式
发送端/接收端（Sender/Receiver）用来传输数据，具有一个通信端口可以包含多种数据类型的特点。但如果一个数据类型要通过总线传输，那么它必须与一个信号对应起来，数据类型既可以是简单的数据类型（integer、float），也可以是复杂类型（array、record）。通信方式是1:n或n:1，如图3-17所示。
图3-17 发送/接收端口特征图
客户端/服务器端口（Client/Serverr）用来提供Operation服务，具有一个客户端/服务器端口可以包含多种Operations和同步或是异步通信的特点，一个客户端/服务器端口可以包含多种Operations，Operations也可被单独调用。通信方式是1: n 或 n :1，如图3-18所示。
图3-18 客户端/服务器端口
可运行实体，简称Runnables，包含实际实现的函数，可以是具体的逻辑算法或是实际操作。可运行实体由RTE周期性或是事件（如接收到数据）触发调用，如图3-19所示。
图3-19 可运行实体
运行时环境（RTE）部分给应用层提供了通信手段，这里的通信是一种广义的通信，可以理解成接口。应用层与其他软件的信息交互有两种：第一种是应用层中不同模块之间的信息交互；第二种是应用层模块同基础软件之间的信息交互。而RTE就是这些交互使用的接口的“集散地”，它汇总了所有需要和软件体外部交互的接口。从某种意义上来看，设计符合AUTOSAR规范的系统其实就是设计RTE。
在设计开发阶段，软件组件通信层面引入了一个新的概念——虚拟功能总线，如图3-20所示。它是对AUTOSAR所有通信机制的抽象。利用VFB，开发工程师将软件组件的通信细节抽象，只需要通过AUTOSAR所定义的接口进行描述，即能够实现软件组件与其他组件以及硬件之间的通信，甚至是ECU内部或者是与其他ECU之间的数据传输。
图3-20 虚拟功能总线
从图3-20可以看到，有3种接口描述。可以先从定义的角度来对这3种接口进行比较。
1）Standardized Interface（标准接口）：标准接口是在AUTOSAR规范中被标准化的接口，但并未使用AUTOSAR接口技术。标准接口通常被用于某个ECU内部的软件模块之间的通信，不能用于网络通信。
2）Standardized AUTOSAR Interface（标准AUTOSAR接口）：标准AUTOSAR接口是在AUTOSAR规范中使用AUTOSAR接口技术标准化的接口，这种接口的语法和语义都被规定好了，通常在AUTOSAR服务中使用，是基础软件服务提供给应用程序的。
3）AUTOSAR Interface（AUTOSAR接口）：AUTOSAR接口定义了软件模块和BSW模块（仅仅是I/O抽象和复杂驱动）之间交互的方式。AUTOSAR接口以Port的形式出现，将ECU内部的通信和网络通信使用的接口进行了统一。
从以上定义可以看出，不同的接口使用的场景不同，不同的模块交互会使用不同的接口。除了将接口归类以外，这种定义的意义从实际使用的角度来看，第一类和第二类接口都是语法语义标准化的接口，即接口函数的数量函数的名字、函数参数名字及数量、函数的功能、函数的返回值都已经在标准里边定义好了。不同公司的软件在实现这些接口的时候虽然内容算法不同，但是它们的“长相”和功能是一致的，接口定义在AUTOSAR规范文档里是可以查到的。第三类接口，AUTOSAR仅仅规定了简单的命名规则，这类接口和应用高度相关，例如BCU控制前照灯打开的接口可以是Rte_Call_RPort_BeamLightSet-DigOut，也可以是Rte_Call_RPort_HeaderLight Output，车企可以自己定义。如仪表想要从CAN总线上获得车速信息，则该接口可以定义为Rte_IRead_RE_Test_RPort_Speed_uint8，也可以定义为Rte_IRead_Test_RE_RPort_S pd_uint8，但这些接口必须通过RTE交互，如图3-21所示。
4）Basic Software（基础软件）：现代汽车中有多种ECU，它们各自具有不同的功能，但实现这些功能所需要的基础服务是可以抽象出来的，例如I/O操作、AD操作、诊断、CAN通信、操作系统等；差别是，不同的ECU功能所操作的I/O、AD代表不同的含义，所接收和发送的CAN消息具有不同的内容，操作系统调度的任务周期优先级不同。这些可以被抽象出来的基础服务被称为基础软件。根据不同的功能，可以将基础软件细分成4部分：复杂驱动（Complex Drivers）、服务层（Service Layer）、ECU抽象层（ECU Abstract Layer）和MCAL层（Microcontroller Abstraction Layer）。这4个部分的互相依赖程度不尽相同，如图3-22所示。
图3-21 接口交互示意图
图3-22 BSW的结构组成
①复杂驱动（Complex Drivers），现代汽车中有一些领域的ECU会处理复杂的硬件信号执行复杂的硬件动作，例如发动机控制、ABS等。这些功能相关的软件很难抽象出来适用于所有类型ECU，其与ECU应用及ECU所使用的硬件紧密相关，属于在AUTOSAR构架中无法移植于不同ECU的部分。
②服务层（Service Layer），这一层基础软件提供了汽车ECU非应用相关的服务，包括操作系统（OS）、网络通信、内存管理（NVRAM）、诊断（UDS，故障管理等）、ECU状态管理模块等，它们对ECU的应用层功能提供辅助支持。该层软件在不同领域的ECU中也非常相似，例如不同的ECU中OS的任务周期和优先级不同，不同的ECU中的NVRAM的分区不同，存储的内容不同。
③ECU抽象层（ECU Abstract Layer），这一层软件提供了ECU应用相关的服务，它是对一个ECU的抽象，包括ECU的所有输入输出，例如数模转换（A/D）、PWM等。该层软件直接实现了ECU的应用层功能，可以读取传感器状态，可以控制执行器输出。不同领域的ECU会有很大的不同。
④MCAL层（Microcontroller Abstraction Layer），这一层软件是对ECU所使用的主控芯片的抽象，它与芯片的实现紧密相关，是ECU软件的最底层部分，直接和主控芯片及外设芯片进行交互。其作用是将芯片提供的功能抽象成接口，再将这些接口提供给服务层或ECU抽象层使用。
AUTOSAR OS为实时应用提供了所有基本服务，即中断处理、调度、系统时间和时钟同步、本地消息处理以及错误检测机制。所有服务都隐藏在良好定义的API之后。应用与OS和通信层的连接只通过API。其基本特征包括静态配置、能推断实时系统性能和提供基于优先级的调度策略等。
在嵌入式汽车ECU中的实时操作系统构成软件动态行为的基础。它管理任务、事件的调度和不同任务间的数据流，并且提供监控和错误处理功能。但是，在汽车系统中，对操作系统的需求集中在特定领域，所使用的操作系统必须高效运行并且所占存储空间小。在多媒体和远程信息处理应用中，操作系统提供的特征集以及可用计算资源有很大不同。在纯粹的任务管理之上，操作系统中还包含了复杂的数据处理（例如流、快速文件系统等）和存储管理甚至图形用户接口。
汽车操作系统的典型领域涵盖了调度和同步的核心特征。在AUTOSAR中，上面讨论的附加特征在OS的范围之外，其他WP4.2.2.1工作包（例如SPAL）涵盖了这些特征。在AUTOSAR的体系结构约束之下不可能把其他OS（例如，QNX、VxWorks和Windows CE等）的特征集合集成到整体的OS/通信/驱动结构中。因此，AUTOSAR OS只考虑核心特征。
BSW调度器是系统服务的一部分，它向所有层的所有模块提供服务。但是，与其他BSW模块不同，BSW调度器提供了集成的概念和服务。BSW调度器可提供方法把BSW模块的实现嵌入AUTOSAR OS中，并应用BSW模块的数据一致性机制。集成者的任务是应用所给的方法（AUTOSAR OS提供的），在特定项目环境中以良好定义和有效的方式把BSW模块装配起来。这也意味着BSW调度器只是使用AUTOSAR OS，它与AUTOSAR OS调度器并不冲突。
模式管理包括3个基本软件模块：①ECU状态管理器，控制AUTOSAR BSW模块的启动阶段，包括OS的启动；②通信管理器，负责网络资源管理；③看门狗管理器，基于应用软件的生存状态触发看门狗。