在车载系统开发中，符合 ISO 21448 和 ISO 26262 的需求日益增长。然而，挑战在于实现一种高效的安全分析方法，通过有效共享两者各自的部分来同时符合这两项标准。为应对这一挑战，我们聚焦于 STAMP/STPA。STAMP/STPA 适用于产品开发过程概念阶段的安全分析，ISO 21448 的附录中提供了 STAMP/STPA 的应用示例。本文提出了一种扩展的 STAMP/STPA，能够高效地符合这两项国际标准。

近年来，在车载系统开发中，对车辆安全性国际标准 ISO 21448和功能安全国际标准 ISO 26262的合规要求日益增加。两项标准之间存在共同项目，但尚未确立能够减少两项标准合规流程的安全分析方法。为实现对两项标准的高效合规，我们关注到在 ISO 21448 附录 B.4 中给出实施示例的现有安全分析方法 STAMP（系统理论事故模型与过程）/STPA（基于 STAMP 的过程分析）。本文通过导出 ISO 21448 和 ISO 26262 的共同项目，提出一种能实现各标准高效合规的 STAMP/STPA 扩展方法。

本章将对关于车辆层面安全性的标准 ISO 21448 以及关于车辆内项目层面功能安全的标准 ISO 26262 的概要进行说明。

2.1. ISO 21448 的概要

ISO 21448 是关于车辆预期功能安全性的国际标准，也被称为 SOTIF（预期功能安全）。ISO 21448 旨在减少和防止系统无失效状态下危害事件的发生，与 ISO 26262 形成互补关系。图 1 展示了两项标准在概念阶段的相关步骤以及需要导出的项目。如图 1 所示，在 ISO 21448 中，第 5 条对分析对象的规格和设计进行定义后，第 6 条导出对车辆造成危害的潜在危害（Hazard）。之后，以与 ISO 26262 同等的粒度对危害性（Severity）、暴露概率（Exposure）、控制可能性（Controllability）进行评估，并根据危害性和控制可能性的值进行风险评估。

图1:ISO 21448与ISO 26262的对应关系概念阶段

2.2. ISO 26262 的概要

ISO 26262 是旨在防止因系统失效而引发危害事件的国际标准，在概念阶段相关内容的第 3 部分中，需实施 HARA（危害分析与风险评估）。如图 1 右侧所示，第 5 条对项目（Item）进行定义后，第 6 条导出项目层面的危害。项目指的是实现车辆某项功能或功能一部分的单个或多个系统，危害则是指由项目误操作引发的潜在危害。之后，导出安全目标（Safety goal），并利用与项目及危害相关联的危害性、暴露概率、控制可能性的值来计算 ASIL（汽车安全完整性等级）。

2.3. 先行研究

如图 1 所示，在两项标准的第 6 条中，都会导出危害、导致危害的状况（hazardous event）、危害性、暴露概率、控制可能性。然而，目前尚未确立能够利用这些共同项目来整合两项标准合规流程的分析方法，现状是必须分别对应两项标准。

为解决这一问题，本研究关注到 STAMP/STPA。在 ISO 21448 附录 B.4 中，存在与第 6 - 7 条相对应的 STAMP/STPA 实施示例。此外，关于运用 STAMP/STPA 来满足各标准要求的研究也在推进中，但这些研究仅停留在针对个别标准应用的层面，并未解决上述问题。因此，参考这些先行研究，本研究提出一种能够导出两项标准共同项目的 STAMP/STPA 扩展方法（以下简称 STPA 扩展方法）。

STAMP/STPA 是一种聚焦于系统内各组成部分之间的相互作用，对系统危害状态进行分析的安全分析方法。

STAMP 是一种模型，其核心观点是：系统事故大多并非由组成要素的失效引起，而是源于系统内执行安全控制的要素与被控制要素之间相互作用的不协调。

STAMP/STPA（以下简称 STPA）是在 STAMP 模型基础上，对引发系统危害事件的因素进行分析的安全分析方法。在车辆或车载设备的开发中，STPA 在概念阶段发挥着重要作用。下面对 STPA 各步骤的详细内容进行说明。

步骤 1：定义分析目的

导出包含系统损失的事故，并导出与各事故相关联的危害状态即危害。之后，将安全约束（Safety Constraints）定义为系统为避免陷入各危害状态而必须满足的条件或应执行的操作。

步骤 2：构建控制结构模型

