區域架構下信號服務轉換與Vehicle API

2022年8月5日，在由Gaspar和AUTOSAR聯合主辦的第三屆軟件定義汽車論壇暨2022年AUTOSAR中國日上，ETech /AUTOSAR技術經理謝宏建以區域架構下的信號業務轉換為主題，詳細介紹了區域架構的發展現狀以及如何實現區域架構下的信號業務轉換。對于AUTOSAR即將推出的車載API(車載接口)標準化，謝宏建表示:“誰能開發出一個被主機廠和供應商廣泛接受的車載ApI，誰就贏得了整個市場！“以下是演講的內容:

地域性建筑的發展現狀及演變趨勢

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

面對諸多挑戰，我們達成共識，應該從架構的創新入手。細看新架構，從硬件維度來看，為了提高可擴展性，提高總線通信效率，減少線束，所有i/o資源將按照區域重新劃分，打破功能界限，最終形成一個區域控制器。從應用層來說，整車的計算資源將進一步向整車計算機集中。未來所有應用都可能部署在整車電腦上，甚至運行在云端。

圖片來源:謝宏建

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

我們可以從以下幾個方面來看行業區域結構的發展。

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

圖片來源:謝宏建

AP和CP通信的區別

至此，我已經簡單介紹了區域控制器的特點。下面我們來看看AUTOSAR如何實現區域控制器中的信號服務轉換。首先，為什么要實現信號和服務的轉換。在E/E架構中，區域控制器和車載計算機扮演著最重要的角色。區域控制器本身主要是一個微控制器，經典的AUTOSAR(CP)平臺會在上面運行。Adaptive AUTOSAR的平臺將可能運行在整車計算機上，實現動態服務的通信和OTA的功能。交通……區域控制器和車載電腦之間需要on，軟件的實現就是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端部署某個/IP模塊，會涉及到很多子模塊，整個實現過程相對復雜。另外，這種方案對同一信息需要雙重維護，一個基于信號角度，一個基于服務，會造成信息的冗余，影響信號的實時傳輸。

圖片來源:謝宏建

如果將s2s部署到車載電腦上，可以從CP端實現基于信號的傳輸模式。對于區域控制器來說，可以遵循傳統的開發流程，所有信號都可以傳輸到車載電腦，不需要部署一些/IP協議棧。在這個方案中，AP實際上需要部署額外的s2s模塊:需要通過操作系統的TCP和UDP協議采集整個以太網報文，通過COM相關協議棧對信號進行分析，獲得相應的信號位置和長度信息，然后需要額外的s2s功能模塊將所有信號轉換成服務。

圖片來源:謝宏建

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

圖片來源:謝宏建

該方案實現的關鍵方法論是通過Etech的VRTE自適應工具提供信號的通信矩陣和一些/IP相關的描述文件，映射信號和服務，最終生成s2s的功能模塊。

圖片來源:謝宏建

作為全球領先的嵌入式軟件開發和汽車信息安全解決方案和服務提供商，Etech可以提供完整的AP和CP解決方案。Etech推出的解決方案ISOLAR有三個主要功能。ISOLAR-A用于應用層和系統配置開發，包括系統的通信矩陣和診斷描述文件。ISOLAR-B可以配置CP相關的軟件協議棧。最近增加了等值線自適應的功能，可以實現AP的配置開發。然后基于Etech的同一個ISOLAR工具，可以實現信號和服務的配置生成和映射，更容易實現s2s解決方案。

0

圖片來源:謝宏建

剛才給大家介紹了如何在AUTOSAR上實現信號和服務的轉換。對于這樣的解決方案，在車載通訊和車載電腦通訊中很有幫助，但對于車外通訊幫助不大。

汽車API的必要性

那么如何實現車外生態通信需要看車載API:

目前汽車行業有兩個趨勢。首先是互聯互通。整車不再是孤島。它需要與云互聯。通過云端可以實現OTA和遠程診斷，實現車輛狀態查詢和車輛控制。此外，汽車還需要通過藍牙與手機、手表互聯，通過V2X協議與交通設施和其他車輛通信，形成完整的交通智能網絡。還可以通過MQTT協議與智能家居、智能城市進行通信，構成了整個IOT生態系統。2022年8月5日，在由Gaspar和AUTOSAR聯合主辦的第三屆軟件定義汽車論壇暨2022年AUTOSAR中國日上，ETech /AUTOSAR技術經理謝宏建以區域架構下的信號業務轉換為主題，詳細介紹了區域架構的發展現狀以及如何實現區域架構下的信號業務轉換。對于AUTOSAR即將推出的車載API(車載接口)標準化，謝宏建表示:“誰能開發出一個被主機廠和供應商廣泛接受的車載ApI，誰就贏得了整個市場！“以下是演講的內容:

地域性建筑的發展現狀及演變趨勢

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

面對諸多挑戰，我們達成共識，應該從架構的創新入手。細看新架構，從硬件維度來看，為了提高可擴展性，提高總線通信效率，減少線束，所有i/o資源將按照區域重新劃分，打破功能界限，最終形成一個區域控制器。從應用層來說，整車的計算資源將進一步向整車計算機集中。未來所有應用都可能部署在整車電腦上，甚至運行在云端。

