📚 课程目录第3章车载诊断基础

3. 车载诊断基础

在S32G域控制器中，诊断功能是连接整车网络、ECU软件与售后/OTA系统的关键通道。无论是读取故障码、刷写固件，还是执行OTA升级前的条件检查，底层都依赖一套标准化的诊断协议栈。本节从UDS协议出发，梳理ISO 14229、ISO 15765、DoIP与CAN诊断之间的关系，并重点讲清诊断服务分类、会话切换与安全访问机制。

一、UDS协议与标准体系

UDS（Unified Diagnostic Services，统一诊断服务）是ISO 14229定义的应用层诊断协议。它规定了诊断仪与ECU之间“问什么、答什么”的语义，例如读取数据、写入配置、执行例程、刷写软件等。UDS本身不关心底层是CAN还是以太网，它只定义服务标识符（SID）、子功能、请求/响应格式以及否定响应码（NRC）。

围绕UDS，常见标准分工如下：

ISO 14229-1：UDS应用层服务与要求，是诊断服务的核心定义。
ISO 14229-2：会话层服务，定义诊断会话的建立、保持与超时。
ISO 14229-3：UDS on CAN的实现要求。
ISO 14229-5：UDS on IP（即DoIP）的实现要求。
ISO 15765-2：CAN上的网络层协议，负责多帧传输、分包与重组。
ISO 13400：DoIP协议，定义基于IP的诊断通信。

可以这样理解：ISO 14229是“语言”，ISO 15765-2和DoIP是“传输方式”。S32G域控制器通常同时支持CAN诊断和DoIP诊断，前者用于传统ECU与网关，后者用于高带宽刷写和远程诊断。

二、CAN诊断与DoIP诊断的对比

CAN诊断基于ISO 15765-2，将UDS报文封装为CAN帧。由于经典CAN单帧只有8字节数据，长报文必须通过首帧（FF）、连续帧（CF）、流控帧（FC）和单帧（SF）完成分段传输。DoIP则基于以太网和TCP/UDP，单包可携带大量数据，更适合大文件刷写和OTA场景。

对比项	CAN诊断（ISO 15765-2）	DoIP诊断（ISO 13400）
底层传输	CAN/CAN FD	以太网、TCP/UDP
典型带宽	500 kbps～2 Mbps（CAN FD）	100 Mbps～1 Gbps
寻址方式	CAN ID + 诊断地址	IP地址 + 逻辑地址
适用场景	常规故障读取、小数据写入	大文件刷写、远程OTA、网关诊断
典型端口	无端口概念	UDP 13400、TCP 13400

在S32G域控制器中，DoIP通常由以太网诊断栈实现，CAN诊断由CAN驱动+ISO 15765-2网络层实现，两者最终都向上对接同一套UDS服务处理层。

三、诊断服务分类

UDS服务按SID范围可分为若干类，工程中常按功能记忆：

0x10～0x3E：诊断与通信管理，如0x10会话控制、0x11 ECU复位、0x27安全访问、0x28通信控制、0x3E保持连接。
0x22～0x2E：数据传输，如0x22读数据、0x23读内存、0x2E写数据、0x2F输入输出控制。
0x31～0x34：例程与刷写，如0x31例程控制、0x34请求下载、0x36传输数据、0x37请求退出传输。
0x19、0x14：故障码相关，如0x19读取DTC信息、0x14清除DTC。
0x7F：否定响应，用于返回NRC，如0x13长度错误、0x22条件不满足、0x33安全拒绝、0x78响应挂起。

在S32G项目中，最常见的诊断序列是：进入扩展会话→安全访问→写入/刷写→复位→回到默认会话。每一步都依赖前一步的状态，不能跳步执行。

四、会话与安全访问机制

UDS会话（Session）是ECU诊断状态机的核心。默认会话（0x01）下只允许少量基础服务；扩展会话（0x03）开放更多诊断与写入权限；编程会话（0x02）用于刷写。会话切换通过服务0x10完成，ECU返回0x50确认。若一段时间无诊断请求，ECU会因S3超时自动回到默认会话。

安全访问（Security Access，0x27）用于防止未授权写入。典型流程是“请求种子→计算密钥→发送密钥”。诊断仪先发送0x27 0x01请求种子，ECU返回0x67 0x01 + Seed；诊断仪用约定算法计算Key，再发送0x27 0x02 + Key；ECU校验通过后返回0x67 0x02，解锁成功。若密钥错误，返回0x7F 0x27 0x35（无效密钥），并可能触发延时锁定。

// 典型安全访问交互（示意）
Tester -> ECU : 27 01
ECU -> Tester : 67 01 5A 3C 9F 01
Tester -> ECU : 27 02 8B 7D 22 4E
ECU -> Tester : 67 02
// 若失败
ECU -> Tester : 7F 27 35

下面用一张信号链图展示S32G域控制器中从诊断仪到ECU的完整诊断路径，包括CAN与DoIP两条链路、UDS服务处理以及会话/安全状态机。

五、典型场景与常见误区

以S32G域控制器刷写为例，诊断仪通常先通过DoIP建立TCP连接，发送0x10 0x03进入扩展会话，再执行0x27安全访问，随后用0x34/0x36/0x37完成下载。若中途S3超时，会话回退，刷写会被中断并返回NRC 0x22或0x33。因此工程实现中必须周期性发送0x3E保持连接。

常见误区一：认为“能发UDS请求就能执行服务”。实际上，会话未切换或安全未解锁时，ECU会直接返回否定响应。误区二：忽略ISO 15765-2的流控参数（BS、STmin），导致多帧传输超时。误区三：DoIP场景下未正确处理路由激活（0x0005），导致诊断请求被网关丢弃。

复盘时建议按“物理链路→网络层→会话状态→安全状态→服务权限”的顺序逐层排查。先确认CAN或以太网链路是否通，再确认ISO 15765-2或DoIP是否正常，最后检查0x10和0x27的状态是否满足目标服务的前置条件。只有把协议栈各层关系理清，S32G域控制器的诊断与OTA功能才能稳定落地。