Sharktale deel I

Zoals eerder al verteld in dit blog moet ik om eventuele informatie uit modaliteiten te krijgen het netwerk verkeer gaan analyseren en dan proberen hier de meldingen uit the halen. Ik heb gekozen voor onze "interne" kamer en een van de bucky kamers. Alvast eerst toestemming gevraagd aan de afdeling zelf om dit te mogen gaan doen, was natuurlijk geen probleem.


Hoe ga ik het nu aanpakken, na overleg met een van mijn ict collega's (Paul Ket, bedankt voor de informatie) zijn we gekomen tot het volgende plan.


Ik zoek uit op welke switch de modaliteit(en) aangesloten zijn, vervolgens wordt gekeken of er nog een vrij poort is en daarna zetten we SPAN aan op de desbetreffende poorten. SPAN staat voor Switch Port Analyser en maakt het mogelijk om data van een bepaalde poort te kopiëren naar een andere poort. Daarna kan ik met Wireshark het netwerk verkeer monitoren en hopelijk de juiste boodschappen voorbij zien komen.


Daarnaast ben ik aan het kijken of er ook een mogelijkheid is om met behulp van emails foutmeldingen te kunnen ontvangen, er zijn in huis ook systemen die dit gebruiken. Bijvoorbeeld het programma Process Manager wat we gebruiken om onze endoscopen reinigers te kunnen monitoren.
In C# heb ik inmiddels een proef smtp server gemaakt waarmee ik eventuele emails zou kunnen ontvangen.


De komende tijd zal ook in het teken staan van het programmeren van de verschillende puzzelstukjes die straks het volledige programma zullen gaan vormen, denk hierbij aan de volgende onderdelen:

• SMTP server om emails te kunnen ontvangen
• XML parsen en generator voor de onderlinge communicatie
• Grafische module voor het tekenen van grafieken, meters etc.
• Logfile analyser om eventuele logfiles te kunnen inlezen en analyseren
• Systeem monitoring
• DICOM communicatie

Uitdaging of showstopper?

Afgelopen vrijdag een gesprek gehad met een van onze leveranciers over de mogelijkheden tot toegang op de systemen. Dit om eventueel een lokale agent te kunnen installeren en toegang te kunnen krijgen op logfiles en foutmeldingen.

Mijn verwachting was dat vooral het installeren van een agent op een systeem niet zomaar toegestaan wordt door de leverancier hetgeen ook het geval blijkt te zijn. Op zich geen verrassing want er zit natuurlijk wel een flink stuk aansprakelijkheid bij, installeren van een lokale agent is dus alleen mogelijk wanneer er een vrijwaringsverklaring ondertekend wordt zodat eventuele aansprakelijkheid niet meer bij de leverancier ligt. 

De modaliteiten sturen wel berichten naar een centrale server buiten het ziekenhuis zodat field engineers logfiles en de status van de apparatuur kunnen bekijken (men heeft dus ook een centrale monitoring op de apparatuur). Er kan geen kopie van deze berichten naar een eigen server gestuurd worden dus rest er niets anders dan met behulp van tools te gaan kijken of we deze berichten kunnen aftappen bij de modaliteit. Dat betekend dat ik met een tool als wireshark het verkeer van een modaliteit ga opnemen en daaruit deze boodschappen moet gaan filteren. Gelukkig is wel toegezegd dat ik logfiles vanuit de leverancier kan krijgen zodat ik deze naast mijn data kan leggen. Hopelijk zijn deze boodschappen niet extreem gecodeerd zodat lezen onmogelijk is.

Gelukkig kan ik wel gewoon verder met de ontwikkeling van een agent en zijn er zeker zaken die ik van buitenaf (dus zonder lokale agent) kan monitoren. Bovenstaande is dus vooral een uitdaging en absoluut geen showstopper!

Windows Services

Een goede monitor agent doet zijn werk op de achtergrond, vandaag onderzoek gedaan naar het implementeren van zo'n service. Als eerste opzet gekozen voor een service op basis van C# die de standaard systeem monitoring kan uitvoeren (geheugen, disks, processor etc).

In Visual Studio 2010 zit een template om al een basis te hebben om een dergelijke service te kunnen programmeren. Als test zal ik de service in een bepaalde interval gegevens laten schrijven in een log file.

Planning week 9

Inmiddels al weer week 9, de eisen en wensen zijn bekend en opgenomen in een beknopt RAD. Ik heb een kleine planning gemaakt met onderwerpen waar ik deze week aan wil gaan werken.

• System Design Document opzetten
• Globaal systeem ontwerpen (start reeds gemaakt vorige week)
• Inventariseren benodigde koppelingen en technologieën (Dicom. XML, SNMP)
• Brainstormen over de centrale server 

System Design en toegang tot de apparatuur

Om het project succesvol te maken moet ik gegevens uit de diverse apparaten op de afdeling Radiologie kunnen halen. Dit zijn semi gesloten systemen, we hebben we wat toegangsrechten maar niet volledig. Daarnaast kun je niet zomaar een stuk software op een dergelijk systeem installeren. Er zijn misschien ook nog wel andere minder invasieve oplossingen zoals berichten uitlezen, logfiles doorsturen.

Ik heb daarom ook contact opgenomen met een van onze leveranciers, Siemens. Op vrijdag 9 december heb ik een afspraak staan om eens samen te kijken wat de mogelijkheden zijn om data te kunnen vergaren uit de systemen.

Ondertussen gaat het systeem ontwerp natuurlijk gewoon door, ik wil ook een agent schrijven om gegevens van een systeem te halen. Er zijn binnen het ziekenhuis ook systemen waarop we wel software kunnen installeren, daarnaast bouwen we op deze manier een uitbreidbaar systeem. De agent kan altijd getest en gedemonstreerd worden op een simulator dus dat komt helemaal goed.

System Design I

Vandaag gestart met het system design, als eerste nagedacht over de agent die op de werkstations geïnstalleerd zou moeten worden. De opzet wordt zo universeel mogelijk zodat niet voor ieder apparaat een volledig nieuwe agent geschreven hoeft te worden. De data die verzameld wordt zal gerapporteerd worden door een xml file richting de centrale server te sturen. 

Ook al even zitten stoeien met system monitoring in c#, hiermee kan ik het onderdeel systemmonitor gaan maken en op deze manier netwerk, processor, geheugen en opslagmedia gaan monitoren.

Het Requirements Analysis Document II

Het RAD is klaar, in tegenstelling tot een RAD uit een UML traject is dit een heel klein document geworden.
Dus geen pagina's vol met usecases, sequence diagrammen en klassendiagram. Waarschijnlijk voeg ik het RAD samen met het SDD (System Design Document) tot een gezamenlijk document. Een groot deel zal ook terug te vinden zijn in het eindverslag.
De klanteisen zijn duidelijk, het is duidelijk wat het systeem moet doen dus kan ik nu starten met het systeemdesign. Voor specifieke gevallen zal ik gebruik maken van sequence diagrammen (met name voor het communicatie onderdeel). Het klassendiagram zoals normaal te vinden is in het RAD zal een plek vinden in het SDD.