如何理解预期功能安全

当前汽车行业热度非常高的三个标准为预期功能安全ISO21448，功能安全ISO26262和网络安全ISO21434，其中预期功能安全对于系统开发者来说比较陌生，容易将它与功能安全混为一谈，预期功能安全要解决的问题是什么，为什么要在功能安全之外还要考虑预期功能安全，网上已经有很多的资料去讲，本篇谈谈对预期功能安全概念的理解。

背景

Road vehicles - safety of the intended functionality SOTIF（道路车辆 预期功能安全）标准在2019年1月作为公开技术规范发布（ISO/PAS 21448），正式版预计将于2022年发布，目前PAS版本共有29页+23页附件，重点关注SAE自动化level 1和level 2驾驶辅助功能。

这个规范用于降低由于系统的预期功能不足（设计不足或性能局限）或可预见的人员误操作导致的不可接受风险，这也是预期功能安全概念的定义，适用的电子系统为安全功能受外部环境影响的功能，来自于传感器和处理算法，典型的有AEB自动紧急制动系统、车道保持系统等高级驾驶辅助系统。

预期功能安全概念

功能安全在于解决系统内的随机失效和系统性失效引起的危害，造成安全事故，包括硬件故障、软件故障，而系统功能正常时出现的危害不在功能安全考虑的范围内，由于使用传感器或算法的性能限制，驾驶人员对系统的误操作，SOTIF规范的推出旨在解决这一类问题。下图来自中国汽车标准化技术委员会在2020年发布的《预期功能安全国际标准ISO21448及中国实践白皮书》，用于说明功能安全与预期功能安全概念的区别。

SOTIF关注领域

一、系统的运行设计域ODD（或称为运行场景）超出了系统和部件性能限制，比如一个自动巡航系统在其ODD范围内（高速公路、天气良好）运行，遇到了有低照明条件的情况，超出了前置摄像头的性能限制；

二、人为因素对系统的影响，特别是与人机交互界面的接口。如驾驶员没有将手放在方向盘上（在需要时）；驾驶员对系统能力和限制的理解，以及驾驶员的责任；以及驾驶员理解和应对警告和警报的能力。

在SOTIF规范中，也对不同标准适用的范围进行了说明，如下表，此表为笔者对英文版规范的翻译，如有差异，以原文为准。

SOTIF四象限概念

预期功能安全提出了四象限图的概念，用于确定系统所在的各类场景，这个概念类似于IEC61508中安全失效率λs、危险失效率λd的概念，不过SOTIF所关注的外部触发事件造成的危害，不是系统内失效引起的危害。

Area 1代表已知的安全场景，这是系统有能力处理的安全场景，例如这些场景已经完全在系统的ODD范围内，也可以是现有措施可以解决的场景。

Area 2代表已知的不安全场景，这些是系统设计者已知的场景，在这些场景下，系统不能安全地运行。系统设计者可以通过几种途径：

• 分析方法（FTA、FMEA、HAZOP、STPA等方法）；
• 已有运行的现场数据和事故案例；
• 已有系统开发的经验教训；
• 标准、指南和行业最佳实践

找出导致系统处于Area 2的触发事件，对系统进行功能迭代优化，促成Area 2向Area 1的转化。

Area 3代表未知的不安全场景，这些是系统设计者不知道的场景，因此没有现实的数据和案例支持做决策，需要通过分析方法（FTA、FMEA、HAZOP、STPA等方法）、仿真和实际道路测试进行触发，以识别出未知的不安全情况，促成Area 3向Area 2的转化。

Area 4代表未知的安全场景，这些场景系统可以安全处理，因此SOTIF并不识别这些场景。

四象限中，Area 3的范围是SOTIF的最大挑战，它不可能完全消除，剩余的未知不安全场景将作为系统的残余风险，最终评判是否可接受。

 

SOTIF生命周期模型 VS ISO26262生命周期模型

在汽车电子系统的研发过程中，伴随着功能安全和预期功能安全从风险分析、安全需求确定、软件和硬件的设计、验证与确认过程。下图在ISO26262生命周期模型中标注了SOTIF对应的阶段。

上图中标红的是SOTIF生命周期模型阶段，具体为

• ISO21448.5：functional and System specification

• ISO21448.6：SOTIF related hazard identification and evaluation

• ISO21448.7：identification and evaluation of triggering events

• ISO21448.8：functional modifications to reduce SOTIF risks

• ISO21448.9：definition of the verification and validation

• ISO21448.10：verification of the SOTIF: evaluate known scenarios

• ISO21448.11：validation of the SOTIF: evaluate unknown scenarios

• ISO21448.12：methodology and criteria for SOTIF release

从上面的生命周期模型映射关系来看：

