基于車載以太網的HIL 實時仿真測試平臺的研究及應用

任 勇，張文平，王 濤，李小燕

（1.福田戴姆勒汽車有限公司，北京 懷柔 101400；2.北京石墨烯研究院，北京 海淀 100094）

由于汽車智能化、網聯化的進一步發展，汽車車載網絡容量需求已極大超過了CAN或FlexFile等傳統汽車車載網絡的能力范圍，從而擁有更高傳輸速率的汽車以太網技術應運而生。汽車車載以太網是一種采用以太網連接車內電子單元的全新局域網技術，其標準[1-3]基于單對雙絞線以太網的Broad R-Reach或OABR技術，最高能夠完成1000 Mbit/s的傳輸速率，同時滿足汽車行業高可靠性、低電磁輻射、低功耗及同步實時性等性能要求。因此，汽車車載以太網在車輛動力、智能駕駛、娛樂等整車網絡領域的應用不斷增加。

HIL測試系統實時運行整車模型，并利用接口板卡鏈接被測控制器硬件接口，模擬被測控制器的輸入信息，收集控制器的輸出和必要的輸入信息，進行控制器對實時模型的閉環控制和HIL系統集成測試工作，完成對功能邏輯算法的驗證與測試。目前，基于CAN/CANFD通信的HIL實時仿真測試平臺，國內已有廣泛研究[4-7]，而利用MATLAB搭建支持車載以太網SOME/IP通信和CAN/CANFD通信的模型，同時支持DoIP通信的HIL實時仿真測試平臺研究尚未見報道。

本文基于Dspace實時仿真平臺，搭建同時支持車載以太網SOME/IP通信、CAN/CANFD通信和DoIP通信的HIL實時仿真測試平臺，該平臺成功應用于環網架構域控制器的HIL工作中。

1 車載以太網HIL實時仿真測試平臺

車載以太網HIL實時仿真測試平臺如圖1所示。該平臺主要由上位機電腦、HIL仿真臺架、交換機、診斷上位機和被測控制器等組成。

車載以太網HIL實時仿真測試平臺搭建過程大致如下：首先，按照圖1連接HIL仿真臺架、被測控制器、交換機和上位機電腦的物理接口；其次，解析車載以太網SOME/IP ARXML協議，根據服務接口搭建車載以太網通信模塊，仿真車載以太網服務（Method和Event類型）信號，而后通過配置CANMM仿真CAN/CANFD信號，建立車載以太網信號與CAN/CANFD信號的交互；然后，根據功能規范，搭建HIL仿真模型，并將自動化環境模型加載至HIL仿真平臺，并對HIL仿真平臺進行接口配置，配置車載以太網信號通道、CAN/CANFD信號通道及I/O通道，編譯仿真模型，生成SDF（System Description File，系統描述文件），上位機通過網線下載到下位機Real Time中運行；最后，配置車載以太網交換機，使車載以太網診斷上位機與被測控制器建立通信，形成具備測試車載以太網的HIL實時仿真平臺。

1）上位機電腦。HIL仿真平臺使用的工作站為上位機電腦，上位機電腦具有以下作用：①安裝MATLAB軟件，用于模型的開發及離線仿真；②安裝ConfigurationDesk軟件，將IO硬件配置與仿真模型搭建分開，用于硬件板卡與Simulink模型之間的關聯配置；③安裝ControlDesk軟件，用于對模型進行手動控制并顯示仿真的輸出數據；④安裝Wireshark軟件，用于采集和分析車載以太網報文。

2）HIL仿真臺架。HIL仿真臺架由下位機實時仿真系統和板卡箱組成。實時仿真系統為RTI實時機，能夠進行高可靠性強的實時檢測，響應時間≤100μs。在實時仿真系統運行仿真模型來模擬車輛的運行狀態，通過接收被測對象發送信號，并對被測對象接收信號進行仿真，仿真環境可與被測對象之間形成閉環，進而為HIL自動化測試提供必要的基礎。板卡箱包括DS6101板卡（電阻輸出信號通道、模擬輸入輸出通道、PWM輸入輸出通道、數字輸入輸出通道）、DS2671板卡（CAN/CANFD的通道）、DS6333板卡（車載以太網的通道）和負載板卡（用于配合DS6101板卡中的“數字輸入”通道使用）。

