CN112771550B - 高效规则集实现方式的自动生成 - Google Patents

Abstract

公开了自动生成规则集实现方式。访问规则集。针对所述规则集中的每个non‑const规则，构造一个或多个蕴涵有向无环图（DAG）。所述non‑const规则直接引起至少一个外部输出或至少一个外部动作。所述一个或多个蕴涵DAG指定规则条件，包括一个或多个可观察规则条件。对针对所述规则集构造的蕴涵DAG进行编译以获得编译结果，所述编译结果被配置成评估与所述规则集相关联的规则条件，并且当规则条件中的至少一个评估为真时确定一个或多个动作。输出所述编译结果。

Description

高效规则集实现方式的自动生成

其他申请的交叉引用

本申请要求2018年9月6日提交的题为“AUTOMATIC GENERATION OF AN EFFICIENTRULE SET IMPLEMENTATION”的美国临时专利申请No.62/728,028的优先权，其通过引用并入本文中以用于所有目的。

背景技术

基于规则的系统（RBS）已经在过去被用于智能系统。例如，所谓的专家系统是在20世纪80年代开发的，作为斯坦福启发式编程项目的一部分，用于霉素/树突医学诊断、海底声纳信号分析和其他应用。这些系统通常将每个规则构造为“条件：动作”对，其中规则条件指示布尔条件，当其评估为真时，暗示要执行该规则动作。传统的RBS通常难以开发以及维护。它们往往针对执行具有很高的存储器和处理要求。因此，传统的RBS通常不适合实现涉及大量可能条件和决策的复杂应用，诸如自动化驾驶、自动化加热和冷却等。

附图说明

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

图1是图示了根据一些实施例的用于自动生成高效规则集实现方式的编程计算机/服务器系统的功能图。

图2是图示了用于使用基于规则的系统来进行传统的复杂自动化决策做出的过程的实施例的流程图。

图3是计算机网络的简单模型的实施例的图示。

图4是利用元素类型创建的网络实例的实施例的图示。

图5A是症状（symptom）的故障场景向量的实施例的图示。

图5B是根本原因表的实施例的图示。

图5C是已知位和值位（known and value bit）的64位块表示的实施例的图示。

图5D是根本原因分析技术的实施例的图示。

图6A是用于执行自动转化的过程的实施例的图示。

图6B是针对网络示例的DAG集合的图示。

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

图8是反应式规则引擎的实施例的图示。

图9是被监测系统中的反应式规则引擎的实施例的图示。

图10是子条件的反向传播的示例的图示。

图11是图示了用于自动生成规则集实现方式的过程的实施例的流程图。

具体实施方式

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

下面连同图示了本发明原理的附图一起提供本发明的一个或多个实施例的详细描述。结合这种实施例对本发明进行描述，但是本发明并不限于任何实施例。本发明的范围仅由权利要求所限制，并且本发明涵盖许多替代方案、修改和等效物。在以下描述中阐述了众多具体细节，以便提供对本发明的透彻理解。这些细节被提供用于示例的目的，并且可以根据权利要求在没有这些具体细节中的一些或全部的情况下实践本发明。为了清晰起见，在与本发明相关的技术领域中已知的技术材料尚未被详细描述，使得不会不必要地模糊本发明。

公开了规则集实现方式的自动生成。这包括如何基于详细和改进的原因和后果知识来高效且可靠地定义和扩展复杂规则集，并且自动生成对应规则引擎的高效实现方式。因此，随着关于条件和动作学习到了新的东西，规则集被扩展以并入该新知识并且完善该实现方式，从而高效地执行该经修正的规则集。公开了自动生成对于各种实际应用所需的复杂规则集的实现方式，该实现方式并入了专家领域知识，同时避免了高维护和执行开销。

图1是图示了根据一些实施例的用于自动生成高效规则集实现方式的编程计算机/服务器系统的功能图。如所示的，图1提供了根据一些实施例的被编程为提供高效规则集实现方式的自动生成的通用计算机系统的功能图。如将显而易见的是，其他计算机系统架构和配置可以用于自动生成高效规则集实现方式。

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

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

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

除了提供对存储子系统的处理器（102）访问之外，总线（114）还可以用于提供对其他子系统和设备的访问。如所示的，这些如所需要的可以包括显示监测器（118）、通信接口（116）、触摸（或物理）键盘（104），以及一个或多个辅助输入/输出设备（106），包括音频接口、声卡、麦克风、音频端口、音频记录设备、音频卡、扬声器、触摸（或定点）设备、和/或其他子系统。除了触摸屏和/或电容性触摸接口之外，辅助设备（106）可以是鼠标、触笔、追踪球、或平板设备，并且对于与图形用户接口交互是有用的。

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

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

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

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

图2是图示了用于使用基于规则的系统（RBS）来进行传统的复杂自动化决策做出的过程的实施例的流程图。在一个实施例中，图2的流程图由图1中所示的系统实行。在一个实施例中，图2的流程图是传统的RBS执行流程。当传统的RBS已经被用于复杂的自动化决策做出时，这些系统通常将规则构造为“条件：动作”，其中条件（202）指示要应用该规则必须为真的条件，并且动作（206）是要应用该规则时要发生的处理。

作为传统RBS的示例，考虑具有如下四个组件的系统：作为知识库类型的规则库，包括规则列表；临时工作存储器、用户接口、以及基于输入和规则库的交互而采取动作的推理引擎。在传统的RBS中，该推理引擎包括传统的匹配-解决-动作（match-resolve-act）循环，用以将输入与规则匹配，在所匹配的规则之间执行冲突解决，并且对已解决的规则进行动作。

例如，在导航中，规则可以被指定为：条件“如果车辆正在接近红灯”（202），则动作“停止并且等待该灯变绿”（206）。也就是说，从条件为真推理出：可以执行指定动作。

然而，在诸如自主驾驶之类的复杂应用中，规则可能终会变得更加复杂得多。例如，重要的是，要认识到车辆应当停止在它前面的任何车辆后面，并且不要在绿灯时继续前进，直到其他车辆也给了它足够的间隔以使得它继续前进是安全的为止。此外，即使车辆是交叉路口处的第一个汽车，如果交叉路口仍然被其他车辆阻塞，则它也不应当在绿灯时继续前进。

一般而言，传统的RBS可能快速地变得开发、理解和维护起来极其复杂，并且执行起来昂贵。特别地，如果多个条件变为真，则需要决定首先执行哪个动作的冲突解决策略（204）。此外，一旦所选规则已经执行了（206）其相关联的动作，其条件实际上匹配的一个或多个先前规则有可能由于第一规则的动作而不再匹配。出于相同的原因，与其他规则相关联的条件也有可能现在匹配。因此，在每次规则执行（206）之后，RBS需要在条件上重新匹配（202）。在复杂的规则和条件集合的情况下，冲突解决（204）和重新匹配（202到206）可能需要被重复许多次，因此显著增加了每次规则执行的处理、存储器、网络和/或资源成本。此外，这些传统的RBS在如下意义上可能是“脆弱”的：即，这些规则在不熟悉的情形下可能过于刚性或不充分。

然而，RBS方法是有吸引力的，这是因为它避免了在命令式过程化编程中出现的处理次序的过度指定。取而代之，规则依赖于随着时间而满足的条件以不同的次序而被触发。在这个意义上，它类似于事件驱动的编程，其中处理响应于事件而被触发，因此处理的次序不是预先指定的，而是响应于事件在系统或应用的实际执行中发生的次序。RBS可以被视为通过如下方式使这更进一步：使处理以一般逻辑条件、而不是个体事件发生为基础。

因此，现实的RBS可以具有大的规则集。例如，在相同的自驾驶示例中，先前的示例规则仅处理非常具体的情况。为了完整性，规则集可能必须包括针对接近绿灯、橙灯、人行横道、交通锥体、指挥交通的警察、在街上跑动的球等等的规则。

一般而言，关于基于规则的系统的经验是，规则集快速地变得极其复杂，并且因此难以理解，以及因此难以维护和扩展。例如，继续上面的示例，如果初始规则未能包括如果交叉路口未被其他车辆阻塞则进行等待的子条件，那么维护者可能需要认识到该子条件可以被添加到每一个规则的条件，否则在该条件中车辆具有通行权。并且在手动指定的情况下，该子条件可能已经存在于这些现有规则中的一个或多个中，也许是以略微不同的形式指定的。因此，维护者可能必须认识到该条件中的这种其他形式的子条件或风险通过向该条件添加冗余逻辑而在规则评估中招致额外开销。

此外，存在规则维护者在这些条件中的一个或多个下出错的风险，使得规则在其应当匹配的某个条件中未能匹配，或者在其应当不匹配的情况下匹配。因此，测试可能是显著的成本。但是此外，理解非常复杂的条件的逻辑并且改变它来解决问题而不引入更多的问题可能是非常具有挑战性的。

在非意图的情况下，从任意但复杂的规则条件集中手动地确定多个规则条件是否恰好在相同输入上匹配可能是不切实际的。也就是说，一个或多个条件指定不足（under-specified）。当不需要某个输入或子条件来消除规则条件与规则集中的其他规则条件的模糊时进行检测也似乎是不可行的。也就是说，一个或多个条件被过度指定。

RBS执行也可能变得昂贵。RBS的执行本质上是如图1中所图示的重复循环：评估规则条件（202），记录正确的那些条件；选择其条件为真的那些规则中的一个或多个，和/或执行关于首先执行哪个动作的冲突解决策略（204）；以及执行与每个所选规则相关联的动作（206）。

一旦所选规则使其相关联的动作被执行，其条件匹配的一个或多个先前规则可能由于第一规则的动作而不再匹配。出于相同的原因，与其他规则相关联的条件也有可能现在匹配。因此，传统的RBS被设计成在每次规则执行后重新评估所有条件。在复杂规则集的情况下，每次规则触发的冲突解决和重新评估显著地增加了每次规则执行的成本。此外，规则条件的指定不足或过度指定所导致的低效性进一步加大成本。

从整体应用的角度来看，规则执行也是低效的，因为RBS要么进行“应用规则时的反向传播”来尝试实现某个目标，要么进行“应用规则时的正向传播”来搜索导致有用结论的事实。因此，应用最终结果仅在实际上是通过许多规则应用进行的搜索之后被实现。在许多应用中所需的复杂规则集的情况下，该成本是显著的。

出于这些原因，已经存在从使用RBS到所谓的机器学习（ML）的重大转变，在机器学习中，应用“学习”如何将给定条件识别为特征分类的输出，从广泛标记的训练集中进行学习。例如，系统可以在输入的训练集上被训练，这些输入对应于具有绿灯但是汽车阻塞交叉路口的交叉路口，使得该软件自动识别这种情形。在内部，它使用人工神经网络，其中与节点相关联的概率或权重被调整以产生训练集中的实例的正确答案。

然而，基于ML的系统关于它们的动作既不完全可预测也不完全可解释。预测该系统对不在其训练集中的场景可能如何做出反应是不可能的。解释为什么它对给定输入集的反应中做出它所做出的事情是不可能的，除非输入与训练集中的一个实例精确匹配。最后，已经示出的是，攻击者可能经常通过使输入略微失真来使基于ML的系统完全混淆。例如，已经示出了ML系统在其在交通标志上被广泛训练之后会将停止标志混淆为让行标志，尽管对于人类观察者来说，该图像显然是停止标志。该示例说明了ML在一些应用中的危险漏洞。

ML系统做出较差决策的另一个示例由若干起AV/自驾驶车辆事故来证实，在这些事故中，该系统在有些混淆的情况下做出了较差的决策。例如，在一种情况下，车辆在撞上护栏之前刚加速，这违反了基本驾驶规则，即：如果你关于情形感到困惑，就减速。类似地，在当图像不完全在它已经在其上被训练的训练集内时的一些情况下，基于ML的图像识别已经被混淆并且产生了明显错误的解释。

如所公开的规则集实现方式的自动生成基于关键观察结果集合，并且是从该关键观察结果集合中导出的。

第一关键观察结果是，规则可以被分成如本文中提到的两个类别：

• const规则——被触发时不生成任何外部输出或外部动作的那些规则；以及

• non-const规则——直接引起外部输出或外部动作的那些规则。

术语“const”和“non-const”来自C++命名法，指代规则是否在逻辑上改变状态，包括外部状态。

