本文主要是介绍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，如果两者相等，则签名验证通过。如果不相等，则签名非法。
这篇关于ISO14229 -1 UDS诊断服务记录-001：0x34\0x36\0x37\0x31\0x19\0x14服务报文格式介绍的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
