Aspice作為車載軟件過程中，關注于功能場景定義（function definition）、架構定義（System Architecture）、系統設計（System Design）、產品設計（Product Design）幾個大的方面。而下一代智能駕駛系統需要面向服務進行相應的功能設計和開發，實現軟硬件解耦。這種開發方式將對整個智能駕駛來說產生顛覆性的影響，比如高性能計算平臺HPC包含多核異構處理模式，通過Hypervisor技術實現對硬件抽象，Inter-Core通信技術使多篇和單片多核實現信息互通，計算單元趨于“云計算+中央計算+邊緣計算結合等多個方面的變革。如上這些設計原則更多的是基于SOA的架構進行的，這就大大增強了平臺的可拓展性，可移植性。

當前更多的主機廠選擇在智能駕駛中采用SOA的開發模式，這可以更加快速的實現從底層、中間層到應用層的軟件開發，且相對較多的軟件只要接口定義得當，就可以實現軟件本體和功能的遷移，同時可以大大的降低開發周期和成本。

對于SOA的設計過程來講，其服務設計原則包括重用、抽象、封裝、協調在內的多個層面。比如對于智能駕駛功能開發而言，如果需要多次用到某一邏輯元素比如車道線等環境信息，則應該將車道線檢測模塊創建為重用（比如封裝到Building Block中），則對該車道線檢測源（如不同方位的攝像頭）進行調整，則由此對車道線檢測產生的任何更新改變都會對后續級聯的應用實例產生影響。而上層應用軟件端對于底層的如何獲取車道線，如何處理的細節也不需要深究，這就是實現模塊抽象的整個過程。抽象后的邏輯功能需要保證其體系相類似的功能需要集成到一起，比如自動換道功能的控制邏輯可以在自動激活后調用觸發換道相關的規劃控制模塊進行車控。因此，觸發換道的規劃決策控制邏輯單元可以完全應用于自動換道模塊。系統工程師只需要保證定義的接口適用于觸發換道已經發布或預定的數據流即可。對于自動駕駛域控單元負責人而言，應該保持邏輯系統結構之間的協調和重用，包含對公共池中的元素排布，對局部域單元中的邏輯構造，跨域之間的資源或模塊調度等。

本文將以智能駕駛系統開發設計實例來講解和分析相應的SOA為基礎下的架構設計和軟件開發。

面向ASPICE流程的SOA軟件架構流程

適用于SOA架構的ASPICE軟件開發過程也是在敏捷開發的模式下進行的系統開發流程。從智能駕駛功能開發層面上講，基于SOA架構開發模式包括了系統功能、系統架構、軟件功能、軟件架構幾個方面。其中分別由分別稱之為產品負責人Product Owner、功能負責人Function Owner、架構負責人Architect Owner、子模塊負責人Module Owner的幾個角色共同承擔。功能設計是搭建功能架構圖和依據產品工程師輸入的產品需求定義進行功能分解定義，架構負責人則根據整車架構及功能負責人輸入的要素信息制定合適的軟硬件架構。這里需要說明的是很多情況下，功能負責人和架構負責人往往是同一個人。模塊負責人則是根據功能定義編制相應的系統軟硬件模塊、零部件軟硬件模塊以實現上層定義的功能需求。各負責人之間的角色定位將在如下分層流程圖中進行詳細說明。這里我們僅關注V模型中的與SOA相關度較高的設計開發部分，測試驗證部分不在本文中進行詳述。

其中，各階段的開發輸出功能過程如下：

1、項目功能定義

項目功能元素（function element）包含與頂層設計相關的不同屬性，例如車輛類型、預期市場、項目功能以及功能發布計劃等。在實際開發中，這類輸出一般是產品策劃部門或市場部輸出的整車功能開發需求或整車裝備需求。本文將以開發智能駕駛系統功能中的點對點自動駕駛NOP為例進行詳細的分析說明基于SOA的架構設計是如何應用于自動駕駛系統開發的。

如下圖舉例中，表示了實現下一代自動駕駛系統NOP場景定義需求。

2、系統架構設計階段（System Architecture Design）

