Un centre médical automatisé utilise de nombreux appareils différents, dont le fonctionnement doit être contrôlé par un système d'information médicale (MIS), ainsi que des appareils qui n'acceptent pas de commandes, mais doivent transmettre les résultats de leur travail au MIS. Cependant, tous les appareils disposent d'options de connexion différentes (USB, RS-232, Ethernet, etc.) et de façons d'interagir avec eux. Il est presque impossible de tous les prendre en charge dans le MIS, c'est pourquoi la couche logicielle DeviceManager (DM) a été développée, qui fournit une interface unique au MIS pour attribuer des tâches aux appareils et obtenir des résultats.
Pour augmenter la tolérance aux pannes du système, DM a été divisé en un ensemble de programmes situés sur les ordinateurs du centre médical. DM est divisé en un programme principal et un ensemble de plugins qui interagissent avec un appareil spécifique et envoient des données au MIS. La figure ci-dessous montre une structure généralisée d'interaction avec DeviceManager, MIS et les appareils.
La structure d'interaction entre MIS et DeviceManager présente 3 options pour les plug-ins :
- Le plugin ne reçoit aucune donnée du MIS et envoie des données converties dans un format compréhensible depuis l'appareil (correspond à l'appareil de type 3 dans la figure ci-dessus).
- Le plugin reçoit une tâche courte (en termes de temps d'exécution) du MIS, par exemple imprimer sur une imprimante ou numériser une image, l'exécute et envoie le résultat en réponse à la requête (correspond au type d'appareil 1 dans la figure ci-dessus ).
- Le plugin reçoit une tâche à long terme du MIS, par exemple pour mener une enquête ou mesurer des indicateurs, et envoie en réponse le statut d'acceptation de la tâche (la tâche peut être refusée s'il y a une erreur dans la demande). Une fois la tâche terminée, les résultats sont convertis dans un format compréhensible pour le MIS et téléchargés sur les interfaces correspondant à leur type (correspond au type d'appareil 2 dans la figure ci-dessus).
Le programme DM principal démarre, initialise, redémarre en cas d'arrêt inattendu (plantage) et termine tous les plugins lors de l'arrêt. La composition des plugins sur chaque ordinateur est différente, seuls ceux nécessaires sont lancés, qui sont précisés dans les paramètres.
Chaque plugin est un programme indépendant qui interagit avec le programme principal. Cette définition d'un plugin permet un fonctionnement plus stable en raison de l'indépendance de toutes les instances du plugin et de la tête en termes de gestion des erreurs (si une erreur critique se produit et provoque le crash du plugin, cela n'affectera pas les autres plugins et la tête) . Un plugin vous permet de travailler avec des appareils d'un type (souvent le même modèle), tandis que certains plugins ne peuvent interagir qu'avec un seul appareil, tandis que d'autres peuvent interagir avec plusieurs. Pour connecter plusieurs appareils du même type à un seul DM, lancez plusieurs instances du même plugin.
La boîte à outils Qt a été utilisée pour développer DM car elle nous permet de nous éloigner d'un système d'exploitation spécifique dans la plupart des cas. Cela a permis de prendre en charge le travail avec des ordinateurs basés sur Windows, Linux et MacOS, ainsi que des appareils Raspberry à carte unique. La seule limitation dans le choix d'un système d'exploitation lors du développement de plugins est la disponibilité de pilotes et/ou de logiciels spéciaux pour un périphérique spécifique.
L'interaction entre les plugins et la tête se produit via un QLocalSocket constamment actif avec le nom d'une instance de plugin spécifique, selon le protocole que nous avons créé. La mise en œuvre du protocole de communication des deux côtés a été conçue comme une bibliothèque dynamique, qui a permis de développer certains plugins par d'autres sociétés sans révéler complètement l'interaction avec le responsable. La logique interne de la prise locale permet à la tête de connaître immédiatement la chute grâce à un signal de rupture de connexion. Lorsqu'un tel signal est déclenché, le plugin problématique est redémarré, ce qui vous permet de gérer les situations critiques plus facilement.
Il a été décidé de construire l'interaction entre MIS et DM sur la base du protocole HTTP, puisque MIS fonctionne sur un serveur Web, ce qui facilite l'envoi et la réception de requêtes via ce protocole. Il est également possible de distinguer les problèmes qui pourraient survenir lors de la configuration ou de l'exécution de tâches avec des appareils en fonction des codes de réponse.
Dans les articles suivants, à l'aide de l'exemple de plusieurs salles de centres de diagnostic, le fonctionnement du DM et de certains plug-ins sera examiné.
Source: habr.com