CN112041820A - 基于匹配集的自动根本原因分析 - Google Patents

Abstract

接收到物理系统的观察到的症状集合。将观察到的症状集合与故障场景数据库进行匹配，以生成多个匹配故障场景，其中，故障场景数据库包括症状和对应的根本原因标识符的组合。对多个匹配故障场景进行细化。确定多个匹配故障场景中的第一故障场景是否将被第二故障场景归并。响应于多个匹配故障场景中的第一故障场景将被第二故障场景归并的确定，将第二故障场景包括在多个匹配故障场景中、将第一故障场景去优先级化、或进行两者。输出作为潜在根本原因的多个匹配故障场景。

Description

基于匹配集的自动根本原因分析

其他申请的交叉引用

本申请要求于2018年3月20日提交的题为“基于匹配集的自动根本原因分析（MATCHSET-BASED AUTOMATIC ROOT CAUSE ANALYSIS）”的申请号为62/645,656的美国临时专利申请的优先权，该美国临时专利申请出于所有目的通过引用并入本文中。

背景技术

由于若干个原因，确定复杂系统中的问题的根本原因是具有挑战性的。

首先，故障可能进行传播以引起高密度的症状，每个症状都表现为某个组件的故障或不良行为。例如，低级别的计算机网络链路故障可能引起在链路的每个末端处的信号损失、在传输层的数据流中断，并且于是引起应用程序级别的超时和错误。

第二，存在与可用信息相关联的不确定性。例如，温度传感器可以指示假定正在被冷却的冷藏区域的温暖读数，这表明制冷系统已发生故障。然而，还可能的是传感器已经发生故障并且正在提供不正确的读数。此外，传感器或报告设备可能发生故障或不可达，因此相关联的遥测就不可用。

最后，即使实际上仅存在一个故障，可用的信息也可能不足以消除两个或更多个潜在根本原因故障之间的歧义。也就是说，不仅有必要过滤掉由根本原因引起的外来故障，而且当不确定遥测在正被诊断的系统上多么正确、当前或完整时，也有必要这样做。

在具有这些挑战的情况下，以绝对的确定性确定实际的根本原因是什么会是不可能的。

附图说明

在下面的详细描述和附图中公开了本发明的各种实施例。

图1是图示了根据一些实施例的用于基于匹配集的自动根本原因分析的编程计算机/服务器系统的功能图。

图2是图示了网络示例的实施例的框图。

图3是图示了功率示例的实施例的框图。

图4是图示了用于基于匹配集的自动根本原因分析的过程的实施例的流程图。

图5A是图示了以下过程的实施例的流程图，该过程用于确定多个匹配故障场景中的第一故障场景是否将被第二故障场景归并。

图5B是图示了以下过程的另一个实施例的流程图，该过程用于确定多个匹配故障场景中的第一故障场景是否将被第二故障场景归并。

图6A、图6B和图6C是图示了以下过程的实施例的流程图，该过程用于基于关系来细化多个匹配故障场景。

具体实施方式

本发明可以以众多方式实现，包括作为过程；装置；系统；物质组成；体现在计算机可读存储介质上的计算机程序产品；和/或处理器，诸如被配置成执行存储在耦合于该处理器的存储器上和/或由该存储器提供的指令的处理器。在该说明书中，这些实现方式或本发明可以采取的任何其他形式可以被称为技术。一般而言，在本发明的范围内，可以更改所公开的过程的步骤次序。除非另行陈述，否则被描述为被配置成实行任务的诸如处理器或存储器之类的组件可以被实现为被临时配置成在给定时间实行任务的通用组件、或者被制造成实行该任务的特定组件。如本文中使用的，术语“处理器”指代被配置成处理诸如计算机程序指令之类的数据的一个或多个设备、电路和/或处理核心。

下面提供了对本发明的一个或多个实施例的详细描述，以及图示了本发明原理的附图。结合这样的实施例描述了本发明，但是本发明不限于任何实施例。本发明的范围仅由权利要求限制，并且本发明涵盖众多替换方式、修改和等同形式。在下面的描述中阐述了众多具体细节，以便提供对本发明的透彻理解。提供这些细节是出于示例的目的，并且可以根据权利要求来实践本发明，而无需这些特定细节中的一些或全部。出于清楚的目的，没有详细描述与本发明相关的技术领域中已知的技术材料，使得本发明不会不必要地晦涩难懂。

公开了标识复杂系统中的问题的最可能的一个或多个根本原因。如上所述，可能并不可能以绝对的确定性来确定实际的根本原因可能是什么，并且因此一种有用的解决方案是标识最可能的根本原因。

公开了对提供多重匹配能力的自动根本原因分析（ARCA）进行细化。通过利用多重匹配能力至少在某种程度上是冗余的事实，基于以下各项中的至少一个之间的关系来细化给定症状集合的多重匹配：匹配的症状、匹配的身份以及匹配的置信水平。这些关系可以指示经由以下各项中的至少一个的细化：通过基础场景相关联的派生场景来归并基础场景；确定两个匹配作为替代解释和/或将匹配指示为相同根本原因组的部分；以及将两个匹配确定为单独的可能故障和/或将匹配指示为不同根本原因组的部分。因此，公开了允许部分匹配的技术。公开了处理额外的匹配以减少和组织匹配，从而使其更易于高效地解释。

所公开的技术以更宽泛的基于规则的系统技术进行概括。从技术上讲，计算中的“规则”被表述为：条件→动作。因此，ARCA只是作为症状集合的条件，并且动作是：“报告相关联的根本原因”。更具体地，条件是“子条件”的结合，也就是“具有症状A而非症状B”等。

例如，加索引对于改进数据库查询的性能至关重要。如果查询条件指定了由索引处理的子条件，则查询处理器就可以访问该索引，并且只是在由索引指示为相关的那些记录上进行迭代、匹配剩余的查询条件，而不是进行全表扫描。后者招致的成本为O(N)，其中N是表中的行数。如果索引包含K个条目，其中K比N小得多，则对K个条目的扫描比扫描所有N个条目快得多，因为要检查的记录更少，并且还因为通过索引处理的子条件减少了查询条件。此外，如果每个记录在长度上平均为B字节，则如果数据在存储器中，则全扫描通常招致N*B字节的I/O或存储器访问，而索引显著降低了该I/O或存储器需求。

索引机制然后可以被构造为索引表，该索引表被优化成用于高效的全扫描，同时作为该扫描的部分来实行多重索引匹配。特别地，每个列表示一索引。行包含数据表中对应行的每一个索引的条目值。例如，行M中的子条件X的值是数据表行M的对应于X的索引的值。允许该值为空（NULL），表示“不在乎”或“不知道”。匹配机制将索引表和索引行掩码取作输入，其中该掩码为每个索引指定一个值，并且返回与该掩码匹配的行列表。掩码还可以为索引指定空值，从而指示“不知道”。索引的集合被旋转到一个表中，而不是每个都被视为单独的（关联的）值数组。

术语子条件是对索引值的解释，因为它比只对列中的特定值加索引更通用。例如，索引中的真值可以只指示表的对应行中的对应条目超过了指定的阈值。而且，诸如超过给定阈值的子条件对于应用而言可能是足够的，并且改变的频率远低于实际值的改变频率。使用该术语，索引表中的行包含：对应于该索引表行的表行的每个索引子条件的子条件值（尽管子条件值可以为空）。

