由盖世汽车、AUTOSAR组织、上海车展三方联合主办的SDVF2021第二届软件定义汽车高峰论坛暨AUTOSAR2021中国日于4月19-21日在上海举办，本次活动也是2021上海车展的同期活动之一，同时也是AUTOSAR组织在中国区唯一官方会议。本次会议邀请到了维克多汽车技术（上海）有限公司商业开发经理曲越先生在本次论坛进行了题为《基于AUTOSAR的功能安全解决方案》的主题演讲，以下是他在本次演讲的主要内容：

大家下午好，我是维克多商业开发经理曲越，这几天有非常多嘉宾和专家分享了一些比较宏观的主题，非常的硬核。而今天我们带来的是具体的解决方案，AUTOSAR下的功能安全解决方案。今天的演讲主要分为四个部分：第一部分，解释一下功能安全相关的概念。第二和第三部分详细介绍维克多针对Classic AUTOSAR和Adaptive AUTOSAR的功能安全解决方案。最后第四部分同样是趋势性的内容，详细介绍Fail-Operational系统中，安全架构设计所面临的挑战。

ISO26262规范于2011年推出，2018年更新，其中详细描述了汽车电子系统安全相关的概念。目的是在现有的技术层面，尽可能地降低汽车电子系统所带来的风险。

什么是功能安全？首先，这里需要区分一下我们经常提及的Safety 和 Security。Functional safety目的是防止由EE系统造成的意外的、不可预估的风险，这些风险可能会造成人身造成伤害。而Cyber Security 目的是防止黑客对系统的攻击，这种风险是种人为的主动因素，是可预测的。总结来看，Safety保护的主体是人身安全，而Security保护的主体是财产也就是汽车系统本身，那么实际归根结底还是会回到人身安全。

ISO26262提出了FFI原则，Freedom from Interference。指的是，不同安全等级的模块之间，故障产生的相互影响必须避免，也就是要防止级联性故障。比如，一个ASIL A的模块，原本来说自身的故障影响比较低，但如果ASIL A模块自身故障影响了其他ASIL D的高风险模块而导致了级联性故障，那这个高风险模块评估为ASIL D就失去意义。

故障方面，分为系统性故障和随机故障。随机故障通常发生在硬件方面，对于随机故障当前已经有很多不同的数学模型可供使用以评估硬件的安全性。这不多做讨论。而软件方面一般会产生的是系统性故障，由一些特定的人为因素引起。系统性故障是可以被检测到的。但是，当前为系统性故障建立数学模型的所有尝试都没有成功，也就意味着比较难以预测。所以要避免系统性故障，需要从开发流程方面下手。

软件方面的系统性故障一般分为三个方面：内存方面的故障，比如野指针，堆栈溢出，变量的写入越界等等。时间上的故障，比如死循环，过高频率的中断，还有由于一些不正常的输入导致的计算时间过长等。通讯故障，最典型的比如报文丢失、重复、损坏以及延迟等等。

接下来，我们分别来探讨Classic AUTOSAR以及Adaptive AUTOSAR的功能安全解决方案中，对于这些故障的检测和处理措施。

首先介绍一下Classic AUTOSAR功能安全解决方案。Vector对于AUTOSAR的解决方案统称为MICROSAR，功能安全解决方案主要分为图中的五个部分。

SafeOS需要提供Memory Protection，配合硬件提供的MPU (Memory Protection Unit) 来实现内存保护，目的是达到FFI原则。SafeRTE除RTE的基本功能外，能够提供ECU内部不同ASIL等级之间的交互，并保障交互的安全性，目的也是达到FFI要求。SafeWDG用于监测代码执行时间以及代码执行顺序等错误，目的是防止代码跑飞。SafeE2E用来检测刚刚提到的通讯方面的诸多问题。SafeBSW，除了刚刚我们提及的模块以外，SafeBSW是其他所有底层模块的统称，整体使用SafeBSW可以提高系统性能，后面会介绍在技术方面，SafeBSW的选择依据。除此以外，SafeBSW中的很多模块还提供一些额外的安全特性，比如使用安全ECUM进行正确的初始化过程，使用NvM安全读写非易失内存的数据，保护数据存储的一致性等等。

接下来我们分别来看，首先是SafeOS部分，除了OS代码本身需要达到ASIL-D以外，AUTOSAR定义了四个OS等级，能供提供额外的安全机制。

SC1是基础OSEK OS + Schedule Table。SC2在SC1基础上添加了Timing Protection功能，可以预先规划Task和二类中断的时间预算来进行监测，超出时间预算的代码将会跑进OS Protection Hook中，让用户自定义代码处理。SC3在SC1基础上添加了Memory Protection功能，也就是配合MPU做内存保护。出于成本考虑，功能安全项目通常是混合ASIL等级的情况，基本都是需要SC3以上等级的OS。SC4相当于SC2+SC3，既有内存保护也有时间保护。

