基于AUTOSAR的點到點安全通信的實現

， ，

(同濟大學 汽車學院，上海 201804)

基于AUTOSAR的點到點安全通信的實現

鐘再敏，黃熙，章鴻濱

(同濟大學汽車學院，上海201804)

功能安全的概念在汽車嵌入式系統領域越發到關注，汽車開放系統架構AUTOSAR(Automotive Open System Architecture)是目前國際流行的標準軟件架構，它在AUTOSAR4.1的版本中針對功能安全首次提出了點到點(End-to-End，E2E)的安全通信機制；為保證汽車各組件間的通信安全，對在AUTOSAR架構下的E2E安全通信機制進行了研究，采用E2E Profile 2的方法來實現E2E安全通信，旨在解決如何保證電子控制單元(Electronic Control Unit，ECU)之間以及ECU內部不同核之間，不同SWC(software component)之間數據的安全通信的問題；基于AUTOSAR架構，通過在電子控制單元核內通信采用E2E Protection Wrapper的通信方式，跨電子控制單元核外通信采用COM E2E Callout的通信方式實現了通信機制的搭建；通過對ECU內部及跨ECU的通信測試，表明該方法能有效的檢測通信過程中的重復發送錯誤、CRC(Cyclic Redundancy Check)校驗和錯誤及發送序列錯誤等問題。

點到點通信；AUTOSAR；功能安全；ECU核內通信；跨ECU通信

0 引言

車載網絡的安全通信一直倍受關注，早有主機廠和零部件供應商在車載安全通信方面做了探索和實現，普遍采用的方式是添加循環冗余校驗的信息，信息在傳遞過程中一旦被篡改可以在信息接收端被識別，保證錯誤的信息不會被系統使用。但是這種方式，只能識別出信息被篡改，卻無法發現信息的丟失和重復發送，因此后面加入了計數器信息，用于標識當前信息的序列號，在信息的接收端就可以發現信息的丟失和重復發送。不同的廠家之間安全通信的實現方式各不相同，因此不同廠家實現的控制器在同一個通信網絡中通信存在兼容性問題。汽車開放系統架構標準AUTOSAR，采用分層的軟件架構，規范通信接口，可實現軟硬件的分離，可極大提高軟件的可移植性和可復用性[1-2]。在AUTOSAR4.1[3-6]的版本后陸續提出和完善了點到點(E2E)的安全通信機制，其囊括了多種的保護方式，并提出了安全通信標準的實現方式，不僅解決了控制器安全通信的問題，同時依托AUTOSAR軟件架構可以保證軟件的可移植性和廠家合作之間的兼容性。

本文采用E2E Profile 2通信安全機制，首先介紹了軟硬件導致的常見的通信失效類型，提出E2E安全通信的必要性，其次介紹了E2E安全通信保護機制，之后介紹了AUTOSAR架構下E2E安全通信的具體實現，最后進行測試和驗證。

1 軟硬件導致的通信失效類型

在AUTOSAR中E2E的應用場景相對集中，E2E的實施是為了保證ECU之間以及ECU內部不同核之間，不同SWC之間數據的安全通信，即在系統運行過程中，動態地識別軟硬件故障引起通信失效，保證系統的可靠運行。E2E安全通信是點到點之間的檢測，它可以發現點到點之間由于軟硬件原因導致的通信失效。圖1列舉了AUTOSAR架構下E2E的幾個應用場景。

圖1中S1～S4代表的是軟件導致的通信失效：S1指的是RTE生成代碼出錯；S2指的是COM服務層代碼出錯；S3指的是通信接口層和通信的驅動層之間可能存在問題，出錯原因與S2的原因類似；S4指的是跨核通信中IOC出錯。這4種通信失效的場景都可以采用E2E安全通信進行檢測。圖1中H1-H3代表的是硬件導致的通信失效：H1指的是通信的物理網絡存在故障；H2指的是通信網絡的接口存在電磁兼容性問題；H3指的是微控制器故障。這3種通信失效的場景同樣可以采用E2E安全通信進行檢測。

