一种车辆OTA过程中禁止记录DTC故障码的优化方法

车龙、李志新、黄越、赖瑞福、朱鹏波、陈文庆

（广州汽车集团股份有限公司汽车工程研究院，广州 510656）

0 引言

随着智能汽车快速发展，空中升级技术（Over-The-Air Technology，简称OTA，也被称作远程升级技术）已经成为了汽车技术不可或缺的一部分，几乎国内外所有汽车主机厂，都已经具备了OTA的能力。根据《国家市场监管总局办公厅关于进一步加强汽车远程升级（OTA）技术召回监管的通知》要求，各汽车生产商不得以OTA升级实施的方式，逃避召回；各汽车生产商实施OTA活动需要依法备案。同时，根据《关于开展汽车软件在线升级备案的通知》要求，企业进行软件升级需进行安全评估、测试验证、实施过程保障及信息记录，所有OTA升级均需告知用户，用户确认才能升级。

汽车故障码（Diagnostic Trouble Code，DTC）在售后保养维修时供专业的技术人员读取，然后根据规程判断，如果无风险存在，则会通过车载自动诊断系统（OBD）设备清除故障码，并试驾无问题才交到客户手中。然而在OTA过程中，由于被升级节点处于启动加载（Bootload）而无法与其他ECU进行通信，导致其他ECU会记录DTC。部分DTC不易自动消失且会在仪表板中显示，给用户带来困恼，也给售后排查问题带来不必要的干扰。通常在OTA结束后，不能自动对车辆升级前的DTC进行清除，防止车辆潜在风险被隐藏。为了避免以上问题，本文提出一种新的优化策略，禁止车载系统在OTA过程中DTC。

1 故障码简述

DTC是汽车出现故障后（比如各种传感器出现异常），通过诊断设备读出来可视化的一种编码。不同的代码表示不同的故障，而不同的系统故障码一般开头都会不一样。故障码又分永久性故障码和瞬时性故障码，当出现永久性故障码时黄色故障灯常亮、出现瞬时性故障码时黄色的故障灯不常亮，但会存储。

比如空调系统未收到高压系统的信号，就会把这个信息记录下来，通报给驾驶员，这个信息就是故障码，反馈给驾驶员的就是仪表板上各种故障灯亮起。故障码通常由5个字符组成，占2个字节数据长度，第一个是字母，后面4个是数字（表1）[1]。

表1 故障码实例

国际上对于故障码定义标准是遵循ISO15031[2]。ISO 15031标准中对于OBD DTC的格式定义如图1所示。其中，第1个字符占用2位数据长度，表示故障所属系统（P、C、B、U）。第2个字符同样占用2位数据长度，表示故障类型。00=0，代表ISO/SAE标准定义的故障码；01=1，代表汽车制造商自定义的故障码；10=2，ISO/SAE预留；11=3，ISO/SAE预留。第3个字符占用4位数据长度，表示故障所属的子系统。第4、5个字符占用1字节数据，表示具体故障对象和类型。

图1 故障诊断码组成格式

2 UDS：0x85 （Control DTC Settering）服务

在刷写过程中，DTC的操作是不需要的，因为该过程无论怎样都可能出现通信异常等情况，故此阶段不应该上报DTC。可以采用0x85服务关闭DTC更新，即：DTCSettingType=off。如果需要打开，则DTCSettingType=on即可。$85 01：继续更新状态码状态位；$85 02：停止更新状态码状态位。

3 记录DTC的优缺点

一般而言，在刷新过程中，记录/不记录DTC，都是使用“UDS：85”诊断服务记录DTC。其优点就是可以方便研发以及售后人员查看ECU在运行过程中发生的错误，方便后期进行BUG修复，使得系统更加稳定，还可以进一步考验ECU量产后的稳定性及可靠性[3]。

但是在升级过程中，如果记录DTC，缺点就比较明显（一般在诊断刷新过程中是会关闭DCT记录的）。比如在刷新过程中往往只针对某个ECU进行单独刷新，而其他ECU还处于运行状态。当非刷新节点对被刷新节点发送应用报文，显然被刷新节点无法响应，此时若没有禁止记录DTC，则被刷新节点会报丢失通信故障，并记录DTC。这显然不符合预期，因为该DTC是在OTA、这种特定场景下产生的伪故障，不属于顾客使用车辆过程中产生的真正意义上的故障。

4 当前OTA过程中市场禁止记录DTC的方法

目前汽车软件系统刷写分为本地诊断设备（DoIP/DoCan）刷新和OTA刷写两种方式。而本地刷新是售后维修人员通过诊断仪进行刷写，即使产生了DTC，也可以等升级完成后统一查看，如果没有问题，则可以全部清除。而OTA过程中不记录DTC一般都是采用“UDS $85 02”的方式关闭记录DTC功能，等升级完成后，再发送“UDS $85 01”打开记录DTC的功能。

