人机交互动态故障树的模式混淆故障逻辑门的设计方法与流程

本发明提供一种人机交互动态故障树的模式混淆故障逻辑门的设计方法，它是基于动态故障树模型(即“dfta”)设计了一种新的人机交互故障逻辑门——模式混淆门，能够用于描述人机系统发生异常状态时人在一定时间内由于所感知信息中的部分信息发生缺失或者错误的显示模式故障而导致人无法正确判断当前的故障模式的逻辑因果，属于基于逻辑的人机交互建模分析领域。

背景技术：

在人机交互建模分析方面，故障树模型(即“fta”)主要是将人为失误行为作为基本事件，通过逻辑门来描述人机交互故障中人与系统、部件或原件故障之间的因果关系。fta作为图形化的方法从逻辑层级进行建模，思路清晰，建模简单。但是，其缺陷是将人考虑的过于简单，仅着眼于人的行为层次，而未将人作为具有认知能力的主体和与机、环之间的耦合特性描述出来。

复杂人机系统中人的任务通常以监视型任务为主，并且可能同时执行多项任务，主要需求与限制是人的大脑认知的能力而不是人的操作能力。针对人的信息加工阶段中的感知信息阶段和判断决策阶段中的信息交互存在两种人机交互故障类型：认知过载和模式混淆。前者表示，在当前情景和任务要求下，人需要感知的信息超出了人的认知能力限度，因而放弃了应该做的任务；后者表示，由于认知过载、环境扰动或设备故障原因，人做出判断决策需要的信息不足而导致人做出了错误的判断决策，因而采取不该做的应对措施。

针对人机交互过程中出现的模式混淆故障类型，如果可以设计一种模式混淆故障逻辑门，并从信息处理模型的信息流层次提出其运算逻辑，这样在原有dfta方法以失效率描述事件发生的不确定性的基础上，通过模式混淆故障逻辑门的运算方法增加了对人机交互逻辑不确定性的考虑。

技术实现要素：

(1)目的：

本发明设计提供一种人机交互动态故障树的模式混淆故障逻辑门的设计方法，它从人机交互过程中人对信息的认知层面出发，充分考虑人的认知特性、场景任务特性和人机耦合特性，完善了系统故障逻辑，从而更加准确地度量了复杂人机系统的可靠性。通过分析能够发现容易诱发人为错误的场景和设计缺陷，对于提高人员绩效能力水平和增强人机系统可靠性和安全性有着重要作用。

(2)技术方案：

一、基于dfta的模式混淆门设计

在异常状态发生时，人在一定时间内，由于所需感知信息中的部分信息缺失以及错误的显示模式故障，而导致人无法正确判断当前的故障模式，为了能够描述模式混淆故障发生的逻辑因果关系，本发明基于dfta设计了一种模式混淆故障逻辑门。

模式混淆故障逻辑门是一种多输入单输出逻辑，当且仅当触发事件发生时才会有输出事件发生，逻辑门符号如图1；事件a、b、c为模式混淆门的输入事件，事件d、e、f为模式混淆门的输出事件，事件m为模式混淆门的判定条件；其中圆形表示故障树中的底事件，方框表示中间事件；当功能故障事件m发生时，调用其隶属故障模式类及该类别里所有故障模式相关信息类型，即人需要感知这些信息才能正确识别该故障模式；不同人机系统具有多个故障模式类，每一类中包含若干故障模式，隶属故障模式类与情景环境和事件m相关；

模式混淆门的输入输出是由信息的显示模式来进行逻辑运算的，如图2所示为模式混淆的运算逻辑。图2中的虚线框表示的是信息在模式混淆门中的传递，与事件一一对应。当事件m调用的所有信息类型的显示模式均为正确时，那么我们认为人一定能够判断出当前正确的故障模式。信息类型是正确识别该功能故障模式需要感知的所有信息，对应事件m，是一个信息集合。信息状态分别与输入事件对应，由信息类型、信息显示故障模式和信息获取渠道组成，情景环境中的环境或故障引起信息显示故障(缺失/错误)。事件c是事件m作为认知过载门的输入事件的输出事件，导致信息显示故障为缺失。事件d、e、f分别对应的故障模式1、2、3分别是该隶属故障模式类里的故障模式，因此输出事件的数量由隶属故障模式类确定。输出事件会导致某些事件的发生(dfta中的基本事件)，与判断为该故障模式后的响应动作相关。

