CN103425817A - 用担忧状况图辅助分析飞行器系统故障容差的方法、设备 - Google Patents

Abstract

用担忧状况图辅助分析飞行器系统故障容差的方法、设备。本发明的目的尤其在于辅助分析飞行器系统的故障容差，包括多个子系统，其中至少一个包括利用担忧状况图来监测和通知检测到的事件的部件。在选择(900)了可被接收的、由所述担忧状况图的顶点表示的至少一个通知消息之后，识别(905)可以导致产生所选择的至少一个通知消息的最小诊断集合的元件，所识别的元件属于故障容差报告。

Description

用担忧状况图辅助分析飞行器系统故障容差的方法、设备

技术领域

本发明涉及复杂系统(特别是飞行器)的零件的诊断，更具体地说，涉及利用担忧状况图(graphe d’événements redoutés)来辅助分析飞行器的系统的故障容差的方法、装置和计算机程序。

背景技术

在飞行器中的最近的故障诊断系统一般利用由制造商和电子设备制造商在飞行器研发周期中制订的故障模型。它可以用来在所考虑的飞行器上或者在地面上例如通过网络(web)类型的服务来建立预防性诊断。

这些诊断系统可以利用来自于设备监测系统的消息，设备监测系统包括自动诊断应用软件，在英语中亦称“Built-In Test Equipment(内置设备测试)”，报告针对从监测系统检测到设备起可能出故障的设备的维护消息。

于是，例如，以名称OMS(英语On-board Maintenance System(机载维护系统)的首字母缩写)已知的，特别是在Airbus(Airbus和A380是商标)公司的飞行器A380中实施的诊断系统，允许重组从设备监测系统接收的消息，并访问在飞行过程中产生的报告，以便进行允许识别要出现的潜在故障的统计分析。

在这里消息的重组是由集中维护系统，称为CMS(英语CentralizedMaintenance System(集中维护系统)的首字母缩写)的应用软件进行的，它采集和整理这些维护消息，以便识别允许对地面上的设备很好地进行维护的最直接相关的维护消息。这样的消息显示出现故障的设备以及基于统计分析(如MTBF(英语Mean Time Between Failures(故障之间的平均时间)的首字母缩写))的可能出现故障的消息。

访问在飞行过程中产生的报告，一般旨在访问以名称ACMS(英语AircraftCondition Monitoring System(飞机状态检测系统)的首字母缩写)已知的报告，它是系统地在每次飞行的某些阶段上或当检测到特定事件(例如，飞行器给定的参数低于预定的阈值)时产生的。于是，这样的报告代表飞行器的设备的若干参数的状态的视图。将因果加以联系，这些ACMS报告允许运营该飞行器的航空公司跟踪其状态并当需要时进行干预。

