?前述文章已經(jīng)對整個SOA的架構(gòu)特性、實現(xiàn)基礎(chǔ)、應(yīng)用優(yōu)勢及開發(fā)流程進行了相應(yīng)的詳細闡述，從而對于整個SOA的設(shè)計流程已經(jīng)有了大概了解。整個核心思想是采用自上而下的方法進行設(shè)計，以改造現(xiàn)有車輛程序和平臺上實施的現(xiàn)有功能或系統(tǒng)的EE架構(gòu)(逆向工程)。

當前國內(nèi)較多的OEM的現(xiàn)有功能開發(fā)過程都是比較激進的，以較為迅速的方式開發(fā)出來后，無法實現(xiàn)平臺化應(yīng)用，在分布式架構(gòu)中的很多車型之間就無法進行軟件重用，更別說更高級別的集中式架構(gòu)設(shè)計方式了。這種無具體邏輯功能架構(gòu)的完整構(gòu)建方式往往制約了對于軟件定義汽車的強烈需求，因此在以面向服務(wù)SOA開發(fā)的過程中，我們更多的是建議將網(wǎng)絡(luò)拓撲、網(wǎng)絡(luò)通信、ECUs平臺架構(gòu)、功能需求和用例場景作為分析作為SOA轉(zhuǎn)換的起點。但是如果特性很復(fù)雜，那么仍然有必要使用邏輯功能架構(gòu)來定義高質(zhì)量和完整性的SOA。

基于SOA的EE架構(gòu)設(shè)計方法完全遵循一種自頂向下的研究開發(fā)方法，從而引入到車輛程序和平臺的新特性或系統(tǒng)。這種方法是以給定特性、系統(tǒng)需求、測試用例及邏輯功能架構(gòu)為輸入，在軟件平臺上由功能所有者Function Owner設(shè)計以域控制器級別公共的基礎(chǔ)服務(wù)類型，同時支持子系統(tǒng)和功能列表。

對于前文所述的業(yè)務(wù)驅(qū)動型SOA開發(fā)方法來說，本文將針對性的以一個業(yè)務(wù)分析的例子進行整體說明。以開發(fā)下一代高階自動駕駛系統(tǒng)為例，終端用戶期望在當前實現(xiàn)的功能基礎(chǔ)上，進一步增加功能適用場景，同時提升當前已實現(xiàn)功能的性能指標。

SOA架構(gòu)系統(tǒng)建模基礎(chǔ)原理

SOA 參考架構(gòu)是對抽象架構(gòu)元素進行建模，獨立于特定的解決方案、技術(shù)、協(xié)議。該參考架構(gòu)可以有效解決服務(wù)消費者和提供者的交互問題，涉及其中的關(guān)鍵要素（包含行為、信任、交互、控制）的參與、實現(xiàn)和管理。針對SOA所提供的服務(wù)過程模型包含描述、可見性、交互、策略等幾個大模塊。其中服務(wù)描述用于進行定義、使用、部署、管理等方式控制服務(wù)所需的交互信息，這些信息涉及服務(wù)可達性、服務(wù)接口、服務(wù)功能、服務(wù)相關(guān)聯(lián)的策略信息。 

服務(wù)接口描述應(yīng)包含行為接口（Action）和信息接口（Process），其中信息的處理需要使用信息交互模式MEP（這種交互模式可理解為一種時序圖）。服務(wù)可達性是為了使服務(wù)參與者能夠相互定位和交互，這種可達性需要有服務(wù)位置和描述通信方式的協(xié)議等信息，并涉及了解服務(wù)的端點、協(xié)議和存在性。服務(wù)功能是針對所提供的服務(wù)可能在真實世界中產(chǎn)生的效果的定義，該功能定義需要保證其功能效果滿足技術(shù)規(guī)范定義。

接下來，我們將基于SOA的服務(wù)架構(gòu)構(gòu)建針對ADAS系統(tǒng)的實例進行詳細原理分析。整個基于SOA架構(gòu)的開發(fā)流程可概括如下圖： 

對于整個SOA的整車開發(fā)流程來說，需要從整體商劃分為兩個層面的開發(fā)，其一是SOA的頂層服務(wù)開發(fā)，該層主要涉及面向服務(wù)的開發(fā)模式。

功能定義階段主要是由功能負責(zé)人Function Owner從整體功能設(shè)計角度上進行把握，其內(nèi)容涉及如下：

1、定義業(yè)務(wù)需求

