CN113272743B - 使用有通道结构的动态环境进行基于规则的自动化控制 - Google Patents

Abstract

输入规范，包括：受控系统环境中的多个通道；与多个通道相关联的多个通道操纵；与受控系统相关联的多个通道子条件；以及包括多个规则的规则集，其中，规则集中的规则指定规则条件和当满足该规则条件时要采取的规则行动，其中，该规则条件包括一组对应的通道子条件，并且其中，规则行动包括对应的通道操纵。至少部分地通过以下方式动态地自动导航受控系统：监控多个通道子条件；评估与规则集中的多个规则相关联的规则条件，以确定已满足其对应的规则条件的一个或多个规则；以及执行与一个或多个所确定的规则相对应的一个或多个通道操纵。

Description

使用有通道结构的动态环境进行基于规则的自动化控制

对相关申请的交叉引用。

本申请要求2019年2月19日提交的题为“USING A LANE-STRUCTURED DYNAMICENVIRONMENT FOR RULE-BASED AUTOMATED CONTROL”的美国临时专利申请No.62/807,694的优先权，其通过引用结合于本文中以用于所有目的。

技术领域

本申请涉及基于规则的自动化控制，并且具体地涉及使用有通道结构的(lane-structured)动态环境进行基于规则的自动化控制。

背景技术

动态地自动导航受控系统可以提供许多好处，诸如降低人工费用、增强人身安全、以及改善受控系统的资源效率。受控系统的示例包括控制自驾驶物理车辆、自动股票交易平台或自动医学诊断和治疗应用的行为的系统。

动态环境(诸如车辆的车行道、股票市场和医学患者)为自动导航呈现了巨大的复杂性。目前，设计一种能够有效应对这些复杂性的自动导航器是具有挑战性的。由于计算资源(诸如处理能力、存储器、存储装置和网络资源)的高成本和/或等待时间和/或吞吐量方面的缓慢响应，这些复杂性会引起问题。

发明内容

公开了使用有通道结构的动态环境进行基于规则的自动化控制。传统上基于规则的系统可以被认为适用于动态环境，例如，为自驾驶车辆使用运动规划，但是运动规划包含多个昂贵的操作来处理自驾驶的复杂性。这些昂贵的操作可能会因等待时间或反应的代价而降低安全性，因速度的代价而降低路线导航的效率，或因处理能力、存储器、存储装置和/或网络资源的代价而增加导航电力/能量需求。

公开了使用“通道”的概念来简化动态环境。如本文中所指，通道是受控系统可以在某些条件下通过N维空间、同时遵守非动态约束的离散化定向路径段。通道的示例是道路中的车道，但如下所述，存在对通道工作抽象化的其他环境，包括如下所述的股票市场环境和如下所述的医学应用环境。因此，公开了使用通道将结构施加于动态环境，使得基于规则的系统可以在该环境中有效地自动导航受控系统。在整个本说明书中，出于例示的目的，可以给出自驾驶车辆、股票交易和/或医学领域/应用的示例，但是本文中所述的原理、技术和系统可以毫无限制地推广到其他应用。

附图说明

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

图1是图示了根据一些实施例的用于近似匹配的编程计算机/服务器系统的功能图。

图2是自主车辆应用示例中车道(lane)的图示。

图3A、3B和3C图示了用于股票交易的分层通道(lane)的示例。

图3D图示了用于医学应用的分层通道的示例。

图4是用于自主车辆示例的车道操纵(maneuver)的图示。

图5A是征兆(symptom)的故障场景向量的示例的图示。

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

图5C是已知位和值位的64位块表示的示例的图示。

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

图5E是RCT层级的示例的图示。

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

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

图8A是用于实行自动转换的过程的实施例的图示。

图8B是用于网络示例的DAG集合的图示。

图9是图示了电力示例的实施例的框图。

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

图11是监控系统中反应式规则引擎的实施例的图示。

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

图13A是图示了使用有通道结构的动态环境进行基于规则的自动化控制的过程的实施例的流程图。

图13B是规范(specification)示例的图示。

图13C是图示了动态自动导航的过程的实施例的流程图。

具体实施方式

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

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

图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、Infiniband、ACCESS.bus、无线局域网、HomePNA、光纤、G.hn、红外网络、卫星网络、微波网络、蜂窝网络、虚拟专用网络(“VPN”)、通用串行总线(“USB”)、FireWire、串行ATA、1-Wire、UNI/O，或将同质、异构系统和/或系统组连接在一起的任何形式。附加的大容量存储设备(未示出)也可以通过通信接口(116)连接到处理器(102)。

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

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

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

基于规则的系统是构建自动化控制系统的一种有直观吸引力的方法，因为平常的手动控制方法往往是根据规则指定的。例如，在自驾驶汽车的应用领域内，手动驾驶受包括道路规则和安全驾驶规则在内的规则支配。类似地，在自动股票交易系统中，存在与交易相关联的规则，这些规则是由市场平台本身以及运行交易应用程序的金融机构两者施加的。类似地，对疾病或失调的医学治疗通常遵循一套规定的规则，例如，如果患者已经服用药物Y，则不应该给患者开服用药物X的处方。

在将基于规则的系统(“RBS”)应用于自动化控制时，首先要解决的问题是，手动/人工操作的规则往往是用约束而不是自动化RBS中使用的条件：行动表述(condition:action formulation)陈述的。例如，标准驾驶规则是：不要超过速度限制。这条规则并没有指示车辆应该行进的速度，而是留给人类驾驶员判断。该示例从陈述车辆速度始终小于或等于速度限制的意义上来说是约束。约束在本文中被称为系统应该努力实现的陈述和/或条件。对于自动化系统，规则需要提供这种判断。也就是说，在引起系统响应于规则的条件变为真以触发实现该约束的行动的条件：行动格式(condition:action format)中需要存在规则。

在简单的表述(formulation)中，基本规则可以容易地表述为：

然而，在现实中，减速的条件要复杂得多，包括在车辆前行方向上突然出现的动态障碍物的潜在存在、前方交通灯、进入相对急转弯等等。车辆何时应该减速的现实条件可能非常复杂且难以搞清楚。

在股票交易应用中也会出现类似的复杂情况。初始规则可以是：不允许投资组合(portfolio)在单一股票中具有多于其价值的X％的价值。然而，实现这一点的条件：行动规则可能更复杂。特别地，增加股票仓位或选择购买数额的规则可能需要避免让数额超过投资组合价值的此X％。然而，如果一只股票的价值显著上升、或投资组合中其余部分的价值显著下降，则有可能再次超过此X％阈值，并且需要纠正措施。确切的行动可能取决于各种因素，包括这些场景中的哪一个正在引起对此约束的关注。作为澄清的说明，术语“工具(vehicle)”在投资上下文中用来将特定投资类别表示为“投资工具”。

另一个挑战是，动态环境/应用中的行动不是瞬时动作，而是可能需要在一段时间内发生，在此期间条件可能会改变。例如，在医学应用中，触发让患者开始服用特定药物的行动不会立即产生结果。此外，即使在发起这种治疗之后，患者的病情也可能会突然改变，从而要求不同的治疗计划。如本文中所指，“突然地”意指相对于所选治疗产生效果所需的时间。因此，规则集可能会因需要考虑已发起某一行为但尚未完成的行动而进一步复杂化。

RBS的另一个挑战是，这些应用可能需要采取无限数量的行动，并且因此需要评估无限数量的条件来选择这些行动，和/或这些条件可能正在迅速地且不可预测地改变着。例如，在有许多其他独立控制的车辆的环境中操作的自驾驶车辆必须实现不与这些其他车辆碰撞的约束，即使它无法预测这些其他车辆的行为。类似地，在自动化股票交易系统中，股票本身的价格可能会在控制系统的控制之外发生显著变化。

控制系统可以实现响应于这些动态改变的行动，以尝试维持为控制系统指定的约束。一个挑战是，当可能存在可能出现的无限数量的动态场景，并且因此在控制逻辑中要考虑无限数量的情况时，为这种控制指定正确、高效且可靠的逻辑。由于在许多情况下可能不会立即实行行动，因此在执行行动期间，环境可能会进一步改变的这一事实使该挑战更加复杂。

往往存在一个基于环境知识的顶层计划的基础，在本文中和导航上下文中被称为“路线引导”。例如，自主车辆(“AV”)可以使用基于例如GPS(“全球定位系统”)的常规车辆导航器技术来生成遵循到目的地的道路和交叉口的合理顺序的计划。在金融环境中，自动化交易平台可以通过股票市场导航投资组合。股票市场本身就是随着时间推移而动态改变的股票集合。在医学环境中，医学治疗计划可以导引(navigate)患者恢复健康。

本质上，路线引导模块产生一系列与关键道路和交叉口处的行动相对应的路点(waypoint)。类似地，基于市盈率、不同指数、交易策略等等，可能会有针对自动股票交易的顶层计划，其中至少在日间交易应用程序中，路点是早上开盘到一天结束时收盘。

然而，这种类型的顶层计划并不一定考虑可能在路点之间发生的环境的具体动态方面。例如，进入要左转的交叉口的自主车辆需要在该交叉口前切换到左转车道，并且然后在遵守车辆必须避免与其他车辆和障碍物碰撞的约束的同时通过该转弯，即使它在执行该计划时并不能准确预测其他车辆和动态障碍物可以做什么。类似地，可能存在股票市场改变，诸如利率改变，这些改变可能无法预测，并且可能要求快速反应加约束，诸如在特定工业部门中不要变得超配。如本文中所指，这种形式的导航是“动态导航”，因为它考虑了环境中的动态元素。

自主驾驶中的传统方法聚焦于通过生成短期计划(有时称为“运动规划”)实现动态导航，以从一个路点导航到另一个路点，同时服从约束、考虑这些约束和环境中的动态条件。然后，控制系统必须时时刻刻地实现控制以遵循该短期计划。也就是说，将确定符合所有约束的路径的复杂任务和用于执行该短期计划的控制机制模块化地分离。

使用这种运动规划/短期规划方法的问题在于，可能会意外地出现使当前计划不可行的新的动态条件。例如，短期计划可能是让自主车辆针对接下来的500米直行，换到左转车道，并且然后在交叉口处左转。然而，可能会从自主车辆前面的车辆上掉落箱子，突然给车辆产生新的意想不到的障碍，使得该计划不可接受，因为它未能避免细心的人类驾驶员可以避免的事故，即通过绕着箱子转向来避免。在这种性质的意外事件点，由于其依赖于短期计划，系统可能无法做出反应，直到生成新的短期计划为止。作为股票交易领域中的示例，炼油厂的爆炸可能会改变某些相关投资的前景，从而需要对投资组合进行快速但无计划的改变。

一种方法是，生成多个短期计划，使得系统可以在发生意料之外的事件时切换到另一个短期计划。然而，考虑到使当前短期计划无效的动态事件，重新评估这些替换的短期计划相对于新场景是否仍然有效可能仍存在延迟。此外，一般而言，具有足够的替换短期计划以便总有一个可接受的替换方案是不可行的，因此系统仍有可能最终没有针对新场景要遵循的短期计划，并且因此对动态事件做出反应存在显著延迟。换句话说，短期规划可能对像国际象棋游戏这样的静态抽象环境有意义，但在现实世界中并不允许快速响应。

生成短期计划的成本很高，因为它需要通过其他对象的集合进行运动规划，其中一些对象也是动态的，例如，运动中的对象。在这里，运动规划可以被视为定义通过N维空间的路径，使得沿路径对工具的所有约束都得到满足。对于处于运动中且与这些约束相关的其他对象，还有必要预测它们随时间推移的行为，以验证该计划在稍后的时间t与每个对象在该时间t的方位而不仅仅是其当前方位没有冲突。这种预测增加了费用，但是也必然增加了它的不确定性，有可能出错，进一步提高了计划因一些不可预测的行为或事件而最终不可行的可能性。例如，在该车辆前方左车道上的车辆可能突然减速，从而使另一车辆成为该车辆按计划改变车道的障碍。本质上，动态环境中的短期规划方法会导致生成和重新生成这些计划的显著开销，然后在选择当前计划之后导致在对使当前计划无效的动态事件做出反应的糟糕的最坏情况的等待时间，尤其是当一个或多个动态事件使所有预先计算的计划无效时。

除了这些挑战之外，由于执行基于规则的系统效率低下，而且规则在被扩展以处理现实场景时难以管理的复杂性，RBS的传统使用一直在挣扎。

公开了一种在不引发生成短期计划或行动过程的开销的情况下对动态改变的环境做出快速反应的技术。实现该技术的实施例包括：自导航车辆、自动股票交易平台、医学治疗或在动态环境中进行控制或识别的其他应用。如本文中所指，术语“自动化动态导航”被定义为确定并维持到目标位置的路线或轨迹的过程。该轨迹可能出现在广义的N维空间中，并且“确定”步骤包括导航通过该空间的与施加在受控系统上的约束相符合的路径。

公开了使用基于规则的系统在动态有“通道”结构的环境中为受控系统(或如本文中所指的“工具”)实现自动动态导航的控制系统，在该基于规则的系统中，所触发的行动是动态地选择和执行“通道操纵”以实现这一导航。也就是说，导航是通过执行新的通道操纵并响应于规则触发而中断现有通道操纵来实现的，其中规则条件响应于环境和工具的改变。

如本文中所指，“通道操纵”是随时间推移实行的相对于通道控制工具的行动。例如，简单的操纵是在当前车道的中心维持车辆的速度。在一个实施例中，操纵是在行动时间期间实行的与环境的动态改变无关的行动。例如，对于自主车辆而言，将车道换成右相邻车道是一种操纵。

通道。通道是受控工具可以在某些条件下通过其所在的N维空间从通道起始到通道结束、同时遵守非动态约束的离散化定向路径段。例如，自驾驶汽车应用中的物理道路被离散化或划分为物理车道或路径段，每个都足够宽且足够平滑以供车辆通过。例如，在美国的双车道道路上，除了在超车时，期望车辆待在右侧车道。毫无限制地且如下详述的，通道是一个抽象概念，其可以应用于自主车辆应用中的物理车道，但是也可以应用于比如股票交易和医学应用的其他动态环境。

