| 编辑推荐: |
本文将重点讨论AUTOSAR架构概览,AUTOSAR的基础软件,
以及多核处理 ，AUTOSAR的Safety功能，AUTOSAR的ICC，希望对您的学习有所帮助。
本文来自于嵌入式软件实战派，由火龙果软件Alice编辑、推荐。 |
|
1 AUTOSAR架构概览
之前文章《老板说项目要上AUTOSAR，我慌得一批》讲过，在新世纪，汽车产业蓬勃发展，欧洲大陆的车企们，瞄准了这是一块大蛋糕，于是在2002年成立了一个联盟，搞了个叫AUTOSAR的标准，以期一统天下。次年，他们就开搞了，开始制作这个AUTOSAR的草图。
话说，这是要定义一套标准，一个统一的架构，那这架构有什么内容呢？
一位工程师，将其想法用草图表达了出来
并解释说，这个架构大概分三层，然后看看在座的各位。会议上的其他人面面相觑，都想说，这么简陋，能统一江湖？这位工程师也不理会，不慌不忙，继续画下去：
工程师解释说，关键在这个BSW，还可以分个三四层：
Service Layer：这个是BSW的最高层，是给Application访问由Abstraction
Layer覆盖的IO信号等。
ECU Abstraction Layer：这个是给底层驱动提供抽象接口的。
Microcontroler Abstraction Layer：这个是基础软件的最底层，它包含有μC的驱动以及外围的设备驱动等。
还有，Application就是应用，跟其他架构写的应用类似，就不用多说了。而这个Runtime
Environment(RTE)呢？
RTE是给应用提供通信服务的，Applcation通过它可以访问BSW的功能，做统一标准的接口，从而实现非常方便的可移植性了，各模块也独立了。
工程师言简意赅，没有做更多的解释，然后就想细化这个架构图：
然后，他微微笑了下：这应该清晰了吧，横着看竖着看都很好理解。比如说这个Memory Service，就可以让Application通过RTE调用，做了很多方法application访问的接口，它是通过调用Memory
Hardware Abstraction来访问Memory Drivers的。
通过这三层关系就实现市面上大部分功能需求了。但是，总会有这几层实现不了的功能吧，怎么办？Complex
Drivers就可以提供给用户自己定义啦，可以做一些复杂的驱动。
总的来说，基础软件（BSW）可以按以下类型分：
Input/Output (I/O)
标准化访问sensors, actuators以及板上的外围器件。
Memory
标准化访问内部或外部的Memory（NVM）。
Crypto
标准化访问密码原语，包括内部/外部硬件加速器
Communication
标准化访问车辆网络系统，ECU车载通信系统和ECU内部软件
Off-board Communication
标准化访问车辆到X的通信，车辆无线网络系统中，ECU车外通信系统
System
提供标准化的（操作系统，计时器，错误存储器）和特定于ECU的（ECU状态管理，看门狗管理器）服务和库功能
等等，还有个东西差点漏了——Library
这个Library实际上是很多functions的集合，它可以：
由BSW模块（包括RTE），SW-C，库或集成代码调用
在同一保护环境中在调用方上下文中运行
只能调用库
可重入的
没有内部状态
不需要任何初始化
是同步的，即它们没有等待点
2 AUTOSAR的基础软件
基础软件，即BSW。工程师打算详细讲解下这个BSW，因为它非常重要。
话说，座上的与会大咖听这位工程师讲的津津有味，越来越觉得AUTOSAR一统江湖指日可待，并期望能讨论更多细节。
工程师也准备好了设计原稿，对这些细节娓娓道来。
MCAL
从底下往上讲，第一个Microcontroler Abstraction Layer（即MCAL），其有以下模块：
Microcontroller Drivers
具有直接μC访问权限的内部外围设备（例如看门狗，通用定时器）驱动程序（例如核心测试）
Communication Drivers
车载ECU（例如SPI）和车辆通信（例如CAN）的驱动程序。OSI层：数据链路层的一部分。
Memory Drivers
片上存储设备（例如内部闪存，内部EEPROM）和存储器映射的外部存储设备（例如外部闪存）的驱动程序。
I/O Drivers
用于模拟和数字I / O的驱动器（例如ADC，PWM，DIO）。
Crypto Drivers
用于SHE或HSM等片上加密设备的驱动程序。
Wireless Communication Drivers
用于无线网络系统的驱动程序（车载或车外通信）。
举例说明，SPIHandlerDriver是允许多业务并发访问，为了抽象出SPI的所有功能，这些已经用为SPI功能的IO是不能做他用的。
CDD
CDD即Complex Driver，上文也提到了，它是用来实现BSW里面非标准化功能的。也就是说，标准化定义以外的功能可以通过CDD来实现，如UART，MCAL是没有定义UART的标准化的。
（这个话题，后续再详细讲解。）
I/O Hardware Abstraction
I/O Hardware Abstraction是一组模块，从外围I/O设备（片上或板上）的位置和ECU硬件布局（例如μC引脚连接和信号电平反转）中抽象出来。I/O硬件抽象不会从传感器/执行器中抽象出来！可以通过I
/O信号接口访问不同的I/O设备。
Communication Hardware Abstraction
Communication Hardware Abstraction是一组模块，从通信控制器的位置和ECU硬件布局中抽象出来。对于所有通信系统，都需要特定的通信硬件抽象（例如，对于LIN，CAN，FlexRay）。
例如，ECU具有带2个内部CAN通道的微控制器和带4个CAN控制器的附加板载ASIC。CAN-ASIC通过SPI连接到微控制器。
可通过总线特定的接口（例如CAN接口）访问通信驱动程序。
Memory Hardware Abstraction
Memory Hardware Abstraction 是一组模块，从外围存储设备（片上或板载）的位置和ECU硬件布局中抽象出来。
例如，可以通过相同的机制访问片上EEPROM和外部EEPROM器件。可以通过特定于存储器的抽象/仿真模块（例如EEPROM抽象）访问存储器驱动程序。通过在闪存硬件单元顶部模拟EEPROM抽象，可以通过存储器抽象接口对两种类型的硬件进行通用访问。
Onboard Device Abstraction
Onboard Device Abstraction 包含用于ECU板载设备的驱动程序，不能将其视为传感器或执行器，例如内部或外部看门狗。这些驱动程序通过μC抽象层访问ECU车载设备。
Crypto Hardware Abstraction
Crypto Hardware Abstraction是从加密基元（内部或外部硬件或基于软件）的位置抽象的一组模块。例如，AES原语在SHE中实现或作为软件库提供。
Crypto Services
Crypto Services包含两个模块：
加密服务管理器负责加密作业的管理
密钥管理器与密钥预配置主机（在NVM或加密驱动程序中）进行交互，并管理证书链的存储和验证
Communication Services
Communication Services是一组用于车辆网络通信（CAN，LIN，FlexRay和以太网）的模块。它们通过通信硬件抽象与通信驱动程序接口。
讲到这里，会上的其他人听着听着有些懵逼，越讲越复杂了，工程师停了下，说，通信服务这部分，涉及到CAN、LIN甚至TCP/IP等，内容很多也很重要，后续我们另外召开会议讨论吧。
Memory Services
Memory Services由一个模块NVRAM管理器组成。它负责非易失性数据的管理（从不同的内存驱动器读取/写入）。
它以统一的方式向应用程序提供非易失性数据。内存位置和属性的摘要。提供非易失性数据管理机制，例如保存，加载，校验和保护和验证，可靠的存储等。
System Services
System Services是一组模块和功能，可由所有层的模块使用。示例包括实时操作系统（包括计时器服务）和错误管理器。
其中一些服务是：
取决于μC（例如OS），并且可能支持特殊的μC功能（例如Time Service），
部分依赖ECU硬件和应用程序（例如ECUM Management）或
硬件和μC独立。
它提供基本的申请服务以及基本软件模块。
有专门的模块可用于AUTOSAR中错误处理的不同方面， 例如：
诊断事件管理器负责处理和存储诊断事件（错误）和相关的FreezeFrame数据。
诊断日志和跟踪模块支持对应用程序进行日志记录和跟踪。它收集用户定义的日志消息并将其转换为标准化格式
基本软件中检测到的所有开发错误都报告给默认错误跟踪程序。
Diagnostic Communication Manager提供了用于诊断服务的通用API
其他的，等等
3 AUTOSAR的多核处理
此刻，有人提问，市面上μC更新换代非常快，性能也不断提升，甚至有多核处理器，这个架构如何应对多核处理？
工程师想了想，show出了下图
并结合下图给出解释：
BSW模块可以分布在多个分区和核心中。所有分区共享相同的代码。
每个分区上的模块可以完全相同，如图中I/O堆栈中的DIO驱动程序所示。
作为替代，他们可以使用依赖于核心的分支来实现不同的行为。Com服务和PWM驱动程序使用卫星主机通信来处理从相应卫星到主机的呼叫。
主站与卫星之间的通信不规范。例如，它可以基于BSW调度程序提供的功能，也可以基于共享内存。
箭头指示服务调用的处理涉及哪些组件，这取决于分发方法和调用的来源。
每个运行BSW模块的分区中的基本软件模式管理器（BswM）
所有这些分区都是受信任的
每个内核一个EcuM（每个在一个受信任的分区中）
通过引导加载程序启动的那个核心上的EcuM是主EcuM
主EcuM启动所有卫星EcuM
如图所示，IOC提供了通讯服务，这些客户端可以访问需要跨同一ECU上OS-Application边界进行通讯的客户端。IOC是操作系统的一部分。
BSW模块可以在多个内核上执行，例如图中的ComM。在运行时确定负责执行服务的核心。
每个核心都运行一种ECU状态管理
4 AUTOSAR的Safety功能
那么，安全功能如何？工程师都有考虑和准备：
AUTOSAR提供了一种灵活的方法来支持与安全相关的ECU，可以使用两种方法：
所有BSW模块均根据所需的ASIL开发
所选模块是根据ASIL开发的，ASIL和非ASIL模块分为不同的分区（BSW分发）
注意：分区基于OSApplications，OS-Application的TRUSTED属性与ASIL/non-ASIL不相关。
使用不同BSW分区的示例，看门狗堆栈放置在自己的分区中
ASIL和非ASIL SW-C可以通过RTE访问WdgM
BSW的其余部分放在自己的分区中
经过以上的解答和分解，会议上的各位都点头表示同意，但是还是有人提了个问题，我们定义这么多功能模块，不一定所有产品都会用到，如何裁剪？
5 AUTOSAR的ICC
好了，我们接下来讨论ICC（Implementation Conformance Class）：
下图显示了基本软件模块到AUTOSAR层的映射
我们称这个为ICC3，那ICC2是怎样的？
这个便是ICC2了。
到目前为止，本文档中显示的集群是该项目定义的集群。
当前，AUTOSAR并未将ICC2级别上的群集限制为专用群集，因为许多不同的约束和优化标准可能会导致不同的ICC2群集。
可能存在不同的AUTOSAR ICC2集群，可以根据要定义的ICC2遵从性方法声明符合性。
ICC1呢？
在符合ICC1的基本软件中，不需要模块或集群。未指定此专有基本软件的内部结构。
纳尼？又回到原来的三层结构？
兼容AUTOSAR（ICC1-3）的基本软件（包括RTE）必须具有ICC3模块规范指定的外部性能。例如，针对以下行为：
1.总线
2.引导加载程序和
3.应用
另外，关于ICC3中的系统描述，ICC1 / 2配置应兼容。
也是说，这个架构能屈能伸，只需遵循相关标准要求即可，非常灵活。
5 后话
会上响起了经久不绝的掌声，结构做到这份上，也是非常详尽了。但是，问题还是有的，架构中定义了那么多模块，模块之间的接口是如何的？
|
