Adatgyűjtő és vezérlő rendszer tervezése intelligens üvegházi szabályozásokhoz

Átírás

1 BUDAPESTI MŰSZAKI ÉS GAZDASÁGTUDOMÁNYI EGYETEM MÉRÉSTECHNIKA ÉS INFORMÁCIÓS RENDSZEREK TANSZÉK Adatgyűjtő és vezérlő rendszer tervezése intelligens üvegházi szabályozásokhoz Eredics Péter Konzulens: Dr. Dobrowiecki Tadeusz

2

3 Tartalomjegyzék Tartalomjegyzék 1. Bevezetés Mesterséges környezetek Mesterségesen fenntartott környezetek Az üvegházak Célok, beavatkozási lehetőségek Az automatizálás fejlődése Az informatika helye az üvegházakban Az automatizálás sémája Feladat specifikáció A tesztkörnyezet Célok Az alacsony szintű szabályozás működése Tervezési szintek A második szint bemutatása A szenzor modulok működése A beavatkozó szervek vezérlése A harmadik szint tervezése Bevezetés Topológia A topológia hatása a tervezésre Centralizált rendszer alternatíva Elosztott rendszer alternatíva Logikai rendszerterv Feladatok PC illesztő, alacsony szinten szabályozó egység (SMART) Az asztalokat vezérlő egység (SENSOR) Nem asztali szenzorok és beavatkozó szervek vezérlője (STRONG) Kommunikáció Fizikai rendszerterv Kommunikációs hálózat Mikrokontrollerek A SMART egység A SENSOR egység STRONG Fizikai rendszerterv Kommunikációs protokollok Master-slave megvalósítás Univerzális protokoll Hibadetektálás A COM protokoll A 485 protokoll Szoftver tervek Bevezetés... 30

4 Tartalomjegyzék Programnyelv Konfigurációkezelés Időkezelés Számábrázolás SMART SENSOR STRONG Kalibráció Hibakeresés, tesztelés Általános megfontolások Hibakeresés Tesztelés A magasabb szintek tervezése A magasabb szintek feladatai Bevezetés A magasabb szintek szoftver komponensei A magasabb szintek hardver komponensei Hálózati infrastruktúra Operációs rendszer Az adatbázis Architektúra Az adatbázis mint univerzális kapcsolódási pont Tárolt adatok Saját fejlesztésű alkalmazások Általános megfontolások greenhand greenface greenlog Távoli felhasználói felület Alapvető megfontolások A megvalósítás A felhasználói felület greensite Grafikus adatmegjelenítés - greengrapher Kiegészítő kliens oldali megoldások Befejezés A megvalósítás állapota A végleges rendszertervek Elkészült komponensek Az üzembe helyezés előfeltételei A tervezési döntések értékelése Bevezetés I 2 C szenzor modulok alkalmazhatósága SMART és STRONG egyesítésének lehetősége Az univerzális protokoll Hibás kezdőbitek A SENSOR modulok címbeállítása... 60

5 Tartalomjegyzék Az ATmega8 memória problémái A szenzor modulok folyamatos lekérdezésének hátrányai A hibakeresés hardveres támogatása A konfigurációk módosítása az adatbázisban Összefoglalás Az elkészült rendszer értékelése F. Függelék F.1. Lábkiosztások F.1.1. Bevezetés F.1.2. SENSOR F.1.3. SMART F.1.4. STRONG F.1.5. Állapotjelző LED-ek F.2. A COM protokoll üzenetei F.2.1. Bevezetés F.2.2. Az üzenetek F.3. A 485 protokoll üzenetei F.3.1. Bevezetés F.3.2. Az üzenetek F.4. Tárolt konfigurációk F.4.1. Bevezetés F.4.2. SMART F.4.3. SENSOR F.4.4. STRONG F.5. Állapotvektorok F.5.1. Bevezetés F.5.2. A globális állapotvektor F.6. Debug állapotvektorok F.6.1. Bevezetés F.6.2. SMART F.6.3. SENSOR F.6.4. STRONG F.7. A greendiagnostics segédprogram F.7.1. Bevezetés F.7.2. Hibakeresés, állapot információk F.7.3. Konfigurációk letöltése, szerkesztése F.7.4. EEPROM tartalom olvasás F.7.5. Kalibráció F.8. A greenhand diagnosztikai kimenete F.8.1. Leírás F.8.2. A kimenet F.9. A közös rendszernapló F.9.1. Bevezetés F.9.2. Egy naplórészlet Irodalomjegyzék... 94

6 1. Bevezetés 1 1. Bevezetés 1.1. Mesterséges környezetek Mesterségesen fenntartott környezetek Napjainkban számtalan mesterséges pontosabban mesterségesen fenntartott környezet vesz körül bennünket. Ezek közös jellemzője, hogy a tér egy valamelyest elszeparált részén a külvilágtól eltérő paramétereket (hőmérséklet, páratartalom, nyomás, stb.) tartanak fenn. Méretük nagyon tág tartományban mozoghat: egy egyszerű fűtéssel ellátott akvárium vagy terrárium már képes megfelelő klímát biztosítani trópusi állatoknak. További példaként tekinthetünk egy gépkocsit, ahol téli időben a fűtés, nyáron a légkondicionálás biztosítja az utasok kellemes közérzetét a külső időjárástól független módon. A mesterséges környezetek közé sorolható szinte minden épület, mely a téli fagyok ellenére képes megfelelő klímát biztosítani. Hasonló feladatot látnak el az üvegházak is, melyeket széles körben alkalmaznak a botanikus kertektől kezdve az ipari növénytermesztés számos területéig ábra: Növénytermesztés a Marson (A NASA terve) [1] Mesterséges környezetek új generációja körvonalazódik a láthatáron, amikor a különböző űrmissziók előkészítése folyik: távoli bolygók benépesítésének elengedhetetlen feltétele az emberi táplálék helyszíni előállítása, vagyis a Földön szabadtéren termelhető növények életfeltételeit például egy légkör nélküli, igen nagy hőingadozásokat produkáló távoli bolygó felszínén kell majd megtermelni. Nem szükséges azonban elhagyni a Földet ahhoz, hogy extrém kihívásokkal találjuk szembe magunkat: mélytengeri kolóniák létrehozásától, a sivatagok növénytermesztési célú felhasználásáig számos hasonlóan nehéz feladat vár még az emberiségre. A fizika törvényei alapján a mesterséges környezetek létrehozása, illetve fenntartása energiát igényel. Ez az energia származhat valamilyen kereskedelmi forgalomban kapható energiahordozóból (például földgázból), vagy amennyiben mód van rá, megfelelő tervezés esetén beszerezhető a befogadó környezetből is. Utóbbi megoldás nyilvánvalóan gazdaságosabb, ám megvalósítása nem mindig lehetséges, illetve jelentősen magasabb konstrukciós költségekkel járhat.

7 1. Bevezetés Az üvegházak A továbbiakban a mesterséges környezetek egy szűkebb csoportját, az üvegházakat vizsgálom. Az üvegházak rendkívül hatékonyan képesek felhasználni a napból érkező energiát, hiszen a napfényt az üvegfalak beengedik, ám az így felmelegített levegő kiáramlását meggátolják. Ezáltal a fűtési költségeken komoly megtakarításokat lehet elérni, így az üvegházak hatékony eszközök relatíve hidegebb környezetben melegebb klíma előállítására, amennyiben a napsütés hordozta energia elegendő, illetve a hőmérsékletkülönbség nem túl nagy. Az üvegfalak kiváló fényáteresztő tulajdonsága mellé sajnos nem túl jó hőszigetelő képesség társul. Amennyiben a külső környezet a háznál jobban lehűl, a falakon jelentkező hőveszteség jelentős mértéket ölthet. A jelenség ellen többrétegű üveg használatával, illetve újabban az üveget helyettesítő, hasonlóan átlátszó polikarbonát lapok beépítésével védekeznek. Az üvegházak belsejét kitöltő levegő rossz hővezető képességének köszönhetően a kisebb külső hőingadozásokat tehetetlenségéből fakadóan magától tudja kompenzálni, míg a komolyabb változások hatását késleltetni, tompítani képes. Az éjszakai túlzott lehűlés megakadályozására beépített fűtés jelenthet megoldást, míg a hosszantartó, erős napsütés által előidézett túlmelegedés ellen szellőztetéssel és árnyékolással lehet védekezni. Üvegházakat elsődlegesen növények számára szokás építeni: botanikus kertekben speciális igényekkel rendelkező növények számára, fajtanemesítés során a fiatal növények védelmére, zöldségtermesztés területén a termésidő meghosszabbítására vagy előrehozására, illetve szobai dísznövények nagyüzemi előállítására. A cél minden esetben melegebb klímájú, világosabb környezet létrehozása a napenergia intenzív hasznosítása által ábra: Nagy kiterjedésű ipari üvegház [2] Az üvegházak mérete az eltérő felhasználási célok miatt széles tartományban mozoghat: a legkisebb néhány tíz négyzetméteres kísérleti épületektől, a növények fejlődésének csak kezdeti szakaszát támogató néhány száz négyzetméteres házakon át, a több hektáros, ipari méretű üvegházrendszerekig. Utóbbi nagyméretű rendszereket tipikusan dísznövények és vágott virágok előállítására építik, ahol azt használják ki, hogy a házakban a klíma egész évben megfelelő a növények virágzásához. A továbbiakban az üvegházak legnépszerűbb alkalmazási területét jelentő, növénytermesztési célú házakkal foglalkozom részletesebben.

8 1. Bevezetés Célok, beavatkozási lehetőségek Éghajlatunkon az üvegházak számos beavatkozó szervvel rendelkezhetnek a környezeti paraméterek megfelelő szinten tartása érdekében. Mivel túl magas hőmérséklet mellet a növények könnyen károsodhatnak, ezért ennek elkerülése alapvető fontosságú. A túl alacsony hőmérséklet sem kedvező, mivel lelassítja a fejlődést, ráadásul 0 C alatt már visszafordíthatatlan károsodások következhetnek be, mind a növényekben, mind pedig a vizet használó berendezésekben. A kívánatos érték eltérő lehet nappal és éjszaka, valamint a növények fejlődésének egyes fázisaiban. Amennyiben a kültéri levegő alacsonyabb hőmérsékletű a beltérinél, a nyitható ablakok és oldalfalak segítségével a természetes vagy ventillátorokkal felgyorsított légáramlás által egyszerűen lehűthető a ház. Túl erős napsütésben a besugárzott energiamennyiség csökkentésének érdekében különböző árnyékolási technikák állnak rendelkezésre, a ház külső befestésétől a belső térben elhelyezett mozgatható ernyőkig. A hideg téli időszakban megfelelő fűtésről kell gondoskodni: ez történhet radiátorok segítségével vagy közvetlenül a növények elhelyezésére szolgáló asztalok fűtésével, mely során a hőleadó felületeket az asztalok aljára szerelik fel. A legmodernebb megoldásnak infrasugárzók alkalmazása számít, mivel ilyenkor közvetlenül a növények felszínét lehet melegíteni, vagyis nincs felesleges energiaveszteség például a talaj fűtése által. A hőmérséklet értéke szorosan összefügg a relatív páratartalommal, mely egyrészt a hőmérséklet függvényében változik, másrészt magas páratartalom mellett a növények jobban viselik a meleget. A különböző fajták más-más mértékben igénylik a levegő nedvességét, azonban túl magas érték nem engedhető meg, mivel ez gátolja a felvett víz elpárologtatását, és egyéb növény-egészségügyi problémákat okozhat. A növények vízigényét beépített párásítóés öntözőrendszer elégítheti ki: az öntözés történhet a párásításhoz hasonlóan felülről, a talajon elhelyezett csövekből, vagy akár hidrokultúra módszerével is. Utóbbi esetben a növényeket táptalaj nélkül nevelik, gyökereik között folyamatosan tápoldatot áramoltatva. A növények fejlődéséhez szükséges a megfelelő megvilágítás, mely az üvegház adottságai alapján történhet napközben természetes fénnyel, amit szükség esetén mesterséges fényforrásokkal egészítenek ki a reggeli és esti órákban. A megvilágítás hosszának és intenzitásának egyaránt fontos szerepe lehet. Például az úgynevezett hosszúnappalos növények csak 12 óránál hosszabb nappalok (világos időszakok) mellett hoznak virágot Az automatizálás fejlődése Az eddigiekben ismertetett beavatkozó szerveket az üvegházak fejlődésének kezdeti szakaszában kézzel működtették. A személyzet feladata volt az ablakok mozgatása, az árnyékolás megoldása, és a megfelelően gyakori öntözés vagy párásítás. A technika fejlődése során ezeket a feladatokat lassanként motorok és elektronikusan szabályozható szelepek vették át, így minden eszközt egy központi vezérlő tábláról működtettek. Ez már jóval kevesebb emberi erőforrást igényelt, azonban a rendszeres személyes jelenlétet még nem váltotta ki. A kapcsolótáblán általában egyszerű műveleteket hajtottak végre, például a ház melegedése esetén aktiválták az árnyékolást, vagy a szellőztetést. Lehűlés esetén a feladat fordított volt, illetve egy bizonyos szint alatt már a fűtés bekapcsolása is szükségessé válhatott. E vezérlő beavatkozások igen könnyen automatizálhatóak voltak, így egyszerű SSI alkatrészek illetve mikrokontrollerek segítségével nemsokára elkészültek az emberi jelenlétet teljesen kiváltó szabályozások. Ezek általában egy mért hőmérsékleti érték függvényében hajtanak végre különféle beavatkozásokat, pontosan olyan elvek alapján, ahogy azt a kezelőszemélyzet korábban a kapcsolótábla segítségével tette. (Ilyen elven működik például a Micro Grow Greenhouse Systems rendszere, a Growmaster [3]).

9 1. Bevezetés ábra: A Growmaster vezérlőegysége [4] Az utóbbi időkben terjedtek el a számítógépekkel összekapcsolt üvegházi vezérlések, melyek azonban az adatok távoli megjelenítésén illetve archiválásán túl nem nyújtanak sokkal többet elődeiknél. Működési elvük még mindig nagyon egyszerű, mivel a mért hőmérséklet függvényében szabályokkal leírható beavatkozások végrehajtásán alapul. (Ilyen szolgáltatásokat nyújt például az Argus Control Systems cég Argus nevű vezérlőrendszere [5].) Az informatika helye az üvegházakban Mint a korábbiakban bemutatott számítógépes vezérlésekkel kapcsolatban már megjegyeztem, ezek nem jelentettek igazi előrelépést az őket megelőző, jóval egyszerűbb megoldásokhoz képest. Az autóiparral összehasonlítva az üvegházak automatizálását, megfigyelhető, hogy a számítógépek beépítése a gépkocsik esetében minőségileg új szolgáltatások megjelenését eredményezte. Az elektronikus vezérlésű fékrendszer például nem pusztán a vezető által a pedálra ható erőt közvetíti digitális jelek formájában a tényleges beavatkozás helyére, hanem az emberi döntést esetenként felülbírálva olyan bonyolult feladatokat is képes ellátni, mint a blokkolásgátlás (ABS) [6] vagy az elektronikus menetstabilizálás (ESC) [7]. Az autóiparban számos további példa található arra, hogy a számítógépek formájában megjelenő számítási teljesítmény segítségével új, jobb szolgáltatásokat képesek nyújtani felhasználóik számára. Ilyen jellegű generációváltás az üvegházak esetében mindezidáig várat magára. Megfigyelhető, hogy a számítógépek egyszerűen átvették a mikrokontrollerek feladatait, azokat mindössze néhány triviális funkcióval mint az adatok rögzítése vagy a távoli hozzáférés biztosítása kiegészítve, azonban a szabályozás terén nem születtek minőségileg új megoldások [8]. Ez a tendencia egyébként nem különösebben meglepő. A bevált szabályozási módszerek a megrendelők igényeit kellőképpen kielégítik, és a nagyobb számítási kapacitásra képes, ezáltal bonyolultabb hardver és szoftver komponensek olyan megbízhatósági kérdéseket vetnek fel, melyek korábban nem jelentkeztek. Könnyen belátható azonban, hogy a megbízhatósági problémák megoldása után rendelkezésre álló számítási teljesítményt fel lehetne használni az üvegházak vezérlése során, hiszen így lehetőség nyílna nagyszámú mérési adat összegyűjtésére, kiértékelésére. Példaként tekintsük az alábbi, újszerű vezérlési megközelítést.

10 1. Bevezetés 5 A mérési adatok tükrében az üvegház egy számítási modellje futási időben létrehozható, vagyis minden olyan üvegházra, amiben ilyen rendszer üzemel, egy tanulási folyamat segítségével önálló modell határozható meg, mely az adott környezethez a leginkább illik. A modell megalkotása történhet teljesen általánosan, illetve élhetünk bizonyos előfeltevésekkel. Amennyiben semmit nem tételezünk fel a modell alakjával kapcsolatban, akkor a tanulási folyamat jóval lassabban konvergál majd, mintha bizonyos apriori tudást bevinnénk a modelltanulás folyamatába. Célszerű tehát a modell vázát beépíteni a tanuló eljárásba, és a működés során mindössze a váz helyes paraméterezését keresni. Mivel az üvegház egy fizikai rendszer, így a benne zajló folyamatok leírhatók a termodinamika törvényeivel. Ezek alkalmazásához célszerű a házat zónákra osztani, mely zónák hőmérsékleti szempontból homogénnek tekinthetők, míg a zónák közötti eltérések megengedettek. Triviális felosztás két zónát alkotni a belső és a külső térből, azonban az üvegház konkrét felépítését figyelembe véve finomabb felosztás is létezhet. A zónák segítségével, határaikra felírva a hőátadási folyamatokhoz (hőátadás, hővezetés, hőáramlás, hősugárzás) tartozó összefüggéseket, azonnal adódik a modell alakja, melyhez már csak a helyes paraméterezést kell meghatározni. A működés folyamán a belső körülmények változása nem ritka esemény, például a kihasználtság ingadozása miatt a ház egyes részei leválasztásra kerülhetnek, illetve a növények növekedésével is számolni kell. A megváltozott körülményekhez a modell létrehozásában szerepet játszó tanulási folyamat önállóan képes alkalmazkodni. Az ilyen módon karbantartott modell a későbbiekben felhasználható a beavatkozások hatásainak becslésére, vagyis a döntéseket immáron nem kizárólag a pillanatnyi helyzet alapján kell meghozni, hanem várható hatásukat mérlegelve választhat a rendszer a rendelkezésére álló lehetőségek közül. A beavatkozást követően az új mérési adatok megfigyelése által a korábbiakban felépített modell pontosítható. Amennyiben a beavatkozás hatása egyáltalán nem, vagy nem a várt formában jelenik meg, bizonyos meghibásodásokra következtetni lehet, így a szükséges kárelhárító intézkedésekről azonnal döntés születhet. Ez azonban még nem minden. Amennyiben a döntések kimenete a modell segítségével jósolható, akkor a döntési pillanatokban több lépéses terveket is fel lehet vázolni, majd ezek közül kiválasztani a legoptimálisabbat, és ennek kezdő lépését végrehajtani. E megoldás lehetővé teszi, hogy a rendszer pillanatnyi döntésként a hosszú távon legjobb beavatkozást válassza, így minimalizálva a működési költségeket. Ez a mechanizmus nem sokban tér el az emberi kezelőszemélyzet által a kapcsolótáblán végzett beavatkozások stratégiájától, mivel ott is a pillanatnyi helyzet ismeretében a jövőről valamilyen hozzávetőleges, emberi becslés alapján hozták meg az egyes döntéseket. (Például a személyzet biztosan nem nyitotta ki egy tavaszi estén az ablakokat még akkor sem, ha a hőmérséklet néhány fokkal a kívánt szint felett volt, mivel ezáltal éjszaka hamarabb szükségessé vált volna a fűtés bekapcsolása.) A modell alapján létrehozott jóslatok pontossága természetesen sok tényező függvénye. A külső időjárás változásait mindenképpen figyelembe kell venni az előrejelzések készítése során, sőt az egyes napszakokban eltérő mennyiségű megvilágítás sem hanyagolható el. E hatásokon kívül a jóslás helyességére komoly negatív hatással lehet a modell pontatlansága, így törekedni kell a valóságot a lehető legjobban közelíteni. A már ismertetett okokból kifolyólag a ház modellje folyamatos változásban van, így az tervezési időben semmiképpen nem határozható meg a szükséges pontossággal, tehát lehetőségként útként a vázolt tanuló, alkalmazkodó modellalkotás megvalósítása marad. A fentiekben ismertetett szabályozási megoldás egyelőre csak elvi síkon létezik, és nagyon könnyen felismerhető benne számos igen erős exponenciális probléma, mint például a potenciális tervek megalkotásának és kiértékelésének feladata. Sajnos már a korábbi fázisokkal kapcsolatban is sok kérdés merülhet fel: Mennyire lehet, illetve kell pontosnak lennie egy ilyen dinamikusan létrehozott (felparaméterezett) modellnek, melyet szükségszerűen zajos mérési adatok alapján készítünk el? Mekkora számítási igénye van egy

11 1. Bevezetés 6 ilyen rendszernek? Milyen hosszú betanulási időszakot igényel a modell elfogadhatóan pontos meghatározása, illetve képes-e a változásokat kellően gyorsan követni? Ahhoz, hogy a kérdésekre válaszokat kaphassunk, először szükség van nagyszámú, valós környezetbeli mérési adatra. Sajnos ezeket szimuláció segítségével nem lehet előállítani, mivel a szimulációk szükségszerűen egyszerűsített modellekkel dolgoznak, melyekből éppen a pillanatnyilag érdekes, apró részletek maradhatnak ki. Így tehát szükség van egy valós környezetben elhelyezett mérőrendszerre az adatok begyűjtéséhez, melyek segítségével már kísérleti körülmények között győződhetünk meg a modell tanulhatóságáról, illetve az adatokkal együtt érkező zaj segítségével az így előálló modell pontosságáról. Második lépésben a szabályozó algoritmusok implementálása után nélkülözhetetlen a kész rendszer valós környezetbeli tesztelése, illetve összehasonlítása a hagyományos szabályozási megoldásokkal annak bizonyítására, hogy az elméletileg elérhető pozitív tulajdonságokat a gyakorlatba is sikerült átültetni Az automatizálás sémája Ez előzőekben felvázolt új automatizálási megközelítést alkalmazó megoldás a továbbiakban magas szintű automatizálásnak nevezett eljárás önmagában sajnos nem elegendő egy üvegház teljes körű, megbízható működtetésére. Mint már említettem a bonyolult tervkészítő és modellalkotó algoritmusok az exponenciális komplexitások kezelésére komoly számítási teljesítményt igényelnek. Ezek az erőforrások napjainkban legegyszerűbben PC-k vagy ipari számítógépek képében állnak rendelkezésre, melyek megbízhatósága összetett felépítésüknek, mozgó alkatrészeiknek, illetve számos hardverszoftver komponensüknek köszönhetően nem teljesen kielégítő. Egy üvegházban, ahol több tízmillió Forint értékű növényt nevelnek, nem fogadható el a számítógépek által így behozott kockázat. Ebből kifolyólag a magas szintű szabályozó algoritmusok alá szükségszerű bevezetni egy alacsonyabb szintet, mely a felső kiesése esetén képes annak rövidtávú feladatait kielégítő módon ellátni. Egy ilyen szint létrehozása számos egyéb előnnyel is jár, mivel megfelelő tervezés esetén a két szint hierarchikusan épülhet egymásra, vagyis felül nem szükséges az alul nyújtott szolgáltatások ismételt implementációja. Az alacsony szint fentiekben meghatározott feladata tehát igen egyszerű: kielégítő rövid távú szabályozást nyújtani a modellalapú szabályozástól függetlenül, illetve a magas szint működése esetén egy köztes réteg formájában kiszolgálni azt. Ehhez célszerű úgy megvalósítani, hogy (1) minden szükséges mérést el tudjon végezni, (2) a mérési adatokat a magas szint által elérhető helyen tárolja, (3) minden beavatkozást végre tudjon hajtani, és (4) a magas szinttől beavatkozó utasításokat fogadhasson, melyeket az érintett szervek felé továbbít. Az eddigiekben vázolt rendszer meglehetősen bonyolult, így célszerű több különálló fázisban megvalósítani. Az első fázis célja a szenzorok és a beavatkozásokat vezérlő hardverés szoftverkomponensek létrehozása, valamint az alacsony szintű szabályozás implementálása. A következő szakasz során a már rendelkezésre álló mérési adatokat felhasználva a modell, illetve az ezt használó magas szintű szabályozó algoritmusok tervezése következhet. A két szabályozási szint elkészülte után a harmadik fázisban kiegészítő szolgáltatások implementálására kerülhet sor. Ilyen kiegészítő funkció lehet az ingyenesen elérhető időjárás előrejelzések kiértékelése, és az így kapott prognózisok beépítése a tervezési folyamatba. Egy másik lehetséges szolgáltatás modellkönyvtárak létrehozása, mely könyvtárakból a modell egy-egy korábban lementett állapota tölthető vissza a működő rendszerbe. Ez lehetővé teszi egy esetleges téli üzemszünet után az előző évben lementett tavaszi modell visszaállítását, így elkerülve az ismételt tanulási folyamat kezdetén nagy valószínűséggel jelentkező

12 Szenzorok Beavatkozók Modellkönyvtár Alacsony szintű szabályozás Időjárás előrejelzés 1. Bevezetés 7 pontatlanságokat. A fejlesztés kezdeti fázisaiban felmerülő új igények, illetve a felhasználóktól érkező visszajelzések alapján a harmadik fázis funkcionalitása még bővülhet. Az automatizálás eddigiekben ismertetett sémája az alábbi ábrán látható. parancsok Magas szintű szabályozás Üvegház mérések Modell Felhasználói felület 1. fázis 2. fázis 3. fázis 1.4. ábra: Az automatizálás sémája Az ábrán szerepel az eddig még nem említett felhasználói felület, mely mindhárom fázishoz szorosan kapcsolódik. A felhasználó természetes elvárása, hogy a ház pillanatnyi illetve korábbi állapotával kapcsolatban tájékozódni tudjon. Ezen kívül a felhasználói felületen keresztül van lehetősége az alacsony szint esetén a működtető paramétereket megadni (például, milyen hőmérséklet alatt kapcsoljon be a fűtés?), illetve a magas szint esetén a célokat specifikálni (a szabályozás feladata lehet például 21 fokot előállítani és tartani a házon belül minimális költségek mellett). E dolgozat az első fázis megvalósítását követi végig Feladat specifikáció A tesztkörnyezet A mérési adatok begyűjtésére, illetve az eredmények valós környezetbeli tesztelésére lehetőség van a rendszert egy konkrét üvegházban kísérleti jelleggel üzemeltetni. Ez a ház 100 m 2 alapterületű, tehát relatíve kicsi, ami a felműszerezési költségeket kezelhető szinten tartja. Az üvegházban a növények 18 mozgatható asztalon helyezkednek el, mely asztalok felülete az alapterület nagyjából 90%-át fedi le. Az üvegházban az év nagy részében fiatal mikroszaporított növények nevelése folyik. A mikroszaporítás egy modern alternatíva a magvetéssel szemben, melynek során a szaporítandó növényről egy hajtást leválasztanak, azt hormonokkal kezelik, majd gyökereztetik. A mikroszaporítás széles körben elterjedt megoldás hagyományos módon nehezen szaporítható növények esetében, illetve új fajták tömeges, gyors bevezetésekor. Tipikusan így szaporítják az orchidea fajtákat, a gerberát vagy az újonnan nemesített szamócákat [9].

13 1. Bevezetés 8 A módszer ismeretében könnyű megérteni, hogy a mikroszaporított növények sokkal kényesebbek a környezeti paraméterekre, mivel fejlődésük kezdeti szakaszában semmilyen gyökérzettel nem rendelkeznek. Így az sem meglepő, hogy az említett üvegház jelentős automatikával, illetve számos speciális (az átlagos dísznövény- vagy zöldségtermelő üvegházakban nem alkalmazott) beavatkozó szervvel rendelkezik. Az alábbiakban röviden ezeket mutatom be. Felső ablakok: A felső ablakok a ház tetejének nagyjából negyedét foglalják el. Mozgatásuk egy központi motor segítségével történik. Az ablakok rendelkeznek végállás kapcsolóval, illetve egy érzékelővel, mely 33%-os nyitottság esetén jelez, vagyis a 0%, 33% és 100% állásba lehet őket könnyen (hardverrel támogatott módon) vezérelni. Oldalsó ablakok: Az üvegház elején egy, a végén két nyitható oldalsó ablak található. Ezek jelenleg nem motorizáltak, így a személyzet beavatkozása szükséges mozgatásukhoz. Pillanatnyi állapotuk az első ablakon elhelyezett mikrokapcsoló segítségével lekérhető. (Az ablakok az esetek legnagyobb részében egyszerre nyitottak vagy zártak, így egy érzékelő elegendő.) Árnyékoló ernyő: A ház teljes üvegfelületét belülről egy motorral mozgatható árnyékoló ernyő fedi. Ez mint általában az ilyen ernyők speciális szövetanyagból készült, melybe fémszálakat helyeztek hő- és fényvisszaverő képességének javítása érdekében. Az ernyő két végállás kapcsolóval közvetlenül visszahat a mozgató motorra, illetve rendelkezik egy érzékelővel, mely 90%-os fedés esetén jelez, így a 0%, 90% és 100%-os fedettség érhető el könnyen (hardveres támogatással). A 90%-os fedési állásra azért van szükség, hogy az ablakok hűtő hatása az ernyő behúzott állapota mellett is érzékelhető legyen a ház belsejében. Fűtés: A fűtés szerepe különösebb magyarázatot nem igényel: a feladatot egy gázkazán látja el. Útpárásítás: A ház belső légterének aktív hűtésére szolgáló eszköz az útpárásítás: a betonlapokkal fedett közlekedő út szórófejekkel történő nedvesítése a víz párolgása által elvont hő miatt segít a felmelegedés fékezésében. A szórófejeket be illetve ki lehet kapcsolni egy elektromos vezérlésű szelep segítségével. Felső párásítás: A növényeket a legtöbb üvegházban a könnyű munkavégzés érdekében asztalokon helyezik el. A konkrét üvegházban a mikroszaporítás technológiájából származó komoly páratartalom igény miatt ezek az asztalok egy átlátszó fóliával lefedhetők a nedvesség benntartása érdekében. Az idősebb növényekről az úgynevezett edzési folyamat keretében egy idő után lekerül a fedés, vagyis közvetlenül az üvegház belső légterébe kerülnek át. Az ilyen növények párásítás és öntözés igényét hivatott kielégíteni az felső párásítás, az asztalok felett elhelyezett szórófejekkel, melyek az útpárásítással azonos módon de attól függetlenül vezérelhetőek. Ultrahangos párásítás: A fedett asztalok párásításának feladatát az asztalok belsejébe csöveken bevezetett hideg pára látja el. Ez a rendszer bevezetés alatt áll az említett üvegházban. A pára előállítását kiskereskedelmi forgalomban is kapható, ultrahangos légnedvesítő készülékek látják el, melyek két asztalonként kerülnek felszerelésre. A beavatkozó szerv elnevezése ultrahangos párásítás, utalva arra, hogy az eszközök a vizet ultrahang közeli frekvenciával rezegtetve érik el a vízmolekulák intenzív leválását a felülettől, vagyis a hideg pára képződését. Asztalszellőztetés: Az asztalok túlmelegedésének csökkentésére egy ventilátor pár is felszerelésre került, melyek néhány perces működéssel képesek az asztalokat kiszellőztetni. A légcsere mellékhatásaként megfigyelhető ilyenkor a páratartalom drasztikus csökkenése, melyet a szellőztetés után az ultrahangos párásítással lehet pótolni. Egyéb beavatkozó szervek és érzékelők: Az oldalsó ablakokhoz hasonló, a személyzet által mozgatott, szellőztetési célokra is alkalmas eszköz az ajtó, melynek nyitottságáról egy mikrokapcsoló szolgáltat adatokat. A házhoz tartozik egy csapadékérzékelő, mivel az ablakokat eső esetén azonnal be kell zárni. (Az érzékeny növényekben komoly kárt tehet a

14 1. Bevezetés 9 csapadékkel együtt esetlegesen érkező jég, illetve a légszennyezettség következtében savas kémhatású eső is igen ártalmas lehet.) A tetőről lefolyó csapadékot elvezető csatornák fűtőszálakat tartalmaznak, így lehetőség van télen az összegyűlt hó gyors leolvasztására a bejutó fény maximalizálásának érdekében Célok A cél egy olyan rendszer létrehozása az előzőekben bemutatott üvegházban, melynek segítségével kényelmesen és hatékonyan lehet magas szintű szabályozási algoritmusokat fejleszteni és tesztelni a valós környezetben. A fejlesztés kezdeti lépéseinek támogatásához nagy mennyiségű mérési adatra van szükség, melyek alapján a ház működése, környezeti viszonyai alaposan megismerhetőek. Az ilyen adatok alapján elméletileg meg lehet alkotni az üvegház termikus modelljét, mely később a beavatkozások tervezésének alapját adhatja. A módszer ismertetésekor már említettem, hogy a ház hőmérsékleti szempontból heterogén belső légterét célszerű egyenként homogénnek tekinthető zónákra osztani, majd ezek kölcsönhatásait közelíteni a tanuló algoritmus segítségével. A konkrét üvegház esetében négy zóna kialakítására van mód. Az első, a fólia fedél által elszigetelt asztalok belseje, mely a szabályozás szempontjából kiemelt fontosságú, hiszen itt helyezkednek el a növények. Amennyiben az adott asztalon éppen úgynevezett edzett növények vannak melyek az edzési folyamat során a külvilághoz szoktatásuk érdekében már nincsenek lefedve, akkor az első zóna nem különíthető el a másodiktól, mely a ház belső légterének az árnyékoló ernyő alatti részét jelenti. A harmadik zónát a zárt ernyő és az üveg közötti rész alkotja. Amennyiben az ernyő nem árnyékol a két középső zóna egynek tekinthető. Az utolsó, negyedik zónának a házon kívüli, szabadtéri levegő tekinthető, mely az üvegfalakon keresztül, és a szellőztetések alkalmával érintkezik a belső légtérrel. Árnyékoló ernyő 4 Felső ablak 3 Bejárat 2 Üvegfal 1 Fedett asztal Fedetlen asztal 1.5. ábra: Az üvegház zónafelosztása Hőszigetelő fal Az 1. zónát alkotó asztalokon mindenhol mérni kell a hőmérsékletet és a páratartalmat. Utóbbi a két asztalonként elhelyezett ultrahangos párásítás vezérléséhez kell, míg előbbi a termikus modell tanulásához nélkülözhetetlen. A 2. zónán belül két helyről kell hőmérsékleti adatokat gyűjteni, mivel a ház egy része alacsony kihasználtság esetén a téli időszakban a fűtési költségek mérséklése érdekében leválasztható, így az üres részben csak a fagy megelőzés a feladat. Szükséges még ebben a zónában egy páratartalom és egy megvilágítás érték regisztrálása is. Előbbi az útpárásítás

