Geräte-Manager. Verlängern Sie das MDM für Geräte

In einem automatisierten medizinischen Zentrum kommen vielfältige Geräte zum Einsatz, die von einem medizinischen Informationssystem (MIS) gesteuert werden müssen, sowie Geräte, die keine Befehle empfangen, aber ihre Ergebnisse an das MIS übermitteln sollen. Alle Geräte besitzen jedoch unterschiedliche Anschlussmöglichkeiten (USB, RS-232, Ethernet usw.) und Interaktionsmethoden. Es ist nahezu unmöglich, alle in das MIS zu integrieren, daher wurde die Software-Schicht DeviceManager (DM) entwickelt, die dem MIS eine einheitliche Schnittstelle zur Verfügung stellt, um Aufgaben an die Geräte zu übermitteln und Ergebnisse zu empfangen.


Zur Erhöhung der Ausfallsicherheit wurde das DM-System in eine Reihe von Programmen unterteilt, die auf Computern im medizinischen Zentrum platziert sind. DM besteht aus einer Hauptanwendung und einer Reihe von Plugins, die die Interaktion mit einem bestimmten Gerät ermöglichen und Daten an das MIS übermitteln. Die folgende Abbildung zeigt die allgemeine Struktur der Interaktion zwischen DeviceManager, MIS und Geräten.

In der Struktur der Interaktion zwischen MIS und DeviceManager werden 3 Betriebsvarianten der Plugins dargestellt:

1. Das Plugin erhält keine Daten von der MIS und sendet die in ein für sie verständliches Format umgewandelten Daten vom Gerät (entspricht Gerätetyp 3 im obigen Bild).
2. Das Plugin erhält von der MIS eine kurze (in Bezug auf die Ausführungszeit) Aufgabe, wie z. B. Drucken oder Scannen eines Bildes, führt diese aus und sendet das Ergebnis als Antwort auf die Anfrage zurück (entspricht Gerätetyp 1 im obigen Bild).
3. Das Plugin erhält von der MIS eine langfristige Aufgabe, wie z. B. eine Untersuchung durchzuführen oder Messwerte zu sammeln, und sendet im Antwortstatus die Bestätigung des Erhalts der Aufgabe (die Auftragsvergabe kann bei einem Fehler in der Anfrage abgelehnt werden). Nach Abschluss der Aufgabe werden die Ergebnisse in ein für die MIS verständliches Format umgewandelt und in die entsprechenden Schnittstellen ihres Typs exportiert (entspricht Gerätetyp 2 im obigen Bild).

Das Hauptprogramm DM startet, initialisiert, startet die Plugins neu im Falle eines unerwarteten Stopps (Absturzes) und beendet sie, wenn die Ausführung abgeschlossen ist. Die Zusammensetzung der Plugins ist auf jedem Computer unterschiedlich, es werden nur die notwendigen Plugins gestartet, die in den Einstellungen angegeben sind.

Jedes Plugin ist ein eigenständiges Programm, das mit der Hauptanwendung interagiert. Diese Definition des Plugins sorgt für eine stabilere Leistung, da alle Plugin-Instanzen und die Hauptanwendung unabhängig in Bezug auf Fehlerverarbeitung agieren (wenn ein kritischer Fehler auftritt und ein Plugin ausfällt, hat das keine Auswirkungen auf die anderen Plugins oder die Hauptanwendung). Ein Plugin ermöglicht die Arbeit mit Geräten eines bestimmten Typs (häufig eines Modells); einige Plugins können nur mit einem Gerät interagieren, während andere mit mehreren arbeiten können. Um mehrere Geräte desselben Typs an einen DM anzuschließen, müssen mehrere Instanzen desselben Plugins gestartet werden.

Für die Entwicklung des DM wurde das Qt-Framework verwendet, da es in den meisten Fällen eine Abstraktion von der spezifischen Betriebssystemumgebung ermöglicht. Dies erlaubte die Unterstützung von Computern mit Windows, Linux und MacOS sowie von Raspberry Pi. Die einzige Einschränkung bei der Auswahl des Betriebssystems für die Entwicklung der Plugins besteht in der Verfügbarkeit von Treibern und/oder spezieller Software für das jeweilige Gerät.

Die Interaktion zwischen den Plugins und dem Hauptsystem erfolgt über einen ständig aktiven QLocalSocket, der den spezifischen Plugin-Instanznamen trägt, gemäß unserem festgelegten Protokoll. Die Implementierung des Kommunikationsprotokolls auf beiden Seiten wurde in Form einer dynamischen Bibliothek realisiert, die es anderen Unternehmen ermöglicht, einige Plugins zu entwickeln, ohne die vollständige Interaktion mit dem Hauptsystem preiszugeben. Die interne Logik des lokalen Sockets informiert das Hauptsystem sofort über einen Ausfall durch ein Verbindungssignal. Bei Auslösung eines solchen Signals wird das fehlerhafte Plugin neu gestartet, was eine schmerzlose Handhabung von kritischen Situationen ermöglicht.

Die Interaktion zwischen dem MCS und DM wurde auf Basis des HTTP-Protokolls gestaltet, da das MCS auf einem Webserverbetrieben wird, auf dem es einfacher ist, Anfragen über dieses Protokoll zu senden und zu empfangen. Zudem ist es möglich, Probleme zu unterscheiden, die bei der Bereitstellung oder Ausführung von Aufgaben durch Geräte auf Grundlage der Antwortcodes auftreten könnten.

In den folgenden Artikeln wird an Hand mehrerer Stationen des Diagnosencenters die Funktionsweise von DM und einiger Plugins behandelt.

Quelle: habr.com