将分析对象所包含的设备、相关人员等作为组成部分，构建控制结构图（以下简称 CS 图）。在该图中，各组成部分之间的连接关系通过控制动作（以下简称 CA）和反馈（以下简称 FB）的相互作用来体现。CA 指的是控制器向被控制过程发送的指示、命令。FB 指的是被控制过程向控制器发送的、对 CA 的响应以及控制器为掌握被控制过程状态所需的信息。

步骤 3：识别不安全控制动作

针对 CS 图中的每个 CA，运用指导词来导出引发危害的非安全 CA，即 UCA（不安全控制动作）。指导词包括 “未提供（Not providing）”“提供导致危害（Providing causes hazard）”“过早 / 过晚（Too early/Too late）”“停止过早 / 应用过久（Stop too soon/Applying too long）” 这 4 种。

步骤 4：识别损失场景

导出导致各 UCA 发生的损失场景，并将危害因果因素（Hazard Causal Factor，HCF）作为损失场景的危害成因进行导出。

4.1. STPA 扩展方法的要件定义

为提出通过导出两项标准的共同项目及共同项目，从而实现各标准高效合规的 STPA 扩展方法，将该方法应满足的 4 项要求定义如下。

R.1 导出传统 STAMP/STPA 所导出的全部项目

R.2 为满足两项标准的要求，无需分别实施 STPA，通过一次 STPA 实施即可导出两项标准的共同项目

R.3 依据标准要求事项，导出 ISO 21448 第 6 条与 ISO 26262 第 6 条中的共同项目

R.4 导出 ISO 21448 附录 B.4 中的全部项目（均为 ISO 21448 第 7 条中的项目）

R.1 作为 STPA 扩展方法的研究，是必备要求。R.2 和 R.3 基于本研究的目的，即通过导出共同项目来减少各标准的合规流程而定义。为满足这些要求，需要导出的项目如表 1 中 No.1 - 5 的 5 项。此外，尽管 ASIL 并非共同项目，但可基于 R.3 进行导出。

R.4 之所以作为要求，是因为若要使该方法成为符合 ISO 21448 的分析方法，最好能与附录 B.4 中的 STPA 实施示例相对应。为满足附录 B.4 的要求，需要导出的项目如表 1 中 No.1 以及 No.6 - 11 的 7 项。

表 1 :满足 R.3 和 R.4 的项目

标准中指出，危害行为（hazardous behaviour）与 UCA 相当，因此可按照与传统方法相同的步骤进行导出。不充分的状况（insufficiency condition）、触发状况（Trigger condition）、功能不足（functional insufficiencies）、输出不足（output insufficiencies）是传统 STPA 中未导出的项目，均需基于损失场景来制定。不充分的状况通过与 UCA 相关的系统控制器或其他要素的单个或多个输出不足的组合来确定。触发状况指的是诸如碰撞时前方有障碍物、恶劣天气等损失场景发生的状况。功能不足指的是传感器失效等系统存在的缺陷、不足。输出不足则是由功能不足引发的、与一个或多个组成部分输出相关的缺陷。

4.2. STPA 扩展方法的步骤

提出满足 4.1 节所列各项要求的 STPA 扩展方法（以下简称本方法）。图 2 展示了本方法的整体分析流程以及将导出的项目。按照该流程操作，能够导出表 1 所示的全部项目，满足 R.3 和 R.4 的要求。此外，第 3 章所介绍的 STPA 流程在后续章节中称为传统方法。

图2：扩展型STAMP/STPA分析流程

本方法的步骤 1 为导出与传统 STPA 中的危害相当的车辆层面危害（以下简称危害（21448））以及更细化的项目层面危害（以下简称危害（26262）），将其分为步骤 1.1 和步骤 1.2。在步骤 1.1 中，导出事故、危害（21448）、危害、运行状况（Operational situations，以下简称 OS），并依据 ISO 26262 - 3 6.4.3 表 1 的规定对危害性（S）进行评估。此时，将危害（26262）与作为基础的危害（21448）相关联。在后续的步骤 1.2 中，依据危害（26262）以及步骤 1.1 导出的 OS，按照 ISO 26262 - 3 6.4.3 表 2 的规定对暴露概率（E）进行评估。同时，将危害（26262）与 OS 的组合作为导致危害的状况（26262）。

表 2:分析结果汇总

