“维克多曲越：基于AUTOSAR的功能安全处理方案”-东方汽车时报

由格斯坦汽车、汽车公司、上海车展三方共同主办的sdvf2021第二届软件定义汽车峰会论坛暨autosar2021中国将于4月19-21日在上海举行，此次活动也将是2021上海车展的同步活动在这次会议上，邀请了维克多汽车技术(上海)有限企业商务开发经理曲越(/S2/) 先生(/S2/)，在这次论坛上，

你好，我是维克多商业开发经理曲越。这几天，非常多的嘉宾和专家分享了一个有点宏观的主题，非常硬核。今天带来了具体的处理方案，autosar下的功能安全处理方案。今天的演讲主要分为四个部分。第一部分说明功能安全相关的概念。第二部分和第三部分详细介绍了维克多将classicautosar和adaptiveautosar进行比较的功能安全处理方案。最后第四部分同样是趋势副本，详细介绍安全体系结构设计在故障操作系统中面临的挑战。

iso26262标准于年上市，年更新，其中详细记述了汽车电子系统安全相关的概念。目的是在目前的技术水平下，尽量降低汽车电子系统带来的风险。

什么是功能安全？首先，这里需要区分我们经常提到的safety和security。功能安全的目的是防止可能危害人身的ee系统带来的意想不到的风险。 cyber security的目的是防止黑客攻击系统，这种风险是人为的能动因素，是可预测的。总而言之，safety保护的主体是人身安全，security保护的主体是财产也就是汽车系统本身，实际上归根结底还是要回归人身安全。

iso26262提出了ffi大体上是自适应接口。这意味着必须防止不同安全级别的模块之间发生故障的相互影响，也就是说，必须防止级联故障。例如，一个asil-a模块本来自身的故障影响就很低，但如果asil-a模块自身的故障影响了其他asil-d的高风险模块而导致级联故障，则该高风险模块判断为asil-d就没有意义了。

故障包括系统故障和随机故障。随机故障一般发生在硬件方面，对于随机故障目前采用了许多不同的数学模型来判断硬件的安全性。我不怎么讨论这个。软件通常会发生系统故障，是由特定的人为因素引起的。可以检测系统故障。但是，目前为系统故障建立数学模型的所有尝试都没有成功，这意味着难以预测。所以，为了不引起系统故障，需要从开发过程方面着手。

软件端系统故障通常分为三个方面，如内存端故障，如野点、栈溢出、变量写入越界等。有死循环、高频中断、以及由于小不规则输入而导致的计算时间过长等时间上的问题。通信故障的最典型的例子是消息的丢失、重复、损坏、延迟等。

接下来，我们将分别研究classic autosar和adaptive autosar的功能安全对策方案中对这些故障的检测和解决方案。

首先，介绍classic autosar功能的安全性处理方案。 vector对autosar的处理方案统称为microsar，功能安全性处理方案主要分为图中的五个部分。

安全操作系统需要提供内存保护，其目的是与硬件提供的内存保护单元( MPU )协作，实现内存保护，从而实现ffi的大致功能。除了rte的基本功能之外，saferte的目的还在于提供ecu内部不同asil水平之间的相互作用，保障相互作用的安全性，达到ffi要求。 safewdg用于监视代码的执行时间和执行顺序等错误，目的是防止代码飞溅。 safee2e用于检测刚才提到的通信中的许多问题。除了刚才提到的模块之外，safebsw是所有其他基础模块的总称，整体上采用safebsw可以提高系统性能。关于技术方面的安全总线的选择根据将在后面叙述。此外，safebsw的许多模块还提供其他安全功能，如使用安全ecum进行适当的初始化过程，使用nvm向非易失性存储器安全读取/写入数据，以及保护数据存储的一致性。

接下来，让我们分别看看。首先是安全操作系统的部分。除了操作系统代码本身必须达到asil-d之外，autosar还定义了四个操作系统级别以提供附加的安全机制。

