Aspice作為車(chē)載軟件過(guò)程中，關(guān)注于功能場(chǎng)景定義（function definition）、架構(gòu)定義（System Architecture）、系統(tǒng)設(shè)計(jì)（System Design）、產(chǎn)品設(shè)計(jì)（Product Design）幾個(gè)大的方面。

而下一代智能駕駛系統(tǒng)需要面向服務(wù)進(jìn)行相應(yīng)的功能設(shè)計(jì)和開(kāi)發(fā)，實(shí)現(xiàn)軟硬件解耦。這種開(kāi)發(fā)方式將對(duì)整個(gè)智能駕駛來(lái)說(shuō)產(chǎn)生顛覆性的影響，比如高性能計(jì)算平臺(tái)HPC包含多核異構(gòu)處理模式，通過(guò)Hypervisor技術(shù)實(shí)現(xiàn)對(duì)硬件抽象，Inter-Core通信技術(shù)使多篇和單片多核實(shí)現(xiàn)信息互通，

計(jì)算單元趨于“云計(jì)算 中央計(jì)算 邊緣計(jì)算結(jié)合等多個(gè)方面的變革。如上這些設(shè)計(jì)原則更多的是基于SOA的架構(gòu)進(jìn)行的，這就大大增強(qiáng)了平臺(tái)的可拓展性，可移植性。

當(dāng)前更多的主機(jī)廠(chǎng)選擇在智能駕駛中采用SOA的開(kāi)發(fā)模式，這可以更加快速的實(shí)現(xiàn)從底層、中間層到應(yīng)用層的軟件開(kāi)發(fā)，且相對(duì)較多的軟件只要接口定義得當(dāng)，就可以實(shí)現(xiàn)軟件本體和功能的遷移，同時(shí)可以大大的降低開(kāi)發(fā)周期和成本。

對(duì)于SOA的設(shè)計(jì)過(guò)程來(lái)講，其服務(wù)設(shè)計(jì)原則包括重用、抽象、封裝、協(xié)調(diào)在內(nèi)的多個(gè)層面。比如對(duì)于智能駕駛功能開(kāi)發(fā)而言，如果需要多次用到某一邏輯元素比如車(chē)道線(xiàn)等環(huán)境信息，則應(yīng)該將車(chē)道線(xiàn)檢測(cè)模塊創(chuàng)建為重用（比如封裝到Building Block中），則對(duì)該車(chē)道線(xiàn)檢測(cè)源（如不同方位的攝像頭）進(jìn)行調(diào)整，則由此對(duì)車(chē)道線(xiàn)檢測(cè)產(chǎn)生的任何更新改變都會(huì)對(duì)后續(xù)級(jí)聯(lián)的應(yīng)用實(shí)例產(chǎn)生影響。

而上層應(yīng)用軟件端對(duì)于底層的如何獲取車(chē)道線(xiàn)，如何處理的細(xì)節(jié)也不需要深究，這就是實(shí)現(xiàn)模塊抽象的整個(gè)過(guò)程。抽象后的邏輯功能需要保證其體系相類(lèi)似的功能需要集成到一起，比如自動(dòng)換道功能的控制邏輯可以在自動(dòng)激活后調(diào)用觸發(fā)換道相關(guān)的規(guī)劃控制模塊進(jìn)行車(chē)控。

因此，觸發(fā)換道的規(guī)劃決策控制邏輯單元可以完全應(yīng)用于自動(dòng)換道模塊。系統(tǒng)工程師只需要保證定義的接口適用于觸發(fā)換道已經(jīng)發(fā)布或預(yù)定的數(shù)據(jù)流即可。對(duì)于自動(dòng)駕駛域控單元負(fù)責(zé)人而言，應(yīng)該保持邏輯系統(tǒng)結(jié)構(gòu)之間的協(xié)調(diào)和重用，包含對(duì)公共池中的元素排布，對(duì)局部域單元中的邏輯構(gòu)造，跨域之間的資源或模塊調(diào)度等。

本文將以智能駕駛系統(tǒng)開(kāi)發(fā)設(shè)計(jì)實(shí)例來(lái)講解和分析相應(yīng)的SOA為基礎(chǔ)下的架構(gòu)設(shè)計(jì)和軟件開(kāi)發(fā)。

面向ASPICE流程的SOA軟件架構(gòu)流程

