CN1145708A

CN1145708A - 分布式硬件监控的方法和系统

Info

Publication number: CN1145708A
Application number: CN95192496A
Authority: CN
Inventors: I·哈比; A·西蒙斯; S·瓦尔曼; R·吉斯康比; M·伦纳森; P·E·施特罗米
Original assignee: Telefonaktiebolaget LM Ericsson AB
Current assignee: Telefonaktiebolaget LM Ericsson AB
Priority date: 1994-04-08
Filing date: 1995-04-04
Publication date: 1997-03-19
Also published as: FI964016A; SE502852C2; US5655071A; DE69533774D1; AU2270295A; JPH10502222A; SE9401185D0; AU684019B2; EP0754382B1; WO1995028047A1; NO964249L; KR100293796B1; FI964016A0; SE9401185L; BR9507278A; MXPA96004197A; EP0754382A1; NO964249D0; KR970702641A

Abstract

一个电信系统中的故障监控和管理系统包括一个在该电信系统的故障传播方向上彼此相连的诊断与推理对象(IFP)的链式系统。确定这些对象在链式系统中的位置，使之能够在各自的临控域中监控一种可能由该电信系统中的故障所引起的现象，并在故障发生时能够互相通信、彼此影响和相互作用，以便定位电信系统中的故障。每个诊断与推理对象使用一个或多个测量点对象(MEP)，观察诊断与推理对象所监控的现象的出现，并向诊断与推理对象(IFP)报告。更多的测量点对象(MEP)可以组成一个测量合成对象(MEC)，收集并处理来自它所包含的测量点对象的数据。

Description

分布式硬件监控的方法和系统

本发明的技术领域

本发明一般涉及电信系统中复杂硬件和软件的管理，特别涉及这样的硬件和软件的监控。

更特别的是，本发明涉及一个故障监控和故障管理系统，以及一种在电信系统中进行分布式故障管理的方法。

众所周知复杂的硬件和软件系统很难用正确的方式监控。大多数系统的监控使用带集中式分析软件模块的集中式解决方案。这种分析模块会变得很大而且复杂，即使是对中等复杂度的系统来说也是如此。当这样的系统中引入新的硬件和软件以及改变原有东西时，通常很难根据新的硬件和软件更新模型和方法。

本领域相关技术的描述

WO 92/17961涉及一种容错的自适应分布式系统。该系统包括一个至少带有三个节点的网络，每个节点至少与另一个节点进行通信。每个节点用于测试另一个节点是否处于一种期望或不期望的状态。确定N个节点，这里N是大于或等于3的整数，是否具有一种期望或不期望的状态是可能的，如果一个被测试节点具有一种期望的状态，那么它就被激活变为一个测试中节点。如果得到了一个不期望的测试结果，上述过程就在其他节点上重复直到测试到一个处理器带有一种期望的状态。诊断信息沿着网络中的通道转发。

EP 139,069描述了一种故障诊断分布式系统，该系统带有多个在一个共同级别上相互互连的子系统，每个子系统具有诊断其它子系统中的故障的功能并基于其它子系统的故障诊断结果保护它本身的子系统。

US 4,627,055表述了一种带有多个互连的同样类型的子系统的分散式系统。每个子系统具有诊断其它子系统中故障的诊断装置以及响应诊断结果进行测量的功能。

US 4,354,267涉及故障处理，其目的是避免使用扩展的“主传输控制单元”时的缺点。

内容

本发明总的目的是提供一种模型和应用这种模型，在带有复杂硬件和软件的电信系统中设计和实施故障处理的方法。

更特别的是，该模型应该作为电信设备故障行为的软件表示。通过观察监控实体并使用实体行为的知识，该模型应该能够在不同的抽象级别和观点中检测、识别并定位故障，并且能够用于协调来自不同的故障检测实体的警报。希望该模型也能够用于复位(自动或手动)一个出故障的单元。

根据本发明，上述目的已经通过故障监控与故障处理系统得到，根据本发明该系统包括一个在该电信系统的故障传播方向上彼此相连的诊断与推理实体的链式系统，确定所述的数据实体在链式系统中的位置可以使其中的每一个、在各自的监控域中、监控一种可能由该电信系统中的故障所引起的现象，并在故障发生时能够互相通信、彼此影响和相互作用，以便定位电信系统中的故障。

根据优选的实施例，每个诊断与推理数据实体使用一个或多个测量点数据实体，观察诊断与推理数据实体所监控的现象的出现、并向诊断与推理数据实体报告。

根据本发明，在电信系统中分布式故障处理的方法包括这些步骤：

系统中数据和信号的分析流，用于在故障出现时确定系统的行为并因此定位故障所引起的现象。

通过电信系统中故障传播方向上彼此互连的诊断与推理数据实体的一个或多个链式系统表示所述的行为，而在数据实体相应的链式系统中确定它们的位置，使得它们中的每一个都能够在各自的监控域中监控一种可能在这样的链式系统中出现的上述现象，并在故障发生时能够互相通信、彼此影响和相互作用，以便定位电信系统中的故障，

提供关联于每个诊断与推理数据实体的一个或多个测量点数据实体，用于观察所关联的诊断与推理数据实体所监控的现象的出现，并向诊断与推理数据实体报告。

几个测量点数据实体可以方便地组成一个测量合成数据实体，收集并处理来自其中所包括的测量点数据实体的数据。

根据另一个实施例，诊断与推理数据实体在证实它本身的监控域中是否出现了故障之前就已经检测到它所对应的链式系统中故障的出现，它向所述的链式系统中、从故障传播方向上看处于这个故障检测数据实体之前的诊断与推理数据实体发送一个故障定位请求，请求它们返回一个是否已经检测到故障的确认消息。

在其它诊断与推理数据实体中搜索故障最好继续进行直到找到了构成所讨论的链式系统开始的诊断与推理数据实体，或是找到了也检测到故障的诊断与推理数据实体为止。

如果当前的链式系统在该故障检测诊断与推理数据实体之前包括更多的并行分支，那么搜索一次在一个分支中进行。

优选的是故障定位请求包括一个标识它的来源的标识参数。

确认消息可以包含两个标识参数，一个标识故障定位请求的来源，一个标识发送者。

每个诊断与推理数据实体可以有一个与之关联的故障序列号，当有关的诊断与推理数据实体检测到一个故障时该号码步进1，所述的序列号作为故障定位请求中的一个参数引入并与沿着有关的链式系统的有关的故障定位请求诊断与推理数据实体的标识一起存储，存储的信息形成一个指示，表示上行流分支已经被研究且确认能够立即从下行流发送。

如果对于故障检测诊断与推理数据实体来说链式系统包括几个并行的分支，搜索就在上行流分支中并行地执行，而且通过请求传递的关于分支的信息被加到故障定位请求的参数列表中。

参数优选地作为一个栈来实现，发送定位请求的每个诊断与推理数据实体加上其本身的标识。

发送的诊断与推理数据实体可以通过计数器装置和保留请求的标识来跟踪未应答的定位请求。

在确认消息返回之前，最好已经收到每个上行流分支中的确认消息。

标识参数可以通过确认消息返回。

每次发送确认消息时，最好在栈上执行更新操作。

根据另一个优选的实施例，诊断与推理数据实体一旦已经证实所检测的故障处于它的域之中，就向故障传播方向上所有处于下行流的诊断与推理数据实体发送一个协调方法呼叫，所述的方法呼叫一直传递直到找到一个故障结束诊断与推理数据实体。

发送中的诊断与推理数据实体的标识最好跟在协调方法呼叫之后并由呼叫所经过的诊断与推理数据实体储存起来。

当故障被处理之后，故障的消失是由最初检测到故障的诊断与推理数据实体检测的，所述的数据实体向所有下行流的诊断与推理数据实体发送一个与之有关的方法呼叫，所述的方法呼叫一直传递直到找到一个故障结束诊断与推理数据实体。

所讨论的诊断与推理数据实体的标识最好跟在有关故障消失的消息之后。

当一个诊断与推理数据实体接收到有关故障消失的消息时，这个数据实体再次开始监控故障，此后所有曾引起这个诊断与推理数据实体脱离操作的诊断与推理数据实体均已恢复。

用另一种方法来表述，根据本发明建立了一种执行该方法的模型，包括真实硬件和软件实体行为的子模型，以及电信系统中实现的更加抽象的实体的行为的子模型。代表硬和软件中某种实现的逻辑功能值得作为例子一提。该模型也包含将被说明为可替代的实体及与之有关的实体的子模型。更特别的是，这里可替代的实体意味着可以被替换的最小的硬件部分，常常是一块单个板或一条单个电缆。使用模型的这个部分的目的是在故障时进行测量活动—一种下面称为修复处理的活动。

代表不同电信系统的模型之间的通信需要是该模型中所固有的。

包括在根据本发明的方法中的故障监控的部分方法，基于问题的分布式方法。用这种方法，根据本领域的状态的集中分析软件模块将是不必要的。

