Device Manager. Падоўжыць МВС да прылад

Device Manager. Падоўжыць МВС да прылад
У аўтаматызаваным медыцынскім цэнтры выкарыстоўваецца мноства розных прыбораў, працай якіх павінна кіраваць медыцынская інфармацыйная сістэма (МВС), а таксама прылад, якія не прымаюць каманд, але павінны перадаць вынікі сваёй працы ў МВС. Аднак усе прылады маюць розныя варыянты падключэння (USB, RS-232, Ethernet і г.д.) і спосабы ўзаемадзеяння з імі. Падтрымаць іх усё ў МИС практычна немагчыма, таму была распрацавана праграмная праслойка DeviceManager (DM), якая падае для МИС адзіны інтэрфейс для пастаноўкі заданняў прыладам і атрыманні вынікаў.

Device Manager. Падоўжыць МВС да прылад
Для павелічэння адмоваўстойлівасці сістэмы DM быў падзелены на набор праграм, які размяшчаецца на кампутарах у медыцынскім цэнтры. DM дзеліцца на галаўную праграму і набор плагінаў, якія выконваюць узаемадзеянне з канкрэтнай прыладай і адпраўляюць дадзеныя ў МИС. На малюнку ніжэй прадстаўлена абагульненая структура ўзаемадзеяння з DeviceManager, МИС і прыборамі.

Device Manager. Падоўжыць МВС да прылад
На структуры ўзаемадзеяння МВС з DeviceManager паказаны 3 варыянты працы плагінаў:

  1. Убудова не атрымлівае ніякіх дадзеных ад МИС і адпраўляе ператвораныя ў зразумелы для яе фармат дадзеныя ад прыбора (адпавядае прыбору тыпу 3 на малюнку вышэй).
  2. Убудова атрымлівае ад МІС кароткую (па часе выканання) задачу, напрыклад, друк на друкарцы або сканаванне малюнка, выконвае яе і адпраўляе вынік у адказе на запыт (адпавядае прыбору тыпу 1 на малюнку вышэй).
  3. Убудова атрымлівае ад МІС доўгую задачу, напрыклад, правесці абследаванне або замерыць паказчыкі, у адказ адпраўляе статут прыняцця задачы (у пастаноўцы задачы можа быць адмоўлена пры памылцы ў запыце). Пасля выканання задачы вынікі пераўтворацца ў зразумелы для МИС фармат і выгружаюцца ў адпаведныя свайму тыпу інтэрфейсы (адпавядае прыбору тыпу 2 на малюнку вышэй).

Галаўная праграма DM запускае, ініцыялізуе, перазапускае ў выпадку непрадбачанага прыпынку (падзення) і завяршае пры завяршэнні працы ўсе плагіны. Склад плагінаў на кожным кампутары свой, запускаюцца толькі неабходныя, якія пазначаны ў наладах.

Кожная ўбудова ўяўляе сабой самастойную праграму, якая ўзаемадзейнічае з галаўной праграмай. Такое вызначэнне плагіна дазваляе забяспечыць больш стабільную працу, за кошт незалежнасці ўсіх экзэмпляраў плагінаў і галавы ў плане адпрацоўкі памылак (калі ўзнікла крытычная памылка, з-за якой убудова ўпала, то на іншых убудовах і галаве гэта не адаб'ецца). Адзін убудова дазваляе працаваць з прыладамі аднаго выгляду (часта адной мадэлі), пры гэтым частка убудоваў можа ўзаемадзейнічаць толькі з адным прыборам, а іншыя - з некалькімі. Для падлучэння некалькіх прылад аднаго тыпу да аднаго DM выкарыстоўваецца запуск некалькіх асобнікаў аднаго плагіна.

Device Manager. Падоўжыць МВС да прылад
Для распрацоўкі DM быў скарыстаны інструментар Qt, таму што ён дазваляе ў большасці выпадкаў абстрагавацца ад пэўнай аперацыйнай сістэмы. Гэта дазволіла падтрымаць працу з кампутарамі на базе Windows, Linux і MacOS, а таксама аднаплатнікамі Raspberry. Адзінае абмежаванне ў выбары аперацыйнай сістэмы пры распрацоўцы плагінаў - гэта наяўнасць драйвераў і / або спецыяльнага ПА для канкрэтнага прылады.

Узаемадзеянне паміж убудовамі і галавой адбываецца праз увесь час актыўны QLocalSocket з імем пэўнага асобніка ўбудовы, па створаным намі пратаколу. Рэалізацыя пратакола сувязі з абодвух бакоў была аформлена ў выглядзе дынамічнай бібліятэкі, што дало магчымасць весці распрацоўку некаторых плагінаў іншымі кампаніямі, не раскрываючы поўнасцю ўзаемадзеянне з галавой. Унутраная логіка працы лакальнага сокета дазваляе галаве адразу пазнаць аб падзенні пры дапамозе сігналу парыву злучэння. Па спрацоўванні такога сігналу адбываецца перазапуск праблемнага плагіна, што дазваляе больш бязбольна апрацоўваць крытычныя сітуацыі.

Узаемадзеянне паміж МВС і DM было вырашана пабудаваць на аснове HTTP пратаколу, бо МВС працуе на базе Web-сервера, у якім прасцей адпраўляць і прымаць запыты па дадзеным пратаколе. Таксама ёсць магчымасць адрозніваць праблемы, якія маглі ўзнікнуць пры пастаноўцы або выкананні задач прыборамі на аснове кодаў адказу.

У наступных артыкулах на прыкладзе некалькіх кабінетаў дыягнастычнага цэнтра будзе разгледжана праца DM і некаторых плагінаў.

Крыніца: habr.com

Дадаць каментар