• 🍅 我是蚂蚁小兵，专注于车载诊断领域，尤其擅长于对CANoe工具的使用
• 🍅 寻找组织 ，答疑解惑，摸鱼聊天，博客源码，点击加入👉【相亲相爱一家人】
• 🍅 玩转CANoe，博客目录大全，点击跳转👉

---

---

📙 UDS标准总览

• UDS（Unified Diagnostic Services，统一的诊断服务）诊断协议是在汽车电子ECU环境下的一种诊断通信协议，UDS的需求规范应该参考：ISO-14229-1中英文版本都有 ，下方公众号网盘地址自取
  

• UDS（统一的诊断服务）是建立在应用层的，“统一”这个词意味着它是一个“国际化的”而非”公司特定的”标准。且适用于所有车载总线的一个标准。

• 以下备注是各种总线传输层的协议标准

• 备注①：ISO15765-2,是CAN总线

• 备注②：ISO10681-2 ,是Flexray总线

• 备注③：ISO13400-2 ,是以太网总线

• 备注④：ISO 17987-2 ,是LIN总线

---

常用诊断服务

• UDS本质上是一系列服务的集合。UDS的服务包含6大类，共26种。每种服务都有自己独立的ID，即SID（Service Identifier，诊断服务ID）。下图是ISO-14229-1中定义的所有服务。其中红色圈起来的是我们常用的诊断服务SID

诊断服务的发送和响应格式

• UDS本质上是一种定向的通信，是一种交互协议（Request/Response），即诊断方(Tester)给ECU发送指定的请求数据（Request），然后ECU根据情况响应（Response）Tester.

• “请求”由Tester端发送给ECU，请求报文里带有SID，根据具体的服务内容后面加具体的数据。肯定响应格式由“SID+40+具体的数据”。否定响应格式是一个固定的格式“7F+请求报文里的SID+一个字节的NRC”，注意都是16进制数。

• NRC ：negative response code ，当ECU对Tester响应的负响应码

• 正响应,发送SID =0x10 ,正相应SID= 0x10 + 0x40 = 0x50

• 负响应 ，14229-1标准中定义了很多NRC,下图列出了一部分

发送SID=0x10,ECU给了NRC 0x11.

📙1 DiagnosticSessionControl (0x10) service

1.1 服务介绍

• 10服务一共有3个子服务，01 Default默认会话，02 Programming编程会话，03Extended扩展会话，ECU上电时，进入的是默认会话(Default)，当某一个服务端正在运行时，只会出现一个会话模式，不会同时存在两个会话模式。

• 默认会话：01 Default Session，支持信息的读取和查询操作，权限最小。

• 编程会话：02 Programming Session 顾名思义这个是用来烧录程序的

• 扩展会话：03 Extended Session，主要是用来读写数据，如写入VIN，序列号，读写诊断码等
  

上图是标准里的一张诊断会话模式切换图，里面包含接收到会话模式请求的四种情况，下面按标准内容进行解释。

1：在默认会话模式下收到默认会话模式请求：服务端应当重新初始化默认会话，即之前被临时激活或者改变的数据都应该恢复到刚上电初始化的状态，写入到非易失存储器（断电数据不会消失的存储器）的数据不会重新初始化。

2：在默认会话模式下收到任何非默认会话模式请求：服务端应当切换到被请求的会话模式。

3：在非默认会话模式下收到非默认会话模式请求：服务端完成会话模式切换的同时需要完成以下操作：

• 停止通过0x86服务设置的事件；
• 重新锁定安全访问状态，并且重置依赖于安全访问的服务；
• 不依赖于安全访问的服务，如果在被请求的会话模式也支持，应当保持当前状态，例如通信控制服务和DTC控制服务。

4：在非默认会话模式下收到默认会话模式请求：

• 服务端应当恢复之前被暂停的通过0x86服务设置的事件，
• 停止所有默认会话模式不支持的服务，包括 重新锁定安全访问状态，重置通信控制服务和DTC控制服务
• 其余需要执行的操作与第1条一样。

5：（补充）在非默认会话模式下如果没有发送3E服务，则S3time超时后，会话将回到默认会话模式

1.2 请求格式

