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

， ，

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

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

鐘再敏，黃熙，章鴻濱

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

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

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

0 引言

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

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

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

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

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

2 E2E安全通信保護(hù)機(jī)制

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

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

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

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

圖3 CRC校驗(yàn)和的計(jì)算方式

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

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

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

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

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

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

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

1)Interface定義

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

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

2)SWC的定義

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

表1 Interface定義

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

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

表2 SWC的定義

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

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

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

3.3 芯片驅(qū)動(dòng)設(shè)計(jì)

芯片驅(qū)動(dòng)設(shè)計(jì)目的是使上層軟件與微處理器型號(hào)無(wú)關(guān)，包含MCU中內(nèi)部外設(shè)的驅(qū)動(dòng)和使用MCU內(nèi)存映射的外部設(shè)備的驅(qū)動(dòng)。本部分開(kāi)發(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通信保護(hù)的代碼實(shí)現(xiàn)

發(fā)送端的軟件組件E2E_InterSWC_1內(nèi)部的可運(yùn)行實(shí)體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ù)是一個(gè)結(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ù)，進(jìn)行發(fā)送端E2E控制數(shù)據(jù)(CRC,Counter)的計(jì)算，之后通過(guò)RTE提供的API函數(shù)，將控制數(shù)據(jù)和需要保護(hù)的數(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ā)送端類似，可運(yùn)行實(shí)體E2E_InterSWC_2_REProc的內(nèi)部通過(guò)函數(shù)E2EPW_Write_E2E_InterSWC_2調(diào)用RTE提供的API函數(shù)來(lái)讀取控制數(shù)據(jù)和E2E保護(hù)的數(shù)據(jù)，再調(diào)用E2E_P02Check函數(shù)來(lái)校驗(yàn)接收的數(shù)據(jù)(CRC,Counter)，最后將校驗(yàn)結(jié)果返回。此外，在ECU的啟動(dòng)時(shí)，需要在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通信保護(hù)的代碼實(shí)現(xiàn)

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

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

下面介紹COM端的代碼實(shí)現(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 測(cè)試及驗(yàn)證

4.1 基于E2EPW實(shí)現(xiàn)ECU內(nèi)部通信測(cè)試

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

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

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

圖12 基于E2EPW的E2E通信的測(cè)試流程圖

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

由于條件限制，本文通過(guò)開(kāi)發(fā)工具模擬一個(gè)節(jié)點(diǎn)，捕捉開(kāi)發(fā)板發(fā)送出來(lái)的CAN報(bào)文，修改CAN報(bào)文的ID，然后重新發(fā)給開(kāi)發(fā)板。通過(guò)這樣的方式，模擬跨ECU之間的通信。

4.2.1 E2E跨ECU通信測(cè)試

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

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

5 結(jié)論

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

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

[2]高煥吉． 基于AUTOSAR的汽車電子控制系統(tǒng)嵌入式軟件開(kāi)發(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)件運(yùn)行實(shí)體映射模型的研究與設(shè)計(jì)[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。

國(guó)家科技支撐計(jì)劃(2015BAG17B00)；國(guó)家科技支撐計(jì)劃(2015BAG03B00)。

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

1671-4598(2017)10-0217-04

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

TP273

A