整合STPA、ISO 26262与SOTIF的自动驾驶安全需求推导与验证

摘要

高级驾驶辅助系统和自动驾驶系统需要随复杂系统的快速整合而相应扩展的安全性分析。本文将系统理论过程分析（STPA）与 ISO 26262 功能安全生命周期以及 ISO 21448 预期功能安全（SOTIF）指南相结合，形成了一套从危害发现、安全目标定义到正确实施 STPA 需求的端到端方法。STPA 中的不安全控制行为（UCA）通过否定转化为可追溯的安全目标（SG），并利用运行设计域（ODD）参数，从严重度、可控性和暴露度三个维度为安全目标分配汽车安全完整性等级（ASIL），进而将其转化为功能安全需求和技术安全需求。每一项需求都明确了特定的测试目标，并据此制定符合 ISO 26262 的测试计划，以确保基于证据的验证。为说明这些整合步骤，本文以通用 SAE 4 级系统架构的 STPA 分析作为案例研究，展示了系统分析与针对性测试如何共同增强对自动驾驶车辆安全性的信心。

1、引言

随着高级驾驶辅助系统（ADAS）和自动驾驶系统（ADS）等先进系统的广泛应用，汽车行业的复杂性日益增加。尽管这些系统能够辅助驾驶员驾驶或实现车辆自主行驶，并承诺安全运行，但由于其自身复杂性，以及在软件、人为因素和运行环境方面可能存在的不可预见的交互作用，它们为确保系统整体安全性带来了重大挑战。在汽车行业中，ISO 26262 通过其 V 型开发周期提供了证明功能安全的框架，该框架从概念阶段一直应用到产品发布阶段。它确立了在产品生命周期内对危害进行测试和验证的结构化流程，并将组件划分为不同的汽车安全完整性等级（ASIL）。然而，ISO 26262 并未涵盖由系统预期功能引发的风险，尤其是在涉及意外环境交互的场景中。为填补这一空白，预期功能安全（SOTIF，ISO/PAS 21448）标准应运而生。SOTIF 是一项最新的 ISO 标准，针对的是即使系统符合 ISO 26262 要求且无故障时，由系统预期功能或性能限制所导致的潜在危害行为。

尽管 ISO 26262 与 SOTIF 共同构成了一个更全面的框架，可同时应对功能安全和预期功能安全问题，但它们在从危害分析直接推导和验证需求的方法上仍存在欠缺。因此，要对汽车系统进行真正全面的安全性评估，就必须借助结构化的危害分析技术来补充这些标准。故障树分析（FTA）和故障模式与影响分析（FMEA）等传统方法已与这些标准广泛结合使用。然而，由于这些传统方法主要关注硬件和组件级别的故障，可能会忽略关键的系统级风险、与软件相关的危害以及由预期功能引发的不安全交互。因此，亟需一种新的方法来应对这些安全挑战。

为解决上述不足，基于系统理论事故模型与过程（STAMP）的系统理论过程分析（STPA）应运而生。STAMP 是一种源于系统理论的事故因果模型，它为理解系统运行方式提供了科学基础，并融入了系统思维，通过应用这些原理来应对潜在故障。STPA 是一种先进的危害分析范式，优于 FMEA、FTA 和危害与可操作性研究（HAZOP）等传统工具。与关注组件级失效不同，STPA 会考察整个系统的交互作用以及现代汽车平台中固有的系统级风险，同时考虑人为、软件和组织等方面的因果因素。因此，它能够检测出传统方法可能忽略的与软件相关的场景以及非失效场景。

STPA 的输出结果通过生成安全需求来减轻与分析中识别出的不同因果因素相关的不安全控制行为（UCA），从而提高系统的稳健性。这些输出结果可应对系统故障、功能安全和预期功能安全等问题 [9]。然而，如何将 STPA 结果转化为符合 ISO 标准且具有清晰、可衡量验证目标的安全标准，仍然是一项挑战。近期研究表明，如何系统地将 UCA 映射为安全目标（SG）、进行 ASIL 分配以及定义 SOTIF 场景验证，这些问题目前仍未得到解决。因此，为确保系统整体安全，在系统设计中实施由 STPA 推导的需求之前，必须对这些需求进行严格的验证与确认（V&V）。

