ˇCeské vysoké uˇcen´ı technické v Praze Fakulta elektrotechnická Katedra mˇeˇren´ı

(1)

Cesk´ ˇ e vysok´ e uˇ cen´ı technick´ e v Praze

Fakulta elektrotechnick´a Katedra mˇeˇren´ı

Framework pro ovl´ ad´ an´ı technologi´ı budov s lok´ aln´ı nab´ıdkou sluˇ zeb

leden 2017 Diplomant: Bc. Martin Vystrˇcil

Vedouc´ı pr´ace: doc. Ing. Jiˇr´ı Nov´ak, Ph.D.

(2)

Podˇ ekov´ an´ı

Rád bych podˇekoval pˇredevˇs´ım vedouc´ımu diplomové práce doc. Ing. Jiˇr´ımu Novákovi, Ph.D.

za pravidelné konzultace a vˇecné pˇripom´ınky v rámci nich. V neposledn´ı ˇradˇe velice dˇekuji své

(3)

Prohl´ aˇ sen´ı autora pr´ ace

Prohlaˇsuji, ˇze jsem pˇredloˇzenou práci vypracoval samostatnˇe a ˇze jsem uvedl veˇskeré pouˇzité informaˇcn´ı zdroje v souladu s Metodickým pokynem o dodrˇzován´ı etických princip˚u pˇri pˇr´ıpravˇe vysokoˇskolských závˇereˇcných prac´ı

V Praze dne . . . .

(4)

(5)

Anotace

Diplomová práce se zabývá návrhem a vývojem frameworku pro ovládán´ı technologi´ı budov s lokáln´ı nab´ıdkou sluˇzeb v závislosti na aktuáln´ı poloze uˇzivatele. V práci je provedena základn´ı reˇserˇse systém˚u, které jsou v dobˇe psan´ı práce bˇeˇznˇe dostupné. V práci je proveden detailn´ı rozbor pouˇzitých hardwarových souˇcástek. Detailn´ı popis vyvinutého software a popis principu urˇcován´ı polohy uˇzivatele. V práci je rovnˇeˇz diskutováno chován´ı systému v reálném testovac´ım zapojen´ı.

Kl´ıˇ cov´ a slova

lokáln´ı nab´ıdka sluˇzeb, poloha, ovládán´ı technologi´ı, framework

Summary

The object of this diploma thesis is building technology control framework with local service offer based on the location of user. Basic research of commonly used system was done at the begining of this thesis. Whole concept of the system is based on this research. There is detailed description of used hardware and software used for such system. In the text there is also description of algorithm used for locating the user. Discussion about qualities of this system tested in real environment is done.

Keywords

(6)

Obsah

1 Uvod´ 1

2 Reˇserˇse 3

2.1 Rozdˇelen´ı syst´em˚u . . . 3

2.2 Standardy . . . 5

2.2.1 KNX / EIB . . . 5

2.2.1.1 Komunikaˇcn´ı m´edia . . . 6

2.2.1.2 Adresace v s´ıti . . . 6

2.2.1.3 Individu´aln´ı a skupinov´e adresy . . . 6

2.2.1.4 V´yrobci implementuj´ıc´ı technologii KNX . . . 8

2.2.2 LonWorks . . . 8

2.2.2.1 Neuron chip . . . 8

2.2.2.2 Komunikaˇcn´ı m´edia . . . 8

2.2.2.3 Vys´ılaˇce . . . 9

2.2.2.4 Adresace v s´ıti . . . 9

2.2.2.5 V´yrobci implementuj´ıc´ı technologii LonWorks . . . 10

2.2.3 CIB . . . 10

2.2.3.1 Adresace v s´ıti . . . 10

2.2.3.2 V´yrobci implementuj´ıc´ı technologii CIB . . . 11

2.3 Shrnut´ı . . . 11

3 Základn´ı koncepce systému 11 4 Systémový návrh 13 4.1 Lokalizace uˇzivatele . . . 13

4.2 Infrastruktura . . . 14

5 Implementace 15 5.1 HW n´avrh ˇreˇsen´ı . . . 15

5.1.1 R´ıdic´ı poˇˇ c´ıtaˇc . . . 15

5.1.2 V´yvojov´e desky . . . 16

5.1.3 Stabiliz´ator napˇet´ı . . . 17

5.1.4 OneWire sbˇernice . . . 17

(7)

5.1.6 Bluetooth rozhran´ı . . . 18

5.1.6.1 Bluetooth modul . . . 19

5.1.7 Vstupnˇe - v´ystupn´ı rozˇsiˇruj´ıc´ı modul . . . 19

5.2 SW n´avrh ˇreˇsen´ı . . . 20

5.2.1 Embedded linux . . . 20

5.2.2 Qt Framework . . . 21

5.2.2.1 Sign´aly . . . 22

5.2.2.2 Sloty . . . 23

5.2.3 Object Handler . . . 23

5.2.3.1 Pˇrenos objekt˚u . . . 23

5.2.4 Communication Handler . . . 24

5.2.4.1 Bluetooth klient . . . 25

5.2.4.2 TCP/IP klient . . . 27

5.2.4.3 Vytvoˇren´ı spojen´ı . . . 28

5.2.5 Database Handler . . . 29

5.2.5.1 Inicializace datab´aze v serverov´e aplikaci . . . 30

5.2.5.2 Inicializace datab´aze v GUI aplikaci . . . 31

5.2.6 Serverov´a aplikace . . . 31

5.2.6.1 Perzistentn´ı ´uloˇziˇstˇe . . . 31

5.2.6.2 Bluetooth server . . . 31

5.2.6.3 TCP/IP server . . . 32

5.2.6.4 Nav´az´an´ı spojen´ı . . . 33

5.2.6.5 Ovˇeˇren´ı uˇzivatele - LDAP . . . 33

5.2.6.6 Ovˇeˇren´ı uˇzivatele - lok´aln´ı . . . 35

5.2.6.7 Pr´ace s identitou uˇzivatele . . . 36

5.2.6.8 R´ızen´ı technologie . . . .ˇ 37 5.2.7 Konfiguraˇcn´ı aplikace . . . 37

5.2.7.1 Horn´ı informaˇcn´ı panel . . . 37

5.2.7.2 Lev´y navigaˇcn´ı panel . . . 38

5.2.7.3 Prav´y panel obsahu . . . 39

5.2.7.4 Panel nastaven´ı vyt´apˇen´ı . . . 39

5.2.8 Uˇzivatelsk´a aplikace . . . 41

5.2.8.1 Rozd´ıly na pˇrihlaˇsovac´ı obrazovce . . . 41

5.2.8.2 Navigaˇcn´ı obrazovka . . . 42

(8)

5.2.8.3 Obrazovka ovl´ad´an´ı termostatu . . . 42

6 Testovac´ı zapojen´ı 43

6.1 Statické mˇeˇren´ı s´ıly signálu . . . 43 6.2 Dynamické chován´ı systému . . . 44

7 Z´avˇer 46

A UML diagram ObjectHandler 50

B UML diagram ObjectHandler pro objekt typu User 51

C Testovan´e zapojen´ı syst´emu 52

D Namˇeˇrené hodnoty testovaného zapojen´ı systému 53

(9)

Seznam obr´ azk˚ u

1 Systém pˇr´ımého ˇc´ıslicového ˇr´ızen´ı . . . 3

2 Sbˇernicov´y syst´em . . . 4

3 Schématické znázornˇen´ı KNX instalace . . . 5

4 Topologie KNX sbˇernice [2] . . . 7

5 Topologie zapojen´ı s´ıtˇe LON . . . 10

6 Diagram cel´eho syst´emu . . . 12

7 R´ıdic´ı deska Cubieboard2 . . . .ˇ 16 8 Bluetooth modul HM-10 . . . 19

9 Vnitˇrn´ı uspoˇr´ad´an´ı KAQV214 [15] . . . 20

10 Vnitˇrn´ı uspoˇr´ad´an´ı MOC3022 [16] . . . 20

11 Grafické znázornˇen´ı signál - slot [22] . . . 22

12 Minimáln´ı kostra pˇrenáˇsených dat . . . 24

13 Stavov´y automat pro Bluetooth komunikaci . . . 26

14 Stavov´y automat pro WiFi komunikaci . . . 27

15 Princip nav´az´an´ı spojen´ı . . . 29

16 Pˇr´ıklad dotazu a odpovˇedi pˇri navazov´an´ı komunikace . . . 30

17 Stavov´y automat TCP/IP serveru . . . 34

18 Schéma LDAP databáze pro testovac´ı úˇcely . . . 35

19 Obsah souboru mapov´an´ı skupin na povolen´e operace . . . 36

20 Rozloˇzen´ı pˇrihlaˇsovac´ı obrazovky konfiguraˇcn´ı aplikace . . . 38

21 Rozloˇzen´ı obrazovky ˇr´ızen´ı teploty . . . 40

22 Navigaˇcn´ı a obsahov´a obrazovka uˇzivatelsk´e aplikace . . . 42

23 ObjectHandler abstraktn´ı tˇr´ıda . . . 50

24 UML diagram tˇr´ıdy User . . . 51

25 Testovan´e zapojen´ı syst´emu . . . 52

26 Mˇeˇren´e body v testovan´em zapojen´ı . . . 53

(10)

Seznam tabulek

1 Základn´ı typy podporovaných pˇrenosových médi´ı . . . 9

2 Výpis moˇzných akc´ı vykonaných na objektech . . . 24

3 Výchoz´ı hodnoty nastavené v pr˚ubˇehu testován´ı systému . . . 39

4 Omezen´ı pro nastaven´ı teplotn´ıch ´urovn´ı . . . 40

5 Staticky namˇeˇren´e hodnoty v bodech dle obr´azku 26. . . 44

(11)

1 Uvod ´

R´ıdic´ı syst´ˇ emy jsou v dneˇsn´ı dobˇe bˇeˇznˇe dostupné a v ˇradˇe velkých budov i implementované.

Nicménˇe v pr˚ubˇehu implementace inteligentn´ıho ˇr´ıdic´ıho systémy do budovy se velmi ˇcasto stane, ˇze je systém pˇretechnizovaný. Taková instalace pak sice nab´ız´ı nespoˇcetné moˇznosti, ale stane se velmi obt´ıˇznˇe ovladatelnou. Ovladatelnost systému je zt´ıˇzena pˇredevˇs´ım vysokým poˇctem moˇzných nab´ıdek a ovládac´ıch prvk˚u, ze kterých je nutné vybrat ten správný.

Tato skuteˇcnost byla podnˇetem k vypracován´ı diplomové práce s c´ılem vylepˇsen´ı této situace t´ım, ˇze bude docházet k nab´ıdce pouze lokáln´ıch prvk˚u instalace. D´ıky lokáln´ı nab´ıdce dojde k razantn´ımu sn´ıˇzen´ı poˇctu nab´ızených prvk˚u a t´ım k vyˇsˇs´ı pˇrehlednosti uvnitˇr aplikace. Základn´ım stavebn´ım prvkem systému s podporou lokáln´ı nab´ıdky je lokalizace uˇzivatele uvnitˇr budovy.

Základn´ı úvahou je moˇzné doj´ıt k tomu, ˇze rozdˇelen´ı systému na celky menˇs´ı neˇz jednotlivé m´ıstnosti nemá smysl. V pˇr´ıpadˇe velkých kanceláˇr´ı, takzvaných open office, bude rozdˇelen´ı na m´ıstnosti pouze virtuáln´ı podle um´ıstˇen´ı jednotlivých pracoviˇst’. Poˇzadavek na pˇresnost urˇcen´ı polohy uˇzivatele uvnitˇr budovy tak nen´ı pˇr´ıliˇs vysoký.

