1. 课程导入
各位工程师朋友，欢迎来到这门课。我是老周，在汽车电子这行摸爬滚打了十几年。今天咱们聊聊AUTOSAR诊断，这是整个课程的开篇，也是后续所有开发工作的地基。
说实话，我刚接触AUTOSAR那会儿，也被那一堆缩写搞得头晕——DCM、DEM、FIM，到底谁管谁？后来做项目踩了坑才慢慢理清楚。今天我就把这些经验掰开揉碎了讲给你听。
1.1 AUTOSAR架构简介
AUTOSAR是什么？说白了，它就是汽车电子软件的一套标准化架构。目的是让不同供应商的代码能拼在一起跑，不用每次从头造轮子。
整个架构分三层，我习惯用一张图来记：
核心分层（从上到下）：
- 应用层（ASW）：写业务逻辑的地方，比如车窗控制、空调策略。
- 运行时环境（RTE）：相当于软件总线，负责应用层和基础软件层之间的通信。
- 基础软件层（BSW）：再往下细分，包括服务层、ECU抽象层、微控制器抽象层。
诊断相关的模块，就藏在BSW的服务层里。嗯，这里要注意，诊断不是应用层的活，它是基础软件的一部分，负责跟外部诊断仪打交道。
1.2 诊断协议栈：DCM、DEM、FIM 的关系
诊断协议栈是三个模块的合称。很多新手搞不清它们的分工，我当年也犯过这个错。咱们一个一个说。
| 模块 | 全称 | 核心职责 |
|---|---|---|
| DCM | Diagnostic Communication Manager | 负责诊断请求的接收、解析、路由和响应。说白了，它是诊断的“门卫”和“翻译官”。 |
| DEM | Diagnostic Event Manager | 负责诊断事件（故障）的监控、存储和管理。它是ECU的“黑匣子”。 |
| FIM | Function Inhibition Manager | 根据故障状态决定是否禁止某些功能。它是“看门人”，出了问题就锁住相关功能。 |
我的经验： 这三个模块的协作关系，你可以想象成医院流程——DCM是挂号处，接收病人（诊断请求）并分诊；DEM是病历室，记录病情（故障事件）；FIM是主治医生，根据病历决定要不要停药（禁止功能）。
它们之间的数据流是这样的：
- 诊断仪发请求 → DCM解析 → 如果是读取故障码，DCM就去问DEM要数据。
- 应用层检测到异常 → 上报给DEM → DEM记录事件 → DEM通知FIM更新功能状态。
- FIM根据故障严重程度 → 决定是否禁止某个SWC（软件组件）的运行。
我曾经在一个项目中，DEM和FIM的接口没配置好，导致一个轻微故障直接锁死了刹车灯。嗯，那会儿被测试部门追着改了一周。所以这三个模块的交互逻辑，一定要在前期就理清楚。
1.3 UDS协议基础
UDS（Unified Diagnostic Services）是ISO 14229定义的一套诊断服务规范。它规定了诊断仪和ECU之间怎么说话、说什么话。
UDS的核心结构，我总结为“三要素”：
- 服务ID（SID）：一个字节，标识要执行什么操作。比如0x10是诊断会话控制，0x22是读取数据。
- 子功能（Sub-function）：可选，进一步细化操作。比如0x10服务下的0x01表示默认会话，0x02表示编程会话。
- 数据参数（Data）：请求或响应中携带的具体数据。
常用的UDS服务（我项目中几乎天天用）：
- 0x10：诊断会话控制（切换模式）
- 0x22：读取数据标识符（读DID）
- 0x2E：写入数据标识符（写DID）
- 0x19：读取故障码信息（读DTC）
- 0x14：清除故障码信息
- 0x31：例程控制（执行特定程序）
- 0x34/0x36/0x37：下载/上传数据（刷写用）
UDS的响应格式也很有讲究。正响应是SID+0x40，比如请求0x22，正响应就是0x62。负响应呢？统一用0x7F开头，后面跟着请求的SID和一个否定响应码（NRC）。
避坑指南： 我曾经遇到过一个ECU，发送0x22请求后一直不回响应。查了半天，发现是DCM配置里把该DID的访问权限设成了“仅编程会话”，而当前ECU处于默认会话。所以，配置会话和访问权限时一定要跟需求文档逐条核对，否则调试起来很痛苦。
UDS的传输层通常基于CAN总线，也就是ISO 15765-2（CAN TP）。它解决了单个CAN帧装不下完整UDS报文的问题——超过8字节的数据需要分包发送。这个后面讲DCM实现时会详细展开。
好了，这一章的内容就是这些。记住三个关键词：AUTOSAR三层架构、诊断三模块分工、UDS三要素。后面的章节，我们会一步步深入到每个模块的代码实现中去。