FELHASZNÁLÓI FELÜLET FEJLESZTÉSE AZ EPICS RENDSZERHEZ. Kósa Márk 1, Pánovics János 1, Heinrich du Toit 2 Nyakóné Juhász Katalin 1, John Pilcher 2

Átírás

1 FELHASZNÁLÓI FELÜLET FEJLESZTÉSE AZ EPICS RENDSZERHEZ DEVELOPMENT OF A GRAPHICAL USER INTERFACE FOR THE EPICS SYSTEM Kósa Márk 1, Pánovics János 1, Heinrich du Toit 2 Nyakóné Juhász Katalin 1, John Pilcher 2 1 Debreceni Egyetem, Informatikai Kar, Információ Technológia Tanszék 2 ithemba Labs, Cape Town Összefoglaló A Magyar Dél-afrikai Kormányközi TéT keretében létrejött együttműködést magyar részről a Debreceni Egyetem Informatikai Kara (IK), dél-afrikai részről az ithemba Laboratory for Accelerator Based Sciences (ithemba LABS) koordinálja. A két intézet tapasztalatai és lehetőségei nagyon jól kiegészítik egymást. Az ithemba LABS-nek sok kutatási és fejlesztési projektje van, ezért állandóan biztosítania kell kísérleti eszközeinek magas szintű megbízhatóságát. Az IK nagy információtechnológiai tapasztalattal és gyakorlattal rendelkezik a számítógéprendszerek tervezésében és a szoftverfejlesztésben, illetve ezen ismeretek oktatásában, kevés lehetőség van azonban technikai problémákkal foglalkozni. A kétéves projekt egy precíziós, nagy intenzitású nyalábosztó rendszer és a hozzá tartozó nyalábcsatorna vezérléséhez és diagnosztikájához szükséges szoftverek tervezésére, fejlesztésére és tesztelésére irányul. Cikkünkben a projekt keretében eddig elkészült szoftverről és a fejlesztés során szerzett tapasztalatainkról számolunk be. Kulcsszavak EPICS, MEDM, Qt programkönyvtár, signal/slot technika, Qt plugin, nemzetköziesítés Abstract The Hungarian South African Intergovernmental Cooperation in the frame of the Hungarian Science and Technology Foundation is coordinated by the University of Debrecen, Department of Informatics (DI) from Hungarian side, and ithemba Laboratory for Accelerator Based Sciences (ithemba LABS) from South African side. The experience and facilities of these two institutes complement each other very well. ithemba LABS has a lot of research and development projects, thus it needs to provide constant availability of its equipments. DI has lots of experience and practice in computer system design and software development, as well as in education of this knowledge, but it has very little chance to deal with technical problems. This two-year project aims at designing, developing and testing sotware used to control and diagnose a high precision, high intensity beam splitter system and the belonging beam tube. In this paper we show the software made by us so far in the frame of the project and about our experience of development. Keywords EPICS, MEDM, Qt program library, signal/slot technique, Qt plugins, internationalization 1

