來源：智能汽車設計

近年來，汽車“新四化”（智能化、網(wǎng)聯(lián)化、電動化、共享化）的快速推進，給汽車行業(yè)帶來了新的技術變革，汽車的功能變得越來越復雜，尤其是智能座艙、智能駕駛、智能底盤的出現(xiàn)，促使汽車電子電氣架構(gòu)也相應地發(fā)生變革。

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

01.

SOA簡介

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

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

SOA在IT行業(yè)中已經(jīng)使用了多年，旨在描述和構(gòu)建分布式系統(tǒng)。同時，面向服務的設計在汽車工業(yè)中也變得極為重要。

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

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

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

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

02.

硬SOA主要模塊及功能

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

圖2 端到端面向服務的架構(gòu)

在傳統(tǒng)的車載網(wǎng)絡中：

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

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

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

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

2.1 SOA適配器

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

（2）在以太網(wǎng)方面，服務是在SOME/IP協(xié)議之上提供的。

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

（4）SOA適配器提供的服務可以動態(tài)更改。

2.2 SOA網(wǎng)關

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

（2）必要時轉(zhuǎn)換協(xié)議并翻譯。

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

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

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

2.3 SD代理

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

（2）分布式SD方法的安全和流量問題可以由集中式SD處理。每個服務只能由允許的ECU查找和訂閱?？梢杂行У乇O(jiān)視服務可用性和搜索/訂閱嘗試。

2.4 服務路由

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

03.

汽車SOA應用現(xiàn)狀

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

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

圖3 SOA汽車分層模型

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

元服務是最小單元。包括汽車的傳感器和執(zhí)行器等的基本接口?；A服務是中間層服務，在利用元服務的基礎上，可自定義汽車業(yè)務模塊，比如利用自車狀態(tài)服務和雷達傳感器等服務，組合出環(huán)境信息融合的服務。應用服務是最頂層的服務，可以訪問和調(diào)用基礎服務以幫助其解決業(yè)務問題。

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

圖4 BMW下一代E/E架構(gòu)

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

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

在該架構(gòu)中還強調(diào)，SOA是數(shù)字化的關鍵，如圖6所示，該架構(gòu)的優(yōu)點如下：

圖6 面向服務通信架構(gòu)

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

（2）使用服務發(fā)現(xiàn)和發(fā)布/訂閱進行動態(tài)綁定；

（3）數(shù)據(jù)表示主要基于REST（表述性狀態(tài)傳遞）過渡到統(tǒng)一接口、無狀態(tài)、關注點分離；

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

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

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

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

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

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

04.

汽車SOA開發(fā)流程

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

圖7 汽車的SOA開發(fā)流程

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

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

4.1 需求分析

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

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

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

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

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

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

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

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

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

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

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

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

4.2 起草軟件和系統(tǒng)架構(gòu)

根據(jù)起草軟件和系統(tǒng)架構(gòu)，構(gòu)建面向服務的部分。

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

4.2.1 分解

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

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

圖8 面向服務部分的架構(gòu)

面向信號的部分：軟件架構(gòu)的某些部分不會由服務接口實現(xiàn)，而是由經(jīng)典的面向信號的方法。通?？紤]與傳感器和執(zhí)行器密切相關的軟件功能。對于該應用，必要的傳感器是踏板和轉(zhuǎn)向裝置。執(zhí)行器則是由噴油嘴表示。為了將3個組件集成到我們的軟件架構(gòu)草案中，引入了圖9中的信號接口。傳感器踏板和轉(zhuǎn)向裝置為轉(zhuǎn)向/踏板狀態(tài)服務提供接口；執(zhí)行器噴油嘴為噴油嘴服務提供接口（圖9）。

圖9 信號接口

4.2.2 部署

接下來，用適合的網(wǎng)絡技術部署軟件架構(gòu)?？紤]3個通信網(wǎng)絡，包括：以太網(wǎng)，底盤/動力總成網(wǎng)絡，LIN網(wǎng)絡。

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

（2）第2個底盤/傳動系統(tǒng)網(wǎng)絡：該網(wǎng)絡描述兩種基于CAN和FlexRay協(xié)議的系統(tǒng)總線拓撲結(jié)構(gòu)連接到底盤/傳動系統(tǒng)域的域控制器。。

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

圖10 網(wǎng)絡混合通信

4.2.3 網(wǎng)絡通信

“Super-TuxKart”應用程序所需的網(wǎng)絡通信是以太網(wǎng)拓撲中面向服務的通信與CAN、FlexRay和LIN系統(tǒng)總線拓撲中的經(jīng)典面向信號的通信相結(jié)合。

4.3 開發(fā)階段

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

4.3.1 構(gòu)建基礎組件

SOA中的主要基礎組件是API存儲庫，它是1個中央數(shù)據(jù)庫，包含詳細的有關服務及其功能和接口的信息?？梢圆渴鸬杰囕v內(nèi)計算平臺的應用程序可以使用這些服務為客戶提供額外的功能。

4.3.2 現(xiàn)有服務的使用

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

4.3.3 創(chuàng)建新服務

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

4.4 空中更新

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

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

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

“分析和設計面向服務的架構(gòu)”，“實現(xiàn)和部署面向服務的軟件”是有效開發(fā)SOA汽車軟件的關鍵環(huán)節(jié)。

來自李丹 汽車ECU開發(fā)公眾號