01

SOA架構技術概述

1.1 面向服務計算的目的和價值

面向服務計算的七大戰略目標相互聯系，具體來說可以分為兩組，即戰略目標和戰略價值（優勢）。其中提高組織業務敏捷性、提高投資回報率和減少研發成本（或IT負擔）是其他四個目標實現所帶來的價值和優勢。 在將面向服務持續應用于軟件程序設計時，一系列戰略目標和優勢（如圖1所示）共同代表了我們所期望實現的目標狀態。理解這些目標和優勢是非常有益的，因為它們可以為我們提供連續不斷的總體背景和理由，以維持我們長期實現面向服務的投入。

以下簡單說明七大戰略目標的內涵：

1. 增強本征互操作性：即互操作性指的是數據的共享。軟件程序的互操作性越高，其之間的信息交換越容易。

2. 增強聯合：即服務的聯合。軟件資源和應用程序聯合在一起，同時保持其各自的自主性和自治性。

3. 增加供應商多元化選擇：即供應商多元化能力，指組織必須選擇“最佳品種＂的供應商產品和技術創新。

4. 同步提升業務與技術領域：即應用程序的設計和實現不僅要滿足初始業務需求，也應滿足未來隨業務性質和方向變化時的業務需求。

5. 提高投資回報率：即衡量自動化解決方案投資回報率(ROI)是決定應用程序或系統實際成本效益的關鍵因素。

6. 提高組織的業務敏捷性：即組織能夠對變化做出反應的效率，以適應行業變化并超越競爭對手。

