关于CAN控制器软件数据完整性校验方式及实现的研究

2021-07-05梁亚丽范新欣黄金山

汽车电器 2021年6期

关键词：主机厂校验上位

梁亚丽，范新欣，黄金山

（1.一汽奔腾轿车有限公司电子电气开发部，吉林长春 130012；2.中国第一汽车集团有限公司工程与生产物流部，吉林长春 130012）

随着整车控制器功能更新的日趋频繁及控制器Bug修复需要，在控制器出厂后会在整车生产线、售后4S店等地通过OTA或物理介入等方式对控制器进行频繁软件更新。这就对数据完整性校验有了严格要求，所以可靠的开发及控制策略显得尤为重要。

1 数据算法简介

比较通用的CAN数据完整性校验算法主要有奇偶校验、校验和、CRC校验。其中奇偶校验检测可靠性低，校验和虽然检测可靠性比奇偶校验大大提升，但仍有1/256的概率无法检测到数据传输中的错误。

CRC算法因其容易实现且容错性强、可靠性强，故广泛应用。CRC算法常用的有CRC8、CRC16、CRC32、CRC64，其中CRCX中的“X”为生成多项式的长度，X越大容错性越强、计算越复杂。综合考虑目前各主机厂常用的为CRC32，常用参数选择如表1所示。

表1 CRC32参数选择示例

2 CRC值计算及传递方案

根据校验值及校验算法集成和控制方式不同，CRC值的计算和传递方案主要有3种。

方案A：控制器供应商将其集成到控制器中，进行软件刷新时，刷写上位机根据集成算法计算出的CRC1与控制器计算出的CRC2比对，如相同则允许刷写。

方案B：控制器供应商将根据该版软件计算出的CRC2值存储在软件中固定位置或DID中传递给主机厂，主机厂上位机根据软件（除去CRC2字段）计算出的CRC1与控制器中提取出的CRC2进行比对，如相同则允许刷写。

方案C：控制器供应商传递更新软件和独立的CRC2给主机厂，主机厂上位机根据软件计算出的CRC1与控制器供应商传递来的CRC2进行比对，如相同则允许刷写。

3 方案分析

以上3种方案均能实现数据完整性校验，其中方案A只能保障上位机传输到刷写控制器的过程中数据未出现错误，而无法保障该软件从控制器供应商到上位机的传输路径上未出现被篡改等错误传输。但方案B和方案C则能保障从控制器供应商软件设计完成到控制器刷写全过程中数据的完整性。

以OTA刷写为例分析数据传输过程（图1），如果采用方案A进行数据完整性校验，在以下数据传输的3个过程中均可能产生问题。

图1 OTA数据传输过程

1）ECU供应商通过手动办公传递至OTA后台过程中。

2）自OTA后台通过4G网络传递至车辆过程中。

3）自车内刷写上位机（一般为GW或TBOX）传递至刷写目标控制器过程中。

在以上3个路径中方案A可以通过两次CRC值计算及校验发现路径2）和3）传输数据完整性，而无法校验出路径1）的问题。故这种方案不建议使用。

方案B和方案C的CRC值均从供应商软件生成开始一直传递至刷写目标控制器，故可以保障路径1）、2）、3）的数据完整性。但此时CRC算法由控制器供应商集成于控制器内部，CRC值由供应商传递给OEM，故OEM无法得知其具体算法是否为OEM要求的算法。如此时控制器供应商未进行任何的数据完整性校验，而随便传递一个CRC值，这样路径1）、2）、3）均无从保障。

要想有效解决该问题，需要在测试环节加入CRC值的计算及验证，将有效地确认ECU供应商是否按照OEM推荐的CRC算法进行开发，如图2所示。为了更好地提升工作效率及便利性，将推荐算法（表1）编译成可执行小程序，测试人员只需将HEX文件导入即可得到CRC值，并将其和供应商提供的值进行比对即可。

图2 CRC验证过程

方案B和方案C的数据完整性校验的可靠程度是一样的，但方案B需要将CRC值放置于软件或DID中。如果放置于软件中，需进行特殊设置确保该部分数据不参与CRC值的计算；如果放置于DID中，ECU供应商在零件下线时需要通过诊断指令写入相应内容，这样会增加下线写入工作量。而方案C则不需该部分操作。故建议选用方案C。

方案C建议的流程及控制方法如图3所示。