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

區(qū)域架構的發(fā)展現(xiàn)狀與演進趨勢

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

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

圖片來源：謝宏健

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

我們可以通過以下幾個方面看看行業(yè)內(nèi)區(qū)域架構的發(fā)展狀況。

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

圖片來源：謝宏健

AP和CP通信的差異性

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

圖片來源：謝宏健

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

圖片來源：謝宏健

實現(xiàn)信號服務轉換的四種方案

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

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

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

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

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

圖片來源：謝宏健

AUTOSAR上如何實現(xiàn)信號和服務的轉換

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

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

圖片來源：謝宏健

采用這樣的方案，最大的優(yōu)勢就在于CP端和AP端都支持SOME/IP協(xié)議，那么通信協(xié)議?；诠痰墓ぞ哝溇湍軐崿F(xiàn)。當然這個方案也存在很多不足：如果在CP端部署SOME/IP模塊，它會牽扯到很多子模塊，整個實施過程相對來說比較復雜。此外，這一方案針對同樣的信息需要兩重維護，一個是基于信號角度維護信息，還要基于服務進行維護，會造成信息的冗余，影響到信號傳輸?shù)膶崟r性。

圖片來源：謝宏健

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

圖片來源：謝宏健

這一解決方案的優(yōu)勢在于，不僅能夠實現(xiàn)信號向整車電腦輸出的實時性，還能將整個區(qū)域控制下面?zhèn)鹘y(tǒng)的CAN/LIN信號，經(jīng)過區(qū)域控制器中CP AUTOSAR的PduR模塊直接給到整車電腦，可以高效地保證通信的實時性。缺點是AP的工具鏈端需要部署s2s的功能。

圖片來源：謝宏健

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

圖片來源：謝宏健

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

圖片來源：謝宏健

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

Vehicle API的必要性

那么如何實現(xiàn)車外生態(tài)通信，需要看一下Vehicle API：

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

圖片來源：謝宏健

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

趨勢之二是，無論國內(nèi)還是國外都在打造屬于自己的操作系統(tǒng)，即OEM.OS?？偟膩碇v，OEM.OS 所針對的不僅僅包含了車端的軟件系統(tǒng)，還包含了云端的軟件系統(tǒng)。 

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

圖片來源：謝宏健

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

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

圖片來源：謝宏健

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

圖片來源：謝宏健

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

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

圖片來源：謝宏健

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

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

圖片來源：謝宏健

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

圖片來源：易特馳 官網(wǎng)

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

返回第一電動網(wǎng)首頁 >