Autonoom beheerplatform voor de detectie van fouten in...

Jochen Firey

in gedistribueerde klinische systemenAutonoom beheerplatform voor de detectie van fouten

Academiejaar 2011-2012Faculteit Ingenieurswetenschappen en ArchitectuurVoorzitter: prof. dr. ir. Daniël De ZutterVakgroep Informatietechnologie

Master in de ingenieurswetenschappen: computerwetenschappen Masterproef ingediend tot het behalen van de academische graad van

Begeleiders: Kristof Steurbaut, Femke De Backere, Jeroen FamaeyPromotoren: prof. dr. ir. Filip De Turck, Steven Latré

Voorwoord

In de huidige samenleving zijn computers niet meer weg te denken. Toch zijn deze systemen

niet perfect en is er veel ruimte voor verbetering. Het meer autonoom maken van systemen,

alsook het introduceren van meer intelligentie via verschillende technieken, is een trend die

meer en meer aan belang wint, en dit binnen zowat iedere sector.

Tijdens deze thesis proefde ik van deze trend door een bestaand systeem meer autonoom te ma-

ken, gebruik makende van enkele machinelearning technieken. Het gaf me een dieper inzicht

in de problemen die computersystemen en hun beheerders of gebruikers de dag van vandaag

het leven moeilijk maken. Ook raakte ik meer vertrouwd met technieken voor het bereiken van

intelligentie, hun toepassingen en hun tekortkomingen. Ik kreeg me de mogelijkheid dingen te

leren die in de opleiding niet of in mindere mate aan bod komen.

Vooreerst wil ik mijn begeleiders -Femke De Backere, Kristof Steurbaut, Jeroen Famaey en

een van mijn promotoren, Steven Latre- bedanken voor hun deskundige hulp tijdens deze

masterproef. Met hun expertise op verschillende vlakken (zoals e-health, autonome systemen

en machinelearning), hielpen ze mij deze masterproef van begin tot einde in de goede richting

te sturen. Ze stonden steeds klaar om mij te helpen als ik problemen had met zaken waar zij

meer ervaring mee hadden. Ze investeerden veel tijd in mij en mijn masterproef om deze tot

een goed einde te brengen.

Verder zou ik graag mijn promotoren Filip De Turck en Steven Latre willen bedanken voor de

geboden kans op deze thesis. Ook alle mensen die mij, direct of indirect, hielpen bij deze thesis

en die niet bij naam vernoemd werden, zou ik graag bedanken. Met alle input die ik ontving,

kreeg mijn masterproef iets meer vorm, tot het uiteindelijk werd wat hier in deze scriptie

beschreven wordt: een succesvolle eerste stap richting autonomie van kritische systemen.

Jochen Firey, juni 2012

IV

Toelating tot bruikleen

”De auteur geeft de toelating deze masterproef voor consultatie beschikbaar te stellen en

delen van de masterproef te kopieren voor persoonlijk gebruik. Elk ander gebruik valt onder

de beperkingen van het auteursrecht, in het bijzonder met betrekking tot de verplichting

de bron uitdrukkelijk te vermelden bij het aanhalen van resultaten uit deze masterproef.”

Jochen Firey, juni 2012

V

Autonoom beheerplatform voor

de detectie van fouten in

gedistribueerde klinische systemen

door

Jochen Firey

Promotoren: Prof. dr. ir. Filip De Turck, dr. Steven Latre

Begeleiders: Kristof Steurbaut, ir. Femke De Backere, Jeroen Famaey

Masterproef ingediend tot het behalen van de academische graad van

Master in de ingenieurswetenschappen: computerwetenschappen

Faculteit Ingenieurswetenschappen

Universiteit Gent

Vakgroep Informatietechnologie

Voorzitter: prof. dr. ir. Daniel De Zutter

Faculteit Ingenieurswetenschappen en Architectuur

Academiejaar 2011–2012

Samenvatting

In dit werk wordt getracht een eerste stap te zetten naar totale autonomie van kritischegedistribueerde systemen. Kritische systemen zijn systemen die, ingeval van falingen, de-sastreuze gevolgen kunnen hebben. Een beheerplatform wordt ontwikkeld om bovenop eenbestaand systeem te draaien en fouten te detecteren, te classificeren en te rapporteren aaneen beheerder. Het beheerplatform wordt geevalueerd met behulp van een emulator van eenpatient-monitoring systeem. Dit is een systeem dat de laatste jaren meer en meer aan belangwint binnen de e-health sector en dat patienten thuis of in een ziekenhuis opvolgt en gegevensdoorstuurt naar medisch personeel of een dokter. Bij de evaluatie van het beheerplatformwerd geconcludeerd dat deze aanpak zeer snel en efficient werkt.

Trefwoorden

beheerplatform, e-health, foutdetectie, autonoom, kritische systemen

Autonomous management platform for detection oferrors in distributed clinical systems

Jochen Firey

Supervisor(s): prof. dr. ir. Filip De Turck, dr. Steven Latre,Kristof Steurbaut, ir. Femke De Backere, Jeroen Famaey

Abstract—This article introduces a management platform for detectionand classification of errors in critical distributed systems. Critical systemsare systems which, when they fail, can have disastrous consequences. Withthis management platform, a first step towards complete autonomy of criti-cal systems is taken. With this approach, errors can be found very fast andadministrators no longer have to search for the specific error that causedthe system to malfunction. This approach has been tested on an emulationof a patient-monitoring system, an upcoming technology in the e-health sec-tor. During evaluation of the management platform it was concluded thatthis approach works very fast and efficient.

Keywords— Management platform, e-health, detection of errors, auto-nomic, critical systems

I. INTRODUCTION

THE biggest problem with computer systems nowadays isthe occurrence of errors. There is hardly any computer

systems which is perfect. In some cases, this is of little con-sequence. However, in most cases errors could endanger lives.One such case is a patient-monitoring system. Such a systemmonitors patients in a hospital or at home, and its results are sentto the medical staff or a doctor. When an error occurs in such asystem, patient lives could be at risk. The monitored data couldbe false, it could fail to reach the responsible personnel and soon. To prevent these errors from going by unnoticed, this paperintroduces a management platform which monitors the systemand discovers, classifies and reports errors to an administrator.

II. MANAGEMENT PLATFORM

Fig. 1MANAGEMENT PLATFORM

The management platform consists of three major compo-nents. First, there is an event channel, which ensures datacompression and encryption and which relays requests and re-sponses to the correct components. The second component isa heartbeat component. Components of the managed systemmust regularly send a heartbeat to the management platform.In this manner, the platform can gather information on the sys-tem. In the first heartbeat message, the sending component mustalso specify which other components it needs during execution.

Hence, the management platform can construct a logical topol-ogy of the underlying system. The third and most importantcomponent is the reasoner. This component calls the event chan-nel on a regular basis to get information on all registered com-ponents of the managed system. This information, combinedwith the logical topology, is used by the reasoning componentto discover, classify and report errors to an administrator.

For this approach to work, the managed system must imple-ment two things:• A heartbeat system must be implemented as explained above.• Logging must be provided. The system must log importantevents, so the management platform can use this information todiscover and classify errors. Also, it must be possible for themanagement platform to retrieve this information.

III. REASONER

The reasoner is constructed as a MAPE control loop [1]. First,there is a monitor component, which receives information fromthe heartbeat module on all registered components. It calls theevent channel periodically to retrieve information on the un-derlying system. When the heartbeat module reports a failingheartbeat, the monitor also retrieves information from the sys-tem. This information retrieval triggers the diagnosis of themanaged system. The retrieved information is sent to a systemanalysis component which discovers and delimits errors, with-out knowing which error occurred. This information is sent toan error/cause detection module, which analyses the errors andclassifies them into categories. These two components composethe analysis step of the MAPE control loop. The plan and exe-cution steps are not implemented, since solving the errors is stilldone manually by an administrator. To this end, the calculatedinformation is sent to a reporting module and reported to theadministrator.

A. Rule-based analysis component

The analysis component discovers and delimits errors. Sinceerrors and the way they can be discovered are different foreach different system to be managed, this functionality is im-plemented using a rule-based system. This has been done usingthe drools library [2]. This library enables specifying and usingrules and to alter them at runtime. The rules must be createdspecifically for the managed system. No changes to this com-ponent are necessary otherwise. This is one of the advantagesof this approach. The main advantage, however, lies in the factthat it can be altered at runtime. If the discovery of errors isimperfect, or changes in the system require changes to the de-tection of errors, the rules can be altered without reinitializing

the managed system or the management platform. However, itshould be noted that changing the rules can have an influence onthe further processing of the errors. More information on how toimplement these rules can be found in the drools documentation[2].

B. Bayesian detection component

When the analysis component has finished its diagnosis, theinformation on the discovered errors is passed to the detectioncomponent. Here the errors are classified into categories. Tothis end, a naive Bayesian network is used. This technique is de-rived from Bayesian spam filters to filter SPAM email [3]. Theconstructed Bayesian network looks like the example in Figure2. The lower nodes hold the observations (different words) con-

Fig. 2NAIVE BAYESIAN NETWORK

tained in the logs and not filtered out by the analysis component.It contains evidence to classify the occurred error. In each node,the frequency of the observation belonging to the node is con-tained. The upper node contains all possible errors and definesthe influence of the observations to this error. The network isconstructed using a training set which is specifically made forthe managed system. For each new system, a new training setmust be made. Other than that, no changes are needed to thiscomponent.

For this technique to work, three adaptations are made to thetraditional spam filtering technique:• Discretisation of continuous variables. Since text classifica-tion is used, each different value is translated to a different nodein the network. To limit the number of different values, discreti-sation is applied.• Delimiting start and end of an error. In spam filtering, eachemail has a clear beginning and end. Errors, however, can stillcontinue after information is retrieved from the system. Becauseof this, errors can contain too little information for the classifierto predict the correct category. Therefore, information on con-tinuing errors is retained and used again in the next iteration.• The classification process of the Bayesian network is also al-tered. In spam filtering, the result of the network is either SPAMor no SPAM. Here, multiple errors can occur at the same time.Therefore, thresholds are used. If a probability of an occurringerror is higher than this threshold, the error is marked as a pos-sible occurrence. In this manner, multiple errors can be found,each with their respective probability. The thresholds are calcu-lated per error automatically using the Youden index [4].

IV. EVALUATION

The efficiency of the management platform was evaluated us-ing an emulation of a patient-monitoring system. This systemconsists of three services to monitor the patient, namely the

blood pressure, heartbeat and temperature. This info is sent toa central service, which uses an external database to calculatethe health of the patient. Also, a medication service is in place,which uses the blood pressure of patients and information fromthe external database to calculate if the patient needs changes inmedication. This information is also sent to the central service.

In this emulator, several errors can be simulated, starting fromsensor failures, to database and network problems. Since therule-based system can be directly influenced, it is possible todetect and delimit all errors. It is, however, not always possibleto separate errors from each other. If they occur in neighbouringcomponents at the same time, it is seen as a single error ratherthan two distinct errors.

The efficiency of the Bayesian network is depicted in Fig-ure 3. It shows a ROC-curve of the classification of a singleerror (full line), two concurrent errors (dashed line) and threeconcurrent errors (dotted line). In the optimal point (left upper

Fig. 3ROC CURVE FOR SINGLE AND MULTIPLE ERRORS

corner), the curve of a single error is nearly perfect. Multiple er-rors cannot be classified well. The efficiency drops very rapidly.However, after extensive testing on the emulator, it was foundthat even for multiple errors, there is nearly always one cor-rectly found. Therefore, multiple errors can be removed fromthe system one by one, in subsequent iterations.

V. CONCLUSION

This paper proposed a first step towards autonomy of criticalsystems by autonomously discovering, classifying and reportingerrors. The results show that this approach works very well. Ofcourse, a lot of work still needs to be done in order to completethe system. Methods for improving efficiency and automaticerror resolving are the first of many. Still, the first step towardsautonomy can be called a success.

REFERENCES

[1] Christine Draper. Combine autonomic computing and soa to improve itmanagement. http://www.ibm.com/developerworks/webservices/library/-ac-mgmtsoa/index.html, April 2006.

[2] JBoss Community. Drools expert user guide. http://docs.jboss.org/drools/-release/5.2.0.Final/drools-expert-docs/html/ch05.html, june 2011.

[3] Ion Androutsopoulos, John Koutsias, Konstantinos Chandrinos, Geor-gios Paliouras and Constantine D. Spyropoulos. An evaluation of NaiveBayesian anti-spam filtering CoRR, cs.CL/0006013, 2000.

[4] Mark J. Kelly, Frank D. Dunstan, Keith Lloyd, and David L. Fone. Evaluat-ing cutpoints for the mhi-5 and mcs using the ghq-12: a comparison of fivedifferent methods. BMC Psychiatry, 8, 2008.

Inhoudsopgave

Voorwoord V

Overzicht VIII

Abstract IX

Inhoudsopgave XI

Lijst van figuren XV

Lijst van tabellen XVII

Lijst van listings XIX

1 Inleiding 1

1.1 Context . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.2 Probleemstelling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.3 Doelstelling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2 Literatuurstudie 5

2.1 Autonome systemen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.1.1 Wat is een autonoom systeem . . . . . . . . . . . . . . . . . . . . . . . 5

2.1.2 Autonome eigenschappen . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.1.3 Architectuur van een autonoom systeem . . . . . . . . . . . . . . . . . 7

2.1.4 Busstructuur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.1.5 Autonoom maturiteitsniveau . . . . . . . . . . . . . . . . . . . . . . . 12

2.1.6 Voorbeelden van autonome systemen . . . . . . . . . . . . . . . . . . . 13

2.2 E-health systemen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.2.1 Introductie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.2.2 Autonome e-health systemen in de praktijk . . . . . . . . . . . . . . . 16

2.3 Kennismodellering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.3.1 Regelgebaseerde systemen . . . . . . . . . . . . . . . . . . . . . . . . . 17

IX

Inhoudsopgave X

2.3.2 Bayesiaanse netwerken . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

2.3.3 Classificatie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

2.3.4 Clustering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

2.3.5 Case-based reasoning . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

2.3.6 Hidden Markov models . . . . . . . . . . . . . . . . . . . . . . . . . . 26

2.3.7 Beslissingsbomen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

2.4 Besluit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

3 Use case 33

3.1 Patient-monitoring systeem . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

3.2 Beheerplatform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

3.2.1 Architectuur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

4 Oorzaakdetectie 41

4.1 Architectuur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

4.2 Werking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

4.2.1 Monitor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

4.2.2 System analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

4.2.3 Error/cause detection . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

4.2.4 Reporting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

4.2.5 Action execution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

4.3 Regelgebaseerde analysecomponent . . . . . . . . . . . . . . . . . . . . . . . . 49

4.4 Bayesiaanse detectiecomponent . . . . . . . . . . . . . . . . . . . . . . . . . . 52

4.4.1 Drempelwaardebepaling . . . . . . . . . . . . . . . . . . . . . . . . . . 56

5 Evaluatie 61

5.1 Emulator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

5.1.1 Architectuur en werking . . . . . . . . . . . . . . . . . . . . . . . . . . 61

5.1.2 Topologie en technologie . . . . . . . . . . . . . . . . . . . . . . . . . . 65

5.1.3 Mogelijke fouten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

5.2 Evaluatie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

5.2.1 Regelgebaseerde analysecomponent . . . . . . . . . . . . . . . . . . . . 66

5.2.2 Bayesiaanse detectiecomponent . . . . . . . . . . . . . . . . . . . . . . 70

5.2.3 Invloed van het beheerplatform op de gebruikte bandbreedte . . . . . 87

5.2.4 Besluit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

6 Conclusie en perspectieven 91

6.1 Conclusie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

6.2 Mogelijke uitbreidingen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93

Inhoudsopgave XI

Bibliografie 95

Lijst van figuren

2.1 MAPE controlelus [13] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.2 Architectuur van een autonoom element met een busstructuur [27] . . . . . . 9

2.3 OODA controlelus [8] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.4 FOCALE controlelus [2] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.5 Maturiteitsniveaus van een systeem [9] . . . . . . . . . . . . . . . . . . . . . . 13

2.6 Forward chaining [18] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

2.7 Backward chaining [18] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

2.8 CBR cyclus [1] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

2.9 Voorbeeld van een beslissingsboom [4] . . . . . . . . . . . . . . . . . . . . . . 28

3.1 Schematische voorstelling van een patient-monitoring systeem . . . . . . . . . 34

3.2 Architectuur van het beheerplatform . . . . . . . . . . . . . . . . . . . . . . . 37

4.1 Architectuur van de redeneercomponent . . . . . . . . . . . . . . . . . . . . . 42

4.2 Logische topologie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

4.3 Visuele representatie van het beheerde systeem . . . . . . . . . . . . . . . . . 48

4.4 Rapportering van fouten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

4.5 Naıef Bayesiaans netwerk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

4.6 Grafisch overzicht tot het bepalen van de Youden index [23] . . . . . . . . . . 57

5.1 Overzicht van de werking van de emulator . . . . . . . . . . . . . . . . . . . . 62

5.2 Topologie van de emulator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

5.3 Tijd nodig voor het opbouwen van het Bayesiaans netwerk in functie van de

grootte van de trainingsset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

5.4 Tijd nodig voor het opbouwen van het Bayesiaans netwerk voor 1000 trainings-

instanties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

5.5 Tijd nodig voor het gebruiken van het Bayesiaans netwerk in functie van het

aantal verschillende observaties in een te classificeren instantie . . . . . . . . 73

5.6 ROC-curve voor meerdere onafhankelijke gelijktijdige fouten aanzien als een

fout door het regelgebaseerd systeem . . . . . . . . . . . . . . . . . . . . . . . 74

XII

Lijst van figuren XIII

5.7 Precision en recall in functie van het aantal gelijktijdige fouten voor drempel-

waarden van 25 en 85 % . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

5.8 ROC-curve bij geen discretisatie en een intervalgrootte van 100 . . . . . . . . 77

5.9 Precision bij geen discretisatie en een intervalgrootte van 100 voor verschillende

drempelwaarden . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

5.10 Recall bij geen discretisatie en een intervalgrootte van 100 voor verschillende

drempelwaarden . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

5.11 Invloed van de discretisatie op de grootte van het netwerk . . . . . . . . . . . 79

5.12 Invloed van de discretisatie op het aantal verschillende observaties in een te

classificeren instantie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

5.13 Invloed van de granulariteit van fouten op de precision en recall . . . . . . . 83

5.14 Bandbreedte nodig voor de emulator zonder het beheerplatform, van het be-

heerplatform apart en in totaal . . . . . . . . . . . . . . . . . . . . . . . . . . 88

5.15 Fractie van de bandbreedte gebruikt voor het beheerplatform . . . . . . . . . 89

Lijst van tabellen

2.1 Score van de verschillende technieken voor foutdetectie . . . . . . . . . . . . . 30

2.2 Score van de verschillende technieken voor foutclassificatie . . . . . . . . . . . 31

4.1 Verwerkte observaties voor het Bayesiaans netwerk . . . . . . . . . . . . . . . 56

5.1 Samenvatting van welke fouten met welke regels ontdekt worden . . . . . . . 68

5.2 Invloed van de grootte van het netwerk op de classificatietijd van instanties . 73

5.3 Invloed van de discretisatie op de classificatietijd van instanties . . . . . . . . 80

5.4 Fouten bij verschillende granulariteiten . . . . . . . . . . . . . . . . . . . . . . 82

5.5 Efficientie van het Bayesiaans netwerk voor enkelvoudige fouten . . . . . . . . 84

5.6 Efficientie van het Bayesiaans netwerk voor meervoudige fouten . . . . . . . . 86

XIV

Lijst van listings

4.1 Loginformatie van de bloeddruksensor . . . . . . . . . . . . . . . . . . . . . . 45

4.2 Loginformatie van de medicatieservice . . . . . . . . . . . . . . . . . . . . . . 46

4.3 Voorbeeld van een functie gebruikt in de thesis . . . . . . . . . . . . . . . . . 50

4.4 Voorbeeld van een regel gebruikt in deze thesis . . . . . . . . . . . . . . . . . 51

5.1 Regel in CSV-bestand . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

5.2 Vorm van de loginformatie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

5.3 Regel en hulpmethode om fouten samen te nemen . . . . . . . . . . . . . . . 69

XV

Hoofdstuk 1

Inleiding

Computersystemen worden steeds ingewikkelder en staan aan vele gevaren bloot: fouten (on-

gelukken of met opzet), virusinfecties, kwaadaardige aanvallen, illegale inbraken en natuur-

rampen zijn enkele voorbeelden. Grote computersystemen zijn zeer dikwijls gedistribueerd

van aard, wat ervoor zorgt dat er nog meer soorten fouten geıntroduceerd kunnen worden

en dat de andere fouten en hun invloed nog complexer worden. Dit heeft als gevolg dat

eigenschappen als betrouwbaarheid, veiligheid en zelfstandigheid, zeker bij gedistribueerde

systemen, een steeds belangrijkere rol spelen. Er is dus nood aan systemen die bescherming

bieden tegen (een subset van) deze problemen. Het doel van dergelijke systemen is het aanbie-

den van services die onder andere autonoom, betrouwbaar, veilig, voorspelbaar en duurzaam

zijn. Dergelijke systemen worden veelal ontwikkeld met behulp van het autonomic compu-

ting paradigm, dat ervoor zorgt dat deze systemen zichzelf kunnen beheren door middel van

zelfoptimalisatie, zelfgenezing, zelfconfiguratie en zelfbescherming [19].

Systemen ontwikkeld met behulp van het autonomic computing paradigm worden autonome

systemen genoemd en krijgen een steeds belangrijkere rol in de wereld van computertechno-

logie. Hoewel het concept redelijk eenvoudig is, blijkt de uitvoering van dergelijke systemen

allesbehalve een triviale zaak. Er is al veel onderzoek gedaan om robuuste en betrouwbare

autonome systemen te ontwikkelen, maar vooraleer deze wereldwijd gebruikt kunnen worden

moet er nog veel onderzoek gebeuren. Het concept van autonome systemen laat toe om vei-

lige en betrouwbare systemen te introduceren, door ervoor te zorgen dat ze zichzelf kunnen

beheren. Om dit zelfbeheer op een zo efficient mogelijke manier te kunnen implementeren,

moet er nog verder onderzoek gebeuren in technologie van autonome systemen. Anderzijds

moet een autonoom systeem ook betrouwbaar zijn om ervoor te zorgen dat dergelijke sys-

temen de controle niet verliezen en dat ze niet falen. Voor het ontwikkelen van veilige en

autonome systemen en communicatietechnieken zijn synergetische onderzoeksinspanningen

nodig in een groot aantal disciplines, varierend van informatica tot natuurwetenschappen en

sociale wetenschappen [10].

1

Hoofdstuk 1. Inleiding 2

1.1 Context

In deze thesis wordt een specifiek type van computersystemen bekeken. Het systeem bevindt

zich in de sector van de e-health, een recent opkomende sector waarbij medische diensten

worden aangeboden, gebruik makend van het internet en aanverwante technologieen. De spe-

cifieke toepassing die in deze thesis behandeld wordt, is deze van een systeem dat patienten

opvolgt, berekeningen uitvoert om na te gaan of de patient nog in een gezonde toestand

verkeert en iemand waarschuwt als dit niet (meer) het geval is. Dergelijke systemen komen

meer en meer voor. Enerzijds in ziekenhuizen, waar er meer en meer elektronisch gewerkt

wordt en waarbij data over patient-monitoring naar een centrale plaats gestuurd wordt voor

verwerking en opslag. Anderzijds ook buiten ziekenhuizen zoals bijvoorbeeld bij telemonito-

ring. Patienten zijn dan veelal thuis en hun monitorgegevens worden naar een andere plaats

(bijvoorbeeld ziekenhuis of dokter) gestuurd.

1.2 Probleemstelling

Er zijn nogal wat problemen die met dergelijke systemen gepaard gaan. Zo kunnen er be-

paalde toestellen falen, kunnen er foute sensorwaarden gelezen worden bij de patient of kan

de data om een of andere reden niet gecommuniceerd worden tussen de zender en ontvanger.

Verschillende andere fouten kunnen ook voorkomen in verscheidene dergelijke systemen. In

normale systemen vormt dit een groot probleem. Het tijdsinterval tussen het optreden van

een fout en het oplossen ervan kan zeer groot zijn. Bepaalde fouten kunnen namelijk in het

systeem bestaan zonder dat het systeem faalt of zelfs zonder dat de externe gebruiker hiervan

op de hoogte is. Het kan dus zijn dat bepaalde fouten zeer lang blijven bestaan alvorens ze

gedetecteerd worden. Als ze dan opgespoord worden, is het onmogelijk om na te gaan hoe

lang ze zich in het systeem bevonden en welke invloed ze hadden. Bij systemen als hierboven

besproken is dit uiteraard niet te tolereren. Fouten moeten zo snel mogelijk gedetecteerd en

opgelost worden. Zo niet kunnen levens van patienten in gevaar komen.

Om voorgaande problemen te kunnen oplossen, worden autonome eigenschappen geıntrodu-

ceerd in het systeem. Dit zou een grote stap voorwaarts kunnen betekenen. Zelfconfiguratie

zou kunnen worden gebruikt om het systeem aan wijzigingen te kunnen aanpassen. Zelf-

genezing zou er voor kunnen zorgen dat het systeem kan herstellen van bepaalde fouten.

Zelfoptimalisatie zou kunnen helpen bij de dagelijkse werking, om sneller te werken en min-

der fouten te introduceren. Zelfbescherming zou kunnen aangewend worden om zich beter te

wapenen tegen fouten.

Hoofdstuk 1. Inleiding 3

1.3 Doelstelling

Alle voorzieningen voor autonomie in een keer implementeren gaat uiteraard niet. In deze

thesis wordt een eerste stap genomen naar het volledig autonoom maken van een patient-

monitoring systeem. Er zullen technieken aangewend worden om fouten te ontdekken en te

classificeren. Het doel van deze thesis is dus het ontwerpen van een autonoom beheerplatform

dat fouten in een patient-monitoring systeem ontdekt en de aard, locatie en tijdstip van de

fouten meedeelt aan een beheerder. Op die manier kunnen beheerders van dergelijke systemen

onmiddellijk op de hoogte gebracht worden van fouten in het beheerde systeem. Daarnaast

zullen ze ook informatie krijgen over het type fout, waar deze zich manifesteerde en wanneer

deze zich voordeed. Het patient-monitoring systeem en het beheerplatform worden besproken

in Hoofdstuk 3. Er wordt dieper ingegaan op de belangrijkste elementen van het beheerplat-

form in Hoofdstuk 4. Vervolgens wordt de implementatie van het beheerplatform geevalueerd

op een emulator van een patient-monitoring systeem. Deze emulator en de evaluatie komen

aan bod in Hoofdstuk 5. De thesis wordt afgesloten met een besluit in Hoofdstuk 6. Vooraleer

de implementatie en evaluatie aan bod komen, worden eerst enkele begrippen, technieken en

voorbeelden uit de praktijk besproken. Dit gebeurt in het volgende hoofdstuk (Hoofdstuk

2).

Hoofdstuk 2

Literatuurstudie

In deze thesis wordt een poging gedaan om een bestaand e-health systeem uit te breiden met

autonome eigenschappen tot het detecteren en classificeren van fouten om het leven van de

beheerder(s) van een dergelijk systeem te assisteren bij foutoplossing. Om deze reden worden

in de eerste sectie autonome systemen besproken. In het tweede deel komen e-health systemen

aan bod. In het derde stuk komen technieken aan bod die gebruikt kunnen worden om de

gewenste functionaliteit aan te reiken. De laatste sectie bevat een besluit waarin samengevat

wordt welke technieken specifiek gebruikt zullen worden.

