面向SOTIF的安全分析与功能改进方法

来源 |   同济智能汽车研究所

编者按：预期功能安全（Safety Of The Intended Functionality, SOTIF）指在系统内部组件并未出现故障的情况下，由外部环境扰动、系统功能局限或人为误操作导致的安全问题，是自动驾驶系统安全性的重要组成成分，已成为近年来的研究热点。编者团队在SOTIF安全分析和功能改进方面进行了一系列研究实践，本文选取其中两篇论文的研究工作进行分享，希望抛转引玉，欢迎各位同行留言讨论。

本文内容来源于以下两篇论文：

[1]《Study on Safety Analysis Method for Take-over System of Autonomous Vehicles》

文章来源：

2020 IEEE Intelligent Vehicles Symposium (IV). IEEE, 1972-1977.

作者：

Chen Junyi, Wang Shan, Zhou Tangrui, Xiong Lu, Xing Xingyu.

原文链接：

https://ieeexplore.ieee.org/abstract/document/9304599

---

---

摘要： 在特定条件下驾驶员被要求从自动驾驶系统接管车辆控制的情形被称为接管过程，但目前缺少对接管过程的安全分析。针对这个问题，我们依据预期功能安全标准ISO 21448扩展了系统理论过程分析（STPA）。我们将接管系统定义为：a)一位驾驶员，以及b)一个人机交互界面（HMI）的组合，并建立了考虑人为因素的控制结构。最后分析了不安全控制行为的原因，并导出了接管系统的安全要求。所提出的方法在一辆园区自动驾驶清扫车上进行了应用，基于安全分析所得的安全要求设计了接管系统的人机交互界面，通过接管测试和问卷调查的方式对其有效性进行了验证。

[2]《城市自动驾驶决策系统安全分析与策略设计》

文章来源：

同济大学学报（自然科学版）, 2020, 48(12):1810-1817.

作者：

陈君毅, 刘力豪, 周堂瑞, 邢星宇

原文链接：

http://tjxb.cnjournals.cn/ch/reader/view_abstract.aspx?file_no=202012014&flag=1

---

---

摘要： 基于系统理论过程分析（System Theory Process Analysis, STPA）提出一种面向高等级自动驾驶决策系统的安全性开发方法。该方法应用在一个城市自动驾驶决策系统的原型开发阶段，通过安全分析得到系统的70个不安全控制行为。针对其中3个功能状态，分析得到10个不安全控制行为原因，提出9个安全策略。应用其中一个典型安全策略进行了系统改进，通过仿真试验对其进行了验证。试验结果表明，基于所提出方法设计的安全策略有效可行，提出的方法能够提高自动驾驶决策系统的安全性。

 1 方法流程

1.1 STPA安全分析方法

传统安全分析方法，如故障树分析（FTA）和失效模式与效应分析（FMEA）等基于可靠性理论，用以识别系统中组件故障引发的事故；HAZOP则提出一种结构化和系统化的方法，用以识别产生事故的原因以及可能的后果。然而随着科技发展，控制系统已经从简单的机械或电气系统转变为复杂的软件密集型系统。传统安全分析方法不适用于分析系统组件间的交互行为违反安全约束而导致的危害。

针对复杂系统的安全分析，Leveson提出了基于控制理论的STPA方法。该方法认为导致事故的根本原因不是系统组件的失效，而在于外部环境扰动或者系统内部组件的错误交互没有被控制系统正确处理。这样，安全被视为在特定环境下系统中各组件的交互行为在整体层面产生的涌现性质，进而安全问题成为控制问题，可以通过对系统各组件的行为与交互施加安全性约束来阻止事故发生。

STPA方法通过一系列步骤找出导致系统危害的根本原因，其通用方法分为4个步骤：

1、定义系统危害，以及系统危害所对应的安全性约束；

2、建立系统控制结构，控制结构应包含过程模型，图1示例了一般系统的控制结构图；

3、根据控制结构图，确定系统的安全关键控制行为，进一步识别系统的不安全控制行为，图2示例了一般系统的不安全控制行为；

4、分析导致不安全控制行为的原因。

图1 一般系统的控制结构图

图2 一般系统的不安全控制行为

1.2 安全分析结果应用