在传统的RBS术语和实现方式中，存在内部工作存储器。规则可能采取的动作包括添加、移除或修改该工作存储器中的事实、以及可能地执行某个外部动作/输出。const规则是仅作用于该工作存储器的规则。non-const规则采取在规则引擎之外可见的某个动作。如果规则集包括更新内部工作存储器、以及生成外部动作或输出两者的规则，则它可以被划分成两个规则，每个规则具有相同的条件，其中一个规则完成前者，并且因此是“const”，并且另一个则仅执行外部动作，具有对冲突解决的某种指示以在两个规则匹配时执行这两个规则。

第二关键观察结果是，const规则可以被视为逻辑蕴涵（implication）。特别地，规则被构造为“条件→动作”。对于const规则，该动作是仅仅将事实F添加到工作存储器。因此，const规则可以被视为“条件→F”。也就是说，该条件的真实性暗示条件F为真，其中条件F是布尔表达式，当它为真时，该布尔表达式对应于“事实”。如本文中所指代，术语“暗示”和“蕴涵”用于逻辑意义，即A暗示B意味着如果A为真，则B为真。

第三关键观察结果是，与规则集相关联的“规则条件”集合是在执行中维护和评估起来困难的方面。这是因为规则条件可能演变成非常复杂的表达式，而动作通常非常有限且相对简单，并且通常被指定为执行动作的单独过程。使用上面的示例来说明，存在车辆可以执行的有限数量的动作，诸如制动、加速和/或转弯。复杂的是诸如先前概述的针对在交叉路口处继续前进的条件之类的条件。

如本文中所指代，术语“条件”在它是条件表达式时被常规地使用，该条件表达式在为真时指示该条件存在。术语“条件”和“子条件”在本文中以相同的方式使用，即针对布尔表达式以及针对该布尔表达式在其中为真的状态两者。

第四关键观察结果是，规则集可以被重写为等效的规则集，使得每个规则条件是布尔子条件的合取（conjunction）。特别地，如果原始规则条件在顶层处具有析取（disjunction），则这可以被重写为多个规则，对于析取中的每个子条件有一个规则。例如，如果规则是：

（SC0 || SC1 || SC2）→动作3；

它可以被重写为三个规则，即：

SC0 →动作3；

SC1 →动作3；

SC2 →动作3；

因此，如果这三个原始子条件中的任一个为真，则触发该动作。

其他常规的布尔变换允许经重写的规则集中的每个规则条件是合取。也就是说，规则条件可以被重写为子条件的合取，例如：

（SC0 && SC1 && SC2）→动作14；

指示子条件SC0、SC1和SC2是否全部为真，具有这些子条件/特征的场景是该情况，因此系统可以执行标记为动作14的动作。

第五关键观察结果是，规则条件正在尝试在特定于应用的模型中实现事实或输入与给定场景的匹配。例如，在特定的应用领域（诸如，自驾驶车辆）中，规则条件可以对应于看到停止标志，并且子条件是：SC0——红颜色、SC1——八角形、以及SC2——刻有“停止”。因此，关键关注点在于将每个规则条件指定为该应用领域中需要执行相关联的动作的一个或多个场景。换句话说，non-const规则可以被视为在逻辑上从其规则条件中推理出其相关联的动作是适当的。

如本文中所指代，术语“模型”指代计算机科学模型，它是系统或实体的面向对象的表示。对“模型”的该使用区别于使用同一术语来指代系统的基于数学等式的规范。特别地，指定了元素及其关系的对象模型被讨论。如本文中所使用的，规则集维护者（例如，系统管理员或程序员）可以考虑添加附加的任意子条件SC3，即布尔表达式。然而，实际上，仅有可能有意义来进行指定的（一个或多个）子条件是帮助匹配给定场景的（一个或多个）子条件。在如与ML和图像解释一起使用的常规术语中，SC0、SC1、SC2和SC3是该场景的特征或者表示该场景的特征，用于对该场景进行分类。在子条件指定传感器输入方面的给定表达式对于该场景为真的意义上，它们表示特征。例如，子条件可以是“正在接近交叉路口”。

如果规则条件RC0相对于另一个规则是模糊的，则向该规则条件RC0添加子条件SC3可能是重要的。否则，规则条件RC0可能是指定不足的。另一方面，如果RC0相对于其他规则条件不模糊，则向RC0添加SC3是不必要的，并且会增加规则条件评估成本。也就是说，将SC3添加到规则条件可能会使其过度指定。

第六关键观察结果是，通过将特征视为症状并且通过考虑特征在其中被分类为根本原因的类，特征上的这种匹配或所谓的特征分类可以被变换成根本原因分析的问题，也就是说，被检测的图像的根本原因是该图像中对应分类的对象。例如，红色、八角形并且刻有“停止”的症状/特征的根本原因是该图像中作为停止标志的对象。

更一般地，可以通过如下操作将RBS变换成根本原因分析的问题：

a）将non-const规则的每个子条件视为症状；

b）将const规则视为症状传播。也就是说，如果条件→事实是const规则，则对应于该条件的“症状”传播到该规则所指定的也是症状的“事实”；以及

c）将根本原因视为单独地映射到要执行的动作的标签。

相反，根本原因分析可以被视为特征分类，其中特征是症状，并且输出分类标识特定的一个或多个根本原因。如上所描述，根本原因分析也可以被视为基于规则的系统，其中non-const规则的每个动作是“输出该根本原因”，并且每个const规则被视为指定症状传播。

如上变换的规则集RS可以通过如下操作被嵌入对象模型中：

a）针对RS中子条件中提到的每个元素，引入元素和对应的元素类型（如果尚未定义），例如网络switch（交换机）元素；

b）针对RS中子条件中提到的每个属性，在对应的元素类型中引入该属性（如果尚未存在）。这包括对应于对象之间的关系的属性。在一个实施例中，这通过手动和/或自动定义和/或修改面向对象的模型来完成；

c）针对每个non-const规则，在适当的元素类型中引入对应的符号子条件，该符号子条件标记有对应动作的指示，并且被指定以暗示构成定义了该规则条件的合取的子条件。每个子条件被定义在最相关的元素类型中，也就是说，即该子条件在其中为真的类型。例如，在网络模型中指定链路元素类型上下文中的“cableBreak（线缆断裂）”条件。另一个示例可以是“看到停止标志”的符号子条件，其引入了诸如“红色”、“八角形”和单词“停止”之类的蕴涵；

d）针对每个const规则，指定由该const规则指定的子条件蕴涵。特别地，如果该规则是“A→B”，则将在其元素类型中的子条件A的蕴涵指定到在相同元素类型、或与该元素类型以某种方式相关的单独元素类型中的B；以及

e）将可以直接从元素属性中确定的子条件指定为可观察对象（observable）。

图3是计算机网络的简单模型的实施例的图示。图3的模型用面向对象的编程语言语法来表述，其图示了该规则嵌入。

如图3中所示，存在针对如下各项中的每一个的元素类型：Unilink（单向链路）（302）、Link（链路）（304）、Interface（接口）（306）和Switch（交换机）（308），它们对应于计算机网络的物理层处的典型组件。每个元素类型具有在其范围内指定的子条件。例如，Link类型（304）具有名为cableBroken的子条件。该子条件还指定了actionLabel，从而使其成为与该actionLabel相关联的规则的规则条件。

该子条件还包括语句→component：：lossOfSignal；意味着该子条件暗示Link的每个Unilink组件中的子条件Unilink：：lossOfSignal。一般而言，在这种语法中，蕴涵语句指示在接收元素中从该子条件推理出的子条件所遵循的关系。关系是元素的属性，诸如，在该示例中，Link：：component属性是Unilink对象的阵列。

Interface元素（306）类似地包含由该较早的语句所暗示的lossOfSignalIn子条件，并且然后进而向它的父代Switch（308）将该子条件暗示为lossOfSignalIn。“$”符号指示由元素名称替换的参数。因此，例如，如果该接口是eth3，则$由eth3替换，作为该推理的一部分。Switch中的lossOfSignalIn子条件被指示为observableBy，表达式即signalIn ==0。这意味着该子条件可以由类型属性方面的表达式检测到、或者等于该表达式。这些属性通常由监测系统设置，监测系统正在从交换机接收该信息作为实时遥测。出现在可观察子条件中并且可能改变的变量或属性在本文中被称为输入属性。

在一个实施例中，可以取而代之地以推理的形式来指定蕴涵。例如，

指定了可以从该当前元素类型所依赖于的调制解调器中的lossOfSignal子条件来推理出signalLoss子条件。这种“推理”形式等效于该示例中从调制解调器到当前元素指定的蕴涵。然而，推理在指定中是有用的，因为元素通常不是利用依赖于它的所有元素的知识来指定的。在这种情况下，依赖元素可以指定推理，从而避免指定中的这种逻辑折衷。例如，可逆关系可以是服务器到客户端之间的关系，以指示问题从服务器到其所有客户端的传播。因此，如果客户端正检测到服务器的问题，则它也可以推理出服务器具有问题。

要注意的是，属性Interface：：connectedToBy被指示为Unilink：：connectedTo关系的逆（inverse）。一般而言，跨其指定了子条件蕴涵的每个关系都需要具有逆关系。在某些标准关系（诸如，component）的情况下，逆是隐式的或已知的，即在这种情况下为parent。

图4是利用元素类型创建的网络实例的实施例的图示。例如，图3的元素类型在图4中示出。在图4中，存在两个交换机，交换机0/SW0（402）和交换机1/SW1（442），均是较早描述的Switch类型的实例。每个交换机SW0（402）和SW1（442）分别被示出有一个组件接口I14-s/eth14（404）和I3-a/eth3（444）、以及分别用于交换机的功率传感器SW0（406）和SW1（446）。图4中未示出的也可以是用于网络接口（404、244）的功率传感器，如果它们被离散地供电的话。

在实际网络中，每个交换机通常可能存在多个接口，并且潜在地存在更多的交换机。这两个连接的接口之间的Link（422）被建模为两个组件的单向链路（422a和422b），均是Unilink的实例。这种水平的细节允许指定蕴涵的方向性。它还允许对故障进行建模，诸如链路的一个方向发生故障，而另一个方向继续起作用。

该简单模型图示了如何在诸如Link（422）之类的元素类型中指定规则条件，在Link（422）上可能没有遥测，这是因为Link（422）上没有传感器。然而，相关联的子条件可能暗示中间元素（诸如单向链路）中以及然后去往到其父代交换机的连接接口的子条件，在这点上它们暗示可观察的子条件。

在一个实施例中，在如图3中所图示的模型中指定输入规则集。因此，分区成const和non-const规则仅仅是如下问题：即认识到每个const规则被指定为从一个子条件到（例如在相同元素中或在与另一个元素的关系之上的）一个或多个其他子条件的蕴涵，并且每个non-const规则被指定为由来自标记有其动作的子条件的蕴涵所达到的可观察子条件的合取所产生的规则条件。

在下文中，规则集被假设为如上那样被嵌入在模型中的输入，或者被自动变换并且嵌入到该模型中，作为使用本文中描述的算法的输入处理的一部分。如本文中所指代，“嵌入”意指从物理放置的角度被指定在对象模型内部，如图3中所示。例如，在unilink元素的情况下，子条件是lossOfSignal，这暗示去往它connectsTo （所连接到）的元素的信号输入的丢失指向interface（接口），如图3中的对象模型中所示。图3中的面向对象的模型建立了上下文并且维护重要的对象之间的关系。

自动根本原因分析（ARCA）。系统可能具有许多故障源，范围从装备故障到计算机硬件故障到软件故障到操作员错误。在复杂系统中，互连的组件之间存在许多依赖关系。针对监测系统的机构也可能遭受故障。由于依赖关系，一个组件的故障可能导致指示故障状况和/或症状的另一个。级联故障可能会导致大量警报，从而使得确定根本原因故障的任务相当困难。如本文中所指代，这些额外警报是根本原因故障的“症状”。

使根本原因分析自动化的传统方法已经尝试通过查找故障之间的统计相关性来找到根本原因，其假设强相关的故障是根本原因。然而，相关性可能不指示因果关系。另一个相关的统计方法是使用机器学习技术来“识别”不同的故障场景。然而，这种方法的可靠性低，除非有经标记的训练集的非常大的集合可用，这可能是昂贵和/或不切实际的。