2 1. Együttműködés a TéT keretében A Magyar Dél-afrikai Kormányközi TéT keretében létrejött együttműködést magyar részről a Debreceni Egyetem Informatikai Kara (IK), dél-afrikai részről az ithemba Laboratory for Accelerator Based Sciences (ithemba LABS) koordinálja. A két intézet tapasztalatai és lehetőségei nagyon jól kiegészítik egymást. Az ithemba LABS-nek sok kutatási és fejlesztési projektje van, ezért állandóan biztosítania kell kísérleti eszközeinek magas szintű megbízhatóságát. Az IK nagy információtechnológiai tapasztalattal és gyakorlattal rendelkezik a számítógéprendszerek tervezésében és a szoftverfejlesztésben, illetve ezen ismeretek oktatásában, kevés lehetőség van azonban technikai problémákkal foglalkozni. A kétéves projekt egy precíziós, nagy intenzitású nyalábosztó rendszer és a hozzá tartozó nyalábcsatorna vezérléséhez és diagnosztikájához szükséges szoftverek tervezésére, fejlesztésére és tesztelésére irányul. A projekt első fázisában az ithemba LABS részecskegyorsítójának vezérlésére használt programhoz (EPICS) egy új, felhasználóbarát GUI kifejlesztését tűztük ki célul, amelyhez nyílt forráskódú rendszereket szerettünk volna felhasználni. A kialakítandó szoftverrel szemben elvárás volt, hogy egy grafikus elemekkel tetszőlegesen bővíthető interfészt nyújtson az EPICS rendszerhez, ezáltal ugyanis könnyebben kielégíthetők lennének a részecskegyorsító operátorainak az igényei, valamint hogy legyen lehetőség a szoftver nemzetköziesítésére. Választásunk azért esett a Qt grafikus programkönyvtárra, mert a signal/slot technológia segítségével szabványos módon tudjuk megoldani az EPICS folyamatváltozói (process variable, PV) és a grafikus elemek közötti kapcsolatot, a beépíthető modulok (plugin) biztosítják a könnyű bővíthetőséget, ráadásul a Qt hatékony eszközöket nyújt a különböző nyelvek közötti váltáshoz is. 2. Az EPICS rendszer Az Experimental Physics and Industrial Control System (magyarul: kísérleti fizikai és ipari vezérlő rendszer, röviden EPICS) szoftveres eszközök és alkalmazások olyan együttese, amely szoftveres infrastruktúrát biztosít elosztott vezérlő rendszerek építéséhez, részecskegyorsítók vagy nagy teleszkópok működtetéséhez és komplex kísérletek vezérléséhez. Az ilyen elosztott vezérlő rendszerek tipikusan több tíz, vagy akár több száz számítógépből állnak, amelyek hálózatba vannak kapcsolva, egyrészt ezzel biztosítva közöttük a kommunikációt, másrészt pedig hogy egy központi vezérlőből vagy akár az internetről vezérelhessük a rendszer különböző részeit, illetve hogy visszajelzést kaphassunk tőlük. Az EPICS a kliens/szerver és a publish/subscribe (közzétesz és előfizet) technikákat használja a számítógépek közötti kommunikáció során. A legtöbb szerver (amelyeket input/output controllernek, IOC-nek nevezünk) valós I/O-t és helyi vezérlő feladatokat hajt végre, és a klienseknek közzétesz bizonyos információkat a Channel Access (CA) hálózati protokoll segítségével PV-ken keresztül. A CA-t az olyan nagy sávszélességet igénylő, valós idejű hálózati alkalmazásokra optimalizálták, mint amilyen az EPICS is, ez az egyik oka, amiért több száz számítógépet magában foglaló vezérlő rendszerek építéséhez is használható. Az Advanced Photon Source (APS) intézménynél az EPICS-et több rendszer vezérlésére is használják. Körülbelül 250 IOC van (főleg Motorola VME kártyák MC680x0 és PowerPC processzorokkal, amelyek vxworks operációs rendszert futtatnak, de egyre több IOC már Linuxot, MacOS-t és RTEMS-et futtat), amelyek közvetlenül vagy közvetetten irányítják 2

3 csaknem az összes gépi műveletet, míg a vezérlőben 40 darab Sun munkaállomás és szerver biztosítja a magas szintű vezérlést, és nyújt felületet az operátoroknak, valamint az adatok archiválását, naplózását és elemzését is ezek végzik. A mérnökök és fizikusok számára egy Channel Access Gateway biztosít lehetőséget arra, hogy az IOC-ktől (és az irányított eszközöktől) biztonságos távolságban, az épület más részeiben vizsgálhassák az IOC-k aktuális állapotát, de megakadályozza, hogy illetéktelen módosításokat végezzenek a működő rendszerben. Sok esetben a mérnökök biztonságos internetkapcsolaton keresztül otthonról is felderíthetik és kijavíthatják a rendszerben fellépő hibákat. Az EPICS-nek megbízhatónak kell lennie, és biztosítania kell az intézményeknek, hogy a kapott vezérlő rendszer karbantartható és könnyen frissíthető legyen. Az APS-nél az említett több mint 200 IOC legtöbbjének meghibásodása vagy leállása azt eredményezheti, hogy az APS gyorsítója eldobja a sugarat, sőt bizonyos esetekben egy hibás output egyes eszközök meghibásodását is okozhatja, amelynek javítása több ezer dollárba kerülhet, és több napot, vagy akár heteket is igénybe vehet. Az IOC-knek folyamatosan kell működniük hónapokon keresztül újraindítás nélkül, ezért az EPICS megbízhatósága segíti az APS-t a sugár 95%-os vagy jobb rendelkezésre állásának biztosításában. 1. ábra Az EPICS rendszer honlapja 3

