本文持续更新中。。。
前言
对UDS部分缩写和名称不理解的兄弟可以参考我的这篇解释:
概述
UDS诊断共分为6大类28种服务。通过UDS实现对汽车的数据读取以及保存故障环境及其详细数据等。
诊断和通信管理类
0x10——诊断会话控制
10服务,诊断会话控制,用于控制服务器切换不同的会话模式(session)。在不同的 session 下,ECU能够执行的服务类型也有所不同。具体区别如下:
01:默认会话,只有最基础的诊断服务;
02:编程会话,对ECU进行编程和刷写软件等服务;
03:扩展会话,能够提供更多的诊断服务,比如控制DTC和非诊断报文的发送等。
一般情况下,编程会话只支持ECU刷写相关的服务,对其他服务基本都不支持;默认会话基本上可以读取大部分的DID,扩展会话在默认会话的基础上还支持31服务等。
0x11——ECU复位
11服务,ECU复位,根据诊断指令执行ECU重启操作。
01:KL30(车载电池供电,使某些用电功能在汽车未启动情况下也能使用)断电,相当于拔掉电池;
02:KL15(车身供电,相当于车钥匙打火启动)断电,相当于关闭开关;
通过11服务可以进入ECU的BootLoader模式 或在刷写软件结束后重启ECU。因为11服务对ECU的正常工作有极大的影响,所以只有在满足一定条件(比如模拟停车时的状态)时,该服务才能生效。
0x27——安全访问
ECU中一般会有一些数据是不希望被随便调用的,所以会有一层安全验证来阻止对这些数据的调用。如果需要调用这些数据的话,就需要做一个通过种子(Seed)和密钥(Key)实现的交互安全验证。
通过27服务获取数据的调用权限分为三个阶段:
(1)首先,发送方会发送一个 请求种子(seed)的请求;
(2)接收方收到请求之后,如果做肯定响应的话,则会回复 种子(随机数);
(3)发送方收到 种子 之后,会根据算法计算出一个 密钥(key),然后将密钥发给接收方;与此同时接收方也会计算一个密钥,如果这两个密钥相同,则完成验证,可以读取被保护的数据;如果密钥不同,则验证失败。
需要注意的是,请求seed的子服务为奇数,比如 01;相应的,发送key的子服务为偶数,比如 02。
此外,142299协议只规定了一个安全等级,通过01和02两个子服务来实现;其他值比如 02,03之类的都保留给了车厂定义,以满足车厂的需求。
0x28——通信控制请求
在进行ECU刷写的时候(比如升级),如果允许ECU进行正常通信的话,可能会影响刷写过程,导致一些问题发生。通过28服务,可以 开启/关闭 服务器 发送/接收报文。
数据传输类
0x22——通过DID读取数据
22服务,通过在DID读取数据,ECU中存在大量数据,通过DID可以实现读取某些特定的数据,比如车辆型号 之类的信息。一般会由车厂来定义每个 DID 会对应什么信息。一般直接在服务后面接想要读取的DID即可。
0x2E——通过DID写数据
2E服务,通过在DID写数据,一般使用时直接在服务后面接想要写入的DID,然后跟写入的数据即可。
存储数据传输类
0x19——读取故障码信息
当ECU检测到故障发生后,便会记录该故障相对应的故障码(DTC),一般占用3个字节。
正常情况下,ECU 除了DTC还可能存储与该DTC有关的快照信息等。
19服务请求在SID之后会接子服务,常用的子服务如下:
19 02:读取符合某DTC状态的DTC列表及其状态。
19 04:读取DTC发生时的快照数据。
19 06: 读取DTC的扩展数据记录。
0x14——清除诊断信息
该服务主要用于清除ECU中存储的故障诊断信息。该服务可以指定某个DTC或者进行清除。
如果发送 14 FF FF FF ,则会默认为清除所有DTC。
I0控制类
0x2F——通过DID控制输入输出
2F服务,通过DID控制输入输出,该服务能够替换服务器输入的值或者功能。
举个例子,假设当前服务器发出一个信号,其功能是控制风扇开关;通过2F服务改变这个信号的作用,比如通过PWM来控制风扇的转速。
2F服务在实际应用中非常重要,其常用的子服务主要是以下三种:
0x00 将控制权还给ECU ,结束控制
0x01 将DID引用的输入信号、 内部参数、输出信号等设为默认值
0x02 将DID引用的输入信号、 内部参数、输出信号冻结
0x03 将DID引用的输入信号、 内部参数、输出信号等进行设置,开始控制
PS:虽然上面列出了四种,但本人做这部分比较少,只用过 00 和 03服务。