SE502852C2 - Sätt och system för distribuerad övervakning av hårdvara - Google Patents

Description

502 852 2 undvika nackdelar med utnyttjande av en omfattande "master transmission control unit".

Redogörelse för uppfinningen Ett allmänt syfte med uppfinningen är att ange en modell och på denna modell applicerade metoder för konstruktion och imple- mentering av felhantering i telekommunikationssystem med komplex hård- och mjukvara.

Närmare bestämt skall modellen tjäna som en representation i mjukvara av felbeteendet hos telekommunikationsutrustningar.

Genom observation av övervakade entiteter och genom användning av kännedom om entiteternas beteende, skall modellen kunna detektera, identifiera och lokalisera fel i olika abstraktions- nivåer och vyer, och kunna användas för koordinering av alarm från olika feldetekteringsentiteter. Det är önskvärt att model- len även skall kunna användas vid återställning (automatiskt eller manuellt) av en felaktig enhet.

Ovanstående har enligt uppfinningen uppnåtts genom att systemet och sättet enligt uppfinningen erhållit de i krav 1 resp. 20 angivna kännetecknen.

Föredragna utföringsformer av uppfinningen har därvid er- hållit de i respektive underkrav angivna kännetecknen.

Uttryckt på annat sätt, skapas enligt uppfinningen en modell för sättets genomförande, som innehåller delmodeller av beteen- det hos egentliga hård- och mjukvaruentiteter, liksom av be- teendet hos de mer abstrakta entiteter, som kan vara implemente- rade i ett telekommunikationssystem. Som exempel kan nämnas logiska funktioner representerande en viss implementering i hård- och mjukvara. Modellen innehåller även delmodeller av vad som fortsättningsvis kommer att benämnas utbytesenheter och därmed relaterade entiteter. Med utbytesenhet menas här närmare bestämt den minsta hårdvarudel som kan ersättas, normalt ett enkelt kort eller en enkel kabel. Denna del av modellen används för aktiviteter som syftar till åtgärdande av fel, en verksamhet som fortsättningsvis kommer att benämnas reparationshantering.

Behovet av kommunikation mellan modeller som representerar olika telekommunikationssystem är inbyggt i modellen.

De i sättet enligt uppfinningen ingående delmetoderna för felövervakning bygger på en distribuerad inställning till pro- 502 852 3 blemet. Med denna inställning blir ett centraliserat analyseran- de mjukvarublock enligt teknikens ståndpunkt onödigt.

Olika objekt i den använda modellen har strängt specificerade och väldefinierade uppgifter, såsom observation av en övervakad entitet, symptomgenerering, dvs sammanställning och bearbetning av av observationer, diagnostisering/analysering av observerad entitet eller entiteter och slutligen tillståndspropagering mellan olika analyserande entiteter. Detta gör det lätt att bygga välstrukturerade modeller av det övervakade systemet.

En grafisk notation, som representerar de övervakade entitet- ernas beteenden, avseende propageringen av hur ett fel yttrar sig, ingår i uppfinningen. En ändring av hård- och mjukvaru- implementeringen kommer att medföra ändringar i grafer som representerar hård- och mjukvaran. Detta innebär att ändringar kan utföras på ett ganska enkelt och strukturerat sätt.

Den distribuerade ansatsen tillsammans med den grafiska notationen gör det lättare att förstå hur olika fel influerar varandra och hur ett särskilt fel manifesteras.

Uppfinningens metoder, dvs koncepten och den grafiska nota- tionen, kan även användas vid konstruktion av hård- och mjukva- ra. Detta hjälper hård- och mjukvarukonstruktören att erhålla god kännedom om feltätheten och -utbredningen i aktuell hård- och mjukvarukonstruktion, liksom möjlig felupptäckningsgrad, samt optimera utpekning av felaktiga utbytesenheter. Vidare är det mycket enkelt att generera och implementera mjukvarumodellen från dokumentationen av hård- och mjukvarukonstruktionen.

Den observerande och symptomgenererande delen av modellen enligt uppfinningen kan återanvändas för prestandaberäknings- funktioner i ett telekommunikationssystem.

Hård- och mjukvaruövervakningsmodellen kan användas rekur- sivt, d.v.s. den för hård- och mjukvaruövervakningen använda mekanismen övervakas likaledes av modellen. Som exempel används övervakningen av hård- och mjukvaran för att utföra observatio- nerna i hård- och mjukvaruövervakningen.

Modellen kan generaliseras till att gälla alla typer av hård- och mjukvarusystem.

Figurbeskrivning Uppfinningen skall nu beskrivas närmare nedan med hänvisning 502 852 4 till bifogade ritningar, på vilka fig. 1 schematiskt i blockschemaform visar ett databehand- lingssystem, varvid även en i detta ingående utföringsform av uppfinningen åskådliggörs, fig. 2 schematiskt åskådliggör en mjukvarumodell för fel- hantering, fig. 3 visar en modell av objektentitetsrelationer vid fel- hantering och reparationshantering av en apparat, fig. 4 är ett inflytandediagram, som åskådliggör principerna för fellokalisering, fig. 5 schematiskt åskådliggör uppbyggnaden av ett diagnos- och beslutpunktsobjekt med tillhörande mottagna och avsända metodanrop, samt inre och yttre gränssnitt, fig. 6 visar en tillståndsgraf, som åskådliggör olika möjliga tillstånd och tillståndsövergångar hos objektet enligt fig. 5, fig. 7 anger betydelsen av vissa grafiska symboler i in- flytandegrafer, som visas i följande figurer, fig. 8 ger exempel på en sådan inflytandegraf, fig. 9 visar exempel på en inflytandegraf vid fellokalise- ring, fig. 10 visar en graf som åskådliggör kvitteringsåtgärder vid exemplet enligt fig. 9, fig. 11 är en graf, som åskådliggör en första förbättring av sökalgoritmen vid fellokalisering, fig. 12 är en graf, som åskådliggör en andra förbättring av sökalgoritmen vid fellokalisering, fig. 13 och 14 schematiskt åskådliggör inverkan av modelle- ring med två olika typer av relationer på inflytandegrafernas utseende, fig. 15 visar en inflytandegraf avsedd att beskriva felkoor- dinering, fig. 16 visar en inflytandegraf, som åskådliggör felåter- ställning, fig. 17 visar en objektrelationsmodell av inflytandegrafen enligt fig. 8, fig. 18 visar ett exempel på en sannolikhetsfunktion, fig. 19 åskådliggör två fall av felhantering av felaktiga utbytesenheter med användning av en sannolikhetsfunktion enligt fig. 18, 502 852 5 fig. 20 visar en funktionsanalyserande del av en modell för felhanteringsanalys av funktioner, fig. 21 åskådliggör tillståndspropagering mellan funktionso- bjekt, fig. 22 åskådliggör uppbyggnaden av en reparationshanterings- modell, fig. 23 visar exempel på en inflytandegraf, som kan uppträda vid reparationshantering, fig. 24 åskådliggör ett exempel på terminering av utbytesen- heter, fig. 25-27 är tabeller, som visar tillståndsövergångar i varsitt gränssnitt ingående i fig. 5.

Föredragna utfögingsformgr De utföringsexempel av uppfinningen, som kommer att beskrivas nedan, bygger för enkelhetens skull på förutsättningen att man har att göra med ett objektorienterat distribuerat datasystem.

Mera generellt är emellertid uppfinningen ej begränsad till denna typ av system, utan kan även tillämpas på andra typer av system, som är uppbyggda på utnyttjande av dataentiteter av annan karaktär än objekt.

För nedan och på ritningarna förekommande uttryck i samband med beskrivning av signaler innehållande meddelanden och meto- danrop, liksom av deltagande aktörer, används konventionella namngivningsregler vid strukturerad programmering, av det slag, som finns beskrivna exempelvis i boken "C++ Primer" av Stanley B. Lippman, 2nd Edition, Addison-Wesley Publishing Company. En närmare beskrivning av de ifrågavarande uttrycken och deras betydelse ges nedan med hänvisning till fig. 5.

De nedan beskrivna utföringsexemplen av uppfinningen är vidare för enkelhetens skull huvudsakligen riktade på övervak- ning av hårdvara. Uppfinningen är emellertid tillämpbar även på mjukvaruövervakning, såsom särskilt kommer att beskrivas nedan i några fall.

Fig. 1 visar schematiskt, och som exempel, en del av ett databehandlingssystem såsom innefattande en central processor CP, betecknad med 2, och därmed sammankopplade lokala processo- rer DP, betecknade med 4 resp. 6. Felhanteringsmodellens enligt 502 852 6 uppfinningen tillämpning på ett sådant system kommer att be- skrivas närmare nedan.

Felhanteringsmodellen enligt uppfinningen består av i princip tre, ganska oberoende delmodeller. Denna uppdelning av modellen reflekterar de huvuduppgifter, som felhanteringen tar hand om, nämligen: - Övervakning av hårdvara, såsom i processorerna 2, 4 och 6.

Denna del används vid detektering av ett fel, identifiering av typen av fel och lokalisering av varifrån felet härrör i hårdva- ran, varvid en eller flera felaktiga enheter, utbytesenheter och/eller funktionsenheter, kan indikeras såsom felaktiga. Denna del av modellen benämns även nedan "hårdvaruövervakningsmodell".

Utbytesenheter, av vilka två visas vid 8 resp. 10 i fig. 1, och antas ingå i processorerna 4 resp. 6, avses i förliggande sam- manhang vara den minsta del hårdvara, som kan ersättas, normalt ett enda kort eller en enda kabel.

- Felkoordinering av funktioner eller analys av funktioner med avseende på felbeteendet. Denna aktivitet startas när ett fel har detekterats och en eller flera funktioner har angetts som felaktiga. Analysen av påverkan av ett fel på funktionerna görs av och mellan funktionerna själva. Denna del av modellen benämns även nedan "felhanteringsmodell på funktionsnivå".

- Reparationshantering. Denna aktivitet startas när en utbytesenhet har angetts som felaktig av hårdvaruövervakningen.

Denna del av modellen benämns även nedan "reparationshanterings- modell".

Denna delning av modellen kan även mappas på olika abstrak- tionsnivåer enligt fig. 2, där hårdvaruövervakningsdelen be- tecknas med 12, felhanteringsdelen FH på funktionsnivå med 14, samt reparationshanteringsdelen RH med 16. Den senare visas såsom innefattande en delmodell 17 av en hårdvaruenhet. De ifrå- gavarande nivåerna anges i figuren såsom exempelvis innefattande en "låg"-nivå 18 för hårdvaruberoende funktioner, och en "hög"- nivå 22 för abstrakta logiska funktioner.

Närmare bestämt är övervakningen av hårdvaran, antydd med pilar 24, 26, 28, naturligtvis beroende av hårdvaruimplemente- ringen. Denna del av modellen återfinns i nivå 18, och kan del- vis implementeras i de lokala processorerna 4 och 6. Den del som 502 852 7 svarar för analysen av felinverkan av funktionerna återfinns på båda abstraktionsnivåerna 18 och 22. Varje system, eller delsys- tem, måste bygga sin egen modell av de två delarna 12 och 14 av modellen.

