Írta: Hóringer Tamás
2021. szeptember 11. 10:33:37 CEST
Nem tudom, Ti hogy vagytok vele, de a különféle munkák közül számomra mindig is a legkedvesebbek közé tartoztak azok, amelyek kerek egészet alkotnak. Ahol nem csak egy új funkció, vagy egy hiba kijavítása cél, hanem ahol az ötleteléstől kezdődően, a konkrét igényeken nyugvó tervezésen, a fejlesztésen, összeszerelésen, beüzemelésen keresztül, a tesztelés, finomhangolás és rutin üzemvitel folyamatával záródóan minden lépésben részt veszel. Ilyenkor együtt élsz az adott rendszerrel, berendezéssel, sajátodként tekintesz rá, eszerint is igyekszel minden apró részletét a lehető legteljesebb - néha talán túlzó - mértékben tökéletesre csiszolni.
A Medi-Radiopharma Kft.-vel történő szorosabb együttműködés azzal a két liofilizáló géppel kezdődött, melynek vezérlés cseréjéről a mostani rövid írás is született. Az ezalatt eltelt idő során, a közösen megélt nehézségek, majd az ezeket utólag megszépítő/feledtető sikerek eredményeképp reményeim szerint egy olyan partneri - és ezen belül kollegiális - kapcsolat született meg, amely hosszú távon sok hasonló projekt garanciája lehet.
Több mint egy évtizede már, hogy életemben először léptem be egy gyógyszergyár kapuján ezzel egyszersmind egy rendkívül érdekes új világ tárult fel előttem számos olyan folyamattal és ezeket kiszolgáló berendezéssel, mely működésének megértéséhez néha újra elő kellett venni a fizika és kémia tankönyveimet.
Mindezek közül talán az egyik legérdekesebb a liofilizálás melyre magyarul leginkább a fagyasztva szárítás kifejezést szokták használni.
A folyamat lényege az ún. hármaspont: Ez olyan hőmérséklet és nyomás, melynél egy anyag három termodinamikai halmazállapota találkozik.
A liofilizáló berendezés tulajdonképpen arra jó, hogy a benne elhelyezett rakományt (ebben az esetben oldattal töltött injekciós üveget) előbb meghatározott hőmérsékletre (pl: ~-45°C) lefagyaszt, majd ezt követően a nyomást rendkívül mély (p<20-30ubar) vákuum közelébe csökkenti és ezt az állapotot huzamosabb ideig fenntartja. Ilyen környezeti feltételek mellett a fagyott oldat jégkristályaiból a nedvesség (előbb a szabadvíz, majd a hőmérséklet emelésével a kötött víz) szublimálni kezd (szilárd halmazállapotból kipárolog), majd a termodinamikai hajtóerő hatására a berendezés részét képező, a termék hőmérsékleténél jóval alacsonyabb (~ -70°C) kondenzátor felé távozik és arra újra kifagy.
A folyamat célja tulajdonképpen a nedvesség kivonása a késztermékből, mely így kedvezőbb paraméterekkel rendelkezik eltarthatóság, kezelés és más szempontokból.
(Ezúton is elnézést kérek a gyógyszerész, technológus, fizikus, gépész és persze operátor kollégáktól akik most a fejüket fogják a pontatlan, esetleg hibás leírás olvasása közben.)
Körülbelül két évvel ezelőtt járunk. Ekkortájt keresett meg egy Kollégám, akivel sok éven át dolgoztunk egyazon vállalatnál. Elmondta, hogy a Medi-Radiopharma Kft.-nél (engedjétek meg, hogy a továbbiakban egyszerűen “MRP”-ként említsem Őket) két - termelés szempontjából - kritikus berendezés vezérlésének (ideértve most az adatgyűjtés- és megjelenítés területét) időszerűvé vált a felújítása, elsősorban annak érdekében, hogy az elektronikus adatkezelés támasztotta elvárások, valamint az Ipar 4.0 nyújtotta előnyök minél teljesebb mértékben való kielégítése, illetve kiaknázása mellett legyenek üzemeltethetőek. A projekt ekkor még két jól elkülöníthető részre, tervezésre és kivitelezésre lett felosztva, melyből az előbbire kaptunk felkérést, amit nagy örömmel el is fogadtunk és miután némi egyeztetést követően tisztázódtak a keretek, kezdetét vette a munka...
A gyógyszeripari projektek hatalmas előnye, hogy a relatív szigorú minőségbiztosítás egy-egy rendszer változtatását, a változtatás módját, annak mérföldköveit, ellenőrző pontjait, az ellenőrzés módját, kritériumait és elfogadását valamint ezek dokumenentálását az érvényben lévő előírásokon - de főleg a segédleteken, guidelineokon - keresztül átfogóan szabályozza. Bevált módszer szerint a Com-Forth Kft. az ISPE által kiadott, az automatizált rendszerekre vonatkozó helyes gyártási gyakorlat immáron 5. kiadását (GAMP5) követve, szakismereti és kockázati megközelítésben (science and risk based) dolgozik, eszerint zajlik a fejlesztés, illetve ennek megfelelően tesz javaslatokat egy berendezés életútja során a szükséges kvalifikációs, validációs tevékenységekre, azok fenntartásához elengedhetetlen feladatokra, illetve igény szerint - mint jelen esetben is - ezt alapul véve végzi azokat.
A felhasználói igények specifikációja (URS) az MRP szakértői gárdájával közösen, az egyes területeket szekciónkként elkülönítve, az érintett terület szakértőjének (SME) vezetésével került összeállításra, így biztosítva, hogy a rendszer specifikációja minden szempontból egyenszilárdságú legyen és éppúgy tartalmazza a kulcsfontosságú gyártástechnológiai aspektusokat, mint az IT/OT által a helyi infrastruktúrába történő hatékony integráláshoz szükséges igényeket. Fontosnak tartom kiemelni, hogy az igény megfogalmazása során végig cél volt, hogy az ne egy adott gyártó eszközeit listázza, hanem egy elvárt megoldást definiáljon, melyre a majdani - így jóval szélesebb körből kikerülő - potenciális partnerek a maguk és az általuk képviselt eszközök lehetőségeihez mérten tudnak válaszokat adni. Eddigi pályafutásom alatt számtalanszor találkoztam ennek ellenkezőjével olyan esetekben is, amikor ez - pl.: meglévő állapothoz történő illesztés miatt - nem lett volna feltétlen szükséges. Egy rendszer minőségére nem szükségszerűen garancia a komponenseinek műszaki színvonala, az azokkal kapcsolatos minőségi szint elvárás termékkategória megjelölésével is elérhető, ha pedig az egyéb okok (pl.: cserealkatrész ellátás, szakismeret, stb.) nem indokolják, kifejezetten sajnálatos, ha ezen megkötésekkel kvázi az URS-be “kódolt” kompromisszumokkal az igénylő - hosszú távon - eleve önmaga ellen dolgozik.
Az URS kiadását követően hosszabb szünet következett, részben a mi, részben pedig az MRP más elfoglaltsága miatt, majd megérkezett az ajánlattételre felhívó megkeresés is, melynek - más versenytársakkal együtt - mi is igyekeztünk legjobb tudásunk szerint eleget tenni.
A felhasználói igény szerint tehát a cél két meglévő, egymással gépészeti- és villamos szempontból gyakorlatilag azonosnak tekinthető berendezés fölé egy olyan PLC/SCADA/HMI rendszer fejlesztése, mely képes
azok felett recepteken keresztül paraméterezhető liofilizálási (illetve vákuum) ciklusok futtatására
a futás során a kamratérben ill. a berendezés egyéb részein elhelyezett szenzorokról érkező adatok gyűjtésére és tárolására,
olyan egyesített kezelőfelület biztosítására, ahol a gép mindenkori állapot ellenőrzésén és kezelésén túlmenően lehetőség van a receptek kezelésére (létrehozás, módosítás, stb.), a tárolt idősoros és diszkrét állapot adatok megtekintésére és különböző riportok készítésére, valamint a berendezés speciális paramétereinek kezelésére.
Az igények a tervezés során, de még a kivitelezés megkezdése előtt kiegészültek abban a vonatkozásban, hogy - lehetőség szerint költséghatékony módon - kerüljön kialakításra egy kizárólag megjelenítési célokat szolgáló, böngészőben, natív HTML5 alapon, bármilyen egyéb komponens telepítése nélkül is futtatható ultravékony kliens, melyet asztali számítógépeken vagy egyéb kézi eszközökön használnak majd.
A PLC - mint hardverelem - adott volt, a Siemens S7-300 programjának újragondolását Török Gábor végezte.
SCADA/HMI tekintetében viszonylag egyszerű volt a választás: a GE által fejlesztett iFIX hosszú évtizedek óta szerepel a Com-Forth Kft. portfóliójában, saját ügyfélkörünkön belül is nehéz lenne megszámolni, hány gyógyszeripari célra készült alkalmazás üzemel a beépített Electronic Signature modullal, mely a felhasználók számára teszi egyszerűbbé a US FDA 21 CFR Part 11 szerinti elvárásoknak megfelelő kezelést. A recept kezelésre a gyári megoldás helyett mi egy saját fejlesztésű, a logikát tekintve teljes egészében SQL alapú megoldással dolgoztuk ki.
Habár az iFIX SCADA core stabil és jól skálázható, a frontend könnyen kezelhető, azonban ekkor még tagadhatatlan hátránya volt, hogy az itt megfogalmazott feladatra az elérhető webes kliensei nem voltak ideálisak: vagy nem volt lehetőség a telepítés nélküli használatra, vagy a licenc költség / elvárt funkcionalitás terén nem bizonyultak optimális megoldásnak.
Alternatíva keresése közben merült fel az ötlet, hogy a Com-Forth Kft. által szintén évtizedek óta forgalmazott OPTO22 legújabb, zászlóshajónak szánt eszközét, a groovEPIC-et felhasználva egy, az iFIX-től részben független, ahhoz - mint OPC UA adatforrás - és a PLC-hez saját driveren keresztül közvetlen csatlakozó megjelenítő rendszert alakítsunk ki. Ezen - ekkor még úgy gondoltuk - nem is fog szerepelni semmi más, csak a berendezés aktuális állapotjelzői és az épp futó ciklus főbb paraméterei (azonosító, név, aktuális lépés, stb.) Talán nem lepek meg vele senkit, ha előre elárulom, nem így lett, de erről majd később.
Komponensek tekintetében ezt követően még két megoldandó feladat maradt:
Az MRP IT hálózata ekkor még nem volt felkészítve a biztonságos távoli hozzáférésre, azonban jó megérzéssel a projekt során ennek kialakítását megkövetelték, mindezt úgy, hogy egy - akkor már tervezés alatt álló - az egész üzemegységet felölelő IT rekonstrukciós folyamatba ez később illeszthető legyen. Ez az igény egyben egy újabb lehetőséget is hozott nekünk és a körülbelül másfél évvel ezelőtt a képviselt termékkörünkhöz csatlakozó MB connect line számára. Olyan eszközre volt szükség, amely ipari kivitelű, ideálisan DIN sínre szerelhető, lehetővé teszi a rendszer számára egy fizikailag is izolált alhálózat létrehozását és mindemellett távoli VPN kapcsolat is kiépíthető vele. Az mbNET.Rokey secure router mindezt egyben kínálta egy olyan SaaS megoldással kiegészítve, amely beruházói oldalon gyakorlatilag nulla további költségráfordítással bárhonnan biztonságosan hozzáférhetővé teszi a berendezést.
A végére már csak a szünetmentes betáplálás biztosítása maradt, amely ebben az esetben kizárólag az adatgyűjtési- és megjelenítési funkciók biztosítására kellett korlátozódjon, a nagyfogyasztók ellátása nem volt cél. Ennek megoldása részben az automatika szekrényben elhelyezett inverteres tápegység (+ akkumulátor), részben pedig a SCADA szerver/kliens PC betáplálását biztosító APC UPS beiktatásával történt.
A rendszer topológiáját az alábbi vázlatrajz szemlélteti:
Megjegyzés: Az “Out of scope” szekció nem ad pontos leírást az üzemi hálózat sem múltbéli, sem jelenlegi állapotáról, csupán a topológia kialakításának könnyebb megértését szolgálja.
A két gép átalakítását egymást követően, meghatározott kihagyással ütemeztük, egyrészt azért, hogy a termelés zavartalanul folyhasson, másrészt pedig mert így az első gépen mód van az új rendszer “gyerekbetegségein” túlesni, így a második esetében mind a beüzemelés, mind pedig az átállás leegyszerűsödik minden résztvevő számára. Az első berendezés előkészítő munkálatai alig két hét alatt befejeződtek, ám amint hozzákezdtünk volna a folytatáshoz, közbeszólt a COVID.
A kivitelezés talán legkritikusabb pontjában, a helyszínen történő beüzemelés megkezdésével nagyjából egy időben érkezett meg Magyarországra a COVID harmadik hulláma és az ezzel járó azon elővigyázatossági intézkedések, melyek - amellett, hogy szükségesek voltak - a hagyományos értelemben vett munkavégzést jelentősen megnehezítették.
Az új helyzet mindenütt új igényeket és (ha a technológiára nézve nem is új) de alkalmazás tekintetében mindenképp újszerűnek tekinthető megközelítéseket kívánt.
Amíg pár éve az ipari hálózatokhoz történő külső hozzáférés még a legtöbb esetben tabutémának számított, melyet a globális vagy helyi IT/OT politika általában kérdés nélkül utasított el, mára ennek a lehetőségnek az elemi szükségességét minden racionálisan gondolkodó szereplő belátta, sőt kijelenthető, hogy akik meglátták az ebben rejlő kétségtelen lehetőségek kihasználásának módját, azok jelentősen növelték előnyüket - és ennélfogva végső soron a versenyképességünket - a termelés és az üzemvitel során egyaránt.
Az MRP liofilizálógépek rokonstrukciós projektje kiváló példa volt erre. Az épp a projekt kritikus pontján bekövetkező korlátozások hetekkel vethették volna vissza a munkát, melyet számokban nem is próbálnék meg kifejezni, de ha csak az így kieső termelést, az szükségessé váló átcsoportosításokat, stb. tekintem (nem beszélve a potenciális üzleti hatásokról) bőven 8 számjegyű összegről beszélünk.
A távoli elérés lehetőségének már tervezőasztaltól kezdődően történő integrálása, valamint a partner és a helyi IT részleg gyors reakciójának köszönhetően gyakorlatilag egyik napról a másikra történő átmenettel, fennakadás nélkül tudtuk folytatni a munkát, így ezzel kapcsolatos veszteséget egyik oldalnak sem kellett elkönyvelnie.
Természetesen a gépoldali szakfelügyeletet így sem volt mód elkerülni, de az infrastruktúra adta lehetőségekkel élve ez a minimum 3-4 főről egyre volt csökkenthető, mellesleg pedig az addig utazással (kiszállás) töltött idő is a projekt szempontjából effektív mérnökidővé konvertált.
A beüzemelés és a tesztelés így kényszerűen javarészt távoli hozzáféréssel történt, azonban ezt sikerült relatív zökkenőmentesen megoldani, a rendszer pedig kezdte felvenni végleges formáját. Mint minden ilyen projektnél, a munka egyik legösszetettebb része a kezelőfelület implementálása volt. Igényként is megfogalmazódott, illetve saját tapasztalatok alapján is úgy próbáltuk a High Performance HMI paradigma szerint megvalósítani a képernyőket, hogy közben a már megszokott felülethez a lehető legközelebb maradjunk, az azon jól működő koncepciókat átmentsük az új rendszerbe, elhagyva azokat, amelyek használata nehézkesebb volt. A régi és új elemeket harmonikus és főleg ergonomikus egésszé kellett komponálni.
A hagyományos értelemben vett asztali megjelenítésért felelős iFIX workspace használatában már van gyakorlatunk, és mivel ez lett dedikáltan a rendszer elsődleges HMI felülete, a koncepció is itt kristályosodott ki.
Bár a dashboardnak szánt felület - mely egyben az ún. “automata üzem” felügyeleti képernyője is - egy kicsit zsúfoltabb a megszokottnál, mégis ezt a megoldást választottuk, két megfontolásból:
A berendezés normál üzemi körülmények között történő használatának túlnyomó idejét automata állapotban tölti. Ilyenkor beavatkozás ideális esetben nem is történik, a folyamat az előre megszabott recept szerint zajlik. Míg a többi üzemmód, funkció esetében jellemző a közel állandó, aktívabb felügyelet, valós időben történő kezelés (és ilyen módon aktív interakció a felületeken keresztül), addig automata üzem közben az operátoroknak elég ritkábban ellenőrizni azt, ezt pedig gyakorlatilag az egyetlen pillantással, egér v. billentyűzet használata nélkül megtehetik.
A korábbi megjelenítő rendszer tartalmilag hasonló koncepciót alkalmazott, így a felhasználóknak nem kellett egy teljesen új felületet megszokni.
Az alkalmazott Full HD felbontású DELL, matt monitorok tükröződés és becsillanás mentes nagy felbontású felületet biztosítanak, így az átláthatóság kockáztatása nélkül is relatív nagy mennyiségű adat elhelyezésére volt mód, melyből a felhasználó számára releváns prompt információ átadást a csoportosítással és az animációkkal érjük el.
A webes megjelenítő esetén már bonyolultabb a helyzet. Míg az asztali megjelenítés esetén a viszonylag fix felbontás és aspektus miatt a felhasználó által látott képet már tervezéskor elég jól testre tudjuk szabni, addig mobil eszközöknél ez értelemszerűen valamivel komplexebb feladat. Ipari rendszereknél kritikusnak tekinthető, hogy az információk mindenkor helyes prioritással és kontextusban történő átadása biztosított legyen: ne legyen kitakarás, “lelógás”, minden ott legyen, ami kell, de mégis áttekinthető maradjon. Ennek megvalósításához volt nagy segítség az EPIC-re előre telepített groov View. A kész kontrollok használatával gyakorlatilag codeless, kizárólag drag&drop megközelítéssel összeállíthatóak voltak az egyes képernyők alternatívái, a natív reszponzibilitásról pedig a külön szerkeszthető desktop és handheld nézet gondoskodott.
A webes megjelenítés - mint desktop kezelőfelület - alkalmazásával ebben az esetben elméletileg limit nélküli kliens egyidejű kiszolgálását tettük lehetővé (melynek tulajdonképp csak a hardver szab korlátokat), így a szóba jöhető alternatívákkal összevetve mindenképp kiemelkedően hatékony mind költség, mind pedig üzemeltetés tekintetében.
Mindenképpen szót kell ejtenünk a megoldás hátrányairól is, melyeket azonban idejében felismerve és már a tervezés során figyelembe véve reális kompromisszumokat lehetett kötni.
Minden projekt során vannak emlékezetes pillanatok. Mérföldkövek, sikerélmények, “végre működik”, “na… mégsem” és “ahááá” felkiáltások. Ezek azok, amelyek kapcsán évek múlva is emlékszik az ember az adott munkára, és amelyek sokszor életre szóló leckével szolgálnak egy-egy módszer, eszköz vagy épp szemlélet tekintetében.
Már jócskán benne voltunk a beüzemelésben, amikor az MRP részéről felmerült, hogy a recept paramétereket a webes megjelenítő felületen is látni szeretnék. Bár az URS erre nem tért ki, az igény megvalósításának különösebb akadálya nem látszott, a groov View firmware-ben pedig az ekkor debütáló Computed Tag erre relatív kényelmes és gyors megoldást kínált.
A képernyő prototípusa fél nap alatt elkészült, kihelyeztük a tesztelés alatt álló rendszerbe, és folyt tovább a munka. Az egyik nap épp az otthoni dolgozóban ülve iszom a délutáni kávét, az egyik monitoron valami hivatalos levelet írok épp, a másikon pedig a gép webes megjelenítő felülete, hogy oda-oda pillantva szemmel tudjam tartani a ciklus lefutását. Csörög a telefonom, az egyik helyszínen dolgozó kolléga kérdezi, hogy mi újság. A képernyőre pillantva (kiélvezem a High Performance HMI nyújtotta gyors áttekinthetőséget) megállapítom, hogy minden kékben, az előírtak szerint, a kamra 25 körül, a nyomás lassan csökken, a kondenzátor hőmérséklet -77°C körül mozog, tehát minden a legnagyobb rendben. A másik oldalon rövid csend, majd a kolléga kurtán és némi indulattal a hangjában közli, hogy nyitva a kamraajtó és áll a gép...
A kezdeti hitetlenkedés, majd zavart fejvakarást követően - illetve miután a kolléga a helyszínről is megerősítette, hogy míg az iFIX HMI a valós állapotot mutatja, addig a webes felületen valóban az van, amit én is látok, hosszas nyomozás vette kezdetét, mely önmagában számos izgalmas pontot tartogatott, ezeket egy jövőbeni személyes találkozás során szívesen elmesélem. A hiba oka az volt, hogy az EPIC firmware tartalmazott egy hibát, amely miatt egy bizonyos számot meghaladó Computed tag esetén, ha az EPIC processzor terhelése egy adott szint fölé került (pl.: a HMI kliensek száma, vagy más háttérben futó folyamatok miatt), akkor a tag-ek feldolgozása csúszni (késni) kezdett az aktuális állapothoz képest, így valós időben egy múltbéli érték volt látható. Ez pár másodperctől a pár óráig eszkalálódott, majd a megjelenítő backend összeomlásához és kényszerű újraindításához vezetett.
Szerencsére a gyártó a hibát kiemelt ügyként kezelte, és viszonylag gyorsan megszületett rá a megbízhatóan működő megoldás.
Az akár mindenfajta szakirányú tudás nélkül is eredményes alkalmazhatóságot biztosító WYSWIG, codeless, drag&drop hármasért az adott határokon túl már korlátozott testreszabhatósággal kell fizetni, mely néha zavaró. Sokszor nyúl az ember keze a nagyobb rendszerekben megszokott scripting toolok után. Hozzáteszem, az EPIC koncepcióját úgy alakították ki, hogy minimális kreativitással és a fedélzeti eszközök (PAC Control, Node-Red, stb.) használatával egészen összetett feladatok is megoldhatóak, de azért ez nem ugyanaz. Adódtak apróbb esztétikai hibák az eredetileg iFIX felületre komponált képernyő portolásából is (pl.: a képen a jobb oldalt látható túllógás), melyen hosszas hezitálást követően végül túlléptünk, és mely nem elsősorban a szoftver eszköznek, hanem az alkalmazás módjának tudható be. Ugyanakkor nem szabad elfelejteni, hogy az eszköz célja és funkciója jelen rendszerben kizárólag a megjelenítés, melynek tökéletesen eleget tesz.
Ezzel a kifejezéssel leginkább a különböző számítógépes szoftverek (pl.: szövegszerkesztő) használata illetve tágabb értelmben a frontendek (HMI képernyők, weboldalak, stb.) fejlesztése során találkozhattok és nagy vonalakban azt jelenti, hogy a fejlesztőkörnyezetben már eleve úgy tudod összeállítani a tartalmat (dokumentumot, képernyőt, felületet, stb.), ahogyan azt használat közben látják majd a felhasználók. A WYSWYG eszközök hatalmas előnye, hogy az adott szoftver használatában kevesebb v. akár minimális gyakorlattal rendelkező ember is relatív gyorsan és eredményesen tud vele dolgozni.
Habár a webes felületen történő beavatkozás nem volt elvárás, mégis közel van ahhoz, hogy akár teljesértékű kliensként is alkalmazni lehesen. Ami ezt jelenleg nem teszi lehetővé, az a SCADA és a groov View eseménykezelése közti natív kapcsolat hiánya, mely miatt a szigorú gyógyszeripari előírások által megkövetelt intakt és integrált eseménynapló, valamint a kliens oldalon végrehajtott Elektronikus Aláírás jelenleg csak olyan mértékű további fejlesztéssel lett volna megoldható, melyre jelen projektben nem volt lehetőség.
A valós időben gyűjtött adatok tárolásáért a GE Historian Essentials, illetve a Microsoft SQL Express 2019 felel. Előbbit a GE biztosítja ingyenesen az iFIX SCADA/HMI mellé, utóbbi pedig szintén ingyenesen használható, limitált funkcionalitású szoftver. A riportálási feladatokat a szintén a Microsoft égisze alá tartozó Reporting Services látja el.
A projekt érdekessége, hogy az új vezérlő és adatgyűjtő rendszerhez kapcsolódó, annak kvalifikált ill. validált állapotát garantáló és bizonyító dokumentumok jelentős részét az MRP-nél dolgozó kollégákkal szoros együttműködésben mi készítettük, javarészt az általunk összeállított sablonok alapján. Aki dolgozott már GMP hatálya alá tartozó rendszeren, tudja, hogy a kivitelezői munka lendülete sokszor bizony nehezen összeegyeztethető a meglehetősen rigorózus szabályokkal. Habár a gyógyszeripari validáció évtizedek óta részét képezi a Com-Forth Kft. mindennapjainak, néha bizony komoly fejtörést okozott a két oldal közti optimális egyensúly fenntartása.
Számomra a projekt, a projektben részt vevő csapat és közös munka eredményeként rendszerbe álló két berendezés legjobb minőségi mutatója a problémamentes üzemvitel mellett az auditokra történő felkészülést megelőző feszült órák alacsony száma, illetve az azt követő kölcsönös elismerés: ezen is túl vagyunk. :)
A munkában részt vettek: K. Nándor (MRP), M. Zsolt (MRP), M. Csaba (MRP), N. Gábor (CF), P. Artúr (MRP), V. Balázs (CF), T. Gábor valamint az Com-Forth Kft. és a Medi-Radiopharma Kft. további kollégái.
A support során nélkülözhetetlen segítséget nyújtottak: Gerhard Kreiling (Opto22)