4 Eredetileg az összes EPICS IOC-nek a Wind River wxworks valós idejű operációs rendszerét kellett futtatnia, de 2004 óta lehetőség van GNU/Linuxot, Solarist, MS Windowst, MacOS-t és RTEMS-et is futtatni. Rendelkezésre állnak olyan hordozható szoftverek is, amelyek lehetővé teszik, hogy az EPICS-től eltérő vezérlő rendszereket CA szerverekként használhassunk. A CA kliensek mindig is számítógépek és operációs rendszerek széles skáláján működtek a legkedveltebbek a Unix, a GNU/Linux, a Windows, az RTEMS és a vxworks. Az EPICS-et eredetileg a Los Alamos National Laboratory és az Argonne National Laboratory fejlesztették ki, ma pedig már számos tudományos intézmény használja az egész világon. Ilyen például a claytoni (Ausztrália) Australian Synchrotron, a berlini (Németország) Berlin Electron Synchrotron, a villigeni (Svájc) Swiss Light Source, a Newport News-i (USA) Jefferson Laboratory, a padovai (Olaszország) Laboratori Nazionali di Legnaro, a didcoti (Nagy Britannia) Diamond Light Source és az tsukubai (Japán) KEK B-Factory. Az EPICS-et ma már ezen csoportok egymással együttműködve fejlesztik, és megosztják egymás között az I/O eszközök támogatását és a kliens alkalmazásokat. 3. A Qt programkönyvtár A Qt egy keresztplatformos alkalmazói keretrendszer asztali és beágyazott fejlesztésekhez. Tartalmaz egy intuitív API-t, egy gazdag C++ osztálykönyvtárat, integrált eszközöket GUI-k fejlesztéséhez és a nemzetköziesítéshez, valamint Java és C++ fejlesztői támogatást. A Qt lehetővé teszi, hogy a forráskód újraírása nélkül olyan alkalmazásokat készítsünk, amelyek különböző asztali operációs rendszereken és beágyazott eszközökön futnak A signal/slot mechanizmus A signalokat és slotokat objektumok közötti kommunikációra használják. A signal/slot mechanizmus a Qt központi eszköze, és valószínűleg ez az a rész, amely a leginkább különbözik a más keretrendszerek által biztosított eszközöktől. Egy GUI programozásánál, amikor módosítunk egy widgetet (a GUI egy tetszőleges elemét), gyakran szeretnénk, hogy erről a módosításról egy másik widget is értesüljön. Általánosabban azt szeretnénk, hogy bármilyen típusú objektum bármilyen típusú objektummal tudjon kommunikálni. Például ha a felhasználó rákattint a Bezár gombra, vélhetően azt szeretnénk, hogy meghívódjon az ablak close() metódusa. A régebbi eszköztárak ezt a fajta kommunikációt az úgynevezett callback mechanizmus segítségével valósították meg. A callback nem más mint egy függvénymutató, tehát ha azt szeretnénk, hogy egy feldolgozó függvény értesítsen minket valamilyen eseményről, akkor át kell adnunk neki egy másik függvényre mutató pointert (callback). Ezután a feldolgozó függvény meghívja ezt a callbacket, amikor szükséges. Ennek a mechanizmusnak két alapvető hátránya van. Egyrészt is nem típusbiztosak: soha nem lehetünk biztosak benne, hogy a feldolgozó függvény a callbacket megfelelő paraméterekkel fogja meghívni. Másrészt a callback szorosan kapcsolódik a feldolgozó függvényhez, hiszen a feldolgozó függvénynek tudnia kell, melyik callbacket kell meghívni. A Qt-ben van egy másik lehetőség: a signalok és slotok használata. Bizonyos események bekövetkezésekor kiváltunk egy signalt. A Qt widgetjei számos előre definiált signallal rendelkeznek, de bármikor származtathatunk új widgeteket az eredetiekből, hogy saját signalokkal egészítsük ki őket. A slot egy olyan függvény, amely egy bizonyos signalra reagálva 4