在一个实施例中，如果原始表中存在N行，则索引表就具有N行。否则，如果原始表中的行在索引表中没有对应的行，则仅可以通过进行全表扫描来在查询中找到该行。本质上，公开了扫描N条目索引表而不是使用多个索引来避免全表扫描的方法。索引表被优化成使得进行扫描比扫描原始基础数据表更为高效。也就是说，重点在于优化索引表扫描，而不是通过使用常规的索引方案来避免N行数据表扫描。关键焦点在于其中数据表的稀疏性使得使用索引表比使用常规索引更为高效的应用。

因此，相对于ARCA，索引表对应于潜在故障场景的集合，每行一个潜在故障场景。症状对应于表中的子条件条目。例如，对于由工厂中每个烤箱的行和对应于烤箱温度的条目组成的数据表，对应于“温度超过阈值”的索引将使索引表中与其中对应烤箱超过温度阈值的每个行的该子条件相对应的列中的条目设置为真。因此，给定症状的潜在故障场景集合中的条目对应于索引表中的索引，并且因此对应于索引表中的列。ARCA中的输出原因对应于索引表实施例中的匹配行。实际故障场景对应于索引表实施例中的掩码。并且，空值是对应于“不关心”或“不知道”的特殊值，因为空值是数据库文献中常规使用的术语。利用术语的该翻译，除了在查询使用中，掩码与行之间的匹配逻辑相反之外，匹配方法与ARCA中的相同。

在一个实施例中，表中的一个或多个索引是位图索引，其被扩展有指示“不关心”值以及真和假的能力。这对应于三元或四元匹配。因此，对于三元或四元表示和匹配而言的最小表示是两位。在没有限制的情况下，在本文中给出了根本原因分析的示例，但是本领域任何普通技术人员都会意识到根本原因分析是索引表的具体应用。特别地，根本原因分析可以被视为被实现为对索引表的查询，以确定与索引行掩码中指定的症状集合相匹配的（一个或多个）行，然后将每个行映射到对应的根本原因。

图1是图示了根据一些实施例的用于基于匹配集的自动根本原因分析的编程计算机/服务器系统的功能图。如所示的，图1提供了根据一些实施例的被编程为提供基于匹配集的自动根本原因分析的通用计算机系统的功能图。如将明显的，其他计算机系统架构和配置可以被用于基于匹配集的自动根本原因分析。

包括如下所述的各种子系统的计算机系统100包括至少一个微处理器子系统，其也被称为处理器或中央处理单元（“CPU”）（102）。例如，处理器（102）可以由单芯片处理器或由多个核心和/或处理器来实现。在一些实施例中，处理器（102）是控制计算机系统100的操作的通用数字处理器。使用从存储器（110）检索的指令，处理器（102）控制输入数据的接收和操纵，以及输出数据和在输出设备上显示数据，该输出设备例如是显示和图形处理单元（GPU）（118）。

处理器（102）与存储器（110）双向耦合，该存储器（110）可以包括通常是随机存取存储器（“RAM”）的第一主存储装置，以及通常是只读存储器（“ROM”）的第二主存储区域。如本领域中公知的，主存储装置可以被用作通用存储区域并且被用作暂时存储器，并且还可以被用来存储输入数据和经处理的数据。除了用于在处理器（102）上操作的过程的其他数据和指令之外，主存储装置还可以以数据对象和文本对象的形式存储编程指令和数据。同样也在本领域中公知的，主存储装置通常包括：由处理器（102）用来实行其功能的基本操作指令、程序代码、数据和对象，例如编程指令。例如，取决于例如数据访问需要是双向还是单向的，主存储设备（110）可以包括下面所描述的任何合适的计算机可读存储介质。例如，处理器（102）还可以直接且非常迅速地检索被频繁需要的数据，并且将该数据存储在未示出的高速缓冲存储器中。处理器（102）还可以包括协处理器（未示出）作为补充处理组件，以帮助处理器和/或存储器（110）。

可移动大容量存储设备（112）为计算机系统100提供了附加的数据存储容量，并且被双向地（读/写）或单向地（只读）耦合到处理器（102）。例如，存储装置（112）也可以包括计算机可读介质，诸如闪速存储器、便携式大容量存储设备、全息存储设备、磁性设备、磁光设备、光学设备和其他存储设备。固定的大容量存储装置（120）也可以例如提供附加的数据存储容量。大容量存储装置（120）的一个示例是eMMC或microSD设备。在一个实施例中，大容量存储装置（120）是通过总线（114）连接的固态驱动器。大容量存储装置（112）、（120）通常存储通常不被处理器（102）主动使用的附加编程指令、数据等等。将领会的是，如果需要，可以以标准方式将保留在大容量存储装置（112）、（120）内的信息作为主存储装置（110）（例如RAM）的部分并入，以作为虚拟存储器。

除了向处理器（102）提供对存储子系统的访问之外，总线（114）还可以被用来提供对其他子系统和设备的访问。如所示的，这些可以包括显示监视器（118）、通信接口（116）、触摸（或物理）键盘（104）以及一个或多个辅助输入/输出设备（106）（包括音频接口、声卡、传声器、音频端口、音频记录设备、音频卡、扬声器、触摸（或指向）设备和/或按照需要的其他子系统）。除了触摸屏和/或电容式触摸界面之外，辅助设备（106）可以是鼠标、手写笔、轨迹球或平板设备，并且可用于与图形用户界面进行交互。

通信接口（116）允许处理器（102）使用如所示出的网络连接被耦合到另一个计算机、计算机网络或电信网络。例如，通过通信接口（116），处理器（102）可以在实行方法/过程步骤的过程中从另一网络接收信息（例如，数据对象或程序指令），或向另一网络输出信息。经常表示为要在处理器上执行的指令序列的信息可以从另一网络接收并且输出到另一网络。接口卡或类似设备以及由处理器（102）实现（例如由处理器（102）执行/在其上实行的）适当软件可以被用来将计算机系统100连接到外部网络，并且根据标准协议来传递数据。例如，本文中公开的各种过程实施例可以在处理器（102）上执行，或者可以与共享一部分处理的远程处理器相结合、通过诸如互联网、内联网网络或局域网之类的网络来实行。贯穿本说明书，“网络”指代计算机组件之间的任何互连，包括互联网、蓝牙、WiFi、3G、4G、4GLTE、GSM、以太网、TCP/IP、内联网、局域网（“LAN”）、家庭区域网络（“HAN”）、串行连接、并行连接、广域网（“WAN”）、光纤通道、PCI/PCI-X、AGP、VLbus、PCI Express、Expresscard、无限带宽、ACCESS.bus、无线LAN、HomePNA、光纤、G.hn、红外网络、卫星网络、微波网络、蜂窝网络、虚拟专用网（“VPN”）、通用串行总线（“USB”）、火线、串行ATA、1-Wire、UNI/O，或将同构、异构系统和/或系统组连接在一起的任何形式。未示出的附加大容量存储设备也可以通过通信接口（116）连接到处理器（102）。

可以与计算机系统100相结合地使用未示出的辅助I/O设备接口。该辅助I/O设备接口可以包括：允许处理器（102）发送数据并且更通常地从其他设备接收数据的通用接口和定制接口，该其他设备诸如是传声器、触敏显示器、换能器卡读取器、磁带读取器、语音或手写识别器、生物计量读取器、相机、便携式大容量存储设备以及其他计算机。

此外，本文中公开的各种实施例进一步涉及具有计算机可读介质的计算机存储产品，该计算机可读介质包括用于实行各种计算机实现的操作的程序代码。该计算机可读介质是可以存储其后可以由计算机系统读取的数据的任何数据存储设备。计算机可读介质的示例包括但不限于上面提及的所有介质：闪存介质，诸如NAND闪存、eMMC、SD、紧凑型闪存；磁性介质，诸如硬盘、软盘和磁带；光学介质，诸如CD-ROM磁盘；磁光介质，诸如光盘；以及特殊配置的硬件设备，诸如专用集成电路（“ASIC”）、可编程逻辑设备（“PLD”）以及ROM和RAM设备。程序代码的示例既包括如例如由编译器生成的机器代码，也包括可以使用解译器执行的包含更高级别代码（例如脚本）的文件。

