AUTOSAR CP從汽車電子的整體開發(fā)視角出發(fā)，解決了多個(gè)ECU開發(fā)的規(guī)范問題，但隨著行業(yè)的快速變化，跨域和域間數(shù)據(jù)傳輸量劇增、軟件復(fù)雜度提升、信息安全等新規(guī)范被引入汽車領(lǐng)域……以上問題已經(jīng)超出了AUTOSAR CP的處理范圍，AUTOSAR AP由此應(yīng)運(yùn)而生。

2023年3月14-16日，2023第四屆軟件定義汽車論壇暨AUTOSAR中國日上，福瑞泰克高級主管工程師猶鑫鑫指出：“AUTOSAR AP正是AUTOSAR組織針對高性能計(jì)算平臺缺乏合適中間件的問題，而推出的一種新型架構(gòu)。它一方面采用面向?qū)ο蟮腟OA架構(gòu)，旨在為上層應(yīng)用提供靈活的軟件開發(fā)平臺；另一方面充分借鑒了前汽車行業(yè)的經(jīng)驗(yàn)和優(yōu)勢，使得汽車軟件能夠在提高質(zhì)量的同時(shí)持續(xù)迭代，實(shí)現(xiàn)快速地量產(chǎn)上車?！?/p>

猶鑫鑫 | 福瑞泰克高級主管工程師

以下是演講內(nèi)容整理：

本次演講主要分三部分：首先會介紹一下AUTOSAR AP的產(chǎn)生和歷史；第二部分是在域控制器部署AUTOSAR AP的優(yōu)勢和挑戰(zhàn)；第三部分是AUTOSAR AP的分布式拓展，針對上述提到的挑戰(zhàn)，我們通過哪些努力對AUTOSAR AP進(jìn)行分布式的拓展。

AUTOSAR AP的產(chǎn)生和歷史

AUTOSAR的產(chǎn)生與汽車電子電氣架構(gòu)的演進(jìn)密不可分。眾所周知，汽車電子電氣架構(gòu)正在從分布式向集中式演進(jìn)，未來總體趨勢是一個(gè)或多個(gè)統(tǒng)一的中央計(jì)算平臺，但目前仍在持續(xù)進(jìn)化?，F(xiàn)在的趨勢是將車輛劃分為幾大域，每個(gè)域有自己的域控制器，以減少ECU數(shù)量。域控制器的出現(xiàn)對軟件提出了更高要求，并對軟件載體——軟件中間件平臺提出了以下挑戰(zhàn)：

一，以太網(wǎng)逐漸成為汽車主干網(wǎng)。隨著域控制器之間數(shù)據(jù)傳輸吞吐量越來越大，延遲要求越來越低，以太網(wǎng)的出現(xiàn)使得AUTOSAR CP傳統(tǒng)協(xié)議棧無法支撐項(xiàng)目開發(fā)。盡管CP協(xié)議棧也支持以太網(wǎng)，但它仍然采用面向信號的傳統(tǒng)通信架構(gòu)，并不能很好地發(fā)揮以太網(wǎng)的優(yōu)勢。

二，隨SOC算力增強(qiáng)，我們會把更多軟件整合到一起。盡管ECU數(shù)量減少了，但軟件復(fù)雜程度在上升。我們不能像過去那樣定義好需求后開發(fā)一套軟件，并一直使用到報(bào)廢——這在現(xiàn)在已經(jīng)不可想象了?，F(xiàn)在軟件的需求包括敏捷開發(fā)、持續(xù)迭代與升級，還要具有良好可移植性和復(fù)用性，這就是面向服務(wù)的SOA架構(gòu)如此火熱的原因。

三，無論軟硬件平臺多么復(fù)雜，在量產(chǎn)時(shí)必須滿足信息安全和功能安全要求，并兼容已有行業(yè)規(guī)范（如時(shí)間同步等功能）。有些非常優(yōu)秀的軟件中間件能靈活支撐自動駕駛軟件開發(fā)，但它們沒有考慮信息安全和功能安全需求，也不是專門為汽車行業(yè)制作的，因此并不適合用于量產(chǎn)。