1.2.1 正响应格式及Trace图例：

• 下图是 10服务的三种会话诊断Trace
  

1.2.1.1 重点参数解释：

• P2Server_max：从ECU接收完一帧完整的请求后，开启该定时器，且ECU应在该定时器定时时间内发送响应报文。如果在该定时器timeout前ECU就开始发送响应报文，那么该定时器在ECU开始发送响应报文的时候停止计时。
• P2*Server_max ： 若在ECU中支持了78NRC的机制，那么当ECU忙于处理其他的事情的时候，诊断仪发送了一条请求到ECU，此时ECU是没空对该请求做出响应的（并不意味着否定响应），因此由于78这个机制的存在，ECU会回一个78NRC的响应报文，告知诊断仪ECU现在处于忙碌状态，稍后回复你，这个回复的时间就由P2*时间决定。

1.2.2 负格式及Trace图例：

1.2.2.1 支持的负响应码（NRC）：

• 10服务支持NRC部分Trace
  

---

📙2 ECUReset (0x11) service

2.1 服务介绍

• 客户端使用ECUReset(0x11)服务来请求服务器重置。该服务请求服务器根据ECUReset请求消息中嵌入的Type参数值的内容，有效地执行服务器重置

2.2 请求格式

• 一般情况下ECU支持 01和03这两种子功能
• 11 01： 硬件复位
• 11 03 ：软件复位

2.2.1 正响应格式及Trace图例：

2.2.1.1 重点参数解释：

• powerDownTime：这个参数是可选的，很多诊断响应都没有这个参数的，都是直接响应$11 01或者 $11 03的，如果有这个参数就是告诉Tester，ECU重启需要的时间

2.2.2 负格式及Trace图例：

2.2.2.1 支持的负响应码（NRC）：

---

📙3 TesterPresent (0x3E) servic

3.1 服务介绍

• 此服务用于向服务器指明客户端仍然在线，并且之前已经激活的诊断服务(或通信)将保持活动状态。
• 如果ECU切换到非默认会话，如果Teser不发送 $3E 00或者$3E 80，则ECU S3time （5s）超时后，就会切换到默认会话，同时也会失去在非默认会话的权限。比如我们在刷写的时候，会进入到编程会话，同时需要周期性地发送TesterPresent (3E 服务) 服务，防止会话回到默认会话

3.2 请求格式

3.2.1 正响应格式及Trace图例：

3.2.2 负格式及Trace图例：

3.2.2.1 支持的负响应码（NRC）：

---

📙4 CommunicationControl (0x28) service

4.1 服务介绍

• 此服务用于开启或者关闭通信

4.2 请求格式

4.2.1 重点参数解释

• ControlType：控制类型 ，请看下图，简单明了。总共有四种控制类型。图中的约定列中：M代表强制，U代表可选。
  

• CommunicationType:通信的报文类型，所要控制通信的报文类型，没有网络管理的ECU可以不支持02/03。
  

• nodeIdentificationNumber:这个参数，很少用，只有ControlType 等于4或者5的时候才会用，用于指定子网节点数。

常见的请求报文组合如下：
28 00 01：使能APP报文的收发
28 00 02：使能NM报文的收发
28 00 03：使能APP和NM报文的收发
28 01 01：禁止发送APP
28 01 02：禁止发送NM报文
28 01 03：禁止发送APP和NM报文

4.2.2 正响应格式及Trace图例：

• 这里ECU接收到28 01 01诊断命令后，就会停发报文，然后收到28 00 01之后再开始发送报文
  

4.2.3 负格式及Trace图例：

4.2.3.1 支持的负响应码（NRC）：

📙5 ControlDTCSetting (0x85) service

5.1 服务介绍

• 该服务用于停止或重启ECU诊断故障代码状态位的更新
• 一般和0x28服务一起在刷写中使用。为了提升刷写的速率和稳定性，应用报文、网络管理报文是没有必要参与通信的，把总线让出来，只让诊断报文参与通信即可。而这个操作就需要用到0x28（Communication Control）服务，禁止非诊断报文的通信。因为报文丢失，会报很多lost communiction相关的DTC，所以在执行0x28服务之前，需要先执行0x85 01禁止DTC更新。

