本系列學(xué)習(xí)筆記基于 AUTOSAR Adaptive Platform 官方文檔 R20-11 版本。本文從AUTOSAR_EXP_PlatformDesign.pdf開始，一邊學(xué)習(xí)，一邊順帶著翻譯一下。盡力而為，不保證精確。你若愿意，也可以當(dāng)作 AUTOSAR Adaptive Platform （AP）中文版來閱讀 。
傳統(tǒng) ECU 主要功能是替代/增強(qiáng)機(jī)電系統(tǒng)。軟件主要根據(jù)總線的輸入信號控制輸出信號。很多控制軟件在車輛的生命周期內(nèi)不會(huì)有大的變化。
但新的技術(shù)如自動(dòng)駕駛，引入了高度復(fù)雜、對計(jì)算資源要求很高的軟件，且必須嚴(yán)格遵守完整性、安全性要求。這些軟件實(shí)現(xiàn)了環(huán)境感知、行為規(guī)劃、和后端/基建系統(tǒng)集成等功能。在車輛的生命周期內(nèi)，軟件要不斷更新以適配外部系統(tǒng)的更新以及改進(jìn)功能。
CP 標(biāo)準(zhǔn)是針對傳統(tǒng) ECU 需求而提出的，無法滿足上述新型 ECU 的需求，于是 AUTOSAR 推出了新的軟件平臺(tái) AP。
AP 主要提供了：
高性能計(jì)算和通信機(jī)制
靈活的軟件配置以支持 OTA 軟件升級
AP 也可以支持傳統(tǒng)的汽車總線的信號，但不是 AP 標(biāo)準(zhǔn)的重點(diǎn)。
AP 背后的技術(shù)驅(qū)動(dòng)主要是以太網(wǎng)和處理器。
不斷增長的帶寬需求引入了以太網(wǎng)。和傳統(tǒng)車身通信技術(shù)（如 CAN）相比，以太網(wǎng)提供了更高的帶寬和交換網(wǎng)絡(luò)，傳輸長報(bào)文效率更高，支持點(diǎn)對點(diǎn)通信。CP 雖然也支持以太網(wǎng)，但 CP 主要為傳統(tǒng)通信技術(shù)設(shè)計(jì)、優(yōu)化，無法充分利用、發(fā)揮以太網(wǎng)的優(yōu)勢。
譯注：長報(bào)文有效載荷比更大；交換網(wǎng)絡(luò)不同于總線式廣播，點(diǎn)對點(diǎn)傳輸，減少總線沖突，提高傳輸效率。
隨著汽車越來越智能，對處理器性能的要求增長巨大，出現(xiàn)了眾核（manycore，十核到百核）處理器、通用目的GPU、FPGA、專用硬件加速器，較傳統(tǒng) MCU 可以大幅提升性能。CP 原本為單核 MCU 設(shè)計(jì)，雖然支持多核（multicore），但對新型處理器的支持大大超出了 CP 的設(shè)計(jì)。此外，電源效率也日漸重要，尤其是這些智能 ECU。受限于 Pollack 法則，處理器的頻率不可能無限增長，要想提升性能，只能增加核心數(shù)并行計(jì)算。為了取得最佳的電源效率性能/瓦，需要混合用到眾核、協(xié)處理器、GPU、FPGA 及硬件加速器。這被稱為異構(gòu)計(jì)算，已被用于 HPC（High-Performance Computing），當(dāng)然遠(yuǎn)超 CP 的范圍。
Pollack Rule：處理器性能的提升與其復(fù)雜性的平方根成正比。如果一個(gè)處理器的硬件邏輯提高一倍，至多能提高性能40%，而如果采用兩個(gè)簡單的處理器構(gòu)成一個(gè)相同硬件規(guī)模的雙核處理器，則可以獲得70%～80%的性能提升。同時(shí)在面積上也同比縮小。
值得一提的是，處理器被集成到一塊芯片上，通過新的處理器互聯(lián)技術(shù)（如 NoC，Network-on-Chip），處理器之間的通信效率比傳統(tǒng) ECU 間通信提高了幾個(gè)數(shù)量級。處理器性能和通信的提升也促進(jìn)了對新平臺(tái)（AP）的需求。
2.1 和 2.2 節(jié)決定了 AP 的特征。
譯注：C++ 比其他語言性能更好。和 C 相比，C++ 標(biāo)準(zhǔn)庫提供 STL及標(biāo)準(zhǔn)庫算法，可以快速適配新算法，提高開發(fā)效率。
為了支持復(fù)雜的應(yīng)用，同時(shí)在分布式處理和計(jì)算資源分配時(shí)，保證最大靈活性和可擴(kuò)展性，AP 遵循面向服務(wù)的架構(gòu)（SOA）。SOA 基于如下概念：系統(tǒng)由一些列的服務(wù)組成，服務(wù)之間可以相互調(diào)用，應(yīng)用可以根據(jù)需要使用一個(gè)或多個(gè)服務(wù)。一個(gè)服務(wù)可以運(yùn)行在本地 ECU，也可以運(yùn)行在遠(yuǎn)程 ECU 上。不論哪種情況，應(yīng)用程序的代碼都一樣（譯注：通過代理模式實(shí)現(xiàn)）。通信服務(wù)負(fù)責(zé)處理具體通信細(xì)節(jié)，應(yīng)用程序無需關(guān)心。從另一個(gè)角度來看這個(gè)架構(gòu)：分布式計(jì)算，通過消息傳遞的形式來通信。這種消息傳遞、基于通信的架構(gòu)也受益于快速、高帶寬的通信（如以太網(wǎng)）的興起。
分布式計(jì)算本來就是并行的。SOA 中，不同的應(yīng)用使用不同的服務(wù)。眾核以及異構(gòu)計(jì)算所帶來的并行計(jì)算能力，使得實(shí)現(xiàn)內(nèi)在并行性在技術(shù)上成為可能。因此，隨著眾核-異構(gòu)計(jì)算技術(shù)的發(fā)展，AP 在架構(gòu)具有了擴(kuò)展功能和性能的能力。硬件和平臺(tái)接口規(guī)范只是一部分，OS/hypervisor 技術(shù)和開發(fā)工具（如自動(dòng)并行化工具）的發(fā)展也非常重要。這部分將有 AP 供應(yīng)商以及行業(yè)/學(xué)術(shù)生態(tài)系統(tǒng)實(shí)現(xiàn)。AP 也旨在適應(yīng)此類技術(shù)。
沒理由重新發(fā)明輪子，對于規(guī)范（相比于實(shí)現(xiàn)）尤其如此。AP 采取了復(fù)用、適配現(xiàn)有開放標(biāo)準(zhǔn)的策略，以促進(jìn) AP 發(fā)展，并從現(xiàn)有標(biāo)準(zhǔn)的生態(tài)中獲益。因此，AP 規(guī)范的一個(gè)關(guān)鍵就是：不要隨意引入一個(gè)現(xiàn)有標(biāo)準(zhǔn)已有功能的替代。例如，不要因?yàn)楝F(xiàn)有接口表面上不容易理解，就隨意引入新的接口。
AP的目標(biāo)系統(tǒng)通常要求一定的功能/網(wǎng)絡(luò)安全等級（可上至最高等級）。雖然有些困難，新引入的概念和技術(shù)不應(yīng)降低安全方面的要求。
為應(yīng)對挑戰(zhàn)，AP 集合了架構(gòu)、功能、流程方法：
該架構(gòu)基于基于 SOA 的分布式計(jì)算，本質(zhì)上使每個(gè)組件更加獨(dú)立，且不受意外干擾
幫助取得 Safety 和 Security 的專門功能
C++ 編碼規(guī)范，幫助開發(fā)者更安全地使用 C++ 這樣的復(fù)雜語言
AP 支持應(yīng)用的增量部署：動(dòng)態(tài)管理資源和通信，以減少軟件開發(fā)、集成的工作量，從而實(shí)現(xiàn)較短的迭代周期。增量部署還支持探索性軟件開發(fā)階段。
對于產(chǎn)品交付，AP 允許系統(tǒng)集成限制一些行為，以降低不利影響帶來的風(fēng)險(xiǎn)，保證功能安全。應(yīng)用的動(dòng)態(tài)行為可以通過 Execution Manifest 來限制。在執(zhí)行時(shí)，資源和通信路徑的動(dòng)態(tài)分配只能以預(yù)先定義的方式進(jìn)行（例如在配置的范圍內(nèi)）。
特定的 AP 實(shí)現(xiàn)可能從軟件配置中移除動(dòng)態(tài)能力。計(jì)劃動(dòng)態(tài)的例子：
預(yù)先決定服務(wù)發(fā)現(xiàn)
限制啟動(dòng)階段的動(dòng)態(tài)內(nèi)存配分
基于優(yōu)先級的調(diào)度策略之外的公平調(diào)度策略
把進(jìn)程分配到固定的 CPU 核
僅訪問文件系統(tǒng)中預(yù)先存在的文件
限制應(yīng)用使用的 AP API
僅執(zhí)行驗(yàn)證過的代碼
盡管不直接反映在平臺(tái)的功能上，AP 以適應(yīng)不同的開發(fā)流程為目標(biāo)，尤其是基于敏捷的開發(fā)流程。對于敏捷開發(fā)，增量、可擴(kuò)展的潛在架構(gòu)至關(guān)重要：提供了先開發(fā)，再更新的可能性。AP 架構(gòu)應(yīng)當(dāng)支持敏開發(fā)：作為概念驗(yàn)證，AP 的規(guī)范和示例代碼都是基于 Scrum 開發(fā)的。
AP 不會(huì)取代 CP 或非 AUTOSAR 平臺(tái)。相反，AP 和后端系統(tǒng)以及路邊基礎(chǔ)設(shè)施共同協(xié)作，形成一個(gè)完整的系統(tǒng)（如圖）。例如 CP 也支持 SOME/IP。
AP 定義了運(yùn)行時(shí)系統(tǒng)架構(gòu)：平臺(tái)組成、提供的功能和接口。還定義了開發(fā)過程中使用的機(jī)器可讀模型。規(guī)范應(yīng)當(dāng)提供使用平臺(tái)的必要信息以及實(shí)現(xiàn)平臺(tái)的需求。
已獲作者文章轉(zhuǎn)載權(quán)限
參考文獻(xiàn)：
[1] Glossary, AUTOSAR_TR_Glossary.pdf.
[2] Main Requirement, AUTOSAR_RS_Main.pdf.
[3] Methodology for Adaptive Platform, AUTOSAR_TR_AdaptiveMethodology.pdf.
[4] Design guidelines for using parallel processing technologies on Adaptive Platform, AUTOSAR_EXP_ParallelProcessingGuidelines.pdf.
[5] FCDesign IAM, AUTOSAR_EXP_FCDesignIdentityAndAccessManagement.pdf.
[6] P. Kruchten, “Architectural Blueprints—The “4+ 1” View Model of Software Architecture,” IEEE Software, vol. 12, no. 6, pp. 42-50, November 1995.
閱讀原文，關(guān)注作者博客
一文詳解奧迪e-tron內(nèi)部系統(tǒng) |附下載
ID.3 和大眾的電氣化平臺(tái) |附下載
一文詳解CAN總線錯(cuò)誤幀|附下載
DoIP協(xié)議介紹，資料分享！
詳解車載網(wǎng)絡(luò) OTA系統(tǒng)的開發(fā)|文末附下載
一文了解汽車嵌入式AUTOSAR架構(gòu)|附下載
詳解汽車Bootloader設(shè)計(jì)
特斯拉Autopilot系統(tǒng)安全研究|附dbc下載
