ISO14229 -1 UDS诊断服务记录-001：0x34\0x36\0x37\0x31\0x19\0x14服务报文格式介绍

目录

1、34服务-请求下载

1.1、诊断请求格式

1.2、正响应格式

1.3、负响应格式

1.4、工程应用分析

2、36服务-传输数据

2.1、请求报文格式

2.2、正响应格式

2.3、负响应NRC

3、37服务-退出传输

3.1、报文格式

3.2、正响应格式

3.3、负响应NRC

4、31服务-例程控制

4.1、报文格式

4.2、正响应格式

4.3、负响应NRC

5、19服务-读取DTC信息

5.1、报文格式

6、14服务-清除DTC

6.1、报文格式

7、签名验证

7.1、软件签名及验签方法

7.2、创建指纹数据块

7.3、数据签名

7.4、RSA-PSS填充

7.5、数据解签

---

1、34服务-请求下载

1.1、诊断请求格式

dataFormatIdentifier

        高位表示“Compression Method”，低位表示“Encryption Method”。0x00表示不使用Compression Method和Encryption Method，非0x00值由主车厂自定义。

        Compression Method：压缩方法

        Encryption Method：加密方法

addressAndLengthFormatIdentifier

        bit 3-0表示memoryAddress参数字节数，bit 7-4表示memorySize参数字节数。（一般为0x44表示4个字节地址，4个字节数据长度）

memoryAddress

        该参数指定了block在MCU PFlash上写入的起始地址。此处提到的block指的是bootloader、application、标定数据块、指纹信息（包含每个block的起始地址和长度以及相应的hash摘要，用于验签操作）等。在刷写时，会将这每个software part当作一个block刷入到MCU的Flash上。该block与0x36所提到的block不是同一个概念。

如下就有6个地址空间

memorySize

        该参数指定了要写入的block的Size大小。

        报文格式举例如下

        44：表示4字节地址4字节长度

        00440000：地址

        000310B8:数据长度

1.2、正响应格式

lengthFormatIdentifier

        该参数是一个单字节值，每个nibble分别编码:

        bit 7 - 4: maxNumberOfBlockLength参数的长度(字节数)。

        bit3 - 0:由文档保留，设置为“0”

        此参数的格式与请求消息中包含的addressAndLengthFormatIdentifier参数的格式兼容，只是必须将较低的小块设置为“0”。

maxNumberOfBlockLength

        该参数指定了可以通过0x36服务一次传输的最大数据量。

        若该参数为0x82，也就是说每次通过0x36服务只能最多发送130个字节，其中还包括了SID和blockSequenceCounter，所以说实际上每次可传的数据信息只有128个字节。

        上述截图20中的2表示两个字节 00 82 也就是130字节，其实也就是传输128字节。128字节如下图所示传输示例。

以上地址空间为S32K3的例子。

1.3、负响应格式

1.4、工程应用分析

        在0x34的service handler中会对请求中的memoryAddress和memorySize进行校验，也就是规定了要写入PFlash的block要在所限定的地址范围内（OTA使用）。

        如下示例所示，需要在配置工具中针对相应的block配置地址范围。若要写入的block的地址与所配置的不匹配，则会返回NRC31 (requestOutOfRange)。针对Allowed Write Security levels也需要进行配置。

        下图是英飞凌的例子

2、36服务-传输数据

2.1、请求报文格式

blockSequenceCounter

        块序列计数器占一个字节，0x34服务后，发送的第一个0x36服务请求的blockSequenceCounter为0x01。之后，每发送一次0x36服务请求，blockSequenceCounter就加1。当增加到0xFF后，下次发送0x36服务请求时blockSequenceCounter = 0x00。

transferRequestParameterRecord

        字节长度和参数格式不定，由厂家制定。

        正常格式如下

2.2、正响应格式

blockSequenceCounter

        对0x36服务请求中的blockSequenceCounter的响应一一对应的。

transferResponseParameterRecord

        0x36服务用于下载数据时，该参数为非必选项。

2.3、负响应NRC

3、37服务-退出传输

3.1、报文格式

transferRequestParameterRecord

可选参数，由厂家定义

3.2、正响应格式

3.3、负响应NRC

4、31服务-例程控制

4.1、报文格式