通道将结构施加于要导航的环境或空间。也就是说，车辆被约束成在一条车道上行驶或切换到另一条车道，并且然后在那条车道上行驶，而不是能够在任何地方行驶。例如，在六车道划分的高速公路上，车辆要么在最右边的车道、中间的车道上行驶，要么在最左边的车道上行驶，除非它正在换车道。因此，通道概念减少了短期内的行动选择。例如，车辆可以在当前车道上行进，也可以切换到另一条车道上行进。作为旁注，可以有可能指定其中工具不可能从一个目的地到达另一个目的地的有通道结构的环境，但这样做并没有用。

通道结构化限制了工具必须导航的选择。例如，在自驾驶汽车的情况下，车辆可能必须相对于车道进行导航，例如，沿着当前车道、切换到相邻车道、或在交叉口处转入另一条道路上的车道。

通道限制可以意味着一些原本可以执行的导航计划可能不会被考虑或支持。例如，如果道路被完全堵塞，那么车辆在物理上有可能会“路外(off-road)”行驶，并且仍然可以在不受约束的导航中到达目的地。然而，对于有通道结构的导航，除非在堵塞周围设置通道，否则工具会被迫停下来，并且在没有人工干预的情况下可能无法到达目的地。

通道结构化也可以意味着工具动态导航也可能假设其他工具也使用有通道结构的导航。例如，车辆控制可以假设正在接近的车辆可以保持在它所在的车道上，并且不会突然偏离到当前车辆的车道中。通过做出这个假设，车道可以允许一些原本不可行的驾驶。例如，考虑约束：车辆与在距离D处的另一车辆的接近速度V不应该超过车辆在行进D的时间内减速V的能力。此约束仅限于与当前车辆处于同一车道上的其他车辆。这种对基于车道的行为的限制正是允许驾驶员假设在相邻车道上有快速接近的车辆时，继续在当前车道上行驶是安全的内容。

通道限制对于安全导航至关重要，因为在不依赖于通道和相关联的工具行为的情况下处理许多常见场景在物理上是不可能的。例如，在双车道道路上迎面而来的车辆通常在自己的车道上以比方说每小时65英里的速度行进。如果这辆迎面而来的车辆突然偏离其车道，考虑到高的接近速度，受控车辆在物理上不可能避免碰撞。在没有车道的情况下，如果迎面而来的车辆可以随时选择导航到道路上的任何地方，那么车辆就不能以任何显著的速度行进。类似地，如果一辆本应停放的汽车突然驶入其车道，则经过所停放汽车的车辆在物理上无法避免碰撞。

在使用高清(HD)地图进行道路上车辆导航的情况下，车辆可在该区域中行驶之前获得车道信息。然后车辆需要实行定位以维持该车辆在HD地图上的位置。存在现有技术使用GPS、航位推算和视觉或其他车道标记指示来实现具有高准确度的车辆定位。

图2是自主车辆应用示例中的车道的图示。地图(202)图示了具有位置目标(206)的自主车辆(AV，204)。顶层计划(208)的示例包括：在驶入或驶离各种高速公路、道路和过渡道路(比如入口匝道和出口匝道)时的一系列路点。沿着该计划，自主车辆(204)在具有两个相邻车道(214)、(216)的当前车道(210)上行进。

其他领域/应用中的通道。在股票交易领域中，存在基于将股票分类为不同行业部门的通道。通常，其他市场参与者不会突然将所有投资转向另一组随机股票。代替地，已知某些动态事件(诸如炼油厂爆炸、利率改变和其他示例)会影响特定的“通道”或行业部门。因此，投资组合可以通过意识到每个事件仅影响一个或多个投资通道以及与那些(一个或多个)通道相关联的约束来对动态事件做出反应。例如，炼油厂大爆炸可能会对经营炼油厂的公司造成负面影响，但是会使炼油厂“通道”中的其他公司受益，并且对高度依赖于石油的其他公司(诸如运输“通道”中的公司)造成负面影响。

与自导航车辆情况不同，自动股票交易应用可能具有分层“通道”，顶端层级的消费者产品、中层层级的干货部门(dry goods sector)以及下层层级的特定股票/公司。也可能具有对应于同时有效地控制多个工具/子工具、遵守这些工具之间的约束(诸如避免跨投资主题的每一个“通道”在过多作为成长期公司的公司中太久)的多个投资主题。

图3A、3B和3C图示了针对股票交易的分层通道的示例。在图3A中，工具/app(302)当前处于“技术服务”顶端层级通道(304)中，该通道与“电子技术”顶端层级通道(306)和“健康技术”顶端层级通道(308)相邻。换句话说，工具/app可以从通道304移动到相邻通道，诸如通道(306)/(308)。在图3B中，工具/app(302)当前处于“技术服务”顶端层级通道中的“云扇区”中层级通道(314)中。“云扇区”中层级通道314与“流式传输”中层级通道(316)和“操作系统”中层级通道(318)相邻。在图3C中，工具/app(302)当前处于“技术服务”顶端层级通道中的“云扇区”中层级通道中的“GOOG”下层层级通道(324)中。通道(324)与“AMZN”下层层级通道(326)和“MSFT”下层层级通道(328)相邻。

在这种情况下，股票交易可以被视为同时导航多个投资工具/子工具，其中这些工具之间具有约束，遵守这些工具间的约束以及环境和每一个工具之间的约束。

图3D图示了用于医学应用的分层通道的示例。工具/app(352)当前处于“阿司匹林治疗方案”通道(354)中，该通道与两个“无治疗方案”通道(356)、(358)相邻，指示患者在开始新的治疗方案之前停止旧治疗方案所花费的时间。一个“无治疗方案”通道(356)与指示一种可能的新治疗的“芬太尼治疗方案”通道(360)相邻，其中另一个“无治疗方案”通道(358)与“心脏外科治疗方案”通道(362)相邻。毫无限制地，图3A、3B、3C和4的图示旨在通过二维显示通道(比如物理车行道)与图2的自主车辆应用相提并论。通过在两个以上的维度中构思，相同的原理可以推广到例如三维通道集，其中“无治疗方案”通道(356)、(358)是相同的通道，而其他治疗方案(354)、(360)、(362)等都与“无治疗方案”相邻。毫无限制地，N维空间可以用于其他应用。

通用通道视图。在最一般的表述中，通道通常是“工具”正在行进的N维空间中的受约束定向路径，在没有动态障碍物的情况下，该路径足以让工具从一端行进到另一端而不违反工具约束(包括静态工具约束)。通道可能具有某些动态和静态特性和行为。例如，与医学应用中的特定患者治疗计划相对应的通道可能涉及特定的副作用，并且可能具有应用时间界限。导航涉及跟随当前通道以及视情况不时地切换到不同的通道，以实现期望的目标，诸如治愈患者。不允许工具(即本医学应用示例中的患者)从其当前通道换成任意其他通道。代替地，只允许它切换到与当前通道相邻的通道。

“邻接(adjacency)”的概念是用应用特定的术语和约束定义的。特别地，当受一些动态条件的影响执行从L0到L1的通道操纵是可行的时，通道L0与另一个通道L1相邻。例如，参考图3D，正在接受芬太尼治疗并因此在通道(360)中的患者可能不会在不经过“无治疗”通道(356)的情况下直接从该通道或治疗切换到阿司匹林治疗通道(354)。这是必需的，因为如果患者在开始服用阿司匹林时其系统内具有一些芬太尼，药物之间可能存在不良的相互作用。此外，患者只有在其症状(symptom)稳定的情况下才允许从芬太尼通道切换。通道间邻接的指定是有通道结构的环境的一部分。

通道操纵。“通道操纵”在本文中被称为就一个或多个通道而言发生的行动。例如，“换成右通道”是将车辆从当前通道换成右侧相邻通道的操纵。因此，如上所述，“相邻通道”在本文中被称为利用通道操纵可从当前通道到达的通道，类似于驾驶中的物理二维车道。从这个意义上说，通道及其邻接用于使环境离散化，因此操纵数量也方便地是有限的和可实现的。例如，将通道换成相邻通道是少数操纵之一，并且实现也很简单。

在许多情况下，操纵可以是相对于通道的静态、预先计算的解决方案。例如，“换道”操纵是静态的，其中车道是标准宽度——可以使用简化和标准的运动计划，可能通过车辆的速度参数化。此外，操纵不必考虑动态事件或障碍物。因此，当选择新的操纵时，自主车辆可以采取瞬时行动来实行所选操纵，而不必动态地生成操纵序列或程序。

图4是用于自主车辆示例的车道操纵的图示。一般而言，受控系统可以实行的行动通常是有限数量的，尤其是当行动由参数限定时。例如，工厂机器人可以向前伸、举起、放下等等。类似地，如图4所示，车辆(402)可以减速(410)、加速(408)、向左换道(412)、向右换道(414)、实行左转(416)、实行右转(418)等等。这些行动是一组有界行动，可能通过速度、道路状况等等参数化。因此，可以在控制软件中预设和/或用硬件(例如，硬连线)实现操纵，并且因此以快速响应实行操纵。

通道结构化可以用来显著地减少在任何给定时间要考虑的行动数量。例如，考虑从A点延伸到B点的平坦平原。在没有任何车道的情况下，A和B之间有无限数量的潜在路径可供选择。在A点和B点之间的每个方向上有一条车道的情况下，减少行动以待在行驶车道上(减速、加速或维持速度)、换到另外的车道以超车，以及超车后换回行驶车道。

在医学上下文中，存在有限数量的通道操纵，因为在治疗中存在已知安全的既定序列。例如，医生绝不应该给一个人开治疗计划突然改变的处方，因为不知道要做的改变是安全的。在股票交易领域中，存在有限数量的待实行的行动或操纵，诸如市场抛售、止损等等。此外，要求有10％的资产用于高科技大盘股增长的股票投资组合不能用任意的其他股票来替换投资组合中的一只这样的股票。代替地，例如参考图3C，如果投资组合持有大量AMZN(326)，则只能用GOOG(324)或NFLX(330)来替换该股票，因为这些股票与AMZN(326)相邻。如前所述，这一邻接示例用二维例示。实际上，可以存在许多与AMZN相邻的不同股票，在N维空间中很容易处理它们。

允许车辆或机器人在其中导航是完全可能的每个可能场景中导航的操纵并不是绝对必要的；人类驾驶员也不能。例如，考虑静态障碍物和以某种快速模式移动通过交叉口或类似地方的动态对象的之字形集合。从理论上讲，可以有可能安全地导航通过该交叉口，但是很少有人能够应对这种情况。该情况非常不寻常，因此考虑到能够在感兴趣的实际现实世界场景中安全驾驶的经济价值，无法自动处理将是可以接受的。

因此，存在一组基本通道操纵，例如，在自主车辆的上下文中：维持在当前车道上的速度、减速、加速、换成右车道、换成左车道、右转、左转等等。这些操纵可以细化为更具体的操纵。例如，减速可以细化为：紧急制动、大力制动、逐渐制动和减速/切断油门。通道结构暗示着相对较小的基本操纵集，其可以细化为较大的更复杂的集合。

相比之下，在没有通道结构的情况下，存在无限数量的可能行动。此外，条件的数量至少是行动的数量，因此规则条件的数量也是过多的，除非行动/操纵的数量受到严格限制。特别地，在没有通道的情况下，要么导致无限数量的行动，诸如“向右移动1英寸”、“向右移动2英尺”、“向右移动3码”等等，要么在没有限制或没有有意义的限制的情况下，对行动进行参数化。例如，如果行动是向右移动X英尺，那么非常大的值可能与小的值具有不同的实现，因此本身很难实现。相比之下，在有车道的情况下，向右换道被用于小的移动，但要向右行驶一段显著的距离，车辆向右转，并且然后沿着向右行驶的车道行驶，并且然后可以向左转以继续前行。

在一个实施例中，通道操纵被实现为“可抢占的(preemptable)”，如本文中所指，是即使正在执行另一个操纵，也可以立即触发新的操纵的情况。考虑到基于先前操纵的车辆中间状态，新的操纵能够接管并执行其操纵。例如，可能先前触发了换到超车车道并加速的操纵，但是在该行动完成之前，检测到动态障碍物，其会触发减速和返回行驶车道的操纵。该操纵识别车辆相对于行驶车道的当前方位，并且基于车辆相对于行驶车道的偏移调整其转向行动。特别地，如果车辆在触发此新操纵时仅稍微偏离行驶车道，则转向行动可能不需要像车辆已经完全处于超车车道时那么激进。

通道子条件。“通道子条件”在本文中被称为指示一个或多个通道相对于该工具或其他对象的状态的输入。例如，hasRightLaneClear是子条件，如果相对于该车辆的右车道没有障碍物，则该子条件为真。它是车道子条件，因为它与车道的状态有关。

正如通道结构减少了通道操纵的数量，它也减少了所需通道子条件的数量。这是因为作为通道操纵，行动仅与通道有关，所以只考虑与通道有关的子条件是可接受的。也就是说，如果唯一的行动选择是通道操纵之一，那么如果按照通道子条件来表达，则用于选择通道操纵的条件应该是充分的。在有通道的情况下，感兴趣的条件被降至应该触发这些行动中的每一个的条件。例如，在当前行驶车道上减速的行动具有少量子条件，这些子条件与当前行驶车道和可能的相邻车道的状态、以及车辆在当前车道中的当前方位有关。

车道子条件往往更容易从车辆上的传感器确定，因为大多数或所有相关子条件都与当前车道或相邻车道相关联，并且与车辆有关。例如，hasRightLaneClear子条件与车辆有关，并且可以由车辆上的传感器——包括车辆右手边上的相机、微波、雷达和激光雷达——感测。车道子条件也是受控车辆的局部条件，使其更易于准确感测。

通道结构还允许排除可能引起假阳性反应的子条件。例如，在没有车道的情况下，每当有对象与该车辆具有高的接近速度时，车辆可能就想要感测。在有车道的情况下，在稍微弯曲的双车道高速公路上，对向车道上迎面而来的车辆可能看起来具有这样高的接近速度：利用车道结构，车辆可以识别对向车道上有迎面而来的车辆，并且仅使用此子条件来阻止在对向车道上超车，而不是以其他方式对其做出反应。

有可能假设车道子条件不充分的场景。例如，岩石可能会从邻近道路的高悬崖上掉下来，直接掉到车辆上。在具有由航空传感器击退的附加子条件的情况下，有可能避免这种碰撞。然而，这些都是极端和不寻常的情况，它们超出了人类/人工驾驶员通常可以处理的范围。虽然如此，扩展车辆上的传感器以检测车道上方相关的子条件，并且因此将这些子条件视为附加车道子条件可能是可行的，如本极端示例中所需要的那样。

