久久免费观看视频,sese久久,久久人人97超碰caoporen

從SOA-RM到AP AUTOSAR

在《AP AUTOSAR基礎簡介》之《AP AUTOSAR & SOA》視頻中，我們提到：AP AUTOSAR是一種面向服務的架構！在《SOA點映》中也提到：SOA不是具體的技術實現，而是一種模板軟件架構！那么，怎么來理解SOA是一種模板軟件架構？又如何理解為什么AP AUTOSAR是SOA？以下是筆者的一些理解分享給大家，如有不對之處，還請指出。 SOA的全稱是：面向服務的架構（Service Oriented Architecture），從SOA的概念中，我們比較容易產生一個問題：這個架構怎么來的？要想搞清楚這個點，我們需要先理解以下SOA參考模型（SOA-RM）

①

SOA-RM到SOA

SOA參考模型（SOA-RM）描述了SOA環境中的各個組件（或者實體）及其之間的關系。當前對SOA-RM的研究大致分為以下幾類： 1. 以W3C的Web服務架構工作組為代表：

它是通過定義一些具體的功能組件和其他抽象實體來研究這些組件和實體之間的關系。但是，它定義于Web服務技術背景，故其架構分析具有局限性。

2. 以OASIS成立的SOA-RM技術委員會為代表：

它主張以SOA中相關的抽象概念和實體為出發點，來研究它們之間的關系。它認為SOA涉及的元素包括服務與服務的描述，服務的發布與發現機制，服務的相關規范，數據模型和服務協議等！

3.以軟件組件為基礎進行系統架構的研究

主要有IBM、微軟等企業為代表，它們進行著自己的應用平臺以及解決方案的SOA研究。但是這樣的模型依賴于特定的技術平臺，因此，不是理想的SOA通用模型。

筆者比較認可OASIS的觀點，且與汽車行業相關度大，因此筆者將以OASIS為代表的SOA-RM出發進行分析。 PS：《搞一下汽車電子》也為各位解鎖全系的朋友準備了中文版的OASIS《soa-rm-v1.0》，在公眾號菜單欄聯系我們進行獲取筆者基于OASIS的觀點，整理了SOA-RM與SOA的關系如下：

SOA-RM是一種抽象框架

SOA-RM并不與任何標準、技術和其他的具體實現細節關聯

與標準技術和其他具體實現細節相關聯的是SOA

SOA是SOA參考模型的一種應用

圖：OASIS SOA-RM 簡單來說：SOA-RM只是一個框架，架構師可以使用現有的協議（如web服務協議）、標準以及規范等來構建具體的架構實現，那么根據SOA-RM，并結合一定協議、標準以及規范等構建出來的架構便是一種面向服務的架構SOA！到此，我們知道了SOA的構建來自SOA-RM。那么，接著下一個問題，SOA到底是什么？上文筆者也說明了筆者眼中的SOA：SOA是一種模板軟件架構，這怎么理解？AP AUTOSAR是SOA又如何理解呢？我們往下看：

②

SOA到AP AUTOSAR

在《AP AUTOSAR & SOA》中，我們主要介紹了SOA的通信機制，并簡單介紹了SOA的概念。知道了它不是具體的技術實現，那么SOA是一種模板軟件架構如何理解呢？我們將模板軟件架構拆開來理解：

模板：基于現有標準、技術等實現一套用于設計和開發應用程序的原則和方法

軟件：這里的軟件代表著一種軟件設計模式，可以使用互操作服務的形式來開發軟件

架構：這里的架構是指一種架構設計模式，按照服務所屬所指定的約束和策略來執行

軟件架構：是指由系統元素及其外部可見屬性以及他們之間的關系組成。

所以，筆者認為SOA是一種模板軟件架構，并不是具體的技術實現。因為SOA不涉及具體技術實現的內容！這也能對應了SOA是SOA-RM的一種應用！這里對SOA中服務的概念進行一個簡單說明：

服務是最基本的單元，一種能夠訪問一個或多個功能的機制

理解了SOA是一種模板軟件架構，那么為什么AP AUTOSAR是一種SOA，筆者認為主要體現在以下方面：從模板的角度出發來理解，AP AUTOSAR提供了一套開發應用程序的方法即AP AUTOSAR方法論，主要分為三部分：

架構與設計（下圖藍色框），包含：

開發一個服務接口描述

通過Machine Design開發通信結構

軟件開發（下圖綠色框），包含：

開發Application-Level類型的軟件

開發Platform-Level類型的軟件

集成與部署（下圖黑色框），包含：

定義和配置Machine

創建Execution Manifest

定義和配置Service Instance

等等

圖：AP AUTOSAR方法論概覽從軟件方面理解： AP AUTOSAR使用互操作服務的形式進行軟件開發，機制如下：主要包含兩個角色：

服務提供者

服務消費者

兩者之間是通過通信管理中間件（CMM）傳輸層進行通信。通信管理中間件主要以下通信方式（協議約束）：

SOME/IP

DDS

服務提供者和服務消費者之間的連接是CMM在運行時動態創建的！

圖：Proxy Skeleton Pattern 需要提到的是，AP AUTOSAR中采用了服務骨架（Service Skeleton）與服務代理（Service Proxy）模式，服務骨架與服務代理是根據 ”服務接口定義 “ 生成的。 PS：那么SOME/IP如何設計，DDS又如何設計？我們將會在后期《搞一下SOA》系列與《搞一下整車以太網》系列中進行分享（需解鎖全系哦！）筆者認為，單一個軟件通信還不足以成為軟件架構，AP AUTOSAR除了通信之外，還有其他的系統元素，如：與存儲相關的ara::per 功能集群。詳細的架構圖如下，我們也在《What AP AUTOSAR》中對上述每個功能集群進行了簡單的描述。因此，筆者認為，AP AUTOSAR是SOA（注意這里是SOA，不是SOA-RM），是一種模板軟件架構！

