Komunikaˇcn´ı protokoly pro chytr´e s´ıtˇe

(1)

Komunikaˇ cn´ı protokoly pro chytr´ e s´ıtˇ e

Bakal´ aˇ rsk´ a pr´ ace

Studijn´ı program: B2612 – Elektrotechnika a informatika

Studijn´ı obor: 2612R011 – Elektronické informaˇcn´ı a ˇr´ıdic´ı systémy Autor práce: Jakub Pecháˇcek

Vedouc´ı pr´ace: Ing. Jan Kraus, Ph.D.

(2)

Communication protocols for smart grids

Bachelor thesis

Study programme: B2612 – Electrical Engineering and Informatics

Study branch: 2612R011 – Electronic Information and Control Systems Author: Jakub Pech´aˇcek

Supervisor: Ing. Jan Kraus, Ph.D.

(3)

TECHNICKÁ UNIVERZITA V LIBERCI

Fakulta mechatroniky, informatiky a mezioborových studií Akademický rok: 2018/2019

ZADÁNÍ BAKALÁŘSKÉ PRÁCE

Jméno a příjmení: Jakub Pecháček

Název práce: Komunikační protokoly pro chytré sítě Zadávající katedra: Ústav mechatroniky a technické informatiky Vedoucí práce: Ing. Jan Kraus Ph.D.

Rozsah práce: 30—40 stran

Z á s a d y p r o v y p r a c o v á n í :

1. Seznamte se s protokoly pro přenos dat v energetice zejména v prostředí tzv. chytrých budov respektive chytrých sítí.

2. Ve vlastní aplikaci na konkrétních jednoduchých příkladech a s využitím existujících knihoven demonstrujte obvyklé funkce jednotlivých protokolů.

3. Prozkoumejte, implementujte, popište a otestujte odlišnosti jednotlivých řešení a v závěru práce shrňte přehlednou formou zjištěná fakta.

[1] FAN, Zhong, et al. Smart grid communications: Overview of research challenges, solutions, and standardization activities. IEEE Communications Surveys & Tutorials, 2013, 15.1: 21-38.

S e z n a m o d b o r n é l i t e r a t u r y :

[2] APPASANI, Bhargav; MADDIKARA, Jaya Bharata Reddy; MOHANTA, Dusmanta Kumar. Standards and Communication Systems in Smart Grid. In: Smart Grids and Their Communication Systems. Springer, Singapore, 2019. p. 283-327.

[3] SEMBROIZ, David; RICCIARDI, Sergio; CAREGLIO, Davide. A Novel Cloud-Based IoT Architecture for Smart Building Automation. In: Security and Resilience in Intelligent Data-Centric Systems and Communication Networks. 2018. p. 215-233.

[4] MINOLI, Daniel; SOHRABY, Kazem; OCCHIOGROSSO, Benedict. IoT considerations, requirements, and architectures for smart buildings—Energy optimization and next-generation building management systems.

IEEE Internet of Things Journal, 2017, 4.1: 269-283.

V Liberci dne ... ...

Ing. Jan Kraus Ph.D.

(4)

Prohl´ aˇ sen´ı

Byl jsem seznámen s t´ım, ˇze na mou bakaláˇrskou práci se plnˇe vztahuje zákon ˇc. 121/2000 Sb., o právu autorském, zejména § 60 – ˇskoln´ı d´ılo.

Beru na vˇedom´ı, ˇze Technická univerzita v Liberci (TUL) neza- sahuje do mých autorských práv uˇzit´ım mé bakaláˇrské práce pro vnitˇrn´ı potˇrebu TUL.

Uˇziji-li bakaláˇrskou práci nebo poskytnu-li licenci k jej´ımu vyuˇzit´ı, jsem si vˇedom povinnosti informovat o této skuteˇcnosti TUL;

v tomto pˇr´ıpadˇe má TUL právo ode mne poˇzadovat úhradu náklad˚u, které vynaloˇzila na vytvoˇren´ı d´ıla, aˇz do jejich skuteˇcné výˇse.

Bakaláˇrskou práci jsem vypracoval samostatnˇe s pouˇzit´ım uvedené literatury a na základˇe konzultac´ı s vedouc´ım mé bakaláˇrské práce a konzultantem.

Souˇcasnˇe ˇcestnˇe prohlaˇsuji, ˇze tiˇstˇen´a verze pr´ace se shoduje s elek- tronickou verz´ı, vloˇzenou do IS STAG.

Datum:

Podpis:

(5)

Podˇ ekov´ an´ı

T´ımto bych rád podˇekoval vedouc´ımu mé Bakaláˇrské práce, Ing. Janu Krausovi, Ph.D., za uˇziteˇcné odborné rady a cenné pˇripom´ınky, které pˇrispˇely k úspˇeˇsnému dokonˇcen´ı této práce.

(6)

Abstrakt

Tento dokument se zabývá Bakaláˇrskou prac´ı Fakulty mechatroniky, informatiky a mezioborových studi´ı Technické univerzity v Liberci. Jej´ım c´ılem je popsat roˇcn´ıkovou práci. Bakaláˇrská práce obsahuje obecnou reˇserˇsi komunikaˇcn´ıch protokol˚u pro chytré s´ıtˇe a budovy. Následnˇe byly pro vybrané protokoly naprogramovány jednoduché pˇr´ıklady pro demonstrován´ı jejich funkc´ı. Ukázky byly programovány ve vývojovém prostˇred´ı Microsoft Visual Studio pomoc´ı jazyka C#. Jedná se o konzolové aplikace, které jsou v závˇeru práce porovnány. Výsledkem této práce je reˇserˇse komunikaˇcn´ıch protokol˚u pro chytré s´ıtˇe a budovy a jednoduché pˇr´ıklady, které se daj´ı v praxi pouˇz´ıt pro základ aplikac´ı tˇechto protokol˚u.

Kl´ıˇ cov´ a slova:

komunikaˇcn´ı protokoly, chytré budovy, chytré s´ıtˇe, C#, konzolové aplikace

Abstract

This document deals with the Bachelor thesis of the Faculty of Me- chatronics, Informatics and Interdisciplinary Studies of the Techni- cal University in Liberec. Its aim is to describe the coursework.

The bachelor thesis contains general research of communication protocols for smart networks and buildings. Subsequently, simple examples for demonstrating their functions were programmed for selected protocols. The samples were programmed in the Microsoft Visual Studio development environment using C#. These are console applications that are compared at the end of the thesis. The result of this work is a review of communication protocols for smart networks and buildings and simple examples that can be used in practice for the basis of application these protocols.

Key words:

communication protocols, smart buildings, smart grids, C#, console application

(7)

Obsah

1 Uvod´ 9

2 Pˇrehled komunikaˇcn´ıch protokol˚u 10

2.1 Chytr´e s´ıtˇe. . . 10

2.1.1 DLMS / COSEM . . . 10

2.1.2 IEC 61850 . . . 12

2.1.3 IEC 60870-5-104 . . . 13

2.1.4 Z-wave . . . 14

2.1.5 ZigBee . . . 15

2.1.6 6LoWPAN . . . 16

2.2 Chytr´e budovy . . . 18

2.2.1 MQTT . . . 18

2.2.2 Modbus . . . 20

2.2.3 BACnet . . . 21

2.2.4 M-BUS . . . 22

2.2.5 KNX . . . 24

2.2.6 CANopen . . . 25

2.2.7 Profinet . . . 26

2.2.8 OPC UA . . . 27

2.2.9 Dalˇs´ı m´enˇe rozˇs´ıˇren´e protokoly. . . 29

3 V´ybˇer protokol˚u 30 4 Jednotliv´e aplikace 31 4.1 MQTT . . . 31

4.2 OPC UA . . . 34

4.3 IEC 60870-5-104 . . . 36

4.4 DLMS/COSEM . . . 40

5 Shrnut´ı 41

6 Z´avˇer 43

A Obsah pˇriloˇzen´eho CD 50

(8)

Seznam obr´ azk˚ u

4.1 MQTT - posl´an´ı zpr´avy a pˇripojen´ı . . . 31

4.2 MQTT - odpojen´ı clienta. . . 32

4.3 MQTT- recconecting . . . 33

4.4 MQTT - reconnected . . . 33

4.5 MQTT - tvar dat . . . 33

4.6 OPC UA - uk´azka nepouˇzit´e knihovny . . . 34

4.7 OPC UA - pˇripojen´ı . . . 35

4.8 OPC UA - odpojen´ı . . . 35

4.9 OPC UA - funkce . . . 36

4.10 OPC UA - tvar blok˚u serveru . . . 36

4.11 IEC 60870-5-104 - pˇripojen´ı . . . 37

4.12 IEC 60870-5-104 - odpojen´ı . . . 37

4.13 IEC 60870-5-104 - tvar pos´ılan´ych dat . . . 38

(9)

1 Uvod ´

Hlavn´ım c´ılem této bakaláˇrské práce je udˇelat obecnou reˇserˇsi nejv´ıce pouˇz´ıvaných komunikaˇcn´ıch protokol˚u jak v chytrých s´ıt´ıch, tak i v chytrých budovách. Následnˇe jsou v této práci vybrány ˇctyˇri z tˇechto protokol˚u. Pro tyto protokoly jsou následnˇe naprogramovány jednoduché aplikace, na kterých jsou zobrazeny jejich funkce pˇrenosu dat a jejich odliˇsnosti, pˇr´ıpadnˇe jejich specifické funkce.

Práce je rozvrˇzena do v´ıce ˇcást´ı. Prvn´ı ˇcást této práce se zabývá obecnou reˇserˇs´ı.

Pro výbˇer tˇechto protokol˚u byly nastaveny urˇcitá kritéria. Hlavn´ım kritériem pro výbˇer komunikaˇcn´ıch protokol˚u je pouˇzit´ı v energetice, pˇr´ıpadnˇe v pr˚umyslové automatizaci. Dalˇs´ım kritériem pro výbˇer protokol˚u do reˇserˇse bylo ˇsirˇs´ı pouˇzit´ı daného protokolu. Protokoly vyuˇz´ıvané jednou nebo dvˇema firmami nejsou tolik zaj´ımavé.

Druhá ˇcást této práce se zabývá výbˇerem protokol˚u pro následné programován´ı jed- notlivých aplikac´ı. Tˇret´ı ˇcást je samotný popis jednotlivých aplikac´ı a ukázka funkc´ı jednotlivých protokol˚u v daných aplikac´ıch.

V závˇeru práce jsou shrnuta jednotlivá zjiˇstˇená fakta. Následnˇe jsou zde popsány rozd´ıly jednotlivých aplikac´ı daných protokol˚u, rozd´ıly, jak jsou data pos´ılány, jaké funkce tyto protokoly odliˇsuj´ı a zda jdou v protokolech pos´ılat veˇskerá data. Dále jsou v závˇeru popsány osobn´ı poznatky k výbˇeru protokol˚u pro programován´ı aplikac´ı, výbˇeru knihoven pro aplikace, i jednotlivé poznatky k samotnému programován´ı s knihovnami.

(10)

2 Pˇ rehled komunikaˇ cn´ıch protokol˚ u

2.1 Chytr´ e s´ıtˇ e

Chytrá s´ıt’ je silová elektrická a komunikaˇcn´ı s´ıt’, která umoˇzˇnuje regulovat výkon a spotˇrebu elektrické energie v reálném ˇcase. Chytré s´ıtˇe m´ıt jak malé i globáln´ı rozmˇery.

Principem tˇechto s´ıt´ı je obousmˇerná interaktivn´ı komunikace mezi vˇsemi prvky této s´ıtˇe. Prvky mohou být spotˇrebiˇce, výrobn´ı stroje nebo klidnˇe i zadávac´ı pa- nel poˇzadavk˚u na danou s´ıt’. Nevýhodou tˇechto s´ıt´ı je bezpeˇcnostn´ı riziko odpo- sloucháván´ı citlivých údaj˚u.

Inteligentn´ı s´ıtˇe mohou dosáhnout stádia plné automatizace. To znamená, ˇze s´ıt’