5 hívódik meg. A Qt widgetjei számos előre definiált slottal rendelkeznek, de általános gyakorlat, hogy új widgeteket származtatunk az eredetiekből, hogy saját slotokkal egészítsük ki őket, hogy kezelhessük a számunkra érdekes signalokat. A signal/slot mechanizmus típusbiztos: a signal specifikációjának meg kell egyeznie a fogadó slot specifikációjával. Mivel a specifikációk kompatibilisek, a fordítóprogram segíthet felfedezni a típuskeveredéseket. A signalok és slotok lazán kapcsolódnak egymáshoz: az az osztály, amelyik kiváltja a signalt, nem is tudja és nem is érdekli, hogy mely slotok fogják azt kezelni. A Qt signal/slot mechanizmusa biztosítja, hogy ha összekötünk egy signalt egy slottal, akkor a slot megfelelő időben meghívódjon a signal paramétereivel. A signalok és a slotok tetszőleges számú és típusú paraméterrel rendelkezhetnek, és teljes mértékben típusbiztosak. Egy slothoz tetszőleges számú signal köthető, ahogy egy signal is tetszőleges számú slothoz köthető, sőt arra is van lehetőség, hogy egy signalt közvetlenül egy másik signalhoz kössünk, ebben az esetben a második signal azonnal kiváltódik, amikor az első signal kiváltódik. Ahogy egy signal nem tudja, hogy bármi is kezeli-e őt, úgy a slot sem tudja, hogy van-e hozzá kötve signal, ezáltal teljesen független komponenseket készíthetünk a Qt-vel. #ifndef TEXTBOXPLUGIN_H #define TEXTBOXPLUGIN_H #include <QObject> #include <QMainWindow> #include "textboxinterface.h" class TextBoxPlugin : public TextBoxInterface { Q_OBJECT Q_INTERFACES( TextBoxInterface ) public: TextBoxPlugin(); ~TextBoxPlugin(); virtual void exec(); QStringList textboxes() const; protected: virtual void connectnotify( const char *signal ); public slots: virtual void setlanguage( QLocale::Language lang ); signals: void textchanged( QString s ); }; #endif 3.2. Nemzetköziesítés a Qt segítségével 2. ábra Signalok és slotok a QTDM programban Egy alkalmazás nemzetköziesítése az a folyamat, amikor felkészítjük az alkalmazást különböző nyelvi környezetekben történő felhasználására. Bizonyos esetekben a nemzetköziesítés egyszerű, például ha egy amerikai alkalmazás ausztrál vagy brit felhasználók számára szeretnénk elérhetővé tenni, akkor ez szinte csak néhány helyesírási korrekciót igényel. Ha viszont egy amerikai alkalmazást japán felhasználók számára, vagy egy koreai alkalmazást 5