模型中使用的不同对象具有严格规定和完善说明的任务，如被监控的实体的观察、症状产生—即汇集和处理观察、诊断/分析一个被观察的实体或多个实体，以及不同分析实体之间最后的状态传播。这使得建立被监控系统的结构良好的模型变得很容易。

与故障如何产生的传播性质有关的、代表被监控实体的行为的图形记号包括在本发明中。硬件和软件实现的改变将导致代表硬件和软件的图形的改变。这意味着变化可以用相对简单和结构化的方法处理。

分布式方法以及图形记号可以更容易地理解不同的故障是如何彼此影响的以及特定的故障是如何产生的。

本发明的方法，即概念和图形记号，也可用于硬件和软件的设计。这有助于硬件和软件的设计者对故障的密度和故障在目前硬件和软件设计中的传播、以及可能的故障检测程度得到一个较好的了解，并优化故障可替代单元的表示。此外，从硬件和软件设计文件中产生并实现软件模型是非常容易的。

根据本发明，该模型的观察和症状产生部分可以复用为电信系统中的性能计算功能。

硬件和软件监控模型可以递归地使用，即用于硬件和软件监控的机制类似地被该模型所监控。例如，硬件和软件的监控用于执行硬件和软件监控中的观察。

该模型可以推广为对所有类型的硬件和软件系统均有效。

附图的简要描述

下面将参考附图对本发明做更详细的描述，其中

图1示意性并以框图的形式表示了一个数据处理系统，也图示说明了一个这里包括的本发明的实施例，

图2示意性地图示说明了故障处理的软件模型，

图3表示与一个装置的故障处理和修复处理有关的对象实体关系的模型，

图4是说明故障定位原则的影响图表，

图5示意性地说明了一个带有接收和发送方法呼叫的装置、以及内部和外部接口的诊断与推理点对象的设计，

图6表示了一个状态图，说明根据图5的对象的不同的可能状态和状态传输，

图7表示下列图中所示的影响图中的某些图形符号的意义，

图8是这样一个影响图的例子，

图9表示关于故障定位的一个影响图的例子，

图10表示一个说明根据图9的例子中的确认测量的图，

图11是一个说明有关故障定位的搜索算法的第一改进的图，

图12是一个说明有关故障定位的搜索算法的第二改进的图，

图13和14示意性地说明了在影响图外观上带有两种不同关系类型的模型的影响，

图15表示一个用于描述故障协调的影响图，

图16表示一个说明故障复位的影响图，

图17表示根据图8的影响图的对象关系模型，

图18表示一个概率函数的例子，

图19表示当使用根据图18的概率函数时，故障可替换单元故障处理的两种情况，

图20表示用于功能的故障处理分析的一个模型的功能分析部分，

图21说明功能对象之间的状态传播，

图22说明修复处理模型的设计，

图23表示可能与修复处理有关而出现的一个影响图的例子，

图24说明了一个可替换单元的结束的例子，

图25-27是表示图5中包括的每个接口的状态变换表。

实施例的详细描述

将在下面描述的本发明的实施例，为了简单起见，基于这样的假设：存在一个面向对象的分布式数据系统的问题。但是，并且更普遍地说，本发明不仅限于这种类型的系统，也可用于其它类型的为使用另一种特性的数据实体而不是对象而设计的系统。

对于下面以及附图上出现的与包括消息和方法呼叫在内的信号、以及参与者的描述有关的表示，使用了结构化编程的常规命名规则，例如Stanley B.Lippman的书“C++入门”，Addison-Wesley出版公司，第二版中描述的那类。所讨论的表示的较详细描述和它们的含义将参考图5在下面给出。

为了简单起见，下面描述的本发明的实施例主要是针对硬件监控。但是，本发明也可用于软件监控，这将在下面的一些情况中描述。

图1示意性地表示、同时也作为一个例子、一个数据处理系统的一部分，包括一个标为2的中央处理器CP，以及与之相连分别标为4和6的本地处理器DP。故障处理模型在这样一个系统上的应用将在下面做更详细的描述。

根据本发明的故障处理模型一般包括三个相当独立的子模型。模型的这种划分反映了故障处理要进行的主要任务，即：

—硬件监控，如在处理器2、4和6中。这部分用于检测故障，识别故障类型并在硬件中定位故障的起源，在这里一个或多个故障单元，可替换单元及/或功能单元都可能表示为故障。模型的这个部分在下面也标为“硬件监控模型”。可替换单元—图1中的8和10分别表示两个，并假设它们分别包括在处理器4和6中—在本连接中可能是最小的可替换的硬件部分，一般是一块单个板或一根单个电缆。

—功能的故障协调或关于故障行为的功能分析。这种操作在检测到故障而且一个或多个功能指示为故障时启动。在功能上故障影响的分析由功能本身并在功能之间进行。模型的这部分在下面也称为“功能级上的故障处理模型”。

—修复处理。这种操作在一个可替换单元被硬件监控指示为故障时开始。模型的这部分在下面也称为“修复处理模型”。

模型的这种划分也可根据图2映射在不同的抽象级上，这里硬件监控部分标为12，在一个功能级上的故障处理部分FH标为14，而修复处理部分RH标为16。后者示为包括一个硬件单元的子模型17。所讨论的级在图中表示，例如包括一个依赖硬件的功能的“低”级别18，和一个抽象逻辑功能的“高”级别22。

更进一步，硬件的监控，用箭头24、26、28表示，当然依赖于硬件的实现。模型的这部分

可以在级别18上找到并且部分在本地处理器4和6中实现。负责通过功能进行故障影响分析的部分可在抽象级别18和22上找到。每个系统，或子系统，必须通过模型的两个部分12和14建立自己的模型。

最后部分16，修复处理模型，由下面更详细讨论并代表着可替换单元的对象建立，如8和10。修复处理部分16也影响模型其它两部分中的实体。当系统可以在一个且同一个可替换单元上实现时，修复处理模型对几个系统或子系统可以是公共的。

在图2中，还在30标出了一个硬件接口和带虚线框32的硬件模型17的物理对应物。34和28处的功能模型进一步表示。

如果作为一种替换，被观察的测量点处于软件中，例如，软件中的一个故障计数器，图2中的部分16和17就消失了，部分12被软件监控部分取代，硬件接口30被软件接口取代。

同样下面将会出现，代表不同系统或子系统的模型可以通过不同模型中的对象之间传播状态而彼此通信。不同模型之间的通信和一个模型内的通信没有任何不同。

图3表示一个设备故障处理及修复处理的对象关系模型。该模型包括多个诊断与推理点对象。其中一个以图3中的40表示。为了简便，这些对象下面将以推理点、或IFP来标识。这样的一个推理点IFP负责数据或信号流的特定部分的监控。

图3中以箭头表示的推理点IFP 40监控一个可替换单元对象44，此后也称为RUO，代表一个可替换单元46，此后也称为ru，用虚线表示。以箭头48表示，推理点IFP 40还监控一个功能对象50，此后也称为FO。这里，功能对象FO的意思是由一个或多个系统执行的一个功能的软件表示。

以箭头51表示，推理点IFP 40为了它的功能使用了多个测量点对象，此后也称为MEP(测量点)，图3中的52表示其中的一个，在图1中的本地处理器4和6中的52.1、52.2和52.3处用虚线分别表示了三个。每个这样的对象MEP对应于一个物理实体54，此后也称为mep，图1中RU 8和RU 10中的54.1、54.2和54.3处分别表示了其中的三个。此后，测量点对象MEP也简称为测量点MEP。在本连接中，一个测量点用于表示一个被观察实体被观察处的假想点的代表。这种测量点MEP也包括用于观察的方法。

MEP与硬件相互作用，用于观察可能的状态转移。检测硬件故障的方法在某些情况下非常依赖于硬件的实现。由于与硬件有着紧密关系，MEP时常、但并不必须总是，分布到一个当前的本地处理器中，正如曾参考图1描述的那样。

在公布一个观察之前，已做了大量被观察实体mep的数据处理。在测量点MEP中公布的测量结果可能是一个计数值、一个数据处理过的计数值、或任何其它的硬件或软件信号。但是，测量点MEP既不分析也不做出任何关于被观察实体mep的结论。

如果必要，测量点MEP也可通过软件调整。一个例子是给使用的方法置一个门限值。

如果合适，来自不同测量点MEP的观察可以合成一个测量合成对象55，此后也称为MEC(测量合成对象)，它同样可以被推理点IFP 40使用。在图1中，本地处理器6中55.1处表示了一个MEC。来自测量合成对象MEC的输出可以看作硬件中被观察实体的一个症状。与测量点一样，测量合成对象MEC从不分析任何数据。但是测量合成对象MEC可以收集并处理来自它所包括的测量点MEP的数据。这种处理经常在软件中进行。“细化的观察”一症状留待进一步分析。