利用环境的通道结构化，RBS导航通过使作为车道子条件的规则条件触发作为通道操纵的规则行动来实现。例如，在自驾驶汽车的应用中，一个子条件可以是当前车道在前方受阻。另外两个子条件可以是相邻的左车道和相邻的右车道空闲。最后一个子条件可以是右转即将来临。在这组子条件的情况下，车辆选择切换到右车道而不是制动或切换到左车道的操纵是合理的。也就是说，上述规则可以被实现为：

请注意，此规则不需要leftLaneClear的子条件，并且因此它不包括在车道子条件中。

一般而言，有通道结构的环境会导致要考虑的一组相对有界的操纵和一组相对有界的子条件，因此规则集具有对于设计、验证和执行而言合理的大小。

路线引导。为了将路线引导并入该规则结构中，路线引导输入可以被视为基于车辆方位改变的动态事件/输入。例如，当自主车辆沿着高速公路的车道行进时，它可以动态地进入高速公路的一部分，在该部分中，路线引导确定它靠近根据路线引导需要走的右侧出口。常规的车辆导航系统将生成比方说0.5英里后有出口的指示。

在一个实施例中，存在对应于“右出口不到0.5英里”的所定义的子条件值，可以基于来自路线引导系统的信息在那一刻将其设置为输入。对于“右出口不到0.1英里”和其他距离，可以有类似的子条件值。

通过使规则由外部对象子条件以及这些路线引导子条件两者触发，可以对车辆进行导航以避开障碍物，以及通过相同的机制朝期望的目的地导航。特别地，在子条件“右出口不到0.5英里”被设置为真的情况下，规则可以触发换成最右边的车道，如果其他子条件指示切换到该车道是安全的话。类似地，当右车道通向高速公路出口时，可以设置引起沿着高速公路出口车道的操纵的子条件。以这种方式，车辆动态改变的方位触发来自路线引导系统的子条件，这些子条件触发在没有干扰障碍物的情况下实现车辆到目的地的期望导航的操纵。

动态事件有可能使得车辆不遵循路线引导。例如，右车道上车辆严重拥堵可能会使得及时到达即将到来的出口不可行。在这种情况下，车辆会导航经过该出口。然后，路线引导系统重新计算要走的路线，这与人类驾驶员未能执行路线引导所提供的路线时可能出现的情况相同。

开发有通道结构的规则集。开发有通道结构的导航规则集的第一步骤是定义工具可以执行的通道操纵词汇。这些操纵可以相当简单，诸如维持当前车道、换成右车道、换成左车道等等。与该第一步骤无关，请注意，在车辆控制系统中有一项单独的任务来实现每个操纵。这项任务涉及可能使用传统技术实现每个操纵的程序。

第二步骤是为每个通道操纵确定应该触发该操纵的条件。每个这样的条件可以被表达为就车道子条件而言的布尔表达式，这些车道子条件被细化到可观察的子条件。例如，重复先前的示例，将换成右车道的条件表达为车道子条件的合取(conjunction)：

其中，laneIsBlocked和rightLaneClear子条件由车辆传感器系统确定，而rightTurnImminent子条件在某种意义上由路线引导系统基于来自车辆定位系统的输入和该区域的静态地图感知。请注意，“rightTurnImminent”被认为是车道子条件，因为它基于车辆在车道上的定位，即它所在的位置，加上路线引导。进一步注意，需要定义车道结构化模型，其包括可能的邻接以及这些车道子条件。例如，上述示例假设相邻车道可以被一般地和完全地指定为“右车道”和“左车道”。

与车道操纵类似，车道子条件可以从基本子条件细化到更复杂的具体车道子条件，使得车道子条件足以表达触发每个细化操纵的规则条件。例如，规则集设计者可以意识到“changeToRightLane”过于笼统，并不足以进行安全驾驶。例如，在非常接近的车辆前面存在突然堵塞的情况可能要求诸如“swerveToRightLane”之类的紧急操纵，而仅仅为了准备进行右转而改变车道可能没有这样的紧迫性。因此，“laneIsBlocked”可以细化为诸如“imminentUnknownLaneBlockage”、“vehicleInFrontSlowing”和“vehicleInFrontBraking”之类的子条件。

相反地，规则集设计者可以从当非常接近的车辆前面存在突然堵塞时要求紧急停止的规则开始。细化是要意识到，如果右车道畅通，则可能优选的是转向右车道。因此，规则集设计者可以添加“swerveToRightLane”和“swerveToLeftLane”操纵，然后基于右车道或左车道是否畅通来细化这些操纵之间的现有规则条件。一般而言，为了解决不同的驾驶情况而对车道操纵的细化要求对车道子条件进行细化，以允许正确表达这些操纵的规则。

三元故障场景表示概述和实施例。在一个实施例中，该规则集被表达为按照使用三元故障场景表示指示的那样嵌入到对象模型中。三元故障场景表示的例示性应用是自动根本原因分析(ARCA)。“征兆”在本文中被称为监控系统的某个组件的指定和/或定义状态，这对于区分一个故障场景与另一个故障场景是重要的。在一个实施例中，对应于“未知”值的征兆值对应于未知的征兆值和“无关(don't care)”值，“无关”值也被称为与使用特定分析并不需要的征兆相对应的不相干值。

在一个实施例中，每个征兆值被限制为以下各项之一：真、假或未知。因此，征兆值在本文中被称为“三元”值。在一个实施例中，未知值和“无关”值由相同的值指定，基于使用的上下文而被区分为一个或另一个。例如，对于自主车辆应用，“vehicleInFrontSlowing”子条件在自主车辆处于雾天的情况下可以是未知，或者“vehicleInFrontSlowing”子条件在自主车辆通过倒车平行停车的情况下可以是“无关”。

自动根本原因分析(ARCA)概述。复杂的监控系统可能具有众多故障源，并且甚至用于监控这样的系统的机制也易遭受故障的影响。例如，监控制冷系统的温度传感器可能永久或间歇性有故障，指示受监控系统的温度不正确。

组件依赖性可以引入另外的复杂性，例如，制冷系统中的冷却盘管取决于压缩机的正确运行来提供冷凝制冷剂。这些依赖性源于这些组件的互连。如上所述，一个组件的故障可以导致另一个指示故障状况/征兆。因此，当一个组件有故障时，它可以导致依赖于该故障组件的组件中的连锁故障，从而使确定实际根本原因故障的任务变得困难。在一些情况下，向操作员提供的警报当中甚至可能不存在根本原因。

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

传统上，这些额外的警报被称为根本原因故障的征兆。生成大量这些征兆作为警报使得确定实际根本原因更加困难。

通过使用征兆的高效匹配而不需要使用故障或不切实际/昂贵的大训练数据集之间的统计相关性，描述了一种对操作原理、依赖性和因果关系、以及由工程设计导致的为工程系统所知的潜在根本原因进行编码的高效方法。这种效率减少了存储成本和/或降低了处理器的功耗，以便确定根本原因分析。这种高效方法允许自动且高效地实行根本原因分析。

征兆和故障场景。图5A是征兆的故障场景向量的示例的图示。征兆(noPower)的一个示例是指示没有电力进入监控系统的征兆。征兆的状态可以是已知值、或者是未知和/或“无关”的特殊指示。术语“无关”通常用于数字逻辑，以指示关联项是不相干的/不需要的。对于针对给定征兆指示“无关”的处理能力允许分析继续进行，即使在系统状态的该方面实际上未知的情况下。

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

如图5A所示，在一个实施例中，故障场景被表示为值数组(502)，其中每个条目(504a-m)对应于指定的征兆。例如，征兆Sy0(504a)是第一条目，征兆Sy1(504b)是第二条目，依此类推。在一个实施例中，可以存在与同一度量相关联的多个征兆。例如，温度传感器可以有略高、中高和极高的不同征兆。在一个实施例中，可以存在与基于不同导数水平的同一度量相关联的征兆。例如，征兆可能与具有一阶导数太长时间为零的度量相关联，也就是说，该度量是常数，往往指示输入传感器有故障。征兆可能与一阶导数过高相关联，这意味着它改变得过快。

可能存在与度量相关联的附加征兆，其指示度量超出范围或表现不当。在这种情况下，例如，超出范围的征兆被同时设置为指示度量过高或过低的征兆。征兆的这种“聚合”形式可以允许就“超出范围”而言，而不是必须同时覆盖“过低”和“过高”来指定故障场景。

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

bool isMatching＝match(s0，s1)；

如果s0中的每个征兆条目都是“无关”，或者与s1中对应条目中的值匹配。请注意，匹配操作是不可换的；match(a，b)可能不一定等于match(b，a)。

根本原因表格。图5B是示例根本原因表格(RCT)的图示。RCT是表格，其中每一行是标记有相关联的根本原因的故障场景。在本上下文中，在这样的故障场景中，征兆的未知值被解释为“无关”。例如，对于根本原因“前方障碍物”，该行中的征兆可能是：VehicleInFront为真、movingForward为真、以及所有其他征兆被指示为“无关”。

在一个实施例中，对于可能是根本原因的每个故障或事件，RCT包含一行，其中每一行指示必须为真才能成为根本原因的征兆，必须为假的征兆，并且其余的被设置为指示“无关”。请注意，对于给定的根本原因，将更多征兆指定为具体值，而不是超出绝对最小的“无关”，可能导致无法识别或匹配根本原因，因为额外的征兆可能未知，或与为该行指定的征兆相反。因此，重要的是指定将系统诊断为与表格中的行相关联的特定根本原因所需的最小已知征兆集。如果给定的根本原因可以具有多个识别征兆集，则RCT中有多个行，如每个集合一行。给定的根本原因可能具有多个对应的行，因为一个行对应于最小征兆集，而其他行对应于带有附加征兆的最小集，这些附加征兆提供对根本原因的更大信任。例如，在交换机电源故障的情况下，最小集可以仅包含来自交换机的电流传感器的“lossOfPower”征兆，而附加的行可以包含该征兆加上来自直接附连到故障交换机的交换机的“lossOfSignal”征兆。

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

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

如上所述，使用三元征兆值，使得将征兆表示为“已知”位，分别以真或假指示已知或未知，以及指示真或假的第二“值”位，仅当已知位被设置为真时才将其解释为这样。使用[a，b]的四元命名法，再次使得对[0，1]的允许解释是不知道相关联的征兆为真。因此，可能对应于未知的[0，0]与可能被解释为不知道为真的[0，1]不同。请注意，与[0，0]不同的是，RCT(522)中的条目中的[0，1]征兆可能与假或未知的输入匹配，其只是不匹配为真。再一次，[0，1]可能不一定被视为与[0，0]相同和/或不被允许。

二元、三元和四元表示。在一个实施例中，值具有三个或更多个状态，包括“真”、“假”和“无关”的值。在一个实施例中，使用三元子条件值，使得将子条件表示为“已知”位，从而分别以位值为真或假来指示已知或未知，以及指示真或假的第二“值”位，仅当“已知”位被设置为真时才将其解释为这样。使用两个位来表示三元值的四元表示在本文中被称为[a，b]，其中，a是状态是否已知(0＝未知，1＝已知)，而b是与状态相关联的值(0＝假，1＝真)。利用这个约定，对[0，1]的允许解释是相关联的子条件“不知道为真”。将可能对应于未知状态的[0，0]与可能被解释为“不知道为真”的[0，1]进行比较(替换约定可以是[0，0]为“不知道为假”)。完成这些可能性，[1，0]可以对应于“假”，并且[1，1]可以对应于“真”。请注意，[0，1]子条件可以与为假或未知的输入匹配，并且与[0，0]不同，[0，1]不与任何为真的输入相匹配。因此，[0，1]可能不一定被视为与[0，0]相同，和/或在内部和/或一致表示中可能不被允许。

在一个实施例中，值具有两种状态，这两种状态允许表格中不同列的不同匹配行为。对于具有二元状态的值，在许多应用中，对象具有征兆，否则客户端“无关”，例如，表示isOverheating的对象(即，机组是否过热)。对于isOverheating的“真”指示特定问题的征兆，但是可能有许多根本原因与机组是否过热无关，并且因此是“无关”的。意识到这一点，替换的方法是，每个条目具有对应于“真”和“无关”的两个值，而不是三个值。对应的匹配运算符输出表格为：

这将每个条目所需的位数从三元表示的两个位减少到二元表示的一个位，因此存储器的开销只有一半。

存在以下情况，在该情况中有必要在都具有征兆S1的实体上以及在不具有征兆的单独的规则/根本原因中进行匹配，诸如S1为假。对于这种情况，可以显式地引入与S1的否定相对应的额外征兆S2，例如，征兆S1可以是lossOfPower，而S2可以是hasPower。然后，需要lossOfPower的行可以具有征兆S1被设置为“真”并且S2被设置为“无关”的对应表格条目。相反地，需要hasPower的行可以具有S2被设置为“真”并且S1条目被设置为“无关”的该对应表格条目。因此，如果例如10％的征兆需要否定，那么1位方法在空间上将仍然比2位方法便宜，也就是说，多出额外10％的空间而非100％。

在一个实施例中，S1和S2两者都为真的组合可以对应于“未知”。也就是说，如果输入设置了S1和S2两者，则征兆被视为“未知”。在应用中，将状态表示为“未知”可能比对第四值的“不知道为真”的解释更加有用。不存在对于针对这种“未知”支持的上述匹配要起作用的改变或扩展。行中的S1和S2条目都指定为真，并且输入也将这些条目指定为真，因此其匹配“未知”。

还有一些征兆实际上是值的离散枚举，诸如非常冷、冷、凉爽、正常、温暖、热和非常热。在正常的二元表示中，这七个值可以用三个位来表示。然而，利用上述“真”/“无关”二元方法，肯定和否定将需要六个征兆作为每一位的单独征兆。特别地，上述7个枚举可以使用常规布尔表示用3位表示，例如，001可以标明“非常冷”。然而，由于真/无关实施例没有显式地处理假，所以需要另一个3位或征兆来指定假，即，0。因此，“非常冷”的001编码将被指示六个征兆[X，X，1，1，1，X]，在这里“X”标明“无关”，并且前3个条目对应于真或1值，并且后3个条目对应于假或0条目。替换地，可以使用这七个值的“one-hot”表示的七个单独的征兆，其中“one-hot”表示在本文中被称为位的组，其中，值的合法组合仅是具有单个“真”位且所有其他都非“真”的那些。

在一个实施例中，使用一组具体的列，由征兆用于表示这样的多个征兆值的枚举。在这种情况下，具体的列被标明为匹配“真”/“假”，而不是“真”/“无关”，以表示三列而不是六列或七列中的枚举。仍然需要“无关”值，使得不关心此枚举征兆值的行可以指示这一点。因此，允许标明列值宽度，并且保留一个值来指示“无关”，例如，全为零。在这种情况下，可以标明具有三个位的逻辑列宽度，因此[0，0，0]可以对应于“无关”，而剩余的七个值的组合分别表示七种不同的征兆状态。因此，该枚举可以用三个位表示，但仍然允许在不关心该枚举征兆的行中指定“无关”。

因此，这个附加扩展允许表格标明逻辑列宽度并且将全零情况视为“无关”。然后，对应于isOverheating或S1、S2的列可以被标记为一位宽度，而与上述枚举相对应的列将被标记为一个具有三个位的逻辑列。

在一个实施例中，如果下一列也是跨越多个列的逻辑列/条目的一部分，则列宽度的高效表示是每列具有被设置的一位。等同地，该位可以指示前一列的延续。因此，对应于枚举的列可以被标记为[1，1，0]，其中，最后一位指示在第三列之外没有延续，以指示形成一个逻辑列/条目的三位列。

通常，表格可以指定列宽度以及逻辑列的匹配行为。作为这种更一般情况的示例，表格可以将逻辑列标明为五位宽，并且匹配行为是对“大于”的测试。也就是说，如果这五位中的输入值是大于表格条目中的值的二元值，则输入可以匹配该条目，除了如果它是零，则将表格条目视为“无关”，或者如果所有都是一，则将表格条目视为“未知”。作为指定匹配行为的另一个示例，可以将匹配行为指定为这些列上的输入的逻辑OR。通过在逻辑列中有一个位指示征兆是否与此行相关并且从OR中将其排除，表格条目中的全零值可以被视为“无关”。

在一个实施例中，诸如Intel和AMD指令集中的“ANDN”或逻辑AND NOT指令之类的硬件指令可以供二元表示使用。硬件指令通常比其软件指令执行得更快，并且编程效率更高。ANDN指令对反转的第一操作数和第二操作数实行逐位逻辑AND，例如，inBlock和tableBlock两个操作数不匹配的结果如下：

mismatch＝～inBlock&tableBlock

其中对应的输出表格：

并且因此，如果不匹配是匹配的补码，

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

根本原因分析。图5D是根本原因分析技术的示例的图示。通过使用匹配引擎(554)将给定实际故障场景与RCT(522)中的每一行进行匹配，并且将匹配的那些指示为可能的根本原因来确定与给定的实际故障场景(552)相关联的实际根本原因。也就是说，如果一个故障场景匹配一行，使得每个条目都通过上述match(a，b)运算符匹配，那么将与该行相关联的根本原因作为与该征兆相关联的可能根本原因(556)输出，如图5D所示。

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

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

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

一个关键元素是将已知为假的征兆指示为没有故障的征兆，以及将已知为真的征兆指示为存在故障的征兆，同时仍然允许未知或“无关”。假的情况有效地过滤掉由于另一个原因所致的征兆，例如，压缩机不工作，但是实际上是没有电力，该没有电力是根本原因。因此，依赖于许多其他子系统的子系统SSi可能在可以将子系统SSi中的故障可靠地确定为根本原因之前需要知道所有这些其他系统是工作的。

在一个实施例中，系统可以记录自上次匹配以来实际故障场景中是否有任何征兆改变，并且如果是，则仅将实际故障场景与RCT(522)重新匹配。这种检查避免了在实际故障场景没有改变时进行重新匹配的开销。

在一个实施例中，重新匹配的频率可根据应用要求进行配置。例如，ARCA匹配可以被配置成在制冷系统中每30分钟实行一次，以使匹配的成本最小化，因为故障不会导致立即的问题，并且由此导致的故障检测延迟不会显著影响平均维修时间。这种低匹配率假设以下故障对于检测来说并不重要，该故障发生得足够短暂，并且然后在匹配发生之前消失，因此在匹配的时候并不存在于实际故障场景中。

RCT层级。图5E是RCT层级的示例的图示。在一个实施例中，可能存在对应于不同层次的根本原因分析的RCT的层级。例如，可以对制冷系统RCT(522)进行划分，使得其具有顶层RCT(572)，该顶层RCT(572)对系统性能不佳的高层原因“寻求根本原因”，其可能是以下各项中的一个：1)没有维持期望的温度，以及2)能量消耗过度。一旦该顶层RCT(572)指示这些原因之一，就可以取决于具体原因来自动部署下一层监控和对应的RCT(574)，从而为顶层根本原因提供更具体的根本原因。例如，如果性能不佳的顶层根本原因是能量消耗过度，则可以部署附加的遥测和分析来检测以下征兆：低冷却液、冷却液盘管结冰、压缩机超循环、电流传感器故障，以及能量消耗过度的其他可能的根本原因。该下一层根本原因可能足以指示对系统进行必要的维修。替换地，可以基于在该第二层确定的根本原因自动调遣下一层RCT(574)和处理。

