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é
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
Hoofdstuk 2. Literatuurstudie 6
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
Hoofdstuk 2. Literatuurstudie 7
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.
Hoofdstuk 2. Literatuurstudie 8
• 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
Hoofdstuk 2. Literatuurstudie 9
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
Hoofdstuk 2. Literatuurstudie 10
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.
Hoofdstuk 2. Literatuurstudie 11
• 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.
Hoofdstuk 2. Literatuurstudie 12
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
Hoofdstuk 2. Literatuurstudie 13
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
Hoofdstuk 2. Literatuurstudie 14
• 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
Hoofdstuk 2. Literatuurstudie 15
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
Hoofdstuk 2. Literatuurstudie 16
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
Hoofdstuk 2. Literatuurstudie 17
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
Hoofdstuk 2. Literatuurstudie 18
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
Hoofdstuk 2. Literatuurstudie 19
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-
Hoofdstuk 2. Literatuurstudie 20
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
Hoofdstuk 2. Literatuurstudie 21
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.
Hoofdstuk 2. Literatuurstudie 22
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
Hoofdstuk 2. Literatuurstudie 23
(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
Hoofdstuk 2. Literatuurstudie 24
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]
Hoofdstuk 2. Literatuurstudie 25
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,
Hoofdstuk 2. Literatuurstudie 26
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.
Hoofdstuk 2. Literatuurstudie 27
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
Hoofdstuk 2. Literatuurstudie 28
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.
Hoofdstuk 2. Literatuurstudie 29
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
Hoofdstuk 2. Literatuurstudie 30
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.
Hoofdstuk 3. Use case 33
• 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.
Hoofdstuk 3. Use case 34
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
Hoofdstuk 3. Use case 35
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
Hoofdstuk 3. Use case 36
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
Hoofdstuk 3. Use case 37
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.
Hoofdstuk 4. Oorzaakdetectie 40
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
Hoofdstuk 4. Oorzaakdetectie 41
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:
Hoofdstuk 4. Oorzaakdetectie 42
– 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
3 Mar 11 , 2012 5 : 5 6 : 3 0 PM BloeddrukSensor zendBloedDruk
4 SEVERE: WebException FileNotFoundException IOException
5 Mar 11 , 2012 5 : 5 7 : 3 0 PM BloeddrukSensor zendBloedDruk
6 SEVERE: WebException FileNotFoundException IOException
7 Mar 11 , 2012 5 : 5 8 : 3 0 PM BloeddrukSensor zendBloedDruk
8 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
Hoofdstuk 4. Oorzaakdetectie 43
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
Hoofdstuk 4. Oorzaakdetectie 44
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.
Hoofdstuk 4. Oorzaakdetectie 45
Figuur 4.3: Visuele representatie van het beheerde systeem
Figuur 4.4: Rapportering van fouten
Hoofdstuk 4. Oorzaakdetectie 46
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
Hoofdstuk 4. Oorzaakdetectie 47
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
Hoofdstuk 4. Oorzaakdetectie 48
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.
Hoofdstuk 4. Oorzaakdetectie 49
• 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
Hoofdstuk 4. Oorzaakdetectie 50
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
Hoofdstuk 4. Oorzaakdetectie 51
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
Hoofdstuk 4. Oorzaakdetectie 52
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/
Hoofdstuk 4. Oorzaakdetectie 53
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.
Hoofdstuk 4. Oorzaakdetectie 54
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
Hoofdstuk 4. Oorzaakdetectie 55
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,
Hoofdstuk 4. Oorzaakdetectie 56
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
Hoofdstuk 5. Evaluatie 59
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
Hoofdstuk 5. Evaluatie 60
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
Hoofdstuk 5. Evaluatie 61
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.
Hoofdstuk 5. Evaluatie 62
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.
Hoofdstuk 5. Evaluatie 63
• 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.
Hoofdstuk 5. Evaluatie 64
• 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
Hoofdstuk 5. Evaluatie 65
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.
Hoofdstuk 5. Evaluatie 66
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
Hoofdstuk 5. Evaluatie 67
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
Hoofdstuk 5. Evaluatie 68
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.
Hoofdstuk 5. Evaluatie 69
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
Hoofdstuk 5. Evaluatie 70
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
Hoofdstuk 5. Evaluatie 71
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
Hoofdstuk 5. Evaluatie 72
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
Hoofdstuk 5. Evaluatie 73
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
Hoofdstuk 5. Evaluatie 74
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
Hoofdstuk 5. Evaluatie 75
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
Hoofdstuk 5. Evaluatie 76
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
Hoofdstuk 5. Evaluatie 77
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.
Hoofdstuk 5. Evaluatie 78
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-, databank- en 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
Hoofdstuk 5. Evaluatie 79
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.
Hoofdstuk 5. Evaluatie 80
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%
Hoofdstuk 5. Evaluatie 81
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.
Hoofdstuk 5. Evaluatie 82
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%
Hoofdstuk 5. Evaluatie 83
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
Hoofdstuk 5. Evaluatie 84
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
Hoofdstuk 5. Evaluatie 85
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
Hoofdstuk 5. Evaluatie 86
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.
Top Related