【UDS 14229-1诊断服务内容详细解读】

目录

一.ISO-14229 UDS

1.1 UDS的结构层次

1. 物理层（Physical Layer）：

2. 数据链路层（Data Link Layer）：

3. 网络层（Network Layer）：

4. 传输层（Transport Layer）：

5. 会话层（Session Layer）：

6. 表示层（Presentation Layer）：

1.2 诊断服务基本知识

二、诊断服务概览

1、UDS诊断包括6大类，26种服务，每种服务都有自己独立的ID，即SID（Service Identifier）

​编辑

2、常见NRC码

3、不同会话支持的服务（会话优先级）

三、寻址方式

 四、特殊详情介绍

1、诊断会话控制（0x10）服务

1.1响应实例：

1.2实例说明：

2、ECU 重置（0x11）服务

2.1客户端使用 ECUReset（ECU重置）服务来请求服务器重置。

​编辑

2.2举例：

3、安全访问（0x27）服务

    3.1不同等级的安全访问（sub-function整车厂自己定义）

3.2举例：

4、诊断设备会话保持（0x3E）服务

4.1举例：

5、按标识符读取数据（0x22）

5.1 主要应用与以下场景：

5.2消息请求格式：(dataIdentifier为数据标识符)

6、按标识符写数据（0x2E）服务

6.1服务的可能用途有：

6.2 数据请求格式：

​编辑

6.3受支持的否定响应代码：​编辑

三、总结

---

一.ISO-14229 UDS

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

ISO 14229(Unified Diagnostic Services)简称为UDS

U代表统一，不限定总线

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

S代表服务，诊断服务

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

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

1.1 UDS的结构层次

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

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

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

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

1. 物理层（Physical Layer）：

        - 涉及物理连接和电气特性，如电压级别、连接器类型和电缆规格。

2. 数据链路层（Data Link Layer）：

        - 确保数据的可靠传输，包括帧的构建、错误检测和必要的重传机制。

3. 网络层（Network Layer）：

        - 负责数据包从源到目的地的传输，以及网络拓扑的管理。

4. 传输层（Transport Layer）：

        - 提供端到端的数据传输服务，确保数据的顺序和完整性。

5. 会话层（Session Layer）：

        - 管理和控制两个通信系统之间的会话连接。

6. 表示层（Presentation Layer）：

        - 确保数据能够被接收系统理解，包括数据的编码、解码和数据格式转换。

1.2 诊断服务基本知识

        汽车诊断首先由Tester（诊断仪）向ECU发送诊断服务请求（Request），ECU则向Tester发送对应服务请求的响应（Response）。

六个服务原语，即，请求、请求确认、指示、响应、响应确认和确认。

对于 ISO 14229 本部分定义的所有服务，请求和指示服务原语务必使用相同的格式和参数。因此，对于所有服务，请求和确认服务原语（除 req_confirm（req_确认）和 rsp_confirm（rsp_确认）外）必须使用相同的格式和参数。

诊断服务通常是指在应用层的服务，应用层服务用于基于客户端-服务器的系统。

诊断应用层服务访问点对于各服务，规定了六种服务原语：

服务请求原语：由诊断测试仪应用程序内客户端功能使用，用于向诊断应用层传输请求诊断服务相关数据；
服务请求-确认原语： 由诊断测试仪应用程序内客户端功能使用，用于指示服务请求原语传输的
数据通过车辆通信总线（连接至诊断测试仪）成功发送；
服务指示原语：由诊断应用层使用，用于将数据传输至 ECU诊断应用程序服务器功能；
服务响应原语：由 ECU 诊断应用程序内服务器功能使用，用于向诊断应用层传输请求诊断服务
相关数据；
服务响应确认原语： 由 ECU 诊断应用程序内服务器功能使用，用于指示服务响应原语传输的
数据通过车辆通信总线（ECU接收器诊断请求）成功发送；
服务确认原语：由诊断应用层使用，用于向诊断测试仪应用程序内客户端功能传输数据。如下图

请求过程：
test发送诊断请求 ——>客户端进行请求确认——>ECU接收到消息后发送指示原语 ——> 对诊断请求进行处理——>并得到诊断消息——>激活响应原语——>向test发送报文——>并进行响应确认——>test进行确认

二、诊断服务概览

1、UDS诊断包括6大类，26种服务，每种服务都有自己独立的ID，即SID（Service Identifier）

2、常见NRC码

3、不同会话支持的服务（会话优先级）

三、寻址方式

        UDS诊断服务是实现人或设备与ECU控制器交流的一种语言，在总线上往往有着众多ECU设备，作为诊断设备既可以与所有的ECU一起沟通，也可以指定某一个ECU单独沟通。寻址方式就有功能寻址（Functionally Addressed）和物理寻址（Physically Addressed）两种。

1. 功能寻址：即广播诊断请求Request，同时等待总线上的ECU给与响应。
2. 物理寻址：指定发送特定诊断请求Request，等待指定ECU给与响应。 

 四、特殊详情介绍

1、诊断会话控制（0x10）服务

0x10服务的请求（request）共需要两个byte，第一个byte是SID，第二个byte是sub-function，用于指示ECU将进入的session。

session具体含义：

ECU内部应始终且仅有一个激活的诊断会话，当UCU重启后会进入默认会话，且不需要超时处理。

• 当用户请求重新启动默认会话时，则服务器应该完全重启初始化默认会话（非易失性存储器除外）。
• 当用户请求从默认会话跳转到其他非默认会话时，服务器会停止默认会话期间的相应并通过0x86服务在服务器中配置其他服务。
• 当用户请求在其他非默认会话间跳转时，则服务器会对这些会话就行重新初始化。
• 当用户请求从非默认会话跳转到默认会话时，服务器会启用安全性校验，终止默认会话中不支持的诊断功能，服务器将会通过0x86服务配置默认会话。