6 német felhasználók számára szeretnénk elérhetővé tenni, akkor a szoftvernek nemcsak különböző nyelveken kell működnie, hanem más beviteli technikákat, karakterkódolást és megjelenítési szabályokat is igényel. A Qt megpróbálja a nemzetköziesítést a lehető legfájdalommentesebbé tenni a fejlesztők számára. Minden beviteli widget és szövegrajzolási módszer beépített támogatást nyújt minden támogatott nyelvhez. A beépített fontmotor helyesen tudja megjeleníteni a különböző írási rendszerek karaktereiből álló szövegeket. #include <QtDebug> #include "textboxplugin.h" TextBoxPlugin::TextBoxPlugin() { } TextBoxPlugin::~TextBoxPlugin() { } void TextBoxPlugin::exec() { qdebug() << "exec()"; emit textchanged( tr( "apple" ) ); } QStringList TextBoxPlugin::textboxes() const { return QStringList() << tr( "TextBox" ); } void TextBoxPlugin::connectNotify( const char *signal ) { qdebug() << "The" << QLatin1String( signal ) << "signal is connected."; } void TextBoxPlugin::setLanguage( QLocale::Language lang ) { emit textchanged( tr( "apple" ) ); } Q_EXPORT_PLUGIN2(textboxplugin, TextBoxPlugin); 3. ábra Signalok kiváltása és nemzetköziesített sztringek a QTDM TextBoxPlugin osztályának tagfüggvényeiben Akárhol is használ a programunk idézőjelezett szöveget, hogy megjelenítse azt a felhasználónak, biztosítanunk kell, hogy azt feldolgozza a QCoreApplication::translate() metódus. Ahhoz, hogy ezt elérjük, mindössze a QObject::tr() függvényt kell használnunk, ahogy az a 3. ábrán is látható. Ez a felhasználó által látható sztringek 99%-ánál működik. Ha használjuk a tr() függvényt egy alkalmazásban, elő kell állítanunk a felhasználó által látható szövegek fordításait is. Egy Qt alkalmazás fordítása egy három lépéses folyamat: 1) Az lupdate segédprogram futtatása, amely kigyűjti a C++ forráskódból a fordítható szövegeket, és előállít egy üzenet fájlt a szövegfordítók számára (ez egy.ts kiterjesztésű állomány). A segédprogram a tr() konstrukciók alapján ismeri fel a kigyűjtendő szövegeket, és rendszerint nyelvenként egy.ts fájlt generál. 2) A.ts fájlban található forrásszövegekhez fordítások biztosítása a Qt Linguist használatával (4. ábra). Mivel a.ts fájlok XML formátumúak, kézzel is szerkeszthetők. 3) Az lrelease segédprogram futtatása, amely a.ts fájlból egy üzenet fájlt hoz létre, amely már alkalmas a végső felhasználásra. A.ts fájl úgy működik mint egy forrás fájl, a.qm fájl pedig mint egy tárgykód fájl. A szövegfordító a.ts fájlokat szerkeszti, de az alkalmazás felhasználóinak csak a.qm fájlokra van szükségük. Mindkét fájltípus platform- és nyelvfüggetlen. 6

7 Ezeket a lépéseket az alkalmazás minden egyes verziójához meg kell ismételni. Az lupdate segédprogram mindent megtesz, hogy az előző verzióból újra felhasználja a fordításokat. Mielőtt lefuttatjuk az lupdate-et, elő kell készítenünk egy projektfájlt. Az általunk használt projektfájl az 5. ábrán látható. 4. ábra A Qt Linguist program ###################################################################### # Automatically generated by qmake (2.01a) Cs dec :52: ###################################################################### TEMPLATE = app subdirs SUBDIRS =. plugin/texboxplugin plugin/caplugin CONFIG += release TARGET = # Input HEADERS += mainwindow.h \ textboxinterface.h \ cainterface.h \ plugindialog.h SOURCES += main.cpp \ mainwindow.cpp \ plugindialog.cpp TRANSLATIONS += p1_hu.ts 5. ábra Egy egyszerű projektfájl a nemzetköziesítéshez 7

8 4. Kommunikáció egy virtuális gyorsítóval A 6. ábrán egy virtuális lineáris gyorsító vezérlőjének az operátori felületét láthatjuk. A virtuális gyorsítót vezérlő IOC szerver kimenete a hátsó parancsablakban látható (részben takarva az operátori felülettel). Ehhez az IOC szerverhez egy olyan egyszerű program kapcsolódik, amely CA segítségével lekérdezi az operátori felület bal oldalán látható (az ábrán piros színnel jelölt) hőmérsékleti értéket, és megjeleníti azt egy szövegdobozban az alkalmazás munkaterületén. 6. ábra A Virtual Linac és a QTDM működés közben Irodalomjegyzék [1] A Trolltech honlapja, [2] Experimental Physics and Industrial Control System, 8