一、DCM诊断协议概述
大家好，我是老张。做汽车电子诊断这块十几年了，今天咱们聊聊DCM诊断协议。说实话，很多刚入行的工程师一看到UDS协议栈就头大，觉得太抽象。其实没那么复杂，咱们把它拆开来看。
1.1 UDS协议栈介绍
UDS，全称是Unified Diagnostic Services，统一诊断服务。说白了，它就是一套标准化的“汽车看病”语言。你想想看，一辆车上有几十个ECU，每个ECU都可能出问题，总得有个统一的沟通方式吧？UDS就是干这个的。
UDS协议栈长什么样呢？我习惯把它分成三层：
- 应用层：定义具体的诊断服务，比如读取故障码、写入数据等
- 会话层：管理诊断会话，控制通信状态
- 传输层：负责数据的分包和重组，确保大报文能正确传输
嗯，这里要注意，UDS是基于OSI模型来的，但实际应用中我们更关注应用层和传输层。我记得刚做第一个项目时，被传输层的TP层搞得晕头转向，后来才发现，其实只要理解了它的分包机制，就没那么难了。
核心要点：UDS协议栈的核心是“请求-响应”模式。诊断仪发一个请求，ECU回一个响应。就这么简单。
给大家看个实际例子。假设我们要读取ECU的软件版本号：
// 诊断请求：读取数据通过标识符（0x22服务）
// 请求报文：22 F1 90
// 含义：服务ID=0x22，数据标识符=0xF190（软件版本号）
// 正常响应：62 F1 90 01 02 03 04
// 含义：肯定响应，数据标识符=0xF190，数据=01 02 03 04（版本号）
// 异常响应：7F 22 31
// 含义：否定响应，服务ID=0x22，否定码=0x31（请求超出范围）
这个例子很典型。我在项目中遇到过好几次，工程师写对了请求，但ECU就是不回正确响应。后来发现，原来是数据标识符的格式搞错了。0xF190和0x90F1，顺序一颠倒，ECU就不认了。
1.2 DCM在AUTOSAR架构中的位置
AUTOSAR架构，说白了就是把汽车软件标准化。DCM（Diagnostic Communication Manager）是AUTOSAR架构中负责诊断通信的模块。
我画了个图，大家看看DCM在AUTOSAR架构中的位置：
从图上可以看出来，DCM位于BSW层，在RTE之下，MCAL之上。它负责接收诊断请求，然后调用相应的服务处理函数。我个人习惯把DCM看作是“诊断通信的交通警察”，它不负责具体的诊断逻辑，只负责把请求正确地分发到该去的地方。
小提示：在AUTOSAR配置工具中，DCM的配置项非常多。我建议新手先从“诊断服务表”入手，把每个服务ID对应的处理函数配置好，其他的慢慢来。
1.3 诊断通信的基本流程
诊断通信的基本流程，其实就三步：请求、处理、响应。但实际项目中，细节比这个多得多。
我给大家梳理一下完整的流程：
- 建立物理连接：诊断仪通过CAN、CAN FD或以太网连接到车辆
- 建立诊断会话：发送0x10服务，进入指定的诊断会话模式
- 安全访问（如果需要）：发送0x27服务，通过种子-密钥验证
- 发送诊断请求：比如读取故障码、读取数据等
- ECU处理请求：DCM解析请求，调用对应的服务处理函数
- 发送诊断响应：肯定响应或否定响应
- 结束诊断会话：发送0x11服务（ECU复位）或0x82服务（结束会话）
为什么会这样设计？你想想看，如果任何人都能随便访问ECU，那车辆的安全性就没法保证了。所以安全访问这一步，说白了就是给诊断加了一把锁。
我曾经在一个项目中遇到过这样的问题：诊断仪发送了正确的请求，但ECU就是不响应。排查了半天，发现是诊断会话没有建立成功。嗯，这里要注意，ECU在默认会话模式下，很多诊断服务是不支持的。必须先通过0x10服务切换到扩展会话模式，才能执行读写操作。
避坑指南：我曾经在量产阶段发现，某批ECU在诊断通信时偶尔会超时。后来定位到是传输层的TP层配置问题——发送缓冲区的深度不够，导致大报文被丢弃。所以，配置DCM时一定要根据实际报文大小，合理设置缓冲区。
给大家看个完整的诊断通信时序图：
这个时序图很直观。诊断仪先建立会话，然后做安全访问，最后才发送真正的诊断请求。每一步都有对应的响应，如果哪一步出错了，ECU会返回否定响应，告诉你哪里不对。
好了，关于DCM诊断协议的概述就讲到这里。这些基础概念搞清楚了，后面咱们再深入聊具体的配置和实战技巧，就会轻松很多。
本章小结：
- UDS协议栈分三层：应用层、会话层、传输层
- DCM在AUTOSAR架构中位于BSW层，是诊断通信的核心模块
- 诊断通信的基本流程：建立会话 → 安全访问 → 请求/响应 → 结束会话
- 配置DCM时，注意缓冲区大小和会话模式的切换
可可精品资料库