Bakalářská práce. Implementace klasifikátoru v bezdrátové senzorové síti

České vysoké učení technické Fakulta elektrotechnická

Bakalářská práce Implementace klasifikátoru v bezdrátové senzorové síti

Tomáš Bárta 2010

Čestné prohlášení Prohlašuji, že jsem předloženou práci vypracoval samostatně a že jsem uvedl veškeré použité informační zdroje v souladu s Metodickým pokynem o dodržování etických principů při přípravě vysokoškolských závěrečných prací.

V Praze dne ................................

................................ Podpis autora práce

Poděkování Na tomto místě bych rád poděkoval vedoucímu bakalářské práce za ochotu a trpělivost. Děkuji mu také za poskytnuté materiály a zapůjčení senzorových uzlů. Chci také poděkovat svojí rodině za stálou podporu během mého studia.

Abstrakt Tato práce se zabývá vytvořením jednoduchého jednotřídního klasifikátoru hodnot snímaných veličin v uzlu bezdrátové sítě a jeho implementací v jazyce nesC. Aplikace je navržena pro senzor IRIS od firmy Crossbow.

Abstract This thesis is focused on creating a simple one-class classifier of condition values taken by wireless sensor network node and implementation of this classifier in the nesC. The application is designed for the IRIS sensor from Crossbow Company.

Obsah 1

ÚVOD ....................................................................................................................... 8

1.1

Bezdrátové senzorové sítě .................................................................................................................................. 8

1.2

Senzorový uzel .................................................................................................................................................... 8

1.3

Struktura bezdrátové sítě .................................................................................................................................. 9

1.4

Aplikace pro bezdrátové sítě ............................................................................................................................. 9

2

SÍŤOVÉ STANDARDY ........................................................................................... 11

2.1

IEEE 802.15.4 ................................................................................................................................................... 11

2.2

ZigBee ............................................................................................................................................................... 11

2.3

Synchronizace sítě ............................................................................................................................................ 12

2.4

Síťové topologie ................................................................................................................................................ 12

3

KLASIFIKACE ....................................................................................................... 14

3.1

One-class klasifikace ........................................................................................................................................ 14

3.2

Minimalizace chybných rozpoznání ............................................................................................................... 15

4

TINYOS .................................................................................................................. 17

4.1

Komponenty ..................................................................................................................................................... 17

4.2 Architektura ..................................................................................................................................................... 18 4.2.1 Prezentační vrstva – Hardware Presentation Layer – HPL....................................................................... 19 4.2.2 Adaptační vrstva – Hardware Adaptation Layer – HAL .......................................................................... 19 4.2.3 Vrstva hardwarových rozhraní – Hardware Interface Layer – HIL .......................................................... 19 4.3

Plánování a úlohy ............................................................................................................................................. 19

4.4 Správa zdrojů ................................................................................................................................................... 20 4.4.1 Vyhrazený (dedicated) .............................................................................................................................. 20 4.4.2 Vizualizovaný (virtualized) ...................................................................................................................... 20 4.4.3 Sdílený (shared) ........................................................................................................................................ 20 4.5

Správa výkonu.................................................................................................................................................. 20

4.6

Správa paměti .................................................................................................................................................. 21

4.7

Síťová komunikace .......................................................................................................................................... 21

4.8

Bezpečnost přenosu dat ................................................................................................................................... 22

5

POUŽITÝ HARDWARE.......................................................................................... 23

5.1

XM2110 (IRIS) ................................................................................................................................................. 23

5.2

MIB520CB ........................................................................................................................................................ 24

5.3 MTS400 ............................................................................................................................................................. 24 5.3.1 Senzory na desce MTS400 ....................................................................................................................... 25 5.3.2 SHT11 ...................................................................................................................................................... 25

6

PRAKTICKÁ ČÁST ............................................................................................... 27

6.1

Rozbor ............................................................................................................................................................... 27

6.2

Návrh klasifikátoru .......................................................................................................................................... 27

6.3

Implementace ................................................................................................................................................... 28

7

ZÁVĚR ................................................................................................................... 29

POUŽITÁ LITERATURA ............................................................................................... 30 PŘÍLOHA A:

NÁVRH KLASIFIKÁTORU V MATLABU ............................................. 32

PŘÍLOHA B:

PROGRAM V TINYOS – KONFIGURACE .......................................... 33

PŘÍLOHA C:

PROGRAM V TINYOS – MODUL ........................................................ 34

1

Úvod

1.1

Bezdrátové senzorové sítě Bezdrátové senzorové sítě (Wireless Sensor Network, WSN) se skládají z množství

prostorově distribuovaných zařízení, která používají různé senzory pro monitorování fyzikálních podmínek životního prostředí, jako jsou teplota, tlak, vlhkost, světlo a pohyb. Tato autonomní zařízení se nazývají senzorové uzly. Hlavním účelem senzorové sítě je monitorování a kontrola okolního prostředí. V počátečních fázích byl vývoj bezdrátových sítí zaměřen především na využití v oblasti vojenské činnosti, např. pro potřeby monitoringu situace na bojišti. Dnes se již technologie bezdrátových sítí využívají v nejrůznějších aplikacích nejen ve sféře průmyslu, ale stále více i v běžném občanském životě, např. v domácnostech.

1.2

Senzorový uzel Senzorový uzel je samostatná entita sítě schopná získávat data ze senzorů připevněných

na jeho základní desce, dále tato naměřená data předzpracovat a pomocí komunikačního rozhraní je odeslat k uživateli. Na následujícím obrázku 1 je znázorněna architektura senzorového uzlu.

Obrázek 1:

Architektura senzorového uzlu podle [2]

Mikro-controler – provádí výpočty, zpracování dat a kontroluje ostatní komponenty Transceiver – zajišťuje komunikaci s ostatními prvky v síti Memory – paměť pro ukládání dat ADC (Analog to Digital Converter) – převádí analogové signály ze senzorů na digitální Power source – napájení hardwaru

1.3

Struktura bezdrátové sítě Základními strukturálními prvky bezdrátové sítě jsou senzorové uzly (node, mote), které

se dále kombinují se směrovači (router) a bránami (gateway), čímž se vytvoří typický WSN systém. Rozmístěné měřicí uzly bezdrátově komunikují s centrální bránou, která zajišťuje spojení s výpočetním systémem, v němž se naměřená data zpracují, vyhodnotí a dále prezentují uživateli. Přestože samotné uzly komunikují mezi sebou a posílají data k bráně, jsou do systému přidávány tzv. směrovače, které vytvářejí další komunikační cestu mezi uzly a bránou a zvyšují tím spolehlivost a rychlost přenosu dat.

1.4