2 E2E安全通信保護機制

圖1 AUTOSAR架構下E2E的應用場景

本文在AUTOSAR架構下采用E2E Profile 2來實現E2E安全通信。E2E Profile 2包含3個保護方式：分別是循環冗余校驗，計數器和數據ID。通過E2E Profile 2處理后的數據Buffer分布如圖2所示。E2E Profile 2規定Data[0]必須存放CRC校驗和，Data[1]的低4個位必須存放Sequence Counter。從Data[2]開始存放需要保護的數據。

圖2 E2E Profile 2處理后的數據Buffer

其中參與CRC校驗和計算的字段可以根據用戶配置而定，我們采用的是下圖3的方式，校驗和包含Data ID部分和排除CRC存儲字段外的所有的數據，雖然Data ID并沒有顯性的通過報文發送出去，但是它的校驗信息包含在CRC中，其中需要填充的部分統一填充為0xF。

圖3 CRC校驗和的計算方式

采用E2E Profile 2安全通信需要額外的引入兩個數據元素，分別是Sequence Counter與CRC校驗和，它們必須隨著被保護數據一起從發送端傳送到接收端。在進行軟件組件接口定義的時候必須定義相關的數據元素，尤其是在跨ECU通信中還必須在DBC中預留出相關的信號用于傳輸Sequence Counter與CRC校驗和。

E2E Profile 2的發送端和接收端，分別維護著一個E2E發送端的狀態機和一個E2E接收端的狀態機。在發送端，E2E會根據發送端的狀態機，首先計算Sequence Counter并寫入數據Buffer，然后根據被保護的數據、靜態配置好的數據ID列表以及Sequence Counter，計算CRC校驗和，并寫入發送Buffer。完成上述操作后，E2E就返回數據Buffer給調用者，最終由調用者將CRC校驗和、Sequence Counter與被保護的數據一起發送出去。被保護的數據并不會被E2E改變，E2E并不負責加密。

在接收端，E2E根據接收端狀態機先計算出預想的Sequence Counter，再根據靜態配置好的數據ID列表、Sequence Counter和接收到的數據，計算出CRC校驗和。這里接收到的數據僅僅指發送端發送的需要被保護的數據。計算出CRC校驗和后，E2E會與發送端發過來的CRC校驗和進行比較，如果一致，則繼續判斷Sequence Counter是否與期望的Sequence Counter一致。如果校驗結果完全正確或者在容忍的范圍內，則E2E Profile 2返回正確的返回值；如果校驗結果有問題，則需要進一步解析出錯的類型，并將錯誤狀態更新到E2E的狀態機。E2E只做數據準確性的校驗，至于出現數據丟失或者重復，應用層是否采用此數據，那是應用層數據訪問的策略，與E2E無關。

在AUTOSAR4.2.2標準中，E2E的通信有3種不同的實現方式：第一種是實現方式E2E Transformer；第二種實現方式是E2E Protection Wrapper；第三種實現方式是COM E2E Callout。本文中，同一個ECU內部的SWC之間的E2E通信采用E2EPW的實現方式，跨ECU的E2E通信采用COM E2E Callout的實現方式。在跨ECU的通信中，E2E通信添加的控制數據需要通過CAN網絡進行傳輸，故需要修改DBC文件，對需要保護的信號添加相應的校驗和字段和序列號字段。

3 AUTOSAR架構下E2E安全通信的實現

3.1 應用層架構設計

應用層開發的流程和需求主要包括以下六步，可參看圖4：第一步，DataType的定義；第二步，Interfaces的定義；第三步，SWC的定義；第四步，System的定義；第五步，ECU Extract的生成；第六步，OS與RTE的配置[7-9]。本文只介紹和E2E通信相關的配置項。

1)Interface定義

