車載基礎(chǔ)軟件——AUTOSAR AP技術(shù)形態(tài)

我是穿拖鞋的漢子,！

今天是2023年2月11日,，時(shí)間好快，疫情解封已好幾個(gè)月,，生活節(jié)奏也在逐漸恢復(fù)到三年前的節(jié)奏,。可能是感覺疫情與自己距離變遠(yuǎn)了,，大家也開始慢慢的不再恐懼,！

老規(guī)矩分享一段喜歡的文字，避免自己成為高知識(shí)低文化的工科男：

“

我們都太迷戀結(jié)尾,！這個(gè)世界有那么多偉大的生命和美好的愛可以見證和體驗(yàn),，但只要結(jié)果不盡如人意，我們立刻覺得這個(gè)是悲劇,。或者正好相反,，只要結(jié)局有一刻的救贖,，一生的不公和痛苦都可以忽略不計(jì)。他媽的,，都是狗屁,！

”

Return to today's topic!

汽車電子行業(yè)在新四化：

-> 電動(dòng)化;

-> 網(wǎng)聯(lián)化;

-> 智能化;

-> 共享化.

等上述需求變革驅(qū)使下，汽車軟件系統(tǒng)變得更加靈活,。汽車軟件既要安全又要可持續(xù)更新以反映新的功能特性或法規(guī)要求,，為此需要新架構(gòu)支持軟件組件的動(dòng)態(tài)部署以及與非車載系統(tǒng)之間的交互。

今天的汽車 E/E 架構(gòu)可劃分為信息娛樂,、底盤,、自動(dòng)駕駛域和車身控制等不同域：

-> 信息娛樂系統(tǒng)通常使用 Linux 或商業(yè)化的通用操作系統(tǒng)（安卓）；

-> 車身控制則使用標(biāo)準(zhǔn)的 AUTOSAR CP,。

隨著未來新技術(shù)及深度嵌入式系統(tǒng)對(duì)計(jì)算能力需求的不斷增長,，急需第三種控制器——域控制器，用于集成特定領(lǐng)域的功能特性（如車輛動(dòng)力域,、車身域等 ),，形成域集中或跨域集中式電子電氣架構(gòu)。

在未來,，隨著汽車電子及軟件功能的大幅增長,，E/E 架構(gòu)最終可能向基于中央計(jì)算平臺(tái)的整車集中式電子電氣架構(gòu)，以及車云協(xié)同控制發(fā)展,。在這種趨勢(shì)下,，需要高度靈活,、高性能且支持 HPC、動(dòng)態(tài)通信等特性的新軟件架構(gòu)平臺(tái)——Adaptive Platform AUTOSAR 平臺(tái)（下文簡稱 AUTOSAR AP）,。

一,、軟件分層架構(gòu)

典型的域控軟件架構(gòu)如下圖所示，整體可被分為四層,，即操作系統(tǒng)層,、基礎(chǔ)平臺(tái)層、原子服務(wù)層,、應(yīng)用組合服務(wù)層,。

AUTOSAR AP 在基礎(chǔ)平臺(tái)層，這一層包含了 AUTOSAR AP,、AUTOSAR CP,、專用基礎(chǔ)功能等，主要為整車提供基礎(chǔ)運(yùn)行環(huán)境,。

原子服務(wù)層是實(shí)現(xiàn)數(shù)據(jù)融合和控制邏輯的功能模塊,，作為服務(wù)的最小單位與單一執(zhí)行實(shí)體，通過 API為應(yīng)用提供可按需編排的基礎(chǔ)服務(wù),，實(shí)現(xiàn)一次開發(fā)多次復(fù)用,，最大化提升開發(fā)效率。該層的設(shè)計(jì)目標(biāo)是原子服務(wù)與平臺(tái)解耦,，提升軟件復(fù)用性,。

應(yīng)用層基于原子服務(wù)實(shí)現(xiàn)對(duì)整車服務(wù)、應(yīng)用,、體驗(yàn)等進(jìn)行定義和組合增強(qiáng),，構(gòu)建差異化競(jìng)爭(zhēng)力的業(yè)務(wù)應(yīng)用，體現(xiàn)千車千面,。