sc1是基础OSEK操作系统+进度表。 sc2在sc1中添加了定时保护功能，可以事先计划和监控任务和两种中断的时间预算。超出时间预算的代码将被带入操作系统保护电话，以便客户定制和解决代码。 sc3在sc1上添加了内存保护功能，也就是说与mpu合作进行内存保护。从价格的观点来看，功能安全项目一般是混合asil等级的情况，基本上需要sc3以上等级的os。 sc4相当于sc2+sc3，既有存储器保护，也有时间保护。

当然，vector提供的所有级别的安全操作系统都支持单核或多核的招聘场景。

安全漏洞。如图所示，autosar监视程序体系结构以检查点为单位进行监视。也就是说，它是嵌入在代码中的监视点。 wdgm提供了三种监控方法，用于定义deadline monitoring、时间预算和监控两个检查点之间的时间是否超出预算。 alive monitoring定义执行次数，并监视在特定时间段内达到检查点的次数是否在预算内。例如，定义某个checkpoint需要在100ms的时间内运行2-3次，如果超过或没有达到该次数，则认为监视失败而引起复位。逻辑监控过程流监视多而复杂，定义的是过程跳跃轨迹。例如，定义为从检查点1只能跳到2和3，跳到4则视为监视失败而进行复位。

一般在混合安全等级系统中，根据不同的安全等级定义不同的监视实体，然后对不同的监视实体采用不同的监视方法，可以以这种组合的形式监视整个系统。

在safee2e中，autosar定义了许多E2E配置文件类型，vector提供的e2e lib现在直接包含所有autosar标准的配置文件类型，可供客户选择。 oem中定义的特殊配置文件可以单独提供。

safe rte除了rte最基本的功能之外，还提供不同安全级别的模块的交互。使用过autosar的观众都知道，维克多作为基本软件供应商通常提供的代码包分为几个部分，有些部分是静态代码，不需要人为更改。部分是由工具生成的动态代码。 rte在这里是特殊的，这意味着rte代码全部由工具生成，在功能安全性方面需要单独考虑。

既然所有的rte代码都是由工具生成的，也就是说必须判断工具的安全性。在iso26262第8部分中也同样定义了工具的可靠性、tcl等级。不同的tcl级别需要不同的验证过程。但是，tcl1不需要额外的验证。

tcl水平有两个影响因素。 ti表示在工具功能异常的情况下，有可能会对安全诉求产生影响。 td表示可以预先预防或检测软件错误的工具的可靠性。最后对工具的可靠性tcl水平进行了综合评价。

达芬奇配置器pro工具可以达到ti2和td1的等级，最终被描述为tcl1。 ti2不需要额外的说明，但是要怎么说明达到td1呢？

首先，davinciconfiguratorpro的插件，rte generator经过很多额外的开发工作，生成的代码也需要经过iso26262第六部分进行测试。这不过是矢量方面的业务。那么，对于客户来说，拿到代码包后，首先在配置过程中，达芬奇工具具备验证和自我检查的功能。此外，功能安全代码包还附带有rte检测工具rte analyzer。配置rte代码生成后，客户必须使用rte analyzer检测和生成报告，然后分解报告以优化配置项目。

通过这种合作，整个工具可以到达td1，最终生成的rte代码也可以到达合适的asil级别。

功能安全的系统一般为混合安全级别。对此，vector提出了分区和高性能完整性两种安全战略。例如，分配给图中的ecu1的功能只有qm，也就是说没有功能安全的诉求，不讨论。 ecu2的话，两个主要功能是qm等级，一个是asil，也就是说大部分功能是安全的，没有关联的。那么，一般采用partitioning的功能安全战略。首先，让我们来看看ecu4。所有功能都带有asil级别。使用高性能完整性策略时，所有模块都需要asil级别，必须提高安全级别。相反，ecu3，一半，那样的话两个战略二者择一就行了。

那么，前面提到的两种安全战略有什么不同呢？首先，介绍partitioning的局部功能安全战略。此策略是从所有模块中提取最小化的核心模块，使其具有asil级别，如rte、e2e、os、wdg和ecum初始化序列。高性能集成战略要求在系统中以最高的安全级别提供所有bsw模块，并且价格比很高。两者的区别在于是否有必要拥有安全宝马。