Den sista delen 16, reparationshanteringsmodellen, skapas av nedan närmare omtalade objekt, som representerar utbytesenhe- terna, såsom 8 och 10. Reparationshanteringsdelen 16 påverkar även entiteter i de andra två delarna av modellen. Reparations- hanteringsmodellen kan vara gemensam för fler system eller delsystem, då systemen kan implementeras på en och samma ut- bytesenhet.

I figur 2 antyds vidare ett hårdvarugränssnitt vid 30 och en fysisk motsvarighet till hårdvarumodellen 17 med ett streckat block 32. Vid 34 och 38 antyds vidare funktionsmodeller.

Om den observerade mätpunkten alternativt skulle befinna sig i programvaran, t.ex. vara en felräknare i programvara, bort- faller i fig. 2 delarna 16 och 17, delen 12 ersätts med en mjukvaruövervakningsdel, och hårdvarugränssnittet 30 ersätts med ett mjukvarugränssnitt.

Såsom likaledes kommer att framgå närmare nedan kan modeller, som representerar olika system eller delsystem, kommunicera med varandra genom att propagera tillstånd mellan objekt i de olika modellerna. Det föreligger ingen skillnad mellan att kommunicera mellan olika modeller eller inom en modell.

Fig. 3 visar en objektrelationsmodell av felhanteringen och reparationshanteringen för en anordning. Modellen innehåller ett antal diagnos- och beslutspunktobjekt. Av dessa visas i fig. 3 ett vid 40. Förkortat kommer dessa objekt nedan att identifie- ras som beslutspunkter, eller IFP (för Inference Point). En sådan beslutspunkt IFP svarar för övervakningen av en speci- ficerad del av ett data eller ett signalflöde.

I fig. 3 övervakar, antytt med pil 42, vidare beslutspunkten IFP 40 ett objekt 44, fortsättningsvis även benämnt RUO (för Replaceable Unit Object), som representerar en utbytesenhet 46, fortsättningsvis även benämnd RU (för Replaceable Unit), visad med streckade linjer. Vidare övervakar, antytt med pil 48, beslutspunkten IFP 40 ett funktionsobjekt 50, fortsättningsvis även benämnt FO (för Function Object). Med funktionsobjekt FO avses här en mjukvarurepresentation av en funktion, som är 502 852 8 implementerad av ett eller flera system.

Beslutspunkten IFP 40 utnyttjar, antytt med pil 51, för sin funktion ett antal mätpunktobjekt, fortsättningsvis även benämn- da MEP (för Measurement Point), av vilka, i fig. 3, ett visas vid 52, och, i fig. 1, tre visas med streckade linjer vid 52.1, 52.2, resp. 52.3. i lokalprocessorerna 4 och 6. Varje sådant objekt MEP motsvaras av en fysisk entitet 54, fortsättningsvis även benämnd mep, varvid tre av dessa visas i fig. 1 vid 54.1, 54.2 resp 54.3 i RU 8 och RU 10.

Fortsättningsvis kan mätpunktobjekten MEP komma att i korthet benämnas mätpunkt MEP. I föreliggande sammanhang avses med en sådan mätpunkt en representation av en fiktiv punkt, där obser- vationen av den observerade entiteten sker. Denna mätpunkt MEP innefattar även den för observationen använda metoden.

Ett MEP interagerar med hårdvaran för att observera möjliga statusändringar. Metoderna för detektering av hårdvarufel är i en del fall mycket beroende av hårdvarans implementering. På grund av den intima relationen till hårdvaran är MEP ofta, men ej nödvändigtvis alltid, distribuerad till aktuell lokalproces- sor, såsom nyss beskrivits med hänvisning till fig. 1.

Före publicering av en observation, kan en hel del databe- handling av den observerade entiteten mep ha skett. Det i en mätpunkt MEP publicerade mätresultatet kan utgöras av ett räk- narvärde, ett databehandlat räknarvärde, eller någon annan hårdvaru- eller mjukvarusignal. Emellertid varken analyserar mätpunkten MEP eller drar några slutsatser om den observerade entiteten mep.

Om så är nödvändigt kan mätpunkten MEP även justeras av mjukvaran. Ett exempel är sättande av ett tröskelvärde för en använd metod.

Om så är lämpligt kan observationer från olika mätpunkter MEP kombineras till ett mätvärdessammanställande objekt 55, fort- sättningsvis även benämnt MEC (för Measurement Combinatory object), som likaledes utnyttjas av beslutspunkten IFP 40. I fig. 1 visas ett MEC vid 55.1 i lokalprocessorn 6. Utgången från ett mätvärdessammanställande objekt MEC kan ses som symptom på observerade entiteter i hårdvaran. I likhet med mätpunkten analyserar aldrig ett mätvärdessammanställande objekt MEC några data. Det mätvärdessammanställande objektet MEC kan emellertid 502 852 9 sätta samman och behandla data från sina tillhörande mätpunkter MEP. Denna behandling sker oftast i mjukvara. Den "förfinade observationen", symptomet, kvarstår för ytterligare analys.

Det mätvärdessammanställande objektet MEC kan helt eller delvis implementeras i mjukvara för en lokal processor, såsom 4 och 6 i fig. 1, under antagande av att de använda observationer- na är tillgängliga i rätt processor, dvs. den använda mätpunkten MEP måste befinna sig i samma processor, som det mätvärdessam- manställande objektet MEC.

Baserat på observationer från MEP:er och/eller MEC, ställer en IFP diagnos beträffande en viss hårdvara genom att analysera observationerna och avgöra om ett fel detekterats.

Förutom för analys av felsymptom svarar IFP:erna även för fellokalisering. Det är viktigt att kunna lokalisera den verkliga orsaken till felet så att man kan peka ut rätt utbytes- enhet. Eftersom ett hårdvarufel kan detekteras av flera IFP:er, måste det finnas en metod för att avgöra vilken IFP som detek- terat felets ursprung.

Ett större hårdvarufel påverkar ett antal olika IFP:er. En felaktig systemklocka, t.ex., kan innebära att IFP:er, som övervakar ett cellflöde i en paketväljare, detekterar fel. För att kunna lokalisera felets ursprung måste IFP:erna vara medvet- na om varandra. De måste vara ömsesidigt anordnade i en särskild ordning på så sätt att det framgår vilken IFP som kan influeras av en annan IFP.

Fellokaliseringen kan ske genom att placera alla IFP:er, som kan influera varandra, i en inflytandekedja. En IFP, som kan influera alla de andra, placeras så att den blir belägen mest uppströms, varefter de andra IFP:erna placeras efter inflytande- ordning. Den mest nedströms belägna IFP:n kan inte influera någon annan.

Principerna för fellokalisering åskådliggörs av det i fig. 4 visade inflytandediagrammet. I diagrammet är IFPI och IFP5 de enligt ovanstående redogörelse mest uppströms resp. nedströms belägna IFP:erna, medan IFP2 och IFP4 är belägna däremellan i inflytandeordning. I fig. 4 numreras de respektive stegen i fellokaliseringen med 1-7.

Baserat på observation, steg 1, från MEP 52 ställer IFP4 diagnos beträffande en viss hårdvara 54 genom att analysera 502 852 10 observationen och avgör att ett fel detekterats. IFP4 riktar därför, steg 2, en begäran om fellokalisering, 'Localize fault', till närmast uppströms belägna IFP, nämligen IFP2. Fellokalise- ringsbegäran vidareleds till den mest uppströms IFP:n, dvs.

IFP1, steg 3. IFPI och IFP2 svarar på lokaliseringsbegäran, stegen 4 och 5, varvid svaret i detta fall är 'Not Faulty', dvs. "ej felaktig". När IFP4 mottager detta svar från de uppströms belägna IFP:na, är lokaliseringsproceduren över och ursprunget för felet har påträffats, nämligen den av IFP4 själv övervakade hårdvaran.

För att undvika onödig felpropagering när ursprunget för felet påträffats, sänder den IFP, som detekterat felet såsom hörande till dess egen övervakningsdomän, dvs. IFP4, en instruk- tion, genom 'Coordinate' i steg 6, till nedströms belägna IFP:er, i detta fall IFP5, att inta vilotillstånd.

Det bör tilläggas att det ovan beskrivna fellokaliseringsför- loppet är mycket förenklat. Inflytandekedjor kan vara invecklade och bilda mycket komplexa nätverk, såsom kommer att framgå nedan längre fram.

Fellokaliseringen och felkoordineringen är mycket beroende på hårdvarans beteende ur felpropageringssynpunkt. I det följande kommer detta att beskrivas närmare.

Innan en mjukvarumodell av hårdvarans beteende, sett ur felpropageringssynpunkt, kan byggas, måste flödet av data och signaler i hårdvaran analyseras och förstås klart. Av dessa flöden skapas delmodeller och de övervakas av hårdvaruövervak- ningsdelen av modellen.

Såsom framgått av beskrivningen nyss med hänvisning till fig. 4 representeras data- eller signalflödets beteende av en kedja av sammankopplade beslutspunkter IFP. Dessa kopplingar bestäms av flödets beteende med avseende på propagering av felets mani- festation, och används vid lokalisering av en feldetekterande beslutspunkt IFP. Beslutspunkter IFP i samma kedja måste ha felinverkan på varandra. Skälet till att sätta en beslutspunkt IFP i en viss inflytandekedja är att om denna insatta besluts- punkt detekterar ett fel, kan någon tidigare belägen besluts- punkt i kedjan detektera samma fel. Beslutspunkterna IFP i en kedja mäter emellertid inte samma sak, men de kan detektera samma verkliga hårdvarufel. Om ett fel uppträder i hårdvaran kan 502 852 ll detta sålunda detekteras av flera beslutspunkter IFP, och alla dessa beslutspunkter måste befinna sig i samma inflytandekedja. Även om beslutspunkterna IFP i en kedja är i stånd att detektera samma hårdvarufel, behöver alla beslutspunkter i själva verket ej detektera felet, eftersom beslutspunkterna söker felet från olika synpunkter, då de som nämnts ej mäter samma sak.

En beslutspunkt IFP där felyttringar termineras, såsom IFP4 i fig. 4, benämns felterminerande beslutspunkt. En felyttring kan ej propageras bortom en sådan punkt, och inflytandekedjan är sålunda slut.

För bättre förståelse av nedanstående beskrivning av in- flytandekedjor och deras funktion med hänvisning till fig. 7 och följande figurer, skall nu, med hänvisning till fig. 5 och 6 först uppbyggnaden av en beslutspunkt IFP, dess olika tillstånd, samt de metodanrop den sänder och mottager beskrivas närmare.

En beslutspunkt IFP innehåller en diagnosdel 60, 'IFPdiagno- ser', nedan och på ritníngarna även förkortat 'IFPdiag', avsedd för analysering och diagnostisering av observationer och symptom beträffande en observerad entitet. I fallet felhantering sker analysering och diagnostisering med avseende på fel, dvs. be- slutspunkten IFP svarar för detektering och identifiering av fel i hårdvaran. Det är beslutspunktens IFP sak att avgöra om den har detekterat ett fel eller inte. En beslutspunkt IFP är till- delad uppgiften att detektera och identifiera en enda typ av fel.

