StpA（浅谈预期功能安全）

作者为CY，投稿本专栏，原载于RAMS工程师

“SOTIF”越来越引起人们的关注。小编也忍不住凑了热闹，于几天前在斯德哥尔摩参加了名为“SOTIF and Functional Safety for Automated Driving”的研讨会。此次研讨会由瑞典皇家理工（KTH）举办，邀请了来自工业界和高校的相关人员。近4个小时的分享和讨论，让小编开始了对SOTIF的更多思考。

鉴于目前能公开检索到的关于SOTIF的中文资料还不多，小编试着归纳整理了今年搜集的相关资料，外加一些个人解读写成本文，仅供入门参考。小编接触SOTIF的时间不长，理解可能有偏颇，欢迎批评指正。部分中文翻译可能有待商榷。

1. 背景

随着Advanced Driver Assistance Systems（ADAS）系统越发复杂，引入了各种复杂的传感系统（如Radar、Lidar）和算法（如machine learning）等。这些传感系统和算法在执行预期功能时（未发生故障），其态势感知能力（situational awareness）在某些情况下能够直接影响安全性。举个例子，Uber自动驾驶汽车2018年3月在美国意外撞击致死一名行人。当时行人正穿过一段未被路灯直接照亮的道路，传感系统（Radar和Lidar，未发生故障）采集了行人的信息，在撞击发生的前6秒被车载软件依次解读为未知物体、车辆和自行车。该事故的最终原因（究竟是传感系统、软件还是其它因素）有待官方调查结果，但仍可见预期功能可能对安全性的极端影响。（小编注：关于该事故截至目前的官方初步调查报告，可参见往期文章Uber自动驾驶汽车事故的初步调查报告。）

基于上述原因，不难理解Safety Of The Intended Functionality （SOTIF）的概念为什么越发受到重视。

2. SOTIF的定义和大致思路

SOTIF在ISO/PAS 21448中的官方定义为：“Safety Of The Intended Functionality (SOTIF): absence of unreasonable risk due to hazards resulting from functional insufficiencies of the intended functionality or from reasonably foreseeable misuse by persons.”

由此可见，SOTIF（中文直译为预期功能安全）的关注点是：由功能不足、或者由可合理预见的人员误用所导致的危害和风险。例如，传感系统在暴雨、积雪等天气情况下，本身并未发生故障，但是否仍能执行预期的功能。而功能安全关注于与安全相关的失效（failure），信息安全关注于与安全相关的威胁（threat）。

SOTIF在很大程度上基于假设场景（scenarios）来进行分析。ISO/PAS 21448对场景（scenarios）的定义是：“description of the temporal development between several scenes in a sequence of scenes”，即一系列片段（scenes）中几个片段（scenes）之间的时序发展描述，如下图所示。

ISO/PAS 21448将场景（scenarios）划分为如下图所示的4个区间，分别为（1）已知-安全、（2）已知-不安全、（3）未知-不安全和（4）未知-安全。目的是尽可能缩小位于区间（2）和（3）中的场景（scenarios）比例，即将确保场景（scenarios）控制在安全的区间。

一些典型的自动驾驶的假设场景（scenarios）如下：

3. SOTIF的现有规范

ISO/PAS 21448《Road vehicles - Safety of the intended functionality》于2019年1月份正式发布，是截至目前唯一的SOTIF规范。该规范从设计、验证（verification）和确认（validation）等方面，提供了（尤其是在level 1和level 2中）实现预期功能安全所需的工作指南。

（小编注：21448目前是以Publicly Available Specification即公用规范的形式发布的，可以理解为“准“标准。PAS的定义如下图所示。）

SOTIF是继功能安全（Functional Safety）、信息安全（Cybersecurity）之后出现在汽车行业的新关注点，同时也与这两者密切关联。下图简要列出了SOTIF规范、功能安全标准和信息安全标准的大致涵盖范畴。

