不脱发的程序猿

本专栏主要介绍汽车嵌入式系统软件规范AUTOSAR以及符合AUTOSAR规范的车用控制器软件开发方法。

AUTOSAR是由全球各大汽车整车厂、汽车零部件供应商、汽车电子软件系统公司联合建立的一套标准协议，是对汽车技术开发一百多年来的经验总结。

在AUTOSAR软件架构中，汽车嵌入式系统软件自上而下分别为：应用软件层（Application Software Layer，ASW）、运行时环境（Runtime Environment，RTE）、基础软件层（Basic Software Layer，BSW）和微控制器（Microcontroller）。

AUTOSAR软件组件大体上可分为原子软件组件（Atomic SWC）和部件（Composition SWC）。其中，部件可以包含若干原子软件组件或部件。

AUTOSAR方法论是指AUTOSAR为汽车电子软件系统开发过程定义的一套通用技术方法。

AUTOSAR规范中，将不同模块间通信的接口主要分为以下三类：AUTOSAR接口、标准AUTOSAR接口和标准接口。

AUTOSAR为了实现一种“自顶向下”的整车级别的软件组件定义，提出了虚拟功能总线（Virtual Function Bus，VFB）的概念。

在 RH850 上集成 CAN 通道时，真正消耗项目时间的往往不是 `Can_Write()` 这一层调用，而是 RSCAN 硬件资源怎么分配、BusOff 后什么时候允许回到 START、Rx FullCAN 为什么不能走中断、CAN-FD 报文长度如何影响共享 RAM、以及中断控制权到底归驱动、OS 还是应用。

在 AUTOSAR Classic 平台里，通信通道是否允许发送、ECU 什么时候进入 RUN 或 POSTRUN、NvM 的 `ReadAll` 和 `WriteAll` 如何嵌入启动关机序列、诊断模式是否影响 I-PDU Group，这些决定通常不会由单个业务 SWC 直接下发到底层模块。它们先汇聚到 BSW 模式管理器（BswM），再由规则、条件和 action list 转成对 Com、ComM、EcuM、PduR、Sd、Nm 等模块的调用。

AUTOSAR CAN Driver 的职责并不是重新定义 CAN 协议，而是把不同控制器上的 CAN 通信统一成 CanIf 可以调用的 MCAL 接口。

CAN Interface（CanIf）是 AUTOSAR Classic CAN 通信栈里最容易被低估的一层。

CanNm 是 AUTOSAR Classic 平台里面向 CAN 总线的网络管理模块。它解决的不是“某个应用报文如何发送”，而是“整条 CAN 网络什么时候应保持唤醒，什么时候可以进入睡眠，以及各 ECU 如何在没有中心主节点的情况下达成一致”。

CAN 通道从睡眠到可通信，不只是把控制器置为 STARTED。控制器、收发器、CanIf PDU Mode、ComM 模式、BswM 状态、DEM 事件都要按顺序变化；其中任何一个异步模式指示缺失，都可能让通信栈停在过渡状态。CanSM 的职责就是把 ComM 的网络通信模式请求翻译成 CAN 硬件和 CanIf 的动作，并把最终状态回报给 ComM 和 BswM。

CanTp 位于 AUTOSAR 通信栈中 PduR 与 CAN 底层之间，用来把超过单个 CAN/CAN-FD 帧承载能力的 N-SDU 拆成 N-PDU 发送，并在接收侧重新组装。它本身不决定诊断服务语义，也不做跨总线路由；它负责的是 ISO 15765-2 网络层传输：单帧、多帧、流控、超时监督、取消和异常终止。

车载 CAN 网络中的多个 ECU 若要使用同一时间基准，难点不只是“发送一个时间值”。时间主节点需要按周期或时间基更新事件发出同步报文，时间从节点必须把前后关联的报文配对，还要处理发送确认、接收超时、CRC、网络访问开关以及跨分区调度。任何一个环节的时序或配置不一致，都可能让同步链路停在等待状态。

ECU 完成 XCP 初始化后，测量标定工具仍可能收不到任何响应。一个常见原因不是 CAN 通道或 A2L 文件错误，而是 CanXcp 初始化后处于 CANXCP_SET_OFFLINE：协议层可以产生响应，传输层却不会把帧发到总线。如果项目没有 CanSM，或者使用的状态管理器不会切换 CanXcp 的 PDU 模式，就必须由应用显式调用 CanXcp_SetPduMode() 进入在线状态。

在 AUTOSAR Classic 的通信链路里，应用不应该关心 CAN、LIN 或 FlexRay 帧的字节布局。它更新的是一个有类型、有传输属性的 Signal，读取的也是 Signal 或 SignalGroup；COM 负责把这些对象打包到 I-PDU，再交给 PDU Router 和下层接口。反方向的数据由下层通过 `Com_RxIndication()` 交给 COM，COM 按配置完成解包、字节序转换、过滤、失效判定和通知。

当 ECU 同时连接 CAN、FlexRay、LIN 和 Ethernet 时，应用不应分别管理每条总线的唤醒、网络管理和休眠时序。AUTOSAR Communication Manager（ComM）把这些动作收敛为用户对通信模式的请求，再由每个 Channel 的状态机协调 BusSM、Nm、EcuM、Dcm、BswM 和 RTE。ComM 不是总线驱动，也不直接搬运业务 PDU；它管理的是“何时允许通信、哪些资源必须保持唤醒、何时可以安全关机”。

