漫谈预期功能安全的实践与挑战

随着智能驾驶系统安全问题日益凸显，解决汽车主动安全隐患对于企业和广大消费者而言也愈发紧迫。

背景

预期功能安全（Safety of the Intended Functionality, 即SOTIF）这一概念最早由欧洲专家于2018年提出，目的是解决由场景导致的安全风险。预期功能安全所覆盖的问题有两个特征，一是非故障原因，即整车、系统、软硬件层面不存在通信、电源等故障，各系统运转正常；二是由外部场景触发，即由于特殊场景发现了系统的设计缺陷，使车辆处于风险中。

欧美国家在这一领域的布局较早，在技术开发和标准研究方面均处于领先地位。国内企业虽然起步较晚，不少企业对预期功能安全概念的理解也尚不充分，不过近期相关标准和管理政策的出台引起各方对这一领域的广泛关注。

标准与法规的进展

目前，最有影响力的预期功能安全标准是由国际标准化组织编写的ISO 21448。该标准于2018年由原负责功能安全标准ISO 26262的工作组TC22/SC32/WG8提出并立项，并在2019年发布PAS版。这一版本标准较为清晰地提出了“未知危害场景-已知危害场景-已知安全场景”的风险解决逻辑和预期功能安全总体分析验证流程，但其内容仍不足以支撑企业开展预期功能安全相关工作。2021年11月，ISO发布/FDIS 21448:2021，在 DIS版本基础上进一步完善，例如：更新了接受准则定义、将误用分为了直接误用和间接误用、扩充了 SOTIF验证和确认方法等。作为预期功能安全领域的技术基础，ISO 21448标准将于2022年正式发布，被各国广泛应用并形成共识，成为事实上的强标，这也将带动预期功能安全领域的发展进入新的阶段。

此外，2021年8月，工信部《关于加强智能网联汽车生产企业及产品准入管理的意见》（后文简称《准入》）的发布进一步引发行业热议。在《准入》文件中，明确提出智能驾驶应满足功能安全、预期功能安全、网络安全等要求。从目前自动驾驶测试效果与能力水平看，阻碍自动驾驶的最大障碍是预期功能安全问题，相应地，文件中对于功能安全和预期功能安全也有了强制性的企业能力和产品过程保障要求，这使得功能安全和预期功能安全的设计、开发、测试成为了企业无法回避的技术问题。随着后续《准入》正式文件和实施细则的出台，功能安全和预期功能安全将成为强制性要求，我国也将逐渐同欧美等国家更加严格的标准和法规接轨。

源自：工信微报

与功能安全的联系

与我国汽车行业现有的多数标准有所差异，预期功能安全和功能安全都属于流程类保障要求。我国已有的大部分标准侧重于对测试结果的要求，而预期功能安全和功能安全更注重在开发、验证的过程中保障安全性。现有阶段安全领域主要包含三部分内容，功能安全、预期功能安全和信息安全，分别对应着汽车电子电气失效、场景风险和网络数据安全。由于不同领域的安全问题在车辆运行中存在不同的表现形式，因此需要形成不同的方法论和标准，以针对性解决不同类型安全隐患（如电子电气失效，可以通过分析系统各个组件近乎穷尽相关风险，解决外部风险则需要不断验证来识别危害场景并对系统不断迭代）。

多年来，功能安全专家们在实践中渐渐发现，尽管车辆的电子系统可以通过功能安全手段几乎避免大部分系统失效和信号故障，但在一些特殊场景下，配备自动驾驶系统的车辆还是无法从容应对。本应在预期设计范围内的场景在开发和验证中被意外忽略，这样的问题频繁在智能驾驶系统中出现，却又无法通过传统的手段有效解决，因此亟须新的方法论来识别、验证风险场景，即“预期功能安全”。在很大程度上，预期功能安全是功能安全理念在智能驾驶系统上的延伸，都是希望通过流程要求保障企业或产品的安全能力。流程类标准的本质在于将大量工程经验中归纳出的必要步骤，转化为执行性高、可量化的实操指导型标准，供新老工程师参考，从而最大程度上规避因人类能力或经验差异而最终体现在产品上的安全不一致性。从这一角度出发，将更容易理解功能安全和预期功能安全实施中每一个步骤的必要性，同时也引出了一个棘手的问题：预期功能安全与功能安全的风险来源完全不同，是否还可以参考功能安全中的系统性方法来解决预期功能安全中大量的非系统性问题？就现阶段而言，答案是肯定的。

现有技术流程

