CN109783870B - 一种基于形式化验证的人机交互风险场景识别方法 - Google Patents

Abstract

一种基于形式化验证的人机交互风险场景识别方法，步骤如下：一：对复杂人机交互推演过程进行建模，形成通用的人机交互形式化推演模型；二：建立考虑人误的任务形式化模型自动推演模板，考虑异常态的系统、人机界面和环境形式化模型自动推演模板；三：确定人机系统安全属性表达式，得到人机系统安全规约；四：借助模型检查工具完成风险场景路径的排查工作；五：采用定性比对方法对演化路径的可能性进行评价，识别发生可能性相对高的风险场景路径；通过以上步骤，本发明采用人机交互形式化方法，解决了人机系统异常态交互风险场景的完备性排查的问题，达到了自动完成风险场景路径完备枚举的效果，并通过定性比对方法实现了关键风险场景的识别。

Description

一种基于形式化验证的人机交互风险场景识别方法

技术领域

本发明提供一种基于形式化验证的人机交互风险场景识别方法，它是一种可靠性设计与人因工程交叉技术领域的人机系统安全性分析方法，注重解决人机系统异常态交互风险场景的完备性排查与关键危险路径识别的问题。

背景技术

人机系统重大安全事故往往是任务进程中人、机、环各要素耦合演化的结果，其过程可以用风险场景进行刻画。由于人机系统的复杂特性，导致风险场景路径分支很多、耦合关系复杂；同时，人机交互过程的任务特征、信息特征和绩效形成因子的变化与历史交互进程相关，所以人机交互风险场景的完备性排查与关键危险路径识别面临极大挑战。

在研制阶段开展人机交互风险场景推演与识别，是保证人机系统安全性的重要技术手段。当前人机系统安全性分析方法中，事件树、故障树等事件逻辑的方法本质上是“以‘形而上’的解构思想及因果链”为基础的静态逻辑分析，在处理复杂交互过程时表现出明显的不足，难以事无巨细地梳理人机系统各要素的逻辑关系，对异常事件组合和时序想不清、想不全；而且这种方法侧重关注可观察的故障模式和人误模式，对人机交互认知耦合作用考虑不足。事件树仿真、多主体仿真等仿真的方法提供了强大的人机交互描述能力，并可以通过计算机自动获取风险信息，但是该方法建模工作量巨大，对人、机、环设计细节要求高，因而难以在设计初期展开；同时，该方法往往针对具体应用场景建模，模型难以校核和验证，通用性和可移植性差。功能共振分析、系统事故理论建模和过程分析等系统化方法分析层次高，对人机系统异常态耦合行为的细节描述不足，不利于支持具体的人机系统设计改进措施，且模型的构建与分析人员的知识水平关系密切，模型一致性差。此外，这些研究在排查风险场景方面主要依靠分析人员依据专业经验进行头脑风暴式推断，或者通过运行仿真模型“大海捞针”式地发现问题，难以遍历系统所有可能的异常态组合和人机交互序列，导致风险场景分析可能出现遗漏，也就可能给人机系统留下不安全隐患，而人机交互形式化方法能有效克服这一缺陷，完备排查人机交互演化路径，支持风险场景推演。

发明内容

1、目的

本发明提供一种基于形式化验证的人机交互风险场景识别方法，注重解决人机系统异常态交互风险场景的完备性排查与关键危险路径识别的问题。

2、技术方案

本发明是一种基于形式化验证的人机交互风险场景识别方法，该方法包括如下五个步骤：

步骤一：采用形式化方法对复杂人机交互推演过程进行建模，形成通用的人机交互形式化推演模型，建模框架如图1所示，主要包括考虑人误的任务形式化建模，考虑异常态的系统、人机界面、环境形式化建模，人机交互形式化推演建模；

步骤二：将人机交互形式化推演模型映射为各种场景下可执行的人机交互自动推演模板，建立考虑人误的任务形式化模型自动推演模板，考虑异常态的系统、人机界面、环境形式化模型自动推演模板；

步骤三：描述人机系统安全属性，确定人机系统安全属性表达式，得到人机系统安全规约；

步骤四：借助模型检查工具简单协议元语言解释器(Simple PromelaInterpreter,SPIN)完成风险场景路径的排查工作；

步骤五：采用定性比对方法对演化路径的可能性进行评价，识别发生可能性相对较高的风险场景路径。

通过以上步骤，采用人机交互形式化方法，解决了人机系统异常态交互风险场景的完备性排查的问题，达到了自动完成风险场景路径完备枚举的效果，并通过定性比对方法实现了关键风险场景的识别。

其中，在步骤一中所述的“考虑人误的任务形式化建模，考虑异常态的系统、人机界面、环境形式化建模，人机交互形式化推演建模”，其内容说明如下：

(1)考虑人误的任务形式化建模

基于任务模型的层次化结构，定义适用于描述任务执行过程的形式化语法和语义，支持任务模型的形式化描述；

A.定义任务形式化模型语法

定义1：人机交互任务模型是一个四元组HTA＝(T,O,R,t₀)，其中

T＝{t₁,t₂,…,t_n,…}是顶任务和子任务的集合；

O＝{o₁,o₂,…,o_n,…}是底层操作的集合；

R＝T→T∪O是任务分解(父任务分解为子任务或操作)；

t₀∈T是顶层任务，即人机交互所要实现的目标；

不失一般性，记人机交互任务模型一中间任务t的子任务集合为

subtask(t)＝{t₁,…,t_i-1,t_i,t_i+1,…,t_n}，则t是

的父任务，记为parent(t_i)＝t，i＝1,…,n；对有限串行任务序列T＝{t₁,…,t_i-1,t_i,t_i+1,…,t_n}，记任务序列中第一个任务和最后一个任务分别为first(T)＝t₁，last(T)＝t_n；同时，对任务序列中一任务t_i，记其前一个任务为

若i＝1，则记

定义2：顶任务/子任务是一个五元组T＝(ID_tsk,S_tsk,G_tsk,I_tsk,R_tsk)，其中，

ID_tsk是顶任务/子任务的唯一标示；

S_tsk＝{Ready,Executing,Done}是任务的执行状态，含义分别为就绪、执行、完成；

G_tsk＝(precondition,postcondition,repeatcondition)是一个三元组，表示顶任务/子任务执行状态转移的执行条件，含义分别为前置条件、后置条件、重复条件；

I_tsk＝(startcondition,endcondition,resetcondition)是一个三元组，表示顶任务/子任务执行状态转移的触发条件，含义分别为开始条件、结束条件、重置条件；

R_tsk＝S_tsk×G_tsk×I_tsk→S_tsk是顶任务/子任务的执行状态转移函数，定义为R_tsk(s_tsk,g_tsk,i_tsk)＝s′_tsk，当且仅当g_tsk∈G_tsk和i_tsk∈I_tsk为真时，s_tsk∈S_tsk转移到下一个状态s′_tsk∈S_tsk；

定义3：操作是一个六元组O＝(ID_op,S_op,I_op,R_op,HE,R_e)，其中，

ID_op是操作的唯一标示；

S_op＝{Ready,Executing,Done}是操作的执行状态，含义为就绪、执行、完成；

I_op＝(startcondition,resetcondition)是一个二元组，表示操作执行状态转移的触发条件，含义分别为开始条件、重置条件；

R_op＝S_op×I_op→S_op是操作的执行状态转移关系，定义为R_op(s_op,g_op,i_op)＝s′_op，当且仅当g_op∈G_op和i_op∈I_op为真时，s_op∈S_op转移到下一个状态s′_op∈S_op；

是操作变量，包含空输出，正常输出和n种人误模式；R_e＝S_op×HE→HE是操作变量函数，定义为R_e(s_op,h)＝h′，当且仅当s_op∈S_op满足时，h∈HE转移到h′∈HE；

R_e表示，当操作处于执行(Executing)状态时，该操作输出正常态或者各种异常操作；当操作处于就绪(Ready)或者完成(Done)状态时，该操作无输出。

根据上述定义，人机交互任务和操作的定义可以表示为图2(a)、(b)所示；

根据层次任务分析，任务/操作间的转移关系定义为顺序、并行、决策、自由组合顺序、自由组合并行、重复六种；其中，顺序、并行、决策、自由组合顺序、自由组合并行五种关系直接描述上级父任务与下级子任务的关系，因此又称为任务分解算子；重复关系主要描述任务的循环执行情况，与任务层次性关系不大，因此定义为执行条件；任务操作分解的详细规则定义如表1所示；

表1任务分解算子定义

分解规则	符号	含义
			顺序	ord	按顺序依次执行
并行	par	同时执行
			决策	xor	选择其中一项执行
自由组合顺序	opt_seq	无顺序执行满足前提条件的所有任务
			自由组合并行	opt_par	同时执行满足前提条件的所有任务

上列“表1”改成以叙述方式表达如下：