STPA方法可以应用到系统开发的各个阶段。在系统开发的早期阶段，可使用STPA方法分析得到系统安全要求，用以指导设计；在系统开发过程中，可使用STPA方法分析和查找系统安全性漏洞，进行功能改进。我们将基于安全分析结果的功能设计和功能改进分为两个思路：正向和反向。正向为提升系统本身的能力，修复其可能存在的错误，弥补其性能不足，使系统在原本的潜在危险场景下不发生事故；反向为限制系统的运行场景，通过要求、标准或法规禁止系统在原本的潜在危险场景下运行，达到避免事故的目标。

 2 方法应用

2.1 基于分析对象的方法改进

在两篇论文中，我们分别将基于STPA的安全分析方法应用到a)园区自动驾驶接管系统的HMI设计和b)城市自动驾驶决策规划原型系统的功能改进中。值得注意的是，STPA只提供了安全分析的基本框架。在对两个系统进行安全分析的过程中，我们基于分析对象各自的特点，对leveson提出的STPA方法作出了一定的改进。

对于a)园区自动驾驶接管系统，分析遵循了STPA方法原本的流程。对于接管系统，不正确的人机交互是危害的主要来源。驾驶员的接管响应决定了接管过程的及时性和有效性。因此在对接管过程进行安全分析时人为因素必须被纳入考虑。我们使用了现行预期功能安全标准ISO 21448提供的人为因素的引导词，如表1所示。

表1 SOTIF提供的人为因素引导词

过程	引导词	例子
识别	不能理解	因为复杂的用法而不能正确操作
	误识别	因为信息过载而无法识别
判断	判断错误	因为错误印象或者误解而判断失误
执行	失误	由于注意力不集中而失误
	故意	违反交通法规或社会规则
	失能	无法操作

对于b)城市自动驾驶决策规划原型系统，在STPA的基础上提出了一个改进的分析流程，如图3所示。由于难以直接定义系统危害和安全性约束，我们调整了分析流程的顺序，将安全分析的起点变更为系统控制结构和过程模型的构建，并在分析过程中逐步推导得到系统危害和安全性约束。同时，作为一个完整的功能改进方法，我们还在原方法上新增了策略设计和试验验证环节。

图3 基于STPA的安全性开发流程

2.2 应用实例：园区自动驾驶车辆接管系统

2.2.1 安全分析

接管系统的工作原理如下：当车辆有必要被接管时，自动驾驶系统提供信号给HMI，提醒驾驶员接管车辆。接管系统的功能是提供正确的接管行为并防止车辆发生碰撞。基于这个概念，系统级危害以及相应的安全性约束被分析提出，如表2所示。

表2 接管系统的危害和安全性约束

序号	系统危害	系统安全性约束
1	当车辆需要接管时，驾驶员未接管，导致碰撞。	当车辆需要接管时，驾驶员应该接管。
2	当车辆不需要接管时，驾驶员接管，导致碰撞。	当车辆不需要接管时，驾驶员不能接管。
3	当车辆需要接管时，驾驶员未正确接管，导致碰撞。	驾驶员应该正确接管。

基于接管系统的功能，建立其控制结构，如图4所示。

图4 接管系统控制结构图

与接管相关的控制行为共5个：

C1：驾驶员开始手动驾驶/驾驶员将驾驶权移交给自动驾驶系统；

C2：车辆信息被发送给驾驶员，作为参考；

C3：接管请求被发送给驾驶员；

C4：外部环境信息被发送给驾驶员，作为参考；

C5：接管信号被发送给接管系统的HMI。

由于控制行为C1、C2、C3与HMI设计直接或间接相关，在接下来的分析中我们关注C1、C2和C3。

STPA将不安全控制行为分为4个类别：1）需要但未提供；2）不需要但提供；3）提供，但时机错误；4）提供，但持续时间错误。基于上述分类，对每一个控制行为的不安全控制行为以及潜在危害进行了分析，如表3所示。

表3 接管系统的系统危害和不安全行为

不安全控制 行为	系统 危害 序号	系统危害描述
C1	H1	接管请求后驾驶员没有及时接管。
	H2	驾驶员不正确地接管车辆。
	H3	驾驶错误地切换回自动驾驶模式。