Dalˇs´ı d˚uleˇzitou roli pˇri návrhu ˇcásti systému urˇceného pro lokalizaci uˇzivatele je výbˇer technologie, pomoc´ı které bude k lokalizaci docházet. V dneˇsn´ı dobˇe chytrých telefon˚u je tlak na to, aby bylo moˇzné co nejv´ıce technologi´ı budovy ovládat právˇe pomoc´ı mobiln´ıch telefon˚u. Prak- ticky se jiˇz nesetkáme s t´ım, ˇze by nˇekterý z výrobc˚u tˇechto systém˚u vyv´ıjel vlastn´ı zaˇr´ızen´ı, které by bylo urˇceno k pˇr´ıstupu k tˇemto technologi´ım. Aby byl systém konkurenceschopný, je nutné vyuˇz´ıt nˇekterou z jiˇz existujic´ıch technologi´ı, kterými bˇeˇzné chytré telefony disponuj´ı.

Dalˇs´ı nespornou výhodou chytrých telefon˚u je fakt, ˇze lidé si jiˇz zvykli m´ıt telefon neustále pˇri sobˇe a tak nedocház´ı ke sn´ıˇzen´ı uˇzivatelského komfortu.

Jiˇz pˇri návrhu systém˚u, které umoˇzˇnuj´ı ˇr´ızen´ı budov je nutné poˇc´ıtat alespoˇn s dvˇema základn´ımi body bezpeˇcnosti. Prvn´ım z nich je uváˇzen´ı toho, zda jsou si vˇsichni uˇzivatelé rovni.

Obvyklá situace vypadá tak, ˇze existuje hierarchická struktura, na jej´ımˇz vrcholu je správce systému a ve spodn´ıch patrech jsou jednotliv´ı uˇzivatelé. Kaˇzdému patru takové struktury je moˇzné pˇridˇelit jistá oprávnˇen´ı. Uˇzivatel˚um s niˇzˇs´ımi právy pak nen´ı umoˇznˇeno pˇridávat pˇr´ıpadnˇe odeb´ırat nové objekty v systému, ale pouze pracovat s jiˇz pˇripravenými objekty.

Druhým bodem je zabezpeˇcen´ı vlastn´ıho pˇrenosu pˇr´ıkaz˚u a dat. Pˇrenos dat ve vˇetˇsinˇe pˇr´ıpad˚u prob´ıhá prostˇrednictv´ım bezdrátového spojen´ı pomoc´ı technologie WiFi. Obsah komunikace (napˇr´ıklad pˇrihlaˇsovac´ı údaje) je moˇzné odposlechnout a pˇr´ıpadnˇe vyuˇz´ıt pro potˇreby útoku na systém. Je proto nutné veˇskerý pˇrenos dat ˇsifrovat pomoc´ı asymetrických ˇsifer. Tento zp˚usob ˇsifrován´ı je velmi rozˇs´ıˇrený a je povaˇzován za nejv´ıce bezpeˇcný.

(12)

V kapitole 2 je provedena základn´ı reˇserˇse dostupných technologi´ı vyuˇz´ıvaných k ˇr´ızen´ı inteligentn´ıch budov. Reˇserˇse je zamˇeˇrena pˇredevˇs´ım na z´ıskán´ı základn´ıho povˇedom´ı o standardn´ıch technologi´ıch, které jsou bˇeˇznˇe vyuˇz´ıvány. Nejsou zde diskutována jednotlivá ˇreˇsen´ı, která výrobci nab´ızej´ı, nebot’ výrobc˚u je mnoho a technologie se neustále vyv´ıjej´ı. Nicménˇe u kaˇzdé z uvedených technologi´ı je uveden alespoˇn jeden pˇredstavitel, který danou technologii implementuje. V této kapitole je rovnˇeˇz zm´ınˇena d˚uleˇzitost standardizace komunikaˇcn´ıch protokol˚u.

V kapitole 3 jsou pˇredstaveny základn´ı konstrukˇcn´ı prvky systému, které jsou bˇeˇznˇe vyuˇz´ıvány.

Nav´ıc je zde diskutována základn´ı koncepce navrhovaného ˇreˇsen´ı, vˇcetnˇe zaveden´ı základn´ıch pojm˚u.

V kapitole 4 je koncepce systému dále rozvedena do vˇetˇs´ıch detail˚u vˇcetnˇe pˇredstaven´ı principu lokalizace uˇzivatele a popisu pouˇzité technologie. Dále je v této kapitole popsáno základn´ı zapojen´ı systému, na kterém byla otestována jeho funkˇcnost.

V kapitole 5 je popsána implementace vzorového systému, který poskytuje nab´ıdku lokáln´ıch sluˇzeb. Je zde podrobnˇe rozebrán návrh hardwarové platformy, na které je realizována pˇr´ıpadová studie. Ve druhé ˇcásti kapitoly je podrobnˇe popsána softwarová ˇcást projektu. Popis softwarové ˇcásti projektu je rozdˇelen na jednotlivé stavebn´ı bloky tak, jak byl systém navrˇzen. Systém je realizován tak, aby potvrdil, ˇze lze pomoc´ı bˇeˇznˇe dostupných komponent dosáhnout lokalizace uˇzivatele a poskytnut´ı lokáln´ı nab´ıdky.

V kapitole 6 je popsána testovac´ı instalace a jsou zde shrnuty výsledky mˇeˇren´ı. Spolu se shrnut´ım dosaˇzených výsledk˚u jsou zde rovnˇeˇz diskutována moˇzná vylepˇsen´ı, která by vedla ke zvýˇsen´ı pˇresnosti pˇri urˇcován´ı polohy.

V závˇereˇcné kapitole jsou shrnuty základn´ı kroky, které vedly k úspˇeˇsné realizaci frameworku pro ovládán´ı technologi´ı budov s lokáln´ı nab´ıdkou. Závˇereˇcná kapitola je nav´ıc doplnˇena o dalˇs´ı budouc´ı kroky, které by vedly k rozˇs´ıˇren´ı systému.

(13)

2 Reˇ serˇ se

V následuj´ıc´ıch kapitolách je popsáno nˇekolik systém˚u slouˇz´ıc´ıch pro automatizaci infrastruktury budov. V posledn´ıch letech je téma automatizace infrastruktury velmi diskutované. Velký rozmach nastal pˇredevˇs´ım d´ıky velkému rozˇs´ıˇren´ı s´ıtˇe internet a k tomu navazuj´ıc´ıch sluˇzeb.

Kv˚uli vysokému zájmu z ˇrad výrobc˚u, ale i z ˇrad zákazn´ık˚u docház´ı k neustálému rozˇsiˇrován´ı stávaj´ıc´ıch a vzniku nových automatizaˇcn´ıch systém˚u.

Na trhu lze nalézt ˇradu výrobc˚u, kteˇr´ı se pokouˇs´ı prodat sv˚uj produkt, který nen´ı ˇzádným zp˚usobem standardizován. V pˇr´ıpadˇe, ˇze je takový produkt nainstalován, dojde dˇr´ıve nebo pozdˇeji k potˇrebˇe jeho rozˇs´ıˇren´ı, pˇr´ıpadnˇe údrˇzby. Po nˇekolika letech uˇz nemus´ı jeho mateˇrská firma existovat a kv˚uli chybˇej´ıc´ım standard˚um nebude moˇzné systém dále spravovat. Takový systém se pak stává nepouˇzitelným a nutnˇe dojde k jeho kompletn´ı náhradˇe.

2.1 Rozdˇelen´ı syst´em˚u

Hlavn´ım kritériem, podle kterého se ˇr´ıdic´ı systémy dˇel´ı, je jejich fyzické pˇripojen´ı k prvk˚um infrastruktury.

Prvn´ım (historicky jednoduˇsˇs´ım) typem je pˇr´ım´e ˇc´ıslicov´e ˇr´ızen´ı (Direct Digital Control) [1].

Zprvu se jednalo o jednoduchá zaˇr´ızen´ı, která nedisponovala velkým výkonem, ale byla urˇcena k ovládán´ı urˇcitého (typicky jednoho) procesu. Parametry ovládaných proces˚u byly pˇredem známé a po uveden´ı systému do provozu uˇz se pˇr´ıliˇs nemˇenily. Vzhledem k absenci dalˇs´ıch komunikaˇcn´ıch rozhran´ı nebylo moˇzné vytváˇret sloˇzitˇejˇs´ı s´ıtˇe obsahuj´ıc´ı napˇr´ıklad stovky spojených zaˇr´ızen´ı.

Rovnˇeˇz rozˇsiˇritelnost takových systém˚u nebyla bez vˇetˇs´ıch zásah˚u moˇzná.

Obrázek 1: Systém pˇr´ımého ˇc´ıslicového ˇr´ızen´ı

(14)

Jak je patrné z obrázku 1, jednoduchý systém vyˇzaduje veden´ı mnohonásobnˇe vyˇsˇs´ıho poˇctu spojovac´ıch prvk˚u. Rovnˇeˇz pˇridán´ı libovolného dalˇs´ıho rozˇs´ıˇren´ı se neobejde bez pˇridán´ı dalˇs´ıho spoje. Toto je nevyhovuj´ıc´ı pˇredevˇs´ım s ohledem na pracnost instalace, kdy kabeláˇz bývá uschována pod om´ıtkou, pˇr´ıpadnˇe v podhledu. Instalace kaˇzdého dalˇs´ıho spoje s sebou tak nese nejen náklad v podobˇe ceny spoje. Rovnˇeˇz je nutné zváˇzit i nepˇr´ıjemnosti v podobˇe omezen´ı uˇzivatelského komfortu a to po celé délce trasy nového spoje.

Druhým, pokroˇcilejˇs´ım typem jsou systémy sbˇernicové. Jak jiˇz název napov´ıdá, jedná se o systémy, které jsou vzájemnˇe propojeny sbˇernic´ı, pomoc´ı které mezi sebou komunikuj´ı. Nespor- nou výhodou tohoto typu systém˚u je vysoká m´ıra modularity, nebot’ je moˇzné sbˇernici témˇeˇr libovolnˇe rozˇsiˇrovat. U kaˇzdého typu sbˇernice ale existuj´ı maximáln´ı limity pˇripojených zaˇr´ızen´ı, které je nutné dodrˇzet. Rozˇsiˇritelnost je vykoupena pouˇzit´ım výkonnˇejˇs´ıch souˇcástek v koncových prvc´ıch (mikroprocesor˚u), coˇz má za následek vyˇsˇs´ı ceny sbˇernicových zaˇr´ızen´ı.

Obrázek 2: Sbˇernicový systém

Z obrázku 2 je patrné, ˇze komunikaˇcn´ı médium je sd´ılené mezi vˇsemi ˇr´ızenými procesy.

Instalace dalˇs´ıho procesu tedy nebude vyˇzadovat pˇridán´ı spoje aˇz k centráln´ımu prvku, ale pouze k nejbliˇzˇs´ımu jiˇz instalovanému. D´ıky tomuto faktu je moˇzné uspoˇrit nejen materiál a ˇcas strávený instalac´ı, ale také minimalizovat sn´ıˇzen´ı uˇzivatelského komfortu na minimum.

(15)

Z výˇse popsaného rozdˇelen´ı jasnˇe vyplývaj´ı výhody sbˇernicových systém˚u nad tˇemi pˇr´ımo ˇr´ızenými a proto jsou témˇeˇr vˇsechny nové instalace navrhovány jako sbˇernicové [1].

2.2 Standardy

D˚uleˇzitost standardizace jiˇz byla popsána v úvodn´ı kapitole. V následuj´ıc´ıch kapitolách budou detailnˇe popsány tˇri bˇeˇznˇe pouˇz´ıvané standardy. Jedná se o standardKNX, standardLonWorks a standard CIB. Kromˇe tˇechto dvou základn´ıch standard˚u se m˚uˇzeme setkat s ˇradou menˇs´ıch standard˚u, ty vˇsak ˇcasto nepokrývaj´ı celou ˇskálu automatizace. Patˇr´ı mezi nˇe napˇr´ıklad standard Dali, který je zamˇeˇren na ˇr´ızen´ı osvˇetlen´ı.

