02 | SOTIF: 一文看懂SOTIF工作流程

shuizhonghua

本篇属于预期功能安全SOTIF专题系列第02篇内容，我们从全局概览视角出发，一文带你了解预期功能安全ISO 21448如何解决预期功能安全问题。

阅读之前强烈建议参考之前系列文章:

01 | 预期功能安全-SOTIF: 自动驾驶安全困局

在上一篇文章我们聊到了自动驾驶的技术困局，预期功能安全以及标准ISO 21448，那么:

那ISO 21448这个标准到底在讲什么?

它和功能安全ISO 26262有什么区别?

解决问题的流程是什么?

带着这些问题，我们开始今天的内容。
01

预期功能安全 vs. 功能安全

从本质上来讲，预期功能安全(SOTIF)和功能安全(Functional Safety)都是在解决汽车电子电气系统的危害问题，二者相辅相成，只不过侧重点或者导致危害的来源不同而已。·  功能安全(Functional Safety):
─ 旨在避免因电子电气系统故障而导致的不合理风险，其危害来源于电子电气系统的故障，该故障是由系统性失效和硬件随机失效产生。
─ 适用于汽车各系统的开发，包括高级辅助驾驶及自动驾驶系统。─ 功能安全系统性失效和硬件随机失效基本上都属于已知运行场景下功能安全失效问题。·  预期功能安全(SOTIF):
─ 旨在解决由功能不足、或由可合理预见的人员误用所导致的危害和风险，其危害不源于功能失效，而是系统功能不足或合理人为误用。

例如，传感系统在恶劣环境情况下，本身并未发生故障，但不能按照预期执行预期的功能。
─ SOTIF是在自动驾驶技术发展的大背景下提出，是自动驾驶从L2到L3升级的必然需求。随着自动驾驶技术的发展，人们发现车辆安全问题并非都源于系统错误和失效。在复杂的系统以及场景中，问题时常源于外部环境影响带来的非预期性安全问题。
─ SOTIF安全开发活动多基于场景(Scenarios)，ISO 21448将将其研究场景划分为如下所图9.16示的4个区间:



Area 1: 已知-安全

Area 2: 已知-不安全

Area 3: 未知-不安全

Area 4: 未知-安全

预期安全活动的目的是尽可能缩小位于区间2和3中的场景的比例，将其转化为1和4的场景，确保场景控制在安全的区间。预期功能安全解决的问题都集中在区间2和3，其中区间3，即未知不安全运行场景下的预期功能安全问题是SOTIF问题的特殊之处且难以解决。

02

预期功能安全开发流程

为解决预期功能安全问题，ISO 21448开发流程为此制定了12个关键开发活动，具体如下：