obsahuje kontroln´ı a ˇr´ıdic´ı systém. Senzory monitoruj´ı chován´ı dané s´ıtˇe a dávaj´ı informaci ˇr´ıdic´ımu systému. Tento systém data vyhodnot´ı a provede zásahy do s´ıtˇe tak, aby nenastala porucha, nebo se dostateˇcnˇe rychle odstranila a s´ıt’ bˇeˇzela a fungovala podle p˚uvodn´ıho zadán´ı.

Mezi protokoly pro chytr´e s´ıtˇe se mohou zaˇradit tyto protokoly:

1. DLMS / COSEM 2. IEC 61850

3. IEC 60870-5-104 4. Z-wave

5. ZigBee 6. 6LoWPAN

2.1.1 DLMS / COSEM

Komunikaˇcn´ı protokol DLMS (Device Language Message Specification) se v lite- ratuˇre velmi ˇcasto objevuje pod názvem DLMS/COSEM. Nazývá se tak, jelikoˇz to jsou dvˇe rozd´ılné vˇeci, které se vˇsak pouˇz´ıvaj´ı zásadnˇe spolu. DLMS/COSEM pouˇz´ıvá DLMS komunikaˇcn´ı protokol a COSEM rozhran´ı, které definuje tˇr´ıdy v

(11)

aplikaˇcn´ı a transportn´ı vrstvˇe protokolu DLMS. D´a se tedy ps´at oboje, jak DLMS tak i DLMS/COSEM protokol.

Je navrˇzen pro podporu zas´ılán´ı dat mezi distribuˇcn´ımi zaˇr´ızen´ımi, sluˇzby vzdáleného mˇeˇren´ı dat, vzdálené ovládán´ı zaˇr´ızen´ı. DLMS protokol má vlastn´ıˇradu norem pouze k vyuˇzit´ı v energetice, tato ˇrada se nazývá IEC 62056.

Komunikace

Data pˇri komunikaci v DLMS jsou rozˇrazeny do tˇr´ıd. Data jsou rozˇrazeny podle hodnot nebo informac´ı, které obsahuj´ı. Tˇr´ıdy obsahuj´ı objekty. Objekt je kolekce atribut˚u a metod. Atributy obsahuj´ı samotná data. Atributy obsahuj´ı názvy a hodnoty. Metody jsou urˇcité funkce, které mohou data poskytovat nebo mˇenit hodnoty atribut˚u. Samotné tˇr´ıdy jsou kolekce objekt˚u.

Komunikace DLMS protokolu funguje na hierarchickém principu. DLMS protokol obsahuje hlavn´ı a nˇekolik niˇzˇs´ıch vrstev (uˇzivatelská, objektová, aplikaˇcn´ı a niˇzˇs´ı tˇr´ıdy zpracovávaj´ıc´ı data). Uˇzivatel má pˇr´ımý pˇr´ıstup k objekt˚um neboli tˇr´ıdám, takˇze i samotným dat˚um. K tˇemto dat˚um se dostává pomoc´ı jmen a samotných kód˚u. Uˇzivatel zadává i parametr co se s daty bude d´ıt. Tento parametr bude zpra- cován podle pˇr´ısluˇsné tˇr´ıdy a následnˇe pˇredán do aplikaˇcn´ı vrstvy. Aplikaˇcn´ı vrstva vloˇz´ı výstup z objektové vrstvy do samotného zaˇr´ızen´ı, kterému data pˇr´ısluˇs´ı a celý tento poˇzadavek, co se má d´ıt, pˇredá do niˇzˇs´ıch vrstev, kde se data jiˇz zpracovávaj´ı v jednotlivých zaˇr´ızen´ıch.

Klient a server mezi sebou mohou komunikovat ve vˇsech vrstvách. Je vˇsak potˇreba nejdˇr´ıve provést asociace. Asociace se provád´ı pˇri navazován´ı spojen´ı v aplikaˇcn´ı vrstvˇe a pˇri asociaci si klient a server stanov´ı urˇcité komunikaˇcn´ı parametry, které pˇri komunikaci mus´ı dodrˇzovat. Po navázán´ı spojen´ı se m˚uˇze klient dotazovat pˇr´ımo na data v serveru a naopak.

Protokol DLMS je nadstavba UDP/IP protokolu. Komunikace v DLMS je bin´arn´ı, ale pˇri pouˇzit´ı IEC 62056 se prov´ad´ı komunikace v ASCII.

Pouˇzit´ı

DLMS protokol se m˚uˇze pouˇz´ıt jak v energetice tak i v bˇeˇzném domác´ım pouˇzit´ı. Má nevýhodu, ˇze je tˇreba udrˇzovat stálé a stabiln´ı spojen´ı komunikace. Dalˇs´ı nevýhodou je, ˇze DLMS pracuje jako nadstavba UDP/IP, protoˇze potˇrebuje vˇetˇs´ı ˇs´ıˇrku pásma pro komunikaci a je pomalejˇs´ı, jelikoˇz pˇri navazován´ı komunikace je sloˇzitˇejˇs´ı.

DLMS protokol bych tedy pouˇzil v s´ıt´ıch kde je zaruˇcená stabiln´ı komunikace, nezáleˇz´ı na rychlosti, zaˇr´ızen´ı jsou napájeny s´ıt’ovými zdroji.

Nejpouˇz´ıvanˇejˇs´ı knihovnou pro tento protokol je open source knihonva Gurux. Tato knihovna slouˇz´ı k implementaci funkc´ı pro server i clienta.

(12)

2.1.2 IEC 61850

IEC 61850 je soubor norem pro komunikaci mezi zaˇr´ızen´ımi pˇredevˇs´ım v energe- tických rozvodnách a elektrických soustavách. IEC 61850 dále stanovuje poˇzadavky, které jsou potˇreba zajistit pˇri komunikaci v rozvodnách. Obsahuje komunikaˇcn´ı protokoly, ale také i urˇcité standardy pro ˇr´ızen´ı zaˇr´ızen´ı.

C´ıle protokolu

Hlavn´ım d˚uvodem vytvoˇren´ı tohoto protokolu bylo, ˇze ve svˇetˇe bylo nespoˇcet r˚uzných komunikaˇcn´ıch protokol˚u pro komunikaci v energetice a kaˇzdý mˇel svoje vlastn´ı pravidla. Tud´ıˇz pˇri tvorbˇe chytré s´ıtˇe, pro rozvodnu, bylo potˇreba brát ohled na výrobce a jaké zaˇr´ızen´ı dokáˇze komunikovat s jakým protokolem.

C´ılem tohoto protokolu bylo tedy sjednotit pravidla komunikace a umoˇznit vytvoˇren´ı s´ıt´ı, v kterých budou komunikovat mezi sebou zaˇr´ızen´ı bez ohledu na výrobce. Tyto zaˇr´ızen´ı, neboli IED (Intelligent Electronic Device) zajiˇst’uj´ı ochranu a provoz rozvodny, tud´ıˇz v ˇzádném pˇr´ıpadˇe nemohlo nastat, ˇze se pˇreruˇsila komunikace mezi dvˇema zaˇr´ızen´ımi z d˚uvodu, ˇze kaˇzdý výrobce si jeho komunikaci udˇelal po svém.

Komunikace

Architektura komunikaˇcn´ıch protokol˚u pro normu IEC 61850 je typu klient a server. Avˇsak má výhodu, ˇze se snaˇz´ı odstraˇnovat hlavn´ı nevýhody této architektury t´ım, ˇze umoˇzˇnuje i klient˚um ˇr´ıdit pˇrenos dat a komunikaci. Tato výhoda dovoluje pˇresunout ˇr´ıd´ıc´ı a komunikaˇcn´ı funkce bl´ıˇze k potˇrebným zaˇr´ızen´ım a umoˇzˇnuje zvýˇsit komunikaˇcn´ı rychlosti a stabilitu pˇrenosu, jelikoˇz pˇrenos m˚uˇze být navázán na menˇs´ı vzdálenosti.

Komunikace prob´ıhá formou publish/subscribe. Data od klient˚u jdou do urˇcitého serveru a ten následnˇe rozes´ılá tˇem, co si data objednaj´ı. M˚uˇze zde být i reˇzim multicasting. Server pos´ılá data vˇsem úˇcastn´ık˚um s´ıtˇe, ale data ˇctou pouze ti, co si je objednali (subscribers).

D´ale umoˇzˇnuje integrovat vˇsechny komunikaˇcn´ı, ˇr´ıdic´ı, ochrann´e a mˇeˇr´ıc´ı funkce pro chod a ochranu rozvoden.

Data se pos´ılaj´ı v tzv. objektech. Tyto objekty spojuj´ı data a programy, takˇze veˇskeré informace a funkce se nacházej´ı na jednom m´ıstˇe. D´ıky tomu je pro uˇzivatele i jednotlivá zaˇr´ızen´ı mnohem snazˇs´ı pˇr´ıstup k dat˚um a funkc´ım s nimi spojených.

IEC 61850 kombinuje ethernet s vysokým výkonem a zabezpeˇcen´ım. T´ım poskytuje vysokorychlostn´ı ochranu, uzamˇcen´ı a pˇrep´ınán´ı. Toto je zajiˇstˇeno vysokorychlostn´ım pˇrenosem kritických dat.

(13)

Pouˇzit´ı

IEC 61850 se pouˇz´ıvá pouze pro komunikaci chytrých s´ıt´ı v energetice. Nejvˇetˇs´ı výhodou je vzájemná kompatibilita zaˇr´ızen´ı v energetice. Vyuˇz´ıvá se pro rozvodny, komunikaci mezi rozvodnami a elektrárnami, vysokorychlostn´ı komunikaci vˇsude v energetice.

Pro tento protkol se nejˇcastˇeji pouˇz´ıv´a open source knihovna OpenIEC61850. Tato knihovna poskytuje veˇsker´e funkce protkolu v jazyce Java.

2.1.3 IEC 60870-5-104

Standard IEC 60870-5-104 definuje funkci systém˚u a protokol˚u pouˇz´ıvaných pro vzdálenou správu dat, jejich prohl´ıˇzen´ı a ˇr´ızen´ı. Tato norma se zabývá pouze daty v automatizaˇcn´ıch systémech a energetických automatizaˇcn´ıch systémech. Popisuje komunikaˇcn´ı profil pro zas´ılán´ı dat mezi dvˇema zaˇr´ızen´ımi.

IEC 60870-5-104 je rozˇs´ıˇren´ı IEC 60870-5-101 o nˇekolik transportn´ıch funkc´ı protokolu TCP/IP. Jedná se tedy o dalˇs´ı nadstavbu protokolu. Lze tedy vyuˇz´ıvat témˇeˇr veˇskeré funkce protokolu TCP/IP.

Komunikace

Komunikace v protokolech vycházej´ıc´ıch z normy IEC 60870-5-104 pracuj´ı na modelu master-slave. To znamená, ˇze urˇcité zaˇr´ızen´ı (master), pˇri komunikaci ˇr´ıd´ı pˇrenos dat a pracuje s nimi a dalˇs´ı (slave) data poskytuj´ı a pracuj´ı tak, jak master urˇc´ı. Toto se provád´ı pˇredevˇs´ım pˇri komunikaci na sbˇernici. Master tyto poˇzadavky na dalˇs´ı zaˇr´ızen´ı rozes´ılá postupnˇe, nikoli najednou. Kaˇzdé zaˇr´ızen´ı slave reaguje pouze na data, která mu jsou urˇceny, ostatn´ı ignoruje.

Tento typ komunikace má velkou nevýhodu, jelikoˇz data na sbˇernici m˚uˇze odpo- slouchávat jakékoli pˇripojené zaˇr´ızen´ı. Pˇri komunikaci pouze mezi stroji, vˇsak na toto bezpeˇcnost´ı riziko nemus´ıme brát pˇr´ıliˇs velký ohled. V rozvodnách je tato bezpeˇcnost d˚uleˇzitˇejˇs´ı.

U komunikace mezi stroji vˇetˇsinou pˇrenos dat ˇr´ıd´ı PLC. Ostatn´ı akˇcn´ı ˇcleny, re- gulátory a podobné zaˇr´ızen´ı, jsou slave jednotky. V energetických soustavách zpra- vidla soustavu ˇr´ıd´ı poˇc´ıtaˇc. ˇR´ıd´ı zbylé jednotky, které se staraj´ı o chod elektráren a rozvoden.

