1. 背景
随着Advanced Driver Assistance Systems（ADAS）系统越发复杂，引入了各种复杂的传感系统（如Radar、Lidar）和算法（如machine learning）等。这些传感系统和算法在执行预期功能时（未发生故障），其态势感知能力（situational awareness）在某些情况下能够直接影响安全性。举个例子，Uber自动驾驶汽车2018年3月在美国意外撞击致死一名行人。当时行人正穿过一段未被路灯直接照亮的道路，传感系统（Radar和Lidar，未发生故障）采集了行人的信息，在撞击发生的前6秒被车载软件依次解读为未知物体、车辆和自行车。该事故的最终原因（究竟是传感系统、软件还是其它因素）有待官方调查结果，但仍可见预期功能可能对安全性的极端影响。
基于上述原因，不难理解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）之间的时序发展描述，如下图所示。
（图片来源：[1]）
ISO/PAS 21448将场景（scenarios）划分为如下图所示的4个区间，分别为（1）已知-安全、（2）已知-不安全、（3）未知-不安全和（4）未知-安全。目的是尽可能缩小位于区间（2）和（3）中的场景（scenarios）比例，即将确保场景（scenarios）控制在安全的区间。
（图片来源：[1]）
一些典型的自动驾驶的假设场景（scenarios）如下：
（图片来源：[3]）
（图片来源：[3]）
（图片来源：[3]）
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的定义如下图所示。）
（图片来源：http://www.iso.org）
SOTIF是继功能安全（Functional Safety）、信息安全（Cybersecurity）之后出现在汽车行业的新关注点，同时也与这两者密切关联。下图简要列出了SOTIF规范、功能安全标准和信息安全标准的大致涵盖范畴。
（图片来源：[1]）
ISO/PAS 21448与正在筹备中的自动驾驶安全标准 IEEE P700X和UL 4600的关联如下：
（图片来源：[2]）
4. SOTIF分析流程
ISO/PAS 21448中定义的SOTIF相关活动如下图所示。（小编注：该图中存在一处笔误：中部的方框“Validation of the SOTIF”应为“Verification of the SOTIF”，参见小编标注出的红线。相信在下一版本中会有所更正。）
（图片来源：[1]）
理论上，SOTIF应该与ISO 26262中的流程衔接，比如作为早期HARA的输入、后期确认（Validation）阶段的输入等等。参见下图。（小编注：将SOTIF与功能安全衔接的潜台词之一，是SOTIF应该采用与功能安全一致的风险接受准则。）
（图片来源：[1]）
在功能安全与信息安全联合分析的理想框架背景下，SOTIF理论上可以作为下图中左半部分HARA的输入。
（图片来源：[5]）
评价SOTIF分析工作的准则如下图所示。
（图片来源：[1]）
5. SOTIF应用现状
由于SOTIF的出现相对较新，能检索到的、有实用价值的资料不多，如何能将它有效地落地仍处于探索阶段。目前有自动驾驶产业链上各个企业的需求和探索、有相关的SOTIF专题研讨会，但几乎还没有成型的、深入的项目应用。（这当然也有可能是出于对知识产权的保护，所以未公开。）各种所谓的培训也是鱼龙混杂。值得一提的是，SOTIF在GM的安全报告[4] 中略有体现。感兴趣的朋友可以下载阅读获取更多信息。
小编个人认为SOTIF是有价值的，但在21448升级为正式的ISO标准之前，SOTIF距离广泛的实际应用恐怕还有很长一段路，功能安全、信息安全仍会是首要的考虑因素。
6.待解决的问题
以下为小编认为的SOTIF的一些待解决问题，包括但不局限于：
如何确保当前的用例（use case）、场景（scenarios）合理且完整？仿真是否切实可行？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的背景、定义、大致思路、现有规范、分析流程、应用现状、待解决的问题等，可作为基础的理论介绍。
本文摘自知乎 RAMS工程师