在 ECU 软件中，CRC 结果不一致往往不是“算法算错了”，而是通信双方对多项参数的理解不一致：多项式相同但初始值不同、输入或结果反射不同、最终异或值不同，都会生成另一套结果。AUTOSAR Crc 模块把这些算法固化为一组同步服务，调用者只提交数据缓冲区、字节长度和连续计算上下文，不在每次调用时动态传入多项式等模型参数。

一套 ECU 同时集成软件密码驱动、硬件安全模块和第三方 Crypto Driver 时，CSM 不应了解每个驱动的对象编号、密钥编号和接口命名差异。Crypto Interface（CryIf）位于密码服务管理器（CSM）与 Crypto Driver 之间，把上层统一的密码作业和密钥管理请求路由到已配置的底层对象，再把执行结果和完成通知送回 CSM。

Csm 的重点不是实现 AES、SHA 或随机数算法，而是管理服务抽象、作业实例、队列、优先级、取消和回调。算法工作区及实际计算能力属于 `CryptoDriverObject`。这种分层让同一个 `Csm_Hash()` 或 `Csm_Encrypt()` 调用可以通过配置落到不同驱动对象，同时把上层调用与具体硬件解耦。

Dcm 管理诊断会话、安全等级、认证状态、通信控制和 DTC Setting 等状态，并据此决定某个服务、子服务、DID、RID 或内存范围是否允许执行。它负责 UDS/OBD 请求解析、服务调度、正负响应构造、P2/P2* 定时以及 `0x78` ResponsePending 处理；DTC 数据本身仍由 Dem 管理，密码学运算和证书验证分别依赖 Csm 与 KeyM，报文分段和总线传输则由 PduR 及其下层 TP 完成。

监控程序刚刚上报 FAILED，诊断仪却读不到 DTC；DTC 已经出现，Snapshot 里的信号又不像故障瞬间；调用了 ClearDTC，接口仍连续返回 DEM_PENDING；软件升级后，旧故障数据甚至让新配置表现得不稳定。这些现象往往不是一个“故障码列表”能够解释的，因为诊断事件管理器（Diagnostic Event Manager，Dem）维护的是从监控结果到外部诊断响应的一整条证据链。

MemIf 的职责是提供统一函数入口，并通过 DeviceIndex 把请求分派给 Fee 或 Ea 实例。真正处理读、写、擦除和失效作业的是目标内存硬件抽象模块；真正推进异步状态机的是该模块的周期主函数；真正访问 Flash 或 EEPROM 硬件的则是 Fls 或 Eep。MemIf 不会把这条异步链路压缩成一次同步函数调用。

开发联调时，某个 BSW API 传入了非法参数，随后任务不再运行；调试器停在一个 while(1) 中，看起来像 ECU 无故死机。另一些运行期错误使用相同的四个标识上报，函数却正常返回。还有一种瞬态故障，最终返回 E_NOT_OK，但这个返回值并不是 Det 自己判断故障严重程度得到的。

一个 SWC 端口提供结构化诊断数据，另一个端口接收字节序列；RTE 连接和类型映射都已生成，运行时却出现数值错位、符号位错误或接收值超出数据约束。问题通常不在通信链路，而在两端数据原型（Data Prototype）没有共享同一种内存与线性化表示。

Det_ReportError() 能记录开发错误，Dem 能维护事件状态，SWC 也能产生业务日志，但这些信息如果只停留在 ECU 内存中，调试人员仍看不到可读结论。Dlt（Diagnostic Log and Trace）的职责是把分散的 DET、DEM 和 SWC 消息收拢到基础软件中的统一出口，再由 PC 端工具按消息语义显示为文本。

汽车软件开发V模型过程中Vector相应的工具介绍。

DaVinci Configurator新建和配置工程。

Green Hills Software（GHS）是美国Green Hills软件公司提供的一种具有调试、编译器和闪存编程工具的集成开发环境，是汽车电子行业常用且重要的开发环境之一。

基于RH850芯片，Green Hills Software（GHS）集成DaVinci Configurator生成代码。

使用GHS编译下载瑞萨RH850程序方式比较简单，配置好E1/E20烧录器参数就可以。

通过学习本篇博文项目，将会把所学的DaVinci Configurator知识系统串联起来。

本篇博文就带大家来认识一下AP AUTOSAR 和CP AUTOSAR 的概念和区别。

DaVinci Configurator导入ARXML配置。

ARXML文件包含了你的工程配置参数，该文件可以传给别人，在别人电脑上，直接打开你的配置模块。

本篇博文将介绍AUTOSAR代码包结构。

本篇博文将介绍AUTOSAR代码工程是如何从上电复位到启动运行。

学习AUTOSAR需要查阅很多手册和文档，本篇博文将介绍如何下载AUTOSAR官方标准文档。

查看AUTOSAR代码包时会发现一些这样格式的文件：xxx_PBcfg.c、xxx_Lcfg.c和xxx_Cfg.h，本篇博文讲一讲这几个配置文件的作用和特点。