3）診斷上位機。車載以太網診斷上位機為基于Python語言開發的診斷上位機，該診斷上位機通過PCAN與被測控制器連接，實現CAN/CANFD診斷；診斷上位機同時也可通過交換機與被測控制器相連，支持車載以太網DoIP診斷。

4）交換機。交換機為Technica的EES車載以太網交換機，支持多端口100/1000BASE-T1轉換，報文延遲為＜2μs，報文可帶有時間戳40ns精度。上位機通過車載以太網交換機環境模型、車載以太網診斷上位機與控制器連接，可與各節點進行數據交互，并且可通過鏡像方式，抓取各節點之間的通信報文。

5）被測控制器。本系統的被測控制器為采用SOA架構的域控制器，支持千兆以太網傳輸速率，支持SOME/IP通信和CAN/CANFD通信，通過DoIP進行診斷，屬于HIL仿真測試對象。

2 HIL仿真模型

基于車載以太網HIL仿真包括：多功能通信模塊（支持車載以太網SOME/IP通信和CAN/CANFD通信）、電源控制模塊、動力學模型、手動控制模塊、輸入模塊、輸出模塊，見圖2。環境模型的主要功能是提供給被測控制器工作所需的各種輸入信號（I/O硬線信號、CAN/CANFD信號、車載以太網SOME/IP信號），并讀取被測控制器的輸出信號，進而驗證被測控制器的各個功能。該系統環境模型的每一個單獨輸出信號（I/O硬線信號、CAN/CANFD信號、車載以太網SOME/IP信號）都有兩種數據流方式，一是通過動力學模型進行仿真，二是通過手動設置。動力學仿真模式將被測控制器的輸出信號及駕駛員輸入信號傳到模型中進行處理，形成了信號的閉環；而手動設置模式則是直接對被測控制器的輸入進行設置，沒有形成信號閉環。通過仿真模型進行某一信號的改變，可以驗證該信號對于被測控制器相關聯功能以及車輛模型其他關聯參數的一系列影響，而通過手動設置模式向被測控制器輸入信號，能便捷直接地驗證被測控制器的直接關聯功能，便于測試人員驗證問題。

圖2 仿真模型模塊

2.1 電源控制模塊

電源控制模塊包括4個信號，分別是：①設備低壓程控電源開關控制信號，同時也是被測控制器低壓開關控制信號；②設備保護電流設置；③設備遠程操作允許設置，此設置允許在上位機對設備進行操作；④設備低壓電源電壓值設置。

2.2 動力學模型

動力學模型包括駕駛員模型、車輛動力學模型、OUTPORT模塊及Plantmodeloutport等4個模塊。分別為：①駕駛員模型的功能是模擬駕駛員對車輛的一些可操作設備的操作及外界環境對車輛的影響因素，作為動力學仿真模型必要的輸入；②車輛動力學模型主要由電池模塊、電機模塊、變速器模塊、車輛模塊、DCDC模塊、真空泵模塊、能耗計算模塊等子仿真模塊構成；③OUTPORT模塊作用主要是將駕駛員模型中的輸入信號，分解或轉化成相關控制器I/O通道的開關信號或模擬信號；④Plantmodeloutport，該模塊的功能是為之前動力學模型沒有進行仿真的信號賦值，保證模型能夠產生被測控制器需要的所有外部信號。

2.3 手動控制模塊

手動控制模塊的功能是提供人為設置Dspace任一輸出信號的接口，包括I/O信號、CAN信號和車載以太網SOME/IP信號。

1）I/O信號手動控制模塊：該模塊的功能是提供Dspace設備向控制器輸出的所有I/O信號的手動設置接口。與輸入模塊相同，每一個信號通道可以單獨控制是否啟用。對于每一個信號，其名稱代表了控制器的管腳號。

