Krónikus hemodialízis gép testenkívüli vérszállítást vezérlő szoftverének objektum orientált szemléletű fejlesztése

Hasonló dokumentumok
Orvosi ké szü lé kékbén haszna lhato modérn féjlészté si téchnolo gia k léhéto sé géinék vizsga lata

Autóipari beágyazott rendszerek. Komponens és rendszer integráció

Eseménykezelés. Szoftvertervezés és -fejlesztés II. előadás. Szénási Sándor.

Krónikus hemodialízisgép dializáló oldat előkészítést vezérlő szoftverének objektumorientált szemléletű fejlesztése

III. Alapfogalmak és tervezési módszertan SystemC-ben

Szoftver újrafelhasználás

OOP. Alapelvek Elek Tibor

Szoftver-technológia II. Szoftver újrafelhasználás. (Software reuse) Irodalom

A LEGO Mindstorms EV3 programozása

Szoftverarchitektúrák 3. előadás (második fele) Fornai Viktor

Termeléshatékonyság mérés Ipar 4.0 megoldásokkal a nyomdaiparban

Szolgáltatás Orientált Architektúra a MAVIR-nál

Információtartalom vázlata

01. gyakorlat - Projektalapítás

Informatika. 3. Az informatika felhasználási területei és gazdasági hatásai

ARM Cortex magú mikrovezérlők. mbed

Széchenyi István Egyetem. Programozás III. Varjasi Norbert

Iman 3.0 szoftverdokumentáció

IDAXA-PiroSTOP. PIRINT PiroFlex Interfész. Terméklap

S01-7 Komponens alapú szoftverfejlesztés 1

Digitális technika VIMIAA01 9. hét Fehér Béla BME MIT

S01-8 Komponens alapú szoftverfejlesztés 2

Digitális technika VIMIAA01 9. hét

Objektum orientáltság alapjai A Java nyelv Fordítás - futtatás

Már megismert fogalmak áttekintése

Inczédy György Középiskola, Szakiskola és Kollégium Nyíregyháza, Árok u. 53. TANMENET. Informatika szakmacsoport

Előzmények

Programozás. Objektum Orientált Programozás (OOP) Alapfogalmak. Fodor Attila

LabVIEW példák és bemutatók KÉSZÍTETTE: DR. FÜVESI VIKTOR

Operációs rendszerek. Az NT folyamatok kezelése

Programozási nyelvek Java

Folyamatirányítás labor 4. mérés Gyártósori szállítószalag modell irányítása Modicon M340 PLC-vel. Feladat leírás

Modellinformációk szabványos cseréje. Papp Ágnes, Debreceni Egyetem EFK

Bánsághi Anna 2014 Bánsághi Anna 1 of 31

A Java EE 5 plattform

Rubin SPIRIT TEST. Rubin firmware-ek és hardverek tesztelése esettanulmány V1.0. Készítette: Hajnali Krisztián Jóváhagyta: Varga József

Programozó- készülék Kezelőkozol RT óra (pl. PC) Digitális bemenetek ROM memória Digitális kimenetek RAM memória Analóg bemenet Analóg kimenet

E-Számla Szerver szolgáltatás bemutató és díjszabás

Neurális hálózatok bemutató

egy szisztolikus példa

ISA szimulátor objektum-orientált modell (C++)

UML (Unified Modelling Language)

Komponens alapú fejlesztés

DAT adatcserefájl AutoCAD MAP DWG mapobject konvertáló program dokumentáció

A KÖZÉPSZINTŰ ÉRETTSÉGI VIZSGA INFORMATIKA TÉMAKÖREI: 1. Információs társadalom

Objektum orientált programozás Bevezetés

Számítógép architektúra

Rendszertervezés 2. IR elemzés Dr. Szepesné Stiftinger, Mária

Advisor Master. GE Interlogix Magyarország Kft.

Interfészek. PPT 2007/2008 tavasz.

Absztrakció. Objektum orientált programozás Bevezetés. Általános Informatikai Tanszék Utolsó módosítás:

Objektumorientált paradigma és a programfejlesztés

