内容提要：此文为该连载系列的“上部分”，我们将结合研究的背景对ISO26262、STPA和FMEA进行概述，从而证明STPA适用于ISO26262概念阶段；此外，我们还将具体介绍提出的新方法是如何形成的，以及是如何根据ISO26262应用STPAFT。

摘要

ISO26262:2018是道路车辆电气和/或电子(E/E)系统的国际功能安全标准。它根据ISO26262概念阶段要求的危害分析和风险评估(HARA)得出的汽车安全完整性等级(ASIL)，为道路车辆提出适当的安全要求，以避免不合理的残余风险。系统理论过程分析(STPA)似乎是专门为处理现代复杂系统的危害分析而设计的，但它不包括大多数与安全相关的国际标准所要求的风险评估。因此我们将STPA集成到失效模式与影响分析（FMEA）模板中，形成一种基于FMEA模板的系统理论过程分析新方法，即STPAFT，不仅可以满足ISO26262概念阶段的所有要求，而且也充分利用了两种方法的优点。通过FMEA对低级组件的关注，STPAFT可以获得更详细的因果因素（CFs），这对于ISO26262概念阶段的安全目标（SGs）和功能安全需求（FSRs）的推导非常有帮助。STPAFT的应用通过燃料油位估计和显示系统(FLEDS)的案例研究进行描述，以展示STPAFT如何支持ISO26262的概念阶段。

“STPA与FMEA相结合的功能安全HARA新方法”专题连载共分为“上、下”两个部分。此文为该连载系列的“上部分”，我们将结合研究的背景对ISO26262、STPA和FMEA进行概述，从而证明STPA适用于ISO26262概念阶段；此外，我们还将具体介绍提出的新方法是如何形成的，以及是如何根据ISO26262应用STPAFT。

1.简介

如今，软件的密集使用和功能需求的增加显著增加了道路车辆系统的复杂性。因此，制定道路车辆电气和/或电子(E/E)系统的安全要求具有挑战性。首先，在早期的概念阶段，工程师不仅需要考虑与安全相关的目标，还需要考虑其他系统级目标，例如性能和信息安全，这决定了利益相关者是否会对新产品感到满意。其次，传统的以组件失效为重点的安全分析方法很难单独用于软件密集型现代复杂系统的安全分析。ISO26262作为道路车辆功能安全的特定领域标准，就是为应对这些挑战而诞生的。它制定了各种程序和流程来确保功能安全，但不限制危害和安全分析方法的类型。系统理论过程分析(STPA)是一种相对较新的针对软件密集型复杂系统的危害分析技术，它将安全视为一个控制问题。在STPA中，事故是由于组件失效控制不当、组件功能失调、外部干扰等引起的。自从ISO26262实施以来，STPA在汽车行业引起了越来越多的关注。

尽管STPA在危害分析方面确实具有传统方法所不具备的优势，但STPA要满足ISO26262危害分析和风险评估（HARA）过程的要求，关键的障碍是STPA不像一些传统的危害分析方法那样直接考虑危害性鉴定。因此，我们提出了一种新的方法STPAFT。通过将STPA融入失效模式和影响分析（FMEA）技术中，STPAFT不仅可以充分发挥两种方法的作用，而且可以满足ISO26262概念阶段的所有要求。在STPAFT中，STPA仍负责危害分析，FMEA负责根据ISO26262进行风险评估。FMEA技术还可以帮助STPA通过关注最低级别的组件更系统地分析因果因素，并且可以在这里生成更多的安全约束 (SC)，这可以为功能安全要求 (FSR) 的推导提供更多指导。事实上，通过STPA和FMEA的整合，STPAFT不仅拥有完整的风险评估过程，而且在原因识别方面也更胜一筹。因此，使用STPAFT而不是一些单一的方法将满足ISO26262概念阶段HARA过程的要求，并处理日益复杂的系统。

我们研究的主要目的是展示ISO26262概念阶段所需的工作产品如何由STPAFT生成。STPAFT生成的安全约束可以为ISO26262安全目标(SG)和FSR的推导提供强有力的支持。此外，随着车辆自动化的快速提高，ISO26262可能有一天需要包括部件失效引起的故障行为以外的危害原因，以跟上技术趋势，STPAF作为一种具有风险评估功能的危害分析方法而约束推导，尤其符合这一发展趋势。

