摘要

未來，車輛制造商希望在網絡通信領域提供更高的靈活性，例如在開發(fā)過程中以及生產后提供簡化的更新和升級功能。為實現(xiàn)這一目標，當前車輛內部架構領域正經歷一場范式轉變 —— 多年來，車輛內部架構一直基于面向信號的通信設計。面向服務通信的引入解除了集成電子控制單元（ECU）之間的靜態(tài)分配關系。然而，在這些面向服務網絡的開發(fā)過程中，新的挑戰(zhàn)已然出現(xiàn)。本文提出了一種搭建此類網絡仿真與測試平臺的方法，并闡述了相關挑戰(zhàn)，同時探討了該平臺可支持的潛在用例。其中，信息安全是一個關鍵方面，在開發(fā)這些架構之初就必須予以考慮。在未來的工作中，我們計劃通過集成新的安全措施等方式為網絡增加更多服務，以便在仿真環(huán)境中對其進行測試。

一、引言

受電氣化、自動駕駛和車聯(lián)網等趨勢的影響，汽車行業(yè)目前正經歷一場變革。此外，未來還應提升在用車的更新和升級能力，并簡化開發(fā)過程中的功能適配。在以往的車輛中，僅采用面向信號的網絡技術（例如控制器局域網（CAN）協(xié)議）。因此，發(fā)送方和接收方之間的網絡消息靜態(tài)分配在開發(fā)階段就已確定。待傳輸?shù)男盘栃畔ⅲㄈ畿囁伲┍混o態(tài)分配到有效載荷內的消息中。例如，若要在實際應用中添加一項需要或提供特定信號的新功能，就必須對網絡配置進行全面修改。為應對這些挑戰(zhàn)，面向服務架構（SOA）范式正被引入當前的車輛中。這使得基于動態(tài)通信模式的面向服務通信成為可能。因此，服務提供者可以為消費者提供特定服務，且服務在運行時可隨時調用。SOA 范式應用于汽車以太網技術，與 CAN 標準相比，該技術除了支持高速傳輸速率外，還能實現(xiàn)點對點連接。然而，這種變革也對現(xiàn)有的開發(fā)流程及所使用的工具產生了影響。CANoe是汽車制造商和供應商廣泛使用的一款成熟工具，適用于仿真、測量和軟件測試。基于 CAN 協(xié)議創(chuàng)建網絡仿真時，可構建一個包含所有消息、信號及相關屬性（如周期時間）的整體數(shù)據(jù)庫。但基于汽車以太網構建 SOA 仿真則需要新的流程。

SOA 等新型通信范式要求在以太網網絡的開發(fā)和測試中采用新方法。通過使用 CANoe 等仿真工具，可在網絡或服務部署到實際硬件之前對其進行開發(fā)和測試。本文提出了一種汽車 SOA 仿真方法，并介紹了應用場景。

二、背景

（一）汽車以太網

2015 年，IEEE 802.3bw 標準對汽車以太網技術進行了規(guī)范。該標準（也稱為 100Base-T1）基于 ISO/OSI 第一層，通過非屏蔽雙絞線電纜提供 100 兆比特 / 秒的數(shù)據(jù)傳輸速率。對于帶寬需求較低且需低成本實現(xiàn)的應用，10Base-T1 標準定義了 10 兆比特 / 秒的數(shù)據(jù)傳輸速率。在 OSI 較高層級（2、3、4 層），汽車以太網融合了傳統(tǒng)信息技術（IT）中的多種不同協(xié)議。對于 SOA，以太網與傳輸控制協(xié)議（TCP）/ 互聯(lián)網協(xié)議（IP）或用戶數(shù)據(jù)報協(xié)議（UDP）/IP 結合使用。與采用載波監(jiān)聽多路訪問 / 沖突避免（CSMA/CA）訪問方法的 CAN 協(xié)議不同，汽車以太網無需此類方法，因為其通信被指定為全雙工傳輸。這使得兩個網絡節(jié)點能夠同時發(fā)送和接收消息，從而避免沖突。由于其物理結構為星形拓撲，每條線路僅連接兩個網絡參與者，因此不會發(fā)生沖突。

（二）面向服務架構