sub-function

        子功能，用于指定对例程的操作动作，有以下三种可选项：

        -- 0x01: startRoutine（启动例程）

        -- 0x02: stopRoutine（停止例程）

        -- 0x03: requestRoutineResults（请求例程结果）

routineIdentifier

        例程标识符，由两个字节组成，用于指定要控制的例程。部分例程标识符是由ISO定义，部分则是由主机厂或者供应商定义。

routineControlOptionRecord

        例程控制可选参数，用于携带其它信息，比如启动条件、退出条件等，一般可以不填。

4.2、正响应格式

routineInfo

        一般写个00表示通过，01表示失败。表示条件类的，例如行车过程中禁止升级等。与负响应有很大区别的。

routineStatusRecord

        可选参数，用于在执行相应例程操作后，返回ECU相关信息（例如，通过0x31 02服务停止例程中，ECU可以通过该参数返回该例程总运行时间等信息）。可根据实际需要进行使用，一般较少用到。

4.3、负响应NRC

一定要注意响应的优先级。

5、19服务-读取DTC信息

        用户通过请求该服务，读取ECU的故障诊断码(DTC)信息，服务的sub-function代表了各式各样读取DTC的方法，UDS给19服务的sub-function从0x00到0x19进行了明确定义。

作用：

        0x19服务的主要作用是读取存储在ECU中的故障码信息。这包括故障码的标识符、故障码的状态、故障码的严重性等信息。

        通过读取故障码信息，工程师可以了解车辆存在的问题，识别需要进行维修或故障排除的系统，并采取适当的措施来解决问题。

首先看一下故障的状态掩码的解释

bit 0 :  testFailed

        指示最近执行test的结果，test失败置1，但是它不一定被ECU存储到EEPROM中，只有当bit2或bit3被置1时DTC才会被存储。test通过则置0，如果调用了14服务清除DTC的话，也需要重新置0

        “0”= DTC测试的最新结果表明未检测到故障。

        “1”= DTC测试的最新结果表明了一个成熟的失败结果。    

bit1：testFailedThisMonitoringCycle

        该位表示在当前test中，诊断test是否已经报告了一个testFailed结果。当新的检测循环开始时，这个位需要置0，在调用了14服务后也需要置0。如果该位置1，那么一直保持置1状态直到新的检测循环开始，因此bit1可以理解为当前DTC。如果bit2和bit3通常一起使用。

        “0”= testFailed:在当前操作周期内或在当前操作周期内调用ClearDiagnosticInformation后，尚未报告testFailed结果。

        “1”= testFailed:在当前操作周期中至少报告了一次testFailed结果。

bit2：pendingDTC

        根据ISO 14229的定义，当一个test结束时，若某个DTC满足故障触发条件，则bit2置1。bit2位其实是表示DTC处于testFailed和confirmedDTC之间的一个状态，称为待定DTC。因为DTC并不是一达到触发位就会被报出来的，而是故障出现一段时间后才会被确认，而中间的这个状态就用bit2位来表示，因此bit2位又可被称为待定DTC。当某个DTC刚达到判定条件的时候，bit2被置1，若一段时间后故障条件不满足了，则bit2置0，若一段时间后故障仍然存在，那么bit3就要置1了。

        “0”= 在完成测试完成且未检测到故障的操作循环后或调用ClearDiagnosticInformation服务时，该位应设置为0。

        “1”= 如果在当前操作循环中检测到故障，则该位应设置为1并锁定。

bit3：confirmedDTC

        当bit3置1时，说明故障已经发生了一段时间，也就是bit2至少有一次被置1了。需要注意的是，bit3置1的时候，DTC被存储在EEprom中，但并不代表现在故障还存在，所以可以理解为历史故障。在调用14服务清除DTC后需要置0。

        “0”= 自上次调用ClearDiagnosticInformation后，或在满足故障诊断码的老化条件（或由于故障记忆溢出而清除了故障诊断码）后，从未确认过故障诊断码。

        “1”= 自上次调用ClearDiagnosticInformation后至少确认一次的DTC，且尚未满足老化标准