När en beslutspunkt IFP har detekterat och identifierat ett fel återstår fortfarande uppgiften att lokalisera ursprunget för felet till rätt beslutspunkt. Det är inte helt säkert att felet härrör från den beslutspunkt IFP där ett fel har detekterats.

Manifestationen av felet kan ha förorsakats av något annat fel någon annanstans. Rätt lokalisering av felet är mycket viktig när en utbytesenhet RU och de ifrågavarande funktionerna skall identifieras som felaktiga.

När ursprunget för felet har lokaliserats till en särskild beslutspunkt IFP, måste felet koordineras med andra feldetekte- rande beslutspunkter IFP, för att undvika onödig tillståndspro- pagering mellan beslutspunkter. i Beslutspunkten IFP har en interagerande och tillståndspropa- 502 852 12 gerande del 62, 'IFPpropHandler', nedan och på ritningarna även förkortat 'IFPprop', som medger att beslutspunkter kan interage- ra med varandra förutsatt att de fel, som de kan identifiera, beror av varandra. Detta är nödvändigt när den feldetekterande beslutspunkten, som svarar för den domän där felet uppstått, skall lokaliseras, dvs. man måste kunna utpeka rätt utbytesen- het.

Den interagerande och tillståndspropagerande delen 62 tas i drift eller ur drift genom instruktionerna openIFP resp. clo- seIFP enligt pil 64, från reparationshanteringsmodelldelen RH, jfr fig. 2, via ett nedan närmare beskrivet gränssnitt IFPcon- troll.

Analys- och diagnostiseringsdelen 60 av en beslutspunkt kan helt eller delvis implementeras i mjukvara hos en lokal processor, såsom processorerna 4 och 6 i fig. 1, under förut- sättning att de använda observationerna och symptomen finns tillgängliga i rätt processor. Den interagerande, tillstånds- propagerande delen 62 av objektet implementeras emellertid alltid i ett överordnat datorsystem, såsom centralprocessorn 2 i fig. 1. Det sagda illustreras även i fig. 1 där analys- och diagnostiseringsdelar IFPdiag 60.1 och 60.2 av vardera en be- slutspunkt är belägna i lokalprocessorerna 4 resp. 6, och mot- svarande tillståndspropagerande delar IFPprop 62.1 resp. 62.2 är belägna i centralprocessorn 2. Det framgår där även att IFPdiag 60.1 utnyttjar MEP 52.1, och att IFPdiag 60.2 utnyttjar MEC 55.1, som utnyttjar de båda MEP 52.2 och 52.3.

I riktning från den interagerande, tillståndspropagerande delen 62 mot den diagnostiserande delen enligt pil 66 avges in- struktioner för att göra en diagnos, starta kontinuerlig diag- nostisering, samt stoppa en pågående diagnostisering genom metodanropen dobiagnose, startDiagnose resp. stopDiagnose. I motsatt riktning enligt pil 68 avges informationsmeddelanden avseende om fel detekterats eller ej, genom errorDetected resp. noErrorDetected. Kommunikationen mellan IFPpropHandler 62 och IFPdiagnoser 60 sker via ett nedan närmare beskrivet gränssnitt DII. I fig. 5 visas även gränssnitt IFPtoIFP, via vilka kommuni- kationen med andra IFP:er äger rum, samt gränssnitt MEI mellan IFPdiagnoser 60 å ena sidan och MEP och MEC å andra sidan, samt mellan MEC och MEP. De i fig. 5 ingående gränssnitten skall nu 502 852 13 beskrivas närmare.

Gränssnittet IFPcontrolI innehåller metoderna openIFP(ruID), som startar IFP:n, closeIFP(ruID), som terminerar IFP:n, samt en metod verifyIFP(), som verifierar IFP:n genom att initiera en dobiagnose-sekvens, varvid möjliga returvärden är verify0K, verifyNot0K, verifyRejected.

Gränssnittet IFPtoIFP tillhandahåller metoder för hantering av Fault Localization, Fault Coordination och Fault Recovery mellan IFP:er och är av typen Client/Server metod/metod-gräns- snitt.

Gränssnittet består således av metoder för fellokalisering och felkoordinering, samt metoder för felåterhämtning.

Metoderna för fellokalisering och koordinering är loca1izeIFP(IFPid), coordinateIFP(faultID), notFaultyIFP(reqIFPid,sending IFPid), Metoderna för felåterhämtning är clearFaultIFP(faultID), Client-IFP:n sänder metodanropet Localize till Server-IFP:n, som har relationen connectedßylnfluence till Client-IFP:n. Ser- ver-IFP:n som mottar metodanropet är inbegripen i 'Lokalize'- aktiviteten. Denna IFP kommer att sända kvittering av denna 'Localize' till Client-IFP:n, när lokaliseringsslingan i en upp- ströms belägen gren terminerats. Om ingen IFP, som indikerat ett fel, påträffats sänds notFaultyIFP till Client-IFP:n, annars sänds metodanropet Coordinate.

Ett utbyte av metodanrop kan påbörjas av Server-IFP:n genom att den sänder metodanropet Coordinate. Detta metodanrop talar om att en IFP, som indikerat ett fel, påträffats och bör koordi- neras med andra påverkade IFP:er. Denna koordinering möjliggörs med hjälp av IFPid-parametern i metodanropet som identifierar den IFP, som indikerat fel.

Felåterhämtning baserar sig på utbyte av metodanropet clear- Fault.

Utbytet av metodanrop kan påbörjas av Server-IFP:n genom att den sänder anropet clearFault när denna IFP är i full drift efter att ha påverkats av ett fel (automatisk återhämtning). 502 852 14 Gränssnittet har inga tillstånd utan endast förvillkor P. Ett inkommande metodanrop kommer att få till följd ett utgående metodanrop enligt vissa förvillkor P: P1: Server-IFP:n har mottagit ett metodanrop notFaultyIFP från alla sina uppströms grann-IFP:er.

P2: Server-IFP:n har mottagit ett metodanrop noErrorDetected efter en begäran doIFPdiagnose.

P3: Server-IFP:n har mottagit ett 'Coordinate'- metodanrop från en av sina uppströms grann-IFP:er.

P4: Server-IFP:n har mottagit ett metodanrop errorüetected från IFP-diagnoser.

P5: Server-IFP:n har mottagit ett metodanrop noErrorDetected, som ej mottages som kvittering av doIFPdiagnose, utan anger att ett felaktigt tillstånd har upphört att föreligga.

Figur 25 visar en tabell över övergångar vid IFPtoIFP-gräns- snittet, i vilken ovanstående förvillkor ingår.

Gränssnittet DII mellan IFPpropHandler och IFPdiagnoser har till ändamål att ange metoder för att påbörja och slutföra begäranden om diagnos till IFPdiagnoser. Det är ett metod/- metod-gränssnitt av typen Client/Server och består av metoder för aktivering och de-aktivering av diagnosoperationen och begäran vid anfordran om en diagnoscykel.

Metoderna för begäran om en diagnosoperation är belägna i IFPdiagnoser och är: - startIFPdiagnose(IFPid,diagnoseType), Metoden startIFPdiagnose beordrar IFPdiagnoser att påbörja diagnos av hårdvara och mjukvara som övervakas. 'diagnoseType' kan vara antingen 'lookingForError' eller 'lookingForRecovery'. - stopIFPdiagnose(IFPid) Metoden stopIFPdiagnose beordrar IFPdiagnoser att stoppa sin diagnostiseringsaktivitet.

- DoIFPdiagnose(IFPid) Metoden doIFPdiagnose beordrar IFPdiagnoser att utföra en diagnos. IFPdiagnoser kommer alltid att svara även om inget fel påträffats.

I ovannämnda metodanrop är 'IFPid' identiteten hos IFPpro- pagationHandler som sänder anropet.

Metoder för att svara på diagnosoperationer är belägna i 502 852 15 IFPpropHandler, och är följande - errorbetected Metoden errorDetected informerar IFPpropHandler om att ett fel påträffats.

- NoErrorDetected Informerar IFPpropHandler om att inget fel påträffats.

Vidare är nedanstående andra metoder belägna i IFPpropHandler - Diagnoser0K Informerar IFPpropHandler om att länken till lokalprocessorn är i drift.

- DiagnoserNot0K Informerar IFPpropHandler att länken till lokalprocessorn är ur drift.

Beträffande dynamiskt beteende gäller följande: Metodanropgränssnittet för begäran om utförande av diagnos baserar sig på metodanroputväxlingen startIFPdiagnose(IFPid,- diagnoseType), stopIFPdiagnose(IFPid), doIFPdiagnose(IFPid). I metoden anropa startIFPdiagnose(IFPid,diagnoseType), anger parametern diagnoseType om servern bör söka efter fel eller efter felåterhämtning. Om Servern har mottagit ett startIFP- diagnose kommer den att svara med errorbetected om ett fel uppträder. Om metodanropet startIFPdiagnose anger sökning efter återhämtning, kommer diagnosenheten att svara med noErrorDetec- ted när felet återhämtats.

Metodanropet stopIFPdiagnose erhåller inget svar från Ser- vern.

Metoden anropa doIFPdiagnose beordrar Servern att utföra en diagnosprovcykel, varvid svaret från Servern blir errorbetected eller noErrorDetected.

Servern kan använda metodanropet diagnoserNotOK t.ex. för att informera Klienten om att länken till lokalprocessorn är ur drift. När länken är i drift igen sänder Servern diagnoserOK.

I fig. 26 visas alla möjliga tillståndsövergångar för DII- gränssnittet, varvid förvillkoret är att ett feltillstånd detek- terats. Dessa tillståndsövergångar framgår även av tillstånds- grafen i fig. 6 och tillhörande beskrivning nedan.

Gränssnittet MEI mellan IFPdiagnoser och MEP samt mellan IFPdiagnoser och MEC/MEP tillhandahåller metoder för att erhålla mätprover från MEP eller MEC object. Dessa prover kan användas 502 852 16 för drifthantering eller felhantering.

Gränssnittet består av metoder för att utvinna mätprover för utförande av diagnos. Följande metoder används av Klienten: - startMeasurement(receiverID,measurementspecification,- IDofCalling0bject), - stopMeasurement(IDofCalling0bject) Metoden startMeasurement i Servern används för att till- handahålla ett antal rapporter för ett objekt, som framställer en begäran därom, varvid varje rapport innehåller en lista av prover. Metoden startMeasurement används av olika objekt (IFP- :er) för att utvinna prover beträffande den för mätning utsatta entiteten. När Servern mottager metodanropet startMeasurement påbörjar den insamling av prover från det övervakade objektet.

Dessa prover sänds därpå till Servern med metodanropet retrievedsamples.

Mer än en begäran kan behandlas parallellt.

