關于CAN控制器軟件數(shù)據(jù)完整性校驗方式及實現(xiàn)的研究

梁亞麗，范新欣，黃金山

（1.一汽奔騰轎車有限公司電子電氣開發(fā)部，吉林 長春 130012；2.中國第一汽車集團有限公司工程與生產(chǎn)物流部，吉林 長春 130012）

隨著整車控制器功能更新的日趨頻繁及控制器Bug修復需要，在控制器出廠后會在整車生產(chǎn)線、售后4S店等地通過OTA或物理介入等方式對控制器進行頻繁軟件更新。這就對數(shù)據(jù)完整性校驗有了嚴格要求，所以可靠的開發(fā)及控制策略顯得尤為重要。

1 數(shù)據(jù)算法簡介

比較通用的CAN數(shù)據(jù)完整性校驗算法主要有奇偶校驗、校驗和、CRC校驗。其中奇偶校驗檢測可靠性低，校驗和雖然檢測可靠性比奇偶校驗大大提升，但仍有1/256的概率無法檢測到數(shù)據(jù)傳輸中的錯誤。

CRC算法因其容易實現(xiàn)且容錯性強、可靠性強，故廣泛應用。CRC算法常用的有CRC8、CRC16、CRC32、CRC64，其中CRCX中的“X”為生成多項式的長度，X越大容錯性越強、計算越復雜。綜合考慮目前各主機廠常用的為CRC32，常用參數(shù)選擇如表1所示。

表1 CRC32參數(shù)選擇示例

2 CRC值計算及傳遞方案

根據(jù)校驗值及校驗算法集成和控制方式不同，CRC值的計算和傳遞方案主要有3種。

方案A：控制器供應商將其集成到控制器中，進行軟件刷新時，刷寫上位機根據(jù)集成算法計算出的CRC1與控制器計算出的CRC2比對，如相同則允許刷寫。

方案B：控制器供應商將根據(jù)該版軟件計算出的CRC2值存儲在軟件中固定位置或DID中傳遞給主機廠，主機廠上位機根據(jù)軟件（除去CRC2字段）計算出的CRC1與控制器中提取出的CRC2進行比對，如相同則允許刷寫。

方案C：控制器供應商傳遞更新軟件和獨立的CRC2給主機廠，主機廠上位機根據(jù)軟件計算出的CRC1與控制器供應商傳遞來的CRC2進行比對，如相同則允許刷寫。

3 方案分析

以上3種方案均能實現(xiàn)數(shù)據(jù)完整性校驗，其中方案A只能保障上位機傳輸?shù)剿懣刂破鞯倪^程中數(shù)據(jù)未出現(xiàn)錯誤，而無法保障該軟件從控制器供應商到上位機的傳輸路徑上未出現(xiàn)被篡改等錯誤傳輸。但方案B和方案C則能保障從控制器供應商軟件設計完成到控制器刷寫全過程中數(shù)據(jù)的完整性。

以OTA刷寫為例分析數(shù)據(jù)傳輸過程（圖1），如果采用方案A進行數(shù)據(jù)完整性校驗，在以下數(shù)據(jù)傳輸?shù)?個過程中均可能產(chǎn)生問題。

圖1 OTA數(shù)據(jù)傳輸過程

1）ECU供應商通過手動辦公傳遞至OTA后臺過程中。

2）自OTA后臺通過4G網(wǎng)絡傳遞至車輛過程中。

3）自車內(nèi)刷寫上位機（一般為GW或TBOX）傳遞至刷寫目標控制器過程中。

在以上3個路徑中方案A可以通過兩次CRC值計算及校驗發(fā)現(xiàn)路徑2）和3）傳輸數(shù)據(jù)完整性，而無法校驗出路徑1）的問題。故這種方案不建議使用。

方案B和方案C的CRC值均從供應商軟件生成開始一直傳遞至刷寫目標控制器，故可以保障路徑1）、2）、3）的數(shù)據(jù)完整性。但此時CRC算法由控制器供應商集成于控制器內(nèi)部，CRC值由供應商傳遞給OEM，故OEM無法得知其具體算法是否為OEM要求的算法。如此時控制器供應商未進行任何的數(shù)據(jù)完整性校驗，而隨便傳遞一個CRC值，這樣路徑1）、2）、3）均無從保障。

要想有效解決該問題，需要在測試環(huán)節(jié)加入CRC值的計算及驗證，將有效地確認ECU供應商是否按照OEM推薦的CRC算法進行開發(fā)，如圖2所示。為了更好地提升工作效率及便利性，將推薦算法（表1）編譯成可執(zhí)行小程序，測試人員只需將HEX文件導入即可得到CRC值，并將其和供應商提供的值進行比對即可。

圖2 CRC驗證過程

方案B和方案C的數(shù)據(jù)完整性校驗的可靠程度是一樣的，但方案B需要將CRC值放置于軟件或DID中。如果放置于軟件中，需進行特殊設置確保該部分數(shù)據(jù)不參與CRC值的計算；如果放置于DID中，ECU供應商在零件下線時需要通過診斷指令寫入相應內(nèi)容，這樣會增加下線寫入工作量。而方案C則不需該部分操作。故建議選用方案C。

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

圖3 方案C控制過程

首先，OEM將算法（推薦變量按照表1選擇）傳遞給控制器供應商。

其次，控制器按其開發(fā)控制器并在開發(fā)完成后將相應的軟件及按OEM算法得到的CRC值打包傳遞給OEM測試，并提交測試樣件。

再次，測試工程師將供應商提供的軟件導入CRC計算小程序得到CRC值，并將其與供應商提供的值進行比對。如一致則進行控制器刷寫，在控制器刷寫過程中如果能正常通過驗證，則證明控制器是按照OEM提供算法進行開發(fā)的。

最后，經(jīng)過驗證的控制器在供應商生產(chǎn)線、OEM生產(chǎn)線、售后等進行批量刷寫。

4 結束語

隨著電器功能復雜度及控制器數(shù)量的急劇增加，軟件刷寫頻率越來越高。為了提高刷寫效率，目前逐步從物理介入向OTA的遠程刷寫迭代。這樣信息安全問題就急劇凸現(xiàn)，為了更好地確定數(shù)據(jù)完整性必須要有可靠的開發(fā)及控制策略。本文對常見的控制策略及方法進行了細致的分析，為數(shù)據(jù)傳輸?shù)耐暾蕴峁┝思夹g保障和理論依據(jù)。