15 1. Bevezetés 10 vezérlését befolyásolja, hiszen ha a megnedvesített járólapokról a víz már nem képes elpárologni, akkor nem érdemes a szórófejeket működtetni. A megvilágítás mért alapján a magas szintű szabályozás a besugárzott energia mennyiségét becsülheti meg. A 3. zónában, az ernyő felett kizárólag hőmérsékletet kell mérni, míg a 4. zónát alkotó kültéri érzékelőknek a hőmérsékleten kívül megvilágítási adatokat is szolgáltatniuk kell. Utóbbi felhasználása hasonló a 2. zónában mért megvilágítási értékhez. Szükség van továbbá a fűtéscsövek hőmérsékletének mérésére, melynek ismeretében a kazán vezérlése gazdaságosabbá tehető. Elmondható tehát, hogy a megvalósítandó rendszer egyik fontos célja a mérési adatok összegyűjtése. A mért értékek beérkezése után az adatokat rendszerezetten kell tárolni oly módon, hogy azok könnyen hozzáférhetők legyenek más programok (például a fejlesztés alatt álló szabályozó algoritmusok) számára, akár távolról is. A távoli elérés lehetővé teszi, a szabályozások fejlesztését illetve futtatását külön dedikált számítógépeken, ami az előreláthatóan erős exponenciális komplexitások miatt előnyösnek kínálkozik. Amennyiben a begyűjtött mérési adatok alapján a későbbiekben elkészítendő szabályozási megoldások már kielégítően működnek, újabb igényként jelenik meg ezeknek az algoritmusoknak a valós környezetbe helyezése. Erre a célra egy olyan felületet kell készíteni, melyen keresztül ezek a programok az aktuális mérési eredmények elérésén túl beavatkozó parancsokat is ki tudnak adni, továbbá e parancsok rövid időn belüli végrehajtása garantált. A szabályozások tesztelése során nem szabad megfeledkeznünk arról, hogy az üvegházban egész évben folyamatos termelés zajlik. A nevelt növények piaci értéke milliós nagyságrendű, így egy hibás szabályozás okozta túlmelegedés vagy fagykár komoly veszteséget okozhat. Talán jogosan feltételezhető, hogy az éppen tesztelés alatt álló szabályozó eljárás működése közben elhárítja az ilyen helyzeteket. Erre az adott programban a fejlesztőnek kell megfelelő garanciákat adnia. Azzal a problémával azonban foglalkozni kell, hogy mi történjen, ha a magas szintű szabályozás meghibásodik (lefagy) vagy (távoli gépen futó szabályozási algoritmus esetén) kapcsolata az üvegházi rendszerrel megszakad. Tekintettel arra, hogy a számítógépek (és a PC-k különösen) nem megbízhatóak, könnyen el lehet képzelni a szabályozást futtató gépen mind hardver, mind pedig szoftver meghibásodást, melynek hatására az üvegház vezérlés nélkül marad. Ez egy tipikus nyári reggelen amikor az árnyékoló ernyő nem fed, illetve az ablakok sincsenek még nyitva - órákon belül a ház túlmelegedéséhez, ezáltal pedig a növények tömeges elpusztulásához vezethet. Az ilyen jellegű esetek elkerülése érdekében szükség van az alacsony szintű (vész)szabályozás kidolgozására, mely a magas szint elvesztése esetén kielégítő módon átveszi annak szerepét. Az elkészítendő rendszer funkcionalitásával kapcsolatos elvárások tehát az alábbiakban foglalhatók össze: 1. Rendszeres időközönként rögzítse az üvegház összes szükséges paraméterét. 2. A mérési adatokat tárolja úgy, hogy ahhoz a felhasználó illetve a magas szintű szabályozás is kényelmesen, távolról hozzáférhessen. 3. Biztosítson felületet a magas szintű szabályozás számára, melyen keresztül az parancsokat adhat a beavatkozó szerveknek. 4. A magas szint hiánya esetén nyújtson kielégítő alacsony szintű szabályozást Az alacsony szintű szabályozás működése A megtervezendő alacsony szintű szabályozással szemben mindössze az az egyszerűnek tűnő elvárás támasztható, hogy a házat a magas szint hibája esetén megfelelő állapotban tartsa. Tekintettel azonban arra, hogy a magas szintet gátló (hardveres) hiba elhárítása (például pótalkatrész beszerzése miatt) sokáig húzódhat, könnyen belátható, hogy az alacsony szinten gyakorlatilag egy komplex, önálló szabályozásra van szükség.

16 1. Bevezetés 11 További érv a teljes értékű alacsony szintű szabályozás tervezése mellett, hogy a magas szint elkészülte előtt, illetve az egyes tesztelési időszakok között is működtetni kell az üvegházat. Ez a tény egyben pozitívum is, mivel a vész szabályozás intenzív használata (nem vészhelyzetekben) biztosítja azt, hogy az a későbbiekben egy esetleges éles szituációban is megfelelően fog működni. Az alacsony szinttel kapcsolatban legalább annyi elvárás van, mint egy egyszerűbb piaci szabályozással szemben. A működés során szükség van egy mért értékre a továbbiakban referencia hőmérséklet, illetve számos paraméterre, melyek segítségével a felhasználó specifikálhatja, hogy a referencia hőmérséklet függvényében milyen állásba kerüljön az ablak, az ernyő és a többi beavatkozó szerv. Ez a megoldás ugyanolyan egyszerű elven működik, mint a legtöbb piaci forgalomban kapható szabályozás. Az alábbiakban röviden ismertetem az alacsony szintű szabályozás működési elvét az egyes beavatkozó szervek esetén. Ablakok: A szabályozható ablakoknak, mint említettem három lehetséges állásuk van. Az ablakok vezérlése a következő négy hőmérséklet érték alapján történik: a 33%-ra nyitás hőmérséklete, a 100%-ra nyitás értéke; a 33%-ra zárás szintje és végül a 0%-ra záráshoz tartozó adat. Árnyékoló ernyő: Hasonló megfontolások alapján az árnyékoló ernyő hőmérsékletfüggő mozgatását a három állapot miatt szintén 4 érték határozza meg. Az üzemeltetők kérése alapján a kezelőszemélyzet tehermentesítése érdekében az ernyők vezérlésével kapcsolatban egy további kényelmi funkció megvalósítása is szükséges: lehetőséget kell biztosítani egy időtartomány megadására, amíg az ernyő garantáltan árnyékol (a továbbiakban fix árnyékolás), illetve egy másik időtartomány rögzítésére, ami alatt az árnyékolás biztosan szünetel (fix nem árnyékolás). Az, hogy e két beállításra is igény van, jól szemlélteti az általános szabályozási megoldások komoly hiányosságait. A fix árnyékolás igénye a téli időszakban merül fel, amikor naplemente után (noha a hőmérséklet még nem csökkent a beállított szint alá) a besugárzás megszűnése miatt célszerű a kisugárzott energiát minimalizálni az ernyő árnyékoló állásba kapcsolásával. A fix nem árnyékolás funkciója hasonló, szintén télen, napfelkelte után, amikor a belső hőmérséklet még alacsony az árnyékolás megszüntetéséhez, ám a felkelő nap fényét már érdemes beereszteni. Fűtés: A fűtés vezérlése során (annak két állapota miatt) két paraméter szükséges, melyek egy egyszerű hiszterézises szabályozót határoznak meg. Útpárásítás: Az útpárásítás intenzitásának állítása az üzemeltetők igényeit felmérve négy lépcsőben történhet. A legalacsonyabb szinten a párásítás ki van kapcsolva. Az 1., 2. és 3. szinthez tartozik egy küszöbhőmérséklet, egy működési idő és egy várakozási idő. Például abban az esetben, amikor a referencia hőmérséklet a 2. és 3. küszöb közötti értéket vesz fel, akkor az útpárásítás a 2. szint működési ideje által meghatározott ideig bekapcsolt állapotban van, majd a 2. szint várakozási idejének megfelelő ideig kikapcsolt állapotban várakozik. Felső párásítás: Az asztali felső párásítás az útpárásítással teljesen azonos módon működik, ám paraméterei attól függetlenül állíthatóak. Ultrahangos párásítás: Az ultrahangos párásítás feladata, hogy a fedett asztalok megfelelő páratartalmáról gondoskodjon. Amennyiben a mért páratartalom a megadott szint alatt van, akkor be kell indítani az ultrahangos párásítást. Ha a páratartalom a párásítás működése ellenére sem éri el a kívánt szintet, akkor egy megadott működési idő után a párásítót le kell állítani. Ezt követően egy szintén adott várakozási idő letelte után lehet csak újraindítani. A várakozási időt az út- és a felsőpárásításhoz hasonlóan három intenzitási szinten külön-külön lehet állítani. Asztalszellőztetés: Az asztalszellőztetés igénye az ultrahangos párásítás kifejlesztése után merült fel, korábban ugyanis a személyzet naponta egy-két alkalommal a párásítás idején eltávolította a fedett asztalokról a fóliát, így kicserélődhetett a fülledt levegő. Az új párásítási módszer már nem igényel manuális beavatkozást, így az asztalok alkalmankénti

17 1. Bevezetés 12 szellőztetésére más módot kellett találni. A szellőztetés megvalósítására beépítésre került asztalonként két ventillátor. A manuális szellőztetés analógiájára az asztalszellőztetést naponta legfeljebb három alkalommal, rögzített időpontban kell bekapcsolni. Ezen kívül az forró nyarak tapasztalatai alapján amikor a ház belső hőmérséklete 45 C, egyes asztalok hőmérséklete 55 C fölé melegedett hasznos lehet az asztalokat bizonyos időintervallumonként rendszeresen kiszellőztetni. Erre a személyzet igényeinek megfelelően a szabályozásnak három fokozatban kell lehetőséget biztosítania: a szellőztetési idő mindig azonos, hiszen a teljes légcsere ideje csak a ventillátorok teljesítményétől függ. A szellőztetések közötti várakozási idő a hőmérséklet emelkedésével célszerűen csökkenthető. Mint korábban említettem a szellőztetés hatására jelentősen leeshet az asztalok páraszintje, ezáltal célszerű a szellőztetés után az asztali párásítást szükség esetén azonnal beindítani. Riasztás: Igen hasznos funkcióként lehetőséget kell biztosítani arra, hogy a felhasználók az üvegház bizonyos paramétereinek függvényében riasztást rendelhessenek el. Jelen esetben az üzemeltetők kívánságainak megfelelően, jelezni kell a ház túlmelegedését vagy lehűlését (egy bizonyos belső hőmérsékleti érték meghaladását), a beavatkozó szervek meghibásodását, valamint az ultrahangos párásító egységek kiürülését Tervezési szintek Az első fázisban megvalósítandó rendszer bonyolultságának csökkentése érdekében célszerű azt egymástól jól elkülöníthető szintekre bontani, majd a továbbiakban ezeket önállóan vizsgálni. Az 1. szint az üvegház fizikai világa. Itt kerül kiépítésre a 2. szintet alkotó, szükséges számú érzékelő, illetve beavatkozó szervet vezérlő áramkör. Az 1. és 2. szinteket a tervezés során, a továbbiakban adottságként kezelem, mivel a ház paraméterein nem lehetséges változtatni, illetve a szenzor és beavatkozás vezérlő áramkörök kialakítása már korábban megtörtént. A 3. szinten helyezkedik el a szenzorok és beavatkozó szervek vezérlése, melynek megvalósítása már e dolgozat tárgyát képezi. A szint feladata megfelelő interfészt képezni a felette elhelyezkedő komponensek számára, megszabadítva azokat a szenzorok rendszeres lekérdezésének és a beavatkozó szervek közvetlen működtetésének feladatától. Itt kerül megvalósításra az alacsony szintű szabályozás is, ezáltal rendelkezésre állása megközelítheti a szenzorok és beavatkozó szervek rendelkezésre állását. Felhasználói felület Magas szintű szabályozás Adatrögzítés és tárolás Szenzor és beavatkozás vezérlés Felműszerezés: szenzorok és beavatkozó szervek Fizikai világ (az üvegház) 5. szint 4. szint 3. szint 2. szint 1. szint 1.6. ábra: Tervezési szintek A 4. szint feladata a mérési adatok begyűjtésén és hosszú távú tárolásán túl, megfelelő csatlakozási felület biztosítása a felette elhelyezkedő komponensek számára. Ezt célszerű

18 1. Bevezetés 13 hálózati kapcsolaton keresztül távoli számítógépek felé is biztosítani. Az alacsonyabb szintekkel kapcsolatban a cél minél jobban kihasználni a rendelkezésre álló erőforrásokat, például több üvegház önálló harmadik szintjének együttes kiszolgálása által. Az 5. szinten helyezkedik el a felhasználói felület, illetve a későbbiekben kifejlesztendő magas szintű szabályozás. A felhasználói felület az esetleges különleges helyzetektől eltekintve konkrét működtető funkciót nem lát el, az alatta lévő szintek tőle függetlenül működőképesek. Hasonlóképpen a magas szintű szabályozás sem kritikus a rendszer üzemelése szempontjából, hiszen feladatait a 3. szinten implementált alacsony szint szükség esetén bármikor átveheti A második szint bemutatása A szenzor modulok működése A szenzor modulok elkészítése során 1 fontos szempont volt, hogy az egyes érzékelők viszonylag hosszú vezetékeket képesek legyenek meghajtani annak érdekében, hogy az asztalok mozgatása során a kábelezés ne jelentsen akadályt. A vezetékek végén elhelyezett rezisztív elven működő érzékelők pontosságát nagymértékben rontotta volna a vezetékek által a környezetből összeszedett zavarás, így a szenzorok jelét célszerű volt már ezen a szakaszon is digitális formában továbbítani. Annak érdekében, hogy az analóg digitális átalakítás ne igényeljen komolyabb hardver elemeket (ezáltal minimális helyigényű és fogyasztású legyen), illetve az adatátvitel is a legegyszerűbben történjen, a szenzor modulok a következő elven működnek. Minden modulhoz két rezisztív elven működő érzékelő alkatrész csatlakozik, melyek ellenállásukat az egyes környezeti paraméterek függvényében változtatják. A mért környezeti paraméter esetünkben hőmérséklet, páratartalom vagy megvilágítás, de a lista a későbbiek során tetszőleges azonos elven működő alkatrésszel bővíthető. Az egyes szenzorok ellenállásának függvényében egy NE556 IC négyszögjelet állít elő, melynek frekvenciája az egyik, kitöltési tényezője a másik mért paramétertől függ. A vonal másik végén ezt a jelet mintavételezve kiadódik egy periódusidő, illetve egy periódusonkénti kitöltési érték. Mivel a szenzorok karakterisztikája nem lineáris, ezért a mért adatok valós paraméterekké konvertálására nem áll rendelkezésre egy jól használható, egyszerű képlet. Képlet hiányában konverziós táblázatokat használhatók, melyek a valódi karakterisztikát több szakaszra bontva, lineárisan közelítik. 1. érzékelő ellenállása 2. érzékelő ellenállása NE556 Periódusidő Kitöltési tényező Átviteli közeg 1. mért érték 2. mért érték 1. kalibrációs táblázat 2. kalibrációs táblázat Mintavételezés 1.7. ábra: Mérési értékek átvitele 1 A szenzor modulok tervezése nem képezi a jelen dolgozat tárgyát, azokat már korábban mások megtervezték, ezért csak a működési elv ismertetésére szorítkozom.

19 1. Bevezetés 14 Az fejezetben ismertetett célok eléréséhez az üvegházban a hőmérsékletet 23, a páratartalmat 19, a megvilágítást pedig 2 érzékelő segítségével szükséges mérni A beavatkozó szervek vezérlése A beavatkozó szerveket működtető motorok illetve vezérelhető szelepek általában 230V-os hálózati feszültségről működnek. Ezek vezérlését 12V-al kapcsolható relék látják el, melyek optocsatolókon keresztül teljesen el vannak szigetelve a rendszer többi részétől. Az optocsatolók bemenetére bármilyen TTL kimenet ráköthető, így ezek kényelmesen vezérelhetőek például egy mikrokontroller általános digitális kimenetéről.

20 2. A harmadik szint tervezése A harmadik szint tervezése 2.1. Bevezetés A 1.6. ábrán látható harmadik szint az első olyan téma, melynek tervezését e dolgozat tárgyalja. A közvetlenül alatta fekvő felműszerezés biztosítja a házban elhelyezett szenzor modulokat, melyek a 1.4. fejezetben ismertetett módon elérhetővé teszik a házban mérhető környezeti paramétereket, illetve működtetik a beavatkozó szerveket. A harmadik szint önálló (külső hatásoktól függetlenül ellátandó) feladatai a következőkben foglalhatóak össze: 1. Rendszeresen mintavételezze a szenzor modulok kimenetét. 2. Határozza meg a mért fizikai paramétereket a konverziós táblázatok segítségével. 3. Továbbítsa a mért értékeket az alacsony szintű szabályozó algoritmus felé. 4. Futtassa az alacsony szintű szabályozást. 5. Hajtsa végre az alacsony szintű szabályozás beavatkozási döntéseit. Az önálló feladatokon túl, a magasabb szintek kiszolgálására az alábbi funkciók megvalósítása szükséges: 1. A magasabb szint kérése esetén továbbítani kell a friss mérési adatokat, és a beavatkozó szervek aktuális állását. 2. A magasabb szinttől érkező konfigurációs paramétereket tárolni kell, hogy azokat az alacsony szintű szabályozás működése során felhasználhassa. 3. A magasabb szinttől (közvetetten a felhasználótól vagy a magas szintű szabályozástól) érkező beavatkozási parancsokat végre kell hajtani Topológia A topológia hatása a tervezésre A mérési adatok begyűjtését végző harmadik szint felépítésének tervezése során figyelembe kell venni a tesztelésre használt üvegház fizikai adottságait, belső felépítését, mivel az üvegház topológiája alapvetően meghatározhatja a létrehozandó rendszer felépítését. A 2.1. ábra az üvegház belső szerkezetét mutatja, jelölve az egyes helyeken mérendő környezeti paramétereket. A kísérleti rendszer telepítésére kiválasztott üvegház szélessége 6,5 méter, hosszúsága 15 méter. A 2.1. ábrán látható a 18 asztal elhelyezkedése. Az asztalok között mindenhol betonlapokkal fedett út vezet, alattuk pedig kavics borítja a talajt. Az asztalok szinte teljesen kitöltik a rendelkezésre álló teret: a rövidebb oldaluk mentén, középen egy állandó út vezet, míg a hosszabb oldaluk mentén egy-egy útnak van hely, mely az asztalok kis mértékű jobbrabalra gördítésével tetszőleges két asztal közé áthelyezhető. Az ultrahangos párásító egységek teljesítménye két asztal ellátására elég, így ezek és az ultrahangos párásítással szorosan összefüggő asztalszellőztetés vezérlése kétasztalonként közösen került kiépítésre. Az ábrán szintén látható a ház beavatkozó szerveinek vezérlési pontja, a kapcsolószekrény (az ábrán Ctrl doboz), valamint a számítógép számára előkészített hely is (PC doboz). A rendszer tervezése során két megvalósítási alternatíva közül kell választani: az elkészítendő rendszer lehet centralizált vagy decentralizált. A két lehetséges megvalósítás összehasonlítása előtt tekintsük át az adatátvitel lehetséges alternatíváit: az átvitel lehet vezetékes, vagy vezeték nélküli. Előbbi esetben komoly költséget jelenthet a kábelezés kiépítése, mivel a vezetékek megfelelő rögzítésére csak az üvegház falai mentén van lehetőség.

21 2. A harmadik szint tervezése ábra: Mérendő paraméterek az üvegházban Rádiós adatátvitel esetén nincs probléma a kábelezéssel, valamint annak költségével, azonban számos egyéb körülményt is figyelembe kell venni: 1. A vezeték nélküli kommunikációt megvalósító IC-k nagy mennyiségben komoly költséget jelentenek (egy vezetékes buszillesztő IC árának legalább négyszeresébe kerülnek [10]). 2. A rádiós átvitel működtetéséhez külön mikrokontroller kell mind a 34 egységhez (szintén komoly költségtényező). 3. Az egységek tápellátása csak elemek segítségével oldható meg, melyeket rendszeresen cserélni kell. Amennyiben elemek helyett minden egység vezetéken keresztül kapja meg a tápfeszültségét, akkor néhány érrel többet használva (minimális további költség árán) megvalósítható a vezetékes átvitel. 4. Több egymás mellé (de külön üvegházakba) telepített rendszer zavarja egymást. A rádiós átvitellel szemben a vezetékes megvalósítás során a fenti negatívumok nem jelentkeznek, sőt az adatátviteli vezetékek mellett az egyes alkatrészek tápellátásáról is egyetlen, több eres vezeték gondoskodni képes. Mindezen körülményeket figyelembe véve a rádiós kommunikáció lehetőségét nem tartom reálisnak, így a továbbiakban csak a vezetékes átvitelre épülő alternatívákat vizsgálok Centralizált rendszer alternatíva Első lehetőségként egy centralizált megoldás merülhet fel, amikor a PC megbízhatóságának növelésére és a beavatkozó szervek felé a kényelmes illesztési felület kialakításának érdekében egy mikrokontrollert alkalmazok. A mikrokontroller a PC-vel soros porton kommunikál. Ebben az esetben minden szenzor modult és vezérlőegységet közvetlenül ehhez a kontrollerhez kell kapcsolni. A megoldás előnyeként a centralizált rendszerek minden jó tulajdonsága elmondható: egyetlen hardver eszközt kell építeni; nincs szükség kommunikációs alrendszerre; egyetlen

22 2. A harmadik szint tervezése 17 programot kell írni, mely minden feladatot ellát, így a fejlesztés és a hibakeresés is viszonylag egyszerűnek mondható. A megoldás óriási hátránya, hogy komoly kábelezést igényel. Amennyiben csak a szenzor modulokat, valamint a ventilátor és ultrahangos párásítás vezérlő egységeket tekintem, akkor a központi egységhez kapcsolás 250 méternél is több kábelt igényelne. Jól látható, hogy ennek egyik fő oka az, hogy az asztalokon begyűjtött adatokat a központi egységnek kell feldolgozásra továbbítani, mely ezután a beavatkozási döntést visszaküldi az asztalokhoz. A probléma tükrében magától adódik az ötlet, hogy a lokális adatokra támaszkodó lokális jellegű döntéseket ki kellene helyezni az asztalok közelébe. Ez a megközelítés egy elosztott megoldáshoz vezet Elosztott rendszer alternatíva Ennek a megoldásnak fő előnye, hogy jóval kevesebb vezeték szükséges hozzá (előreláthatólag legfeljebb 60 m), azonban számos hátránya is van a centralizált megoldáshoz képest: 1. Több hardver egységet kell tervezni. 2. A különböző típusú egységekre különböző programokat kell készíteni. 3. Szükség van egy hálózati (hardver és szoftver) alrendszer tervezésére az egységek közötti kommunikáció megvalósításához. 4. A bonyolultabb rendszerben a több egység nagyobb meghibásodási kockázatot hordoz magában. A hátrányok mellett előnyként lehet megjegyezni, hogy a feladatok elosztása által a rendszer egyes részeinek kiesése esetén a többi komponens még működésben tarthatja a hozzájuk kapcsolt beavatkozó szerveket. (Centralizált rendszer esetén az egyetlen kontroller meghibásodása a teljes rendszer leállását okozza, míg az elosztott megoldás esetén bizonyos fontos funkciók mint az ultrahangos párásítás és az asztalok szellőztetése továbbra is működőképesek maradnak.) Összességében a hátrányok ellenére az elosztott megoldással a kábelezésen jelentős összegeket lehet megtakarítani, illetve a megbízhatósági szempontból előnyős, részleges működőképesség lehetősége miatt, végül ez az alternatíva kerül megvalósításra. 2.3 Logikai rendszerterv Feladatok Az elosztott rendszer komponenseinek meghatározásához először ismerni kell az egyes ellátandó feladatokat, melyek a következők: 1. Az asztali szenzor modulok lekérdezése. 2. A nem asztali szenzor modulok lekérdezése. 3. Az asztali ventilátorok és ultrahangos párásítás vezérlése. 4. A globális beavatkozó szervek (ablakok, árnyékolás, fűtés, útpárásítás és felső párásítás) vezérlése. 5. Az alacsony szintű szabályozó algoritmus futtatása. 6. Kommunikáció a PC-vel, a magasabb szintek kiszolgálása. A feladatokat célszerű az ellátási helyük alapján csoportosítani, így háromféle egység körvonalazódik. Ezen egységek központi eleme minden esetben egy megfelelően megválasztott mikrokontroller, mely bemenetein a környezet állapotáról gyűjt információkat, kimenetein pedig a beavatkozó szervek vezérléséről gondoskodik.

23 2. A harmadik szint tervezése PC illesztő, alacsony szinten szabályozó egység (SMART) A PC közelében kell elhelyezni azt az illesztő egységet, mely a PC-ről érkező konfigurációs paramétereket és beavatkozó parancsokat a többi egység számára továbbítja. Ez a feladat előreláthatólag nem jelent komoly terhelést az adott kontrollernek, így célszerű az alacsony szintű szabályozási algoritmust is ezen az egységen futtatni. E megoldás mellett szól az is, hogy így a rendszer többi része számára láthatatlan, hogy a kapott parancsokat éppen a magas szint, a felhasználó vagy az alacsony szintű szabályozás adta ki. Ennek előnye, hogy az alacsony szintű szabályozás tesztelése után, ha minden egység megfelelően működött a rendszerben, akkor az intelligens szabályozás futtatása esetén sem lehetnek már problémák ezen a szinten a vezérlési parancsok továbbítási és végrehajtási mechanizmusaiban. Az eszköz központi egységével, a mikrokontrollerrel kapcsolatban az alábbi elvárásaim vannak: 1. Rendelkezzen megfelelően nagy programmemóriával és számítási teljesítménnyel az alacsony szintű szabályozó algoritmus működtetéséhez. 2. Biztosítson kapcsolódási felületet mind a PC, mind pedig a többi egység felé. 3. Rendelkezzen megfelelően nagy, nem felejtő adatmemóriával az alacsony szintű szabályozás paramétereinek tárolására. (A paramétereknek a tápfeszültség időleges elvesztése, majd visszatérése után is elérhetőnek kell lenniük, mivel így a rendszer a feszültség visszatérése után a PC újraindulásától függetlenül, azonnal működésbe léphet). Tekintettel arra, hogy ez az egység nem kapcsolódik közvetlenül sem szenzor modulokhoz, sem pedig beavatkozó szervekhez, így a be- és kimeneti portokkal szemben nincsenek elvárások. Látható, hogy a komponensek által ellátandó, az előző fejezetben említett feladatok közül ez az egység az ötödik és hatodik pontokért felelős. A továbbiakban a mikrokontrolleres egységekre a könnyű azonosítás érdekében egy-egy saját névvel hivatkozom majd. Feladatainak jellege alapján a PC illesztő egység a SMART nevet kapta Az asztalokat vezérlő egység (SENSOR 2 ) Az ilyen típusú egységek hivatottak a felesleges kábelezést kiküszöbölni azáltal, hogy a szenzor moduloktól érkező adatokat feldolgozzák, továbbítják a SMART felé, illetve a helyi beavatkozási döntéseket meghozzák. Az ultrahangos párásítás működtetése kizárólag az asztalokon mért páratartalom függvénye, így az ezzel kapcsolatos döntések helyben is meghozhatóak, amennyiben a felhasználótól származó konfigurációs paraméterek lokálisan elérhetők. Szintén célszerű a vezérlési pontok közelségére tekintettel az asztali ventillátorok vezérlését is ezekre az egységekre bízni. Az itt alkalmazandó mikrokontrollerrel kapcsolatban az alábbi elvárások támaszthatóak: 1. Rendelkezzen megfelelően nagy programmemóriával és számítási teljesítménnyel a szenzor moduloktól érkező adatok értelmezésére (a konverziós táblázatok alapján), illetve a ventillátorok és az ultrahangos párásítás lokális vezérlésére. 2. Biztosítson kapcsolódási felületet a SMART felé. 3. Rendelkezzen kellően nagy, nem felejtő adatmemóriával a konverziós táblázatok illetve a ventillátorok és az ultrahangos párásítás szabályozási paramétereinek tárolására. 2 Az alkalmazott terminológia: A szenzor alkatrész a hőmérséklet, páratartalom vagy megvilágítás függvényében ellenállását változtató alkatrész. A szenzor modul két szenzoralkatrészt és egy NE556 IC-t tartalmazó egység, mely a szenzor alkatrészek aktuális ellenállásának függvényében különböző frekvenciájú és kitöltésű négyszögjelet képes előállítani. A szenzor vezérlő egység, más néven SENSOR az a mikrokontrolleres egység, melyhez a szenzor modulok csatlakoznak. Feladata többek közt a mért fizikai paraméter értékek visszaállítása a négyszögjel alapján, illetve továbbítása a buszon keresztül a SMART vagy közvetetten a PC felé.

