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

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

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

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



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

本文將以系統(tǒng)設(shè)計(jì)和開(kāi)發(fā)者的身份重點(diǎn)講解如何設(shè)計(jì)一個(gè)SOA架構(gòu)，并重點(diǎn)說(shuō)明整個(gè)過(guò)程中需要完成哪些具體的工作。

1.SOA開(kāi)發(fā)流程設(shè)計(jì)

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



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

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

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

上層服務(wù)可以通過(guò)該標(biāo)準(zhǔn)接口調(diào)用下層服務(wù)封裝的子服務(wù)內(nèi)容。同時(shí)，整體的服務(wù)內(nèi)容可以被操控單元遠(yuǎn)程訪問(wèn)和獨(dú)立更改或更新。同時(shí)，對(duì)于SOA來(lái)說(shuō)，需要通過(guò)服務(wù)編排來(lái)定義清楚服務(wù)之間的相互關(guān)系。

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

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



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

它們?cè)诠δ茉O(shè)計(jì)時(shí)由功能負(fù)責(zé)人識(shí)別和請(qǐng)求。一些系統(tǒng)相關(guān)的PC也可以由系統(tǒng)架構(gòu)師或模塊負(fù)責(zé)人直接識(shí)別，在模塊架構(gòu)工作中映射PC時(shí)，模塊所有者還可以確定對(duì)更多 PC 的需求。

在確定并決定添加 PC 后，對(duì)應(yīng)的軟件模塊擁有該 PC，模塊所有者負(fù)責(zé)將其實(shí)施到正確的版本，并在平臺(tái)的整個(gè)生命周期內(nèi)維護(hù)/發(fā)展 PC。

?

Step2：定義服務(wù)接口

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

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

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

Step3：配置服務(wù)映射關(guān)系

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

從整個(gè)SOA的架構(gòu)模型中我們知道服務(wù)需要從通用服務(wù)平臺(tái)開(kāi)始進(jìn)行底層驅(qū)動(dòng)，然后對(duì)上層傳感器執(zhí)行器的控制管理進(jìn)行驅(qū)動(dòng)。

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

Step4：通訊協(xié)議設(shè)計(jì)

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

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

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

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

2.SOA架構(gòu)設(shè)計(jì)流程

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



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

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

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

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

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

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

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

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

云端服務(wù)管理：云端管理可以是以總監(jiān)控臺(tái)管理的該車(chē)輛及其周邊車(chē)輛、基礎(chǔ)設(shè)施相關(guān)的功能服務(wù)，例如網(wǎng)絡(luò)安全管理、云端計(jì)算服務(wù)、軟件升級(jí)等協(xié)同控制。

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

一般的，對(duì)于SOA系統(tǒng)架構(gòu)設(shè)計(jì)過(guò)程中可使用面向?qū)ο蟮脑O(shè)計(jì)工具進(jìn)行設(shè)計(jì)。

如前所述對(duì)于服務(wù)來(lái)說(shuō)我們需要首先進(jìn)行產(chǎn)品能力PC定義，對(duì)應(yīng)于該服務(wù)模塊需要設(shè)計(jì)相應(yīng)的服務(wù)軟件模塊組建SWC。

其中服務(wù)組件包和軟件組件包的設(shè)計(jì)流程分別如下：



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

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

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

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

審核編輯：劉清