当然，Vector提供的所有等级的SafeOS都可支持单核或者多核的使用场景。

Safe WDG。 AUTOSAR看门狗架构如这张图所示，看门狗以CheckPoint为单位进行监测，也就是代码中嵌入的监测点。WdgM能够提供三种监测方式：Deadline Monitoring，定义时间预算，监测两个check point之间的时间是否超出预算。Alive monitoring，定义的是执行次数，监测特定时间段中，达到checkpoint的次数是否在预算范围内。比如定义某个checkpoint需要在100ms时间内，要运行2-3次，如果超出或者没达到该次数，则认为监测失败，引起复位。Logic monitoring程序流监控比较复杂，定义的是程序跳转轨迹。比如定义从checkpoint1只能跳到2和3，如果跳到4，就认为监测失败，引起复位。

通常在混合安全等级系统中，可以根据不同安全等级来定义不同的监测实体，然后针对不同的监测实体使用不同的监测方式，以这么一种组合的形式对系统整体进行监测。

SafeE2E方面，AUTOSAR定义了诸多E2E Profile类型，Vector所提供的E2E lib现在直接包含了所有AUTOSAR标准的Profile类型以供用户自行选用。对于一些OEM定义的特殊Profile可以单独提供。

Safe RTE，除了RTE最基本的功能以外，还要提供不同安全等级模块的交互。使用过AUTOSAR的观众都知道，维克多作为基础软件供应商，通常提供的代码包分几个部分，一部分是静态代码，属于不需要人为修改的静态部分。一部分是由工具生成的动态代码。RTE这里比较特殊，RTE代码全部是由工具生成，也就意味着在功能安全方面需要做单独的考量。

既然RTE代码全部由工具生成，也就是说，我们需要评估工具的安全性。在ISO26262第八部分同样定义了工具的置信度，TCL等级。不同TCL等级需要不同的验证过程。其中，TCL1不需要额外的验证。

TCL等级有两个影响的因素。TI表示工具的功能异常情况下，会对安全需求造成影响的可能性。TD表示工具能够提前预防或者检测出软件错误的置信度。最后综合判断出工具的置信度 TCL等级。

达芬奇Configurator PRO工具，可以达到TI2和TD1等级，最终证明为TCL1。 TI2不需要额外的证明，那么如何证明达到TD1呢？

首先DaVinci Configurator Pro中的插件，RTE Generator需要经过很多额外的开发工作量，所生成的代码也需经过ISO26262第六部分来进行测试，这只是Vector这边的工作。那么对于用户来说，拿到代码包之后，首先在配置过程中，达芬奇工具已经具备了一些验证和自查的功能。与此同时，我们会随功能安全代码包提供一个RTE检测工具叫做RTE Analyzer。用户在配置生成RTE代码后，需要通过RTE Analyzer检测并生成报告，对报告进行分析并优化配置项。

通过这种配合，工具整体也就认为能够达到TD1，最终生成的RTE代码也就能够达到相应的ASIL等级。

一个功能安全的系统通常是混合安全等级的。Vector对此提出了两种安全策略，Partitioning和High Performance Integrity。比如图中ECU1所分配的功能仅有QM，也就是说没有功能安全需求，不做讨论。对于ECU2，两个主要功能是QM等级，一个是ASIL，也就是说大部分功能是安全不相关的。那么通常使用Partitioning的功能安全策略。先看ECU4，它所有功能均带有ASIL等级，那么通常采用High Performance Integrity策略，所有模块都需要具有ASIL等级，且安全等级需要额外提升。反观ECU3，一半一半，那么两种策略二选一即可。

那么刚刚提到的两种安全策略区别是什么呢？先说Partitioning局部功能安全策略，这种策略是从所有模块中，摘取了最小化的核心模块做成带有ASIL等级，比如RTE、E2E、OS、WDG以及EcuM初始化序列。High Performance Integrity策略，所有BSW模块均需要按照系统中的最高安全等级来提供，成本比较高。两者区别就在于是否需要具有Safe BSW。

那么SafeBSW选择依据是什么呢？首先，我们说BSW中服务层是能够提供非常多服务接口给到应用层的，这就存在一种情况。假如我们的应用层SWC和提供服务的BSW不在同一个安全等级下，也就是不在同一个内存分区中，这种跨内存分区的调用方式会消耗额外的运行时间。也就是说，考虑到整个系统的运行效率，如果多数功能具有功能安全，选择ASIL的SafeBSW更加划算，反之选择QM BSW即可。这只是技术上的衡量因素，实际还有很多因素需要考量，比如成本。