24 2. A harmadik szint tervezése Biztosítson megfelelő számú be- és kimeneti portot a szenzor modulok, illetve a vezérlő áramkörök felé. A szenzorillesztő modul a korábbiakban specifikált öt feladat közül az elsőt és a harmadikat látja el. Ebből a modulból értelemszerűen több darabra lesz szükség. Legegyszerűbb megoldásként felmerülhet, hogy minden két asztalhoz melyek vezérlése úgyis közös az együtt használt ultrahangos párásító egység miatt tartozzon egy ilyen egység. Az egyes alkatrészek árát figyelembe véve azonban, nem feltétlenül ez lesz az optimális megoldás Nem asztali szenzorok és beavatkozó szervek vezérlője (STRONG) A feladatlistából már csak a második és a negyedik pont maradt ki, mely feladatok a STRONG-ra hárulnak. Ezt az egységet célszerű az üvegház szintű beavatkozó szervek vezérlési helyének közelébe elhelyezni, mivel így a vezérlő jeleket nem kell messzire vezetni. A STRONG-hoz tartozó szenzor modulok (a második, harmadik illetve negyedik zóna érzékelői) a ház területén viszonylag szétszórtan helyezkednek el, így az ezekhez szükséges hosszú kábelezést semmiképpen nem lehet megtakarítani. A felhasznált mikrokontrollerrel kapcsolatos elvárások az alábbiak: 1. Rendelkezzen megfelelően nagy programmemóriával és számítási teljesítménnyel a szenzor moduloktól érkező adatok értelmezésére (a konverziós táblázatok alapján). 2. Biztosítson kapcsolódási felületet a SMART felé. 3. Rendelkezzen kellően nagy, nem felejtő adatmemóriával a konverziós táblázatok számára. 4. Biztosítson megfelelő számú be- és kimeneti portot a szenzor modulok, és a vezérlő áramkörök felé. Ezzel az egységgel az összes feladatot sikerült kiosztani az elosztott rendszer egy-egy komponense között, így további modulokra nincs szükség Kommunikáció Egyetlen fontos, nyitott kérdés maradt még: a kommunikáció az egységek között. A hálózatnak az alkalmazott SENSOR modulok számától függően 4-11 egység között kell kapcsolatot biztosítania. A kapcsolat jellegét a különböző típusú egységek között az alábbi ábra mutatja. PC (adatrögzítés és magas szintű szabályozás) STRONG (globális beavatkozók SMART (adatgyűjtés, alacsony szintű szabályozás, a PC kiszolgálása) SENSOR 1 (mérés, párásítás, szellőztetés)... SENSOR n (mérés, párásítás, szellőztetés) 2.2. ábra: A modulok kapcsolatai

25 2. A harmadik szint tervezése 20 Jól látható, hogy a STRONG és a SENSOR egységek egymással közvetlenül nem kommunikálnak. A SMART a STRONG-nak parancsokat, vagy konverziós táblázatokat küldhet, illetve lekérheti annak pillanatnyi állapotát, mért értékeit. A SENSOR egységeknek a SMART szintén küldhet parancsokat, konverziós táblázatokat és vezérlési paramétereket (például az ultrahangos párásító működtetéséhez). Ezen túl lekérdezheti az aktuális mérési eredményeket és a beavatkozó szervek állását (pontosabban ez esetben a párásítás illetve a ventillátorok működési időit a legutóbbi lekérdezés óta). Az előbbiek alapján, illetve az ábrán is jól látható, hogy a kommunikáció kezdeményezője minden esetben a SMART: ő küld konfigurációt vagy parancsot, illetve kér mérési eredményeket vagy beavatkozó szerv állapotot. Ebből következően a kommunikációt célszerű egyszerű, master-slave elven megvalósítani, ahol a master egység a SMART. Ez a megoldás számos olyan problémát kizár, ami a véletlen hozzáférésű kommunikációs közegek esetében például a közeghozzáféréssel kapcsolatban felmerülhetne, így nagyban egyszerűsíti a megvalósítást a funkcionalitás korlátozása nélkül. Az üvegház topológiájának ismeretében (2.1. ábra), a 2.2. fejezet megfontolásai alapján célszerű a vezetékes adatátvitelt egy buszon keresztül megvalósítani, mely a ház falán fut végig. A busz vezetésére két lehetőség kínálkozik: az első alternatíva az, hogy a busz egyik végén a SMART, másik végén a STRONG helyezkedik el, tehát az asztalokat a 18-tól az 1-es felé veszi körbe. A másik lehetőség választásával minimálisan csökkenthető a busz hossza úgy, hogy az a 11-től a 10 irányába haladna. A két busz vezetési lehetőséget a 2.3. ábra szemlélteti STRONG 1. lehetőség 2. lehetőség 2.3. ábra: - Lehetséges busz vezetési megoldások SMART Az első megoldás mellett szól, hogy a SMART és STRONG egységek egyediek, míg a SENSOR egységekből több példányt is készíteni kell. Amennyiben a busz két végpontján valamilyen speciális alkatrészre (tipikusan lezáró ellenállásra) van szükség, akkor azt az egyedi egységekbe könnyen be lehet építeni. Ezzel szemben a SENSOR egységek esetén módosított változatokat kellene tervezni erre a feladatra, ebből kifolyólag az 1. alternatíva kerül megvalósításra Fizikai rendszerterv A logikai rendszertervben összefoglaltam a harmadik szint feladatait, illetve vázoltam az ezeket ellátó három egységet. A következőkben az eszközök konkrét tervezését mutatom be. Ezt megelőzően azonban néhány alapvető döntést kell meghozni a kommunikációs hálózattal, illetve az alkalmazott mikrokontrollerekkel kapcsolatban.

26 2. A harmadik szint tervezése Kommunikációs hálózat Minden egységgel szemben elvárás, hogy a többiekkel kommunikálni tudjon, vagyis a kommunikációs hálózatra megfelelően csatlakozzon. A kommunikációs hálózat esetünkben egy busz, melynek a következő szempontoknak kell megfelelnie: 1. A busznak egyszerre (legfeljebb) 11 egység kommunikációját kell lehetővé tennie. 2. A busz hosszának legalább 45 méteresnek kell lennie. 3. A busznak legalább 1200 bps adatátviteli sebességet kell biztosítania. 4. A busz legyen megfelelően zavarvédett. A kommunikáló egységek száma egyedül a SENSOR egységek számától függ, de 11-nél több jelen esetben biztosan nem kerül beépítésre. A busz hossza a ház fizikai méreteiből (6,5 x 15 méter) és a 2.3. ábrán látható topológiából megfelelő ráhagyások mellett adódik. Az átviteli sebességgel szemben támasztott követelmény minimális, tekintettel arra, hogy a legnagyobb kommunikáció igényű művelet a konverziós táblák elküldése is legfeljebb 100 bájt adat átvitelét igényli egyszerre, illetve nincsenek kritikus, gyors kommunikációt igénylő feladatok. A zavarvédelem általánosan is fontos, de esetünkben a beavatkozó szerveket működtető 230V-os relék közelsége miatt még komolyabb hangsúlyt kap. A fenti követelményeknek tökéletesen megfelel az EIA-485 specifikáció, mely egy aszinkron, soros, differenciális buszt ír le [11]. Ennek főbb tulajdonságai: 1. Alapesetben egy hálózatra legfeljebb 32 egység kapcsolódhat. 2. A busz hossza legfeljebb 1200 m lehet. 3. A maximális adatátviteli sebesség (45 m hossz mellett) az 512 KB/s-ot is elérheti. 4. A busz jó zavarvédettségét differenciális jellegének köszönheti, mivel az információt a két vezeték közötti feszültségkülönbség hordozza, amit a vezetékekre ható (közel) azonos zavarás nem képes megváltoztatni. A busz két vezetéket igényel, melyeket egyszerű árnyékolt, csavart érpárból kell kialakítani, a végén egy-egy 120 Ohm-os lezáró ellenállással [12]. A zavarvédettség javításának érdekében célszerű a buszra csatlakozó eszközöket azonos földdel ellátni. A busz szabad állapotában (például, ha minden egység vételi módban van) célszerű az egyes vezetéket két ellenállás használatával definiált, magas logikai értéken tartani. A hálózatra csatlakozáshoz a Maxim által gyártott IC-ket (MAX485), illetve az azokkal megegyező, de kedvezőbb árú Texas Instruments által gyártott alkatrészeket (SN75179) használok. A busz sebességét mindössze 9600 baud-ra választottam, mivel már ez is elégséges a feladatok ellátására Mikrokontrollerek Az egyes mikrokontrolleres egységeket célszerű azonos családba tartozó kontrollerek segítségével megépíteni. Ennek két előnye van: egyrészt az egyik egységen futó kód könnyen átvihető a másikra (például a kommunikációval kapcsolatos kódrészletek várhatóan minden egységen azonosak lesznek), másrészt a fejlesztő és programozó (hardver-szoftver) környezet is univerzálisan használható minden egységhez. A fenti megfontolások alapján az Atmel által gyártott 8 bites ATmega család mellett döntöttem [13], mely az alábbi tulajdonságokkal rendelkezik: 1. A kontrollerek könnyen programozhatóak akár a végleges alkalmazási helyükön is (a viszonylag egyszerű programozó egységtől mindössze négy adatvezetéket kell a kontrollerhez csatlakoztatni) [14]. 2. Magyarországon nagy választékban, könnyen beszerezhetőek [15]. 3. Relatíve olcsók. 4. Jól illeszkednek a jelen alkalmazáshoz. A fejlesztés során próbapanelok használata esetén csak DIP tokozású alkatrészeket lehet felhasználni, illetve a végleges nyák esetében is csak DIP foglalat esetén van lehetőség egy

27 2. A harmadik szint tervezése 22 meghibásodott alkatrész egyszerű cseréjére, ezért a legtöbb alkatrészt így a mikrokontrollereket is DIP tokozással használom. (Az üvegházban a nedvesség miatt nem lehet eltekinteni az alkatrészek esetleges meghibásodásától, így az egyszerű csere lehetősége nagyon fontos.) Az ATmega család minden számomra fontos tagja kapható Magyarországon ilyen kiszerelésben. A továbbiakban a logikai rendszertervben ismertetett egységekhez a 2.3. fejezetben megfogalmazott elvárásoknak megfelelően választok kontrollereket az ATmega családból A SMART egység A SMART feladatai közül az egyik legfontosabb az alacsony szintű szabályozás futtatása, melynek működését a bevezető fejezet írta le. A másik ilyen hangsúlyos feladat megfelelő illesztési felület képzése a PC és a hálózat többi eleme között. Ebből kifolyólag mindkét irányban szükség van egy adó-vevő egységre, melyet az ATmega család esetében általában USART-nak neveznek (Universal Synchronous and Asynchronous serial Receiver and Transmitter). A SMART központi egységének egy ATmega162 mikrokontrollert választottam, mely az alábbi fontos tulajdonságokkal rendelkezik [16]: MIPS műveleti sebesség 16 MHz órajel mellett KB flash program memória bájt EEPROM adatmemória db USART egység. A 16 MHz-s órajel feltehetően a nem túl számításigényes feladatok miatt még sok is lesz jelen alkalmazáshoz. A szükséges programmemória méretét nehéz előre megbecsülni, de feltehetően a 16 KB-ps méret megfelelő. Az EEPROM feladata az alacsony szintű szabályozás paramétereit tárolni, amire az 512 bájt biztosan elég lesz. Az USART egységek közül az egyik a PC irányába, a másik a hálózat többi egysége felé teszi lehetővé a kommunikációt. Előbbi egy MAX232 IC segítségével kapcsolódik a számítógéphez, míg utóbbi célra a már említett MAX485 szolgál. A SMART egység logikai felépítését a 2.4. ábra mutatja be. A pontos lábkiosztást az F.1.2. függelék ismereti A SENSOR egység Ennek az egységnek a feladata az egyes szenzor modulok rendszeres lekérdezése, valamint az asztali szellőztetés és ultrahangos párásítás vezérlése. Az ebből a típusból építendő egységek számát az befolyásolja, hogy egy példány hány párásító és szellőztető vezérlésére alkalmas. Amennyiben egynél többre, úgy az egységek előállítási költségein megtakarítás érhető el, azonban a kábelezés hosszabb lesz. Reális kompromisszumként egy egységhez két asztalpárt rendelek hozzá, így összesen 5 darabra lesz szükség. Mivel csak 18 asztal van, így az egyik egység nem lesz teljesen kihasználva. Ez szerencsésnek is mondható, mert a falak mentén futó fűtéscsövek hőmérsékletének monitorozása is a feladatok közé tartozik, így a kihasználatlan egységre köthető ez a plusz érzékelő. Célszerűen a SENSOR egységek programját úgy kell megvalósítani, hogy ez a különleges feladatot állátó egység ne különbözzön szoftverében a többiektől. (Természetesen vezérlési paramétereiben különböznie kell, hiszen a kihasználatlan oldalán felesleges a párásítás vagy a szellőztetés kimeneteket működtetnie.) A feladatok ellátására a szabályozás egyszerűségére tekintettel a SMART-nál egy kisebb kontrollert, az ATmega8-at választottam, mely az alábbi fontos paraméterekkel rendelkezik [17]: MIPS számítási teljesítmény 16 MHz órajel mellett KB flash programmemória bájt EEPROM adatmemória.

28 2. A harmadik szint tervezése db USART egység. 5. Jelen alkalmazás mellett 14 szabadon használható I/O port. A maximális számítási teljesítményre minden bizonnyal itt sem lesz szükség, illetve a futtatandó program egyszerűsége miatt, feltehetően a 8 KB-os programmemória is elégséges. Az EEPROM-ban a két asztal pár szabályozási paraméterei (kívánatos páratartalom szintje), valamint a konverziós táblázatok (a 4*2 érzékelő alkatrész számára 8 táblázat) foglalnak majd helyet. Az USART egység a MAX485 IC-n keresztül kapcsolódik a hálózatra. Az USART használata mellett szabadon maradó 14 I/O port által ellátott feladatokat, valamint a pontos lábkiosztást az F.1.2. függelék ismereti. A SENSOR egység logikai felépítése a 2.5. ábrán látható. A szenzor modulok működését a fejezet mutatta be: a modulok egy négyszögjel periódusa és kitöltési tényezője segítségével továbbítják az adatokat a SENSOR egységekhez. E négyszögjel feldolgozására két lehetőség adódik. Az első lehetőség a mikrokontroller beépített analóg komparátorának felhasználása, mely a szintén beépített Timer egységek segítségével képes a szintváltások (által kiváltott megszakítási kérések) között eltelt időket meghatározni. A megoldás viszonylag egyszerű és hardverrel támogatott. Az egyetlen probléma, hogy a kontroller mindössze egyetlen bemenettel rendelkezik erre a célra, tehát erre a vonalra egy multiplexer segítségével kellene a szenzor moduloknak csatlakozniuk. További hátrány, hogy a mérés során az analóg komparátor által kiváltott megszakításoknak az éppen futó programrésztől függetlenül, azonnal kiszolgálásra kell kerülniük a pontos mérések érdekében. A multiplexer beépítése elkerülhető, amennyiben nem használom az analóg komparátort, hanem a bemeneteket a mérés során folyamatos lekérdezéssel mintavételezem. Ebben az esetben a mérés pontosságát a lekérdezések között beérkező egyéb megszakítás kérések veszélyeztethetik, azonban ezek a mérés idejére letilthatók. Ez a megoldás a külső alkatrész kiváltásáért cserébe a mérés alatt a processzort teljesen lefoglalja. Tekintettel a SENSOR feladatainak minimális számításigényére, illetve a feladatok nem kritikus időfüggésére, ez a kompromisszum felfogadhatónak tűnik, így e hardveresen egyszerűbb megvalósítás mellett döntöttem STRONG Ennek az egységnek nincsenek komolyabb számításokat igénylő vezérlési feladatai: a szenzor modulok felől érkező jelek mintavételezésén és a táblázatok alapján történő konvertáláson kívül csak a beavatkozó szervekre vonatkozó parancsokat kell végrehajtania. Ebből következően a mikrokontrollerrel szemben a fő elvárás a megfelelő számú I/O port megléte. A feladat ellátására a jelen alkalmazás mellett 26 I/O porttal rendelkező ATmega16 egységet választottam, mely az alábbi paraméterekkel rendelkezik [18]: MIPS számítási teljesítmény 16 MHz órajel mellett KB flash programmemória bájt EEPROM adatmemória db USART egység. A számítási teljesítmény itt biztosan jóval több a szükségesnél, mint ahogyan a programmemória sem lesz teljesen kihasználva. Az EEPROM-ba kizárólag a konverziós táblák kerülnek. Az USART egység értelemszerűen a hálózatra csatlakozik. Az egység logikai felépítését a 2.6. ábra mutatja. A STRONG 26 szabad I/O portja között az alábbi 20 feladat kerül kiosztásra: Bemenetek 4 db Szenzor mintavételező bemenet

29 2. A harmadik szint tervezése 24 1 db Esőérzékelő bemenet 1 db Ajtó nyitottságot jelző bemenet 1 db Oldalsó ablak nyitottságot jelző bemenet 1 db 90% árnyékolást jelző bemenet 1 db 1/3 ablak nyitottságot jelző bemenet Kimenetek 2 db Státusz LED kimenet 1 db Ablak mozgatási irány kimenet 1 db Ablak mozgató kimenet 1 db Árnyékoló ernyő mozgatási irány kimenet 1 db Árnyékoló ernyő mozgató kimenet 1 db Útpárásítás kimenet 1 db Asztali felső párásítás kimenet 1 db Fűtés kimenet 1 db Riasztás kimenet 1 db Szenzor vezérlés (tápellátás) kimenet A pontos lábkiosztás az F.1.4. függelékben található meg ábra: A SMART logikai felépítése

30 2. A harmadik szint tervezése ábra: A SENSOR logikai felépítése 2.6. ábra: A STRONG logikai felépítése

31 2. A harmadik szint tervezése Fizikai rendszerterv A végleges fizikai rendszerterv az alábbi ábrán látható ábra: A fizikai rendszerterv

32 2. A harmadik szint tervezése Kommunikációs protokollok Master-slave megvalósítás A következőkben vázolom a kommunikációs protokollok működését az egyes egységek között a buszon (485 protokoll), illetve a PC-t és a SMART-ot összekötő soros vonalon (COM protokoll). Mindként protokoll esetén az egyik legfontosabb tervezési alapelv az, hogy az egyes egységek egymástól maximálisan függetlenül működjenek, tehát egymás kiesését amennyiben az nem feltétlenül indokolt észre se vegyék. Ennek alapvető eszköze a masterslave megvalósítás, melynek lehetőségét a SMART és a többi egység között a kommunikáció jellegének ismeretében már a logikai rendszertervben felvetettem. A soros vonal esetén, mivel csak két egység van, ezért szintén könnyen alkalmazható egy ilyen felosztás. A master-slave megoldás előnye, hogy bármelyik egység kiesése csak minimálisan hat a másikra. Amennyiben a master nem érhető el, azt a slave egységek gyakorlatilag nem érzékelik, hiszen mindössze a rendszeres lekérdezések vagy parancsok maradnak el. Ettől függetlenül a slave egységek a saját autonóm feladataikat zavartalanul elláthatják. Amennyiben egy slave egység válik elérhetetlenné, az mindössze a masterre van hatással, aki az eseményt megfelelő módon (hibajelzés, újrapróbálkozás, kommunikáció időleges felfüggesztés) kezelheti. Az előbbi meggondolások egyértelműen illenek a buszon folyó kommunikációra, és kisebb módosításokkal a SMART-PC kapcsolatra is. Utóbbi esetben a lényeg az, hogy a SMART mint slave egység sosem kezdeményez kommunikációt a PC-vel, így annak hiánya semmilyen formában nem érinti a rendszer működését. A megoldásnak természetesen hátrányai is vannak: mivel a slave egységek nem képesek a master felé kommunikációt kezdeményezni, ezért esetleges igényeik kielégítéséről megfelelően gyakori lekérdezéssel kell gondoskodni. Ez problémát jelenthetne abban az esetben, ha sok egység lenne, illetve a kommunikációs csatornák leterheltek lennének, azonban jelen esetben egyik körülmény sem áll fenn Univerzális protokoll A fizikai rendszerterv ismeretében magától adódhat, hogy a két különböző kommunikációs csatornán két különböző protokoll kerül implementálásra. Megfontolandó azonban egy alternatív és egyszerűbb lehetőség, miszerint elég lenne csak egy protokollt használni minden egység között. Ebben az esetben a PC bárkinek küldhetne üzenetet, melyet a SMART továbbítana a buszra. A megoldásnak két előnye van: egyrészt csak egy protokoll tervezése szükséges, másrészt a SMART-ban így csak az üzenet továbbítást megvalósító részt kell implementálni, a nem neki szóló üzenetek feldolgozását nem. (Ezzel kapcsolatban felmerülhet, hogy a PC akár közvetlenül is csatlakozhat a buszra egy megfelelő illesztőkártyával, ám ez semmiképpen sem engedhető meg, mivel nagyon elmosná az egyes tervezési szintek között jelenleg meglévő tiszta határokat. Az egyes szintek keveredése a rendszer komplexitását jelentősen növelné, ezáltal pedig a megbízhatóság kevésbé lenne biztosítható.) Az előnyökkel szemben egyetlen érv áll, melynek alapján mégis a két protokollos megvalósítás mellett döntöttem: amennyiben két külön protokoll van, akkor a SMART-nak protokoll fordítást kell ellátnia a két hálózat között. Ennek során például egy beavatkozó parancs esetén értelmezi a PC-től érkező üzenetet, majd annak tartalma alapján kiadja a buszra a megfelelő parancsot. Tekintettel arra, hogy az alacsony szintű szabályozás minden beavatkozó szervet működtet, nyilvánvalóan megfelelő eljárások kerülnek implementálásra a SMART-ban minden ilyen feladatra. Ezek az eljárások értelemszerűen felhasználhatóak a PCtől érkező parancsok továbbítására is. Az így kialakuló helyzet azért előnyös, mert így a kommunikáció a PC és a hálózat többi része között két részre bontható: az első szakaszban a

33 2. A harmadik szint tervezése 28 PC üzenete a SMART-hoz megy, aki értelmezi azt, majd a második szakasz során továbbítja a megfelelő beépített eljárások használatával. Ez a két szakasz egymástól független, így függetlenül is tesztelhető. Amennyiben a SMART és a többi egység között a kommunikáció megfelelően működik ami például az alacsony szintű szabályozás alapos tesztesésével ellenőrizhető, akkor az garanciát jelent arra is, hogy a magas szintű szabályozás helyesen megfogalmazott parancsai is képesek lesznek működtetni az üvegházat. További pozitívum még, hogy ebben az esetben a PC semmiképpen sem képes az egyes beavatkozó szervek felé értelmetlen üzeneteket küldeni, hiszen a SMART-ban implementált eljárások, illetve a PC-től érkező üzenetek értelmezése együttesen garantálják, hogy csak értelmezhető üzenetek kerülhetnek ki a buszra. Természetesen ezek az előnyök egy olyan megoldás esetén is elérhetők lennének, amikor a SMART az univerzális protokoll nem neki szóló üzeneteit továbbítás előtt tartalmilag ellenőrzi. Ekkor azonban minden üzenettípushoz implementálni kellene az ellenőrző eljárást. Amennyiben azonban minden üzenethez tartozik egy külön ellenőrző függvény, akkor ennek a megoldásnak nincs számottevő előnye a két protokollos megoldáshoz képest, amelytől így már csak az ellenőrzést követő továbbküldés módjában tér el. E megfontolások alapján tehát két különböző, viszonylag egyszerű, a feladat ellátására alkalmas protokollt használok a két csatornán Hibadetektálás Mint a kommunikációs protokollok esetében általában, úgy most is szükséges a kommunikációs hibák detektálása annak ellenére, hogy a viszonylag rövid vezetékek elég megbízható kommunikációs csatornát biztosítanak. Az ATmega mikrokontrollerek beépített USART egysége háromféle hibát képes egyegy jelzőbit beállításával jelezni [18]: 1. Keretezési hiba bit: jelzi, hogy a vett karakter után várt stop bit (aminek magas szinten kellene lennie) nem érkezett meg, 2. Puffer túltöltés bit: jelez, amennyiben a vételi pufferben egy még kiolvasatlan karakter felülírásra került az aktuálisan vett karakterrel, 3. Paritás hiba bit: jelzi, ha a vett karakter paritásbitje nem megfelelő (amennyiben a paritásellenőrzés be van kapcsolva). E három, hardveresen támogatott hibajelzés nem elegendő az összes lehetséges hiba felismerésére. Előfordulhat ugyanis olyan eset, hogy a vételi puffer csupa hibátlanul vett adatot tartalmaz, ezek azonban nem alkotnak értelmes üzenetet. Ilyen helyzet állhat elő szinkronizációs problémák esetén, amikor az egyik egység túl későn küldi a tőle várt adatokat, melyek egy másik üzenettel keveredve kerülnek eltárolásra. Az ilyen jellegű hibák felismerésére igen egyszerű megoldásként minden üzenet utolsó bájtja egy ellenőrző összeg, mely a korábbi adatok bináris összeadásával gyorsan számítható. Amennyiben ez az ellenőrző összeg hibás, akkor a vett üzenet is minden bizonnyal hibás, így azzal a továbbiakban nem szabad foglalkozni. Felmerülhet lehetőségként, hogy ilyenkor a másik felet egy válaszüzenetben tájékoztatni kellene az átviteli hibáról, azonban ez bonyolult megoldásokat igényelne: Más a teendő, ha a master kap ilyen hibaüzenetet a slave-től vagy fordítva; a korábbi üzeneteket el kellene tárolni újraküldés esetére; minden vétel során külön ellenőrizni kellene, hogy a várt adat vagy egy hibaüzenet érkezett. Ebből kifolyólag sokkal egyszerűbb megoldásként ilyenkor az üzenetet meg nem érkezettként tekinti a vevő fél. Az adó erre az esetre vagyis a válasz elmaradására megfelelő számú újraküldési kísérlettel válaszolhat. Az ellenőrzőösszeg önmagában elegendő a hardveresen támogatott hibajelzések kiváltására is, hiszen egy hibásan vett karakter minden bizonnyal elrontja az ellenőrző összeget, így detektálásra kerül a megfelelő bitek vizsgálata nélkül is.

34 2. A harmadik szint tervezése A COM protokoll A SMART-ot a PC-vel összekötő soros vonal full duplex kommunikációt tesz lehetővé, azonban a korábbiakban említett szempontokat figyelembe véve itt is master-slave protokollt valósítok meg. A PC a master egység, aki a kapcsolatot kezdeményezi egy üzenettel, melyre a SMART mint slave köteles válaszolni. Minden üzenet első bájtja az üzenet hosszát tartalmazza. Ennek ismeretében a vételi oldalon egy egyszerű ciklussal be lehet olvasni a küldött adatokat. A mastertől érkező üzenetek második bájtja minden esetben egy parancsot azonosít, ezt követik a parancshoz tartozó egyéb paraméterek, melyeket az utolsó bájton az ellenőrzőösszeg zár le. A slave-től érkező üzenetek a második bájttól kezdődően tartalmazzák az adatokat, és szintén ellenőrző összeggel zárulnak. Az üzenetek nem tartalmaznak cím információkat, hiszen csak két kommunikáló fél van. Az üzenetek felépítését az egyes irányokba az alábbi két ábra mutatja. A protokoll implementált üzeneteit az F.2. függelék sorolja fel. Hossz Parancs Adat 1 Adat 2 Adat 3 Adat N Ellenőrző azonosító összeg 2.8. ábra: COM protokoll a master-től a slave felé Hossz Adat 1 Adat 2 Adat 3 Adat 4 Adat N Ellenőrző összeg 2.9. ábra: COM protokoll a slave-től a master felé A 485 protokoll A soros vonali kommunikációnál valamivel összetettebb feladat a buszon használt protokoll tervezése, hiszen itt már az üzeneteket címezni kell. A master-slave megvalósításnak köszönhetően a címet elég csak a master-től jövő üzenetekben elhelyezni, mivel az ellenkező irányú kommunikáció esetén a címzett csak a master lehet. A master által küldött üzenetek minden esetben a megszólított egység címével kezdődnek, így minden slave azonnal el tudja dönteni, hogy foglalkoznia kell-e a vett üzenet hátralevő részével. Ezt követi az üzenet hossza, majd a parancs azonosítója, mely mezők hasonló szerepet töltenek be, mint a COM protokoll esetén. A következő bájtokon az adott parancs paraméterei helyezkednek el, majd itt is az ellenőrző összeg zárja az üzenetet. A slavetől érkező válasz első helyén a feladó egység címe áll a címzettnek itt nem lenne értelme, hiszen a slave úgyis csak a masterrel kommunikál -, így ellenőrizni lehet, hogy valóban attól jött-e az üzenet akitől a master várta. Ezt követi a hossz információ, majd opcionálisan a hasznos adatot hordozó bájtok, végül az üzenet az ellenőrző összeggel zárul. A 485 protokoll üzeneteinek felépítése az alábbi ábrákon látható. Címzett Hossz Parancs Adat 1 Adat 2 Adat N Ellenőrző azonosító összeg ábra: 485 protokoll a master-től a slave felé Küldő Hossz Adat 1 Adat 2 Adat 3 Adat N Ellenőrző összeg ábra: 485 protokoll a slave-től a master felé A 485 protokollnak megfelelő, implementált üzeneteket az F.3. függelék ismerteti. A protokoll nem túl bonyolult, azonban egy kérdés még nyitva maradt: honnan tudja a slave egység, hogy a master címet helyezett a buszra, vagyis új üzenet kezdődik? A probléma

35 2. A harmadik szint tervezése 30 megoldása szerencsére viszonylag egyszerű, mivel az ATmega családnál alkalmazott USART egység képes 9 bites karaktereket küldeni és fogadni, így az adatok mellett elküldött 9. bit jelezheti, hogy éppen cím van a buszon. Ezen felül további kényelmi funkcióként minden alkalmazott mikrokontrollerben lehetőség van az úgynevezett MPCM (Multi Processor Communication Mode) aktiválására. Ebben az üzemmódban az USART egység csak a címinformációt tartalmazó kereteket helyezi a vételi pufferbe, minden mást figyelmen kívül hagy. A címeket itt is a 9. bit magas értéke azonosítja a ábrán ezt vastag keret jelöli. Látható, hogy a MPCM pontosan a vázolt problémát kezelő hardver megoldás. A kívánatos működés MPCM esetén az alábbi lépésekből áll: 1. A master elküldi a címet, a 9. bitet egybe állítva. 2. Minden slave egység USART modulja veszi a címet. 3. Minden slave egység összehasonlítja a címet a sajátjával, illetve a broadcast címmel. 4. a) Minden megcímzett egység (broadcast esetén több is lehet) kikapcsolja az MPCMet, így a további bájtokat venni fogja, majd a vétel befejezésekor visszakapcsolja az MPCM-et. b) A nem megcímzett egységeknek további tennivalójuk nincs, az adat bájtokat az USART moduljuk aktivált MPCM mód mellett figyelmen kívül hagyja. A master magától értetődően nem használ MPCM-et, hiszen minden adatot vagy ő küld, vagy neki szánják. A slavetől érkező üzenetek esetén éppen ezért nincs szükség az elsőként küldött, feladót tartalmazó bájt külön megjelölésére, azt a master mindenképpen venni fogja Szoftver tervek Bevezetés A következőkben az egyes egységeken futó szoftver feladatait gyűjtöm össze, azokat két kategóriába sorolva. A szinkron feladatok végrehajtásáról az adott egységnek saját ütemezése alapján, a külvilágtól függetlenül kell gondoskodnia. Az aszinkron feladatok valamilyen külső hatásra például egy másik egységtől érkező kérésre elinduló programrészek. A konkrét feladatok vizsgálata előtt néhány alapvető döntést azonban meg kell még hozni. Ezek következnek az alábbiakban Programnyelv Az ATmega család mikrokontrollereihez a gyártó AVR Studio néven egy önálló assembler fejlesztőkörnyezetet ad [19]. Ennek segítségével kényelmesen lehet programokat fejleszteni, illetve futtatást szimulálni a legtöbb Atmel mikrokontrolleren. A fejlesztőkörnyezet csak az assembly nyelvet támogatja, így nagyon gyors és hatékony kód írására nyílik lehetőség. A fejlesztés viszont jóval időigényesebb, mint egy magas szintű programozási nyelv alkalmazása esetén. Az ATmega kontrollerek számára nincs hivatalos C fejlesztőkörnyezet, mindössze egy módosított BSD licenc alatt elérhető, GNU eszközkészlet található AVR Libc néven [20]. Az itt található fordítóprogram segítéségével a kontrollerek számára készült C forráskód Intel HEX formátumba fordítható, mely közvetlenül a mikrokontrollerekre tölthető. Tekintettel arra, hogy a megvalósítandó feladatokban nincs szükség az optimális kód által biztosított nagy működési hatékonyságra, illetve figyelembe véve az assembly fejlesztés nehézségeit, a C programnyelv mellett döntöttem Konfigurációkezelés A szoftverek vizsgálata előtt meg kell tervezni egy látszólag jelentéktelen részletet, mégpedig az egységek konfigurációkezelését. A konfiguráció tartalmaz minden a működéssel