图1中所示的计算机/服务器系统只是适合与本文中公开的各种实施例一起使用的计算机系统的示例。适用于这样的用途的其他计算机系统可以包括附加或更少的子系统。此外，总线（114）是说明性的服务于链接各子系统的任何互连方案。也可以利用具有不同配置的子系统的其他计算机架构。

输入概率比对输出概率。与贝叶斯网络和机器学习一起使用的传统方法是将概率与输入相关联，并且通过计算网络传递这些概率，以计算具有最高概率的输出。例如，可以认为温度传感器以某个概率P超过阈值，并且按补概率1-P在阈值以下，其中P反映了传感器未报告当前温度的不确定性。

将概率与输入相关联时存在若干个问题。

首先，考虑到这些输入概率可能取决于许多因素，包括组件的使用年限、其被安装的方式以及组件的品牌/型号，这些输入概率是未知的，并且也许实际上是不可知的。由于相当少见的故障事件，这在ARCA中特别成问题。例如，可能不可行的是，具有关于给定品牌和型号的温度传感器发生故障有多频繁的数据，使得它报告不正确的温度超过特定系统的该设置的阈值，考虑到该事件可能仅通过具有一个或多个冗余温度传感器来检测，利用该一个或多个冗余温度传感器来比较正常或在用温度传感器。也就是说，每个传感器将需要第二监视设备，并且记录以其出现差异的频率，这是一种昂贵的冗余，不经常在实践中进行。

第二，不同的输入经常不是完全独立的，因为考虑到不同的输入是受诊断的同一系统的部分，不同的输入之间可能经常存在依赖性或相关性。该依赖性可以用概率表述为两个输入之间的条件概率。然而，考虑到这样的条件概率牵涉到跨一对元素的样本，它甚至更难以知道。此外，实际的条件概率可以基于各种因素随时间和/或空间而变化，该各种因素包括不同传感器值的实际值、系统的使用年限、其操作模式等等。

最后，这种系统的输出通常被提供为具有最高概率的根本原因，如从这些输入概率计算的那样，因此考虑到仅一个可以具有最高概率，该输出是单个根本原因。事实上，这些概率计算可以生成大量潜在诊断，并且按概率对它们进行排名。然而，考虑到在使用较早前提及的输入概率的情况下的困难，不清楚如何基于计算的概率容易感知地（sensibly）过滤这些诊断。例如，如果操作员仅考虑具有大于0.7概率的潜在根本原因，则合理的考虑是询问用户如何可以具有实际根本原因至少具有该概率的置信。也就是说，用户如何可以推断该特定的阈值是正确的阈值以包括实际根本原因，而没有任意的数字或不需要重复来获得系统的手动定性直觉。

根本原因分析的手动方法传统上使用症状和人类“常识”的定性评估，所以不非常适应于自动化根本原因分析系统。类似地，这些手动“用手工”方法缺乏用于处理不确定性的计算框架，进一步使它们难以自动化。

传统的ARCA的示例是DellEMC的SMARTS程序，该程序可以针对输入来应用概率。当它可以使用基于汉明距离的最接近匹配时，似乎没有生成多重根本原因匹配。汉明距离的使用通常除了平局之外将仅给予一个顶级匹配。考虑到使用汉明距离作为任意度量，不必清楚要相对于第二最接近匹配、第三最接近匹配等等附加什么语义或值。

公开了一种高效的自动化手段，其生成与受诊断中系统的症状相对应的很可能的根本原因故障集合。公开了指定和/或预先指定的多重潜在故障场景。如本文中提到的，潜在故障场景可以对应于在系统中的给定故障发生时预期的症状集合。如本文中提到的，症状是可观察值或值范围，或可根据与标识故障有关或反指示故障的可观察值计算的值。与可以针对输入应用概率的SMARTS不同，所公开的技术将概率与输出相关联，例如被表述为置信水平。如本文中提到的，针对潜在故障场景的置信水平是在考虑到潜在故障场景的症状集合的情况下系统中的场景故障的概率。在一些实施例中，对历史数据进行分析以构造症状集合-置信水平映射表。在映射表中查找症状集合以获得对应的置信水平。考虑到症状集合，可以使用用于确定置信水平的其他技术。

例如，症状可以是由计算机网络交换机在其接口中的特定接口上报告的“信号损失”。当对系统的监视从正被监视的实际系统（本文中被称为实际故障场景）中检测到症状集合时，将该实际故障场景针对潜在故障场景集合进行匹配，以产生本文中被称为该实际故障场景的匹配集，其中如果潜在故障场景与实际故障场景匹配，则该潜在故障场景就是匹配集的成员。

然后，可以基于匹配的潜在故障场景的属性和其他信息来细化该匹配集。如本文中提到的，属性包括与匹配的潜在故障场景相关的任何信息和/或关系，诸如在匹配的症状、匹配的身份和/或匹配的置信水平之间的关系。然后，可以输出与经细化的匹配集中的条目相关联的根本原因故障，从而构成根本原因分析的结果。该根本原因分析可以产生潜在根本原因集合，以更有可能包括实际根本原因故障或根本原因故障。

网络示例–多个潜在故障场景。图2是图示了网络示例的实施例的框图。在该示例中，网络当前症状中的症状是由计算机网络交换机在其接口中的特定接口上报告“信号损失”。

该交换机SW1（202）包括：网络接口I1-a（204）和功率传感器（206），以感测对于交换机SW1的功率损耗。网络接口I1-a（204）被耦合到链路a（222），该链路通往交换机SW2（242），其中，交换机SW2同样包括：网络接口I2-a（244）和功率传感器（246）。如果网络接口（204，244）被分立地供电，则图2中未示出的也可以是用于网络接口（204，244）的功率传感器。

由接口I1-a（204）上的SW1（202）报告的“信号损失”的实际故障场景可以与故障场景FS1相匹配，该故障场景FS1对应于在交换机SW1（202）与交换机SW2（242）之间的链路a（222）中存在链路故障。然而，相同的症状也可以与故障场景FS2相匹配，在故障场景FS2中，链路任一末端处的两个接口（204，244）同时发生故障。它也可以与故障场景FS3相匹配，故障场景FS3对应于链路a（222）中的链路故障，但没有考虑辅助症状，诸如已知与在SW1传感器（206）和SW2传感器（246）处的功率损耗相对应的症状为假。因此，在该示例中，匹配集由FS1、FS2和FS3组成。对此的表格表述为：

标签/元数据	症状	根本原因
				FS1	在（204）上的信号损失&在（206）处没有功率损耗&在（246）处没有功率损耗。	链路<i>a</i>（222）发生故障
FS2	在（204）上的信号损失&在（206）处没有功率损耗&在（246）处没有功率损耗。	两个接口（202，244）同时都发生故障。
				FS3	在（204）上的信号损失。	链路<i>a</i>（222）发生故障

通过基础场景相关联的派生场景来归并基础场景。在一个实施例中，潜在故障场景的属性指示一个潜在故障场景FSa何时被另一个潜在故障场景FSb归并。也就是说，每当FSb被匹配时，FSa也将被匹配。如本文中提到的，FSa是基础场景，并且FSb是派生场景。在FSa和FSb两者都被匹配的情况下，匹配集的细化是在将故障场景转换到它们相关联的根本原因之前从匹配集中移除FSa。