使用三元故障场景的自动根本原因分析（ARCA）是一种替代技术。“症状”在本文中被称为被监测系统的一些组件的所命名和/或定义的状态，这对于将一个故障场景与另一个故障场景区分开是重要的。如本文中所指代的“三元系统”可以部分地通过使用与对应于未知症状值的“未知”值相对应的症状值、以及“不关心”值（也被称为与对于特定分析不需要的症状相对应的无关值）而被用于ARCA。在一个实施例中，每个症状值被限制为真、假或未知之一。因此，症状值在本文中被称为“三元”值。在一个实施例中，未知值和不关心值由相同的值来标示，它们基于使用的上下文被区分为一个或另一个。

三元匹配和ARCA。在一个实施例中，使用用于ARCA的三元系统来实现RBS条件匹配。如上所描述，复杂的被监测系统可能具有许多故障源，并且甚至用于监测这种系统的机构也遭受故障。例如，监测制冷系统的温度传感器可能永久或间歇地发生故障，这指示被监测的系统的不正确温度。

组件依赖关系可能会引入进一步的复杂性，例如，制冷系统中的冷却盘管依赖于压缩机的正确操作来提供冷凝的制冷剂。这些依赖关系产生于这些组件的互连。如上所描述，一个组件的故障可能导致指示故障状况/症状的另一个。因此，当一个组件具有故障时，它可能导致依赖于有故障的组件的组件中的级联故障，从而使得确定实际根本原因故障的任务变得困难。在一些情况下，根本原因甚至可能不存在于提供给操作员的警报当中。

例如，如果两个计算机网络交换机之间的线缆发生故障，则可能存在来自线缆的任一端处的交换机的大量警报。然而，通常不存在直接指示线缆断裂的警报，这是因为没有直接处于线缆上的能够检测线缆断裂的传感器。复杂系统也可以在多个层中实现，从而创建另一依赖关系集合。这些层依赖关系是另一个警报源。例如，上述线缆故障可能引起传输层指示它具有会话超时，因为没有确认正在被接收。类似地，IP层处的错误配置可能引起生成TCP/传输层和路由层处的警报。

传统上，这些额外的警报被称为根本原因故障的症状。生成大量这些症状作为警报使得确定实际根本原因更加困难。使用症状的高效匹配、而不需要使用故障之间的统计相关性或不切实际/成本高昂的大型训练数据集，对操作原理、依赖关系和因果关系、以及工程系统由于其工程设计而已知的潜在根本原因进行编码的高效方式是对ARCA的改进。这种效率减少了存储成本和/或降低了处理器的功率消耗，以便确定根本原因分析。这种高效方式允许自动且高效地执行根本原因分析。

症状和故障场景。图5A是症状的故障场景向量的实施例的图示。症状的一个示例“noPower（无功率）”是指示没有功率来到被监测系统的症状。症状的状态可以是已知值，或者其未知和/或不关心的特殊指示。数字逻辑中通常使用术语“不关心”来指示相关联的项目是无关/不需要的。该处理指示不关心给定症状的能力允许分析继续进行，即使当系统状态的该方面实际上未知时亦如此。

“故障场景”在本文中被称为指示被监测系统的已知和未知故障状态的症状值的集合。在逻辑上，从系统有些问题或没有问题的所观察到/确定的症状的角度来看，故障场景表示该系统的状态和/或潜在的部分状态。它可能不指示该系统的完整状态。例如，在车辆的情况下，故障场景可能不一定指示车辆的位置、速度等，而仅指示症状的状态，即执行故障的根本原因分析所需要的方面。

如图5A中所示，在一个实施例中，故障场景被表示为值的阵列（512），其中每个条目（514a-m）对应于指定症状。例如，症状Sy0（514a）是第一条目，症状Sy1（514b）是第二条目，以此类推。在一个实施例中，可能存在与相同度量相关联的多个症状。例如，对于温度传感器略微高、中等高和极其高，可能有不同的症状。在一个实施例中，可能存在与基于不同导数水平的相同度量相关联的症状。例如，症状可能与具有为零的一阶导数太久的度量相关联，也就是说，它是常数，这通常指示输入传感器已发生故障。症状可能与一阶导数过高相关联，这意味着它改变得太快。

可能存在与度量相关联的附加症状，附加症状指示该度量超出范围或行为不正确。在这种情况下，例如超出范围的症状与指示度量过高或过低的症状被同时设置。这种“聚合”形式的症状可以允许根据“超出范围”指定故障场景，而不必覆盖“过低”和“过高”两者。

在两个故障场景s0与s1之间定义匹配运算符以返回真

bool isMatching = match（s0,S1）；

如果s0中的每个症状条目要么是不关心，要么与s1中的对应条目中的值匹配。要注意的是，匹配操作不是可交换的；match(a,b)可能不一定等于match(b,a)。

根本原因表。图5B是根本原因表（RCT）的实施例的图示。RCT是如下表，其中每一行是故障场景，其标记有相关联的根本原因。在该上下文中，症状的未知值在这种故障场景下被解释为不关心。例如，针对根本原因“不良电动机”，该行中的症状可以是：“noPower（无功率）”为假；“motorNotRunning（电动机不运行）”为真；以及被指示为不关心的所有其他症状。

在一个实施例中，RCT针对每一个故障或事件包含可以是根本原因的行，其中每一行指示：必须为真以使其作为根本原因的症状、必须为假的症状、以及被设置为指示不关心的其余症状。要注意的是，针对给定根本原因将更多症状指定为特定值而不是不关心超出了绝对最小值，可能会导致根本原因未被标识或匹配，这是因为额外的症状可能未知、或与针对该行指定的症状相反。因此，指定针对将该系统诊断为与表中的行相关联的特定根本原因所需的最小已知症状集合是重要的。如果给定根本原因可能具有多个标识症状集合，则在RCT中存在多行，作为每个集合的一行。给定根本原因可能具有多个对应的行，这是因为一行对应于最小症状集合，而其他行对应于具有附加症状的最小集合，这些附加症状在根本原因中提供了更大置信度。例如，在交换机的功率故障的情况下，最小集合可能仅包含来自交换机的电流传感器的“lossOfPower（功率丢失）”症状，而附加行可能包含该症状加上来自直接附接到发生故障的交换机的交换机的“lossOfSignal（信号丢失）”症状。

在一个实施例中，每个RCT行以与故障场景相同的方式来表示。由此，在本文中可以将其称为“潜在故障场景”。如图5B中所示，RCT（522）包括k+1行（524a-304l），每一行与特定根本原因相关联，每行具有N个症状。例如，根本原因#0与第一行（524a）相关联。每一行（524a）中的症状（204a-m）的值不同于其他行（524b-304l），每一行对应于相关联的根本原因的潜在故障场景，如由标记为#0到#k的根本原因所指示。

与潜在故障场景形成对照，从被监测系统确定的故障场景在本文中被称为“实际故障场景”。针对被监测系统可能存在多个实际故障场景。一个实际故障场景可以是特定子系统与另一个子系统相比的更详细的故障场景。多个实际故障场景的另一个源是关于故障的不确定性。例如，一个场景可能具有对应于系统温度过低的症状，而另一个场景可能具有指示温度传感器已发生故障的症状。在后一种情况下，这可能将温度传感器相关症状指示为未知。

在一个实施例中，使用三元症状值，使得症状被表示为：通过分别为真或假而指示已知或未知的“已知”位，以及指示真或假的第二“值”位，该第二“值”位仅在已知位被设置为真的情况下被如此解释。四元命名法在本文中指代[a,b]，其中a是状态是否已知（0 =未知，1 =已知），并且b是与状态相关联的值（0 =假，1 =真）。在该约定的情况下，可允许对[0,1]进行的解释是相关联的症状未知为真：将可能对应于未知的[0,0]与可能被解释为未知为真的[0,1]进行比较。要注意的是，RCT中的条目中的[0,1]症状可能匹配于输入为假或未知，这与[0,0]不同，其对应于“不关心”，并且匹配于实际故障向量中的对应条目中的任何值。因此，[0,1]可能不一定被视为与[0,0]相同和/或不被允许。

图5C是已知位和值位的64位块表示的实施例的图示。在一个实施例中，故障场景表示为被分区成“已知”位序列和值位序列的位块。例如，如图5C中所示，一个实现方式使用64位块，其中前32位是“已知”位，并且第二个32位是值位。参考图5C，如果第i个已知位为1，则第i个值位指示对应的症状是真还是假；否则，实际值是未知的，并且第i个值位没有意义。该实施例允许高效地确定块中的“已知”位。这也意味着，如果块中的所有症状都是未知或不关心的，则不需要存储该块。也就是说，没有对块进行显式存储被解释为该块仅包含“不关心”值。

根本原因分析。图5D是根本原因分析技术的实施例的图示。通过使用匹配引擎（534）以将给定实际故障场景（532）与RCT（522）中的每一行进行匹配，并且将匹配的那些行指示为可能根本原因，来确定与给定实际故障场景（532）相关联的实际根本原因。也就是说，如果故障场景匹配于一行，使得每个条目通过上述match(a,b)运算符而匹配，则与该行相关联的根本原因被输出为与该症状相关联的可能根本原因（536），如图5D中所示。

这种匹配本质上是“三元匹配”，但是与三元内容可寻址存储器（T-CAM）提供的三元匹配不同，输入故障场景也是三元的。然而，T-CAM可以用作高效/硬件匹配系统的一部分。被监测系统中可能存在多个同时的根本原因故障。因此，该匹配有可能与RCT中的多行匹配，每个根本原因有一行。例如，电动机可能在温度传感器因指示完全不切实际的读数而已发生故障的同时发生故障。可能存在映射到相同根本原因的多行。这处理了其中根本原因故障可能由不同的症状集合所指示的情况。

在一个实施例中，行表示并不显式地存储不关心条目。也就是说，没有对第i个症状进行显式标示或表示被解释为针对第i个症状不关心。在一个实施例中，症状被聚合成与被监测系统的逻辑单元或组件相关联的块。例如，实施例可以使用较早描述的已知位/值位的64位块。因此，如果组件与特定根本原因无关，则不需要存储整个块。然后每一行可能需要相对少量的存储。通常，大多数行相对稀疏，因为仅症状的小子集与特定故障相关，所以实际上仅存储了该行的小百分比，其中在默认情况下，其余行是不关心。

任意故障标准的表示是通过使用多个症状来实现的。例如，一个根本原因由温度非常高来证明，又一个根本原因由温度高来证明，并且另一个根本原因由温度略微高来证明。也就是说，每一行中可能存在针对这些级别中的每一个的症状条目。

关键元素是：将已知为假的症状指示为无故障的症状，以及将已知为真的症状指示为存在故障的症状，同时仍虑及未知或不关心。假的情况有效地过滤掉由于另一个原因引起的症状，例如压缩机没有在工作，但实际上是无功率，这是根本原因。因此，在子系统SSi中的故障可以被可靠地标识为根本原因之前，依赖于许多其他子系统的子系统SSi可能需要知道所有这些其他系统都在工作。

基于根本原因分析技术的基于模型的生成。建立在对与自动根本原因分析的关系的观察之上，存在传统技术用以从元素的高级模型、这些元素之间的关系、症状、以及从根本原因到可观察症状的跨这些关系的症状传播来自动生成根本原因表（RCT）。该方法还可以与合适的扩展一起使用，以生成如上所描述的三元RCT。三元匹配对于避免必须为每个输入属性指定子条件是重要的。

在一个实施例中，模型类似于图3中所图示的模型，并且类似于RCT参考，而不是常规的规则集。该模型捕获应用域的关键元素或对象以及其子条件，也被称为特征和/或症状。例如，在自驾驶应用中，该模型可以包括车辆、道路、交叉路口、驾驶标志、行人等。子条件依据去往模型的实际输入（诸如，车辆停止）来表述，或根据输入（诸如，车辆超速限制）来计算，基于给定行进区域的速度限制和车辆速度来计算，由车轮旋转速度和可能的位置信息来确定。这些动作在模型中被指定，如图3中所图示。

在一个实施例中，作为中间阶段，编译器模块自动将该模型转化成有向无环图（DAG）的集合，每个有向无环图都植根于作为non-const规则的规则条件的子条件处。每个DAG的叶是依据输入属性来表述的子条件。

