内容提要：本文的主要贡献是通用安全生命周期，整合了功能安全和预期功能的安全生命周期。显示了WP之间的需求分布。引入了用于存储有关预期功能的非项目特定数据的单独数据库的概念。两个生命周期的集成使SOTIF更清晰，更易于实施。

摘要

现代汽车系统必须符合严格的安全要求。本文侧重于安全的两个方面：符合ISO 26262 (FS)的功能安全和符合ISO PAS 21448的预期功能安全(SOTIF)。FS包含整个生命周期，确保不存在由于系统内部失效而导致的不合理风险。SOTIF专注于非确定性部分和算法（例如神经网络），因为它们的性能的完整规范现在还遥不可及。同时，FS及其生命周期为社会所熟知，并且具有更好的实施历史。本文介绍了一种基于FS生命周期来集成FS和SOTIF需求的方法。

1.简介

提高道路车辆的自主性是当今汽车行业的最重要趋势之一。开发人员和车厂面临的挑战之一是如何在任何情况下保证自动驾驶汽车(AV)内部和周围人员的安全。多年来，安全保障方法一直在不断发展，没有任何终结的迹象。本文介绍了汽车安全相关的术语，以及工程师为确保安全所采取的主要策略。

根据欧亚经济联盟TR TS 018/2011技术法规“轮式车辆安全”，“车辆安全”被定义为“将危害人员生命、健康、财产的风险消除或最小化”。立法者承认不可能完全消除与车辆相关的风险。该法律的目的是激励车辆设计者和制造商以及其他车辆生命周期参与者，在整个生命周期中采取措施应对这些风险。

功能安全规范（例如ISO 26262）遵循此范例。功能安全(FS)解决由系统错误（即其组件故障）引起的故障。现代自动驾驶(AD)系统和高级驾驶员辅助系统(ADAS)高度依赖于非确定性、通常基于AI算法（例如目标识别、使用机器学习技术的路径规划）提供的外部数据。在这些情况下，即使是无故障的系统也可能由于系统性能的限制而表现出危险行为。ISO PAS 21448中制定的预期功能安全(SOTIF)的新范例解决了这个问题。

FS和SOTIF都规定了用于识别和控制风险的生命周期过程。FS生命周期因其较长的历史而广为人知并得到更广泛的实施，而随着车辆自主性的提高，SOTIF措施变得越来越必要。这两个生命周期可以结合起来，以实现需求的全程可追溯性并促进安全档案的创建。

2.FS和SOTIF的范围

众所周知，仅在不同的ISO标准中，就可以找到40多种安全定义。令人惊讶的是，ISO 26262和ISO PAS 21448都同意将安全定义为不存在不合理的风险。他定义了每个标准的范围：

·功能安全：不存在因E/E系统故障行为引起的危害而导致的不合理风险（ISO 26262-1，Def.1.51）。

※故障行为被定义为一个相关项相对于其设计意图的失效或非预期行为（这又是未定义的）。

·预期功能的安全性：不存在由于预期行为的性能限制或用户合理可预见的误用引起的危害而导致的不合理风险（ISO PAS 21448，Def.3.5）。

※性能限制：功能本身的不足（例如：对场景的不正确认识或由不可行的模型假设引起）–ISO PAS 21448，Def.3.4。

两个标准中定义的范围都不够明确，因为没有明确区分“故障”和“性能限制”。两者都被定义为与期望行为的偏差。可以说FS和SOTIF的范围存在重叠。与其细化定义以得出更清晰的区别，更有用的方法是定义安全方面，哪些方面最好用FS方法处理，哪些方面SOTIF方法更有益。

图1.安全方法：用例

业界采用安全方法论来控制（即系统地识别、减少、减轻和评估残留）风险。只有将与不同方法论(这里的不同方法论追求相同的目标)相关的方法放在一个生命周期中，才能实现对各种方法论的有效使用。

图1没有完整性声明，除此之外，还存在交叉依赖关系，例如，如果误用在故障情况下变得危险，则功能安全处理非故意误用问题；网络安全也处理非故意的误用情况，例如在人机界面（HMI）领域。本文将讨论FS和SOTIF生命周期；网络安全没有涉及。然而，此处定义的方法能够适应网络安全和可能的其他安全方法（即机械部件安全、化学安全等）。

3.通用安全生命周期（FS+SOTIF）

3.1.ISO 26262

ISO 26262中著名的“3-V图”展示了功能安全的生命周期。