为填补这一方法空白，本文探索了 STPA 与 ISO 26262 及 SOTIF 的整合，并提出了一种推导和验证安全需求的方法。首先，通过将 STPA 中的 UCA 进行否定来推导安全目标（SG）；其次，提出一种基于运行设计域（ODD）推导标准的 ASIL 分配新方法；然后，根据 ASIL 分配结果，在 STPA 范式内定义与 SOTIF 相关的风险；针对每个安全目标，制定一系列功能安全需求（FSR）和技术安全需求（TSR），以确保安全目标的实现；随后确定合格标准；在最后阶段，利用已识别的不安全场景和安全需求，依据 ISO 26262 和规定的测试目标，为每个场景定义验证目标并选择合适的验证活动。通过对每个已识别的风险进行测试和验证，可显著提高系统的整体安全性和可靠性。

2、相关工作

ISO 26262 和 SOTIF 都强调了基于场景的测试的重要性，但在推导符合标准隐含需求的测试场景的方法方面，它们仍存在空白，且未提供明确的合格标准来验证这些场景，这使得评估所提出安全措施的有效性变得困难。

由于 STPA 与 ISO 26262 及 SOTIF 的整合在应对安全挑战和跟上快速发展步伐方面具有重要意义，现有文献中已对其进行了探讨。文献提出了在 SOTIF 背景下应用 STPA 的研究，证明了该方法在应对盲点检测（BSD）系统危害方面的有效性 ——BSD 系统是最常见的自动驾驶功能之一。该研究强调了这种整合在提升风险评估方面的潜力，并针对与 SOTIF 相关的触发条件确定了 24 项改进措施。

除上述标准外，研究人员还提出了多种方法来补充 ISO 26262 和 SOTIF。文献提出了过程映射方法，该方法结合了基于系统建模语言（SysML）的综合元模型，以促进将 STPA 整合到 ISO 26262 功能安全流程中。具体而言，该文献展示了 STPA 如何按照 ISO 26262 的危害分析与风险评估（HARA）方法的规定，助力提升对安全性和系统级目标（包括汽车安全完整性等级（ASIL）分类）的评估。

这些广泛的研究主要围绕在 ISO 26262 和 SOTIF 标准框架下，通过整合 STPA 来应对危害识别和风险评估问题。然而，它们并未进一步提供将 STPA 输出转化为测试场景、定义合格 / 不合格标准以及选择符合 ISO 26262 的适当验证活动的方法。为解决这一问题，本文对这种整合方法进行了研究，以填补空白，确保 STPA 推导的需求不仅能被识别，还能在符合 ISO 26262 和 SOTIF 的前提下得到验证。

3、所提方法的创新点

本文提出了一种创新方法，通过整合 STPA、ISO 26262 和 SOTIF 来填补现有空白。此外，该方法还利用 ISO 26262 标准中确立的结构化测试计划，对 STPA 的分析结果进行验证。

首先，从已识别的不安全控制行为（UCA）中推导安全目标（SG）；接着，提出一种基于运行设计域（ODD）中定义参数的 ASIL 分配新方法；考虑到整合新兴技术的系统所固有的复杂性，该方法进一步纳入了与 SOTIF 相关的风险，并确定了相应的改进措施。

随后，通过这些综合评估推导功能安全需求（FSR）和技术安全需求（TSR），进而确定合格标准和测试目标；最后，选择并分配合适的测试方法，以确保准确实施并全面验证通过 STPA 过程识别的安全需求。

本研究的主要贡献如下：

1. 通过整合 ISO 26262、SOTIF 和 STPA，解决传统标准的局限性；

2. 为正确实施由 STPA 推导的需求制定测试计划；

3. 提升系统设计的稳健性和可靠性；

4. 推动 STPA 在汽车行业的实际应用，并确保符合安全法规和政策。

4、方法

4.1 STPA 方法概述

STPA 是一种基于系统理论事故模型与过程（STAMP）的危害分析技术。STAMP 是一种基于系统思维的事故模型，尤其适用于复杂系统，能够识别涉及组件交互、系统以及人为因素的更广泛因果因素。在 STAMP 中，事故被视为动态控制问题，而非故障问题。与 FTA 或 FMEA 等其他传统安全分析方法不同，STPA 是一种全面的方法，旨在识别可能导致危害场景的潜在不安全行为，并制定需求以改进设计。STPA 已在多个领域得到广泛应用，包括航空领域、汽车领域、铁路安全管理领域，以及大型语言模型时代的安全分析。