2.1 Autonome systemen

Autonome systemen zijn systemen die ingezet worden om een bepaald doel te bereiken en

onafhankelijk van een menselijke input handelingen kunnen uitvoeren tot het behalen van

dit doel [39]. De naam ‘autonome systemen’ komt uit de biologie, van het begrip autonoom

zenuwstelsel. Dit is een systeem in het lichaam dat heel wat onbewuste activiteiten uitvoert.

Op deze manier hoeft men zich geen zorgen te maken om de snelheid van de hartslag, of de

ingewanden hun werk doen, . . . . Dit idee werd overgenomen in softwaresystemen die zichzelf

beheren (zoals bijvoorbeeld automatische foutdetectie en -oplossing en hogere efficientie van

dagelijkse taken) en een efficientere werking toelaten.

2.1.1 Wat is een autonoom systeem

IBM lanceerde het idee van autonome systemen in 2001. De conclusies van een studie gaven

aan dat er tegen 2010, 200 miljoen werknemers in de IT-sector nodig zouden zijn om alle

systemen te kunnen bemannen [12]. Deze hoeveelheid komt overeen met de ganse werkende

Amerikaanse bevolking. Uiteindelijk bleek deze studie het aantal werknemers te overschatten.

4

Hoofdstuk 2. Literatuurstudie 5

Desalniettemin is de nood aan autonome systemen groot. IBM definieerde dergelijke systemen

en gaf aan dat ze uit acht elementen moesten bestaan [20]:

• Een eigen identiteit bezitten: autonome systemen moeten gedetailleerde kennis hebben

over hun eigen componenten.

• Zelfconfiguratie en reconfiguratie: een autonoom systeem moet zich kunnen aanpassen

aan een veranderende omgeving, dikwijls opgelegd door regels opgesteld door een ope-

rator. Voorbeelden van dergelijke veranderingen zijn het verwijderen of wijzigen van

softwarecomponenten.

• Operaties optimaliseren: een autonoom systeem moet in staat zijn om zichzelf te opti-

maliseren zodat het aan de noden van de eindgebruikers kan voldoen. Een voorbeeld van

een mogelijke actie is het opnieuw toewijzen van resources. Het effect van een dergelijke

actie is het verbeteren van de operationele efficientie.

• Herstel: een autonoom systeem moet kunnen herstellen van fouten, zonder invloed uit

te oefenen op de aanwezige data of de uitvoerende verwerking.

• Zelfbescherming: een autonoom systeem moet zichzelf kunnen beschermen zodat de

dagelijkse operaties minder kans hebben op falen. Het moet anticiperen op, detecteren

van, identificeren van en beschermen tegen interne en externe bedreigingen. Voorbeeld

van dergelijke bedreigingen zijn onbevoegde toegang, virussen en Denial of Service aan-

vallen. Het effect is een hogere beveiliging.

• Bewust zijn van de omgeving en zich kunnen aanpassen: vooraleer zelfconfiguratie mo-

gelijk is, moet het systeem zich eerst bewust zijn van zijn omgeving.

• In een heterogene wereld kunnen werken: een autonoom systeem moet met andere

systemen kunnen interageren.

• Complexiteit verbergen: een autonoom systeem laat toe om een hogere efficientie te

verkrijgen, door de onderliggende low-level handelingen zelf uit te voeren.

2.1.2 Autonome eigenschappen

Het doel van een autonoom systeem is zelfbeheer. Op dit moment wordt het grootste deel

van het beheer van een systeem manueel door een administrator uitgevoerd. Naarmate syste-

men ingewikkelder worden, wordt dit steeds moeilijker. Daarnaast kan een beheerder fouten

maken, waardoor het systeem niet meer correct werkt. Autonome systemen streven ernaar

om de last op beheerders te verminderen. In het ideale geval zou een beheerder overbodig

worden, maar daarvoor is de technologie nog niet ver genoeg gevorderd. Toch is het ook nu

al mogelijk om een groot deel van het beheer automatisch te laten verlopen. Tevens is het


mogelijk voor een systeem om de beheerder te assisteren bij het uitvoeren van manuele taken

zoals besproken in [7]. Uiteraard moet opgelet worden dat autonome systemen geen extra

complexiteit introduceren en zo het werk van beheerders nog bemoeilijken.

Zelfbeheer kan enkel bereikt worden steunend op vier pijlers [30]:

• zelfconfiguratie: de mogelijkheid van een systeem om zichzelf te configureren rekening

houdend met veranderende noden.

• zelfgenezing: de mogelijkheid van een systeem om autonoom te kunnen herstellen van

fouten.

• zelfoptimalisatie: de mogelijkheid van een systeem om zichzelf te optimaliseren en een

snellere werking toe te laten.

• zelfbescherming: de mogelijkheid van een systeem om zichzelf te kunnen beschermen

tegen fouten.

Let op dat niet al deze pijlers nodig zijn in alle systemen. In de meeste gevallen zullen ze

echter toch steeds alle vier in zekere mate aanwezig zijn.

De vier pijlers van zelfbeheer kunnen enkel bereikt worden door vier attributen in het systeem

te integreren, namelijk:

• Zelfbewustzijn: een systeem moet zich bewust zijn van zichzelf en zichzelf kunnen on-

derscheiden van zijn omgeving.

• Omgevingsbewustzijn: naast het bewust zijn van zichzelf moet het ook bewust zijn van

zijn omgeving. Een voorbeeld hiervan is location awareness, het plaatsen van zichzelf

in de omgeving.

• Zelfmonitoring: een autonoom systeem moet zichzelf kunnen controleren op onregelma-

tigheden. Voorbeelden van onregelmatigheden zijn onder andere onjuiste uitvoer en een

te trage werking.

• Zelfaanpassing: een systeem moet zichzelf kunnen instellen.

Voor de twee laatste attributen is er een nood aan een of meerdere controlelussen die con-

stant monitoren, denken, plannen maken voor wijzigingen en deze uitvoeren. Verschillende

controlelussen zijn over de jaren heen voorgesteld, elk met hun eigen voor- en nadelen [2].

2.1.3 Architectuur van een autonoom systeem

Een algemene architectuur voor een autonoom systeem bestaat er niet. Elk systeem heeft een

ander doel en een andere manier om er te raken. Daarom moet een specifieke architectuur


ontworpen worden. Wel zijn er verschillende algemene high-level architecturen, waarvan de

MAPE controlelus (en zijn varianten) het meest gebruikt wordt. Hieronder worden drie

algemene structuren besproken.

MAPE controlelus

Zoals eerder aangegeven introduceerde IBM het concept ‘autonome systemen’. Daarnaast

introduceerden ze ook het concept van autonome managers als een groep van samenwerkende

componenten die elk hun eigen component beheren. De origineel voorgestelde autonome

manager is de MAPE controlelus (zie Figuur 2.1). Een MAPE controlelus bestaat uit 4

Figuur 2.1: MAPE controlelus [13]

stappen die constant en sequentieel doorlopen worden; Al deze stappen gebruiken of genereren

kennis (knowledge):

• Monitorstap: in deze stap wordt kennis geaggregeerd, gefilterd en bestuurd. De infor-

matie wordt verworven door sensoren vanuit de component die gestuurd wordt door de

autonome manager. Eenmaal de informatie verwerkt is, wordt de kennis opgeslagen in

de knowledge module.

• Analysestap: in deze stap wordt de informatie geanalyseerd. Op die manier wordt een

diagnose gesteld van het systeem om onregelmatigheden te detecteren.

• Planningsstap: deze stap gaat na welke stappen uitgevoerd moeten worden op basis van

de gestelde diagnose.


• uitvoeringsstap: deze stap zorgt ervoor dat de geplande acties uitgevoerd worden.

Elke MAPE controlelus beheert een enkel element. Deze controlelus is de bekendste van

alle controlelussen, populair omwille van zijn eenvoud. Net door die eenvoud heeft deze

controlelus enkele nadelen. Een van de belangrijkste is dat het vrijwel onmogelijk is om te

leren uit ervaring. Daarom werden in de loop van de jaren nieuwere en betere controlelussen

voorgesteld [2].

2.1.4 Busstructuur

In figuur 2.2 wordt een eenvoudig autonoom element weergegeven. De componenten van dit

element hebben toegang tot een bus die het mogelijk maakt informatie te lezen en te publice-

ren. De functionaliteit van deze componenten is vergelijkbaar met de MAPE controlelus [3],

maar met behulp van de busstructuur is de onderlinge koppeling minder streng. Volgende

Figuur 2.2: Architectuur van een autonoom element met een busstructuur [27]

componenten zijn aanwezig:

• Monitoring Probe: deze component voert de monitorstap van de MAPE controlelus uit

en interageert met de beheerde resource via de Resource Interface. Deze component

haalt informatie op en zet deze op de bus. De Knowledge Processing Component slaat

deze informatie op.

• Context Manager : deze component maakt communicatie tussen verschillende autonome

elementen mogelijk. Het publiceert lokaal aanwezige informatie zodat andere autonome

elementen dit kunnen lezen. Het behandelt ook aanvragen van andere autonome ele-

menten in verband met het ophalen van informatie. Als deze component informatie


binnen krijgt, wordt ook dit op de bus gezet en opgeslagen door de Knowledge Proces-

sing Component .

• Knowledge Processing Component : deze component gedraagt zich zoals een lokale data-

bank die allerlei informatie opslaat en beschikbaar stelt. Deze informatie kan verkregen

worden via de Monitoring Probe, de Context Manager of via het redeneren van het

autonoom element zelf.

• State Comparator en Planning Agent : deze component voert de analysestap en de

planningsstap van de MAPE controlelus uit. Informatie uit de Knowledge Processing

Component wordt hiervoor gebruikt.

• Resource Endpoint : deze component biedt een eenvoudige interface aan zodat het au-

tonoom element kan communiceren met de beheerde resource. Met behulp van deze

interface kunnen nieuwe configuraties, opgelegd door de State Comparator en Planning

Agent componenten, afgedwongen worden.

• Policy Framework : deze component bepaalt het globaal gedrag van het autonoom ele-

ment. Policy’s worden gebruikt om business logica te scheiden van het systeem zelf.

Een policy is een (high-level) doel waaraan het systeem moet voldoen.

OODA controlelus

De Observe Orient Decide and Act controlelus (zie Figuur 2.3) is een controlelus die voortge-

vloeid is uit de MAPE controlelus [2]. Terwijl de stappen bij de MAPE controlelus sequentieel

Figuur 2.3: OODA controlelus [8]

doorlopen moeten worden, is dit bij de OODA controlelus niet het geval. Dit maakt deze

techniek een stuk dynamischer. De vier stappen van de MAPE controlelus komen ook hier


aan bod (met andere namen), maar hoeven niet sequentieel doorlopen worden. Ze vormen

meer een set van interagerende controlelussen. Deze controlelus wordt meer en meer gebruikt

als basis voor autonome controlelussen. De reden is te vinden bij het feit dat de vier stappen

nauw aansluiten bij het menselijk denkproces. De observatiestap haalt de informatie op, de

orientatiestap filtert deze waarna het systeem in de beslissingsstap een beslissing neemt die

in de actiestap uitgevoerd wordt.

Een eerste voordeel tegenover de MAPE controlelus is, dat iedere stap feedback kan geven om

gemaakte fouten te vermijden of te corrigeren. Een ander pluspunt is, dat de processen parallel

lopen. Zo hoeven de verschillende stappen niet op elkaar te wachten en kan er bijvoorbeeld

nieuwe informatie opgehaald worden terwijl het systeem de vorige nog aan het analyseren is.

Een gevolg van de manier waarop deze controlelus werkt, is dat er een evenwicht gevonden kan

worden tussen latere beslissingen en het beter analyseren van informatie. Het grootste nadeel

van deze controlelus is dat alle stappen doorlopen moeten worden. Men kan dus bijvoorbeeld

geen acties nemen als de juiste informatie daarvoor niet voorzien werd.

FOCALE controlelus

De Foundation Observation Comparison Action and Learning Environment controlelus is

gebaseerd op de OODA controlelus, maar probeert de problemen hiermee te omzeilen [2].

Deze controlelus verbindt alle componenten door middel van een bus, zoals afgebeeld in

Figuur 2.4. In deze controlelus zijn volgende stappen aanwezig:

Figuur 2.4: FOCALE controlelus [2]

• Observatiestap: ophalen van informatie uit de beheerde component.

• Normalisatiestap: vertaling van informatie in een specifiek formaat naar een genor-

maliseerd formaat. Deze informatie wordt geanalyseerd om de huidige status van het

systeem te achterhalen.


• Vergelijkingsstap: deze stap vergelijkt de huidige toestand van het systeem met een

referentie.

• Beslissingsstap: deze stap beslist wat er moet gebeuren.

• Actiestap: deze stap voert de beslissing uit.

• Redeneerstap: tijdens deze stap wordt nagegaan of de beslissing goed was.

• Leerstap: in deze stap wordt geleerd beslissingen en acties te optimaliseren op basis van

acties genomen in het verleden.

Het voordeel van deze controlelus tegenover de OODA controlelus is dat niet alle stappen

doorlopen hoeven te worden. Zo kan de controlelus snel reageren op externe informatie door

de beslissings-, redeneer- en leerstappen over te slaan. In andere gevallen kan er gekozen

worden om alle stappen te doorlopen om goed gekozen beslissingen te nemen en te leren

vanuit die beslissingen om in de toekomst nog beter te kunnen werken.

2.1.5 Autonoom maturiteitsniveau

Niet alle computersystemen zijn even autonoom. Sommige hebben geen enkele voorziening

tot autonomie, anderen bevatten dan weer zeer veel elementen. In het algemeen kunnen

systemen in vijf niveaus onderverdeeld worden [9]:

1. Basic: zowel de analyse als het oplossen van het probleem gebeurt manueel.

2. Beheerd: dergelijke systemen voorzien in gecentraliseerde tools, maar de analyse en

probleemoplossing gebeuren nog steeds manueel.

3. Voorspellend: bij dergelijke systemen is er nog steeds manuele uitvoer, maar deze han-

delingen worden gestuurd door het systeem. Ook wordt informatie van verschillende

bronnen automatisch verwerkt.

4. Adaptief: het systeem verzamelt meetwaarden, verwerkt informatie en neemt actie waar

nodig. Dit gebeurt zonder tussenkomst van een beheerder. Bij incorrecte werking van

deze handelingen, moet de beheerder het systeem wijzigen.

5. Autonoom: beheer gebeurt automatisch met behulp van policy’s die kunnen aanpassen

met veranderende business. Aanpassen van policy’s introduceert andere gedragingen in

het systeem.


Figuur 2.5: Maturiteitsniveaus van een systeem [9]

2.1.6 Voorbeelden van autonome systemen

De meeste software die gebruikt wordt voor peer-to-peer systemen is autonoom in die zin dat

deze autonoom het netwerk kan configureren en bepaalde optimalisaties van prestaties kan

doorvoeren. Een peer-to-peer systeem is dus enkel autonoom op het vlak van zelfconfiguratie

en zelfoptimalisatie. Als er nodes bijkomen of weggaan, wordt het netwerk automatisch

opnieuw geconfigureerd. Dit heeft als voordeel dat er geen centrale beheerder nodig is. Het

nadeel daarvan is echter dat bijvoorbeeld zelfbescherming onmogelijk wordt. Iedere knoop kan

nieuwe bestanden (en dus ook virussen en dergelijke) introduceren en eens deze rondgestuurd

worden, is het zeer moeilijk om ze te verwijderen uit het systeem. In normale client-server

toepassingen is dit wel gemakkelijk, daar beslist een centrale beheerder om de bestanden niet

meer aan te bieden. In een peer-to-peer omgeving moet iedere knoop dus zelf zorgen dat

malware niet gedownload wordt. Daarnaast is ook zelfgenezing niet mogelijk. Als een knoop

faalt, is het aan de persoon die verantwoordelijk is voor die knoop om de fout op te lossen en

het netwerk opnieuw te betreden.

Nieuwere web-services en data center management software bezitten ook mogelijkheden tot

zelfconfiguratie die ervoor zorgen dat deze systemen zichzelf automatisch instellen bij veran-

deringen in werkdruk. Ook planners en workflow-managers kunnen bestaan uit een aantal


autonome mogelijkheden. Een autonoom design van deze systemen vereist een soort van be-

wustzijn van de toestand van het systeem en feedback over de prestaties, wat vaak afwezig is

bij bestaande planners en workflow-managers [17].

Voorlopers van bedrijven die gebruik maken van autonome systemen zijn IBM, Sun en HP.

Hieronder zijn enkele commerciele projecten opgesomd die gebruik maken van autonome

systemen [29]:

• IBM

– eLiza: een project dat ervoor zorgt dat servers en mainframes autonoom kunnen

omgaan met veranderingen in het systeem alsook met componentfalingen1.

– LEO: dit is een automatisch query optimalisatieprogramma voor IBMs DB2 data-

bank systemen. Het monitort query’s terwijl ze uitgevoerd worden en vergelijkt de

schattingen van de uitvoeringstijd voor elke stap in de uitvoering van de query met

de werkelijke resultaten. De detectie van schattingsfouten kan als trigger dienen

voor zelfoptimalisatie tijdens de uitvoering van een query2.

– Blue Gene/L: de eerste supercomputer die voorzieningen had voor zelfbeheer en

zelfgenezing3.

– IceCube: een server die informatie bijhoudt over zijn eigen nodes (gezondheid,

maximale load) en data distribueert zodat een maximale processing kan gebeuren.

Falende nodes worden automatisch overgeslagen4.

• Sun

– Jini network: een netwerk dat zichzelf kan aanpassen. Als er netwerkelementen

falen kan het netwerk op zoek gaan naar werkende nodes die de gewenste functio-

naliteit aanbieden en deze gebruiken in plaats van de gefaalde node5.

– Grid Engine: een grid beheersysteem dat ervoor zorgt dat zogenaamde deadline

policies kunnen gebruikt worden om ervoor te zorgen dat projecten die hun dead-

line naderen meer resources toegekend krijgen. Ook share based policies kunnen

gebruikt worden om users die teveel resources gebruiken tijdelijk minder resources

te geven6.

1http://www-03.ibm.com/systems/i/software/db2/db2eliza.html2http://domino.watson.ibm.com/comm/research.nsf/pages/r.datamgmt.innovation.html3http://www.research.ibm.com/bluegene/index.html4http://www.sgi.com/products/data center/ice cube/?5http://java.sun.com/developer/technicalArticles/jini/JiniVision/jiniology.html6http://www.oracle.com/us/products/tools/oracle-grid-engine-075549.html


• HP

– superdome: dit is een server die voorziet in zelfgenezende eigenschappen voor

het vervangen van een processor als er teveel fouten opgetreden zijn om ze nog

automatisch op te lossen7.

2.2 E-health systemen

Naast bijvoorbeeld servers en peer-to-peer netwerken, zijn er nog een heleboel andere systemen

die beter zouden kunnen functioneren door autonome eigenschappen aan te nemen. In deze

thesis wordt zo een voorbeeld bekeken, namelijk de tak van e-health systemen. Afhankelijk

waarvoor ze ingezet worden, kunnen e-health systemen nood hebben aan bepaalde autonome

eigenschappen. Neem als voorbeeld systemen die dokters kunnen bijstaan bij het stellen van

diagnoses. Dergelijke systemen moeten altijd correcte informatie kunnen geven en dit op elk

moment. Zo niet, kan een verkeerde diagnose gesteld worden, wat faliekant kan zijn voor de

patient in kwestie. Een ander voorbeeld kan gevonden worden in systemen die patienten in

leven houden. Dergelijke systemen moeten snel en efficient kunnen aangepast worden aan

de veranderende toestand van de patient. Naast deze twee voorbeelden kunnen nog tal van

andere toepassingen gevonden worden waarin autonome eigenschappen een enorme doorbraak

kunnen betekenen.

2.2.1 Introductie

[14] definieert e-health systemen als volgt: “E-health is een opkomend gebied op het kruis-

punt van medische informatica, de volksgezondheid en het bedrijfsleven, met betrekking tot

de medische diensten en informatie geleverd aan of verbeterd door middel van het internet

en aanverwante technologieen. In bredere zin kenmerkt de term niet alleen een technische

ontwikkeling, maar ook een state-of-mind, een manier van denken, een houding, en een ver-

plichting voor een genetwerkt, wereldwijd denken, om de gezondheidszorg lokaal, regionaal en

wereldwijd te verbeteren door gebruik te maken van informatie- en communicatietechnologie”.

Onder de term e-health systeem vallen dus enorm veel toepassingen. Deze reiken van het

online aanbieden van medicijnen over het adviseren van dokters tot het real time controleren

van patienten in een ziekenhuis. Bij dergelijke systemen is het essentieel dat ze niet falen.

Falingen kunnen immers leiden tot verlies van levens. Om deze reden is het aan te raden

om dergelijke kritische e-health toepassingen te ontwikkelen als autonome systemen. In vele

praktische implementaties is dit echter nog niet het geval. De belangrijkste eigenschap bij

dergelijke systemen is dat ze betrouwbaar zijn. Denk bijvoorbeeld aan een systeem dat de

7http://h20341.www2.hp.com/integrity/w1/en/high-end/integrity-high-end-servers-superdome2.html


hartslag van een patient meet en een alarm geeft als deze onder een bepaalde waarde gaat.

Deze moet betrouwbaar zijn, anders kunnen er mensen door sterven. Hetzelfde geldt ook voor

intelligente systemen die dokters helpen bij het analyseren van symptomen van ziektes. Be-

trouwbaarheid bestaat uit verschillende attributen: beschikbaarheid, betrouwbaarheid, vei-

ligheid, vertrouwelijkheid, integriteit en onderhoudbaarheid [6]. Deze attributen komen in

ieder betrouwbaar systeem in zekere mate voor en kunnen verkregen worden met behulp van

preventie, tolerantie, verwijdering en voorspelling van fouten.

2.2.2 Autonome e-health systemen in de praktijk

Een van de eerste e-health systemen met een zekere intelligentie was MYCIN. Dit was een

van de eerste expertsystemen en het liet toe bacterien die infecties veroorzaken automatisch

te identificeren en correcte antibiotica voor te stellen, rekening houdend met het gewicht van

de patient. Hiervoor werd een regelgebaseerd systeem gebruikt. MYCIN werd echter nooit

in de praktijk gebruikt. Het experiment begon in 1970 en in die tijd was er van internet nog

geen sprake. Alle informatie die het systeem nodig had om diagnoses te stellen moest manueel

ingevoerd worden. Dit nam veel te veel tijd in beslag (hoewel de uiteindelijke diagnose meestal

beter was dan deze gesteld door een mens) en teveel foute informatie ingegeven kon worden.

Een tweede probleem was van ethische aard. Als het systeem een incorrecte diagnose stelde,

wie was dan verantwoordelijk? Door deze twee problemen werd het systeem nooit in de

praktijk gebruikt. MYCIN was de voorloper van de hedendaagse e-health systemen en met

behulp van dit experiment werd onder andere duidelijk dat een systeem niet alleen correct

moest werken bij afwezigheid van fouten, maar dat het ook voorzieningen moest treffen om

het systeem zo robuust mogelijk te maken.

Ondertussen heeft het onderzoek naar e-health systemen al een geweldige vooruitgang ge-

boekt. Een voorbeeld is het concept van SMC’s (Self-Managed Cells) [24]. Dit concept laat

toe dat sensoren, die bijvoorbeeld patienten opvolgen om hun gezondheid na te gaan, auto-

matisch geconfigureerd en beheerd kunnen worden. SMC introduceert dus zelfconfiguratie

en zelfbeheer in een dergelijk systeem. Een voorbeeld van een e-health systeem dat gebruik

maakt van deze technologie is AMUSE (Autonomic Management of Ubiquitous e-Health Sys-

tems) [28]. Dit is een patient-monitoring systeem waarbij patienten van thuis uit opgevolgd

kunnen worden en dat gebruik maakt van SMC’s en de communicatie ertussen zodat het

sensornetwerk dat de patient opvolgt, zichzelf kan configureren en beheren.

2.3 Kennismodellering

Zoals eerder aangegeven wordt in deze thesis een aanzet gegeven om patient-monitoring sys-

temen uit te breiden met autonome eigenschappen. Na deze thesis zal het mogelijk zijn om


fouten te detecteren en te linken aan onderliggende oorzaken. Het probleem dat hier aange-

pakt moet worden is dus tweeledig. Enerzijds moeten fouten die optreden ontdekt worden,

anderzijds moeten ontdekte fouten correct ondergebracht worden in categorieen. Hiervoor

kunnen verschillende technieken gebruikt worden. Hieronder worden enkele van de meest

voor de hand liggende besproken. Op het einde van deze sectie is een korte samenvatting en

vergelijking te vinden.

2.3.1 Regelgebaseerde systemen

Het begrip “regelgebaseerd systeem” werd ingevoerd in 1970 in Stanford University tijdens

het Mycin experiment [36].

Met een regelgebaseerd systeem wordt een systeem bedoeld dat gebruikt wordt om kennis op

te slaan onder de vorm van regels en deze regels toe te passen om snel en veelvuldig intelligente

beslissingen te kunnen nemen. Regelgebaseerde systemen worden met name veel gebruikt bij

de studie van kunstmatige intelligentie.

Een klassiek voorbeeld van een regelgebaseerd systeem is het domeinspecifieke expertsysteem.

Dit systeem wordt gebruikt voor het maken van afleidingen of keuzes. Een arts kan zo

bijvoorbeeld aan de hand van een bepaalde reeks symptomen een bijbehorende diagnose van

de aandoening stellen. Een ander voorbeeld is het maken van tactische bewegingen in een

computerspel [35].

Binnen het kader van de lexicale analyse kunnen regelgebaseerde systemen gebruikt worden

om computerprogramma’s te compileren of interpreteren. Programma’s die deze omzetting

uitvoeren worden lexical analysers, lexers of scanners genoemd. Voor de omzetting van een

reeks karakters in een reeks symbolen wordt een aantal regels geformuleerd die aangeven welke

opeenvolgende karakters een (geldig) symbool vormen. Deze regels worden meestal gespeci-

ficeerd door middel van reguliere expressies. Lexers worden vooral gebruikt in compilers en

interpreters. Daar vormen ze de eerste fase in het lezen en interpreteren van een programma.

Nadat een bronprogramma (dat bestaat uit een reeks karakters, meestal in een bestand) is

omgezet in een reeks symbolen, worden deze symbolen verder verwerkt door een parser. Ook

buiten het gebruik in compilers en interpreters worden lexers vaak gebruikt in combinatie

met parsers. Dit is echter niet noodzakelijk. Een lexer is bijvoorbeeld ook bruikbaar in een

programma dat alle HTML-tags uit een tekst verwijdert. Een parser is daarbij overbodig.

Een ander voorbeeld van regelgebaseerde systemen is logisch programmeren. Logisch pro-

grammeren is een poging tot het afleiden van uitvoeringsinstructies op basis van een regelge-

baseerd systeem dat bestaat uit een reeks gegevens en regels. Deze methode is wat minder

rechtstreeks dan het gebruik van imperatieve programmeertalen waarbij de uit te voeren


stappen simpelweg achter elkaar staan. In een deductieve logische programmeertaal valt het

redeneerproces schematisch weer te geven als feiten + regels = resultaten. De compiler/inter-

preter is op de hoogte van een aantal feiten en probeert, aan de hand van regels, een antwoord

te geven op een vraag die aan hem wordt gesteld. Je kan je bijvoorbeeld voorstellen dat de

volgende feiten aan de interpreter bekend zijn:

• Katten hebben een vacht

• Een vacht bestaat uit haren

De interpreter moet dan antwoord kunnen geven op de vraag “Hebben katten haren?”.

Een voorbeeld van een functionele en logische programmeertaal is Curry [5].