1.  对于功能安全和SOTIF来说，系统的边界、功能、场景条件的假设，对于两者都很重要，而SOTIF更要确定设计使用的传感器类型、关键算法功能的初步描述，因为这些定义对于SOTIF风险分析很重要；
   
   
2. 功能安全HARA风险分析用于识别安全目标，从而将安全目标分解到软硬件层面；而SOTIF不会给每个功能规定一个安全等级，在于找到促成风险向区域2，进而向区域1转化的措施；
   
   
3.  预期功能安全没有像功能安全标准一样，规定软硬件的设计实现方法，而重点放在对风险减轻措施的验证和确认策略上，这一点可能是从所实现技术的更新迭代速度，对于标准来说，规定做什么，而不规定怎么做，但笔者建议，对于ISO26262的技术方法，如果SOTIF同样采用了类似的技术，应该参考ISO26262的要求来做；
   
   
4. SOTIF对于传感器、决策算法、执行器给出了推荐性的验证与确认策略，用于避免累积跑无效里程，而采用需求驱动、风险事件驱动的VV策略。

 

HARA VS SOTIF风险评估

实际项目实施中，没有必要分别去做HARA和SOTIF风险分析，整车级危害所引出的安全目标可以基于同一个过程来做，但在SOTIF会识别出可预见的人员误操作造成的顶层危害，以车道保持系统（实现车辆的居中和变道行驶）为例，在功能安全中，整车级危害有：

• 车道保持系统启动过程中发生车道偏离；
• 在目标车道上由于障碍物或车道被占变道；
• 车辆未完成变道或跨越到两车道；
• 系统对更高优先级的安全系统造成干扰（争夺控制权）

而从SOTIF角度，考虑到可预见的司机误操作，还存在的危害有：

• 司机与系统之间控制权的转换不当；

造成的事故后果可能是撞行人、与迎面车辆相撞、撞击障碍物、追尾车辆、侧面相撞，判断风险等级都是从可控性、严重性、暴露性三个方面去评价，以确定整车级的安全目标。

预期功能安全的启发

春节前发生的地铁夹人导致伤亡的事件，事故造成的影响很大，引发了社会公众对于无人驾驶系统的关注，现在还未发布最终的事故报告，根据现场的视频和各方的分析，与现场站务人员在处理站台门夹人故障情况下操作有关，从SOTIF角度，这也是一个系统故障（屏蔽门夹人）叠加人员误操作造成了更严重的事故。

从系统安全角度会做操作与维护造成危害的安全分析，但从功能安全的角度，多数把人员的失效排除在系统设计范围外，通过对人员的管理规定进行落实。但从各行业的历次事故报告来看，在紧急状况下，人往往是靠不住的，比如737 MAX事故中自动驾驶系统与驾驶员控制权的争夺，723事故中高铁信号系统故障后调度员未对司机进行及时提醒。从预期功能安全的角度，对人员误操作开展风险分析，并制定相应的验证确认策略，就有很大的必要性。

按照预期功能安全对人员误操作进行安全分析，需要考虑的情况有：

• 操作人员对系统信息的识别，需要考虑操作人员对系统给出信息不理解和理解错误（信息发生混淆）的情况；
• 操作人员错误的判断，无意对系统的停用、错误的启动和解除系统；
• 操作人员错误的动作，对其它系统错误操作导致本系统无意地停用；
  
• 人机界面接口的控制和响应操作错误。
  

谈预期功能安全的触发事件triggering event，它指的是车辆驾驶场景的某个特定条件，启动了系统的特定反应，导致危害事件发生。

在ISO21448中举了一个例子：车辆在高速公路上行驶过程中，车辆的自动紧急制动系统AEB误认为路标是前方的一辆车，从而以X g的减速度减速Y秒。

这个示例中，触发事件是AEB的感知子系统对前方物体的识别发生了误判，危害事件是非预期的减速，可能导致车辆的追尾事故。

ISO21448定义的第一类触发事件是超过系统和部件性能限制的事件，需要针对系统设计所使用的技术，以车道保持系统使用的camara和radar为例，列举几个典型的SOTIF触发事件。

例1：环境中的干扰因素如道路的光线反射，会影响相机检测车道标线的能力，下图中对光线反射亮斑的识别

例2：相机对路面环境条件的检测可能造成的误判，下图中车轮行驶印迹与车道线的混淆

例3：雷达天线上覆盖水膜对雷达信号的损失衰减，下图中水膜厚度的增加对雷达天线功率的影响，引自[1] https//www.hirecpaint.com

以上这些示例都属于感知组件中在物理环境中的局限性导致的性能下降，在系统的功能安全分析过程中，不会覆盖此类性能局限下的影响分析，这类外部环境对系统传感器、控制器、执行器的影响是SOTIF的范围。