基于當(dāng)前現(xiàn)狀，AUTOSAR在2017年推出了新的AUTOSAR平臺——俗稱AUTOSAR AP。AUTOSAR AP的出現(xiàn)是為了填補(bǔ)高性能計(jì)算平臺上缺乏好用中間件的空白，采用面向?qū)ο蟮腟OA架構(gòu)，旨在為上層應(yīng)用提供靈活的軟件開發(fā)平臺；同時(shí)利用汽車行業(yè)經(jīng)驗(yàn)和優(yōu)勢，讓所有汽車軟件能持續(xù)迭代，更快更好地量產(chǎn)上車。

自2017年第一個(gè)版本AUTOSAR標(biāo)準(zhǔn)提出至今，已有6年時(shí)間。接下來讓我們談?wù)勗谟蚩刂破魃喜渴餉UTOSAR AP真實(shí)項(xiàng)目中的好處和困難。

域控制器部署AUTOSAR AP的優(yōu)勢和挑戰(zhàn)

福瑞泰克在域控制器開發(fā)方面的經(jīng)驗(yàn)比較豐富，基于福瑞泰克ODIN 1.0平臺有兩款域控制器——ADC15和ADC20去年已量產(chǎn)上車，這些都是小算力域控平臺，支持福瑞泰克自研5V5R/6V5R傳感器，運(yùn)行自研非標(biāo)準(zhǔn)軟件中間件，能實(shí)現(xiàn)高速+泊車行泊一體功能。

今年，福瑞泰克將要推出更高效能的ADC25，并在未來基于福瑞泰克ODIN 2.0的平臺中推出ADC30，ADC30會自研12V5R傳感器，搭配1~3個(gè) Lidar，目標(biāo)是支持L3以上的自動駕駛功能，支持高速+城區(qū)+泊車的高等級的自動駕駛，我們選擇了AUTOSAR AP作為域控中間件的基礎(chǔ)，所以我們對在域控制器上部署AUTOSAR AP的優(yōu)勢和挑戰(zhàn)都有著非常清楚的認(rèn)知，對AUTOSAR AP的能力邊界也有非常深刻的理解。

以下是我基于域控制器真實(shí)項(xiàng)目軟件平臺部署作出的簡化圖。由于單顆SOC算力不足以及安全冗余原因，域控制器ECU通常內(nèi)置多顆SOC用于計(jì)算和性能域，多顆MCU用于安全冗余。在軟件平臺選擇上，MCU部分基本都選擇AUTOSAR CP，這已成為事實(shí)標(biāo)準(zhǔn)。在異構(gòu)SOC內(nèi)部，有傳統(tǒng)計(jì)算核（俗稱A核）和小核心，小核心通常運(yùn)行非AUTOSAR平臺的軟件。

圖片來源：嘉賓演講材料

選擇AUTOSAR AP作為計(jì)算核心上的中間件主要有幾個(gè)優(yōu)勢。首先，它支持C++，能讓我們更快使用新算法，提高應(yīng)用開發(fā)能力和速度。其次，它采用面向服務(wù)的SOA架構(gòu)，SOA架構(gòu)可以提高軟件可移植性。應(yīng)用只關(guān)心使用和提供的服務(wù)，不關(guān)心服務(wù)提供者位置，能極大解耦硬件綁定并提高軟件復(fù)用度。再者，AUTOSAR AP利用現(xiàn)有標(biāo)準(zhǔn)（如UDS診斷、SOME/IP等），工程師無需重新學(xué)習(xí)復(fù)雜理論。此外，AUTOSAR AP在信息安全和功能安全上都有完整方法論、獨(dú)立功能組件和配置工具支持。最后，AUTOSAR AP支持軟件敏捷開發(fā)和持續(xù)迭代，并可以通過OTA能力更新軟件平臺。

