先提出幾點容易混淆的概念：

       1、什么是軟件平臺

       架構(gòu)，平臺的概念是復(fù)雜且不一致的。為了盡量簡化，以達到在概念上保持一致的目的，把應(yīng)用層拋開后，以下的統(tǒng)稱為軟件平臺，不涉及應(yīng)用相關(guān)的需求，只會將應(yīng)用根據(jù)軟件平臺對應(yīng)用提供的支持進行大致的分類。

       2、模塊化結(jié)構(gòu)性開發(fā)和軟件水平分層的關(guān)系

       軟件的水平分層2/3/5/7...怎么分都好，是一個結(jié)果和目標，真實開發(fā)過程中，無論是出于對軟件團隊的能力要求，還是開發(fā)的可操作性，建議都以模塊化為切入點。

       3、功能性需求和非功能型需求的關(guān)系

       應(yīng)用的迭代是非常敏捷的，和應(yīng)用強相關(guān)的需求都不在平臺考慮范圍。換句話說，平臺需要提煉出非功能強相關(guān)的需求。以及需要注意到一些潛在的新技術(shù)。

       本質(zhì)上非功能需求也是通過功能提煉出來的。

        4、軟件平臺工作量

       軟件平臺的概念很大，且是定制化比較高的。不太存在一步到位給出具體軟件工程需求的可能性，需要專家團隊細化協(xié)作。且任何解法也不是唯一的，只是基于自身遺留客觀情況的取舍。

軟件平臺

      完整的軟件平臺應(yīng)該考慮兩部分組成，即用于車內(nèi)的CarOS和用于云端的架構(gòu)。實際開發(fā)中需要繼續(xù)收斂話題，我們先聚焦車內(nèi)的軟件平臺，并分為兩個軟件模塊：安全模塊和性能模塊。（非精準的類比為CP和AP）

軟件平臺的安全模塊和性能模塊

      Car.OS設(shè)計初衷是用于承載車輛內(nèi)所有類型的應(yīng)用程序。根據(jù)要求和限制，我們將車內(nèi)應(yīng)用分為不同類別，以引導(dǎo)出不同需求的可以承載不同應(yīng)用的軟件平臺模塊：

      1、安全模塊可以支持從QM到ASIL-D的所有控制回路，包括：

• 無安全保證的應(yīng)用。堆棧部署在一個或多個μC上，沒有任何安全保證。

• 在安全認證環(huán)境中運行的安全相關(guān)應(yīng)用程序。堆棧部署在滿足所需安全屬性和功能的一個或多個μC。

      2、性能模塊在基于Linux的操作系統(tǒng)上運行，包括：

• 沒有UI的應(yīng)用程序：應(yīng)用程序可能使用特殊用途的硬件，如GPU。性能模塊承載所有QM軟件，并可以使用分解降級來承載ASIL-B。同時在安全模塊上有一個安全檢查器。

• 需要UI（如信息娛樂或?qū)Ш剑┑膽?yīng)用程序運行在相同的基于Linux的操作系統(tǒng)之上，軟件平臺需要可以承載虛擬化的Android操作系統(tǒng)和信息娛樂堆棧。

