詳解汽車SOA主要功能模塊及開發流程

來源：智能汽車設計

近年來，汽車“新四化”（智能化、網聯化、電動化、共享化）的快速推進，給汽車行業帶來了新的技術變革，汽車的功能變得越來越復雜，尤其是智能座艙、智能駕駛、智能底盤的出現，促使汽車電子電氣架構也相應地發生變革。

隨著汽車智能化發展、汽車功能的增加，汽車上的電子控制單元（Electronic Control Unit，ECU）也越來越多，每個ECU的信號都必須在設計時進行靜態規劃和路由，為了應對這種增長帶來的挑戰，汽車行業正在采用1種新的架構，即面向服務的體系架構（Service-Oriented Architecture,SOA）。

01.

SOA簡介

SOA是從遵循服務導向原則的可重用服務中構建復雜軟件系統的方法。SOA也是1個組件模型，它將應用程序的不同功能單元（稱為服務），通過這些服務之間定義良好的接口和契約聯系起來。接口采用中立的方式進行定義，它應該獨立于實現服務的硬件平臺、操作系統和編程語言。這使得構建在各種各樣的系統中的服務以1種統一和通用的方式進行交互。SOA可以根據需求通過網絡對松散耦合的粗粒度應用組件進行分布式部署、組合和使用。服務層是SOA的基礎，可以直接被應用調用，從而有效控制系統中因軟件代理交互而產生的人為依賴性。

SOA的特點是松耦合性、路徑透明、可復用性、一定的標準化，不涉及底層編程接口和通訊模型。

SOA在IT行業中已經使用了多年，旨在描述和構建分布式系統。同時，面向服務的設計在汽車工業中也變得極為重要。

傳統汽車通訊是基于信號的通訊方式，即信息發送者不關心誰接收而只負責將信號發送出去，接收者也不關心是誰發送的，而只負責接收信號，這種方式適用于有限大小控制數據的應用場景。

SOA代碼靈活性強，支持請求/響應模式，支持復雜的數據模型，可擴展性強，能夠滿足自動駕駛等應用場景下，大量數據的動態交互，可以對系統進行部分更新，如圖1所示。

圖1 面向信號與面向服務對比

汽車領域采用SOA的優勢是能加快車輛與互聯網的互聯互通。比如，能夠將各種新功能靈活地與互聯網集成；能夠實現更高效的車載自動診斷系統OBD（On Board Diagnostics，OBD）及空中下載技術（Over-The-Air Technology，OTA）軟件升級，有助于實現各種遠程診斷、預診斷功能；能夠大幅提升影音娛樂功能的用戶體驗，能夠實現不同平臺間的各種App共享功能；更便于實現平臺架構升級；同時各個服務可以由不同團隊獨立開發，可以縮短車輛開發的時間。

02.

硬SOA主要模塊及功能

Wonseon和Seung設計了端到端的SOA，如圖2。

圖2 端到端面向服務的架構

在傳統的車載網絡中：

（1）許多ECU是基于CAN等舊式IVN進行工作。

（2）大量的車輛信息和功能也來自舊式IVN。

（3）基于以太網的ECU上的新應用程序應可以訪問這些信息/功能。

在本架構中，主要的功能模塊有SOA適配器（SOA Adaptor），SOA網關（G/W），SD代理（SD Proxy）和服務路由（Service Router）。下面將介紹各個模塊的功能。

2.1 SOA適配器

（1）將信息/功能從舊式IVN轉換為“服務”，任何基于以太網的ECU上的應用程序都可以輕松訪問。

（2）在以太網方面，服務是在SOME/IP協議之上提供的。

（3）可以在舊版IVN和基于以太網的IVN之間的“橋接ECU”上實現，例如域控制單元，區域控制器等。也可以僅在具有以太網接口的非橋接ECU上實現。

（4）SOA適配器提供的服務可以動態更改。

2.2 SOA網關

（1）處理與外部設備/網絡互通相關的問題。

（2）必要時轉換協議并翻譯。

（3）緩存外部信息以處理外部網絡的可用性和成本問題。

（4）應用策略并執行服務級別的訪問控制。

（5）應該在具有外部連接的ECU上實施。

2.3 SD代理

（1）可以使用SD代理實現集中式SD。通過1個稱為“SD代理”的中央模塊交換服務發現消息。SOME/IP-SD消息也可用于ECU與SD代理之間的通信。

（2）分布式SD方法的安全和流量問題可以由集中式SD處理。每個服務只能由允許的ECU查找和訂閱。可以有效地監視服務可用性和搜索/訂閱嘗試。

2.4 服務路由

可以使用服務路由器來處理來自SOA分布式性質的問題。服務只能通過服務路由器來使用。服務路由可以應用于選定的服務。SD代理可用于高效的服務路由實施，安全和資源問題可以得到有效處理，可以基于域、ECU、服務甚至方法來控制服務訪問，策略也可以動態應用。

03.

汽車SOA應用現狀