4.2 所提方法

本文提出了一种结构化方法（图 1），通过将不安全控制行为（UCA）转化为否定表述来推导安全目标（SG），每个安全目标都与相应的不安全控制行为明确关联。此外，本文还提出了一种 ASIL 分配新方法，该方法利用从运行设计域（ODD）推导的既定标准，对严重度、可控性和暴露度进行评估，且这种 ASIL 分配符合 ISO 26262 标准。随后，定义安全状态，以便在发生预期行为偏差时采取纠正措施。此外，根据分配的 ASIL，在 STPA 框架内整合与 SOTIF 相关的风险。

图 1、所提方法结合了用于全面危害分析和需求推导的 STPA，以及用于从 STPA 输出推导安全目标和 ASIL 分配、进而定义与 SOTIF 相关风险和结构化测试的 ISO 26262）

针对每个安全目标，制定相应的系统级功能安全需求（FSR），以确保这些安全目标得以实现。在 ISO 26262 中，功能安全需求属于功能安全概念范畴，因此，它们用于应对 STPA 在控制结构较高层级识别出的不安全控制行为（UCA）。

这些功能安全需求与 STPA 第四步中识别的因果因素明确关联，从而确保在整个安全生命周期内对危害进行可靠追溯。根据 ISO 26262 指南，为这些功能安全需求定义故障容忍时间间隔（FTTi），以便及时检测和缓解系统故障。

下一步，从 STPA 识别的因果因素中推导子系统或组件级别的技术安全需求（TSR），并将其分配给控制结构中的各个元素。这些技术安全需求将高层级约束转化为架构各元素内具体的技术措施。

随后确定验证的合格标准。最后，以已识别的不安全场景和安全需求为基础，依据 ISO 26262 和明确界定的测试目标，确定验证目标并选择适当的验证活动。通过对每个已识别的风险场景进行测试和验证，可提升系统的整体安全性和可靠性。本文以通用 SAE 4 级系统架构作为实际案例，展示了如何在 ISO 26262 流程中应用 STPA。通过整合 STPA、ISO 26262 和 SOTIF，本研究提供了一个连贯的框架，可缓解复杂系统相关的风险，并确保汽车行业功能安全达到更高标准。

5、STPA分析与整合结果

本节将介绍 STPA 过程在 ISO 26262 和 SOTIF 框架内的整合方法，并通过示例说明该方法的应用。STPA 分析由 WMG 与外部合作伙伴共同开展，其输出结果（尤其是已识别的不安全控制行为（UCA）和相关因果因素）是实施所提方法的基础。

5.1 STPA输出

STPA 的第一步是确定系统边界、损失和危害，该步骤的输出将在后续呈现。接下来进行 STPA 第二步，即根据项目定义中提供的信息，建立高层级控制结构模型，该模型可在完成 STPA 第四步的过程中进一步完善。

5.1.1 系统定义

本文以通用 SAE 4 级系统架构作为案例研究。该系统的运行设计域（ODD）包括最低限速为 60 公里 / 小时的城市道路，以及雾天等能见度较低的恶劣天气条件。

5.1.2 不安全控制行为的推导

在建立控制结构模型后，下一步是识别具体的控制行为以及这些行为可能出现不安全情况的场景。

在 STPA 范式中，这一步需要定义可能导致至少一种危害的不安全控制行为（UCA），该步骤与 ISO 26262 中描述的危害识别过程相对应。

为简化说明并提高方法应用的清晰度，本案例研究仅使用一个不安全控制行为（UCA）。

以 “路径规划” 这一控制行为为例，考虑以下不安全控制行为：UCA1：当自车（EV）处于行驶状态且自动驾驶系统（ADS）控制自车时，任务规划器向制导系统提供错误的路径规划信息。

推导的安全约束（SC）：SC1：当自车在自动驾驶系统（ADS）控制下行驶时，任务规划器应仅向制导系统提供正确的路径规划数据，确保不会出现错误或不安全的路径指令。

5.2 安全目标定义与 ASIL 分配

为将 STPA 在系统级推导的不安全控制行为（UCA）映射到车辆级，需将已识别的不安全控制行为转化为：UCA1：目标车辆（VOI）在行驶过程中提供错误的路径规划信息。

