Autosar规范

软件架构层 文件编号053

免责声明

Autosar发布的规范（specification）及其材料仅供参考（purpose of information only）。Autosar及其做出贡献的公司不对规范的使用负责。本规范的材料受知识产权保护，任何商业开发（commercial exploitation）需要获得知识产权（Intellectual Property Rights）的许可证（license）。

本规范可以在不做修改的情况下，以参考为目的进行复制和使用。至于其他目的则需要得到出版商（publisher）的书面认可。

Autosar规范仅针对汽车应用，不适合非汽车电子应用。AUTOSAR一词和图标（logo）已经注册商标（trademark）

autosar规范包含示例性项目（参考模型（reference models），用例（use cases），对技术方案，设备，过程或者软件的引用）。这些示例性项目仅做证明，它们并不是autosar规范标准的一部分。它们以及相关文件出现在规范里，并不意味着使用相同的许可证（license）。

本文档目的

自上而下地描述了autosar软件架构，将软件模块映射到软件层并且说明了相互之间的关系。本文档侧重于静态地描述软件架构的层次概念。

autosar规范主要用于汽车电子控制单元（ECU），ECU具有这样的特点：

1.硬件之间的强交互（strong interaction）（传感器（sensors）和执行器（actuators））

2.连接到车载网络（CAN, LIN，FlexRay和Ethernet（以太网））

3.微处理器（通常是16位或者32位），计算能力和内存资源有限

4.实时系统（real time system）

5.从内部到外部闪存（flash memory）的程序执行（program execution）

在autosar规范中，一个ECU意味着一个微控制器加上外设（peripherals）以及相应的软件配置。在autosar规范中不考虑机械设计。这就意味着如果一个部件里面有多个微处理器，每个微处理器自身都需要一个完整的架构设计。

autosar 扩展性

1.标准模块可以在功能上进行扩展，同时保持兼容，同时扩展的配置需要在底层软件配置的时候考虑

2.非标准模块可以集成到复杂驱动（complex drivers）

3.不可以添加更多的层了

抽象到最后autosar架构分为三层，高级功能层，运行时环境，还有运行在微控制器上的底层软件。

底层软件进一步可以分为，服务层，ECU抽象层，微处理器抽象层，以及复杂驱动

底层还可以继续分为不同的功能组，服务层还可以包括系统服务，内存调度服务，通信服务。

微处理器抽象层是最最最底层，它包含了内部驱动（internal drivers），本质上还是软件模块（software modules），但是可以直接访问微处理器并且调用内部资源。它的作用就是使得上层的软件独立于微处理器。

ECU抽象层和微处理器抽象层的驱动程序相交互，它包含了外设的驱动。它提供了访问外设和设备的API接口，而且不需要知道外设和设备的位置以及连接的方式（端口引脚（port pins），接口类型（type of interface））。这样，可以使得更高层的软件运行独立于ECU硬件层了。

复杂驱动层的范围从硬件直接到运行时环境。提供集成特殊目的功能的可能性，比如autosar规范没有限定的，非常高的定时限制的，或者用于迁移目的（migration purpose）

服务层是底层的最高层，虽然ECU抽象层覆盖了对输入输出信号的访问，但服务层可以提供：

1. 操作系统功能
   

2. 车辆网络通信和管理服务

3. 内存服务（NVRAM 管理）

4. 诊断服务 （包括 UDS 通信，error memory和 故障处理）

5. ECU状态管理，模式管理

6. 逻辑和时间（temporal）程序流监控（Edg管理器）

7. 加密服务（Crytographic Services）

RTE层向应用软件（autosar软件组件，传感器，执行器）提供通信服务。在RTE层上方软件架构从分层变成分组（layered to component style）。autosar软件组件之间的通信或者与服务的通信，通过RTE进行。

底层软件又可以分为下面四种服务：

输入和输出，对于传感器，执行器以及ECU片上外设的标准化访问

内存，内部和外部资源（非易失性内存）标准化访问

通信，车载网络，ECU片上通信系统和ECU内部程序的通信标准化访问

系统，操作系统，定时器，错误寄存器，ECU状态管理，看门狗管理以及库功能。

驱动包含控制和访问内部和外部设备的功能

内部设备位于微处理器上，比如：内部EEPROM，内部CAN控制器，内部ADC。内部设备的驱动也叫内驱，位于微处理器抽象层。

外部设备位于ECU硬件上，不在微处理器上，比如：外部EEPROM，外部看门狗，外部闪存。

外部设备的驱动也叫外驱，位于ECU抽象层，但是它通过微处理器中的驱动来访问外部设备。这样的话，AUTOSAR也支持集成在System Basis Chips上面的元件。比如，具有SPI接口（interface）的外部EEPROM的驱动程序通过SPI总线的处理程序（handler）或者驱动（driver）来访问外部EEPROM。例外就是，如果是映射到外部设备的内存的驱动，可以直接访问微处理器，因为他们位于未处理抽象层，并且依赖于微处理器。

接口（interface）包含从底层模块提取（abstract）的功能，比如从具体设备的硬件实现（hardware realization）抽象出来的接口模块。它提供了一种通用的API来访问具体的设备，和设备的数量以及硬件实现方式无关。

接口不会改变数据的内容。总体来说，接口位于ECU抽象层。比如，CAN通信的接口提供了一个通用API，用于访问CAN通信网络，独立于CAN控制器的数量，以及硬件实现方式。

处理程序（Handler）是一种特殊的接口，它控制者多个客户端对多个驱动的并发（concurrent），多线程（multiple）和异步（asynchronous）访问。执行缓冲（buffering），队列（queuing），仲裁（arbitration），多路复用（multiplexing）。它不改变数据的内容。处理程序通常包含在驱动或者接口中（SPIHandlerDriver，ADC Driver）。

管理器（manager）为多个客户提供特定服务，他在纯处理程序（handler）不能从多个客户端进行抽象的时候特别重要。在处理程序之外，管理器可以评估和改变数据的内容。通常来说，管理器位于服务层（services layer）。比如NVRAM管理器可以处理内部或者外部内存（闪存，EEPROM）的并发访问。他也可以处理分布式的可靠的数据存储，数据检查和提供默认值等。

库（libraries）是相关目的函数的集合，可以叫做BSW模块（包括RTE），SW-CS，或者集成代码（integration code），没有内部状态，不需要初始化，是同步的（没有等待的点）。Autosar包含了浮点计算，定点计算，浮点计算的插值（interpolation），定点计算的插值，位处理，E2E通信，CRC计算，扩展功能如滤波，加密（crypto）

具体内容

SPIHandlerDriver 允许多个客户端对一个或者多个SPI总线的并发访问。在这里，片选信号不再由DIO驱动控制，而是由SPIHandlerDriver处理。

复杂驱动里面包含了喷射控制装置，电动阀控制，以及增量位置检测。满足复杂传感器和执行器的功能和时序要求。

输入输出硬件抽象不是从传感器和执行器来的。

通信硬件抽象从通信控制器的位置以及ECU布局上面上面抽象而来的。

下面是几种通信服务

常规通信堆栈属性（stack），信号网关（gateway）是Autosar COM的一部分，用来路由（route）信号。基于PUD的网关是PDU路由的一部分。

内存服务包含了NVRAM管理器，用来管理不冲突的数据，从不同的内存驱动里面读和写。

下面具体看看接口