IEC 60870-5-104 obsahuje implementované funkce vylepˇsuj´ıc´ı architekturu master- slave. Jedna z funkc´ı je napˇr´ıklad, ˇze slave m˚uˇze obsahovat kritické informace, které jsou potˇreba zpracovávat pˇrednostnˇe. Tyto informace pak mohou m´ıt vyˇsˇs´ı prioritu a mohou být doruˇceny masteru i bez toho aniˇz, by si o nˇe ˇrekl. Tato funkce výraznˇe zlepˇsuje bezpeˇcnostn´ı chod energetických s´ıt´ı.

(14)

Pouˇzit´ı

Komunikaˇcn´ı protokoly normy IEC 60870-5-104 se mohou pouˇz´ıt nejen v energetice.

Mnohem v´ıce, neˇz v energetice, se vyuˇz´ıvaj´ı u automatizaˇcn´ıch systém˚u, ale pouˇzit´ı v energetice m˚uˇze m´ıt také své výhody. Dále se také mohou hodit vˇsude, kde je potˇreba zajistit chod událost´ı po sobˇe, jelikoˇz data (události) mohou obsahovat i ˇcas, kdy k nim doˇslo.

Mohou být vhodné pro výrobn´ı linky, energetické rozvodny, s´ıtˇe, kde je potˇreba kontrolovat sekvenˇcn´ı chod a s´ıtˇe, kde je potˇreba zajistit rychlé odpovˇedi v pˇr´ıpadˇe po- ruchy. K pouˇzit´ı tohoto protkolu je vejv´ıce rozˇs´ıˇrená knihovna IEC 60870-5-101/104 C#/.NET v jazyce C#. Tato knihovna poskytuje funkce serveru i clienta.

2.1.4 Z-wave

Z-wave je komunikaˇcn´ı protokol vytvoˇrený primárnˇe pro domác´ı automatizace a IoT. Byl vyvinut pro ovládán´ı, monitoring a zajiˇstˇen´ı urˇcitých stav˚u v budovách urˇcených pro bydlen´ı a v menˇs´ıch budovách pro soukromé pouˇzit´ı. Z-wave je urˇcen k bezdrátové komunikaci. Protokol je standardizován a lze propojit mezi produkty od r˚uzných výrobc˚u. Byl navrˇzen pro zaˇr´ızen´ı, které nemaj´ı vysoké energetické poˇzadavky a pracuj´ı pouze s malými objemy dat.

Komunikace

Pro komunikaci mezi jednotlivými zaˇr´ızen´ımi pouˇz´ıvá vlastn´ı vyhrazenou ˇs´ıˇrku pásma.

Tato ˇs´ıˇrka pásma neprot´ıná a ani se nebl´ıˇz´ı ˇs´ıˇrkám pásma Wi-Fi nebo Bluetooth.

Vyuˇz´ıv´a 800 – 900 MHz v z´avislosti na kontinentu, kde je protokol pouˇzit (v Evropˇe se tato frekvence pohybuje v okol´ı 869 MHz).

Protokol Z-wave má sm´ıˇsenou topologii s´ıtˇe. To znamená, ˇze nˇekterá zaˇr´ızen´ı v s´ıt´ı mohou být propojeny s v´ıce neˇz jedn´ım dalˇs´ım zaˇr´ızen´ım v s´ıti. Tato topologie se nˇekdy také nazývá s´ıt’ová topologie.

V s´ıti se nacház´ı centráln´ı prvek, který rozdává pˇr´ıkazy jednotlivým zaˇr´ızen´ım. Toto má za d˚usledek zpomalen´ı chodu s´ıtˇe a tak Z-wave protokol podporuje rozdáván´ı pˇr´ıkaz˚u kaˇzdého zaˇr´ızen´ı v s´ıti. Dokáˇze sledovat a ˇr´ıdit pr˚ubˇeh jiných zaˇr´ızen´ı.

Centr´aln´ı zaˇr´ızen´ı tak slouˇzi pouze ke kontrole nebo k nov´emu nastaven´ı s´ıtˇe uˇzivatelem.

Pouˇzit´ı

Pouˇzit´ım protokolu Z-wave z´ısk´ame velmi rychlou komunikaci s malou odezvou.

Nevýhodou této rychlé komunikace s malou odezvou je dosah a objem dat. Lze pos´ılat pouze velmi malé packety. Vzdálenost, na kterou jsou schopna dvˇe zaˇr´ızen´ı

(15)

spolehlivˇe komunikovat, se udává do 30 aˇz 40 metr˚u. Pokud je vyuˇzit na volném prostranstv´ı, ne uvnitˇr budovy, zvedne se dosah aˇz na 100 metr˚u.

V´yhodou pouˇzit´ı toho protokolu je, ˇze podporuje takzvanou schopnost ”plug &

play”. To znamená, ˇze zaˇr´ızen´ı staˇc´ı pˇripojit do s´ıtˇe a okamˇzitˇe se samo nastav´ı a zaˇcne komunikovat s dalˇs´ım zaˇr´ızen´ımi. Dalˇs´ı výhodou je, ˇze staˇc´ı pˇripojit pouze jedno zaˇr´ızen´ı k internetu a následnˇe lze celou s´ıt’ kontrolovat a nastavovat pomoc´ı vzdáleného webového prohl´ıˇzeˇce nebo chytrého telefonu. Pouˇzit´ı toho protokolu je vymezeno výhradnˇe pro domác´ı úˇcely chytrých dom˚u a nelze tento protokol pouˇz´ıt v energetice ani ˇzádném dalˇs´ım pr˚umyslovém odvˇetv´ı. Neobsahuje ˇzádné nadstavby nebo vlastn´ı normy pro pouˇzit´ı v energetice. Tento protokol se ˇcistˇe soustˇred´ı na chytré domácnosti.

Nejˇcastˇejˇs´ı pouˇzit´ı Z-wave protokolu prob´ıhá pˇres knihovnu OpenZWave. Jak uˇz nadpis napov´ıdá, jedná se o open source knihovnu. Knihovna poskytuje tˇr´ıdy pro pˇrij´ıman´ı a vys´ılán´ı dat a mnoho dalˇs´ıch.

2.1.5 ZigBee

ZigBee je bezdrátový komunikaˇcn´ı protokol postavený na základech protokolu Blu- etooth, proto také spadá do stejné skupiny norem. Stejnˇe jako Bluetooth je urˇcen pro zaˇr´ızen´ı s n´ızkým výkonem. ZigBee podporuje komunikaci na delˇs´ı vzdálenosti bez, pˇr´ımé radiové viditelnosti jednotlivých zaˇr´ızen´ı. ZigBee byl primárnˇe navrˇzen pro pr˚umyslové pouˇzit´ı. Nejedná se tedy o pokus vytvoˇren´ı konkurenˇcn´ıho protokolu pro Bluetooth, ale o jeho doplnˇek pro pr˚umysl.

ZigBee byl navrˇzen pro aplikace, kde nen´ı Bluetooth vhodný. Jedná se tedy o hodnˇe podobný protokol, který vˇsak neslouˇz´ı pro osobn´ı vyuˇzit´ı, ale slouˇz´ı primárnˇe pro pr˚umyslové aplikace.

Komunikace

Komunikace tohoto protokolu je provádˇena v úzkém komunikaˇcn´ım pásmu. Toto pásmo se pohybuje témˇeˇr totoˇznˇe s pásmem protokolu Z-wave, nenaruˇsuje tedy pásma Wi-Fi ani Bluetooth.

ZigBee m˚uˇze m´ıt 3 druhy topologie. Prvn´ım a nejv´ıce pouˇz´ıvanou je hvˇezdicová topologie s centráln´ım zaˇr´ızen´ım. Druhým typem topologie je hvˇezdicová topologie. Tato topologie umoˇzˇnuje delˇs´ı komunikaˇcn´ı vzdálenosti. Pokud u této topologie vyuˇzijeme redundantn´ı spojen´ı, vznikne stejná topologie jako u Z-wave, tedy sm´ıˇsenou neboli s´ıt’ovou topologi´ı. Redundantn´ı spojen´ı znamená, ˇze se vytvoˇr´ı spojen´ı mezi zaˇr´ızen´ımi, kde to nen´ı nutné, ale v pˇr´ıpadˇe výpadku se tato spojen´ı mohou pouˇz´ıt. Zaˇr´ızen´ı je spojeno s kaˇzdým dalˇs´ım zaˇr´ızen´ım v dosahu. D´ıky tomu nen´ı tˇreba dbát na poˇrad´ı um´ıstˇen´ı prvk˚u, ale staˇc´ı pouze kontrolovat, zda se nacház´ı v dosahu alespoˇn jednoho dalˇs´ıho zaˇr´ızen´ı, které je pˇripojeno do s´ıtˇe.

(16)

ZigBee si dˇel´ı zaˇr´ızen´ı v s´ıti na dva druhy. Prvn´ı se nazývá FFD – Full Functional De- vice, neboli zaˇr´ızen´ı s plnou funkˇcnost´ı. Druhý typ je zaˇr´ızen´ı s omezenou funkˇcnost´ı a ten se nazývá RFD – Reduced Functionality Device. Zaˇr´ızen´ı s plnou funkˇcnost´ı obsahuj´ı kompletn´ı protokol a mohou vyuˇz´ıvat veˇskeré sluˇzby, které ZigBee nab´ız´ı.

Zaˇr´ızen´ı s omezenou funkˇcnost´ı obsahuj´ı pouze nezbytné rámce protokolu a slouˇz´ı pouze jako koncová. Tyto zaˇr´ızen´ı jsou omezena z d˚uvodu omezeného hardwaru.

Protokol dovoluje i implementaci zabezpeˇcen´ı. Toto zabezpeˇcen´ı vyuˇz´ıvá takzvané kl´ıˇce, které mohou být jiˇz pˇriˇrazeny k MAC adrese zaˇr´ızen´ı, nebo vytvoˇreny pˇri instalaci zaˇr´ızen´ı do s´ıtˇe. Vytváˇren´ı kl´ıˇc˚u ˇr´ıd´ı centráln´ı zaˇr´ızen´ı. Toto zaˇr´ızen´ı také kontroluje veˇskerou komunikaci a t´ım m˚uˇze kontrolovat i kl´ıˇce. T´ımto zp˚usobem protokol zajiˇst’uje urˇcitý stupeˇn bezpeˇcnosti naruˇsen´ı.

Jednotlivá zaˇr´ızen´ı jsou pˇri komunikaci adresovány pomoc´ı binárn´ıch adres. Tyto adresy mohou m´ıt dvˇe podoby, dlouhou nebo krátkou verzi. Pouˇzit´ı krátké verze je urˇceno pˇredevˇs´ım pro RFD zaˇr´ızen´ı. Pouˇzit´ı této zkrácené verze uˇsetˇr´ı 48 bit˚u pamˇeti zaˇr´ızen´ı. Je to tedy pouˇzito u extrémnˇe jednoduchých zaˇr´ızen´ı. Pˇri komunikaci dvou s´ıt´ı mezi sebou je k adresaci pouˇzito ID s´ıtˇe.

Pouˇzit´ı

Pˇri pouˇzit´ı toho protokolu z´ıskáme s´ıt’, která má velice pomalé pˇrenosové rychlosti, avˇsak pˇrenos dat je pomˇernˇe stabiln´ı. Pˇrenos je dále odolný oproti ruˇsen´ı jiným bezdrátovým pˇrenosem, jelikoˇz pˇrenos prob´ıhá ve vzdáleném pásmu od bˇeˇzných pˇrenosovým pásem.

Pouˇzit´ı je také velice vhodné pro s´ıtˇe, kde jsou pouˇzity zaˇr´ızen´ı s bateriemi. Protokol má velice n´ızkou spotˇrebu energie. Nen´ı vhodný pro aplikace, kde je potˇreba pˇrenáˇset velký objem dat s vysokou rychlost´ı. Pro ˇr´ızen´ı energetiky je tedy nevhodný, protoˇze v energetice je rychlost pˇrenosu kritických dat témˇeˇr nutnost´ı.