假设使用的观察在适当的处理器中是有效的，即使用的测量点MEP必须位于与测量合成对象MEC相同的处理器中，那么测量合成对象MEC可以整个或部分地在本地处理器的软件中实现，如图1中的4和6。

基于来自MEP和/或MEC的观察，一个IFP通过分析观察并确定是否已检测到故障对特定的硬件进行诊断。

除了分析故障症状，IFP也负责故障定位。能够定位引起故障的真实原因是很重要的，这样就能够指向正确的可替换单元。由于硬件故障可以通过几个IFP检测，就必须有一种方法确定哪个IFP检测到了故障的根源。

大的硬件故障影响多个不同的IFP。故障系统时钟可以，例如，暗示一个单元中监控一串单元的IFP交替检测故障。为了能够定位故障的根源，IFP必须能够彼此觉察。它们必须按照能被另一个IFP影响的IPF将出现的方式以确定的顺序相互排列。

故障定位可以通过将所有能够彼此影响的IFP置入一个影响链来执行。能够影响所有其它IFP的IFP应该放在上行流的最上端，然后其它IFP按照影响的顺序放置。不能影响任何其它IFP的IFP放在下行流的最下端。

故障定位的原则通过图4中所示的影响图说明。根据上面的描述，在图中IFP₁和IFP₅分别是处于上行流最上端和下行流最下端的IFP，而IFP₂和IFP₄则处于影响顺序的中间。在图4中，故障定位的相应步骤编号为1-7。

基于步骤1中来自MEP52的观察，IFP₄通过分析该观察作出关于某个硬件54的诊断并且确定已经检测到一个故障。IFP₄因此在步骤2中向上行流处于最近的IFP，即IFP₂发出一个故障定位的请求，“定位故障”。步骤3中，故障定位请求被转发到上行流最上端的IFP，即IFP₁。IFP₁和IFP₂在步骤4和5中响应定位请求，在这种情况下应答为“无故障”。当IFP₄从上行流的IFP接收到这个响应时，定位过程结束并且找到了故障的根源，即，IFP₄本身监控的硬件。

当找到故障根源时为了避免不必要的故障传播，检测到故障属于自身监控域的IPF，即IFP₄，在步骤6中用“协调”向处于下行流的IFP，此时为IFP5，发送一个指令，使之进入休息状态。

应该补充的是上面描述的故障定位过程是非常简单的。影响链可能很复杂并形成相当复杂的网络，正如下面接着会出现的那样。

从故障传播的观点来说，故障定位和故障协调密切依赖于硬件的行为。这在下面将做更详细的描述。

从故障传播的观点来看，在建立硬件行为的软件模型之前，必须分析并清楚地了解硬件中的数据和信号流。从这些流中，建立子模型而且它们被模型的硬件监控部分所监控。

正如上面参考图4的描述中所体现的，数据或信号流的行为通过一串互连的推理点IFP来体现。参考故障所产生的传播，通过流的行为确定这些连接，并且这些连接用于故障检测推理点IFP的定位上。在同一链中的推理点IFP必须彼此之间存在故障影响。将一个推理点IFP放在某个影响链中的原因是，如果这个引入的推理点检测到一个故障，在链中位置较前的一些推理点可能也检测到了同样的故障。尽管如此，一个链中的推理点IFP并不测量同一个事物，但它们可能检测到同样的真实硬件故障。如果硬件中出现一个故障，可能被几个推理点IFP检测到，而且这些推理点必须包括在同一个影响链中。

即使链中的推理点IFP能够检测到同样的硬件故障，事实上，所有的推理点也不一定都检测到该故障，因为推理点是从不同的角度来搜索故障的，已经提到过，它们不是测量同一个事物的。

故障产生结束的一个推理点IFP，例如图4中的IFP₄，称为故障结束推理点。故障产生的传播不能超过这个点，而且影响链也因此结束。

为了对下面参考图7及以下的图所描述的影响链和它们的功能有更好的理解，将参考图5和6对影响点IFP的设计、它的不同状态、以及它所发送和接收的方法呼叫做更详细的描述。

一个推理点IFP包括一个诊断部分60，“IFPdiagnoser”，在下面和附图中也缩写为“IFPdiag”，用于分析和诊断与被观察实体有关的观察及症状。在故障处理情况下，分析和诊断是围绕故障而执行的，即，推理点IFP负责检测和识别硬件中的故障。推理点IFP负责确定它是否检测到了一个故障。推理点IFP具有检测和识别单一类型故障的任务。当一个推理点IFP检测并识别出一个故障时，对于一个正确的推理点来说还有定位故障根源的任务。不能非常确定故障起源于检测到故障的推理点IFP。故障的产生可能由任一别的地方的一些其它故障所引起。当一个可替换单元RU和功能出了问题、应该被识别出故障时，对故障进行正确定位十分重要。

当故障的根源已经定位到了某个推理点IFP时，必须与其它故障检测推理点IFP协调该故障，以避免推理点之间不必要的状态传播。

推理点IFP有一个相互作用和状态传播部分62，“IFPpropHandler”，在下面和附图中也缩写为“IFPprop”，假如推理点所识别的故障彼此依赖，它允许推理点彼此相互作用。当负责产生故障域的故障检测推理点应该被定位时，这就很必要，即，必须能够指出正确的可替换单元。

参见图2，根据箭头64，相互作用和状态传播部分62分别通过指令“openIFP”和“closeIFP”，从修复处理模型部分RH，经由下面更详细描述的接口IFPcontrolI进入或退出操作。

假如所使用的观察和症状在正确的处理器中生效，推理点的分析和诊断部分60可以完全或部分地由本地处理器中的软件来实现，如图1中的处理器4和6。但是，对象的相互作用状态传播部分62总是在高级计算机系统中实现的，如图1中的中央处理器2。图1中也说明了每个推理点的分析和诊断部分IFPdiag 60.1和60.2分别处于本地处理器4和6中，而且各自对应的状态传播部分IFPprop 62.1和62.2也处于中央处理器2中。显然，IFPdiag60.1使用MEP52.1，IFPdiag60.2使用MEC55.1，后者使用两个MEP，52.2和52.3。

根据箭头66，从相互作用状态传播部分62到诊断部分，分别通过方法呼叫doDiagnose、startDiagnose和stopDiagnose给出进行诊断、开始继续诊断、和停止一个进行中的诊断的指令。在相反方向上，根据箭头68，分别通过errorDetected和noErrorDetected给出关于故障是否检测到的信息消息。IFPpropHandler 62和IFPdiagnoser60之间的通信通过下面详细描述的接口DII执行。在图5中也表示了接口IFPtoIFP，通过这个接口产生与其它IFP的通信，以及在一侧的IFPdiagnoser 60与在另一侧的MEP和MEC之间、MEC和MEP之间的接口MEI。图5中包括的接口现在将在下面详细描述。

接口IFPcontrolI包括方法

openIFP(ruID)，启动IFP，

openIFP(ruID)，结束IFP，

以及方法

verifyIFP()，通过初始化一个doDiagnose序列校验IFP，可能的返回值是verifyOK、verifyNotOK、verifyRejected。

接口IFPtoIFP在IFP之间提供处理故障定位、故障协调和故障恢复的方法，是客户机/服务器、方法/方法类型的接口。

因此该接口由故障定位和故障协调的方法、以及故障恢复的方法组成。

故障定位和故障协调的方法是

localizeIFP(IFPid)，

coordinateIFP(faultID)，

noFaultyIFP(reqIFPid，sending IFPid)。

故障恢复的方法是

clearFaultIFP(faultID)。

客户机IFP向服务器IFP发送定位方法呼叫，该服务器与客户机IFP具有connectedByInfluence关系。接收方法呼叫的服务器IFP进入“定位”动作。当处于上行流的一个分支中的定位循环结束时，这个IFP将向客户机IFP发送这个“定位”的确认。如果没有IFP指示找到了故障，就向客户机IFP发送notFaultyIFP，否则发送协调方法呼叫。

方法呼叫的交换可以由服务器IFP通过发送协调方法呼叫来启动。这个方法呼叫告知已经找到了一个指示故障的IFP并且应该与其它受影响的IFP协调。通过在该方法呼叫中标识指示故障的IFP的IFPid参数使这种协调成为可能。

故障恢复基于clearFault方法呼叫的交换。

当服务器IFP在受到故障影响之后处于满操作中时，这个IFP通过发送clearFault呼叫可以启动方法呼叫的交换(自动恢复)。

接口没有状态，只有先决条件P。入方法呼叫将根据特定的先决条件P产生一个出方法呼叫：

P1：服务器IFP已从它所有的上行流相邻IFP收到notFaultyIFP方法呼叫。

P2：服务器IFP在一个doIFPdiagnose请求之后已收到一个noErrorDetected方法呼叫。

P3：服务器IFP从它上行流相邻的一个IFP中收到“协调”方法呼叫。