在系统正常运行的情况下，这种分层处理可以减少根本原因分析所消耗的资源。如果下一层根本原因分析仅需要基于较高层处的根本原因指示处理可能征兆的子集，则还可以减少对具体故障寻求根本原因所需的资源。例如，使用上述制冷系统的案例，知道系统的问题是电力消耗过度，实际部署的下一层根本原因分析处理与被配置成检测无法维持所配置的温度以及过度电力消耗的该层根本原因分析相比，可以需要更小的RCT(574)和更少的遥测和处理。替换地，如果两个顶层征兆都出现，则可能就没有这样的节省。然而，将此详细的根本原因分析的两个实例作为单独的进程并行运行是可行的，这样时间效率高。

通常，可以通过跨多个并行线程划分RCT，并且收集每个线程的输出来并行实行根本原因分析匹配。因为匹配不会修改实际故障场景或RCT，并且因为匹配与行之间的顺序无关，所以线程之间唯一需要的同步在于对聚合的根本原因集的输出。

多层、划分和这种层级式方法显著地减小了RCT的大小。例如，在网络应用中，如果诸如基本连接性之类的较高层RCT只考虑每个网络节点四个征兆而不是256个，则RCT的大小可以是以前的近1/64。通过在基本RCT中只具有粗粒度的根本原因，可以进一步减小该大小。相反，链路的大量具体问题可以在该层通过简单的“链路问题”作为根本原因来处理，该问题当被确定时，可能会引起使用整个可能的具体链路问题集来调遣更详细的ARCA。

除了减小在没有故障的常见情况下需要主动访问的RCT的大小之外，这种较小的RCT处理起来更加高效。而且，随着大小方面的充分减小，故障场景向量可能潜在地适于硬件T-CAM，使得可以在硬件中进行匹配。在一个实施例中，在根本原因有多个类似独立单元的情况下，诸如在HVAC应用的情况下具有多个屋顶单元(RTU)，单个RTU RCT可以用来将每个单独RTU的故障场景向量依次传递到T-CAM中，以检测每个RTU中的故障。

这样的分层方法的一个好处是，期望基本ARCA是常见情况，即当装备正确运行时，因此T-CAM可以非常高效地处理常见情况，并且详细的ARCA可以被保留用于实际存在问题的时候。另一个好处是，该分层方法所允许的更基本的ARCA可能意味着在没有故障时收集的遥测数据较少，这再次可以是常见情况。因此，当前可以使用SRAM实现的硬件实现方式(例如，使用T-CAM或等同物)在一些应用中是实用且有吸引力的。

返回到有通道结构的动态环境的自动化导航，每个通道子条件被实现为上述三元故障表示技术的“征兆”，并且每个通道操纵对应于“根本原因”。

规则集被编译成规则引擎可以高效执行的表示。例如，可以将规则集的规则条件编译成代码实现或表格，其中具有每个可观察到的子条件的列，以及每行与规则相关联，并且因此进行操纵，类似于先前图5B中所讨论的内容。给定行(524)(比如行R)和给定列(527)(比如列C)中的条目被设置成对应于与规则R相关联的条件中的子条件C。然后，规则引擎可以使用上述三元故障表示技术周期性地将更新后的计算出或观察到的子条件与表格进行匹配，以确定要实行的一个或多个操纵。

通过使用高效的匹配机制，有可能包括比如TCAM的专用硬件支持，可以以大约亚秒级时段实行该匹配，从而允许响应于动态事件非常快速地触发新操纵，和/或提供对动态事件的快速响应时间。

高效规则集实现方式的自动生成。将讨论范围扩大到如何将规则编译成高效的规则条件评估机制，规则集实现方式的自动生成基于并且源自一组关键观察(key observation)。自主车辆识别停车标志的示例是下面详述的一个示例。

第一个关键观察是，可以将规则分成如本文中所指的两个类别：

·常量规则——触发时不生成任何外部输出或外部行动的规则；以及

·非常量规则——直接引起外部输出或外部行动的规则。

术语“常量”和“非常量”来自C++命名，指的是规则是否在逻辑上改变状态，包括外部状态。

在传统RBS术语和实现方式中，存在内部工作存储器。规则可能采取的行动包括：在该工作存储器中添加、移除或修改事实，以及有可能实行一些外部行动/输出。常量规则是只作用于该工作存储器的规则。非常量规则采取在规则引擎之外可见的某一行动。如果规则集包括既更新内部工作存储器又生成外部行动或输出的规则，则可以将其拆分为两个规则，每个规则具有相同的条件，其中一个执行前者，并且因此是“常量(const)”，并且另一个不仅仅是实行外部行动，还对冲突消解有某种指示，以在两个规则匹配时实行它们。

第二个关键观察是，常量规则可以被视为逻辑蕴涵(logical implication)。特别地，规则被构造为“条件→行动”。对于常量规则，行动仅仅是将事实F添加到工作存储器。因此，常量规则可以被视为“条件→F”。也就是说，该条件的真值隐含着条件F为真，其中条件F是当它为真时对应于“事实”的布尔表达式。如本文中所指，在逻辑意义上使用术语“隐含(imply)”和“蕴涵”，即A隐含B意味着如果A为真，则B为真。

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

如本文中所指，术语“条件”在其为条件表达式时照惯例使用，当为真时其指示条件存在。术语“条件”和“子条件”在本文中以相同的方式使用，即用于布尔表达式以及用于其中该布尔表达式为真的状态两者。

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

(SC0||SC1||SC2)→行动3；

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

SC0→行动3；

SC1→行动3；

SC2→行动3；

因此，如果这三个原始子条件中的任一个为真，就会触发行动。

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

(SC0&&SC1&&SC2)→行动14；

指示在子条件SC0、SC1和SC2全为真的情况下，具有这些子条件/特征的场景的确如此，因此系统可以实行被标记为行动14的行动。

第五个关键观察是，规则条件试图在应用特定的模型中实现事实或输入与给定场景的匹配。例如，在诸如自驾驶车辆之类的特定应用领域中，规则条件可以对应于看到停车标志，并且子条件是：SC0——颜色为红色，SC1——八角形的形状，以及SC2——刻有“停”。因此，重点在于将每个规则条件指定为识别应用领域中需要实行相关联行动的一个或多个场景。换句话说，非常量规则可以被视为从其规则条件逻辑推断其相关联的行动是适当的。

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

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

第六个关键观察是，通过将特征视为征兆，并且考虑将特征归类为根本原因的类，这种特征匹配或所谓的特征分类可以变换为根本原因分析问题，即检测到的图像的根本原因是对应分类的图像中的对象。例如，红色、八角形和刻有“停”的征兆/特征的根本原因是图像中作为停车标志的对象。

更通常地，RBS可以通过处理以下问题变换为根本原因分析问题：

·非常量规则的每个子条件作为征兆；

·常量规则作为征兆传播。也就是说，如果条件→事实是常量规则，那么对应于该条件的“征兆”就传播到规则指定的也是征兆的“事实”；以及

·根本原因作为单独映射到要实行的行动的标签。

相反地，根本原因分析可以被视为特征分类，其中特征是征兆，并且输出分类识别了特定的一个或多个根本原因。如上所述，根本原因分析也可以被视为基于规则的系统，其中非常量规则的每个行动都是“输出此根本原因”，并且每个常量规则被视为指定征兆传播。

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

·对于RS中的子条件中提到的每个元素，引入元素及对应的元素类型(如果尚未定义的话)，例如，网络交换元素；

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

·对于每个非常量规则，以被标记有对应行动的指示的适当元素类型引入对应的符号子条件(symbolic subcondition)，并且被指定隐含构成定义了此规则条件的合取的子条件。每个子条件都是以最相关的元素类型定义的，即是这个子条件为真的元素类型。例如，在网络模型中，在Link元素类型的上下文中，指定“cableBreak”条件。另一个示例可以是“看到停车标志”的符号子条件，其引入诸如“红色”、“八角形”和词语“停”之类的蕴涵；

·对于每个常量规则，指定由该常量规则指定的子条件蕴涵。特别地，如果该规则是“A→B”，则指定以其元素类型的子条件A蕴涵以与该元素类型以某种方式相关的相同元素类型或单独元素类型的B；以及

·指定可以从元素属性直接确定为可观察量的子条件。

图6是计算机网络的简单模型的实施例的图示。图6的模型以面向对象的编程语言语法表达，从而说明了这种规则嵌入。

如图6所示，存在用于以下各项中的每一个的元素类型：Unilink(602)、Link(604)、Interface(606)和Switch(608)，它们对应于计算机网络物理层处的典型组件。每个元素类型具有在其范围内指定的子条件。例如，Link类型(604)具有名为cableBroken的子条件。该子条件还具有指定的actionLabel，使其成为与该actionLabel相关联的规则的规则条件。

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

Interface元素(606)类似地包含由该先前语句隐含的lossOfSignalIn子条件，并且然后进而将该子条件作为lossOfSignalIn隐含到其父Switch(608)。“$”符号指示由元素名称替换的参数。因此，例如，如果该接口是eth3，则$将被替换为eth3，作为此推断的一部分。将Switch中的lossOfSignalIn子条件指示为observableBy表达式，即signalIn＝＝0。这意味着该子条件可以在类型的属性方面由表达式检测到或等于表达式。这些属性通常由监控系统设置，该监控系统正在从交换机接收此信息作为实时遥测。出现在可观察到的子条件中并且可以改变的变量或属性在本文中被称为输入属性(input attribute)。

