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

CRC與Checksum區別

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

01

兩者存放位置不同

CRC校驗：循環冗余檢查（CRC）是一種數據傳輸檢錯功能，對數據進行多項式計算，并將得到的結果附在幀的后面，接收設備也執行類似的算法，以保證數據傳輸的正確性和完整性。通過CRC概念可以得知，CRC存放在CRC場，而Checksum存放在數據場之中，一般在數據場的第一個字節或者最后一個字節。
圖1 標準數據幀格式

02

兩者應用場景不同

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

Checksum的應用場景

對于Checksum而言，它的應用場景有以下三點：

01

確保數據正確打包

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

01

實現數據加密

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

03

提高數據的可信度

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

在CAPL中Checksum信號實現

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

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

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

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

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

總結

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

注：圖片來自于Vector。