梁亞麗，范新欣，黃金山

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

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

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

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

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

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

2 CRC值計(jì)算及傳遞方案

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

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

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

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

3 方案分析

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

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

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

1）ECU供應(yīng)商通過手動(dòng)辦公傳遞至OTA后臺(tái)過程中。

2）自O(shè)TA后臺(tái)通過4G網(wǎng)絡(luò)傳遞至車輛過程中。

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

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

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

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

圖2 CRC驗(yàn)證過程

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

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

圖3 方案C控制過程

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

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

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

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

4 結(jié)束語(yǔ)

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