为了说明这种情况，继续图2的网络示例，匹配细化步骤将意识到FS3被FS1归并，因为FS3仅需要匹配FS1正在需要的症状的子集。

基础场景被派生场景归并的另一个简单示例是医学示例：

● 潜在故障场景FSm示出了具有80％的置信水平的流感的根本原因，这考虑到高体温和疼痛的症状；以及

● 潜在故障场景FSn示出了具有90％的置信水平的流感的根本原因，这考虑到高体温、疼痛和头痛的症状。

因此，在包括高体温、疼痛和头痛的症状的实际故障场景的情况下，FSm被识别为由派生场景FSn归并的基础场景，因此具有90％置信水平的流感的根本原因被输出。

。

输出概率的组合。在一个实施例中，细化可以意识到，存在于匹配集中的两个潜在故障场景实际上是针对相同根本原因的两个不同的症状集合，并且事实上可能都为真，所以输出包含该潜在根本原因，可能地具有作为两个潜在故障场景的概率组合的相关联的概率。例如，FSn可以是潜在故障场景，其示出了具有90%置信水平的流感的根本原因，这考虑到高体温、疼痛和头痛的症状，并且FSp可以是潜在故障场景，其示出了具有5%置信水平的流感的根本原因，这考虑到流鼻涕和耳朵疼痛的症状。

。

具有高体温、疼痛、头痛、流鼻涕和耳朵疼痛的症状的患者可以被识别为具有是90%置信水平和5%置信水平的组合的相关联的概率的组合。在一个实施例中，置信水平可以被线性求和。

标签/元数据	症状	根本原因标识符	置信水平
				FSn	高体温&疼痛&头痛。	流感	90％
FSp	流鼻涕&耳朵疼痛。	流感	5％
				<i>组合（FSn，FSp）</i>	<i>高体温</i>&amp;<i>疼痛</i>&amp;<i>头痛</i>&amp;<i>流鼻涕</i>&amp;<i>耳朵疼痛。</i>	<i>流感</i>	<i>95％</i>

替代解释。在一个实施例中，潜在故障场景的属性指示一个潜在故障场景FSc何时是对另一个潜在故障场景FSd的替代可能性。因此，当FSc和FSd两者都出现在匹配集中时，细化将指示这些作为针对实际故障场景的替代潜在根本原因子集的部分，而不是将这两个匹配指示为两个单独的可能故障，和/或将两个匹配指示为不同根本原因组的部分。在实施例中，可以通过比较两个潜在根本原因的症状来计算将潜在根本原因指示为替代的属性。它是具有其他潜在根本原因症状的子集的替代，并且它不是相同内容的基础根本原因，它是替代。

例如，使用图2的网络示例，细化将指示FS1和FS2作为对彼此的替代，这考虑到这两种场景都对应于常见的症状集合或症状子集。

标签/元数据	症状	根本原因标识符
				FS1 （派生场景）	在（204）上的信号损失&在（206）处没有功率损耗&在（246）处没有功率损耗。	链路<i>a</i>（222）发生故障
FS2 （对<i>FS1的替代解释</i>）	在（204）上的信号损失&在（206）处没有功率损耗&在（246）处没有功率损耗。	两个接口（202，244）同时发生故障。

替代解释的另一个简单示例是医学示例：

● 潜在故障场景FSn示出了具有90％的置信水平的流感的根本原因，这考虑到高体温、疼痛和头痛的症状；以及

● 潜在故障场景FSq示出了具有3％的置信水平的枯草热的根本原因，这考虑到高体温、疼痛和头痛的症状；

标签/元数据	症状	根本原因标识符	置信水平
				FSn	高体温&疼痛&头痛。	流感	90％
FSq	高体温&疼痛&头痛。	枯草热	3％

因此，在包括高体温、疼痛和头痛症状的实际故障场景的情况下，FSq被识别为对FSn的替代解释。

在一个实施例中，潜在故障场景的另一个属性是该故障场景相对于其相关联的替代故障场景的概率。为了说明，使用图2的网络示例，FS1的概率可以是0.95，并且作为对FS1 的替代的FS2的概率可以被指定为0.05。然后，匹配集细化可以根据与每一个替代相关联的概率对相关联的根本原因进行排序。因此，在图2的网络示例中，经细化的根本原因集合可以是：

[RC1：0.95，RC2：0.05]

其中，RC1对应于与故障场景FS1相关联的根本原因，并且RC2对应于与故障场景FS2相关联的根本原因。该细化消除了第三条目，因为FS3被FS1归并。

标签/元数据	症状	根本原因标识符	置信水平
				FS1 （派生场景）	在（204）上的信号损失&在（206）处没有功率损耗&在（246）处没有功率损耗。	链路<i>a</i>（222）发生故障	95％
FS2 （对FS1的替代解释）	在（204）上的信号损失&在（206）处没有功率损耗&在（246）处没有功率损耗。	两个接口（202，244）同时发生故障。	5％

将概率与潜在故障场景相关联可能比输入概率方法更可行，因为每个故障场景都表示其中顶级故障需要补救的情况。因此，与替代（即，具有相同症状的那些替代）的相比，操作数据可以指示给定根本原因发生的频率。例如，重新回到图2的网络示例，如果断开的链路a（222）是出自观察到100次相关联的症状中的95次实际根本原因，并且出自那些100次中仅有5次是实际上两个接口（204，244）同时发生故障的情况，则记录的操作数据提供了利用这些概率对这两个替代根本原因进行加权和排序的基础。

因此，首先将输出结果视为检测到断开的链路a（222）的补救动作将在大多次数的情况下立即解决实际根本原因故障，并且仅有5%次数的情况下将需要转到替代故障补救动作。在一些情况下，诸如两个接口（204，244）同时发生故障的情况，用户可以估计基于概率的用于修复接口的平均时间、以及个体接口发生故障的频率和接口的数量，进一步利用在同一恢复窗口内发生故障的两个接口实际上位于链路的任一末端上的可能性来证明合格。注意到，有可能两个链路发生故障并且两个接口发生故障，尽管是不太可能的。也就是说，替代的根本原因可能不相互排斥。在这种情况下，需要对两种故障采取补救动作。

匹配。在一个实施例中，如通过匹配机制实行的实际故障场景与潜在故障场景的匹配在如下意义上是精确的：可能需要每个匹配的潜在故障场景为使得实际故障场景对于每个症状满足在匹配的潜在故障场景中指定的症状要求。

例如，如果潜在故障场景将症状Si指定为烤箱温度大于100摄氏度，则实际故障场景应当包括被报告为大于100摄氏度的该症状。

该匹配与例如在SMARTS中使用的输入概率方法形成对比，在该输入概率方法中，考虑到如由相关联的概率所捕获的关于传感器的不确定性，即使传感器没有报告这一点，也存在症状为真的某个概率。它还与各种看似任意的“基于距离”的方法（诸如汉明距离方法）形成对比，其中ARCA系统基于在实际症状与关联于根本原因的症状（类似于潜在故障场景）之间的按某个度量的距离来选择“最佳匹配”。

在一个实施例中，通过在题为“AUTOMATIC ROOT CAUSE ANALYSIS USING TERNARYFAULT SCENARIO REPRESENTATION”的申请号为15/973，847的美国专利申请中指定的匹配机制来实行匹配集的生成，该美国专利申请出于所有目的通过引用并入本文中。

未细化的故障场景匹配集可以包括多个成员，它们甚至是在部分匹配单个实际故障的情况下，因为潜在故障场景集合应当覆盖其中某种遥测缺失或错误的情况。例如，提供了在图2的网络示例中的FS3，使得即使用于辅助症状的遥测并不完整或并不正确，也存在某种匹配。也就是说，不能够仅仅因为一个交换机（202）或另一个交换机（242）不能够向接口针对功率（206，246）进行报告而诊断链路a（222）中的链路故障，这将是不可接受的。

