3. 车载诊断标准与法规要求

在AURIX这类车规级MCU上开发诊断系统，真正决定“能不能上线”的往往不是代码写得多漂亮，而是是否满足一整套标准与法规的约束。ISO 14229（UDS）、ISO 15765（DoCAN）、ISO 26262（功能安全）以及OBD-II与欧VII排放法规，分别从应用层服务、网络传输、安全机制和排放合规四个维度，对诊断系统提出了不同层次的要求。理解它们之间的分工与衔接，是后续在AURIX上做诊断协议栈配置、故障管理和安全设计的前提。

一、ISO 14229（UDS）：应用层诊断服务的统一语言

ISO 14229定义的是统一诊断服务（Unified Diagnostic Services，UDS），它工作在OSI模型的应用层，规定了诊断仪与ECU之间“说什么”。UDS的核心是服务标识符（SID）与子功能（Sub-function）的组合，常见服务包括：0x10会话控制、0x11 ECU复位、0x14清除诊断信息、0x19读取DTC信息、0x22按标识符读数据、0x27安全访问、0x2E按标识符写数据、0x31例程控制、0x3E保持连接、0x85控制DTC设置等。

UDS本身不关心底层是CAN、CAN FD还是以太网，它只规定请求与响应的格式。一个典型请求由SID、子功能、数据参数组成，正响应为“SID+0x40”，负响应为0x7F加原SID再加否定响应码（NRC）。例如读取DTC的请求为 19 02 FF，其中0x19是服务，0x02是子功能“按状态掩码报告DTC”，0xFF是状态掩码；若ECU不支持该子功能，会返回 7F 19 12，0x12表示subFunctionNotSupported。

在AURIX项目中，UDS服务通常由诊断协议栈（如Vector CANdela或自研栈）实现，开发者需要关注的是：哪些服务必须支持、会话与安全等级的映射关系、DTC状态位的定义是否符合ISO 14229-1的位定义（如testFailed、confirmedDTC、pendingDTC等）。这些状态位直接决定诊断仪能否正确读出故障的“当前/历史/已确认”状态。

二、ISO 15765（DoCAN）：诊断报文如何在CAN上传输

ISO 15765解决的是“怎么传”。它把UDS的请求/响应数据映射到CAN帧上，核心机制是网络层分段与重组。当诊断数据长度超过单帧CAN（经典CAN 8字节，CAN FD最多64字节）时，需要拆分为首帧（FF）、连续帧（CF）、流控帧（FC）和单帧（SF）。

以经典CAN为例，单帧最多携带7字节有效数据（PCI占1字节）。若发送 22 F1 90（读取VIN）这类短请求，可用单帧；若响应VIN为17字节，则需首帧声明总长度，再由ECU发送流控帧（含BS块大小和STmin最小间隔），诊断仪按节奏发送连续帧。ISO 15765-2还规定了寻址方式：物理寻址用于点对点，功能寻址用于一对多广播（如0x7DF）。

在AURIX上，这部分通常由CAN驱动与CAN TP层配合完成。需要配置的关键参数包括：CAN波特率（如500 kbit/s）、发送/接收ID（如0x7E0/0x7E8）、STmin与BS、以及超时时间N_As、N_Ar、N_Bs、N_Cr。这些参数若与诊断仪不一致，会出现“请求发出但无响应”或“连续帧丢失”的典型问题。

三、ISO 26262：功能安全对诊断的要求

ISO 26262并不直接规定诊断服务，但它要求对安全相关功能进行故障检测与响应，这使诊断成为安全机制的一部分。核心概念包括：安全目标（Safety Goal）、功能安全需求（FSR）、技术安全需求（TSR）、安全机制（Safety Mechanism）以及诊断覆盖率（DC）。

对诊断系统而言，ISO 26262带来的约束主要有三点：第一，安全相关故障必须能被检测并进入安全状态，这通常通过周期性自检、看门狗、锁步核比较、ECC校验等机制实现，检测结果需以DTC或安全状态标志的形式记录；第二，诊断覆盖率需要量化，例如某安全机制对目标故障模式的DC达到90%以上，才能支撑相应的ASIL等级；第三，诊断本身不能成为新的风险源，例如清除DTC或复位操作需受安全访问保护，避免被误触发。

在AURIX上，这体现为SMU（安全管理单元）、锁步核、ECC、看门狗等硬件安全机制与诊断软件的联动：硬件检测到故障后触发报警，软件在诊断任务中读取状态并置位对应DTC，同时根据安全需求决定是否限制功率或进入降级模式。

四、OBD-II与欧VII：排放法规对诊断的约束

OBD-II（美国）和欧VII（欧盟）属于法规层面的强制要求，它们关注的不是“诊断服务怎么实现”，而是“排放相关系统必须被监控到什么程度”。OBD-II要求对催化器、氧传感器、失火、燃油系统、EGR等进行连续或非连续监控，并定义了标准化的DTC、冻结帧、就绪状态（Readiness）和MIL灯控制。

欧VII在OBD-II基础上进一步加严，要求更全面的在用车监控（IUPR）、NOx传感器监控、颗粒物过滤器监控等，并对诊断的鲁棒性提出更高要求。对ECU开发者的直接影响是：排放相关DTC的触发条件、确认逻辑、清除条件必须严格符合法规，且不能被非授权操作随意清除。

下表对比四类标准在诊断系统中的定位，便于建立整体认知：

五、四类要求的协同关系

这四类要求并非孤立。一个典型的排放相关故障处理链路是：AURIX上的监控软件检测到失火，按ISO 26262要求确认故障并进入安全响应，同时按OBD-II/欧VII要求置位DTC、点亮MIL、记录冻结帧；诊断仪通过ISO 15765传输的UDS服务0x19读取DTC，通过0x14清除（需满足法规规定的清除条件）。整个链路中，UDS负责“表达”，DoCAN负责“传输”，功能安全负责“判断与响应”，法规负责“约束边界”。

从工程实践角度看，建议在AURIX项目启动阶段就建立一张“诊断需求追溯表”，把每条UDS服务、每个DTC、每项安全机制和每条法规要求对应起来。例如：DTC P0301（失火）对应OBD-II监控要求、ISO 26262安全响应、UDS 0x19读取和0x14清除；其传输依赖ISO 15765的物理寻址0x7E0/0x7E8。这样在后续做诊断验证时，可以按标准逐项确认，而不是等到整车测试才发现某条法规要求未被覆盖。

综上，ISO 14229、ISO 15765、ISO 26262、OBD-II与欧VII分别从服务、传输、安全和法规四个层面约束诊断系统。在AURIX开发中，只有把四者作为整体来设计，才能保证诊断功能既可用、又安全、还合规。