大白话给你讲明白UDS诊断(汽车诊断服务 实例应用图文讲解）（二）

上一篇，我已经讲了UDS诊断作用以及为什么要这个东西。我这里再补充一点点，在整个ECU软件架构里面，诊断程序（诊断功能）只是占了一小部分，但是也是非常重要的一个部分。
我这里做了一个简图示意

好，我们继续讲解ISO 里面的服务，上一篇我讲了10的服务应用和实例应答，现在接着讲11服务
11服务ISO里面英文为****ECUReset (0x11) service

很容易我们从字面意思可以知道，这个是为了ECU重启的服务，如果ECU设计有这个功能，而且这个功能还能正常运行的话，诊断仪可以通过这个服务要求ECU重启。这样检修人员可以不需要去拔电瓶或者去按ECU的复位键，开玩笑，ECU一般没有复位键的。

11服务的子功能也可以有很多种，也是根据需求去设计，比如，软复位，这个情况下ECU没有断电，还有硬复位，这个ECU相当于从断电到通电的状态启动。至于你用什么方式实现这个功能，是由上层应用决定。
这是怎么理解呢？回本篇最开始的示意图，
具体的实现功能就是某个function。诊断仪请求这个11 01/11 03服务后，ECU会调用相应的function达到重启的目的，你可以是看门狗复位也可以是控制电源断电复位等方式。
换句话说，UDS诊断11服务只是开了一扇门给你，具体你要进去做什么，由上层应用实现。

实例演示

诊断仪给ECU发送了02 11 01的命令，02我们说过是长度。
ECU收到这个命令后，执行了重启的动作，然后给诊断仪回复了02 51 01，51就是请求的ID 0x11+0x40
也有另外一个重启动作是，先回复02 51 01 再执行重启动作。
其他命令比如 11 03 硬复位等类似，

实例模拟长度不对的情况

ECU检测到长度不对，就会给出负响应，响应帧7F 11 13

11服务应该是比较好理解，就是重启! 因为一些特殊情况下，我们是要求ECU做一些重启的动作。
以上这些都是针对物理寻址做的测试。功能寻址需要设置服务支持，用功能寻址才会有响应

接下来我们看下一个服务，如果没有特殊的说明，我们接下来都是用物理寻址的方式进行实例讲解。
下一个

SecurityAccess (0x27) service 0x27服务，字面理解是安全访问服务。
为啥要这个服务呢？
我来觉举一个例子，汽车的VIN码，这个相当于汽车的身份证，这装车后，是不允许修改的。那么我们在出厂设计的时候，又需要写入VIN码，那就需要先得到对应的访问权限才能操作。我这里要讲的27服务就是为这种情况诞生的。

那他是怎么运作的？
上实例

细心的读者，发现我先给ECU发送了10 03的命令，10 03 我们在10服务说了是session ctrl ，权限控制的，因为我们设置了27服务之有在10 03 的扩展会话中才会生效，我们这些例子都是正儿八经实际项目的报文截图，极具参考价值，从项目中实际感受下这些服务逻辑用途，本人自学的时候，可没有那么幸运****如果没有这样的设定，在默认 10 01 也可以使用27服务。
待会话ECU切换成功正响应后，诊断仪发出了 27 01这个命令，这个命令是请求一个seed，这个seed你可以理解为ECU按照一定的算法给诊断仪发出的随机码。
67 01 03 04 0A 01这就是ECU对27 01的相应，ECU回的Seed 有四个字节‘03 04 0A 01’
诊断仪会收到这四个字节，然后用他们计算出对应的key，这里算出来是00 00 00 00 ，实际上不可能是4个0 ，我这边做演示给了4个0 ，通过27 02命令带上4个Key 27 02 00 00 00 00 转给ECU，27 02是诊断仪让ECU比较Key. 验证两边的算法是不是一致的。如果是一致的，ECU就会回一个正相应，如图所示 67 02

这个过程就像是对特务对暗号一样，”宫廷玉液酒“ 下一句是啥？”一百八一杯“对的上就是自己人，对不上就是棒槌了，这个暗号(算法)是可以由整车厂自己设定。

通过了，ECU就放开权限给你做相对应的操作，对不上就直接拒绝，这就是27服务安全访问的过程。

28服务 通讯控制
CommunicationControl (0x28) service
直接看实例报文截图

这个就是28服务控制命令的收发图，可以看到我也是先发送了；10 03命令，因为我在设定28服务是在扩展回会话里面才生效的，如果是10 01 默认会话下是报错的，
我们上图看下，会更容易理解

这里回复的是7F 28 7F，第一个7F前面已经讲过，第二个7F是“serviceNotSupportedInActiveSession”
就是服务在这个会话下面不支持！
所有的NRC解释在ISO14229 里面都有解释，
章节参考Negative Response Code (NRC) definition and values

回到之前上一张图，我下发了命令28 00 03，其中28是服务ID，00是子功能，参考一下14229里面的对照表
Table 54 — Request message sub-function parameter definition

00子功能是使能 RX TX，也就是允许CAN 的正常收发。01 02 03 自行查阅英文意思。
03是通讯控制类型，有那些类型呢，请看下如图

常用的有三种，我们这命令带的03是 网络和普通报文
正常情况下，发送诊断仪发给ECU 28 00 03 ECU是不会做出变化的。
但是如果你发送的是 28 03 03 子功能换成了 禁止RX TX，那么这个时候，ECU的 CAN通讯的RX TX就会停止，我们看下实例截图

同样的，在扩展会话进行，发送命令 28 03 03 给ECU，ECU回复了一个68 03正响应，如果功能正常的话，CAN分析仪里面就会发现ECU发送 接收的报文已经停止，如果我们在发送让他恢复通讯的命令 28 00 03 这个时候ECU 通过CAN TX RX功能又会恢复。有人会问，这个有什么用？
这个用处目前我觉得最有用的就是可以排除一些干扰的报文，比如调试CAN驱动是非常友好的。

继续下一个服务
TesterPresent (0x3E) service 3E服务，这个服务是诊断在线的服务
它主要的目的就是告知ECU，我的诊断仪一直链接着，没有断开。我们使用的时候主要是让他维持在某一个session，因为ECU在非默认会话的时候，内部是有计数器的，超时就会自己跳转默认会话，如果诊断仪一直发着这个3E,就能让ECU维持这个会话，当然，发送的周期，要小于ECU会话超时跳转的时间才有意义。看下实例

诊断仪在线就会一直的发送3E 00给ECU。

下一个服务
AccessTimingParameter (0x83) service
SecuredDataTransmission (0x84) service
这两个服务我从事项目几乎没用过，暂时跳过不讲。有兴趣自己看

我们讲一下85服务
ControlDTCSetting (0x85) service DTC控制，这个是怎么理解呢，看下实例

这个服务也是在扩展会10 03话进行，我发送了85 01 ，是告诉ECU你可以恢复你的正常DTC记录状态，DTC是啥？是故障码，我前面的篇幅有介绍。
那么有恢复肯定有暂停，那暂停DTC记录是那个，实例截图

暂停DTC记录是85 02命令。为啥要这个功能？

假设我们ECU在全速传输大批量数据，比如是升级的数据，那么报文中可能会包含很多的固件数据，这时候我们要避免ECU误以为这是数据是有故障的而吧故障码记录下来，因此在这种情况下，就告诉ECU，我正在做升级，无论什么数据来了，你都不要去解析和记录，等我告诉你可以记录的时候你在记录。

ResponseOnEvent (0x86) service
LinkControl (0x87) service
这两个服务用的也很少，跳过。

重点看下下面这个服务
ReadDataByIdentifier (0x22) service 读DID的22服务
DataByIdentifier 简称DID，DID就是一个标识符号，如果把22服务比作一个酒店，那么DID就好比酒店的房间号码。 诊断仪通过22服务就能获取到DID里面的信息。DID可由客户制定和定义。DID一般由2个字节组成，比如我们习惯用的0xF190 这个DID存放VIN码，0xF191存放硬件版本信息等等，如下表
有人就说那我定义0x1000,存放VIN不行吗？
可以，没问题，以上的表格只是多数汽车厂家大家约定俗成的用法，不是强迫一定这样用。

举个实例
我发送命令读取DID 0xFA00 的数据，ECU回复正响应，62 FA 00 03, 03就是读出来的内容
这个可以在默认会话读取，因为我在程序里面没做session限定。

ReadMemoryByAddress (0x23) service
ReadScalingDataByIdentifier (0x24) service
ReadDataByPeriodicIdentifier (0x2A) service
DynamicallyDefineDataIdentifier (0x2C) service
这四个用的少，读法类似22不在细说。

说完读的，我们看下怎么写这个，看服务2E
DIDWriteDataByIdentifier (0x2E) service
这个就是写DID的方法。和22反过来需要吧写入的数据带在DID后面，看下实例

哎，这是个负向响应，为啥呢？
因为我这边没有做这个DID写入的功能，因此我想在0xF191写入00的时候，ECU给了负响应，告知诊断仪，你写入的DID不存在
正常的话，如果已经做了DID写入接口，ECU回的正响应，应该是6E F1 91

WriteMemoryByAddress (0x3D) service
这个用的也少，跳过

来看一个重要的服务14
ClearDiagnosticInformation (14 hex) service这个是清除故障码DTC的服务
前面我们讲过诊断仪可以清除故障码，就是靠的这个服务。
看下实例应用

控制命令发送格式是14 FF FF FF 这后面三个FF代表的是高 中 低所有的数据，全部清除

ECU正相应就一个字节 54

接下来到最复杂也是很重要的一个服务了 19服务
ReadDTCInformation (19 hex) service这个是读取DTC的服务，为什么说它复杂，因为它能使用的子服务和参数非常的多，ISO14229里面篇幅是最长的一个，新手进来很容易迷失，老鸟也差不多，经常得翻看规格，我这边介绍里面常用的几种读取方式，如果你读懂了，基本能覆盖85%的项目应用了。
第一个19 01通过状态掩码报告DTC数量
状态掩码是什么意思，这就需要补一下DTC的知识，DTC有不同的状态，如下图，有8个状态喂位
实例演示，19 01 01，最后一个01是 Test file的状态位，如果ECU有支持的DTC这一位被置起为1，这个数将会累计

ECU回复59 01 89 02 00，59是响应19服务，01是子服务，89是支持的DTC状态位。后面的00 00 是数量。

继续看02子服务，实例操作

诊断仪发送19 02 08给ECU，通过状态掩码报告DTC信息，诊断仪问ECU，有没有状态位为08的DTC？
ECU回复59 02 89，没有更多的信息，证明ECU现在没有与08状态相匹配的DTC故障。

**再看04子服务，**在对应故障发生时，ECU端要记录发生故障时的快照信息；而04服务就是用于请求指定故障码（DTC）的快照信息，通过查找故障发生时刻的这些数据，来分析故障原因
发送请求命令为19 04 92 08 13 01，92 08 13是DTC码，查询快照的记录号码是02，
ECU回了一个负响应，因为ECU没有设计支持这个子服务，正常应该是回复92 08 13快照信息

**再看06子服务，**除了前面04服务中介绍到的快照信息；一般还会再定义一个扩展信息，用于记录故障的一些其他信息，比如故障发生的次数、老化次数、已老化次数等。而将下来介绍的06服务就是用于请求指定故障码（DTC）的扩展信息
发送请求命令为19 06 92 08 13 01，92 08 13是DTC码，查询扩展的记录号码是01，也就也就是老化循环次数。
ECU回复59 06 92 08 13 00 ,最后一个就是次数，这里是0.

最后一个0A子服务。
这个比较好理解，就是吧ECU支持的所有的故障码和状态统统读出来，也就是前面的集合。演示一下

诊断仪发送了19 0A,
ECU回复数据很多，后面的数据就是他支持的所有的DTC和每个DTC的状态，点开数据可以进行详细分析，我这个CAN首发工具是CANOE 11

下一个服务
InputOutputControlByIdentifier (0x2F) service
这个服务用的频率也很高，这个是做功能控制的。比方说我吧机器装好到车上了，需要测试一下电机的转动角度，已经不方便用调试器等工具了，那就可以通过这个服务和对应的功能实现。
看下实例

同样是需要在扩展会话进行，诊断仪发了2F F0 13 03 00 00，2F是服务ID，F0 13 是需要操作的DID。这个DID跟上一个提到的DID其实也是一回事。最后的03 00 00是参数。
当ECU接收到这个命令，首先解析DID号码，然后获取参数，进行对应的操纵。
上图演示反馈了一个负响应，原因是我这个ECU不支持这个DID F0 13 正常的正响应应该是6F F0 13
再看一个
接着看一个类似的服务
RoutineControl (0x31) service 例程控制
这个功能和2F类似，实际的发送例子是这样的

在扩展模式下，发送了 31 01 FF 01,31是服务号，01是子服务，这里01表示是开始执行， FF 01 是DID
EC反馈是是负响应，因为ECU没有设计这个DID。正响应应该是71 01 FF 01
刚说到子服务 01是开始，那就就有结束，也就是02，这个还有一个反馈的子功能03
看下标准里面的解释

也就是31执行动作可以控制开始，控制结束，和查询执行结果三个基础功能。

RequestDownload (0x34) service
RequestUpload (0x35) service
TransferData (0x36) service
RequestTransferExit (0x37) service
RequestFileTransfer (0x38) service
这几个也会用到，他们是传输用的服务，常用的是在Bootloader 或者是OTA等功能，需要进行数据传输用。因为我这边没有这几个服务功能，实例不做具体演示，但是我给解释一下标准里面的定义

第一个34就是我们的服务ID，第二个字节就是
（1）dataFormatIdentifier

这个参数为1字节长度，高4位表示“compressionMethod”，低4位表示“encryptingMethod” 。如果两种Method都没有用到，则值为0x00。

（2）addressAndLengthFormatIdentifier

这个参数也是1个字节的长度。

bit 7 - 4：参数memorySize的长度（Bytes）

bit 3 - 0：参数memoryAddress的长度（Bytes）

（3）memoryAddress

开始下载数据的起始位置的地址。

（4）memorySize

这个参数用来把传输数据和内存进行对比，这种操作增加了下载数据的安全性。

正相应解析

（1）lengthFormatIdentifier

这个参数为1字节长度。

bit 7 - 4：参数maxNumberOfBlockLength的长度（Bytes）

bit 3 - 0：保留位，设为0

（2）maxNumberOfBlockLength

这个参数用来通知用户在每次数据传输请求中包含了多少字节的数据。

有了以上的基础，后续 35 36 37 38个服务不在细讲，参考14229里面多读两次便可理解