*本文翻译自Juan R. Pimental所著Safety of the Intended Functionality (SOTIF) Book 3 - Automated Vehicle Safety Series，中文版权归轩辕实验室所有

随着汽车电气/电子系统的软件集成化程度越来越高，汽车系统的开发需求具有挑战性。设计必须考虑到软件特性之间意外的相互作用，以及不可预见的环境因素。此外，工程师必须迭代地进行架构交易，并将责任分配给系统中的每个组件，以适应新出现的安全需求。ISO 26262是汽车电气/电子系统功能安全的行业标准。它规定了确保功能安全的各种过程和程序，但不限制用于危害和安全分析的方法。系统理论过程分析(STPA)是一种危害分析的新技术，它是由部件(包括人)之间不安全的相互作用以及部件故障引起的危害。STPA除了功能安全性之外，还包括系统故障的安全性分析以及预期功能(SOTIF)的安全性。

本文介绍了一个基于系统模型语言(SysML)的完整元模型流程图，以支持将STPA集成到基于ISO 26262的功能安全流程中。特别地，本文阐述了STPA如何通过ISO26262推荐危害分析和风险评估(HARA)中的ASIL分类来帮助评估安全性和其他系统级目标。该元模型还可以用于提供关于制定体系结构决策的指导，以创建功能性安全需求。为了使流程图适用于OEM采用的不同功能安全过程，需要工具的支持。本文给出了基于元模型的可视化工具开发指南。

1 简介

开发汽车电气/电子系统的需求具有挑战性：首先，工程师不仅要在概念阶段的早期处理与安全相关的目标，还要处理其他系统级的目标，如性能和安全性，这决定了涉众对新产品的满意度。通常，架构交易必须在创建详细的需求之前进行。其次，处理硬件故障的传统危险分析技术在复杂的软件密集型系统中很难使用。即使系统按设计运行，软件特性之间无意的交互也会导致一些有名无实的场景。第三，对系统工程活动的建模和工具支持常常因部门而异，这使得系统集成变得困难，因为模型和需求工件在不同的过程中有所不同。

为了应对这些挑战，国际标准化组织(ISO)将通用功能安全标准IEC 61508扩展为汽车行业的功能安全领域专用标准ISO 26262。它规定了确保功能安全的各种过程和程序，但不限制用于危害和安全分析的方法。特别是，其概念阶段规定了确定危害和因果因素的过程，以支持安全要求的发展。STPA是危害分析的一种新技术，因为危害是由组件(包括人)之间的不安全交互以及组件故障和故障引起的。以前在汽车领域使用STPA的工作包括应用STPA识别ISO 26262兼容框架中的危险，以及相应的建模和工具支持。

Hommes建议在ISO 26262的概念阶段使用STPA和其他危害分析技术，以识别危害的全面列表并制定功能性安全要求。Mallya等人展示了STPA如何在ISO 26262兼容过程中使用，其中基于STPA的危害分析扩展到包括风险评估。Tomas等人提出了一种集成的方法，在这种方法中，危害分析和需求生成可以在并行和迭代的过程中进行。虽然没有专门针对ISO 26262，但这种方法为工程师在早期概念开发期间做出关键设计决策提供了指导和反馈。

针对基于STPA的危害分析和需求生成的建模和工具支持，开发了软件原型和工具。说明了一个概念证明工具，支持形式化的STPA步骤1和自动需求生成。Abdulkhaleq开发了一个开源平台，允许工程师执行STPA来进行需求开发和测试用例生成。安全风险分析工具(SafetyHAT)是由美国国家运输系统中心Volpe开发的，用于支持STPA和针对不同运输系统的应用定制。尽管这些努力促进了STPA在汽车行业的使用，但据作者所知，建模和工具支持在以下三个方面仍然缺乏:

•在概念开发的早期，增强STPA考虑安全性以及其他系统级属性，如客户的经验或网络安全威胁。

•通过自动检测安全约束之间的一致性来验证功能安全需求。

•为定义初步架构向系统组件分配职责提供指导。

本文介绍了一种将STPA集成到ISO 26262规定的功能安全流程的流程图。特别是，它说明了如何在符合ISO 26262的过程中将STPA用作危害分析（HA）活动，以建立安全和其他系统级目标，并将这些目标与基于当前风险评估（RA）方法的ASIL分类相结合 完成ISO 26262第3部分的HARA目标。这里描述的流程图还提供了架构决策的指导，以适应功能性安全需求。为了使流程图适用于原始设备制造商采用的不同功能安全流程，系统模型语言(SysML)的STPA扩展已被修改，以方便使用带有建模和支持工具的STPA。并通过一个自动化驾驶系统的案例研究，说明了如何使用建议的流程图。图1概述了ISO 26262中与危害分析技术相关的集成工作。所有工作都基于ISO 26262-汽车电气/电子系统的功能安全标准。

