SOTIF 标准翻译和解读：Part 4 SOTIF 各生命周期相关开发活动及开发阶段的关联关系...
ISO 21448 | SOTIF : 标准翻译和解读
Part 4 SOTIF各阶段开发过程活动概述
SOTIF的主要目的是为了规避那些因功能限制导致潜在危害行为发生的不合理风险。ISO26262功能安全和SOTIF在关于Safety主题上是互补的。
关于 SOTIF，VSI Labs 创始人 Phil Magney 也有自己的看法。他指出，“你不知道自己不知道什么”的事情，在主动安全系统和自动驾驶功能中太常见了，而这是 SOTIF 的前提。想让这个标准落地，你必须识别出那些未知且不安全的部分，然后将它们的风险级别降到可接受范围内。
ISO PAS 21448 (SOTIF)自2019年初公布以来，逐渐获得行业内部的广泛关注，本文为SOTIF标准的相关翻译和阐述，主要描述了SOTIF标准中，第四章节中定义的各生命周期相关开发活动, 以及各开发阶段的关联关系。
联席作者: ida Liu
备注：本文非SOTIF国标正式版，相关解释和相关注释仅供参考。
本SOTIF标准中每章第一节-目标（5.1、6.1、7.1、8.1、9.1、10.1、11.1和12.1）属于标准中的强制要求部分，所有其他内容全部属于参考性意见部分。在具体的工程开发实践中，可以通过列出目标，并提供已实现的相关证据的方式，来满足本标准中的要求。通过列出这些目标以及对已经实现的目标提供论证的方式来达到对本文档的符合性。
在汽车电控系统研发项目中，分布式产品开发的合作模式普遍存在，和ISO26262标准要求类似，SOTIF标准同样要求在所有开发伙伴之间定义开发接口协议(DIA)。定义开发接口协议(DIA)的目标，为确认在项目开发总体生命周期过程中，各相关方在SOTIF活动相关的所有责任和义务。
实现SOTIF的目标需要与ISO 26262:2018标准进行融合互动，并需要追加一些额外的分析和确认工作过程，这些工作相对ISO26262:2018系列标准是一种良好的补充。本文档的主要目标之一，是描述确认危险事件发生的可能性足够低的过程和基本原理。此外，本文档同样尝试评估以下方面的残余风险：
i）系统无法用安全的方式处理给定场景，以及
ii）可以接受的相关人员（司乘人员、其他车辆乘员或旁观者）不能减轻危险事件（见图6）。所涉及的人员（司乘人员或旁观者）没有能力减轻危害事件的发生，是可以接受的。<br />功能和系统规范包含相关用例，这些用例由几个相关场景组成。这些场景可能包含导致伤害的触发事件（参见第3章节定义）（见图6）。
a 这些场景也可能是其他一些情况，如由合理可预见的人为误用(mis-use)造成的，例如：在城市道路场景中，驾驶员意外激活HWP高速公路控制功能模式，会导致车辆配备的交通灯检测功能意外关闭，并威胁相关人员的人身安全；或
b 合理可预见的误用，可直接导致危险，例如：在较为复杂或者有严重干扰的场景下，即使控制系统已停用，驾驶员仍可能认为系统处于激活状态，并因继续依赖自动控制功能造成意外事故；
c 无法控制危险事件，也可导致可合理预见的误用，例如：因驾驶员注意力不集中(e.g. 注意力关注于微信抢红包)不按要求监控相关控制系统。
图6-潜在SOTIF相关可视化危险事件模型
在本SOTIF标准中，相关用例的部分场景被划分为四个区域（见图7）。
图7-已知/未知和安全/不安全场景类别定义
区域1 (已知的安全场景)、区域2 (已知的危险场景)和区域3 (未知的危险场景)用为本SOTIF标准的构思模型，区域4 (未知的安全场景)是为了完整性而引用的，但本SOTIF标准不需要，因此不再使用。在考虑模型中的区域时，可以将它们的面积大小，近似等价为表示每个区域内每种场景类型的比例。
给定的用例可以包括已知和未知场景。
与在SOTIF相关的开发活动初期，区域2 (已知的危险场景)和区域3(未知的危险场景)面积可能较大，造成不可接受的残余风险。SOTIF活动的最终目标是评估SOTIF中的区域2和区域3面积大小并提供合理论据或证据，证明这些区域足够小，因此产生的残余风险是可接受的。
虽然可以明确评估已知场景和区域2的相应用例，但区域3的场景和相应用例是通过行业最优实践方法或其它方法，（如：设计方法、系统分析或专用实验）进行评估的。这些评估的结果提供了一个论据，即：区域3面积足够小，区域2通过SOTIF改进进行管理，因此遇到这种场景的概率非常低。
在开发过程中预计区域2和区域3面积将减小，区域1面积将增大。（见图8）。
图8-ISO/PAS 21448标准的场景类别演变过程
SOTIF过程的目标涉及区域1、区域2和区域3以及这些区域对应的相关场景：
区域1：最大化或尽力维护此区域面积，同时最小化区域2和3面积。这样可以优化安全功能，保持或改善安全功能。
区域2：采用技术设计手段，缩小此区域面积到可接受的较小水平，该水平的统计意义与技术方法的相对影响相适应；评估潜在风险，必要时通过改进功能或限制功能的使用/性能将危险情况转移到区域1。
区域3：尽可能减小此区域（未知风险），并达到可接受的水平（每个检测到的危险场景都被移动到区域2）。
图9：描述了改进预期功能流程图以确保安全的基本思路。圆圈内的数字，表示本SOTIF标准中的相应章节编号。
图9-SOTIF开发活动流程图
在图9中，基本的分析过程从功能和系统规范的定义开始（详见第5章节）。对预期功能的潜在危险行为进行危险识别和风险评估（详见第6章节），以识别潜在危险事件。如果能够证明这些潜在的危险事件不会造成伤害，则无需改进，并且可以认为预期功能没有不合理的风险。
如果证明有可能造成伤害，则需要对可能引起危险的触发事件（例如:在特定环境条件下,对某些物体的错误识别或驾驶员的错误操作）进行分析（见第7章节）。
第6章节和第7章节阐述了SOTIF的不同方面，分别关注于场景分析和触发条件分析。
第6章节不考虑功能潜在危险预期行为的原因，只考虑其对安全的潜在影响后果。因此，第6章节的重点是评估可能由预期危险行为引起的危险事件，并定义验证和确认(V&V)的目标。
第7章节阐述了潜在危险行为的原因分析。
以上相关内容后期将在在第8章中逐步分解，在第9章节、第10章节和第11章节中得到了验证和确认。通过应用用例(Use Case)的功能改进或限制，进一步降低由此产生的风险（见第8章节）。
制定验证和确认(V&V)策略以证明残余风险低于可接受水平（见第9章节）。这包括实施由此衍生出的技术策略。相应的验证和确认(V&V)测试用例可从该分析中得出（详见第10章节和11章节）。<br />最后，应用验证和确认(V&V)的结果对残余风险进行评估（详见第12章节）。如果确定风险是不可接受的，则可能需要对用例进行进一步的功能改进或限制（详见第8章节）。
相关验证和确认(V &V)策略可以包括：
模型在环测试（MIL）
软件在环测试（SIL）
硬件在环测试（HIL）
实际道路场景测试
专用分析
长期耐久性测试或其它测试方法
本SOTIF标准中考虑到的非预期行为的可能原因与感知、决策、执行以及功能开发的实现密切相关。因此，本SOTIF标准中的活动，同时适用于整车开发、ADAS总成开发和零部件/传感器级别的开发项目。<br />同样，选择一个有效的且全面的系统架构设计方案，将成为SOTIF是否能够成功应用的重要基础条件。为了实现SOTIF要求的总体性能，开发人员应全面关注SOTIF的相关要求，并同时在早期概念设计阶段，和总体开发生命周期中，都确保相关活动正确执行与落地。
为确保实现SOTIF要求，同样需要考虑引入特殊的安全机制。例如：可以引入专用人机界面（HMI），以防止/减轻因驾驶员造成的，合理且可预见的错误使用（详见附录E）。在产品开发过程中，本SOTIF标准阐述的相关活动和ISO 26262:2018活动应均被重视和贯彻执行，开发团队应对SOTIF应用的方法进行相关评审或评估。
图10描述了本文档与ISO 26262:2018活动之间可能的交互关系。产品开发阶段通常需要多次迭代来确定最终的功能和系统规范，这些关系未呈现在图中。
从中选择一组方法和措施，从而：
识别和评估与SOTIF预期功能相关的危险（详见第6章节）；
识别和评估危险触发事件（详见第7章节）；
根据需要通过功能修改或用例限制来改进系统设计，以降低SOTIF风险（详见第8章节）；
验证和确认与SOTIF相关的设计的适用性（详见第9-11章节）。
注：SOTIF标准中的危险识别方法, 与ISO 26262-3:2018中描述的HARA过程相似， 因为SOTIF相关的潜在失效行为在车辆层面的影响和ISO26262系列标准所覆盖的系统失效是完全一致的。
Part 4 SOTIF各阶段开发过程活动概述
SOTIF的主要目的是为了规避那些因功能限制导致潜在危害行为发生的不合理风险。ISO26262功能安全和SOTIF在关于Safety主题上是互补的。
关于 SOTIF，VSI Labs 创始人 Phil Magney 也有自己的看法。他指出，“你不知道自己不知道什么”的事情，在主动安全系统和自动驾驶功能中太常见了，而这是 SOTIF 的前提。想让这个标准落地，你必须识别出那些未知且不安全的部分，然后将它们的风险级别降到可接受范围内。
ISO PAS 21448 (SOTIF)自2019年初公布以来，逐渐获得行业内部的广泛关注，本文为SOTIF标准的相关翻译和阐述，主要描述了SOTIF标准中，第四章节中定义的各生命周期相关开发活动, 以及各开发阶段的关联关系。
联席作者: ida Liu
备注：本文非SOTIF国标正式版，相关解释和相关注释仅供参考。
本SOTIF标准中每章第一节-目标（5.1、6.1、7.1、8.1、9.1、10.1、11.1和12.1）属于标准中的强制要求部分，所有其他内容全部属于参考性意见部分。在具体的工程开发实践中，可以通过列出目标，并提供已实现的相关证据的方式，来满足本标准中的要求。通过列出这些目标以及对已经实现的目标提供论证的方式来达到对本文档的符合性。
在汽车电控系统研发项目中，分布式产品开发的合作模式普遍存在，和ISO26262标准要求类似，SOTIF标准同样要求在所有开发伙伴之间定义开发接口协议(DIA)。定义开发接口协议(DIA)的目标，为确认在项目开发总体生命周期过程中，各相关方在SOTIF活动相关的所有责任和义务。
实现SOTIF的目标需要与ISO 26262:2018标准进行融合互动，并需要追加一些额外的分析和确认工作过程，这些工作相对ISO26262:2018系列标准是一种良好的补充。本文档的主要目标之一，是描述确认危险事件发生的可能性足够低的过程和基本原理。此外，本文档同样尝试评估以下方面的残余风险：
i）系统无法用安全的方式处理给定场景，以及
ii）可以接受的相关人员（司乘人员、其他车辆乘员或旁观者）不能减轻危险事件（见图6）。所涉及的人员（司乘人员或旁观者）没有能力减轻危害事件的发生，是可以接受的。<br />功能和系统规范包含相关用例，这些用例由几个相关场景组成。这些场景可能包含导致伤害的触发事件（参见第3章节定义）（见图6）。
a 这些场景也可能是其他一些情况，如由合理可预见的人为误用(mis-use)造成的，例如：在城市道路场景中，驾驶员意外激活HWP高速公路控制功能模式，会导致车辆配备的交通灯检测功能意外关闭，并威胁相关人员的人身安全；或
b 合理可预见的误用，可直接导致危险，例如：在较为复杂或者有严重干扰的场景下，即使控制系统已停用，驾驶员仍可能认为系统处于激活状态，并因继续依赖自动控制功能造成意外事故；
c 无法控制危险事件，也可导致可合理预见的误用，例如：因驾驶员注意力不集中(e.g. 注意力关注于微信抢红包)不按要求监控相关控制系统。
图6-潜在SOTIF相关可视化危险事件模型
在本SOTIF标准中，相关用例的部分场景被划分为四个区域（见图7）。
图7-已知/未知和安全/不安全场景类别定义
区域1 (已知的安全场景)、区域2 (已知的危险场景)和区域3 (未知的危险场景)用为本SOTIF标准的构思模型，区域4 (未知的安全场景)是为了完整性而引用的，但本SOTIF标准不需要，因此不再使用。在考虑模型中的区域时，可以将它们的面积大小，近似等价为表示每个区域内每种场景类型的比例。
给定的用例可以包括已知和未知场景。
与在SOTIF相关的开发活动初期，区域2 (已知的危险场景)和区域3(未知的危险场景)面积可能较大，造成不可接受的残余风险。SOTIF活动的最终目标是评估SOTIF中的区域2和区域3面积大小并提供合理论据或证据，证明这些区域足够小，因此产生的残余风险是可接受的。
虽然可以明确评估已知场景和区域2的相应用例，但区域3的场景和相应用例是通过行业最优实践方法或其它方法，（如：设计方法、系统分析或专用实验）进行评估的。这些评估的结果提供了一个论据，即：区域3面积足够小，区域2通过SOTIF改进进行管理，因此遇到这种场景的概率非常低。
在开发过程中预计区域2和区域3面积将减小，区域1面积将增大。（见图8）。
图8-ISO/PAS 21448标准的场景类别演变过程
SOTIF过程的目标涉及区域1、区域2和区域3以及这些区域对应的相关场景：
区域1：最大化或尽力维护此区域面积，同时最小化区域2和3面积。这样可以优化安全功能，保持或改善安全功能。
区域2：采用技术设计手段，缩小此区域面积到可接受的较小水平，该水平的统计意义与技术方法的相对影响相适应；评估潜在风险，必要时通过改进功能或限制功能的使用/性能将危险情况转移到区域1。
区域3：尽可能减小此区域（未知风险），并达到可接受的水平（每个检测到的危险场景都被移动到区域2）。
图9：描述了改进预期功能流程图以确保安全的基本思路。圆圈内的数字，表示本SOTIF标准中的相应章节编号。
图9-SOTIF开发活动流程图
在图9中，基本的分析过程从功能和系统规范的定义开始（详见第5章节）。对预期功能的潜在危险行为进行危险识别和风险评估（详见第6章节），以识别潜在危险事件。如果能够证明这些潜在的危险事件不会造成伤害，则无需改进，并且可以认为预期功能没有不合理的风险。
如果证明有可能造成伤害，则需要对可能引起危险的触发事件（例如:在特定环境条件下,对某些物体的错误识别或驾驶员的错误操作）进行分析（见第7章节）。
第6章节和第7章节阐述了SOTIF的不同方面，分别关注于场景分析和触发条件分析。
第6章节不考虑功能潜在危险预期行为的原因，只考虑其对安全的潜在影响后果。因此，第6章节的重点是评估可能由预期危险行为引起的危险事件，并定义验证和确认(V&V)的目标。
第7章节阐述了潜在危险行为的原因分析。
以上相关内容后期将在在第8章中逐步分解，在第9章节、第10章节和第11章节中得到了验证和确认。通过应用用例(Use Case)的功能改进或限制，进一步降低由此产生的风险（见第8章节）。
制定验证和确认(V&V)策略以证明残余风险低于可接受水平（见第9章节）。这包括实施由此衍生出的技术策略。相应的验证和确认(V&V)测试用例可从该分析中得出（详见第10章节和11章节）。<br />最后，应用验证和确认(V&V)的结果对残余风险进行评估（详见第12章节）。如果确定风险是不可接受的，则可能需要对用例进行进一步的功能改进或限制（详见第8章节）。
相关验证和确认(V &V)策略可以包括：
模型在环测试（MIL）
软件在环测试（SIL）
硬件在环测试（HIL）
实际道路场景测试
专用分析
长期耐久性测试或其它测试方法
本SOTIF标准中考虑到的非预期行为的可能原因与感知、决策、执行以及功能开发的实现密切相关。因此，本SOTIF标准中的活动，同时适用于整车开发、ADAS总成开发和零部件/传感器级别的开发项目。<br />同样，选择一个有效的且全面的系统架构设计方案，将成为SOTIF是否能够成功应用的重要基础条件。为了实现SOTIF要求的总体性能，开发人员应全面关注SOTIF的相关要求，并同时在早期概念设计阶段，和总体开发生命周期中，都确保相关活动正确执行与落地。
为确保实现SOTIF要求，同样需要考虑引入特殊的安全机制。例如：可以引入专用人机界面（HMI），以防止/减轻因驾驶员造成的，合理且可预见的错误使用（详见附录E）。在产品开发过程中，本SOTIF标准阐述的相关活动和ISO 26262:2018活动应均被重视和贯彻执行，开发团队应对SOTIF应用的方法进行相关评审或评估。
图10描述了本文档与ISO 26262:2018活动之间可能的交互关系。产品开发阶段通常需要多次迭代来确定最终的功能和系统规范，这些关系未呈现在图中。
从中选择一组方法和措施，从而：
识别和评估与SOTIF预期功能相关的危险（详见第6章节）；
识别和评估危险触发事件（详见第7章节）；
根据需要通过功能修改或用例限制来改进系统设计，以降低SOTIF风险（详见第8章节）；
验证和确认与SOTIF相关的设计的适用性（详见第9-11章节）。
注：SOTIF标准中的危险识别方法, 与ISO 26262-3:2018中描述的HARA过程相似， 因为SOTIF相关的潜在失效行为在车辆层面的影响和ISO26262系列标准所覆盖的系统失效是完全一致的。
