基于AP AUTOSAR实现功能安全岛

文章来源：汽车电子与软件发布时间：2021-07-14

分享到

AP 标准在经过几年的进化后，渐渐有了越来越多的量产项目。其中，作者观察到AP的一个重要使用场景为实现功能安全岛。

一、背景

在传统的硬件架构下，一般是一个MPU搭配一个从芯片MCU。MPU上运行需要高算力的应用，而且MCU侧于车内总线(比如CAN)。功能安全的应用部署在MCU侧，软件栈比如选用CP AUTOSAR。

传统MPU加从芯片MCU的硬件架构

在这个架构下，受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等级。

二、底座 - 满足功能安全的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标准里定义了应用至少需有如下依赖关系。

AP应用的依赖关系（出自Vector）

目前业界的现状为顶级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部分的运行效率。

三、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等级的。但是其和具体项目的上下文强相关，无法通用性的展开讨论。

四、总结

在向集中式EE架构的演进过程中，肯定越来越多需要得在MPU侧实现功能安全。目前比较多的国际Tier-1采用AP AUTOSAR在MPU侧来实现功能安全岛。值得各位同行注意的是，要实现此架构，safety应用需要整个软件栈支持，从底层OS，标准库，POSIX库，BSP，到AP协议栈。他们缺一不可。目前就AP协议栈本身来讲，已经有商用解决方案提供ASIL-D等级的EM和PHM。