適用于SOA架構(gòu)的ASPICE軟件開(kāi)發(fā)過(guò)程也是在敏捷開(kāi)發(fā)的模式下進(jìn)行的系統(tǒng)開(kāi)發(fā)流程。從智能駕駛功能開(kāi)發(fā)層面上講，基于SOA架構(gòu)開(kāi)發(fā)模式包括了系統(tǒng)功能、系統(tǒng)架構(gòu)、軟件功能、軟件架構(gòu)幾個(gè)方面。

其中分別由分別稱(chēng)之為產(chǎn)品負(fù)責(zé)人Product Owner、功能負(fù)責(zé)人Function Owner、架構(gòu)負(fù)責(zé)人Architect Owner、子模塊負(fù)責(zé)人Module Owner的幾個(gè)角色共同承擔(dān)。功能設(shè)計(jì)是搭建功能架構(gòu)圖和依據(jù)產(chǎn)品工程師輸入的產(chǎn)品需求定義進(jìn)行功能分解定義，架構(gòu)負(fù)責(zé)人則根據(jù)整車(chē)架構(gòu)及功能負(fù)責(zé)人輸入的要素信息制定合適的軟硬件架構(gòu)。

這里需要說(shuō)明的是很多情況下，功能負(fù)責(zé)人和架構(gòu)負(fù)責(zé)人往往是同一個(gè)人。模塊負(fù)責(zé)人則是根據(jù)功能定義編制相應(yīng)的系統(tǒng)軟硬件模塊、零部件軟硬件模塊以實(shí)現(xiàn)上層定義的功能需求。各負(fù)責(zé)人之間的角色定位將在如下分層流程圖中進(jìn)行詳細(xì)說(shuō)明。

這里我們僅關(guān)注V模型中的與SOA相關(guān)度較高的設(shè)計(jì)開(kāi)發(fā)部分，測(cè)試驗(yàn)證部分不在本文中進(jìn)行詳述。

其中，各階段的開(kāi)發(fā)輸出功能過(guò)程如下：

1、項(xiàng)目功能定義

項(xiàng)目功能元素（function element）包含與頂層設(shè)計(jì)相關(guān)的不同屬性，例如車(chē)輛類(lèi)型、預(yù)期市場(chǎng)、項(xiàng)目功能以及功能發(fā)布計(jì)劃等。在實(shí)際開(kāi)發(fā)中，這類(lèi)輸出一般是產(chǎn)品策劃部門(mén)或市場(chǎng)部輸出的整車(chē)功能開(kāi)發(fā)需求或整車(chē)裝備需求。

本文將以開(kāi)發(fā)智能駕駛系統(tǒng)功能中的點(diǎn)對(duì)點(diǎn)自動(dòng)駕駛NOP為例進(jìn)行詳細(xì)的分析說(shuō)明基于SOA的架構(gòu)設(shè)計(jì)是如何應(yīng)用于自動(dòng)駕駛系統(tǒng)開(kāi)發(fā)的。

如下圖舉例中，表示了實(shí)現(xiàn)下一代自動(dòng)駕駛系統(tǒng)NOP場(chǎng)景定義需求。

2、系統(tǒng)架構(gòu)設(shè)計(jì)階段（System Architecture Design）

這個(gè)階段涉及產(chǎn)品能力定義及模塊定義。用于描述智能汽車(chē)中的用戶(hù)功能，通過(guò)定義相應(yīng)的函數(shù)來(lái)指出使用哪些子系統(tǒng)或者零部件具備相應(yīng)的產(chǎn)品能力（Product Capabilities，PC）并對(duì)其進(jìn)行相應(yīng)的實(shí)例化來(lái)實(shí)現(xiàn)此功能。

（1）產(chǎn)品能力PC：

這種稱(chēng)之為產(chǎn)品能力的模塊主要是用于定義想要實(shí)現(xiàn)該功能模塊的傳感器或執(zhí)行器所具備的能力，這也是位于各個(gè)時(shí)序圖上各個(gè)節(jié)點(diǎn)的能力描述。通常，該產(chǎn)品能力的定義主要由產(chǎn)品工程師牽頭，功能所有者、架構(gòu)師和模塊所有者/設(shè)計(jì)者的跨職能小組共同決定。

（2）產(chǎn)品能力實(shí)例化PC Instance：

產(chǎn)品能力可以被認(rèn)為是一種高級(jí)服務(wù)，一些需要在汽車(chē)中實(shí)現(xiàn)的功能，但它沒(méi)有描述應(yīng)該如何實(shí)現(xiàn)。產(chǎn)品能力實(shí)例是 PC 的簡(jiǎn)單實(shí)例化，可以在平臺(tái)中擁有 PC 的不同變體。如果需要 PC 的不同變體實(shí)例以及在何處使用不同的實(shí)例，則模塊所有者負(fù)責(zé)。

