一.ISO-14229  UDS

ISO国际化标准组织，用于国际化标准

ISO 14229(Unified Diagnostic Services)简称为UDS

U代表统一，不限定总线

D代表诊断，诊断通信协议

S代表服务，诊断服务

ISO 14229-1有ISO/TC 22技术委员会，道路车辆，SC3组，电气电子设备组编制。

UDS建立了诊断系统独立于数据链路的通用需求，同时UDS是一种Client/Server的通信服务。

本质上是一种定向的通信，是一种交互协议，是一种面向汽车（整车）控制单元ECU的统一诊断服务

1.1 UDS的结构层次

诊断仪（客户端）和电子控制单元（ECU）的服务分为以下层次：

应用层、表示层、会话层、网络层、传输层、数据链路层、物理层、

统一诊断服务层是应用层，因为ISO在应用层规定了诊断需求。

网络服务层指表示层、会话层、网络层、传输层、数据链路层、物理层

诊断增强型七层模型：

在基于UDS的规范时，通信机制是由一条总线构成，总线贯穿全局架构。总线是可以发生改变的，比如基于CAN、基于蓝牙、基于LAN、基于FlexRay等

总线就是用于传输数据的一条数据传输通道,针对不同的汽车厂家，可以根据需求采用适合的总线。

就是根据诊断出的数据，进行显示。

1.2 UDS的通信流程

1.3 UDS的规范与要求

UDS允许诊断仪（客户端）控制车辆ECU（至少包含一个服务器）中的诊断功能，但是两个不同的ECU（车载电子控制的单元、服务器）不可以传输UDS规范外的数据。另外不同的厂家指定的标准是不一样的，如果将错误的数据传输给另一个不同的ECU，个人理解可能会导致总线紊乱，发生异常，以致汽车发生异常。同时在测试时，如果没有规范和约束，你如何判断对错，测试又从何而起那？所以说，不成规矩，何以成方圆。这也是为什么要有UDS协议的意义。但是UDS支持诊断消息传输，可以达到数据交互，排查错误的作用

1.4 协议数据单元及帧的传输

协议数据单元：协议数据单元是一组信息和数据的集合，表示了发送方和接受方对等实体之间传递的信息和数据。协议数据单元包括：

协议控制信息(PCI)：

数据(Data)

帧：

数据帧的定义：

单帧的定义：

多帧中首帧的定义：

多帧中流控帧的定义：

块大小：当前发送的数据帧是有一定的次序的，而一旦发送一定次序（Block Size），则数据接收端就会发送一次流控帧，否则发送端就会判断当前多帧为发送失败

流控帧的定义：

单帧传输：数据长度<6/7个字节 ，报文类型  单帧(SF)

单帧：值为0，其长度可为8个字节(value值占1个字节 + 7个表示正常地址字节，一般我们遇到主要就是类型的)或7个字节(value值占1个字节 + 6个扩展地址字节)；

多帧传输：数据长度>6/7个字节，最多允许4095个字节

报文类型：

第一帧(FF)：描述传输的起始。其值为1， 用于长的、已被分割的多帧消息包中。首帧包括整个包的数据长度，以及数据初始值

连续帧(CF)：传输数据。其值为2，包含多帧消息包后续子序列的数据帧；

帧的传输的数据长度，是和网络层的格式相关的

流控制帧(FC)：传输过程中，报文流控制。其值为3， 是由接收方在确认收到首帧(FF)后发起的响应。其约定了后续连接帧(CF)的传输参数；

单帧的发送流程：

多帧的发送流程：

单帧为报文类型直接发送，多帧在首帧发送并接受后，返回流控制帧

PDU的说明：

N_PIC的结构：

7E0h 8 Tx 02 10 01 55  55 55 55 55。02代表单帧，10 01实际数据，55为填充

7E0h 8 Tx 10 0F 2E F0 10 04 05 06。1代表首帧，00F2E代表长度，后面的是它的数据

7E0h 8 Rx 30 0A 0A 55 55 55 55 55。3代表流控制帧，0代表继续发送

首帧包含数据长度

FS的含义：

