2022年8月5日，由蓋世汽車、AUTOSAR組織聯合主辦的2022第三屆軟件定義汽車論壇暨AUTOSAR中國日活動中，易特馳/AUTOSAR技術經理謝宏健聚焦區域架構下的信號服務轉換，對區域架構的發展現狀，如何在區域架構下實現信號服務轉換做了詳盡地介紹，針對AUTOSAR即將推出的Vehicle API（整車接口）標準化，謝宏健表示：“誰能夠開發出來讓OEM和供應商廣泛接受的Vehicle ApI，誰就會贏得整個市場！”以下為演講內容整理：

區域架構的發展現狀與演進趨勢

先來看一下什么是區域架構。目前整個汽車行業正處于新四化的變革當中：首先是電器化，動力電池、驅動電機和電控系統取代了傳統的發動機和變速箱，經過十幾年的發展已經趨于成熟。第二個是互聯化，汽車不再是一個孤島，它將會與萬物互聯。再次是智能化，智能化一般指的是自動駕駛技術，也是當前最熱門的話題，比如這三天的會議，很多話題都是圍繞自動駕駛技術。最后是個性化，個性化是以用戶為中心的延伸，隨著汽車行業的發展，消費者對于個性化的需求會日益強烈。汽車新四化帶來技術和商業模式的創新，同時也為整個OEM和供應商帶來了巨大的挑戰：如何快速的更新軟件與功能？如何進行跨區域合作？如何基于大數據提升用戶的體驗？如何提升資源效率，包括計算資源和帶寬資源？如何增強信息安全和功能安全？如何降低整個電機架構的復雜度？

面對諸多挑戰，我們達成的共識是從架構的革新入手。具體看一下新的架構，從硬件維度看，為了提高擴展性、提升總線通信效率、減少線束，所有i/o資源會根據區域重新劃分，打破功能邊界，最終形成區域控制器。從應用層看，整車的計算資源會進一步向整車電腦集中，將來所有的應用程序都有可能部署到整車電腦上，甚至會上升到云端運行。

圖片來源：謝宏健

基于這兩個維度，我們發現區域控制器會扮演三個重要角色：首先作為區域的輸入輸出中心，會連接所有的傳感器、執行器，實現最基本的硬件邏輯。其次會作為區域的數據中心，實現區域路由、網關功能。再是作為電力分配中心，基于智能電網分配模塊，實現對整個區域的傳感器、執行器和ECU電源的動態分配。

我們可以通過以下幾個方面看看行業內區域架構的發展狀況。

首先是硬件的集成度，新的架構要減少ECU的數量和線束的長度，只有將所有區域下的硬件功能資源都向區域控制器上進行集中，才能實現目的。其次是軟件的集成度，目前許多OEM都實現了整車OTA功能，未來還要看是不是把區域相關的功能和應用層上移到整車電腦上。第三是區域控制器的數量，所有的OEM在架構上都可以部署2-6個區域控制器。電力分配方面，是采用傳統的、機械式的保險盒，還是升級到智能配電模塊，來實現所有i/o資源的動態電力分配，并且實現電力冗余。此外，在骨干網和子網上會采用千兆的以太網、新的CAN XL，CAN FD等協議組合，來實現整個通信的網絡拓撲。最后是針對智能駕駛和智能座艙的子節點、數據和電力分配，是否集成到區域控制器當中。

圖片來源：謝宏健

AP和CP通信的差異性

到此我已經簡單介紹了一下區域控制器的特點，下面我們再來看一看如何在區域控制器當中以AUTOSAR的方式實現信號服務的轉換。首先，為什么需要實現信號和服務的轉換。E/E架構中，區域控制器和整車電腦扮演著最為重要的角色，區域控制器本身以微控制器為主，上面還會運行著Classic AUTOSAR（CP）平臺。在整車電腦上大概率會運行Adaptive AUTOSAR的平臺，來實現動態服務的通信和OTA的功能。區域控制器和整車電腦之間是需要通信的，落實到軟件就是CP和AP如何實現通信。AP和CP必須要通信的原因在于， AP上運行的功能應用軟件，肯定需要獲取CP軟件上產生的車速、溫度等傳統的信號，反過來CP軟件要實現一些功能邏輯，獲取功能軟件應用層下發出來的命令服務。

圖片來源：謝宏健

我們再來看一看AP和CP會有什么區別？從通信方式看，CP軟件它是以信號的方式實現通信，是靜態配置的。從整個開發流程來講，首先需要明確通信的矩陣，生成相應的配置，再做相應的代碼生成、調試、運行、測試、驗證，最后部署到ECU當中去。一旦部署到ECU當中，整個通信屬性就被固化下來，一旦需要改動其中的信號就會涉及到整個流程。在AP端，通信方式是不一樣的，它是基于服務方式實現通信，是可動態配置的。舉個例子，就好比我們訪問網站，只有訪問時才會和電腦的服務器進行通信；當不訪問的時候，電腦就不需要周期性地和服務器進行通信。站在AP軟件角度，我們可以動態地增加客戶端和服務端，而無需改變整個操作系統。基于AP和CP在通信協議上差異性，如果要實現CP和AP之間的通信，必然要在某個層級實現信號和服務轉換的功能。

