汽車行業的消費者需求推動了復雜的車載信息娛樂系統（IVI）的發展，這些系統需要完全了解整個車輛及其周圍環境。實施這樣的高級方案需要在不同的主機環境中實現數據交換，例如高級駕駛輔助系統（ADAS）和IVI。本文分析了在汽車軟件開發中使用的面向服務的架構中的不同通信機制，包括域內和跨域的通信。介紹了連接ADAS和IVI主機的可能方法，并從性能和它們支持的用例方面進行了分析。

I.簡介

目前，汽車是世界上增長最快的行業之一。隨著汽車所提供的功能的發展，電子控制單元（ECU）的數量也在增加，這導致了對更有效和更強大的數據交換機制的需求。此外，隨著消費行業需求的不斷增長，需要加強車載信息娛樂(IVI)系統，并構建信息娛樂應用程序，以感知更多關于車輛本身的信息。只有通過實現IVI系統與負責收集車輛及其周圍信息的ECU之間的通信，才能實現這一目標。

在一般情況下，車輛由許多ECU組成，它們具有不同的架構，運行不同的操作系統（OS），并相應地支持不同的使用情況。這些ECU根據其執行的任務，在語義上被連接到幾個領域。車載軟件方面的兩個主要領域是高級駕駛輔助系統（ADAS）和前面提到的IVI。如前所述，為了建立一個支持高級功能的車輛系統，ECU必須能夠交換信息，無論它們是屬于同一領域還是不同領域。

本文將對汽車行業中使用的通信通機制進行全面研究。第1、2、3節通過收集和提供汽車以及其他領域各分支的已知事實來處理定性的研究方法。在第4節中，由于缺乏對所調查的例子進行比較的資料，有必要采用定量方法，進行更多的衡量。重點是面向服務的架構（SOA）方法，它與其他機制的比較，以及它在不同使用情況下的采用。在這個分析中，不僅要研究領域內和領域間的通信，而且還要考慮數據背景。

II.汽車行業的SOA原則

汽車中以太網利用率的提高，使得面向服務的架構范式被汽車行業所接受。也就是說，采用面向服務的架構的一個必要條件是設備上存在一個網絡堆棧。由于車輛中的大部分組件已經使用以太網進行通信，所以通用網絡堆棧已經存在。SOA的優勢在于它允許建立可擴展和模塊化的應用程序，使用ECU內部和ECU之間的通信機制，以及跨域的信息交換。SOA范式不依賴于操作系統本身，這意味著每個ECU可以有不同的操作系統（如Linux、Android、QNX）。 SOA方法在消費者領域已經很成熟，例如在網絡和云服務中，基于超文本傳輸協議（HTTP）的API通常被用來在系統組件之間交換信息。然而，由于云和汽車應用的性質不同，HTTP不能用于汽車行業，必須創建一個新的協議。可擴展的面向服務的IP中間件（SOME / IP）是一個標準化的汽車解決方案，由兩個主要的聯盟支持：汽車開放系統架構（AUTOSAR）和互聯汽車系統聯盟（COVESA），前身是GENIVI。SOME/IP針對汽車領域進行了調整，在數據序列化和流量傳輸方面提供標準化。COVESA制作了一個通用API棧，將FRANCA框架應用于Linux和安卓平臺，這使得它適用于IVI系統。 另一方面，Adaptive AUTOSAR的ara::com適用于具有ADAS平臺的性能主機。這兩個堆棧都支持SOME/IP標準，為其互操作性提供了可能。然而，目前還沒有標準化的解決方案，支持在這兩個堆棧之間進行信息交換。 在SOA架構中，多個客戶端可以聯系服務器模塊，服務器模塊以服務的形式向他們提供其功能，如圖1所示。

圖1 面向服務的中間件架構

III.可能的通信機制

在本節中，我們將分析汽車SOA中常用的通信機制，特別是在數據背景和數據交換的目的方面。根據需要傳輸的數據類型或其目的，可以使用不同的方法，如圖2和表1所描述的。詳細情況將在下文中討論。

A. 共享內存

在兩個域之間進行通信的情況下，使用共享內存很少適用。對于域間數據交換，這種方法只適用于兩個域都位于一個多核ECU內的情況。由于具有不同安全完整性級別的域可以訪問相同的內存空間，因此這種情況會遇到安全問題。有一種假設是，它可以通過使用管理程序來處理，但目前沒有考慮。

對于域內通信，共享內存可用于交換常規數據，它不適用于從傳感器收集數值并向執行器發送命令的情況。

圖2 汽車領域的通信方式

表I 通信方式的比較

B. SSOME/IP和以太網

如前所述，SOME/IP依賴于TCP和UDP協議。它主要負責基于SOA的通信的序列化和反序列化。基于UDP的通信被推薦用于較小的數據量，而TCP更適合較大的數據量。SOME/IP是通信機制的代表，它易于擴展，因此最適合在汽車中建立SOA應用，它適用于域內和域間通信。也就是說，自適應AUTOSAR和COVESA對SOA的支持允許使用該特定平臺的接口定義語言（IDL），生成和描述基于SOME/IP的通信中間件。這簡化了開發，加快了在系統環境中整合算法的過程。然而，正如已經提到的，在不同的汽車領域之間沒有標準化的通信方法，因此沒有IDL或工具可以為這種目的提供自動中間件代碼生成。