Opbouw

Een regelgebaseerd systeem kan in drie componenten onderverdeeld worden [34]:

• Rule base, in de vorm van een lijst met regels. Dit is een gespecialiseerde databank die

“kennis” (de regels) opslaat en beheert.

• Rule engine, om informatie af te leiden of stappen te zetten op basis van de input-rule

base interactie.

• Working memory , het werkgeheugen dat een tijdelijke opslagplaats vormt voor taak-

relevante informatie.

Soorten regels

Er bestaan 2 soorten regels:

• Forward chaining rules: dergelijke regels starten met aangereikte data en gebruiken

afleidingsregels om meer gegevens te extraheren tot een doel bereikt is. Een schematische

weergave is te vinden in Sectie 2.6.

Stel dat het doel is, de kleur van een huisdier met de naam Fritz te bepalen, gezien het

feit dat hij kwaakt en vliegen eet, en dat de rule base de volgende vier regels bevat:

– Als X kwaakt en vliegen eet - Dan is X een kikker.

– Als X kwettert en zingt - Dan is X een kanarie.

– Als X een kikker is - Dan is X groen.

– Als X een kanarie is - Dan is X geel.

Deze rule base wordt doorzocht en de eerste regel wordt gekozen, omdat het antecedent

(Als Fritz kwaakt en vliegen eet) overeen komt met onze gegevens. Nu wordt het

consequent (Dan is X een kikker) toegevoegd aan de data. De rule base wordt opnieuw


Figuur 2.6: Forward chaining [18]

doorzocht en dit keer wordt de derde regel geselecteerd, omdat het antecedent (Als Fritz

een kikker is) overeen stemt met onze gegevens. Nu wordt het nieuwe consequent (Dan

is Fritz groen) toegevoegd aan onze gegevens. Er kan niets meer afgeleid worden uit

deze informatie, maar we hebben nu ons doel bereikt, de kleur van Fritz is bekend.

Omdat de gegevens bepalen welke regels worden geselecteerd en gebruikt, wordt deze

methode data-driven genoemd, in tegenstelling tot backward chaining . De forward chai-

ning aanpak wordt vaak toegepast in expert systemen.

Een van de voordelen van forward chaining tegenover backward chaining is dat de

ontvangst van nieuwe gegevens kan leiden tot nieuwe conclusies, waardoor de engine

beter geschikt is voor dynamische situaties waarin de condities kunnen veranderen.

• Backward chaining rules: in tegenstelling tot forward chaining beginnen dergelijke re-

gels met een lijst van doelen (of een hypothese) en werken ze terug vanaf het consequent

tot aan het antecedent om te zien of er gegevens beschikbaar zijn die ondersteuning bie-

den voor een van deze consequenten. Een schematische weergave is te vinden in Figuur

2.7.

Stel dat we nu dezelfde vraag willen beantwoorden als hierboven, en dat de rule base

dezelfde regels bevat. Bij backward chaining werkt dit nu als volgt. De rule base wordt

doorzocht en de derde en vierde regels worden geselecteerd, omdat hun consequenten

(Dan is Fritz groen, dan is Fritz geel) overeenkomen met het doel (de kleur van Fritz

bepalen). Het is nog niet bekend dat Fritz een kikker is, dus beide antecedenten (Als


Figuur 2.7: Backward chaining [18]

Fritz een kikker is, als Fritz een kanarie is) worden toegevoegd aan het lijst met doelen.

De rule base wordt opnieuw doorzocht en deze keer worden de eerste twee regels gese-


lecteerd, omdat hun consequenten (Dan is X een kikker, dan is X een kanarie) overeen

komen met de nieuwe doelen die net toegevoegd werden aan de lijst. Het antecedent

(Als Fritz kwaakt en vliegen eet) is bekend en daarom kan er geconcludeerd worden dat

Fritz een kikker is, en niet een kanarie. Het doel van het bepalen van de kleur van Fritz

is nu bereikt (Fritz is groen als hij een kikker is, en geel als hij een kanarie is, maar hij

is een kikker omdat hij kwaakt en vliegen eet, daarom Fritz is groen).

Merk op dat de doelstellingen altijd matchen met de consequenten van de implicaties

(en niet de negaties), en dat de antecedenten dan beschouwd worden als de nieuwe

doelen (en niet de conclusies), die uiteindelijk moeten overeenkomen met bekende feiten

(meestal gedefinieerd als consequenten wiens antecedenten altijd waar zijn); bijgevolg

is de gevolgtrekkingsregel die gebruikt wordt, de modus ponens.

Omdat de lijst van doelen bepaalt welke regels geselecteerd en gebruikt worden, wordt

deze methode goal-driven genoemd, in tegenstelling tot data-driven forward chaining

inferentie.

Regelgebaseerde systemen in de praktijk

Regelgebaseerde systemen worden in de praktijk nog niet vaak gebruikt omwille van twee

grote redenen [34]:

• Ten eerste is er nog geen algemene standaardtaal om regels te definieren. Verschillende

leveranciers hebben hun eigen taal en het is zeer moeilijk om de verschillende talen te

leren.

• Daarnaast verwachten veel rule engines nog steeds meta-data in plaats van (of in com-

binatie met) data.

Dit zijn de twee grote problemen die regelgebaseerde systemen de dag van vandaag het leven

moeilijk maken. Men ziet veelal geen winst in het gebruik van regelgebaseerde systemen in

plaats van het conventionele programmeren. Naast bovenvermelde problemen zijn er natuur-

lijk nog tal van andere. Zo moeten regelgebaseerde systemen voorzien in mechanismen om

data tussen de rule engine en de applicatie heen en weer te sturen en moeten er mechanismen

voorzien worden om resultaten permanent op te slaan. Ondanks deze tekortkomingen zijn

regelgebaseerde systemen aan een opmars bezig. Ze worden onder andere al gebruikt door

enkele grote bedrijven als Dell, Cisco en Vodafone.

2.3.2 Bayesiaanse netwerken

Een Bayesiaans netwerk is een datastructuur, voorgesteld door middel van een gerichte acycli-

sche graaf waarin de knopen proposities (gebeurtenissen) beschrijven en de takken de relaties


ertussen [22]. Deze datastructuur wordt gebruikt om probabilistische redeneringen te model-

leren. Meestal (maar niet noodzakelijk) wordt de richting van de tak gezien als een causaal

verband tussen de verschillende gebeurtenissen. De causale interpretatie is vaak een goede

intuıtieve manier om een probabilistisch netwerk te lezen. Een voorbeeld waarbij een Bayesi-

aans netwerk gebruikt wordt is het modelleren van probabilistische relaties tussen ziekten en

symptomen. Gezien de symptomen kan het netwerk gebruikt worden om de waarschijnlijkheid

van de aanwezigheid van verschillende ziekten te berekenen.

Bayesiaanse netwerken zijn dus gerichte acyclische grafen waarvan de knooppunten willekeu-

rige variabelen vertegenwoordigen in de Bayesiaanse zin: ze kunnen waarneembare groot-

heden, latente variabelen, onbekende parameters of hypothesen zijn. Takken vormen con-

ditionele afhankelijkheden; knooppunten die niet verbonden zijn met elkaar, representeren

variabelen die conditioneel onafhankelijk zijn van elkaar. Aan elk knooppunt is een probabili-

teitsfunctie gekoppeld met als input een bepaalde set van waarden voor de ouderknoop en als

output de probabiliteit van een variabele die gerepresenteerd wordt door de node. Bijvoor-

beeld, als de ouders m Booleaanse variabelen voorstellen, dan kan de probabiliteitsfunctie

vertegenwoordigd worden door een tabel van 2m ingangen, een ingang voor elk van de 2m

mogelijke combinaties van zijn ouders.

Er bestaan efficiente algoritmen die gevolgtrekking en leren uitvoeren in Bayesiaanse netwer-

ken. Bayesiaanse netwerken die sequenties van variabelen modelleren (bijvoorbeeld spraaksig-

nalen of eiwitsequenties) worden dynamische Bayesiaanse netwerken genoemd. Generalisaties

van Bayesiaanse netwerken die problemen met onzekerheid kunnen vertegenwoordigen en op-

lossen worden influence diagrammen genoemd.

Een voordeel van Bayesiaanse netwerken is dat het intuıtief gemakkelijker is voor een mens

om directe afhankelijkheden en lokale distributies te begrijpen dan een complete gezamenlijke

distributie.

Taken van Bayesiaanse netwerken

Er zijn drie belangrijke gevolgtrekkingstaken voor Bayesiaanse netwerken.

Afleiden van niet-waargenomen variabelen Omdat een Bayesiaans netwerk een com-

pleet model voor de variabelen en hun relaties is, kan het gebruikt worden om er probabi-

listische vragen over te beantwoorden. Zo kan het netwerk gebruikt worden om bijgewerkte

kennis van de toestand van een subset van variabelen na te gaan als andere variabelen waarge-

nomen worden. Dit proces van het berekenen van de posterior distribution van de variabelen

als andere variabelen gegeven zijn als bewijs, wordt probabilistische gevolgtrekking genoemd.


Een Bayesiaans netwerk kan dus beschouwd worden als een mechanisme voor het automatisch

toepassen van de stelling van Bayes voor complexe problemen.

Leren van parameters Om ten volle het Bayesiaanse netwerk te specificeren en dus de

volledige gezamenlijke distributie te kunnen representeren, is het noodzakelijk om voor elke

node X de distributie voor X afhankelijk van de ouders van X aan te geven. Deze distributie

kan elke vorm aannemen. Het is gebruikelijk om te werken met discrete of Gauss-verdeling,

omdat de berekeningen dan eenvoudiger worden. Vaak hebben deze conditionele distribu-

ties parameters die onbekend zijn. Deze moeten geschat worden op basis van de gegevens,

soms met behulp van de maximum likelihood benadering. Direct maximaliseren van de like-

lihood is vaak complex als er niet-waargenomen variabelen zijn. Een klassieke aanpak van

dit probleem is het expectation-maximization algoritme dat wisselt tussen het berekenen van

de verwachte waarden van de niet-waargenomen variabelen afhankelijk van de waargenomen

gegevens en het maximaliseren van de complete likelihood in de veronderstelling dat vooraf be-

rekende verwachte waarden correct zijn. Onder milde omstandigheden convergeert dit proces

naar maximum likelihood waarden voor de parameters. Een volledigere Bayesiaanse aanpak

bestaat er in de parameters als niet-waargenomen variabelen te behandelen, de volledige dis-

tributie te berekenen over de geobserveerde data en er daarna de parameters uit te integreren.

Deze aanpak kan echter zeer rekenintensief zijn en leiden tot modellen met grote dimensies,

waardoor in de praktijk de klassieke parameter-setting benaderingen vaker voorkomen.

Leren van de structuur In het eenvoudigste geval wordt een Bayesiaans netwerk bepaald

door een deskundige en wordt het vervolgens gebruikt voor gevolgtrekkingen. In andere

toepassingen is de taak van het definieren van het netwerk te complex voor de mens. In dit

geval moeten de netwerkstructuur en de parameters van de lokale distributies geleerd worden

met behulp van data. Dit automatisch leren van de structuur van een Bayesiaans netwerk

is een uitdaging die nagestreefd wordt binnen machinelearning. Het basisidee gaat terug tot

een algoritme ontwikkeld door Rebane en Pearl [32].

2.3.3 Classificatie

Classificatie wordt gebruikt om nieuwe waarnemingen (of instanties) in te delen in een set van

categorieen op basis van een trainingsset van waarnemingen waarvan de categorieen bekend

zijn [37]. Een algoritme dat de classificatie implementeert staat bekend als een classifier . De

afzonderlijke metingen worden gesplitst in een aantal meetbare eigenschappen: verschillende

variabelen, kenmerken, . . . . Deze eigenschappen kunnen categoriaal (bijvoorbeeld “A”, “B”,

“AB” of “O” voor bloedgroep) , ordinaal (bijvoorbeeld “grote”, “middel” of “kleine”), geheel

(bijvoorbeeld het aantal exemplaren van een bepaald woord in een e-mail) of reeelwaardig


(bijvoorbeeld een meting van de bloeddruk) zijn. Sommige algoritmen werken alleen in termen

van discrete gegevens en eisen dat geheel of reeelwaardige gegevens in groepen gediscretiseerd

worden (bijvoorbeeld minder dan 5, tussen 5 en 10, of groter dan 10). Een voorbeeld hiervan

is het toewijzen van een bepaalde e-mail in “spam” of “niet-spam” klassen of het toewijzen

van een diagnose voor een bepaalde patient zoals beschreven door de waargenomen kenmerken

van de patient (geslacht, bloeddruk, aan-of afwezigheid van bepaalde symptomen, . . . . ).

De terminologie voor alles wat met classificatie te maken heeft, is heel gevarieerd en hangt

af van het veld waarin de termen gebruikt worden. In de statistiek worden de eigenschap-

pen van de waarnemingen bijvoorbeeld variabelen genoemd en de categorieen die voorspeld

worden, uitkomsten. Bij machinelearning zijn de waarnemingen vaak bekend als gevallen (of

instanties), terwijl de verklarende variabelen kenmerken (of observaties) genoemd worden. De

mogelijke categorieen die te voorspellen zijn, worden klassen genoemd.

2.3.4 Clustering

Bij clusteranalyse worden een reeks van waarnemingen (of instanties) samengenomen in ver-

schillende groepen (of clusters) zodat instanties in dezelfde cluster meer gelijkenis tonen met

elkaar dan met de instanties uit andere clusters [21]. Het is een van de belangrijkste taken in

de exploratieve datamining, en een vaak gebruikte methode voor statistische data-analyse ge-

bruikt in vele gebieden, met inbegrip van machinelearning, patroonherkenning, beeldanalyse

en bio-informatica.

Clusteranalyse op zichzelf is geen specifiek algoritme, maar een algemene taak die opgelost

moet worden. Dit kan bereikt worden door verschillende algoritmen, die aanzienlijk verschillen

in hun definitie van wat een cluster is en hoe deze efficient gevonden kunnen worden. Populaire

definities van clusters zijn groepen met kleine afstanden tussen de clusterleden, dicht bevolkte

delen van de data ruimte, intervallen of bepaalde statistische verdelingen. Clustering kan dus

geformuleerd worden als een multi-objective optimalisatieprobleem. De selectie van het juiste

clusteringalgoritme en parameters instellingen (inclusief waarden, zoals de afstandsfunctie die

gebruikt zal worden, een dichtheidsdrempel of het aantal te verwachten clusters) is afhanke-

lijk van de individuele gegevens en het beoogde gebruik van de resultaten. Clusteranalyse als

zodanig is geen automatische taak, maar een iteratief proces van kennisverwerving of interac-

tieve multi-objective optimalisatie die trial and error inhoudt. Vaak moeten voorbewerkingen

en parameters aangepast worden tot het resultaat de gewenste eigenschappen bereikt heeft.

Naast de term clustering zijn er een aantal termen met vergelijkbare betekenis, met inbegrip

van automatische classificatie, numerieke taxonomie, botryology en typologische analyse. De

subtiele verschillen zijn vaak in het gebruik van de resultaten: terwijl in datamining de resul-

terende groepen zelf van belang zijn, is het in de automatische classificatie in de eerste plaats


het onderscheidend vermogen van de verschillende groepen van belang. Dit leidt vaak tot

misverstanden tussen onderzoekers uit het gebied van datamining en machinelearning, omdat

ze gebruik maken van dezelfde voorwaarden en vaak dezelfde algoritmes, maar verschillende

doelen hebben.

2.3.5 Case-based reasoning

Case-based reasoning (CBR) is het oplossen van problemen op basis van problemen uit het

verleden (waarvan de oplossing bekend is) [25]. Een programmeur die bugs uit een programma

haalt door gebruik te maken van ervaring met eerder geschreven programma’s is een voorbeeld

van gebruik van CBR. Ook een ingenieur die werkende elementen vanuit de natuur kopieert, is

een voorbeeld van CBR, waarbij de natuur behandeld wordt als een databank met oplossingen

voor problemen. Case-based reasoning steunt op het maken van analogieen.

CBR is niet alleen een krachtige methode voor computer reasoning , maar wordt ook vaak

(onbewust) gebruikt door de mens bij het oplossen van alledaagse problemen. CBR wordt

ook soms aangehaald als de enige manier van denken bij de mens, dus dat alle redenering

gebaseerd is op gevallen die een mens in het verleden aan den lijve ondervond. Deze visie is

gerelateerd aan prototype theorie, de diepst onderzochte theorie in de cognitieve wetenschap.

Figuur 2.8: CBR cyclus [1]


Case-based reasoning voor computerredeneren is geformaliseerd als een proces van vier stap-

pen (zoals afgebeeld in Figuur 2.8) [41]:

• Retrieve: als een nieuw probleem zich voordoet, worden gevallen opgehaald uit het

geheugen die relevant zijn voor het oplossen van dit nieuw probleem. Een geval (of

case) bestaat uit een probleem, een oplossing en gewoonlijk aantekeningen over hoe

de oplossing verkregen werd. Stel bijvoorbeeld dat Fred bosbessenpannenkoeken wil

maken. Hij heeft dit nog nooit gedaan, maar hij heeft wel nog gewone pannenkoeken

gemaakt en was hierin succesvol. De procedure die hij volgde bij het maken van gewone

pannenkoeken, samen met argumenten voor beslissingen gemaakt tijdens het maken van

die pannenkoeken, vormt Freds opgehaald geval.

• Reuse: in deze stap wordt de oplossing van het vorige geval op het doelprobleem gemapt.

Dit kan een aanpassing van de oplossing inhouden om deze aan de nieuwe situatie aan

te passen. In het voorbeeld van de pannenkoeken moet Fred zijn opgehaalde oplossing

aanpassen zodat het de toevoeging van bosbessen behelst.

• Revise: nadat de vorige oplossing op de nieuwe situatie gemapt is, moet deze worden

toegepast. Indien nodig moet de oplossing herzien worden. Stel dat Fred zijn oplossing

voor het maken van de pannenkoeken aanpaste door het toevoegen van blauwe bessen

aan het deeg. Na het mengen ontdekt hij dat het deeg blauw uitslaat. Dit is een

ongewenst effect. Om deze reden stelt hij de volgende wijziging voor: de toevoeging

van blauwe bessen uitstellen tot het deeg in de pan geschept is.

• Retain: nadat de oplossing met succes aangepast is aan het beoogde probleem, moet

de resulterende ervaring opgeslagen worden als een nieuw geval in het geheugen. In het

voorbeeld van de pannenkoeken zal Fred zijn pas ontdekte procedure voor het maken van

bosbessen pannenkoeken onthouden, en zo zijn set van opgeslagen ervaringen verrijken,

zodat hij in de toekomst hogere pannenkoekeneisen kan stellen.

2.3.6 Hidden Markov models

[31] definieert een hidden Markov model (HMM) als “een dubbel stochastisch proces met een

onderliggend stochastisch proces dat niet observeerbaar is (vandaar de term hidden), maar

enkel ‘geobserveerd’ kan worden aan de hand van een andere set van stochastische processen

die dezelfde sequentie van geobserveerde symbolen produceert”. Deze definitie wordt duidelijk

aan de hand van volgend voorbeeld: stel, je krijgt een lijst met resultaten van een experiment

waarbij een of meerdere munten gegooid werden en waarbij bijgehouden werd of het kop of

munt was. Het proces dat gehandhaafd werd tijdens het experiment is dus niet bekend (niet

observeerbaar of hidden), enkel de resultaten zijn bekend. Deze resultaten zijn de symbolen

geproduceerd door het verborgen experiment. De vraag die we nu willen beantwoorden is

“hoe bouwen we een HMM om de sequentie, zoals verkregen vanuit het onbekend experiment,


te kunnen verklaren?”. Verschillende HMMs zijn mogelijk: het experiment kan uitgevoerd

zijn met behulp van een normale munt, waardoor er 50% kans zou zijn op kop, en 50% kans op

munt. Een andere mogelijkheid is dat de munt meer de neiging heeft om kop weer te geven dan

munt, waardoor er andere probabiliteiten gelden. Het is ook mogelijk dat meerdere munten

gebruikt werden. Naast deze modellen zijn er nog tal van andere mogelijk.

Het opstellen van HMMs gaat gepaard met het oplossen van drie problemen. Het eerste pro-

bleem, en een van de moeilijkste elementen bij het modelleren van experimenten, is beslissen

hoe groot het model kan zijn (hoeveel toestanden het kan bevatten). Bij het voorbeeld met

de munt kan voor eender welk aantal munten gekozen worden. Met een munt zijn er twee

toestanden mogelijk per experiment, namelijk kop of munt; bij twee munten zijn er vier, na-

melijk kop-kop, kop-munt, munt-kop en munt-munt. Het aantal toestanden kan dus blijven

toenemen. Zonder kennis vooraf is de beslissing over het aantal toestanden vaak zeer moeilijk

en gebeurt met vallen en opstaan tot het beste resultaat bereikt wordt. Een tweede probleem

en een nog grotere vraag is: “hoe kiezen we de parameters voor het model (kans op kop of

munt als de vorige worp kop of munt was) om het te optimaliseren en zo het best mogelijke

resultaat te bekomen?”. Een derde en laatste probleem is de keuze van de grootte van de

geobserveerde sequentie van resultaten. Een te kleine sequentie kan het model te eenvoudig

maken, waardoor het de realiteit niet goed benadert. Een te grote sequentie kan het model

echter te ingewikkeld maken, of teveel rekentijd in beslag nemen om op te bouwen. Er moet

dus een goed compromis gevonden worden.

2.3.7 Beslissingsbomen

Een beslissingsboom is een van de mogelijke technieken die gehanteerd worden bij het oplossen

van problemen in meerdere stappen. Het idee achter deze techniek is het opsplitsen van een

complex probleem in een aantal opeenvolgende deelproblemen, in de hoop dat de verkregen

oplossing dezelfde is als bij het oplossen van het moeilijkere probleem. Voor deze techniek

wordt een boomstructuur opgesteld. Hiervoor zijn verschillende algoritmes ontwikkeld, elk

met hun eigen voor- en nadelen. De bekendste zijn de ID3- en C4.5-algoritmes [40]. De

opgestelde boom kan gebruikt worden om complexe problemen in verschillende stappen op te

lossen [33].

Een voorbeeld van een beslissingsboom is gegeven in Figuur 2.9. In dit voorbeeld wil men

nagaan of gebruikers van een systeem een nieuwe feature zouden apprecieren. Van elke ge-

bruiker is geweten hoe dikwijls ze in het systeem inloggen en wat hun geslacht is. Voor elke

gebruiker kan men nu de boom doorlopen. Men begint bij de root knoop (bovenste node) en

kijkt of een gebruiker dikwijls inlogt. Indien de gebruiker niet vaak inlogt, onderzoekt men

nog het geslacht. Aan de hand van de verschillende attributen van een gebruiker kan men tot

een bladnode komen. Hier wordt dan bepaalt of een gebruiker de feature graag zou hebben.


Figuur 2.9: Voorbeeld van een beslissingsboom [4]

Op die manier is het probleem gesplitst in kleinere deelproblemen.

Beslissingsbomen zijn zeer aantrekkelijk omdat ze toelaten complexe beslissingen op te splitsen

in kleinere eenvoudigere deelproblemen. Ook zijn ze zeer intuıtief en makkelijk te begrijpen.

Het voordeel tegenover conventionele classifiers (in een enkele stap) is dat niet alle attributen

hoeven doorlopen te worden. Als een tak gekozen is, kan het zijn dat andere attributen niet

meer van toepassing zijn. Dit vereenvoudigt de berekeningen. Zeker voor problemen met

veel dimensies (of attributen) is deze aanpak aan te raden aangezien niet met alle dimensies

rekening dient gehouden te worden, en zeker niet in een stap. Het belangrijkste nadeel van

beslissingsbomen is de complexiteit. Attributen kunnen meerdere keren voorkomen in de

boom en ook uitkomsten kunnen identiek zijn, maar dan via een andere manier bereikt.

Een beslissingsboom kan zeer groot en complex worden bij stijgende complexiteit van het

probleem. Daarnaast is er het probleem van propagerende fouten. Als er een fout gemaakt

wordt in een bepaalde stap, kan die niet meer worden goedgemaakt in volgende stappen. Ook

kan de uitkomst maar een attribuut bevatten en moet deze categorisch van aard zijn. Als

laatste is ook het opstellen van de beslissingsboom geen triviale zaak. Het opstellen van een

optimale beslissingsboom is NP-compleet. Hierdoor zijn praktische algoritmes heuristisch.

De efficientie van de beslissingsboom hangt volledig af van hoe goed de boom opgebouwd

werd met behulp van deze heuristiek [33].

2.4 Besluit

In deze thesis wordt de grondslag gelegd voor het autonoom maken van een specifieke toepas-

sing vanuit de e-health sector, namelijk een patient-monitoring systeem. Hierbij zullen fouten

gedetecteerd en onderverdeeld worden in categorieen om foutoplossing voor de beheerder van

een dergelijk systeem eenvoudiger te maken. Dit wordt bekomen door het patient-monitoring

systeem uit te breiden met een beheerplatform. Voor dit platform wordt gebruik gemaakt


van een busstructuur (zoals besproken in Sectie 2.1.4) om alle componenten te laten com-

municeren met elkaar (maar dan zonder de MAPE controlelus erin), alsook van de MAPE

controlelus in de redeneercomponent (de component die effectief de fouten detecteert en clas-

sificeert). Meer informatie over de precieze implementatie is te vinden in Sectie 3.2. Het

beheerplatform legt de grondslag voor twee van de pijlers van autonome systemen, name-

lijk zelfgenezing en zelfbescherming. Als dit systeem later uitgebreid wordt met acties door

het beheerplatform op het beheerde systeem om fouten automatisch op te lossen, dan is de

pijler zelfgenezing volledig geımplementeerd. Als daarnaast ook acties gespecificeerd worden

om fouten in de toekomst te voorkomen, dan is de pijler zelfbescherming ook in orde. Deze

acties worden tijdens deze thesis nog niet geımplementeerd. Hier wordt de focus gelegd op

het vinden en classificeren van fouten. Met een correcte implementatie van dit systeem kan

een autonoom maturiteitsniveau van niveau 3 gehaald worden. Het beheerplatform verwerkt

informatie van verschillende bronnen en stuurt een beheerder in zijn handelingen.

Er zijn technieken nodig om twee taken uit te voeren:

• Het ontdekken van fouten in het systeem.

• Het indelen van ontdekte fouten in verschillende categorieen.

Voor het ontdekken van fouten is het van belang dat de gebruikte techniek volgende aspecten

ondersteunt:

• Snelheid in gebruik (E1): fouten moeten snel ontdekt worden. Een zeer lange rekentijd

vanaf het moment dat informatie beschikbaar is, is ongewenst. Initialisatietijd mag een

tijdje duren, gebruik niet.

• Direct beınvloedbaar (E2): de beheerder van het systeem moet de werking snel en direct

kunnen beınvloeden. Als deze merkt dat het systeem bepaalde fouten niet opmerkt,

moet het mogelijk zijn eenvoudig aanpassingen te doen, zodat deze later toch ontdekt

worden.

• Complexiteit (E3): de complexiteit mag niet te hoog worden. Complexiteit slaat hier

zowel op de rekentijd bij gebruik als de complexiteit voor de beheerder om de techniek

te gebruiken en aan te passen.

• Schaalbaarheid (E4): De techniek moet schaalbaar zijn. Een toevoeging van nieuwe

manieren voor het ontdekken van fouten mag niet leiden tot een enorme invloed op de

uitvoering.

• At run time aanpasbaar (E5): de techniek moet toelaten dat de beheerder aanpassingen

doorvoert at run time, dus zonder dat het systeem moet stoppen met uitvoering.