·   规范定义和设计：SOTIF流程始于规范定义和设计(见ISO 21448，第5章)，规范定义和设计中包含了那些在后续SOTIF活动和周期开始前就已知的性能局限和功能不足。这部分内容和功能安全ISO 26262概念阶段中相关项的定义基本类似(具体见第3.2章节），都是对研究对象(对SOTIF而言，为不同级别的自动驾驶系统)的组成(系统及其要素)、功能和性能局限性(例如，分类不足，测量不足，运动学估算不足，假阳/阴性探测等)的充分理解，最终会形成一份已知的功能不足、相关的触发条件及其应对措施(如果已经存在或定义)的详尽列表，以便执行后续阶段的活动。·   危害分析和风险评估：危害分析和风险评估(见ISO 21448，第6章)基本上安全参考ISO 26262中相应内容(具体见第3.3章节)，同样也是根据研究对象整车级别功能安全分析，例如HAZOP，评价危害事件的暴露度(S)、可控度(E)、严重性(C)，只是对SOTIF而言，不会根据S、E、C确定综合的ASIL等级，而是会定义危害事件的接受准则，预期功能安全的接受准则包含两个层面(所谓的双层接受准则)，即：
─ 第一层：判断车辆行为是否属于危害行为而可能导致危害事件的准则，即危害行为接受准则；
─ 第二层：针对不满足危害行为接受准则的那些行为，可导致S>0且C>0的危害事件，需要进一步判断车辆运行过程中残余安全风险是否处于合理水平的准则，即残余风险接受准则，并将其作为这一阶段的工作输出结果，在下一个开发阶段进一步确定其触发条件。·   潜在功能不足与触发条件识别：根据危害分析和风险评估结果，针对不满足危害行为接受准则的那些行为，我们需要识别其触发条件，即分析由哪些原因导致该事件的产生(见ISO 21448，第7章)。针对自动驾驶系统，一般会根据其“感知-规划-执行”模型，对规划算法、传感器和执行器，以及环境条件和合理可预见误用，进行系统性分析，识别和评估潜在规范定义不足、性能局限、输出不足和触发条件。例如，触发条件可以外部环境干扰，道路基础设施，已知规划算法的局限性，感知和执行的精度问题等。触发条件是构成危害事件，进而产生危险的直接诱发因素，也是SOTFI流程中为后续进行系统优化和改进的重要基础。·   系统的优化与改进：通过潜在功能不足与触发条件的识别，则需要根据已有设计，判断系统是否有相应的安全措施应对这些风险。如果没有的话，那么就需要对系统进行改进与优化(见ISO 21448，第8章)，包括提高性能(更好的传感器技术，算法等)，系统修改(冗余、多样性和互补要素)，功能限制，权限移交等手段，并对规范定义和设计进行更新。·   定义验证和确认策略：旨在制定适当的验证和确认策略(见ISO 21448，第9章)，以提供证据来证明系统：─ 验证：在组件层面，来自已知危害场景的潜在的危害行为得到全面且有效的控制。─ 确认：在整车层面，来自已知和未知危害场景的残余风险满足接受准则并具有足够的置信度。具体而言，就是为后续已知危害场景的评估和未知危害场景(残余风险)的评估，提供相应的策略，包括集成定义，验证和确认活动的导出方法，确认目标定义等。这部分内容和功能安全ISO 26262中第7章节内容，即系统阶段(II)中的验证确认方法基本类似。·   已知场景的评估：对于已知场景的评估，包括了对已知场景的验证和确认。对于已知的危害场景的验证部分，根据上一部分内容中的验证和确认策略，只需要对其进行基于场景的验证即可(见ISO 21448，第10章)，同样根据自动驾驶系统决策模型(感知-规划-执行)，分别对其进行感知的验证，规划算法的验证，执行的验证和系统集成的验证，只是根据验证对象的不同其验证方法有所区别，验证手段多以仿真和测试为主。对于已知的危害场景的确认部分，则需要通过验证结果证明其残余风险在可控合理的范围内。这一部分的内容，对于SOTIF来讲，其实属于相对比较容易解决的问题，本质上和功能安全解决问题的思路是一样的，只是对象和危害根源不同而已。·   未知场景的评估：对于未知危害场景的评估，主要是未知场景的确认，目的是确认来自未知危害场景的残余风险满足接受准则并具有足够的置信度(见ISO 21448，第11章)，这部分是SOTIF最难解决的问题，也是和功能安全相比，全新的存在的内容。对此，ISO 21448也没有太多的解决办法，只能依靠大量的长期测试进行确认，以极大的数据量覆盖未知场景，包括一些非常极端的小概率场景。·   SOTIF成果评估：SOTIF成果评估(见ISO 21448，第12章)，主要是对 SOTIF 活动产生的工作成果的完整性、正确性和一致性进行评审，给出并确认发布建议，包括“接受”、“有条件接受”或“拒绝”SOTIF发布的建议。这部分内容和功能安全中的第8.2.4章节认可措施有点类似，主要是对SOTIF流程和各阶段工作成果进行审核和评估。·   运行阶段的活动：该部分属于ISO 21448，第13章内容，主要是发布之前定义现场监控流程，以确保运行期间的 SOTIF.
场监控流程的程度需要根据驾驶自动化等级、预期功能的复杂程度以及危害的严重程度进行预期。 对于较低的驾驶自动化等级，通常的市场监管程序可能已足够。 但对于较高的驾驶自动化等级，需要额外的手段，例如自动驾驶数据存储系统(DSSAD)/汽车事件数据记录系(EDR)和车载/远程安全监控系统等。这些手段可以监测和记录车辆的性能和行驶情况，并提供实时的安全监测和控制，以确保自动驾驶车辆的安全和可靠性。