Aplikace pro bezdrátové sítě V současné době aplikace vestavěných bezdrátových modulů pokrývá široké spektrum

oblastí v průmyslové i civilní sféře lidské činnosti. Oblasti použití bezdrátových sítí lze podle jejich charakteru rozdělit do sektorů, jako jsou např. vojenství, zdravotnictví, monitorování životního prostředí, průmyslová či zemědělská výroba, dopravní systémy, ale i automatizovaná domácnost a mnoho dalších. Aplikace bezdrátových sítí je obvykle spojena s potřebou určitého druhu kontroly, sledování nebo řízení konkrétní oblasti. Jejich možností je však využíváno i tam, kde by kvůli energetickým nebo infrastrukturním omezením bylo kabelové řešení mnohem nákladnější nebo náročnější na vybudování či dokonce nemožné.

Obrázek 2:

Oblasti použití WSN podle [5]

Konkrétním příkladem využití systémů WSN jsou aplikace pro monitorování životního prostředí, kde je prioritou požadavek na dlouhodobá měření stavu a jeho změn (seizmická aktivita, klimatické změny, hledání vody či půdy pro zemědělství a těžbu nerostů).

Dalším velmi důležitým oborem, kde jsou systémy WSN využívány, je distribuce elektrické energie, vody a dalších médií. V této oblasti nabízejí senzory levný způsob sběru dat o technickém stavu celého distribučního systému, možných úsporách energie a lepší správě zdrojů. Systémy WSN se také již delší dobu využívají k tzv. „automatizaci“ kancelářských i obytných budov, především jako detektory požárů nebo kvůli monitorování prostor pro účely klimatizace či bezpečnosti.

2

Síťové standardy V systémech poháněných bateriemi, kam patří i systémy WSN, je základním požadavkem

minimalizace energetické náročnosti, a to nejen jednotlivých komponent. Je třeba také také přizpůsobit aplikace danému hardwaru, protože vyšší rychlost přenosu dat a časté využívání rádiového spojení samozřejmě spotřebovává více energie. Standardním požadavkem ve WSN aplikacích je minimálně tříletá životnost baterií. Proto jsou dnešní systémy založeny na technologii ZigBee a protokolu IEEE 802.15.4.

2.1

IEEE 802.15.4 Protokol IEEE 802.15.4 je standard, který specifikuje fyzickou a MAC (Media Access

Control) vrstvu pro bezdrátové osobní sítě (LR-WPAN). Je základem pro technologie Zigbee, BlueTooth a další, z nichž každá se dále snaží nabídnout kompletní síťová řešení prostřednictvím vyšších vrstev, které nejsou pokryty standardem. Standard definuje tři základní režimy přenosu dat: periodický s krátkou dobou opakování (bezdrátové počítačové periferie) periodický s delší dobou opakování (přenos dat ze senzorů) nepravidelný (externí události) Standard IEEE 802.15.4 definuje několik základních radiových pásem, aby mohl být využit v různých zemích, kde jsou rozdílné národní předpisy a normy. Hlavním problémem u většiny bezdrátových technologii jsou rozdílné definice radiových pásem v Americe a Evropě.[4]

2.2

ZigBee ZigBee je bezdrátová komunikační technologie vystavěná na standardu IEEE 802.15.4.

Je určena pro spojení nízkofrekvenčních zařízení v síti PAN (Personal Area Network) na malé vzdálenosti do 75 metrů. Je navržena jako jednoduchá a flexibilní technologie pro tvorbu i rozsáhlejších bezdrátových sítí, u nichž není požadavek přenosu velkého objemu dat. Pracuje v bezlicenčních pásmech 868, 915 a 2400 MHz. Přenosová rychlost činí 20, 40 a 250 kbit/s. Přehled rádiových pásem je uveden na obrázku 3.

Obrázek 3:

Radiová pásma využívaná ZigBee podle [6]

Kvůli nutnosti implementovat standart ZigBee do nízko výkonových mikro-kontrolerů je důležitá maximální jednoduchost implementace protokolů, které zabírají málo místa v paměti (do 30 kB). Protokol se skládá ze tří základních vrstev. Vrstvy standardu IEEE 802.15.4, nad nimi je definována síťová vrstva (NWK) a aplikační vrstva (APL). Fyzická vrstva specifikuje přístup k přenosovému médiu. Síťová vrstva (NWK) zajišťuje připojení k sítí, zabezpečení, směrování a synchronizaci. V případě koordinátora sítě je ještě zodpovědná za start sítě a přiřazování adres nově nalezeným zařízením. Aplikační vrstva zajišťuje potřebné služby. Aplikační vrstva je zodpovědná za párování zařízení podle poskytovaných služeb a definici role jednotlivých zařízení v rámci sítě. Dále zajišťuje vyhledávání nových zařízení a zodpovídá za zabezpečení.

2.3

Synchronizace sítě Z důvodů minimalizace spotřeby koncových zařízení mohou být na základě

synchronizace mezi řadičem sítě a koncovou stanicí uspávána jednotlivá zařízení. K jejich probouzení dochází v předem definovanou dobu, a poté jsou přeneseny veškeré užitečné informace. Interval synchronizačních sekvencí může být v rozmezí 15 ms až přibližně 15 minut. Synchronizace je realizována pomocí „beacon“ rámce. Koncová zařízení jsou periodicky probouzena a přenáší data řadiči sítě. Data jsou uložena a následně přeposlána při probuzení zařízení, pro nějž jsou určena. Pokud síť funguje bez použití beacon sekvencí, jednotlivá zařízení se periodicky dotazují.

2.4

Síťové topologie Technologie ZigBee postavená na fyzické linkové vrstvě IEEE 802.15.4 definuje tři různé

síťové topologie. Znázornění jednotlivých topologií je na obrázku 4.

hvězdicová – základní topologie s centrálním řídícím uzlem (řadičem) stromová – struktura, jež umožňuje zvětšit vzdálenost mezi řadičem a koncovým zařízením mesh – typ topologie umožňující vytvořit redundantní spojení a tím libovolné uspořádání

Obrázek 4:

Síťové topologie WSN podle [5]

Jednotlivá zařízení sítě jsou adresována pomocí binárního adresného kódu o délce 64 bitů či ve zkrácené podobě 16 bitů. Každá sestavená síť je ještě dále identifikována 16 bitovým PAN ID, jež slouží pro rozlišení překrývajících se sítí postavených na standardu IEEE 802.15.4. Každou síť zakládá a spravuje koordinátor, který jí přiděluje ID. Ostatní stanice pracují jako směrovače a koncová zařízení. [3][7]

3

Klasifikace Obyčejně se senzorový uzel stará pouze o naměření hodnot a jejich odesílání k bráně, kde

