预期功能安全-SOTIF:自动驾驶系统潜在功能不足与触发条件到底如何识别?

汽车电子与软件 2023-09-15 20:34

在预期功能安全ISO 21448中，一旦完成危害分析和风险评估过程，针对那些不满足危害行为接受准则的那些行为，我们如何有效地识别导致危害行为产生的潜在功能不足与触发条件，这绝对是预期功能安全开发的难点之一😂。

根据ISO 21448内容，一旦通过危害分析识别出整车危害(Hazard)及危害事件(Hazard Event)，就需要对其潜在功能不足与触发条件进行识别，即哪些原因导致了危害行为的产生，便于后续依据触发条件制定安全需求，对系统进行优化和改进。

和功能安全相比，预期功能安全SOTIF的危害源于系统功能和性能局限，或人为合理误触发，且应用于自动驾驶或高级辅助驾驶系统。

那么预期功能安全危害产生的原因，尤其是由功能不足导致的危害原因识别中，存在什么难点呢？这篇文章我们深度聊一聊。

在功能安全ISO 26262中，通过单一的，或者针对较高的ASIL等级，采用FMEA+FTA的双重安全手段，就可以有效地识别出危害产生的原因，但随着自动驾驶自动化水平不断提高，系统越来越复杂，危害触发原因也随之复杂化和多样化，传统的安全分析手段在预期功能安全中已经不能满足其需求，尤其是由AI算法或机器学习得到的非白盒模型的应用，直接增加了预期功能安全危害源识别的难度😭，主要体现在:

自动驾驶系统功能和性能局限多属于未知因素，触发条件与运行场景强相关

系统复杂性增加，安全分析工作量剧增

系统之间错综复杂的相互作用关系使得安全分析很难找到失效的真正原因

非白盒模型极大增加了安全分析的难度

人为合理触发存在一定的个体差异性

由于以上原因，基于传统的安全分析方法，已经不再能够满足预期功能安全SOTIF危害源识别的需求，那么我们应该如何应对呢？

总体来看，我们可以从以下几个方面入手:

重视并不断丰富自动驾驶运行场景的搭建

结合多种安全分析手段，充分利用不同分析手段的优势和适用场景

加强仿真及测试验证的作用

只有这样才能充分识别自动驾驶系统在已知和未知的危害场景下的功能不足及危害触发条件。是的，这个结论看似简单，却不简单！

自动驾驶运行场景

对于自动驾驶系统而言，究其危害行为发生的原因，不仅涉及系统本身的原因，即系统潜在的功能不足和性能局限，还包括了故障发生当下的触发条件的激活，因为只有在特定的触发条件下，系统功能不足和性能局限才会显现出来，进而导致故障产生，例如，自动驾驶系统在夜间运行场景这一触发条件下，摄像头由于其功能不足将车道线误识别，导致非预期的转向产生，所以自动驾驶功能不足的触发条件和运行场景强烈相关，我们在识别自动驾驶系统功能不足的时候必须明确其触发条件。

自动驾驶系统运行场景的建立非常有助于潜在功能不足的触发条件的识别，和功能安全分析的车辆场景相比，预期功能安全中触发条件识别需要的运行场景更为细致，为了涵盖小概率危害事件，需要尽可能全面地收集更多的运行场景，包括一些极为少见的情形。

自动驾驶系统常见的运行场景因素主要包括:

气候

─ 例如，良好，多云，雨，雪，雾，风等

道路及道路特性

─ 例如，直道，弯道，上坡，下坡，道路宽窄，坑洼道路，车道线存在/不存在等

道路特征
─ 例如，高速，立交桥，匝道，隧道等
一天中所处的时间
─ 例如，早上，中午，晚上等
光照
─ 例如，直射，背光，无光照，路灯照射等
自车运行情况
─ 例如，车辆运行状态(纵向，横向)，车重，传感器位置，干净程度等
自车操作
─ 例如，加速，减速，弯道超车，停车，转向等
周围车辆
─ 例如，前车加速，前车减速，前车停止，迎面来车，对面车打开了远光灯等
其他交通参与情况
─ 例如，行人，轿车，卡车，公交车等
障碍物等
─ 例如，交通标志，围栏，侧壁，掉落的物体等