36 2. A harmadik szint tervezése 31 kapcsolatos paramétert, mint például a vezérléseknél felhasznált küszöbszinteket. Ezek a paraméterek a PC-től érkeznek meg a SMART-hoz, aki a kapott üzenetet feldolgozza. A feldolgozás során a SMART megállapítja, hogy egy konfigurációs üzenetet kapott, így az abban szereplő cím alapján (lásd COM protokoll F.2. függelék) ha nem ő a címzett, akkor továbbküldi a megfelelő egység számára. A konfiguráció az egységek EEPROM-jában tárolódik, tehát egy áramszünet esetén sem veszik el, így kijelenthetném, hogy kizárólag a felhasználó paramétermódosításainak hatására szükséges a frissítése. Ez azonban nem igaz, például egy egység meghibásodása és cseréje esetén. Hasonlóképpen, a tárolt program frissítése során a programmemória felülírása is általában az EEPROM tartalmának elvesztésével jár. (Ennek nem kellene így lennie, a gyakorlatban azonban mégis ez tapasztalható.) Nem is kell az egységnek teljesen működésképtelenné válnia, mivel egy rövidebb üzemszünet miatt is könnyen lemaradhat a legfrissebb konfiguráció rögzítéséről. A felsorolt esetek ugyan előreláthatóan nem lesznek túl gyakoriak, azonban ha a felhasználó a paramétereket ritkán módosítja, a probléma sokáig fennállhat. Ennek a helyzetnek a kiküszöbölésére a konfigurációkat egy azonosító számmal kell ellátni, melynek alapján könnyen eldönthető, hogy az adott egység a legfrissebb verzióval rendelkezik-e. Az azonosító szám generálása a magasabb szintek feladata lesz, hiszen a konfiguráció módosítása is ott történik. Ezt a verziószámot célszerű kellően gyakran lekérdezni, és amennyiben valamelyik egység nem a legfrissebb verzióval rendelkezik, akkor azt frissíteni. Az egységek konfigurációjának részletes tartalmát az F.4. függelék tartalmazza Időkezelés Egy másik fontos, eddig nem említett probléma az időkezelés. A vezérléssel szemben elvárás, hogy bizonyos beavatkozásokat előre meghatározott időpontokban hajtson végre. Ilyen az árnyékolás hőmérséklettől független be- illetve kikapcsolása, vagy a napi háromszori asztalszellőztetés. Az ilyen feladatok ellátása érdekében rendelkezni kell egy pontos időt szolgáltató órával, melyet a hardver egyszerűségének megtartása érdekében szoftverben kell implementálni. Az idő forrásaként nem lehet a PC-re támaszkodni, hiszen a kapcsolat elvesztése esetén is teljes körű vezérlést kell biztosítani. Az árnyékolás vezérlési döntései a SMART-on kerülnek meghozatalra, illetve az óraszinkronizáció a PC-vel is csak a SMART-on keresztül történhet, így a SMART-nak célszerű a pontos idővel rendelkeznie. Az asztalszellőztetés vezérlése közvetlenül a SENSOR-ok kezében van, így célszerű lenne itt is egy óra segítségével önállóan dönteni a beavatkozásról. Ezzel akár a busz meghibásodása esetén is garantálni lehetne a rendszeres asztalszellőztetés megtörténtét. Az órák szoftveres implementálása viszonylag egyszerűnek ígérkezik: a mikrokontrollerekbe épített Timer egység ütéseit (megszakítási kéréseit) számolva könnyen meghatározható az eltelt idő. Természetesen nyilván kell tartani, hogy az adott óra szinkronizálva volt-e valaha, hiszen egy áramszünetet követő, a valóságtól teljesen független idő adatot hiba lenne felhasználni bármilyen vezérléshez. Az óra értékének tárolására a legkézenfekvőbb megoldás a napból eltelt másodpercek nyilvántartása lenne, hiszen ez a legkisebb időegység a rendszer működése közben. Sajnos egy nap másodperce nem tárolható el két bájtos integer alakjában, ezért mindenképpen bontás szükséges. Adódik az ötlet, hogy az emberi szem számára megszokott óra:perc:másodperc alakot kellene használni, azonban ez felesleges konverziót jelentene a percek órára váltása miatt, ezért az időt a napból eltelt percek (két bájton), és az ezen felüli másodpercek alakjában tartom nyilván. Az ismertetett szoftver megvalósítás azonban nem működik a SENSOR egységeken egy korábbi tervezői döntés miatt: a SENSOR egységek a hozzájuk tartozó szenzor modulok adatainak begyűjtése során a bemenő portot egy késleletetés nélküli ciklusban folyamatosan

37 2. A harmadik szint tervezése 32 mintavételezik. Ez azt jelenti, hogy a mintavételezés idejére le kell tiltani minden megszakítást, hiszen egy ilyen elronthatja a mérést. A megszakítás letiltása alatt a Timer egység jelzései nem kerülnek feldolgozásra, így a beépített óra hamar pontatlanná válhat. A SENSOR órájának elcsúszásához hasonló problémával a SMART esetén nem kell szembenézni, mivel a SMART-hoz nem kapcsolódnak szenzor modulok, és más, a megszakítások hosszabb letiltását igénylő feladatai sincsenek. A probléma kezelésére megoldást jelenthet a SENSOR egységek megfelelően gyakori szinkronizálása a SMART órájához, azonban ennek a megoldásnak az elfogadása előtt tekintsünk egy másik alternatívát. A probléma kiküszöbölhető, amennyiben az asztali szellőztetésről nem a SENSOR-ok döntenek, hanem ezt a vezérlési feladatot is a SMART látja el. Ez egyébként reális megoldásnak tűnik, hiszen az ilyen időzített szellőztetést minden asztalon egyszerre kell működtetni, tehát a SMART egy broadcast üzenetben könnyedén felszólíthat mindenkit a ventillátorok bekapcsolására. E megoldás előnye, hogy nincs szükség a SENSOR-okon órákra, ezzel tehát megtakarítható például a buszon az óraszinkronizálás kezelése. Az asztalszellőztetés vezérlésének a SMART-ra ruházásával szintén megtakarítható a hozzá tartozó vezérlési paraméterek rögzítése az összes SENSOR egységen, ehelyett ezeket csak a SMART-nak kell tárolnia. A megoldás hátránya, hogy a SMART vagy a busz kiesése esetén az asztalszellőztetés is teljesen kiesik, noha a SENSOR egységeknek lehetőségük lenne azt önállóan is működtetni. A jóval egyszerűbb megvalósítás érdekében úgy döntöttem, hogy elég ha csak a SMART rendelkezik órával, és ezáltal hozzá kerül az asztalszellőztetés teljes vezérlése is. A SENSOR moduloknál tehát egyedül az ultrahangos párásítás vezérlése maradt, ezáltal a szabályozási szerkezet is letisztultabb lett: a SMART vezérel mindent, amit a referenciahőmérséklet vagy az óra alapján kell működtetni, a SENSOR pedig egyedül felelős a helyben mért páratartalom adatok alapján a helyi ultrahangos párásítás vezérléséért Számábrázolás A hőmérsékleti értékekkel kapcsolatban felmerülhet a probléma, hogy a szenzor modulok alkalmasak fél fok pontossággal rögzíteni a mérési eredményeket, azonban ezeket célszerű lenne egyetlen bájt átvitelével továbbítani a hálózaton. (A páratartalom és a megvilágítás értékek százalékban értendőek, így ott a tört részeknek jóval kisebb szerep jut, mint a belső légtér C között mozgó hőmérséklete esetén.) A probléma megoldására a szenzor modulok mintavételezése után előálló érték kétszeresét, kerekítve küldöm át a hálózaton, így a fél fok pontosság megmarad. A módszer megfelelő, hiszen így a -63 C-től +64 C-ig terjedő tartomány fél fok pontossággal leírható. A megoldás egyetlen mellékhatása, hogy a hőmérsékleti értékeket felhasználásuk előtt vissza kell alakítani eredeti formájukra. Az alacsony szintű szabályozás egyszerűségének köszönhetően azonban ezt a műveletet csak egy esetben, a referenciahőmérséklet visszaállítására kell e szinten elvégezni, hiszen itt csak ez kerül felhasználásra SMART Szinkron feladatok A SMART-nak három fő szinkron feladata van, melyek ütemezéséről önállóan gondoskodik. Az első egy listának a karbantartása, mely a többi egység állapotát rögzíti. A második a mérési eredmények rendszeres (5 perc időközönkénti) lekérése a többi egységtől, a harmadik pedig az alacsony szintű szabályozó algoritmus futtatása. A többi egységről vezetett nyilvántartásba két adatot kell rögzíteni minden frissítés alkalmával: az egységtől utoljára érkező üzenet óta eltelt időt, illetve az egység konfigurációjának azonosítóját. Amennyiben az adott egység egy bizonyos időnél régebb óta nem volt elérhető, akkor vele felesleges a továbbiakban normális kommunikációt

38 2. A harmadik szint tervezése 33 kezdeményezni, mivel a timeout-ra várakozás csak lassítja a működést. Természetesen az egység újraéledését célszerű időnként ellenőrizni, így amennyiben ismét elérhető, a kommunikációba újra bekapcsolódhat. Az ilyen jellegű ellenőrzések során különösebb plusz erőforrás használata nélkül lekérhető az egyes egységek konfigurációs azonosítója. Ahhoz azonban, hogy a konfigurációs azonosító minden egység esetében a valóságot kellően frissen tükrözze, szükség van minden egység az elérhetőket is beleértve rendszeres ellenőrzésére. Ez a rendszeres ellenőrzés és táblázat karbantartás tehát a SMART első feladata. Meg kell jegyezni, hogy a SMART egyedül nem képes egy érvénytelen konfigurációval rendelkező eszköz szinkronizálására, mivel ehhez rendelkeznie kellene az összes konfigurációval, ami jelentős mennyiségű memóriát igényelne. Az ilyen jellegű problémák kezelésére egy magasabb szinten futó a PC-n tárolt konfigurációkhoz könnyen hozzáférő szolgáltatásra van szükség, mely a SMART-tól rendszeresen lekérdezi a frissítést igénylő egységek listáját, majd azoknak érvényes konfigurációt küld. A második szinkron feladat viszonylag egyszerű: az összes többi egységtől be kell gyűjteni a pillanatnyi mérési értékeket és a beavatkozó szervek állapotát (ezeket az információkat együttesen a továbbiakban állapotvektornak nevezem). Ezt az információt kell kérés esetén továbbítani a PC felé, illetve ebből egyetlen adat, a referenciahőmérséklet alapján működik az alacsony szintű szabályozás. A PC felé továbbított, az egységektől kapott állapotvektorok egyesítése és a SMART állapotát leíró értékek hozzáadása után előálló globális állapotvektor pontos felépítését az F.5. függelék ismerteti. Az utolsó szinkron feladat az alacsony szintű szabályozás futtatása. Ez két különböző periodicitású feladatcsoportra bontható: vannak percenként, illetve ötpercenként ellátandó feladatok. Az utóbbi nyilvánvalóan a friss mérési eredmények feldolgozását és az adatok felhasználását jelenti. Az előbbi, gyakoribb beavatkozást az egyes periodikus beavatkozások vezérlése teszi szükségessé: az asztalszellőztetés, a felső párásítás és az útpárásítás működése periodikus. Egy bekapcsolt időszakot minden esetben egy hosszabb várakozási idő követ. A felhasználótól túl erős megszorítás lenne azt megkövetelni, hogy ez a várakozási idő öt perces egységekben mérhető legyen, és bizonyos szervek esetén ez nem is reális. Célszerű lehet például nagy melegben a felső párásítást akár hárompercenként is bekapcsolni néhány másodpercre, amire az öt perces ütemezés mellett nem lenne mód. Az alacsony szintű szabályozással kapcsolatos feladatokat az alábbi ábra foglalja össze. Jól látható, hogy a feladatok jellegük alapján a két csoportba sorolhatók: 5 percenkénti vezérlést igényelnek azok a beavatkozó szervek, melyek vezérlése állapotok közötti váltást idéz elő. Az egy perces csoportba kerültek azok a szervek, melyek vezérlése bizonyos idejű bekapcsolt állapotot eredményez, amit várakozási állapot követ. 5 percenként 1 percenként Ablak Árnyékolás Fűtés Riasztás SMART Felső párásítás Asztalszellőztetés Útpárásítás ábra: Az alacsony szintű szabályozás feladatainak ütemezése

39 2. A harmadik szint tervezése 34 Aszinkron feladatok Az aszinkron feladatok minden esetben valamilyen üzenet hatására elinduló feladatok. Mivel a mikrokontrolleres egységeket összekötő buszon a SMART a master szerepét tölti be, a busz felől nem érkezhetnek aszinkron események. Az aszinkron feladatok indítója így egyedül csak a PC-től kapott üzenet lehet. A PC által elküldhető összes lehetséges üzenetet az F.2. függelék részletesen ismerteti, így itt csak a normál működés során előforduló üzenetek felsorolására szorítkozom: 1. konfigurációt tartalmazó üzenet leküldése a SMART-nak vagy egy másik egységnek, 2. a SMART óráját szinkronizáló üzenet, 3. a magas szintű szabályozás állapotát jelző üzenet (közvetve az alacsony szintű szabályozás engedélyezése vagy letiltása), 4. az egységek konfigurációs azonosító számát lekérő üzenet, 5. az ablakokat vezérlő üzenet, 6. a felső árnyékolást vezérlő üzenet, 7. a fűtést vezérlő üzenet, 8. az útpárásítást vezérlő üzenet, 9. a felső párásítást vezérlő üzenet, 10. a szellőztetést vezérlő üzenet, 11. a riasztást vezérlő üzenet, 12. a globális állapotvektort lekérő üzenet. Az 1. üzenet tartalmát a SMART EEPROM-jában kell rögzíteni vagy továbbítani kell azt a megcímzett egysége felé. Az óraszinkronizáció az óraváltozók frissítését jelenti, és csak a SMART-ot érinti, hasonlóan a magas szint állapotának jelzéséhez. A konfigurációs azonosítók lekérése során a szinkron feladatként nyilvántartott lista elemeit kell továbbítani, így a magasabb szint el tudja dönteni, hogy kinek kell konfigurációfrissítést küldenie. Az üzeneteket egyszerűen továbbítani kell a STRONG-nak, aki a megfelelő beavatkozást végrehajtja. A 12. üzenet hatására a legfrissebb globális állapotvektor elküldésével kell válaszolni a vektor ilyenkor csak elküldésre kerül, a frissítéséről az öt percenként ütemezett adatlekérés gondoskodik SENSOR Szinkron feladatok A SENSOR egység szinkron feladatai jóval egyszerűbbek, mint a SMART esetében. A SENSOR-nak percenként méréseket kell végeznie, és döntenie kell az ultrahangos párásítás vezérléséről mindkét hozzá tartozó asztal páron. A bekapcsolás feltétele, hogy a páratartalom a kívánatos szint alatt legyen, és a legutóbbi párásítás óta kellően hosszú idő teljen el. A feladatot kismértékben bonyolítja, hogy az ultrahangos párásítás és az asztalszellőztetés működési ideje másodperces egységekben határozható meg, így bekapcsolás után másodpercenként ellenőrizni kell, hogy nem járt-e le valamelyik időzítő. Aszinkron feladatok A SENSOR egység aszinkron feladatait a buszon az egységnek (vagy broadcast során mindenkinek) címzett üzenet vétele inicializálja. A normál működés során a SENSOR az alábbi üzeneteket fogadja: 1. kapcsolattesztelő és konfigurációs azonosítót lekérő üzenet, 2. az állapotvektort lekérő üzenet, 3. konfigurációt vagy konverziós táblázatot tartalmazó üzenet, 4. asztalszellőztetést vezérlő üzenet. A kapcsolattesztelő üzenet segítségével tartja nyilván a SMART az elérhető egységeket, illetve a PC ezen keresztül értesül az elavult konfigurációval rendelkező egységekről. Az

40 2. A harmadik szint tervezése 35 állapotvektor lekérésére válaszként elküldött adatokat a SMART a globális állapotvektor megfelelő pozícióira helyezi, majd így továbbítja a PC felé, amikor az a teljes rendszer állapotát kéri le. A konfigurációt vagy táblázatot tartalmazó üzenet tartalmát az EEPROM megfelelő helyére kell eltárolni. Az asztalszellőztetést vezérlő üzenet hatására a szellőztetést a paraméterként kapott időre aktiválni kell STRONG Szinkron feladatok A STRONG két szinkron feladattal rendelkezik: percenként le kell kérnie a hozzá tartozó szenzor modulok mérési eredményeit (pontosan úgy, ahogy a SENSOR-ok is teszik), illetve másodpercenként ellenőriznie kell az esőérzékelőre kötött bemenetét, valamint a párásításokhoz rendelt számlálók értékét. Amennyiben az esőérzékelő csapadékot jelez, az ablakokat teljesen be kell zárni, és a jelzés megszűnéséig nem lehet kinyitni. Ha a párásítási számlálók (a párásításból hátralevő másodperceket nyilvántartó) értéke nem nulla, akkor a számlálót csökkenteni kell, illetve nulla értéke esetén a párásítást le kell állítani. A STRONG esetében a szenzor modulok percenkénti lekérése nem magától értetődő, mivel a SMART a mérési eredményeket csak 5 percenként gyűjti össze. (A SENSOR esetében ez a kérdés nem merülhetett fel, mivel ott a begyűjtött adatok alapján percenként születik döntés az ultrahangos párásítással kapcsolatban.) A gyakori mérés oka az, hogy amikor a SMART lekéri a mérési értékeket a szokásos 5 perces ütemezésben, azok sosem lesznek régebbiek egy percnél, így érvényesnek tekinthetőek. A percenkénti mérés elkerülhető lenne, ha a SMART az adatok begyűjtése előtt mindenkit felszólítana mérésre ilyen üzenet van a 485 protokollban a konverziós táblázatok létrehozásának meggyorsítása érdekében. Ezt a funkciót azonban felesleges lenne kizárólag a STRONG kedvéért megvalósítani, ehelyett inkább a STRONG a SENSOR-okhoz hasonlóan, percenként lekérdezi a szenzor moduljait. Aszinkron feladatok A STRONG aszinkron feladatait, a SENSOR-okhoz hasonlóan, a buszon kapott üzenetek aktiválják. Normál működés során az alábbi üzenetekre kell reagálnia: 1. kapcsolattesztelő és konfigurációs azonosítót lekérő üzenet, 2. az állapotvektort lekérő üzenet, 3. konfigurációt vagy konverziós táblázatot tartalmazó üzenet, 4. a felső ablakok kívánatos állapotát tartalmazó üzenet, 5. a felső árnyékolás kívánatos állapotát tartalmazó üzenet, 6. a fűtés kívánatos állapotát tartalmazó üzenet, 7. az útpárásítás kívánatos állapotát tartalmazó üzenet, 8. a felső párásítás kívánatos állapotát tartalmazó üzenet, 9. a riasztás kívánatos állapotát tartalmazó üzenet. Az első három üzenet hatása teljesen azonos a SENSOR esetében leírtakkal. Az ablak és az árnyékolás új állapotának beállítása a beavatkozó szervek lassú mozgása miatt a következő módon történik: a vezérlés beállítja a motor irányát meghatározó irány relét, majd beindítja a motorokat a mozgató relével. Ezután, ha valamelyik végállásba kell mozgatni, akkor a mozgás a motorokkal összekapcsolt végállás kapcsolóknak köszönhetően magától leáll. Ilyenkor is célszerű néhány perc után a feszültséget levenni a motorokról a relék terhelésének minimalizálása érdekében. Amennyiben nem végállásba történik a vezérlés (ablak esetén 1/3 nyitottság, ernyő esetén 90% árnyékolás), akkor folyamatosan (másodpercenként) figyelni kell a félállásjelző mikrokapcsolót, melynek jelzése esetén azonnal le kell állítani a motort. (A jelzés nagyjából 10 másodpercig aktív, így az 1 másodperces mintavételezés biztosan elég.) Felmerülhet a kérdés, hogy a mikrokapcsolókat lehetséges-e kiváltani egyszerű időzítő programrészekkel: amennyiben ismert lenne az ablak vagy az árnyékolás bizonyos állapotba

41 2. A harmadik szint tervezése 36 mozgatásának ideje, akkor elég lenne annyi ideig működtetni a motort. Sajnos erre jelen esetben nincs lehetőség, mivel nem garantálható, hogy az eszközök mindig azonos időt igényeljenek az azonos állapotba mozgatáshoz. Erre konkrét példa, hogy a téli hónapokban a hóval megterhelt ablak teljes kinyitása a szokásos 90 másodperc helyett jóval 100 másodperc feletti időt igényel. A fűtés vezérlése egyetlen kimeneti porton történik. A párásítások működtetéséhez számlálókra van szükség, melyek nyilvántartják a hátralevő időt, és annak leteltekor a párásítást befejezik. A riasztás kimenet vezérlése egyelőre nem meghatározott a külső riasztó egység hiánya miatt. A 4-6. és 9. üzenetek egy kívánatos állapotot jelölnek meg ahelyett, hogy konkrét mozgató parancsokat adnának. A megoldás előnye, hogy a STRONG-ra van bízva, hogy mit tesz a parancs vételekor. Amennyiben ő tudja és valószínűleg ő tudja legjobban, hogy az adott szerve a megfelelő állapotban van, akkor nem tesz semmit. Ha a SMART mozgató parancsokat küldene, akkor a SMART újraindulása esetén, vagy egy üzenet többszöri továbbítása miatt a beavatkozó szervek a kívánatostól eltérő állapotba kerülhetnének Kalibráció A szenzor modulokkal kapcsolatban álló egységeknél szükség van minden modulhoz egy konverziós táblázatra, mely alapján a mintavételezett periódusidő és kitöltési tényező függvényében meg lehet határozni a mért fizikai értékeket. Ezek a táblázatok az egyes érzékelő alkatrészek eltérése miatt nem hozhatók létre globálisan, egy példányban, hanem azokat minden egyes szenzor modulhoz a kalibráció során külön meg kell alkotni. A kalibrációs folyamat közben a szenzor modulokat ismert hőmérsékletű, páratartalmú és megvilágítási erősségű környezetbe kell helyezni, majd a mért nyers értékek rögzítése szükséges. Ezeknek a kiolvasására létezik egy-egy üzenet mindkét protokollban. (A PC és a SMART közötti COM protokollban annak ellenére is szükség van ilyenre, hogy a SMART nem kapcsolódik szenzor modulhoz, mivel a PC csak így tudja a SMART-ot felszólítani a slave egységek lekérdezésére.) A bemérési folyamat gyorsítása érdekében minden érintett egységen egy további parancs értelmezett, melynek hatására azonnal megtörténik a szenzor modulok mintavételezése, így nem szükséges a nyers adatok lekérésével minden esetben megvárni az egy percenként ütemezett mérési időpontot. A mért nyers értékek és az ismert fizikai paraméterek tükrében már meghatározhatóak minden szenzor modulhoz a konverziós táblázatok, melyeket a konfigurációval teljesen azonos módon juttat el a PC az egységekhez. Természetesen minden szenzor alkatrészhez külön táblázat tartozik, ami mind a SENSOR, mind a STRONG esetében 8 táblázatot jelent, melyeket az EEPROM-ban a konfiguráció mellett kell elhelyezni. Ahogy azt az F.4. függelék részletesen bemutatja, az egységek konfigurációja jelenleg 29 illetve 21 bájt helyet igényelnek. Amennyiben az esetleges későbbi fejlesztések lehetőségére tekintettel mindkét egységben 56 bájtot fenntartok a konfigurációnak, akkor a 8 táblázatra az 512 bájt EEPROM memóriából 456 bájt marad, ami táblázatonként 57 bájt. Az egyes konverziós táblázatok számára rendelkezésre álló 57 bájt összesen 19 bejegyzést tesz lehetővé, hiszen a kitöltési tényező vagy a periódusidő a tartományban mozog, míg a fizikai értéket egy bájton (de fél fok pontossággal) ábrázolom. A 19 bejegyzés a hőmérséklet esetében a teljes C tartományt 3 fokos lépésközzel képes ábrázolni, ami már önmagában is jó közelítés. A konverzió pontossága tovább növelhető, amennyiben a frekventáltabb hőmérséklet tartományokban finomabb felbontást alkalmazok, illetetve a felbontás finomsága az egyes szenzor modulok között is eltérő lehet: a külső hőmérséklet mérésekor a C a lényegesebb, beltéren viszont a C tartomány a fontos. A páratartalomra és a megvilágításra alkalmazott százalékos ábrázolási mód esetén a

42 2. A harmadik szint tervezése bejegyzés majdnem 5%-os felbontást tesz lehetővé, ami a szenzor alkatrészek pontosságával közel azonos, így a hiba elhanyagolható marad. A kalibrációt egy Windows operációs rendszer alatt futtatható saját fejlesztésű grafikus segédprogram, a greendiagnostics teszi kényelmesebbé, melyet az F.7. függelék mutat be Hibakeresés, tesztelés Általános megfontolások A hibakeresés és a tesztelés feladatainak megkönnyítésére célszerű az egységek programjában néhány, a normál működés során nem szükséges funkciót is implementálni. Ezeket a rendszer bevezetése során eltávolíthatóak, azonban megtartásuk a telepített rendszer helyszíni diagnosztizálását, esetleges további tesztelését segítheti Hibakeresés A rendszer működése során a hibakeresési feladat összetett lehet: hibák előfordulhatnak a futtatott programokban és a tesztkörnyezetben is (hibás bekötések, alkatrészek). A második eset elkerülésére az egyes kapcsolásokat célszerű először próbapanelen megépíteni, és csak működő megoldásokat véglegesíteni. A programhibák a végleges hardveren futó program esetében akár a telepítési helyszínen is felszínre kerülhetnek. A mikrokontrollereken futó programok hibakeresése jóval bonyolultabb, mint a PC-n futó társaik esetében, vannak azonban professzionális megoldások, melyeket az ATmega család is támogat. Ilyen professzionális eszköz egy JTAG debugger, melynek segítségével az éppen futó program hibakeresése kényelmesen, a PC-n elvégezhető. Sajnos a JTAG debuggerel kapcsolatban két probléma is felmerül: egyrészt az eszközt meg kell vásárolni, másrészt pedig a csatlakoztatása a kontrollerhez négy I/O portot lefoglal. Ez a SMART és a SENSOR esetén nem is lenne probléma, azonban a STRONG esetében a csatlakoztatáshoz szükséges portok már foglaltak. (Természetesen kompromisszumot lehetne kötni a később kifejlesztendő funkciók számára fenntartott tartalék portok számának csökkentésével, azonban ez hosszú távon nem biztos, hogy jó döntés lenne.) A JTAG debugger jó univerzális eszköz a program hibakeresésére, de az említett két negatívum ismeretében tekintsünk egy a feladathoz jobban illő megoldást. A hibakeresés során általában két fontos kérdés merül fel: Hol tart éppen a program, illetve milyen változó értékeken dolgozik? Mindkét kérdésre a válasz a mikrokontrolleren futó program számára ismert, így egy megfelelő üzenet segítségével bármikor lekérhető. A program pillanatnyi állapotának meghatározása nem feltétlenül szükséges programsor pontossággal. Jelen esetben elég azt tudni, hogy pontosan melyik ütemezett feladat végrehajtása folyik, ez pedig az egyes ütemező számlálók aktuális értékének ismeretében könnyen megállapítható: az a feladat fut, melynek számlálója éppen nullán áll. A pillanatnyi programállapot ismeretén kívül szükség van az aktuális változó értékekre, melyek nagyrészt az egység állapotvektorában találhatóak, hiszen a program általában mérési eredményeket használ működése során. Összességében elmondható, hogy jó közelítéssel meghatározható a program állapota az időzítő számlálóinak és állapotvektorának ismeretében. Amennyiben ezek értékeit bármikor képes egy parancs hatására a SMART közreműködésével a PC felé továbbítani, akkor a hibakeresés külső alkatrészek nélkül általában kielégítő hatékonysággal megoldható. A hibakeresési célra szolgáló legfontosabb üzenet az eddigiekben ismertetett állapotlekérés. Ezen kívül néhány egyszerűbb funkciót is célszerű hasonló módon implementálni a kommunikációs protokollban. Ilyen feladat például a kommunikációs vonalak tesztelése, a konfigurációként vagy konverziós táblázatként kiírt EEPROM tartalom

43 2. A harmadik szint tervezése 38 visszaolvasása, illetve a SMART-on karbantartott (elérhetőségi, konfigurációs) táblázatok közvetlen lekérése. Az egyes protokollokban implementált összes üzenetet a hibakeresést támogatókat is beleértve az F.2. és F.3. függelékek ismertetik. A hibakeresés támogatására, az egyes állapotvektor értékek átlátható megjelenítésére az F.7. függelékben ismertetett greendiagnostics program alkalmas Tesztelés A rendszer bevezetését megelőző fontos lépés a tesztelés, melynek során az elkészült hardver-szoftver komponensek működésének, illetve együttműködésének verifikálása történik. A tesztelés során a működést a későbbi valós környezettel megegyező körülmények között kell ellenőrizni. Ez hagyományos PC-n futó programok esetében ahol a bemenetek fájlokból, adatbázisokból vagy felhasználói beavatkozásokból származnak közel sem olyan problémás, mint egy beágyazott rendszer esetén, ahol a mikrokontrollerek portjaikon várják a bemenő paramétereket. A tesztelés megvalósítására két lehetőség adódik. A programok és a hardverek tesztelését elvégezhetem külön-külön, aminek során a hardvereket egyszerű tesztprogramok futtatásával ellenőrzöm: egy tesztalkalmazás a kommunikáció a buszon, egy másik az EEPROM írása, egy harmadik a beavatkozó szervek működtetése és így tovább. Amennyiben a hardver a szükséges feladatok ellátására képes, akkor teljesen szeparált módon kezdődhet a szoftverek tesztelése. Ennek során a szoftvereket a PC-n futtatva, számukra megfelelő tesztkörnyezetet kell létrehozni, ahol a szükséges bemeneteket egy keretprogram adja át a tesztelt programnak. Tekintettel arra, hogy a kontrollereken futó program is C-ben íródik, a mikrokontroller specifikus részük átalakítása után a fordítás egy normál C fordítóval elvégezhető. A vázolt első megoldás egyértelmű előnye, hogy függetleníti a hardver és a szoftver tesztelését, ezáltal a hibajelenségek szoftveres vagy hardveres eredete egyértelműen meghatározható. A megoldás hátránya, hogy el kell készíteni a mikrokontrolleres programot PC-n futtató teszt keretrendszert, melynek komplexitása a kontrollereken futó programok komplexitásánál jelentősen nagyobb lehet. A keretrendszerben futtatáshoz minden eredeti programot át kell alakítani a kontroller specifikus részek kihagyásával (például megszakítás vektorok átalakítása egyszerű függvényhívássá, melyet a keretrendszer meghív a megfelelő pillanatban), majd ezeket az átalakításokat a tesztelés végén vissza kell állítani. Annak megoldása, hogy a megszakítások a program futása során bármikor beérkezhessenek további problémákat vet fel. Az előbbiekben vázolt megoldás megvalósításának nagy munkaigénye miatt felmerülhet egy kompromisszumos megoldás lehetősége, melynek során a hardver és szoftver tesztelése nem különül el nagymértékben egymástól, így nincs szükség a programokat futtató külön keretrendszerre sem. Az ötlet az, hogy fusson minden program a neki szánt végleges hardveren, így csak a megfelelő bemeneteket kell szimulálni számára. Mivel ez a fizikai bemenő vonalakon nehézkes lenne például a szenzor modultól jövő jelet kellene a szenzor bemenet lábakra kötni, ezért a bemeneteket is (a kontrolleren futó) szoftverből kell szimulálni. Ez egyszerűen megoldható, mindössze a programok adat bekérő részeit kell egy konstans adat beállításával kicserélni. A megoldás hátránya, hogy amennyiben az olvasott adatot változtatni kell, az a program módosításával jár, melyet fordításnak és a kontrollerre töltésnek kell követnie. E nehézség kivédhető egy rugalmasabb megoldás alkalmazásával: a bemenetek értékét az aktuális tesztelés során nem a programba bevasalt módon kell rögzíteni, hanem dinamikusan például a memóriában kell tárolni, így azok megváltozásáról a konrollert egy üzenet értesítheti a buszon. A tesztelés során előfordulhat, hogy a rendszert újra kell indítani, így ezeket a tesztelési paramétereket célszerű a konroller nem felejtő EEPROM memóriájában

44 2. A harmadik szint tervezése 39 tárolni. Természetesen célszerű a teszt üzemmód kikapcsolására is lehetőséget biztosítani, így a rendszer viselkedése rugalmasan tesztelhető. A két megoldás közül a második jóval könnyebben implementálható, így azt választottam. A tesztelő paramétereket az EEPROM-ban tárolom, és onnan kerülnek beolvasásra minden alkalommal, amikor szükség van rájuk. Ez valamelyest lassítja a működést, de a bemenetek olvasása viszonylag ritka esemény a program működése közben, így a megoldás elfogadható, ráadásul nem is foglalja feleslegesen az operatív memóriát. Az első bájt minden kontroller esetében azt jelzi, hogy a tesztelő módot aktiválni kell-e. Amennyiben igen (a jelző bájt értéke ilyenkor 1), akkor a további bájtokon tárolt adatok lesznek bemenetként felhasználva, míg a jelző bájt 0 értéke esetén a beolvasás a bemeneti portokról történik. A tesztelő paraméterek eltárolása teljesen azonos módon történik a konverziós táblázatokkal és a konfigurációkkal. Tehát a PC egy megfelelő, EEPROM tartalom tárolására felszólító üzenettel utasítja a megcímzett egységet az adatok megfelelő szintén a PC által kijelölt területre rögzítésére, így a tesztparaméterek módosításának megoldása nem igényel külön üzenettípust a buszon. A tesztelt egység kimeneteinek vizsgálata történhet a kimenetekre kötött LED-ek segítségével manuális megfigyelés által, vagy az állapotvektorokban rögzített beavatkozó szerv állapotok, illetve működési idők kiértékelésével. A kimenetek ellenőrzése során nem merülnek fel a bemeneteknél tapasztalt nehézségek. A különböző egységek konfigurációjának, és a konfigurációt közvetlenül követő, de attól függetlenül kezelt és továbbított tesztadatoknak felépítését az F.4. függelék részletezi. A tesztelési célokat szolgáló változók egyszerű módosítását a greendiagnostics teszi lehetővé a konfiguráció szabad szerkesztésére szolgáló ablakában (lásd F.7. függelék).