以上是AUTOSAR AP部署在域控平臺上的優(yōu)勢，但在真實(shí)項(xiàng)目中，我們也發(fā)現(xiàn)了一些不足和挑戰(zhàn)。

首先是分布式的通信管理問題，AUTOSAR AP通信管理模塊稱為CM模塊，AUTOSAR標(biāo)準(zhǔn)化了兩個(gè)通信綁定（傳輸層）：SOME/IP和DDS，均基于以太網(wǎng)傳輸。例如，在域控制器內(nèi)部兩個(gè)SOC之間通過高速以太網(wǎng)互聯(lián)，此時(shí)AUTOSAR AP能完美發(fā)揮特性，讓兩個(gè)SOC之間的應(yīng)用正常運(yùn)行。但問題在于，并非所有ECU平臺都支持以太網(wǎng)通信。例如，TI的TDA4中有些小核心需要與計(jì)算核心通信，但這部分是不支持以太網(wǎng)的。此時(shí)大部分算法運(yùn)行在計(jì)算核心上，小核心主要負(fù)責(zé)傳感器數(shù)據(jù)采集（如攝像頭和雷達(dá)等），而計(jì)算核心上的應(yīng)用如果需要獲取這些傳感器數(shù)據(jù)，通常需要通過兩種方法。

一種方法是寫一個(gè)轉(zhuǎn)發(fā)APP，通過核間通信獲取傳感器數(shù)據(jù)，信息會通過AP的CM模塊轉(zhuǎn)化進(jìn)入AP體系，這種方法雖然能完成要求，但存在性能問題。因?yàn)槊看无D(zhuǎn)化都會增加一次數(shù)據(jù)拷貝，對數(shù)據(jù)性能影響嚴(yán)重。如果傳輸延遲敏感數(shù)據(jù)（如攝像頭數(shù)據(jù)）或通信數(shù)據(jù)量大，這種方案可能無法滿足項(xiàng)目需求。

第二種方法是計(jì)算域上應(yīng)用不僅使用AP，還額外添加專門用于核間通信的中間件。計(jì)算核與小核心進(jìn)行核間通信時(shí)使用核間通信中間件，與其他支持以太網(wǎng)的SOC通信時(shí)使用AP。這種方法可行且無性能損耗，但會影響軟件可移植性。理論上，只使用AP標(biāo)準(zhǔn)接口的軟件具有強(qiáng)大可移植性，可在多個(gè)項(xiàng)目復(fù)用，但如果引入非標(biāo)準(zhǔn)中間件，軟件將與硬件平臺綁定，原軟件不再可復(fù)用，也不符合SOA架構(gòu)面向服務(wù)的特性。

我認(rèn)為上述方法都不是解決問題的最佳辦法。如果AUTOSAR AP想在復(fù)雜多核異構(gòu)SOC上部署，就必須要支持非以太網(wǎng)通信。

第二個(gè)挑戰(zhàn)是分布式狀態(tài)/執(zhí)行管理。由于ECU功能眾多，域控制大部分功能不能同時(shí)運(yùn)行，否則會造成嚴(yán)重算力損失。AUTOSAR AP通過狀態(tài)管理SM模塊和執(zhí)行管理EM模塊支持此需求。當(dāng)SM檢測到功能組狀態(tài)切換時(shí)，會向EM發(fā)起請求，EM根據(jù)配置決定當(dāng)前狀態(tài)下應(yīng)運(yùn)行哪些進(jìn)程，哪些進(jìn)程被殺死。

標(biāo)準(zhǔn)AUTOSAR AP存在兩個(gè)問題。一是在復(fù)雜多SOC平臺上部署AUTOSAR AP時(shí)，每個(gè)平臺都有自己的SM和EM，每個(gè)SM都有自己的狀態(tài)，且狀態(tài)不互通。若想讓狀態(tài)互通，需要AP用戶編寫大量SM代碼，但這部分代碼并非OEM廠家關(guān)心的內(nèi)容，而是系統(tǒng)軟件的一部分。二是OEM廠家大多沒有功能組的概念，主要關(guān)心的是整車或ECU的狀態(tài)而非功能組狀態(tài)，通常情況下，ECU狀態(tài)與AP體系內(nèi)的功能組狀態(tài)無關(guān)聯(lián)。

