内容提要：本文提供了在SOTIF背景下使用STPA（系统理论过程分析）实现客车高速公路自动驾驶功能的简化示例。

1.简介

本文提供了在SOTIF背景下使用STPA（系统理论过程分析）实现客车高速公路自动驾驶功能的简化示例。

STPA是ISO 21448中推荐的方法之一。它与其他安全分析技术互补，并由于其系统性而增加了独特的优势，特别是覆盖了由交互问题而不是局部失效或缺陷引起的危害。STPA可用作支持ISO 21448第6条（由预期功能引起的危害的识别和评估，ISO 21448）和第7条（识别系统缺陷和限制，以揭示相应的触发条件）活动的手段，并可为ISO 21448第8条活动（减少SOTIF相关风险的功能修改）提供输入。

STPA是一种安全分析方法，旨在评估复杂系统的安全性并识别安全约束。它已应用于包括汽车在内的各个行业，并已公布了ADAS和自动驾驶功能的应用实例。STPA的核心思想是将危害解释为控制回路中“不安全控制行为”的结果，这种行为可能由多种影响引起，包括但不限于局部失效：非局部失效的危害原因示例包括对环境或其他部件状态的错误感知，外部环境中发生的现象的不准确的底层模型、子系统之间不成功的交互序列（例如时间和竞争条件）、特征干扰等等。特别是，该方法也明确解决了与人类的互动问题，与FMEA或类似技术相比，该方法不限于社会技术系统的技术部分。这意味着STPA可以考虑对功能的误解、技术系统的误导性警告和信号、人为错误甚至故意滥用，ISO 21448认为STPA是ADAS和部分自动驾驶系统的重要内容。

2.STPA方法概述以及ADAS/AV领域的解释

本文基本上遵循STPA流程，但也考虑了汽车应用。我们在这里仅限于ISO 21448和ISO 26262中的安全定义，因此只考虑对人类有害的损失。关于术语，我们坚持STPA术语，但将原始词汇部分改编为汽车领域，或建议使用ISO 21448或ISO 26262中的相应术语。

为了在ISO 21448（或ISO 26262）流程中使用STPA，我们可以假设STPA的一些准备步骤（特别是定义项目和识别顶级危害）可能已经根据适用标准的约束要求执行，并且系统的后续改进也可以在STPA报告之外的安全概念中获取。因此，我们在此示例中采用以下经过调整的STPA工作流程：

- [准备]分析目的和分析项目的定义

- [准备]事故/损失和危害以及车辆安全约束的确定

- [STPA步骤0] 控制结构建模

- [STPA第1步] 识别不安全控制行为

- [STPA第2步] 识别导致不安全控制行动的因果场景

- [后续行动] 根据STPA的调查结果改进系统

建议的工作流程如图1所示：

图1：自动驾驶汽车SOTIF的STPA工作流程

在以下部分中，将按此顺序解释并示例性执行STPA工作流程。

3.定义分析目的和分析项目

定义分析和其他准备工作的目的首先包括（安全）流程规划，在本例中定义STPA如何集成到整体开发和ISO 21448流程中，其次是定义要进行分析的系统或功能。

关于流程规划和目的定义，重要的是要了解STPA是一种整体方法。与FMEA或故障树分析不同，STPA不仅仅是一种分析技术。相反，它还解决了危害识别、系统建模以及在执行分析的核心步骤后对系统的后续改进。根据ISO 26262和ISO 21448建立的汽车流程，通常会将其中一些活动分配给不同的流程阶段。在定义安全流程时，安全经理必须决定是否将STPA步骤分散到不同的流程阶段，或者仅使用STPA的一些核心步骤作为孤立的分析技术，专门用于分析危害原因、发现系统弱点和环境触发条件。即使危害识别或控制结构建模被分配给其他过程阶段，它们仍然可以从SPTA手册中描述的方法中受益。此外，STPA不仅限于失效，而是解决系统弱点、不合适环境中的系统使用、与人类的误解等。因此，STPA可以被视为跨越功能安全、SOTIF和使用安全的活动。当对所有这些方面使用通用STPA时，STPA必须符合不同标准的要求，特别是ISO 26262和ISO 21448。