Tabel 2.1: Score van de verschillende technieken voor foutdetectie

Techniek E1 E2 E3 E4 E5

Regelgebaseerd systeem + + + + +

Bayesiaanse netwerken + - - + -

Classificatie + - + - -

Clustering + - + - -

Case-based reasoning - - + + -

HMM + - - + -

Beslissingsbomen + - - - +

Hieronder is weergegeven per techniek hoe ze scoren op de verschillende vereisten: Hieruit

volgt duidelijk dat een regelgebaseerde aanpak de beste techniek is voor het ontdekken van

fouten in het systeem. In deze thesis zal gebruik gemaakt worden van de Drools-bibliotheek,

een business rule management system dat gebruik maakt van forward chaining regels (meer

info in Sectie 4.3).

Voor het classificeren van fouten in verschillende categorieen, zijn volgende elementen belang-

rijk:

• Dynamisch (E1): de techniek moet toelaten dat verkregen kennis uit het verleden ge-

bruikt kan worden in latere gevallen.

• Meerdere uitkomsten mogelijk (E2): omdat het mogelijk is dat er verschillende fouten

samen voorkomen, moet de techniek in staat zijn meerdere categorieen aan te geven

voor een gevonden observatie.

• Probabiliteiten (E3): als er meerdere fouten gevonden worden, is het handig om te

weten welke fout de hoogste kans op voorkomen heeft.

• Labels aan uitkomsten (E4): als fouten onderverdeeld zijn in categorieen, is het be-

langrijk dat deze eenduidig gerapporteerd kunnen worden aan de beheerder. Hiervoor

moeten de verschillende categorieen labels hebben die verstaanbaar zijn voor de beheer-

der.

• Frequenties van observaties (E5): aangezien er met gedistribueerde systemen gewerkt

wordt, is het mogelijk dat observaties van fouten in willekeurige volgorde afgeleverd

worden. Het is dus van belang dat de frequenties van de verschillende observaties

bekeken worden en niet de opeenvolgende sequenties.

Hieronder is weergegeven per techniek hoe ze scoren op de verschillende vereisten: Hieruit


Tabel 2.2: Score van de verschillende technieken voor foutclassificatie

Techniek E1 E2 E3 E4 E5

Regelgebaseerd systeem - + - + +

Bayesiaanse netwerken + + + + +

Classificatie + - - + +

Clustering + - - - +

Case-based reasoning + + - + +

HMM + + + + -

Beslissingsbomen + - - + -

volgt dat Bayesiaanse netwerken de meest aangewezen techniek is. De implementatie van

deze techniek wordt bekomen met de Weka-bibliotheek (meer info in Sectie 4.4).

In deze thesis zal een regelgebaseerd systeem gebruikt worden om fouten te ontdekken, waarna

een Bayesiaans netwerk deze fouten zal indelen in verschillende categorieen.

Hoofdstuk 3

Use case

In deze thesis wordt een patient-monitoring systeem uitgebreid met functionaliteiten om fou-

ten te ontdekken, te classificeren en te rapporteren aan een beheerder. Wat een patient-

monitoring systeem precies is en doet, wordt uitgelegd in Sectie 3.1. Hoe de functionaliteit

uitgebreid wordt met behulp van een beheerplatform, dat bovenop het patient-monitoring sys-

teem draait en de foutherkennings-, foutclassificatie- en rapporterinsfunctionaliteiten voorziet,

wordt uitgewerkt in Sectie 3.2.

3.1 Patient-monitoring systeem

Een schematische voorstelling van een patient-monitoring systeem is afgebeeld in Figuur 3.1.

Aan de ene zijde van het systeem zitten patienten. Deze kunnen zich zowel thuis als in een

ziekenhuis bevinden. Met behulp van sensoren worden meetwaarden over de gezondheid van

deze patienten verzameld. Deze meetwaarden worden naar bepaalde services gestuurd die er

berekeningen op uitvoeren. Zo kan er een service zijn die bijvoorbeeld de algemene gezondheid

van een patient controleert op basis van bijvoorbeeld temperatuur, bloeddruk en hartslag.

Ook kan er een service zijn die aan de hand van de meetwaarden nagaat welke medicijnen

een patient zou moeten nemen en in welke dosissen. Naast deze twee voorbeelden zijn tal van

andere mogelijkheden. Al deze services kunnen nood hebben aan extra informatie over de

patienten. In dit geval kunnen ze gebruik maken van een of meerdere databanken. Eenmaal

de berekeningen doorgevoerd zijn, kan het zijn dat deze opgeslagen moeten worden in de

databank. Daarnaast kunnen resultaten ook gerapporteerd worden aan bevoegd personeel.

Denk hierbij aan een dokter of verpleegkundige die ervoor moet zorgen dat patienten de

medicijnen toegediend krijgen. Om die reden moeten de resultaten dus beschikbaar zijn voor

client pc’s en moeten ze in een leesbaar formaat geconverteerd worden. Het versturen van data

van de sensoren naar de verwerkingseenheden, het opvragen en wegschrijven van data van en

naar de databank(en), het onderling communiceren van services, alsook het rapporteren van

31

Hoofdstuk 3. Use case 32

Figuur 3.1: Schematische voorstelling van een patient-monitoring systeem

resultaten aan gebruikers gebeurt meestal via een of ander netwerk (bijvoorbeeld het internet

of een lokaal netwerk).

In een dergelijk systeem kunnen zeer veel fouten voorkomen. Hieronder volgt een lijst met

mogelijk fouten die in een dergelijk systeem geıntroduceerd kunnen worden.

• Er kunnen databankfouten zijn:

– Data die niet aanwezig is. Er kunnen bijvoorbeeld patientgegevens ontbreken,

waardoor bepaalde services hun werk niet goed kunnen doen.

– Data die niet correct is. Data kan bijvoorbeeld fout in het systeem gestopt zijn

of verouderd zijn, waardoor berekeningen die rekening houden met deze gegevens

foute resultaten opleveren.


• Ook snelheidsproblemen kunnen voorkomen:

– Trage reactie van dataophaling. Dit kan resulteren in een onaanvaardbaar trage

werking.

– Trage visuele representatie. Als men bijvoorbeeld resultaten van een bepaalde

berekening wil ophalen en de visuele representatie van deze resultaten duurt zeer

lang, zou men ervoor kunnen opteren de onbewerkte data te bekijken, terwijl de

visuele representatie van data een beter licht kan scheppen op de resultaten.

– Late versturing van gemeten waarden. Als bijvoorbeeld een patient op afstand

opgevolgd wordt, moeten de meetresultaten zo snel mogelijk verstuurd worden

naar de bevoegde instanties. Bij een late versturing van de resultaten kan het

leven van patienten in gevaar gebracht worden.

• Daarnaast kunnen er problemen zijn met services, bijvoorbeeld geen reactie of crashen.

Een dergelijke fout kan verschillende gevolgen hebben. In het ergste geval kan het

volledige systeem falen. Een ander gevolg is bijvoorbeeld het niet meer aanleveren van

berekeningen op data omdat de component die de berekeningen uitvoert faalde.

• Ook is er kans op netwerkproblemen tussen de verschillende knooppunten in het systeem.

Data (onbewerkte data, databank informatie, verwerkte data) die tussen de verschillende

componenten gestuurd wordt, kan zo de nodige componenten niet bereiken.

• Componenten van het platform kunnen crashen. Services kunnen falen, maar ook het

besturingssysteem waarop de services uitvoeren kunnen falen en zo de goede werking

van het systeem in het gedrang brengen.

• Ook hardwareproblemen kunnen zich voordoen, zoals verlies van elektriciteit, crash van

een server of harde schijf. In sommige gevallen is de fout snel opgelost (aansluiten op

een batterij om verlies van elektriciteit tijdelijk op te lossen), in andere gevallen is dit

moeilijker (als een harde schijf kapot gaat).

• Er kunnen problemen zijn met client pc’s, bijvoorbeeld als configuratieveranderingen

gebeurd zijn. Als men het systeem wil gebruiken of beheren, heeft men soms client pc’s

nodig met bepaalde configuraties om het systeem te kunnen gebruiken. Denk hierbij

bijvoorbeeld aan een arts die gegevens over een patient wil ophalen. Als de client pc

niet correct geconfigureerd is, kan het zijn dat (delen van) het systeem niet beschikbaar

zijn voor de gebruiker.

• Er kunnen zich menselijke fouten voordoen, zoals het niet (tijdig) ingeven van informa-

tie. Als het systeem afhankelijk is van menselijke invoer om correct te kunnen werken

en deze informatie wordt niet (tijdig) ingegeven, kan het systeem incorrect werken of

niets doen tot de informatie ingegeven wordt.


Als een patient-monitoring systeem niet uitgebreid is met functionaliteiten voor foutdiagnose,

kan het soms lang duren eer fouten gevonden worden. Dit kan vergaande gevolgen hebben

en het leven van patienten in gevaar brengen. Het is dus van cruciaal belang dat dergelijke

systemen uitgebreid worden om meer autonomie te voorzien. In deze thesis wordt een aanzet

hiertoe gegeven door de introductie van een beheerplatform. Dit platform is uitgewerkt in de

volgende sectie.

3.2 Beheerplatform

Om foutdiagnose in een patient-monitoring systeem te voorzien, wordt een beheerplatform

ontwikkeld dat bovenop dit systeem draait en geıntroduceerde fouten opmerkt, classificeert

en rapporteert. Er wordt ervan uitgegaan dat dit een robuust systeem is, dat zelden tot nooit

faalt. Dit wil zeggen dat dit platform het onderliggend systeem moet beheren, maar niet

zichzelf. Dit platform moet in eerste instantie merken dat het patient-monitoring systeem

zich in een ongewenste toestand bevindt. Hiervoor dient het deze te monitoren, onder andere

via logs en heartbeats. Daarnaast dient het te kunnen nagaan tot welke categorie de fout

behoort. Deze bevindingen, samen met de plaats en het tijdstip waarop de fout zich voordeed,

moeten gerapporteerd worden.

In deze thesis is vooral het ontdekken en classificeren van deze fouten van belang. Met deze

diagnose kan een beheerder fouten in het systeem eenvoudiger oplossen. Het automatisch

oplossen van de gevonden fouten door het beheerplatform, is niet opgenomen in deze thesis.

Omwille van het kritieke karakter van de toepassingen waarvoor het beheerplatform ingezet

wordt, is het af te raden alles automatisch op te lossen. Als het systeem een foute diagnose

stelde (bijvoorbeeld een verkeerde classificatie van een gevonden fout), zou het proberen

oplossen ervan een negatieve invloed op het systeem kunnen hebben. Om deze reden worden

bevindingen gerapporteerd, en met deze inzichten kan een menselijke beheerder de beste acties

kiezen. Hieronder worden de hoofdlijnen van het beheerplatform besproken. Hierbij wordt

belang gehecht aan zowel de architectuur als aan de werking. In Hoofdstuk 4 wordt dieper

ingegaan op de redenering, die de hoofdzaak van dit platform vormt.

3.2.1 Architectuur

De architectuur van het beheerplatform is afgebeeld in Figuur 3.2. Het platform bevindt

zich op een fysieke node. Een gecentraliseerde aanpak is hier gewenst omdat op deze manier

met behulp van informatie over het volledige systeem een diagnose gesteld kan worden. Elke

component afzonderlijk beheren is geen goed idee, want bepaalde fouten beınvloeden meerdere

componenten van het systeem. Elke component afzonderlijk zou een deel van de fout kunnen


Figuur 3.2: Architectuur van het beheerplatform

vinden, maar een goede diagnose zou heel moeilijk worden. Om deze reden werd voor een

gecentraliseerde aanpak gekozen.

Het platform bestaat uit drie componenten. De communicatie met het onderliggend systeem

gebeurt door middel van een event channel . De heartbeat module voorziet een functionaliteit

om enerzijds nodes uit het beheerde platform te registreren en anderzijds falende nodes te de-

tecteren. De reasoning component voert de taken uit om fouten te ontdekken, te classificeren

en te rapporteren. Ook voorziet het de mogelijkheid om fouten in het systeem automatisch

op te lossen. Na de detectie van fouten, kan deze component bepaalde acties specificeren om

de fouten op te lossen.

Op het ogenblik dat componenten uit het onderliggend systeem worden geactiveerd, beginnen

ze een heartbeat te sturen naar de event channel . Op deze manier worden ze geregistreerd

en kan de heartbeat module nagaan of de toestellen nog actief en beschikbaar zijn. Hiervoor

moeten de externe toestellen wel weten hoe het beheerplatform moeten contacteren. Periodiek

wordt de GetInfo-interface aangesproken om informatie over de werking van een component

in het onderliggend systeem te weten te komen. Het betreft hier niet informatie die door het

onderliggend systeem gebruikt wordt bij de uitvoering van zijn taken, maar metadata over de

status en werking van het systeem. Is er een actie vereist omwille van ongewenst gedrag of

falende hartslag, dan wordt de ExecuteAction-interface aangesproken om een bepaalde actie

op het systeem uit te voeren.

De external device component is in principe niet een component, maar een hele reeks van

componenten van het patient-monitoring systeem. Als het platform bovenop het systeem


afgebeeld in Figuur 3.1 zou draaien, zouden alle sensoren, de databank, de health check service,

de pedication proposal service als alle client pc’s externe toestellen zijn die alle gekoppeld zijn

aan het beheerplatform.

Event channel

De event channel voorziet communicatiemogelijkheden tussen de verschillende componenten

van het beheerde systeem en de componenten van het beheerplatform. Het idee is gelijkaardig

aan de busstructuur voorgesteld in Sectie 2.1.4. Alle componenten (zowel de componenten

van het beheerde systeem als de componenten van het beheerplatform) kunnen met elkaar

communiceren door middel van de event channel . Het grote verschil met de busstructuur

uit Sectie 2.1.4 is dat er hier geen sprake is van een MAPE controlelus. De event channel

zorgt ervoor dat gecomprimeerde en geencrypteerde informatie verstuurd door het onderlig-

gend systeem gedecomprimeerd en gedecrypteerd wordt, waarna de informatie aan de juiste

module wordt aangeboden. In de andere richting zorgt deze ervoor dat informatie gecompri-

meerd en geencrypteerd wordt en naar de juiste module in het onderliggend systeem gestuurd

wordt. De event channel biedt een interface aan aan het onderliggend systeem, namelijk de

functionaliteit om een heartbeat te sturen. Deze wordt dan doorgegeven aan de heartbeat

module. Intern worden twee interfaces aangeboden, namelijk GetInfo en TakeAction. De

GetInfo-interface wordt door de reasoning component aangesproken om loginformatie van

een bepaalde module te verkrijgen. De TakeAction-interface dient om acties op een bepaalde

component van het onderliggend systeem uit te voeren. Dit laatste is niet geımplementeerd

in deze thesis, doch stubs zijn voorzien.

Heartbeat module

Bij de initialisatie van het onderliggend systeem, dienen alle componenten zich te registreren

bij het beheerplatform. Dit doen ze door een heartbeat te sturen met volgende informatie:

• Locatie van de node: de URL waarop deze node te vinden is. Deze informatie wordt

gebruikt om loginformatie van de component te kunnen ophalen en op een eenduidige

manier de component te kunnen aanduiden bij de rapportering.

• Locaties van nodes die aangesproken worden: als de component die geregistreerd wordt

andere componenten gebruikt tijdens zijn uitvoer, moeten deze vervat zitten in het

heartbeat bericht. Deze informatie wordt door de reasoning component gebruikt om een

logische topologie op te stellen die kan worden gebruikt om bijvoorbeeld fouten die door

het systeem propageren als enkele fout te aanzien.

• Actiecodes voor acties: iedere node kan voorzien in acties die kunnen uitgevoerd worden

door het beheerplatform om fouten op te lossen. In het heartbeat bericht worden dus


de actiecodes voor deze ondersteunde acties opgenomen. In deze thesis wordt vooral

nadruk gelegd op het ontdekken van fouten, niet op de automatische oplossing ervan.

Om deze reden zijn de acties niet in het systeem geımplementeerd. Toch zijn er stubs

voorzien voor eventuele uitbreidingen.

• Last heartbeat bit: als deze bit op 1 gezet wordt, wil dit zeggen dat de node op een

normale wijze afsluit en wordt deze verwijderd uit de logische topologie. Het zorgt er

dus voor dat componenten het systeem kunnen verlaten.

Als een nieuwe component geregistreerd wordt bij de heartbeat module, of een heartbeat be-

richt met de last heartbeat bit op 1 ontvangen wordt, dan wordt de reasoning component op

de hoogte gebracht van het registreren of uitschrijven van de module die dit bericht heeft ver-

stuurd. Voor elke geregistreerde module wordt een tijdsstempel bijgehouden waarin de tijd

van het laatst ontvangen bericht opgeslagen is. Onder normale omstandigheden sturen de

verschillende componenten iedere minuut een heartbeat bericht. De heartbeat module houdt

rekening met de mogelijkheid dat een bericht verloren kan gaan en markeert een module als

onbeschikbaar als er geen bericht ontvangen werd binnen de twee minuten en dertig secon-

den na het vorig bericht (dertig seconden om het eventueel laat aankomen van een bericht te

overbruggen). Als een component te lang op zich liet wachten om een heartbeat bericht te stu-

ren en dus als onbeschikbaar gemarkeerd wordt, wordt de ReportBrokenComponent-interface

aangesproken om dit te melden aan de reasoning component.

Reasoning component

De reasoning component voert de eigenlijke functionaliteit van het beheerplatform uit. Het

vraagt periodiek informatie over de geregistreerde nodes op en, met behulp van de logische

topologie en de verkregen informatie, wordt nagegaan of er zich fouten in het systeem voor-

deden. Is dit het geval, dan worden ze geclassificeerd en gerapporteerd. Als de reasoning

component beslist dat er een actie uitgevoerd moet worden in het onderliggend systeem kan

het de TakeAction-interface van de event channel aanroepen. Bij de oproep worden een ac-

tiecode en parameters meegegeven. Op die manier weet de aangesproken component van het

beheerde systeem welke actie deze moet uitvoeren en met welke parameters. Een simpel voor-

beeld van een actie is het opnieuw opstarten van een component. In de parameters kunnen

variabelen opgeslagen worden die de component nodig heeft om de herinitialisatie door te

voeren, of eventueel informatie over de wijze van het heropstarten (bijvoorbeeld soft reboot

of hard reset). Het oproepen van de ReportBrokenComponent-interface door de heartbeat

module bij het ontdekken van een falende node, start ook een nieuwe controle (naast het

periodiek controleren) van het systeem (aangezien er waarschijnlijk een fout in het systeem

geslopen is). Meer informatie over deze component is te vinden in het volgend hoofdstuk

(Hoofdstuk 4).

Hoofdstuk 4

Oorzaakdetectie

In dit hoofdstuk wordt de redeneercomponent van het beheerplatform besproken. De ver-

schillende onderdelen van deze component worden behandeld in de volgende sectie. Hierna

volgt een high-level bespreking van de taken van ieder element. Vervolgens wordt dieper

ingegaan op de twee belangrijkste zaken van de redeneercomponent, namelijk de regelgeba-

seerde analysecomponent, die fouten in het systeem ontdekt en afbakent en de Bayesiaanse

detectiecomponent, die fouten in verschillende categorieen onderverdeelt.

Doorheen dit hoofdstuk wordt, bij wijze van illustratie, een zeer eenvoudig voorbeeld aange-

houden. We gaan ervan uit dat het te beheren systeem uit twee componenten bestaat. De

eerste is een sensor die de bloeddruk van een patient meet. De tweede is een medicatieservice

die nagaat of de patient medicijnen nodig heeft om de bloeddruk te verhogen of te verlagen.

De sensor stuurt periodiek informatie via een netwerk naar de medicatieservice. Op een be-

paald tijdstip faalt het netwerk, waardoor de meetwaarden van de sensor de medicatieservice

niet meer bereiken.

4.1 Architectuur

De architectuur van de redeneercomponent is afgebeeld in Figuur 4.1. De extern aangeboden

interfaces werden reeds besproken in Sectie 3.2. De monitorcomponent krijgt informatie

van de hearbeat module over de geregistreerde componenten en vraagt periodiek informatie

over de geregistreerde modules op. De verkregen informatie wordt naar de system analysis

component gestuurd. Deze gaat na of er zich fouten in het systeem bevinden en geeft de

informatie door aan de error/cause detection component. Indien mogelijk en nodig kunnen

acties uitgevoerd worden op het onderliggend systeem met behulp van de action execution

component. Informatie kan aan de beheerder aangereikt worden via de reporting component.

De storage component voorziet in opties om informatie permanent op te slaan.

38

Hoofdstuk 4. Oorzaakdetectie 39

Figuur 4.1: Architectuur van de redeneercomponent

In deze architectuur zit de MAPE controlelus vervat. De monitorstap in de controlelus wordt

uitgevoerd door de monitorcomponent. De analysestap wordt uitgevoerd door de system

analysis en error/cause detection componenten. De plannings- en uitvoeringsstappen worden

geımplementeerd door de action execution component. Deze component is op dit ogenblik niet

geımplementeerd. Wel zijn stubs voorzien voor eventuele uitbreiding. De storage component

wordt gebruikt om kennis permanent op te slaan en te kunnen gebruiken in elke stap van de

controlelus. Een component die niet in de MAPE controlelus zit, is de reporting module. Het

is echter belangrijk dat deze in dit systeem opgenomen wordt.


4.2 Werking

4.2.1 Monitor

De monitor start periodiek de controle van het beheerde systeem. Daarnaast kan een niet-

geplande controle ook gestart worden door de heartbeat module als deze merkt dat een com-

ponent geen hartslag meer stuurt. De monitor houdt een lijst van geregistreerde componenten

bij en vraagt dus periodiek, of op aanvraag, loginformatie van al de componenten op. Deze

informatie wordt, samen met de kennis over het onderliggend systeem, aangeboden aan de

system analysis component. Deze kennis van het onderliggend systeem is in de eerste plaats

de logische topologie, die wordt opgesteld met behulp van de heartbeat functionaliteit. Een

voorbeeld van een topologie is afgebeeld in Figuur 4.2 en bevat informatie over welke compo-

nenten met elkaar communiceren (de topologie in de afbeelding is degene die gebruikt werd

tijdens de uitvoering van deze thesis). Naast de topologie wordt ook de beschikbaarheid van

Figuur 4.2: Logische topologie

de componenten aan de informatie toegevoegd. Als de event channel de loginformatie van

een component niet kon ophalen, wordt deze component aangeduid als onbeschikbaar. Er

worden ook twee tijdsstempels toegevoegd aan de informatie. De ene tijdsstempel houdt de

tijd op de component bij, terwijl de andere de tijd van het beheerplatform opslaat. Deze twee

tijdsstempels kunnen gebruikt worden om een ruwe vorm van synchronisatie door te voeren.

Dit kan nodig zijn als bijvoorbeeld bij een bepaalde component de tijd niet goed ingesteld

is. Deze synchronisatie kan vervangen worden door een van de vele bestaande alternatieve

technieken en is afhankelijk van systeem tot systeem. Als het beheerde systeem het toelaat

om de klokken op de verschillende componenten te synchroniseren, kan de synchronisatie in

het beheerplatform zelfs volledig weggelaten worden. Naast het bundelen van bovenvermelde

data wordt ook de storage component aangesproken om te controleren of er fouten uit een


vorige iteratie meegenomen moeten worden tijdens deze iteratie. Dit is het geval als er zich

tijdens de vorige iteratie nog een fout in het systeem bevond. Het kan zijn dat de nieuwe

informatie meer licht schept op de aard van de fout.

In het voorbeeld van de twee services werkt deze module dus als volgt. Periodiek zal de

monitor beide componenten aanspreken en de loginformatie ophalen. Aan de informatie

van de sensor wordt ook de locatie van de medicatieservice toegevoegd, daar de sensor deze

component nodig heeft om correct te kunnen functioneren. Aan de informatie van de me-

dicatieservice worden geen locaties van andere componenten toegevoegd. Deze service heeft

geen andere componenten nodig om te kunnen functioneren. De topologie van dit systeem

is zoals in Figuur 4.2, maar enkel met de componenten bloodPressureService en medicati-

onService. Als informatie van beide componenten opgehaald kan worden, wordt er nog een

parameter toegevoegd aan de informatie van elk van de twee componenten die aangeeft dat

ze nog actief en beschikbaar zijn. Bij de ophaling van de informatie wordt ook een tijdsstem-

pel meegestuurd van de component naar het beheerplatform. Het beheerplatform slaat ook

deze informatie, samen met de huidige tijd van het platform op bij de twee componenten.

Deze informatie kan gebruikt worden, indien nodig, om synchronisatie door te voeren. De

laatste actie die uitgevoerd wordt, is de controle of er loginformatie van een vorige iteratie

dient bijgevoegd te worden. Is dit het geval, dan wordt deze aan het begin van de nieuwe

informatie toegevoegd. De lijst met informatie over de verschillende componenten wordt in

een encapsulator -object gestopt, zodat er met een enkel object gewerkt kan worden in de

volgende stappen. Dit object wordt geleverd aan de system analysis component.

4.2.2 System analysis

Het doel van de system analysis component is het afbakenen van fouten. Deze component

zorgt ervoor dat fouten die in het systeem voorkomen, ontdekt en afgelijnd worden. Ook zal

het oninteressante observaties uit de informatie filteren en continue waarden discretiseren.

Dit gebeurt met behulp van een regelgebaseerd systeem. Er wordt in detail ingegaan op dit

systeem in Sectie 4.3.

Vooraleer het regelgebaseerde systeem de informatie verkregen van de monitor verwerkt, wor-

den eerst twee voorbewerkingen uitgevoerd.

• De loginformatie (typisch een lange string) wordt opgesplitst in verschillende entries.

De tekst wordt dus uiteengehaald op een identieke wijze zoals ze opgebouwd werd.

Dankzij deze voorbewerking is het eenvoudiger om regels te schrijven die fouten kunnen

ontdekken.

• Aan iedere zender-ontvangerrelatie wordt een label toegekend over de manier waarop

informatie heen en weer gestuurd wordt. Mogelijke manieren zijn:


– Triggered : de zender stuurt informatie naar de ontvanger op het ogenblik dat het

informatie ontvangt van een andere module. De modules die triggers zijn voor

deze communicatie worden ook opgeslagen.

– Periodiek: de zender is geen triggered zender en stuurt periodiek informatie naar

de ontvanger. De periode dient hier bijgehouden te worden.

– Random: de zender valt niet onder vorige categorieen, maar stuurt wel informatie

naar een ontvanger.

– Geen: de module is geen zender voor bepaalde communicatie met een ontvanger.

Met behulp van deze voorbewerking is het mogelijk om regels te schrijven om bijvoor-

beeld na te gaan of een component nog steeds op verwachte tijdstippen data verstuurt.

Na deze voorbewerkingen, voert het regelgebaseerd systeem de instructies op de informatie

uit en worden fouten afgebakend. De informatie over de gevonden fouten wordt gebundeld en

naar de error/cause detection component gestuurd, waar nagegaan wordt welke fouten precies

optraden. Als een fout wordt gevonden die duurt tot aan de laatste entry van een log, wordt

deze opgeslagen met behulp van de storage component om in een volgende iteratie opnieuw

gebruikt te worden om de fout beter af te bakenen en te classificeren.

Laten we opnieuw het voorbeeld van hierboven nemen. Het encapsulator -object wordt afge-

leverd door de monitor. We stellen dat de loginformatie afgebeeld in Listing 4.1 de verkregen

loginformatie van de bloeddruksensor is en dat de informatie afgebeeld in Listing 4.2 de ver-

kregen informatie van de medicatieservice is. Deze informatie werd gelezen op het moment

