浅谈预期功能安全分析流程与过程保障

1、预期功能安全来源与现状

传统电子电气领域问题，可通过功能安全解决。但随着自动驾驶技术的发展，加入了包括算法、图像识别等内容，仅保证自身无故障已经不足以满足自动驾驶对于安全的需求。

由于自动驾驶系统本身的高度复杂性，导致了我们设计的功能本身就有局限性或缺陷，从而进一步导致安全事故的发生，预期功能安全试图解决的就是这些问题。预期功能安全就是在这样的背景下提出了。

本文将重点讲解如何通过SOTIF标准更好的解决智能驾驶开发中功能不足的问题和设计局限性导致的风险，如何验证和确认当前的危害是合理可接受的，如何正确采用标准要求的技术方法（FMEA/CTA/STPA）。同时本文将依托NOA功能实例，重点讲解如何借助一定的工具链开展SOTIF标准的安全分析过程。

在以NOA为例进行预期功能安全分析的过程中，需要考虑其主要原因是在设计和开发期间对系统功能的定义不能完全涵盖目标市场的使用需求。其中，对目标场景的考虑的不全面，导致系统不能准确识别环境要素；功能仲裁逻辑不合理，将导致系统决策错误；执行器响应不充分，则会导致运动控制偏离预期。

2、预期功能安全分析理论基础

自动驾驶会受到很多因素的影响，比如路况、周围事物和环境天气。如何克服环境干扰，可靠地进行环境识别、驾驶决策和运动控制是确保安全驾驶的关键。对于NOA来讲，预期功能安全要求在危害分析和风险评估的过程中对影响安全的功能需求进行FEMA，FTA，HAZOP，SPTA，CTA等工具进行分析和验证。其中FEMA，FTA，HAZOP等是ISO26262功能安全分析常用的工具。此外，Hazard的分析涉及传统意义上的危害分析，包括功能、HAZOP、危害行为描述、失效影响（主要是指整车层级危害）这几个方面。

对于自动驾驶领域，自动驾驶汽车功能的实现依赖于与外部环境的交互，传统基于事件链模型的危害识别方法无法适用于这类开放系统。而在预期功能安全的分析方法则更倡导基于控制理论的系统理论过程分析（SPTA）来进行自动驾驶汽车危害识别。

如下图表示了NOA中典型的STPA 搭建驾驶员、车辆、环境交互模型。

系统理论过程分析（SPTA）方法主要流程是：事故→系统控制结构→不安全控制行为→原因分析→安全约束。

进行STPA分析时，其分析过程包括驾驶员职责划分（R-x），对应的控制行为、对应的反馈等几个部分。其中驾驶职责主要是指决策何时刹车，何时启动：是手动还是自动？其中涉及驻车、启动指令，汽车物理结构反馈（速度、刹车踏板状态、油门踏板状态）、外部环境反馈（位移）、视觉位移、AutoHold开关状态。监督自动刹车/启动过程，出现故障时手动刹车，给自动驾驶系统发送触发信号等几个部分。

STPA的方法仍旧是不够完美的，在将其直接应用于高等级自动驾驶上时，还需要解决自动驾驶汽车事故数据记录问题，体现不同功能下的车辆状态控制结构差异；以系统的方法来分析具体失效原因。

3、NOA下的SOTIF分析实例

我们知道对于以自动驾驶为基础的安全能力分析主要包括从整体场景抽象，从感知端、规划控制到决策执行端的整个分析过程。对于很多设计功能来讲，都需要基于已有的分析和经验积累，形成预期功能安全场景库，便于识别所有触发条件。

首先在系统输入层面，需要定义设计运行范围ODD（定义中包含特殊天气场景、特殊交通流场景），场景抽象完成后再进行策略设计，策略设计主要是为了满足动态驾驶任务的设计过程，涉及利用NOP对应的系统硬件架构对周边环境进行的感知、提取交通流下的关键场景、利用关键场景进行车身控制。

设计中包含整车层面、系统层面、零部件层面几个大方面。从下至上，则包括合理可预见误用作为触发条件，功能不足及性能受限的说明，风险分析。

进一步细化危害行为这一模块分析又涉及具体的危害事件描述、危害场景重建、相关人员反映、可控度、伤害（人员）、严重度、是否可接受等。基于如上信息又会拆解到对于该危害场景的具体触发条件，包括场景特征（如道路特征、交通设施特征、气候环境特征、其他特征）、主车驾驶场景（行动、事件、目标）、其他交通参与者行为、发生概率。

如下列举几个典型的预期功能安全场景识别与应对，作为案例分析。

实例1：误作用识别

实例2：误触发条件的识别