包括對標市場主流車型的場景，接收項目組功能配置清單，從售后的角度對用戶需求進行調(diào)研，隨即生成功能場景庫。如果同時考慮自動駕駛系統(tǒng)的數(shù)據(jù)采集端口，需要考慮場景數(shù)據(jù)來源，包括自然采集數(shù)據(jù)、高精地圖數(shù)據(jù)、標準法規(guī)文檔、數(shù)據(jù)記錄場景及道路交通法規(guī)等可以生成不同的場景庫（如自然駕駛場景庫、重組場景庫、法規(guī)標準場景庫、事故場景庫、交通法規(guī)場景庫等）。如上的場景庫又可以通過ADAS功能安全測試生成預(yù)期功能安全場景庫，通過V2X終端功能測試生成V2X場景庫。

假設(shè)我們需要實現(xiàn)點對點自動駕駛這一終極自動駕駛目標，則需要首先對該目標進行分解，從而挖掘用戶的所有可能使用場景。比如需要進行適時加速、減速、換道、對中等操作。在細化下去，就是包含其感知、規(guī)劃及決策的系統(tǒng)控制能力拆解了。感知方面則是對車輛附著的多個傳感器分別進行能力需求定義Product Capability（PC），規(guī)劃決策方面則是會根據(jù)檢測的感知信息進行目標級語義融合，然后生成可用的軌跡信息，并預(yù)測該軌跡是否有碰撞風(fēng)險目標，這整個過程需要在模塊Module中不同軟件元組件Software Component（SWC）中進行分別定義和實現(xiàn)。決策執(zhí)行中對如上各個子目標動作的行為拆解，比如加減速則需要對底盤——動力系統(tǒng)進行一體化控制，對中控制則需要對轉(zhuǎn)向系統(tǒng)進行有效控制，換道則除了轉(zhuǎn)向系統(tǒng)EPS外，還需要對車身系統(tǒng)（如轉(zhuǎn)向燈）進行控制。

2、搭建Module服務(wù)架構(gòu)

Module架構(gòu)實際是實現(xiàn)整個SOA架構(gòu)從底層硬件層到頂層硬件層的整個功能設(shè)計模型，該模塊匯總了其下軟件組件SWC模塊，它們實現(xiàn)了產(chǎn)品功能并創(chuàng)建服務(wù)和算法來實現(xiàn)功能。從如下簡單的SOA軟件封裝模型中可知其中包含幾個大模塊： 

如上圖所示，Module模塊將車輛和使用模式的原子信息提供給車輛中的消費應(yīng)用程序和系統(tǒng)。所有管理或控制用戶功能和傳感器/執(zhí)行器的應(yīng)用程序都應(yīng)使用元服務(wù)來評估該功能是否應(yīng)由其自身的功能執(zhí)行。這樣做可以提供更好的安全性、健壯性，以用戶和系統(tǒng)有意義的方式實現(xiàn)快速訪問。

以ADAS開發(fā)距離，整個Module服務(wù)模塊可以被理解為實現(xiàn)ADAS功能的各個封裝模塊，比如車身域、底盤域、動力域、娛樂域等可分別拆解為module中其中一層的多個子Module。各個子module又可以定義自己的產(chǎn)品能力PC和軟件組件SWC。

3、分解Module產(chǎn)品能力

從場景庫分解出相應(yīng)的測試用例Usecase，各Usecase對應(yīng)著統(tǒng)一建模語言設(shè)計過程，其中包括相應(yīng)的用例圖、活動圖、時序圖。如上三種圖形在功能設(shè)計中至少需要有時序圖相對應(yīng)。

如下圖a所示用例圖需要從用戶角度描述系統(tǒng)功能，并指出各功能的操作者。圖b所示為針對各個產(chǎn)品能力所對應(yīng)的時序圖，時序圖中各子單元是實現(xiàn)某一個用戶功能所需要調(diào)用的產(chǎn)品能力單元，調(diào)用過程遵循從上至下過程。比如，如果某個功能先要進行功能自檢，就需要在初始調(diào)用單元中畫出回環(huán)箭頭來調(diào)用自身的自檢函數(shù)單元；如果要調(diào)用關(guān)聯(lián)系統(tǒng)的實現(xiàn)函數(shù)，則需要畫出箭頭指向關(guān)聯(lián)實現(xiàn)單元，并通過在箭頭上賦予相應(yīng)的調(diào)用函數(shù)名稱來實現(xiàn)對該實現(xiàn)函數(shù)模塊的調(diào)用。 