流控制帧(3)后面的0：继续发送 。让发送方继续发送接下来的连续帧，表示接收方已经准备好了接受最大为BS数量的连续帧

流控制帧(3)后面的1：等待。发送方等待下一帧流控帧并重置自己的计时。一般用于接收方没有处理完上一次接收到的连续帧。

流控制帧(3)后面的2：过载。发送方打算发送的数据长度超过了接收方的存储能力

BS的含义：1~FF表示发送方在发送BS数值的连续帧之后，需要等待接收方的流控帧。

Block Size = 0表示不需要任何流控帧，直接发送全部数据

Block Size = 3,就代表最大能接收几条连续帧。

STmin的含义：表示发送方发送的两个连续帧之间，最小需要的时间间隔。00~7F单位为ms；F1~F9表示0.1~0.9ms；0表示按照发送方最快速度发送

当首帧发送的字节数过大，接收方会自动将此帧忽略，不会向上层上报任何内容。接收和发送都不会报错。但是如果在应用层可能会给出长度不符合的错误报文

如果发送方发送FC，其中FS=Overflow(2 过载)，接收方(EUC)无indication，会返回Overfloew的错误

发送方发送多帧长度不符合，网络层忽略FF，接收方无indication,自动丢弃，且不发送FC，网络层会受到超时响应（N_TimeOut_BS）

发送方发送连续帧，因为网络波动，报文接收被终端，导致SN号顺序错误等，整个发送过程会被中断。接收方返回SN错误，发送方返回发送超时

1.5刷写流程

二.UDS协议相关常见术语

本地客户端

本地客户端（local client）与服务器处于统一本地网络，且处于同一地址空间

本地服务器

本地服务器（local server）与客户端处于同一个网络，且处于同一地址空间

Diagnostic Service(诊断服务)

诊断服务是介于诊断设备（诊断仪）和被诊断ECU(电子控制单元)之间的一种信息交互方式。

诊断服务是从客户端发起请求服务器信息或修改服务器行为以进行诊断，

通常由诊断设备(诊断仪)发出请求，被诊断ECU（电子控制单元）做出回应

Diagnostic Trouble Code（故障码）

故障码是用来标记故障的代码，保存在非易失性存储器中

非易失性存储器简称NVM，当电流关闭后，所存储的数据不会消失的电脑存储器。即时时自动保存

Diagonstic Data(诊断数据)

诊断数据是可以被诊断设备请求的ECU内部数据，它包括：

1.当前数据，即ECU正在使用的某个数据，比如车速、节气门角度等

2.存储数据，即被ECU存储在存储器中某一时刻的数据，比如DTC

3.静态数据，即恒定不变的ECU内部数据，比如VIN码

诊断数据包含模拟输入输出、数字输入输出、中间值和状态改变信息

服务器不负责保存以诊断为目的的内部数据拷贝，这种情况下可能只会获取当前值

Diagnostic Session(诊断会话)

诊断会话是服务器中一些特定的诊断服务和启用功能的集合

根据诊断模式或权限的不同，在不同的模式下，对不同的诊断服务的使用进行了限制

只有当前激活的诊断会话支持的诊断服务才能被响应。ECU通常有两个以上的诊断会话，包括：一个默认会话(Default Session)和若干个非默认会话(Non Defailt Session)。非默认会话由用户自行定义。典型的ECU诊断会话定义如下：

同一时刻只有一个会话处于激活状态。此时ECU可以响应该诊断会话关联的诊断服务。如果客户端请求了当前诊断绘画下不支持的诊断服务，则服务器需要给出NRC为0x7F的否定响应。激活新的诊断会话上会关闭一个诊断会话。通常在默认会话(Default Session)下，允许如下的诊断服务：

非默认会话支持下的诊断服务由用户自定义。通常编程会话(Programming Session)下支持的诊断服务如下：

1.在默认会话（Default Session）下，如果服务器(ECU)收到了诊断会话控制服务请求再次激活默认会话，则服务器（ECU）重新初始化默认会话。之前在默认会话下的设置或激活的功能将失效

重新激活默认会话，之前的默认会话下的设置和激活的功能会失效