第三個(gè)挑戰(zhàn)是分布式日志管理。當(dāng)多個(gè)SOC都有自己需要存儲和傳輸?shù)娜罩緯r(shí)，這一問題就開始變得嚴(yán)重了。假設(shè)一個(gè)ECU內(nèi)有5個(gè)SOC，每個(gè)SOC上都有AP平臺，就可以各自將日志存儲到文件系統(tǒng)或通過網(wǎng)絡(luò)傳輸給外部日志工具。這種情況下，若想訪問整個(gè)ECU的日志，就需分別訪問5個(gè)SOC，對OEM用戶不利。因?yàn)镺EM用戶看到的是整個(gè)ECU，我們提供的也是整個(gè)ECU，但訪問日志時(shí)需單獨(dú)訪問5個(gè)SOC。因此，分平臺自行處理本身日志會破壞ECU的一致性。

第四個(gè)挑戰(zhàn)是分布式升級。AUTOSAR AP對升級提供了很好的支持，UCM模塊是一個(gè)軟件包管理器，通常與DM配合使用，DM支持UDS診斷。當(dāng)升級整個(gè)域控制器ECU時(shí)，由于ECU內(nèi)部有多個(gè)SOC，最簡單的方法是給每個(gè)SOC分配一個(gè)DM診斷地址和各自的UCM模塊，外部升級主控節(jié)點(diǎn)可依次向這些SOC發(fā)起診斷請求、進(jìn)行升級。當(dāng)所有SOC都升級完畢后，ECU也就完成了升級。

這種方案的問題在于，升級主控只關(guān)心ECU的升級，這就需要在外部寫一大段復(fù)雜的邏輯去處理ECU內(nèi)部每個(gè)SOC升級的一致性，如果其中一個(gè)升級成功了，另一個(gè)升級失敗了，這種情況就需要采用外部的升級節(jié)點(diǎn)進(jìn)行額外處理，因此，更好的解決辦法是將ECU升級的邏輯在內(nèi)部處理掉，而不是放到外部去做。

AUTOSAR AP的分布式拓展

剛才談到了真實(shí)項(xiàng)目中部署AUTOSAR AP需要考慮的一些問題，我們下面來講一下針對上述提到的問題，怎么通過分布式拓展來解決它們。

首先，第一個(gè)要解決的是分布式的通信管理問題，得益于AUTOSAR AP CM模塊良好的拓展性，可以支持添加自定義網(wǎng)絡(luò)通信綁定。這樣我們就可以在AUTOSAR AP協(xié)議棧內(nèi)部添加非以太網(wǎng)通信，從而在非AP平臺和AP平臺之間通過物理共享內(nèi)存互聯(lián)互通，在AP協(xié)議棧里面增加物理內(nèi)存綁定的通信方式，實(shí)現(xiàn)核間通信。小核心上發(fā)來的數(shù)據(jù)直接進(jìn)入到CM體系內(nèi)，將來即使傳感器數(shù)據(jù)不是由小核心提供，而是由另外一個(gè)ECU提供，對應(yīng)代碼也不用更改，只需修改配置文件即可完成切換。這樣做既不降低性能，又具有良好可移植性。

第二是分布式狀態(tài)/執(zhí)行管理，拓展的核心是讓所有平臺處于統(tǒng)一的狀態(tài)管理體系下，在ECU狀態(tài)和功能組狀態(tài)之間建立映射。這個(gè)拓展可以選擇主控SOC，在上面部署ECU級別狀態(tài)管理模塊，與各SOC APP平臺或非APP平臺管理應(yīng)用進(jìn)行相互通信。通過ECU狀態(tài)到功能組狀態(tài)的映射完成統(tǒng)一管理，使整個(gè)ECU對外呈現(xiàn)統(tǒng)一狀態(tài)，滿足OEM客戶需求；同時(shí)沒有拋棄傳統(tǒng)AUTOSAR AP中功能組體系。

