In einem automatisierten medizinischen Zentrum kommen viele verschiedene Geräte zum Einsatz, deren Betrieb von einem medizinischen Informationssystem (MIS) gesteuert werden muss, sowie Geräte, die keine Befehle entgegennehmen, sondern die Ergebnisse ihrer Arbeit an das MIS übermitteln müssen. Allerdings verfügen alle Geräte über unterschiedliche Anschlussmöglichkeiten (USB, RS-232, Ethernet usw.) und Möglichkeiten, mit ihnen zu interagieren. Da es fast unmöglich ist, sie alle im MIS zu unterstützen, wurde die Softwareschicht DeviceManager (DM) entwickelt, die eine einzige Schnittstelle für das MIS zur Zuweisung von Aufgaben zu Geräten und zum Erhalten von Ergebnissen bereitstellt.
Um die Fehlertoleranz des Systems zu erhöhen, wurde DM in eine Reihe von Programmen aufgeteilt, die sich auf Computern im medizinischen Zentrum befanden. DM ist in ein Hauptprogramm und eine Reihe von Plugins unterteilt, die mit einem bestimmten Gerät interagieren und Daten an das MIS senden. Die folgende Abbildung zeigt eine verallgemeinerte Struktur der Interaktion mit DeviceManager, MIS und Geräten.
Die Struktur der Interaktion zwischen MIS und DeviceManager zeigt 3 Optionen für Plug-Ins:
- Das Plugin empfängt keine Daten vom MIS und sendet die in ein für ihn verständliches Format konvertierten Daten vom Gerät (entspricht Gerätetyp 3 in der Abbildung oben).
- Das Plugin empfängt vom MIS eine kurze (von der Ausführungszeit her) Aufgabe, beispielsweise das Drucken auf einem Drucker oder das Scannen eines Bildes, führt diese aus und sendet das Ergebnis als Antwort auf die Anfrage (entspricht Gerätetyp 1 in der Abbildung oben). ).
- Das Plugin erhält vom MIS eine langfristige Aufgabe, beispielsweise die Durchführung einer Umfrage oder die Messung von Indikatoren, und sendet als Antwort den Status der Aufgabenannahme (die Aufgabe kann abgelehnt werden, wenn in der Anfrage ein Fehler vorliegt). Nach Abschluss der Aufgabe werden die Ergebnisse in ein für das MIS verständliches Format umgewandelt und auf die ihrem Typ entsprechenden Schnittstellen hochgeladen (entspricht Gerätetyp 2 in der Abbildung oben).
Das Haupt-DM-Programm startet, initialisiert, startet im Falle eines unerwarteten Stopps (Absturzes) neu und beendet beim Herunterfahren alle Plugins. Die Zusammensetzung der Plugins ist auf jedem Computer unterschiedlich; es werden nur die notwendigen Plugins gestartet, die in den Einstellungen festgelegt sind.
Jedes Plugin ist ein unabhängiges Programm, das mit dem Hauptprogramm interagiert. Diese Definition eines Plugins ermöglicht einen stabileren Betrieb aufgrund der Unabhängigkeit aller Plugin-Instanzen und des Heads hinsichtlich der Fehlerbehandlung (wenn ein kritischer Fehler auftritt, der zum Absturz des Plugins führt, hat dies keine Auswirkungen auf andere Plugins und den Head). . Mit einem Plugin können Sie mit Geräten eines Typs (oft desselben Modells) arbeiten, während einige Plugins nur mit einem Gerät interagieren können, während andere mit mehreren interagieren können. Um mehrere Geräte desselben Typs mit einem DM zu verbinden, starten Sie mehrere Instanzen desselben Plugins.
Für die Entwicklung von DM wurde das Qt-Toolkit verwendet, da es uns in den meisten Fällen ermöglicht, von einem bestimmten Betriebssystem abzustrahieren. Dadurch war es möglich, die Arbeit mit Computern auf Basis von Windows, Linux und MacOS sowie Raspberry-Single-Board-Geräten zu unterstützen. Die einzige Einschränkung bei der Auswahl eines Betriebssystems bei der Entwicklung von Plugins ist die Verfügbarkeit von Treibern und/oder spezieller Software für ein bestimmtes Gerät.
Die Interaktion zwischen Plugins und dem Head erfolgt über einen ständig aktiven QLocalSocket mit dem Namen einer bestimmten Plugin-Instanz, gemäß dem von uns erstellten Protokoll. Die Implementierung des Kommunikationsprotokolls auf beiden Seiten wurde als dynamische Bibliothek konzipiert, die es ermöglichte, einige Plugins anderer Unternehmen zu entwickeln, ohne die Interaktion mit dem Kopf vollständig offenzulegen. Die interne Logik des lokalen Sockets ermöglicht es dem Kopf, mithilfe eines Verbindungsunterbrechungssignals sofort vom Sturz zu erfahren. Wenn ein solches Signal ausgelöst wird, wird das problematische Plugin neu gestartet, wodurch Sie kritische Situationen schmerzloser bewältigen können.
Es wurde beschlossen, die Interaktion zwischen MIS und DM auf Basis des HTTP-Protokolls aufzubauen, da MIS auf einem Webserver läuft, was das Senden und Empfangen von Anfragen über dieses Protokoll erleichtert. Es ist auch möglich, anhand von Antwortcodes Probleme zu unterscheiden, die beim Einstellen oder Ausführen von Aufgaben mit Geräten auftreten können.
In den folgenden Artikeln wird am Beispiel mehrerer Diagnosezentrumsräume die Funktionsweise von DM und einigen Plug-Ins untersucht.
Source: habr.com