NL1030059C2 - Modelgesteunde diagnose en reparatie door middel van gebeurtenisprotocollering. - Google Patents

Description

MODELGESTEUNDE DIAGNOSE EN REPARATIE DOOR MIDDEL VAN GEBEURTENISPROTOCOLLERING

Voor diagnosedoeleinden gebruiken softwaresystemen met verschillende compo-5 nenten vaak protocol leringsdatabanken, die het bedrijf van het systeem en van componenten volgen. Met een “gebeurtenisprotocollering” kan men chronologisch gebeurtenissen opslaan, die door verschillende softwarecomponenten in het systeem worden gegenereerd. Softwarecomponenten kunnen gebeurtenissen als reacties op bepaalde combinaties van hun begintoestand en stimuli bijvoorbeeld uit andere softwaremodules, 10 de hardware of van de gebruiker genereren.

De geprotocolleerde gebeurtenissen vallen in de regel in een van drie categorieën: een “foutgebeurtenis” wordt gegenereerd wanneer een fout werd gevonden of een buitengewone of onverwachte gebeurtenis optrad; een “succesgebeurtenis” informeert erover dat een aspect van het systeem correct loopt; en een “informatiegebeurtenis” 15 informeert erover dat bepaalde informatiedingen optreden.

Aan gebeurtenissen kan verder een gewicht worden toegewezen. Bijvoorbeeld kunnen verschillende foutgebeurtenissen verschillende gewichten hebben. Succesgebeurtenissen en informatiegebeurtenissen zullen gewoonlijk een lager gewicht hebben dan foutgebeurtenissen.

20 De gebeurtenisprotocollering kan ook verscheidene toegangsbevoegdheden heb ben. Bijvoorbeeld kunnen mogelijkerwijs slechts systeemadministratoren toegang tot bepaalde beveiligde protocolleringen (“interne gebeurtenisprotocollering”) of delen van de protocollering of gebeurtenissen (bijvoorbeeld beveiligingsovertreding enzovoorts) hebben, terwijl softwarecomponentgebruikers toegang hebben tot verscheidene proto-25 colleringen (“gebruikersgebeurtenisprotocollering”) of protocolleringsdelen, die op het bedrijf van de betreffende softwarecomponent betrekking hebben.

De gebruikersgebeurtenisprotocollering stelt een voor de gebruiker gefilterde versie van de interne gebeurtenisprotocollering voor. Het doel van het filteren van de interne gebeurtenisprotocollering bestaat eruit te vermijden dat aan de gebruiker irrele-30 vante en redundante informatie wordt getoond. De gebruikersgebeurtenisprotocollering toont slechts gebeurtenissen met een bepaalde criticiteitsgraad (waarbij deze graad een configureerbare graad is). Gebeurtenissen worden in de gebruikersgebeurtenisprotocol- .1030 0 59 2 lering aangeduid, tot de gebruiker ze bevestigt. Het gebruikersoppervlak kan een speciaal symbool aanduiden, zolang de gebruikersgebeurtenisprotocollering ten minste één onbevestigde gebeurtenis omvat. De gebruikersgebeurtenisprotocollering toont de gefilterde gebeurtenissen in omgekeerde chronologische volgorde, zodat de nieuwste bo-5 ven in een lijst wordt aangeduid. In een afzonderlijk gebruikersoppervlak kan de gebruiker de volledige gebruikersgebeurtenisprotocollering bekijken, dat wil zeggen, inclusief de bevestigde gebeurtenissen. Gebeurtenissen in de gebruikersgebeurtenisproto-collering kunnen bij de ontvangst van succesgebeurtenissen automatisch worden bevestigd.

10 Zowel de interne gebeurtenisprotocollering (voor systeempersoneel) als ook de gebruikersgebeurtenisprotocollering (voor gebruikers) worden voor de eenvoudigere diagnose van problemen in het systeem beschikbaar gesteld.

Een probleem met dergelijke protocolleringsbestanden bestaat er echter uit dat de gebruikersgebeurtenisprotocollering te veel gebeurtenissen of niet de meest relevante 15 gebeurtenissen toont. Elk significant probleem, dat de gebruiker interesseert, kan meer dan één gebeurtenis genereren. Aangezien de gebeurtenissen chronologisch zijn aangegeven, bevinden de belangrijkste zich niet beslist bovenaan.

Bovendien kan in dergelijke systemen de voor elke gebeurtenis aangeduide verklarende tekst de oorzaak van het probleem beschrijven, maar de gebeurtenisoorzaken-20 tekst is statisch en wordt niet door andere gebeurtenissen beïnvloed. Bepaalde gebeurtenissen kunnen verschillende oorzaken hebben. Aangezien de uiteenzetting statisch is, moeten ze dan ofwel alle mogelijkheden beschrijven of anders bepaalde of alle oorzaken weglaten. Dit kan verwarrend zijn, in het bijzonder wanneer op grond van tegenstrijdige, redundante of ontoereikende informatie meerdere gebeurtenissen in de ge-25 bruikersgebeurtenisprotocollering aanwezig zijn.

