UDS从入门到实践：CAN总线诊断协议核心解析-北京尧图网络

如果你在车载电子行业待过一阵子不管是做ECU软件开发、测试验证还是产线下线诊断迟早都会撞上UDS这个词。UDS全称是Unified Diagnostic Services统一诊断服务几乎成了现代汽车诊断的事实标准。刚接触的人最容易懵的不是服务的名字而是“为什么一个诊断协议要设计得这么啰嗦”——又是会话又是安全等级又是负响应码。这篇文章就是写给刚入门的朋友看的帮你在脑子里把UDS的骨架搭起来知道它到底解决什么问题、报文长什么样、排查问题从哪儿下手。我自己属于典型的“先踩坑后补课”类型。最早接触UDS是在某款ECU的刷写功能联调现场上位机发了10 03ECU一直不回50 03当时连功能寻址和物理寻址都没分清盯着CAN报文看了半天也没看出门道。后来把ISO 14229系列标准翻开配合抓包工具一帧一帧地看才把整个逻辑串通。现在回头看UDS入门其实就三层东西需要理解透协议的分层思想、核心服务的请求响应模式、以及状态管理带来的时序约束。这篇文章尽量用白话把这三点讲清楚不需要你有深厚的CAN协议基础只要知道CAN报文是啥帧、带ID和数据场就能跟上。1. 为什么车辆诊断绕不开UDS一个面向“功能”而非“寄存器”的协议早期诊断协议如KWP2000做事方式偏向底层很多操作直接跟ECU内部的寄存器、内存地址挂钩。问题在于不同ECU的内存布局完全不同诊断仪到了不同车上就得重新适配。而UDS换了个思路它不关心你内部怎么实现只定义“功能”层面的接口。你要读车速就发一条“读数据”服务附带一个数据标识符你要清故障码就发一条“清DTC”服务。至于这个数据标识符背后查的是哪块内存、清DTC时是写哪个Flash区域那是ECU软件的事UDS不管。这层抽象让OEM和供应商之间的联调变得干净许多。还有一个背景也决定了UDS的设计思路一个控制器局域网CAN里挂着几十个ECU诊断仪通过总线跟它们对话不能像串口点对点那样随心所欲。总线是广播式的一帧报文发出去所有节点都能收到。所以UDS必须解决“怎么让该响应的ECU响应、不该响应的ECU保持沉默”的问题于是有了物理寻址和功能寻址的区分。前者是点对点只发给一个特定的ECU后者是广播发给总线上所有支持该服务的ECU。UDS还引入了**会话Session**的概念相当于ECU的一个工作状态机。不是你想读什么就读什么、想改什么就改什么得先进入对应的会话。比如默认会话下只能做基本读取要刷写程序得切到扩展会话或编程会话。这个设计看着啰嗦但很实用——ECU在正常运行时要保证控制功能实时可靠不能因为总线上有人发一帧“写内存”就把刹车逻辑打断了。通过会话隔离ECU可以明确什么时间段允许什么样的诊断干预。对新人来说理解UDS最关键的一步不是死记服务ID而是先建立这个框架请求-响应的对话模型会话和子功能约束权限NRC表达拒绝理由。有了这三根柱子后面所有服务理解起来就是套公式。2. 从CAN报文到UDS服务之间隔着一层ISO-TP协议你直接抓CAN总线看到的是一帧帧带仲裁ID和数据场的报文。但UDS服务不是一个报文对应一个服务这么简单。像31 01 02 03这种例程控制请求数据才四五个字节CAN标准帧也能塞得下可遇到刷写时的36 01 ...传输数据一包动不动二十几个字节CAN标准帧8个字节的数据场根本装不下。这时候就需要一个“拆包重组”的机制这就是ISO-TPISO 15765-2干的事。2.1 单帧、多帧和流控UDS数据是怎么塞进CAN帧里的ISO-TP的四种帧类型入门阶段记住前三个就够用单帧SF、首帧FC实际上我们常说的首帧是FFFirst Frame流控帧是FCFlow Control首帧缩写FF流控缩写FC这块不要记混、连续帧CF。单帧用在数据总长度不超过7字节标准CAN或64字节CAN FD时PCI字节最高位为0低4位表示数据长度。比如CAN标准帧下收到10 03这条UDS请求CAN数据场实际是02 10 03那个02就是单帧PCI意思是我后面有2个字节的UDS数据。数据一长就要发首帧。首帧PCI最高位为1后面12位表示总长度比如收到的首帧数据场是10 14 50 01 00 00 7F 22 ...10代表这是首帧014十六进制换算成十进制是20说明后面跟的UDS数据一共20个字节。首帧里已经带了前6个字节的数据剩下的拆成连续帧一包一包发。连续帧PCI最高位为2后面的4位是帧序号从1开始循环。这里有个新手必踩的坑流控帧FC是接收方发的不是发送方发的。发送方发完首帧后必须等接收方回一个流控帧里面带三个参数流控状态通常为0表示继续发、块大小BS、最小间隔时间STmin。很多人刚抓包时看到发出首帧后来了一个30 00 00以为是对方发来的数据其实那是对方在说“我准备好了你继续发连续帧吧”。你不理解流控机制刷写时偶尔丢包就会一脸懵。用数据量来体会一下同样的60字节UDS数据标准CAN帧要拆成1个首帧加9个连续帧CAN FD一帧就能搞定。这也是为什么刷写应用越来越倾向CAN FD。2.2 远程帧和寻址格式诊断ID不是随便配的UDS在CAN上还定义了诊断请求ID和诊断响应ID。物理寻址时请求ID和响应ID是一一对应的通常响应ID 请求ID 8很多OEM这样分配功能寻址时所有ECU共用一个功能请求ID但每个ECU用自己的响应ID回复。不同OEM的ID分配表千差万别有的用29位扩展帧有的用11位标准帧入门阶段不必死记具体值但要记住抓包看到同一帧数据却不知道是谁回的八成是没搞懂ID分配方式。这也是为什么原厂诊断仪软件里总有车型配置里面大部分内容就是一堆ID映射和地址信息。还有一个概念叫寻址模式N_AI包括物理寻址、功能寻址以及带源地址和目的地址的扩展寻址。在CAN上常见的是普通寻址和扩展寻址。扩展寻址在数据场里多一个字节表示目的地址总线上所有ECU都收这帧但只有目的地址匹配的才会响应。这种模式在某些OEM的私有诊断中很常见做网关测试时会遇到知道有这回事就行。2.3 为什么要靠报文抓取来学UDS我强烈建议入门阶段别只在文档里看协议一定要配一个USB-CAN工具加一个抓包软件对着真车或者仿真ECU看报文。UDS在总线上跑起来后你能看到完整的请求、响应、流控时序。比如你发一个22 F1 90读VIN看CAN报文数据场是怎么从03 22 F1 90变成06 62 F1 90 31 32 33 34的这种直观印象比背一百遍PCI格式都管用。后面讲到的所有例子都建议你在抓包工具里亲手过一遍。3. 核心服务逐个拆解请求、响应、NRC是怎么配合的UDS的服务ID定义在ISO 14229里常用的其实就那么十几个。我按使用频率和逻辑关系分成四组讲每组都给实际请求响应示例。记住UDS的通用规则请求服务后ECU要么回肯定响应服务ID 0x40要么回负响应0x7F 服务ID NRC没有第三种情况。3.1 会话控制和安全访问权限管理的地基10服务DiagnosticSessionControl用于切换会话。请求格式是10 子功能子功能01是默认会话02是编程会话03是扩展会话。比如发10 03ECU回50 03 00 32 01 F4其中50 03是肯定响应后面跟着的是P2Server和P2*Server的计时参数单位毫秒分别表示“正常响应时间”和“增强响应时间”。可别小看这两个参数后面做测试时超时时间的设置全得靠它们。27服务SecurityAccess用于解锁受保护的功能。流程是请求种子27 01ECU回种子67 01 1A 2B然后计算密钥发27 02加密钥ECU回67 02表示解锁成功。这个种子密钥算法由OEM自己定有简单的加解密规则也有复杂的对称加密。做刷写工具开发时算法往往是OEM给的一个库你只管调用。踩坑点是安全访问有失败次数限制连续错几次后ECU会锁住一段时间测试时手速太快就会把自己锁外面等好几秒才能再试。这两个服务是所有刷写类、标定类功能的前置条件不理解会话状态机后面刷写出问题你连错在哪都不知道。3.2 读取和写入数据DID是访问ECU数据的钥匙22服务ReadDataByIdentifier按DID读数据。DID是16位的比如F190通常表示VIN。请求22 F1 90响应62 F1 90 31 32 33 34 ...后面跟的就是VIN的ASCII码。这个服务做得好的地方在于ECU可以定义几百个DID每个对应一组参数诊断仪不需要知道内存地址只知道DID编号就行。2E服务WriteDataByIdentifier往DID写数据。比如写VIN2E F1 90 31 32 33 34 35 36 37响应是6E F1 90。注意可写的DID和可读的DID往往不是同一批写操作通常要求在扩展会话或编程会话下有些还要先做安全解锁。写VIN这种操作一般发生在产线或者售后配置环节ECU内部会把数据放到专门的存储区甚至防篡改区。有个容易被忽略的细节DID的内容可以不是纯数据还可以是复合结构。比如一个DID包含版本号、校验和、配置字等多个字段按固定格式排列。做测试时要用OEM提供的DID表逐字节核对不能想当然地认为“DID就是单值”。3.3 例程控制和DTC做动作和查故障的路径31服务RoutineControl执行例程这是我最喜欢的一个服务因为它能干很多“动作型”的事情。格式是31 子功能例程ID 可选参数。子功能01启动例程02停止03查询结果。比如让ECU执行一个自检例程发31 01 02 01ECU回71 01 02 01表示已启动。例程控制功能的灵活性极高ECU软件可以把压缩、擦除、校验、自检等等动作全包成例程诊断仪只负责调用。这一点在刷写流程里用得特别多。19服务ReadDTCInformation读故障码14服务ClearDiagnosticInformation清故障码。DTC是3字节的比如C00100可能表示某个控制器故障。为什么是3字节因为DTC格式继承了OBD-II体系的规则通过ISO 14229又统一了。19服务有好多子功能01按状态掩码读DTC数量02按状态掩码读DTC列表04读快照06读扩展数据……很多新手分不清最简单的方法是先记19 02就是“读出所有当前故障码”响应里会有一串DTC列表和状态字节。DTC状态字节是位编码的每一位代表一种状态当前存在、历史出现、已确认、测试失败等这也是诊断协议里比较麻烦但必须搞懂的部分。3.4 上下载数据刷写链路的三个关键服务34RequestDownload、36TransferData、37RequestTransferExit这三个服务组合起来就是刷写数据的核心通道。34请求下载格式是34 数据格式地址长度内存大小长度地址大小ECU回74 块长度告诉对方一次能收多少个字节。36传输数据格式是36 块序号数据每包数据大小受ISO-TP和ECU接收缓冲区限制。37退出传输表示数据都发完了。这套协议体现了UDS的设计哲学把“传输会话”这样一个底层操作包装成上层服务让OEM可以在传输前后插入校验、擦除等流程。4. 把一次刷写流程串起来看服务间如何配合光挨个看服务很难体会协议设计的精妙之处。我把ECU刷写全流程串一遍你就知道会话、安全、上下载服务是怎么咬合的。这是一条非常典型的刷写时序来源是我在某次量产工具联调中的实际操作流程。4.1 从默认会话到编程会话权限逐步打开刷写开始前ECU跑在默认会话。第一步发10 02进入编程会话Programming SessionECU回50 02同时会停掉一些非必要的通信和功能。有些ECU不直接在默认会话响应10 02而是需要先10 03进扩展会话再10 02进编程会话这取决于OEM的状态机设计。这里有一个通用原则进编程会话前先停应用通信。常用做法是发28 03CommunicationControl关闭应用报文防止刷写过程中ECU还在往外发周期报文干扰总线。这一步不做总线负载率会异常刷写时序容易出问题。进入编程会话后先擦除Flash。擦除一般用31 01 02 01启动一个擦除例程或者用34请求下载到Flash地址后由ECU内部处理。擦除例程的特点是响应慢可能几十秒这时候P2*Server计时参数就派上用场了——ECU在慢响应时会先回7F 31 7878代表“响应待定”告诉诊断仪“我正在忙别急”。测试工具收到78后就要用增强超时时间等不能用普通超时否则会误判超时。4.2 安全解锁与数据搬运权限校验与传输时序Flash擦完下一步是安全解锁。因为很多ECU要求下载数据前必须通过安全访问校验否则34请求会返回7F 34 33securityAccessDenied安全访问被拒。解锁流程就是前面说的27 01取种子、算密钥、27 02发密钥。解锁成功后马上发34请求下载带上目标地址和数据长度。比如要往0x8000开始的区域写1KB数据请求就是34 00 44 10 00 00 04 00这里44表示地址和长度都是4字节。ECU回74 00 40意思是你每块最多给我0x40也就是64字节。这个块长度决定了后续36报文的数据载荷大小也直接受ISO-TP的帧类型影响——CAN标准帧下每包最多7字节UDS数据而ECU却允许块长度64字节就需要发送方自己拆成多个连续帧再组合。然后就是循环发36 01、36 02、36 03……每一块序号递增ECU每次回76 01表示该块已收到。有些ECU要求块与块之间必须等待响应有些允许流水线式地连续发取决于ECU实现。发完后发37退出传输ECU回77。到这一步数据只是写进了RAM或临时缓冲区还没真正固化到应用区。接下来通常是发31 01 FF 00启动校验例程ECU内部比对校验和比对通过后再复位。逻辑越严谨的OEM在这个阶段加的例程越多。4.3 复位与验证收尾阶段的关键动作最后发11 01ECUReset硬复位ECU回51 01然后重启。复位后重新进入扩展会话用22读版本号、用19读DTC确认刷写后的软件版本正确、没有新故障码整个刷写流程才算收尾。很多刷写工具“提示完成”其实只是把数据发完了真正刷成功要看到复位后ECU能正常通信、版本号对得上。把流程从头到尾走一遍你会发现UDS的每个服务都有明确的位置和不可替代的作用整个流程像流水线一样环环相扣。理解了刷写流程再回看各个服务的功能记忆就会非常牢固。我在带新人时都是让他们先把这个流程画出来再对着抓包报文一个一个找对应帧比背服务ID列表高效得多。5. 入门最容易踩的坑NRC、时序和会话状态网上讲UDS服务的文章很多但操作中真正的拦路虎往往不是服务格式而是这些看不见的规则。5.1 负响应码ECU拒绝你的真实原因NRC类型比较多初学掌握高频的几个就够用11服务不支持serviceNotSupported、12子功能不支持subFunctionNotSupported、13请求数据长度错误incorrectMessageLengthOrInvalidFormat、22条件不满足conditionsNotCorrect、31请求超出范围requestOutOfRange、33安全访问被拒securityAccessDenied、78响应待定responsePending。实际工作中遇到7F 22 31说明ECU认为你当前条件不满足比如没进编程会话、安全未解锁、或者请求的地址不可写。遇到7F 36 31八成是块序号没连续或者数据长度不对。排查NRC的通用方法很简单先看NRC是哪个类。11和12是功能层面的问题查服务ID和子功能是否拼错13是格式问题数一下请求用了几个字节跟OEM诊断规范对不对22、31、33是权限和状态问题先检查会话、安全等级、参数范围。记住这四类对应的检查路径能帮你节省大量抓包分析时间。5.2 时序参数别用错了P2和P2*每个会话都会定义P2Server和P2Server。P2是正常响应时间一般50msP2是增强响应时间一般5000ms。ECU处理慢动作时会先回7F xx 78这时测试工具的计时要从普通P2切到P2*。很多测试工具软件里都会有一个全局超时配置默认值不一定是目标ECU的值。我在某个项目里就遇到过上位机配置的超时仍是500ms而ECU擦除例程花了几秒钟工具每次都误报超时其实ECU早就回了7F 31 78在干活。后来把P2*设为5秒才正常。做测试前第一件事确认当前会话的P2和P2并把工具的超时参数设好*这事没啥技术含量但影响特别大。5.3 功能寻址的坑请求发了别等响应功能寻址是广播式的。比如用功能寻址发10 01切换到默认会话总线上多个ECU都会收到并执行但它们不会同时回响应。实际上ISO 14229规定功能寻址的请求ECU不应该回响应除非是某些特定服务和特殊情况。新手第一次测试功能寻址发完请求干等响应等不到还以为没发出去。实际上功能寻址请求发出去只要总线没报错就代表ECU收到了并执行了。验证是否执行用物理寻址读一下状态就行。还有一个易混淆点功能寻址下不要发需要响应的服务比如22读取、27安全访问这类。因为功能寻址是给所有ECU的如果两个ECU都回复总线就会冲突。标准做法是10、11、28、3E这类“广播命令型”服务用功能寻址读写类服务用物理寻址。5.4 会话超时与状态未复位ECU有会话超时机制。默认会话下如果一段时间通常几秒钟到几分钟取决于OEM没有收到任何诊断请求ECU会自动跳回默认会话。如果你在做一套半自动测试每步操作间隔较长前一步解锁了安全访问后一步要发34时发现NRC是33很可能是会话超时被重置了安全等级也一起丢了。解决方法是测长流程时周期性发3E 00TesterPresent保持会话活跃但注意3E要带子功能00有些OEM规范要求3E 00只保活不重置安全等级有的会重置要做区分。5.5 诊断仪和ECU的地址别搞反最后提一个低级但常见的坑诊断仪地址和ECU地址。UDS在CAN上传输时N_SA源地址和N_TA目标地址有严格定义。很多工具软件里配置地址时会把0x7E0/0x7E8这类ID当成“ECU地址”填错。实际上0x7E0这类ID属于诊断仪的请求ID0x7E8是ECU的响应ID跟ECU的节点地址如0x01、0x10不是一个概念。地址配置错了报文根本到不了ECU。看抓包时先分清哪些帧是请求帧、哪些是响应帧比急着看数据场重要得多。6. 没有真车也能上手搭建最小UDS实验环境的实操建议很多人觉得学UDS必须有实车或者控制器。其实不然现在模拟手段很成熟完全可以在电脑上跑通一条完整的UDS请求响应链路。6.1 硬件和基础软件选型参考最经济的组合是一块USB-CAN分析仪加一个CAN总线仿真环境。USB-CAN分析仪选市面上常见的即可这类工具基本都会配套上位机软件支持发送CAN帧、抓包、查看总线负载有些还内置了简单的UDS发送面板。如果你不想立刻买硬件也可以先用纯软件的虚拟CAN总线工具比如在PC上创建虚拟CAN通道再配合脚本模拟ECU行为。选择哪个取决于你是想练“发报文”还是想练“写ECU逻辑”。如果是车载ECU开发工程师建议直接用整车厂常用的商业总线仿真工具里面自带UDS模块和CAPL编程环境可以建一个模拟ECU实现会话切换、DID读写、例程响应等逻辑然后让诊断仪来连。这套环境的优势是高度接近真实工程环境缺点是要有授权成本高。学生或自学入门用开源方案就行Python配合CAN收发库自己写一个最简ECU模拟器处理10、22、2E、27、31等几个核心服务用诊断工具发请求验证响应。这个方案能让你把协议细节吃透因为每个响应都是你自己写的。6.2 建议按这个顺序做实验先做会话切换实验发10 01回50 01发10 03回50 03观察默认会话和扩展会话下同一服务的响应差异。再做DID读写实验定义几个DID比如F190存一串ASCII字符串试试写进去再读出来体会数据格式和长度。然后做NRC触发实验故意发错误子功能、错误长度观察ECU回的NRC类型把高频NRC都触发一遍。接着做安全访问实验在模拟ECU里实现一个种子算法尝试解锁成功和失败两种路径看看连续失败后的锁定期。最后做一次完整刷写流程模拟不需要真的操作Flash在RAM里模拟一块区域走完34、36、37、31校验、11复位全流程打印日志验证。每个实验做完都把抓包报文存下来对照协议标准逐帧分析。我摸索下来的体会是看懂五帧报文比浏览五十页标准有用前提是你确实知道怎么逐字节拆解这五帧。做实验时也顺便练练19和14服务模拟ECU里设置几个DTC状态用诊断仪读故障码、清故障码摸清楚DTC状态字节的状态位都是在什么条件下变的。6.3 买不到真车用仿真ECU方案如果你能拿到OEM的诊断规范文档按照文档描述建一个仿真ECU比如支持哪些DID、每个DID的读写属性、各服务的子功能列表、会话状态机、NRC返回逻辑做成一份配置文件然后用脚本自动生成诊断响应。这种做法在开发诊断仪工具时极其常见本质上就是一套“诊断真值表”。把它跑起来之后不但能验证工具逻辑还能用来培训新同事熟悉UDS流程。我的经验是这个仿真器写的越细你对规范的把握就越深很多OEM规范里写得不清楚的地方在写仿真逻辑时会被逼着去确认。从入门到能干活缺的只是“多看报文”这一件事如果你问我UDS入门最核心的一条建议是什么我的答案不是“背熟服务ID”也不是“读完整本ISO 14229”而是把抓包工具用好一帧一帧地看请求和响应之间的关系。UDS的响应格式有规律可循但每个OEM的具体实现差异很大不抓包光靠标准很容易被现实打脸。最后分享一个个人习惯我会在电脑里长期保留一批典型报文记录文件包括每一次刷写流程、每次安全访问交互、每个NRC触发的完整抓包数据。遇到新项目时先翻旧报文回忆一遍流程很多时候能少走弯路。做UDS相关开发很多时候拼的不是智力是你积累了多少能够“对得上号”的报文场景。把这批素材攒起来你会发现自己对UDS的理解已经远超“入门”了。