任务分解算子分为5种类别，每一种具有不同的符号表示与含义，具体为：顺序任务分解算子的符号为ord，含义为按顺序依次执行；并行任务分解算子的符号为par，含义为同时执行；决策任务分解算子的符号为xor，含义为选择其中一项执行；自由组合顺序任务分解算子的符号为opt_seq，含义为无顺序执行满足前提条件的所有任务；自由组合并行任务分解算子的符号为opt_par，含义为同时执行满足前提条件的所有任务；

因此，任务分解可以表示为：

B.定义任务形式化模型语义

任务形式化模型的语义主要是触发条件的形式化语义，其主要描述任务如何执行；由于触发条件的本质是控制局部的任务执行时序，而任务分解算子的本质是控制全局的任务执行时序，因此二者有着天然的耦合关系；为了理清不同任务的执行时序关系，需要从触发条件和任务分解算子两个维度严格进行定义任务/操作的状态迁移关系；

(2)考虑异常态的系统形式化建模

系统形式化建模的主要任务是描述系统各种状态(包括正常运行模式和故障模式)之间的切换关系；

系统运行模式是指根据任务要求和技术文档，将系统可能的运行状态进行归纳并解耦成一系列离散状态，每种状态称为一个运行模式。模式之间既可以通过人的控制进行切换，也可以发生自动切换，切换发生时可能需要满足一定的切换条件(包括触发条件和前提条件)。系统运行模式分析的结果可以用表2进行记录；

表2系统运行模式切换关系分析表

系统运行模式	运行模式1	运行模式2	运行模式3	…
					运行模式1	——
运行模式2		——
					运行模式3			——
…				——

附注：该表表示横向所示运行模式切换至纵向所示运行模式的触发条件和前提条件。当系统在某运行模式运行且不满足所有的切换条件时，认为系统在该运行模式停留；

上列“表2”改成以叙述方式表达如下：

系统的运行状态可以划分为若干种运行模式，不同的运行模式之间可以进行切换，但切换发生时可能需要满足一定的切换条件(包括触发条件和前提条件)，具体为：当系统处于运行模式1且满足一定切换条件时，系统的运行状态可切换至运行模式2或运行模式3或…当系统处于运行模式2且满足一定切换条件时，系统的运行状态可切换至运行模式1或运行模式3或…当系统处于运行模式3且满足一定切换条件时，系统的运行状态可切换至运行模式1或运行模式2或…当系统在某运行模式运行且不满足所有的切换条件时，认为系统在该运行模式停留；

系统故障模式分析从功能角度出发，重点关注与具体任务场景相关的功能。系统功能分析采用树状层级结构，从系统层出发，逐层进行功能分解，分解颗粒度以和系统运行模式相洽为止。所谓“相洽”指功能故障模式能够不歧义地引发系统运行模式切换。此外，故障模式需要和特定的信息相关联(告警或反映故障特征的任务信息)，系统故障模式分析的结果可以用表3进行记录；

表3系统运行模式与故障模式耦合分析表

上列“表3”改成以叙述方式表达如下：

系统故障模式分析从系统功能角度出发，首先将系统功能逐层分解为功能1、功能2…然后分析每种功能包含的故障模式，如故障模式1、故障模式2…这些功能故障模式能够引发系统运行模式切换，此外，故障模式需要和特定的信息相关联(告警或反映故障特征的任务信息)；

系统形式化建模包括三个步骤，具体如下：

A.构建正常情况下系统运行模式状态迁移模型

该步骤的基本思路是将表2中记录的状态迁移关系直接映射为扩展状态迁移系统(Extended Transition System,ETS)；下面给出几个定义；

定义1：一个状态迁移系统(Transition System,TS)是一个四元组TS＝(S,s₀,A,Δ)，其中，

S＝{s₁,s₂,…,s_n,…}表示系统所有可能的状态集合；

s₀∈S是S的初始状态；

A＝{a₁,a₂,a₃,…}表示迁移动作集；

Δ∈S×A×S称为状态迁移关系，它描述了状态在动作集的触发下由一个状态转移到另一个状态的行为，通常采用符号

表示迁移关系(s,a,s′)∈A；

定义2：给定一个TS，对其中某个状态s和操作a，状态s在执行操作a的后继状态定义为：

可见，Post(s,a)包含了在状态s时执行操作a的所能到达的所有状态；

可见，Post(s)包含了在状态s时执行任何操作所能到达的所有状态；

定义3：一个TS被认为是确定的，当且仅当

a.|s₀|＝1，即仅有一个初始状态；

b.

对所有操作和状态，其后继状态不超过一个；

否则，该TS被认为是非确定的；

定义4：一个ETS是一个五元组ETS＝(S,s₀,A,Δ,G)，其中，

S＝{s₁,s₂,…,s_n,…}表示系统所有可能的状态集合；

s₀∈S是S的初始状态；

A＝{a₁,a₂,a₃,…}表示迁移动作集；

G＝{g₁,g₂,…,g_n,…}表示系统状态迁移的前提条件；

Δ∈S×A×S称为状态迁移关系，对一个迁移δ＝(s,g,a,s′)∈Δ，称s∈S为源状态，g∈G为前提条件，a∈A为迁移动作，s′∈S为目标状态；通常用符号

表示δ；

定义5：令C＝{ETS¹,ETS²,…,ETSⁿ}表示由多个ETS构成的迁移系统网络，且

令

对某个迁移动作

定义

则C的复合ETS¹×ETS²×…×ETSⁿ定义为一个ETS＝(S,s₀,A,Δ,G)，其中

S＝S¹×S²×…×Sⁿ；

A＝A¹∪A²∪…∪Aⁿ；

定义为δ＝((s₁,…s_n),g,a,(s′₁,…s′_n))∈Δ，当且仅当

有s_i＝s′_i；且

始终存在一个状态迁移关系(s_i,g_i,a,s′_i)使得g＝^_i∈E(a)g_i；

G＝G¹∪G²∪…∪Gⁿ；

状态迁移图是一个带节点和有向边的有向图，有向边表示迁移，迁移动作和前提条件作为迁移条件出现在有向边的标记上，用a:[g]格式进行标记；ETS可以采用状态迁移图表达，典型的状态迁移图如图3所示；

根据以上定义，假定分析人员识别出系统共n种运行模式，将其依次编号为s₁,s₂,…,s_n；一般的，系统运行模式状态迁移有两种基本触发方法：人的操作/环境扰动(+前提条件)触发，系统自动(+前提条件)触发；不失一般性，当系统运行模式从s_i迁移到s_j(1≤i＜j≤n)，记状态迁移关系为δ_ij＝(s_i,g_ij,a_ij,s_j)；其中，当

代表人的操作触发，可用通过任务形式化模型的共享变量获得；当

代表系统自动触发；则可生成正常情况下系统运行模式状态迁移模型为

B.构建系统各功能的故障模型

假设系统各功能故障的发生是随机、互斥、不可逆的，且可以在人机交互过程的任何时刻发生；模型构建的基本思路是将表3中各功能故障模式映射为非确定性扩展状态迁移系统(Extended Transition System,ETS)；假定分析人员识别出系统共m个功能，每个功能对应有m_i种可能故障模式(状态)；不失一般性，将系统的功能故障模式编号为

(1≤i≤m)，且记系统功能正常态为f_i,0(1≤i≤m)；系统故障模型就是系统从功能正常态f_i,0随机迁移到一个故障模式f_i,j(1≤j≤m_i)；则可生成第i个功能对应的系统故障状态迁移模型为

C.构建系统形式化模型

将系统故障所导致的系统运行模式状态迁移关系扩展到正常情况下系统运行模式状态迁移模型中，系统故障所导致的系统运行模式状态迁移模型的本质是以故障模式f_k,l作为迁移动作对M⁰的迁移关系Δ⁰进行补充；表2记录的状态迁移关系，当系统运行模式因为故障f_k,l(1≤k≤m，1≤l≤m_k)从s_i迁移到s_j(1≤i＜j≤n)，记状态迁移关系为δ_ij,kl＝(s_i,f_k,l,s_j)时，将该迁移关系增添至M⁰中，并称M⁰更新后得到的状态迁移模型

为考虑故障的系统运行模式状态迁移模型。

对考虑故障的系统运行模式状态迁移模型和系统故障状态迁移模型进行复合操作，即可得到系统状态迁移模型M＝(S,s₀,A,Δ,G)，即

式中，

满足δ＝((s₁,s₂,…,s_m+1),g,a,(s′₁,s′₂,…,s′_m+1))∈Δ，使得当且仅当

时，有s_i＝s′_i，且当且仅当

时，总存在迁移(s_i,g_i,a,s′_i)满足g＝∧_i∈E(a)g_i；

其中，

(3)考虑异常态的人机界面形式化建模

