專利名稱：分布式硬件監(jiān)控的方法和系統(tǒng)的制作方法
技術領域：
本發(fā)明一般涉及電信系統(tǒng)中復雜硬件和軟件的管理，特別涉及這樣的硬件和軟件的監(jiān)控。
更特別的是，本發(fā)明涉及一個故障監(jiān)控和故障管理系統(tǒng)，以及一種在電信系統(tǒng)中進行分布式故障管理的方法。
眾所周知復雜的硬件和軟件系統(tǒng)很難用正確的方式監(jiān)控。大多數(shù)系統(tǒng)的監(jiān)控使用帶集中式分析軟件模塊的集中式解決方案。這種分析模塊會變得很大而且復雜，即使是對中等復雜度的系統(tǒng)來說也是如此。當這樣的系統(tǒng)中引入新的硬件和軟件以及改變原有東西時，通常很難根據(jù)新的硬件和軟件更新模型和方法。
本領域相關技術的描述WO 92/17961涉及一種容錯的自適應分布式系統(tǒng)。該系統(tǒng)包括一個至少帶有三個節(jié)點的網(wǎng)絡，每個節(jié)點至少與另一個節(jié)點進行通信。每個節(jié)點用于測試另一個節(jié)點是否處于一種期望或不期望的狀態(tài)。確定N個節(jié)點，這里N是大于或等于3的整數(shù)，是否具有一種期望或不期望的狀態(tài)是可能的，如果一個被測試節(jié)點具有一種期望的狀態(tài)，那么它就被激活變?yōu)橐粋€測試中節(jié)點。如果得到了一個不期望的測試結果，上述過程就在其他節(jié)點上重復直到測試到一個處理器帶有一種期望的狀態(tài)。診斷信息沿著網(wǎng)絡中的通道轉發(fā)。
EP 139,069描述了一種故障診斷分布式系統(tǒng)，該系統(tǒng)帶有多個在一個共同級別上相互互連的子系統(tǒng)，每個子系統(tǒng)具有診斷其它子系統(tǒng)中的故障的功能并基于其它子系統(tǒng)的故障診斷結果保護它本身的子系統(tǒng)。
US 4,627,055表述了一種帶有多個互連的同樣類型的子系統(tǒng)的分散式系統(tǒng)。每個子系統(tǒng)具有診斷其它子系統(tǒng)中故障的診斷裝置以及響應診斷結果進行測量的功能。
US 4,354,267涉及故障處理，其目的是避免使用擴展的“主傳輸控制單元”時的缺點。
內容本發(fā)明總的目的是提供一種模型和應用這種模型，在帶有復雜硬件和軟件的電信系統(tǒng)中設計和實施故障處理的方法。
更特別的是，該模型應該作為電信設備故障行為的軟件表示。通過觀察監(jiān)控實體并使用實體行為的知識，該模型應該能夠在不同的抽象級別和觀點中檢測、識別并定位故障，并且能夠用于協(xié)調來自不同的故障檢測實體的警報。希望該模型也能夠用于復位(自動或手動)一個出故障的單元。
根據(jù)本發(fā)明，上述目的已經(jīng)通過故障監(jiān)控與故障處理系統(tǒng)得到，根據(jù)本發(fā)明該系統(tǒng)包括一個在該電信系統(tǒng)的故障傳播方向上彼此相連的診斷與推理實體的鏈式系統(tǒng)，確定所述的數(shù)據(jù)實體在鏈式系統(tǒng)中的位置可以使其中的每一個、在各自的監(jiān)控域中、監(jiān)控一種可能由該電信系統(tǒng)中的故障所引起的現(xiàn)象，并在故障發(fā)生時能夠互相通信、彼此影響和相互作用，以便定位電信系統(tǒng)中的故障。
根據(jù)優(yōu)選的實施例，每個診斷與推理數(shù)據(jù)實體使用一個或多個測量點數(shù)據(jù)實體，觀察診斷與推理數(shù)據(jù)實體所監(jiān)控的現(xiàn)象的出現(xiàn)、并向診斷與推理數(shù)據(jù)實體報告。
根據(jù)本發(fā)明，在電信系統(tǒng)中分布式故障處理的方法包括這些步驟系統(tǒng)中數(shù)據(jù)和信號的分析流，用于在故障出現(xiàn)時確定系統(tǒng)的行為并因此定位故障所引起的現(xiàn)象。
通過電信系統(tǒng)中故障傳播方向上彼此互連的診斷與推理數(shù)據(jù)實體的一個或多個鏈式系統(tǒng)表示所述的行為，而在數(shù)據(jù)實體相應的鏈式系統(tǒng)中確定它們的位置，使得它們中的每一個都能夠在各自的監(jiān)控域中監(jiān)控一種可能在這樣的鏈式系統(tǒng)中出現(xiàn)的上述現(xiàn)象，并在故障發(fā)生時能夠互相通信、彼此影響和相互作用，以便定位電信系統(tǒng)中的故障，提供關聯(lián)于每個診斷與推理數(shù)據(jù)實體的一個或多個測量點數(shù)據(jù)實體，用于觀察所關聯(lián)的診斷與推理數(shù)據(jù)實體所監(jiān)控的現(xiàn)象的出現(xiàn)，并向診斷與推理數(shù)據(jù)實體報告。
幾個測量點數(shù)據(jù)實體可以方便地組成一個測量合成數(shù)據(jù)實體，收集并處理來自其中所包括的測量點數(shù)據(jù)實體的數(shù)據(jù)。
根據(jù)另一個實施例，診斷與推理數(shù)據(jù)實體在證實它本身的監(jiān)控域中是否出現(xiàn)了故障之前就已經(jīng)檢測到它所對應的鏈式系統(tǒng)中故障的出現(xiàn)，它向所述的鏈式系統(tǒng)中、從故障傳播方向上看處于這個故障檢測數(shù)據(jù)實體之前的診斷與推理數(shù)據(jù)實體發(fā)送一個故障定位請求，請求它們返回一個是否已經(jīng)檢測到故障的確認消息。
在其它診斷與推理數(shù)據(jù)實體中搜索故障最好繼續(xù)進行直到找到了構成所討論的鏈式系統(tǒng)開始的診斷與推理數(shù)據(jù)實體，或是找到了也檢測到故障的診斷與推理數(shù)據(jù)實體為止。
如果當前的鏈式系統(tǒng)在該故障檢測診斷與推理數(shù)據(jù)實體之前包括更多的并行分支，那么搜索一次在一個分支中進行。
優(yōu)選的是故障定位請求包括一個標識它的來源的標識參數(shù)。
確認消息可以包含兩個標識參數(shù)，一個標識故障定位請求的來源，一個標識發(fā)送者。
每個診斷與推理數(shù)據(jù)實體可以有一個與之關聯(lián)的故障序列號，當有關的診斷與推理數(shù)據(jù)實體檢測到一個故障時該號碼步進1，所述的序列號作為故障定位請求中的一個參數(shù)引入并與沿著有關的鏈式系統(tǒng)的有關的故障定位請求診斷與推理數(shù)據(jù)實體的標識一起存儲，存儲的信息形成一個指示，表示上行流分支已經(jīng)被研究且確認能夠立即從下行流發(fā)送。
如果對于故障檢測診斷與推理數(shù)據(jù)實體來說鏈式系統(tǒng)包括幾個并行的分支，搜索就在上行流分支中并行地執(zhí)行，而且通過請求傳遞的關于分支的信息被加到故障定位請求的參數(shù)列表中。
參數(shù)優(yōu)選地作為一個棧來實現(xiàn)，發(fā)送定位請求的每個診斷與推理數(shù)據(jù)實體加上其本身的標識。
發(fā)送的診斷與推理數(shù)據(jù)實體可以通過計數(shù)器裝置和保留請求的標識來跟蹤未應答的定位請求。
在確認消息返回之前，最好已經(jīng)收到每個上行流分支中的確認消息。
標識參數(shù)可以通過確認消息返回。
每次發(fā)送確認消息時，最好在棧上執(zhí)行更新操作。
根據(jù)另一個優(yōu)選的實施例，診斷與推理數(shù)據(jù)實體一旦已經(jīng)證實所檢測的故障處于它的域之中，就向故障傳播方向上所有處于下行流的診斷與推理數(shù)據(jù)實體發(fā)送一個協(xié)調方法呼叫，所述的方法呼叫一直傳遞直到找到一個故障結束診斷與推理數(shù)據(jù)實體。
發(fā)送中的診斷與推理數(shù)據(jù)實體的標識最好跟在協(xié)調方法呼叫之后并由呼叫所經(jīng)過的診斷與推理數(shù)據(jù)實體儲存起來。
當故障被處理之后，故障的消失是由最初檢測到故障的診斷與推理數(shù)據(jù)實體檢測的，所述的數(shù)據(jù)實體向所有下行流的診斷與推理數(shù)據(jù)實體發(fā)送一個與之有關的方法呼叫，所述的方法呼叫一直傳遞直到找到一個故障結束診斷與推理數(shù)據(jù)實體。
所討論的診斷與推理數(shù)據(jù)實體的標識最好跟在有關故障消失的消息之后。
當一個診斷與推理數(shù)據(jù)實體接收到有關故障消失的消息時，這個數(shù)據(jù)實體再次開始監(jiān)控故障，此后所有曾引起這個診斷與推理數(shù)據(jù)實體脫離操作的診斷與推理數(shù)據(jù)實體均已恢復。
用另一種方法來表述，根據(jù)本發(fā)明建立了一種執(zhí)行該方法的模型，包括真實硬件和軟件實體行為的子模型，以及電信系統(tǒng)中實現(xiàn)的更加抽象的實體的行為的子模型。代表硬和軟件中某種實現(xiàn)的邏輯功能值得作為例子一提。該模型也包含將被說明為可替代的實體及與之有關的實體的子模型。更特別的是，這里可替代的實體意味著可以被替換的最小的硬件部分，常常是一塊單個板或一條單個電纜。使用模型的這個部分的目的是在故障時進行測量活動—一種下面稱為修復處理的活動。
代表不同電信系統(tǒng)的模型之間的通信需要是該模型中所固有的。
包括在根據(jù)本發(fā)明的方法中的故障監(jiān)控的部分方法，基于問題的分布式方法。用這種方法，根據(jù)本領域的狀態(tài)的集中分析軟件模塊將是不必要的。
模型中使用的不同對象具有嚴格規(guī)定和完善說明的任務，如被監(jiān)控的實體的觀察、癥狀產(chǎn)生—即匯集和處理觀察、診斷/分析一個被觀察的實體或多個實體，以及不同分析實體之間最后的狀態(tài)傳播。這使得建立被監(jiān)控系統(tǒng)的結構良好的模型變得很容易。
與故障如何產(chǎn)生的傳播性質有關的、代表被監(jiān)控實體的行為的圖形記號包括在本發(fā)明中。硬件和軟件實現(xiàn)的改變將導致代表硬件和軟件的圖形的改變。這意味著變化可以用相對簡單和結構化的方法處理。
分布式方法以及圖形記號可以更容易地理解不同的故障是如何彼此影響的以及特定的故障是如何產(chǎn)生的。
本發(fā)明的方法，即概念和圖形記號，也可用于硬件和軟件的設計。這有助于硬件和軟件的設計者對故障的密度和故障在目前硬件和軟件設計中的傳播、以及可能的故障檢測程度得到一個較好的了解，并優(yōu)化故障可替代單元的表示。此外，從硬件和軟件設計文件中產(chǎn)生并實現(xiàn)軟件模型是非常容易的。
根據(jù)本發(fā)明，該模型的觀察和癥狀產(chǎn)生部分可以復用為電信系統(tǒng)中的性能計算功能。
硬件和軟件監(jiān)控模型可以遞歸地使用，即用于硬件和軟件監(jiān)控的機制類似地被該模型所監(jiān)控。例如，硬件和軟件的監(jiān)控用于執(zhí)行硬件和軟件監(jiān)控中的觀察。
該模型可以推廣為對所有類型的硬件和軟件系統(tǒng)均有效。
附圖的簡要描述下面將參考附圖對本發(fā)明做更詳細的描述，其中