TANMENET 2018/2019. tanév

Nagy bonyolultságú rendszerek fejlesztőeszközei

Programozási nyelvek Java

MICONT Intelligens ház automatika. Rendszermodulok

Hatékony iteratív fejlesztési módszertan a gyakorlatban a RUP fejlesztési módszertanra építve

Komponens alapú programozás Bevezetés

OpenCL alapú eszközök verifikációja és validációja a gyakorlatban

Orvostechnikai eszköz tesztelése DSS Unit test. Taliga Miklós BME-IIT

Alapismeretek. Tanmenet

Járműinformatika A járműinformatikai fejlesztés

Nyilvántartási Rendszer

Enterprise JavaBeans. Ficsor Lajos Általános Informatikai Tanszék Miskolci Egyetem. Az Enterprise JavaBeans

Kameleon Light Bootloader használati útmutató

Megoldás. Feladat 1. Statikus teszt Specifikáció felülvizsgálat

Információk. Ismétlés II. Ismétlés. Ismétlés III. A PROGRAMOZÁS ALAPJAI 2. Készítette: Vénné Meskó Katalin. Algoritmus. Algoritmus ábrázolása

C++ programozási nyelv

Laborgyakorlat Logikai áramkörök számítógéppel segített tervezése (CAD)

Podoski Péter és Zabb László

és az instanceof operátor

2.1.A SZOFTVERFEJLESZTÉS STRUKTÚRÁJA

Java VIII. Az interfacei. és az instanceof operátor. Az interfészről általában. Interfészek JAVA-ban. Krizsán Zoltán

Szárazföldi autonóm mobil robotok vezérlőrendszerének kialakítási lehetőségei. Kucsera Péter ZMNE Doktorandusz

Osztott Objektumarchitektúrák

ORVOSTECHNIKAI ESZKÖZÖK GYÁRTMÁNYFEJLESZTÉSE AKTÍV ORVOSI ESZKÖZÖK FEJLESZTÉSE - PEMS V&V

A szoftver-folyamat. Szoftver életciklus modellek. Szoftver-technológia I. Irodalom

Informatikai alkalmazásfejlesztő Információrendszer-elemző és - tervező

1. Mi a fejállományok szerepe C és C++ nyelvben és hogyan használjuk őket? 2. Milyen alapvető változókat használhatunk a C és C++ nyelvben?

Norway Grants. Az akkumulátor mikromenedzsment szabályozás - BMMR - fejlesztés technológiai és műszaki újdonságai. Kakuk Zoltán, Vision 95 Kft.

Miskolci Egyetem Alkalmazott Informatikai Intézeti Tanszék A minőségbiztosítás informatikája. Készítette: Urbán Norbert

Documentum-menedzsment. À la Open Source Molnár Ferenc Rendszerintegrációs igazgató

Pilot projekt az NFGM-ben: nyílt forráskódú kollaborációs dokumentumportál és üzleti dashboard projektek tapasztalatai

Laborgyakorlat Logikai áramkörök számítógéppel segített tervezése (CAD)

Az operációs rendszer szerkezete, szolgáltatásai

Számítógépes képelemzés projektmunkák 2012

Bevezetés a Python programozási nyelvbe

A J2EE fejlesztési si platform (application. model) 1.4 platform. Ficsor Lajos Általános Informatikai Tanszék Miskolci Egyetem

Ficsor Lajos Általános Informatikai Tanszék Miskolci Egyetem

Grid menedzsment megoldás az ARC köztesrétegben

10. EGYSZERŰ HÁLÓZATOK TERVEZÉSE A FEJLESZTŐLAPON Ennél a tervezésnél egy olyan hardvert hozunk létre, amely a Basys2 fejlesztőlap két bemeneti

SZENZORMODUL ILLESZTÉSE LEGO NXT PLATFORMHOZ. Készítette: Horváth András MSc Önálló laboratórium 2 Konzulens: Orosz György

Kölcsönhatás diagramok

Könyvtári címkéző munkahely

SZÓBELI ÉRETTSÉGI TÉMAKÖRÖK