軟件平臺/安全模塊

      CarOS中的安全模塊是可以通過一個具有多核支持的Classic AUTOSAR和一個ASIL-D微內(nèi)核的組合實現(xiàn)。Classic AUTOSAR應(yīng)符支持所有軟件組件（SWC）可以依賴RTE作為與其他SWC和車輛網(wǎng)絡(luò)的通用通信中間件。只有該平臺上的應(yīng)用程序才能直接訪問本地現(xiàn)場總線。根據(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保護防止消息損壞和重播錯誤，但使用CAN進行通信。

       安全模塊不存在任何與后端的直接連接。

       需要注意的是，由于技術(shù)和成本原因，Classic AUTOSAR堆棧沒有按照ASIL-D進行開發(fā)。要運行ASIL-D SWCs，在Classic AUTOSAR堆棧旁邊放置另一個ASIL-D安全內(nèi)核，以實現(xiàn)時間、內(nèi)存和CPU的FFI。

     ASIL-D核提供：

•   ASIL-D微內(nèi)核、服務(wù)中斷（ISR）handling, resources, events

•   端到端保護，確保沒有消息被破壞或重復(fù)（消息計數(shù)器、循環(huán)冗余校驗CRC）；安全研究趨勢是Keyed-Hash消息認證碼HMA-C）

•   定時保護，確保關(guān)鍵功能及時執(zhí)行且不會中斷

•   看門狗功能，用于失效安全/失效復(fù)位或監(jiān)控系統(tǒng)其他部分中運行的軟件

•   內(nèi)置自檢（BIST）

      安全模塊需要考慮未來的各種需求，如多核μC的使用效率或復(fù)雜任務(wù)鏈的調(diào)度。

軟件平臺/性能模塊

       HPC由帶加速器的微處理器、附加的小型微控制器單元以及大量的互聯(lián)和外圍設(shè)備組成。這些HPC上運行的性能模塊支持一系列用例，從傳感器融合和AI算法到用戶界面再和云通信或車內(nèi)通信。

       大多數(shù)性能模塊部署目標是Linux。

      未來的AD安全概念需要判斷是否必須將需求分解為ASIL-D=ASIL-B（D）+ASIL-B（D）。解法之一是提供一個支持ASIL-B性能模塊（例如基于QNX），該模塊具有本地ASIL-B支持，以承載具有已部署分解功能的AD功能。例如，兩個ASIL-B檢查程序可以監(jiān)控QM中的第三個ML組件。

      ISO 26262允許的另一種分解是ASIL-D=ASIL-D（D）+QM（D）。這將允許軟件平臺在Linux（QM）中實現(xiàn)性能模塊，但這將需要在安全模塊上實現(xiàn)ASIL-D作為檢查器組件，以達到相同的ASIL總體水平。（依舊回想一下，架構(gòu)設(shè)計和技術(shù)路線的選擇強相關(guān)，在總體設(shè)計之前先羅列技術(shù)點，對設(shè)計是很有幫助的）這將減少由于支持QNX和Linux雙系統(tǒng)而導(dǎo)致的工作，并且不用使用OS抽象層。

      雖然特斯拉使用linux可能不應(yīng)該拿來作為實現(xiàn)安全方案的主要例證，但他們在ADAS中使用Linux降低了工作量應(yīng)該是其中之一個主要原因。

軟件平臺/性能模塊/應(yīng)用模式

 

     基于內(nèi)存分配，性能模塊上的應(yīng)用程序通常以以下方式之一構(gòu)建。

• 全靜態(tài)RAM：應(yīng)用開發(fā)人員設(shè)定不能為了防止內(nèi)存碎片或內(nèi)存不足而產(chǎn)生新的操作。這是嵌入式應(yīng)用程序的可靠默認設(shè)置，即使它們與安全無關(guān)。如果應(yīng)用程序與安全相關(guān)，則必須這樣做。它通常通過完整的代碼生成、基于模型的開發(fā)（Matlab）和復(fù)雜的測量與控制任務(wù)來實現(xiàn)。平臺在開發(fā)和運行時實施這種應(yīng)用程序模式。

• 運行時靜態(tài)RAM，僅在啟動時分配內(nèi)存：此應(yīng)用程序開發(fā)模式允許應(yīng)用程序開發(fā)人員在啟動時從只讀內(nèi)存（ROM）、持久性或文件系統(tǒng)讀取二進制或文本配置，按照定義獲取內(nèi)存，然后在操作期間完全靜態(tài)操作。該模式也用于復(fù)雜的人機界面（HMI），但在安全C-D環(huán)境中禁止使用，因此，安全模塊不支持該模式。

• 動態(tài)內(nèi)存：僅允許在性能模塊、特定護欄內(nèi)以及性能模塊支持的定義限制內(nèi)使用動態(tài)內(nèi)存。應(yīng)用程序需要實施開發(fā)應(yīng)用程序控制接口。

      性能模塊可以定義線程池的使用方式，各種情況包括進程如何與非阻塞的回調(diào)函數(shù)進行同步和異步通信，進程間彼此之間如何通信，以及在整車層面的通信。性能模塊還可以為應(yīng)用程序提供跟蹤和調(diào)試功能。不僅限于純1對1連接，性能模塊還可以使用高效的發(fā)布-訂閱機制。

      此外，計算平臺將提供persistency，以避免閃存在整個生命周期內(nèi)損壞。使用請求時刷新或關(guān)機時刷新等策略，并對babblingidiot進行保障和約束。對persistency設(shè)計了各種約束限制，如考慮每個key的最大數(shù)據(jù)大小以及與出廠重置相關(guān)的軟件更新數(shù)據(jù)遷移。將加密功能與persistency相結(jié)合，可以實現(xiàn)安全的數(shù)據(jù)存儲。循環(huán)冗余校驗（CRC）和默認回退值用于在性能模塊支持健壯的應(yīng)用程序開發(fā)。

軟件平臺/性能模塊/從應(yīng)用到服務(wù)

      分類的模型的多種多樣的，和開發(fā)的工作流工具鏈，和組織架構(gòu)都有關(guān)系，這部分應(yīng)該統(tǒng)一語言然后定制

      再跳躍到軟件平臺之上的應(yīng)用框架說一些前沿的。

      基于一些設(shè)想和對軟件平臺的設(shè)計目標：開發(fā)人員可以高效地構(gòu)建、部署和測試小型、可重用和高質(zhì)量的應(yīng)用程序，這些應(yīng)用程序可以以不同的方式組合，以提供最終用戶可見的功能。（也可以理解為服務(wù)）

      ROS似乎符合提到的許多要求。在不同領(lǐng)域中各種機器人用例重已經(jīng)被反復(fù)驗證，并打下堅實基礎(chǔ)。它提供了開發(fā)人員需要的工具鏈和適當(dāng)?shù)某橄笥脕砗喕_發(fā)。

      ROS并不是OS或者軟件平臺，再次強調(diào)不是一個操作系統(tǒng)或者軟件平臺。它是一個應(yīng)用程序編排框架，主要專注于算法開發(fā)和快速原型制作。正在擴展的方向（1）到小型嵌入式平臺，包括裸機，（2）到硬實時系統(tǒng)，（3）重點關(guān)注生產(chǎn)環(huán)境。

      ROS 2的操作系統(tǒng)旨在符合汽車標準，如ISO 26262，并可達到ASIL-D級別的安全支持。這使得在未來在未來在未來，ROS 2可能成為性能模塊應(yīng)用程序和擴展服務(wù)編程模型的首選。在未來在未來在未來，甚至可能延伸到安全模塊。

      ROS 2可以用DDS標準進行進程間通信。它旨在使用發(fā)布-訂閱模式以及同步和異步RPC風(fēng)格通信的擴展，實現(xiàn)可靠、高性能、互操作、實時、可擴展的數(shù)據(jù)交換。這點和軟件平臺的編排調(diào)度和實時性是息息相關(guān)的。ROS應(yīng)該是一個獨立的子話題。

