先提出幾點(diǎn)容易混淆的概念：
1、什么是軟件平臺(tái)
架構(gòu)，平臺(tái)的概念是復(fù)雜且不一致的。為了盡量簡(jiǎn)化，以達(dá)到在概念上保持一致的目的，把應(yīng)用層拋開后，以下的統(tǒng)稱為軟件平臺(tái)，不涉及應(yīng)用相關(guān)的需求，只會(huì)將應(yīng)用根據(jù)軟件平臺(tái)對(duì)應(yīng)用提供的支持進(jìn)行大致的分類。
2、模塊化結(jié)構(gòu)性開發(fā)和軟件水平分層的關(guān)系
軟件的水平分層2/3/5/7...怎么分都好，是一個(gè)結(jié)果和目標(biāo)，真實(shí)開發(fā)過程中，無論是出于對(duì)軟件團(tuán)隊(duì)的能力要求，還是開發(fā)的可操作性，建議都以模塊化為切入點(diǎn)。
3、功能性需求和非功能型需求的關(guān)系
應(yīng)用的迭代是非常敏捷的，和應(yīng)用強(qiáng)相關(guān)的需求都不在平臺(tái)考慮范圍。換句話說，平臺(tái)需要提煉出非功能強(qiáng)相關(guān)的需求。以及需要注意到一些潛在的新技術(shù)。
本質(zhì)上非功能需求也是通過功能提煉出來的。
4、軟件平臺(tái)工作量
軟件平臺(tái)的概念很大，且是定制化比較高的。不太存在一步到位給出具體軟件工程需求的可能性，需要專家團(tuán)隊(duì)細(xì)化協(xié)作。且任何解法也不是唯一的，只是基于自身遺留客觀情況的取舍。
軟件平臺(tái)
完整的軟件平臺(tái)應(yīng)該考慮兩部分組成，即用于車內(nèi)的CarOS和用于云端的架構(gòu)。實(shí)際開發(fā)中需要繼續(xù)收斂話題，我們先聚焦車內(nèi)的軟件平臺(tái)，并分為兩個(gè)軟件模塊：安全模塊和性能模塊。（非精準(zhǔn)的類比為CP和AP）
軟件平臺(tái)的安全模塊和性能模塊
Car.OS設(shè)計(jì)初衷是用于承載車輛內(nèi)所有類型的應(yīng)用程序。根據(jù)要求和限制，我們將車內(nèi)應(yīng)用分為不同類別，以引導(dǎo)出不同需求的可以承載不同應(yīng)用的軟件平臺(tái)模塊：
1、安全模塊可以支持從QM到ASIL-D的所有控制回路，包括：
-
無安全保證的應(yīng)用。堆棧部署在一個(gè)或多個(gè)μC上，沒有任何安全保證。
-
在安全認(rèn)證環(huán)境中運(yùn)行的安全相關(guān)應(yīng)用程序。堆棧部署在滿足所需安全屬性和功能的一個(gè)或多個(gè)μC。
2、性能模塊在基于Linux的操作系統(tǒng)上運(yùn)行，包括：
-
沒有UI的應(yīng)用程序：應(yīng)用程序可能使用特殊用途的硬件，如GPU。性能模塊承載所有QM軟件，并可以使用分解降級(jí)來承載ASIL-B。同時(shí)在安全模塊上有一個(gè)安全檢查器。
-
需要UI（如信息娛樂或?qū)Ш剑┑膽?yīng)用程序運(yùn)行在相同的基于Linux的操作系統(tǒng)之上，軟件平臺(tái)需要可以承載虛擬化的Android操作系統(tǒng)和信息娛樂堆棧。
軟件平臺(tái)/安全模塊
CarOS中的安全模塊是可以通過一個(gè)具有多核支持的Classic AUTOSAR和一個(gè)ASIL-D微內(nèi)核的組合實(shí)現(xiàn)。Classic AUTOSAR應(yīng)符支持所有軟件組件（SWC）可以依賴RTE作為與其他SWC和車輛網(wǎng)絡(luò)的通用通信中間件。只有該平臺(tái)上的應(yīng)用程序才能直接訪問本地現(xiàn)場(chǎng)總線。根據(jù)API框架描述（ARXML...）配置網(wǎng)絡(luò)，并生成RTE中的stubs/ skeletons/ slots。
安群模塊需要能夠支持：
-
遵循Classic AUTOSAR的各種QM任務(wù)控制和任務(wù)處理。
-
ASIL-D堆?？杀O(jiān)控ASIL-A/B任務(wù)。安全模塊為應(yīng)用程序開發(fā)人員提供了關(guān)于如何使用這些監(jiān)控的明確指導(dǎo)，例如看門狗等的具體說明。
-
ASIL-D微核上的ASIL-D任務(wù)。ASIL-D堆棧通過E2E保護(hù)防止消息損壞和重播錯(cuò)誤，但使用CAN進(jìn)行通信。
安全模塊不存在任何與后端的直接連接。
需要注意的是，由于技術(shù)和成本原因，Classic AUTOSAR堆棧沒有按照ASIL-D進(jìn)行開發(fā)。要運(yùn)行ASIL-D SWCs，在Classic AUTOSAR堆棧旁邊放置另一個(gè)ASIL-D安全內(nèi)核，以實(shí)現(xiàn)時(shí)間、內(nèi)存和CPU的FFI。
ASIL-D核提供：
-
ASIL-D微內(nèi)核、服務(wù)中斷（ISR）handling, resources, events
-
端到端保護(hù)，確保沒有消息被破壞或重復(fù)（消息計(jì)數(shù)器、循環(huán)冗余校驗(yàn)CRC）；安全研究趨勢(shì)是Keyed-Hash消息認(rèn)證碼HMA-C）
-
定時(shí)保護(hù)，確保關(guān)鍵功能及時(shí)執(zhí)行且不會(huì)中斷
-
看門狗功能，用于失效安全/失效復(fù)位或監(jiān)控系統(tǒng)其他部分中運(yùn)行的軟件
-
內(nèi)置自檢（BIST）
安全模塊需要考慮未來的各種需求，如多核μC的使用效率或復(fù)雜任務(wù)鏈的調(diào)度。
軟件平臺(tái)/性能模塊
HPC由帶加速器的微處理器、附加的小型微控制器單元以及大量的互聯(lián)和外圍設(shè)備組成。這些HPC上運(yùn)行的性能模塊支持一系列用例，從傳感器融合和AI算法到用戶界面再和云通信或車內(nèi)通信。
大多數(shù)性能模塊部署目標(biāo)是Linux。
未來的AD安全概念需要判斷是否必須將需求分解為ASIL-D=ASIL-B（D）+ASIL-B（D）。解法之一是提供一個(gè)支持ASIL-B性能模塊（例如基于QNX），該模塊具有本地ASIL-B支持，以承載具有已部署分解功能的AD功能。例如，兩個(gè)ASIL-B檢查程序可以監(jiān)控QM中的第三個(gè)ML組件。
ISO 26262允許的另一種分解是ASIL-D=ASIL-D（D）+QM（D）。這將允許軟件平臺(tái)在Linux（QM）中實(shí)現(xiàn)性能模塊，但這將需要在安全模塊上實(shí)現(xiàn)ASIL-D作為檢查器組件，以達(dá)到相同的ASIL總體水平。（依舊回想一下，架構(gòu)設(shè)計(jì)和技術(shù)路線的選擇強(qiáng)相關(guān)，在總體設(shè)計(jì)之前先羅列技術(shù)點(diǎn)，對(duì)設(shè)計(jì)是很有幫助的）這將減少由于支持QNX和Linux雙系統(tǒng)而導(dǎo)致的工作，并且不用使用OS抽象層。
雖然特斯拉使用linux可能不應(yīng)該拿來作為實(shí)現(xiàn)安全方案的主要例證，但他們?cè)贏DAS中使用Linux降低了工作量應(yīng)該是其中之一個(gè)主要原因。
軟件平臺(tái)/性能模塊/應(yīng)用模式
基于內(nèi)存分配，性能模塊上的應(yīng)用程序通常以以下方式之一構(gòu)建。
-
全靜態(tài)RAM：應(yīng)用開發(fā)人員設(shè)定不能為了防止內(nèi)存碎片或內(nèi)存不足而產(chǎn)生新的操作。這是嵌入式應(yīng)用程序的可靠默認(rèn)設(shè)置，即使它們與安全無關(guān)。如果應(yīng)用程序與安全相關(guān)，則必須這樣做。它通常通過完整的代碼生成、基于模型的開發(fā)（Matlab）和復(fù)雜的測(cè)量與控制任務(wù)來實(shí)現(xiàn)。平臺(tái)在開發(fā)和運(yùn)行時(shí)實(shí)施這種應(yīng)用程序模式。
-
運(yùn)行時(shí)靜態(tài)RAM，僅在啟動(dòng)時(shí)分配內(nèi)存：此應(yīng)用程序開發(fā)模式允許應(yīng)用程序開發(fā)人員在啟動(dòng)時(shí)從只讀內(nèi)存（ROM）、持久性或文件系統(tǒng)讀取二進(jìn)制或文本配置，按照定義獲取內(nèi)存，然后在操作期間完全靜態(tài)操作。該模式也用于復(fù)雜的人機(jī)界面（HMI），但在安全C-D環(huán)境中禁止使用，因此，安全模塊不支持該模式。
-
動(dòng)態(tài)內(nèi)存：僅允許在性能模塊、特定護(hù)欄內(nèi)以及性能模塊支持的定義限制內(nèi)使用動(dòng)態(tài)內(nèi)存。應(yīng)用程序需要實(shí)施開發(fā)應(yīng)用程序控制接口。
性能模塊可以定義線程池的使用方式，各種情況包括進(jìn)程如何與非阻塞的回調(diào)函數(shù)進(jìn)行同步和異步通信，進(jìn)程間彼此之間如何通信，以及在整車層面的通信。性能模塊還可以為應(yīng)用程序提供跟蹤和調(diào)試功能。不僅限于純1對(duì)1連接，性能模塊還可以使用高效的發(fā)布-訂閱機(jī)制。
此外，計(jì)算平臺(tái)將提供persistency，以避免閃存在整個(gè)生命周期內(nèi)損壞。使用請(qǐng)求時(shí)刷新或關(guān)機(jī)時(shí)刷新等策略，并對(duì)babblingidiot進(jìn)行保障和約束。對(duì)persistency設(shè)計(jì)了各種約束限制，如考慮每個(gè)key的最大數(shù)據(jù)大小以及與出廠重置相關(guān)的軟件更新數(shù)據(jù)遷移。將加密功能與persistency相結(jié)合，可以實(shí)現(xiàn)安全的數(shù)據(jù)存儲(chǔ)。循環(huán)冗余校驗(yàn)（CRC）和默認(rèn)回退值用于在性能模塊支持健壯的應(yīng)用程序開發(fā)。
軟件平臺(tái)/性能模塊/從應(yīng)用到服務(wù)
分類的模型的多種多樣的，和開發(fā)的工作流工具鏈，和組織架構(gòu)都有關(guān)系，這部分應(yīng)該統(tǒng)一語言然后定制
再跳躍到軟件平臺(tái)之上的應(yīng)用框架說一些前沿的。
基于一些設(shè)想和對(duì)軟件平臺(tái)的設(shè)計(jì)目標(biāo)：開發(fā)人員可以高效地構(gòu)建、部署和測(cè)試小型、可重用和高質(zhì)量的應(yīng)用程序，這些應(yīng)用程序可以以不同的方式組合，以提供最終用戶可見的功能。（也可以理解為服務(wù)）
ROS似乎符合提到的許多要求。在不同領(lǐng)域中各種機(jī)器人用例重已經(jīng)被反復(fù)驗(yàn)證，并打下堅(jiān)實(shí)基礎(chǔ)。它提供了開發(fā)人員需要的工具鏈和適當(dāng)?shù)某橄笥脕砗?jiǎn)化開發(fā)。
ROS并不是OS或者軟件平臺(tái)，再次強(qiáng)調(diào)不是一個(gè)操作系統(tǒng)或者軟件平臺(tái)。它是一個(gè)應(yīng)用程序編排框架，主要專注于算法開發(fā)和快速原型制作。正在擴(kuò)展的方向（1）到小型嵌入式平臺(tái)，包括裸機(jī)，（2）到硬實(shí)時(shí)系統(tǒng)，（3）重點(diǎn)關(guān)注生產(chǎn)環(huán)境。
ROS 2的操作系統(tǒng)旨在符合汽車標(biāo)準(zhǔn)，如ISO 26262，并可達(dá)到ASIL-D級(jí)別的安全支持。這使得在未來在未來在未來，ROS 2可能成為性能模塊應(yīng)用程序和擴(kuò)展服務(wù)編程模型的首選。在未來在未來在未來，甚至可能延伸到安全模塊。
ROS 2可以用DDS標(biāo)準(zhǔn)進(jìn)行進(jìn)程間通信。它旨在使用發(fā)布-訂閱模式以及同步和異步RPC風(fēng)格通信的擴(kuò)展，實(shí)現(xiàn)可靠、高性能、互操作、實(shí)時(shí)、可擴(kuò)展的數(shù)據(jù)交換。這點(diǎn)和軟件平臺(tái)的編排調(diào)度和實(shí)時(shí)性是息息相關(guān)的。ROS應(yīng)該是一個(gè)獨(dú)立的子話題。
軟件平臺(tái)/性能模塊/基礎(chǔ)服務(wù)
拉回來，到軟件平臺(tái)的基礎(chǔ)服務(wù)。軟件平臺(tái)本質(zhì)是提供盡可能豐富，完整的基礎(chǔ)服務(wù)。
基于庫的概念，不同應(yīng)用程序所需的任何服務(wù)都可能是由平臺(tái)的基礎(chǔ)服務(wù)提供。理想情況下，不同車型的基礎(chǔ)服務(wù)是從相同的源代碼創(chuàng)建的。說的是理想情況，非常難實(shí)現(xiàn)，并且需求可能本身就是不同的。
例如以下這些比較有代表性的基礎(chǔ)服務(wù):
-
通信
-
安全相關(guān)的服務(wù)
-
Persistency
-
Logging
-
能量管理
-
時(shí)間服務(wù)
-
診斷
-
......
AP已經(jīng)提供了一大部分需要的基礎(chǔ)服務(wù)，但按照整車的視角和覆蓋未來的需求并不完整，需要做出相應(yīng)的擴(kuò)展額定制性的開發(fā)。這部分的工作細(xì)化明確后會(huì)是軟件平臺(tái)（除集成外）的主要工作。系統(tǒng)需求，各類服務(wù)的需求，Software requirement specification，Software architecture specification...再逐一得到明確。
轉(zhuǎn)自汽車電子與軟件