自动驾驶运行场景库的建立是其研发的重要基础，目前行业内，不同的企业，或者以国家研究机构为单位都在积极地建立相应的自动驾驶运行场景，例如，中国汽研自动驾驶运行场景库，德国PEGASUS项目等，可以直接查看具体的运行场景库。

在预期功能安全后续的危害原因的识别和分析过程中，需要将不同的分析手段和运行场景相结合，才能有效识别出其功能不足和触发条件。

安全分析手段的应用

这一部分我们系统地来看看，有哪些分析手段可以用来识别预期功能安全危害触发原因，它们各自的适用程度如何，更适合解决哪类问题！

传统的安全分析方法，即归纳和演绎分析手段，例如，最常见的FMEA，FTA，依然是预期功能安全识别危害源，导出并定义安全需求的重要手段。

对于自动驾驶系统的预期功能安全而言，传统的安全分析方法的最大的局限性就在于需要依靠分析者的经验，对错综复杂的系统，甚至是非白盒系统，进行安全分析，不但分析工作量大，难度大，而且很多触发条件强烈依赖场景，而很多运行场景存于未知状态，所以安全分析+运行场景在预期功能安全分析中成为必然，安全分析在具体使用过程中也会发生一定的变化。

由于传统分析手段的白盒分析的特性，所以传统的安全分析手段，除了识别危害本身外，比较适用于以下情形:

失效源和触发条件的初步识别

在功能和逻辑层面存在的功能和性能不足的问题及触发条件

执行器端的功能和性能不足的问题及触发条件

当然，传统的安全分析方法完全可以用于AI，机器学习等非白盒模型，只是不能像白盒模型一样，通过对模型内部工作原理进行分析，使得整个模型达到可完全解释的状态，进而让我们可以比较容易地获得模型所有可能且确定的运行状态并进行安全分析，所以非白盒模型的安全分析多基于功能，逻辑和接口进行，可以借助模型特性等相关技术增加模型的可解释性，帮助我们更好地进行安全分析。

2.1 归纳分析方法

归纳分析法，例如FMEA, 是一种自下而上的安全分析方法，重点关注系统的各组成部分可能会发生的故障以及这些故障对系统的影响，属于从原因到结果的分析方法。

由于自动驾驶系统功能不足的触发条件的识别，离不开自动驾驶运行场景，所以我们可以从两个角度系统地应用归纳分析法，识别系统的功能不足和触发条件:

角度一: 从潜在功能不足识别触发条件

这个角度和我们传统的归纳分析方法，例如FMEA，分析流程完全一致，主要是依据自动驾驶“感知-策划-执行”的模型的组成和功能，针对特定的系统功能，首先识别功能所涉及的软件，硬件要素列表，分析要素可能存在的功能不足，然后根据潜在的功能不足，结合运行场景，进一步识别可能会激活这些不足的触发条件。

为了朋友们更好理解，我们上个实例。例如，对于如下所示的自动驾驶系统车道保持(LKA)这个功能而言:

首先，分析该功能主要涉及的要素包括:

─ 传感器: 摄像头

─ 控制器: 主要包括了LKA控制系统和运行控制(Running Controller)两个部分，主要的控制变量是LKA系统发出的转矩和转向角度。

─ 执行器: EPS

然后，识别要素潜在的功能不足:

例如:

─ 传感器: 摄像头由于分辨率限制，车道线识别不清晰或误识别。

─ 控制器:由于识别输入车道线不清晰，LKA算法无法进行合理应对。

─ 执行器: EPS执行单元在较低的温度下，执行速度变慢。

最后，考虑运行场景，识别出触发条件:

─ 触发条件1: 在乡村道路，车道线不清晰(触发传感器和控制器功能不足)，自车以100km/h速度行驶，迎面存在驶来的其他车辆。

─ 触发条件2: 车辆夜间行驶(触发传感器和控制器功能不足)在高速公路，自车处于弯道行驶状态，旁边存在高速公路护栏。

