作者 | 沈平 上海控安可信軟件創新研究院汽車網絡安全組
來源 |鑒源實驗室
社群 |添加微信號“TICPShanghai”加入“上海控安51fusa安全社區”
隨著汽車行業逐步走向電氣化、智能化,車載系統的軟件和硬件復雜度不斷上升。如何確保這些復雜系統中的數據通訊安全和可靠,已成為業界關注的焦點。E2E(End-to-End)通訊常常指的是一個信息從發送端到接收端的完整傳輸過程,保障通訊中數據的完整性與安全性。AUTOSAR (AUTomotive Open System ARchitecture)是一個全球汽車工業的標準化項目,旨在為嵌入式汽車軟件創造一個共同的標準。在AUTOSAR架構中,軟件被分為三個主要層次:應用軟件(ASW, Application Software),基礎軟件(BSW, Basic Software),以及運行時環境(RTE, Runtime Environment)。E2E通常是在ASW層實現的,它確保應用級的數據通信在發送和接收時的完整性。圖1所示為在AUTOSAR架構中E2E保護示例圖。在圖1中E2E能夠減輕BSW層軟硬件以及ECU之間網絡通訊的故障。
圖1通過E2E保護減輕故障的示例圖
功能安全是關于硬件和軟件系統在出現故障時仍然保持安全狀態的能力。在車載系統中,例如ISO 26262標準定義了如何評估和確保汽車電子/電氣系統的功能安全。當進行功能安全評估時,可以考慮E2E保護作為降低數據通信相關風險的一個措施。E2E之所以能夠保證一定程度的功能安全是因為E2E保護的目標是確保數據在傳輸過程中的完整性,避免由于噪聲、干擾或軟件錯誤導致的數據損壞或失真。它包括兩大核心要素:
1.通過計算和驗證校驗和或CRC(循環冗余校驗),確保數據在傳輸過程中沒有被篡改或損壞。如果一個關鍵系統(例如制動系統或轉向系統)收到了損壞或篡改的數據,它可能會做出不正確的決策,從而導致功能失效甚至危險情況。E2E保護通過確保數據完整性來減少這種風險。
2.通過順序計數器(Counter)來確保消息按預期的順序到達,能夠檢測丟失的消息或重復的消息。如果接收端的計數器值與預期不符,這可能是由于消息丟失或者重復。對于某些功能安全關鍵的應用,如自動駕駛或緊急剎車,如果系統收到的數據是間斷的,可能會導致不適當或延遲的響應。
接下里將結合AUTOSAR官方文檔中的E2E Profile 1例子,具體闡述E2E是如何工作的。E2E Profile 1由以下四個組件構成:
CRC:循環冗余檢查。Profile 1通常使用一個8位的CRC,采用CRC-8-SAE J1850-0x1D多項式計算。
Counter:計數器在每次消息發送時增加。對于Profile 1,這通常是一個4位的值,這意味著它的范圍是從0到14。當達到最大值后,計數器會回繞到0。
Data ID:用來唯一標識數據元素或消息的標識符。對于Profile 1,這通常是16位的值,用來參與計算CRC,但不會進行實際的數據傳輸。
Timeout monitoring:超時監控是由E2E管理模塊對counter的值計算得到。
需要注意的是E2E保護中的CRC不同于CAN或者FlexRay通訊協議的CRC校驗。其中CAN或者FlexRay通訊協議的CRC是由通信控制器中的硬件支持提供,并不是由E2E管理模塊生成的。E2E保護中的CRC是CAN或者FlexRay通訊協議中傳輸的數據段內容。另外Counter的值是0到14,值15是用來表示錯誤的。在AUTOSAR 官方文檔中E2E Profile 1對于CRC以及Counter是可以自定義其起始位置的,在本文中將CRC起始位置定義為bit 0且長度為8,Counter起始位置定義為bit 8,且長度為4。如圖2所示。
圖2 E2E保護報文矩陣示意圖
CRC的計算過程中,一般會對整個報文傳輸的數據進行校驗。其中未使用的bit位用0xFF代替。根據圖2報文矩陣定義,CRC的計算如圖3計算示意圖所示,在圖3中CRC計算的結果填充在了報文的第一個Byte,Counter值填充在了報文第二個Byte的低位。
圖3 CRC計算示意圖
E2E保護的工作原理,作為發送端需要對每一條消息增加順序計數器的值,使用Data ID、Counter以及傳輸數據計算CRC,將Counter和CRC添加到消息中并發送。作為接收方使用接收到的Data和Counter計算CRC,檢查計算出的CRC是否與接收到的CRC匹配,檢查Counter值以確定消息的連續性。如果在接收端CRC不匹配,這意味著數據可能已經被損壞。根據系統的需求,可以選擇觸發一個錯誤報告或者采取其他的錯誤處理措施。如果Counter值不是預期的(例如,如果它比上一條消息的值小),這可能意味著消息是過時的或者已經被重復。同樣,可以根據具體情境進行處理,如丟棄數據或者觸發一個警告。對于Counter校驗機制如圖4所示。
圖4 counter校驗機制
在圖4中,會根據配置的參數對counter進行校驗,配置項包括允許最大的丟幀的數量,允許重復的計數器的數量等。通過對計數器的校驗,會導致8種E2E狀態:
E2E_P01STATUS_OK:Counter計數器正確并且CRC校驗正確。
E2E_P01STATUS_NONEWDATA:一個報文周期內未接收到該E2E報文。
E2E_P01STATUS_WRONGCRC:CRC校驗失敗。
E2E_P01STATUS_SYNC:在收到期望之外的Counter后,收到了一個正確的CRC與合理的Counter。
E2E_P01STATUS_INITIAL:初始化階段。
E2E_P01STATUS_REPEATED:收到的Counter是重復的。
E2E_P01STATUS_OKSOMELOST:接收到的E2E報文連續兩幀之間的Counter差值大于1但小于MaxDeltaCounterInit。
E2E_P01STATUS_WRONGSEQUENCE:接收到的E2E報文連續兩幀之間的Counter差值大于MaxDeltaCounterInit。
以上,本文對E2E保護機制的核心概念以及實現原理進行了簡單的闡述。如果想對E2E保護機制在AUTOSAR中如何進行配置,需要進一步閱讀AUTOSAR官方文檔。
參考文獻:
AUTOSAR.(2022).E2E Protocol Specification. AUTOSAR Standard Working Specification.
AUTOSAR.(2022).pecification of SW-C End-to End Communication Protection Library. AUTOSAR Standard Working Specification.
審核編輯:湯梓紅
-
AUTOSAR
+關注
關注
10文章
339瀏覽量
21355 -
車載系統
+關注
關注
1文章
131瀏覽量
27078 -
車載通信
+關注
關注
0文章
42瀏覽量
13402
發布評論請先 登錄
相關推薦
評論