第三個(gè)拓展是分布式日志管理。想在復(fù)雜的域控制器內(nèi)多SOC上管理日志，可以選擇一個(gè)主控日志管理中心節(jié)點(diǎn)。通過改造AP平臺上的日志后臺進(jìn)程，讓它擁有網(wǎng)關(guān)模式，在收集到來自自己應(yīng)用程序上的日志之后，可以將日志發(fā)送到對應(yīng)的主控節(jié)點(diǎn)上進(jìn)行統(tǒng)一存儲和管理。通過外部工具訪問這些日志時(shí)，也只需要訪問這個(gè)主控節(jié)點(diǎn)，不需要依次訪問每個(gè)SOC。進(jìn)一步來看，小核心上的應(yīng)用也可以通過核間通信方式，將日志收集到AP的日志體系中來。雖然這些小核心不運(yùn)行AUTOSAR平臺，但它們的日志通過AP進(jìn)行統(tǒng)一管理對于應(yīng)用開發(fā)調(diào)試會很有幫助。

最后一個(gè)拓展是支持支持ECU級別的統(tǒng)一升級。這個(gè)拓展的核心要點(diǎn)是在整個(gè)ECU的內(nèi)部構(gòu)建一個(gè)小的UCM Master，讓UCM Master負(fù)責(zé)ECU內(nèi)多個(gè)SOC或多個(gè)MCU的升級。當(dāng)遠(yuǎn)端升級節(jié)點(diǎn)通過診斷把升級請求發(fā)到主控節(jié)點(diǎn)后，主控節(jié)點(diǎn)對外部節(jié)點(diǎn)外來的ECU升級包做信息安全處理，把升級包解壓出來，得到每個(gè)SOC上的升級包，最后調(diào)用每個(gè)SOC中AP平臺的UCM模塊提供的服務(wù)對每個(gè)SOC進(jìn)行升級。如果有升級失敗就可以向外部報(bào)告升級情況，讓整個(gè)ECU的升級狀態(tài)在內(nèi)部完成。

基于以上方案的思路，福瑞泰克基于AUTOSAR AP進(jìn)行了一些拓展，開發(fā)了滿足AUTOSAR AP標(biāo)準(zhǔn)，具備分布式設(shè)計(jì)部署的SOC中間件——福澤FUZE，同時(shí)有配套的工具鏈。

最后談一談我對AUTOSAR AP的未來展望。通過以上的內(nèi)容，大家可以發(fā)現(xiàn)，很多時(shí)候不是AUTOSAR AP的分布式做得不好，而是基于當(dāng)下算力的缺失，ECU功能的繁雜，SoC增多等挑戰(zhàn)，AUTOSAR AP才不得不作一些拓展。在集成式趨勢下，未來ECU內(nèi)部的SOC數(shù)量將會大幅度減少，加上標(biāo)準(zhǔn)的不斷完善，AUTOSAR AP也可以覆蓋中間件開發(fā)的大部分需求。

在這個(gè)前提下，我認(rèn)為AUTOSAR在中國會持續(xù)取得成功，福瑞泰克作為AUTOSAR組織的成員，將持續(xù)利用AUTOSAR AP為我們的客戶提供更好的產(chǎn)品和更好的服務(wù)。

（以上內(nèi)容來自福瑞泰克高級主管工程師猶鑫鑫于2023年3月14日-16日在2023第四屆軟件定義汽車論壇暨AUTOSAR中國日發(fā)表的《基于AUTOSAR AP的多核SOC域控制器的分布式設(shè)計(jì)》主題演講。）

返回第一電動網(wǎng)首頁 >