5.2 请求格式

5.2.1.1 重点参数解释

• DTCSettingType：控制类型 :主要用到 0x01(开启DTC更新)，0x02 (停止DTC状态更新)
• 01： 当ECU接受到子功能参数为关的控制诊断故障代码设置请求时，ECU应暂停诊断故障代码状态位的任何更新（即冻结当前数值），直到功能被重新使能。
• 02 ：当ECU接收到子功能参数为开的控制诊断故障代码服务请求， 或进入不支持控制诊断故障代码设置服务的会话（如：会话层时序参数超时进入默认会话、电控单元复位等），诊断故障代码状态位信息应重新开始更新。
• 特例：如果一个ClearDiagnosticInformation (0x14)服务由客户端发送，ControlDTCSetting不应该禁止重置服务器的DTC状态位，就是14服务可以清除已有DTC的状态位。

5.2.1 正响应格式及Trace图例：

5.2.2 负格式及Trace图例：

5.2.1.1 支持的负响应码（NRC）：

📙6 ReadDataByIdentifier (0x22) service

6.1 服务介绍

• 该服务通过标识符（identifier）来读取ECU的数据。dataIdentifier（DID），占用两个字节，ISO 14229-1定义了一些固定的DID，比如 0xF18C （读取ECU序列号），0xF181(读取app软件版本)等。除了规范了的DID，厂家可以自定义DID值。

6.2 请求格式

• dataIdentifier：标准规定可以一次请求多个DID的值，比如可以$22 f190 f180 。。。但是实际使用，我们常常只请求一个DID值

6.2.1 正响应格式及Trace图例：

6.2.2 负格式及Trace图例：

6.2.1.1 支持的负响应码（NRC）：

---

📙7 WriteDataByIdentifier (0x2E) service

7.1 服务介绍

• 诊断服务2E主要用于Client向Server(ECU)通过DID的方式写入相关的数据。一般情况，相同的一个DID号码，会支持22/2E服务。

7.2 请求格式

• 一般情况，2E服务只支持拓展会话和编程会话，而且需要解锁才能写入。而多数22服务，可以在默认会话，且无需解锁就可访问的。

• dataIdentifier：DID值

• dataRecord：写入的数据

7.2.1 正响应格式及Trace图例：

7.2.2 负格式及Trace图例：

7.2.1.1 支持的负响应码（NRC）：

📙8 ReadDTCInformation (0x19) Service

8.1 服务介绍

• $19服务读取DTC相关的服务，在14229-1中占用很多篇幅，可能是最重要的服务了，19服务有很多子功能，功能也很复杂，常用的就下面6种功能，下面我们通过Trace 一一解读下。

8.2 常用子功能

8.2.1 sub-function = 0x01 reportNumberOfDTCByStatusMask

• 根据 reportNumberOfDTCByStatusMask 字面意思可以理解 获取与客户端定义的状态掩码匹配的DTC的数量**,重要的点是这个Mask（掩码）的理解, DTCStatusMask 是一个字节，8个BIT全部都定义了意义，用来描述一个DTC的当前状态，比如BIT(0) Test Failed ，如果这个DTC当前被激活，那么这个BIT(0)就要置 1。全部BIT的意义，下面再细讲。
• 那么下面的Trace 19 01 01 就好理解了，就是读取 此刻被激活的DTC的数量.

• 那么再看下改诊断的响应参数理解：
• ReportNumberOfDtcByStatusMask ： 子功能 01 没什么可说的。
• DTCStatusAvailabilityMask ： 7B ，说明该控制器，只支持前6个BIT的DTC状态，如果控制器支持全部，则应该回复FF
• DTCFormatIdentifier :DTC的格式，根据那个标准来定义的。一包默认都是0，具体标准对应如下图。
  
• DTCCount ： 占两个字节，返回的DTC的数量（根据请求的掩码）

8.2.2 ub-function = 0x02 reportDTCByStatusMask

• Retrieving the list of DTCs that match a client defined status mask
• 根据掩码返回所有的DTC.这里要注意， DTC是根据掩码 与 运算 来决定是否返回的，比如 用 19 02 01请求 ，当前控制器中有一个DTC的状态是 0x2B(0010 1101) ,则该DTC应该出现再诊断响应中，因为0x01 &0X2B! = 0 .
  
