(Microsoft Word - praca magisterska S\263awek Jaros.doc)

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.

SPIS TREŚCI

Wykaz skrótów ..................................................................................................................4
Wykaz rysunków ...............................................................................................................6
Wykaz tabel .......................................................................................................................7

WSTĘP ......................................................................................................................8

1.1

Idea Inteligentnego Budynku ..............................................................................8

1.2

Definicja Inteligentnego Budynku ......................................................................9

1.3

Historia powstania i ewaluacja Inteligentnego Budynku ...................................10

Cel i zakres pracy .....................................................................................................11

Inteligentny Budynek ...............................................................................................12

3.1

Inteligentny Budynek – zastosowanie ...............................................................12

3.2

Sieci domowe w kontekście Inteligentnego Budynku........................................15

3.3

Podział sieci domowych ze względy na użyte medium. ....................................16

3.3.1

Sieci z nowym okablowaniem...................................................................16

3.3.2

Sieci bez nowego okablowania .................................................................18

3.3.3

Sieci bezprzewodowe................................................................................23

3.3.3.1

IrDA .....................................................................................................23

3.3.3.2

HomeRF ...............................................................................................27

3.3.3.3

ZigBee (IEEE 802.15.4)........................................................................28

3.3.3.4

Bluetooth ..............................................................................................31

Symbian – system operacyjny ..................................................................................37

4.1

Informacja ogólne.............................................................................................37

4.2

Dlaczego Symbian? ..........................................................................................38

4.3

Interfejsy w Symbianie .....................................................................................38

4.4

SDK i dostępne IDE pod Symbiana ..................................................................39

4.5

Podstawy Symbiana (różnice pomiędzy Symbianem a C++).............................40

4.5.1

Podstawowe typy danych ..........................................................................40

4.5.2

Nazewnictwo klas.....................................................................................41

4.5.3

Łańcuchy tekstowe i deskryptory ..............................................................42

4.5.4

Mechanizm opuszczeń (Leaves)................................................................44

Projekt .....................................................................................................................45

5.1

Idea projektu ....................................................................................................45

5.2

Budowa projektu ..............................................................................................46

5.2.1

Aplikacja na telefon komórkowy ..............................................................47

5.2.1.1

Budowa i elementy składające się na aplikację......................................47

5.2.1.2

Struktura katalogów projektu ................................................................48

5.2.1.3

Podział aplikacji na podstawowe pliki...................................................49

5.2.1.4

Rodzaje plików w projekcie ..................................................................50

5.2.1.5

System identyfikatorów UID.................................................................51

5.2.1.6

Zasada działania aplikacji .....................................................................52

5.2.1.7

Bezpieczeństwo ....................................................................................55

5.2.1.8

Identyfikator UUID...............................................................................56

5.2.1.9

Protokoły wyszukiwania usług ..............................................................57

5.2.2

Aplikacja na PC ........................................................................................59

5.2.3

Aplikacja na Game Board .........................................................................61

5.2.4

Profile zastosowań Bluetooth....................................................................63

5.2.5

Instrukcja obsługi......................................................................................65

5.2.5.1

Wymagania sprzętowe ..........................................................................65

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

Dalsze kierunki rozwoju...........................................................................................68

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

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

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

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

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.

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

• 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.

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.

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

[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].

• 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

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ą.

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

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].

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

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

sieć

wąskopasmowa,

która

korzysta

jedynie

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ą

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

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].

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

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

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].

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].

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).

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.

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]

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].

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

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

, 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].

Pakiet FHS - służy do synchronizowaniu zegarów i przekazania sekwencji przeskoków po kanałach

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

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].

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

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)

S60 1 edycji (obecna w najstarszych modelach telefonów z Symbianem)

S60 2 edycji

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)

UIQ 2 edycji

UIQ 2.0 (system wykorzystany w części praktycznej)

UIQ 2.1

UIQ 3 edycji

UIQ 3.0

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.

Środowisko

Komercyjny

Debugowanie na telefonie

Microsoft Visual C++ (6.0,

7.0, 2005)

TAK

NIE

Microsoft Windows SDK

NIE

CodeWarrior

for

SymbianOS

TAK

TAK w wersji Professional i

OEM

Carbide C++ Express

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].

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.

• 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:

przydzielające pamięć (Open(), Create(), Allocate(), itp.)

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].

• 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

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

(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

Cleanup Stack - stos wskaźników do obiektów. Więcej na jego temat można znaleźć w literaturze [1].

ródłowych projektu [34]. Nazwa tego narzędzia to LeaveScan i jest nawet wbudowane w

niektóre wersje SDK.

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.

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.

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

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)

• 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.

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.

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].

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.

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.

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

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

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:

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.

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

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

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.

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

• 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.

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]

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.

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)

• 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

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:

Procesor: Intel Celeron/ Pentium III/ Pentium IV; AMD Duron/ Athlon

System operacyjny: Microsoft Windows 98 SE/ME/2000/XP

Pamięć RAM: co najmniej 32MB

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.

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.

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ć

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.

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].

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ń.

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.

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)

• 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ą.

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.

[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

[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

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

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