Följande parametrar används av metoden startMeasurement: - MEPid: MEP:s identitet. Denna identitet måste vara unik. - measurementspecifikation: Detta är uppgifter, som anges för varje typ av MEP. T.ex. om det rör sig om händelse- eller tids- triggade MEP:er.

- IDofCallingObject: denna parameter är identiteten hos det objekt som startar en mätning.

Metoden stopMeasurement i Serverobjektet kommer att användas för att stoppa alla mätningar som begärts av ett objekt till Servern. Alla aktiva mätningar för det anropande objektet kommer att omedelbart stoppas utan rapport. Denna metod accepterar följande parametrar: - IDofCallingObject: se ovan, Följande metoder används av Servern - retrievedsamples(list0fSamples,IDofCallingObject) - DP_linkError() - DP_linkErrorCeased() Metoden retrievedsamples tillhandahålls av Klienten och används för att kunna sända tillbaka de begärda proverna till Klienten. Denna metod accepterar följande parametrar: - list0fSamples: en länkad lista med de prover Servern beordrades sända.

- IDofCallingObject: se ovan 502 852 17 Med metodanropen DP_linkError och DP_1inkErrorCeased kan Servern informera Klienten om status hos lokalprocessorlänken.

När metodanropet DP_linkError sänds innebär detta att MEI- gränssnittet ej längre existerar. När metodanropet DP_linkEr- rorCeased sänds innebär detta att gränssnittet har återskapats.

I tabellen i fig. 27 anges alla möjliga tillståndsövergångar för MEI-gränssnittet.

Den interagerande och tillståndspropagerande delen 62 av IFP kan anta ett antal tillstånd, antytt vid 70 i fig. 5, som be- stäms av vad som inträffar i de nedan närmare beskrivna kedjorna av IFP. De ifrågavarande tillstånden, liksom Övergångarna mellan dessa, skall nu beskrivas närmare med hänvisning även till den i fig. 6 visade tillståndsgrafen, samt fortsatt hänvisning till fig. 5 och beskrivningen av dess gränssnitt. I fig. 6, används följande akronymer: ed errorbetected ned noErrorDetected loc loca1izeIFP notf notFaultyIFP coord coordínateIFP clrf clearFault Med hänvisning till grafen i fig. 6 utgörs nämnda tillstånd av INAKTIVT, AKTIVT, VILANDE, FELAKTIGT resp. VILANDE/FELAKTIGT tillstånd, i fig. 6 benämnda CLOSED, ACTIVE, SLEEPING, FAULTY respektive SLEEPING/FAULTY. Mellan dessa tillstånd uppträder genom pilar åskådliggjorda övergångar. De metodanrop, som leder till de olika, nedan närmare behandlade övergångarna, anges med användning av de ifrågavarande akronymerna som insignal till egen IFP/utsignal till nästa IFP I INAKTIVT eller "transparent" tillstånd är IFP transparent kedjorna av IFP:er. Det transparenta tillståndet framkallas antingen genom det ovannämnda metodanropet closeIFP, eller av ett feltillstånd i observatíonsmekanismen, såsom t.ex. på grund av ett avbrott i länken mellan processorerna 2 och 4 i fig. 1, vilket skulle leda till transparent tillstånd hos IFP:n 62.1.

Det transparenta tillståndet innebär att metodanrop locali- zeIFP, enligt pil 72, samt coordínateIFP, notFaultyIFP och ClearFaultIFP, enligt pil 74, endast vidareleds till nästa IFP i kedjan. Diagnosdelen 60 tas även ur drift. Betydelsen av dessa 5Û2 852 18 metodanrop kommer att framgå närmare längre fram. Det inaktiva tillståndet är det ursprungstillstånd, i vilket IFP har inträtt före start av systemet och när en reparationsaktivitet har påbörjats. Tillståndet INAKTIVT lagrar även en lista över iden- titeter på utbytesenheter, då en IFP:s drifttillstånd kan vara beroende av flera utbytesenheter. - Övergång 1, pil 80: c1oseIFP(ruID)/closeIFP(ruID) Gammalt tillstånd: INAKTIVT, AKTIVT, VILANDE, FELAKTIGT och VILANDE/FELAKTIGT.

Nytt tillstånd: INAKTIVT En reparationsaktivitet har påbörjats och IFP:n sätts till det transparenta tillståndet. Den nedströms IFP:n informeras genom utsignalen closeIFP(ruID), där ruID står för identiteten hos utbytesenheten (replaceable unit identity) och används för att kunna hantera ersättning av flera utbytesenheter samtidigt.

I AKTIVT tillstånd, som är det "normala" tillståndet för en IFP, arbetar diagnosdelen 60 och söker fel. Diagnosdelen startas genom ovannämnda instruktion eller metod startbiagnose. - Övergång 2, pil 82: openIFP(ruID)/openIFP(ruID) Gammalt tillstånd: INAKTIVT Nytt tillstånd: AKTIVT IFP:n aktiveras, t.ex. efter en reparation eller vid system- start. En nedströms IFP informeras genom utsignalen openIFP(ruID). Observera att tillståndsövergången kräver att alla utbytesenheter, som IFP:n är beroende av tagits i drift, dvs. openIFP har mottagits från samtliga utbytesenheter i lis- tan. - Övergång 3, pil 84: noErrorDetected/- Gammalt tillstånd: AKTIVT Nytt tillstånd: AKTIVT Diagnosdelen 60 hos IFP:n har rapporterat att inget fel detekterats. - Övergång 4, pil 84: localizeIFP(reqId)/localizeIFP(reqId) Gammalt tillstånd: AKTIVT Nytt tillstånd: AKTIVT 502 852 19 Insignalen localizeIFP har mottagits från en nedströms IFP, metodanropet leds vidare till den uppströms IFP:n. Identiteten hos den anropande IFP:n sparas, genom reqId, tillsammans med identiteten hos den uppströms gren där metodanropet localize vidareleddes. _ - Övergång 5, pil 84: notFaultyIFP(reqId,sendingId)/notFau1tyIFP(reqId,sendingId) Gammalt tillstånd: AKTIVT.

Nytt tillstånd: AKTIVT Inga feldetekterande IFP:n påträffades i den uppströms grenen. Insignalen notFaulty vidareleds till den nedströms IFP:n.

Det bör observeras att innan metodanropet notFaultyIFP kan vidareledas måste en diagnos beordras, dvs. doDiagnose. För att kunna hantera detta måste ett undertillstånd införas. I det i tillståndsgrafen visade förenklade framställandet antas det emellertid att IFP:n redan känner till resultatet av en sådan diagnosoperation, dvs. inget fel har detekterats. - Övergång 6, pil 86: clearFaultIFP(recoveredId)/clearFaultIFP(recoveredïd) Gammalt tillstånd: VILANDE Nytt tillstånd: AKTIVT En tidigare feldetekterande IFP, dvs. ej denna IFP, har detekterat att felet försvunnit av något skäl, och anger detta i insignalen. I detta fall antar vi att det återhämtade felet var det enda som detekterats i inflytandekedjans uppströms del, dvs. detta var den sista IfpId i listan av vilobegärande IFP:n.

Listan av vilobegärande IFP:er förklaras närmare i beskrivningen av tillståndet VILANDE nedan.

Metodanropet vidareleds genom utsignalen till nästa nedströms IFP. - Övergång 7, pil 88: noErrorDetected/clearFaultIFP(recoveredId=thisId) Gammalt tillstånd: FELAKTIGT Nytt tillstånd: AKTIVT Denna IFP har detekterat att det tidigare av denna IFP detekterade felet har försvunnit. Metodanropet clearFaultIFP sänds nedströms till nästa IFP. A I VILANDE tillstånd är diagnosdelen 60 hos IFP avaktiverad. 502 852 20 Detta tillstånd kan intas på två sätt: - diagnosdelen har detekterat ett fel, en lokaliseringsmeka- nism har startat, som åstadkommer att metodanropet localizeIFP skickas uppströms i kedjan av IFP, - metodanropet coordinateIFP har mottagits, vilket innebär att det finns ett fel uppströms i kedjan av IFP:er, och leder till att den berörda IFP:n övergår till vilande tillstånd.

I det vilande tillståndet lagras en lista av identiteter över de uppströms IFP:er, som inträtt i tillståndet FELAKTIGT. Samt- liga i listan inskrivna IFP:er har ju beordrat denna IFP att övergå till tillståndet VILANDE. - Övergång 8, pil 90: errorßetected/localizeIFP(regId=thisId) Gammalt tillstånd: AKTIVT Nytt tillstånd: AKTIVT Diagnosdelen har detekterat ett fel, lokaliseringsmekanismen startas, ett metodanrop localizeIFP sänds uppströms. - Övergång 9, pil 90: coordinateIFP(fau1tyId)/coordinateIFP(faultyId) Gammalt tillstånd: AKTIVT Nytt tillstånd: VILANDE Insignalen coordinateIFP har mottagits, dvs. det finns en uppströms IFP som detekterat ett fel. - Övergång 10, pil 92: clearFaultIFP(recoveredId)/clearFau1tIFP(recoveredId) Gammalt tillstånd: VILANDE ' Nytt tillstånd: VILANDE En tidigare feldetekterande IFP har detekterat att ett fel återhämtats, och meddelar detta genom metodanropet clearFault, som vidareleds nedströms. I detta fall antar vi att detta åter- hämtade fel ej var det enda som detekterats i inflytandekedjans uppströms del, dvs. detta var ej den sista IfpId i listan av vilobegärande IFP:n.

Metodanropet vidareleds genom utsignalen till nästa nedströms IFP. - Övergång 11, pil 92: localizeIFP(reqId)/- Gammalt tillstånd: VILANDE Nytt tillstånd: VILANDE 502 852 _ 21 Denna IFP har redan koordinerats, varför detta localize- metodanrop kan negligeras. - Övergång 12, pil 92: coordinateIFP(fau1tyId)/coordinateIFP(fau1tyId) Gammalt tillstånd: VILANDE Nytt tillstånd: VILANDE En insignal coordinateIFP har mottagits, dvs. det finns en uppströms IFP som detekterat ett fel. Om denna feldetekterande IFP redan har blivit koordinerad, kan koordineringen negligeras, annars sparas identiteten i listan av vilobegärande IFP:n. - Övergång 13, pil 92: notFaultyIFP("not expected")/- Gammalt tillstånd: VILANDE Nytt tillstånd: VILANDE Bortse från denna insignal. - Övergång 14, pil 94: noErrorDetected/clearFaultIFP(fau1tyId=thisId) Gammalt tillstånd: VILANDE/FELAKTIGT Nytt tillstånd: VILANDE Diagnosdelen hos IFP:n har rapporterat att felet återhämtats.

Det finns emellertid åtminstone ett detekterat och ouppklarat fel i den uppströms grenen. Utsignalen ClearFaultIFP sänds nedströms.

Tillståndet FELAKTIGT innebär att diagnosdelen 60 hos IFP:n har konstaterat att den entitet den är satt att övervaka är felorsakande. Diagnosdelen tas i drift men letar nu efter "noEr- ror" dvs. inget fel, vilket innebär att felåterhämtning pågår.