U kaˇzdého ze standard˚u je uvedena norma, v n´ıˇz je moˇzné nalézt jeho kompletn´ı specifikaci. V tomto textu jsou uvedeny pouze zásadn´ı informace, d´ıky kterým je moˇzné spatˇrit hlavn´ı rozd´ıly mezi nimi.

2.2.1 KNX / EIB

Je pr˚umyslový komunikaˇcn´ı sytém, který se v systémové technice budov pouˇz´ıvá pro s´ıt’ové informatické spojen´ı zaˇr´ızen´ı. Implementace je pˇrizp˚usobena elektrotechnické instalaci, ˇc´ımˇz jsou zajiˇstˇeny funkce a automatizované procesy v budovˇe [1].

Zapojen´ı KNX systému v budovˇe je schematicky znázornˇeno na obrázku 3. Z obrázku je patrná sbˇernicová struktura s centráln´ım rozvodem.

Obrázek 3: Schématické znázornˇen´ı KNX instalace

(16)

2.2.1.1 Komunikaˇcn´ı m´edia

Komunikaˇcn´ı protokol je popsán v mezinárodn´ım standardu ISO 14543. Standardem je pod- porována celá ˇrada pˇrenosových médi´ı. Patˇr´ı mezi nˇe kroucený pár (oznaˇcovaný jako KNX.TP) nebo napˇr´ıklad rádiový pˇrenos oznaˇcovaný jako KNX.RF. D´ıky ˇsiroké ˇskále podporovaných pˇrenosových cest je moˇzné systém KNX napojit i na jiˇz existuj´ıc´ı rozvody, at’ uˇz se jedná o kroucené páry nebo pˇrenos po silové ˇcásti veden´ı. Zat´ımco pˇrenos po médiu, které je vyhrazeno ˇcistˇe pro potˇreby systému KNX (kroucený pár) prob´ıhá témˇeˇr bez chyb, tak v pˇr´ıpadˇe sd´ıleného média (rádio, silnoproudá instalace) m˚uˇze docházet (a docház´ı) k silnému ruˇsen´ı.

Napájen´ı vˇsech úˇcastnických stanic na sbˇernici je vyˇreˇseno pomoc´ı zdroje pˇripojeného pˇr´ımo na sbˇernici. Kaˇzdé zaˇr´ızen´ı tedy staˇc´ı ke sbˇernici pˇripojit pouze jedn´ım párem vodiˇc˚u, odpadá potˇreba extern´ıho napájen´ı. Výˇse popsaný zp˚usob napájen´ı je moˇzný pouze v pˇr´ıpadˇe, ˇze je vyuˇzita nˇekterá z variant vyuˇz´ıvaj´ıc´ı fyzického pˇrenosového kanálu. V pˇr´ıpadˇe vyuˇzit´ı rádiového pˇrenosu je stále nutnost´ı zajistit napájen´ı jednotlivých prvk˚u sbˇernice.

2.2.1.2 Adresace v s´ıti

KNX s´ıt’ je rozdˇelena do tˇr´ı úrovn´ı. Do nejvyˇsˇs´ı (páteˇrn´ı) úrovnˇe se pˇripojuj´ı oblastn´ı spojky, které slouˇz´ı k propojován´ı jednotlivých oblast´ı. V pˇr´ıpadˇe vyuˇzit´ı v´ıce neˇz jedné oblasti v instalaci je vhodné zavést logické dˇelen´ı, napˇr´ıklad jedna oblast m˚uˇze odpov´ıdat jednomu patru budovy.

Maxim´aln´ı poˇcet adresovateln´ych oblast´ı je 15.

Druhým, niˇzˇs´ım patrem hierarchie jsou linie, ke kterým jsou jiˇz pˇripojovány jednotlivé komponenty systému. Stejnˇe jako je moˇzné pˇredstavit si oblast jako jedno patro budovy, je moˇzné si linii pˇredstavit jako automatizaˇcn´ı prvky stejného typu (zásuvky / ˇzaluzie / vyp´ınaˇce). Ma- ximáln´ı poˇcet adresovatelných lini´ı je 15, pˇriˇcemˇz linie jsou mezi sebou propojovány pomoc´ı liniových spojek.

Kaˇzdá z lini´ı m˚uˇze být dále rozdˇelena na 4 segmenty. Segmenty jsou k linii pˇripojeny pomoc´ı liniových opakovaˇc˚u. Maximáln´ı poˇcet prvk˚u pˇripojených do jednoho segmentu je 64. Maximáln´ı moˇzný poˇcet prvk˚u zapojených do systému je pak 2¹⁶= 65536 [2].

Hierarchické rozdˇelen´ı systému je schematicky znázornˇeno na obrázku 4.

2.2.1.3 Individu´aln´ı a skupinov´e adresy

Kaˇzdý prvek pˇripojený do s´ıtˇe KNX mus´ı m´ıt pˇriˇrazenu unikátn´ı (individuáln´ı) adresu.

Celá adresa jednoho prvku pˇripojeného ve sbˇernici se skládá ze tˇr´ı ˇc´ısel oddˇelených teˇckou - oblast.linie.prvek (napˇr´ıklad 1.1.2) [1].

(17)

Obr´azek 4: Topologie KNX sbˇernice [2]

Pokud jsou v individuáln´ı adrese prvku nˇekterá pole rovna nule, pak se jedná o speciáln´ı adresy. Napˇr´ıklad adresa 1.12.0 je pˇriˇrazena liniové spojce v oblasti 1, linii 12. Podobnˇe je tomu u adresy 2.0.0, která oznaˇcuje oblastn´ı spojku um´ıstˇenou ve druhé oblasti [1].

Pro zjednoduˇsen´ı programován´ı rozsáhlých systém˚u byl ve standardu zaveden speciáln´ı typ adres skupinové adresy. Skupinové adresy lze poznat podle zp˚usobu jejich zápisu, pˇri nˇemˇz se vyuˇz´ıvá lom´ıtek nam´ısto teˇcek, napˇr´ıklad 1/2, pˇr´ıpadnˇe 1/2/3. Pˇri zavádˇen´ı skupinových adres je vhodné logické rozdˇelen´ı systému do skupin, napˇr´ıklad skupina 1/ bude pouˇzita pro ˇr´ızen´ı osvˇetlen´ı, zat´ımco skupina 2/ bude pouˇzita pro ˇr´ızen´ı ˇzaluzi´ı. Za oddˇelovac´ım lom´ıtkem pak m˚uˇze následovat kupˇr´ıkladu oznaˇcen´ı m´ıstnosti. Skupinová adresa 1/1 by pak ˇr´ıdila osvˇetlen´ı v m´ıstnosti obývac´ı pokoj, zat´ımco skupinová adresa 1/2 by ˇr´ıdila osvˇetlen´ı v m´ıstnosti kuchynˇe [1].

Ve standardu je zahrnuta podpora pro dvouúrovˇnové, pˇr´ıpadnˇe tˇr´ıúrovˇnové adresován´ı. Po- kud se ale projektant rozhodne pro jeden ze zp˚usob˚u, zvolený zp˚usob mus´ı být pouˇzit v celém systému. Pˇri pouˇzit´ı dvouúrovˇnové adresace (ˇcastˇejˇs´ı vyuˇzit´ı) jsou 4 bity vyuˇzity pro adresaci hlavn´ı skupiny a 11 bit˚u je pouˇzito pro adresaci podskupiny. ˇC´ıselnˇe je tedy pouˇzitelných 16 hlavn´ıch skupin a aˇz 2048 podskupin. Podle doporuˇcen´ı z [1] je vhodné skupinu 0 pouˇz´ıvat pro signalizaci alarm˚u.

(18)

2.2.1.4 V´yrobci implementuj´ıc´ı technologii KNX

Standard KNX je jedn´ım z nejrˇs´ıˇreji pouˇz´ıvaných standard˚u. S t´ımto souvis´ı také to, ˇze výrobce ˇr´ıdic´ıch systém˚u s podporou KNX je moˇzné naj´ıt v nejr˚uznˇejˇs´ıch zem´ıch. Jako pˇr´ıklady lze uvést ˇspanˇelskou firmu Futurasmus, anglickou firmuLivinghometech, pˇr´ıpadnˇe ˇc´ınskou firmu HDL, která má poboˇcku i v ˇCeské Republice.

2.2.2 LonWorks

Oznaˇcen´ı LonWorks v sobˇe zahrnuje celou ˇradu podruˇzných zaˇr´ızen´ı. Koˇrenová ˇcást názvu této technologie - Lon znamená Local operating network [3]. Volnˇe pˇreloˇzeno jako lokáln´ı s´ıt’ové sluˇzby.

Samotný komunikaˇcn´ı protokol oznaˇcovaný jako LonTalk byl vyvinut spoleˇcnost´ı Echelon v roce 1989 [5] a je popsán ve standardu ISO/IEC 14908-1. Jedná se o protokol specificky navrˇzený pro ˇr´ıdic´ı úˇcely, který slouˇz´ı pro komunikaci mezi dvˇema koncovými body (peer to peer).

2.2.2.1 Neuron chip

Hlavn´ım stavebn´ım prvkem technologie LonWorks jsou mikrokontroléry nazývané Neuron Chip. Kaˇzdý mikrokontrolér je sloˇzen ze tˇrech osmibitových procesorových jednotek, fyzické pamˇeti a referenˇcn´ı implementace LonTalk protokolu. Kaˇzdý vyrobený ˇcip nav´ıc obsahuje svˇetovˇe unikátn´ı identifikaˇcn´ı ˇc´ıslo - Neuron ID [3].

Dvˇe procesorové jednotky se staraj´ı o komunikaci prostˇrednictv´ım LonTalk protokolu. Tˇret´ı procesorová jednotka je dostupná pro potˇreby vlastn´ı aplikace. Kompatibilita zapojen´ı ˇcip˚u od r˚uzných výrobc˚u je zajiˇstˇena d´ıky tomu, ˇze kaˇzdý Neuron Chip v sobˇe jiˇz implementuje kompletn´ı rozhran´ı pro komunikaci prostˇrednictv´ı LonTalk s´ıtˇe [3].

2.2.2.2 Komunikaˇcn´ı m´edia

Podobnˇe jako systém KNX i LonWorks lze provozovat na ˇradˇe fyzických médi´ı. Tabulka 1 je pˇrevzatá z [3] a uvád´ı základn´ı typy podporovaných fyzických médi´ı.

Jak je z tabulky patrné, pˇrenosové rychlosti jsou niˇzˇs´ı (ˇrádovˇe stovky kbps), stále ale naprosto vyhovuj´ıc´ı pro pˇrenos krátkých zpráv. V pˇr´ıpadˇe vyuˇzit´ı typu TP/FT-10 lze fyzické zapojen´ı realizovat bez jakýchkoliv omezen´ı v topologii. Zapojen´ı lze provést do hvˇezdy, lineárn´ı sbˇernice, pˇr´ıpadnˇe i do kruhu [3]

(19)

Oznaˇcen´ı vys´ılaˇce M´edium Pˇrenosov´a rychlost Standard

IP-852 IP tunelov´an´ı N/A ISO/IEC 14908-4

PL-20 (A/C/N) Silové rozvody 3.6 - 5 kbps ISO/IEC 14908-3 TP/FT-10 Kroucená dvojlinka 78.6 kbps ISO/IEC 14908-2 TP/XF-1250 Kroucená dvojlinka 1.25 Mbps ISO/IEC 14908-2

Tabulka 1: Základn´ı typy podporovaných pˇrenosových médi´ı

2.2.2.3 Vys´ılaˇce

Kaˇzdý neuron ˇcip obsahuje referenˇcn´ı implementaci protokolu LonTalk. Aby byla zajiˇstˇena modulárnost systému, doˇslo k oddˇelen´ı vlastn´ıho zpracován´ı dat (uvnitˇr neuron ˇcipu) a vlastn´ı komunikaci se sbˇernic´ı (prostˇrednictv´ım vys´ılaˇce).

