W zautomatyzowanym centrum medycznym korzysta się z wielu różnych urządzeń, których działaniem powinien zarządzać system informacyjny dla medycyny (MIS), a także z urządzeń, które nie przyjmują poleceń, ale muszą przekazywać wyniki swojej pracy do MIS. Jednak wszystkie urządzenia mają różne opcje połączenia (USB, RS-232, Ethernet itp.) i sposoby interakcji z nimi. Utrzymanie ich wszystkich w MIS jest praktycznie niemożliwe, dlatego opracowano programową warstwę DeviceManager (DM), która zapewnia dla MIS jednolity interfejs do zlecania zadań urządzeniom i odbierania wyników.
Aby zwiększyć odporność systemu DM, został on podzielony na zestaw programów umieszczonych na komputerach w centrum medycznym. DM dzieli się na program główny oraz zestaw wtyczek, które wykonują interakcję z konkretnym urządzeniem i przesyłają dane do MIS. Na poniższym rysunku zaprezentowano ogólną strukturę interakcji z DeviceManager, MIS i urządzeniami.
Na strukturze interakcji MIS z DeviceManager przedstawiono 3 warianty pracy wtyczek:
- Wtyczka nie otrzymuje żadnych danych od MIS i przesyła dane z urządzenia, przekształcone w jej zrozumiały format (odpowiada urządzeniu typu 3 na powyższym rysunku).
- Wtyczka otrzymuje od MIS krótkie (czasowo realizowane) zadanie, na przykład drukowanie na drukarce lub skanowanie obrazu, realizuje je i przesyła wynik w odpowiedzi na zapytanie (odpowiada urządzeniu typu 1 na powyższym rysunku).
- Wtyczka otrzymuje od MIS długie zadanie, na przykład przeprowadzenie badania lub pomiar wskaźników, w odpowiedzi wysyła status przyjęcia zadania (w zleceniu zadania może być odmowa w przypadku błędu w zapytaniu). Po wykonaniu zadania wyniki są przekształcane w format zrozumiały dla MIS i przesyłane do odpowiednich interfejsów odpowiadających ich typowi (odpowiada urządzeniu typu 2 na powyższym rysunku).
Program główny DM uruchamia, inicjuje, ponownie uruchamia w przypadku nieprzewidzianego zatrzymania (awarii) i kończy działanie wszystkich wtyczek po zakończeniu pracy. Zestaw wtyczek na każdym komputerze jest inny, uruchamiane są tylko te niezbędne, które wskazane zostały w ustawieniach.
Każdy plugin to samodzielny program, który współdziała z głównym programem. Taka definicja pluginu zapewnia większą stabilność działania, dzięki niezależności wszystkich egzemplarzy pluginów i głowy pod kątem obsługi błędów (jeśli wystąpił krytyczny błąd, który spowodował awarię pluginu, inne pluginy i głowa pozostaną nietknięte). Jeden plugin obsługuje urządzenia jednego typu (często jednego modelu), przy czym niektóre pluginy mogą współdziałać tylko z jednym urządzeniem, a inne — z wieloma. Aby podłączyć kilka urządzeń tego samego typu do jednego DM, uruchamiamy kilka egzemplarzy jednego pluginu.
Do opracowania DM użyto narzędzi Qt, ponieważ w większości przypadków pozwala to na abstrahowanie od konkretnego systemu operacyjnego. Umożliwiło to wsparcie dla komputerów działających na Windows, Linux i MacOS, a także dla jednopłytkowych komputerów Raspberry. Jedynym ograniczeniem w wyborze systemu operacyjnego podczas tworzenia pluginów jest dostępność sterowników i/lub specjalnego oprogramowania dla konkretnego urządzenia.
Interakcja między pluginami a głową odbywa się za pomocą stale aktywnego QLocalSocket o nazwie konkretnego egzemplarza pluginu, według stworzonego przez nas protokołu. Implementacja protokołu komunikacyjnego po obu stronach została zrealizowana w formie dynamicznej biblioteki, co pozwoliło innym firmom na rozwijanie niektórych pluginów bez ujawniania pełnego działania z głową. Wewnętrzna logika lokalnego socketu pozwala głowie od razu dowiedzieć się o awarii za pomocą sygnału zerwania połączenia. W momencie sygnalizacji takiego sygnału następuje ponowne uruchomienie problematycznego pluginu, co pozwala na łagodniejsze radzenie sobie z krytycznymi sytuacjami.
Interakcję między MŚiS a DM zbudowano na podstawie protokołu HTTP, ponieważ MŚiS działa na bazie serwera WWW, w którym łatwiej jest wysyłać i odbierać zapytania zgodnie z tym protokołem. Istnieje również możliwość rozróżnienia problemów, które mogły wystąpić podczas ustawiania lub wykonywania zadań przez urządzenia na podstawie kodów odpowiedzi.
W kolejnych artykułach na przykładzie kilku gabinetów centrum diagnostycznego zostanie omówiona praca DM oraz niektórych pluginów.
Źródło: habr.com