Tillståndet ifråga intas när IFP har mottagit meddelandet not- FaultyIFP från alla uppströms i kedjan belägna länkar, vilka står i "isConnectedbyInfluence" -förhållande till ifrågavarande IFP, vilket likaledes kommer att beskrivas närmare nedan. - Övergång 15, pil 96: notFaultyIFP(reqId,expAckId)/coordinateIFP(faultyId=thisId) Gammalt tillstånd: VILANDE Nytt tillstånd: FELAKTIGT Insignalen anger att inget fel har detekterats i den upp- ströms grenen. Detta måste vara den "felorsakande" IFP:n, dvs. den mest uppströms IFP:n har detekterat felet. A De nedströms IFP:na koordineras via utsignalen coordinateIFP. 502 852 22 - Övergång 16, pil 98: clearFau1tIFP/- Gammalt tillstånd: FELAKTIGT Nytt tillstånd: FELAKTIGT Detta skall aldrig inträffa. Negligera insignalen. - Övergång 17, pil 98: notFaultyIFP(reqId,expAckId)/- Gammalt tillstånd: FELAKTIGT Nytt tillstånd: FELAKTIGT Bortse från insignalen. - Övergång 18, pil 98: localizeIFP(reqId)/coordinateIFP(faultyId=thisId) Gammalt tillstånd: FELAKTIGT Nytt tillstånd: FELAKTIGT Denna IFP har redan tagit ansvaret för att vara felorsakande.

Utsignalen coordinateIFP skall sändas nedströms. - Övergång 19, pil 100: clearFau1tIFP(recoveredId)/clearFaultIFP(recoveredId) Gammalt tillstånd: VILANDE/FELAKTIGT Nytt tillstånd: FELAKTIGT En tidigare feldetekterande IFP, dvs. ej denna, har detekte- rat att felet återhämtat sig av någon anledning, och anger detta genom insignalen. I detta fall antar vi att det återhämtade felet var det enda som detekterades i den uppströms grenen av inflytandekedjan, dvs. det var den sista IfpId i listan av vilo- begärande IFP:n.

Metodanropet vidareleds genom utsignalen till nästa nedströms IFP.

Tillståndet VILANDE/FELAKTIGT innebär att diagnosdelen 60 hos IFP:n har funnit att en entitet den är satt att övervaka är felorsakande, men diagnosdelen har tagits ur drift på grund av ett annat fel. Denna situation kan uppträda vid en dubbelfelssi- tuation. Efter att IFP:n har konstaterat att dess övervakade entitet är felorsakande - det första felet - mottages metodan- ropet coordinateIFP, som anger att ett nytt fel - det andra felet - har uppträtt tidigare i inflytandekedjan. Beroende på vilket fel som försvinner först övergår IFP återigen till till- ståndet FELAKTIGT när det andra felet har försvunnit, eller till tillståndet VILANDE när det första felet försvunnit. 502 852 23 - Övergång 20, pil 102: coordinateIFP(faultyId)/coordinateIFP(fau1tyId) Gammalt tillstånd: Axl-IVT Nytt tillstånd: VILANDE/FELAKTIGT Genom insignalen mottages metodanropet coordinateIFP, dvs. det finns en uppströms IFP som detekterat ett fel. - Övergång 21, pil 104: clearFaultIFP(recoveredId)/c1earFaultIFP(recoveredïd) Gammalt tillstånd: VILANDE Nytt tillstånd: vILANoE/FELAKTIGT En tidigare feldetekterande IFP, dvs. ej denna, har detekte- rat att felet återhämtats av någon anledning, och anger detta i insignalen. I detta fall antar vi att det återhämtade felet ej var det enda som detekterades i inflytandekedjans uppströms gren, dvs. detta var ej den sista IfpId i listan av vilobegäran- de IFP:n.

Metodanropet vidareleds genom utsignalen till nästa nedströms IFP. - övergång 22, pil 104: 1ocalizeIFP(reqId)/- Gammalt tillstånd: VILANDE Nytt tillstànd: vILANDE/FELAKTIG Denna IFP har redan koordinerats, varför man kan bortse från denna lokaliseringsbegäran. - Övergång 23, pil 104: coordinateIFP(faultyId)/coordinateIFP(faultyId) Gammalt tillstånd: VILANDE Nytt tillstånd: vILANDE/FELAKTIGT Ett metodanrop coordinateIFP mottages, dvs. det finns en uppströms IFP som detekterat ett fel. Om denna feldetekterande IFP redan har koordinerats, kan man bortse från koordineringen, annars sparas identiteten i listan av vilobegärande IFP:er. - Övergång 24, pil 104: notFaultyIFP("not expected")/- Gammalt tillstånd: VILANDE Nytt tillstånd: VILANDE/FELAKTIGT Negligera insignalen.

Här skall nu, med hänvisning till fig. 1 och till vad som beskrivits ovan med hänvisning till fig. 5 och 6, ett enkelt 502 852 24 praktiskt utföringsexempel av felövervakning, t.ex. för utpek- ning av en felaktig utbytesenhet, beskrivas.

En ATM-länk 106 övervakas med avseende på fel i cellhuvudet hos celler överförda på länken. Sådana fel kan bero på dålig överföringskvalitet, fel på sändaren, mottagaren eller länken.

Utbytesenheten kan således, men behöver inte, utgöras av en del av länken. Närmare bestämt antas här s.k. Header Error Check, HEC, komma till användning. Denna typ av felkontroll finns beskriven i CCITT Draft Recommendation I.432, "B-ISDN User Network Interface - Physical Layer Specification". Närmare bestämt är HEC en typ av CRC (Cyclic Redundancy Check), som finns beskriven i "Data Communications, Computer Networks and OSI" av Fred Halsall, Addison-Wesly, p. 98. I fig. 1 represente- rar ett block 108 HEC-kontrollen. ' ATM-cellernas "Header" checksum-beräknas och resultatet jäm- föres med ett i cellhuvudet likaledes ingående fält av checksum- mor, ett s.k. HEC-fält. Vid olikhet, dvs. vid fel, stegas en räknare av antalet felaktiga celler upp. I det föreliggande exemplet är denna räknaren mep 54.1.

Mepzn 52.1 i lokalprocessorn 4 registrerar räknarens 54.1 räknevärde, det senare representerat i både 52.1 och 54.1 med ett räknevärdesfönster 110. IFPdiagnoser 60.1 i lokalprocessorn 4 analyserar räknarvärdena i enlighet med en s.k "leaky bucket" - algoritm, som är ett för fackmannen välkänt verktyg i liknande sammanhang, och som har till uppgift att detektera om för många celler har förlorats per tidsenhet. Resultatet som erhålls är diagnosen, dvs. errorbetected/noErrorDetected, jfr fig. 5.

När ett fel inträffar informeras IFPpropHandler 62.1 i centralprocessorn 2 (jfr även fig. 5) om detta, förutsatt att IFPpropHandler är i tillståndet AKTIV. Är IFPpropHandler i tillståndet FELAKTIGT vidareledes endast noErrorDetected-med- delanden. Ovanstående medför en minimal signalering mellan CP 2 och DP 4, dvs. endast signaler vid tillståndsförändringar.

I fig. 7a-d visas grafiska tecken som används i de följande figurerna 8-12, 15, 16 samt 23, 24 för beskrivning av kedjor av beslutspunkter. Närmare bestämt visas i fig. 7, vid a) symbolen för en beslutspunkt IFP, vid b) symbolen för en felterminerande beslutspunkt, vid c) symbolen för en inflytandelänk, samt vid d) symbolen för början av en inflytandekedja. I det mycket schema- 502 852 _ 25 tiska exemplet i fig. 1 antas IFP 60.1/62.1 ligga i början av en inflytandekedja, hos vilken IFP 60.2/62.2 bildar felterminerande IFP.

I figurerna 9-12, 15, 16 samt 23, 24 anges även under de respektive kedjorna riktning och namn för nedan behandlade signaler och kvitteringar genom pilar med tillhörande meddelan- detext.

I fig. 8 visas ett exempel på en inflytandegraf, som innehål- ler ett antal sammankopplade beslutspunkter IFP1-IFP9. Med hän- visning till fig. 7 kan det noteras att IFP1 och IFP8 är felter- minerande beslutspunkter, och att IFP2, IFP6 och IFP9 ligger i början av en inflytandekedja. Av exemplet framgår även att en beslutspunkt kan vara kopplad till flera beslutspunkter, både i nedströms och uppströms riktning. Med nedströms riktning avses riktningen för felpropageringsflödet enligt pil 111. Det framgår även att riktningen för felpropageringsflödet är den motsatta mot riktningen för inflytanderelationerna enligt pil 112.

Fellokaliseringen grundar sig på antagandet att ett fel har sin orsak i den domän, som övervakas av den mest uppströms beslutspunkten, som detekterat felet. Följande strategi används för lokalisering av denna första uppströms beslutspunkt.

Antag att ett fel har detekterats av en beslutspunkt. Innan beslutspunkten kan avgöra om felet verkligen är beläget vid den ifrångavarande beslutspunkten eller inte, måste den gå ut och fråga sina grannar, motsatt flödesriktningen 110, varifrån felet kan ha propagerats. Sökandet efter felets ursprung fortsätter tills en beslutspunkt nås, i vilken ett av följande villkor har uppfyllts: - Den uppnådda beslutspunkten.är inte influerad av någon annan beslutspunkt, dvs. ett fel kan ej ha propagerats till denna beslutspunkt. Detta stämmer in på beslutspunkterna IFP2, IFP6 och IFP9, som ej är anslutna uppströms till någon annan beslutspunkt.

- Den nådda beslutspunkten har likaledes detekterat ett fel.

Det bör vidare i sammanhanget framhållas att ett flöde kan degenerera till en enda punkt, dvs. start- och termineringspunkt är densamma. Övervakningen sker av endast en typ av fenomen, eller fel. A Med hänvisning till fig. 9, samt vad som beskrivits ovan med 502 852 26 hänvisning till fig. 4, har beslutspunkten IFP8 detekterat ett fel. Så snart detta skett sänder den en lokaliseringsbegäran till en uppströms belägen beslutspunkt IFP7. Denna begäran har formen av metodanropet localizeIFP. Detta metodanrop har en identitetsparameter, som identifierar ursprunget för lokali- seringsbegäran. I det aktuella fallet får då begäran formen 1ocalizeIFP (8), jfr den på samma sätt identifierade pilen i figuren, där (8) identifierar IFP8 som ursprung för begäran. Den begärande beslutspunkten IFP8 intar det vilande tillståndet, dvs. dess analyserande och diagnostiserande del tas ur drift.

En beslutspunkt kan endast ha en utestående lokaliseringsbe- gäran med samma identitet, dvs. IFP7 måste vänta på kvittering från IFP4 innan den fortsätter undersökningen av nästa gren, dvs. IFP5. Den sändande beslutspunkten IFP måste spåra det utestående metodanropet localizeIFP. Detta sker genom att spara lokaliseringsbegärans identitet och identiteten hos en uppströms belägen beslutspunkt, från vilken en kvittering kan väntas.

