车载ECU嵌入式设备的诊断测试 – 读和写

作者 | 李伟 上海控安安全测评中心安全测评部总监

来源 | 鉴源实验室

引言：第四篇中我们介绍了UDS服务中的会话和安全控制，主要讲了不同模式会话间的切换逻辑，问答报文结构，安全控制的作用和等级、安全控制的解锁过程，以及这两个服务的测试注意要点等等。本篇讲述UDS中的读和写服务，读写服务几乎是工程师日常使用最为频繁的服务，特别是读服务。

01 $22读服务

$22读服务通常在默认会话下即可执行，特殊情况下，某些信息做了读取保密设计，需要在扩展会话和安全控制下才能读取该DID（Data ID）信息。

DID长度通常为16进制2个字节，范围从0x00 00至0xFF FF，每个DID代表一条对应的消息，这样我们需要知道该信息的内容时，只需要使用$22+DID既可以获取该信息内容。如：我们用DID 0xF1 90标识车辆VIN，需要知道车辆VIN具体号码信息时，向ECU发送$22 F1 90进行信息查询，即可得到内容反馈。

之前我们一直在强调UDS诊断的自定义空间比较大，在极个别项目中，我们遇到过DID长度为3个字节的情况，我们需要以实际项目研发测试过程设计为准。

1.1 DID的分类

通过上面的描述我们可以理解，车辆上很多信息可以通过DID进行设计定义，通常主机厂根据信息属性不同将DID进行设计分类：

1）物流数据

物流数据中一般包含的是跟车辆和设备生产相关的固定信息。在生产过程中，零部件供应商不会一个批次完成所有零部件的生产和交付，这个过程一般是以月份或者季度为单位分批次执行，伴随着这个过程的通常还有主机产要求的VAVE等活动，因此同一个零部件也会因生产批次不同，对应的软硬件和配置信息有所不同。物流数据通常有：零部件硬件批次号、软件批次号、本设备的串号、部件号、出厂时间、制造时间、供应商硬件号、供应商软件号、ECU部件数量、ECU应用软件数量、ECU配置文件数量、车型信息、车辆VIN码等等。

2）内部属性数据

内部属性数据一般包含了ECU本身的软硬件配置相关信息，如：软件版本号、设备温度、ICCID号、IMEI号、GNSS天线状态、GNSS定位信息、NAD基本信息、NAD天线信息等等。

3）配置属性数据

配置属性数据顾名思义包含了ECU中需要进行配置的相关数据，这些数据一般情况下都可以做成模板进行复用，根据要求不一样进行模板选择，如：当前车辆的车型（同一型号的车具体有高中低等不同配置，具体到当前车辆可能发动机等配置都是有区别的）、移动通信运营商国家代码、运营商网络编码、APN拨号配置等。

4）Bitmapped I/O parameter DID和Non-Bitmapped I/O parameter DID

ECU通常会收到网络上其他设备发送的周期信号，这些信号通常可以在相应的网络上实时获取，也可以通过诊断读取，这类信号一般包含在Bitmapped和Non-Bitmapped属性数据中，区别是一个通常包含的是开关与否、报警与否的状态信号，另一个通常包含的对应的数值，如：机油过低报警状态、机油量、油量过低报警状态、当前油量等等。

1.2 $22服务请求报文

$22服务的请求报文格式总体与第三篇文档的描述一致。但是$22服务没有子功能，在服务ID后直接跟DID。发送报文帧结构如下图：

 图 1

举例$22服务请求VIN码对应的DID，报文为：03 22 F1 90，当然根据项目实际情况车辆VIN可能是其他DID。

$22服务支持多个DID一次读取，报文格式如下图：

 图 2

举例$22服务一次请求多个DID，$22 F1 80 F1 81。

1.3 $22服务响应报文

$22服务的响应报文格式总体与第三篇文档的描述一致。正响应报文的服务号为$62，第二、三字节对应请求报文的DID。从第四字节至最后为对应DID的实际数据。响应报文帧的结构图如下所示：

 图 3

举例$22服务的响应报文通常为：

ECU：  10 14 62 F1 90 01 02 03

Tester：30 00（流控制帧）

ECU：  21 04 05 06 07 08 09 0A

ECU：  22 0B 0C 0D 0E 0F 10 11

$22服务一次读取多个DID的响应报文格式如下图：

 图 4

$22服务一次读取多个DID的响应报文，如：

ECU：  10 0C 62 F1 80 01 02 03

Tester：30 00（流控制帧）

ECU：  21 04 F1 81 0A 0B 0C AA

$22服务的否定响应格式，可以参考第三篇文章服务响应总体中负响应部分介绍，所有UDS服务的负响应故障代码表在项目中均是通用的。

02 $2E写服务

$2E写服务跟$22是对应的关系，完成了DID对应的数据写入后，我们才能通过$22服务读取出相应DID写入的内容。所以$2E服务的请求应答过程跟$22的请求应答格式上看是相互翻转的。

$2E服务成功写入的前提条件，通常要求服务在扩展会话和安全等级1的模式下执行。另外要注意的，并不是所有支持$22服务的DID都能够在$2E服务下写入，通常物流数据DID、配置信息DID等可以反复写入，Bitmapped和Non-Bitmapped属性数据一般不支持$2E手动写入，具体情况还需要查看项目的相关设计文档。

2.1 $2E服务请求报文

$2E服务请求报文写入DID对应的数据格式总体上跟上篇中UDS请求报文介绍一致，发送报文帧结构如下图：

 图 5

举例$2E服务的请求报文通常为：

10 14 2E F1 90 01 02 03

30 00

21 04 05 06 07 08 09 0A

22 0B 0C 0D 0E 0F 10 11

2.2 $2E服务响应报文

$2E服务的响应报文格式总体与第三篇文档的描述一致。正响应报文的服务号为$6E，第二、三字节对应请求报文的DID。响应报文帧的结构图如下所示：

 图 6

举例$2E的正响应报文通常格式为：03 6E F1 90

负响应的报文格式可以参考第三篇的相关章节，负响应NRC代码表一般在项目中是通用的。

03 总结

$22服务和$2E服务测试过程中通常是配合一起执行的。但是支持$22服务的DID，不一定支持$2E服务。DID对应的信息含义和格式一定要查阅和依据诊断规范。

04 测试要点

$22和$2E服务跟其他服务测试相同的地方是，大家都要依照针对规范执行相关测试；不同点在于$22和$2E涉及到的物流数据DID，对于这些信息零部件每个生产批次的数值可能都不一样，最新的数值表一般在排产前，由DRE在系统中申请生成，并向供应商释放，因此测试的时间和对应释放的软件版本号需要特别注意。