圖：AP AUTOSAR架構概覽上圖中需要提到的是，AP AUTOSAR規定，Application只能直接訪問POSIX的PSE51接口，不能直接訪問非PSE51接口。 PS：《搞一下汽車電子》也為各位解鎖全系的朋友準備了原版的《IEEE1003.13》，在公眾號菜單欄聯系我們進行獲取解釋了為什么AP AUTOSAR是SOA，我們再來總結一下what AP AUTOSAR？

SOA：動態創建連接

中間件：承上啟下

標準：規范API及功能、規范交互方式、規范開發方法

詳細內容，請查閱《What AP AUTOSAR中》

圖：What AP AUTOSAR 這里筆者也總結了一下AP AUTOSAR的特性：

靈活的軟件配置

Security & Safety

并行處理

與現有標準及規范的兼容

基于POSIX標準

動態分配內存

SOA

我們從SOA-RM出發，分析了AP AUTOSAR。AP AUTOSAR也剛發布了R2011版本，本系列后期也會結合AP AUTOSAR R20-11的新特性來分享《搞一下AP AUTOSAR進階應用》，因此，這里筆者為大家整理了一下AP AUTOSAR R20-11的一些更新！

AP AUTOSAR R20-11

我們將從文檔、平臺設計以及新增特性等方面進行分享。

①

文檔變更

R2011文檔方面的變更還是很大的，《搞一下汽車電子》按照之前的分類方式將R2011進行了整理，大家可以后臺回復" AP點映"進行查看。我們還是將其分為以下幾個文件夾：

Adaptive Foundation：與基礎功能集群相關的文檔

Adaptive Service：與服務功能集群相關的文檔

General：AP AUTOSAR General文檔

Methodology And Manifest：與方法論、元模型以及Manifest等相關的文檔

Release Documentation：Release相關文檔

其中Adaptive Foundation增加了很多Foundation中功能集權的解釋性說明文檔，主要包括：

AdaptiveService部分，增加了以下內容：

其中：《AUTOSAR_RS_AutomatedDrivingInterfaces》規定了傳感器接口上AP AUTOSAR的要求。《AUTOSAR_SWS_SensorInterfaces》描述了傳感器接口的功能說明與接口 Adaptive General部分進行了以下更改：

需要說明的是，R2011標準文檔中，沒有《AUTOSAR_SWS_General》等，筆者認為是缺少了，而不是被刪除了。 Methodology And Manifest部分進行了以下更改：

其中《AUTOSAR_TPS_AdaptivePlatformTimingExtensions》是通過AUTOSAR元模型對時間擴展正式定義的補充。這里需要特別說明的一個文檔是《AUTOSAR_SWS_AdaptiveIntrusionDetectionSystemManager》。筆者認為，上述文件入侵檢測系統管理（Idsm）應該是一個屬于Foundation部分的功能集群（FC），但是，其他文檔中，都沒有與Idsm相關的內容。即使是《平臺設計》中也沒有。屬于標準的問題，可能會在下個版本中有所體現。

②

平臺設計變更

《平臺設計》是AP AUTOSAR中對AP AUTOSAR進行概述的文檔，這里，對平臺設計中主要的改動進行說明如下： 1. 在《持久性》章節進行了以下更改：持久性主要的三種應用場景有：

在Adaptive Machine上安裝新的應用程序軟件

將現有應用程序軟件更新到Adaptive Machine

從Adaptive Machine卸載現有的應用程序軟件

圖：Persistency 在R1911中，對上述三種應用場景進行了以下說明： UCM都使用持久性來部署/刪除/更新應用程序的持久性數據在R2011中，對其進行說明如下：在前兩個場景中，持續性由UCM通過EM觸發，以部署/更新應用程序的持久性數據在第三個場景中，UCM可以使用uri從持久性配置中刪除剩余的持久性數據 2. 在《UCM》章節，更改了UCM Master 的狀態機：我們也會在后期基于此分享" AP AUTOSAR & OTA"

圖：UCM Master狀態機 3. 在《Crypto》章節更改了密鑰管理交互，如：增加獨立且受信任的環境等：

圖：密鑰管理交互當然，還有其他更多更改內容，可參考《AP AUTOSAR 平臺設計》文檔。 PS：《搞一下汽車電子》也為各位解鎖全系的朋友準備了中文版的AP AUTOSAR R2011《平臺設計》，在公眾號菜單欄聯系我們進行獲取

③

新增特性

從Safety方面來說，新增了系統健康監控，主要用于系統協調健康狀況/錯誤。主要包含以下內容：

SHM Client交流平臺健康狀況

SHM Master確定健康指標

根據健康指標進行的機器恢復（例如降級）

圖：系統健康監控從上圖也可以看出，SHM Client是在AP AUTOSAR端，SHM Master是CP AUTOSAR端。這也是AUTOSAR官方在AP AUTOSAR 功能安全方面的又一考慮吧。有關AP AUTOSAR & Safety更多內容，可查看《AP AUTOSAR & Safety》在Safety方面，也增加了確定性同步的內容，描述了同步行為和周期性激活的要求，包括時間同步和數據同步。