se data následně zpracují. Tento proces je u větších sítí trochu problematický, protože standard Zigbee poskytuje relativně malý datový tok. Proto se snaží zavést různé výpočetní metody aplikovatelné již na uzlech, které předzpracují data nezávisle na bráně, a senzor potom odešle pouze informaci o výsledcích. Jednou z těchto možností je použití klasifikace. Klasifikace je proces řízeného strojové učení, v němž jsou jednotlivé položky umístěny do skupiny založené na kvantitativní informaci na základě již dříve označených vzorků. V podstatě se jedná o funkci, která přiřazuje (klasifikuje) jednotlivé vzorky do určené kategorie podle jejich vlastností. Cílem klasifikátoru je co nejpřesnější odhad přiřazení zpracovávaného objektu.

Obrázek 5:

3.1

Příklad klasifikace jablek a hrušek podle velikosti a hmotnosti podle [7]

One-class klasifikace Jednotřídní (one-class) klasifikace je speciální typ klasifikace, která se zabývá dvěma

soubory dat (třídami), z nichž každá má svůj zvláštní význam. Situace je prezentována obrázkem 5. Tyto dvě množiny se nazývají target-class (cílová, trénovací) a outlier-class (okolí), která v jednodušších případech bývá prázdná. V podstatě se tento typ klasifikace snaží odlišit jednu třídu objektů od všech ostatních možných předmětů na základě připravené trénovací množiny obsahující pouze objekty této třídy. Tím se liší oproti tradiční klasifikaci, která se pokouší rozlišovat mezi dvěma nebo více třídami podle školícího souboru dat, který obsahuje předměty ze všech tříd.

Typickým příkladem jednotřídní klasifikace je diagnostika stroje. Je-li stroj funkční, tedy dělá to, co dělat má, je vše v pořádku. Nastane-li však jiná situace, zřejmě se něco porouchalo a je třeba zavolat technického pracovníka, aby chybu opravil. Měření na správně běžícím zařízení je relativně levné a jednoduché (i když odběr vzorků ze všech situací, které mohou nastat, může být poněkud rozsáhlejší). Na druhou stranu měření na nefunkčním stroji a následné určení kde přesně je chyba je složitý diagnostický problém, protože porouchat se může velké množství věcí. Vytvoření vyvážené trénovací třídy pro tento případ bude tedy velice složité. Dalším příkladem je detekce. Zde je úkolem odhalit konkrétní objekt (obličej, minu) v neurčitém prostředí (fotka, půda). V rámci tohoto problému se dá předpokládat, že trénovací třída je poměrně dobře definována, ale v okolí se může nacházet cokoliv. Při klasifikaci tohoto typu dat je pravděpodobnost nalezení objektu podobného s cílovým (blízkému trénovací množině) v okolním prostředí tak veliká, takže se dá předpokládat množství falešných detekcí.

3.2

Minimalizace chybných rozpoznání Za účelem nalezení dobrého klasifikátoru musí být nízká pravděpodobnost dvou typů

chyb. Jsou to falešně pozitivní a falešně negativní detekce. V následující tabulce jsou situace, které mohou nastat při jednotřídní klasifikací.

Tabulka 1:

Typy chyb vyskytující se při klasifikaci podle [9]

Dobrý jednotřídní klasifikátor musí mít malý počet falešných detekcí. Protože chyba se pomocí trénovací třídy odhaduje docela dobře, předpokládá se, že pro všechny klasifikátory můžeme přednastavit prahovou úroveň pro chybu rozpoznání cílového vzorku. Změnou této hranice a následným měřením chyby na objektech z okolní třídy získáme křivku ROC (Receiver Operating Characteristic), která se může podobat příkladu na obrázku 6. Tato charakteristika znázorňuje, jak se podíl falešně pozitivní detekce liší v závislosti na falešně negativní. Čím

menší jsou tyto části, tím lepší je klasifikátor. Tradičně se křivka ROC vykresluje jako závislost podílu správně pozitivních a špatně pozitivních.

Obrázek 6:

Příklad křivky ROC podle [9]

Přestože křivka ROC poskytuje velmi dobrý přehled o spolehlivosti klasifikátoru, je složité porovnávat křivky od více klasifikátorů mezi sebou. Jedním ze způsobů je vyjádřit křivku jediným číslem, neboli obsahem plochy pod křivkou (Area Under the Curve, AUC). Vyšší hodnoty tohoto parametru znamenají lepší oddělení mezi vzorky z jednotlivých tříd. V praxi je jasné, že při přípravě klasifikátoru nebude znám konkrétní pracovní bod na křivce ROC. Na druhou stranu, často mohou být uvedeny přibližné rozsahy výsledků, a proto lze omezit pásmo integrace AUC na tuto specifickou část. To bude mít za následek lepší porovnání různých klasifikátorů pro danou aplikaci. [8][9]

4

TinyOS TinyOS je „open-source“ operační systém vytvořený v programovacím jazyce nesC,

určený pro vestavěné bezdrátové senzorové sítě. Velikost jádra operačního systému (méně než 400 Byte) je minimalizována kvůli omezené paměti senzorových uzlů. Model TinyOS je založen na split-phase rozhraních, asynchronních událostech a tzv. úloh.

4.1

Komponenty Systémové aplikace jsou sestaveny z komponent. Aplikace je v podstatě graf těchto

komponent. Struktura komponenty je na následujícím obrázku.

Obrázek 7:

Schéma komponenty TinyOS

Obsluhovače – jejich úkolem je obsluhovat příkazy a události ostatních komponent Rámec (framework) – datové úložiště komponenty, které má předem definovanou velikost Úloha - zatím neprovedené výpočetní operace Každá komponenta je nezávislá výpočetní součást pracující s rozhraními, která jsou používána pro vzájemnou interakci mezi dvěma komponentami. Rozhraní jsou obousměrná, protože obsahují příkazy, které mohou být implementovány jak poskytovatelem, tak uživatelem. Komponenta má k dispozici tři výpočetní abstrakce. Příkaz – žádost o vykonání nějaké operace (čtení ze senzorů) Událost – signalizace provedení příkazu Úloha – provedení čtení, výpočtu nebo jiné služby Rozhraní je označováno jako split-phase, protože obsahuje rozdělené operace, které na sebe navazují. Komponenta dále vysílá úlohu, která bude vykonána v pozdějším čase. Jazyk nesC rozlišuje dva typy komponent. Jsou jimi moduly a konfigurace. Úkolem modulů je implementovat rozhraní, čili všechny příkazy a události poskytovaných rozhraní.

Konfigurace je komponenta spojující ostatní komponenty přes rozhraní. Na následujícím obrázku je příklad konfigurace časovače. Modul TimerM je uživatel rozhraní Clock a komponenta HWClock je jeho poskytovatel.