在一个实施例中，可以代替地以推断的形式指定蕴涵。例如，

signalLoss：Subcondition{

<＝modem：：lossofSignal；

}

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

请注意，Interface::connectedToBy属性被指示为Unilink::connectedTo关系的逆反(reverse)。一般而言，在其上指定子条件蕴涵的每个关系都要求具有逆反关系。在某些标准关系的情况下，诸如组件，逆反是隐含或已知的，在这种情况下即为父(parent)关系。

图7是用元素类型创建的网络实例的实施例的图示。例如，在图7中示出了图6的元素类型。在图7中，存在两个交换机，交换机0/SW0(702)和交换机1/SW1(742)，每个都是先前所述Switch类型的实例。每个交换机SW0(702)和SW1(742)都被示有一个组件接口，分别为I14-s/eth14(704)和I3-a/eth3(744)，以及交换机的电力传感器，分别为SW0(706)和SW1(746)。如果网络接口(704)、(744)被分离供电，则图7中未示出的也可以是它们的电力传感器。

在实际网络中，每个交换机通常可以有多个接口，并且可能有更多的交换机。这两个连接接口之间的Link(722)被建模为两个组件单向链路(722a)、(722b)，每个都是Unilink的实例。这种详细程度允许指定蕴涵的方向性。还允许对故障进行建模，诸如链路的一个方向发生故障而另一方向继续运行。

这个简单模型例示了如何在诸如Link(722)之类的元素类型中指定规则条件，因为在链路(722)上没有传感器，所以Link(722)上可能没有遥测。然而，相关联的子条件可能隐含着中间元素(诸如单向链路)中的子条件，以及然后到它们的父交换机的连接接口的子条件，此时它们隐含可观察到的子条件。

在一个实施例中，在如图6中图示的模型中指定了输入规则集。因此，划分为常量规则和非常量规则只是认识到这个问题而已，即每个常量规则被指定为例如在同一元素中或在与另一个元素的关系上从一个子条件到一个或多个其他子条件的蕴涵，并且每个非常量规则被指定为规则条件，其由可观察到的子条件的合取产生，这些可观察到的子条件由来自被标记有其行动的子条件的蕴涵得出。

在下文中，规则集被假设为如嵌入在如上述模型中的输入，或者被自动变换并嵌入到该模型中，作为使用本文中所述算法进行的输入处理的一部分。如本文中所指，“嵌入”是指从物理放置的角度在对象模型内部指定，如图6所示。例如，对于unilink元素，子条件是lossOfSignal，这隐含着它所连接的元素的信号输入损失指向接口(interface)，如图6中的对象模型所示。图6中的面向对象的模型构建上下文，并且将对象之间的关系维持为重要的关系。

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

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

在一个实施例中，作为中间阶段，编译器模块将该模型自动转换为有向无环图(DAG)的集合，每个DAG以作为非常量规则的规则条件的子条件为根。每个DAG的叶子是按照输入属性表达的子条件。

图8A是用于实行自动转换的过程的实施例的图示。在步骤(801)中，对模型中的所有元素进行迭代以构建规则条件的集合。在步骤(803)中，对于该集合中的每个规则条件RC，将规则条件RC视为DAG的根，并且对与该规则条件RC相关联的所有蕴涵进行迭代，在DAG中为每个规则条件RC均添加链路和边，其中源端对应于规则条件，并且目的地端对应于蕴涵的右手侧或目标。在步骤(805)中，对DAG中与输入子条件不对应的每个叶节点进行递归迭代，包括如在步骤(803)中添加附加节点和链路，以及在每个叶节点对应于输入子条件时终止，以及如果叶节点没有对应于输入属性的蕴涵并且自身不对应于输入属性，则报告错误。

图8B是用于网络示例的DAG集合的图示。在图8B中，存在三个规则R0(802)、R1(804)和R2(806)。每个规则具有相关联的规则条件RC0(808)、RC1(810)和RC2(812)。每个规则条件都隐含着一个或多个子条件的真值，这些子条件是该条件中作为合取的组成部分。例如，RC0(808)隐含S1(814)和S2(816)的真值。S1(814)隐含子条件S3(818)的真值，该子条件S3(818)隐含子条件S5(822)的真值。S2(816)隐含子条件S4(820)的真值，该子条件S4(820)隐含子条件S6(824)的真值。类似地，RC1(810)隐含S8(826)的真值，该S8(826)进而隐含S2(816)和S9(828)的真值。类似地，RC2(812)隐含S1(814)和S11(830)两者的真值。S11(830)隐含S12(832)的真值。换句话说，导出DAG来反映蕴涵。

在一个实施例中，该处理是通过用“子条件”替换“征兆”并且用行动标明替换根本原因标明来对诸如ARCA工作之类的其他工作进行的改编。再次考虑自驾驶应用，规则“由于堵塞而在绿灯进入交叉口时保持停止”在元素AV(用于自主车辆)中具有规则条件，该规则条件在交通灯检测器中隐含子条件“isGreen”，并且在交叉口检测器中隐含子条件“isEntering”，并且在障碍物检测器中隐含子条件“IsBlocked”。然后将该规则条件生成为这些子条件为真的合取。在类似C++的伪代码中，生成的规则可以被指定为：

这种生成基于观察到RCT的行将根本原因指定为可观察量/可观察到的征兆的合取，因此通过上述转换，规则的条件是对应输入子条件的合取。因此，表格1是表示图8B的DAG的RCT：

表格1：例如图8B中的根本原因表格。

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

if((trafficLightDetector-＞color()＝＝green)&&(intersectionDetector-＞position()＝＝entering)&&(obstacleDetector()-＞state()＝＝blocked)){output(″enteringGreenBlockedIntersection″)；}

因此，标签是“enteringGreenBlockedIntersection”。

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

actionObject＝actionMap(″enteringGreenBlockedIntersection″)；actionObject-＞performAction()；

其中“actionObject”是C++对象，其具有在该对象的每个衍生类型中被覆盖(override)以实行期望行动的虚拟函数performAction。

在这种情况下，actionMap可以映射到衍生类型的对象，其覆盖performAction程序以实行“remainStopped”的行动。这种间接性意味着匹配会利用标签来识别场景，并且将场景映射到行动。因此，可以跨多个场景共享相同的行动实现方式。实际上，可以通过具有“comeToStop”行动来细化该示例，该行动可以应用于许多不同场景，这些场景不一定涉及交叉口、交通灯或堵塞。例如，在将道路缩窄为一条车道的一些施工之前，可能有道路工人举起停止指示器。在这个场景以及许多其他场景中可以调用相同的行动。

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

为了解释简单起见，performAction函数被示出为不带任何参数。然而，在一个实施例中，可能存在与被传递给performAction函数的匹配场景相关联的“场景”对象，即actionObject->performAction(scenario)；其中“场景”是对场景的描述。例如，“comeToStop”行动需要根据到堵塞的距离以及车辆速度进行参数化。此额外信息可以允许行动程序确定是否需要大力制动或渐进制动是否足够。

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

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

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

将概率与输入相关联存在几个问题。

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

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

最后，如根据这些输入概率计算出的，这样的系统的输出通常被提供为具有最高概率的根本原因，并且因此是单个根本原因，因为只有一个可以具有最高概率。实际上，这些概率计算可能会生成大量的潜在诊断，并且按概率对它们进行排序。然而，考虑到先前所提及的使用输入概率的困难，尚不清楚如何基于计算出的概率合理地过滤这些诊断。例如，如果操作员只考虑概率大于0.7的潜在根本原因，那么合理的关注是询问用户如何可以确信实际根本原因至少具有该概率。也就是说，用户如何可以推论该特定阈值是包括实际根本原因的正确阈值，而无需任意数字或需要重复来获得系统的手动、定性直觉。

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

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

本文中示出了一种用于生成与被诊断系统的征兆相对应的一组可能的根本原因故障的高效自动化手段，包括通过指定和/或预先指定多种潜在故障场景。如本文中所指，潜在故障场景可以对应于当系统中发生给定故障时预期的一组征兆。如本文中所指，征兆是可观察到的值或值范围，或者可从与识别故障或指示故障的计数器有关的可观察值计算出的值。与可以对输入应用概率的SMARTS不同，本文中的技术将概率与输出相关联，表达为例如置信水平。如本文中所指，潜在故障场景的置信水平是在给定潜在故障场景的征兆集的情况下，系统中的场景故障的概率。

例如，征兆可能是计算机网络交换机在其特定接口之一上报告的“信号损失”。当对系统的监控从受监控的实际系统(在本文中被称为实际故障场景)检测到一组征兆时，将该实际故障场景与潜在故障场景集进行匹配，以产生在本文中被称为针对该实际故障场景的匹配集的内容，其中如果潜在故障场景与实际故障场景匹配，则它是匹配集的成员。

然后可以基于匹配的潜在故障场景的属性和其他信息来细化该匹配集。如本文中所指，属性包括与匹配的潜在故障场景有关的任何信息和/或关系，诸如匹配的征兆、匹配的身份(identity)和/或匹配的置信水平之间的关系。然后可以输出与细化的匹配集中的条目相关联的根本原因故障，构成根本原因分析的结果。这种根本原因分析可以产生一组潜在的根本原因，其中很可能将包括实际根本原因故障或根本原因故障。

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

SW0(702)在接口I1-a(704)上报告“信号损失”的实际故障场景可能与对应于交换机SW0(702)和交换机SW1(742)之间的链路a(722)中存在链路故障的故障场景FS1匹配。然而，相同的征兆也可能与其中链路任一端处的两个接口(704)、(744)同时发生故障的故障场景FS2匹配。它还可能与对应于链路a(722)中的链路故障的故障场景FS3匹配，但不考虑辅助征兆，诸如与SW0传感器(706)和SW1传感器(746)处的电力损失相对应的征兆已知为假。因此，在本示例中，匹配集由FS1、FS2和FS3组成。其表格表达是：

基本场景被归入其相关联的衍生场景。在一个实施例中，潜在故障场景的属性指示一个潜在故障场景FSa何时被归入另一个潜在故障场景FSb。也就是说，只要FSb匹配，FSa也将匹配。如本文中所指，FSa是基本场景，并且FSb是衍生场景。在FSa和FSb二者都匹配的情况下，匹配集的细化是要在将故障场景转换为其相关联的根本原因之前从匹配集中移除FSa。

为了例示这种情况，继续图7的网络示例，匹配细化步骤将意识到，FS3被归入FS1，因为FS3只需要匹配FS1要求的征兆的子集。

基本场景被归入衍生场景的另一个简单示例是医学示例：

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

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

因此，对于包括高体温、疼痛和头痛征兆的实际故障场景，FSm被认为是归入衍生场景FSn的基本场景，并且因此输出了具有90％置信水平的流感的根本原因。

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

具有高体温、疼痛、头痛、流鼻涕和耳痛征兆的患者可以被认为是其中关联概率为90％置信水平和5％置信水平的组合的组合。在一个实施例中，可以对置信水平线性求和。

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

例如，使用图7的网络示例，细化将指示FS1和FS2作为彼此的替换方案，因为这两个场景都对应于一组共同的征兆或征兆子集。

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

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

·潜在故障场景FSq考虑到高体温、疼痛和头痛的征兆示出具有3％置信水平的花粉过敏的根本原因。

因此，对于包括高体温、疼痛和头痛征兆的实际故障场景，FSq被认为是FSn的替换解释。

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

[RC1：0.95，RC2：0.05]

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

将概率与潜在故障场景相关联可能比输入概率方法更可行，因为每个故障场景都表示其中顶层故障需要补救的情况。因此，运行数据可以指示与替换方案(即具有相同征兆的替换方案)相比，给定的根本原因出现的频率。例如，重新回到图7的网络示例，如果在观察到关联征兆的100次里有95次断开链路a(722)是实际根本原因，并且在那100次里只有5次是实际上两个接口(704)、(744)同时发生故障的情况，则所记录的运行数据提供了用这些概率对这两个替换根本原因进行加权和排序的基础。

因此，首先将输出结果视为检测到断开链路a(722)的补救行动在大多数情况下会立即解决实际根本原因故障，并且只有5％的时间会需要转到替换故障补救行动。在一些情况下，诸如两个接口(704)、(744)同时发生故障的情况，用户可以估计基于概率的接口平均维修时间、以及单个接口故障的频率和接口数量，进一步限定在同一恢复窗口内发生故障的两个接口实际上位于链路任一端的可能性。请注意，虽然不太可能，但链路和两个接口都发生故障是可能的。也就是说，替换的根本原因可能不是相互排斥的。在这种情况下，需要针对两个故障采取补救行动。

匹配。在一个实施例中，如由匹配机制实行的实际故障场景与潜在故障场景的匹配从以下意义上说是精确的，即每个匹配的潜在故障场景可能被要求为使得实际故障场景对每个征兆满足在匹配的潜在故障场景中指定的征兆要求。

例如，如果潜在故障场景将征兆Si指定为烤箱温度高于100摄氏度，则实际故障场景应该包括被报告为高于100摄氏度的这种征兆。

这种匹配与例如在SMARTS中使用的输入概率方法形成对比，其中，即使传感器没有报告这种情况，但考虑到由关联概率所捕获的关于传感器的不确定性，该征兆也有一定概率是真的。它还与各种看似任意的“基于距离的”方法(诸如汉明距离方法)形成对比，其中ARCA系统基于距离来选择“最佳匹配”，该距离是按照实际征兆和与根本原因相关联的征兆(类似于潜在故障场景)之间的某种度量的距离。在一个实施例中，匹配集的生成由如本文中所述的具有三元RCT表示的三元匹配机制来实行。

未细化的故障场景匹配集可能包括多个成员，即使在部分匹配单个实际故障的情况下，因为潜在故障场景集应该覆盖其中一些遥测缺失或错误的情况。例如，提供了上述网络示例中的FS3，使得即使对辅助征兆的遥测不完整或不正确，也存在某种匹配。也就是说，仅仅因为一个交换机(702)或另一个交换机(742)无法向接口报告电力(706)、(746)而不能诊断链路a(722)中的链路故障将是不可接受的。