目前，预期功能安全研究开展的思路主要有两类，一是延续功能安全的思路，针对某一功能，基于工程经验，在较小的范围内通过识别特定系统的自身问题，有针对性地识别相应风险场景并解决；二是从场景分析出发，不再局限于某个特定功能或系统，从场景的元素入手，更广泛地找到通用性的场景问题。前者的优势在于通过系统性的分析方法，在有限的范围内更容易找到针对这一特定系统的危害场景，可以比较好地保证场景的有效性；后者的优势在于，虽未完全按照预期功能安全标准展开分析，但可以从更广阔的角度保证危害场景识别的全面性。现阶段，双方均未总结出大量的、结论性的解决方案，因此短期内还将呈现两种研究思路互补并存的状态。

预期功能安全的实施中，需要贯彻“迭代”的概念，迭代的内容包括场景、分析、验证、以及系统自身等等。参考ISO 21448标准草案，预期功能安全的分析和验证流程主要包括以下8个方面：

1.相关项定义：

关于相关项定义的部分可以很大程度上参考功能安全标准ISO 26262相关章节，基于功能规范和系统架构形成所需内容，在此不再赘述。

2.危害分析和风险评估：

类似地，危害分析和风险评估部分，同样可以参考功能安全中HAZOP关键词法分析，评价危害事件的暴露度（S）、可控度（E）、严重性（C），只是在S、E、C评分得出后不再综合评定ASIL等级，只考虑危害事件的可接受与不可接受两种情况；如果危害事件不可接受，那么其将作为这一阶段的结果，进而推出下一步所需的触发条件。

3.潜在功能不足与触发条件识别：

如果危害事件不可接受，那么我们将分析由于何种原因会导致该事件的发生，即识别触发条件。基于危害分析和风险评估中的风险可接受准则，定义危险。此时，可以较为方便地应用STPA分析方法，建立控制流程，确定系统间的交互方式和内容。根据控制行为识别相对应的各类UCA（Unsafe Control Action）。基于已有UCA，识别哪些类别的原因或条件会导致不安全控制行为的发生；从而构成UCA来源。继而基于中汽数据经验，详尽识别触发条件，结合开发人员描述和系统规范，评估系统对触发条件的响应，并给出相应的安全机制。例如，触发条件可以是车道线被雪覆盖等等。触发条件构成了场景众多元素中最关键的一个，即直接诱发场景风险的元素，因此这一步是预期功能安全最核心的环节。基于多年的场景研究经验，中汽数据等企业已在这一环节积累大量预期功能安全场景形成场景库，更易于帮助客户有效地、全面地识别系统场景风险。

4.对系统的优化与改进：

在危害场景识别后，需要确认在开发前期该风险是否已经可以被合理应对，如开发中未考虑相关场景的出现，那么需要对系统进行改进或优化，手段包括但不限于优化算力、增加感知冗余、限制系统使用ODD。在这里要说明的是，限制系统ODD是一柄双刃剑，虽可以保证智能驾驶系统运行的安全性，但很可能会破坏用户的使用体验，出现遇到问题就退出的情况。

5.测试验证策略的确定：

本部分主要结合前文的验证策略，将发现的问题进行测试验证，不同的危害场景需要通过何种验证手段实现，测试的时长、方式、计划等等，并评估其结果是否达到预期目标。

6.已知危害场景验证：

这里涉及的测试手段主要包含仿真和实车两大部分。仿真测试方面，可通过视频注入、视频暗箱的方式对于摄像头进行传感器的单独测试；毫米波雷达可通过回波模拟器的方式模拟障碍物目标进行仿真。不过，由于少有测试企业能对仿真和物理测试的有效性进行量化评估，部分厂商对于仿真验证的信赖度仍有疑虑。实车方面，可包括在道路上寻找特殊场景进行测试；或者对所需场景在场地中进行物理复现来进行测试。

7.未知危害场景验证：

这一部分主要依赖于更广阔的长期测试来完成，通过近乎无限的里程数验证，发掘极小概率发生的极端场景。

8.发布后的运营与维护。

发展与问题

预期功能安全无疑将成为未来备受关注的话题，但其实施中的诸多问题也需要行业各界共同探讨解决。

首先，无限的场景验证很难依赖于完全真实的实车验证，仿真验证的重要性将逐渐提升，而如何量化评价仿真测试有效性，尤其是感知部分，将成为行业的痛点之一。其次，预期功能安全分析与验证的验收边界尚不明确，迭代次数、场景数量达到何种程度才可以释放？现有的可接受准则多停留在理论层面的计算，尚未经过广泛实践验证可行性。最后，对于现有的大量非系统性预期功能安全场景问题，我们是否还能按照系统性的方法论来处理？这3个重点问题的解决，将极大推动预期功能安全的落地和实施，使智能驾驶的安全性实现真正跨越。

中汽数据有限公司基于多年来的驾驶场景大数据和仿真工程经验，在预期功能安全领域已有较为深厚积累。目前，中汽数据已与国内外多家企业展开预期功能安全相关合作与研究，包括流程管理、安全开发、工程咨询、验证确认等，助力客户率先在预期功能安全环节满足合规要求，实现技术落地。