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

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

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

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



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

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

1.SOA開發(fā)流程設計

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



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

Step1：定義服務內(nèi)容

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

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

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

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



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

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

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

?

Step2：定義服務接口

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

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

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

Step3：配置服務映射關系

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

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

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

Step4：通訊協(xié)議設計

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

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

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

區(qū)別于傳統(tǒng)總線（Can/Lin），在軟件架構設計過程中，開發(fā)人員需要設計具體的服務類型、服務ID、服務數(shù)據(jù)類型、服務角色等。

2.SOA架構設計流程

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



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

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

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

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

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

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

單元域功能控制管理：對系統(tǒng)內(nèi)部功能進行協(xié)調(diào)的功能服務，如ADAS系統(tǒng)中利用深度學習進行環(huán)境信息檢測、傳感器信息融合，同時在動力學模型中進行車輛運動控制、車身姿態(tài)控制。

整車功能控制管理：對單個整車內(nèi)的系統(tǒng)進行調(diào)度的功能服務，包括協(xié)調(diào)運動控制單元、動力系統(tǒng)、車輛安全相關的能力，特別是車身安全上需要充分考慮智能網(wǎng)聯(lián)車輛的功能安全設置相應的軟硬件安全門檻。

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

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

一般的，對于SOA系統(tǒng)架構設計過程中可使用面向?qū)ο蟮脑O計工具進行設計。

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

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



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

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

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

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

審核編輯：劉清