作者 | 沈平 上?？匕部尚跑浖?chuàng)新研究院汽車網(wǎng)絡安全組

來源 |鑒源實驗室

社群 |添加微信號“TICPShanghai”加入“上?？匕?1fusa安全社區(qū)”

隨著汽車行業(yè)逐步走向電氣化、智能化，車載系統(tǒng)的軟件和硬件復雜度不斷上升。如何確保這些復雜系統(tǒng)中的數(shù)據(jù)通訊安全和可靠，已成為業(yè)界關(guān)注的焦點。E2E（End-to-End）通訊常常指的是一個信息從發(fā)送端到接收端的完整傳輸過程，保障通訊中數(shù)據(jù)的完整性與安全性。AUTOSAR (AUTomotive Open System ARchitecture)是一個全球汽車工業(yè)的標準化項目，旨在為嵌入式汽車軟件創(chuàng)造一個共同的標準。在AUTOSAR架構(gòu)中，軟件被分為三個主要層次：應用軟件(ASW, Application Software)，基礎軟件(BSW, Basic Software)，以及運行時環(huán)境(RTE, Runtime Environment)。E2E通常是在ASW層實現(xiàn)的，它確保應用級的數(shù)據(jù)通信在發(fā)送和接收時的完整性。圖1所示為在AUTOSAR架構(gòu)中E2E保護示例圖。在圖1中E2E能夠減輕BSW層軟硬件以及ECU之間網(wǎng)絡通訊的故障。

圖1通過E2E保護減輕故障的示例圖

功能安全是關(guān)于硬件和軟件系統(tǒng)在出現(xiàn)故障時仍然保持安全狀態(tài)的能力。在車載系統(tǒng)中，例如ISO 26262標準定義了如何評估和確保汽車電子/電氣系統(tǒng)的功能安全。當進行功能安全評估時，可以考慮E2E保護作為降低數(shù)據(jù)通信相關(guān)風險的一個措施。E2E之所以能夠保證一定程度的功能安全是因為E2E保護的目標是確保數(shù)據(jù)在傳輸過程中的完整性，避免由于噪聲、干擾或軟件錯誤導致的數(shù)據(jù)損壞或失真。它包括兩大核心要素：

1.通過計算和驗證校驗和或CRC（循環(huán)冗余校驗），確保數(shù)據(jù)在傳輸過程中沒有被篡改或損壞。如果一個關(guān)鍵系統(tǒng)（例如制動系統(tǒng)或轉(zhuǎn)向系統(tǒng)）收到了損壞或篡改的數(shù)據(jù)，它可能會做出不正確的決策，從而導致功能失效甚至危險情況。E2E保護通過確保數(shù)據(jù)完整性來減少這種風險。

2.通過順序計數(shù)器（Counter）來確保消息按預期的順序到達，能夠檢測丟失的消息或重復的消息。如果接收端的計數(shù)器值與預期不符，這可能是由于消息丟失或者重復。對于某些功能安全關(guān)鍵的應用，如自動駕駛或緊急剎車，如果系統(tǒng)收到的數(shù)據(jù)是間斷的，可能會導致不適當或延遲的響應。

接下里將結(jié)合AUTOSAR官方文檔中的E2E Profile 1例子，具體闡述E2E是如何工作的。E2E Profile 1由以下四個組件構(gòu)成：

CRC：循環(huán)冗余檢查。Profile 1通常使用一個8位的CRC，采用CRC-8-SAE J1850-0x1D多項式計算。

Counter：計數(shù)器在每次消息發(fā)送時增加。對于Profile 1，這通常是一個4位的值，這意味著它的范圍是從0到14。當達到最大值后，計數(shù)器會回繞到0。

Data ID：用來唯一標識數(shù)據(jù)元素或消息的標識符。對于Profile 1，這通常是16位的值，用來參與計算CRC，但不會進行實際的數(shù)據(jù)傳輸。

Timeout monitoring：超時監(jiān)控是由E2E管理模塊對counter的值計算得到。

需要注意的是E2E保護中的CRC不同于CAN或者FlexRay通訊協(xié)議的CRC校驗。其中CAN或者FlexRay通訊協(xié)議的CRC是由通信控制器中的硬件支持提供，并不是由E2E管理模塊生成的。E2E保護中的CRC是CAN或者FlexRay通訊協(xié)議中傳輸?shù)臄?shù)據(jù)段內(nèi)容。另外Counter的值是0到14，值15是用來表示錯誤的。在AUTOSAR 官方文檔中E2E Profile 1對于CRC以及Counter是可以自定義其起始位置的，在本文中將CRC起始位置定義為bit 0且長度為8，Counter起始位置定義為bit 8，且長度為4。如圖2所示。

圖2 E2E保護報文矩陣示意圖

CRC的計算過程中，一般會對整個報文傳輸?shù)臄?shù)據(jù)進行校驗。其中未使用的bit位用0xFF代替。根據(jù)圖2報文矩陣定義，CRC的計算如圖3計算示意圖所示，在圖3中CRC計算的結(jié)果填充在了報文的第一個Byte，Counter值填充在了報文第二個Byte的低位。

圖3 CRC計算示意圖

E2E保護的工作原理，作為發(fā)送端需要對每一條消息增加順序計數(shù)器的值，使用Data ID、Counter以及傳輸數(shù)據(jù)計算CRC，將Counter和CRC添加到消息中并發(fā)送。作為接收方使用接收到的Data和Counter計算CRC，檢查計算出的CRC是否與接收到的CRC匹配，檢查Counter值以確定消息的連續(xù)性。如果在接收端CRC不匹配，這意味著數(shù)據(jù)可能已經(jīng)被損壞。根據(jù)系統(tǒng)的需求，可以選擇觸發(fā)一個錯誤報告或者采取其他的錯誤處理措施。如果Counter值不是預期的（例如，如果它比上一條消息的值?。?，這可能意味著消息是過時的或者已經(jīng)被重復。同樣，可以根據(jù)具體情境進行處理，如丟棄數(shù)據(jù)或者觸發(fā)一個警告。對于Counter校驗機制如圖4所示。

圖4 counter校驗機制

在圖4中，會根據(jù)配置的參數(shù)對counter進行校驗，配置項包括允許最大的丟幀的數(shù)量，允許重復的計數(shù)器的數(shù)量等。通過對計數(shù)器的校驗，會導致8種E2E狀態(tài)：

E2E_P01STATUS_OK：Counter計數(shù)器正確并且CRC校驗正確。

E2E_P01STATUS_NONEWDATA：一個報文周期內(nèi)未接收到該E2E報文。

E2E_P01STATUS_WRONGCRC：CRC校驗失敗。

E2E_P01STATUS_SYNC：在收到期望之外的Counter后，收到了一個正確的CRC與合理的Counter。

E2E_P01STATUS_INITIAL：初始化階段。

E2E_P01STATUS_REPEATED：收到的Counter是重復的。

E2E_P01STATUS_OKSOMELOST：接收到的E2E報文連續(xù)兩幀之間的Counter差值大于1但小于MaxDeltaCounterInit。

E2E_P01STATUS_WRONGSEQUENCE：接收到的E2E報文連續(xù)兩幀之間的Counter差值大于MaxDeltaCounterInit。

以上，本文對E2E保護機制的核心概念以及實現(xiàn)原理進行了簡單的闡述。如果想對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.

審核編輯：湯梓紅