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

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

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

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

SOA架構(gòu)系統(tǒng)建?；A(chǔ)原理

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 4、分解Module軟件組件能力

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

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

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

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

總結(jié)

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