V avtomatiziranem medicinskem centru se uporablja vrsta različnih naprav, katerih delo mora upravljati medicinska informacijska sistem (MIS), ter naprav, ki ne prejemajo ukazov, ampak morajo prenesti rezultate svojega dela v MIS. Vse naprave imajo različne možnosti povezave (USB, RS-232, Ethernet itd.) in načine interakcije. Podpirati vse v MIS je praktično nemogoče, zato je bila razvita programska plast DeviceManager (DM), ki za MIS nudi enoten vmesnik za postavljanje nalog napravam in pridobivanje rezultatov.
Za povečanje odpornosti sistema DM je bil razdeljen na niz programov, nameščenih na računalnikih v medicinskem centru. DM se deli na glavni program in niz pluginov, ki izvajajo interakcijo s specifično napravo in pošiljajo podatke v MIS. Na spodnji sliki je prikazana splošna struktura interakcije z DeviceManagerjem, MIS in napravami.
Na strukturi interakcije MIS z DeviceManagerjem so prikazani 3 načini delovanja pluginov:
- Plugin ne prejema nobenih podatkov iz MIS in pošilja podatke od naprave, ki so pretvorjeni v razumljiv format (ustreza napravi tipa 3 na zgornji sliki).
- Plugin prejme kratko (po času izvajanja) nalogo iz MIS, na primer tiskanje na tiskalniku ali skeniranje slike, jo izvrši in pošlje rezultat v odgovoru na zahtevo (ustreza napravi tipa 1 na zgornji sliki).
- Plugin prejme dolgo nalogo iz MIS, na primer izvesti preiskavo ali izmeriti kazalnike, v odgovor pošlje status sprejemanja naloge (postopek naloge se lahko zavrne v primeru napake v zahtevi). Po izvršitvi naloge se rezultati pretvorijo v razumljiv format za MIS in prenesejo v ustrezne vmesnike po svoji vrsti (ustreza napravi tipa 2 na zgornji sliki).
Glavni program DM zažene, inicializira, ponovni zažene v primeru nepričakovane zaustavitve (padca) in konča vse plugine ob zaključku dela. Sestava pluginov na vsakem računalniku je posebna, zagonijo se samo potrebni, ki so navedeni v nastavitvah.
Vsak vtičnik predstavlja samostojni program, ki sodeluje z glavno programsko opremo. Ta opredelitev vtičnika omogoča stabilnejše delovanje, zahvaljujoč neodvisnosti vseh primerkov vtičnikov in glavne aplikacije pri obravnavi napak (če se pojavi kritična napaka, zaradi katere vtičnik preneha delovati, to ne bo vplivalo na druge vtičnike in glavno aplikacijo). En vtičnik omogoča delo z napravami iste vrste (pogosto istega modela), pri tem pa lahko nekateri vtičniki komunicirajo le z enim napravo, drugi pa z več. Za povezovanje več naprav istega tipa z enim DM se uporablja zagon več primerkov enega vtičnika.
Za razvoj DM je bilo uporabljeno orodje Qt, ker omogoča v večini primerov abstraktno delovanje ne glede na konkretno operacijsko sistem. To je omogočilo podporo delovanju na računalnikih z operacijskimi sistemi Windows, Linux in MacOS ter enonaplatnikih Raspberry. Edina omejitev pri izbiri operacijskega sistema za razvoj vtičnikov je prisotnost gonilnikov in/ali posebne programske opreme za določeno napravo.
Interakcija med vtičniki in glavno aplikacijo poteka prek stalno aktivnega QLocalSocket z imenom konkretnega primerka vtičnika, po protokolu, ki smo ga zasnovali. Izvedba komunikacijskega protokola z obeh strani je bila realizirana v obliki dinamične knjižnice, kar je omogočilo, da so nekateri vtičniki razvijali druge družbe, ne da bi razkrili popolno interakcijo z glavno aplikacijo. Notranja logika delovanja lokalnega socketa omogoča glavni aplikaciji, da takoj izve za morebitno napako z uporabo signala o prekinitvi povezave. Ob aktivaciji tega signala se ponovno zažene problematični vtičnik, kar omogoča bolj neproblematično obravnavo kritičnih situacij.
Interakcijo med MIS in DM smo se odločili zgraditi na osnovi HTTP protokola, saj MIS deluje na osnovi spletnega strežnika, na katerem je lažje pošiljati in sprejemati zahteve po tem protokolu. Prav tako je mogoče razlikovati težave, ki so se lahko pojavile pri nalaganju ali izvajanju nalog naprav na podlagi odgovornih kod.
V naslednjih člankih bo na primeru več kabinetov diagnostičnega centra predstavljeno delovanje DM in nekaterih vtičnikov.
Izvor: habr.com
