Автоматизираният медицински център използва много различни устройства, чиято работа трябва да се контролира от медицинска информационна система (MIS), както и устройства, които не приемат команди, но трябва да предават резултатите от работата си в MIS. Всички устройства обаче имат различни опции за свързване (USB, RS-232, Ethernet и др.) и начини за взаимодействие с тях. Почти невъзможно е да се поддържат всички от тях в MIS, затова беше разработен софтуерният слой DeviceManager (DM), който осигурява единен интерфейс за MIS за възлагане на задачи на устройства и получаване на резултати.
За да се увеличи отказоустойчивостта на системата, DM беше разделен на набор от програми, разположени на компютри в медицинския център. DM е разделен на основна програма и набор от добавки, които взаимодействат с конкретно устройство и изпращат данни към MIS. Фигурата по-долу показва обобщена структура на взаимодействие с DeviceManager, MIS и устройства.
Структурата на взаимодействие между MIS и DeviceManager показва 3 опции за плъгини:
- Плъгинът не получава никакви данни от MIS и изпраща данни, конвертирани в разбираем за него формат от устройството (съответства на устройство тип 3 на фигурата по-горе).
- Плъгинът получава кратка (по отношение на времето за изпълнение) задача от MIS, например отпечатване на принтер или сканиране на изображение, изпълнява я и изпраща резултата в отговор на заявката (съответства на устройство тип 1 на фигурата по-горе ).
- Плъгинът получава дългосрочна задача от MIS, например за провеждане на проучване или измерване на индикатори, и в отговор изпраща състоянието на приемане на задачата (задачата може да бъде отказана, ако има грешка в заявката). След изпълнение на задачата резултатите се конвертират във формат, разбираем за MIS и се качват на интерфейсите, съответстващи на техния тип (съответства на устройство тип 2 на фигурата по-горе).
Основната DM програма стартира, инициализира, рестартира в случай на неочаквано спиране (срив) и прекратява всички добавки при изключване. Съставът на плъгините на всеки компютър е различен, стартират се само необходимите, които са посочени в настройките.
Всеки плъгин е независима програма, която взаимодейства с основната програма. Тази дефиниция на плъгин позволява по-стабилна работа поради независимостта на всички екземпляри на плъгина и главата по отношение на обработката на грешки (ако възникне критична грешка, която причинява срив на плъгина, това няма да засегне други плъгини и главата) . Един плъгин ви позволява да работите с устройства от един тип (често един и същ модел), докато някои плъгини могат да взаимодействат само с едно устройство, докато други могат да взаимодействат с няколко. За да свържете няколко устройства от един и същи тип към един DM, стартирайте няколко екземпляра на един и същи плъгин.
За разработването на DM беше използван инструментариумът Qt, защото в повечето случаи той позволява абстракция от специфична операционна система. Това позволи поддръжка за компютри, базирани на Windows, Linux и MacOS, както и едноплаткови устройства Raspberry Pi. Единственото ограничение при избора на операционна система при разработване на плъгини е наличието на драйвери и/или специализиран софтуер за конкретно устройство.
Взаимодействието между плъгините и главата се осъществява чрез постоянно активен QLocalSocket с името на конкретен екземпляр на плъгин, според създадения от нас протокол. Внедряването на комуникационния протокол от двете страни беше проектирано като динамична библиотека, което направи възможно разработването на някои добавки от други компании, без да се разкрива напълно взаимодействието с главата. Вътрешната логика на локалния сокет позволява на главата незабавно да научи за падането с помощта на сигнал за прекъсване на връзката. Когато се задейства такъв сигнал, проблемният плъгин се рестартира, което ви позволява да се справяте с критични ситуации по-безболезнено.
Беше решено взаимодействието между MIS и DM да се изгради на базата на HTTP протокола, тъй като MIS работи на базата на Уеб сървъри, което улеснява изпращането и получаването на заявки, използвайки този протокол. Той също така ви позволява да идентифицирате проблеми, които може да са възникнали при задаване или изпълнение на задачи на устройства въз основа на кодове за отговор.
В следващите статии, използвайки примера на няколко стаи на диагностичен център, ще бъде разгледана работата на DM и някои добавки.
Източник: www.habr.com