P4：服务器IFP从IFPdiagnoser收到errorDetected方法呼叫。

P5：服务器IFP收到noErrorDetected方法呼叫，它不是通过doIFPdiagnose作为确认而接收的，而是故障状态结束退出的状态。

图25表示了一个接口IFPtoIFP处的状态变换表，其中包括了上面的先决条件。

IFPpropHandler和IFPdiagnoser之间的接口DII的目的是指示开始和结束关于到IFPdiagnoser的诊断请求的方法。这是一个客户机/服务器类型的方法/方法接口并且由激活和关闭诊断操作以及请求诊断循环的请求方法组成。

请求诊断操作的方法处于IFPdiagnoser中，它们是：

-startIFPdiagnose(IFPid，diagnoseType)

startIFPdiagnose方法请求IFPdiagnoser开始诊断被监控的硬件和软件。“diagnoseType”可以是“lookingForError”或“lookingForRecovery”。

-stopIFPdiagnose(IFPid)

stopIFPdiagnose方法指示IFPdiagnoser停止它的诊断动作。

-doIFPdiagnose(IFPid)

doIFPdiagnose方法指示IFPdiagnoser执行一次诊断。IFPdiagnoser总会响应，即使没有找到故障。

在上面提到的方法呼叫中，“IFPid”是发送呼叫的IFPpropagationHandler的标识。

响应诊断操作的方法处于IFPpropHandler中，如下：

-errorDetected

errorDetected方法通知IFPpropHandler已经找到一个故障。

-NoerrorDetected

通知IFPpropHandler没有找到故障。

此外下面的其它方法也处于IFPpropHandler中

-DiagnoserOK

通知IFPpropHandler到本地处理器的链路处于操作中。

-DiagnoserNotOK

通知IFPpropHandler到本地处理器的链路脱离操作。

关于动态行为，使用下面：

请求诊断执行的方法呼叫接口基于方法呼叫互换startIFPdiagnose(IFPid，diagnoseType)，stopIFPdiagnose(IFPid)，doIFPdiagnose(IFPid)。在方法呼叫startIFPdiagnose(IFPid，diagnoseType)中，参数diagnoseType指示服务器应该检查故障还是故障恢复。如果服务器收到一个startIFPdiagnose，如果故障出现的话用errorDetected来响应。如果方法呼叫startIFPdiagnose指示检查恢复，当故障已经恢复时诊断单元用noErrorDetected来响应。

方法呼叫stopIFPdiagnose不从服务器接收任何响应。

方法呼叫doIFPdiagnose指示服务器执行一个诊断测试周期，其中来自服务器的应答是errorDetected或noErrorDetected。

例如，为了通知客户机到本地处理器的链路脱离操作，服务器可以使用方法呼叫diagnoseNotOK。当链路再次处于操作中时，服务器发送diagnoserOK。

在图26中表示了DII接口所有可能的状态变换，先决条件是已经检测到一个故障情况。这些状态转移也在图6中的状态图和下面所附的描述中出现。

IFPdiagnoser和MEP之间、IFPdiagnoser和MEC/MEP之间的接口MEI提供从MEP或MEC对象得到测量样本的方法。这些样本可以用于操作处理或故障处理。

该接口由获得执行诊断的测量样本的方法组成。客户机使用下列方法：

-startMeasurement(receiverID，measurementSpecificaiton，-IDofCallingObject)，

-stopMeasurement(IDofCallingObject)。

服务器中的方法startMeasurement用于向请求的对象提供多个报告，每个报告包括一个样本清单。不同对象(IFP)使用方法startMeasurement，得到关于被测量实体的样本。当服务器收到方法呼叫startMeasurement时，它开始从被监控的对象收集样本。这些样本用方法呼叫retrieveSamples送到服务器。

可以并行处理一个以上的请求。

下列参数由方法startMeasurement使用：

-MEPid：MEP的标识。这个标识必须是唯一的。

-measurementSpecificaiton：给出每个MEP类型的信息。例如，它可以是事件的问题或时间激励的MEP。

-IDofCallingObject：这个参数是开始一次测量的对象的标识。

在服务器对象中的方法stopMeasurement将用于停止一个对象对服务器的所有测量请求。该呼叫对象的所有激活的测量将不需要任何报告就立即停止。这个方法接受下列参数：

-IDofCallingObject：见上面

下列方法由服务器使用：

-retrievedSamples(listOfSamples，IDofCallingObject)

-DP_linkError()

-DP_linkErrorCeased()

方法retrievedSamples由客户机提供并用于允许将请求的样本返回到客户机。这个方法接受下列参数：

-listOfSamples：一个带有请求服务器发送的样本的链接的列表。

-IDofCallingObject：见上面

用方法呼叫DP_linkError和DP_linkErrorCeased，服务器可以通知客户机本地处理器链路的状态。

当发送方法呼叫DP_linkError时，表示MEI接口不再存在。当发送方法呼叫DP_linkErrorCeased时，表示接口已经重新建立。

在图27的表中，指明了MEI接口所有可能的状态转移。

IFP的相互作用和状态传播部分62可以取图5中70处所示的多个状态，由下面将详细描述的IFP链中发生的情况来确定。所讨论的状态，以及它们之间的转移，将在下面参考图6中所示的状态图、并继续参考图5及其接口的描述做更详细的描述。在图6中使用了下列缩写：

ed errorDetected(检测到错误)

ned noErrorDetected(未检测到错误)

loc localizeIFP(定位IFP)

notf notFaultyIFP(无故障IFP)

coord coordinateIFP(协调IFP)

clrf clearFault(清除故障)

参考图6中的图，上述的状态为CLOSED、ACTIVE、SLEEPING、FAULTY和SLEEPING/FAULTY。通过出现的箭头说明这些状态之间的转移。下面将详细描述导致不同转移的方法呼叫，通过使用所讨论的缩写来表示，即

输入信号到本身IFP/输出信道到下一个IFP

在CLOSED或“透明”状态，IFP在IFP链中是透明的。该透明状态通过上面提到的方法呼叫closeIFP，或通过观察机制中的故障状态来激励，例如，由于图1中的处理器2和4之间的链路中断，它将会导致IFP 62.1的一个透明状态。

透明状态意味着，根据箭头72方法呼叫localizeIFP以及根据箭头74方法呼叫coordinateIFP、notFaultyIFP和ClearFaultIFP只能进一步传递到链中的下一个IFP。诊断部分60也脱离操作。这些方法呼叫的意义将进一步更详细地体现出来。CLOSED状态是系统启动之前、以及当启动了一个修复活动时IFP进入的最初状态。CLOSED状态也存储了可替换单元标识的列表，因为一个IFP的操作状态可能依赖于更多的可替换单元。

-转移1，箭头80：

closeIFP(ruID)/closeIFP(ruID)

旧状态：CLOSED，ACTIVE，SLEEPING，FAULTY以及SLEEPING/FAULTY。

新状态：CLOSED

启动了一个修复活动并且IFP设置为透明状态。通过输出信号closeIFP(ruID)通知下行流IFP，这里ruID代表可替换单元的标识并用于使同时管理多个可替换单元的替换成为可能。

在ACTIVE状态中，这对于IFP这是一个“正常”状态，诊断部分60操作并搜索故障。诊断部分被上面提到的指令或方法startDiagnose启动。

-转移2，箭头82：

openIFP(ruID)/openIFP(ruID)

旧状态：CLOSED

新状态：ACTIVE

IFP被激活，例如，在一次修复或系统启动之后。通过输出信号openIFP(ruID)通知下行流IFP。观察到该状态转移需要该IFP所依赖的所有可替换单元脱离操作，即，openIFP已经从列表中的所有可替换单元收到。

-转移3，箭头84：

noErrorDetected/-

旧状态：ACTIVE

新状态：ACTIVE

IFP的诊断部分60已经报告没有检测到错误。

-转移4，箭头84：

localizeIFP(reqId)/localizeIFP(reqId)

旧状态：ACTIVE

新状态：ACTIVE

已经从下行流IFP收到输入信号localizeIFP，该方法呼叫传递到上行流IFP。呼叫IFP的标识-reqID，与方法呼叫localize(定位)所传递到的上行流分支的标识一起存储起来。

-转移5，箭头84：

notFaultyIFP(reqId，sendingId)/notFaultyIFP(reqId，sendingId)

旧状态：ACTIVE

新状态：ACTIVE

在上行流分支中没有找到检测到故障的IFP。输入信号notFaulty被传递到下行流IFP。

应该注意的是，在方法呼叫notFaultyIFP可以被传递之前，必须指示诊断，即doDiagnose。为了处理它，必须引入一个子状态。但是，在所假设的状态图中所示的简化表示中，IFP已经知道了这样一个诊断操作的结果，即没有检测到故障。

-转移6，箭头86：

clearFaultyIFP(recoveredId)/clearFaultyIFP(recoveredId)