SOA是汽車以太網和IP帶來的汽車系統/軟件體系架構的創新，其概念可以擴展到從傳統ECU到外部設備的端到端范圍。SOA適配器和SOA網關可以分別用于舊設備和外部設備。通過使用其他SOA實體可以有效地管理SOA。端到端SOA支持快速高效地部署各種互聯汽車服務。

劉佳熙等在面向服務架構汽車軟件開發方法和實踐中，提出SOA汽車軟件的分成模型，如圖3示。

圖3 SOA汽車分層模型

該模型主要包括3個層級：元服務、基礎服務和應用服務，通過不同的服務層級來分別對應不同層級的汽車業務邏輯。

元服務是最小單元。包括汽車的傳感器和執行器等的基本接口。基礎服務是中間層服務，在利用元服務的基礎上，可自定義汽車業務模塊，比如利用自車狀態服務和雷達傳感器等服務，組合出環境信息融合的服務。應用服務是最頂層的服務，可以訪問和調用基礎服務以幫助其解決業務問題。

在設計中，上層服務調用下層服務，下層服務不調用上層服務，這一原則有助于構建清晰簡單的SOA汽車軟件架構。寶馬公司在新一代的E/E架構中引入了SOA的方法，如圖4所示。SOA為整個系統提供大量的抽象服務。嚴格的封裝和層次結構允許針對接口和使用敏捷方法進行測試，并且它們降低了系統復雜性。在各代汽車之間重用軟件組件將變得更加簡單。

圖4 BMW下一代E/E架構

大眾MEB平臺車載應用服務架構（In-Car Appli?cation-Server,ICAS），采用了1種可升級的新方法，如圖5所示。采用集中式功能與應用程序軟件和I/O功能分離的架構，來降低整體系統復雜性和應用程序之間的依賴性，同時可以高效快速地開發客戶功能，提供一些客戶職能所需的基本服務，并且利用面向服務的通信。

圖5 大眾MEB平臺車載應用服務架構升級方法示例

在該架構中還強調，SOA是數字化的關鍵，如圖6所示，該架構的優點如下：

圖6 面向服務通信架構

（1）采用面向服務的通信；

（2）使用服務發現和發布/訂閱進行動態綁定；

（3）數據表示主要基于REST（表述性狀態傳遞）過渡到統一接口、無狀態、關注點分離；

（4）接口的向前和向后兼容性。

最后，通過提高可更新性、可升級性、重用能力和便攜性，使大眾汽車可以實現各種功能。

在AUTOSAR自適應平臺（Adaptive Platform，AP）設計中，為了支持復雜的應用程序，同時在處理分布和計算資源分配方面允許最大的靈活性和可擴展性，AP遵循了面向服務的體系結構理念。

SOA通常具有AP所具有的系統間特性。例如，服務可以駐留在應用程序運行的本地ECU上，也可以位于遠程ECU上，該遠程ECU也在運行另一個AP例。

上汽組建“零束”軟件子公司，聚焦基于SOA技術的智能駕駛系統工程，同時推出“Z-ONE”的SOA開放平臺，致力于打造上汽SOA的軟件生態。該平臺是以SOA理念打造整車功能，將汽車各個功能模塊化。同時可以讓第3方開發者甚至是普通用戶參與到軟件功能的打造。

威馬汽車在2021年4月交付的威馬W6汽車，率先推出了車輛自定義場景編程功能，實現25種能力、自定義場景超100個、手機端與車機端的同步，未來將攜手用戶及開發者，打開“千人千面”的全新格局。

04.

汽車SOA開發流程

Andreas等開發面向服務的車用應用程序，并使用空中軟件更新部署它。主要流程如圖7所示。

圖7 汽車的SOA開發流程

研究背景如下：在巴塞羅那舉行的2019年世界移動通信大會上，梅賽德斯·奔馳展示了1款經過改裝的車輛，可與開源SuperTuxKart游戲一起用作沉浸式游戲系統。游戲是使用真實的方向盤控制游戲中的車輛，空調模擬虛擬賽車的氣流、溫度效果。

Andreas假設車輛類型的制造商現在想要開發這樣的游戲系統并將其部署到車輛上，可作為車主購買的可選更新，其開發流程如下。

4.1 需求分析

首先，進行需求分析，具體過程如下：

（1）主機將顯示1個賽車視頻游戲。聲音應來自車載音響系統。

（2）游戲中的效果應由實車反映，例如：空調應根據游戲中的場景（即駛過火山）和虛擬車的速度調節氣流和溫度。游戲中的撞車事故應通過可逆安全帶拉緊器告知用戶。電動座椅調節器和按摩器可產生更多的觸覺效果。在虛擬比賽開始時，車內的環境照明應用作交通信號燈。

（3）虛擬車輛的水平動力學應根據當前方向盤角度得出。

（4）虛擬車輛的速度應從油門踏板和制動踏板得出。

（5）中指定的效果體驗應與視頻游戲中顯示的情況相匹配。

（6）游戲的最小幀速率應為30 fps。

（7）效果的延遲應等于或小于1幀持續時間（最小幀頻）。

還存在一些非功能性需求：

（1）此功能應部署在現有汽車上，無需對硬件進行任何修改。

（2）該功能不得損害機動車的安全。

（3）只有在車輛周圍環境允許安全操作時，該功能才有效。