人机系统中同一信息可能具有多种来源，人并不需要感知所有来源。在一定情景环境中，仅通过一种来源便获取该信息并且不再进行复核验证；某情景环境中，人需要通过至少两种来源来确认某重要信息。

本发明一种人机交互动态故障树的模式混淆故障逻辑门的设计方法，其假设如下：

1、信息的获取渠道包含人机交互界面(ci)、环境(ce)、通讯(cce)、直接与人交流(ccm)，信息的获取渠道至少为1项，人机交互界面中可能包含多个提供该信息的区域；

2、不同任务阶段和不同情境下，人感知同一信息的优先级不同；相同任务阶段和相同情境下，人感知不同信息的优先级也不同；假设人会仅通过能获取的最优先的渠道获取，并且不再继续从其他渠道获取复核；

3、若同一信息的同一获取渠道存在于认知过载门的输出事件，那么该信息该渠道的显示故障模式以认知过载门的输出事件为准；

假设信息获取渠道的优先级为：直接与人交流(ccm)>环境(ce)>人机交互界面(ci)>通讯(cce),以此为例，分析信息见表1：

表1给定信息获取渠道优先级时，信息显示模式情况

附注1：其中，m1、m2、m3分别表示信息显示模式为正确/缺失/错误，无表示该信息无法从该渠道获取。

从上表可以看出，若信息仅有一种获取渠道，且此信息的此渠道不属于认知过载输出，则该信息的显示模式与此渠道获取的信息显示模式相同，如信息1；若信息仅有一种获取渠道，且此信息的此渠道属于认知过载输出，则该信息的显示模式与认知过载输出相同为缺失，如信息2；若信息有多种获取渠道，且此信息的这些渠道都不属于认知过载输出，则该信息的显示模式与优先级高的渠道获取的信息显示模式相同，如信息3、4；若信息有多种获取渠道，且此信息的部分获取渠道属于认知过载输出，则该信息的显示模式与不属于认知过载输出的优先级高的渠道获取的信息显示模式相同，如信息5、6；由此获得该故障模式类内所有信息类型的信息状态，人通过感知该信息状态的信息进行判断决策，即得到输出事件；通过分析输入事件是否发生与信息状态的影响关系，专家需构建输入事件与输出事件的对应真值表。当输出事件对应的故障模式与事件m相同，则未发生模式混淆，否则就认为发生了模式混淆。

二、基于模式匹配的模式混淆门定量建模方法

本发明一种人机交互动态故障树的模式混淆故障逻辑门的设计方法，其基于模式匹配的模式混淆门定量建模方法主要包括下面两个阶段：

第一阶段：构建信息显示模式合集

依据人机系统的特点，调研相关参考文献和事故案例，挑选并建立所有功能故障模式；将容易混淆的故障模式划分为一类，将所有功能故障模式划分为若干故障模式类，并罗列出从该故障模式类中识别出故障模式所需的全部故障征兆信息，如表2。

表2人机系统故障模式类的划分

每个故障模式类别下有多种功能故障，相对应的故障征兆信息类型也有若干种，如表3。当功能故障被人发现时，人会从其所隶属的故障模式类中进行模式识别，感知该故障模式类别下所有信息并依据这些信息判断出当前故障模式。信息的显示模式包括：正确、缺失、错误，不同的信息显示模式组合下，识别出故障模式的概率不同；依据故障模式类,列举该模式类的所有信息的全部信息显示模式组合；若信息数量为n，则全部信息显示模式组合有3ⁿ种；

表3故障模式类i的信息显示模式合集

附注1：其中，m1，m2，m3分别代表正确、缺失和错误三种信息显示模式；