在車輛架構中集成 SOA 范式旨在為原始設備制造商（OEM）和第三方供應商提供更高的靈活性，使其能夠在開發(fā)過程中或實際運行時更便捷地進行更改。為此，功能被劃分為盡可能小的服務，這些服務可通過編排來執(zhí)行更復雜的任務。此外，硬件和軟件之間的解耦程度進一步提高，使得功能設計與底層架構不存在靜態(tài)依賴關系。例如，功能開發(fā)人員無需知道某個傳感器信號在哪個消息中傳輸，或所需功能集成在哪個 ECU 上，而只需了解車輛中可用的服務概況。在汽車領域，目前用于車載 SOA 通信的協(xié)議包括基于 IP 的可擴展面向服務中間件（SOME/IP）和數(shù)據(jù)分發(fā)服務（DDS）。中間件充當服務提供者和消費者之間的協(xié)調者，并基于 SOME/IP 支持以下功能：

· 序列化：實現(xiàn)數(shù)據(jù)在 OSI 低層與高層之間的相互轉換。

· 遠程過程調用（RPC）：包括簡單的 “即發(fā)即棄”（Fire&Forget）模式（客戶端調用服務提供者提供的方法且無需返回值）和 “請求 / 響應”（Request/Response）模式（帶有返回值的方法調用，返回值通過額外消息傳輸）。

· 服務發(fā)現(xiàn)（SD）：涵蓋三個核心方面：一是傳輸現(xiàn)有服務的狀態(tài)信息（是否可用）；二是支持消費者定位所需服務；三是通過 SD 實現(xiàn)發(fā)布 / 訂閱機制。

· 發(fā)布 / 訂閱：服務提供者可提供事件通知（Event Notification）或字段通知（Field Notification），消費者可進行訂閱。一旦事件或字段中的信號發(fā)生變化（如座椅占用狀態(tài)），相關信息將通過事件幀發(fā)送給所有訂閱者。這使得僅在發(fā)生變化時才傳輸幀，從而最大限度地減少網絡負載。與事件不同，字段包含歷史參考（先前的值）。

· UDP 消息分段：該功能允許通過 UDP 幀傳輸大型 SOME/IP 數(shù)據(jù)，且無需分片。

此外，由于電氣和電子架構（E/E 架構）中未采用信號到消息的靜態(tài)映射，該概念允許在開發(fā)完成后仍能添加新功能。新功能可作為升級項添加，且所需服務可輕松訂閱。

（三）AUTOSAR

汽車開放系統(tǒng)架構（AUTOSAR）標準的核心目標是將軟件功能與所用硬件解耦，以簡化汽車軟件的可復用性。這意味著 AUTOSAR 不僅包括操作系統(tǒng)本身，還包含分層軟件架構，即基礎軟件層（BSW）、運行時環(huán)境層（RTE）和應用層。基礎軟件層（也稱為 AUTOSAR 協(xié)議棧）包含多個模塊和子模塊，負責處理通信、診斷或安全等特定任務。實際應用程序下方所需的模塊（如用于建立車輛通信的模塊）被稱為 AUTOSAR 通信棧。

目前，AUTOSAR 有兩種不同的平臺變體（經典 AUTOSAR 和自適應 AUTOSAR），未來車輛將以混合方式集成這兩種變體。經典變體主要針對傳統(tǒng) ECU 的面向信號通信概念。較新的自適應變體于 2017 年首次發(fā)布，旨在支持基于可移植操作系統(tǒng)接口（POSIX）操作系統(tǒng)和面向對象編程的 SOA 范式。為確保兩個平臺的兼容性，經典變體提供有限的面向服務通信能力。

開發(fā)新車輛時，OEM 將所有所需功能定義為軟件組件（SWC），并以可擴展標記語言（XML）文件的形式提供相關接口描述。然后，將軟件組件分配給規(guī)劃中的控制單元，這些控制單元通過網絡技術（如 CAN 或以太網）連接。相關信息以系統(tǒng)描述的形式存儲在 AUTOSAR XML（ARXML）文件中。為便于交換這些描述，會生成系統(tǒng)描述摘要，供相關供應商在開發(fā)過程中導入使用。

圖1、SOA原則由服務代理、消費者和提供者組成

（四）CANoe

CANoe 軟件在開發(fā)早期階段及后續(xù)測試活動中就支持車輛網絡及相關 ECU 的開發(fā)。除了對所有組件進行完整仿真外，還可僅仿真網絡的一部分，并將實際 ECU 集成到仿真中。仿真 ECU 上的功能實現(xiàn)可通過 Vector 專用編程語言通信訪問編程語言（CAPL）或微軟.NET 框架完成。為仿真 SOA，可導入不同的描述格式（如.ARXML），這些格式包含已定義的 ECU、服務和接口的相關信息。

三、搭建原型網絡