Obrázek 8: Konfigurace časovače podle [12] Na obrázku 8 je zobrazena časová služba. Jde o konfiguraci připojující modul k hardwarové komponentě. Tímto je spojeno několik komponent do jedné a rozhraní StdControl a Timer jsou poskytovány dalším komponentám. Dále existuje tzv. parametrizované rozhraní. Jedná se o situaci, kdy komponenta může poskytovat nebo používat více instancí jednoho rozhraní, které má za parametr určitý identifikátor. Jak je vidět na výše uvedeném obrázku u rozhraní Timer, tento identifikátor bývá většinou typu integer. Takto označený identifikátor je parametrem příkazů a událostí, který od sebe odliší komponenty využívající dané rozhraní. [10][11][12][13]

4.2

Architektura Z důvodu zvýšení přenositelnosti a jednoduchosti vývoje aplikací se v operačním

systému TinyOS (od verze 2.x) zavedla tzv. architektura hardwarové abstrakce (Hardware Abstraction Architecture – HAA). Abstrakce tedy zobrazuje fyzický hardware do TinyOS modelu komponent. Její třívrstvý návrh přizpůsobuje rozhraní hardwaru k platformě, která se nachází mezi operačním systémem a aplikacemi. Každá vrstva je závislá na poskytovaných rozhraních nižšími vrstvami. Směrem od hardwaru k horním rozhraním se komponenty stávají méně závislé na hardwaru. Tato vlastnost dává větší volnost vývojářům při návrhu a implementaci opakovaně použitelných aplikací.[15]

4.2.1

Prezentační vrstva – Hardware Presentation Layer – HPL Komponenty obsažené v této vrstvě jsou umístěny přímo nad úrovní hardwaru. Jejich

hlavním úkolem je zajistit jeho funkčnost. Jednotlivé komponenty přistupují k hardwaru dvěma způsoby, Memory-mapped I/O a Port-mapped I/O. Jsou to dvě metody pro vykonávání vstupních a výstupních operací mezi mikro-kontrolerem a ostatním hardwarem. Každá komponenta je unikátní jako jednotlivý hardware, ale HPL skrývá hardwarovou složitost, protože všechny komponenty budou mít podobnou strukturu (poskytují základní operace jako čtení nebo zápis). 4.2.2

Adaptační vrstva – Hardware Adaptation Layer – HAL Komponenty HAL vrstvy operují jádro architektury. Využívá rozhraní poskytované

komponentami HPL vrstvy. Komponenty HAL mohou ukládat informace o stavu hardwaru, které se dále využívají například při kontrole spotřeby energie. Abstrakce na HAL úrovni je přizpůsobena konkrétním platformám. 4.2.3

Vrstva hardwarových rozhraní – Hardware Interface Layer – HIL Komponenty obsažené v poslední vrstvě architektury se starají o převod abstrakcí

poskytovaných vrstvou HAL na rozhraní nezávislých na hardwaru. Tato rozhraní poskytují abstrakci nezávislou na platformě, což ulehčuje vývoj aplikací.

4.3

Plánování a úlohy Úlohy se používají při vykonávání procedur, které nemusejí být provedeny ihned. Bez

nich by mohly nastat různé kolizní situace. Příkladem je příjem paketů, kdy příchozí paket vyvolá událost pro příjem, která muže ještě paket zpracovávat nějakým delším výpočtem. Po dobu průběhu tohoto výpočtu by událost nevrátila prostředky pro příjem dalšího paketu. Tím dochází k odmítnutí a následnému zahození paketu. Využití úlohy tento problém vyřeší, neboť tím se odloží daný výpočet na později a buffer pro příjem může být využit ihned. Úloha je formou procedury s odloženým voláním (Deferred Procedure Call – DPC). To znamená, že nebude vykonána okamžitě, ale bude zařazena do fronty k pozdějšímu zpracování. Úlohy se navzájem nepředbíhají, takže běží synchronně s ohledem na ostatní. Pokud je třeba u nějaké komponenty spustit delší operaci, je vhodné ji rozdělit na více úloh, neboť úloha má tu vlastnost, že sama sebe může opětovně poslat do fronty. [22]

4.4

Správa zdrojů TinyOS rozlišuje mezi třemi druhy hardwaru. [16][17]

4.4.1

Vyhrazený (dedicated) Komponenta vždy potřebuje prioritní přístup k tomuto typu zdrojů. V této třídě není

potřeba sdílení, protože o použití žádá vždy jen jedna komponenta. Do té to skupiny patří například časovač na mikro-kontroleru Atmel Atmega128. Vyhrazené zdroje jsou užitečné, když je zdroj používán jen jednou komponentou. 4.4.2

Vizualizovaný (virtualized) Každá komponenta pracuje s tímto zdrojem jako s vyhrazeným. Jedná se zde

o softwarovou vizualizaci, a proto počet komponent používajících zdroj není omezen. Vizualizované zdroje jsou vhodné pro aplikace, kde není nutná úplná kontrola nad zdrojem a je možné ho jednoduše sdílet. 4.4.3

Sdílený (shared) V situacích, kdy větší množství komponent potřebuje kontrolu nad jedním zdrojem,

přichází na řadu tzv. multiplex. Jelikož všechny komponenty nemohou mít úplnou kontrolu najednou, je úkolem multiplexování efektivní využití daného zdroje. Mezi tento typ se řadí například sběrnice.

4.5

Správa výkonu V prostředí TinyOS jsou zařízení podle správy výkonu rozdělena do dvou kategorií,

mikro-řadiče a periferie. Mikrořadiče mají několik stavů výkonu s proměnným odběrem energie. K přesnému určení tohoto stavu je třeba vědět mnoho informací. Například, zpracovává-li řadič přerušení, přepíná se do aktivního stavu a kdykoliv plánovač zjistí prázdnou frontu úloh, vrátí mikrořadič do stavu s nízkou spotřebou (režim spánku). Zatímco mikrořadič je schopný vypočítat svůj stav s nejnižší spotřebou energie, jiná zařízení (jako senzor teploty) vyžadují externí informace, aby byly schopné změnit svůj stav. Mikrořadiče mají několik stavů spotřeby energie, oproti tomu periferie mají jen dva (zapnuto, vypnuto). [18]

4.6

Správa paměti Senzorové uzly používají paměti typu Flash, která může být mazána pouze po větších

jednotkách od 256 B do 128 kB. Záleží na technologii paměťového čipu (NAND, NOR) a různí výrobci používají různé technologie. Tyto rozdíly mezi velikostmi je nutné skrýt, aby aplikace byly použitelné na různých uzlech. TinyOS rozděluje paměti do svazků pevně dané velikosti a rozlišuje je mezi třemi paměťovými abstrakcemi. [19] Velké bloky – pro dlouhodobé uložení většího množství dat Malé bloky – ukládání konfiguračních dat (identifikace uzlu, komunikační frekvence) Logy – logování výsledků událostí

