如何理解预期功能安全（一）

当前汽车行业热度非常高的三个标准为预期功能安全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事故中高铁信号系统故障后调度员未对司机进行及时提醒。从预期功能安全的角度，对人员误操作开展风险分析，并制定相应的验证确认策略，就有很大的必要性。

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

• 操作人员对系统信息的识别，需要考虑操作人员对系统给出信息不理解和理解错误（信息发生混淆）的情况；

• 操作人员错误的判断，无意对系统的停用、错误的启动和解除系统；

• 操作人员错误的动作，对其它系统错误操作导致本系统无意地停用；
  

• 人机界面接口的控制和响应操作错误。
  

如能得到更多行业同仁的关注和点赞，笔者将结合实例做一些预期功能安全的具体分析。

原文始发于微信公众号（薄说安全）：如何理解预期功能安全（一）