7. 減少研發成本(IT成本）：即減少浪費和冗余，縮小規模和運營成本，減少與其治理和演進相關開銷等。

1.2 SOA架構特征及優缺點

SOA是一個組件化模型，它將應用程序的不同功能單元（服務）通過這些服務間良好的接口和契約聯系起來。其中，服務(Service)是一個粗顆粒度的、可發現的軟件實體，以一個單獨實例存在，通過一組松耦合和基于消息的模型與其他應用或服務交互。接口是采用中立的方式進行定義的，獨立于實現服務的硬件平臺、操作系統和編程語言，使得構建在這樣的系統中的服務可以以一種統一和通用的方式進行交互。

交互的服務大致由三個實體組成：服務請求者、服務提供者和服務注冊表。其中實體間的操作包括：服務發布、服務發現、服務綁定和調用。 面向服務架構是眾多軟件架構風格中的一種，是微服務架構的一種。因面向服務架構風格具有基于標準、松散耦合、共享服務和粗粒度等優勢，表現出易于集成現有系統、具有標準化的架構、提升開發效率、降低開發維護復雜度等特征，更符合智能網聯化時代車載系統對軟件架構的要求，所以被汽車行業引入和采用。

SOA因組件化和服務化模型特征，有其自身的優缺點，具體分析如下（僅針對IT行業業務特征和實施環境）：

優點分析：

靈活性，根據需求變化，可重新編排服務或應用程序

對IT資產的復用

使企業的信息化建設真正以業務或應用為核心，業務人員根據需求編排服務，不需要考慮技術細節

缺點分析：

服務劃分很困難

服務的編排是否得當

如果選擇的接口標準有問題，會帶來系統的額外開銷和不穩定性

對IT硬件資產還談不上復用

主流實現方式接口很多，很難統一

主流實現方式只局限于不帶界面的服務的共享

1.3 SOA國內外技術應用現狀

在IT行業，國外于1996年由Gartner第一次提出SOA思想，2005年SOA開始推廣和普及，2007年應用廠商希望通過發布標準來推動SOA的實施，如SCA和SDO通過OASIS審核，WS-POLICY、W3C成為W3C標準等，如今SOA在國外IT行業、通訊行業、政府部門得到廣泛系統性應用。其中，歐美實現SOA架構的關鍵任務是：對已有系統中的功能進行提取和包裝，形成標準化的“服務”。

在國內，2006年之前是技術萌芽；2006-2008年是過熱期；2009年度過了幻滅期；從2010年開始進入復蘇期，現在正處于由復蘇期邁向成熟期。其中，國內近30年的IT建設多為生產型系統，服務型系統普遍未開始建設，大量"服務"需要全新標準化構造。

在汽車行業，因汽車智能化和網聯化需求，尤其是自動駕駛系統研發應用的需要，車載系統SOA軟件架構技術受到國內外整車企業的關注。國外，2010年以寶馬、電裝、大眾等為首的歐、美、日汽車產業巨頭便開始車載SOA軟件架構的研究工作，形成一定理論基礎和實踐成果，并對傳統汽車電子系統進行革命性創新。

當前，大眾、奧迪、寶馬、福特等汽車巨頭自成聯盟，進行SOA軟件架構技術和規范的應用研究，預計2023前后將開始應用于量產車型。國內，整車企業有加入和使用的意愿，但考慮軟件架構規范核心實施技術不給予開放，后期產品技術和產品生態會高度依賴國外技術平臺和標準規范，將會嚴重制約車企自身創新發展。

其中， 一汽、東風和上汽等部分頭部OEM己意識到SOA軟件架構的重要性，在尋找自主解決方案。同時，軟件架構技術屬于行業共性技術，屬于開發式共性平臺，因國內缺少行業協同和協作機制，在共性平臺和生態建設方面發展緩慢。

02

SOA技術規范現狀

2.1 Web服務SOA相關技術規范概述

Web服務作為SOA架構技術發展的典型和成熟代表，其促進了SOA架構技術的發展和推廣，其標準體系的開發方式和開發內容對于車載SOA軟件架構技術規范開發具有深入的指導意義。

2. 1. 1技術標準組織

SOA架構的WEB服務相關的標準化組織主要有三家，分別為萬維網聯盟(World Wide Web Consortium, W3C)、結構信息標準化促進組織(Organisationfor the Advancement of Structured Information Standards, OASIS)和Web服務互操作組織(Web Service Interoperability Organisation,WS-I) W3C是一個專注于開發基于Web的行業技術標準的國際聯盟。它的使命是通過開發協議和指導方針，確保萬維網作為一種多功能媒體的長期增長，使萬維網充分發揮其潛力。1994年Tim Berners-Lee創建了W3C,因為跨網絡分割的風險變得越來越明顯（特別是在多個版本的HTML同時工作時）。從那時起，W3C就開始優先開發核心的Web技術(HTML、XML等），以及相關的樣式化語言(CSS 、XSLT等）。如今，Web服務嚴重依賴于W3C開發的技術，W3C委員會制作Web服務技術

主要由以下幾部分：

? XML 架構1.0;

? WSDL 1.1，2.0;

? SOAP 1.1, 1.2；

? WS-Addressing 1.0;

? WS-Policy 1.5;

OASIS

OASIS成立于1993年，是一家非營利性的國際協會，旨在開發、整合和推廠包括Web服務、安全、商業事務、供應鏈、電子政務、互操作性等所需的標準。OASIS對Web服務的貢獻包括對UDDI(Universal Description Discovery and Integration)規范的標準化，以及對WS-BPEL規范的標準化。此外OASIS也推出了諸如面向服務的架構參考模型和面向服務架構的相關規范等。OASIS和W3C不同，他的主要興趣在于制定附加規范以及支持不同的行業，與應用領域的關系更為密切。

WS-I

WS-I成立于2002年，其目的不是建立新的標準，而是旨在推動Web服務的互操作性。具體目包括三個方面：

為客戶的網絡服務應用提供實施指導和培訓；

促進跨平臺、跨應用軟件和跨程序語言的網絡服務的一致和兼容，并保證可靠兼容；

致力于使網絡服務協同成為本行業共同遵守的準則，以幫助客戶在網絡服務技術的選擇上輕松決策，提高網絡服務的應用范圍和水平，并確保網絡服務技術的持續發展。

2. 1. 2技術標準的形成 標準如何被開發出來？

為了充分利用Web服務技術，最大潛力發掘其技術價值，理解將技術規范開發為已批準的行業標準的過程是很重要的。 這一切都始于新技術的原創想法，當社區對這個想法有足夠的興趣時，W3C就會舉行一個開放的研討會，相關方聚在一起討論技術解決的范圍和技術提出的解決方案。

就Web服務而言，供應商組織通常倡議他們獨立或合作開發的技術，雖然這些技術常常用來解決那些對供應商來說很重要的問題，但人們希望讓它們成為非專有的Web服務框架的一部分。如果W3C參與者之間有足夠的協議，那么這些所提出的技術將成為創建行業標準的基礎。

標準開發流程是怎樣的？

W3C技術規范聲明周期的第一步是成立一個負責定義目標標準的工作組。該組將由W3C成員組成，他們通常由供應商代表和從業者組成。W3C還提供了支持的技術人員，幫助確保該技術將完全補充其他已經開發的行業標準。然后，該組通過以下階段開發一個規范：

l．工作草案——這是一個定期發布的規范的快照，以讓社區了解工作組所采取的方向，并收集早期的意見。

2．最后一次呼叫工作草案——當工作組認為該規范滿足其所有原始要求時，它將發布此文件并正式請求社區的意見。這一步驟通常至少持續三周。

3．候選推薦——納入前一階段的反饋后，工作組要求實施規范，以確保規范實際上是可實現和互操作的。

4．建議——證明規范巳以互操作方式成功實施，已提交W3C咨詢委員會批準，這一步驟至少會持續四周。

5.建議——規范為W3C建議，通常稱為“行業標準”。整個過程的持續時間因所開發規范的范圍和復雜程度而不同。從一個工作組成立的那一刻起，它可能需要18個月到幾年的時間來提交W3C建議。在這些階段，公眾可以通過提交工作組有義務回應的反饋，對正在制定的技術規范發表評論。工作組成員之間的所有通信和工作組的所有交付成果都發布為公開訪問。 W3C的一個特殊性是，它的過程是基于共識的，這意味著整個工作組在做出決定之前需要就解決方案達成一致。投票只有在有嚴重分歧的情況下才會進行投票，而通過投票作出的任何決定通常會在剩下的過程中進行仔細審查。

2.2 AUTOSAR-AP平臺SOA相關技術規范概述

AUTOSAR-AP平臺采用SOA方法論，主要涉及一種自適應軟件產品的開發，是一套包括軟件分析、設計、開發、部署在內的復雜工作流程。主要包括兩個方面：工作流定義與成果物定義（如圖2-2)。具體描述如下：

2.21 流程定義

AP平臺的方法論作為CP平臺的擴展，其引入了新的概念，AP平臺軟件的實例是在進程的上下文中執行。AP平臺引入了“機器”(Machine)的概念，“機器”是虛擬化的ECU,一個可以部署軟件的實體。它可以是真實存在的處理器，也可以是一個虛擬機，AP軟件則運行在某一特定的“機器”上。



(1)開發服務接口(Service Interface)

AP平臺是一個面向服務的軟件架構(SOA)，基于AP平臺的軟件開發，首先需要進行服務接口的設計。服務接口可以由事件(Events)、方法(Methods)和字段(Fields)組成，是生成軟件組件頭文件的基礎。

(2)開發通信結構(Communication Structure)

OEM在設計階段需要指定預期“機器”(Machine)的通信結構以及相應的配置參數，包括機器的所有網絡端點和服務發現地址端口等。這一步將產生一個可交付的“機器設計”(Machine Design)，一個特定的“機器”模型將引用一個特定的“機器設計“ 模型。

(3)開發自適應應用軟件(Adaptive Application Software)

自適應應用軟件開發從軟件組件(SW component)的設計開始，軟件組件是通過其端口(Port)定義的，每個端口實現一個服務接口。基于服務接口描述，生成包含實現軟件組件的頭文件。開發人員在此基礎上實現軟件組件的核心功能。

(4)開發自適應平臺軟件(Adaptive Platform Software)

與應用級軟件類似，平臺級軟件可以由基于標準化服務接口的軟件組件組成，也可以直接實現而不需要軟件組件模型。

(5)定義和配置機器

包括了功能組狀態和每個狀態超時的定義，進程到特定機器的映射，以及平臺服務（例如NM、DoIP) 和基礎模塊（例如日志）配置等。此過程會產生一個獨立于服務實例或應用程序的機器清單(Machine Manifest)

(6)集成軟件

軟件的實現和編譯完成后，需要集成到一個可執行文件CExecutable)中。通過進程來定義特定機器上可執行文件的實例化，每一個進程會產生一個執行清單CExecution Manifest)，其中包括了進程及其啟動配置。