一般而言，匹配可以高效实现，并且能够同时匹配多个独立的根本原因，如上述关于三元故障场景表示的应用中所描述的。匹配的缺点是，当潜在故障场景中与实际故障场景相对应的任何指定征兆与从遥测确定的征兆不匹配时，匹配失败。即使当对征兆的人工评估可能很快得出根本原因是什么时，也可能出现这种情况。

图9是图示了电力示例的实施例的框图。在该电力示例中，交换机SW0(902)经由接口和链路完全耦合到24个其他交换机SW1(942)、SW2(962)直至SW15(992)。如之前图9中所示，每个交换机(例如，交换机SW0(902))包括电力传感器(902z)以及一个或多个接口I1-a(902a)，I1-b(902b)，...，I1-x(902x)，每个接口对应于链路a(922a)，b(922b)，...，x(922x)。

如果对计算机网络交换机SW0(902)(包括SW0电力传感器(902z))的电力发生故障，人们会期望交换机通过链路与之连接的每个接口都将检测到信号损失。然而，如果所讨论的交换机通过链路连接到24个单独的接口I2-a(942a)，I3-b(962b)，…，I25-x(992x)，但是这些接口中只有23个报告信号损失，并且遥测中缺少第24个接口I25-x(992x)，则匹配将无法与指定全部24个单独接口都具有失电征兆的潜在故障场景进行匹配——即使任何正常人都可以从征兆中得出交换机发生故障的结论，并且此外，如果该交换机SW0的电力传感器(902z)报告失电，则也会由于电力不足而发生故障。

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

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

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

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

部分匹配潜在故障场景(PMPFS)。PMPFS在本文中被称为被添加以通过匹配机制有效地处理部分匹配的潜在故障场景。有各种技术来定义PMPFS。

省略一个征兆的PMPFS。首先，对于根本原因的每个完全潜在故障场景，每个征兆都可能存在省略其中一个征兆的PMPFS。例如，使用图9的电力示例，每个相邻接口都可能有PMPFS，其将该接口作为征兆省略，或者替换地将该征兆标明为“无关”。例如，PMPFS可以将I25-x(992x)作为“无关”省略掉，并且因此在I2-a(942a)，I3-b(962b)，…，I24-w(图9中未示出)报告信号损失的情况下，系统可以得出交换机SW0(902)已经发生故障的结论。

有可能更进一步，并且为完全潜在故障场景的征兆子集提供PMPFS。例如，创建I24-w和I25-x(992x)二者为“无关”的PMPFS。然而，在现实复杂性系统中，这可能导致PMPFS的数量不切实际。例如，在具有32个直接相邻交换机的交换机示例中，基本上有2的32次方或大约40亿个可能的子集。在这里，近似匹配可以解决PMPFS数量过多的问题。换句话说，部分匹配可以被认为是添加不太完整的额外行，而近似匹配是放宽匹配标准，所以人们可以匹配与掩码或实际完整征兆集不完全匹配的行。

排除一个值范围的PMPFS。一种用于有效支持部分匹配同时避免PMPFS数量呈指数级骤增的方法是，允许潜在故障场景将给定征兆指定为排除某个值、或值的范围。通常使用的值会与作为根本原因的关联故障相矛盾。在图9的电力示例中，可以将PMPFS指定为要求lossOfSignal征兆为真或未知。然后，只要没有相邻交换机声称接收到来自据称已断电的交换机的信号，就会发生匹配。也就是说，如果一些相邻交换机(例如，未知的I25-x(992x))不知道此征兆，则匹配仍会发生。

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

限制PMPFS的范围。用于有效支持部分匹配同时避免PMPFS数量呈指数级骤增的另一个方法是，限制PMPFS的范围及其征兆，并且对应地降低与其相关联的概率。在图9的电力示例中，可以生成PMPFS，该PMPFS与交换机SW0(902)的当前电力故障传感器(902z)匹配，并且指定对相邻交换机(942a)，(942b)，…，(942x)的遥测有效的“无关”。如果电力传感器(902z)报告电力故障，但存在来自一个或多个相邻交换机的矛盾信息(诸如I25-x(992x)的“未知”，其可能不正确或过时)，则该PMPFS匹配。

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

定义聚合征兆。用来有效支持部分匹配同时避免PMPFS数量呈指数级骤增的另一个方法是，定义基于跨多个传感器输入的遥测所设置的聚合征兆。在图9的电力示例中，人们可以定义大于对应于具有来自给定交换机SW0(902)的损失信号的相邻交换机SW1(942)，SW2(962)，…，SW15(992)的某个阈值K的聚合征兆。然后，针对交换机失电的PMPFS可以指定这个聚合征兆，使得如果交换机的大多数直接邻居具有来自它的损失信号，则该交换机被认为已发生了电力故障。需要清楚的是，合并来自其直接邻居的这种信息的好处在于，它有助于区别这种情况和其中交换机上的电流传感器发生故障而不是电力本身发生故障的情况。

征兆的反向传播。另一个高效支持部分匹配的方法是，从PMPFS中排除已由本文中所称为的反向传播所确定的征兆要求(简称“征兆的反向传播”)。在图7的网络示例中，对于在链路a(722)的远端/SW1端(742)未接收到信号的一个可能解释是，网络电缆损坏。对于在链路的远端未接收到信号的替换解释是，在近端/SW0端(702)的接口I1-a(704)已经失电。这是因为链路(722)一端的接口处的失电有效地将信号损失征兆传播到链路另一端的接口。

使用征兆的反向传播，此场景的征兆的完全故障场景要求每个接口和/或交换机(706)、(746)的失电征兆为假。然而，这种反向传播还意味着，如果该交换机SW0的当前电力传感器(706)出现故障，则ARCA可能无法匹配完全故障场景，并且因此除非存在匹配的PMPFS，否则无法确定根本原因。在这种情况下，考虑到通过忽略由于反向传播而以其它形式要求的征兆所引入的不确定性，可能存在把由这种反向传播引起的这些征兆(通常具有相关联的较低概率)排除在外的PMPFS。

使用征兆的反向传播的组合。每一个先前的技术或方法也可以应用于征兆的反向传播，包括：1)使用反向传播征兆的子集；2)使用反向传播征兆的聚合，以及3)使用征兆值的排除，而不是包含范围。

一般而言，PMPFS允许在根本原因分析的准确性与大量PMPFS的计算机存储器/处理之间进行工程权衡。也就是说，可以利用较少数量的PMPFS来降低计算机存储器需求、和/或增加计算机处理速度。更准确的分析比不太准确的分析需要更多计算资源。然而，超过一个点以后，使用更多PMPFS的回报会递减，因为遥测的正确性和可用性的不确定性限制了任何分析的确定性。

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

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

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

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

一种替换方法是使行动幂等(idempotent)。也就是说，如果行动程序在同一场景中被执行一次以上，则其具有与执行一次相同的效果。例如，如果“comeToStop”的行动已经在踩刹车了，则可以通过让它继续踩刹车来使之成为幂等的，因此多次调用该行动与调用其一次具有相同的效果，即本文中所称的“幂等”。可以在每次匹配时重新执行幂等行动，但是在第二次和随后的匹配中无效。

一般而言，有各种各样的手段把行动实现方式与场景的分类分开、按照触发场景将行动实现方式参数化、以及实行冲突消解和/或匹配集细化，并且处理行动重新执行。此外，这些技术可以独立于指定的实际模型，因此并不严格取决于自动代码生成。从上面的代码片段中可以明显看出，与条件代码本身不同，这些代码片段中的行动映射代码并不特定于模型的任何方面。

也就是说，自动代码生成可以在行动映射中实行各种优化，诸如当模型被指定为CARBS实例时消除冲突消解的代码。假设将行动本身显式地指定为程序或类似的，因此在本文中可能不一定要求或涉及自动代码生成。因此，规则条件代码生成如下所述。

规则条件代码的自动生成。规则条件匹配代码的自动生成可能比上面针对现实应用模型所概述的更加复杂。例如，先前的示例建议存在单个trafficLightDetector、intersectionDetector和obstacleDetector。然而，实际上，在自主车辆正在行进的区域中可能有众多交通灯和交叉口。因此，交叉口检测器需要指向与自主车辆的方位和速度有关的检测器，trafficLightDetector和obstacleDetector也是一样。也就是说，障碍物检测器可能需要检测自主车辆正在行进的路径上的障碍物。

在基于表格的实施例中，通过每个元素实例地生成征兆，并且在RCT中为共置的trafficLightDetector、intersectionDetector和obstacleDetector特定征兆的每个组合生成行来解决该问题。先前从网络领域中使用的示例进一步例示了这种方法。RCT方法为每对所连接的接口生成行，其中将特定于那些接口的征兆设置为指示信号损失，同时为每个单向电缆故障生成行。实际上，如图8B中图示的，对于每对所连接的接口都存在DAG，其中对应的行包含该DAG的叶(leaf)子条件。因此，如果数据中心网络中有10,000根电缆，那么就有10,000行与这一个逻辑故障相关联，每对接口有一行。这种把实际征兆与行分开以获得对条件有效的不同参数值是被用于自动化根本原因分析的一种方法。

在一个实施例中，生成显式条件评估代码而不是依赖于表格匹配。每个非常量规则因此可以具有所生成的代码片段，该代码片段评估按照所涉及的元素进行参数化的关联规则条件，并且存在作为参数提供这些元素的关联数据结构。然后通过对该集合进行迭代、为每个参数集调用代码片段(如该数据结构中所指示的)来实行对该逻辑根本原因的条件的评估。例如，可能存在所连接的接口对的集合，其然后被用来调用与检测电缆故障相关联的代码片段。对该集合进行迭代，调用每对上的代码片段，然后检测是否存在电缆故障。

请注意，使用本示例，对于数据中心网络中的10,000根电缆，该集合中可以有10,000个条目，空间开销在某种程度上类似于与此故障相关联的RCT中的10,000行。然而，如果存在与所连接的接口对相关联的第二个根本原因故障，则相同的对集合可以用来迭代第二个根本原因代码片段，然而对于RCT，必然存在与该第二个根本原因故障相关联的第二组10,000行。例如，如果存在隐含从一个接口到另一个接口的根本原因，而不是来自电缆的双向蕴涵，则可以使用该同一集合来评估该另一个根本原因。例如，如果电缆的一个方向断开，则一个接口检测到信号损失，而另一个接口没有检测到。可以使用与图9中所示的内容类似的相同的接口对集合来识别此根本原因故障。

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

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

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

在利用RCT的自动根本原因分析的其他实现中，将当前征兆周期性地与表格进行匹配，以检查根本原因故障，如图5D中图示的。类似地，规则引擎通常会反复轮询整个规则集，以检查规则条件是否为真，以便检测可能触发的规则行动。然而，这种方法会受到快速轮询的开销与检测可能触发行动的条件的延迟之间的典型权衡的影响。特别地，用以最小化触发行动时的延迟的较高频率轮询引入了显著的开销，而用以减少该开销的较低频率轮询增加了在条件变为真之后触发的延迟。以显式规则条件代码支持的替换方法是采用反应式实现方式，其中输入属性改变会触发对取决于该输入的规则条件的立即重新评估。因此，如果该行动的规则条件现在已经变为真，则可以在没有延迟的情况下实行该行动。下面描述了这样的反应式实现方式。

反应式规则引擎实现方式。在一个实施例中，编译器输出实现了反应式规则引擎的代码。反应式规则引擎直接对输入改变做出反应，并且实行与规则条件相关联的行动，这些规则条件由于输入改变(如果有的话)而变为真，从这个意义上说，反应式规则引擎可以是反应式的。

图10是反应式规则引擎的实施例的图示。在一个实施例中，将反应式规则引擎实现为“侦听器”模块(1004)，如图10所示。“侦听器”或等同的“观察器”(1004)是面向对象编程中的传统软件设计模式。本质上，侦听器(1004)是当“侦听到”对象(1002)之一中的某个感兴趣的属性发生改变时通过回调通知的模块。因此，侦听器(1004)对元素属性(1002)的改变做出反应，如果规则条件为真，则将规则实例添加到匹配集(1006)。

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

在一个实施例中，生成侦听器模块(1004)以侦听在模型中实例化的每个元素(1002a，1002b，…，1002z)的每个输入属性。因此，在C++术语中，编译器定义具有指向该模块需要侦听或响应的每个元素的数据成员的类，如果存在多个这样的相同类型的元素，则可以将类定义为单个指针或定义为指针集合。对于每个输入属性ia，编译器还生成回调函数“onIa()”。遵循C++中的标准做法，此回调可以位于作为回调接口的衍生类的单独的类中，然后调用到实际的主侦听器模块类中。利用代码生成回调函数，以评估模型中指定的受该输入属性ia改变影响的规则条件中的每一个。因此，当属性“ia”改变时，调用该Listener::onIa()(1004)程序。该程序评估取决于该输入的规则条件，并且为每个评估为真的规则条件输出行动标签(1006)。

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

上述代码片段中“if”条件的生成是简单直接的，因为它只是可观察的子条件的合取，这些子条件是以规则条件为根的DAG的叶子，如图8B中图示的那样。

在上面，“通知器(notifier)”对应于正实行回调的接口元件，并且otherInterface是它连接到的接口(通过Link和Unilink对象间接连接)，通过getOtherInterface返回。因此，编译器可以生成代码以存储和维护该侦听器模块中的集合，该集合可以保存所连接的接口对。因此，当将上述条件作为执行该回调函数的一部分进行评估时，将上述代码中的“otherInterface”变量设置为通过访问该集合将“通知器”接口与之连接的接口。

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

在一个实施例中，侦听器模块(1004)被实现为定义和实现行动程序的基本类的衍生类(在C++术语中)。例如，可以在C++中手动指定行动，如下：

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

也就是说，(所生成的)RuleModule是可以显式编程的ActionModule的衍生类，因此能够访问由后一模块提供的“受保护的(protected)”行动程序。然后，如前所述，可以为每个输入属性生成规则评估代码，并且对行动程序的调用仅调用ActionModule中指定的那些，ActionModule通过继承合并到规则模块中。

在一个实施例中，可以通过手动编程提供侦听器模块代码的选定部分。例如，通过在规则条件中指定“外部的(external)”，自动生成不会为该规则生成规则条件，而是代替地假设/依赖于处理此条件的手动指定代码。该规定意识到，对于特定应用程序，往往需要进行一些超出编译器支持范围的特殊优化。