Interface定義如表1所示，在同一個ECU內部的兩個SWC通信引用的接口為E2E_DataInterface_0。在跨ECU通信中，將CAN的發送和接收接口定義為E2E_Can_Input和E2E_Can_Output。它們均為S-R端口，內部包含3個數據元素，分別為被保護的數據、序列號Counter及CRC校驗和。

圖4 應用層的開發流程和需求

2)SWC的定義

本文應用層需要在ECU內部實現兩個SWC之間的E2E通信，這兩個SWC分別是CPT_E2E_InterSWC_1(作為發送SWC)和CPT_E2E_InterSWC_2(作為接收SWC)。

表1 Interface定義

與此同時，還有一個SWC與其他ECU的SWC通過CAN網絡進行E2E通信，即將CPT_E2E_SWC這個SWC的接收發送端口上的數據MAPPING到CAN網絡的信號上。

SWC的定義如表2所示。以發送端SWC功能定義為例，E2E_InterSWC_1包含一個PPort端口和一個內部行為。內部行為包含兩個運行實體，其中一個運行實體關聯一個周期性的事件運行。另外一個是初始化的運行實體。此外還需要為周

表2 SWC的定義

期性運行的可運行實體添加數據訪問點，用于發送數據。其余兩個SWC定義類似。

3.2 基礎軟件層及OS配置

應用層架構設計工具與基礎軟件配置工具進行信息交互的文件是ARXML文件，主機廠只要把前一階段生成的ECU Extract of System Description交付給一級供應商，一級供應商就可以進行底層基礎軟件的配置。基礎軟件層代碼庫及其配置工具來自某商用公司開源的AUTOSAR基礎軟件層解決方案。該部分在AUTOSAR軟件架構RTE層的下面，MCAL層的上面。基礎軟件層配置后，需要將基礎軟件層配置的XML文件拷貝到AUTOSAR應用層配置軟件中，為接下來的OS配置和RTE配置做好準備[8-10]。該部分本文不作介紹。在應用層配置軟件中可進行操作系統的配置，用戶可以根據需要將不同的SWC的runnable和基礎軟件層的MainFunction映射到操作系統的任務中[11]。

3.3 芯片驅動設計

芯片驅動設計目的是使上層軟件與微處理器型號無關，包含MCU中內部外設的驅動和使用MCU內存映射的外部設備的驅動。本部分開發工作主要面向控制器抽象層(Microcontroller Abstraction)，屬于AUTOSAR軟件架構的最底層，包括Microcontroller Driver、Memory Driver、Communication Driver以及I/O Driver等。具體需要配置的模塊有MCU、CAN、Port。Mcal模塊配置完成就可以生成相關的配置代碼，它是以源文件的形式生成。除了配置代碼，還需要配置Mcal的靜態代碼，二者配合才能集成編譯。

3.4 基于E2EPW通信保護的代碼實現

發送端的軟件組件E2E_InterSWC_1內部的可運行實體E2E_InterSWC_1_REProc周期性被操作系統任務AppTask_10ms調度，如下所示:

FUNC(void,E2E_InterSWC_1)E2E_InterSWC_1_REProc(void)

{

if(E2E_TestActive==0)

{

E2EPW_error_SWC1=E2EPW_Write_E2E_InterSWC_1(&E2E_InterSWC_Var1);

}

}

函數E2EPW_Write_E2E_InterSWC_1的參數是一個結構體指針，該結構體的類型為應用層配置軟件中E2EImplementationDataType_0，如下所示：

typed ef struct {

uint8 Impl_CKS;

uint8 Impl_Alive_Cnt;

uint8 Impl_Data;

} E2EImplementationDataType_0;

在函數E2EPW_Write_E2E_InterSWC_1內部調用E2E_P02Protect函數，進行發送端E2E控制數據(CRC,Counter)的計算，之后通過RTE提供的API函數，將控制數據和需要保護的數據發送給接收端SWC，如下所示:

FUNC(unit32,E2E_InterSWC_1)E2EPW_Write_E2E_InterSWC_1

(E2EImplementationDataType_0*E2E_InterSWC_var1)

{unit32 E2EPW_error=E2E_E_OK;

static boolean FirstRun=TRUE;

Std_ReturnType E2E_error;

E2E_error=E2E_P02Protect(&E2E_P02_StaticCfg_SWC1,&E2E_P02SenderState_SWC1,E2E_InterSWC_var1);

Rte_Write_E2E_InterSWC_1_PPortPrototype_0_Alive_Cnt(E2E_InterSWC_var1->Impl_Alive_Cnt);

Rte_Write_E2E_InterSWC_1_PPortPrototype_0_CKS(E2E_InterSWC_var1->Impl_CKS);

Rte_Write_E2E_InterSWC_1_PPortPrototype_0_Data(E2E_InterSWC_var1->Impl_Data);

return((RTE_E_OK)|(E2EPW_error<<8)|(E2E_error<<16));

}

接收端軟件組件E2E_InterSWC_2代碼原理與發送端類似，可運行實體E2E_InterSWC_2_REProc的內部通過函數E2EPW_Write_E2E_InterSWC_2調用RTE提供的API函數來讀取控制數據和E2E保護的數據，再調用E2E_P02Check函數來校驗接收的數據(CRC,Counter)，最后將校驗結果返回。此外，在ECU的啟動時，需要在E2E安全通信之前初始化發送端和接收端E2E狀態的結構體，如下所示。

FUNC(Std_ReturnType,E2E_InterSWC_1)E2EPW_WriteInit_E2E_InterSWC_1(void)

{Std_ReturnType

E2EPW_error=E2E_E_OK;

E2E_P02SenderState_SWC1.Counter=0;

return E2EPW_error;

}

FUNC(Std_ReturnType,E2E_InterSWC_1)E2EPW_ReadInit_E2E_InterSWC_2(void)

{ Std_ReturnType E2EPW_error=FALSE;

E2E_P02ReceiverState_SWC2.LastValidCounter=0;

E2E_P02ReceiverState_SWC2.LostData=0;

E2E_P02ReceiverState_SWC2.MaxDeltaCounter=0;

E2E_P02ReceiverState_SWC2.NewDataAvailable=FALSE;

E2E_P02ReceiverState_SWC2.WaitForFirstData=TRUE;

E2E_P02ReceiverState_SWC2.Status=E2E_P02STATUS_NONEWDATA;

E2EPW_error=TRUE;

return E2EPW_error;

}

3.5 基于COM E2E Callout通信保護的代碼實現

首先在基礎軟件配置工具中將PDU的發送和接收的回調函數配置好，會生成一個函數指針，并聲明該函數具有的參數和返回值類型。

Com_RxCbk_msg_RxCycle500_20_E2E和Com_RxCbk_msg_TxCycle500_20_E2E分別為發送和接收的回調函數。通過基礎軟件層配置工具生成配置代碼，其只是聲明了回調函數的形式，具體回調函數的定義需要用戶自己完成。

下面介紹COM端的代碼實現:發送端在PDU發送回調函數中直接調用E2E_P02Protect函數，如圖10所示。

FUNC(boolean,COM_CODE)Com_RxCbk_msg_TxCycle10_0_E2E(VAR(PduIdType,AUTOMATIC)id,P2VAR(unit8,AUTOMATIC,COM_APPL_DATA)ptr)