旧状态：SLEEPING

新状态：ACTIVE

较早检测到故障的IFP，即不是这个IFP，已经检测到因为某种原因故障消失了，并在输入信号中做了指示。在这种情况下，可以假设被恢复的故障正是在影响链的上行流部分中检测到的一个，即这是休眠请求IFP的列表中最后的IfpId。休眠请求IFP的列表在下面对状态SLEEPING的描述中做更详细的声明。

方法呼叫通过到下一个下行流IFP的输出信号来传递。

-转移7，箭头88：

noErrorDetected/clearFaultIFP(recoveredId＝thisId)

旧状态：FAULTY

新状态：ACTIVE

这个IFP检测到以前由这个IFP检测到的故障已经消失。方法呼叫clearFaultIFP在下行流上传递到下一个IFP。

在状态SLEEPING中IFP的诊断部分60被解除激活。这个状态用两个步骤进入：

-诊断部分检测到一个故障，启动了一个定位机制，引起方法呼叫localizeIFP被送往IFP链的下行流，

-已经接收到方法呼叫coordinateIFP，意味着IFP链中上行流存在一个故障，并在所讨论的IFP中导致进入SLEEPING状态。

在SLEEPING状态中存储了一个已经进入FAULTY状态的上行流IFP的标识的列表。所有引入该列表的IFP指示这个IFP进入状态SLEEPING。

-转移8，箭头90：

errorDetected/localizeIFP(reqId＝thisId)

旧状态：ACTIVE

新状态：SLEEPING

诊断部分检测到一个故障，启动了一个定位机制，方法呼叫localizeIFP被送往上行流。

-转移9，箭头90：

coordinateIFP(faultyId)/coordinateIFP(faultyId)

旧状态：ACTIVE

新状态：SLEEPING

接收到输入信号coordinateIFP，即有一个上行流IFP检测到一个故障。

-转移10，箭头92：

clearFaultIFP(recoveredId)/clearFaultIFP(recoveredId)

旧状态：SLEEPING

新状态：SLEEPING

以前检测到故障的IFP检测到故障已经恢复并且通过方法呼叫clearFault通知这个情况，该方法呼叫进一步向下行流传递。在这种情况下，假设这个恢复的故障不是影响链上行流部分中检测到的唯一一个，即，这不是休眠请求IFP列表中最后一个Ifpid。

方法呼叫通过到下一个下行流IFP的输出信号传递。

-转移11，箭头92：

localizeIFP(reqId)/-

旧状态：SLEEPING

新状态：SLEEPING

这个IFP已经被协调且因此这个定位呼叫可以被忽略。

-转移12，箭头92：

coordinateIFP(faultyId)/coordinateIFP(faultyId)

旧状态：SLEEPING

新状态：SLEEPING

接收到一个输入信号coordinateIFP，即有一个上行流IFP检测到一个故障。如果检测到这个故障的IFP已经被协调，该协调被忽略，否则该标识被存入休眠请求IFP的列表中。

-转移13，箭头92：

notFaultyIFP(“not expected”)/-

旧状态：SLEEPING

新状态：SLEEPING

不考虑这个输入信号。

-转移14，箭头94：

noErrorDetected/clearFaultIFP(faultyId＝thisId)

旧状态：SLEEPING/FAULTY

新状态：SLEEPING

该IFP的诊断部分报告故障已经恢复。但是，在上行流中至少存在一个检测到且未清除的故障。输出信号ClearFaultIFP被送往下行流。

状态FAULTY意味着该IFP的诊断部分60观察到它所监控的实体是故障的根源。诊断部分进入操作但是现在搜索“noError”，意味着故障恢复正在进行。当IFP从链中所有的上行流链路接收到notFaultyIFP消息时，进入所讨论的状态，它们与所讨论的IFP处于“isConnectedbyInfluence”关系，下面将同样做详细描述。

-转移15，箭头96：

notFaultyIFP(reqId，expAckId)/coordinatIFP(faultyId＝thisId)

旧状态：SLEEPING

新状态：FAULTY

输入信号表明在上行流分支中没有检测到箭头。这肯定是“故障根源”IFP，即最上行流的IFP检测到故障。

下行流IFP被输出信号coordinatIFP协调。

-转移16，箭头98：

clea rFaultyIFP/-

旧状态：FAULTY

新状态：FAULTY

这种情况从不会发生。忽略该输入信号。

-转移17，箭头98：

notFaultyIFP(reqId，expAckId)/-

旧状态：FAULTY

新状态：FAULTY

不考虑该输入信号。

-转移18，箭头98：

localizeIFP(reqId)/coordinatIFP(faultyId＝thisId)

旧状态：FAULTY

新状态：FAULTY

这个IFP已经承担了引起故障的责任。输入信号coordinateIFP应送往下行流。

-转移19，箭头100：

clearFaultyIFP(recoveredId)/clearFaultyIFP(recoveredId)

旧状态：SLEEPING/FAULTY

新状态：FAULTY

一个以前检测到故障的IFP，即非这个IFP，检测到因为某些原因故障已经恢复，并通过输入信号指示了这种情况。在这种情况下，假设被恢复的故障正是在影响链的上行流部分中检测到的一个，即这是休眠请求IFP的列表中最后的Ifpid。

方法呼叫通过到下一个下行流IFP的输出信号传递。

状态SLEEPING/FAULTY意味着该IFP的诊断部分60找到了所监控的一个实体是故障根源，但是该诊断部分由于另一个故障脱离了操作。这种情况在双故障情况下可能出现。在该IFP观察到它监控的实体是故障根源后—第一个故障—收到coordinateIFP方法呼叫，表明一个新的故障—第二个故障—已经在影响链中较早出现。根据首先消失的故障，当另一个故障消失时IFP再一次进入FAULTY状态，或当第一个状态消失时进入进入SLEEPING状态。

-转移20，箭头102：

coordinatIFP(faultyId)/coordinatIFP(faultyId)

旧状态：FAULTY

新状态：SLEEPING/FAULTY

通过输入信号，收到方法呼叫coordinateIFP，即有一个上行流IFP检测到一个故障。

-转移21，箭头104：

clearFaultyIFP(recoveredId)/clearFaultyIFP(recoveredId)

旧状态：SLEEPING/FAULTY

新状态：SLEEPING/FAULTY

以前检测到故障的IFP，即不是这个IFP，检测到因为某些原因故障已经恢复，并且在输入信号中指示了这种情况。在这种情况下，假设这个恢复的故障不是影响链上行流分支中检测到的唯一一个，即，这不是休眠请求IFP列表中最后一个Ifpid。

方法呼叫通过到下一个下行流IFP的输出信号传递。

-转移22，箭头104：

localizeIFP(reqId)/-

旧状态：SLEEPING/FAULTY

新状态：SLEEPING/FAULTY

这个IFP已经被协调，且因此这个定位请求被忽略。

-转移23，箭头104：

coordinateIFP(faltyId)/coordinateIFP(faltyId)

旧状态：SLEEPING/FAULTY

新状态：SLEEPING/FAULTY

接收到方法呼叫coordinateIFP，即有一个上行流IFP检测到一个故障。如果这个检测故障的IFP已经被协调，就不考虑该协调，否则该标识被存入休眠请求IFP的列表中。

-转移24，箭头104：

notFaultyIFP(“未预见(not expected)”)/-

旧状态：SLEEPING/FAULTY

新状态：SLEEPING/FAULTY

忽略该输入信号。

参考图1以及上面参考图5和6所做的描述，现在将描述故障监控的一个简单实用的实施例，例如，指向一个可替换单元。

针对一条ATM链路106上传输的信元的信元头中所出的故障对该链路进行监控。这样的故障可能是由于较差的传输质量、发送机故障、接收机故障或链路故障所引起的。因此可替换单元可能、但不一定形成了该链路的一部分。特别是，这里假设使用了所谓字头错误校验，HEC。这种类型的错误校验在CCITT I.432建议草案“B-ISDN用户网络接口—物理层规定”

中进行了描述。特别是HEC是一种CRC校验(循环冗余校验)，后者在“数据通信，计算机网络和OSI”，Fred Halsall，Addision-Wesly著，第98页中有所描述。在图1中方框108代表HEC校验。

计算ATM信元的“字头”校验和并且将其结果与类似地包括在信元头中的一个称为HEC域的校验和域相比较，在不同的情况下，即出错情况下，故障信元数计数器步进一次。在本例中。这个计数器是mep54.1。

本地处理器4中的Mep52.1记录了计数器54.1的计数值，这个值通过计数器值窗口110在52.1和54.1中表示。本地处理器4中的IFPdiagnoser60.1根据所谓“漏桶(leaky bucket)”算法分析计数器的值，该算法对于类似领域中的人是熟知的工具，目的是为了检测每个时间单位是否丢失了太多的信元。所得的结果就是诊断，即errorDectected/noErrorDectected，参考图5。