• 再来个反例，体会下，掩码与运算的逻辑，,如果 用19 02 04去请求，则该DTC不应该被返回，因为0x04 &0X2B = 0
  - 那么再看下改诊断的响应参数理解：
• ReportNumberOfDtcByStatusMask ： 子功能 02 没什么可说的。
• DTCStatusAvailabilityMask ： 7B ，说明该控制器，只支持前7个BIT的DTC状态，如果控制器支持全部，则应该回复FF
• ListOfDTC:返回的是满足请求掩码的DTC的一个列表，每个列表包含4个字节（3个字节的DTC和一个DTC的状态位）

8.2.3 sub-function = 0x03 reportDTCSnapshotIdentification

• Retrieving DTCSnapshot record identification
• 这里先明白快照是什么意思，就是当一个DTC触发的时候，控制器要记录控制器的一些信息，比如拍照片的时候，照片会记录日期信息一样，当DTC触发时也要记录触发时的日期，里程，速度等基本信息
• 而且，一个DTC可能不止记录一次快照，可能有两个快照信息。比如可能DTC会记录第一次触发时的快照，和最后一次触发的快照，DTC可能被多次触发，那么快照信息只更新该DTC的最后一个快照，第一个快照信息就一直不变
• 该 03子功能返回所有已经被记录在NVM中的快照信息，类似于19 02，返回的时满足的所有DTC信息，但是19 03 和 19 01 一样，都是返回概括信息，并不是具体信息。返回快照的具体信息需要用到 19 04
  
• 从Trace返回值上我们应该可以看出，当前控制器有两个DTC被触发，且每个DTC有两个快照信息被保存在NVM中

8.2.4 sub-function = 0x04 reportDTCSnapshotRecordByDTCNumber

• Retrieving DTCSnapshot record data for a client defined DTC mask

• 该子服务返回的是DTC 快照的内容细节，和1903不同。

• 该子服务一次只能请求一个DTC的快照信息，由DTCMaskRecord参数指定，

• 该子服务一次可以请求多个快照信息，由DTCSnapshotRecordNumber控制，如果该参数为1，则请求一个快照信息，如果为FF，则请求支持的所有快照信息。
  
  

• 看下19 04的响应内容。

• DTCSnapshotRecordNumber： 参数是快照的索引，本实例用FF请求的快照，返回了所支持的全部两个两块找信息，快照2由于截图原因未展开，图中 DTCSnapshotRecordNumber 1 就表明下面的内容是快照 1的内容

• DTCSnapshotRecordNumberOfIdentifiers ： 快照的所有内容是由 多少个 DID（22服务）组成的，本实例是由8个DID信息组成快照信息

• 再下面就是每个DID（占两个字节），每个DID中的数据字节数不固定，根据厂家自定义

• 下图是19 04正响应的标准格式
  

8.2.5 sub-function = 0x06 reportDTCExtDataRecordByDTCNumber

• Retrieving DTCExtendedData record data for a client defined DTC mask and a client defined DTCExtendedData record number
• 19 06 读取扩展信息，从字面意思可以理解，就是快照的拓展信息了，一般情况下 1906会记录 DTC老化相关的参数信息。如果 19 04 没有记录年月日时分秒，那么拓展信息一定会记录，19 06记录什么，每个控制器定义的都不同，但是格式要根据标准来
• 19 06 请求格式和 19 04一样。同时拓展信息也支持多个拓展信息块，用FF请求可以请求所有的拓展信息。
• 19 06请求标准格式
  -

• 1906 中一个重要的概念就是老化，什么是老化呢？就是ECU 出现过一次故障，然后故障消失了，存储为历史故障，比如我们常用 19 02 09去读取当前故障DTC，然后用 19 02 08 去读取历史故障DTC，这个08对应着DTC掩码位的bit3 （Confirmed DTC），也就是说，虽然DTC在当前周期一定不存在了，但是这个Confirmed DTC 位一直为1，来表明该故障曾将出现过，那么这个BIT怎么才能清楚呢，一种方法是 14 服务清除，另外一种方法就是老化机制了，一个点火或者上下电是一个周期，那么当ECU经过 50（因厂而定）个周期，则Confirmed DTC置0，下图中的拓展信息中的Aging Counter 就是老化参数，每个周期该值+1，直到加到50，再重置为0。
  