人机界面形式化建模的主要任务是描述人能否能及时、正常地接收信息或者对系统的控制是否被阻止；人机界面模型相当于对提供给人的正常信息进行过滤和“拉偏”，即分析主要考虑可能出现的虚警、漏警、任务信息错误、任务信息不完整、任务信息不及时、通信信息错误、通信信息不完整、通信信息不及时等异常信息模式；理论上，系统提供给人的任务信息、告警信息以及通信信息均可能出现异常态，但是这样可能会导致模型状态规模膨胀；因此，可以根据实际情况，针对性地考虑某些故障相关的异常信息模式，这些异常信息模式需要同任务模型接洽，人机界面模型的分析结果可以通过表4进行记录；

表4人机界面信息异常态分析表

上列“表4”改成以叙述方式表达如下：

人机界面信息包含任务信息、告警信息、通信信息三种类别，每种类别的信息又包含若干条具体信息，如任务信息包含任务信息1、任务信息2…告警信息包含告警信息1、告警信息2…通信信息包含通信信息1、通信信息2…对于每条具体信息，需要分析可能出现的异常信息模式，如虚警、漏警、任务信息错误、任务信息不完整、任务信息不及时、通信信息错误、通信信息不完整、通信信息不及时等异常信息模式；

人机界面建模首先将表4中任务信息、告警信息或者通信信息分别映射为系统形式化模型中的状态量，与其对应的信息异常模式等价于系统模型中的故障模式，因此其建模方法等同于系统各功能的故障模型；不失一般性，将表4所涉及的信息依次编号为

其中I_i对应的信息异常模式编号为Iv₁,Iv₂,Iv₃(对应信息不正确、不完整、不及时)；显然，I_i∈S，其中S是M＝(S,s₀,A,Δ,G)中的状态集合；设第i个信息对应的异常状态迁移模型为

则MIⁱ的生成算法与系统故障模型类似，显然，该迁移系统的迁移动作集合和前提条件集合均为空集；

令

即得到基于ETS描述的人机界面形式化模型。

(4)考虑异常态的环境形式化建模

环境形式化建模的目的是描述在任务执行过程中可能影响系统运行或诱发人为失误的环境变量的状态变化；环境对人机系统的影响主要包括影响系统运行模式切换、影响任务执行条件、影响人的绩效形成因子；环境模型的状态量需要同系统模型、任务模型和PSFs相匹配；环境模型分析结果可以通过表5进行记录；

表5环境扰动分析表

环境扰动因素	扰动描述	对系统模型的影响	对任务模型的影响	对PSFs的影响
					扰动因素1
扰动因素2
					…

上列“表5”改成以叙述方式表达如下：

环境扰动分析需要对各个环境扰动因素如扰动因素1、扰动因素2…的状态变化进行描述，此外，还需分析各个环境扰动因素对系统运行模式切换、任务执行条件、人的绩效形成因子的影响；

环境形式化模型有两种形式，其一是直接设定环境状态，在人机交互过程中不再发生变化；其二是类似系统运行模式状态迁移模型，将环境的各种扰动模式及正常情况抽象为离散状态量，然后建立这些状态量之间的转移关系；

设环境模型为Env＝(E,e₀,A_E,Δ_E,G_E)，其中E是环境的各种扰动状态与正常状态的集合；e₀为初始状态；A_E为环境状态迁移动作集，即环境状态迁移的触发状态，由于从扰动的角度构建环境模型，所以认为A_E为空；Δ_E是环境状态迁移关系，一般是随机迁移，即δ_e＝(e_i,e_j)∈Δ_E，相应的，G_E为空。

Env＝(E,e₀,A_E,Δ_E,G_E)与系统故障状态迁移模型类似，该模型即是基于ETS描述的环境形式化模型；

(5)人机交互形式化推演建模

上述过程根据任务模型和系统/人机界面/环境模型的特点分别构建了形式化模型，但是这两种形式化描述不尽相同；考虑到任务形式化模型本质上是任务/操作执行状态变化的描述，所以能将其映射为ETS；其基本思想是将任务或操作的状态等价为ETS的状态，将任务或操作的状态迁移的触发条件等价为ETS的迁移动作集，将任务的执行条件等价为ETS的前提条件；则生成基于ETS的任务模型为

因此，通过状态迁移系统，可以得到一致的任务、系统、人机界面和环境模型形式化描述；进一步地，令MMI＝(S,s₀,A,Δ,G)＝T×M×MI×Env，MMI是基于ETS构建的形式化模型，通过严格定义的状态迁移关系实现人机交互行为的推演，因此将MMI称为人机交互形式化推演模型；

如果直接采用ETS的形式描述人机交互行为，会导致模型抽象程度高，可读性差，不易理解；而根据可读性强、易于理解的可视化任务分析和状态迁移图可以无歧义地得到人机交互形式化推演模型，因此可采用可视化任务分析和状态迁移图的方式对人机系统进行形式化建模。

其中，在步骤二中所述的“建立考虑人误的任务形式化模型自动推演模板，考虑异常态的系统、人机界面、环境形式化模型自动推演模板”，其内容说明如下：

复杂人机交互形式化验证方法的核心，是将人机交互形式化推演模型语义映射为各种场景下可执行的自动推演模板，然后借助计算机完成风险场景路径的排查工作；由于本文采纳简单协议元语言解释器(Simple Promela Interpreter,SPIN)作为模型检查工具，协议元语言(Protocol Meta Language,Promela)是SPIN的模型输入语言，因此基于Promela语言构建自动推演模板；

(1)考虑人误的任务形式化模型自动推演模板

A.正常操作执行自动推演模板

首先考察任务模型底层的操作执行的自动推演模板，不失一般性，一个任务(Task)被分解为两个操作(Operation 1和Operation 2)，操作之间的关系包括顺序、并行、决策、自由组合顺序、自由组合并行五种。根据形式化语义，操作关系中顺序和自由组合顺序、并行和自由组合并行是重合的，因此它们的自动推演模板也是一致的；此外，由于操作的输出——操作变量属于共享变量，因此需要定义控制通道：

chanctrl＝[0]of{byte}

式中，通道大小为0，表示向通道发送和接收数据必须是同时发生的；byte表示操作的ID，用于区分不同的操作；任务模型中人通过该通道发出具体动作。基于此，则可建立操作语义的自动推演模板；

当考虑时间窗口时，需要记录各操作所消耗的时间；具体地，需要将连续的时间离散成一系列单位时间点，并额外构造全局时间变量和时间通道，用于记录任务执行的时间开销，如下式所示；每当一项操作完成，就通过时间通道在全局时间变量上记录该操作花费的时间；时间通道在描述操作执行的所需时间与可用时间关系方面很重要，当出现延迟失误时，需要时间通道量化延迟对任务完成的影响；

chan stopwatch＝[0]of{byte}

B.正常任务执行自动推演模板

其次考察子任务分解相关的自动推演模板，不失一般性，顶任务(Parent)被分解为两个子任务(Task 1和Task 2)，任务的执行需要满足前提条件(precondition)，任务的结束需要满足后置条件(postcondition)；根据层次任务分析，子任务并不直接作用于系统，因此，任务进程中没有控制通道。基于此，则可建立子任务语义的自动推演模板；

C.人为失误自动推演模板

根据人机交互任务分析，人误模式是操作层的属性，因此需要在操作自动推演模板的基础上定义人误模式自动推演模板；一般地，由于人误模式本身可以视为操作输出的变异，而且同一操作不同人误模式之间是相互独立的，因此可以认为各种人误模式和正常操作之间是“亦或关系”，即当操作处于执行状态时，选择正常操作和人误模式中任意一种作为输出送入控制通道；

人为失误包括时机和精度两个维度，前者主要是不及时，后者可视为某时间点上操作不正确、不完整；在自动推演模板构造上，“不及时”通过单位时间点上重复空操作来表征，当出现不及时人误模式时，记录1单位时间开销后，跳过操作输出至操作执行起点；“操作不正确”和“不完整”通过具体操作命令体现；假设操作Operation对应人误模式分别为HEM 1、HEM 2、HEM 3，且其中HEM3为延迟失误，任务需求时间为t，则可建立考虑人误模式的操作自动推演机制；

需要指出的是，原则上，只要人误概率不为零，该人误均可能发生；但是人为失误具有路径依赖性，某种情形下路径依赖对人为失误的影响是全相关时，其发生概率为1；这样，人误模式自动推演模板中其他人误就不会发生；由于这种路径依赖通过其他事件或信息的变异性体现，因此需要在考虑人误模式的操作自动推演机制中人误操作亦或关系前加入非全相关判断条件；

(2)考虑异常态的系统形式化模型自动推演模板

系统形式化模型包括考虑故障的系统运行模式状态迁移模型和系统故障状态迁移模型；考虑故障的系统运行模式状态迁移模型将系统运行模式映射为离散Promela进程的状态，状态迁移关系有两种：操作员控制和自动切换；其中，操作员控制需与任务模型相结合，即系统从控制通道中接收人的操作，作为系统运行模式切换的触发条件，若该运行模式的前提条件满足时，进行切换；自动切换是系统运行模式满足给定前提条件(故障或环境扰动状态)时，自动切换到其他运行模式。基于此，则可建立典型考虑故障的系统运行模式状态迁移模型对应的自动推演模板；

