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