📚 课程目录第2章 ECU诊断基础与ETAS工具链概览

2. ECU诊断基础与ETAS工具链概览

在ECU软件开发与验证中，“诊断”并不是一个附加功能，而是贯穿需求、实现、集成、测试与售后全生命周期的核心能力。它既要在整车下线时判断控制器是否合格，也要在售后维修时帮助技师定位故障，还要在开发阶段为标定与测试提供可观测、可控制的接口。理解诊断，首先要理解两套最常被同时提及的协议：UDS与OBD。

UDS与OBD：目标不同，机制互补

OBD（On-Board Diagnostics）起源于排放法规，核心目标是让外部设备能够读取与排放相关的故障信息。它规定了标准化的诊断座、标准化的服务（如读取故障码、读取冻结帧、读取就绪状态）以及标准化的数据流PID。OBD强调“统一可读”，因此不同厂商的车辆在排放相关诊断上具有高度一致性。

UDS（Unified Diagnostic Services，ISO 14229）则面向更广泛的ECU诊断需求，覆盖读取数据、写入数据、例程控制、安全访问、刷写、DTC控制等。UDS不限定物理层，可以运行在CAN、CAN FD、DoIP、LIN等之上。它强调“能力可描述”，即通过诊断描述文件（CDD/ODX）定义每个ECU支持哪些服务、哪些DID、哪些例程以及会话与安全等级约束。

两者并非替代关系。一个典型的ECU可能同时实现OBD服务用于法规相关诊断，又实现UDS服务用于开发、标定与售后深度诊断。在ETAS工具链中，诊断数据库往往同时导入OBD与UDS描述，测试用例则根据目标选择对应服务。

诊断栈分层结构：从物理帧到应用服务

诊断通信不是单一协议，而是一条分层栈。以CAN上的UDS为例，自下而上通常包括：

物理层与数据链路层：CAN/CAN FD控制器、收发器、仲裁与错误处理，决定报文如何在线束上传输。
网络层：ISO 15765-2（CAN TP），负责将超过8字节的诊断请求/响应拆分为多帧，处理流控、序号与超时。
会话层与传输层：管理诊断会话（默认会话、编程会话、扩展会话）、安全访问（Seed/Key）、通信控制。
应用层：UDS服务（0x10、0x27、0x22、0x2E、0x31、0x19等）与DTC、DID、例程的具体语义。
诊断描述与配置层：CDD/ODX/PDX文件，描述ECU支持的服务、参数、寻址方式与超时。

这条栈的每一层都可能成为集成问题的来源。例如，应用层服务正确但TP层流控参数不匹配，会导致长响应超时；安全访问算法正确但会话切换顺序错误，会导致0x27返回0x7F否定响应。因此，诊断集成必须同时关注“服务对不对”和“链路通不通”。

ETAS工具链的协同分工

ETAS工具链在诊断集成中并不是“一个工具做所有事”，而是围绕诊断描述文件形成分工闭环。

ISOLAR-AB / ISOLAR-EVE承担诊断栈的配置与代码生成。工程师将OEM提供的CDD或ODX文件导入ISOLAR，工具解析出ECU支持的服务、DID、DTC、例程以及会话与安全等级。随后在图形化界面中配置Dcm模块的服务表、Dem模块的故障事件与去抖策略、CanTp的寻址与超时参数。配置完成后生成AUTOSAR诊断栈代码，集成到ECU工程中编译。这一环节决定了“ECU能响应什么、在什么条件下响应”。

CANoe是诊断验证的主力。通过加载CDD/ODX，CANoe的诊断控制台可以手动发送UDS请求并观察响应。例如发送 10 03 进入扩展会话，再发送 27 01 请求Seed，ECU返回 67 01 加Seed值，测试脚本计算Key后发送 27 02 完成安全访问。CANoe的CAPL脚本可以把这些步骤写成自动化序列，批量验证多个DID的读写权限与否定响应码。

CANoe.DiVa进一步把验证自动化。它读取ODX中的诊断描述，自动生成覆盖服务、会话、安全等级、参数边界与异常序列的测试用例，执行后输出通过/失败报告。对于“某个DID在默认会话下是否应返回0x7F 0x22 0x31（请求超出范围）”这类规则，DiVa可以系统化覆盖，减少人工遗漏。

INCA则从测量与标定角度参与诊断。INCA通过XCP/CCP或诊断接口读取ECU内部变量与DID，用于观察诊断相关状态量（如故障计数器、去抖计时器、会话状态）。在标定阶段，INCA可以写入标定参数，验证诊断阈值调整后的行为变化。它与CANoe的分工在于：CANoe验证“诊断服务本身是否正确”，INCA观察“诊断逻辑背后的内部量是否按预期变化”。

LABCAR / HIL提供真实或半真实的运行环境。在ECU硬件未就绪时，可用仿真ECU验证诊断栈配置；在硬件就绪后，HIL台架可以注入总线故障、电压异常、传感器失效等条件，观察DTC是否按去抖策略置位、冻结帧是否记录、诊断响应是否在超时内返回。

一个可复现的诊断集成检查示例

假设某ECU需要验证“扩展会话下读取DID 0xF190（VIN）”。可按下述顺序执行，并记录每一步的请求与响应：

步骤1：默认会话下读取
发送：22 F1 90
预期：7F 22 31（请求超出范围，默认会话不允许）
实际：________

步骤2：切换到扩展会话
发送：10 03
预期：50 03 00 32 01 F4（会话参数）
实际：________

步骤3：扩展会话下读取VIN
发送：22 F1 90
预期：62 F1 90 + 17字节VIN
实际：________

步骤4：安全访问后写入
发送：27 01 → 67 01 + Seed
发送：27 02 + Key → 67 02
发送：2E F1 90 + 新VIN
预期：6E F1 90
实际：________

判断依据：若步骤1返回了正响应，说明会话权限配置过宽；若步骤2返回0x7F 0x10 0x12（子功能不支持），说明Dcm服务表未配置0x03子功能；若步骤3超时无响应，应检查CanTp的块大小与STmin是否与ECU一致；若步骤4的Key计算失败，需核对Seed-Key算法与安全等级映射。

诊断集成的核心不是“能发出一条请求”，而是“在正确的会话、安全等级、寻址方式与超时约束下，得到可预期的响应，并能解释每一个否定响应码”。ETAS工具链的价值在于把描述文件、配置、测试与标定串成可追溯的链条。

常见误区与排障方向

第一，把OBD与UDS混为一谈。OBD的PID读取与UDS的DID读取在服务号、寻址与权限模型上都不同，测试用例必须明确目标协议。第二，只验证正响应，忽略否定响应。0x7F后的NRC（如0x11服务不支持、0x12子功能不支持、0x13长度错误、0x22条件不满足、0x31请求超出范围、0x33安全拒绝、0x78响应挂起）才是诊断健壮性的关键。第三，忽略TP层参数。CAN FD下块大小与STmin的配置差异会直接导致长响应失败。第四，描述文件版本与ECU软件版本不一致，导致“测试通过但实车不响应”。

排障时建议按栈自下而上定位：先用CANoe确认物理层有报文、TP层能完成多帧传输，再确认会话与安全状态，最后核对应用层服务与DID定义。INCA可用于观察ECU内部诊断状态机与故障计数器，HIL可用于复现边界条件。把每一次失败对应到栈的某一层，才能把“诊断不通”转化为可修复的具体配置项。