接下来介绍Adaptive AUTOSAR功能安全解决方案。首先，在Adaptive AUTOSAR的模块中，除了代码本身需要达到相应的ASIL等级要求之外，所提供的安全机制与Classic AUTOSAR是基本类似的。对于通讯上的保护仍然使用E2E。AP使用的是基于服务的SOA通讯，而基于服务的通讯是动态数据长度的，AUTOSAR中的Profile4、6、7可以支持这种动态数据长度。AP中提供平台健康管理PHM模块，该模块类似于CP中的看门狗，同样提供Alive、Deadline、Logic的监测方式。另外对于内存，需要确保数据的完整性和一致性。比如对于相同数据的读写操作不能同时，以确保一致性。另外可以对数据添加CRC校验，以保证完整性。

但是前面说的这些故障检测机制对于Fail Operational系统来说就不再够用了，后面我们会详细讨论Fail Operational系统的要求。

前面谈到的仅仅是AP中提供的安全机制，而AP只是一个中间件，除此以外，还需要考虑Posix OS和C++代码本身的功能安全问题。C++语言的使用给功能安全带来很多全新的挑战。最典型的问题是如何处理动态内存分配。操作系统在运行时需要请求和释放内存，这会带来一些新的故障。

对于Fail Safe系统，代码层面的风险比较典型的是悬空指针造成的use after free UAF，悬空指针指一个长生命周期的指针指向了一个短生命周期提前被释放的变量。再比如重复使用、分配或者释放内存等等。要解决这些问题，开发阶段需要遵照一些代码规则手册，以及使用静态代码分析工具进行分析等，比如使用VectorCast。

对于Fail Operational系统，代码风险包括内存溢出，内存分配不连续导致的内存碎片等等。由于需要确保系统的可用性，那么对于故障的可接受程度也会更低。常规的解决策略包括使用恒定时间的内存分配，使用OS预留的内存，以及使用边界内存等等。

另外，ISO26262第六部分的Table6提及了一些软件单元设计和实现的原则，包括需要避免Exceptions，这点在MISRA规范中同样有所体现。原则上来说，一个函数仅能够含有一个入口和出口，而Exceptions的情况会在出现故障时，在函数正确出口到达之前就错误的改变了程序流向，引向了其他出口，这会干扰关键系统的可预测性。AUTOSAR中定义的API都已经避免了Exceptions。

还存在一个问题，C++中的Templates模板，包括函数模板或者类模板，目的是相同类型代码的重复使用，但这些模板的使用也是之前在C语言中没有遇到的。尤其是对于Templates的测试来说，需要额外的测试过程，而手动的创建测试用例比较耗时而且很容易有疏漏，所以通常这种测试需要使用额外的测试工具来支持，比如Vector这边能够提供的VectorCast工具。

这张图是Adaptive AUTOSAR的整体架构。AP是一个在POSIX OS之上的中间件。而OS在功能安全方面扮演的角色也非常重要，所以同样需要考虑OS的功能安全实现。当前我们的AP产品已实现集成在PikeOS、QNX、风河的Vxworks、GHS的Integrity以及Linux等POSIX OS之上。

这里是Vector Adaptive Microsar产品的Roadmap，其中最基本的模块已经都具备量产条件了，并且也已经有了OEM在基于我们的AP产品做量产。这里可以看到一些额外模块的开发进度。最下方是我们AP产品支持的AUTOSAR版本变动情况。其中带有功能安全的AP产品预计在2021年底将会正式释放。

前面我们提到了Fail Operational，那么含义究竟是什么呢？Fail Operational如何实现呢？

随着自动化驾驶程度越来越高，安全相关的功能处理措施也在发生演变，从最初的ABS功能需要做数据冗余，ESP功能需要做内存分区，到紧急刹车需要做前面提到的高性能功能安全集成。再到后面越来越高的自动化程度，可能直接需要做功能的冗余而不单单是数据冗余了。这就牵扯到了Fail Safe系统到Fail Operational系统的演变。

Fail-Safe系统指的是，如果车辆出现故障，故障需要能够检测到，然后允许直接去禁用故障的功能，甚至是减速至停车。Fail-Operational指的是，车辆出现故障时，仍然需要提供基础功能，以满足系统的基本运行。之前Fail Operational系统通常是用于航空航天方面这种不能停的交通工具，故障后，也最起码要能够维持飞行之类的最基本操作。汽车自动化程度高了之后，不再全靠人为操作车辆了，那么同样需要实现fail-operational系统。

