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

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

1  以C++為實現(xiàn)形式

Adaptive Autosar平臺的Applications都將采用C++編程，我們知道C是嵌入式系統(tǒng)的主要編程語言，具有執(zhí)行速度快、效率高的特點；但在性能要求非常高的復(fù)雜應(yīng)用和算法開發(fā)上（如機器學(xué)習(xí)、圖像特征識別等）具有面向?qū)ο筇匦缘?/span>C++顯然比C更具有優(yōu)勢，而AP主要適應(yīng)未來智能化和網(wǎng)聯(lián)化的需求，這些需求的實現(xiàn)主要涉及復(fù)雜應(yīng)用和復(fù)雜算法的開發(fā)，因此選用一種面向?qū)ο蟮木幊陶Z言是必要的。最新Release的Adaptive Autosar標(biāo)準(zhǔn)完全采用C++ 11/14作為首選語言。

2  面向服務(wù)的通訊方式（SOA）

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

3  并行處理能力

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

4  利用現(xiàn)有標(biāo)準(zhǔn)

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

5  具有一定的安全性

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

6  動態(tài)部署

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

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

下面是AP的軟件分層架構(gòu)，樓主隨意選兩點談?wù)?，謬誤之處，還請指正。

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

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

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

App都有一個非常重要的API->ara::com，這個API在分層架構(gòu)下的位置如下：

ara::com使基于SOA的通訊方式成為可能，負(fù)責(zé)進程間和不同控制器間基于服務(wù)的通訊。

在AP這種靈活的框架下，ara::com可支持或擴展對車載以太網(wǎng)SOME/IP  、 TSN 、 DDS等SOA通訊技術(shù)的應(yīng)用。

對Data Distribution Service（DDS）或基于時間敏感網(wǎng)絡(luò)（TSN）等通訊技術(shù)的支持如下：

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

1  大眾MEB平臺軟件架構(gòu)

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

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

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

2  域控制器

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

3  自動駕駛應(yīng)用

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

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

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

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