图2.符合ISO 26262的安全生命周期

数字1到10标记了与每个生命周期阶段相关的标准部分。生命周期包括五个阶段：概念阶段（标准第3部分）、系统（第4部分）、硬件（第5部分）和软件（第6部分）以及生产和运营（第7部分）。目前，SOTIF仅限于概念阶段和系统级活动。确保软件级别预期功能安全的技术细节是所谓的“机器学习安全(ML)”的一部分。目前，这些方面未在ISO PAS 21448中解决。

3.2.ISO PAS 21448

SOTIF生命周期包括三个主要步骤：

1.“通过分析评估”：识别和评估触发事件（即成为可能导致危害事件的连续系统反应的触发因素的某个驾驶场景的特定条件，def.3.15）。

2.“评估已知危害场景”：从已知危害场景集合识别相关危害场景，进行明确的危害测试。

3.“评估未知危害场景”：“统计测试”，即通过将系统暴露于真实世界或模拟的统计分布条件下进行搜索验证。

ISO PAS 21448由12章组成，沿着接近ISO 26262生命周期的V模型运行。表1提供了集成FS和SOTIF要求的生命周期视图（通用安全生命周期）。

4.通用安全生命周期（建议）

在表1中，斜体部分是存在于FS生命周期中，并从SOTIF生命周期获得额外需求的工作产品(WP)。粗体部分的触发事件分析(TEA)，是唯一特定于SOTIF的WP。

在通用安全生命周期的14个WP中，一个TEA是由于SOTIF而新引入的，另外3个没有任何附加要求。剩余的10个WP包含FS和SOTIF要求。

表1.通用安全生命周期：FS+SOTIF

本文的下一章将介绍通用安全生命周期的具体工作产品，并在工作产品级别上介绍FS和SOTIF的集成。

5.生命周期的整合

现在我们已经定义了应该更改的工作产品或需要添加额外信息以整合ISO PAS 21448要求的工作产品。下一个问题是：哪些信息需要添加到每个WP和安全性中整个生命周期？SOTIF生命周期的要求是什么？

参考文献（关注“牛喀网”公众号后台咨询）介绍了关于ML的通用安全档案(General Safety Case,SC)。尽管SOTIF不等于“汽车ML应用程序”，但也可以使用该安全档案模型来涵盖SOTIF相关的安全档案。

ML安全档案的目标：证明与目标检测和分类功能中的功能不足相关的剩余风险是可以接受的。此处的论点应针对系统运行配置文件的假设、ML函数的输入及其算法的性能限制提供。

这些假设包含的数据不是特定于项目的，因此不是项目安全档案的一部分。它们可以在项目之间全部或部分共享。每个项目都可以使用整个可用数据集或一个子集。这些数据可以通过作为标准安全生命周期一部分的安全分析以及通过安全生命周期的SOTIF特定步骤找到。表1中标识的唯一特定于SOTIF的WP是触发事件分析(TEA)。然而，另一种SOTIF需求的分配，可能会导致其他WP表征生命周期的SOTIF特定部分。

图3.通用安全生命周期的结构

章节4中定义的通用安全生命周期如图3所示。它由符合ISO 26262的功能安全生命周期和一些接受ISO PAS 21448要求的WP以及正常安全要求组成。通过SOTIF生命周期扩展了安全生命周期，目前只包含触发事件分析的过程。通用安全生命周期的FS和SOTIF部分均基于预期功能的数据。

有关预期功能的数据，包括当前已知的项目中要实现的功能的信息。数据与项目无关；因此，它可以集中存储在组织或组织部门内的数据库中。

有关预期功能的必要数据包括：

·触发事件

·已知的相关用例，包括安全的和危险的，参考相关的触发事件

·已知相关用例发生的统计

·在危险情况下预期的人类反应。这对于具有1到3级SAE自动化水平的系统是特别需要的，因为这些系统的安全档案通常包括人类驾驶员作为安全措施。

数据库可能包含更多数据，具体取决于组织内实施的数据模型。

5.1.危害分析与风险评估

HARA包括危害识别和风险评估。

危害识别是一个归纳过程，旨在识别可能的危害以及与之相关的风险。危害识别始终考虑可能被视为系统外部的情况（用例、驾驶员和道路条件等）以及实际系统行为与某些预期行为的偏差。通用安全生命周期遵循FS生命周期，将功能失效（故障）视为危害识别的偏差。