De voor elke gebeurtenis getoonde verklarende tekst kan een passende reparatie-' actie voor het oplossen van het probleem beschrijven. Het probleem bestaat eruit dat de i gebeurtenisactietekst statisch is en niet door andere gebeurtenissen wordt beïnvloed, j Voor bepaalde gebeurtenissen is het eventueel niet mogelijk om één enkele reparatieac- 30 tie te specificeren, omdat de overeenkomstige reparatieacties afhangen van aanvullende informatie. Aangezien de verklaring statisch is, moet ze dan alle mogelijkheden beschrijven of bepaalde of alle reparatieacties weglaten. Ook dit kan verwarrend werken, 3 in het bijzonder, wanneer op grond van tegenstrijdige, redundante of ontoereikende instructies meerdere gebeurtenissen in de gebruikersgebeurtenisprotocollering aanwezig zijn.

Er ontbreekt een software, die automatisch reparatie-acties uitvoert. Bepaalde 5 problemen kunnen met softwareprogramma’s worden gerepareerd. Overeenkomstige reparatieacties kunnen automatisch worden uitgevoerd wanneer een diagnose automatisch kan plaatsvinden, of ze kunnen wellicht worden toegestaan, wanneer ze door de gebruiker worden bevestigd.

Er is een software nodig die probeert om door analyse van meerdere gebeurtenis-10 sen een diagnose uit te voeren. Bepaalde problemen kunnen slechts door beschouwing van meer dan één gebeurtenis of door aanvullende informatie sluitend worden vastgesteld.

De interne gebeurtenisprotocollering omvat niet altijd genoeg informatie voor een sluitende diagnose. Het zou nuttig zijn wanneer ook andere informatiebronnen voor 15 diagnosedoeleinden gebruikt zouden kunnen worden. Dergelijke informatiebronnen zouden protocolleringsbestanden, data of programmamodule-toestandsinformatie kunnen zijn.

In bepaalde gevallen zou voor een sluitende diagnose noodzakelijke aanvullende informatie automatisch door oproepen van testfuncties verzameld kunnen worden. De-20 ze mogelijkheid bestaat thans niet. Het technische probleem bestaat eruit om erachter te komen wanneer dergelijke testfuncties opgeroepen zouden moeten worden. Om per-formance-redenen is het niet geschikt om deze bijvoorbeeld voor elke ontvangen gebeurtenis uit te voeren.

Het is niet altijd mogelijk om automatisch zonder interventie door de gebruiker 25 noodzakelijke informatie voor een sluitende diagnose te verzamelen. Bepaalde dingen kunnen slechts of het eenvoudigst door de gebruiker worden gecontroleerd. De diagno-semogelijkheid van het systeem zou verbeterd kunnen worden, wanneer de diagno-sesoftware naar handmatige testresultaten zou kunnen vragen of deze zou kunnen aannemen.

30 Enkele wizards van moderne Microsoft-producten zijn voorbeelden voor efficiën te diagnosewerktuigen. De gebruiker wordt door een reeks dialogen geleid, die ertoe dienen om informatie te verzamelen en om de probleemoorzaak vast te stellen.

4

Het is bekend om gebeurtenisprotocolleringen te gebruiken waarbij gebeurtenissen naar gewicht worden geclassificeerd en slechts de belangrijkste boven in een lijst worden aangeduid. Hun bevestiging en - indien nodig - verplaatsing in een verlooplijst is gewoonlijk mogelijk.

5 Het is een taak van de uitvinding om het vinden van een hardware- of gebruikers- fout in een softwaregestuurde inrichting zoals bijvoorbeeld een NMR-inrichting te vergemakkelijken. De uitvinding lost deze doelstelling en de hierboven beschreven problemen onder andere op door toevoegen van een diagnosefunctie aan de gebruikersge-beurtenisprotocollering. De uitvinding kan ofwel het filteren tussen de interne gebeur-10 tenisprotocollering en de gebruikersgebeurtenisprotocollering vervangen ofwel kan aanvullend naast de gebruikersgebeurtenisprotocollering worden gebruikt.

Er wordt een analyse van informatiebronnen uitgevoerd: het verloop van de gebeurtenisprotocollering wordt op patronen doorzocht; aanvullend kunnen vragen/tests verdere informatie voor uitgebreide patronen opleveren; verder kunnen reparatieacties 15 worden voorgesteld.

Een optionele uitvoeringsvorm van de uitvinding voegt de mogelijkheid toe om afhankelijk van een realisatiemethode de gebruiker naar handmatige Testresultaten te \ vragen of handmatige testresultaten aan te nemen. Een andere uitvoeringsvorm van de uitvinding maakt het voor de diagnosefunctie mogelijk om automatisch testfuncties 20 voor het verzamelen van verdere, voor een sluitende diagnose noodzakelijke informatie op te roepen. Een verdere uitvoeringsvorm van de uitvinding bestaat eruit het voor de diagnosefunctie mogelijk te maken om automatisch reparatieacties voor het oplossen van het probleem op te roepen.