图11是监控系统中反应式规则引擎的实施例的图示。图11示出了结构化为侦听器模块(1004)和行动执行模块(1008)的反应式规则引擎(1000)如何连接到监控系统(1102到1108)。在图11中，传感器(1104)提供与监控系统(1102)相关联的值的测量结果，诸如温度、湿度等等。这些值由遥测系统(1106)收集，该遥测系统递送这些值以供输入处理(1108)，该输入处理可以对输入采取若干行动。例如，它可以将传感器输入值从一种度量转换为另一种度量，诸如从A/D单位转换为摄氏温度。它还可以在缺失值的情况下内插或外推传感器值，或者在可能由于传感器瞬变所致的尖峰或错误值的情况下平滑或纠正传感器值。在那种情况下，它可以提供来自输入的计算值，诸如对某个输入的加权移动平均值。它还可以将输入流离散化为由阈值定义的少量离散值，诸如例如对于温度读数而言的冷、凉、暖和热。因此，反应式规则引擎(1000)仅对穿过阈值的温度改变做出反应。最后，它可以保留来自侦听器(1004)的输入值，直到某个指定的周期或轮次为止，以支持规则的周期性轮询，而不是对每个输入改变做出反应，如稍后所述的那样。也就是说，映射可以限制反应式规则引擎仅对阈值穿过(threshold crossing)做出反应，以降低噪声、保留输入值以降低噪声等等。

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

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

在一个实施例中，作为优化，编译器可以识别模型中完全针对常量规则存在并且不对应于任何输入的对象的情况。例如，网络中的电缆上面通常没有传感器，并且因此在没有输入指示器的情况下对其建模。它存在只是为了提供上下文以指定一个或多个规则条件及其蕴涵。在这些情况下，编译器可以通过破坏关系来优化这些对象，所以直接对具有观察到的征兆的对象进行评估。例如，在计算机网络的示例中，可以优化Link和Unilink对象，并且接口之间的互连可以直接记录在Interface对象中。特别地，通过这种优化，接口包含指向其连接到的接口的属性“otherInterface”。在比如“父级(parent)”的关系的特殊情况下，很容易通过常见的父返回指针从组件元素中确定父级。

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

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

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

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

在“if”块内嵌套otherInterface的获取意味着只有在通知器的lossOfSignal属性为真时才会执行getOtherInterface程序调用。在预期的常见情况下，该属性可能为假，由此节省了本次调用的成本。

另外的优化是识别正在被评估的规则条件中的公共子表达式。例如，与单向电缆断开相对应的规则条件对应于一端的信号损失，而不是另一端的信号损失。即

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

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

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

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

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

(SC0&&SC1)

而衍生规则可以指定进一步导致SC2的子条件蕴涵，所以其条件表达式是：

(SC0&&SC1&&SC2)。

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

衍生规则条件比对基本规则条件可以用来有效地指定子条件的部分匹配。或者相反地，可以用来避免在缺失一个或多个子条件时规则条件无法匹配的情况，尽管预期场景很可能是这种情况。例如，作为停止标志的对象的基本规则条件可以是它具有观察到的八角形以及红色的子条件。衍生规则条件可以指定刻有单词“停止”的标志的附加子条件。即使刻印可能未被读取，对象也仍可以被识别为停止标志，但是如果可以读取该刻印，则会以更大的置信度将该对象识别为停止标志。当衍生规则条件匹配时，这些规则条件之间的衍生关系提供了抑制与基本规则条件匹配的指示。

在一个实施例中，编译器可以基于推断自动生成衍生规则条件，即子条件的反向传播，如上所述作为征兆的反向传播。特别地，编译器可以在可能为假的衍生规则条件中添加观察到的子条件，由此区别开指定规则条件和在引起它们触发的观察到的子条件中以其它形式重叠的其他规则条件。

上述优化可以用来优化用于处理基本条件和(一个或多个)衍生条件评估的代码。在简单的情况下，代码的结构为：

也就是说，仅当基本规则条件成立时才评估衍生规则条件。

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

在一个实施例中，可以将输入子条件定义为按照实际输入属性的表达式。例如，交换机可以具有Switch：：signalInLevel属性，而不是Switch：：lossOfSignalIn布尔输入属性。然后，从输入的信号损失由表达式switch-＞signalInLeVel()<minSignalLeVel()指示。

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

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

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

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

步骤1使用与规则条件RC相关联的DAG的叶子填充OSS，参考图8B中图示的规则条件的DAG表示。

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

用来生成用于为条件的给定实参找到对应的一个或多个元素的代码的步骤是：

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

b.找到隐含当前子条件所跨关系的逆反关系。(逆反关系在模型中如此指示，如图6中指定的connectedToBy关系所图示的)

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

i.获取隐含当前子条件的子条件，如果有的话。往往存在单个这样的子条件，所以在这些情况下的代码中是照此指定的。

ii.遵循此子条件隐含所跨的隐含关系，前进到输入属性，排除与刚刚遍历的逆反关系相对应的关系。(在“otherInterface”情况下，除了规则条件本身的情况外，没有其他关系。)记录要用作条件实参的输入属性值。

iii.如果此子条件对应于规则条件，则实参生成完成。

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

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

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

上述序列中描述的其余子条件的实现包括：生成代码以沿着先前示例中为“otherInterface”描述的行，访问这些其他子条件所使用的值。

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

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

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

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

在替换的实现方式中，编译器生成程序PP，当调用该程序PP时，会调用具有每一个可能参数的每一个反应式程序。在此实施例中，在每个周期开始时调用PP程序。

在一个实施例中，优化程序的实现方式以最小化或避免重复规则评估。例如，考虑与断开链路相关联的规则条件的先前示例，该程序可以意识到，利用接口对(intfj，intfi)评估规则条件与利用接口对(intfi，intfj)评估规则条件相同，因此只有其中一个作为该程序执行的一部分而被执行。该实施例可以生成单个经优化的pollEvaluate程序，当调用该pollEvaluate程序时，实现所有规则条件，从而输出规则条件为真的指示。

总体上，相同的代码生成技术可以用来为周期性轮询形式的执行以及为先前所述的反应式执行(并且在一个实施例中是动态切换)生成规则引擎代码。软件编程领域的技术人员可以意识到，除了在这里详述的优化之外，还可以实现各种各样的优化，从而允许在轮询形式的执行的情况下高效执行。

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

在一个实施例中，编译器检查这种模糊性。这样做的一种方法涉及为指定的模型和条件生成根本原因表格的等同物。特别地，对于可观察子条件的每个具体实例都存在一列。对于每个规则，都存在一行表示关于可观察子条件的条件，其中如果在该条件中子条件为真，则给定子条件的条目为真，如果在该条件中子条件为假，则为假，并且在三元匹配RCT的情况下为“无关”，并且在所生成的条件中未指定子条件。

利用这种所生成的表格，编译器然后对RCT中的每一对的行实行成对匹配。如果Ri与Rj匹配，则Rj与Ri部分模糊不清。即每当Ri匹配时，Ri就匹配。类似地，如果Rj与Ri匹配，则Ri与Rj部分模糊不清。如果该对双向匹配，则它们完全模糊不清。

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

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

图12是子条件反向传播的示例的图示。RCi(1202)和RCm(1204)均分别隐含可观察的子条件OSk(1208)和OSp(1212)。RCi(1202)和RCm(1204)也隐含Sj(1206)。RCi(1202)进一步隐含OSp(1212)。因此，编译器可以将“not OSk”添加到为RCm(1204)所生成的规则条件，以进一步将RCm(1204)与RCi(1202)区分开。也就是说，OSk(1208)为假意味着RCi(1202)不可能为真。作为另外的示例，考虑图7的网络，两个交换机接口上的电力故障可以引起与断开链路相同的每端处的信号损失的征兆。因此，如果将接口电力征兆添加到模型，则反向传播会将针对每个接口的接口上电力损失的错误条目添加到对应于cableBreak规则条件的行。

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

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

自动生成规则集实现方式的第二个好处是，它允许反应式规则引擎实现方式，也就是说，通过重新评估取决于该输入属性的规则条件来立即对输入属性改变做出反应的实现方式。当快速响应至关重要时，这种反应式方法效果很好，并且避免了快速轮询的开销与缓慢响应时间之间的权衡。

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

在显式代码方法中，与基于表格的方法相反，还有另外的好处。特别地，显式代码方法使得无需重新编译模型即可改变元素之间的关系成为可行的。这是修改指示已改变的给定关系的(一个或多个)集合的问题。例如，使用网络示例，当在这些接口之间添加新链路时，可以动态地添加新的接口对(Ii，Ij)，而无需任何重新编译。

而且，在一些应用程序中节省了存储器，因为有一个代码实例来评估条件而不是RCT中的N个条目，并且不需要“工作存储器”。例如，有一个代码片段检查电缆断开，而不是RCT中的N个条目，每对接口(即，每根电缆)有一个。当有几个条件使用(一个或多个)相同的关系时，这种好处会被放大。这是因为关系被存储一次但是被使用多次，而对于RCT来说，行数对应于条件数乘以该关系中的条目数。当应用程序已存储了相关联的参数和关系，并且使用这种状态来提取每个关联场景的参数是可行的时，这种方法特别有吸引力。因此，这样做的优点是，在一些情况下，它可能较快并且使用空间较少。

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

如上所述，例如，当两个或更多个规则响应于相同的子条件而触发时，可以自动检查规则集的模糊性。避免RBS引起两个操纵被触发的情况可能很重要。它还可以检测其他情况，诸如任何规则条件中未指定的子条件或相互矛盾的通道子条件，并且因此包含的规则条件可能永远不会匹配。

还如上所述，基于匹配集的ARCA和比如与PMPFS相关联的那些的相关联的技术可以用来消除归入条件以减少触发操纵的数量。

利用通道规则集，会出现车辆无法导航通过的某些场景。例如，如果道路在行驶车道上的道路外侧被部分阻挡，并且在对向车道上的道路外侧被部分阻挡，则可能无法在行驶车道或对向车道上通过该道路。在这种特定情况下，细化车道操纵的词汇以包括改变为跨过中央分隔带的操纵，并且添加适当的子条件来触发该操纵，可能会允许导航该场景。

如前所述，车道操纵词汇的复杂性与车辆可以导航的场景之间存在权衡。一种推荐的方法是，使操纵词汇足够全面，以允许导航所有预期场景，并且在与其他场景不匹配的情况下使用默认操纵，其中，该默认操纵可能需要人类协助，或切换到替换目标/路线。再一次，这与人类驾驶员相同。如果驾驶员不能在给定场景中处理车辆，则他们可以将驾驶权交给另一个人，或改变预期目的地。

通道规则集可以迭代开发，依次扩展它可以正确处理的场景集，并且纠正编译过程中指出的问题。对于不同类别的场景，也可能存在单独的通道规则集，如下所述，以避免在每个规则集中产生过多的复杂性/匹配成本。

使用有通道结构的规则集的自动导航。在开发了一个或多个有通道结构的规则集，并且接受有可选路线引导的预期目的地之后，自动导航的基本算法是：

步骤1：根据传感器输入、感知系统和路线引导更新通道子条件指示；

步骤2：确定满足或匹配这些更新的通道子条件的规则条件；

步骤3：启动与这些匹配的规则条件相对应的(一个或多个)操纵，终止与不再匹配的条件相对应的任何正在进行的操纵；以及

步骤4：一旦通道子条件指示可能已经改变，从步骤1开始重复。

考虑到子条件可能由于车辆改变或移动而发生改变，如果没有其他原因，可以在适当的延迟之后采取最后一步。替换地，它可以由传感器输入的改变或另一个触发来触发。如上面关于三元故障场景表示所述的，子条件可以形成掩码，并且与表格匹配，或者被提供以生成反应性地指示所选定的一个或多个操纵的代码。

对于子条件不匹配任何规则条件的情况，可以提供默认操纵。这种情况对应于控制系统不了解当前情况。默认操纵可以是警告人类操作员和/或采取一些预防行动。例如，在自驾驶车辆的情况下，默认操纵可以是使车辆安全停车。

在一个实施例中，规则条件可以由指示特定子条件是否与环境中的已知/理解元素有关的子条件进一步限定。例如，当对象出现在自驾驶车辆旁边的右车道上时，如果该对象未知与已知是在相邻车道上行进的另一辆车，则所匹配的规则条件可能不同。在前一种情况下，所匹配的规则条件可能会发起预防操纵，而在后一种情况下，仅在当前车道上继续维持速度通常就足够了。利用这种结构/特征，车辆可以立即对感测到新的但未知的对象做出反应，而不是让其响应因感知系统而被延迟。然后，当事件发生在其类型和行为被理解的对象上时，它可以使用更详细和复杂的感知能力来减少误报预防措施。从这个意义上说，系统可以在理解之前做出反应，而不是必须在做出反应之前理解。

此行为在其他设置中也适用且很重要。例如，在医学治疗领域，即使在完全了解不良反应的原因之前，检测到患者的不良反应或病情突然恶化，也需要立即采取补救/预防行动。

使用多个导航规则集。对于模块化，为了避免给定规则集的过度复杂性并且最小化规则条件评估成本，针对每个不同类别的导航场景可能存在单独的规则集。例如，对于自驾驶车辆来说，针对高速公路驾驶、城市商业区驾驶和住宅驾驶可能存在单独的规则集。针对不同的天气条件，也可能有不同的操纵和规则集。例如，可能有针对在湿滑条件下驾驶的规则集和针对干燥道路条件的不同规则集。

在股票交易应用中，针对牛市环境、高波动性市场、年终交易等等，可能有不同的规则集。在医学治疗场景中，针对不同类别的患者，例如，年轻人、老年人、青少年、男性和女性，以及基于病情的明显严重性，可能有不同的规则集。

在一个实施例中，可以使用单独的规则集来选择要用于导航的规则集。例如，在股票交易应用中，可以基于具有关键领先股票指数的趋势来选择规则集。对于驾驶应用来说，可以基于驾驶区域(诸如住宅驾驶区域或商业驾驶区域)以及道路状况来选择规则集。在本实施例中，对于用于该选择的每个规则，规则条件是可以使用的关联规则集下的条件，并且规则行动在被触发时切换到使用该规则集。