由于系统故障状态迁移模型中迁移动作集和前提条件集均是空集，状态迁移关系退化为随机迁移；系统故障状态迁移模型自动推演模板成为非循环随机执行序列；假设系统共有m种故障模式，以状态变量sf表示各种故障模式，其状态为0表示正常，状态1～m表示第1～第m种故障模式，则可建立其自动推演模板；

(3)考虑异常态的人机界面形式化模型自动推演模板

人机界面模形式化模型的自动推演模板，主要是对系统的输出信息和系统的输入信息进行“过滤”，模拟虚警、漏警、信息缺失、信息不正确、操作无效等人机交互异常情况；由于人需要在任务过程中不断的获取信息、输入操作，因此采用循环机制构建人机界面自动推演模板；

在实际案例分析时，理论上任何告警信息(例如发动机故障、舵机卡滞故障等)都会出现虚警和漏警异常态，任何任务信息和通讯信息(例如高度信息、速度信息、塔台指令等)都可能出现信息缺失、信息不正确等异常模式，任何操作都可能因人机界面故障而被阻止；但是，这种事无巨细地推演对于形式化验证方法可能造成维度灾难，因此可以根据具体应用场景针对性的选择告警信息、任务信息和通讯信息进行“过滤”处理；

(4)考虑异常态的环境形式化模型自动推演模板

将环境形式化模型考虑为环境扰动模型，即将环境模型作为影响因素纳入其他模型中，而不考虑环境模型与其他模型的交互；其自动推演有两种模板，其一是直接设定背景环境变量；其二是类似系统运行模式自动推演模板，考虑不同环境状态之间切换。

其中，在步骤三中所述的“描述人机系统安全属性，确定人机系统安全属性表达式，得到人机系统安全规约”，其内容说明如下：

人机系统安全规约是利用具有精确语义的形式化语言描述系统属性和安全边界，用于支持系统安全属性自动化验证；

给定模型的形式规约从识别使得模型为真的原子命题开始；关系结构(Kripke)提供了一种利用标记函数来标记各状态下使得该状态为true的变量集合(原子命题)，因此引入Kripke结构对ETS进行扩展；

定义1：一个Kripke结构扩展标记迁移系统是一个三元组(ETS,AP,L)，其中，

ETS＝(S,s₀,A,Δ,G)是一个扩展状态迁移系统；

AP＝{a,b,c,…}表示原子命题集；

L:S→2^AP称为标签函数；

将人机交互形式化推演模型MMI扩展为Kripke结构，即(MMI,AP,L)；模型的一个执行序列可以表示为r＝＜s₀,(a₁,g₁),s₁,(a₂,g₂),…＞；式中，s₀,s₁,…∈S，a₁,a₂,…∈A，g₁,g₂,…∈G；定义执行序列r的路径为Trace(r)＝<L(s₀),L(s₁),L(s₂),…>；令Trace(MMI,AP,L)表示Kripke结构的人机交互形式化推演模型MMI的演化路径的集合，

则σ＝<AP₀,AP₁,AP₂…>∈Trace(MMI,AP,L)表示Trace(MMI,AP,L)中的一条路径，且记σ[i]＝<AP_i,AP_i+1,…>表示从第i个时刻(第i个执行序列)开始的路径；下面，就可以利用时态逻辑描述人机系统安全属性；

时态逻辑是在逻辑框架中采用一组规则来表达和推理时间的符号系统，其中时间通过一组有序的状态序列表示；在形式化验证的应用方面，一个时态逻辑公式由关于模型变量和模态算子的布尔命题组成；模态算子通常指定命题之间时序的关系；最常见的时态逻辑包括线性时序逻辑(Linear-time Temporal Logic,LTL)、计算树逻辑(ComputationTree Logic,CTL)，其模态算子如表6所示；

表6时态逻辑常用模态算子

附注：路径算子为CTL特有，ψ表示路径。

上列“表6”改成以叙述方式表达如下：

时态逻辑常用模态算子分为路径算子与时态算子两类：路径算子包含All、Exists两种操作，其符号分别为A_ψ、E_ψ，其含义分别为全称路径量词、存在路径量词；时态算子包含NeXt、Future、Global、Unitl四种操作，其符号分别为X_ψ/○ψ、Fψ/◇ψ、Gψ/□ψ、

其含义分别为下一状态、未来某个状态、未来所有状态、直到…都；

基于巴科斯范式(Backus-Naur Form,BNF)描述的LTL的语法如下式所示：

式中，p是原子命题，φ是定义的公式；

在人机交互风险场景分析中，一般采用(Fφ)的形式或者(Gφ)的形式，前者表达了希望人机系统最终能达到的状态的约束；后者表达了系统人机系统始终保持某个属性的约束；

这样，结合Kripke结构的MMI，LTL的语义可以表示为：

σ|＝Fφifthereexists i≥0such thatσ[i]|＝φ

σ|＝Gφif for all i≥0,σ[i]|＝φ

式中，φ是由分析人员确定的人机系统安全属性的表达式；利用该式就能得到人机系统的安全规约；

进一步，将LTL公式转化为Promela语言，语法形式如下式所示：

ltl::＝ltl＜name＞'{'formula'}'

式中，formula一般是由分析人员事先确定的人机系统危险状态的布尔表达式。

其中，在步骤四中所述的“借助模型检查工具SPIN完成风险场景路径的排查工作”，其作法说明如下：

人机交互风险场景推演就是在自动推演模板的基础上，利用SPIN模型检查工具排查危险路径；

SPIN模型检查工具完成给定模型的形式验证后能够返回丰富的信息，包括危险路径总数、模型状态变化序列以及基于通道信息传递的模拟运行图；基于这些信息，分析人员就能够开展危险路径的风险评估，支持风险场景识别；

风险场景路径可以记录为<Event 1,Event 2,…,Event n>；考虑到风险场景事件包含人、机、环状态的变化，为了清楚地表达人机系统不同组成要素在事件序列中的时序关系和序列，提出可视化的路径表示方式，如图4所示；图中，环境状态变化采用六边形表示，系统/人机界面状态改变采用椭圆表示，人状态变化采用方框表示；而故障和人误则采用虚线进行标识，使之同系统和正常操作进行区分；图中箭头表示路径时序关系。

其中，在步骤五中所述的“采用定性比对方法对演化路径的可能性进行评价，识别发生可能性相对较高的风险场景路径”，其作法说明如下：

异常事件对比方法，对推演得到的路径的可能性大小进行对比识别，其基本思想是比较路径中等价小概率异常事件(故障、人误)的个数；若某条路径上小概率异常事件数量越多，则该路径越不可能发生；具体而言，首先统计路径中异常事件(故障、人误和扰动)的数量；然后对异常事件赋予风险权重，风险权重表征了异常事件发生可能性的大小；最后统计每条路径的权重总和进行排序，权重越小，说明该路径发生的可能性越大；

在进行风险权重赋值时，一般不加区分地对异常事件赋予风险权重为1(异常事件概率一般都很小)，但需要对如下三种情况进行调整：

(1)具有路径依赖性的人误事件：具有路径依赖性的人误事件的发生与人机交互路径相关，即该人误受到演化路径上前面事件的诱发，例如，当出现漏警故障事件后，出现延迟发生告警人误事件的可能性就较大；因此，该人误事件就不能归结为小概率事件；此外，当路径中前后两个事件呈低相关(不含)以上路径依赖相关关系时，其人误概率至少为0.14，相对名义人误概率或故障概率而言比较大，因此本文认为此时不宜将其统计为小概率事件；

(2)当多次出现没有路径依赖性的相同异常事件，记为

时，第一次出现的该异常事件

的权重为1，第二次出现的该异常事件

的权重为2，依次类推；

(3)当出现执行延迟(不及时)时，根据延迟时间越长，发生概率越低的原则，认为每多延迟1单位时间，风险权重增加0.5。

3、本发明的工效、优点

该方法基于人机交互失误机理建立了人机交互形式化推演模型，并将其转化为人机交互自动推演模板，利用依托于计算机工具的形式化验证技术自动完成风险场景路径的完备枚举，并通过定性比对方法实现了关键风险场景的识别。

附图说明

图1本发明人机交互形式化推演模型建模框架。

图2(a)本发明人机交互模型顶任务/子任务执行状态转移示意图。

图2(b)本发明人机交互模型操作执行状态转移示意图。

图3本发明典型状态迁移图。

图4本发明人机交互演化路径图形化表示。

图5本发明所述方法流程图。

图6本发明1#发动机火情处置任务模型图。

图7本发明2#发动机误关闭重启任务模型图。

图8(a)本发明1#发动机状态迁移模型。

图8(b)本发明2#发动机状态迁移模型。

图9本发明起飞阶段典型人机交互危险路径。

图10本发明巡航阶段典型人机交互危险路径。

图11本发明降落阶段典型人机交互危险路径。

图中序号、符号、代号说明如下：

