1
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.
2
SPIS TREŚCI
Wykaz skrótów ..................................................................................................................4
Wykaz rysunków ...............................................................................................................6
Wykaz tabel .......................................................................................................................7
1
WSTĘP ......................................................................................................................8
1.1
Idea Inteligentnego Budynku ..............................................................................8
1.2
Definicja Inteligentnego Budynku ......................................................................9
1.3
Historia powstania i ewaluacja Inteligentnego Budynku ...................................10
2
Cel i zakres pracy .....................................................................................................11
3
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
4
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
5
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
3
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
4
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
5
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
6
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
7
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
8
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.
9
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
10
• 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 70-
te. 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.
11
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
jest najbardziej
rozpowszechnionym systemem operacyjnym na telefony komórkowe. 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.
12
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
13
[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].
14
• 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
15
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ą.
16
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
17
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].
18
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
19
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
20
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ą
21
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 techniki rozpraszania widma [11]. Jest to otwarty standard, który
zapewnia specyfikację oddzielnej warstwy fizycznej dla komunikacji liniami
elektroenergetycznymi, światłowodami, skrętkami, 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
22
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].
23
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
24
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
25
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].
26
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].
27
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).
28
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.
29
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.
30
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]
31
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].
32
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
33
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 FHS
1
, 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
34
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
35
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
Połączenie
Do 3 równoległych kanałów po
64 kb/s w każdą stronę
433 kb/s w każdą
stronę
721 kb/s w jedną
stronę i 57,6 kb/s
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
36
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].
37
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
.
38
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
39
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.
40
Środowisko
Komercyjny
Debugowanie na telefonie
Microsoft Visual C++ (6.0,
7.0, 2005)
TAK
NIE
Microsoft Windows SDK
NIE
NIE
CodeWarrior
for
SymbianOS
TAK
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].
41
Nazwa: Typ: Rozmiar:
TInt
Integer
przynajmniej 32 bity
TUint
Unsigned integer
przynajmniej 32 bity
TInt8
Integer
8 bitów
TInt16
Integer
16 bitów
TInt32
Integer
32 bity
TUInt16
Unsigned Integer
16 bitów
TUInt32
Unsigned Integer
32 bity
TReal
Real
przynajmniej 64 bity
TReal32
Real
przynajmniej 32 bity
TReal64
Real
przynajmniej 64 bity
TRealX
Real
rozszerzona precyzja
TText
Character
przynajmniej 16 bitów (unicode)
TText8
Character
przynajmniej 8 bitów (ascii)
TText16
Character
przynajmniej 16 bitów
TChar
Character
przynajmniej 32 bity (extended
unicode )
TBool
ETrue lub EFalse
32 bity
TAny
Używane jako TAny*
Tab.4 Podstawowe typy danych w systemie Symbian
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.
42
• 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 Klient-
Serwer, 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].
43
• 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
44
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 Stacku
2
(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].
45
ź
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.
46
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.
47
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
48
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)
49
• 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.
50
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.
51
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
uid@symbiandevnet.com
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].
52
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.
53
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.
54
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
55
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
56
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.
57
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
58
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.
59
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
60
• 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.
61
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]
62
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.
63
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)
64
• 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
65
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.
66
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.
67
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.
68
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ń.
69
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.
70
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)
71
• 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ą.
72
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.
73
[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
74
[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-99EC-
0363D879FC27/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
75
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
76
Dodatek B
Raport skrócony wygenerowany przez System Antyplagiatowy Plagiat.pl, za
pomocą witryny
http://plagiat.pl
77
78
79
Wyszukiwarka
Podobne podstrony:
Ewolucja podejścia do problemu zarządzania jakością (10 stron) (2), Zarządzanie jakością2, Zarzadzan
Ludwig von Mises Uwagi o matematycznym podejściu do problemów ekonomicznych
Socjotechnika jest próbą praktycznego podejścia do socjologii
Podejście do problemów, Pedagogika twórczości
Nowe podejście do problemu zakłóceń w sieciach przemysłowych nn
temat 6 ZRÓŻNICOWANIE W PODEJŚCIU DO PROBLEMATYKI ZDROWOTNEJ W ZALEŻNOŚCI OD KULTURY I RELIGII
praca zaliczeniowa podejście ekonomiczne do problemów ergono, Ekonomia
praca zaliczeniowa podejście ekonomiczne do problemów ergono, Ekonomia, ekonomia
Nie kaz mi myslec O zyciowym podejsciu do funkcjonalnosci stron internetowych Wydanie II Edycja kolo
Istnieją trzy podstawowe podejścia do zrozumienia zachowania przestępcze, ☆──══♦ஓ♦══──☆ STUDIA, re
Wprowadzenie do problemów psychopatologii (Bogacka, Frączek)
Wykład 9 ILOŚCIOWE PODEJŚCIE DO ZARZĄDZANIA
49 WSZECHMOC JEZUSA POLEMIKA Z ANTYTRYNITARNYM PODEJŚCIEM DO WERSETU Mt(,18
Praktyczny komentarz do Nowego Testamentu Ewangelia Marka
więcej podobnych podstron