{

Std_ReturnType error,temporary_return;

if(E2E_ProfileSelector==0x02){

error=E2E_P02Protect(&E2E_P02_StaticCfg_msg_TxCycle10_0_E2E,&E2E_P02_SenderState_msg_TxCycle10_0_E2E,ptr);

count_TX_P02++;

if(error==0){

temporary_return=TRUE;

}

else{

temporary_return=error;

}

return temporary_return;

}

接收端在PDU接收回調函數中直接調用E2E_P02Check函數，如下所示:

FUNC(boolean,COM_CODE)Com_RxCbk_msg_RxCycle500_20_E2E(VAR(PduIdType,AUTOMATIC)id,P2CONST(unit8,AUTOMATIC,COM_APPL_CONST)ptr)

{Std_ReturnType error,temporary_return;

if(E2E_ProfileSelector==0x02){

E2E_P02ReceiverState_msg_Rxcycle500_20.NewDataAvailable=TRUE;

error=E2E_P02Check(&E2E_P02_StaticCfg_msg_RxCycle500_20_E2E,&E2E_P02_ReceiverState_msg_RxCycle500_20_E2E,ptr);

count_RX_P02++;

if((error==0)&&((E2E_P02ReceiverState500_20.Status==E2E_P02STATUS_OK)||

(E2E_P02ReceiverState500_20.Status==E2E_P02STATUS_OKSOMELOST)||

(E2E_P02ReceiverState500_20.Status==E2E_P02STATUS_INITIAL))){

temporary_return=TRUE;

}

else{

temporary_return=FALSE;

}

4 測試及驗證

4.1 基于E2EPW實現ECU內部通信測試

根據上文建立的模型，通過實驗測試ECU內部SWC之間的E2E通信，對于可能出現的錯誤的通信進行模擬。我們通過在發送端SWC發送數據時注入錯誤，查看接收端SWC的E2E狀態結構體，看E2E的通信檢測機制是否可以檢測出相應的錯誤。

E2E_TestActive是一個全局變量，我們添加在TRACE32上位機中作為標定量，表示程序是否進入測試。E2E_TestCase也是一個全局變量，我們將其作為標定量，表示不同的測試案例。此外，還需要在TRACE32上位機中添加一個觀測量E2E_P02ReceiverState_SWC2，該變量是接收端E2E的狀態結構體，存放當前數據校驗的結果。測試的流程如圖12所示。

首先測試正常通信，使E2E_TestActive=0，此時狀態位為E2E_P02STATUS_OK，表示通信正常。之后每次測試前應保證通信正常。使E2E_TestActive=1，此時狀態位為E2E_P02STATUS_REPEATED，表示發生重復發送錯誤。使E2E_TestActive=2，此時狀態位為E2E_P02STATUS_WRONGCRC，表示CRC檢驗和出錯。使E2E_TestActive=3，此時狀態位為E2E_P02STATUS_WRONGSEQUENCE，表示發送序列出錯。

圖12 基于E2EPW的E2E通信的測試流程圖

4.2 基于COM E2E Callout實現跨ECU通信測試

由于條件限制，本文通過開發工具模擬一個節點，捕捉開發板發送出來的CAN報文，修改CAN報文的ID，然后重新發給開發板。通過這樣的方式，模擬跨ECU之間的通信。

4.2.1 E2E跨ECU通信測試

1)常通信測試：在TRACE32中添加觀測量E2E_P02ReceiverState_msg_RxCycle500_20，這是COM層上E2E通信的狀態結構體，其內部保存對最新接收到的PDU的校驗結果。用CANoe和開發板配合構造一個閉環的通信過程來測試E2E跨ECU通信是否正常工作。此時接收端狀態結構體中Status為E2E_P02STATUS_OK，表示接收端校驗正常，Rte_ImplicitBufs會跟隨CAN報文內容動態變化。

2)異常通信測試：本文通過構造一個開環的通信過程測試E2E的檢錯能力，將CAN卡和開發板連接，此時上位機不對接收到的報文做處理，而是將我們自定義的報文發給開發板。發送端的Counter是0-15循環，如果我們通過E2E保護的數據沒有動態改變，則CAN報文在每個循環中只要Counter相同，那CAN報文的內容完全一致。首先保證接收端校驗正常，再人為的在報文中注入我們想要的錯誤來測試不同的錯誤。連續發送兩幀Counter為2的CAN報文來測試重復發送錯誤，此時接收端狀態結構體中Status為E2E_P02STATUS_REPEATED。改變Counter為2的CAN報文的內容，使其CRC校驗和出錯，然后發送給開發板，此時接收端狀態結構體中Status為E2E_P02STATUS_WRONGCRC。改變發送序列，在本應該發Counter為3的時候，發送Counter為4的給開發板，接收端狀態結構體中Status為E2E_P02STATUS_OKSOMELOST。

5 結論

本文在AUTOSAR架構下，采用E2E Profile 2實現了E2E安全通信。介紹了基于E2E Profile 2實現E2E安全通信的原理。在ECU內部通信采用E2E Protection Wrapper的通信模式，在ECU跨核通信采用COM E2E Callout的通信模式，描述了這兩種通信模式的搭建過程，并搭建實驗來模擬在這兩種模式下的通信錯誤，實驗表明，該方法能快速有效的檢測通信過程中的重復發送錯誤、CRC校驗和錯誤及發送序列錯誤等問題，保障汽車的通信安全。

[1] 魏學哲,戴海峰,孫澤昌.汽車嵌入式系統開發方法、體系架構和流程[J].同濟大學學報(自然科學版),2012,40(7):1064-1070.

[2]高煥吉． 基于AUTOSAR的汽車電子控制系統嵌入式軟件開發[J]. 汽車電器,2010(05): 11-14.

[3]AUTOSAR Administration．Specification of SW-C End to-End Communication Protection Library V4.2.2[EB/OL]. http://www.autosar.org/.

[4]AUTOSAR Administration．Specification of Module E2E Transformer V4.2.2[EB/OL]. http://www.autosar.org/.

[5]AUTOSAR Administration.Specification of Communication V4.2.1[EB/OL]. http://www.autosar.org/.

[6]Moessinger J． AUTOSAR-The Standard for Global Cooperation in Automotive SW Development[Z]. 2008.

[7]Voget S． AUTOSAR and the Automotive Tool Chain[C]. 2010.

[8]AUTOSAR Administration. Specification of Operating System V5.0.0 [EB/OL]. http://www.autosar.org/.

[9]ETAS GmbH．RTA-OS User Guide [Z]. 2014.

[10]AUTOSAR基礎軟件介紹[Z]. 2013.

[11]秦美峰． AUTOSAR軟件構件運行實體映射模型的研究與設計[D]. 成都：電子科技大學，2012.

RealizationofE2ESecureCommunicationBasedonAUTOSAR

Zhong Zaimin，Huang Xi，Zhang Hongbin

(School of Automotive Studies，Tongji University，Shanghai 201804，China)

The concept of functional safety has attracted more and more attention on the automotive embedded systems. The automotive open system software architecture standard AUTOSAR is the current international popular standard, it firstly proposes a End-to-End (E2E) security communication mechanism for functional security in the AUTOSAR4.1. In order to ensure the safety of communication between components of the vehicle, the E2E security communication mechanism under the framework of AUTOSAR is studied.By using E2E Profile 2 methods to realize the secure communication of E2E to solve the problem of how to ensure the secure communication between ECU or different SWC inside ECU.By using the E2E Protection Wrapper communication mode of the ECU nuclear communication and the COM Callout E2E mode of the ECU core communication, AUTOSAR architecture is built based on this communication mechanism.By testing the communication, the proposed method can effectively detect the repeated transmission errors, CRC checksum errors and send sequence errors .

E2E； AUTOSAR；functional safety； ECU kernel communication； cross-ECU communication

2017-04-09；

2017-04-26。

國家科技支撐計劃(2015BAG17B00)；國家科技支撐計劃(2015BAG03B00)。

鐘再敏(1973-)，男，博士，教授，主要從事車用電驅動控制技術方向的研究。

1671-4598(2017)10-0217-04

10.16526/j.cnki.11-4762/tp.2017.10.055

TP273

A