D´ıky tˇemto vlastnostem se s protokolem setkáme v pr˚umyslové automatizaci, zdra- votnictv´ı (monitorován´ı pacient˚u), chytré domácnosti (zabezpeˇcen´ı, osvˇetlen´ı, topen´ı), poˇc´ıtaˇcovém pr˚umyslu (bezdrátové periferie).

Nejˇcastˇei se tento protokol pouˇz´ıv´a s knihovnou SiplmeZigBee. Tato knihovna je urˇcena pro Arduino a poskytuje funkce pro komunikaci v s´ıti ZigBee.

2.1.6 6LoWPAN

Protokol 6LoWPAN spadá pod úplnˇe stejnou normu jako ZigBee. Kaˇzdý z nich si vˇsak postavil jinou nadstavbu nad touto normou a kaˇzdý pracuje troˇsku jinak.

Základ vˇsak maj´ı stejný a pracuj´ı ve stejném frekvenˇcn´ım pásmu. Stejnˇe jako ZigBee a Z-wave byl navrˇzen pro n´ızko výkonové s´ıtˇe. Byl navrˇzen pro s´ıtˇe, kde je rychlost pˇrenosu dat relevantn´ı a vyˇzaduj´ı pˇredevˇs´ım spolehlivost pˇrenosu dat. 6LoWPAN propojuje Internet protokolu (IP), konktrétnˇe IPv6, a bezdrátové s´ıtˇe definované

(17)

normou IEEE 802.15.4. Tato norma definuje bezdrátové komunikaˇcn´ı s´ıtˇe. Hlavn´ım c´ılem tohoto protokolu bylo vytvoˇrit protokol, který nen´ı nároˇcný na spotˇrebu energie a zároveˇn zaˇr´ızen´ı mohou být pˇripojeny k internetu a vyuˇz´ıvat Internet Protokol verze 6. T´ım z´ıskáme s´ıt’, která se nemus´ı pˇripojovat do internetu, protoˇze sama je ˇcást internetu a lze se na kaˇzdá zaˇr´ızen´ı pˇripojit celkem snadno z jakéhokoli zaˇr´ızen´ı, které je také pˇripojeno na internet.

Komunikace

Architektura s´ıtˇe m´a stejnou topologii jako ZigBee nebo Z-wave, tedy s´ıt’ovou.

Kaˇzdé zaˇr´ızen´ı je propojeno se vˇsemi v dosahu. Správném rozm´ıstˇen´ım zaˇr´ızen´ı se dá zvˇetˇsovat ˇci zmenˇsovat dosah s´ıtˇe. V s´ıti se vˇsak nacház´ı dalˇs´ı 2 zaˇr´ızen´ı nav´ıc oproti ZigBee nebo Z-wave. Nacház´ı se zde webový server a takzvaná brána. Brána oddˇeluje internet od naˇs´ı vnitˇrn´ı s´ıtˇe. Webový server zase publikuje data na internet a zpracovává data z nˇej. V s´ıti se m˚uˇze nacházet centráln´ı zaˇr´ızen´ı, pomoc´ı kterého uˇzivatel rozdává pˇr´ıkazy, jak se s´ıt’ má chovat, nutné to ale nen´ı. Jako zaˇr´ızen´ı, pomoc´ı kterých uˇzivatel bude rozdávat pˇr´ıkazy, m˚uˇze slouˇzit jakékoli zaˇr´ızen´ı pˇripojeno k internetu a pˇres bránu se uˇzivatel m˚uˇze vzdálenˇe pˇripojit do s´ıtˇe. Kaˇzdé zaˇr´ızen´ı v s´ıt´ı m˚uˇze ˇc´ıst data z ostatn´ıch a podle nich pˇrizp˚usobit sv˚uj chod. Zaˇr´ızen´ı mohou být aktivn´ı, mohou nastavovat ostatn´ı zaˇr´ızen´ı, nebo pasivn´ı, ty mohou jen prezentovat svoje data.

Ke komunikaci m˚uˇze 6LoWPAN vyuˇz´ıvat jak IEEE 802.15.4, tak i Ethernet nebo Wi-Fi. 6LoWPAN vyuˇz´ıvá veˇskeré funkce IPv6 a pomoc´ı toho protokolu se i adre- suje. M˚uˇze vyuˇz´ıvat i systém zabezpeˇcen´ı ”Acces Control List”. Toto zabezpeˇcen´ı slouˇz´ı k obranˇe proti neoprávnˇenému pˇr´ıstupu z internetu do vnitˇrn´ı s´ıtˇe.

Pouˇzit´ı

6LoWPAN nemá ˇzádné pˇr´ımé urˇcen´ı. Je vˇsak navrhnut pro pomalé pˇrenosové rychlosti, protoˇze pˇrenos dat prob´ıhá po malých rámc´ıch. Jeho výhodou je snadná adresace a také vyuˇz´ıván´ı veˇskerých funkc´ı IPv6. Nevýhodou je nutnost znalosti IP protokolu, pro schopnost naprogramovat s´ıt’ s protokolem 6LoWPAN. Dále je nutnost pˇripojen´ı do internetu, coˇz m˚uˇze zp˚usobit jisté bezpeˇcnostn´ı riziko. Pˇri soukromém pouˇzit´ı nás toto riziko nemus´ı pˇr´ıliˇs zaj´ımat, ale pˇri pouˇzit´ı v energetice uˇz se toto riziko zvyˇsuje. Z tˇechto d˚uvod˚u se tento protokol z mého pohledu hod´ı pˇredevˇs´ım pro domác´ı aplikace. Dále je moˇznost pouˇzit´ı pro pr˚umyslové aplikace, kde nen´ı potˇreba velká pˇrenosová rychlost, ale je zde potˇreba urˇcitá spolehlivost s moˇznost´ı existence urˇcitého bezpeˇcnostn´ıho rizika naruˇsen´ı nebo odposloucháván´ı dat.

Nejv´ıce rozˇs´ıˇrenou knihovnou pro tento protokol je Contiki. Tato knihovna poskytuje komunikaci protokol˚u 6lowpan, RPL a CoAP.

(18)

2.2 Chytr´ e budovy

Chytrá budova je taková budova, která vyuˇz´ıvá technologii ke sd´ılen´ı informac´ı o tom, co se dˇeje v jednotlivých systémech budovy tak, aby optimalizovala jej´ı

´

uˇcinnost. Toto sd´ılen´ı informac´ı se pouˇz´ıv´a pˇredevˇs´ım k automatizaci r˚uzn´ych proces˚u, napˇr´ıklad topen´ı, klimatizace, bezpeˇcnost a dalˇs´ı.

Vybudován´ı chytrých budov je velice nákladné. V pˇr´ıpadˇe rozhodnut´ı o vybudován´ı, jsou tyto náklady akceptovatelné, protoˇze po vybudován´ı chytrých budov se zvýˇs´ı výkonnost budovy a t´ım se uˇsetˇr´ı pen´ıze - at’ uˇz jen na topen´ı nebo klimatizován´ı.

Casto jsou tyto syst´ˇ emy naistalovány ˇspatnˇe, takzvanˇe neinteligentnˇe, a tud´ıˇz budova neslouˇz´ı jako chytrá budova, ale pouze jako budova v chytrými aplikacemi.

Hlavn´ım c´ılem inteligentn´ıch budov je zabránit plýtván´ı energiemi a zdroji. Dalˇs´ım c´ılem je sn´ıˇzen´ı náklad˚u, zvýˇsen´ı výkonnosti a energetické úˇcinnosti budov.

N´asledujc´ı protokoly pro chytr´e budovy se ˇrad´ı mezi nejpouˇz´ıvanˇejˇs´ı : 1. MQTT

2. Modbus 3. BACnet 4. KNX 5. CANopen 6. Profinet 7. OPC UA

8. Dalˇs´ı m´enˇe rozˇs´ıˇren´e protkoly (DNP3, LonTalk, Ego-n, Synco living a Elko EP)

2.2.1 MQTT

MQTT, neboli MQ Telemetry Transport, je M2M (machine to machine) nebo IoT komunikaˇcn´ı protokol. Byl navrˇzen pro extrémnˇe nenároˇcné pˇrenáˇsen´ı zpráv a dat.

Jedná se o jednoduchý a nenároˇcný komunikaˇcn´ı protokol.

C´ıle protokolu

Hlavn´ım c´ılem protokolu je sn´ıˇzen´ı zat´ıˇzen´ı s´ıtˇe a omezen´ı poˇzadavk˚u na zdroje jed- notlivých zaˇr´ızen´ı, kdyˇz je potˇreba urˇcitá komunikace mezi jednotlivými zaˇr´ızen´ımi.

Navrˇzeno pro jednoduchá zaˇr´ızen´ı, s´ıtˇe s velkou latenc´ı (pingem), s´ıtˇe s úzkou ˇs´ıˇrkou komunikaˇcn´ıho pásma, nespolehlivá nebo poruchová zaˇr´ızen´ı i celé s´ıtˇe.

(19)

Jedná se tedy o protokol, jenˇz nezatˇeˇzuje s´ıt’ pˇri komunikaci. MQTT se snaˇz´ı zajiˇst’ovat urˇcitý stupeˇn spolehlivosti, který udává zajiˇstˇen´ı doruˇcen´ı zprávy mezi zaˇr´ızen´ımi v s´ıti.

Komunikace

MQTT protokol je zaloˇzen na principu publish/subscribe (zveˇrejnit/odeb´ırat). To znamená, ˇze s´ıt’ má vlastn´ı centrum a klienty. Centrum se nazývá MQTT Broker.

Klienti mohou být r˚uzné aplikace, senzory, webové sluˇzby nebo samotná zaˇr´ızen´ı v s´ıti, které data vytváˇr´ı nebo je pouze zpracovávaj´ı.

Funguje na principu, kdy kaˇzdý klient (napˇr´ıklad teplomˇer) produkuje data, které následnˇe publikuje do daného centra. Dané centrum následnˇe tyto data rozeˇsle vˇsem klient˚um, kteˇr´ı si o tento protokol zaˇzádali (subscribe). Data obsahuj´ı vlastn´ı název téma, nazývaný topic, podle kterého si klienti data objednávaj´ı, nebo Broker data rozes´ılá.

Protokol MQTT byl vyvinut jako nadstavba protokolu TCP/IP.

MQTT také podporuje urˇcitý stupeˇn zabezpeˇcen´ı komunikace. Od urˇcité verze lze do dat vloˇzit poˇzadavky na uˇzivatelské údaje. Lze do packet˚u hlaviˇcky vloˇzit jméno a heslo. Toto zabezpeˇcen´ı vyuˇz´ıvá ˇsifrovanou komunikaci.

Nevýhodou tohoto zabezpeˇcen´ı je výrazné zvýˇsen´ı zat´ıˇzen´ı s´ıtˇe, které se celý protokol snaˇz´ı co nejv´ıce sn´ıˇzit. Pokud tedy nen´ı ˇsifrován´ı nutné, vyuˇz´ıvá se.

Pouˇzit´ı

MQTT protokol se vyuˇz´ıvá a hod´ı se pro s´ıtˇe jak v energetice, tak i v domác´ım pouˇzit´ı. Dá se pouˇz´ıt vˇsude, kde jsou s´ıtˇe s obousmˇerným pˇrenosem dat, s´ıtˇe s

´

uzkou ˇs´ıˇrkou komunikaˇcn´ıho pásma, s´ıtˇe s bezdrátovými zaˇr´ızen´ımi.

Je výhodné v tom, ˇze nezatˇeˇzuje s´ıt’ a t´ım sniˇzuje poˇzadavky na zdroje zaˇr´ızen´ı, tak se velice hod´ı do s´ıt´ı, kde jsou pouˇzity bezdrátové zaˇr´ızen´ı. Hod´ı se do takových s´ıt´ı, protoˇze prodluˇzuje výdrˇz baterie oproti výdrˇzi pˇri pouˇzit´ı jiného komunikaˇcn´ıho protokolu. Dalˇs´ı výhodou je, ˇze nepotˇrebuje velkou ˇs´ıˇrku pásma, tud´ıˇz se m˚uˇze pouˇz´ıt i v pˇr´ıpadˇe, ˇze se v okol´ı vyskytuje nˇejaká dalˇs´ı komunikace nebo bezdrátový pˇrenos dat.