图2(a)、(b)中，圆角矩形表示顶任务或子任务；Ready、Executing、Done表示活动的执行状态，含义分别为就绪、执行、完成；StartCondition、EndCondition、Reset表示活动执行状态转换的触发条件，含义分别为开始条件、结束条件、重置条件；Precondition、Postcondition、Repeatcondition表示活动执行的条件，含义分别为前置条件、后置条件、重复条件。

图3中，圆角矩形中的S0、S1、S2表示系统状态；有向边表示迁移；迁移动作和前提条件作为迁移条件出现在向边的标记上，用a:[g]格式进行标记。

图4中，环境状态变化采用六边形表示，系统/人机界面状态改变采用椭圆表示，人状态变化采用方框表示；而故障和人误则采用虚线进行标识，使之同系统和正常操作进行区分；图中箭头表示路径时序关系。

具体实施方式

本发明是一种基于形式化验证的人机交互风险场景识别方法，分析流程如图5所示，以航空发动机火警应急处置人机交互过程为例说明该流程，案例描述如下。

航空发动机是飞机的动力装置，当发现发动机火警时一般需要立即执行应急流程；但是如果发动机火警在起飞时出现，飞行员应首先将飞机建立并稳定在安全爬升航径上，然后再执行应急流程。发动机火警应急流程包括：

·关断发动机(将发动机混合器控制杆置于关断位置)；

·隔离发动机(关闭液压系统、切断气源和燃油线路、切断电源)；

·释放灭火剂(释放置于发动机内壁固定式灭火瓶中的卤代烃物质)。

设某双发飞机在巡航阶段，1#发动机着火并告警，飞行员观察到告警信息后进行发动机火警应急处置。在处置过程中飞行员可能出现人为失误，包括没有及时处置1#发动机火警或者误操作2#发动机。当2#发动机停车时会出现动力失去告警，飞行员需要执行发动机重启程序以保证飞行安全。若1#发动机着火后没有及时扑灭，会导致发动机损毁。一般而言，发动机火警处置完毕后不允许重启发动机，否则很容易导致发动机再次起火和损毁。此外，在处置发动机火警过程中，飞行员需要保持正常的飞行姿态。

本发明是一种基于形式化验证的人机交互风险场景识别方法，见图5所示，该方法包括如下五个步骤：

步骤一：采用形式化方法对复杂人机交互推演过程进行建模，形成通用的人机交互形式化推演模型；

根据飞行操作手册，进行适当简化后，对发动机火警处置的任务分析如图6所示；当2#发动机误关闭时，其重启任务分析如图7所示。对上述任务进行分析，描述结果如表7所示。1#发动机和2#发动机状态迁移模型如图7所示。

表7发动机火警案例任务描述表

附注1：所需时间的是指假设的单位时间。

附注2：延迟指操作没有在应该执行的时间执行，可能延后1,2,3,…个时间单位

附注3：“保持爬升姿态”中“提前结束”人误模式反映为时间窗口减少1个单位时间，即起飞阶段时间窗口变为11个单位时间。

飞机发动机火警应急处置的目的是保证飞行安全，可以用时间窗口度量。时间窗口指人机交互中可供操作员正确响应的时间长度，操作员只能在时间窗口内进行人机交互。其中，发动机火警处理时间窗口与任务基本场景相关，规定如下：

·飞机处于巡航阶段且发动机工作时，飞行高度较高，飞行员有充足的时间完成应急处理，保证飞行安全，故火警处理时间窗口规定为18个单位时间；

·飞机处于降落阶段时，飞行高度较低、飞行速度慢，飞行员为保证飞行安全而进行应急处理的时间不够，因此规定火警处理时间窗口为8个单位时间；

·当处于起飞阶段时，飞行高度较低，需要先爬升到一定高度后在处理火警，且当飞机爬升后能够提供更多的保证飞行安全的应急响应时间，由于此时爬升高度一般达不到巡航高度，因此认为飞行员火情处理时间窗口为8个单位时间，但通过爬升，火情处理时间窗口能增加4个单位时间；若前提结束爬升，则时间窗口只能增加3个单位时间。

步骤二：将人机交互形式化推演模型映射为各种场景下可执行的人机交互自动推演模板，包括考虑人误的任务形式化模型自动推演模板，考虑异常态的系统、人机界面、环境形式化模型自动推演模板；

根据步骤一，建立发动机火警处置任务模型对应的自动推演模板以及1#、2#发动机状态迁移模型对应的自动推演模板。

步骤三：描述人机系统安全属性，确定人机系统安全属性表达式，得到人机系统安全规约；

根据任务场景，希望飞行员能够在火情时间窗口内扑灭火情，保证飞行安全。记t_fire为发动机火警解除实际所历时间，TW_FIRE为保证飞行安全而用于处理发动机火警的时间窗口，则本案例的安全规约可以用如下LTL公式表达：

G(t_fire＜TW_FIRE)

当路径违背上式时，就认为发生危险。相应的，定义非安全规约

F(t_fire＞TW_FIRE)

其含义是，当“违背”t_fire＞TW_FIRE时，说明人机交互路径解除火警时间不会超过时间窗口，因此上式对应安全路径。

步骤四：借助模型检查工具SPIN完成风险场景路径的排查工作；

基于人机交互自动推演模板得到实例化自动推演模型，输入到SPIN模型检查工具中进行安全验证。考虑飞机在起飞、巡航和降落阶段三种任务场景的人机交互演化路径，其主要差别为保证飞行安全的时间窗口。当发动机被喷洒灭火剂后不能再次启动，因此规定在2#发动机上错误释放灭火剂，则时间窗口为0。

经过验证分析，得到结果如表8所示。对起飞和降落阶段，分别找到108条和62条危险路径，同时存在24条和94条安全路径；而在巡航阶段，则找到162条危险路径和142条安全路径，危险路径和安全路径数量均超过起飞和降落阶段。这是，由于在巡航阶段时间较窗口长，当操作所需时间一定的情况下，飞行员有更多的操作的机会，因而人机交互演化路径分叉点多，导致交互路径总数也较多。而起飞和降落阶段由于时间窗口短，允许飞行员进行操作的次数少，因而人机交互演化路径分叉少，导致交互路径总数也较少。

表8发动机火警案例验证结果

场景	飞行阶段	安全路径	风险场景路径
				1	起飞	47	90
2	巡航	142	162
				3	降落	24	62

步骤五：采用定性比对方法对演化路径的可能性进行评价，识别发生可能性相对较高的风险场景路径。

对于得到的交互路径，经定性对比方法，分别得到起飞、巡航和降落阶段的发生概率较高的典型危险演化路径，如图9-图11所示。

从分析结果可以看到，在起飞和降落阶段，可供飞行员处理发动机火警的时间窗口小，飞行员需要按照任务流程正常执行，稍有人为失误即可能导致不安全后果，包括飞行员关错发动机、发现火情延时和提前结束爬升等。

在巡航阶段，可供飞行员处理发动机火警的时间窗口较长，飞行员可以从容处理火警情况，即使关错发动机，也有足够的时间供飞行员进行补救。当许多小概率事件同时发生时，才可能导致时间窗口不足的情况。

Claims (5)

1.一种基于形式化验证的人机交互风险场景识别方法，其特征在于：该方法包括如下步骤：

步骤一：采用形式化方法对复杂人机交互推演过程进行建模，形成通用的人机交互形式化推演模型，包括考虑人误的任务形式化建模，考虑异常态的系统、人机界面、环境形式化建模和人机交互形式化推演建模；

步骤二：将人机交互形式化推演模型映射为复数种场景下能执行的人机交互自动推演模板，建立考虑人误的任务形式化模型自动推演模板，考虑异常态的系统、人机界面和环境形式化模型自动推演模板；

步骤三：描述人机系统安全属性，确定人机系统安全属性表达式，得到人机系统安全规约；

步骤四：借助模型检查工具简单协议元语言解释器即SPIN完成风险场景路径的排查工作；

步骤五：采用定性比对方法对演化路径的可能性进行评价，识别发生可能性相对高的风险场景路径；

在步骤一中所述的“考虑人误的任务形式化建模，考虑异常态的系统、人机界面、环境形式化建模和人机交互形式化推演建模”，其内容说明如下：

(1)考虑人误的任务形式化建模

基于任务模型的层次化结构，定义适用于描述任务执行过程的形式化语法和语义，支持任务模型的形式化描述；

A.定义任务形式化模型语法

定义1：人机交互任务模型是一个四元组HTA＝(T,O,R,t₀)，其中

T＝{t₁,t₂,…,t_n,…}是顶任务和子任务的集合；

O＝{o₁,o₂,…,o_n,…}是底层操作的集合；

R＝T→T∪O是任务分解，即父任务分解为子任务及操作；

t₀∈T是顶层任务，即人机交互所要实现的目标；

不失一般性，记人机交互任务模型一中间任务t的子任务集合为subtask(t)＝{t₁,…,t_i-1,t_i,t_i+1,…,t_n}，则t是