当发生了一个故障时，只要IFPpropHandler处于ACTIVE状态，就通知中央处理器2中的IFPpropHandler 62.1(也参考图5)。如果IFPpropHandler处于FAULTY状态就只传递noErrorDectected消息。上述产生了CP2和DP4之间最少的信令，即只有状态变化信号。

在图7a-d中，表示了下列图8-12、15、16和23、24中为了描述推理点链而使用的图形符号。特别是，图7中表示了a)代表推理点IFP的符号，b)代表故障终结推理点的符号，c)代表影响链路的符号，以及d)代表一条影响链开始的符号。在图1中非常示意性的例子中，假设IFP60.1/62.1处于一条影响链的开始，而IFP60.2/62.2是故障终结IFP。

在图9-12、15、16和23、24中，也通过箭头以及附带的消息文字表示了，在相应的链下，下面讨论的信号与确认的方向和名称。

在图8中，表示了包括多个互连的推理点IFP₁-IFP₉的一个影响图的例子。参考图7，可以注意到IFP₁和IFP₈是故障终结推理点，IFP₂、IFP₆和IFP₉处于影响链的开始。从例子中也可以看到一个推理点可能连接几个推理点，下行流和上行流均有。这里下行流意思是根据箭头111的故障传播流的方向。也可看到故障传播流的方向与根据箭头112的影响关系的方向相反。

故障定位基于一个故障是由检测到故障的最上行流推理点所监控的域中所引起的这个假设。下列策略用于定位这个第一上行流推理点。

假设一个推理点检测到一个故障。在推理点能确定该故障是否确实处于所讨论的推理点上之前，它必须相对故障可能从此传播的流的方向，出去询问它的邻居。对故障根源的搜索一直继续到到达满足下列条件之一的一个推理点：

-所到达的推理点不被任何其它的影响点所影响，即故障不会传播到这个推理点。推理点IFP₂、IFP₆和IFP₉是这样的，它们没有在上行流连接到任何其它推理点。

-所到达的推理点同样检测到了一个故障。

在这种连接中，应该进一步强调的是一个流可能退化为一个单个的点，即开始和结束点是一个。只对一种现象或故障进行监控。

参考图9，以及上面就参考图4所做的描述，推理点IFP₈检测到了一个故障。只要发生这种情况，它就向上行流推理点IFP₇发送一个定位请求。这个请求具有方法呼叫localizeIFP的形式。这个方法呼叫具有标识定位请求的来源的标识参数。在所讨论的情况下，该请求具有localizeIFP(8)的形式，参见图中用同样方法标识的箭头，这里(8)表示作为请求起源的IFP₈。请求的推理点IFP₈进入休眠状态，即它的诊断与推理部分脱离操作。

一个推理点只能有一个未应答的带同样标识的定位请求，即IFP₇必须等到来自IFP₄的确认之后才能继续到下一分支，即IFP₅的调查。发送的推理点IFP必须跟踪未应答的方法呼叫localizeIFP。这通过储存定位请求的标识和希望从中得到确认的上行流推理点的标识来执行。

当定位请求已经到达一个连接到影响链开始点的推理点IFP而这个推理点未检测到任何故障时，就向下行流所有分支发送一个该请求的确认，图10中做了图示，其中当前推理点是IFP₂。定位请求的确认具有方法呼叫notFaultyIFP的形式。

这个方法呼叫具有两个参数，一个标识定位请求的来源，一个标识正发送的推理点。来自IFP₂的确认具有notFaultyIFP(8，2)的形式，如图10的图中所示，分别标识推理点IFP₈和推理点IFP₂。其它确认，与定位请求一样在图10中的图中出现。只有当方法呼叫notFaultyIFP是一个未应答的请求的确认时，推理点才接受它，即正发送的推理点的标识等于所期待的确认。

在一个推理点，例如图10中的IFP₇，被允许沿着影响图传递方法呼叫notFaultyIFP之前，它必须满足所有上行流分支的定位请求，在图10中是两个。一个推理点IFP直到观察到所监控的机制已经找到或没找到故障之后才可以发送任何方法呼叫notFaultyIFP。有这个限制，在一个影响图的推理点之间就不必有时间的相关性，即一个故障下行流是否在该故障上行流被检测到之前被发现是无关紧要的。

当到达了负责未应答定位请求的推理点IFP₈时，确认的传递就终止。

如果接收到方法呼叫localizeIFP的推理点IFP也检测到一个故障时，只存储请求推理点IFP的标识，即方法呼叫localizeIFP不向上行流传递。这种情况将通过后面更详细描述的故障协调机制来处理。

当故障检测推理点接收到每个未应答的方法呼叫localizeIFP上的方法呼叫notFaultyIFP时，该故障被认为是处于该推理点所分析的被观察实体内。这样的一个推理点现在改变了故障检测机制的模式，特别是，现在检测到故障的消失，如上面参考图5和6所做的描述。在故障的两级检测和同样故障消失的检测之间一定会出现滞后现象。

当使用上面描述的故障策略时，搜索的次数随着影响图中分支数的增加快速地增长。如果经常有这样大的影响图就会出现问题。

为了改进搜索算法以便找到最上行流故障检测IFP而不必搜索得太多，根据第一修改并且参考图11，引入了每个推理点本地的故障序列号。当通过推理点IFP₄检测到一个故障时，这个推理点通过故障序列号123继续转发，该序列号作为方法呼叫localizeIFP(4，123)中的一个参数，通过推理点IFP₄发送。序列号123和请求推理点的标识4一起被沿着图中的定位分支的IFP存储。存储的信息表示上行流分支已经被调查并且确认可以立即发送到下行流。因此当第二localizeIFP请求经由IFP₂、IFP₁被IFP₁接收到时，可以理解这个故障已经在上行流分支中定位，因为localizeIFP请求的标识等于变量lastFault的值。因此notFaultIFP可以立即发往下行流。

在改进搜索算法的另一个修改中，参考图12，上行流分支的调查可以并行执行而不是一次只调查一个。为了这个目的，通过请求传递的分支信息必须加入方法呼叫localizeIFP的参数列表中。这个参数可以作为一个“栈”来实现，每个向其发送方法呼叫localizeIFP的推理点加入自己的标识。在图12中，IFP₆观察到一个故障并向上行流发送了定位请求之后，在三个分支IFP₆-IFP₄-IFP₂，IFP₆-IFP₅-IFP₃和IFP₆-IFP₄-IFP₃中顺序加入相应的IFP标识，以便IFP₁最终分别收到方法呼叫localizeIFP(2，4，6)、localizeIFP(3，5，6)和localizeIFP(3，4，6)。为了清楚起见，这些方法呼叫在图12中缩写为“loc”。发送推理点IFP₆必须跟踪这些未应答的方法呼叫。这通过使用一个计数器并存储该方法呼叫的标识来实现。在图12中缩写为“notF”的方法呼叫notFaultyIFP返回之前，确认“expAckID”必须在每个上行流分支上收到。标识参数，即栈，被方法呼叫notFaultyIFP返回。每次发送方法呼叫notFaultyIFP时，执行一次栈的更新操作。通过在每个连续更新的栈中的第一个标识是返回的IFP的标识来实现的这种操作示于图12，返回的IFP的标识通过去掉最新的前面返回的IFP的标识来得到。因此IFP₆最后收到消息notFaultyIFP(5，6)和notFaultyIFP(4，6)。结果发现IFP₆是负责这个故障域的IFP。

在搜索算法的第三个修改中，在推理点之间的故障影响关系可以模型化为用户/提供者关系，也称做“isDependentUpon(相互依赖)”，而不是“isConnectedByInfluence(通过影响而连接)”关系。这种关系意味着用户的操作状态完全依赖于提供者的操作状态。在根据这种关系而彼此依赖的推理点的情况中，意味着一个推理点的故障状态只是依赖于最近的上行流推理点的故障状态。在定位故障根源时，在一个认为其本身与故障无关的推理点之后就不必用localizeIFP继续下去。可以肯定的是上行流没有故障检测推理点。

用关系“isDependentUpon”所做的模型将给出影响图的另一种表现。以付出更多的分支为代价，关系时常会变得较浅一些。

以上所述在图13和14中做了更详细的说明。

假设有四个IFP，即IFP₀、IFP₁、IFP₂和IFP₃关于故障检测行为具有下列关系。

如果IFP₁检测到一个故障，则IFP₀也可以检测到一个故障。

如果IFP₂检测到一个故障，则IFP₀也可以检测到一个故障。

如果IFP₃检测到一个故障，则IFP₁也检测到一个故障。

如果IFP₃检测到一个故障，则IFP₂也检测到一个故障。

图13表示此时产生的isConnectedByInfluence关系模型情况下的图，而图14表示isDependentUpon关系模型情况下的图。

这里将更详细地描述故障协调策略。

