大连网站建设怎么做,代做道路毕业设计网站,wordpress创建注册,好友介绍网站怎么做目录 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服务-例程控制 …目录 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测试的最新结果表明了一个成熟的失败结果。
bit1testFailedThisMonitoringCycle 该位表示在当前test中诊断test是否已经报告了一个testFailed结果。当新的检测循环开始时这个位需要置0在调用了14服务后也需要置0。如果该位置1那么一直保持置1状态直到新的检测循环开始因此bit1可以理解为当前DTC。如果bit2和bit3通常一起使用。 “0” testFailed:在当前操作周期内或在当前操作周期内调用ClearDiagnosticInformation后尚未报告testFailed结果。 “1” testFailed:在当前操作周期中至少报告了一次testFailed结果。
bit2pendingDTC 根据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并锁定。
bit3confirmedDTC 当bit3置1时说明故障已经发生了一段时间也就是bit2至少有一次被置1了。需要注意的是bit3置1的时候DTC被存储在EEprom中但并不代表现在故障还存在所以可以理解为历史故障。在调用14服务清除DTC后需要置0。 “0” 自上次调用ClearDiagnosticInformation后或在满足故障诊断码的老化条件或由于故障记忆溢出而清除了故障诊断码后从未确认过故障诊断码。 “1” 自上次调用ClearDiagnosticInformation后至少确认一次的DTC且尚未满足老化标准
bit4testNotCompletedSinceLastClear 因为并不是所有的DTC测试都是从上电就开始的所以该位用来表示上次调用14服务清除诊断消息后是否进行过完整的test。如果进行了完整的test无论结果如何都置0否则置1。 “0” 自上次清除诊断信息以来DTC测试至少返回一次测试结果无论通过或失败。 “1” 自上次清除诊断信息后DTC测试尚未运行到完成。
bit5testFailedSinceLastClear 该位表示在上次调用14服务清除后DTC后若test DTC未进行测试或者测试了但结果是pass时置0如果test运行完成并且返回结果为fails那么该位置1。在调用14服务清除DTC后需要置0。bit4和bit5通常一起使用。 “0”自上次清除诊断信息后DTC测试未显示失败结果。如果满足老化阈值或发生故障记忆溢出则车辆制造商应负责将该位重置为零“0”。 “1”自上次清除诊断信息以来DTC测试至少返回一次失败结果。
bit6testNotCompletedThisOperationCycle 该位表示在当前检测循环周期过程中DTC test是否完成若完成了置0未完成置1。在调用ClearDiagnosticDTC后需要置1。 “0” DTC测试在当前驾驶循环期间或自上次在当前操作循环期间清除诊断信息以来完成。 “1” 此操作循环或自上次清除此操作循环的诊断信息后DTC测试尚未运行到完成。
bit7warningIndicatorRequested 该位报告警告指示比如说仪表盘上的警示灯等。但不是所有的DTC都会有警告指示如果没有和DTC相关的警告存在该位应置0如果该DTC有相关警告指示bit3置1的时候bit7也要置1。在调用14服务清除DTC后需要置0。
5.1、报文格式
Service ID (SID): 0x19
请求示例119 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信息包括但不限于以下各项数据 1DTC状态字节 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 (destbus:sri, dest_offset0x80040100, size256k - 256 - 16k);map not_cached (destbus:sri, dest_offset0xa0040100, reserved, size256k - 256 - 16k);
} 然后通过Hash算法例如SHA256针对每个Software Part Block计算出相应的Hash摘要。接着将Software Part Block的数目、每个Software Part Block的起始地址、大小、Hash摘要都按顺序进行排列从而创建出一个新的数据块。这个数据块就称为指纹数据块。
7.3、数据签名 此处以RSA-PSS算法进行介绍签名流程RSA算法采用RSA2048Hash算法采用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 bit256 Byte所以需要使用一种填充算法将32 Byte的Hash摘要填充成为256 Byte的消息。 下图展示了PSS算法进行填充的流程示意图大体可以分为以下四步 M转换成M1
M1 p1 || mHash ||salt
p1为8字节大小的0。
mHash为MFingerprint 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的长度为hLenmaskedDB的长度记为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
通过所接收到的MFingerprint Data Block计算Hash摘要
mHash Hash(M)
然后构建M1
M1 p1 || mHash || salt
接着计算M1的Hash
H1 Hash(M1)
比较H1与H如果两者相等则签名验证通过。如果不相等则签名非法。