系統(tǒng)架構(gòu)師負(fù)責(zé)定義系統(tǒng)中定義了產(chǎn)品能力PC的不同類(lèi)型，并確定哪些 PC 需要由跨職能團(tuán)隊(duì)才能完成。通過(guò)將當(dāng)前定義的 PC 和其他的需要PC 建立依賴(lài)關(guān)系，我們可以建模一個(gè)完整的功能架構(gòu)，該功能層級(jí)的架構(gòu)無(wú)需研究實(shí)際的實(shí)現(xiàn)機(jī)制。這對(duì)于定義需要哪些高級(jí)服務(wù) (PC) 以及分配誰(shuí)（哪個(gè)模塊）負(fù)責(zé)實(shí)施每個(gè) PC 非常有幫助。

如上過(guò)程一般是通過(guò)各種圖表（包含用例圖、序列圖、活動(dòng)圖等）來(lái)完成的。如下圖表示了一種活動(dòng)圖所示意的系統(tǒng)交互方式。

由于在定義過(guò)程中還建立了與功能之間的連接，因此我們可以使用該模塊來(lái)規(guī)劃需要實(shí)現(xiàn) PC 的順序，以便我們?cè)诿總€(gè)版本的集成階段開(kāi)發(fā)出正確的功能。

（3）模塊及實(shí)例Module Instance：

模塊是整個(gè)模型甚至整個(gè)組織中非常核心的元素。從SOA的架構(gòu)設(shè)計(jì)上講，每個(gè)設(shè)計(jì)的 PC 都被分配到一個(gè)并且只有一個(gè)模塊（或者稱(chēng)之為函數(shù)），該模塊負(fù)責(zé)實(shí)現(xiàn) PC，但在整個(gè)平臺(tái)生命周期內(nèi)維護(hù)和發(fā)展 PC，規(guī)劃 PC 的演進(jìn)步驟，提供路線(xiàn)圖等。

PC 定義的功能在 Component 中實(shí)現(xiàn)，模塊實(shí)例可以確保在平臺(tái)中擁有模塊的不同變體。系統(tǒng)架構(gòu)師負(fù)責(zé)定義系統(tǒng)中存在哪些模塊，但模塊所有者負(fù)責(zé)領(lǐng)導(dǎo)模塊內(nèi)的工作，并負(fù)責(zé)維護(hù)和發(fā)展模塊。模塊所有者還負(fù)責(zé)是否需要模塊的不同變體實(shí)例以及在何處使用等。

同時(shí)，模塊中的相關(guān)參數(shù)是在對(duì)應(yīng)構(gòu)建的系統(tǒng)功能規(guī)范中實(shí)現(xiàn)定義的。

3、軟件架構(gòu)設(shè)計(jì)階段

軟件組件Software Component：

組件是模塊的實(shí)際設(shè)計(jì)和實(shí)現(xiàn)。組件可以是軟件或硬件組件，但在SOA的軟件架構(gòu)中，我們將主要處理軟件組件，組件定義了模塊需要哪些接口以及提供哪些接口。其中接口將包括SOA架構(gòu)所要求的服務(wù)、屬性和事件。在硬件組件上，接口可以是螺孔或電線(xiàn)連接器。

軟件包Software Package：

軟件包是將部署到特定運(yùn)行環(huán)境時(shí)的所有軟件組件、清單文件等的集合。

為了實(shí)現(xiàn)面向SOA的架構(gòu)設(shè)計(jì)和開(kāi)發(fā)過(guò)程，需要重點(diǎn)定義。

4、底層驅(qū)動(dòng)設(shè)計(jì)階段

中央控制單元ECU/處理器Processor/虛擬機(jī)Virtual Machine：

一個(gè) ECU 可以由一個(gè)或多個(gè)處理器組成，一個(gè)處理器可以運(yùn)行一個(gè)或多個(gè)虛擬機(jī)。不必對(duì)每個(gè)組件進(jìn)行建模，例如，如果 ECU 僅包含一個(gè)處理器，則僅對(duì) ECU 進(jìn)行建模就足夠了?？梢詫⒏鱾€(gè)軟件包部署到如上運(yùn)行時(shí)環(huán)境中的任何一個(gè)。

網(wǎng)絡(luò)及連接器Network Connector：