图6A是用于执行自动转化的过程的实施例的图示。在步骤（601）中，在该模型中的所有元素之上迭代以构建规则条件的集合。在步骤（603）中，针对该集合中的每个规则条件RC，将规则条件RC视为DAG的根，并且在与该规则条件RC相关联的所有蕴涵之上迭代，从而针对每个蕴涵来添加DAG中的每个链接和边，其中源端对应于规则条件，并且目的地端对应于蕴涵的目标或右手侧。在步骤（605）中，在DAG中不与输入子条件相对应的每个叶节点之上递归地迭代，包括如步骤（603）中那样添加附加节点和链接，并且当每个叶节点对应于输入子条件时终止，并且如果叶节点不具有对应于输入属性的蕴涵并且其自身不对应于输入属性，则报告错误。

图6B是网络示例的DAG集合的图示。在图6B中，存在三个规则R0（602）、R1（604）和R2（606）。每个规则具有相关联的规则条件RC0（608）、RC1（610）和RC2（612）。每个规则条件暗示一个或多个子条件的真实性，这些子条件是作为合取的该条件的组成部分。例如，RC0（608）暗示S1（614）和S2（616）的真实性。S1（614）暗示子条件S3（618）的真实性，子条件S3（618）暗示子条件S5（622）的真实性。S2（616）暗示子条件S4（620）的真实性，子条件S4（620）暗示子条件S6（624）的真实性。类似地，RC1（610）暗示S8（626）的真实性，S8（626）进而暗示S2（616）和S9（628）两者的真实性。类似地，RC2（612）暗示S1（614）和S11（630）两者的真实性。S11（630）暗示S12（632）的真实性。换句话说，导出DAG是为了反映蕴涵。

在图4中所图示的网络上下文中：

• RC0是双向链路断开，所以S1和S2表示Unilink 信号丢失。S3和S4是两个连接的interface处的lossOfSignal，并且S5和S6是可观察的每个interface的交换机中的指示器；

• RC1是loose interface（松散接口），其暗示了S8——去往Interface的功率丢失。S2是Link上的lossOfSignal。S9是可观察的switch级别处的noInterface（无接口）；以及

• RC2是另一个loose interface，其暗示了S11——去往Interface的功率丢失。S1是Link上的lossOfSignal。S12是可观察的switch级别处的noInterface。

在一个实施例中，编译器输出如下表：其中存在针对每个规则条件RCi的行Ri，以及针对每个输入子条件Ij的列。如果输入子条件Ij作为对应于RCi的DAG的叶出现，则行Ri中的第j个条目被设置为真。如果输入子条件Ij作为该DAG的否定叶而出现，则它被设置为假。在三元表示的情况下，如果在该DAG中没有对应于Ij的叶节点，则它被设置为“不关心”。该实施例还包括匹配机构，该匹配机构计算输入子条件，并且将它们与该表中的行匹配，从而为匹配的每一行输出动作标签，使得能够执行与该匹配规则相关联的动作。

在一个实施例中，编译器输出显式条件检查代码，当被调用时，该显式条件检查代码利用规则集中的规则来评估规则条件。在这种情况下，它生成“if（如果）”语句，该语句的条件是作为与non-const规则相关联的DAG的叶的子条件（即其输入子条件）的合取。例如，考虑图6B，针对RC0（608），编译器生成代码以检查规则条件为：

如果（S5与S6），则针对R0执行动作；

该模型的一个解释本质上是图6B中所示的示例：R0（602）对应于当接口中的线缆断裂时要采取的动作。因此，RC0（608）对应于“线缆断裂”。该条件暗示该线缆的两个单向信道上的信号丢失，这对应于子条件S1（614）和S2（616）。然后，这些子条件中的每一个暗示关于信号丢失的附接接口的子条件，这对应于子条件S3（618）和S4（620）。然后，这些子条件中的每一个暗示关于相关联的交换机的子条件，即S5（622）和S6（624），它们对应于由两个交换机报告的遥测值，该遥测值指示这些接口中的每一个上的信号丢失。

在一个实施例中，该处理是对其他工作（诸如，ARCA工作）的适配，该适配通过用“子条件”来替换“症状”并且用动作标示来替换根本原因标示。再次考虑自驾驶应用，规则“因为阻塞而在进入交叉路口时在绿灯下保持停止”在元素AV（用于自主车辆）中具有如下规则条件：该规则条件在交通灯检测器中暗示子条件“isGreen（是否绿灯）”，并且在交叉路口检测器中暗示子条件“isEntering（是否进入）”，并且在障碍物检测器中暗示子条件“IsBlocked（是否被阻塞）”。然后，该规则条件被生成为这些子条件的合取为真。在类似C++的伪代码中，所生成的规则可以指定为：

这种生成基于如下观察：即RCT的行正在将根本原因指定为可观察对象/可观察的症状的合取，因此通过上面的转化，用于规则的条件是对应输入子条件的合取。因此，表1是表示图6B的DAG的RCT：

表1：图6B中的示例的根本原因表。

。

将动作与条件评估分离。在一个实施例中，通过在该模型中指定场景标签或动作标签来代替根本原因名称，并且提供场景标签到动作的单独映射，来间接地指定non-const规则的动作。在该实施例中，再次使用上述示例，规则可以是：

所以标签是“enteringGreenBlockedIntersection（进入绿灯阻塞交叉路口）”。

执行规则评估之后，将所输出的标签与相关联的动作进行匹配。在这种情况下，actionMap（动作映射）可以映射到动作“remainStopped（保持停止）”。在类似C++的伪代码中，一个实现可以是：

其中“actionObject（动作对象）”是C++对象，它具有虚拟函数performAction（执行动作），performAction在该对象的每个派生类型中被覆盖以执行期望动作。

在这种情况下，actionMap可以映射到派生类型的对象，该对象覆盖performAction过程以执行“remainStopped”动作。这种间接性意味着该匹配利用标签来标识场景，并且场景被映射到动作。因此，相同的动作实现方式可以跨多个场景被共享。事实上，可以通过具有“comeToStop（达到停止）”动作来完善该示例，该动作可以应用于许多不同的场景中，这些场景不一定涉及交叉路口、交通灯或阻塞。例如，可能存在如下情况：道路工人在将道路变窄为一个车道的某种施工之前举起停止指示符。在该场景中，可以调用相同的动作，以及许多其他动作。

为了解释清楚，动作映射被示出为文本标签映射。然而，在内部实现方式中，标签可以是至相关联动作对象的指针，所以在C++术语中，映射本质上只是虚拟函数调用。

为了解释简单，performAction函数被示出为不具有任何参数。然而，在一个实施例中，可能存在与被传递给performAction函数的匹配场景相关联的“scenario（场景）”对象，即actionObject->performAction(scenario)；其中“scenario”是对该场景的描述。例如，“comeToStop”动作需要关于与阻塞的距离以及车辆速度来参数化。该额外信息可以允许该动作过程确定它是否需要用力制动或者渐渐制动是否足够。

因此，来自图6B的编译结果包括针对其进行匹配以执行规则条件评估的表和/或显式地评估规则条件的所生成代码。在一个实施例中，依据规则条件中涉及的元素和输入来参数化所生成代码。因此，编译结果可能是倾向于自动轮询驱动、存储器密集型操作的表，比如每五分钟轮询一次。编译结果还可以或替代地是所生成代码，其倾向于经由代码生成来参数化代码的中断和/或症状驱动的代码库，并且可以例如由症状来触发。

为了执行冲突解决，如传统上在RBS中指定的那样，一个实施例创建匹配的动作标签的匹配集作为条件评估的结果。然后，如果该集合中存在指示正在触发多个规则的多个条目，则它将冲突解决应用于该集合，以选择要执行的动作子集。关于选择动作的技术存在相当多的其他参考，包括优先级，时间匹配，并且至少部分地基于如本文中描述的概率。

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

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

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

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

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

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

传统ARCA的示例是DellEMC的SMARTS程序，该SMARTS程序可以将概率应用于输入上。当它可以使用基于汉明距离的最接近匹配时，它似乎不生成多个根本原因匹配。除了平局之外，对汉明距离的使用将通常仅给出一个最高匹配。在给定将汉明距离用作任意度量的情况下，在相对性（relativity）中什么语义或值被附加到第二接近的匹配、第三接近的匹配等等不一定是清楚的。

本文中示出了用于生成对应于被诊断的系统的症状的可能的根本原因故障集合的高效自动化手段，包括通过指定和/或预先指定多个潜在故障场景。如本文中所指代，潜在故障场景可以对应于当系统中的给定故障发生时所预期的症状集合。如本文中所指代，症状是可观察的值或值范围，或可根据与标识故障相关或与故障相反指示的可观察值来计算的值。与可能将概率应用于输入上的SMARTS不同，本文中的技术将概率与输出相关联，例如表述为置信度水平。如本文中所指代，给定潜在故障场景的症状集合，潜在故障场景的置信度水平是该系统中的场景故障的概率。

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

然后，可以基于匹配的潜在故障场景的属性和其他信息来完善该匹配集。如本文中所指代，属性包括与匹配的潜在故障场景相关的任何信息和/或关系，诸如匹配的症状、匹配的标识和/或匹配的置信度水平之间的关系。然后，可以输出与完善的匹配集中的条目相关联的根本原因故障，该根本原因故障构成根本原因分析的结果。该根本原因分析可以产生潜在根本原因集合，该潜在根本原因集合很可能将包括一个或多个实际根本原因故障。

网络示例——多个潜在故障场景。基于图4的示例是网络的当前症状中的症状，该症状是计算机网络交换机报告的在其特定一个接口上的“信号丢失”。

SW0（402）报告的在接口I1-a（404）上的“信号丢失”的实际故障场景可以与对应于交换机SW0（402）与交换机SW1（442）之间的链路a（422）中存在链路故障的故障场景FS1匹配。然而，相同的症状也可以与其中在链路的任一端处的两个接口（404、444）同时发生故障的故障场景FS2匹配。它还可以与对应于链路a（422）中的链路故障的故障场景FS3匹配，但是不考虑附属症状，诸如对应于SW0传感器（406）和SW1传感器（446）处的功率丢失的症状已知为假。因此，在该示例中，匹配集由FS1、FS2和FS3组成。其表格式表述为：

通过基本场景的相关联的派生场景来包摄（subsume）基本场景。在一个实施例中，潜在故障场景的属性指示一个潜在故障场景FSa何时被另一个潜在故障场景FSb包摄。也就是说，每当FSb匹配时，FSa也将匹配。如本文中所指代，FSa是基本场景，并且FSb是派生场 景。在FSa和FSb两者都匹配的情况下，匹配集的完善是在将故障场景转化成其相关联的根本原因之前，从匹配集中移除FSa。

为了说明这种情况，继续图4的网络示例，匹配完善步骤将识别出：FS3被FS1包摄，这是因为FS3仅需要匹配FS1需要的症状的子集。

被派生场景包摄的基本场景的另一个简单示例是医学示例：

• 潜在故障场景FSm示出：在给定高体温和疼痛的症状情况下的具有80%置信度水平的流感根本原因；以及

• 潜在故障场景FSn示出：在给定高体温、疼痛和头痛的症状情况下的具有90%置信度水平的流感根本原因。

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

输出概率的组合。在一个实施例中，完善可以识别出：匹配集中存在的两个潜在故障场景实际上是相同根本原因的两个不同症状集合，并且事实上可能均为真，因此输出包含该潜在根本原因，其可能地具有作为两个潜在故障场景的概率的组合的关联概率。例如，FSn可以是如下潜在故障场景：其示出了在给定高体温、疼痛和头痛的症状情况下的具有90%置信度水平的流感根本原因，并且FSp可以是如下潜在故障场景：其示出了在给定流鼻涕和耳朵痛的症状情况下的具有5%置信度水平的流感根本原因。

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

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

例如，使用图4的网络示例，完善将把FS1和FS2指示为彼此的替代方案，这是鉴于这两个场景均对应于共同的症状集合或症状子集。

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

• 潜在故障场景FSn示出：在给定高体温、疼痛和头痛的症状情况下的具有90%置信度水平的流感根本原因；以及

• 潜在故障场景FSq示出：在给定高体温、疼痛和头痛的症状情况下的具有3%置信度水平的枯草热的根本原因；

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

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

[RC1：0.95，RC2：0.05]

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

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

