AP 標準在經(jīng)過幾年的進化后，漸漸有了越來越多的量產(chǎn)項目。其中，作者觀察到AP的一個重要使用場景為實現(xiàn)功能安全島。
1
背景
在傳統(tǒng)的硬件架構(gòu)下，一般是一個MPU搭配一個從芯片MCU。MPU上運行需要高算力的應(yīng)用，而且MCU側(cè)于車內(nèi)總線(比如CAN)。功能安全的應(yīng)用部署在MCU側(cè)，軟件棧比如選用CP AUTOSAR。
在這個架構(gòu)下，受MCU算力限制，CP側(cè)無法對高算力的MPU做細顆粒的監(jiān)控。目前很多量產(chǎn)項目用到AP AUTOSAR的主要原因是在MPU上實現(xiàn)功能安全島。最近有好幾個ADAS項目采用如下軟件架構(gòu)：
這樣的架構(gòu)主要使用在高性能ADAS控制器上。在Linux VM側(cè)，部署各種開源機器學(xué)習(xí)框架和ADAS算法。算法工程師能夠從廣大Linux軟件生態(tài)中獲益。常見的機器學(xué)習(xí)框架，算法庫等等都在Linux上有移植。受限于Linux實現(xiàn)功能安全能力，所有的項目都把跟功能安全相關(guān)部分放在AUTOSAR側(cè)。AP AUTOSAR側(cè)一般實現(xiàn)safety應(yīng)用：
-
系統(tǒng)失效后的緊急運行功能或降級功能
-
備份功能滿足Fail-operational的安全策略。
-
實現(xiàn)不同算法監(jiān)控比對Linux VM側(cè)結(jié)果實現(xiàn)算法級冗余。
當然，也有RTOS廠商移植了部分框架。比如opencv等。在這種情況下，可以省去Hypervisor和Linux部分，大大降低開發(fā)集成難度。如果Safety應(yīng)用要滿足ASIL等級，那么其下底下AP AUTOSAR協(xié)議棧，RTOS，Hypervisor，和重要的庫和系統(tǒng)服務(wù)也必須滿足ASIL等級。
2
底座 - 滿足功能安全的RTOS/Hypervisor和工具
為了滿足功能安全架構(gòu)，目前業(yè)界主流的方案采用微內(nèi)核架構(gòu)的RTOS。
和LInux這樣的宏內(nèi)核架構(gòu)不同的是，微內(nèi)核架構(gòu)RTOS的內(nèi)核只有最基本的系統(tǒng)服務(wù)，比如IPC，調(diào)度，內(nèi)存管理。其他的所有服務(wù)和應(yīng)用都屬于用戶態(tài)。包括基礎(chǔ)服務(wù)，比如文件系統(tǒng)，網(wǎng)絡(luò)協(xié)議棧，板級支持包BSP，POSIX中間件。任何用戶態(tài)的應(yīng)用，系統(tǒng)服務(wù)或者外圍驅(qū)動宕掉，內(nèi)核仍然可以繼續(xù)運行。內(nèi)核對應(yīng)的恢復(fù)機制，比如重啟對應(yīng)的服務(wù)。從信息安全角度，對于網(wǎng)絡(luò)協(xié)議棧這樣復(fù)雜度的子系統(tǒng)來說，其存在信息安全弱點是不可避免的。如果在宏內(nèi)核架構(gòu)下，一旦處在內(nèi)核態(tài)的網(wǎng)絡(luò)協(xié)議棧被攻破，整個內(nèi)核進而整個系統(tǒng)將有被攻擊者挾持的風(fēng)險。除了將大部分服務(wù)移出到用戶態(tài)，RTOS內(nèi)核能做到對不同服務(wù)和應(yīng)用之間的完全隔離。
隔離的范圍包括：CPU時間片，內(nèi)存，外圍設(shè)備訪問，總線占用。這樣，從功能安全的角度達到：
-
故障的隔離(Fault isolation)；
-
功能之間互不影響 (Interference-free)。
從軟件架構(gòu)設(shè)計的角度，ASIL功能只是系統(tǒng)占比很小的的一部分。如果其能與其他QM等級的應(yīng)用隔離開來，那么只有很少的一部分代碼需要做ASIL認證。這樣ASIL的工作量會大大減少。按照作者所在公司測算，與開發(fā)同樣的QM功能相比，符合ASIL-A等級的開發(fā)需要花費大概3倍的工作量。更進一步，不同ASIL等級的應(yīng)用能夠在同一系統(tǒng)中共存，實現(xiàn)Mixed Criticality系統(tǒng)。信息安全架構(gòu)也能很好得益于模塊之間的完全隔離。因為，高安全等級模塊能夠和低安全等級模塊之間隔離開來。這也就是TEE (Trusted Execution Environment)的設(shè)計概念。目前頂級的商用微內(nèi)核RTOS內(nèi)核部分能滿足ASIL-D等級。除了RTOS內(nèi)核需要滿足ASIL等級之外，從軟件平臺的角度POSIX PSE51的庫也必須滿足ASIL要求。因為如果一個AP AUTOSAR的應(yīng)用有ASIL要求，其依賴的所有庫都必須滿足ASIL。其中最重要的是POSIX PSE51。AP標準里定義了應(yīng)用至少需有如下依賴關(guān)系。
目前業(yè)界的現(xiàn)狀為頂級RTOS供應(yīng)商能提供滿足ASIL等級的POSIX PSE51庫。但是，還沒有廠商號稱POSIX PSE53/54的庫也通過了ASIL認證。然后是滿足功能安全的文件系統(tǒng)。值得注意的是，C和C++標準庫提供文件操作接口，比如，C++ fstream。目前有RTOS供應(yīng)商提供滿足ASIL功能的文件系統(tǒng)。經(jīng)常容易被忽略的一點，開發(fā)ASIL Safety應(yīng)用使用的編譯器也必須滿足ASIL要求。兩個方面，第一，如果編譯器不滿足ASIL要求，那么其生成的機器代碼無法保證和源代碼的對應(yīng)關(guān)系。那么對于源代碼的認證并無法保證機器代碼的可靠性。第二，如上圖的應(yīng)用依賴關(guān)系所示，C/C++標準庫也使用在了ASIL safety應(yīng)用中。那么與編譯器配套的C/C++的標準庫也必須通過ASIL認證。目前業(yè)界的最新情況來，C99和C++11大部分能允許在Safety應(yīng)用里使用。還無法達到認證C++14的標準庫。最后聊一下Hypervisor。和傳統(tǒng)Type-1 Hypervior不一樣的是，最優(yōu)的Hypervisor方案和RTOS是一體的。
也就是說AP AUTOSAR能直接在Hypervisor上面運行，而不是通過虛擬化一個RTOS之后，再在上面運行AP AUTOSAR。這樣最大的好處是減少了一次上下文切換，提高的AP AUTOSAR部分的運行效率。
3
AP AUTOSAR功能安全
整個AP AUTOSAR協(xié)議棧的體量非常大。要想整體通過ASIL作者認為可能性不大。在這里作者想特別提醒：一個號稱有ASIL-D證書的產(chǎn)品并不能代表產(chǎn)品有多高的功能安全能力。這可能是業(yè)界經(jīng)常用來marketing的一個手段。ASIL-D最多表明了產(chǎn)品開發(fā)符合了ASIL-D流程。其他任何也說明不了。真正能夠能代表一個產(chǎn)品功能安全能力的，一定需要查看產(chǎn)品的功能安全手冊。功能安全手冊的重要性作者無法更多的強調(diào)，上面應(yīng)該解釋了：產(chǎn)品考慮了哪些故障場景，哪些功能允許或不允許在在安全應(yīng)用里使用，在使用某個功能或者接口的時候必須滿足怎么的條件和限制。目前AP協(xié)議棧在RTOS的實現(xiàn)如下圖。
像EM，PHM，COM，PM, DM，UCM這樣功能模塊都是以獨立的進程在系統(tǒng)中出現(xiàn)。值得注意的是，每個模塊完全包含了所有依賴的庫，就像每個模塊運行在獨立的容器里。這方便每個模塊的獨立部署和升級。一般來講Platform Health Management (PHM)模塊必須符合ASIL，其ASIL等級必須和系統(tǒng)最高級別safety應(yīng)用的等級相當。目前已經(jīng)有滿足ASIL-D的PHM模塊。內(nèi)容包括：
-
健康監(jiān)控：檢查應(yīng)用是否正常運行，是否異常退出或者處在suspend狀態(tài)不會被OS調(diào)度。
-
Deadline監(jiān)控：檢查應(yīng)用是否在規(guī)定時間完成。
-
程序流監(jiān)控：檢查應(yīng)用是否在規(guī)定時間內(nèi)執(zhí)行配置好的的檢查點(checkpoint)。
-
其他系統(tǒng)監(jiān)控：OS內(nèi)核運行狀態(tài)，RAM校驗值，電壓，等等和平臺細節(jié)相關(guān)的參數(shù)。
第二重要的功能安全模塊為EM(Execution Management), EM模塊必須符合ASIL等級，其ASIL等級必須和系統(tǒng)最高級別safety應(yīng)用的等級相當。目前已經(jīng)有滿足ASIL-D的EM模塊。內(nèi)容包括：
-
安全初始化：和RTOS一起，保證如果safety應(yīng)用需要被EM啟動，所有需要的硬件資源都可用。這里包括了CPU時間片和內(nèi)存等。作者的經(jīng)驗是實現(xiàn)了ASIL等級的posix_spawn API。
-
可靠運行：主要使用軟件Lock-step框架，實現(xiàn)在規(guī)定時間內(nèi)執(zhí)行好預(yù)設(shè)應(yīng)用并且比對結(jié)果。參看EM的Deterministic Client部分。
-
可靠調(diào)度：和RTOS一起，當safety應(yīng)用被EM啟動之后, 在運行過程中需保證分配的CPU時間片不受其他應(yīng)用影響。
-
可靠退出：和RTOS一起，當safety應(yīng)用被(如果被SM)請求退出時，所有的有依賴關(guān)系的應(yīng)用按配置的順序正常退出，而且不會出現(xiàn)系統(tǒng)異常。
順便簡短提下CM(Communication Management)和SM(State Management)的功能安全實現(xiàn)。CM模塊代碼量相當大。作者的個人觀點是無法達到ASIL等級。目前在具體項目主要是中搭配使用E2E保護。SM一般來講也是達到ASIL等級的。但是其和具體項目的上下文強相關(guān)，無法通用性的展開討論。
轉(zhuǎn)載汽車電子相關(guān)文章
轉(zhuǎn)自汽車電子與軟件