Utolsó módosítás:

OO rendszerek jellemzői

ESEMÉNY VEZÉRELT ALKALMAZÁSOK FEJLESZTÉSE I. Bevezetés. Készítette: Gregorics Tibor

A szerzõrõl... xi Bevezetés... xiii

PLC Versenyfeladat. XIV. Országos Irányítástechnikai Programozó Verseny Budapest, március Összeállította az EvoPro Kft.

Átírás:

Kutatói beszámoló Krónikus hemodialízis gép testenkívüli vérszállítást vezérlő szoftverének objektum orientált szemléletű fejlesztése Készítette: Paári Krisztián gyakornok, B. Braun Medical Kft. 2015.01.21.

Bevezető Az ipar minden területét jellemzi az a tendencia, hogy az elkészítendő új termékeket egyre rövidebb idő alatt, egyre olcsóbban kell elkészíteni. Természetesen ez nem mehet a minőség rovására, mert akkor a megrendelők, felhasználók nem fogják az adott terméket választani a jövőben. Ez a megközelítés az orvosi berendezések esetén is igaz. Bár ezen eszközök, berendezések közvetlenül befolyásolják az emberek egészségét, mégse mentesülnek ettől az igen nehéz követelménytől. Így elkerülhetetlen a versenyben maradáshoz, hogy ezen iparág szereplői kövessék a globális trendet: olcsóbban, gyorsabban, jobbat. A kutatói pályázat során egy krónikus hemodialízis gép irányító szoftverének egy adott részét kell elkészítenem, amely testen kívüli vérszállítás irányításáért felel. A munkámat támogató vállalat kitűzte céljául, hogy nem csak az irányító szoftvert, de magát a fejlesztés folyamatát is modernizálják. Így nem az volt a fő feladatom, hogy elkészítsem a dialízis gép irányító szoftverének egy fejlesztését, hanem a fejlesztés folyamatára javasoljak újításokat. A hemodialízisről általában Dialízis kezelésre akkor van szükség, ha a beteg veséje nem képes ellátni a feladatát. A kezelések két nagy csoportra oszthatók: akut és krónikus. Előbbire akkor kerül sor, ha a kezelést szükségessé tévő állapot átmeneti és csak rövid ideig áll fenn. Utóbbit akkor kell alkalmazni, ha tartósan fennáll a veseelégtelenség. A kutatási pályázat keretén belül az utóbbi esetben alkalmazott kezelési módszer egyik fajtája, a hemodialízis kerül a vizsgálat középpontjába. A hemodialízis során a beteg vérét átvezetik egy testen kívüli félig áteresztő szűrőn (dializátor), majd a már megtisztított vért visszajuttatják a testbe. A szűrőn való áthaladás során a vérből kiszűrik a méreganyagokat, a felesleges víz távozik, viszont a szükséges elemek, mint fehérjék, fehérvértestek a vérben maradnak. A folyamat a dialízis készülék segítségével megy végbe, mely irányítja a vér és egyéb folyadékok áramlását, valamint felügyeli mindazt. A folyamat biztonságos, számos szigorú szabvány és előírás szabályozza a dialízis műveletét. A kezelés folyamatát fel lehet osztani különböző állapotokra. Ez azért előnyös, mert ekkor egyszerűen meghatározható, hogy az adott állapotban milyen működés szükséges. Így az implementálás nagyban egyszerűsödik. Újrafelhasználhatóság és Referencia Modell Architektúra Az újrafelhasználhatóság célja, hogy egy már meglévő szoftver komponenst többször is képesek legyünk alkalmazni, ne kelljen minden esetben újra és újra ugyan azt a funkcionalitást elkészíteni. Ennek több fajtája létezik. S bár egyik esetben sem kell újra feltalálni a kereket, mégse mindegy, hogy ez pontosan miért is van. Minden szinten lehetséges a már meglévő funkció újbóli alkalmazása. Ez történhet hivatkozás, illetve másolás útján. Az utóbbi eset alkalmazása az egyszerűbb. A két fajta újrafelhasználás közül nem lehet győztest hirdetni. Az adott típus az egyes esetekben sokkal előnyösebb lehet a másiknál. Ezért minden alkalommal mérlegelni kell, hogy melyiket kell alkalmazni.