因此，首先将输出结果视为检测到断裂的链路a（422）的补救措施将在大部分时间立即解决实际根本原因故障，并且仅在5%的时间将需要进行到替代故障补救动作。在一些情况下，诸如在两个接口（404、444）同时发生故障的情况下，用户可以估计接口修复的基于概率的平均时间、和个体接口发生故障的频率以及接口数量，从而进一步限定在相同恢复窗口内发生故障的两个接口实际上处于链路的任一端上的可能性。要注意的是，链路已经发生故障并且两个接口也已经发生故障是有可能的，尽管不太可能。也就是说，替代的根本原因可能并不相互排斥。在这种情况下，需要针对两个故障的补救动作。

匹配。在一个实施例中，由匹配机构所执行的实际故障场景与潜在故障场景的匹配是确切在如下意义上：即，可能需要每个匹配的潜在故障场景使得实际故障场景针对每个症状满足在匹配的潜在故障场景中指定的症状要求。

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

这种匹配与例如在SMARTS使用的输入概率方法形成对照，在该输入概率方法中，鉴于如关联概率所捕获的关于传感器的不确定性，存在症状为真的某种概率，即使传感器没有在报告这一点亦如此。它还与各种看似任意的“基于距离”的方法（诸如，汉明距离方法）形成对照，在该“基于距离”的方法中，类似于潜在故障场景，ARCA系统正在基于实际症状与关联于根本原因的症状之间的按照某个度量的距离来选择“最佳匹配”。在一个实施例中，匹配集的生成由如本文中描述的具有三元RCT表示的三元匹配机构来执行。

未完善的故障场景匹配集可以包括多个成员，即使匹配单个实际故障的情况也是如此，部分地是因为潜在故障场景的集合应当覆盖其中某种遥测缺失或错误的情况。例如，提供了上述网络示例中的FS3，使得即使附属症状的遥测不完整或不正确，也存在某种匹配。也就是说，无法仅仅因为交换机（442）中的一个（402）或另一个不能够关于功率（406、446）向接口报告而诊断出链路a（422）中的链路故障将是不可接受的。

一般而言，匹配可以高效地实现并且能够同时匹配多个独立的根本原因，如上面关于三元故障场景表示的应用中所描述的那样。匹配具有如下缺点：当潜在故障场景中的对应于实际故障场景的任何指定症状与从遥测确定的症状不匹配时，它无法匹配。即使当人类对症状的评估可能快速地得出根本原因是什么的结论，这种情况也可能出现。

图7是图示了功率示例的实施例的框图。在该功率示例中，交换机SW0（702）经由接口和链路完全耦合到24个其他交换机SW1（742）、SW2（762）至SW15（792）。如之前在图4中所示，每个交换机（例如，交换机SW0（702））包括功率传感器（702z）、以及一个或多个接口I1-a（702a）、I1-b（702b）……I1-x（702x），这些接口各自对应于链路a（722a）、b（722b）……x（722x）。

如果去往包括SW0功率传感器（702z）的计算机网络交换机SW0（702）的功率发生故障，则将预期该交换机通过链路连接到的每个接口将检测到信号丢失。然而，如果所讨论的交换机通过链路连接到24个单独的接口I2-a（742a）、I3-b（762b）……I25-x（792x），但是这些接口中只有23个正在报告信号丢失，并且第24个I25-x（792x）正在从遥测中缺失，则匹配将无法匹配到指定了具有症状功率丢失的所有24个单独接口的潜在故障场景，即使任何明事理的人都可以从该症状中得出如下结论：该交换机已发生故障，并且此外，如果交换机SW0功率传感器（702z）报告了功率丢失，则该交换机是由于功率丢失而发生故障。

如本文中所示，利用这种匹配的能力来同时匹配到多个故障场景以便补偿该缺点是重要的。特别地，除了具有对应于所有症状的潜在故障场景之外，还存在被指定对应于针对相同根本原因的部分匹配的潜在故障场景。对具有潜在故障场景的相关联属性的扩展允许对匹配集进行完善，以减少实际输出的潜在根本原因的数量。

特别地，当出现与完全潜在故障场景的匹配时，对应于相同根本原因的部分匹配的潜在故障场景被消除和/或包摄。类似地，当根本原因仅由于有效地部分匹配而存在时，与潜在故障场景相关联的概率属性允许输出有效地指示输出中的该根本原因的较低置信度。

在一个实施例中，用于允许部分匹配的另一种技术被称为“近似匹配”，并且被用于其中并非所有特征（例如，子条件）都必须已知的情况。因此，近似匹配可以与部分匹配结合使用。

在一个实施例中，通过如下方式来提供近似匹配：指定距离阈值参数，并且如果根据行与掩码之间所定义的某个距离度量，行处于距离阈值内，则将所述行输出为匹配。处理额外匹配以便为了解释的效率而减少并组织匹配可以通过近似匹配来改进，这部分地通过将距离D处的近似匹配例如视为相对于距离D-1处的匹配的基本根本原因。

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

忽略一个症状的PMPFS。首先，针对根本原因的每个完全潜在故障场景，针对每个症状，可能存在忽略症状之一的PMPFS。例如，使用图7的功率示例，针对每个相邻接口，可能存在忽略该接口作为症状、或者替代地将该症状标示为“不关心”的PMPFS。例如，PMPFS可能忽略I25-x（792x）为“不关心”，并且因此其中I2-a（742a）、I3-b（762b）……I24-w（图7中未示出）报告了信号丢失，该系统可以得出交换机SW0（702）已发生故障的结论。

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

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

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

限制PMPFS的范围。用于有效地支持部分匹配同时避免PMPFS的数量呈指数级增长的另一种方法是：限制PMPFS及其症状的范围，并且对应地降低与之相关联的概率。在图7的功率示例中，可以生成如下PMPFS：该PMPFS在用于交换机SW0（702）的当前功率故障传感器（702z）上匹配，并且指定了对于邻居交换机（742a、762b……792x）的遥测有效的“不关心”。如果功率传感器（702z）报告功率故障，但存在来自一个或多个邻居交换机的矛盾信息（诸如，针对I25-x（792x）的“未知”，其可能不正确或过时），则该PMPFS匹配。

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

定义聚合症状。用于有效地支持部分匹配同时避免PMPFS的数量呈指数级增长的另一种方法是：定义基于跨多个传感器输入的遥测而设置的聚合症状。在图7的功率示例中，可以定义聚合症状，该聚合症状对应于具有来自给定交换机SW0（702）的丢失信号的相邻交换机SW1（742）、SW2（762）……SW15（792）中的多于某个阈值K个。然后，针对交换机功率丢失的PMPFS可以指定该聚合症状，使得如果该交换机的大部分直接邻居具有来自它的丢失信号，则认为该交换机已经发生了功率故障。明确地说，并入来自其直接邻居的信息的益处在于：它有助于从交换机上的电流传感器已发生故障而不是功率本身的情况中消除该情况的模糊。

症状的反向传播。用于高效地支持部分匹配的另一种方法是：从PMPFS中排除已经通过本文中被称为反向传播的事物（“症状的反向传播”的缩写）所确定的症状要求。在图4的网络示例中，针对在链路a（422）的远端/SW1端（442）处未接收到信号的一个可能解释是断裂的网络线缆。针对在链路的远端处未接收到信号的替代解释是近端/SW0端（402）处的接口I1-a（404）已经丢失功率。这是因为链路（422）的一端处的接口处的功率丢失有效地将信号丢失症状传播到链路的另一端处的接口。

使用症状的反向传播，针对该场景的症状的完全故障场景需要每个接口和/或交换机（406、446）的功率丢失症状为假。然而，这种反向传播还意味着，如果用于该交换机SW0的当前功率传感器（406）有故障，则ARCA可能无法与完全故障场景匹配，并且因此除非存在匹配的PMPFS，否则无法确定根本原因。在这种情况下，可能存在如下PMPFS：该PMPFS排除了由这种反向传播引起的这些症状，其通常具有相关联的较低概率，这是鉴于通过忽略由于反向传播而原本将需要的症状所引入的不确定性。

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

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

使用本文中的技术识别并且解决了用于ARCA的传统方法中的主要谬误；单个根本原因的假设、以及确定根据传感器输入以确定性来确定实际根本原因是可行的假设。传感器输入可能不正确。因此，基于匹配的潜在故障场景（其中一些可能对应于相同的根本原因故障）来生成潜在根本原因集合、并且然后提供完善步骤以产生精选的潜在根本原因集合可能是至少部分地基于概率来选择RBS动作的一个方式。

在一个实施例中，该模型可以指定动作在“可以以任何次序来执行并且不影响条件的评估”的意义上是可交换的，并且这在本文中被称为可交换动作RBS（CARBS）。在一个实施例中，当该模型如此指示时，实现方式可以执行与匹配集中的多个条目中的每一个相关联的动作，而无需重新匹配。例如，在自驾驶情况下，该匹配可以标识“enteringGreenBlockedIntersection”和“aboutToTurnRight（即将右转）”，其中与第一条件相关联的动作是“comeToStop”，并且与第二条件相关联的动作是“turnOnRightSignal（打开右转灯）”。在这种情况下，执行两个动作是有意义的。

在一个实施例中，使用如上描述的匹配集完善，匹配集中的一个或多个场景可以被标识为给定场景S的替代方案。在这种情况下，以最大置信度和可能的其他标准所标识的场景可以使其动作被执行，同时抑制或不执行替代方案的动作。

在一个实施例中，当相关联的规则条件保持为真时，确保某个动作不被重复执行可能是必要的。存在避免重复执行的各种技术。例如，该实现方式可以记录它上次执行相关联的动作的条件匹配的时间，并且不重新执行该动作，直到该条件变为假并且然后再次变为真。也就是说，如果没有对匹配时间戳的更新，则不重新执行该动作。

一个替代方法是使动作幂等（idempotent）。也就是说，如果动作过程在相同场景中被执行多于一次，则它具有的效果与被执行一次相同。例如，如果“comeToStop”动作已经施加了制动，则可以通过使其继续施加制动，从而使“comeToStop”动作幂等，所以多次调用该动作和调用一次该动作具有相同的效果，即幂等。幂等动作可以在每次匹配时被重新执行，但是在第二次和随后的匹配中没有效果。

一般而言，存在多种手段将动作实现方式与场景的分类分离，从而依据触发场景来参数化动作实现方式，以及执行冲突解决和/或匹配集完善，并且处理动作重新执行。此外，这些技术可以独立于被指定的实际模型，因此并不严格依赖于自动代码生成。这从上面的代码片段中是明显的，在这些代码片段中，动作映射代码不特定于该模型的任何方面，这与条件代码本身不同。

也就是说，自动代码生成可以在动作映射中执行各种优化，诸如当该模型被指定为CARBS实例时，消除用于冲突解决的代码。假设该动作本身被显式地指定为过程或类似物，因此本文中可能不一定需要或必然需要自动代码生成。因此，下面描述了规则条件代码生成。

规则条件代码的自动生成。规则条件匹配代码的自动生成可能比上面针对现实应用模型所概述的更加复杂。例如，先前示例表明了存在单个trafficLightDetector（交通灯检测器）、intersectionDetector（交叉路口检测器）、obstacleDetector（障碍物检测器）。然而，实际上，在AV正在行进的区域中可能存在许多交通灯和交叉路口。因此，交叉路口检测器需要指向与AV的位置和速度相关的一个，这与在trafficLightDetector和obstacleDetector的情况下相同。也就是说，障碍物检测器可能需要检测AV正在行进的路径上的障碍物。

在基于表的实施例中，通过生成每个元素实例的症状，并且针对共同定位的症状的特定于trafficLightDetector、intersectionDetector和obstacleDetector的症状的每个组合来生成RCT中的行，从而解决该问题。来自网络域的较早使用的示例进一步说明了这种方法。RCT方法生成针对每对连接的接口的行——其中特定于那些接口的症状被设置为指示信号丢失——以及针对每个单向线缆故障的行。实际上，针对每对连接的接口，存在如图4中所图示的DAG，其中对应的行包含该DAG的叶子条件。因此，如果数据中心网络中有10000个线缆，则存在与该一个逻辑故障相关联的10000行，每对接口有一行。将实际症状和对于条件有效的不同参数值的行分离的这种方法是用于自动化根本原因分析的方法。

在一个实施例中，生成显式条件评估代码，而不是依赖于表匹配。因此，每个non-const规则可能生成代码片段，该代码片段评估依据所涉及的元素而参数化的相关联的规则条件，并且存在将这些元素作为参数提供的相关联的数据结构。然后，通过在该集合上迭代，针对每个参数集合来调用代码片段，从而执行该逻辑根本原因的条件评估，如该数据结构中所指示。例如，可能存在连接的接口对的集合，该集合然后用于调用与检测到线缆故障相关联的代码片段。通过在该集合上迭代，调用关于每对的代码片段于是检测是否存在线缆故障。