每个不安全控制行为都需与至少一种危害相关联；若未关联任何危害，则不能将其视为不安全行为。上述不安全控制行为与以下危害事件相关联：H4：目标车辆未能遵循预设路线 / 完成预设行程；H5：目标车辆未能遵循道路和路口规则；H6：目标车辆未能遵循交通信号灯、交通标志 / 交通规则。

下一步是为每个不安全控制行为（UCA）分配相应的安全目标（SG）。

5.2.1 从 STPA 结果推导安全目标

对于每个不安全控制行为（UCA），通过否定其表述来制定相应的安全目标（SG），即每个安全目标都明确了为防止不安全控制行为发生而必须确保的条件。

例如，从 UCA1 推导得出以下安全目标：SG1：目标车辆（VOI）在行驶过程中应始终提供准确的路径规划信息。

制定该安全目标是为了防止目标车辆在行驶过程中因路径规划信息不准确或不可用而出现不安全场景，这体现了如何在 STPA 第三步分析不安全控制行为（UCA）的过程中直接推导安全目标。每个安全目标都与特定的不安全控制行为（UCA）及其在系统控制结构中的相关控制回路相关联。

针对每个安全目标，需识别潜在的缓解失效模式 —— 该模式描述了安全目标在缓解危害方面可能出现的失效情况。在这种情况下，系统的预期行为被称为安全状态（SS）。

在此基础上，在定义完安全目标（SG）后，下一步是为每个安全目标分配 ASIL，以确定所需的风险降低程度。需根据运行设计域（ODD）参数评估严重度、暴露度和可控性这三个因素，并依据评估结果对已识别的不安全控制行为（UCA）进行分类，进而确定 ASIL，并将其分配给为缓解这些不安全控制行为而制定的安全目标（SG）。

5.2.2 为安全目标分配 ASIL

本小节将介绍 ASIL 分配方法。为实现这一目标，需基于下文中描述的运行设计域（ODD）参数，确定 ASIL 分配的标准。

基于运行设计域（ODD）的 ASIL 分类标准ASIL 分配将依据以下标准进行：位置 / 道路布局、车辆速度、环境 / 周边元素、动态行驶状态、能见度、受影响人员。

表1展示了针对本案例研究中 SAE 4 级系统与 UCA1 相关的、从运行设计域（ODD）推导得出的 ASIL 分类标准。

表1、 ASIL分类标准

依据 ISO 26262 的 ASIL 确定标准本方法遵循 ISO 26262 标准，采用与该标准相同的 ASIL 分配流程。ASIL 的确定将基于以下参数：

· 严重度

· 可控性

· 暴露度

这些参数将根据上文表 1 中定义的运行设计域（ODD）参数进行评估。汽车安全完整性等级（ASIL）分为四个等级：ASIL A（最低等级）、ASIL B、ASIL C 和 ASIL D（最高等级）。此外，质量管理（QM）等级表示根据 ISO 26262 标准无相关安全需求。

为说明本节内容，将采用所提方法为 UCA1 分配 ASIL。

方法应用：为 SG1 分配 ASIL严重度（S）：在城市环境、高速行驶（60 公里 / 小时）且能见度较低的情况下，路径规划信息错误可能导致严重事故甚至致命事故。该 UCA 与 H-4、H-5、H-6 相关联，可能造成严重伤害或死亡。

· 评估结果：S3（造成伤害或死亡）。

暴露度（E）：存在恶劣天气和低能见度的城市道路较为常见，因此暴露度较高。

· 评估结果：E4（发生概率高）。

可控性（C）：在恶劣天气、能见度低的条件下，若缺乏正确的路径规划信息，很难安全控制车辆。

· 评估结果：C3（难以控制）。

分配的 ASIL 为 ASIL D。

为某个 UCA 确定的 ASIL 将分配给其对应的安全目标（SG）。

注：一个潜在的 UCA 可能对应多个安全目标，若这些安全目标相似，可将它们合并为一个安全目标，并为该合并后的安全目标分配这些安全目标中最高的 ASIL。

5.3 是否存在相关的 SOTIF 风险？

5.3.1 识别特定于 SOTIF 的风险场景

要将某一风险归类为与 SOTIF 相关的风险，关键在于确定危害场景是否由系统的预期功能引发，而非由故障导致。根据 ISO 21448 标准，可采用 ISO 26262-3:2018（第 6节）中描述的方法，对 SOTIF 分析中危害场景的严重度和可控性进行评估。尽管所采用的方法相同，但针对 SOTIF 危害评估的具体结果和参数可能与传统的 ISO 26262 分析有所不同。