如上整個過程會涉及系統(tǒng)的硬件架構(gòu)設(shè)計，將會后續(xù)硬件部署中進行詳細介紹。對于要實現(xiàn)如上述功能所定義的場景，需要設(shè)計自動駕駛系統(tǒng)相關(guān)的域控制器或傳感器進行邊界能力設(shè)計。這里我們稱之為產(chǎn)品能力（Product Capability，PC），這種產(chǎn)品能力主要是針對自動駕駛系統(tǒng)。產(chǎn)品能力的需求設(shè)計是由系統(tǒng)設(shè)計架構(gòu)師進行設(shè)計的，他需要判定該需求是否能夠適配對應(yīng)的自動駕駛系統(tǒng)功能——>該PC是否準確——>如果沒有對應(yīng)PC，該如何新增——>如果有，該PC實現(xiàn)方式是由哪個模型Module來提供——>如果沒有相應(yīng)的支撐Module，該如何新增該Module（包括考慮在軟件模塊定義中如何實現(xiàn)功能性模塊和非功能性模塊）。

如上這一系列問題都是我們需要重點考慮的部分。

 4、分解Module軟件組件能力

功能軟件開發(fā)階段主要是由軟件模塊負責(zé)人Module Owner從整體功能軟件開發(fā)角度進行規(guī)劃，其中包含涉及的軟件模塊與功能負責(zé)人設(shè)計的功能進行映射，相應(yīng)的過程涉及軟件模塊架構(gòu)設(shè)計、軟件概要設(shè)計、軟件詳細設(shè)計。整個軟件設(shè)計過程主要是與系統(tǒng)設(shè)計階段的架構(gòu)、功能、場景均需要進行一一對應(yīng)。同時，在Module概要設(shè)計中主要是進行實現(xiàn)產(chǎn)品軟件組件（Software Component）SWC靜態(tài)接口設(shè)計，整個設(shè)計過程還要與前述產(chǎn)品能力PC進行相互映射（即每個產(chǎn)品能力PC都需要有一個相應(yīng)的軟件組件SWC來實現(xiàn)）。具體的SWC設(shè)計方法和映射原理會在后續(xù)文章中進行詳細闡述。 

5、功能安全與預(yù)期功能安全相關(guān)的設(shè)計過程

如上正向設(shè)計過程中，需要同步考慮功能安全進行同步設(shè)計。從上至下需要在設(shè)計場景庫階段制定功能安全目標Saftygoal。在定義用戶案例階段進行危害分析與風(fēng)險評估HARA分析，識別項目的功能故障引起的危害，對危害事件進行分類，然后定義與之對應(yīng)的安全目標，以避免不可接受的風(fēng)險。在定義活動圖和時序圖過程中需要同時進行整個功能安全需求FSR設(shè)計。 

在模型詳細設(shè)計階段，需要根據(jù)系統(tǒng)功能UML設(shè)計階段的時序設(shè)計、接口設(shè)計來進行軟件階段更為詳細的SWC動態(tài)時序設(shè)計、詳細接口設(shè)計。同時，在模型詳細設(shè)計階段還可以同步進行功能技術(shù)安全需求設(shè)計TSR。技術(shù)安全要求(TSR)是對功能安全要求(FSR)提煉,細化了功能安全的概念,同時考慮功能性的概念和初步的體系架構(gòu)。通過分析技術(shù)安全需要來驗證符合功能安全需求。因此，F(xiàn)SR是item級的功能安全要求,進行系統(tǒng)階段的開發(fā),需要將FSR細化為system級的TSR，然后可進行完整的系統(tǒng)設(shè)計。

總結(jié)

本文對整個SOA的架構(gòu)設(shè)計過程做了詳細的過程分析，其中包括搜集用戶需求，根據(jù)用戶需求定義使用場景，根據(jù)使用場景構(gòu)建不同的Module實現(xiàn)不同的功能子項，各個功能子項又需要定義自己的產(chǎn)品能力模塊、接口模塊、軟件組件模塊幾個。最后由SWC調(diào)用相應(yīng)的函數(shù)調(diào)用I/O模塊硬件和底層驅(qū)動模塊。同時，從正向開發(fā)的角度考慮，在自頂向下的設(shè)計過程中，需要充分考慮功能安全/預(yù)期功能安全相關(guān)的Saftygoal、FSR、TSR幾大設(shè)計流程設(shè)計。?