2.在默认会话(Default Session)下，如果服务器(ECU)收到了诊断会话控制服务请求激活一个非默认会话(如扩展会话)，则服务器只需要停止事件响应服务(ResponseOnEvent，SID 0x86)请求执行的功能，其他服务的执行不受影响

激活默认会话后，在激活非默认会话，只会把激活的服务关闭掉，其他服务不受影响

3.在非默认会话下，如果服务器(ECU)收到了诊断会话控制服务请求激活一个非默认会话(包括当前激活的会话)，则在上一个会话下事件响应服务（ResponseOnEvent,SID 0x86）请求执行的功能将停止；之前解锁的安全等级将重新锁定；诊断会话切换前后，两个会话都支持并且不需要解锁安全访问等级的服务将不受影响。上一会话支持但新的会话不支持的服务将终止执行

切换会话后，如果新的会话安全等级比上一个会话等级高或者相同（不需要解锁安全等级），且新的会话支持上一个会话的服务，会话将不受影响，继续执行。上一个会话支持，但新的会话不支持，服务将会停止

4.在非默认会话下，如果服务器(ECU)收到了诊断会话控制服务请求激活默认会话，则在非默认会话下事件响应服务(ResonseOnEvent, SID 0x86)请求执行的功能将被停止，解锁的安全等级将被重新锁定，在默认会话下不支持诊断服务将被终止。

切换会话后，如果新的会话安全等级比上一个会话等级高或者相同（不需要解锁安全等级），且新的会话支持上一个会话的服务，会话将不受影响，继续执行。上一个会话支持，但新的会话不支持，服务将会停止

新旧会话必须同时支持已经运行的会话

为什么要设计三个会话模式哪？

因为权限问题。默认会话权限最小，可操作的服务少；扩展模式通常用于解锁高权限诊断服务

拓展会话：默认会话有的我全有，写入数据/参数、读写诊断码、例程控制等

编程会话:读/擦故障码、解锁bootloader相关的诊断服务

这里来一张权限表格。带颜色的区域代表需要解锁操作。

Diagnostic Routine（诊断例程）

驻留在被诊断ECU中的子程序（内嵌至ECU内部），它可以被诊断设备（客户端）启动和停止。比如格式化EEPROM的子程序

EEPROM是指带电可擦可编程只读存储器。是一种掉电后数据不丢失的存储芯片。即插即用。简单直白就是内存卡

Tester诊断仪

诊断仪系统对车辆电子控制单元进行注入测试、检查、监控、诊断，也可以进行专门的操作类型

三.诊断服务常见术语

3.1术语简称(别名)

3.2原语

原语的发送格式一旦确定那么响应格式也也是和发送格式相同

3.3术语

寻址方式(Addressing Type)

寻址方式指的是诊断消息的传递方式，有两种寻址方式：

Physical，物理寻址，即1对1通信，用于知道确切的被诊断ECU的地址

Functional，功能寻址，即1对n通信，或者说广播发送，用于不知道确切的被诊断的ECU的地址，向一组或者全体ECU发送请求

物理寻址相当于单独发送，类似你和你的好友私聊

功能寻址就是群发，在群里一起聊天

物理寻址和功能寻址的区别：两种寻址支持的服务是不一样的，ECU所支持的服务，物理寻址都可以访问，功能寻址只能访问部分服务

功能寻址只支持10，11，28，3E，85，22，14，19这几个服务

使用物理寻址进行诊断时，当出现错误时都会反馈NRC码，但功能寻址出现以下情况，不需要反馈错误码

1.31

2.12

3.11

4.7F

5.7E

服务器响应实现规范:

重要提示 - 依据表中要求的下列条款中：带否定响应码SNS（serviceNotSupported）、SNSIAS（serviceNotSupportedInActiveSession）、SFNS（sub-functionNotSupported）、SFNSIAS（sub-functionNotSupportedInActiveSession）和ROOR（requestOutOfRange）的否定响应消息不应在请求消息使用功能寻址时传输。（异常参考附录 A.1 NRC 0x78 的定义）

消息请求和服务器响应行为：

不带子功能参数服务器一定要响应回复

诊断的结果(Result)

Result指的是诊断仪(tester)请求诊断服务执行后，从ECU的返回结果。有两种返回结果：