我们的文章组织如下：第2节提供了我们研究的背景。第3节简要概述了ISO26262、STPA和FMEA。此外，分析了STPA和ISO26262概念阶段的基础和关键术语，证明STPA适用于ISO26262概念阶段。第4节介绍了我们提出的方法是如何形成的，以及如何根据ISO26262应用STPAFT。最后，我们在第5节中展示了STPAFT在燃料油位估计和显示系统 (FLEDS) 案例研究中的应用，以展示STPAFT如何支持ISO26262的概念阶段。第6节和第7节分别是我们研究的讨论、结论和未来的工作。

2.背景

本节简要介绍与本文相关的ISO26262概念阶段的一些条款、STPA和FMEA技术。此外，我们对STPA和ISO262626概念阶段的理论基础和关键术语进行了详细的比较分析。

2.1.道路车辆功能安全ISO26262

ISO26262于2011年底发布，是一项国际标准，涉及汽车系统中与安全相关的E/E系统的功能安全。该标准的目的是构建一个框架，通过提供指导、建议和论证，将功能安全活动集成到安全相关E/E系统的开发中。通过对具体的安全开发流程和安全分类提出建议，可以帮助确保每个新产品都是最先进的。

ISO26262由12个部分组成，主要在7个部分（从第3部分到第9部分）中描述安全活动。第3部分对概念阶段的具体内容给出了清晰的解释：

1.相关项定义：这个过程的目的是描述一个相关项的功能、其他相关项之间的接口、驱动程序和环境。此步骤是HARA过程的输入。

2.HARA过程由三个步骤组成：

(1)根据识别出的整车级危害源、相应的运行情况和运行模式确定危害事件。

(2)对于每一个识别出的整车级危害，应用ISO26262的风险评估框架：

•评估运行场景的暴露概率(E)。

•确定可能导致危害的潜在场景。如果发生碰撞，则评估对相关人员造成伤害的严重程度(S)。

•评估车辆的可控性(C)和运行情况。

•根据ISO 26262，确定基于E、S和C的汽车安全完整性等级(ASIL)，如图1所示。

(3)将最坏情况的ASIL分配给危害事件。

3.根据其ASIL为每个已识别的危害事件确定SG。

4.功能安全概念：考虑到系统架构设计，这一步最重要的目标是从SG推导FSR。

图1. 根据严重度(S)、可控性(C)和暴露度(E)确定汽车安全完整性等级(ASIL)：(a)影响因子S的等级；(b)影响因子E的类别；(c)影响因子C的类别；(d)确定ASIL

2.2.系统理论过程分析

STPA是一种基于STAMP框架的危害分析技术，由Leveson于2004年开发。STPA将安全视为一个控制问题，并使用分层安全控制结构来描述系统。当组件之间的不安全交互、外部干扰和/或组件失效没有得到充分控制时，就会发生事故。对安全控制结构的分析可以确定为什么会发生安全相关约束的不充分控制和执行。STPA主要分为三个步骤：

1.首先是建立工程基础，包括事故的判定、导致事故的系统级隐患识别、系统安全控制结构的贡献。

2.使用在上一步中构建的安全控制结构识别导致危害的潜在不安全控制行为(UCA)。

3.通过检查控制结构中的每个部分，确定导致UCA或违反SC的原因。

近年来，STPA已成功应用于多个领域的各种安全关键系统，如用于汽车系统的STPA、用于国防系统的STPA、用于医疗设备（如放射治疗系统）、用于核工业和航空航天相关系统等。

2.3.失效模式及影响分析

FMEA是一种归纳分析方法，用于在早期开发过程中识别系统中所有组件的潜在失效模式及其原因。FMEA通过测量严重性、发生率和检测概率来计算已识别失效模式的影响。分析从最低级别的组件开始，然后继续分析失效对整个系统的影响。最后，将提出对策以减少或最小化已识别失效模式的负面影响。通常的FMEA的步骤如图2所示。

2.4.相关工作

由于STPA在安全分析方面的优势，一些学者将其用于ISO26262的HARA过程中。Hanneet将STPA应用于车道保持辅助系统，以得出安全驱动的设计约束和要求。Abdulkhaleq为基于STPA的全自动驾驶车辆开发了一个可靠的架构。Abdulkhaleq还将STAMP/STPA的结果与同一系统上的安全档案进行了比较。然后，安全工程和软件工程通过基于STPA的软件密集型系统方法结合在一起。Suo提出了一种使用基于系统模型语言(SysML)的元模型来支持将STPA集成到ISO26262中的方法。