D´ıky tomuto rozdˇelen´ı je moˇzné v jedné s´ıti vyuˇz´ıvat ˇcipy a vys´ılaˇce r˚uzných výrobc˚u.

D˚uleˇzité je pouze zachován´ı stejného typu vys´ılaˇce / pˇrij´ımaˇce na obou stranách.

Podobnˇe jako v pˇr´ıpadˇe instalace KNX, i pˇri vytváˇren´ı LON s´ıtˇe je moˇzné jej´ı dˇelen´ı. Pˇri rozdˇelen´ı instalace se pouˇz´ıvá pojm˚u jako pods´ıt’, s´ıt’, pˇr´ıpadnˇe doména. Hierarchicky je s´ıt’

zn´azornˇena na obr´azku 5.

Nejjednoduˇsˇs´ı instalace, pˇri nichˇz je zapojeno maximálnˇe 128 úˇcastn´ık˚u, je moˇzné provozovat jako samostatné s´ıtˇe. V pˇr´ıpadˇe vyuˇzit´ı vys´ılaˇc˚u napájených ze sbˇernice je poˇcet omezen na 64.

Rozˇs´ıˇren´ı takovéto s´ıtˇe na 128 prvk˚u je moˇzné s vyuˇzit´ım opakovaˇc˚u. Pokud jsou pro komunikaci vyuˇzity vys´ılaˇce s vlastn´ım zdrojem napájen´ı, je maximáln´ı poˇcet úˇcastn´ık˚u zvýˇsen aˇz na 128.

V pˇr´ıpadˇe, ˇze je nutné zapojit v´ıce úˇcastn´ık˚u, je jiˇz zapotˇreb´ı rozdˇelit s´ıt’ na v´ıce pods´ıt´ı. Jako oddˇelovac´ıch prvk˚u se vyuˇz´ıvá zaˇr´ızen´ı nazývanýchroutery. Smˇerován´ı komunikace prob´ıhá tak, ˇze pokud nebyl telegram doruˇcen do pods´ıtˇe daného routeru, je pˇreposlán do dalˇs´ıho segmentu spojené s´ıtˇe. Routery nav´ıc podporuj´ı spojen´ı v´ıce pods´ıt´ı postavených na r˚uzných technologi´ıch do jedné s´ıtˇe.

Spojen´ım v´ıce s´ıt´ı vznikaj´ı nejvˇetˇs´ı adresovatelné celkydomény. V jedné doménˇe je moˇzné spojit aˇz 255 pods´ıt´ı (router˚u). V pˇr´ıpadˇe, ˇze by ani tento poˇcet nebyl dostaˇcuj´ıc´ı, je moˇzné spojit dalˇs´ı dvˇe domény pomoc´ı výkonného routeru.

Nejvyˇsˇs´ı poˇcet pˇripojených uzl˚u v jedné doménˇe je 255∗127 = 32385. Maximáln´ı velikost s´ıtˇe pak m˚uˇze vzniknout spojen´ım dvou domén, ˇc´ımˇz se poˇcet uzl˚u zdvojnásob´ı.

(20)

Obr´azek 5: Topologie zapojen´ı s´ıtˇe LON

2.2.2.5 V´yrobci implementuj´ıc´ı technologii LonWorks

Jedná se o druhého z nejvˇetˇs´ıch výrobc˚u, který je rozˇs´ıˇrený pˇredevˇs´ım v zámoˇr´ı. Mezi hlavn´ı výrobce patˇr´ı napˇr´ıklad americká spoleˇcnost Allen-Bradley, nˇemecká spoleˇcnostWilo, pˇr´ıpadnˇe francouzská spoleˇcnost Schneider. Dvˇe posledn´ı jmenované spoleˇcnosti maj´ı nav´ıc poboˇcky v Cesk´ˇ e Republice.

2.2.3 CIB

Technologie, potaˇzmo standard CIB (Common Installation Bus) je vlastnictv´ım ˇceské firmy ELKO ep. Jedná se podobnˇe jako u dvou výˇse popsaných standard˚u o sbˇernicovou technologii. Zapojen´ı s´ıtˇe je v podstatˇe libovolné, vyjma zapojen´ı do kruhu. Komunikace prob´ıhá bud’

bezdrátovˇe, pˇr´ıpadnˇe prostˇrednictv´ım krouceného páru.

Na sbˇernici je vˇzdy nutné pˇripojit hlavn´ı ˇr´ıdic´ı jednotku, která jednak ˇr´ıd´ı komunikaci na sbˇernici a druhak se stará o jej´ı napájen´ı. Maximáln´ı poˇcet pˇripojených uzl˚u na jedné vˇetvi je omezen na 32. Jednotky jsou proto vybaveny alespoˇn dvˇema oddˇelenými vˇetvemi. Dalˇs´ı vˇetve sbˇernice je moˇzné pˇripojit pomoc´ı rozˇsiˇruj´ıc´ıch modul˚u [7].

Jako pˇr´ıklad lze uvést centráln´ı jednotku CU3-01M, která disponuje dvˇema svorkami pro pˇripojen´ı k CIB sbˇernici. Jednotka nav´ıc umoˇzˇnuje rozˇs´ıˇren´ı aˇz o dalˇs´ıch 8 extern´ıch komu- nikaˇcn´ıch jednotek, z nichˇz kaˇzdá extern´ı jednotka disponuje rovnˇeˇz dvˇema svorkami pro pˇripojen´ı ke sbˇernici. Celkovˇe lze tedy zapojit aˇz 2∗32 + 8∗2∗32 = 576 uzl˚u [8].

(21)

2.2.3.2 V´yrobci implementuj´ıc´ı technologii CIB

Standard CIB je v souˇcasné dobˇe implementována pouze v systému iNels, jeˇz je vyv´ıjen stejnou spoleˇcnost´ı jako vlastn´ı technologie. Jin´ı výrobci implementuj´ıc´ı CIB nebyli nalezeni.

2.3 Shrnut´ı

Vˇsechny výˇse popsané systémy poskytuj´ı dostateˇcné rozhran´ı pro ovládán´ı inteligentn´ı elektroinstalace a kvalitn´ı uˇzivatelské rozhran´ı potˇrebné k tomu, aby je bylo moˇzné efektivnˇe vyuˇz´ıvat.

D´ıky standard˚um, které jsou propracovany do nejmenˇs´ıch detail˚u a jiˇz ˇradu let vyuˇz´ıvany je moˇzné ve vývoji pokroˇcit kupˇredu a v´ıce se zamˇeˇrit na uˇzivatelský komfort.

Vˇsechny systémy je moˇzné ˇskálovat do obrovských celk˚u. V takto rozsáhlých systémech pak nen´ı z uˇzivatelského hlediska snadné naj´ıt potˇrebné objekty. M˚uˇze tak nastat situace, kdy celá budova bude m´ıt implementovanou podporu pro automatizaci, ta vˇsak nebude vyuˇz´ıvána z d˚uvodu uˇzivatelsky nepohodlného rozhran´ı.

Nab´ız´ı se zde ˇreˇsen´ı v podobˇe nab´ıdky pouze té ˇcásti automatizace, kterou je moˇzné v daném m´ıstˇe (m´ıstnosti) vyuˇz´ıt. Uˇzivatel tak nebude nucen vyhledávat konkrétn´ı objekt mezi stovkami dalˇs´ıch, ale seznam objekt˚u se omez´ı na des´ıtky. Bˇehem reˇserˇse se nepodaˇrilo nalézt implementaci takovéto funkce u jiˇz nab´ızených systém˚u. Skuteˇcnost, ˇze taková funkce nen´ı zat´ım implemen- tována m˚uˇze být zp˚usobena napˇr´ıklad i t´ım, ˇze by nebylo moˇzné takovéto ˇreˇsen´ı realizovat.

3 Z´ akladn´ı koncepce syst´ emu

Systémy pro automatizaci domác´ı infrastruktury se skládaj´ı ze tˇr´ı základn´ıch stavebn´ıch prvk˚u. Prvn´ım, nejd˚uleˇzitˇejˇs´ım prvkem je vˇzdy poˇc´ıtaˇc s ˇr´ıdic´ım softwarem, který se stará o vlastn´ı automatizaci systému. Aby bylo uˇzivateli umoˇznˇeno jednoduchým zp˚usobem vstoupit do systému a provádˇet v nˇem zmˇeny, je nutné systém vybavit o dalˇs´ı podp˚urný software. V pˇr´ıpadˇe této realizace se jedná o dvˇe aplikace, které je moˇzné spustit na mobiln´ım telefonu, pˇr´ıpadnˇe na standardn´ım poˇc´ıtaˇci.

Pˇrehledové schéma celého systému je zobrazeno na obrázku 6. Centráln´ım prvkem automatizace jeˇr´ıdic´ı server, který kromˇe celkové konfigurace nab´ız´ı funkˇcn´ı ˇr´ızen´ı vˇsech automatizo- vaných celk˚u. Kromˇe software pro automatizaci, je na ˇr´ıdic´ım serveru spuˇstˇen i software urˇcený pro komunikaci s uˇzivatelskou nebo konfiguraˇcn´ı aplikac´ı.

R´ıdic´ı serverˇ je centráln´ım prvkem automatizace, který se stará nejen o dohled nad celým systémem, ale také o komunikaci s uˇzivatelem. V pˇr´ıpadˇe rozsáhlých budov je velmi vhodné nasadit takovýchto prvk˚u v´ıce. Nebude pak docházet k zahlcen´ı jednoho centráln´ıho prvku, ale

(22)

dojde k rozloˇzen´ı zátˇeˇze mezi jednotlivé body. U takového zapojen´ı vznikaj´ı ˇcásteˇcnˇe samostatné jednotky. V pˇr´ıpadˇe výpadku nedojde k omezen´ı dostupnosti veˇskeré technologie, ale pouze k jej´ımu lokáln´ımu omezen´ı.

Uˇzivatelská aplikace je zamýˇslena pro bˇeh na mobiln´ıch terminálech a uˇzivateli nab´ız´ı jed- noduché rozhran´ı pro vzdálené ovládán´ı a dohledován´ı dostupných ˇcást´ı systému. Typickými akcemi, jeˇz je moˇzné vykonávat, je ovládán´ı automatizaˇcn´ıch celk˚u (osvˇetlen´ı, topen´ı, venti- lace). Nav´ıc umoˇzˇnuje pˇridáván´ı plánovaných akc´ı jako je nastaven´ı poˇzadované teploty v daný ˇcas, pˇr´ıpadnˇe automatické staˇzen´ı st´ın´ıc´ı techniky.

Konfiguraˇcn´ı aplikace je urˇcena pro celkovou správu systému, která zahrnuje výˇse popsané vzdálené ovládán´ı a nastaven´ı ˇcasových událost´ı. Nav´ıc disponuje moˇznostmi nastaven´ı nových objekt˚u do ˇr´ızeného systému.

Obrázek 6: Diagram celého systému

Na komerˇcn´ım trhu je dostupná celá ˇrada systém˚u od r˚uzných dodavatel˚u. Kaˇzdý z nich ˇreˇs´ı potˇrebu konfiguraˇcn´ı aplikace po svém. ˇRada dostupných aplikac´ı urˇcených pro konfiguraci domác´ı automatizace je zaloˇzena na principech grafického programován´ı. V pˇr´ıpadˇe grafického programován´ı se umist’uj´ı grafické elementy na plochu pˇredstavuj´ıc´ı daný objekt, tyto elementy se poté graficky spojuj´ı ˇcarami pˇredstavuj´ıc´ımi logické spoje. V pˇr´ıpadˇe rozumného dˇelen´ı systému a stálého udrˇzován´ı poˇrádku na ploˇse jsou tyto systémy výhodné. Pokud ale operátor umist’uje objekty chaoticky, dojde v krátkém obdob´ı ke ztrátˇe pˇrehledu nad projektem. Z toho d˚uvodu byla v konfiguraˇcn´ı aplikaci vybrána metoda textového zadáván´ı konfigurace.

