智能<em>驾驶</em>:功能安全与预期安全流程融合可行吗?-技术圈

（第415期）

文丨高工

汽车主机厂ADAS研发人员

在汽车研发领域，汽车电子电气系统有2个主要安全维度：功能安全、预期功能安全。但在研发过程中我们常常会发现周围很多人把二者混为一谈，这里梳理相关内容如下。并顺便探讨下二者之间的融合可能性。

首先，汽车电子电气系统其实有3个主要安全维度：功能安全、预期功能安全、信息安全。三者关系的联系： 1、功能安全是基础，主要解决内部故障引起的风险。 2、预期功能安全进一步解决了系统正常但存在潜在风险的问题。 3、网络安全是最外层的防护，主要针对外部恶意攻击。

功能安全 (Functional Safety)： 侧重点：确保电子电气系统中出现的故障不会引发危险。核心：避免由硬件和软件故障导致的风险。标准：ISO26262。
预期功能安全 (Safety Of The Intended Functionality, SOTIF)： 侧重点：即使在系统正常运行无故障的状态下，还是可能存在的风险，如由于性能不足或误用引起的。核心：确保系统的功能与其预期是一致的，并避免因此产生的风险。标准：ISO21448。
网络安全 (Cyber Security)： 侧重点：防止外部恶意攻击。核心：保护系统不被蓄意攻击，确保系统的控制接口和通信方式的安全。标准：ISO21434。
实例：

在实际应用中，这三个领域经常交叉。例如，一个汽车的刹车系统可能需要考虑功能安全(确保刹车总是工作)、SOTIF(确保在所有驾驶条件下都能正确应用刹车)和网络安全(确保刹车系统不能被远程黑客攻击)。

为了确保系统的全面安全，工程师和设计者需要在设计、开发和验证过程中考虑这三个领域的原则和实践。

功能安全、网络安全的概念视图

例如， 一个汽车的刹车系统可能需要考虑功能安全(确保刹车总是工作)、SOTIF(确保在所有驾驶条件下都能正确应用刹车)和网络安全(确保刹车系统不能被远程黑客攻击)。

为了确保系统的全面安全，工程师和设计者需要在设计、开发和验证过程中考虑这三个领域的原则和实践。

汽车功能安全（ISO26262）和网络安全（ISO/SAE21434）协同

综上，电子电气系统的安全运行不仅仅是一个孤立的概念，而是一个综合性的体系，涉及到功能安全、预期功能安全和网络安全这三个紧密相连的层面。这三者如同三位一体，互相补充，缺失任何一方都会使得整体安全性受到威胁。

接下来，我们探讨下三者是否在研发流程上是否具有融合的可行性。

其实，信息安全作为保护系统不被蓄意攻击的手段，其主要针对外部恶意攻击，属于最外层的防护，相比于功能安全与预期安全，它涉及更多的是IT领域的开发内容，相对比较独立。所以，流程融合的可能性主要在功能安全与预期安全。

那么，流程融合的意义是什么呢？2023年12月7日，在2023中国汽车功能安全与质量管理峰会上，合众新能源汽车股份有限公司功能安全高级经理刘翔表示，首先企业内部研发流程体系繁杂；其次功能安全大多为成熟体系，预期功能安全的标准缺乏有效支持类流程定义；最后预期功能安全在智能驾驶和智能座舱等领域是功能安全的补充。

刘翔表示，不管是预期功能安全还是功能安全如果在测试开发中出现问题，会同时对两个流程的体系活动产生影响。对于现场监控而言，两个流程可以放到一起做，后续发现和识别到问题，同时去评估对两个活动的影响。针对开发阶段的融合和验证及管理阶段的融合，刘翔进行了产品实践全过程的经验分享。

以下是来自自合众 新能源 汽车股份有限公司功能安全高级经理刘翔于2023年12月7日在2023中国汽车功能安全与质量管理峰会发表的《功能安全和预期功能安全流程融合》主题演讲：

以下为演讲内容整理：

