本申请对2017年11月30日提交的、题为automaticrootcauseanalysisusingternaryfaultscenariorepresentation的、申请号为62/592,797的美国临时专利申请要求优先权，所述美国临时专利申请通过引用被并入本文中用于所有目的。
背景技术：
：：系统可能有众多故障源，范围从装备故障到计算机硬件故障到软件故障到操作者失误。在复杂的系统中，在互连的组件之间存在许多相关性。用于监控系统的机制可能也同样地遭受故障。由于相关性，一个组件的故障可能导致另一个表明故障状况和/或征兆。级联的故障可能导致大量警报，使得确定根本原因故障的任务相当困难。如本文中所谈及的，这些额外的警报是根本原因故障的“征兆”。对于自动化根本原因分析的现有技术途径已经尝试通过寻找故障之间的统计相关性来找到根本原因，假定强相关的故障是根本原因。然而，相关性可能不表明因果关系。另一有关的统计途径是要使用机器学习技术来“识别”不同的故障场景。然而，该途径的可靠性是低的，除非经标注的训练集合的非常大的采集是可用的，这可能是昂贵和/或不实际的。附图说明在以下详细描述和附图中公开本发明的各种实施例。图1是一功能图解，其图示了根据一些实施例的用于通过使用三元故障场景来进行自动根本原因分析的经编程的计算机/服务器系统。图2是征兆的故障场景向量的图示。图3是根本原因表（rct）的图示。图4是已知（known）和值（value）位的64位块表示的图示。图5a是根本原因分析技术的图示。图5b是rct层次的图示。图6是图示了被监控的系统的实施例的框图。图7是一框图，其图示了用于通过使用三元故障场景表示来进行自动根本原因分析的过程的实施例。图8是一框图，其图示了用于置信度和多个实际故障场景的过程的实施例。具体实施方式本发明可以用众多方式来被实现，包括被实现为过程；装置；系统；物质的组成；在计算机可读存储介质上具体化的计算机程序产品；和/或处理器，诸如被配置成执行在耦合到处理器的存储器上所存储的和/或由该存储器所提供的指令的处理器。在本说明书中，这些实现方式、或本发明可以采取的任何其它形式可以被称为技术。通常，所公开的过程的步骤的次序可以在本发明的范围内变更。除非另行声明，否则诸如被描述为被配置成执行任务的处理器或存储器之类的组件可以被实现为在给定时间临时被配置成执行该任务的通用组件或被制造成执行该任务的特定组件。如本文中所使用的，术语“处理器”是指被配置成处理数据、诸如计算机程序指令的一个或多个设备、电路和/或处理核。本发明的一个或多个实施例的详细描述在以下连同图示发明原理的附图一起被提供。结合这样的实施例来描述本发明，但是本发明不限于任何实施例。仅仅通过权利要求来限制本发明的范围，并且本发明涵盖众多可替换方案、修改和等同物。在以下描述中阐明众多特定细节以便提供对本发明的透彻理解。这些细节被提供用于示例的目的，并且本发明可以根据权利要求、在没有这些特定细节中一些或全部的情况下被实践。为了清楚的目的，在与本发明有关的
技术领域：
：中已知的技术材料没有被详细描述以便不会不必要地使本发明模糊。公开了使用三元故障场景的自动根本原因分析。“征兆”在本文中被称为被监控的系统的某个组件的、对于将一个故障场景与另一个区别开而言重要的经命名和/或定义的状态。公开了使用征兆值，所述征兆值对应于与未知的征兆值对应的“未知”值，以及“不用在意”值，所述“不用在意”值也被称为与对于特定分析而言不需要的征兆相对应的没有关联的值。在一个实施例中，每个征兆值被限制为以下中的一个：真、假、或未知。因而，征兆值在本文中被称为“三元”值。在一个实施例中，“未知”和“不用在意”值由相同的值指明，基于使用上下文而被区分为一个或另一个。图1是一功能图解，其图示了根据一些实施例的用于通过使用三元故障场景来进行自动根本原因分析的经编程的计算机/服务器系统。如所示的，图1提供了根据一些实施例的被编程为提供自动根本原因分析的通用计算机系统的功能图解。如将显而易见的，其它计算机系统架构和配置可以用于自动根本原因分析。包括如下所述的各种子系统的计算机系统100包括至少一个微处理器子系统，所述微处理器子系统也被称为处理器或中央处理单元（“cpu”）（102）。例如，处理器（102）可以通过单芯片处理器或通过多个核和/或处理器被实现。在一些实施例中，处理器（102）是控制计算机系统100的操作的通用数字处理器。通过使用从存储器（110）检索的指令，处理器（102）控制输入数据的接收和操纵，以及在输出设备、例如显示器和图形处理单元（gpu）（118）上的数据的输出和显示。处理器（102）与存储器（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）说明用于链接子系统的任何互连方案。还可以利用具有不同子系统配置的其它计算机架构。概览。如上所述，复杂的受监控的系统可以具有众多故障源，并且甚至用于监控这样的系统的机制也遭受故障。例如，监控制冷系统的温度传感器可能永久地或间歇地出故障，其指示被监控系统的不恰当温度。组件相关性可引入另外的复杂性，例如，制冷系统中的冷却线圈取决于压缩机的正确操作以提供浓缩的制冷剂。这些相关性起因于这些组件的互连。如上所述，一个组件的故障可能导致另一个表明故障状况/征兆。因此，当一个组件有故障的时候，它可能导致依赖于出故障组件的组件中的级联故障，使得确定实际根本原因故障的任务是困难的。在一些情况中，在被提供给操作者的警报之中可能甚至不存在根本原因。例如，如果在两个计算机网络交换机之间线缆出故障，可能存在来自线缆任一端的交换机的一大批警报。然而，通常没有直接指示线缆断开的警报，因为直接地在线缆上没有能够检测线缆破损的传感器。还可以在多层中实现复杂的系统，从而创建另一相关性集合。这些层相关性是另一警报源。例如，以上线缆故障可引起输送层指示它有会话定时失效，因为没有接收到任何应答。类似地，ip层处的误配置可能使得生成tcp/输送层和路由层处的警报。传统地，这些额外的警报被称为根本原因故障的征兆。将大量这些征兆生成为警报使得确定实际根本原因更困难。尝试使用故障之间统计相关性的传统途径假定强相关故障是根本原因，但是如以上所指出的，相关性可能不指示因果关系。使用机器学习技术来“识别”不同故障场景的有关的统计途径需要使得经标注的训练集的较大采集是可用的。此外，这些训练集特定于系统的特定配置和部署，因为为每个部署提供足够大训练数据集是昂贵和/或不实际的。此外，这些途径不允许系统的认知被并入，除了可能地通过经标注训练数据的广泛使用之外。特别地，在工程系统中，操作的原理、组件之间的相关性以及潜在根本原因故障及其征兆一般作为设计过程的部分已知，但不可通过机器学习途径被利用。通过在不需要使用故障之间统计相关性或不实际/高成本大训练数据集的情况下使用高效征兆匹配，公开了一种高效的方式来对以下进行编码：对于工程系统、作为其工程设计的结果而已知的操作原理、相关性和因果关系以及潜在根本原因。该效率降低存储成本和/或减少处理器功耗以便确定根本原因分析。该高效方式允许自动地且高效地执行根本原因分析。征兆和故障场景。图2是征兆的故障场景向量的图示。征兆的一个示例，无功率，是指示没有功率来到被监控系统的征兆。征兆的状态可以是已知值或特殊指示，它是未知的和/或不用在意的。术语“不用在意”通常使用在数字逻辑中以指示相关联的项是没有关联的/不需要的。使得处理为给定征兆指示“不用在意”的能力允许分析进行，甚至是在系统状态的那方面并不实际已知的时候。“故障场景”在本文中被称为征兆值集合，其指示所监控系统的已知和未知的故障状态。逻辑上，故障场景表示从所观察/确定的系统有点不对劲或没有不对劲的征兆的立场的系统的状态和/或潜在部分状态。它可能不指示系统的全状态。例如，在车辆的情况下，故障场景可能不一定指示车辆的定位、速度等等，仅仅指示征兆的状态，即，执行故障根本原因分析所需要的方面。如图2中所示，在一个实施例中，故障场景被表示为值的数组（202），其中每个条目（204a-m）对应于所指定的征兆。例如，征兆sy0(204a)是第一条目，征兆sy1（204b）是第二条目，等等。在一个实施例中，可以存在与相同度量相关联的多个征兆。例如，可以存在对于温度传感器的不同征兆，即微高、中高以及极高。在一个实施例中，可以存在与相同度量相关联的、基于不同级导数的征兆。例如，征兆可以相关联于具有太长久为零的一阶导数、即恒定的度量，通常指示输入传感器已经出故障。征兆可以相关联于太高的一阶导数，意味着它改变得太快速。可以存在与度量相关联的附加征兆，其指示该度量在范围外或表现得不恰当。在该情况中，例如，与征兆指示度量太高或太低的同时设置范围外征兆。征兆的该“聚合”形式可以允许在“范围外”方面指定故障场景，而不是必须覆盖“太低”和“太高”二者。在两个故障场景s0和s1之间定义匹配操作符以如果有如下情况则返回真：boolismatching=match(s0,s1);如果s0中的每个征兆条目要么是不用在意，要么否则与s1中的对应条目中的值匹配。注意到，匹配操作不是可交换的，match(a,b)可能不一定等同于match(b,a)。根本原因表。图3是根本原因表（rct）的图示。rct是一表，其中每行是标注有相关联的根本原因的故障场景。在该上下文中，针对这样的故障场景中的征兆的未知值被解译为“不用在意”。例如，对于根本原因“坏掉的发动机”，该行中的征兆可以是：“无功率”为假，“发动机不运行”为真，并且所有其它征兆被指示为“不用在意”。在一个实施例中，rct包含对于可以是根本原因的每个故障或事件的一行，其中每行指示对于这是根本原因必须为真的征兆、必须为假的那些，以及如指示不用在意的其余集合。注意到，将更多的征兆指定为特定值，而不是超出对于给定根本原因的绝对最小值的不用在意，可能导致根本原因不被标识或匹配，因为额外的征兆可能不是已知的，或与针对该行所指定的那个相反。因此，重要的是指定对于将系统诊断为与表中该行相关联的特定根本原因所需要的已知征兆的最小集合。如果给定根本原因可具有多个征兆标识集合，则在rct中存在多行，因为每个集合一行。给定根本原因可具有多个对应的行，因为一行对应于最小征兆集合，并且其他行对应于具有附加征兆的最小集合，所述附加征兆提供根本原因中的较大置信度。例如，在对交换机的功率供给故障的情况中，最小集合可以仅仅包含来自交换机当前传感器的“功率丢失”征兆，而附加的行可以包含该征兆加上来自对于出故障交换机的直接附连的交换机的“信号丢失”征兆。在一个实施例中，以与故障场景相同的方式表示每个rct行。因而，它在本文中可以被称为“潜在故障场景”。如图3中所示，rct（302）包括k+1行（304a-304l），与特定根本原因相关联的每一行每行具有n个征兆。例如，根本原因#0相关联于第一行（304a）。每行（304a）中的征兆（204a-m）的值不同于其它行（304b-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]相同地被对待，和/或不被允许。图4是已知（known）和值（value）位的64位块表示的图示。在一个实施例中，故障场景被表示为位块，其被分区成“已知”位的序列和值位的序列。例如，如图4中所示，一实现方式使用64位块，其中前32位是“已知”位，并且其次32位是值位。参考图4，如果第i已知位是1，则第i值位指示对应的征兆是真还是假；否则实际值不是已知的，并且第i值位不是有意义的。该实施例允许高效确定块中的“已知”位。它还意味着：如果块中的所有征兆是未知的或不用在意的，则不需要存储块。也就是说，不存在块的显式存储被解释为该块仅仅包含“不用在意”值。根本原因分析。图5a是根本原因分析技术的图示。通过如下来确定与给定实际故障场景（502）相关联的实际根本原因：使用匹配引擎（504）来对照rct（302）中的每一行而匹配给定的实际故障场景，并且将匹配的那些指示为很可能的根本原因。也就是说，如果故障场景与一行匹配使得每个条目通过以上的match(a,b)操作符而匹配，则与该行相关联的根本原因被输出为与该征兆相关联的很可能的根本原因（506），如图5a中所示。该匹配本质上是“三元匹配”，但是不像三元内容可寻址的存储器（t-cam）所提供的三元匹配，输入故障场景也是三元的。然而，t-cam可以被用作匹配的高效/硬件系统的部分。在所监控的系统中可能存在多个同时的根本原因故障。因此，可能的是进行的匹配与rct中的多行匹配，每个根本原因一个。例如，在温度传感器通过指示完全不现实的读数而已出故障的同时，发动机可能出故障。可存在映射到相同根本原因的多行。这处置以下情况：在所述情况中，可以通过不同的征兆集合来指示根本原因故障。在一个实施例中，行表示不显式地存储“不用在意”条目。也就是说，不存在第i征兆的显式指定或表示被解释为对于第i征兆的不用在意。在一个实施例中，征兆被聚合到与所监控的系统的逻辑单元或组件相关联的块中。例如，实施例可以使用较早前描述的已知/值位的64位块。因而，如果组件与特定根本原因不相关，则不需要存储整个块。每行于是可需要相对小量的存储。典型地，大多数行是相对稀疏的，因为仅仅小的征兆子集与特定故障相关，因此，该行的仅仅小的百分比被实际存储，其中其余的默认是不用在意。通过使用多个征兆来实现任意故障准则的表示。例如，一个根本原因由温度非常高证明，又一个根本原因通过温度高被证明，并且另一个通过温度微高被证明。也就是说，对于这些级别中的每一个，每一行中可以存在征兆条目。关键的要素指示已知作为征兆为假的征兆，即无故障，以及已知为真的内容，即故障存在，而同时仍允许未知或不用在意。为假的情况实际上滤出由于另一原因所致的征兆，例如压缩机不运作，但是实际上没有功率，这是根本原因。因而，取决于多个其它子系统的子系统ssi可能需要在子系统ssi中的故障可以可靠地被标识为根本原因之前使所有这些其它系统已知为运作。在一个实施例中，系统可以记录任何征兆自从其上一次匹配以来在实际故障场景中是否改变，并且仅仅在如果是改变了的情况下将该实际故障场景重匹配到rct（302）。该检查避免在没有对于实际故障场景的改变的时候的重匹配的开销。在一个实施例中，根据应用需要，重匹配的频率是可配置的。例如，自动根本原因分析（arca）匹配在制冷系统中可以被配置成每30分钟被执行，以最小化匹配的成本，因为故障不导致即时问题，并且结果导致的在检测故障中的延迟不显著影响修复的间隔时间。这种低匹配速率假定如下故障不是关键要检测的：所述故障足够短暂地出现并且然后在匹配发生之前消失，并且因而在匹配时的实际故障场景中不存在。rct层次。图5b是rct层次的图示。在一个实施例中，可以存在对应于根本原因分析的不同级别的rct层次。例如，制冷系统rct（302）可以被分区，使得它具有顶级rct（552），所述顶级rct对系统不是良好执行的高级别原因“根本上定因”，其可以是以下中之一：1）没有维持期望的温度，以及2）消耗过度的能量。一旦该顶级rct（552）指示了这些原因中的一个，监控和对应rct（554）的下一级别可以取决于特定原因被自动部署，从而为顶级根本原因提供更特定的根本原因。例如，如果对于不良好执行的顶级根本原因是过度能量消耗，则附加的遥测和分析可以被部署以检测如下征兆：低量冷却剂、冷却线圈上的结冰、压缩机的过度循环、电流传感器的故障、以及过度能量消耗的其它可能的根本原因。该下一级别根本原因可足以指示对系统的必要修复。可替换地，基于在该第二级别确定的根本原因，可以自动分派下一级别的rct（554）和处理。该分层次的处理可以减少在其中系统正常运作的情况中由根本原因分析所消耗的资源。它还可以减少对于为特定故障根本上定因所需要的资源，如果下一级别的根本原因分析基于较高级别的根本原因的指示而仅仅需要处置可能的征兆的子集的话。例如，通过使用制冷系统的以上情况，已知该系统情况下的问题是过度功率消耗，实际部署的下一级别根本原因分析处理可要求与被配置成检测维持所配置温度以及过度功率消耗这二者故障的此级别的根本原因分析相比的较小的rct（554）以及较少的遥测与处理。可替换地，如果两个顶级征兆都出现，则可能没有这样的节省。然而，可行的是将并行的该详细根本原因分析的两个实例运行为分离的过程，这是时间高效的。通常，根本原因分析匹配可以被并行地执行，这通过跨多个并行线程来对rct分区并且收集每一个的输出。由于匹配不修改实际的故障场景或rct，并且由于匹配是跨行而次序无关的，所以在线程之间所需的唯一的同步是在对聚合的根本原因集合的输出上。多层、分区以及该分层次的途径显著减小rct的大小。例如，在网络应用中，如果较高级别的rct、诸如基本连接性仅仅考虑每网络节点四个征兆，而不是256个，则rct在大小方面可以减小到大约1/64。该大小可以通过在基本rct中仅仅具有粗粒度的根本原因而进一步减小。例如，对于链接的大量特定问题可以在该级别通过简单的“链接问题”被处置作为根本原因，其在被标识的时候可以引起更详细arca的分派，使用可能的特定链接问题的全集合。除了缩减在其中不存在任何故障的常见情况中需要被主动访问的rct的大小之外，该较小的rct处理起来更高效。而且，在大小方面的足够缩减的情况下，故障场景向量可以潜在地拟合于硬件t-cam，使得匹配可以在硬件中进行。在一个实施例中，其中存在用于根本上定因的多个类似的独立单元，诸如在hvac应用的情况中具有多个屋顶单元（rtu），单个rturct可以用于将对于每个分离的rtu的故障场景向量顺序地传递到t-cam中，以在每个rtu中检测故障。这样的分层次途径的益处是预期基本arca是常见情况，即当装备恰当执行的时候，因此t-cam可以是在非常高效地处置常见情况，并且详细的arca可以被预留用于当实际存在问题的时候。另一益处是分层次途径所允许的更基本的arca可以意指当不存在任何故障的时候收集较少的遥测，这再次可以是常见情况。因而，例如使用t-cam或等同物的硬件实现方式在一些应用中是实际的和有吸引力的，所述t-cam或等同物可以当前通过使用sram来被实现。将度量映射到实际故障场景。图6是图示了被监控的系统的实施例的框图。所监控的系统（602）耦合到传感器（604），包括传感器0（604a）、传感器1（604b）、传感器2（604c）等等。“遥测系统”（606）周期性地经由传感器（604）从诊断下的系统或所监控的系统（602）收集各种度量。例如，通过连接到所监控的系统（602）上的温度传感器（604），遥测系统（606）可以反复轮询该传感器以产生温度读数的时间序列。度量映射（608）是将这些度量映射到实际故障场景（502）上的装置。存在多个度量映射，例如度量映射0（608a）、度量映射1（608b）等等（608y）。每个度量映射（608）取针对一个或多个度量的值的加时间戳的序列作为输入，并且将这些值映射到实际故障场景（502）中的零个或多个征兆上。如图中所示，这是从所监控的系统（602）通过传感器（604）到遥测系统（606）的映射，所述遥测系统然后将值提供到相关联的度量映射（608），所述度量映射然后更新实际故障场景（502）。在一个实施例中，针对给定度量的读数的时间序列流可以基于所指定的阈值和相关联的征兆而被映射到征兆上。例如，如果温度（604）超过一个指定的阈值，则映射（608）使得“温度/微高”征兆（例如204a-m）在实际故障场景（502）中被设置为真。如果该值（604）超过另一个甚至更高的阈值，则映射（608）使得“温度/非常高”征兆（例如204a-m）在实际故障场景（502）中被设置为真。在这两种情况中，相同的映射（608）还可以设置“温度/范围外”征兆（204a-m）。在一个实施例中，该映射（608）被周期性地执行，由可配置的时钟时段来驱动。例如，系统可以每5秒对照阈值映射的相关联的度量来评估所述阈值映射（608）中的一些或全部。在一个实施例中，度量可以指示其值（604）自从先前的时钟时段以来是否已经改变。在该情况中，与度量相关联的映射（608）仅仅在下一时段上、对于自从先前的时段以来已经改变的度量而被重评估。在一个实施例中，对于度量的映射（608）直接响应于相关联的度量（604）中的改变而被评估。然而，在一些情形中，度量可迅速改变，并且通过重评估对每个改变的响应可能是昂贵的。系统和应用中的重要设计考虑是能够在不同条件下、特别是在压力和故障的时间期间、当额外的资源需求可能导致另外的故障的时候限制系统的监控和分析的计算资源需求。度量映射（608）还可以基于相关联的度量的导数来设置征兆。例如，映射可以设置“温度/传感器故障”征兆，如果该度量的一阶导数是零、即该值在过量的时间段上是恒定的话。在一个实施例中，机制被配置成修改在度量映射（608）中所使用的阈值和其它参数值。例如，度量映射（608）可以提供在系统上负载方面被参数化的阈值，认识到：当系统在显著负载下的时候，度量可以合理地处于较高的值。相比于作为其分析的部分而执行复杂且通常应用特定的比较的传统手动根本原因分析，公开了对照阈值而强制度量评估。该强制度量评估作为向实际故障场景（502）的度量映射的部分而发生，从而允许故障场景中的征兆被表示为简单的三元值/向量。因此，对照rct中潜在故障场景的收集而匹配实际故障场景的根本原因分析部分是应用无关的。这允许紧致的表示，其使能对于高效arca的高效故障场景匹配。直接报告的度量。相对于所计算的度量一些度量由所监控的系统（602）上的传感器（604）或监控器直接报告。例如，网络交换机可以报告在上一时间间隔上的每接口的包传输计数。然而，其它度量可能需要根据直接报告的度量（604）来被计算。例如，一个度量可以是给定接口上的传输包速率相比于跨所有其它接口的平均值的标准偏差。所计算的度量和直接报告的度量这二者都可以使用在向实际故障场景的度量映射过程（608）中。其它应用领域。在具有对于操作原理和系统相关性充分了解以及充足定量遥测的情况下，所公开的可以被应用到除了复杂工程系统之外的应用领域。例如，医学已经开发了关于人体如何运作、相关性、潜在故障和结果产生的征兆的广泛知识体系。尽管身体本身没有工程化，但是它在某种程度上被理解的物理原理上运作。此外，监控技术在改进，从而甚至在医院环境外部也提供对身体的持续的和更详细的监控。例如，某些“智能手表”可以感测身体温度、心率、血压和身体运作的其它方面。在这些改进的情况下，图6的技术和/或系统可以被配置和部署以提供人体故障的快速根本原因分析。在一些情况中，诊断取决于实际上需要图像处理的x射线和cat扫描。在这些情况中，经由图像处理的对图像的自动和/或机械解译可以用于计算度量/征兆以与故障信息和其它输入融合以执行根本原因分析。应用的另一领域是检测系统中的侵入检测。在一些情况中，可以基于对以下的认知来构造rct：侵入者利用，以及可能由所述利用引起的结果产生的征兆是什么。该分析进而可以驱动对于遥测的需要。例如，遥测可以指示系统日志的大小以及日志轮转行为，并且从而检测何时侵入者尝试通过截断或替换现存系统日志来掩蔽其存在。在该领域中，侵入者还可以尝试中断遥测系统，但是这作为基本传感器故障被处置，类似于较早前描述的内容，其基于以下假定：对于侵入者而言足够快速地使足够的遥测系统中断以避免检测将不会是可行的。利用有关技术。三元值已经被使用在电路逻辑中，其中例如状态转变函数可以将其输入指定为真、假和不用在意。电路逻辑与根本原因分析不相同：电路逻辑中的不用在意实际上是如与为仅仅具有相同输出的两个值指定表行相比压缩规范的手段，并且输入总是已知的。类似地，t-cam已经用于三元匹配，其中t-cam字段可以被指定为不用在意，再次作为如与指定根本原因分析中值的每个可能的组合相比压缩所需条目的数目的手段。数据库语言sql具有被视为未知的null值，但是数据库不直接支持自动根本原因分析。传统地，决策树已经被用作执行根本原因分析的手段。然而，计算中的决策树简单地是“如果-于是-否则（if-then-else）”声明的嵌套集合。不像本文中公开的内容，这些传统技术不一定具有标准的或全系统的起始条件用于评估。而且，考虑到同时可能存在多个根本原因故障，可能不一定存在遵循遍历决策树的单个途径。同样地，考虑到某些条件或变量可能是未知的，当执行有可能在决策树中遇到依照某个未知值的条件的时候，不清楚如何使序列结构化。决策树情况下的一个其他的差异是：其固有的“如果-于是-否则”结构对于现实系统可能变得不合理地复杂，并且因而维护和扩展起来非常昂贵和困难。传统地，一些途径是基于规则的。计算中的规则通常被表征为条件和动作，其中arca情况中的动作是报告根本原因，或否则评估又一条件。因此，基于规则的系统基本上等同于“如果-于是-否则”途径，具有所有上述差异。不像本文中公开的内容，可能存在并且通常存在不同规则表述上的显著重叠，使得它可能非故意地引起显著量的冗余计算以及重计算，除非规则执行引擎足够复杂以检测和提取常见的子表述。相反，通过使用本文中所公开的内容，评估可以每时间/实例间隔进行一次，从而映射到实际故障场景中，其中rct的每行执行一次匹配。传统地，一些途径发现统计相关性，例如，如果在与出现各种其他征兆的同时cpu负载上升，则cpu负载被假定为根本原因。这将相关性解释为因果关系，其经常无效。例如，两个故障可能仅仅是两个不同模块依赖于的某个组件中的故障的征兆。传统地，一些途径聚焦于异常检测。在该途径下，以低概率发生的事件可以被假定为问题。然而，这可能不一定指示故障。同样，即使它是故障，它也不一定是根本原因。而且，根本原因可能实际上不是直接或间接可观察的，诸如在两个网络接口之间的线缆断开的情况。不像本文中公开的内容，根本原因可能不能通过简单地从所报告的异常之中智能选择而被检测。示例性用例：通用教程。被称为故障场景诊断（fsd）的、在三元故障场景表示的情况下使用arca的软件以教程的形式、无限制地被公开为示例性用例。介绍。fsd软件可以被封装为代理，其对来自数据文件或挂载（mount）的、对诊断下系统（sud）的状态进行反映的输入作出反应；它可以提供该sud中的故障的根本原因分析。它可以根据经配置的rct和征兆集、以及数据输入到该rct上的经配置的映射来执行该根本原因分析。如果有同时存在的多个根本原因故障，则它可以输出多个根本原因。例如，冷却系统可遭受冷却剂泄漏以及压缩机短循环这二者。当没有任何征兆存在的时候，它不输出任何根本原因。它避免报告不是根本原因、而是由其他故障所引起的故障，从而有效地抑制这些作为假阳性。它在许多应用中可以被配置成还检测何时一个或多个传感器本身可能已出故障。例如，如果制冷温度没有在读取期望的温度，则要么是温度传感器已经出故障，要么是制冷系统本身没有在正确运作，或者是这二者。fsd可以被配置成使用压缩机温度和压力来区分这些情况。fsd“哲学”是要鼓励遥测的设计导入（design-in）使能在某事出差错的时候实现快速根本原因分析，这可能出现在生产中。fsd鼓励利用支持该arca的遥测来开发应用，而不是使代码载重有许多错误报告，所述错误报告只能手动处置，并且可能导致相对于根本原因故障的许多假阳性，因为输出模块没有正在发生什么的“重点（bigpicture）”。它还鼓励用于组件的相关模型的显式开发/设计作为应用设计的部分，如对于arca所要求的那样。相反，通常在关于一个故障对系统其它部分的影响的很少思考的情况下设计应用和系统。在fsd的情况下，利用根本原因分析/相关性模型，设计者可以聚焦于提供所需的遥测，从而避免由于不知道需要什么而尝试报告“每件事”的执行负担。fsd至少部分地基于三元要素故障场景匹配。故障场景是针对sud的征兆或非征兆或未知的状态。此处，“要素”在本文中是指以最基本形式指定的征兆，即要么真要么假的征兆。这与以下相对：将它指定为相对于阈值的某个值，或其它类似的复杂表示。如上所述，三元意指：征兆可以被指定为真或假或未知。未知在一些上下文中可以被解释为“不用在意”。fsd根据其输入数据来确定sud故障场景，并且然后对照着构成rct、各自对应于根本原因的故障场景的集合来匹配该实际故障场景。此教程描述了fsd的使用，其以下在fsd使用的基于json的配置方面被结构化和解释。fsdjson配置被指定为四个不同的配置文件：1.征兆和根本原因表配置文件；2.指示符文件；3.指示符映射文件；以及4.输入绑定文件。征兆。如上所述，征兆是对于在不同根本原因故障之间解释清楚而言所需的sud中的状况或状态。它通常是不被认为是正常或可接受的状况。例如，比预期更高的电流消耗是这样的征兆。在rctjson文件的第一区段中定义针对sud的征兆集合。可以为sud中每个设备的每个组件定义分离的特定征兆。例如，在100个交换机的网络中，每个具有32个接口，可以存在为针对这些接口中每一个的crc错误所定义的分离的征兆，即3200个特定征兆。而且，可以存在针对感兴趣的crc错误的每个级别的分离的征兆，即低错误率、中等、和高错误率。因而，在现实网络中，可以存在数千或多于数千个征兆要被定义。如果诊断下的系统包括若干独立但是相同的子系统，则可以存在用于这些子系统的单个rct，并且特定于这些子系统中每一个的实际故障场景可以与rct匹配，要么并行地要么循序地。例如，建筑物可以具有多个rtu，所述rtu从根本原因分析的立场是独立和/或相同的。在该情况中，fsd可以为rtu中的每一个生成实际故障场景，并且对照相同的rct来匹配这些中的每一个。相反，在计算机网络中，作为子系统的交换机不是独立的，而是具有需要每个连接的另一端上的信息以用于准确rca的故障。因此，作为单独的分离的子系统来对这些进行诊断可能不是可行的。在fsd中，特定的征兆可以被定义为往rct的列中的经命名的索引。为了支持大量征兆，一个较好的实践是要遵循以下概述的命名惯例：征兆命名惯例征兆名称可以被结构化为：unitname/componentname/metric/issue(单元名称/组件名称/度量/问题)例如，对于屋顶单元14中的压缩机0，电流消耗很高可以被指明为：rtu14/compressor/current/high(屋顶单元14/压缩机/电流/高)类似地，交换机17上的接口eth4上的频繁链接crc错误可以被指明为：switch17/eth4/link/frequentcrcerrors(交换机17/eth4/链接/频繁crc错误)对于“偶然的”crc错误，对于频繁和偶然的所选概念，征兆可以是：switch17/eth4/link/occasionalcrcerrors(交换机17/eth4/链接/偶然crc错误)征兆的json规范。fsd可以支持征兆的结构化规范，作为定义数千征兆的高效手段。该结构化的规范可以鼓励跨不同组件和单元的对征兆的统一命名。基本结构模型是：•度量类型，其可以定义一个或多个相关联的征兆。例如，“电流”度量可以定义征兆：太低、太高或太恒定，其中太恒定可以可能地暗示传感器故障。这些值中的每一个可以被设置为开始于0的指定的偏移；•组件类型，其可以定义度量列表，其中的每一个被定义为度量类型，其可以呈现与该度量类型相关联的征兆值中的任一个；和/或•单元类型，其可以定义各自是组件类型的实例化的构成组件的集合。更具体地，jsonrct文件格式如下：•度量类型-一集合，其可以定义将在sud的组件的实例化中使用的一组相对索引值和基本征兆名称。例如，温度度量可以具有低、高和恒定的征兆，其中如果它随时间不改变，则它可能指示问题；•组件类型-可以定义组件类型的集合，所述组件类型各自定义度量的集合；•单元类型-可以定义单元类型的集合，所述单元类型各自定义组件的集合；和/或•单元-可以定义单元的集合，各自是单元类型的实例化。fsd可以将该描述扩展成特定征兆的集合，所述特定征兆各自具有其自己的分层次名称以及往rct列中的偏移。例如，对于被称为“foo”的单元，其具有被称为“bar”的组件，所述组件具有被称为“bazz”的度量以及被称为“blat”的问题或征兆，该特定征兆被称为“foo/bar/bazz/blat”。该征兆的偏移于是可以是以度量类型所定义的、相对于针对该单元的征兆块的征兆偏移，其中每个度量被置于分离的块中。在fsd的一个示例中，每个块可以持有多达32个征兆。通常没有理由知道针对征兆的偏移，因为征兆通过其分层次的字符串名被提及。以下是jsonrct文件中的两个度量类型的示例：{"metrictype":{..."generic":{"offset":{"0":"constantreading","1":"low","2":"high"}},"current":{"offset":{"0":"constantreading","1":"verylow","2":"low","3":"high","4":"veryhigh"},...},...}({“度量类型”：{“通用”：{“偏移”：{“0”：“恒定读数”，“1”：“低”，“2”：“高”}},“电流”：{“偏移”：{“0”：“恒定读数”，“1”：“非常低”，“2”：“低”，“3”：“高”，“4”：“非常高”},},})第一个“...”指示：可能存在所定义的附加度量类型。第二个“...”指示可能存在更多的要在该json文件中定义。该示例定义“通用”度量类型以及“电流”度量类型。“通用”度量类型被定义为具有四个征兆，以相对偏移0直到2，其对应于太低、太高和太恒定的读数。恒定读数对应于如下故障：其中电流传感器本身正在太长的时间段中读取相同的值，很可能因为它断开或已经出故障。“电流”度量类型定义5个征兆的扩展集合。任何数目的值可以被定义为与度量相关联。如果度量具有多于设置数目的、例如32个值，则它可消耗多于一个块。fsd可以被配置成在偏移冲突确实由配置状态引起的时候检测和报告所述偏移冲突。以下是fsdjsonrct配置文件中的组件类型定义的示例。"componenttype":{"compressor":{"metric":{"current":{"metrictypename":"current"},"pressure":{"metrictypename":"generic"},"superheat":{"metrictypename":"generic"},"subcooling":{"metrictypename":"generic"},"runtime":{"metrictypename":"generic"}}...},...}...(“组件类型”：{“压缩机”：{“度量”：{“电流”：{“度量类型名称”：“电流”},“压力”：{“度量类型名称”：“通用”},“过热”：{“度量类型名称”：“通用”},“低温冷却”：{“度量类型名称”：“通用”},“运行时”：{“度量类型名称”：“通用”}}},}...)该json定义被称为“压缩机”的组件类型，所述压缩机具有被称为“电流”的、具有度量类型为“电流”的度量，因此具有对应于那些度量的征兆，即非常低、低、高、非常高和恒定读数。它还通过使用“通用”度量类型来为压力、过热、低温冷却和运行时定义度量。可以在第一个“...”处定义针对压缩机的附加度量。可以通过在第二个“...”处插入更多的定义来定义附加的组件类型。第三个“...”允许json文件中更进一步的规范。以下说明“单元类型”定义："unittype":{"rooftopunit":{"metric":{"power":{"metrictypename":"generic"}},"component":{"compressor0":{"typename":"compressor"},"compressor1":{"typename":"compressor"},...}}...(“单元类型”：{“屋顶单元”：{“度量”：{“功率”：{“度量类型名称”：“通用”}},“组件”：{“压缩机0”：{“类型名称”：“压缩机”},“压缩机1”：{“类型名称”：“压缩机”},}}...)这定义“屋顶单元”单元类型，其具有两个组件“压缩机0”和“压缩机1”。它还说明了度量可以直接被定义为“单元类型”的部分，诸如该情况中的“功率”度量。特定的单元可以如下被定义："unit":{"rtu0":{"typename":"rooftopunit"},"rtu1":{"typename":"rooftopunit"},...}(“单元”：{“屋顶单元0”：{“类型名称”：“屋顶单元”},“屋顶单元1”：{“类型名称”：“屋顶单元”},})以上定义了两个单元，即“屋顶单元0”和“屋顶单元1”，它们是“屋顶单元”单元类型的实例化。屋顶单元0的实例化的一个结果是：定义了大量征兆。例如：“屋顶单元0/压缩机0/电流/非常低，”“屋顶单元0/压缩机0/电流/低，”“屋顶单元0/压缩机0/电流/高，”“屋顶单元0/压缩机0/电流/非常高”，以及类似地对于“屋顶单元0”的其它度量，以及类似地对于压缩机1。对于屋顶单元0功率的征兆是：“屋顶单元0/功率/低”，等等。对于“屋顶单元0”的征兆开始于列/偏移32，因为所述征兆被指派给开始于1的块。对于征兆的偏移，没有任何意义。它应当是唯一的，即，不同于任何其它征兆的。为“屋顶单元1”生成类似的征兆集，其中基于起始块是8，起始偏移是256。通常，结构化的征兆规范允许在json的少得多的行中指定对于sud所需的数千征兆。通常不需要知道或计算征兆偏移。仅仅有必要能够确定从单元定义中生成的、依据单元类型、依据按照组件类型定义的、按照度量类型定义的组件的征兆名称。一般的相对于部署特定的征兆。可以存在跨多个部署是公共的度量、组件和单元类型，以及对于特定部署或配置是唯一的度量、组件和单元类型。这二者都在相同的jsonrct文件中被定义，以允许与具有另一分离文件的负担相比的高效fsd初始化。一个假定是：通过可从较高级别文件运作的分离的程序来生成fsd文件，所述较高级别文件将这些分离成更多的类别和文件。例如，在将fsd应用于联网中，分离的程序可以处理为给定的网络拓扑生成征兆和rct。根本原因。根本原因可以被定义为逻辑上是各种征兆的源或原因的状况。也就是说，补救该状况将会治愈这些相关联的征兆。相反，在一些情况中，不存在可以合理被补救以移除相关联征兆的另一状况。根本原因可以被包含在上下文内，或由sud视角定义，而不是必定是某个基本的根本原因。例如，压缩机不工作的根本原因可以被标识为缺功率，而不一定钻研到确切地为什么它没有功率中。从功率系统的视角，缺功率是这样的征兆：其根本原因可以是功率线缆断开、发电机故障、变压器故障等等，但是这些超出作为sud的制冷系统的范围。存在各种类别的根本原因：直接观察的根本原因度量。可以存在与某个传感器的输入的值直接对应的根本原因。例如，电流传感器能够报告没有电流到压缩机，直接对应于对于压缩机的功率故障根本原因。甚至更直接的形式可以是得到指示没有电流的输入。在该情况中，fsd可以用于抑制作为该根本原因的征兆而出现的其它征兆，诸如没有冷却发生，因而仅仅报告实际的根本原因。fsd可以处置的其它方面在这些情况中是传感器故障。例如，压缩机电流传感器可报告没有电流，但是其它传感器可报告：制冷在正常发生。在该情况中，fsd可以抑制“无功率”作为根本原因，并且代替地推断根本原因为电流传感器故障。例如，如果与功率故障相关联的根本原因故障场景需要相关的征兆也为真，则当是电流传感器已出故障的时候，该故障场景不匹配。当存在多个同时的故障时，可能存在关于可诊断性的限制。例如，如果关于电流和关于冷却系统其余部分的传感器已经出故障，则fsd可能没有关于sud的充分数据来执行超出以下的诊断：指示要么是传感器已出故障、要么是sud已出故障、或者二者。计算上确定的根本原因度量。一些根本原因可以根据需要从直接观察的数据中计算的度量来被确定。例如，压缩机的过度循环通过计算在压缩机的起动与其下一个起动时间之间的持续时间或时段来被确定。类似地，网络中的拥塞通过随时间的平均带宽来指示，而不是如可以由网络设备报告的给定时间处的瞬时包率来指示。fsd可以提供用来根据基本输入度量而计算各种度量以检测这些征兆的手段。所推断的根本原因。可以存在这样的根本原因：其可以不是根据直接观察的或计算的度量被确定，而是可以被推断。例如，在网络中，如果链接的两端被报告为运转并且恰当地配置然而不能通信，则fsd可以推断：它们之间的线缆未插接或有缺陷，尽管没有线缆传感器。有可能该推断是错的。例如，有可能两个接口都已经实际上出故障，并且线缆是好的。然而，相比于它是线缆问题，这可能是相对低概率事件。该情况在以下意义上类似于故障传感器的情况：fsd可能在推断传感器的值。无论传感器是已出故障还是仅仅不存在，处置的主要不同之处在于：fsd是被配置成覆写传感器输入还是仅仅推断它。在后一情况中，它正常地推断征兆，并且然后实际上推断度量，并且然后使用阈值来将它映射到征兆。对于这些根本原因，fsd可以执行逆推断，这通过对于征兆集合引起的行的故障场景，通常是已知为假的征兆，其最可能通过相关联的根本原因被解释。根本原因表（rct）rct的每行可以对应于由其名称标识的可能的根本原因。该行可以是被表示为经命名的征兆数组的潜在故障场景，所述征兆中的每一个是真、假或不用在意。该行中被指示为真的征兆指示对于使该行匹配而言必须为真的征兆。该行中被指示为假的征兆指示对于使该行匹配而言必须为假的征兆。如果该行中的征兆被指示为不用在意，则与该行相关联的可能的根本原因可以与该征兆无关。在具有许多单元的系统中，rct可以具有与可能在每个单元的每个组件中发生的众多根本原因故障相对应的数千行。可存在对于相同根本原因的多行，其在名称中通过附加数字后缀来被唯一地限定，例如故障压缩机0、故障压缩机1等等。为了促进rct的定义，fsd可以允许定义行模板，所述行模板允许一个或多个rct行的参数化定义。fsd可以使用'$'字符作为跟有零个或更多数字数位以指示行模板中的参数的转义字符的示例。在一个实施例中，没有跟随在后的数位的'$'被行实例的名称取代。跟有某个数字值i的'$'由该行实例中指定的第i个自变量取代。如果参数规范应当跟有数位，则该参数规范可以由数位前的“$-”终止。如果'$'应当出现在行模板中，则它可以被转义为“$+”。行模板定义。行模板可以利用跟有“行”列表的名称来被定义，所述行中的每一个利用以下来被定义：参数化名称、征兆的参数化列表，以及可选地非征兆的参数化列表，所述非征兆即对于该行/根本原因已知为假的征兆。以下是行模板定义的示例："rowtemplate":{"compressor":{"row":{"$fail":{"symptom":["environ/ambienttemp/high"],"notsymptom":["main/current/low","$/current/low","$/current/constantreading"]},"$coolantundercharged":{"symptom":["$/superheat/high","$/subcooling/low"],"notsymptom":["main/current/low","$/current/low","$/current/constantreading"]},"$coolantovercharged":{"symptom":["$/superheat/low","$/subcooling/high"],"notsymptom":["main/current/low","$/current/low","$/current/constantreading"]},"$blockageincoilsorficelineset":{"symptom":["$/superheat/high","$/subcooling/high"],"notsymptom":["main/current/low","$/current/low","$/current/constantreading"]},"$stuckortoobigorfice":{"symptom":["$/superheat/low","$/subcooling/low"],"notsymptom":["main/current/low","$/current/low","$/current/constantreading"]},"$shortcyclingcompressor":{"symptom":["$/runtime/starttostartshort"],"notsymptom":["main/current/low","$/current/low","$/current/constantreading"]}}}},...(“行模板”：{“压缩机”：{“行”：{“$出故障”：{“征兆”：[“环境/周围温度/高”]，“非征兆”：[“主/电流/低”，“$/电流/低”，“$/电流/恒定读数”]},“$冷却剂加载不足”：{“征兆”：[“$/过热/高”，“$/低温冷却/低”]，“非征兆”：[“主/电流/低”，“$电流/低”，“$/电流/恒定读数”]},“$冷却剂过度加载”：{“征兆”：[“$/过热/低”，“$/低温冷却/高”]，“非征兆”：[“主/电流/低”，“$/电流/低”，“$/电流/恒定读数”]},“$线圈公称直径线组中的堵塞”：{“征兆”：[“$/过热/高”，“$/低温冷却/高”]，“非征兆”：[“主/电流/低”，“$/电流/低”，“$/电流/恒定读数”]},“卡住或太大公称直径”：{“征兆”：[“$/过热/低”，“$/低温冷却/低”]，“非征兆”：[“主/电流/低”，“$/电流/低”，“$/电流/恒定读数”]},“$短循环压缩机”：{“征兆”：[“$/运行时/起始到起始短”]，“非征兆”：[“主/电流/低”，“$/电流/低”，“$/电流/恒定读数”]}}}},...)以上示例性行模板定义了6行，各自由'$'参数化，指示了行实例化声明的名称。模板中的每行指定了参数化的名称，加上“征兆”中真征兆与“非征兆”中可已知为假的征兆的集合。当实例化的时候，每个行名称可以是唯一的。此外，征兆和非征兆数组中所命名的每个征兆可能已经通过较早前描述的征兆定义设施被定义。如果没有满足这些要求，则fsd可以生成错误消息。rct行模板实例化。rctjson文件可以包含行模板实例化的集合，所述行模板实例化各自指定名称、行模板名称、以及用于代入到行模板中参数化条目中的自变量的列表。例如，以上行模板可以被实例化为："rowtemplateinstance":{"compressor0":{"rowtemplatename":"switch","arg":[]},...}(“行模板实例”：{“压缩机0”：{“行模板名称”：“交换机”，“自变量”：[]},})在该实例化的情况下，可以存在rct中定义的六行，其中'$'的每次出现都由该实例化的名称、即“压缩机0”取代。以下是首先生成的行，其中'$'由行模板实例的名称、该情况中为“压缩机0”取代："compressor0fail":{"symptom":["environ/ambienttemp/high"],"notsymptom":["main/current/low","compressor0/current/low","compressor0/current/constantreading"]}(“压缩机0出故障”：{“征兆”：[“环境/周围温度/高”]，“非征兆”：[“主/电流/低”，“压缩机0/电流/低”，“压缩机0/电流/恒定读数”]}),如果存在多于一个功率源，则那可以在行模板中被参数化为："notsymptom":["$0/current/low",...(“非征兆”：[“$0/电流/低”，...]其中实例化的行实例中的第一自变量可以指定功率源的名称。行模板设施可以显著减小对于定义复杂系统的rct所需要的json文件的大小，尤其是当存在相同单元的许多实例的时候。在该情况中，行模板可以为参数所限定的每个这样的单元定义公共行，因此可以为每个这样的单元实例化行模板，从而生成多行。在sud包括给定单元的仅一个实例的情况中，用于该单元的行模板可以被定义并且实例化一次，即用于该单元。在该情况中，没有对于参数化的行名称和征兆的需要，但是它仍可以保证遵循通过行实例化名称所进行的参数化的模式以用于统一性。自变量列表主要在根本原因行具有对另一单元中征兆的相关性的时候被使用。自动生成这些自变量将会需要对单元相关性拓扑的认知，因此它遵从分离的领域特定的程序。rct开发策略。对于开发rct规范的一个起始点是标识目标领域中的sud可能有的故障的不同根本原因。例如，在制冷系统中，压缩机可能烧坏，并且因而不能运行。因此，在rct中可以存在被标注为“压缩机$故障”的行。然后，在每个这样的根本原因的情况下，对已经发生该根本原因的可观察的指示可以被标识。通常存在不可观察的许多根本原因。例如，传感器可能不直接报告压缩机是否已出故障。来自压缩机故障的可观察的指示通常是：制冷单元中的温度没有在下降。对于指示根本原因的每个所需的征兆应当被添加到与该行、即根本原因对应的故障场景中的征兆集合。在一些情况中，根本原因的指示符指出对于新征兆定义的需要。例如，它可能不是起初被看作具有针对不充分下降温度的征兆。在该情况中，可以有可能返回到征兆定义，并且在该阶段添加该征兆。指示符可能不是直接由sud中的传感器提供，而是需要根据所报告的值被间接计算。在该情况中，可以引入“指示符”对象，其提供经计算的值并且将此映射到sud场景上。在以上示例中，可以使用对应于温度的一阶导数的指示符，并且可以使用往sud上的阈值映射，所述阈值映射在sud处于冷却模式的时候设置相关联的征兆，并且该一阶导数高于某个阈值，也就是说，不是充分为负。指示符的配置和指示符映射以下被更详细地描述。在对暗示了给定根本原因的故障的这些可观察的指示符进行标识了之后，下一步是要考虑可能导致相同指示符的其它根本原因。例如，如果没有功率给到压缩机，则压缩机可能不运作，并且因而温度的一阶导数可能不充分为负。为了避免假阳性，任何这样的征兆可以被添加到与该行对应的故障场景中的非征兆集合。除了缺功率之外，可被标识的是：如果压缩机没有被配置成运行，则压缩机将不运行。如果来自sud制冷系统的报告数据路径没有在运作的话，则可以看到非下降的温度。对于这两种情况的征兆可以被定义为“压缩机$误配置”和“压缩机$不报告”，并且前一个为“压缩机$无功率”，因而“非征兆”将被指定为："notsymptom":["compressor%nopower","compressor$misconfigured","compressor$notreporting"](“非征兆”：[“压缩机%无功率”，“压缩机$误配置”，“压缩机$不报告”])，“非征兆”征兆在另一故障可能引起类似征兆的时候有效地抑制假阳性。逻辑上，当sud场景使得行的“征兆”集合中的征兆为真并且对于行的“非征兆”集合中的那些为假的时候，行被匹配。因而，在该示例中，当压缩机功率已经停转的时候，fsd可能不报告压缩机故障，因为“压缩机$无功率”征兆在该情况中为真，从而使得压缩机故障行/故障场景不匹配。如果根本原因故障可以通过不同准则可观察，则可以为每个不同的准则集合定义行。可以假定：应用机制可以将这些行名称映射到公共根本原因。可以依据征兆来使fsd结构化，如与恰当表现的指示相对。例如，假设性地使逻辑反转，因此存在状况“压缩机$有功率”，可以用作可替换的技术。如与此相对的，出于若干原因，采取征兆途径。首先，通常存在恰当的一个状态，但是有故障的许多状态，即征兆。例如，功率可能很低或过度尖峰化以及完全没有功率，而存在功率处于规范内的单个情况。因此，简单地取良好状况的反转作为故障并不提供不同类型故障的充足标识。因而，利用征兆，征兆的数目可以任意扩展。恰当表现于是仅仅是不存在任何相关联的征兆。其次，sud中存在可能不与arca相关的许多特定状态。聚焦于征兆将焦点保持在可能实际与fsd相关的信息上。可预期的是对于特定应用领域和部署的fsd配置随时间演进，从而扩展根本原因以及细化与根本原因相关联的征兆，这既在“征兆”中也在“非征兆”中。有价值的是具有回归测试，所述回归测试确保这些改变不引入假阳性或假阴性。返回到rct策略，上述对根本原因与相关联的征兆的部署导致标识新征兆、新指示符、以及这些指示符往sud场景中征兆上的映射。下一主题涵盖这些指示符的配置。指示符json配置文件。在一个实施例中，来自sud的传感器值的fsd内部表示被存储在本文中被称为“指示符”的对象中。每个指示符在属性“fsd::指示符::所估计的值”中提供单个值，其是表示中的双精度浮点数。它被称为所估计的值，因为它可以不对应于sud上的传感器所实际报告的任何值，而是通过各种手段被估计，包括传感器值的内插。它还可以提供“模式”属性，指示与该值相关联的当前模式。“指示符”还可以列出由该指示符所假定的一个或多个故障场景。例如，如果在该指示符的值的计算中假定冰箱温度传感器已经出故障并且已经根据其他因素计算了该温度，则利用该指示符列出的故障场景中的一个指定冰箱温度传感器故障。该设施允许指示符通过后面的假定来反映如何计算它。正常情况中，可预期该列表是空的。“指示符”实例可以被定义为在其输入上的其相关联的操作的输出。例如，指示符可以被定义成提供其估计的值，为其输入指示符中所估计值的最大值的那个。“指示符”还可以指示其值中的置信度，其通常由其输入中的置信度来确定，这取决于如何根据其输入来计算它。例如，最大值运算的置信度是被选为最大值的输入的置信度，假定其它输入显著较小。求和运算的置信度可以被计算为输入的置信度的加权平均值，其取决于每个输入提供到最终总和的量。较简单的途径仅仅是使置信度是输入的最小值。所支持的当前操作符是：•输入-伪操作符，意味着它根据外部输入数据被设置，并且不取任何指示符输入；•求和-一元操作符，在某个指定的间隔上求和；•求平均值-一元操作符，在某个指定的间隔上求平均值；•持续时间-一元操作符，测量特定模式中输入指示符的持续时间；•多项式-其单个输入的多项式输出；•步进函数-其单个输入的表驱动的步进函数输出；•打印-所选指示符的标准错误输出，主要用于调试；•标准偏差-其输入的递增的标准偏差；•最大值-n元操作符；•最小值-n元操作符；•差-二元操作符；•绝对差-绝对差二元操作符；•总和-其k个输入的总和；和/或•预测限定符-如果第一输入足够靠近于第二输入（预测器），则输出第一输入，否则使用预测器。可以相对简单地添加新操作符。json指示符配置指定将由fsd用来根据所供给的输入而计算对于征兆而言感兴趣的值的指示符集合。指示符的每个json规范包括：•“名称”-指示符的名称-这是可选的并且默认成用于条目的名称；•“操作符”-计算该指示符的值的操作符，例如差；•“模式”-初始操作模式；可选的，默认成如由-1指定的“任何”。另外，与指示符相关联的操作仅仅在输入处于所指定模式中的时候更新指示符。•每更新的回合-在对于指示符估计值的更新之间的输入回合的数目。可选，默认成1；•“输入”-对以上操作符的输入指示符，作为其名称的数组；和/或•“自变量”-对操作符的选项自变量，如果有任何的话。指示符文件可选地指定“输出时钟名称”，其指定指示符被用作输出时钟。如果该名称没有被指定，则它默认成“输出时钟指示符”。输出时钟用于触发对照输入指示符的估计值而对下述映射的重评估，然后设置或清除sud场景中的任何征兆。它还可以用于确定何时值已太恒定。也就是说，可以通过该时钟来测量“最大恒定回合”。以下无限制地说明用于计算制冷系统中过热和低温冷却的指示符集合的定义，其开始于标准输出时钟和子场景指示符。{"indicator":{"suctionpressureinkpa":{"op":"polynomial","input":["suctionpressure"],"arg":["100.0","100.0"]},"suctionsaturationtemperature":{"op":"polynomial","input":["suctionpressurekpa"],"arg":["3.67e-31","7.02e-27","-5.81e-23","2.73e-19","-7.99e-16","1.52e-12","-1.90e-9","1.55e-6","-8.23e-4","3.17e-1","-70.575084"]},"suctionlinetemperature":{"op":"input"},"suctionsuperheat":{"op":"difference","input":["suctionlinetemperature","suctionsaturationtemperature"]},...}"outputclockname":"outputclockin"}({“指示符”：{“以kpa的吸入压力”{“操作符”：“多项式”，“输入”：[“吸入压力”]，“自变量”：["100.0","100.0"]},“吸入饱和温度”：{“操作符”：“多项式”，“输入”：[“吸入压力kpa”]，“自变量”：["3.67e-31","7.02e-27","-5.81e-23","2.73e-19","-7.99e-16","1.52e-12","-1.90e-9","1.55e-6","-8.23e-4","3.17e-1","-70.575084"]},“吸入线温度”：{“操作符”：“输入”：},“吸入过热”：{“操作符”：“差”，“输入”：[“吸入线温度”，“吸入饱和温度”]},}“输出时钟名称”：“输出时钟in”})。可选地，可以指定“每更新回合”，其默认为1。而且，可以每指示符地指定“模式”，其默认为“任何”，也就是说，-1。输入集合中的指示符的数目特定于指示符操作符。一些操作符、诸如“输入”不接受任何输入。其它操作符是一元的，诸如求和，并且仅仅允许和/或需要输入指示符。还相对于相关联的操作符来解释自变量。响应于读取指示符文件，fsd实例化所指定的指示符中的每一个。对指示符的每个输入必须是该文件中所定义的指示符。对指示符的输入还必须在数目上匹配相关联的操作符所预期的量。可以为rct提供宏设施，以允许跨单元和组件的指示符的统一规范，尤其是对于网络域。宏设施也可以包括指示符映射。fsd配置的下一个方面包括指定由这些指示符所提供的度量到实际故障场景、即sud场景的映射。该映射由指示符映射文件指定，如接下来所讨论的。指示符映射json配置文件。指示符映射将指示符映射到一个或多个真或假的征兆中，这基于其估计的值和模式。仅仅在对输出时钟的更新时应用指示符映射。例如，如果输入时钟每一秒被更新，但是输出时钟仅仅每十秒被更新，则sud场景中的征兆每10秒被更新。因此，rct匹配还可以每十秒被执行。默认地，阈值所使用的时钟是指示符文件中所指定的输出时钟。可选地，可以指定要使用的输出时钟的分离的“时钟名称”。存在至少三种类型的映射：1.恒定映射-检测指示符是否已经过度恒定，通常是损坏传感器的指示；2.阈值映射-基于所指定的指示符的值在基于阈值规范的范围外而映射到征兆；和/或3.估计的值映射-将其指示符输入的指示符值映射到sud场景的指示符值。如指示符操作符一样，需要时，fsd使用附加形式的指示符映射。恒定映射1.最大恒定回合-输入值在它被视为故障之前可以为恒定的（输出时钟的）最大数目的回合；2.恒定征兆-将由该映射设置的rct征兆的名称；和/或3.所允许的增量（delta）-被视为值改变的最小改变。阈值映射。通过指定以下来指定阈值映射：1.最小阈值和最大阈值的值，其定义对阈值的下界和上界；以及2.对于低于最小值、高于最大值、在一般范围外、以及太恒定的征兆的名称。以下是阈值映射的示例性规范，其将被命名为“叶1::功率”的指示符映射到sud场景中的特定征兆，这基于“叶1::功率”的“估计值”属性。{"thresholdmap":{"leaf1:power/thresholdmap0":{"alloweddelta":0.01,"maxconstantrounds":100000000,"constantsymp":"leaf1/power/constantreading","minthreshold":[4.0],"minthresholdsymp":[13.0],"maxthresholdsymp":["leaf1/power/high"],},...}...}({“阈值映射”：{“叶1:功率/阈值映射0”：{“所允许的增量”：0.01，“最大恒定回合”：100000000，“恒定征兆”：“叶1/功率/恒定读数”，“最小阈值”：[4.0]，“最小阈值征兆”：[13.0]，“最大阈值征兆”：[“叶1/功率/高”]，},}})。每个征兆名称可能已经先前在rct文件中被定义，如较早前所描述的。可以利用已经是对其它指示符的输入的输入指示符来定义阈值映射。可以为相同指示符定义多个阈值映射。当多个阈值映射到相同征兆的时候，不在sud场景中定义表现，除非每个映射具有分离的模式并且不是“任何”，因此在每个输出时钟回合上仅仅一个映射在设置征兆中是活动的。阈值映射还可以被定义以通过使用对其输入的操作符来计算阈值。例如，添加：“其它指示符名称”：“预期的结果”，“操作符”：“差”，到上述定义，基于在“结果”指示符和“预期的结果”指示符之间的差来计算阈值。所支持的操作符包括最小值、最大值、和以及差。当在两个指示符之间的差上计算阈值的时候，差操作符通常可以避免分离的差指示符，如在测试中以及在检测出故障的传感器中可能出现的那样。除了减少指示符的数目之外，在阈值中使用操作符的另一优点是：仅仅在输出时钟上、而不是在每个输入改变时评估操作符。估计值映射。该映射可以使得所指定的指示符的“估计值”成为sud场景中可用的估计值。在一个实施例中，fsd使用附加类型的映射。fsd配置的下一个部分是将输入文件映射到fsd指示符，如接下来描述的那样。fsdjson输入绑定和计时。fsd可以被配置成从输入数据文件读取关于sud的传感器数据。输入数据文件可以是以各种不同格式，并且可以包含多个传感器值。输入绑定。json输入绑定配置文件指定输入文件的集合，并且对于每个输入文件：1.用于处理该数据格式的输入适配器类型；2.输入记录中字段到fsd指示符的绑定；和/或3.预测增量-在输入值作为错误的被忽略并且预测值被代替地使用之前在输入值与适配器预测的值之间的差。0.0的值指示没有任何预测应当被应用，即它不是连续值。csv文件格式。在一个实施例中，所支持的主输入是csv，其中以秒的时间作为第一字段，零个或更多可忽略的字段，然后字段的文本名称跟有指定时间处的该字段/传感器的值。例如，23.0,juicebar4,rtu0-compressor0%temp,4.3在以上示例中，输入记录处于距输入文件的起始时间的23.0秒的时间处。它相关联于地点“juicebar4”，其可能不与fsd处理相关，因此是忽略字段的示例。传感器被标识为“rtu0-compressor0%temp”。该时间处该传感器的读数是4.3摄氏度。注意到：该适配器将开始于“//”的行视为注释行。行上的时间可以被省略，使得输入行开始于“，”，在该情况中，时间被取为在前时间值。以下是示例性输入绑定。"inputfile":{"/data/juicebar4:oct2417:3to6pm.csv":{"name":"/data/juicebar4:oct2417:3to6pm.csv","adaptertypename":"csv","ignoredinputfields":1,"binding":{"rtu0:compressor0:temperature":{"indname":"rtu0:compressor0:temperature","fieldname":"rtu0-compressor0%temp","adaptationqualifier":"","predictiondelta":1.5},...}}...}...}(“输入文件”：{"/data/juicebar4:oct2417:3to6pm.csv":{“名称”："/data/juicebar4:oct2417:3to6pm.csv",“适配器类型名称”："csv",“忽略的输入字段”：1，“绑定”：{“屋顶单元0：压缩机0：温度”：{“指示符名称”：“屋顶单元0：压缩机0：温度”,“字段名称”："rtu0-compressor0%temp",“适配限定符”："",“预测增量”：1.5},}}}})该配置指示fsd应当通过使用通用csv适配器从具有路径名称“/data/juicebar4:oct2417:3to6pm.csv”的输入数据文件读取。同样，具有字段名称"rtu0-compressor0%temp"的值可以被映射到被命名为"rtu0:compressor0:temperature"的指示符。空串的“适配限定符”指示：系统应当使用默认指定的输入适配器处理。该属性当被指定时意图修改用于相关联的字段的处理。同样，“预测增量”指定输入值需要在预测值的1.5度内，否则，它被忽略以有利于预测值。这允许fsc处理原始传感器输入，而不与不正确的传感器读数妥协。第一个“...”指示：可以为该文件指定附加的字段绑定。如果选项“允许默认输入到指示符的绑定”对于该输入文件是真的，其默认是真，则fsd可以自动尝试将输入字段名称映射到相同名称的指示符，如果它不是另行被指定的话。在该情况中，“默认预测增量”可以用于预测增量，并且“预测限定符”可以是空的。该默认减少在常见情况中所需的绑定的数目，如果通过与用于对应输入字段的名称相同的名称来为输入指示符命名是可行的话。fsd如果遇到一输入字段，针对所述输入字段没有对应的指示符，则fsd可以生成错误。在一个实施例中，最佳实践是将不感兴趣的任何输入字段映射到没有另行被使用的指示符。使得fsd忽略它不识别的输入字段的可替换方案可能不幸地导致输入数据被静默地忽略，使得更难以调试结果产生的问题。在该格式的情况下，常见情况是：文件包含来自多个源或传感器的输入。否则，不指定字段名称可能是更高效的。例如，hvac输入文件可以包含来自与给定rtu相关联的压力、电流以及温度传感器的读数。可替换的csv格式是这样一个：其中每个记录包含输入值的固定序列，每个传感器一个。然后，指定时间的成本在多个读数上分摊，并且无需要反复地指定字段名称。然而，常见的是：不是所有传感器都可以同时被读取，因此，对于某些系统可能不是可能的和/或优越的。fsd允许附加的输入适配器被相对容易地添加。计时。fsd在本文中被称为“回合”的中操作，所述回合是固定的时钟时段，以使能恰当的时间计算。存在输出时钟和输入时钟。输入时钟确定用来根据输入数据更新指示符的速率。它不由与输入数据相关联的时间所管控。代替地，如果与输入字段相关联的“预测增量”属性是非零的，则fsd内插每个输入值以估计输入时钟时间处的值，其根据它已读取的实际输入数据来确定。例如，如果输入时钟回合发生在3pm，然而只有2:59pm和3.01pm处的传感器的输入读数，则它可以使用在这两个值之间的线性或其它内插来估计该值以写入到输入时间3pm处的相关联的指示符。该内插对于处理在不同时间读取的、来自不同传感器的传感器读数而言是重要的，而同时提供sud的状态的合理诊断。例如，功率传感器可以每秒进行采样，因为电流可能快速改变，而另一方面，温度可以每分钟被采样一次，因为它缓慢且线性地改变。fsd还被配置有输出时钟。该时钟规定它多长时间一次地执行指示符到sud场景的映射以及根本原因分析。这是重要的，因为根本原因分析可能需要对照数千rct行来匹配sud场景，并且因而成本应当被限定以将预期的处理时间维持在数秒而不是数小时内。在一个实施例中，fsd允许根本原因分析被分区并且跨多个过程并行地运行。考虑到在行匹配之间没有相关性，它自然地是数据并行计算。fsd输出时钟可以是输入时钟的积分因子。例如，输入时钟可以每五秒更新以执行准确计算、诸如标准偏差的计算。相反，输出时钟可以每60秒更新以最小化开销，此外认识到：在许多应用中，在小于一分钟内对问题的根本原因分析几乎没有益处或没有任何益处。fsdjson输入绑定文件可以在输入文件绑定之后包括第二区段，其指定定时参数：1.“每输出回合的秒数”，其中所述秒数是指使用输入数据中报告的时间的sud中时间。2.每输出回合的输入回合-这允许输入时钟时段根据输出时钟而被计算；3.起始时间；4.结束时间-停止输入的处理。如果结束时间延伸到输入文件的结束时间之外，则fsd通过使用内插所使用的相同的线性预测逻辑来在时间中向前外推度量；和/或5.预热时间-在任何根本原因分析发生之前开始读取输入数据的时间。这允许恰当地初始化各种指示符计算，以避免否则可能出现的假阳性。来自fsdjson输入绑定文件的示例性定时区段是：“每输出回合的秒数”：30.0，“每输出回合的输入回合”：6，“起始时间”：{“秒数”：0，“微秒”：0}，“结束时间”：{“秒数”：1234，“微秒”：0}，“预热时间”：0.0，输出时钟被指定为在sud时间中每30.0秒具有一回合。注意到，当fsd执行时，输出时钟通常实时执行得快得多。例如，fsd可以在小于五秒内处理五分钟的输入数据，假定它在新接收的传感器数据上每五分钟运行。存在每输出回合的六个输入回合，因此可以存在每五秒sud时间的输入时钟回合。起始时间、结束时间和预热时间是自描述的。在预期的用例中，输入数据文件覆盖过去的已知时间段，因此可以利用与输入数据文件所覆盖的时间结束相对应的结束时间来调用fsd。然而，由于输入数据文件可包含以不同速率读取的、来自不同传感器的数据，所以fsd可能在结束时间之前达到输入数据文件的结束，从而使得外推被使用，如较早前所描述的。陷阱。fsd提供在本文中被称为“陷阱（trap）”设施的事物来用于在特定rct条目匹配到或从中不匹配的时候采取行动。可以定义根本原因表本身上的陷阱，其当没有在一行上定义的特定陷阱的时候，使得该陷阱被用在该行上。陷阱还可以被置于指示符映射上，以检测何时该映射使得征兆被设置或解设置。输入绑定文件可选地包含“陷阱描述”集合，其描述将在配置上设置的陷阱。陷阱描述包括：•陷阱名称•类别-当前是rct或映射•触发该陷阱的条件，其可以是以下中的一个或多个：◦为设置故障（issetfault）-设置征兆，◦为解设置故障（isunsetfault）-解设置征兆，◦为匹配（ismatch）-匹配相关联的映射或rct条目◦为不匹配（isnonmatch）-不匹配相关联的映射或rct条目•动作-将在陷阱上执行的动作，其可以是以下中的一个或多个：◦为陷阱上挂起（issuspendingontrap）-挂起fsd处理。这主要意图用于交互式调试模式，尚未被完全支持。◦为递增预期的匹配计数（isincrementingexpectedmatchcount）-递增预期的匹配计数-由测试程序所使用◦为递增非预期的匹配计数（isincrementingunexpectedmatchcount）-递增非预期的匹配计数-由测试程序所使用◦为陷阱上存记（isloggingontrap）-将陷阱存记到文件。设置rct本身上的陷阱可以具有特殊的方面。首先，如果“行”被指定为空串，则fsd可以将该陷阱映射到整个rct。其次，将条件指定为“为不匹配（isnonmatch）”意味着它确定在对照着rct匹配sud场景中没有被匹配的征兆。这允许确定什么征兆完全没有被匹配。使得它在rct的每行上它没有匹配上的陷阱的“正常”语义可能不是看起来有用的。此处是定义该rct陷阱的示例性“陷阱描述”："trapdesc":{"":{"category":"rct","condition":["issetfault","isunsetfault"],"action":["isloggingontrap","isincrementingexpectedmatchcount"]}}(“陷阱描述”：{"":{“类别”：“rct”，“条件”：[“为设置故障”，“为解设置故障”]，“动作”：[“为陷阱上存记”，“为递增预期的匹配计数”]}}),该陷阱存记sud场景中的征兆的每个设置和解设置，以及在每个这样的设置和清除时递增“预期的匹配计数”。常见的途径是定义该rct陷阱，并且然后当特定行需要不同的条件和/或动作的时候用特定行上的那些来覆写。该陷阱机制可以用于调试fsd处理参数以及应用数据集中的指示符配置。例如，如果rct的给定行曾匹配，则该行上的陷阱可以指示那个。陷阱机制还用于fsd测试程序。例如，fsd可以被配置成处理具有已知故障表现的特定测试输入文件。陷阱可以用于确定这些故障正被检测并且没有其他故障在被检测。输入处理和定时。在一个实施例中，fsd依照回合、即固定重复的时间递增来执行处理。它实际上利用两个时钟来操作：输出时钟和输入时钟。回合涉及sud时间，即，如在输入数据中所指示的时间，其通过将该时间计算为sud时间中所指定的纪元时间的起始加上回合数目乘以每输出回合的秒数的乘积。在输出时钟的每个回合上，fsd可以重评估正被指示的根本原因，这通过对照根本原因表来匹配sud场景。例如，如果fsd::config::secondsperoutputround（fsd::配置：：每输出回合的秒数）属性被指定为30，fsd在它正执行的时候可以在sud时间中每30秒地执行该根本原因匹配。注意到：预期fsd处理大体上快于实时地执行。例如，fsd代理被设计成周期性地被调用、利用它的如在其上一次调用的结束时的状态来重开始，并且处理自从上一次它被调用以来的所有输入数据。例如，它可以被配置成每30分钟地运行，从而处理上30分钟的sud输入数据，但是仅仅花费两秒来这样做。输入时钟可以确定用来根据数据输入更新fsd指示符的速率。它可以依据每输出回合的输入回合的数目而被指定。例如，如果fsd::config::inputroundsperoutputround（fsd::配置::每输出回合的输入回合）被指定为6（其中有针对输出时钟的30秒回合，如上），则fsd可以每五秒地执行输入回合。当输入时钟被推进到下一个回合时，可以预期每个输入适配器读取其输入，直到它已经读取了比针对该输入回合的时间更晚的输入为止，然后通过线性或其它内插来计算针对回合时间的该输入值的估计，并且然后更新其相关联的输入指示符。它于是可以指示：它已经完成了该输入回合。例如，如果输入数据集每秒提供样本，则输入适配器可以内插这些样本以提供如对输入时钟时间的值的最佳估计。注意到，在一些实例中，将该值计算为样本上的平均值可能不是适当的，因为在迅速上升或下落的输入源的情况下，平均值可能是不准确的。在一个实施例中，fsd充分在实时之后执行，使得数据对于每个输入时间步是及时可用的。实时输入适配器可以在需要时、通过使用外推来填入缺失的值。如果例如输入数据每十秒提供样本，则与上述相同的内插途径起作用。特别地，输入适配器可以提供输入数据的内插，从而提供如对当前输入时钟时间的值的最佳估计。输入数据还可以提供以不规律隔开的间隔、即抖动（jitter）读取的值。例如，来自温度传感器的读数之间的时间可以在10秒和30秒之间变化。输入适配器可以使用线性或其它内插，从而允许在针对读数的时间之间的差异。该内插还可以处置以下情形：在所述情形中输入数据时间不与输入时钟匹配。例如，输入时钟可指定3:01:05pm，但是输入数据在3:01:03pm和3:01:08pm被读取。也就是说，输入数据可以具有与输入时钟相同、但是不与它同步的时段。输入适配器将会估计其数据在3:01:05pm的时间。在一个实施例中，不同输入源以不同时间步来提供数据。这些通过如上述的内插而全部有效地“同步”到输入时钟。输出时钟可以被配置有大体上长于输入时钟的回合，以减少运行根本原因分析处理的开销。例如，具有30秒的输出回合意味着可以在故障被指示的30秒内发现故障，这通常是足够的，但是相比于每五秒、输入回合时间运行它引发1/6的根本原因分析处理开销。相反，输入时钟可以被配置有比输出时钟更短的回合，使得如果输入数据具有比用来执行根本原因分析的速率更频繁的更新，则可以发生更细粒度的处理。例如，如果需要在30秒时段上的某个潜在迅速改变的输入的标准偏差，则可以每五秒地更新标准偏差，其基于5-秒输入时钟。在一个实施例中，对于利用比任何输入数据都更短的回合来配置输入时钟可能存在有限的益处，因为输入适配器通常对于许多回合都没有任何附加的输入数据。在一些情况中，如果读数的定时与输入时钟异相，则它可具有某种益处。fsd配置开发和调试。在通过使用fsd、为特定应用开发诊断系统中，以下阶段是有帮助的：1.如上指定征兆和rct；2.定义指示符的计算网络；3.将这些指示符中的一个或多个映射到sud场景上；4.定义输入数据文件到指示符的映射，以及时钟/定时配置；和/或5.对照各种输入数据文件来调试该系统，从而验证它正提供准确的分析，即没有假阳性或假阴性。在稍后的阶段，fsd配置的每个步骤都有误差可能性。某些关键调试场景包括：1.断定什么引起假阳性；和/或2.断定什么引起假阴性，即征兆的未检测。考虑到fsd的端对端表现，给定版本可能由于以下中任一项而不能输出正确的根本原因：1.为rct行中的根本原因所指定的错误征兆；2.不正确的参数被指定于指示符到rct的阈值映射；3.不正确的计算被指定用于指示符输出；和/或4.指定了不正确的输入绑定或时钟配置。对于差rct的第一情况，可以在相关联的行上设置陷阱，有期望的动作，以捕获这正发生，并且然后检查状态。在一个实施例中，fsd的交互运行受支持，其通过使用用于交互调试的陷阱机制。例如，如果fsd没有将场景匹配到所应当是的可能的根本原因，则可以在与该可能的根本原因对应的行上设置陷阱，其中条件是不匹配。然后，可以检查为什么它不匹配。对于阈值匹配问题的第二情况，可以在阈值上设置陷阱，从而检查为什么征兆在被设置或没有被设置，并且相应地调节参数。尝试在缺失的阈值上设置陷阱可能引起误差指示，其提供该阈值定义缺失的信号，如果那是问题的话。对于不正确的指示符计算的第三情况，可以利用测试输入数据文件来运行fsd，所述测试输入数据文件除了正常输入数据文件之外还为给定指示符提供预期值。可在该“黄金文件（goldfile）”输入与应该计算该值的指示符之间配置差异指示符，并且所述差异指示符具有阈值映射，所述阈值映射在所述差异大于可接受的情况下设置征兆。利用该途径，可以如上在阈值映射上或在相关联的rct行上设置陷阱，以当出现不符的时候用陷阱捕捉。fsd还可以提供打印指示符，所述打印指示符可以用于输出所计算的值以用于可视检查或用于与已知值的分离比较。例如，对输出时钟的每个改变可以通过使用json指示符配置中的以下而被输出："outputclockinprint":{"op":"print","input":["outputclockin"],"arg":["hasvalue","hasmode","hasconfidence","hasfaultscenarios"]}(“输出时钟in打印”：{“操作符”：“打印”，“输入”：[“输出时钟in”]，“自变量”：[“具有值”，“具有模式”，“具有置信度”，“具有故障场景”]}),假定输出时钟指示符接口被命名为“outputclockin（输出时钟in）”。打印操作符仅仅在如稍后描述的设置了“冗长模式”的情况下进行输出。对于具有不正确输入绑定的第四情况，fsd可以被配置成如果输入字段被读取、其没有被映射到指示符，或当对于该字段的值很坏的时候默认地生成错误。冗长模式。可以通过fsd命令行参数“—isverbose（为冗长）”来激活冗长模式。fsd于是可以向标准错误输出各种消息，包括每映射的消息以及被命中的rct陷阱。在一个实施例中，所指示的时间实际上是下一回合，而不是当前回合。fsd的生产执行。fsd的一个操作模式是为了它被周期性地调用以处理上一窗口的sud输入数据，其中该时段取决于应用领域和用户要求。例如，在hvac监控的情况下，每30分钟地运行fsd可能是足够的，因为在该时段内对根本原因所致的故障的响应时间是足够的。在网络上下文中，每十秒地运行它可能是更适当的。可以假定遥测收集系统正将来自sud的传感器/探针数据连续地存付到文件中，其以fsd具有的输入适配器所用于的格式，并且以单调增的时间定序。fsd可以在每次重执行的时候重启动，从在先sud时间继续，利用内部对象的状态，所述内部对象诸如从在先执行所恢复的累加器。例如，如果fsd正将某个指示符生成为加权移动平均，则指示符可以在其重执行时以下一个输入继续，就像它一直在连续执行一样。fsd可以比sud实时快得多地处理输入数据。因此，在网络示例中，fsd可以执行一秒，以处理过去十秒的数据。该周期性执行有效地成批处理，而不是连续地对实时输入作出反应。这可以比使得fsd连续运行、等待附加输入更高效。它还意味着重启机制可以被连续运用，从而确保故障容差。在一个实施例中，为了允许快速有状态的重启，fsd被设计成从sysdb（系统数据库）中所存储的其状态的二进制表示中恢复其关键的内部状态。在重启时，fsd装载来自sysdb的状态，并且除非它由命令行参数另行指定，否则如果它被初始化的话使用该状态，而不是读取json配置文件。在一个实施例中，假定它从它被处理到的上一个时间点继续。例如，rct被存储在sysdb中，作为tac::entity的集合，各自具有行集合，因此比从json规范中初始化快得多地恢复。指示符、指示符映射、和输入绑定配置类似地从sysdb中重创建，而不是重读取json文件。如果fsd出故障并且立即重启以从故障中恢复，则也可以使用对状态的该sysdb恢复。总结。在一个实施例中，fsd高度可配置以处置不同的诊断要求和应用语义。它从sud输入经时间标记的数据，并且产生事件日志，其指示对故障的根本原因，如果有任何的话。它还可以包括对于为特定应用领域和部署调试其配置的陷阱支持。fsd使得能够作为设计应用的部分而设计分布式应用的遥测和根本原因分析。fsd允许在生产中利用事情如何可能出差错；为此进行规划以及支持快速补救动作使能支持高可用性。附录：操作符步进函数（stepfunc）。“步进函数”支持“模态”指示符，所述模态指示符可以为相同输入指示符的每个输入模式定义分离的步进函数。例如，“步进函数”操作符可以被定义成在压缩机作为一个模式运行的时候为制冷温度提供预测结果，并且为当压缩机不运行的时候提供分离的计算，这通过具有与它不运行相关联的分离的模式。限定符后缀可以被提供给输出指示符名称，其对于每个这样的“步进函数”是唯一的，以避免名称冲突。例如，对于关断模式的“步进函数”指示符可以被定义为“预测温度/关断”，其中该模式被指定为0，而对于开启模式的“步进函数”指示符可以被定义为“预测温度/开启”，其中该模式被指定为1。利用相同的输出接口和冲突模式、即相同的模式或以“任何”模式所指定的一个模式来指定两个不同的“步进函数”操作符可能是个错误。打印。打印操作符用于调试fsd应用。它采取单个输入和输出由自变量指示的指示符的字段的值，默认成仅值，如果没有自变量被指定的话。所支持的自变量包括：•hasvalue（有值）•hasmode（有模式）•hasconfidence（有置信度）•hasfaultscenarios（有故障场景）输出格式是：indicatorname<mode>time=val<confidence>{listoffaultscenarionames}其中封闭分隔符被省略，如果字段没有被输出的话。附录2：前言主题基于自调谐预测的指示符。通过基于其它指示符状态而向指示符的参数提供反馈，可以自动调谐指示符的计算。例如，“步进函数”指示符节点所使用的值可以由另一节点调节，所述另一节点诸如具有其输出、该第一指示符的“步进函数”参数的另一“步进函数”节点。该情况的一个示例是使用预测来防止传感器故障，所述传感器故障否则可能以不正确的值来危害计算。一种技术是“预测”下一时间间隔处的所关注的输入传感器的值，并且然后对照所预测的读数来比较实际读数。如果实际读数太远离所预测的读数，则假定传感器读数是不良的。然而，这需要预测是相当准确的，这意味着调谐对系统的预测参数。因此可以用各种方式生成预测。一个示例是“步进函数”节点，所述节点可以从当前估计的值以及指示符所定义的步进函数外推，以计算下一个值，要么为实际值，要么为实际值的一阶导数。例如，在制冷系统中，根据冷却温度中的变化所计算的冷却速率被提供到“步进函数”节点，以估计冷却速率。根据冷却速率，预测节点可以预测下一回合时间处的温度。在预测值和实际值之间的实际选择通过使用“预测限定符”指示符节点来进行，所述指示符节点取预测和实际的这二者作为输入和输出，要么是预测的，要么是实际的，其取决于所允许的增量以及这些输入的每一个中的置信度。它还可以输出二者之间的平均值。还存在差异节点，所述差异节点计算在实际的和预测的之间的增量，作为对参数校正的输入，预测差异。预测差异可以用于在“步进函数”节点中进行预测参数的某种标称校正，也就是说，如果预测微高，则相关联的参数可以被往下调，并且反之亦然。该能力在以下意义上是一种形式的“反向传播”：一些相对高级别的指示符可以用于细化一些较低级别指示符中的置信度。例如，在制冷系统中，冷却的行为可以用于估计通过压缩机和风扇的电流消耗。该估计可以被反馈以与来自压缩机和风扇电路上的电流传感器的输入相组合。在电流消耗的某种意义上将该估计视为预测器，其可以用于检测何时电流传感器已出故障或不可靠地执行。作为输入的输出。在一个实施例中，fsd允许以适合于fsd输入适配器中的一个读取的格式来输出根本原因。例如，根本原因可以用csv格式输出，其中有检测到该根本原因的sud时间，跟有一个或多个可忽略的字段名称，并且然后根本原因的名称作为输入字段名称，跟有为1的值，其指示它为真，或否则当它不再为真的时候，如果为假则是0。然后，csv输入适配器可以读取包含这些值的文件，与输入数据文件一样。该能力允许fsd的一个实例确定可能不是直接可观察的值，即一个sud的根本原因，并且然后将该值作为输入提供给fsd的另一实例。例如，如果被递送到sud的功率不是直接可观察的，则fsd实例可以确定其表现的根本原因是功率丢失。如果另一sud在相同的功率源上，则该根本原因可以被提供到处理该第二sud的fsd实例，作为输入。并行根本原因分析。在一个实施例中，fsd被配置使得通过分离的代理并行执行来并行施行rct匹配。每个代理简单地装载sud场景和rct，并且被指派rct行的某个子集以对照着来匹配。在一个实施例中，在这些代理之中对rct进行分区。注意到，通常在对照rct进行匹配中不存在次序相关性。在一个实施例中，以如多个显式分区的尺度来使rct结构化，因此每个代理仅须装载它正处理的分区。该分区的并行执行意味着可能昂贵的fsd的该方面，可以缩放到非常大的系统。动态fsd配置。一直运行诊断可能是昂贵的。例如，如果冷却系统正在恰当地冷却并且不使用过度功率，则可能没有需要监控系统的每个组件。在该示例中，可以存在与这些关键“端对端”度量以及被设置为系统不适当执行的根本原因的征兆相关联的阈值。例如，可以存在根本原因“过度能量消耗”，其由系统在功耗上超过阈值来触发。响应于该顶级根本原因，新的fsd过程实例可以被发动，其被配置成对该过度能量消耗在根本上定因。它然后可以处理各种组件的传感器以对该问题进行根本原因分析，其可以包括冷却剂泄漏、压缩机过度循环、脏线圈等等。fsd处理实例可以被配置成在一段时间之后、当没有根本原因的时候退出，将系统返回到仅仅在根本上引起顶级端对端根本原因的状态。示例性用例：网络诊断。通过使用以上实施例，用于给定网络的网络诊断的fsd需要遵循在上述通用教程中为每个这样的网络所描述的步骤。还存在特定于网络诊断的参数，如将在以下所描述的。无限制地，该用例示出了如何可以通过所公开的技术来解决特定用例。特别地，应当为每个交换机上的每个接口或网络中的其它设备定义征兆。然后可以为该网络定义rct，具有针对该网络中每个可能的根本原因故障的行。这特定于网络的特定部署，因为征兆和rct应当覆盖网络中的每个设备，这随网络变化。rct应当在一些情况中捕获由特定网络拓扑所引起的相关性。例如，如果链接的一端检测到故障，但是另一端没有，相对于当两端都检测到给定故障的时候，诊断可以不同。在一个实施例中，分离的程序根据网络拓扑描述来生成fsdjson配置文件。如在上述通用教程中所描述的，fsd可以提供对该任务的某种支持，这通过允许你定义可以利用特定自变量被实例化的类型。诸如“叶片交换机”之类的各种“单元”类型可以依据诸如接口、边界网关协议（bgp）连接等等之类的组件而被定义，所述组件依据组件类型被定义，所述组件类型进而依据度量被定义，所述度量各自具有其自己的相关联的通用征兆集合。类似地，fsd支持一个或多个“行模板”的定义，所述行模板在本文中被定义为模板以有助于减少在定义rct行中的冗余。例如，可以为“叶片交换机”定义“行模板”，并且然后为网络中的每个叶片交换机实例化它。这支持json配置文件的大小，这对于fsd启动时间是有益的。考虑到配置文件由某个分离的程序根据网络拓扑描述自动生成，该能力不一定减小写入这些配置文件的时间。该教程描述了用于定义fsd配置以用于计算机网络诊断的一般途径，其开始于网络特定的故障状况/征兆。配置开发策略。建立于以上通用教程策略区段中所描述的开发策略之上，用于网络的起始点是标识并且列出可能发生的根本原因故障。在计算机网络中，存在用于功能性和机制的多层，例如物理接口层、链接层、输送、路由、叠覆等等。例如，物理接口层征兆可以是“downwhenconfiguredup（当被配置为运转时停止运转）”。注意到“链接停止运转”不是故障状况/征兆，除非它应该是运转的。在诸如bgp之类的较高层，可存在征兆“holdtimerexpired（保持定时器期满）”。有价值的是将征兆结构化到常规网络层中，因为较高的层一般依赖于较低的层。开始是首先定义最低层处的征兆，并且逐渐达到较高的层。这是因为较低层故障通常生成较高级别征兆。为了抑制这些较高级别征兆触发故障根本原因，应当定义较低层征兆，因此它们可以在与较高级别根本原因故障场景相关联的“notsymptom（非征兆）”集合中被指定。在一些情况中，应当为近邻交换机接口指定这些较低级别征兆，用以抑制假阳性。例如，如果近邻使其接口在它应当运转的时候被配置成停止运转，则它不是bgp根本原因。征兆。下一步骤是定义网络度量类型以提供网络需要的征兆。这允许在诸如接口之类的组件以及诸如包含接口集合的交换机之类的单元中的度量的定义然后在fsd中实例化这些交换机，因此在网络中每个设备的每个接口中存在为每个可能的征兆所定义的征兆。例如，如果存在交换机“交换机004”和接口“eth4”，则存在switch004/eth4/link/downwhenconfiguredup（交换机004/eth4/链接/当被配置为运转时停止运转）征兆。一个建议的途径是定义与可观察的状况相对应的征兆，无论是直接通过传感器输入还是独立地通过根据直接输入来计算。该可观察性排除诸如断开线缆之类的故障，假定线缆上没有传感器。然而，可以通过根本原因分析来标识不可观察的故障，如稍后所描述的。以下概述可以用作起始点的某些度量类型。网络征兆度量类型：•误配置度量◦误配置：▪配置误匹配◦运转停止运转配置：▪当被配置为运转时停止运转▪当被配置为停止运转时运转◦开启关断配置：▪当被配置为开启时关断▪当被配置为关断时开启◦计数器度量▪恒定▪零▪低▪过度变化▪峰值高▪高•物理层◦未能同步◦同步的周期性损耗◦同步的持久损耗•链接层◦很少rcv错误◦一些rcv错误◦许多rcv错误◦总rcv错误◦瞬时tx超时◦频繁tx超时•lldp•bgp-各种bgp错误代码可以是起始点，诸如◦保持定时器期满◦对等解除配置•mlag网络组件和单元类型。用于网络的rct配置文件可以将一个或多个接口定义为组件类型。大多数征兆相关联于接口，因为具有相关联软件的接口是故障的观察点。通常不存在与交换机之间的线缆或导线相对应的组件类型，因为没有故障可以在线缆上被观察到，仅仅通过根本原因分析。每个接口类型可以定义与不同网络层对应的若干不同度量，如以上所开发的。用于网络的rct配置文件通常将一个或多个交换机定义为单元类型。每个交换机类型需要显式地指明交换机的每个接口实例。例如，对于32端口的叶片交换机，在“叶片交换机”的单元类型定义中，接口类型被实例化32次。难以为该情况提供迭代构造，因为每个接口具有不同的近邻，因此每个实例化都稍微不同。在叶片-主干网络中，可以存在至少两个交换机类型，一个对应于叶片交换机或tor，并且另一个对应于主干交换机。交换机类型中的每一个被实例化在实际网络中可能出现的次数。因此，如在以上通用教程中所述，fsd按交换机接口、层和故障来生成特定征兆。网络rct定义。可以一般地如在以上通用fsd教程中所述的那样来定义rct。关于网络特定的方面，通常存在用于每种类型交换机的行模板。行的数目可以等于接口的数目乘以与每个接口相关联的根本原因的数目。例如，如果所讨论的交换机模型具有32个接口，并且七个根本原因故障相关联于接口，则有在用于该交换机的行模板中所定义的224行。如果在网络中存在16个这样的交换机，则该行模板被显式地实例化16次。需要用于每个交换机的行模板的显式实例化，而不是提供迭代构造，因为每个交换机的连接性是不同的。例如，每个叶片交换机连接到主干交换机上的不同接口。在网络行模板情况下的一个惯例是要指定参数使得每个偶数编号的自变量是接口的名称，并且下一个奇数编号的自变量是设备和它连接到的接口的名称。例如，如果spline0没有连接在eth0上，但是连接在eth1上到leaf0::eth0，并且到eth2上的leaf1::eth0，则spline0的实例化中的自变量是：“自变量”：["eth0","","eth1","leaf0/eth0","eth2","leaf1/eth0"]在eth0之后的空自变量字符串指示了它没有被连接。在行模板中，可以存在仅仅在接口被连接的情况下有意义的行。在该情况中，另一端的名称可以被包括在行模板中。然后，如果对应于该名称的该自变量在自变量列表中是空的，指示了它没有被连接，则该行可能不是在fsd内部生成的。例如，如果第一接口上的同步的链接级别的损耗在用于交换机的行模板中被指定为："$/$0-$1/linksync/unilossofsync":{"symptom":["$/$0/linksync/persistentlossofsync"],"notsymptom":["$/power/low","$/$0/intfconfig/configmismatch","$/$0/linkconfig/configmismatch","$1/linksync/persistentlossofsync"]},然后，当$1时，不生成该行，指定另一端的自变量是空的。可以在fsd中将它标记为错误以具有使用为空的自变量的行模板中的行，除了在行的名称中之外。也就是说，将该自变量插入到行的名称中实际上充当对于生成行的守卫条件。网络指示符。一些网络指示符是数字度量，其中依据处于某个阈值范围外来定义征兆。例如，交换机接口可以报告传输丢包率。当丢包率超过某个配置的阈值的时候，设置征兆。在这样的度量的情况中，可以为每个接口定义指示符，其包括该值和到sud场景的阈值映射，所述阈值映射在值移动到该范围外的时候设置相关联的故障状况/征兆。该途径可应用于许多度量，诸如交换机cpu利用、接收的错误等等。指示符值可以直接从设备被报告，或可以根据某种聚合、诸如移动平均而被计算。在一些情况中，可能合期望的是提供多个阈值级别，具有相关联于每一个的不同征兆。在一个实施例中，fsd支持多级别阈值映射。在其它情况中，所报告的观察是二元的，诸如接口被配置成运转或停止运转。在该情况中，停止运转/运转二元指示可以被映射到相应为0和0.1的指示符估计值上，并且简单的阈值映射可以在指示符是0并且接口应该运转的时候将值映射到征兆上。可替换地，每个指示符可以提供一模式，所述模式可以指示：指示符是否相关。例如，如果接口没有被使能，则模式可以是0，其指示正常阈值不适用。在一个实施例中，fsd支持位集合指示符和位集合映射，所述位集合指示符表示多个二进制的值，所述位集合映射将没有如预期那样设置的每个位映射到sud场景中指定的故障状况/征兆。这减少具有网络中所需的大量指示符的空间开销。分区。针对网络的征兆和特定根本原因的总数目可能是巨大的，成千上万。因此，对状态和处理进行分区是有某种吸引力的。一个问题是：网络的连接性不允许通过不同交换机的干净分区。例如，在叶片交换机和主干交换机之间的诊断可能不容易分区，因为它们被连接，并且准确的诊断需要考虑线缆的两端。可替换的途径是按层对网络诊断进行分区。物理网络和虚拟网络层可能需要这个，因为这两个可能具有不同的拓扑。在该情况中，物理网络诊断可以向每个虚拟网络诊断指示故障或不存在故障。然后，如果虚拟网络诊断可以将物理层故障（如果有任何的话）映射到虚拟节点上，则虚拟网路诊断将这些物理层故障视为输入数据。例如，如果在物理层中的交换机s1和s2之间存在拥塞，并且这些对应于虚拟交换机vsi和vsj之间的链接的部分或全部，则该情形可以被反映到虚拟网络诊断中，作为关于vsi到vsj连接性的指示符。相反，来自物理网络的不存在征兆、即征兆值是假的可以指示：虚拟网路问题不可以指定的置信度被归因于底层物理网络。可能可行的是还在链接层和更高层之间对物理网络诊断进行分区。链接层诊断可以检测网络拓扑中直接连接的近邻之间的连接性中的故障，并且在不存在这样的故障的情况下，指示网络连接性问题以高概率是由于更高层处故障所致。该分区实际上使用多层根本原因分析，其中的层是网络协议层，而不是细节层。可以可行的是使用分层的这两方面的组合。也就是说，可以为不同的层建立rct，并且然后在每层内，可以为不同级别的细节建立分离的rct。在一个实施例中，存在两个级别的细节：一个用于它是否基本上正确地运作，并且另一个用于当第一级别检测到该级别没有正确运作的时候的详细根本原因。该分区主题是令人感兴趣的，因为将诊断缩放到大规模网络具有关键的重要性。接下来考虑一些缩放分析。缩放。考虑具有100,000个端点的网络，于是存在近似250,000个链接端点。每个链接端点可以具有故障状况/征兆的8个不同块，每个各自花费32位，假定每块不多于32个故障状况/征兆。故障场景表示中的每个非默认条目可具有附加开销，因此每个非默认条目的空间是20字节。因而，故障场景在最坏情况中可以是40百万字节。注意到，很可能许多状况在正常操作中已知为假，这对于抑制没有关联的原因是重要的，因此预期sud故障场景粗略为该大小。考虑到rct，每行的大小将取决于潜在故障中所涉及的设备的数目。对于大多数网络故障状况/征兆，“被关心”的状况在很大程度上与点对点网络成对，也就是说，什么状况在链接的一端相对于另一端为真。每个这样的行在上层情况中可需要粗略地每层两条目，其中当下层无故障时，可以诊断上层故障。因而，假定八层，每行可以大约为8×2×20字节或小于一千字节。因而，可以存在粗略地100,000个链接以及8层，因此800兆字节的rct用于该拓扑有关的故障分析。该估计是细化的较低，因为一些行用于较低层根本原因，在该情况中对于较高层存在不用在意值，因此那些条目不存在。因此，正常的商品服务器能够存储sub故障场景和rct，甚至是对于非常大的网络。关于处理开销，大多数行可能不快速匹配，因为很少的行应当实际上具有匹配的征兆。在一个实施例中，fsd并行地执行根本原因表匹配，如在以上通用教程中所提及的。注意到，fsd不重运行根本原因表匹配，除非sud场景自从执行匹配的上一次以来实际上已经改变。因而，在不存在征兆的情况下，或如果征兆不改变，有用于运行fsd的很小开销。总结。在该示例中，fsd为显著大小的网络中的问题的高效诊断提供基础，提供根本原因分析，而同时避免来自级联故障的没有关联的假阳性。该诊断取决于在征兆、rct、指示符和输入映射方面对fsd配置的仔细定义。该谨慎的部分意味着仔细选择征兆，以及规范在故障场景方面的根本原因，其考虑以层对诊断的分区，以及fsd的执行频率，从而提供负责的响应时间。示例性用例：一般实现方式。考虑通过fsd代理（504）的基本处理流。按时的处理流以及计时。处理流以及fsd的计时可以如下被处置。输入模块。input::main::process（输入::主::过程）协同例程中的输入模块可以每输入时钟回合地循环，其在每个输入适配器上迭代。每个“每输出回合的输入回合”，它更新outputclockindicator::estimatedval（输出时钟指示符::估计值）以触发scenariogen处理。注意到，指示符用于输出时钟，因为它是可用于输入和场景模块二者的接口。input::main::process（输入::主::过程）协同例程中的输入模块具有每输入源的输入适配器实例，并且等待直到每个适配器已经进展通过当前输入回合，如由“前进输入”属性变成零所指示的。每个输入适配器从定时的数据源读取，将输入源中每个感兴趣的度量映射到指示符，为每个输入回合而将值调节到输入时钟回合时间。对于具有非零预测增量的输入度量，输入模块为该度量使用正好在当前输入时钟回合时间之前的输入值与在当前输入时钟回合时间之后的下一个输入值之间的线性内插——如果所述线性内插可用的话——并且否则使用外推。特别地，每个输入适配器当它指示了它已经完成该输入回合的时候可能已经在当前输入时钟回合时间之前进行了读取。如果“预测增量”是0，则可以假定该度量是离散的，并且所使用的值是在当前输入回合时间之前或同时的最后一个。在通过使用“输出时钟（outputclock）”指定了新的输出时钟回合之后，协同例程等待直到scenariogen::lastoutputround（scenariogen::上一输出回合）被递增，其指示了scenariogen和match（匹配）已经完成了输出回合。scenariogen模块。scenariogen可以被触发以执行指示符值到实际故障场景上的映射，其通过输入模块更新输出时钟（outputclock）的indicator::estimatedval（指示符::估计值），如上所述。该属性在每个输出时钟回合上、由输入模块利用输入处理的当前sud时间的tac::seconds（tac::秒数）中的值被写。scenariogen模块在映射上迭代，将每个映射的指示符映射到实际故障场景中，并且然后，如果sud故障场景已经改变并且经过了预热时段，如由上一预热回合（lastwarmupround）所指示的，则更新match::config（匹配::配置）接口中的更新时间（updatetime），使得匹配模块执行匹配。它然后可以等待直到匹配模块改变，其指示了它已经完成了rct匹配，在该点处它递增scenariogen:agentdb::lastoutputround（scenariogen:代理db::上一输出回合）以向输入模块指示它已经完成了该输出回合。匹配模块。匹配（match）模块可以被触发以执行匹配，这通过对config::updatetime（配置::更新时间）属性的更新，其此外指示指示符的sud时间和实际故障场景。它由scenariogen、利用与输入数据的输入处理时间对应的sud时间来更新，所述输入处理时间是对应于输入数据被处理的sud中时间。可以预期/要求它单调增加。匹配模块然后可以执行实际故障场景到rct的匹配，并且然后指示它已经通过利用该sud时间写入而完成了它的处理。fsd可以被设计使得匹配模块可以作为分离的过程被执行。因而，如果在匹配过程中对实际故障场景拍了快照，则输入和场景模块可以在正执行匹配的时候并行继续进行到下一回合。还可行的是并行执行多个匹配过程，其中每个取rct的不相交部分来对照着匹配。接下来，考虑模块的一般结构。模块结构。每个模块可以被结构化为顶部（top）实体，其充当对于模块的调用状态接口。它们可以包含初始化属性，加上用于控制给定模块的各种过程。特别地，每个都包含initconfig（初始化配置）和commitconfig（提交配置）过程。所述“初始化配置”过程可以引起模块的基础初始化，而不实例化实现约束器。“提交配置”过程基于配置属性而完成初始化，从而实例化实现约束器。如果在没有首先调用“初始化配置”的情况下调用“提交配置”，则它首先在内部调用“初始化配置”。该顶部调用状态接口支持对这些模块的python访问，以用于python控制的执行、动态配置和调试。每个模块具有agentdb（代理数据库）实体，所述实体指定跨代理重启将在sysdb（系统数据库）中预留的状态，也就是说，该状态可以被挂载到sysdb中。该结构可以是用于每个模块的标准代理结构。该途径用于允许“匹配（match）”作为分离的代理过程被运行。它还提供模块性以及模块之间的封装。注意到，input（输入）、scenariogen和match（匹配）是处理路径模块。config（配置）可以是用于配置该处理流水线的模块。fsd:场景、根本原因表和指示符。该模块可以定义基本场景、根本原因表、和指示符类型定义加上有关的值类型，以及场景上的操作。场景操作可以包括：•克隆；•融合；•解融合；•下一已知征兆、下一故障状况、下一非故障状况；•设置征兆；和/或•清除征兆-使它未知根本原因表（rootcausetable）可以是场景（scenarios）的集合加上征兆名称到征兆索引以及反之亦然的映射。fsd::指示符（fsd::indicator）实体是度量的内部表示。它可以记录所述度量的估计值（estimatedval），与该度量相关联的模式，由该度量根据其输入所假定的任何故障场景，以及其值中的置信度。在一个实施例中，所述值被表示为f64以用于统一性以及易于计算。如果它是整数值，则预期48位尾数足以执行准确的整数算术。调试支持。可以存在fsd::陷阱（fsd::trap）类型，其被实例化为派生类型并且传递到scenariogen阶段中。“场景”（scenario）提供非存记的“陷阱”（trap）属性，从而允许在场景上设置陷阱，即使从sysdb挂载。还可以在rct本身上设置陷阱，以对未能将真故障状况/征兆匹配到rct中的任何事物设陷阱。fsd::match（fsd::匹配）。该模块可以实现实际故障场景到被聚合到rct中的潜在故障场景的集合的arca匹配。它可以在场景上实现附加的操作，即：1.匹配；和/或2.componentfcnextdiffentry-差注意到，rct的行中的每一列被称为征兆，因为：i)那是rct中使用的常规术语，以及ii）它在rct中被定义，因为需要它作为根本原因分析/匹配的部分进行标识和/或解释清楚。此外注意到，征兆以其本身而言可能不一定是故障状况。匹配（match）约束器可以被触发以执行或重执行匹配，并且通过更新fsd::config::updatetime（fsd::配置::更新时间）而利用当前根本原因来更新fsd::rcastatus。它可以具有对实际故障场景、sudscenario的只读访问，并且执行匹配。fsd::match（fsd::匹配）可以允许代理被配置成仅仅作为匹配代理而运行，即，只读挂载fsd::config（fsd::配置）和rct，并且作为分离的过程而执行匹配，从中执行输入和实际场景生成。fsd::scenariogen“恒定”检测。在某些操作模式中，可预期指示符在某个时间段上改变其值。例如，如果系统正运行，冷却系统的温度读取应当很可能随时间改变。停留在确切相同值处的指示符通常是对以下的指示：传感器故障，或无能力从传感器读取/连接到传感器。在一些情况中，如果指示符不在某个最小量之间改变，则它还是问题的指示，这考虑到传感器对可重复性进行限制，也就是说立即再次读取传感器不确保提供确切相同的值。为了支持这个，scenariogen模块追踪指示符自从上一输出回合以来是否已经改变。如果没有，则它可以调用agentdb::indicatormap::updatemappingonunchanged（代理数据库::指示符映射::在未改变时更新映射）来对此进行指示。合理性。agentdb::indicatormap::updatemappingonunchanged（代理数据库::指示符映射::在未改变时更新映射）调用确保映射有效地能够随时间流逝而执行，即使没有对其指示符的改变。存在另一情况：某个指示符必须在最小时间段内保持在某个状态中。调试支持。接口可以提供setrcttrap（设置rct陷阱）和setmaptrap（设置映射陷阱）用于分别在rct上和所指明的映射上设置陷阱对象。可以根据状况（condition）值来调用trap::handle（陷阱::处置）过程，所述状况值是一个或多个标记。fsd::input（fsd::输入）指示符值计算。输入适配器可以为输入值计算一阶导数，从而在每个可接受的输入读数之后调节该一阶导数。在一种形式中，这被计算为在上一读数和下一读数之间的增量，除以在这两个读数之间的sud时间增量。被写到指示符的值于是可以是比当前输入回合时间更早的上一个读取的值，加上所述一阶导数乘以时间增量，从而将该上一个值外推到输入回合时间。因此，如果输入时钟回合比输入数据样本时间更短，则适配器可以基于以上内插来估计中间值。另一方面，如果输入时钟回合比输入数据回合更长，则中间输入数据回合可以用于细化所述一阶导数值。fsd::input（fsd::输入）：指示符操作符。输入模块支持对指示符的各种操作符，诸如最小值、最大值、求和、求平均值、求差等等。在对indicator::estimatedval（指示符::估计值）的更新时，该指示符作为输入所用于的每个指示符根据其相关联的操作符而被更新。可以存在各种输入适配器，如接下来所描述的。fsd::input（fsd::输入）：事件日志。可以存在处置事件日志输入的输入适配器。eventlog::intf(事件日志::intf)遥测事件。来自对eventlog::intf::event（事件日志::intf::事件）的更新的每个通知可以触发对eventlogadapter::handletelemetryevent（事件日志适配器::处置遥测事件）过程的调用。如果需要来自事件日志的更多输入，则eventlogadapter::advanceinput（事件日志适配器::提前输入）过程可以解挂事件日志的输入处理，并且否则仅仅根据先前读取的输入遥测数据来生成对相关联的指示符的接下来的输入。eventlog::intf(事件日志::intf)非遥测事件。在事件日志中还可以存在对于处置非遥测事件的支持。csv重定向到eventlog::intf(事件日志::intf)。csv适配器可以被重定向以将其输入转化到事件日志接口中，如由适配器eventlogintf（事件日志intf）属性非空所指示的。这可以用于测试“事件日志”（eventlog）输入处置。csv适配器。适配器可以使用输入数据格式，包括时间、地点/单元/度量，或传感器加上值。csv适配器可以在输入样本上迭代以细化针对其各种指示符的一阶导数，直到它读取到针对比当前输入回合更晚的时间的输入为止。它然后保存该上一输入，并且然后通过使用这些一阶导数而将针对输入指示符的值外推到该回合的时间。输入适配器可扩展性。可以通过定义input::main::adapter（输入::主::适配器）的派生类型来定义附加的输入适配器类型，所述input::main::adapter覆写adapter::advanceinput（适配器::提前输入）来提前用于其数据源的输入处理，从而处置当前输入回合。它还可以覆写adapter::setsyncpoint（适配器::设置同步点）来保存在代理重启时在agentdb（代理db）中需要是持久的任何值。它还可以覆写adapter::handledatainexceptionid（适配器::处置例外id中的数据）以对输入字节连接上的例外id（exceptionid）作出反应，如果该例外id出现的话。fsd::config（fsd::配置）时钟配置。fsd::config::setclockconfig（fsd::配置::设置时钟配置）过程可以用于指定“每输出回合的微秒（microsecondsperoutputround）”和“每输出回合的输入回合（inputroundsperoutputround）”。fsd::config::setdiagnosisinterval（fsd::配置::设置诊断间隔）可以指定分析的起始时间、结束时间，这二者都以sud时间，以及预热时间间隔。预热时间间隔如果非零的话可以使得fsd在比起始时间更早的时间开始处理输入数据集，但是仅仅在一旦输入时间达到起始时间的时候才开始输出处理。例如，在60秒预热时间的情况下，输入适配器在比起始时间更早的60秒开始于它们的数据集，并且因而在执行任何输出处理之前“预热”fsd指示符中的状态。该能力可以用于在随机时间开始fsd处理，而不是根据上一状态和fsd代理的sud时间来继续执行。可扩展性。fsd代码可以可扩展到任意数目的故障状况/征兆、根本原因规范，以及还有新映射和操作，如下所述。rct和fc可扩展性。应用可以任意地扩展征兆的数目。它还可以扩展在这些征兆方面的根本原因的定义。例如，应用可以具有“过度温度”的初始概念，其可以稍后被细化成“轻微过度”，“中等过度”和“极度过度”。类似地，可以通过提供“短时间内的过度温度”、“中等时间内的过度温度”等等来引入时间元素。当将指示符映射到sud场景的时候，这些附加的经细化的且构成的征兆可以对应于值和时间二者中的附加阈值。很可能被一起设置的征兆可以从索引的相同mod32块内的效率立场来被最佳指定。指示符映射可扩展性。fsd支持可扩展性以添加附加形式的指示符到sud故障场景的映射，超出：恒定值映射、离散映射、基于阈值的映射以及如上所述的估计值（estimatedval）映射。因而可以扩展附加的映射。为了这样做，存在两个关键模块，用以更新：fsd::scenariogen模块和fsd::config（fsd::配置）。fsd::scenariogen.fsd::scenariogen映射扩展步骤包括：1.定义类似于thresholdmap（阈值映射）的fsd::scenariogen::agentdb::indicatormap（fsd::scenariogen::代理db::指示符映射）的新派生属性和类型，从而定义该新映射所需的参数；2.提供两个相关联过程的实现，包括updatemapping（更新映射），其在相关联的输入被修改的时候被调用，从而将改变的数目返回到sud场景故障状况/征兆；和/或3.在fsd::scenariogen::top（fsd::scenariogen::顶部）接口中提供“设置”过程，以用于设置新类型的映射。注意到，scenariogen模块可以预期参数已经被检查并且仅仅中止问题；在无配置的情况下，它不提供用户错误报告。注意到，映射可以独立于输入指示符模式，或者能够是可配置成不同模式的。此外，在相同指示符上可以配置多个相同映射，为每个感兴趣的模式一个。fsd::config（fsd::配置）fsd::config（fsd::配置）映射扩展步骤包括：1.在fsdconfigimpl.tac文件中添加indicatormappingjsonconfig::map（指示符映射json配置::映射）的派生类型；2.扩展topimpl::initindicatormappingsfromjsonconfig过程以从json初始化该新映射；和/或3.在fsd::config::top（fsd::配置::顶部）接口中提供“设置”过程，以用于设置你的新类型的映射。注意到，该过程可以在某个错误检查之后调用scenariogen::top（scenariogen::顶部）过程，并且不改变scenariogen::agentdb（scenariogen::代理db），因此它在代理处于执行中的时候可以正确地运作。指示符操作符可扩展性。fsd可以支持可扩展性以添加附加的操作符，超出：求和、持续时间、求平均、最大值、最小值、标准偏差、和差异以及“输入”的伪操作符，如上所述。添加附加操作符的过程包括两个关键模块以更新：fsd::input（fsd::输入）模块和fsd::config（fsd::配置）。fsd::input（fsd::输入）fsd::input（fsd::输入）映射扩展步骤包括：1.为该新的操作符向fsd::op（fsd::操作符）枚举添加值；2.向input.tac添加input::agentdb::indicatoropbinding（输入::代理db::指示符操作符绑定）的新派生属性；3.在fsd::inputimpl.tac文件中添加input::main::outoperator（输入::主::输出操作符）的新派生属性，从而覆写基本类型中的handleestimatedval（处置估计值）过程。当相关联的输入indicator::estimatedval（指示符::估计值）属性改变的时候，该过程应当更新输出；和/或4.扩展fsdinputimpl.tin中的main::configindicatorop（主::配置指示符操作符）过程，以处置对该新操作符的配置，加上实现该文件中的handleestimatedval（处置估计值）过程。fsd::config（fsd::配置）fsd::config（fsd::配置）操作符扩展步骤包括：1.向fsdconfigimpl.tac中的indicatorjsonconfig::operator（指示符json配置::操作符）枚举添加针对操作符的枚举值；和/或2.扩展topimpl::initindicatorsfromjsonconfig过程以当在文件中指定的时候从json初始化该操作符。注意到config::top::bindoperator（配置::顶部::绑定操作符）过程在以上改变的情况下以新操作符而运作。fs代理重启。在一个实施例中，重启时的第一步骤是只读地挂载rct。第二步骤是重挂载以用于写入指示符。然后可以在本地重创建sud场景。它不需要跨重启地被预留，因为它直接通过向sud场景的指示符映射来被设置：1.实例化输出接口以及对此作出反应的任何本地处理；2.挂载/实例化rct；3.实例化输入处理器，其指定要使用的输入适配器；4.在该输入处理器中实例化输入接口；5.实例化经计算的指示符；和/或6.映射一个或多个接口和/或指示符。交互式fsd。在一个实施例中，交互式运行fsd用于为给定数据集而测试和调试fsd。它基于：1.pythoncmd包-如在/src/taccdebugtools/tacprobe中所使用的；和/或2.python封装器，如在/src/taccdebugtools/probefacility.py中所使用的那个连接事件机制可以用于完成。在一个实施例中，fsd管理器以c++速度运行fsd，并且仅仅挂起执行，当它这样做的时候通知cli/python。cli可以并发地查询或监控fsd执行，即，当fsd正执行的时候，或它可以在管理器中设置参数以使得执行被挂起，或停止。总结。测试。在一个实施例中，fsd包括各种特征以允许通过使用特殊json配置文件和输入数据文件的自测试。映射测试。阈值测试可以通过具有输入指示符上的阈值映射来完成，所述输入指示符被映射为输入数据文件，所述输入数据文件生成处于阈值边界上的值。rtc陷阱（rtctrap）可以被定义以将预期的陷阱映射到预期的计数（expectedcount）上并且将其它的映射到非预期的计数（unexpectedcount）。操作符测试。每个操作符测试可以被结构化为配置文件和输入文件。在一个实施例中，配置文件配置fsd代理以具有：1.用于测试下的操作符的“结果”指示符，用于该操作符的输入中每一个的指示符，“预期结果（expectedresult）”指示符，和“差异”指示符；2.阈值映射，其在差异指示符示出大于0、或某个可接受阈值的值的情况下设置征兆；和/或3.具有动作的rct陷阱，所述rct陷阱指定isincrementingunexpectedmatchcount（为递增非预期的匹配计数），其在与对应于以上阈值映射状况的rct行的匹配上设置陷阱。rct文件对于每个操作符测试可以是相同的。指示符文件可以仅仅在测试下的操作符中是不同的，即结果节点与其参数数量。在一个实施例中，使用具有某个操作符置换的binaryoptestindicator.json，其中操作符恰当地处置每个不同模式。指示符映射可以仅仅在最小/最大值中不同，即允许结果自预期结果变化。通常，该差异可以是零。输入绑定和计时可以按输入数据文件、运行时间以及计时而变化，如果在输入时钟和输出时钟之间存在差异的话。陷阱信息一般是相同的。输入文件可以包含经时间索引的、经字段命名的值的序列，所述值指定在给定时间的每个输入的值加上该时间处的预期操作符输出值。这通常以csv格式，但是其它格式也可以被支持/使用。输入绑定json文件可以将适当的字段名称绑定到输入指示符。测试故障可以通过如下被指示：在sudscenario中生成根本原因，从而递增unexpectedmatchcount（非预期的匹配计数），如由在rct的相关联的行上所指定的陷阱检测到的。rct上的陷阱可以用于检测其它非预期的匹配。注意到，rct上的陷阱检测行的匹配，而映射陷阱通过特定的映射而指示动作。还注意到：1.可以通过相同的配置和输入文件来测试多个操作符。事实上，相同的输入可以被提供给多个操作符；2.对于在回合/时间上应用的操作符，比如求和、求平均、持续时间、输出时钟可以用比输入时钟更低的频率运行，对应于在其上计算输出值的回合的数目；和/或3.使用阈值映射而不是监控操作符指示符的确切输出是重要的，以具有根据输出时钟的监控工作，并且避免出自结果指示符的瞬时值。在一个实施例中，假定差异操作符加上rct、映射、匹配和陷阱机制运作。使输入和预期结果二者都被存储在相同输入文件中的途径减少对于测试所需的文件的数目。测试可以包括用于以下各项的命令行测试：恒定测试和阈值测试，以及估计值映射，以及指示符操作符测试，诸如预测限定符操作符测试和步进函数测试。附录：实现方式基本原理。故障场景表示可以被使用，因为它可以表示同时发生的多个征兆，要么独立的要么级联的。因此，来自多个代理的输入可以被融合以产生组合的或融合的场景，所述场景包括来自二者的征兆。它还可能由于两个征兆之间的不确定性而出现。例如，如果温度不良，则不知道这是因为温度传感器故障，是因为制冷出故障，还是因为二者都有问题。因而，可以存在与两个状况之一为真相对应的征兆。它也可以被使用，因为根本原因分析通常需要看同时为真或为假的多个征兆。例如，当没有功率的时候，可能没有诊断压缩机故障，即，功率征兆应当是假的，但是缺压缩机活动应当是真的。rct被实现为潜在场景的集合，每行一个，从而利用场景用以表示多个故障状况/征兆的能力。可以对照这些潜在场景中的每一个来匹配实际场景。场景还可以对应于不应当发生的某个情况。例如，报告其中功率丢失但是压缩机过度循环的故障没有逻辑意义。为了处置这个，rct可以包含一行，该行匹配/映射到“不应当发生”的错误状况。所述场景在以下意义上通常是“部分”场景：一些征兆状态不已知，或在rct中，是不用在意值。场景表示。在一个实施例中，所述表示处置假、真和不用在意/不知道/未知。也就是说，不是简单的每征兆一布尔。fsd处置大量场景，因而表示应当是紧致的。许多场景可能仅仅具有已知的一些征兆。因而，需要稀疏集合。具有针对“已知”的分离集合以及稀疏的征兆集合在空间和时间上将会是昂贵的，这考虑到每条目的空间成本和所涉及的双重迭代。使用有效位及其对应的值位的“块”，例如在一个实施例中各自32位，意味着每条目的空间开销很可能从两个指针加上索引加上两个布尔增加、或22字节增加到28字节。因而，在完全稀疏的情况中，开销粗略大百分之二十五。然而，当在相同块中存在多个征兆、即某种密集的时候，该开销被减小。此外，如果非常密集，则空间开销可以仅仅加倍或更少，而严格稀疏的表示可引发176×的开销。有效掩码和相关联的征兆值的经组合的子块的块的表示意味着可以一次跳过一字节、八个条目的子运行。“传感器融合”在本文中被定义为组合多个不同的传感器输入，使得结果与这些源被单独使用的情况相比具有更少的不确定性。然而，通过组合多个源，还被暴露于多个故障的可能性。通常，系统有些不对劲可能不被证明，除非知道系统特定的什么事物不对劲，除了以下情况之外：它“致命地”坏了，即不在限制内运作。一种途径是使用一矩阵，所述矩阵具有作为行的根本原因以及按征兆的列。因而，如果检测到所有征兆，则匹配的行指示可能的根本原因。然而，征兆一般被定义为主观度量。它不导致对场景的简单表示。代替地，故障或对于故障场景的征兆被定义为布尔型，其具有未知或不用在意的附加值。因而，并不是在征兆的表中具有诸如“温度超过10c”之类的条目，而是故障场景具有与该状况对应的征兆，其是真或假或未知的。因而，模型是：依据这些三元征兆以及征兆到根本原因的常规映射来完全地指示场景，从征兆的数组或行到场景集合的变换可能地在不同平面或语义上。例如，坏掉的风扇传动皮带可被视为“根本原因”，但是也可能将它视为故障，并且问到为什么风扇传动皮带坏了。多个故障、诸如老旧的风扇传动皮带、过度占空比、以及或许过热的风扇轴承可能暗示根据此故障的根本原因。也就是说，一个组件的根本原因可能是另一个级别的故障。在某种程度上，存在与任何给定时间的故障场景对应的潜在根本原因的大集合。诊断过程和匹配的作用是要将该集合缩减到小数目，所述小数目与来自传感器的指示一致，匹配器对其具有信心。在该意义上，它可以被视为消除过程。rct匹配途径。在一个实施例中，匹配途径是要在实际故障场景已经改变并且它处于新输出时钟回合中的时候，在rct中的所有行上迭代。当有可能实际故障场景中的改变尚未改变任何可能的根本原因或仅仅移除了一个可能的根本原因的时候，这可能是相当强力和过度的。然而，确切追踪在什么征兆的情况下影响了什么行可能是相当复杂的。看起来容易检测的一个特殊情况是当在实际故障场景中没有已知征兆的时候。然而，不预期这在大多数应用中发生，因为一些征兆已知是假的，甚至是在没有问题的sud中。填充未知。在一个实施例中，如果除了场景中的某种未知之外场景匹配，则fsd动态地创建/扩展输入和计算网络已产生针对该未知的应答。例如，如果除了短循环征兆未知之外场景与行匹配，则fsd可以在内部构造场景映射/网络，所述场景映射/网络提供：来自配置规范的该征兆，即电流读数到“起始到起始”持续时间到阈值监控器，产生短循环征兆。这可以被视为相关性：1.短循环fc取决于对于“起始到起始”持续时间的阈值配置；2.由具有压缩机模式作为输入的聚合代码提供“起始到起始”；和/或3.由压缩机电流输入度量提供压缩机模式。处置相关性。在一个实施例中，不同征兆之间的相关性由rct行中的假征兆和真征兆二者的规范来处置。例如，如果电路上的功率丢失可影响传感器s1和s2二者，则对应于传感器s1出故障的行可要求对于该电路的“功率出故障”征兆为假的。否则，功率故障可被诊断为传感器故障。另一方面，如果s1和s2二者都看似运作，然而传感器电路上的电流传感器指示无功率，则可以推断：电流传感器很可能已出故障。在一个实施例中，fsd预期这些相关性在rct的配置中被识别。这些相关性通常是已知的，因为它们起初在sud的设计中就被引入并且考虑，不像用于根本原因分析的传统机器学习途径。置信度和多个实际故障场景。在一个实施例中，fsd支持同时的多个“实际”故障场景，每个对应于传感器输入的不同解释。通常，不同的解释是以下中的一个：i)传感器输入是正确的，或ii)传感器输入不是正确的。这是因为，在工程系统中，如果传感器输入是正确的并且适当地测量了sud的状态，则sud的状态是已知的，因此没有不确定性。然而实际上，传感器输入不总是正确的，并且不知道它是否是正确的。因此，基于传感器不确定性，存在关于场景的不确定性。而且，通常存在可影响给定传感器中置信度的其它传感器。例如，如先前提及的，如果传感器s1和s2被观察为正确地运转，然而取决于传感器指示为没有功率的给定电路，则暗示是：电流传感器不在正确地运作。尽管如此，有可能s1和s2在某些情况中看似是正确的，甚至在它们没有功率的时候。因而，存在两个可能的场景。在一个实施例中，fsd计算多个故障场景以捕获这两个不同的解释。它还计算与场景相关联的置信度。它然后可以以置信度的次序来呈现对于每个场景的根本原因，或简单地呈现其中它具有最大置信度的那个。至少部分地基于传感器相对于其预测值执行得多好来计算该置信度。它还可以至少部分地基于传感器值多好地对应于由其他传感器值或所述其他传感器值的导出值所暗示的那个，或者多好地与之一致。作为示例，良好表现的传感器s1和s2与在为它们供电的电路上没有功率不一致，这降低电流传感器中的置信度。在该结构的情况下，fsd具有与所谓的“最大-和-积”网络的某种类似性，因为最大值是挑选具有最高置信度的场景的特殊情况。然而，fsd与例如emcsmarts软件形成对比，因为部分地它们使用汉明距离并且挑选最小距离，其意味着至多有一个根本原因。这进而暗示了签名必须包括多个故障情况，否则它们可能不被恰当地识别。相比之下，fsd使用跨整个表的三元匹配，并且可以容易地在多个根本原因行上匹配。图7是一框图，其图示了用于通过使用三元故障场景表示来进行自动根本原因分析的过程的实施例。在一个实施例中，图7的过程主要通过图5a中的匹配引擎（504）来实施。在步骤702中，多个潜在故障场景（202）被访问，其中所述多个潜在故障场景的给定潜在故障场景具有对应的根本原因，并且所述给定的潜在故障场景的表示包括“不用在意”值。在一个实施例中，给定的潜在故障场景的表示包括三元值。在一个实施例中，实际故障场景的表示包括三元值。在一个实施例中，给定的潜在故障场景由配置系统自动生成，如上所述。在一个实施例中，所述多个潜在故障场景被布置在包括三元值的表（302）中。三元值在本文中被称为包括真、假、未知，并且同样地四元值通过使用[a,b]的上述四元命名法而包括[0,0]、[0,1]、[1,1]和[1,1]。在一个实施例中，分层次的表结构包括较低级别rct，所述较低级别rct具有每网络节点的减少数目的征兆。在一个实施例中，分层次的表结构包括具有粗粒度根本原因的较高级别rct。在一个实施例中，分层次的表结构包括用于其中装备在正确执行的常见情况的较高级别rct。在一个实施例中，分层次的表结构包括用于其中装备没有在完全正确地执行的详细情况的较低级别rct。在步骤704中，根据从所监控的系统（602）所接收的遥测（604、606）而生成实际故障场景（502）。在一个实施例中，实际故障场景的表示包括未知值。在一个实施例中，所监控的系统包括以下中的至少一个：网络系统、制冷系统、成像系统和侵入检测系统。在步骤706中，对照所述多个潜在故障场景（302）来匹配（504）实际故障场景（502）。在一个实施例中，匹配包括精确的三元匹配。如本文中所提及的，“精确的三元匹配”包括：将真匹配到被标明为{真，真}的真；将假映射到被标明为{假，假}的假；并且将未知和/或不用在意映射到被标明为{未知，未知}和/或{x，x}的未知和/或不用在意。通过使用[a,b]的上述四元命名法，精确的三元匹配还包括使用[0,1]组合来意指“不知道为真”。这将匹配扩展到允许在潜在根本原因中以及在实际故障场景中的[0,1]组合，因此该征兆条目匹配输入征兆值，只要它不是真的。例如，如果征兆实际为真与相关联于该表的根本原因矛盾，则它不应匹配，但是如果征兆是未知或假的，那么它是匹配。使用精确的三元匹配不排除诸如上述的四元匹配。在一个实施例中，执行实际故障场景的匹配，而无需对实际故障场景的同时发生的更新。在一个实施例中，并行地在多个处理器上执行匹配。在步骤708中，一个或多个匹配的原因被输出为所监控的系统（602）的一个或多个可能的根本原因故障（506）。在一个实施例中，另外的步骤（图7中未示出）是将潜在故障场景存储在t-cam中。在一个实施例中，另外的步骤（图7中未示出）是将所述多个潜在故障场景中的每个潜在故障场景存储到相同的t-cam中。如上所述，三元cam也可以做四元匹配；三元cam包括第一三元cam和第二三元cam二者，所述第一三元cam具有相同的“已知”和“值”位，并且通常与[0,0]相同地对待[0,1]，所述第二三元cam可与[0,0]不同地对待[0,1]，这通过使用上述的四元命名法/四元匹配。图8是一框图，其图示了用于置信度和多个实际故障场景的过程的实施例。在一个实施例中，图8的过程是图7的步骤706的部分。在步骤802中，为图7的步骤704中生成的实际故障场景计算第一置信度。在步骤804中，根据从所监控的系统（602）所接收的遥测来生成第二实际故障场景，并且为所述第二实际故障场景计算第二置信度。如上所述，实际的故障场景和第二实际故障场景可以不同，对应于传感器输入的不同解释。例如，基于传感器不确定性，或可影响给定传感器中置信度的其它传感器，可存在关于场景的不确定性。在步骤806中，在实际故障场景和第二实际故障场景之间进行选择是至少部分地基于在第一置信度和第二置信度之间的比较。在一个实施例中，它可以以置信度的次序呈现这两个场景。尽管已经相当详细地描述了前述实施例以用于清楚理解的目的，但是本发明不限于所提供的细节。存在实现本发明的许多可替换方式。所公开的实施例是说明性的并且不是限制性的。当前第1页12当前第1页12