CRC與Checksum區(qū)別

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

第一、兩者存放位置不同。

CRC校驗(yàn)：循環(huán)冗余檢查（CRC）是一種數(shù)據(jù)傳輸檢錯(cuò)功能，對(duì)數(shù)據(jù)進(jìn)行多項(xiàng)式計(jì)算，并將得到的結(jié)果附在幀的后面，接收設(shè)備也執(zhí)行類似的算法，以保證數(shù)據(jù)傳輸?shù)恼_性和完整性。

通過CRC概念可以得知，CRC存放在CRC場(chǎng)，而Checksum存放在數(shù)據(jù)場(chǎng)之中，一般在數(shù)據(jù)場(chǎng)的第一個(gè)字節(jié)或者最后一個(gè)字節(jié)。

圖1 標(biāo)準(zhǔn)數(shù)據(jù)幀格式

第二、兩者應(yīng)用場(chǎng)景不同。

在CAN報(bào)文幀中，CRC校驗(yàn)是發(fā)送器根據(jù)發(fā)送的bit進(jìn)行多項(xiàng)式計(jì)算校驗(yàn)，結(jié)果放在15bit長(zhǎng)度的CRC位。接收器也是用相同的多項(xiàng)式計(jì)算總線上的數(shù)據(jù)，與接收到的校驗(yàn)值進(jìn)行比較，相同則表示幀正確接收，并在ACK時(shí)隙中發(fā)送顯性狀態(tài)，覆蓋發(fā)送器的隱性位；如果不同接收節(jié)點(diǎn)在ACK界定符之后發(fā)送錯(cuò)誤幀。

圖2 CRC校驗(yàn)原理

展開全文

CRC校驗(yàn)是為了保證數(shù)據(jù)從一個(gè)CAN收發(fā)器發(fā)送到另外一個(gè)收發(fā)器的信號(hào)完整性，而數(shù)據(jù)場(chǎng)中Checksum校驗(yàn)算法是為了校驗(yàn)數(shù)據(jù)被正確的打包與解包，并且Checksum算法是可以自行制定的，計(jì)算規(guī)則的靈活度高。

Checksum的應(yīng)用場(chǎng)景

對(duì)于Checksum而言，它的應(yīng)用場(chǎng)景有以下三點(diǎn)：

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

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

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

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

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

一幀報(bào)文在多個(gè)字節(jié)中可能出現(xiàn)位錯(cuò)誤，一般情況下CRC8校驗(yàn)的錯(cuò)誤率為1/256，crc16校驗(yàn)的錯(cuò)誤率為1/65536，crc32校驗(yàn)的錯(cuò)誤率為1/(65536*65536)。通過Checksum校驗(yàn)可以提高數(shù)據(jù)的可信度。

由于Checksum的作用，其也常應(yīng)用在車載以太網(wǎng)當(dāng)中。

在CAPL中Checksum信號(hào)實(shí)現(xiàn)

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

下面以CAN總線DBC為例，介紹在CAPL中實(shí)現(xiàn)LiveCounter和Checksum校驗(yàn)仿真。

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

下圖為L(zhǎng)iveCounter計(jì)算的代碼，為了保證數(shù)據(jù)的準(zhǔn)確性，進(jìn)行一次Checksum計(jì)算，這樣就可以實(shí)現(xiàn)LiveCounter信號(hào)的仿真。

圖3 LiveCounter計(jì)算代碼

下圖為示例報(bào)文中各個(gè)信號(hào)位置排布關(guān)系，在此報(bào)文中，Checksum校驗(yàn)方式為前七個(gè)字節(jié)異或運(yùn)算，將運(yùn)算結(jié)果存放到最后一個(gè)字節(jié)。排布圖中共有8個(gè)信號(hào)，它們的格式為Motorola格式，也就是俗稱的大端模式。

圖4 報(bào)文中信號(hào)排布

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

對(duì)于不同長(zhǎng)度的信號(hào)，需要聲明不同類型的數(shù)組來存放不同的信號(hào)。byte類型長(zhǎng)度為1字節(jié)，聲明兩個(gè)byte *[8]類型的數(shù)組（*為省略的數(shù)組名稱）分別存放長(zhǎng)度小于一字節(jié)的信號(hào)和重組后每個(gè)字節(jié)的真實(shí)值；int類型長(zhǎng)度為2字節(jié)，聲明int *[8]類型的數(shù)組存放長(zhǎng)度為1-2字節(jié)的信號(hào)；long類型長(zhǎng)度為4字節(jié)，聲明long *[8]類型的數(shù)組存放長(zhǎng)度為2-4字節(jié)的信號(hào)。下圖為Checksum中信號(hào)長(zhǎng)度小于1字節(jié)的字節(jié)重組示例代碼。

圖5 Checksum字節(jié)重組示例代碼

另外，參與Checksum計(jì)算的是信號(hào)的真實(shí)值而不是物理值，如果信號(hào)中有偏移量和比例因子，在賦值時(shí)需要將信號(hào)加上偏移量，并除以比例因子以獲得真實(shí)值。

圖6 信號(hào)描述

為了保證和真實(shí)控制器通信正常，Checksum數(shù)據(jù)必須準(zhǔn)確，Checksum計(jì)算步驟一般寫成無返回值函數(shù)（void），在LiveCounter信號(hào)改變或者其他信號(hào)改變時(shí)調(diào)用計(jì)算。

正確計(jì)算的LiveCounter和Checksum信號(hào)曲線如下圖所示。

總結(jié)：

本文重點(diǎn)描述了CRC和Checksum信號(hào)的區(qū)別以及Checksum信號(hào)在CAPL中實(shí)現(xiàn)的方法。CAPL編程作為CANoe的靈魂，使CANoe滿足仿真、分析、測(cè)試和診斷的各種復(fù)雜的要求，同時(shí)使CANoe的功能得以不斷擴(kuò)展。