這個階段涉及產品能力定義及模塊定義。用于描述智能汽車中的用戶功能，通過定義相應的函數來指出使用哪些子系統或者零部件具備相應的產品能力（Product Capabilities，PC）并對其進行相應的實例化來實現此功能。

（1）產品能力PC：

這種稱之為產品能力的模塊主要是用于定義想要實現該功能模塊的傳感器或執行器所具備的能力，這也是位于各個時序圖上各個節點的能力描述。通常，該產品能力的定義主要由產品工程師牽頭，功能所有者、架構師和模塊所有者/設計者的跨職能小組共同決定。

（2）產品能力實例化PC Instance：

產品能力可以被認為是一種高級服務，一些需要在汽車中實現的功能，但它沒有描述應該如何實現。產品能力實例是 PC 的簡單實例化，可以在平臺中擁有 PC 的不同變體。如果需要 PC 的不同變體實例以及在何處使用不同的實例，則模塊所有者負責。系統架構師負責定義系統中定義了產品能力PC的不同類型，并確定哪些 PC 需要由跨職能團隊才能完成。通過將當前定義的 PC 和其他的需要PC 建立依賴關系，我們可以建模一個完整的功能架構，該功能層級的架構無需研究實際的實現機制。這對于定義需要哪些高級服務 (PC) 以及分配誰（哪個模塊）負責實施每個 PC 非常有幫助。

如上過程一般是通過各種圖表（包含用例圖、序列圖、活動圖等）來完成的。如下圖表示了一種活動圖所示意的系統交互方式。

由于在定義過程中還建立了與功能之間的連接，因此我們可以使用該模塊來規劃需要實現 PC 的順序，以便我們在每個版本的集成階段開發出正確的功能。

（3）模塊及實例Module Instance：

模塊是整個模型甚至整個組織中非常核心的元素。從SOA的架構設計上講，每個設計的 PC 都被分配到一個并且只有一個模塊（或者稱之為函數），該模塊負責實現 PC，但在整個平臺生命周期內維護和發展 PC，規劃 PC 的演進步驟，提供路線圖等。

PC 定義的功能在 Component 中實現，模塊實例可以確保在平臺中擁有模塊的不同變體。系統架構師負責定義系統中存在哪些模塊，但模塊所有者負責領導模塊內的工作，并負責維護和發展模塊。模塊所有者還負責是否需要模塊的不同變體實例以及在何處使用等。

同時，模塊中的相關參數是在對應構建的系統功能規范中實現定義的。

3、軟件架構設計階段

軟件組件Software Component：

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

軟件包Software Package：

軟件包是將部署到特定運行環境時的所有軟件組件、清單文件等的集合。

為了實現面向SOA的架構設計和開發過程，需要重點定義。

4、底層驅動設計階段

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

一個 ECU 可以由一個或多個處理器組成，一個處理器可以運行一個或多個虛擬機。不必對每個組件進行建模，例如，如果 ECU 僅包含一個處理器，則僅對 ECU 進行建模就足夠了。可以將各個軟件包部署到如上運行時環境中的任何一個。

網絡及連接器Network Connector：

定義網絡以及連接到它的運行時環境。運行時環境可以由一個或多個網絡連接組成，這些網絡連接可以是 CAN、CAN FD、以太網、VLAN、LIN 等。

嚴格說來，底層驅動設計應該屬于軟件架構設計的其中一個部分，面向底層軟件設計部分，通常與頂層軟件開發團隊不是一伙人，且具有較大區別，該開發過程由頂層軟件設計人員對底層軟件開發人員單獨提出需求及建議。一般的需求包括平臺軟件總體架構及對相關AUTOSAR標準組件和復雜驅動的調度框架設計、開發和集成要求；內存、非易失性存儲、任務、中斷等等資源和權限分配；上下電流程和管理的設計；系統運行狀態監控、異常處理等功能的設計等方面。

基于SOA架構模型設計分工