8.2.6 ub-function = 0x0A reportSupportedDTC

• Retrieving the status of all DTCs supported by the server
• 返回素有支持的DTC码
• 请求格式很简单就是19 0A
• 响应的是所有支持的DTC码以及当前状态
  

8.3 DTC的定义

8.4 DTC状态掩码的细讲

• 这8个BIT，各有意义.但是很多厂商，逻辑做的并不复杂，也就是有些BIT的逻辑直接就不支持。

bit 0 : testFailed

通常来说，ECU内部以循环的方式不断地针对预先定义好的错误路径进行测试，如果在最近的一次测试中，在某个错误路径中发现了故障，则相应DTC的这一个状态位就要被置1，表征出错。此时DTC的testFailed位被置1，但是它不一定被ECU存储到non-volatile memory中，只有当pendingDTC或confirmedDTC被置1时DTC才会被存储。而pendingDTC或confirmedDTC被置1的条件应该是检测到错误出现的次数或时间满足某个预定义的门限。当错误消失或者诊断仪执行了清除DTC指令时，testFailed会再次被置为0。

bit 1 :testFailedThisOperationCycle

这个bit用于标识某个DTC在当前的operation cycle中是否出现过testFailed置1的情况，即是否出现过错误。operation cycle的起始点是ECU通过网络管理唤醒到ECU通过网络管理进入睡眠，对于没有网络管理的ECU，这个起始点就是KL15通断。通过bit 0我们无法判断某个DTC是否出现过，比如，当前testFailed = 0，说明当前这个DTC没有出错，如果testFailedThisOperationCycle =1的话，就说明这个DTC在当前这个operation cycle中出过错，但是当前错误又消失了。

bit 2 : pendingDTC

根据规范的解释，pendingDTC = 1表示某个DTC在当前或者上一个operation cycle中是否出现过。pendingDTC位其实是位于testFailed和confirmedDTC之间的一个状态，有的DTC被确认的判定条件比较严苛，需要在多个operation cycle中出现才可以被判定为confirmed的状态，此时就需要借助于pendingDTC位了。pendingDTC =1的时候，DTC就要被存储下来了，如果接下来的两个operation cycle中这个DTC都还存在，那么confirmedDTC就要置1了。如果当前operation cycle中，故障发生，pendingDTC = 1，但是在下一个operation cycle中，故障没有了，pendingDTC 仍然为1，再下一个operation cycle中，故障仍然不存在，那么pendingDTC 就可以置0了。

bit 3 : confirmedDTC

当confirmedDTC = 1时，则说明某个DTC已经被存储到ECU的non-volatile memory中，说明这个DTC曾经满足了被confirmed的条件。但是请注意，confirmedDTC = 1时，并不意味着当前这个DTC仍然出错，如果confirmedDTC = 1，但testFailed =0，则说明这个DTC表示的故障目前已经消失了。将confirmedDTC 重新置0的方法只有删除DTC，UDS用0x14服务，OBD用0x04服务。

bit 4 : testNotCompletedSinceLastClear

这个bit用于标识，自从上次调用了清理DTC的服务（UDS用0x14服务，OBD用0x04服务）之后，是否成功地执行了对某个DTC的测试（不管测试结果是什么，只关心是否测了）。因为很多DTC的测试也是需要满足某些边界条件的，并不是ECU上电就一定会对DTC进行检测。

• testNotCompletedSinceLastClear = 1 : 自从清理DTC之后还没有完成过针对该DTC的测试。

• testNotCompletedSinceLastClear = 0 : 自从清理DTC之后已经完成过针对该DTC的测试。
  

bit 5 : testFailedSinceLastClear

这个位与bit 1 :testFailedThisOperationCycle有些类似，后者标识某个DTC在当前的operation
cycle中是否出现过testFailed置1的情况，而testFailedSinceLastClear标识的是在上次执行过清理DTC之后某个DTC是否出过错。