的父任务，记为parent(t_i)＝t，i＝1,…,n；对有限串行任务序列T＝{t₁,…,t_i-1,t_i,t_i+1,…,t_n}，记任务序列中第一个任务和最后一个任务分别为first(T)＝t₁，last(T)＝t_n；同时，对任务序列中一任务t_i，记其前一个任务为

若i＝1，则记

定义2：顶任务/子任务是一个五元组T＝(ID_tsk,S_tsk,G_tsk,I_tsk,R_tsk)，其中，

ID_tsk是顶任务/子任务的唯一标示；

S_tsk＝{Ready,Executing,Done}是任务的执行状态，含义分别为就绪、执行、完成；

G_tsk＝(precondition,postcondition,repeatcondition)是一个三元组，表示顶任务/子任务执行状态转移的执行条件，含义分别为前置条件、后置条件和重复条件；

I_tsk＝(startcondition,endcondition,resetcondition)是一个三元组，表示顶任务/子任务执行状态转移的触发条件，含义分别为开始条件、结束条件和重置条件；

R_tsk＝S_tsk×G_tsk×I_tsk→S_tsk是顶任务/子任务的执行状态转移函数，定义为R_tsk(s_tsk,g_tsk,i_tsk)＝s′_tsk，当且仅当g_tsk∈G_tsk和i_tsk∈I_tsk为真时，s_tsk∈S_tsk转移到下一个状态s′_tsk∈S_tsk；

定义3：操作是一个六元组O＝(ID_op,S_op,I_op,R_op,HE,R_e)，其中，

ID_op是操作的唯一标示；

S_op＝{Ready,Executing,Done}是操作的执行状态，含义分别为就绪、执行、完成；

I_op＝(startcondition,resetcondition)是一个二元组，表示操作执行状态转移的触发条件，含义分别为开始条件、重置条件；

R_op＝S_op×I_op→S_op是操作的执行状态转移关系，定义为R_op(s_op,g_op,i_op)＝s′_op，当且仅当g_op∈G_op和i_op∈I_op为真时，s_op∈S_op转移到下一个状态s′_op∈S_op；

是操作变量，包含空输出，正常输出和n种人误模式；R_e＝S_op×HE→HE是操作变量函数，定义为R_e(s_op,h)＝h′，当且仅当s_op∈S_op满足时，h∈HE转移到h′∈HE；

R_e表示，当操作处于执行Executing状态时，该操作输出正常态及各种异常操作；当操作处于就绪Ready及完成Done状态时，该操作无输出；

根据层次任务分析，任务/操作间的转移关系定义为顺序、并行、决策、自由组合顺序、自由组合并行、重复六种；其中，顺序、并行、决策、自由组合顺序、自由组合并行五种关系直接描述上级父任务与下级子任务的关系，因此又称为任务分解算子；重复关系描述任务的循环执行情况，与任务层次性关系不大，因此定义为执行条件；任务操作分解的详细规则定义如下：顺序任务分解算子的符号为ord，含义为按顺序依次执行；并行任务分解算子的符号为par，含义为同时执行；决策任务分解算子的符号为xor，含义为选择其中一项执行；自由组合顺序任务分解算子的符号为opt_seq，含义为无顺序执行满足前提条件的所有任务；自由组合并行任务分解算子的符号为opt_par，含义为同时执行满足前提条件的所有任务；

因此，任务分解能表示为：

B.定义任务形式化模型语义

任务形式化模型的语义是触发条件的形式化语义，其描述任务如何执行；由于触发条件的本质是控制局部的任务执行时序，而任务分解算子的本质是控制全局的任务执行时序，因此二者有着天然的耦合关系；为了理清不同任务的执行时序关系，需要从触发条件和任务分解算子两个维度严格进行定义任务/操作的状态迁移关系；

(2)考虑异常态的系统形式化建模

系统形式化建模的任务是描述系统各种状态，包括正常运行模式和故障模式之间的切换关系；

系统运行模式是指根据任务要求和技术文档，将系统可能的运行状态进行归纳并解耦成一系列离散状态，每种状态称为一个运行模式；模式之间既能通过人的控制进行切换，也能发生自动切换；切换发生时可能需要满足预定的切换条件，包括触发条件和前提条件；系统运行模式分析的结果能用“系统运行模式切换关系分析表”进行记录，具体为：当系统处于运行模式1且满足预定切换条件时，系统的运行状态能切换至运行模式2及运行模式3；当系统处于运行模式2且满足预定切换条件时，系统的运行状态能切换至运行模式1及运行模式3；当系统处于运行模式3且满足预定切换条件时，系统的运行状态能切换至运行模式1及运行模式2；当系统在某运行模式运行且不满足所有的切换条件时，认为系统在该运行模式停留；

系统故障模式分析从功能角度出发，重点关注与具体任务场景相关的功能；系统功能分析采用树状层级结构，从系统层出发，逐层进行功能分解，分解颗粒度以和系统运行模式相洽为止；所谓“相洽”指功能故障模式能够不歧义地引发系统运行模式切换；系统故障模式分析的结果能用“系统运行模式与故障模式耦合分析表”进行记录，具体为：首先将系统功能逐层分解为功能1、功能2，然后分析每种功能包含的故障模式，即故障模式1、故障模式2，这些功能故障模式能够引发系统运行模式切换，此外，故障模式需要和特定的信息即告警及反映故障特征的任务信息相关联；

系统形式化建模包括三个步骤，具体如下：

A.构建正常情况下系统运行模式状态迁移模型

该步骤的思路是将“系统运行模式切换关系分析表”中记录的状态迁移关系直接映射为扩展状态迁移系统即ETS；下面给出几个定义；

定义1：一个状态迁移系统即TS是一个四元组TS＝(S,s₀,A,Δ)，其中，

S＝{s₁,s₂,…,s_n,…}表示系统所有可能的状态集合；

s₀∈S是S的初始状态；

A＝{a₁,a₂,a₃,…}表示迁移动作集；

Δ∈S×A×S称为状态迁移关系，它描述了状态在动作集的触发下由一个状态转移到另一个状态的行为，采用符号

表示迁移关系(s,a,s′)∈A；

定义2：给定一个TS，对其中一个状态s和操作a，状态s在执行操作a的后继状态定义为：

式中，Post(s,a)包含了在状态s时执行操作a的所能到达的所有状态；

Post(s)包含了在状态s时执行任何操作所能到达的所有状态；

定义3：一个TS被认为是确定的，当且仅当

a.|s₀|＝1，即仅有一个初始状态；

b.

对所有操作和状态，其后继状态不超过一个；

否则，该TS被认为是非确定的；

定义4：一个ETS是一个五元组ETS＝(S,s₀,A,Δ,G)，其中，

S＝{s₁,s₂,…,s_n,…}表示系统所有可能的状态集合；

s₀∈S是S的初始状态；

A＝{a₁,a₂,a₃,…}表示迁移动作集；

G＝{g₁,g₂,…,g_n,…}表示系统状态迁移的前提条件；

Δ∈S×A×S称为状态迁移关系，对一个迁移δ＝(s,g,a,s′)∈Δ，称s∈S为源状态，g∈G为前提条件，a∈A为迁移动作，s′∈S为目标状态；用符号

表示δ；

定义5：令C＝{ETS¹,ETS²,…,ETSⁿ}表示由复数个ETS构成的迁移系统网络，且

令

对某个迁移动作

定义

则C的复合ETS¹×ETS²×…×ETSⁿ定义为一个

ETS＝(S,s₀,A,Δ,G)，其中，

S＝S¹×S²×…×Sⁿ；

A＝A¹∪A²∪…∪Aⁿ；

定义为δ＝((s₁,…s_n),g,a,(s′₁,…s′_n))∈Δ，当且仅当

有s_i＝s′_i；且

始终存在一个状态迁移关系(s_i,g_i,a,s′_i)使得g＝∧_i∈E(a)g_i；

G＝G¹∪G²∪…∪Gⁿ；

状态迁移图是一个带节点和有向边的有向图，有向边表示迁移，迁移动作和前提条件作为迁移条件出现在有向边的标记上，用a:[g]格式进行标记；ETS能采用状态迁移图表达；

根据以上定义，假定分析人员识别出系统共n种运行模式，将其依次编号为s₁,s₂,…,s_n；系统运行模式状态迁移有两种基本触发方法：人的操作/环境扰动触发，系统自动触发；不失一般性，当系统运行模式从s_i迁移到s_j,1≤i＜j≤n，记状态迁移关系为δ_ij＝(s_i,g_ij,a_ij,s_j)；当

代表人的操作触发，能用通过任务形式化模型的共享变量获得；当

代表系统自动触发；则生成正常情况下系统运行模式状态迁移模型为

B.构建系统诸功能的故障模型

