1
從SOA-RM到AP
在《AP 基礎簡介》之視頻中，我們提到：AP 是一種面向服務的架構！在中也提到：SOA不是具體的技術實現，而是一種模板軟件架構！
那么，怎么來理解SOA是一種模板軟件架構？又如何理解為什么AP 是SOA？以下是筆者的一些理解分享給大家，如有不對之處，還請指出。
SOA的全稱是：面向服務的架構（ ），從SOA的概念中，我們比較容易產生一個問題：這個架構怎么來的？要想搞清楚這個點，我們需要先理解以下SOA參考模型（SOA-RM）
①
SOA-RM到SOA
SOA參考模型（SOA-RM）描述了SOA環境中的各個組件（或者實體）及其之間的關系。當前對SOA-RM的研究大致分為以下幾類：1. 以W3C的Web服務架構工作組為代表：
2. 以OASIS成立的SOA-RM技術委員會為代表：
3.以軟件組件為基礎進行系統架構的研究
筆者比較認可OASIS的觀點，且與汽車行業相關度大，因此筆者將以OASIS為代表的SOA-RM出發進行分析。PS：《搞一下汽車電子》也為各位解鎖全系的朋友準備了中文版的OASIS《soa-rm-v1.0》，在公眾號菜單欄聯系我們進行獲取
筆者基于OASIS的觀點，整理了SOA-RM與SOA的關系如下：
圖：OASIS SOA-RM
簡單來說：SOA-RM只是一個框架，架構師可以使用現有的協議（如web服務協議）、標準以及規范等來構建具體的架構實現，那么根據SOA-RM，并結合一定協議、標準以及規范等構建出來的架構便是一種面向服務的架構SOA！
到此，我們知道了SOA的構建來自SOA-RM。那么軟件構架指的是什么，接著下一個問題，SOA到底是什么？上文筆者也說明了筆者眼中的SOA：SOA是一種模板軟件架構，這怎么理解？AP 是SOA又如何理解呢？我們往下看：
②
SOA到AP
在中，我們主要介紹了SOA的通信機制，并簡單介紹了SOA的概念。知道了它不是具體的技術實現，那么SOA是一種模板軟件架構如何理解呢？
我們將模板軟件架構拆開來理解：
所以，筆者認為SOA是一種模板軟件架構，并不是具體的技術實現。因為SOA不涉及具體技術實現的內容！這也能對應了SOA是SOA-RM的一種應用！這里對SOA中服務的概念進行一個簡單說明：
理解了SOA是一種模板軟件架構，那么為什么AP 是一種SOA，筆者認為主要體現在以下方面：
從模板的角度出發來理解，AP 提供了一套開發應用程序的方法即AP 方法論，主要分為三部分：軟件開發（下圖綠色框），包含：集成與部署（下圖黑色框），包含：
圖：AP 方法論概覽
從軟件方面理解：
AP 使用互操作服務的形式進行軟件開發，機制如下：
主要包含兩個角色：兩者之間是通過通信管理中間件（CMM）傳輸層進行通信。通信管理中間件主要以下通信方式（協議約束）：
服務提供者和服務消費者之間的連接是CMM在運行時動態創建的！
圖：Proxy
需要提到的是，AP 中采用了服務骨架（ ）與服務代理（ Proxy）模式，服務骨架與服務代理是根據 ”服務接口定義 “ 生成的。
PS：那么SOME/IP如何設計，DDS又如何設計？我們將會在后期《搞一下SOA》系列與《搞一下整車以太網》系列中進行分享（需解鎖全系哦！）
筆者認為，單一個軟件通信還不足以成為軟件架構，AP 除了通信之外，還有其他的系統元素，如：與存儲相關的ara::per 功能集群。詳細的架構圖如下，我們也在中對上述每個功能集群進行了簡單的描述。
因此，筆者認為，AP 是SOA（注意這里是SOA，不是SOA-RM），是一種模板軟件架構！
圖：AP 架構概覽
上圖中需要提到的是，AP 規定，只能直接訪問POSIX的PSE51接口，不能直接訪問非PSE51接口。PS：《搞一下汽車電子》也為各位解鎖全系的朋友準備了原版的《.13》，在公眾號菜單欄聯系我們進行獲取
解釋了為什么AP 是SOA，我們再來總結一下what AP ？
詳細內容，請查閱
圖：What AP
這里筆者也總結了一下AP 的特性：
我們從SOA-RM出發，分析了AP 。AP 也剛發布了R2011版本，本系列后期也會結合AP R20-11的新特性來分享《搞一下AP 進階應用》，因此，這里筆者為大家整理了一下AP R20-11的一些更新！
2
AP R20-11
我們將從文檔、平臺設計以及新增特性等方面進行分享。
①
文檔變更
R2011文檔方面的變更還是很大的，《搞一下汽車電子》按照之前的分類方式將R2011進行了整理，大家可以后臺回復" AP點映"進行查看。
我們還是將其分為以下幾個文件夾：
其中 增加了很多中功能集權的解釋性說明文檔，主要包括：
部分，增加了以下內容：
其中：《》規定了傳感器接口上AP 的要求。《》描述了傳感器接口的功能說明與接口
部分進行了以下更改：
需要說明的是，R2011標準文檔中，沒有《》等，筆者認為是缺少了，而不是被刪除了。
And 部分進行了以下更改：
其中《ions》是通過元模型對時間擴展正式定義的補充。
這里需要特別說明的一個文檔是《》。筆者認為，上述文件入侵檢測系統管理（Idsm）應該是一個屬于部分的功能集群（FC），但是，其他文檔中，都沒有與Idsm相關的內容。即使是《平臺設計》中也沒有。屬于標準的問題軟件構架指的是什么，可能會在下個版本中有所體現。
②
平臺設計變更
《平臺設計》是AP 中對AP 進行概述的文檔，這里，對平臺設計中主要的改動進行說明如下：
1. 在《持久性》章節進行了以下更改：
持久性主要的三種應用場景有：
圖：
在R1911中，對上述三種應用場景進行了以下說明：
UCM都使用持久性來部署/刪除/更新應用程序的持久性數據
在R2011中，對其進行說明如下：在前兩個場景中，持續性由UCM通過EM觸發，以部署/更新應用程序的持久性數據在第三個場景中，UCM可以使用uri從持久性配置中刪除剩余的持久性數據2. 在《UCM》章節，更改了UCM 的狀態機：
我們也會在后期基于此分享" AP & OTA"
圖：UCM 狀態機
3. 在《》章節更改了密鑰管理交互，如：增加獨立且受信任的環境等：
圖：密鑰管理交互
當然，還有其他更多更改內容，可參考《AP 平臺設計》文檔。PS：《搞一下汽車電子》也為各位解鎖全系的朋友準備了中文版的AP R2011《平臺設計》，在公眾號菜單欄聯系我們進行獲取
③
新增特性
從方面來說，新增了系統健康監控，主要用于系統協調健康狀況/錯誤。主要包含以下內容：
圖：系統健康監控
從上圖也可以看出，SHM 是在AP 端，SHM 是CP 端。這也是官方在AP 功能安全方面的又一考慮吧。有關AP & 更多內容，可查看
在方面，也增加了確定性同步的內容，描述了同步行為和周期性激活的要求，包括時間同步和數據同步。
圖：確定性同步
從方面來說，增加了入侵檢測系統管理，有標準化的接口來報告安全事件，有標準化的過濾機制，來通過網絡來傳輸合格的安全事件。PS：還是如前所說，除了一份Idsm文檔外，無更多描述
在方面，也增加了 API的描述：
上述，便是R2011主要的變更，當然還有很多變更，我們會在后期的系列分享中，與大家進行分享，那么為什么要分享《搞一下AP 進階應用》
3
Why AP 應用
從流程來說：
從架構來說：
從功能需求來說：
從應用來說：
從兼容適配來說：
當然，上述內容會根據實際情況進行一定的調整。最后再回答一個大家比較關心的問題：如何學習AP ？