Enhetsbehandling. Utvid MIS til enheter

Et automatisert medisinsk senter bruker mange forskjellige enheter, hvis drift må kontrolleres av et medisinsk informasjonssystem (MIS), samt enheter som ikke aksepterer kommandoer, men som må overføre resultatene av sitt arbeid til MIS. Alle enheter har imidlertid forskjellige tilkoblingsmuligheter (USB, RS-232, Ethernet, etc.) og måter å samhandle med dem på. Det er nesten umulig å støtte alle i MIS, så DeviceManager (DM) programvarelaget ble utviklet, som gir et enkelt grensesnitt for MIS for å tildele oppgaver til enheter og oppnå resultater.


For å øke feiltoleransen til systemet ble DM delt inn i et sett med programmer plassert på datamaskiner i legesenteret. DM er delt inn i et hovedprogram og et sett med plugins som samhandler med en bestemt enhet og sender data til MIS. Figuren nedenfor viser en generalisert struktur for interaksjon med DeviceManager, MIS og enheter.

Strukturen for interaksjon mellom MIS og DeviceManager viser 3 alternativer for plug-ins:

1. Plugin-modulen mottar ingen data fra MIS og sender data konvertert til et format som er forståelig for den fra enheten (tilsvarer enhetstype 3 i figuren ovenfor).
2. Programtillegget mottar en kort (når det gjelder utførelsestid) oppgave fra MIS, for eksempel utskrift på en skriver eller skanning av et bilde, utfører det og sender resultatet som svar på forespørselen (tilsvarer enhetstype 1 i figuren ovenfor ).
3. Programtillegget mottar en langsiktig oppgave fra MIS, for eksempel å gjennomføre en undersøkelse eller måle indikatorer, og som svar sender oppgaveakseptstatusen (oppgaven kan bli avvist hvis det er en feil i forespørselen). Etter å ha fullført oppgaven, konverteres resultatene til et format som er forståelig for MIS og lastes opp til grensesnittene som tilsvarer deres type (tilsvarer enhetstype 2 i figuren ovenfor).

DM-hovedprogrammet starter, initialiserer, starter på nytt i tilfelle et uventet stopp (krasj) og avslutter alle plugins når de slås av. Sammensetningen av plugins på hver datamaskin er forskjellig bare de nødvendige blir lansert, som er spesifisert i innstillingene.

Hver plugin er et uavhengig program som samhandler med hovedprogrammet. Denne definisjonen av en plugin tillater mer stabil drift på grunn av uavhengigheten til alle plugin-forekomster og hodet når det gjelder feilhåndtering (hvis det oppstår en kritisk feil som får plugin-en til å krasje, vil dette ikke påvirke andre plugins og hodet) . Ett plugin lar deg jobbe med enheter av én type (ofte samme modell), mens noen plugins kan samhandle kun med én enhet, mens andre kan samhandle med flere. For å koble flere enheter av samme type til én DM, start flere forekomster av samme plugin.

Qt-verktøysettet ble brukt til å utvikle DM-en fordi det i de fleste tilfeller tillater abstraksjon fra et spesifikt operativsystem. Dette ga støtte for datamaskiner basert på Windows, Linux og MacOS, samt Raspberry Pi-enheter med ett kort. Den eneste begrensningen på valg av operativsystem når man utvikler plugins er tilgjengeligheten av drivere og/eller spesialisert programvare for en bestemt enhet.

Interaksjon mellom plugins og hodet skjer gjennom en konstant aktiv QLocalSocket med navnet på en spesifikk plugin-forekomst, i henhold til protokollen vi opprettet. Implementeringen av kommunikasjonsprotokollen på begge sider ble designet som et dynamisk bibliotek, som gjorde det mulig å utvikle noen plugins av andre selskaper uten å fullstendig avsløre interaksjonen med hodet. Den interne logikken til den lokale stikkontakten gjør at hodet umiddelbart kan lære om fallet ved hjelp av et tilkoblingsbruddsignal. Når et slikt signal utløses, startes den problematiske plugin-en på nytt, noe som lar deg håndtere kritiske situasjoner mer smertefritt.

Det ble besluttet å bygge samspillet mellom MIS og DM basert på HTTP-protokollen, siden MIS opererer basert på Webservere, noe som gjør det enklere å sende og motta forespørsler ved hjelp av denne protokollen. Den lar deg også identifisere problemer som kan ha oppstått når du angir eller utfører oppgaver på enheter basert på svarkoder.

I de følgende artiklene, ved hjelp av eksemplet med flere diagnostiske senterrom, vil driften av DM og noen plug-ins bli undersøkt.

Kilde: www.habr.com