步骤 2 基于步骤 1 的导出结果，按照与传统方法相同的步骤构建 CS 图。步骤 3 同时关注危害（21448）和危害（26262），按照与传统方法相同的步骤导出 UCA。由于在 ISO 21448 附录 B.4 中，UCA 被视为危害行为，因此在本方法中也作同样处理。步骤 4 同样按照与传统方法相同的步骤，从各 UCA 导出包含 HCF 的损失场景。

在步骤 5 中，由于包含非失效类 HCF 的损失场景对应 ISO 21448 的内容，而包含失效类 HCF 的损失场景对应 ISO 26262 的内容，因此在步骤 5.1 和步骤 5.2 中分别进行处理。在步骤 5.1 中，针对包含非失效类 HCF 的损失场景，依据 ISO 26262 - 3 6.4.3 表 3 的规定对控制可能性（C）进行评估，并制定不充分的状况。之后，制定触发状况、功能不足、输出不足。此时，这 3 项内容作为因果因素（Causal factors，CF）来处理。另外，在 ISO 21448 的风险判定中，危害性为无（S0）或易于控制（C0）的场景不被视为不合理风险。因此，利用损失场景的 S 值和 C 值来判定该损失场景是否属于不合理风险。

表 3：扩展的 STAMP/STPA 步骤 1.1 的结果

步骤 5.2 处理包含失效类 HCF 的损失场景。对于这些损失场景，按照与步骤 5.1 相同的方式评估控制可能性（C）。之后，追溯与损失场景相关联的 UCA、与 UCA 安全约束相关联的导致危害的状况（26262）以及危害（21448），并依据相关联的 S、E、C 值，采用 ISO 26262 - 3 6.4.3 表 4 的计算方法来计算各损失场景的 ASIL。此时，通过参考与导致危害的状况（26262）相关联的各损失场景的 C 值以及 ASIL 的最高值，能够得到导致危害的状况（26262）的 C 值评估结果和 ASIL 计算结果。

表 4：扩展的 STAMP/STPA 步骤 1.2 的结果

5.1. 分析对象

为评估本方法是否满足 4.1 节所列的 4 项要求，以 MathWorks 公司提供的 AEB（自动紧急制动）系统（6）的 MATLAB/Simulink 模型作为分析对象，对本方法进行试行。该 AEB 系统会根据与前方障碍物的距离以及相对速度，向车辆发送制动指示。

5.2. 试行结果

本方法的试行结果汇总于以下表 2。在本次试行中，仅导出了与 UCA1N - 1（参见表 5）相对应的损失场景及其导出项目。

表 5：扩展的 STAMP/STPA 步骤 3 的结果

表 3 和表 4 分别展示了本方法步骤 1.1 和步骤 1.2 的部分试行结果。在步骤 1.1 中，从 “车辆与障碍物发生碰撞，导致驾驶员及交通参与者受伤” 这一事故出发，导出了危害、危害对应的危害性（S）、引发事故的危害（21448）以及危害（21448）发生的 OS。在步骤 1.2 中，将危害（21448）细化到作为项目的 AEB ECU 层面，导出危害（26262），并对安全约束以及危害的暴露概率（E）进行了评估。

步骤 2 所构建的分析对象 CS 图如图 3 所示。图中实线（红字）表示 CA，虚线（蓝字）表示 FB。

图3：AEB系统控制结构

步骤 3 中，针对图 3 中的每个 CA，运用与传统 STPA 相同的 4 种指导词导出 UCA。表 5 展示了针对其中一项 CA “制动控制指令” 的试行结果。

步骤 4 中，从步骤 3 导出的 UCA 中，选取 “（UCA - N - 1）制动控制指令未传递至车辆，AEB 未启动导致碰撞” 这一 UCA，导出包含 HCF 的损失场景。表 6 展示了步骤 4 的部分试行结果。

表 6：扩展的 STAMP/STPA 步骤 4 的结果

步骤 5.1 中，针对步骤 4 导出的包含非失效类 HCF 的损失场景，依据 ISO 21448 的实施示例进行分析，评估损失场景的控制可能性（C）。同时，利用危害性（S）和控制可能性（C）的值进行风险判定。

步骤 5.2 中，针对包含失效类 HCF 的损失场景，评估其控制可能性（C），并依据与 UCA 相关联的 S 值和 E 值，按照 ISO 26262 的规定计算 ASIL。

本章基于试行结果，从是否满足第 4 章所定义的各项要求以及能否减少两项标准的合规流程这两个方面对本方法进行评价。之后，阐述本方法存在的问题。

6.1. 要求对应评价

