Biró Csaba, Geda Gábor, Kovács Emőd Eszterházy Károly Főiskola AgriaMedia 2011 Eger, október

Tartalom Elosztott rendszer és middleware Middleware-ekkel szemben támasztott elvárások Általános koncepciók Problémák összetett rendszerek tervezésénél Alrendszerek kompozíciója Middleware-ek a robottechnikában Miro, Orca, UPnP Robot Middleware, ASEBA, Player/Stage System, The PEIS Kernel, ORiN, MARIE, RSCA, RT-Middleware 2

Elosztott rendszer és a Middleware Elosztott rendszer Egy több komponensből álló rendszer, amelyek valamilyen kommunikációs mechanizmuson keresztül működnek együtt. Middleware A middleware egy olyan elérhető szoftver réteg, mely a heterogén platformok és protokollok hálózati rétege és az üzleti alkalmazás(ok) között helyezkedik el. 3

Middleware-ekkel szemben támasztott elvárások Minden funkciót biztosító, széles körűen elfogadott API-k. Magasabb absztrakciós szint. Komponens alapú és bizonyos esetekben objektumorientált szemlélet támogatása. Lokális transzparencia biztosítása. Biztonság: kódolt kommunikáció, kliens azonosítható, különböző szerepkörökkel felruházható. Skálázható, azaz a terheléstől függően konfigurálható. Hibakezelés, hibakeresés (elosztott környezetben). 4

Middleware-ek a robotikában Elsődlegesen összetett robotirányítási rendszerekben használják. Egy úgynevezett „glue” szoftver, amelynek segítségével, a fejlesztők egyszerre el tudják érni az összes szoftver és hardver komponenst. Segíti a komponensek közötti kommunikációt és rendszerekbe ágyazott alkalmazás független kód által segítséget nyújt a komponens alapú fejlesztéshez. 5

Problémák összetett rendszer tervezésénél Interfész ne legyen bonyolultabb, mint az összes alrendszer kombinációja. Megtalálni az egyensúlyt a teljesítmény és az egyszerű újrafelhasználhatóság között. 6

Fogalmi szinten, egy komplex robotvezérlő rendszer összetevőinek mindegyike besorolható a következő felsorolás valamelyikébe: Kommunikáció: Egyes összetevők közötti információcsere (adatok, események, parancsok). Számítás: Minden komponens bizonyos számításokat hajt végre, amelyek elvégzéséhez a rendszer biztosítja a megfelelő funkcionalitást. Konfiguráció: A pontos konfiguráció elengedhetetlen a tervezésnél a rendszer és az egyes komponensek implementációjánál. Szükséges a szoftver életének különböző fázisaiban: fordítási idő, futásidő,… Koordináció: A várt viselkedés és teljesítmény érdekében rendszer szinten az alkotóelemek tevékenységeit össze kell hangolni. A koordináció magába foglalja: döntéshozatal, ütemezés, alrendszerek és/vagy összeköttetések aktiválása vagy inaktiválása. 7

Alrendszerek kompozíciója Alrendszerekből optimálisan összeállítani egy „nagy” rendszert még napjainkban is inkább művészet, mint tudomány. Legnagyobb kihívást az jeleni, hogy az alrendszerek amellett, hogy szorosan együttműködnek a nagy rendszerrel továbbra is megtartsák stabilitásukat. Lehetséges eljárások a különböző szoftverkomponensek összeállítására: explicit hivatkozásokkal összekapcsolt objektumosztályok létrehozása, olyan objektumosztályok létrehozása, amelyek nem tudnak egymásról, komponensekből összeállítva, szoftverszolgáltatásokból összeállítva. Egy összetett rendszert stabilnak nevezünk, ha az felhasználói beavatkozás nélkül rendeltetésszerűen működik. 8

Miro Elosztott objektum orientált keretrendszer, mobil robotok irányítására. Alapkomponenseket C++-ban fejlesztették ACE (Adaptive Communications Environment) alatt. ACE egy objektum orientált multi platform keretrendszer kifejezetten operációsrendszertől független interprocesszekre, hálózai és valós idejű kommunikációra terveztek. TAO (The ACE ORB) ORB (Object Request Broker) egy CORBA implementáció, amelyet nagy számítási teljesítmény eléréséhez és valós idejű alkalmazások futtatásához terveztek. Miro elosztott architektúrája 9

Orca Elsődlegesen olyan alkalmazások fejlesztésére tervezték, amely egy járművön levő elosztott érzékelő- hálózatot képes kezelni. Orca első verziója egy nyílt forráskódú CORBA implementáció, de a CORBA-nál jelentkező komplexitási problémák miatt már az Ice-t használják. Ice egy egészen új szemléletet vezetett be az objektum orientált middleware-ek között. Biztosít egy az eddigieknél sokkal kisebb és konzisztensebb API-t. Átláthatóbb implementációt tesz lehetővé, fejlett szolgáltatásokkal, és jobb teljesítménnyel. Orca kommunikációs modellje 10

