導語：近期項目中遇到壹些E2E的診斷故障，涉及到整車需求和AutoSAR配置，對這個概念重新做了下梳理，與大家交流。由於E2E機制比較成熟，本文章內容更多出自於AutoSAR標準、ISO?26262?和相關文獻，這裏只撿重點和個例對這個概念做下解讀。
1.?什麽是E2E？
2.?為什麽要做E2E？
3.?怎麽做E2E？
4.?常用的保護形式有哪些?
5.?E2E狀態機與配置參數
1.?什麽是E2E？
首先明確壹點，E2E並非只是在汽車領域應用，任何通信領域都會涉及，只不過是AutoSAR對這壹協議/機制做了規範。
E2E，全稱End?to?End，中文即端到端的通信保護，是壹種針對安全相關數據，為防止通信鏈路中可能存在的故障（HW/SW），?在?通信節點?之間?執行的?壹種數據保護協議/機制。其適用於多種網絡結構：CAN、?CANFD、FlexRay、Ethernet等。
具體，如下圖所示,假設有兩個ECU：?ECU1和ECU2，兩節點之間通過CAN總線通信，ECU1要將某壹安全信號傳輸至ECU2，如果采用E2E?profile1保護協議（AutoSAR?E2E?Library），ECU1在對必要信息數據做傳遞之外，還要補充CRC和Counter信息給至ECU2，ECU2在接收到這幀數據後，會計算CRC，然後與接收到的進行比較，ECU2會根據校驗結果執行下壹步動作（這就涉及到故障的處理，之前有做過簡要概述，可參見文章《?電動汽車動力系統的"望聞問切"?|?故障診斷?》）。
不知道是否註意到，所謂的E2E其實是對兩個關鍵對行為的保護：發送端（sender）和接收端（receiver）。標準中定義如下：
E2E所涉及的所有保護機制都圍繞這兩個行為展開的。
2.?為什麽要做E2E？
通過上述簡介，可以get到，E2E保護概念的核心是針對安全相關的數據交換，需要在運行時進行保護，以消除通信鏈路中可能的失效帶來的影響，這就是為什麽要做E2E的本質原因。另外，E2E也是汽車動力系統實現ASIL?D的必要手段。
那麽，數據交換過程中可能的失效模式?有哪些呢？關於這個問題ISO26262?中有總結，如下:
●?信息的重復發送?(Repetition?of?Information)，相同的信息被收到了多次
●?信息的丟失?(Loss?of?Information)，整條或者信息的壹部分在通信過程中丟失
●?信息的延遲?(Delay?of?Information)，接收信息的時間異於期望的時間
●?信息的插入?(Insertion?of?Information)，多余的內容被插入到信息中
●?假冒的或者不正確的尋址?(Masquerade?or?Incorrect?Addressing?of?Information)，假冒的發送者發送未認證的信息被接收端接受，或者正確的信息被錯誤的接收端接受
●?信息順序錯誤?(Incorrect?Sequence?of?Information)，數據流中的信息順序錯誤
●?信息破損?(Corruption?of?Information)，信息的內容被篡改
●?向多個接收端發送非對稱信息?(Asymmetric?information?sent?from?a?sender?to?multiple?receivers)，接收端收到的數據不壹致
●?僅部分接收端收到發送者的信息?(Information?from?a?sender?received?by?only?a?subset?of?receivers
●?阻塞通信通道?(Blocking?access?to?communication?channel)
這些失效可能發生的數據交換的場景包括，與I/O外設的通信，基於數據總線的通信等等。產生失效的原因包括系統性失效與隨機失效，在軟件端面，如生成代碼過程中的錯誤，手動編碼引入的錯誤，網絡協議棧的錯誤等等；硬件端面，如處理器的故障，網絡硬件的故障，電磁輻射等等。
3.?怎麽做E2E?
AutoSAR中有對E2E?Library?的定義，其中提供了多種用於E2E保護的函數供選擇，每種profile都有自己特定的機制、參數和數據格式，用戶可以根據需求選擇。無論何種profile，基本可分為以下兩步驟：
Step1：?發送端通過增加控制字段拓展數據結構，控制字段壹般包含：checksum、counter等，擴展處的字段由RTE進行發送，如下圖所示：
Step2：?接收端對上述整個字段內的數據進行驗證，如果pass，則移除其中控制字段，並將應用數據交給SWCs處理；如果no?pass，則執行安全保護機制。
那麽，在具體對profile做配置時，常用的保護保護形式有哪些呢?
4.?常用的保護形式有哪些呢？
這裏對profile中提到的壹些保護機制做下解釋。
CRC
循環冗余校驗，是壹種根據網絡數據包或文件等數據簡短固定位數校核碼的快速算法，主要用來檢測或校驗數據傳輸或保存後，可能出現的錯誤，利用除法及余數的原理。
此外，ISO26262-5?中明確說明CRC的覆蓋率主要取決於報文長度、CRC字段大小和多項式形式，詳情可參見ISO26262文檔。
特別說明，我們習慣說“CRC?checksum校驗”，其實這裏涉及兩種校驗方法。
Checksum
顧名思義，和的校驗，在數據處理和數據通信領域中，用於校驗目的的壹組數據項的和，這些數據項目可以是數字或在計算校驗總和過程中看作數字的其他字符串，其類型有多種：XOR?checksum,?1's?complement?Checksum,?2's?complement?Checksum等。
Counter
在報文中占4bit，範圍0~14?(profile1)，用於計數，發送端每發送壹幀報文，計數+1，ECU1將計數值發給ECU2，ECU2對收到的counter進行比較，確認是否及時接收，當達到14，重新開始計數。
Timeout
通過counter來評估報文是否丟失、延遲等。
Data?ID
壹般為2個byte，是ECU1和ECU2之間提前定好的特殊字段，AutoSAR?profile1中對E2E_P01DataIDMode定義幾種模式：BOTH、ALT、LOW、NIBBLE，Data?ID用於報文checksum，但是特別註意的是這壹段DID並不作為報文傳輸數據的壹部分放在總線上，僅僅作為報文密鑰，這就好比特務接頭，開始聊正文之前，總要私下先確認好暗號，以證明“我接收的指令確實是期待的發送方所發送的”。
特別說明下增加Data?ID字段的報文如何計算checksum：
例如，Autosar?E2E?profile?1?規定采用CRC-8-SAE?J1850?，對應多項式為0x1D?(x8?+?x4?+?x3?+?x2?+?1)，通常情況下報文數據場中Byte0?用於存放報文CheckSum?數據，byte?1~byte7?存放報文其它數據，報文數據場存放數據下圖所示。
具體步驟如下。
Step1：計算Data?ID字段內CRC值?（註：實際初始值為初始值取反）。
Step2：計算Byte1~Byte7字段內CRC值（註：實際初始值為上壹步校驗值取反）。
Step3：?將上壹步校驗值取反，得到最終值。
以下是AutoSAR中針對profile1保護機制的原始定義，供參考：
5.?E2E狀態機與配置參數
E2E數據的接收是周期性的，接收方在每個周期內，調用對應的profile的檢測接口，針對接收到的數據進行檢測，驗證這個周期內接收到的數據是正確的，並提供額外信息說明檢測到的失效形式。下圖給出了狀態及遷移的說明，從中可以看到數據是否有用是根據窗口期內error數和ok數來做判斷。
那麽，E2E保護需要的配置參數有哪些呢？
以AUTOSAR?E2E?Protocol?Specification1.3.0?為例，目前E2E中系統支持配置的設置信息如下圖所示：
以上就是對E2E概念和保護邏輯做的簡要介紹，它是汽車動力總成實現ASIL?D的必經之路，更多內容大家感興趣可以直接查看標準《AutoSAR?E2E?Protocol?Specification》。
Reference
《AutoSAR?E2E?Protocol?Specification》
《ISO?26262?-?"Road?vehicles?-?Functional?safety"》
最後做個統計，臭皮匠試驗室暫定年底前舉辦壹次培訓交流會，形式待定，培訓主題：?電動汽車三合壹電驅動系統標準解讀與試驗開發。?具體暫定以下幾方面內容：
1）結合項目經驗，從整車需求角度，對三合壹系統試驗標準進行梳理，建立試驗標準思維導圖；
2）理解FMEA與試驗的關聯性；
3）講解項目開發不同階段下的試驗如何分布；
4)路譜的采集與轉化，以及對三合壹系統和部件的影響；
5）對系統疲勞耐久、環境適應性、高低壓電氣負荷適應性中的關鍵點、難點做解讀。
詳細交流會信息後續會正式推送給大家。感興趣的可以私信。
最後，感謝大家壹直以來的支持，感謝有妳！
本文來源於汽車之家車家號作者，不代表汽車之家的觀點立場。