D´ıky textové konfiguraci je poˇrádek v aplikaci udrˇzován automaticky a je vˇzdy stejný. Systém si neklade za c´ıl být obecný pro vˇsechna pouˇzit´ı, ale zprostˇredkovat jednoduché rozhran´ı pro vˇsechny uˇzivatele a být dostateˇcnˇe obecný na to, aby dovolil nastaven´ı vˇsech bˇeˇznˇe pouˇz´ıvaných sekvenc´ı.

Hardwarová platforma je zaloˇzena na Linuxovém jednodeskovém poˇc´ıtaˇci, který má do- stateˇcný poˇcet vstupn´ıch a výstupn´ıch pin˚u a zároveˇn s nimi nab´ız´ı i r˚uzná komunikaˇcn´ı rozhran´ı.

(23)

pˇripojen´ı ke sbˇernici je n´avrhem hardware podporov´ano.

Navrˇzený komunikaˇcn´ı protokol je zaloˇzen na pˇrenosu zpráv ve formátu XML. Tento formát byl vybrán pˇredevˇs´ım s ohledem na moˇznosti jeho budouc´ıho vyuˇzit´ı. Veˇskerá data, která jsou formátována pomoc´ı XML, je moˇzné velmi snadno vyuˇz´ıt i mimo poskytovanou softwarovou architekturu. Nab´ız´ı se napˇr´ıklad moˇznost sbˇeru aktuáln´ıch teplot z jednotlivých m´ıstnost´ı a jejich následné vyhodnocen´ı pomoc´ı extern´ıch aplikac´ı.

Protokol je navrˇzen s ohledem na bezpeˇcnost svých uˇzivatel˚u. Veˇskerá komunikace je proto ˇsifrována pomoc´ı protokolu TLS1.2. Následné ovˇeˇren´ı pˇr´ıstupových údaj˚u je porovnáno proti nastavenému LDAP serveru. Komunikace mezi ˇr´ıdic´ım serverem a LDAP serverem je ˇsifrována.

4 Syst´ emov´ y n´ avrh

Ovládán´ı menˇs´ı budovy (napˇr´ıklad rodinný d˚um) nemá smysl optimalizovat z hlediska usnadnˇen´ı navigace v aplikaci. Rodinný d˚um má typicky do 10 m´ıstnost´ı, nalezen´ı té správné je tedy snadné a lehce proveditelné. Naproti tomu v pˇr´ıpadˇe rozsáhlé instalace (napˇr´ıklad administrativn´ı budova / ˇskola), kde mohou být stovky m´ıstnost´ı, se navigace v aplikaci stane obt´ıˇznou aˇz otravnou velmi snadno.

Stávaj´ıc´ı systémy pracuj´ı tak, ˇze se uˇzivatel pˇripoj´ı na pˇredem známou adresu (server), kde bˇeˇz´ı pˇr´ısluˇsná aplikace. Z této aplikace se stáhnou potˇrebná data tak, aby bylo moˇzné z uˇzivatelova zaˇr´ızen´ı ovládat pˇr´ısluˇsný automatizaˇcn´ı celek.

Vylepˇsen´ı souˇcasného zp˚usobu pˇripojen´ı spoˇc´ıvá v implementaci systému, který m´ısto uˇzivatele rozhodne, k jaké adrese se pˇripojit a jaká data pˇr´ıpadnˇe stáhnout. Aby bylo moˇzné implementovat vylepˇsen´ı stávaj´ıc´ıch systém˚u, je nutné znát alespoˇn pˇribliˇznou polohu uˇzivatele.

4.1 Lokalizace uˇzivatele

Lokalizovat uˇzivatele jako ˇzivou osobu uvnitˇr budovy nen´ı se souˇcasnou technologi´ı prove- ditelné. Lokalizaci je nutné omezit na elektronický pˇr´ıstroj, který bude m´ıt uˇzivatel neustále u sebe. V dneˇsn´ı dobˇe vˇsak má vˇetˇsina lid´ı alespoˇn jeden chytrý mobiln´ı telefon, který u sebe ne- ustále nos´ı. Z nich pak mohou být tyto systémy ˇr´ızeny, a tak navrhované ˇreˇsen´ı nezavád´ı ˇzádné dodateˇcné komplikace.

Systém se tedy omez´ı na lokalizaci chytrého mobiln´ıho telefonu uvnitˇr budovy. Vzhledem k tomu, ˇze mobiln´ı telefon je pˇrenosné zaˇr´ızen´ı, je nutné lokalizaci provést pomoc´ı nˇekteré z bezdrátových technologi´ı. K tˇemto technologi´ım, které se v souˇcasné dobˇe u chytrých telefon˚u nab´ızej´ı zcela samozˇrejmˇe, patˇr´ı WiFi a Bluetooth. U nˇekterých draˇzˇs´ıch model˚u se pak nab´ız´ı

(24)

Rozhran´ı NFC (Near Field Communication) je urˇceno pro pomalý pˇrenos na velmi malé vzdálenosti. ˇRádovˇe se jedná o pˇrenosy na vzdálenost 10 - 15 cm [9], pˇresné specifikace vycházej´ı z normy ISO/IEC 18092. Takto krátká komunikaˇcn´ı vzdálenost je pro potˇreby navrhovaného systému nedostateˇcná, nen´ı proto moˇzné tohoto rozhran´ı vyuˇz´ıt.

Rozhran´ı WiFi (Wireless Fidelity) je urˇceno pro rychlý pˇrenos dat na vzdálenost ˇrádovˇe des´ıtky aˇz stovky metr˚u. Technologie je popsána ve standardu IEEE 802.11. WiFi technologie je bˇeˇznˇe vyuˇz´ıvána pro vysokorychlostn´ı pˇripojen´ı k internetu, a proto je velmi pravdˇepodobné, ˇze bude tato s´ıt’ uvnitˇr budov jiˇz implementována. Jako ˇreˇsen´ı lokalizace by se tedy nab´ızelo vyuˇzit´ı jiˇz existuj´ıc´ı WiFi infrastruktury. Jakkoliv se toto ˇreˇsen´ı m˚uˇze zdát výhodné, zejména s ohledem na jiˇz existuj´ıc´ı infrastrukturu, bylo by nutné vytvoˇrit pˇresný model budovy spolu s rozm´ıstˇen´ım vys´ılaˇc˚u uvnitˇr. Poté by se dalo za pomoci triangulace mezi viditelnými WiFi vys´ılaˇci urˇcit pˇribliˇznou polohu. Nicménˇe sestaven´ı takového modelu a následné otestován´ı celého systému by vyˇzadovalo nezanedbatelnˇe vysoké úsil´ı.

Pˇri navrhován´ı WiFi s´ıtˇe jsou nav´ıc kladeny pˇresnˇe opaˇcné poˇzadavky, neˇz které jsou vhodné pro lokalizaci uˇzivatele. Hlavn´ım poˇzadavkem pˇri vytváˇren´ı bezdrátové s´ıtˇe je pouˇzit´ı co nejmenˇs´ıho poˇctu pˇr´ıstupových bod˚u k dostateˇcnému pokryt´ı co nejvˇetˇs´ı plochy [10].

Rozhran´ı Bluetooth bylo vyv´ıjeno s c´ılem umoˇznit pˇrenosy na kratˇs´ı vzdálenost (niˇzˇs´ı des´ıtky metr˚u), bez potˇreby sloˇzitého vytváˇren´ı infrastruktury [11]. Standard tedy uˇz ve své základn´ı podobˇe podporuje vytváˇren´ı malých s´ıt´ı o nˇekolika málo úˇcastn´ıc´ıch (piconet / scatternet).

V roce 2010 se standard nav´ıc rozˇs´ıˇril o ˇcást Bluetooth Low Energy. Technologie BLE nen´ı zpˇetnˇe kompatibiln´ı s technologi´ı klasického Bluetooth. Kaˇzdý z výrobc˚u Bluetooth ˇcip˚u se proto mus´ı jiˇz pˇri výrobˇe rozhodnout, zda podporovat oba standardy, nebo pouze jeden z nich [12].

Mezi hlavn´ı výhody BLE rozˇs´ıˇren´ı patˇr´ı pˇredevˇs´ım sn´ıˇzen´ı spotˇreby modul˚u a následnˇe zkrácen´ı odezvy pˇri navazován´ı komunikace. Nevýhodou je sn´ıˇzen´ı pˇrenosové rychlosti z ˇrádovˇe 2Mbit/s na 0.2Mbit/s [12].

D´ıky tomu, ˇze se v souˇcasné dobˇe technologie Bluetooth nevyuˇz´ıvá jako hlavn´ı informaˇcn´ı kanál, je moˇzné jej´ı vyuˇzit´ı k jiným úˇcel˚um. Lze si tedy pˇredstavit takové zapojen´ı, kdy dojde k optimáln´ımu pokryt´ı m´ıst, ve kterých se uˇzivatelé pohybuj´ı bez sn´ıˇzen´ı komfortu.

Pro lokalizaci uˇzivatele uvnitˇr budov bude z výˇse popsaných d˚uvod˚u pouˇzito bezdrátové rozhran´ı Bluetooth s podporou Low Energy standardu.

4.2 Infrastruktura

Pro úˇcely testován´ı byl systém zapojen v bytˇe o velikosti 2+kk. Systém byl instalován podle pˇredpokládané instalace uvnitˇr administrativn´ıch budov. Nainstalovány byly dva servery tak,

(25)

aby bylo moˇzné správnˇe testovat poskytován´ı lokáln´ı nab´ıdky systémem.

Schéma instalovaného bytu spolu se znázornˇeným rozm´ıstˇen´ım ˇr´ıdic´ıch server˚u je um´ıstˇeno v pˇr´ıloze na obrázku 25. Vzhledem k tomu, ˇze v dobˇe testován´ı byly dostupné pouze dva servery, bylo moˇzné rozliˇsit pouze dvˇe skupiny uˇzivatel˚u. Pˇredpokládané výsledky jsou takové, ˇze do prvn´ı skupiny budou zaˇrazeni uˇzivatelé, kteˇr´ı se nacházej´ı bud’ v prostoru kuchynˇe, pˇr´ıpadnˇe obývac´ıho pokoje. Do druhé skupiny budou zaˇrazeni uˇzivatelé, kteˇr´ı se nacházej´ı v prostoru pokoje.

Ve schématu zapojen´ı m˚uˇzeme vidˇet, ˇze m´ısto kolem vstupu do bytu, pˇr´ıpadnˇe na chodbˇe vedouc´ı do obou pokoj˚u, nen´ı pˇr´ımo pokryto ˇzádným ze server˚u. K tomuto doˇslo v d˚usledku zapojen´ı pouhých dvou server˚u, v pˇr´ıpadˇe reálné instalace by se v tomto m´ıstˇe nacházel dalˇs´ı, tˇret´ı server.

5 Implementace

V následuj´ıc´ı ˇcásti textu budou popsány kroky vedouc´ı k implementaci inteligentn´ıho systému automatizace. Hardwarové komponenty systému byly vybrány tak, aby umoˇznily rychlou a bezproblémovou kompletaci. Softwarová ˇcást je postavená tak, aby s sebou nesla co nejmenˇs´ı závislost na zvoleném hardwarovém ˇreˇsen´ı. D´ıky této nezávislosti je do budoucna moˇzné kdykoliv vymˇenit hardwarovou platformu témˇeˇr bez zásah˚u do softwaru.

5.1 HW n´avrh ˇreˇsen´ı

Hardware ˇr´ıdic´ıho serveru je rozdˇelen do dvou desek. Prvn´ı z nich je vybavena konektory pro pˇripojen´ı ˇr´ıdic´ıho poˇc´ıtaˇce, pˇripojen´ı extern´ıho zdroje napˇet´ı a dvˇema konektory pro budouc´ı rozˇs´ıˇren´ı. Druhá z nich je vybavena vstupnˇe / výstupn´ımi svorkami, za pomoci kterých je moˇzné ˇr´ıdit standardn´ı prvky elektroinstalace.

