企业官网建设流程全解析

01 诊断测试要做什么：先看懂分层

现在的整车诊断普遍基于UDS（ISO 14229），跑在 CAN 上时中间还要套一层传输层 ISO-TP（ISO 15765-2）负责多帧拆装。CANoe 作为 Tester，诊断栈一共四层：

CAN 诊断分层架构

日常打交道最多的是 UDS 服务层，先混个脸熟：

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：

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 管批量。结合故障注入，"制造异常 → 确认感知 → 清码恢复"的实车验证闭环就完整了。