2STPA集成的流程图

2.1 ISO 26262

ISO 26262是电气和电子系统产品的功能安全标准，是针对汽车行业的IEC 61508功能安全标准的修订。“规定了安全工程的系统工程流程”。

在ISO 26262的概念阶段中，有三条与功能性安全要求的发展相关的条款被考虑用于集成STPA。虽然自2011年发布初步标准以来已经进行了修订，对ISO 26262的审查和评估仍然有效。由于涉及组件的设计细节，因此省略了制定技术安全要求的过程。

•项目定义：在车辆层面实现功能的系统或子系统。

•危害分析和风险评估(HARA)：HARA用于识别危害和安全目标所捕获风险的适当降低。工程师们首先要头脑风暴可能发生的危险事件，确定在各种环境条件下，某一特定物品的故障行为是否会造成危险。评估相关危险事件的严重程度、暴露程度(E)和可控性(C)。然后根据{S, E, C}到ASIL的固定表映射，将汽车安全完整性等级(ASIL)分类(a - d)分配给每个安全目标。对于每一个a - d级别的危险事件，都要制定一个安全目标(SG)。

•功能性安全概念：这一步的目的是在概念层面创建功能性安全要求，以实现HARA制定的安全目标。

虽然ISO 26262标准为识别危险事件提供了结构化的程序，但它对具体的危险分类和减轻提供了有限的指导。

图1 集成工作的概述

2.2 STPA

STPA是针对复杂系统的一种新的危害分析技术，它的危害是由组件(包括人)之间的不安全交互以及组件故障和故障引起的。STPA基于STAMP——一个基于系统和控制理论的突发事件因果关系模型。安全约束、层次化控制结构和过程模型是STAMP的三个基本概念。事故的发生是因为控制结构没有执行安全约束。每个“控制器”，无论是人还是计算机，都有一个过程或心理模型来决定是否向被控制的过程发出控制命令。

STPA中有两个步骤，如图2所示。作为步骤1的扩展，不希望的控制结果(UCA)被标识并分为四类:

•未提供或未遵循所需的控制操作。

•提供了一个不需要的控制动作。

•控制动作提供得太早或太晚。

•控制动作停止得太快或应用得太晚。

确定了UCAs之后，步骤2确定可能导致UCAs的因果因素和场景。这些都是基于STAMP中描述的事故因果关系模型。

值得一提的是，STPA可以从安全性扩展到其他高级系统目标，如安全性或性能。

图2 系统理论过程分析的程序

2.3 创建功能性安全需求的流程图

本文提出了一种将STPA与ISO 26262中的功能安全流程相结合的流程图，如图3所示。图中显示了系统建模语言(SysML)描述的元模型(中间)如何促进ISO 26262中的封闭环境下的STPA(右)的使用，以开发功能安全需求和做出体系结构决策。

元模型(顶部中心)的第一个部分将输入危险信息以及其他系统级属性(如客户体验)作为输入，这些属性用于识别STPA步骤1中不需要的控制操作，如图3中的红色箭头(向下)所示。此外，如果在STPA步骤2中发现的因果因素中存在网络漏洞，新的安全威胁可以作为系统级属性派生出来，如图3中向上(红色)箭头所示。该元模型还可以根据ISO 26262中的项目定义中的系统组件和假设，为将控制结构作为系统工程基础提供帮助。元模型的第二个作用是STPA对HARA的补充。通过对基于元模型的STPA Step-1的工具支持，工程师可以通过风险评估创建和验证与ASIL安全目标相关的安全约束。元模型的第三个用途是为创建驱动体系结构决策的功能性安全需求提供指导，如图3的底部中心所示。

图3 STPA与ISO 26262流程集成的流程图

3 建模和工具支持

SysML入门

OMG系统建模语言(SysML)是一种图形化建模语言，它为复杂系统的开发提供支持，包括指定、分析、设计和验证。它包括三种类型的图，每一种都代表了系统的一个特定方面，包括行为图、需求图和结构图。块是在结构图中从结构上描述环境中的硬件、软件、设施、人员和外部实体的基本单元。对于这个项目，SysML被用作基本语言，它被扩展来捕获STPA的控制结构。最高级别的SysML需求图将安全目标与基于STPA的分析得出的安全需求和其它非安全需求联系起来。