Az AUTOSAR szabvány segítségével lehetővé vált a komponens alapú szoftvertervezési modell a járműrendszerekre. Ez a modell olyan alkalmazás szoftver komponenseket használ, amelyek egy absztrakt komponensen át, a virtuális buszon kapcsolódnak egymáshoz. Az alkalmazás szoftver komponensek a legkisebb alkotórészei a rendszernek, melyek még egy bizonyos funkcióval rendelkeznek. Ezek között standardizált interfészek segítségével történik az információcsere, melyek a szabványban rögzítettek. Az AUTOSAR-hoz hasonló referencia-architektúrát is el lehetne készíteni dialízis gépek esetében. A referencia rendszer tartalmazná az összes funkcionalitást, melyek akármelyik dialízis gép esetén előfordulhat. Ebből az unióból lehetne kiválasztani az éppen szükséges részeket az aktuális összeállítás számára. Majd a kiválasztott részekből generálható lenne a teljes rendszer. Javasolt szoftver architektúra A legalsó réteg legyen ebben az esetben is a hardverrel kapcsolatot tartó réteg. A hardver absztrakciós réteg (HardWare Abstraction Layer - HWAL) tartalmazna minden hardverfüggő részt a szoftverben. Így ha megváltozik valamelyik hardver egység a dialízis gépben, akkor elegendő ebben a rétegben módosításokat eszközölni, az irányító rész többi része változatlanul maradhat. A következő szoftver réteg tartalmazza az alap objektumokat (Basic Object - BO). Ezek a HWAL által szolgáltatott jeleket fogadják többek között. Ezen réteg felelős azért, hogy egy meghatározott hardver egység (például egy nyomás szenzor vagy egy pumpa) teljes irányításáért. Ezen a rétegen nagy számú alap objektum lesz megtalálható, hisz minden egyes hardver egység rendelkezni fog egy ilyennel. A következő, legfelső réteg az alacsony szintű irányító szoftverrendszerben a szervező objektumok (Organizer Object - Org) szintje. Ezen réteg tagjai felelősek a kis egységek, az alap objektumok irányításáért, összehangolásáért. Itt az állapotgép által megadott módon kerül sor a különböző egységek irányítására. A szervezők számára már minden információ rendelkezésre fog állni, hogy megfelelő módon tudják működtetni a dialízis gépet. A most ismertetésre került javasolt architektúra látható alábbi ábrán. Ezen architektúra legfelső rétege az Adminisztrátorok nevet kapta és mely a kezelővel és a dialízis gép egyéb komponenseivel tartja a kapcsolatot. 1. Javasolt SW architektúra felépítése

A programozás jobb átláthatósága miatt jött az ötlet, hogy az alap és szervező objektumok, azok kapcsolata grafikus programozó eszköz segítségével legyen implementálva. Ekkor a függvényeket felváltják a blokkok, amik magukba foglalják azok funkcionalitását. A mostani sok változó helyett jelek lennének, melyek szemmel jobban követhetőek a feldolgozás során. Az egyek jeles útja a grafikus ábrázolásnak köszönhetően jól megfigyelhető. Úgy tűnt, hogy a Matlab Simulink alkalmas lesz az új architektúra kipróbálására, illetve ha beválik, akkor a későbbi fejlesztése is hosszú távon. Alap objektumok Az egyes alap objektumok könyvtárakként ( Library ) való elkészítése a javasolt. Ezek olyan nem futtatható modellek, amelyeket később fel lehet használni más modellben, mégpedig azok belinkelésével, vagyis referencia útján. A Matlab könyvtárak számos előnyös tulajdonsággal rendelkeznek. Az alábbi ábra mutatja egy alap objektum általános felépítését. Látható, hogy az egyes belső blokkok fogják a különböző funkciókat megvalósítani. Ahogy azt már korábban ismertettem, az alap objektumok minden olyan funkcionalitást tartalmaznak, amelyek valamely dialízis gépben szükségesek lehetnek. Ezen funkciók nagy része paraméter segítségével engedélyezhető, letiltható. Vannak olyan funkcionalitások is, amelyek annyira alapvetőek, hogy azok letiltásának semmi értelme nincsen, mert ekkor az alap objektum teljesen elveszti funkcionalitását, így nincs értelmét az adott elem használatának az alkalmazásban. 2. Alap objektum általános felépítése Példányosítás során nem kell mást tenni, mint a megfelelő könyvtár elemet behúzni a modellbe, a megfelelő paramétereket beállítani, a ki és bemeneteket pedig rákötni egy-egy buszra. Figyelni kell arra, hogy a kimenetnél a busz neve megegyezzen a példány nevével. Erre azért van szükség, mert később a példányok neve alapján lehet elkülöníteni a jeleket egymástól. Az így példányosított alap objektum rendelkezni fog egy ki és bemeneti porttal, a többi rész a példányon belül marad.

