第三章 诊断需求分析：如何解读OEM的诊断规范

好，咱们进入正题。这一章我要讲的是诊断开发里最容易被忽视、但也是最关键的一步——需求分析。

很多人一上来就写代码、配DBC，结果做到一半发现OEM规范没读懂，回头返工。我见过太多这样的案例了。说白了，诊断需求分析就是「把OEM的规矩翻译成工程师能干活的语言」。

3.1 解读OEM诊断规范——从「天书」到「地图」

OEM的诊断规范，比如VW的VW 80000、BMW的GS 95001，动辄几百页。我第一次拿到VW规范时，说实话，头皮发麻。但后来我总结了一套方法，读起来就快多了。

第一步：先看目录，找核心章节

别从头读到尾。先翻目录，重点关注这几块：

• 诊断服务定义（哪些UDS服务被支持）
• DID列表（数据标识符，比如VIN、软件版本）
• DTC定义（故障码列表）
• 会话与安全访问（什么会话下能做什么事）
• 例程控制（比如刷写、自检）

第二步：提取关键参数

我习惯用Excel建一个表格，把每个服务、DID、DTC的关键信息摘出来。比如：

嗯，这一步很枯燥，但必须做。我见过有人跳过这一步，结果开发到一半发现某个DID的读写权限搞反了，整个重来。

3.2 提取诊断需求列表——从规范到「待办清单」

解读完规范，下一步就是提取需求列表。说白了，就是把OEM的「要求」变成我们开发团队的「任务」。

需求列表应该包含什么？

• 需求ID：唯一编号，方便追溯
• 需求描述：一句话说清楚要做什么
• 来源：OEM规范的章节号
• 优先级：P0（必须）、P1（重要）、P2（可选）
• 实现状态：未开始/进行中/已完成

举个例子，从VW规范里提取的一条需求：

需求ID: REQ_DIAG_001
描述: 支持通过0x22服务读取VIN（DID 0xF190）
来源: VW 80000 第5.2.3节
优先级: P0
实现状态: 未开始

我曾经在一个项目里，团队用这种方式整理了200多条需求。后来OEM来审核，拿着我们的需求列表一条条对，一次通过。为什么？因为每一条都有出处，不是我们自己瞎编的。

3.3 编写诊断功能规范文档——从「需求」到「设计蓝图」

需求列表是给团队内部看的。但诊断功能规范文档，是给所有相关方看的——包括OEM、系统工程师、软件工程师、测试工程师。

文档结构我一般这样组织：

1. 文档概述：目的、范围、术语定义
2. 诊断服务定义：每个UDS服务的详细行为
3. DID详细定义：每个DID的数据格式、读写权限、长度
4. DTC详细定义：每个故障码的触发条件、恢复条件
5. 会话与安全访问：状态机转换图
6. 例程与下载：刷写流程、自检流程
7. 附录：参考文档、变更记录

写文档时要注意什么？

• 用图说话：状态机、时序图比文字管用一百倍
• 明确边界：哪些是ECU该做的，哪些是Tester该做的
• 写清楚异常处理：比如超时了怎么办、NRC怎么返回

举个例子，一个DID的定义：

DID: 0xF190 (VIN)
长度: 17字节
格式: ASCII字符串
访问权限: 默认会话可读，扩展会话可写（需安全解锁）
读行为: 返回17字节VIN，不足部分填充0x20
写行为: 校验长度是否为17字节，否则返回NRC 0x13

你看，这样写出来，软件工程师拿到手就能直接编码，不用再猜。

3.4 避坑指南——我踩过的那些坑

最后，分享几个我亲身经历过的坑，希望能帮你绕过去。

• 坑一：忽略OEM规范的版本号。有一次我拿着V1.2的规范开发，结果OEM已经升级到V2.0了，很多服务都变了。从那以后，我每次开工前第一件事就是确认规范版本。
• 坑二：DID长度搞错。VIN是17字节，但有些OEM要求存成21字节（带校验）。我见过有人按17字节开发，结果OEM测试时发现长度不匹配，直接打回。
• 坑三：会话管理没搞清楚。有些服务只能在特定会话下执行。比如刷写只能在编程会话下做。有人没注意这个，在默认会话下发刷写请求，结果NRC 0x78（请求正确接收，但响应待定）一直挂着，把总线都堵了。

嗯，这些坑说起来都是泪。但吃一堑长一智，现在我做需求分析时，会专门花一天时间做「交叉检查」——让另一个工程师拿着我的需求列表去对OEM规范，看有没有遗漏或误解。

好了，这一章就到这里。下一章我们讲诊断栈的架构设计，到时候我会聊聊怎么选型、怎么搭框架。咱们下章见。