45 3. A magasabb szintek tervezése A magasabb szintek tervezése 3.1. A magasabb szintek feladatai Bevezetés Az előző fejezetben bemutatott harmadik szint önállóan képes az üvegház vezérlését működtetni, amennyiben az összes szükséges konfiguráció és konverziós táblázat a mikrokontrolleres egységek rendelkezésére áll. A konfigurációk és konverziós táblázatok eredetével azonban eddig még nem foglalkoztam. Ezeket a beállításokat valahol tárolni kell, illetve szükség esetén az igénylő egységek felé továbbításukról is gondoskodni szükséges. A dolgozat címében deklarált célnak megfelelően az egyes mérési adatok rögzítése, megjelenítése nem csak az üzemeltetés feladatainak ellátást segíti, hanem a magas szintű szabályozások fejlesztéséhez is ezek a mérési eredmények adják majd az alapot. Ennek következtében a magas szintű szabályozások számára az adatokat elérhetővé kell tenni. Az alacsony szint működési paramétereinek módosításához a felhasználó joggal tart igényt egy felhasználói felületre az üvegházban, ráadásul napjainkban már természetes elvárás a távoli hozzáférés lehetősége is. A távoli hozzáférés megvalósítására a legegyszerűbb megoldás egy webes felület létrehozása, mivel ez nem igényel különösebb kliens oldali támogatást. Az eddigiekben említett feladatok ellátása a mikrokontrolleres egységeket tartalmazó harmadik szint feletti szintekre hárul. E szinteken a jövőbeli magas szintű szabályozás nagy számítási igénye, valamint az eltárolandó adatok jelentős mennyisége miatt nem jöhet szóba mikrokontrollerek alkalmazása, így a feladatokat szükségszerűen egy vagy több számítógép látja el A magasabb szintek szoftver komponensei A bevezetésben felvetett problémák és hiányosságok kezelésére, a feladatok ellátására a számítógépen a következő szoftver komponensek alkalmazása szükséges: 1. Adatbázis: az adatok tárolásáért és a többi komponens számára elérhetővé tételéért felelős összetevő. 2. A harmadik szint kiszolgáló alkalmazása: feladata a harmadik szint rendszeres lekérdezése által a mérési adatok rögzítése az adatbázisban, valamint a mikrokontrolleres egységek igényeinek kielégítése (például konfiguráció hiánya esetén). Ezen túl ez az alkalmazás továbbítja a felhasználótól vagy a magas szintű szabályozástól érkező parancsokat a harmadik szint felé. 3. Naplózó alkalmazás: a többi szolgáltatás és a rendszer eseményeinek rögzítésére létrehozott szoftver komponens. 4. Üvegházi felhasználói felület: lehetőséget biztosít az üzemeltetésnek az alacsony szintű szabályozás paramétereinek helyszíni módosítására, és a pillanatnyi mérési eredmények lekérdezésére. 5. Távoli felhasználói felület: az üvegházi felhasználói felület szolgáltatásainak távoli elérésén túl felelős a korábbi mérési adatok, tendenciák megjelenítéséért az üzemeltetés számára. 6. Kliens oldali alkalmazások: céljuk a távoli felhasználói felület kényelmesebbé, hatékonyabbá tétele az üzemeltetés számítógépein. A továbbiakban megvizsgálom a feladatok elosztásának elvi lehetőségeit több számítógép között, illetve ismertetem a megvalósításra kerülő alternatívát. Ezt követi a hálózati infrastruktúra bemutatása, majd a megfelelő operációs rendszer kiválasztása után a

46 3. A magasabb szintek tervezése 41 fenti komponensek feladatait ellátó külső, illetve saját fejlesztésű programok leírása zárja a fejezetet A magasabb szintek hardver komponensei A számítógépek által ellátandó feladatokat jellegük és helyfüggésük alapján négy fő csoportra lehet osztani. Az első csoport közvetlenül, fizikailag kötődik az üvegházhoz. Ide tartozik minden olyan szolgáltatás, mely a mikrokontrolleres szinttel áll kapcsolatban (például egy korlátozott hosszúságú soros vonalon keresztül). Szintén ide tartozik a helyszíni felhasználói felület, mellyel szemben nem követelmény a korábbi mérési adatok elegáns megjelenítése és kiértékelése, mindössze a pillanatnyi értékek elérhetőségét, és a beavatkozások lehetőségét kell biztosítani. Ez utóbbi kitétel következtében a felhasználói felület erőforrásigénye alacsony szinten tartható, így a hasonlóan nem számítási- és tárigényes kiszolgáló alkalmazásokkal együtt sem igényelnek nagy teljesítményű hardvert. A második csoport az adatok kezelésével kapcsolatos feladatokat tartalmazza: ide tartozik a mérési és beavatkozási adatok tárolása, illetve elérhetővé tétele a többi szolgáltatás számára. Az adatok tárolását célszerű egy megfelelő klímájú szerverteremben megoldani, egy kellően nagy háttértárral rendelkező számítógépen. Az adatok biztonságáról gyakori biztonsági másolat készítéssel, vagy több, egymással szinkronizáló számítógéppel szükséges gondoskodni, mivel adatvesztés esetén a pótlás (mérések általi újra begyűjtés) sok időt igényel. A harmadik csoportba tartozó távoli felhasználói felületet biztosító komponenseket célszerű egy erre dedikált számítógépen megvalósítani, melynek azonban nagy sebességű kapcsolattal kell rendelkeznie az adatbázis felé. Ez a felület biztosít lehetőséget a felhasználónak a korábbi mérési adatok megjelenítésére, kiértékelésére, ami várhatóan gyakori adatlekérést igényel. Tekintettel az alacsony felhasználó számra hiszen a felület csak az üzemeltetés számára készül, a felhasználói felület működtetése nem igényel jelentősebb erőforrásokat. Az utolsó, negyedik csoportba a magas szintű szabályozáshoz kötődő komponensek tartoznak, melyek előreláthatóan komoly számításigénnyel rendelkeznek majd, ezért kellően nagy teljesítményű számítógépre célszerű őket elhelyezni. A naplózó alkalmazást a rendszerbe bevont össze számítógépre célszerű telepíteni, így minden érintett gép állapota bármikor ellenőrizhető. Amennyiben megfelelő számú számítógép áll rendelkezésre, akkor a feladatok optimális elosztását a 3.1. ábra szemlélteti. Az ábrázolt felépítést akkor lehet legjobban kihasználni, ha több üvegház kiszolgálására van szükség. Ilyenkor ugyanis az üvegházi egységeken kívül a többi komponenst mindaddig nem kell többszörözni, amíg erőforrásaik elegendőek a megsokszorozódó feladatok ellátására. Jelen alkalmazás mellett, amikor csak egy üvegház vezérlésére van lehetőség, a vázolt megoldás igen pazarló lenne, így célszerű összevonásokat kezdeményezni. Megfelelő kompromisszum az összes most megvalósításra kerülő funkciót tehát a még nem létező magas szinten kívül mindent egy számítógépre telepíteni. Az összevonás eredményeként létrejövő egyetlen számítógépet az üvegházi, helyi feladatok ellátásának szükségessége miatt kizárólag az üvegházba lehet elhelyezni. A magas szintű szabályozások számára a kapcsolódási lehetőséget az összevonás nem módosítja, míg az egyes komponensek közötti kommunikációt a hálózati kapcsolatok eliminálása egyértelműen csak pozitívan érinti, így ez az alternatíva kerül megvalósításra. A későbbiek során, esetleges bővítések esetén az egyes komponensek szétosztásának támogatására a pillanatnyi helyzettől függetlenül minden kommunikációt úgy kell megvalósítani, hogy az később a fentihez hasonló elosztott rendszerben is módosítás nélkül működőképes maradjon.

47 3. A magasabb szintek tervezése ábra: A feladatok optimális elosztása több számítógép között 3.2. ábra: A hálózati infrastruktúra

48 3. A magasabb szintek tervezése Hálózati infrastruktúra A 3.2. ábra mutatja be a hálózati infrastruktúrát, mely a rendszer helyi, illetve internet felőli elérhetőségéről gondoskodik. Az ADSL internet kapcsolatot egy D-Link modemen keresztül egy Netgear WLAN router osztja meg a beltéri számítógépek között. A router által létrehozott vezeték nélküli hálózaton keresztül kapcsolódik az üvegházi számítógép az internetre egy USB WLAN adapter segítségével. Az USB csatlakozás azért lényeges, mert ez teszi lehetővé, hogy a hálózati kártyát, pontosabban az azzal egybeépített antennát az üvegház legmegfelelőbb, legjobb vételi viszonyokkal rendelkező pontjára lehessen elhelyezni. Természetesen egy beépíthető például PCI buszra csatlakozó kártya antennája is áthelyezhető, ám az ehhez szükséges antennahosszabbító kábeleken jelveszteséggel kellene számolni, ami az előbbi esetben nem jelentkezik. A router rendelkezik egy egyszerű beépített tűzfallal, melynek használatával portok nyitására és átirányítására nyílik lehetőség. Az internet szolgáltató minden kapcsolódás alkalmával dinamikusan új IP címet ad, így a távoli eléréshez, az ingyenesen regisztrált green.dyndns.ws dinamikus DNS címet használom. A router önállóan képes a Dynadns dinamikus DNS szolgáltatóhoz kapcsolódni, és a módosult IP címet jelezni, így a regisztráción és a router beállításán túl további tennivaló ezzel kapcsolatban nincs. Az ábrán bemutatott topológiában látható az egyetlen kiszolgáló számítógép, mely mint már említettem szükségszerűen az üvegházban kerül elhelyezésre Operációs rendszer Az üvegházi számítógépen futtatott operációs rendszerrel szemben a következő elvárások fogalmazhatóak meg: 1. Megbízhatóság A megbízhatóság természetes követelmény egy olyan rendszerrel szemben, mely vezérlési feladatokat lát el, még akkor is, ha a számítógép önmagában nem missziókritikus komponens. 2. Biztonság A megbízhatósághoz hasonlóan a biztonság, azaz a külső támadásoktól való védettség is fontos, hiszen a rendszernek az internet felől állandóan elérhetőnek kell lennie. Természetesen a hozzáférés tűzfalas korlátozása által valamelyest javítható a biztonság, azonban bizonyos funkciók például a távoli felhasználói felület elérhetőségének korlátozása nem lehetséges. 3. Minimális erőforrásigény Az alacsony erőforrásigény célja a hardverköltségek alacsonyan szinten tartása. 4. Minimális költség A hardverhez hasonló módon az operációs rendszer költségeit is célszerű alacsonyan tartani. Például egy nyílt forráskódú rendszer választásával e költség teljesen eltűnhet. 5. Vezeték nélküli hálózati eszközözök támogatása Tekintettel arra, hogy a számítógép vezeték nélküli hálózaton keresztül csatlakozik az internetre, ezért elvárás, hogy az ilyen eszközök jó támogatottsággal rendelkezzenek. Külön előny, ha a rendszer önállóan is képes vezeték nélküli hálózatot kialakítani maga körül, vagyis képes hozzáférési pontként működni, mivel így a vezeték nélküli infrastruktúra meghibásodása vagy teljes hiánya esetén is elérhető marad. 6. A felhasználásra kerülő külső programok támogatása Nagy előny, ha az operációs rendszer mellé készen letölthetőek a későbbiekben ismertetett, külső forrásból származó programok, így nincs szükség azok forráskódból történő előállítására.

49 3. A magasabb szintek tervezése Szabványos fejlesztői felület a saját szolgáltatások implementálásához Az operációs rendszerrel szemben elvárás, hogy az ott elkészített saját fejlesztésű szolgáltatások a későbbiek során bármilyen hasonló szabványt alkalmazó operációs rendszerre a forráskód módosítása nélkül áthelyezhetők legyenek. Az ismertetett elvárásoknak megfelelő számos operációs rendszer közül az OpenBSD jelenlegi legfrissebb 4.1-es verzióját választottam, nem utolsósorban azért, mert ezzel a rendszerrel kapcsolatban már vannak tapasztalataim. Az OpenBSD egy BSD licenc alapján ingyenesen használható UNIX alapú operációs rendszer, melynek fejlesztése során a fő hangsúlyt a biztonságra helyezik. A rendszer alacsony erőforrásigényére garancia, hogy egy első generációs Pentium processzoron 32 MB memóriával már működőképes. A vezeték nélküli hálózati technológiák támogatásának bizonyítéka az alaprendszer által az i386 platformon jelenleg is közvetlenül támogatott 481 különböző vezeték nélküli hálózati kártya [21]. Az operációs rendszer telepítés után azonnal képes saját hozzáférési pontot létrehozni, valamint az ennek támogatására szükséges programok (például DHCP szerver) is elérhetőek külön letölthető csomagok formájában. A külső programok támogatottsága nem hagy kívánnivalót maga után, a hivatalos FTP szerveren a legkülönbözőbb célokra találhatóak azonnal felhasználható alkalmazások. A fejlesztői felület a POSIX szabványnak megfelelő, így az itt elkészített programok a későbbiek során bármilyen szintén POSIX standard platformon (tehát a legtöbb UNIX alapú rendszeren) újrafordíthatók és futtathatók Az adatbázis Architektúra A magasabb szintek feladatai között kiemelt helyen szerepel az adatok tárolása, hozzáférhetővé tétele. Ezt a feladatot meg lehetne oldani egy saját adatfájl tervezésével, melyet a szolgáltatásokat nyújtó programok mind elérnek. Látható, hogy a nagy mennyiségű mérési adat miatt ezt a tárolási megoldást komolyan optimalizálni kellene. Ezen kívül a külső komponensek illesztésével kapcsolatban, és a távoli gépeken futó program összetevők hozzáférésével is komoly nehézségek lehetnek. Jóval optimálisabb megoldásnak tűnik egy professzionális adatbázis kezelő rendszert alkalmazni, mely a legtöbb adattárolással kapcsolatos feladatot leveszi a szolgáltatásokat nyújtó programok válláról. Az adatok tárolására a világon legelterjedtebb nyílt forráskódú adatbázis rendszert, a GPL licenc alapján ingyenesen használható MySQL adatbázis kezelő rendszer 5.0. változatát választottam, mely az alábbi előnyökkel jár a saját fejlesztésű adattárolási megoldással szemben [22]: 1. Készen elérhető Ingyenesen beszerezhető, ráadásul az OpenBSD-hez csomag formájában is letölthető, így fordítása sem szükséges. 2. Távoli elérési lehetőséget biztosít Szinte minden professzionális adatbázishoz, tehát a MySQL-hez is lehetséges hálózaton keresztül csatlakozni, így az elosztott rendszer megvalósítás esetén is megoldott a kommunikáció. Amennyiben titkosított kapcsolatra van szükség, arra is van mód SSL használatával. 3. Jogosultságokat kezel A rendszer lehetőséget biztosít felhasználók létrehozására, akiknek a jogosultágait egyenként lehet szabályozni. Ezzel a módszerrel egyrészt megoldott az adatok védelme a jogosulatlan hozzáféréstől, másrészt az egyes kiszolgáló programokhoz más-más felhasználót rendelve, lehetőség nyílik a programok számára csak a feltétlenül szükséges

50 A 3. szintet kiszolgáló programok Felhasználói felületek 3. A magasabb szintek tervezése 45 jogokat biztosítani. (Így például a mérési adatok rögzítésére csak az alsó szintet kiszolgáló programnak lehet joga, míg azok törlése senki számára sem engedélyezett.) 4. Biztonsági másolat készítést, illetve szinkronizációt támogat A MySQL külön biztonsági másolat készítő eszközzel rendelkezik, melynek segítségével az adattartalom könnyedén, ütemezetten exportálható SQL parancsok alakjába. Több adatbázis szerver esetén a szerverek közötti szinkronizáció is megoldható Az adatbázis mint univerzális kapcsolódási pont Az adatbázis feladata értelemszerűen az adatok hatékony tárolása, ám a rendszerben egy másik nagyon fontos funkciót is ő fog ellátni. Tekintettel az előnyök között másodikként említett kényelmes távoli hozzáférésre, az adatbázis ideális kapcsolódási felületet biztosít az egyes szoftver komponensek között, függetlenül azok elhelyezkedésétől. A kapcsolatok jellegét az alábbi ábra szemlélteti. mérési adatok mérési adatok konfiguráció konverziós táblázat parancsok Adatbázis konfiguráció parancsok mérési adatok parancsok Magas szintű szabályozás 3.3. ábra: Az adatbázis, mint univerzális kapcsolódási felület A képen feltüntetésre kerültek az egyes komponensek által használt adatok, melyek vagy az adatbázisba kerülnek rögzítésre, vagy onnan olvasódnak ki. Ebbe a megközelítésbe egyetlen részlet nem fér bele: a parancsok átadása a felhasználói felület illetve a magas szintű szabályozás felől az alacsony szintek irányába, mivel azokat a gyors végrehajtás értelmében célszerű lenne közvetlenül a harmadik szint felé küldeni. Természetesen a parancsok rögzítése az adatbázisban szükséges a működés hatékonyságának utólagos kiértékelésére, ám nem tűnik hatékony megoldásnak a parancsokat az adatbázison keresztül küldeni. A fentiekben ábrázolt megoldás működőképességéhez a 3. szintet kiszolgáló programoknak folyamatosan figyelniük kell az adatbázist, hogy bármilyen változást, parancsot észleljenek. Az adatbázis figyelése rendszeres lekérdezéseket jelent az érintett táblákon. Ez könnyen kiválható lenne, ha az adatmódosító alkalmazások (a magas szint illetve a felhasználói felületek) értesítenék a kiszolgáló alkalmazást arról, hogy hol, milyen változtatást hajtottak végre. Ez a hatékonyságot növelő megoldás azonban felvetne néhány további problémát: 1. ki kellene alakítani egy protokollt a 3. szintet kiszolgáló programok és a többiek közötti jelzések átvitelére, 2. meg kellene oldani a programok közötti kommunikáció védelmét, például megfelelő titkosítás alkalmazásával,

51 3. A magasabb szintek tervezése külön művelettel rögzíteni kellene a kiadott parancsot az adatbázisban, 4. kezelni kellene a kiszolgáló programok elérhetetlensége esetén a megfelelően gyakori újraküldés megoldását. Ezzel szemben a fentiekben vázolt megoldás alkalmazása jóval egyszerűbb: a parancsot kiadó program az adatbázis megfelelő helyére egy bejegyzést tesz, melyet a kiszolgáló programok rendszeresen a gyors válaszidő érdekében például másodpercenként lekérdeznek. Amennyiben a kiszolgáló program egy parancsot lát, akkor azt végrehajtja, több parancs esetén pedig azok együttes hatása esetén előálló új állapotba vezérli a rendszert. Ezzel a módszerrel nincs szükség külön protokollra, sőt az egyes alkalmazásoknak az adatbázison kívül más hálózati erőforráshoz sem kell hozzáférniük. (Az adatbázis támogatja a titkosított kapcsolatok fogadását, így ezt sem kell külön megoldani.) A művelet rögzítése az adatbázisban természetesen megtörténik, mivel a végrehajtott parancsokat a végrehajtás tényének jelzése után nem szükséges törölni, azok később visszakereshetőek. Nincs probléma a kiszolgáló programok elérhetetlensége esetén sem, hiszen az adatbázis mindaddig megőrzi a parancsokat, míg azokat végre nem hajtják. Természetesen az előnyök mellett hátrányként jelentkezik az adatbázist érő folyamatos terhelés a rendszeres lekérdezések miatt. Ez a hatás azonban több okból is elhanyagolható: Egyrészt az adatbázis a normál működés során nincs leterhelve, ezért van szabad kapacitása, másrészt pedig a gyakran lekérdezett adatokat mind az adatbázis, mind az operációs rendszer (az adatfájlok formájában) gyorsítótárazza, így a rendszeres lekérdezések kiszolgálása kizárólag memóriaműveleteket igényel. Ettől a jelentéktelen hátránytól eltekintve a 3.3. ábrán vázolt megoldás csak előnyökkel rendelkezik, ezáltal az adatbázis a rendszer univerzális kapcsolódási pontjává válik Tárolt adatok Természetesen nem szabad megfeledkezni az adatbázis eredeti céljáról, az adatok tárolásáról. A MySQL relációs adatbázisokat kezel, azonban jelen alkalmazás mellett az adatbázis relációs voltát nem lehet kihasználni, mivel egymástól független adatok kerülnek eltárolásra a különböző táblákban. A továbbiakban az adatbázis tábláit mutatom be rövid leírással. cfgai: Ebben a táblában egyetlen érték tárolódik, mely a magas szintű (intelligens) szabályozás engedélyezettségét jelzi. A magas szintű szabályozásnak csak akkor szabad beavatkozásokat kezdeményeznie, ha ez számára engedélyezve van. A beállítson keresztül a felhasználónak lehetősége van a magas szint letiltására. cfgairing: A szellőztetéssel kapcsolatos összes paramétert tároló tábla. cfgalarm: A riasztások paramétereit (küszöb hőmérsékleteit) rögzítő tábla. cfgdesks: Az asztalok kihasználtságát, az ultrahangos párásító használata esetén az elvárt páratartalmat, a felső párásítás engedélyezettségét és az ultrahangos párásító összesített működési idejét tartalmazó tábla. Az összesített működési idő nyilvántartása az ultrahangos párásító egy utántöltését követő maximális működési idejének ismeretében lehetőséget biztosít a párásító egység víztartalékának meghatározására. A víztartalék ismeretében a rendszer módjában áll a felhasználót értesíteni az utántöltés szükségességéről. cfgheating: A fűtés két paraméterét tároló tábla. cfgmisting: A felső párásítás beállításait rögzítő tábla. cfgroadmisting: Az útpárásítás paramétereit tároló tábla. cfgsensortables: A konverziós táblázatok bejegyzéseit tartalmazó tábla. Minden rekordnál az eszköz és a tábla sorszáma azonosítja a táblázatot, majd egy mért érték és egy fizikai (konvertált) érték következik. cfgsensors: A SENSOR és a STRONG számára tartalmaz információkat a konverziós tábláik EEPROM-beli kezdőcíméről. Minden szenzor modulhoz egy rekord tartozik, mely

52 3. A magasabb szintek tervezése 47 mindkét tábla kezdőcímét tartalmazza, így lehetőség van a táblákat akár rendszer működése közben áthelyezni vagy átméretezni. cfgultrasonic: Az ultrahangos párásítás (globális) beállításait rögzítő tábla. Tartalmazza a globális engedélyezettséget, egy párásítás maximális idejét, a párásítások közötti kötelező várakozási időt és az egy feltöltéssel elérhető működési időt. cfguppershading: A felső árnyékolás beállításai. cfgupperwindows: A felső ablakok vezérlésének paramétereit tartalmazó tábla. ConfigChangeLog: Ebben a táblában kerül rögzítésre az alacsony szintű szabályozás konfigurációjának változási naplója. Az alacsony szint paramétereinek változásakor a módosítást végző folyamatnak kötelessége ebben a táblában (egy megjegyzés formájában) rögzíteni a változtatás leírását. Ennek célja, hogy a változások nyomon követhetőek legyenek a későbbiek során. Ezen túl az alacsony szinteket kiszolgáló program ezt az egyetlen táblát figyelve észlelheti a konfiguráció megváltozását. Amennyiben ebben a táblában egy új bejegyzés szerepel, akkor a kiszolgáló program újra beolvassa a teljes konfigurációt, és a megfelelő frissített adatokat kiküldi a 3. szint egységeinek. Commands: Ebbe a táblába írja be a felhasználói felület, illetve a magas szint az alacsonyabb szinteknek szánt parancsokat. Minden parancshoz tárolásra kerül a kiadó alkalmazás azonosítója, a kiadás ideje, a feldolgozás ideje (amikor a 3. szint számára továbbítva lett), illetve a 3. szint válasza (vagyis hogy érkezett-e nyugta). A 3. szintet kiszolgáló alkalmazás feladata, hogy egyszer megpróbálja továbbítani a parancsot a SMART felé. Amennyiben a SMART működőképes, akkor ez biztosan sikerül, mivel a soros vonali kapcsolat rövid és igen megbízható. Ezt követően a SMART feladata, hogy a parancsot végrehajtsa, vagy egy másik egységet a végrehajtásra utasítson. Végül a (közvetlenül vagy közvetett úton a) SMART tól érkező válasz a táblába bejegyezésre kerül. A parancsok a táblában a COM protokoll szerint megfogalmazott bájtok alakjában kerülnek be. Ez lehetne másként is például a legtöbb parancs azonosítható lenne egyetlen bájttal (ablak kinyitás vagy bezárása egy-egy parancs és így tovább), azonban ehhez egy újabb protokoll kidolgozása, illetve a soros portra továbbítás előtt egy konverziós művelet alkalmazására lenne szükség. DataLog: Ez a tábla tárolja a rendszer öt percenként lekérdezett állapotát: minden mért hőmérsékleti, páratartalom és megvilágítás érték, a beavatkozó szervek pillanatnyi állapota és a működési időtartamok is itt kerülnek eltárolásra. A rengeteg tárolt adat miatt a tábla nagyon sok attribútumot tartalmaz, ezért célszerűnek tűnhet az adatbázis relációs voltát kihasználva több részre darabolni: a hőmérsékleti értékek külön, a páratartalmak külön, a beavatkozó szerv állapotok külön, és így tovább. Ezt azonban mégsem teszem meg, mivel az egy időben mért adatok szorosan összetartoznak, ráadásul általában közösen van rájuk szükség, például a felhasználói felületeken az adatok megjelenítése során, vagy a magas szintű szabályozás lekérdezéseinek kiszolgálásakor. A gyakorlatban tehát a tábla feldarabolása miatt a felhasználáshoz rendszeresen számos (számításigényes) JOIN műveletet kellene végrehajtani. Ezzel szemben egyetlen tábla alkalmazásakor nincs szükség illesztésekre, azonban nagyszámú adat esetén a sok attribútum miatt a lekérdezési és beszúrási műveletek jelentősen lassulhatnak. Tekintettel arra, hogy az öt percenként végzett mérések hatására normál működés mellett öt percenként keletkezik egy új rekord, éves szinten bejegyzésre lehet számítani. Ezt a mennyiséget az adatbázisnak gond nélkül el kell bírnia, a további növekedést pedig célszerű a régebbi adatok archiválásával vagy utófeldolgozásával és tömörítésével meggátolni. (Amennyiben az utófeldolgozás az adatokat óránkénti bejegyzésekre tömöríti, akkor a rekordok száma máris 1/12-ére esik le.) siteusers: A távoli elérést nyújtó felhasználói felület felhasználóinak és jogosultságainak tárolására szolgáló tábla. (Ez független az adatbázishoz hozzáféréssel rendelkező felhasználók listájától.)

53 3. A magasabb szintek tervezése 48 SystemLog: A teljes rendszer működésével kapcsolatos napló, ahová bármelyik komponens szöveges bejegyzéseket rögzíthet, melyek a hibakeresést és a rendszer működésének elemzését segítik Saját fejlesztésű alkalmazások Általános megfontolások A fejezet elején, a pontban bemutatott szoftver komponensek közül számos nem szerezhető be készen, így azokat magamnak kell elkészítenem. Ezeknek a programoknak a jelenlegi rendszerfelépítés ismeretében mindenképpen működőképesnek kell lenniük az OpenBSD operációs rendszeren, azonban célszerű őket a későbbi áthelyezhetőség támogatására könnyen portolhatóra megírni. Az OpenBSD kiválasztása során szempont volt a POSIX szabványnak való megfelelősége, így ezzel feltehetően nem lesz probléma. A programok viszonylagos egyszerűségére tekintettel a fejlesztést C nyelven végzem, mivel ilyen kis feladatok esetén a C++ objektum orientált szemlélete inkább csak hátrány lenne. Az adatbázis elérését a MySQL adatbázissal együtt beszerezhető MySQL C API hívások segítségével könnyedén meg lehet oldani C nyelven. A programok fejlesztése során szem előtt kell tartani a későbbi áthelyezhetőség, illetve szükség esetén egy számítógépen több példány párhuzamos futtatásának lehetőségét is. Ez utóbbit támogató megoldásként a programok a legfőbb beállításaikat indítási paraméter formájában kapják meg, így ugyanazt a programot több különböző paraméterezéssel elindítva több üvegház is kiszolgálható egyetlen számítógépen. Az elkészült rendszer összes (külső illetve saját fejlesztésű) szoftver komponensét, valamint ezek kapcsolatát a 4.1. ábra szemlélteti greenhand A harmadik szint kiszolgálására megalkotott program a greenhand. Indítási paraméterei között megkapja a soros portot (UNIX rendszereken) reprezentáló fájl nevét, az adatbázis szervert futtató számítógép hosztnevét, az adatbázis nevét, illetve a hozzáféréshez szükséges felhasználói nevet és jelszót. A magasabb szintek részéről egyedül a greenhand áll kapcsolatban a 3. szinttel, így minden kommunikációval kapcsolatos feladat rá hárul. A fejezetben leírt megfontolások alapján a greenhand master-slave alapon kommunikál a SMART-al, tehát minden kommunikációt ő kezdeményez a COM protokoll használatával. A greenhand feladatai az alábbiak: 1. A SMART órájának rendszeres szinkronizálását (az óra szoftveres megvalósítása következtében) a megszakítások hatására létrejövő hiba indokolja. (Az órát léptető megszakítás mindaddig nem érvényesülhet, amíg egy másik megszakítás kiszolgálása olyan szakaszban tart, ahol a többi megszakítást nem engedélyezi.) A SMART óráját 12 óránként szinkronizálva a hiba öt másodperc alatt tartható. A greenhand elindulása után elsőként az órát szinkronizálja, mivel normál működés során joggal tételezheti fel az alábbiakat: a greenhand elindítását az operációs rendszer kezdeményezte újraindítás miatt, normál működés mellett az újraindítás legvalószínűbb oka a hálózati feszültség kimaradása, a hálózati feszültség kimaradása miatt minden bizonnyal a SMART is újraindult, így az órája szinkronizálatlan állapotban van.