─ 触发条件3: ...

角度二: 从运行条件识别潜在功能不足

虽然这个分析角度和传统的FMEA分析过程不同，但本质上也是属于归纳分析法，只不过是通过对可能导致危害行为的运行场景进行归纳，找出受这些潜在触发条件的影响的系统功能或要素，进而推断出其功能不足的问题。

该方式正好是前面所描述的从潜在功能不足到触发条件识别的反过程，上述实例过程也是同样适用，只是过程相反。

在实际应用中，这两种方式都可以使用，可以相互补充和验证分析结果的完整性。

2.2 演绎分析方法

所谓的演绎分析方法，例如，FTA，即自上而下，从危害入手，通过故障树的形式，逐级分析导致危害产生的原因，直至最终的底层原因为止。

在预期功能安全功能安全及触发条件识别中，虽然演绎分析发看似比较直接有效，可以根据危害直接识别到功能不足和触发条件，但由于自动驾驶系统较为复杂，影响因素相互交错，演绎分析方法的应用相对比较困难，很难直接应用于整个系统。

为此，在实际操作中可以根据特定的安全目标或危害，将系统按照“感知-策划-执行”三个大的部分，甚至可以在每个大的部分内部进行进一步分解，以此降低系统复杂度，便于演绎分析的实际操作。

但这样的操作可能导致在演绎分析过程中忽略系统组成部分之间的相互作用，这一点需要特别注意！

2.3 系统理论过程分析STPA

STPA(System-Theoretic Process Analysis)，即系统理论过程分析认为事故是由不当的控制引起，而不是来源于失效链，非常适合自动驾驶系统预期功能安全这样比较复杂的分析对象。

STPA属于定性的安全分析方法，其核心在于建立系统的控制模型:

首先，需要建立自动驾驶系统分析对象的控制模型。
然后，根据分析引导词，通过对控制模型中的每个控制行为(包括人类行为)进行安全分析，识别出可能会导致危害(Hazard)产生的不安全的控制行为(UCA, Unsafe Controll Action)，即可能潜在的功能不足。
最后，分析不安全控制行为产生的原因，即得到了触发条件。

STPA直接基于控制模型，对分析者者经验要求相对低，比较适合预期功能安全危害原因的分析。

仿真和测试手段

尽管利用上述安全分析手段，可以识别出绝大部分预期功能安全危害产生的原因，但依然很难保证一些特殊触发条件下的功能不足和性能局限。为了增加上述安全分析结果的完整性，还需要对自动驾驶系统进行充分的仿真和实际测试。

仿真是自动驾驶系统研发的重要手段。它的实现离不开仿真平台和运行场景库的搭建。通过对各种各样自动驾驶场景的仿真，识别可能存在的问题，进而识别出系统功能不足和对应的触发条件。

实际测试也是自动驾驶验证必不可缺的环节，需要大量的长期测试，才能发现系统存在的问题。

实际上，从系统开发V模型来看，由于目前自动驾驶技术和能力的限制，自动驾驶系统还不足以充分应对复杂的现实驾驶场景，所以我们在自动驾驶系统V模型左侧所做的开发工作实际上是不足的，虽然会导致后期开发成本增加，但也只能将工作量后移，依靠V模型右侧大量的测试验证和确认工作来弥补。随着自动驾驶技术日益成熟，预期功能安全问题将逐渐淡化，演化为功能安全问题！

END

登录阅读全文



免责声明：该内容由专栏作者授权发布或作者转载，目的在于传递更多信息，并不代表本网赞同其观点，本站亦不保证或承诺内容真实性等。若内容或图片侵犯您的权益，请及时联系本站删除。侵权投诉联系： nick.zong@aspencore.com！

汽车电子与软件主要介绍汽车电子软件设计相关内容,每天分享一篇技术文章!

进入专栏

汽车电子与软件主要介绍汽车电子软件设计相关内容,每天分享一篇技术文章!

文章：1815篇粉丝：187人

 私信

预期功能安全-SOTIF:自动驾驶系统潜在功能不足与触发条件到底如何识别?

最近文章

热门文章

推荐

最新资讯