面向机载软件的预期功能安全分析验证过程及方法研究

姜梦岑，温晓玲，李海峰

（1.航空工业沈阳飞机设计研究所，辽宁沈阳 110035；2.北京航空航天大学，北京 100191）

机载软件对系统任务完成与运行安全有着决定性的影响，其一旦发生失效，轻则导致任务失败，重则导致飞行事故［1］。因此，机载软件通常需要满足较高的安全性要求［2-3］。国内外已经制定了一系列标准［4-5］，来保障机载软件安全性满足指标要求。

对于具有复杂逻辑的机载软件来说，其导致系统危险的原因，不仅仅是非法数据、通信中断等单点失效，还可能是软硬耦合冲突、人机交互异常、外部环境干扰、功能并发冲突等复杂行为。而传统功能安全技术，例如，故障模式与影响分析（Fault Modes and Effect Analysis，FMEA）、故障树分析（Fault Tree Analysis，FTA）等，倾向于将此类复杂行为排除在系统设计范围之外，导致很多机载软件虽然经历了较为充分的功能安全和测试工作，但运行时仍然会出现非预期的系统危险，难以满足新一代复杂机载系统及其软件的高安全、高可靠要求。

针对传统功能安全技术应用于复杂系统时存在的不足，自动驾驶汽车领域提出了预期功能安全（Safety of the Intended Functionality，SOTIF）的概念［6-7］。依据ISO 26262 与ISO 21448，SOTIF定义如下：系统不存在由于危险而导致的不合理风险。其中，危险是由于系统预期功能不足（设计不足或性能局限）或合理可预见的人员误操作引发的。

依据上述定义，相对于传统功能安全，SOTIF重点关注系统在与外界环境、交联设备、任务场景和操作人员交互时，由于自身功能设计存在遗漏或者缺陷而导致的软件失效。SOTIF是功能安全在复杂系统上的扩展与完善，可以更加准确地追溯系统安全事故的复杂成因，有效保障系统和软件在非预期交互、动态控制异常、工作状态异常、多失效组合等复杂情况下的安全性水平，确保将系统和软件的运行风险控制在可接受的范围内。

近些年来，国内外高校、研究所、公司等针对SOTIF开展了大量的技术研究和典型应用［8-14］。已有研究表明，SOTIF理论将复杂系统安全性视为一个动态控制问题，具有分析过程动态化、非单点故障的危险溯源、多失效组合分析等优势，可有效识别复杂系统的安全隐患和约束条件，弥补传统功能安全应用于复杂系统时存在的不足，已成为系统和软件在安全性领域的重要研究方向与发展趋势。但是，目前SOTIF 多以汽车驾驶系统为对象开展研究，在航空、航天等领域则极为少见。因此，本文将借鉴SOTIF 在汽车领域的成功应用经验，面向复杂机载软件系统，开展机载软件SOTIF分析验证过程与方法研究，为SOTIF 在机载软件领域的研究与应用提供支撑。

1 机载软件SOTIF分析验证框架

SOTIF与功能安全类似，均需通过完整且严格的分析验证过程来保障系统安全能力，本质在于将大量技术活动归纳于若干步骤，转化为执行性高、可复现的操作指南，在最大程度上规避因人员能力或经验差异而导致的工作结果不一致的情况。因此，本文参考ISO 21448 标准，机载软件SOTIF分析验证过程需要贯彻“迭代”的概念［6］，实施框架如图1 所示。

图1 机载软件SOTIF分析验证过程

在图1 中，标注绿色的部分为机载软件SOTIF 分析验证相关的关键技术活动，说明如下。

①相关项定义。

依据ISO 21448 开展SOTIF 工作，需要先确定分析验证的对象［6］。因此，本文针对该项技术活动，将开展机载软件SOTIF建模技术研究。

②危险分析与风险评估。

此项活动需要识别系统危险，并评估风险等级。在本文中，针对该项活动，开展基于功能危险分析（Functional Hazard Analysis，FHA）的机载软件SOTIF危险分析研究和基于危险分析的风险评估研究。

本质上，FHA 技术来源于功能安全，但也可以应用于SOTIF。这是因为SOTIF是功能安全的扩展和补充，二者的目标是相同的，即消除系统危险，控制风险在合理可接受的范围内。因此，本文将参考功能安全的工程经验，将FHA技术应用于SOTIF活动。

