docPraktyczne podejście do problemu Home Automation
download 
Reklamacja Transkrypt
Praktyczne podejście do problemu Home Automation
Sławomir Jaros praca dyplomowa magisterska ( inżynierska ) Praktyczne podejście do problemu Home Automation – Zastosowanie jako urządzeń sterujących popularnych telefonów wyposażonych w OS Symbian. Promotor: Dr inż. Michał Morawski Dyplomant: Sławomir Jaros nr albumu 116696 Łódź, 17.09.2007 r. 1 SPIS TREŚCI Wykaz skrótów ..................................................................................................................4 Wykaz rysunków ...............................................................................................................6 Wykaz tabel.......................................................................................................................7 1 2 3 4 5 WSTĘP ......................................................................................................................8 1.1 Idea Inteligentnego Budynku ..............................................................................8 1.2 Definicja Inteligentnego Budynku ......................................................................9 1.3 Historia powstania i ewaluacja Inteligentnego Budynku ...................................10 Cel i zakres pracy.....................................................................................................11 Inteligentny Budynek ...............................................................................................12 3.1 Inteligentny Budynek – zastosowanie ...............................................................12 3.2 Sieci domowe w kontekście Inteligentnego Budynku........................................15 3.3 Podział sieci domowych ze względy na użyte medium. ....................................16 3.3.1 Sieci z nowym okablowaniem...................................................................16 3.3.2 Sieci bez nowego okablowania .................................................................18 3.3.3 Sieci bezprzewodowe................................................................................23 3.3.3.1 IrDA .....................................................................................................23 3.3.3.2 HomeRF ...............................................................................................27 3.3.3.3 ZigBee (IEEE 802.15.4)........................................................................28 3.3.3.4 Bluetooth ..............................................................................................31 Symbian – system operacyjny ..................................................................................37 4.1 Informacja ogólne.............................................................................................37 4.2 Dlaczego Symbian? ..........................................................................................38 4.3 Interfejsy w Symbianie .....................................................................................38 4.4 SDK i dostępne IDE pod Symbiana ..................................................................39 4.5 Podstawy Symbiana (różnice pomiędzy Symbianem a C++).............................40 4.5.1 Podstawowe typy danych..........................................................................40 4.5.2 Nazewnictwo klas.....................................................................................41 4.5.3 Łańcuchy tekstowe i deskryptory ..............................................................42 4.5.4 Mechanizm opuszczeń (Leaves)................................................................44 Projekt .....................................................................................................................45 5.1 Idea projektu ....................................................................................................45 5.2 Budowa projektu ..............................................................................................46 5.2.1 Aplikacja na telefon komórkowy ..............................................................47 5.2.1.1 Budowa i elementy składające się na aplikację......................................47 5.2.1.2 Struktura katalogów projektu ................................................................48 5.2.1.3 Podział aplikacji na podstawowe pliki...................................................49 5.2.1.4 Rodzaje plików w projekcie ..................................................................50 5.2.1.5 System identyfikatorów UID.................................................................51 5.2.1.6 Zasada działania aplikacji .....................................................................52 5.2.1.7 Bezpieczeństwo ....................................................................................55 5.2.1.8 Identyfikator UUID...............................................................................56 5.2.1.9 Protokoły wyszukiwania usług..............................................................57 5.2.2 Aplikacja na PC ........................................................................................59 5.2.3 Aplikacja na Game Board .........................................................................61 5.2.4 Profile zastosowań Bluetooth....................................................................63 5.2.5 Instrukcja obsługi......................................................................................65 5.2.5.1 Wymagania sprzętowe ..........................................................................65 2 5.2.5.2 Instalacja...............................................................................................65 5.2.5.3 Opis szczegółowy .................................................................................66 5.3 Standardy Bluetooth na komputery PC ............................................................67 5.4 Dlaczego C++ ..................................................................................................68 6 Dalsze kierunki rozwoju...........................................................................................68 7 Wnioski i podsumowanie .........................................................................................70 BIBLIOGRAFIA .............................................................................................................72 Dodatek A .......................................................................................................................75 Zawartość nośnika CD-ROM .......................................................................................75 Dodatek B........................................................................................................................76 Raport skrócony wygenerowany przez System Antyplagiatowy Plagiat.pl, za pomocą witryny http://plagiat.pl................................................................................................76 3 Wykaz skrótów HVAC - heating, ventilation and air conditioning EIBG - European Intelligent Building Group IrDA - Infrared Data Association VFIR - Very Fast Infrared FIR - Fast Infrared SIR - Serial Infrared AIr - Advanced Infrared. HomeRF - Home Radio Frequency HomePNA - Home PhoneLine Alliance CEBus - Customer Electronic Bus RF - Radio Frequency PLC - PowerLine Communication EIB - European Installation Bus EIBA - European Installation BUS Association CRC - Cyclic Redundancy Check IrLAP - Infrared Link Access Protocol IrLMP - Infrared Link Management Protocol IAS - Intention Access Service IrOBEX - Object Exchange Protocol IrLAN - Local Area Network IrMC - Infrared Mobile Communications IrTran-P - Infrared Transfer Picture SWAP - Shared Wireless Access Protocol CSMA/CA - Carrier Sense Multiple Access/Collision Avoidance PDA - Personal Digital Assistant CSMA/CA - Carrier Sense Multiple Access With Collision Avoidance MAC - Medium Access Control TDMA - Time Division Multiple Access ADS - Asynchronous Data Service PADS - Priority Asynchronous Data Service DSSS - Direct Sequence Spread Spectrum SSCS - Service-Specific Convergence Sublayer 4 LLC - Link Layer Control LR - WPAN - Low-Rate Wireless Personal Area Networks IG - Special Interest Group ISM - Industrial Scientific Medical TDD - Time Division Duplex CRC - Cyclic Redundancy Check HCI - Host Control Interface TCS - Telephony Control Specification RFCOMM – Serial Port Emulation SDP - Service Discovery Protocol IDE - Integrated Development Environment SDK - Software Development Kit AIF - Application Information File MIME - Multipurpose Internet Mail Extension MBM - Multi Bitmap UID - Unique Identification Number URL - Uniform Resource Locator UUID - Universally Unique Identifier SLM - Salutation Manager SLP2 - Service Location Protocol, Version 2 SSDP - Simple Service Discovery Protocol PDP - Pervasive Discovery Protocol SSDS - Secure Service Discovery Service PDU - Protocol Data Unit SDDB - Service Discovery Database SPP - Serial Port Profile GCC - GNU Compiler Collection PIN - Personal Identification Number DAC - Device Access Code GOEP - Generic Object Exchange Profile FTP - File Transfer Profile OPP - Object Push Profile SP - Synchronization Profile 5 Wykaz rysunków 1. Schemat ideowy Inteligentnego Budynku 2 Schemat przedstawiający podsystemy Inteligentnego Budynku 3. Wykaz technologii dla sieci domowych 4. Przekrój przewodu komunikacyjnego w EIB 5.Możliwe topologie w EIB 6. Idea sieci HomePNA 7. Prędkości transmisji w porównaniu z odległościami w IrDA i Bluetooth 8. Stos protokołów IrDA 9. Specyfikacja HomeRF 10. Ulokowanie kanałów standardu 802.15.4. 11. Stos protokołów ZigBee 12. Topologie sieci ZigBee 13. Rozmieszczenie kanałów w systemie Bluetooth 14. Pikosieć: Jedno urządzenie Master (M) i cztery urządzenia Slave (S) 15. Dwie pikosieci mogą występować na jednym obszarze, nie zakłócając się nawzajem. 16. Pikosieci mogą tworzyć sieci rozproszone (scatternet). 17. Stos protokołów Bluetooth 18. Typy deskryptorów w Symbianie 19. Idea projektu 20. Budowa typowej aplikacji na Symbian OS 21. Proces powstawania pliku SIS 22. Wymiana klucza 23. Protokoły uczestniczące w transakcji SDP 24. LPC2104 Color LCD Game Board 25. Wariant rozbudowy projektu 6 Wykaz tabel Tab.1 Podstawowe parametry standardu ZigBee Tab.2 Przepustowość kanałów transmisyjnych Tab.3. Środowiska programistyczne pod Symbian OS (IDE) Tab.4. Podstawowe typy danych w systemie Symbian 7 1 WSTĘP 1.1 Idea Inteligentnego Budynku Coraz częściej usłyszeć można o zastosowaniach nowoczesnej technologii w różnych dziedzinach przemysłu. Bardzo szybko rozwijająca się technika pozwala zastosować innowacyjne technologie w budynkach, w których, na co dzień przebywamy. Poprawia to komfort codziennego życia, nasze bezpieczeństwo a także daje to oszczędność w eksploatacji. Jeszcze kilkanaście lat temu instalacja pozwalająca na inteligentne sterowanie urządzeniami znajdującymi się w budynku była mało realna. Obecnie tradycyjne rozwiązania powoli zostają wypychane przez standardy umożliwiające inteligentne sterowanie budynkiem (rozdz. 2). Wyobraźmy sobie sytuację, jak po trudach codziennej pracy wracamy do domu. Po wejściu, włącza się przyjemne oświetlenie, włącza się muzyka, film lub jakiś inny stosowany program TV dostosowany do naszego gustu. Temperatura w całym domu wyregulowana jest na optymalną wartość, odpowiadającą wszystkim mieszkańcom domu. Nie jest ani za zimno ani za gorąco. Zasiadając przy telewizorze w naszym ulubionym salonie, nie musimy martwić się o to, że poziom natężenia światła jest niezadowalający, wystarczy jedno naciśnięcie przycisku „tryb wieczorowy” na pilocie, komórce lub innym urządzeniu sterującym lub nawet jedno słowo żeby włączyć wcześniej zdefiniowaną wartość natężenia światła powodując natychmiastową zmianę klimatu w pokoju. Żaluzje okienne przysłonią się automatycznie w zależności od nasłonecznienia pokoju [3, 4]. W dzisiejszych czasach mało kto ma czas na pielęgnację własnego ogródka, a w szczególności na jego codzienne podlewanie. Nie musimy się już o to martwić, gdyż w zależności od panujących warunków pogodowych, dom sam o to zadba. Wychodząc z domu, przekręcając klucz w naszych drzwiach automatycznie włącza się system alarmowy, opuszczają się rolety w oknach, obniża się temperatura w poszczególnych pokojach, niezgaszone lampy same się wyłączają, sprzęt AGD i RTV zostaje automatycznie wyłączony [4]. Oprócz wygody, tego typu czynności pozwalają nam zaoszczędzić znaczną ilość energii, co nie jest wcale bez znaczenia w dzisiejszych czasach. Te wszystkie zautomatyzowane czynności to właśnie idea Inteligentnego Domu. 8 Rys.1 Schemat ideowy Inteligentnego Budynku [http://dqm.pl/_img/inteligentny_bud.jpg] 1.2 Definicja Inteligentnego Budynku Inteligentny budynek (również inteligentny dom, system zarządzania budynkiem) – jest określeniem wysoko zaawansowanego technicznie budynku. Zdefiniowanie samego pojęcia nie jest rzeczą prostą i spotkać można wiele określeń. [2].Według EIBG Budynek Inteligentny to budynek, który maksymalizuje efektywność osób go wykorzystujących i pozwala efektywnie zarządzać zasobami przy minimalnych kosztach [2]. Według innej definicji Budynek Inteligentny posiada zdolność adaptacji do nowej technologii i zmieniających się potrzeb organizacji jego użytkowników [2]. Jeszcze inni uważają, że Inteligentny Budynek to taki, w którym można kontrolować cały budynek za pomocą kilku przycisków lub pilota. Uogólniając temat definicji Inteligentnego Budynku uważam, że Inteligentne Budynki powinny mieć następujące cechy: • Integracja systemów teletechnicznych w budynku • Centralny system zarządzania i nadzoru • Kanał komunikacyjny umożliwiający sterowanie urządzeniami w budynku 9 • Efektywne zarządzanie przestrzenią budynku w celu minimalizacji kosztów eksploatacji 1.3 Historia powstania i ewaluacja Inteligentnego Budynku Zagadnienie sterowania różnymi urządzeniami zarówno w danym pomieszczeniu jak i jego otoczeniu jest znane od dawna [2]. Sam pomysł Inteligentnych Budynków wywodzi się ze Stanów Zjednoczonych. Początki rozwoju przypadają na wczesne lata 70te. W tym okresie poddano elektronicznym udoskonaleniom systemy ogrzewania, wentylacji i klimatyzacji (ang. HVAC) oraz systemy oświetleniowe. Głównymi powodami tych zmian były względy ekonomiczne, tj. konieczność ograniczenia zużycia energii oraz usprawnienie obsługi nowo powstających, coraz to większych biurowców [2]. Sprecyzowane pojecie Inteligentnego Budynku pojawiło się 10 lat później, w latach 80-tych, gdzie nastąpiła stopniowa automatyzacja różnych systemów, tj. system kontroli dostępu, system przeciwpożarowy, system sterowania windami itp.[2]. Zaczęto intensywnie myśleć nad koordynacją działania elementów poszczególnych systemów. Sukcesywna integracja różnych technologii w latach 90-tych doprowadziła do powstania współczesnych Budynków Inteligentnych. Obecnie wszystkie systemy w budynku mają strukturę sieciową. Trzeba powiedzieć o tym, że niektóre systemy bywają celowo rozdzielone, jednak są kontrolowane przez jeden centralny punkt, aby ułatwić ich współdziałanie. Przykładami takich systemów zajmę się w rozdziale 3. 10 2 Cel i zakres pracy Cel pracy można podzielić na dwie części. Część pierwsza to poznanie systemu operacyjnego Symbian OS, który obok Windows Mobile rozpowszechnionym systemem operacyjnym na telefony komórkowe. jest najbardziej Precyzując ten rozległy temat, celem jest zapoznanie ze sposobami tworzenia i uruchamiania oprogramowania na tym systemie. Druga część polega na wykorzystaniu napisanego oprogramowania do sterowania urządzeniami w oparciu o protokół 802.15.1 (Bluetooth). Zakres pracy obejmuje opisanie zasady tworzenia aplikacji komunikacyjnych dla OS Symbian, zapoznanie się z protokołem Bluetooth, oraz opracowanie protokołu wymiany informacji pomiędzy różnego typu urządzeniami wyposażonymi w interfejs Bluetooth ze szczególnym uwzględnieniem problemów niezawodności i bezpieczeństwa transmisji, ale także wygody użytkownika systemu. 11 3 Inteligentny Budynek 3.1 Inteligentny Budynek – zastosowanie Można budować całe systemy złożone z przeróżnych sensorów, czujników. Oczywiście można to wszystko usystematyzować, w poszczególne podsystemy, które w krótki sposób postaram się scharakteryzować. Rys.2 Schemat przedstawiający podsystemy Inteligentnego Budynku [http://www.mikroenergetyka.com.pl/images/systemy/eib2.jpg] Do najbardziej popularnych podsystemów zalicza się: • System sterowania ogrzewaniem Zastosowanie takiego systemu jest dosyć oczywiste. Jego zadaniem jest odpowiednia reakcja na zbyt niską lub zbyt wysoką temperaturę panującą w danym pomieszczeniu. Polega to na podgrzewaniu względnie obniżaniu temperatury poszczególnych pokoi 12 [6]. Nie trudno wyobrazić sobie sytuację gdzie dwa pokoje usytuowane są w różnych częściach domu, jeden od wschodu słońca, a drugi od zachodu. Wydawałoby się, że temperatura w tych pomieszczeniach musi być różna, uzależniona od położenia tych pokoi. Wcale nie musi tak być, gdyż taki system zadba o to, aby temperatura we wszystkich pokojach była taka sama, dostosowana do naszych wymagań. [4] • System sterowania oświetleniem We wstępie mojej pracy wspomniałem o tym systemie, który jest odpowiedzialny za automatyczną regulację oświetlenia zgodną z upodobaniami mieszkańców. Najprostsze systemy tego typu umożliwiają zaprogramowanie kilku nastrojów oświetleniowych w poszczególnych pomieszczeniach [6]. Zaawansowane systemy umożliwiają jeszcze bardziej fantazyjne rozwiązania [5]. Możemy zaprogramować ściemnianie lamp, tak żeby w określonych godzinach wieczorowych światło na korytarzu nie oślepiało nas. Często zdarza się, że wracając z zakupów, wchodząc do domu mamy zajęte ręce. Otwierając zamek w drzwiach, system automatycznie wykryje naszą obecność i podejmie stosowną decyzję o włączeniu światła w pokoju, w którym się znaleźliśmy [5][6]. • System symulacji obecności Jest to jeden z najbardziej popularnych sposobów wykorzystania systemu inteligentnego domu [6]. Wyjeżdżając na zasłużony wakacyjny wypoczynek, nasz dom staje się potencjalnym celem dla złodzieja. Posiadanie takiego systemu zmniejsza ryzyko „nieproszonych” gości. Wystarczy, że odpowiedni moduł systemu nagrywa poczynania domowników przez pewien okres czasu i odtwarza nagrane czynności symulując obecność w budynku (chodzi głównie o zapalanie i gaszenie światła w poszczególnych pomieszczeniach, włączanie muzyki) [6]. Bardziej wyrafinowane systemy wykorzystują do tego celu większość urządzeń zintegrowanych z systemem, tj. telewizora, telefonu, lub innych podsystemów, które skutecznie mogą odstraszyć włamywacza [6]. 13 • System alarmowy Pożar, powódź i inne żywioły są największymi zagrożeniami dla budynku a przede wszystkim dla ludzi tam przebywających. Nie można też zapomnieć o wrogu, jakim jest włamywacz. Wczesne wykrycie zagrożenia i możliwość zapobiegnięciu niebezpieczeństwa jest podstawowym celem takiego systemu [6]. Dzięki czujnikom i detektorom takim, jak chociażby detektor ruchu możliwa jest reakcja systemu na próby włamania [10]. Reakcje systemu mogą być bardzo różne [9], od włączenia alarmu, który sygnałem dźwiękowym zwróci uwagę osób trzecich, po automatyczne poinformowanie policji o zaistniałych okolicznościach. Bardzo często taki system jest połączony z innymi systemami, tj. systemem kamer, który może okazać się kluczowym zagadnieniem dla policji, czy systemem przeciwpożarowym, który w kilku zdaniach omawiam poniżej. • System przeciwpożarowy Tak jak wspomniałem wcześniej, jest on istotnym systemem z punktu widzenia systemu alarmowego, gdyż bardzo często jest on uruchamiany za jego pośrednictwem. Zadaniem tego podsystemu jest oczywiście ochrona budynku przed pożarem wraz z jego mieszkańcami. Taki system najczęściej składa się z dwóch części: sieci czujników temperatury i dymu oraz bezpośredniej sieci przeciwpożarowej, czyli sieci różnego typu spryskiwaczy [9] [10]. • System kontroli dostępu Jeden z bardziej skomplikowanych systemów. Ma zastosowanie przede wszystkim w biurowcach i jest oparty najczęściej o system personalizacji. Osoba z grupy osób, która ma dostęp do wybranego budynku chcąc wejść do niego musi być rozpoznana przez system personalizacji, który w następstwie informuje system kontroli, że dana osoba ma prawo wejścia do budynku. Wspomniany system personalizacji zajmuje się dostosowywaniem wymagań poszczególnych osób w inteligentnych budynkach. Idea jest taka, żeby osoby znajdujące się w grupie objętej dostępem do budynku, mające różne upodobania miały 14 możliwość zdefiniowania systemu tak żeby funkcje systemu realizowane automatycznie odpowiadały ich wymaganiom. [10] • System pogodowy System, na który składa się szereg czujników, które decydują o zamknięciu okien na wypadek deszczu. Czujniki takie mogą również spowodować przejście na niezależne zasilanie podczas burzy. Powyżej wymieniłem tylko podstawowe podsystemy, które wchodzą w skład systemu zarządzania budynkiem. Trzeba mieć świadomość, że podobnych podsystemów jest bardzo wiele [6]. 3.2 Sieci domowe w kontekście Inteligentnego Budynku Całkiem nie dawno temat sieci domowych nie cieszył się tak dużą popularnością jak dzisiaj. Na skutek bardzo szybkiego rozwoju Inteligentnego Budynku, zainteresowanie sieciami domowymi diametralnie wzrosło. Termin „Sieć Domowa„( Home Network) wygląda dosyć niewinnie, w rzeczywistości można powiedzieć, że jest to sieć składająca się z wielu komputerów i urządzeń peryferyjnych, które połączone są ze sobą istniejącą instalacją telefoniczną i elektryczną lub bezprzewodową. [11]. W odniesieniu do Inteligentnego domu, sieci domowe można podzielić na dwie podsieci: komputerowe (HomePNA, HomeRF, inne) i sieci sterujące urządzeniami peryferyjnymi (EIB, X10, PLC, Lonworks, CEBus, Echonet, technologie bezprzewodowe). Oczywiście obie te podsieci muszą umieć „rozmawiać” ze sobą. 15 Rys3. Wykaz technologii dla sieci domowych [11] 3.3 Podział sieci domowych ze względy na użyte medium. 3.3.1 Sieci z nowym okablowaniem • Ethernet 10Base-T • HAVi (Home Audio Video interoperability) • EIB (European Installation Bus) • USB (Universal Serial Bus) • Protokół IEEE 1394 (Fireware) Ethernet Najważniejszą z tych sieci jest oczywiście sieć Ethernet. Zalety takiej sieci są powszechnie znane, czyli niezawodność i szybkość przesyłania danych. Dużą wadą, hamującą rozwój tej sieci jest konieczność dodatkowego okablowania oraz dosyć duży stopień komplikacji [7]. Nie będę opisywał tego protokołu, gdyż jest on powszechnie znany i informacje o nim są ogólnie dostępne. HAVi Komunikacja wszystkich urządzeń w tej sieci odbywa się za pośrednictwem jednego urządzenia sterującego. Nośnikiem sprzęgającym jest IEEE 1394. Dużą zaletą jest to, że 16 HAVi może operować na urządzeniach od różnych producentów [19]. System z definicji ma być bardzo łatwy w obsłudze i dlatego, kiedy zostanie dołączone jakieś nowe urządzenie, takie jak faks, czy drukarka, to system sam je skonfiguruje. Więcej na ten temat można dowiedzieć się ze strony internetowej http://havi.org. EIB Opracowany został przez czołowych europejskich producentów systemów elektroinstalacyjnych w 1990 roku [21]. W Polsce pojawił się 6 lat później. Instalacja EIB pozwala na swobodne zarządzanie budynkiem, czyli służy do szeroko rozumianego sterowania urządzeniami elektrycznymi stosowanymi w budownictwie [21]. Jest ona bardzo konkurencyjną instalacją dla klasycznej instalacji elektrycznej. Tradycyjne elementy sterownicze zostały zastąpione urządzeniami wykonanymi w technice cyfrowej, które potrafią wymieniać informacje za pomocą jednego, łączącego wszystkie urządzenia elektryczne przewodu magistralnego. Przekrój takiego przewodu przedstawia rysunek numer 4. Jest to dwuparowa skrętka o przekroju żyły 0,8mm, zasilanej napięciem stałym 24 V. Do transmisji wykorzystywana jest tylko jedna para przewodów, druga służy jako rezerwa. Rys.4 Przekrój przewodu komunikacyjnego w EIB [http://www.e-instalacje.pl/artykul_zdjecia/instabus_art3.jpg] Z punktu widzenia bezpieczeństwa, wielką zaletą jest fakt, iż przez ten przewód płynie bezpieczne napięcie 24V. Napięcie 230 V owszem występuję, jednak doprowadzone jest tylko i bezpośrednio do odbiorników prądu (gniazdka elektryczne itp.) [22]. 17 W krajach Unii Europejskiej EIB jest jednym z najszybciej rozwijających się standardów automatyki. Szacuje się, że 70% nowo budowanych budynków w Niemczech będzie posiadało system EIB [21]. Sieć komunikacyjna, EIB jest siecią typu „peer to peer”, w której może funkcjonować do 57375 urządzeń [21]. Wszystkie te urządzenia mają równe prawa dostępu do medium komunikacyjnego. Wynika to bezpośrednio z protokołu CSMA/CA [20]. Możliwe topologie EIB przedstawia rysunek numer 5. Więcej informacji na temat EIB można dowiedzieć się ze strony internetowej http://eib.org. Rys 5. Możliwe topologie w EIB [http://upload.wikimedia.org/wikipedia/commons/b/b4/Topologia_eib.png] 3.3.2 Sieci bez nowego okablowania • HomePNA (Home PhoneLine Alliance) - standardy sieci oparte na skrętce telefonicznej; • PLC (PowerLine Communication) – sieć szerokopasmowa oparta na zewnętrznym okablowaniu energoelektrycznym • PLC (PowerLine Communication) – sieć wąskopasmowa oparta na wewnętrznym okablowaniu elektroenergetycznym. Do najczęstszych protokołów własnych 18 należą: X10, CEBus, Lonworks, PLT, PLUG-IN, Echonet. Do tej grupy zaliczają się sieci oparte o już istniejące okablowanie elektroenergetyczne i telefoniczne na skrętce UTP. HomePNA Jest to sieć, w której urządzenia połączone są za pomocą skrętki telefonicznej. Obecnie przepływność sieci wynosi 100 Mb/s. Specjalne konsorcjum o tej samej nazwie, co protokół zajmuje się standaryzacją tego typu systemów sieciowych. Do grupy założycieli należą największe firmy na świecie z branży IT, tj.:3COM, IBM, INEL, Hewlett-Packard i wiele innych [11]. Obecnie sieć obsługuje do 25 urządzeń. Poniżej przedstawiam rysunek, obrazujący idee takiej sieci. Rys 6. Idea sieci HomePNA [http://www.domotica.nl/images/standaard-homepna.jpg] Więcej na temat tego standardu można dowiedzieć się na stronie internetowej http://homepna.org. PLC Komunikacja w tej sieci oparta jest o linie elektroenergetyczne. Rozróżnić można dwa rodzaje takich sieci: szerokopasmową i wąskopasmową. Mnie w szczególności interesuje 19 sieć wąskopasmowa, która korzysta jedynie z domowego okablowania elektroenergetycznego, które służy do komunikacji urządzeń elektrycznych. Urządzenia w takiej sieci działają w oparciu o różne standardy (protokoły). Postaram się wymienić te najbardziej popularne i mające przyszłość i w kilku zdaniach je omówić [11]. X10 Protokół ten znany jest już od około 25 lat i z założenia przeznaczony jest do sterowania urządzeniami domowymi, tj.: oświetleniem, czy ogrzewaniem i wentylacją [11, 13]. Największą popularność zyskał w USA, jednak technologia X10 zaczyna się też cieszyć dużą popularnością na innych kontynentach [13]. Ważną rzeczą jest to, aby jak największa ilość urządzeń przeznaczonych dla Inteligentnych Budynków umiało obsługiwać ten protokół. Obliczono, że na rynku światowym jest już ponad 10 milionów urządzeń obsługujących ten protokół. Rozbudowa takiej sieci jest rzeczą niebywale prostą, gdyż wymaga jedynie włączenia nowego urządzenia do jakiegoś gniazdka prądowego lub zamontowania go na szynie DIN (takiej jak przy bezpiecznikach) [13]. Transmisja danych cyfrowych przez przewody instalacji elektrycznej odbywa się przy użyciu modulacji amplitudowej. Dane przesyłane są w specjalnych ramkach po detekcji przejścia napięcia przemiennego przez zero [13]. Więcej informacji na temat X10 znaleźć można na witrynie http://www.cotse.com/dlf/man/x10/index.htm . LonWorks Jeden z bardziej wyrafinowanych protokołów komunikacyjnych. Standard ten jest silnie wspierany przez największe koncerny w USA, a także w Europie. Technologia LonWorks umożliwia łączenie różnorodnych urządzeń nie tylko po przewodach zasilających. Kanałem komunikacyjnym równie dobrze może być skrętka telefoniczna, fale radiowe czy podczerwień [15]. Komunikacja jest odporna na zakłócenia dzięki specjalnym systemom kontroli błędów, które są wbudowane w urządzenia obsługujące ten standard. Jak podaje Echelon (firma zajmująca się tym protokołem), w skład systemu może wchodzić maksymalnie 32 tysiące urządzeń [15]. Wąskopasmowe urządzenia PLC pracujące w omawianym systemie składają się typowo z kilku komponentów: zasilacza, mikroprocesora, transceivera, oraz elementu sprzęgającego sygnał danych z siecią 20 energetyczną. Więcej informacji na ten temat można znaleźć na witrynie http://www.echelon.com/developers/lonworks/faq.htm. CEBus i PLUG-IN Urządzenia produkowane przez firmę Intellon, która promuje system CEBus posiadają układ nadawczo-odbiorczy oraz mikrokontroler. Szybkość transmisji dochodzi do 10kb/s z wykorzystaniem zapewnia techniki rozpraszania widma [11]. Jest to otwarty standard, który specyfikację oddzielnej warstwy elektroenergetycznymi, światłowodami, fizycznej skrętkami, dla komunikacji liniami podczerwienią oraz RF [13]. Specyfikacja definiuje wspólną składnię komend, dzięki której następuje komunikacja (jest to tzw. język CAL, ang. Common Application Language) [13]. Więcej informacji na temat tego protokołu znaleźć można na stronie internetowej firmy Intellon ( http://intellon.com ). Protokół PLUG-IN w pełni odnosi się do warstwowego modelu OSI. Zostały w nim zdefiniowane wszystkie warstwy oprócz sesji i prezentacji [11]. Protokół PLUG-IN jest podobny do CEBus. Różnica jest taka, że Intelogis (firma upowszechniająca PLUG-IN) promuje model klient/serwer, a nie model „peer to peer” [17]. Dużą wadą obu standardów (w porównaniu do standardu X10) jest wysoka cena urządzeń obsługujących te standardy. ECHONET Echonet wywodzi się z Japonii i jest jedną z najnowszych technologii sieci domowych. Oprócz obsługi linii energetycznych, specyfikacja umożliwia wykorzystanie łączy bezprzewodowych a także łączy IrDA [11]. Patrząc na ten protokół z punktu widzenia modelu OSI, warstwę fizyczną sieci można rozszerzać na inne media, chociażby takie jak Bluetooth – oczywiście przez dodanie odpowiednich sterowników. Echonet cechuje otwarta architektura. Producenci mogą więc dodawać własne usługi. Więcej na ten temat można dowiedzieć się ze strony internetowej http://www.echonet.org. Współczesne standardy PLC Obecnie standardami PLC zajmuje się kilka organizacji na świecie. Na kontynencie europejskim najważniejszą jest Open PLC European Research Alliance (OPERA), która częściowo finansowana jest przez Komisję Europejską [16]. Produkty oparte na 21 specyfikacji tego standardu będą w stanie przesłać dane z prędkością 200 Mb/s [16]. Więcej informacji na jego temat można znaleźć na www.ist-opera.org. Inne gremium standaryzacyjne, Home Plug Alliance zajmuje się specyfikacją HomePlug AV, która teoretycznie oferuje transfer do 200 Mb/s (podobnie jak OPERA), lecz w praktyce jest trochę inaczej. W rzeczywistości sieć oparta o ten standard umożliwia przesyłanie danych z prędkością rzędu 14 Mb/s (HomePlug 1.1) i 85 Mb/s (HomePlug Highspeed) [18]. Specyfikacja opisuje HD-PLC, która umożliwia prędkość przesyłania danych na poziomie 170 Mb/s, lecz na razie jest to rozwiązanie czysto teoretyczne. Również teoretyczna jest możliwość podłączenie 253 adapterów maszyn, gdyż producenci nie zalecają wykorzystywania więcej niż dziesięciu jednocześnie [18]. Jednak istotną rzeczą jest to, iż nowy standard zapewnia szyfrowanie transmitowanych danych [16]. Zainteresowanie standardem jest dosyć duże, gdyż można zaobserwować powiększającą się listę certyfikowanych przez HomePlug Alliance urządzeń. Niestety zdecydowana większość produktów przeznaczona jest na rynek amerykański, gdzie napięcie w instalacjach elektrycznych wynosi 110V. Warto również zauważyć, że specyfikacja opisująca ten standard nie jest ujawniona. Więcej informacji można znaleźć na firmowej stronie internetowej firmy dostarczającej układy scalone dla urządzeń zgodnych z tym standardem http://intellon.com. Oprócz OPERY i HomePlug dwie grupy producentów zawiązały współpracę w celu stworzenia standardu PLC. Pierwszą jest United Powerline Association (w skład której wchodzi m.in. Ascom), oraz CE-Powerline Communications Alliance (w skład której wchodzą m.in. Panasonic i Sony). Wspomniana przeze mnie firma Ascom posiada swój własny system PLC (ASCOM PLC), który składa się z systemów zewnątrzbudynkowego (outdoor) i wewnątrzbudynkowego (indoor). Mnie interesuje ten drugi. System wewnątrzbudynkowy rozsyła sygnał do wszystkich gniazdek w budynku. Umożliwia przesyłanie danych przez sieć energetyczną niskiego napięcia z szybkością 4,5 Mb/s [17]. Producent podaje jednak, że praktyczna wartość tego parametru to 3 Mbit/s. Urządzenie końcowe podłączone do gniazdka to samokonfigurujący się adapter z wbudowanymi interfejsami 10Base-T i USB [17]. Adapter może również posiadać złącze telefoniczne a/b, dzięki któremu możliwe jest podłączenie telefonu analogowego. System umożliwia także stworzenie sieci domowej, do której dostęp jest zapewniony z każdego gniazdka elektrycznego w budynku [17]. 22 Omawiany system charakteryzuje się ograniczonym zasięgiem, co oznacza, iż długość linii dystrybucyjnej pomiędzy stacją transformatorową a budynkiem odbiorcy energii nie może przekroczyć 350 m, a długość przewodów domowej instalacji elektrycznej łączącej urządzenia w sieć lokalną nie powinna być większa niż 70 m [17]. Więcej informacji można się dowiedzieć ze strony internetowej http://ascom.com. Największą konkurencją dla systemu oferowanego przez firmę Ascom jest rozwiązanie PLUS (Power Line Ultimate System) izraelskiej firmy Main.net. Niestety producent nie podaje dokładnych parametrów technicznych produkowanych urządzeń. Maksymalna szybkość transmisji oferowana przez system nie przekracza 2,5 Mbit/s [14]. Na szczególną uwagę zasługuje internetowy terminal HotPLUS, który po podłączeniu do dowolnego gniazdka zasilającego w budynku umożliwia dostęp do różnorodnych usług, takich jak: poczta elektroniczna, wideo-konferencje, oraz telefonia pakietowa [14]. Szczegółowe informacje na jego temat można znaleźć na stronie internetowej firmy MainNet Communications http://www.mainnet-plc.com. Podsumowując bardzo rozległy temat jakim jest PLC, warto zauważyć że problemem PLC nie jest brak standardów, lecz paradoksalnie ich nadmiar. W przyszłości może powstanie jedna, ale za to dopracowana specyfikacja, która ułatwi rozwój tego standardu. 3.3.3 Sieci bezprzewodowe • IrDA • HomeRF • ZigBee • Bluetooth 3.3.3.1 IrDA Jest protokołem transmisji cyfrowych w podczerwieni, który powstanie zawdzięcza normalizacji dotyczącej pilotów do telewizorów i magnetowidów. Protokół ten jest silnie wspierany przez największe firmy na świecie. Na razie IrDA zapewnia transmisję typu 23 punkt-punkt na odległość ok. 1 m w zakresie falowym 850-900 nm. [23]. Osiągane prędkości przepływu danych dochodzą do 16 Mb/s, ale kąt transmisji nie może przekroczyć 30° [23]. Prędkość transmisji jest ściśle związana z odległością komunikujących się urządzeń. Wystarczy że odległość tą zwiększymy do 5 m, wówczas szybkości transmisji spadnie do 75 kb/s. Dobrze ilustruje to rysunek numer 7 [23]. Patrząc na ten rysunek można zauważyć: IrDA-Data, IrDA-Control oraz AIr. Są to standardy komunikacji za pośrednictwem fal podczerwonych. IrDA DATA przeznaczony jest dla transmisji danych (VFIR, FIR, SIR) [23], IrDa Control obejmuje aspekty sterowania a AIr jest jeszcze na etapie rozwoju. Rys. 7 Prędkości transmisji w porównaniu z odległościami w IrDa i Bluetooth [12] Architektura tego standardu składa się z kilku protokołów i pokazuje to rysunek nr.8. Protokoły te podzielone są na warstwy spełniające wiele funkcji. A warstwy można podzielić na 3 podgrupy [11]: - protokoły implementowane obowiązkowo - protokoły opcjonalne - protokoły multimedialne 24 Rys. 8 Stos protokołów IrDA [12] W skład pierwszej podgrupy (protokołów obowiązkowych) wchodzą: • Warstwa fizyczna (Physical Layer) - tutaj następuje kodowanie danych, synchronizacja ramek, oraz sprawdzanie bitu nadmiarowości CRC [12]. • IrLAP - jest to protokół dostępu do łącza i odpowiada za niezawodny transfer danych. Jej zadaniem jest m.in. zawiadamianie warstw wyższych o zaistniałych problemach, tj. przerwanie wiązki światła itp. Jeśli taka sytuacja ma miejsce wówczas użytkownik może otrzymać stosowny komunikat informujący o problemie. Trzeba nadmienić że wszystko to odbywa się bez przerwania połączenia i utraty transmitowanych danych [12]. • IrLMP - protokół zarządzania łączem, który odpowiada za multipleksowanie usług i aplikacji [12]. • IAS - protokół dostępu do informacji [12]. 25 Zastosowanie protokołów opcjonalnych zależy od konkretnej aplikacji. Do tej podgrupy należą [12]: • IrTTP - protokół transportowy, pełni bardzo ważną funkcję, gdyż zapewnia sterowanie strumieniem w kanale. Funkcja ta jest często rekomendowana dla wielu aplikacji. • IrOBEX - ułatwia transfer plików oraz innych obiektów danych. protokół ten określa zasady wymiany obiektów (pliki, wszelkiego rodzaju informacje sterujące) pomiędzy stacjami (komputery klasy PC, urządzenia telekomunikacyjne, sprzęt gospodarstwa domowego, itp.) • IrCOMM - jego zadaniem jest emulowanie portów szeregowych i równoległych. • IrLAN - określa zasady współpracy z sieciami lokalnymi (zapewnia urządzeniom, przykładowo notebookom, dostęp do sieci lokalnej za pośrednictwem podczerwieni). Protokoły multimedialne zaliczające się do grupy protokołów opcjonalnych to: • IrMC - jego zadaniem jest określenie zasad współpracy ze sprzętem telekomunikacyjnym (telefony komórkowe, itp.) • IrTran-P - określa zasady przesyłu i reprezentacji obrazów cyfrowych. Dodając protokół warstwy aplikacyjnej w bardzo łatwy sposób mamy możliwość uzyskania dodatkowej usługi [23]. Ponadto standard ten cechuje możliwość zwiększania szybkości w następnych wersjach, nie tracąc jednocześnie kompatybilności ze starszymi. Poprzez implementowanie tylko niektórych wybranych protokołów (z puli protokołów opcjonalnych) możemy uzyskać pewnego rodzaju oszczędność (przykładowo aparaty cyfrowe z IrDA nie musza implementować protokołu dostępu do sieci LAN ) [12]. 26 3.3.3.2 HomeRF Protokół ten wyróżnia się tym z pośród innych, że równocześnie zapewnia: szerokopasmowy dostęp do Internetu, współdzieli zasoby, wiele sesji strumieni medialnych a także kilka wysokiej jakości połączeń głosowych [12]. Dobrze to uwidacznia rysunek numer 9, gdzie przedstawiłem stos protokołów. Rys. 9 Specyfikacja HomeRF [12] Urządzenia HomeRF operują w globalnie otwartym paśmie 2,4 GHz, czyli w takim samym co Bluetooth i kuchenki mikrofalowe [12]. Stosują technologię skoków po częstotliwościach - od 50 do 100 skoków na sekundę. Problem utraty pakietów wiąże się z interferencjami wywołanymi przez inne urządzenia działające w tym samym paśmie lub inne sieci bezprzewodowe [12]. W HomeRF zaimplementowano kilka mechanizmów które zwalczają ten problem. Pakiety z danymi podlegają ADS [24], czyli mechanizmowi pozwalającemu uniknąć kolizji. Jeśli węzeł nie otrzyma potwierdzenia odbioru pakietu, wówczas przed próbą powtórnego wysłania pakietu odczeka jakiś zadany okres czasu, odpowiadający pewnej liczbie szczelin czasowych. Innym mechanizmem który został zaimplementowany w HomeRF jest mechanizm o nazwie PADS [24]. Jest to metoda która pozwala przypisać konkretnym pakietom priorytet dostępu do kanału komunikacyjnego (mechanizm przydatny np. w sesjach wideo). 27 Kilka informacji o stosie protokołów HomeRF. Za szybkość przesyłania danych odpowiada oczywiście warstwa fizyczna. Warstwa wyższa (czyli MAC) odpowiada za bezpieczeństwo, oraz definiuje typy obsługi danych (np. video) [12]. Trzeba wspomnieć o najważniejszym protokole, który został zdefiniowany w HomeRF, czyli o SWAP [24] (umiejscowiony w warstwie MAC). Umożliwia on przenoszenie zarówno głosu jak i danych. Interaktywne transakcje głosowe wykorzystują TDMA, natomiast transakcje asynchroniczne (usługi bezpołączeniowe, używane typowo w ruchu TCP/IP) wymagają CSMA/CA [24]. W porównaniu z Ethernetem, można powiedzieć, że HomeRF jest jego przeciwieństwem ponieważ używa dwóch oddzielnych protokołów dostępu do medium. Wybiegając w przyszłość, zagrożeniem z punktu widzenia firm które są mocno związane z rozwojem tego standardu są technologie HomePNA i PLC. Kto zwycięży, dowiemy się w niedalekiej przyszłości. 3.3.3.3 ZigBee (IEEE 802.15.4) Promocją tego standardu zajmuje się grupa ZigBee Alliance, do której należą największe firmy zajmujące się oprogramowaniem i produkcją sprzętu elektronicznego. Najważniejszą cechą tego standardu, którą należy wymienić w pierwszej kolejności jest niski pobór energii urządzeń które się ze sobą komunikują. Inną zaletą jest prostota budowy sieci opartej o ZigBee [25]. Urządzenia pracujące w takiej sieci działają w zakresach częstotliwości które nie wymagają pozwolenia [26]. Dobrze to obrazuje rysunek numer 10. 28 Rys. 10 Ulokowanie kanałów standardu 802.15.4. [25] We wszystkich 27 kanałach komunikacyjnych wykorzystuje się proste rozpraszanie widma DSSS [26]. Pozostałe parametry tego standardu pokazuje tabela numer 1 Pasmo 868/915 MHz (11 kanałów), 2,4 GHz (16 kanałów) Zasięg 10-30 m Opóźnienie 15 ms Adresowanie 8 lub 64 bity Dostęp do kanału CSMA-CA Przepływność 868 MHz: 20kb/s; 915 MHz: 40kb/s; 2,4 GHz: 250kb/s Temperatura pracy Od -40 do 85˚C Tab.1 Podstawowe parametry standardu ZigBee Stos protokołów w ZigBee przedstawia rysunek na następnej stronie. 29 Rys.11 Stos protokołów ZigBee [25] Na uwagę zasługuje jedynie warstwa łącza danych, w której znajduje się specjalna podwarstwa zbieżności SSCS [26] odpowiedzialna za współpracę z logiczną kontrolą łącza zgodną z 802.2. SSCS zapewnia kompatybilność pomiędzy różnymi implementacjami LLC. ZigBee przewidział w swojej specyfikacji specjalny tryb pracy dla aplikacji które wymagają małych, stałych opóźnień. Wówczas ustalony „koordynator” koordynuje pracę urządzeń mu podległych. Realizuje to poprzez wysyłanie w odpowiednim czasie specjalnych ramek kontrolnych. Odstęp między nimi może wynosić od 15 ms do 245 s. Dostęp do szczelin czasowych w których można coś wysłać odbywa się na zasadzie rywalizacji, lecz urządzenie koordynujące ma możliwość przypisania szczeliny czasowej urządzeniu, które wymagać będzie określonego pasma i opóźnienia [25]. Który mechanizm zostanie użyty, zależy od topologii sieci. Możliwe topologie przedstawia rysunek numer12. Rys.12 Topologie sieci ZigBee [25] 30 Obecnie ZigBee jest silną konkurencją dla standardu X10 czy LonWorks, które w dużej mierze ograniczone są przez kable. Największym rywalem jest jednak Bluetooth, który opisuję szerzej w następnym podrozdziale. Dużą zaletą ZigBee w odniesieniu do Bluetooth jest zasięg między węzłami, który jest rzędu ok. 100m. Inną pozytywną cechą tego standardu jest to, że urządzenia pracujące w standardzie Bluetooth muszą być ładowane co kilka lub kilkanaście dni. ZigBee przewyższa pod tym względem Bluetooth, uwzględniono w nim bardzo niski pobór mocy (urządzenia korzystające z pary baterii AAA mogą wytrzymać nawet 2 lata) [25]. Wynika to z charakteru transmisji (urządzenie wysyłają informacje tylko wtedy kiedy wymaga tego aplikacja – dostęp do kanału jest więc tylko chwilowy). 3.3.3.4 Bluetooth Technologia ta jest pomysłem inżynierów szwedzkiej firmy Ericsson. Prowadząc kilkuletnie badania nad komunikacją bezprzewodową, zaprosili oni do współpracy kilka innych firm. Firmy te założyły w 1998 roku grupę Bluetooth Special Interest Group (SIG), która funkcjonuje do tej pory i zajmuje się rozwijaniem tej technologii [12]. System Bluetooth pracuje na częstotliwości 2,4 GHz, w jednym z trzech pasm ISM. Pasma ISM zostały udostępnione na całym świecie systemom radiowym o małej mocy. Pasma te w większości państw nie są licencjonowane. Rys.13 Rozmieszczenie kanałów w systemie Bluetooth Jak widać z powyższego rysunku, kanał radiowy zajmuje 1 MHz, a liczba kanałów wynosi 79. Dopuszczalne odchylenie od częstotliwości nośnej nie może być większe ani mniejsze od 75 kHz [27]. 31 Twórcy systemu Bluetooth ze względu na różnego rodzaju zakłócenia generowane przez urządzenia działające w tym samym paśmie zastosowali technikę rozpraszania widma sygnału z pseudolosowym przeskokiem częstotliwości. Liczba skoków w ciągu sekundy wynosi 1600. Różnica między częstotliwościami po skokach jest całkowitą krotnością 1 MHz. Sens działania mechanizmu jest taki, że nadajnik nie pracuje na jednej częstotliwości – zmienia ją z odpowiednią częstotliwością zgodnie z pewną sekwencją skoków. W bardzo podobny sposób pracuje odbiornik, który nie dostraja się do stałej jednej częstotliwości lecz zmienia ją ze znaną sekwencją [27]. Z punktu widzenia bezpieczeństwa, rozwiązanie to wydaje się być interesujące, gdyż odbiornik który nie będzie znał odpowiedniej sekwencji nie będzie mógł odebrać przesyłanego sygnału Ale czy jest to mechanizm wystarczający? Na to pytanie odpowiem w dalszej części pracy. Sekwencja przeskoków jest unikalna w obrębie jednej sieci i określona przez BD_ADDR (adres ten jest odpowiednikiem adresu MAC elementów sieci LAN) [27].Z liczby przeskoków częstotliwości w ciągu jednej sekundy można wyliczyć czas pracy jednej szczeliny czasowej równej 625us [27]. Urządzenia typu Master przesyłają pakiety w parzystych szczelinach czasowych, natomiast urządzenia typu Slave zarezerwowane mają nieparzyste szczeliny czasowe. Kilka słów o urządzeniach typu Master (urządzenia nadrzędne) i typu Slave (urządzenia podrzędne). Zgodnie ze specyfikacją każde urządzenie w sieci Bluetooth może pełnić dowolną z tych ról [27]. Oczywiście są pewne zasady co do tego. Załóżmy, że mamy pikosieć składającą się z: urządzenia typu Master jakim może być przykładowo komputer i urządzenia typu Slave jakim może być klawiatura. Do istniejącej sieci chcemy dołączyć mysz. Podłączając ją do zasilania, automatycznie powodujemy utworzenie tymczasowej nowej pikosieci, w której urządzeniem Master staje się to nowo przyłączone urządzenie. W tym momencie następuje realizacja procedury PAGE, która inicjowana jest zawsze przez urządzenie Master [27]. Nadajnik (mysz) nie wie na jakiej sekwencji kanałów będzie mógł odbierać dane odbiornik, ponieważ ich zegary nie są jeszcze zsynchronizowane. Dlatego następuje wysyłanie 16 identycznych ciągów wiadomości (tzw. kodów DAC) na 16 różnych częstotliwościach, słuchając w przerwach czy nie nadchodzi odpowiedź. Jeśli nie otrzyma odpowiedzi wchodzi w stan uśpienia na 1,28 s. Po tym czasie wysyła wiadomości na kolejnych 16 częstotliwościach [27]. Czyli maksymalny czas po którym nastąpi komunikacja to 2,56 s. Aby odbiornik (komputer) poprawnie zinterpretował wiadomość, co 1,28 s. wykonuje procedurę PAGE SCAN (co pewien określony czas urządzenie nasłuchuje na jednym z 32 kanałów nadejścia swojego kodu 32 DAC). Po odbiorze własnego kodu DAC urządzenie (odbiornik) przechodzi w tryb PAGE RESPONSE, czyli pakiety potwierdzające, przesyłane są na tej samej częstotliwości na której zostały odebrane (bo nie ma jeszcze synchronizacji zegarów). Dopiero po odebraniu kodu DAC, wysłaniu potwierdzenia, otrzymaniu pakietu FHS1, wysłaniu kolejnego potwierdzenia, następuje synchronizacja zegarów [27]. Należy zauważyć, iż komputer w tej sytuacji pełni zarówno rolę Master (gdyż jest połączony z klawiaturą) i na krótko rolę Slave (dla myszy). Przyłączanie się nowych urządzeń do komputera, nie powoduje żadnej przerwy w istniejącym połączeniu pomiędzy komputerem a klawiaturą. Po synchronizacji zegarów, mysz przechodzi w stan w którym pełni rolę urządzenia Slave [27]. W momencie gdy mamy zestawione już połączenie, po opisanej powyżej operacji, każde kolejne urządzenie dołączając się do połączonych urządzeń staje się urządzeniem typu Slave tworząc tym samym pikosieć z jednym elementem nadrzędnym [27]. Rys.14 Pikosieć: Jedno urządzenie Master (M) i cztery urządzenia Slave (S) Pikosieć tworzona jest tylko wtedy, gdy istnieje potrzeba komunikacji między urządzeniami i wówczas gdy taka potrzeba zostaje zaspokojona, pikosieć przestaje istnieć. Dzięki mechanizmowi przeskoków po częstotliwościach możliwa jest sytuacja w której na jednym obszarze będą współistnieć dwie lub więcej pikosieci [27]. 1 Pakiet FHS - służy do synchronizowaniu zegarów i przekazania sekwencji przeskoków po kanałach 33 Rys.15 Dwie pikosieci mogą występować na jednym obszarze, nie zakłócając się nawzajem. Może się jeszcze zdarzyć sytuacja w której urządzenie w jednej pikosieci pełni rolę master a w drugiej pikosieci rolę Slave. Wówczas mamy do czynienia z połączeniem dwóch pikosieci w sieć zwaną scatternetem (siecią rozproszoną) [27]. Rys.16 Pikosieci mogą tworzyć sieci rozproszone (scatternet). Są dwa rodzaje połączeń w systemie Bluetooth, które można podzielić na: • SCO (Synchronous Connection Oriented) – protokół transmisji dźwięku • ACL (Asynchronous Connectionless Links) – protokół transmisji danych Transmisja dźwięku różni się od transmisji danych tym, że jest synchroniczna, jej pakiety nie zawierają CRC i nie są retransmitowane [27]. Pasmo podstawowe Bluetooth jest w 34 stanie równocześnie obsługiwać jedno łącze asynchroniczne dla transmisji danych i do trzech synchronicznych dla transmisji głosu (połączenia mogą być zestawione z tym samym lub różnymi urządzeniami Slave) [27]. SCO ACL asynchroniczna Transmisja synchroniczna symetryczna asymetryczna 721 kb/s w jedną Połączenie Do 3 równoległych kanałów po 433 kb/s w każdą stronę i 57,6 kb/s 64 kb/s w każdą stronę stronę w drugą. Tab.2 Przepustowość kanałów transmisyjnych Specyfikacja Bluetooth dzieli urządzenia na trzy klasy: • Klasa 1 - 100 mW, zasięg 100m • Klasa 2 - 2,5 mW, zasięg 10m • Klasa 3 - 1 mW, zasięg 1m Większość urządzeń należy do klasy 2 lub 3. Stos protokołów przedstawia poniższy rysunek. Rys.17 Stos protokołów Bluetooth 35 Jak widać na powyższym rysunku stos protokołów można podzielić na 3 grupy: • Grupa protokołów transportowych Zadaniem tej grupy protokołów jest zestawienie fizycznych i logicznych połączeń między urządzeniami, umożliwiają również wzajemną lokalizację. W skład tej grupy wchodzą: protokoły radiowe, protokoły pasma podstawowego, menedżera połączeń, kontrolera hosta i połączenia logicznego, a także HCI (interfejs kontrolera hosta) [8]. • Grupa protokołów pośredniczących Protokoły z tej grupy umożliwiają poprawną współpracę urządzeń Bluetooth z innymi standardami przemysłowymi. W skład tej grupy wchodzą: protokół emulujący port szeregowy (RFCOMM), protokół poszukiwania usług (SDP), protokół sterowania telefonem (TCS) [8]. • Grupa aplikacji (oprogramowanie) Jest to grupa, która nie ukazała się w specyfikacji. SIG nie zajmuje się tymi protokołami [8]. Celem pracy nie jest dogłębne przedstawienie protokołu jakim jest Bluetooth, jednak z uwagi na to że jest ważną częścią mojego projektu, wchodzącego w zakres tej pracy, wiedza na temat protokołów pośredniczących wydaje się niezbędna w celu dogłębnego zrozumienia zasady działania całej aplikacji. W części poświęconej praktycznej części pracy staram się omówić najważniejsze aspekty związane z tymi protokołami, jednak szczegółowe informacje na ten temat można znaleźć w oficjalnej specyfikacji Bluetooth [27]. 36 4 Symbian – system operacyjny 4.1 Informacja ogólne Każdy, nawet najprostszy model telefonu komórkowego posiada system operacyjny. Im bardziej zaawansowana konstrukcja, tym bardziej rozbudowany system. Telefon komórkowy można porównywać w pewien sposób do komputera. Posiada wyświetlacz, klawiaturę, pamięć, procesor. Zazwyczaj wszystko to rozmieszczone jest na kilku układach scalonych. Aby wszystko ze sobą współgrało niezbędny jest system operacyjny [30]. Większość systemów na telefon komórkowy ma zasadniczą wadę, otóż aplikacje przeznaczone dla jednego modelu nie działają na innym. Istniejący problem zmusił producentów telefonów do opracowania uniwersalnego systemu na który zostanie napisanych wiele aplikacji i w ten sposób telefony zyskają na popularności [30]. Pierwszym takim systemem jest Palm OS. Niestety telefony wyposażone w ten system straciły na „użyteczności”, gdyż przestały być intuicyjne w obsłudze, korzystanie z nich przypomina obsługę komputera. W chwili obecnej system ten jest używany zasadniczo na palmtopach (mały, przenośny komputer osobisty, w skrócie PDA) [30]. W 2000 roku na rynku pojawił się pierwszy model telefonu komórkowego z systemem Symbian 5.0 [30]. Rok później pojawił się już telefon z systemem Symbian 6.0, jednak o kompatybilności obu systemów nie było mowy. Dopiero w następnych modelach z Symbianem można docenić przenośność aplikacji pomiędzy różnymi komórkami [30]. W tej chwili na rynku jest już kilka wersji tego najpopularniejszego systemu operacyjnego przeznaczonego w głównej mierze na telefony komórkowe (ma zastosowanie również w PDA) [29]. Omawiam je w następnym podrozdziale. Od powstania Symbiana sprzedano już ponad 126 milionów aparatów w niego wyposażonych i z każdym dniem ta liczba rośnie [29]. Ze strony Microsoftu odpowiedzią na Symbiana był i jest do tej pory system Pocket PC: Phone Edition, jednak nie znalazł większego uznania gdyż podobnie jak Palm OS jest mało intuicyjny. Następca tego systemu, mowa o systemie z rodziny Windows Mobile jest już godnym konkurentem Symbiana. Jednak nie będę zajmował się omawianiem tego systemu z uwagi na to, iż nie wchodzi on w zakres mojej pracy. Informacje na jego temat można znaleźć na oficjalnej stronie Microsoftu http://microsoft.com. 37 4.2 Dlaczego Symbian? Można zadać pytanie dlaczego w swojej aplikacji użyłem telefonu komórkowego z systemem operacyjnym Symbian OS? Nim odpowiem na to pytanie pozwolę sobie zauważyć, iż inne systemy są równie dobre z punktu widzenia funkcjonowania telefonu komórkowego jako urządzenia sterującego innymi urządzeniami w Inteligentnym Budynku. Windows Mobile jest rozwiązaniem alternatywnym. Silnie wspieranym przez Microsoft i kreowanym na lidera systemów operacyjnych wśród telefonów komórkowych w przyszłości. Za Symbianem przemawiają jednak pewne liczby. Otóż warto wiedzieć, że w pierwszym kwartale 2007 roku sprzedano 15.9 milionów telefonów z Symbianem (wzrost o 35.9% w stosunku do pierwszego kwartału 2006) [29]. Obecnie dostępnych jest ponad 7478 różnego rodzaju programów dla tego systemu operacyjnego [29]. Na chwilę obecną istnieje już 55 różnych modeli telefonów opartych na Symbianie. System ten dominuje na rynku telefonów inteligentnych mając 70% udziałów, Linux ma 20% a Microsoft i Palm OS tylko 10% [29]. 4.3 Interfejsy w Symbianie Symbian OS dostarczany jest przez producenta z podstawowym interfejsem użytkownika. Producenci telefonów zmieniają go mniej lub bardziej modyfikując. W ten sposób powstały następujące wersje tego systemu [31]: • S60 (dostarcza najwięcej swoistych cech i rozwiązań spośród wszystkich rodzajów interfejsów) o S60 1 edycji (obecna w najstarszych modelach telefonów z Symbianem) o S60 2 edycji o S60 3 edycji (używana w najnowszym modelach Noki) • UIQ (przeznaczony dla urządzeń z dużym ekranem dotykowym, obsługiwanym przy użyciu rysika) o UIQ 2 edycji UIQ 2.0 (system wykorzystany w części praktycznej) UIQ 2.1 o UIQ 3 edycji UIQ 3.0 38 UIQ 3.1 • Series80 (urządzenia typu Communicator) – aktualnie nierozwijany • Series90 (tablety internetowe) – aktualnie nierozwijany • NTT DoCoMo's MOAP – dostępny tylko w Japonii 4.4 SDK i dostępne IDE pod Symbiana SDK to zestaw narzędzi, plików danych, programów, które pozwalają na tworzenie oprogramowania. Dla różnych wersji Symbiana jak i dla różnych wersji interfejsu użytkownika istnieją różne, osobne SDK [29]. Do poprawnego działania każde SDK potrzebuje: • Active Perl • JRE W większości dostępnych wersjach instalacyjnych zawiera w sobie potrzebne komponenty. Każde SDK zawiera również emulator systemu operacyjnego Symbian. Emulator jest kompilacją całego systemu operacyjnego Symbian dla Windows. Większość funkcji korzystających bezpośrednio z zasobów udostępnianych przez telefon zostało zastąpionych analogicznymi funkcjami z Windows. Napisałem większość, gdyż obsługa Bluetooth czy IrDA jest niestety pominięta. Aby generować kod wykonywalny programu który chcemy uruchomić na komórce, potrzebny jest oczywiście kompilator. W przypadku Symbiana kod wykonywalny na telefon kompilowany jest przez darmowy gcc. Warto jeszcze powiedzieć o tym, że SDK dostarczane jest w kilku wersjach w zależności jaki kompilator został użyty do skompilowania emulatora [29]: • WINS – kod jest generowany przez Microsoft Visual Studio • WINSCW – kod jest generowany przez Code Warriora Stworzenie całego projektu od samego początku byłoby rzeczą bardzo pracochłonną [31]. Z pomocą programistom przychodzą narzędzia do ich automatycznego generowania. Samo SDK nie dostarcza tzw. wizardów, które potrafią tworzyć aplikacje. Jednak praktycznie każde narzędzie IDE, na którym można kompilować kod dla Symbiana potrafi ekspresowo stworzyć aplikację, która może być punktem wyjścia dla naszego programu [31]. Wszystkie dostępne IDE wymieniam w tabeli numer 3. 39 Środowisko Komercyjny Microsoft Visual C++ (6.0, TAK Debugowanie na telefonie NIE 7.0, 2005) Microsoft Windows SDK CodeWarrior NIE for TAK SymbianOS NIE TAK w wersji Professional i OEM Carbide C++ Express NIE NIE Borland C++ Builder X TAK/darmowy w wersji 1.5 NIE Tab3. Środowiska programistyczne pod Symbiana (IDE) 4.5 Podstawy Symbiana (różnice pomiędzy Symbianem a C++) Nie ulega wątpliwości, że programowanie w C++ pod Symbianem jest podobne do programowania w C++ pod inne systemy jak np. Windows [31]. Oczywiście różnice są i staram się je pokazać w następnych podrozdziałach. 4.5.1 Podstawowe typy danych W trochę zmienionej formie istnieją int, long czy real. Zabieg taki ma na celu uchronić programistę przed różnymi kompilatorami. Pisząc programy na Symbiana zamiast klasycznych typów danych, tj.: int, char używa się TInt, TChar, itp., typy które są zdefiniowane w standardowych plikach nagłówkowych Symbiana [1]. Podstawowe typy, to: • sized - znany jest ich dokładny rozmiar (np. TInt8) • unsized - nieznany jest ich dokładny rozmiar (np. TInt) Prawdziwe wielkości typów określanych jako unsized mogą zmieniać się zależnie od kompilatora, wówczas gdy te określane jako sized prawa takiego nie mają [31]. Typy signed mają liczbę bitów w nazwie, dzięki temu w łatwy sposób można je zidentyfikować[1]. Warto wiedzieć o typie TBool którego wartościami mogą być: ETrue i EFalse. Wszystkie typy danych umieściłem w tabeli numer 5 [1]. 40 Nazwa: TInt TUint TInt8 TInt16 TInt32 TUInt16 TUInt32 TReal TReal32 TReal64 TRealX TText TText8 TText16 Typ: Integer Unsigned integer Integer Integer Integer Unsigned Integer Unsigned Integer Real Real Real Real Character Character Character TChar Character TBool ETrue lub EFalse TAny Używane jako TAny* Tab.4 Podstawowe typy danych w systemie Symbian Rozmiar: przynajmniej 32 bity przynajmniej 32 bity 8 bitów 16 bitów 32 bity 16 bitów 32 bity przynajmniej 64 bity przynajmniej 32 bity przynajmniej 64 bity rozszerzona precyzja przynajmniej 16 bitów (unicode) przynajmniej 8 bitów (ascii) przynajmniej 16 bitów przynajmniej 32 bity (extended unicode ) 32 bity 4.5.2 Nazewnictwo klas Konwencja nazw, czyli tak na prawdę system przedrostków jest ważnym elementem całego systemu. Dzięki temu, w bardzo łatwy sposób można dowiedzieć się jakie funkcje pełni obiekt danej klasy [1]. Pierwsze litery w nazwach klas wskazują podstawowe jej własności. Ze względu na ten podział można rozróżnić następujące typy klas: • Klasy T. Są to proste klasy nieposiadające ani konstruktora ani destruktora. Pamięć dla obiektów tych klas jest alokowana na stosie. Przykładami takich klas są: TDesC, TPoint, TFileName [1]. Podczas programowania dla Symbiana obiekty tych klas pojawiają się niemal na każdym kroku. • Klasy C. Każda taka klasa dziedziczy z CBase i obiekt tej klasy zawsze jest alokowany na stercie. Klasy C posiadają zarówno konstruktor jak i destruktor. Konstruktor z klasy nadrzędnej (klasy CBase) dba o to, by wszystkie pola znajdujące się w klasie odpowiednio wyzerować [1]. Przykładami tej klasy są: CConsoleBase, CActive, CBase. 41 • Klasy R. Obiekty tej klasy mają dostęp do zewnętrznych zasobów, tj.: plików, gniazd sieciowych, itp. Zazwyczaj wykorzystywane są w aplikacjach typu KlientSerwer, jednak nie jest to regułą [1]. Zazwyczaj posiadają funkcje: o przydzielające pamięć (Open(), Create(), Allocate(), itp.) o zwalniające pamięć (Close(), Destroy(), Free(), itp.) Przykładami tej klasy są: RFile, RTimer, RWriteStream. • Klasy M. Klasy abstrakcyjne, które posiadają jedynie metody wirtualne. Ich implementacja pojawia się dopiero w klasach z niej dziedziczących [1]. Przykłady takich klas to: MGraphicsDevice-Map, MEikMenuObserver. Warto jeszcze wiedzieć, że obowiązują również konwencje w nazewnictwie nazw obiektów [1]. • E – używany przy typach wyliczeniowych (np. Eteru, EFalse, EMonday, itp.) • K - Używany przy stałych (np. KErrNone, KMaxFileName) • i – Zmienne jako pola w klasach • a – Zmienne deklarowane jako argumenty w funkcjach. 4.5.3 Łańcuchy tekstowe i deskryptory Można powiedzieć że jest to specjalność Symbiana. Jednak niestety nie jest to takie proste jak w C, gdyż wszystko wygląda o wiele bardziej skomplikowanie. Wyróżnić można 5 typów deskryptorów: • TBuf • TBufC • TPtr • TPtrC • HBufC Jak widać niektóre nazwy zakończone są literą C, otóż oznacza to, że taki deskryptor jest stały, o określonej stałej długości i wszystkie jego funkcje są typu const (ang. constans). Dane przechowywane przez jakikolwiek deskryptor mogą znajdować się we wszelkich możliwych rodzajach pamięci (ROM, RAM, stos, sterta) [31]. 42 • TBuf i TBufC - patrząc na te deskryptory z perspektywy języka C, można powiedzieć, że są to tak naprawdę tablice stringów (łańcuchy tekstowe). W nomenklaturze „symbianowej” mówi się o nich, że są to deskryptory bufora. Dane stanowią część obiektu deskryptora, który umieszczony jest na stosie. Jak widać na rysunku numer 18, długość tych tablic ustawia się za pomocą specyficznych „widełek”. TBufC<5> helloStack(„hello”); Tak jak pisałem wcześniej, na takim obiekcie można wywołać jedynie funkcje typu const. Jeśli mielibyśmy następującą definicję: TBuf<5> helloWorld(„hello”); ,wówczas taki bufor jest modyfikowalną tablicą stringów, gdzie można bez problemów modyfikować tekst (np. metodą Append()). • HBufC są to deskryptory sterty, dane stanowią część obiektu deskryptora, który umieszczony jest na stercie. • TPtr i TPtrC to deskryptory wskaźnika, gdzie obiekt deskryptora oddzielony jest od danych. [1]. Rysunek numer 18 przedstawia hierarchie możliwych deskryptorów w Symbianie. Rys18. Typy deskryptorów w Symbianie 43 TDesC i Des są klasami abstrakcyjnymi. Z tego względu mogą zostać wykorzystane tylko jako argumenty funkcji, których celem są dowolne działania na łańcuchach tekstowych bądź innych danych [31]. Wszystkie deskryptory posiadają kilka odmian (TDesC8, TDesC16, TBuf8, TBuf16, TDes8, TDes16, itp.). Liczba w nazwie informuje o tym ilu bitowymi danymi może operować dany deskryptor [1, 31]. 4.5.4 Mechanizm opuszczeń (Leaves) Jest to jeden z najważniejszych mechanizmów Symbiana. Litera L na końcu nazwy funkcji informuje, że dana funkcja może zgłosić opuszczenie W większości współczesnych języków programowania istnieje możliwość obsłużenia błędów (tak jak się to dzieje np. w Javie, gdzie obsługa błędów odbywa się za pomocą konstrukcji try-catch) lub przekazania ich na wyższy poziom hierarchii wywołań [34]. W Symbianie jest to rozwiązane przez konstrukcję Leave-Trap (w wolnym tłumaczeniu, opuszczenie-złapanie). Opuszczenie (symbianowy odpowiednik wyjątku) może się zdarzyć w wielu sytuacjach. Dobrym przykładem może być brak pamięci na załadowanie grafiki lub nie znalezienie potrzebnego pliku [34]. Najczęściej nie obsługuje się własnoręcznie błędu, gdyż przekazuje się go po prostu systemowi, który wyświetli stosowny komunikat [1]. Jednak można zaimplementować odpowiednią obsługę błędu za pomocą stosownej pułapki (instrukcji TRAP). Wówczas gdy wyrzucamy wyjątek, sterowanie programu przechodzi do miejsca „najbliższego TRAPa” [31]. Czyli można to nazwać złapaniem wyjątku. W tym momencie wywoływane są destruktory obiektów, których wskaźniki odłożone są na Cleanup Stacku2 (oczywiście tylko tych obiektów, które stworzyliśmy po wejściu do TRAP) [31]. Jeżeli wskaźnika obiektu, który zaalokował pamięć, nie ma na tym stosie, nie mamy już możliwości usunięcia tego obiektu w żaden sposób i w tym momencie pamięć zajmowana przez ten obiekt jest tracona (czyli mamy do czynienia z klasycznym wyciekiem pamięci) [31]. Aby przeciwdziałać takim wyciekom pamięci, wskaźnik nowo utworzonego obiektu powinno się odkładać na Cleanup Stacku [31]. Mechanizm opuszczania jest o tyle ważny, że firma Symbian stworzyła bardzo przydatny program sprawdzający, czy konwencja nazewnictwa jest przestrzegana w plikach 2 Cleanup Stack - stos wskaźników do obiektów. Więcej na jego temat można znaleźć w literaturze [1]. 44 źródłowych projektu [34]. Nazwa tego narzędzia to LeaveScan i jest nawet wbudowane w niektóre wersje SDK. 5 Projekt 5.1 Idea projektu Idea całego projektu oparta jest o komunikację pomiędzy urządzeniami znajdującymi się w budynku przy wykorzystaniu protokołu Bluetooth. W moim przypadku jest to telefon komórkowy, komputer PC i urządzenie LPC2104 Color LCD Game Board. Równie dobrze mogłyby to być inne urządzenia, jednak z uwagi na posiadanie wyżej wymienionych urządzeń zdecydowałem się na skorzystanie właśnie z nich. Celem pracy było skonstruowanie takiego systemu, w którym człowiek posiadający „klucz” ( w moim projekcie jest to telefon komórkowy ) będzie mógł sterować innymi urządzeniami w budynku. Bardzo ważną rzeczą jest to, iż użytkownik mając telefon komórkowy, po wejściu w zasięg Bluetootha konkretnego urządzenia nawiąże z nim automatycznie połączenie i wysyłając stosowne polecenia zrealizuje z góry przypisane mu zadanie. Natomiast jeśli opuści zasięg danego urządzenia, urządzenie również musi zareagować w pewien ustalony sposób. Cała ta operacja ma się odbyć bez ingerencji osoby posiadającej klucz. Można sobie wyobrazić sytuację, w której podjeżdżamy samochodem do swojego domu, a dokładniej pod bramę swojej posesji i bez jakiejkolwiek reakcji z naszej strony brama otwiera się. Po wjechaniu samochodem, opuszczeniu garażu, brama automatycznie ma się zamknąć. Oczywiście warto sobie zadać pytanie na jakiej zasadzie brama nas słucha, czy każdy może otworzyć i zamknąć naszą bramę. Na to pytanie odpowiem w dalszej części pracy, gdyż jest to bardzo ważny aspekt patrząc na to z punktu widzenia bezpieczeństwa (rozdz. 5.2.1.7). Idea całego projektu jest więc bardzo przejrzysta. Wszystkie komunikujące się urządzenia posiadają Bluetootha, dzięki któremu następuje wymiana danych. Całe zagadnienie dobrze ilustruje rysunek numer 19. 45 Rys.19 Idea projektu [11] 5.2 Budowa projektu Projekt powinien składać się z 3 odrębnych aplikacji. Jeden napisany na telefon komórkowy z systemem Symbian 7.0 z interfejsem UIQ 2.0. Drugi napisany na komputer klasy PC. A trzeci zaimplementowany na LPC2104 Color LCD Game Board. Niestety musiałem zrezygnować z wdrożenia Game Board’a do działającej sieci urządzeń. Powodem była niekompatybilność stosów Bluetooth dla tego urządzenia i telefonu komórkowego. Sytuacja z którą się zetknąłem jest dosyć skomplikowana. Otóż istnieją dwie procedury zapytań o serwisy (przypomnę tylko że łącząc się z urządzeniem Bluetooth tak naprawdę łączymy się z jakimś serwisem dostępnym na tym urządzeniu) [39]. Jedna procedura to SDP_ServiceSearchAttributeRequest, a druga SDP_ServiceSearchRequest [39]. Problem polega na tym, iż urządzenie Game Board umie obsługiwać tylko pierwsze zapytanie, czyli SDP_ServiceSearchAttributeRequest. Niestety telefon komórkowy wykorzystuje drugą procedurę do odszukania serwisu i w ten sposób dochodzi do braku kompatybilności. Problem można by było rozwiązać używając innego modelu telefonu komórkowego (przynajmniej wszystko na to wskazuje), jednak nie zdecydowałem się na taki krok, gdyż wiązałoby się to z dosyć dużym nakładem finansowym. 46 5.2.1 Aplikacja na telefon komórkowy 5.2.1.1 Budowa i elementy składające się na aplikację Jeśli chodzi o budowę napisanej przeze mnie aplikacji to jest ona zgodna z wszelkimi zasadami które obowiązują w tworzeniu tego typu programów i dlatego na podstawie tej aplikacji omówię jednocześnie budowę typowych aplikacji na system operacyjny Symbian OS. Na poniższym rysunku prezentuję budowę takiej właśnie aplikacji, połączenia między jej elementami, oraz przepływ informacji. Rys.20 Budowa typowej aplikacji na Symbian OS Podstawowe elementy składające się na aplikację niezależnie od używanej wersji SDK są widoczne na rysunku numer 20 i są następujące: • Aplikacja – jest to podstawowy element, który pozwala na wykorzystanie biblioteki Uikon. Zawiera również interfejs do plików z zasobami, oraz tworzy dokument. Klasa aplikacji dziedziczy z klasy CQikApplication. (Dla programu pisanego pod telefon komórkowy z interfejsem S60, klasa ta powinna dziedziczyć z klasy CAknApplication) [1] • Dokument – jest to pośrednia warstwa pomiędzy kontrolerem i modelem a plikiem, z którego korzysta model. Dokument tworzy kontroler aplikacji (APP UI). Klasa dokumentu dziedziczy z CQikDocument (dla S60 dziedziczyłaby z klasy 47 CAknDocument). Tak naprawdę dokument wykorzystywany jest tylko do tworzenia kontrolera. Dzieje się tak w wypadku gdy aplikacja nie zapisuje i odczytuje danych z systemu plików [31]. • Kontroler (APP UI) – jest to element który obsługuje wszystkie sprawy związane z interfejsem użytkownika, takie jak: menu, paski narzędziowe, kończenie aplikacji, itp. Kontroler odpowiedzialny jest za obsługę komend wysyłanych z menu, a także za współpracę z serwerem okien [31]. Kontroler dziedziczy po klasie CQikAppUi (dla S60 byłaby to klasa CAknAppUi). • Model – jest to klasa która odpowiedzialna jest za mechanizm działania aplikacji. Model powinien być tworzony przez dokument, a kontroler i widok aplikacji powinny mieć do niego bezpośredni dostęp (poprzez referencję lub wskaźnik). • Widok – odpowiada za prezentację danych dla użytkownika oprogramowania [1]. Widok prezentuje specyficzne ujęcie danych w modelu i posiada bezpośredni dostęp do modelu, żeby wizualizować dane w nim zawarte. (Aplikacja może posiadać wiele widoków, przykładowo kalendarz ma widok tygodnia, miesiąca, roku.) Klasa widoku dziedziczy bezpośrednio po klasie CCoeControl. (W przypadku S60 byłaby to klasa CAknView). 5.2.1.2 Struktura katalogów projektu Po utworzeniu nowego projektu, w określonym przez użytkownika miejscu na dysku tworzy się struktura katalogów charakterystyczna dla projektów Symbiana. W zależności od użytego wizarda ta struktura może się nieznacznie różnić. Zarówno moja struktura jak i standardowa struktura aplikacji składa się z następujących katalogów [1, 31]: • Group - tutaj znajdują się najważniejsze pliki wchodzące w skład całego projektu. Są to: plik MMP określający zawartość projektu (.mmp), plik RRS z zasobami (.rss), oraz plik definicji komponentów (bld.inf) • Inc - w tym katalogu znajdują się wszystkie pliki nagłówkowe aplikacji (.h), pliki z typami numerycznymi projektu (.hrh), pliki definiujące kody Panic codes (.pan), oraz plik adresów dla plików binarnych dla komponentów interfejsu użytkownika (generowany automatycznie - .rsg) • Src - tutaj znajdują się wszystkie pliki źródłowe projektu (.cpp) 48 • Sis - w tym katalogu znajduje się plik .pkg określający wersję instalacyjną programu na telefon, służący do tworzenia pliku instalacyjnego dla aplikacji (.sis) 5.2.1.3 Podział aplikacji na podstawowe pliki Każda aplikacja dla systemu operacyjnego Symbian, z punktu widzenia podziału na podstawowe pliki składa się z [1, 31]: • Plik APP – w pliku tym znajduje się skompilowany kod aplikacji, jest to biblioteka polimorficzna udostępniająca tylko jedną funkcję tworzącą instancję aplikacji. Jest to niezbędny plik do działania całej aplikacji [1]. Warto wiedzieć, że po skompilowaniu całego projektu w CodeWarrior plik ten jest tworzony w specyficznym miejscu na dysku. Ścieżka katalogu w którym tworzone są pliki tego typu jest następująca: C:\Symbian\UIQ_70\epoc32\release\armi\urel\CLIENTBT.APP • Plik RSC – zadaniem tego pliku jest dostarczanie informacji o zasobach w trakcie działania aplikacji. Chodzi o to, żeby podczas działania programu nie ładować wszystkich zasobów do pamięci, a tylko te które są aktualnie potrzebne [31]. W ten sposób następuje oszczędność pamięci, gdyż niezbędne zasoby są „doładowywane” wtedy, gdy są potrzebne. Plik ten zawiera wszystkie zasoby związane z językiem aplikacji (definicje komponentów interfejsu, napisy używane w programie, itp.) Bardzo dużą zaletą tego pliku jest fakt, że można go podmienić bez konieczności ponownej kompilacji całej aplikacji [31]. Można więc zrobić kilka plików z różnymi wersjami językowymi i podczas uruchomienia programu ładować odpowiedni język (w zależności od wyboru użytkownika). Plik ten jest niezbędny do działania całej aplikacji. Ścieżka katalogu w którym tworzony jest taki plik jest następująca: C:\Symbian\UIQ_70\epoc32\data\z\system\APPS\CLIENTBT\ClientBT.RSC • Plik AIF – służy do przetrzymywania podstawowych informacji o aplikacji takich jak ikony, obsługiwane typy MIME, itp. • Plik MBM – przechowuje dowolną ilość ikon, które podczas działania programu mogą zostać załadowane i wyświetlone w postaci zwykłych obrazków czy przycisków. 49 5.2.1.4 Rodzaje plików w projekcie Rodzaje plików w projekcie są następujące: • plik MMP, który określa zawartość projektu. Definiuje on typ projektu (aplikacja wykonywalna, biblioteka itp.), plik z zasobami, pliki z kodem C++, użyte biblioteki, język, ścieżki systemowe, ścieżki do plików nagłówkowych, itp.. Określa także identyfikator aplikacji (UID), o którym więcej pisze w rozdziale 5.2.1.5. W mojej aplikacji plik ten nosi nazwę ClientBT.mmp. • Plik Bld.inf – definiuje komponenty wchodzące w skład projektu. Wszystkie pliki MMP, które wchodzą w skład aplikacji są wymienione w tym pliku [31]. W moim przypadku jest to tylko jeden plik. W pliku tym powinny być również wpisy z nazwami używanych bibliotek dynamicznych (plików DLL), jeżeli takich używamy [1]. Z punktu widzenia budowania aplikacji, a także budowania pliku instalacyjnego plik ten jest niezbędny. • Plik RSS – jest to plik zasobów aplikacji. Tutaj zdefiniowane i umieszczone są wszystkie definicje komponentów użytkownika (menu, dialogi, itp.). Aplikacja używa tego pliku do zbudowania aktualnie wymaganego komponentu podczas działania programu. • Plik HRH - zawiera typy numeryczne wykorzystywane w aplikacji. Mówiąc bardziej „obrazowo”, to tutaj zdefiniowane są typy numeryczne m.in. dla opcji z menu. • Pliki CPP i H – pliki źródłowe projektu. Omawiając wszystkie pliki nie można zapomnieć o pliku instalacyjnym, o którym już wcześniej wspomniałem. Jest to plik który umożliwia zainstalowanie aplikacji na telefon komórkowy. 50 Rys.21 Proces powstawania pliku SIS [http://developer.uiq.com/devlib/uiq_30/SDKDocumentation/sdl/N10012/3-building.html] Do utworzenia pliku instalacyjnego niezbędny jest plik PKG, w którym definiuje się przede wszystkim ścieżki źródłowe jak i docelowe dla pliku APP i RSC. Mając dobrze zdefiniowany taki plik, używając programu MakeSIS.exe wbudowany w każde SDK otrzymujemy niepodpisany plik instalacyjny. Na tym etapie można już poprzestać, gdyż telefony komórkowe wyposażone w Symbian 7.0 i starsze nie wymagają podpisywania tych plików. Niestety telefony z Symbianem nowszym od 7.0 wymagają tej operacji. 5.2.1.5 System identyfikatorów UID Każdy plik wykonywany w systemie Symbian OS jest identyfikowany przez dwa identyfikatory (są to liczby 32 bitowe bez znaku), które dokładnie identyfikują dany plik [1]. Pierwszy identyfikator określa typ pliku i przykładowo dla wszystkich tzw. GUI aplikacji jest on określony liczbą 0x100039ce. Drugi powinien być nabyty bezpośrednio od firmy Symbian. Można to zrobić a nawet trzeba wysyłając maila na adres [email protected] o tytule „UID request”, w treści podając ile chce się nabyć identyfikatorów [1]. Ja jednak skorzystałem z eksperymentalnych identyfikatorów, które są udostępnione przez Symbiana. Ich zakres wynosi od 0x01000000 do 0x0fffffff. To pozwala Symbianowi na odróżnienie plików powiązanych z tą daną aplikacją od plików skojarzonych z inną aplikacją [1]. 51 5.2.1.6 Zasada działania aplikacji Aby móc zagłębić się w szczegóły implementacyjne zarówno po stronie klienta (aplikacja na telefonie komórkowy) jak i serwera (aplikacja na komputerze PC) trzeba zaznajomić się dosyć szczegółowo z protokołem Bluetooth. Jak powszechnie wiadomo w aplikacjach klient – serwer, klient żąda od serwera wykonania pewnych usług. Mówiąc o usługach, trzeba wprowadzić bardzo ważne pojęcie jakim jest serwis, słowo którego używałem wcześniej, a w specyfikacji Bluetooth pojawia się niemal od samego początku. Najkrócej mówiąc serwis jest usługą realizowaną przez serwer. Pierwszą rzeczą jaką należy poruszyć omawiając moją aplikację pod Symbianem pod względem implementacji jest nawiązanie połączenia pomiędzy dwoma urządzeniami. Nim nastąpi połączenie, wcześniej realizowanych jest kilka bardzo ważnych zadań. Podstawowe działania klienta zmierzające do nawiązania połączenia z serwerem można podzielić na: • Odszukanie urządzenia z którym klient chce nawiązać połączenie (Device Discovery) • Odszukanie serwisów działających na znalezionym urządzeniu (Service Discovery) • Pobranie URL serwisu Odszukanie urządzenia jest o tyle ułatwione, iż znam wszystkie urządzenia z którymi mogę i mam możliwość nawiązania połączenia. Dlatego w swojej aplikacji używam specjalnej struktury (TBTDevAddr tabDevices []), która zawiera adresy MAC urządzeń z którymi mogę się połączyć. Do odszukiwania serwisów na zdalnym urządzeniu używam obiektu klasy CSdpAgent. Obiekt ten można nazwać agentem, który wykorzystuje do wyszukania serwisów Service Discovery Protocol (SDP), który omawiam w rozdziale 5.2.1.8. Zgodnie z profilem zastosowań SDP, aplikacja wyszukująca usługi na urządzeniu zdalnym powinna obsługiwać trzy rodzaje zapytań o usługi: • Szukanie usług należących do danej klasy usług, • Szukanie usług o podanych atrybutach, • Przeszukiwanie dostępnych usług. 52 Skorzystałem z pierwszej funkcjonalności jaką daje profil zastosowań SDP, czyli szukanie usług należących do danej klasy usług. Obiekt CSdpAgent posiada wiele różnorodnych funkcji. Chcę wspomnieć tylko o dwóch które z punktu widzenia uruchomienia całego mechanizmu szukania serwisów są kluczowe. Jedna z nich to SetRecordFilterL( CSdpSearchPattern pattern ), która to właśnie ma możliwość ustawienia klasy usługi którą chcemy znaleźć [35]. W mojej aplikacji klasa usługi którą szukam to „Serial Port” (Dlaczego akurat takiego serwisu szukam piszę w rozdziale 5.2.4). Każda taka klasa ma przypisaną 16 bitową liczbę (tzw. UUID o którym szerzej napiszę w rozdziale 5.2.1.7), Dla ścisłości, usługa Serial Port jest określona przez liczbę 0x1101. Drugą funkcją jest NextRecordRequestL(), która jest asynchroniczną funkcją inicjalizującą szukanie (można powiedzieć że zwraca „uchwyt” do serwisu) [35]. Po ukończeniu tej funkcji, zostaje wywołany ciąg innych funkcji, które doprowadzają do stanu w którym telefon komórkowy albo nawiąże połączenie z urządzeniem peryferyjnym albo nie. Jak wygląda kwestia związana z bezpieczeństwem nawiązywania połączenia? Otóż oparłem się o znany i zaimplementowany już mechanizm „parowania” urządzeń (Bluetooth Pairing). Aplikacja jest napisana w ten sposób, że parowanie urządzeń wymusza serwer, który może pracować w 3 trybach zabezpieczeń (niskim, średnim i wysokim), ale o tym piszę szerzej w rozdziale poświęconym aplikacji serwera (rozdział 5.2.2). Wspomnę tylko, iż uruchamiając serwer należy włączyć średni tryb zabezpieczenia, którego zadaniem jest wymuszanie wymiany tego samego klucza hasła po obydwu stronach połączenia jeśli dwa urządzenia są łączone po raz pierwszy lub jeśli występuje brak zaufanych relacji pomiędzy dwoma urządzenia. Po tej wymianie klucze haseł nie będą już wymagane do dalszej komunikacji pomiędzy urządzeniami. 53 Rys.22 Wymiana klucza po stronie klienta Przyjmując że operacja nawiązania połączenia powiodła się, wówczas automatycznie zostaje wysłane określone polecenie do zdalnego urządzenia. Po poprawnym wysłaniu tego polecenia i odebraniu potwierdzenia, połączenie zostaje zakończone. Dzieje się tak, gdyż musi być możliwość łączenia się z innymi urządzeniami, które znajdą się w zasięgu naszego „klucza”. Po udanym nawiązaniu połączenia i wysłaniu stosownego komunikatu, nie można skorzystać z sytuacji, w której połączenie byłoby utrzymywane w sposób „sztuczny” (np. za pomocą mechanizmu znanego jako „keep-alive”), co byłoby z jednej strony bardzo wygodne, gdyż po automatycznym wysłaniu jednego komunikatu, byłaby możliwość wysyłania innych. Jednak w takiej sytuacji byłby ogromny problem z obsłużeniem więcej niż jednego urządzenia znajdującego się w zasięgu użytkownika posiadającego „klucz”. Z założenia wynika, że w pomieszczeniu może znajdować się większa ilość urządzeń peryferyjnych i dlatego zdecydowałem się na wariant z każdorazowym wykonywaniem funkcji „Disconnect”, aby umożliwić poprawną pracę całego systemu. Można sobie zadać pytanie, co nastąpi jeśli będziemy przebywać w otoczeniu aktywnego urządzenia Bluetooth przez dłuższy okres czasu. Czy polecenie zostanie wysłane bliżej nieokreśloną ilość razy? Odpowiedzią jest oczywiście nie. Aplikacja sprawdza czy polecenie zostało już wysłane w czasie przebywania w zasięgu danego urządzenia. Jeśli tak, wówczas następuje wysyłanie komunikatów informujących o tym, że polecenie zostało wykonane i ponowny komunikat zostanie wysłany tylko wtedy gdy opuścimy 54 zasięg działania tego urządzenia i z powrotem się w nim pojawimy. Jeśli urządzenie sterujące opuści zasięg urządzenia z którym miało połączenie i wymieniało komunikaty, wówczas następuje powiadomienie o tym po stronie urządzenia aktywnego (peryferyjnego). . 5.2.1.7 Bezpieczeństwo W opisie idei projektu, wspomniałem o kwestii bezpieczeństwa związanej z działaniem aplikacji przeznaczonej na telefon komórkowy, obsługującej otwieranie bramy garażowej. Otwieraniem bramy zajmuje się aplikacja na komputerze PC. Pytanie, które zadałem we wstępnej części rozdziału 5.1 brzmi, czy każdy może otworzyć moją bramę do garażu (korzystając z urządzenia z Bluetooth). Oczywiście nie każdy może otworzyć bramę. Aby móc dokonać takiej operacji, po pierwsze zdalne urządzenie musi znać format polecenia (pisze o nim w rozdziale 5.2.2), a po drugie zdalne urządzeni musi być „sparowane” z komputerem PC. Na czym polega ta operacja? Proces „sparowania” polega na wygenerowaniu klucza inicjalizacyjnego i użyciu go do uwierzytelnienia urządzeń. Rezultatem jest utworzenie dla nich stałego klucza połączenia. Klucz ten generowany jest poprzez wprowadzenie w obu urządzeniach kodu PIN, który z kolei generuje klucz tymczasowy. (Ani klucze ani PIN nie są przesyłane drogą radiową w formie otwartego tekstu). Wygenerowane w ten sposób klucze tymczasowe muszą być sobie równe [27]. Pisząc ten projekt założyłem że jeśli dwa urządzenia nawiązują ze sobą po raz pierwszy połączenie, wówczas wymuszana jest wspomniana operacja „sparowania”. Z opisu wynika, że wiąże się to z manualnym wpisaniem hasła zarówno po stronie klienta jak i serwera. I tak właśnie się dzieje. Zdaję sobie sprawę z tego, że zabezpieczenie na poziomie „sparowania” urządzeń komunikujących się nie jest jakimś wyrafinowanym rozwiązaniem i w rzeczywistości dla osoby próbującej złamać klucz „sparowania” nie jest rzeczą trudną złamanie takiego klucza. Używając ogólnie dostępnego oprogramowania pod nazwą BTCrack, złamanie najdłuższego klucza to kwestia kilkudziesięciu sekund. Wspomniany program opiera się na brutalnym ataku, analizując przechwycone pakiety. Dla celów demonstrujących szybkie łamanie klucza, program można ściągnąć ze strony http://nruns.com/_en/security_tools.php Dlatego też, chcąc w lepszy sposób zabezpieczyć się przed atakami, nadmieniam w jaki sposób można lepiej to zrobić, zabezpieczając komunikację. Otóż rozwiązaniem jest 55 dodanie szyfrowania na poziomie protokołu komunikacyjnego. Szyfrowanie , które w znaczący sposób poprawi bezpieczeństwo komunikacji może opierać się o znane algorytmy szyfrowania, takie jak MD5, czy SHA2. Warto byłoby wymusić uwierzytelnianie, które mogłoby dokonywać się przy każdorazowym przesyłaniu komunikatów, przykładowo mogłaby być wykonywana taka operacja: LOGIN + MAC address klienta MD5 -- -- -- -- -- -- -- -- KLIENT Klient posiadając bazę loginów, odszyfrowując komunikat, dopuszczałaby do wymiany danych lub nie. Taki sposób zapewniłby znacznie lepszą ochronę niż mechanizm „sparowania” urządzeń. 5.2.1.8 Identyfikator UUID Celem było stworzenie takiego identyfikatora, który mógłby jednoznacznie identyfikować informację w systemach rozproszonych, bez używania centralnej bazy danych umożliwiających ich przechowywanie. Cel został osiągnięty wprowadzając standard uniwersalnie unikatowego identyfikatora jakim jest UUID, który jest 128 bitową pseudolosową liczbą [37]. Oczywiście od razu powstało wiele algorytmów generowania tych liczb. Prawdopodobieństwo wygenerowania dwóch takich samych identyfikatorów jest bliskie zeru, pozwolono zredukować go do 32-cyfrowej liczby szesnastkowej gdyż jest to wystarczająco długa liczba by nie pozwolić na dwa takie same identyfikatory [37]. Zaistniała potrzeba zarezerwowania pewnej liczby identyfikatorów na potrzeby Bluetooth SDP, SIG (o której pisałem w rozdziale o Bluetooth) postanowiła zdefiniować krótsze UUID aby ułatwić urządzeniom używanie identyfikatorów często używanych usług [37]. Wobec tego powstały identyfikatory 16- i 32-bitowe UUID. Oczywiście z krótkich UUID można wyliczyć długie, 32-bitowe. 56 5.2.1.9 Protokoły wyszukiwania usług Powstało wiele protokołów wyszukiwania usług. Różnią się między sobą, gdyż są przeznaczone do stosowania w różnych urządzeniach i w różnych środowiskach. Najpopularniejsze protokoły są następujące: • SLP2 (Service Location Protocol, Version 2) – jest to najpowszechniejszy protokół wyszukiwania usług. Jest w stanie obsłużyć bardzo rozbudowane sieci dzięki zastosowaniu katalogu usług [36]. Aplikacja poszukująca usług nazywana jest „User Agent”, dostawcą usług jest „Service Agent”, a „Direktory Agent” pełni rolę katalogu usług [36]. W niedużych sieciach można pominąć katalog usług, wówczas zapytanie od „User Agent’a” wysyłane jest multicastowo do wszystkich „Service Agent’ów”. Jednak jeśli „User Agent” ma świadomość istnienia w sieci katalogu usług, wtedy zapytanie wysyła tylko do „Direktory Agent’a” (unicast) [36]. Więcej na temat tego protokołu można dowiedzieć się ze strony www.openslp.org. • Jini – technologia, która jest rozszerzeniem języka Java na systemy rozproszone. Każde urządzenie działające w tym środowisku umie interpretować kod Java. Nawet jeśli nie potrafi, wówczas ma swojego Proxy, który zrobi to za niego [38]. Więcej o tym protokole można dowiedzieć się ze strony www.jini.org • Salutation – można powiedzieć że jest to mechanizm wykrywania i uzyskiwania dostępu do usług w dużych sieciach o zróżnicowanym medium. W tej technologii występuje pośrednik między klientem a usługą, tzw. Salutation Manager (SLM) [33]. Każdy klient chcący skorzystać z jakiejkolwiek usługi musi wysłać zapytanie do lokalnego SLM (najczęściej znajduje się on fizycznie na tej samej maszynie co klient) Ten po konsultacjach z innymi wysyła wynik do klienta. Po uzyskaniu odpowiedzi mówiącej o dostępności danej usługi, klient może zażądać wykonania usługi za pomocą SLM [33]. Może się zdarzyć, iż lokalny SLM nie będzie dysponował wymaganą przez klienta usługą. Wtedy SLM komunikuje się z innymi SLM’ami [33]. Salutation można porównać z Jini, gdyż jest bardzo podobny w sposobie działania. Jest jednak bardziej uniwersalny. Więcej informacji na stronie http://www.salutation.org • SSDP-UPnP (Simple Service Discovery Protocol) – służy do automatycznego wykrywania, konfiguracji i kontroli usług w niedużych sieciach LAN [32]. Po nazwie można dojść, że jest to protokół dosyć prosty. Zrezygnowano z katalogu 57 usług, skorzystano z multicast’u. W ten sposób system wykrywania usług nie wymaga konfiguracji. W jaki sposób klient może dowiedzieć się o istniejącej usłudze? Otóż na dwa sposoby. Pierwszy to bierne nasłuchiwanie, które tutaj ma sens, gdyż aktywne usługi rozsyłają swoje ogłoszenia. Znaleziony serwis zostaje zapisany w lokalnej bazie danych [32]. Drugi sposób polega na wysyłaniu multicast’owego zapytania (zapytanie do wszystkich). Urządzenie posiadające stosowny serwis, odpowiada na zapytanie [32]. Więcej na stronie http://upnp.org • PDP (Pervasive Discovery Protocol) – protokół skupiający się na decentralizacji mechanizmu wyszukiwania usług. Więcej informacji na ten temat na stronie http://www.it.uc3m.es/~celeste/papers/pdp_aamas2002.pdf • DEAPspace – opiera się o rozgłaszanie broadcast’owe informacji o usługach w całej sieci. • SSDS - (Secure Service Discovery Service). Zawiera metody uwierzytelniania i wymiany kluczy na potrzeby wykrywania usług. Więcej informacji znaleźć można na http://ninja.cs.berkeley.edu/dist/papers/sds-mobicom.pdf • SDP – jest to protokół z którego skorzystałem w swoim projekcie. Największą zaletą tego protokołu, która przemówiła za tym aby z niego skorzystać jest niewątpliwie fakt, iż jest on zaimplementowany we wszystkich urządzeniach wykorzystujących technologię Bluetooth. Pisząc aplikacje, miałem na uwadze uniwersalność programów, które z założenia mają działać na jak największej ilości urządzeń. Obecność klienta lub serwera SDP w urządzeniach z Bluetooth jest obowiązkowa. Dostawca usługi musi mieć funkcjonalność serwera SDP, a klient usługi klienta SDP [27]. Trzeba pamiętać, że funkcja klienta i serwera SDP jest niezależna od tego, które urządzenie jest w danym połączeniu urządzeniem Master, a które Slave [27]. Transakcję SDP bardzo dobrze obrazuje obrazek numer 23. 58 Rys 23. Protokoły uczestniczące w transakcji SDP [www.bluetooth.org/spec/] Po wywołaniu żądania zapytania o usługę, następuje wygenerowanie PDU przez klienta SDP, który przekazywany jest niższym warstwom. Każde zapytanie i każda odpowiedź składa się z jednego PDU. Przez interfejs radiowy, odpowiednio zapakowany wysyłany jest do urządzenia zdalnego, gdzie po dekapsulacji i scalaniu trafia do serwera SDP. Serwer posiada swoistą bazę danych o usługach (SDDB), na jej podstawie generuje odpowiedź, która wraca do klienta SDP [27]. 5.2.2 Aplikacja na PC Aplikacja na komputerze klasy PC pełni rolę serwera. W dużej części oparta jest o oprogramowanie dostarczane wraz z urządzeniem Bluetooth ze stosem protokołów BlueSoleil. Po instalacji oprogramowania BlueSoleil mamy dostęp do API, z którego można korzystać w swoich aplikacjach. Dzięki temu moja aplikacja może wykonywać podstawowe operacje, typu: start serwis, stop serwis, itp. 4 pliki zostały dostarczone projektantom i programistom w celu kompilowania, linkowania i uruchamiania aplikacji: plik DLL btfunc.dll, biblioteka btfunc.lib i dwa pliki nagłówkowe bt_ui.h, bt_def.h. • btfunc.dll – implementacja API do Bluetooth. W momencie instalacji BlueSoleil, biblioteka ta jest instalowana w systemie Windows 59 • btfunc.lib – zawiera adresy funkcji, biblioteka którą trzeba dołączyć do pisanego programu • bt_ui.h – plik nagłówkowy w którym zdefiniowane są stałe, struktury • bt_def.h – plik nagłówkowy w którym zdefiniowane są typedef’y i klasy Bluetooth Aplikacja oferuje 3 poziomy zabezpieczeń połączenia pomiędzy urządzeniami: • Niski - brak zabezpieczenia. Procedury zabezpieczenia nie są wymagane dla połączeń. Inne urządzenia mają swobodny dostęp do serwera bez konieczności wprowadzania klucza hasła. • Średni - uwierzytelnianie lub autoryzacja są wymagane przy dostępie do określonej usługi przez inne urządzenia. Jeśli dwa urządzenia nawiązują ze sobą po raz pierwszy połączenie, wówczas taki tryb wymusza wymianę tego samego klucza hasła między nimi. • Wysoki – wymuszone zabezpieczenie. Jeśli mamy uruchomiony ten tryb, wówczas uwierzytelnianie jest wymagane przy każdym inicjowaniu połączenia pomiędzy dwoma urządzeniami z obsługą Bluetooth. Do dokończenia procesu uwierzytelniania wymagane jest dostarczenie klucza hasła obydwu stronom. Skoro aplikacja ta pełni rolę serwera, to musi być na niej uruchomiony co najmniej jeden serwis (w moim przypadku jest to „Serial Port”), który nasłuchuje na połączenia przychodzące od innych urządzeń. Każde przychodzące połączenie obsługiwane jest przez nowy wątek. Aby serwis spełniał założone przeze mnie zadanie, przed jego uruchomieniem należy zarejestrować funkcję CallBack() (z dostępnych poleceń wybrać należy cyfrę 10), która w pośredni sposób odpowiada za zdarzenia związane z nadchodzącymi ze zdalnych urządzeń „poleceniami”. Wszystkie możliwe polecenia które mogą napłynąć od zdalnych urządzeń są oczywiście znane i odpowiednio zdefiniowane w aplikacji. Przyjąłem zasadę, iż każde polecenie składa się z 3 liter, które są w pełni wystarczające aby zdefiniować wszystkie potrzebne zadania. Polecenia mogą być dłuższe, jednak trzeba pamiętać, że identyfikacja następuje po 3 ostatnich literach. Oprócz tego, każde poprawne polecenie musi się kończyć sekwencją „AT\r”. Każdorazowe prawidłowe przetworzenie odpowiedniego polecenia wymusza na aplikacji wysyłanie stosownego potwierdzenia. 60 Dla celów pokazowych komunikaty będące poleceniami użytkownika, serwer realizuje w postaci głosowych zadań, które w łatwy sposób mogą być modyfikowane, w zależności od potrzeb. 5.2.3 Aplikacja na Game Board Tak jak pisałem wcześniej, nie udało się wdrożyć tego urządzenia do działającego systemu „inteligentnych urządzeń”. Istotę problemu opisałem w rozdziale 5.2. Jednak urządzenie to jest o tyle ciekawe, że warto przedstawić jego istotne cechy. W rzeczywistości Game Board to nic innego jak mikrokontroler. Jego najważniejsze cechy są następujące [40]: • posiada 128 kB pamięci Flash i 16 SRAM • 130 x 130 pixel kolorowy wyświetlacz LCD • Obecność Bluetootha opartego o Philips BGB203-S06 z zaimplementowanym profilem SPP, czyli Serial Port • 5-cio funkcyjny joystick odpowiedzialny za interakcje z użytkownikiem. • Zasilany przez USB • Wymiary mikrokontrolera to 90x90mm. Rys.24 LPC2104 Color LCD Game Board [40] 61 W jaki sposób połączyć się z urządzeniem przez USB? Przede wszystkim trzeba zainstalować stosowne sterowniki, gdyż po podłączeniu urządzenia do komputera PC za pomocą wspomnianego USB, komputer prosi o sterowniki. Po prawidłowym zainstalowaniu tych sterowników, tworzony jest COM port służący do komunikacji (USB Serial Port) [40]. Ustawienia dla tego portu są następujące: - szybkość transmisji 115200 b/s - bity danych 8 - brak parzystości - bity stopu 1 - brak sterowania przepływem Zauważyć można że są to standardowe ustawienia portu, którym łączymy się z routerami. Przydzielony numer portu powinien mieścić się w zakresie od 1 do 5 [40], ponieważ tego wymaga Philips FLASH Utility program, którego używałem do wgrywania oprogramowania. Alternatywnym programem do rozmieszczania oprogramowania jest lpc21isp dostarczany z biblioteką LPC2xxx-gcc-newlib-v2_3_0_0. Przewagą pierwszego programu jest bardzo przyjazny interfejs graficzny, który w prosty sposób umożliwia przesłanie napisanego oprogramowania na urządzenie. W tym momencie należy poruszyć temat związany ze zworkami, które są obecne na urządzeniu. Jest to bardzo istotne zagadnienie, ponieważ wspomniane zworki muszą znajdować się w odpowiednim ustawieniu aby umożliwić wgrywanie nowego oprogramowania. Jednak nie będę się nimi szczegółowo zajmował, ponieważ informacje na ten temat znaleźć można w literaturze [44, 45]. Mówiąc o wgrywaniu gotowych aplikacji, trzeba powiedzieć w jaki sposób powstaje plik, który można przesłać do mikrokontrolera. Plik ma określony format, jest to plik HEX. Aby móc skompilować napisany przez siebie program niezbędne jest odpowiednie środowisko wraz z kompilatorem (GCC), który to umożliwi [41]. Środowisko to jest oczywiście dostarczane przez producenta i dostępne na stronie www.EmbeddedArtists.com. Bardzo ważne zadanie pełni plik makefile. Określa parametry kompilowania i linkowania, a także jakie pliki wchodzą w skład programu, jakie biblioteki, jaki będzie wynik kompilacji (jakiego typu będzie plik wynikowy), itp.. Ponieważ modelów mikrokontrolerów jest bardzo dużo na rynku, to w pliku tym określa się również model mikrokontrolera na jaki kompilujemy program [41]. Jeśli chodzi o Bluetootha, to trzeba pamiętać o włączeniu aktywnego trybu, który powoduje możliwość wykrycia naszego urządzenia przez innych. 62 Do uruchomiania serwisu nasłuchującego na przychodzące połączenia, użyłem Hyper Terminala i następującego polecenia: AT+BTSRV=<Port>, “<Service Name>” Powyższe polecenie wystarcza do tego, aby serwis zaczął nasłuchiwać. Wracając do problemu z którym zetknąłem się podczas implementacji projektu i o którym pisałem w rozdziale 5.2, warto zauważyć, że komunikacja pomiędzy mikrokontrolerem a komputerem PC doszła do skutku. Niestety taka opcja była mało zadawalająca ze względu na założone cele, w których klientem poszukującym serwisu miał być telefon komórkowy. Więcej informacji o tym urządzeniu można znaleźć na stronie www.EmbeddedArtists.com. 5.2.4 Profile zastosowań Bluetooth Profile są bardzo istotnym zagadnieniem w standardzie Bluetooth od których w dużej mierze zależy dalszy rozwój tej technologii. Ich celem jest zapewnienie kompatybilności pomiędzy aplikacjami i urządzeniami pochodzącymi od różnych producentów [8]. Najogólniej, profile można podzielić na 4 grupy [8]: • Profile ogólne • Profile portu szeregowego • Profile telefonii • Profile pracy sieciowej Do profili ogólnych zalicza się profil ogólnego dostępu (GAP – Generic Access Profile) , który jest podstawą dla wszystkich pozostałych profili i jest obecny w każdym urządzeniu wyposażonym w Bluetooth [8]. Drugim profilem ogólnym jest profil aplikacji wyszukiwania usług (SDPAM – Service Discovery Application Protocol). Profil GAP określa jednakowe zasady korzystania z protokołów transportowych dla wszystkich profili, określa funkcję, które są obowiązkowe dla wszystkich urządzeń Bluetooth. Natomiast profil SDPAM tworzy zasady korzystania z protokołu SDP [8]. Do rodziny profilu portu szeregowego, z którego bezpośrednio korzystałem w swoim projekcie, zalicza się następujące profile [8]: • Profil portu szeregowego (SPP) • Profil ogólnej wymiany obiektów (GOEP) 63 • Profil transferu plików (FTP) • Profil wypychania obiektów (OPP) • Profil synchronizacji danych (SP) Ze względu na założenie w którym napisane przeze mnie aplikacje mają działać na jak największej ilości urządzeń, skorzystanie z profilu SPP wydaje się oczywiste, gdyż jest on najczęściej implementowanym profilem [8]. Pozwala na zestawienie wirtualnego portu szeregowego pomiędzy dwoma urządzeniami Bluetooth. Profil ten odwołuje się bezpośrednio do protokołu RFCOMM, co nie jest w cale bez znaczenia. Przewagą RFCOMM nad innymi protokołami pośredniczącymi jest fakt, iż w urządzeniu posiadającym Bluetooth jest on zaimplementowany zawsze, natomiast inne tego typu protokoły niekoniecznie [8]. Trzeba pamiętać, że do ustanowienia bezprzewodowego połączenia szeregowego, oprócz wszystkich protokółów transportowych do warstwy L2CAP włącznie (rysunek numer 17) potrzebne są 2 protokoły pośredniczące: wspomniany RFCOMM i SDP. Więcej na ten temat można dowiedzieć się ze specyfikacji Bluetooth i z literatury [8]. Chcę zauważyć, że inne profile, niektóre o wiele bardziej wyrafinowane byłyby również dobre, jednak z uwagi na fakt, iż urządzenie wyposażone w Bluetooth nie musi ich posiadać, tracą trochę na użyteczności. Nie będę opisywał pozostałych profili, gdyż zajęłoby to wiele stron, a nie to jest celem pracy. Wszystkie opisy dostępnych profili znajdują się w literaturze [8]. Aby uzupełnić rodziny profili, wspomnę jeszcze o profilach telefonii i pracy sieciowej, w skład pierwszej grupy wchodzą [8]: • Profil telefonii bezprzewodowej • Profil Interkomu • Profil zestawu słuchawkowego Do rodziny profili pracy sieciowej zalicza się [8]: • Profil pracy sieciowej z połączeniem komutowanym • Profil dostępu do LAN • Profil faksu 64 5.2.5 Instrukcja obsługi 5.2.5.1 Wymagania sprzętowe • Telefon komórkowy z systemem Symbian 7.0 z interfejsem UIQ 2.0 • Komputer PC: o Procesor: Intel Celeron/ Pentium III/ Pentium IV; AMD Duron/ Athlon o System operacyjny: Microsoft Windows 98 SE/ME/2000/XP o Pamięć RAM: co najmniej 32MB o Wolne miejsce na dysku: 11,5MB • Bluetooth USB Dongle z API BlueSoleil 5.2.5.2 Instalacja • Instalacja aplikacji na komputerze PC Mając w napędzie CD-ROM płytkę CD dołączoną wraz z tą pracą, należy podłączyć Bluetooth USB Dongle. Automatycznie zostanie wykryty nowy sprzęt, system operacyjny Windows poprosi nas o zainstalowanie sterowników, które dostępne są w katalogu SterownikiBlueSoleil. Po ukończeniu instalacji, program w katalogu AplikacjaNaPc\EXE jest gotowy do uruchomienia. • Instalacja aplikacji na telefonie komórkowym z Symbianem Instalacja napisanej przeze mnie aplikacji może przebiegać na różne sposoby. Przedstawię najłatwiejszy, ten z którego sam korzystałem. Otóż wystarczy przegrać plik instalacyjny SIS do pamięci telefonu (plik instalacyjny znajduje się w katalogu AplikacjaNaTelKom\SIS). Można to zrobić za pośrednictwem karty SD, w którą wyposażonych jest większość telefonów (np. Motorola A920, A925), lub nawiązując połączenie Bluetooth z telefonem komórkowym i przesyłając stosowny plik. Sama instalacja jest trywialna, wymaga jedynie kilkukrotnego kliknięcia „OK”. Po ukończonej instalacji, program jest gotowy do uruchomienia. 65 5.2.5.3 Opis szczegółowy • Aplikacja na komputerze PC Po uruchomieniu aplikacji, na ekranie pojawia się główne „menu”, które zawiera numerowane akcje. Do poprawnego działania wymagane jest włączenie SDK_BtRegisterCallBack, czyli akcja numer 10 (jest to funkcja która odpowiada za zdarzenia). Następnie trzeba podać na jakie zdarzenia ma reagować, więc należy podać EVENT_CONNECTION_STATUS (akcja numer 3). Aby wyjść z tego poziomu i wrócić do głównego „menu” należy podać w linii poleceń „-1”. Po tej operacji pozostaje tylko uruchomienie serwisu nasłuchującego na połączenia, co czyni akcja 12 (SDK_BtStartSPPExService). Po tych czynnościach aplikacja czeka na pojawienie się w zasięgu Bluetooth urządzenia zdefiniowanego w pliku BlueSoleilClient.ini. W pliku tym znajduje się MAC adres urządzenia posiadającego dostęp do wysłania stosownych komunikatów. Po pojawieniu się danego urządzenia w zasięgu, aplikacja na komputerze PC stosownym komunikatem głosowym powiadamia o tym zdarzeniu. Tak samo dzieje się w przypadku, gdy dane urządzenie opuszcza zasięg, • Aplikacja na telefonie komórkowym Po uruchomieniu aplikacji, z „menu” górnego należy wybrać polecenie „Commands”, a następnie z rozwijanej listy poleceń „Start”. Niestety dostępne urządzenia z którymi telefon komórkowy może nawiązać komunikację są zapisane w postaci struktury w pliku źródłowym aplikacji (w pliku ClientBT_MsgClient.cpp). Aby zmienić MAC adresy tych urządzeń, trzeba przekompilować cały projekt. Aby zatrzymać działanie aplikacji, trzeba wybrać z „menu” polecenie „Stop”. Zasadę działania aplikacji opisuję w rozdziale 5.2.1.6. 66 5.3 Standardy Bluetooth na komputery PC Na rynku jest kilka standardów Bluetooth, są to: • JSR 82 + Java API. Specyfikacja standaryzująca zbiór wywołań API, które pozwalają na wykorzystanie Bluetootha w aplikacjach napisanych w Javie. Link do strony z której można ściągnąć niezbędne biblioteki wraz ze specyfikacją to http://jcp.org/aboutJava/communityprocess/mrel/jsr082/index.html • Widcomm , obecnie Broadcom . Są dwie wersje SDK: jedna do pisania pod PC (Windows 98, ME, 2000, XP), druga na Windows Mobile Pocket PC (wspierane są HP, iPAQ's, Dell, Axim, X30, X50, Acer, n50, n300, Asus, A636, A716, A730, Windows Mobile Pocket PC ze zintegrowanym Bluetooth). Link do tego standardu jest następujący http://www.broadcom.com/products/bluetooth_sdk.php • Toshiba, SDK dostępne na stronie http://aps.toshiba-tro.de/bluetooth/ Wspierane platformy to: Win 95A, Win 95B, Win 98, Win 98SE, Win ME, Win NT 4.0, Win 2K, Win XP, Win Server 2K3, Win Vista. Informacje na temat tego standardu można uzyskać ze strony http://aps.toshiba- tro.de/bluetooth/redirect.php?page=pages/faq.html • Microsoft Bluetooth i jego API, które zawiera niezbędne biblioteki. Windows zapewnia dwa sposoby dostępu do Bluetooth: - poprzez użycie Windows Sockets Interface - zarządzanie urządzeniem bezpośrednio, bez użycia Sockets • BlueSoleil (w kilku zdaniach opisuje jego API w rozdziale 5.2.2) Wszystkie wymienione standardy rozwijane są w bardzo szybkim tempie. Niestety bardzo często nie są ze sobą kompatybilne, o czym mogłem się przekonać. Stwarza to wiele problemów z ich używaniem. Do swojego projektu wybrałem standard BlueSoleil. Decyzje mogę umotywować tylko tym, iż chciałem zapoznać się z implementacją podstawowych funkcji w standardzie innym niż Microsoft. 67 5.4 Dlaczego C++ W porównaniu z Javą, zaletą C++ jest pełny, niskopoziomowy dostęp do urządzenia, możliwość bezpośredniego dostępu do wielu funkcji telefonu., oraz znacznie szybsza praca aplikacji. Java uznawana jest za technologię wolną i „zasobożerną”, co w przypadku urządzeń o ograniczonej mocy obliczeniowej i małej pamięci jest poważnym zastrzeżeniem. Jeśli aplikacja pisana przeze mnie miałaby charakter jakiejś gry czy innej podobnej tego typu aplikacji, wówczas Java byłaby równie dobra co język C++. Jednak do tworzenia złożonych i bardziej zaawansowanych aplikacji (aplikacja wykorzystująca Bluetooth należy do takiej grupy programów), znacznie lepiej skorzystać z C++ [34]. 6 Dalsze kierunki rozwoju Przedstawiony i zrealizowany przeze mnie projekt posiada jedynie podstawowe elementy wchodzące w skład Inteligentnego Budynku. Proponowany jest dalszy rozwój w celu zwiększenia złożoności systemu i doprowadzeniu do stanu w którym liczba „inteligentnych” urządzeń wzrośnie. Należy dążyć do implementacji rzeczywistych wymogów stawianych przed tego typu systemami. Jest wiele kierunków, w których projekt może się rozwinąć. Oprócz dodania innych urządzeń, które w znaczący sposób rozszerzą projekt, można spróbować zmienić schemat ideowy projektu, o który opiera się cały system. Do istniejącej sieci można dodać punkt centralny – jednostkę, która będzie zarządzała wszystkimi urządzeniami peryferyjnymi, które byłyby w takim wypadku podrzędnymi w stosunku do punktu centralnego. Dobrym kandydatem urządzenia centralnego spełniającego wszystkie potrzebne funkcje mógłby być komputer klasy PC z Bluetooth’em. Wtedy „klucz”, telefon komórkowy łączyłby się tylko z jednostką centralną, która zajmowała by się realizacją zleconych mu zadań poprzez przesyłanie komunikatów do odpowiednich urządzeń. 68 Rys.25 Wariant rozbudowy projektu Takie rozwiązanie miałoby jedną dużą zaletę. Proces polegający na zweryfikowaniu tożsamości osoby (tzw. uwierzytelnienie) posiadającej telefon komórkowy i próbującej nawiązać połączenie z którymkolwiek urządzeniem byłby o tyle prosty, iż wymagałby zaimplementowania go jedynie na dwóch urządzeniach: telefonie komórkowym i jednostce centralnej. Niestety należało by się zastanowić nad wadami takiego rozwiązania. Jedną z takich wad jest niewątpliwie to, iż w sieci będzie istniała jednostka centralna, która w razie jakichkolwiek problemów technicznych unieruchomi całą sieć. Aplikacja na telefon komórkowy z system Symbian OS stwarza ogromne możliwości rozwoju. Napisana przeze mnie aplikacja polega na automatycznym wysyłaniu stosownego polecenia do zdalnego urządzenia, w momencie pojawienia się w jego zasięgu. Jednak może zajść potrzeba, gdzie użytkownik będzie chciał po wysłaniu tego polecenia, wysłać inne (przykładem może być telewizor, który włączy się po naszym wejściu do mieszkania, lecz przykładowo domownik chciałby mieć możliwość zmiany kanałów). Aplikacja uwzględnia przyszłe takie potrzeby, jest napisana w taki sposób, aby umożliwić w przyszłości zaimplementowanie tej funkcjonalności. 69 7 Wnioski i podsumowanie Cel który postawiłem sobie na samym początku został osiągnięty. W ramach mojej pracy powstał system Inteligentnego Budynku. Urządzeniem sterującym jest telefon komórkowy z systemem Symbian OS. Komputery klasy PC wraz z mikrokontrolerem pełnią rolę urządzeń peryferyjnych, wykonujących wcześniej skonfigurowane zadania. Oczywiście mam świadomość że w rzeczywistości Inteligentne Budynki składają się z większej ilości aktywnych urządzeń. Są to systemy bardzo rozbudowane, ich topologie bardzo często przybierają różną postać – w zależności od zastosowań. Zasadniczym celem pracy było zapoznanie się ze sposobami tworzenia i uruchamiania oprogramowania dla OS Symbian. Do tworzenia oprogramowania na Symbian OS powstało wiele środowisk programistycznych, tzw. IDE, których celem jest ułatwienie pisania aplikacji pod ten system. Mimo wszystko, tworzenie nawet prostych aplikacji przysparza wielu kłopotów, o czym mogłem się przekonać. Dużą przeszkodą w pisaniu programów na Symbian OS jest brak dobrej dokumentacji. Wsparcie techniczne dla tego systemu operacyjnego jest nieporównywalnie mniejsze od innych systemów operacyjnych, takich jak Windows czy Linux. Skalę problemu można zaobserwować przeglądając oferty księgarni publicznych a także księgarni internetowych. Na polskim rynku nie ma jeszcze ani jednej książki omawiającej system operacyjny Symbian. Jednym z najtrudniejszych wyzwań w tej pracy było napisanie oprogramowania przeznaczonego na telefon komórkowy, służącego do sterowania innymi urządzeniami. W tym celu niezbędną rzeczą było dogłębne poznanie protokołu Bluetooth. Jak wspominałem we wcześniejszych rozdziałach, protokół ten rozwija się bardzo szybko. Niestety nie jest on jeszcze doskonały, o czym świadczą istniejące „dziury”, które często wykorzystywane są przez liczne ataki. W 2005 roku opracowano już nawet mechanizm łamania PINu, o który oparty jest proces „parowania” urządzeń przed rozpoczęciem transmisji. Do najczęstszych ataków wykorzystujących luki w specyfikacji Bluetooth należą: • BlueJack – wysyłanie wiadomości do widocznych urządzeń będących w zasięgu, rozsyłanie SPAMu, wirusów. • BlueSmack – atak typu Dos, bazujący na wysyłaniu wiadomości protokołu L2CAP z żądaniem odpowiedzi (echo request) 70 • BlueBump – umożliwia połączenie z telefonem ofiary bez jej wiedzy jeśli wcześniej istniało uwierzytelnione połączenie. Jego działanie polega na manipulacji przechowywaniem klucza połączenia (link key). Wobec tego można sobie zadać pytanie dlaczego zdecydowałem się użyć Bluetootha, skoro jest tak dużo zagrożeń związanych z komunikacją opartą o ten protokół. W tym miejscu warto zastanowić się nad tym, czy chcemy mieć komunikację z urządzeniami za pomocą jakiegokolwiek okablowania, czy też drogą radiowa będzie odpowiedniejsza (bezpieczeństwo i uciążliwe kable, czy wygoda i ryzyko związane z narażaniem się na różne ataki ). W grupie protokołów radiowych Bluetooth wydaje się rozwiązaniem najlepszym patrząc z punktu widzenia zastosowania w Inteligentnym Budynku i nie bez znaczenia jest to, iż protokół ten jest bardzo intensywnie rozwijany. Grupa SIG stara się zwalczać wszelkie problemy, myślę że w ciągu kilku lat uda im się opracować algorytmy, które wykluczą wszelkiego rodzaju ataki. W przyszłości na podstawie mojej aplikacji może powstać bardzo duży system, który umożliwi sterowanie wieloma urządzeniami. Kod programu sterującego innymi urządzeniami jest napisany zgodnie z konwencją pisania programów pod Symbian OS, co powinno ułatwić rozwój aplikacji. Podsumowując cały temat związany z Inteligentnym Budynkiem, po zapoznaniu się z różnymi technologiami umożliwiającymi realizację praktyczną, z całą pewnością mogę stwierdzić, że jest to zagadnienie o które w przyszłości opierać się będzie budownictwo na całym świecie. Zaawansowane systemy kontrolujące niemal wszystko, co jest związane z budynkiem będą codziennością. 71 BIBLIOGRAFIA [1] Richard Harrisom, „Symbian OS C++ for Mobile Phones”, John Wiley & Sons Ltd 2003 [2] Rafał Fabich, Rafał Fetorków, strona zrealizowana w ramach przedmiotu "Środowisko telekomunikacyjne sieci komputerowych", http://fedik.republika.pl [3] SMARTech, Zastosowania Inteligentnego Budynku, http://poradnik.smartech.pl/ [4] Soft-Net, Zastosowania Inteligentnego Budynku, http://www.soft-net.com.pl [5] Piotr Zwierzchowski, „Oświetlenie w inteligentnych budynkach”, 2005 http://www.steruj.pl/index2.php?option=com_content&do_pdf=1&id=6 [6] Mariusz Szepietowski „Porównanie systemów inteligentnego domu - część I, II i III„, 2007 http://budujemydom.pl/component/option,com_content/task,specialblogcategory/ac t,view/id,1358/Itemid,45/ [7] Krzysztof Nowicki, „Ethernet - sieci, mechanizmy”, wyd. Infotech 2006 [8] Brent A. Miller, Chatschink Bisdikian, Ph. D., “Uwolnij się od kabli - Bluetooth”, Helion, Gliwice 2003 [9] Bzowski Remigiusz, Cerankowski Łukasz, „System zabezpieczenia w inteligentnym domu”, Elbląg 2005 http://www.elektrycy.cba.pl/nauka/informatykawelektroenergetyce/System_zabezpi eczenia_w_inteligentrnym_budynku.pdf [10] Jerzy Mikulik, „Budynek inteligentny. Tom II. Podstawowe systemy bezpieczeństwa w budynkach inteligentnych”, wyd. Politechniki Śląska 2005. [11] A. Janikowski „Sieci domowe cz.1”, 2001, http://www.networld.pl/artykuly/9289.html [12] A. Janikowski “Sieci domowe cz. IV - Sieci bezprzewodowe”, http://www.networld.pl/artykuly/21058.html [13] A. Janikowski, „PLC - prąd i dane w jednym gniazdku“, Networld – wydanie specjalne, nr 1/2002 [14] MainNet Communications Ltd, „BPL / PLC Technology Overview”, 2007, http://www.mainnet-plc.com/mainnet/home/page.aspx?id=1 [15] S. Chemishkian, „Building Smart Services for Smart Home”, Networked Appliances, 2002. Proceedings. IEEE 4th International Workshop on, 2002. 72 [16] Przemysław Pawełczak, Krzysztof Jakubik „Co nowego w PLC?”, 2006 http://cyfrowydom.idg.pl/artykuly/51611.html [17] Ascom Poland Sp. z o.o., opis techniczny systemu ASCOM PLC, http://networld.pl/suplementy/urzadzenia/ascom.html#charakt [18] Krzysztof Pietrzak, „Sieci HomePlug”, 2006, http://cyfrowydom.idg.pl/artykuly/50188.html [19] Andrzej Janikowski, “Sieci domowe”, 2002, http://wireless.idg.pl/artykuly/24453.html [20] XinWang, Georgios B. Giannakis, “CSMA/CCA: A Modified CSMA/CA Protocol Mitigating the Fairness Problem for IEEE 802.11 DCF”, http://www.hindawi.com/GetArticle.aspx?doi=10.1155/WCN/2006/39604&e=REF [21] Małgorzata Szafarz, „Inteligentny budynek”, 2006, http://nowebiuro.pl/biuro/kategorie/artykuly/Inteligentny;budynek-12,12129.html [22] Wojciech Wiśniewski, „Zasady działania systemu EIB”, http://eib.pl/?60320401 [23] IrDA Specifications, http://www.irda.org/displaycommon.cfm?an=1&subarticlenbr=7 [24] The HomeRF Technical Committee, “HomeRF 2.0 Specification Revision 2.01”, 2002, http://palowireless.com/homerf/homerfspec.asp [25] Marcin Suszkiewicz, “ZigBee - sieci energooszczędne”, 2004, http://www.idg.pl/artykuly/45542.html [26] ZigBee Alliance, ZigBee Specification Document 053474r13, 2006, http://www.zigbee.org/en/spec_download/download_request.asp [27] Bluetooth Specification Version 2.1 + EDR [vol 0], 2007, http://www.bluetooth.com/Bluetooth/Learn/Technology/Specifications/ [28] Philips, “UM_1SPP BGB203 BT 2.0 Serial Port Profile Module User’s Guide”, 2005 [29] Oficjalna strona Symbian OS, http://www.symbian.com [30] Cezary Kramp, „Systemy także w komórkach”, 2004 http://www.pcworld.pl/artykuly/44802.html [31] Portal poświęcony systemowi operacyjnemu Symbian, http://www.symbianos.pl [32] IETF Internet Draft – “Simple Service Discovery Protocol/1.0”, www.upnp.org [33] Choonhwa Lee and Sumi Helal “Protocols for Service Discovery in Dynamic and Mobile Networks”, 2002 Nova Science Publishers, Inc, http://www.harris.cise.ufl.edu/projects/publications/servicediscovery.pdf 73 [34] Andreas Jakl, „Pierwsze kroki w C++ dla Symbian OS”, Software 2.0, 5/2005 [35] Michael J. Jipping, “Symbian OS - Communications Programming”, published by John Wiley & Sons 2004, ISBN 0-470-88430-2 [36] Network Working Group, “RFC 2608 - Service Location Protocol, Version 2”, 1999 www.faqs.org/rfcs/rfc2608.html [37] International Telecommunication Union, “What is a UUID?”, http://www.itu.int/ITU-T/asn1/uuid.html [38] Sun Microsystems, White Paper, “Jini Architectural Overview”, www.sun.com/software/jini/whitepapers/architecture.pdf [39] Alan Berkema, “Minimal Basic Printing Profile Requirements for a Sender”, 2002, http://www.bluetooth.com/NR/rdonlyres/497756B8-1066-48D6-99EC0363D879FC27/0/Minimal_BPP_Reqs_For_Sender.pdf [40] Embedded Artists AB, “LPC2104 Color LCD Game Board User’s Guide”, 2006, http://.EmbeddedArtists.com [41] Embedded Artists AB, “QuickStart Program Development User’s Guide”, 2005, http://.EmbeddedArtists.com 74 Dodatek A Zawartość nośnika CD-ROM Aplikacja na telefon komórkowy – załączone oprogramowanie jest w dwóch wersjach: • programu wykonywalnego w postaci pliku SIS (AplikacjaNaTelKom\SIS) • plików źródłowych całej aplikacji (katalog AplikacjaNaTelKom\Sources) Aplikacja na PC – załączone w dwóch wersjach: • program wykonywalny w postaci pliku EXE (AplikacjaNaPc\EXE) • program w postaci plików źródłowych (AplikacjaNaPc\Sources) Praca mgr – tekst pracy w dwóch wersjach: • plik PDF (TekstPracyMgr\PDF) • plik DOC (TekstPracyMgr\DOC) SDK + Sterowniki do Bluetooth BlueSoleil • Katalog SDKiSterownikiBlueSoleil Materiały elektroniczne • Katalog Materiały elektroniczne Użyte rysunki • Katalog Rysunki do pracy Raporty autentyczności pracy • Katalog Pelny raport Systemu antyplagiatowyego Plagiat.pl • Katalog Skrócony raport Systemu antyplagiatowego Plagiat.pl Instalacja CodeWarrior + SDK (wersja 15 dniowa) • Katalog CodeWarrior + SDK LPC Game Board – sterowniki + programy • Katalog LPC 75 Dodatek B Raport skrócony wygenerowany przez System Antyplagiatowy Plagiat.pl, za pomocą witryny http://plagiat.pl 76 77 78 79
