， ，

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

基于AUTOSAR的點到點安全通信的實現(xiàn)

鐘再敏，黃熙，章鴻濱

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

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

點到點通信；AUTOSAR；功能安全；ECU核內(nèi)通信；跨ECU通信

0 引言

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

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

1 軟硬件導(dǎo)致的通信失效類型

在AUTOSAR中E2E的應(yīng)用場景相對集中，E2E的實施是為了保證ECU之間以及ECU內(nèi)部不同核之間，不同SWC之間數(shù)據(jù)的安全通信，即在系統(tǒng)運行過程中，動態(tài)地識別軟硬件故障引起通信失效，保證系統(tǒng)的可靠運行。E2E安全通信是點到點之間的檢測，它可以發(fā)現(xiàn)點到點之間由于軟硬件原因?qū)е碌耐ㄐ攀?。圖1列舉了AUTOSAR架構(gòu)下E2E的幾個應(yīng)用場景。

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

2 E2E安全通信保護機制

圖1 AUTOSAR架構(gòu)下E2E的應(yīng)用場景

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

圖2 E2E Profile 2處理后的數(shù)據(jù)Buffer

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

圖3 CRC校驗和的計算方式

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

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

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

在AUTOSAR4.2.2標(biāo)準(zhǔn)中，E2E的通信有3種不同的實現(xiàn)方式：第一種是實現(xiàn)方式E2E Transformer；第二種實現(xiàn)方式是E2E Protection Wrapper；第三種實現(xiàn)方式是COM E2E Callout。本文中，同一個ECU內(nèi)部的SWC之間的E2E通信采用E2EPW的實現(xiàn)方式，跨ECU的E2E通信采用COM E2E Callout的實現(xiàn)方式。在跨ECU的通信中，E2E通信添加的控制數(shù)據(jù)需要通過CAN網(wǎng)絡(luò)進行傳輸，故需要修改DBC文件，對需要保護的信號添加相應(yīng)的校驗和字段和序列號字段。

3 AUTOSAR架構(gòu)下E2E安全通信的實現(xiàn)

3.1 應(yīng)用層架構(gòu)設(shè)計

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

1)Interface定義

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

圖4 應(yīng)用層的開發(fā)流程和需求

2)SWC的定義

本文應(yīng)用層需要在ECU內(nèi)部實現(xiàn)兩個SWC之間的E2E通信，這兩個SWC分別是CPT_E2E_InterSWC_1(作為發(fā)送SWC)和CPT_E2E_InterSWC_2(作為接收SWC)。

表1 Interface定義

與此同時，還有一個SWC與其他ECU的SWC通過CAN網(wǎng)絡(luò)進行E2E通信，即將CPT_E2E_SWC這個SWC的接收發(fā)送端口上的數(shù)據(jù)MAPPING到CAN網(wǎng)絡(luò)的信號上。

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

表2 SWC的定義

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

3.2 基礎(chǔ)軟件層及OS配置

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

3.3 芯片驅(qū)動設(shè)計

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

3.4 基于E2EPW通信保護的代碼實現(xiàn)

發(fā)送端的軟件組件E2E_InterSWC_1內(nèi)部的可運行實體E2E_InterSWC_1_REProc周期性被操作系統(tǒng)任務(wù)AppTask_10ms調(diào)度，如下所示:

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);

}

}

函數(shù)E2EPW_Write_E2E_InterSWC_1的參數(shù)是一個結(jié)構(gòu)體指針，該結(jié)構(gòu)體的類型為應(yīng)用層配置軟件中E2EImplementationDataType_0，如下所示：

typed ef struct {

uint8 Impl_CKS;

uint8 Impl_Alive_Cnt;

uint8 Impl_Data;

} E2EImplementationDataType_0;

在函數(shù)E2EPW_Write_E2E_InterSWC_1內(nèi)部調(diào)用E2E_P02Protect函數(shù)，進行發(fā)送端E2E控制數(shù)據(jù)(CRC,Counter)的計算，之后通過RTE提供的API函數(shù)，將控制數(shù)據(jù)和需要保護的數(shù)據(jù)發(fā)送給接收端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代碼原理與發(fā)送端類似，可運行實體E2E_InterSWC_2_REProc的內(nèi)部通過函數(shù)E2EPW_Write_E2E_InterSWC_2調(diào)用RTE提供的API函數(shù)來讀取控制數(shù)據(jù)和E2E保護的數(shù)據(jù)，再調(diào)用E2E_P02Check函數(shù)來校驗接收的數(shù)據(jù)(CRC,Counter)，最后將校驗結(jié)果返回。此外，在ECU的啟動時，需要在E2E安全通信之前初始化發(fā)送端和接收端E2E狀態(tài)的結(jié)構(gòu)體，如下所示。

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通信保護的代碼實現(xiàn)

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

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

下面介紹COM端的代碼實現(xiàn):發(fā)送端在PDU發(fā)送回調(diào)函數(shù)中直接調(diào)用E2E_P02Protect函數(shù)，如圖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接收回調(diào)函數(shù)中直接調(diào)用E2E_P02Check函數(shù)，如下所示:

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實現(xiàn)ECU內(nèi)部通信測試

根據(jù)上文建立的模型，通過實驗測試ECU內(nèi)部SWC之間的E2E通信，對于可能出現(xiàn)的錯誤的通信進行模擬。我們通過在發(fā)送端SWC發(fā)送數(shù)據(jù)時注入錯誤，查看接收端SWC的E2E狀態(tài)結(jié)構(gòu)體，看E2E的通信檢測機制是否可以檢測出相應(yīng)的錯誤。

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

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

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

4.2 基于COM E2E Callout實現(xiàn)跨ECU通信測試

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

4.2.1 E2E跨ECU通信測試

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

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

5 結(jié)論

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

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

[2]高煥吉． 基于AUTOSAR的汽車電子控制系統(tǒng)嵌入式軟件開發(fā)[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基礎(chǔ)軟件介紹[Z]. 2013.

[11]秦美峰． AUTOSAR軟件構(gòu)件運行實體映射模型的研究與設(shè)計[D]. 成都：電子科技大學(xué)，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-)，男，博士，教授，主要從事車用電驅(qū)動控制技術(shù)方向的研究。

1671-4598(2017)10-0217-04

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

TP273

A