③识别功能不足与触发条件。

此项活动需要分析导致危险的系统功能存在的不足，以及引发系统功能存在的不足的触发条件（即原因），进而针对触发条件制定安全性需求，以消除危险，降低系统运行风险。本文针对该项活动，开展基于系统理论的事故模型（Systems Theoretic Accident Modeling and Process，STAMP）的机载软件SOTIF分析技术研究。

④针对已知危险及其原因的测试验证。

ISO 21448 将系统运行场景分为4 个区域［6］，即已知安全场景（区域1）、已知不安全场景（区域2）、未知不安全场景（区域3）和未知安全场景（区域4），如图2所示。

图2 SOTIF系统运行场景

其中，区域2 和区域3 是SOTIF需要解决的问题，即充分识别系统运行过程中的各种危险及其原因（功能设计不足、性能局限或者人员误操作等），验证已知不安全场景和未知不安全场景是否得到有效识别与消除。因此，本文针对该项活动，将开展场景驱动的机载软件SOTIF测试技术研究。

需要说明的是，图1 中除了上述4 项活动，还有“回顾与复审”“运维阶段活动”“功能提升和修改”等活动，限于篇幅，不作为本文讨论的重点。

2 机载软件SOTIF建模与危险分析技术

2.1 机载软件SOTIF建模

有研究表明，在SOTIF 分析验证过程中引入建模技术有利于工作效率的提升［14］。因此，本文参考SOTIF构建汽车自动驾驶系统测试场景的经验，从控制逻辑、外部设备、软硬耦合、运行场景、数据交互等角度对机载软件需求进行SOTIF建模。

（1）系统控制视图建模。

首先，参考机载系统的典型控制任务，建立系统控制视图模型，如图3 所示。

图3 系统控制视图模型

该模型描述机载系统控制过程以及与外部设备（传感器、执行机构、操作人员等）之间的交互情况，为其他模型的构建提供输入基础。

（2）外部接口建模。

对软件外部输入输出接口、数据及其关联设备等信息进行规范描述，支撑从接口角度进行SOTIF 分析。需明确数据取值、时序关系、通信协议、源／目的设备、故障策略、余度关系等内容，具体建模要求如下。

①数据取值：包括取值范围、取值精度、安全值／初始值设置等。

②时序关系：包括输入输出时刻、输入输出周期、输入输出持续时间等。

③通信协议：包括数据帧格式、数据帧长度、数据帧校验方式等。

④源／目的设备：明确输入数据来源设备的状态或工作模式，以及输出数据目的设备的状态或工作模式。

⑤故障策略：包括故障诊断、故障处理、故障复位等故障策略。

⑥余度关系：包括多余度输入数据表决、多余度输出数据表决等。

（3）功能逻辑建模。

对软件功能处理逻辑、控制过程等进行规范描述，支撑从功能角度进行SOTIF 分析。须明确控制过程、数据解算、处理逻辑、余度切换等内容。具体建模要求如下。

①控制过程：应明确软件所控制的对象、输出的控制指令、采用的控制律算法等内容。

②数据解算：应明确数据解算的输出值范围、数据解算公式、数据解算模型等内容。

③处理逻辑：应明确功能进入条件、功能执行分支、功能操作过程等内容。

④余度切换：应明确主备通道的切换条件、切换时机、切换时长等内容。

（4）交互关系建模。

对软件与硬件项、操作人员之间，软件功能项之间等因素的交互关系进行规范描述，支撑从外部交互角度进行SOTIF 分析。须明确软硬耦合、人员操作、告警显示、功能交互等内容。具体建模要求如下。

①软硬耦合：明确软件项与硬件项之间的控制耦合关系、数据交互关系等内容。

②人员操作：明确人员操作软件的操作方式、输入方式等内容。

③告警显示：明确告警显示的方式、优先级、显示时序等内容。

④功能交互：明确功能之间的组合、调用等交互关系。

（5）运行场景建模。

对机载软件运行中所经历的飞行阶段、状态模式、任务环境等信息进行规范描述，支撑从运行场景角度进行SOTIF分析。须明确典型运行场景、场景切换过程、场景切换条件等内容。具体建模要求如下。