2）總線信號手動控制模塊：信號設置模塊包括整車網絡節點的所有總線信號（CAN信號和SOME/IP信號），每一個信號都有Value和Switch兩個信號，一個用來對該總線信號進行數值設置，Switch信號用來進行手動設置值與模型仿真值的切換。信號觸發模塊的功能為向多功能通信模塊提供觸發信號，使Dspace設備按總線協議的要求發送相應的總線信號。

2.4 輸入模塊

本模塊主要包括了被測控制器的輸出信號與HIL設備的接口模塊，功能是HIL設備接收被測控制器的輸出信號，并轉化成易讀格式。

2.5 輸出模塊

本模塊是HIL設備的輸出信號與被測控制器的接口，功能是將被測控制器工作需要的輸入信號通過HIL設備相應的硬件接口發送給被測控制器。

2.6 多功能通信模塊

多功能通信模塊包含車載以太網通信模塊和CAN/CANFD通信模塊，功能是發送與接收車載以太網SOME/IP信號和CAN/CANFD信號。其中，車載以太網通信模塊具有以下技術指標：①該通信模塊支持車載以太網協議中的UDP和TCP兩種傳輸方式，支持TCP握手，Socket建立；②該通信模塊支持發送車載以太網SOME/IP和SOME/IP SD報文，并可仿真事件通告、遠程過程調用的使用場景，同時可仿真SOME/IP SD報文訂閱過程；③該通信模塊支持車載以太網E2E校驗及故障注入，同時支持單播、多播和廣播的網絡通信方式。

3 車載以太網HIL實時仿真測試

基于車載以太網HIL實時仿真測試平臺能夠實現模擬駕駛測試、車載以太網服務訂閱、SOME/IP通信測試、車載以太網DoIP診斷測試和故障注入測試。

3.1 模擬駕駛測試

HIL仿真系統通過模擬實車運行環境，可在實車測試前進行基本功能的駕駛測試仿真測試，同時可以覆蓋實車上無法驗證的測試場景（如極限工況測試等），為被測控制器軟件功能性測試提供了極大便利。測試者可通過駕駛員仿真界面為HIL仿真系統輸入ON電指令、油門開度、制動、換擋位置等信號。駕駛員仿真信號經過硬件在環仿真模擬器的處理后，將傳感器I/O信號、CAN總線信號、車載以太網信號等傳輸到整車控制器，整車控制器底層接收處理后傳輸至整車控制器應用層，整車控制器應用層軟件運算處理后發出執行器控制信號。圖3為模擬駕駛測試界面。

圖3 模擬駕駛測試界面

如圖3所示，整車狀態為12，行車模式，READY燈點亮，擋位為D擋。同時該界面也可仿真快慢充插槍使被測控制器進入快慢充模式，亦可仿真T-BOX邏輯使被測控制器進入遠程模式。

3.2 車載以太網服務訂閱及SOME/IP通信測試

采用基于SOME/IP協議通信的SOA架構的控制器根據各節點的功能需求的不同，可分為Client端（客戶端）和Server端（服務端）。Server端為服務的提供者，可通過SOME/IP的服務接口向Clien端提供服務；Clien端為服務的消費者，可通過服務接口向Server端請求服務。SOME/IP通信主要功能可以劃分為服務訂閱和遠程服務調用。

本文以被測控制器上ON電功能為例，仿真節點ECU1為服務端，被測控制器ECU2為客戶端。具體上ON電流程如圖4所示，當被測控制器收到制動踏板踩下信號后，就會識別鑰匙位置是否在車內，若鑰匙有效信號為有效，則被測控制器控制IG繼電器吸合，成功上ON電。下文將依據該實例進行服務訂閱和遠程服務調用過程說明。

圖4 上ON電流程

3.2.1 服務訂閱