Positie Response，正响应，即诊断请求执行成功

Negative Response，负响应，即诊断请求执行失败

服务识别符(Service Identifier)

Service Identifier可以简称为SID，它是一个一字节的无符号整数，用以指某个诊断服务。

诊断协议为每一个诊断服务都分配了唯一一个SID，因此更方便协议的软件实现。同时，在我们日常工作中用SID

来指代某个诊断服务比说出某个服务的名字更方便简洁  别名 简称

数据标识符(Data Identifier)

简称DID，是两个字节无符号整数的ID，用来标识ECU中储存的某个诊断数据单元。它的好处是当要读取某个单元的诊断数据时，

只要读对应的DID就可以了，不必知道具体地址。即使当ECU中的数据地址发生变化时，只要DID和某个地址单元的映射地址改变即可，对于使用者来说DID屏蔽了具体实现细节，而将重点放在了数据本身。

DID是ID可以当作唯一标识符

只用知道数据的DID就行了，无论数据的地址如何改变，通过反射就可以找到

错误响应码(Negative Response Code)

简称NRC，或者叫错误响应码，是一个字节的无符号整数。发送失败或者响应失败返回一个整数，它是诊断协议为每一种执行失败的诊断服务分配的失败原因代号。

(子功能)Sub-function

有些诊断服务可以支持不同的诊断自服务，Sub-function就是用来定义这种自服务的，它将某一个服务细分为更为具体的服务，

它是一个字节的无符号整数。比如ECUReset这个服务就有0x01,0x02,0x03等几种sub-function指代具体的reset方式

诊断的基本概念

诊断服务的传输

客户端与服务端

客户端(Client)

诊断请求的提供者-Tester，发送诊断请求。诊断仪由我们来操作

服务器端(Server)

诊断响应的提供者-某个ECU，发送诊断响应。电子控制单元

远程客户端/服务器(Remote Client/Server)

与Server(Client)不在同一个网段，无法进行连接

诊断服务的概念

服务请求和响应格式："请求"由诊断仪(Tester)发送给电子控制中心(ECU)，请求报文中带有SID，

根据具体的服务内容后面加上具体的数据

诊断请求

诊断会话控制服务(Diagnostic Settion Control Service，SID 0x10),请求报文定义如下:

其中：A_Data_byte #1为该服务的请求SID，值为0x10

A_Data_byte#2为诊断会话类型，即请求激活的诊断会话，取值如下：

注意，诊断会话类型仅占A_Data_byte#2的bit 0~bit6。Bit7为肯定响应抑制位

诊断服务的两种响应？

肯定响应和否定响应

肯定响应又分为支持子功能和不支持子功能。支持子功能(Subfunction)的请求格式为"SID+一个字节Subfunction+具体的数据"，肯定相应格式为"SID(服务识别符)+40+具体的数据"。如果有的UDS服务不支持子功能(Subfunction)，那么这个UDS功能肯定是支持DID(数据ID)的，那么它的请求格式为"SID+具体的DID+数据内容"，肯定响应为"SID+40+DID+具体的数据"。

否定响应格式是一个固定的格式"7F+请求报文里的SID+一个字节的NRC(错误响应码)"

肯定响应：

其中，A_Data_byte#1为诊断会话控制服务响应SID，值为0x50。(0x10+1x40);

A_Data_byte#2为请求的诊断会话类型，与诊断请求中的参数相同。

ADatabyte#3~#6为被激活的诊断会话参数。包括P2Server_max和P2*Server_max

子功能的抑制位

子功能参数的取值范围0x-ox7F。子功能参数只占用一个字节

可用取值范围为0x00-0x7F。但最大取值范围为0x7F

子功能参数的最高位就是诊断服务肯定响应抑制位SuppressPosRspMsgIndicationBit，简写为SPRMIB。

子功能参数的格式定于。其中的最高位Bit7九决定了ECU是否需要给出肯定响应

肯定响应抑制位的作用：ECU收到响应抑制位(SPRMIB)为1的服务时，不需要给出肯定响应。相反当ECU收到肯定响应抑制位(SPRMIB)为0的服务时，需要给出肯定响应

为0时就是失败了