①典型运行场景：应明确机载软件运行过程中所处的工作模式、飞行阶段、任务阶段等内容。

②场景切换过程：应明确各个场景之间的切换过程、切换时序等内容。

③场景切换条件：应明确场景的进入条件、退出条件等内容。

2.2 系统功能危险分析

针对机载系统功能，识别不同工作状态下的功能危险，并分析危险对于系统任务完成或运行安全的影响后果与等级。具体过程与技术方案如下。

（1）系统功能识别。

首先，依据系统需求，识别机载系统运行过程中可能经历的飞行阶段及工作状态。然后，依据GJB 438B／C等标准，从“外部输入（Input）→处理过程（Process）→外部输出（Output）”的黑盒角度，识别不同工作状态或飞行阶段下的系统功能，形成系统功能清单，为“功能危险识别”提供输入。

（2）系统功能危险分析。

系统功能危险指的是功能输出的各类异常。本文考虑针对机载系统功能的外部输出数据，从数据失效、时序失效、通信失效、目的设备失效等角度，分析不同飞行阶段或者工作状态下，系统功能输出的各种异常。例如“系统功能持续N 秒未输出”“系统功能输出超限”等。

（3）危险影响分析和等级评估。

从“运行安全”（对机载设备或机组人员的损伤）和“任务完成”（任务无法完成或者性能降低）这两个角度分析机载系统危险的影响后果，例如，系统死机崩溃、任务执行超时、设备损坏等。可建立系统外部交联环境视图、功能组成框图等，辅助危险影响分析的开展，并评估影响后果的严重等级，包括A、B、C、D等级别。

2.3 基于危险分析的系统风险评估

系统风险评估包括危险事件分析、危险严重性等级评估、危险可能性等级评估、系统风险指标评估等几项内容。其中，危险事件分析、危险严重性等级评估已经在2.2 节中进行了说明，本节重点阐述后两项内容的技术方案。

（1）危险可能性等级评估。

可依据危险所在功能的运行频率或者导致危险的外部输入频率，以及系统所采取的软件和硬件检测手段，分析每项系统危险出现的可能性（即出现概率P），进而对危险可能性等级进行评估。依据GJB／Z 102A，可能性等级可分为5 级，即经常（P ＞10-1）、很可能（10-2≤P≤10-1）、偶然（10-3≤P≤10-2）、很少（10-4≤P≤10-3）和极少（P≤10-4）。

（2）系统风险指标评估。

综合每项系统危险事件的严重性等级和可能性等级，采用表1 的系统风险指标评估矩阵，对每项危险的系统风险指标进行评估。

表1 系统风险指标评估矩阵

3 基于STAMP的机载软件SOTIF 分析技术

STAMP将事故理解为系统设计、开发和操作过程中的安全性相关约束没有得到充分控制或充分施行［15］，这与STAMP模型的思想不谋而合。因此，本文将依据ISO 21448 等标准，参考STAMP模型及其应用技术系统理论过程分析（Systems-Theoretic Process Analysis，STPA），在SOTIF 安全模型基础上，开展机载软件SOTIF分析技术研究。主要过程如图4 所示。

图4 基于STAMP的机载软件SOTIF分析

3.1 复杂场景下的机载软件SOTIF影响因素

参考SOTIF构建汽车自动驾驶系统测试场景的经验，针对机载软件系统控制视图模型中的运行环境、任务阶段、控制逻辑、软硬耦合、外部激励等场景进行分析，识别安全影响因素，为异常控制行为及其原因分析提供依据。主要包括以下内容。

①软硬件耦合冲突：由于外部执行机构行为或属性出现异常，导致软件任务失败或运行异常。例如，执行机构运动速度过快或过慢，执行机构的运动位置超出物理极限位置等。

②动态控制异常：软件控制过程或者控制律算法出现各种异常，导致软件任务失败或者运行异常。例如，执行机构行为与控制指令连续多个周期不相符、控制过程提前结束或者滞后结束等。

③工作状态异常：由于软件所处的工作状态出现异常，导致软件任务失败或者运行异常。例如，工作状态切换后，功能异常终止等。

④功能并发冲突：软件多个功能或组件并发时出现冲突，导致软件任务失败或运行异常。例如，多个功能同时对同一数据进行赋值，产生冲突等。

