作者：北城舊巷
小編：吃不飽

CRC與Checksum區(qū)別

相信大家在CAN Msg或者ETH PDU中經(jīng)常會看到Checksum這種信號。提到Checksum，就必須要說明一下CRC校驗，很多工程師會概念混淆，認(rèn)為兩者是同一個東西，實則它們有很大的區(qū)別。

01

兩者存放位置不同

CRC校驗：循環(huán)冗余檢查（CRC）是一種數(shù)據(jù)傳輸檢錯功能，對數(shù)據(jù)進(jìn)行多項式計算，并將得到的結(jié)果附在幀的后面，接收設(shè)備也執(zhí)行類似的算法，以保證數(shù)據(jù)傳輸?shù)恼_性和完整性。通過CRC概念可以得知，CRC存放在CRC場，而Checksum存放在數(shù)據(jù)場之中，一般在數(shù)據(jù)場的第一個字節(jié)或者最后一個字節(jié)。
圖1 標(biāo)準(zhǔn)數(shù)據(jù)幀格式

02

兩者應(yīng)用場景不同

在CAN報文幀中，CRC校驗是發(fā)送器根據(jù)發(fā)送的bit進(jìn)行多項式計算校驗，結(jié)果放在15bit長度的CRC位。接收器也是用相同的多項式計算總線上的數(shù)據(jù)，與接收到的校驗值進(jìn)行比較，相同則表示幀正確接收，并在ACK時隙中發(fā)送顯性狀態(tài)，覆蓋發(fā)送器的隱性位；如果不同接收節(jié)點在ACK界定符之后發(fā)送錯誤幀。
圖2 CRC校驗原理CRC校驗是為了保證數(shù)據(jù)從一個CAN收發(fā)器發(fā)送到另外一個收發(fā)器的信號完整性，而數(shù)據(jù)場中Checksum校驗算法是為了校驗數(shù)據(jù)被正確的打包與解包，并且Checksum算法是可以自行制定的，計算規(guī)則的靈活度高。

Checksum的應(yīng)用場景

對于Checksum而言，它的應(yīng)用場景有以下三點：

01

確保數(shù)據(jù)正確打包

有些ECU內(nèi)部的變量在傳遞到CAN收發(fā)器之前就有可能發(fā)生錯誤，這種類型的錯誤CAN收發(fā)器是無法檢測到的。報文中的信號和Checksum校驗是在應(yīng)用層完成的，將報文中的各個字節(jié)進(jìn)行校驗，報文和Checksum一起發(fā)送，并且在接收節(jié)點進(jìn)行解析，從而確保數(shù)據(jù)鏈路完整和數(shù)據(jù)正確打包。

01

實現(xiàn)數(shù)據(jù)加密

CAN網(wǎng)絡(luò)是開放性的，CAN節(jié)點可以隨時加入到總線當(dāng)中，為了保證通信的安全性，ECU傳輸?shù)年P(guān)鍵控制信號需要進(jìn)行加密，報文的發(fā)送方和接收方使用相同的Checksum算法作為數(shù)據(jù)加密的密鑰。接收方對比秘鑰，如果不同，此條報文的數(shù)據(jù)不被使用，從而避免被其他節(jié)點的數(shù)據(jù)影響。Checksum算法不在DBC等數(shù)據(jù)庫文件中說明，可以單獨保密，從而確保了數(shù)據(jù)的加密。

03

提高數(shù)據(jù)的可信度

一幀報文在多個字節(jié)中可能出現(xiàn)位錯誤，一般情況下CRC8校驗的錯誤率為1/256，crc16校驗的錯誤率為1/65536，crc32校驗的錯誤率為1/(65536*65536)。通過Checksum校驗可以提高數(shù)據(jù)的可信度。由于Checksum的作用，其也常應(yīng)用在車載以太網(wǎng)當(dāng)中。

在CAPL中Checksum信號實現(xiàn)

通常情況下，Checksum和LiveCounter信號是成對出現(xiàn)的。在CANoe中使用仿真節(jié)點與真實控制器交互，需要將LiveCounter和Checksum信號仿真，這樣才能成功通信。LiveCounter長度為4bit，它是用于報文發(fā)送計數(shù)的生命信號，每發(fā)送一幀報文后就對該LiveCounter位加1，會在0~15之間循環(huán)增加。在報文其他信號沒有改變時，LiveCounter實時更新使得Checksum信號跟著更新，提高校驗的準(zhǔn)確性。那么LiveCounter信號該如何仿真呢？下面以CAN總線DBC為例，介紹在CAPL中實現(xiàn)LiveCounter和Checksum校驗仿真。

CAPL是CANoe和CANalyzer中可用的類C的編程語言。CAPL中程序塊的執(zhí)行由事件控制，在專用的編譯器中開發(fā)和編譯，這樣可以訪問數(shù)據(jù)庫中的所有對象以及系統(tǒng)變量，被汽車電子工程師們廣泛使用。

下圖為LiveCounter計算的代碼，為了保證數(shù)據(jù)的準(zhǔn)確性，進(jìn)行一次Checksum計算，這樣就可以實現(xiàn)LiveCounter信號的仿真。
圖3 LiveCounter計算代碼下圖為示例報文中各個信號位置排布關(guān)系，在此報文中，Checksum校驗方式為前七個字節(jié)異或運算，將運算結(jié)果存放到最后一個字節(jié)。排布圖中共有8個信號，它們的格式為Motorola格式，也就是俗稱的大端模式。
圖4 報文中信號排布

CAPL只能訪問到報文中的信號，無法訪問到報文中的每個字節(jié)，要進(jìn)行Checksum計算，需要根據(jù)信號排布把前七個字節(jié)的真實值重新組合存放在一個byte類型的數(shù)組當(dāng)中，然后對這個數(shù)組異或運算獲取的結(jié)果為該報文中Checksum信號值。

對于不同長度的信號，需要聲明不同類型的數(shù)組來存放不同的信號。byte類型長度為1字節(jié)，聲明兩個byte *[8]類型的數(shù)組（*為省略的數(shù)組名稱）分別存放長度小于一字節(jié)的信號和重組后每個字節(jié)的真實值；int類型長度為2字節(jié)，聲明int *[8]類型的數(shù)組存放長度為1-2字節(jié)的信號；long類型長度為4字節(jié)，聲明long *[8]類型的數(shù)組存放長度為2-4字節(jié)的信號。下圖為Checksum中信號長度小于1字節(jié)的字節(jié)重組示例代碼。
圖5 Checksum字節(jié)重組示例代碼另外，參與Checksum計算的是信號的真實值而不是物理值，如果信號中有偏移量和比例因子，在賦值時需要將信號加上偏移量，并除以比例因子以獲得真實值。
圖6 信號描述為了保證和真實控制器通信正常，Checksum數(shù)據(jù)必須準(zhǔn)確，Checksum計算步驟一般寫成無返回值函數(shù)（void），在LiveCounter信號改變或者其他信號改變時調(diào)用計算。正確計算的LiveCounter和Checksum信號曲線如下圖所示。
圖7 LiveCounter和Checksum信號曲線

總結(jié)

本文重點描述了CRC和Checksum信號的區(qū)別以及Checksum信號在CAPL中實現(xiàn)的方法。CAPL編程作為CANoe的靈魂，使CANoe滿足仿真、分析、測試和診斷的各種復(fù)雜的要求，同時使CANoe的功能得以不斷擴(kuò)展。
北匯信息作為Vector中國的合作伙伴，致力于為中國汽車客戶提供優(yōu)質(zhì)的工具支持、解決方案以及測試服務(wù)。

注：圖片來自于Vector。