当前企业内部的研发流程体系十分繁杂，包括质量管理体系、功能安全体系、网络管理体系、整车软件等流程。这些体系如果要放到整车开发中，需要考虑各流程之间的迭代和交互。但如果要完全独立的引入一个新流程，就需要打通和各个流程之间的关系，看各流程之间的关联性和接口。因此基于现有流程进行融合是最优解。

许多企业对于功能安全已经有了成熟的开发体系。预期功能安全的标准中提到了支持类和管理类流程至关重要，且可以参考其他标准体系，因此以功能安全体系为基础建立预期功能安全的流程也是符合预期功能安全标准建议的方案。预期功能安全并不是一个独立的流程，而是功能安全的补充。预期功能安全开发过程中会涉及到功能安全的迭代。

我们将预期功能安全和功能安全落回到了V字型的开发流程，因为所有流程都需要回到整车层面落地。下图左上角是功能规范，对于预期功能安全而言，这部分的要求比较详细。功能安全和预期功能安全的起始点不一样。考虑到流程融合，我们建议细化功能规范，把功能安全的相关项定义融入到功能规范中。我们后续做预期功能安全开发过程中，涉及到的功能设计、架构的修改，都可以很好的反馈到功能安全的输入中。

预期功能安全和功能安全最大的区别在于暴露度判断 。基于现状，我们已经搭建了功能安全整体的开发平台，在此基础上做预期功能安全的分析。触发条件是预期功能安全所特有的。在我们的预期功能安全标准中，没有安全概念活动，但明确定义了功能优化。为了更好匹配功能安全流程和整车开发流程，我们引入了预期功能安全的概念阶段。

预期功能安全和功能安全中存在着关联迭代，预期功能安全的开发以功能安全的安全机制为前提。由于在引入高阶智驾功能后，很难假设驾驶员是完全可控的，因此我们也考虑基于预期功能安全分析的可控性，评估预期功能安全上对驾驶员可控性的打分。

针对预期功能安全和功能安全，我们都是基于多支柱法、仿真、场地、里程测试。以上不论是从验证方式还是开发阶段来看，匹配都没有问题。需要注意的是，不管是预期功能安全还是功能安全，一旦在测试开发中出现问题，都会同时对两个流程的体系活动产生影响。

开发阶段的融合

在预期功能安全中，性能局限、措施、场景库、功能不足、检查清单等是必须条件。我们在做预期功能安全分析的过程中，这部分数据很多都是基于假设和行业经验。但对于预期功能安全而言，必须要引入这些数据，才能支撑分析。而这部分数据十分庞大，一家企业很难独立完成。

我们建议将已知性能局限和措施提前输入给功能规范，这样可以避免后续在安全开发中出现相应问题。此外，我们基于功能安全所识别出来的功能列表进行补充和完善，同时引入一些新方面，主要基于HMI的设计做一些分析。我们还基于场景库，在原有功能安全基础上，把场景做一个详细的参数化定义。检查清单则是为了做安全分析的场景识别。预期功能安全分析完成后，需要评估系统对触发条件的响应。如果响应是可接受的，就直接进入测试环节，不需要做更多功能优化。交通事故和交通流数据是基于预期功能安全做接受准则和确认目标的定义。这两部分数据的更新可以用于功能安全中的打分。

我们将功能安全和预期功能安全危害事件模型进行了融合。功能安全主要考虑的是随机硬件故障和系统性故障，预期功能安全主要考虑误用、性能局限、功能规范不足，以及叠加触发条件后所产生的影响危害行为。

在预期功能安全分析中，我们会考虑场景，但不会进行评估场景。这部分内容是在做确认目标定义时，基于交通流的数据，抽样出我们所关心的场景，评估场景的存在概率，调整验证里程。

在不可控事件中，对于高阶智驾功能的分析，不管是高阶行车NOA功能还是记忆泊车，我们很难判定驾驶员是可以迅速接管的，因此这部分可控性的分析是基于预期功能安全的引入，会调整原有功能安全的打分。