Szervező objektumok A szervező objektumok felelősek a leendő dialízis gép tényleges irányításáért. Ezen egységek dolgozzák fel az alap objektumok jeleit, határozzák meg a szükséges műveleteket, valamint adják ki a kívánt utasításokat. Ezen egységek között elképzelhető a hierarchia, amely esetében bizonyos szervezők nem csak a különböző alap objektumokat hanem egymást is képesek vezérelni. Ez azért előnyös a jövőre nézve, mivel így a működést fel lehetne osztani kisebb részekre, amelyek megvalósításáért más és más szervezők a felelősek. Az így készülő rendszer átláthatóbbá válik, a fejlesztés során lehetőség nyílik a munkamegosztásra. Például elképzelhető, hogy egy külön szervező lesz felelős a riasztások feldolgozásáért és azokra való megfelelő válaszlépések kiadásáért. Az egyes szervező egységek között lehetséges a kommunikáció, csatolás. Így elkerülhető, hogy egymásnak ellentmondó működést kívánjanak megvalósítani. A szervező objektumok az egyes állapotokban különböző funkciókat valósítanak meg. Az aktuális állapot az Adminisztrátori réteg felől érkezik. Ez alapján hajtódik végre a kívánt funkció. Természetesen lehetséges olyan állapot is, mely során az adott szervezőnek nincsen feladata. De előfordul a gyakorlatban, hogy két különböző állapotban is ugyan azt a funkciót kell végrehajtani. Az egyes szervező objektumok vázát egy Switch Case blokk fogja alkotni a hozzá tartozó Switch Case Action Subsystem blokkokkal együtt. Az előbbi meghatározza az aktuális állapot alapján, hogy az utóbbiak közül éppen melyik lesz aktív, azaz milyen műveletet hajt végre az aktuális szervező objektum. A Switch Case Action Subsystem blokkok fogják tartalmazni az egyes funkcionalitásokat, melyek az adott állapotban végrehajtódnak. Ezek az újrafelhasználhatóság, módosíthatóság miatt könyvtárakként lesznek elkészítve, ugyan úgy, mint az alap objektumok. Ha egy állapotban nem kell semmilyen műveletet elvégezni, akkor az ahhoz tartozó blokk helyett egy Terminator blokkot lehet rakni, így elkötve a szabad vezetéket. 3. Szervező objektum általános felépítése

Összegzés A korábbiakban ismertetett módon implementált alap és szervező objektum példányokból felépíthető a végső rendszer, mely alkalmas egy dialízis gép irányítására. Ez a rendszer látható az alábbi ábrán. A különböző be és kimeneti portokon át képes a rendszer kommunikálni a dialízis gép egyéb komponenseivel. 4. Az irányító rész elkészült modellje Természetesen ezzel még nem érhet véget a munka. Az elmúlt rövid idő nem volt elegendő ahhoz, hogy a hosszú távú kitűzött cél, miszerint az irányító rendszer modellje automatikus készüljön el, teljesüljön. Ehhez már arra lenne szükség, hogy elkészüljenek a különböző függvények, melyek a részekből felépítik az egész rendszert.