uds2e服务_常用的网络服务

【转自：https://blog.csdn.net/xiandang8023/article/details/125379878】

UDS（Unified Diagnostic Services）协议，即统一的诊断服务，是面向整车所有ECU的一种诊断通信方式，是基于ISO 14229规范的规范化诊断服务标准，其位于OSI模型中的应用层。

1. 26个UDS服务

2. 通讯方式

在使用中，UDS诊断是基于问答形式实现，”请求”由client端发送给server，UDS规定使用1个byte来表示诊断服务，即所谓的Service ID，简称SID。请求报文里带有SID，根据具体的服务内容后面加具体的数据。肯定响应格式由“SID+40+具体的数据”。否定响应格式是一个固定的格式“7F+请求报文里的SID+一个字节的NRC”。

2.1 request

诊断的request格式分2种，一种有sub-function的，一种没有sub-function的。

当 UDS 服务支持 Subfunction 的请求和响应格式时：

• 请求格式为 ：”SID + 一个字节Subfunction + 具体的数据”，肯定响应为”SID+40+Subfunction+具体的数据”。

而有的UDS服务里面是不支持 Subfunction，是支持DID的，DID是“数据ID”的意思，

• 请求格式为：“SID+具体的DID+数据内容”，肯定响应为：“SID+40+DID+具体的数据”。

支持Subfunction和DID：

• 请求格式为：“SID + Sub-Function + DID + 数据。

2.2 response

一般来讲，response会在一个服务被request且执行之后发送，成功的话就发positive response，失败的话要发negative response，但是也有例外的时候，比如ECUreset，他要求先发送response，然后再去执行具体的reset，因为如果先reset，那么ECU的通信模块shut down，是无法发送出去response的。一般像这种特殊情况，协议会在描述具体服务时标注出来。

2.2.1 Positive Response：

基本格式：

• <SID+0x40> + <Sub-function> + <Parameter>
• <SID+0x40> + <Parameter>

比如session control的service：

• Send：10 01（byte1的10是SID，byte2的01是sub-function，且可知Bit 7是false）
• Receive：50 01 （byte1是SID+0x40，byte2是sub-funtion）

不带sub-function的例子，比如ReadDataById这个service：

• Send：22 F1 86（byte1是SID，byte2和byte3是DID，可视为parameter的一种）
• Receive：62 F1 86 01（byte1的62是SID+0x40，byte2和byte3是DID，byte4是读到的数据）

2.2.2 Negative Response：

基本格式:

• <0x7F> + <SID> + <NRC> //NRC：Negative Response Code（否定响应码）

只要是Negative Response，第一字节就一定是0x7F，第二字节照抄原来的SID，第三个字节是错误响应码，指示具体错误响应的原因，这个NRC可以在协议中查到，并且不同的服务所支持的NRC也有规定。

拿 session control 这个service来举例：

• Send：10 05（现在sun-function变为05了，假定系统不支持这个sub-function） 
• Receive：7F 10 12（7F即指代错误响应，10为SID，12是NRC，查协议可知其指代sub-function not supported 这个错误）

3. 常用的六个服务

【转自：https://blog.csdn.net/initiallizer/article/details/126003692】

3.1  10 诊断会话控制

10服务为会话服务，可以使能不同的诊断会话，不同的会话有不同的权限，在ECU上电时，进入的是默认会话（Default），默认会话权限最小，可操作的服务少；扩展模式通常用于解锁高权限诊断服务，例如写入数据/参数、读写诊断码；编程模式用于解锁bootloader相关的诊断服务，即程序烧录。

此外，还给整车厂及供应商提供了自主定义的会话范围，如供应商可以在10 60至10 7E间开发自己使用的会话服务。

 在10服务使用中，如应答为否定应答，则对应的否定NRC代号对应解析：

 3.2  27 安全访问

ECU当中有很多数据是整车厂独有的，从保密性角度考虑，ECU上电之后是一个锁定的状态（Locked），在读取一些特殊数据的时候，要先进行一个安全解锁，我们通过$27服务，加上一个子服务，再加上一个钥匙，这样的服务请求可以进行解锁。
如下图，其中2n-1是一个子服务，其安全访问过程为：
First Step：Tester端向ECU端发送首轮种子的请求，首轮ECU会返回67+2n-1+AA+BB+CC+DD，其中AA~DD就是种子，Tester端会利用种子进行运算（利用整车厂的算法）计算得到k1；
Second Step：Tester端向ECU端发送请求，27+2n+[k1]。ECU同样也会通过种子算出k2。当k1和k2相等时，则解锁（Unlocked），安全访问成功。