处理无通道环境。在一个实施例中，车辆控制系统包括：至少部分地基于车辆之间关于如何进行的一般规则，在没有车道的区域中动态生成“虚拟车道”的模块。例如，如果两艘自航船在海洋中航行，则可能有这样的一般规则：这艘船向右舷的船让行，以及超船向前面的船让行并且从左舷通过。更深入地探索这个示例：在许多商业航线中，即使只标明了经纬度，也存在有效地提供要遵循的实际航道的既定航道。因此，默认航道可以是与既定航道一致的到目的地的最短路径，并且然后当超越另一艘船以从左舷通过该船时，更新该虚拟航道。

一般而言，环境可以通过强加通道来结构化或部分结构化。具有动态事件的完全非结构化环境可能意味着与结构化环境相比，导航必须受到严格约束，否则受控元素必须能够相对于事件的发生及其自身的动态能力极其快速地做出反应。

总之，通道表示对应于有限数量的行动——即通道操纵以及相应地有限数量的通道子条件——的环境的结构化和离散化。

优点。使用有通道结构的动态环境进行基于规则的自动化控制的第一个关键优点是快速反应时间。利用快速规则条件评估，系统可以提供快速反应时间。使用规则条件的表格表示和合适的硬件/软件支持，似乎可以在远小于250毫秒内实行规则条件评估，因此提供优于正常人类反应时间的反应时间。因为消除了本地规划，因此在发生意外/动态事件时不会引入延迟，否则会使任何本地计划无效。在本地规划被消除的情况下，在动态事件发生之后，完全“理解”当前场景不存在延迟。规则条件评估方法对众多优化开放，以使得评估既快速又高效。相比之下，依赖于复杂的感知、预测和约束评估的本地规划计算加速起来似乎更具挑战性。

第二个关键优点是，可以预先验证有通道结构的规则集，以响应于任何子条件集来选择至多一个操纵，因此不需要像常规RBS中那样的所谓的冲突消解。也不需要基于采取行动而立即重新评估规则集，因为与一般RBS的行为不同，这些行动对子条件没有直接影响。

第三个关键优点是，基于将行动限制为通道操纵，并且将规则条件限制为关于通道子条件的逻辑表达式，通道结构化导致了简化的规则集。这种通道结构化的简化也意味着自动动态导航更易于理解、可预测和可解释。对于后者，一个或一系列操纵可以追溯到引起每个操纵的一个或多个规则。

作为一种基于规则的方法，使用有通道结构的动态环境进行基于规则的自动化控制具有RBS的所有优点，即可预测的可解释行为。这也意味着系统可以检测到何时没有规则匹配、何时车辆不“理解”当前场景。在这种情况下，正确的行动是要通知操作员，并且可能地采取一些预防行动，诸如让车辆安全停车。也就是说，由于进行了基于规则的决策，系统可以知道它何时不知道。此外，可以基于相对于规则集条件的不匹配场景来列举那些情况。相比之下，基于概率/统计的方法(诸如所谓的机器学习(ML))并不提供这种关键属性。

这种方法的关键缺点是它需要将环境结构化成通道。因此，它无法处理非结构化环境。然而，在许多实际应用中，环境已经被结构化成通道。大多数物理车辆在道路上行进，并且在那里，道路系统被结构化成车道。在医学治疗、股票交易和其他应用中也存在逻辑通道。而且，在一些情况下，当环境未预先结构化成通道时，车辆子系统可以将通道强加于非结构化环境。

环境的通道结构化很重要，因为没有通道，环境就是非结构化的，因此该车辆和其他车辆可能实行的可能操纵的数量就是无限的，因此规则条件的数量是无限的，并因此实现起来不可行。

图13A是图示了使用有通道结构的动态环境进行基于规则的自动化控制的过程的实施例的流程图。在一个实施例中，由图1的系统执行图13A的过程。

在步骤(1302)中，输入规范。图13B是规范的图示。在一个实施例中，图13B的图示是图13A(1302)的规范的一部分。该规范包括：

·在受控系统(1322)的环境中的多个通道，包括它们的邻接，例如，图2中自主车辆应用中的车道(210)、(214)、(216)，或图3A中股票交易应用中的通道(304)、(306)、(308)，或者是图3D中医学应用中的通道(354)、(356)、(358)。在一个实施例中，在“开发时间”指定通道操纵、子条件、规则集、通道和邻接。在一个实施例中，在“开发时间”和/或“编译时间”指定通道操纵、子条件和规则集，而具体通道及其邻接取决于情况(例如，车辆所在位置和/或行驶位置)在“运行时间”加载，以提高效率；

·与多个通道相关联的多个通道操纵/规则行动(1324)，例如，在图4中加速(408)、切换到相邻车道(412)、(414)或减速(410)；

·与受控系统(1326)相关联的多个通道子条件/规则条件，例如，在图4中，自主车辆(402)的子条件为在相邻车道上没有车辆的情况下处于五车道单向道路的中间车道上；以及

·一个或多个规则集，每个规则集包括多个规则(1328)，其中，规则集中的规则指定规则条件以及当满足规则条件时要采取的规则行动，其中，规则条件包括对应的通道子条件集，并且其中，规则行动包括对应的通道操纵，例如，在图4中，规则指示当路线引导指示驶离并且相邻车道上没有车辆时，自主车辆可以操纵至右相邻车道(414)。

在步骤(1304)中，动态地自动导航受控系统。图13C是图示了动态自动导航的过程的实施例的流程图。在一个实施例中，图13C的流程图是图13A的步骤(1304)的一部分。在步骤(1342)中，监控多个通道子条件，例如，通过针对诸如“noVehicleInAdjacentLanes”之类的子条件的改变轮询一组子条件，或者使用更多的中断驱动逻辑，诸如当状态改变时(诸如车辆驶入相邻车道)使传感器中断。在步骤(1344)中，评估与规则集中的多个规则相关联的规则条件，以确定已满足其对应规则条件的一个或多个规则。评估可以周期性地进行或响应于状态改变而进行。在步骤(1346)中，执行与一个或多个所确定的规则相对应的一个或多个通道操纵，例如，在图4中，规则指示当路线引导指示驶离，并且在相邻车道上没有车辆时，自主车辆可以操纵至右相邻车道(414)。

在一个实施例中，自动导航进一步包括：从受控系统的环境接收一个或多个输入；并且响应于接收到一个或多个输入，动态地更新多个子条件的状态。输入的示例可以是前方汽车的微波雷达、车道标志的相机传感器输入、和/或自主车辆后面对象的激光雷达。状态可以是对象是否紧跟在自主车辆后面，这对于自主车辆倒车以进行侧方停车时的更新可能很重要，使得自主车辆制动以避免从车辆后面的动态对象上碾过。

在一个实施例中，多个通道子条件中的通道子条件的表示包括：具有多个状态中的一个的值，并且其中，多个状态包括“无关”状态，其中另一状态为“假”或“真”。在一个实施例中，值由单个位表示。在一个实施例中，值由单个位表示，并且ANDN硬件指令被用来以高效的方式匹配两个值，从而匹配通道子条件并且产生通道操纵。在一个实施例中，值由两个位表示。在与两个位比较时，使用一个位的一个好处是存储减半。

在一个实施例中，多个通道中的第一通道与多个通道中的第二通道相邻。多个通道操纵中的通道操纵包括第一通道到第二通道之间的改变。例如，在图4中，自主车辆(402)使用车道操纵(414)在中间车道到右车道之间改变。

在一个实施例中，受控系统的环境是包括离散化有通道结构的环境的受约束环境，其中，受控系统在当前通道上前进或切换到与当前通道相邻的通道。多个通道子条件包括：路线引导子条件。例如，在图5B中，该路线引导子条件提供用于匹配该表格的另一列(527)。多个通道操纵包括可抢占的通道操纵，因为即使正在执行另一个操纵，也可以立即触发新的操纵。例如，可能先前触发了改变到超车道并加速的操纵，但是在该行动完成之前，检测到动态障碍物，这会触发减速并返回行驶车道的操纵。

在一个实施例中，多个通道中的通道是受控系统可以沿其通过的离散化定向路径段。

在一个实施例中，动态地自动导航受控系统包括：控制自驾驶物理车辆的行为(例如，操作)。在一个实施例中，多个通道包括用于驾驶的道路车道。

在一个实施例中，动态地自动导航受控系统包括：控制自动股票交易平台的行为。在一个实施例中，多个通道包括：至少部分地基于不同行业部门中的股票分类的分层通道。例如，在图3C中，初始规则可以是：不允许投资组合在任何单一股票中具有多于其价值的X％的价值，这由通道(324)、(326)、(328)表示。增加股票仓位或选择购买数额的规则可能需要避免让数额超过投资组合价值的此X％。然而，如果一只股票的价值显著上升、或投资组合中其余部分的价值显著下降，则有可能再次超过此X％阈值，并且需要纠正措施。

在一个实施例中，动态地自动导航受控系统包括：控制自动医学诊断和治疗应用的行为。在一个实施例中，多个通道包括：表示医学治疗计划的通道。例如，在图3D中，医学应用(352)当前可能处于“阿司匹林治疗方案”通道(354)中，其中可能的通道操纵是在第二通道操纵进入“芬太尼治疗方案”(360)之前切换到“无治疗方案”(356)。

在一个实施例中，以不同的表示接收规则集，其中，不同的表示是以下各项中的至少一个：代码实现和编译表格，其中每个可观察子条件具有一列，并且每一行与操纵相关联。

虽然出于理解清晰的目的已经对前述实施例进行了比较详细地描述，但是本发明并不局限于所提供的细节。存在实现本发明的许多替换方法。所公开的实施例是说明性的而不是限制性的。

Claims (22)

1.一种用于基于规则的自动化控制的方法，其包括：

输入规范，包括：

受控系统环境中的多个通道；

与所述多个通道相关联的多个通道操纵；

与所述受控系统相关联的多个通道子条件；以及

包括多个规则的规则集，其中，所述规则集中的规则指定规则条件和当满足所述规则条件时要采取的规则行动，其中，所述规则条件包括一组对应的通道子条件，并且其中，所述规则行动包括对应的通道操纵；以及

动态地自动导航所述受控系统，包括：

监控所述多个通道子条件；

评估与所述规则集中的多个规则相关联的规则条件，以确定已满足其对应的规则条件的一个或多个规则；以及

执行与一个或多个所确定的规则相对应的一个或多个通道操纵。

2.根据权利要求1所述的方法，其中，自动导航进一步包括：

从所述受控系统的环境接收一个或多个输入；以及

响应于接收到所述一个或多个输入，动态地更新所述多个子条件的状态。

3.根据权利要求1所述的方法，其中，所述多个通道子条件中的通道子条件的表示包括具有多个状态之一的值，并且其中，所述多个状态包括“无关”状态。

4.根据权利要求3所述的方法，其中，所述值由单个位表示。

5.根据权利要求3所述的方法，其中，所述值由单个位表示，并且使用ANDN硬件指令来匹配两个值。

6.根据权利要求3所述的方法，其中，所述值由两个位表示。

7.根据权利要求1所述的方法，其中，所述多个通道中的第一通道与所述多个通道中的第二通道相邻。

8.根据权利要求7所述的方法，其中，所述多个通道操纵中的通道操纵包括第一通道到第二通道之间的改变。

9.根据权利要求1所述的方法，其中，所述受控系统的环境是包括离散化有通道结构的环境的受约束环境，其中，所述受控系统在当前通道中前进或切换到与当前通道相邻的通道。

10.根据权利要求1所述的方法，其中，所述多个通道子条件包括路线引导子条件。

11.根据权利要求1所述的方法，其中，所述多个通道操纵包括可抢占的通道操纵。

12.根据权利要求1所述的方法，其中，所述多个通道中的通道是所述受控系统可以沿其通过的离散化定向路径段。

13.根据权利要求1所述的方法，其中，动态地自动导航所述受控系统包括：控制自驾驶物理车辆的行为。

14.根据权利要求13所述的方法，其中，所述多个通道包括用于驾驶的道路车道。

15.根据权利要求1所述的方法，其中，动态地自动导航所述受控系统包括：控制自动股票交易平台的行为。

16.根据权利要求15所述的方法，其中，所述多个通道包括：至少部分地基于不同行业部门中的股票分类的分层通道。

17.根据权利要求1所述的方法，其中，动态地自动导航所述受控系统包括：控制自动医学诊断和治疗应用的行为。

18.根据权利要求17所述的方法，其中，所述多个通道包括：表示医学治疗计划的通道。

19.根据权利要求1所述的方法，进一步包括：接收采用不同的表示的规则集，其中，所述不同的表示是以下各项中的至少一个：编译表格和代码实现。

20.根据权利要求1所述的方法，其中，规范进一步包括：一个或多个附加规则集。

21.一种用于基于规则的自动化控制的系统，其包括：

被配置成接收规范的接口，包括

受控系统环境中的多个通道；

与所述多个通道相关联的多个通道操纵；

与所述受控系统相关联的多个通道子条件；以及

包括多个规则的规则集，其中，所述规则集中的规则指定规则条件和当满足所述规则条件时要采取的规则行动，其中，所述规则条件包括一组对应的通道子条件，并且其中，所述规则行动包括对应的通道操纵；以及

处理器，其被耦合到所述接口并且被配置成至少部分通过以下方式动态地自动导航所述受控系统：

监控所述多个通道子条件；

评估与所述规则集中的多个规则相关联的规则条件，以确定已满足其对应的规则条件的一个或多个规则；以及

执行与一个或多个所确定的规则相对应的一个或多个通道操纵；以及

存储器，其被耦合到所述处理器并且被配置成向所述处理器提供指令。

22.一种在其上存储计算机程序指令的计算机可读存储介质，当由处理器执行时，所述计算机程序指令使得处理器：

输入规范，包括：

受控系统环境中的多个通道；

与所述多个通道相关联的多个通道操纵；

与所述受控系统相关联的多个通道子条件；以及

包括多个规则的规则集，其中，所述规则集中的规则指定规则条件和当满足所述规则条件时要采取的规则行动，其中，所述规则条件包括一组对应的通道子条件，并且其中，所述规则行动包括对应的通道操纵；以及

至少部分地通过以下方式动态地自动导航所述受控系统：

监控所述多个通道子条件；

评估与所述规则集中的多个规则相关联的规则条件，以确定已满足其对应的规则条件的一个或多个规则；以及

执行与一个或多个所确定的规则相对应的一个或多个通道操纵。