1 Mar 11 , 2012 5 : 5 5 : 3 0 PM BloeddrukSensor zendBloedDruk

2 INFO: Bloeddruk 105 over 65 verzonden


4 SEVERE: WebException FileNotFoundException IOException





Listing 4.1: Loginformatie van de bloeddruksensor

dat het netwerk tussen beide componenten in faling was. De bloeddruk probeerde iedere

minuut een waarde te sturen, maar dit lukte slechts een maal. De andere drie maal kon de

informatie niet verstuurd worden. Bij de eerste mislukte poging kwam er nog een deel van de

informatie bij de medicatieservice aan, maar niet alles, waardoor de informatie niet gedeseri-

aliseerd kon worden en er een StreamCorruptException opgegooid werd. Bij de sensor kon de


1 Mar 11 , 2012 5 : 5 5 : 3 0 PM Med i ca t i eSe rv i c e ontvangBloedDruk

2 INFO: Bloeddruk 105 over 65 ontvangen

3 Mar 11 , 2012 5 : 5 6 : 3 0 PM Med i ca t i eSe rv i c e ontvangBloedDruk

4 SEVERE: StreamCorruptedException

Listing 4.2: Loginformatie van de medicatieservice

medicatieservice niet gevonden worden en werden drie exceptions opgegooid. Deze drie zijn

gelinkt aan elkaar daar de IOException opgegooid werd omdat het wsdl-bestand van de ser-

vice niet gevonden kon worden. Deze exception zorgde ervoor dat een FileNotFoundException

opgegooid werd, die op zijn beurt ervoor zorgde dat een WebException opgegooid werd. In

beide gevallen staat er normaal nog een heleboel meer informatie in de logs (zoals stacktraces

en zo), maar dit is niet van belang voor dit voorbeeld en werd om deze reden weggelaten.

De informatie is een lange string en wordt gesplitst met de eerste voorbewerking. De infor-

matie van de bloeddruk wordt opgesplitst in vier entries, elke minuut een. De informatie van

de medicatieservice wordt in twee entries gesplitst. Met behulp van de tweede voorbewerking

wordt het zendgedrag van de componenten nagegaan. Voor de bloeddrukservice gevonden

wordt dat deze periodiek stuurt met een periode van een minuut. De medicatieservice stuurt

geen berichten naar iemand en is dus geen zender. Deze informatie wordt ook aan de in-

formatie van de componenten gekoppeld. Het encapsulator -object met de nieuwe informatie

dient als input voor het regelgebaseerd systeem. De output is hetzelfde object, maar nu met

een lijst van fouten (als er gevonden zijn). In het voorbeeld bevat deze lijst een object. Dit

object bevat informatie over de betrokken modules (de bloeddruksensor en de medicatieser-

vice), het tijdstip (tussen 5u56 en nu, aangezien de fout duidelijk nog niet afgelopen was

bij het lezen van de fout) en de gefilterde observaties van de fout (WebException, FileNot-

FoundException, IOException, WebException, FileNotFoundException, IOException, We-

bException, FileNotFoundException, IOException, StreamCorruptedException). Hoe deze

informatie precies verkregen wordt, wordt besproken in Sectie 4.3. Het encapsulator -object

wordt doorgegeven aan de error/cause detection module om de fout te classificeren.

4.2.3 Error/cause detection

Het doel van de error/cause detection module is het classificeren van fouten in verschillende

categorieen. Dit gebeurt met behulp van een naıef Bayesiaans netwerk. Meer informatie over

de precieze werking is te vinden in Sectie 4.4. Eens de gevonden fouten geclassificeerd zijn,

gebeuren er drie dingen:

• De reporting component wordt aangeroepen en de informatie wordt aangeleverd. Deze

component zorgt ervoor dat beheerders op de hoogte gebracht worden van voorkomende


fouten.

• De informatie wordt permanent opgeslagen met behulp van de storage module. Deze

informatie kan dan later door een beheerder bekeken worden of opgenomen worden in

de trainingsset van de error/cause detection component.

• De informatie wordt aangeleverd aan de action execution component. Deze kan de

informatie gebruiken om eventueel corrigerende acties in het systeem uit te voeren. In

deze thesis is deze component niet geımplementeerd. Er zijn wel stubs voorzien, wat

eventuele uitbreiding mogelijk maakt.

Als we vorig voorbeeld er weer bij nemen, dan hebben we als input van deze component

een encapsulator -object dat informatie over de fout bevat. Met behulp van de observaties

wordt deze fout geclassificeerd en aan het foutobject wordt het label ‘netwerkfaling’ gehangen.

Daarna wordt het encapsulator -object naar de drie componenten gestuurd.

4.2.4 Reporting

Het doel van de reporting module is het aanbieden van een grafisch overzicht van het systeem

en de fouten aan de beheerder. In deze thesis is dit een zeer eenvoudige GUI met volgende

functionaliteiten:

• Een grafisch overzicht van het onderliggend systeem. De logische topologie kan zo

eenvoudig visueel weergegeven worden (zie Figuur 4.3).

• Een tekstuele rapporteringsmodule waarin fouten kunnen gerapporteerd worden. Er

wordt aangeduid welke componenten betrokken waren bij de fout, wanneer de fout zich

afspeelde en tot welke categorie(en) ze kan behoren (samen met de probabiliteit dat

deze fout in de categorie zit). Een voorbeeld is te vinden in Figuur 4.4.

4.2.5 Action execution

Het doel van de action execution component is het oplossen van gevonden fouten. Het krijgt

informatie over de gevonden fout (type fout, tijdstip, locatie). Met behulp van deze informatie

en de mogelijke acties in het beheerde systeem (de mogelijke acties voor iedere component

worden, zoals eerder vermeld, via heartbeat berichten van het beheerde systeem verkregen),

worden een of meerdere acties uitgevoerd op het beheerde systeem. Met behulp van deze

acties wordt getracht de fout(en) uit het systeem te verwijderen. Let wel dat deze component

niet geımplementeerd is in deze thesis. Stubs zijn voorzien voor eventuele uitbreiding, maar

de implementatie is niet gebeurd.


Figuur 4.3: Visuele representatie van het beheerde systeem

Figuur 4.4: Rapportering van fouten


4.3 Regelgebaseerde analysecomponent

Zoals eerder aangehaald, worden twee voorbewerkingen uitgevoerd op de data verkregen van

de monitor. Daarna worden de regels toegepast om fouten te ontdekken. De regels worden

geımplementeerd door middel van de Drools-bibliotheek1. Drools is een business rule mana-

gement system (BRMS) dat, met behulp van een rule engine gebaseerd op forward chaining

(meer informatie over forward chaining is te vinden in Sectie 2.3.1) toelaat om regels te spe-

cificeren en toe te passen waar nodig. Deze bibliotheek maakt gebruik van het Rete algoritme

om de regels uit te voeren. Dit algoritme zorgt ervoor dat niet alle antecedenten van de regels

gecontroleerd hoeven te worden om te weten of de consequenten van de regels uitgevoerd

moeten worden en is een van de efficientste algoritmes waar rule engines gebruik van kunnen

maken. Meer informatie over dit algoritme is te vinden in [16]. De Drools rule engine on-

dersteunt de JSR-94 standaard. Deze standaard voorziet een API voor rule engines om via

eenvoudige JAVA code de rule engine te kunnen gebruiken. Met behulp van Drools kunnen

enerzijds regels en anderzijds functies die deze regels ondersteunen geschreven worden.

Een voorbeeld van een functie vanuit de thesis is te vinden in Listing 4.3. Deze functie

zoekt in een lijst van intervallen naar een interval dat overlapt met een ander interval. Er

wordt ook gebruik gemaakt van een lijst met intervallen die niet gekozen mogen worden. De

functie wordt gebruikt bij het combineren van fouten om verschillende fouten in overlappende

intervallen te combineren tot een fout. Interessant om op te merken is dat er op dit ogenblik

nog geen ondersteuning is voor lijsten waarin types zijn gespecificeerd in het return-type of

de parameters. Er moet dus een extra typecasting worden gedaan in de functie.

Een voorbeeld van een van de regels uit de thesis is aangegeven in Listing 4.4. Deze regel gaat

na of er ergens een exception werd gelogd. Is dit het geval, dan worden de opeenvolgende

entries die exceptions bevatten samengenomen als een fout. De programmeertaal die voor

deze regels gebruikt wordt, lijkt heel sterk op de JAVA programmeertaal. Het voordeel hiervan

tegenover andere bibliotheken is dat er geen volledig nieuwe taal geleerd moet worden en dat

regels begrepen kunnen worden door iedereen met kennis van JAVA.

De naam van de regel is “contains exception” en moet uniek zijn. Daaronder wordt een at-

tribuut gedefinieerd. Het sleutelwoord “salience”, gevolgd door een integerwaarde (positief

of negatief), bepaalt de prioriteit van de regel. Standaard staat deze waarde op nul. Dit

wil zeggen dat alle regels een even hoge prioriteit hebben en dat ze in willekeurige volgorde

uitgevoerd kunnen worden. In de thesis willen we eerst fouten ontdekken en daarna pas dis-

cretiseren en filteren. Om deze reden krijgen regels om fouten te ontdekken een hogere waarde

(hier 10), waardoor ze eerder uitgevoerd worden dan discretisatie- en filterregels. Na dit at-

tribuut volgt de eigenlijke regel. Eerst komt het antecedent, na het sleutelwoord “when”,

1http://www.jboss.org/drools


1 f unc t i on i n t f indOver lap ( L i s t i n t e r v a l 1 , L i s t candidates1 , L i s t

e x c l u s i o n L i s t 1 ) {2 List<Long> i n t e r v a l = ( List<Long>) i n t e r v a l 1 ;

3 List<List<Long>> cand idate s = ( List<List<Long>>) cand idates1 ;

4 List<Integer> e x c l u s i o n L i s t = ( List<Integer >) e x c l u s i o n L i s t 1 ;

5 f o r ( i n t i = 0 ; i < cand idate s . s i z e ( ) ; i++) {6 i f ( ! e x c l u s i o n L i s t . conta in s ( i ) ) {7 i f ( cand idate s . get ( i ) . get (0 ) >= i n t e r v a l . get (0 ) &&

cand idate s . get ( i ) . get (0 ) <= i n t e r v a l . get (1 )

8 | | cand idate s . get ( i ) . get (1 ) >= i n t e r v a l . get (0 )

&& cand idates . get ( i ) . get (1 ) <= i n t e r v a l . get

(1 )

9 | | cand idate s . get ( i ) . get (0 ) <= i n t e r v a l . get (0 )

&& cand idates . get ( i ) . get (1 ) >= i n t e r v a l . get

(1 ) ) {10 re turn i ;

11 }12 }13 }14 re turn −1;

15 }

Listing 4.3: Voorbeeld van een functie gebruikt in de thesis

daarna het consequent, na het sleutelwoord “then”. Enkel als de condities van het antecedent

vervuld zijn, wordt het consequent uitgevoerd. Hier stelt het antecedent dat het object dat

als parameter meegegeven wordt aan de rule engine van het type “Encapsulator” moet zijn.

Is dit het geval, dan wordt het consequent uitgevoerd. In dit consequent worden de informa-

tieobjecten van de verschillende componenten een voor een doorlopen. Als de loginformatie

van een component het woord exception bevat, worden alle entries apart gecontroleerd. Op-

eenvolgende entries waarin exception voorkwam, worden samengenomen tot een fout. Als een

volledige fout afgelijnd is, wordt de fout opgeslagen (met behulp van de addErrorObserva-

tion-methode). Ook worden de indices van de entries bijgehouden, zodat, na discretisatie en

filteren van de informatie, toch nog de originele logentries achterhaald kunnen worden.

In deze thesis komen drie soorten regels aan bod. Deze regels moeten in dezelfde volgorde

uitgevoerd worden als hier opgelijst:

• Regels tot het ontdekken en afbakenen van fouten: deze regels ontdekken fouten op

basis van kennis over het systeem. Een voorbeeld van een dergelijke regel is deze in


1 r u l e ‘ ‘ c onta in s except ion ’ ’

2 s a l i e n c e 10

3 when

4 $enc : Encapsulator ( )

5 then

6 f o r ( LogObject $ l : $enc . getLogObjects ( ) ) {7 i f ( $ l . getContent ( ) . toLowerCase ( ) . conta in s ( ‘ ‘ except ion ’ ’ ) ) {8 $ l . s e tVa l i d ( f a l s e ) ;

9 List<Str ing> e n t r i e s = $ l . g e t E n t r i e s ( ) ;

10 St r ing $temp = ‘ ‘ ’ ’ ;

11 f o r ( i n t i = 0 ; i < e n t r i e s . s i z e ( ) ; i++){12 i f ( e n t r i e s . get ( i ) . toLowerCase ( ) . conta in s ( ‘ ‘

except ion ’ ’ ) ) {13 $temp += e n t r i e s . get ( i ) + newl ine ;

14 $ l . addErrorEntry ( i ) ;

15 } e l s e {16 i f ( $temp != ‘ ‘ ’ ’ ) {17 $temp = $ l . getModuleLocation ( ) + ‘ ‘ ; ; ’ ’ +

newl ine + $temp ;

18 $ l . addErrorObservation ( $temp ) ;

19 $temp = ”” ;

20 }21 }22 }23 i f ( $temp != ‘ ‘ ’ ’ ) {24 $temp = $ l . getModuleLocation ( ) + ‘ ‘ ; ; ’ ’ + newl ine +

$temp ;

25 $ l . addErrorObservation ( $temp ) ;

26 }27 }28 }29 end

Listing 4.4: Voorbeeld van een regel gebruikt in deze thesis

Listing 4.4. Als deze regel toegepast wordt op het voorbeeld van de bloeddruksensor

en de medicatieservice, bevat het object waarin de informatie van de bloeddruksensor

vervat zit een fout waarin de drie foutentries voorkomen. Ook het object met informatie

over de medicatieservice bevat nu een fout met een enkele entry.


• Regels tot het combineren van fouten in een enkele node of tussen nodes die met elkaar

communiceren: als fouten voorkomen in overlappende intervallen in een node of tus-

sen nodes die met elkaar communiceren, dan worden ze samengenomen tot een enkele

fout. Een voorbeeld kan gevonden worden in een regel die de twee fouten uit het vorig

item combineert tot een enkelvoudige fout. Deze regel zal de fout van de bloeddruk-

sensor vinden en zien dat de sensor informatie naar de medicatieservice stuurt. Om

deze reden wordt de medicatieservice gecontroleerd en wordt de fout gevonden die deze

bevat. Aangezien deze fout zich in hetzelfde tijdsinterval voordeed als de fout in de

bloeddruksensor, worden beide fouten gecombineerd. Deze fout wordt in het encap-

sulator -object opgeslagen (in plaats van bij de afzonderlijke componenten omdat nu

meerdere componenten betrokken zijn bij een fout). De informatie van de twee fouten

wordt samengenomen tot een. Beide componenten zijn beınvloed door de fout, het

tijdsinterval is dit van de bloeddrukservice en de observaties van de twee fouten worden

samengenomen.

• Regels tot het filteren van observaties: in een laatste stap worden de foutobservaties

gefilterd en worden continue waarden gediscretiseerd. Als weer hetzelfde voorbeeld ge-

nomen wordt, zal deze fout enkel de exceptions overhouden. Het sleutelwoord SEVERE

levert geen nuttige informatie, ook het tijdstip of module niet. Om deze reden wor-

den deze weggefilterd. Mochten er nog waarden in de fouten zitten, dan zouden deze

gediscretiseerd worden. De discretisatie in de thesis gebeurt uniform. Er zijn een on-

dergrens, een bovengrens en een aantal intervallen gedefinieerd. Al de waarden kleiner

dan de ondergrens worden gelijk gesteld aan de ondergrens. Alle waarden groter dan

de bovengrens met de bovengrens en het interval tussen beide grenzen wordt onderver-

deeld in een aantal intervallen gespecificeerd door de derde parameter. Hoe hoger deze

waarde, hoe meer intervallen en hoe kleiner deze worden.

Onderlinge volgordes van regels binnen deze categorieen maken niet uit. Als bijvoorbeeld eerst

de oninteressante woorden uit de observaties gefilterd worden en daarna pas de discretisatie

doorgevoerd wordt of omgekeerd, geeft dit hetzelfde resultaat.

4.4 Bayesiaanse detectiecomponent

Nadat de analysecomponent de fouten afgebakend heeft, is het de beurt aan de detectiecom-

ponent om zijn werk te doen. Met de observaties geleverd door de analysecomponent worden

fouten in categorieen onderverdeeld. Dit gebeurt aan de hand van een Bayesiaans netwerk dat

observaties (en in het bijzonder de frequenties waarin ze voorkomen) koppelt aan verschillende

categorieen van fouten.

Het idee achter het gebruik van een dergelijk netwerk stamt voort uit de filtering van SPAM


e-mail. Deze techniek werkt als volgt. Het netwerk wordt opgebouwd met behulp van een

reeks e-mails waarvan bekend is of ze SPAM zijn of niet. Elke e-mail wordt gesplitst in een

lijst van woorden en de frequentie waarin ze voorkomen. Deze lijsten dienen als trainingsset

voor het opbouwen van het netwerk. Als er een nieuwe e-mail binnenkomt, wordt ook deze

gesplitst in een lijst met woorden en hun frequenties. Deze observaties worden aan het netwerk

meegedeeld en zo wordt de probabiliteit dat de nieuwe e-mail een spam bericht is, berekend.

Elke e-mail wordt op die manier geclassificeerd. Als de kans dat de nieuwe e-mail SPAM is,

hoger is dan vijftig procent, dan wordt deze aanzien als SPAM. In het andere geval is deze

geen SPAM.

Het idee achter SPAM filtering kunnen we doortrekken voor het classificeren van fouten in

categorieen. We kunnen namelijk de loginformatie van de verschillende nodes zien als e-

mails en de verschillende mogelijke categorieen van fouten als de uitkomst waarvan we de

probabiliteiten willen weten. Bij het maken van deze analogie moet wel op enkele dingen

gelet worden:

• Om gebruik te mogen maken van een naıef Bayesiaanse aanpak, moeten de observaties

in het netwerk onafhankelijk zijn van elkaar. Dit wil zeggen dat de verschillende woor-

den in de loginformatie volledig ongecorreleerd moeten zijn. Dit is uiteraard niet het

geval. Doordat de regelgebaseerde analysecomponent verschillende woorden die geen

of weinig informatie bevatten uitfiltert, kan de correlatie verlaagd worden. Toch blijft

er een zekere correlatie tussen de verschillende woorden in de loginformatie bestaan.

Dit is echter geen probleem. Ook bij spamfilters is aan deze voorwaarde niet voldaan

(in vrijwel elke taal zijn er bepaalde woorden die samen voorkomen of bepaalde se-

quenties van woorden). Toch werkt deze techniek zeer goed, waardoor ook in het geval

van foutclassificatie kan aangenomen worden dat deze beperking geen problemen zal

opleveren.

• SPAM filtering is een vorm van tekstclassificatie. Dit wil zeggen dat verschillende

karaktersequenties als verschillende woorden aanzien worden. In de loginformatie van de

verschillende nodes zitten echter niet alleen woorden. Er kunnen ook continue waarden

in voorkomen. Om ervoor te zorgen dat het opgebouwde netwerk niet oneindig groot

wordt, moet een zekere discretisatie doorgevoerd worden. Ook dit wordt gedaan in de

analysecomponent, zoals eerder besproken. Hoe fijner de discretisatie, hoe groter het

netwerk wordt en hoe langer de classificatietijd, maar hoe nauwkeuriger de verschillende

waarden.

• In e-mails heb je een duidelijk afgebakend begin en einde. Hier heb je dit niet. Door

het samennemen van opeenvolgende logentries en entries van verschillende nodes met

overlappende intervallen, kan dit in de meeste gevallen opgelost worden. Toch is er nog

een probleem bij het begin en einde van opgehaalde loginformatie. Stel dat een node


fout werkt op het moment dat informatie opgevraagd wordt. Dan zit er informatie over

de fout in het logbestand tot op het einde. Bij ophaling van de volgende informatie

zit er informatie over diezelfde fout in het begin. Dit hoort eigenlijk samen, maar zal

als apart worden aanzien (het beheerplatform heeft het tweede deel nog niet als het de

loginformatie van het eerste deel analyseert). Zo kunnen volgende fouten optreden:

– Een fout wordt twee maal gedetecteerd, wat in principe niet zo erg is.

– Een fout wordt fout geclassificeerd, dus het verkeerde fouttype wordt gevonden

door een tekort aan informatie.

– Een fout wordt niet als fout aanzien omdat er niet genoeg informatie in het logbe-

stand zit.

Ook dit probleem kan opgelost worden en werd voorzien in de analysecomponent. Als

er zich op het einde van het logbestand van een bepaalde node nog een fout in het

systeem bevindt, dan wordt deze informatie meegenomen naar de volgende iteratie. Op

deze manier kunnen fouten nog steeds twee maal gedetecteerd worden (ook onvolledige

informatie wordt gebruikt zodat een beheerder snel op de hoogte kan gebracht worden

van een mogelijke fout), maar de fout in een verkeerde categorie onderverdelen komt niet

meer voor. In de eerste iteratie kan dit wel nog voorkomen, maar dit wordt gecorrigeerd

in de tweede iteratie. Ook het niet kunnen classificeren van een fout, omwille van tekort

aan informatie, wordt zo vermeden.

• Bij SPAM filtering wordt een Bayesiaans netwerk gebruikt om zuivere classificatie toe

te passen. Dit wil zeggen dat een e-mail ofwel SPAM ofwel geen SPAM is. Voor het

onderverdelen van fouten in categorieen is dit niet het geval. Zo kan het bijvoorbeeld zijn

dat er meerdere fouten samen voorkomen. In dit geval moeten al deze fouten gevonden

worden. Ook kan het zijn dat het netwerk moeite heeft om een fout te vinden en dat

er verschillende ongeveer even mogelijk zijn. In dit geval is het beter al deze fouten

als mogelijkheden te geven aan de beheerder, zodat deze enkel hoeft te controleren of

een van deze fouten voorkwam. Mocht slechts een mogelijke fout worden weergegeven

aan de beheerder, en deze was fout, dan moet de beheerder manueel gaan zoeken welke

fout dan wel optrad. In plaats van dus een fout aan te geven, moeten meerdere fouten

samen met hun probabiliteiten kunnen gerapporteerd worden. Het is dus noodzakelijk

om bepaalde drempelwaardes te specificeren per fout. Als een probabiliteit hoger is dan

deze drempelwaarde, dan is het mogelijk dat deze fout optrad en moet de beheerder

hiervan op de hoogte gebracht worden. Het bepalen van de drempelwaarden wordt

besproken in Sectie 4.4.1.

De opbouw en het gebruik van het Bayesiaans netwerk wordt mogelijk gemaakt door gebruik


te maken van de Weka-bibliotheek2. Dit is een bibliotheek die zeer veel machinelearning algo-

ritmes implementeert. Het bevat tools voor voorbewerking van data, classificatie, regressie,

clustering en vele andere. Het kan ook zeer eenvoudig uitgebreid worden om eigen en/of

nieuwe algoritmes in te voeren. Een van de bestaande tools is een naıef Bayesiaans netwerk.

Een voorbeeld van een dergelijk netwerk is afgebeeld in Figuur 4.5. De bovenste node bevat de

Figuur 4.5: Naıef Bayesiaans netwerk

verschillende mogelijke categorieen van fouten en de onderste nodes bevatten de verschillende

mogelijke observaties die de probabiliteiten van de verschillende foutcategorieen beınvloeden.

Als informatie van een nieuwe fout beschikbaar is, wordt deze gevoed aan de onderste nodes

en worden de probabiliteiten van de bovenste node afgelezen.

Voor het gebruik van het Bayesiaans netwerk voorziet de Weka bibliotheek mogelijkheden om

nieuwe observaties (zoals aangeboden door de analysecomponent) in te laden in het netwerk.

Voor de standaard classificatie voorziet het ook een methode om als uitkomst een fout te ver-

krijgen. Hier wordt echter niet met standaard classificatie gewerkt. Gelukkig is het in Weka

ook mogelijk om de probabiliteiten van alle fouten eenvoudig af te lezen. Deze probabili-

teiten, gecombineerd met de optimale drempelwaarden berekend zoals hierboven beschreven,

leiden tot een correcte rapportering van een of meerdere fouten, samen met de probabiliteit

dat ze ook effectief voorkomen, aan een beheerder. Als een probabiliteit hoger is dan de

overeenkomstige drempelwaarde, dan wordt deze gerapporteerd. Zo niet, wordt geen actie

ondernomen.

Laten we weer het voorbeeld van de bloeddruksensor en medicatieservice nemen. Het Bay-

esiaans netwerk kan er uit zien zoals in figuur 4.5. Laten we ervan uitgaan dat er slechts

twee soorten fouten mogelijk zijn, namelijk een componentfaling en een netwerkfaling. De

bovenste knoop (“ErrorType”) heeft nu slechts twee toestanden. Elke toestand heeft een

zekere kans om voor te komen (de som van de twee kansen is 1). De andere nodes bevatten

mogelijke observaties die kunnen voorkomen en die deze kansen beınvloeden. In het geval

2http://www.cs.waikato.ac.nz/ml/weka/


van de netwerkfout zien de observaties er als volgt uit: WebException, FileNotFoundEx-

ception, IOException, WebException, FileNotFoundException, IOException, WebException,

FileNotFoundException, IOException, StreamCorruptedException. Weka zal deze observa-

ties optimaliseren door met frequenties te werken. Als dit gebeurt is, ziet de fout er als volgt

uit: Iedere frequentie wordt op zijn beurt in het netwerk bij de correcte node ingeladen.

Tabel 4.1: Verwerkte observaties voor het Bayesiaans netwerk

Observatie Frequentie

WebException 3

FileNotFoundException 3

IOException 3

StreamCorruptedException 1

Telkens als het netwerk geupdatet wordt met de frequentie van een observatie, worden de

probabiliteiten van de verschillende fouttypes aangepast. Als alle observaties ingeladen zijn,

kunnen deze probabiliteiten afgelezen worden. Stel dat de kans op een netwerkfout 85% be-

draagt en de kans op een componentfaling 15%. Als bijvoorbeeld beide drempelwaarden 10%

zijn, dan worden beide fouten als mogelijkheid aanzien, maar de kans op een netwerkfout is

een stuk hoger dan een componentfaling. Als de drempelwaarden 20% zijn, dan wordt enkel

de netwerkfout, met zijn probabiliteit van 85%, als mogelijke fout aanzien. Stel dat er nu

tien mogelijke fouten zouden zijn, en elk heeft een probabiliteit rond de 10%, dan wordt het

heel moeilijk om een fout er uit te filteren. Aan de andere kant kan het dan ook zijn dat er

bijvoorbeeld geen enkele fout een kans heeft die boven de drempelwaarden uitkomt, waardoor

geen enkele fout mogelijk lijkt. De bepaling van optimale drempelwaarden is dus van cruciaal

belang om enerzijds niet teveel mogelijkheden over te houden, maar anderzijds ook niet te

weinig. De bepaling van de drempelwaarden wordt in de volgende sectie besproken.

4.4.1 Drempelwaardebepaling

Zoals eerder aangegeven dienen drempelwaarden gespecificeerd te worden voor elke mogelijke

fout. Deze drempelwaarden worden met behulp van de Youden index [15] bepaald. Om deze

index te kunnen bepalen, is er nood aan een testset. Daarvoor wordt de trainingsset gesplitst

in een deel om het netwerk op te bouwen en een deel om deze te testen en met deze resultaten

de optimale drempelwaarden te berekenen. Er wordt 90% van de trainingsset gebruikt om

het netwerk op te bouwen en 10% om te testen. Praktisch gezien wordt dus per fout random