在UDS规范中请求种子及发送秘钥对应的子服务如下表：

 3.3  22 通过DID读数据

3.4  2E 通过DID写数据

 与读DID相反的一个服务为2E，该服务可以对DID信息进行修改（对于写数据的请求，一般来说需要在一个非默认会话，和解锁的状态下才能进行），其数据发送的格式如下图：

3.5  19 读DTC信息服务

【转自：https://zhuanlan.zhihu.com/p/555254853】

DTC（Diagnositc Trouble Code），诊断故障码读取是UDS诊断中非常重要的一环，在ECU运行过程中如检测到故障如检测到汽车的三效催化器发生老化，会记录对应的故障码，不同的故障码根据故障严重及危害程度确定是否需要点亮仪表盘的发动机故障灯。

3.5.1 故障码形式及转换

一般看到的故障码，可能有两种形式，注意有时候如果故障码最后两个数字是00，可能显示时会省略掉，这种情况自己补上就行了。

1. 字母开头的，类似于：U041600，P308800，B116220等

2. 全部是数字，类似于：012700，803910，403123等

这两者本质是一样的，如果你的故障码是第二种，那么先按照以下方式将其转换成第一种：

故障码：0x012700，其中0x01、0x27、0x00分别为第1，2，3个字节，转换时只涉及第一个字节，即0x01。

1. 首先将0x01转换为二进制：0000 0001
2. 取最前面两位，按这个规律（00=P，01=C，10=B，11=U）可以转换为：P 00 0001
3. 然后接着两位和最后4位分别转换为16进制数：00：0x0，0001：0x1
4. 最终0x012700转换为：P012700

同理，803910：B003910，403123：C003123

3.5.2 故障码定义

故障码包括四个大类，分别是PCBU，P是powertrain动力系统，C是Chassis底盘，B是Body车身，U是network通信系统。

19拥有28个子服务（Sub-Function）。常用的子服务有02（通过DTC状态掩码读取DTC），04（读取快照信息），06（读取扩展信息），0A（读ECU支持的所有DTC数据）。

ECU在记录故障代码的时候，还会记录故障发生时的一些其他信息，比如车速，时间，环境温度等信息，这些信息就是DTC的Snapshot（快照），主机厂会定义具体的快照信息。

当ECU监测到某个故障信息时，除了记录故障码，还要记录如上的Snapshot数据。操作人员可以通过0x19 服务的0x04子服务读取snapshot。

3.5.3 示例

对照上图，试着推断几个实际的故障码，故障码和其后的文字均是由诊断仪读取到的，其下为根据故障码的定义尝试推导的信息：
格式说明： 故障码，[发生该故障的控制器]，故障码文字描述。这些内容均从诊断仪中读取。

• U041600，[发动机控制器]，ESP不可信信号

网络系统故障（收到的ESP信号有问题，所以归到网络系统） -> 通用故障码 -> 排放系统 -> 16故障 -> 00表示无进一步信息，因为U0416已经能够确认故障组件，该故障在ISO15031中已有明确定义。

• C101C4A，[制动电子装置]，左后轮轮速传感器-部件安装不正确

底盘系统故障 -> 整车厂特有故障 -> 未区分故障系统 -> 1C故障 -> 系统内部故障 -> 部件安装不正确

另外，为什么诊断仪能够显示具体的故障信息？这是因为诊断仪在使用时会导入一个ODX文件（可以当成一个数据库，里面存放了控制器支持的故障码），当诊断仪读到故障码的时候，根据这个故障码去ODX文件里查询，如果有这个故障码条目，就把对应的文字描述从ODX文件中拿到，然后显示出来。

3.6  14 清除DTC诊断信息服务

清除（复位）DTC格式，它可以改变DTC的状态。3个FF代表清除所有DTC。

3.7 应用层寻址方式

功能寻址— CAN总线上所有集成诊断功能的ECU均对请求报文给出响应（一对多），例：11-请求所有ECU重启 28-请求所有ECU关闭通讯报文。
物理寻址— 指定的控制器对请求报文给出响应（一对一）例：22，2E-每个ECU的数据流种类定义不同，只能一一读取/写入。34、36、37-针对一个ECU刷写，不支持功能寻址。

今天的文章uds2e服务_常用的网络服务分享到此就结束了，感谢您的阅读，如果确实帮到您，您可以动动手指转发给其他人。