Nejrozˇs´ıˇrenˇejˇs´ı knihovnou pro MQTT je Mosquitto. Tato knihovna poskytuje veˇsker´e funkce protokolu.

(20)

2.2.2 Modbus

Protokol Modbus je otevˇrený komunikaˇcn´ı protokol, který umoˇzˇnuje vzájemnou komunikaci mezi r˚uznými zaˇr´ızen´ımi. Umoˇzˇnuje pˇrenáˇset data po r˚uzných typech s´ıt´ı i sbˇernic.

P˚uvodnˇe byl vyuˇz´ıván pouze jednou firmou pro pr˚umyslovou komunikaci, ale d´ıky jeho jednoduchosti se rozˇs´ıˇril mezi veˇrejnost a v dneˇsn´ı dobˇe je vyuˇz´ıván pomˇernˇe hojnˇe. Toto rozˇs´ıˇren´ı zp˚usobilo to, ˇze nen´ı standardizován ani objektovˇe orientovaný.

Kaˇzdá jeho aplikace m˚uˇze být jiná a samotný protokol neum´ı nic speciáln´ıho, ale jelikoˇz je otevˇrený, tak v kaˇzdá aplikaci prakticky m˚uˇze umˇet vˇse. Jeho výhodou je to, ˇze jsou definovány pouze vstupy a výstupy. Samotná struktura je pak na uˇzivateli.

V dneˇsn´ı dobˇe je zde pokus o standardizaci protokolu. Je zde nadstavba tohoto protokolu s myˇslenkou, ˇze kaˇzdé zaˇr´ızen´ı bude obsahovat bloky. Kaˇzdý blok, který bude m´ıt urˇcitá data o daném zaˇr´ızen´ı, bude na stejné adrese na vˇsech zaˇr´ızen´ıch.

Napˇr´ıklad ID zaˇr´ızen´ı bude na adrese 1 na vˇsech zaˇr´ızen´ıch. Pozor, tato adresa nen´ı stejná adresa celého zaˇr´ızen´ı. Tato adresa slouˇz´ı pouze k vnitˇrn´ı adresaci na dané bloky. Tento pokus by ˇreˇsil problém se sjednocen´ım protokolu mezi firmami, kteˇr´ı Modbus vyuˇz´ıvaj´ı.

Komunikace

Modbus je zaloˇzen na architektuˇre ”master-slave”. Na sbˇernici je jedno zaˇr´ızen´ı master a nˇekolik zaˇr´ızen´ı slave. Master pos´ılá dotazy a slave pouze odpov´ıdá. Master pos´ılá dotazy pouze na zaˇr´ızen´ı, od kterých ˇzádá odpovˇedi. Toho doc´ıl´ı adresován´ım, avˇsak adresován´ı se liˇs´ı v závislosti na pouˇzit´ı s´ıtˇe nebo sbˇernice. Pokud pouˇzijeme Ethernet, adresujeme pomoc´ı IP adres. Ale pokud pouˇzijeme sériové rozhran´ı, adresa je hexadecimáln´ı ˇc´ıslo 0 aˇz 255. Pˇri pouˇzit´ı sériové linky m˚uˇze Modbus pracovat v reˇzimu ASCII. T´ım se data i adresace pˇrevede do ASCII znak˚u.

Komunikace prob´ıhá stylem poˇzadavek - odpovˇed’. Master vyˇsle data s adresou zaˇr´ızen´ı, poˇzadavkem co má zaˇr´ızen´ı udˇelat a pˇr´ıpadnˇe daty. Adresu zpracuj´ı vˇsechny zaˇr´ızen´ı na sbˇernici, ale dalˇs´ı data pouze to zaˇr´ızen´ı, které má poˇzadovanou adresu.

Pokud m´ame Modbus s vnitˇrn´ımi bloky v zaˇr´ızen´ı o kter´ych jsem jiˇz mluvil, adresace bloku je vloˇzena mezi adresu zaˇr´ızen´ı a vlastn´ı poˇzadavek funkce.

Velikost packet˚u nen´ı pˇredem urˇcena a ˇcistˇe z´avis´ı na uˇzivateli, jak si velikost urˇc´ı v aplikaci.

Pouˇzit´ı

Modbus je vhodný pro pouˇzit´ı pˇredevˇs´ım u pr˚umyslových zaˇr´ızen´ı a systémech automatizace budov. Je vhodný pro pouˇzit´ı pˇri komunikaci mezi rozd´ılnými s´ıtˇemi

(21)

nebo sbˇernicemi, jelikoˇz tento protokol je otevˇren´y a m˚uˇze b´yt upraven na jakoukoli aplikaci.

Pˇri pouˇzit´ı tohoto protokolu je zde jedna velká nevýhoda, která m˚uˇze být obˇcas povaˇzována na výhodu. Je to právˇe to, ˇze samotný protokol nen´ı standardizován a jsou pˇredem definovány pouze vstupy a výstupy. Zda jsou digitáln´ı nebo analogové a zda se maj´ı chovat jako vstup, výstup nebo oboje. Toto je výhoda, kdyˇz potˇrebujeme specifickou aplikaci, ale je to také nevýhoda pˇri snaze o spojen´ı dvou aplikac´ı od dvou vývojáˇr˚u. Pˇri pouˇzit´ı vnitˇrn´ıch blok˚u zaˇr´ızen´ı tuto nevýhodu eliminujeme a je pomˇernˇe jednoduché a pˇrehledné sjednotit v´ıce aplikac´ı v jednu.

Tento protokol se tedy dá vyuˇz´ıt v jakékoli pr˚umyslové aplikaci. Jeho jediná nevýhoda spoˇc´ıvá ve snaze o pˇrenesen´ı kritických dat. Tyto data nem˚uˇze samotné slave zaˇr´ızen´ı

”vnutit”masteru. Kdyˇz uˇz se tato data dostanou na ˇradu ke komunikaci, mus´ı proj´ıt pˇres samotn´y master k zaˇr´ızen´ı ke kter´emu patˇr´ı.

Nejpouˇz´ıvanˇejˇs´ı knihovna tohoto protokolu je knihovna libmodbus. Jedná se o knihovnu pro jazyk C a podporuje jak pˇrij´ımán´ı, tak vys´ılán´ı data pˇres Ethernet nebo sériovou linku.

2.2.3 BACnet

Protokol BACnet slouˇz´ı k celosvˇetové normalizaci a standardizaci automatizace budov. Jedná se o snahu zaruˇcit univerzálnost a zamˇenitelnost jednotlivých prvk˚u tohoto protokolu. Snaha o zaruˇcen´ı funguj´ıc´ıho systému pˇri pouˇzit´ı zaˇr´ızen´ı od r˚uzných výrobc˚u. Výsledkem tohoto protokolu je tedy univerzáln´ı pˇredpis r˚uzných zaˇr´ızen´ı a funkc´ı.

BACnet byl navrˇzen pˇredevˇs´ım k vyuˇzit´ı k automatizaci a ˇr´ızen´ı budov. Byl navrˇzen pro komunikaci pomoc´ı internetov´eho pˇripojen´ı a zajiˇstˇen´ı pˇr´ıstupu pomoc´ı IP adres.

Komunikace

Kaˇzdé zaˇr´ızen´ı je reprezentováno jedn´ım ˇci v´ıce objekty. Tyto objekty jsou pak cha- rakterizovány vlastnostmi, které popisuj´ı jej´ıch chován´ı a ˇr´ıd´ı jejich provoz. Nˇekterá data v objektech mohou být pouze ke ˇcten´ı, nˇekteré zase umoˇznuj´ı zápis. BACnet definuje 23 r˚uzných standardn´ıch typ˚u objekt˚u, do kterých si pak jednotlivá zaˇr´ızen´ı m˚uˇzeme pˇriˇradit.

Kaˇzd´e zaˇr´ızen´ı m˚uˇze komunikovat s kaˇzd´ym dalˇs´ım objektem, nebo zaˇr´ızen´ım v s´ıti.

Nen´ı zde ˇzádný centráln´ı prvek s´ıtˇe. Architektura systému je tedy s´ıt’ová uˇz jen z principu, ˇze protokol m˚uˇze vyuˇz´ıvat j´ıˇz vybudovaných internetových s´ıt´ı.

Protokol vyuˇz´ıvá nejen stávaj´ıc´ı internetové s´ıtˇe, ale vyuˇz´ıvá i adresaci pomoc´ı IP adres. Pˇri pˇripojen´ı systému do internetu pˇres IP router, m˚uˇzeme vyuˇz´ıt takzvaný

(22)

”IP tunneling”a projit pˇres internet 2 s´ıtˇe mezi sebou. Tyto s´ıtˇe se pak chovaj´ı jako jedna a m˚uˇzeme propojit v´ıce budov mezi sebou.

BACnet m˚uˇze vyuˇz´ıvat i komunikaci pˇres sériovou sbˇernici, ale to se nepouˇz´ıvá, jelikoˇz je zbyteˇcnˇe sloˇzitá adresace a nav´ıc nelze vyuˇz´ıvat výhod TCP/IP protokolu a nelze systém pˇripojit to internetu. Ztrat´ıme tedy moˇznost kontrolovat systém zvenˇc´ı.

Celkovˇe je mnohem lepˇs´ı vyuˇz´ıt Ethernet, protoˇze v dneˇsn´ı dobˇe se Ethernetová s´ıt nacház´ı témˇeˇr v kaˇzdé budovˇe.

Pouˇzit´ı

BACnet je v dneˇsn´ı dobˇe jeden z nejpouˇz´ıvanˇejˇs´ıch protokol˚u pro automatizaci budov. Je tomu tak jelikoˇz je normován a jeho nasazen´ı je pomˇernˇe jednoduché, je- likoˇz vyuˇz´ıvá jiˇz existuj´ıc´ıch internetových s´ıt´ı. Umoˇzˇnuje provozovat komunikaci souˇcasnˇe i s jinými stávaj´ıc´ımi s´ıtˇemi.

Pˇri pouˇzit´ı pro automatizaci budov, na kterou je primárnˇe zamˇeˇren, je pouˇzit´ı IP komunikace Ethernet velmi vhodná. Pˇri takovémto pouˇzit´ı m˚uˇzeme jednak realizovat komunikaci v´ıce budov mezi sebou, ale m˚uˇzeme i kontrolovat a ˇr´ıdit budovy nebo celé systémy z jakéholiv pˇr´ıstupu na internet a to je v dneˇsn´ı dobˇe jedno kritéri´ı pˇri výbˇeru.

BACnet d´ıky své rychlosti a moˇznosti komunikace ”kaˇzdý s kaˇzdým”je vhodný pro pouˇzit´ı do budov, kde chceme detekovat a hlásit poˇzár, ˇr´ıdit osvˇetlen´ı, topen´ı, ven- tilaci, zabezpeˇcen´ı a hl´ıdán´ı budov, automatizovat chod budovy.

Pro tento protokol se pouˇz´ıv´a BACnet Stack. Tato knihovna je pro jazyk C, ale podporuje mnoho dalˇs´ıch jazyk˚u a kompil´ator˚u.

2.2.4 M-BUS

M-BUS je evropský standard, který byl p˚uvodnˇe urˇcený pˇredevˇs´ım pro vzdálené mˇeˇren´ı spotˇreby. Postupnˇe se rozˇs´ıˇril a v dneˇsn´ı dobˇe se pouˇz´ıvá pro vzdálené mˇeˇren´ı dat a regulaci systém˚u. Pˇri odeˇc´ıtán´ı tˇechto hodnot nezáleˇz´ı na rychlosti pˇrenosu dat, ale hodnˇe záleˇz´ı na pˇresnosti tˇechto dat. Takˇze tento protokol neklade d˚uraz na rychlost, ale d˚uraz na kvalitu pˇrenosu a zabezpeˇcen´ı proti ruˇsen´ı.

V dneˇsn´ı dobˇe je tento standard vyuˇz´ıván mnoha výrobci, tud´ıˇz podporuje moˇznost vzájemné komunikace zaˇr´ızen´ı r˚uzných výrobc˚u.