När lokaliseringsbegäran har nått en beslutspunkt IFP an- sluten till en startpunkt för inflytandekedjan, och denna be- slutspunkt ej har detekterat något fel, skickas en kvittering av begäran nedströms till alla grenar, vilket åskådliggörs i fig. 10 där den aktuella beslutspunkten är IFP2. Kvitteringen av en lokaliseringsbegäran har formen av metodanropet notFaultyIFP.

Detta metodanrop har två parametrar, en som identifierar ursprunget för lokaliseringsbegäran och en som identifierar den sändande beslutspunkten. Kvitteringen från IFP2 får då formen notFaultyIFP (8,2) såsom framgår av diagrammet i fig. 10, iden- tifierande beslutspunkten IFP8 resp. beslutspunkten IFP2. Ut- seendet hos övriga kvitteringar, liksom lokaliseringsbegäran framgår likaledes av diagrammet i fig. 10. En beslutspunkt accepterar endast ett metodanrop notFaultyIFP om det är en kvittering av en utestående begäran, dvs. den sändande besluts- punktens identitet är lika med identiteten hos den väntade kvitteringen.

Innan en beslutspunkt, såsom IFP7 i fig. 10, tillåts vida- releda ett metodanrop notFaultyIFP utefter inflytandegrafen, måste den ha fullföljt lokaliseringsbegäran hos alla uppströms belägna grenar, vilka i fig. 10 är två. En beslutspunkt IFP tillåts vidare inte sända något metodanrop notFaultyIFP förrän 502 852 27 den har fastställt om den övervakade mekanismen befinns felaktig eller inte. Med denna begränsning finns det inget behov av tidskorrelation mellan beslutspunkterna i en inflytandegraf, dvs. det har ingen betydelse om ett fel nedströms upptäcks innan orsaken till felet uppströms detekteras.

När den för den utestående lokaliseringsbegäran svarande beslutspunkten IFP8 har nåtts, stoppas vidareledningen av kvit- teringen.

Om beslutspunkten IFP som mottog ett metodanrop localizeIFP, även har detekterat ett fel, sker ingenting annat än att identi- teten hos den begärande beslutspunkten IFP sparas, dvs. metodan- rop localizeIFP vidareleds ej uppströms. Detta fall kommer att hanteras av den sedan närmare beskrivna felkoordineringsmekanis- men.

När en feldetekterande beslutspunkt har mottagit ett metodanrop notFaultyIFP på varje utestående metodanrop loca- lizeIFP kan felet anses vara beläget i den observerade entite- ten, som analyseras av beslutspunkten. En sådan beslutspunkt ändrar nu mode hos feldetekteringsmekanismen och detekterar nu närmare bestämt felets försvinnande, såsom beskrivits ovan med hänvisning till fig. 5 och 6. Det måste föreligga en hysteres mellan de två nivåernas detektering av ett fel och detektering av samma fels försvinnande.

Vid användning av den ovan beskrivna fellokaliseringsstrate- gin kan antalet sökningar öka mycket snabbt med antalet grenar i inflytandegrafen. Detta kan utgöra ett problem om sådana stora inflytandegrafer kommer att bli vanliga.

För förbättring av sökalgoritmen för att finna den mest uppströms feldetekterande IFP:n utan att behöva leta så mycket, kan med hänvisning till fig. 11 enligt en första modifikation ett för varje beslutspunkt lokalt felsekvensnummer introduceras.

När ett fel detekteras av beslutspunkten IFP4 stegar denna beslutspunkt fram med ett till felsekvensnumret 123, vilket leds som en parameter i metodanropet localizeIFP (4, 123), som sänds av beslutspunkten IFP4. Sekvensnumret 123 tillsammans med den begärande beslutspunktens identitet 4 lagras av IFP:erna utefter den lokaliserade grenen hos grafen. Denna lagrade information utgör en markering av att uppströms belägna grenar redan är undersökta och att kvittering kan sändas nedströms omedelbart. 502 852 28 När sålunda den andra localizeIFP-begäran mottages av IFP1 via IFP2, förstår IFP1 att detta fel redan blivit lokaliserat i de uppströms grenarna, eftersom identiteten hos localizeIFP-begäran är lika med värdet i variabeln 1astFault. Därmed kan notFau1- tyIFP sändas nedströms omdelbart.

Med hänvisning till fig. 12 kan i en andra modifikation för förbättring av sökalgoritmen undersökningen av de uppströms belägna grenarna ske parallellt istället för var för sig. Härvid måste information om den gren, som begäran passerat, adderas till parameterlistan hos metodanropet 1ocalizeIFP. Dessa para- metrar kan implementeras som en "stack", till vilken varje be- slutspunkt, som sänder ett metodanrop localizeIFP, lägger till sin egen identitet. Efter det att i fig. 12 IFP6 konstaterat uppträdande av ett fel och sänder lokaliseringsbegäran uppströms, adderas sålunda successivt i de tre grenarna IFP6- IFP4-IFP2, IFP6-IFP5-IFP3 resp. IFP6-IFP4-IFP3 respektive IFP:ers identiteter, så att IFP1 till slut mottager metodanropen localizeIFP(2,4,6), localizeIFP(3,5,6) resp. 1ocalizeIFP(3,4,6).

I fig. 12 är dessa metodanrop för överskådlighetens skull för- kortade till "loc". Den sändande beslutspunkten IFP5 måste hålla reda på dessa utestående metodanrop. Detta sker medelst en räknare och genom att spara metodanropets identitet. Innan ett metodanrop notFaultyIFP returneras, i fig. 12 förkortat till "notF", måste kvitteringar "expAckID" ha mottagits på varje upp- ströms gren. Identitetsparametern, dvs. stacken, returneras av metodanropet notFaultyIFP. Varje gång ett metodanrop notFaul- tyIFP sänds sker en uppdateringsoperation på stacken. Detta visas i fig. 12 såsom utfört genom att första identiteten i varje successivt uppdaterad stack är den returnerande IFP:ns identitet, vilket uppnåtts genom avlägsnande av den närmast föregående returnerande IFP:ns identitet. IFP6 mottager sålunda till slut meddelandena notFaultyIFP(5,6) och notFaultyIFP(4,6).

Resultatet blir att IFP6 befinns vara den IFP, som ansvarar för den felaktiga domänen.

I en tredje modifikation av sökalgoritmen kan felinverkans- relationen mellan beslutspunkter modelleras som en användar/- tillhandahållarrelation, även kallad 'isDependentUpon', i stäl- let för relationen 'isConnectedByinfluence'. Denna typ av rela- tion innebär att användarens drifttillstånd är fullständigt 5Û2 852 29 beroende av tillhandahållarens drifttillstånd. I fallet med beslutspunkter relaterade till varandra enligt denna typ av relation innebär det att feltillståndet hos en beslutspunkt endast är beroende av feltillståndet hos de närmast uppströms belägna beslutspunkterna. Vid lokalisering av ursprunget till felet behöver man således aldrig fortsätta vidare med locali- zeIFP efter en beslutspunkt som anser sig felfri. Man kan med säkerhet säga att det inte finns några feldetekterande besluts- punkter uppströms.

Modellering med relationen 'isDependentUpon' kommer att ge ett annat utseende åt inflytandegraferna. De blir oftast mindre djupa, på bekostnad av flera förgreningar.

Det ovan sagda åskådliggörs närmare i fig. 13 och 14.

Antag att det finns fyra IFP:er, nämligen IFPO, IFP1, IFP2 och IFP3 med följande relationer med avseende på feldetekte- ringsbeteendet.

Om IFP1 detekterar ett fel kan även IFPO detektera ett fel.

Om IFP2 detekterar ett fel kan även IFPO detektera ett fel.

Om IFP3 detekterar ett fel detekterar även IFP1 ett fel.

Om IFP3 detekterar ett fel detekterar även IFP2 ett fel.

Fig. 13 visar i detta fall den resulterande grafen vid model- lering med relationen isConnectedByInfluence, medan fig. 14 visar grafen vid modellering med relationen isDependentUpon.

Här skall nu felkoordineringsstrategin beskrivas närmare.

Felkoordineringen baserar sig på den insikten att alla be- slutspunkter IFP belägna nedströms om en felansvarig besluts- punkt saknar värde, eftersom inga nya fel kan detekteras och separeras av dessa beslutspunkter. Dessa beslutspunkter kan inta det vilande tillståndet och sätta sin feldetekteringsmekanism ur drift.

Så snart som en beslutspunkt har konstaterat att ett detekte- rat fel ligger inom dess ansvarsdomän, kommer den att sända koordineringsmetodanropet coordinateIFP till alla nedströms be- lägna beslutspunkter. Detta metodanrop vidareleds utefter in- flytandegrafen tills en felterminerande beslutspunkt påträffas.

Identiteten hos den mätpunkt, som konstaterat felet, följer metodanropet och sparas av de passerade beslutspunkterna.

Det ovan beskrivna åskâdliggörs i fig. 15, där beslutspunkten IFP4 konstaterat att ett detekterat fel ligger inom dess an- 502 852 30 svarsdomän, och därför skickar ett metodanrop coordinateIFP (4) nedströms till beslutspunkterna IFP7 och IFP8, vilka intar det vilande tillståndet och sätter sin feldetekteringsmekanism ur drift.

Här följer nu en beskrivning av felåterhämtningsstrategin.

När ett fel har återställts, automatiskt eller genom en reparation, kommer den beslutspunkt IFP, vars övervakade entitet befunnits felaktig, att detektera att felet försvunnit, eftersom dess diagnosdel togs i drift igen så snart som felet konstatera- des, med uppgift att detektera felets försvinnande, såsom be- skrivits ovan med hänvisning till fig. S och 6. Alla nedströms belägna beslutspunkter kommer att underrättas om felets för- svinnande genom felelimineringsmetodanropet "clearFaultIFP".

Detta metodanrop vidareleds utefter inflytandegrafen tills en felterminerande beslutspunkt IFP har påträffats. Identiteten hos den återhämtade beslutspunkten IFP följer metodanropet.

När en beslutspunkt har mottagit metodanropet clearFaultyIFP, kommer den att påbörja övervakningen av fel igen. Naturligtvis måste alla beslutspunkter, som bringat denna beslutspunkt till det vilande tillståndet, ha återhämtat sig först.

Det sagda illustreras i fig. 16, där beslutspunkten IFP4 sänder metodanropet clearFaultIFP (4) till IFP7 och IFP8, vilka påbörjar övervakningen igen.

I fig. 17 har inflytandegrafen enligt fig. 8 ritats på kon- ventionellt sätt som en instansierad objektrelationsmodell.

Riktningen för en relation mellan beslutspunktobjekt skall behandlas som, definitionsmässigt, det omvända mot felpropage- ringsriktningen. Närmare bestämt rör det sig här om relationen connectedßylnfluence.