要注意的是，使用该示例，针对数据中心网络中的10000个线缆，该集合中可能有10000个条目，在空间开销方面，这在某种程度上类似于与该故障相关联的RCT中的10000行。然而，如果存在与连接的接口对相关联的第二根本原因故障，则可以使用相同的对集合来利用该第二根本原因代码片段进行迭代，而在RCT的情况下，必然存在与该第二根本原因故障相关联的10000行的第二集合。例如，如果存在暗示着从一个接口到另一个接口的根本原因——这与来自线缆的双向蕴涵相对，则可以使用该相同集合来评估该其他根本原因。例如，如果线缆的一个方向断裂，则一个接口检测到信号丢失，但是另一个接口没有。该根本原因故障可以使用相同的接口对的集合来标识，类似于图4中所示的集合。

在一个实施例中，当多个条件使用给定逻辑根本原因的相同参数或参数子集时，这些多个条件被组合成单个代码片段，该代码片段可以被调用作为这些参数的迭代的一部分，从而评估迭代的每个步骤的条件集。例如，迭代的每个步骤可能在相关联的代码片段的单次调用中检测是否存在断裂的线缆、半断裂的线缆、过度的分组损坏和过度的分组丢弃。

在一些应用中，独立于规则执行，存在对维护与元素、其属性及其关系相对应的数据结构的需要。例如，网络管理应用可能需要按网络中的每个交换机来维护对象，该对象存储交换机的属性以及其与网络中的其他元素的关系，包括它如何连接到其他交换机。

在一个实施例中，当该应用维护与元素及其关系相对应的对象时，这些数据结构用于为一个或多个RC代码片段提供参数。例如，继续上述示例，规则引擎可以在元素对象之上迭代，为每个元素确定它所连接到的（一个或多个）其他元素，从而生成上述示例中的规则条件评估所需的连接接口对。然后，不需要单独的连接的接口对集合。在这种情况下，鉴于该应用正在将该信息存储用于其他目的，显式规则条件代码生成方法不会由于其针对其代码片段的这些参数的需要而生成额外的空间开销。在另一方面，当使用基于表的方法时，利用与元素和关系相关联的应用状态来减少空间似乎是不可行的，因此后者很可能在这些应用中招致更多的空间开销。

在利用RCT的自动根本原因分析的其他实现中，当前症状周期性地与表匹配，以检查根本原因故障，如图5D中所图示的。类似地，规则引擎通常重复轮询整个规则集，以检查为真的规则条件，以便检测规则动作可以被触发。然而，这种方法在快速轮询的开销与检测可能触发动作的条件的延迟之间遭受典型的折衷。特别地，用以最小化触发动作时的延迟的较高频率轮询引入显著的开销，而用以减少该开销的较低频率轮询增加在条件变为真之后进行触发的延迟。在显式规则条件代码下支持的替代方法是具有反应式实现方式，其中输入属性改变触发对依赖于该输入的规则条件的立即重新评估。因此，如果该动作的规则条件现在变为真，则可以无延迟地执行该动作。下面描述了这种反应式实现方式。

反应式规则引擎实现方式。在一个实施例中，编译器输出实现反应式规则引擎的代码。在如下意义上，它可以是反应式的：即它直接对输入改变做出反应，并且执行与由于输入改变（如果有的话）而变为真的规则条件相关联的动作。

图8是反应式规则引擎的实施例的图示。在一个实施例中，反应式规则引擎被实现为“监听器”模块（804），如图8中所示。“监听器”或等效地“观察器”（804）是面向对象的编程中的传统软件设计模式。实质上，监听器（804）是当“被监听”对象（802）之一中的某个感兴趣的属性已经改变时由回调通知的模块。因此，如果规则条件为真，则监听器（804）对元素属性（802）改变做出反应，从而将规则实例添加到匹配集（806）。

存在用于以C++和其他语言来手动实现监听器模块的成熟技术。总体上，在该实施例中，编译器部分使用其他技术来生成元素类型和回调通知的代码，包括在2008年5月21日提交的题为“DYNAMIC COLLECTION ATTRIBUTE-BASED COMPUTER PROGRAMMING LANGUAGEMETHODS”的美国专利申请No.12/154,354中公开的那些技术，该申请出于所有目的通过引用并入本文中。它进一步使用2008年5月21日提交的题为“NOTIFICATION-BASEDCONSTRAINT SET TRANSLATION TO IMPERATIVE EXECUTION”的美国专利申请No.12/154,399中的技术来生成监听器模块（804），该申请出于所有目的通过引用并入本文中，该监听器模块（804）具有用于每个回调通知、即用于评估可观察子条件所需的每个可修改属性的回调过程。在该上下文中，规则可以被视为模型与动作标签的匹配集之间的约束，所述约束即：如果规则条件为真，则要求规则的动作标签处于匹配集的集合中。

在一个实施例中，监听器模块（804）被生成以监听在该模型中被实例化的每个元素（802a、802b……802z）的每个输入属性。因此，在C++术语中，编译器定义了具有指向该模块需要监听或对其做出反应的每个元素的数据成员的类，要么作为单个指针，要么作为指针的集合（如果存在相同类型的多个这种元素的话）。针对每个输入属性ia，编译器还生成回调函数“onIa()”。遵循C++中的标准实践，该回调可能在单独的类中，该类是回调接口的派生类，该派生类然后调用实际的主监听器模块类。回调函数是用代码生成的，用以评估被该输入属性ia改变所影响的该模型中指定的每一个规则条件。因此，当属性“ia”改变时，该Listener：：onIa()（804）过程被调用。该过程评估依赖于该输入的规则条件，并且输出评估为真的每个规则条件的动作标签（806）。

要注意的是，尤其是在更复杂的规则的情况下，对象之间的关系阐明和/或指示连接。编译器还在监听器模块中生成必要的数据成员和集合，以允许评估这些规则条件。例如，返回到计算机网络模型的示例，对应于断裂链路的规则条件需要知道“其他”接口，即链路另一端处的接口，以评估规则条件，如以下代码所说明：

上面代码片段中“if”条件的生成是直接的，因为它仅仅是可观察子条件的合取，这些子条件是植根于规则条件处的DAG的叶，如图6B中所图示。

在以上内容中，“notifier”对应于正在执行回调的接口元素，并且otherInterface是它（通过Link和Unilink对象间接地）连接到的接口，如getOtherInterface返回的那样。因此，编译器可以生成代码来存储和维护该监听器模块中的集合，该集合可以保存连接的接口对。因此，当要评估上述条件作为执行该回调函数的一部分时，上述代码中的“otherInterface”变量被设置为“notifier”接口通过访问该集合而连接到的接口。

要注意的是，输入属性被指定为该模型中的输入，但是可能是根据实际系统输入进行的复杂计算。例如，输入属性可以是某个原始传感器值的加权移动平均值，该原始传感器值只有当该平均值以显著量改变时才被更新。因此，实际输入可能比该模型中使用的输入属性改变得更频繁并且具有更显著的改变。

在一个实施例中，监听器模块（804）被实现为定义并实现动作过程的基类的派生类（在C++术语中）。例如，可以在C++中手动指定这些动作，如下：

程序主体可以地单独指定，如在C++中的典型做法。然后，可以将规则模型生成为该ActionModule的派生类，例如，

也就是说，（所生成的）RuleModule是ActionModule的派生类，可以对该派生类进行显式编程，以便其能够访问后者模块提供的“受保护的”动作过程。然后，如较早所描述，可以针对每个输入属性生成规则评估代码，并且对动作过程的调用仅调用ActionModule中指定的那些，ActionModule通过继承被并入到RuleModule中。

在一个实施例中，监听器模块代码的所选部分可以通过手动编程来提供。例如，通过在规则条件中指定“外部”，该自动生成不针对该规则生成规则条件，而是假设/依赖于处理该条件的手动指定的代码。该规定认识到：对于特定的应用，通常需要超出编译器所支持的优化的一些特殊优化。

图9是被监测系统中的反应式规则引擎的实施例的图示。图9示出了被构造为监听器模块（804）和动作执行模块（808）的反应式规则引擎（800）如何连接到被监测系统（902至908）。在图9中，传感器（904）提供与被监测系统（902）相关联的值的测量结果，诸如温度、湿度等。这些值由遥测系统（906）收集，遥测系统（906）递送这些值以用于输入处理（908），输入处理（908）可以对输入采取若干动作。例如，它可以将传感器输入值从一种度量转化成另一种度量，诸如从A/D单位转化成以摄氏度为单位的温度。它还可以在缺失值的情况下内插或外推传感器值，或者在可能由于传感器瞬变导致的尖峰或错误值的情况下平滑或校正传感器值。在这种基调下，它可以从输入中提供计算值，诸如某个输入上的加权移动平均值。它还可以将输入流离散成由阈值定义的少量离散值，诸如例如针对温度读数的冷、凉、温、热。因此，反应式规则引擎（800）仅对越过阈值的温度改变做出反应。最后，它可以扣留（withhold）来自监听器（804）的输入值直到某个指定的周期或轮次为止，以支持对规则的周期性轮询，而不是对每个输入改变做出反应，如稍后描述的那样。也就是说，映射可以将反应式规则引擎限制成仅对阈值越过做出反应以减少噪声，扣留输入值以减少噪声，等等。

在一个实施例中，如果多个规则条件依赖于相同输入属性，则编译器在相同回调函数中生成这些规则条件。

为了识别匹配集中不再有效的规则条件，周期性过程可以测试匹配的规则条件集合，并且如果它不再有效和/或当元素“条”改变时将它从该集合中删除，它可以提示对该集合中依赖于该元素的任何RC进行重新评估。在一个实施例中，在任何时间处，只有单个独立的规则条件应当为真，与不同规则条件的匹配可以立即从匹配集中删除现有的规则条件（如果有的话）。

在一个实施例中，作为优化，编译器可以识别该模型中完全针对const规则而存在并且不对应于任何输入的对象的情况。例如，网络中的线缆通常在其上没有传感器，并且因此在没有输入指示器的情况下被建模。它存在仅仅是为了提供上下文来指定一个或多个规则条件及其蕴涵。在这些情况下，编译器可以通过折叠关系将这些对象优化出，所以评估直接对具有观察到的症状的对象发生。例如，在计算机网络的示例中，可以优化出Link和Unilink对象，并且可以将接口之间的互连直接记录在Interface对象中。特别地，利用这种优化，接口包含属性“otherInterface”，该属性指向它所连接到的接口。在像“父代”这样的关系的特殊情况下，通过通常的父代反向指针从组件元素中容易地确定父代。

非二元关系可以分解成二元关系，因此上述方法也可以用于处理三元关系/参数。当初始执行反应式规则引擎软件时，可以用实践中没有出现的输入属性的初始值来实例化所生成的对象。然后，规则引擎过程和这些输入属性可以连接到实际遥测，实际遥测引起这些输入属性被改变为不同的值，从而引起反应式行为与如较早描述的规则条件相匹配，并且然后调用（一个或多个）相关规则（如果有的话）。

在一个实施例中，编译器优化回调函数中的所生成代码，以减少执行时间和代码大小。例如，在上面的代码片段中，如果另一个规则条件需要“otherInterface”，则优化所生成代码以从上面的集合中访问该值一次，并且将该值用于两个规则条件。

作为另一个候选优化，在执行对于评估其余规则条件所必要的动作之前，可以首先测试涉及该通知输入属性的子表达式。例如，上面的代码片段可以被优化如下：

其中getOtherInterface是返回另一个接口的过程。

将otherInterface的取得嵌套在“if”块内意味着：只有在通知器的lossOfSignal属性为真时才执行getOtherInterface过程调用。在预期的常见情况下，该属性可能为假，从而节省该调用的成本

进一步的优化是识别正在被评估的规则条件中的公共子表达式。例如，对应于单向线缆断裂的规则条件对应于一端而不是另一端处的信号丢失，即：

通过识别公共子表达式，可以按照以下代码来优化该规则条件：

在一个实施例中，编译器可以确定：规则表达式的一个或多个自变量可以根据一个或多个元素中的属性来确定。例如，在网络的运行示例中，Interface实例可以具有指向其所连接到的Unilink实例的指针，并且Unilink实例可以具有指向其所连接到的Interface的指针。此外，接口必需指定逆关系，诸如Interface中的connectedToBy关系。因此，编译器可以生成getOtherInterface的类似C++的实现方式，如下：

