În centrul medical automatizat sunt utilizate numeroase dispozitive diferite, ale căror funcționare trebuie gestionată de un sistem informațional medical (SIM), precum și dispozitive care nu primesc comenzi, dar trebuie să transmită rezultatele muncii lor către SIM. Cu toate acestea, toate dispozitivele au diferite opțiuni de conectare (USB, RS-232, Ethernet etc.) și modalități de interacțiune cu acestea. Susținerea tuturor acestora în SIM este practic imposibilă, de aceea a fost dezvoltat un strat software numit DeviceManager (DM), care oferă pentru SIM o interfață unică pentru a trimite comenzi dispozitivelor și a primi rezultate.
Pentru a crește reziliența sistemului DM a fost împărțit într-un set de programe, plasate pe computere în centrul medical. DM este format dintr-un program principal și un set de plugin-uri, care efectuează interacțiunea cu dispozitive specifice și trimit date către SIM. În figura de mai jos este prezentată structura generală a interacțiunii cu DeviceManager, SIM și dispozitive.
În structura de interacțiune a SIM cu DeviceManager sunt prezentate 3 variante de lucru ale plugin-urilor:
- Plugin-ul nu primește date de la SIM și trimite datele transformate într-un format inteligibil pentru acesta de la dispozitiv (corespunzător dispozitivului de tip 3 din figura de mai sus).
- Plugin-ul primește de la SIM o sarcină scurtă (din punct de vedere al timpului de execuție), de exemplu, imprimarea pe printer sau scanarea unei imagini, o execută și trimite rezultatul ca răspuns la cerere (corespunzător dispozitivului de tip 1 din figura de mai sus).
- Plugin-ul primește de la SIM o sarcină de lungă durată, de exemplu, efectuarea unui examen sau măsurarea indicatorilor, trimite în răspuns statutul acceptării sarcinii (acceptarea sarcinii poate fi refuzată în cazul unei erori în cerere). După finalizarea sarcinii, rezultatele sunt transformate într-un format inteligibil pentru SIM și sunt descărcate în interfețele corespunzătoare tipului lor (corespunzător dispozitivului de tip 2 din figura de mai sus).
Programul principal DM lansează, inițializează, repornește în cazul unei opriri neprevăzute (defecțiuni) și încheie toate plugin-urile la finalizarea funcționării. Componența plugin-urilor de pe fiecare computer este specifică, se lansează numai cele necesare, care sunt specificate în setări.
Fiecare plugin este o aplicație autonomă care interacționează cu programul principal. Această definiție a pluginului permite o funcționare mai stabilă, datorită independenței tuturor instanțelor de pluginuri și a programului principal în gestionarea erorilor (dacă apare o eroare critică care determină căderea unui plugin, celelalte pluginuri și programul principal nu vor fi afectate). Un plugin permite lucrul cu dispozitive de același tip (adesea de același model), iar unele pluginuri pot interacționa doar cu un singur aparat, în timp ce altele pot lucra cu mai multe. Pentru a conecta mai multe dispozitive de același tip la un DM, se folosește lansarea mai multor instanțe ale aceluiași plugin.
Pentru dezvoltarea DM s-a folosit instrumentul Qt, deoarece acesta permite, în cele mai multe cazuri, să se abstreze de la un sistem de operare specific. Acest lucru a permis suportul pentru computerele care rulează pe Windows, Linux și MacOS, dar și pentru plăci de dezvoltare Raspberry. Singura restricție în alegerea sistemului de operare pentru dezvoltarea pluginurilor este disponibilitatea driverelor și/sau a software-ului special pentru dispozitivul specific.
Interacțiunea dintre pluginuri și programul principal se desfășoară printr-un QLocalSocket activ constant, numit după instanța specifică a pluginului, conform protocolului creat de noi. Implementarea protocolului de comunicare din ambele părți a fost realizată sub formă de bibliotecă dinamică, ceea ce a permis altor companii să dezvolte unele pluginuri fără a dezvălui complet interacțiunea cu programul principal. Logica internă de funcționare a socket-ului local permite programului principal să afle imediat despre o cădere printr-un semnal de întrerupere a conexiunii. Atunci când se activează un astfel de semnal, pluginul problematic este repornit, ceea ce permite o gestionare mai ușoară a situațiilor critice.
Interacțiunea între MCI și DM a fost decisă să fie construită pe baza protocolului HTTP, deoarece MCI funcționează pe baza serverului web, ceea ce face mai ușor să trimiți și să primești solicitări prin acest protocol. De asemenea, există posibilitatea de a distinge problemele care ar putea apărea la stabilirea sau executarea sarcinilor de către aparate pe baza codurilor de răspuns.
În articolele următoare, vor fi analizate funcționarea DM și a unor pluginuri prin exemplul mai multor cabinete de diagnosticare.
Sursa: habr.com
