3. 诊断需求分析与诊断规范解读
在ECU诊断软件开发中，诊断需求文档（Diagnostic Requirement Specification，通常以Word/Excel/PDF形式交付）是OEM对ECU诊断行为的正式约定，而诊断数据库（CDD或ODX）则是ECU软件和诊断工具能够直接解析的机器可读描述。二者之间的转换，是诊断集成工作中最容易出错、也最需要工程化管理的环节。本节围绕“需求文档→诊断数据库”的转换主线，说明诊断服务、DID、DTC的定义方式，以及ETAS工具链中诊断描述文件的管理方法。
一、诊断需求文档与诊断数据库的分工
诊断需求文档回答的是“ECU应该支持哪些诊断行为”：支持哪些UDS服务（如0x10会话控制、0x22按标识符读数据、0x2E按标识符写数据、0x19读DTC信息、0x27安全访问、0x31例程控制、0x3E保持连接等），每个服务的子功能、寻址方式（物理寻址/功能寻址）、会话与安全等级约束、正响应与否定响应码（NRC）行为，以及每个DID的数据长度、数据类型、字节序、缩放与偏移、默认值、写入权限等。
诊断数据库回答的是“这些行为如何被机器执行”：CDD（CANdela Diagnostic Description）以诊断服务、DID、DTC、会话、安全等级等对象组织，供CANdelaStudio编辑、供ISOLAR-AB/ECU软件生成诊断栈配置、供INCA/CANape等工具执行诊断；ODX（Open Diagnostic data eXchange，ISO 22901）则以分层结构（ODX-D诊断层、ODX-C通信参数、ODX-F刷写数据、ODX-E ECU配置）描述同一套诊断能力，常用于跨工具、跨供应商交换。二者本质是同一诊断规范的不同载体，转换的核心是“语义不丢失”。
二、从需求文档到CDD/ODX的转换要点
转换不是简单的“抄表”，而是一次结构化建模。建议按以下顺序推进：
- 建立需求条目编号与数据库对象的映射表。为每条诊断需求分配唯一ID（如REQ-DIAG-0x22-0xF190），并在CDD中为对应DID或服务对象记录该ID，便于后续追溯与变更影响分析。
- 先定义通信与寻址参数。包括诊断请求/响应CAN ID（物理请求、功能请求、响应）、寻址模式、STmin与BS等ISO-TP参数、P2/P2*超时。这些参数决定诊断栈能否正常收发，必须与需求文档中的通信矩阵一致。
- 再定义会话与安全等级。把0x10下的各会话（默认会话0x01、编程会话0x02、扩展会话0x03）与0x27的种子/密钥等级（如Level 1、Level 3）建成CDD中的Session与Security对象，后续每个服务和DID都引用这些对象作为访问前提。
- 逐个定义诊断服务与子功能。明确服务ID、子功能、请求/响应参数结构、支持的NRC集合（如0x13长度错误、0x22条件不满足、0x31请求超出范围、0x33安全拒绝、0x7E子功能不支持、0x7F服务不支持）。
- 定义DID。为每个DID指定标识符、名称、数据长度、数据类型、字节序、物理量换算（缩放因子与偏移）、读写权限、所属会话与安全等级、是否支持0x22/0x2E/0x2F等。
- 定义DTC。包括DTC编号（3字节故障码）、DTC状态位（bit0 testFailed、bit3 confirmedDTC、bit4 testNotCompletedSinceLastClear等）、快照数据（Snapshot）与扩展数据（Extended Data）所关联的DID、清除/老化（Aging）与去抖动（Debounce）策略。
三、诊断服务与DID/DTC定义示例
以VIN（车辆识别码）DID 0xF190为例，需求文档通常描述为“通过0x22读取VIN，17字节ASCII”。在CDD中应展开为：DID标识符0xF190，名称VehicleIdentificationNumber，数据长度17字节，数据类型ASCII字符串，读权限允许，默认会话可读，无需安全解锁，正响应格式为62 F1 90 + 17字节数据。若同时支持写入，则需定义0x2E的写权限、会话与安全等级，并明确写入后是否立即生效或需下电重启。
DTC定义则以P0301（气缸1失火）为例：DTC编号0x030100（3字节），状态位按ISO 14229-1定义，快照数据关联DID 0xF190（VIN）、0xF187（零件号）与转速/负荷等运行条件DID，扩展数据关联发生次数与老化计数器。去抖动策略需说明是计数型还是时间型，例如“连续10个驾驶循环内检测到失火则置位confirmedDTC”。
四、ETAS工具中的诊断描述文件管理
在ETAS工具链中，CDD/ODX文件通常作为工程资产纳入版本管理。典型做法是：在ISOLAR-AB工程中导入CDD，由诊断配置生成器产出诊断栈配置代码（如Dem、Dcm、CanTp相关配置）；在INCA/CANape中导入同一CDD或ODX，用于台架与整车诊断测试。为避免“软件用一版、测试用另一版”的错配，应建立以下管理规则：
- CDD/ODX文件与需求文档版本号绑定，例如需求V2.3对应CDD V2.3.0，并在文件属性中记录变更摘要。
- 每次CDD变更后，重新生成诊断栈配置并执行回归测试，重点验证受影响的服务、DID与DTC。
- 使用ETAS工具的比较功能（如CANdelaStudio的Compare）核对两版CDD差异，确认新增/删除/修改的DID与DTC清单。
- 将CDD/ODX纳入Git或SVN，提交信息中引用需求ID，保证可追溯。
五、转换质量的检查清单
完成CDD/ODX转换后，建议用以下清单做一次自检，避免把问题带到集成阶段：
| 检查项 | 判断依据 | 常见问题 |
|---|---|---|
| 服务与子功能完整性 | 需求文档中每个服务/子功能在CDD中均有对应对象 | 遗漏0x2F或0x31子功能 |
| DID数据格式 | 长度、类型、字节序、缩放偏移与需求一致 | 长度差1字节导致NRC 0x13 |
| 会话与安全权限 | 每个DID/服务的访问前提与需求一致 | 默认会话误开放写权限 |
| DTC状态位与快照 | 状态位定义、快照DID关联正确 | 快照DID未在CDD中定义 |
| NRC集合 | 每个服务支持的NRC与需求一致 | 缺少0x22条件不满足 |
| 通信参数 | CAN ID、寻址、P2/P2*与通信矩阵一致 | 功能寻址响应ID错误 |
诊断需求分析与规范解读的最终产出，是一份可被ETAS工具链直接消费、且与需求文档逐条可追溯的CDD/ODX文件。只有把“需求条目—数据库对象—生成配置—测试用例”这条链路打通，后续的诊断集成与验证才有稳定的基线。