第一章：诊断基础与标准体系
各位同学，大家好。我是你们这堂课的讲师。在汽车电子这行摸爬滚打十几年，我最大的感触就是：诊断协议这东西，看着是标准，用起来全是坑。今天咱们就从最基础的地基开始聊。
你想想看，一辆现代汽车里有多少个ECU？少则三四十，多则上百。这些ECU来自不同供应商，用着不同芯片，跑着不同操作系统。它们之间怎么通信？出故障了怎么排查？这就是诊断协议要解决的核心问题。
ISO 14229 (UDS) 协议栈概述
UDS，全称是统一诊断服务。说白了，它就是一套标准化的“问诊”语言。不管你是发动机ECU，还是车身控制器，只要支持UDS，诊断仪就能用同样的方式跟它对话。
我个人习惯把UDS协议栈分成三层来看：
- 应用层：定义了具体的诊断服务，比如读取故障码、读写数据、执行例程等。这一层有26个标准服务，用SID（服务标识符）来区分。
- 会话层：管理诊断会话的状态机。默认会话、扩展会话、编程会话...不同会话下能用的服务不一样。嗯，这里要注意，很多ECU在默认会话下是不允许写操作的，这是安全机制。
- 传输层：负责把诊断数据打包成网络能传输的格式。比如CAN总线上，一帧最多传8个字节，超过8字节就得分包。
核心要点：UDS的核心思想是“请求-响应”模式。诊断仪发请求，ECU给响应。响应分两种：肯定响应（服务ID+0x40）和否定响应（0x7F+否定码）。
我在项目中遇到过一件事。有个ECU，诊断仪发读取故障码请求，它就是不回。查了两天，最后发现是会话没切到扩展模式。你看，基础的东西往往最容易出问题。
ISO 13400 (DoIP) 协议栈概述
DoIP，就是基于以太网的诊断协议。为什么需要它？因为CAN总线太慢了。现代汽车电子系统越来越复杂，OTA升级、大数据量诊断，CAN那点带宽根本不够用。
DoIP协议栈比UDS多了一层——传输层用的是TCP/UDP。它把UDS的请求封装在以太网帧里，通过IP网络传输。这里有几个关键点：
- 物理层：100BASE-T1或1000BASE-T1，这是汽车专用的以太网物理层，跟咱们办公室的以太网不一样。
- 传输层：TCP用于可靠传输，UDP用于广播和发现。诊断仪怎么找到ECU？靠的是DoIP的车辆发现机制——UDP广播。
- 应用层：还是UDS那套服务，只是传输载体从CAN换成了以太网。
实战技巧：DoIP测试时，我最常遇到的问题是TCP连接超时。很多ECU的TCP栈实现有bug，连接数一多就挂。我建议你在测试用例里加上连接压力测试。
SAE J1939 诊断协议简介
J1939是商用车和工程机械领域的老大哥。它基于CAN总线，但跟UDS的CAN实现不太一样。J1939的报文ID有29位，比UDS用的11位ID复杂得多。
J1939诊断的核心是DM（诊断消息）系列：
| DM编号 | 功能 | 对应UDS服务 |
|---|---|---|
| DM1 | 主动发送故障码 | 无直接对应 |
| DM2 | 读取历史故障码 | 0x19 读故障码 |
| DM3 | 清除故障码 | 0x14 清除故障码 |
| DM11 | 读取数据 | 0x22 读取数据 |
我记得有一次给某卡车厂做测试，他们的ECU同时支持UDS和J1939。结果发现，同一个故障码，用UDS读和用J1939读，返回的SPN（可疑参数编号）对不上。后来查标准才发现，J1939的故障码映射规则跟UDS不一样。这种兼容性问题，在混合协议栈的项目里特别常见。
诊断一致性测试的核心概念与意义
好了，前面讲了这么多协议，那怎么知道你的ECU实现得对不对？这就是一致性测试要干的事。
一致性测试，说白了就是拿着标准当尺子，量一量你的实现有没有跑偏。它跟功能测试不一样：功能测试关心“能不能用”，一致性测试关心“符不符合标准”。
为什么一致性测试这么重要？我给你讲个真实案例。曾经有个供应商，他们的ECU在自家台架上测得好好的，一装车就出问题。诊断仪连不上，读不到数据。最后发现，他们的UDS实现里，对“物理寻址”和“功能寻址”的处理搞反了。这种问题，功能测试根本发现不了，只有一致性测试能揪出来。
避坑指南：我曾经见过一个团队，为了赶项目进度，把一致性测试压缩到只测“正案例”——就是所有请求都返回正确响应的情况。结果呢？量产之后，诊断仪一发送格式错误的请求，ECU直接死机。记住，一致性测试一定要覆盖异常场景，尤其是否定响应码的测试。
一致性测试的核心概念包括：
- 测试用例：每个服务、每个参数组合都要有对应的测试用例。标准里写得很清楚，但实现起来细节很多。
- 测试序列：有些服务有先后依赖关系。比如，你得先进入编程会话，才能执行写操作。测试序列就是把这些依赖关系串起来。
- 通过准则：什么算通过？响应时间在范围内？数据格式正确？状态机跳转正确？这些都要明确定义。
我个人习惯把一致性测试分成三个层次：
- 协议层测试：检查报文格式、时序、寻址方式。这是最基础的。
- 服务层测试：检查每个UDS服务的实现是否正确。比如0x22读数据，能不能正确返回数据标识符对应的值。
- 行为层测试：检查ECU在异常情况下的行为。比如收到不支持的服务请求，应该返回0x7F+否定码，而不是直接不理。
你可能会问：这些测试能不能自动化？当然可以。实际上，现在主流的一致性测试工具，比如Vector的CANoe、ETAS的INCA，都支持自动化测试脚本。但我要提醒你，自动化不是万能的。有些场景，比如ECU的启动行为、网络管理状态机，还是得靠人工手动测。
总结一下：诊断一致性测试不是可选项，而是必选项。它就像汽车电子系统的“质检员”，帮你把问题挡在量产之前。我见过太多因为一致性测试没做好，导致召回、索赔的案例。嗯，希望你们不要成为下一个。
好了，第一章的内容就到这里。下一章我们会深入UDS的会话管理和安全访问机制，那是诊断协议里最容易出bug的地方。咱们到时候见。