Bachelor Informatica
Algoritme voor het beheren en
bewerken van videobeelden uit
de digitale operatiekamer
Lars Lokhoff
17 juli 2017
Supervisor(s): Jurgen Deege (ChipSoft), Robert Belleman
Inf
orma
tica
—
Universiteit
v
an
Ams
terd
am
Samenvatting
Video’s die worden opgenomen in een operatiekamer zijn van groot belang voor een ziekenhuis en haar specialisten. De processen die op een videoserver draaien naast het opnemen van de video’s mogen de opname niet verstoren. Ook mogen de processen elkaar niet zodanig in de weg zitten dat er fouten optreden op de videoserver en in de werkstations op een operatiekamer. In opdracht van ChipSoft is een algoritme ontwikkeld dat de processen op een videoserver regelt met als doel het beschermen van de videoopnames en het verhogen van de up-time van de videoserver. Het algoritme regelt het opnemen, knippen, verplaatsen en verwijderen van video’s en snapshots zodanig dat de resources van de videoserver niet overbelast raken. Aan de hand van het aantal draaiende processen start het algoritme processen, rekening houdend met het maximale resourcegebruik van deze processen. Uit de experimenten concluderen we dat het algoritme de processen op een juiste manier regelt en het opneemproces niet lijdt onder het resourcegebruik van de andere processen.
Inhoudsopgave
1 Introductie 7
1.1 Onderzoeksvraag . . . 7
1.2 ChipSoft . . . 8
2 Achtergrond 9 2.1 Opstelling Videoserver in een Digitale OK . . . 9
2.2 Videoserver . . . 10 2.3 Processen . . . 11 2.4 Model . . . 12 3 Implementatie 13 3.1 Globaal Ontwerp . . . 13 3.2 Resources Meten . . . 14
3.3 Schedulen van Processen . . . 15
3.4 Proces Starten . . . 17
4 Experimenten 19 4.1 Waardes in het Model . . . 19
4.2 Algoritme Testen . . . 20
5 Conclusie 23 5.1 Toekomst . . . 23
HOOFDSTUK 1
Introductie
Door de modernisering van ziekenhuizen komt het gebruik van opnameapparatuur in de operatiekamer (OK) tegenwoordig steeds vaker voor [1]. De opgenomen videobeelden zijn be-langrijk voor een specialist omdat deze gebruikt worden bij een consult van de pati¨ent, voor verder onderzoek na een operatie, als bewijsmateriaal bij incidenten die tijdens een operatie plaats kunnen vinden of in een verslag van de specialist. De video’s moeten om de laatste reden ook wettelijk verplicht 3 maanden bewaard worden. Buiten het feit dat videobeelden van hoge waarde zijn voor de specialist, is het niet mogelijk een operatie over te doen. Een video kan maar eenmalig gemaakt worden. De videobeelden moeten dus correct worden opgenomen zonder dat er beelden verloren gaan. Denk hierbij aan een operatie waarbij beelden worden opgenomen om een aandoening vast te stellen bij een pati¨ent. Als juist de beelden die de specialist helpen bij het vinden van een aandoening verloren gaan, kan dit nare gevolgen hebben voor specialist en pati¨ent.
Voor het opnemen en opslaan van de videobeelden wordt een videoserver gebruikt. Deze videoserver draait naast het opnemen ook andere processen. Tijdens het opnemen kunnen er snapshots, oftewel stilstaande beelden van de video, gemaakt worden. Deze snapshots worden net als de video’s na een operatie gebruikt voor consult met een pati¨ent, verder onderzoek of om mee te sturen met een recept naar bijvoorbeeld een huisarts. Er worden stukjes uit opgenomen video’s geknipt, er worden video’s en afbeeldingen verplaatst naar de externe storageserver en er wordt beeldmateriaal verwijderd. Met uitzondering van het opnemen, kunnen er van elk proces meerdere instanties tegelijk draaien.
Omdat er meerdere processen tegelijk kunnen draaien op de videoserver moet rekening worden gehouden met de eindige hoeveelheid resources van een videoserver. Elk proces maakt gebruik van deze resources op de videoserver. Tijdens het opnemen van een video kunnen er beelden verloren gaan als het maximaal aantal resources van de videoserver gebruikt wordt. Omdat het zo belangrijk is dat een opname volledig is, mogen de resources dus niet overbelast raken tijdens het opnemen van een video. Naast de belangrijke videobeelden is het ook van belang dat een operatie ongestoord kan verlopen. Het is niet wenselijk dat een operatie stil komt te liggen omdat er iets fout gaat met het opnemen. Omdat de OK en de apparatuur die daar gebruikt wordt steriel is kost het een systeembeheerder veel moeite om een OK binnen te gaan en een fout op een werkstation te verhelpen.
1.1
Onderzoeksvraag
In deze scriptie wordt een algoritme gepresenteerd dat het draaien van processen op de video-server regelt zonder dat daarbij het opnemen van video’s verstoord wordt. Dit algoritme is ontworpen en ge¨ımplementeerd in opdracht van ChipSoft. Het algoritme start processen zonder dat het belangrijkste proces, het opnemen van de video, hierdoor onderbroken wordt. Indien
nodig worden processen stopgezet aan de hand van het resourcegebruik op de videoserver. Het algoritme heeft het doel om zoveel mogelijk processen naast elkaar op de videoserver te draaien. De processen waar het algoritme mee te maken heeft zijn: het opneemproces, het knipproces, het
verplaatsproces en het verwijderproces. Wat deze processen precies inhouden wordt later bespro-ken. Het algoritme houdt het resourcegebruik van elk proces bij en gebruikt dit bij het regelen van de processen. De onderzoeksvraag van deze scriptie is: Hoe regelen we de processen op de videoserver zodanig dat de resources van de videoserver niet overbelast raken en het opnemen van de video niet onderbroken wordt.
1.2
ChipSoft
Het ontwikkelen en implementeren van het algoritme is gedaan in opdracht van ChipSoft. ChipSoft is een softwarebedrijf dat software levert met als doel het ondersteunen van zorgverleners bij het bieden van de juiste zorg. ChipSoft levert sinds 2013 een totaalsysteem voor de zorg genaamd HiX. ”De primaire ambitie van ChipSoft is: innovatieve software blijven ontwikkelen die iedere zorgverlener ondersteunt en faciliteert om op het juiste moment de juiste zorg aan de pati¨ent te leveren. Om die ambitie te verwezenlijken, onderzoekt ChipSoft voortdurend de mogelijkheden om zorg n´og effici¨enter te maken, zodat schaarse tijd en middelen optimaal kunnen worden in-gezet ten bate van de pati¨ent.”[2]
ChipSoft heeft de opdracht voor het ontwikkelen van dit algoritme gegeven omdat er in de huidige opzet van ChipSoft voornamelijk kortere video’s worden opgenomen. ChipSoft wil een overgang maken naar een opzet waarbij ook langere video’s opgenomen kunnen worden, zonder dat de videobeelden of de videoserver hieronder lijden. Het algoritme is ontwikkeld als aanvulling van de CS-MultiMedia module in HiX. Door het gebruik van CS-MultiMedia voor de integratie van beeldmateriaal in het EPD worden de beelden onmiddellijk onderdeel van de medische context n van het totale werkproces. Het is daardoor mogelijk om het beeldmateriaal op precies het juiste moment, gekoppeld aan het juiste dossier aan de zorgverlener/behandelaar aan te bieden. Dit gebeurt ook nog eens binnen dezelfde user interface, zodat de gebruiker zonder overbodige muis-klikken en inlogacties zijn/haar werk kan doen. Deze integratie met het EPD zorgt ervoor dat beeldmateriaal moeiteloos kan worden ingezet om bijvoorbeeld multidisciplinaire besprekingen en verslaglegging te onder-steunen.
Naast bovengenoemde functionaliteit kan CS-MultiMedia worden ingezet voor andere doelein-den. Bijvoorbeeld (geen onderdeel van deze aanbieding) het feit dat alle gescande documenten en andere bestanden kunnen worden gekoppeld aan informatie in HiX. Denk hierbij aan het verwijsbriefje van de verloskundige wat bij een patint in het gynaecologisch dossier moet worden opgenomen, aan het aanvraagbriefje voor het radiologisch onderzoek of aan de foto van een patint of lichamelijk kenmerk van de patint. Diverse media kunnen aan een patintnummer worden ge-koppeld, maar kunnen ook worden gehangen aan een gebeurtenis, bijvoorbeeld aan een afspraak van een patint. Media kunnen binnen of buiten HiX worden opgeslagen.
HOOFDSTUK 2
Achtergrond
In dit hoofdstuk behandelen we de opstelling van een digitale OK, de workflow van een arts tijdens een operatie en de specificaties van de videoserver waarop het algoritme is getest. Verder leggen we uit welke resources het algoritme rekening mee houdt en wat de processen inhouden die het algoritme gaat regelen.
2.1
Opstelling Videoserver in een Digitale OK
Figuur 2.1 geeft een overzicht weer van de opstelling die gebruikt wordt bij het opnemen van video’s. Er zijn drie hoofdonderdelen te onderscheiden: de OK met daarin de werkstations, de videoswitch en de videoserver. Bij het maken van een opname start de specialist het opnemen van een video op een van de werkstations. De werkstations staan in verbinding met de videoserver en een centrale videoswitch. De videoswitch ontvangt meerdere signalen vanuit verschillende OK’s en stuurt de signalen door naar de betreffende videoserver. Een video wordt vanuit de OK via de videoswitch verzonden met een HDMI of SDI aansluiting naar de capture card van de videoserver. Met behulp van de capture card en de VisioForge SDK [3] wordt een video opgenomen en opgeslagen op de videoserver. In de OK staan ook twee voetpedalen die zijn aangesloten op de videoswitch. Het ene voetpedaal wordt gebruikt om snapshots van de video te maken. Als een specialist dit pedaal indrukt gaat er via de videoswitch een signaal naar de videoserver dat er een snapshot gemaakt moet worden. De videoserver maakt een snapshot en stuurt deze via de videoswitch terug naar de werkstations op de OK zodat de specialist het snapshot kan bekijken. Het tweede voetpedaal wordt gebruikt door de specialist om de start- en eindtijden te registreren van belangrijke delen van een video die er later uitgeknipt worden. Als een operatie voltooid is en de opname is gestopt, worden er op de tijden die de specialist heeft aangegeven stukjes uit de video geknipt. Deze stukjes video worden vervolgens, samen met de originele video en de snapshots verplaatst van de videoserver naar de externe storageserver.
Figuur 2.1: De opstelling van video’s opnemen in het ziekenhuis.
2.2
Videoserver
Het algoritme wordt ge¨ımplementeerd op een videoserver die deel uit maakt van de hierboven beschreven opstelling. De videoserver gebruikt voor het ontvangen van het videosignaal een Blackmagic Design DeckLink Mini Recorder 4k [4]. De capturekaart heeft 2 aansluitingen: een 6G SDI aansluiting een een HDMI aansluiting, waarvan maar 1 aansluiting tegelijk gebruikt kan worden om een videosignaal te ontvangen. De videobeelden die worden opgenomen met de capture card hebben een resolutie van 1920x1080 pixels en 30 fps. Naast de capture card bevat de videoserver waarop het algoritme is getest een Intel Core i7-4790 CPU, een 1TB Western Digital harddisk met een maximum bandbreedte van 600 MB/s en 32GB aan werkgeheugen. De belasting van de hardware componenten is eindig. Het algoritme houdt daarom de volgende statistieken van de resources bij:
• CPU: hoeveel % van de CPU er op dit moment gebruikt wordt en hoeveel % van de CPU heeft een proces dat gestart wil worden maximaal nodig.
per seconde er gelezen wordt op de harddisk. Bij het starten van een proces wordt gekeken naar de hoeveelheid bytes die een proces per seconde schrijft of leest. Ook wordt gekeken naar de opslagcapaciteit van de harddisk bij het verplaatsen en knippen van bestanden. • Werkgeheugen: hoeveel bytes van het totale werkgeheugen zijn in gebruik. Bij het starten
van een nieuw proces wordt gekeken naar de hoeveelheid bytes die een proces reserveert van het werkgeheugen.
• Processen: per type proces (knippen, verplaatsen of verwijderen) hoeveel processen er draaien.
• Tijd: het algoritme houdt bij hoeveel tijd een proces nodig heeft om af te ronden en hoeveel tijd er is verstreken sinds de laatste opname.
2.3
Processen
De processen die het algoritme regelt draaien naast elkaar op de videoserver. Er kunnen meerdere instanties van een proces naast elkaar draaien, met uitzondering van het opnemen van een video. De processen die het algoritme regelt zijn:
1. Opneemproces: het opneemproces neemt videobeelden op uit de OK en slaat deze op de vi-deoserver op. De beelden worden tijdens het opnemen gecomprimeerd om de grootte van de beelden te verminderen en er kunnen tijdens het opnemen snapshots gemaakt worden door een specialist. Dit proces heeft de hoogste prioriteit en mag niet lijden onder het draaien van de overige processen op de videoserver. Het opneemproces wordt niet aangestuurd door het algoritme, maar vanuit de OK. De belangrijkste resources voor het opnemen zijn de CPU en de harddisk. Om video’s op te nemen wordt gebruik gemaakt van een SDK genaamd VisioForge [3]. Deze SDK maakt het mogelijk om de video’s met de capture card op te nemen en te comprimeren. De video’s worden gecomprimeerd met behulp van een H.264 encodering en hebben een mp4 extentie [5] [6].
2. Knipproces: het knipproces knipt stukken uit een opgenomen video. De lengte en plaats van de stukken wordt aangegeven door een specialist. Dit zullen stukken video zijn die de specialist later wil gebruiken voor bijvoorbeeld verder onderzoek. Omdat de geknipte stukjes video minder belangrijk zijn dan de originele video worden deze tijdens het knippen opnieuw ge¨encodeerd zodat ze minder ruimte op de harddisk innemen [7]. Het opnieuw encoderen van de stukjes video is erg CPU intensief. Ook kost het opnieuw encoderen van de stukjes video veel tijd. Het knippen en opnieuw encoderen wordt gedaan met behulp van FFmpeg [8]. FFmpeg is een command-line tool waarmee men stukjes uit video’s kan knippen en waarmee deze stukjes ook opnieuw ge¨encodeerd kunnen worden.
3. Verplaatsproces: Het verplaatsproces verplaatst video’s en snapshots van de videoserver naar de externe storageserver, zodat deze klaar zijn voor gebruik door de specialist na de operatie. Bij het verplaatsen van een bestand is de belangrijkste resource de harddisk. 4. Verwijderproces: het verwijderproces verwijdert video’s of snapshots van de videoserver
die niet meer nodig zijn en aan de wettelijk verplichte opslagtermijn hebben voldaan. Ook bij het verwijderen is de harddisk de belangrijkste resource.
Als er tijdens het opneemproces een of meerdere processen gestart worden die zoveel resources gebruiken dat de videoserver overbelast raakt, is de kans groot dat het opneemproces of een operatie hieronder lijdt. Als door overbelasting van de videoserver een foutmelding ontstaat op een van de werkstations moet een systeembeheerder de steriele OK in. Dit kost extra tijd, manuren en kan ten koste gaan van de veiligheid van de pati¨ent. Het algoritme heeft als taak om dit te voorkomen en zal processen starten aan de hand van de hoeveelheid resources die vrij zijn op de videoserver en de hoeveelheid resources die de processen nodig hebben.
2.4
Model
Om te bepalen of een proces gestart mag worden gebruikt het algoritme een model. Met behulp van het model kan worden bepaald hoeveel de CPU, de harddisk en het werkgeheugen belast worden bij het draaien van processen op de server. Naast de maximale hoeveelheid resources wordt ook bepaald hoelang het duurt voordat een proces is afgerond om te zorgen dat een proces niet overlapt met de eerstvolgende operatie.
Omdat we te maken hebben met een maximum belasting van de resources die we niet willen overschrijden, gebruikt het algoritme vergelijking 2.1 om de maximale belasting van een resource bij een bepaalde hoeveelheid actieve processen te berekenen. In de vergelijking wordt de maxi-male belasting van alle actieve processen berekend door de maximaxi-male belasting van 1 proces te vermenigvuldigen met het aantal actieve processen, zoals te zien in vergelijking 2.2. Het proces dat gestart wil worden wordt daarbij als actief gezien. Zo kan het algoritme bepalen of met het starten van het nieuwe proces de maximale belasting wordt overschreden. Om te bepalen of een maximum overschreden wordt moet het algoritme weten wat de maxima van de resources zijn. De CPU heeft een maximale belasting van 100%, waarbij we 5% reserveren voor achtergrond-processen en het besturingssysteem. De maximum belasting van de achtergrond-processen is dus 95%. De harddisk heeft zoals eerder genoemd een maximum bandbreedte van 600 MB/s. Deze houden we aan als maximum. Het totale werkgeheugen van de videoserver bedraagt 32GB. Er wordt 2GB aan werkgeheugen gereserveerd voor achtergrondprocessen en het besturingssysteem, waardoor het maximum op 30GB werkgeheugen uitkomt.
maximaal resourcegebruik = maximaal gebruik opnemen + maximaal gebruik knippen + maximaal gebruik verplaatsen + maximaal gebruik verwijderen (2.1)
maximaal gebruik X = aantal actieve processen X * maximaal 1 X (2.2)
Om te bepalen hoelang het duurt voordat een knipproces is afgerond, wordt voor een knip-proces gekeken naar de lengte van het te knippen stuk video. Deze wordt vermenigvuldigd met de tijd die het duurt om 1 seconde video te knippen. Bij het bepalen van de tijd die het kost om een verplaats- of verwijderproces uit te voeren wordt de grootte van het bestand in bytes vermenigvuldigd met de tijd die het kost om een byte te verwijderen ofwel te verplaatsen. Het bepalen van de maximale hoeveelheid benodigde resources van de actieve processen en de tijd die het kost om een proces af te ronden maken deel uit van het beslisproces van het algoritme. Het volledige beslisproces wordt behandeld in sectie 3.3.
HOOFDSTUK 3
Implementatie
In dit hoofdstuk behandelen we de implementatie van het algoritme, waarbij eerst kort wordt uitgelegd hoe het ontwerp van het algoritme in elkaar steekt. Vervolgens leggen we uit hoe het algoritme bepaalt of een proces gestart mag worden aan de hand van de gebruikte resources op de videoserver en laten we zien hoe de verschillende resources gemeten worden.
Het algoritme is geschreven in de C# programmeertaal, omdat dit de programmeertaal is die gehanteerd wordt binnen ChipSoft.
3.1
Globaal Ontwerp
Het algoritme is opgedeeld in 2 componenten: een schedulingcomponent en een procescompo-nent.
Het schedulingcomponent maakt met behulp van de vergelijkingen uit het model de beslissing of een proces gestart mag worden. Deze is ge¨ımplementeerd in het programma genaamd schedu-ler.exe. Hoe de scheduler de beslissing maakt of een proces kan starten zal later worden behandeld onder het kopje Schedulen van Processen. De scheduler communiceert met het procescomponent, zoals te zien in is in figuur 3.3. De scheduler communiceert alleen met het procescomponent, omdat de scheduler het procescomponent commando’s geeft over het starten van de processen. Het procescomponent start de processen op aangeven van de scheduler en stuurt de scheduler de id van het gestarte proces, zodat deze het proces kan monitoren. Het procescomponent is ge¨ımplementeerd in processStarter.exe. Zoals te zien in figuur 3.3 stuurt het procescomponent de 4 processen aan. Een proces mag alleen gestart worden vanuit het procescomponent. Er is gekozen om het algoritme op te delen in 2 componenten, omdat zo het meten en maken van beslissingen buiten het starten van nieuwe processen om door kan gaan. De communicatie tussen de componenten verloopt met behulp vanNamed Pipes[9]. Named Pipeswerken volgens het cli¨ent server model. Omdat beide componenten berichten naar elkaar sturen en berichten met eenNamed Pipemaar in 1 richting verstuurd kunnen worden gebruiken we 2 pipes. Op deze manier kunnen beide componenten berichten versturen en verzenden.
Figuur 3.1: Verbinding tussen de componenten en processen.
3.2
Resources Meten
Om te beslissen of een proces mag starten op de videoserver moet het algoritme weten wat de staat van de server op dat moment is. Met de staat van de server bedoelen we de hoeveelheid resources die op dit moment gebruikt worden, hoeveel processen er van elk type draaien en als er op dit moment niet opgenomen wordt, de tijd sinds de laatste opname.
De statistieken houdt het algoritme bij in 2 dictionaries genaamdserverStateen runningProces-ses. DeserverStatedictionary bevat de informatie over de CPU, harddisk, het werkgeheugen en de tijd waarop de laatste opname is afgerond. De runningProcesses dictionary bevat van elke proces hoeveel er op dit moment actief zijn op de videoserver en of er op dit moment opgenomen wordt.
Om de belasting van de CPU, de harddisk en het werkgeheugen van de videoserver te meten gebruiken we een C# klasse genaamdPerformanceCounter[10]. Voor elke resource maken we een apartePerformanceCounter aan. Hoe een PerformanceCounter aangemaakt en gebruikt wordt is te zien in figuur 3.2. Bij het aanmaken verwacht de counter 3 argumenten: Categorie, Coun-ternaam en Instantie. Het Categorie argument bepaalt welk performance object gemeten wordt. Denk hierbij aan bijvoorbeeld de harddisks of de CPU. De Counternaam bepaalt welk aspect gemeten wordt van het performance object. Bijvoorbeeld de hoeveelheid bytes die geschreven worden op de harddisks of de belasting in procenten van de CPU. De Instantie geeft aan welk deel van het performance object gemeten wordt. Zo kan er bijvoorbeeld in plaats van alle hard-disks een specifieke harddisk geselecteerd worden. EenPerformanceCounter meet constant de gewenste waarde op de achtergrond. Om een waarde op te vragen wordt deNextValue()functie gebruikt.
1 using System.Diagnostics.PerformanceCounter;
2
3 //Maak nieuwe PerformanceCounter aan
4 PerformanceCounter counter = new PerformanceCounter(Catagorie,
5 Counternaam, Instantie);
6
7 //Vraag huidige belasting van de CPU op in \%
8 double counterValue = counter.NextValue();
Figuur 3.2: Het aanmaken van een PerformanceCounter en het opvragen van een waarde.
3.3
Schedulen van Processen
Het algoritme start processen aan de hand van de staat van de videoserver. Alle resources van de videoserver dienen onder het maximum te blijven. Om te weten welke processen er gestart moeten worden, hanteert het algoritme 3 queue’s. Een queue voor de knipprocessen, een queue voor de verplaatsprocessen en een queue voor de verwijderprocessen. De queue’s zijn FIFO (first in, first out) queue’s. Er is gekozen om FIFO queue’s te gebruiken omdat zo de ouderen pro-cessen eerst de kans krijgen om te draaien. Om een queue te implementeren gebruiken we de
Queue<T>klasse [11]. Een item in een queue bevat per soort proces de benodigde informatie om het proces te starten. Bij een item uit de knipqueue zijn dat het pad naar de te knippen video en de tijden waarop de video geknipt moet worden. Een item uit de verplaatsqueue bevat het pad van het te verplaatsten bestand en het pad naar de bestemming van het bestand. In een item van de verwijderqueue staat het pad naar een te verwijderen bestand. Het algoritme kiest de volgende queue aan de hand van de opslagcapaciteit van de harddisk van de videoserver. Als er minimaal 3GB aan geheugen vrij is op de harddisk dan houdt het algoritme de volgorde knipqueue, verplaatsqueue en verwijderqueue aan. 3GB om genoeg ruimte over te laten voor een video van 1 uur, de gemiddelde duur van een video uit de OK. Als deze hoeveelheid niet vrij is dan slaat het algoritme de knipqueue over om met het afhandelen van de verplaats- en verwijderprocessen geheugen op de videoserver vrij te maken. De knipqueue wordt overgeslagen tot de verwijder- en verplaatsqueue leeg zijn.
Het starten van een proces gaat aan de hand van een aantal stappen die het algoritme uitvoert:
1. De eerste stap van het algoritme is het verversen van de statistieken die het algoritme bijhoudt van de videoserver.
2. De tweede stap is het bepalen hoeveel resources de draaiende processen plus het nieuwe proces maximaal nodig hebben. Het
algoritme gebruikt hiervoor het model zoals beschreven in sectie 2.4. Het algoritme bepaalt met behulp van het model de belasting van de CPU, de hoeveelheid bytes per seconde die gelezen en geschreven gaan worden, de hoeveelheid werkgeheugen die het proces nodig gaat hebben en de tijd die het gaat kosten om een proces uit te voeren. Ook bepaalt het algoritme voor een knip- of verplaatsproces hoeveel geheugen er nodig is om het bestand op te slaan. Om de hoeveelheid resources te bepalen heeft elk proces zijn eigen functie:
calculateCutResources(),calculateMoveResources()encalculateDeleteResources(). 3. Bij de derde stap wordt de uiteindelijke beslissing genomen of het proces gestart mag
worden. Dit wordt gedaan op basis van de bij stap 1 en 2 bepaalde waardes en de ge-update statistieken. Een proces mag starten als voldaan wordt aan een van de volgende voorwaarden:
• Het opneemproces is actief en er zijn genoeg vrije resources om het nieuwe proces te starten.
• Het opneemproces is niet actief en het nieuwe proces is niet klaar voor het beginnen van de volgende opname, maar er blijven wel genoeg resources over om het opneemproces te starten.
• Het opneemproces is niet actief, maar het nieuwe proces is afgerond voordat het volgende opneemproces begint.
4. Als besloten is dat het proces voldoet aan een van de 3 boven genoemde voorwaarden, stuurt de scheduler een bericht naar het procescomponent. Daar wordt het proces gestart. Als besloten is dat het proces niet gestart mag worden, begint het algoritme bij stap 1 met een item uit de volgende queue. Als een proces niet mag starten omdat deze niet klaar zou zijn voor de volgende opname en het proces gebruikt te veel resources wordt het proces achteraan de queue gezet. Op deze manier kan het algoritme kortere processen een kans geven zonder dat ze moeten wachten op een langdurig proces.
3.4
Proces Starten
Als het procescomponent een bericht ontvangt waarin staat dat hij een proces moet starten, leest hij de bijbehorende argumenten uit de tekst file. Vervolgens maakt hij een nieuw proces aan met behulp van de System.Diagnostics.Process klasse, voegt de argumenten toe aan de StartInfo
en start het proces. De argumenten bevatten de informatie die een proces dat gestart wordt nodig heeft om zijn taak uit te voeren. Als laatste vraagt het procescomponent het id van het net gestarte proces op en stuurt deze naar de scheduler. In figuur 3.4 wordt als voorbeeld een verplaatsproces gestart. Als FileName wordt het pad meegegeven naar de executable, in dit geval MoveFile.exe. Als argumenten worden de naam van de te verplaatsen file en zijn bestemming meegegeven.
1 Process process = new Process();
2
3 process.StartInfo.FileName = pad/naar/executable/MoveFile.exe;
4 process.StartInfo.Arguments = file die verplaatst wordt + bestemming;
5 process.Start();
6
7 var id = process.GetId
8 sendIdToServer(id);
HOOFDSTUK 4
Experimenten
In dit hoofdstuk behandelen we de experimenten die zijn uitgevoerd om de werking van het algoritme te testen en behandelen we de metingen die zijn uitgevoerd om te bepalen welke waardes we in het model gebruiken, zodat het algoritme het maximale resourcegebruik van de processen kan bepalen. Tijdens de experimenten en metingen is gebruik gemaakt van de opzet zoals beschreven in sectie 2.3.
4.1
Waardes in het Model
Om de waardes die in het model in tabel 4.1 als variabelen weergegeven worden in te vullen, zijn er metingen verricht. Van elk van de 4 processen is tijdens het verloop van een proces gemeten hoeveel procent CPU het proces gebruikt, hoeveel MB er geschreven of gelezen wordt en hoeveel MB aan werkgeheugen een proces reserveert. De resultaten van de metingen zijn te zien in tabel 4.1. Elk proces is 100 maal gemeten en de weergegeven waardes zijn de hoogst gemeten waardes per resources over deze metingen. Belangrijk om te vermelden is dat de grootte van de bestanden die verplaatst, verwijderd of geknipt worden een factor 10 kleiner zijn dan bestanden die men op de videoserver van een OK zou verwachten. Er is hiervoor gekozen met het oog op de tijd die het zou kosten om bestanden van 5GB of groter te verplaatsen, verwijderen of te knippen. Bij het opnemen is het resourcegebruik gemeten door een video van 15 minuten op te nemen, waarbij elke seconde een snapshot gemaakt wordt. Om het resourcegebruik van een knipproces te meten zijn stukjes video van 5 minuten uit een video van 15 minuten geknipt met starttijden op 0 minuten, 5 minuten en 10 minuten. Het resourcegebruik van een verplaatsproces is gemeten door een video van 15 minuten te verplaatsen naar een externe netwerkschijf. Het resourcege-bruik van een verwijderproces is gemeten door een video van 15 minuten te verwijderen.
Resource Opnemen Knippen Verplaatsen Verwijderen CPU (%) 18.1 ±0.1 92.2 ±7.0 2.3 ±0.3 15.0 ±25.4 Harddisk schrijven (MB/s) 3.4 ±6.1 ∗ 106 3.5 ±2.3 1.2 ±2.1 ∗ 106 44.1 ±1.6 ∗ 109
Harddisk lezen (MB/s) 0.1 ±0.0 2.4 ±1.4 ∗ 107 116.7 ±3.2 ∗ 107 25.9 ±3.1 ∗ 109
Werkgeheugen (MB) 481.7 ±1.3 567.7 ±1.2 ∗ 106 21.7 ±203.4 13.6 ±885.6 Tijd (ms) nvt 39368 ±663269112 9794 ±289361 14141 ±49177794
Tabel 4.1: De gemiddelde hoogst gemeten waardes per resource per proces over 100 metingen met variantie.
4.2
Algoritme Testen
Er is 10 keer een test uitgevoerd waarmee we beoordelen of het algoritme de resources van de videoserver tijdens het opnemen niet boven het maximum laat komen. We meten het resourcege-bruik tijdens het opnemen van 3 video’s van 1 minuut lang, met daartussen een vaste periode van 2 minuten waarin niet opgenomen wordt. Tijdens het opnemen worden 2 snapshots gemaakt, 1 na 15 seconden en 1 na 45 seconden. Na het opnemen van een video worden er 5 stukjes uit een video geknipt tussen de 30 en 120 seconden. Deze stukjes video worden samen met de snapshots naar de externe storageserver verplaatst. Na het verplaatsen van een bestand, wordt dit bestand verwijderd. Door op deze manier te testen bootsen we een verkorte dag in een OK na. Tijdens het verloop van de test meten we de belasting van de CPU, de harddisk en het werkgeheugen van de videoserver.
In figuur 4.1 is de CPU belasting weergegeven tijdens het verloop van een van de test. Er is een terugkerend patroon te zien. Een patroon van opnemen (het groen gemarkeerde deel van de gra-fiek) gevolgd door een periode waarin knip-, verplaats- en verwijderprocessen plaatsvinden. Dit patroon herhaalt zich 4 keer, waarbij na de 3e opname een langere periode plaatsvindt waarbij veel knipprocessen achter elkaar draaien. Dit is de periode waarin het algoritme weet dat er geen opnames gepland staan. Het algoritme start dan de knipprocessen die eerder niet gestart konden worden omdat ze zouden overlappen met een volgende opname.
In figuur 4.2 laten we de eerste opneem- en pauzecyclus zien. De lijn geeft de CPU belasting weer waarbij de kleuren aangeven welke processen er op dat moment actief zijn. Daarin is beter te zien dat na het opnemen 3 knipprocessen gestart worden met tussendoor een verplaats- of verwijderproces. We verwachten echter 5 pieken na het opnemen, we zouden namelijk 5 keer een knipproces starten. Om te testen of het algoritme de tijd die het kost om een proces af te ronden juist berekent, duren 2 van de 5 knipprocessen 60 seconden. De knipprocessen die niet voor de volgende opname klaar zijn worden na de laatste opname gestart, waarmee we de pieken na het 3e groene gedeelte in figuur 4.1 verklaren.
Figuur 4.1: CPU belasting gemeten tijdens het testen van het algoritme waarmee met kleur is aangegeven welke processen wanneer draaien.
Figuur 4.2: CPU belasting van de eerste opneem- en pauzecyclus uit 4.1. Ook hier is met kleur aangegeven welke processen wanneer draaien.
In figuur 4.3 wordt de hoeveelheid MB/s die gelezen of geschreven wordt tijdens de test weerge-geven. De waardes die getoond worden zijn het aantal MB/s dat gelezen wordt plus het aantal MB/s dat geschreven wordt op een moment. Opvallend is de piek tijdens een opname die plaats-vindt rond de 350 seconden. Deze piek verklaren we door het meten van een moment waarop een snapshot gemaakt wordt tijdens het opnemen. Het algoritme meet namelijk elke halve seconde de staat van de videoserver en kan deze pieken dus missen.
In figuur 4.4 is het aantal MB te zien dat is gealloceerd tijdens het testen van het algoritme. Zoals te zien in het figuur is de hoeveelheid werkgeheugen die gealloceerd wordt door de processen elke keer vergelijkbaar. Opvallend zijn de 2 piekjes die tijdens een opname plaatsvinden. Deze verklaren we door het maken van een snapshot.
Figuur 4.3: MB/s geschreven plus gelezen tijdens het testen van het algoritme. De maximale hoeveelheid MB/s dat tegelijkertijd gelezen en geschreven kan worden is 600MB/s
Figuur 4.4: Hoeveelheid gealloceerd werkgeheugen in MB tijdens de test van het algoritme. De maximale hoeveelheid werkgeheugen van de videoserver is vastgesteld op 30GB.
HOOFDSTUK 5
Conclusie
Zoals te zien in grafiek 4.1, 4.3 en 4.4 worden de processen zo geregeld dat de maxima van de resources niet overschreden worden. Ook is te zien dat tijdens een opname geen resources overbe-last raken door het starten van processen of door het te lang doorgaan van een proces waardoor deze overlapt met een opname. We concluderen dat het algoritme de processen kan schedulen, zodat geen van de resources overbelast raakt, met behulp van het model en de gemeten waardes die gebruikt worden in het model. De onderzoeksvraag van dit onderzoek luidde: Hoe regelen we de processen op de videoserver zodanig dat de resources van de videoserver niet overbelast raken en het opnemen van de video niet onderbroken wordt ? Het regelen van de processen op de videoserver zonder dat deze overbelast raakt, kan bereikt worden met de vergelijkingen uit het model. Het bepalen van de maximaal benodigde resources en de tijd die het kost om een proces af te ronden helpen het algoritme om het doel te behalen: een opname mag niet verloren gaan door het starten van andere processen.
5.1
Toekomst
Het algoritme gebruikt van tevoren gemeten waardes, te zien in tabel 4.1, met de formules van het model om de maximale belasting van de processen te bepalen. Het algoritme kan worden uitgebreid door de waardes die tijdens het schedulen van de processen worden gemeten te gebruiken bij het maken van beslissingen. Op deze manier kan nog nauwkeuriger bepaald worden of een proces gestart mag worden.
Het algoritme kan ook uitgebreid worden met meldingen naar de systeembeheerder van een ziekenhuis over de status van de videoserver. Met behulp van meldingen over bijvoorbeeld een constante hoge CPU belasting of de opslagcapaciteit van een harddisk kan een systeembeheerder voortijdig ingrijpen door de videoserver uit te rusten met vernieuwde hardware.
Verder onderzoek kan gedaan worden naar een mogelijkheid om meerdere capture cards op een videoserver te installeren. Er kan dan gekeken worden naar de belasting van de videoserver bij het opnemen van meerdere video’s tegelijkertijd om zo te bepalen of het mogelijk is om een videoserver voor meerdere OK’s te gebruiken.
Bibliografie
[1] A Klinger, GL de Lima, Valter Roesler, G Maron, G Longoni, V Goulart, FS dos Santos, MD Ferreira, and MB Mariano. A low cost digital operating room. In Proceedings of the 29th Annual ACM Symposium on Applied Computing, pages 36–37. ACM, 2014.
[2] Chipsoft, de organisatie. https://www.chipsoft.nl/organisatie. Geraadpleegd op: 20-06-2017.
[3] VisioForge video capture SDK .Net. https://www.visioforge.com/ video-capture-sdk-net2.html. Geraadpleegd op: 21-06-2017.
[4] Blackmagic Design Decklink Mini Recorder 4K. https://www.blackmagicdesign.com/ products/decklink/techspecs/W-DLK-33. Geraadpleegd op: 07-07-2017.
[5] Thomas Wiegand, Gary J Sullivan, Gisle Bjontegaard, and Ajay Luthra. Overview of the h. 264/avc video coding standard. volume 13, pages 560–576. IEEE, 2003.
[6] Saroj Choudhary and Purneshwari Varshney. A study of digital video compression techni-ques. volume 5, 2016.
[7] Vasudev Bhaskaran and Konstantinos Konstantinides. Image and video compression standards: algorithms and architectures, volume 408. Springer Science & Business Media, 1997.
[8] FFmpeg command line tools. http://ffmpeg.org/about.html. Geraadpleegd op: 21-06-2017.
[9] Microsoft developer network named pipes serverstream. https://msdn.microsoft.com/ en-us/library/system.io.pipes.namedpipeserverstream(v=vs.110).aspx. Geraad-pleegd op: 09-07-2017.
[10] Microsoft developer network performancecounter class. https://msdn.microsoft.com/ en-us/library/system.diagnostics.performancecounter(v=vs.110).aspx. Geraad-pleegd op: 26-06-2017.
[11] Microsoft developer network queue class. https://msdn.microsoft.com/en-us/library/ system.collections.queue(v=vs.110).aspx. Geraadpleegd op: 27-06-2017.