圖片來源:謝宏建

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

我們可以從以下幾個方面來看行業區域結構的發展。

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

圖片來源:謝宏建

AP和CP通信的區別

至此，我已經簡單介紹了區域控制器的特點。下面我們來看看AUTOSAR如何實現區域控制器中的信號服務轉換。首先，為什么要實現信號和服務的轉換。在E/E架構中，區域控制器和車載計算機扮演著最重要的角色。區域控制器本身主要是一個微控制器，經典的AUTOSAR(CP)平臺會在上面運行。Adaptive AUTOSAR的平臺將可能運行在整車計算機上，實現動態服務的通信和OTA的功能。交通……區域控制器和車載電腦之間需要on，軟件的實現就是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端部署某個/IP模塊，會涉及到很多子模塊，整個實現過程相對復雜。另外，這種方案對同一信息需要雙重維護，一個基于信號角度，一個基于服務，會造成信息的冗余，影響信號的實時傳輸。

圖片來源:謝宏建

如果把s2s部署到車載電腦上，從CP端就可以實現基于信號的傳輸模式。對于區域控制器來說，可以遵循傳統的開發流程，所有信號都可以傳輸到車載電腦，不需要部署一些/IP協議棧。在這個方案中，AP實際上需要部署額外的s2s模塊:需要通過操作系統的TCP和UDP協議采集整個以太網報文，通過COM相關協議棧對信號進行分析，獲得相應的信號位置和長度信息，然后需要額外的s2s功能模塊將所有信號轉換成服務。

圖片來源:謝宏建

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

圖片來源:謝宏建

該方案實現的關鍵方法論是通過Etech的VRTE自適應工具提供信號的通信矩陣和一些/IP相關的描述文件，映射信號和服務，最終生成s2s的功能模塊。

圖片來源:謝宏建

作為全球領先的嵌入式軟件開發和汽車信息安全解決方案和服務提供商，Etech可以提供完整的AP和CP解決方案。Etech推出的解決方案ISOLAR有三個主要功能。ISOLAR-A用于應用層和系統配置開發，包括系統的通信矩陣和診斷描述文件。ISOLAR-B可以配置CP相關的軟件協議棧。最近增加了等值線自適應的功能，可以實現AP的配置開發。然后基于Etech的同一個ISOLAR工具，可以實現信號和服務的配置生成和映射，更容易實現s2s解決方案。

0

圖片來源:謝宏建

剛才給大家介紹了如何在AUTOSAR上實現信號和服務的轉換。對于這樣的解決方案，在車載通訊和車載電腦通訊中很有幫助，但對于車外通訊幫助不大。

汽車API的必要性

那么如何實現車外生態通信需要看車載API:

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

圖片來源:謝宏建

在這種趨勢下，汽車和手機最大的區別就是手機協議明確，但是車內外的通信協議很多。如何打通不同的協議？這是我們面臨的最大挑戰。

第二個趨勢是國內外都在打造自己的操作系統，即OEM.OS，一般來說就是OEM。OS針對的不僅僅是車內的軟件系統，還有云端的軟件系統。

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

3

圖片來源:謝宏建

這是汽車側。讓我們簡單看一下云。云可能包括一些核心服務、平臺服務、數字孿生服務等。它還將包括生態系統開放發展港；也可以運行一些與車輛各種功能域相關的軟件和第三方軟件。車載API的目的就是在此基礎上實現所有應用軟件的互聯功能。Etech提供多種開發端口，未來將進一步將應用軟件部署到云端，支持第三方服務。

車云集成的未來需要車輛API的支持，需要滿足以下要求:一是需要開放的已知接口，幫助不同的應用層實現交互和復用。二是高，容易集成。第三是不能給代工帶來額外的工作。

4

圖片來源:謝宏建

COVESA在第13屆AUTOSAR開放大會上為AUTOSAR提出了標準化概念，包括三個方面:首先，定義了通用數據模型和服務模型，實現不同設備間信息描述的統一。二是標準化相應的數據和服務。事實上，中國的許多組織和企業都試圖制定標準化的數據和服務。難點不在于技術，而在于如何讓更多的主機廠和供應商達成數據和服務標準化的共識。三是相應軟件基礎協議棧的支持，幫助實現跨通信交互和數據轉換。

5

圖片來源:謝宏建

回到通用數據服務模型，covesa使用vss和vsc語言。vss的全稱是車輛信號規范(vehicle signal specification)，來源于2016年w3c的汽車工作組發布的首個公開工作草案。在設計之初，我希望車載信息娛樂系統和本地車載網絡中運行的應用程序能夠訪問車輛信號和其他數據。所以vss主要以車輛信號為主，將車輛信號進行功能分類。