4.2 起草軟件和系統架構

根據起草軟件和系統架構，構建面向服務的部分。

在“SuperTuxKart”應用程序的需求定義完成后，起草它的軟件和系統架構。本樣例中關注需求第2～4步，為此一共設計了3個步驟。

4.2.1 分解

實現“SuperTuxKart”應用程序的必要組件在某種程度上遵循面向服務、面向信號的方法。

面向服務的部分：在這部分中，“Super-TuxKart”應用程序被描述為1個服務消費者組件（客戶端）。消費的服務是噴油嘴服務（Nozzle）和轉向/踏板狀態服務（Steering/Pedal status）。其中，轉向/踏板狀態服務接口目的是定期接收踏板和轉向角的狀態，為“Super?TuxKart”應用程序提供施加的踏板壓力和轉向角；噴油嘴服務接口目的是實現對油泵執行器的控制，“Su?perTuxKart”應用程序根據游戲中的場景和虛擬車輛的速度以所需的噴嘴效果強度刺激界面。如圖8所示。

圖8 面向服務部分的架構

面向信號的部分：軟件架構的某些部分不會由服務接口實現，而是由經典的面向信號的方法。通常考慮與傳感器和執行器密切相關的軟件功能。對于該應用，必要的傳感器是踏板和轉向裝置。執行器則是由噴油嘴表示。為了將3個組件集成到我們的軟件架構草案中，引入了圖9中的信號接口。傳感器踏板和轉向裝置為轉向/踏板狀態服務提供接口；執行器噴油嘴為噴油嘴服務提供接口（圖9）。

圖9 信號接口

4.2.2 部署

接下來，用適合的網絡技術部署軟件架構。考慮3個通信網絡，包括：以太網，底盤/動力總成網絡，LIN網絡。

（1）第1個網絡是以太網拓撲。3個ECU通過1個中央以太網交換機互連。ECU 1是中央計算平臺。在ECU 1上，部署“SuperTuxKart”應用程序。對于踏板/轉向服務，底盤/傳動系統域的域控制器ECU2作為部署目標給出。以類似的方式，車身域的域控制器ECU3作為部署噴油嘴服務的目標。

（2）第2個底盤/傳動系統網絡：該網絡描述兩種基于CAN和FlexRay協議的系統總線拓撲結構連接到底盤/傳動系統域的域控制器。。

（3）第3個網絡描述了基于LIN協議的系統總線拓撲。在此網絡中，專注于油泵執行器，該執行器部署在專用的LIN組件上，并由噴油嘴服務控制。混合通信如圖10所示。

圖10 網絡混合通信

4.2.3 網絡通信

“Super-TuxKart”應用程序所需的網絡通信是以太網拓撲中面向服務的通信與CAN、FlexRay和LIN系統總線拓撲中的經典面向信號的通信相結合。

4.3 開發階段

應用程序的開發階段主要有3部分。

4.3.1 構建基礎組件

SOA中的主要基礎組件是API存儲庫，它是1個中央數據庫，包含詳細的有關服務及其功能和接口的信息。可以部署到車輛內計算平臺的應用程序可以使用這些服務為客戶提供額外的功能。

4.3.2 現有服務的使用

一旦應用程序確定了它的需求，它將通過API存儲庫并嘗試找到可以滿足所有要求的服務。理想情況下，存儲庫中的服務可以滿足所有要求。在這種情況下，應用程序可以使用API存儲庫提供的接口描述來設計軟件。由于面向服務架構的解耦性質，不需要對域控制器或它們背后的ECU進行修改。在“SuperTuxKart”示例中，應用程序設計將根據需求調整空調的氣流，并在API中尋找合適的服務存儲庫。他們會找到噴油嘴服務并集成此服務接口到應用程序中。

4.3.3 創建新服務

當API存儲庫中的服務不能滿足應用程序的需求時，需要聯系API的創建者來進行更新API存儲庫，以滿足開放的要求。由于這個擴展過程大大減慢了新應用程序的設計，因此API存儲庫設計時應提供盡可能多的功能。

4.4 空中更新

要通過空中更新汽車嵌入式系統的軟件，需要2部分：一部分由汽車制造商維護服務器，用于管理更新程序包；另一個負責接收，驗證和分發更新程序的客戶端，將文件更新到相應的ECU。

更新客戶端功能通常在車輛的中央網關平臺上實現，該平臺可直接訪問主機并代表通信總線之間的中央通信點。下載的更新包括1個或多個交叉編譯的二進制文件，準備在相應的ECU中進行刷新。中央網關的更新功能（或服務）負責檢查更新包，并將二進制文件分發到目標ECU。

該研究表明，使用現有服務可以較少的協調并提高開發速度。如果任何應用程序始終都可以使用現有服務，則可能會帶來安全方面的挑戰（即訪問行駛中的車輛的主動懸架系統）。因此，有必要對汽車SOA的訪問控制管理進行研究。

“分析和設計面向服務的架構”，“實現和部署面向服務的軟件”是有效開發SOA汽車軟件的關鍵環節。

來自李丹 汽車ECU開發公眾號