車載以太網的服務發現和訂閱是通過SOME/IP SD協議來實現的，固定端口號為30490，其報文使用UDP傳輸方式傳送。Client端可通過SOME/IP SD的Find Service報文發現服務實例，使用Subscribe報文訂閱報文或調用的服務實例；同時Server端通過SOME/IP SD的Offer報文告知其它網絡節點可提供的服務，通過SubscribeACK/SubscribeNACK告知客戶端服務的可用性（比如服務出現錯誤時，則該服務不可用），見圖5。

圖5 服務訂閱過程

SOME/IP SD 主要有以下優勢：①車輛啟動時，車內各ECU初始化時間各不相同，ECU 通過SOME/IP SD 就可以靈活發布其Service 的使用狀態；②車輛變型時，可以更好適應功能/配置的變化，同時減少前期的配置工作；③Client端的Service出現問題時，SOME/IP SD可快速識別Service的不可用狀態，Server端就可以迅速做出響應；④降低總線負載率，功能場景需要的時候才會提供/訂閱服務，可降低總線負載率，減少能量消耗。

被測控制器ECU2服務訂閱過程如下文描述。HIL系統啟動后，給ECU2供電。ECU2訂閱ECU1鑰匙有效服務，實現服務的注冊，其服務發現和訂閱過程如圖6所示。

圖6 鑰匙有效服務訂閱過程

1）Client端以廣播形式發出發現服務（Type=0x00，FindService）報文給各節點，鑰匙有效服務Service ID為47105（源IP地址為192.168.61.7，目的IP地址為239.0.0.255）。

2）Server端收到該FindService報文后，通過單播發出提供服務（Type=0x01，OfferService）報文給Client端（源IP地址為192.168.61.4，目的IP地址為192.168.61.7）。

3）Client端收到該OfferService報文后，通過單播發出訂閱服務（Type=0x06，SubscribeEventgroup）報文給Server端（源IP地址為192.168.61.7，目的IP地址為192.168.61.4）。

4）Server端收到該SubscribeEventgroup報文后，通過單播發出服務確認（Type=0x07，SubscribeEventgroupACK）報文給Client端（源IP地址為192.168.61.4，目的IP地址為192.168.61.7），此時服務訂閱成功。

3.2.2 遠程服務調用

車載以太網遠程服務調用報文類型可分為Method類型和Event類型，如圖7所示。Method類型又分為Request/Response（RR）和Fire&Forget（FF）兩種通信方式。其中RR通信主要用于實現Clien端發送請求消息，Server端收到請求，處理后進行響應；FF是一種不需要Client端響應報文的請求通信。Event類型的通信主要用于實現Client端向Server 端訂閱需要的事件組/事件，當事件被觸發時，Server端需要向Client端發送更新的內容。

圖7 Request/Response服務和Event服務

Event類型報文發送方式可分為Cycle、On change和事件值變化超過預定范圍。圖8為鑰匙有效服務為On change觸發，上文中該服務已被客戶端訂閱。當仿真節點服務端檢測到制動踏板信號值變化時，就會觸發仿真節點發出鑰匙位置有效報文（Service ID=47105，Method ID=32769），同時被測控制器ECU2檢測到仿真環境發送的制動踏板信號后，ECU2就會檢測鑰匙有效信號，當ECU2接收到鑰匙位置有效信號為有效時，IG繼電器吸合，ECU2上ON電。圖8所示整車狀態為12，整車模式為行車模式。

圖8 成功上ON電界面和鑰匙有效信號

3.3 車載以太網DoIP診斷測試

DoIP的主要作用是實現外部診斷儀與車載網絡節點之間的診斷連接，其通信采用TCP傳輸方式。本文利用自主開發的DoIP診斷儀用于被測控制器ECU2的下線電檢測試。

3.3.1 連接過程