Deze aanzet van de foutopsporing kan op voordelige wijze op een breed spectrum 25 van technische apparaten worden toegepast. De enige voorwaarde bestaat eruit dat de systeemsoftware gebeurtenissen genereert en deze in een gebeurtenisprotocollering opslaat. De uitvinding is in het bijzonder geschikt voor software van medische systemen. Ze kan zonder veel moeite in bestaande software worden geïntegreerd; de noodzakelijke software is klein en kan in een afzonderlijke softwaremodule worden geïm-30 plementeerd. De verandering aan het gebruikersoppervlak is klein en tot de gebeurtenisprotocollering geïsoleerd. Ze wordt door een gemakkelijk actualiseerbaar model gestuurd. Aangezien geen verandering van programmacode nodig is, kunnen geactuali- 5 seerde modellen aan klantensystemen worden verdeeld, ook wanneer in deze systemen medische apparaten voorkomen. De modellen kunnen vanuit op afstand gelegen standplaatsen worden geactualiseerd, waardoor het mogelijk wordt om verbeteringen snel en goedkoop wereldwijd te verdelen.

5 Dit systeem kan ook in verbinding met onvolledige modellen nuttig zijn en zou zelfs met een leeg model kunnen werken; de diagnosemogelijkheid zou dan op het niveau van een zuivere gebeurtenisprotocollering verslechterd worden, alsof de uitvinding niet gebruikt zou worden. De kwaliteit van de diagnose kan door uitbreiden van het model incrementeel worden verbeterd. Met toenemende ervaring met het gebruik 10 van het systeem kan men het model uitbreiden, om de diagnosemogelijkheden te verbeteren.

Verdere voordelige uitvoeringsvormen van de uitvinding zijn door de maatregelen van de onderconclusies gekenmerkt.

De uitvinding wordt uitvoeriger uiteengezet met verwijzing naar verschillende 15 uitvoeringsvormen, die in de tekeningen worden afgebeeld en hieronder uitvoeriger worden beschreven.

Figuur 1 is een blokschema van wezenlijke componenten van het systeem;

Figuur 2 is een blokschema van de verhouding tussen patronen, oorzaken en reparaties; 20 Figuur 3 is een blokschema van de gebeurtenisstroom door het systeem;

Figuur 4 is een blokschema van de toewijzing van waarschijnlijkheden met betrekking tot gebeurtenissequenties, diagnoses, tests en reparatieacties;

Figuur 5 is een blokschema van het gebruik van de gebeurtenisfilter- en diagno-sesoftware met een mogelijk gebruikersaanduid- en ondervragingsmechanisme; en 25 Figuur 6 is een stroomschema van een uitvoeringsvorm van de uitvinding.

Figuur 1 toont de bij uitvoeringsvormen van de uitvinding betrokken hoofdcomponenten. Het systeem omvat zowel hardwarecomponenten 12 als ook softwarecompo-nenten 14. Gebeurtenissen met betrekking tot activiteiten van hardware 12, software 14 en gebruiker 16 worden in een gebeurtenisprotocollering 20 opgeslagen. In de bekende 30 systemen wordt een verloop van de gebeurtenisprotocollering 20 aan de gebruiker 16 gedeeltelijk (gefilterd) aangeduid, maar er bestaat praktisch geen intelligentie in het hiermee verbonden filter, met de uitzondering, dat, wanneer een fout later wordt gecor- 6 rigeerd en een succesgebeurtenis wordt gegenereerd, de voormalige fout niet meer wordt aangeduid. Fouten kunnen hardwarefouten van de hardwarecomponenten 12 of gebruikersfouten bij de invoer door de gebruiker 16 zijn.

De volgende begrippen worden hieronder met verwijzing naar de figuren voor 5 verwijzingscijfers gedefinieerd.

Begrip Definitie

Hoofdoorzaak (bijv. diagnose dl) Defecte hardwarecomponent of foutieve gebruikersinvoer; de aan de fout ten grondslag liggende oorzaak

Een op een hoofdoorzaak betrekking heb- De hoofdoorzaak veroorzaakt een reeks bend patroon (bijvoorbeeld gebeurtenisse- gebeurtenissen (errorl, infol, enz.); deze quentie enl) reeks hangt meer of minder direct met de hoofdoorzaak samen; ze kan logische bewerkingen aan gebeurtenissen omvatten. Voorbeeld-patroon: errorl OR error2; ten minste driemaal, dan error3; “Antwoord questionl: component 1 antwoordt niet”; dan error4; infol enz.

Uitgebreid patroon Verdere informatie zou het zoekproces naar de eerste oorzaak kunnen beperken, daarom: a) kunnen “vragen” worden gesteld die de gebruiker kan beantwoorden (correct ingestoken stekker enz.); en b) er kunnen “tests” (dl) worden uitgevoerd die op de functionaliteit van de hardware betrekking hebben (zie bijvoorbeeld de US-octrooiaanvrage nr. 2004/0153819, waarnaar hiermee uitdrukkelijk wordt verwezen); deze informatie draagt bij tot het met de hoofdoorzaak samenhangende patroon.