该过程遵循这些指针，以使用这些网络元素中的状态来返回“otherInterface”，而不是具有单独的接口对的集合，从而避免相关联的状态开销。

在一个实施例中，引用的属性是集合。例如，在广播网络中，接口可以被视为连接到多个不同的接口。在这种情况下，可以在迭代循环中评估规则条件，其中对于该循环的每次迭代，将“otherInterface”的值设置为下一个其他接口。

在一个实施例中，元素类型可以被定义为另一个元素类型的派生类型，类似于大多数面向对象语言中的继承机制。派生类型可以在基本类型中的子条件上添加附加的子条件。它还可以扩展或覆盖基本类型中提供的子条件蕴涵。在特定情况下，派生类型子条件可以对应于基本类型中的规则条件的扩展或完善版本。这种派生规则条件可以扩展或完善基本规则条件的观察到的子条件。例如，基本规则可以指定其规则条件来暗示观察到的子条件SC0和SC1，所以其条件表达式为：

（SC0 && SC1）

而派生规则可以指定进一步导致SC2的子条件蕴涵，因此其条件表达式为：

（SC0 && SC1 && SC2）

在一个实施例中，可以通过指定规则条件“扩展”现有规则条件来在相同类型中指定该规则条件，从而允许在与基本规则条件相同的元素类型中定义派生规则条件。

派生对比基本规则条件可以用于有效地指定子条件的部分匹配。或者相反地，它可以用于避免如下情况：当一个或多个子条件缺失时规则条件未能匹配，即使所意图场景很可能是这种情况。例如，针对作为停止标志的对象的基本规则条件可能是它具有“是八角形”以及“是红色”的观察到的子条件。派生规则条件可以指定刻有单词“停止”的标志的附加子条件。即使刻文（inscription）可能未被阅读，对象也仍然可以被识别为停止标志，而如果刻文可以被阅读，则对象可以以更高的置信度被识别为停止标志。当派生规则条件匹配时，这些规则条件之间的派生关系提供了抑制与基本规则条件的匹配的指示。

在一个实施例中，编译器可以基于推理（即，子条件的反向传播，如上所描述为症状的反向传播）来自动生成派生规则条件。特别地，编译器可以在可能为假的派生规则条件中添加观察到的子条件，从而消除指定规则条件与其他规则条件的模糊，否则所述其他规则条件在引起它们触发的观察到的子条件中重叠。

上述优化可以用于优化用于处理基本条件和（一个或多个）派生条件评估的代码。在简单的情况下，代码被构造为：

也就是说，只有在基本规则条件成立的情况下才评估派生规则条件。

在一个实施例中，动作映射/冲突解决识别出基本和派生动作标签两者均存在的情况，并且仅执行与最派生的规则条件相关联的动作。

在一个实施例中，输入子条件可以被定义为依据实际输入属性的表达式。例如，交换机可能具有Switch：：signal level属性，而不是Switch：：lossOfSignalIn 布尔输入属性。然后，来自输入的信号丢失由如下表达式来指示：

switch->signalInLevel()<minSignalLevel()

在该模型中，这可以表述为：

在具有输入子条件表达式的一个实施例中，作为优化，编译器生成代码，使得它在执行相关联的规则评估之前，在通知时执行与通知相关联的子条件为真的检查。也就是说，作为示例，如果被通知了signalInLevel中的改变，如果值大于或等于“minSignalLevel”，则该回调立即返回。

在如上的一个实施例中，作为优化，编译器在调用回调之前生成评估该输入子条件的代码，并且如果为真，则仅调用回调过程。

由编译器用于生成规则评估代码的方法可以描述如下：

针对每个规则条件RC {

1. 遵循来自规则条件RC的子条件的蕴涵，生成可观察子条件的集合，即可观察子条件集（OSS）。

2. 针对OSS中的每个可观察子条件OSC {

2.1针对OSC中的每个输入/通知属性IA {

2.1.1找到用于“onIa”过程的回调过程主体数据结构，

如果尚未声明，则声明该回调过程

2.1.2在该过程中找到测试与IA相关联的子条件的现有“if-else”语句

2.1.3如果没有找到，则实例化该“if-else”语句

2.1.4如果是真子条件，则将OSS中的其余子条件嵌入在“if”块中

并且否则，嵌入在相关联的“else”块中

2.1.5如果该条件评估为真，则将动作或动作标签插入在被录入的所得块中

}

}

}

步骤1利用与规则条件RC相关联的DAG的叶来填充OSS，参考图4中所图示的规则条件的DAG表示。

在上面的步骤2中，假设了标准编译器技术，即具有 “if”和“else”语句的内部数据结构表示。此外，OSS仅仅是表示子条件的逻辑合取的数据结构，类似于在许多编译器内部找到的解析树结构。利用这种表示，可以将附加的语句添加到“if”语句的主体，该添加采用与通常通过解析输入来构建这种数据结构相同的方式。主要差异在于：规则条件被嵌入在“if”或“else”语句中，所述语句是以输入属性IA为条件的，而不是如在普通编程语言中那样完全如所解析的输入要求的那样来放置。而且，编译器需要确定对评估规则条件所需的其他值的访问路径，例如，在我们的网络示例中，确定如何访问“otherInterface”。然而，该访问路径可能是由当前规则条件跨其过渡到该子条件的关系、以及从当前规则条件到这些其他子条件的关系来确定的。特别地，针对每个其他子条件SCi，它使用逆关系来访问回到规则条件范围，并且然后使用与这些其他子条件的蕴涵关系来构建用于访问针对每个子条件所需的数据的路径。在一个实施例中，编译器必须评估该访问路径，部分地是为了找到另一个接口。因此，编译器可以使用DAG以通过逆转关系来确定该访问路径。

生成用于针对条件的给定自变量来找到一个或多个对应元素的代码的步骤是：

a. 使输入子条件成为当前子条件

b. 找到跨其暗示了当前子条件的关系的逆关系。（逆关系在该模型中被如此指示，如图2中指定的connectedToBy关系所图示）

c. 生成处理该逆关系中的每个元素的代码，如下（如果是集合，则为“for”循环，或者如果是单例，则为“if”条件（以允许该单例为空））：

i. 取得暗示了当前子条件的子条件（如果有的话）。通常存在单个这种子条件，所以在这些情况下，这在代码中被如此指定

ii . 遵循该子条件跨其进行暗示的暗示关系，前进到输入属性，从而排除对应于刚刚遍历的逆关系的关系。（在“otherInterface”的情况下，除了规则条件本身的情况，不存在其他关系）。记录输入属性值以用作对该条件的自变量

iii . 如果该子条件对应于规则条件，则自变量生成完成

iv. 否则，在该子条件上递归地调用该过程。

例如，在示例计算机网络的情况下，已知“lossOfSignalInEth14”的输入属性由来自“lossOfSignalIn”子条件的被命名为“eth14”的接口所暗示。后者不具有其他蕴涵。暗示该子条件的逆关系是connectedToBy属性，该属性然后提供了导入式（in-bound）Unilink对象。Unilink：：lossOfSignal子条件具有由Link：：cableBreak子条件暗示的逆关系，该子条件是规则条件，因此终止了跨逆关系的反向传播。该规则条件跨属于Unilink类型的Link的组件进行暗示。因为存在两个这种组件，明显存在单个“other”组件，即另一个Unilink实例，鉴于一个可能对应于与另一个为逆的关系，以得到该规则条件。在该“other”Unilink组件上进行前向遍历产生了该Unilink组件所连接到的“other”接口，其是在这种情况下对于条件评估所需的自变量。所生成代码可以被优化以绕过Link级别，并且将connectedToUnilink实例识别为包含指向“otherInterface”的指针的逆。结果是通过最少数量的存储器引用来找到“otherInterface”的代码。

该所生成代码的该相同内部编译器数据结构表示可以用于执行各种优化变换，以使用标准编译优化技术以及通过模型中的结构和规范而可能的其他技术来减小代码大小并且改进执行性能。

以上序列中描述的其余子条件的实现包括生成代码以像较早示例中针对“otherInterface”所描述的一样来访问这些其他子条件所使用的值。

在一个实施例中，该模型用通用面向对象的语言来表述，在该语言中，添加了子条 件的概念和子条件蕴涵。在另一个中，添加了规则构造，并且蕴涵被指示为布尔表达式。然后，如上所描述，扩展编译器以对这些规则、子条件和蕴涵执行代码生成。

为了避免过多的回调开销，可以在条件的输入属性中将输入值离散化，使得仅在该值越过与该条件相关的某个阈值时发生通知。例如，如果条件指定温度是热的作为子条件，则温度传感器可以提供仅指示“热”或“冷”的离散化属性。因此，通知不会关于温度的每个微小改变而发生，而只是在输入值从“冷”改变为“热”时才发生。

轮询和轮询优化。在一些应用中，由于输入值的快速改变，规则引擎的反应式执行招致过多的开销，其中大部分不会导致任何规则触发。例如，如果规则引擎正在执行根本原因分析，并且仅在存在系统故障且系统故障很少发生时才触发规则，则绝大多数反应都不导致有用的处理。此外，在一些应用中，规则只需要在条件持续存在达一些时间而不是仅瞬时发生时被调用。这适用于根本原因分析用例。在故障发生之后，指示该故障的条件往往持续存在，直到该故障被补救为止。在该假设的情况下，不一定对每个输入改变做出反应。取而代之，规则引擎可以周期性地重新评估规则条件，而不是对每个输入改变做出反应。在一个实施例中，规则引擎可以调用相同的所生成代码来周期性地评估所有规则条件。

在一个实施例中，通过仅在每个周期开始时将输入属性更新为其当前值来提供对规则的周期性评估和触发。这些更新引起依赖于由于更新而改变的输入属性的规则条件在当前输入上被（重新）评估。因此，不是对每个输入属性改变是反应式的，而是可以周期性地执行相同的规则引擎，并且仍然正确地操作。事实上，相同的所生成代码可能被调用为反应式的，或者被周期性地调用，这依赖于输入处理是如何被配置的。也就是说，输入处理可以被配置成：当接收到输入时或仅在轮询周期间隔处更新输入属性。要注意的是，上述处理假设：在该应用中，当触发条件在下一个周期开始时不为真时，不响应于对这些周期之间的输入的中间改变而触发动作并不是问题。也就是说，当动作的条件在执行的周期之间仅瞬时为真时，该应用允许跳过该动作。在一个实施例中，这可以通过在一时间段内冻结所有输入并且在以后的离散时间段进行更新来完成。

在另一个实现方式中，编译器生成过程PP，该过程PP在被调用时用每个可能的参数来调用每个反应式过程。在该实施例中，该PP过程在每个周期的开始处被调用。

在一个实施例中，过程的实现方式被优化以最小化或避免复制规则评估。例如，考虑到与断裂链路相关联的规则条件的先前示例，该过程可以识别出：对具有接口对（intfj、intfi）的规则条件的评估与对具有接口对（intfi、intfj）的规则条件评估是相同的，因此仅执行这些中的一个作为该过程执行的一部分。该实施例可以生成单个优化的pollEvaluate过程，该过程在被调用时实现所有规则条件，从而输出规则条件为真的指示。

总的来说，相同的代码生成技术可以用于针对周期性轮询形式的执行以及针对较早描述的反应式执行生成规则引擎代码，并且在一个实施例中动态地切换。软件编程领域的普通技术人员可以认识到：除了这里详述的优化之外，还可以实现多种优化，从而允许在轮询形式的执行的情况下高效执行。

规则的反向传播和自动检查。在一个实施例中，编译器检查规则条件的模糊性。如果存在两个条件在其上都匹配的输入子集，则这两个条件部分地模糊。如果两个条件在相同的输入子集上匹配，则这两个条件完全地模糊。

在一个实施例中，编译器检查这种模糊性。这样做的一种方法必然需要针对指定的模型和条件生成根本原因表的等效物。特别地，存在针对可观察子条件的每个特定实例的列。针对每个规则，存在依据可观察子条件来表示该条件的行，其中给定子条件的条目在该子条件在该条件中为真的情况下为真，在该子条件在该条件中为假的情况下为假，并且在三元匹配的RCT并且在所生成的条件中未指定子条件的情况下为“不关心”。