Hommes通过评估指出，ISO26262中推荐的危害分析方法不足以应对现代软件密集型系统迅速增加的复杂性，并强调了在ISO26262的概念阶段使用STPA作为危害分析技术的优势。这是我们开发一种基于STPA的新方法的强大动力，该方法可以保持STPA的优势，同时评估风险。

图2. 失效模式与影响分析(FMEA)实施过程的步骤

3.STPA和ISO26262的危害分析基础和关键术语

STPA是我们提出的方法的核心，因此证明STPA适合作为ISO26262概念阶段的危害分析方法非常重要。为此，我们首先分析了ISO26262和STPA的危害分析基础。然后，将ISO26262概念阶段使用的关键术语与STPA进行对比，从另一个角度证明STAP适用于ISO26262。

3.1.ISO26262和STPA中HARA过程的危害分析基础

首先，STPA和ISO26262都是基于将系统视为一个整体的系统工程框架。它们都旨在将安全嵌入到系统工程过程中，并从开发过程的一开始就将安全设计到系统中。另一个共同点是STPA和HARA流程都是自上而下的流程。ISO26262的HARA过程只关注组件失效引起的危害，而STPA中的危害可能来自组件之间的功能失调相互作用、设计缺陷、人为因素和外部干扰，而不仅仅是组件失效。HARA过程中的活动主要分为上述三个部分。这里HARA和STPA流程最重要的区别在于，HARA流程需要根据危害事件的分类和ASIL的判定进行风险评估，而STPA并不打算进行风险预估。我们在表1中列出了STPA和ISO26262的基础。

表1. ISO26262危害分析和风险评估以及系统理论过程分析(STPA)的基础

表1.续

3.2.ISO26262概念阶段和STPA的关键术语

表2列出了STPA和ISO26262 HARA过程的关键术语。从表中我们可以看出两者之间的概念差异。以危害的定义为例，首先，STPA中的危害范围比上述HARA过程中的危害范围要广得多。接下来，STPA中的危害定义包括“系统状态或条件”和“一组特定的最坏情况环境条件”，它们描述了“系统状态或条件”的上下文，而在ISO26262中，危险只是危害的“潜在来源”。ISO26262中“harm”的含义与STPA中“loss”的含义相似，但“harm”仅指“伤害或对人的健康造成损害”，而“loss”除了人的伤亡外，还包括财产损失、环境污染、任务损失等。虽然在STPA中没有定义“运行模式和运行场景”，但根据ISO26262中对这两个概念的描述，我们可以推断这两个概念可以包含在STPA的危害定义中。因此，如果我们将STPA中“事故”中的“损失”范围限制为ISO26262中的“危害”，那么在我们的研究中，STPA中的“事故”可能相当于“危害事件的后果”。至于ISO26262中的安全目标，它们可以等同于STPA中的系统级SC，因为它们在定义上是相似的。

表2.STPA和ISO26262概念阶段的关键术语

表2.续

根据以上分析，STPA与ISO26262的区别主要体现在STPA在危害、事故等诸多关键因素上比ISO26262涵盖的范围更广。如果STPA要用于ISO26262中的危害分析，则STPA有必要适应ISO26262概念阶段的当前要求。在本文中，STPA中的某些关键术语将限制在ISO26262要求的范围内，例如STPA中的“损失”和ISO26262中的“危害”，并且有些术语在本文中可以等效，例如STPA中的“事故”和ISO26262中的“危害事件的后果”。从而通过STPA的分析得到ISO26262概念阶段所需的工作产品。此外，我们将在第5节中解释如何映射STPA和ISO26262的相应关键术语。总之，所有区别都是可以理解的，因为STPA是一种通用的安全分析方法，而ISO26262仅针对道路车辆。所以，如果我们对STPA做一些适当的调整，完全可以满足ISO26262对危害分析的要求。

4.拟议方法

为了生成（或支持）ISO26262概念阶段所需的相关工作产品，我们提出了一种称为STPAFT的改进方法，它将STPA集成到FMEA技术中，以进行危害分析和风险评估。通过FMEA对系统相关组件的关注，FMEA技术也可以支持STPA系统地识别因果因素，并且可以在此处制定更多的SC，这意味着所提出的方法将为FSR的确定提供更多信息。

