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

该参数指定了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摘要都按顺序进行排列，从而创建出一个新的数据块。这个数据块就称为指纹数据块。