Un centru medical automatizat folosește multe dispozitive diferite, a căror funcționare trebuie să fie controlată de un sistem de informații medicale (MIS), precum și dispozitive care nu acceptă comenzi, dar trebuie să transmită rezultatele muncii lor către MIS. Cu toate acestea, toate dispozitivele au opțiuni de conectare diferite (USB, RS-232, Ethernet etc.) și modalități de a interacționa cu ele. Este aproape imposibil să le susținem pe toate în MIS, așa că a fost dezvoltat stratul software DeviceManager (DM), care oferă o singură interfață pentru MIS pentru atribuirea sarcinilor dispozitivelor și obținerea rezultatelor.
Pentru a crește toleranța la erori a sistemului, DM a fost împărțit într-un set de programe situate pe computerele din centrul medical. DM este împărțit într-un program principal și un set de plugin-uri care interacționează cu un anumit dispozitiv și trimit date către MIS. Figura de mai jos prezintă o structură generalizată de interacțiune cu DeviceManager, MIS și dispozitive.
Structura de interacțiune dintre MIS și DeviceManager arată 3 opțiuni pentru plug-in-uri:
- Pluginul nu primește date de la MIS și trimite date convertite într-un format pe care acesta îl înțeleg de pe dispozitiv (corespunde tipului de dispozitiv 3 din figura de mai sus).
- Pluginul primește o sarcină scurtă (în ceea ce privește timpul de execuție) de la MIS, de exemplu, imprimarea pe o imprimantă sau scanarea unei imagini, o execută și trimite rezultatul ca răspuns la cerere (corespunde tipului de dispozitiv 1 din figura de mai sus ).
- Pluginul primește o sarcină pe termen lung de la MIS, de exemplu, pentru a efectua un sondaj sau a măsura indicatorii și, ca răspuns, trimite starea de acceptare a sarcinii (sarcina poate fi refuzată dacă există o eroare în cerere). După finalizarea sarcinii, rezultatele sunt convertite într-un format ușor de înțeles pentru MIS și încărcate pe interfețele corespunzătoare tipului lor (corespunde tipului de dispozitiv 2 din figura de mai sus).
Programul DM principal pornește, inițializează, repornește în cazul unei opriri neașteptate (crash) și oprește toate pluginurile la oprire. Compoziția pluginurilor pe fiecare computer este diferită, sunt lansate doar cele necesare, care sunt specificate în setări.
Fiecare plugin este un program independent care interacționează cu programul principal. Această definiție a unui plugin permite o funcționare mai stabilă datorită independenței tuturor instanțelor de plugin și a capului în ceea ce privește gestionarea erorilor (dacă apare o eroare critică care provoacă blocarea pluginului, atunci aceasta nu va afecta alte plugin-uri și capul) . Un plugin vă permite să lucrați cu dispozitive de un tip (adesea același model), în timp ce unele plugin-uri pot interacționa doar cu un dispozitiv, în timp ce altele pot interacționa cu mai multe. Pentru a conecta mai multe dispozitive de același tip la un DM, lansați mai multe instanțe ale aceluiași plugin.
Setul de instrumente Qt a fost folosit pentru a dezvolta DM, deoarece ne permite să facem abstracție de la un anumit sistem de operare în majoritatea cazurilor. Acest lucru a făcut posibilă sprijinirea lucrului cu computere bazate pe Windows, Linux și MacOS, precum și cu dispozitive Raspberry cu o singură placă. Singura limitare în alegerea unui sistem de operare la dezvoltarea pluginurilor este disponibilitatea driverelor și/sau a software-ului special pentru un anumit dispozitiv.
Interacțiunea dintre pluginuri și head are loc printr-un QLocalSocket activ constant cu numele unei anumite instanțe de plugin, conform protocolului creat de noi. Implementarea protocolului de comunicare pe ambele părți a fost concepută ca o bibliotecă dinamică, ceea ce a făcut posibilă dezvoltarea unor plugin-uri de către alte companii fără a dezvălui complet interacțiunea cu șeful. Logica internă a prizei locale permite capului să învețe imediat despre cădere folosind un semnal de întrerupere a conexiunii. Când un astfel de semnal este declanșat, pluginul problematic este repornit, ceea ce vă permite să gestionați situațiile critice mai fără durere.
S-a decis construirea interacțiunii dintre MIS și DM pe baza protocolului HTTP, deoarece MIS funcționează pe un server Web, ceea ce facilitează trimiterea și primirea cererilor folosind acest protocol. De asemenea, este posibil să distingem problemele care ar putea apărea la stabilirea sau efectuarea sarcinilor cu dispozitive pe baza codurilor de răspuns.
În articolele următoare, folosind exemplul mai multor săli de centre de diagnostic, se va examina funcționarea DM și a unor plug-in-uri.
Sursa: www.habr.com