Wsn_Softverski_Tehnologii

УНИВЕРЗИТЕТ “СВ. КЛИМЕНТ ОХРИДСКИ” - БИТОЛА ТЕХНИЧКИ ФАКУЛТЕТ Семинарска работа по предметот Безжични сензорски мрежи Софтверски технологии кај WSN изработил ментор Миленковска Талевска Наташа проф.др. Маркоски Александар бр.индекс 19/08 Битола, март 2010 Содржина 1. Вовед 2 2. Middleware 4 2.1. Карактеристики на WSN Middleware 5 2.2. Различни приоди кон креирање на Middleware за WSN 6 2.3. Архитектури на Middleware базирани на кластери 7 3. Програмирање на апстракции 9 4. Агентски технологии кај WSN 9 4.1. Агентски платформи 10 4.2. Примена на карактеристиките на агентите во WSN 11 5. Архитектура на софтвер за WSN 12 5.1. Софтвер кај јазлите-сензори 14 6. TinyOS 14 6.1. Компоненти 15 6.2. Модули 16 6.3. Интерфејси, команди и настани 18 6.4. Внатрешни функции 19 6.5. Split-Phase операции 20 6.6. Задачи (Tasks) 21 6.7. Модел на конкурентност 21 6.8. Правила за именување 23 7. TinyDB 25 8. Заклучок 29 9. Користена литература 30 1. Вовед Имајќи ги во предвид се поголемите напори на сите светски сили за справување со големите климатски нарушувања, прибирањето на информации за различните промени во животната средина станаа неизбежни. За таа потреба, технологијата се движи во насока на производство на мали уреди, опремени со сензори, кои би следеле различни промени на локациите на кои би биле поставени. Тука многу добро се вколпуваат сензорските мрежи. Земајќи ја во предвид распространестоста на нивното поставување, безжичното поврзување на таквата мрежа игра важна улога. Безжичните сензорски мрежи се состојат од просторно дистрибуирани независни сензори кои се користат за кооператвно следење на физички промени или промени во животната средина како на пример температура, звук, вибрации, притисок, движење или загадување. Нивната првична примена била за следење т.е. надзор на бојните полиња. Денес полето на примена на безжичните сензорски мрези е многу поголемо. Тргнувајќи од следење и контрола на процесите во индустријата, следење на состојбата на исправност на машини, мониторинг на промените во животната средина, сообраќајна контрола, разни истражувања во медицината итн. Секој сензор од сензорската мрежа е опремен со радио трансивер или друг уред за безжична коминикација, мал микриконтролер, како и извор на енергија, во најчест случај батерија. Нивната големина може да варира од големина на кутија за чевли па се до големина на зрно од прашина. [pic] Сл 1.1 Mica2 јазол-сензор составен од 2 АА батерии, CPU, меморија, трансивер, антена и 52-пински конектор Сензорска мрежа обично претставува безжична ад-хок мрежа, што значи дека секој сензор поддржува мултихоп рутирачки алгоритми (неколку јазли можат да испратат податочни пакети до базна станица). Уникатните карактеристики на WSN вклучуваат: • Ограничена моќ на складирање • Способност да издржат во тешки услови на животната средина • Способност да се справат со пропусти • Мобилноста на сензорите-јазли • Динамичка мрежна топологија • Хетерогеноста на јазли • Испади во комуникацијата • Големото ниво на ангажирање • Делување без надзор • Скалабилен капацитет на бројност, кој единствено е ограничен од пропусната моќ на јазолот портал. Главниот предизвик при дизајнирањето на сензор-јазли е да се произведе сензор со ниска цена и мали димензии. Во однос на овие цели, сегашните сензор јазли се главно прототипови. Минијатурноста и ниската цена ги следат последнитете и идните напредоци во областа на MEMS (Micro-Electro-Mechanical Systems) и NEMS (Nanoelectromechanical systems). Дел од овие јазли се сеуште во фаза на истражување. Информациите кои се добиваат од јазлите-сензори треба да се проследат и процесираат за да се добијат резултати според кои би се донесувале одредени одлуки или би се преземале одредени акции. Тука многу важна улога игра софтверот кој би се користел. Како на јазлите-сензори, така и на серверот кој би ги прибирал податоците. Енергијата е најограничениот ресурс кај WSN јазлите и обично го одредува животниот век на WSN мрежите. Ако се земе во предвид тоа што јазлите-сензори се распределени и на тешко достапни места, протоколите и алгоритмите кои се однесуваат на ваквиот тип на мрежи треба да ги задоволуваат следните каракеристики • Максимизирање на животниот век • Робустностност и толеранција на грешки • Авто-конфигурација Со самото тоа што се работи за мрежно поврзување, постојат мрежни протоколи кои се грижат за транспорт на податоците, рутирање на истите, протолоки за пристап до медиумите итн. Од друга страна тука се и апликациите за безжичните сензорски мрежи. Така постои јаз помеѓу мрежните протоколи, од една страна, и апликациите, од друга страна. Треба да се обезбедат функции за адаптација помеѓу мрежните протоколи и апликациите, за да се задоволат барањата на специјалните карактеристики на безжичните сензорски мрежи и разновидноста на апликациите. Функциите за адаптација треба да овозможат обезбесување на квалитетно извршување на сервисите потребни за апликациите користејќи ограничени ресурси и продолжување на животниот век на јазилте-сензори. Како и кај стандардните дистрибуирани системи, middleware е пристапот кој ги задоволува наведените адаптации. Ако се земе во предвид дека WSN мрежите се со ограничени ресурси од типот на прописност, пресметувачка моќ, комуникациски способности и енергија, дизајнирањето на middleware-от е доста сложен. Се “наоѓа” под апликацискиот слој и над оперативниот систем и мрежните протоколи. Неговата задача е проследување на апликациските барања, криење на деталите од пониско ниво, олеснување на развојот на апликациите и нивното менаџирање. Покрај middleware-от, за да се добие целокупна слика на состојбата на јазлите-сензори, се почесто се прибегнува кон мултиагентски технологии. Како што е познато софтверски агент е автономен процес кој реагира на околината, но исто така иницира промени во околината во соработка со клинети или други агенти. Особината која го прави агентот нешто повеќе од процес е неговата можност да дејствува по своја иницијатива. Сето ова е доста применливо кај WSN мрежите. Со огле на тоа што постојат различни типови на агенти, со нивна комбинација се доаѓа до доста моќен мултиагент систем. И на крај, софтверот кој е инсталиран на WSN мрежите мора да исполнува одредени ограничувања: избор на програмски јазик, оперативен систем, база на податоци, ... Тука мора да се нагласи генералноста на оперативните системи за WSN и специјализираноста на апликациите. Првите мора да се што поопшти и да одговараат за различни топологии на мрежи, додека апликативниот софтвер е тесно поврзан со намената, односно целта на WSN мрежата. Како најчето користен оперативен систем за јазлите-сензори се јавува TinyOS, оперативен систем кој паралелни се движи со прилично новиот програмски јазик nesC. nesC може да се рече дека е дијалект на стандардниот програмски јазик C. Главна улога во програмирањето играат компонентите и интерфејсите. За сето добро да е спакувано, од прием на информацијата па се до нејзино понатамошно проследување, важна улога игра и TinyDB, “лесна” база на податоци со соодветен SQL, во која би се складирале податоците. 2. Middleware Во последните години, WSN мрежите се многу атрактивни за повеќе области од секојдневниот живот. Првично WSN мрежите биле специјализирани, односно поддржувале една апликација за една мрежа. При тоа, дизајнот на мрежните протоколи со апликацијата што се користи бил тесно поврзан, а во некои случаи дури и комбиниран во монолитна процедура. Таквите процедури директно комуницирале со оператиовниот систем, а во некои случаи дури и со самиот хардвер. Во денешно време се повеќе WSN мрежите се користат повеќенаменски. Тоа значи дека една иста мрежа од сензори би полсужила за повеќе видови на мониторинг. Во овој случај, WSN треба да поддржува повеќе апликации конкурентно да се извршуваат на една мрежа. Middleware е слојот кој стои помеѓу целиот мрежен хардвер, опратиовниот систем и апликациите и неговата цел е да обезбеди: • Стандардизирани системски сервиси за различните апликации • Околина за извршување која поддржува и координира повеќе апликации • Механизми кои би обезбедиле прилагодливо и ефикасно користење на системските ресурси Само таков middleware практично е корисен за WSN мрежите врз кои се извршуваат комплексни апликации со голема количина на информации кои се процесираат по строго определени правила. Middleware може да се сфати како мост помеѓу оперативниот систем и апликациите, кој многу придонесува во развојот на дистрибуираните апликации. [pic] Сл 2.1 Традиционален мрежен дистрибутивен систем Традиционалните middleware (како DCOM, CORBA, PVM, MPI) не излегува во пресрет на барањата на WSN мрежите. Тие најчесто бараат голема меморија, енергија и пресметки. 2.1. Карактеристики на WSN Middleware [pic] Сл 2.1.1 Ако се земат во предвид фактите од типот: минијатурни димензии на сензор-јазлите, ограничено количество на енергија, ограничени перформанси на процесорот и меморијата како и безжичен комуникациски проток и ранг, тогаш middleware за WSN мрежите треба да ги исполнуваат следните предизвици: • Поддршка за развој, одржување, инсталирање (deployment) и извршување на апликации кои се базирани на насетување. Ова вклучува механизми за дефинирање на комплексни задачи за насетувања на високо ниво, комуникација на овие задачи со WSN, нивно координирање со сензор-јазлите, како и читање на информациите се со цел тие да се спојат во резултати од високо ниво и тие да се испратат до задавачот на задачата. • Работа во мрежа во која безжично се поврзани огромен број на јазли-сензори. • Обезбедување на апстракција на мрежата во однос на хетерогеноста на различните компоненти кои неа ја сочинуваат. • Исполнување на главните барања на WSN мрежите, имено: ефикасно користење на енергијата, сигурност и скалабилност. • Дозволување на периодична комуникација или комуникација базирана на одреден настан. • Обезбедување на поддршка за автоматско конфигурирање и менаџирање на грешки, доста важен аспект ако се има во предвид дека јазлите оперираат независно. • Времето и локацијата, доста битни концепти при прибирање на информации и нивно обединување од различните сензори. • Обезбедување на механими за што полесно инјектирање на знаење во инфрастуктурата на мрежата. • Обезбедување на поддршка за апликации работаат во реално време. 2.2. Различни приоди кон креирање на middleware за WSN Во однос на моделот на програмирање на WSN, постојат два типа на пристап: програмирање на мрежата со акцент на поддршката или програмирање на мрежа со аспект на апстакција на мрежата. Кај првиот пристап пак, постојат пет пристапи базирани на: виртуелна машина (Maté, Squawk), модуларно програмирање – мобилни агенти (Impala, Smart Messages Project), бази на податоци (Cougar, TinyDB, SINA, DSWare), според потребите на апликацијата (Milan), Middleware базиран на пораки – MOM (MIRES, SensorBus). Постојат и други пристапи кои не можат да се сврстат во претходните пет како AutoSec, Agilla, Garnet, како и архитектури базирани на кластери. 2.3. Архитектури на Middleware базирани на кластери Главна карактеристика на овој пристап е тоа што семантиката на апликацијата е одвоена од инфраструктурата на мрежата и е базиран на кластери. Кластер е множество на просторно соседни јазли-сензори кои што се наоѓаат околу целната појава и се способни да детектираат и/или процесираат податоци кои се од интерес. Кластерите динамички се формираат во текот на целиот животен век на системот, предизвикани од некаква промена во околината, изворитена подаотци или самите јазли-сензори. Соодветно на тоа, членовите на кластерот соодветно се прилагодуваат. Исто така е можно во рамките на еден систем да постојат повеќе кластери и тие да се преклопуваат. За време на формирањето на кластерот, еден јазол е избран за главен и е одговорен за контрола и координација на сите останати членови на соодветниот кластер. [pic] Сл 2.3.1 Архитектектура на middleware базиран на кластери Како што е прикажано на сл 2.3.1, инфраструктурата на middleware-от е поделена на два слоја. Апстракцијата што ја нуди middleware-от ја нарекуваме виртуелна машина, поради сличноста со концептот за виртуелна машина кој е претставен во традиционалните диструбуирани системи и овозможува тренаспарентност на семантиката на апликациите од физичката инфраструктура. Иако протоколот за формирање и контрола на кластерите е дистрибуиран низ сите јазли-сензори, се претпоставува дека кодот за слојот за менаџирање со ресурси се наоѓа на главниот јазол. Мултикластер хиерархиска архитектура се гради аналогно на претставениот начин од сл 2.3.1. Ако се разгледува сл 2.3.1 очигледно е дека вируелната машина е поделена на два слоја и тоа: • Слој кластер: Овој слој е одговорен за формирање на кластерите од базенот на сезори-јазли кои се наоѓаат околу целта на опсервација. Главни критериуми за одредување на членство на сензорите-јазли се: достапноста на податоците, способноста на јазлите-сензори и мрежната конекција. Прибирањето и размената на таквите информации треба да биде на дистрибуиран начин. • Слој за менаџирање на ресурси: Клучната компонента на еден middleware е слојот за менаџирање на ресурси. Ја контролира алокацијата и адаптација на ресурсите на начин што захтевите на QoS (Quality of Service) сервисот специфицирани со апликацијата ќе бидат задоволени. Распределбата, алокацијата на ресурсите се однесува на донесувања на првична одлука при формирање на кластерот, додека адаптацијата го контролира однесувањето на кластерот при активност во реално време. Многу е важно да се обезбеди робустност на ситемот. Варијациите во системот и животната околина можат да доведат до нарушување на капацитетот на јазлите-сензори како и нарушувања во квалитетот на комуникациските канали, па дури и до целосни откази. Затоа информациите од таков вид треба периодично да се собираат преку протоколот за контрола на кластерот и да се ажурираат кај главниот јазол. Овој пак, е задолжен за преземање на соодветни мерки за адаптација за да не се нарушат QoS на апликацијата. При развојот на кластер-базираните архитектури вклучени се уште неколку важни предизвици и елементи како: • Контрола на кластерите: Поради динамичниот карактер на феноменот што се следи и поради потребата од заедничка обработка на сигналите, неопходно е да се развие дистрибутивен кластерски механизам за самостојно конфигурирање во од. Поконкретно, таквите механизми се одговорни за формирање на почетниот кластер и негова понатамошна адаптација. • Менаџирање на ресурси: Главна улога во менаџирањето на ресурсите е периодично собирање и ажурирање на информациите за кластерот кај главниот јазол-сензор, а кои се однесуваат на способностна на јазлите-сензори, нивното количество енергија како и мрежната комуникација. Различни начини можат да се користат за одредување на фреквенцијата на собирање на податоците. Тоа може да биде периодично иницирано од главниот јазол-сензор, или секој член може да испраќа порака ако неговата енергија е пониска од некој претходно одреден праг. Сето ова е во зависност од метриките кои се поставени при креирањето на кластерот. • Внатре-кластерска координација: Во кластер-базираниот middleware, размената на информации е потребна и за координација на јазлите-сензори, и за делење на инфорамции. Така, собраните податоци од еден кластер можат да бидат побарани или од базната станица или од некој друг кластер кој се наоѓа на истата мрежа. За таа цел кај главниот јазол егзистира рутирачки протокол со помош на кој се проследува бараната информација. Друг проблем е кога кластерите се преклопуваат едни со други. Во тој случај е неопходно да се обезбедат потребни механизми кои ќе можат да го координираат ова преклопување се со цел да не дојде до ќор-сокак при натпреварувањето на кластерите за ресурсите. Таквите механизми опфаќаат воведување на алиаси, со што се одредува идентифицирање на јазлите кога тие припаѓаат на повеќе преклопувачки кластери. 3. Програмирање на апстракции Постојат два пристапи при прогрaмирањето на класи на апстракции: • Глобално однесување, или макро-програмирање: Пристап со кој сензорските се програмираат како целина, наместо пишување на код за индивидуалните јазли-сензори. Примери за овој пристап се: Karios, Regiment, Abstract Task Graph, Semantic Streams, … • Локално однесување: Се разгледува однесувањето на јазлите-сензори од мрежата од локална гледна точка при дистрибуирани пресметки. Фокусот се става на податоците, поточно на специфични локации од мрежата (Abstract regions, EnviroTrack, Hood, Generic role assigment). 4. Агентски технологии кај WSN Агентите се ентитети кои во дадена средина можат да чувствуваат и реагираат, па затоа и се квалификувани и да комуницираат и соработуваат со други ентитети и агенти. Овозможуваат униформна синтакса и со семантиката која ја овозможуваат играат посредничка улога. Ако се земат во предвид атрубутите кои ги имаат, се издвојуваат следните видови на агенти: • Интелигентни агенти: ентитети кои емулитаат ментални процеси или симулираат рационално однесување. • Лични асистенти: ентитети кои им помагаат на корисниците за извршување на одредена задача. • Мобилни агенти: етитети кои се во состојба да се движат низ мрежата за да исполнат одредена цел. Тие се способни да го мигрираат нивниот код помеѓу јазлите-сензори. [pic] Сл 4.1 Архитектура на MAWSN (Mobile Agent for WSN) • Агенти за информации: агенти кои фи филтрираат и организираат кохерентно дисперзираните и неповрзани податоци. • Автономни агенти: агенти способни за дејствување без присуство на надзор. Според карактеристиките на агентите, може да се дефинира мултиагент систем како дистрибуиран систем формиран од агенти кои се способни да соработуваат меѓу себе и да ги делат ресурсите, се со цел да се изврши одредена заедничка или индивидуална задача. Од тие причини, агентите треба да се способни за интеракција во дадената околина и да имаат способност за комуницирање, преговарање и координирање. Целата на еден мултиагентски систем е да стане автономен систем. Главни карактеристики кои агент-базираните програми ги разликуваат од традиционалните програми се следните: • Автономност: агентите сами прават одлуки, бидејќи реагираат според своите потреби • Секој агент има своја нишка на извршување, за разлика од традиционалната програма која има еден тек за цел систем. 4.1. Агентски платформи На агентите им се потребни одредени платформи кои ќе им овозможат одредени сервиси како идентификација, мобилност, комуникација и други сервиси потребни за нивно извршување. Како најексплоатирани архитектури за мултиагентски системи се: KAoS (Knowledgeable Agent-oriented System), MASIF (Mobile Agents Standard Interface) и FIPA (IEEE Foundation for Intelligent Physical Agents) [pic] Сл 4.1.1 Генерален модел на една агентска платформа 4.2. Примена на карактеристиките на агентите во WSN Следните карактеристики на агентите можат да се применат во сензорските мрежи: • Реактивност: Агентите се способни за детектирање и реагирање на различни стимули. Тие се способни да ги процесираат податоците што ги добиваат од сензорите и да соодветно да одговорат. • Способност за асинхрона работа: Агентите започнуваат да работаат кога еден или повеќе сензори детектираат одреден настан, како на пример натрапник во мрежата користејќи сигурносни мерки во својот опсег. • Автономност: Тие имаат одреден тип на контрола над своите активности. Детектираат проблем, одлучуваат каква активност да се преземе и ги решаваат конфликтите. Ова е многу важно кај WSN мрежите бидејќи ако еден елемент откаже, агентот треба да е во можност да ја исполне својата цел без овој елемент. • Ориентираност кон целта: Агентите се способни за справување со задачи за достигнување на нивната цел. Ова е логично со оглед на фактот дека тие треба да се справат со информациите добиени од сензорите како би ја извршиле својата цел. • Способност за комуникација: Агентите мора да се способни за интеракција со други агенти, сензори, па дури и луѓе бидејќи нивната цел е да обезбедат информации или решенија на еден или повеќе стимули. • Соработка: Агентите мора да се способни за извршување на своите задачи со помош на други агенти со кои мора да соработуваат. Всушност, тие мора да добијат, обезбедат информации од другите елементи, формирајќи на тој начин дистрибуирана околина со цел решавање на одредени проблеми. На кратко, применливоста на агентите во WSN мрежите доаѓа од сличноста на нивните цели. Агентите се ентитети со одредена автономност кои реагираат на одредени настани и се обидуваат да постигнат одредена цел. Сето ова е многу слично на она што се случува но некои апликации за сензорски мрежи. 5. Архитектура на софтвер за WSN Најчесто при дизајнирањето на софтвер за WSN се користи посредување на софтверски слој – middleware над оперативниот систем. Како што претходно беше појаснато, тој служи за обезбедување на апстракција и сериси за апликациите. Кај ваквиот вид на архитектура, сите компоненти се претставени како блокови. На сл 5.1 е претставенен циклусот на развоја на софтвер за ваквите видови на мрежи. [pic] Сл 5.1 Циклус на дизајн на софтвер за јазли-сензори Додека структурата на софтверот кој се извршува е претставена на следната слика. [pic] Сл 5.2 Структура на апликација која се извршува на јазол-сензор Кај WSN мрежите различни типови на аплокации и софрвер коегзистираат на различни хардверски платформи како јазли-сензори, јазли-серверии и клиентски опреми. [pic] Сл 5.3 Архитектура на софтвер за WSN Затоа, како што е прикажано на сл 5.3, софтверот е поделен на три слоеви и тоа: • Јазол слојот е составен од јазлите со нивните сензори. Во овој слој софтверот треба да се состои од “лесен” (во однос на меморија) оперативен систем кој ќе се извршува на јазлите и соодветна апликација која би извршувала некаков сервис, како на пример мониторинг на промени во животната средина или пак следење на некакви нарушувања. Овие апликации обично се тесно хардверски поврзани, односно развиени за одреден тип на хардвер, а програмскиот јазик кој се користи за нивен развој мора да се вклопи во високите барањата кои ги поставуваат уредите. • Сервер слојот, од WSN мрежата добива информации користејќи соодветни протоколи, а потоа тие информации ги складира во база на податоци. Тој обично нуди и сервиси, најчесто користејќи го TCP/IP протоколот, со цел да им се овозможи на клиентите пристап до складираните информации. Во овој случај изборот на програмските јазици треба да е според нивната портабилност, односно можноста да се извршуваат на машини со различни карактеристики, оперативни системи и различни платформи. • Клиентскиот слој вклучува графички кориснички интерфејс кој овозможува информациите, топологија и состојбата на WSN и нејзиното менаџирање да бидат видливи. Со тоа овој софтвер на корисникот му обезбедува информации потребни за менаџирање на WSN, интерпретација на големи количества на генерирани информации и следење на целокупната состојба на мрежата. Од друга страна пак, податоците кои јазолот-сензор ги мери и испраќа до серверот не мора да се во сирова форма. Може да се постават брокери, сервиси или посредувачки ентитети за процесирање, кои би ги филтрирале информациите од јазлите и би нуделе сервиси за повисоките слоеви. Брокерите концепциски би биле поставени помеѓу јазол слојот и сервер слојот, иако физички би биле поставени на самите јазли. 5.1. Софтвер кај јазлите-сензори Кога се дизајнира middleware-от главна карактеристика е неговата општост. Апликациите пак, кои ќе се инсталираат на јазлите-сензори се индивидуални скоро за секоја WSN мрежа бидејќи зависат од полето на примена на мрежата. Од друга страна тука е и оперативниот систем на јазлите-сензори. Оперативниот систем е клуч за сите изведувања во дистрибуирана околина, па така и кај безжичните сензорски мрежи. Некои особини на оперативните системи како: заштита, вируелна меморија, распеределување на ресурси итн, значително ја подобруваат сигурностна на WSN мрежата, а исто така и го олеснуваат развојот на комплексни WSN апикации. Неколку оперативните системи се развиени за сензор-мрежни апликации: TinyOS, MagnetOS, SOS, t-kernel, Contiki, eCos, Cormos, MantisOS. 6. TinyOS TinyOS е оперативен систем за проширени безжични мрежни системи, со акцент на реагирање на надворешни настани и исклучително ниско моќни операции. Наместо монолитен оперативен систем, TinyOS е множество на модули кои се импортираат во апликација во зависност од потребата. Еден значаен предизвик во развојот на TinyOS е дизајнирање и имплементирање на флексибилни, повеќекратно употрбливи компоненти. TinyOS - системот, библиотеките и апликациите се напишани во NesC, релативно нов програмски јазик за програмирање на структурирани апликации кои во основа се сосојат од множество на независни компоненти. Исто како и TinyOS, и програмскиот јазик NesC е првенствено е наменет за проширливи системи како што се сензорските мрежи. Синтаксата на NesC е многу слична на добро познатиот програмски јазик C, меѓутоа поддржува конкурентност, а поседува и механизми за структурирање, именување, како и поврзување на софтверски компоненти во робусни проширливи мрежни системи. Основната цел е да им се овозможи на дизајнерите на апликации да создадат компоненти кои лесно можат да се искомпонираат во комплетен, конкурентен систем, кој сепак лесно може да се провери во време на компајлирање. [pic] Сл 6.1 Најпопуларни TinyOS платформи Важните карактеристики кои ги поседува NesC се задржани и кај TinyOS. Прво, апликациите во NesC се изградени од компоненти, со добро дефинирани двонасочни интерфејси. Второ, NesC го дефинира моделот на конкурентност, што подразбира работа со таскови (задачи) и хендлери за хардверски иницирани настани. За разлика од програмскиот јазик C, во NesC компонентите можат да референцираат само локални променливи, меѓутоа може да декларира дека користи функција која е дефинирана од друга компонента. 6.1. Компоненти Компонентите дефинираат два опсега: • Спецификација (потпис): Една апликација во NesC ја сочинуваат од една или повеќе компоненти кои заедно формираат извршна програма. Една компонента може да се разгледува како црна кутија со познати влезни и излезни функции, наречени интерфејси. Интерфејсите се единствените точки за пристап кон една компонента, а со самото тоа што имаат влезни и излезни функции, тие се двонасочни. • Имплементација: Постојат два типови на компоненти во NesC: модули и конфигурации. Конфигурациите се парчиња код чија задача е да ги поврзат компонентите, додека модулите се основните блокови за градење на една TinyOS програма. Тие се всушност имплеметациите на компонентите. Го претставуваат кодот на апликацијата и користат и обезбедуваат повеќе интерфејси. Секоја компонента има спецификација во која се декларираат функциите кои компонентата ги нуди (имплементира) и функциите кои ги користи, односно повикува. 6.2. Модули Модулите, како што е прикажано во погоренаведениот код, го содржат извршниот код на апликацијата. Секоја компонента после спецификацијата содржи блок за имплементација. Кај модулите, импленетацијата е слична на објект: има променливи и функции. Модулите мора да ја имплементираат секоја команда од интерфејсите кои ги нудат и секој настан од интерфејсите кои ги повикува. Иако модулите имаат сличности со објектите, тие и битно се разликуваат. Прво, тие се единки, не може да се инстанцираат. Со ова се врши сокривање дали една компонента е хардвер или софтвер. Како што не може да се прават истанци од регистри или излезни пинови, така не може и со софтверот, освен кај генеричките модули. Исто така во модулите можат да се декларираат променливи во кои се чува одредена состојба. Било која состојба на компонентата е приватна, до неа се нема пристап. 6.3. Интерфејси, команди и настани Во пракса, компонентите многу ретко декларираат индивидуални функции. Наместо тоа, во NesC постојат интерфејси кои се колекција од поврзани функции. Најчесто спецификациите на компонентите се состојат од интерфејси. Интерфејсите специфицираат множество на именувани функции, наречени команди, кои треба се имплементираат кај интерфејсот на провајдерот и множество на функции, наречени настани, кои се имплементираат на интерфејсот на корисникот. За една компонента да повика команда од некој интерфејс, мора да ги имплементира настаните од тој интерфејс. Интерфејсите се специцифицираат на следниот начин: Секој тип интерфејс содржи одреден опсег на листа на декларации, во кој се наведуваат сите потребни декларации. Така, тука се наведуваат и командите и настаните. Еден пример на интерфејс е следниот: Овој интерфејс SendMsg мора да ја имплементира командата send, додека корисникот мора да го имплементира настанот sendDone. За повикување на команда од даден интерфејс се користи резервираниот збор “call”, додека за повикување на настан се користи “signal”. 6.4. Внатрешни функции Командите и настаните се единствениот начин на кој една функција може да се направи достапна за други компоненти. Постојат ситуации кога на една компонента и се потребни приватни функции за своја интерна употреба. Во таквите случаи, се креираат стандардни C функции, кои други компоненти не можат директно да ги повикуваат. Таквите функции исто така можат да повикуваат команди и/или настани. Пример за внатершна функицја може да се види од следниот код: split-phase операциите Исто како и во програмскиот јазик C, за повикување на внатрешна функција не се потребни резервираните зборови “call” или “signal”. 6.5. Split-Phase операции Бидејќи сензор-јазлите имаат широк спектар на хардверски можности, една од целите на TinyOS е да се има флексибилна хардвер/софтвер граница. Многу хардверски операции се извршуваат подолго време (иако тоа се брои во милисекунди). Затоа наместо системот да се блокира, се до целосното извршување на операцијата, се оди на користење на split-phase операции. Конкретен пример за split-phase операција е читањето на семплиран податок. Софтверот запишува во конфигурациските регистри да се започне читање. Кога читањето ќе се изврши, хардверот издава прекин и софтверот чита податочните регистри. Со други зборови, кај split-phase операциите комплетирањето на барањето (request) е повратниот повик (callback). [pic] Сл 6.5.1 Типична split-phase операција Во nesC интерфејсите се поврзуваат за време на компајлирањето, за разлика од C каде се врши поврзувањето за време на извршување со користење на покажувачи. Оваа особина на nesC е многу битна за опимирањето на апликациите бидејќи однапред се знае кои функции каде се повикани, со што се избегнуваат блокирачките повици. Наместо тоа се користат split-phase операциите со што се дели (split) повикот на барање и комплетирање при извршувањето. Разликата во блокирачки и поделени операции може да се види од следниот код: 6.6. Задачи (Tasks) Ако при програмирањето се работи со деливи операции (split-phase), тогаш при издавање на барањето треба повратната страна да одговори. Ова може да доведе до јамки при многу фреквентни повици. Затоа, во TinyOS се користат задачи (tasks). Задачите се всушност одложени повици кон дадена процедура. Модулот може да објави задача до распоредувачот на TinyOS. Подоцна, во даден момент распоредувачот ќе ја изврши задачата. Поради тоа што задачата не се извршува веднаш, нема повратна вреност. Исто така бидејќи задачата се извршува во рамките на опсегот на именување на компонента, нема ниту параметри. Во случај да треба се пренесат одредени параметри, тие се зачувуваат во компонентата. Една компонента може да објави задача користејќи го резервираниот збор post после што се пишува името на задачата. Важна карактеристика е тоа што во одредено време тече една задача, т.е. TinyOS никогаш не прекинува една задача за да започне извршување на друга. Оваа карактреистика е важна од аспект што задачите не се мешаат помеѓу себе и се избегнува добивањето на недоследни податоци кои задачите треба да ги разменуваат меѓу себе. Ова исто значи и дека задачите треба да бидат разумно долги за извршување. Ако една компонента има релативно долга пресметка за извршување, истата трена да за декомпонира на повеќе помали задачи. 6.7. Модел на конкурентност Со помош на задачите на софтверските компоненти им се овозможува емулирањето на двофазното однесување на хардверот. Ова е само една мала корист при користење на задачите. Многу поважна улога имаат со тоа што со нивна помош се обезбедуваат механизми за менаџирање на приоритетите на системот. Треба да се нагласи дека еден стандарден TinyOS распоредувач важи FIFO моделот на извршување на задачите. При тоа може да се каже дека задачите се атомични во однос една на друга, меѓутоа не се во однос на справувачите на прекини (interrupt handler). Функциите кои асинхроно се извршуваат во однос на задачите се означуваат со резервираниот збор async. Асинхрона функција не може да повика команда или настан кои исто така не се асинхрони. Справувачите на прекини работаат асинхроно и соодветно во нивниот повикувачки граф не може да се најде синхрона функција. Еден и единствен начин за извршување на синхрона функција е објавувањето на задача. Односно, објавувањето на задача е асинхрона операција, додека извршувањето на задачата е синхрона операција. Најлесно би било кога сите функции би биле асинхрони, меѓутоа така програмата би ја довеле во состојба на трка по ресурси, односно често променување на состојбата за системот. За да се избегне сето тоа, кодот би требало да е составен синхнони функции, додека асинхроните трена да се користат во некои исклучителни случаи кога тајмингот на извршување е многу важен. Еден од начините со кои може да се зачува точна состојбата на систенот е користење на атомични блокови на код. Со овој блок се обезбедува атонично читање и променување на променливите. При креирањето на атомични блокови трена да се има во предвид: • Атомичниот код означува одреден вид на ексклузивност, односно попречување на прекини, а со самото тоа трошење на процесорот. • Бидејќи го “трошат” процесорот, треба да се минимизира бројот на атомични блокови. • Атомичните блокови треба да се што пократки за да може одложувањето на прекините да биде помало и да се подобри конкурентноста на ситемот. 6.8. Правила за именување |Тип на идентификатор |Правила на именување |Пример | |Интерфејси |Интерфејсите треба да бидат глаголи или именки, |ADC | | |напишани така што правта букава од секој внатрешен|Range | | |збор да е голема. |SendMsg | | | |BombillaLocks | |Компоненти |Компонентите треба да се именки, напишани така што|Counter | | |правта букава од секој внатрешен збор да е голема.|IntToRfm | | |Постојат две различни именувања на компоненти: |IntToRfmM | | |Едните завршуваат со големата буква C, а другите |TimerC | | |со M. Ова се користи за да се разликуваат |TimerM | | |интерфејсите од компонентите и конфигурациите од |UARTM | | |модулите. | | | |Големата буква C доаѓа од Component. Се користи за| | | |да се направи разлика помеѓу интерфејсот (Timer) и| | | |компонентата која го обезбедува тој интерфејс | | | |(TimerC). | | | |Големата буква M доаѓа од Module. | | |Датотеки |Имињата на датотеките треба да бидат описни при |Counter.nc | | |што би било јасно за што користи датотеката; сите |IntToRfm.nc | | |nesC датотеки имаат суфикс ".nc". |IntToRfmM.nc | | | |TimerC.nc | | | |TimerM.nc | | | |UARTM.nc | |Апликации |Апликациите треба да го носат името на |CntToRfm | | |компонентата што се наоѓа на највисокото ниво. Ако|Chirp | | |апликацијата тестира некој дел од TinyOS тогаш |DemoTracking | | |треба соодветно да се именува како “Test”. Ако е |TestTinyAlloc | | |дел од некаква демонстрација треба да е “Demo” |VerifyMicaHW | | |итн. |TestTimer | |Команди, Настани и Задачи |Командите, настаните и задачите треба да се |sendMsg | | |именки, при што првата буква треба да е мала, а |output | | |секој внатрешен зброр од променливата треба да |outputComplete | | |започнува со голема буква. Ако парот команда / |put | | |настан формираат split-phase операција, името на |putDone | | |настанот треба да е името командата суфиксирано со|fired | | |"Done" или "Complete". Командите кои директно |TOSH_SET_RED_LED_PIN(); | | |пристапуваат до хардверот треба да носaт префикс | | | |"TOSH_". | | |Променливи |Променливите треба да се именки, при што првата |bool state | | |буква треба да е мала, а секој внатрешен зброр од |uint16_t lastCount | | |променливата треба да започнува со голема буква. |uint16_t counter | | |Треба да се описни, освен времените променливи и |result_t writeResult | | |променливите кои се користат во циклусите. |uint8_t noHeader | |Константи |Константите треба да бидат со големи букви, при |TOS_UART_ADDR | | |што одделните зборови да се поврзани со долна |TOS_BCAST_ADDR | | |црта. |TOS_LOCAL_GROUP | | | |TOSH_S1PS | 7. TinyDB TinyDB е систем за процесирање на прашалници преку кои се извлекуваат и обработуваат податоци од мрежата на јазлите-сензори. Ако TinyOS е дијалект на програмскиот јазик C, тогаш може да се каже дека TinyDB е дијалект, односно одередено проширување на SQL. Преку едноставниот интерфејс што го обезбедува може да се специфицираат податоците кои треба да се извлечат, да се проследат одредени параметри за филтрирање на истите, како и де се постави стапка за ажурирање на податоците. Кога ќе се зададе прашалник за добивање податоци кои се домен на истражување, TinyDB ги прибира тие податоци од јазлите-сензори, ги филтрира, ги спојува и ги рутира (користејќи специјални алгоритми) до локалниот компјутер. Поважни карактеристики на TinyDB се: • Менаџирање на metadata (податоци за податоците): TinyDB обезбедува каталог на метадата податоци во кој се наведни видовите на читања на сензорите од мрежата. • Прашалници од високо ниво: TinyDB користи декларативен јазик за прашалници кој дозволува да се опишат податоците кои треба да се добијат, без да се обрнува внимание на тоа како податоците ќе се добијат. Ова овозможува полесно пишување на апликации и еден вид на гаранција дека апликацијата ќе продолжи ефикасно да работи и при промени во мрежата. • Мрежна топологија: TinyDB ја менаџира радио мрежата врз која се наоѓа преку следење на соседи, одржување на рутирачки табели, и обезбедува секој сезнор во мрежата да може ефикасно и (релативно) сигуно да ги испрати податоците до корисникот. • Повеќе истовремени прашалници: TinyDB овозможува повеќе прашалници во истовремено да се извршуваат над исто множество на сензори. Прашалниците можат да имаат различен период на семплирање и пристап до различен тип на читања, при што TinyDB ефикасно ја дели работата помеѓу нив. • Инкрементално инсталирање со користење на делење на прашалници: За да се прошири TinyDB мрежата доволно е се сними стандардниот TinyDB код на новите сензори, понатаму TinyDB мрежата се задолжена за останатото. TinyDB јазлите ги делат прашалниците помеѓу себе: кога еден јазол ќе “слушне” во мрежата прашалник за пребарување кој не се извршува кај него, автоматски од испраќачот на тие податоци бара копија од прашалникот и започнува да го извршува. Со други зборови на новите јазли освен основната инсталација не се потребни додатни конфигурирања или програмирање. TinyDB системот може генерално да се подели на два дела: 1. Софтвер за сензорската мрежа: Овој дел е срцето на ситемот иако голем дел од корисниците немаат потреба од промена на овој код. Се извршува на секој сензор од мрежата и е составен од неколку делови: o Менаџер на сензори: Каталог кој е одговорен за следење на множеството на атрибути, типовите на читања кои се вршат од сензорите (како светлина, звук,...), нивните особини (ИД на сензорот). Генерално, оваа листа е различна за секој сензор: мрежите можат да бидат составени од хетерогена колекција на уреди, и соодветно може да регистрира различни особини. o Процесор на прашалници: Главна компонента на TinyDB е мал процесор за прашалници. Овој процесот го користи каталогот за превземање на вредностите од локалните атрибути, ги прима читањата од соседните сезнори преку радио врска, ги соединува и комбинира овие вредности, ги филтрира несоодветните податоци и ги препраќа понатаму. o Менаџер на меморијата: TinyDB го проширува TinyOS со мал, динамички менаџер на меморијата. o Менаџер на топологијата на мрежата: TinyDB управува со поврзувањето на сензорите во мрежата се со цел ефикасно рутирање на податоците и резултатите низ истата. 2. Java-базиран клиентски интерфејс: Мрежата на TinyDB сензори преку специјален кориснички интерфејс се поврзува со персоналните компјутери. Тој интерфејс се состоиод множество на Java класи и апликации. Некои од поважните класи се следните: o Класа за мрежен интерфејс преку која се вметнуваат прашалниците во мрежата и се читаат резултатите. o Класи за креирање и пренесување на прашалници. o Класа која ги прима и парсира резултатите од прашалниците. o Класа за извлекување на информации за атрибутите и способностите на уредите. o GUI (графички кориснички интерфејс) за креирање на прашалници. o GUI за прикажување на резултати од индивидуалните сензори. o GUI за визуелизација на топологијата на динамичката мрежа. o Апликација која како интерфејс користи прaшалници кои се однесуваат на сензорската мрежа. TinyDB е декларативен јазик од високо ниво кој се користи за специфицирање на прашалници. Декларативните јазици имаат две предности. Првата е што лесно се учат, читливи се и се разбираат. Втората е тоа што на системот врз кои се поставени му овозможуваат различно да ги извршува прашалниците, без при тоа тие да се менуваат. Ова е важна карактеристика за една променлива категорија како што се безжичните сензорски мрежи. Кај TinyDB начинот на извршување на прашалниците се менува на скоро на секое извршување, дури и за време на извршување. Користењето на TinyDB имплицитно се сведува на една, бесконечно долга логичка табела наречена sensors. Во оваа табела за секој атрибут од каталогот е резервирана по една колона. Исто така, концепциски, содржи еден ред за секое читање, генерирано од било кој сензор, па така табелата може да се разгледува како бескрајно долг стриминг на податоци. Ако одреден сензор не е во состојба да ги генерира сите атрибути, односно не поседува такви можности, тогаш во тие колони ќе се запишува вреност NULL. Јазикот кој TinyDB го користи за пребарување и прашалници е базиран на SQL и се нарекува TinySQL. Коко и во SQL, прашалниците во TinyDB, се состојат од множество на атрибути кои се селектираат (пример светлина, температура, ...), множество на изрази кои формираат излезни колони, множество на предикати за филтрирање на редици и опционално израз за групирање преку кој би се добиле сумирачки резултати. TinyDB вклучува и механизам за едноставни тригери или прашалници кои извршуваат одредена команда при појавување на одреден резултат. Пример треба да се вкучи аларм кога температурата околу сензорот надминува некој праг. Со TinySQL тригер то асе постигнува на следниот начин: Командата SetSnd го стартува звукот, а вредноста 512 ја означува должината на звукот од 512 мс. Од примерот е уочлива сличноста со стандардниот SQL јазик. Меѓутоа постојат и некои специфични синтакси кои се карактеристични за сензорите. Сите TinySQL прашалници ја имаат следната форма: Клаузулите SELECT, FROM, WHERE, GROUP BY и HAVING се многу слични со функционалностите од стандардниот SQL. Така, и аритметичките изрази се поддржани за сите овие клаузули. Исто така, како и кај SQL-от, клаузулата GROUP BY е опционална, а во случај да е вклучена, тогаш е опционална клаузулата HAVING. Освен очигледната сличност, постојат и разлики помеѓу стандардниот SQL и TinySQL. Карактреристики кои го одвојуваат TinySQL се следните: • FROM клаузулата вклучува само една табела, наречена sensors и е опционална. • WHERE и HAVING клаузулите можат да содржат само едноставни конјукции на аритметички оператори, па така логичките опратори OR и NOT не се поддржани. Исто така не се поддржани ниту споредувања на текстови (LIKE и SIMILAR). • Нема можност за подселеки (подпрашалници). • Сеуште не постои можност за преименување на колоните (користење на конструкторот AS) • Аритметичките опрации се сведуваат на колона оп константа, каде што оп може да е една од следните опрации: +, -, *, / Од друга страна постојат одредени механизми кои се поврани со спецификата на сензорите. Тоа се клаузулите TRIGGER ACTION и EPOCH DURATION. Кај првата клаузула, командата која се користи мора да е регистрирана, а како параметар, кој е опционален, може да се пренесе било каква целобројна вредност. Времето помеѓу две епохи се наведува во EPOCH DURATION клаузулата. Постојат и специјални прашалници кои се стартуваат при појава на некој означен настан од ниско ниво. Пример за таков настан е кога сензорот ќе отчита вредност која е над или под некој означен праг. Потребни се два чекори при креирањето на ваквите прашалници: 1. Дефинирање на настанот во оперативниот систем 2. Регистрирање на прашалникот во TinyDB Синтаксата на ваквите прашалници е следна: Каде што event е името на настанот со чие што појавување би се извршил прашалникот. 8. Заклучок Софтверот за WSN мрежите е во процес голем развој. Не постои дел ов ваквите мрежи кој може да се поединечно да се равива или дизјанира, туку системот треба да се разгледува како целина. Сепак, поголемиот број на проекти кои се фокусирани кон развој на софтвер за WSN, системски или апликативен, може да се каже дека сеуште се во рана фаза на развој. Поголемиот број на софтверски технологии наведени претходно се само пионери во развојот на алгоритми, компоненти и протоколски решенија за WSN мрежите. Кога една апликација се извршува на сензор-јазлите неколку фактори треба да се земат во предвид. Тоа се складирањето на податоци, пресметувачката моќ и комуникацијата. Овие фактори треба добро да се избалансирани и во поглед на потрошувачката на енергија. Како одговор на ова се јавува middleware кој со својата робустност би можел добро да ги менаџира овие потреби. Од не така големиот број софтверски решенија за безжичните сензорски мрежи како најраспоространет се јавува TinyOS – оперативен систем кој со својата модуларна природа е доста прилагодлив на различни потреби. Од друга страна како тандем на TinyOS во однос на менаџирање и складирање на податоци, се јавува TinyDB. Истиот како систем за процесирање на прашалници, многу лесно, ефикасно и исцрпно ги прави податоците од сензор-јазлите достапни за првична и понатамошна обработка на податоци. 9. Користена литература 1. Problem Solving for Wireless Sensor Networks - Ana-Beleґn Garcıґa-Hernando, Joseґ-Fernaґn, Martıґnez-Ortega, Juan-Manuel, Loґ pez-Navarro, Aggeliki Prayati, Luis Redondo-Loґ pez, MsC 2. Wireless Sensor Networks Technology, Protocols, and Applications - Kazem Sohraby, Daniel Minoli, Taieb Znati 3. TinyOS Programming - Philip Levis 4. TinyDB: In-Network Query Processing in TinyOS - Sam Madden, Joe Hellerstein, Wei Hong 5. Mobile Agent Based Wireless Sensor Networks - Min Chen, Taekyoung Kwon, Yong Yuan, Victor C.M. Leung 6. http://docs.tinyos.net/ 7. http://www.cs.virginia.edu/~stankovic/psfiles/r10how.pdf 8. http://www.ventocom.com/fileadmin/user_upload/WSN%20Requirements.pdf 9. http://www.tinyos.net/tinyos-1.x/doc/tutorial/ 10. http://www.ece.rochester.edu/~merlin/academic/TinyOSTutorial.pdf 11. http://www.cse.wustl.edu/~lu/cse521s/Slides/tutorial.pdf 12. http://nescc.sourceforge.net/papers/nesc-ref.pdf ----------------------- Blink.nc configuration BlinkC { } Implementation { components MainC, BlinkC, LedsC; components new TimerMillic() as Timer0; components new TimerMillic() as Timer0; components new TimerMillic() as Timer0; BlinkC ->MainC.Boot; BlinkC.Timer0 -> Timer0; BlinkC.Timer1 -> Timer1; BlinkC.Timer2 -> Timer2; BlinkC.Leds -> LedsC; } При што “->” ја означува поврзаноста на еден интерфејс со друг BlinkM.nc module BilnkC { uses interface Timer as Timer0; uses interface Timer as Timer1; uses interface Timer as Timer2; uses interface Leds; uses interface Boot; } Implementation { event void Boot.booted() { call Timer0.startPeriodic(250); call Timer1.startPeriodic(500); call Timer1.startPeriodic(1000); } event void Timer0.fired(){ call Leds.led0Toggle(); } event void Timer1.fired(){ call Leds.led1Toggle(); } event void Timer2.fired() { call Leds.led2Toggle(); } } Timer.nc: interface Timer { // basic interface command void startPeriodic( uint32_t dt ); command void startOneShot( uint32_t dt ); command void stop(); event void fired(); } SendMsg.nc: interface SendMsg { command result_t send(uint16_t address, uint8_t length, TOS_MsgPtr msg); event result_t sendDone(TOS_MsgPtr msg, result_t success); } module BlinkC { uses interface Timer as Timer0; uses interface Timer as Timer1; uses interface Timer as Timer2; uses interface Leds; uses interface Boot; } implementation { void startTimers() { call Timer0.startPeriodic( 250 ); call Timer1.startPeriodic( 500 ); call Timer2.startPeriodic( 1000 ); } event void Boot.booted() { startTimers(); } . . . } Блокирачка операција if (send() == SUCCESS) { sendCount++; } Split-phase операција // start phase send(); //completion phase void sendDone(error_t err) { if (err == SUCCESS) { sendCount++; } } command bool Increment () { atomic { a++; b = a + 1; } } SELECT temp FROM sensors WHERE temp > thresh TRIGGER ACTION SetSnd(512) EPOCH DURATION 512 SELECT select-list [FROM sensors] WHERE where-clause [GROUP BY gb-list [HAVING having-list]] [TRIGGER ACTION command-name[(param)]] [EPOCH DURATION integer] module { …..//интерфејси кои ги нуди и повикува … } implementation{ …..//извршен код … } ON event: SELECT ... configuration { …..// интерфејси кои ги нуди и повикува … } implementation{ …..//поврзување на компоненти … } интерфејс: interface идентификатор { листа на декларации } event void Boot.booted() { startTimers(); } ... }