基于SOA軟件模型架構的設計過程實際是在研究如何在開發流程中進行軟硬件解耦。包括構建不同的分層來隔離硬件與軟件功能和服務。例如，將自動駕駛相關的傳感器和執行器邏輯與應用程序邏輯分開，則能夠在中央系統中分配應用程序，同時保持傳感器/執行器盡可能的具體。程序之間可以利用SOA的服務模式實現軟件包的調用，傳感器和執行器也可以作為組件或模組來進行邊緣采購，性能則是集中管控，中央系統可以將戰略軟件進行分開，這就更容易進行軟件模塊移植和處理。這一過程實際就是在提高上層應用層軟件關鍵功能的復用性，瞄準軟硬件功能與邏輯控制分離。這里需要說明的是，軟硬件之間的協調和調度是通過中間件來實現。

從如下圖所示，SOA的架構從下至上分別底層驅動功能管理，物理層功能管理，車輛控制服務，面向用戶的應用服務，云端遠程管理。

底層驅動功能管理：用于實現包含診斷、日志記錄、存儲管理、驅動管理等相關功能。

物理層功能管理：主要是設置I/O接口將原始傳感器數據進行輸入，同時也是執行到車端的控制單元（如電機、制動卡鉗等）；

車輛控制服務：車端控制包含上層ADAS發送的執行指令到控制執行器執行該指令的相應ECU（如控制電機的VCU、HCU或ESP），該車輛控制服務是綜合考慮了車身穩定性與動力學反饋模型得出的。

應用層服務：該層服務就是智能駕駛面向用戶級別的頂層開發功能，主要用于實現包含傳統的智能駕駛功能，比如HWP、NOP、TJP以及ALC等。

云端管理服務：該層服務主要是面向遠程監控，遠程控制，大數據存儲等特殊場景。通常該服務需要基于4G/5G網絡進行遠程連接。

人機交互管理功能：人機交互管理功能一般是針對不同的車型呈現出不同的模式的，因此，這一塊一般是獨立于SOA的功能架構。SOA通常只涉及底層對車輛控制邏輯，對于平臺化車型功能開發來說，這一塊是無法為用戶所感知的。而HMI的顯示設置則是用戶能夠真切感知和控制的，因此，不同車型肯定是有極大的不同之處。因此，從協議上分析不難看出，SOA內部的網絡架構一般是基于以太網為基礎的交互方式，采用Some/ip的協議進行通信控制。而如果在平臺化車型的開發過程中，HMI這一塊的通常仍然按照原始CAN/CANFD信號模式的通信協議進行交互控制。這么做的原因是，智能駕駛的HMI行為比核心應用功能更容易改變，特別是在不同車型開發后期通常會選擇不同的顯示和交互方式。同時，由于開發核心軟件和HMI設計需要不同的能力技能，因此，將HMI功能與其他應用層軟件功能分離，為了實現這一點，一般需要使用Model-View-Controller，用戶輸入由Controller處理，Controller用于解釋用戶的意圖并操作模型。

SOA服務實現過程

隨著車載以太網技術的日益成熟，國內大部分OEM都已經著手SOA的設計工作，并將以太網通信矩陣生成ARXML文件，用于項目前期的網絡行為仿真和后期測試驗證。對于已經完成架構搭建的SOA來講，需要將其建模后的成品導入到軟件團隊進行服務實現。其過程包含：以Some/Ip協議導入Service ARXML，導入后新增ETH、TCP/IP、Some/IP模塊（BSW工程），建立與Service Handler SWC（應用層）中Port Interface連接，為所有Service Handler SWC增加可運行時間，定義Windows Service Handler SWC 和Feature SWC到Simulink/Stateflow。通過符合Autosar的ARXML和Simulink進行交互，將由軟件開發工程師繼續進行算法設計并自動生成代碼。

總 結

本文從SOA軟件架構模型的構建角度出發講解了相應實現過程原理，利用了基于模型、集成式的可視化開發工具PREEvision進行了智能汽車行業及相關領域E/E架構開發并支持以太網SOA的架構開發設計，本文以介紹SOA架構設計模型為基礎展示了如何在Enterprise Architect中進行SOA建模。同時，以系統工程師的角度說明如何利用Enterprise Architect構建SOA系統及軟件架構設計、功能設計Function Design 和模塊設計Module Design。對于SOA在整個智能駕駛系統設計原理有個清晰的把控。