第二阶段：构建模式混淆门输入输出运算

当给定情景时，模式混淆门的环境条件、信息获取渠道优先级是确定的，输出事件的概率与输入事件是否发生(即信息显示模式组合)相关；给定情景下，若条件判定事件m发生，则p项输入事件的发生状态组合2^p可能同时与事件m隶属故障模式类(q项信息)的信息显示模式合集3^q项中的多种信息显示模式组合匹配，由专家依据两者之间的对应关系和信息显示模式组合与输出事件(功能故障模式判断结果)之间的关联关系给出每种输入事件发生状态组合下的输出事件，如表4。

表4输入事件与输出事件真值表

附注1：其中，1——发生，0——不发生，输出事件仅有一项；

综上所述，规纳总结如下：

本发明一种人机交互动态故障树的模式混淆故障逻辑门的设计方法，假设如下：

1、信息的获取渠道包含人机交互界面(ci)、环境(ce)、通讯(cce)、直接与人交流(ccm)，信息的获取渠道至少为1项，人机交互界面中可能包含多个提供该信息的区域；

2、不同任务阶段和不同情境下，人感知同一信息的优先级不同；相同任务阶段和相同情境下，人感知不同信息的优先级也不同；假设人会仅通过能获取的最优先的渠道获取，并且不再继续从其他渠道获取复核；

3、若同一信息的同一获取渠道存在于认知过载门的输出事件，那么该信息该渠道的显示故障模式以认知过载门的输出事件为准；

其具体实施步骤如下：

步骤一：依据系统功能故障，将容易混淆的故障划分为故障模式类

依据人机系统的特点，调研相关参考文献和事故案例，挑选并建立所有功能故障模式；将容易混淆的故障模式划分为一类，将所有功能故障模式划分为若干故障模式类，并罗列出从该故障模式类中识别出故障模式所需的全部故障征兆信息，见表2所示；

步骤二：对划分好的故障模式类构建信息显示模式合集

每个故障模式类别下有多种功能故障，相对应的故障征兆信息类型也有若干种，见表3所示；信息的显示模式包括：正确、缺失、错误，m1，m2，m3分别代表正确、缺失和错误三种信息显示模式；不同的信息显示模式组合下，识别出故障模式的概率不同；依据故障模式类,列举该模式类的所有信息的全部信息显示模式组合，构建信息显示模式合集；

步骤三：根据案例事故情景，建立相应的动态故障树模型

在步骤一、二对案例事故的故障模式类划分及相关信息模式合集构建的基础上，依据事故情景描述，建立相应的动态故障树模型；

步骤四：统计案例事故的信息显示模式情况，分析模式混淆门的输出事件

假设信息获取渠道的优先级为：直接与人交流(ccm)>环境(ce)>人机交互界面(ci)>通讯(cce),以此为例，分析信息显示模式情况如表1所示，若信息仅有一种获取渠道，且此信息的此渠道不属于认知过载输出，则该信息的显示模式与此渠道获取的信息显示模式相同，如表1中的信息1；若信息仅有一种获取渠道，且此信息的此渠道属于认知过载输出，则该信息的显示模式与认知过载输出相同为缺失，如表1中的信息2；若信息有多种获取渠道，且此信息的这些渠道都不属于认知过载输出，则该信息的显示模式与优先级高的渠道获取的信息显示模式相同，如表1中的信息3、4；若信息有多种获取渠道，且此信息的部分获取渠道属于认知过载输出，则该信息的显示模式与不属于认知过载输出的优先级高的渠道获取的信息显示模式相同，如表1中的信息5、6；由此获得该故障模式类内所有信息类型的信息状态，人通过感知该信息状态的信息进行判断决策，即得到输出事件；

步骤五：构建输入事件与输出事件真值表

