面向服務的開發模式已經是為大家熟知的下一代智能汽車開發模式了，由于SOA（Service Oriented Architecture）架構的靈活性和可擴展性，而這個恰恰與「軟件定義汽車」的思路不謀而合，因此可以說SOA的發展基礎是伴隨著軟件定義汽車的模式而產生的。為了更好的支持車控軟件的分布式部署與更新迭代，針對SOA的開發模式，需要在基于信號的服務通訊架構下進行開發，這種新架構下的開發模式本身也存在一定的難度。

SOA系統由一組服務組成，并且其中的總服務包可以依次使用其他的多個子服務，也可以根據需要使用一個或多個服務的應用程序，SOA通常以不同系統間隔表現出不同的功能特性。

為了支持復雜的應用程序，同時在處理分布式和計算資源分配方面提供最大的靈活性和可擴展性，業界均采用AP（Adaptive Platform）作為中間件進行SOA的設計開發，遵循面向服務的體系結構。

AP作為HPC（High Performance Controller）類型ECU的重要組成部分，可以統一管理下屬OS以及周邊資源，使得系統運行時的一切調度、狀態和資源消耗都處在一個可控的范圍內，以滿足車載安全性、確定性的要求。



此外，AP架構可以實現分布式計算，通過某種形式的消息傳遞進行有效通信。這種基于消息傳遞和基于通信的架構也可以實現快速和高帶寬的有效通信（例如以太網）。

本文將以系統設計和開發者的身份重點講解如何設計一個SOA架構，并重點說明整個過程中需要完成哪些具體的工作。

1.SOA開發流程設計

下一代自動駕駛系統將定義整車級SOA軟件架構，通過分層部署的方式，將全局變量的服務統籌提取出來（例如車速、時間、車輛狀態等），作為共用的軟件模塊提供服務，實現特定的基礎功能軟件接口統一，并可靈活部署。



大體上，AP（Adaptive Platform）的開發是一個“從上至下”的流程，其中跟SOA設計相關的有以下幾個重要步驟：

Step1：定義服務內容

此步驟實際上就是搭建了一個系統功能架構，從整車層面即是按照功能需求定義并劃分服務。對于SOA中的服務表示了一種獨立的功能單元，一個服務可以包含其他子服務單元，使用標準接口進行通訊，將內部信息封裝成一個黑盒子，實現子服務的重用性。

上層服務可以通過該標準接口調用下層服務封裝的子服務內容。同時，整體的服務內容可以被操控單元遠程訪問和獨立更改或更新。同時，對于SOA來說，需要通過服務編排來定義清楚服務之間的相互關系。

簡單地說服務對于智能駕駛汽車而言就是定義產品，對其中產品的能力進行描述，這里的產品能力我們稱之為PC（Product Capability）。

實現這種產品能力需要從下至上定義硬件抽象服務、平臺核心服務、域核心服務、應用程序服務。而每一個服務內容對應著一個或多個實現的軟件模塊，這里我們稱之為SWC（Software Capability）



產品能力(PC) 描述了系統所需的一些高級功能。區別于系統設計，PC是用來分配職責的，所以很清楚哪個SWC Module軟件模塊（如攝像頭識別模塊、雷達識別模塊、中央域控制器模塊）應該實現什么。

它們在功能設計時由功能負責人識別和請求。一些系統相關的PC也可以由系統架構師或模塊負責人直接識別，在模塊架構工作中映射PC時，模塊所有者還可以確定對更多 PC 的需求。

在確定并決定添加 PC 后，對應的軟件模塊擁有該 PC，模塊所有者負責將其實施到正確的版本，并在平臺的整個生命周期內維護/發展 PC。

?

Step2：定義服務接口

服務接口是一種通信內容定義，其目的在于將服務從功能架構過渡到軟件技術架構，且軟件模塊之間的關系需要被清晰的定義出來，過程中將服務內容封裝成相應的接口被實際調用。這種接口定義是獨立于通信協議的抽象實體，這種接口可以建立任何兩個服務間的通信能力，而使用合適的工具鏈可以由此生成基于特定協議的接口。

服務接口可分為方法（Method）、屬性（Property）、事件（Event）三種類型。以智能駕駛的一個子功能執行接口服務為例，假設需要獲取攝像頭傳感器探測的環境數據，而需要進行定義的服務接口中方法是要對傳感器的參數進行后融合，那么就需要其底層服務提供攝像頭處理的基礎函數（如ISP、深度學習函數、BEV函數等）。

而服務接口的屬性則是通過一定的方法操作（如get/set）來獲取該服務函數，這種服務屬性可以對上層調用的服務部分可見，底層服務有變動上層的調用方式也會隨之變動，這種變動所帶來的更新會由服務底層決定何時發送給上層調用它的服務單元。 服務接口定義完整后，開發人員可以根據該接口定義對其中的函數進行定義開發了。

Step3：配置服務映射關系

此過程會建立軟硬件之間的映射關系，實現從抽象的服務定義到軟件層面的推導，從而方便實現軟件驅動或調用硬件實現單元，這種結果是實現服務與中間件或底層硬件ECU之間的映射關系。

從整個SOA的架構模型中我們知道服務需要從通用服務平臺開始進行底層驅動，然后對上層傳感器執行器的控制管理進行驅動。

由于AP直接支持服務接口，可以直接面向上層應用層，CP仍然是對常用的底層應用服務的驅動映射，因此，兩層驅動分別對應著經典的CP Autosar中間件調用和AP Autosar模式。