利用该生成的表，编译器然后对RCT中的每对行执行逐对匹配。如果Ri与Rj匹配，则Rj对于Ri部分地模糊。即每当Ri匹配时，Ri就匹配。类似地，如果Rj与Ri匹配，则Ri对于Rj部分地模糊。如果该对在两个方向上都匹配，则它们完全地模糊。

在一个实施例中，每当编译器确定一对规则部分或完全地模糊时，它可以输出警告消息。然后，规则集维护者可以选择完善该模型和相关联的规则条件，以消除这种模糊性。

在一个实施例中，编译器可以尝试消除模糊的一对规则条件Ci和Cj的模糊。在一种方法中，编译器从作为生成规则条件Ci的一部分的每个子条件SCk追溯回到任何其他子条件，所述其他子条件可能引起该子条件SCi为真而其对于Ci条件不为真。针对这种单独的子条件SCl，它从该子条件前向遍历到可观察子条件SCm，并且将该子条件SCm的否定添加到条件Ci。这种添加确保了Ci和Cj不再模糊。

图10是子条件的反向传播示例的图示。RCi（1002）和RCm（1004）各自分别暗示可观察子条件OSk（1008）和OSp（1012）。RCi（1002）和RCm（1004）还暗示Sj（1006）。RCi（1002）进一步暗示OSp（1012）。因此，编译器可以针对RCm（1004）向所生成的规则条件添加“not OSk”，以进一步将其与RCi（1002）区分开。也就是说，OSk（1008）为假意味着RCi（1002）不可能为真。作为进一步的示例，考虑图4的网络，两个交换机接口上的功率故障可以在每一端处引起与针对断裂的链路相同的信号丢失症状。因此，如果将接口功率症状添加到该模型，则反向传播将向对应于cableBreak规则条件的行添加针对每个接口的接口上的功率丢失的假条目。

在一个实施例中，编译器仅报告它无法消除模糊的规则条件对的模糊性作为警告。当这种情况出现时，后续处理可以确定要执行的动作。

自动生成规则集实现方式的益处。自动生成规则集实现方式的第一益处是：它允许实现规则引擎，其中规则条件评估是高效的，这是因为通过将规则条件编译成表或“if…else”语句，从运行时开销中去除了对其他规则条件的前向和后向推理搜索。

自动生成规则集实现方式的第二益处是：它允许反应式规则引擎实现方式，即，其中它通过重新评估依赖于该输入属性的规则条件来对输入属性改变立即做出反应的实现方式。这种反应式方法在快速响应至关重要时很好地工作，并且避免了快速轮询的开销与慢响应时间之间的折衷。

自动生成规则集实现方式的第三益处是：它允许自动检查规则条件的指定不足和过度指定，并且在一些情况下使用反向传播来消除指定不足的规则条件的模糊。该设施减少了维护和扩展复杂规则集的困难。它还教导了如何将规则集完全嵌入在特定于应用的对象模型中，从而进一步帮助复杂规则集的开发和扩展。如从上面的描述可以看出的，对该模型所提供的对象之间关系的详细指定是正确评估规则条件的关键方面。

在与基于表的方法相对的显式代码方法中，存在进一步的益处。特别地，显式代码方法使得在不必重新编译该模型的情况下改变元素之间的关系是可行的。这是修改指示已经被改变的给定关系的（一个或多个）集合的问题。例如，使用网络示例，当在这些接口之间添加新链路时，可以动态地添加新的接口对（Ii、Ij），而无需任何重新编译。

此外，在一些应用中，存储器被保存，因为存在用于评估条件的一个代码实例，而不是RCT中的N个条目，并且不需要“工作存储器”。例如，存在检查线缆断裂的一个代码片段，而不是RCT中的N个条目，对于每对接口（即，对于每个线缆）有一个条目。当存在使用（一个或多个）相同关系的若干个条件时，这种益处被放大。这是因为该关系被存储一次但是被使用多次，而在RCT的情况下，行的数量对应于条件数量乘以该关系中的条目数量。当应用已经存储了相关联的参数和关系时，这种方法特别有吸引力，并且使用这种状态来提取每个相关联场景的参数是可行的。因此，所公开的实施例在一些情况下可能更快并且使用更少的空间。

人们可能认为子条件和子条件蕴涵的指定仅仅是规则条件的分布式指定。在某种程度上，这是对的。然而，所公开的关键方面是在编译期间考虑整个规则集。这允许使对规则条件之间关系的确定和处理为显式的，从而允许针对一致性和模糊性来自动检查规则集。这使得能够确保这些条件是一致的，或者至少允许针对一致性来自动检查这些条件。此外，在模型指定内可能的程度上，可以通过反向传播自动消除规则条件的模糊。

图11是图示了用于自动生成规则集实现方式的过程的实施例的流程图。在一个实施例中，图1的系统实行图11的过程。

在步骤（1102）中，访问规则集。在一个实施例中，规则集被嵌入在指定了元素及其关系（例如包括指定与对象模型中的元素相关联的子条件蕴涵）的对象模型中。

针对规则集中的每个non-const规则，在步骤（1104）中构造一个或多个蕴涵DAG，其中non-const规则直接引起至少一个外部输出或至少一个外部动作；并且一个或多个蕴涵DAG指定规则条件，包括一个或多个可观察规则条件。蕴涵DAG被如此命名，是因为它们表示从规则条件至输入条件/属性的蕴涵，所以因此，每个DAG的叶指示要评估的输入条件，以便评估规则条件。

在一个实施例中，一个或多个蕴涵DAG的构造至少部分地基于一个或多个适用的const规则，例如一个或多个适用的const规则是从non-const规则导出的，或者是在规则集中指定的，和/或一个或多个适用的const规则不生成外部输出或外部动作。

在步骤（1106）中，对针对该规则集构造的蕴涵DAG进行编译以获得编译结果，该编译结果被配置成评估与该规则集相关联的规则条件，并且当规则条件中的至少一个评估为真时确定一个或多个动作。在一个实施例中，对蕴涵DAG进行编译包括执行症状的反向传播以消除模糊性。

在步骤（1108）中，输出编译结果。编译结果可以包括针对其进行匹配以执行规则条件评估的表。编译结果还可以包括显式地评估规则条件的所生成代码，例如依据规则条件中涉及的元素和输入来参数化所生成代码，和/或所生成代码在被执行时对个体输入改变做出反应，以重新评估依赖于输入的一个或多个规则条件。

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

Claims (20)

1.一种用于自动生成规则集实现方式的系统，包括：

处理器；以及

存储器，其与处理器耦合，其中存储器被配置成向处理器提供指令，所述指令在被执行时引起处理器：

从规则库访问基于规则的系统RBS的规则集，其中所述RBS包括所述规则库和RBS推理引擎以至少部分地基于RBS条件匹配和RBS冲突解决而采取动作；

针对所述规则集中的每个non-const规则，构造一个或多个蕴涵有向无环图DAG，其中：

所述non-const规则直接引起至少一个外部输出或至少一个外部动作；并且

所述一个或多个蕴涵DAG指定规则条件，包括一个或多个可观察规则条件；

对针对所述规则集构造的蕴涵DAG进行编译以获得编译结果，所述编译结果被配置成评估与所述规则集相关联的规则条件，并且当规则条件中的至少一个评估为真时确定所述RBS推理引擎的一个或多个动作；

输出所述编译结果；

至少部分地基于所述编译结果执行RBS条件匹配；

至少部分地基于所述RBS条件匹配来创建匹配的动作标签集；以及

至少部分基于所述匹配的动作标签集来应用RBS冲突解决。

2.根据权利要求1所述的系统，其中所述一个或多个蕴涵DAG的构造至少部分地基于一个或多个适用的const规则。

3.根据权利要求1所述的系统，其中所述一个或多个蕴涵DAG的构造至少部分地基于一个或多个适用的const规则，并且其中所述一个或多个适用的const规则是从所述non-const规则中导出的，或者是在所述规则集中指定的。

4.根据权利要求1所述的系统，其中所述一个或多个蕴涵DAG的构造至少部分地基于一个或多个适用的const规则，并且其中所述一个或多个适用的const规则不生成外部输出或外部动作。

5.根据权利要求1所述的系统，其中所述规则集被嵌入在指定了元素及其关系的对象模型中。

6.根据权利要求1所述的系统，其中所述规则集被嵌入在对象模型中，所述对象模型指定了元素及其关系，包括指定与所述对象模型中的元素相关联的子条件蕴涵。

7.根据权利要求1所述的系统，其中所述编译结果包括针对其进行匹配以执行规则条件评估的表。

8.根据权利要求1所述的系统，其中所述编译结果包括显式地评估规则条件的所生成代码。

9.根据权利要求1所述的系统，其中所述编译结果包括显式地评估规则条件的所生成代码，并且其中依据规则条件中涉及的元素和输入来参数化所生成代码。

10.根据权利要求1所述的系统，其中所述编译结果包括显式地评估规则条件的所生成代码，并且其中所生成代码在被执行时对个体输入改变做出反应，以重新评估依赖于所述输入的一个或多个规则条件。

11.根据权利要求1所述的系统，其中对所述蕴涵DAG进行编译包括执行症状的反向传播以消除模糊性。

12.一种自动生成规则集实现方式的方法，包括：

从规则库访问基于规则的系统RBS的规则集，其中所述RBS包括所述规则库和RBS推理引擎以至少部分地基于RBS条件匹配和RBS冲突解决而采取动作；

针对所述规则集中的每个non-const规则，构造一个或多个蕴涵有向无环图DAG，其中：

所述non-const规则直接引起至少一个外部输出或至少一个外部动作；并且

所述一个或多个蕴涵DAG指定规则条件，包括一个或多个可观察规则条件；

对针对所述规则集构造的蕴涵DAG进行编译以获得编译结果，所述编译结果被配置成评估与所述规则集相关联的规则条件，确定所述规则条件中的至少一个评估为真，并且至少部分地基于确定所述规则条件中的至少一个评估为真来确定所述RBS推理引擎的一个或多个动作；以及

输出所述编译结果；

至少部分地基于所述编译结果执行RBS条件匹配；

至少部分地基于所述RBS条件匹配来创建匹配的动作标签集；以及

至少部分基于所述匹配的动作标签集来应用RBS冲突解决。

13.根据权利要求12所述的方法，其中所述一个或多个蕴涵DAG的构造至少部分地基于一个或多个适用的const规则。

14.根据权利要求12所述的方法，其中所述规则集被嵌入在指定了元素及其关系的对象模型中。

15.根据权利要求12所述的方法，其中所述编译结果包括针对其进行匹配以执行规则条件评估的表。

16.根据权利要求12所述的方法，其中所述编译结果包括显式地评估规则条件的所生成代码。

17.根据权利要求12所述的方法，其中所述编译结果包括显式地评估规则条件的所生成代码，并且其中依据规则条件中涉及的元素和输入来参数化所生成代码。

18.根据权利要求12所述的方法，其中所述编译结果包括显式地评估规则条件的所生成代码，并且其中所生成代码在被执行时对个体输入改变做出反应，以重新评估依赖于所述输入的一个或多个规则条件。

19.根据权利要求12所述的方法，其中对所述蕴涵DAG进行编译包括执行症状的反向传播以消除模糊性。

20.一种计算机程序产品，所述计算机程序产品被嵌入在非暂时性计算机可读存储介质中，并且包括用于以下操作的计算机指令：

从规则库访问基于规则的系统RBS()的规则集，其中所述RBS包括所述规则库和RBS推理引擎以至少部分地基于RBS条件匹配和RBS冲突解决而采取动作；

针对所述规则集中的每个non-const规则，构造一个或多个蕴涵有向无环图DAG，其中：

所述non-const规则直接引起至少一个外部输出或至少一个外部动作；并且

所述一个或多个蕴涵DAG指定规则条件，包括一个或多个可观察规则条件；

对针对所述规则集构造的蕴涵DAG进行编译以获得编译结果，所述编译结果被配置成评估与所述规则集相关联的规则条件，确定所述规则条件中的至少一个评估为真，并且至少部分地基于确定所述规则条件中的至少一个评估为真来确定所述RBS推理引擎的一个或多个动作；

输出所述编译结果；

至少部分地基于所述编译结果执行RBS条件匹配；

至少部分地基于所述RBS条件匹配来创建匹配的动作标签集；以及

至少部分基于所述匹配的动作标签集来应用RBS冲突解决。