【原】autosar规范（二）

CAN通信服务（CAN Communication Services）是车载CAN通信网络系统的一组模块。为CAN网络提供了统一的接口（interface），对于应用隐藏了协议（protocol）和信息特征。CAN通信堆栈（stack）支持经典CAN2.0和CANFD。

存储服务由NVRAM模块组成，负责管理非冲突数据（不同存储驱动的读写操作）。为应用统一提供非冲突数据，隔离了寄存器位置和特征。包含的机制如保存，加载，检查以及验证，可靠的存储等。

系统服务是一些能够被所有层的模块使用的模块和功能。比如实时操作系统和错误管理器。

有专门的模块来处理错误，比如Debugging模块，Diagnostic Event Manager，Diagnostic Log and Trace。所有被发现的开发错误都会被送到 Default Error Tracer。

双核模式

Master EcuM starts all Satellite EcuMs。

Autosar的三种接口

Autosar接口定义了软件组件和底层软件信息交互的方式。这种方式不依赖与特定的编程方式，ECU或者网络技术。Autosar定义了软件组件和底层软件模块的端口（port），通过端口可以发送和接受信息，或者调用服务（invoke services）。AUTOSAR实现了软件组件和底层软件的通信，本地或者网络上。

标准AUTOSAR接口，是一种AUTOSAR接口，它的语法和语义都是标准化的。通常用来定义Autosar服务，这些服务通常是底层软件提供给应用层软件组件。 

标准化接口，是一种应用编程接口（API），在AUTOSAR中标准化，但是没有使用AUTOSAR接口技术。这种接口通常为C语言量身定制，因此通常用于同一块ECU上面的软件模块通信。当使用标准化接口之后就不可以在网络中通信了。

下图展示了服务和驱动之间的交互方式。ECU硬件包含了外部EEPROM和外部Watchdog，通过SPI与微处理器连接。

SPIHandlerDriver控制着并发访问，并且给予watchdog访问更高的权限。微处理器拥有一个并行与EEPROM内部闪存器，EEPROM Abstraction和Flash EEPROM Emulation拥有语义上等价的应用编程接口。

存储抽象层接口有三种实现方式，运行时（runtime）分别可以通过设备索引，区块索引，ROM表，进行路由（routing）。

Std_ReturnType MemIf_Write

(

uint8 DeviceIndex,

uint16 BlockNumber,

uint8 *DataBufferPtr

)

MemIf_Write(DeviceIndex,BlockNumber,DataBufferPtr)

PDU 路由器 在不同的抽象层和上层之间提供PDU信号的路由功能

COM，提供不同I-PDU之间单个信号或者多组信号之间的路由。

NM Coordinator 连接到ECU不同网络通道的网络状态的同步。

Communication state manager 通信系统的硬件单元的打开和关闭，控制PDU组。

RTE 中的数据流过程

转换器都位于系统服务层。第一步，RTE调用SOME/IP转换器。第二步SOME/IP执行转换并将结果写入RTE提供的缓存器1。第三步，RTE执行安全转换，安全转换的输入就是SOME/IP转换器的输出。第四步，安全转换保护数据并且将输出写入RTE中另一个缓存器。第五步，RTE最终将数据流写入COM模块。

说一下编译的流程，首先是预处理，在这个过程中会做一些宏定义展开，条件编译，头文件展开，删除代码中的注释，接着就是编译器的工作，词法分析，语法分析，语义分析与中间代码产生，代码优化，最后是连接器的工作，目标代码以及需要的库生成程序。

Autosar 底层软件支持三种配置方式

Pre-compile time 预处理器指令，代码生成器（选择与综合，可能是优化）

Link time 模块外的常数，模块被编译后依旧可以配置

Post-build time 模块外的本地常数，类似于link time，但是数据位于特殊的寄存器，可以重载。（ECU产线上重新刷写）