干汽车电子这一行不管你是做嵌入式开发、做测试验证还是做售后诊断工具早晚都要跟UDS打交道。UDS全称Unified Diagnostic Services是ISO 14229标准定义的一套统一诊断服务规范。说人话就是它规定了诊断仪Tester和车上的ECU之间怎么“对话”、能问哪些问题、对方怎么回答。早年各家ECU的诊断协议五花八门一个品牌一套私有指令售后设备厂家苦不堪言。后来行业痛定思痛把诊断服务统一成了UDS这套“普通话”上到CAN、CAN FD下到LIN甚至车用以太网DoIP应用层基本都是它。这篇文章是写给刚接触UDS的新手看的。我会把我在项目里踩过的坑、常用的服务IDSID、正负响应的套路、DTC的读取方式以及刷写Bootloader流程的完整链路都整理出来配合具体报文示例来拆解。看完你至少能看懂诊断仪抓回来的报文能上手写简单的诊断测试脚本也知道遇到NRC负响应码该往哪个方向排查。1. 先把底子打好UDS到底是啥解决什么问题1.1 从“维修工和ECU对话”说起可以这样理解ECU就是车上几十个“小管家”发动机、变速箱、ABS、车身控制器、电池管理各管一摊。正常行驶时它们各干各的但出了问题维修工或者产线设备就得跟它们沟通。怎么沟通UDS就是那本标准问答手册。ISO 14229这个标准定义了UDS的服务、格式、时序要求但它并没有规定数据一定要跑在什么物理层上。这意味着不管ECU是挂在CAN总线上还是挂在LIN总线上诊断仪都能用同一套“语言”跟它说话只是底层的“快递方式”不同。这也是UDS能成为车厂主流诊断协议的根本原因统一、可扩展、有严格的规定。在OEM的实际项目里售后诊断、产线EOLEnd of Line测试、刷写ECU、读取故障码这些场景基本都跑UDS。哪怕不是所有ECU都做全服务的至少0x10诊断会话控制、0x22读取数据、0x19读取DTC这些核心服务是逃不掉的。所以对新人来说UDS不是“可学可不学”的加分项而是吃饭的家伙。1.2 UDS在整个系统里的位置很多新手把UDS和CAN TP搞混这俩其实是两层的东西。UDS工作在OSI模型的应用层它只关心“请求什么服务”“回什么数据”。而CAN总线上一帧最多只能带8字节数据CAN FD可以到64字节如果诊断响应很长比如读VIN码、上传软件数据8字节根本装不下这时候就需要传输层协议把长消息分包发送。在CAN网络上这个分包任务由ISO 15765-2也就是常说的CAN TP完成。CAN TP把上层的一条UDS消息拆成多个CAN帧接收方再拼回去。在以太网上对应的是DoIPISO 13400在LIN总线上也有对应的传输机制但应用层照样是UDS的子集。我把常见场景的下层协议整理成了一个表新手看一眼就能明白该往哪个方向查资料物理层UDS的下层协议典型应用场景CANISO 15765-2CAN TP国内绝大多数车载ECU诊断CAN FDISO 15765-2:2016高速诊断、刷写大软件包以太网ISO 13400DoIP刷写域控制器、远程诊断LINLIN诊断规范基于ISO 14229子集车窗、座椅、天窗等车身小节点如果你在CANoe里看到一堆ID相同、连续帧数据那不是ECU发疯了而是CAN TP在拆包。真正分析诊断逻辑的时候要在应用层看完整的UDS消息不要一条条CAN帧去抠不然很容易被分包搞晕。1.3 一条诊断报文的“快递”路径举个例子诊断仪发一个0x22请求读取ECU的软件版本号。请求很短可能就3个字节。但ECU的响应可能很长比如版本号字符串加起来30字节CAN一帧装不下。于是CAN TP先把这30字节加上协议头拆成单帧、连续帧发出去接收方再重新组装成一条完整的UDS响应。所以你在总线上抓到的往往是好几条CAN帧但在UDS层面它们只是一条“响应消息”。理解这个分层关系对后面排查“为什么没响应”“为什么响应不完整”这类问题特别重要。我见过不少新人看到总线上好几条相同ID的帧就以为ECU发了多条响应实际上人家只是一条被拆开的UDS消息。2. 报文长什么样一次完整的UDS请求与响应2.1 请求、正响应、负响应的基本结构UDS报文的结构其实非常简单它不像某些复杂的应用层协议有那么多头字段。一条请求消息通常是这么组织的请求: [SID] [Sub-function/参数] [参数...]比如请求进入默认会话10 01其中0x10是服务IDSessionControl0x01是子功能默认会话。就这么简单。正响应的规矩是服务ID加上0x40。也就是说0x10服务的正响应SID是0x50。比如50 01 00 19 01 F4这表示ECU同意你进入默认会话后面跟的是P2定时器参数00 19即25ms和P2*定时器参数01 F4即500ms。这些参数用来告诉诊断仪ECU处理普通请求需要多长时间、处理特殊请求比如刷写时的擦除操作需要多长时间。负响应则是固定格式0x7F开头紧跟请求的服务ID最后是NRC负响应码7F 10 22这条意思是你请求了0x10服务但ECU回了NRC 0x22条件不正确conditionsNotCorrect。负响应的格式一定要背下来后面所有排查都离不开它。一个特别容易让新人蒙圈的坑是服务ID 0x22是“读取数据”而NRC 0x22是“条件不正确”。两者长得一模一样只是在报文里出现的位置不同。我第一次看报文时也卡了半天怎么“7F 22 22”前半段是个服务后半段是个错误码实际上前半段是“你请求的SID”后半段是“我拒绝你的原因”。记清楚这个后面读日志就顺了。2.2 子功能与0x80抑制正响应位UDS里很多服务都带子功能因为一个服务名字可能涵盖多种操作。最典型的就是0x19“读取DTC信息”它有十几种子功能按状态掩码读DTC数量、读DTC列表、读快照、读扩展数据……如果不带子功能ECU根本不知道你到底要干什么。子功能在请求字节里占用第二个位置例如19 02 FF0x19是服务ID0x02是子功能“按状态掩码读取DTC列表”0xFF是DTC状态掩码。这个请求的意思是把ECU里所有状态的DTC列表都读出来。还有一个很关键的设计子功能字节的最高位是抑制正响应位Suppress Positive ResponseSPR。如果这个位被置1ECU只执行命令但不回正响应。举例来说请求进入扩展会话10 83 // 0x83 0x03 | 0x80ECU会切到扩展会话但不会回0x50响应。这个机制常用于周期性的TesterPresent0x3E保活报文——我一直发你一直不回复省得总线上全是确认帧网络负担小很多。新手容易踩的坑是把0x80当成子功能码的一部分来解析结果对不上文档。记住0x80在子功能字节里是掩码位不是普通数据。换算子功能实际值时把最高位清零再看。2.3 物理寻址vs功能寻址UDS报文跑在CAN总线上时还有一个寻址概念要分清物理寻址和功能寻址。物理寻址就是一对一。诊断仪发一个请求指定发给某个ECU只有这个ECU会响应。比如OBD标准里的诊断请求ID通常是0x7E0对应的响应ID是0x7E8一个ECU一个ID。功能寻址则是一对多。诊断仪发一条广播请求总线上所有支持该服务的ECU都会收到。OBD标准里常见的功能寻址请求ID是0x7DF所有ECU都会接收。这种模式适合产线统一检查或者售后快速扫描哪些ECU在线。这里有个实践教训功能寻址的请求ECU通常不回正响应避免多个ECU同时回帧导致总线冲突。你如果拿功能寻址发了0x22去读数据大概率是收不到响应的——不是ECU坏了是你用错了寻址方式。另外0x10会话切换、0x11复位这类会改变ECU状态的服务不要用功能寻址去发否则整车一堆ECU同时复位够你喝一壶的。具体项目里怎么配置请求ID和响应ID完全看ECU的诊断规范。同一平台不同ECUID可能不同所以做测试之前一定要先拿到DBC文件和诊断调查表。3. 必会的核心服务逐个拆解3.1 0x10诊断会话控制ECU平时跑在“默认会话”Default Session里这个会话下很多诊断操作是不允许的。你需要切到“扩展会话”Extended Session或“编程会话”Programming Session才能执行写数据、刷写、例程控制等操作。这就是0x10服务干的事。常见的子功能子功能含义典型用途0x01默认会话DefaultECU上电后的默认模式危险操作都被禁止0x02编程会话ProgrammingBootloader刷写0x03扩展会话Extended标定、写DID、执行例程等维修诊断报文例子请求: 10 03 正响应: 50 03 00 32 01 F40x0032换算一下是50ms这是P2定时器0x01F4是500ms这是P2*定时器。含义是ECU在扩展会话下普通请求会在50ms内响应处理耗时操作时最长允许500ms再长时间就要回0x78挂起。这里有个重要细节会话是有超时机制的。ECU内部有个S3定时器一般5秒。如果5秒内没有收到诊断请求ECU会自动退回默认会话。所以诊断仪必须在S3超时前周期发送0x3E TesterPresent保活不然说着说着话ECU就“翻脸不认人”了。3.2 0x22/0x2E读写DIDDID是数据标识符Data Identifier可以理解成一个“寄存器编号”。每个DID对应一组数据可能是版本号、VIN码、硬件序列号也可能是传感器校准值。0x22按DID读取数据0x2E按DID写入数据。这是日常诊断中用得最频繁的服务。读取VIN码的例子请求: 22 F1 90 正响应: 62 F1 90 43 41 4E 31 32 33 34 35 36 37 38 39 30 31 32 33正响应的SID是0x62接着回显DID 0xF190后面就是VIN码的ASCII字符串。0xF190是OEM规范里常见的VIN DID但实际以项目诊断表为准不同OEM可能不一样。写DID的格式类似请求: 2E F1 90 43 41 4E 31 32 33 34 35 36 37 38 39 30 31 32 33 正响应: 6E F1 90写入操作通常要满足两个前置条件第一当前会话允许写通常得先切到扩展会话第二很多关键DID需要先过安全访问0x27否则直接回7F 2E 33安全访问被拒绝。实操中我建议新人先把0x22玩熟因为它最简单、最容易验证链路通不通。拿到一个ECU先发10 03再发22读几个关键DID能正常回说明底层通信、寻址、会话管理都是通的再碰复杂的服务。3.3 0x27安全访问与0x3E保持连接安全访问机制说白了就是一把锁。很多关键诊断操作比如刷写、写标定数据、执行特殊例程必须先“解锁”。解锁过程是一个挑战-应答流程诊断仪请求种子Seed27 01ECU回种子67 01 12 34后面的12 34就是种子数据诊断仪用内部算法对种子计算后得到密钥Key发送27 02 13 35ECU校验通过回67 02表示解锁成功这里计算密钥的算法是厂商保密的实际项目中由诊断仪供应商集成。作为测试人员你通常不用关心怎么算但要知道整个流程的状态。安全访问有几个敏感点种子是按访问级别分的。级别01/02是一级03/04可能对应更高权限05/06又是另一级。不同级别对应不同操作。连续失败会触发失败计数器锁定ECU会回NRC 0x36超过尝试次数或者0x37延时未到。触发后你短时间怎么试都没用只能等延时结束。安全访问通常在扩展会话下做默认会话直接请求种子大概率被拒。0x3E TesterPresent虽然不显眼但在整个诊断流程中相当重要。它的作用是告诉ECU“我还活着”防止S3超时。正常周期是2~3秒一次。每次请求就是请求: 3E 00 正响应: 7E 00如果不带抑制位ECU会回正响应也能顺便验证链路还在不在。如果带0x80抑制位只发不答适合长时间占用会话时降低总线负载。3.4 0x19读DTC与0x14清DTCDTC是故障码Diagnostic Trouble Code比如发动机失火、传感器对地短路、电压过高ECU会把故障记下来方便维修人员定位问题。0x19服务就是负责把这些故障码读出来的。0x19是整个UDS里最复杂的服务之一子功能非常多。我挑几个高频的0x01按状态掩码读取DTC数量比如先看有几个已确认故障0x02按状态掩码读取DTC列表项目里最常见的请求之一0x04读取DTC快照记录冻结帧记录故障发生时的环境数据0x06读取DTC扩展数据比如故障发生次数0x0A读取所有支持的DTC就是ECU有能力报哪些故障以最常见的19 02 FF为例正响应大致长这样59 02 FF 01 02 03 28 02 03 04 08 03 04 05 00其中59是正响应SID第二个字节0x02对应子功能0xFF是状态掩码可用性标识再往后就是一条条DTC记录。每条DTC记录通常是4字节3字节DTC编码 1字节状态码。这里我举例用的DTC编码是演示格式实际ECU用的是OEM自定义编码还是ISO 15031-6标准格式要看具体项目的诊断规范。清除DTC用0x14服务请求: 14 FF FF FF 正响应: 54请求里的三个字节是DTC分组掩码FF FF FF表示清除所有组的DTC。清码操作通常要求先进入扩展会话如果ECU配置了安全访问还得先解锁否则会回7F 14 22或7F 14 33。3.5 0x31例程控制和0x2F输入输出控制0x31例程控制RoutineControl是一种“让ECU干一件事”的服务。它跟读写DID不同它触发的是一个动作比如启动自检、擦除Flash、计算校验和、清除学习值。例程通过RIDRoutine Identifier来区分。子功能有三种0x01启动例程0x02停止例程0x03查询例程运行结果举个例子启动一个标识为0x0201的例程请求: 31 01 02 01 正响应: 71 01 02 01 00这里的最后一个字节00表示例程执行成功。如果例程返回非零值一般就是有错误。0x2F输入输出控制InputOutputControlByIdentifier则多用于功能测试。比如你想控制某个执行器动作或者强制某个传感器信号值就用这个服务。它的请求格式是服务ID 子功能/参数 DID 控制参数。以控制某个DID 0x1234的引脚输出高电平为例不同OEM格式差异较大但大方向是请求: 2F 12 34 01 正响应: 6F 12 34 010x2F是DID和具体控制模式非常依赖ECU的具体实现。新手用之前一定要先查诊断表别自己猜参数。0x2F操作可能会影响车辆行为测试时注意不要误动作导致安全问题。4. 实操用19 02 FF一步步读懂诊断信息4.1 一条请求从发送到响应的完整流程前面把服务都过了一遍现在拿最热的19 02 FF来一次完整实战演示。假设我们在CANoe上对一个ECU发送请求发送: 19 02 FF这条请求在CAN上走到ECUECU解析后做三件事先确认0x19服务是否支持、再确认0x02子功能是否支持、最后按状态掩码FF过滤出所有DTC。处理完回一条响应。响应我见过的大致格式如下示例数据59 02 FF 01 02 03 28 02 03 04 08 03 04 05 00第一段59 02 FF里59是正响应SID02是子功能回显FF是DTC状态掩码的可用性标识表示ECU支持所有8个状态位。接下来的每一条都是“DTC编码3字节 状态1字节”的记录。4.2 状态掩码怎么计算新手拿到状态字节比如0x28往往一头雾水。其实只要把状态字节展开成二进制就能看明白了。DTC状态字节共8个bit每一位对应一种状态位掩码值含义bit00x01testFailed测试失败bit10x02testFailedThisOperationCycle本循环测试失败bit20x04pendingDTC待确认故障bit30x08confirmedDTC已确认故障bit40x10testNotCompletedSinceLastClear上次清码后未完成测试bit50x20testFailedSinceLastClear上次清码后测试失败bit60x40testNotCompletedThisOperationCycle本循环未完成测试bit70x80warningIndicatorRequested点亮了故障灯0x28 0x08 0x20表示这是一个“已确认故障”且“自上次清码后测试失败过”的DTC。0x08单独出现通常就是已确认但还没再次复现的故障。0x00则代表这个DTC记录当前没有任何状态位置1常见于“曾经支持但当前不活跃”的记录。如果请求时只想读“已确认故障”状态掩码就填0x08想读“已确认 待确认”就填0x08 | 0x04 0x0C想全部读就填FF。计算方式就是按bit把需要的状态位OR起来这是19服务请求里最常用的操作。4.3 响应数据的解析思路拿到一条19 02响应时正确的解析顺序是先看第一个字节确认是59正响应。看第二个字节确认是02子功能。看第三个字节确认状态掩码可用性。从第四个字节开始按“4字节一组”拆分DTC记录。每条记录里前3字节是DTC编码查诊断调查表得到具体故障含义最后1字节是状态按上面的位表展开分析。我用上面那条示例数据再走一遍01 02 03 28 DTC编码 01 02 03状态 0x28 已确认故障 上次清码后测试失败之前我在实际项目里见到一位同事解析响应时没有把DTC按4字节分组直接把一整串数据按ASCII去解码结果当然是一团乱。记住0x19 02的响应里前面有回显和掩码后面才是固定长度的记录别把回显部分当成DTC数据。还有一点要提醒19服务如果读出来的DTC特别多响应可能超过单帧长度CAN TP会拆成多帧传输。你在应用层看是一条完整消息在CAN层看是好几帧这很正常不需要额外处理。5. 刷写Bootloader流程详解5.1 为什么刷写是UDS最复杂的应用场景刷写ECU固件也就是常说的“编程”是UDS所有服务中流程最长、涉及服务最多、最容易出问题的一个场景。它把前面讲过的会话切换、安全访问、读写DID、例程控制、传输数据全部串起来了。一次标准刷写通常涉及这些服务0x10、0x85、0x27、0x22/0x2E、0x31、0x34、0x36、0x37、0x11、0x14。所以你如果能把一次刷写流程完整跑通并且能讲清楚每一步在做什么基本就可以说UDS入门了。为什么刷写流程要搞这么复杂原因也很现实一个ECU的Flash里存着Bootloader和应用程序。刷写过程中一旦中途断电、数据写错、时序不对ECU可能变砖。每多一道检查、每多一步验证都是在给“万一出问题”兜底。5.2 一次完整刷写的步骤我把通用的一次刷写步骤列出来每个步骤都解释一下目的进入扩展会话或编程会话请求10 03或10 02让ECU打开编程相关权限。关闭DTC记录功能请求85 02防止烧录过程中ECU因为通信中断等原因误报一堆故障码。安全访问请求27 01获取种子计算密钥后请求27 02解锁拿到刷写权限。写入指纹信息通过2E写DID记录刷写时间、刷写原因、刷写工具等信息便于追溯。检查前置条件通过31 01启动一个检查例程例如检查电压是否足够、点火状态是否满足。请求下载请求34告诉ECU我要往哪个地址写数据、写多长。传输数据循环请求36把固件数据按块发送给ECU。请求传输结束请求37告诉ECU数据发完了。验证程序完整性通过31 01执行Flash校验例程确保写入的数据是正确的。复位ECU请求11 01让ECU重启并运行新程序。清除DTC请求14 FF FF FF把刷写过程中产生的临时故障码清掉。刷写完成后如果是Bootloader程序还需要回到应用程序区确认版本号通常会用0x22读取软件版本DID确认刷进去的版本是预期的那个。5.3 刷写过程的细节与保护刷写过程中有很多细节稍不注意就出事。我挑几个重要的说第一块序列计数器。0x36传输数据时每次请求都要带一个块序列计数器从0x01开始递增。ECU用这个计数来确保数据按顺序到达、没有丢块。如果你重复发了同一块ECU可能直接回NRC 0x73错误块序列计数器。用CANoe脚本刷写时计数器务必在循环里正确累加。第二0x34请求下载的参数计算。请求下载时要指定地址和长度格式比如34 00 44 10 00 20 00 00 40 00这里的0x44表示内存地址占4字节、数据长度占4字节10 00 20 00是起始地址00 00 40 00是要写的数据长度。如果地址长度格式算错ECU根本不知道你想干嘛直接回NRC 0x31。第三擦除时间可能很长。ECU在擦除Flash期间可能无法及时响应新请求如果超时诊断仪不要立马判定ECU坏了先看它有没有回0x78ResponsePending占位响应。0x78的含义是“请求收到我正在处理再等等”。诊断仪收到0x78后要重置超时定时器继续等最终响应。第四刷写过程中不要频繁开关诊断仪或拔总线。回过一次NRC 0x24请求序列错误后ECU会认为整个刷写流程作废新的传输请求会被直接拒掉只能重新从头来过。考虑到刷写过程中涉及大量数据一旦出错代价高建议实际项目里先在台架上用模拟ECU或真实ECU把整个流程调通再上车操作。别一上来就刷整车血的教训不少。6. 常见NRC分析与排查思路6.1 NRC的基础知识NRC全称Negative Response Code是ECU回复“我拒绝你”时携带的原因码。负响应报文格式7F [请求的SID] [NRC]比如你发0x22读取数据ECU回到7F 22 31意思就是“22服务我不接受原因是0x31请求超出范围”。NRC是单字节0x00~0xFF常用的就那么几十个。我把项目里高频出现的NRC整理成一个速查表新人可以收藏NRC名称常见原因0x11serviceNotSupported服务ID不支持可能ECU没实现该服务0x12subFunctionNotSupported子功能不支持比如19服务里01支持、02不支持0x13incorrectMessageLengthOrInvalidFormat报文长度或格式不对参数多一个少一个0x22conditionsNotCorrect条件不满足比如当前会话下不能执行该操作0x24requestSequenceError请求顺序不对常见于刷写流程乱序0x31requestOutOfRange请求超范围比如DID或数据地址不在支持列表里0x33securityAccessDenied安全访问被拒绝没解锁就想干需要权限的事0x35invalidKey密钥错误种子计算不对0x36exceedNumberOfAttempts超过尝试次数安全访问被临时锁死0x37requiredTimeDelayNotExpired需等待延时安全访问锁定还没解除0x72generalProgrammingFailure编程失败Flash写入异常0x73wrongBlockSequenceCounter块序列计数器错误0x78requestCorrectlyReceived-ResponsePending已收到请求正在处理稍后回最终响应0x7EsubFunctionNotSupportedInActiveSession当前会话不支持该子功能0x7FserviceNotSupportedInActiveSession当前会话不支持该服务两个0x7开头的NRC特别容易让新人懵它们是“服务本身ECU支持但当前会话不支持”。比如默认会话下发0x2E写DIDECU可能回0x7F而不是0x11。看到0x7F先想想是不是没切会话。6.2 高频问题与排查手段我按实际项目里经常遇到的场景把排查思路写一下场景一发10 02切编程会话回7F 10 22。这种情况通常是ECU不允许从默认会话直接切编程会话需要先切扩展会话再切编程会话。有些ECU还会在车速、电压等条件不满足时拒绝切换查一下前置条件。场景二发27 01请求种子完全没响应。先检查寻址对不对是不是用了功能寻址再检查当前会话是不是扩展会话最后检查是不是ECU本身没配置安全访问。场景三发22读DID回7F 22 31。这说明DID不在支持范围或者报文长度不对。拿诊断调查表核对一下很多OEM的DID是分会话支持默认会话只支持很小一部分。场景四刷写过程中36回7F 36 73。先看块序列计数器是不是从1开始并且连续递增再看是不是之前某块发送失败ECU已经终止了整个下载流程。场景五发14清DTC回7F 14 22。一般就是会话不对默认会话下不让清码。切到扩展会话再试如果还不行看安全访问有没有解锁。排查NRC问题有一个通用套路先把请求报文逐字节写出来确认SID、子功能、参数长度都对再确认当前会话状态再确认安全访问状态最后才怀疑ECU本身的软件逻辑。大多数问题都出在前三步。6.3 建议的工具和工作流做UDS测试我建议至少准备两样工具一个能抓CAN总线的硬件USB-CAN卡或者CANoe一个能解析UDS的上位机工具。CANoe的Diagnostic Console可以直接发UDS请求也能加载诊断DLLOEM或供应商提供的协议封装方便自动化测试。没有CANoe的话用PCAN、ZLG等设备配合Python的python-can库也能完成基本请求发送成本低很多适合学习。如果只是入门验证可以先不追求专业工具。用python-can自己拼一个最简单的请求发到ECU上把响应的字节打出来对照标准自己解析。这个过程虽然原始但对理解报文结构的帮助是巨大的比直接在CANoe里点按钮要深刻得多。7. 给新手的几条学习建议7.1 学习路线怎么排很多人一上来就抱着ISO 14229原文啃啃两天就放弃了标准文本太干全是抽象定义。我的建议是反着来先动手再读规范。第一步找一块带CAN的板子或者哪怕用模拟软件先发一个10 01、10 03、22读DID、19 02 FF把正负响应的手感找出来。第二步遇到不懂的字段再翻标准对应章节。第三步尝试自己写一个简单的脚本完成“切会话-安全访问-读DID-读DTC”的完整链路。第四步再碰刷写。这样一步步来比从头到尾读标准高效得多。7.2 阅读ISO 14229的重点章节ISO 14229-1的核心是第三部分到第五部分也就是服务定义、DTC格式和时序要求、以及数据标识符组织方式。刚入门不用全看先看0x10、0x22、0x19、0x27这几个服务相关的章节再补充0x34到0x37刷写相关章节。后面要碰DoIP再看ISO 13400碰LIN再看LIN诊断规范不要一口吃个胖子。另外强烈建议结合项目里的诊断调查表Diagnostic Survey一起看。调查表里才是真正定义了某个ECU支持哪些服务、哪些DID、哪些DTC、哪些安全级别。标准是通用规则调查表是具体语言两个搭配着用有效信息量翻倍。7.3 一个很实用的小技巧最后分享一个小技巧遇到不懂的负响应别急着查手册先把NRC按十六进制展开成二进制看一遍再对照状态位表分析。别小看这个习惯很多“奇怪的问题”其实只是状态字节里某一位的含义没对上展开成二进制一眼就看明白了。我在实际做项目时还有一个习惯把所有诊断交互都用脚本记录下来包括请求、响应、时间戳不管有没有报错都留档。出问题的时候翻历史日志比现场复现容易得多特别是那些概率性出现、时好时坏的NRC问题历史日志往往能帮你快速锁定规律。UDS的学习没有捷径但多做一步记录能让你少走很多弯路。