⑤运行环境影响：与软件处于同一环境的硬件项或软件项出现异常，导致任务失败或运行异常。例如，外存故障或存满，操作系统不兼容等。

⑥人员误操作：操作人员的非法操作、快速操作、误操作等异常。例如，执行关键控制时未充分确认，重复施加控制指令等。

3.2 基于故障树的软件异常控制行为识别

本文依据机载系统体系结构与可靠性框图，构建故障树，自上而下地识别导致系统危险的软件原因事件，即异常控制行为，形成系统向软件分配的SOTIF需求，反馈至系统设计架构中。包括如下内容。

（1）系统体系结构分析。

自上而下确定系统由哪些子系统、设备、软件项或硬件项组成，并确定这些组成项之间的层级关系，以及这些组成项之间的动态数据交互关系，从而为故障树模型构建提供依据。

（2）基于系统体系结构的故障树建模。

首先，针对系统功能危险分析结果，选取“影响等级”为“A级”的功能危险，作为故障树顶事件。然后，基于系统体系结构自上而下逐层展开，分析组成项可能存在的异常失效，构建故障树的中间事件和底事件。同时，依据组成项之间的动态运行关系，构建相应的“逻辑门”。例如，组成项之间为串联关系，对应“或门”；组成项之间为并联关系，对应“与门”。

（3）基于故障树的软件异常控制行为识别。

基于故障树模型，识别底事件中由软件导致系统危险的原因，即软件异常控制行为。主要包括以下部分。

①控制行为不完整安全：例如，没有提供必须的控制行为，没有提供充分的控制行为，以及控制行为可能会导致人员伤亡、设备损坏或环境破坏。

②控制行为时序不符合约束要求：例如，执行时间过晚或过早、控制行为持续时间过长或过短、控制行为无法结束或者异常中断等。

③执行机构未正确响应：例如，执行机构未响应或未正确响应控制信号，执行机构过早或者过晚响应控制信号等。

④执行机构运行异常：例如，执行机构运动速度过快或过慢，执行机构位置超出物理限位等。

（4）系统向软件分配的SOTIF要求。

针对故障树中与软件相关的底事件和软件异常控制行为，从事前预防或事后控制的角度，形成系统向软件分配的SOTIF要求，主要包括以下部分。

①针对数据失效的SOTIF要求：针对输出接口数据的取值、组合、变化等异常情况，进行检查，提出处理措施，确保输出取值有效的数据信息。

②针对时序失效的SOTIF 要求：针对输出周期、时刻、持续时长等异常情况，进行检查，提出处理措施，确保输出时序有效的数据信息。

③针对通信失效的SOTIF要求：针对输出接口的格式、内容等异常情况，进行检查，提出处理措施，确保软件能够输出通信协议有效的数据信息。

④针对余度失效的SOTIF要求：针对软件余度表决关系，进行容错检查，分析余度输出不一致、余度输出无效等异常情况，提出相应处理措施。

⑤针对交联设备失效的SOTIF要求：对外部交联设备进行检查，分析设备未响应指令或者处于故障状态等异常情况，提出相应处理措施，确保软件正确实现与交联设备的数据或控制交互。

3.3 基于影响因素的异常控制行为原因分析

最后，依据SOTIF 影响因素，识别导致异常控制行为的各种可能原因。例如，接口数据异常、软硬耦合冲突、设备状态异常、外部非法干扰、人机交互异常、状态场景异常、功能逻辑异常、功能组合异常等。具体如下。

①接口数据异常：针对软件外部接口的数据取值、时序约束、通信协议等进行异常控制行为原因分析，例如数据取值异常、通信中断、关联设备故障、余度设计异常等。

②功能逻辑异常：针对软件控制过程、数据解算、处理逻辑等进行异常控制行为原因分析，例如功能执行超时、逻辑分支无法成立等。

③功能组合异常：针对软件功能之间的并发、串行、调用等组合关系，进行异常控制行为原因分析，例如功能并发冲突、顺序执行异常等。

④状态场景异常：针对软件工作状态和飞行阶段，进行异常控制行为原因分析，例如状态无法退出、状态转移导致功能中断等。

⑤软硬耦合冲突：针对软件项与硬件项之间的控制或者数据交互关系进行异常控制行为原因分析，例如硬件未响应软件的控制指令、硬件错误响应软件的控制指令等。