圖1示意性并以框圖的形式表示了一個數(shù)據(jù)處理系統(tǒng)，也圖示說明了一個這里包括的本發(fā)明的實施例，圖2示意性地圖示說明了故障處理的軟件模型，圖3表示與一個裝置的故障處理和修復處理有關的對象實體關系的模型，圖4是說明故障定位原則的影響圖表，圖5示意性地說明了一個帶有接收和發(fā)送方法呼叫的裝置、以及內部和外部接口的診斷與推理點對象的設計，圖6表示了一個狀態(tài)圖，說明根據(jù)圖5的對象的不同的可能狀態(tài)和狀態(tài)傳輸，圖7表示下列圖中所示的影響圖中的某些圖形符號的意義，圖8是這樣一個影響圖的例子，圖9表示關于故障定位的一個影響圖的例子，圖10表示一個說明根據(jù)圖9的例子中的確認測量的圖，圖11是一個說明有關故障定位的搜索算法的第一改進的圖，圖12是一個說明有關故障定位的搜索算法的第二改進的圖，圖13和14示意性地說明了在影響圖外觀上帶有兩種不同關系類型的模型的影響，圖15表示一個用于描述故障協(xié)調的影響圖，圖16表示一個說明故障復位的影響圖，圖17表示根據(jù)圖8的影響圖的對象關系模型，圖18表示一個概率函數(shù)的例子，
圖19表示當使用根據(jù)圖18的概率函數(shù)時，故障可替換單元故障處理的兩種情況，圖20表示用于功能的故障處理分析的一個模型的功能分析部分，圖21說明功能對象之間的狀態(tài)傳播，圖22說明修復處理模型的設計，圖23表示可能與修復處理有關而出現(xiàn)的一個影響圖的例子，圖24說明了一個可替換單元的結束的例子，圖25-27是表示圖5中包括的每個接口的狀態(tài)變換表。
實施例的詳細描述將在下面描述的本發(fā)明的實施例，為了簡單起見，基于這樣的假設存在一個面向對象的分布式數(shù)據(jù)系統(tǒng)的問題。但是，并且更普遍地說，本發(fā)明不僅限于這種類型的系統(tǒng)，也可用于其它類型的為使用另一種特性的數(shù)據(jù)實體而不是對象而設計的系統(tǒng)。
對于下面以及附圖上出現(xiàn)的與包括消息和方法呼叫在內的信號、以及參與者的描述有關的表示，使用了結構化編程的常規(guī)命名規(guī)則，例如Stanley B.Lippman的書“C++入門”，Addison-Wesley出版公司，第二版中描述的那類。所討論的表示的較詳細描述和它們的含義將參考圖5在下面給出。
為了簡單起見，下面描述的本發(fā)明的實施例主要是針對硬件監(jiān)控。但是，本發(fā)明也可用于軟件監(jiān)控，這將在下面的一些情況中描述。
圖1示意性地表示、同時也作為一個例子、一個數(shù)據(jù)處理系統(tǒng)的一部分，包括一個標為2的中央處理器CP，以及與之相連分別標為4和6的本地處理器DP。故障處理模型在這樣一個系統(tǒng)上的應用將在下面做更詳細的描述。
根據(jù)本發(fā)明的故障處理模型一般包括三個相當獨立的子模型。模型的這種劃分反映了故障處理要進行的主要任務，即—硬件監(jiān)控，如在處理器2、4和6中。這部分用于檢測故障，識別故障類型并在硬件中定位故障的起源，在這里一個或多個故障單元，可替換單元及/或功能單元都可能表示為故障。模型的這個部分在下面也標為“硬件監(jiān)控模型”。可替換單元—圖1中的8和10分別表示兩個，并假設它們分別包括在處理器4和6中—在本連接中可能是最小的可替換的硬件部分，一般是一塊單個板或一根單個電纜。
—功能的故障協(xié)調或關于故障行為的功能分析。這種操作在檢測到故障而且一個或多個功能指示為故障時啟動。在功能上故障影響的分析由功能本身并在功能之間進行。模型的這部分在下面也稱為“功能級上的故障處理模型”。
—修復處理。這種操作在一個可替換單元被硬件監(jiān)控指示為故障時開始。模型的這部分在下面也稱為“修復處理模型”。
模型的這種劃分也可根據(jù)圖2映射在不同的抽象級上，這里硬件監(jiān)控部分標為12，在一個功能級上的故障處理部分FH標為14，而修復處理部分RH標為16。后者示為包括一個硬件單元的子模型17。所討論的級在圖中表示，例如包括一個依賴硬件的功能的“低”級別18，和一個抽象邏輯功能的“高”級別22。
更進一步，硬件的監(jiān)控，用箭頭24、26、28表示，當然依賴于硬件的實現(xiàn)。模型的這部分可以在級別18上找到并且部分在本地處理器4和6中實現(xiàn)。負責通過功能進行故障影響分析的部分可在抽象級別18和22上找到。每個系統(tǒng)，或子系統(tǒng)，必須通過模型的兩個部分12和14建立自己的模型。
最后部分16，修復處理模型，由下面更詳細討論并代表著可替換單元的對象建立，如8和10。修復處理部分16也影響模型其它兩部分中的實體。當系統(tǒng)可以在一個且同一個可替換單元上實現(xiàn)時，修復處理模型對幾個系統(tǒng)或子系統(tǒng)可以是公共的。
在圖2中，還在30標出了一個硬件接口和帶虛線框32的硬件模型17的物理對應物。34和28處的功能模型進一步表示。
如果作為一種替換，被觀察的測量點處于軟件中，例如，軟件中的一個故障計數(shù)器，圖2中的部分16和17就消失了，部分12被軟件監(jiān)控部分取代，硬件接口30被軟件接口取代。
同樣下面將會出現(xiàn)，代表不同系統(tǒng)或子系統(tǒng)的模型可以通過不同模型中的對象之間傳播狀態(tài)而彼此通信。不同模型之間的通信和一個模型內的通信沒有任何不同。
圖3表示一個設備故障處理及修復處理的對象關系模型。該模型包括多個診斷與推理點對象。其中一個以圖3中的40表示。為了簡便，這些對象下面將以推理點、或IFP來標識。這樣的一個推理點IFP負責數(shù)據(jù)或信號流的特定部分的監(jiān)控。
圖3中以箭頭表示的推理點IFP 40監(jiān)控一個可替換單元對象44，此后也稱為RUO，代表一個可替換單元46，此后也稱為ru，用虛線表示。以箭頭48表示，推理點IFP 40還監(jiān)控一個功能對象50，此后也稱為FO。這里，功能對象FO的意思是由一個或多個系統(tǒng)執(zhí)行的一個功能的軟件表示。
以箭頭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與硬件相互作用，用于觀察可能的狀態(tài)轉移。檢測硬件故障的方法在某些情況下非常依賴于硬件的實現(xiàn)。由于與硬件有著緊密關系，MEP時常、但并不必須總是，分布到一個當前的本地處理器中，正如曾參考圖1描述的那樣。
在公布一個觀察之前，已做了大量被觀察實體mep的數(shù)據(jù)處理。在測量點MEP中公布的測量結果可能是一個計數(shù)值、一個數(shù)據(jù)處理過的計數(shù)值、或任何其它的硬件或軟件信號。但是，測量點MEP既不分析也不做出任何關于被觀察實體mep的結論。
如果必要，測量點MEP也可通過軟件調整。一個例子是給使用的方法置一個門限值。
如果合適，來自不同測量點MEP的觀察可以合成一個測量合成對象55，此后也稱為MEC(測量合成對象)，它同樣可以被推理點IFP 40使用。在圖1中，本地處理器6中55.1處表示了一個MEC。來自測量合成對象MEC的輸出可以看作硬件中被觀察實體的一個癥狀。與測量點一樣，測量合成對象MEC從不分析任何數(shù)據(jù)。但是測量合成對象MEC可以收集并處理來自它所包括的測量點MEP的數(shù)據(jù)。這種處理經(jīng)常在軟件中進行?！凹毣挠^察”一癥狀留待進一步分析。
假設使用的觀察在適當?shù)奶幚砥髦惺怯行У?，即使用的測量點MEP必須位于與測量合成對象MEC相同的處理器中，那么測量合成對象MEC可以整個或部分地在本地處理器的軟件中實現(xiàn)，如圖1中的4和6。
基于來自MEP和/或MEC的觀察，一個IFP通過分析觀察并確定是否已檢測到故障對特定的硬件進行診斷。
除了分析故障癥狀，IFP也負責故障定位。能夠定位引起故障的真實原因是很重要的，這樣就能夠指向正確的可替換單元。由于硬件故障可以通過幾個IFP檢測，就必須有一種方法確定哪個IFP檢測到了故障的根源。
大的硬件故障影響多個不同的IFP。故障系統(tǒng)時鐘可以，例如，暗示一個單元中監(jiān)控一串單元的IFP交替檢測故障。為了能夠定位故障的根源，IFP必須能夠彼此覺察。它們必須按照能被另一個IFP影響的IPF將出現(xiàn)的方式以確定的順序相互排列。
故障定位可以通過將所有能夠彼此影響的IFP置入一個影響鏈來執(zhí)行。能夠影響所有其它IFP的IFP應該放在上行流的最上端，然后其它IFP按照影響的順序放置。不能影響任何其它IFP的IFP放在下行流的最下端。
故障定位的原則通過圖4中所示的影響圖說明。根據(jù)上面的描述，在圖中IFP1和IFP5分別是處于上行流最上端和下行流最下端的IFP，而IFP2和IFP4則處于影響順序的中間。在圖4中，故障定位的相應步驟編號為1-7。
基于步驟1中來自MEP52的觀察，IFP4通過分析該觀察作出關于某個硬件54的診斷并且確定已經(jīng)檢測到一個故障。IFP4因此在步驟2中向上行流處于最近的IFP，即IFP2發(fā)出一個故障定位的請求，“定位故障”。步驟3中，故障定位請求被轉發(fā)到上行流最上端的IFP，即IFP1。IFP1和IFP2在步驟4和5中響應定位請求，在這種情況下應答為“無故障”。當IFP4從上行流的IFP接收到這個響應時，定位過程結束并且找到了故障的根源，即，IFP4本身監(jiān)控的硬件。
當找到故障根源時為了避免不必要的故障傳播，檢測到故障屬于自身監(jiān)控域的IPF，即IFP4，在步驟6中用“協(xié)調”向處于下行流的IFP，此時為IFP5，發(fā)送一個指令，使之進入休息狀態(tài)。
應該補充的是上面描述的故障定位過程是非常簡單的。影響鏈可能很復雜并形成相當復雜的網(wǎng)絡，正如下面接著會出現(xiàn)的那樣。
從故障傳播的觀點來說，故障定位和故障協(xié)調密切依賴于硬件的行為。這在下面將做更詳細的描述。
從故障傳播的觀點來看，在建立硬件行為的軟件模型之前，必須分析并清楚地了解硬件中的數(shù)據(jù)和信號流。從這些流中，建立子模型而且它們被模型的硬件監(jiān)控部分所監(jiān)控。
正如上面參考圖4的描述中所體現(xiàn)的，數(shù)據(jù)或信號流的行為通過一串互連的推理點IFP來體現(xiàn)。參考故障所產(chǎn)生的傳播，通過流的行為確定這些連接，并且這些連接用于故障檢測推理點IFP的定位上。在同一鏈中的推理點IFP必須彼此之間存在故障影響。將一個推理點IFP放在某個影響鏈中的原因是，如果這個引入的推理點檢測到一個故障，在鏈中位置較前的一些推理點可能也檢測到了同樣的故障。盡管如此，一個鏈中的推理點IFP并不測量同一個事物，但它們可能檢測到同樣的真實硬件故障。如果硬件中出現(xiàn)一個故障，可能被幾個推理點IFP檢測到，而且這些推理點必須包括在同一個影響鏈中。
即使鏈中的推理點IFP能夠檢測到同樣的硬件故障，事實上，所有的推理點也不一定都檢測到該故障，因為推理點是從不同的角度來搜索故障的，已經(jīng)提到過，它們不是測量同一個事物的。
故障產(chǎn)生結束的一個推理點IFP，例如圖4中的IFP4，稱為故障結束推理點。故障產(chǎn)生的傳播不能超過這個點，而且影響鏈也因此結束。
為了對下面參考圖7及以下的圖所描述的影響鏈和它們的功能有更好的理解，將參考圖5和6對影響點IFP的設計、它的不同狀態(tài)、以及它所發(fā)送和接收的方法呼叫做更詳細的描述。
一個推理點IFP包括一個診斷部分60，“IFPdiagnoser”，在下面和附圖中也縮寫為“IFPdiag”，用于分析和診斷與被觀察實體有關的觀察及癥狀。在故障處理情況下，分析和診斷是圍繞故障而執(zhí)行的，即，推理點IFP負責檢測和識別硬件中的故障。推理點IFP負責確定它是否檢測到了一個故障。推理點IFP具有檢測和識別單一類型故障的任務。當一個推理點IFP檢測并識別出一個故障時，對于一個正確的推理點來說還有定位故障根源的任務。不能非常確定故障起源于檢測到故障的推理點IFP。故障的產(chǎn)生可能由任一別的地方的一些其它故障所引起。當一個可替換單元RU和功能出了問題、應該被識別出故障時，對故障進行正確定位十分重要。
當故障的根源已經(jīng)定位到了某個推理點IFP時，必須與其它故障檢測推理點IFP協(xié)調該故障，以避免推理點之間不必要的狀態(tài)傳播。
推理點IFP有一個相互作用和狀態(tài)傳播部分62，“IFPpropHandler”，在下面和附圖中也縮寫為“IFPprop”，假如推理點所識別的故障彼此依賴，它允許推理點彼此相互作用。當負責產(chǎn)生故障域的故障檢測推理點應該被定位時，這就很必要，即，必須能夠指出正確的可替換單元。
參見圖2，根據(jù)箭頭64，相互作用和狀態(tài)傳播部分62分別通過指令“openIFP”和“closeIFP”，從修復處理模型部分RH，經(jīng)由下面更詳細描述的接口IFPcontrolI進入或退出操作。
假如所使用的觀察和癥狀在正確的處理器中生效，推理點的分析和診斷部分60可以完全或部分地由本地處理器中的軟件來實現(xiàn)，如圖1中的處理器4和6。但是，對象的相互作用狀態(tài)傳播部分62總是在高級計算機系統(tǒng)中實現(xiàn)的，如圖1中的中央處理器2。圖1中也說明了每個推理點的分析和診斷部分IFPdiag 60.1和60.2分別處于本地處理器4和6中，而且各自對應的狀態(tài)傳播部分IFPprop 62.1和62.2也處于中央處理器2中。顯然，IFPdiag60.1使用MEP52.1，IFPdiag60.2使用MEC55.1，后者使用兩個MEP，52.2和52.3。
根據(jù)箭頭66，從相互作用狀態(tài)傳播部分62到診斷部分，分別通過方法呼叫doDiagnose、startDiagnose和stopDiagnose給出進行診斷、開始繼續(xù)診斷、和停止一個進行中的診斷的指令。在相反方向上，根據(jù)箭頭68，分別通過errorDetected和noErrorDetected給出關于故障是否檢測到的信息消息。IFPpropHandler 62和IFPdiagnoser60之間的通信通過下面詳細描述的接口DII執(zhí)行。在圖5中也表示了接口IFPtoIFP，通過這個接口產(chǎn)生與其它IFP的通信，以及在一側的IFPdiagnoser 60與在另一側的MEP和MEC之間、MEC和MEP之間的接口MEI。圖5中包括的接口現(xiàn)在將在下面詳細描述。
接口IFPcontrolI包括方法openIFP(ruID)，啟動IFP，openIFP(ruID)，結束IFP，以及方法verifyIFP()，通過初始化一個doDiagnose序列校驗IFP，可能的返回值是verifyOK、verifyNotOK、verifyRejected。
接口IFPtoIFP在IFP之間提供處理故障定位、故障協(xié)調和故障恢復的方法，是客戶機/服務器、方法/方法類型的接口。
因此該接口由故障定位和故障協(xié)調的方法、以及故障恢復的方法組成。
故障定位和故障協(xié)調的方法是localizeIFP(IFPid)，coordinateIFP(faultID)，noFaultyIFP(reqIFPid，sending IFPid)。
故障恢復的方法是clearFaultIFP(faultID)。
客戶機IFP向服務器IFP發(fā)送定位方法呼叫，該服務器與客戶機IFP具有connectedByInfluence關系。接收方法呼叫的服務器IFP進入“定位”動作。當處于上行流的一個分支中的定位循環(huán)結束時，這個IFP將向客戶機IFP發(fā)送這個“定位”的確認。如果沒有IFP指示找到了故障，就向客戶機IFP發(fā)送notFaultyIFP，否則發(fā)送協(xié)調方法呼叫。
方法呼叫的交換可以由服務器IFP通過發(fā)送協(xié)調方法呼叫來啟動。這個方法呼叫告知已經(jīng)找到了一個指示故障的IFP并且應該與其它受影響的IFP協(xié)調。通過在該方法呼叫中標識指示故障的IFP的IFPid參數(shù)使這種協(xié)調成為可能。
故障恢復基于clearFault方法呼叫的交換。
當服務器IFP在受到故障影響之后處于滿操作中時，這個IFP通過發(fā)送clearFault呼叫可以啟動方法呼叫的交換(自動恢復)。
接口沒有狀態(tài)，只有先決條件P。入方法呼叫將根據(jù)特定的先決條件P產(chǎn)生一個出方法呼叫P1服務器IFP已從它所有的上行流相鄰IFP收到notFaultyIFP方法呼叫。
P2服務器IFP在一個doIFPdiagnose請求之后已收到一個noErrorDetected方法呼叫。
P3服務器IFP從它上行流相鄰的一個IFP中收到“協(xié)調”方法呼叫。
P4服務器IFP從IFPdiagnoser收到errorDetected方法呼叫。
P5服務器IFP收到noErrorDetected方法呼叫，它不是通過doIFPdiagnose作為確認而接收的，而是故障狀態(tài)結束退出的狀態(tài)。
圖25表示了一個接口IFPtoIFP處的狀態(tài)變換表，其中包括了上面的先決條件。
IFPpropHandler和IFPdiagnoser之間的接口DII的目的是指示開始和結束關于到IFPdiagnoser的診斷請求的方法。這是一個客戶機/服務器類型的方法/方法接口并且由激活和關閉診斷操作以及請求診斷循環(huán)的請求方法組成。
請求診斷操作的方法處于IFPdiagnoser中，它們是-startIFPdiagnose(IFPid，diagnoseType)startIFPdiagnose方法請求IFPdiagnoser開始診斷被監(jiān)控的硬件和軟件?！癲iagnoseType”可以是“l(fā)ookingForError”或“l(fā)ookingForRecovery”。
-stopIFPdiagnose(IFPid)stopIFPdiagnose方法指示IFPdiagnoser停止它的診斷動作。
-doIFPdiagnose(IFPid)doIFPdiagnose方法指示IFPdiagnoser執(zhí)行一次診斷。IFPdiagnoser總會響應，即使沒有找到故障。
在上面提到的方法呼叫中，“IFPid”是發(fā)送呼叫的IFPpropagationHandler的標識。
響應診斷操作的方法處于IFPpropHandler中，如下-errorDetectederrorDetected方法通知IFPpropHandler已經(jīng)找到一個故障。
-NoerrorDetected通知IFPpropHandler沒有找到故障。
此外下面的其它方法也處于IFPpropHandler中-DiagnoserOK通知IFPpropHandler到本地處理器的鏈路處于操作中。
-DiagnoserNotOK通知IFPpropHandler到本地處理器的鏈路脫離操作。
關于動態(tài)行為，使用下面請求診斷執(zhí)行的方法呼叫接口基于方法呼叫互換startIFPdiagnose(IFPid，diagnoseType)，stopIFPdiagnose(IFPid)，doIFPdiagnose(IFPid)。在方法呼叫startIFPdiagnose(IFPid，diagnoseType)中，參數(shù)diagnoseType指示服務器應該檢查故障還是故障恢復。如果服務器收到一個startIFPdiagnose，如果故障出現(xiàn)的話用errorDetected來響應。如果方法呼叫startIFPdiagnose指示檢查恢復，當故障已經(jīng)恢復時診斷單元用noErrorDetected來響應。
方法呼叫stopIFPdiagnose不從服務器接收任何響應。
方法呼叫doIFPdiagnose指示服務器執(zhí)行一個診斷測試周期，其中來自服務器的應答是errorDetected或noErrorDetected。
例如，為了通知客戶機到本地處理器的鏈路脫離操作，服務器可以使用方法呼叫diagnoseNotOK。當鏈路再次處于操作中時，服務器發(fā)送diagnoserOK。
在圖26中表示了DII接口所有可能的狀態(tài)變換，先決條件是已經(jīng)檢測到一個故障情況。這些狀態(tài)轉移也在圖6中的狀態(tài)圖和下面所附的描述中出現(xiàn)。
IFPdiagnoser和MEP之間、IFPdiagnoser和MEC/MEP之間的接口MEI提供從MEP或MEC對象得到測量樣本的方法。這些樣本可以用于操作處理或故障處理。
該接口由獲得執(zhí)行診斷的測量樣本的方法組成?？蛻魴C使用下列方法-startMeasurement(receiverID，measurementSpecificaiton，-IDofCallingObject)，-stopMeasurement(IDofCallingObject)。
服務器中的方法startMeasurement用于向請求的對象提供多個報告，每個報告包括一個樣本清單。不同對象(IFP)使用方法startMeasurement，得到關于被測量實體的樣本。當服務器收到方法呼叫startMeasurement時，它開始從被監(jiān)控的對象收集樣本。這些樣本用方法呼叫retrieveSamples送到服務器。
可以并行處理一個以上的請求。
下列參數(shù)由方法startMeasurement使用-MEPidMEP的標識。這個標識必須是唯一的。
-measurementSpecificaiton給出每個MEP類型的信息。例如，它可以是事件的問題或時間激勵的MEP。
-IDofCallingObject這個參數(shù)是開始一次測量的對象的標識。
在服務器對象中的方法stopMeasurement將用于停止一個對象對服務器的所有測量請求。該呼叫對象的所有激活的測量將不需要任何報告就立即停止。這個方法接受下列參數(shù)-IDofCallingObject見上面下列方法由服務器使用-retrievedSamples(listOfSamples，IDofCallingObject)-DP_linkError()-DP_linkErrorCeased()方法retrievedSamples由客戶機提供并用于允許將請求的樣本返回到客戶機。這個方法接受下列參數(shù)-listOfSamples一個帶有請求服務器發(fā)送的樣本的鏈接的列表。
-IDofCallingObject見上面用方法呼叫DP_linkError和DP_linkErrorCeased，服務器可以通知客戶機本地處理器鏈路的狀態(tài)。
當發(fā)送方法呼叫DP_linkError時，表示MEI接口不再存在。當發(fā)送方法呼叫DP_linkErrorCeased時，表示接口已經(jīng)重新建立。
在圖27的表中，指明了MEI接口所有可能的狀態(tài)轉移。
IFP的相互作用和狀態(tài)傳播部分62可以取圖5中70處所示的多個狀態(tài)，由下面將詳細描述的IFP鏈中發(fā)生的情況來確定。所討論的狀態(tài)，以及它們之間的轉移，將在下面參考圖6中所示的狀態(tài)圖、并繼續(xù)參考圖5及其接口的描述做更詳細的描述。在圖6中使用了下列縮寫ed errorDetected(檢測到錯誤)nednoErrorDetected(未檢測到錯誤)loclocalizeIFP(定位IFP)notf notFaultyIFP(無故障IFP)coord coordinateIFP(協(xié)調IFP)clrf clearFault(清除故障)參考圖6中的圖，上述的狀態(tài)為CLOSED、ACTIVE、SLEEPING、FAULTY和SLEEPING/FAULTY。通過出現(xiàn)的箭頭說明這些狀態(tài)之間的轉移。下面將詳細描述導致不同轉移的方法呼叫，通過使用所討論的縮寫來表示，即輸入信號到本身IFP/輸出信道到下一個IFP在CLOSED或“透明”狀態(tài)，IFP在IFP鏈中是透明的。該透明狀態(tài)通過上面提到的方法呼叫closeIFP，或通過觀察機制中的故障狀態(tài)來激勵，例如，由于圖1中的處理器2和4之間的鏈路中斷，它將會導致IFP 62.1的一個透明狀態(tài)。
透明狀態(tài)意味著，根據(jù)箭頭72方法呼叫l(wèi)ocalizeIFP以及根據(jù)箭頭74方法呼叫coordinateIFP、notFaultyIFP和ClearFaultIFP只能進一步傳遞到鏈中的下一個IFP。診斷部分60也脫離操作。這些方法呼叫的意義將進一步更詳細地體現(xiàn)出來。CLOSED狀態(tài)是系統(tǒng)啟動之前、以及當啟動了一個修復活動時IFP進入的最初狀態(tài)。CLOSED狀態(tài)也存儲了可替換單元標識的列表，因為一個IFP的操作狀態(tài)可能依賴于更多的可替換單元。
-轉移1，箭頭80closeIFP(ruID)/closeIFP(ruID)舊狀態(tài)CLOSED，ACTIVE，SLEEPING，F(xiàn)AULTY以及SLEEPING/FAULTY。
新狀態(tài)CLOSED啟動了一個修復活動并且IFP設置為透明狀態(tài)。通過輸出信號closeIFP(ruID)通知下行流IFP，這里ruID代表可替換單元的標識并用于使同時管理多個可替換單元的替換成為可能。
在ACTIVE狀態(tài)中，這對于IFP這是一個“正常”狀態(tài)，診斷部分60操作并搜索故障。診斷部分被上面提到的指令或方法startDiagnose啟動。
-轉移2，箭頭82openIFP(ruID)/openIFP(ruID)舊狀態(tài)CLOSED新狀態(tài)ACTIVEIFP被激活，例如，在一次修復或系統(tǒng)啟動之后。通過輸出信號openIFP(ruID)通知下行流IFP。觀察到該狀態(tài)轉移需要該IFP所依賴的所有可替換單元脫離操作，即，openIFP已經(jīng)從列表中的所有可替換單元收到。
-轉移3，箭頭84noErrorDetected/-舊狀態(tài)ACTIVE
新狀態(tài)ACTIVEIFP的診斷部分60已經(jīng)報告沒有檢測到錯誤。
-轉移4，箭頭84localizeIFP(reqId)/localizeIFP(reqId)舊狀態(tài)ACTIVE新狀態(tài)ACTIVE已經(jīng)從下行流IFP收到輸入信號localizeIFP，該方法呼叫傳遞到上行流IFP。呼叫IFP的標識-reqID，與方法呼叫l(wèi)ocalize(定位)所傳遞到的上行流分支的標識一起存儲起來。
-轉移5，箭頭84notFaultyIFP(reqId，sendingId)/notFaultyIFP(reqId，sendingId)舊狀態(tài)ACTIVE新狀態(tài)ACTIVE在上行流分支中沒有找到檢測到故障的IFP。輸入信號notFaulty被傳遞到下行流IFP。
應該注意的是，在方法呼叫notFaultyIFP可以被傳遞之前，必須指示診斷，即doDiagnose。為了處理它，必須引入一個子狀態(tài)。但是，在所假設的狀態(tài)圖中所示的簡化表示中，IFP已經(jīng)知道了這樣一個診斷操作的結果，即沒有檢測到故障。
-轉移6，箭頭86clearFaultyIFP(recoveredId)/clearFaultyIFP(recoveredId)舊狀態(tài)SLEEPING新狀態(tài)ACTIVE較早檢測到故障的IFP，即不是這個IFP，已經(jīng)檢測到因為某種原因故障消失了，并在輸入信號中做了指示。在這種情況下，可以假設被恢復的故障正是在影響鏈的上行流部分中檢測到的一個，即這是休眠請求IFP的列表中最后的IfpId。休眠請求IFP的列表在下面對狀態(tài)SLEEPING的描述中做更詳細的聲明。
方法呼叫通過到下一個下行流IFP的輸出信號來傳遞。
-轉移7，箭頭88noErrorDetected/clearFaultIFP(recoveredId＝thisId)舊狀態(tài)FAULTY
新狀態(tài)ACTIVE這個IFP檢測到以前由這個IFP檢測到的故障已經(jīng)消失。方法呼叫clearFaultIFP在下行流上傳遞到下一個IFP。
在狀態(tài)SLEEPING中IFP的診斷部分60被解除激活。這個狀態(tài)用兩個步驟進入-診斷部分檢測到一個故障，啟動了一個定位機制，引起方法呼叫l(wèi)ocalizeIFP被送往IFP鏈的下行流，-已經(jīng)接收到方法呼叫coordinateIFP，意味著IFP鏈中上行流存在一個故障，并在所討論的IFP中導致進入SLEEPING狀態(tài)。
在SLEEPING狀態(tài)中存儲了一個已經(jīng)進入FAULTY狀態(tài)的上行流IFP的標識的列表。所有引入該列表的IFP指示這個IFP進入狀態(tài)SLEEPING。
-轉移8，箭頭90errorDetected/localizeIFP(reqId＝thisId)舊狀態(tài)ACTIVE新狀態(tài)SLEEPING診斷部分檢測到一個故障，啟動了一個定位機制，方法呼叫l(wèi)ocalizeIFP被送往上行流。
-轉移9，箭頭90coordinateIFP(faultyId)/coordinateIFP(faultyId)舊狀態(tài)ACTIVE新狀態(tài)SLEEPING接收到輸入信號coordinateIFP，即有一個上行流IFP檢測到一個故障。
-轉移10，箭頭92clearFaultIFP(recoveredId)/clearFaultIFP(recoveredId)舊狀態(tài)SLEEPING新狀態(tài)SLEEPING以前檢測到故障的IFP檢測到故障已經(jīng)恢復并且通過方法呼叫clearFault通知這個情況，該方法呼叫進一步向下行流傳遞。在這種情況下，假設這個恢復的故障不是影響鏈上行流部分中檢測到的唯一一個，即，這不是休眠請求IFP列表中最后一個Ifpid。
方法呼叫通過到下一個下行流IFP的輸出信號傳遞。
-轉移11，箭頭92localizeIFP(reqId)/-舊狀態(tài)SLEEPING新狀態(tài)SLEEPING這個IFP已經(jīng)被協(xié)調且因此這個定位呼叫可以被忽略。
-轉移12，箭頭92coordinateIFP(faultyId)/coordinateIFP(faultyId)舊狀態(tài)SLEEPING新狀態(tài)SLEEPING接收到一個輸入信號coordinateIFP，即有一個上行流IFP檢測到一個故障。如果檢測到這個故障的IFP已經(jīng)被協(xié)調，該協(xié)調被忽略，否則該標識被存入休眠請求IFP的列表中。
-轉移13，箭頭92notFaultyIFP(“not expected”)/-舊狀態(tài)SLEEPING新狀態(tài)SLEEPING不考慮這個輸入信號。
-轉移14，箭頭94noErrorDetected/clearFaultIFP(faultyId＝thisId)舊狀態(tài)SLEEPING/FAULTY新狀態(tài)SLEEPING該IFP的診斷部分報告故障已經(jīng)恢復。但是，在上行流中至少存在一個檢測到且未清除的故障。輸出信號ClearFaultIFP被送往下行流。
狀態(tài)FAULTY意味著該IFP的診斷部分60觀察到它所監(jiān)控的實體是故障的根源。診斷部分進入操作但是現(xiàn)在搜索“noError”，意味著故障恢復正在進行。當IFP從鏈中所有的上行流鏈路接收到notFaultyIFP消息時，進入所討論的狀態(tài)，它們與所討論的IFP處于“isConnectedbyInfluence”關系，下面將同樣做詳細描述。
-轉移15，箭頭96notFaultyIFP(reqId，expAckId)/coordinatIFP(faultyId＝thisId)舊狀態(tài)SLEEPING
新狀態(tài)FAULTY輸入信號表明在上行流分支中沒有檢測到箭頭。這肯定是“故障根源”IFP，即最上行流的IFP檢測到故障。
下行流IFP被輸出信號coordinatIFP協(xié)調。
-轉移16，箭頭98clea rFaultyIFP/-舊狀態(tài)FAULTY新狀態(tài)FAULTY這種情況從不會發(fā)生。忽略該輸入信號。
-轉移17，箭頭98notFaultyIFP(reqId，expAckId)/-舊狀態(tài)FAULTY新狀態(tài)FAULTY不考慮該輸入信號。
-轉移18，箭頭98localizeIFP(reqId)/coordinatIFP(faultyId＝thisId)舊狀態(tài)FAULTY新狀態(tài)FAULTY這個IFP已經(jīng)承擔了引起故障的責任。輸入信號coordinateIFP應送往下行流。
-轉移19，箭頭100clearFaultyIFP(recoveredId)/clearFaultyIFP(recoveredId)舊狀態(tài)SLEEPING/FAULTY新狀態(tài)FAULTY一個以前檢測到故障的IFP，即非這個IFP，檢測到因為某些原因故障已經(jīng)恢復，并通過輸入信號指示了這種情況。在這種情況下，假設被恢復的故障正是在影響鏈的上行流部分中檢測到的一個，即這是休眠請求IFP的列表中最后的Ifpid。
方法呼叫通過到下一個下行流IFP的輸出信號傳遞。
狀態(tài)SLEEPING/FAULTY意味著該IFP的診斷部分60找到了所監(jiān)控的一個實體是故障根源，但是該診斷部分由于另一個故障脫離了操作。這種情況在雙故障情況下可能出現(xiàn)。在該IFP觀察到它監(jiān)控的實體是故障根源后—第一個故障—收到coordinateIFP方法呼叫，表明一個新的故障—第二個故障—已經(jīng)在影響鏈中較早出現(xiàn)。根據(jù)首先消失的故障，當另一個故障消失時IFP再一次進入FAULTY狀態(tài)，或當?shù)谝粋€狀態(tài)消失時進入進入SLEEPING狀態(tài)。
-轉移20，箭頭102coordinatIFP(faultyId)/coordinatIFP(faultyId)舊狀態(tài)FAULTY新狀態(tài)SLEEPING/FAULTY通過輸入信號，收到方法呼叫coordinateIFP，即有一個上行流IFP檢測到一個故障。
-轉移21，箭頭104clearFaultyIFP(recoveredId)/clearFaultyIFP(recoveredId)舊狀態(tài)SLEEPING/FAULTY新狀態(tài)SLEEPING/FAULTY以前檢測到故障的IFP，即不是這個IFP，檢測到因為某些原因故障已經(jīng)恢復，并且在輸入信號中指示了這種情況。在這種情況下，假設這個恢復的故障不是影響鏈上行流分支中檢測到的唯一一個，即，這不是休眠請求IFP列表中最后一個Ifpid。
方法呼叫通過到下一個下行流IFP的輸出信號傳遞。
-轉移22，箭頭104localizeIFP(reqId)/-舊狀態(tài)SLEEPING/FAULTY新狀態(tài)SLEEPING/FAULTY這個IFP已經(jīng)被協(xié)調，且因此這個定位請求被忽略。
-轉移23，箭頭104coordinateIFP(faltyId)/coordinateIFP(faltyId)舊狀態(tài)SLEEPING/FAULTY新狀態(tài)SLEEPING/FAULTY接收到方法呼叫coordinateIFP，即有一個上行流IFP檢測到一個故障。如果這個檢測故障的IFP已經(jīng)被協(xié)調，就不考慮該協(xié)調，否則該標識被存入休眠請求IFP的列表中。
-轉移24，箭頭104
notFaultyIFP(“未預見(not expected)”)/-舊狀態(tài)SLEEPING/FAULTY新狀態(tài)SLEEPING/FAULTY忽略該輸入信號。
參考圖1以及上面參考圖5和6所做的描述，現(xiàn)在將描述故障監(jiān)控的一個簡單實用的實施例，例如，指向一個可替換單元。
針對一條ATM鏈路106上傳輸?shù)男旁男旁^中所出的故障對該鏈路進行監(jiān)控。這樣的故障可能是由于較差的傳輸質量、發(fā)送機故障、接收機故障或鏈路故障所引起的。因此可替換單元可能、但不一定形成了該鏈路的一部分。特別是，這里假設使用了所謂字頭錯誤校驗，HEC。這種類型的錯誤校驗在CCITT I.432建議草案“B-ISDN用戶網(wǎng)絡接口—物理層規(guī)定”中進行了描述。特別是HEC是一種CRC校驗(循環(huán)冗余校驗)，后者在“數(shù)據(jù)通信，計算機網(wǎng)絡和OSI”，F(xiàn)red Halsall，Addision-Wesly著，第98頁中有所描述。在圖1中方框108代表HEC校驗。
計算ATM信元的“字頭”校驗和并且將其結果與類似地包括在信元頭中的一個稱為HEC域的校驗和域相比較，在不同的情況下，即出錯情況下，故障信元數(shù)計數(shù)器步進一次。在本例中。這個計數(shù)器是mep54.1。
本地處理器4中的Mep52.1記錄了計數(shù)器54.1的計數(shù)值，這個值通過計數(shù)器值窗口110在52.1和54.1中表示。本地處理器4中的IFPdiagnoser60.1根據(jù)所謂“漏桶(leaky bucket)”算法分析計數(shù)器的值，該算法對于類似領域中的人是熟知的工具，目的是為了檢測每個時間單位是否丟失了太多的信元。所得的結果就是診斷，即errorDectected/noErrorDectected，參考圖5。
當發(fā)生了一個故障時，只要IFPpropHandler處于ACTIVE狀態(tài)，就通知中央處理器2中的IFPpropHandler 62.1(也參考圖5)。如果IFPpropHandler處于FAULTY狀態(tài)就只傳遞noErrorDectected消息。上述產(chǎn)生了CP2和DP4之間最少的信令，即只有狀態(tài)變化信號。
在圖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中，表示了包括多個互連的推理點IFP1-IFP9的一個影響圖的例子。參考圖7，可以注意到IFP1和IFP8是故障終結推理點，IFP2、IFP6和IFP9處于影響鏈的開始。從例子中也可以看到一個推理點可能連接幾個推理點，下行流和上行流均有。這里下行流意思是根據(jù)箭頭111的故障傳播流的方向。也可看到故障傳播流的方向與根據(jù)箭頭112的影響關系的方向相反。
故障定位基于一個故障是由檢測到故障的最上行流推理點所監(jiān)控的域中所引起的這個假設。下列策略用于定位這個第一上行流推理點。
假設一個推理點檢測到一個故障。在推理點能確定該故障是否確實處于所討論的推理點上之前，它必須相對故障可能從此傳播的流的方向，出去詢問它的鄰居。對故障根源的搜索一直繼續(xù)到到達滿足下列條件之一的一個推理點-所到達的推理點不被任何其它的影響點所影響，即故障不會傳播到這個推理點。推理點IFP2、IFP6和IFP9是這樣的，它們沒有在上行流連接到任何其它推理點。
-所到達的推理點同樣檢測到了一個故障。
在這種連接中，應該進一步強調的是一個流可能退化為一個單個的點，即開始和結束點是一個。只對一種現(xiàn)象或故障進行監(jiān)控。
參考圖9，以及上面就參考圖4所做的描述，推理點IFP8檢測到了一個故障。只要發(fā)生這種情況，它就向上行流推理點IFP7發(fā)送一個定位請求。這個請求具有方法呼叫l(wèi)ocalizeIFP的形式。這個方法呼叫具有標識定位請求的來源的標識參數(shù)。在所討論的情況下，該請求具有l(wèi)ocalizeIFP(8)的形式，參見圖中用同樣方法標識的箭頭，這里(8)表示作為請求起源的IFP8。請求的推理點IFP8進入休眠狀態(tài)，即它的診斷與推理部分脫離操作。
一個推理點只能有一個未應答的帶同樣標識的定位請求，即IFP7必須等到來自IFP4的確認之后才能繼續(xù)到下一分支，即IFP5的調查。發(fā)送的推理點IFP必須跟蹤未應答的方法呼叫l(wèi)ocalizeIFP。這通過儲存定位請求的標識和希望從中得到確認的上行流推理點的標識來執(zhí)行。
當定位請求已經(jīng)到達一個連接到影響鏈開始點的推理點IFP而這個推理點未檢測到任何故障時，就向下行流所有分支發(fā)送一個該請求的確認，圖10中做了圖示，其中當前推理點是IFP2。定位請求的確認具有方法呼叫notFaultyIFP的形式。
這個方法呼叫具有兩個參數(shù)，一個標識定位請求的來源，一個標識正發(fā)送的推理點。來自IFP2的確認具有notFaultyIFP(8，2)的形式，如圖10的圖中所示，分別標識推理點IFP8和推理點IFP2。其它確認，與定位請求一樣在圖10中的圖中出現(xiàn)。只有當方法呼叫notFaultyIFP是一個未應答的請求的確認時，推理點才接受它，即正發(fā)送的推理點的標識等于所期待的確認。
在一個推理點，例如圖10中的IFP7，被允許沿著影響圖傳遞方法呼叫notFaultyIFP之前，它必須滿足所有上行流分支的定位請求，在圖10中是兩個。一個推理點IFP直到觀察到所監(jiān)控的機制已經(jīng)找到或沒找到故障之后才可以發(fā)送任何方法呼叫notFaultyIFP。有這個限制，在一個影響圖的推理點之間就不必有時間的相關性，即一個故障下行流是否在該故障上行流被檢測到之前被發(fā)現(xiàn)是無關緊要的。
當?shù)竭_了負責未應答定位請求的推理點IFP8時，確認的傳遞就終止。
如果接收到方法呼叫l(wèi)ocalizeIFP的推理點IFP也檢測到一個故障時，只存儲請求推理點IFP的標識，即方法呼叫l(wèi)ocalizeIFP不向上行流傳遞。這種情況將通過后面更詳細描述的故障協(xié)調機制來處理。
當故障檢測推理點接收到每個未應答的方法呼叫l(wèi)ocalizeIFP上的方法呼叫notFaultyIFP時，該故障被認為是處于該推理點所分析的被觀察實體內。這樣的一個推理點現(xiàn)在改變了故障檢測機制的模式，特別是，現(xiàn)在檢測到故障的消失，如上面參考圖5和6所做的描述。在故障的兩級檢測和同樣故障消失的檢測之間一定會出現(xiàn)滯后現(xiàn)象。
當使用上面描述的故障策略時，搜索的次數(shù)隨著影響圖中分支數(shù)的增加快速地增長。如果經(jīng)常有這樣大的影響圖就會出現(xiàn)問題。
為了改進搜索算法以便找到最上行流故障檢測IFP而不必搜索得太多，根據(jù)第一修改并且參考圖11，引入了每個推理點本地的故障序列號。當通過推理點IFP4檢測到一個故障時，這個推理點通過故障序列號123繼續(xù)轉發(fā)，該序列號作為方法呼叫l(wèi)ocalizeIFP(4，123)中的一個參數(shù)，通過推理點IFP4發(fā)送。序列號123和請求推理點的標識4一起被沿著圖中的定位分支的IFP存儲。存儲的信息表示上行流分支已經(jīng)被調查并且確認可以立即發(fā)送到下行流。因此當?shù)诙ocalizeIFP請求經(jīng)由IFP2、IFP1被IFP1接收到時，可以理解這個故障已經(jīng)在上行流分支中定位，因為localizeIFP請求的標識等于變量lastFault的值。因此notFaultIFP可以立即發(fā)往下行流。
在改進搜索算法的另一個修改中，參考圖12，上行流分支的調查可以并行執(zhí)行而不是一次只調查一個。為了這個目的，通過請求傳遞的分支信息必須加入方法呼叫l(wèi)ocalizeIFP的參數(shù)列表中。這個參數(shù)可以作為一個“?！眮韺崿F(xiàn)，每個向其發(fā)送方法呼叫l(wèi)ocalizeIFP的推理點加入自己的標識。在圖12中，IFP6觀察到一個故障并向上行流發(fā)送了定位請求之后，在三個分支IFP6-IFP4-IFP2，IFP6-IFP5-IFP3和IFP6-IFP4-IFP3中順序加入相應的IFP標識，以便IFP1最終分別收到方法呼叫l(wèi)ocalizeIFP(2，4，6)、localizeIFP(3，5，6)和localizeIFP(3，4，6)。為了清楚起見，這些方法呼叫在圖12中縮寫為“l(fā)oc”。發(fā)送推理點IFP6必須跟蹤這些未應答的方法呼叫。這通過使用一個計數(shù)器并存儲該方法呼叫的標識來實現(xiàn)。在圖12中縮寫為“notF”的方法呼叫notFaultyIFP返回之前，確認“expAckID”必須在每個上行流分支上收到。標識參數(shù)，即棧，被方法呼叫notFaultyIFP返回。每次發(fā)送方法呼叫notFaultyIFP時，執(zhí)行一次棧的更新操作。通過在每個連續(xù)更新的棧中的第一個標識是返回的IFP的標識來實現(xiàn)的這種操作示于圖12，返回的IFP的標識通過去掉最新的前面返回的IFP的標識來得到。因此IFP6最后收到消息notFaultyIFP(5，6)和notFaultyIFP(4，6)。結果發(fā)現(xiàn)IFP6是負責這個故障域的IFP。
在搜索算法的第三個修改中，在推理點之間的故障影響關系可以模型化為用戶/提供者關系，也稱做“isDependentUpon(相互依賴)”，而不是“isConnectedByInfluence(通過影響而連接)”關系。這種關系意味著用戶的操作狀態(tài)完全依賴于提供者的操作狀態(tài)。在根據(jù)這種關系而彼此依賴的推理點的情況中，意味著一個推理點的故障狀態(tài)只是依賴于最近的上行流推理點的故障狀態(tài)。在定位故障根源時，在一個認為其本身與故障無關的推理點之后就不必用localizeIFP繼續(xù)下去?？梢钥隙ǖ氖巧闲辛鳑]有故障檢測推理點。
用關系“isDependentUpon”所做的模型將給出影響圖的另一種表現(xiàn)。以付出更多的分支為代價，關系時常會變得較淺一些。
以上所述在圖13和14中做了更詳細的說明。
假設有四個IFP，即IFP0、IFP1、IFP2和IFP3關于故障檢測行為具有下列關系。
如果IFP1檢測到一個故障，則IFP0也可以檢測到一個故障。
如果IFP2檢測到一個故障，則IFP0也可以檢測到一個故障。
如果IFP3檢測到一個故障，則IFP1也檢測到一個故障。
如果IFP3檢測到一個故障，則IFP2也檢測到一個故障。
圖13表示此時產(chǎn)生的isConnectedByInfluence關系模型情況下的圖，而圖14表示isDependentUpon關系模型情況下的圖。
這里將更詳細地描述故障協(xié)調策略。
故障協(xié)調是基于理解到所有處于故障責任推理點下行流的推理點IFP都與之無關，因為不會再檢測到新的故障且不會再有新的故障被這些推理點隔開。這些推理點可以處于SLEEPING狀態(tài)并使其故障檢測機制脫離操作。
一旦一個推理點觀察到一個檢測到的故障處于它的責任域中，它將向所有下行流推理點發(fā)送協(xié)調方法呼叫coordinateIFP。這個方法呼叫沿著影響圖傳遞直到找到一個故障終結推理點。已觀察到故障的測量點的標識跟在方法呼叫后面并被經(jīng)過的推理點存儲。
上面的描述在圖15中說明，這里推理點IFP4觀察到一個檢測到的故障處于它的責任域中，因此向下行流發(fā)送一個方法呼叫coordinateIFP(4)到推理點IFP7和IFP8，它們都處于SLEEPING狀態(tài)并且它們的故障檢測機制都設為脫離操作。
現(xiàn)在繼續(xù)描述故障恢復策略。
當一個故障自動或通過修復而復位時，推理點IFP-它所監(jiān)控的實體曾找到故障—將檢測到故障消失，因為一旦觀察到故障它的診斷部分就再次進入操作，具有檢測故障消失的任務，如上面參考圖5和6所做的描述。所有的下行流推理點將通過故障消除方法呼叫“clearFaultIFP”得到關于故障消失的通知。這個方法呼叫沿著影響圖傳遞直到找到一個故障終結推理點IFP。恢復的推理點IFP的標識跟在該方法呼叫后面。
當一個推理點收到方法呼叫clearFaultIFP時，它將再次開始監(jiān)控故障。當然所有使這個推理點指向狀態(tài)SLEEPING的推理點必須首先恢復。
在圖16中示意說明了這個描述，其中推理點IFP4向IFP7和IFP8發(fā)送方法呼叫clearFaultIFP(4)，它們再次開始監(jiān)控。
在圖17中根據(jù)圖8的影響圖被按照常規(guī)方法作為示例的對象關系模型而畫出。推理點對象之間的關系的方向應通過定義看作故障傳播方向的反方向。特別是這里存在connectedByInfluence關系的問題。
參考圖17，connectedByInfluence關系說明由于IFP7通過對IFP4的影響而連接這個事實，被IFP7檢測到的故障也可能已被IFP4和/或任何其它通過對IFP4的影響而連接的推理點檢測到，即此時的IFP3。
現(xiàn)在將在下面對故障功能對象FO的表示做詳細描述。
如前面所討論的，功能對象FO是在軟件中由一個或更多的系統(tǒng)實現(xiàn)的功能的代表。功能對象可以代表所有類型的抽象級別上的功能。
功能對象可以通過推理點IFP表示為故障。換句話說，推理點負責功能的監(jiān)控。
一旦一個推理點被定位為“故障”，就通知所監(jiān)控的功能并將其標為故障。在根據(jù)圖15的例子中，IFP4具有向所有它所監(jiān)控的功能對象FO發(fā)送故障指示消息的責任。
推理點IFP和功能對象FO之間的關系是一個多對多關系，即一個功能可以被很多推理點來監(jiān)控同時一個推理點可監(jiān)控很多功能。但是功能對象也可以作為推理點本身來實現(xiàn)。只有諸如coordinateIFP和clearFaultIFP這樣的方法呼叫在功能對象之間使用(故障已經(jīng)被定位)。
一旦故障的根源被定位，即一個推理點被標識為負責首先檢測到故障的域，推理點IFP負責指示出了故障的可替換單元。
推理點IFP和可替換RU之間的關系是多對多關系。推理點IFP監(jiān)控的域可以覆蓋多于一個的可替換單元RU。當考慮可替換單元之間的接口時常常出現(xiàn)這種情況。
在一個可替換單元RU被替換之前，依賴于該可替換單元的IFP必須被結束(closeIFP)以便防止不必要的警報。在替換之后，推理點再次進入操作(openIFP)。
為了使得同一次只有一個可替換單元RU指示故障，在推理點IFP中作為一個屬性引入一個概率函數(shù)。這個概率函數(shù)表示處于某個可替換單元RU中的故障的概率，參見圖18中的條狀圖，其中故障概率P以Y軸上0到1的坐標來表示。在三個可替換單元RU1、RU2、RU3中的故障概率以條狀圖的形式表示。
推理點IFP可以以概率函數(shù)為基礎，確定將要更換的單元，或者通過與故障指示方法呼叫一起傳遞概率值，將該判決傳遞到代表可替換單元的對象RUO。這兩種情況在圖19中分別作為情況A和B說明。
在情況A中，IFP確定RU1為故障，通過到RUO1的箭頭faultyRU來表示。在情況B中對相應對象RUO的判決被傳遞到RUO1-3，如箭頭suspectRU所示(分別為P1、P2和P3)。
考慮功能的故障行為分析的軟件模型部分負責有關功能實體的故障協(xié)調。
這個模型是相當簡單的，因為它只包括一種對象，即通過一個IFP監(jiān)控的功能對象FO，參見圖20。功能對象代表一種由電信設備實現(xiàn)的功能并且它們代表在所有抽象級上的功能。
故障對所監(jiān)控功能的影響的分析是相當簡單的。故障已經(jīng)被檢測、識別并且定位。行為分析在模型化階段實現(xiàn)。在實時中，該任務限于功能對象FO之間的純狀態(tài)傳播。
在模型化階段必須仔細分析功能之間的依賴性。如果一個功能的操作狀態(tài)依賴于其它功能，就必須作為功能對象之間的isDependentUpon關系反映在軟件模型中。
參考圖21，F(xiàn)O6被硬件監(jiān)控模型指示為故障。功能對象FO5和FO3依賴于FO6。因此這兩個對象將同樣被認為故障。狀態(tài)的傳播將繼續(xù)下去直到?jīng)]有更多的依賴性被找到。
依賴性存在于不同抽象級上的功能內部和功能之間。狀態(tài)傳播不限于一個單個電信設備中的對象。一個電信設備中的功能當然可以依賴于另一個這樣設備中的功能。
功能對象FO之間的接口以只使用coordinat和clearFault類型的方法呼叫這樣的方式來實現(xiàn)，因為故障已經(jīng)被定位了。
模型有關修復處理的部分被一個有利于故障硬件單元替換的功能使用。圖22示出了模型的對象關系表示。
當操作員請求一個修復測量時，這個請求被傳遞到代表可修復單元的對象RUO。所討論的請求可以用兩種方法之一來實現(xiàn)，即，通過操作員的操作臺以及到代表可替換單元RU的被控制對象的接口，或者通過按下裝在可替換單元上的一個按鈕。
對象RUO通知有關的必須停止檢測故障的推理點IFP。每個受到修復活動影響的推理點IFP請求功能對象FO停止當前對功能對象FO所代表的被監(jiān)控功能的使用。因此可替換單元RU被停止并可能被去掉。當安裝一個新的單元時，進入使用之前要對新單元進行啟動或接受測試。
假設由于硬件故障可替換單元RU必須被替換。監(jiān)控該可替換單元RU的所有推理點IFP都接到通知。在有關影響圖的下行流的所有推理點IFP同樣要接到通知。這就避免了替換硬件時不必要的警告。有關的對象通過狀態(tài)傳播通知。
狀態(tài)傳播一直執(zhí)行到到達一個推理點IFP，該點滿足下列可能性之一-推理點IFP是一個故障終結推理點，-已經(jīng)將修復活動通知該推理點IFP。
圖23是一個例子，其中RU1由于在推理點IFP4中定位到一個故障而被指示為故障。當需要一個修復測量時，代表RU1的對象立即通知負責監(jiān)控可替換單元的推理點IFP2到IFP8。這些推理點將完全脫離操作，即它們關掉自己的故障檢測機制，并將有關單元結束的消息通知給它們負責監(jiān)控的功能。
應該注意的是推理點IFP在轉換到脫離操作模式時，可以改變它的故障傳播行為。這是根據(jù)圖22的例子中IFP8的情況，參考圖8。從修復處理的觀點來看，這意味著影響圖可以做一些修改。
IFP8將單元的終結通知給負責監(jiān)控RU2的IFP9到IFPn。這些IFP將只關掉它們的故障檢測機制，而不通知有關的功能。
如前面所提到的，每個脫離操作的IFP負責將單元的終結通知給功能對象。功能對象將結束正在進行的對被監(jiān)控功能的使用。功能對象之間的狀態(tài)傳播用與上面描述的功能的故障協(xié)調情況完全相同的方式進行。
結束請求由方法呼叫closeIFP來實現(xiàn)，參見圖24。值得注意的是IFP8在進入透明狀態(tài)時改變?yōu)橐粋€“普通”IFP。IFP9由于收到帶一個與其本身RU關系不同的RU標識的方法呼叫closeIFP而進入SLEEPING狀態(tài)。
在一個單元脫離操作之前，單元自身執(zhí)行一次啟動或接受測試。啟動測試是一個內置的自檢功能，只在啟動時執(zhí)行一次。這個測試可以認為是一種純粹的硬件功能并且不包括在軟件模型內。但是，該測試可以被控制該單元的本地處理器控制并監(jiān)控。
在新單元進入操作之前必須無問題地通過自檢。
為了描述一個可替換單元如何進入操作，可以假設到本地處理器中負責硬件監(jiān)控的應用程序的控制連接已經(jīng)重新建立。
所有受這個修復活動影響的推理點IFP都得到有關新硬件單元RU安裝的通知。因此推理點將開始它們的監(jiān)控。間接連接到可替換單元RU的推理點，也用結束可替換單元時完全相同的方式，通過沿著影響圖的狀態(tài)傳播而被通知。有關開始的請求以方法呼叫openIFP的形式來進行。
一旦一個IFP開始它的監(jiān)控，就允許使用這個推理點監(jiān)控的功能對象FO。如果該功能被多個推理點所監(jiān)控，它們必須等到從所有推理點收到允許時才能使用。
權利要求
1.在電信系統(tǒng)中的一個故障監(jiān)控和管理系統(tǒng)，包括一個在電信系統(tǒng)的故障傳播方向上彼此互連的診斷與推理數(shù)據(jù)實體的鏈式系統(tǒng)，所述的數(shù)據(jù)實體在鏈式系統(tǒng)中的位置這樣確定，使它們能夠在相應的監(jiān)控域中每個監(jiān)控一個由電信系統(tǒng)中的故障所引起的現(xiàn)象，并在故障出現(xiàn)的情況下互相通信、彼此影響和相互作用，以便在電信系統(tǒng)中定位故障。
2.一個根據(jù)權利要求1的系統(tǒng)中，每個診斷與推理數(shù)據(jù)實體使用一個或多個測量點數(shù)據(jù)實體觀察診斷與推理數(shù)據(jù)實體所監(jiān)控的現(xiàn)象的出現(xiàn)、并向診斷與推理數(shù)據(jù)實體報告。
3.一個根據(jù)權利要求2的系統(tǒng)中，幾個測量點數(shù)據(jù)實體可以組成一個測量合成數(shù)據(jù)實體，收集并處理來自其所包含的測量點數(shù)據(jù)實體的數(shù)據(jù)。
4.一個根據(jù)權利要求1-3中任何一個的系統(tǒng)中，已經(jīng)在對應的鏈式系統(tǒng)中檢測到一個故障出現(xiàn)的診斷與推理數(shù)據(jù)實體，在確定故障是否出現(xiàn)于本身的監(jiān)控域之前，向所述的鏈式系統(tǒng)中從故障傳播方向看去處于這個故障檢測數(shù)據(jù)實體之前的診斷與推理數(shù)據(jù)實體發(fā)送一個故障定位請求，請求它們返回一個有關它們是否檢測到故障的確認消息。
5.一個根據(jù)權利要求4的系統(tǒng)中，在其它診斷與推理數(shù)據(jù)實體中的故障搜索一直繼續(xù)直到找到一個這樣的診斷與推理數(shù)據(jù)實體，它或是構成所討論的鏈式系統(tǒng)的開始，或是也檢測到一個故障。
6.一個根據(jù)權利要求4或5的系統(tǒng)中，如果當前的鏈式系統(tǒng)在故障檢測診斷與推理數(shù)據(jù)實體之前包括更多的并行分支，那么搜索一次在一個分支中進行。
7.一個根據(jù)權利要求4-6中任何一個的系統(tǒng)中，故障定位請求包括一個標識它的來源的標識參數(shù)。
8.一個根據(jù)權利要求4-7中任何一個的系統(tǒng)中，確認消息包括兩個標識參數(shù)，一個標識故障定位請求的來源，一個標識發(fā)送者。
9.一個根據(jù)權利要求4的系統(tǒng)中，每個診斷與推理數(shù)據(jù)實體具有一個有關的故障序列號，當有關的診斷與推理數(shù)據(jù)實體檢測到一個故障時該號遞增一次，所述的序列號作為故障定位請求的一個參數(shù)引入并且與沿著有關的鏈式系統(tǒng)的一個有關的故障定位請求診斷與推理數(shù)據(jù)實體的標識一起存儲起來，存儲的信息形成一個上行流分支已經(jīng)被調查且確認可以立即向下行流發(fā)發(fā)送的指示。
10.一個根據(jù)權利要求4的系統(tǒng)中，如果對于故障檢測診斷與推理數(shù)據(jù)實體，一個鏈式系統(tǒng)包括幾個并行的分支，那么搜索在上行流分支中并行完成，通過請求傳遞的有關分支的信息加入該故障定位請求的一個參數(shù)列表中。
11.一個根據(jù)權利要求10的系統(tǒng)中，參數(shù)作為一個棧來實現(xiàn)，每個發(fā)送定位請求的診斷與推理數(shù)據(jù)實體向其中添加自己的標識。
12.一個根據(jù)權利要求11的系統(tǒng)中，正發(fā)送的診斷與推理數(shù)據(jù)實體通過一個計數(shù)器以及存儲請求標識來跟蹤未應答的定位請求。
13.一個根據(jù)權利要求9-12中任何一個的系統(tǒng)中，在確認消息返回之前，必須已經(jīng)收到每個上行流分支中的確認消息。
14.一個根據(jù)權利要求9-13中任何一個的系統(tǒng)中，標識參數(shù)通過確認消息返回。
15.一個根據(jù)權利要求9-14中任何一個的系統(tǒng)中，每次發(fā)送確認時，在棧上執(zhí)行一次更新操作。
16.一個根據(jù)權利要求4-15中任何一個的系統(tǒng)中，一個診斷與推理數(shù)據(jù)實體，一旦已經(jīng)確認一個檢測到的故障在它的域中，就向故障傳播方向上處于下行流的所有診斷與推理數(shù)據(jù)實體發(fā)送一個協(xié)調方法呼叫，所述的方法呼叫一直傳遞到找到一個故障結束診斷與推理數(shù)據(jù)實體。
17.根據(jù)權利要求16的一個系統(tǒng)中，正發(fā)送的診斷與推理數(shù)據(jù)實體的標識跟在協(xié)調方法呼叫之后并被呼叫所經(jīng)過的診斷與推理數(shù)據(jù)實體儲存。
18.一個根據(jù)權利要求4-17中任何一個的系統(tǒng)中，當注意到一個故障時，故障的消失由最初檢測到故障的診斷與推理數(shù)據(jù)實體來檢測，所述數(shù)據(jù)實體向所有的下行流診斷與推理數(shù)據(jù)實體發(fā)送一個有關這個的方法呼叫，所述的方法呼叫一直傳遞到找到一個故障結束診斷與推理數(shù)據(jù)實體。
19.一個根據(jù)權利要求18的系統(tǒng)中，所討論的診斷與推理數(shù)據(jù)實體的標識跟在有關故障消失的消息之后。
20.一個根據(jù)權利要求19的系統(tǒng)中，在所有曾使一個診斷與推理數(shù)據(jù)實體脫離操作的診斷與推理數(shù)據(jù)實體得到恢復之后，當所討論的診斷與推理數(shù)據(jù)實體收到關于故障消失的消息時，這個數(shù)據(jù)實體再次開始監(jiān)控故障。
21.一種在電信系統(tǒng)中分布式故障處理的方法，包括如下步驟分析系統(tǒng)中的數(shù)據(jù)和信號流以便在故障出現(xiàn)時確定系統(tǒng)行為并因此而定位由故障引起的現(xiàn)象，通過在電信系統(tǒng)中故障傳播方向上彼此互連的診斷與推理數(shù)據(jù)實體組成的一個或多個鏈式系統(tǒng)來代表所述的行為，同時在相應的鏈式系統(tǒng)中確定數(shù)據(jù)實體的位置，使它們每個都能在相應的監(jiān)控域中監(jiān)控這樣的鏈式系統(tǒng)中出現(xiàn)的所述現(xiàn)象中的一種，并且在故障出現(xiàn)的情況下互相通信、彼此影響和相互作用，以便在電信系統(tǒng)中定位故障，提供一個或多個與每個診斷與推理數(shù)據(jù)實體有關的測量點數(shù)據(jù)實體，以便觀察有關的診斷與推理數(shù)據(jù)實體所監(jiān)控的現(xiàn)象的出現(xiàn)，并向診斷與推理數(shù)據(jù)實體報告。
22.一個根據(jù)權利要求21的系統(tǒng)，還包括將多個測量點數(shù)據(jù)實體與一個測量合成數(shù)據(jù)實體相關聯(lián)的步驟，以便收集并處理來自所述的測量點數(shù)據(jù)實體的數(shù)據(jù)。
23.一個根據(jù)權利要求21或22的方法，還包括通過已經(jīng)在對應的鏈式系統(tǒng)中檢測到一個故障的出現(xiàn)的診斷與推理數(shù)據(jù)實體，在確定故障是否出現(xiàn)于本身的監(jiān)控域之前，向所述的鏈式系統(tǒng)中從故障傳播方向看去處于這個故障檢測數(shù)據(jù)實體之前的診斷與推理數(shù)據(jù)實體發(fā)送一個故障定位請求，請求它們返回一個有關它們是否檢測到故障的確認消息的步驟。
24.一個根據(jù)權利要求23的方法，包括在其它診斷與推理數(shù)據(jù)實體中繼續(xù)搜索故障直到找到一個這樣的診斷與推理數(shù)據(jù)實體，它或是構成所討論的鏈式系統(tǒng)的開始，或是也檢測到一個故障。
25.一個根據(jù)權利要求23或24的方法，包括如果當前的鏈式系統(tǒng)在故障檢測診斷與推理數(shù)據(jù)實體之前包括更多的并行分支，那么搜索一次在一個分支中進行。
26.一個根據(jù)權利要求23-25中任何一個的方法中，故障定位請求包括一個標識它的來源的標識參數(shù)。
27.一個根據(jù)權利要求23-26中任何一個的方法中，確認消息包括兩個標識參數(shù)，一個標識故障定位請求的來源，一個標識發(fā)送者。
28.一個根據(jù)權利要求23的方法，包括將一個故障序列號關聯(lián)于每個診斷與推理的步驟，當有關的診斷與推理數(shù)據(jù)實體檢測到一個故障時將上述的號碼遞增一次，在故障定位請求中上述的序列號作為一個參數(shù)引入，并且與沿著有關的鏈式系統(tǒng)的一個有關的故障定位請求診斷與推理數(shù)據(jù)實體的標識一起存儲起來，存儲的信息形成一個上行流分支已經(jīng)被調查且確認可以立即向下行流發(fā)發(fā)送的指示。
29.一個根據(jù)權利要求23的方法，包括如下步驟的執(zhí)行，對于故障檢測診斷與推理數(shù)據(jù)實體，如果一個鏈式系統(tǒng)包括幾個并行的分支，那么搜索在上行流分支中并行進行，通過請求傳遞的有關分支的信息加入該故障定位請求的一個參數(shù)列表中。
30.一個根據(jù)權利要求29的方法，包括將參數(shù)作為一個棧來實現(xiàn)，并且每個發(fā)送定位請求的診斷與推理數(shù)據(jù)實體向上述的棧中添加自己的標識。
31.一個根據(jù)權利要求30的方法中，正發(fā)送的診斷與推理數(shù)據(jù)實體通過一個計數(shù)器以及存儲請求的標識來跟蹤未應答的定位請求。
32.一個根據(jù)權利要求28-31中任何一個的方法，包括從鏈式系統(tǒng)的每個上行流分支中收到確認消息以后才能返回一個確認消息。
33.一個根據(jù)權利要求28-32中任何一個的方法中包括，標識參數(shù)通過確認消息返回。
34.一個根據(jù)權利要求30-33中任何一個的方法中，每次發(fā)送確認時，在棧上執(zhí)行一次更新操作。
35.一個根據(jù)權利要求23-34中任何一個的方法中，包括如下步驟一個診斷與推理數(shù)據(jù)實體，一旦已經(jīng)確立一個檢測到的故障在它的域中，就向故障傳播方向上處于下行流的所有診斷與推理數(shù)據(jù)實體發(fā)送一個協(xié)調方法呼叫，所述的方法呼叫一直傳遞直到找到一個產(chǎn)生故障的診斷與推理數(shù)據(jù)實體。
36.一個根據(jù)權利要求35的方法中包括，正發(fā)送的診斷與推理數(shù)據(jù)實體的標識跟在協(xié)調方法呼叫之后并被呼叫所經(jīng)過的診斷與推理數(shù)據(jù)實體儲存。
37.一個根據(jù)權利要求23-36中任何一個的方法中包括，當注意到一個故障時，故障的消失由最初檢測到故障的診斷與推理數(shù)據(jù)實體來檢測，同一個診斷與推理數(shù)據(jù)實體向所有的下行流診斷與推理數(shù)據(jù)實體發(fā)送一個有關這個的方法呼叫直到找到一個故障結束診斷與推理數(shù)據(jù)實體。
38.一個根據(jù)權利要求37的方法中包括，所討論的診斷與推理數(shù)據(jù)實體的標識在有關故障消失的消息之后發(fā)送。
39.一個根據(jù)權利要求38的方法中包括，在所有曾使一個診斷與推理數(shù)據(jù)實體脫離操作的診斷與推理數(shù)據(jù)實體得到恢復之后，這個收到關于故障消失的消息的診斷與推理數(shù)據(jù)實體，再次開始監(jiān)控故障。
全文摘要
一個電信系統(tǒng)中的故障監(jiān)控和管理系統(tǒng)包括一個在該電信系統(tǒng)的故障傳播方向上彼此相連的診斷與推理對象(IFP)的鏈式系統(tǒng)。確定這些對象在鏈式系統(tǒng)中的位置，使之能夠在各自的臨控域中監(jiān)控一種可能由該電信系統(tǒng)中的故障所引起的現(xiàn)象，并在故障發(fā)生時能夠互相通信、彼此影響和相互作用，以便定位電信系統(tǒng)中的故障。每個診斷與推理對象使用一個或多個測量點對象(MEP)，觀察診斷與推理對象所監(jiān)控的現(xiàn)象的出現(xiàn)，并向診斷與推理對象(IFP)報告。更多的測量點對象(MEP)可以組成一個測量合成對象(MEC)，收集并處理來自它所包含的測量點對象的數(shù)據(jù)。
文檔編號H04L12/56GK1145708SQ9519249
公開日1997年3月19日 申請日期1995年4月4日 優(yōu)先權日1994年4月8日
發(fā)明者I·哈比, A·西蒙斯, S·瓦爾曼, R·吉斯康比, M·倫納森, P·E·施特羅米 申請人:艾利森電話股份有限公司