6.1 UDS诊断：一次完整的诊断会话

6.1 UDS诊断：一次完整的诊断会话

本节摘要：UDS（ISO 14229）是乘用车诊断的通用语言，也是本章四套协议中最值得精学的一套。本节沿一次真实会话走完全程：进会话、过安全访问、读数据、清故障码，报文逐帧标注，拆包与流控机制顺带讲透。学完本节，诊断仪屏幕上滚动的报文对你将不再是天书。

一次会话的全过程，是对UDS最好的讲解方式。先立好两个底座：其一，UDS的报文模型是"请求—响应"——诊断仪发请求报文，控制器回响应报文，两者用同一个标识符对区分方向（诊断仪到网关用请求ID，返回用响应ID，典型如七百二十与七百二十八）。其二，八字节装不下的内容靠ISO 15765-2拆包传输，这是理解会话报文的前置技能，本节在走会话时随用随讲。

从进会话到出会话

诊断会话是UDS的"模式开关"。默认会话里只有基础服务可用；扩展会话解锁写数据、例程控制等进阶服务；编程会话用于刷写。一切敏感操作前必须先切会话，这是UDS安全模型的第一道闸。

下面走一个"读取并清除故障码"的最小完整会话，报文取自诊断仪日志的真实格式，注释逐段标注：

诊断仪 发送  7E0#0210030000000000     ; 进扩展会话  服务0x10 子功能0x03
控制器 响应  7E8#065003003201F400     ; 正响应  含会话定时参数
诊断仪 发送  7E0#0227010000000000     ; 安全访问第一步 请求种子  服务0x27 子功能0x01
控制器 响应  7E8#056701AABBCC00       ; 回种子  AABBCC
诊断仪 发送  7E0#06270212345678       ; 安全访问第二步 回密钥  服务0x27 子功能0x02
控制器 响应  7E8#0267020000000000     ; 正响应  解锁成功
诊断仪 发送  7E0#03190209000000       ; 读故障码  服务0x19 子功能0x02 掩码0x09
控制器 响应  多帧拆包                  ; 故障码列表较长  拆包传输
诊断仪 发送  7E0#0214000000000000     ; 清故障码  服务0x14 组0x00
控制器 响应  7E8#0154000000000000     ; 正响应
​

注意第三行起的拆包机制。故障码列表超过八字节时，响应报文变成多帧结构：首帧声明总长度，随后连续帧携带数据，中间穿插流控帧——接收方通过流控帧告知发送方"可以连发几帧、间隔多久"。三个连续帧的参数（块大小、间隔时间）是拆包吞吐的调节阀，刷写场景会把间隔调到最短，这正是第5章刷写提速的另一半配合。

安全访问的两步握手值得多看一眼：第一步只拿种子，第二步用种子做输入算出密钥回传。算法是保密约定，控制器端校验通过才解锁。这个机制的强度直接决定诊断接口的攻击成本，第7章还会回头检讨它的弱点。

案例：一次"清不掉"的故障码

背景：售后反馈某车故障灯常亮，读出太阳能传感器通信丢失的故障码，执行清除后数十秒故障灯复亮。操作：按本节会话流程重做并全程抓帧，发现清码成功后立即重读，故障码在数秒后重新置位——控制器在周期性检测中持续发现信号缺失。检查传感器供电线路，发现插接件氧化。结果：修复线路，清码后不再复现。解读：这个案例建立了对故障码的正确预期——它是症状记录而非病根，清码是验证手段：清后立刻复现说明故障仍在活动，清后不再复现才说明是历史故障。变式：若故障码为历史性（状态位显示"测试未完成"而非"当前失败"），则可能是上一次检测循环被中断，应引导客户复行驶循环而非盲目换件。

服务与定时的骨架

UDS的服务编号是它的词汇表，工程高频的不过十来个：0x10 切会话、0x27 安全访问、0x22 读数据标识符、0x2E 写数据标识符、0x19 读故障码、0x14 清故障码、0x31 例程控制，外加刷写三部曲——0x34 下载请求、0x36 传输数据、0x37 传输退出。前三类覆盖日常诊断，后三类组成刷写流程。定时参数（P2响应时间、会话保持时间）规定了诊断仪与控制器之间"等多久算超时"，排障时要记得会话会因空闲超时自动回落默认会话——很多"写数据莫名失败"的根因是会话早已回落，操作落在了默认会话的权限外。

安全访问的工程注意点还有两条。其一，种子密钥算法的保密性有限，安全等级是"防误操作"而非"防专业攻击"，防御纵深要靠网关过滤与访问控制补齐。其二，失败尝试次数有上限，连续错误密钥会触发延迟惩罚，自动化脚本盲试会把自己锁进冷却期。

刷写三部曲的时序骨架

刷写是UDS最复杂也最考验协议功底的应用，骨架是三个服务的循环：0x34请求下载（声明地址与长度）、0x36传输数据（搬运载荷）、0x37退出传输（收尾校验），循环执行直到整个数据块搬完。每个环节都有定时参数盯着：响应超时、连续帧间隔，任何一处超时都会让控制器回滚到安全状态。刷写通常配合0x31例程控制做擦除、校验与完整性检查，构成"擦—写—验"的完整闭环。

量产刷写的工程要点：时序参数要在最差工况下验证——电压跌落、温度极限、总线负载满载时的刷写仍须可靠；断点续传与断电保护是量产必须项，产线断电不稀奇，刷到一半的控制器重启后必须能安全重来。诊断协议的健壮性，最终都体现在这些"不体面"的异常路径上。

另一个高频疑问：诊断报文会不会干扰正常控制？会——刷写时的大流量与周期报文共存，负载冲击显著。成熟做法是刷写前由网关进入编程模式：抑制非关键周期报文、降低干扰源，刷写完成后再恢复。这个模式切换本身也有标准服务约定，是诊断与网络管理两个体系的交接面。

顺带把本节与第4章连一条线：诊断报文同样受错误机制管辖——刷写大流量阶段若线束余量不足，错误帧重传会显著拖慢进度甚至触发超时回滚。物理层的健康度是刷写成功率的隐形前提，量产前务必核查。

本节要点回顾

• 会话是权限的开关：默认、扩展、编程三档，敏感操作先切会话，空闲超时自动回落。
• 拆包与流控是UDS的物流系统：首帧报长度、连续帧运货、流控帧调节奏，刷写提速靠调参。
• 安全访问是两步握手：种子加密钥，防误操作够用，防攻击要靠纵深。
• 清码是验证手段：清后复现说明故障活动，不复现才可能是历史故障。
• 高频服务十来个：会话、安全、读写、故障码、例程、下载三部曲，覆盖九成日常。

诊断是乘用车的通用语言。下一节切换到商用车场景，看J1939如何用二十九位地址空间装下整个车队。