假设系统诸功能故障的发生是随机、互斥、不可逆的，且能在人机交互过程的任何时刻发生；模型构建的基本思路是将“系统运行模式与故障模式耦合分析表”中诸功能故障模式映射为非确定性扩展状态迁移系统即ETS；假定分析人员识别出系统共m个功能，每个功能对应有m_i种可能故障模式；不失一般性，将系统的功能故障模式编号为

且记系统功能正常态为f_i,0,1≤i≤m；系统故障模型就是系统从功能正常态f_i,0随机迁移到一个故障模式f_i,j,1≤j≤m_i；则生成第i个功能对应的系统故障状态迁移模型为

C.构建系统形式化模型

将系统故障所导致的系统运行模式状态迁移关系扩展到正常情况下系统运行模式状态迁移模型中，系统故障所导致的系统运行模式状态迁移模型的本质是以故障模式f_k,l作为迁移动作对M⁰的迁移关系Δ⁰进行补充；当系统运行模式因为故障f_k,l从s_i迁移到s_j,1≤i＜j≤n,1≤k≤m，1≤l≤m_k，记状态迁移关系为δ_ij,kl＝(s_i,f_k,l,s_j)时，将该迁移关系增添至M⁰中，并称M⁰更新后得到的状态迁移模型

为考虑故障的系统运行模式状态迁移模型；

对考虑故障的系统运行模式状态迁移模型和系统故障状态迁移模型进行复合操作，即能得到系统状态迁移模型M＝(S,s₀,A,Δ,G)，即

式中，

满足δ＝((s₁,s₂,…,s_m+1),g,a,(s′₁,s′₂,…,s′_m+1))∈Δ，使得当且仅当

时，有s_i＝s′_i，且当且仅当

时，总存在迁移(s_i,g_i,a,s′_i)满足g＝∧_i∈E(a)g_i；其中，

(3)考虑异常态的人机界面形式化建模

人机界面形式化建模的任务是描述人能否能及时、正常地接收信息及对系统的控制是否被阻止；人机界面模型相当于对提供给人的正常信息进行过滤和“拉偏”，即分析考虑可能出现的虚警、漏警、任务信息错误、任务信息不完整、任务信息不及时、通信信息错误、通信信息不完整、通信信息不及时的异常信息模式；系统提供给人的任务信息、告警信息以及通信信息均可能出现异常态，但是这样可能会导致模型状态规模膨胀；因此，根据实际情况，针对性地考虑某些故障相关的异常信息模式，这些异常信息模式需要同任务模型接洽；人机界面模型的分析结果能通过“人机界面信息异常态分析表”进行记录，具体为：人机界面信息包含任务信息、告警信息、通信信息三种类别，每种类别的信息又包含诸条具体信息，需要分析可能出现的异常信息模式，包括：虚警、漏警、任务信息错误、任务信息不完整、任务信息不及时、通信信息错误、通信信息不完整、通信信息不及时的异常信息模式；

人机界面建模首先将“人机界面信息异常态分析表”中的任务信息、告警信息及通信信息分别映射为系统形式化模型中的状态量，与其对应的信息异常模式等价于系统模型中的故障模式，因此其建模方法等同于系统各功能的故障模型；不失一般性，将“人机界面信息异常态分析表”所涉及的信息依次编号为

其中I_i对应的信息异常模式编号为Iv₁,Iv₂,Iv₃，对应信息不正确、不完整、不及时；显然，I_i∈S，其中S是M＝(S,s₀,A,Δ,G)中的状态集合；设第i个信息对应的异常状态迁移模型为

则MIⁱ的生成算法与系统故障模型类似，显然，该迁移系统的迁移动作集合和前提条件集合均为空集；

令

即得到基于ETS描述的人机界面形式化模型；

(4)考虑异常态的环境形式化建模

环境形式化建模的目的是描述在任务执行过程中可能影响系统运行及诱发人为失误的环境变量的状态变化；环境对人机系统的影响包括影响系统运行模式切换、影响任务执行条件、影响人的绩效形成因子；环境模型的状态量需要同系统模型、任务模型和PSFs相匹配；环境模型分析结果能通过“环境扰动分析表”进行记录，具体为：环境扰动分析需要对复数个环境扰动因素的状态变化进行描述，此外，还需分析复数个环境扰动因素对系统运行模式切换、任务执行条件、人的绩效形成因子的影响；

环境形式化模型有两种形式，其一是直接设定环境状态，在人机交互过程中不再发生变化；其二是类似系统运行模式状态迁移模型，将环境的复数种扰动模式及正常情况抽象为离散状态量，然后建立这些状态量之间的转移关系；

设环境模型为Env＝(E,e₀,A_E,Δ_E,G_E)，其中E是环境的各种扰动状态与正常状态的集合；e₀为初始状态；A_E为环境状态迁移动作集，即环境状态迁移的触发状态，由于从扰动的角度构建环境模型，所以认为A_E为空；Δ_E是环境状态迁移关系，是随机迁移，即δ_e＝(e_i,e_j)∈Δ_E，相应的，G_E为空；

Env＝(E,e₀,A_E,Δ_E,G_E)与系统故障状态迁移模型类似，该模型即是基于ETS描述的环境形式化模型；

(5)人机交互形式化推演建模

上述过程根据任务模型和系统/人机界面/环境模型的特点分别构建了形式化模型，但是这两种形式化描述不尽相同；考虑到任务形式化模型本质上是任务/操作执行状态变化的描述，所以能将其映射为ETS；其基本思想是将任务或操作的状态等价为ETS的状态，将任务或操作的状态迁移的触发条件等价为ETS的迁移动作集，将任务的执行条件等价为ETS的前提条件；则生成基于ETS的任务模型为

因此，通过状态迁移系统，能得到一致的任务、系统、人机界面和环境模型形式化描述；进一步地，令MMI＝(S,s₀,A,Δ,G)＝T×M×MI×Env，MMI是基于ETS构建的形式化模型，通过严格定义的状态迁移关系实现人机交互行为的推演，因此将MMI称为人机交互形式化推演模型；

如果直接采用ETS的形式描述人机交互行为，会导致模型抽象程度高，可读性差，不易理解；而根据可读性强、易于理解的可视化任务分析和状态迁移图能无歧义地得到人机交互形式化推演模型，因此能采用可视化任务分析和状态迁移图的方式对人机系统进行形式化建模。

2.根据权利要求1所述的一种基于形式化验证的人机交互风险场景识别方法，其特征在于：在步骤二中所述的“建立考虑人误的任务形式化模型自动推演模板，考虑异常态的系统、人机界面、环境形式化模型自动推演模板”，其内容说明如下：

复杂人机交互形式化验证方法的核心，是将人机交互形式化推演模型语义映射为各种场景下能执行的自动推演模板，然后借助计算机完成风险场景路径的排查工作；由于本文采纳简单协议元语言解释器即SPIN作为模型检查工具，协议元语言即Promela是SPIN的模型输入语言，因此基于Promela语言构建自动推演模板；

(1)考虑人误的任务形式化模型自动推演模板

A.正常操作执行自动推演模板

首先考察任务模型底层的操作执行的自动推演模板，不失一般性，一个任务Task被分解为两个操作Operation 1和Operation 2，操作之间的关系包括顺序、并行、决策、自由组合顺序、自由组合并行五种；根据形式化语义，操作关系中顺序和自由组合顺序、并行和自由组合并行是重合的，因此它们的自动推演模板也是一致的；此外，由于操作的输出——操作变量属于共享变量，因此需要定义控制通道：

chanctrl＝[0]of{byte}

式中，通道大小为0，表示向通道发送和接收数据必须是同时发生的；byte表示操作的ID，用于区分不同的操作；任务模型中人通过该通道发出具体动作；基于此，则能建立操作语义的自动推演模板；

当考虑时间窗口时，需要记录各操作所消耗的时间；具体地，需要将连续的时间离散成一系列单位时间点，并额外构造全局时间变量和时间通道，用于记录任务执行的时间开销，如下式所示；每当一项操作完成，就通过时间通道在全局时间变量上记录该操作花费的时间；时间通道在描述操作执行的所需时间与可用时间关系方面很重要，当出现延迟失误时，需要时间通道量化延迟对任务完成的影响；

chan stopwatch＝[0]of{byte}

B.正常任务执行自动推演模板

其次考察子任务分解相关的自动推演模板，不失一般性，顶任务Parent被分解为两个子任务Task 1和Task 2，任务的执行需要满足前提条件precondition，任务的结束需要满足后置条件postcondition；根据层次任务分析，子任务并不直接作用于系统，因此，任务进程中没有控制通道；基于此，则能建立子任务语义的自动推演模板；

C.人为失误自动推演模板

根据人机交互任务分析，人误模式是操作层的属性，因此需要在操作自动推演模板的基础上定义人误模式自动推演模板；由于人误模式本身能视为操作输出的变异，而且同一操作不同人误模式之间是相互独立的，因此能认为各种人误模式和正常操作之间是“亦或关系”，即当操作处于执行状态时，选择正常操作和人误模式中任意一种作为输出送入控制通道；

