donderdag 2 februari 2012

(semi) Dynamische GUI

Ik had het idee om het dashboard zo flexibel mogelijk te maken, het moet dus mogelijk zijn om verschillende pagina's te maken om apparaten te groeperen op afdeling, type of locatie. Een hele dynamische gui is voor dit proof of concept misschien nog wat te ver gezien de beschikbare tijd. Maar een tussenweg moest toch te vinden zijn.

Ik denk dat ik die tussenweg heb gevonden, namelijk een soort van standaard layout waar de diverse items dynamisch aangepast kunnen worden. In de eerste eenvoudige opzet acht items en een label. Op de achtergrond heb ik een array met verschillende vensters (momenteel nog gevuld met slechts 1 venster) en ieder venster heeft maximaal 8 items met daarin de beschrijving, label naam, de modaliteit naam (om een apparaat te koppelen aan een item) en een eventuele actie omschrijving voor de button (het groene vinkje, rode kruis of geen verbinding symbool). Hiermee wordt het straks mogelijk om door te klikken naar een volgende pagina.

Daarnaast heb ik getest of meerdere agents contact kunnen maken met mijn Intersect Server, zoals te zien in onderstaand filmpje is dit gelukt.






donderdag 19 januari 2012

Intersect; een eerste pre-pre-pre-preview


Een eerste blik op hoe simpel een dashboard kan zijn.
De agent haalt gegevens op van het systeem en bewaakt het errorlog van mijn virtuele röntgenkamer. De gegevens worden verzonden en wanneer de errorlog wordt aangepast omdat er een fout wordt weggeschreven (dit simuleer ik met het venster linksonder) dan wordt er een melding richting de server gestuurd dat er een critical error is.

De server ontvangt de data en ziet dat het om een critical melding gaat, vervolgens wordt het vinkje een rood kruis. Door op het kruis te klikken wordt de status weer teruggezet naar het groene vinkje.

donderdag 12 januari 2012

Systeemdata => XML => TCP/IP => Server => XML

Weer een belangrijk stuk werkend, er wordt systeem informatie opgevraagd uit de client zoals bijvoorbeeld Windows Taakbeheer dit ook doet. De informatie wordt omgezet in een xml formaat en vervolgens via tcp/ip verstuurd naar een server welke de file weer verder verwerkt.
Dit wordt straks de basis voor de communicatie tussen de verschillende agents en de centrale server.


donderdag 5 januari 2012

SPAN(nend)

Omdat het communicatie protocol van de rontgenkamers niet openbaar is en het niet mogelijk is eventuele foutmeldingen ook naar een 2e adres te sturen ben ik genoodzaakt om het protocol te reverse engineeren, tenminste te proberen want als het om versleutelde data gaat kan dit een probleem worden.
De beste manier is om dus mee te luisteren met het netwerkverkeer, dit wordt vaak gedaan door een hub tussen pathpunt en apparaat te zetten waarop een systeem wordt aangesloten met daarop Wireshark.
Gelukkig gebruiken wij hier CISCO switches en deze hebben een vreselijk handige functie SPAN.
SPAN staat voor Switched Port Analyzer en is een manier om data te kopieren naar een andere poort zodat hier met behulp van een sniffer (Wireshark) de data geanalyseerd kan worden.


Door nu op de rontgenkamer fouten te genereren en de kamer opnieuw te starten zodat deze weer aangemeld wordt bij leverancier kan ik hopelijk gericht zoeken naar de gebruikte protocollen en deze dus reverse engineeren. Wanneer deze gegevens bekend zijn is het mogelijk om een eenvoudige sniffer te programmeren welke toegevoegd kan worden aan het project.
Het werkend krijgen van dit systeem zou heel erg mooi zijn aangezien dan alle foutmeldingen afgevangen kunnen worden.

Vandaag heb ik de de juiste pathpunten en switches gezocht en overleg gehad met collega's hoe ik dit het beste kan aanpakken. Gelukkig zijn er voldoende vrije poorten op de switches en worden deze ook niet al te zwaar belast zodat het gebruiken van SPAN geen performance problemen zou moeten veroorzaken.


dinsdag 3 januari 2012

Happy New Year!

Het nieuwe jaar is weer gestart, iedereen nog de beste wensen voor 2012.


Afgelopen week vakantie gehad en daardoor geen updates gedaan in dit blog, ondertussen wel het een en ander geprogrammeerd. Het project lijkt iets uit te gaan lopen onder andere doordat ik doormiddel van Wireshark het protocol moet gaan ontrafelen waarmee onze Röntgenkamers communiceren met de leverancier. Dit staat de komende weken op de planning, hiervoor moeten echter eerst nog wat instellingen aangepast worden op enkele switches zodat ik met een laptop of pc de lijn kan "afluisteren".


Op andere fronten gaat het gelukkig een stuk beter, ik heb al een aantal onderdelen voor de agent en server werkend en ook het binnenhalen van werklijsten met behulp van de Dicom Modality Worklist is mogelijk.
De afgelopen weken heb ik de volgende onderdelen werkend gekregen:



  • Email communicatie (server en client)
  • XML files maken, schrijven en lezen
  • Versturen van bovenstaande xml files (doormiddel van socketcommunicatie)
Neem daarbij nog de eerder functionerend gekregen onderdelen:

Windows service in c#
Hardware monitoring (van het werkstation / pc)

En de blokkendoos voor het Intersect begint al aardig compleet te worden. De grote uitdaging zal hem zitten in het samenvoegen van al deze onderdelen tot een stabiele windows service.

Om de agent compleet te krijgen moet ik de volgende zaken nog aanpakken:

  • Protocol communicatie Röntgenkamers met leverancier (dit om foutmeldingen af te kunnen vangen van deze kamers.
  • Logfile analyser
  • Netwerk ping en Dicom ping
Daarnaast moet ik nog starten aan de centrale server (samen met Edwin Kailuhu) en aan het dashboard voor de afdeling.



donderdag 15 december 2011

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







maandag 12 december 2011

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!