3 风险分析的元模型和需求生成

如图1和图3所示，建模支持(来自开源或商业工具)对于使流程映射可扩展到复杂的汽车系统并可供不同的工程团队使用是必要的。本文描述了一个基于支持系统建模语言的建模环境的元模型，这样STPA中导出的安全约束和需求可以映射到ISO 26262支持功能性安全过程的元素中，如图4、图5和图6所示。

图4 用于建立基于ISO 26262项定义的控制结构的元模型

图4说明了如何通过定义系统组件和链接的元模型(左)来构建控制结构(右)。除了STPA中的组件外，还将新元素添加到模型中以进行可视化。例如，“控制动作”块通过“命令”链接传播，一个关联链接将它们连接起来。

图5 支持STPA步骤1和步骤2的元模型

图5(左)给出的元模型可以将基于STPA的危害分析与ISO 26262中的过程耦合起来。上半部分展示了如何构建可视化工具(表格形式)，以便将STPA步骤1结果中的UCAs和安全约束与HARA开发的安全目标和ASIL评级联系起来。工程师可以利用UCAs和情景之间的可追溯性和因果因素来创建相关的功能性安全约束，如下图所示。

图6 验证安全约束的元模型

除了对STPA与ISO 26262集成的建模支持之外，本文还提出了一个元模型，用于验证功能安全流程中创建的安全需求和约束，如图6所示。这个元模型建立在两个理论基础上:

•过程模型。STPA中的控制结构可以有多个控制器(例如，自动化或人工控制器)，每个控制器都有一个被控制的流程模型和外部环境，如图2所示。流程模型可能包含表示系统状态或上下文的不同变量。例如，自动驾驶系统可以处于活动模式，在操作边界内和正确的路线上。是否需要提供运动规划命令取决于此上下文。

•危险控制措施的正式规范。Tomas提出了一种形式化的方法来部分自动化识别UCAs、识别冲突和生成需求的过程。具体来说，一个危险控制动作由四个要素组成，包括源控制器、类型、控制动作和上下文。有了这四个要素，工程师们可以制定一个“规则”，即包含特定上下文的形式化的UCA。该规则的形式接近于自然语言，但机器可读，用于进行组合搜索以确定相互冲突的约束。

使用基于图6中提出的元模型的用户界面，工程师可以为UCAs指定一个“规则”。“规则”是指定UCA上下文的形式化方式。作者开发的插件中内置的Java算法可以将这些“规则”作为输入，自动检测冲突。如图6中表格的最后一列所示，“规则3”与“规则8”冲突，表明了UCAs与相应的安全约束之间的一致性。本文后面将提供一个具体的例子。

4 基于项目设计的系统工程基础

为了在ISO 26262中为系统工程过程建立基础，工程师从项目定义中获取输入，用本文描述的建模和工具支持来构建安全控制结构。这些输入包括系统级危害、系统组件和系统假设。

作为一个例子，本案例研究选择了三个高级别的危害。G-1是一个系统级的目标，与客户对运输系统的满意度或效率有关，它也被包括在本文中，以说明处理不同系统级属性的建模支持。

H-1:太接近物体/地形

H-2:车辆离开预定路径

H-3:骑手的进入/出口问题

•G-1:自动驾驶系统的运行不应影响乘客的体验和交通。

另外，对自动车辆做了五个假设：

•乘客可以通过云基础设施申请乘车服务。

•自动化驾驶系统和道路基础设施支持V2V或V2I通信通过车辆网络(例如，专用短程通信- DSRC)。

•自动驾驶系统只可在指定的操作范围内运作(例如:时间、地理范围、天气情况等)。

•自动驾驶系统启动后，可适当处理所有驾驶任务。

•人类驾驶员或乘客能够中断自动驾驶系统的运行。

构建系统工程基础的建模支持如图7所示。代表系统组件的基于SysML的方框图(左)可用于派生自动车辆的控制结构(右)。这构成了下一节分析的示例的基础。

图7 从项目定义推导出的自动车辆的安全控制结构

5 整合STPA步骤1以评估现有的安全目标

在STPA 步骤1中，工程师识别不希望的控制动作，为系统创建初始(安全)约束。这些约束随后与HARA现有的安全目标相关联。如果任何安全约束与现有的安全目标无关，则HARA可以进行修订，从而产生新的安全目标。

从HARA发展出来的几个抽象的安全目标如下。

•SG-1:防止车辆偏离预定路径。

•SG-2:防止车辆违反与其他车辆固定的隔离距离。

•SG-3:防止人类进入/出口问题。

