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