预期功能安全标准：ISO PAS 21448（二）

自动驾驶车辆的安全风险来源包含系统失效、功能局限性及网络安全等。国际标准ISO 21448由12个章节及7个附录构成，围绕自动驾驶车辆的功能局限性(含设计不足和性能局限)，在复杂环境影响和人员合理误用的情况下，避免或降低车辆潜在的安全风险。

本文主要包括ISO 21448第四章的内容，这部分内容主要给出了ISO 21448的一些说明。

4本文档在开发过程中的活动概述

一、 一些说明

1.ISO 21448本文件的目标章节(5.1、6.1、7.1、8.1、9.1、10.1、11.1和12.1)是规范性的，所有其它内容都是信息性的。通过列出目标并提供目标已实现的论据，可以声称遵守了本文件。

2.当适用于分布式产品开发时，可以在所有开发人员之间定义开发接口协议。协议的目标是在项目的早期阶段确定SOTIF活动的所有职责。

3.实现SOTIF需要一些与ISO 26262:2018系列相补充的活动。ISO 21448本文件的主要目标之一是勾画出用于确保危险事件的可能性足够低的过程和基本原理。此外，本文件还试图评估来源于以下两个原因的剩余风险：

1）无法以安全方式处理给定场景的系统；

2）有关人士（司机、其他车辆拥有者或旁观者）没有能力减轻危险事件，这种危险时间是可以接受的。

4.功能和系统规范包括由几个相关的场景组成的用例。这些场景可能包含导致伤害的触发事件(见第3章节的定义)

二、ISO 21448 场景分类

一个用例会包含四种场景： 已知的安全场景（区域1）、已知的不安全场景（区域2）、未知的不安全场景（区域3）、未知的安全场景（区域4）

三、ISO 21448 SOTIF目标

在开发初期，第2区域和第3区域可能太大，导致无法接受的剩余风险。SOTIF活动的最终目标是评估区域2和区域3的SOTIF，并提出一个论点，即这些区域足够小，因此产生的剩余风险是可接受的。

区域2的已知场景和相应的用例可以明显地评估；区域3的场景和相应的用例是通过行业最佳实践或其他方法（如：设计措施，系统分析，或专门的实验）进行评估。这些评估的结果提供了一个论据，即，区域3足够小，而区域2通过SOTIF改进进行管理，因此遇到这种情况的概率足够低。

注：这个区域模型更适合理解为各种情况的占比。

SOTIF过程在区域1、区域2和区域3及相关场景的的目标是：

1、区域1：最大化或维护区域，同时最小化区域2和3，这将保留或提升安全功能；

2、区域2：将采用技术措施将该区域减少到可接受的水平，该水平具有一定的统计学意义，与减小区域2所采取技术措施产生的影响相适应。评估潜在风险，有必要的话，通过改进功能或限制功能的使用/性能，将危险场景移至区域1；

3、区域3：在可接受的努力水平下，尽可能减少区域3（未知的风险）（每个检测到的危险场景都移到区域2）。

四、SOTIF流程

ISO 21448 圆圈的序号代表后面各章节号。

5. 功能和系统规范的定义。

6. 对预期功能可能存在的危险行为进行危害识别和风险评估。这里不考虑原因，只评估可能由危险预期行为导致的危险事件，并定义要满足的验证和确认目标。

7. 识别和评估触发事件。这里重点考虑原因。

8. 功能完善或用例限制，避免或降低SOTIF风险。在9、10、11章节都会应用到。

9. 提出了一种验证和确认策略，以证明剩余风险低于可接受的水平。测试用例在这个阶段设计出。

10. 在已知危险场景中验证SOTIF。已知危险场景是否被覆盖？系统和部件是否按预期工作？

11. 在未知危险场景中验证SOTIF。系统和部件在真实场景中是否会引起不合理风险？

12. 剩余风险评估，通过验证和确认工作评估风险是被接受还是功能完善或用例限制。

在图9中，流程从功能和系统规范的定义开始(参见第5章节)。预期功能可能存在的危险行为需要进行危险识别和风险评估(见第6章节)，以识别潜在的危险事件。如果这些潜在的危险事件不会导致危害，那么就没有必要进行任何改进，并且预期的功能可以被认为没有不合理的风险。

如果它表明危害是可能的，那么分析可能的危险触发事件(参见章节7)(例如：对某些环境条件下的某些物体进行误检或驾驶员误操作)。

第6章节和第7章节涉及SOTIF的不同方面。第6章节没有考虑功能预期行为可能发生的危险的原因，只考虑了它们对安全的后果。因此，第6章节集中于评估可能由危险预期行为导致的危险事件，并定义要满足的验证和确认目标。第7章节论述了潜在危险行为的原因分析。这些在第8章节中有所缓解，并在第9章节、第10章节和第11章节中得到验证。

应用用例的功能改进或限制来避免这些危害或进一步减少产生的风险(见第8章节)。

制定了验证和确认策略，以提供关于剩余风险低于可接受水平的论证(参见第9章节)，包括相关策略的实施。从这个分析中可以得出相应的验证和确认测试用例(参见第10和11章节)。

最后，根据验证和确认的结果对剩余风险进行评估(第12章节)。如果决定是不可接受的风险，有必要进一步功能改善或限制用例(章节8)。这种验证和确认策略可以包括模型在环(MIL) 、软件在环(SIL)、硬件在环(HIL)，测试跟踪实验、特定分析，长期耐力测试等方法。

本文档中所考虑的意外行为的可能原因与正在开发功能的感知、算法处理、驱动及其实现的性能密切相关。因此，本文档的活动适用于整车、系统和零部件级别。

同时，有能力的、整体的系统架构的选择是确保SOTIF的主要关注点，并且，为了确保整体的能力，相应的活动在早期阶段和整个功能开发生命周期中都在进行。

可能有必要制定确保SOTIF的具体机制。例如，一个专用的可以定义人机界面(HMI)来防止/减轻驾驶员一些合理可预见的误操作(见附件E)。

在产品开发过程中，本文件的活动和ISO 26262:2018中规定的活动都得到了执行，并采取了相应的措施进行SOTIF评估，如下图所示。

图10描述了本文档与ISO 26262:2018系列活动之间可能的交互。产品开发阶段通常需要几个迭代来产生最终的功能和系统规范。图中没有表示出这些迭代。

选择一套方法和措施是为了：

1、识别和评估与预期功能相关的SOTIF相关的危害(第6章节)；

2、识别和评估危险触发事件(第7章节)；

3、需要通过功能修改或用例限制来改进系统设计，以减少SOTIF风险(第8章节)；

4、验证和确认工作设计的适当性(第9-11章节)

注：危险识别过程类似于ISO 26262-3:2008中描述的过程，因为SOTIF相关的车辆级别的潜在危险行为和ISO 26262涵盖的系统故障的影响可能是相同的。

注：本文内容参考了CSDN博主道道2020所发的相关博客，网址https://blog.csdn.net/qq_25320393