用于举例说明该方法的高速公路驾驶系统是SAE 3级系统，即它可以在有限环境中较长时间地控制整个车辆的动态，而无需人类驾驶员的直接监督；然而，人类驾驶员必须在场并能够在通常几秒到不超过一分钟的规定时间范围内收回控制权。该功能旨在部署到客车上，并且在每个方向至少有两条车道、行驶方向分离的高速公路上使用，而且没有十字路口、优先通行场景或交通信号灯。它将纵向控制（自适应巡航控制/ACC，通过自动紧急制动/AEB增强）与横向控制（车道居中或车道保持控制/LKC）相结合。在其最基本的配置中，它并不用于执行变道或超车操作。在特殊情况下，例如道路施工、事故或收费站时，它可能必须将控制权交还给驾驶员，但有责任安全地这样做。请注意，这不是一个实际的系统，而是一个抽象和简化的人工示例，其灵感来自于多个制造商的类似系统。

可以预期，在开始STPA之前，已经执行了符合ISO 26262-3第5条的相关项定义和/或符合ISO 21448第5条规定的功能和系统规范；在那里发现的信息可以被使用，并且应当被修改以用于STPA中。本分章末尾给出了用于HP功能的功能架构，以提供对预期系统结构和功能的更详细理解。

4.事故/损失和危害的确定

STPA准备工作的下一步是确定损失（对人类的伤害）、事故以及相应的危害。对于确定和分类危害时应遵循的要求，可参考ISO 26262-3第6条(HARA)和ISO 21448第6.3条（危害识别）。这些标准和最初的STPA方法之间的推荐程序略有不同，但危害的概念基本上是一致的。可以考虑STPA识别危害的做法，以按照标准的要求改进HARA/危害识别。请注意，在汽车实践中，损失和危害的识别通常是紧密联系在一起进行的，而STPA文献将它们作为两个连续的步骤提到，从损失开始。需要指出的是，ISO 26262仅考虑由E/E系统失效引起的危害，而ISO 21448和STPA方法则包括由非失效的限制、缺陷和不利条件引起的危害，意外环境以及人类和技术系统之间的误解。STPA一般考虑事故和损失，而ISO 26262和ISO 21448侧重于对人类的伤害，但这仅仅意味着如果仅执行安全标准，可以忽略货物、金融资产、声誉或环境破坏方面的损失。

表1通过根据ISO 21448第6条的HARA/危害识别的简化摘录举例说明了该过程，该摘录已适用于STPA环境中的使用。省略了与STPA无关的信息（如严重性和可控性评级）。对列标题进行了调整，以将STPA和ISO 21448第5条这两种方法统一起来。STPA所需的主要列被突出显示，但也显示了另外两列，这些列通常用于ISO 21448危害识别过程。原始的HARA表将显示更多的详细信息，并且在大多数情况下，具有更多的列和数百行，甚至数千行。请注意，与ISO 26262 HARA不同，此表不必从故障行为开始分析。

表1：损失和危害识别示例

准备阶段的最后一步是推导系统级安全约束，这在某种程度上类似于ISO 26262中安全目标（顶级安全要求）的推导。根据STPA手册（参考资料1，关注牛喀网公众号，后台咨询下载），系统级约束规定了需要满足的系统条件或行为，以防止危害（从而防止事故），或确保在危害发生时检测到危害并迅速采取应对措施以防止事故。它必须与它应该预防的危害有关（见表2高速公路试点的简单示例）。

表2：危害和相应的车辆级安全约束

5.控制结构建模