AUTOSAR AP在域控軟件架構(gòu)中位于中間件的位置,，通過服務(wù)和API為上層服務(wù)提供功能，如圖

所示,。

在 Non-AUTOSAR 環(huán)境中,，系統(tǒng)已經(jīng)實(shí)現(xiàn)了部分 AUTOSAR AP 標(biāo)準(zhǔn)組件，只需要實(shí)現(xiàn)剩余部分組件即可滿足 AUTOSAR AP 的標(biāo)準(zhǔn),。比如在 Android Automotive OS 中,，軟件框架提供了進(jìn)程管理、執(zhí)行管理,、Log,、加密、生命周期管理等功能,，基礎(chǔ)軟件供應(yīng)商實(shí)現(xiàn)通信管理,、診斷,、升級(jí)、網(wǎng)絡(luò)管理等功能,，即可滿足 AUTOSAR AP 的標(biāo)準(zhǔn),。

二、工具鏈

基于自適應(yīng)平臺(tái)的應(yīng)用程序開發(fā)一般要經(jīng)歷三個(gè)階段,，分別是設(shè)計(jì)建模階段,、軟件開發(fā)階段,、集成部署階段，為了更好地支撐這三個(gè)階段的活動(dòng)，AP 工具鏈具備以下能力：

-> 設(shè)計(jì)建模階段使用建模工具,，用于生成 ARXML,，完成 Adaptive Application,、Service Instance,、Executable、Machine 等設(shè)計(jì)開發(fā),，配置 SWC（Software Component）相關(guān)配置項(xiàng),，完成 SWC端口及框架設(shè)計(jì) , 最終導(dǎo)出 AP 平臺(tái)的 ARXML 文件。產(chǎn)品工具應(yīng)具備支持導(dǎo)入導(dǎo)出,、解析,、編輯ARXML 文件的能力。

-> 軟件開發(fā)階段：使用 AP 產(chǎn)品生成工具,，用于實(shí)現(xiàn)組件 API 代碼及 Manifest 配置文件的生成。輸入是標(biāo)準(zhǔn)的 ARXML 文件,，生成源代碼和 Manifest 配置文件,，另外需要包含應(yīng)用層的代碼編輯器和代碼庫管理，實(shí)現(xiàn)源碼編輯,，編譯鏈文件編寫,，代碼庫同步等功能。

-> 集成部署階段：使用集成編譯調(diào)試以及部署工具,，包含編譯工具,、可視化調(diào)試工具、部署工具,、資源監(jiān)控等工具,，支持編譯、調(diào)試,、部署等功能,。

三、開發(fā)方法論

為了支持 AP 平臺(tái)下應(yīng)用程序獨(dú)立,、敏捷,、分布式的開發(fā),，需要在開發(fā)方法論上有一套標(biāo)準(zhǔn)化的方法。AUTOSAR AP 開發(fā)方法論涉及工作產(chǎn)品的標(biāo)準(zhǔn)化,，用于描述工作產(chǎn)品（如服務(wù),、應(yīng)用程序、機(jī)器及其配置）,、工作產(chǎn)品應(yīng)如何交互,、以實(shí)現(xiàn)自適應(yīng)平臺(tái)產(chǎn)品開發(fā)過程中不同角色之間所需的信息交換。如下圖簡要展示了 AP 平臺(tái)的開發(fā)工作流,，總體來說需要經(jīng)歷三個(gè)階段七個(gè)步驟,，最終將開發(fā)的軟件集成入車輛中。

（1）,、架構(gòu)設(shè)計(jì)階段

服務(wù)接口設(shè)計(jì)（Define Services）：主要是定義服務(wù)接口及數(shù)據(jù)類型,，包括定義服務(wù)所包含的method、event,、field,、trigger 等通信元素以及數(shù)據(jù)類型詳細(xì)說明等；