54 3. A magasabb szintek tervezése A konfiguráció felhasználó általi megváltozásának észlelése érdekében a greenhand percenként ellenőrzi az adatbázis ConfigChangeLog tábláját. Amennyiben új bejegyzés került a táblába, lekéri az összes többi konfigurációs tábla tartalmát, majd az érintett egységeknek konfigurációfrissítő üzenetet küld. Az ellenőrzés gyakoriságának meghatározásakor két szempontot kellett mérlegelni: túl ritka ellenőrzés mellett a felhasználónak sokat kell várnia a beavatkozásainak hatására, míg túl gyakori ellenőrzés esetén feltételezve, hogy a felhasználó egyszerre nem csak egy beállítást módosít a konfigurációfrissítő üzenetet minden egyes módosítás után a buszt terhelve továbbítani kell. Egy perc (ami a gyakorlatban átlagosan 30 másodperc várakozást jelent) a felhasználó számára elfogadható válaszidőt biztosít azzal a reálisnak tűnő feltételezéssel élve, hogy a felhasználó egy perc alatt egy átlagos, több paramétert is érintő módosítást el tud végezni. 3. A greenhand percenként ütemezett módon lekéri a SMART-tól a globális állapotvektor legfrissebb változatát, a kérésben megfelelően jelölve az általa ismert legújabb állapotvektor azonosítót. A COM protokollnak megfelelően, amennyiben a greenhand által küldött azonosító a legfrissebb, akkor a SMART csak egy nyugtával jelzi, hogy nincs mit küldenie, míg ellenkező esetben a legfrissebb állapotvektort tartalmazó üzenettel válaszol. A percenkénti lekérdezés célja, hogy a SMART öt percenként végrehajtott buszlekérdező ciklusa után korlátos időn belül a magasabb szintek rendelkezésére álljanak az adatok. Tekintettel a COM protokoll master-slave jellegére, a SMART nem jelezheti a greenhand felé egy új állapotvektor létrehozását, ezért egyetlen lehetőségként a lekérdezés marad. (Ez természetesen nem negatívum, a master-slave tervezés során külön cél volt, hogy a SMART-ra a magasabb szintek hibája vagy hiánya semmiképpen ne hasson még egy timeout-ra várakozás formájában se.) Az ily módon begyűjtött új adatok garantáltan nem idősebbek 2 percnél, hiszen a slave egységek egy percenként végeznek méréseket, és ehhez legfeljebb a greenhand lekérdezési ciklusának újabb egy perce adódhat hozzá. Az üvegház dinamikáját tekintve ez a maximális hiba elfogadható, az átlagos hiba (1 perc) pedig teljesen elhanyagolható. 4. A greenhand-re háruló utolsó feladat a 3. szinthez tartozó egységek konfigurációs igényeinek kiszolgálása. Egy mikrokontrolleres egység a rendszer indítása után kizárólag valamilyen különleges esemény (meghibásodás, újraprogramozás, kézi újraindítás) hatására veszítheti el a konfigurációját, illetve használhat érvénytelenné vált konfigurációt. A SMART feladatai között szerepelt az összes egység konfigurációs azonosítójának nyilvántartása, így a greenhand ezt a táblázatot lekérve állapítja meg, hogy mely egységeket kell frissítenie, majd a SMART-on keresztül frissítő üzeneteket küld. Tekintettel a konfiguráció frissítés szükségességének ritka voltára, a greenhand a konfigurációs azonosítókat tartalmazó táblázatokat csak öt percenként elemzi ki. A greenhand a fontosabb eseményeket a közös rendszernaplóban, az adatbázisban rögzíti (indítás, konfiguráció letöltés, konverziós táblázat letöltés, stb.), míg a pillanatnyi működéssel kapcsolatos részletes adatokat a standard outputján írja ki. Ezt a kimenetet fájlba átirányítva részletes működési napló rögzíthető későbbi feldolgozásra, illetve megfelelő elhelyezés esetén a távoli felhasználói felületen keresztül is rendelkezésre állhat. A greenhand rendszerindítást követő kimenetét mutatja be az F.8. függelék greenface A greenface az üvegházba telepített egyszerű felhasználói felület. A célja, hogy egyszerűen használható, kis erőforrás igényű felületet biztosítson az üvegházi személyzet

55 3. A magasabb szintek tervezése 50 számára a pillanatnyi állapot megismerésére, és az alacsony szintű szabályozás paramétereinek módosítására. A greenface indítási paraméterként kapja az adatbázist futtató gép hosztját, az adatbázis nevét, a hozzáféréshez szükséges felhasználói nevet és jelszót, valamint egy opcionális paraméterként lehetőség van kötegelt módban futtatni. A program egyszerű, karakteres terminálon megjeleníthető felülettel rendelkezik, melynek minden funkciója elérhető egy numerikus billentyűzet segítségével. (Különálló, a számítógéphez USB csatlakozóval kapcsolódó numerikus billentyűzet viszonylag olcsón beszerezhető, az OpenBSD pedig támogatja, mint billentyűzetet.) A program indulása után az alábbi, első ránézésre áttekinthetetlen, de minden lényeges információt tartalmazó képernyőt jeleníti meg Max H: Min H: 21.0 Átl H: % -- % -- % -- % -- % -- % -- % -- % Max P: 96 % Min P: 96 % UP77 FP UP60 FP FP UP65 Átl P: 96 % % -- % -- % -- % 96 % -- % -- % -- % -- % -- % UP UP90 UP90 UP90 UP HOL Fűtés H ---- P -- % F -- % Ernyő alatt 1 Ernyő alatt % -- % -- % 6 % Dátum: :56:20 3 perces adatok Ernyő felett Kültér % -- % -- % 2 % Belépés a menübe: [ 0 ] 3.4. ábra: A greenface felülete Az ábra a rendszer tesztelése során készült. Az egyetlen aktív szenzor a 6. asztalon került elhelyezésre, ahogy az a képernyőn vonalasan ábrázolt topológiából látható. Minden asztalon megjelenik a mért hőmérséklet, a páratartalom és a párásítás módja (FP = felső párásítás; UPxx = ultrahangos párásítás xx % páratartalom alatt). Két asztalonként, az asztalok közös sarkai között elhelyezett kétjegyű számérték az ultrahangos párásítás víztartalékát mutatja. A képernyő alján és jobb felső részén a ház globális adatai, illetve összesített értékek láthatóak. Mint azt felirat is jelzi a beállítások módosítására a menü a 0 gombbal nyitható meg. A felület igen egyszerű és karakteres jellege miatt az erőforrás igénye is szinte nulla. Természetesen jóval esztétikusabb, sőt jobban használható grafikus felületet is létre lehetne hozni (például színek segítségével a lényeges részek kiemelése által), és a módosítások elvégzése is kényelmesebb lehetne egy érintőképernyő segítségével. Ezek a fejlesztések a későbbiek során elvégezhetőek, azonban szeretném felhívni a figyelmet ennek az egyszerű felületnek két jó tulajdonságára: A karakteres felület egyszerűen elérhető egy távoli terminál segítségével is, például az üvegházi számítógépre SSH-n keresztül bejelentkezve. Ezáltal a távoli felhasználói felület kiesése esetén még mindig van lehetőség távolról beavatkozni. Szintén a karakteres felületnek köszönhető, hogy a program kimenete pontosabban jelen esetben a fő képernyője könnyedén átirányítható egy fájlba, melynek tartalma a távoli felhasználói felület meghibásodása esetén a távoli felhasználók

56 3. A magasabb szintek tervezése 51 számára is elégséges mennyiségű adatot szolgáltat. (Tekintettel arra, hogy a program alapértelmezetten interaktív módban indul el, szükséges egy opcionális indítási paraméter formájában tájékoztatni az alkalmazást arról, hogy kötegelt módban fut, ezért a főképernyő megjelenítés után ki kell lépnie.) A greenface képes tehát a legfrissebb mérési adatokat az üvegházban megjeleníteni, illetve az alacsony szintű szabályozás beállításait módosítani. Ezen túl egyszerű felületének köszönhetően alkalmas a távoli felhasználói felületet bizonyos megkötések mellett, meghibásodás esetén pótolni greenlog A greenlog egy egyszerű alkalmazás, mely elsősorban az operációs rendszer eseményeinek közös rendszernaplóba rögzítésére jött létre. A program indítási paraméterként kapja az adatbázis hozzáféréshez szükséges adatokat, továbbá az utolsó paraméterként egy szöveges megjegyzést vár, melyet a közös rendszernaplóba jegyez be. A bejegyzés rögzítése után az alkalmazás kilép. A greenlog segítségével és a közös rendszernapló használatával a teljes rendszer működése figyelemmel kísérhető, beleértve az újraindításokat, a felhasználói bejelentkezéseket, és az ütemezetten futtatott feladatokat, mint az adatbázis biztonsági mentése. A közös rendszernapló egy részletét az F.9. függelék mutatja be Távoli felhasználói felület Alapvető megfontolások A távoli felhasználói felület létrehozása történhetne hasonló módon, mint az előzőekben ismertetett saját fejlesztésű programok fejlesztése. Készíthetnék egy saját kiszolgáló alkalmazást, illetve egy kliens oldalon futó felhasználói felületet, melyek között egy újabb saját protokoll alapján folyna a kommunikáció. Ez a megoldás igen sok munkát igényelne, hiszen a kommunikáció megfelelő védelméről, vagy a kliens program minden érintett számítógépre való telepítéséről is gondoskodni kellene. Ezzel szemben felmerülhet alternatívaként egy jóval egyszerűbb megoldás, egy webes felhasználói felület képében. Ebben az esetben kliensprogram telepítésére nincs szükség (hiszen az a legtöbb felhasználó rendelkezésére áll), és a kiszolgáló programoknak is széles választéka áll rendelkezésre. A fejlesztés során kizárólag a felhasználói felület megjelenítésével, illetve a funkciók implementálásával kell foglalkoznom, így e megoldás mellett döntöttem A megvalósítás A rendszer központi magját egy Apache 1.3. webszerver alkotja, melyen belül az oldalak dinamikus létrehozására a PHP modul 4.4. verzióját használom. Az Apache a PHPhoz hasonlóan a MySQL adatbázis elérésére is rendelkezik modullal. A biztonságról a HTTPS protokoll használata gondoskodik, ehhez azonban tanúsítványokra van szükség. Ezeket egyszerűen létre lehet hozni, azonban hitelesítésükhöz külső szolgáltatókra van szükség. A külső szolgáltatók a hitelesítésért több tízezer Forintos összegeket számláznak ki, ami egy bank internetes oldala esetén nyilvánvalóan megtérülő befektetés, jelen esetben azonban túl magas költség. A tanúsítványokat tehát harmadik, megbízható fél hitelesítése nélkül használom fel: így a kiszolgáló hitelessége ugyan nem állapítható meg, de a titkosított kommunikáció algoritmikus erőssége nem csökken, tehát a jelszavak nem szerezhetőek meg primitív eszközökkel.

57 3. A magasabb szintek tervezése A felhasználói felület greensite A felhasználói felület egy PHP-ből generált webes oldal, mely a webszerver 443-as (HTTPS) portján érhető el, és a többi saját fejlesztésű komponenshez hasonló elnevezésként, a greensite nevet kapta. Az oldalra belépni csak felhasználói név és jelszó megadásával lehetséges. Az ilyen név és jelszó(lenyomat) párok az adatbázisban a siteusers táblában tárolódnak, és tartozik hozzájuk egy felhasználói szint azonosító szám is. Ez utóbbi lehetőséget ad a különböző felhasználóknak eltérő jogkör biztosítására. Jelenleg a 0 szint a vendég felhasználót jelöli, akinek csak az adatok megtekintésére van joga, míg az 5-ös szint minden jogot garantál, így a beállítások módosítása mellett akár közvetlen beavatkozó parancsok is kiadhatóak. A köztes szintek egyelőre nincsenek használatban, ám ha a későbbiek során szükségessé válik, akkor a felosztást lehet finomítani. A bejelentkezést követően az oldalon a legfrissebb adatok menüpont alatt elérhető információk jelennek meg, ahogy azt az alábbi tesztelés során készült képen is látni lehet: 3.5. ábra: A greensite bejelentkezés utáni kezdőlapja A webes felület minden lapján megjelenik a bal oldali sáv, ahonnan az egyes funkciók öt csoportra bontva érhetőek el. A legfelső csoportban van lehetőség jelszómódosításra és kijelentkezésre. Ez alatt a mérési adatok szekcióban az alábbi adatok kérhetők le: a (bejelentkezés után automatikusan megjelenő) legfrissebb mérési adatok, a ház korábbi mérési adatai és ezek előzményei, az asztalok részletes adatai és előzményei, az óránként, naponta vagy hetente összesített maximum és minimum mért értékek. A mérési adatok mellett ebben a blokkban kapott helyet néhány technikai napló is: A közös rendszernapló a rendszer globális állapotáról tartalmaz információkat a komponensektől származó adatok összegyűjtése által (lásd F.9. függelék). Lehetőség van a személyzet vagy a magas szintű szabályozás által kiadott parancsok állapotával kapcsolatban a következő adatokat megtekinteni (az adatbázisban

58 3. A magasabb szintek tervezése 53 Commands tábla): a parancs tulajdonosa, kiadási ideje, (a greenhand) feldolgozás ideje, tartalma, és az alacsonyabb szint válasza (nyugta vagy annak hiánya). Megtekinthető a konfiguráció változásainak naplója (ConfigChangeLog tábla). A greenface kötegelt módú kimenete (html fájl alakjában, mely hozzáférhető bejelentkezés nélkül is, hogy képes legyen a webes felületet meghibásodása alatt azt átmenetileg kiváltani lásd 3.4 ábra). A mérési adatok szekciója alatt található a Beállítások blokk, ahol külön oldalakon módosíthatóak az alacsony szintű vezérlés paraméterei az egyes beavatkozó szervekre. Ezután a közvetlen (felhasználói) beavatkozásokra lehetőséget nyújtó link következik, míg legalul mindig a ház legfontosabb és legfrissebb adatai láthatóak Grafikus adatmegjelenítés - greengrapher A mérési adatok táblázatos megjelenítése implementációs szempontból egyszerű, azonban egyáltalán nem átlátható, ezért a felhasználóknak természetes igénye, hogy az adatokat grafikusan ábrázolva is megkapják. A webes felület segítségével erre kétféle módon nyílik lehetőség. Az első alternatíva a grafikonokat ábrázoló képek szerver oldali előállítása, és a kliens felé képként továbbítása. A megoldás előnye, hogy a kliens oldalon nem igényel támogatást, cserébe azonban a szerver oldalon számítási erőforrásokat igényel. Az extra számítási igény a kérés kiszolgálását lassíthatja. A szerver oldalon a jelenlegi megvalósítás mellett a számítási kapacitáson az adatbázis, a webszerver és a kiszolgálói programok osztozkodnak. Ezzel szemben a kliens oldalán még egy napjainkban átlagosnak mondható számítógépen is bőven van kihasználatlan számítási teljesítmény, ami ilyen célra jól használható. Szintén nem elhanyagolható szempont, hogy az adatbázis vezeték nélküli kapcsolaton keresztül kommunikál a klienssel, így az adatok szöveges (jóval tömörebb) átvitele a kapcsolat jellege miatt is előnyösebb. Az ilyen lehetőségek kihasználására, a grafikonok kliens oldali generálására egy jelenleg még a fejlesztés kezdeti stádiumában álló Java applet szolgál, mely a mérési eredményeket megjelenítő weboldalakon a táblázatos adatok felett helyezkedik el ábra: A greengrapher fejlesztés alatt álló felülete a táblázatos adatok felett

59 3. A magasabb szintek tervezése 54 A kliens oldalon futó alkalmazás a Java-nak köszönhetően platform független, és a kliens részéről is csak a széles körben elterjedt Java futtató környezetet igényeli Kiegészítő kliens oldali megoldások A felhasználók számára a távoli elérést biztosító webes felület lehetővé teszi az üvegház felügyeletét anélkül, hogy a házat személyesen meg kellene látogatniuk. A fizikai jelenlét kiváltásáért cserébe az üzemeltetőknek a rendszer biztonságos működése érdekében az adatok elérése előtt azonosítaniuk kell magukat, illetve egy állandóan futó web böngészőre van szükségük a folyamatos felügyelethez. Felmerülhet az igény, hogy ezt a távfelügyeleti feladatot valamelyest egyszerűsített formában is elláthassák. A probléma megoldására bizonyos adatokat felhasználói azonosítás nélkül is elérhetővé kell tenni, illetve szükség van egy kliens oldalon futó alkalmazásra, mely a felhasználót igényei szerint tájékoztatja a pillanatnyi állapotról, és a riasztásokat haladéktalanul jelzi. Az adatok elérhetővé tételére a webes felhasználói felületet futtató webszerver kitűnően alkalmas, így az adatok egyszerűen HTTP protokoll felett utazhatnak. Az adatok átvitele során az értékek elkülönítésére XML formátumot alkalmazok, mivel ez igen rugalmas, és a későbbiekben szükség esetén könnyen bővíthető. <?xml version="1.0" encoding="iso "?> - <CurrentState> <Temperature>32</Temperature> <UpperWindows>zárva</UpperWindows> <UpperShading>100%</UpperShading> <Heating>kikapcsolva</Heating> <Alarm>Túlmelegedés!</Alarm> <Time>01:14:00</Time> </CurrentState> 3.7. ábra: A legfontosabb adatokat hordozó XML dokumentum Az adatok kliens oldali megjelenítéséről a Windows rendszeren futtatható greenmeter alkalmazás gondoskodik, mely a tálca értesítési ikonok számára fenntartott részén helyezkedik el. Az alkalmazás ikonja a belső légtér hőmérsékletváltozásának tendenciáját egy nyíllal jelzi, illetve dupla kattintás esetén információs panelt jelenít meg a hőmérséklet pontos értékével. A program a webszerverről az adatokat percenként kéri le, és ha riasztást észlel, minden lekérés után megjeleníti az alábbi ábrán látható panelt, melyen a riasztás oka is feltüntetésre kerül ábra: A greenmeter riaszt A greenmeter kizárólag Windows rendszeren működik, és funkcionalitása szűkös, ám már így is képes a riasztásokról a felhasználókat egy percen belül értesíteni. Az esetleges továbbfejlesztést, vagy hasonló alkalmazások készítését az alkalmazott XML formátum támogatja.

60 4. Befejezés Befejezés 4.1. A megvalósítás állapota A végleges rendszertervek Fizikai rendszerterv A fizikai rendszerterv végleges verzióját a 2.7. ábra mutatta be. Az itt ábrázolt felépítés minden tekintetben a megvalósítás alapját képezi. Az említett ábrán feltüntetésre került, ám részletesen nem lett specifikálva a felhasznált számítógép, mely a költségtakarékosság jegyében az alábbi jelen feladatainak ellátására, azaz a kísérleti üvegház kiszolgálására elégséges hardver felépítéssel rendelkezik: Alaplap: IBM 2169 i810 chipset Processzor: Intel Celeron 400 MHz Memória: 320 MB 133 MHz SD-RAM Videokártya: Intel (integrált) Háttértár: 2db Quantum Fireball 3079 MB ATA merevlemez WLAN illesztő: Surecom 9001g USB adapter A specifikáció ismeretében nem meglepő, hogy a számítógép költsége igen alacsony volt, ezért azonban az öregebb alkatrészek hordozta nagyobb meghibásodási kockázattal kell számolni. A tervezés során mindvégig szempont volt az alacsonyabb szintek függetlensége a számítógéptől, így ez a kockázat nem veszélyezteti az üvegház egészének biztonságos működtetését. A számítógép és a 3. szint tápellátása szintén független egymástól, mivel a mikrokontrollerek az asztali szellőztetés ventillátorait működtető tápegységre csatlakoznak. A számítógépbe épített két darab merevlemez kapacitása mai szemmel nézve igen kevésnek tűnik, azonban az alap rendszer mindössze 132 MB helyet foglal, amit a nagyobb komponensek mint az Apache és a MySQL még további 30 MB-al egészítenek ki. Ennek tükrében a 3 GB bőven elégséges még nagy mennyiségű mérési adat rögzítése után is. A két teljesen azonos típusú merevlemezt eredetileg egy olcsón beszerezhető IDE-RAID kártya segítségével RAID-0 tömbbé szerettem volna összeállítani, így növelve a rendszer rendelkezésre állását. Sajnos a felhasznált PCI csatlakozójú illesztő kártyáról az OpenBSD megállapította, hogy hasonlóan a legtöbb azonos árfekvésű vagy integrált RAID kártyához hardveresen csak egy IDE illesztőnek tekinthető. Az ilyen kártyák esetén az alkatrészhez mellékelt Windows-os meghajtó programokban kerül implementálásra a RAID kötetek kezelése. Tekintettel arra, hogy az OpenBSD rendelkezik hasonló, szoftveres RAID megoldással ami ráadásul nem igényel külön vezérlő kártyát az operációs rendszer fejlesztői nem készítettek hasonló funkcionalitású meghajtó programokat, ehelyett a saját szoftveres RAID megoldásuk használatát javasolják. Ennek egyetlen komoly hátránya az, hogy a rendszer nem képes ilyen szoftveres RAID tömbről bootolni, márpedig a redundancia növelése által az lenne a cél, hogy az egyik lemez kiesése esetén a másik önállóan is teljes értékű rendszert tartalmazzon. Tekintettel arra, hogy a szoftver RAID alap változata nem garantálja a szükséges biztonságot, úgy döntöttem, hogy a két merevlemez közül az egyiken az operációs rendszer és a programok kapnak helyet, míg a másikon az adatbázis adatfájljait helyezem el. A működés során napi ütemezéssel mindkét oldalról biztonsági másolatot készítek a másik lemezre. Ezzel ugyan az egyik lemez kiesése átmenetileg a rendszer működésképtelenségét eredményezi, azonban így lehetőség nyílik annak tartalmát a másikon tárolt biztonsági másolatból visszaállítani. (Az adatbázis adatfájljai nem az operációs rendszert tartalmazó lemezre

61 4. Befejezés 56 kerültek, mivel így lehetőség nyílik az olvasási műveletek párhuzamosítása révén az adatok gyorsabb elérésére.) A későbbiekben a rendszer véglegesítése során, illetve a magas szintű szabályozás beépítése előtt le kell majd cserélni ezt a számítógépet egy nagyobb teljesítményű, megbízhatóbb gépre. A jelenlegi feladatok ellátására azonban a bemutatott konfiguráció is alkalmas. Szoftveres rendszerterv A rendszer szoftver komponenseit és azok kapcsolatát az alábbi ábra szemlélteti ábra: Szoftver komponensek Az ábrán szaggatott vonallal bekeretezve feltüntetésre került a kizárólag diagnosztikai és hibakeresési feladatokat ellátó greendiagnostics program is, mely a normál működésben nem vesz részt, ám a szenzor modulok kalibrációja során, a konverziós táblázatok létrehozását nagymértékben segíti.

62 4. Befejezés Elkészült komponensek A rendszer jelenleg tesztelés alatt áll, mely az üvegházi telepítést megelőző utolsó lépés. Minden szoftver komponens elkészült, illetve a hardver egységek közül a mikrokontrollereket tartalmazó egységek is működőképesek. A teszteléshez egyelőre egyetlen darab szenzor modul áll rendelkezésre, melyen a tesztelés folyamán begyűjtött tapasztalatok alapján még lehetőség van hardveres módosításokat végezni ábra: A kísérleti szenzor modul Elkészült az egységeket összekötő kábelezés, továbbá minden kapcsolószekrényen kívüli egységhez rendelkezésre áll a megfelelő burkolat. Az alábbi képeken a mikrokontrolleres egységek láthatók. Az első a SMART (4.3. ábra), ahol az ATmega 162-es mikrokontroller mellett csak a MAX232 és a MAX485 kommunikációs illesztő IC-k kaptak helyet. A nyákra csatlakozó két vezeték párból a bal oldali a busz, míg jobb oldalon a tápellátás látható. A busz csatlakozásának módjából egyértelműen azonosítható, hogy a SMART a busz egyik végén helyezkedik el, amit a csatlakozó felett található 120 Ohm-os lezáró ellenállás is alátámaszt. A jobb oldalon középen elhelyezkedő csatlakozó a soros portra kapcsolódó három vezeték kivezetése. Mint minden egység, a SMART is rendelkezik egy reset kapcsolóval. A SMART esetében az állapotjelző LED-ek a többi egységhez képest jóval többen vannak: a zöld a SMART működését jelzi, míg a piros LED-eken megjelenő kód alapján a program pillanatnyi állapotára lehet következtetni (lásd az F.1.5. függeléket) ábra: A SMART egység 4.4. ábra: Egy SENSOR egység

63 4. Befejezés 58 A jobb oldali képen (4.4. ábra) a buszon 7-es címmel elérhető SENSOR egység látható. A SMART-hoz képest különbség, hogy a kontroller itt kisebb, ATmega8-as. A nyák bal alsó részén látható a busz csatlakozása, illetve a tápcsatlakozó, ahol a 12V-os vezeték is be van kötve, mivel a relék 12V-ot igényelnek. Jobb oldalt alul láthatóak a szenzor modulok bekötésére szolgáló csatlakozók. Közvetlenül a mikrokontoller felett található a programozáshoz használt négy tüske. Ezek mellett a táp és a föld is ki van vezetve, így a programozó egység közvetlenül a buszról táplálható a programozás ideje alatt. A felső részen láthatóak az ultrahangos párásító egységek és a ventillátorok vezérlő kimenetei. Az utolsó mikrokontrolleres egység a STRONG, melynek központi alkatrésze az ATmega16 kontroller. A STRONG nem rendelkezik burkolattal, mivel a helyszíni telepítés során a kapcsolószekrénybe kerül majd beépítésre. A nyákra bal oldalon középen csatlakozik a tápellátás, alul középen pedig a kommunikációs busz. Az utóbbi mellett megfigyelhető a busz végét jelző lezáró ellenállás. A nyák felső részén helyezkednek el a működtető kimenetek. Jobb oldalt alulra csatlakoztathatóak a ház különböző pontjaira kihelyezett szenzor modulok, míg bal oldalt alul kaptak helyet az egyszerű digitális bemenetek, mint például a csapadékérzékelő vagy az ablak 1/3 állásának jelzése ábra: A STRONG egység Az üzembe helyezés előfeltételei A magasabb szintek programjai az adatbázissal és a webszerverrel együtt a célszámítógépre telepítve készen állnak a helyszíni üzembe helyezésre. A mikrokontrolleres egységek programja tesztelésre került a különböző tesztelést támogató eszközök segítségével, és készen áll az éles környezetbe telepítésre. A rendszer beüzemelése előtt már csak az alábbi feladatokat kell végrehajtani: 1. A tesztelési célból készült egyetlen szenzor modult be kell mérni, az érzékelőihez kapcsolódó konverziós táblázatokat létre kell hozni, majd a működését tesztelni kell. 2. A tesztelés eredményei alapján a szenzor modul terveit szükség esetén módosítani kell, majd a folyamat az 1. ponttól indulhat újra. 3. Amennyiben a tesztelési eredmények megfelelőek, akkor a 23 db szenzor modul legyárthaó, majd mindegyikhez létre kell hozni a konverziós táblázatokat egy bemérési folyamat során. E lépéseket követően a már teljes rendszer készen áll az üvegházba telepítésre.

64 4. Befejezés A tervezési döntések értékelése Bevezetés Az alábbiakban a megvalósítás során felmerülő olyan problémákat és lehetséges alternatívákat mutatok be, melyek a tervezés során nem kerültek megfontolásra, vagy a tervezési döntések a megvalósítás tükrében nem tekinthetőek ideálisnak. Olyan problémákra is kitérek, melyek a tervezéstől függetlenül a megvalósítás során merültek fel először I 2 C szenzor modulok alkalmazhatósága Ahogy azt már 2. szint bemutatása során is hangsúlyoztam, a szenzor modulok tervezését nem én végeztem, ezért nem volt rálátásom a tervezési döntésekre. Ettől függetlenül azonban meg kell jegyezni, hogy analóg szenzorok helyett digitális szenzorok alkalmazása számos ponton egyszerűsítette volna a feladatot: nem lenne szükség az érzékelők mellett külön IC-re, mely a digitális jelet előállítja, illetve a kontroller oldalán a mintavételezést is ki lehetne hagyni. Ennek következtében a kalibrációs táblázatok tárolása, letöltése is szükségtelenné válna. Az analóg szenzorok kiváltásának egyik reális alternatívája I 2 C buszon kommunikáló digitális mérő alkatrészek használata lehetne. Az I 2 C busz specifikációja elsődlegesen nem az üvegházban található nagy távolságok áthidalására jött létre (hivatalosan csak 2-3 méteres távolságon működőképes), ám az adatátviteli sebesség csökkentése árán az eszközök között akár 100 m is lehet [23]. Számos hőmérsékletmérésre alkalmas I 2 C interfésszel rendelkező szenzor kapható, melyek ára néhány száz Forinttól indul. Nagyobb problémát jelenthet a páratartalom szenzorok beszerzése, melyek jelentősen drágábbak: az egyik legolcsóbb, a (beépített hőmérséklet szenzorral rendelkező) SHT11 típusú alkatrész 5800 Ft-ba kerül [24]. A digitális szenzorok alkalmazása jelentősen egyszerűsítette volna a szoftvereket, azonban a költségek jelentősen emelkedtek volna, hiszen a 19 db hőmérséklet és páraszenzor alkatrész önmagában 100 ezer Forint feletti költség lenne. Ezt a szempontot figyelembe véve, jelen helyzetben az analóg alkatrészek alkalmazása elfogadható megoldásnak bizonyul SMART és STRONG egyesítésének lehetősége A tervezési folyamat során mindvégig hangsúlyos szempont volt, hogy a létrejövő rendszer átlátható szerkezettel rendelkezzen. Ennek a törekvésnek a következtében nem merült fel, hogy a SMART és a STRONG egységeket össze lehet vonni egyetlen modulba. Ez a megoldási alternatíva reális: A SMART komoly számítási igénnyel rendelkezik, de nem használja a kimeneti portjainak nagy részét, míg a STRONG (a mérési értékek konvertálásán túl) szinte semmit nem számol, ám számos I/O portot használ. Az összevonás által eggyel kevesebb egység tervezésére lett volna szükség, ami mind hardver, mind pedig szoftver szempontból. A befektetett munkát csökkentette volna. Ezzel szemben a jelenlegi tiszta szerkezetet amikor a SMART csak parancsokat ad és mérési eredményeket kér be, míg a többi egység mér és beavatkozik a SMART utasításai alapján fel kellett volna áldozni. Ezen kívül jelentkezett volna néhány kisebb probléma is, mint például az, hogy a SMART szoftver órája a mérések során alkalmazott polling miatt gyorsan elállítódna, illetve a buszt lezáró egyik ellenállást egy SENSOR-ra kellett volna áthelyezni. Összességében az átlátható szerkezet feláldozása a megtakarítható munkát figyelembe véve, reális kompromisszumot eredményezett volna Az univerzális protokoll Ahogy azt már a fejezetben is említettem az első ránézésre természetesnek tűnő, a két kommunikációs csatornán két különböző protokollt használó megoldás nem feltétlenül

65 4. Befejezés 60 indokolt. Természetesen az említett fejezetben ismertetett érvek (a két protokoll elválasztásával az alsó szint tesztelése garancia a felső szintről érkező parancsok sikeres továbbítására) a különböző protokollok felhasználása mellett megállják a helyüket. A SMART programja azonban ennek köszönhetően számos olyan eljárást tartalmaz, mely a COM protokoll üzenetének bájtjait egyesével áthelyezi a 485 protokollnak megfelelő alakba, majd a választ hasonlóképpen transzformálja. A SMART ilyen jellegű függvényeit egy univerzális protokoll alkalmazásával ki lehetett volna váltani. Ezen túl a protokoll bővítése is jelentősen egyszerűsödne, hiszen jelenleg minden a SMART-on kívül más egységet is érintő üzenetet be kell építeni a két protokollba, és az üzenet továbbítását a SMART-on is le kell programozni. Mindezek tükrében az univerzális protokoll használatának előnyei jóval a hátrányok felett állnak, vagyis a két protokollt alkalmazó tervezői döntés hibásnak bizonyult. Tekintettel arra, hogy a két protokoll már implementálásra került, valamint figyelembe véve a tényt, hogy a protokollok bővítésére valószínűleg nem lesz szükség, megállapítható, hogy az univerzális protokoll utólagos bevezetése nem indokolt Hibás kezdőbitek A mikrokontrolleres egységek megépítése és összekapcsolása után olyan jelenséget tapasztaltam, amilyen a próbapaneles tesztelés során nem jelentkezett: a buszon az üzenetek hibamentes továbbításának valószínűsége közel nullára esett vissza (a SMART rendszeres kapcsolat tesztelő üzeneteire kevesebb mint 10%-ban érkezett érvényes válasz). Eleinte az új, jelentősen hosszabb kábelezésre terelődött a gyanú, ám annak hibamentessége miatt a problémát mégis a szoftverekben kellett keresni. A fejezetben ismertettem az ATmega családba épített USART egység hibajelző képességét (kerethiba, puffer túltöltés és paritáshiba). A későbbiekben eltekintettem e jelzőbitek felhasználásától, mivel az üzenetek utolsó bájtján továbbított ellenőrző összeget önmagában alkalmasnak tartottam a hibás üzenetek detektálására. Ezzel módszerrel a próbapanelen nem volt probléma, azonban a végleges összeállításban a busz irányváltása során gyakran keletkezett egy-egy téves kezdőbit, aminek hatására a vevő egy nullás bájtot olvasott. Természetesen a bájt végéről hiányzott a stop bit, és ennek tényét a kerethiba jelző bit rögzítette, ám a program ezt nem vette figyelembe, kizárólag az ellenőrző összegre koncentrált. Ennek köszönhetően, ha a SMART-nak sikerült egy parancsot az egyik egységhez eljuttatnia, akkor a busz irányváltása során (a SMART vételbe kapcsolt, majd a felszólított egység adásba állítja a buszillesztő IC-jét) keletkezett egy téves nulla bájt. A SMART ezt vette, és mivel ezen a pozíción a 485 protokollban a feladónak kell szerepelni, 0 feladó pedig nincs, az üzenetet a további hasznos bájtokat figyelmen kívül hagyva teljes egészében eldobta. A probléma fordított irányban nem jelentkezett, mivel a SMART által küldött üzenetek első bájtján a címet a 9. bit 1 értékének kellett volna jeleznie. Ez azonban a hibás kezdőbiteket követően 0-nak mintavételeződött. A probléma megtalálásának nehézsége ellenére kezelése egyszerű volt: a vételi folyamat során az ellenőrző összeg számítása mellett minden bájt vétele után ellenőrizni kell a kerethibát jelző bitet, melynek 1 értéke esetén az adott bájt nem kerülhet a vett üzenetbe A SENSOR modulok címbeállítása A SENSOR modulok programozása során nagy kellemetlenséget jelent, hogy az egységek buszon használt címe szoftveresen kerül meghatározásra. Ezért, ha minden SENSOR egységen frissíteni kell a programot és általában ez a helyzet akkor az új programból 5 verziót kell külön fordítani, melyek kizárólag a saját cím konstansban térnek el egymástól. A probléma egyszerűen kezelhető lenne, ha az egységek saját címüket bemeneti portjaikról olvasnák be, így a címet néhány jumper segítségével módosítani lehetne. A