診斷儀與被測控制器ECU2建立網絡連接過程如下文所述。首先，進行診斷儀與被測控制器的物理連接；其次，診斷儀請求被測控制器ECU2 打開 TCP_ DATA Socket，使診斷儀與被測控制器ECU2建立Socket（TCP 3次握手）；隨后，診斷儀向被測控制器ECU2發送路由激活請求，被測控制器收到路由激活指令后則進行路由激活處理，建立Socket，并對診斷儀的激活請求進行響應，從而完成路由激活連接，此時成功完成DoIP的連接。當結束診斷交互后，診斷儀主動請求關閉Socket（TCP 4次揮手），從而使診斷儀與被測控制器斷開連接。DoIP連接和斷開流程如圖9所示。

圖9 DoIP連接和斷開流程

3.3.2 下線電檢診斷

1）首先，診斷儀與被測控制器ECU2進行Socket連接和路由激活（診斷儀Source Address 為0x0E80，IP 為192.168.61.71；被測控制器ECU2 Target Address=0x0100，IP為192.168.61.36），如圖10所示。

圖10 DoIP連接示意圖

2）診斷儀發送診斷報文到被測控制器ECU2，DoIP實體經過通用DoIP首部處理及DoIP診斷處理后，向診斷儀發送確認接收的診斷響應。如圖11所示，診斷儀發送0x10 03，DoIP實體回復0x50 03 00 32 00 c8，則被測控制器ECU2進入擴展模式。

圖11 DoIP診斷示意圖

3）當DoIP斷開連接時，首先進行TCP 4次揮手過程，而后關閉Socket接口，如圖12所示。

圖12 DoIP斷開示意圖

3.4 車載以太網E2E校驗

車載以太網E2E為端到端保護機制的簡稱，在整車通信系統中通過特定監測機制來保證信息在節點之間傳輸過程中的數據及時性、正確性和完整性。從功能安全的角度看，如果E2E接收方必須依賴于所接收信號的及時性、正確性和完整性，那么E2E發送端和接收端之間的通信即為安全相關的。本文定義以太總線網絡使用Profile 4算法[5-7]。如圖13所示，E2E Profile 4算法元素包括：Length、Counter、Data ID、CRC Checksum。

圖13 E2E Header示意圖

Counter，其初始化、累加、重置以及校驗都由E2E Profile完成。對于發送端，初始化完成以后，第1次傳輸時，Counter值應該被初始化為0x0；每次發送后，Counter值遞增0x1；當Counter值達到最大值0xFFFF后，下一次發送時，Counter值從0x0重新開始循環。Data ID，每一個被E2E保護的信號組都擁有一個特定的ID，長度為32bits。Data ID 配置為SOME/IP 的Message ID（ServiceID/MethodID）。Length用來指示車載以太網中報文數據的長度，長度為32bits。

CRC Checksum為循環冗余校驗。被測控制器ECU2的CRC采用32-bit 0x1F4ACFB13多項式算法，具體參數設置見表1。

表1 32-bit 0xF4ACFB13算法元素值

車載以太網E2E校驗測試前，需要把E2E Header的Length、Counter、Data ID和CRC Checksum算法導入HIL測試系統中。如需驗證E2E校驗的故障注入，可通過修改算法，使Length、Counter、Data ID和CRC Checksum其中之一錯誤即可。圖14為加載E2E Profile 4算法仿真擋位信號（Service ID=14，Method ID=32769）的以太網E2E校驗值，其中Length=0x00 1D，Counter=0x3B B3，Data ID=0x00 0E 80 01，CRC=0x4B E4 5E A6。

圖14 E2E校驗案例

4 結論

本文基于Dspace實時仿真平臺搭建具備測試車載以太網的HIL實時仿真測試平臺及仿真測試。結果表明：該平臺可以滿足基本功能的駕駛仿真測試，同時支持CAN/CANFD通信和SOME/IP通信測試，并可以對車載以太網報文進行E2E校驗；利用診斷上位機可以進行CAN/CANFD通信和DoIP通信的UDS診斷操作。綜上所述，車載以太網的HIL實時仿真測試平臺能夠幫助提高基于車載以太網通信的域控制器應用軟件測試效率，提升軟件品質，節省開發成本，可以滿足當前對于域控制器應用層軟件快速開發、驗證、測試的需求。