作者 |Jessie
前述文章已經對整個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幾大設計流程設計。