C2	H4	HMI未提供有效的接管请求。
	H5	HMI过于频繁地提醒驾驶员，导致驾驶员的警惕性降低。
	H6	HMI未及时提供接管请求。
	H7	接管请求持续时间过短，未引起驾驶员注意。
C3	H9	HMI未提供有效的信息导致驾驶员不能完成接管。
	H10	提供的信息过于复杂，导致驾驶员未注意或理解重要信息。

在此基础上，根据SOTIF提供的人为因素引导词，从驾驶员的认识、判断和执行三个方面识别不安全控制行为的原因，并提出具体的安全要求和完整的安全性约束。我们将接管系统HMI分为两个部分：图形用户界面（GUI）和接管请求，最终每部分对应的具体安全要求如表4所示。

表4 接管系统的具体安全要求

HMI组件	安全要求	系统危害
GUI	R2: 自动驾驶和手动驾驶模式的状态信息要能够清晰可辨。	H2, H3, H8
	R3: 当切换了自动/手动驾驶模式后进行警示。	H2, H3
	R4: 车辆当前状态信息要能实时显示。	H3, H8
	R8: GUI要具有合理的布局和层次化的信息分割。	H9
接管请求	R1: 接管请求要足够清晰和容易被识别，最好具有多种激励方式。	H1, H6
	R5: 相比其他消息，接管请求要具备第一优先级。	H4, H7, H9
	R6: 接管请求应该是层次化的。	H4, H7, H9
	R7: 接管请求应该具有合理的持续时间。	H7

2.2.2 HMI设计

在HMI的设计中，我们在3个方面应用分析得到的安全要求：a)进行安全导向的方案设计（例如GUI信息的选择）；b)确立方案选择的评估准则（例如图标设计的差异化程度）；c)问卷调查和接管测试。

对于GUI的设计，在信息选择方面，依据安全需求R3和R4，自动/驾驶模式切换后GUI上应该有警示信息，当前的驾驶状态应该实时显示。在信息布局方面，依据安全需求R8，我们将GUI分为左中右三块区域，如图2所示。左边区域放置一个显示当前车速的速度计，右区域中显示各传感器的工作状态，中间区域的信息包括手动/自动驾驶状态、当前自动驾驶模式（例如沿车道行驶）以及导航地图，对于中间区域的信息布局我们设计了3个方案以作后续对比。在图标设计方面，依据安全需求R2和R4，我们设计了3个信息展示的方案：只有文字、只有图标、文字和图标。此外，不同的图标颜色被用以区分不同的运行状态。绿色图标代表自动驾驶模式，白色图标代表手动驾驶模式。当传感器发生故障时，图标将会变红；当传感器信号缺乏时，图标将会变黄。

图5 GUI信息布局分区

图6 GUI中间区域的三个设计方案

对于接管请求的设计，依据安全需求R5，我们将接管请求界面设计为覆盖正常车辆状态界面，以保证接管请求具有最高优先级；依据安全需求R1和R6，我们设计了多个接管阶段，如表5所示，我们在后续的实验中对比了只包含阶段2和3的方案A与包含全部阶段的方案B。依据安全需求R7，我们将每个阶段的持续时间设计为3.5秒，这是考虑了传感器的探测距离、车速和路径规划用时的较合理的时间。

表5 接管请求的3个阶段

阶段	描述	方案图
1	当满足接管条件时，屏幕边缘将会出现白色闪烁，伴随警示音。
2	屏幕中心出现红色接管标志，警示音保持播放。
3	如果驾驶员仍未接管车辆，整个屏幕会变红，并显示“Take-Over”字样，伴随有更急促的警示音。

为了选出最好的设计方案，我们对11位被测者进行了接管测试和问卷调查。在接管测试开始时，被测者被要求一直求解数学问题，来模拟他们被非驾驶任务分心的情况。一段时间后，接管请求会出现在屏幕上，被测者需要按下特定按键进行接管。接管时间被定义为从接管请求出现到被测者按下接管按钮的时间。根据接管测试的结果（表6所示），方案B的平均接管时间小于方案A，表明B方案对于接管过程而言更加安全。

我们也根据安全要求确认评价标准并设计问卷，依据问卷调查结果对不同的HMI设计方案进行了选取。

表7 问卷调查结果