⑥人机交互异常：针对人员操作行为进行异常控制行为原因分析，例如重复操作、误操作等。

⑦设备状态异常：针对交联设备的状态进行异常控制行为原因分析，例如设备处于上电、下电、故障等异常状态。

⑧外部非法干扰：针对软件所处的运行环境和外部信号等进行异常控制行为原因分析，例如强电磁干扰信号等。

4 场景驱动的机载软件SOTIF测试技术

在SOTIF模型与软件异常控制行为原因分析基础上，构建基于SOTIF 的测试用例及典型测试场景，实现对软件各类异常控制行为和复杂运行场景的有效覆盖。

4.1 机载软件SOTIF测试场景构建

基于软件异常控制行为及其原因分析结果，参考汽车自动驾驶系统测试场景构建方法，构建机载软件SOTIF测试场景，实现对软硬耦合、控制过程、外部激励、人机交互、状态切换等复杂场景的有效模拟或仿真。

“场景”通常用于描述导致结果的一系列动作和事件。在ISO 26262 标准中，将场景分为功能场景、逻辑场景和具体场景3 类［7］。在本文中，机载软件的场景（测试场景或者运行场景）主要指的是，软件与其任务阶段、运行环境等组成要素在一段时间内的总体动态描述，这些要素组成由所期望完成的系统任务与具体功能决定。

基于上述定义，本文将识别的软件异常控制行为及其原因，转化为机载软件与其任务阶段、运行环境等要素表征的一系列动作与事件，形成软件SOTIF 测试场景构建要求。主要包括以下部分。

①基于接口数据异常的SOTIF测试场景：针对外部接口数据的各类异常，通过异常激励数据施加构建测试场景。例如，设置输入数据取值大于值域上限、取值一段时间内保持不变等。

②基于控制过程异常的SOTIF测试场景：针对软件控制过程中的各类异常，通过异常激励数据施加或环境仿真构建测试场景。例如，设置控制律长时间未输出数据、输出取值大于值域上限等。

③基于交联设备异常的SOTIF 测试场景：针对源／目的等交联设备的异常，通过设备模拟或仿真等方式构建测试场景。例如，设置传感器下电故障、数据库容量已存满、执行机构卡滞等。

④基于余度表决异常的SOTIF测试场景：针对余度表决异常，通过余度模拟或者仿真等方式构建测试场景。例如，设置余度来源设备处于下电状态、余度间的数据取值之差大于规定阈值等。

⑤基于状态切换异常的SOTIF测试场景：针对软件工作状态之间的切换异常，通过异常激励数据施加或仿真等方式构建测试场景。例如，设置状态切换超时、同时进入两个工作状态等。

4.2 场景驱动的软件SOTIF测试用例设计

在所构建的SOTIF测试场景基础上，建立异常控制行为原因、SOTIF要求与用例输入，以及预期输出之间的关联关系，设计SOTIF测试用例。

①确定用例输入数据：依据异常控制行为原因，明确相应接口数据的取值规则，以选取确定数值或者等价类数值作为SOTIF测试用例输入数据。

②确定用例约束条件：依据异常控制行为原因，选取相应功能执行逻辑、运行场景或外部环境等，作为SOTIF测试用例执行的约束条件。

③确定用例预期输出与通过准则：依据机载软件SOTIF要求和异常控制行为，明确相应输出数据的取值规则以确定测试用例的预期输出，即软件异常控制行为不发生或者得到有效控制。一般来说，用例执行通过准则应与预期输出完全一致。但若危险等级较低，则通过准则也可适当放宽。

④确定SOTIF测试用例格式：依据外部接口控制文件（ICD），确定输入接口数据的通信格式。进而依据接口通信格式和相应的数据取值内容，拼装成可执行的软件SOTIF测试用例。

5 典型应用

本文针对机轮转弯控制软件，开展SOTIF 分析应用，验证本文研究成果的可行性与有效性。

（1）机载软件SOTIF建模。

首先，依据软件需求，建立机载软件的系统控制视图模型，如图5 所示。

图5 系统控制视图模型实例

依据上述系统控制结构模型，对转弯控制软件的相关需求描述如下。

①控制器：机轮转弯控制系统。

②执行机构：机轮装置。

③源设备：机轮角度传感器。

