1. 诊断协议栈概述：车载诊断协议栈的架构、分层模型与ECU中的位置
大家好，我是老周。今天咱们聊聊诊断协议栈的总体架构。说实话，这玩意儿是车载ECU开发的基石，也是很多新手最容易懵圈的地方。
你想想看，一辆车上有几十个ECU，每个ECU都可能出故障。怎么统一管理？怎么标准化诊断？这就是诊断协议栈要解决的问题。我个人习惯把诊断协议栈看作一个“翻译官”——它把诊断仪发来的请求，翻译成ECU能理解的内部操作，再把结果翻译回去。
1.1 诊断协议栈的分层模型
先看这张分层图，我当年刚入行时，对着这张图看了三天才真正理解。
| OSI层 | 诊断协议栈对应层 | 典型协议/模块 |
|---|---|---|
| 应用层 (Layer 7) | 诊断应用层 | UDS (ISO 14229-1) |
| 表示层 (Layer 6) | （通常合并到应用层） | 数据格式定义 |
| 会话层 (Layer 5) | 诊断会话管理 | 非默认会话、安全访问 |
| 传输层 (Layer 4) | 传输协议层 | ISO 15765-2 (DoCAN), ISO 10681-2 (DoIP) |
| 网络层 (Layer 3) | 网络层 | 单帧/多帧传输、流控制 |
| 数据链路层 (Layer 2) | 数据链路层 | CAN (ISO 11898), Ethernet (IEEE 802.3) |
| 物理层 (Layer 1) | 物理层 | CAN收发器、以太网PHY |
嗯，这里要注意：实际开发中，我们通常不会严格按OSI七层来划分。更常见的做法是分成三层：应用层、传输层、网络层+数据链路层。说白了，就是把OSI的上三层合并，下两层合并。
核心观点：诊断协议栈的本质，就是一套“请求-响应”的通信机制。上层定义“说什么”，下层定义“怎么说”。
1.2 OSEK/VDX与AUTOSAR的分层思想
说到分层模型，就绕不开OSEK/VDX和AUTOSAR。这两个标准，我建议你当成“圣经”来读。
OSEK/VDX时代，诊断模块叫OSEK-COM。它把通信分成了三层：
- 应用层：处理诊断数据
- 交互层：管理会话、时序
- 数据链路层：收发CAN报文
我在项目中遇到过一个问题：OSEK-COM的交互层对多帧传输的支持很弱。当时我们做Bootloader升级，传输大文件时经常丢帧。后来查了三个月，才发现是交互层的超时参数没配好。嗯，从那以后，我对时序参数就特别敏感。
AUTOSAR时代，诊断栈被拆得更细了。我列一下关键模块：
- DCM (Diagnostic Communication Manager)：诊断通信管理器，负责解析UDS请求、路由、会话管理
- DEM (Diagnostic Event Manager)：诊断事件管理器，负责DTC的存储、状态管理
- FIM (Function Inhibition Manager)：功能抑制管理器，控制诊断功能的启用/禁用
- CanTp / DoIP_Tp：传输协议模块，处理单帧/多帧分包
- CanIf / EthIf：接口层，抽象硬件差异
我的建议：如果你是新手，先死磕DCM和DEM。这两个模块占了诊断栈80%的工作量。CanTp虽然重要，但配置工具（如Vector DaVinci）能帮你搞定大部分。
1.3 诊断协议栈在ECU中的位置
诊断协议栈不是独立存在的。它嵌在ECU的软件架构里，跟其他模块有千丝万缕的联系。我画个简图帮你理解：
+------------------------------------------+
| 应用层软件 (ASW) |
| (空调控制、车窗控制、发动机管理...) |
+------------------------------------------+
| 运行时环境 (RTE) |
+------------------------------------------+
| +--------+ +--------+ +--------+ |
| | DCM | | DEM | | FIM | |
| +--------+ +--------+ +--------+ |
| | CanTp | | CanIf | | 其他BSW| |
| +--------+ +--------+ +--------+ |
| | CAN/Ethernet驱动 |
| +--------------------------------------+
| 微控制器 (MCU) |
+------------------------------------------+你看，诊断协议栈位于基础软件层 (BSW)。它向上通过RTE跟应用层交互，向下通过驱动层跟硬件交互。
这里有个关键点：诊断协议栈不直接控制硬件。比如你要读一个传感器的值，DCM收到请求后，会通过RTE调用应用层的接口。应用层再去读ADC，把结果返回。说白了，诊断栈只负责“传话”，不负责“干活”。
避坑指南：我曾经见过一个团队，把诊断逻辑直接写在应用层代码里。结果换了一个诊断仪，协议不兼容，整个应用层都要重写。记住：诊断协议栈必须独立于应用逻辑。这是架构红线，不能碰。
1.4 为什么分层这么重要？
你可能会问：搞这么复杂干嘛？直接写个函数处理诊断请求不行吗？
我举个例子你就明白了。假设你的ECU原本用CAN通信，现在要升级到车载以太网。如果诊断栈是分层设计的，你只需要换掉底层的CanTp和CanIf，换成DoIP_Tp和EthIf。上层的DCM、DEM完全不用动。
但如果是一锅粥的架构，呵呵，那你就等着加班吧。我在2018年就经历过一次这样的迁移，整整花了6个月。如果当时用了AUTOSAR分层架构，估计2个月就能搞定。
所以，分层模型不是学术上的花架子。它是实实在在的工程实践，能帮你省时间、省钱、省头发。
1.5 小结
这一章我们聊了：
- 诊断协议栈的分层模型，从OSI七层到实际的三层划分
- OSEK/VDX和AUTOSAR的架构差异，以及AUTOSAR的关键模块
- 诊断栈在ECU软件架构中的位置，以及它跟应用层的关系
下一章，我会带你深入DCM模块，看看一个诊断请求从收到到响应的完整流程。到时候我会分享一个我踩过的坑——关于会话超时的，保证让你印象深刻。
公众号:蓝海资料掘金营，微信deep3321