定義網(wǎng)絡(luò)以及連接到它的運(yùn)行時(shí)環(huán)境。運(yùn)行時(shí)環(huán)境可以由一個(gè)或多個(gè)網(wǎng)絡(luò)連接組成，這些網(wǎng)絡(luò)連接可以是 CAN、CAN FD、以太網(wǎng)、VLAN、LIN 等。

嚴(yán)格說(shuō)來(lái)，底層驅(qū)動(dòng)設(shè)計(jì)應(yīng)該屬于軟件架構(gòu)設(shè)計(jì)的其中一個(gè)部分，面向底層軟件設(shè)計(jì)部分，通常與頂層軟件開(kāi)發(fā)團(tuán)隊(duì)不是一伙人，且具有較大區(qū)別，該開(kāi)發(fā)過(guò)程由頂層軟件設(shè)計(jì)人員對(duì)底層軟件開(kāi)發(fā)人員單獨(dú)提出需求及建議。

一般的需求包括平臺(tái)軟件總體架構(gòu)及對(duì)相關(guān)Autosar標(biāo)準(zhǔn)組件和復(fù)雜驅(qū)動(dòng)的調(diào)度框架設(shè)計(jì)、開(kāi)發(fā)和集成要求；內(nèi)存、非易失性存儲(chǔ)、任務(wù)、中斷等等資源和權(quán)限分配；上下電流程和管理的設(shè)計(jì)；系統(tǒng)運(yùn)行狀態(tài)監(jiān)控、異常處理等功能的設(shè)計(jì)等方面。

基于SOA架構(gòu)模型設(shè)計(jì)分工

基于SOA軟件模型架構(gòu)的設(shè)計(jì)過(guò)程實(shí)際是在研究如何在開(kāi)發(fā)流程中進(jìn)行軟硬件解耦。包括構(gòu)建不同的分層來(lái)隔離硬件與軟件功能和服務(wù)。例如，將自動(dòng)駕駛相關(guān)的傳感器和執(zhí)行器邏輯與應(yīng)用程序邏輯分開(kāi)，則能夠在中央系統(tǒng)中分配應(yīng)用程序，同時(shí)保持傳感器/執(zhí)行器盡可能的具體。

程序之間可以利用SOA的服務(wù)模式實(shí)現(xiàn)軟件包的調(diào)用，傳感器和執(zhí)行器也可以作為組件或模組來(lái)進(jìn)行邊緣采購(gòu)，性能則是集中管控，中央系統(tǒng)可以將戰(zhàn)略軟件進(jìn)行分開(kāi)，這就更容易進(jìn)行軟件模塊移植和處理。這一過(guò)程實(shí)際就是在提高上層應(yīng)用層軟件關(guān)鍵功能的復(fù)用性，瞄準(zhǔn)軟硬件功能與邏輯控制分離。這里需要說(shuō)明的是，軟硬件之間的協(xié)調(diào)和調(diào)度是通過(guò)中間件來(lái)實(shí)現(xiàn)。

從如下圖所示，SOA的架構(gòu)從下至上分別底層驅(qū)動(dòng)功能管理，物理層功能管理，車(chē)輛控制服務(wù)，面向用戶(hù)的應(yīng)用服務(wù)，云端遠(yuǎn)程管理。

底層驅(qū)動(dòng)功能管理：用于實(shí)現(xiàn)包含診斷、日志記錄、存儲(chǔ)管理、驅(qū)動(dòng)管理等相關(guān)功能。

物理層功能管理：主要是設(shè)置I/O接口將原始傳感器數(shù)據(jù)進(jìn)行輸入，同時(shí)也是執(zhí)行到車(chē)端的控制單元（如電機(jī)、制動(dòng)卡鉗等）；

車(chē)輛控制服務(wù)：車(chē)端控制包含上層ADAS發(fā)送的執(zhí)行指令到控制執(zhí)行器執(zhí)行該指令的相應(yīng)ECU（如控制電機(jī)的VCU、HCU或ESP），該車(chē)輛控制服務(wù)是綜合考慮了車(chē)身穩(wěn)定性與動(dòng)力學(xué)反饋模型得出的。

應(yīng)用層服務(wù)：該層服務(wù)就是智能駕駛面向用戶(hù)級(jí)別的頂層開(kāi)發(fā)功能，主要用于實(shí)現(xiàn)包含傳統(tǒng)的智能駕駛功能，比如HWP、NOP、TJP以及ALC等。

