Gestionnaire de périphériques. Prolonger la MISE à jour des appareils

Un centre médical automatisé utilise de nombreux appareils différents, dont le fonctionnement doit être géré par un système d'information médicale (SIM), ainsi que des dispositifs qui ne reçoivent pas d'instructions, mais doivent transmettre les résultats de leur travail au SIM. Cependant, tous les appareils disposent de différentes options de connexion (USB, RS-232, Ethernet, etc.) et de modes d'interaction. Les prendre tous en charge dans le SIM est pratiquement impossible, c'est pourquoi une couche logicielle appelée DeviceManager (DM) a été développée, offrant au SIM une interface unique pour donner des tâches aux appareils et recevoir les résultats.


Pour augmenter la résilience du système DM, il a été divisé en un ensemble de programmes hébergés sur des ordinateurs dans le centre médical. DM se divise en un programme principal et un ensemble de plugins qui interagissent avec un appareil spécifique et envoient des données au SIM. La structure générale de l'interaction avec DeviceManager, le SIM et les appareils est représentée dans l'image ci-dessous.

La structure d'interaction entre le SIM et DeviceManager présente 3 modes de fonctionnement des plugins :

1. Le plugin ne reçoit aucune donnée du SIM et envoie des données, converties dans un format compréhensible pour lui, provenant de l'appareil (correspond à l'appareil de type 3 sur l'image ci-dessus).
2. Le plugin reçoit du SIM une tâche courte (en termes de temps d'exécution), par exemple, imprimer sur une imprimante ou scanner une image, l'exécute et envoie le résultat en réponse à la demande (correspond à l'appareil de type 1 sur l'image ci-dessus).
3. Le plugin reçoit du SIM une tâche longue, par exemple, effectuer un examen ou mesurer des indicateurs, et renvoie le statut d'acceptation de la tâche (la demande peut être refusée en cas d'erreur dans la demande). Après l'exécution de la tâche, les résultats sont convertis dans un format compréhensible pour le SIM et téléchargés dans les interfaces correspondant à leur type (correspond à l'appareil de type 2 sur l'image ci-dessus).

Le programme principal de DM lance, initiale, redémarre en cas d'arrêt imprévu (plantage) et termine tous les plugins à la fin du travail. La composition des plugins sur chaque ordinateur est unique, seuls ceux indiqués dans les paramètres sont lancés.

Chaque plugin est un programme autonome qui interagit avec le programme principal. Cette définition du plugin permet d'assurer un fonctionnement plus stable grâce à l'indépendance de toutes les instances de plugins et du programme principal en termes de gestion des erreurs (si une erreur critique survient et fait planter un plugin, cela n'a pas d'impact sur les autres plugins ou sur le programme principal). Un plugin permet de travailler avec des appareils d'un même type (souvent d'un même modèle), tandis que certains plugins peuvent interagir seulement avec un appareil, et d'autres avec plusieurs. Pour connecter plusieurs appareils d'un même type à un seul DM, plusieurs instances d'un même plugin doivent être lancées.

Pour le développement du DM, l'outil Qt a été utilisé, car il permet dans la plupart des cas de s'abstraire du système d'exploitation spécifique. Cela a permis de prendre en charge le fonctionnement avec des ordinateurs fonctionnant sous Windows, Linux et MacOS, ainsi que des cartes Raspberry. La seule restriction dans le choix du système d'exploitation lors du développement des plugins est la disponibilité des pilotes et/ou des logiciels spéciaux pour un appareil donné.

L'interaction entre les plugins et le programme principal se fait via un QLocalSocket toujours actif, portant le nom de l'instance spécifique du plugin, selon le protocole que nous avons établi. La mise en œuvre du protocole de communication des deux côtés a été réalisée sous la forme d'une bibliothèque dynamique, ce qui a permis à d'autres entreprises de développer certains plugins sans révéler complètement l'interaction avec le programme principal. La logique interne du fonctionnement du socket local permet au programme principal d'être immédiatement informé d'un plantage grâce à un signal de rupture de connexion. Lorsqu'un tel signal est émis, le plugin problématique est redémarré, ce qui permet de gérer de manière plus douce les situations critiques.

L'interaction entre le MIS et le DM a été décidée de se baser sur le protocole HTTP, car le MIS fonctionne sur la base Serveurs Web, qui facilite l'envoi et la réception de requêtes via ce protocole. Il est également possible de distinguer les problèmes qui peuvent survenir lors de la mise en place ou de l'exécution des tâches par les appareils en fonction des codes de réponse.

Dans les prochains articles, le fonctionnement du DM et de certains plugins sera examiné à travers plusieurs cabinets d'un centre de diagnostic.

Source : habr.com