两个控制动作——加速和运动规划被选为案例研究。考虑下面的uca9。如果不提供“运动计划”会导致上述定义的任何危害，则应创建安全约束。

•UCA 9:如果自动驾驶系统处于主动模式，车辆在行驶路线内，且在运行边界内，则不需要提供运动规划[H-1, H-2]。

•安全约束9：自动驾驶系统应提供运动规划，如果是在主动模式下，车辆在路线和操作范围内。

表1显示了从HARA获得ASIL评级的安全目标如何分配到每个UCA及其相应的安全约束。第一列包含一组用于加速和运动规划命令的UCAs，而第三列显示为每个UCA派生的安全约束。对于给定的行，如果任何安全约束都与现有的安全目标无关，则可以修改HARA，从而产生新的安全目标。

作为如何扩展STPA以处理非安全目标的一个例子， 考虑这样一种情况，当自动驾驶车辆在高速公路上合并到一个快速(左)车道时，自动驾驶系统没有提供加速命令(表1中的第6行)，而且它当前的速度太低，无法顺利地合并到交通流中。

表1 为安全约束分配ASIL安全目标

我们不期望这种情况发生(虽然不一定是不安全的)，因为车辆可能需要刹车，不能保持乘客期望的速度，从而违反了G-1。表1(最后一行)给出了新派生的不提供加速命令的UCA-ADS，这在车辆合并到高速公路上的快车道时并不需要。

在确定UCAs并创建相应的安全约束之后，有必要验证步骤1的结果，以确保安全约束或要求之间不存在一致性。为了帮助工程师完善这个任务，作者开发了一个基于图6中的元模型的原型用户界面。表2给出了一个来自UCAs的两个安全约束之间存在冲突的例子。3可以看到,“规则3”与“规则8”矛盾 , 规则3要求当自动驾驶车辆在高速公路上向左车道行驶且驾驶员在场时，自动驾驶车辆必须提供运动规划, 而规则8要求自动驾驶车辆不提供在极端天气条件下车辆在高速公路上行驶的运动规划。

表2 自动检测需求以验证安全约束

4 集成STPA步骤2以创建功能安全需求

在建立安全约束来验证运动规划和加速指令的安全目标之后，工程师可以执行STPA步骤2来为每个安全目标创建功能性安全要求。

•为自动化车辆的初步架构分配系统组件的职责。

元模型为执行这些任务提供了必要的可跟踪性。考虑UCA 9——如果自动驾驶系统处于主动模式，而车辆在行驶中且在运行边界内，则不提供运动规划是不可取的。与此UCA相关的因果情景和因素包括:

场景9:自动车辆在高速公路上行驶，由于新检测到的事件或障碍，需要更换车道。但是由于自动驾驶系统没有及时提供运动规划，所以它不会改变车道。自动控制器认为车辆没有在正确的路线上或在操作范围内。

•因果因素9.1：任务细节不完整。

•因果因素9.2：意外模式从自动驾驶模式转变为手动模式。

•因果因素9.3：自动驾驶系统认为自动车辆没有在路上行驶，因为地图数据被未经授权的访问修改了。

•因果因素9.4：自动驾驶系统认为自动车辆不在操作范围内，因为地图数据(如路线方向)或时间信息(如时钟)被未经授权的访问修改了。

虽然前两个原因被认为是安全问题，但第三和第四个原因与前面描述的给定架构中的网络漏洞有关。这可以通过一个涉及“可逆车道”的例子来理解，该车道的设计允许车辆根据特定条件向任意方向移动。它的设计是为了避免交通高峰期的交通堵塞，如图8所示。可以看出，中间的黄色通道是“可逆的”，它的交通方向取决于一天的时间。交通在早上由东向西(左)移动，而在晚上向相反方向(右)移动。目前，车道方向是通过控制信号、LED标志或物理分隔来指示的。未来，当自动车辆支持V2I通信时，如果自动驾驶系统通过车辆网络(如DSRC)接收道路单元的路线信息，就可以实现这种设计。

图8 一个由网络漏洞引起的UCA-9的例子

一个问题是V2I通信容易受到网络攻击。对于只允许自主车辆在“操作设计域”内移动的车辆架构(例如，时间、地理条件等)，能够修改与高速公路方向相关的地图数据或欺骗时间信息(例如，车辆时钟)的对手很容易危害车辆的正常运行。假设车辆在可逆车道上从东向西行驶，但是自动驾驶系统接收到的时间信息表明它是在晚上。根据交通规则，在这种情况下，自动驾驶系统发现自己“超出了操作设计边界”，因为它只能在早上在可逆车道上从东向西行驶。更糟的是,如果移动车辆的自动驾驶系统没有设计到一个“安全”的地方当车辆不是途中或运营边界,它不会停止提供运动规划和控制命令,将自动车辆在危险的情况下(没有人控制车辆)。