(7)定義和配置服務實例(Service Instance)

首先對服務接口進行部署，然后定義服務接口的實例，并決定是否提供或使用該服務實例。其次要建立服務實例到機器的映射，以及服務實例到端口的映射。此過程會產生進程所需的所有服務實例清單(Service Instance Manifest)

(8)生成軟件包(Software Package)

將可執行文件及所需清單整合為軟件包上傳到機器上，而無需重新刷寫。OEM可以將軟件包存儲在后端服務器中進行統一管理。

2.22 成果物定義

由于AUTOSAR的工作流包含了整個汽車軟件開發流程，涉及多個開發角色，因此需要各個開發角色之間有信息交互，為了保證信息不出現二義性，需要對各個環節的工作成果物規則進行定義。同時為了信息的保存、傳輸、交互的需求，需要定義這些成果物的載體，ARXML就是定義了不同流程成果物的載體，使用不同的標簽來表示不同的信息及流程，這些標簽的定義就是AUTOSAR的數據元模型（如下圖)。



MO:使用Ml級規則生成的可運行軟件實體，例如車門控制的可自行軟件組件

Ml:使用M2級規則定義軟件組件，例如車門控制的軟件組件，軟件組件的表現形式可以是ARXML,C/C+＋語言或各類文檔。一般情況下會使用工具鏈以ARXML的形式定義軟件組件的框架，然后導入下游工具鏈生成目標語言。或直接生成目標語言框架，然后手寫代碼的形式完成整體的軟件組件；

M2:使用M3級規則定義使用AUTOSAR開發的元素、語法及規則，例如軟件組件，port口，機器，清單等。該級別的元素與具體的功能無關，類似于各類開發語言的語法；

M3:用于定義M2的元模型

審核編輯：劉清