UDS从入门到实践：CAN总线诊断协议核心解析

相关推荐

机器学习入门核心概念：特征、模型与过拟合一次讲清

2026降AI率工具横测：十大技术路线谁在治本谁在治标

STM32驱动5011AS共阴数码管：从GPIO直驱到段码表显示实战

更多资讯

第一次小考全流程拆解：出题、评分、监考与复盘一次讲透

Spring Boot 容器镜像：Windows 构建到 Linux 运行全记录

企业微信 API 接口：微信客服消息接收与自动回复

拼多多客服机器人接入实战：对话中台工程化落地指南

Skill开发避坑指南：如何让技能扛住用户的一百种说法

软考高项案例分析：成本管理与挣值计算公式详解

今日更新

智能硬件视频会议集成：从芯片选型到场景落地的全栈实践

FFmpeg音视频处理与5路RTMP推流实战：从原理到118克盒子部署

RK3528+1GB内存如何变身直播节点？硬编解码与六协议实战复盘

本周精选

金融AI落地指南：从调研报告到技术选型与工程实践

大模型上下文成本与注意力优化技术深度解析——为何O(n²)平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测

基于GMM的语音识别系统原理与MATLAB实现详解

本月热门

我发现了一个新思路：用 Remotion + Claude Code 像写代码一样自动化生成短视频

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式：TaoToken 统一 Key 配置与验证

2026 大模型集体涨价：用 Python 做企业 Token 成本测算与选型避坑（附配置）

读完文章，想聊聊您的网站？