项目	安全要求	评价准则	问卷调查结果
信息布局	R8	合理性	方案 2 > 方案 3 > 方案 1
图标设计	R3, R4	区分度 信息负载	图标加文字 > 仅文字 > 仅图标

最终，基于问卷调查和接管测试的结果，选择信息布局方案2，图标加文字的图标设计方案，以及接管请求方案B（包括3个阶段）作为最终的HMI设计方案。

2.3 应用实例：城市自动驾驶决策规划系统

2.3.1 安全分析

第二篇论文中研究的城市自动驾驶决策系统基于有限状态机构建，在MATLAB/Simulink中完成了原型实现，涵盖4个子功能：①沿全局路径的循迹，包括无前车的定速巡航和有前车的跟车巡航；②主动换道，在巡航通行效率过低时会考虑进行主动变道；③路口通行，通过交通信号灯控制的路口；④自主泊车，在路边停车位进行垂直车位泊车或者平行车位泊车。我们根据系统功能和原型实现抽象得到控制结构和过程模型，如图7和图8所示。

图7 城市自动驾驶系统控制结构图

图8 基于决策状态机抽取的过程模型

从控制结构图中确定安全关键控制行为，即直接与事故相关的控制信号或指令。对于被分析的自动驾驶决策系统而言，它包括了期望速度（A1）和期望位置（A2）两个控制行为，记为集合A。

在STPA通用分类方法的基础上提出了以下8种错误模式：需要提供控制信号但未提供（M1），不需要提供控制信号但提供（M2），提供了正确的控制信号但时机过早（M3），提供了正确的控制信号但时机过晚（M4），提供的控制信号持续时间过长（M5），提供的控制信号持续时间过短（M6），提供的控制信号数值过大（M7），提供的控制信号数值过小（M8），用M表示它们的集合。

用功能状态指代自动驾驶车辆不同的运行情况。从过程模型中提取得到9个功能状态：定速巡航（S1），跟车巡航（S2），换道（S3），换道后保持（S4），交通信号灯处理（S5），路口中决策（S6），寻找车位（S7），平行泊车（S8）和垂直泊车（S9）。用S表示功能状态的集合。

作集合A、M与S的笛卡尔积，可以得到所有可能的不安全控制行为，对这些不安全控制行为做进一步的筛选、原因分析和结果分析，可以得到系统危害和细化的安全性约束，并提出针对性的安全策略。以自主泊车功能为例，最终的分析结果如表8所示，提出安全策略如表9所示。

表8 泊车功能的不安全控制行为、安全性约束与系统危害

不安全控制行为	安全性约束	系统危害	事故
（A1, M2, S7）	C1 寻位时，车辆应随时检测前进方向，当有障碍物时，及时减速制动	H1 寻位时前方有障碍物，车辆未停止等待	D1 自车在寻位时与前方障碍物发生碰撞
（A1, M7, S7）	C2 泊车时，采用速度不能超过上限	H2 寻位时使用过高的速度
（A2, M2, S7）	C3 寻位时，车辆应始终沿全局路径行驶	H3 寻位时车辆偏离目标轨迹
（A1, M2, S8/S9）	C4 车位可行性检测应准确无误	H4 选择了已经被占据的库位进行泊车	D2 自车在泊车时与库位或周围停放的车辆发生碰撞
（A2, M*, S8/S9）	C5 泊车模式判断和切换应准确无误	H5 使用错乱的泊车模式泊车
（A1, M3/M5, S8/S9）	C6 泊车时，规划的轨迹应使车辆与周围障碍保持一定安全距离	H6 泊车时车辆离周围障碍物过近
（A2, M*, S8/S9）
（A1, M7, S8/S9）	C7 泊车时，采用速度不能超过上限	H7 使用过高的速度进行泊车
（A1, M2, S8/S9）	C8 泊车过程中，应实时检测周围环境中的动态障碍物，当有物体进入车库时，应暂停泊车	H8 泊车过程中，库位内进入其余车辆或行人，车辆未停止等待	D3 自车在泊车时与闯入库位的行人或车辆发生碰撞

表9 泊车功能的安全策略

