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

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

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

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

SOA架構系統建模基礎原理

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

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

接下來，我們將基于SOA的服務架構構建針對ADAS系統的實例進行詳細原理分析。整個基于SOA架構的開發流程可概括如下圖： 

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

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

1、定義業務需求

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

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

2、搭建Module服務架構

Module架構實際是實現整個SOA架構從底層硬件層到頂層硬件層的整個功能設計模型，該模塊匯總了其下軟件組件SWC模塊，它們實現了產品功能并創建服務和算法來實現功能。從如下簡單的SOA軟件封裝模型中可知其中包含幾個大模塊： 

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

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

3、分解Module產品能力

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

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

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

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

 4、分解Module軟件組件能力

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

5、功能安全與預期功能安全相關的設計過程

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

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

總結

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