对 5.2 节所示试行结果是否满足第 4 章定义的本方法各项要求进行评价，结果如下。评价结果表明，本方法满足各项要求。

R.1 导出传统 STAMP/STPA 所导出的全部项目

从 5.2 节各表可知，本方法能够导出 STPA 的各项项目。

R.2 为满足两项标准的要求，无需分别实施 STPA，通过一次 STPA 实施即可导出两项标准的共同项目

试行结果表明，通过一次 STPA 实施能够导出两项标准的共同项目（表 1 中 No.1 - No.5）。

R.3 在概念阶段范围内（ISO 21448 第 6 - 7 条、ISO 26262 第 6 - 7 条），依据标准要求事项导出两项标准的全部共同项目

通过试行确认，能够按照各标准的要求事项导出表 1 中 No.1 - No.5 的项目。

R.4 导出 ISO 21448 附录 B.4 中的全部项目（均为 ISO 21448 第 7 条中的项目）

通过试行确认，能够按照要求事项导出表 1 中 No.1 以及 No.6 - No.11 的 7 项项目。

6.2. 对应流程削减效果评价

从 5.2 节的试行结果可以看出，采用本方法，以往需在各标准中分别进行分析并单独导出的共同项目，通过一次方法实施即可完成导出。此外，由于步骤 5.1 的分析结果符合 ISO 21448 附录 B.4 的要求，可直接将分析结果应用于后续的 SOTIF 活动。在步骤 5.2 中，损失场景和 ASIL 的判定结果也可应用于 ISO 26262 后续条款的相关工作。综上所述，由于通过一次分析能够导出两项标准的共同项目，并且能够满足后续标准内容的要求，因此与分别对应 ISO 21448 和 ISO 26262 相比，本方法能够减少各标准的合规流程。

此外，由于本方法能够同时满足两项标准的要求，可减少分别对应各标准时可能出现的分析内容不一致问题。这一点有助于减少返工情况的发生，从而缩短工作流程。

6.3 本方法的问题

本节总结通过试行发现的两个问题。

第一个问题是，本方法无法导出暴露概率低的损失场景，导致这些损失场景无法用于后续各项标准的合规工作。由于 STPA 是一种聚焦于系统运行时各组成部分相互作用不协调的分析方法，因此本方法步骤 1 中导出的运行状况被认为是系统运行的一般状况。其结果是，基于此类运行状况评估得出的暴露概率总体偏高（但对于仅在特定运行状况下使用的功能而言，情况并非如此）。

为解决这一问题，可考虑根据运行状况的差异对危害进行细分导出等方法。然而，事故和危害的细分程度越高，分析工作的工时就越多。因此，需要根据对暴露概率低的损失场景的需求程度，考虑是否对运行状况进行细分等。

第二个问题是，在步骤 5.1 中难以轻松导出不充分的状况、触发状况、功能不足和输出不足。在本方法的试行过程中，出现了难以对这 4 个项目进行适当区分的问题。在 ISO 21448 附录 B.4 所示的 STPA 实施例中，触发状况、功能不足和输出不足并未加以区分就被导出，标准中未记载各个项目详细的导出方法和区分方法。因此，需要在理解各项目定义和内容差异的基础上，注意避免偏离定义进行导出。这一问题被认为也是 ISO 21448 自身存在的问题，因为其未给出触发状况等项目明确的导出步骤。要解决本方法中的这一问题，在步骤 5.1 中，要么不明确区分各项目而进行列举，要么需要根据 HCF 的内容制作用于选择适用的触发状况等项目的检查表。

在本研究中，为减少 ISO 21448 和 ISO 26262 两项标准的合规流程，提出了一种扩展 STPA 分析步骤的安全分析方法，并进行了试行。结果表明，本方法对两项标准的高效合规具有实用价值。

在本方法中，通过将 ISO 21448 的车辆层面危害进行细化，导出 ISO 26262 的项目层面危害，并根据作为 STAMP/STPA 最终成果的损失场景所关联的 HCF 内容，区分对应哪项标准，从而实现了两项标准要求及共同项目的导出。

本方法的试行结果证实，该方法能够通过一次分析导出两项标准的共同成果，并且能够减少两项标准的合规流程。同时，试行也暴露出一些问题，如无法导出暴露概率低的损失场景，以及 ISO 21448 附录 B.4 中触发状况等项目的导出方法不明确。为解决这些问题，今后将继续改进分析方法。