随着自动驾驶程度的提升，故障处理的方式也在逐渐变化。对于Level 0 QM的系统，安全不相关，不多做考虑。对于较低自动化程度的系统，比如Level 1和2，通常使用Fail Safe。这类系统的故障处理措施关键字是检测，这要求故障必须要被检测到，故障功能也可直接关闭。故障检测主要针对时序、内存管理、通讯等方面。一旦发生故障，需要由驾驶员充当Fallback的角色，接管车辆逐步安全停车。

对于高自动化程度的系统，比如Level 3、4、5，就需要使用Fail-Operational来进行处理了，这时驾驶员不再充当接管故障系统的角色。那么所有基本功能都要求是可用的，或者要能够修复的。功能可以降级，但不可以失效。那么这里就要求，通过合理的开发流程，避免系统性故障。

对于Fail-Operational系统，处理故障的方法有两种，一种是Tolerance容错，ISO26262将其描述为，尽管系统软件存在故障，容错的机制仍然要试图让系统保持正常运行。容错通常通过冗余来实现，而这种冗余要求具有多样性，防止在特定条件下，冗余和原系统同时发生故障。我们认为，这种冗余的方式对于基础软件层面来说并不适用，冗余的机制要求基础软件开发两套完全不同的代码同时运行。既浪费硬件资源，也浪费人力。

单从基础软件角度来看，Vector更为倾向第二种方式，Avoidance故障避免，这就要求根据ISO26262第6部分，规范开发流程。代码需要保证FFI的要求，报文确保不会出现重复、丢失、损坏等各种故障，BSW部分需要确保进行正确的模式切换等。Vector的开发过程中遵循原子设计，将单一的功能划分为较小的单元，降低复杂度，并且尽可能使单元之间没有数据交互，降低耦合度。另外就是测试，Vector的Classic AUTOSAR产品从单元到组件测试覆盖度全部达到百分之百。Vector基础软件经历了市场常年的检验，并且有大量的项目经验不断地进行完善，已经具备了足以支持Fail Operational的条件。

刚刚我们分别介绍了AP，CP下的功能安全，以及Fail Safe和Fail Operational的相关概念，那么如何结合这些进行部署实现？

通常，我们建议在微控制器上，比如当前一些主流的MCU上，使用Classic AUTOSAR来实现Fail Operational。软件层面来看，Classic AUTOSAR比Adaptive AUTOSAR具备更多的静态特性和可预测性，且Classic AUTOSAR基础软件已经足够成熟。硬件方面来看，当前的微控制器也比微处理器结构具有更多的安全机制，如lock step锁步核等。

对于在微处理器上运行Adaptive AUTOSAR，建议从构建Fail Safe系统入手。原因其实就是反过来看，从软件方面来说，我们都知道代码成熟度需要经过时间检验，当前Adaptive AUTOSAR本身发展的时间较短，很难达到Classic AUTOSAR的成熟度。硬件方面，虽然微处理器芯片在高性能计算等方面有着不可取代的优势，但目前的微处理器安全机制仍然不足。当然，满足功能安全的基本要求是可以的，但是对于Fail Operational系统，硬件上仍然有比较长的路要走。

我们刚刚提到，在基础软件层面，Vector通过Avoidance实现Fail Operational，这只是基础软件层面达到Fail Operational的要求。

那么从整个ECU系统层面来看，达到fail-operational的策略就需要使用Tolerance容错。整个ECU层面需要部署Fallback的冗余ECU，冗余ECU允许功能降级。另外，AP部分由于实现的仅是Fail Safe，所以需要单独来做冗余，这个微处理器的冗余目的不在于提高AP本身的可用性，而是为了保证每个通道计算的完整性。这种情况下，那些需要保证可用性需求的功能，也就是fail-operational相关的部分功能，需要分配给Classic AUTOSAR部分。

这里存在两种方式，一种是图中这样，ECU中分别部署一个微处理器运行AP和一个微控制器运行CP。两者可以通过以太网等或者SPI等方式连接，自定义IPC通讯。

另外，当前的一些微处理器，比如一些SOC异构芯片，其中M核或者R核可以运行CP，A核用来运行AP。这类芯片具有安全岛，添加了很多安全机制，比如锁步核、MMU或MPU等，同样为CP的运行提供了安全保障，再加上整个芯片层面的冗余，那么仍然认为CP部分能够达到Fail Operational。这种情况下，AP与CP之间只需要通过Shared Memory方式进行IPC通讯。

当前对于Fail Operational的探讨仍然在进行，对于AP的fail-operational实现也仍然有着很长的路要走。

下面是维克多汽车在本次大会中的精彩瞬间：