66 4. Befejezés 61 megoldás a hardver minimális módosításával tenné lehetővé a kényelmesebb programozást. Sajnálatos módon ez az igény csak a nyákok legyártása után merült fel. A probléma a használhatóságot nem befolyásolja, csak a fejlesztés során okoz kényelmetlenséget Az ATmega8 memória problémái A fizikai rendszerterv létrehozása során minden egységhez meg kellett becsülni a mikrokontrollereken futtatott alkalmazások programmemória igényét. Ez a becslés a háromból két esetben jól sikerült: a STRONG kényelmesen elfér 16 KB memóriában, míg a SMART néhány száz bájt híján kitölti a rendelkezésére álló helyet. A SENSOR modulok esetében nem volt ilyen szerencsés a választás, ugyanis a végleges program nagyjából 50 bájttal hosszabb lett, mint a rendelkezésre álló memória. Az implementáció során ahogy azt a hibakeresésről szóló fejezetben részletesebben megindokoltam a programokból nem kerültek eltávolításra a hibakeresést támogató programrészek, így a SENSOR esetében is volt még lehetőség a program rövidítésére a normál funkcionalitás károsítása nélkül. Ennek során a programból elhagyásra került a hibakereső állapotvektort elküldő részlet, aminek köszönhetően a rendelkezésre álló FLASH memória már elégségesnek bizonyult. Az elkerülhetetlen megoldás mellékhatásaként a hibakereső állapotvektor hiányában a greendiagnostics nem képes a SENSOR egységek belső állapotát megjeleníteni. Amennyiben erre mégis szükség lenne, akkor a programból átmenetileg a normál működés során használt funkciókat kell kihagyni, majd a hibakereső részt belefordítva egy új verziót letölteni az érintett kontrollerre. Szerencsére a probléma jelentkezése óta még nem volt szükség ennek a kényszermegoldásnak az alkalmazására. A jövőbeli fejlesztések például a magas szintű szabályozás megépítése előre láthatólag nem igénylik majd a 3. szinten elhelyezkedő szoftver komponensek módosítását, így feltehetően a SENSOR egységek funkcionalitásának bővítésére sem lesz szükség. Ennek következtében a jelenlegi megoldás hosszú távon működőképes lehet, így a kontroller cseréje (mely a hozzá tervezett nyák újratervezését is igényelné) minden bizonnyal elkerülhető A szenzor modulok folyamatos lekérdezésének hátrányai A szenzor modulok állandó mintavételezésének elkerülésére a fejezetben felvetettem az analóg komparátor felhasználásának lehetőségét. A végleges tervbe az egyszerűbb hardver megvalósítás érdekében nem került bele a multiplexer, mely lehetővé tenné négy szenzor modul csatlakoztatását az analóg komparátorra. A kontrollerek számítási teljesítményének alacsony kihasználtsága lehetővé teszi a folyamatos lekérdezést. Ez az állítás megállja a helyét, azonban a későbbiek során ez a döntés számos olyan negatív hatással járt, mint például a SENSOR-okon az óra megvalósításának lehetetlensége. Ezen felül a mérések idején a letiltott megszakításoknak köszönhetően a buszon érkező üzenetek fogadása is elmaradhat, ezért az üzenetek újraküldéséről kellett gondoskodni, noha erre a busz megbízhatósága miatt nem lett volna szükség. Összességében elmondható, hogy a multiplexer és az analóg komparátor kihagyása a későbbiek során komoly nehézségeket, és felesleges korlátozásokat eredményezett. Ezek a korlátozások kihatottak a rendszer többi komponensének tervezésére, azonban a normál működésre minimális hatással vannak, így az egységek újratervezésére szükségtelen A hibakeresés hardveres támogatása A fejezetben ismertetett hibakeresési megoldások a fejlesztés későbbi szakaszaiban kielégítő segítséget nyújtottak a működési rendellenességek megtalálásában. A fejlesztés kezdeti szakaszán azonban nagy segítség lett volna egy JTAG debugger, melyet költségtakarékossági célokból nem szereztem be.

67 4. Befejezés A konfigurációk módosítása az adatbázisban A fejezet ismertette az adatbázisban a konfiguráció módosításának protokollját, miszerint a konfigurációs paraméterek változtatása mellett a megfelelő naplózó táblába egy külön művelettel be kell jegyezni a módosítás tényét. Ezt a két műveletet a jövőben célszerű lenne egy tárolt eljárás formájában egyesíteni, így a felhasználói programoknak csak ezt az eljárást kellene meghívniuk, mely mind a módosítást, mind pedig a naplózást elvégezné. A megoldás további előnye, hogy annak az adatbázishoz hozzáférő felhasználónak, aki a módosításokat végzi, csak a tárolt eljárások futtatására kell jogot adni. Ez szükségszerűen biztonságosabbá tenné a működést, hiszen így a naplózás véletlenül sem maradhat el Összefoglalás Az előzőekben ismertetett, megkérdőjelezhető tervezési döntésekről általánosan elmondható, hogy szinte kizárólag csak a tervezési folyamatra hatottak negatívan, a megvalósított rendszer működőképességét nem veszélyeztették. A problémák egy részét tipikusan a szoftveres eredetűeket meg lehetett, illetve a jövőben meg lehet oldani a programok módosításával. A hardverekkel kapcsolatos kérdéses pontok kezelésére a korábbi részletes indoklások alapján főleg anyagi megfontolásokat, illetve a módosítások munkaigényét figyelembe véve nincs reális lehetőség. Az elkészült rendszer értékelésével a következő fejezet foglalkozik Az elkészült rendszer értékelése A dolgozatban megtervezett rendszer jelen állapotában működőképes, a beüzemelés előtt már csak néhány kisebb lépést kell végrehajtani, melyek a szenzor modulok tesztelését és bemérését érintik. Ezt követően a rendszer telepíthető a kísérleti üvegházba. Az elkészült rendszer értékeléséhez a továbbiakban az fejezet végén deklarált négy alapvető cél teljesülését ellenőrzöm pontokba szedve. A rendszerrel szemben tehát az alábbi elvárások fogalmazódtak meg a tervezés megkezdése előtt: 1. Rendszeres időközönként rögzítse az üvegház összes szükséges paraméterét. A méréseket a szenzor modulok kimenetének mintavételezésével a 485-ös buszra csatlakozó slave egységek végzik, a többi egységtől függetlenül, percenként ütemezve. Ezek a mérési adatok az egyes egységek állapotvektorában kerülnek rögzítésre, melyet a SMART minden öt percben bekér, és a beérkező adatok alapján összeállítja a rendszer globális állapotvektorát. A globális állapotvektort a PC-n futó greenhand kiszolgáló alkalmazás az összeállítást követő egy percen belül elkéri a SMART-tól, majd az adatokat a MySQL adatbázis DataLog táblájában rögzíti. 2. A mérési adatokat tárolja úgy, hogy ahhoz a felhasználó, illetve a magas szintű szabályozás is kényelmesen, távolról hozzáférhessen. Az összetartozó mérési adatok tárolása a MySQL adatbázis DataLog táblájának egy rekordjában történik. Ehhez a táblához olvasási joggal rendelkezik a felhasználói felületeket működtető összes alkalmazás, így a mérési adatok a felhasználó számára megjeleníthetőek. A későbbiekben kifejlesztendő magas szintű szabályozás közvetlenül a DataLog táblára vonatkozó SQL lekérdezésekkel fér hozzá a mérési eredményekhez. Ez a megoldás a közvetlen hozzáférés miatt igen hatékony, és általa lehetőség nyílik az adatbázis biztonságos távoli elérésén keresztül a magas szintű szabályozást egy távoli számítógépen fejleszteni, tesztelni, illetve a későbbiek során akár üzemeltetni is.

68 4. Befejezés Biztosítson felületet a magas szintű szabályozás számára, melyen keresztül az parancsokat adhat a beavatkozó szerveknek. Az alkalmazott MySQL adatbázis a rendszer univerzális kapcsolódási pontjaként működik. Az egyes szoftver komponensek kizárólag az adatbázis megfelelő tábláin keresztül kommunikálnak egymással. Ez valamelyest lassítja a kommunikációt, azonban a sebességcsökkenésért cserébe minden komponensnek kizárólag az adatbázissal kell kapcsolatban állnia. Tekintettel arra, hogy az adatbázis távolról is hozzáférhető, lehetőség nyílik az egyes komponenseket egymástól távoli számítógépeken elhelyezni anélkül, hogy ez a működésben bármilyen problémát okozna. A magas szintű szabályozás parancsaival teljesen analóg módon történik a felhasználói utasítások kiszolgálása: a parancs az adatbázis megfelelő táblájában rögzítésre kerül, mely táblát a greenhand másodpercenként új parancsok után kutatva ellenőriz. A greenhand az adatbázisból kiolvasott parancsot a soros porton keresztül a SMART felé továbbítja, mely végrehajtja vagy a címzett felé továbbítja a kapott utasítást. Az utasítás végrehajtását a 485-ös buszon egy nyugta jelzi, melyet a SMART a greenhand-en keresztül az adatbázisba bejegyeztet, így a kezdeményező meggyőződhet a parancs végrehajtásáról. 4. A magas szint hiánya esetén nyújtson kielégítő alacsony szintű szabályozást. A magas szintű szabályozás kikapcsolt állapotában vagy meghibásodása esetén a SMART veszi át a vezérlési feladatokat. A felhasználói felület segítségével rögzített paraméterek alapján a SMART képes az összes beavatkozó szervet egy hagyományos set-point szabályozás szintjén működtetni. A vezérlés során a SMART semmiben nem támaszkodik a PC-re, így annak hiánya nem lényeges tényező. A magas szintű szabályozó program elindulása után egy üzenetet küld a SMART-nak, mellyel letiltja az alacsony szintű szabályozást, majd átveszi a ház vezérlését. A tervezés kezdetén megfogalmazott négy elvárásnak tehát hiánytalanul megfelel a kialakított rendszer. A tervezés során a feladat bonyolultságának kezelése érdekében mindig kiemelt szempontként volt jelen a tiszta szerkezet megalkotásának szándéka. Ennek következtében születtek olyan tervezői döntések, melyek a megvalósítási fázisban aránytalanul nagy terhet jelentettek (például SMART-STRONG különválasztás vagy két protokoll alkalmazása), azonban e döntések eredményeként egy átlátható, könnyen bővíthető rendszer jött létre. A későbbiek során az igényeknek megfelelően a rendszer minden szinten rugalmasan bővíthető, hiszen a 485-ös buszra újabb egységek csatlakozhatnak, illetve az alkalmazott adatbázis és felhasználói felület is képes akár egy számítógépen futtatva is több felhasználót és üvegházat kiszolgálni. A rendszer jelen állapotában néhány ponton még nem tekinthető késznek, hiszen még hiányoznak a végleges szenzor modulok, illetve az adatok grafikus megjelenítésért felelős greengrapher is csak részlegesen látja el feladatát. A hiányosságok pótlása után a fejlesztés két ágon folytatódhat. Egyrészt az egyes komponensek működésének hatékonyabbá és biztonságosabbá tételének érdekében a meglévő rendszeren módosítások végezhetőek (például az adatbázis módosítására tárolt eljárások létrehozásával és kizárólagos használatával). A fejlesztés másik ágán a begyűjtött mérési adatok alapján megkezdődhet a bevezető fejezetben nagy vonalakban vázolt intelligens szabályozás megvalósíthatóságának elemzése. Ezt követően a magas szintű szabályozás implementálása, tesztelése, végül üvegházi bevezetése zárhatja a folyamatot. Mindezen lépésekhez a megtervezett támogató rendszer készen áll.

69 F. Függelék 64 F. Függelék F.1. Lábkiosztások F.1.1. Bevezetés A következőkben az egyes mikrokontrolleres egységek végleges láb- és portkiosztását ismertetem. Az alkalmazott színek jelentése az alábbi: szenzor modulra kötött bemenet szenzor modul (tápellátás)vezérlő kimenet egyéb bemenet nem használt / tartalék láb foglalt láb vezérlő kimenet állapotjelző (piros) LED kimenet állapotjelző (zöld) LED kimenet F.1.2. SENSOR Láb Port Funkció Típus 1 Reset 2 USART RXD 3 USART TXD 4 MAX485 irány kimenet 5 PD3-6 PD4-7 Tápfeszültség 8 Föld 9 Oszcillátor 1 10 Oszcillátor 2 11 PD5 Szenzor bemenet 1 be 12 PD6 Szenzor bemenet 2 be 13 PD7 Szenzor bemenet 3 be 14 PB0 Szenzor bemenet 4 be 15 PB1 Szenzor aktiválás ki 16 PB2-17 Programozó csatlakozó (MOSI) 18 Programozó csatlakozó (MISO) 19 Programozó csatlakozó (SCK) 20 A/D tápellátás 21 A/D referencia feszültség 22 Föld 23 PC0 Ventilátor relé 3-4 ki 24 PC1 Párásítás relé 3-4 ki 25 PC2 Ventilátor relé 1-2 ki 26 PC3 Párásítás relé 1-2 ki 27 PC4 LED zöld ki 28 PC5 LED piros ki

70 F. Függelék 65 F.1.3. SMART A SMART nem lát el közvetlenül beavatkozó szerv vezérlő feladatot, így csak néhány állapotjelző LED kimenettel rendelkezik. Ezek a többi egységnél már megszokott két állapotjelzésen kívül a SMART által éppen végrehajtott műveletről (1 perces szabályozás, 5 perces szabályozás, kapcsolattesztelés a slave egységekkel) nyújtanak információt. (Az egyes LED-ek pontos jelentését az F.1.5. pont ismerteti.) Láb Port Funkció Típus 1 PB0-2 PB1-3 USART1 RXD 4 USART1 TXD 5 PB4-6 Programozó csatlakozó (MOSI) 7 Programozó csatlakozó (MISO) 8 Programozó csatlakozó (SCK) 9 Reset 10 USART 0 RXD 11 USERT 0 TXD 12 MAX485 irány kimenet 13 PD3-14 PD4-15 PD5-16 PD6-17 PD7-18 Oszcillátor 1 19 Oszcillátor 2 20 Föld 21 PC0-22 PC1-23 PC2-24 PC3 LED piros ki 25 PC4-26 PC5 LED piros ki 27 PC6-28 PC7 LED piros ki 29 PE2-30 PE1 LED piros ki 31 PE0-32 PA7 LED piros ki 33 PA6-34 PA5 LED piros ki 35 PA4-36 PA3 LED piros ki 37 PA2-38 PA1 LED zöld ki 39 PA0-40 Tápfeszültség

71 F. Függelék 66 F.1.4. STRONG Láb Port Funkció Típus 1 PB0 Ablak mikrokapcsoló be 2 PB1 Árnyékoló mikrokapcsoló be 3 PB2 Ajtó mikrokapcsoló be 4 PB3 Oldalablak mikrokapcsoló be 5 PB4 Esőérzékelő be 6 Programozó csatlakozó (MOSI) 7 Programozó csatlakozó (MISO) 8 Programozó csatlakozó (SCK) 9 Reset 10 Tápfeszültség 11 Föld 12 Oszcillátor 1 13 Oszcillátor 2 14 USART RXD 15 USART TXD 16 MAX485 irány kimenet 17 PD3 Szenzor bemenet 4 be 18 PD4 Szenzor bemenet 3 be 19 PD5 Szenzor bemenet 1 be 20 PD6 Szenzor bemenet 2 be 21 PD7 Tartalék relé (9) ki 22 PC0 Riasztó relé (8) ki 23 PC1 Tartalék relé (10) ki 24 PC2 Bővítő be/kimenet 25 PC3 Bővítő be/kimenet 26 PC4 Bővítő be/kimenet 27 PC5 Szenzor aktiválás ki 28 PC6 Felső párásítás relé (7) ki 29 PC7 Útpárásítás relé (6) ki 30 A/D tápfeszültség 31 Föld 32 A/D referencia feszültség 33 PA7 Tartalék bemenet be 34 PA6 LED piros ki 35 PA5 LED zöld ki 36 PA4 Fűtés relé (5) ki 37 PA3 Árnyékoló irány relé (4) ki 38 PA2 Ablak működtető relé (1) ki 39 PA1 Árnyékoló működtető relé (3) ki 40 PA0 Ablak irány relé (2) ki

72 F. Függelék 67 F.1.5. Állapotjelző LED-ek Általános tulajdonságok Minden mikrokontrolleres egységbe beépítésre került legalább két állapotjelző LED. Ezek segítségével az eszközök bizonyos szintű működése szemrevételezéssel ellenőrizhető. Minden egységen található egy zöld LED, melyet a kontrollerek a programjuk futtatásának kezdetén bekapcsolnak, majd egy rövid villantással jelzik, hogy a program futtatása elindult. A továbbiakban ez a LED (néhány kivételtől eltekintve) folyamatosan világít, ezzel jelezve, hogy a program futását hardveres probléma nem gátolja. Állapotjelző LED-ek a Strong és Sensor egységeken A zöld mellett a STRONG és a SENSOR egységeken található egy piros jelzőfény is. Ennek elsődleges feladata a kommunikációs tevékenységek jelzése. Amikor egy egység adási vagy vételi műveletet végez, akkor ez a LED világít, így könnyen megállapítható, hogy melyik egység kommunikál a buszon keresztül a SMART-tal. A LED-ek az előbbiekben ismertetett normál működés mellett még egy műveletet, a szenzor modulok lekérdezésének lépéseit jelzik. A lekérdezés három lépésből áll, melyeket az alábbi kombinációk jeleznek: 1. A szenzor modulok tápellátásának aktiválása mindkét LED elsötétül. 2. A szenzor modulok kimenetének mintavételezése a piros LED világít, a zöld sötét. 3. A mintavételezés vége, a modulok tápellátásának megszüntetése a zöld LED világít a piros sötét, így visszaáll a normál működés. Állapotjelző LED-ek a Smart-on A SMART a zöld LED-en kívül rendelkezik még további 7 db piros LED-del, melyek segítségével működése mélyebben nyomon követhető. A további LED-ek felhasználását a SMART-on futó bonyolultabb program indokolja, és a LED-ek alacsony ára illetve a SMART sok szabad I/O portja miatt a megvalósításnak nem volt reális akadálya. A SMART-on a LED-ek egymás mellett helyezkednek el (lásd 4.3. ábra). Tekintettel arra, hogy a 7 db LED segítségével a jelzésre érdemes állapotok számánál jóval több kombináció megjelenítésére nyílik lehetőség, az egyes LED-ekhez önálló jelentést lehetett rendelni, melyet csak egy speciális esetben volt szükséges felülbírálni. Az alábbi táblázat az egyes LED-ek elsődleges jelentését mutatja be. 1. A soros vonalon érkező üzenet vételét és feldolgozását jelző LED. 2. A soros vonali adás jelzője. 3. A 485 buszon vett üzenetet jelző LED. 4. A 485 buszon küldött üzenet jelzője. 5. Az egységek állapotvektorának 5 percenként ütemezett lekérését jelző LED. 6. Az 1 percenként ütemezett szabályozás futásának jelzője. 7. Az 5 percenként ütemezett szabályozás futását jelző LED. A 6. és 7. LED normál működés során nem világíthat egyszerre, mivel a szabályozó algoritmus lineáris felépítésű, tehát ha mindkét szabályozáshoz lejárt már a várakozási számláló, akkor először az 5 percenként ütemezett feladatok futnak le, majd őket követik az 1 perces ütemezéssel rendelkezők. Ennek a ténynek köszönhetően lehetőség van a két LED-et egyszerre bekapcsolva egy további működési fázis egyértelmű jelzésére. Ez az új, önálló működési jelzéssel bíró fázis az egyes slave egységek élőségi információit tartalmazó táblázat frissítése, amikor a SMART minden egységnek egy-egy kapcsolat tesztelő üzenetet küld.

73 F. Függelék 68 F.2. A COM protokoll üzenetei F.2.1. Bevezetés Az alábbiakban felsorolom a COM protokoll érvényes üzeneteit. A master-slave megvalósításnak köszönhetően minden esetben a PC kezdeményezi a kommunikációt, melyre a SMART válaszol. Az üzenetek egy része debug jelzéssel van ellátva: ezek a normál működéshez nem szükségesek, kizárólag diagnosztikai, hibakeresést segítő feladatokat látnak el. Az üzenetek felépítésének ábrázolásakor a felhasznált színek jelentése: az üzenetek felépítésében rögzített adat parancs bájt paraméterek, adatok Minden üzenet végén megtalálható az ellenőrző bájt, melyet CB jelez. F.2.2. Az üzenetek Kapcsolattesztelés (debug) A PC felszólítja a SMART-ot, hogy egy kapcsolat tesztelő kérést küldjön ki a buszra a paraméterként kapott egység felé. Amennyiben a címzett a SMART, akkor ő azonnal nyugtával válaszol. Ha egy másik egység a címzett, akkor csak a megcímzett egység megfelelő válasza esetén küld nyugtát a SMART. Ha nincs válasz, azt a nyugta hiánya jelzi, melyet a PC a vétel során timeout formájában érzékel. Normál működés mellett a megcímzett egység a válaszában a konfigurációjának azonosítószámát is mellékeli, ezért ilyenkor az is frissül a SMART nyilvántartásában. A kérés: 4 1 Cél címe CB A válasz (ha van): 2 CB=2 A slave egységek utolsó elérhetőségének lekérése (debug) A PC felszólítja a SMART-ot, hogy továbbítsa a nála karbantartott élőségi információkat (az utolsó sikeres kapcsolatfelvétel óta eltelt másodpercek számát) tartalmazó táblázatot. A válaszban jelzett Idő (X) bájt a buszon X címmel elérhető egység utolsó válasza óta eltelt időt jelzi. A kérés: 3 2 CB=5 A válasz: 8 Idő (2) Idő (3) Idő (4) Idő (5) Idő (6) Idő (7) Idő (8) CB

74 F. Függelék 69 EEPROM tartalom küldése A PC felszólítja a SMART-ot, hogy továbbítsa a paraméterként kapott EEPROM tartalmat a megcímzett egységnek. Ezzel az üzenettel lehet az egységeknek konfigurációt vagy konverziós táblázatokat küldeni. A kérésben rögzíteni kell a célegységet, illetve az eltárolandó adat kezdőcímét az EEPROM-ban. Utóbbi érték (tekintettel arra, hogy az 512 bájt memória egy bájton nem címezhető, két bájt pedig felesleges lenne erre a célra) a felhasználás előtt kettővel szorzódik, így a teljes memóriatartomány címezhető kétbájtos lépésekben. Az adatok sikeres tárolásáról nyugta, vagy hiba esetén annak hiánya tájékozatja a PC-t. A kérés: Hossz 3 Cél címe Ofszet Adat 1 Adat 2 Adat N CB A válasz (ha van): 2 CB=2 EEPROM tartalom visszaolvasása (debug) A PC felszólítja a SMART-ot, hogy kérje be a paraméterként kapott egység EEPROMjának az ofszettől kezdődő, megadott hosszúságú blokkját. (A ofszet értéke felhasználás előtt kétszereződik annak érdekében, hogy az 512 bájt EEPROM-ot egy bájton címezni lehessen.) A kérés: Adat 6 4 Cél címe Ofszet CB hossz A válasz: Hossz Adat 1 Adat 2 Adat 3 Adat 4 Adat 5 Adat N CB A SMART órájának lekérdezése (debug) A PC felszólítja a SMART-ot, hogy közölje az órájának aktuális állását. A SMART a saját belső időábrázolása szerint küldi el a választ: két bájton a nap aktuális perce szerepel, míg egy bájton a másodperc érték kap helyet. A kérés: 3 5 CB=8 A válasz: 5 MinH MinL Sec CB A SMART órájának beállítása A PC közli a SMART-tal a pontos időt, a SMART által használt számábrázolás szerint. A kérés: 6 6 MinH MinL Sec CB A válasz: 2 CB=2

75 F. Függelék 70 A magas szintű szabályozás állapotának beállítása A PC közli a SMART-tal, hogy a magas szintű szabályozás aktív (Állapot = 1). Ennek hatására a SMART az alacsony szintű szabályozás futtatását leállítja, illetve elindít egy időzítőt. Ha az időzítő lejár, az alacsony szint újra aktiválva lesz. Amennyiben az időzítő lejárta előtt a PC ismét ilyen üzenetet küld, akkor a számláló újraindul, így garantálva azt, hogy a magas szint kiesése után az alacsony szint rövid időn belül átveszi annak feladatait. Abban az esetben, ha a PC az üzenetben az állapot bájtot nullára állítja, akkor a SMART értesül a magas szint leállásáról és azonnal aktiválja az alacsony szintet. A kérés: 4 7 Állapot CB A válasz: 2 CB = 2 Konfigurációs azonosítószámok lekérése A PC felszólítja a SMART-ot, hogy továbbítsa az általa nyilvántartott táblázatot, melyben az egységek aktuális konfigurációs azonosítói szerepelnek. Ezt a SMART a rendszeres kapcsolattesztelések során frissíti (illetve a sajátjával nyilvánvalóan tisztában van). A PC ennek ismeretében el tudja dönteni, hogy mely egységek szorulnak konfigurációfrissítésre. A válaszban az azonosítók között az első helyen a SMART, a másodikként a STRONG, majd ezt követően a SENSOR-ok adata következik a címük alapján növekvő sorrendben. A kérés: 3 8 CB=11 A válasz: Hossz Azon. (1) Azon. (2) Azon. (3) Azon. (4) Azon. (5) Azon. (6) Azon. (7) CB Azonnali mérés kezdeményezése (kalibrációhoz) A PC felszólítja a SMART-ot, hogy egy azonnali mérést kezdeményező üzenetet küldjön ki a célcímre. Erre a szenzor modulok kalibrálása során van szükség, hogy a mérések azonnal megtörténjenek, és a mért (konvertálatlan) értékeket gyorsan le lehessen kérni. (A nyers értékek az ütemezett mérések során is eltárolásra kerülnek, itt a lényeg a mérések manuális ütemezése által a kalibráció gyorsítása.) A nyugta a mérés megkezdését jelzi. A kérés: 4 20 Cél címe CB A válasz: 2 CB = 2

76 F. Függelék 71 Azonnali adatlekérés és beavatkozás kezdeményezése a SMART-on (debug) Az üzenet hatására a SMART úgy viselkedik, mintha lejárt volna az 5 perces számlálója: lekéri az összes slave egység pillanatnyi állapotát, majd meghozza az öt percenként ütemezetett beavatkozási döntéseket. (Amennyiben a magas szintű szabályozás aktív, akkor csak adatlekérés történik, beavatkozás természetesen nem.) A kérés: 3 21 CB=24 A válasz: 2 CB = 2 A konvertálatlan mérési eredmények lekérése (kalibrációhoz) A PC felszólítja a SMART-on keresztül a megcímzett slave egységet, hogy továbbítsa a legutóbbi mérés során rögzített, nem konvertált mérési eredményeit. Ez minden szenzorhoz egy periódushossz és egy kitöltési tényező értéket jelent, melyek értéktartományuk miatt kétkét bájton kerülnek továbbításra. A kérés: 4 22 Cél címe CB A válasz: 18 Adat 1.1 H Adat 1.1 L Adat 1.2 H Adat 1.2 L Adat 2.1 H Adat 4.2 L CB A felső ablakok kívánt állapotba állítása A PC felszólítja a SMART-ot, hogy a STRONG segítségével a felső ablakokat a paraméterként kapott állapotba állítsa. A nyugta a művelet időigénye miatt csak a mozgatás megkezdését jelzi. A kérés: 4 41 Új állapot CB A válasz: 2 CB = 2 A felső árnyékolás kívánt állapotba állítása A PC felszólítja a SMART-ot, hogy a STRONG segítségével a felső árnyékolást a paraméterként kapott állapotba állítsa. A nyugta a művelet időigénye miatt csak a mozgatás megkezdését jelzi. A kérés: 4 42 Új állapot CB A válasz: 2 CB = 2

77 F. Függelék 72 A fűtés vezérlése A PC felszólítja a SMART-ot, hogy a STRONG segítségével a fűtést be- vagy kikapcsolja. A kérés: 4 43 Új állapot CB A válasz: 2 CB = 2 Az útpárásítás vezérlése A PC felszólítja a SMART-ot, hogy a STRONG segítségével az útpárásítást a megadott időre kapcsolja be. Az idő annak érdekében, hogy egy bájton elférjen 12 másodperces egységekben számolódik. (Az egy bájtos limit itt és a későbbiekben is a konfiguráció tárolása miatt, és nem az üzenetek hosszán megtakarított egy bájt miatt fontos: a konfiguráció értékeinek beolvasására így egyetlen általános eljárás használható. Amíg az egy bájtos ábrázolás a használhatóságot nem befolyásolja, addig igyekszem erre törekedni.) A nyugta a párásítás megkezdését jelzi. A kérés: 4 44 Idő CB A válasz: 2 CB = 2 A felső párásítás vezérlése A PC felszólítja a SMART-ot, hogy a STRONG segítségével az útpárásítást a megadott időre kapcsolja be. Az idő 12 másodperces egységekben számolódik. A nyugta a párásítás megkezdését jelzi. A kérés: 4 45 Idő CB A válasz: 2 CB = 2 Az asztalszellőztetés vezérlése A PC felszólítja a SMART-ot, hogy a megcímzett egységhez tartozó, megadott oldali asztalszellőztetést a paraméterként kapott időre indítsa el. Az idő öt másodperces egységekben értendő. Az oldal paraméter 0 értéke esetén mindkét, 1 esetén a bal, 2 esetén a jobb oldali vezérelt asztalpáron kapcsol be a szellőzés. A nyugta a szellőztetés kezdetét jelzi. A kérés: 6 46 Idő Cél címe Oldal CB A válasz: 2 CB=2

78 F. Függelék 73 Riasztás állapotának megadása A PC a riasztási szintet megadva önállóan aktiválhatja vagy deaktiválhatja a riasztást. A STRONG riasztásra szolgáló kimenetét mindaddig magas szinten tartja, ameddig az ilyen üzenetekben kapott Új állapot nem nulla. Jelen pillanatban a STRONG nem foglalkozik azzal, hogy a riasztás állapotának értéke pontosan mennyi, ezt azonban a későbbiek során egy fejlettebb riasztó rendszerrel ellátott környezetben fel lehet használni, akár a felhasználó felé továbbítva is. A kérés: 4 47 Új állapot CB A válasz: 2 CB = 2 Szenzor állapotváltozóinak lekérdezése (debug) A PC a SMART-on keresztül lekéri a megcímzett szenzor egység összes fontos állapotváltozóját (időzítők állása, beavatkozó szervek állapota, mért értékek, működési idők), hogy az egység működését vizsgálni lehessen. Az üzenetek felépítését az egyes egységek esetén az F.6. függelék ismerteti. A kérés: 4 50 Idő CB A válasz: Hossz Állapot 1 Állapot 2 Állapot 3 Állapot 4 Állapot 5 Állapot N CB A globális állapotvektor lekérése a SMART-tól A PC ezzel az üzenettel utasítja a SMART-ot a globális állapotvektor elküldésére, ha a mellékelt állapotvektor azonosító nem a legfrissebb. Amennyiben a két azonosító szám megegyezik, akkor a SMART egy nyugtával jelzi, hogy a kérés megérkezett hozzá, de nincs újabb adat, amit küldhetne. Az állapotvektor felépítését az F.5. függelék részletezi. A kérés: Azon CB szám A válasz, ha az elküldött azonosító szám nem a legfrissebb: Állapot Állapot Állapot Állapot Állapot Hossz A válasz, ha a PC a legfrissebb azonosítót küldte a kérésben: 2 CB = 2 Állapot N CB

