Un centro medico automatizzato utilizza molti dispositivi diversi, il cui funzionamento deve essere controllato da un sistema di informazione medica (MIS), nonché dispositivi che non accettano comandi, ma devono trasmettere i risultati del loro lavoro al MIS. Tuttavia, tutti i dispositivi hanno diverse opzioni di connessione (USB, RS-232, Ethernet, ecc.) e modi per interagire con essi. È quasi impossibile supportarli tutti nel MIS, quindi è stato sviluppato il livello software DeviceManager (DM), che fornisce un'unica interfaccia per il MIS per assegnare attività ai dispositivi e ottenere risultati.
Per aumentare la tolleranza agli errori del sistema, DM è stato suddiviso in una serie di programmi posizionati sui computer del centro medico. DM è suddiviso in un programma principale e un insieme di plugin che interagiscono con un dispositivo specifico e inviano dati al MIS. La figura seguente mostra una struttura generalizzata di interazione con DeviceManager, MIS e dispositivi.
La struttura di interazione tra MIS e DeviceManager mostra 3 opzioni per i plug-in:
- Il plugin non riceve dati dal MIS e invia i dati convertiti in un formato comprensibile dal dispositivo (corrisponde al tipo di dispositivo 3 nella figura sopra).
- Il plugin riceve un compito breve (in termini di tempo di esecuzione) dal MIS, ad esempio, stampare su una stampante o scansionare un'immagine, lo esegue e invia il risultato in risposta alla richiesta (corrisponde al tipo di dispositivo 1 nella figura sopra ).
- Il plugin riceve un compito a lungo termine dal MIS, ad esempio per condurre un sondaggio o misurare degli indicatori, e in risposta invia lo stato di accettazione del compito (il compito può essere rifiutato se c'è un errore nella richiesta). Dopo aver completato l'attività, i risultati vengono convertiti in un formato comprensibile per il MIS e caricati sulle interfacce corrispondenti al loro tipo (corrisponde al tipo di dispositivo 2 nella figura sopra).
Il programma DM principale si avvia, inizializza, riavvia in caso di arresto imprevisto (crash) e termina tutti i plugin allo spegnimento. La composizione dei plugin su ciascun computer è diversa, vengono avviati solo quelli necessari, specificati nelle impostazioni.
Ogni plugin è un programma indipendente che interagisce con il programma principale. Questa definizione di plugin consente un funzionamento più stabile grazie all'indipendenza di tutte le istanze del plugin e dell'head in termini di gestione degli errori (se si verifica un errore critico che causa il crash del plugin, ciò non influirà sugli altri plugin e sull'head) . Un plugin ti consente di lavorare con dispositivi di un tipo (spesso lo stesso modello), mentre alcuni plugin possono interagire solo con un dispositivo, mentre altri possono interagire con diversi. Per connettere più dispositivi dello stesso tipo a un DM, avviare più istanze dello stesso plug-in.
Il toolkit Qt è stato utilizzato per sviluppare DM perché nella maggior parte dei casi ci consente di astrarre da un sistema operativo specifico. Ciò ha permesso di supportare il lavoro con computer basati su Windows, Linux e MacOS, nonché con dispositivi a scheda singola Raspberry. L'unica limitazione nella scelta del sistema operativo durante lo sviluppo dei plugin è la disponibilità di driver e/o software speciali per un dispositivo specifico.
L'interazione tra i plugin e l'head avviene tramite un QLocalSocket costantemente attivo con il nome di una specifica istanza del plugin, secondo il protocollo da noi creato. L'implementazione del protocollo di comunicazione su entrambi i lati è stata concepita come una libreria dinamica, che ha permesso di sviluppare alcuni plugin di altre aziende senza rivelare completamente l'interazione con il capo. La logica interna della presa locale consente al capo di apprendere immediatamente la caduta tramite un segnale di interruzione della connessione. Quando viene attivato un segnale di questo tipo, il plugin problematico viene riavviato, il che consente di gestire le situazioni critiche in modo più indolore.
Si è deciso di costruire l'interazione tra MIS e DM sulla base del protocollo HTTP, poiché MIS opera su un server Web, il che rende più semplice inviare e ricevere richieste utilizzando questo protocollo. È anche possibile distinguere i problemi che potrebbero sorgere durante l'impostazione o l'esecuzione di attività con i dispositivi in base ai codici di risposta.
Nei seguenti articoli, utilizzando l'esempio di alcune sale di un centro diagnostico, verrà esaminato il funzionamento di DM e di alcuni plug-in.
Fonte: habr.com