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

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

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

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

圖片來源：謝宏健

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

我們可以通過以下幾個(gè)方面看看行業(yè)內(nèi)區(qū)域架構(gòu)的發(fā)展?fàn)顩r。

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

圖片來源：謝宏健

AP和CP通信的差異性

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

圖片來源：謝宏健

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

圖片來源：謝宏健

實(shí)現(xiàn)信號(hào)服務(wù)轉(zhuǎn)換的四種方案

結(jié)合新的架構(gòu)，如果要實(shí)現(xiàn)信號(hào)和服務(wù)的轉(zhuǎn)換，基本上有這幾種方案：

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

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

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

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

圖片來源：謝宏健

AUTOSAR上如何實(shí)現(xiàn)信號(hào)和服務(wù)的轉(zhuǎn)換

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

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

圖片來源：謝宏健

采用這樣的方案，最大的優(yōu)勢就在于CP端和AP端都支持SOME/IP協(xié)議，那么通信協(xié)議棧基于供應(yīng)商的工具鏈就能實(shí)現(xiàn)。當(dāng)然這個(gè)方案也存在很多不足：如果在CP端部署SOME/IP模塊，它會(huì)牽扯到很多子模塊，整個(gè)實(shí)施過程相對(duì)來說比較復(fù)雜。此外，這一方案針對(duì)同樣的信息需要兩重維護(hù)，一個(gè)是基于信號(hào)角度維護(hù)信息，還要基于服務(wù)進(jìn)行維護(hù)，會(huì)造成信息的冗余，影響到信號(hào)傳輸?shù)膶?shí)時(shí)性。

圖片來源：謝宏健

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

圖片來源：謝宏健

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

圖片來源：謝宏健

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

圖片來源：謝宏健

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

圖片來源：謝宏健

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

Vehicle API的必要性

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

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

圖片來源：謝宏健

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

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

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

圖片來源：謝宏健

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

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

圖片來源：謝宏健

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

圖片來源：謝宏健

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

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

圖片來源：謝宏健

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

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

圖片來源：謝宏健

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

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

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

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