7

Reparatieactie (bijvoorbeeld rl) Een geïsoleerde fout kan door een repara- tieactie zoals bijvoorbeeld “nogmaals insteken”, “correcte parameter nogmaals invoeren”, “service oproepen” enz. worden opgeheven.

Probabilistische verhoudingen Dit zijn verhoudingen bijvoorbeeld tussen een eerste oorzaak en een patroon of een patroon en een reparatiectie; positieve waarschijnlijkheid -> direct verbonden, negatieve waarschijnlijkheid -> exclusief verbonden; gerealiseerd door

Bayesiaanse netwerkimplementering (zie bijv. de US-octrooiaanvrage nr.

2004/0153819).

Er wordt een “causaliteitsmodel” (figuur 2) gebruikt, dat hoofdoorzaken (26, causel, cause2, cause3) met “(uitgebreide) op hoofdoorzaken betrokken patronen” (24, patteml, pattem2, pattem3) in verband brengt. Om een “hoofdoorzaak” 26 te isoleren, 5 wordt het verloop van de gebeurtenisprotocollering 20 met de patronen 24 vergeleken.

Er worden waarschijnlijkheden Pi-Pn geëvalueerd en aan de gebruiker 16 aanvullende “vragen” gesteld, om het zoekproces zo veel mogelijk te beperken. Van de hardware en de gebruiker op basis van vragen en tests 22 ontvangen informatie wordt beschikbaar gesteld om de bepaling uit te voeren. Als laatste kunnen “reparatieacties” (28, repairl, 10 repair2, repair3) op basis van de ontvangen informatie 22, patroon 24, oorzaken 26 en waarschijnlijkheden Pi-Pn worden voorgesteld.

Aanvragen voor de gebruiker, die bij voorkeur ja/nee-vragen omvatten, zouden bijvoorbeeld zijn “Heeft u stekker A in poort B gestoken?” of “Heeft u de inrichting tijdens het afstemmen correct gepositioneerd?” 15 Er kunnen hardwaretests worden uitgevoerd (bijvoorbeeld uit een testmodel, dat in de US-octrooiaanvrage nr. 2004/0153819 wordt beschreven), waartoe software-testroutines behoren, die: 1) tot ja/nee-antwoorden leiden of 2) uit andere protocolle- 8 ringsbestanden, die met het lopende systeem in verband staan en dit beschrijven, verdere informatie extraheren.

Eenvoudige gebeurtenissen in de gebeurtenis-historie kunnen een patroon vormen, wanneer ze met antwoorden tot enkele weinige vragen worden samengekoppeld.

5 Bijvoorbeeld kan men een foutpatroon van lokale spoelen met alle soorten verschillende gebeurtenissen in de gebeurtenisprotocollerings-historie mengen, bijvoorbeeld 1) “spoel onbekend” - een foutgebeurtenis in de softwarelaag A; 2) “kan niet meten” - een foutgebeurtenis in de softwarelaag B; 3) “meting door NMR-scanner gestopt” - een foutgebeurtenis in een (bovenste) 10 softwarelaag C.

In dit voorbeeld wordt aan de gebruiker een gefilterde foutgebeurtenis gepresenteerd: “lokale spoelfout - lokale spoel niet detecteerbaar”. De mogelijke redenen luiden bijvoorbeeld:

De spoel is 15 a) beschadigd; b) niet correct verbonden; c) aan het systeem nog niet bekend (nieuwe spoel van de fabrikant).

Een mogelijke test om te bepalen of de spoel verbonden, beschadigd enzovoorts is, zou een spanningstest kunnen zijn. Vragen zouden bijvoorbeeld zijn: 20 1) “Heeft u de spoel ingestoken?” - waarvoor een ja/nee-antwoord zou worden vereist; 2) “Is dit een standaardspoel (markering X)?” - waarvoor een “ja”-antwoord de reparatieactie “service oproepen” en een “nee”-antwoord de reparatieactie “een nieuwe spoel installeren” zou kunnen inleiden.

25 Nu volgt een uitvoerigere beschrijving. Hieronder beschreven verscheidene uitvoeringsvormen van de uitvinding hebben twee delen: een datamodel en een algoritme. Het datamodel slaat voor een bepaald systeem specifieke informatie op. Het algoritme is daarentegen generiek en blijft op alle systemen gelijk.

Een datamodel is een netwerkmodel met vier hoofdknooppunttypen: gebeurtenis-30 sequenties, tests, diagnose en reparatieacties. De randen van het netwerkmodel beschrijven afhankelijkheden tussen de knooppunten. De relevante afhankelijkheden lui- 9 den: gebeurtenis-diagnose-afhankelijkheden, test-diagnose-afhankelijkheden en dia-gnose-reparatie-afhankelijkheden.