1.1响应实例：

        以CAN帧举例，由于CAN帧一共8个字节，且第一个字节被网络层占用，所以我们实际的服务ID是从第二个字节开始的。

• 例如Tester请求进入01子服务：

        Tester：02 10 01 00 00 00 00 00
        ECU：06 50 01 00 32 00 C8 00
        该回复表明ECU进入01子服务成功！

• 例如Tester请求进入02子服务：

        Tester：02 10 02 00 00 00 00 00
        ECU：03 7F 10 7E 00 00 00 00
        该回复表明ECU进入02子服务失败！

• 例如Tester请求进入03子服务：

        Tester：02 10 03 00 00 00 00 00
        ECU：06 50 03 00 32 00 C8 00
        该回复表明ECU进入03子服务成功！

1.2实例说明：

 请求数据格式：02 10 02 xx xx xx xx xx ，其中02是网络层单帧SF，表示应用程包含两个字节，10表示为10服务ID，02是子功能–进入编程会话

回复数据格式：XX 50 02 xx xx xx xx xx ，XX表示应用层含XX个字节，50 = 10 + 40表示SID的肯定回复，02是子功能，xx xx xx xx xx为具体数据。

回复数据格式：03 7F 10 7E xx xx xx xx ，03即应用层包含三个字节，10是SID，7E是NRC（否定响应码）。

2、ECU 重置（0x11）服务

2.1客户端使用 ECUReset（ECU重置）服务来请求服务器重置。

sub-function值：

肯定响应消息格式：

其中：sub-function = [ resetType ] powerDownTime为断电时间

2.2举例：

• 例如Tester请求进入01子服务：

        Tester：02 11 01 00 00 00 00 00
        ECU：02 51 01 AA AA AA AA AA
        该回复表明ECU进入01子服务成功！

• 例如Tester请求进入02子服务：

        Tester：02 11 01 00 00 00 00 00
        ECU：03 7F 11 12 AA AA AA AA
        该回复表明ECU进入01子服务失败！因为并没有开发配置11 02服务，所以没有02 子服务。

• 例如Tester请求进入03子服务：

        Tester：03 11 01 03 00 00 00 00
        ECU：03 7F 11 13 AA AA AA AA
        该回复表明ECU进入01子服务成功！请求报文的长度为3字节，正确情况只需要2字节即可

3、安全访问（0x27）服务

    3.1不同等级的安全访问（sub-function整车厂自己定义）

完成SecurityAccess 有以下步骤：

• 诊断仪向ECU请求“Seed”（通常是一个与时间相关的伪随机数）
• ECU向诊断仪发送“Seed”
• 诊断仪向ECU发送“Key” (根据请求得到的Seed和一个本地的密码进行计算得来)
• ECU判断诊断仪发来的“Key”是否有效

其中功能参数定义：

3.2举例：

• 例如Server在Locked状态：

        Tester：03 27 01 00 00 00 00 00
        ECU：04 67 01 36 57 AA AA AA
        Tester：03 27 02 C9 A9 00 00 00
        ECU：02 67 02 AA AA AA AA AA
        该回复表明首先Tester请求Seed ，Server回复肯定响应，并返回Seed ，然后Tester请求Key ，Server回复肯定响应。

• 例如Server在Unlocked状态：

        Tester：03 27 01 00 00 00 00 00
        ECU：04 67 01 00 00 AA AA AA
        该回复表明首先Tester请求Seed ，Server回复肯定响应，并返回全0数据，表明目前已经处于解锁状态，不再返回Seed 

任何时间都仅可有一个安全级别处于活动状态

4、诊断设备会话保持（0x3E）服务

这个服务的目的是保持当前的非默认（Default Session）会话，通过周期地发送请求帧来阻止自动跳转回默认（Default Session）会话。

请求消息格式：SID+sub-function

4.1举例：

        Tester：02 3E 00 00 00 00 00 00
        ECU：02 7E 00 AA AA AA AA AA

        Tester：02 3E 80 00 00 00 00 00
        ECU：不回复

子功能字节为0x80表示服务器不能去发肯定响应，即使服务器正常去响应请求，也不能发肯定响应消息。

该服务除了具有确定服务端是否在线的操作外还能通过周期的向服务器发送请求消息让服务器保持在非defaultSession诊断会话状态。

具体实现如下：
将诊断会话计时器S3server中记录的还没有超过5000ms的事件记录清楚，让它再从0开始计时，这时要想回到默认会话就要再等5000ms。

5、按标识符读取数据（0x22）

5.1 主要应用与以下场景：

• 读取当前ECU的序列号，版本号等；
• 标定成功后读取内部标定结果等；
• 读取当前ECU所处在的Session，内部状态，Snapshot Data等；
• 其他需要读取内部相关参数的场合；

5.2消息请求格式：(dataIdentifier为数据标识符)

肯定响应格式如下：

6、按标识符写数据（0x2E）服务

        按标识符写数据服务允许客户端向服务器中给定数据标识符指定的内部位置写入信息。

6.1服务的可能用途有：

• 将配置信息编入服务器中（如 VIN）；
• 清除非易失性存储器；
• 重置所得的值；
• 设置选项内容；

6.2 数据请求格式：

6.3受支持的否定响应代码：

三、总结

        本文主要基于14229协议介绍UDS常用诊断服务，服务子功能及对应服务支持的NRC码。诊断服务的内容实在太多，挑选了重要部分进行总结。