Rozdˇelen´ı do dvou desek je výhodné nejen z hlediska m´ısta, které deska zab´ırá, ale zároveˇn slouˇz´ı i k logickému rozdˇelen´ı funkc´ı. V c´ılové instalaci tak m˚uˇze být pouˇzita napˇr´ıklad pouze hlavn´ı deska, která nese ˇr´ıdic´ı poˇc´ıtaˇc a rozˇsiˇruj´ıc´ı konektory. V pˇr´ıpadˇe vyuˇzit´ı pouze jedné poloviny systému tak dojde ke sn´ıˇzen´ı potˇreby m´ısta pro instalaci pˇri zachován´ı vˇsech funkc´ı, vyjma pˇr´ımého ovládán´ı vstupnˇe / výstupn´ıch port˚u. V pˇr´ıpadˇe potˇreby je moˇzné systém rozˇs´ıˇrit o druhou desku, která nese právˇe tyto vstupnˇe / výstupn´ı svorky.

5.1.1 R´ˇıdic´ı poˇc´ıtaˇc

Základn´ım stavebn´ım prvkem kaˇzdého systému je procesorová jednotka. Jiˇz pˇri návrhu je

(26)

by se ale nemˇelo jednat o centráln´ı jednotku, která by svou cenou degradovala celý systém z finanˇcn´ıho hlediska.

Centráln´ı jednotka m˚uˇze být bud’ vybudována na základnˇe libovolného mikrokontroléru, kterých jsou v nab´ıdce stovky od r˚uzných výrobc˚u, nebo je moˇzné vyuˇz´ıt nˇekterý z vývojových kit˚u, v nichˇz je mikrokontroler vˇcetnˇe vybraných periferi´ı pˇripojen na základn´ı desku. U do- stateˇcnˇe výkonných mikrokontrolér˚u je ˇcasto pˇripojen s´ıt’ový konektor, pˇr´ıpadnˇe USB sbˇernice.

Takováto deska pak obsahuje také vstupnˇe - výstupn´ı piny, pomoc´ı kterých lze tuto desku zapojit do vyv´ıjeného systému. D´ıky takové pˇr´ıpravˇe jiˇz od výrobce je moˇzné urychlit ˇcas nutný k vývoji základn´ıho HW vyv´ıjené aplikace.

5.1.2 V´yvojov´e desky

Vývojové desky jsou nab´ızeny v celém výkonovém spektru. Zat´ımco nejménˇe výkonné základn´ı desky nemaj´ı podporu pro pˇr´ıstup k s´ıt’ovému rozhran´ı, ty výkonnˇejˇs´ı jiˇz nab´ızej´ı nejenom pˇr´ıstup k s´ıt’ovému rozhran´ı, ale nav´ıc i podporu pro bˇeh operaˇcn´ıho systému.

Pokud by doˇslo k výbˇeru základn´ı desky, která nezahrnuje podporu pro bˇeh operaˇcn´ıho systému, bylo by nutné vyvinout, pˇr´ıpadnˇe z´ıskat základn´ı knihovn´ı funkce. Pod pojmem základn´ıch funkc´ı se rozum´ı pˇredevˇs´ım pˇr´ıstup k s´ıt’ovým funkc´ım, pˇr´ıpadnˇe ukládán´ı konfiguraˇcn´ıch dat do perzistentn´ı pamˇeti. Veˇskeré knihovn´ı funkce by pak byly vyvinuty na m´ıru danému mikro- kontroléru a tud´ıˇz bez úprav nepouˇzitelné na jiné platformˇe.

V pˇr´ıpadˇe výbˇeru základn´ı desky s podporou bˇehu operaˇcn´ıho systému nen´ı nutné vyv´ıjet knihovn´ı funkce zajiˇst’uj´ıc´ı základn´ı komunikaci. Vyv´ıjený software bude nav´ıc psán za pomoci obecných knihovn´ıch funkc´ı, které daný operaˇcn´ı systém zahrnuje. Výsledný software bude tedy moˇzné vyuˇz´ıt na libovolné vývojové desce s podporou stejného operaˇcn´ıho systému. Podpora pro bˇeh operaˇcn´ıho systému je natolik zásadn´ı, ˇze výbˇer prob´ıhal pouze mezi základn´ımi deskami s jeho podporou.

Obr´azek 7: ˇR´ıdic´ı deska Cubieboard2

(27)

Výbˇer hlavn´ı ˇr´ıdic´ı desky je jedn´ım z kl´ıˇcových rozhodnut´ı, jeˇz je nutné provést. Hlavn´ım poˇzadavkem byl poˇcet vstupnˇe/výstupn´ıch pin˚u a dalˇs´ıch komunikaˇcn´ıch rozhran´ı na desce do- stupných. Vybrána byla deska vyvinutá firmouCubietech s názvem Cubieboard2. Deska disponuje 96 vyvedenými piny, z nichˇz lze pˇreváˇznou vˇetˇsinu vyuˇz´ıt jako binárn´ı vstupy a výstupy, pˇr´ıpadnˇe jim pˇriˇradit speciáln´ı funkce. Speciáln´ı funkc´ı se kupˇr´ıkladu rozum´ı nastaven´ı dvou pin˚u tak, aby se tváˇrily jako I2C rozhran´ı. Celkovˇe deska disponuje 4 x rozhran´ımUART a 1 x rozhran´ıI2C. Z dalˇs´ıch rozhran´ı, které jsou na desce pˇripojeny lze jmenovat napˇr´ıklad ethernet, USB, pˇr´ıpadnˇe grefické HDMI.

V realizovaném pˇr´ıpadˇe je zapojeno 10 pin˚u jako vstupy a 10 pin˚u jako výstupy. Rozhran´ı I2C je pˇripojeno prostˇrednictv´ım pˇrevodn´ıku na OneWire sbˇernici (popsáno v kapitole 5.1.4). Dvˇe sériová rozhran´ı jsou vyvedena na extern´ı svorkovnici pro budouc´ı vyuˇzit´ı (popsáno v kapitole 5.1.5), jedno sériové rozhran´ı je vyhrazeno pro komunikaci s bluetooth modulem (popsáno v kapitole 5.1.6). Rozhran´ı ethernet slouˇz´ı pro pˇripojen´ı k s´ıti, ostatn´ı rozhran´ı z˚ustaly v systému nevyuˇzity.

Na desce je osazen dvoujádrový procesor zaloˇzený na architektuˇre ARM s maximáln´ı frek- venc´ı 1.2GHz [14]. Jedná se o architekturu porocesor˚u speciálnˇe vyvinutou pro vyuˇzit´ı v zaˇr´ızen´ıch s n´ızkou spotˇrebou energie. Procesor je doplnˇen o 1024MB sd´ılené pamˇeti RAM. Deska je nav´ıc osazena 4GB pamˇet’i NAND, j´ıˇz je moˇzné vyuˇz´ıt pro uloˇzen´ı operaˇcn´ıho systému.

5.1.3 Stabiliz´ator napˇet´ı

Pro bˇeh základn´ı desky je nutné pˇrivést napˇet´ı 5V, odeb´ıraný proud se pohybuje mezi 500 aˇz 2000 mA [14]. Pˇri zapojen´ı do infrastruktury automatizace se ale pˇredpokládá napájen´ı nˇekterým ze standardn´ıch napájec´ıch napˇet´ı a to 12 nebo 24V.

Kv˚uli poˇzadavku na sn´ıˇzen´ı napˇet´ı z 24V na 5V byl jako stabiliz´ator vybr´an LM 2575 [13].

Jedná se o standardn´ıstep-down sp´ınaný regulátor. Jeho zapojen´ı na prototypové desce je zcela dle doporuˇcen´ı výrobce [13].

5.1.4 OneWire sbˇernice

Aby mohl vyv´ıjený systém zjiˇst’ovat aktuáln´ı teplotu, je nutné jeho vybaven´ı o pˇr´ısluˇsné rozhran´ı. Pro mˇeˇren´ı teploty byly vybrány teplotn´ı ˇcidla DS18B20 od firmy Maxim [17]. Jedná se o velmi rozˇs´ıˇrený modul, který poskytuje dostateˇcnou pˇresnost pˇri velmi pˇr´ıznivé cenˇe.

Tato teplotn´ı ˇcidla komunikuj´ı prostˇrednictv´ım OneWire sbˇernice. Jedná se o sbˇernici, které postaˇcuj´ı dva vodiˇce. Jeden vodiˇc je urˇcený pro nulový potenciál (GND), druhým vodiˇcem jsou jednotlivá zaˇr´ızen´ı napájena a zároveˇn j´ım komunikuj´ı. Takovéto zapojen´ı je doporuˇcené podle

(28)

dokumentace výrobce pouze pro ménˇe rozsáhlé instalace. Pˇri zapojen´ı vyˇsˇs´ıho poˇctu teplotn´ıch ˇcidel je doporuˇceno pˇristoupit ke tˇr´ı drátovému zapojen´ı. V pˇr´ıpadˇe tˇr´ıdrátového zapojen´ı je tˇret´ı drát vyuˇzit jako trvalý zdroj napˇet´ı [17].

Protoˇze hlavn´ıˇr´ıdic´ı poˇc´ıtaˇc nedisponuje rozhran´ım pro OneWire sbˇernici, bylo jeho zapojen´ı doplnˇeno o pˇrevodn´ık DS2482. Tento ˇcip prov´ad´ı pˇrevod I2C rozhran´ı na OneWire sbˇernici.

Pˇrevodn´ık má implementovanou podporu pˇr´ımo v jádru Linuxu, jeho pouˇzit´ı tedy bylo velmi jednoduché.

5.1.5 S´eriov´e rozhran´ı

Aby si systém zachoval jistou moˇznost dalˇs´ıho rozˇs´ıˇren´ı, byla na hlavn´ı desce vyvedena dalˇs´ı dvˇe sériová rozhran´ı, která rozˇs´ıˇren´ı o nové komunikaˇcn´ı kanály umoˇzˇnuj´ı.

V pˇr´ıpadˇe potˇreby pˇripojen´ı ke sbˇernici KNX by se nab´ızelo vyuˇz´ıt napˇr´ıklad modulu TP- UART2 Board BTM2-PCB. Tento modul pˇredstavuje pˇrevodn´ık mezi KNX sbˇernic´ı (KNX.TP) a sériovou linkou. Samotné pˇripojen´ı modulu k systému by samozˇrejmˇe nebylo dostateˇcné, pˇripojen´ı by vyˇzadovalo úpravu softwaru. Na internetu je dostupná ˇrada open source knihoven, d´ıky kterým je moˇzné pˇristupovat pomoc´ı tohoto modulu na KNX sbˇernici. Bylo by tedy bezpodm´ıneˇcnˇe nutné portovat nˇekterou z tˇechto knihoven a naimplementovat jej´ı obsluhu do systému.

5.1.6 Bluetooth rozhran´ı

Jak jiˇz bylo popsáno v pˇredchoz´ıch kapitolách, Bluetooth komunikace je v systému pouˇzita pro úˇcely lokalizace uˇzivatele. Na trhu je dostupná ˇrada ˇr´ıdic´ıch desek, které jiˇz maj´ı kombino- vaný WiFi / Bluetooth modul s podporou BLE pˇr´ıtomný na desce. Pouˇzit´ı modulu s osazeným modulem by se mohlo zdát výhodnˇejˇs´ı, odpadá potˇreba dalˇs´ı souˇcásti, u které by mohlo doj´ıt k poˇskozen´ı, pˇr´ıpadnˇe k nekompatibilitˇe. Nicménˇe toto ˇreˇsen´ı nebylo vybráno a to z d˚uvodu, ˇze pokud je Bluetooth modul extern´ı, je moˇzné optimalizovat jeho um´ıstˇen´ı. Je moˇzné nainstalovat ˇr´ıdic´ı desku do rozvadˇeˇce a následnˇe vyvést Bluetooth modul na optimáln´ı m´ısto. Nicménˇe je nutné respektovat fyzická omezen´ı sériového rozhran´ı.