一般而言，匹配可以高效地实现并且能够同时匹配多个独立的根本原因，如在以上关于三元故障场景表示的申请中所述的。匹配具有的缺点是，当对应于实际故障场景的潜在故障场景中的任何指定症状与根据遥测确定的症状不匹配时，其未能进行匹配。即使在人类对症状的评估可能很快总结出根本原因是什么时，这种情况也可能出现。

图3是图示了功率示例的实施例的框图。在该功率示例中，交换机SW1（302）经由接口和链路完全耦合到24个其他交换机SW2（342）、SW3（362）直至SW25（392）。如之前在图2中所示的，每个交换机（例如交换机SW1（302））包括：功率传感器（302z），以及一个或多个接口I1-a（302a）、I1-b（302b）、…、I1-x（302x），每个对应于链路a（322a）、b（322b）、…、x（322x）。

如果对包括SW1功率传感器（302z）的计算机网络交换机SW1（302）的供电失败，则将预期交换机通过链路连接到的每个接口将检测到信号损失。然而，如果所讨论的交换机通过链路连接到24个单独的接口I2-a（342a）、I3-b（362b）、…I25-x（392x），但这些接口中仅有23个报告信号损失，并且第24个接口I25-x（392x）从遥测中丢失，则即使是从症状中合理地总结出了交换机已发生故障，以及此外在该交换机SW1功率传感器（302z）报告了功率损耗的情况下，是由于缺少功率而发生的故障，匹配将还是未能标识出指定了所有24个单独接口具有功率损耗症状的潜在故障场景。

所公开的技术部分地利用这样的匹配能力来同时匹配多个故障场景，以便于补偿该缺点。特别地，除了具有对应于所有症状的潜在故障场景之外，还存在对应于针对相同根本原因的部分匹配所指定的潜在故障场景。对具有潜在故障场景的相关联属性的扩展允许对匹配集进行细化，以减少实际上输出的潜在根本原因的数量。

特别地，当与全潜在故障场景的匹配发生时，对应于相同根本原因的部分匹配的潜在故障场景被消除和/或归并。类似地，与潜在故障场景相关联的概率属性允许输出高效地指示针对输出中的根本原因的较低置信，这是在它仅仅由于什么有效地是部分匹配而存在的情况下。

在一个实施例中，允许部分匹配的另一种技术是在题为“APPROXIMATE MATCHING”的申请号为62/799,613的美国临时专利申请中指定的近似匹配，该美国临时专利申请出于所有目的通过引用并入本文中。例如，近似匹配被用于其中并非所有特征（例如，子条件）都必须已知的情况。因此，近似匹配可以与部分匹配相结合使用。

在一个实施例中，通过指定距离阈值参数，并且根据在行与掩模之间定义的某个距离度量将行输出为匹配（如果它们在距离阈值内），来提供近似匹配。为了在解释时的效率来处理额外的匹配以减少和组织匹配可以通过近似匹配来改进，该近似匹配部分通过例如将距离D处的近似匹配视作相对于距离D-1处的匹配的基础根本原因来进行。

部分匹配潜在故障场景（PMPFS）。PMPFS在本文中被称为潜在故障场景，其被添加以有效地处理与匹配机制的部分匹配。存在各种技术来定义PMPFS。

省略一个症状的PMPFS。首先，对于针对根本原因的每个全潜在故障场景，对于每个症状可能存在省略症状之一的PMPFS。例如，使用图3的功率示例，每个相邻接口可能存在PMPFS，它省略作为症状的该接口，或者替代地将该症状标明为“不关心”。例如，PMPFS可以省略I25-x（392x）作为“不关心”，因此在I2-a（342a）、I3-b（362b）、…、I24-w（图3中未示出）报告信号损失的情况下，系统可以总结出交换机SW1（302）已经发生故障。

进一步进行并且为全潜在故障场景的症状子集提供PMPFS可以是可能的。例如，为I24-w和I25-x（392x）两者创建PMPFS为“不关心”。然而，这可能在现实复杂的系统中导致不切实际数量的PMPFS。例如，在具有32个直接相邻交换机的交换机示例中，基本上存在2的32次方或粗略地40亿个可能的子集。在这里，近似匹配可以解决PMPFS数量过多的问题。换句话说，部分匹配可以被认为是添加了额外的不太完整的行，而近似匹配是放宽匹配标准，所以可以匹配并不与掩码或实际完整的症状集合精确匹配的行。

排除一系列值的PMPFS。一种有效支持部分匹配同时避免PMPFS数量呈指数爆炸增长的方法是允许潜在故障场景将给定症状指定为排除某个值或某范围的值。通常被使用的值将与作为根本原因的相关联的故障相矛盾。在图3的功率示例中，可以将PMPFS指定为要求信号损失症状为真或未知。然后，只要没有相邻交换机声称接收到来自本应损耗功率的交换机的信号，匹配就发生。也就是说，如果对于某些相邻交换机而言该症状是未知的，例如未知的I25-x（392x），匹配仍然发生。

在一个实施例中，PMPFS的表示允许在范围规范中规范基于排除的匹配，而不仅仅是基于包括的匹配。例如，在所引用的公开内容中，三元值的二元表示可以使用“不知道但为真”的值（即，01），其否则不用来标明“不知道为真”。一般而言，存在用于数据表示的传统技术，其可以被用来高效地编码与排除以及包括相对应的额外信息。

限制PMPFS的范围。另一种有效支持部分匹配同时避免PMPFS数量呈指数爆炸增长的方法是限制PMPFS及其症状的范围，并且对应地降低与其相关联的概率。在图3的功率示例中，可以生成PMPFS，该PMPFS针对交换机SW1（302）的当前功率故障传感器（302z）进行匹配，并且指定对相邻交换机（342a，362b，…，392x）的遥测效果方面的“不关心”。如果功率传感器（302z）报告功率故障，但来自一个或多个相邻交换机的信息存在矛盾，诸如对于I25-x（392x）“未知”的信息可能不正确或陈旧，则该PMPFS匹配。

另一方面，如果用于相同交换机SW1（302）的上述PMPFS与基于排除的匹配相匹配，则该较低概率的匹配被细化步骤过滤掉。一般而言，PMPFS的生成可以基于与其他元素的关系、其他元素的类型、这些元素的特定特性和其他属性来限制范围。

定义聚集症状。另一种有效支持部分匹配同时避免PMPFS数量呈指数爆炸增长的方法是定义聚集症状，该聚集症状基于跨多个传感器输入之上的遥测而被设置。在图3的功率示例中，可以定义聚集症状，该聚集症状对应于多于某个阈值K个的相邻交换机SW2（342）、SW3（362）、…、SW25（392），它们具有来自给定交换机SW1（302）的损失信号。然后，用于交换机功率损耗的PMPFS可以指定该聚集症状，使得如果其大多数直接邻居具有来自它的损失信号，则交换机被认为已经具有功率故障。为了清楚，合并来自其直接邻居的这种信息的益处是，它有助于将这种情况与其中交换机上的电流传感器、而不是功率本身发生故障的情况区分开。

反向传播。另一种高效支持部分匹配的方法是从PMPFS症状要求中排除已由在本文中被称为症状的反向传播的内容所确定的要求。在图2的网络示例中，在链路a（222）的远端/SW2端（242）没有接收到信号的一种很可能的解释是断开的网络线缆。对于在链路的远端没有接收到信号的替代解释是在近端/SW1端（202）的接口I1-a（204）已经损耗功率。这是因为在链路（222）一端的接口处的功率损耗有效地将信号损失症状传播到链路另一端处的接口。