圖片來源：謝宏健

實現信號服務轉換的四種方案

結合新的架構，如果要實現信號和服務的轉換，基本上有這幾種方案：

第一種是將信號和服務的轉化部署在傳統的ECU當中，此時可以發現傳統的ECU和區域控制器、區域控制器和整車電腦都是基于服務進行通信。在實際操作中，這種方案基本上是無法實現的。因為傳統的ECU都是供應商提供完整的解決方案，要增加基于服務式的通信方式，改進成本會非常高昂。而且傳統的ECU本身并不帶有以太網的通信協議棧，且計算資源很有限，很難實現這種功能。

第二種方案是將信號服務轉化部署到區域控制器上，傳統ECU和區域控制器以基于信號的方式進行通信，區域控制器和整車電腦是以服務的方式通信，這個方案目前比較容易理解。

第三種方案是將信號服務的解決方案部署到整車電腦的AP端，傳統ECU和區域控制器以信號方式通信，區域控制器和整車電腦也是基于信號通信。AP端會基于額外的模塊將信號轉換成服務提供給應用層，這種方案也也有一定的實施性。

最后一種方案是將信號服務直接部署到應用層上，顯然易見它會造成應用層的巨大問題，這種方案基本上也不會實現。

圖片來源：謝宏健

AUTOSAR上如何實現信號和服務的轉換

下面再來具體看看第二個和第三個方案在AUTOSAR上如何實現。

如果將s2s部署到區域控制器當中，對應的，因為AP端已經具備了ara::com，本身是具備DDS，SOME/IP等動態服務通信的協議棧，因此AP端不需要做任何改變。但要在CP端實現SOME/IP的協議功能，除了需要部署相關協議棧之外，還要有SD模塊，BswM模塊，SOME/IP TP模塊等等，并結合應用層實現整個SOME/IP的通信協議。

圖片來源：謝宏健

采用這樣的方案，最大的優勢就在于CP端和AP端都支持SOME/IP協議，那么通信協議棧基于供應商的工具鏈就能實現。當然這個方案也存在很多不足：如果在CP端部署SOME/IP模塊，它會牽扯到很多子模塊，整個實施過程相對來說比較復雜。此外，這一方案針對同樣的信息需要兩重維護，一個是基于信號角度維護信息，還要基于服務進行維護，會造成信息的冗余，影響到信號傳輸的實時性。

圖片來源：謝宏健

如果將s2s部署到整車電腦端，從CP端可以實現基于信號的傳輸方式，針對區域控制器可以沿用傳統的開發流程，將所有信號轉到整車電腦端，不需要再額外部署SOME/IP協議棧。這一方案下，AP端實際還需要部署額外的s2s模塊：需要通過操作系統的TCP，UDP協議，將整個以太網的報文收集上來，通過COM相關協議棧進行信號的解析，獲取對應的信號位置和長度信息，再需要額外的s2s的功能模塊，將所有信號轉換成服務。

圖片來源：謝宏健

這一解決方案的優勢在于，不僅能夠實現信號向整車電腦輸出的實時性，還能將整個區域控制下面傳統的CAN/LIN信號，經過區域控制器中CP AUTOSAR的PduR模塊直接給到整車電腦，可以高效地保證通信的實時性。缺點是AP的工具鏈端需要部署s2s的功能。

圖片來源：謝宏健

該方案得以實現的關鍵方法論是，提供信號的通信矩陣和SOME/IP相關的描述文件，經過易特馳的VRTE Adaptive工具進行信號和服務的映射，最終生成s2s的功能模塊。

圖片來源：謝宏健

易特馳作為全球領先的嵌入式軟件開發與汽車信息安全解決方案和服務提供商，能夠提供完整的AP和CP的解決方案。易特馳推出的解決方案ISOLAR帶有三個主要的功能，ISOLAR-A 被用于應用層、系統的配置開發，包含系統的通信矩陣和診斷描述文件。ISOLAR-B可以做CP相關軟件協議棧的配置。最近又增加了ISOLAR Adaptive這樣一個功能，可以實現AP的配置開發工作。那么，基于易特馳的同一ISOLAR工具，就可以實現信號、服務的配置生成，信號和服務的映射，更加容易的實現s2s解決方案。

圖片來源：謝宏健

剛才向大家介紹了如何在AUTOSAR上實現信號和服務的轉換，對于這樣的解決方案，它在整車通信、車載電腦通信上非常有幫助，但對于車外通信沒有任何的幫助。

Vehicle API的必要性

那么如何實現車外生態通信，需要看一下Vehicle API：

目前汽車行業有兩個趨勢，首先是互聯化，整車不再是孤島，它需要和云端互聯，通過云端可以實現OTA、遠程診斷，實現車輛狀態的查詢和車輛控制。除此之外，車還需要通過藍牙和手機、手表互聯，通過V2X協議與交通設施和其他車輛通信，構成完整的交通智能網絡。還有可能通過MQTT協議和智慧家庭、智慧城市做通信，構成整個IOT的生態系統。