M-BUS podporuje a zajiˇst’uje spolehlivé propojen´ı mnoha zaˇr´ızen´ı aˇz na vzdálenosti nˇekolika kilometr˚u. Poˇcet pˇripojen´ı zaˇr´ızen´ı na tyto vzdálenosti se udává ˇrádovˇe ve stovkách.

(23)

Pokud chceme pouˇz´ıt bezdrátovou komunikaci, M-BUS poskytuje vlastn´ı ˇreˇsen´ı tohoto problému. M-BUS vyv´ıj´ı vlastn´ı komunikaˇcn´ı standard pro bezdrátovou komunikaci M-BUS Wireless. Tento standard zat´ım nen´ı pˇr´ıliˇs rozˇs´ıˇren a prob´ıhá prozat´ım vývoj.

Komunikace

Struktura s´ıtˇe je sbˇernicového typu, protoˇze je to pro pr˚umyslový sbˇer dat to nej- efektivnˇejˇs´ı ˇreˇsen´ı. Vyuˇzit´ım této sbˇernice z´ıskáme jednoduché pˇripojován´ı a odpo- jován´ı zaˇr´ızen´ı bez jakéhokoli naruˇsen´ı komunikace mezi zbytkem zaˇr´ızen´ı. Z´ıskáme moˇznost jednoduˇse vys´ılat data v´ıce zaˇr´ızen´ım najednou, ale je zde problém, ˇze pokud vys´ılá jedno zaˇr´ızen´ı, nem˚uˇze komunikovat dalˇs´ı. To má za následek sn´ıˇzen´ı rychlosti systému, ale na rychlost M-BUS nehled´ı. Vzdálenost mezi jednotlivými zaˇr´ızen´ımi mus´ı být maximálnˇe 1km. Samotná komunikace prob´ıhá zp˚usobem Master- slave. Komunikace mezi zaˇr´ızen´ımi se provád´ı binárnˇe. Prob´ıhá zde sériová 8bitová asynchronn´ı komunikace. Adresy stanic jsou primárnˇe jednobytové. Je zde vˇsak moˇznost, pˇri vyˇsˇs´ım poˇctu zaˇr´ızen´ı, pouˇz´ıt 8bytovou adresaci.

Samotná tato sbˇernice je pomˇernˇe atypická. Vyuˇz´ıvá dvoudrátové spojen´ı. Je aty- pická t´ım, ˇze master vys´ılá data pomoc´ı dvou hodnot napˇet´ı – 36 a 24 volt˚u. Pˇri komunikaci k jednotlivým zaˇr´ızen´ım od Masteru znamená 36 volt˚u logickou 1 a 24 volt˚u logickou 0. T´ımto zp˚usobem je moˇznost i napájen´ı zaˇr´ızen´ı ze sbˇernice.

Pˇri opaˇcné komunikaci, tedy slave zaˇr´ızen´ı odpov´ıdaj´ı na master dotazy, se neprovád´ı zmˇena napˇet´ı, ale zmˇena proudu. Slave zaˇr´ızen´ı odeb´ırá 1,5mA pˇri logické 1 a pˇri logické 0 je tato hodnota o 11 aˇz 20mA vyˇsˇs´ı.

Pouˇzit´ı

Pˇri pouˇzit´ı této sbˇernice nedocház´ı k naruˇsen´ı ostatn´ıch komunikac´ı, jelikoˇz ne- vyuˇz´ıvá stávaj´ıc´ıch s´ıt´ı, ale je potˇreba vytvoˇrit dvoudrátovou sbˇernici. Tato sbˇernice je urˇcena výhradnˇe pro pˇrenos dat z mˇeˇr´ıc´ıch zaˇr´ızen´ı do centráln´ıho zaˇr´ızen´ı, které pak provede zásah do systému.

Vzhledem k pˇrenosovým rychlostem nen´ı sbˇernice M-BUS vhodná pro systém, kde je potˇreba rychlého pˇrenosu kritických zaˇr´ızen´ı. Nen´ı tedy vhodná na zabezpeˇcen´ı budov nebo pˇr´ımo do energetiky, do automatického chodu budovy (napˇr´ıklad rozvoden).

Je vˇsak vhodná pro mˇeˇren´ı hodnot a d´ıky zajiˇstˇen´ı bezpeˇcnosti doruˇcen´ı dat a odol- nosti v˚uˇci ruˇsen´ı, by se tato sbˇernice mohla pouˇz´ıvat v energetice pouze pro mˇeˇren´ı spotˇreby jednotlivých zaˇr´ızen´ı. Dále by mohl být urˇcen pro mˇeˇren´ı dat v budovˇe a následnou regulaci veliˇcin. M-BUS je v podstatˇe univerzáln´ı ˇreˇsen´ı pomalého re- gulován´ı veliˇcin na velké vzdálenosti s urˇcitou m´ırou zabezpeˇcen´ı. Pro regulován´ı napˇr´ıklad teploty v budovˇe je v´ıce neˇz dostaˇcuj´ıc´ı.

(24)

Knihovna libmbus slouˇz´ı ke ˇcten´ı dat z mˇeˇr´ıc´ıch pˇr´ıstroj˚u, podm´ınkou je podpora tohoto protokolu. Knihovna m˚uˇze ˇc´ıst data po RS232 nebo Ethernetu.

2.2.5 KNX

Pˇri vytváˇren´ı sbˇernice KNX, neboli Konnex Bus, byla jako základ pouˇzita sbˇernice EIB. D˚uvodem tohoto vyuˇzit´ı byl komerˇcn´ı úspˇech EIB. Jelikoˇz EIB je základ pro KNX, tak vˇsechny pˇr´ıstroje, které vyhovuj´ı EIB, automaticky vyhovuj´ı i KNX. KNX má oproti EIB mnohem v´ıce funkc´ı, nab´ız´ı moˇznost pˇripojen´ı v´ıce zaˇr´ızen´ı a také podporuje vyuˇzit´ı r˚uzných pˇrenosových médi´ı. KNX je prakticky rozˇs´ıˇren´ı EIB. D´ıky tomuto propojen´ı EIB prakticky zanikla a ˇcasto v literatuˇre KNX objevuje pod názvem KNX/EIB.

Stejnˇe jako pˇredeˇslé sbˇernice i tato sbˇernice podporuje komunikaci mezi mnoha pˇr´ıstroji od r˚uzných výrobc˚u. Také podporuje napájen´ı zaˇr´ızen´ı ze sbˇernice.

Komunikace

Topologie je k pˇrekvapen´ı libovolná, pouze s jedn´ım omezen´ım, ˇze na sbˇernici nesm´ı být uzavˇrená smyˇcka. M˚uˇzeme tedy pouˇz´ıt témˇeˇr veˇskeré topologie, aˇz na kruhovou a s´ıt’ovou.

Typická sbˇernice je stromová, která napodobuje samotou budovu. Jedna takzvaná linie (pˇredstavme si jako m´ıstnost) m˚uˇze obsahovat aˇz 256 zaˇr´ızen´ı. Takových lini´ı m˚uˇze být na hlavn´ı linii (patro budovy) pˇripojeno aˇz 15. Ty jsou následnˇe pˇripojeny na páteˇrn´ı linii, kterou si uˇz m˚uˇzeme pˇredstavit jako celou budovu, a zde je moˇznost zase pˇripojen´ı 15 hlavn´ıch linii. Pokud mezi sebou tyto ˇc´ısla vynásob´ıme, z´ıskáme poˇcet kolik je moˇzných zaˇr´ızen´ı na jedné sbˇernici, dostaneme aˇz 57600 jednotlivých zaˇr´ızen´ı. Je zde vˇsak dalˇs´ı omezen´ı - jeden napájec´ı zdroj m˚uˇze napájet pouze 64 zaˇr´ızen´ı.

Poloha zaˇr´ızen´ı v s´ıti je definována individuáln´ı adresou. Tato adresa je sloˇzena ze tˇr´ı ˇcást´ı, které jsou mezi sebou oddˇeleny teˇckami. Prvn´ı ˇcást obsahuje ˇc´ıslo 0 aˇz 15 a udává oblast (pˇredstavili jsme si patro), pˇriˇcemˇz 0 je vyhrazeno pro samotnou páteˇrn´ı linii. Dalˇs´ı ˇcást obsahuje opˇet 0 aˇz 15 a urˇcuje samotnou linii (m´ıstnost).

Zde je 0 vyhrazena pro hlavn´ı linii. Posledn´ı ˇcást adresy urˇcuje poˇrad´ı zaˇr´ızen´ı na dané linii a m˚uˇze nabývat hodnot 0 aˇz 255. Tato individuáln´ı adresa má vyhrazeno 16 bit˚u. KNX umoˇzˇnuje i vytváˇren´ı skupin pro jednoduˇsˇs´ı komunikaci a ovládán´ı nˇekolik zaˇr´ızen´ı najednou.

Samotná komunikace prob´ıhá binárnˇe a po sbˇernici jsou pˇrenáˇseny takzvané datové telegramy. Pro pˇrenos dat m˚uˇze být vyuˇzita kroucená dvojlinka, optické veden´ı nebo silové veden´ı. Nejˇcastˇeji se pouˇz´ıvá kroucená dvojlinka. Samotný signál je brán jako rozd´ıl napˇet´ı mezi kladným a záporným vodiˇcem. Logická 0 je vyjádˇrena pulsem o velikosti -5V na kaˇzdý vodiˇc, tud´ıˇz napˇet´ı mezi vodiˇci je rovno 14V. Logická 1 je

(25)

vyjádˇrena jako nulový puls, tedy napˇet’ový rozd´ıl je 24V. ˇCasová jednotka tˇechto pulz˚u je také normalizovaná.

Pouˇzit´ı

Jelikoˇz KNX sbˇernice m˚uˇze vyuˇz´ıvat obrovský poˇcet jednotlivých zaˇr´ızen´ı, je vhodná pro pr˚umyslové výrobn´ı haly, tomuto nasvˇedˇcuje i vzdálenost mezi jednotlivými zaˇr´ızen´ımi, která se udává na 700metr˚u. M˚uˇze dosahovat i vyˇsˇs´ıch pˇrenosových rychlost´ı, záleˇz´ı pouze na pouˇzitém médiu. Hod´ı se tedy i do zabezpeˇcován´ı chodu budov a celkové automatizaci budov. D´ıky své rychlosti a bezpeˇcné komunikaci m˚uˇze být pouˇzit i do protipoˇzárn´ıch systém˚u. D´ıky svým vlastnostem se hod´ı také napˇr´ıklad pro mˇeˇren´ı regulace, detekci poˇzáru, plnou automatizaci budov a výrobn´ı pr˚umyslové haly.

Pro KNX protokol se najˇcastˇeji vyuˇz´ıv´a funkc´ı knihovny xknx. Tato knihovna slouˇz´ı pro jazyk Python. Knihovna poskytuje funkce pro komunikaci mezi dvˇema zaˇr´ızen´ımi.

Pokud by se pouˇzil jako pˇrenosové médium optický kabel, mysl´ım si, ˇze ani tak by se tato sbˇernice nemohla pouˇz´ıt v energetice. Vzhledem k tomu, ˇze nejrychlejˇs´ı pˇrenos se udává jako 32kbps, nemysl´ım si, ˇze by tato rychlost byla dostaˇcuj´ıc´ı pro pˇrenos kritické informace. Vycház´ım z toho, ˇze pouze adresa zab´ırá 16 bit˚u.

2.2.6 CANopen

CANopen je standardizovaný komunikaˇcn´ı protokol, který je nadstavba pro sbˇernici CAN. Tento protokol byl navrˇzen pro tuto sbˇernici s t´ım, ˇze má za úkol zjed- noduˇsovat návrh ˇr´ıdic´ıho systému. Byl navrˇzen pro rychlý pˇrenos dat po sériové sbˇernici s d˚urazem na rychlost a zaruˇcen´ı pˇrenesen´ı kritických dat. C´ılem tohoto protokolu bylo výraznˇe zjednoduˇsit návrh systému a vyhnout se problematice spo- jené se sbˇernic´ı CAN, z tohoto d˚uvodu tento protokol funguje pouze na této sbˇernici.