4.7

Síťová komunikace Komunikace v TinyOS je zprostředkována aktivními zprávami (Active Messages). Jsou

to malé pakety o velikosti 36 B. Další důležitá věc v architektuře je buffer zpráv (message_t). Hlavním účelem tohoto bufferu je předávání paketů mezi jednotlivými linkovými vrstvami. Každá linková vrstva (pokud má daný senzorový uzel více než jednu) definuje svoji hlavičku, zápatí a metadata. Data jsou předávána jako souvislá oblast paměti bez nutnosti jejich kopírování (zero-copy semantics). Každá platforma musí poskytovat komunikaci na paketové úrovni. Toto zaručuje základní linková komponenta operačního systému (ActiveMessageC) na úrovni HIL, jež využívá tři základní rozraní. Packet – zpřístupňuje datové oblasti paketu Send – odesílá pakety Recieve – obsluhuje události spojené s příjmem paketů Dalším běžným požadavkem na aplikace bezdrátových sítí je sbírání dat a jejich přeposílání na kořenový uzel (gateway). K tomu je používán protokol CTP (Collection Tree Protocol), který zaručuje „best-effort multihop“ doručování paketů. Což znamená, že protokol vynaloží přiměřené úsilí pro doručení paketu alespoň jednomu z kořenových uzlů sítě. Není ale zaručeno doručení paketu (nebo pořadí) a k tomu dochází k doručování duplikátů. Pakety putují postupně přes uzly nacházející se na cestě ke kořenovému uzlu. Každý uzel se také stará o přeposílání dat, která obdržel od jiných uzlů.[20]

4.8

Bezpečnost přenosu dat Z důvodu rozšíření bezpečnosti v senzorových sítích byl vytvořen protokol TinySec.

Protože senzorové uzly mají omezené výpočetní a komunikační schopnosti a malou paměť, není možné použít standardní bezpečnostní protokoly známé z běžných sítí jako. TinySec je první implementovaný šifrovací protokol na úrovni linkové vrstvy. Před vytvořením tohoto protokolu byl také řešen problém, jestli je možné dosáhnout přijatelného výkonu při softwarovém šifrování nebo je potřeba i hardwarová podpora. TinySec provádí šifrování a autentizaci pouze na softwarové úrovni a žádný speciální hardware nepoužívá. [21]

5

Použitý hardware V této kapitole jsou popsány použité senzory a senzorové desky. Informace byly získány

z manuálů k daným přístrojům.

5.1

XM2110 (IRIS) Tento typ je jednou z poslední generace senzorových desek firmy Crossbow Technology.

Senzor obsahuje základní desku Atmel RF230 s integrovaným mikroprocesorem ATmega1281 a vysílačem pracujícím podle protokolu ZigBee. Komunikuje přes rozhraní IEEE 802.15.4 na frekvenci 2,4 až 2,48 GHz. Toto nastavení mu umožňuje komunikaci na třikrát větší vzdálenost než u předešlých modelů a má dvakrát větší paměťové prostory pro uložení programu. Dále obsahuje konektor s 51 piny pro připojení přídavné senzorové desky a 4 MBit flash paměť pro uložení naměřených a dalších uživatelských dat. Je napájen dvěma alkalickými bateriemi a odhadovaná doba mezi výměnami je více než jeden rok.

Obrázek 9:

Fotka senzorové desky XM2110 (IRIS) a její blokové schéma

Komunikace je realizována přes rozhraní IEEE 802.15.4 v ISM pásmu 2,4 GHz. Vysílač Atmel AT86RF230, který lze naladit na jeden z 15 kanálů odstupňovaných 5 MHz od sebe

a je navržen pro nízkonapěťové bezdrátové aplikace. Rozhraní využívá DSSS (digital direct sequence spread spectrum) modem, který poskytuje všesměrné zesílení 9 dB a efektivní datový tok 250 kb/s.

5.2

MIB520CB Tento modul zajišťuje komunikaci mezi senzory a uživatelem, používá se pro něj název

„gateway“. K počítači je připojen přes USB rozhraní, což zároveň řeší problém s napájením. Na desce je integrován procesor (ISP) Atmega16L, který se stará o programování senzorů.

Obrázek 10:

Fotka základní desky MIB520CB

Je potřeba nainstalovat ovladače FTDI FT2232C VSP, které umožní používat USB jako virtuální COM port. Po připojení desky k PC se vytvoří dva virtuální sériové porty, z nichž ten s nižší váhou se používá pro programování a druhý pro komunikaci se senzory.

5.3

MTS400 Přídavná senzorová deska MTS400 obsahuje základní nástroje pro monitorování

okolního prostředí s možností přidání modulu GPS. Proto se tento senzor dá využít ve velkém množství rozmanitých aplikací, počínaje jednoduchou meteorologickou stanicí až po komplexní senzorovou síť pro sledování širokého okolí, například v zemědělství nebo velkých podnicích. GPS modul lze použít k poziční identifikaci jednotlivých senzorů, například k vyhledávání vozidel nebo sledování nákladů.

Obrázek 11:

5.3.1

Fotka MTS400CC bez přidaného GPS modulu

Senzory na desce MTS400 Sensirion SHT11 je jednočipový modul měřící teplotu (-40 až +125 °C) a relativní

vlhkost vzduchu (0 až 100%). Osahuje 14 bitový A/D převodník a sériové rozhraní. Intersema MS5534AM je čip obsahující piezoelektrický snímač tlaku (300 až 1100 hPa) a senzor teploty (-10 až +60 °C). TAOS TLS2550 je světelný senzor vytvořený ze dvou fotodiod. Dokáže měřit intenzitu světa o vlnové délce 400 až 1000 nm, což je viditelné spektrum pro lidské oko. ADXL202JE je dvouosý akcelerometr měřící maximální zrychlení do 2 G. Je možno ho použít k detekci pohybu, náklonu nebo vibrací. 5.3.2

SHT11 Jedná se o digitální teplotní a vlhkostní čidlo vzduchu kalibrované už od výrobce, které je

aplikováno v pouzdře SIL 4 pin. Toto čidlo kromě uvedených vlastností jako je měření teploty, relativní vlhkosti a z toho vypočítaného rosného bodu je vybaveno vlastním vyhříváním a kontrolou nízkého napájecího napětí. Vnitřní vyhřívání čidla může být v případě zvýšené relativní vlhkosti a kondenzaci vody na čidlu ovládáno obslužným programem vytvářeného měřícího zařízení. Toto vyhřívání při odběru 8 mA a 5 V navýší teplotu čidla o 5 °C.