危害评估在FS和SOTIF框架内以不同方式进行。这是由于两个标准中对“合理”或目标风险水平的不同理解造成的。

ISO 26262具有四个汽车安全完整性等级(ASIL)以及“QM”安全等级，适用于剩余风险被认为可以通过质量管理方法最小化而无需实施任何特定安全措施的情况。ASIL级别具有双重作用：它们衡量在给定情况下与特定故障相关的风险（ASIL A表示最低风险，ASIL D表示最高风险），同时ASIL分配定义了标准对系统的要求，即为将现有风险降至可容忍水平而需投入的工作量。因此，标准本身给出了系统中可能发现的风险级别以及可容忍级别，即使此信息是隐含的（不像IEC 61508，其中可以进行定量风险评估）。

图4.可接受的风险和所需的工作量：ISO 26262和SOTIF

根据ISO 26262，只有最危险的用例与相关安全目标的最高ASIL定义相关。然后，定义的安全目标被用作所有技术活动的代理。同时，SOTIF标准既没有明确规定风险的可接受水平，也没有明确规定达到风险所需的工作量。所以应单独考虑每个用例，尽管所需的技术措施可以在用例之间共享（例如，使用类似于ISO 26262的安全目标作为代理），但每个用例的安全性最终应单独证明，除非用例被认为属于一个等价类（见下文章节5.3）。

5.1.1.危害识别用例

用例由功能范围、期望行为、功能系统边界和场景组成。情境是场景的静态部分。根据“ISO/PRF PAS 21448 2018道路车辆--预期功能的安全性”的用例的类图如图5所示。

图5.根据“ISO/PRF PAS 21448 2018道路车辆--预期功能的安全性”的用例定义

完整定义的用例示例如下：

1.功能范围：自动紧急制动（AEB）

2.期望的行为：如果认为很可能与障碍物发生碰撞，系统将激活制动

3.系统边界：摄像头/雷达系统、AEB ECU、制动ECU、制动系统

4.场景

4.1.行为和事件：

i）自车（即分析中考虑的配备AEB功能的车辆）正在向前移动

ii）在危险距离（2秒）内，自车的路径上不存在障碍物

4.2.目标和数值

i）目标：继续沿着道路行驶，不改变车道，不改变方向

ii）数值：优选速度、横向距离、纵向距离

4.3.情景

4.3.1.动态要素：道路上的其他车辆（例如，自我车辆前面的一辆公共汽车，距离3秒，自车后面的另一辆汽车，距离5秒）

4.3.2.场景

i）市区内

ii）右侧通行

iii）双车道道路：右侧车道和左侧车道

iv）右侧车道右侧的自行车道

v）自行车道右侧的行人通道

vi）道路是对称的（即它有两条车道，自行车车道和相反方向的行人通道）

4.3.3.自我描述：自车是一辆乘用车。

通过迭代可变参数获得新的用例。可变参数包括场景的行为和事件、数值和参数。

为了防止考虑的用例数量激增，需要在迭代过程中发挥创造力。只有与所选功能相关的参数才会被迭代。上面的列表考虑了AEB功能，它会影响车辆的纵向动力学。因此，横向条件（例如在其他车道行驶的汽车）与AEB相关的危险无关。它们不应该被迭代。

5.1.2.危害评价

危害是根据它们的概率来评估的。SOTIF考虑系统限制的非概率模型，即只要出现危害用例，系统就会出现故障。因此，危害的概率完全由危害用例的概率特征来定义。

用例的发生概率表示为每小时或每公里。HARA应定义该概率，用于定义后面所需的验证里程。显然，不能按照用例定义要求的详细程度来定义概率（参见章节5.1.1中的列表）。用例可分为多个集合，其中可计算整个集合的暴露概率。该策略要求基于整个用例集验证。

概率建模可以产生相对精确的数据，用于确定危害用例的概率。图6显示了潜在风险生成过程的示例。从交通和事故统计数据中可以得知右侧吸收状态（“安全驾驶”和“事故”）的概率。驾驶情况概率评估的质量取决于过渡过程建模的精度（例如，马尔可夫链建模的过渡率）。

图6.作为马尔可夫链的风险生成过程

拟合质量参数（置信区间、可能性等）可用于了解概率评估的好坏程度。使用来自先前验证的数据可以增加可能性。模型直接产生拟合质量估计，而对于其他评估方法，这些估计应基于假设得出。