④控制过程中的外部输入输出数据（包含控制反馈信号），外部输入输出数据列表如表2 所示。

表2 外部输入输出数据列表

⑤控制过程：软件依据上位机传输的输入数据“目标角度”（由人员设置）和机轮装置反馈的输入数据“机轮角度”（来自于传感器）进行实时闭环控制解算，输出“转弯控制指令”至机轮装置，驱动机轮装置运动到“目标角度”。同时，输出“显示角度”至上位机显示。

（2）机载软件系统危险分析。

依据系统控制视图模型，机载软件系统的功能危险分析如下。

①H-1：机轮转弯速度过快，导致飞机侧翻。

②H-2：机轮到达指定角度位置的时间过久，导致飞机冲出跑道

针对识别的系统危险，参考STAMP 模型理论，确定相关的安全约束条件如下。

①SC-1：软件必须控制机轮转弯速度小于2°／s（对应危险H-1）。

②SC-2：软件必须在规定的时间内（50 s），控制机轮转动到规定位置（对应危险H-2）。

依据上述系统控制视图模型，对安全约束条件进一步细化如下。

①SC-11：软件必须控制机轮转弯速度小于2°／s（对应危险H-1），即机轮装置反馈的“机轮角度”取值变化率应小于2°／s。

②SC-22：软件必须在规定的时间内（50 s），控制机轮转动到规定位置（对应危险H-2），即机轮装置反馈的“机轮角度”取值应与“目标角度”相一致。

（3）异常控制行为识别。

依据3.2 节中列举的基于故障树的异常控制行为识别方法，对两个安全约束条件进行分析，识别导致危险的可能异常控制行为如下。

①针对安全约束条件SC-1（软件必须控制机轮转弯速度小于2°／s），识别的异常控制行为如表3 所示。

表3 SC-1 的异常控制行为识别

②针对安全约束条件SC-2（软件必须在规定的50 s时间内，控制机轮转动到规定位置），识别的异常控制行为UCA如表4 所示。

表4 SC-2 的异常控制行为识别

（4）异常控制行为原因分析。

依据3.3 节中的基于影响因素的异常控制行为原因分析方法，对上述异常控制行为的原因分析如下。

①针对异常控制行为UCA.1.1，识别原因如表5所示。

表5 UCA.1.1 的原因分析

②针对异常控制行为UCA.1.2，识别原因如表6所示。

表6 UCA.1.2 的原因分析

③针对异常控制行为UCA.2.1，识别原因如表7所示。

表7 UCA.2.1 的原因分析

④针对异常控制行为UCA.2.2，识别原因如表8所示。

表8 UCA.2.2 的原因分析

6 结束语

本文参考ISO 21448 标准中的SOTIF实施框架和汽车领域工程经验，借助功能危险分析、故障树模型、STAMP模型、场景驱动等理论方法，针对机载软件运行特征构建SOTIF分析验证工作的实施过程，包括机载软件SOTIF 建模、系统功能危险分析、基于危险分析的系统风险评估、复杂场景下的机载软件SOTIF 影响因素识别、基于故障树的软件异常控制行为识别、基于影响因素的异常控制行为原因分析、机载软件SOTIF测试场景构建、场景驱动的机载软件SOTIF 测试用例设计等内容。

上述研究成果及其初步工程应用结果表明，面向机载软件的SOTIF分析验证过程及方法可以推进SOTIF技术在机载软件研制过程中的推广与应用，形成符合标准要求、适用于复杂系统的机载软件SOTIF 分析验证能力，避免FMEA、FTA等安全性分析技术多关注非法数据、通信中断等单点失效的不足，支撑研制人员充分识别机载软件运行过程中的软硬耦合冲突、人机交互异常、场景切换异常等复杂失效模式。同时，支持测试人员面向构建机载软件的SOTIF 测试场景，实现对软硬耦合、控制过程、外部激励、人机交互、状态切换等复杂场景的有效模拟或仿真，提升软件测试效率和质量，最终确保机载软件能够满足高安全、高可靠的研制要求。

需要说明的是，本文主要目标是建立SOTIF 在机载软件研制中的完整实施过程，为后续的相关技术研究与工程应用提供参考。但限于篇幅，本文重点给出可能的技术方案和初步的工程示例，还需在未来工作中进行更加深入的技术研究与工程应用。