根据给定情景和模式混淆门的输入事件，对某些信息类型的信息获取渠道进行封锁，参见表，步骤四得到该故障模式类内所有信息类型的信息显示模式，并构建输入事件与输出事件的真值；当给定情景时，模式混淆门的环境条件、信息获取渠道优先级是确定的，输出事件的概率与输入事件是否发生(即信息显示模式组合)相关；给定情景下，若条件判定事件m发生，则p项输入事件的发生状态组合2^p可能同时与事件m隶属故障模式类(q项信息)的信息显示模式合集3^q项中的多种信息显示模式组合匹配，由专家依据两者之间的对应关系和信息显示模式组合与输出事件(功能故障模式判断结果)之间的关联关系给出每种输入事件发生状态组合下的输出事件，如表4所示；

步骤六：在步骤一至五所建模型基础上，分析得到如下结论，若模式混淆门的输出事件与判定条件事件对应的故障模式相同，则人未发生模式混淆，否则，人发生了模式混淆；

通过以上作法，设计了人机交互动态故障树的模式混淆故障逻辑门，它从人机交互过程中人对信息的认知层面出发，充分考虑人的认知特性、场景任务特性和人机耦合特性，在原有基于动态故障树模型即dfta方法以失效率描述事件发生的不确定性的基础上，增加了对人机交互逻辑不确定性的考虑，完善了系统故障逻辑，从而更加准确地度量了复杂人机系统的可靠性；通过分析能够发现容易诱发人为错误的场景和设计缺陷，进一步提高人员绩效能力水平和增强人机系统可靠性和安全性。

(3)本发明的优点和功效：

从人机交互过程中人对信息的认知层面出发，充分考虑人的认知特性、场景任务特性和人机耦合特性，增加了对人机交互逻辑不确定性的考虑，完善了系统故障逻辑，能够更加准确地复现复杂人机系统的事故案例的结果，通过分析能够发现容易诱发人为错误的场景和设计缺陷。

附图说明

图1本发明所述的模式混淆门的逻辑门设计方法框图。

图2本发明的模式混淆的运算逻辑表示。

图3401号航班事故案例故障树。

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

a、b、c、m1、x5模式混淆门的输入事件

d、e、f、m3、m4模式混淆门的输出事件

m、x4模式混淆门的条件判定事件

x1触发事件

x3、m2、x2一般事件

t终事件

fdep功能相关门

具体实施方式

本发明以401号航班事故作为案例，具体实施方式分为两个阶段，共六个步骤。

401号航班事故案例

1972年12月29日晚，东方航空公司401号航班自纽约约翰菲茨杰拉德肯尼迪国际机场起飞，于迈阿密国际机场降落。机组由机长、副驾驶和第二副驾驶三人组成。在着陆准备阶段，机鼻起落架信号灯泡发生故障。起落架手柄处于“向下”的位置时，用于指示机鼻起落架是否伸出或锁定的绿灯未点亮。当机长收回起落架后，绿灯仍未变亮。由于无法确定机鼻起落架是否放下，机组人员通知塔台暂停着陆，爬升至2000英尺(609.6米)盘旋待命，设置飞机为2000英尺高度的自动驾驶，随后全神贯注修理灯泡，同时派遣第二副驾驶到舱内目视确认机鼻起落架是否放下。在修理灯泡期间，机组无意间触碰方向驾驶舵，负责高度的控制解除，自动驾驶解除。飞机的高度开始下降，但机组人员专注于修理飞机而未有效监控飞机飞行参数，未注意到飞机高度异常的事实和警告声。当时处于夜间无月，第二副驾驶在目视确认时也无法获得高度异常的信息。塔台发现飞机高度下降，通过通讯与机组联系并确认，机组回复正处于自动驾驶状态，高度没有异常。70年代，雷达性能比较差，经常出现测量误差的问题。因此塔台判断目前是雷达测量误差，在机组人员申请着陆后告知飞机可随时进场。此时，机组发现高度过低，立即采取措施，但实在过晚。飞机左引擎触地，发生严重的坠毁事故。

本发明一种人机交互动态故障树的模式混淆故障逻辑门的设计方法，见图1所示，模式混淆的运算逻辑表示见图2所示，其应用实施方式分为两个阶段，第一阶段分为两个步骤，第二阶段分为四个步骤；

