Et automatiseret lægecenter bruger mange forskellige enheder, hvis drift skal styres af et medicinsk informationssystem (MIS), samt enheder, der ikke accepterer kommandoer, men skal overføre resultaterne af deres arbejde til MIS. Alle enheder har dog forskellige tilslutningsmuligheder (USB, RS-232, Ethernet osv.) og måder at interagere med dem på. Det er næsten umuligt at understøtte dem alle i MIS, så softwarelaget DeviceManager (DM) blev udviklet, som giver en enkelt grænseflade til MIS'et til at tildele opgaver til enheder og opnå resultater.
For at øge systemets fejltolerance blev DM opdelt i et sæt programmer placeret på computere i lægehuset. DM er opdelt i et hovedprogram og et sæt plugins, der interagerer med en bestemt enhed og sender data til MIS. Figuren nedenfor viser en generaliseret struktur for interaktion med DeviceManager, MIS og enheder.
Strukturen af interaktion mellem MIS og DeviceManager viser 3 muligheder for plug-ins:
- Pluginnet modtager ingen data fra MIS'en og sender data konverteret til et format, der er forståeligt for det fra enheden (svarer til enhedstype 3 i figuren ovenfor).
- Pluginnet modtager en kort (med hensyn til udførelsestid) opgave fra MIS, for eksempel udskrivning på en printer eller scanning af et billede, udfører det og sender resultatet som svar på anmodningen (svarer til enhedstype 1 i figuren ovenfor ).
- Pluginnet modtager en langsigtet opgave fra MIS, for eksempel at udføre en undersøgelse eller måle indikatorer, og som svar sender opgaveacceptstatus (opgaven kan blive afvist, hvis der er en fejl i anmodningen). Efter fuldførelse af opgaven konverteres resultaterne til et format, der er forståeligt for MIS, og uploades til de grænseflader, der svarer til deres type (svarer til enhedstype 2 i figuren ovenfor).
DM-hovedprogrammet starter, initialiserer, genstarter i tilfælde af et uventet stop (nedbrud) og afslutter alle plugins ved nedlukning. Sammensætningen af plugins på hver computer er forskellig; kun de nødvendige lanceres, som er angivet i indstillingerne.
Hvert plugin er et uafhængigt program, der interagerer med hovedprogrammet. Denne definition af et plugin giver mulighed for mere stabil drift på grund af uafhængigheden af alle plugin-instanser og hovedet med hensyn til fejlhåndtering (hvis der opstår en kritisk fejl, der får pluginet til at gå ned, så vil dette ikke påvirke andre plugins og hovedet) . Et plugin giver dig mulighed for at arbejde med enheder af én type (ofte samme model), mens nogle plugins kun kan interagere med én enhed, mens andre kan interagere med flere. For at forbinde flere enheder af samme type til en DM skal du starte flere forekomster af det samme plugin.
Qt-værktøjssættet blev brugt til at udvikle DM, fordi det giver os mulighed for at abstrahere væk fra et specifikt operativsystem i de fleste tilfælde. Dette gjorde det muligt at understøtte arbejde med computere baseret på Windows, Linux og MacOS, samt Raspberry single-board enheder. Den eneste begrænsning ved valg af operativsystem ved udvikling af plugins er tilgængeligheden af drivere og/eller speciel software til en bestemt enhed.
Interaktion mellem plugins og hovedet sker gennem en konstant aktiv QLocalSocket med navnet på en specifik plugin-instans i henhold til den protokol, vi oprettede. Implementeringen af kommunikationsprotokollen på begge sider var designet som et dynamisk bibliotek, som gjorde det muligt at udvikle nogle plugins af andre virksomheder uden helt at afsløre interaktionen med hovedet. Den interne logik i det lokale stik gør det muligt for hovedet straks at lære om faldet ved hjælp af et forbindelsesbrudsignal. Når et sådant signal udløses, genstartes det problematiske plugin, hvilket giver dig mulighed for at håndtere kritiske situationer mere smertefrit.
Det blev besluttet at bygge interaktionen mellem MIS og DM ud fra HTTP-protokollen, da MIS opererer på en webserver, hvilket gør det nemmere at sende og modtage forespørgsler ved hjælp af denne protokol. Det er også muligt at skelne mellem problemer, der kan opstå ved indstilling eller udførelse af opgaver med enheder baseret på svarkoder.
I de følgende artikler vil DM og nogle plug-ins blive undersøgt ved hjælp af eksemplet med flere diagnostiske centerrum.
Kilde: www.habr.com