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

I.簡介

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

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

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

II.汽車行業(yè)的SOA原則

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

圖1 面向服務(wù)的中間件架構(gòu)

III.可能的通信機制

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

A. 共享內(nèi)存

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

對于域內(nèi)通信，共享內(nèi)存可用于交換常規(guī)數(shù)據(jù)，它不適用于從傳感器收集數(shù)值并向執(zhí)行器發(fā)送命令的情況。

圖2 汽車領(lǐng)域的通信方式

表I 通信方式的比較

B. SSOME/IP和以太網(wǎng)

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

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

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

C. 其他車載通信機制

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

IV.方法比較

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

速度是共享內(nèi)存的主要優(yōu)勢，這可以從表二提供的實驗結(jié)果中看出。分析是根據(jù)同一設(shè)備內(nèi)兩個不同的應(yīng)用程序之間交換的兩種大小的數(shù)據(jù)來進(jìn)行的，所以SOA和共享內(nèi)存都適用。第一種情況(8字節(jié))表示車輛在兩個應(yīng)用程序之間的傳輸狀態(tài)。第二種情況(843千字節(jié))是將從相機獲得的幀傳輸?shù)教幚響?yīng)用程序。

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

表II 數(shù)據(jù)讀取性能

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

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

表IIISOME/IP方法的調(diào)用性能

V.總結(jié)

本文提供了對汽車數(shù)據(jù)交換的不同方法的分析。通過數(shù)據(jù)傳輸?shù)念愋秃捅尘?，以及對域?nèi)和域間通信的適用性來比較各種方法，重點是ADAS和IVI的跨域連接。事實證明，面向服務(wù)的架構(gòu)機制是最適合這種跨域結(jié)合的方法。他們的優(yōu)點、缺點以及與其他方法的比較都一一做了介紹、評估和討論。

未來的工作應(yīng)該是在Android平臺上實現(xiàn)SOA范式，因為Android被越來越多地用作IVI系統(tǒng)的解決方案。

?

審核編輯：劉清