某些飞行器制造商在称为AHM(英语Airplane Health Management（飞机健康状态管理)的首字母缩写)的与飞行器发出的报告以界面相连的地面系统中提供预防在飞机驾驶舱中出现的故障的可能影响(英语术语称为FDE(Flight DeckEffect(飞行甲板影响))的可能性。为此目的，针对由飞行器的CMCF(英语Centralised Maintenance Computing Function(集中维护计算功能)的缩略语)功能报告并与这些消息的历史有关的维护消息，AHM计算和调整用语执行维护的剩余时间(英语术语称为TTF，是Time To Failure(到发生故障的时间)的缩略语)。

为了规划预防性维护任务，航空公司需要预先知道即将到来的工作异常。但是，在最近一代飞行器(其中这些系统非常相互依赖，加入复杂的故障模式组件并具有简单故障的容差体系结构)上这是不足够的。

故障容差能力允许飞行器即便有一个设备有故障，飞行器仍旧可用。最小功能设备列表(英语术语称为MEL，Minimum Equipment List(最小设备列表)的缩写)定下一些条件，按照这些条件，其中至少一个设备处于担忧状况的飞行器仍能被使用(英语术话称为dispatch(调度)的能力)。作为举例说明，航空公司可以得到准许在10天中运营带有处于故障的某些设备的飞行器。于是，这些运营条件被MEL划定范围并往往伴以强制的维护动作，以便检查处于运行状态的与有故障的设备相关联的设备，和/或手动保证安全地禁止有故障的设备。

故障容差能力还允许航空公司运营一个飞行器，同时并行地准备购买和供给备用设备以及相关联的维护。

在这种背景下，不仅需要获得飞行器中设备的故障状态，以便决定其运营，而且此外，运营该飞行器的航空公司希望准确地知道影响重大的工作异常(例如，在MEL中所谓NO GO的状态)突然到来之前剩余的容差裕量，该容差裕量不准许航空公司在该状态下或在乘客登机与可由航空公司给出的图像不一致的情况下(例如视频系统在舱内不工作)运营飞行器。

存在提供预防性维护和故障容差信息的需求。

本发明允许解决前面阐述的问题中的至少一个。

发明内容

于是，本发明的目的在于计算机辅助建立飞行器的复杂系统的故障容差报告的方法，该复杂系统包括多个子系统，多个子系统中的至少一个子系统包括至少一个检测到的事件的监测装置和通知装置，该方法的特征在于：

实施至少部分地对所述复杂系统进行建模的担忧状况图，所述担忧状况图包括多个顶点，所述多个顶点中的每个顶点都用逻辑隐含关系连接至所述多个顶点中的至少另一个顶点，所述多个预点包括：

-每一个都表示能够被接收至的通知消息的多个顶点；

-表示担忧状况的至少一个顶点；和

-每一个都表示所述复杂系统的一个元件的多个顶点，每个元件都用可能发生故障的顶点表示；

该方法包括下列步骤：

-接收实现所述至少一个检测到的事件的至少一个通知消息；

-创建与所述至少一个检测到的事件相关的最小诊断集合，最小诊断集合包括被怀疑导致所述至少一个检测到的事件的多个元件，所述最小诊断集合的每个元件都用所述担忧状况图的一个顶点表示，并根据所述担忧状况图的至少一个与表示接收到的所述至少一个通知消息的一个顶点的逻辑隐含关系来确定；

-选择用所述担忧状况图的一个顶点表示的能被接收到的至少一个通知消息；和

-识别所述最小诊断集合中的能够导致产生所选择的至少一个通知消息的元件，所识别的元件属于所述故障容差报告。

根据本发明的方法尤其允许借助故障在该系统中传播的优选为穷尽的物理知识，而不依赖统计，来识别尚未声明处于故障、但是其故障会导致担忧状况的指责对象(objet accusable)。这个识别对于做出决定非常重要。事实上，若容差裕量仅例如由于在飞行器目的地位置剩有非常昂贵的LRU，则这样的信息允许例如避免飞行器出发。在这种情况下，飞行器长时间停飞等待备用LRU的风险大。反之，若容差裕量被打破，但是后勤和备用件维护就成本和操作而言不是问题，让飞行器出发的风险小些。

这个方法以系统的物理和拓扑知识(例如，与AMDEC(Analyse des Modesde Défaillances，deleurs Effets etde leur Criticité(故障模式、其影响及其临界性分析，也叫FMEA)的字首词)和设备最小列表(MEL)一致的飞行器物理和拓扑知识)为基础，它尤其允许基于系统的体系结构知识来获得关于故障容差的剩余裕量的信息。它还允许知道处在将出现的影响较大的工作异常路径上、但仍能继续运行的设备的列表。这些信息的获得可以实时地实现并传送至远程系统，例如，从飞行中的飞行器向地面系统传送。

可以获得一些属性并将其赋予所识别的元件。

所述担忧状况图可以至少部分地由至少一个一般子图的实例化产生，以便简化创建和管理。

该方法最好还包括针对所识别的元件中的至少一个元件来计算在紧迫影响之前的剩余距离，所述剩余距离是根据以下这样的元件的数量来计算的：这些元件不属于所述最小诊断集合并且要产生所选择的至少一个消息需要这些元件发生故障。

按照一个特定的示例，识别元件的所述步骤包括从所述担忧状况图中提取至少一个子图的步骤，所述至少一个子图包括表示能够由所述最小诊断集合的一个元件的故障产生的至少一个消息的至少一个顶点。该方法最好还包括把与所述至少一个子图的顶点相关联的消息与所选择的至少一个消息比较的步骤。

该方法还最好包括响应于比较的步骤、基于所述至少一个子图来创建第二最小诊断集合的步骤，前述最小诊断集合称为第一最小诊断集合；以及还包括在所述笫二最小诊断集合中选择最小诊断的步骤，所识别的元件是由对最小诊断的所述选择产生的。

于是，按照本发明的方法允许根据分析要求和诊断结果来确定故障容差的分析目标。

该方法最好还包括产生所述故障容差报告的步骤。

按照一个特定的示例，该方法还包括选择针对所识别的上述至少一个元件的至少一个故障解决过程的步骤。

本发明的目的还在于提出一个计算机程序，包括适于当所述程序在计算机上执行时实施根据前述权利要求中任一项的方法的每个步骤的指令，以及在于包括计算机的飞行器的维护系统，它包括实施先前描述每一个方法步骤的装置。该计算机程序和该系统带来的优点与上述类似。

附图说明

从参照附图作为非限制性示例在下文所作的详细描述中，本发明的其他优点、目标和特征将变得明显，附图中：

-图1示意地表示建立飞行器系统的诊断的辅助的方法的某些步骤；

-图2举例说明担忧状况图的一个示例；

-图3举例说明与两个系统相关联的担忧状况图的一个示例，每一个系统都用不同担忧状况的子图表示；

-图4表示在图2上举例说明的担忧状况图，还包括与来自由担忧状况图表征的系统的监测系统的消息相关联的顶点；

-图5举例说明按照相似性产生担忧状况图的算法的一个示例；

-图6，包括图6a和6b，举例说明基于担忧状况的一般子图来产生担忧状况图的一个示例；

-图7举例说明基于监测系统和担忧状况图收到的通知的飞行器系统的诊断的辅助算法的一个示例；

-图8，包括图8a和8b，举例说明参见图7描述的算法的某些步骤；

-图9举例说明故障容差分析算法的一个示例；

-图10举例说明当ECAMEM1消息被选择为检测时，基于图4所示的担忧状况图来获得担忧状况子图的一个示例，其中指责对象S1是在一个故障识别步骤结束时被怀疑的指责对象，而且MM1消息已经被告知；

-图11举例说明基于预先算出的最小顶点，对最可能的疑点和障碍给出对策以便于进行预防性诊断操作的算法的一个示例；

-图12举例说明其中在两个障碍之间呈现覆盖关系的担忧状况图的一个示例；

-图13和14举例说明本发明的两个实施方式；以及

-图15举例说明适于实现本发明的某些步骤的硬件体系结构的一个示例。

具体实施方式

总体而言，本发明旨在提出一种利用基于安全研究时开发的故障树(英语术语fault tree)而建立的担忧状况图(或者英语术语failure condition graph(失效条件图))对飞行器系统进行预防性诊断和故障容差分析的系统。

如图1所示，建立诊断报告的总体方法在这里分解为几个阶段。第一阶段(阶段100)旨在进行担忧状况图的建模。参照图2和3描述这样的建模的一个示例。第二阶段(阶段105)旨在给预先建模的担忧状况图赋予故障消息码。第三阶段(阶段110)包括实时地或者有差别地获得由飞行器监测系统定出的状况检测通知。在第四阶段(阶段115)，由基于所检测到的状况和所建模的担忧状况图来提供飞行器的辅助诊断的机器执行故障识别算法。

识别出故障之后，独立地进行几个步骤和/或步骤序列，以便为每个潜在地出故障的设备选择最优的解决故障的过程而且其中该故障可能导致系统的当前配置(阶段120)，在其当前配置下分析系统的故障容差(阶段125)，并建立其预防性诊断(阶段130)。在这些步骤过程中获得的结果允许建立诊断报告(阶段135)。

正如用虚线箭头举例说明的，最好重复最后几个阶段，以便允许分析所有检测到的状况，例如，随着检测而检测到的所有状况。

按照一个特定的实施方式，担忧状况图的建模是从飞行器的几个系统的、最好基于所有系统的担忧状况图的建模来实现的。担忧状况图可被认为是安全研究时开发的故障树的扩展。在这里其特征如下：

-该图是有向的，它可能包括一些循环；

-该图包括至少三种类型的顶点：

○指责对象，其指示设备、最好指示可替换的设备(特别是LRU(英语LineReplaceable Unit(在线可替换单元)的首字母缩写)型计算机)、应用软件、电缆和运行状态，如功能失灵的设备重新置零(复位)或者系统的异常运行状态(诸如，例如，马达的超运转、制动失控或者进气口有冰的运行状态)。有利地指定特定属生以把每个“指责对象”顶点分类为两组，即，持久的指责对象和非持久的指责对象。持久的指责对象是一旦出现故障，若不进行维护动作，则其故障是不可逆的。非持久的指责对象是所有其他对象；

○担忧状况，英语术语称为failure condition(失效条件)，指示通过该图建模的系统故障状况；以及

○逻辑门，指示逻辑操作，例如，逻辑或、与、非(NEG)的操作或者“n中取一”类型的门(其中n是表示激活阈值的非零的自然整数）；

-该图的每个弧都是有向弧，表示它所连接的两个顶点之间的逻辑隐含关系，该弧的起点可以认为是一个影响的原因和目的地；

-该图的所有顶点覆盖针对安全分析（system safety analysis(系统安全分析)或者FMEA系统)而进行的AMDEC(Analyse des Modes de Defaillance，deleurs Effets etdeleur Criticité(故障的模式、其作用及其临界的分析))分析的所有故障树。换句话说，在FMEA系统中出现的所有故障树都是担忧状况图的一个子图；

-指责对象类型的所有顶点包括维护手册中已知名为TSM和AMM的所考虑的所有可替换的单元或模块(LRU和LRM，英语Line Replaceable Module(在线可替换模块)的首字母缩写)；和

-在所考虑的系统的MSG-3类型的分析中定义的所有功能故障(Functional Failures)都包括在该图的担忧状况类型的所有顶点中。

该担忧状况图可包括几百万个顶点和弧。

要指出，一个图可有不同的完备程度。例如，与布线相关联的指责对象可能没有列入系统的图的自动缩减版本中。可是，缩减后的图使得对在线维护有意义的第一诊断水平成为可能并允许其中制造商提出基于完整的图的详细诊断服务的实施方式。

图2举例说明一个这样的担忧状况图200的一个示例。在这里圆代表担忧状况图的顶点，而箭头代表图的弧。圆205至225，用实线表示，代表担忧状况类型的顶点，圆230至240，用虚线表示，代表逻辑门类型的顶点，而圆245和250，用点划线表示，代表指责对象类型的顶点。这样，例如，在S1(245)设备(在这里是软件应用)中的异常可能引发担忧状况E2(210)。同样，设备L1(250)(在这里是一个LRU)中的异常可能引发担忧状况E3(215)。另外，担忧状况E2(210)或者担忧状况E3(215)的发生，根据把担忧状况E2和E3连接至担忧状况E1的或逻辑门OU(230)，引起担忧状况E1(205)的发生。

一个系统的每个子系统都可以用一个担忧状况子图表示。这样，当担忧状况图关联到一个包括几个子系统的系统时，每个子系统都关联到一个担忧状况子图，在该担忧状况图中存在担忧状况类型的顶点，它起到这些担忧状况子图之间的界面作用，表示相应的子系统之间的因果关系。这样的顶点最好用特定的属性识别。图3举例说明连接至两个子系统(在这里是致动器类型的子系统和电源类型的子系统)的担忧状况图300的一个示例，每一个子系统都分别用附图标记305-1和305-2标记的担忧状况的不同子图表示。

这些圆仍然代表担忧状况图的顶点，而箭头代表图的弧。这些用实线表示的圆代表担忧状况类型顶点，用虚线表示的圆代表逻辑门类型的顶点，而用点划线表示的圆代表指责对象类型的顶点。用双实线表示的圆代表在两个系统之间起接口作用的担忧状况类型的顶点。

作为举例说明，根据担忧状况子图305-2中的“或”逻辑门325，在断路器310或汇流条315中检测出异常是担忧状况“汇流条掉电”320的原因。由于担忧状况“汇流条掉电”320是一个在子图305-1和305-2之间起接口作用的顶点，所以根据弧335，它是担忧状况子图305-1中的担忧状况“致动器掉电”330的原因。

这样以担忧状况图的形式表示的优点，尤其与安全分析用的模型的一致性相关，它允许用同一形式表示对系统、对高级的担忧状况、直至系统组件层次的担忧状况的认识，并且因此把电子设备制造商和飞机制造商的认识数据重组在单个数据库中。它还允许通过利用图覆盖理论来建立形式验算，从安全观点看，这些担忧状况被在辅助诊断系统中使用的担忧状况图充分覆盖。

担忧状况图建模之后，下一个阶段(图1的阶段105)旨在识别担忧状况图中示出的担忧状况和可由与该担忧状况图相关联的飞行器系统的监测系统(BITE)、机组成员或操作人员检测出来的事件之间的关系，这些事件一般实时地检测。检测出来的事件是，例如，用相应的监测系统发出的消息通知的。它同样可以由被通知的人员观察导致。

维护消息、故障报告、ACMF(英语Aircraft Condition MonitoringFunction(飞机状态监测功能)的首字母缩写)功能监测参数、ECAM(英语Electronic Centralised Aircraft Monitor(飞机电子集中监测)首字母缩写)类型的消息、FWS(英语Flight Warning System(飞行报警系统)首字母缩写)报警系统的报警、或者驾驶员在电子飞行记事本(英语术语Electronic Logbook)中的输入特别是飞行器中出现担忧状况的自动通知。因而，这些消息以及必要时类似的消息是与担忧状况图中的担忧状况相关联的。为此目的，通知类型的顶点加入担忧状况图并在送些新顶点和担忧状况类型顶点之间建立有向连接。

借助于基本(法语中的du premier ordre)的简单逻辑便可以建立这样的关系。于是，例如，如图4所示，表示一个基于参见图2描述的图的担忧状况图，EM1(ECAM类型消息)消息，在这里用附图标记400标示，目的是通知担忧状况E1(205)的实现可以用通知类型的顶点表示在担忧状况图上，该通知类型的顶点用孤连接到表示与之相关联的担忧状况的顶点，就是说，在这里的担忧状况E1(205)。同样，维护消息MM1(405)，目标是通知担忧状况E2(210)的实现在这里在担忧状况图上用顶点表示，并与表示相应的担忧状况的顶点连接。

在这里注意到，检测到的、用消息通知的事件对应于一个担忧状况或一些担忧状况的结合随时间的特定实例化(法语中的instanciation)。于是，尽管为了清晰起见，在这里该担忧状况图包括通知类型的顶点，但是担忧状况图的担忧状况可以直接基于通知消息而获得，而不需要在担忧状况图中实现通知类型的顶点。

举例说明，检测到液压流体压力值小于345巴并传递相应消息的监测单元(BITE)是通知出现“液压非常低”类型的担忧状况的装置。于是，可以在该消息和该担忧状况之间建立连接。同样，检测到制动器用的液压储能器的压力小于8巴的监测单元是另一个通知“制动功能用的储能器中液压压力非常低”，类型担忧状况的装置。

换句话说，这个阶段允许把与监测系统的消息相关联的认识引入预先建模的担忧状况图中。

这个阶段尤其允许按照同一形式体系、与相应的担忧状况相关联地重组维护消息、FWS消息，特别是ECAM类型的消息和报警消息、ACMF监测参数以及飞行器在地面上进行的测试结果。

它还允许在所考虑系统的非专业用户容易理解的担忧状况图中，在基本逻辑的基础上获得一些监测系统中检测到的事件的简单表示。另外，它还允许通过计算由通知顶点及其所有祖先顶点(就是说具有向所考虑的通知类型顶点的逻辑隐含连接的所有指责对象类型顶点)产生的担忧状况子图来对发出维护消息的这些系统的监测系统软件(内置测试)的诊断的覆盖和精度，进行形式验算。于是，例如，图4上附图标记410标记的子图表示由对应于消息通知MM1(405)的顶点产生的子图。在这里祖先顶点是经由至少一个担忧状况类型顶点连接至通知类型顶点的指责对象类型的顶点，祖先顶点可以被认为是(被两个顶点之间的连接方向确定的)起因。

由不同制造商提供的监测系统软件(内置测试)之间的独立性，是通过该模型中对接口类型的担忧状况节点的使用而得到保证的。这些节点使确定备系统之间的接口的规范变得容易并形式化。另外，这种表示允许在同一系统或其他系统中对飞行器设备的在其功能或其故障方式方面的改变的后果进行自动分析。这样的分析可以借助于逐步地自动追溯图并列出可能由设备的这个改变产生的担忧状况的算法而实现。

这个阶段还允许设计者定义要用每个维护消息实现的失灵或故障管理过程(英语术语亦称trouble-shooting(故障排查))覆盖目标。最后，可以被用作地面上故障管理用的推理模型，这是因为它表示可以导致飞行中通知的担忧状况所有可能工作异常分支。

这些担忧状况图的建模和故障消息码的赋值的阶段(图1的阶段100和105)可以加以改进，以便通过利用图样式(英语术语亦称graph patterns)和实例化表来简化图的建立和管理。

在这里，图样式是一般图，其中顶点表示担忧状况而指责对象表示可以取像所考虑的系统中的相似性同样多的值的一般事件和对象。

举例说明，一个飞行器一般都具有两个时称和类似的机腹起落架。对这两个起落架的分析和建模是冗余的，因为所获得的担忧状况图将具有相同的形式，只是顶点的名称不同，第一图涉及左边起落架零件并且第二图涉及右边起落架零件。同样，为了赋予消息码，若左边起落架的监测技术类似于右边起落架，则进行两次分析是无用的。

于是，图1的步骤100和105可以用步骤500至515补全，如图5所示，它举例说明图产生算法的一个示例。

第一步旨在识别要建模的系统的所有相似性(步骤500)，就是说，该系统的识别具有类似结构的子集的所有各组。这可以通过按照预定标准的系统分析或通过运算装置来自动进行。

在下一步骤(步骤140)，对担忧状况的一般图进行建模，并赋予故障消息码，正如参照图1的步骤100和105所描述的那样。如虚线箭头所示，赋予代码的这个图的建模步骤是针对识别出来的每个相似性进行的，也就是说，针对具有类似结构的子集的每个组进行的。

这时，分析(步骤505)这样建模的一般图，以便针对每个一般顶点来识别在所考虑的顶点名称中的根据相似性而改变的一个或多个参数。

于是，例如，考虑，一般图的一个顶点具有名称“丢失由计算机输送的门[x]的门自动锁紧信号”，而且该飞行器上有十个类似的门，命名为P₁至P₁₀，在顶点名称中的参数是[x]，它取实例化值P₁至P₁₀。

接着，针对每个一般图，按照相应子集中的图参数值(步骤510)来建立参数实例表。例如，这样的表包括所考虑图中的一般参数名，并针对所考虑的组的每个子集包括参数值。

举例说明，附件(表1)给出参数实例表。在这里，每一行表示给定的一般模型的一个参数。第一列包含该参数的名称，而以后各列包含用于每次实例化(就是说，针对用该一般图表示的每个子集)的该参数可能取的值。作为举例说明，该参数实例表在这里包括参数#Param1#、#Param2#、#Param3#和#Objet_accusable_générique1#，每一个都可以按照三个值实例化。该表是从图6a所示的图样式和时要建模的系统的描述(未示出)得出的。

回到图5，该一般图然后按照所有可能的实例进行实例化，以便产生相应的担忧状况图(步骤515)。

举例说明，在这里考虑图6a举例说明的一般图，它是基于一个正如参见图5所描述的要建模的系统而获得的，还考虑参数实例表也是基于该系统用图6a上举例说明的一般图获得的。

如同图2、3和4所示，圆代表担忧状况图的顶点，而箭头代表图的弧。圆605和615用实线表示，代表担忧状况类型的顶点，圆610用虚线表示，表示逻辑门类型的顶点，而圆600用点划线表示，表示指责对象类型的顶点。

菱形620对应于ECAM类型的维护消息，目的是通知担忧状况的出现。

用附图标记600表示的一般设备中的异常能够触发附图标记605表示的一般担忧状况，而它本身又能够触发用附图标记615表示的一般担忧状况，后者可能被另一个原因触发。用附图标记615表示的一般担忧状况的实现触发用附图标记620表示的一般维护消息。

图6a举例说明的一般图中涉及的一般参数在附件的表1中定义。如上所述，在这里表1包括四列，其中一列包含参数名，每个参数可以包括三个值。举例说明，参数#Param3#分别按照第一、第二和第三实例可以取值E11、E12和E13。仍举例说明，分别对于参数#Param1#、#Param2#、#Param3#和#objet_accusable_générique1#，第一实例涉及数值EM1、E10、E11和LRU L1。

图6a所示的一般图用附件表1定义的实例化值进行的实例化允许产生图6b所示的担忧状况图。

由于该参数实例表中定义的值，该担忧状况图包括三个特定的分支和一个共用分支(附图标记610′，615′和620′)，每个特定分支专属于一个实例(附图标记600′-i和605′-i，其中i表示实例编号(从1到3)。

参见图5描述的步骤相对于参见图1描述的步骤带来的优点，单独考虑，特别是以下优点：

-担忧状况图的分析和编辑工作负荷减为与在要建模的系统中呈现的相似性的数目相关联的系数。于是，例如，考虑包括5个类似的主桥门的A380(A380是商标)类型的飞行器，为了产生门管理子系统的担忧状况图，建模工作量除以约5。

-担忧状况图的便利验证与这样的事实相关联，即可能的实例以表的形式呈现，该表给出逐列验证数据的相干性的机会；

-由于只有可变参数变化，所以最终担忧状况图的一致性和质量得到改善。另外，这样的算法允许应用担忧状况图的顶点命名规则，减少可能的差错并简化其读出；和

-基于专业人员的认识，一般图的样式的存储可以用于不同类型的类似飞行器的建模的可能性。这种途径允许在飞行器模型之间知识的转移，而且不退化(在上几代飞行器图样式上学到的教训可用于新生代的飞行器)。

回到图1，当担忧状况图已经建立，而且与监测系统中检测到的事件相关联的消息和担忧状况图的担忧状况类型顶点之间的关系已经建立时，即可实时地或者在不同的时间获得与在监测系统中检测到的事件相关联的消息(阶段110)，以便处理。尤其是通过接收飞行器定期发送的消息，例如，ACARS(英语术语(Aircraft Communication Addressing and Reporting System(飞机通信寻址和报告系统)的字首词)类型的消息，通过集中维护系统(CMS)可在飞行器机上或在地面上获得这些消息。

这个获得消息的阶段目的还在于确定担忧状况图中实现的逻辑表达式中使用的最小参数列表，特别是ACMS参数，以便允许进行数据诊断操作并访问这些参数值，以便允许估计这些逻辑表达式。

下一个阶段(阶段115)特别是包括利用担忧状况图(静态的和先验的知识)、所识别的参数值、和监测系统的通知(动态的和实时地接收的认识)，以便在给定时刻实现与担忧状况图相对应的系统诊断的辅助。

为此目的，该担忧状况图允许在其中已经收到相应通知的担忧状况之间建立因果关系，并把这些担忧状况与其他传播源隔离。该图还允许通过计算顶点最小集合(或者英语术语hitting set(命中集合))，也就是说，可能导致所考虑的每个担忧状况的指责对象配置的充分集合，来推断通过指责对象的最小数目的怀疑进行的辅助诊断。

图7举例说明基于如前所述的担忧状况图和监测系统接收的通知来进行辅助诊断的一个算法示例。

从监测系统收到至少一个通知(步骤700)之后，在担忧状况图中，按照预先建立的联系(图1的阶段105)，识别(步骤705)出该一个或多个相应通知类型顶点N_i。

在下一步骤(步骤710)中，识别出的通知类型顶点N_i用来遍历担忧状况图，并选择源担忧状况的集合O，源担忧状况也就是说，可能触发与识别出的通知类型顶点N_i直接联系的担忧状况。集合O的每一个源担忧状况使得：

-不存在不能推导出的与所识别的通知类型顶点N_i直接关联的担忧状况；和

-其出现时间间隔包括在后序事件出现间隔中。

为了保证各事件之间的因果关系，与识别出的通知相关联的消息的出现时间之间的包含条件最好在建立集合O时实现。按照这个条件，O是N_i的子集{E_j｝_{j ∈J}，使得对于包括在N_i内的任何元素E′和包括在O内任何元素E_j，或者E′不包含E_j(

E′＝＞E_j)，或者E_j的出现间隔不包含在E′的出现间隔内。

( $I_{E_j}\⊂⃒I_{E^{\′}}$ 且 $I_{E_j}\≠I_{E^{\′}}$ )

在下一步骤(步骤715)中，该算法遍历集合O每个源担忧状况的祖先顶点的子图。该算法追溯该子图直至指责对象，并在其遍历中应用担忧状况图的这些逻辑门以便构造基于指责对象和逻辑“与”、“或”或者“非”逻辑算子而形成的简化逻辑表达式。这个表达式构成所考虑的源担忧状况的逻辑解释。为此目的，引入逻辑谓词Ab(.)(英语术语Ab表示abnormal(异常))。它代表一个允许怀疑指责对象的逻辑函数。于是，例如，Ab(致动器)想说怀疑致动器出现故障。举例说明并如图8a所示，

-担忧状况E1用逻辑表达式：Ab(AccObj₅)“或”Ab(AccObj₇)说明

-担忧状况E2用逻辑表达式：Ab(AccObj₇)“或”Ab(AccObj₁)说明

-担忧状况E3用逻辑表达式：Ab(AccObj₁)“或”Ab(AccObj₄)说明

在下一步骤(步骤720)中，源担忧状况用以下方式重新分组：若其相关联的(先前确定的)逻辑说明有至少一个共同的指责对象操作数，则这两个担忧状况E_i和E_k重新分组在同一集合P_j中。

重新采用基于图8a的上述示例，事件E1、E2和E3(被认为是源担忧状况)重新分组在同一集合P₁＝{E1，E2，E3｝中，这是因为解释这些源担忧状况E1和E2的逻辑表达式具有同一操作数Ab(AccObj₇)，而阐明源担忧状况E2和E3的这些逻辑表达式有同一操作数Ab(AccObj₁)。

于是，两个组P_j和P_k构成不同源的两个分组并允许隔离不同的被怀疑的指责对象集合：考虑被P_j怀疑的指责对象集合和被P_k怀疑的指责对象集合，这些集合是分开的。每个分组P_k表示存在障碍F_k，障碍F_k的诊断是可以基于该分组推导出的指责对象来形成的。

对于分组P_k，障碍F_k是担忧状况的子集，使得：

-分组F_k包括在分组P_k内或者等于分组P_k；

-分组F_k是最小基数(cardinalité)；以及

-P_k\F_k的所有元素在分组F_k中有至少一个祖先。

于是，例如，若分组P_k等于{E1，E2，E3｝，则利用在图2上举例说明的图，障碍F_k等于{E2，E3}，这是因为根据图2上所示的图，E2和E3是E1的祖先。

在下一步骤(步骤725)中，计算每个集合P_k的覆盖每个源担忧状况E_i的指责对象最小顶点(minimalhitting set(最小命中集合))。

集合P_j的覆盖给定担忧状况的指责对象的顶点在这里定义为对和这些与该担忧状况E_i相关联的逻辑表达式相一致的指责对象的谓词合取(conjunction deprédicat)。

于是，作为举例说明并参见图3，与“调节失灵，”担忧状况相关联的逻辑表达式Ab(致动器)“和”Ab(供电电缆)与逻辑表达式Ab(致动器)“或”Ab(供电电缆)“或”Ab(断路开关)“或”Ab(汇流条)相一致。

在这里最小顶点定义如下：在顶点集合{V_n｝中，一个顶点V_m∈{V_n｝被称为最小，是在不存在能够从V_m逻辑推导出的{V_n｝的另一个顶点的情况下。

于是，例如，顶点Ab(致动器)是从顶点Ab(致动器)“和”Ab(供电电缆)推导出的。因而，顶点Ab(致动器)“和”Ab(供电电缆)不是包含这两个顶点的集合的最小顶点。

在这里，这些最小顶点代表对于每个与分组P_k相关联的障碍F_k的最小诊断。换句话说，一个分组P_k的最小顶点是可以解释分组P_k的所有担忧状况的指责对象的最小逻辑表达式。按照参见图8a先前给出和在图8b上示出的示例，对于分组P₁＝{E1，E2，E3｝，最小顶点V_r是下列指责对象的逻辑表达式，

V1：Ab(AccObj₁)“和”Ab(AccObj₇)

V2：Ab(AccObj₁)“和”Ab(AccObj₅)

V3：Ab(AccObj₄)“和”Ab(AccObj₇)

举例说明，顶点V4(Ab(AccObj₁)“和”Ab(AccObj₇)“和”Ab(AccObj₄)不是分组P1的最小顶点，因为它由此推导出最小顶点V1{Ab(AccObj₁)“和”Ab(AccObj₇)}。

然后，每个集合P_k的指责对象的最小顶点可以重新分组，以便代表允许通过所检测的事件通知消息来解释所有所识别的担忧状况的所有指责对象。

在辅助诊断系统中使用担忧状况图允许通过最小顶点(最小命中集合)进行核对的可能性来提高诊断的精度水平，这允讲在时间方面优化在地面上的故障管理过程，从而降低维护成本。

另外，加强了最终诊断的完备性水平。事实上，该诊断是基于担忧状况图的指责对象来表达的。通过它的结构，它覆盖可以解释随后故障的所有已知起因：可替换的设备(LEU)、软件(software)、电缆或运行状态(如设备的再次初始化(reset)或者异常运行状态)。

另外，在诊断和消息或通知报警之间建立的关系(可以在担忧状况图上查看)可以用在中途停留的飞行器的在线维护操作期间，以便解决与驾驶员在飞行报告(logbook)中报告的特定症状(ECAM、报警等等类型的消息)相关联的原因。通过利用该担忧状况图，辅助诊断系统不是作出故障和症状之间的相关性关系，而是建立与安全分析相一致的因果性关系，从而尤其可以用于调查，具体地说，在事故的范围内。

另外，与诊断结果相关联地，该担忧状况图可用于故障管理过程。事实上，这样的过程通常包括测试图的与指责对象相关联的其上存在故障疑问的下层分支，这是因为通知消息的集合是不足以消除这些疑问。为了消除模糊性，该故障管理过程可以依赖图，以便确定疑问区域的范围，接着求助于由ACMF参数或者航空电子学测试结果引起的新型通知。

回到图1，在阶段115过程中所识别的最小顶点，尤其可以用来选择故障解决过程(trouble-shooting(故障排查))。

于是，图1用附图标记120标示的步骤旨在针对先前计算的每个最小顶点在故障排查手册(常称为TSM，英语Trouble-Shooting Manual(故障排查手册)的首字母缩写，或者FIM，英语术语FauIt Isolation Manual(故障隔离手册)的缩写)中选择最优的故障排查过程。故障排查手册的每个过程都测试一组指责对象(通过给定过程测试的指责对象的数量称为过程范围)。

这个步骤可以分解为两个部分。

在这个步骤的第一部分的过程中，在该故障排查手册中搜索出的其目标在于测试先前计算的每个最小顶点的所有指责对象的过程(其过程范围是最小的)的标号。对于各个最小顶点，这个过程集合形成故障排查过程的一个优化列表。

第二部分旨在识别几个顶点共同的过程。

这样获得的与故障排查过程相关的消息有利地与诊断报告相关联，以便允许进行最优的和有效的故障测试。

在这里要注意，在如在上面描述的故障排查手册中对过程的查找，可以如下改进：例如，按照其执行时间，把优先权赋予相对于最长时间的执行最快的过程，或者按照其实施，优选不需要任何工具的过程，其相对于需要地面上特定工具(称为GSE英语Ground Specific Equipment(地面专用设备)的首字母缩写)的过程。

举例说明，在这里假定，其分组P₁表示存在的障碍F₁用最小顶点V1＝{L1，L2｝或V2＝{L3}诊断，和其分组P₂表示存在的障碍F₂用最小顶点V3＝{L1，L4｝诊断。还假定，该故障排查手册包括下列过程：

TSM1：目标在于测试LRU L1、L2和L4的过程

TSM2：目标在于测试LRU L1和L3的过程

TSM3：目标在于测试LRU L3的过程

TSM4：目标在于测试LRU L3的过程

因此，在过程选择步骤120结束时获得的结果如下：

-对于分组P₁表现存在的障碍F₁，

○最小顶点V₁最优是用过程TSM1处理；而

○最小顶点V₂最优是用过程TSM3或者过程TSM4处理；

-对于分组P₂表现存在的障碍F₂，

○最小顶点V₃最优用过程TSM1处理。

因此过程TSM1是障碍F₁和F₂(其分组P₁和P₂表达其存在)的解决方案共用的。因此这个过程比其他过程有利。

这样的故障解决过程的选择步骤尤其带来如下优点：

-故障排查过程的动态选择，允许最优适应在该系统中呈现的故障结合(目前的解决方案一般不允许获得这样的结果，是维护操作者逐个地处理指责对象而不是明确确信系统地使用最直接的过程)；

-动态地识别解决几个障碍共同的过程，允许应用最少过程来解决几个障碍。因此，当准备维护动作时，任务卡(job card)的数目可以由运营所考虑的飞行器的公司的维护控制中心优化；

-故障排查手册的结构相对于故障解决过程的选择算法的独立性。换句话说，TSM文献独立于诊断系统。可是，TSM过程的标号可能在担忧状况图中制图，正如检测装置被制图，目的在于优化。

回到图1，在阶段115过程中所识别的最小顶点，同样可以用来进行故障容差分析并识别紧迫的高级担忧状况。

图9举例说明这样的故障容差分析算法。

第一步(步骤900)旨在建立担忧状况图的要对其实现故障容差分析的故障通知的检测的列表。换句话说，步骤900目的在于在担忧状况图中选择要时其实现故障容差分析的可能被检测出和利用的故障通知。所选择的这样的检测的列表可以被预先确定、由操作者建立、或者按照给出的标准自动地建立。

有利地所选择的每个检测与属性相关联。这样的属性包括，例如，下列属性：

-按照预定的分类对与该检测相关联的类别(famille)的引用，特别是可以包括元素，比如飞行器影响(effet_aéronef)、维护影响(effet_maintenance)和运营影响(effet_exploitation)；和

-与之相关的运行冲击的重要性，按照预定的比例，尤其可以包括三个等级(小、中和大)。

这些属性不是一定用在计算故障容差时，而且可用于辅助决定是否发出预防性维护动作。

举例说明，图4的ECAM EM1消息可能在步骤900时被选择，并分类归入运行冲击大的effet_aéronef类别。

在下一步骤(步骤905)中，执行故障容差的确定。其目标尤其在于针对所选择的每一个检测来确定是否超过与故障有关的故障容差，并且基于由先前(图1步骤115)实现的诊断怀疑的指责对象来识别可能导致相应的所选择的检测的担忧状况图的路径。该分析尤其允许识别担忧状况图中的其故障对所选择的检测具有直接作用的指责对象。

要注意，在步骤900过程中所选择的检测一般位于担忧状况图的这种高度，因为它们涉及高级的担忧状况。举例说明，这样的检测可能涉及ECAM消息，ECAM消息向驾驶员报告失去飞行器的功能(FCOM过程(英语Flight CrewOperating Manual(飞行机组成员操作手册)的字首词)，因此驾驶员应该应用适当的驾驶过程。

于是，步骤905目标在于识别预先选定的检测的列表，这些检测使得至少一个指责对象在图中的至少一个引向该检测的分支上是可疑的。以后有利地只研究这些检测，因为这是在飞行器中唯一受到被怀疑的故障冲击的。事实上，与总体不可用性分隔开的距离由于这些故障而减短了。

在此应注意，在某些状况下，例如，按照该飞行阶段，报警消息没有立刻显示以免干扰驾驶员。因而，可能存在没有向驾驶员显示的故障。因而，预先知道一个报警是紧迫的可能是有用的。

如图9所示，确定故障容差的步骤可以分解为几个步骤910至930。

在图1的步骤115过程中实现的诊断，必要时，允许识别导致障碍F_i存在的几个分组P_i。这些分组中的每一个分组都由可被认为是疑点集合的指责对象E_i最小顶点集合诊断出来。

在步骤910的过程中，从先前(图1步骤100)建立的担忧状况图提取子图。更准确地说，对于导致障碍F_i存在的每个分组P_i的每个疑点集合E_i的可疑的每个指责对象，由该指责对象和其后继的所有孤和顶点产生的子图都从担忧状况图提取出来。这样产生的子图的集合下文中称为SG。

在下一步骤(步骤915)中，识别集合SG的属于在步骤900建立的所选择检测的列表的事件通知检测。该步骤允许获得所选择的检测(对其应该实现故障容差分析)的列表，由于所选择的检测与可疑的指责对象的联系(由于这些检测隶属于集合SG)，所选择的检测可能在最近的将来被通知。这个检测列表下文中称为紧迫影响列表。

接着，针对紧迫影响列表中的每个检测I_i计算该指责对象的最小顶点(步骤920)。为此目的，可以利用先前参见图7描述的方法。于是，这个步骤允许对于紧迫影响列表的每个检测I_i获得指责对象的集合V_i，这可以用以下的形式表达：

I_i→V_i＝{v₁＝{AccObj_n｝_n，v₂＝{ACCObj_m｝_m，...｝

其中{AccObj_n｝_n表示由索引n(不一定连续的)的值的集合定义的指责对象(AccObj)的集合。

接着(步骤925)针对紧迫影响列表的每个检测I_i，对集合V_i(最小顶点集合)的指责对象进行选择，以便只保留包括由先前实现(在图1步骤115的过程中)的诊断怀疑的至少一个指责对象(指责对象集合)的顶点。这些顶点代表预防性诊断。因此，对于紧迫影响列表的每个检测l_i，获得集合V_i的子集w_i：

$I_i\→W_i\⊆V_i$

W_i＝{w₁＝{AccObj_o｝_o，w₂＝{AccObj_p｝_p，...｝

因而，每一个顶点W_i都包含至少一个被怀疑的指责对象。

在这里要注意，作为替代方案，包括被先前实现的诊断怀疑的至少一个指责对象的顶点的选择，可以在长度较小的、也就是说包含有限数目的指责对象最小顶点中(并且不在所有这些最小顶点中间)进行。要考虑的最小顶点的最大长度可以是预定的。

在下一个步骤的过程中，对每一个顶点w_i计算紧迫影响之前剩余的距离(步骤930)。紧迫影响之前剩余的距离被计算作为等于在所考虑的顶点中存在的以及在图1步骤115的过程中没有怀疑的指责对象的数目。于是，顶点w_i的距离di可以定义如下：

W_i→d_i＝Card{AccObj_j｝使得AccObj_j∈W_i并且

AccObj_j不是被怀疑的指责对象

这样获得的数据用以形成故障容差报告(步骤935)。更准确地说，故障容差报告尤其可以包括紧迫影响列表的检测I_i连同其属性(例如，类别和运行冲击的重更性)、与此相关的预防性诊断、以及对于这些诊断中每一个诊断而言紧迫影响之前剩余的距离一起的列表。

图10举例说明当ECAM EM1消息被选择为检测(图9步骤900)、指责对象S1是故障识别(图1的步骤115)结束时怀疑的指责对象并发且出MM1消息的通知时，基于图4所示的担忧状况图来获得的子图1000的一个示例。参见图9描述的算法允许从子图1000推断，EM1消息是紧迫的并且紧迫影响之前剩余的距离等于与之相关联的1(与指责对象L1相联系)。

在附件给出的表2表示由参见图9描述的算法考虑到子图1000而产生的故障容差报告的一个示例。

借助于参见图9描述的算法而完成的故障容差报告提供大量优点，其中有：

-使用故障在该系统中传播的穷尽物理知识，而不依赖统计；

-指示尚未声明处于故障、但是其中故障会导致担忧状况的指责对象。这个消息对于做出决定非常重要。事实上，若容差裕量仅例如由于在飞行器目的地位置剩有非常昂贵的LRU，则这样的消息允许避免飞行器出发。在这种情况下，飞行器长时间停飞等待备用LRU的风险大。反之，若容差裕量被打破，但是后勤和备用件维护就成本和操作而言不是问题，让飞行器出发的风险少些。

回到图1，在阶段115过程中所识别的最小顶点同样可以用来排列最可能的疑点和/或障碍，以便于进行预防性诊断操作(阶段130)。这样的排列尤其可以基于诊断的历史。

图11举例说明基于预先计算的最小顶点来排列最可能的疑点和障碍的算法的一个示例，以便于进行预防性诊断操作。

正如举例说明的，第一步(步骤1100)旨在访问诊断历史，通常是以前的n次飞行的诊断历史，例如，以前的四次飞行(n＝4)或者以前的15次飞行(n＝15)。

接着，建立(步骤1105)属于被预先识别的被怀疑的指责对象集合(E_i集合)的指责对象的列表。

按照一个特定示例，根据被怀疑的指责对象E_i集合的基数来建立几个被怀疑的指责对象列表。更准确地说，列表LS_r，s是针对E_i集合的每个基数r(r从1变到p)和各次以前的飞行s(s从1变到n)建立的。要考虑的所有E_i集合的基数的最大值p最好是预定的，例如，p＝4。换句话说，p集合{LS_r，s｝_r＝1...p是针对每次飞行s定义的。

在下一个步骤(步骤1110)的过程中，对每次历史飞行，对于当前飞行中被怀疑的每个指责对象，计算诊断持久权重(poid de persistance)。

按照一个特定的示例，诊断持久权重被如下计算：

-只计算当前飞行中被怀疑的指责对象的诊断持久权重。进行该计算时，忽略以前飞行中但不在当前飞行中被怀疑的指责对象

-若在飞行s中指责对象ObjAcc被怀疑，若它在下一次飞行s-1中不再被怀疑，则对于这次飞行，其诊断持久权重为零P_objAcc，s＝0)；并且

-若在飞行s中一个指责对象被怀疑而且它在下一次飞行s-1总是被怀疑，则其诊断持久权重P_objAcc，s，对于该飞行s，被定义为该指责对象P_objAcc，s-1在下一次飞行(s-1)中的诊断持久权重再加上与飞行s服务年数以及包括指责对象的集合LS_r，s的基数(r)相关联的数值，或者若被怀疑的指责对象不属于任何集合LS_r，s，则加上零。然后在下一次飞行s中该指责对象的诊断持久权重可以用以下关系定义，

式中：f(s)是s的递增函数，允许减小以前飞行的权重，以便限制可能对其进行了维护操作的以前诊断的影响。举例说明，函数f(s)可以定义如下：

f(s)＝s

附件中的表3给出被怀疑的指责对象的列表和相关联的诊断持久权重的示例。在这里每行表示用第一列给出的索引值标识的一次飞行。第二列指示在相应的飞行过程中识别的一个或多个障碍。例如，在当前飞行(s＝1飞行)的过程中，识别出障碍F_E，4。第三列给出对于相应的飞行、响应于图1的步骤115而获得的最小顶点。这样，例如，在飞行s＝2，也就是说当前飞的前一次飞行结束时，最小顶点为{S1｝、{L2，L3｝和{L4}。该表的第四列指示最小顶点的一个或多个基数，而第五列表示基于最小顶点按照其基数而建立的列表LS_r，s的内容。第六列对于每次飞行包括在当前飞行中被怀疑的指责对象的列表，而第七列指示按照先前描述的计算、与这些指责对象相关联的诊断持久权重。举例说明，对于飞行s＝3，与指责对象S1相关联的诊断持久权重计算如下：

$P_{S\mathrm{1,3}}=P_{S1,3-1}+\frac{1}{1\×3}=\mathrm{1,5}+\mathrm{0,33}=\mathrm{1,83}$

其中：i＝1，f(s)＝s＝3。

在下一步骤(步骤1115)中，针对当前飞行中被怀疑的每个指责对象来计算诊断历史持久权重。被怀疑的指责对象的诊断历史持久权重，称为PH_objAcc，是在飞行集合上通过该指责对象获得的持久权重的最大值。这样的权重可以用以下关系定义：

PH_ObjAcc＝max_s(P_objAcc，s)

举例说明并采用参照附件的表3给出的示例，指责对象S1的历史持久权重等于2.08，它表示该对象的诊断持久权重分别对于飞行s＝1、2、3和4从1变到1.5到1.83再到2.08的最大值。类似地，指责对象L2具有等于1.58的历史持久权重，而指责对象L5的历史持久权重等于1。

在下一步骤(步骤1120)中，这些历史持久权重用来在同一障碍的诊断中排列最小顶点，从较相关到较不相关。为此目的，可以利用一些规则，特别是下列规则：

-当两个最小顶点具有不同的基数时，认为基数最小的顶点最相关：

-当两个最小顶点具有相等的基数时，认为最相关的顶点是其中它所包括的指责对象的历史持久权重的总和最大的顶点；以及

-当两个最小顶点的基数相等并且它们所包括的指责对象的历史持久权重总和相等时，指责对象的特性(诸如其类型和其性质(硬件、软件、布线、抑制模式，...)可以用来比较这些最小顶点。因此，举例说明，认为硬件指责对象比软件指责对象更相关，而软件指责对象本身又比布线类型的指责对象更相关。最后，若还相等，则可以利用诸如字母顺序等其他判据。

这样的步骤允许获得按相关度分类的诊断。

举例说明并采用附件的参照表3给出的示例，针对当前的飞行识别出三个最小顶点({S1}，{L5｝，{L2｝)。这三个最小顶点的基数相同(1)。但是，利用每个最小顶点的每个指责对象的历史持久权重总和(分别为2.08，1.58和1)，就可以将其分类：{S1}，{L2｝，{L5}。

历史持久权重还可以用来以绝对方式排列被怀疑的指责对象的优先顺序，例如，利用下列规则：

-对于给出的两个指责对象，包含在基数最小并带有最大的历史持久权重的最小顶点中的指责对象最优先；

-对于两个包含在基数相同的顶点中的指责对象，包含在最相关的顶点中的指责对象最优先；

-对于两个包含在具有相同基数、具有相同相关性的顶点中的指责对象，可以利用指责对象的一些特性，诸咖其类型和其性质(硬件、软件、布线、抑制模式，...)等，来比较这些指责对象。因此，举例说明，认为硬件指责对象比软件指责对象更相关，而软件指责对象本身又比布线类型的指责对象更相关。最后，若还相等，则可以利用其他判据，诸如字母顺序等。

举例说明，假定当前诊断包括下列最小顶点，

{L1，L2}或{L3｝或{L4，L5｝

包含下列这些指责对象，其历史持久权重已被计算出并在圆括号之间指出：

L1(3)，L2(2)，L3(1)，L4(1)，L5(2)

使用先前给出的规则，允许基于最小顶点的基数和历史相关性权重，来确定指责对象的优先顺序为下列顺序：

1.L3

2.L1

3.L2

4.L5

5.L4

这个优先顺序是由于以下事实得出的：指责对象L3包含在基数为一的顶点中，而所有其他指责对象都包含在基数大于一的顶点中。另外，在基数为2的顶点中，由于相应的历史持久权重总和(指责对象L1和L2比指责对象L4和L5大)，故顶点{L1，L2｝比顶点{L4，L5｝更相关。最后，指责对象L1的历史持久权重大于指责对象L2，而指责对象L5的历史持久权重大于指责对象L4。

以前n次飞行的诊断历史以及担忧状况图可以用来在给定的飞行的诊断中对障碍进行排列。

为此目的，第一步(步骤1130)包括利用以下这样的顺序关系来逐次飞行地识别被诊断的障碍F_i的可能顺序：在本次飞行的先前一次飞行上诊断出的障碍F_i完全覆盖在本次飞行时诊断出的障碍F_j，如果诊断障碍F_i的所有最小顶点都包括在诊断障碍F_j的最小顶点的列表中或者使后者最小化的话。举例说明，这使人联想到分组{A｝使分组{A，B｝最小化并且分组{A｝包括在分组{{A｝，{C，D}，{E，F}}分组内。这样的关系记为F_i→F_j。

在下一步骤(步骤1135)中，计算当前飞行期间诊断出的障碍的持久权重。这样的计算尤其可以按照下列步骤进行：

-在相继各次飞行上查找诊断出的障碍F₀、F_-1、...、F_-k的最大长度序列，诸如F₀是在当前飞行上检测出的，F_-1是在上次飞行上检测出的，以此类推，直至障碍F_-k(当前飞行之前的第k次飞行期间诊断出的)，其中k＞0，而且

F_-k→F_-(k-1)→...→F_-1→F₀

-若这样的序列存在，则障碍F₀的持久权重等于k，并且若它不存在，则障碍F₀的持久权重等于零。

接着，当前飞行期间诊断出的障碍F_i被按照根据持久权重的优先级排列，从较大到较小(步骤1140)，使得持久权重大的障碍优先于持久权重小的障碍。

在两个障碍之间相等的情况下，其各自诊断的构成最好用来评定这些障碍。为此目的，计算对每个障碍进行诊断的最小顶点的秩。在这里最小顶点的秩等于构成该顶点的指责对象的数目。举例说明，最小顶点{AccObj_A，AccObj_B}的秩为2，而最小顶点{AccObj_C，AccObj_D，AccObj_E｝的秩为3。这时，利用最小顶点的秩来对这些障碍进行分类，使得用秩较小的顶点诊断的障碍优先于秩较大的顶点诊断的障碍。于是，例如，若F₁和F₂是具有相同的持久权重的障碍，则用最小顶点{AccObj_A｝和{AccObj_B，AccObj_C｝诊断的障碍F₁，优先于用最小顶点{AccObj_D，AccObj_E｝诊断的障碍F₂。在相等的情况下，这些障碍可以根据最小顶点的数目来评定，具有最少数目的那个障碍是最优先的。

图12举例说明在上面示出两个障碍之间的覆盖关系的担忧状况图的示例。

这里假定，消息MM1和MM2是在上次飞行的过程中通知的，而且消息MM3是当前飞行时通知的。障碍F₁是在上次飞行期间通过最小顶点{S1}诊断。障碍F₂是在当前飞行期间通过最小顶点{S1｝、{L1｝、{L2｝诊断。

障碍F₁完全覆盖障碍F₂（F₁→F₂)。因而，障碍F₁优先于障碍F₂。

参见图11描述的步骤尤其提供下列优点：

-便于最经常怀疑的指责对象的维护，这避免非常长时间使对象处于未解决的故障中。这在一系列飞行之后尚未回到其主要基地而且在基站上有不同维护设备工作的情况下是特别有用的。事实上，在这种情况下，在一个机场与另一个机场维护操作员并不是同一个人，只是在给定的机场中对飞行器进行严谨的检查。借助于上述步骤获得的结果允许从以前的诊断历史获益；以及

-便于在地面上，例如，由运营该飞行器的公司的维护控制中心，做出决定，这是因为诊断结果已经根据历史而被分类，从而避免该中心的人员每次飞行都进行手工工作。

最后，回到图1，在步骤135的过程中建立完整的诊断报告，在这期间诊断消息和故障容差的评价有序地(按障碍，从较优先到较不优先，并且对于每个障碍，按顶点，从较相关到较不相关)加以集合。该报告最子还按其绝时优先顺序包含被怀疑的指责对象的列表。

按照一个特别实施方式，在飞行器机载维护系统中实施该辅助诊断系统。辅助诊断系统收到的通知，优选地是由飞行器系统发送的ARINC624类型的故障报告、ECAM类型的消息通知、由FWS发送的可用性和/或报警消息。因此，定期地或者当收到新的通知时执行参见图7描述的算法。所使用的担忧状况图优选地按照其有效配置，特别是通过考虑到已安装的可选设备，来对应于飞行器系统的担忧状况图的级联。

飞行器机载的担忧状况图的版本可以是缺少某些分支的缩减版本，但其允许获得第一诊断结果并因此优化运营和维护操作。在第二实施方式中，可以利用担忧状况图的完整版本，以便，例如允许飞机制造商向航空公司出售详细的运营和诊断服务。

辅助诊断的结果最好存储在飞行器机上。接着，其可以通过人机界面可视化。还可以通过通信系统(例如，ACARS系统)发送至在地面上的消息处理系统。

图13举例说明这样的在飞行器1300中实施的实施方式，包括总体上用附图标记1305标记的一套系统，每一个系统都配备BITE类型的监测系统和FWS报警系统1310。该监测系统以及报警系统向机载维护系统1315发送检测到的事件通知消息。机载维护系统1315包括知识库1320，知识库1320尤其包括至少一个连接至飞行器系统的担忧状况图1325。该担忧状况图是与收到的通知消息结合使用的，以便通过实施例如参照图7、9和11所描述的算法、按照本发明来建立辅助诊断。这样的辅助诊断结果(尤其包括表示最小诊断的一组最小顶点、故障容差分析结果以及预防性诊断)被以报告的形式存储在数据库1330中，以便通过通信装置1335(例如，ACARS系统)传送至在地面上的信息处理系统(未示出)并且/或者以便通过人机界面1335查询。

这样的系统允许在监测系统的通知和辅助诊断算法的执行之间的较小延迟。另外，飞行器机载的辅助诊断结果的实时可用性为飞行器赋予诊断自治。

按照另一个实施方式，辅助诊断算法由在地面信息处理系统基于飞行器所传输的数据来执行。辅助诊断算法最好可以由飞行器制造商执行，集中几个飞行器的辅助诊断结果并对其进行验证，这些结果可以由专家验证。接着，这些结果(包括表示最小诊断的最小顶点集合)可以通过诸如互联网等通信网络传送到运营该飞行器的航空公司。替代地或补充地，该辅助诊断算法可以在运营这些飞行器的航空公司内部实施，该辅助诊断算法可以由飞行器制造者以软件应用的形式提供。这些软件应用可以用一个开放和模块化的界面体系结构实现，从而允许其与管理飞行器机队的其他服务集成在一起。

图14举例说明针对来自飞行器1400的数据而实施的这样的实施方式，飞行器1400包括整体用附图标记1405表示的一套系统，每一个都配备有BITE类型监测系统和FWS报警系统1410。这些监测系统以及报警系统把检测到的事件通知消息传输至机载维护系统1415。机载维护系统1415可以把从监测系统1405和报警系统1410接收的通知消息，经过或不经过处理，结合或不结合，通过通信装置1425(例如，ACARS系统)传送至在地面上的信息处理系统1420。

信息处理系统1420包括知识库1430，知识库1430中尤其包括至少一个连接至所考虑的飞行器系统的担忧状况图1435。该担忧状况图与所接收的通知消息结合使用，以便通过例如实施参照图7、9和11描述的算法来建立按照本发明的辅助诊断。这样的辅助诊断的结果(包括表示最小诊断的一组最小顶点、故障容差分析结果、和预防性诊断)以报告的形式存储在数据库1445中。这可以在它产生之后或在它存储之后通过人机界面1450查询。

这样的实施方式允许在地面上实施可以用来建立对几个飞行器的辅助诊断的集中辅助诊断系统。另外，该辅助诊断系统可以，例如，与另一个目标在于对维护任务编程和管理备用件后勤计划的维护消息系统集成。使用这样的实施方式允许显著地缩短建立诊断所需要的时间。因此，已观察到与故障管理过程相关联的情况下，时间增益可达50倍。

在这里要注意，先前描述的方法还可用于由飞行器在其飞行期间自动发送的实时建立的报告、一般称为CFR(英语Current Flight Report(当前飞行报告)的首字母缩写)的后处理。

该方法允许对飞行器进行预防性辅助诊断，预防性辅助诊断允许地面上的专家推荐预防生维护动作以避免对其运营非常惩罚性的紧迫影响。

举例说明，该方法允许对由于一个或几个门(门的关闭/闭锁/锁定状态(closed&latched&locked)没有得到确认)的缺陷引起的客舱增压系统的临近抑制发出警报。飞行器的这种增压抑制，若不加以预防，对该公司非常成问题，这是因为它阻上所有起飞并且驾驶员得到登机门的报警，此时所有乘客在登机。通过预先通知，该公司可能尽早编制该门的维护动作计划，并最后避免机舱的任何增压抑制。

图15举例说明适于实施本发明的某些步骤(特别地，参照图7、9和11描述的步骤)的装置1500的硬件体系结构的一个示例。例如，装置1500是一个计算装置或计算机。在这里它包括通信总线1505，其上连接有：

-一个或几个中央处理单元或者微处理器(CPU)1510；

-只读存储器1515(ROM，英语术语Read Only Memory的字首词)可以包括实现本发明所需要的程序(prog、prog1和prog2)；

-随机存存储储器或缓存1520(RAM英语术语Random Access Memory的字首词)，包括适于记录在上述程序执行过程中建立和修改的变量和参数的寄存器；和

-通信接口1550，适于发送和接收数据。

装置1500优选地还配备有：硬盘1535，可以包括上述程序以及根据本发明已处理和待处理的信息；以及存储卡读取器1540，适于接纳存储卡1545并在其中读出或者写入按照本发明的已处理和待处理的数据。

该通信总线允许在包括在装置1500内或与之连接的不同元件之间进行通信和互操作。对总线的描绘不是限制性的，特别是中央单元能够把指令直接或者借助于装置1500的其他元件向装置1500的所有元件传送。

允许该可编程装置实施按照本发明的过程的每个程序的执行代码，可以存储，例如，在硬盘1535中或者只读存储器1515中。

根据一个变型，存储卡1545可能含有信息，特别是根据本发明的待处理的信息以及上述程序的可执行代码，该可执行代码一旦由装置1500读出就存储在硬盘1535中。

根据另一个变型，程序的可执行代码和根据本发明的待处理的信息可以借助于接口1550接收，至少部分地接收，以便与先前描述的方式相同地存储。

更一般地说，这一个或多个程序以及根据本发明的待处理的信息可以在执行之前咖载到装置1500的存储装置中。

中央单元1510将控制和引导执行根据本发明的一个或多个程序的指令或者一部分软件代码，该代码存储在硬盘1535中或者在只读存储器1515中或者在上述其他存储元件中。上电时，存储在非易失性存储器(例如，硬盘1535或只读存储器1515)中的一个或多个程序被传送到随机存取存储器1520(其然后包含按照本发明的一个或多个程序的可执行代码)以及用来存储实施本发明所需的变量和参数的寄存器。

自然，为了满足特定的要求，本领域的技术人员能在上述的描述中做出修改。

附件

表1：参数实例表的示例

表2：故障容差报告

故障容差报告：

紧迫影响：EM1

飞行器影响，重大冲击(impact_élevé)

距离1的预防性诊断

带有疑点S1

S1

和

L1

表3：被怀疑的指责对象的列表与诊断持久权重

Claims (12)

1.一种飞行器(1300，1400)的包括多个子系统(1305，1405)的复杂系统的计算机辅助建立故障容差报告的方法，所述多个子系统中的至少一个子系统包括至少一个检测到的事件的监测装置和通知装置，该方法的特征在于：

实施至少部分地对所述复杂系统建模的担忧状况图(200，300)，所述担忧状况图包括多个顶点(205-250)，所述多个顶点中的每个顶点都根据逻辑隐含关系连接至所述多个顶点中的至少另一顶点，所述多个顶点包括，

-每一个都表示能被接收到的通知消息(400，405)的多个顶点；

-表示担忧状况(205，210)的至少一个顶点；以及

-每一个都表示所述复杂系统的一个元件(245，250)的多个顶点，每个元件都用可能发生故障的顶点表示；

该方法包括下列步骤：

-接收(110)实现所述至少一个检测到的事件的至少一个通知消息；

-创建(115)与所述至少一个检测到的事件相关的最小诊断集合，最小诊断集合包括被怀疑导致所述至少一个检测到的事件的多个元件，所述最小诊断集合的每个元件都用所述担忧状况图的一个顶点表示，并根据所述担忧状况图的至少一个与表示接收到的所述至少一个通知消息的一个顶点的逻辑隐含关系来确定；

-选择(900)用所述担忧状况图的一个顶点表示的能被接收到的至少一个通知消息；以及

-识别(905)所述最小诊断集合中的能够导致产生所选择的所述至少一个通知消息的元件，所识别的元件属于所述故障容差报告。

2.根据权利要求1的方法，还包括针对所识别的元件中的至少一个元件来计算在紧迫影响之前的剩余距离(930)的步骤，所述剩余距离是根据以下这样的元件的数量来计算的：这些元件不属于所述最小诊断集合并且要产生所选择的至少一个消息需要这些元件发生故障。

3.根据权利要求1或权利要求2的方法，根据此方法，识别元件的所述步骤包括从所述担忧状况图中提取(910)至少一个子图的步骤，所述至少一个子图包括表示能够由所述最小诊断集合的一个元件的故障产生的至少一个消息的至少一个顶点。

4.根据权利要求3的方法，还包括把与所述至少一个子图的顶点相关联的消息与所选择的至少一个消息进行比较(915)的步骤。

5.根据权利要求4的方法，还包括响应于比较的步骤、基于所述至少一个子图来创建(920)第二最小诊断集合的步骤，前述最小诊断集合称为第一最小诊断集合；以及还包括在所述第二最小诊断集合中选择(935)最小诊断的步骤，所识别的元件是由对最小诊断的所述选择产生的。

6.根据前述权利要求中任一项的方法，还包括对所识别的元件获得并分配属性的步骤。

7.根据前述权利要求中任一项的方法，还包括产生所述故障容差报告的步骤。

8.根据前述权利要求中任一项的方法，还包括选择(120)针对所识别的上述至少一个元件的至少一个故障解决过程的步骤。

9.根据前述权利要求中任一项的方法，根据此方法，所述担忧状况图至少部分地通过至少一个一般子图的实例化产生。

10.一种计算机程序，包括适于当所述程序在计算机上执行时实施根据前述权利要求中任一项的方法的每个步骤的指令。

11.一种飞行器维护系统，包括计算机，该计算机包括用来实施根据权利要求1至9中任一项的方法的每个步骤的装置。

12.一种飞行器，包括根据权利要求11的系统。

Images