bit4：testNotCompletedSinceLastClear

        因为并不是所有的DTC测试都是从上电就开始的，所以该位用来表示上次调用14服务清除诊断消息后，是否进行过完整的test。如果进行了完整的test，无论结果如何，都置0，否则置1。

        “0”= 自上次清除诊断信息以来，DTC测试至少返回一次测试结果（无论通过或失败）。

        “1”= 自上次清除诊断信息后，DTC测试尚未运行到完成。

bit5：testFailedSinceLastClear

        该位表示在上次调用14服务清除后DTC后，若test DTC未进行测试或者测试了但结果是pass时置0，如果test运行完成并且返回结果为fails，那么该位置1。在调用14服务清除DTC后需要置0。bit4和bit5通常一起使用。

        “0”=自上次清除诊断信息后，DTC测试未显示失败结果。如果满足老化阈值或发生故障记忆溢出，则车辆制造商应负责将该位重置为零（“0”）。

        “1”=自上次清除诊断信息以来，DTC测试至少返回一次失败结果。

bit6：testNotCompletedThisOperationCycle

        该位表示在当前检测循环周期过程中DTC test是否完成，若完成了置0，未完成置1。在调用ClearDiagnosticDTC后需要置1。

        “0”= DTC测试在当前驾驶循环期间（或自上次在当前操作循环期间清除诊断信息以来）完成。

        “1”= 此操作循环（或自上次清除此操作循环的诊断信息后），DTC测试尚未运行到完成。

bit7：warningIndicatorRequested

        该位报告警告指示，比如说仪表盘上的警示灯等。但不是所有的DTC都会有警告指示，如果没有和DTC相关的警告存在，该位应置0；如果该DTC有相关警告指示，bit3置1的时候，bit7也要置1。在调用14服务清除DTC后需要置0。

5.1、报文格式

Service ID (SID): 0x19

请求示例1：19 01 / 19 02

19 01 09  => 根据状态掩码0x09读取匹配的DTC数量

19 02 09  => 根据状态掩码0x09 读取匹配的DTC

19 01正响应格式

19 02正响应格式

对应了以下报文

请求示例 2： 19 04

        19 04 00 0101 41 FF  => 假设0x000101 是设置的转向灯故障码名称，FF代表读取所以快照数据。读取转向灯故障发送时的快照信息

        在此格式下，Service ID + Sub-Funtion + DTCMaskRecord (三个字节) + SnapshotRecordNumber

19 04响应格式

请求示例 3： 19 06

        19 06 C1 40 41 FF => 读取转向灯故障发送此时信息

        与19 04 格式类似，区别在于最后一个字节时DTCExtDataRecordNumber, DTC扩展数据记录编号。

请求示例 4： 19 0A

        发送指令19 0A，读取ECU支持的所有DTC列表以及各DTC的状态。

6、14服务-清除DTC

        当请求该服务之后，ECU回复正响应，即使没有存储任何DTC故障信息。若ECU支持内存中多份DTC状态信息副本（例如：一份存在RAM里，一份存在EEPROM里，当然大部分是用flash模仿EEPROM的功能），则ECU会清除0x19 Sub-function 02的服务（ReadDTCInformation）请求的信息副本，即RAM中的那份。

通过本服务重置/清除的DTC信息包括但不限于以下各项数据：

        1，DTC状态字节

        2，捕获的DTC快照数据

        3，捕获的DTC扩展数据

        4，其他特定于DTC的相关数据，如最近的DTC，标志，计数器，计时器等。

6.1、报文格式

Service ID        Group of DTC

14               XX XX XX

第一个字节就是SID，

后边的三个字节 用于标识将要被删除的DTC种类，UDS规定用FF FF FF表示所有种类的DTC，由厂家自定义代表Powertrain、Chassis、、Body、Network Communication等种类DTC的值。

通常，该服务请求请求报文为14 FF FF FF：清除所有存储的DTC信息。

例如：

TX   04 14 FF FF FF 00 00 00

RX   01 54 AA AA AA AA AA

7、签名验证

7.1、软件签名及验签方法

        签名验证的目的在于确认OTA升级包来源的可靠性。

        ECU软件签名与验签的整体流程可以分为创建指纹数据块、数据签名和数据解签这三个步骤。其中，创建指纹数据块和数据签名的操作由外部工具链执行，数据解签的操作由ECU执行。流程示意图如下所示：

