對于Adaptive AUTOSAR，經常會看到這句話：Write once， Adopt everywhere。但實際上理想很豐滿，現實很骨感。畢竟Classic Platform（后面簡稱：CP）搞了這么多年大家都還沒玩轉，更何況這剛出沒兩年的Adaptive Platform（后面簡稱：AP），但樓主也相信隨著Autosar標準的不斷推進和應用，我們不斷在向這個目標接近。

如樓主《Adaptive Autosar》那篇所說，Adaptive Autosar并不是為了取代Classic Autosar和非Autosar架構的平臺，而是為了更好的與當前這些架構平臺相互兼容、協作并滿足未來的需求。例如Classic Autosar已增加對車載以太網SOME／IP的支持，而這對于Adaptive Autosar來說必須是基本操作，而且還會支持更加先進的通訊方式。

Adaptive Autosar的特點

1、以C＋＋為實現形式

Adaptive Autosar平臺的Applications都將采用C＋＋編程，我們知道C是嵌入式系統(tǒng)的主要編程語言，具有執(zhí)行速度快、效率高的特點；但在性能要求非常高的復雜應用和算法開發(fā)上（如機器學習、圖像特征識別等）具有面向對象特性的C＋＋顯然比C更具有優(yōu)勢，而AP主要適應未來智能化和網聯化的需求，這些需求的實現主要涉及復雜應用和復雜算法的開發(fā)，因此選用一種面向對象的編程語言是必要的。最新Release的Adaptive Autosar標準完全采用C＋＋ 11／14作為首選語言。

2、面向服務的通訊方式（SOA）

為了支持復雜的應用程序，并在并行處理和計算資源分配上具有最大的靈活性和可擴展性，AP采用面向服務的通訊架構。SOA主要基于以下概念：系統(tǒng)由一組服務構成，其中一個可使用另外一個的服務，應用程序Applications可根據自己的需要使用一個或多個服務；此外服務可以在應用程序運行的本地ECU上，也可在運行另一個AP實例的遠程ECU上。

3、并行處理能力

分布式計算本質上是并行的，先進的多核異構處理器既具有強大的計算能力也能為并行計算提供技術支持，隨著多核異構計算技術的發(fā)展，AP具有擴展其功能和性能架構的能力。事實上，硬件和接口規(guī)范僅是實現AP的一部分，在OS等技術和開發(fā)工具的發(fā)展上對實現AP的應用也至關重要。

4、利用現有標準

閉門重新造車是沒有意義的，尤其在規(guī)范方面。正如C＋＋中所描述的那樣，AP采用重用和調整現有開放標準的策略，來促進AP本身更快的發(fā)展應用并在現有標準的生態(tài)系統(tǒng)中受益。因而開發(fā)的AP規(guī)范并不是隨意引入新的標準，因為現有標準已提供了所需的功能需求。

5、具有一定的安全性

AP目標系統(tǒng)通常需要一定的安全性，新技術的引入不應破壞這些要求，盡管實現起來并非易事。為了應對該挑戰(zhàn)，AP則將架構、功能和過程方法結合起來來保證一定的安全目標。AP架構是基于SOA的分布式計算架構，這種方式可保證功能組件更加獨立而不受意外干擾，從而可實現專用功能的安全性，此外諸如C＋＋編碼指南等指導書有助于我們更加安全可靠的使用諸如C＋＋的復雜編程語言。

6、動態(tài)部署

AP支持應用程序的動態(tài)部署，通過資源和通訊的動態(tài)管理來降低軟件開發(fā)和集成的effort，從而實現短迭代周期。增量部署還支持軟件開發(fā)階段，就如開發(fā)個Beta版本的軟件部署在控制器上去不斷測試驗證和修復，從而達到最終的正式版。

在AP架構下，不同的Applications可能由不同供應商提供，因此在產品交付階段，AP允許系統(tǒng)集成商合理限制這種動態(tài)部署的特性以降低不必要的風險和影響。應用程序將受到Application Manifest中所規(guī)定的約束限制，幾個應用程序的Manifest在設計時可能會產生相互影響，但在執(zhí)行時，在配置的范圍內，資源和通訊路徑的動態(tài)分配僅可以限定的方式進行。

Adaptive Autosar軟件分層架構

下面是AP的軟件分層架構，樓主隨意選兩點談談，謬誤之處，還請指正。