Extern´ı Bluetooth moduly se standardnˇe pˇripojuj´ı pˇres rozhran´ıUART. Bluetooth modul se pak m˚uˇze nacházet ve dvou stavech. V prvn´ım stavu pˇrij´ımá takzvané AT pˇr´ıkazy, pomoc´ı kterých je moˇzné modul nastavit. Do druhého stavu se modul dostane ve chv´ıli, kdy dojde ke spojen´ı s jiným zaˇr´ızen´ım, poté se veˇskerá data poslaná pˇres UART rozhran´ı pˇrenesou na vzdálenou stranu spojen´ı. Stejnˇe tak se veˇskerá data odeslaná vzdálenou stranou pˇrenesou na sériové rozhran´ıUART.

(29)

5.1.6.1 Bluetooth modul

Jedn´ım z prvn´ıch ˇsiroce nab´ızených Bluetooth modul˚u s podporou standardu Low Energy byl modul zaloˇzený na ˇcipu CC2540 od firmy Texas Instruments [19]. Modul se nab´ız´ı pod oznaˇcen´ım HM-10 a je vyrábˇen ˇc´ınskou firmou Huamao technology.

Obr´azek 8: Bluetooth modul HM-10

Bluetooth modul je nutné správnˇe nastavit tak, aby se choval jako server. V tomto módu nejen ˇze bude moˇzné se k nˇemu pˇripojit z mobiln´ıho terminálu, ale modul bude vys´ılat rámce, pomoc´ı kterých bude moˇzné jeho nalezen´ı. Tyto rámce jsou v normˇe oznaˇcované jako iBeacon rámce. Jedná se o speciálnˇe formátované zprávy, které jsou periodicky vys´ılány. Jejich obsahem je pˇredevˇs´ım jednoznaˇcný identifikátor oznaˇcuj´ıc´ı typ modulu a popis dostupných sluˇzeb.

5.1.7 Vstupnˇe - v´ystupn´ı rozˇsiˇruj´ıc´ı modul

Jedná se o modul, který nen´ı pevnˇe spojen s hlavn´ı ˇcást´ı prototypu. Tento modul nab´ız´ı rozˇs´ıˇren´ı o 10 vstupn´ıch a 10 výstupn´ıch port˚u.

Jako vstupn´ı optick´e oddˇelovaˇce jsou pouˇzity integrovan´e obvody od firmy Cosmo, PC817B.

Optoˇcleny maj´ı izolaˇcn´ı pevnost do 5kV.

Na vstupu optoizol´ator˚u je LED dioda, jej´ıˇz maxim´aln´ı proud je 50mA, ˇspiˇckovˇe aˇz 1A.

Za normáln´ıho provozu by ale nemˇel pˇresahovat 20mA. Pro splnˇen´ı tˇechto podm´ınek je nutné správnˇe spoˇc´ıtat odpor zapojený s diodou do série. Výpoˇcet vycház´ı z hodnoty maximáln´ıho proudu z datasheetu a z maximáln´ıho vstupn´ıho napˇet´ı 24V. Výpoˇcet je uveden v rovnici 1.

R= Umax−ULED

Imax

= 24.0−1.5

20.10⁻³ = 1.125kΩ (1)

Pˇri výbˇeru výstupn´ıch optoˇclen˚u je moˇzné vyb´ırat ze dvou typ˚u, s triakovým výstupem nebo tranzistorovým výstupem. Pouˇzit´ı výstupn´ıch optoˇclen˚u s triaky je omezeno pouze na sp´ınán´ı stˇr´ıdavých napˇet´ı, zat´ımco pˇri správném zapojen´ı optoˇclenu s tranzistorovým výstupem

(30)

je moˇzné sp´ınat jak stˇr´ıdavé tak i stejnosmˇerné obvody. Do zapojen´ı byly vybrány oba dva druhy výstupn´ıch prvk˚u.

Obrázek 9: Vnitˇrn´ı uspoˇrádán´ı KAQV214 [15]

Obrázek 10: Vnitˇrn´ı uspoˇrádán´ı MOC3022 [16]

Na obrázku 9 je vnitˇrn´ı zapojen´ı optoˇclenu s tranzistorovým výstupem. Aby bylo moˇzné pomoc´ı tranzistorového výstupu ovládat stejnosmˇerné i stˇr´ıdavé obvody mus´ı se výstupn´ı obvod zapojit mezi piny 4 a 6. Z obrázk˚u vnitˇrn´ıch zapojen´ı 9 a 10 je zˇrejmé, ˇze jsou mezi sebou zamˇenitelné. Vstupn´ı signály na fotodiodu jsou rovnˇeˇz stejné - 1.2V pˇri proudu 10mA.

5.2 SW n´avrh ˇreˇsen´ı

Pro implementaci projektu byl vybrán framework Qt. Hlavn´ım d˚uvodem k výbˇeru právˇe tohoto frameworku je jeho ˇsiroké pole p˚usobnosti. Je moˇzné v nˇem vytváˇret jak konzolové aplikace bez uˇzivatelského rozhran´ı, tak i aplikace s grafickým rozhran´ım. Nejvˇetˇs´ı výhodou Qt je podpora v´ıce platforem neˇz pouze x86 PC. Tato podpora dovoluje spouˇstˇet stejnou aplikaci na bˇeˇzném poˇc´ıtaˇci i na mobiln´ıch zaˇr´ızen´ıch s operaˇcn´ımi systémy Android / iOS. Kompletn´ı seznam pod- porovaných platforem je k nalezen´ı na http://doc.qt.io/qt-5/supported-platforms.html.

Celý projekt je rozdˇelen do ˇsesti vzájemnˇe závislých ˇcást´ı. Jednou z nich je aplikace bˇeˇz´ıc´ı na serveru -Serverová aplikace a dvˇe aplikace s grafickým rozhran´ım - Konfiguraˇcn´ı aplikace, Uˇzivatelská aplikace. Zbývaj´ıc´ı tˇri ˇcásti projektu jsou zamýˇsleny jako sd´ılené knihovny poskytuj´ıc´ı funkce a objekty, které se staraj´ı o výmˇenu a ukládán´ı dat. Sd´ılené knihovny jsou Com- municationHandler,DatabaseHandler a ObjectHandler.

5.2.1 Embedded linux

Hlavn´ı ˇr´ıdic´ı deska podporuje bˇeh operaˇcn´ıho systému Linux. Instalace linuxového prostˇred´ı na bˇeˇzném poˇc´ıtaˇci je velmi snadná. V pˇr´ıpadˇe vestavˇených systém˚u je nutné dodrˇzet nˇekolik

(31)

základn´ıch krok˚u, jak postupovat pˇri sestavován´ı celého systému.

Vstupn´ım prvkem kaˇzdého embedded linuxu je bootloader, ˇcesky zavadˇeˇc. Úkolem zavadˇeˇce je základn´ı nastaven´ı periferi´ı a pˇr´ıstupu k pamˇeti. Nav´ıc se zavadˇeˇc stará o nahrán´ı linuxové jádra z pˇripojené MicroSD karty pˇri startu systému. Pˇri výbˇeru bootloaderu je nutné dbát na to, zda obsahuje podporu pro daný typ procesoru. Nejrozˇs´ıˇrenˇejˇs´ım a nejv´ıce podporovaným zavadˇeˇcem jeDas U-Boot. Jedná se o univerzáln´ı open source zavadˇeˇc, který zahrnuje podporu nejen procesor˚u architektury ARM, ale také PowerPC, MIPS a dalˇs´ıch.

Linuxové jádro je nutné um´ıstit na speciáln´ı (pˇredem zadanou) adresu na MicroSD kartˇe.

Je proto nutné jádro takzvanˇe vypálit, nestaˇc´ı pouze zkop´ırovat na souborový systém. Zdrojové kódy linuxového jádra jsou volnˇe dostupné. Pro úspˇeˇsné fungován´ı jádra je nutné pouˇzit´ı jádra s rozˇs´ıˇren´ım o podporu procesor˚u Allwinner. Takové jádro je volnˇe ke staˇzen´ı v repozitáˇr´ıch udrˇzovaných sdruˇzen´ım sunxi [20]. Jádro udrˇzované sdruˇzen´ım sunxi je vˇzdy zaloˇzeno na nˇekteré z oficiáln´ıch verz´ı linuxového jádra. Do jádra jsou následnˇe aplikovány zmˇeny, které umoˇzn´ı podporu vˇsech periferi´ı daného procesoru.

Shodnost jádra distribuovaného komunitou sunxi s oficiáln´ım jádrem je d˚uleˇzitá zejména ve chv´ıli, kdy vznikne poˇzadavek na aplikaci dalˇs´ıch zmˇen. V tomto pˇr´ıpadˇe byly aplikovány zmˇeny na podporureal-time bˇehu.

Posledn´ı souˇcást´ı kaˇzdého linuxového systému je základn´ı adresáˇrová struktura spolu se základn´ımi programy, takzvanýfilesystem. Celý základn´ı systém je moˇzné sestavit podobnˇe jako linuxové jádro ze zdrojových kód˚u. Sestaven´ı celé struktury by ale zabralo velké mnoˇzstv´ı ˇcasu, a proto bylo vyuˇzito pˇredem pˇripraveného základn´ıho filesystému, dostupného online.

Sestaven´ı jádra linuxu, vˇcetnˇe korektn´ı instalace na MicroSD kartu bylo zautomatizováno pomoc´ı skript˚u napsaných v jazyce BASH.

5.2.2 Qt Framework

Qt Framework je zaloˇzen na programovac´ım jazyce C++ a je vyv´ıjen pod open source licen- cemi. Jeho hlavn´ım smyslem je poskytnut´ı kompaktn´ıho ekosystému knihoven a dalˇs´ıch nástroj˚u pro vývoj cross-platform aplikac´ı.

Nejvˇetˇs´ım rozˇs´ıˇren´ım jazyka C++ v Qt Frameworku je zaveden´ı takzvanýchsignál˚u aslot˚u [22]. Vyuˇzit´ı vazby typu signal - slot má výhody pˇredevˇs´ım v grafických aplikac´ıch. Tyto aplikace jsou charakteristické t´ım, ˇze velkou ˇcást svého bˇehu nevykonávaj´ı ˇzádnou akci, avˇsak jakmile uˇzivatel stiskne tlaˇc´ıtko, je nutné okamˇzité vykonán´ı obsluhy.

Vˇetˇsina ostatn´ıch framework˚u tuto situaci ˇreˇs´ı tak, ˇze pˇri kliknut´ı je zavol´an tzv. callback.

Jedná se o ukazatel na funkci, která má za úkol obslouˇzit danou akci. Nevýhodou tohoto pˇr´ıstupu

(32)

je nemoˇznost typové kontroly, zda volaná funkce vyˇzaduje urˇcité parametry, a zda jsou tyto parametry zadány. Pokud nen´ı tato kontrola provedena, m˚uˇze doj´ıt k neoˇcekávaným pád˚um aplikace z d˚uvodu pˇr´ıstupu k neinicializované pamˇeti a podobnˇe [22].

Navázán´ı signálu na slot je schematicky znázornˇeno na obrázku 11. Jak je ze schématu zˇretelné, prvn´ı objekt definuje signál, jenˇz bude vyslán. Druhý objekt který na danou akci m˚uˇze reagovat definuje naopak slot. Vytvoˇren´ı vazby - connect je moˇzné zavolat z libovolného jiného objektu, který obsahuje reference na oba objekty. V pr˚ubˇehu kompilace projektu je kontrolováno, zda zdrojová funkce objektu 1 (signál) obsahuje stejný poˇcet parametr˚u stejného typu jako c´ılová funkce objektu 2 (slot).

Obrázek 11: Grafické znázornˇen´ı signál - slot [22]