軟件平臺/性能模塊/基礎(chǔ)服務(wù)

      拉回來，到軟件平臺的基礎(chǔ)服務(wù)。軟件平臺本質(zhì)是提供盡可能豐富，完整的基礎(chǔ)服務(wù)。

      基于庫的概念，不同應(yīng)用程序所需的任何服務(wù)都可能是由平臺的基礎(chǔ)服務(wù)提供。理想情況下，不同車型的基礎(chǔ)服務(wù)是從相同的源代碼創(chuàng)建的。說的是理想情況，非常難實現(xiàn)，并且需求可能本身就是不同的。

      例如以下這些比較有代表性的基礎(chǔ)服務(wù):

• 通信

• 安全相關(guān)的服務(wù)

• Persistency

• Logging

• 能量管理

• 時間服務(wù)

• 診斷

• ......

      AP已經(jīng)提供了一大部分需要的基礎(chǔ)服務(wù)，但按照整車的視角和覆蓋未來的需求并不完整，需要做出相應(yīng)的擴展額定制性的開發(fā)。這部分的工作細化明確后會是軟件平臺（除集成外）的主要工作。系統(tǒng)需求，各類服務(wù)的需求，Software requirement specification，Software architecture specification...再逐一得到明確。

轉(zhuǎn)自汽車電子與軟件