Step4：通訊協議設計

智能網聯汽車的SOA架構設計需要強大的環境感知、信息處理、實施決策、控制能力可以把智能交通、地圖、定位、通訊、云、大數據等進行系統集成，故車端與云端、車輛與車輛之間、車輛內部的各個ECU之間通信的速率和數據量都比傳統汽車高出幾個數量級，這些需要由多種復雜的硬件、軟件和高速通信總線共同實現，并在很大程度上決定智能汽車的功能實現和擴展的可靠性。

車載以太網能夠很好的解決大數據量的信息交互，整個通信協議的定義包括虛擬以太網VLAN，以太網交換機Switch，套接字Socket，基于IP的可擴展面向服務的中間件SOME/IP，SD等。而基于AVB的下一代協議TSN（時間敏感網絡）可以提供非常優秀的實時性。

以太網通訊設計過程包含對服務實例進行通訊協議相關的信息配置。由于SOA架構中包含多個應用實體之間的多通路通信過程，且這些通信通常是網狀通信，因此需要在各個實體節點之間建立中間路由、轉化等。

區別于傳統總線（Can/Lin），在軟件架構設計過程中，開發人員需要設計具體的服務類型、服務ID、服務數據類型、服務角色等。

2.SOA架構設計流程

SOA的邏輯架構內容需要根據分層架構策略分配給一層的多個模塊。這些層也被分成幾個功能區，使用Enterprise Architect進行架構模型管理是SOA模塊架構設計的基礎，如下圖表示了典型的SOA系統的架構設計模型。



區別于傳統Can總線面向信號的設計思路，在以太網設計過程中，開發人員需要在邏輯層面將功能抽象為服務的方式進行架構設計。

如上圖，從下至上包含了SOA基礎服務管理、硬件I/O控制管理、系統功能控制管理、單元域功能控制管理、整車功能控制管理、云端控制管理、人機交互管理。

SOA基礎服務管理：該模塊主要是對整車軟件模塊的基礎功能（例如診斷管理、驅動管理、存儲、日志記錄、OTA等）進行分解并統一管理。

SOA硬件I/O控制管理：該模塊主要涉及對SOA中的傳感器&執行器進行的相應管理，包括定義傳感器輸入源硬件（Camera、Radar、Lidar、Uss、GPS等），定義執行器輸入輸出源硬件（方向盤、制動踏板、轉向電機、車門車窗、電源電池、藍牙wifi等）。

傳感器執行器層中的所有模塊都必須包含其各自設備的功能設備驅動程序 (FDD)。設備管理模塊將包含所有 ECU 使用的通用 ECU 設備驅動程序 (EDD)。

SOA系統功能控制管理：以SOA服務所需要實現的系統內部作為劃分區間，將對特定功能進行控制的特殊功能服務，例如比如ADAS系統將傳感器輸入的信息進行統一初級信息處理（如ISP、加串解串、原始點云處理）。

單元域功能控制管理：對系統內部功能進行協調的功能服務，如ADAS系統中利用深度學習進行環境信息檢測、傳感器信息融合，同時在動力學模型中進行車輛運動控制、車身姿態控制。

整車功能控制管理：對單個整車內的系統進行調度的功能服務，包括協調運動控制單元、動力系統、車輛安全相關的能力，特別是車身安全上需要充分考慮智能網聯車輛的功能安全設置相應的軟硬件安全門檻。

云端服務管理：云端管理可以是以總監控臺管理的該車輛及其周邊車輛、基礎設施相關的功能服務，例如網絡安全管理、云端計算服務、軟件升級等協同控制。

基于以太網的SOA架構設計，需要開發人員明確4個問題： 服務提供者（Provider）+ 服務·類型（Service）+ 客戶端（Consumer） + 服務接口（Service Interface）。

一般的，對于SOA系統架構設計過程中可使用面向對象的設計工具進行設計。

如前所述對于服務來說我們需要首先進行產品能力PC定義，對應于該服務模塊需要設計相應的服務軟件模塊組建SWC。

其中服務組件包和軟件組件包的設計流程分別如下：



如上過程的設計和配置完成之后可采用一些現有的SOA開發工具PREEvision生成Arxml文件。該文件區別于CAN/CANFD/LIN總線的DBC和LDF等數據文件，Arxml包含了SOA架構設計所有相關的服務、屬性以及服務的軟硬件實現方式，成為了以太網總線開發的通用標準數據接口。

SOA架構主要優勢是可以很大程度上實現軟硬解耦，通過軟件升級OTA可以更加方便靈活的實現服務實體有效部署在任意的域控制器上，而且可以在售出車輛上調整部署策略。

同時，SOA的衍生功能是可以在汽車功能安全方面實現有效的冗余部署。例如，對于安全性要求比較高的智能駕駛功能可以實現雙重制動冗余配置，同時在車端布置雙重中央域控制服務，確保當一個域控制器失效時，那么另外一個域控制器上的備用服務實例立刻啟動，重新與服務使用者建立連接，以保證功能的正常運轉，借此實現冗余機制。

對于SOA來說，是需要在AP Autosar流程下設計從服務定義到服務實例化的整個過程，為了實現在算法和軟硬件調用中的有效通信，就需要設計有效的通信協議，對于SOA來說基礎的通信協議除了Can以外，最基本的就是以太網的通訊設計。

審核編輯：劉清