选择safebsw的根据是什么？首先，bsw中提到了服务层可以向APP应用层提供非常多的服务接口，这有一种情况。如果APP应用层swc和提供服务的bsw不在同一安全级别，即不在同一内存分区中，则此内存分区之间的调用方法会消耗额外的执行时间。也就是说，考虑到系统整体的运用效率，如果大多数功能在功能上是安全的，那么选择asil的safebsw比较划算，相反选择qm bsw就可以了。这是技术测量要素，实际上有很多价格等需要考虑的要素。

下面就adaptive autosar功能安全性处理方案进行说明。首先，除了代码本身必须满足适当的asil级别要求之外，adaptive autosar模块提供了与classicautosar基本相似的安全机制。通信上的保护采用了e2e。 ap采用基于服务的soa通信，而基于服务的通信是动态数据长度，autosar的profile4、6、7可以支持这种动态数据长度。为ap提供了平台健康管理phm模块，该模块类似于cp的看门狗，还提供了alive、deadline、logic的监视方法。此外，对于内存，必须确保数据的完整性和一致性。例如，不能对同一数据进行读写操作。此外，确保一致性。此外，还可以在数据中添加crc检查以保证其完整性。

但是，前面提到的故障检测机制对于故障操作系统来说还不够。稍后将详细介绍fail operational系统的要求。

前面说的只是ap提供的安全机制，ap只是中间件，除此之外还需要考虑posix os和c+代码本身的功能安全问题。 c +语言的采用给功能安全性带来了许多新的挑战。最典型的问题是如何解决动态内存分配。操作系统在运行时需要请求并释放内存，这会带来一些新的故障。

在fail safe系统中，代码级别的风险典型地是使用悬挂空指针的use after free uaf，从而在短生命周期内提前释放悬挂空指针重新招聘、分配或释放内存等。要解决这些问题，在开发阶段需要遵循一点代码规则文档，以及使用vectorcast之类的静态代码分解工具进行分解等。

在fail operational系统中，代码风险包括内存溢出、内存分配不连续性导致的内存碎片等。对故障的容忍度也很低，因为需要确保系统的可用性。一般的处理策略有采用一定时间的内存分配、采用操作系统保留的内存、采用边界存储器等。

此外，iso26262第6部分的table6概述了软件单元的设计和实现，包括必须不使用exceptions。这在misra规格中也可以看到。一般来说，一个函数只能包含一个入口和出口，但在exceptions的情况下，在函数正确的出口到达之前，会错误地改变程序的流向，导向其他出口，妨碍重要系统的可预测性。在autosar中定义的api不再使用表达式。

此外，c +的templates模板包括函数模板和类模板，目的是重新采用相同类型的代码，但这些模板在c语言中从来没有遇到过。特别是在templates测试中，需要额外的测试流程，手动创建测试用例很花时间，容易被忽略，因此这类测试通常需要vector端可以提供的vectorcast工具等额外的测试工具

此图显示了adaptiveautosar的整体体系结构。 ap是位于posix os操作系统之上的中间件。另外，由于os在功能安全方面发挥的作用也很重要，因此也需要考虑实现os的功能安全。目前，我们的ap产品已集成到pikeos、qnx、风河的vxworks、ghs的完整性、linux等posixos中。

这里是vector adaptive microsar产品的roadmap，其中最基本的模块已经具备批量生产条件，同时oem已经根据本公司的ap产品进行批量生产。在这里，我们可以稍微了解一下追加模块的开发进度。底部是ap产品支持的autosar版本更改。其中，功能安全的美联储产品预计将于2021年底正式推出。

前面提到了故障操作，是什么意思？ fail operational是如何实现的呢？

随着自动驾驶的程度越来越高，安全相关的功能解决方案也在进化。最初的abs功能需要数据冗余化，esp功能需要内存分区，紧急制动需要上述高性能功能的安全集成。此外，随着后面越来越高级的自动化，除了数据冗余外，还可能直接需要功能冗余。这导致了从故障安全系统向故障操作系统的进化。

故障安全系统是指车辆发生故障时，需要检测故障，允许直接禁用故障功能或减速至停车。故障运营意味着即使车辆发生故障，也需要提供基础功能以满足系统的基本运行。此前，故障操作系统用于航空空航天方面这种不能停止的交通工具，在发生故障后，也需要最低限度地维持飞行等基本操作。汽车自动化发展后，如果不再通过人为操作操作车辆，同样需要实现故障诊断系统。