本節(jié)的目標是搭建一個支持與實際節(jié)點通信的示例網絡，以闡釋 SOA 原理并提供開發(fā)和測試平臺。為此，我們對不同的搭建方案進行了可行性評估（見表 1），具體如下所述。

表 1、SOA 網絡三種不同搭建方案的評估

（一）原型實現(xiàn)方案

1. 方案 1：第一種方案是建模三個節(jié)點，分別代表媒體播放器、導航系統(tǒng)和顯示器。此外，開發(fā)一個可連接到 CANoe 仿真并輸出相應數(shù)據(jù)的實際節(jié)點，通過以太網硬件接口實現(xiàn)與 CANoe 的連接。但該方案存在一些挑戰(zhàn)：首先，新創(chuàng)建的 CANoe 示例尚未包含 SOME/IP 實現(xiàn)；其次，媒體文件采用 Windows 標準格式，數(shù)據(jù)通過 Windows 標準工具顯示；此外，實例化實際 SOME/IP 節(jié)點需要完整的自適應 AUTOSAR 協(xié)議棧實現(xiàn)。

2. 方案 2：Vector 已開發(fā)一款計算器示例，該示例已應用于多個 CANoe 軟件版本，且包含 SOA 實現(xiàn)。服務提供者將各種基本算術運算作為服務提供，消費者可通過 RPC 訪問這些服務。該實現(xiàn)已提供 SOME/IP 描述，支持將仿真（服務提供者）與實際網絡節(jié)點（消費者）耦合。但挑戰(zhàn)在于，為使用 SOME/IP 功能，需在實際節(jié)點上實現(xiàn) AUTOSAR 協(xié)議棧，這需要扎實的 AUTOSAR 知識和工具支持。相比之下，可通過實際汽車以太網連接進行數(shù)據(jù)傳輸，以便進一步分析。

3. 方案 3：另一種方案是使用另一臺運行 CANoe 的電腦替代實際節(jié)點。這將簡化實現(xiàn)過程，因為無需進行 AUTOSAR 協(xié)議棧實現(xiàn)，但需要額外支付 CANoe 許可費用。

為確定最合適的方案，我們進行了效用值分析（見表 1）?；谠摲治觯桨?3 最為合適，因為其已具備 SOME/IP 實現(xiàn)和數(shù)據(jù)序列化功能，且可將配置數(shù)據(jù)存儲在以太網硬件接口上，從而簡化了可重復性。盡管購買多個硬件接口及由此產生的成本帶來了負面影響，但方案 3 在時間投入方面具有優(yōu)勢，其加權總評分為 83%。

（二）實現(xiàn)過程

該實現(xiàn)基于圖 2 所示的結構，包含兩個 CANoe（12 版本）實例和兩個 USB - 以太網硬件接口。CANoe 中已有的計算器功能用作 SOME/IP RPC，同時實現(xiàn)了兩個 SOME/IP 事件服務（回聲（Echo）、三角波（Triangle））。此外，通過現(xiàn)有的 ARXML 文件將服務描述導入 CANoe。

圖2、原型汽車以太網的結構

所實現(xiàn)服務的 SOME/IP SD 通信原理如圖 3 所示。SOME/IP 節(jié)點 2 提供服務接口（SIF）為 11 的三角波（Triangle）服務，該服務代表由該節(jié)點生成的三角波信號。節(jié)點 1 通過訂閱事件組（SIF 11）消息訂閱該服務，服務提供者則通過確認消息響應。一旦信號值發(fā)生變化，消費者（節(jié)點 1）將收到新的 SOME/IP 消息。

此外，節(jié)點 1 提供回聲（Echo）服務，該服務對所訂閱的三角波服務進行反轉處理。在這種情況下，節(jié)點 2 作為消費者，訂閱服務接口（SIF）為 10 的回聲服務。由于三角波服務的值定期變化，回聲服務也將以相同的周期時間發(fā)送。

第二種服務類型為 RPC，支持四種不同的方法（加、減、乘、除）?？赏ㄟ^圖形界面在仿真中修改方法參數(shù)，同時也可在圖形面板中可視化服務提供者的返回值。這些服務通過 CAPL 實現(xiàn)，并存儲在仿真節(jié)點上。面板的圖形元素允許與 CAPL 實現(xiàn)建立鏈接，例如讀取或修改變量。

除 SOME/IP 配置外，還需為每個節(jié)點分配相應的 IP 地址、媒體訪問控制（MAC）地址以及交互層（IL）。交互層負責將仿真 SOME/IP 節(jié)點與實際網絡硬件連接起來。