故障协调是基于理解到所有处于故障责任推理点下行流的推理点IFP都与之无关，因为不会再检测到新的故障且不会再有新的故障被这些推理点隔开。这些推理点可以处于SLEEPING状态并使其故障检测机制脱离操作。

一旦一个推理点观察到一个检测到的故障处于它的责任域中，它将向所有下行流推理点发送协调方法呼叫coordinateIFP。这个方法呼叫沿着影响图传递直到找到一个故障终结推理点。已观察到故障的测量点的标识跟在方法呼叫后面并被经过的推理点存储。

上面的描述在图15中说明，这里推理点IFP₄观察到一个检测到的故障处于它的责任域中，因此向下行流发送一个方法呼叫coordinateIFP(4)到推理点IFP₇和IFP₈，它们都处于SLEEPING状态并且它们的故障检测机制都设为脱离操作。

现在继续描述故障恢复策略。

当一个故障自动或通过修复而复位时，推理点IFP-它所监控的实体曾找到故障—将检测到故障消失，因为一旦观察到故障它的诊断部分就再次进入操作，具有检测故障消失的任务，如上面参考图5和6所做的描述。所有的下行流推理点将通过故障消除方法呼叫“clearFaultIFP”得到关于故障消失的通知。这个方法呼叫沿着影响图传递直到找到一个故障终结推理点IFP。恢复的推理点IFP的标识跟在该方法呼叫后面。

当一个推理点收到方法呼叫clearFaultIFP时，它将再次开始监控故障。当然所有使这个推理点指向状态SLEEPING的推理点必须首先恢复。

在图16中示意说明了这个描述，其中推理点IFP₄向IFP₇和IFP₈发送方法呼叫clearFaultIFP(4)，它们再次开始监控。

在图17中根据图8的影响图被按照常规方法作为示例的对象关系模型而画出。推理点对象之间的关系的方向应通过定义看作故障传播方向的反方向。特别是这里存在connectedByInfluence关系的问题。

参考图17，connectedByInfluence关系说明：由于IFP₇通过对IFP₄的影响而连接这个事实，被IFP₇检测到的故障也可能已被IFP4和/或任何其它通过对IFP₄的影响而连接的推理点检测到，即此时的IFP₃。

现在将在下面对故障功能对象FO的表示做详细描述。

如前面所讨论的，功能对象FO是在软件中由一个或更多的系统实现的功能的代表。功能对象可以代表所有类型的抽象级别上的功能。

功能对象可以通过推理点IFP表示为故障。换句话说，推理点负责功能的监控。

一旦一个推理点被定位为“故障”，就通知所监控的功能并将其标为故障。在根据图15的例子中，IFP4具有向所有它所监控的功能对象FO发送故障指示消息的责任。

推理点IFP和功能对象FO之间的关系是一个多对多关系，即一个功能可以被很多推理点来监控同时一个推理点可监控很多功能。但是功能对象也可以作为推理点本身来实现。只有诸如coordinateIFP和clearFaultIFP这样的方法呼叫在功能对象之间使用(故障已经被定位)。

一旦故障的根源被定位，即一个推理点被标识为负责首先检测到故障的域，推理点IFP负责指示出了故障的可替换单元。

推理点IFP和可替换RU之间的关系是多对多关系。推理点IFP监控的域可以覆盖多于一个的可替换单元RU。当考虑可替换单元之间的接口时常常出现这种情况。

在一个可替换单元RU被替换之前，依赖于该可替换单元的IFP必须被结束(closeIFP)以便防止不必要的警报。在替换之后，推理点再次进入操作(openIFP)。

为了使得同一次只有一个可替换单元RU指示故障，在推理点IFP中作为一个属性引入一个概率函数。这个概率函数表示处于某个可替换单元RU中的故障的概率，参见图18中的条状图，其中故障概率P以Y轴上0到1的坐标来表示。在三个可替换单元RU1、RU2、RU3中的故障概率以条状图的形式表示。

推理点IFP可以以概率函数为基础，确定将要更换的单元，或者通过与故障指示方法呼叫一起传递概率值，将该判决传递到代表可替换单元的对象RUO。这两种情况在图19中分别作为情况A和B说明。

在情况A中，IFP确定RU1为故障，通过到RUO1的箭头faultyRU来表示。在情况B中对相应对象RUO的判决被传递到RUO1-3，如箭头suspectRU所示(分别为P1、P2和P3)。

考虑功能的故障行为分析的软件模型部分负责有关功能实体的故障协调。

这个模型是相当简单的，因为它只包括一种对象，即通过一个IFP监控的功能对象FO，参见图20。功能对象代表一种由电信设备实现的功能并且它们代表在所有抽象级上的功能。

故障对所监控功能的影响的分析是相当简单的。故障已经被检测、识别并且定位。行为分析在模型化阶段实现。在实时中，该任务限于功能对象FO之间的纯状态传播。

在模型化阶段必须仔细分析功能之间的依赖性。如果一个功能的操作状态依赖于其它功能，就必须作为功能对象之间的isDependentUpon关系反映在软件模型中。

参考图21，FO6被硬件监控模型指示为故障。功能对象FO5和FO3依赖于FO6。因此这两个对象将同样被认为故障。状态的传播将继续下去直到没有更多的依赖性被找到。

依赖性存在于不同抽象级上的功能内部和功能之间。状态传播不限于一个单个电信设备中的对象。一个电信设备中的功能当然可以依赖于另一个这样设备中的功能。

功能对象FO之间的接口以只使用coordinat和clearFault类型的方法呼叫这样的方式来实现，因为故障已经被定位了。

模型有关修复处理的部分被一个有利于故障硬件单元替换的功能使用。图22示出了模型的对象关系表示。

当操作员请求一个修复测量时，这个请求被传递到代表可修复单元的对象RUO。所讨论的请求可以用两种方法之一来实现，即，通过操作员的操作台以及到代表可替换单元RU的被控制对象的接口，或者通过按下装在可替换单元上的一个按钮。

对象RUO通知有关的必须停止检测故障的推理点IFP。每个受到修复活动影响的推理点IFP请求功能对象FO停止当前对功能对象FO所代表的被监控功能的使用。因此可替换单元RU被停止并可能被去掉。当安装一个新的单元时，进入使用之前要对新单元进行启动或接受测试。

假设由于硬件故障可替换单元RU必须被替换。监控该可替换单元RU的所有推理点IFP都接到通知。在有关影响图的下行流的所有推理点IFP同样要接到通知。这就避免了替换硬件时不必要的警告。有关的对象通过状态传播通知。

状态传播一直执行到到达一个推理点IFP，该点满足下列可能性之一：

-推理点IFP是一个故障终结推理点，

-已经将修复活动通知该推理点IFP。

图23是一个例子，其中RU1由于在推理点IFP₄中定位到一个故障而被指示为故障。当需要一个修复测量时，代表RU1的对象立即通知负责监控可替换单元的推理点IFP₂到IFP₈。这些推理点将完全脱离操作，即它们关掉自己的故障检测机制，并将有关单元结束的消息通知给它们负责监控的功能。

应该注意的是推理点IFP在转换到脱离操作模式时，可以改变它的故障传播行为。这是根据图22的例子中IFP₈的情况，参考图8。从修复处理的观点来看，这意味着影响图可以做一些修改。

IFP₈将单元的终结通知给负责监控RU2的IFP₉到IFP_n。这些IFP将只关掉它们的故障检测机制，而不通知有关的功能。

如前面所提到的，每个脱离操作的IFP负责将单元的终结通知给功能对象。功能对象将结束正在进行的对被监控功能的使用。功能对象之间的状态传播用与上面描述的功能的故障协调情况完全相同的方式进行。

结束请求由方法呼叫closeIFP来实现，参见图24。值得注意的是IFP₈在进入透明状态时改变为一个“普通”IFP。IFP₉由于收到带一个与其本身RU关系不同的RU标识的方法呼叫closeIFP而进入SLEEPING状态。

在一个单元脱离操作之前，单元自身执行一次启动或接受测试。启动测试是一个内置的自检功能，只在启动时执行一次。这个测试可以认为是一种纯粹的硬件功能并且不包括在软件模型内。但是，该测试可以被控制该单元的本地处理器控制并监控。

在新单元进入操作之前必须无问题地通过自检。

为了描述一个可替换单元如何进入操作，可以假设到本地处理器中负责硬件监控的应用程序的控制连接已经重新建立。

所有受这个修复活动影响的推理点IFP都得到有关新硬件单元RU安装的通知。因此推理点将开始它们的监控。间接连接到可替换单元RU的推理点，也用结束可替换单元时完全相同的方式，通过沿着影响图的状态传播而被通知。有关开始的请求以方法呼叫openIFP的形式来进行。

一旦一个IFP开始它的监控，就允许使用这个推理点监控的功能对象FO。如果该功能被多个推理点所监控，它们必须等到从所有推理点收到允许时才能使用。

Claims