人为失误包括时机和精度两个维度，前者是不及时，后者能视为某时间点上操作不正确、不完整；在自动推演模板构造上，“不及时”通过单位时间点上重复空操作来表征，当出现不及时人误模式时，记录1单位时间开销后，跳过操作输出至操作执行起点；“操作不正确”和“不完整”通过具体操作命令体现；假设操作Operation对应人误模式分别为HEM 1、HEM 2、HEM 3，且其中HEM3为延迟失误，任务需求时间为t，则建立考虑人误模式的操作自动推演机制；

需要指出的是，原则上，只要人误概率不为零，该人误均可能发生；但是人为失误具有路径依赖性，某种情形下路径依赖对人为失误的影响是全相关时，其发生概率为1；这样，人误模式自动推演模板中其他人误就不会发生；由于这种路径依赖通过其他事件及信息的变异性体现，因此需要在考虑人误模式的操作自动推演机制中人误操作亦或关系前加入非全相关判断条件；

(2)考虑异常态的系统形式化模型自动推演模板

系统形式化模型包括考虑故障的系统运行模式状态迁移模型和系统故障状态迁移模型；考虑故障的系统运行模式状态迁移模型将系统运行模式映射为离散Promela进程的状态，状态迁移关系有两种：操作员控制和自动切换；其中，操作员控制需与任务模型相结合，即系统从控制通道中接收人的操作，作为系统运行模式切换的触发条件，若该运行模式的前提条件满足时，进行切换；自动切换是系统运行模式满足给定前提条件时，自动切换到其他运行模式；基于此，则能建立典型考虑故障的系统运行模式状态迁移模型对应的自动推演模板；

由于系统故障状态迁移模型中迁移动作集和前提条件集均是空集，状态迁移关系退化为随机迁移；系统故障状态迁移模型自动推演模板成为非循环随机执行序列；假设系统共有m种故障模式，以状态变量sf表示各种故障模式，其状态为0表示正常，状态1～m表示第1～第m种故障模式，则建立其自动推演模板；

(3)考虑异常态的人机界面形式化模型自动推演模板

人机界面模形式化模型的自动推演模板，是对系统的输出信息和系统的输入信息进行“过滤”，模拟虚警、漏警、信息缺失、信息不正确、操作无效诸人机交互异常情况；由于人需要在任务过程中不断的获取信息、输入操作，因此采用循环机制构建人机界面自动推演模板；

在实际案例分析时，理论上任何告警信息都会出现虚警和漏警异常态，任何任务信息和通讯信息都可能出现信息缺失、信息不正确诸异常模式，任何操作都可能因人机界面故障而被阻止；但是，这种事无巨细地推演对于形式化验证方法可能造成维度灾难，因此能根据具体应用场景针对性的选择告警信息、任务信息和通讯信息进行“过滤”处理；

(4)考虑异常态的环境形式化模型自动推演模板

将环境形式化模型考虑为环境扰动模型，即将环境模型作为影响因素纳入其他模型中，而不考虑环境模型与其他模型的交互；其自动推演有两种模板，其一是直接设定背景环境变量；其二是类似系统运行模式自动推演模板，考虑不同环境状态之间切换。

3.根据权利要求1所述的一种基于形式化验证的人机交互风险场景识别方法，其特征在于：在步骤三中所述的“描述人机系统安全属性，确定人机系统安全属性表达式，得到人机系统安全规约”，其内容说明如下：

人机系统安全规约是利用具有精确语义的形式化语言描述系统属性和安全边界，用于支持系统安全属性自动化验证；

给定模型的形式规约从识别使得模型为真的原子命题开始；关系结构即Kripke提供了一种利用标记函数来标记各状态下使得该状态为true的变量集合即原子命题，因此引入Kripke结构对ETS进行扩展；

定义1：一个Kripke结构扩展标记迁移系统是一个三元组(ETS,AP,L)，其中，

ETS＝(S,s₀,A,Δ,G)是一个扩展状态迁移系统；

AP＝{a,b,c,…}表示原子命题集；

L:S→2^AP称为标签函数；

将人机交互形式化推演模型MMI扩展为Kripke结构，即(MMI,AP,L)；模型的一个执行序列能表示为r＝<s₀,(a₁,g₁),s₁,(a₂,g₂),…>；式中，s₀,s₁,…∈S，a₁,a₂,…∈A，g₁,g₂,…∈G；定义执行序列r的路径为Trace(r)＝<L(s₀),L(s₁),L(s₂),…>；令Trace(MMI,AP,L)表示Kripke结构的人机交互形式化推演模型MMI的演化路径的集合，则σ＝<AP₀,AP₁,AP₂…>∈Trace(MMI,AP,L)表示Trace(MMI,AP,L)中的一条路径，且记σ[i]＝<AP_i,AP_i+1,…>表示从第i个时刻开始的路径；下面，就能利用时态逻辑描述人机系统安全属性；

时态逻辑是在逻辑框架中采用一组规则来表达和推理时间的符号系统，其中时间通过一组有序的状态序列表示；在形式化验证的应用方面，一个时态逻辑公式由关于模型变量和模态算子的布尔命题组成；模态算子指定命题之间时序的关系；最常见的时态逻辑包括线性时序逻辑即LTL、计算树逻辑即CTL，其常用模态算子分为路径算子与时态算子两类：路径算子包含All、Exists两种操作，其符号分别为Aψ、Eψ，其含义分别为全称路径量词、存在路径量词；时态算子包含NeXt、Future、Global、Unitl四种操作，其符号分别为Xψ/○ψ、Fψ/◇ψ、Gψ/□ψ、

其含义分别为下一状态、未来某个状态、未来所有状态、直到…都；

基于巴科斯范式(Backus-Naur Form,BNF)描述的LTL的语法如下式所示：

式中，p是原子命题，φ是定义的公式；

在人机交互风险场景分析中，采用(Fφ)的形式及(Gφ)的形式，前者表达了希望人机系统最终能达到的状态的约束；后者表达了系统人机系统始终保持某个属性的约束；

这样，结合Kripke结构的MMI，LTL的语义能表示为：

σ|＝Fφif there exists i≥0 such thatσ[i]|＝φ

σ|＝Gφif for all i≥0,σ[i]|＝φ

式中，φ是由分析人员确定的人机系统安全属性的表达式；利用该式就能得到人机系统的安全规约；

进一步，将LTL公式转化为Promela语言，语法形式如下式所示：

ltl::＝ltl＜name＞'{'formula'}'

式中，formula是由分析人员事先确定的人机系统危险状态的布尔表达式。

4.根据权利要求1所述的一种基于形式化验证的人机交互风险场景识别方法，其特征在于：在步骤四中所述的“借助模型检查工具SPIN完成风险场景路径的排查工作”，其作法说明如下：

人机交互风险场景推演就是在自动推演模板的基础上，利用SPIN模型检查工具排查危险路径；SPIN模型检查工具完成给定模型的形式验证后能够返回丰富的信息，包括危险路径总数、模型状态变化序列以及基于通道信息传递的模拟运行图；基于这些信息，分析人员就能够开展危险路径的风险评估，支持风险场景识别；

风险场景路径能记录为<Event 1,Event 2,…,Event n>；考虑到风险场景事件包含人、机、环状态的变化，为了清楚地表达人机系统不同组成要素在事件序列中的时序关系和序列，提出可视化的路径表示方式。

5.根据权利要求1所述的一种基于形式化验证的人机交互风险场景识别方法，其特征在于：在步骤五中所述的“采用定性比对方法对演化路径的可能性进行评价，识别发生可能性相对较高的风险场景路径”，其作法说明如下：

异常事件对比方法，对推演得到的路径的可能性大小进行对比识别，其基本思想是比较路径中等价小概率异常事件，包括故障、人误的个数；若某条路径上小概率异常事件数量越多，则该路径越不可能发生；具体而言，首先统计路径中异常事件包括故障、人误和扰动的数量；然后对异常事件赋予风险权重，风险权重表征了异常事件发生可能性的大小；最后统计每条路径的权重总和进行排序，权重越小，说明该路径发生的可能性越大；

在进行风险权重赋值时，不加区分地对异常事件赋予风险权重为1，但需要对如下三种情况进行调整：

(1)具有路径依赖性的人误事件：具有路径依赖性的人误事件的发生与人机交互路径相关，即该人误受到演化路径上前面事件的诱发；当出现漏警故障事件后，出现延迟发生告警人误事件的可能性就大；因此，该人误事件就不能归结为小概率事件；此外，当路径中前后两个事件呈低相关以上但不包含低相关路径依赖相关关系时，其人误概率至少为0.14，相对名义人误概率及故障概率而言比较大，因此认为此时不宜将其统计为小概率事件；

(2)当多次出现没有路径依赖性的相同异常事件时，记为

第一次出现的该异常事件

的权重为1，第二次出现的该异常事件

的权重为2，依次类推；

(3)当出现执行延迟时，根据延迟时间越长，发生概率越低的原则，认为每多延迟1单位时间，风险权重增加0.5。

Images