在汽車通信和軟件建模標準中，數據是通過SOME/IP使用消息字段、方法和事件來交換的。AUTOSAR中的字段（或FRANCA中的屬性）是由服務存儲的值，可由服務器和客戶端訪問。客戶端可以通過讀取和/或設置字段值與服務器互動。訂閱的客戶可以得到關于字段修改的通知。當需要在服務端執行某個功能時，客戶端使用這些方法。它允許客戶端發送一些控制參數、請求更改或添加一些不是服務屬性的數據。方法可以是可回應的，也可以實現為不響應的“清除并忽略”請求。AUTOSAR中的事件（或FRANCA中的推送）是用來通知感興趣的客戶關于服務方事件的機制。客戶端可以訂閱推送，從而接收有關信息。可以在服務端進行選擇性發送，以便只通知選定的客戶。

另外，在SOME/IP可以使用的場景方面也有一些限制。由于以太網提供的可靠性不足，在需要具有確定性命令執行的情況下，不適合向執行器發送數據。此外，它的利用對收集傳感器的數據沒有好處。傳感器數據是在網絡堆棧的較低層傳輸的，即使用原始以太網。此外，SOME/IP提供了傳輸一系列數據的能力，這些數據可以代表圖像或視頻內容（一系列圖像），但在需要通過IP傳輸視頻流的情況下，使用一些現有協議（如RTSP）更為方便。現有流媒體協議的優勢在于對各種格式的內置支持以及在應用層面的現有支持。基于SOME/IP的SOA適用于流媒體管理，即控制流媒體的開始和停止、攝像機選擇、視頻格式選擇等。

C. 其他車載通信機制

有幾種通信機制對汽車使用情況很重要，如控制器區域網絡（CAN）、本地互聯網絡（LIN）和FlexRay等。由于這種車載網絡機制被認為是面向信號的架構的代表，而不是面向服務的架構，因此將不對其進行更詳細的研究。但值得一提的是，本文還分析了數據環境，以太網在與執行器通信時，由于可靠性不足或價格昂貴，無法與車載網絡相抗衡。CAN和FlexRay用于連接對確定性和可靠性要求最高的動力系統部件，如發動機、變速器和剎車，以及低成本的LIN，用于控制沒有嚴格時間要求的電動設備，如座椅、窗戶和門。

IV.方法比較

在前面的章節中已經描述了一些用于汽車系統組件之間通信的最常用機制。雖然面向信號的車內網絡提供了確定性和低延遲性，但它們不容易擴展，也不適合用于連接SOA組件。這使我們有可能需要在共享內存方法和SOME/IP通信之間進行選擇，這取決于應用程序是否需要在不同領域之間交換數據。

速度是共享內存的主要優勢，這可以從表二提供的實驗結果中看出。分析是根據同一設備內兩個不同的應用程序之間交換的兩種大小的數據來進行的，所以SOA和共享內存都適用。第一種情況(8字節)表示車輛在兩個應用程序之間的傳輸狀態。第二種情況(843千字節)是將從相機獲得的幀傳輸到處理應用程序。

在第二種情況下，由于需要更大的數據量，對于共享內存的訪問，需要使用一個字節來指示對內存的寫入是否完成來實現同步。在兩種數據大小上都進行了1000次測量，平均值在表中列出。很明顯，共享內存方法的性能明顯高于SOME/IP的性能。然而，這種機制沒有那么靈活，因為它很少適用于域內的數據交換，并可能在安全方面造成問題，因為多個應用程序組件可以訪問、修改一個內存位置的數據，并因此破壞數據。

表II 數據讀取性能

共享內存方法的另一個缺點是缺乏一種機制來通知使用特定數據點的應用程序數據發生了變化。解決方案是使用輪詢，定期檢查應用組件使用的數據是否可用或被修改。這樣的方法增加了應用邏輯的復雜性，影響了系統的整體性能。 與SOME/IP相比，SOA的額外好處是它可以用于異構平臺之間的域間通信，例如在一方是帶有AUTOSAR的ADAS系統，另一方是帶有Android操作系統的IVI。由于可以為安卓建立COVESA的通用API，所以解決方案可以是SOME/IP。 建議在UDP上使用SOME/IP而不是TCP。應用層的交付是有保證的，但在事件的情況下則不能。

為了在OSI模型的第四層實現交付確認，事件通過TCP發送。下一個衡量的目的是檢查速度方面的缺點，使用TCP而不是UDP，這帶來了額外的可靠性，。在使用SOME/IP時需要考慮的一個有趣的問題是，大多數IVI系統是基于Linux內核的，在這種情況下，TCP連接有可能比UDP快。這可能會導致意想不到的行為，即通過UDP的通信時間比通過TCP的通信時間長。表三的測量結果顯示，如果使用TCP，通過SOME/IP的方法調用的平均時間會更快，而且通過SOME/IP的SOA并不會因為帶有可靠性TCP而降低速度。

表IIISOME/IP方法的調用性能

V.總結

本文提供了對汽車數據交換的不同方法的分析。通過數據傳輸的類型和背景，以及對域內和域間通信的適用性來比較各種方法，重點是ADAS和IVI的跨域連接。事實證明，面向服務的架構機制是最適合這種跨域結合的方法。他們的優點、缺點以及與其他方法的比較都一一做了介紹、評估和討論。

未來的工作應該是在Android平臺上實現SOA范式，因為Android被越來越多地用作IVI系統的解決方案。

?

審核編輯：劉清