1.在电信系统中的一个故障监控和管理系统，包括一个在电信系统的故障传播方向上彼此互连的诊断与推理数据实体的链式系统，所述的数据实体在链式系统中的位置这样确定，使它们能够在相应的监控域中每个监控一个由电信系统中的故障所引起的现象，并在故障出现的情况下互相通信、彼此影响和相互作用，以便在电信系统中定位故障。

2.一个根据权利要求1的系统中，每个诊断与推理数据实体使用一个或多个测量点数据实体观察诊断与推理数据实体所监控的现象的出现、并向诊断与推理数据实体报告。

3.一个根据权利要求2的系统中，几个测量点数据实体可以组成一个测量合成数据实体，收集并处理来自其所包含的测量点数据实体的数据。

4.一个根据权利要求1-3中任何一个的系统中，已经在对应的链式系统中检测到一个故障出现的诊断与推理数据实体，在确定故障是否出现于本身的监控域之前，向所述的链式系统中从故障传播方向看去处于这个故障检测数据实体之前的诊断与推理数据实体发送一个故障定位请求，请求它们返回一个有关它们是否检测到故障的确认消息。

5.一个根据权利要求4的系统中，在其它诊断与推理数据实体中的故障搜索一直继续直到找到一个这样的诊断与推理数据实体，它或是构成所讨论的链式系统的开始，或是也检测到一个故障。

6.一个根据权利要求4或5的系统中，如果当前的链式系统在故障检测诊断与推理数据实体之前包括更多的并行分支，那么搜索一次在一个分支中进行。

7.一个根据权利要求4-6中任何一个的系统中，故障定位请求包括一个标识它的来源的标识参数。

8.一个根据权利要求4-7中任何一个的系统中，确认消息包括两个标识参数，一个标识故障定位请求的来源，一个标识发送者。

9.一个根据权利要求4的系统中，每个诊断与推理数据实体具有一个有关的故障序列号，当有关的诊断与推理数据实体检测到一个故障时该号递增一次，所述的序列号作为故障定位请求的一个参数引入并且与沿着有关的链式系统的一个有关的故障定位请求诊断与推理数据实体的标识一起存储起来，存储的信息形成一个上行流分支已经被调查且确认可以立即向下行流发发送的指示。

10.一个根据权利要求4的系统中，如果对于故障检测诊断与推理数据实体，一个链式系统包括几个并行的分支，那么搜索在上行流分支中并行完成，通过请求传递的有关分支的信息加入该故障定位请求的一个参数列表中。

11.一个根据权利要求10的系统中，参数作为一个栈来实现，每个发送定位请求的诊断与推理数据实体向其中添加自己的标识。

12.一个根据权利要求11的系统中，正发送的诊断与推理数据实体通过一个计数器以及存储请求标识来跟踪未应答的定位请求。

13.一个根据权利要求9-12中任何一个的系统中，在确认消息返回之前，必须已经收到每个上行流分支中的确认消息。

14.一个根据权利要求9-13中任何一个的系统中，标识参数通过确认消息返回。

15.一个根据权利要求9-14中任何一个的系统中，每次发送确认时，在栈上执行一次更新操作。

16.一个根据权利要求4-15中任何一个的系统中，一个诊断与推理数据实体，一旦已经确认一个检测到的故障在它的域中，就向故障传播方向上处于下行流的所有诊断与推理数据实体发送一个协调方法呼叫，所述的方法呼叫一直传递到找到一个故障结束诊断与推理数据实体。

17.根据权利要求16的一个系统中，正发送的诊断与推理数据实体的标识跟在协调方法呼叫之后并被呼叫所经过的诊断与推理数据实体储存。

18.一个根据权利要求4-17中任何一个的系统中，当注意到一个故障时，故障的消失由最初检测到故障的诊断与推理数据实体来检测，所述数据实体向所有的下行流诊断与推理数据实体发送一个有关这个的方法呼叫，所述的方法呼叫一直传递到找到一个故障结束诊断与推理数据实体。

19.一个根据权利要求18的系统中，所讨论的诊断与推理数据实体的标识跟在有关故障消失的消息之后。

20.一个根据权利要求19的系统中，在所有曾使一个诊断与推理数据实体脱离操作的诊断与推理数据实体得到恢复之后，当所讨论的诊断与推理数据实体收到关于故障消失的消息时，这个数据实体再次开始监控故障。

21.一种在电信系统中分布式故障处理的方法，包括如下步骤：

分析系统中的数据和信号流以便在故障出现时确定系统行为并因此而定位由故障引起的现象，

通过在电信系统中故障传播方向上彼此互连的诊断与推理数据实体组成的一个或多个链式系统来代表所述的行为，同时

在相应的链式系统中确定数据实体的位置，使它们每个都能在相应的监控域中监控这样的链式系统中出现的所述现象中的一种，并且在故障出现的情况下互相通信、彼此影响和相互作用，以便在电信系统中定位故障，

提供一个或多个与每个诊断与推理数据实体有关的测量点数据实体，以便观察有关的诊断与推理数据实体所监控的现象的出现，并向诊断与推理数据实体报告。

22.一个根据权利要求21的系统，还包括将多个测量点数据实体与一个测量合成数据实体相关联的步骤，以便收集并处理来自所述的测量点数据实体的数据。

23.一个根据权利要求21或22的方法，还包括通过已经在对应的链式系统中检测到一个故障的出现的诊断与推理数据实体，在确定故障是否出现于本身的监控域之前，向所述的链式系统中从故障传播方向看去处于这个故障检测数据实体之前的诊断与推理数据实体发送一个故障定位请求，请求它们返回一个有关它们是否检测到故障的确认消息的步骤。

24.一个根据权利要求23的方法，包括在其它诊断与推理数据实体中继续搜索故障直到找到一个这样的诊断与推理数据实体，它或是构成所讨论的链式系统的开始，或是也检测到一个故障。

25.一个根据权利要求23或24的方法，包括如果当前的链式系统在故障检测诊断与推理数据实体之前包括更多的并行分支，那么搜索一次在一个分支中进行。

26.一个根据权利要求23-25中任何一个的方法中，故障定位请求包括一个标识它的来源的标识参数。

27.一个根据权利要求23-26中任何一个的方法中，确认消息包括两个标识参数，一个标识故障定位请求的来源，一个标识发送者。

28.一个根据权利要求23的方法，包括将一个故障序列号关联于每个诊断与推理的步骤，当有关的诊断与推理数据实体检测到一个故障时将上述的号码递增一次，在故障定位请求中上述的序列号作为一个参数引入，并且与沿着有关的链式系统的一个有关的故障定位请求诊断与推理数据实体的标识一起存储起来，存储的信息形成一个上行流分支已经被调查且确认可以立即向下行流发发送的指示。

29.一个根据权利要求23的方法，包括如下步骤的执行，对于故障检测诊断与推理数据实体，如果一个链式系统包括几个并行的分支，那么搜索在上行流分支中并行进行，通过请求传递的有关分支的信息加入该故障定位请求的一个参数列表中。

30.一个根据权利要求29的方法，包括将参数作为一个栈来实现，并且每个发送定位请求的诊断与推理数据实体向上述的栈中添加自己的标识。

31.一个根据权利要求30的方法中，正发送的诊断与推理数据实体通过一个计数器以及存储请求的标识来跟踪未应答的定位请求。

32.一个根据权利要求28-31中任何一个的方法，包括从链式系统的每个上行流分支中收到确认消息以后才能返回一个确认消息。

33.一个根据权利要求28-32中任何一个的方法中包括，标识参数通过确认消息返回。

34.一个根据权利要求30-33中任何一个的方法中，每次发送确认时，在栈上执行一次更新操作。

35.一个根据权利要求23-34中任何一个的方法中，包括如下步骤：一个诊断与推理数据实体，一旦已经确立一个检测到的故障在它的域中，就向故障传播方向上处于下行流的所有诊断与推理数据实体发送一个协调方法呼叫，所述的方法呼叫一直传递直到找到一个产生故障的诊断与推理数据实体。

36.一个根据权利要求35的方法中包括，正发送的诊断与推理数据实体的标识跟在协调方法呼叫之后并被呼叫所经过的诊断与推理数据实体储存。

37.一个根据权利要求23-36中任何一个的方法中包括，当注意到一个故障时，故障的消失由最初检测到故障的诊断与推理数据实体来检测，同一个诊断与推理数据实体向所有的下行流诊断与推理数据实体发送一个有关这个的方法呼叫直到找到一个故障结束诊断与推理数据实体。

38.一个根据权利要求37的方法中包括，所讨论的诊断与推理数据实体的标识在有关故障消失的消息之后发送。

39.一个根据权利要求38的方法中包括，在所有曾使一个诊断与推理数据实体脱离操作的诊断与推理数据实体得到恢复之后，这个收到关于故障消失的消息的诊断与推理数据实体，再次开始监控故障。