Obrázek 12:

Fotka digitálního senzoru SHT11

Nízký stav napájení čipu je indikován napětím pod hranici 2,45 V s přesností 0,05 V. Čidlo před každým měřením ze své kalibrační paměti přehrává kalibrační data senzorů, to má

za následek měření veličin o 8 ms pomaleji. Tento čas lze ušetřit, ale podstupujeme tak riziko ztráty nebo poškození výrobcem nahraných kalibračních dat vlivem přepětí či ESD. Z výroby je nastaveno, že čidlo vysouvá naměřená data s rozlišením 14 bitů (teplota) a 12 bitů (vlhkost). Hloubka rozlišení těchto AD převodů může být natavena i na 12 a 8 bitů. Pro délky čtení naměřených dat teploty (T) nebo relativní vlhkosti (RH) platí tyto časy 11/55/210 ms při AD rozlišení 8/12/14 bit.

6

Praktická část Ze zadání práce vyplývá, že je potřeba sestavit klasifikátor a implementovat ho v jazyce

nesC. Vytvořit obecný klasifikátor není vůbec jednoduchý úkol, proto jsem problém trochu konkretizoval a vymyslel základní aplikaci požárního hlásiče, který slouží ke včasné detekci a signalizaci vznikajícího požáru.

6.1

Rozbor Problematiku signalizace požáru jsem konzultoval s odborníkem, který mě odkázal

na normu ČSN EN 54. Tato norma specifikuje požadavky, zkušební metody a kritéria pro komponenty použité v požárních poplachových systémech instalované uvnitř i vně budov, které ke komunikaci využívají rádiová spojení. Existují dva druhy hlásičů. Jeden typ sleduje nárůst teploty v místnosti. Je-li navyšování teploty strmější než 10 °C za 30 sekund, spustí poplach. Druhý periodicky monitoruje teplotní a vlhkostní podmínky v místnosti a na základě jejich současné hodnoty vyhlásí stav ohrožení.

6.2

Návrh klasifikátoru Pro účely své aplikace jsem si vybral periodické monitorování teploty a vlhkosti.

V programu MATLAB byla navržena funkce klasifikátoru [Příloha A]. Vstupními proměnnými této funkce jsou dvě pole obsahující hodnoty trénovací množiny a vzorky připravené ke klasifikaci. Výstupem funkce je pole klasifikovaných vzorků, jehož grafické znázornění je na obrázku 13. Jako trénovací množina byly zvoleny body (45,60) a (120,0), které nejlépe vystihují funkci běžného hlásiče. Body trénovací množiny jsou v grafu zobrazeny zeleně. Funkce byla dále aplikována na 100 náhodných vzorků z celého oboru hodnot. Body, které byly klasifikátorem identifikovány jako zdroj požáru, jsou označeny červeně a ostatní nepřijaté vzorky jsou zbarveny modře. V tomto klasifikátoru je zbytečné zabývat se chybovostí, protože je ušit přímo na míru danému typu aplikace. Jeho koeficient AUC bude vždy roven jedné.

Obrázek 13:

6.3

Graf klasifikovaných vzorků

Implementace Při implementaci klasifikátoru jsem vycházel z ukázkového programu používaného jako

ukázková aplikace. Program po nahrání do senzorového uzlu periodicky vyčítá data ze všech senzorů a odesílá je na bránu. Přijatá data se následně dají zobrazit pomocí aplikace MoteView, kde jsou připravené prezentační tabulky. Vzorový kód jsem upravil pro své potřeby a vložil do něj klasifikační podmínku. Uzel načte vzorek ze senzoru SHT11 a potom na něj aplikuje klasifikátor. Jsou-li data shledána jako pozitivní je provedena signalizace, která je řešena rozsvícením žluté LED diody. Protože data z AD převodníku na senzoru jsou 14 a 12 bitová, je potřeba přepočítat je na reálnou hodnotu teploty a vlhkosti pomocí rovnic (1) a (2). Teplota:

TR

38,4 0,0098 data

Vlhkost:

HR

2,8 10

6

data2

4,05 10

(1) 2

data 4

(2)

7

Závěr Cílem této práce bylo navržení klasifikátoru a jeho implementace v programovacím

jazyce nesC. Protože samotný návrh obecného klasifikátoru je velmi složitý ve věci matematického popisu a následného programování, zvolil jsem si pro zjednodušení určitou aplikaci, a to požární signalizaci. Byl vytvořen jednoduchý klasifikátor v prostředí programu MATLAB. Klasifikátor je navržen přímo pro vymyšlenou aplikaci požárního hlásiče. Následně byl klasifikátor mírně upraven pro implementaci a vložen do upraveného programu. Vytvořený kód byl nahrán do senzorového uzlu ve dvou variacích. První, která pouze kontrolovala teplotu, fungovala bez problému. Po zahřátí na stanovenou teplotu začala svítit žlutá dioda. Druhá variace s přidanou kontrolou vlhkosti nevyhodnocovala podmínky podle mých představ a k rozsvícení diody nedošlo. Problém se pravděpodobně skrývá v tom, že při vytváření podmínek nastavených na klasifikátoru se pravděpodobně nepodařilo nasimulovat vlhkost vzduchu. Závěrem bych chtěl dodat něco k vybranému programovacímu jazyku. Osobně si myslím, že pro nějaké rozsáhlejší projekty není tento jazyk příliš vhodný. Nejsem zkušený programátor a s tímto jazykem teprve začínám pracovat. Přestože moje aplikace není příliš náročná, její zpracování nebylo zcela bez problémů, a to hlavně kvůli provázanosti komponent a celkové struktuře samotného jazyka. Do budoucna bych zvážil vyzkoušení jiného programovacího prostředí a samotného jazyka. Například firma National Instruments vyrábí také bezdrátové senzory a založila je na svém systému LabView, což je grafické prostředí určené k programování měřicích desek a automatizaci procesů. Tato práce mi značně rozšířila orientaci v oblasti bezdrátových sítí a přinesla mnoho nových informací.

Použitá literatura [1]

Wsn. In Wikipedia : the free encyclopedia [online]. St. Petersburg (Florida) : Wikipedia Foundation, 15.3.2006, last modified on 30.5.2010 [cit. 2010-06-02]. Dostupné z WWW: http://en.wikipedia.org/wiki/Wsn

[2]

Sensor node. In Wikipedia : the free encyclopedia [online]. St. Petersburg (Florida) : Wikipedia Foundation, 11.6.2007, last modified on 1.6.2010 [cit. 2010-06-02]. Dostupné z WWW: http://en.wikipedia.org/wiki/Sensor_node

[3]

