作者:北城舊巷
小編:吃不飽
CRC與Checksum區(qū)別
相信大家在CAN Msg或者ETH PDU中經(jīng)常會看到Checksum這種信號。提到Checksum,就必須要說明一下CRC校驗,很多工程師會概念混淆,認(rèn)為兩者是同一個東西,實則它們有很大的區(qū)別。
01
兩者存放位置不同
CRC校驗:循環(huán)冗余檢查(CRC)是一種數(shù)據(jù)傳輸檢錯功能,對數(shù)據(jù)進行多項式計算,并將得到的結(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進行多項式計算校驗,結(jié)果放在15bit長度的CRC位。接收器也是用相同的多項式計算總線上的數(shù)據(jù),與接收到的校驗值進行比較,相同則表示幀正確接收,并在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é)進行校驗,報文和Checksum一起發(fā)送,并且在接收節(jié)點進行解析,從而確保數(shù)據(jù)鏈路完整和數(shù)據(jù)正確打包。
01
實現(xiàn)數(shù)據(jù)加密
CAN網(wǎng)絡(luò)是開放性的,CAN節(jié)點可以隨時加入到總線當(dāng)中,為了保證通信的安全性,ECU傳輸?shù)年P(guā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)確性,進行一次Checksum計算,這樣就可以實現(xiàn)LiveCounter信號的仿真。
圖3 LiveCounter計算代碼下圖為示例報文中各個信號位置排布關(guān)系,在此報文中,Checksum校驗方式為前七個字節(jié)異或運算,將運算結(jié)果存放到最后一個字節(jié)。排布圖中共有8個信號,它們的格式為Motorola格式,也就是俗稱的大端模式。
圖4 報文中信號排布
CAPL只能訪問到報文中的信號,無法訪問到報文中的每個字節(jié),要進行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的功能得以不斷擴展。
北匯信息作為Vector中國的合作伙伴,致力于為中國汽車客戶提供優(yōu)質(zhì)的工具支持、解決方案以及測試服務(wù)。
注:圖片來自于Vector。
-
編程
+關(guān)注
關(guān)注
88文章
3614瀏覽量
93686
發(fā)布評論請先 登錄
相關(guān)推薦
評論