ISO/PAS 21448与正在筹备中的自动驾驶安全标准 IEEE P700X和UL 4600的关联如下：

4. SOTIF分析流程

ISO/PAS 21448中定义的SOTIF相关活动如下图所示。（小编注：该图中存在一处笔误：中部的方框“Validation of the SOTIF”应为“Verification of the SOTIF”，参见小编标注出的红线。相信在下一版本中会有所更正。）

理论上，SOTIF应该与ISO 26262中的流程衔接，比如作为早期HARA的输入、后期确认（Validation）阶段的输入等等。参见下图。（小编注：将SOTIF与功能安全衔接的潜台词之一，是SOTIF应该采用与功能安全一致的风险接受准则。）

在功能安全与信息安全联合分析的理想框架背景下，SOTIF理论上可以作为下图中左半部分HARA的输入。

评价SOTIF分析工作的准则如下图所示。

5. SOTIF应用现状

由于SOTIF的出现相对较新，能检索到的、有实用价值的资料不多，如何能将它有效地落地仍处于探索阶段。目前有自动驾驶产业链上各个企业的需求和探索、有相关的SOTIF专题研讨会，但几乎还没有成型的、深入的项目应用。（这当然也有可能是出于对知识产权的保护，所以未公开。）各种所谓的培训也是鱼龙混杂。值得一提的是，SOTIF在GM的安全报告[4] 中略有体现。感兴趣的朋友可以下载阅读获取更多信息。

小编个人认为SOTIF是有价值的，但在21448升级为正式的ISO标准之前，SOTIF距离广泛的实际应用恐怕还有很长一段路，功能安全、信息安全仍会是首要的考虑因素。

6.待解决的问题

以下为小编认为的SOTIF的一些待解决问题，包括但不局限于：

如何确保当前的用例（use case）、场景（scenarios）合理且完整？仿真是否切实可行？STPA是否切实可行？（小编注：关于STPA的介绍，可参见往期文章STPA：一款危害分析工具。）谁来提（OEM？）、如何提SOTIF要求？是否应该有类似于ASIL级别的“SOTIF级别”？如何评估、谁来评估SOTIF的分析结果？对于level 3及以上，除了ISO/PAS 21448，还能参考哪些指南来考虑SOTIF？关于这一点，在该规范的Scope里也有所提及：“This edition of the document can be considered for higher levels of automation, however additional measures might be necessary.“ （小编注：这里的“higher levels of automation“指level 3及以上）如何将SOTIF落地，如何与功能安全分析流程有效衔接。例如如何界定“非预期功能”，究竟该将其划分为故障（即ISO 26262的范畴）、还是划分为功能不足（functional insufficiencies，即SOTIF的范畴）。

7. 小结

本文简要介绍了SOTIF的背景、定义、大致思路、现有规范、分析流程、应用现状、待解决的问题等，可作为基础的理论介绍。

参考资料

[1] ISO/PAS 21448. Road vehicles - Safety of the intended functionality. 2019.

[2] Philip Koopman. Safety and Validation of Autonomous Vehicles. 2019. https://www.slideshare.net/PhilipKoopman1/safety-and-validation-of-autonomous-vehicles-june-2019?next_slideshow=1

[3] Technical Report- Taxonomy of Scenarios for Automated Driving. V1.2. 2017. https://s3-eu-west-1.amazonaws.com/media.ts.catapult/wp-content/uploads/2017/04/25114137/ATS34-Taxonomy-of-Scenarios-for-Automated-Driving.pdf

[4] General Motors. Self-driving Safety Report. 2018. https://www.gm.com/content/dam/company/docs/us/en/gmcom/gmsafetyreport.pdf

[5] Riccardo Mariani. Can we trust autonomous systems? 2017. http://www.icri-sc.org/fileadmin/user_upload/Group_VCI/Events/Kickoff_2017/Mariani_Intel_ICRI-CARS_kickoff_v1.pdf