面向服務的架構SOA的出現可以打破車內靜態交互模型，并且建立功能靈活治理的系統架構。確保新增功能的實現可以與車輛原有的系統架構、驅動方式、通信方式相匹配。（SOA）總體思路是設計組件模型，將不同的應用功能服務進行拆分，并通過定義恰當的通信接口將相應的服務串聯起來。接口定義是獨立于實現服務的硬件平臺、操作系統和編程語言。確保構建在不同系統中的服務可以以一種統一和通用的方式進行交互。
SOA是基于系統的概念，這種系統是由一組服務組成的，其中一個服務可以輪流使用另一個服務，應用程序可以根據各自的需要調用一到多個服務。這一點上，SOA與Autosar的工作方式是一致的，因此，當前自動駕駛系統的開發中往往采用了基于Autosar的SOA設計模式。
一、基于Autosar的SOA軟件架構
基于SOA開發模式的軟件架構（見下圖）主要在于通過軟件抽象層——運行時環境 (RTE) 拆分獨立于硬件的應用軟件（ASW）和面向硬件的基礎軟件 (BSW)。一方面，這個抽象層能夠為OEM自動駕駛系統開發特定的、有競爭力的軟件應用程序。另一方面，它簡化了獨立于 OEM 的 基礎軟件標準化，其中，基礎軟件進一步分為以下幾層，“服務”、“ECU 抽象”、“微控制器抽象”。此外，它是 ECU 軟件可擴展性的前提條件。
運行時環境RTE是從基礎軟件中抽象出應用層，并組織它們之間的數據和信息流量。這構成了在應用層面向組件、獨立于硬件的軟件結構的基礎，軟件模塊可以作為獨立的單元存在。
例如，下一代自動駕駛系統采用SOA軟件模塊架構，其所有頂層功能都由底層軟件模塊實現。這些軟件模塊共同構成了應用程序。各個軟件模塊僅直接與 RTE 通信。因此，無論是在 ECU 內還是超出 ECU 邊界，都設計了清晰的通信邊界。通過這種獨立性，可以在不了解使用或計劃的硬件情況下開發軟件組件，或者更確切地說是在 ECU 之間分配現有軟件模塊。
二、基于SOA構建軟件設計方法
除了基于SOA的軟件架構模塊設計外，AUTOSAR針對汽車軟件開發提出了一套標準化的方法論，構建 ECU 中的軟件模塊，將各種 ECU 集成到具有不同總線系統的車輛通信網絡。它定義了通用工件和相關活動，特別是活動的依賴關系。
在 SOA的設計方法中可以使用AUTOSAR的相關信息，定義了一種具有語義約束的正式數據交換格式，這種數據信息作為標準描述了存儲在 AUTOSAR XML (.arxml) 文件中，這種ARXML文件實際是由頂層SOA系統架構設計者通過構建相應的SWC組件接口來生成的。軟件組件描述為應用軟件提供了標準化的組件模型，系統描述定義了系統上的純軟件層與物理系統架構之間的關系，許多工具使用這些描述來配置和生成AUTOSAR 中RTE的基礎軟件。
基于SOA架構的流程設計方法的原理如下圖所示。其中各框圖表示了帶有交叉鏈接的 ECU 實例。它描述了網絡拓撲、每個通道的通信以及各種 ECU 上軟件模塊的分配。
基于Autosar的SOA軟件架構設計方法
除了具備描述汽車行業 E/E 系統的基本能力外，還有許多方面需要實際交換格式的支持，例如可以通過技術文檔（包括規范、定義、技術要求等）、接口需求表等可追溯性來貫穿整個軟件生命周期。這種集成的變體管理允許 OEM 和供應商共同深入到基本的 AUTOSAR 產品線，并在必要時與其合作伙伴交換相互的信息，對這些變體的共同理解和一致解釋是聯合開發項目成功合作的關鍵因素。
各種SWC組件接口調用示意圖
SOA中的應用程序接口用于確保應用程序模塊與 RTE 進行有效鏈接。其中，AP Autosar并未標準化應用程序的內部功能流程，例如算法，而是將在應用程序之間交換的信息。
一方面Autosar使用專用語法將基本接口機制進行了標準化。這種標準化接口規范允許軟件設計人員和開發人員獨立于任何特定硬件或 ECU 來開發軟件模塊，這種軟件模塊可以在包含其使用的數據類型、單位和縮放因子下進行擴展或重用。另一方面對車輛域主體中應用程序接口的語義、內涵、舒適性、動力傳動系、底盤以及乘客和行人保護進行了標準化。重點是廣泛引入應用程序的接口規范，以重點突破軟件模塊的重用和交換。最后，標準化應用程序接口的使用對于應用程序的重用至關重要。
三、系統架構-虛擬功能總線
為了開發功能系統架構，AUTOSAR 引入了虛擬功能總線的概念——VFB（Virtual FunctionBus）。為了避免誤解，應該明確指出：AUTOSAR 已經指定了 VFB 概念。這個概念在市場上可用的各種系統架構工具中實現。
VFB 允許描述整個系統中應用模塊之間的功能交互，此描述獨立于實際 ECU 的架構和實施的網絡。通過這種方式，VFB 將應用程序從硬件中抽象出來，在這里，軟件組件被分配給 ECU，在每個 ECU 中，VFB 的功能由 RTE 和底層基礎軟件實現。在進一步架構構建過程中，功能系統架構被映射到物理架構上或者說在 ECU 和網絡拓撲上。SOA中將單個應用程序描述為軟件組件 (SWC)。VFB 既提供了它們之間的通信機制，也提供了使用基本軟件服務到軟件組件的機制，各種機制由所謂的端口表示。
四、SOA軟件分層
1、應用軟件
SOA軟件架構的層模型將應用軟件以軟件組件的形式放置在應用層中，可以將軟件組件分組為在外部再次充當軟件組件的組合。通過這個通用組件概念，可以將軟件組件的任何嵌套層次結構實現為一個系統。應用軟件可以獨立于硬件進行設計和開發。
軟件組件通過端口進行通信，每個端口代表某種通信機制。應用程序之間通信中最重要的機制是“發送方-接收方”用于由數據發送方發起的通信，以及“客戶端-服務器”用于接收方發起的通信。除此之外，還有用于過程控制（外部觸發事件）或用于訪問某些參數（校準、操作模式、非易失性存儲器）的更多端口。每個端口都有一個接口，用于確定要通信的數據類型。AUTOSAR 已在編程語言 C 中定義了端口的精確映射。下圖顯示了 ECU 內以及不同 ECU 中的應用程序之間的通信路徑。
軟件組件在 AUTOSAR中由 “軟件組件模板”做特定描述。除了端口和接口的描述之外，這還包含所謂的內部行為。在 AUTOSAR 的上下文中，“內部行為”是描述與時間或事件相關的過程控制（事件和調度）相關的組件。這包括“可運行實體”的定義，即底層操作系統可在事件或時間上調度的最小軟件實體。需要說明的是，要在組件中明確實現的算法不屬于“內部行為”。
在實踐中，有幾種典型的方法來填寫或編輯軟件組件描述。許多基于模型開發的設計工具如EA、Rapshody等，可以從圖形模型中生成軟件組件描述，并允許編輯相應的條目。此外，RTE 生成器通常允許編輯軟件組件描述。對于具有特定硬件要求的應用程序，例如作為依賴于某些傳感器或執行器的軟件，AUTOSAR 提供了所謂的傳感器/執行器軟件組件，其中可以在軟件組件描述中注明此類約束。
2、實時運行環境
AUTOSAR 運行時環境 (RTE) 從基本軟件的任何實現細節和控制設備的硬件中提取應用程序。它表示特定 ECU 上 VFB的運行時實現。RTE 提供應用程序之間的通信機制和訪問基礎軟件服務的機制。這還包括為通信提供數據緩沖和排隊。RTE 的實際程序代碼取決于應用程序及其通信、使用的基礎軟件服務和調度。在實踐中，代碼是由 RTE 生成器根據軟件組件描述信息創建的。
嚴格來說，RTE 是一種“中間件”層技術，它可以通過去中心化網絡實現應用層組件的重新定位。
3、基礎軟件
基礎軟件通過 RTE 為應用程序提供所有系統服務和功能。盡管基本軟件的功能對于應用程序來說是必不可少的，但車輛用戶通常不會很好地注意到這些功能。隨著對硬件的依賴性越來越大，基本軟件進一步劃分為多個層次：即服務層、ECU 抽象層和微控制器抽象層。反過來，每一層都包含代表精確指定功能范圍的單獨模塊。AUTOSAR 基礎軟件總共包含大約 80 個不同的模塊，標準對每個模塊都有一個要求和軟件規范。其中模塊的功能行為及其接口是用 C 定義的，因此一個模塊的兩種不同但符合標準的實現可以直接互換。基本軟件模塊的功能行為參數化及其配置使用與應用程序組件相同的形式描述機制?？刂茊卧拒浖K的配置描述總結在ECU配置描述中。
五、基于Autosar的SOA 服務
服務層包括通信服務、診斷協議、存儲服務、ECU工作模式管理等系統服務，以及作為獨立模塊的AUTOSAR操作系統（OS）。AUTOSAR OS 基于實時系統標OSEK/VDX，在某些領域得到擴展，但在其他領域也受到限制。它是靜態配置和縮放的，并提供基于優先級的實時行為和中斷處理。在運行時，可以使用各種用于內存訪問或時間行為的保護機制。AUTOSAR OS 也適用于小型和較低性能的微控制器，同時也支持多核對代碼、數據使用和使用多個內存分區，服務的模塊是獨立于硬件的操作系統。這些系統服務可通過 RTE 提供給應用程序，應用程序不能直接訪問底層的基本軟件模塊。這是保留提供服務作為其功能的一部分從而訪問 ECU 或微控制器資源。服務模塊及其底層模塊也稱為功能棧，例如 FlexRay 的通信棧。此類堆棧有時會作為一個大型軟件單元來實現和集成，而沒有 AUTOSAR 定義的底層模塊結構。雖然這破壞了抽象原則并降低了靈活性，但由于實現的效率和性能可能更高，因此在 AUTOSAR 中使用函數堆棧進行處理很普遍。
六、硬件抽象
服務層主要用于硬件抽象。首先，ECU 抽象層將 ECU 布局（即外圍模塊如何與微控制器連接）與上層分離。盡管這一層是特定于 ECU 的，但它獨立于微控制器。下一級抽象是由微控制器抽象層實現的，其中包括微控制器特定的驅動程序。例如，這些驅動程序是用于數字輸入和輸出的 I/O 驅動程序，或用于將模擬信號轉換為數字值的 ADC 驅動程序。因此，AUTOSAR 標準直接支持標準化硬件。
復雜驅動層用于處理特殊情況，例如，用于控制具有特殊實時要求或具有特定機電硬件要求的復雜傳感器或執行器。此類模塊并未標準化為 AUTOSAR 基本軟件模塊，因為這里需要汽車制造商或供應商的特定專業知識和知識產權。然而，復雜的驅動程序和標準化的模塊必須滿足 AUTOSAR 基礎軟件中接口機制的要求。
七、基于Autosar的SOA系統配置
在 AUTOSAR 的上下文中，系統是指網絡控制單元的組合或集成，其中可能包括車輛的所有 ECU。系統配置遵循 VFB 級功能系統架構的開發。在設計系統配置時，會根據系統的實際物理架構做出決定。這些決定主要與系統拓撲有關，即哪些控制單元可用以及它們如何連接。對于每個控制單元，都有關于處理器架構、處理器容量、內存、接口和外圍設備或信號方法的資源描述。網絡拓撲的描述范圍從總線系統到各個通道的通信矩陣。此外，它還包括確定哪個應用軟件組件應該在哪個控制單元上運行，所有這些信息都記錄在系統描述中。在實踐中，這可以通過系統架構設計工具以及 VFB 設計（也稱為系統生成器）或通過基本軟件模塊的配置工具來完成。
系統配置成功需要通過對各個控制單元的進一步配置，最后通過軟件集成來完成，每個 ECU 都是獨立的，即如果需要，它可以并行運行。此外，某個控制單元的所有相關信息都被復制到系統配置之外的 ECU 描述中。這被命名為系統描述的 ECU 摘錄。ECU 描述還匯總了每個基本軟件模塊的配置描述。基本軟件配置的許多參數直接來自系統描述軟件組件的描述。其余的自由參數通過使用基本的軟件配置工具來設置。在幾乎所有基本軟件模塊的配置步驟之后，屬于配置的代碼由生成器生成——就像在 RTE 中一樣。
應用軟件組件的實現是算法和編碼的創建，可以與系統配置完全并行完成，因為這一步獨立于硬件。最終，基礎軟件的整個代碼連同 RTE 代碼以及所有應用軟件組件的代碼都集成到每個控制單元的 ECU 軟件中。
八、總結
整體上講，面向服務的SOA架構設計主要包含五個步驟：梳理整車功能、規劃SOA架構、服務定義、服務矩陣和ARXML設計、服務驗證和仿真；SOA不是一種具體的技術實現，而是一種模板軟件架構，而AP AUTOSAR則稱是一個模板SOA。如何利用Autosar構建好的SOA模型是我們需要特別關注的。本文詳細闡述了面向服務的SOA軟件設計過程，以Autosar為基礎分析軟件架構及其設計方法、系統配置、硬件抽象、軟件分層等。
來源：焉知智能汽車 作者：Jessie