使用反向传播，对于该场景的症状的全故障场景要求每个接口和/或交换机（206，246）的功率损耗症状为假。然而，该反向传播也意味着，如果该交换机SW1的电流功率传感器（206）有故障，则自动根本原因分析（ARCA）可能无法与全故障场景匹配，因此除非存在匹配的PMPFS，否则不确定根本原因。在这种情况下，可能存在排除了由该反向传播产生的这些症状的PMPFS，考虑到由于忽略了症状（否则由于反向传播将需要该症状）而引入的不确定性，这些症状通常具有相关联的较低概率。

使用反向传播的组合。较早期的技术或方法中的每一种也可以应用于反向传播，包括：1）使用反向传播症状的子集2）使用反向传播症状的聚集，以及3）使用症状值的排除，而不是包含范围。

一般而言，PMPFS允许在根本原因分析的准确性与大量PMPFS的计算机存储器/处理之间进行工程权衡。也就是说，在具有较少数量PMPFS的情况下，计算机存储器需求可以减少，和/或计算机处理速度可以增加。与不太准确的分析相比，更准确的分析需要更多计算资源。然而，在某一点之外，由于遥测的正确性和可用性的不确定性限制了任何分析的确定性，所以存在使用更多PMPFS的逐渐减少的回报。

使用上面公开的技术意识到并且解决了用于ARCA的传统方法中的主要谬误；单个根本原因的假设以及确定实际根本原因可行的假设要利用来自传感器输入的确定性来确定。传感器输入可能是不正确的。公开了基于匹配的潜在故障场景来生成潜在根本原因集合，所述匹配的潜在故障场景中的一些可以对应于相同的根本原因故障，然后提供细化步骤来产生精选的潜在根本原因集合。

拼写检查器类比。从这个意义上说，这些技术类似于拼写检查器应用。这样的计算机程序可能不精确地确定根本原因，就像拼写检查器可能不精确地确定所有拼写错误的单词一样：当“ate”是拼写正确的单词时，作者是不是想说“你好，今天过得怎么样”。然而，它可以极大地减少要考虑的潜在错误集合，与拼写检查器相同，可以减少文档中的人员需要验证为具有正确拼写的单词的数量。

匹配集方法对于根本原因分析的匹配方法很重要，因为多个匹配对于避免仅仅由于一个或小量差异所致的匹配失败至关重要。例如，如果为断开链路的情况指定了潜在故障场景，其具有症状，这些症状指示在链路两个末端处的交换机/接口的功率完好无损，则如果用于这些接口中任一个接口的功率传感器出故障，匹配将未能匹配到断开的链路。

图4是图示了基于匹配集的自动根本原因分析的过程的实施例的流程图。在一个实施例中，图4的过程由图1中的系统实行。

在步骤402中，接收物理系统的观察到的症状集合。如本文中提到的，物理系统是具有非暂时性组件的任何系统，例如制冷系统、计算机网络和/或可能接触疾病的生物系统，比如人类。例如，传感器可以与图2的网络示例的每个元件相关联，并且观察到的症状集合可以包括每个工作传感器的状态。

在步骤404中，将观察到的症状集合与故障场景数据库进行匹配，以生成多个匹配故障场景，其中，故障场景数据库包括症状和对应的根本原因标识符的组合。在一个实施例中，故障场景数据库还包括一个或多个置信水平。

例如，图2的网络示例的观察到的症状集合可以包括：在链路a（222）的远端/SW2端（242）没有接收到信号。该观察到的症状集合可以对应于断开的链路a（222）的第一匹配故障场景和在近端/SW1端（202）的接口I1-a（204）损耗功率的第二匹配故障场景。

在一个实施例中，匹配包括：添加部分匹配潜在故障场景（PMPFS）以利用匹配机制来处理部分匹配。

在一个实施例中，添加PMPFS包括以下各项中的至少一个：

● 允许潜在故障场景将给定症状指定为排除一个或多个值；

● 允许潜在故障场景限制PMPFS及其症状的范围，并且对应地降低与PMPFS相关联的概率；

● 允许潜在故障场景跨多个输入定义聚集症状；以及

● 从PMPFS中排除反向传播症状集合。

在一个实施例中，添加PMPFS包括以下各项中的至少一个：使用反向传播症状的子集；使用反向传播症状的聚集；以及使用反向传播症状值的排除。

在步骤406中，细化多个匹配故障场景。下面结合图5A和图5B描述了如何细化匹配故障场景的细节。如下面将更详细讨论的，细化包括：确定第一故障场景是否将被第二故障场景归并，并且如果是，则将第二故障场景包括在多个匹配故障场景中；将第一故障场景去优先级化（deprioritize）；或进行以上两者。在下面的示例中，第一故障场景是匹配故障场景之一，并且第二故障场景可以是匹配故障场景中的另一个或者是与具有第一故障场景作为参数的表达式相关联的故障场景。如本文中所使用的，当第一故障场景被第二故障场景归并时，第一故障场景可以被改变、标记、降低优先级、从匹配故障场景中移除、或者以其他方式受第二故障场景影响。在一些实施例中，该细化进一步包括：根据关系将匹配故障场景相关联。在一些实施例中，关系包括以下各项中的至少一个：症状关系、根本原因标识符关系和置信水平关系。

匹配故障场景然后作为与观察到的症状集合相关联的潜在根本原因被输出。

图5A是图示了用于确定多个匹配故障场景中的第一故障场景是否将被第二故障场景归并的过程的实施例的流程图。在一些情况下，图4的步骤406包括图5A的过程500。

在该示例中，匹配故障场景的细化包括：确定多个匹配故障场景中的第一故障场景是否将被第二故障场景归并，这进而包括：在步骤502中成对比较多个匹配故障场景。例如，将断开的链路场景与接口功率损耗场景进行比较。在步骤504中，响应于多个匹配故障场景中的第一匹配故障场景被第二故障场景归并的确定，第一匹配故障场景被去优先级化。在一些实施例中，去优先级化包括：从匹配故障场景集合中移除第一匹配故障场景。在一些实施例中，去优先级化包括：将第一匹配故障场景与较低概率的替代解释根本原因相关联。在可选步骤506中，细化包括：根据与给定的匹配故障场景相关联的置信水平对多个匹配故障场景进行排序。在一个实施例中，多个匹配故障场景作为导致观察到的症状的潜在根本原因被输出。

在一个实施例中，在确定了第一匹配故障场景是基础场景并且第二匹配故障场景是从基础场景派生的场景的情况下，第一匹配故障场景被确定为被第二匹配故障场景归并。

在一个实施例中，在第一匹配故障场景和第二匹配故障场景共享相同的根本原因标识符并且第一匹配故障场景置信水平低于第二匹配故障场景置信水平的情况下，确定第一匹配故障场景是基础场景，并且第二匹配故障场景是从基础场景派生的场景。

在一个实施例中，细化多个匹配故障场景进一步包括：在第一匹配故障场景被确定为是对于第二匹配故障场景的替代解释的情况下，指示第一匹配故障场景和第二匹配故障场景作为根本原因组的部分。

在一个实施例中，在第一匹配故障场景和第二匹配故障场景共享相同或相似的症状集合的情况下，确定了第一匹配故障场景是对于第二匹配故障场景的替代解释。

在一个实施例中，细化多个匹配故障场景进一步包括：在第一匹配故障场景被确定为是与第二匹配故障场景分离的可能故障的情况下，指示第一匹配故障场景和第二匹配故障场景不是相同根本原因组的部分。