Med hänvisning till fig. 17 anger relationen connectedßylnfluence: på grund av att IFP7 är kopplat genom inflytande till IFP4, kan ett av IFP7 detekterat fel även ha detekterats av IFP4 och/eller av någon annan beslutspunkt, som är ansluten genom inflytande till IFP4, dvs. IFP3 i detta fall.

Här skall nu indikering av felaktiga funktionsobjekt FO be- skrivas närmare.

Såsom tidigare berörts är ett funktionsobjekt FO en representation i mjukvara av en funktion, som är implementerad av ett eller flera system. Funktionsobjekten kan representera 502 852 31 funktioner på alla typer av abstraktionsnivåer.

Ett funktionsobjekt kan indikeras såsom felaktigt av be- slutspunkterna IFP. Med andra ord är det beslutspunkterna som svarar för övervakningen av funktionerna.

Så snart som en beslutspunkt har lokaliserats såsom "fel- aktig", informeras de övervakade funktionerna och betecknas som felaktiga. I exemplet i fig. 15 svarar IFP4 för att sända ett felindikeringsmeddelande till alla funktionsobjekt FO som över- vakas av den.

Förhållandet mellan beslutspunkten IFP och funktionsobjektet FO är ett många-till-många-förhållande, dvs. en funktion kan övervakas av många beslutspunkter, och en beslutspunkt kan övervaka många funktioner. Funktionsobjekten kan emellertid likaväl implementeras som beslutspunkter själva. Endast metodanrop såsom coordinateIFP och clearFaultIFP används mellan funktionsobjekt (felet är redan lokaliserat).

Så snart som ursprunget för ett fel har lokaliserats, dvs. en beslutspunkt har identifierats som ansvarande för den domän där felet först detekterades, har beslutspunkten IFP ansvaret för att ange en utbytesenhet RU såsom felaktig.

Förhållandet mellan beslutspunkten IFP och utbytesenheten RU är ett många-till-många-förhållande. Den domän, som beslutspunk- ten IFP är satt att övervaka kan täcka fler än en utbytesenhet ru. Detta är ofta fallet när man har att göra med gränssnitt mellan utbytesenheter.

Innan en utbytesenhet RU bytes måste de av utbytesenheten beroende IFP:erna termineras (close IFP) för att förhindra onödiga larm. Efter utbytet tas beslutspunkten i drift igen (openIFP).

För att möjliggöra felindikering endast av en utbytesenhet RU vid samma tillfälle, införs en sannolikhetsfunktion som ett attribut i beslutspunkterna IFP. Denna sannolikhetsfunktion anger sannolikheten för att felet är beläget i en viss utbytes- enhet RU, jfr. stapeldiagrammet i fig. 18, där sannolikheten P för fel anges i en skala från 0 till 1 på y-axeln. Sannolikheten för fel hos tre utbytesenheter RU1, RU2, RU3 anges därvid i form av staplar.

Beslutspunkten IFP kan använda sannolikhetsfunktionen som grundval vid bestämning av vilken enhet som skall ersättas, 502 852 32 eller också kan beslutet vidareledas till objekten RUO som representerar utbytesenheter, genom att vidareleda sannolik- hetsvärdet med felindikeringsmetodanropet. Dessa två fall åskåd- liggörs i fig. 19 såsom fall A resp. B.

I fall A har IFP beslutat att RU1 är felaktig, såsom antyds med pilen faultyRU till RUO1. I fall B vidareleds beslutet till respektive objekt RUO såsom antyds med pilarna suspectRU (P1, P2 resp. P3) till RUO1-3.

Den del av mjukvarumodellen som har hand om felbeteendeanalys av funktioner ansvarar för koordineringen av felet avseende funktionsentiteter.

Denna modell är ganska enkel, den består bara av en typ av objekt, nämligen det av en IFP övervakade funktionsobjektet FO, jfr. fig. 20. Funktionsobjektet representerar en funktion, som implementeras av telekommunikationsutrustningar, och de repre- senterar funktioner på alla abstraktionsnivåer.

Analysen av inverkan av ett fel på de övervakade funktionerna är ganska enkel. Felet är redan detekterat, identifierat och lokaliserat. Analysen av beteendet sker under modelleringsfasen.

I realtid är uppgiften begränsad till en ren tillståndspropage- ring mellan funktionsobjekten FO.

I modelleringsfasen måste beroendet mellan funktionerna omsorgsfullt analyseras. Om arbetstillståndet hos en funktion beror av andra funktioner, måste detta reflekteras i mjukvaru- modellen som ett förhållande isDependentUpon mellan funktions- objekten.

Med hänvisning till fig. 21 har F06 indikerats som felaktigt av hårdvaruövervakningsmodellen. Funktionsobjekten F05 och F03 beror av F06. Därigenom kommer dessa två objekt likaledes att anges som felaktiga. Propageringen av tillstånd kommer att fortsätta tills inga fler beroenden påträffas.

Beroenden existerar inom och mellan funktioner på olika abstraktionsnivåer. Ej heller är tillståndspropageringen be- gränsad till objekt i en enda telekommunikationsutrustning.

Funktioner i en telekommunikationsutrustning kan naturligtvis bero av funktioner i en annan sådan utrustning.

Gränssnittet mellan funktionsobjekt FO implementeras på så sätt att endast metodanrop av typen coordinate och clearFault används, eftersom felet redan har lokaliserats. 502 852 33 Den delen av modellen som hänför sig till reparationshante- ring används av en funktion som underlättar ersättning av fel- aktiga hårdvaruenheter. En objektrelationsrepresentation av modellen visas i fig. 22.

När operatören har begärt en reparationsâtgärd vidarebefor- dras denna begäran till det objekt RUO som representerar ut- bytesenheten. Ifrågavarande begäran kan ske på endera av två sätt, nämligen genom operatörens arbetsstation och användar- gränssnittet till det styrda objektet, som representerar ut- bytesenheten RU, eller genom tryckning av en på utbytesenheten monterad knapp.

Objektet RUO underrättar de berörda beslutspunkterna IFP, vilka måste upphöra att detektera fel. Varje beslutspunkt IFP som är påverkad av reparationsaktiviteten ber funktionsobjekten FO att avsluta den aktuella användningen av den övervakade funktionen som funktionsobjekten FO representerar. Därigenom termineras utbytesenheten RU och kan avlägsnas.

När en ny enhet installeras sker ett igångsättnings- eller acceptanstest av den nya enheten innan den tas i tjänst.

Antag att en utbytesenhet RU måste ersättas p.g.a. hårdvaru- fel. Alla beslutspunkter IFP som övervakar utbytesenheten RU in- formeras. Alla beslutspunkter IFP nedströms i de berörda infly- tandegraferna informeras likaledes. Detta undviker onödiga alarm vid ersättning av hårdvaran. De berörda objekten informeras genom tillståndspropagering.

Tillståndspropageringen sker tills en beslutspunkt IFP har nåtts, för vilken endera av följande möjligheter uppfyllts: - beslutspunkten IFP är en felterminerande beslutspunkt - beslutspunkten IFP är redan informerad om reparationsakti- viteten.

Fig. 23 visar ett exempel där RU1 har indikerats som felaktig p.g.a. ett fel lokaliserat i beslutspunkten IFP4. När en repara- tionsåtgärd krävs, informeras de beslutspunkter IFP2 till IFP8, som är ansvariga för övervakningen av utbytesenheten, direkt av objektet, som representerar RU1. Dessa beslutspunkter kommer att helt sättas ur drift, dvs. de stänger av sin feldetekterande mekanism, och informerar de funktioner, vilkas övervakning de ansvarar för, om enhetens terminering.

Det bör anmärkas att en beslutspunkt IFP kan ändra sitt 502 852 34 felpropageringsbeteende vid övergång till den urdriftsatta moden. Det är fallet för IFP8 i exemplet enligt fig. 22, jfr. fig. 8. Detta innebär att inflytandegrafen kan bli lätt modifie- rad när den betraktas ur reparationshanteringssynpunkt.

IFP9 till IFPn, som svarar för övervakningen av RU2, informe- ras om termineringen av enheten av IFP8. Dessa IFP:er kommer endast att stänga av sin feldetekteringsmekanism, varvid till- hörande funktioner ej informeras.

Såsom nämnts tidigare är nu varje urdriftsatt IFP ansvarig för att informera funktionsobjekten om termineringen av enheten.

Funktionsobjekten kommer att terminera den pågående användningen av de övervakade funktionerna. Tillståndspropageringen mellan funktionsobjekten sker på exakt samma sätt som vid felkoordine- ring av funktioner, vilken beskrivits ovan.

Termineringsbegäran implementeras med ett metodanrop closeIFP, jfr. fig. 24. Det kan noteras att IFP8 ändras till en "normal" IFP när den inträder i det transparenta tillståndet.

IFP9 övergår till vilande tillstånd p.g.a. att ett metodanrop closeIFP mottas med en RU-identifierare, som ej är lika med dess egen RU-anknytning.

Innan en enhet tas i drift sker en igångsättnings- eller acceptanstest av enheten själv. Igångsättningstesten är en inbyggd självtestningsfunktion, som endast sker en gång vid uppstart. Denna test kan betraktas som en ren hårdvarufunktion och ingår inte i mjukvarumodellen. Testen kan emellertid styras och övervakas av den lokala processorn, som styr enheten.

Innan den nya enheten sätts i drift måste självtesten äga rum utan problem.

För beskrivning av hur en utbytesenhet sätts i drift, kan det antas att styranslutningen till tillämpningsprogrammet, som svarar för hårdvaruövervakningen, i lokalprocessorn har återupp- rättats.

Alla beslutspunkter IFP, som påverkas av denna reparationsak- tivitet informeras om installationen av den nya hårdvaruenheten RU. Därpå kommer beslutspunkterna att påbörja sin övervakning.

Beslutspunkter som indirekt är knutna till utbytesenheten RU in- formeras genom tillståndspropagering utefter inflytandegrafen, exakt på samma sätt som när utbytesenheten terminerades. Begäran om igångsättning sker i form av metodanropet openIFP. 502 852 35 Så snart som en IFP har påbörjat sin övervakning, medges användning av de funktionsobjekt FO som övervakas av denna beslutspunkt. Om funktionen övervakas av flera beslutspunkter måste den vänta tills tillstånd mottagits från alla besluts- punkter.

Claims (37)

502 852 36 Eatentkrav

1. Felövervaknings- och felhanteringssystem i ett telekommu- nikationssystem, kännetecknat av ett kedjesystem av i en felpropageringsriktning i telekommu- nikationssystemet efter varandra sammankopplade diagnos- och be- slutsobjekt, vilkas placering i kedjesystemet bestäms så att de i en egen övervakningsdomän är i stånd att övervaka varsitt fenomen, som kan förorsakas av fel i telekommunikationssystemet, och kommunicera, påverka och interagera med varandra vid felupp- komst för lokalisering av fel i telekommunikationssystemet, att ett diagnos- och beslutsobjekt, som detekterar förekomst av ett fel i sitt kedjesystem, innan det fastställer om felet uppkommit i dess egen observationsdomän skickar en fellokalise- ringsbegäran till diagnos- och beslutsobjekt i kedjesystemet, som är belägna före det feldetekterande objektet relativt fel- propageringsriktningen, om att de skall sända tillbaka ett kvitteringsmeddelande om huruvida även de har detekterat ett fel eller inte.