Een gebeurtenissequentieknooppunt vertegenwoordigt een uitdrukking, die ofwel als true (1) ofwel als false (0) wordt geëvalueerd. Een bijzonder geschikt, voor de uit-5 vinding bruikbaar uitdrukkingstype zijn “reguliere uitdrukkingen”. Reguliere uitdrukkingen worden precies dan als true geëvalueerd, wanneer de gebeurtenissequentie in de interne gebeurtenisprotocollering met het patroon van de uitdrukking kan worden vergeleken. Reguliere uitdrukkingen kunnen zeer efficiënt worden geëvalueerd. De ge-beurtenissequentieknooppuntuitdrukkingen worden als true geëvalueerd, zodra de eer-10 ste gebeurtenis wordt ontvangen, die het patroon van de reguliere uitdrukking comple- ! i teert. Normaliter wordt de reguliere uitdrukking zodanig geformuleerd dat hij ofwel als foutief wordt geëvalueerd, zodra een andere gebeurtenis, bijvoorbeeld een succesgebeurtenis wordt ontvangen. Bij een uitvoeringsvorm van de uitvinding zou de reguliere uitdrukking uitgebreid kunnen worden, om ook tijdsbeperkingen tussen gebeurtenissen 15 te behandelen.

Bij een uitvoeringsvorm van de uitvinding kunnen ook andere informatiebronnen in gebeurtenissequentieknooppunten worden geëvalueerd. Dergelijke informatiebronnen zijn bijvoorbeeld andere vormen van protocolleringsbestanden, die het systeem voert, configuratiebestanden en databanken.

20 Het testknooppunt vertegenwoordigt tests, die uitgevoerd kunnen worden om informatie te verzamelen die de mogelijkheid van een beslissende diagnose verbetert. Men kan ook zeggen dat testknooppunten een uitdrukking hebben, die net als bij de gebeurtenissequentieknooppunten als true (1) of false (0) wordt geëvalueerd. “True” betekent dat de test positief was, en “false” betekent de test negatief was. Er zijn twee 25 hoofdtypes van tests: handmatig en automatisch. Handmatige tests bestaan uit een vraag voor de gebruiker, die met “ja” of “nee” beantwoord kan worden. Afhankelijk van de context moet men specificeren welk antwoord met een positief testresultaat overeenkomt. De automatische tests kunnen door het systeem zelf zonder interactie met de gebruiker worden uitgevoerd.

30 Bij een uitvoeringsvorm van de uitvinding zouden de gebeurtenissequentie- knooppuntuitdrukking en de testknooppuntuitdrukking op een waarde tussen nul en één geëvalueerd kunnen worden, die uitdrukt tot welke graad wordt aangenomen dat de L ________ 10 uitdrukking “true” is. Een waarde in de nabijheid van één is dan “almost true” en een waarde in de nabijheid van nul “almost false”. De waarde zou als de waarschijnlijkheid ervoor geïnterpreteerd kunnen worden dat het gebeurtenissequentieknooppunt true is.

Het diagnoseknooppunt omvat een tekstbeschrijving, die specificeert wat foutief 5 is, wanneer de diagnose correct is. Of een diagnose correct is of niet, wordt onder gebruikmaking van de gebeurtenis-diagnose- en test-diagnose-afhankelijkheden geëvalueerd. Het resultaat is een waarde tussen nul en één, die als de waarschijnlijkheid ervoor geïnterpreteerd kan worden dat de diagnose correct is. Gebeurtenis-diagnose- en test-diagnose-afhankelijkheden hebben telkens twee eigenschappen, die in de evaluatie 10 worden opgenomen. De eerste eigenschap is de “polariteit” van de afhankelijkheid, dat wil zeggen of het resultaat van de evaluatie van een gebeurtenisknooppunt of test-knooppunt geïnverteerd dient te worden of niet. De tweede eigenschap is het gewicht van de afhankelijkheid. Bij bepaalde implementaties van de uitvinding (onder gebruikmaking van een Bayesiaans netwerk) kan het gewicht als de waarschijnlijkheid ervoor 15 worden geïnterpreteerd dat het gebeurtenisknooppunt of testknooppunt als true wordt geëvalueerd, wanneer de diagnose correct is. Daarbij dient eerst de polariteit in acht genomen te worden. In dit geval moet het gewicht tussen nul en één liggen. Er bestaat gewoonlijk meer dan één gebeurtenis-diagnose- en test-diagnose-afhankelijkheid voor elke diagnose.