79 F. Függelék 74 F.3. A 485 protokoll üzenetei F.3.1. Bevezetés Az alábbiakban felsorolom a 485 protokoll érvényes üzeneteit. A master-slave megvalósításnak köszönhetően minden esetben a SMART kezdeményezi a kommunikációt, melyre a megcímzett egység válaszol. Az üzenetek egy része debug jelzéssel van ellátva: ezek a normál működéshez nem szükségesek, kizárólag a hibakeresést segítik. Az üzenetek felépítésének ábrázolásakor az egyes felhasznált színek jelentése: a slave egység címe az üzenetek felépítésében rögzített adat parancs bájt paraméterek, adatok Minden üzenet végén CB felirat jelzi az ellenőrző bájtot. F.3.2. Az üzenetek Kapcsolattesztelés és konfigurációs azonosító lekérése A SMART egy teszt bájtot küld a megcímzett egységnek, akinek ezt a bájtot és a konfigurációs azonosítószámát kell a válaszban visszaküldenie. A kérés: Cím 5 1 Teszt bájt CB A válasz: Feladó 5 Teszt bájt Konf. azon. CB Kapcsolattesztelés (debug) Az üzenet hatására a piros állapotjelző LED-et egy másodpercre be kell kapcsolni. A kérés: Cím 4 2 CB A válasz: Feladó 3 CB Kapcsolattesztelés (debug) Az üzenet hatására a zöld állapotjelző LED-et egy másodpercre be kell kapcsolni. A kérés: Cím 4 3 CB A válasz: Feladó 3 CB

80 F. Függelék 75 Azonnali mérés kezdeményezése (kalibrációhoz) Az üzenetet vevő egység azonnal elkezdi lekérdezni a hozzátartozó szenzor modulokat. A kérés: Cím 4 20 CB A válasz: Feladó 3 CB Mérési eredmények és aktuális állapot lekérdezése A SMART ezzel az üzenettel kérdezi le az összes egységtől a legfrissebb mérési eredményeket, a beavatkozó szervek állapotát vagy használati idejét az utolsó lekérdezés óta. A kérés: Cím 4 21 CB A válasz: Feladó Hossz Adat 1 Adat 2 Adat 3 Adat 4 Adat N CB Nyers mérési eredmények lekérdezése (kalibrációhoz) A SMART ezzel az üzenettel kéri le a megcímzett egység nyers (konvertálatlan) mérési eredményeit, hogy azt a PC-n keresztül a felhasználónak továbbíthassa a bemérési folyamat során. Az így elküldésre kerülő adatok nagyságrendjük miatt két-két bájton tárolódnak. A kérés hatására mind a 8 nyers adat elküldésre kerül. A kérés: Cím 4 22 CB A válasz: Feladó 19 Adat 1.1 H Adat 1.1. L Adat 1.2 H Adat 1.2 L Adat 4.2 L CB Paraméterek beírása az EEPROM-ba A SMART-tól érkező üzenet tartalmát a megcímzett egység a megadott ofszettől kezdve beírja a nem felejtő memóriájába. Ezzel az üzenettel lehet konfigurációt vagy konverziós táblázatot rögzíteni a slave egységeken. Az ofszet a felhasználás előtt kettővel szorzódik, így egy bájton két bájtos lépésekkel lehet megcímezni a teljes 512 bájt méretű memóriát. A kérés: Param. Cím Hossz 30 Param. 1 Param. 2 Param. 3 CB N A válasz: Feladó 3 CB

81 F. Függelék 76 Paraméterek kiolvasása az EEPROM-ból (debug) A megcímzett egységnek erre az üzenetre az EEPROM-jából az ofszettől kezdve kiolvasott megfelelő hosszú adatsorral kell válaszolnia. Az ofszet a felhasználás előtt kettővel szorzódik, így egy bájton két bájtos lépésekkel lehet megcímezni a teljes 512 bájt memóriát. A kérés: Adat Cím 6 31 Ofszet CB hossz A válasz: Feladó Hossz Adat 1 Adat 2 Adat 3 Adat 4 Adat N CB A felső ablakok vezérlése Az üzenetet csak a STRONG kaphatja, hatására az ablakokat új állásba mozgatja. A kérés: Cím 5 41 Új állapot CB A válasz: Feladó 3 CB A felső árnyékolás vezérlése Az üzenetet csak a STRONG kaphatja, aki az árnyékolást a megfelelő állásba mozgatja. A kérés: Cím 5 42 Új állapot CB A válasz: Feladó 3 CB A fűtés vezérlése Az üzenetet csak a STRONG kaphatja, aki a fűtést a megfelelő állásba kapcsolja. A kérés: Cím 5 43 Új állapot CB A válasz: Feladó 3 CB

82 F. Függelék 77 Az útpárásítás vezérlése Az üzenetet csak a STRONG kaphatja, aki az útpárásítást a paraméterként kapott időtartamra bekapcsolja. (Az idő 10 másodperces egységekben állítható.) A kérés: Cím 5 44 Idő CB A válasz: Feladó 3 CB A felső párásítás vezérlése Az üzenetet csak a STRONG kaphatja, aki a felső párásítást a paraméterként kapott időtartamra bekapcsolja. (Az idő 10 másodperces egységekben állítható.) A kérés: Cím 5 45 Idő CB A válasz: Feladó 3 CB Az asztalszellőztetés bekapcsolása Az üzenetet csak egy SENSOR kaphatja, aki ennek hatására a megfelelő oldali (vagy 0 oldal értek esetén mindkét) ultrahangos párásító egységét a paraméterként kapott időtartamra bekapcsolja. Az idő 10 másodperces egységekben állítható. A kérés: Cím 6 46 Idő Oldal CB A válasz: Feladó 3 CB A riasztás állapotának beállítása Az üzenetet csak a STRONG kaphatja, aki a paraméter nem nulla értéke esetén aktiválja a riasztás kimenetét. A kérés: Cím 5 47 Új állapot CB A válasz: Feladó 3 CB

83 F. Függelék 78 Hibakeresési információk lekérése (debug) A megcímzett egység a típusától függő állapotinformációkat küld a válaszüzenetben (számlálók pillanatnyi állása, beavatkozó szervek állapota és működési ideje), ami a hibakeresést segíti. Az adatok értelmezését az F.6. függelék részletezi. A kérés: Cím 4 50 CB A válasz: Feladó Hossz Adat 1 Adat 2 Adat 3 Adat 4 Adat N CB

84 F. Függelék 79 F.4. Tárolt konfigurációk F.4.1. Bevezetés Minden mikrokontrolleres egység a nem felejtő EEPROM-jában tárolja a konfigurációs paramétereket, melyek az egység működéséhez szükséges beállításoknak felelnek meg. Konfiguráció alatt az alábbi információkat értem a továbbiakban: 1. A szabályozás paraméterei, melyeket a felhasználó adott meg. 2. A konverziós táblázatok kezdőcímei, melyek a tervezés során kerültek meghatározásra, de a rugalmasság érdekében (későbbi, több vagy kevesebb bejegyzést igénylő modulok kezelésére) a PC-n tárolt változatuk módosítható. Nem tartozik a konfigurációhoz a konverziós táblázatok tartalma, mivel annak frissítése előreláthatóan csak akkor szükséges, ha az EEPROM törlődik. Szintén nem tartoznak a konfigurációhoz a hibakereső változók, mivel ezeket kizárólag az EEPROM tartalmának (megfelelő segédprogram általi) kézi szerkesztésével lehet módosítani. Minden egységnél rögzített a konfiguráció első bájtja. Ez a FLAG, melynek 1 értéke jelzi, hogy van letöltött konfiguráció. Ha az EEPROM bármilyen okból törlődött vagy sosem volt írva, akkor ezen a pozíción 255 áll. A FLAG ellenőrzésével minden konfigurációs paraméter használata előtt meg kell győződni arról, hogy van eltárolt konfiguráció. (Természetesen a FLAG-et célszerű a memóriába gyorsítótárazni, hiszen normál működés közben a konfiguráció csak módosulhat, el nem veszhet.) A FLAG tartalmának beállítása nem a vevő egység feladata, azt a konfiguráció küldőjének (a PC-nek) ugyanúgy tárolandó adatként kell megadnia, mint az összes többi értéket. Egy másik, minden egység számára fontos, ám nem rögzített helyű adat a SERIAL, mely a konfiguráció azonosító száma, és ennek ismeretében határozza meg a greenhand a frissítést igénylő egységek listáját. A konfigurációk után minden esetben feltüntetésre kerültek a tesztelést segítő változók is. Ezek fizikailag a hatékony helykihasználás érdekében közvetlenül a konfiguráció után tárolódnak, ám letöltésük attól teljesen függetlenül történik: sem az adatbázis, sem pedig a konfigurációkért felelős kiszolgáló program nem foglalkozik a tesztelő adatokkal, azokat kizárólag kézzel (a greendiagnostics segédprogram segítségével lásd F.7. függelék) lehet szerkeszteni. Az alacsony szintű szabályozás paramétereinek értelmét az fejezet ismertette. F.4.2. SMART Belső név Forrás Leírás 0 FLAG (greenhand) A konfiguráció jelenlétét jelző bájt 1 Enabled cfgairing A szellőztetés vezérlésének engedélyezettsége 2 AiringDuration Egy szellőztetés hossza (perc egységben) 3 AiringTime1 Az 1. rögzített szellőztetési időpont (15 perc egységben) 4 AiringTime2 A 2. rögzített szellőztetési időpont (15 perc egységben) 5 AiringTime3 A 3. rögzített szellőztetési időpont (15 perc egységben) 6 Level1Temp Az 1. intenzív program küszöbhőmérséklete 7 Level1Interval Az 1. program várakozási ideje két működés között (perc) 8 Level2Temp A 2. intenzív program küszöbhőmérséklete 9 Level2Interval A 2. program várakozási ideje két működés között (perc) 10 Enabled cfgalarms A riasztás engedélyezettsége 11 ColdAlarm A fagyveszély riasztás küszöbszintje 12 HotAlarm A túlmelegedés riasztás küszöbszintje 13 AlarmOnAiOff A magas szint kiesése riasztás engedélyezettsége 14 Enabled cfgheating A fűtés vezérlésének engedélyezettsége

85 F. Függelék Temp A fűtés bekapcsolásának küszöbhőmérséklete 16 Enabled cfgmisting A felső párásítás engedélyezettsége 17 Level1Temp Az 1. intenzív program küszöbhőmérséklete 18 Level1Interval Az 1. program várakozási ideje két működés között (perc) 19 Level1Duration Az 1. intenzív program párásítási hossza (másodperc) 20 Level2Temp A 2. intenzív program küszöbhőmérséklete 21 Level2Interval A 2. program várakozási ideje két működés között (perc) 22 Level2Duration A 2. intenzív program párásítási hossza (másodperc) 23 Level3Temp A 3. intenzív program küszöbhőmérséklete 24 Level3Interval A 3. program várakozási ideje két működés között (perc) 25 Level3Duration A 3. intenzív program párásítási hossza (másodperc) 26 Enabled cfgroadmisting Az útpárásítás engedélyezettsége 27 Level1Temp Az 1. program küszöbhőmérséklete 28 Level1Interval Az 1. program várakozási ideje két működés között (perc) 29 Level1Duration Az 1. program párásítási hossza (másodperc) 30 Level2Temp A 2. program küszöbhőmérséklete 31 Level2Interval A 2. program várakozási ideje két működés között (perc) 32 Level2Duration A 2. program párásítási hossza (másodperc) 33 Level3Temp A 3. program küszöbhőmérséklete 34 Level3Interval A 3. program várakozási ideje két működés között (perc) 35 Level3Duration A 3. program párásítási hossza (másodperc) 36 Enabled cfguppershading A felső árnyékolás vezérlésének engedélyezettsége 37 NightShadeOn Az éjszakai fix árnyékolás engedélyezettsége 38 Night100Time Az éjszakai fix árnyékolás kezdete 39 Night0Time Az éjszakai fix árnyékolás vége 40 0to100Temp A 0->100% árnyékolás küszöbhőmérséklete to0Temp A 100->0% árnyékolás küszöbhőmérséklete 42 0to90Temp A 0->90% árnyékolás küszöbhőmérséklete 43 90to0Temp A 90->0% árnyékolás küszöbhőmérséklete 44 NightShadingOff Az éjszakai fix nem árnyékolás engedélyezettsége 45 NightOffStartTime Az éjszakai fix nem árnyékolás kezdete 46 NightOffEndTime Az éjszakai fix nem árnyékolás vége 47 Enabled cfgupperwindows A felső ablakok vezérlésének engedélyezettsége 48 0to33Temp A 0->33% nyitás küszöbhőmérséklete 49 33to100Temp A 33->100% nyitás küszöbhőmérséklete to33Temp A 100->33% nyitás küszöbhőmérséklete 51 33to0Temp A 33->0% nyitás küszöbhőmérséklete 52 SERIAL (greenhand) A konfiguráció azonosító száma 53 DEBUG - A DEBUG mód engedélyező jele 54 debug_reftemp - A DEBUG módban használt referenciahőmérséklet F.4.3. SENSOR Belső név Forrás Leírás 0 FLAG (greenhand) A konfiguráció jelenlétét jelző bájt 1 Active cfgdesks Az 1. asztal engedélyezettsége 2 MinH Az 1. asztal cél páratartalma (ultrahangos párásításnál) 3 Active A 2. asztal engedélyezettsége 4 MinH A 2. asztal cél páratartalma (ultrahangos párásításnál) 5 Active A 3. asztal engedélyezettsége

86 F. Függelék 81 6 MinH A 3. asztal cél páratartalma (ultrahangos párásításnál) 7 Active A 4. asztal engedélyezettsége 8 MinH A 4. asztal cél páratartalma (ultrahangos párásításnál) 9 Enabled cfgultrasonic Az ultrahangos párásítás engedélyezettsége 10 Duration Egy párásítás hossza (perc) 11 MinInterval Két párásítás közötti minimális várakozási idő (perc) 12 Table1A cfgsensors Konverziós tábla kezdőcím 13 Table1B Konverziós tábla kezdőcím 14 Table2A Konverziós tábla kezdőcím 15 Table2B Konverziós tábla kezdőcím 16 Table3A Konverziós tábla kezdőcím 17 Table3B Konverziós tábla kezdőcím 18 Table4A Konverziós tábla kezdőcím 19 Table4B Konverziós tábla kezdőcím 20 SERIAL (greenhand) A konfiguráció azonosító száma 21 DEBUG - A DEBUG mód engedélyező jele 22 debug_state4 - A DEBUG módban visszaadott állapotváltozók 23 debug_state5 - A DEBUG módban visszaadott állapotváltozók 24 debug_state6 - A DEBUG módban visszaadott állapotváltozók 25 debug_state7 - A DEBUG módban visszaadott állapotváltozók 26 debug_state8 - A DEBUG módban visszaadott állapotváltozók 27 debug_state9 - A DEBUG módban visszaadott állapotváltozók 28 debug_state10 - A DEBUG módban visszaadott állapotváltozók 29 debug_state11 - A DEBUG módban visszaadott állapotváltozók F.4.4. STRONG Azonosító Forrás Leírás 0 FLAG (greenhand) A konfiguráció jelenlétét jelző bájt 1 SERIAL (greenhand) A konfiguráció azonosító száma 2 Table1A cfgsensors Konverziós tábla kezdőcím 3 Table1B Konverziós tábla kezdőcím 4 Table2A Konverziós tábla kezdőcím 5 Table2B Konverziós tábla kezdőcím 6 Table3A Konverziós tábla kezdőcím 7 Table3B Konverziós tábla kezdőcím 8 Table4A Konverziós tábla kezdőcím 9 Table4B Konverziós tábla kezdőcím 10 DEBUG - A DEBUG mód engedélyező jele 11 debug_state9 - A DEBUG módban visszaadott állapotváltozó 12 debug_state10 - A DEBUG módban visszaadott állapotváltozó 13 debug_state11 - A DEBUG módban visszaadott állapotváltozó 14 debug_state12 - A DEBUG módban visszaadott állapotváltozó 15 debug_state13 - A DEBUG módban visszaadott állapotváltozó 16 debug_state14 - A DEBUG módban visszaadott állapotváltozó 17 debug_state15 - A DEBUG módban visszaadott állapotváltozó 18 debug_state16 - A DEBUG módban visszaadott állapotváltozó 19 debug_rain - A DEBUG módban visszaadott csapadékjelző érték 20 debug_door - A DEBUG módban visszaadott ajtó nyitottság érték 21 debug_sidewind - A DEBUG módban visszaadott oldalablak állapot értéke

87 SENSOR (3) F. Függelék 82 F.5. Állapotvektorok F.5.1. Bevezetés A buszon elhelyezkedő összes egység rendelkezik állapotvektorral, melyek segítségével a SMART illetve a PC pontosan tisztában lehet az egész rendszer állapotával. Az egységek által a SMART-nak küldött állapotvektorokból áll össze a SMART által a PC felé továbbított globális állapotvektor. Az alábbiakban csak a globális állapotvektor bemutatására szorítkozom, mivel azt a forrás oszlop mentén fel lehet bontani az egységek önálló állapotvektoraira. A globális állapotvektor összeállítása során a SMART-nak megfelelő módon jeleznie kell az esetleges ismeretlen értékeket. Ezeket minden esetben közötti értékek jelölnek, mivel ez a tartomány sem a százalékos értékek, sem a fél fok pontosságú hőmérséklet adatok számára nem foglalt. A hibajelzések jelentése a következő: 120 Hibás mérési eredmény (a szenzor modul nem válaszolt). 121 (nem használt) 122 Átmeneti kommunikációs hiba (a kérésre nem érkezett válasz). 123 Állandósult kommunikációs hiba (az állapot tábla alapján az egység nem elérhető). 124 Hiányzik a konfiguráció (nincs letöltött konfiguráció). 125 (nem használt) 126 Hiányzik a konverziós táblázat (a nyers mérési adatokat nem lehet értelmezni). 127 Általános hiba (minden egyéb hiba jelzésére). F.5.2. A globális állapotvektor Cím Forrás Belső név Leírás Egység 0 Serial A konfiguráció azonosítószáma 1 1 Perc (felső bájt) min 2 Perc (alsó bájt) min 3 Másodperc sec 4 Ablak állapota 1 5 Felső árnyékolás állapota 1 6 Útpárásítás működési ideje sec*5 7 Felső párásítás működési ideje sec*5 8 Fűtés állapota 1 9 Riasztás állapota 1 10 Ajtó állapota 1 11 Oldalsó ablakok állapota 1 12 Csapadék állapota 1 13 STRONG 1 A Kültér Hő C 14 STRONG 1 B Kültér Fény % 15 STRONG 2 A Ernyő felett Hő C 16 STRONG 2 B (nincs eszköz) - 17 STRONG 3 A Ernyő alatt távol Hő C 18 STRONG 3 B Ernyő alatt távol Fény % 19 STRONG 4 A Ernyő alatt közel Hő C 20 STRONG 4 B Ernyő alatt közel Pára % 21 SENSOR3 Airing 1 (nincs eszköz) sec*5 22 SENSOR3 UltraSonic 1 (nincs eszköz) sec*5 23 SENSOR3 Airing 2 Asztal 1-2 ultrahang sec*5 SMART (1) STRONG (2)

88 F. Függelék SENSOR3 UltraSonic 2 Asztal 1-2 szellőztetés sec*5 25 SENSOR3 1 A (nincs eszköz) - 26 SENSOR3 1 B (nincs eszköz) - 27 SENSOR3 2 A Fűtés C 28 SENSOR3 2 B (nincs eszköz) - 29 SENSOR3 3 A Asztal 1 Hő C 30 SENSOR3 3 B Asztal 1 Pára % 31 SENSOR3 4 A Asztal 2 Hő C 32 SENSOR3 4 B Asztal 2 Pára % 33 SENSOR4 Airing 1 Asztal 3-4 ultrahang sec*5 34 SENSOR4 UltraSonic 1 Asztal 3-4 szellőztetés sec*5 35 SENSOR4 Airing 2 Asztal 5-6 ultrahang sec*5 36 SENSOR4 UltraSonic 2 Asztal 5-6 szellőztetés sec*5 37 SENSOR4 1 A Asztal 3 Hő C 38 SENSOR4 1 B Asztal 3 Pára % 39 SENSOR4 2 A Asztal 4 Hő C 40 SENSOR4 2 B Asztal 4 Pára % 41 SENSOR4 3 A Asztal 5 Hő C 42 SENSOR4 3 B Asztal 5 Pára % 43 SENSOR4 4 A Asztal 6 Hő C 44 SENSOR4 4 B Asztal 6 Pára % SENSOR (4) A pozíciókon az 5. és 6. SENSOR egységtől származó adatok továbbítódnak a bemutatott SENSOR-októl származó adatokkal azonos formában. 69 SENSOR7 Airing 1 Asztal ultrahang sec*5 70 SENSOR7 UltraSonic 1 Asztal szellőztetés sec*5 71 SENSOR7 Airing 2 Asztal ultrahang sec*5 72 SENSOR7 UltraSonic 2 Asztal szellőztetés sec*5 73 SENSOR7 1 A Asztal 15 Hő C 74 SENSOR7 1 B Asztal 15 Pára % 75 SENSOR7 2 A Asztal 16 Hő C 76 SENSOR7 2 B Asztal 16 Pára % 77 SENSOR7 3 A Asztal 17 Hő C 78 SENSOR7 3 B Asztal 17 Pára % 79 SENSOR7 4 A Asztal 18 Hő C 80 SENSOR7 4 B Asztal 18 Pára % SENSOR (7)

89 Globális állapotvektor F. Függelék 84 F.6. Debug állapotvektorok F.6.1. Bevezetés A hibakeresés támogatására minden egység képes normál működése közben használt állapotvektorának egy bővített változatát elküldeni a SMART-on keresztül a PC-re. Az alábbiakban ezeknek a bővített állapotvektoroknak a felépítését mutatom be. A duplán szereplő értékek két bájtos adatokat jelentenek, ahol a bájtsorrendet a H és L jelzések rögzítik. Tipikusan a számlálók értéke nem továbbítható egyetlen bájt felhasználásával. F.6.2. SMART Cím Belső név Leírás Egység 1 AIState A magas szintű szabályozás állapota 2 controll_timer H Az öt perces szabályozás másodperc 3 controll_timer L számlálója sec 4 airing_timer H Az asztalszellőztetés várakozási 5 airing_timer L idejének számlálója sec 6 misting_timer H A felső párásítás várakozási idejének 7 misting_timer L számlálója sec 8 roadmisting_timer H Az útpárásítás várakozási idejének 9 roadmisting_timer L számlálója sec 10 realtime_min H Az óra perc értéke (a napból eltelt 11 realtime_min L percek száma) min 12 realtime_sec Az óra másodperc értéke sec 13 realtime_set Az óra szinkronizáltságát jelző bájt 14 lastseen[0] STRONG 15 lastseen[1] SENSOR 3 16 lastseen[2] SENSOR 4 17 lastseen[3] SENSOR 5 18 lastseen[4] SENSOR 6 19 lastseen[5] SENSOR 7 20 config_approved[0] - PC N/A 21 config_approved[1] SMART 22 config_approved[2] STRONG 23 config_approved[3] SENSOR 3 24 config_approved[4] SENSOR 4 25 config_approved[5] SENSOR 5 26 config_approved[6] SENSOR 6 27 config_approved[7] SENSOR 7 28 uwindows_state 29 ushading_state 30 global_state[0] 31 global_state[1] 32 global_state[2] 33 global_state[3] 34 global_state[4] 35 global_state[5] 36 global_state[6] 110 global_state[80] Az egységek utolsó válasza óta eltelt idők Az egységek konfigurációjának azonosító száma A felső ablakok helyben nyilvántartott állapota A felső árnyékolás helyben nyilvántartott állapota Az állapotvektor a legutóbbi lekérdezés során elküldött értékeket tárolja, tehát nem a legfrissebb adatokat, mint a fentiekben elküldött változó értékek. sec

90 Állapotvektor F. Függelék 85 F.6.3. SENSOR Cím Belső név Leírás Egység 1 config_approved A konfiguráció azonosítószáma 1 2 airing_state1 Az 1. szellőztető egység állapota 3 airing_state2 A 2. szellőztető egység állapota 4 airing_timeleft1 H Az 1. szellőztető egységen az aktuális 5 airing_timeleft1 L szellőztetésből hátralévő idő sec 6 airing_timeleft2 H A 2. szellőztető egységen az aktuális 7 airing_timeleft2 L szellőztetésből hátralévő idő sec 8 airing_usage1 H 9 airing_usage1 L Az 1. szellőztető egység működési ideje sec 10 airing_usage2 H 11 airing_usage2 L A 2. szellőztető egység működési ideje sec 12 sonic_state1 Az 1. párásító egység állapota 13 sonic_state2 A 2. párásító egység állapota 14 sonic_timeleft1 H 15 sonic_timeleft1 L Az 1. párásító egység működéséből hátralévő idő sec 16 sonic_timeleft2 H 17 sonic_timeleft2 L A 2. párásító egység működéséből hátralévő idő sec 18 sonic_usage1 H 19 sonic_usage1 L Az 1. párásító egység működési ideje sec 20 sonic_usage2 H 21 sonic_usage2 L A 2. párásító egység működési ideje sec 22 sonic_since_laststart1 H Az 1. párásító egység legutóbbi működtetése óta 23 sonic_since_laststart1 L eltelt idő sec 24 sonic_since_laststart2 H A 2. párásító egység legutóbbi működtetése óta 25 sonic_since_laststart2 L eltelt idő sec 26 min_prescaler A belső másodperc számláló állása 1 27 SENSOR Airing 1 sec*5 28 SENSOR UltraSonic 1 sec*5 29 SENSOR Airing 2 sec*5 30 SENSOR UltraSonic 2 sec*5 31 SENSOR 1 A 32 SENSOR 1 B 33 SENSOR 2 A 34 SENSOR 2 B 35 SENSOR 3 A 36 SENSOR 3 B 37 SENSOR 4 A 38 SENSOR 4 B Az állapotvektor a legutóbbi lekérdezés során elküldött értékeket tárolja, tehát nem a legfrissebb adatokat, mint a fentiekben elküldött változó értékek.

91 Állapotvektor F. Függelék 86 F.6.4. STRONG Cím Belső név Leírás Egység 1 config_approved A konfiguráció azonosítószáma 1 2 uwindows_state A felső ablakok állapota 3 ushading_state A felső árnyékolás állapota 4 heating_state A fűtés állapota 5 roadmisting_state Az útpárásítás állapota 6 misting_state A felső párásítás állapota 7 alarm_state A riasztás állapota 8 roadmisting_timeleft H 9 roadmisting_timeleft L Az aktív útpárásításból hátralévő idő sec 10 misting_timeleft H 11 misting_timeleft L Az aktív felső párásításból hátrélevő idő sec 12 roadmisting_usage H 13 roadmisting_usage L Az útpárásítás használati ideje sec 14 misting_usage H 15 misting_usage L A felsőpárásítás használati ideje sec 16 min prescaler A belső másodperc számláló állása sec 17 Ablak állapota 18 Felső árnyékolás állapota 19 Útpárásítás működési ideje 20 Felső párásítás működési ideje 21 Fűtés állapota 22 Riasztás állapota 23 Ajtó állapota 24 Oldalsó ablakok állapota 25 Csapadék állapota 26 STRONG 1 A 27 STRONG 1 B 28 STRONG 2 A 29 STRONG 2 B 30 STRONG 3 A 31 STRONG 3 B 32 STRONG 4 A 33 STRONG 4 B Az állapotvektor a legutóbbi lekérdezés során elküldött értékeket tárolja, tehát nem a legfrissebb adatokat, mint a fentiekben elküldött változó értékek.

92 F. Függelék 87 F.7. A greendiagnostics segédprogram F.7.1. Bevezetés A hibakeresés, kalibrálás és tesztelés támogatására a COM protokoll implementál üzeneteket, melyek egy egyszerű terminál program használatával elküldhetők a SMART számára a soros porton keresztül, illetve a válasz is megjeleníthető számok sorozataként. Ezek az adatok nagy mennyiségben az emberi szem számára nehezen értelmezhetőek, ezért célszerű őket egy feldolgozott, átlátható formában megjeleníteni. Hasonló a helyzet a tesztelési és hibakeresési célú parancsok esetén, ahol jó néhány bájt hosszú üzeneteket kellene kézzel, egymás után begépelni a soros terminálba. Ez a megoldás például az EEPROM tartalmak letöltésének tesztelésére teljesen alkalmatlan, hiszen egy komplett konfiguráció a SMART esetében 54 bájt hosszú. A konverziós táblázatok létrehozása során, a kalibrációs folyamat alatt a szenzorokkal számos mérést el kell végeztetni, illetve a kapott nyers mérési eredményeket megfelelően össze kell gyűjteni. Ez a feladat is megoldható lenne egy általános soros terminál programmal, ám egy célprogram használata jóval kényelmesebbé teheti a táblázatok megalkotását. Az előzőekben ismertetett három probléma megoldására hoztam létre a greendiagnostics segédprogramot, mely egy egyszerű Windows rendszeren futó grafikus alkalmazás. Az alábbiakban röviden áttekintem az általa nyújtott funkciókat. F.7.2. Hibakeresés, állapot információk A greendiagnostics program minden mikrokontrolleres egység típushoz rendelkezik egy füllel a főablakban, melyet kiválasztva az adott egység hibakeresési célú állapotvektorának adatai könnyen átlátható formában jelennek meg. Példaként az alábbi ábrán a SMART állapotát megjelenítő fül tartalma látható. F.1. ábra: A SMART állapota a greendiagnostics segítségével megjelenítve

93 F. Függelék 88 A képen látható a SMART teljes hibakereső állapotvektora, illetve mindkét karbantartott táblázat: bal oldalon helyezkedik el az egységek legutóbbi válasza óta eltelt idő, míg középen foglal helyet a konfigurációs azonosítószámokat tartalmazó táblázat. (Pillanatnyilag minden konfigurációs azonosító szám 127, jelezve, hogy egyetlen konfiguráció sincs szinkronizálva.) A bal felső panelen lehetőség van az adatokat frissíteni, vagy az automatikus 5 másodperces frissítést bekapcsolni. A két táblázat között a legfontosabb beavatkozó szervek állapota, a SMART órájának értéke, és a referenciahőmérséklet látható. A jobb oldalon felül a beavatkozó szerveknek lehet közvetlen parancsokat kiadni, míg jobb oldalon középen a SMART-ban implementált hat számláló értéke ellenőrizhető. (A Controll 5 érték színnel is ki van emelve, mivel ez vezérli az adatlekérést a slave egységekről, és az 5 perces szabályozást is.) Az ablak alján a teljes globális állapotvektor látható, az egyes értékek mellett a jelentésüket is feltüntetve. A STRONG és SENSOR modulok hasonló információs oldalakkal rendelkeznek a programon belül. F.7.3. Konfigurációk letöltése, szerkesztése A program a mikrokontrolleres egységek konfigurációjának szerkesztésére típusonként egy külön ablakkal rendelkezik, ahová az egység EEPROM-jának megfelelő része egy gomb segítségével betölthető, illetve módosítások után a tartalom egy másik gomb megnyomásával könnyedén visszaküldhető. Az egységeken az EEPROM-ban a jó helykihasználás érdekében közvetlenül a konfiguráció után tárolódnak a hibakeresést támogató változók. Ezeket a program a konfigurációval együtt, egyetlen olvasási művelettel szintén betölti a táblázat aljára, ahol a konfigurációval azonos módon szerkeszthetőek, illetve visszaírhatóak. A kontroller ezt követően újraindítás nélkül, azonnal a hibakereső változók értékének megfelelően fog viselkedni, így nagyon kényelmesen végezhető a tesztelés. A következő ábra a SMART konfigurációjának szerkesztésére szolgáló ablakot ábrázolja. F.2. ábra: A SMART konfigurációjának szerkesztő ablaka

94 F. Függelék 89 F.7.4. EEPROM tartalom olvasás A greendiagnostics segítségével könnyedén beolvasható bármelyik egység EEPROMjának tetszőleges területe. Ez egyrészt egy második módon lehetővé teszi a konfigurációk ellenőrzését, másrészt lehetőséget biztosít a konverziós táblázatok megjelenítésére, melyek mérete és elhelyezkedése a csatlakoztatott szenzor modulok függvényében változhat. Az EEPROM tartalom megjelenítésére szolgáló táblázatot a programban az alábbi ábra mutatja. A kép bal oldalán a SMART egység memóriájának tartalma látható a 0 címtől kezdve, 31 bájt hosszan. Az adatok megegyeznek az F.2. ábrán látható értékekkel, hiszen a SMART ezen a területen a konfigurációját tárolja. F.3. ábra: Az EEPROM olvasó és kalibrációs felület F.7.5. Kalibráció A konverziós táblázatok kényelmes létrehozásának támogatására a greendiagnostics az F.3. ábra jobb oldalán látható felülettel rendelkezik. A kalibrált egység címének megadása után a gombok segítségével azonnali mérés kezdeményezhető, a nyers mérési adatok lekérhetőek, a táblázat értékei a vágólapra másolhatóak, vagy a táblázat tartalma törölhető. Az egyes funkciókhoz rendelt gyorsbillentyűk (F1-F4) még gyorsabb feldolgozást tesznek lehetővé.