在此背景下，归类为与 SOTIF 相关的场景，其严重度和可控性必须超过可忽略等级（分别为 S0 和 C0）。通过利用表 1 中识别的触发条件，对特定于 SOTIF 的风险进行评估，并确定相应的改进措施。

5.3.2 潜在的安全影响

将所提方法应用于本案例研究，目标车辆（VOI）在未接收到更新的路径引导信息（如新的或修正后的导航数据）的情况下继续运行，这一场景即为特定于 SOTIF 的风险场景。该场景凸显了系统预期功能中固有的局限性，可能导致不安全的操作，或使目标车辆错过关键的路径调整。分析表明，此类场景可能导致危害情况，其严重度为 S3、可控性为 C3，这凸显了制定针对性缓解策略的必要性。

5.3.3 提出的改进措施

基于表 1 中识别的危害场景属性，针对风险场景 UCA1，提出以下针对性改进措施：

· 增强导航数据完整性检查：对导航数据的可靠性进行实时监测，尤其在城市道路布局环境中；

· 环境检测系统：整合先进传感器以检测恶劣天气条件，并触发预防措施；

· 动态路径调整机制：当主要路径更新缺失或错误时，启用备用导航数据。

5.4 安全需求

在确定安全目标（SG）和 ASIL 分类后，下一步是定义安全状态（SS），即确定在出现预期行为偏差时应采取的纠正措施。

SS1：切换至备用导航系统或使车辆安全停车。

为实现每个安全目标（SG），需制定相应的功能安全需求（FSR）。功能安全需求规定了确保相关安全目标得以实现的、高层级的车辆级功能措施。

在推导功能安全需求（FSR）之后，需定义技术安全需求（TSR）以实施这些功能安全需求。技术安全需求是基于 STPA 过程中识别的因果因素制定的详细技术级需求，将其分配给控制结构中的相应组件，以确保系统保持或恢复到安全状态。

以下小节将详细介绍这些步骤。

5.4.1 第四步：识别损失场景

下一步是定义损失场景，明确导致不安全控制行为（UCA）的因果因素，确定这些不安全控制行为如何违反系统需求并产生不安全后果。为缓解这些风险，关键在于通过完善设计需求和增强安全特性来应对这些因果因素。

从 STPA 第四步推导的因果因素（CF）示例：“任务规划器中用于发送路径规划信息的指定控制算法存在错误。”

该示例表明，因果因素揭示了系统控制逻辑在提供准确路径规划信息方面可能存在的缺陷，进而为制定直接应对这一潜在危害的特定功能安全需求提供了依据。

5.4.2 功能安全需求（FSR）

根据文献的定义，功能安全需求是对与实现无关的安全行为或与实现无关的安全措施（包括其安全相关属性）的规范。

按照所提方法，首先从 STPA 第四步推导（系统及软硬件层面的）功能安全需求（FSR），以确保：

· 功能行为正确；

· 能够检测任何故障或功能异常。

然后，将这些功能安全需求分配给控制结构中的项目元素。功能安全需求在系统级定义，具体如表 2 所示。

表2、功能安全需求与技术安全需求

功能安全需求（FSR）的识别：在推导并分配功能安全需求后，它们将成为确保系统能够维持或恢复到安全状态的、与实现无关的措施的基础。

时序需求：需为每个功能安全需求分配时序需求，其中包括文献提及的故障容忍时间间隔（FTTi）。根据文献的定义，故障容忍时间间隔是指在危害事件发生前，系统中可存在一个或多个故障的时间段，它包括诊断时间（故障检测时间）和故障响应时间（检测到故障后达到安全状态所需的时间）。

根据 STPA 中定义的检测型需求和预防型需求这两种类型，故障容忍时间间隔（FTTi）的取值将有所不同：

对于检测型需求：FTTi = X + SS其中，根据具体情况，X 可为 FTi（功能时间间隔）、MRT（最大响应时间）或 MSOT（最小安全运行时间）。

对于预防型需求：FTTi = FDTI + FRTi + SS其中，FTI 为功能时间间隔，FDTI 为故障检测时间间隔，MRT 为最大响应时间，MSOT 为最小安全运行时间，FRTi 为故障响应时间间隔。

需注意，功能安全需求（FSR）继承其推导所依据的相应安全目标（SG）的 ASIL。

