如何通过SOTIF标准解决智能驾驶开发中功能不足的问题

1、预期的功能安全来源和当前情况

传统电子电气领域的问题可以通过功能安全来解决。但是随着自动驾驶技术的发展，仅仅靠增加算法、图像识别等已经不足以满足自动驾驶的安全要求。

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

本文将重点讨论如何通过SOTIF标准更好地解决智能驾驶开发中因设计限制导致的功能不足和风险问题，如何验证和确认当前的危害是合理和可接受的，以及如何正确采用标准(FMEA/CTA/STPA)要求的技术方法。同时，本文将重点介绍如何借助基于NOA函数实例的某个工具链来进行SOTIF标准的安全性分析过程。

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

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

自动驾驶会受到很多因素的影响，比如路况，周围的东西，环境天气。如何克服环境干扰，做出可靠的环境识别、驾驶决策和运动控制是保证安全驾驶的关键。对于NOA来说，预期的功能安全要求在危险分析和风险评估过程中，通过FEMA、FTA、HAZOP、SPTA和CTA等工具对影响安全的功能要求进行分析和验证。其中，FEMA、FTA和HAZOP是ISO26262功能安全分析的常用工具。另外，危害分析涉及传统的危害分析，包括功能、HAZOP、危害行为描述、故障影响(主要指整车级危害)。

对于自动驾驶领域，自动驾驶车辆功能的实现依赖于与外部环境的交互，传统的基于事件链模型的危险识别方法无法适用于这种开放系统。在预期功能安全的分析方法中，提倡基于控制理论的系统理论过程分析(SPTA)来识别自动驾驶汽车的危险。

下图显示了NOA典型的STPA建筑驾驶员、车辆和环境相互作用模型。

系统论过程分析(SPTA)方法的主要过程是：事故系统控制结构不安全控制行为原因分析安全约束。

在分析STPA时，分析过程包括驾驶员的责任划分(R-x)、相应的控制行为和相应的反馈。其中，驾驶责任主要是指决定什么时候刹车，什么时候起步：手动还是自动？涉及驻车和起步指令、车辆物理结构反馈(速度、制动踏板状态、油门踏板状态)、外界环境反馈(位移)、视觉位移和AutoHold开关状态。监督自动制动/启动过程，出现故障时手动制动，并向自动驾驶系统发送触发信号。

STPA的方法仍然不完善。直接应用于高级自动驾驶时，需要解决自动驾驶车辆的事故数据记录问题，体现不同功能下车辆状态控制的结构差异。系统地分析具体的故障原因。

NOA下的SOTIF分析示例3、NOA

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

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

设计包括整车级、系统级和零部件级。自下而上包括作为触发条件的合理可预见误用、功能不足和性能受限的说明、风险分析。

危险行为分析模块的进一步细化涉及危险事件的具体描述、危险场景的重构、相关人员的反映、可控性、伤害(人员)、严重程度、可接受性等。基于上述信息，它将被分解为危害场景的具体触发条件，包括场景特征(如道路特征、交通设施特征、气候环境特征等特征)、主车辆的驾驶场景(动作、事件、目标)、其他交通参与者的行为、发生概率等。

作为一个案例研究，下面列出了几种典型的预期功能安全场景。

示例1:误操作识别

示例2:错误触发条件的识别

示例3:因果关系识别

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

为什么要在这里提自动驾驶接入？因为对于车企来说，肯定是希望自己开发设计的功能能够在量产上市之前得到工信部、公安部、交通部等部门的认可，能够拿到一个正常的牌照上市，算是一个妥妥的车身(也就是我们所说的量产上市准入)。这样的需求需要在整个设计、R&D、验证期间设计一个预期性很强的功能性安全管理流程，将安全文化渗透到企业的各个方面，在各个环节开展文档化工作，对产品生命周期进行监控。当涉及到其开发的汽车产品时，要求参考国际和国内标准的开发流程，并在产品开发过程中做必要的SOTIF分析。产品的SOTIF能力通过仿真和实车测试来验证，并在产品的使用中不断迭代。

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

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

以上诸如此类的故障隐患，需要对隐患造成的风险进行评估，制定合理的风险接受标准。通常，对于已知危害场景中的问题，即S0和C0的危害事件，如果功能修改后无法实现S=0或C=0，则需要适当调整风险接受准则(作为验证目标的依据)作为该危害场景中的接受准则。验收标准包括几个重要参数：

单位里程(或单位时间)内危险行为事件的平均发生频率，与该参数实际关系的发生频率，此处表示为；危险行为事件的平均里程或时间间隔(即无事故的里程或持续时间)为；故障的置信水平，以及该参数的实际关系对于判断故障场景是否准确。最后，我们可以定义当无害行为事件的里程达到一定值且具有一定的置信水平时，系统从现场出发达到所需事故率的触发频率数。

因此，我们的风险接受标准可以用以下公式表示：

其次，预期的功能安全要求识别和评估潜在的功能

这种风险缓解措施实际上通过ODD分析、事故场景数据分析和安全分析方法，针对相应的危险场景，识别导致危险事件的功能缺陷和触发条件。

此外，预期功能安全还要求定义验证和确认策略，验证和确认预期功能安全，评估在已知和未知危害情景下是否满足产品的预期功能安全发布要求，合理控制发布产品的预期功能安全风险。

最后，需要定义与驾驶自动化系统预期功能安全相关的组件的接口要求，以确保组件满足相应预期功能安全设计、开发、验证和确认的要求。

针对这种开发过程，在预期的功能安全上，企业需要从哪些方面努力才能达到良好的开发能力？

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

同时，安全管理流程的有效改进也至关重要。包括提供质量管理体系的证明材料，对安全管理人员提出合理的能力评估方法，确保其能够胜任相关工作，详细记录安全计划、安全案例、安全确认等文件中涉及的内容。

此外，在生产和开发过程中，需要建立产品的后开发过程，包括对产品的生产、操作、维护和使用的安全管理计划，并提供生产现场的审查报告。

写在最后

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

一般来说，SOTIF的风险规避或缓解措施主要包括提高系统能力，如计算能力；增加多样性冗余技术，如增强感知融合能力；提高函数限制的能力，比如定义ODD的设计和运算范围；提高对驾驶员接管能力的检测，减少误用，最终满足SOTIF的安全要求。

审计刘清