10% van de instanties genomen om te dienen als testset. Omdat dit ervoor kan zorgen dat

het netwerk toevallig zeer slecht werkt, wordt dit tien maal gedaan. Het netwerk dat het best

scoorde op de tests, wordt uiteindelijk gebruikt in het systeem.


De efficientie van het Bayesiaans netwerk kan het best afgebeeld worden met behulp van een

ROC-curve. Ook het bepalen van de optimale drempelwaarde kan met een dergelijke curve

grafisch gedaan worden. Een ROC-curve (of receiver operating characteristic curve) is een

grafiek van de gevoeligheid (sensitiviteit of de verhouding van het aantal correct gevonden

positieven tegenover het totaal aantal positieven) in functie van de aspecificiteit (1 - specifici-

teit, met specificiteit de verhouding van het aantal correct gevonden negatieven tegenover het

totaal aantal negatieven) voor een classfier als zijn discriminatiedrempel gevarieerd wordt.

De ROC-curve kan ook weergegeven worden door de fractie van true positives (TPR = true

positive rate) uit te zetten tegen de fractie van fout-positieven (FPR = false positive rate).

De ROC-curve staat ook bekend als de Relative Operating Characteristic curve, omdat twee

operating characteristics (TPR & FPR) vergeleken worden terwijl het criterium (de drempel)

verandert [38]. Een voorbeeld van een ROC-curve wordt weergegeven in Figuur 4.6. Zoals

Figuur 4.6: Grafisch overzicht tot het bepalen van de Youden index [23]

afgebeeld in de figuur, gaat een ROC-curve altijd door de punten (0,0) en (1,1). In het punt

(0,0) worden geen positieven gevonden (geen waarden boven de drempelwaarde). In dit punt

worden alle positieve gevallen fout geclassificeerd, maar alle negatieve juist. In het punt (1,1),

wordt alles als positief ervaren (alles boven de drempelwaarde). In dit punt worden alle posi-

tieve gevallen correct geclassificeerd, maar alle negatieve zijn fout. De manier waarop de curve

van het punt (1,1), met een zeer lage drempelwaarde, naar het punt (0,0), met een zeer hoge


drempelwaarde gaat, wordt bepaald door de classifier . Een random classfier bijvoorbeeld,

zal een curve hebben die de diagonaal volgt. Een classifier die slechter doet dan een random

classifier , zal een curve onder de diagonaal hebben. Een classifier die beter werkt een curve

erboven. Een ideale classifier zal een curve hebben die start in het punt (1,1), via een rechte

naar het punt (0,1) gaat en ten slotte naar het punt (0,0). Dit wil zeggen dat deze classifier

alle echte positieven kan aanduiden, zonder valse positieven aan te duiden [26].

Een ROC-curve kan opgebouwd worden door een drempelwaarde te wijzigen. Tijdens de

uitvoering van de classifier zal slechts een drempelwaarde gebruikt worden. Met behulp van

de ROC-curve kan een optimale drempelwaarde gevonden worden. Er bestaan verschillende

manieren om dit te doen. Meer informatie over die verschillende methoden kan gevonden

worden in [23]. Hier wordt enkel ingegaan op een van de methoden, namelijk de Youden

index, omdat die gebruikt wordt in deze thesis tot het vinden van het optimale punt. Het

bepalen van de Youden index wordt grafisch aangegeven in Figuur 4.6. De Youden index

maximaliseert de verticale afstand vanaf de curve voor een random classifier (stippellijn) tot

aan opgestelde ROC-curve. Met andere woorden, het punt aangeduid door de Youden index,

is het punt dat het verst verwijderd is van de stippellijn. Het doel van de Youden index is

het maximaliseren van het verschil tussen de true positive rate (TPR) en de false positive rate

(FPR) en wordt dus gevonden door de formule

J = max[sn + sp]

met sn = sensitivity

en sp = specificity

(4.1)

De Youden index is het meest gebruikte criterium omdat dit de intentie tot het maximaliseren

van de correcte classificatie ratio reflecteert en omdat het gemakkelijk te berekenen is.

Om het netwerk te testen en drempelwaarden te voorzien, wordt de testset in het netwerk

geladen en worden bij verschillende arbitraire drempelwaarden de true positives, false posi-

tives, true negatives en false negatives berekend. Met behulp van deze waarden worden de

sensitivity en specificity per fout en per drempelwaarde berekend. Met deze waarden wordt

de Youden index per fout en per drempelwaarde berekent. De drempelwaarde per fout die

de hoogste waarde voor de Youden index opleverde (maximum een waarde van 2), wordt als

optimale drempelwaarde voor deze fout beschouwd. Het netwerk met de beste totaalscore

van de som van de Youden indices, wordt als beste netwerk gekozen en wordt in het systeem

gebruikt.

Bij voorgaande bespreking moet opgemerkt worden dat het mogelijk moet zijn om meer-

voudige fouten in het systeem te ontdekken. Ook fouten die bijna even waarschijnlijk zijn,


moeten gerapporteerd kunnen worden. Om deze redenen is het dus van belang dat de You-

den index niet te hoog is. Met dit in het achterhoofd werd een nabewerking ontwikkeld. Als

een drempelwaarde hoger dan 20% gekozen werd als optimale drempelwaarde, dan kan deze

verlaagd worden op voorwaarde dat de Youden index niet onder de 1,95 zakt. Met behulp

van deze nabewerking kunnen sommige hoge drempelwaarden, behoudens een zeker verlies in

prestatie, verlaagd worden om meer kans te bieden tot het ontdekken van meerdere fouten. De

reden waarom de index in sommige gevallen verlaagd dient te worden, is omdat de trainings-

set alleen enkelvoudige fouten bevat. Daarom is het moeilijk voor een nieuwe instantie om

als meervoudige fout aanzien te worden. Meervoudige fouten werden niet in de trainingsset

opgenomen omdat dan voor iedere combinatie van fouten trainingsinstanties voorzien zouden

moeten worden. Als er bijvoorbeeld tien enkelvoudige fouten zijn, dan zouden er trainingsin-

stanties voor de 10 enkelvoudige fouten moeten aanwezig zijn, maar ook voor de 45 dubbele

fouten, de 120 drievoudige fouten, . . . . Dit wordt heel snel teveel. Eventueel kan een betere

trainingsset in de toekomst ontworpen worden om ook meervoudige fouten in rekening te

kunnen brengen.

Hoofdstuk 5

Evaluatie

In dit hoofdstuk worden de technieken die besproken werden in de vorige hoofdstukken,

geevalueerd. Er wordt nagegaan of fouten ontdekt worden, of ze goed afgelijnd worden, of dit

efficient is enz. Alvorens dit uitgevoerd kan worden, moet eerst een emulator van een patient-

monitoring systeem (zoals besproken in Hoofdstuk 3) gebouwd worden. Deze emulator dient

als onderliggend systeem dat beheerd wordt met behulp van het beheerplatform. Die emulator

wordt in de eerste sectie besproken. De eigenlijke evaluatie komt in het tweede stuk aan bod.

5.1 Emulator

5.1.1 Architectuur en werking

De emulator van het patient-monitoring systeem werkt zoals weergegeven in Figuur 5.1. Dit

systeem bevat zes services. Er zijn drie services die een patient effectief opvolgen, namelijk

een temperatuurservice die de temperatuur van de patient meet, een hartslagservice die de

hartslag van een patient bijhoudt en een bloeddrukservice die de bloeddruk meet. In de

emulator zijn er twee mogelijkheden voorzien om de waarden die deze services in een echt

systeem moeten meten, te genereren.

• In de eerste plaats kunnen waarden random gegenereerd worden. Er zijn verschillende

parameters die aangepast kunnen worden om de werking van dit systeem bij te sturen:

– Een parameter die de normale monitorperiode aangeeft. Deze staat standaard

op 3600 seconden bij bloeddruk- en temperatuurservice en op 60 seconden bij de

hartslagservice. Dit wil zeggen dat er om het uur of om de minuut een waarde

wordt gegenereerd.

– Een parameter die de kans op 1000 aangeeft dat de gegenereerde waarde een nor-

male (gezonde) waarde is. Dit wil zeggen dat dit de kans is dat de bloeddruk tussen

57

Hoofdstuk 5. Evaluatie 58

Figuur 5.1: Overzicht van de werking van de emulator


90/60 en 150/100 is, de temperatuur tussen 35 en 40 ◦C zit en de hartslag tussen

de 50 en de 120 slagen per minuut is.

– Een parameter die de kans aangeeft dat een ongezonde waarde wordt gegenereerd

(ook hier op 1000). Bij de bloeddruk is dit een waarde tussen 0/0 en 60/40 of

tussen 150/100 en 210/140. Bij de temperatuur is dit een waarde tussen 30 en

35 ◦C of tussen 40 en 45 ◦C. Voor de hartslag is dit een waarde tussen 30 en 50 of

tussen 120 en 140.

– Bij de hartslagservice is er nog een extra parameter, namelijk de kans dat deze

een waarde tussen de 0 en 30 genereert (kans ook op 1000). Als een dergelijke

waarde gemeten wordt bij een patient, dan moet deze waarde onmiddellijk naar

een centrale service gestuurd worden, ongeacht de zendperiode.

– Vervolgens hebben alle services nog een parameter die de kans aangeeft dat ze een

nulwaarde genereren (kans ook op 1000). Dit duidt op een fout in de sensor.

– De volgende parameter geeft de kans op 1000 aan dat er een fout in het toestel

bevindt, waardoor een onmogelijke zeer hoge waarde wordt gegenereerd.

– De laatste parameter geeft de kans op 1000 aan dat de service geen waarde stuurt,

ook al is de zendperiode verstreken. Dit kan duiden op een faling in de service.

Als een service zich in deze mode bevindt, dan worden waarden dus random gegenereerd,

rekening houdt met bovenstaande parameters.

• Naast het genereren van waarden, kunnen deze ook gelezen worden uit een CSV-bestand

(een tekstueel bestand waarvan de waarden met komma’s gescheiden worden). Dit

bestand wordt dan regel per regel ingelezen. Elke regel bevat volgende informatie (zie

Listing 5.1):

1 zender , ontvanger , p a t i e n t i d , meetwaarde , wachtt i jd

Listing 5.1: Regel in CSV-bestand

De zender is de service die de informatie verstuurt. De ontvanger is degene die de

informatie krijgt. De patient id is de id van de patient waarvan de lichaamsfuncties

gecontroleerd worden zoals aangegeven in de databank. De meetwaarde is de waarde die

verstuurd wordt. De wachttijd geeft aan hoe lang gewacht wordt alvorens de volgende

informatie verstuurd wordt.

Naast bovenvermelde services, zijn er nog drie andere. In de eerste plaats is er de databank.

Deze houdt informatie bij over een patient. Hier wordt onder andere de leeftijd, het gewicht,

het feit of de persoon een sporter is en de medicatie die de patient gebruikt bijgehouden.

Een volgende service is de medicatieservice. Deze krijgt informatie over de bloeddruk en

gaat na of er een verandering van medicatie nodig is. Als de bloeddruk onder de gezonde


waarde zakt, worden medicijnen tot het verhogen van de bloeddruk aangeraden. In het geval

van een te hoge bloeddruk worden medicijnen tot het verlagen van de bloeddruk voorgesteld.

Ook het stopzetten van medicatie omwille van het feit dat de bloeddruk een gezonde waarde

bereikt, wordt hier nagegaan. De medicatie maakt gebruik van de leeftijd van de patient

(verkregen uit de databank) om dit te doen. De bloeddruk van 60-plussers kan namelijk

tussen de 150/100 en 160/103 zitten zonder dat dit ongezond is. Oudere mensen hebben

nu eenmaal een hogere bloeddruk. In dit geval hoeft geen medicijn toegediend worden. De

laatste service is de centrale service. Deze ontvangt de gemeten waarden van de hartslag-,

bloeddruk- en temperatuurservices alsook voorstellen voor medicatie van de medicatieservice.

Als het ongezonde waarden krijgt van een van de eerste drie, of een verandering in medicatie

van de medicatieservice, dan wordt dit gerapporteerd aan verplegend personeel. De centrale

service maakt ook gebruik van patientgegevens verkregen van de databank om deze informatie

te berekenen. Een sporter kan bijvoorbeeld een hartslag tussen 30 en 50 slagen per minuut

hebben zonder dat dit ongezond is. Bij een niet-sporter moet dit wel gerapporteerd worden.

Bij de bloeddruk is het hetzelfde verhaal als bij de medicatieservice, namelijk dat oudere

mensen vaak een hogere bloeddruk hebben.

De emulator moet uiteraard voorzien in mogelijkheden tot loggen. Het is net deze informatie

die gebruikt wordt door het beheerplatform om na te gaan of er zich fouten in het systeem

bevinden. Om deze reden moet iedere actie, probleem of dergelijke gelogd worden door de

emulator. De vorm van deze logs is als volgt:

1 t i j d module methode

2 l o g l e v e l : b e r i c h t

Listing 5.2: Vorm van de loginformatie

De tijd wordt weergegeven als DD-MMM-JJJJ hh:mm:ss. Andere formaten zijn mogelijk,

maar dan moet het formaat ook veranderd worden in het regelbestand. De module is de

service (of een onderdeel van de service) die de informatie logt. De methode is de methode

die in uitvoering was bij het maken van de logentry. De loglevel is een van volgende drie

waarden:

• INFO : deze lijn is normaal en dient enkel als informatie.

• WARNING : deze lijn dient als waarschuwing van iets wat mogelijk fout kan gaan.

• SEVERE : deze lijn bevat informatie over een fout die opgetreden is.

Het bericht kan om het even wat zijn. Deze kan een of meerdere lijnen bevatten.

Alle logberichten worden in een tijdelijk bestand ondergebracht. Eens het beheerplatform

de loginformatie gelezen heeft, wordt deze toegevoegd aan een permanent bestand en wordt


het tijdelijk bestand opnieuw geınitialiseerd. Op deze manier wordt niet twee maal dezelfde

informatie verstuurd.

5.1.2 Topologie en technologie

De topologie van de emulator is afgebeeld in Figuur 5.2. Alle services bevinden zich op

Figuur 5.2: Topologie van de emulator

aparte fysieke nodes die verbonden zijn met elkaar door een netwerk. Ook het beheerplatform

bevindt zich op een aparte fysieke node, en staat ook in verbinding met dit netwerk, zodat

het informatie van de verschillende services kan opvragen. Tussen elke service en het netwerk

bevindt zich een router. Deze horen eigenlijk niet thuis in de topologie. Deze routers zijn

speciale routers, opgenomen in de emulator, waarmee de trafiek kan beınvloed worden (traffic

shaping). Met behulp van deze routers kunnen netwerkfouten gesimuleerd worden. De routers

kunnen geconfigureerd worden om pakketten weg te gooien, om lange delays te voorzien en

om de bandbreedte van de connectie te beperken. De routers horen dus eigenlijk niet tot het

systeem, noch tot het netwerk, maar zijn desalniettemin aanwezig om een belangrijke reden

en daarom worden ze ook opgenomen in de topologie.


De emulator werd ontwikkeld in JAVA. De communicatie werd voorzien met behulp van

JAVA Web Services. Om de emulator van alle functionaliteiten te kunnen voorzien, werd

deze uitgevoerd op de Virtual Wall . Dit is een zeer grote testomgeving waarin gedistribu-

eerde software geemuleerd en geevalueerd kan worden. Het bevat honderd nodes die allen via

een 1.5Tb/s VLAN Ethernet switch zijn geconnecteerd met elkaar. Meer informatie over de

Virtual Wall is te vinden in [11].

5.1.3 Mogelijke fouten

In een patient-monitoring systeem kunnen verschillende fouten aan bod komen. Deze fouten

werden reeds besproken in Hoofdstuk 3. De emulator werd zo opgesteld dat de belangrijkste

fouten gesimuleerd kunnen worden. Toch kunnen niet alle fouten voorkomen. In de emulator

zitten bijvoorbeeld geen client pc’s en is er geen menselijke input, dus deze fouten kunnen niet

voorkomen. Databankfouten kunnen wel voorkomen, maar enkel de data die niet aanwezig

is. Aangezien er geen menselijke input is, is het verkeerd ingeven van data niet aan de orde.

Snelheidsproblemen kunnen ook voorkomen, maar enkel de late versturing van gemeten waar-

den (met andere woorden, sensoren die hun meetwaarden niet op de verwachte tijdstippen

stuurden). Ook serviceproblemen kunnen voorkomen. Een service kan bijvoorbeeld falen (dit

kan een sensor, rekenservice of databank zijn) of incorrecte waarden sturen (foute meetwaar-

den van sensoren). Netwerkproblemen kunnen ook optreden, zowel netwerkfalingen als trage

reactie van het netwerk. Hardwareproblemen en falingen van het platform waarop de services

uitvoeren zijn zeer moeilijk te simuleren en werden niet opgenomen.

5.2 Evaluatie

Met behulp van de emulator, besproken in vorige sectie, kan het beheerplatform geevalueerd

worden. De twee belangrijkste elementen voor de evaluatie zijn de regelgebaseerde analyse-

component, die fouten moet ontdekken en aflijnen, en de Bayesiaanse detectiecomponent, die

fouten in categorieen onderbrengt.

5.2.1 Regelgebaseerde analysecomponent

In de emulator kunnen volgende specifieke fouten voorkomen:

• Afwisselende waarden (F1): dit is een fout waarbij een service met een sensor waarden

stuurt die eventueel wel mogelijk (en ongezond) zijn, maar die in realiteit niet kunnen.

Denk bijvoorbeeld aan een temperatuur van een persoon die volgende waarden krijgt:

40, 35, 41, 36, 39. Een dergelijke fluctuatie van de temperatuur is in de praktijk niet

mogelijk. Er is dus een fout in de sensor geslopen.


• Nulwaarden (F2): dit is een fout waarbij een service met een sensor nulwaarden stuurt.

In dit geval is bijvoorbeeld de temperatuur van een (levend) persoon dus zogezegd nul.

• Hoge waarden (F3): dit is een fout waarbij er iets misloopt in een service waardoor zeer

hoge (en onmogelijke waarden) verstuurd worden. Een voorbeeld is een temperatuur

van een persoon van 1000 ◦C.

• Geen waarden (F4): dit is een fout waarbij een service plots geen waarden meer stuurt.

Stel bijvoorbeeld de temperatuurservice die al enkele uren geen temperatuur meer ver-

stuurde.

• Burst van waarden (F5): dit is een fout waarbij een service na een poos geen informatie

te versturen plots alle waarden samen verstuurt. Een voorbeeld is een temperatuurser-

vice die enkele uren geen waarde meer rapporteerde, maar plots alle informatie in een

keer stuurt.

• Ontvanger faling (F6): dit is een fout waarbij de service op de ontvanger niet meer

beschikbaar is om een of andere reden. Een voorbeeld is een crash van de centrale

service.

• Netwerk faling (F7): dit is een fout waarbij het netwerk op een bepaalde plaats faalt.

Een voorbeeld is een gebroken netwerkkabel.

• Netwerk traag (F8): dit is een fout waarbij het netwerk niet faalde, maar zeer traag

werkt. Dit kan bijvoorbeeld duiden op een te hoge load op het netwerk. Informatie

verzonden over het netwerk komt pas na een hele poos aan op zijn bestemming.

• Databank faling (F9): dit is een fout waarbij de databank faalt. Een voorbeeld is een

crash van het databank management systeem (DBMS).

• Data niet aanwezig (F10): dit is een fout waarbij de databank nog werkt, maar de data

niet gevonden wordt. Een voorbeeld is het niet vinden van een patient die opgevolgd

wordt.

Om deze fouten te vinden, zijn er verschillende regels ontworpen:

• R1: het al dan niet bevatten van een exception in de loginformatie: deze regel zal

opeenvolgende entries waarin een exception voorkwam samenbundelen tot een fout. Let

wel dat hier nog niet bekend is welke fout dit is. Het kan om het even welke fout gaan.

• R2: het al dan niet bevatten van een onmogelijke waarde. Hiertoe behoren afwisselende,

nul- en hoge waarden. Ook hier worden opeenvolgende foute entries samengenomen als

een fout.


• R3: het al dan niet bevatten van onregelmatigheden in de zendtijd. Hiermee kunnen pe-

riodieke zenders gecontroleerd worden of ze nog steeds periodiek zenden alsook triggered

zenders of ze nog steeds iets versturen als dit verwacht wordt.

• R4: het al dan niet terugvinden van data in de databank. Als opgemerkt wordt dat

data niet gevonden werd, worden opeenvolgende entries, waar informatie staat over het

niet vinden van data, samengenomen tot een enkele fout.

In onderstaande tabel wordt aangeduid welke fouten (of delen van fouten) met welke regels

gevonden worden. Zoals duidelijk wordt uit de tabel, worden alle fouten gevonden door

Tabel 5.1: Samenvatting van welke fouten met welke regels ontdekt worden

R1 R2 R3 R4

F1 x

F2 x

F3 x

F4 x

F5 x

F6 x

F7 x

F8 x

F9 x x

F10 x

minstens een regel. Alle fouten worden dus gevonden. Toch is dit niet voldoende. Een tweede

voorwaarde voor correcte werking van deze component is het aflijnen van fouten. Zoals uit

de tabel op te maken valt, zijn er twee regels die een databankfaling ontdekken. Deze lopen

onafhankelijk van elkaar en met enkel bovenstaande regels zou een dergelijke fout dus als twee

aparte fouten beschouwd worden. Ook in andere gevallen kan de aflijning nog niet correct

zijn. Bij een faling van bijvoorbeeld de medicatieservice treden er exceptions op in zowel de

medicatieservice zelf (waar iets misliep) als de bloeddrukservice (aangezien deze zijn waarden

niet kan afleveren). Beide zaken worden ontdekt door de eerste regel, maar worden niet als

enkele fout aanzien.

Naast vorige regels is er dus nog nood aan een regel die fouten samenneemt. In het regelbe-

stand is een dergelijke regel opgenomen. Deze regel controleert alle fouten. Bij iedere fout

wordt gekeken door welke module deze opgegooid werd. Daarna wordt gekeken met welke

modules deze component in verbinding staat. Dan worden deze andere modules bekeken. Als

deze een fout bevatten in hetzelfde interval, worden deze twee (of meer) fouten samengeno-

men tot een enkele fout. De vereenvoudigde uitwerking van deze regel wordt in pseudocode


afgebeeld in Listing 5.3. Als we het voorbeeld vanuit het vorig hoofdstuk hanteren, name-

1 f o r ( Component c : components ) {2 List<Component> r e l s = f i n d R e l a t i o n s ( c ) ;

3 f o r ( Error e : e r r o r s ) {4 MergedError me = mergeError ( e , r e l s ) ;

5 }6 }7

8 MergedError mergeError ( e r ror , r e l a t i o n s ) {9 MergedError merged = e r r o r ;

10 f o r ( Component r : r e l a t i o n s ) {11 Error e = f indOver lapp ingError ( e r ror , r ) ;

12 i f ( e != n u l l ) {13 List<Component> r e l s = f i n d R e l a t i o n s ( r ) ;

14 MergedError me = mergeError ( e , r e l s ) ;

15 Merged = mergeErrors (me , e r r o r ) ;

16 }17 }18 re turn merged ;

19 }

Listing 5.3: Regel en hulpmethode om fouten samen te nemen

lijk een bloeddruksensor die stuurt naar een medicatieservice en er is een netwerkfaling, dan

werkt deze regel als volgt. Eerst wordt de bloeddruksensor genomen. Hij heeft een enkele

relatie met de medicatie en er komt ook een fout voor. De hulpmethode mergeError wordt

dus een maal aangeroepen. In deze methode wordt de medicatieservice onderzocht en wordt

een overlappende fout gevonden. Nu worden de relaties van de medicatieservice gezocht en

roept de methode zichzelf op met de fout en de relaties van de medicatieservice. Aangezien

deze module geen relaties heeft, wordt de originele fout teruggegeven. De methode eindigt

met het samennemen van de fouten gevonden in beide modules. Vervolgens zal de regel de

medicatieservice component onder de loep nemen. Deze component heeft echter geen fouten

meer (de enige fout werd samengenomen met de fout van de sensor), waardoor de uitvoering

van de regel ten einde is. Van de twee afzonderlijk gevonden fouten is dus een samengenomen

fout gemaakt.

Ook deze regel werkt correct. Bij een databankfaling worden de twee fouten (de exceptions

bij de databank zelf en de melding dat de data niet gevonden werd bij de oproeper) samen-

genomen tot een enkele fout. Ook bij de faling van een ontvanger worden de foutinformaties

van zender en ontvanger samengenomen tot een fout.


Een laatste regel zorgt ervoor dat oninteressante informatie uit de fouten gefilterd worden, dat

continue waarden gediscretiseerd worden en dat informatie die nog nodig is voor de volgende

iteratie opgeslagen wordt (zoals besproken in Sectie 4.3). Ook dit werkt correct.

Met behulp van de besproken regels worden alle enkelvoudige fouten gevonden en correct

afgelijnd. Het is echter mogelijk dat er meerdere fouten onafhankelijk van elkaar op hetzelfde

ogenblik voorkomen. Ook meervoudige fouten worden door de eerste vier regels gevonden.

Door de samenvoegingsregel worden meervoudige fouten wel soms als enkele fout aanzien. Dit

komt voor als de fouten in hetzelfde tijdsinterval voorkomen en als ze voorkomen in modules

die communiceren met elkaar (of in een module en een netwerklink die ermee verbonden is).

Alle andere fouten worden als enkelvoudig aanzien.

Het regelgebaseerd systeem werkt dus zeer goed voor enkelvoudige fouten. Alle fouten worden

ontdekt en correct afgelijnd. Ook meervoudige fouten worden ontdekt en meestal correct

afgelijnd. Het enige minpunt aan de uitwerking is het incorrect samennemen van meervoudige

fouten. Of dit ook een echt probleem oplevert voor de Bayesiaanse detectiecomponent, wordt

later in dit hoofdstuk besproken.

5.2.2 Bayesiaanse detectiecomponent

Bij de evaluatie van deze component zijn er verschillende dingen van belang. Allereerst moet

gecontroleerd worden of de uitvoer snel genoeg kan gebeuren. Daarna moet geevalueerd

worden of enkelvoudige en meervoudige fouten goed ondergebracht worden in categorieen.

Daarnaast is ook het bepalen van de optimale drempelwaarden van belang. Ook de invloed

van de discretisatie en de granulariteit van de fouten moet nagegaan worden. Aangezien

het beheerplatform extra datatrafiek met zich meebrengt, is ook de invloed op de gebruikte

bandbreedte niet te onderschatten.

Opbouwtijd van het Bayesiaans netwerk

Bij de initialisatie van het beheerplatform dient het Bayesiaans netwerk opgebouwd te worden.

Dit wordt gedaan met behulp van trainingsinstanties. Hoe meer instanties gebruikt worden,

hoe beter het netwerk kan worden. Hier wordt nagegaan hoe de opbouwtijd beınvloed wordt

door het aantal instanties. Om rekening te houden met mogelijke fluctuaties in opbouwtijd,

werd deze test 100 maal herhaald. Het resultaat is te vinden in Figuur 5.3.

Het opbouwen van het netwerk gebeurt als volgt. 90% van de trainingsset wordt gebruikt

om het netwerk op te stellen. De overige 10% dient om te testen. Met deze testset, worden

de optimale drempelwaarden per fout berekend. Dit alles wordt 10 maal gedaan, zodat er 10

netwerken opgebouwd worden. Hierna wordt het beste netwerk gekozen (beste totale youden


score). Er zijn dus vijf elementen tijdens het bouwen van het netwerk: het maken van de

trainings- en testset, het bouwen van het netwerk, het testen van het netwerk, het bepalen