圖片來源：謝宏健

這種趨勢下，汽車和手機最大的不同點在于：手機協議是明確的，但汽車所擁有的車內和車外的通信協議眾多，如何打通不同協議？這是我們面臨的最大挑戰。

趨勢之二是，無論國內還是國外都在打造屬于自己的操作系統，即OEM.OS。總的來講，OEM.OS 所針對的不僅僅包含了車端的軟件系統，還包含了云端的軟件系統。 

在汽車上，我們知道最底層硬件是微控制器和微處理器，甚至是包含兩者的SOC。硬件的上一層是啟動程序，燒寫更新引導程序； 再往上是hypervisor來實現區域隔離，系統隔離。再上一層可能會涉及芯片內不同內核之間，不同域間通信的軟件， 再往上，按照功能可以劃分為不同的基礎軟件或者中間件，比如以太網交換機軟件， 信息安全軟件， 經典autosar軟件， 整車電腦里的自適應autosar軟件， 自動駕駛相關軟件， 智能座艙相關軟件。 再往上則是各種應用軟件。

圖片來源：謝宏健

 這是車端， 我們再來簡單看下云端， 云端有可能會包含一些核心服務，平臺服務，數字孿生服務等； 還會包含生態系統開放開發端口； 那還有可能會運行一些和車輛各個功能域相關的軟件和第三方軟件。 而vehicle API的目的則是基于此實現所有應用軟件的互聯互通功能。易特馳提供各種各樣的開發端口，將來會進一步將應用軟件部署到云端，支持第三方服務。

車云一體化的未來需要Vehicle API做支撐，Vehicle API需要滿足以下要求：第一是明確需要開放和已知的接口，幫助不同的應用層實現交互、復用。第二是高度、易于集成。第三是不能給OEM帶來額外的工作。

圖片來源：謝宏健

COVESA在第十三屆AUTOSAR開放大會上提出了針對AUTOSAR的標準化理念，包含三個方面：第一定義了通用數據模型和服務模型，實現不同設備之間信息描述的統一。第二是標準化相應的數據和服務，實際上，國內也有很多組織和企業嘗試去制定標準化的數據和服務，難點并不在技術上，而在于如何讓更多的OEM和供應商達成標準化的數據和服務共識。第三是相應的軟件基礎協議棧的支撐，去幫助實現跨通信的交互、數據轉換。

圖片來源：謝宏健

回到通用數據服務模型上，covesa 采用的vss和vsc語言。 vss全稱是車輛信號規范，來自于w3c組織汽車工作組在2016年發布的首份公開工作草案。設計目的之初就是希望運行在車載信息娛樂系統及本地車輛網絡中的應用程序來訪問車輛信號及其他數據。 因此，vss主要針對的是車輛信號，并且將車輛信號進行功能分類。 

比如這就是一個樹狀信號分類示例。 綠顏色的原點代表分支，可以將整車信號按照功能域劃分在不同的分支。 分支的末端可以是信號的屬性，傳感器信號，或者執行器信號。 vss采用yaml語言來進行描述，方便人類讀寫。其次，可以容易被各種工具進行解讀并生成其他類型文件。 那么基于該vss標準，可以讓所有相關從業者在統一信號描述，及文件類型上達成一致，從而實現更加容易的信號信息交互。為配套工具的開發也做了很好的準備。

圖片來源：謝宏健

有了vss和vsc， 我們還是無法解決軟件的互聯互通，比如云端的信號和服務基于HTTP協議給到車載電腦，車載電腦內部是以someip通信為主，甚至還包含dds協議。 我們還需要配套的工具和軟件來實現不同協議之間的轉換。

在autosar concept703中提到了一個解決方案：該方案由配置工具和網關模塊構成。在autosar端，信號和服務采用vss vsc描述語言。 autosar工具商基于vss和vsc的輸入轉換成應用層所需要的arxml文件實現符合ara com的通信接口。 同時autosar工具還需要將vss vsc信息轉換成需要滿足http協議或者其他協議的接口文件。 用于實現相關協議信息的解讀。 基于此，還需要特定的網關中間件來實現不同協議之間的轉換。 最終實現應用層與通信協議的完全解耦。

圖片來源：謝宏健

展望未來，汽車有可能像手機一樣，成為一個更加趨同的智能設備，作為應用開發者，往往不再需要關心車型差別和系統差異，應用開發出來以后都能夠部署到任何車型上，并使用相關的功能。這一角度下，Vehicle API會起到關鍵的作用，因此，誰能夠開發出來讓OEM和供應商廣泛接受的Vehicle API，誰就會贏得整個市場！謝謝大家！

圖片來源：易特馳 官網

（以上內容來自易特馳/AUTOSAR技術經理謝宏健于2022年8月5日由蓋世汽車、AUTOSAR組織聯合主辦的2022第三屆軟件定義汽車論壇暨AUTOSAR中國日發表的《區域架構下的信號服務轉換和整車接口》主題演講。）

返回第一電動網首頁 >