ZigBee. In Wikipedia : the free encyclopedia [online]. St. Petersburg (Florida) : Wikipedia Foundation, 4.6.2005, last modified on 30.5.2010 [cit. 2010-06-02]. Dostupné z WWW: http://en.wikipedia.org/wiki/ZigBee

[4]

IEEE 802.15.4. In Wikipedia : the free encyclopedia [online]. St. Petersburg (Florida) : Wikipedia Foundation, 1.8.2008, last modified on 1.8.2008 [cit. 2010-06-02]. Dostupné z WWW: http://en.wikipedia.org/wiki/IEEE_802.15.4

[5]

Communication Networks. In Wikipedia : the free encyclopedia [online]. St. Petersburg (Florida) : Wikipedia Foundation, 22.8.2007, last modified on 12.9.2009 [cit. 2010-06-02]. Dostupné z WWW: http://en.wikibooks.org/wiki/Network_Topologies

[6]

National instruments [online]. 2009 [cit. 3.5.2010]. Wireless Sensor Networks. Dostupné z WWW: http://www.ni.com/wsn/

[7]

BRADÁČ, Zdeněk. Bezdrátový komunikační standard ZigBee. Automatizace [online]. Duben 2005, 48, 4, [cit. 3.5.2010]. Dostupný z WWW: http://www.automatizace.cz/article.php?a=638

[8]

TAX, David. One-class classification [online] : ASCI, 2001. 190 s. Dizertační práce. ASCI. Dostupné z WWW: . ISBN 90-75691-05-x.

[9]

TAX, David. Data description toolbox : dd tools 1.5.0 [online]. Nizozemsko : Delft University of Technology, 26.7.2006 [cit. 4.5.2010]. Dostupné z WWW: http://homepage.tudelft.nl/n9d04/dd_manual.pdf

[10] GAY, David, et al. The nesC Language : A Holistic Approach to Networked Embedded Systems [online]. Berkeley : PLDI, 2003 [cit. 4.5.2010]. Dostupné z WWW: http://www.eecs.berkeley.edu/~pal/pubs/nesc-pldi03.pdf [11] GAY, David, et al. NesC 1.1 Language Reference Manual [online]. Berkeley : PLDI, květen 2003 [cit. 4.5.2010]. Dostupné z WWW: http://nescc.sourceforge.net/papers/nescref.pdf [12] LEVIS, Philip, TinyOS Programming [online]. Revize 1.2. Berkeley :, 28.6.2006 [cit. 4.5.2010]. Dostupné z WWW: http://csl.stanford.edu/~pal/pubs/tinyos-programming.pdf [13] LEVIS, Philip, et al. TinyOS: An Operating System for Sensor Networks [online]. Berkeley : 28.6.2006 [cit. 4.5.2010]. Dostupné z WWW: http://www.dbis.ethz.ch/education/ss2007/tatbul/hotdms/papers/tinyos_chapter.pdf

[14] ROSSI, Dario. Sensors as Software : TinyOS [online] : 16.3.2006 [cit. 5.5.2010]. Dostupné z WWW: http://www.telematica.polito.it/wsn/ppt/WSN2_TinyOS.pdf [15] HANDZISKI, Vlado, et al. TinyOS 2.0.2 Documentation [online]. 2007 [cit. 6.5.2010]. Hardware Abstraction Architecture. Dostupné z WWW: http://www.tinyos.net/tinyos2.1.0/doc/pdf/tep2.pdf [16] TinyOS Documentation Wiki [online]. 19.10.2007, 17.1.2009 [cit. 6.5.2010]. Modules and the TinyOS Execution Model. Dostupné z WWW: http://docs.tinyos.net/index.php/Modules_and_the_TinyOS_Execution_Model [17] KLUES, Kevin, et al. TinyOS Documentation [online]. Revize 1.7. 11.1.2006, 21.2.2007 [cit. 6.5.2010]. Power Management of Non-Virtualised Devices. Dostupné z WWW: http://www.tinyos.net/tinyos-2.1.0/doc/pdf/tep115.pdf [18] SZEWCZYK, Robert, et al. TinyOS Documentation [online]. Revize 1.7. 19.9.2005, 1.10.2007 [cit. 6.5.2010]. Microcontroller Power Management. Dostupné z WWW: http://www.tinyos.net/tinyos-2.1.0/doc/pdf/tep112.pdf [19] GAY, David, et al. TinyOS Documentation [online]. 2007 [cit. 6.5.2010]. Permanent Data Storage. Dostupné z WWW: http://www.tinyos.net/tinyos-2.1.0/doc/pdf/tep103.pdf [20] LEVIS, Philip. TinyOS Documentation [online]. Revize 1.10. 10.12.2004, 28.3.2007 [cit. 7.5.2010]. Packet Protocols. Dostupné z WWW: http://www.tinyos.net/tinyos2.1.0/doc/pdf/tep116.pdf [21] HAI, Yan. Xxx [online]. 27.4.2006 [cit. 7.5.2010]. TinySec: A Link Layer Security. Dostupné z WWW: http://uwsn.engr.uconn.edu/presentations/TinySec.ppt [22] LEVIS, Philip. TinyOS Documentation [online]. 2007 [cit. 7.5.2010]. Schedulers and Tasks. Dostupné z WWW: http://www.tinyos.net/tinyos-2.1.0/doc/pdf/tep106.pdf

Příloha A:

Návrh klasifikátoru v MATLABu

function O = klasifikace(a,b) pocetA = size(a(:,1)); minX = min(b(:,1)); minY = min(b(:,2)); maxX = max(b(:,1)); maxY = max(b(:,2)); O = zeros(pocetA(1), 3); inc = 1; while (inc<=pocetA(1)) P = a(inc,:); if (P(1)>minX && P(1)<maxX && P(2)>minY && P(2)<maxY) O(inc,:) = [P,1]; else O(inc,:) = [P,0]; end inc = inc + 1; end return

Příloha B:

Program v TinyOS – Konfigurace