在一个实施例中，在第一匹配故障场景和第二匹配故障场景既不共享相同的症状集合也不共享相同的根本原因标识符的情况下，确定了第一匹配故障场景是与第二匹配故障场景分离的可能故障。

图5B是图示了用于确定多个匹配故障场景中的第一故障场景是否将被第二故障场景归并的过程的另一个实施例的流程图。在一个实施例中，图4的步骤406包括过程550。

在该示例中，假设在过程550之前，某些元数据被设立为与个体故障场景相关联。元数据除了其他事物之外指定了预定义的表达式，其包括对应的故障场景作为参数。在各种实施例中，可以通过将数据库中的附加字段添加到与故障场景相关联的元数据、通过设立指向来自个体故障场景的相应表达式的指针或引用、或者通过使用任何其他适当的技术来进行关联。故障场景可以被视为基础场景，并且表达式可以被视为定义对应的派生场景。例如，对于与根本原因RC1相对应的故障场景FS1，其对应的元数据指定表达式FSk=（FS1或FS2）和（FS3或FS4），其中FS2、FS3和FS4是被包括在数据库中的其他故障场景。当通过匹配观察到的症状发现FS1是匹配故障场景时，FS2、FS3和FS4均可以在或可以不在匹配故障场景中，这取决于观察到的症状的特定集合。表达式可以由用户或系统管理员指定、由编译器基于故障模型生成，该故障模型分析所有症状到故障场景的映射，并且使用布尔代数和/或任何其他适当的技术来确定表达式。进一步假设选择了第一故障场景，诸如来自匹配故障场景的故障场景。

在该示例中，在步骤552中，确定具有第一故障场景作为参数并且对应于第二故障场景的表达式。可以通过检查存储表达式的对应元数据来进行表达式的确定。例如，对应于第一故障场景的元数据可以包括表达式、或者指向表达式对象的指针或引用。以上面讨论的示例为例，对于故障场景FS1，表达式对应于另一个故障场景FSk，其被指定为：FSk=（FS1或FS2）和（FS3或FS4）。

在步骤554中，确定了表达式是否满足预设标准。在各种实施例中，预设标准可以是表达式为真、表达式为假、表达式具有某个值、表达式超过某个阈值等等。在一些表达式中，表达式中的附加参数也被确定，并且表达式被评估以便确定表达式是否满足预设标准。该确定可以基于例如匹配故障场景集合。在上面的FSk示例中，该确定基于FS3或FS4是否为真/是否存在于匹配故障场景集合中。将参数应用于表达式以获得结果，将该结果与预设标准（在这种情况下为FSk是否为真）进行比较。

如果表达式不满足预设标准，则不需要做任何附加的事情，并且过程550可以针对匹配故障场景集合中的下一个故障场景重复或者结束。然而，如果表达式满足预设标准，则在各种实施例中，在556处，第一故障场景被认为被第二故障场景归并。继续上面的示例，考虑到FS1为真，则如果FS3和FS4都不为真，FSk的表达式就不满足表达式为真的预设标准，并且该过程进行重复或结束。然而，如果FS3、FS4或两者都为真，则FSk的表达式为真，并且满足预设标准，并且FS1被认为被FSk归并。因此，FSk被包括在要被输出的匹配故障场景集合中、将FS1去优先级化（从匹配故障场景中移除或者被分配较低的概率），或者进行以上两者。在一些实施例中，FS2、FS3或FS4（无论哪个为真）也被去优先级化。在这一点上，对于下一个匹配故障场景，可以重复过程550，或者如果已经处理了所有匹配故障场景，则过程550结束。

图6A、图6B和图6C是图示了用于基于关系来细化多个匹配故障场景的过程的实施例的流程图。在一个实施例中，图4的步骤406包括图6A、图6B和图6C的过程。如果在步骤602中确定X和Y具有相同的根本原因标识符，则控制被转移到步骤604；否则，控制被转移到步骤624。

如果在步骤604中确定X具有Y的症状子集，则控制被转移到步骤606，其中X被指示为被Y归并；对称地，如果否，但是如果在步骤605中，Y具有X的症状子集，那么在步骤607中，Y被X归并；否则，控制被转移到步骤608，在步骤608中，识别出在匹配集中存在的两个潜在故障场景实际上是针对相同根本原因的两个不同症状集合，并且实际上可能两者都为真，所以输出包含该潜在根本原因，可能地具有相关联的概率，该相关联的概率是与X和Y相关联的两个潜在故障场景的输出概率的组合。

如果在步骤624中确定X具有与Y相同或相似的症状集合，则控制被转移到步骤626，在步骤626中，X被指示为Y的替代解释；否则，控制被转移到步骤628，在步骤628中，X被指示为与y分离的可能故障。在该步骤624中，X和Y不必具有精确地相同的症状集合，因为在这一点上已知它们两者都匹配实际故障场景。例如，有可能在X为真的列中，Y具有“不在乎”。实际测试是要么X通过三元匹配与Y匹配，要么Y与X匹配。否则，它们是单独的故障，这意味着存在两个单独的故障要补救。

尽管出于理解清楚的目的，已经相当详细地描述了前述实施例，但是本发明不限于所提供的细节。存在许多实现本发明的替代方式。所公开的实施例是说明性的而非限制性的。

Claims (44)

1.一种系统，包括：

处理器；以及

与处理器耦合的存储器，其中，存储器被配置成向处理器提供指令，所述指令当被执行时使得处理器用于：

接收物理系统的观察到的症状集合；

将观察到的症状集合与故障场景数据库进行匹配，以生成多个匹配故障场景，其中，故障场景数据库包括症状和对应的根本原因标识符的组合；以及

细化所述多个匹配故障场景，包括进行：

确定所述多个匹配故障场景中的第一故障场景是否将被第二故障场景归并；以及

响应于所述多个匹配故障场景中的第一故障场景将被第二故障场景归并的确定：将第二故障场景包括在所述多个匹配故障场景中，将第一故障场景去优先级化，或者既将第二故障场景包括在所述多个匹配故障场景中，又将第一故障场景去优先级化；以及

输出多个匹配故障场景作为潜在根本原因。

2.根据权利要求1所述的系统，其中：

第二故障场景是所述多个匹配故障场景之一；以及

确定所述多个匹配故障场景中的第一故障场景是否将被第二故障场景归并包括成对比较所述多个匹配故障场景。

3.根据权利要求1所述的系统，其中将第一故障场景去优先级化包括从所述多个匹配故障场景中移除第一故障场景。

4.根据权利要求1所述的系统，其中，将第一故障场景去优先级化包括将第一故障场景识别为与导致观察到的症状集合的一个或多个根本原因相关联的替代解释。

5.根据权利要求1所述的系统，其中，故障场景数据库进一步包括一个或多个置信水平。

6.根据权利要求5所述的系统，其中，细化所述多个匹配故障场景进一步包括：根据关系将匹配故障场景相关联。

7.根据权利要求6所述的系统，其中，所述关系包括以下各项中的至少一个：症状关系、根本原因标识符关系和置信水平关系。

8.根据权利要求1所述的系统，其中，细化所述多个匹配故障场景进一步包括：根据与给定的匹配故障场景相关联的置信水平对所述多个匹配故障场景进行排序。

9.根据权利要求1所述的系统，其中，响应于第一故障场景是基础场景并且第二故障场景是从所述基础场景派生的场景的确定，第一故障场景被确定为被第二故障场景归并。

10.根据权利要求9所述的系统，其中，确定了第一故障场景是所述基础场景，并且第二故障场景是从所述基础场景派生的场景，该确定是响应于第一故障场景和第二匹配故障场景共享相同的根本原因标识符并且第一故障场景的置信水平低于第二匹配故障场景的置信水平而做出的。