20 Het reparatieknooppunt vertegenwoordigt een actie, waarvan wordt aangenomen dat deze het door een diagnoseknooppunt beschreven probleem oplost. Er zijn twee hoofdtypes van reparatieknooppunten, handmatig en automatisch. Het handmatige reparatieknooppunt is een tekstbeschrijving, die specificeert wat er gedaan moet worden om het probleem te corrigeren. Het automatische reparatieknooppunt vertegenwoordigt 25 een functie die door het systeem kan worden uitgevoerd om het probleem automatisch te corrigeren. De diagnose-reparatie-afhankelijkheid heeft een gewichtseigenschap. Bij bepaalde implementaties van de uitvinding kan het gewicht als de waarschijnlijkheid ervoor worden geïmplementeerd dat het reparatieknooppunt de correcte werkwijze voor het oplossen van het door de diagnose beschreven probleem vertegenwoordigt. Een 30 reparatieknooppunt kan de oplossing voor meer dan één diagnose zijn.

Een algoritme voor de uitvinding kan door een stroomschema worden beschreven (zie figuur 6). In een stap SI wacht het algoritme (bijvoorbeeld in een lus of asyn 11 chroon) op een volgende gebeurtenis of tot de gebruiker een handmatig testresultaat verandert. In een stap S2 wordt, wanneer de nieuwe gebeurtenis bewerkstelligt dat een willekeurig gebeurtenissequentieknooppunt zijn waarde verandert of wanneer een handmatig testresultaat werd veranderd, de volgende stap S3 uitgevoerd en anders keert i | 5 het algoritme terug naar de stap S1.

In de stap S3 berekent het algoritme de waarschijnlijkheid ervoor dat elk van de diagnoses correct is. Een bijzonder geschikte werkwijze daarvoor is het model van het Bayesiaanse netwerk. In een stap S4 zoekt het algoritme, wanneer geen enige sluitende diagnose gevonden kan worden, naar onbeantwoorde tests voor de diagnosekandidaten; 10 anders gaat het algoritme over naar stap S7.

In een stap S5 voert het algoritme eventuele gekozen automatische tests uit en in een stap S6 presenteert hij aan de gebruiker de handmatige tests, die het waarschijnlijkst tussen de diagnosekandidaten worden onderscheiden.

In een stap S7 presenteert het algoritme aan de gebruiker de diagnosekandidaten, 15 mogelijkerwijs met hun betreffende waarschijnlijkheid. In een stap S8 berekent het algoritme de waarschijnlijkheid ervoor dat elk van de reparatieacties geschikt is. In een stap S9 voert het algoritme alle automatische reparatieacties met een waarschijnlijkheid boven een bepaalde drempel uit. In een stap S10 presenteert het algoritme aan de gebruiker de waarschijnlijkste reparatieactie, mogelijkerwijs met hun betreffende waar-20 schijnlijkheid. Het totale proces wordt dan herhaald.

Verschillende uitvoeringsvormen van de hierboven beschreven uitvinding worden het best aan de hand van een voorbeeld uiteengezet.

Figuur 3 toont een voorbeeld ervoor hoe gebeurtenisssen in het systeem worden gegenereerd en behandeld. Gebeurtenissen worden door softwaremodules 14 (ml, m2, 25 m3, m5, m8) gegenereerd en chronologisch in de interne gebeurtenisprotocollering 20A

opgeslagen. Op grond van de softwarestructuur kan één enkel probleem meerdere gebeurtenissen veroorzaken. Wanneer bijvoorbeeld een probleem met oorsprong uit de hardwarecomponent cl (gedetecteerd door c5) bestaat, zou dit eerst door de software-module ml herkend kunnen worden, die de gebeurtenis el2 genereert. De softwaremo-30 dule m2 hangt af van het resultaat van ml en kan bij het gegeven probleem zijn werk niet verrichten; daarom genereert de module m2 dan de gebeurtenis e4. Op soortgelijke wijze hangt de softwaremodule m3 af van het resultaat van de module m2 en genereert 12 hij bij het gegeven probleem de gebeurtenis e6. Al deze gebeurtenissen worden in de interne gebeurtenisprotocollering 20A opgeslagen.

Het gebeurtenisfilter 32 filtert de gebeurtenissen, voordat ze aan de gebruikersge-beurtenisprotocoHering 20B worden toegevoerd. Zoals in figuur 3 is weergegeven, laat 5 het filter 32 eerst slechts de foutgebeurtenissen door. Ten tweede werd de foutgebeur-tenis c2 automatisch door de succesgebeurtenis e5 bevestigd.

Figuur 4 toont een voorbeeld voor een gebruikt model. Onder de aanname van een implementering met Bayesiaans netwerk toont figuur 4 bijvoorbeeld dat de gebeurtenissequentie enl een optreedwaarschijnlijkheid van 0,7 heeft, wanneer de diagnose 10 dl correct is. Op soortgelijke wijze heeft de gebeurtenissequentie en2 een optreedwaarschijnlijkheid van 0,8, wanneer de diagnose dl correct is. Doordat de diagnose dl correct is, heeft de test tl een waarschijnlijkheid van 0,9, wanneer de test positief is, en de test t2 de waarschijnlijkheid 0,9, wanneer de test negatief is.