随着自动驾驶水平的提高，解决故障的方法也在发生变化。在level 0 qm的系统中，与安全性无关，很少考虑。在自动化程度较低的系统(如level 1和2 )中，通常采用故障安全。这种系统的故障解决对策关键词是检查，需要检测故障，故障功能也可以直接关闭。故障检测的第一比较时序、内存管理、通信等方面。如果发生故障，司机需要扮演fallback的角色，接管车辆，慢慢安全停车。

对于高自动化系统(如3级、4级和5级)，必须采用故障操作解决。在这种情况下，司机不会起到接管故障系统的作用。基本功能必须全部可用或可修复。可以降低功能，但不能禁用。这里，要求通过合理的开发过程，不引起系统故障。

对于故障操作系统，有两种解决故障的方法。一个是容错机制，iso26262对此进行了解释，说明虽然系统软件有故障，但容错机制试图使系统正常工作。容错通常通过冗余来实现，但这种冗余要求是多样化的，可以防止在特定条件下冗余和原始系统发生故障。我们认为这样冗长的方法在基础软件层面上是不适用的。冗余机制要求基础软件开发和运行两套完全不同的代码。既浪费硬件资源，也浪费人才。

从基本软件的角度来看，载体更倾向于第二种方法，不会发生混淆故障，因此要求基于iso26262第6部分，规范开发流程。代码需要保证ffi的要求，消息需要确保没有重复、丢失、损坏等各种故障，bsw部分需要确保正确的模式切换等。在vector的开发过程中，按照原子设计，将单一功能分割为小单元，降低很多噪声，同时尽量避免单元间的数据交换，降低耦合度。另外，是测试。从设备到组件测试，vector的classicautosar产品全部涵盖100%。 vector的基础软件在市场上经过多年检验的同时，许多项目经验不断完善，具备了支持故障操作的充分条件。

刚才我们讨论了在ap、cp中的功能安全性，以及故障安全和故障操作的相关概念，如何将它们组合起来实现部署？

一般来说，对于微控制器，例如现在主流的mcu，建议采用classic autosar实现故障操作。从软件层面来看，classic autosar比adaptiveautosar具有更多的静态特征和可预测性，classic autosar的基础软件十分成熟。在硬件方面，与微解决方案体系结构相比，现在的微控制器也有越来越多的安全机制，如lock step锁定核心等。

在微解决方案中运行adaptiveautosar时，建议从构建故障安全系统开始。其理由是，反过来看，我们知道在软件方面，代码成熟度必须经过时间验证。目前，adaptiveautosar自身发展迅速的时间很短，要达到classic autosar的成熟度并不容易。在硬件方面，微处理器芯片具有高性能计算等无法代替的特点，但目前的微处理器安全机制还不够。当然，可以满足功能安全的基本要求，但是在故障操作系统中，硬件还有比时间更长的路要走。

如上所述，在基本软件级别，vector通过保证实现了故障操作。这只是在基本软件级别实现故障操作的要求。

那么，从整个ecu系统来看，要实现故障操作战略，需要采用容错技术。需要在整个ecu级别部署故障恢复冗余ecu，冗余ecu允许功能下降。另外，由于ap部分只实现了故障安全，因此需要分别进行冗余化。此微解决方案的冗余化目的是保证每个通道计算的完整性，而不是提高ap本身的可用性。在这种情况下，必须将需要保证可用性诉求的功能(某些与故障操作相关的功能)分配到“classic autosar”部分。

这里有两种方法。一个是在ecu中分别部署一个微解决方案运行ap，另一个是部署一个微控制器运行cp，如图所示。两者通过以太网等和spi等方法连接，可以定制ipc通信。

另外，在目前的微解决方案(如soc异构芯片)中，m核或r核可以执行cp，a核用于执行ap。这样的芯片拥有安全岛，添加了许多安全机构，如锁定步核、mmu或mpu等，同样为cp的运行提供了安全保障，加上芯片级整体冗余，认为cp部分还是可以达到故障运营的。在这种情况下，ap和cp之间只需要通过共享内存方法进行ipc通信。