欢迎加入自动驾驶圈
https://www.zhihu.com/club/1180807677260824576

本文经授权转载伟世通Visteon
本文经授权转载燃云汽车
本文未经授权转载牛喀网
本文未经授权转载搜狐汽车

本文结合行业标准与个人学习理解，从自动驾驶系统供应商的角度对SOTIF做出部分分析，但由于正式版本SOTIF尚未面世，本文内容仅可作为参考和讨论，后续将对各部分内容进行持续更新。

1. SOTIF ISO21448的定义

SOTIF ISO21448是汽车行业的一个新兴概念，由2015年启动ISO标准的制定，全称为Safety of the intended function，预计在2018年，ISO PAS21448以行业规范的形式发布，预计在2021年启用正式的ISO标准。

当汽车中存在越来越多的电子和软件时，我们发现并不是所有的安全问题都来自于系统错误和失效，很多时候，系统安全的问题来源于环境影响带来非预期的安全问题。

对于自动驾驶系统来说，系统接管车辆控制，即使系统并发生故障，也可能因为黑盒输出的不确定性导致功能的偏离，造成交通伤害。这类非故障情况下因系统功能不满足预期而导致的安全风险就是SOTIF要解决的问题。

2. SOTIF 与 Functional Safety

当前版本的SOTIF中列举了安全相关的ISO标准：

简而言之：

Funtional Safety:电子电器失效对人造成的危害

SOTIF: 自动驾驶系统非故障原因对人造成的危害

ISO26262-1中提到”ISO26262对E/E系统的标称性能没有要求，对这些系统的功能性性能标准也没有什么要求（例如：主被动安全系统，刹车系统，ACC等）“ ，SOTIF的存在弥补了这部分的遗憾。

3. SOTIF在实际项目中的应用

自动驾驶系统功能局限可分为几个部分：

1. 目标场景考虑不周到，系统无法对环境做出正确相应 - Perception

2. 功能逻辑仲裁机制、算法不合理，导致决策出现问题 - Decision

3. 执行机构的输出与理想输出发生偏差，难以完美控制 - Execution

“尽管可能在感知决策执行层面没有任何错误和失效的发生，其他复杂的交通状况和车辆的意外行为依然可能会成为自动驾驶系统的不稳定因素”

自动驾驶行业中高频词“AI”存在的意义在于其加强了感知和决策的能力，理想的状态下对其输入确定数值，我们期望相同的结果，但AI问题本质上是一种概率问题。考虑到车辆的运行场景往往是多变的，静态和动态因素同时存在于驾驶场景之中。这种连续或离散变化的状态对于Perception来说的输入变量是不可量化和计算的，这时实际项目开发过程中就很难以保证系统输出的稳定性和鲁棒性，直接导致系统的设计不能保证目标市场的实际需求。

那么如何解决这样的问题？

1.如何预防？

在设计的初期我们就要大量收集并记录目标市场的使用场景作为产品设计的输入，当训练数据全部在印度完成那么产品将很难在中国投放。在系统需求定义时应注重traceability的实施，与传统ECU定义不同点是应充分抽象目标市场的特征，用高度抽象并且明确的表达定义SYS1 Stakeholder requirement & Feature Level Requirement，届时需求中将大量出现Rain、Snow、Foggy等字眼。SYS2 System requirement阶段定义明确的功能逻辑、诊断策略和冗余策略、人机交互策略。- Why HMI here?

Home » drive.ai » the self-driving car is herewww.drive.ai

在这个阶段中HARA的工作需要考虑到SOTIF，对安全的功能需求进行FMEDA、FMEA、FTA验证。在一篇名为“How to reach complete safety requirement refinement for autonomous vehicle”的论文中，作者对SG、FSR、TSR在新环境下的适应性改变做了细致的说明，它建议Refinement Verification、Multi-level requirement hierarchy，正对应了上面我提到的思想。

在系统需求这里马克以下，在一篇“Testing of advanced driver assistance towards automated drivings: A survey and taxonomy on exsiting approached and open questions”的论文中作者建议系统需求应考虑comfort, reliability, robustness and safety要点。

执行SOTIF需要进行大量的测试验证工作，Ford的Safety Report中提到在产品开发的早期（个人理解为第一次Software Release）就开始做SIL、HIL和大批量的Vehicle test，通过虚拟测试和路试的方法积累尽可能多的Scenario（注意此处为Scenario非Scene）数据库以测试驱动开发的敏捷开发形式快速进行算法迭代，保证目标市场的投放稳定可靠。SIL、 HIL、 Vehicle test里程数和脱离次数可以参考欧洲各家主机厂的Safety Report，见仁见智。

在SOTIF的定义中驾驶的场景可以分为四个部分 - 此处的场景为Scenario并非Scene

Known Safe

Known Unsafe

Unknown Safe

Unknown Unsafe

“这部分内容非常重要，它不涉及具体的项目实施，但个人认为是一种非常先进的指导性思想。”

对于Known Safe，Unknown Safe，Know Unsafe的部分无需赘述，V-Cycle中的Verification工作可以很好的覆盖这三种场景，要解决的问题来源于Unknown Unsafe，它超越客观和想象力的认知。在这一点上SOTIF并没有过多解决思想上的说明。

”在这里我建议对于Unknown Unsafe最好的解决办法是精细化Known部分的框架从而增加已知部分的安全性，不断探索其中的设计缺陷，以预测客观未知部分的不足。贸然对Unknown Unsafe下定义极有可能捡了芝麻丢了西瓜。这部分的工作主机厂由于占有fleet的优势将take more responsibility，它看似无迹可寻，实则将大幅度影响最终产品交付质量。“

在此处对Scenario和Scenario based test做出解释:

Scenario:

"description of the temporal development between several scenes in a sequence of scenes" - SOTIF

关于Scenario的量化过程属于核心Know how，这里不做阐明。

这里给出我制作并建议的场景框架图：

Scenario based test：

这是在SOTIF所提供的框架下建立的一种新的测试方法，Level 3的自动驾驶功能通常为许多Level 2的功能组成，功能安全在实际项目开发过程中难以贯彻。这种新的测试方法通常被应用于Level 3以上的自动驾驶功能测试，Level 2或以下考虑到成本因素将只采用Requirement based test。由于主机厂拥有fleet和数据的优势，皮球往往被踢给了主机厂。

给出一张图来说明整体的思想：

2.如何解决？

SOTIF中提出了Fail operational、misuse的概念，通俗的解释就是错了还能用。其存在原因在于系统设计难以覆盖使用工况，其在自动驾驶系统中有着非常重要的意义。

举个例子，若单独使用摄像头方案对交通标志检测的过程中出现遗漏或者错判的情况，HD Map ECU将输出冗余信息用于仲裁完成决策，当operational的结果不理想或出现失效，则执行ISO 26262 3-8中故障检测和失效缓解措施-执行Fail Safe，功能降级完成安全状态的转换。当然，在这里我个人的想法是也许我们可以在HMI上做一些事情，让SOTIF回归ISO26262的范畴。

4. SOTIF的发展和未来

由于产品投放市场的异质性，个人感觉SOTIF不会成为与ISO26262相同的State of Art，但它会成为一种思想和经验的积累，指导自动驾驶从业者完善自己的产品。