7.2、创建指纹数据块

        指纹数据块，顾名思义，就是包括了整个OTA升级软件包的特征信息。OTA升级包中通常包括Bootloader、Application、Calibration Data等Software Part Block。这里提到的Software Part Block指的是一个地址上连续的block，可以通过在链接脚本中设置填充的方式使其地址连续（例如，Tasking中的fill关键字），如下所示：

memory Bootloader
{mau = 8;size = 256k - 256 - 16k;type = rom;fill = 0x00000000;map     cached (dest=bus:sri, dest_offset=0x80040100,           size=256k - 256 - 16k);map not_cached (dest=bus:sri, dest_offset=0xa0040100, reserved, size=256k - 256 - 16k);
}

        然后通过Hash算法（例如SHA256）针对每个Software Part Block计算出相应的Hash摘要。接着将Software Part Block的数目、每个Software Part Block的起始地址、大小、Hash摘要都按顺序进行排列，从而创建出一个新的数据块。这个数据块就称为指纹数据块。

7.3、数据签名

        此处以RSA-PSS算法进行介绍签名流程，RSA算法采用RSA2048，Hash算法采用SHA256。下图展示了生成签名的整体流程。

M

输入消息，此处即为Fingerprint Data Block。

H

Fingerprint Data Block通过SHA256算法计算得到的Hash摘要，其大小为32个字节

EM

32个字节大小的Hash摘要通过PSS算法进行填充后得到的大小为256个字节的加密消息。

S

EM通过使用RSA2048中的私钥K1签名后生成的大小为256个字节的数字签名。

7.4、RSA-PSS填充

RSA-PSS填充

        RSA2048算法中的输入和输出的大小都为2048 bit（256 Byte），所以需要使用一种填充算法将32 Byte的Hash摘要填充成为256 Byte的消息。

        下图展示了PSS算法进行填充的流程示意图，大体可以分为以下四步：

M转换成M1

M1 = p1 || mHash ||salt

p1为8字节大小的0。

mHash为M（Fingerprint Data Block）通过SHA256生成的消息摘要，大小为32 Byte，即mHash的大小hLen为32。

salt是一个伪随机数，其长度 (sLen)一般等于hLen，此处为32。

构建DB

DB = p2 || salt

p2的值等于若干个字节的0x00，后面跟着1字节的0x01。这若干个字节长度即为xLen，则xLen表达式如下：

xLen = emLen - sLen - hLen -2

其中，emLen指的是EM长度，此处为256。

MGF

RSA-PSS采用的MGF (Mask Generation Function，掩码生成函数) 为MGF1。对于上图而言，MGF所对应的输入和输出如下：

mask = MGF1(mgfSeed, maskLen, hash)

其中，mgfSeed = Hash(M1)，Hash函数选择SHA256。

maskLen = emLen - hLen -1

构建EM

EM = maskedDB || H || bc

输入如下所示：

maskedDB = DB xor mask

H = Hash(M1)

bc = 0xBC

其中，bc的长度为1个字节，H的长度为hLen，maskedDB的长度记为（mdbLen）为：

mdbLen = emLen - hLen - 1

7.5、数据解签

数据解签

针对签名的验证流程可以分为如下4个步骤：

解密

使用公钥对S (数字签名) 进行解密，从而得到EM。

分割EM

获取到EM以后，接下来就是分割和验证：

maskedDB, H, bc = Split(EM)

最右一个字节是bc，然后从bc往左数hLen个字节是H，然后剩下的是maskedDB。

如果最右一个字节不是0xBC，则签名验证停止（该数字签名是非法的）。

计算salt

得到H以后，就可以计算mask，

mask = MGF1(H, maskLen, hash)

因为，maskedDB = DB xor mask

所以，DB = maskedDB xor mask

得到DB以后，就可以对其分割

p2, salt = Split(DB)

其中，salt是DB的最右sLen个字节，剩下的是p2。

如果p2的值不等于若干个字节的0x00，后面跟着1字节的0x01，那么验证停止（该数字签名是非法的）。

校验Hash

通过所接收到的M（Fingerprint Data Block），计算Hash摘要：

mHash = Hash(M)

然后构建M1：

M1 = p1 || mHash || salt

接着计算M1的Hash：

H1 = Hash(M1)

比较H1与H，如果两者相等，则签名验证通过。如果不相等，则签名非法。