4.1.将STPA集成到FMEA中

虽然STPA和FMEA是两种不同的方法，但从两种方法的分析过程来看，FMEA首先是在为子系统和组件分配功能后识别失效模式，然后确定失效模式的成因。这个过程类似于STPA建立安全控制模型后，识别不安全控制动作，进而确认原因的过程。因此，为了充分利用FMEA模板进行原因分析和风险评估，本文将STPA的一些概念与FMEA相对应。这并不是说它们的本质是一样的，而是为了让STPA能够在分析过程中充分利用FMEA模板。图3说明了STPA和FMEA关键概念之间的对应关系。

图3.STPA和FMEA关键概念之间的对应关系

在整合两种方法之前，我们先完成STPA的Step 1和Step 2，即确定事故，识别系统级危害和不安全的UCA。在这里，如图3所示，STPA中的控制动作可以等同于FMEA中的功能，而UCA可以等同于我们文章中的失效模式。结合STPA的Step 3和FMEA的Step 3来确定UCAs（失效模式）的成因（causes），FMEA的Step 4可以根据ISO26262进行风险评估。我们提出的方法的一般步骤如图4所示，下面详细介绍STPAF的具体步骤。

图4.所提出方法的一般步骤，左侧是STPAFT的实施步骤，右侧是ISO26262概念阶段所需的 STPAFT输出

4.2.Step 1:系统工程基础建立和UCA识别

STPAFT从系统工程基础的建立开始，类似于STPA的第一步，包括系统级的事故和危害识别、相应的SCs确定和安全控制结构的建立。

4.2.1.系统工程基础建设

如第3节所述，可以通过将STPA中的事故与运行模式和运行场景相结合来确定ISO26262中危害事件的后果。STPA的“危害”可以映射到ISO26262的“危害事件”。为了区分STPA的“危害”和ISO26262的“危害”，这里用“系统级危害”来表示STPA的“危害”，在本文的其余部分用“车辆级危害”表示ISO26262中的“危害”。

STPA的第一步包括：

•在STPA中定义系统事故的“损失”，并限制在ISO26262定义的危害范围内进行分析。

•从已识别的系统级危害的描述中识别导致事故的系统级危害，以及相应的运行模式和运行场景。

•确定可用于支持ISO26262的SG确定子条款的相应车辆级SC，因为SG也是高级要求。然而，ISO26262中的SG比STPA中同级别的SC更具体。

•绘制系统的安全控制结构，以识别导致系统级危害的潜在UCA。控制结构图显示了被分析系统的边界及其接口，它包含的信息可以用来定义一个相关项。

4.2.2.UCA识别

•通过检查安全控制结构，根据四类（未提供控制措施、提供错误的控制措施、在错误的时间/顺序提供的控制措施以及过早停止/施加过长的控制措施），识别导致上一步中识别的系统级危害的UCA。UCA的信息可能有助于确定每个危害事件的运行模式、运行场景和可控性。

•可以通过在UCA的描述中添加“应该”或“必须”等前导词来确定相应的SC。

4.3.Step 2:危害事件分类和SGs确定

在此步骤中，FMEA技术被集成用于风险评估。

•识别出的每个危害都可以用两个因素（S和E）进行分类。每个危害事件的可控性，以评估场景是否可控，可以由已识别的运行场景和UCA来确定。

•将上面确定的系统级危害的SC转换为与其ASIL相对应的每个危害事件的SG。

4.4.Step 3:确定因果因素和创建FSR

•在FMEA技术和STPA提供的指导词的帮助下，可能的因果因素的识别在组件级别变得更加详细。为了更好地使用FMEA，应该创建一个包含更多被分析系统细节的功能结构。

•为确定的因果因素生成相应的SC。由于UCA和因果因素的SC都用于描述如何避免或减轻危害，因此可以将它们映射到ISO26262的FSR。

•根据ISO26262第3部分中7.4子条款的要求，将SC转化为相应的FSR。

更多内容，请关注“STPA与FMEA结合的功能安全HARA新方法（下）：工程应用实例分析”，关注牛喀网，学习更多汽车科技。有兴趣的朋友，可以添加牛小喀微信：NewCarRen，加入专家社群参与讨论。

详询“牛小喀”微信：NewCarRen

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