Op soortgelijke wijze is de reparatieactie rl met een waarschijnlijkheid van 0,8 15 gepast, wanneer de diagnose dl correct is. Bepaalde reparatieacties kunnen voor meer dan één diagnose gemeenschappelijk zijn. Een dergelijke gemeenschappelijk benutte reparatieactie is in het bijzonder relevant in gevallen, wanneer geen beslissende diagnose gevonden kan worden, wanneer echter de in aanmerking komende diagnoses dezelfde reparatieacties hebben.

20 Figuur 5 toont een mogelijk gebruikersoppervlak dat gebruikt kan worden. In aanvulling op de gebruikersgebeurtenisprotocollering 20B is een afzonderlijke diagno-setabel 36 getoond, die diagnoseberichten dl, d2 mogelijkerwijs met de waarschijnlijkheid van een correcte diagnose omvat en waarin handmatige tests dl, d2, beschikbaar gesteld kunnen worden, om de waarschijnlijkheid van een correcte diagnose te verbete-25 ren. De tests tl, t2 kunnen bijvoorbeeld direct in de tabel 36 door selecteren van de overeenkomstige selectie worden beantwoord. De diagnosetabel 36 kan worden geactualiseerd, wanneer gebeurtenissequentieknooppunten de waarde veranderen of wanneer handmatige tests worden beantwoord.

Voor een beter begrip van de principes van de uitvinding werd verwezen naar de 30 in de tekeningen weergegeven voorkeursuitvoeringsvormen, en er werd specifieke taal voor het beschrijven van deze uitvoeringsvormen gebruikt. Door deze specifieke taal is echter geen beperking van de beschermingsomvang van de uitvinding beoogd, en de 13 uitvinding dient zodanig opgevat te worden, dat ze alle uitvoeringsvormen omsluit, die normaliter de gemiddelde vakman zouden invallen.

De onderhavige uitvinding kan met het oog op fiinctieblokcomponneten en ver-j schillende verwerkingsstappen worden beschreven. Dergelijke functieblokken kunnen 5 door een willekeurig aantal hardware- en/of softwarecomponenten worden gerealiseerd, die zodanig worden geconfigureerd dat ze de gespecificeerde functies uitvoeren. Bijvoorbeeld kan de onderhavige uitvinding verschillende geïntegreerde schakelingscom-ponenten gebruiken, zoals bijvoorbeeld geheugenelementen, verwerkingselementen, logische elementen, naslagtabellen en dergelijke, die onder de besturing van een of 10 meer microprocessoren of andere besturingsinrichtingen veelvoudige functies kunnen uitvoeren. Wanneer de elementen van de onderhavige uitvinding onder gebruikmaking van softwareprogrammering of software-elementen worden geïmplementeerd, kan de uitvinding op soortgelijke wijze ook onder gebruikmaking van een willekeurige programmeer- of scripting-taal worden geïmplementeerd, zoals bijvoorbeeld C, C++, Java, 15 Assembler of dergelijke, waarbij de verschillende algoritmen met een willekeurige combinatie van datastructuren, objecten, processen, routines of andere programmeer-elementen worden geïmplementeerd. Verder zou de onderhavige uitvinding een willekeurig aantal gebruikelijke technieken voor elektronische configuratie, signaalverwerking en/of besturing, dataverwerking en dergelijke kunnen gebruiken.

20 De hier getoonde en beschreven concrete implementeringen zijn veraanschouwe lijkende voorbeelden voor de uitvinding en dienen de beschermingsomvang van de uitvinding verder op generlei wijze te beperken. Kortheidshalve worden gebruikelijke elektronica, besturingssystemen, software-ontwikkeling en andere functionele aspecten van het systeem (en de componenten en afzonderlijke bedrijfscomponenten van het 25 systeem) mogelijkerwijs niet uitvoerig beschreven. De in de verschillende figuren getoonde verbindingslijnen of verbindingen dienen bij wijze van voorbeeld gegeven functionele verhoudingen en/of fysieke of logische koppelingen tussen de verschillende elementen te vertegenwoordigen. Er dient op gelet te worden dat in een praktische inrichting veel alternatieve of aanvullende functionele verhoudingen, fysieke verbindin-30 gen of logische verbindingen aanwezig kunnen zijn. Geen element of geen component is voor de uitoefening van de uitvinding wezenlijk, wanneer niet het element specifiek als “wezenlijk” of “kritisch” wordt beschreven. Talrijke modificaties en aanpassingen 14 zullen aan vakmensen zonder meer duidelijk zijn, zonder van de gedachte en bescher-mingsomvang van de onderhavige uitvinding af te wijken.

103 0 o 5 9

Claims (14)