已知用例（即被确定为对给定故障有害的用例）是“预期功能数据”的一部分（见图3）。它们大多不是特定于项目的，属于集中式数据存储。

5.2.触发事件分析

触发事件分析(TEA)是通用安全生命周期中唯一特定于SOTIF的WP。重要的是要了解触发事件不是用例，它是多个用例的特征。

TEA包括触发事件(TE)的识别和对其可接受性的评估（类似于HARA）。

建议的流程包括对SOTIF关键特性(SOTIF-CC)的分析，类似于FMEA流程中定义的关键特性，与可能受功能不足相关危害影响的功能相关。

5.2.1.相关TE的识别

SOTIF-CC融合了TEA过程与FMEA过程，并允许通过任何通用FMEA工具实施TEA。与相机相关的SOTIF-CC示例包括锐度、亮度和分类质量。使用类似HAZOP的程序，根据SOTIF-CC识别失效。这些失效可能与项目中先前定义的故障直接相关（通常故障是在相关项定义步骤中定义的）。

应根据“ISO/PRF PAS 21448 2018道路车辆--预期功能的安全性”中描述的组，准备触发事件列表：环境和位置、道路基础设施、城市基础设施、高速公路基础设施、驾驶员行为（包括可合理预见的驾驶员误用）、其他驾驶员/道路使用者的预期行为等。该列表可以预先定义并上传到FMEA工具中。然后，预定义的TE与失效相关联，而失效又与故障相关联。呈现出一个将TE与故障相关联的失效网络。

5.2.2.TE可接受性评估

根据“ISO/PRF PAS 21448 2018道路车辆--预期功能的安全性”，如果与TE相关的所有用例具有低暴露概率、高可控性或与其相关的风险具有低严重性，则TE是可以接受的。使用ISO26262-3中的定义，为了获得可接受的资格，TE应仅链接到发生的用例远远少于所有驾驶时间的1%（例如，飞机降落在高速公路上），或者用例很容易可控（即超过99%的驾驶员可以毫无风险地解决危险情况），或没有任何人身伤害风险的用例。

以系统的方式准备TEA和HARA可以通过数据库工具轻松识别可接受和不可接受的TE。

相关触发事件是“关于预期功能的数据”的一部分（参见图3）。它们不是特定于项目的，属于集中式数据存储。特定项目相关的TE列表是该通用列表的子集。

5.3.未知用例的验证

对未知用例进行验证的目的是，表明开发中的系统不会产生任何不可接受的风险，即使是在开发过程中未直接考虑的用例。

选择用于测试的用例应遵循用例在一般人群中的分布。这不一定包括特定的用例，尤其是那些与触发事件相关的用例，因为它们应该已经在确认阶段挑出来了。

HARA中给出了用例的基本概率（参见章节5.1）。概率以每小时或每公里给出。但是，仅将数字倒置将使该用例的安全性置信度低于50%。应考虑二项分布的用例概率来计算完整的验证里程。L2的典型验证距离为数十万公里，最高可达一百万公里。然而，正确规划验证距离比它的长度更重要。驾驶条件（例如天气、地点、市内/市外驾驶等）应根据目标车辆所经历的分布进行加权。当地交通部门收集的与道路交通相关的统计数据（例如AASHTO所谓的“绿皮书”）是与此相关的主要信息来源。

驾驶和事故统计数据是“预期功能数据”的一部分（见图3）。它们不是特定于项目的，属于集中式数据存储。

5.4.安全评估报告

安全评估报告(SAR)总结安全证据并提供安全论据，即对安全生命周期的发现进行解释。SAR通常以半正式的方式编写。对于通用安全生命周期，SAR基本上是根据ISO 26262的要求创建的，但也包括SOTIF相关的证据。

不需要对SAR的创建过程进行具体更改。

6.结论

本文的主要贡献是通用安全生命周期，整合了功能安全和预期功能的安全生命周期。显示了WP之间的需求分布（表1）。引入了用于存储有关预期功能的非项目特定数据的单独数据库的概念（章节5，图3）。两个生命周期的集成使SOTIF更清晰，更易于实施。

功能安全通常被当局或客户视为“只是另一项要求”。但是，如果基于系统工程方法实施，FS和SOTIF都有助于提高对正在开发的系统的理解并使其更安全。它们有助于未来的更新和修改，从而降低开发和售后市场活动的成本。

作者：牛喀网专栏作者
牛喀网文章，未经授权不得转载！