基于上述场景和因果因素，可以创建功能性安全需求来防御车辆的架构。图9说明了如何通过考虑最坏的情况来创建FSR 9.1。根据系统假设，自动车辆只能在运行边界内运行，在此情景下，由于原因9.3,ADS将停止提供动作规划指令。然后，工程师可能决定将保持车辆移动直到进入“安全”区域的责任分配给ADS，架构决策1就是一个例子。

图9 创建FSRs和做出架构决策的可跟踪性

除了推导功能安全要求，STPA步骤2中确定的场景和因果因素也提供了识别网络安全威胁的指导。例如，一个网络安全威胁(图9)与情景9和因果因素9.3和9.4有关

•行为1:来自外部传感器或车辆网络的欺骗或恶意误报

尽管行为1被认为是一个安全问题，但它也有安全方面的含义，因为对地图数据或车辆网络的欺骗攻击也可能导致车辆违反最小间隔距离(H-1)或没有按照自动驾驶系统最初计划的路径(H-2)行驶。工程师可以创建FSR 9.2来指定任务/请求接收方所需的行为——任务/请求接收方必须与云/车辆进行检查，以确保在车辆处于运行模式时任务细节和地图的数据完整性。图9只说明了如何使用STPA步骤2的结果来派生功能安全需求和责任分配，而不是指定执行此任务的用户界面。

作为工程师在做架构决策时的指导方针，在为自动驾驶系统创建功能安全需求后，考虑几个指导问题。

•鉴于系统假设自动驾驶系统应该只运行在其运营边界(如时间、地理和线路条件、天气条件,等等),哪个模块自动车辆时应保证车辆的安全还在动但禁用自动驾驶系统,因为它是不操作的边界?

•如果自动驾驶系统负责将车辆移到一个“安全”的地方，即使它已经超出了操作边界，那么需要哪些测试用例来确保系统没有危险行为?

•当自动驾驶系统由于意外事件而不在操作范围内时，如果需要另一个控制器来操作车辆，应制定哪些安全要求，以使新控制器发出的控制命令与旧控制器发出的控制命令不一致?

6 网络安全分析集成的考虑

ISO 26262中的安全保障没有考虑汽车系统网络安全指南(SAE J3061)关注的网络安全问题。提供网络安全指南的目标之一是“评估威胁分析和风险评估(TARA)方法，使用一种简单的方法来实现汽车行业的有效实施。STPA可以补充威胁分析，因为它可以查找丢失的威胁或评估现有的威胁，而不是替代TARA。

图10说明了如何从STPA第2步的结果中得到Treat-1。自动化驾驶系统的案例研究始于必须预防的高级别危险和损失(即自动驾驶系统的两个功能——运动规划和加速，而不是明确考虑对自动驾驶车辆的潜在威胁或恶意攻击。在完成步骤1和步骤2之后，将所有的因果情景和因素识别为UCAs，工程师不仅能够创建功能安全需求，还能够创建系统组件的安全需求(例如，自动驾驶系统和任务/请求接收器)。此外，对于自动驾驶系统使用的信息，例如地图数据中的路线方向或时间信息，工程师可以根据哪个功能(例如，运动规划)正在使用它，以及该功能的安全目标的ASIL评级来决定其临界性。

图10 功能安全、STPA、网络安全关系图

7 总结

本文介绍了一种基于ISO 26262的STPA功能安全流程集成流程图。具体地，通过一个汽车系统的实例研究，说明了流程图中的三个步骤。

•系统假设和来自项目定义的组件用于形成STPA的系统工程基础。

•在STPA步骤1中创建的UCAs标识和安全约束用于评估现有的安全目标，ASIL评级来自HARA。

•STPA步骤2中确定的UCAs的因果情景和因素帮助工程师创建功能性安全需求并做出架构决策。

在建模和工具支持方面，开发了基于SysML的元模型。除了支持STPA与ISO 26262流程的集成之外，本文还展示了如何使用元模型来处理概念阶段早期的系统级属性，即安全性之外的属性。，识别STPA步骤1中与客户体验相关的不希望的控制行动，并根据STPA步骤2中的场景和因果因素推导出新的网络安全威胁。值得一提的是，STPA是一个迭代过程，还可以用于创建技术安全需求和生成测试用例。但这些方面没有涵盖，因为这篇论文的重点是功能安全要求。