如果在早期流程阶段应用STPA，则控制结构模型将处于抽象级别，基于通用控制循环模型和相关项定义中的现有信息。这可能需要稍后进行细化，或者在架构的细化级别上重复STPA步骤。如果STPA应用在项目的更高级阶段，通常可以获得详细信息，但挑战是找到正确的抽象级别，并且不要失去STPA思想的焦点。与FMEA不同，STPA的目标不是对系统进行接近实施级别的描述，因为这最终会导致寻找各个部件的失效，而不是理解系统的动作链。

在此示例中，我们使用高速公路自动驾驶功能的顶层控制结构来启动STPA，如图2所示（采用SysML兼容符号）。它显示了涉及人类驾驶员的主要控制回路（即使他打算在自动驾驶模式下“脱离回路”）和系统的环境或上下文（道路上的场景，包括其他交通参与者）。它将传感器和执行器表示为抽象结构，只要它们理解控制和反馈等交互，但也允许直接通道（例如，如果人类驾驶员想要，他可以立即感知到他的车辆是如何移动的，以及外部世界发生了什么）。“Highway Pilot”是核心功能，STPA围绕其执行。反馈信号用虚线绘制，以便将它们与控制动作区分开。对此类功能的控制循环模型的下一个细化级别示例感兴趣的读者可以下载（参考资料2，关注牛喀网公众号，后台咨询下载）中的图5。本小节末尾的功能架构可以提供下一级细化所需的更多细节。一般来说，对于具有相当复杂性的系统，模型不会局限于简单的控制回路，而是跨越控制层次结构。层次结构有助于确定哪个元素是最终控制实体，以及哪些系统元素将下游命令传递给较低级别的元素。以这种方式，可以识别并解决“竞争”控制元件之间的冲突，以便每个系统元件知道要优先考虑或验证哪个输入。

控制结构建模不应局限于图形或半形式模型（例如SysML），还应提供图例或其他信息源来解释每个模块及其职责。控制结构建模过程中的下一步是识别控制动作。在此示例中，假定以下语义（不排除其他解释）：静态体系结构中的接口，根据动态体系结构定义了可能的控制动作的库。

例子：

- 从驱动器到HP功能的连接允许以下控制动作：{打开HP、关闭HP、增加设定速度、减少设定速度、增加默认距离、减少默认距离}

- 从执行器到车辆动力学的连接允许以下连续控制信号：{转向角、加速方向的轴扭矩、减速方向的轴扭矩}

图2：高速公路自动驾驶的顶层控制回路图

高速公路自动驾驶系统示例的控制操作（非详尽）列表可在表3中找到。

表3：高速公路自动驾驶控制行动列表

6.不安全控制行为的识别

STPA程序的下一步是确定不安全控制措施(UCA)，其在（参考资料1，关注牛喀网公众号，后台咨询下载）中定义为“在特定情况和最坏情况环境下将导致危害的措施”。STPA手册中推荐的做法是采用表格技术，将每个控制操作暴露给4个预定义类别（或引导词，借用HAZOP方法中的一个术语），以表示与指定或预期行为的偏差：

1.不采取控制措施会导致危害。

2.提供控制动作会导致危害。

3.提供潜在安全的控制措施，但太早、太晚或顺序错误。

4.控制动作持续时间过长或停止过快（仅适用于连续控制动作）。

请注意，控制动作仅适用于控制结构中的“向下”路径（执行器路径），并且在STPA的此阶段尚未调查不当行为的原因（例如来自传感器的不准确反馈）。不安全控制行为列表见表4。

表4：不安全控制措施调查

请注意，每项不安全控制操作必须潜在地导致至少一种危害（否则它不会不安全），但也可能导致多种危害。另请记住，STPA（类似于FMEA和其他分析类型）是最坏情况分析，即假设导致危害的因果链，即使UCA仅在非常不利的副条件下导致危害。必须确保危害的可追溯性，例如通过一个表格列出了所有不安全的控制操作，以及它们并排造成的相应危害。在许多情况下，描述控制行为成为危害原因的附带条件是有帮助的。这可以通过包含“当”、“同时”、“期间”、“虽然”、“与”、“这样”等词语来实现。