2. System enligt krav 1, i vilket varje diagnos- och be- slutsobjekt utnyttjar ett eller flera mätpunktsobjekt för obser- vation av uppkomst av det fenomen diagnos- och beslutsobjektet övervakar, samt rapportering till diagnos- och beslutsobjektet.

3. System enligt krav 2, kännetecknat av att flera mätpunkts- objekt kan vara grupperade till ett mätkombinationsobjekt, som samlar upp och behandlar data från de ingående mätpunktsobjek- ten.

4. System enligt något av krav 1-3, kännetecknat av att sökningen av fel hos andra diagnos- och beslutsobjekt fortsätter tills ett diagnos- och beslutsobjekt påträffas, vilket antingen bildar början av det aktuella kedjesystemet, eller också har detekterat ett fel.

5. System enligt något av krav 1-4, kännetecknat av att om det aktuella kedjesystemet innehåller flera parallella grenar före det feldetekterande diagnos- och beslutsobjektet, sker sökning i en gren åt gången.

6. System enligt något av krav 1-5, kännetecknat av att fellokaliseringsbegäran innehåller en identitetsparameter, som identifierar ursprunget för den.

7. System enligt något av krav 1-6, kännetecknat av att 502 852 37 kvitteringsmeddelandet innehåller två identifieringsparametrar, en som identifierar ursprunget för lokaliseringsbegäran och en som identifierar avsändaren.

8. System enligt något av krav 1-3, kännetecknat av att ett för varje diagnos- och beslutsobjekt lokalt felsekvensnummer används, varvid när ett fel detekteras av ett diagnos- och beslutsobjekt, det senare stegar fram sekvensnumret med ett, och detta nummer infogas som en parameter i fellokaliseringsbegäran, och sekvensnumret tillsammans med det begärande diagnos- och beslutsobjektets-identitet lagras utefter kedjesystemet, vilken lagrade information utgör en markering av att uppströms belägna grenar redan är undersökta och att kvittering kan sändas ned- ströms omedelbart.

9. System enligt något av krav 1-3, kännetecknat av att om det aktuella kedjesystemet innehåller flera parallella grenar för det feldetekterande diagnos- och beslutsobjektet, sker sökning i de uppströms belägna grenarna parallellt, varvid information om den gren, som begäran passerat, adderas till en parameterlista för fellokaliseringsbegäran.

10. System enligt krav 9, kännetecknat av att parametrarna implementeras som en stack, till vilken varje diagnos- och beslutsobjekt, som sänder en lokaliseringsbegäran lägger till sin egen identitet.

11. System enligt krav 10, kännetecknat av att det sändande diagnos- och beslutsobjektet håller reda på utestående lokalise- ringsbegäranden med hjälp av en räknare och genom att spara begärans identitet.

12. System enligt något av krav 8-ll, kännetecknat av att innan ett kvitteringsmeddelande returneras, måste kvitterings- meddelanden på varje gren uppströms ha mottagits.

13. System enligt något av krav 10-12, kännetecknat av att identitetsparametern returneras av kvitteringsmeddelandet.

14. System enligt något av krav 8-13, kännetecknat av att varje gång ett kvitteringsmeddelande sänds sker en uppdaterings- operation på stacken.

15. System enligt något av krav l-14, kännetecknat av att så snart som ett diagnos- och beslutsobjekt har konstaterat att ett detekterat fel ligger inom dess domän, sänder det ett koordi- neringsmetodanrop till alla nedströms i felpropageringsrikt- 502 852 38 ningen belägna diagnos- och beslutsobjekt, vilket metodanrop vidareleds tills ett felterminerande diagnos- och beslutsobjekt påträffas.

16. System enligt krav 15, kännetecknat av att identiteten hos det sändande diagnos- och beslutsobjektet följer koordine- ringsmetodanropet och sparas av de passerade diagnos- och be- slutsobjekten.

17. System enligt något av krav 1-16, kännetecknat av att när ett fel har åtgärdats detekteras felets försvinnande av det diagnos- och beslutsobjekt, som ursprungligen detekterade felet, varvid objektet sänder ett metodanrop om detta till alla ned- ströms belägna diagnos- och beslutsobjekt, vilket metodanrop vidareleds tills ett felterminerande diagnos- och beslutsobjekt har påträffats.

18. System enligt krav 17, kännetecknat av att identiteten hos det ifrågavarande diagnos- och beslutsobjektet följer med- delandet om felets försvinnade.

19. System enligt krav 18, kännetecknat av att när ett diagnos- och beslutsobjekt har mottagit meddelandet om felets försvinnande påbörjar det övervakningen av fel igen efter det att alla diagnos- och beslutsobjekt, som förorsakat urdriftsätt- ning av detta diagnos- och beslutsobjekt, har återhämtat sig.

20. Sätt för distribuerad felhantering i ett telekommunika- tionssytem, kännetecknat av att flöden av data och signaler i systemet analyseras för be- stämning av systemets beteende vid feluppkomst och därigenom lokalisering av fenomen, som kan förorsakas av fel, nämnda beteende representeras med ett eller flera kedjesystem av i en felpropageringsriktning efter varandra sammankopplade diagnos- och beslutsobjekt, vilkas placering i sitt kedjesystem bestäms så att de i en egen övervakningsdomän är i stånd att övervaka varsitt av de av nämnda fenomen, som ingår i detta kedjesystem, och kommunicera, påverka och interagera med varan- dra vid feluppkomst för lokalisering av ett fel i systemet, varje diagnos- och beslutsobjekt utnyttjar ett eller flera mätpunktsobjekt för observation av uppkomst av det fenomen diagnos- och beslutsobjektet övervakar, samt rapportering till diagnos- och beslutsobjektet, 1 ett diagnos- och beslutsobjekt, som detekterar förekomst av 502 852 39 ett fel i sitt kedjesystem, innan det fastställer om felet upp- kommit i dess egen observationsdomän skickar en fellokalise- ringsbegäran till diagnos- och beslutsobjekt i kedjesystemet, som är belägna före det feldetekterande objektet relativt fel- propageringsriktningen, om att de skall sända tillbaka ett kvitteringsmeddelande om huruvida även de har detekterat ett fel eller inte.

21. Sätt enligt krav 20, kännetecknat av att flera mätpunkts- objekt kan vara grupperade till ett mätkombinationsobjekt, som samlar upp och behandlar data från de ingående mätpunktsobjek- ten.

22. Sätt enligt krav 20 eller 21, kännetecknat av att sök- ningen av fel hos andra diagnos- och beslutsobjekt fortsätter tills ett diagnos- och beslutsobjekt påträffas, vilket antingen bildar början av det aktuella kedjesystemet, eller också har detekterat ett fel.

23. Sätt enligt något av krav 20-22, kännetecknat av att om det aktuella kedjesystemet innehåller flera parallella grenar före det feldetekterande diagnos- och beslutsobjektet, sker sökning i en gren åt gången. _

24. Sätt enligt något av krav 20-23, kännetecknat av att fellokaliseringsbegäran innehåller en identitetsparameter, som identifierar ursprunget för den.

25. Sätt enligt något av krav 20-24, kännetecknat av att kvitteringsmeddelandet innehåller två identifieringsparametrar, en som identifierar ursprunget för lokaliseringsbegäran och en som identifierar avsändaren.

26. Sätt enligt krav 20 eller 21, kännetecknat av att ett för varje diagnos- och beslutsobjekt lokalt felsekvensnummer an- vänds, varvid när ett fel detekteras av ett diagnos- och be- slutsobjekt, det senare stegar fram sekvensnumret med ett, och detta nummer infogas som en parameter i fellokaliseringsbegäran, och sekvensnumret tillsammans med det begärande diagnos- och beslutsobjektets identitet lagras utefter kedjesystemet, vilken lagrade information utgör en markering av att uppströms belägna grenar redan är undersökta och att kvittering kan sändas ned- ströms omedelbart.

27. Sätt enligt krav 20 eller 21, kännetecknat av att om det aktuella kedjesystemet innehåller flera parallella grenar för 502 852 40 o det feldetekterande diagnos- och beslutobjektet, sker sökning 1 de uppströms belägna grenarna parallellt, varvid information om den gren, som begäran passerat, adderas till en parameterlista för fellokaliseringsbegäran.

28. Sätt enligt krav 27, kännetecknat av att parametrarna implementeras som en stack, till vilken varje diagnos- och beslutsobjekt, som sänder en lokaliseringsbegäran lägger till sin egen identitet.

29. Sätt enligt krav 28, kännetecknat av att det sändande diagnos- och beslutsobjektet håller reda på utestående lokalise- ringsbegäranden med hjälp av en räknare och genom att spara begärans identitet.

30. Sätt enligt något av krav 26-29, kännetecknat av att innan ett kvitteringsmeddelande returneras, måste kvitterings- meddelanden på varje gren uppströms ha mottagits.

31. Sätt enligt något av krav 26-30, kännetecknat av att identitetsparametern returneras av kvitteringsmeddelandet.

32. Sätt enligt något av krav 26-31, kännetecknat av att varje gång ett kvitteringsmeddelande sänds sker en uppdaterings- operation på stacken.

33. Sätt enligt något av krav 20-32, kännetecknat av att så snart som ett diagnos- och beslutsobjekt har konstaterat att ett detekterat fel ligger inom dess domän, sänder det ett koordi- neringsmetodanrop till alla nedströms i felpropageringsrikt- ningen belägna diagnos- och beslutsobjekt, vilket metodanrop vidareleds tills ett felterminerande diagnos- och beslutsobjekt påträffas.

34. Sätt enligt krav 33, kännetecknat av att identiteten hos det sändande diagnos- och beslutsobjektet följer koordinerings- metodanropet och sparas av de passerade diagnos- och beslutsob- jekten.

35. Sätt enligt något av krav 20-34, kännetecknat av att när ett fel har åtgärdats detekteras felets försvinnande av det diagnos- och beslutsobjekt, som ursprungligen detekterade felet, varvid objektet sänder ett metodanrop om detta till alla ned- ströms belägna diagnos- och beslutsobjekt, vilket metodanrop vidareleds tills ett felterminerande diagnos- och beslutsobjekt har påträffats.

36. Sätt enligt krav 35, kännetecknat av att identiteten hos 502 852 41 det ifrågavarande diagnos- och beslutsobjektet följer meddelan- det om felets försvinnade.

37. Sätt enligt krav 36, kännetecknat av att när ett diagnos- och beslutsobjekt har mottagit meddelandet om felets försvinnan- de påbörjar det övervakningen av fel igen efter det att alla diagnos- och beslutsobjekt, som förorsakat urdriftsättning av detta diagnos- och beslutsobjekt, har återhämtat sig.