van de optimale drempelwaarden en het vinden van het beste netwerk. In Figuur 5.3 wordt de

Figuur 5.3: Tijd nodig voor het opbouwen van het Bayesiaans netwerk in functie van de grootte van

de trainingsset

opbouwtijd in functie van het aantal trainingsinstanties weergegeven. De bovenste curve is de

totale opbouwtijd, eronder worden de verschillende componenten van het opbouwen getoond.

Uit de grafiek kan opgemaakt worden dat de opbouwtijd lineair afhankelijk is van het aantal

instanties die gebruikt werden om het netwerk te bouwen. Een trainingsset van 1000 instanties

heeft een overeenkomstige opbouwtijd van ongeveer 32 seconden. Deze tijd wordt vooral

bepaald door het opstellen van de trainingsset en het testen van het netwerk. Dit komt nog

duidelijker naar voor in Figuur 5.4. In deze figuur zijn de elementen voor het opbouwen van

het netwerk weergegeven in een taartdiagram. Hier werden 1000 trainingsistanties gebruikt

om het netwerk op te bouwen. Het opbouwen van de trainings- en testset neemt duidelijk het

leeuwendeel van de tijd in beslag. Het testen van het netwerk neemt ook een groot deel voor

zijn rekening. De andere elementen zijn vrijwel onzichtbaar en nemen slechts een heel klein

deel van de tijd in beslag.

De initialisatie van het netwerk duurt dus ongeveer 30 seconden voor 1000 instanties en stijgt

lineair. Deze initialisatietijd is dus zeker niet te lang, zolang niet overdreven wordt met het

aantal trainingsinstanties. Er moet wel opgelet worden dat ook niet te weinig instanties ge-

nomen worden, dit zou de prestaties van het netwerk kunnen ondermijnen. De initialisatie


Figuur 5.4: Tijd nodig voor het opbouwen van het Bayesiaans netwerk voor 1000 trainingsinstanties

van het netwerk gebeurt eenmalig bij het opstarten van het beheerplatform. Het is onafhan-

kelijk van de toestand van andere componenten alsook het beheerde systeem en beınvloedt

de werking van deze componenten dus niet.

Gebruikstijd van het Bayesiaans netwerk

Eens het systeem getraind is, kan het gebruikt worden. Fouten worden ontdekt door het

regelgebaseerd systeem en aan het Bayesiaans netwerk gevoed voor classificatie.

Tijdens deze test wordt nagegaan wat de invloed van de grootte van het netwerk is op de

tijd nodig om een instantie te classificeren. Aangezien de tijd om een instantie te classificeren

te klein is om te meten, worden er telkens 10000 instanties samen geclassificeerd. Let wel

dat de tijd in de tabel de gemiddelde tijd per te classificeren instantie is. Uit de tabel

kunnen twee dingen opgemerkt worden. Enerzijds kan opgemerkt worden dat de tijd om

een instantie te classificeren enorm klein is. Enkele microseconden zijn voldoende om een

instantie te classificeren. Anderzijds kan ook gemerkt worden dat de grootte van het netwerk

geen significante invloed heeft op de tijd nodig voor het classificeren van de instantie. Dit komt

omdat nodes van het netwerk die observaties bevatten die niet voorkomen in de instantie, niet

in beschouwing genomen worden. Enkel het aantal verschillende nodes van het netwerk die

moeten in beschouwing genomen worden (en dus het aantal verschillende observaties in een

instantie), beınvloeden de classificatietijd. Dit is weergegeven in Figuur 5.5. Uit de figuur

valt op te maken dat de classficatietijd lineair afhankelijk is van het aantal verschillende

observaties in de te classificeren instantie.


Tabel 5.2: Invloed van de grootte van het netwerk op de classificatietijd van instanties

Nodes classificatietijd (ms)

50 0,0033

54 0,0029

67 0,0027

134 0,0064

1072 0,0034

1596 0,0172

1863 0,0049

2321 0,0108

2899 0,0059

Figuur 5.5: Tijd nodig voor het gebruiken van het Bayesiaans netwerk in functie van het aantal

verschillende observaties in een te classificeren instantie

Uit deze test volgt dus duidelijk dat de tijd nodig voor het classificeren niet afhankelijk

is van de grootte van het netwerk, maar van het aantal verschillende observaties in de te

classificeren instantie. Wel moet opgemerkt worden dat beide vaak hand in hand gaan. Denk

bijvoorbeeld aan de dicretisatie. Hoe fijner de discretisatie, hoe meer verschillende waarden.

Om deze reden wordt het aantal nodes in het netwerk groter, maar ook het aantal observaties

in de verschillende instanties wordt groter. Deze twee elementen mogen dus zeker niet los van


elkaar gezien worden, maar de grootte van het netwerk beınvloedt de gebruikstijd niet direct.

In een latere test, wordt de echte invloed van de discretisatie in meer detail geevalueerd.

Offline efficientie van het Bayesiaans netwerk

In deze test wordt de efficientie van het Bayesiaans netwerk nagegaan op basis van een trai-

ningsset. In eerste instantie wordt voor een fout de true positives, false positives, true ne-

gatives en false negatives nagegaan en dit voor een hele range aan drempelwaarden (meer

informatie over de werking van het Bayesiaans netwerk kan gevonden worden in Sectie 4.4),

meer informatie over het opstellen van de drempelwaarden is terug te vinden in Sectie 4.4.1.

Dezelfde test wordt gedaan voor meervoudige fouten. De resultaten zijn te vinden in Figuur

5.6 en Figuur 5.7.

In deze test werd een ROC-curve opgesteld over het correct classificeren van fouten in ca-

tegorieen. Er zijn verschillende curves weergegeven. Elke curve werd opgesteld met een

verschillend aantal samen voorkomende fouten. De drempelwaarden tot het vinden van deze

fouten werden gevarieerd om elke curve op te stellen. Het resultaat is te zien in Figuur 5.6.

Uit deze figuur kan afgeleid worden dat bij het voorkomen van een enkelvoudige fout in het

Figuur 5.6: ROC-curve voor meerdere onafhankelijke gelijktijdige fouten aanzien als een fout door

het regelgebaseerd systeem

systeem, de classifier (hier dus het naıef Bayesiaans netwerk) zich bijna als een ideale clas-

sifier gedraagt. In het optimale punt is de TPR ongeveer 95%, terwijl de FPR ongeveer


0% is. Dit wil zeggen dat tijdens het gebruik van het Bayesiaans netwerk, samen met de

optimale drempelwaarden voor de verschillende fouten, vrijwel alle fouten juist geclassificeerd

worden. Bij meervoudige fouten zakt de efficientie van het Bayesiaans netwerk echter zeer

snel. Bij twee samen voorkomende fouten bijvoorbeeld, wordt de TPR in het optimale punt

slechts 55%. De FPR is wel nog relatief goed, deze is nu 5%. Ook bij meer fouten is dit het

geval. Het lijkt er dus op dat enkelvoudige fouten zeer goed ontdekt kunnen worden, maar

meervoudige fouten leveren een groot probleem op.

In Figuur 5.7 worden de precision (het percentage van de gevonden fouten die correct ge-

classificeerd zijn) en recall (percentage van fouten die voorkomen die ook effectief gevonden

worden) in functie van het aantal samen voorkomende fouten weergegeven. Hierbij werd

gebruik gemaakt van de optimale drempelwaarden. Voor beide criteria zijn er twee curves

getekend, namelijk de curves voor een drempelwaarde van 25% en voor een drempelwaarde

van 85%. Ook hier kan duidelijk afgelezen worden dat het netwerk goed functioneert bij het

Figuur 5.7: Precision en recall in functie van het aantal gelijktijdige fouten voor drempelwaarden

van 25 en 85 %

vinden van enkelvoudige fouten (precision en recall beide rond de 95%), maar dat het een

stuk minder goed gaat bij meervoudige fouten. Bij twee samen voorkomende fouten bijvoor-

beeld, zakt de recall tot minder dan 45%. De precision blijft wel redelijk goed (80%). Bij nog

meerdere fouten zakt de recall nog verder. De precision blijft redelijk hoog.

Naast de goede werking bij enkelvoudige fouten en slechte werking bij meervoudige fouten,

kan uit deze figuur nog iets anders gevonden worden. De curves van de precision bij 25% en


85% drempelwaarden, liggen zeer dicht bij elkaar. Ook de recall curven liggen heel dicht bij

elkaar. Het lijkt er dus op dat de drempelwaarden slechts een heel kleine invloed hebben op

de efficientie van het netwerk.

In deze thesis worden de optimale drempelwaarden automatisch berekend met een afgeleide

van de Youden index (zoals besproken in Sectie 4.4). De optimale drempelwaarde wordt

berekend per mogelijke fout. Over het algemeen is deze waarde zeer laag (typisch minder dan

1%). Voor de fouten waar deze hoger is dan 20%, wordt ze verlaagd tot 20% met een zeer

kleine invloed op de waarde van de Youden index (een verschil typisch kleiner dan 1%).

In deze test kwam naar voor dat enkelvoudige fouten bijna perfect kunnen geclassificeerd

worden. Meervoudige fouten werken zeer slecht. Of dit ook een echt probleem betekent in het

online systeem, wordt later nagegaan. Als het mogelijk is om fout per fout uit het systeem

te verwijderen, kan deze slechte efficientie bij het optreden van meervoudige fouten genegeerd

worden. Indien niet, moet gezocht worden naar technieken om meervoudige fouten toch beter

te classificeren, of om meervoudige fouten te splitsen voor ze aan het netwerk gevoed worden.

Naast vorige conclusies, kan ook geconcludeerd worden dat de invloed van de drempelwaarden

slechts heel miniem is. Dit kan verklaard worden door te controleren welke probabiliteiten

aan de verschillende mogelijke fouten toegekend worden. Als een fout zich voordoet, is het

netwerk altijd redelijk zeker van zijn stuk (probabiliteit voor een fout hoger dan 90%). Of nu

een drempelwaarde van 20% of 70% gekozen wordt, in beide gevallen wordt de fout gekozen.

Toch wordt best een kleinere drempelwaarde gekozen, daar deze toch net iets beter werkt dan

een hogere waarde.

Invloed van de discretisatie

Om het Bayesiaans netwerk niet oneindig groot te laten worden, dienen continue waarden

gediscretiseerd te worden. In deze test wordt allereerst de invloed van de discretisatie op

efficientie getoetst. Vervolgens wordt ook de invloed op de grootte van het netwerk nagegaan.

Als laatste wordt de invloed op het aantal verschillende observaties in de te classificeren

instanties geevalueerd. Daarbij wordt ook gekeken welke invloed dit heeft op de snelheid bij

gebruik van het netwerk.

De eerste subtaak van deze test bestaat erin om het netwerk te testen bij verschillende granu-

lariteiten voor de intervallen waarin de continue waarden ondergebracht worden. Verscheidene

intervalgroottes werden geevalueerd, met als extremen langs de ene zijde geen discretisatie

en aan de andere zijde intervallen met grootte 100. In de curves die hieronder weergegeven

worden, zijn deze twee extremen weergegeven. Figuur 5.8 bevat de ROC-curve voor het net-

werk bij deze extremen. Zoals uit de figuur kan afgeleid worden, benaderen beide curven de

ideale classifier . Ook wordt duidelijk dat de discretisatie, net zoals de bepaling van optimale


Figuur 5.8: ROC-curve bij geen discretisatie en een intervalgrootte van 100

drempelwaarden, een heel kleine invloed heeft op de efficientie van het netwerk. Helaas is het

onmogelijk op te maken uit de figuur welke van de twee nu eigenlijk beter scoort. Om deze

reden zijn figuren 5.9 en 5.10 hierna weergegeven.

In Figuur 5.9 is de precision van beide extremen weergegeven. Hier lijkt het erop dat de

discretisatie een positief effect heeft op de precision. Voor vrijwel iedere drempelwaarde is

de precision hier hoger dan bij een niet-gediscretiseerde aanpak. Als we daarentegen Figuur

5.10 onder de loep nemen, lijkt de recall van de niet gediscretiseerde aanpak beter. Bij hoge

drempelwaarden is de aanpak met discretisatie beter, maar zoals eerder opgemerkt, werken

we met drempelwaarden typisch kleiner dan 20%.

Zoals hierboven gezien, wordt de efficientie van het Bayesiaans netwerk slechts in beperkte

mate beınvloed door de discretisatie. De keuze van de discretisatie hoeft dus niet alleen van

de efficientie af te hangen. In de volgende deeltaak van de test bekijken we de invloed van

de discretisatie op de grootte van het netwerk. De resultaten van deze test zijn afgebeeld

in Figuur 5.11. Uit deze figuur kan afgeleid worden dat de discretisatie de grootte van het

netwerk sterk beınvloedt. Als geen discretisatie gebruikt wordt, bevat het netwerk meer dan

1800 nodes. Bij intervallen van 20 is dit gezakt tot ongeveer 300, nog een zesde van het

oorspronkelijk netwerk. Bij grotere intervallen wordt de invloed van de discretisatie minder

sterk. Bij intervallen van 100 bevat het netwerk nog slechts een 100-tal knopen. Met grovere


Figuur 5.9: Precision bij geen discretisatie en een intervalgrootte van 100 voor verschillende drem-

pelwaarden

discretisatie kan het Bayesiaans netwerk dus sterk vereenvoudigd worden.

Een laatste deeltaak van deze test is het evalueren van de invloed op het aantal verschillende

observaties per te classificeren instantie en de ermee gepaard gaande classificatietijd. De

resultaten voor de invloed op het aantal verschillende observaties per te classificeren instantie

zijn te vinden in Figuur 5.12. Zoals verwacht wordt bij een grovere discretisatie, het aantal

verschillende observaties kleiner. Ook hier lijkt het erop dat de grootste vereenvoudiging

gebeurt tussen het niet gebruiken van discretisatie en het discretiseren met intervallen van

20. Toch is de invloed niet zo heel groot. Een fout bevat typisch niet zo veel verschillende

observaties. Dit is waar onder de assumptie dat de fouten niet te lang duren, wat uiteraard

de opzet van deze thesis is. De fouten gebruikt voor deze test duurden typisch vijf tot tien

minuten.

Aangezien de discretisatie een kleine invloed heeft op het aantal verschillende observaties in

de te classificeren instanties, verwachten we ook een kleine invloed op de tijd nodig om ze

te classificeren. In onderstaande tabel zijn de resultaten van de tijdsmetingen weergegeven.

Zoals eerder opgemerkt, wordt de classificatie zeer snel gedaan. In enkele microseconden kan

een instantie geclassificeerd worden. Ook in onderstaande tabel zien we dit duidelijk. De


Figuur 5.10: Recall bij geen discretisatie en een intervalgrootte van 100 voor verschillende drempel-

waarden

Figuur 5.11: Invloed van de discretisatie op de grootte van het netwerk

invloed van de discretisatie op de classificatietijd is een heel stuk minder duidelijk. De enige

conclusie die getrokken kan worden uit de resultaten, is dat de discretisatie een slechts heel


Figuur 5.12: Invloed van de discretisatie op het aantal verschillende observaties in een te classificeren

instantie

kleine invloed heeft op de classificatietijd.

Tabel 5.3: Invloed van de discretisatie op de classificatietijd van instanties

Intervalgrootte Gebruikstijd (ms) standaardfout (ms)

0 0,0035 0,00059

0,1 0,0024 0,00049

0,2 0,0026 0,00051

0,5 0,0035 0,00059

1 0,0034 0,00058

2 0,0045 0,00067

5 0,0040 0,00063

10 0,0034 0,00058

20 0,0033 0,00057

50 0,0035 0,00059

100 0,0033 0,00057

Beslissen welke discretisatie het best is, lijkt een moeilijke taak. Een grovere classificatie heeft

een slechts beperkte invloed op de efficientie van het Bayesiaans netwerk. Zelfs als rekening

gehouden wordt met de efficientie van het netwerk, kan nog een hele range van intervalgroottes

gekozen worden. Het enige waarop gelet moet worden, is dat de intervallen niet zodanig

groot mogen worden dat alle waarden in hetzelfde interval geplaatst worden. Ook voor de


classificatietijd van een instantie is de discretisatie van weinig tot geen belang. Classificatie

gebeurt enorm snel, voor gelijk welke intervalgrootte. Als de grootte van het netwerk in

beschouwing wordt genomen, is het wel duidelijk dat een grovere discretisatie beter kan zijn.

In dat geval wordt het netwerk een stuk eenvoudiger. De grote vraag is natuurlijk: moet dit

in beschouwing genomen worden? Het is zo dat de grootte van het netwerk geen (of slechts

in beperkte mate) invloed heeft op de efficientie, en dat er ook geen (directe) invloed is op de

classificatietijd. Er is echter nog een ander luik waar rekening mee gehouden moet worden,

namelijk fysische opslag. Als het netwerk blijft groeien (als geen discretisatie wordt toegepast

is dit onvermijdbaar, doordat steeds nieuwe continue waarden verzonden worden), kan een

tekort aan geheugen het platform doen falen. Hoe snel dit gebeurt, hangt natuurlijk af van

de hardware waarop het beheerplatform draait. Toch is het best om een zekere discretisatie

door te voeren om de mogelijkheid van een oneindig groeiend netwerk in de kiem te smoren.

In deze thesis werd rekening gehouden met vorige twee belangrijke voorwaarden. Enerzijds

is er het niet te groot nemen van de intervallen om de efficientie niet teveel te beınvloeden

en anderzijds het grover discretiseren om het netwerk te vereenvoudigen. In deze thesis werd

gekozen voor intervalgroottes van 20. Dit werd zo gekozen omdat het netwerk al zeer sterk

vereenvoudigd werd en omdat deze intervalgrootte een heel goede benadering is voor het niet

toepassen van discretisatie in termen van efficientie.

Granulatie van fouten

In vorige tests werd gezocht naar technieken om het netwerk zo efficient mogelijk te laten

classificeren. Hierbij werd het netwerk zelf onder de loep genomen. Daarnaast is het ook

mogelijk om de fouten waarin nieuwe instanties onderverdeeld moeten worden, fijner of grover

te maken.

Zoals aangegeven in Sectie 5.2.1, zijn er tien mogelijke fouten in de emulator. Deze fouten zijn

afwisselende waarden (F1), nulwaarden (F2), hoge waarden (F3), geen waarden (F4), burst

van waarden (F5), ontvanger faling (F6), netwerk faling (F7), netwerk traag (F8), databank

faling (F9) en data niet aanwezig (F10). In onderstaande tabel zijn de fouten bij verschillende

granulatiteiten weergegeven (een komma scheidt verschillende fouten, een ampersand geeft

samengenomen fouten aan): Als we de tabel van onder naar boven bekijken (van fijnere tot

grovere fouten), zien we dat volgende fouten werden samengenomen:

• Voor acht fouten werden afwisselende, nul- en hoge waarden samengenomen tot een

algemene sensorwaardefout.

• Om zeven fouten te verkrijgen, werden databank faling en data niet gevonden fouten

samengenomen tot een algemene databankfout.


Tabel 5.4: Fouten bij verschillende granulariteiten

Aantal fouten Fouten

3 F1 - F2 - F3 - F4 - F5 - F6, F7 - F8, F9 - F10

4 F1 - F2 - F3 - F4 - F5, F6, F7 - F8, F9 - F10

5 F1 - F2 - F3, F4 - F5, F6, F7 - F8, F9 - F10

6 F1 - F2 - F3, F4, F5, F6, F7 - F8, F9 - F10

7 F1 - F2 - F3, F4, F5, F6, F7, F8, F9 - F10

8 F1 - F2 - F3, F4, F5, F6, F7, F8, F9, F10

10 F1, F2, F3, F4, F5, F6, F7, F8, F9, F10

• Nog grovere fouten (zes fouten) werden verkregen door een netwerk faling en netwerk

traag samen te nemen tot een algemene netwerkfout.

• Om vijf fouten te bekomen, werden geen en burst van waarden samengenomen tot een

fout waarbij de zender onregelmatig data verstuurd.

• Vier fouten werden bekomen door afwisselende, nul-, hoge, geen en burst van waarden

samen te nemen, die samen een algemene zenderfout vormen.

• Om drie fouten te verkrijgen, werd aan voorgaand gedefinieerde fout, ook nog de ont-

vanger faling toegevoegd. Al deze fouten samen vormen een algemene fout in een

component. De enige fouten die nu nog bestaan zijn component-, databanken net-

werkfouten.

De invloed van bovenvermelde granulatie van fouten op de precision en recall is weergegeven

in Figuur 5.13. Uit de figuur kan geconcludeerd worden dat zowel de precision als de recall

slechter worden bij fijnere fouten. Toch blijft de precision bij de fijnste fouten ongeveer 90%

terwijl de recall zelfs 95% haalt. Ook wordt duidelijk uit de figuur dat de fijnheid van de fouten

niet de enige parameter is die bepalend is hoe goed het Bayesiaans netwerk fouten classificeert.

Het splitsen van componentfalingen in zender- en ontvangerfouten, bijvoorbeeld beınvloedt de

precision en recall niet. Zenderfouten splitsen in sensorwaarde fouten en onregelmatigheden

bij het versturen van data, hebben ook geen invloed. Het splitsen van onregelmatig zenden

in niet zenden en zenden in bursts heeft geen invloed op de recall , maar wel op de precision.

Deze zakt van 100 naar ongeveer 97%. Het splitsen van een netwerkfout in een netwerk faling

en een traag netwerk, beınvloedt beide parameters. De precision zakt van 97 tot 93%, terwijl

de recall van 100 naar 99% zakt. Het splitsen van een databankfout in een databank faling

en een fout waarbij de data zich niet in de databank bevindt, heeft een relatief sterke impact

op precision en recall . De precision zakt nu van 93 tot 89% en de recall van 99 tot 96%. Het

splitsen van een fout in sensorwaarde in zijn drie componenten, zorgt er dan weer voor dat


Figuur 5.13: Invloed van de granulariteit van fouten op de precision en recall

het Bayesiaans netwerk efficienter werkt. De recall wijzigt amper, maar de precision stijgt

van 89 tot 90%.

In het algemeen kan geconcludeerd worden dat het Bayesiaans netwerk beter werkt als de

fouten grover zijn. Toch is de invloed minimaal. Er moet opgemerkt worden, dat dit niet

altijd geldig is. De efficientie hangt minder sterk af van hoeveel fouten samengenomen worden,

maar meer van welke fouten nu net gecombineerd worden. Samennemen van fouten die niet zo

sterk op elkaar lijken (zoals afwisselende, nul- en hoge waarden), kan een verslechtering van de

efficientie teweegbrengen. Men moet dus goed opletten als men fouten wil grover maken om de

efficientie te verbeteren. Naast de efficientie is er nog een ander criterium waarmee rekening

gehouden moet worden. Hoe grover de fouten, hoe minder informatie de beheerder krijgt

als de fouten geclassificeerd en gerapporteerd worden. Er moet dus een afweging gemaakt

worden tussen enerzijds het grover nemen van fouten om de efficientie ten goede te komen en

het fijner definieren van fouten om meer informatie uit de fout te kunnen halen.

In deze thesis werd ervoor gekozen om de fouten zo fijn mogelijk te laten en op die manier zo

veel mogelijk informatie aan de beheerder te kunnen geven. Het criterium van de hoeveelheid

informatie voor de beheerder werd als belangrijkste criterium gekozen. Aangezien zowel

precision als recall zeer hoog blijven, is deze keuze verantwoord.


Online efficientie van het Bayesiaans netwerk

In een vorige test evalueerden we het Bayesiaans netwerk met behulp van een vooraf opge-

stelde trainingsset. Daar werd geconcludeerd dat enkelvoudige fouten bijna perfect gevonden

werden. Meervoudige fouten leverden een groot probleem op. De efficientie bij een toenemend

aantal fouten zakte zeer snel. In deze test wordt enerzijds nagegaan hoe efficient het Baye-

siaans netwerk is in het online systeem voor enkelvoudige fouten. Er wordt dus nagegaan of

online gevonden fouten (fouten geıntroduceerd en gevonden tijdens actieve werking van het

beheerde systeem en het beheerplatform) ook zo goed werken als gevonden in de offline test.

Anderzijds worden meervoudige fouten onder de loep genomen en wordt gekeken of deze toch

op een of andere manier aangepakt kunnen worden.

De resultaten voor de evaluatie van enkelvoudige fouten, wordt weergegeven in onderstaande

tabel. In de eerste kolom is aangegeven welke fout onderzocht wordt. De tweede kolom bevat

informatie over het vinden van deze fout. Een waarde van 100% geeft aan dat de fout altijd

gevonden wordt. Een waarde van 0% geeft aan dat ze nooit ontdekt wordt. In de derde

kolom is informatie weergegeven over de probabiliteit die aan de fout toegekend wordt als

deze gerapporteerd wordt. Het is mogelijk dat meerdere mogelijke fouten gevonden werden.

Onder normale omstandigheden moet de probabiliteit van de fout die effectief voorkwam, het

grootst zijn. Als dit altijd zo is, krijgen we een waarde van 100% in de derde kolom. Als de

fout nooit als meest mogelijke fout voorkomt, is de waarde 0%. De meeste fouten lijken te

Tabel 5.5: Efficientie van het Bayesiaans netwerk voor enkelvoudige fouten

Fout Gevonden Hoogste probabiliteit

Afwisselende waarden 100% 100%

Nulwaarden 100% 100%

Hoge waarden 100% 0%

Geen waarden 100% 100%

Burst van waarden 100% 100%

Ontvanger faling 100% 100%

Netwerk faling 100% 100%

Netwerk traag 100% 45%

Databank faling 100% 100%

Data niet aanwezig 100% 100%

werken zoals in de offline tests. Er zijn echter twee fouten die de aandacht vereisen:

• De fout ‘hoge waarden’ wordt altijd gevonden (net zoals alle andere fouten), maar

wordt nooit als meest mogelijke aanzien. Gemiddeld wordt een probabiliteit van 35%


toegekend aan deze waarde, wat er dus voor zorgt dat ze gevonden wordt. De fout

‘afwisselende waarden’ wordt ook altijd als mogelijkheid aanzien, met een gemiddelde

probabiliteit van 64%. Een hoge waarden fout wordt dus altijd als een afwisselende

waarde fout aanzien. In de praktijk is dit echter geen probleem. Beiden zijn fouten met

een sensor. In de praktijk wordt deze fout opgelost door de sensor te vervangen. Beide

fouten worden op dezelfde manier opgelost, waardoor ze uit het systeem verdwijnen.

• Net zoals hierboven wordt ook de fout ‘netwerk traag’ altijd gevonden, maar niet altijd

als eerste keuze genomen. In 55% van de gevallen is de eerste keuze een netwerk faling

(met een probabiliteit tot 75%). Een fout van het type ‘netwerk traag’, wordt dus vaak

verward met een netwerk faling. Een manier om deze twee fouten beter te scheiden, is

de introductie van monitoring probes, die speciaal ontwikkeld worden om het netwerk in

de gaten te houden. Met de extra informatie van deze probes kan de efficientie verhoogd

worden.

Naast bovenvermelde opmerkingen moet ook nog opgemerkt worden dat in vele gevallen de

fout niet als enige mogelijkheid gerapporteerd wordt. Bij een afwisselende waardefout, data

niet aanwezig fout of databank faling, worden deze fouten als enige gevonden. In alle andere

gevallen worden meer niet voorkomende fouten als mogelijkheden gevonden. Dit is echter

geen probleem (behalve in de gevallen hierboven besproken), daar de probabiliteiten van deze

fouten typisch kleiner zijn dan 5%.

Het evalueren van meervoudige fouten is iets ingewikkelder. Niet alle combinaties van fouten

kunnen voorkomen in het systeem. Ook het effectief introduceren van meervoudige fouten is