安全策略序号	安全策略内容	系统 危害
SS1	使用多源传感器确保障碍物位姿、几何和速度信息的冗余	H1
SS2	在寻找车位的期望速度输出通道上添加一个软件限制器	H2
SS3	寻找车位时，限制期望位置只能输出0值（与全局路径偏移为0）	H3
SS4	综合智能停车场的V2X信息和感知检测结果判断车位是否为空	H4
SS5	综合智能停车场的V2X信息和感知检测结果判断泊车模式	H5
SS6	泊车轨迹规划算法中，设置安全距离；并在泊车过程中，随时检测安全距离是否得到保持	H6
SS7	在泊车状态的期望速度输出通道上添加一个软件限制器	H7
SS8	在泊车规划模块中增加紧急制动状态	H8
SS9	仅限在封闭道路中使用泊车功能	H8

2.3.2 功能改进

以危险事件“因决策系统缺少紧急制动状态，导致泊车过程中车辆未避让闯入库位的行人，发生碰撞”为例，说明功能改进的步骤。我们使用PreScan联合MATLAB/Simulink的仿真平台进行试验，试验场景如图 9所示。自车为黑色车，将泊入中间平行库位，在车辆开始泊车后，有一行人走入库位中。

图8 危险事件试验场景

安全性分析中指出，由于自车在完成库位检测开始倒车入库后，其行为被确定，不再受外界环境影响，也不具备紧急制动机制。如果此时有行人进入车位，自车不会避让。通过仿真对危险事件进行验证，试验结果表明，自车最终与行人发生碰撞，碰撞过程如图 9所示。

图9 自车与行人的碰撞过程

我们通过实现安全策略SS8“在泊车规划模块中增加紧急制动状态”对该决策系统进行了功能改进。安全策略的工作原理是：在车辆泊车过程中，实时检测库位中是否存在闯入的行人或车辆等动态物体，如果存在且碰撞检测标志为真，则转移到紧急制动状态，输出0期望速度，以避免碰撞发生。搭载安全策略后的泊车状态机程序如图 10所示，其中浅色区域内即为添加的紧急制动状态。当碰撞检测标志“CrashCheck”为真时，保存工作现场并从泊车状态转移到紧急制动状态，输出0期望速度；当“CrashCheck”为假时，退出紧急制动状态，恢复工作现场，继续完成泊车。

图10 添加紧急制动模块后的决策状态机程序

我们同样通过仿真对安全策略的效果进行了验证。图 11展示了泊车过程中自车速度以及自车与行人相对距离的变化。在34.1 s时搭载安全策略前后的自车均完成了第一次泊车规划，速度降低至0。未搭载安全策略的车辆随即重新加速执行第二次泊车规划，而未注意避让后方闯入库位的行人，导致最终在36.4 s时发生碰撞（相对距离为0）；搭载安全策略后的车辆检测到行人，在34 s~38 s间保持速度为0、安全距离大于2 m，成功避让行人，过程如图12所示。

图11实现安全策略前后泊车过程中的自车速度和相对距离

图12 实现安全策略后的泊车过程

 3 研究总结

自动驾驶系统的安全性是一个长尾问题，SOTIF框架和STPA方法为我们解决这个关键且困难的问题提供了一些思路。本文介绍了我们在SOTIF安全分析方面的一些实践经验，通过园区自动驾驶车辆接管系统的例子介绍了安全分析在功能设计上的应用，通过城市自动驾驶决策规划原型系统的例子介绍了安全分析在功能改进上的应用。

在研究的过程中，我们也发现了STPA方法的一些局限性，通过引入其他方法对原本的STPA方法做了一些扩展。针对人因相关的不安全控制行为难以分析的问题，我们参考了ISO 21448的引导词机制；针对直接定义系统危害和安全性约束困难的问题，我们调整了分析步骤的顺序，从系统本身功能和结构出发，通过不安全控制行为推导出危险事件；针对复杂系统过程模型难以构建的问题，我们引入了状态机方法，通过行为状态对系统的控制逻辑进行抽象。然而自动驾驶系统的预期功能安全仍有许多待解决的问题。

后续我们将对不安全控制行为的触发条件做进一步的研究，明确和量化环境因素对自动驾驶系统性能产生的影响；也将研究减少分析过程中对专家经验的依赖，建立半形式化和自动化的分析方法，提高分析结果的可靠性和一致性。