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

来源:鉴源实验室
2022-11-08
4177
作者 | 李伟 上海控安安全测评中心安全测评部总监
来源 | 鉴源实验室




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

1.汽车电子架构和CAN网络基础



2.车载ECU嵌入式软件的测试入门



3.车载ECU嵌入式设备的诊断测试-服务



4.车载ECU嵌入式设备的诊断测试-会话和安全控制




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在系统中申请生成,并向供应商释放,因此测试的时间和对应释放的软件版本号需要特别注意。



阅读原文

收藏
点赞
2000