圖 3、兩種不同服務類型（RPC、事件）的通信原理

四、SOME/IP的安全性

由于 SOA 服務分布在不同的實例上，且需通過上述機制（如發(fā)布 / 訂閱）進行請求，因此 SOME/IP 協(xié)議的安全性問題應運而生。特別是通信參與者的真實性至關重要，因為攻擊者可能偽裝成服務提供者，提供被篡改或惡意的服務。此外，近年來發(fā)生的車輛攻擊事件往往導致車輛內部通信的真實性遭到破壞。近年來，車輛安全受到了媒體、車輛制造商、供應商及研究界的廣泛關注。因此，相關標準（如 ISO 21434標準和聯(lián)合國歐洲經濟委員會（UNECE）WP.29法規(guī)）正在制定中，這些標準和法規(guī)明確了車輛生命周期內安全保障所需滿足的要求。對于面向服務架構而言，這意味著所使用的協(xié)議必須具備抗攻擊能力。為此，本節(jié)將探討 SOME/IP 協(xié)議的安全性相關方面。我們參考了文獻，該文獻基于 “通過修復漏洞增強軟件安全性和安全性（HEAVENS）”方法對 SOME/IP 協(xié)議進行了威脅和風險分析，研究了服務發(fā)現(xiàn)、遠程過程調用和發(fā)布 / 訂閱等通信機制。威脅分析識別出了數(shù)據(jù)修改、讀取、刪除或服務操縱等威脅。在后續(xù)的風險評估中，這些威脅被評為中高風險，因為 SOME/IP 協(xié)議幾乎未提供任何防范攻擊的安全機制。因此，應通過測試驗證已發(fā)現(xiàn)威脅的實際可行性，而安全機制的集成可作為進一步的研究方向。下一節(jié)將介紹本文提出的方法可支持的用例。

五、用例

所搭建的網絡可用于多種用例。一方面，它適用于實驗室課程，為學生提供面向應用的環(huán)境；另一方面，可用于研究并擴展，以探索汽車功能的新方法。此外，可通過網關與面向信號的網絡技術（如 CAN 總線）耦合，構建混合 E/E 架構，進而用于研究傳輸延遲。特別是服務與面向信號消息之間的相互適配（或反之）帶來了新的挑戰(zhàn)。

另一個新興的研究領域是 SOA 網絡的信息安全?；谕{和風險分析，可推導安全機制并將其集成到 SOA 仿真中。前文所述的研究已提出了部分可能的安全機制，例如可在 CANoe 仿真中部分實現(xiàn)這些機制以測試其有效性。因此，CANoe 可用于搭建測試平臺，支持基于上述 SOA 架構的安全測試。這使得驗證已識別威脅的可行性成為可能，此外，還可通過在集成安全機制前后對架構進行攻擊測試，來驗證安全機制的有效性。

六、結論

SOA 范式正被引入當前的車輛架構中。與傳統(tǒng)的面向信號通信相比，這種通信方式和網絡開發(fā)發(fā)生了根本性變化，為功能的更新和升級提供了更高的靈活性。然而，搭建這些網絡也面臨新的挑戰(zhàn)。本文闡述了如何實現(xiàn)基于 SOME/IP 的原型通信，該通信包含仿真（CANoe）和用于傳輸汽車以太網數(shù)據(jù)包的實際硬件。但其中一個挑戰(zhàn)是 SOA 通信的描述 —— 需通過網絡描述文件定義，這需要額外的工具支持和扎實的 AUTOSAR 知識。此外，由于 SOME/IP 協(xié)議缺乏安全功能，本文還強調了安全在 SOA 中的重要性，未來應改進這一問題。可利用 CANoe 等工具搭建測試環(huán)境，開展 SOA 安全措施研究，以支持安全測試的執(zhí)行。

七、未來工作

在未來的工作中，我們將通過添加更多網絡節(jié)點和服務來擴展 SOME/IP 結構，但需要創(chuàng)建新的 AUTOSAR 網絡描述文件并將其集成到仿真中。此外，將開發(fā)和實現(xiàn)處理環(huán)境信息（如攝像頭和雷達數(shù)據(jù)）的自動駕駛功能，并測試模擬服務提供者故障的場景。受影響的客戶端應能夠在運行時訂閱其他可用的服務提供者。此外，可通過集成安全測試來擴展仿真，構建測試框架。通過這種方式，可通過模擬對系統(tǒng)的攻擊來驗證安全措施，從而助力構建 SOA 中的安全通信場景。

（添加微信號NewCarRen咨詢）