第一阶段：401号航班事故案例的信息显示模式合集构建

步骤一：依据系统功能故障，将容易混淆的故障划分为故障模式类

塔台是机场里的最高建筑，是一种用于监视飞机和地面车辆、控制飞机的起飞和降落等的航空运输管制设施；塔台内包含能与飞机进行通讯的无线电设备、监控飞机位置的监视器、气象条件与航班咨询等。在本事故案例中，当监视器显示飞机的高度异常时，塔台与飞行机组联系，未能识别出机组人员回复的高度数据有误，而是错误判断为雷达故障，发生了模式混淆，未能再次提醒机组人员关注高度数据。将这两种故障模式划分为一个故障模式类，罗列其从该故障模式类中识别出故障模式所需全部故障征兆信息，见表；

表5401号航班事故案例的人机系统故障模式类的划分

步骤二：对划分好的故障模式类构建信息显示模式合集

在401号航班事故案例的人机系统故障模式类内，信息类型仅包含高度信息一种，其信息显示模式为m1/m2/m3，其中，m1，m2，m3分别代表正确、缺失和错误三种信息显示模式，故该案例故障模式类1的信息显示模式合集如下表6所示；

表6401航班事故案例故障模式类1的信息显示模式合集

第二阶段：401号航班事故案例的模式混淆门的输入输出运算

步骤三：根据案例事故情景，建立相应的动态故障树模型

依据401号航班事故情景描述，建立故障树模型如图3，该故障树中的模式混淆门输入事件数量为2；

步骤四：统计事故案例的信息显示模式情况，分析模式混淆门的输出事件

塔台获取飞机高度信息具有三种来源，包括塔台监视器仪表的雷达高度数据、目视飞机位置数据和经由通讯获得的机组人员回复。此时，塔台需要从所有信息获取渠道得知该信息。依据案例描述得知，401号航班飞机飞行情景为夜间无月，因此塔台无法通过目视获得飞机的位置，即通过环境获得信息的信息显示模式为缺失(m2)，而是需要通过与机组联系询问高度是否正常来进行飞机高度信息的复核验证，并进行判断决策。当不给定信息获取渠道的优先级时,401航班事故案例的信息显示模式情况如下表7所示；

表7401航班事故案例的信息显示模式情况

由此获得该故障模式类内所有信息类型的信息状态，人通过感知该信息状态的信息进行判断决策，即得到模式混淆门的输出事件；

步骤五：构建输入事件与输出事件真值表

通过分析输入事件是否发生与信息状态的影响关系，构建输入事件与输出事件的对应真值表8。

表8401航班事故案例的输入事件与输出事件真值表

附注1：其中，1表示发生，0表示不发生；

步骤六：根据已知条件，分析事故案例

当输出事件对应的故障模式与事件x4相同，则未发生模式混淆，否则就认为发生了模式混淆。条件判定事件x4通过功能相关门(即“fdep”)与触发事件x1相连，当触发事件x1发生时，事件x4发生。当条件判定事件x4未发生时，塔台未感知到飞机的高度异常信息，此模式混淆门无法发生；当条件判定事件x4发生时，塔台感知到雷达显示飞机高度异常信息，塔台开始判断飞机高度异常信息是否正确，有可能经由模式混淆门导致事件x3发生。依据条件判定事件x4和案例描述，本案例的模式混淆门分析中不考虑雷达不显示和通讯系统故障的情况，因此不考虑表7中的塔台经由人机交互界面和通讯获取的信息为缺失，即情形2、4、5、6、8；

①当输入事件x5发生时，塔台认为机组的飞机高度信息更值得信赖，因此会以通讯获得的飞行高度信息为准；

②当输入事件x5不发生时，塔台认为雷达的飞机高度信息更为可靠；

当输入事件m1，x5同时发生，条件判定事件也发生时，输出事件为m4，塔台也未发现飞机高度异常，发生了模式混淆，因此401航班事故发生。