機(jī)器配置設(shè)計(jì)（Configure Machine）：定義和配置機(jī)器的網(wǎng)絡(luò)通信屬性,，包含網(wǎng)絡(luò)連接配置,，服務(wù)發(fā)現(xiàn)配置等信息；

（2）,、軟件開發(fā)階段

定義與配置可執(zhí)行實(shí)例及通信方式,，定義可執(zhí)行實(shí)例如何訪問軟件集；

定義軟件集群所提供的服務(wù)實(shí)例,、配置服務(wù)實(shí)例和可執(zhí)行實(shí)例的映射,；

服務(wù)實(shí)例接口框架源碼生成；軟件集群源碼開發(fā)及測(cè)試等,；

（3）,、集成與部署階段

軟件集群集成 (Integrate Software)：配置可執(zhí)行實(shí)例和進(jìn)程的映射、定義和配置應(yīng)用程序配置清單,、定義和配置服務(wù)實(shí)例部署信息,；

ECU 集成 (ECU(Machine) Integrate)，定義應(yīng)用程序執(zhí)行清單 (Execution Manifest),、定義平臺(tái)程序的配置清單,、診斷和進(jìn)程之間的映射配置；

四,、AP與CP比較

兩個(gè)軟件架構(gòu)主要有如下區(qū)分：

1,、架構(gòu)設(shè)計(jì)原則不同

CP AUTOSAR架構(gòu)設(shè)計(jì)原則為：

1、CP AUTOSAR將于硬件相關(guān)的以及通用系統(tǒng)功能定義為BSW模塊

2、應(yīng)用功能定義為獨(dú)立的軟件組件SWC

3,、RTE分離SWC和BSW

4,、BSW可配置，并且可以被多個(gè)產(chǎn)品線的ECU重復(fù)使用

5,、不開源

AP AUTOSAR架構(gòu)設(shè)計(jì)原則為：

1,、遵循面向服務(wù)的架構(gòu)SOA設(shè)計(jì)范式（理念）

2、充分利用其他領(lǐng)域軟件成熟技術(shù),，重用軟件市場(chǎng)成熟組件,，縮短開發(fā)周期

3、充分利用各種開源軟件

2,、通信方式

CP AUTOSAR是基于信號(hào)的通信,，主要包括CAN、Lin,、FlexRay等,。

AP AUTOSAR是面向服務(wù)的通信，支持基于以太網(wǎng)的SOME/IP,、IPC,、DDS、RPC等,。

CP AUTOSAR雖然可以支持SOME/IP,，但是CP AUTOSAR中SOME/IP只不過是把Sender-Receiver的CAN通信轉(zhuǎn)換成了Client-Server的以太網(wǎng)通信，整個(gè)通信鏈路仍是靜態(tài)配置的,，并不是真正的面向服務(wù)的通信,。

這也是為什么AUTOSAR官方說AP AUTOSAR是SOA，但從來不會(huì)說CP AUTOSAR是SOA,。

3,、芯片需求

CP AUTOSAR一般運(yùn)行在8bit、16bit,、32bit的微控制器（MCU）中,，如英飛凌的TC3xx,，瑞薩的RH850等,。

AP AUTOSAR可以運(yùn)行在64bit的高性能處理器（MPU）、CPU等中,，如瑞薩的H3,，英偉達(dá)的Xavier等。除此之外,，AP AUTOSAR也可以運(yùn)行在虛擬硬件上,。

PS：有些公司可能會(huì)將某種POSIX OS移植到如TC3xx中，進(jìn)而在TC3xx中使用AP,，這種例子很少見,，且不推薦,，所以這里不做細(xì)究。

運(yùn)行CP AUTOSAR 的芯片算力一般低于1000 DMIPs

AP AUTOSAR可以運(yùn)行在算力高于20000 DMIPs的芯片上

這里的算力是指邏輯算力DMIPs,，還有另一種TOPS,，一般是指AI芯片的指標(biāo)，一般是指矩陣運(yùn)算算力,。

擱筆打停,！

愿你我相信時(shí)間的力量，

做一個(gè)長期主義者,！