以与从危害导出的顶级安全约束类似的方式，控制器的较低级别安全约束也从UCA导出，从而防止UCA。控制器安全约束指定控制器行为的声明或不变量，需要满足这些声明或不变量以防止UCA发生。

一些控制器安全约束（关于一些与制动相关的UCA）如表5所示：

表5：控制器安全约束列表

7.识别导致不安全控制行动的因果场景

STPA的最后一个核心阶段是确定导致危害的原因，或更准确地说，是确定导致危害的因果场景（正如我们在系统性行动链中思考的那样，而不仅仅是局部失效）。在这一点上，我们应该记住，在SOTIF的背景下，我们必须特别注意功能模块（特别是传感器）的限制（包括标称或内在的限制）和弱点，这些并不是失效。如果同时针对ISO 26262和ISO 21448执行STPA，则因果分析可以揭示所有类型的原因，即

- 交互失效（例如，时序失效、命令矛盾、局部状态不一致、控制环路不稳定）

-（传感器和感知算法）缺陷和限制，包括由于不适当的环境模型而导致的缺陷和限制（例如，某种类型的交通参与者可以移动的最大速度）

- 人机交互问题（例如模式混乱、对系统功能的错误假设、未能对系统警报做出正确反应、一定程度的故意误用）

- 组件局部失效

识别导致危害和不安全控制行动的因果场景的活动，为每个UCA解决了两个问题：

1.为什么会出现不安全控制行为？

2.为什么控制动作执行不当或未执行？

图3对此进行了图形化描述：

图3：识别因果场景的两个问题（引自参考资料1）

为了回答问题1，从UCA开始向后遍历控制结构，对于问题2，则向前遍历控制结构。STPA手册列出了直接或间接导致UCA的不同类别的影响，其中一些影响将在下面讨论。显然，这也与组件失效有关，但STPA手册警告不要只列出单个组件失效（例如“轮速传感器失效”）而不告诉整个情况。

使用建模工具创建SysML/UML活动图或序列图来识别和记录这些场景可能会有所帮助。为了找到这些场景，可以采用多种方法，包括

- 专家评审，逐步完成操作顺序

- 危害源典型方案的清单（例如，受到（参考资料1）中建议的方案的启发）

- 故障树分析（在这种情况下，不应仅关注单个组件及其失效，还应关注系统相互作用）

- 仿真。

在SOTIF的背景下，最有趣的因果场景涉及系统某些部分（特别是感知子系统）名义性能的限制和缺陷、其他对象行为的适当模型以及环境中的触发或干扰条件。预计STPA还会揭示技术失效原因，然后应将其移交给ISO 26262 FuSa流程，因为它们超出了ISO 21448的范围。

以下是解决问题1（为什么会发生UCA？）的因果场景示例：

“（1）自车辆接近在右侧邻车道上以曲线行驶的慢速车辆。（2）前雷达传感器报告其他车辆的速度和距离都正确，但都处于碰撞临界状态。(3)由于传感器不准确或调整不当，报告的该车辆的左车道与其实际位置相比有一点向左偏移。(4)同时，基于摄像头感知弯曲道路标线的预测行驶轨迹不够准确，使得一定距离内的行驶轨迹投影时向右有一定偏移。(5)因此，慢速车辆看起来与自车轨迹相交，尽管实际上，本车辆可以轻松超过其他车辆。(6)因此，AEB模块确定碰撞危急情况，并发出可能导致追尾碰撞的紧急制动请求([UCA-12])：[H-2]”

我们可以看到，诸如轻微的偏差和关于现实世界事实的不准确模型等弱点的组合导致了此示例中不安全的控制操作。

下一个例子是解决问题2的场景（正确的控制动作为什么没有正确执行？）：