例如，這是一個樹形信號分類的例子。綠色的原點代表分支，車輛信號可以根據功能域分為不同的分支。分支的末端可以是信號、傳感器信號或致動器信號的屬性。Vss用yaml語言描述，方便人們讀寫。其次，它可以很容易地被各種工具解釋，并生成其他類型的文件。然后，基于vss標準，所有相關從業者可以就統一的信號描述和文件類型達成一致，從而實現更容易的信號信息交互。也為配套工具的開發做好了充分的準備。

6

圖片來源:謝宏建

有了vss和vsc，還是解決不了軟件互聯的問題。比如云端的信號和服務基于HTTP協議發送到車載電腦，車載電腦內部主要基于someip通信，甚至包括dds協議。我們還需要支持工具和軟件來實現不同協議之間的轉換。

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

7

圖片來源:謝宏建

展望未來，汽車可能會像手機一樣成為更加融合的智能設備。作為應用程序開發人員，通常不再需要關心模型和系統之間的差異。應用開發完成后，可以部署到任何型號，使用相關功能。從這個角度來說，車輛API將起到關鍵作用，所以誰能開發出一個被主機廠和供應商廣泛接受的車輛API，誰就贏得了整個市場！謝謝大家！8

圖片來源:易特馳官網

(以上內容來自ETech /AUTOSAR技術經理謝宏建在2022年8月5日由Gaspar和AUTOSAR聯合主辦的第三屆軟件定義車輛論壇2022暨AUTOSAR中國日上發表的主題演講《區域框架下的信號服務轉換與車輛接口》。) 2

圖片來源:謝宏建

在這種趨勢下，汽車和手機最大的區別就是手機協議明確，但是車內外的通信協議很多。如何打通不同的協議？這是我們面臨的最大挑戰。

第二個趨勢是國內外都在打造自己的操作系統，即OEM.OS，一般來說就是OEM。OS針對的不僅僅是車內的軟件系統，還有云端的軟件系統。

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

3

圖片來源:謝宏建

這是汽車側。讓我們簡單看一下云。云可能包括一些核心服務、平臺服務、數字孿生服務等。它還將包括生態系統開放發展港；也可以運行一些與車輛各種功能域相關的軟件和第三方軟件。車載API的目的就是在此基礎上實現所有應用軟件的互聯功能。Etech提供多種開發端口，未來將進一步將應用軟件部署到云端，支持第三方服務。

車云集成的未來需要車輛API的支持，需要滿足以下要求:一是需要開放的已知接口，幫助不同的應用層實現交互和復用。二是高，容易集成。第三是不能給代工帶來額外的工作。

4

圖片來源:謝宏建

COVESA在第13屆AUTOSAR開放大會上為AUTOSAR提出了標準化概念，包括三個方面:首先，定義了通用數據模型和服務模型，實現不同設備間信息描述的統一。二是標準化相應的數據和服務。事實上，中國的許多組織和企業都試圖制定標準化的數據和服務。難點不在于技術，而在于如何讓更多的主機廠和供應商達成數據和服務標準化的共識。三是相應軟件基礎協議棧的支持，幫助實現跨通信交互和數據轉換。

5

圖片來源:謝宏建

回到通用數據服務模型，covesa使用vss和vsc語言。vss的全稱是車輛信號規范(vehicle signal specification)，來源于2016年w3c的汽車工作組發布的首個公開工作草案。在設計之初，我希望車載信息娛樂系統和本地車載網絡中運行的應用程序能夠訪問車輛信號和其他數據。所以vss主要以車輛信號為主，將車輛信號進行功能分類。

例如，這是一個樹形信號分類的例子。綠色的原點代表分支，車輛信號可以根據功能域分為不同的分支。分支的末端可以是信號、傳感器信號或致動器信號的屬性。Vss用yaml語言描述，方便人們讀寫。其次，它可以很容易地被各種工具解釋，并生成其他類型的文件。然后，基于vss標準，所有相關從業者可以就統一的信號描述和文件類型達成一致，從而實現更容易的信號信息交互。也為配套工具的開發做好了充分的準備。

6

圖片來源:謝宏建

有了vss和vsc，還是解決不了軟件互聯的問題。比如云端的信號和服務基于HTTP協議發送到車載電腦，車載電腦內部主要基于someip通信，甚至包括dds協議。我們還需要支持工具和軟件來實現不同協議之間的轉換。

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

7

圖片來源:謝宏建

展望未來，汽車可能會像手機一樣成為更加融合的智能設備。作為應用程序開發人員，通常不再需要關心模型和系統之間的差異。應用程序開發完成后，可以部署到任何型號，并使用相關功能。從這個角度來說，車輛API將起到關鍵作用，所以誰能開發出一個被主機廠和供應商廣泛接受的車輛API，誰就贏得了整個市場！謝謝大家！8

圖片來源:易特馳官網

(以上內容來自ETech /AUTOSAR技術經理謝宏建在2022年8月5日由Gaspar和AUTOSAR聯合主辦的第三屆軟件定義車輛論壇2022暨AUTOSAR中國日上發表的主題演講《區域框架下的信號服務轉換與車輛接口》。)

標簽：發現DS理念遠程

汽車資訊熱門資訊