UPnP Robot Middleware Az UPnP Robot Middleware fejlesztője a KIST (Korea Institute of Science and Technology). Az UPnP (Universal Plug and Play) architektúrát használja fel dinamikus robotok belső és külső szoftverintegrációihoz és irányításához. Software konfiguráció 11

Az UPnP támogatja a konfigurálásmentes hálózatot. Egy UPnP kompatiblis eszköz bármilyen gyártótól beszerezhető, amely tud dinamikusan csatlakozni egy hálózathoz, megszerzi az IP-címet, bejelenti a nevét, kérésre közli a képességeit, eszközök jelenlétéről értesül, valamint azok képességeiből képes tanulni. 12

Az eszközök automatikusan elhagyhatják a hálózatot anélkül, hogy otthagynának bármilyen felesleges állapotinformációt. Ezen mechanizmusokat használják fel a robot komponenseinek konfigurálása. A robot képes körülötte lévő robotok szenzorjait (kamerák, szenzorhálózatok, elektromechanikus eszközök) felfedezni és interakcióba lépni. Hardware konfiguráció 13

ASEBA ASEBA egy eseményvezérelt köztesszoftver, amely támogatja az elosztottságot (irányítást és hatékony erőforrás-kihasználást) a multiprocesszoros robotoknál. Több processzorral rendelkező robotok kommunikációjának segítésére tervezték. 14

Player/Stage System Player/Stage rendszer, mint köztesszoftver platform eszközöket és algoritmusokat biztosít mobil robotalkalmazásokhoz. Két fő összetevője van: Player Stage 15

Player Egy repository szerver indítókaroknak, szenzoroknak és robotoknak ahol minden egyes eszközhöz tartozik egy driver és egy interfész. Az interfészek egy részét a kliens egyrészt arra használja, hogy alkalmazásokat indítson továbbá, hogy információt kapjon a szenzor működéséről. A drivereken implementálva vannak az üzenetküldéssel kapcsolatos algoritmusok. 16

Stage Egy grafikus alapú szimulátor, aminek segítségével az elkészített modelleket és eszközöket felhasználó által definiált környezetben lehet tesztelni. Stage szimulátor Gazebo 3D szimulátor 17

The PEIS Kernel A PEIS kernel az ETRI (Electronics and Telecommunications Research Institute, Korea) és CAASS (Centre for Applied Autonomous Sensor Systems, Sweden) kutatóközpontok közös munkájának eredménye. Ezeknek a rendszereknek elsődleges célja olyan robotok készítése, amelyeknek feladata, hogy otthonunkban mindennapi feladataink elvégzésében segítsenek. 18

PEIS middleware Célja olyan egységes kommunikációs és együttműködési modell kialakítása, amelyet egységesen tudnak használni, mobil robotokon lévő érzékelők és működtetők illetve az automatizált háztartási gépek. Minden PEIS eszköz ezt az egységes kommunikációs modellt használja. 19

ORiN Egy interfészt biztosít Windows operációs rendszerrel rendelkező számítógépeknek, szabványos módszerek eléréséhez és robotikai rendszerek irányításához. 20

MARIE MARIE (Mobile and Autonomous Robotics Integration Environment). Céljuk egy rugalmas és elosztott komponensrendszer fejlesztése volt, amely egy rendkívül gyors alkalmazásfejlesztés tesz lehetővé. A MARIE háromrégetű architektúrája: mag, komponensek, alkalmazások. 21

RSCA (Robot Software Communication Architecture) Az RSCA a (Seoul National University) által (QoS szolgáltatásaira építve) fejlesztett middleware. Fő erőssége, hogy valós idejű támogatást illetve egy szabványos felhasználói környezet biztosít az alkalmazások fejlesztéséhez. A felhasználói környezet részei: Valós idejű operációs rendszer (PSE52 IEEE POSIX) Kommunikációs middleware (CORBA and RT-CORBA) Deploymnet middleware (QoS) 22

RT–Middleware RT (Robot-Technology) a JARA (The Japan Robot Association) a METI (Japanese Ministry of Economy, Trade and Industry) és a AIST (National Institute of Advanced Industrial Science Technology) közös fejlesztése. RT-Middleware egy CORBA alapú implementáció. Kihasználva ennek az elosztott middleware-nek számos specifikációját. A prototípust OpenRTM-ben készítették el. 23

Köszönjük a figyelmet!!! 24