实例3：因果关系识别

4、《自动驾驶准入指南》对于预期功能安全的要求

这里为什么要提自动驾驶准入呢？因为对于车企来讲，肯定希望自身所开发设计的功能能够在量产上市前得到工信部、公安部、交通部等部门的认可，拿到正常的牌照上市，这也算是可以正身（也就我们所说的量产上市准入）。这样的需求就需要在整个设计、研发及验证期间做到设计强有力的预期功能安全管理流程，将安全文化渗透到企业的方方面面，在各个环节中进行Documentation Work，对产品的生命周期进行监控。而具体涉及到其开发的车型产品方面，就要求参考国际、国内标准的开发流程，在产品开发环节做必要的SOTIF分析。通过仿真、实车测试手段对产品的SOTIF能力进行验证，在产品使用中仍继续对SOTIF能力进行迭代。

预期功能安全的开发流程要求可以确保企业在设计定义、危害识别、功能不足识别、功能改进、验证及确认、安全发布、运行维护等方面得到最好的规范，保障车辆不存在因为前期功能设计不足可能导致的较大风险。

首先预期功能安全规范和设计的要求通过相关项定义识别和评估预期功能可能造成的危害，这类危害主要涉及失效后的整车级危害以及结合场景形成的危害事件。

如上这类失效危害需要评估危害造成的风险，制定合理的风险可接受准则。通常对于已知危害场景中的问题，即S>0且C>0的危害事件，在进行了功能修改后，若仍不能使S=0或C=0，则需适当调整风险可接受准则（作为验证目标的依据），作为该危害场景下的验收标准。接收标准涉及几个重要的参量：

单位里程（或单位时间）内危害行为事件的平均发生次数，该参量实际关系发生频次，这里以α表示；危害行为事件发生的平均里程或时间间隔（即无事故里程或时长）β；发生失效的置信度水平，该参量实际关系对于失效场景的判断是否准确τ。最终我们可以定义对于当无危害行为事件里程数达到一定值β时，具有一定置信度水平η的情况下，可认为该系统在同等驾驶从场景危害事故率能达到要求的触发频次数α。

那么这里我们的风险接受准则条件可以以如下公式可以表示三者之间的关系：

其次，预期功能安全要求识别和评估潜在功能不足和触发条件（含可合理预见的人员误用），并应用功能改进等措施减少预期功能安全相关的风险。

这类风险减缓措施实际是通过ODD分析、事故场景数据分析、安全分析方法来识别功能不足和导致危害事件的触发条件，具体到相应的危害场景。

此外，预期功能安全还要求定义验证及确认策略，并进行预期功能安全的验证和确认，评估已知危害场景和未知危害场景下是否符合产品预期功能安全发布要求，并对发布后产品的预期功能安全风险进行合理管控。

最后，需要重点定义驾驶自动化系统预期功能安全相关零部件的接口要求，确保零部件符合对应的预期功能安全设计开发、验证、确认等规定。

针对这一开发过程企业需要从哪些方面努力还能真正在预期功能安全上做到很好的开发能力呢？

鉴于目前相当一部分车企在预期功能安全上的研发精力投入还远远不够，因此，企业应该首先建立并维持良好的Safty Culture，鼓励企业内部各部门就预期功能安全问题展开沟通和研究（包括感知、决策、执行系统的元件升级设计规范和评估报告等），并根据企业自身特点，建立合理的安全异常解决机制。鼓励OEM与供应商在预期功能安全开发中一同制定开发接口协议DIA，明确开发要求，并在开发过程中对DIA进行多次分阶段讨论、打和。

同时，安全管理流程上帝的有效完善也是必不可少的。这其中就包括提供质量管理体系的证明材料，对安全管理人员提出合理的的Competence考核办法，以确保胜任相关工作，对Safety Plan、Safety Case和Safety Confirmation等文件中所涉及的内容详细记录在案。

此外，在生产开发流程上，需要建立产品的后开发流程，包括关于产品的生产、运营、维护、使用等安全管理计划，提供生产现场的审查报告等。

写在最后

预期功能安全分析中的关键技术主要是指HARA、FTA、FMEA、HAZOP、STPA等几个方面，这几个方面也是与功能安全分析相重叠的部分。本文以NOA为例，在我们对设计过程中，需要参照以下步骤进行详细分析分解。

总体来说，对于SOTIF的风险规避或减缓手段主要包括提升系统能力，比如算力；增加多样性冗余技术，例如增强感知融合能力；提升功能限制能力，例如明确设计运行范围ODD；提升对驾驶员接管能力的探测，减少误用情况，最终满足SOTIF的安全要求。