Hlavn´ım z tˇechto problém˚u bylo správné ˇcasován´ı zpráv, CANopen tento problém eliminuje standardizac´ı komunikaˇcn´ıch objekt˚u a zaveden´ım speciáln´ıch funkc´ı (napˇr´ıklad synchronizace).

Komunikace

Komunikace protokolu CANopen spoˇc´ıvá na principu master-slave. Princip komunikace je vˇsak vylepˇsen dvˇema typy pˇrenosu dat. Pˇrenos procesn´ıch dat a pˇrenos sluˇzebn´ıch dat. Kaˇzdý tento pˇrenos funguje troˇsku odliˇsnˇe. Zat´ımco pˇrenos procesn´ıch dat funguje jako producent a konzument, pˇrenos sluˇzebn´ıch dat pracuje podle modelu klient a server. Pˇri pˇrenosu procesn´ıch dat docház´ı k pˇrenosu kri- tických dat a tento pˇrenos m˚uˇze kaˇzdé zaˇr´ızen´ı vyslat bez poˇzadavku na tyto data.

To znamená, ˇze producent m˚uˇze být napˇr´ıklad nˇejaký senzor a vyslat data, která nejsou vyˇzádaná, ale jsou kritická a následnˇe je konzument pˇrijme a vyhodnot´ı.

(26)

Pˇri pˇrenosu tˇechto kritických dat, je pˇrijme pouze ten konzument, kterému data náleˇz´ı. Tento pˇrenos dat nevyuˇz´ıvá potvrzen´ı a tyto data jsou vys´ılány cyklicky do- kud nedojde ke zmˇenˇe v systému, která zmˇen´ı proces, který zp˚usobil jejich vys´ılán´ı.

Pˇri pˇrenosu sluˇzebn´ıch dat je zde typick´y pˇrenos stylem, ˇze server vyˇsle dotaz na data a klient mu je poskytne. Klient s´am od sebe data na sbˇernici neposkytuje.

Tento pˇrenos uˇz nen´ı cyklick´y a klient pˇrestane vys´ılat data po pˇrijet´ı potvrzen´ı od serveru.

Data jsou vys´ılány v objektech. Samotné objekty obsahuj´ı adresu, typ objektu, data a parametr, zda je povoleno data mˇenit nebo pouze ˇc´ıst. Adresován´ı v tomto protokolu je pomˇernˇe jednoduché. Kaˇzdé zaˇr´ızen´ı na sbˇernici má vlastn´ı ID a vˇsechny zaˇr´ızen´ı, které potˇrebuj´ı toto ID znát, ho maj´ı uloˇzené. Pˇri komunikaci pak zaˇr´ızen´ı ˇcistˇe zap´ıˇse do objektu ID zaˇr´ızen´ı, komu data náleˇz´ı. Pˇri pˇrenosu kritických dat je zde pouze ID a data.

Pouˇzit´ı

Hlavn´ı výhodou pˇri pouˇzit´ı tohoto protokolu je rychlý pˇrenos kritických dat. CA- Nopen se dá pouˇz´ıt pouze ve spojen´ı se sbˇernici CAN. Pˇri pouˇzit´ı toho spojen´ı z´ıskáme odolný systém, který zaruˇcuje rychlost a urˇcitý stupeˇn zaruˇcen´ı doruˇcen´ı dat. Jeho nevýhodou je jeho jednoduchost. Kaˇzdý, kdo tomuto protokolu rozum´ı, m˚uˇze velmi snadno data ˇc´ıst. Z toho vyplývá, ˇze protokol nen´ı moc bezpeˇcný a jeho pouˇzit´ı se nedoporuˇcuje do s´ıt´ı, kde je urˇcité bezpeˇcnostn´ı riziko. Hod´ı se tedy do výrobn´ıch pr˚umyslových hal, kde je potˇreba rychle data pˇrenáˇset, ale nezaleˇz´ı na stupni zabezpeˇcen´ı.

Kvaser CANopen stack je knihovna poskytuj´ıc´ı funkce pro master i slave zaˇr´ızen´ı.

Pouˇzit´ı t´eto knihovny je nejrozˇs´ıˇrenˇejˇs´ı. Poskytuje funkce pro komunikaci tˇechto zaˇr´ızen´ı v s´ıti.

2.2.7 Profinet

Profinet je pr˚umyslová sbˇernice, která byla navrˇzena jako nadstavba TCP/IP. Jej´ı hlavn´ı zamˇeˇren´ı je v oblasti ˇr´ıdic´ıch systém˚u v pr˚umyslové automatizaci. Tento protokol je otevˇrený a podléhá urˇcité standardizaci. Patˇr´ı mezi jeden z nejrozˇs´ıˇrenˇejˇs´ıch protokol˚u v pr˚umyslové automatizaci, který je zaloˇzený na TCP/IP. Profinet umoˇzˇnuje vyuˇzit´ı jiˇz existuj´ıc´ıch internetových tras bez jakéhokoli jejich naruˇsen´ı. D´ıky tomuto se hojnˇe rozˇsiˇruje, protoˇze t´ımto krokem razantnˇe sniˇzuje poˇrizovac´ı cenu.

D´ıky základ˚um v protokolu TCP/IP m˚uˇze být jako pˇrenosové médium pouˇzit i bezdrátový pˇrenos pˇres Wi-Fi nebo optický Ethernet. Jedná se prakticky o rozˇs´ıˇren´ı výhod protokolu TCP/IP do pr˚umyslové automatizace.

(27)

Komunikace

Topologie tohoto protokolu nen´ı pˇredem stanovená, uˇzivatel si m˚uˇze vytvoˇrit ja- koukoliv s´ıt’, stejnˇe jak tomu je u internetu. Jak bylo jednou zm´ınˇeno, lze pouˇz´ıt uˇz stávaj´ıc´ı s´ıt’ a podle potˇreby ji tˇreba rozˇs´ıˇrit. Profinet dokáˇze rozliˇsovat 3 typy komunikace. Prvn´ı je pro pˇrenos standartn´ıch informac´ı, u kterých nen´ı d˚uleˇzitý ˇcas doruˇcen´ı, a Profinet se chová jako TCP/IP. Druhý je komunikace v reálném ˇcase (RT), tento typ je urˇcen pro ˇcasovˇe závislé kritické informace.

Pro tento typ komunikace slouˇz´ı vlastn´ı komunikaˇcn´ı kanál. Tento kanál je ˇcást standartn´ıho komunikaˇcn´ı kanálu. Zaˇr´ızen´ı se schopnost´ı této komunikace maj´ı sn´ıˇzené nároky na procesor, jedná se vˇetˇsinou o sn´ımaˇce nebo ˇcidla. Tˇret´ı typ je komunikace v Izochronn´ım reálném ˇcase (IRT). Tento typ je urˇcen pro aplikace, kde je potˇreba velmi malé odezvy a pˇresnou synchronizaci. Toto je doc´ıleno t´ım, ˇze IRT má vlastn´ı uzavˇrený komunikaˇcn´ı kanál. T´ımto stylem m˚uˇze být standardn´ı komunikace, která obsahuje RT, existovat zároveˇn s IRT komunikac´ı. Tyto dva komunikaˇcn´ı kanály pracuj´ı nezávisle na sobˇe. At’ se pouˇzije jakákoliv komunikace, pˇrenos dat prob´ıhá stejnˇe jako u TCP/IP ve tvaru HTML nebo XML. Adresace je provádˇena pomoc´ı IP adres zaˇr´ızen´ı, pˇri nutnosti vˇsak lze vyuˇz´ıt MAC adres.

Pouˇzit´ı

Pouˇzit´ı protokolu Profinet se nab´ız´ı jako nejlepˇs´ıˇreˇsen´ı tam, kde jiˇz existuje vybudo- vaná komunikaˇcn´ı s´ıt’. Toto se vyuˇz´ıvá ve velkém rozsahu, jelikoˇz t´ımto zp˚usobem lze uˇsetˇrit velký obnos penˇez, který by byl vynaloˇzen na vybudován´ı komunikaˇcn´ı s´ıtˇe.

Nav´ıc d´ıky pouˇzit´ı st´avaj´ıc´ıho Ethernetu lze pˇristupovat i pˇres webov´e rozhran´ı.

D´ıky tomuto pˇr´ıstupu lze dohl´ıˇzet na chod a zároveˇn upravovat, nebo servisovat, systém v reálném ˇcase z jakéhokoli m´ısta s pˇr´ıstupem k webu. D´ıky tˇemto vlastnostem se hod´ı Profinet do velkých výrobn´ıch hal, kde je potˇreba urˇcitá data pˇrenáˇset velmi rychle a s velmi malou odezvou (menˇs´ı neˇz 1ms). Dále se tento protokol hod´ı do výrobn´ıch hal, kde je potˇreba urˇcitý stupeˇn utajen´ı dat, ale s moˇznost´ı kontroly dat z m´ısta mimo halu.

Pro tento komunikaˇcn´ı protokol jsem nenalezl ˇz´adnou opec source knihovnu. Exis- tuje pouze knihovna od firmy Siemens, kter´a podporuje ˇcten´ı dat pomoc´ı tohoto protokolu.

2.2.8 OPC UA

OPC UA je nová verze komunikaˇcn´ıho protokolu pro pr˚umyslovou automatizaci OPC. Na rozd´ıl od OPC tento protokol nen´ı funkˇcn´ı pouze pro operaˇcn´ı systém Windows, ale je zaloˇzen na jiˇz funguj´ıc´ıch komunikaˇcn´ıch protokolech TCP/IP a HTTP a jedná se o jejich nadstavbu. T´ım je zaruˇceno, ˇze protokol OPC UA m˚uˇze fungovat na jakémkoli zaˇr´ızen´ı, které nemus´ı obsahovat OS Windows a m˚uˇze být

(28)

zabudováno napˇr´ıklad do PLC automat˚u. Na rozd´ıl od OPC, které definuje pˇrenos kaˇzdého typu dat zvláˇst’, nové OPC UA definuje pouze formát pˇrenosu dat a neˇreˇs´ı, o jaké data se jedná.

Komunikace

OPC UA podporuje dvoj´ı typ komunikace. Prvn´ı podporuje bin´arn´ı komunikaci pomoc´ı TCP/IP protokolu a druh´a je pˇres web sluˇzby pomoc´ı HTTP protokolu.

Pˇrenos samotných dat prob´ıhá ve formˇe pˇrenosu takzvaných zpráv mezi klienty a serverem. Jako s´ıt’ m˚uˇze být pouˇzit jiˇz stávaj´ıc´ı Ethernet nebo Wi-Fi s´ıt’. Kaˇzdé zaˇr´ızen´ı v s´ıti má vlastn´ı tˇr´ıdu, kterou je definováno. Tato tˇr´ıda obsahuje jméno zaˇr´ızen´ı, pouˇzit´ı, datový typ a popis. Ve jménˇe je jméno samotného zaˇr´ızen´ı. V pouˇzit´ı je zapsáno, zda má zaˇr´ızen´ı nˇejaká omezen´ı. Popis definuje charakteristiku zaˇr´ızen´ı nebo samotného pouˇzit´ı tohoto zaˇr´ızen´ı. K adresován´ı je pouˇzito jméno zaˇr´ızen´ı. Pˇr´ıstup k dat˚um je pomoc´ı objekt˚u.

Server vyˇsle poˇzadavek, který obsahuje jméno zaˇr´ızen´ı, id objektu, metodu a zda chce ˇc´ıst nebo zapisovat. Pˇres jméno zaˇr´ızen´ı se dostane k nˇekolika blok˚um. Pomoc´ı ID bloku vybere samotný blok, který obsahuje urˇcitá data. Do bloku vyˇsle poˇzadavek, zda chce data ˇc´ıst nebo jen zapisovat a metoda urˇcuje, co se s daty bude d´ıt. Kaˇzdé zaˇr´ızen´ı v s´ıti mus´ı m´ıt ke komunikaci aplikaˇcn´ı certifikát, pomoc´ı kterého se provád´ı zabezpeˇcen´ı systému. OPC AU definuje 4 úrovnˇe zabezpeˇcen´ı dat komunikace – bez autentizace, serverová autentizace, klientská autentizace a oboustranná autentizace.