在AP架構下，一切都是OS中的進程，這跟CP架構有著顯著的區(qū)別，在CP架構下，所有應用都是靜態(tài)配置的，即應用的進程在OS中被寫死，一旦軟件編譯完成就不可更改，其調用的周期也是確定，因此基于CP架構的軟件一旦有小的應用變更就得重新配置和編譯：費時費力。而AP架構的軟件就如計算機的工作原理，應用是動態(tài)運行的，何時調用、進程生存周期、資源占用及進程結束等都由系統(tǒng)動態(tài)管理，好比你手機上的App何時打開、運行后其會調用的資源及何時關閉都是動態(tài)進行的。

AP架構的優(yōu)勢能使車載控制器可如同手機一樣（理想的目標），使應用實現動態(tài)的部署和升級更新。

在AP架構下每個Application都是一個App，每個App主要包含如下這些部分：

App都有一個非常重要的API－＞ara：：com，這個API在分層架構下的位置如下：

ara：：com使基于SOA的通訊方式成為可能，負責進程間和不同控制器間基于服務的通訊。

在AP這種靈活的框架下，ara：：com可支持或擴展對車載以太網SOME／IP  、 TSN 、 DDS等SOA通訊技術的應用。

對Data Distribution Service（DDS）或基于時間敏感網絡（TSN）等通訊技術的支持如下：

Adaptive Autosar的應用

Adaptive Autosar的應用是靈活的，下面樓主就列舉三個吧。

1、大眾MEB平臺軟件架構

我們知道針對互聯化、智能化的趨勢，大眾推出MEB平臺，期望從MQB分布式的E／E架構向MEB的中央集成式E／E架構過渡，并希望在后續(xù)的電動車上都采用最先進的MEB平臺打造，構建從高端到平價的車輛體系，有點后發(fā)先至的感覺，關于大眾MEB平臺，樓主《半吊子劃水在上海車展》這篇有點涉及。

樓主在今年的上海車展上已看到大眾向電動化進軍的決心，今年車展大眾帶來了各系列車型的混動或純電動版本，借助MEB平臺，大眾希望打造互聯、智能并可具有高度擴展性、靈活性的整車系統(tǒng)。

而整車的軟件架構毫無疑問需要AP架構的加入和支持，如下：

2、域控制器

域控制器也是最近這些年才熱起來的，所謂的域就是將整車E／E架構劃歸為不同的區(qū)，如動力域、車身域、底盤域、娛樂域等，每個域只需要掛載單個控制器來負責所在域的通訊和控制，減少之前一個功能、一個“盒子”的分布式E／E架構復雜的布線和集成：其實就是將多個控制器的軟件糅合進一個控制器。我們知道不同的控制器軟件可能由一個或多個供應商提供，若由多個供應商提供，每個供應商除了負責各自軟件的升級，還涉及復雜且不同類型軟件的集成，那么顯然AP架構可很好的滿足這種需求，使不同的軟件在單個多核控制器上的集成和升級工作變的相對容易些。

3、自動駕駛應用

自動駕駛領域的競爭目前是十分火熱的，既有傳統(tǒng)大佬，也有新入玩家，目前主要的玩家有如下這些，但就如幾年之前的手機操作系統(tǒng)一樣，相信最終只有少數玩家才能贏得這場競賽。

自動駕駛應用的加入使整車功能更加復雜，不同的應用可能由很多供應商提供，其次應用也越來越復雜，對計算資源和性能要求越來越高，需要更牛逼的硬件來支持，而AP架構既能滿足應用對高性能計算的需求又具有一定的功能安全等級。

例如BMW計劃在以后的自動駕駛系統(tǒng)方面，對軟件組件進行重新設計，以支持不同的API要求，從而將軟件合理布置在不同架構上發(fā)揮更優(yōu)的功能。

總結

此次樓主又嘮叨了很多，總體來說呢，CP架構雖然搞了這么多年但依然在路上，因為其依然需要不斷的完善，由于CP標準的復雜性，到目前我們還沒玩轉，整車控制系統(tǒng)的軟件架構要實現完美的Classic Autosar依然任重而道遠；而AP架構伴隨著互聯化、網聯化的趨勢在這兩年應運而生，其更需要不斷的完善和發(fā)展。CP和AP不是為了誰取代誰，而是針對不同的應用領域和不同的功能安全要求相輔相成。

參考文獻：

Autosar標準文檔以及Vector、EB、Mathworks等技術文檔等