下图是功能安全的评分表。该表的范围都是与预期功能安全相关，但也包含了一部分功能安全QM的安全目标。我们会基于整车的危害做后续安全分析追溯，将其分为两类，一类基于预期功能安全相关，另一类与预期功能安全和功能安全都相关。

下图是STPA流程图。第一步是匹配HARA的内容。第二步是基于系统架构，做控制结构，该控制结构会把驾驶员融入功能框图中，可以分析驾驶员误用的问题。第三步是识别不安全的控制行为，同时定义控制器层级的安全约束，会基于驾驶员的CA(控制行为)识别相应的UCA(不安全的控制行为)。第四步是致因场景的识别。

识别完成后，我们会做一个触发条件的可接受度评估。第三步中的控制器层级安全约束需要结合第四步中识别到的致因场景，才能导出这一层级的功能安全需求和预期功能安全需求。其中如果涉及到一些安全需求的分解或冗余架构，我们需要以CTA的方式，可视化梳理功能安全可能涉及的等级分解，以及预期功能安全存在的弱点。

与FMEA、FTA和ETA等专注于识别故障事件下游影响的方法不同，STPA可适用于分析导致损失的故障和非故障，考虑组件和系统之间的相互作用，分析其是否按照设计期望运行，提供相关功能。使用STPA的一个重要好处是它能够识别导致故障和非故障原因的各种因果因素，因此用STPA做融合开发是一个较好的方式。

基于STPA的融合安全分析第三步主要是UCA的识别，会基于第二步的功能框图所定义的CA以及引导词，识别我们的UCA。其中引入了上下文变量，能够更好细化UCA的描述，有助于识别系统上的安全风险。第四步会基于UCA推导可能存在的不足条件，再看所存在的因果因素。对于因果因素，我们会预先做一些触发条件库，基于公开数据以及项目上的积累、供应商交流，完善数据库。

我们会定义已知的传感器局限性，算法局限性，再去参考其他因素。21448会考虑天气和其他交通参与者的行为、设施、场景，定义潜在存在的触发条件，用触发条件在STPA四部中做因果因素的映射。

验证及管理阶段的融合

由于功能安全和预期功能安全是相互关联的，因此我们需要做验证及管理阶段的融合。功能安全的验证和确认策略是计划性的内容。但预期功能安全需要通过我们识别出的触发条件、做安全分析时的整体残余风险接受准则、交通流数据、交通事故的数据等定义我们的确认目标。

我们在实际验证过程中会考虑限制条件，如最大的加速度、最大的减速度、功能运行的车速等。这些限制条件是做预期功能安全分析的前提。如果在整个测试过程中发现确认目标没有达到，不管是限制条件有问题还是性能指标有问题，都需要进行迭代。

预期功能安全在借用功能安全流程时有一个问题，即预期功能安全没有ASIL等级，而功能安全存在很多属性以及不同等级要求。 针对这一问题，对于功能安全和预期功能安全重叠部分的软件和硬件开发，我们完全按照功能安全要求进行。对于非重叠部分，我们则按照质量体系、QM的要求开展。

我们在做Fusa时面临独立性的问题，做预期功能安全是没有ASIL等级的。我们目前是按照控制器的最高等级实施，但中间可能存在一些偏差项，这些偏差项只能用case by case处理。对于这一问题行业尚无共识。

不管是功能安全还是预期功能安全，我们所有安全开发的落脚点都是企业的开发流程。因此不同企业需要根据自身开发流程对功能安全和预期功能安全融合方案进行修改。

流程融合方式探讨

我们把预期功能安全和功能安全流程融合方式分为“完全融合开发”和“开发阶段匹配”两种方式。完全融合开发是指将模板融合在一起，由相同的工程师同步做，指导书也会进行合并。这一方式的优势在于工作量较低，开发工作的重复性低，能够避免两个流程之间的反复迭代，模板会简化，流程文件及模板的管理工作量也会下降。其劣势在于需要重新改写现有的流程体系。尤其是对于主机厂而言，我们的开发不仅仅是智驾域，还包含底盘域、车身域等，但目前很多域并不会做预期功能安全，因此整个流程的修改影响较大。