但是在OTA过程中需要考虑到的场景非常复杂，仅仅依靠0x85服务指令的技术手段难以满足所有升级场景，无法做到完全禁止所有ECU节点记录故障码的。比如有的节点（非被升级节点）中途复位了，那么该ECU节点就会退出该功能。而0x85功能寻址指令仅仅会发一次，不能周期发送，所以该中途重启的ECU就会开始记录DTC[4]。

再比如以太网节点（不带CAN接口），在传统的方案中，是没有这种禁止记录DTC逻辑的，所以很多以太网节点就会记录DTC。这给售后判断带来迷惑和困难，不知道是真正驾驶过程中产生的，还是在某些特定场景下产生的。

5 一种OTA过程禁止记录DTC的方法策略

当前智能汽车大多数都已经进入了EEA3.0平台，所以主刷新机基本上都由域控制器承担，如CCU、TBOX、网关或车机等。不同厂家的主刷新机不一样，但有3种现象是普遍存在的[5]。

（1）主刷新节点自升级过程中，会存在复位。复位过程中会由于某些CAN信号无法发出，导致记录DTC。

（2）被刷新节点分为常电节点和配电节点，而配电节点在刚配电到系统APP运行过程中，是会记录周边ECU通信异常的DTC。

（3）常电节点或者以太网节点会存在异常复位情况，复位前保持的不记录DTC状态，在复位后会丢失，所以等待完全恢复状态后，其实已经记录了不少DTC。有些DTC严重的会导致上高压失败，动力系统功能、底盘性能等都会受到相当程度的影响，汽车行驶有风险。

基于EEA3.0平台架构以及0x85服务的缺点，本文提出的优化方案核心内容如下。

（1）以OTA模式CAN信号（1：有效，0：无效）为禁止记录DTC的CAN信号，所有ECU都必须接收该信号。通信矩阵打点适配。

（2）OTA模式信号跳变沿从1变成0后的2 s内，不允许记录DTC。

（3）ECU在配电/启动后的5 s内，不允许记录DTC。

（4）升级过程中，在OTA模式发出后仍需周期发送“85 02”指令禁止记录DTC，提供系统冗余性。

（5）OTA升级之前，采集当前车辆已经存在的故障码并上报OTA云平台。

（6）升级完成后，通过14FFFFFF指令，清除整车DTC，确保升级过程中意外产生的非必要DTC被清除掉。

（7）从云端下载升级之前该车辆上报到云端的DTC，将其恢复到Norflash里面，从而让DTC恢复到升级之前的状态[6]。

（8）对于域控制器（假设名称：CCU）来说，复位需要保证在2 s内有应用报文发出。

图2所示为OTA过程中，哪些场景允许记录故障码，哪些场景屏蔽故障码。图3和图4所示为CAN报文中禁止DTC和允许DTC的实际测试截图，表示“85 01”和“85 02”指令有效，ECU正常响应回复。

图2 OTA模式在记录DTC的设计

图3 禁止DTC的测试报文

图4 打开DTC的测试报文

6 结果对比分析

本文提出的优化方案在OTA执行过程中，可以通过以下方式实现不增加新的DTC。

（1）在OTA任务执行之前，整车已存有DTC（图5）。

图5 升级前故障码

（2）如图6所示，在OTA之后，会产生新的DTC（141829和141929）。由于OTA的场景复杂，产生新的DTC往往是不可预知的，且有可能让部分车辆功能失效。如新产生的快慢充正负极温度传感器失效故障，可能会让用户无法正常充电。

图6 升级过程产生的故障码

（3）在OTA任务结束后，即执行完成升级后以后，执行如下清除DTC动作。

清除DTC，发：$14 FF FF FF

ECU正响应，返回：$54

ECU负响应，返回：$7F 14 NRC

测试效果如图7所示。

图7 清除DTC响应报文

发出清除DTC指令后，再去查看DTC（图8），可以看出，“14 FF FF FF”指令已经把原有的DTC一并清除了。

图8 所有DTC都被清除

（4）通过云端下载升级前的DTC，并成功写入CCU，恢复升级前的DTC（图9）。可以看出，采用该优化策略可以实现OTA升级过程中不记录故障码的功能（升级前后故障码保持一致）。

图9 恢复DTC

7 结束语

综上，本文提出的基于OTA模式信号禁止记录DTC的方法明显优于仅仅通过$85服务禁止记录DTC的方法，且有更强的可靠性和更好的容错性。除此之外，使用OTA模式信号能够让整个OTA子系统乃至整个架构的设计更加简便，用最简便的方式基本覆盖了所有OTA过程中的场景。针对当前的OTA技术以及后期无感升级的推进，采用本文所提出的方法，系统在升级过程中是完全有手段做到真正清除故障码，且不破坏升级前的状态，恢复到原始状态。这既不耽误工程师做后期的系统监控及Bug修复，也可以非常有效地支持OTA进行车端ECU升级。