geen eenvoudige taak. Om deze reden evalueren we enkel twee samen voorkomende fouten

en dit voor alle combinaties van fouten die in het systeem geıntroduceerd kunnen worden.

Meer samen voorkomende fouten worden niet geevalueerd. De keuze kan verantwoord worden

door de implementatie van kritische toepassingen. Dergelijke toepassingen worden ontworpen

om zo weinig mogelijk fouten te introduceren. Het voorkomen van fouten moet dus zo laag

mogelijk zijn. De kans op een enkelvoudige fout is nog relatief hoog. Meervoudige fouten

komen al een heel stuk minder voor. Daarbij komt nog eens kijken dat fouten die in modules

voorkomen die niet (direct) met elkaar communiceren, als enkelvoudige fouten aanzien worden

door het regelgebaseerd systeem. Als fouten wel voorkomen in communicerende componenten,

dan moeten de fouten nog op hetzelfde ogenblik voorkomen om als meervoudige fout aanzien

te worden. Om deze redenen kan dus aangenomen worden dat meervoudige fouten eerder

uitzondering dan regel zijn. Meervoudige fouten met meer dan twee samen voorkomende

fouten zullen zelden tot nooit voorkomen.

De resultaten van de test zijn te zien in onderstaande tabel. De eerste twee kolommen be-

schrijven de fouten die voorkomen. De derde kolom geeft aan hoe dikwijls er een van de

twee gevonden wordt. De vierde kolom geeft aan hoe dikwijls beide fouten ontdekt worden.


De voorlaatste kolom geeft aan hoe groot de kans is dat een van de fouten als beste keuze

aangeduid wordt. De laatste kolom bevat identieke informatie, maar nu is het de kans dat

beide fouten als nummers een en twee aanzien worden. In bijna alle gevallen wordt minstens

Tabel 5.6: Efficientie van het Bayesiaans netwerk voor meervoudige fouten

Fout 1 Fout 2 1 gevonden 2 gevonden 1 hoogste kans 2 hoogste kans

burst afwisselend 100% 0% 100% 0%

burst hoog 0% 0% 0% 0%

burst nul 100% 0% 100% 0%

databankfaling netwerkfaling 100% 0% 100% 0%

databankfaling netwerk traag 100% 0% 0% 0%

data afwezig afwisselend 100% 0% 100% 0%

data afwezig hoog 100% 0% 100% 0%

data afwezig netwerkfaling 100% 0% 100% 0%

data afwezig netwerk traag 100% 100% 100% 0%

data afwezig nul 100% 0% 100% 0%

netwerkfaling afwisselend 100% 0% 100% 0%

netwerkfaling burst 100% 0% 100% 0%

netwerkfaling hoog 100% 0% 100% 0%

netwerkfaling nul 100% 0% 100% 0%

netwerk traag afwisselend 100% 0% 0% 0%

netwerk traag burst 100% 0% 0% 0%

netwerk traag hoog 100% 0% 0% 0%

netwerk traag ontvanger faling 100% 25% 25% 0%

netwerk traag nul 100% 43% 71% 0%

ontvanger faling afwisselend 100% 0% 100% 0%

ontvanger faling hoog 100% 0% 100% 0%

ontvanger faling nul 100% 0% 100% 0%

totaal 95% 8% 73% 0%

een van de fouten gevonden. Enkel bij de combinatie van hoge en burst van waarden wordt

geen enkele van deze fouten gevonden. De combinatie van deze fouten wordt door het Bay-

esiaans netwerk altijd ervaren als een afwisselende waardefout. Zoals eerder aangehaald is

het oplossen van een afwisselende waardefout in de praktijk identiek aan het oplossen van

een hoge waardefout, dus is dit niet echt een probleem. Het vinden van de tweede fout laat

echter te wensen over. In het algemene geval wordt slechts een van de twee fouten ontdekt.

Enkel bij de combinatie ‘data niet aanwezig’ en ‘netwerk traag’ worden altijd beide fouten

gevonden. Bij de combinaties ‘netwerk traag’ samen met ‘ontvanger faling’ en ‘netwerk traag’

en nulwaarden, worden beide fouten soms ontdekt. In alle andere gevallen niet. In de meeste

gevallen wordt een van de fouten aangeduid als meest mogelijke. Dit is het geval in 73%


van de gevallen. Bij sommige combinaties van fouten wordt soms tot nooit een van de twee

fouten als beste keuze aangeduid. Dit treedt op bij iedere combinatie van een ‘netwerk traag’

fout. In al deze gevallen wordt een ‘netwerk faling’ de fout met de grootste kans (typisch

een probabiliteit rond de 70%). Bij alle combinaties van fouten zonder ‘netwerk traag’ fout

(behalve dan die ene anomalie van hoge en burst van waarden), wordt een van de twee fouten

als beste keuze aangeduid. De tweede fout wordt nooit als tweede beste keuze aangeduid. Bij

fouten waar de tweede fout niet gevonden wordt is dit uiteraard normaal. Maar ook bij de

andere fouten wordt de tweede fout nooit als tweede beste optie genomen.

Ook in het online systeem kunnen enkelvoudige fouten zeer goed ontdekt en geclassificeerd

worden. Het Bayesiaans netwerk lijkt hier te doen wat het moet om het beheerplatform een

succes te noemen. Meervoudige fouten zijn echter nog steeds een probleem. Om de efficientie

te verhogen, zouden extra functionaliteiten voorzien kunnen worden om meer informatie over

het netwerk op te halen. Zowel bij enkelvoudige fouten als bij meervoudige fouten zou de

verwarring tussen een traag werkend netwerk en een netwerkfaling vermeden kunnen worden.

Als dit zou lukken, dan zou de ontdekking van een fout en aanduiden van de fout als beste

keuze voor zowel enkelvoudige als meervoudige (in iedere geval 2 samen voorkomende) fouten

geoptimaliseerd kunnen worden om bijna perfect te werken. Een andere mogelijkheid be-

staat erin om de twee netwerkfouten samen te nemen, maar dan gaat er uiteraard informatie

verloren.

Vormen meervoudige fouten nu effectief een probleem? Eigenlijk niet. Stel dat er zich twee

gelijktijdige fouten voordoen. De beheerder wordt op de hoogte gebracht en kijkt welke

fouten er mogelijk voorkwamen. Hij neemt deze met de hoogste probabiliteit en kijkt of

deze inderdaad voorkwam. Als dit niet het geval was loopt hij de lijst af en controleert elke

voorgestelde fout (typisch 2 a 3). In 73% van de gevallen zal hij echter onmiddellijk de juiste

fout vinden. Eens deze fout opgelost is, bevindt er zich nog een fout in het systeem. In een

volgende monitorperiode wordt deze fout gerapporteerd (nu nog een enkelvoudige fout, en dit

werkt bijna perfect). Nu kan de beheerder ook de tweede fout uit het systeem verwijderen. Als

de optimalisaties voor de netwerkfouten (zoals hierboven beschreven) doorgevoerd worden,

dan kan de foutoplossing nog sneller gaan. In dit geval zal de fout met de hoogste probabiliteit

bijna altijd de effectief voorkomende fout zijn, waardoor niet meer gezocht moet worden naar

de fout die effectief voorkwam. Voor meervoudige fouten is het dus mogelijk om fout per fout

uit het systeem te verwijderen met behulp van het beheerplatform.

5.2.3 Invloed van het beheerplatform op de gebruikte bandbreedte

In deze test wordt nagegaan wat de invloed van het beheerplatform op de gebruikte band-

breedte van het netwerk is. Een systeem waarop het beheerplatform gebouwd wordt, wordt

met een node uitgebreid. Alle componenten sturen periodiek een heartbeat naar deze node om


aan te geven dat ze nog actief zijn. Ook worden periodiek loggegevens van alle systeemnodes

gelezen. Welke invloed dit heeft op het netwerk is weergegeven in figuren 5.14 en 5.15.

In Figuur 5.14 is het absoluut bandbreedtegebruik weergegeven voor verschillende groottes

van het beheerde systeem. De bovenste curve geeft de totale bandbreedte weer, dus het

Figuur 5.14: Bandbreedte nodig voor de emulator zonder het beheerplatform, van het beheerplat-

form apart en in totaal

bandbreedtegebruik van het systeem samen met het beheerplatform. Dit wordt uitgezet in

functie van het aantal knopen in het systeem (exclusief het beheerplatform). De curve net

eronder geeft het bandbreedtegebruik van het beheerde systeem aan, terwijl de onderste curve

de bandbreedte van het beheerplatform aangeeft, beide in functie van het aantal knopen in

het systeem. Beide componenten stijgen bij een toenemende grootte van het systeem, maar

het netwerkgebruik van het beheerplatform stijgt een stuk minder snel. Dit toont aan dat

de relatieve invloed van het beheerplatform daalt naarmate het beheerde systeem groter

wordt. In Figuur 5.15 wordt de relatieve invloed van het beheerplatform op het netwerk

aangegeven. In de figuur wordt de fractie van de totale bandbreedte, gebruikt door het

beheerplatform, uitgezet in functie van het aantal knopen in het beheerde systeem (exclusief

het beheerplatform). Uit de figuur valt duidelijk op te maken dat de relatieve invloed van het

beheerplatform afneemt met stijgend aantal knopen in het beheerde systeem. Bij een systeem

met drie nodes is de relatieve invloed 50%, wat duidt op een verdubbeling van de bandbreedte

door introductie van het beheerplatform. Bij een systeem met twaalf nodes, is de relatieve

invloed nog ongeveer 20%, wat duidt op een vermeerdering tegenover het oorspronkelijke

systeem van ongeveer 25%. Verder lijkt het er op dat bij nog grotere systemen, de relatieve


Figuur 5.15: Fractie van de bandbreedte gebruikt voor het beheerplatform

invloed niet zo sterk meer afneemt. De invloed van het beheerplatform op een zeer groot

systeem zal dus normaal gezien tussen de 10 en 20% liggen.

Zo te zien ligt de invloed van het beheerplatform op het onderliggend systeem binnen aan-

vaardbare grenzen. De relatieve invloed van het beheerplatform ligt tussen de 10 en 20%.

Vooraleer het beheerplatform op het systeem wordt gebouwd, moet natuurlijk nagegaan wor-

den of het netwerk de extra last kan dragen. Daarnaast moet opgemerkt worden dat de

relatieve invloed vooral afhankelijk is van de hoeveelheid loginformatie. Hoe meer informatie

bekend is, hoe beter het platform zijn werk kan doen, maar hoe groter de invloed op het net-

werk wordt. Men dient er dus zeker voor te zorgen dat alleen nuttige en bruikbare informatie

wordt gelogd.

5.2.4 Besluit

Het eerste deel van de evaluatie gaf aan dat het regelgebaseerd systeem de fouten die voorko-

men in het beheerde systeem correct detecteert en aflijnt. Het tweede deel van de evaluatie

ging de werking van het Bayesiaans netwerk na. Er werd gevonden dat de initialisatie van het

systeem relatief snel gebeurt. Ook classificatie van nieuwe fouten gebeurt zeer snel. Vervolgens

werd de efficientie nagegaan en hier werd gevonden dat het netwerk zeer efficient om kan gaan

met enkelvoudige fouten. De efficientie bij meervoudige fouten viel echter tegen. Er moest

vastgesteld worden dat het netwerk zeer slecht werkt bij meervoudige fouten. Bij de evaluatie

van meervoudige fouten in het online systeem kon opgemerkt worden dat ook meervoudige


fouten op een correcte manier uit het systeem konden gefilterd worden, door deze een voor

een aan te pakken. Tijdens het laatste deel van de evaluatie werd het bandbreedtegebruik

van het beheerplatform tegenover het beheerde systeem geevalueerd. Hieruit kon opgemaakt

worden dat het beheerplatform een relatief kleine portie van de bandbreedte gebruikt en dat

dit aandeel zakt naarmate het beheerde systeem groter wordt. Het beheerplatform werkt dus

efficient en heeft een minimale invloed op het beheerde systeem.

Hoofdstuk 6

Conclusie en perspectieven

6.1 Conclusie

In deze thesis werd een beheerplatform ontwikkeld dat fouten in een kritisch gedistribueerd

systeem ontdekt, classificeert en rapporteert aan een beheerder. Er werd gebruik gemaakt

van een emulatie van een patient-monitoring systeem. Deze emulator bevatte verschillende

gedistribueerde nodes met elk hun eigen taak en eigenschappen.

Het beheerplatform draait bovenop een kritisch systeem en stelt twee voorwaarden aan het

onderliggend systeem:

• Enerzijds moet het systeem een heartbeat functionaliteit voorzien. Periodiek dient een

heartbeat van iedere node in het beheerde systeem verstuurd te worden naar het beheer-

platform. Met deze informatie weet het beheerplatform welke nodes zich in het systeem

bevinden, alsook hoe deze nodes met elkaar interageren. Met deze informatie kan een

logische topologie van het onderliggend systeem opgebouwd worden die gebruikt kan

worden bij de analyse van fouten.

• Daarnaast moet het systeem logging voorzien. Deze moet voldoende informatie bevatten

voor het beheerplatform om fouten te kunnen ontdekken en classificeren. Daarnaast

moet het systeem ook voorzien in een mogelijkheid voor het beheerplatform om de

loginformatie op te halen.

Met de informatie van het onderliggend systeem worden fouten geanalyseerd. Dit gebeurt in

twee stappen:

1. Fouten worden ontdekt en afgebakend met behulp van een regelgebaseerde analysecom-

ponent (zoals besproken in Sectie 4.3). Dit is een systeem, opgebouwd met behulp van

regels, dat fouten in de loginformatie kan terugvinden en correct kan afbakenen.

87

Hoofdstuk 6. Conclusie en perspectieven 88

2. Eens de fouten ontdekt en afgebakend zijn, worden ze gevoed aan een Bayesiaanse

detectiecomponent (bespreking in Sectie 4.4). Het naıef Bayesiaans netwerk dat de

classificatie van fouten doet, wordt bij initialisatie van het beheerplatform opgebouwd

met behulp van een trainingsset. Met de informatie, verkregen van de regelgebaseerde

analysecomponent, worden fouten in categorieen onderverdeeld. Het netwerk geeft als

uitkomst welke fout(en) mogelijk in het systeem voorkwam(en) op het bepaalde tijdstip

en de bepaalde plaats, en welke kans elke fout krijgt dat het effectief deze fout was die

voorkwam.

Na deze twee stappen worden de gevonden resultaten gerapporteerd aan een beheerder zoals

uitgelegd in Sectie 4.2.4.

De regelgebaseerde analysecomponent dient voor elk systeem opnieuw opgesteld te worden.

De regels zijn sterk afhankelijk van het beheerde systeem en de logging die voorzien werd.

Een goede kennis van dit systeem is dus vereist om de regels op te stellen. De regels kunnen at

run time aangepast worden, waardoor het vinden en aflijnen van fouten op een directe manier

gewijzigd kan worden. Het voordeel van het gebruik van een regelgebaseerd systeem is het at

run time en direct aanpassen van regels, om zo de efficientie te verbeteren. Het nadeel is dat

een goede kennis van het onderliggend systeem vereist is om de regels op te stellen. Er kruipt

redelijk wat intelligentie in het opstellen van regels. De regels die in deze thesis opgesteld

werden, zijn er om fouten te vinden in de emulator. Deze component werkt vrijwel perfect,

fouten worden correct gevonden en afgelijnd. Enkel meervoudige fouten, die voorkomen in

communicerende componenten in hetzelfde tijdsinterval, worden niet correct gesplitst in de

aparte, enkelvoudige fouten.

Voor de Bayesiaanse detectiecomponent is het noodzakelijk om een trainingsset te voorzien.

Ook deze moet aangepast zijn aan het beheerde systeem. Deze trainingsset kan ook at run

time geupdatet worden. Het netwerk zal echter enkel rekening houden met de vernieuwde

trainingsset als deze geherinitialiseerd wordt. Ook die herinisialisatie kan at run time gebeu-

ren. Het is best om de trainingsset niet te groot te laten worden. De initialisatietijd van het

Bayesiaans netwerk wordt groter naarmate de trainingsset groeit. Ze verlengt met ongeveer

dertig seconden per duizend trainingsinstanties. Fouten gevoed aan de detectiecomponent

worden zeer snel geclassificeerd. Typisch enkele microseconden volstaan om een instantie

te classificeren. De grootte van het netwerk wordt bepaald door enerzijds het aantal trai-

ningsinstanties, maar anderzijds ook door de discretisatie van continue waarden. Dit moet

gebeuren, anders wordt het netwerk steeds groter. De discretisatie heeft een grote invloed

op de grootte van het netwerk, maar een slechts kleine invloed op het gebruik ervan. Men

moet dus vooral rekening houden met de hoeveelheid geheugen, nodig voor de opslag van het

Bayesiaans netwerk, als men de discretisatie doorvoert. Hierin mag echter niet overdreven

worden. Als de discretisatie te grof wordt, zullen alle nuttige continue waarden als gelijk aan-

Hoofdstuk 6. Conclusie en perspectieven 89

zien worden en wordt het moeilijk om fouten correct te classificeren. Ook de granularisatie

van fouten kan deze component beınvloeden. Over het algemeen is de efficientie bij grovere

fouten groter, maar is de informatie -die eruit gehaald kan worden- kleiner. Er dient dus

een afweging gemaakt te worden van beide criteria. Enkelvoudige fouten, afgeleverd door het

regelgebaseerd systeem, worden bijna perfect geclassificeerd. Alle fouten worden gevonden

en de meeste worden ook als meest mogelijk aanzien. Meer informatie in de logging kan de

efficientie eventueel nog verhogen. Voor meervoudige fouten dient in meerdere iteraties ge-

werkt te worden. Hier wordt eveneens in de meeste gevallen minstens een fout gevonden en

meestal wordt deze als beste keuze aangeduid. Ook hier kan extra informatie ervoor zorgen

dat de efficientie verhoogd wordt. Aangezien zelden tot nooit een tweede fout gevonden wordt,

dienen meervoudige fouten een voor een, in verschillende iteraties verwijderd te worden. Op

deze manier kunnen alle fouten uit het systeem gehaald worden.

In het algemeen kan gesteld worden dat de aanzet tot het volledig autonoom beheren van

kritische toepassingen een succes is. Fouten die geıntroduceerd worden in het systeem, worden

vrijwel altijd gevonden en kunnen dus aan een beheerder gerapporteerd worden. Deze kan

dus snel en efficient fouten oplossen.

6.2 Mogelijke uitbreidingen

Het beheerplatform ontworpen tijdens deze thesis is zeker niet af. Dit platform stelt een

diagnose van het beheerde systeem en de fouten die erin voorkomen. Het is nog steeds de taak

van de beheerder om de gevonden fouten uit het systeem te verwijderen. Een eerste uitbreiding

op het huidige beheerplatform is de introductie van acties die uitgevoerd kunnen worden

door het beheerplatform op het beheerde systeem om fouten uit dit systeem te verwijderen.

Daarnaast kunnen ook technieken toegevoegd worden om fouten in de toekomst te vermijden

of op zijn minst de kans op een fout sterk te verlagen. Naast het uitbreiden van het platform

kan ook gezocht worden naar technieken om de huidige implementatie te verbeteren. Het

platform zoals het nu geımplementeerd is, bevat twee knelpunten. Een eerste bevindt zich

in het regelgebaseerd systeem om fouten te detecteren en af te lijnen. Deze aanpak werkt

zeer goed, maar het schrijven van goede regels is geen eenvoudige zaak. Er kan dus gezocht

worden om dit te vereenvoudigen, bijvoorbeeld door automatisch regels voor te stellen. Een

tweede knelpunt bevindt zich in de Bayesiaanse detectiecomponent. Op dit ogenblik is het

niet mogelijk om meervoudige fouten in een iteratie te verwijderen. Er kan dus ook gezocht

worden naar technieken om dit mogelijk te maken, bijvoorbeeld het netwerk trainen met

zowel enkelvoudige als meervoudige fouten. Als laatste kunnen ook technieken geıntroduceerd

worden die toelaten dat het beheerplatform zichzelf beheert. Zoals aangegeven in Hoofdstuk 3

wordt er nu vanuit gegaan dat het beheerplatform correct werkt. Ook in dit platform kunnen

natuurlijk fouten voorkomen, dus zijn technieken om zichzelf te beheren zeker aangewezen.

Bibliografie

[1] A. Aamodt and E. Plaza. Case-based reasoning: Foundational issues, methodological

variations, and system approaches. AI Communications, 7:39–59, 1994.

[2] Nazim Agoulmine and James Won-Ki Hong. Autonomic Network Management Principles

(From Concepts to Applications). Academic Press, 2010.

[3] Nazim Agoulmine and James Won-Ki Hong. Autonomic Network Management Princi-

ples: From Concepts to Applications. Academic Press, 2010.

[4] Satnam Alag. Collective intelligence in action. Manning Publications Co., 2009.

[5] Sergio Antoy and Michael Hanus. Curry, A Tutorial Introduction. Christian-Albrechts-

Universitat Kiel, Germany, 2007.

[6] Algirdas Avizienis, Jean-Claude Laprie, Brian Randell, and Vytautas Magnus U. Fun-

damental concepts of dependability. Technical report, UCLA, LAAS-CNRS, University

of newcastle, 2000.

[7] R. Barrett, P.P. Maglio, E. Kandogan, and J. Bailey. IEEE International Conference

on Autonomic Computing, 2004., chapter Usable autonomic computing systems: the

administrator’s perspective, pages 18 – 25. IEEE Computer Society, 2004.

[8] Berndt Brehmer. The dynamic ooda loop: Amalgamating boyd’s ooda loop and the

cybernetic approach to command and control. The International C2 Journal, 10:15,

2005.

[9] Ingeol Chun, Jeongmin Park, Wontae Kim, Woochun Kang, Haeyoung Lee, and Seung-

min Park. Autonomic computing technologies for cyber-physical systems. In The 12th

International Conference on Advanced Communication Technology (ICT for green growth

and sustainable development ), volume 2, pages 1009 – 1014, Phoenix Park, Korea, Fe-

bruary. 7-10 2010.

[10] Dasc’11. The 9th ieee international symposium on dependable, autonomic and secure

computing. In Call for papers, 2011.

90

Bibliografie 91

[11] Piet Demeester and Brecht Vermeulen. ilab.t virtual wall. http://www.ibcn.intec.ugent.-

be/?q=FAT ilabtvirtualwall, 2012.

[12] Simon Dobson, Roy Sterritt, Paddy Nixon, and Mike Hinchey. Computer - Innova-

tive Technology for Computer Professionals, chapter Fulfilling the Vision of Autonomic

Computing, pages 35–41. IEEE Computer Society, 2010.

[13] Christine Draper. Combine autonomic computing and soa to improve it manage-

ment. http://www.ibm.com/developerworks/webservices/library/ac-mgmtsoa/index.-

html, April 2006.

[14] Gunther Eysenbach. Journal of Medical Internet Research (JMIR). Gunther Eysenbach,

2001.

[15] Tom Fawcett. An introduction to roc analysis. Pattern Recognition Letters, 27:861–874,

2006.

[16] Charles L. Forgy. Rete: A fast algorithm for the many pattern/many object pattern

match problem. Artificial Intelligence, 19:17–37, 1982.

[17] Jose Fortes and Miriam Boon. What is autonomic computing? http://www.isgtw.org/-

feature/what-autonomic-computing, january 2011.

[18] James Freeman-Hargis. Methods of rule-based systems. http://ai-depot.com/Tutorial/-

RuleBased-Methods.html.

[19] Salim Hariri, Bithika Khargharia, Houping Chen, Jingmei Yang, Yeliang Zhang, Ma-

nish Parashar, and Hua Liu. The autonomic computing paradigm. Springer Science +

Business Media, 9:5–17, 2006.

[20] IBM. Autonomic computing - The 8 elements. http://www.research.ibm.com/autono-

mic/overview/elements.html.

[21] A. K. Jain, M. N. Murty, and P. J. Flynn. Data clustering: a review. ACM Computing

Surveys, 31(3):264–323, September 1999.

[22] Finn V. Jensen. An Introduction To Bayesian Networks. UCL Press, may 1996.

[23] Mark J. Kelly, Frank D. Dunstan, Keith Lloyd, and David L. Fone. Evaluating cutpoints

for the mhi-5 and mcs using the ghq-12: a comparison of five different methods. BMC

Psychiatry, 8, 2008.

[24] S. L. Keoh, N. Dulay, E. Lupu, K. Twidle, A. E. Schaeffer-Filho, M. Sloman, S.Heeps,

S. Strowes, and J. Sventek. Self-managed cell: A middleware for managing body-sensor

networks. In International Conference on Mobile and Ubiquitous Systems: Computing,

Networking and Services, 2007.

Bibliografie 92

[25] Janet L. Kolodner. Case-based reasoning. Morgan Kaufmann Publishers, 1993.

[26] William Langdon. Receiver operating characteristics (roc). http://www.cs.ucl.ac.uk/-

staff/ucacbbl/roc/, may 2011.

[27] Steven Latre. Autonomic QoE management of multimedia networks. PhD thesis, Ghent

University, 2011.

[28] E. Lupu, N. Dulay, M. Sloman, J. Sventek, S. Heeps, S. Strowes, K. Twidle, S. l,

A. Schaeffer-filho, Sw Az, and G Rz. Amuse: Autonomic management of ubiquitous

e-health systems. In Special Issues of the Journal of Concurrency and Computation:

Practice and Experience, 2007.

[29] Julie A. McCann and Markus Huebscher. Evaluation issues in autonomic computing. In

In Proceedings of the Conference on Grid and Cooperative Computing Workshops, pages

597–608, 2004.

[30] Richard Murch. Autonomic computing. Prentice Hall PTR, 2004.

[31] L. R. Rabiner and B. H. luang. An introduction to hidden markov models. IEEE ASSP

MAGAZINE, 4:4–16, 1986.

[32] G. Rebane and J. Pearl. Proceedings, 3rd Workshop on Uncertainty in AI, chapter The

Recovery of Causal Poly-trees from Statistical Data, pages 222–228. Seattle, WA, 1987.

[33] S. Rasoul Safavian and David Landgrebe. A survey of decision tree classifier methodology.

IEEE Transactions on Systems, Man, and Cybernetics, 21:660–674, 1991.

[34] Suresh Sambandam. Rule based system. http://www.slideshare.net/sureshsambandam/-

rule-based-system-presentation, November 2008.

[35] M. Sasikumar, S. Ramani, S. Muthu Raman, KSR. Anjaneyulu, and R. Chandrasekar.

A Practical Introduction to Rule Based Expert Systems. Narosa Publishing House, New

Delhi, 2007.

[36] Edward Hance Shortliffe. Computer-based medical consultations, MYCIN. Elsevier, 1976.

[37] P. H. A. Sneath and R. R. Sokal. Numerical taxonomy. The principles and practice of

numerical classification. W H Freeman & Co (Sd), 1973.

[38] John A. Swets. Signal Detection Theory and Roc Analysis in Psychology and Diagnostics:

Collected Papers. Lawrence Erlbaum Associates, 1996.

[39] W. et al. Truszkowski. Autonomous and Autonomic Systems, NASA Monographs in Sys-

tems and Software Engineering, chapter Autonomic Systems, pages 173–186. Springer-

Verlag London Limited 2009, 2009.

Bibliografie 93

[40] Barry De Ville. Decision Trees for Business Intelligence and Data Mining: Using SAS.

SAS Institute, 2006.

[41] Ian Watson and Farhi Marir. Case-based reasoning: A review. the Knowledge Engineering

Review, 9(4):355–381, 1994.

Autonoom beheerplatform voor de detectie van fouten in...

Documents

Transcript of Autonoom beheerplatform voor de detectie van fouten in...