Gerätemanager. MIS auf Geräte verlängern

In einem automatisierten medizinischen Zentrum werden viele verschiedene Geräte eingesetzt, deren Betrieb durch ein medizinisches Informationssystem (MIS) gesteuert werden muss, sowie Geräte, die keine Befehle entgegennehmen, aber die Ergebnisse ihrer Arbeit an das MIS übertragen sollen. Alle Geräte haben jedoch unterschiedliche Anschlussmöglichkeiten (USB, RS-232, Ethernet usw.) und Wege der Interaktion. Sie alle im MIS zu unterstützen, ist praktisch unmöglich, weshalb eine Software-User-Interface-Software namens DeviceManager (DM) entwickelt wurde, die dem MIS eine einheitliche Schnittstelle für die Auftragsvergabe an die Geräte und den Erhalt von Ergebnissen bietet.


Um die Fehlertoleranz des Systems zu erhöhen, wurde DM in eine Reihe von Programmen unterteilt, die auf Computern im medizinischen Zentrum installiert sind. DM besteht aus einem Hauptprogramm und einer Reihe von Plugins, die die Interaktion mit bestimmten Geräten ermöglichen und Daten an das MIS übermitteln. Die untenstehende Abbildung zeigt die allgemeine Struktur der Interaktion zwischen DeviceManager, MIS und Geräten.

Die Struktur der Interaktion zwischen dem MIS und DeviceManager zeigt 3 Varianten der Plugin-Arbeit:

1. Das Plugin erhält keine Daten vom MIS und überträgt die vom Gerät in ein für es verständliches Format umgewandelten Daten (entspricht Gerätetyp 3 in der obigen Abbildung).
2. Das Plugin erhält vom MIS eine kurze (zeitlich begrenzte) Aufgabe, z.B. Drucken auf dem Drucker oder Scannen eines Bildes, führt diese aus und sendet das Ergebnis als Antwort auf die Anfrage zurück (entspricht Gerätetyp 1 in der obigen Abbildung).
3. Das Plugin erhält vom MIS eine langfristige Aufgabe, z.B. eine Untersuchung durchzuführen oder Messwerte zu erfassen, und sendet danach den Status der Auftragsannahme zurück (bei einem Fehler in der Anfrage kann die Auftragsannahme verweigert werden). Nach Abschluss der Aufgabe werden die Ergebnisse in ein für das MIS verständliches Format umgewandelt und in die entsprechenden Schnittstellen ihres Typs hochgeladen (entspricht Gerätetyp 2 in der obigen Abbildung).

Das Hauptprogramm DM startet, initialisiert, setzt bei unvorhergesehenem Stopp (Absturz) neu und schließt alle Plugins bei Beendigung der Arbeit. Die Zusammensetzung der Plugins auf jedem Computer ist unterschiedlich; es werden nur die notwendigen Plugins gestartet, die in den Einstellungen angegeben sind.

Jedes Plugin stellt ein eigenständiges Programm dar, das mit dem Hauptprogramm interagiert. Diese Definition eines Plugins ermöglicht eine stabilere Funktionalität, da alle Instanzen der Plugins und des Hauptprogramms unabhängig von der Fehlerverarbeitung sind (wenn ein kritischer Fehler auftritt, der dazu führt, dass ein Plugin ausfällt, hat dies keine Auswirkungen auf andere Plugins und das Hauptprogramm). Ein Plugin ermöglicht die Verwaltung von Geräten eines bestimmten Typs (oft eines Modells), wobei einige Plugins nur mit einem bestimmten Gerät interagieren können, während andere mit mehreren interagieren können. Um mehrere Geräte desselben Typs mit einem DM zu verbinden, wird die Ausführung mehrerer Instanzen eines Plugins verwendet.

Für die Entwicklung von DM wurde das Qt-Framework verwendet, da es in den meisten Fällen ermöglicht, sich von einem bestimmten Betriebssystem zu abstrahieren. Dies erlaubte die Unterstützung von Computern auf Basis von Windows, Linux und MacOS sowie von Einplatinencomputern wie Raspberry. Die einzige Einschränkung bei der Auswahl des Betriebssystems bei der Entwicklung von Plugins liegt in der Verfügbarkeit von Treibern und/oder spezieller Software für ein bestimmtes Gerät.

Die Interaktion zwischen Plugins und dem Hauptprogramm erfolgt über einen permanent aktiven QLocalSocket mit dem Namen der spezifischen Plugin-Instanz, basierend auf dem von uns entwickelten Protokoll. Die Implementierung des Kommunikationsprotokolls auf beiden Seiten wurde als dynamische Bibliothek gestaltet, was es anderen Unternehmen ermöglichte, an der Entwicklung einiger Plugins zu arbeiten, ohne die vollständige Interaktion mit dem Hauptprogramm offenzulegen. Die interne Logik des lokalen Sockets ermöglicht es dem Hauptprogramm, sofort über einen Verbindungsabbruchsignal über einen Ausfall informiert zu werden. Bei Auslösung eines solchen Signals wird das problematische Plugin neu gestartet, was eine effektivere Handhabung kritischer Situationen ermöglicht.

Die Interaktion zwischen dem MIS und dem DM wurde auf der Grundlage des HTTP-Protokolls realisiert, da das MIS auf einem Webserver, der es erleichtert, Anfragen über dieses Protokoll zu senden und zu empfangen. Außerdem gibt es die Möglichkeit, Probleme zu unterscheiden, die beim Anlegen oder Ausführen von Aufgaben durch Geräte basierend auf Antwortcodes auftreten konnten.

In den nächsten Artikeln wird die Funktionsweise des DM und einiger Plugins anhand mehrerer Büros eines Diagnostikzentrums betrachtet.

Quelle: habr.com