1. Werkwijze voor isoleren van een hardware- of gebruikersfout en voor het uitkiezen van een geschikte reparatieactie in een softwaregestuurde inrichting onder gebruikma-5 king van geregistreerde gebeurtenissen en een causaliteitsmodel, dat ten minste één hoofdoorzaak met ten minste één patroon van de gebeurtenissen in verband brengt, dat met hoofdoorzaken in verband staat, waarbij ten minste een van de met hoofdoorzaken samenhangende patronen met waarschijnlijkheidsfactoren voor meer dan één hoofdoorzaak samenhangt, waarbij het causaliteitsmodel aanvullend ten minste één repara-10 tieactie omvat, die via waarschijnlijkheidsfactoren met ten minste één van de hoofdoorzaken samenhangt, met de volgende werkwijzestappen: - registreren van een reeks gebeurtenissen; - evalueren van de reeks gebeurtenissen door vergelijken van deze reeks met ten minste één van de met hoofdoorzaken samenhangende patronen; 15. bepalen van dat patroon, dat het beste met de reeks overeenstemt; - isoleren van de aan de fout ten grondslag liggende hoofdoorzaak door evaluatie van de waarschijnlijkheidsfactoren; en - uitkiezen van ten minste een reparatieactie op basis van het patroon, de hoofdoorzaken en de waarschijnlijkheidsfactoren. 20

2. Werkwijze volgens conclusie 1, waarbij een van de met hoofdoorzaken samenhangende patronen ten minste een foutgebeurtenis, informatiegebeurtenis en/of succesgebeurtenis is.

3. Werkwijze volgens conclusie 1 of 2, met de volgende aanvullende werkwijze stappen: - verkrijgen van door een gebruiker beschikbaar gestelde aanvullende informatie door interactie met een gebruiker; en - gebruiken van de door de gebruiker beschikbaar gestelde aanvullende informatie in 30 een van de met hoofdoorzaken samenhangende patronen. 1030059

4. Werkwijze volgens een van de vorige conclusies, met de volgende aanvullende werkwij zestappen: - verkrijgen van door een test beschikbaar gestelde aanvullende informatie door testen van de inrichting met ten minste één testroutine; en 5. gebruiken van de door de test beschikbaar gestelde aanvullende informatie in een van de met hoofdoorzaken samenhangende patronen.

5. Werkwijze volgens een van de vorige conclusies, waarbij ten minste één van de reparatieacties met waarschijnlijkheidsfactoren voor meer dan één hoofdoorzaak 10 samenhangt.

6. Werkwijze volgens een van de vorige conclusies, waarbij ten minste één van de hoofdoorzaken met waarschijnlijkheidsfactoren voor meer dan één reparatieactie samenhangt. 15

7. Werkwijze volgens een van de vorige conclusies, waarbij de gekozen reparatieactie automatisch wordt uitgevoerd.

8. Werkwijze volgens een van de conclusies 1 tot en met 6, waarbij de gebruiker 20 wordt gevraagd de gekozen reparatieactie handmatig uit te voeren.

9. Werkwijze volgens een van de vorige conclusies, waarbij een Bayesiaans netwerk voor het bepalen van een weging van waarschijnlijkheidsfactoren wordt gebruikt.

10. Werkwijze volgens een van de vorige conclusies, waarbij een gebeurtenisfil ter voor het filteren van aan een gebruiker te presenteren gebeurtenissen wordt gebruikt.

11. Systeem voor isoleren van een hardware- of gebruikersfout en voor het uit- 30 kiezen van een geschikte reparatieactie in een softwaregestuurde inrichting, omvattend: - een gebeurtenisprotocollering, waarin gebeurtenissen van de inrichting worden geregistreerd; ! - een tabel met een lijst van mogelijke hoofdoorzaken voor verschillende problemen of toestanden; - een tabel met reparatieacties; - een diagnosemodule, die zodanig is geconfigureerd dat deze een causaliteitsmodel 5 implementeert, dat ten minste één hoofdoorzaak uit de tabel met ten minste één met een hoofdoorzaak via waarschijnlijkheidsfactoren samenhangend patroon van gebeurtenissen door genereren van aangepaste, met hoofdoorzaken samenhangende patronen voor een reeks gebeurtenissen, isoleren van de aan de fout ten grondslag liggende hoofdoorzaak door evaluatie van de waarschijnlijkheidsfactoren in verband brengt en verder ten 10 minste een van de reparatieacties, die via waarschijnlijkheidsfactoren met ten minste een van de hoofdoorzaken samenhangen, op basis van het patroon, de hoofdoorzaken en de waarschijnlijkheidsfactoren uitkiest.

12. Systeem volgens conclusie 11, waarbij een Bayesiaans netwerk een deel van 15 de diagnosemodule is, die zodanig is geconfigureerd dat deze een weging van waarschijnlijkheidsfactoren bepaalt.

13. Systeem volgens conclusie 11 of 12, waarbij de gebeurtenisprotocollering een interne gebeurtenisprotocollering, en 20 een gebruikersgebeurtenisprotocollering heeft en waarbij het systeem verder het volgende omvat: een gebeurtenisfilter, dat de interne gebeurtenisprotocollering filtert, om de gebruikers-gebeurtenisprotocollering te genereren.

14. Systeem volgens een van de conclusies 11 - 13, waarbij de tabel geautomati seerde reparatiemodules heeft, die zodanig zijn geconfigureerd dat ze de reparatieacties uitvoeren. 1 03 0 05 9 *