includes sensorboardApp; configuration XMTS400 { } implementation { components Main, XMTS400M, SensirionHumidity, MicaWbSwitch, GenericCommPromiscuous as Comm, MULTIHOPROUTER, ADCC, Voltage LEDS_COMPONENT TimerC; Main.StdControl -> XMTS400M; Main.StdControl -> MULTIHOPROUTER.StdControl; Main.StdControl -> Comm; Main.StdControl -> TimerC; XMTS400M.ADCControl -> ADCC; LEDS_WIRING(XMTS400M) XMTS400M.BattControl -> Voltage; XMTS400M.ADCBATT -> Voltage; XMTS400M.TempHumControl -> SensirionHumidity; XMTS400M.Humidity -> SensirionHumidity.Humidity; XMTS400M.Temperature -> SensirionHumidity.Temperature; XMTS400M.HumidityError -> SensirionHumidity.HumidityError; XMTS400M.TemperatureError -> SensirionHumidity.TemperatureError; XMTS400M.RouteControl -> MULTIHOPROUTER; XMTS400M.Send -> MULTIHOPROUTER.MhopSend[AM_XMULTIHOP_MSG]; MULTIHOPROUTER.ReceiveMsg[AM_XMULTIHOP_MSG] -> Comm.ReceiveMsg[AM_XMULTIHOP_MSG]; XMTS400M.HealthMsgGet -> MULTIHOPROUTER; XMTS400M.health_packet -> MULTIHOPROUTER.health_packet; XMTS400M.Timer -> TimerC.Timer[unique("Timer")]; XMTS400M.TO_Timer -> TimerC.Timer[unique("Timer")]; }

Příloha C:

Program v TinyOS – Modul

#include "appFeatures.h" module XMTS400M { provides interface StdControl; uses { interface MhopSend as Send; interface RouteControl; interface ADC as ADCBATT; interface StdControl as BattControl; interface SplitControl as TempHumControl; interface ADC as Humidity; interface ADC as Temperature; interface ADCError as HumidityError; interface ADCError as TemperatureError; interface Timer as TO_Timer; interface ADCControl; interface Timer; interface Leds; command void health_packet(bool enable, uint16_t intv); command HealthMsg* HealthMsgGet(); } } implementation { enum { START, BUSY, GPS_DONE }; enum { SENSOR_NONE = 0, SENSOR_BATT_START = 10, SENSOR_HUMIDITY_START = 20, SENSOR_HUMIDITY_GETHUMDATA = 21, SENSOR_HUMIDITY_GETTEMPDATA = 22, SENSOR_HUMIDITY_STOP = 23 }; norace uint32_t timer_rate; bool sleeping; norace uint8_t main_state; norace uint8_t sensor_state; TOS_Msg msg_buf_radio; TOS_MsgPtr msg_radio; norace XDataMsg readings; HealthMsg *h_msg; norace uint8_t iNextPacketID; norace bool sending_packet,sensinginsession; task void Battstop() { call BattControl.stop(); }

task void TempHumstart() {call TempHumControl.start();} task void TimeTOtart(){call TO_Timer.start(TIMER_ONE_SHOT,timer_rate);} task void send_radio_msg() { uint8_t i; uint16_t len; XDataMsg *data; data = (XDataMsg *)call Send.getBuffer(msg_radio, &len); for (i = 0; i < sizeof(XDataMsg); i++) ((uint8_t*)data)[i] = ((uint8_t*)&readings)[i]; data->xmeshHeader.board_id = SENSOR_BOARD_ID; data->xmeshHeader.packet_id = iNextPacketID; data->xmeshHeader.parent = call RouteControl.getParent(); data->xmeshHeader.packet_id = data->xmeshHeader.packet_id | 0x80; if(call Send.send(BASE_STATION_ADDRESS,MODE_UPSTREAM,msg_radio, sizeof(XDataMsg)) != SUCCESS) { atomic {sending_packet = FALSE; main_state = START;}} return; } task void stopTempHumControl(){ atomic sensor_state = SENSOR_HUMIDITY_STOP; call TempHumControl.stop(); return; } command result_t StdControl.init() { atomic {msg_radio = &msg_buf_radio; sending_packet = FALSE;} call BattControl.init(); TOSH_MAKE_FLASH_OUT_OUTPUT(); TOSH_MAKE_FLASH_CLK_OUTPUT(); call ADCControl.init(); call Leds.init(); call TempHumControl.init(); timer_rate = XSENSOR_SAMPLE_RATE; return SUCCESS; } command result_t StdControl.start() { // osetreni chyb na senzoru call HumidityError.enable(); call TemperatureError.enable(); atomic main_state = START; atomic sensor_state= SENSOR_NONE; h_msg = call HealthMsgGet(); h_msg->rsvd_app_type = SENSOR_BOARD_ID; call health_packet(TRUE,TOS_HEALTH_UPDATE); call Timer.start(TIMER_REPEAT, 1024); // spusteni casovace return SUCCESS; } command result_t StdControl.stop() { call BattControl.stop(); call Timer.stop(); return SUCCESS; }

event result_t Timer.fired() { uint8_t l_state; call Leds.redToggle(); if(sending_packet) return SUCCESS; atomic l_state = main_state; switch(l_state) { case BUSY: break; case START: atomic {main_state = BUSY; sensor_state = SENSOR_BATT_START;} call Leds.redToggle(); call BattControl.start(); if (!sensinginsession){ call ADCBATT.getData(); atomic sensinginsession = TRUE; } break; } return SUCCESS; } async event result_t ADCBATT.dataReady(uint16_t data) { if (!sensinginsession) return FAIL; atomic sensinginsession = FALSE; readings.xData.data6.vref = data; post Battstop(); atomic{main_state = BUSY;sensor_state = SENSOR_HUMIDITY_START;} call Leds.redToggle(); post TempHumstart(); post TimeTOtart(); //klasifikacni podminka, je-li splnena rozsviti se zluta LED if ((readings.xData.data6.temp>10040) && (readings.xData.data6.humidity<1333)) {call Leds.yellowOn();} else {call Leds.yellowOff();} return SUCCESS; } event result_t TO_Timer.fired() { return SUCCESS; } async event result_t Temperature.dataReady(uint16_t data) { readings.xData.data6.temp = data; post stopTempHumControl(); return SUCCESS;} async event result_t Humidity.dataReady(uint16_t data) { readings.xData.data6.humidity = data; atomic sensor_state = SENSOR_HUMIDITY_GETTEMPDATA; call Temperature.getData(); return SUCCESS;}

event result_t TempHumControl.startDone() { atomic call TO_Timer.stop(); atomic sensor_state = SENSOR_HUMIDITY_GETHUMDATA; call Humidity.getData(); return SUCCESS; } event result_t TempHumControl.stopDone() { atomic {main_state = BUSY; sensor_state = SENSOR_HUMIDITY_STOP;} call Leds.redToggle(); return SUCCESS; } event result_t HumidityError.error(uint8_t token) { call Temperature.getData(); return SUCCESS; } event result_t TemperatureError.error(uint8_t token) { call TempHumControl.stop(); return SUCCESS; } static void initialize() { atomic { sleeping = FALSE; main_state = START; sending_packet = FALSE; timer_rate = XSENSOR_SAMPLE_RATE; sensinginsession=FALSE; } } event result_t Send.sendDone(TOS_MsgPtr msg, result_t success) { atomic {msg_radio = msg;sending_packet = FALSE;} return SUCCESS; } }