“(1)HP AEB功能模块发送紧急制动命令，但(2)未采取制动，因为(3)HP状态管理器在这之前临时更改为HP被动模式，而且(4)尚未通知驾驶员，因为(5)检测到异常情况。结果，(6)没有提供减速或减速不足，没有和前车保持安全距离，这可能(7)导致追尾碰撞[H-1]”。

8.确定控制措施和缓解措施，改进系统设计并得出要求

一旦ISO 21448背景下的STPA核心活动完成，STPA的剩余活动就可以委托给相应的流程步骤，请参阅第8节“减少SOTIF相关风险的功能改进”，或了解与失效相关的原因，分别符合ISO 26262-4第6条“技术安全概念”。这涉及制定可实施的要求，这些要求适合满足STPA的安全约束，并防止或检测不安全控制操作的所有原因（失效以及缺陷/限制），并相应地修改或改进系统架构。这部分过程在本附录中未举例说明，请读者参阅本标准的相应条款。

附件：高速公路自动驾驶功能架构示例

为了更好地理解STPA示例，HP示例的功能架构如图4所示。该图遵循控制工程师通常使用的结构，并将整体控制结构显示为从左侧传感器到右侧执行器的开环。从左侧的用户控件（例如按钮、方向盘、制动踏板）到右侧的用户反馈（例如警告、状态信息）。它没有指定技术实现（例如分配给ECU）。

图4：高速公路自动驾驶示例系统的功能架构

图形中间是Highway Pilot(HP)核心功能，由以下功能模块组成

a)纵向控制（自适应巡航控制和紧急制动）

b)横向控制（车道保持控制）

c)状态管理器，管理运行模式（包括失效反应和切换）。

核心模块向执行器（动力系统、制动系统和转向系统）的输出信号的仲裁，由状态管理器控制的仲裁执行。状态管理器从用户界面（例如，HP功能的专用操纵杆、按钮或触摸屏，以及方向盘或制动踏板等“正常”车辆控制装置，这可能表明人类驾驶员想要越过自动驾驶功能）和名为“HP启用条件传感”的特殊块中获得输入，基于诸如路标和道路标记检测的传感器信息来确定当前是否允许启用自动驾驶或保持在自动驾驶模式。状态管理器还负责为驾驶员生成状态信息、接管请求和警告，并在特殊情况下向其他交通参与者发出警告（例如，当车辆因接管失败而需要停车时，命令打开闪光灯）。

为了简化和通用化，感知功能被简化为一个前置摄像头、一个前置远程雷达和一个前置激光雷达，并集成了各自的预处理和物体检测、跟踪和分类功能。带有虚线轮廓的框可以理解为其他传感器的占位符。传感器信息由传感器融合功能块进行后处理和合并，该功能块还完成对象分类和跟踪的过程，以便向HP核心功能提供适当抽象级别的信息，例如目标对象的速度和距离。ACC功能、用于引导横向控制的车道分隔符和围栏描述符以及用于紧急制动功能的碰撞关键物体。该摄像头还提供有关路标的信息，使ACC功能能够了解法定速度限制。一组自我运动传感器提供有关自我车辆的运动和动态条件的实际值，例如自我车辆速度、加速度、行驶距离和偏航率。这些是横向和纵向控制所需要的。

我们假设常用的执行器，如电动（线控）转向系统、电动或传统动力总成以及包括稳定性控制的（线控）制动系统。还假定了转向灯、刹车灯和警告（喇叭、危害闪光灯）的控制接口。驾驶员反馈主要通过仪表盘或屏幕上的象形图（状态反馈、警告、接管请求）以及针对紧急情况和接管请求的声音或触觉警报来实现。模型中未显示，但假定可用的是人类驾驶员与执行器的直接交互，至少包括转向和制动。尽管HP功能感知并考虑了驾驶员的直接交互，但仍然假定它是有机械和液压部件额外保证的，以便可以在人类驾驶员成功接管后的失效情况下用作后备。

详询“牛小喀”微信：NewCarRen

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