云端管理服務(wù)：該層服務(wù)主要是面向遠(yuǎn)程監(jiān)控，遠(yuǎn)程控制，大數(shù)據(jù)存儲(chǔ)等特殊場(chǎng)景。通常該服務(wù)需要基于4G/5G網(wǎng)絡(luò)進(jìn)行遠(yuǎn)程連接。

人機(jī)交互管理功能：人機(jī)交互管理功能一般是針對(duì)不同的車(chē)型呈現(xiàn)出不同的模式的，因此，這一塊一般是獨(dú)立于SOA的功能架構(gòu)。SOA通常只涉及底層對(duì)車(chē)輛控制邏輯，對(duì)于平臺(tái)化車(chē)型功能開(kāi)發(fā)來(lái)說(shuō)，這一塊是無(wú)法為用戶(hù)所感知的。

而HMI的顯示設(shè)置則是用戶(hù)能夠真切感知和控制的，因此，不同車(chē)型肯定是有極大的不同之處。因此，從協(xié)議上分析不難看出，SOA內(nèi)部的網(wǎng)絡(luò)架構(gòu)一般是基于以太網(wǎng)為基礎(chǔ)的交互方式，采用Some/ip的協(xié)議進(jìn)行通信控制。而如果在平臺(tái)化車(chē)型的開(kāi)發(fā)過(guò)程中，HMI這一塊的通常仍然按照原始CAN/CANFD信號(hào)模式的通信協(xié)議進(jìn)行交互控制。

這么做的原因是，智能駕駛的HMI行為比核心應(yīng)用功能更容易改變，特別是在不同車(chē)型開(kāi)發(fā)后期通常會(huì)選擇不同的顯示和交互方式。同時(shí)，由于開(kāi)發(fā)核心軟件和HMI設(shè)計(jì)需要不同的能力技能，因此，將HMI功能與其他應(yīng)用層軟件功能分離，為了實(shí)現(xiàn)這一點(diǎn)，一般需要使用Model-View-Controller，用戶(hù)輸入由Controller處理，Controller用于解釋用戶(hù)的意圖并操作模型。

SOA服務(wù)實(shí)現(xiàn)過(guò)程

隨著車(chē)載以太網(wǎng)技術(shù)的日益成熟，國(guó)內(nèi)大部分OEM都已經(jīng)著手SOA的設(shè)計(jì)工作，并將以太網(wǎng)通信矩陣生成ARXML文件，用于項(xiàng)目前期的網(wǎng)絡(luò)行為仿真和后期測(cè)試驗(yàn)證。

對(duì)于已經(jīng)完成架構(gòu)搭建的SOA來(lái)講，需要將其建模后的成品導(dǎo)入到軟件團(tuán)隊(duì)進(jìn)行服務(wù)實(shí)現(xiàn)。其過(guò)程包含：以Some/Ip協(xié)議導(dǎo)入Service ARXML，導(dǎo)入后新增ETH、TCP/IP、Some/IP模塊（BSW工程），建立與Service Handler SWC（應(yīng)用層）中Port Interface連接，

為所有Service Handler SWC增加可運(yùn)行時(shí)間，定義Windows Service Handler SWC 和Feature SWC到Simulink/Stateflow。通過(guò)符合Autosar的ARXML和Simulink進(jìn)行交互，將由軟件開(kāi)發(fā)工程師繼續(xù)進(jìn)行算法設(shè)計(jì)并自動(dòng)生成代碼。

總 結(jié)

本文從SOA軟件架構(gòu)模型的構(gòu)建角度出發(fā)講解了相應(yīng)實(shí)現(xiàn)過(guò)程原理，利用了基于模型、集成式的可視化開(kāi)發(fā)工具PREEvision進(jìn)行了智能汽車(chē)行業(yè)及相關(guān)領(lǐng)域E/E架構(gòu)開(kāi)發(fā)并支持以太網(wǎng)SOA的架構(gòu)開(kāi)發(fā)設(shè)計(jì)，

本文以介紹SOA架構(gòu)設(shè)計(jì)模型為基礎(chǔ)展示了如何在Enterprise Architect中進(jìn)行SOA建模。同時(shí)，以系統(tǒng)工程師的角度說(shuō)明如何利用Enterprise Architect構(gòu)建SOA系統(tǒng)及軟件架構(gòu)設(shè)計(jì)、功能設(shè)計(jì)Function Design 和模塊設(shè)計(jì)Module Design。對(duì)于SOA在整個(gè)智能駕駛系統(tǒng)設(shè)計(jì)原理有個(gè)清晰的把控。