01 诊断测试要做什么：先看懂分层
现在的整车诊断普遍基于 UDS（ISO 14229） ，跑在 CAN 上时中间还要套一层**传输层 ISO-TP（ISO 15765-2）**负责多帧拆装。CANoe 作为 Tester，诊断栈一共四层：
CAN 诊断分层架构
日常打交道最多的是 UDS 服务层，先混个脸熟：
| SID | 服务 | 典型用途 |
|---|---|---|
| 0x10 | DiagnosticSessionControl | 切换默认/扩展/编程会话 |
| 0x22 / 0x2E | 读 / 写 DID | F190 读 VIN，F195/F19A 读软硬件版本 |
| 0x19 / 0x14 | 读 / 清 DTC | 19 02 按状态读码，14 FF FF FF 清码 |
| 0x27 | SecurityAccess | Seed-Key 安全解锁后才能写/刷写 |
| 0x31 | RoutineControl | 自检、擦除、复位等例程 |
| 0x3E | TesterPresent | 非默认会话下的在线保活 |
02 硬件连接与寻址
硬件与上一篇完全相同：笔记本 + CANoe 12 + VN1630 + OBD 转接线，DB9 的 7/2/3 脚对应 OBD 的 6/14/4·5。诊断阶段一般不需要断接盒，直接挂 OBD 口即可。
连接之前先搞清寻址方式------这决定了你的请求发给谁：
物理寻址 vs 功能寻址
▪ 物理寻址：点对点，Tester 用某 ECU 的请求 ID（如 0x7E0），只有它应答（0x7E8）------常规测试都用它
▪ 功能寻址 ：广播，统一用 0x7DF，总线上所有诊断节点都会收到（如全体进入编程会话）------慎用，会唤醒整网
注意： 各 OEM 的诊断 ID 分配不同（7E0/7E8 只是常见值），网关车型多数只在外部诊断口暴露网关或特定域控器的 ID，其余 ECU 的诊断要经网关路由。以整车诊断规范（DID/ID 分配表）为准。
03 三步搭好诊断环境
▍3.1 打开诊断配置
切换到 Simulation Setup 环境，点击工具栏**【Diagnostic/ISO TP】图标**，打开诊断与传输层配置窗口。
▍3.2 导入诊断描述（CDD/ODX）
在配置窗口中添加诊断描述文件：
▪ 有 OEM 提供的 CDD / ODX：选第一项，加载对应 ECU 的诊断数据库（服务、DID、参数都在里面）
▪ 没有：选Vector 标准 CDD（Basic Diagnostics，UDS），或用 Basic Diagnostics Editor 自建需要的几个服务
▍3.3 Transport Layer 与 Diagnostic Layer
▪ Transport Layer ：设置请求 ID / 响应 ID（如 7E0 / 7E8）、寻址格式（正常 11 位）、总线类型与波特率；CAN FD 诊断在此启用 FD 支持
▪ Diagnostic Layer ：一般保持默认；要发 27 服务时在 Seed&Key DLL 处加载 OEM 提供的解锁算法库
配置完成后打开Diagnostic Console（菜单 Diagnostics → Diagnostic Console），界面分三块：
04 Diagnostic Console 手动实战
▍4.1 读 VIN：一次标准的多帧交互
左侧服务树双击 ReadDataByIdentifier，DID 填 F190；也可以在 Raw 模式直接输入 22 F1 90，点 Execute 。响应 62 F1 90 + 17 字节 VIN 共 20 字节，超过单帧容量，CANoe 自动走 ISO-TP 多帧流程：
这就是为什么不建议用 IG 模块发诊断：单帧请求勉强能拼，长报文的手工 FF/FC/CF 拆装既繁琐又容易错，而诊断描述 + 传输层把这些全自动化了。
4.2 会话与安全访问
▪ 先 10 03 进入扩展会话（读 DID/写操作大多要求非默认会话）
▪ 安全访问 27 01 收 Seed → 27 02 回 Key------加载了 Seed&Key DLL 后 Console 会自动算 Key，无需手算
▪ 注意 S3 定时 ：非默认会话下若约 5s（典型值）收不到 3E，ECU 会回落默认会话并重新上锁------点亮工具栏 **【Tester Present on】**图标，CANoe 自动周期发 3E 80
▍4.3 读清 DTC 与功能寻址
▪ 读码 19 02 FF（按状态掩码读全部），清码 14 FF FF FF，响应区直接显示 DTC 列表与状态位
▪ 需要广播时：诊断描述属性 【Functional Group Requests】 里添加功能组描述（0x7DF），Console 即可用功能寻址发送
▍4.4 看懂负响应（NRC）
负响应格式 7F SID NRC，常见 NRC：
| NRC | 含义 | 常见原因 |
|---|---|---|
| 0x11 / 0x12 | 服务 / 子函数不支持 | 当前会话不支持，或 CDD 与实际 ECU 不符 |
| 0x22 | 条件不满足 | 车速不为 0、会话不对等前置条件 |
| 0x31 | 请求超出范围 | DID 不存在、参数值非法 |
| 0x33 / 0x35 / 0x36 / 0x37 | 安全拒绝 / 无效密钥 / 超次数 / 延时未到 | 未解锁就写、Key 错、连续失败超限后锁定 |
| 0x78 | 响应待处理（Pending） | ECU 忙，属正常现象，等 P2* 内的最终响应 |
05 CAPL 自动化诊断
CAPL 的诊断对象名称来自诊断描述（CDD/ODX 中的限定名）。
5.1 事件驱动：发请求、接响应
5.2 测试模块：带判定与超时
把读版本、读 DTC、安全访问、清码做成一串 testcase，结合故障注入脚本，就是一个完整的**"注入 → 感知 → 恢复"自动化闭环**。
06 没有诊断描述文件怎么办
拿不到 OEM 的 CDD/ODX 是常态，三个替代方案按优先级排：
▪ Vector 标准 CDD：添加诊断描述时选第四项，UDS 基本服务开箱即用（27 服务无法自动解锁------那需要 OEM 的 DLL）
▪ Basic Diagnostics Editor：自建几个需要的服务和 DID，轻量够用
▪ 手搓单帧请求：会话控制、保活这类单帧服务，直接按 ISO-TP 单帧格式发原始报文：
07 常见坑与排查
▪ 完全无响应：先看 Trace 里请求发出去了没有------ID 配错、TL 没映射到通道、网关不路由外部诊断，都是常见原因
▪ 频繁 0x78：Pending 是正常现象（ECU 处理慢），P2* 内等到最终响应即可，不要当成失败
▪ 功能寻址"炸网"：0x7DF 会唤醒/影响所有节点，整网休眠测试期间千万别发
▪ 27 服务被锁：连续错 Key 触发延时（0x37）后耐心等待，别继续爆破，部分 ECU 掉电才解锁
▪ 写服务要谨慎：2E 写 DID、31 例程控制可能改 ECU 配置/触发动作，实车上先确认目标与影响，最好先在台架验证脚本。
08 小结
CANoe 诊断测试一句话总结：诊断描述管编解码，Transport Layer 管收发，Diagnostic Console 管手动，CAPL 管批量。结合故障注入，"制造异常 → 确认感知 → 清码恢复"的实车验证闭环就完整了。