• testFailedSinceLastClear = 0 ， 自从清理DTC之后该DTC没有出过错。

• testFailedSinceLastClear = 1， 自从清理DTC之后该DTC出过至少一次错。
  

bit 6 : testNotCompletedThisOperationCycle

这个位与bit 4 testNotCompletedSinceLastClear类似，后者标识自从上次调用了清理DTC的服务之后，是否成功地执行了对某个DTC的测试。而testNotCompletedThisOperationCycle则标识在当前operation cycle中是否成功地执行了对某个DTC的测试。

• testNotCompletedThisOperationCycle = 1 ： 在当前operationcycle中还没在完成过针对该DTC的测试。

• testNotCompletedThisOperationCycle = 0 ： 在当前operationcycle中已经完成过针对该DTC的测试。
  

bit 7 : warningIndicatorRequested

某些比较严重的DTC会与用户可见的警告指示相关联，比如仪表上的报警灯，或者是文字，或者是声音。这个warningIndicatorRequested就用于此类DTC。

• warningIndicatorRequested = 1 ： ECU请求激活警告指示。

• warningIndicatorRequested = 0： ECU不请求激活警告指示。
  

📙9 SecurityAccess (0x27) service

9.1 服务介绍

• 安全访问服务，主要功能是为了通过诊断安全地访问服务端，也就是ECU，而设置的一层保护机制。
• 安全访问服务用于修改存储在内存中的 ECU 数据，在此之前，用户首先必须通过该服务授予访问权限。此服务的目的是提供一种访问信息和/或诊断服务的方法，这些服务因安全、排放或安全原因而受到限制。比如一些用于将例程或信息下载/上传到服务器中，并从服务器中读取特定的内存位置的诊断服务可能需要安全访问。因为下载到服务器中的不当程序或信息无疑可能会损害ECU，或危及车辆遵守排放、违反安全或安保标准。安全访问的机制通过使用种子和密钥来实现
• 使用此服务的典型示例如下∶
  ①客户端首先发送请求种子的诊断请求
  ②服务端收到请求后，计算一个随机种子通过诊断响应发送给客户端
  ③客户端收到种子后，使用定义好的算法计算出密钥，然后通过诊断请求发送给服务端
  ④服务端收到密钥后，与自己计算的密钥作对比，如果一致，验证通过，如果不一致，验证失败

9.2 请求格式

• 通过上图可以看到， "requestSeed (请求种子) ”子功能参数值应始终为奇数,且同一安全级别的相应"sendKey (发送密钥) ”子功能参数值应等于"requestSeed (请求种子) ”子功能参数值加一。
• 一般情况，ECU至少支持两个子功能的解锁，一个适用于APP模式下的解锁等级，一个适用于BOOT下的解锁等级。很多情况下下，为了区分访问ECU的权限，都设置可多余2个解锁等级。
• 需要注意：
• 同一时刻最多只能有一个安全等级是解锁的状态，因此从一个安全等级接收到另外一个等级的请求并且解锁成功后，之前的安全等级将被重新锁定，而由于切换安全等级致使先前解锁的状态被锁定后，其依赖于被锁定的等级的服务和功能也一并被关闭
• 如果被请求的安全等级当前是已经解锁的状态，那么在响应种子时，ECU就会响应全零的种子，表示已经解锁了，你就不要再请求了。
• 安全访问为了增加破解难度，一般会设置错误尝试次数和延时机制。当错误尝试超过次数的限值时，就会开启延时，延时时间内，不允许进行安全访问，也就是说请求种子会一直给否定响应

9.2.1 正响应格式及Trace图例：

9.2.2 负格式及Trace图例：

• 支持的负响应码（NRC）：

• 27服务比较复杂，除了支持常规的 0x12,0x13,0x24外，还支持0x35,0x36,0x37服务

---

🌎总结

• 🚩要有最朴素的生活，最遥远的梦想，即使明天天寒地冻，路遥马亡！
  
  
• 🚩如果这篇博客对你有帮助，请 “点赞” “评论”“收藏”一键三连 哦！码字不易，大家的支持就是我坚持下去的动力。