11.根据权利要求1所述的系统，其中，响应于第一故障场景是对于第二故障场景的替代解释的确定，来细化所述多个匹配故障场景进一步包括：将第一故障场景和第二故障场景指示为根本原因组的部分。

12.根据权利要求11所述的系统，其中，响应于第一故障场景和第二故障场景共享相同症状集合，第一故障场景被确定为是对于第二故障场景的替代解释。

13.根据权利要求1所述的系统，其中，响应于第一故障场景是与第二故障场景分离的可能故障的确定，来细化所述多个匹配故障场景进一步包括：指示第一故障场景和第二故障场景不是相同根本原因组的部分。

14.根据权利要求13所述的系统，其中，响应于第一故障场景和第二故障场景既不共享相同症状集合也不共享相同根本原因标识符，确定第一故障场景是与第二故障场景分离的可能故障。

15.根据权利要求1所述的系统，其中，确定所述多个匹配故障场景中的第一故障场景是否将被第二故障场景归并包括进行：

确定具有第一故障场景作为参数并且对应于第二故障场景的表达式；

确定所述表达式是否满足预设标准；以及

响应于表达式满足预设标准，认为第一故障场景被第二故障场景归并。

16.根据权利要求1所述的系统，其中，匹配观察到的症状集合包括：添加部分匹配潜在故障场景（PMPFS），以利用匹配机制来处理部分匹配。

17.根据权利要求16所述的系统，其中，添加PMPFS包括：允许潜在故障场景将给定症状指定为排除一个或多个值。

18.根据权利要求16所述的系统，其中，添加PMPFS包括：允许潜在故障场景限制PMPFS及其症状的范围，并且对应地降低与PMPFS相关联的概率。

19.根据权利要求16所述的系统，其中，添加PMPFS包括：允许潜在故障场景跨多个输入定义聚集症状。

20.根据权利要求16所述的系统，其中，添加PMPFS包括：从PMPFS中排除反向传播症状集合。

21.根据权利要求20所述的系统，其中，添加PMPFS包括以下各项中的至少一个：使用反向传播症状的子集；使用反向传播症状的聚集；以及使用反向传播症状值的排除。

22.根据权利要求1所述的系统，其中，匹配观察到的症状集合包括实行近似匹配。

23.一种方法，包括：

接收物理系统的观察到的症状集合；

将观察到的症状集合与故障场景数据库进行匹配，以生成多个匹配故障场景，其中，故障场景数据库包括症状和对应的根本原因标识符的组合；以及

细化所述多个匹配故障场景，包括：

确定所述多个匹配故障场景中的第一故障场景是否将被第二故障场景归并；以及

响应于所述多个匹配故障场景中的第一故障场景将被第二故障场景归并的确定：将第二故障场景包括在所述多个匹配故障场景中，将第一故障场景去优先级化，或者既将第二故障场景包括在多个匹配故障场景中，又将第一故障场景去优先级化；以及

输出多个匹配故障场景作为潜在根本原因。

24.根据权利要求23所述的方法，其中：

第二故障场景是所述多个匹配故障场景之一；以及

确定所述多个匹配故障场景中的第一故障场景是否将被第二故障场景归并包括成对比较所述多个匹配故障场景。

25.根据权利要求23所述的方法，其中，第一故障场景的去优先级化包括从所述多个匹配故障场景中移除第一故障场景。

26.根据权利要求23所述的方法，其中，第一故障场景的去优先级化包括将第一故障场景识别为与导致观察到的症状集合的一个或多个根本原因相关联的替代解释。

27.根据权利要求23所述的方法，其中，故障场景数据库还包括一个或多个置信水平。

28.根据权利要求27所述的方法，其中，所述多个匹配故障场景的细化进一步包括：根据关系将匹配故障场景相关联。

29.根据权利要求28所述的方法，其中，所述关系包括以下各项中的至少一个：症状关系、根本原因标识符关系和置信水平关系。

30.根据权利要求23所述的方法，其中，所述多个匹配故障场景的细化进一步包括：根据与给定的匹配故障场景相关联的置信水平对所述多个匹配故障场景进行排序。

31.根据权利要求23所述的方法，其中，响应于第一故障场景是基础场景并且第二故障场景是从所述基础场景派生的场景的确定，第一故障场景被确定为被第二故障场景归并。

32.根据权利要求31所述的方法，其中，确定了第一故障场景是所述基础场景，并且第二故障场景是从所述基础场景派生的场景，该确定是响应于第一故障场景和第二匹配故障场景共享相同的根本原因标识符并且第一故障场景的置信水平低于第二匹配故障场景的置信水平而做出的。

33.根据权利要求23所述的方法，其中，响应于第一故障场景被确定为是对于第二故障场景的替代解释，所述多个匹配故障场景的细化进一步包括：将第一故障场景和第二故障场景指示为根本原因组的部分。

34.根据权利要求33所述的方法，其中，响应于第一故障场景和第二故障场景共享相同症状集合，第一故障场景被确定为是对于第二故障场景的替代解释。

35.根据权利要求23所述的方法，其中，响应于第一故障场景是与第二故障场景分离的可能故障的确定，所述多个匹配故障场景的细化进一步包括：指示第一故障场景和第二故障场景不是相同根本原因组的部分。

36.根据权利要求35所述的方法，其中，响应于第一故障场景和第二故障场景既不共享相同症状集合也不共享相同根本原因标识符，确定第一故障场景是与第二故障场景分离的可能故障。

37.根据权利要求23所述的方法，其中，所述多个匹配故障场景的细化进一步包括：

确定具有第一故障场景作为参数并且对应于第二故障场景的表达式；

确定所述表达式是否满足预设标准；以及

响应于表达式满足预设标准，认为第一故障场景被第二故障场景归并。

38.根据权利要求23所述的方法，其中，观察到的症状集合的匹配包括：添加PMPFS，以利用匹配机制来处理部分匹配。

39.根据权利要求38所述的方法，其中，PMPFS的添加包括：允许潜在故障场景将给定症状指定为排除一个或多个值。

40.根据权利要求38所述的方法，其中，PMPFS的添加包括：允许潜在故障场景限制PMPFS及其症状的范围，并且对应地降低与PMPFS相关联的概率。

41.根据权利要求38所述的方法，其中，PMPFS的添加包括：允许潜在故障场景跨多个输入定义聚集症状。

42.根据权利要求38所述的方法，其中，PMPFS的添加包括：从PMPFS中排除反向传播症状集合。

43.根据权利要求42所述的方法，其中，PMPFS的添加包括以下各项中的至少一个：使用反向传播症状的子集；使用反向传播症状的聚集；以及使用反向传播症状值的排除。

44.一种计算机程序产品，所述计算机程序产品体现在非暂时性计算机可读存储介质中，并且包括计算机指令，用于：

接收物理系统的观察到的症状集合；

将观察到的症状集合与故障场景数据库进行匹配，以生成多个匹配故障场景，其中，故障场景数据库包括症状和对应的根本原因标识符的组合；以及

细化所述多个匹配故障场景，包括：

确定所述多个匹配故障场景中的第一故障场景是否将被第二故障场景归并；以及

响应于所述多个匹配故障场景中的第一故障场景将被第二故障场景归并的确定：将第二故障场景包括在所述多个匹配故障场景中，将第一故障场景去优先级化，或者既将第二故障场景包括在所述多个匹配故障场景中，又将第一故障场景去优先级化；以及

输出所述多个匹配故障场景作为潜在根本原因。

Images