5.4.3 技术安全需求（TSR）

在确定功能安全需求（FSR）列表后，需实施相应的技术解决方案。为此，需深入到系统层面，详细了解主要组件信息，并绘制二级控制结构以更清晰地呈现组件细节，从而助力制定实现功能安全需求的技术解决方案。技术安全需求（TSR）在子系统或组件级定义。

表 2 列出了针对 UCA1 和 SG1 识别的技术安全需求（TSR）以及相应的因果因素。技术安全需求（TSR）继承相应功能安全需求（FSR）的 ASIL。

根据 ISO 26262 标准，下一步是进行系统架构设计，以实施技术安全需求（TSR）。为使该步骤与 STPA 相整合，需将这些技术安全需求在 STPA 第二步建立的控制结构中实施。

6、安全验证与确认策略

本节将详细阐述正确实施功能安全需求（FSR）和技术安全需求（TSR）的必要性。所提方法的第一步是定义合格标准，合格标准规定了测试场景判定为 “合格” 所需满足的一系列条件，并需为每个技术安全需求（TSR）分配相应的合格标准。合格标准通过对过程模型信念（PMB）及其成因进行否定来制定，并分为人工判定标准和机器读取标准两类。

表 3 列出了为表 2 中提及的每个技术安全需求（TSR）分配的合格标准。

表3、合格标准

6.1 将安全需求映射到测试方法

通过 STPA 识别的不安全场景和安全需求，依据 ISO 26262 标准，确定每个场景的验证目标并选择适当的验证活动。如表 4 所示，列出了测试目标以及与指定 ASIL 等级对应的测试方法。

为测试技术安全需求（TSR）的正确实施情况，需定义测试目标，以分配相应的测试计划。

为说明该方法，以以下技术安全需求（TSR）为例：TSR 1.1.1：任务规划器应采用冗余传感器输入和数据融合技术，验证路径规划信息的准确性。

6.1.1 安全验证目标的定义

· 验证冗余性：验证任务规划器是否能识别多个传感器输入；

· 数据融合：确认数据融合能正确估算位置、速度和路径规划可靠性；

· 路径规划准确性：验证在数据质量不佳的情况下，系统推荐的路径是否安全有效。

6.1.2 测试方法的定义

以下测试集直接源于 ISO 26262 中软件层面识别的技术安全需求（TSR），先将每个技术安全需求映射到具体的测试目标，再映射到特定的验证目标。建议通过以下测试来验证这些目标：

· 基于需求的测试：有助于确认软件逻辑是否按规定实现了技术安全需求（TSR）；

· 故障注入测试：可用于模拟一个或多个传感器数据流中的传感器故障或数据损坏情况，验证任务规划器的数据融合逻辑是否仍能生成正确（或至少安全）的路径规划；

· 接口 / 集成测试：确保多个传感器数据输入（如摄像头、激光雷达、全球定位系统）能正确融合，且系统的接口约定（时序、数据类型、消息完整性）保持一致；

· 性能 / 压力测试：确保任务规划器在处理大量数据和应对意外延迟时，仍能维持可靠的路径规划信息；

· 测试环境与数据收集：在硬件在环（HIL）仿真框架中进行验证，该框架可回放实时摄像头、激光雷达和全球定位系统记录数据，同时注入故障序列（如噪声注入、延迟）。

随后，定义测试目标。在选择测试方法时，以 ASIL 分类作为参考来指导测试执行，具体如表 4 所示。

7、结论

本文为原始设备制造商（OEM）提供了一种全面的方法，助力其有效利用 STPA，确保符合 ISO 26262 和 ISO/PAS 21448（SOTIF）标准，尤其侧重于验证和正确实施推导的安全需求。通过将不安全控制行为（UCA）否定表述以推导安全目标（SG），并基于运行设计域（ODD）中定义的参数评估严重度、可控性和暴露度，从而确定 ASIL 等级。通过制定相应的功能安全需求（FSR）和技术安全需求（TSR），所提方法实现了在整个安全生命周期内对危害的有效缓解和可靠追溯。

本文提出的方法将 STPA 过程与成熟的行业安全流程相结合，使原始设备制造商（OEM）能够采用 STPA 等范式，有效应对由多因素引发的复杂危害。通过以 SAE 4 级自动驾驶系统为案例的研究，验证了该方法的有效性。在未来的工作中，研究团队计划将该方法应用于实际案例研究。