最近做項目感覺很疲憊，而且有種深深的無力感，這個狀態(tài)估計要持續(xù)到五月底了。好久不更新了，趁著假期放松時間，簡單聊一聊E2E相關內(nèi)容。

（一）

在汽車控制器研發(fā)過程中，控制器與控制器之間（或者同一個產(chǎn)品主板與從板之間）的通訊必不可少。發(fā)送方與接收方在數(shù)據(jù)交換過程中，如果數(shù)據(jù)完整性被破壞，那么正常的通訊功能可能出現(xiàn)問題，進而影響安全相關的功能。

（二）

這里我們先來看下通訊相關的故障都有哪些，以及如何去理解這些故障模式。大家也可以自行查看ISO-26262標準，Part5-附錄D， Table D.1 -》D6 Communication bus 或者Part6-附錄D， D.2.4 Exchange of information

Repetition of information; -》 信息是否被多次收到？

Loss of information; -》 信息或者部分信息是否從傳輸?shù)男畔⒘髦斜灰瞥?/p>

Delay of information; -》 信息是否晚于預期收到的時間？

Insertion of information; -》 額外的信息是否被插入到傳輸?shù)男畔⒘髦校?/p>

Masquerade or incorrect addressing of information; -》 Masquerade 非真實的信息是否被接收方認為是真實信息？ -》 incorrect addressing 信息是否從不正確的發(fā)送方或者接收方接受了信息？

Incorrect sequence of information; -》 信息順序是否被改變？

Corruption of information; -》信息是否被損壞，從而改變了信息？

Asymmetric information sent from a sender to multiple receivers; -》 接收方是否從同一發(fā)送方接收到了不對稱/不同的信息？

Information from a sender received by only a subset of the receivers; or -》 信息是否只被部分接收方收到？

Blocking access to a communication channel. -》 通信通道訪問是否被阻止？

（圖片源于Autosar 官網(wǎng)文件）

（三）

26262中對通訊的保護，要求使用E2E （End-2-End protection）機制。E2E保護的概念是假設安全相關的數(shù)據(jù)交換在運行時應該被保護，進而免受通訊鏈路內(nèi)故障的影響。此類故障的例子--隨機硬件失效（e.g. CAN收發(fā)器的寄存器損壞），干擾（e.g. EMC因素），ECU內(nèi)部 （e.g. IOC， RTE， COM和網(wǎng)絡堆棧）實現(xiàn)VFB通訊的軟件內(nèi)的系統(tǒng)故障；當然也有外部的故障，比如，網(wǎng)關。

這里我們借鑒AUTOSAR對E2E的描述：從軟件組見角度看，通過RTE傳輸數(shù)據(jù)的行為類似于簡單的點到點連接。但是，這種抽象的實現(xiàn)，需要一個由應用層，通訊堆棧，驅(qū)動程序 和底層硬件組成的高復雜度的基礎設施。隨著復雜性的增加，潛在故障源的數(shù)量也在增加。E2E保護機制的使用假設在通訊期間必須保持安全相關數(shù)據(jù)的完整性，保護數(shù)據(jù)免受通訊鏈路內(nèi)故障的影響。E2E保護最重要的方面是保護能力的標準化和機制的靈活運用。

（四）

E2E保護的架構(gòu)實現(xiàn)如下，由應用數(shù)據(jù)組成的數(shù)據(jù)元素在發(fā)送方擴展了附加的控制信息，即E2E header。控制信息通常包含Checksum， Counter和其他選項。擴展數(shù)據(jù)元素被提供給RTE進行傳輸，如下圖所示。展示了E2E基本的原理。通過根據(jù)應用數(shù)據(jù)處理E2E header的內(nèi)容，在接收方驗證數(shù)據(jù)元素。在接收到的數(shù)據(jù)元素被處理并被接受為正確之后，控制信息被移除并且應用數(shù)據(jù)被提供給目標軟件組件。錯誤處理在接收器處執(zhí)行。

（五）

對于E2E的配置文件，這里依然借用AUTOSAR的描述。E2E的配置文件使用如下的數(shù)據(jù)保護機制的子集：

1）- CRC checksum，由CRC庫提供；

2）- Sequence Counter 在每次傳輸請求時遞增，在接收端檢查該值是否正確遞增；

3）- Alive Counter 在每次傳輸請求時遞增，如果它發(fā)生變化，則在接收端檢查該值，但不檢查正確的遞增。

4）- A specific ID 通過端口發(fā)送的每個端口數(shù)據(jù)元素的特定ID（全局到系統(tǒng)，其中系統(tǒng)可能包含多個ECU）；

5）- Timeout Detection 接收方通訊超時和發(fā)送方確認超時；

AUTOSAR中一共提出了3種 E2E 配置文件 （其中配置1 有兩個variants）。

Note： 一般情況下，都是只應用標準的配置文件。非標準的E2E配置文件只能用于特殊場景，比如 legacy software。

下面我們來看看各配置文件的保護機制：

Note： E2E profile4專門為符合ASIL-D標準的長數(shù)據(jù)傳輸而設計。

本文主要是簡單聊聊E2E能保護什么錯誤。關于E2E保護，還涉及E2E的狀態(tài)機，E2E保護包裝，E2E傳輸管理，RTE數(shù)據(jù)傳輸，檢測和響應等，這里不再過多闡述。感興趣的小伙伴可以到AUTOSAR官網(wǎng)去查看下相關資料。

審核編輯 ：李倩