1.3.2 AP（自適應平臺）與CP（經(jīng)典平臺）的對比

無論是自適應平臺還是經(jīng)典平臺，總體目標都是一致的：更好的管理數(shù)量增多，功能復雜度增加的汽車ECU、改善ECU軟件質量和可靠性、提升產(chǎn)品升級靈活性，縮短產(chǎn)品推向市場的時間、可拓展的架構解決方案。但是它們在各方面都有很大的區(qū)別。

首先，CP AUTOSAR一般運行在8bit、16bit、32bit的微控制器（MCU）中，如英飛凌的TC3xx、瑞薩的RH850等。AP AUTOSAR可以運行在64bit的高性能處理器（MPU）、CPU等中，如瑞薩的H3、英偉達的Xavier等。除此之外，AP AUTOSAR也可以運行在虛擬硬件上。

硬件不同，其算力也不同。CP是無法運行在高算力的芯片上的，而AP則可以在算力高于20000 DMIPs的芯片上運行。芯片算力越高，就意味著相同時間可以處理更為復雜的算法，那么軟件可實現(xiàn)的功能也就越高。

CP和AP的軟件架構也是不同的，CP的軟件架構有明顯的上下層關系，其軟件架構如圖1-23所示。

可以看出，AUTOSAR CP主要有微控制器層、基礎軟件層、RTE層和應用層。AUTOSAR CP架構設計原則為：

1）CP AUTOSAR將與硬件相關的以及通用系統(tǒng)功能定義為BSW模塊。

2）應用功能定義為獨立的軟件組件SWC。

3）RTE分離SWC和BSW。

4）BSW可配置，并且可以被多個產(chǎn)品線的ECU重復使用。

5）CP是不開源的。

而AP的軟件架構則如圖1-24所示。

圖中所有的模塊均稱為功能集群（Functional Clusters，F(xiàn)C），功能集群又分成兩部分：Foundation（FO）和Service。每個功能集群都是相互獨立的，沒有相互依存（Dependency）的關系，也就是說，一個廠家搭建的軟件架構不一定需要設計圖1-24中所有的FC，只需要根據(jù)軟件需求設計相應的FC即可，可以降低系統(tǒng)開發(fā)成本。AP的設計原則是：

1）遵循面向服務的架構（SOA）設計范式（理念）。

2）充分利用其他領域軟件成熟技術，重用軟件市場成熟組件，縮短開發(fā)周期。

3）充分利用各種開源軟件。

在軟件開發(fā)過程階段，CP與AP都主要都包括以下三個階段：

1）設計階段：設計ARXML。

2）代碼生成：基于ARXML生成代碼。

3）集成：集成Application、編譯調試等。

AP與CP在軟件開發(fā)過程中主要有以下不同：

1）在AUTOSAR AP設計階段，需要進行Service和Manifest的設計，而CP則無此過程；CP需要進行ECU配置設計，而AP沒有ECU配置這個設計項。

當然，CP與AP都需要進行系統(tǒng)設計和診斷設計，具體的不同體現(xiàn)在設計細節(jié)上。

2）在代碼生成時，CP生成的是基礎軟件模塊相關的代碼，AP生成的是FC相關的代碼和Manifest，需要注意的是，AP中不是所有的FC都會生成相關的代碼和Manifest。

3）集成時，AP AUTOSAR需要考慮OEM Application Cloud，而CP則不用。

AP在軟件設計階段不需要考慮軟件應用具體部署到什么位置，即哪個ECU。軟件開發(fā)人員只需要按照軟件的功能需求進行軟件開發(fā)即可，AP程序的驗證也可以不在ECU上驗證，AP可以通過將軟件部署到虛擬ECU來驗證各類軟件的正確性。

4）CP與AP還有一個很大的區(qū)別是通信方式。以往汽車ECU間的通信是通過CAN，各ECU將信號往總線上發(fā)送，各個ECU又從總線上各取所需。在以往的車輛上，這種通信方式是可以的，但是當新的技術涌現(xiàn)出來，總線上已經(jīng)不足以傳輸數(shù)量如此龐大的信號時，我們就需要提出一種新的通信方式以滿足傳輸大量信號數(shù)據(jù)的需求。這時候面向服務的通信架構（Service Oriented Architecture，SOA）就出現(xiàn)了，SOA是將應用程序的不同功能單元（稱為服務）進行拆分，并通過這些服務之間已定義好的接口和協(xié)議聯(lián)系起來。接口是采用中立的方式進行定義的，它應該獨立于實現(xiàn)服務的硬件平臺、操作系統(tǒng)和編程語言。而在AP系統(tǒng)中，所有應用由一組服務組成，其中一個服務可以依次使用另一個服務，應用程序可以根據(jù)其需要使用一個或多個服務。服務可以駐留在應用程序運行的本地ECU上，也可以位于正在運行AP另一個實例的遠程ECU上。數(shù)據(jù)只在需要的時候傳輸，總線的使用率降低了很多。

5）CP與AP的調度方式也是不同的，CP AUTOSAR OS采用固定的任務調度配置。在OS Task中調度BSW Main Functions以及SWC的Runnable Entities，按既定規(guī)則順序執(zhí)行，并協(xié)同BSW Modules和App SWC的模式切換。而AP AUTOSAR支持多種動態(tài)調度策略，配置在運行時完成，配置信息在Manifest文件中體現(xiàn)。AP AUTOSAR中與調度相關的模塊主要為執(zhí)行管理（EM）和狀態(tài)管理（SM），應用程序運行在Process、Thread中。CP AUTOSAR中，任務的調度周期可以到微秒（μs）級別；而AP AUTOSAR是在毫秒（ms）級，一般是幾十至上百毫秒。

6）CP的狀態(tài)管理較為簡單，而AP主要有以下三種狀態(tài)管理：

①Function Group（FG）State：功能組狀態(tài)。Machine State：Machine狀態(tài)是一種典型的功能組狀態(tài)。

②Process State：進程狀態(tài)。EM通過Function Group來改變Process State。

③Execution State：進程的執(zhí)行狀態(tài)。

AP的狀態(tài)管理結構如圖1-25所示。

CP與AP的主要區(qū)別見表1-1。

因此，與CP相比，基于AP開發(fā)的ECU具有更加智能、更大的計算力（基于SOA架構使得AP能夠支持多核并行處理），更好的安全性，更好的兼容性，更靈活敏捷的開發(fā)，更易實現(xiàn)物聯(lián)（基于以太網(wǎng)的SOA通信，更易實現(xiàn)無線、遠程、云連接以及部署V2X應用）。