什么情况下不需要给出否定响应

在UDS中规定，如果服务器收到的是功能寻址的诊断请求，并且需要回复如下的否定响应码时，是不需要给出否定响应的

仍然要给出否定响应的特殊情况

ECU在响应某些诊断服务时，由于执行时间较长，无法给出肯定响应。此时ECU会先给出NRC为0x78的否定响应。然后等到所请求的服务执行完后，给出最终的肯定响应或否定响应。这种情况下，即使ECU收到的诊断服务请求中子功能参数肯定响应抑制为1，最终的肯定响应也不会被抑制

过程：首先Tester请求ECU进入编程会话(Programming session)，但不希望ECU给出肯定响应。但是进入编程会话通常需要ECU复位，重新启动后进入BootLoader。这个过程所需要的时间会超过P2CAN_Server(通常为50ms）。所以ECU会先给出NRC为0x78的否定响应，用以通知Tester诊断请求已经正确接收了，正在处理，稍后给出响应。当ECU成功执行了切换编程会话(Programming  Session)的操作后，由于之前给出了NRC为0x78的否定响应，用以通知Tester诊断请求已经被执行成功了

当我们把请求发送给ECU后，类似于延时操作，然后会给出接受成功正在处理的信后，等处理完成后，在重新响应，当ECU切换到编程会话后，会给出肯定响应，告知我们请求成功了

时间参数

时间参数：一个叫做P2Server，一个叫做P2Server*。当Tester给ECU发送请求过后，ECU需要在P2Server时间内给出相应的响应，如果ECU当前正在处理别的任务，而不能在P2Server的时间内给出相应的响应，那么它在P2Server*时间内给出一个NRC为78的Pending的报文，告诉Tester现在“ECU正在忙”，之后会在P2Server的时间内给其它的响应报文，如果P2Server*的时间内还是不能给出相应的肯定响应或否定响应将继续给出Pending报文，直到能够正确处理请求报文之后，或给出正确的响应报文

P2Server_max为当前诊断会话下从服务器(ECU)接受到诊断请求到开始发送诊断响应报文的最长时间

P2Server*_max为当前诊断会话下从服务器(ECU)发出NRC为0x78的否定响应到开始发送到最终的诊断响应报文的最长时间

在一个时间节点内如果没有响应成功，就给出一个NRC为78的Pending的报文，之后的时间会一直Pending报文，直到能够正确处理请求报文之后，给出正确的响应报文

诊断会话定时参数

在非默认会话下，如果服务器(ECU)在S3Server时间内未收到任何诊断服务，将会结束当前会话。这种情况下被称为会话超时。通常在客户端没有诊断服务请求但又希望服务器（ECU）维持非默认会话时，需要定期发送诊断仪在线服务(TesterPresent,SID 0x3E),以避免服务器(ECU)发生诊断会话超时。两次发送诊断仪在线服务(Tester Present，SID 0x3E)的间隔时间由S3Client来规定

诊断仪发送诊断仪在线服务(Tester Present,SID 0x3E)的间隔时间最长为4000ms，小于服务器(ECU)的会话超时时间(5000ms)。通常建议2000ms发一次诊断仪在线服务(Tester Present,SID 0x3E)以保证可靠的维持服务器的诊断会话

四.诊断服务术语码图示

4.1 $3E待机握手

4.2 $27安全访问

ECU当中有很多数据是整车厂独有的，并不希望开放给所有客户，它需要一个保密的设定。我们在读取一些特殊数据的时候，要先进行一个安全解锁。ECU上电之后是一个锁定状态(Locked)，我们通过$27服务，加上子服务，再加上一个钥匙，这样的服务请求可以进行解锁。

通常在第一轮，ECU会根据时间线生成一个种子，然后用一个全局变量变量保存种子。等到第二轮Tester的key来的时候，才会进行运算的。当第一次计算出的数据和第二次计算出的数据相同时，解锁(Unllocked)成功

任何时候只能激活一个安全等级

安全验证算法包括1个核心，3个主体。

第一个主体通常和ECU有关。比如我们先用22服务读取ECU的SN，取其中4个字节，作为"调味料"参与，显然这个"调味料"对于这个ECU来说是不变的，也能通过22服务方便读取到

第二个主体seed，通常与ECU的运行时间有关系，是主料，在27服务发送奇数子宫时回复。seed通常一直在发生变化，无法发现其规律

第三个主体就是执行次数了，就是算法要执行几轮。执行一轮和两轮得到的结果肯定是不一样的。

最大的核心就是算法了，例举：比如seed和ECU SN前四个字节加一下，循环左右两位，执行三轮，return这个数作为key，结束。安全验证就是一把锁，算法越复杂，短时间解开的成本越高，约不容易破解掉。如果失败次数过多还会触发惩罚机制，一段时间内无法在尝试解锁，防止人为的破解

执行两次以上，根据算法算出后判断两次计算的数据是否相同，如果不相同，就代表访问错误。安全验证算法的核心就是算法，越安全的算法步骤越多，效率越慢，消耗的资源也越多

$22读数据

4.3 $2E写数据

4.4 $19 读DTC

19服务是一套诊断服务中的重中之重。协议中篇幅长达63页，通信举例达到了18个。可以说没有19服务，就没有完整的UDS。

DTC(diagnostic trouble code 诊断故障码)：如果系统监测到了一个错误，它将存储为DTC。DTC可表现为：一个显而易见的故障；通讯信号的丢失(不会使故障亮起)；排放相关的故障；安全相关的错误等。DTC可以揭示错误的位置和错误类型。通常DTC占用三个字节，OBD II占用两个字节。

图中FTB为Fault Type Byte。

故障码包括四个大类，分别时PCBU，P是powertrain动力系统，C是Chassis底盘，B是Boby车身，U是network通信系统。一个DTC信息占用四个字节。最后一个字节是DTC的状态。DTMMiddleByte和DTCLowByte两个字节是我们熟知的类似P0047(ISO15031中的故障码)中"0047"的纯数字故障码。第一个字节在乘用车中，前两个bit代表P/C/B/U(动力/底盘/车身/网络)中的一个，之后六个bit是数字，合在一起形如"C01".第一个字节的前两个bit中，用00/01/10/11分别表示P/C/B/U

ISO15031中的故障码，和UDS中的故障码在长度上有一定的不同

$19拥有28个子服务(Sub-Function)。常用的子服务有：

01(读取符合掩码条件的DTC数量)(必须支持)，后面的参数是DTC状态掩码，若为01表示我想读当前故障，若为08表示我想读历史故障，若为09表示当前故障和历史故障都想读

在肯定回复时，组合应该是59(19+40)-01(子功能)-09(本ECU所支持的掩码条件)-01

DTC的格式(ISO14229-1为01) -00 01(目前满足条件的DTC有一个)

02(读取符合掩码条件的DTC列表及其状态)(必须支持)，后面的参数是DTC状态掩码，解读同上。

在肯定回复是，59-02(子功能) -09(本ECU所支持的掩码条件)- XX XX XX(DTC,车厂定义) -01(这个故障码怎么了，01表示当前故障)

04(读取快照信息)，也叫冻结帧

06(读取扩展信息)

OA(读取ECU支持的所有DTC列表及其状态)(必须支持)。

一个DTC除了它自己的三个字节，还有一个字节专门用于表达DTC的状态，这个字节我们叫它DTC状态掩码。但并不是所有的DTC状态都是支持的。

DTC状态掩码：

4.5 $14清除DTC

4.6 $2F IO控制

该服务可以通过DID(数据标识符)来进行输入信号的替换和控制零部件负载输出。这是一个用在产线上较多的服务。该报文的请求至少由四个字节组成。第一个字节是2F，第二第三字节是DID，其中第二字节是高位。第四字节是input Output Control Parameter(并不能算一个子功能)，可以看做IO控制类型

IO控制类型分为4类：

00是控制权还给ECU,Return Control To ECU。

01是复位为默认值，Reset to Default。

02是冻结当前的状态，Freeze Current State

03是短暂接管控制权，Short Term Adjustment

若控制类型是00-02这三种，请求报文是4个字节

若控制类型是03，请求报文的第五字节是控制代码，可以是数字量

转载自积木家智能科技