第二类触发事件是潜在可能的非预期的人为误操作，第一类触发事件中，有人机界面的限制，人机界面属于系统内的一部分，也存在潜在的性能不足，还有的触发事件是人为潜在的可预见的误用。

列举几个典型的SOTIF第二类触发事件：

例1：驾驶员难以接触系统控制界面（如果系统控制位于子菜单中或控制界面的按钮位置设计较远）。

例2：车道保持系统在控制过渡期结束时将控制权还给驾驶员，未考虑司机的注意力状态。

例3：驾驶员将其他车辆系统反馈的信息，如其它系统发出的警告，误认为是自动车道保持系统的警告。驾驶员可能会操作车道保持系统的控制功能，而不是操作其他系统的控制功能。

例4：驾驶员在系统的ODD范围外启动自动车道保持系统，不满足进入系统功能的条件。

在ISO21448附件E中描述的三个阶段的人为操作过程：

1. 对信息的获取
2. 对信息的判断
3. 对系统的操作

将人类比于一个系统，按照I-P-O的方式去分析三个环节中存在的各种误操作因素。

SOTIF规定的第1类和第2类触发事件相当于功能安全HARA分析中的危害识别，触发事件的识别是一个不断递进往复的过程，它的细化程度决定了减轻措施的针对性。

在ISO21448中，减轻措施的类别可以归为以下几种：

对系统性能限制的减轻策略

• 限制系统操作或特定使用情况（降级条件）下的权限。
• 防止系统在特定的使用情况下运行。

设计改进的缓解策略

• 提高算法的性能。
• 采用多样化的传感器技术以规避单一传感器的性能受限。
• 调整传感器位置。
• 检测传感器受到的干扰并作出反应。
• 确定系统所处于ODD的极限边界。
• 改进控制执行技术，包括反应时间、准确度、耐久程度和可靠性能力。
• 检测并应对已知的不支持的user case。
• 针对已知的不安全情况，通过系统和组件的可测试性进行检测。

缓解策略，以改善人的后备操作，减少可预见的误用

• 改进人机界面。
• 改进预警和降级策略。
• 提高司机对系统限制的理解。

理解了SOTIF的触发事件，如何开发完备的针对所考虑系统的触发事件场景，是一个具有挑战性的工作，如何从具有无限种可能性的场景分析中找出影响系统预期功能的触发事件，这个方面在ISO21448中并没有提供明确的指导方法。

在系统开发V模型中的上升阶段，什么时候意味着开发可以收口，系统达到了发布的条件，从风险管理的角度，就是说具备什么条件，意味着系统残余的风险可以接受，在预期功能安全中，可以总结为两句话：

一：所有已知的风险已有对应措施进行了控制（区域2）——ISO21448第10节

二：所有未知的风险在实际运行中已经足够小（区域3）——ISO21448第11节

下面对这两个方面展开谈谈

第一句是对已知的不安全情况（区域2）进行评估，确保在采取SOTIF缓解措施的情况下，已知情况下导致危害事件，不存在不合理的风险了。缓解措施可能包括限制系统应用范围ODD，进行传感器和算法的冗余设计。风险接受的重点在于是否根据已知的缓解措施对传感器、算法、执行器和集成后的系统进行有针对性的测试。ISO21448提供了一系列测试方法的组合，包括分析、模拟仿真和实车测试，用于对区域2的各种场景进行全面的测试。

验证技术的运用不那么简单，寥寥数语，实际做起来非常考验安全和验证人员的能力。举个例子，对于第一点，已知不安全情况的风险评估，在采用了冗余的系统架构时，不同计算通道的独立性是需要验证的。而独立性要从系统失效的独立性（软件和硬件）和随机失效的独立性（硬件）两个方面进行验证，例如软件系统性失效方面如使用了两个不同类型算法的分类器，但采用了相同的数据集进行训练，容易对相同的样本产生同一错误的输出，因此建议采用有区分度的数据集进行训练，硬件系统性失效，如主计算通道和辅计算通道采用了不同的硬件平台进行冗余计算，但存在采用了同一电源，在同一个电路板上，存在由于电源波动和EMI干扰，导致多样化硬件同时失效的情况，这些都是系统保证独立性需要考虑的因素。

比如在基于触发事件进行场景测试时，要求单个触发事件有明确的场景条件，基于场景可以去构建测试案例，如果危害分析中的触发事件比较笼统，则需要进行额外的分析，以建立基于场景的测试案例。以车道保持系统触发事件——车道线被覆盖导致相机无法检测到，需要考虑的场景变量就有很多种：

车辆行驶的地点有：出入高速口、车道并窄、分叉口、弯道左转、弯道右转、施工维修路障；

覆盖物类型有：水完全淹没、雪、沙、雨水淋、泥浆、淤泥、标线模糊、跌落异物。