Existuj´ı ale i jistá omezen´ı, která je nutné znát a respektovat. V následuj´ıc´ıch odstavc´ıch budou tato omezen´ı popsána oddˇelenˇe pro signály i sloty. Veˇskerá uvedená upozornˇen´ı jsou ˇcerpána z [22].

5.2.2.1 Sign´aly

Signály mohou být vyslány z jakéhokoliv m´ısta v kódu, avˇsak je doporuˇceno vys´ılat signály pouze z objektu, který daný signál definuje. Obsah bloku slotu je vykonán okamˇzitˇe po vyslán´ı signálu ve stejném vláknˇe, z nˇehoˇz byl signál vyslán. Jedná se tedy o rovnocennou akci, jako zavolán´ı bˇeˇzné funkce.

Existuje zde vˇsak jedna výjimka, pokud se pˇri vytváˇren´ı spojen´ı (connection) zadá jako posledn´ı parametr typ spojen´ıQt::QueuedConnection, vykoná se blok slotu aˇz po skonˇcen´ı obsluhy vyslán´ı signálu.

(33)

Signály jsou ve zdrojovém kódu pouze definovány, nejsou implementovány. O jejich implementaci se stará v pr˚ubˇehu kompilace takzvanýMeta Object Compiler [23].

5.2.2.2 Sloty

Slot je vˇzdy zavolán, pokud doˇslo k vyslán´ı signálu, na který je daný slot navázán. Na rozd´ıl od signálu je funkce implementuj´ıc´ı slot naprosto shodná s bˇeˇznou funkc´ı, a lze k n´ı tak i pˇristupovat.

Zavolán´ı slotu, který je navázán s nˇekterým signálem, nen´ı samozˇrejmˇe zdarma, je zde jisté zdrˇzen´ı zp˚usobené vyhledán´ım správné vazby a jej´ım následným zpracován´ım. Autoˇri Qt uvádˇej´ı zhruba desetinásobné zpomalen´ı v porovnán´ı s pˇr´ımým zavolán´ım funkce.

5.2.3 Object Handler

Jedná se o knihovnu, jeˇz popisuje vˇsechny objekty, jeˇz jsou vymˇeˇnovány mezi klientskou a serverovou ˇcást´ı. V této knihovnˇe jsou zavedeny dvˇe abstraktn´ı tˇr´ıdy, které pˇredepisuj´ı metody, jeˇz mus´ı kaˇzdý objekt implementovat. Tyto abstraktn´ı tˇr´ıdy jsouObjectHandleraDataObject.

Prvn´ı tˇr´ıda ObjectHandler zavád´ı metody, jeˇz jsou urˇceny pro serializaci a deserializaci objekt˚u, které maj´ı být odeslány nebou pˇrijaty. Druhá tˇr´ıda DataObject pˇredepisuje metody, které jsou vyuˇzity pro ukládán´ı objekt˚u do perzistentn´ıho úloˇziˇstˇe (databáze).

V pˇr´ıloze na obrázku 23 je zobrazen UML diagram vztahu (dˇediˇcnosti) mezi rozhran´ım IObjectHandler a dvˇema objekty, které jej implementuj´ı. Na obrázku 24, rovnˇeˇz v pˇr´ıloze, je zobrazen celkový UML diagram pro tˇr´ıduUser.

5.2.3.1 Pˇrenos objekt˚u

Spojen´ı je vˇzdy zaloˇzeno na principu spolehlivého kanálu realizovaného prostˇrednictv´ım TCP/IP. Data, která jsou t´ımto spojen´ım pˇrenáˇsena, nen´ı bezpodm´ıneˇcnˇe nutné chránit proti poˇskozen´ı pˇri pˇrenosu. Tato ochrana je jiˇz implementována niˇzˇs´ı vrstvou TCP/IP v podobˇe výpoˇctu CRC.

Pˇrenáˇsená data jsou ve formátu XML. Jedná se o univerzáln´ı rozˇsiˇritelný znaˇckovac´ı jazyk, jenˇz klade velký d˚uraz na správné formátován´ı a uzav´ırán´ı tag˚u. Pˇrenos ve formátu XML byl vybrán pˇredevˇs´ım s ohledem na moˇznost dalˇs´ıho vyuˇzit´ı dat i mimo vyv´ıjené aplikace. V pˇr´ıpadˇe potˇreby je moˇzné jakákoliv data kdykoliv exportovat a pomoc´ı extern´ıch nástroj˚u dále vyuˇz´ıvat.

Pro pˇrenos vˇsech objekt˚u je zvolena jednotn´a kostra zpr´avy 12.

Kaˇzdá zpráva tak obsahuje hlaviˇcku oznaˇcuj´ıc´ı, ˇze se jedná o xml zprávu. Koˇrenovým atributem kaˇzdé zprávy je typ operace, která má být pro daný objekt vykonána. Moˇzné varianty

(34)

(1)<?xml version="1.0"?>

(2)<operation type="">

(3) <object name=""/>

(2)</operation>

Obrázek 12: Minimáln´ı kostra pˇrenáˇsených dat jsou detailnˇe popsány v tabulce 2.

Posledn´ım vnoˇreným atributem je jméno objektu, pro který bude daná akce vykonána. V pˇr´ıpadˇe, ˇze se jedná o volán´ı operace typu GET, je moˇzné, aby byl obsah objektu prázdný.

V takovém pˇr´ıpadˇe jsou navráceny vˇsechny vyhovuj´ıc´ı hodnoty. Pokud se jedná o volán´ı jiné operace, je nutné, aby bylo vyplnˇeno rovnˇeˇz i tˇelo objektu.

ADD vytvoˇren´ı nového objektu daného typu GET vyˇcten´ı dat z aktuáln´ıho objektu SET nastaven´ı dat do aktuáln´ıho objektu DEL vymazán´ı aktuáln´ıho objektu

INVOKE vykonán´ı pˇr´ıkazu na aktuáln´ım objektu RESP pˇr´ıjem odpovˇedi na pˇredchoz´ı dotaz / pˇr´ıkaz Tabulka 2: Výpis moˇzných akc´ı vykonaných na objektech

Zpracován´ı komunikace je na stranˇe klienta omezeno pouze na odpovˇedi od serveru. Zpra- covávány jsou pouze zprávy typu RESP. Pˇri zpracován´ı pˇrijatých dat je nejdˇr´ıve provedena kontrola, zda se jedná o validn´ı (správnˇe formátovaný) xml dokument. V kladném pˇr´ıpadˇe je naˇcteno jméno objektu, kterého se zpráva týká, a operace, která má být provedena. Posledn´ım krokem je proveden´ı poˇzadavku a aktualizace dat.

Zpracován´ı komunikace je na stranˇe serveru doplnˇeno o krok ovˇeˇren´ı, který je vloˇzen pˇred vlastn´ı zpracován´ı operace. C´ılem je zabránit neoprávnˇené zmˇenˇe objektu. Vlastn´ı proces ovˇeˇren´ı oprávnˇen´ı je popsán v pˇr´ısluˇsné ˇcásti práce vˇenované softwaru na stranˇe serveru.

5.2.4 Communication Handler

Jedná se o knihovnu, kterou vyuˇz´ıvá uˇzivatelská a konfiguraˇcn´ı aplikace. Hlavn´ım úˇcelem této knihovny je vyhledáván´ı dostupných server˚u a navazován´ı komunikace s nimi. Po navázán´ı komunikace automaticky dojde k autentizaci uˇzivatele. Vyˇsˇs´ı vrstvy vyuˇz´ıvaj´ıc´ı tuto knihovnu obdrˇz´ı spojen´ı, které je jiˇz pˇripraveno k odes´ılán´ı a pˇr´ıjmu dat.

(35)

5.2.4.1 Bluetooth klient

Komunikace pomoc´ı Bluetooth s podporou standardu Low Energy je v Qt Frameworku podporována od verze 5.4. V této verzi prob´ıhal vývoj velmi bouˇrlivˇe, a tak je doporuˇceno pouˇzit´ı verze 5.5 a vyˇsˇs´ı. V této verzi je jiˇz API pro pˇr´ıstup stabilizováno. I pˇresto, ˇze vˇetˇsina práce s ohledem na podporu této technologie je oznaˇcena za hotovou, byla v pr˚ubˇehu práce nalezena ˇrada problem˚u.

Vzhledem k tomu, ˇze Qt technologie je zaloˇzena na principu pos´ılán´ı signál˚u do pˇripravených slot˚u, je i BLE subsystém napsán t´ımto zp˚usobem. Vyhledáván´ı okoln´ıch Bluetooth zaˇr´ızen´ı prob´ıhá tak, ˇze objektQBluetoothDeviceDiscoveryAgent zaregistruje signálydeviceDiscovered a finished. Pˇr´ısluˇsné signály jsou pak obslouˇzeny tak, ˇze deviceDiscovered je vykonán vˇzdy, kdyˇz dojde k nalezen´ı nového zaˇr´ızen´ı, signál finished je vykonán ve chv´ıli, kdy jiˇz doˇslo k nalezen´ı vˇsech okoln´ıch Bluetooth zaˇr´ızen´ı.

V pr˚ubˇehu testován´ı vyhledáván´ı dostupných zaˇr´ızen´ı se na platformˇe Android vyskytl problém v tom, ˇze signál o ukonˇcen´ı vyhledáván´ı byl vyslán aˇz v rozmez´ı 60 - 90 s od poˇcátku vyhledáván´ı. Jednotlivá zaˇr´ızen´ı sice byla ve vˇetˇsinˇe pˇr´ıpad˚u nalezena jiˇz v pr˚ubˇehu prvn´ıch 10 - 15 s, nicménˇe i zde byl pozorován velký ˇcasový rozptyl, coˇz by nebylo pro tento systém (lokalizaci uˇzivatele) vhodné. Uˇzivatel by musel ˇcekat relativnˇe dlouhou dobu, neˇz by bylo moˇzné spoleh- livˇe urˇcit, ke kterému z dostupných zaˇr´ızen´ı se pˇripojit. V pr˚ubˇehu ˇreˇsen´ı tohoto problému byl nalezen záznam o stejném chován´ı na platformˇe Android i v bugzille Qt projektu, popis problému je moˇzné nalézt na adrese https://bugreports.qt.io/browse/QTBUG-46253.

Oprava je pl´anov´ana ve verzi Qt Framework 5.8.

Vzhledem k nemoˇznosti pouˇzit´ı intern´ıch mechanizm˚u Qt Frameworku bylo nutné nastalou situaci vyˇreˇsit. Prvn´ım krokem bylo ovˇeˇren´ı, zda je platforma Android schopná vyhledávat BLE zaˇr´ızen´ı lépe, neˇz jak je tato funkce implementována uvnitˇr Qt. Byla tedy vyvinuta jednoduchá aplikace, jej´ımˇz jedinným úkolem bylo vyhledávat dostupná BLE zaˇr´ızen´ı.

Podobnˇe jako v pˇr´ıpadˇe implementace BLE podpory uvnitˇr Qt Frameworku, byl i v pˇr´ıpadˇe platformy Android vývoj velmi bouˇrlivý. Podpora pro BLE byla zavedena ve verzi 18 [24], nicménˇe pro verze Android menˇs´ı neˇz 21 je nutné pouˇz´ıvat jiné API, neˇz které je doporuˇcené pouˇz´ıvat pro verze Android vyˇsˇs´ı neˇz 21 vˇcetnˇe [25]. Vyv´ıjená aplikace pro vyhledáván´ı tyto zmˇeny v API reflektuje, a proto je moˇzné jej´ı pouˇzit´ı jak na starˇs´ıch systémech Android 4.3, tak i na novˇejˇs´ıch systémech verze 5.0.

Aplikace vyvinutá pˇr´ımo pro platformu Android se ukázala jako funkˇcn´ı, vyhledán´ı vˇsech dostupných zaˇr´ızen´ı je dokonˇceno ve zlomc´ıch vteˇrin. Posledn´ım krokem tedy bylo zavolán´ı