Bez autentizace znamená, ˇze vˇsechny certifikáty jsou povaˇzovány za d˚uvˇeryhodné a pokud jakékoli zaˇr´ızen´ı obsahuje certifikát, m˚uˇze být pˇripojeno do systému a komunikovat. Serverová autentizace spoˇc´ıvá v tom, ˇze server se pˇripoj´ı k jakémukoli klientu a ovˇeˇren´ı klienta probˇehne pˇres jméno a heslo. Klientská autentizace dovoluje klientovi se pˇripojit na jakýkoliv server, ale pouze pomoc´ı administrátorských dat.

Oboustranná znamená, ˇze klient i server se m˚uˇze pˇripojit pouze pokud obsahuje d˚uvˇeryhodný certifikát.

Pouˇzit´ı

Vzhledem k tomu, ˇze protokol UPC UA vyuˇz´ıvá pˇrenosu dat pomoc´ı vyuˇzit´ı inter- netových protokol˚u, je pˇrenos dat pomˇernˇe jednoduchý. To je zp˚usobeno t´ım, ˇze v dneˇsn´ı dobˇe je internetová s´ıt’ souˇcást´ı témˇeˇr kaˇzdé pr˚umyslové budovy. UPC UA je tedy jednoduché implementovat do jakékoli budovy. V nejvˇetˇs´ı m´ıˇre se pouˇz´ıvá pro systémy ˇcásteˇcné automatizace. Pro systémy, které kontroluj´ı energie v budovˇe, ˇr´ızen´ı teplot, ale také hlavnˇe u systém˚u, které potˇrebuj´ı rychlý pˇrenos kritických dat a u systém˚u, které potˇrebuj´ı ke svému chodu urˇcitý pojem o ˇcase (napˇr´ıklad poˇc´ıtán´ı cykl˚u, nebo urˇcit ˇcas, kdy se jaká událost stala).

Pro uˇzivatelsk´e pouˇzit´ı tohoto protokolu se nejˇcastˇeji vyuˇz´ıv´a knihovna OuickOPC.

Tato knihovna poskytuje funkce clienta. Je moˇzn´e ji implementovat do mnoha programovac´ıch jakzyk˚u (napˇr´ıklad C, C++, C#, Python a dalˇs´ı).

(29)

2.2.9 Dalˇ s´ı m´ enˇ e rozˇ s´ıˇ ren´ e protokoly

DNP3

Jedná se komunikaˇcn´ı protokol, který se vyuˇz´ıvá výhradnˇe v Americe. Je pouˇz´ıván jako protokol ke komunikaci mezi dvˇema zaˇr´ızen´ımi v pr˚umyslové automatizaci.

Jedná se o pomˇernˇe dobˇre zabezpeˇcenou komunikaci, která zaruˇcuje urˇcitý stupeˇn doruˇcen´ı zprávy. Protokol podporuje i zabezpeˇcen´ı proti odposloucháván´ı dat. Tento protokol se v Evropských zem´ı témˇeˇr nevyuˇz´ıvá.

LonTalk

LonTalk je komunikaˇcn´ı protokol, kter´y se pouˇz´ıv´a pro pˇrenos dat po sbˇernici LON.

Tento protokol vyuˇz´ıvá pˇrenos dat ve zprávách a pˇrenos je realizován po sbˇernici, která podporuje velké mnoˇzstv´ı pˇrenosových médi´ı. Tento protokol vyuˇz´ıvaj´ı pouze 3 svˇetové firmy (Echelon, Motorola a Toshiba).

Ego-n

Ego-n je komunikaˇcn´ı protokol pro inteligentn´ı elektroinstalaci. Pouˇz´ıvá se jak pro pr˚umyslové, tak pro domác´ı vyuˇzit´ı. Pˇrenos dat je opˇet pˇres sbˇernici a je zde jeden modul, který ˇr´ıd´ı celý systém. Tento protokol je vyuˇzit pouze firmou ABB.

Synco living

Synco living je systém inteligentn´ıch komunikaˇcn´ı prvk˚u, které dohromady tvoˇr´ı inteligentn´ı domácnosti a budovy. Jedná se o plnou automatizaci. Tento systém vycház´ı ze sbˇernice KNX. Pouze tuto sbˇernici vylepˇsuje, ale funguje témˇeˇr stejnˇe.

Tento syst´em vyuˇz´ıv´a a nab´ız´ı pouze firma Siemens.

Elko EP

Elko EP je ˇcesk´a obdoba syst´emu Synco living. Tento produkt nab´ız´ı firma Elko EP.

Oproti Synco living podporuje ELKO EP automatizacepro nepr˚umyslov´e pouˇzit´ı.

Podporuje pouze automatizaci mal´ych dom˚u, maxim´alnˇe hotel˚u.

(30)

3 V´ ybˇ er protokol˚ u

Po hotové reˇserˇsi protokol˚u pˇriˇslo na ˇradu vybrat z tˇechto protokol˚u tˇri aˇz ˇctyˇri pro ukázku jejich funkc´ı. Pˇri vyb´ırán´ı protokol˚u jsem vzal v potaz nejpouˇz´ıvanˇejˇs´ı knihovny, které jsem zmiˇnoval v reˇserˇsi. Pokud vˇsak knihovna nebyla veˇrejnˇe pˇr´ıstupná, hledal jsem jinou. Jako programovac´ı jazyk jsem si, v závislosti na konzultaci s vedouc´ım práce, zvolil C#. Pokud tedy nejpouˇz´ıvanˇejˇs´ı knihovna daného protokolu nebyla .Net hledal jsem .Net knihovnu pro daný protokol. Pˇri hledán´ı .Net knihoven jsem hledal knihovny nedávno a ˇcasto aktualizované. To bylo jedno z hlavn´ım kritéri´ı pro výbˇer knihovny. Knihovny, které pro pˇrenos dat vyˇzaduj´ı sbˇernici, jsem z výbˇeru odebral. Dále bylo potˇreba, aby daný protokol mˇel knihovny jak pro server, tak pro clienta, pˇr´ıpadnˇe pro oboj´ı v jedné.

Poté, kdyˇz uˇz bylo nalezeno nˇekolik knihoven pro jednotlivé protokoly, pˇriˇslo na ˇradu vybrat, pro jaké se budou programovat aplikace. Po konzultaci s vedouc´ım jsme vybrali ˇctyˇri protokoly, které maj´ı odliˇsný zp˚usob pˇrenosu dat. Bylo by zbyteˇcné pouˇz´ıt dva sobˇe velice podobné protokoly, jejichˇz pˇrenos dat je témˇeˇr totoˇzný.

Pro tuto pr´aci tedy byla vybr´ana tato ˇctveˇrice protokol˚u:

• DLMS/COSEM

• IEC 60870-5-104

• MQTT

• OPC UA

Pro kaˇzd´y z protokol˚u jsem si pro jednoduˇs´ı implementaci knihoven zvolil pouze knihovny podporuj´ıc´ı funkce pro obˇe zaˇr´ızen´ı v s´ıti.

Pro MQTT jsem nepouˇzil knihovnu z reˇserˇse (viz strana19), protoˇze tato knihovna byla pouze pro vývojové prostˇred´ı Eclipse. Pro DLMS jsem knihovnu z reˇserˇse vyuˇzil, jelikoˇz obsahovala ˇcást .Net. Pro IEC 60870-5-104 jsem vyuˇzil knihovnu z reˇserˇse.

Pro OPC UA jsem knihovnu z reˇserˇse nevyuˇzil, jelikoˇz obsahovala funkce pouze pro clienta.

(31)

4 Jednotliv´ e aplikace

Pro programován´ı jednotlivých aplikac´ı jsem si zvolil vývojové prostˇred´ı Microsoft Visual Studio. Toto prostˇred´ı jsem si zvolil, protoˇze se v tomto prostˇred´ı pohybuji jiˇz od základn´ı ˇskoly. Na vysoké ˇskole jsme v nˇem programovali a také nám ho zdarma poskytuje ˇskola ke studijn´ım úˇcel˚um.

4.1 MQTT

Jako prvn´ı protokol pro uk´azku aplikace jsem zvolil MQTT. Pro tento protokol existuje velk´e mnoˇzstv´ı knihoven, obsahuj´ıc´ıch funkce pouze pro clienta nebo server.

Knihovny MQTTnet [52] a M2Mqtt [54], kter´e obsahuj´ı funkce pro clienta i server, jsem vyzkouˇsel. M2Mqtt nemohla naj´ıt cestu ke knihovnˇe, pˇrestoˇze byla ruˇcnˇe nastavena, zvolil jsem tedy programovat a ukazovat funkce v knihovnˇe MQTTnet.

Knihovna podporovala bal´ıˇcek NuGet. Po nainstalován´ı a vloˇzen´ı do projektu bylo velice snadné vyuˇz´ıvat jeho funkce. Následnˇe jsem hledal jak vyuˇz´ıvat danou knihovnu. Bohuˇzel, veˇskeré návody byly pro jiné programovac´ı jazyky. Knihovnu jsem se tedy uˇcil pouˇz´ıvat pomoc´ı pˇr´ıklad˚u, které sloˇzka s knihovnou obsahovala. Nej- prve jsem se musel nauˇcit, jak vlastn´ı kód funguje a co dˇelá. Poté jsem zaˇcal psát vlastn´ı ˇcásti kódu a komunikaci protokolu zaˇcal zprovozˇnovat. Po propojen´ı serveru a clienta, jsem mezi nimi zaˇcal pos´ılat pˇredem urˇcená data.

Obrázek 4.1: MQTT - poslán´ı zprávy a pˇripojen´ı

(32)

Na obrázku4.1 lze vidˇet, jak samotná aplikace vypadá. Nejprve urˇc´ıme, zda spust´ı server nebo clienta. Client je nastaven tak, aby hledal server na adrese 127.0.0.1, tedy localhost. Pokud na této adrese server nenajde, vyp´ıˇse chybovou hláˇsku a zaˇcne s opˇetovným pˇripojován´ım. Pokud je vˇsak server zapnut, client ho najde, oba vyp´ıˇs´ı, ˇze pˇripojen´ı probˇehlo, a client m˚uˇze zaˇc´ıt vys´ılat data. Po zmáˇcknut´ı libovolné klávesy se odeˇslou specifická, pˇredem urˇcená data. V aplikaci lze vidˇet, ˇze u protokolu MQTT nefunguje klasické pos´ılán´ı dat, ale takzvaný ”publish data”. To znamená, ˇze dané zaˇr´ızen´ı vyˇsle data vˇsem zaˇr´ızen´ım v s´ıt´ı. Je to patrné i z toho, ˇze client, který data vyslal, tyto data také pˇrijal.

Data se pos´ılaj´ı v pˇredem daném tvaru. Obsahuj´ı ID zaˇr´ızen´ı, které data vyslalo, téma dat, samotná data a v tomto pˇr´ıpadˇe i kvalitu pˇrenosu. Dat˚um lze v této knihovnˇe nastavit jeˇstˇe ”retain flag”, coˇz znamená, ˇze je server uschová a vˇsem client˚um, kteˇr´ı se pˇripoj´ı, je bude poskytovat. Server tyto “retain” data zapisuje do seznamu.

Po odpojen´ı clienta server vyp´ıˇse hláˇsku o odpojen´ı (viz Obrázek 4.2). Pokud je client pˇripojen a server se vypne, zaˇcne opˇetovné pˇripojován´ı (viz Obrázek 4.3) a v pˇr´ıpadˇe, ˇze se server opˇet zapne, client se automaticky pˇripoj´ı. Poté m˚uˇze znovu prob´ıhat komunikace (viz Obrázek 4.4).

Obr´azek 4.2: MQTT - odpojen´ı clienta

(33)

Obr´azek 4.3: MQTT- recconecting

Obr´azek 4.4: MQTT - reconnected

V ukázkách lze vidˇet výhody protokolu MQTT. Prvn´ı výhodou je zas´ılán´ı dat bez ohledu na jejich obsah nebo tvar. Veˇskerá data se pos´ılaj´ı ve tvaru zprávy, do které lze zapsat jakýkoliv datový typ. Mnou vytvoˇrená aplikace pos´ılá datum narozen´ı jako typ DateTime (viz Obrázek4.5).

Obr´azek 4.5: MQTT - tvar dat