Chytré zariadenia v priemysle (7)

Protokoly a komunikačné štandardy

Prvky internetu vecí, ako aj všetky ostatné smart technológie prinášajú nespočetné množstvo možností na získavanie údajov v reálnom čase. Rôzne systémy a senzory v priemyselnej oblasti počnúc priemyslom a zábavou končiac generujú periodické alebo neperiodické, časovo závislé udalosti (dáta), ktoré je okrem iného nevyhnutné zosnímať, spracovať, preniesť, uložiť a bezpochyby aj analyzovať. Treba podotknúť, že senzor nemusíme nutne vnímať ako fyzické zariadenie produkujúce dáta o fyzikálnych vlastnostiach reálneho objektu. Senzorom môže byť aj syntetické zariadenie – softvérový pozorovateľ (z angl. listeners, observers, watch dogs), ktorý monitoruje nie prísne fyzikálne veličiny. Príkladom môže byť dostupnosť služby, vyťaženosť serverov či interakcia s používateľom. V tejto časti série článkov chceme poukázať na zaužívané pravidlá, protokoly a štandardy, ktoré súvisia predovšetkým s kódovaním, prenosom a ukladaním senzorických dát z fyzických (hardvérových) a syntetických (softvérových) senzorov používaných v smart a IoT aplikáciách.

Kódovanie senzorických dát

Z pohľadu efektívnosti, ale aj elementárnej bezpečnosti je typické, že sa dáta neprenášajú v čistej textovej podobe (z angl. plain text). Dáta sa preto pred prenosom kódujú alebo komprimujú. Treba poznamenať, že aj štruktúra dát je dôležitý aspekt súvisiaci s efektívnosťou prenosu. Univerzálnym štandardom pri prenose silne aj slabo štruktúrovaných dát sa v súčasnosti stal formát JSON (RFC 8259) [1]. Na kompresiu sa tradične využívajú štandardy deflate (RFC 1951) [2] a gzip (RFC 1952) [3], pričom kódovanie obsahu väčšinou závisí od pôvodného formátu. V prípade formátu JSON je vhodnou alternatívou jeho binarizovaná forma nazvaná CBOR (RFC 7049) [4]. Tento formát na úkor čitateľnosti človekom zvyšuje prenosovú rýchlosť, resp. znižuje objem prenesených dát. Práve z uvedeného dôvodu je vhodný aj na použitie pri komunikácii smart a IoT zariadení medzi sebou (M2M) alebo externým prostredím pomocou rôznych protokolov. Okrem iného je formát CBOR odporúčaný v IoT komunikačnom protokole CoAP (pôvodne RFC 7252, po aktualizáciách RFC 8323) [5]. Alternatívou vo formátovaní je tradičný XML formát s príslušnou schémou XSD alebo transformáciou XSLT do štandardných formátov pre smart dáta (RFC 3470) [6]. Podobne ako formát JSON, aj XML je zaťažený svojím štandardným objemom a navyše aj schémou. Binarizovanou reprezentáciou XML je W3C kódovací formát EXI (z angl. Efficient XML Interchange) [7], ktorý tieto problémy čiastočne eliminuje. Jeho výlučným cieľom je zefektívnenie prenosu XML dokumentov kódovaním, racionalizáciou a vytvorením striktných pravidiel na návrh schémy XSD.

Prenos senzorických dát

Zvyčajne sa komunikácia a prenos realizujú dvoma rôznymi spôsobmi, ktoré určujú formát, kódovanie a prenosový protokol. Pri prenose dát v oblasti smart zariadení sú tieto spôsoby vždy do istej miery modifikované z dôvodu maximalizácie prenosovej rýchlosti, resp. minimalizácie objemu prenesených dát. Konkrétne ide o komunikácie typu:

1. Klient – server – komunikácia, kde sa očakáva, že jedno zo zariadení je zodpovedné za udržiavanie spojenia a realizuje rôzne funkcie:

a) Cloudové riešenia – protokoly umožňujúce komunikáciu D2C (device-to-cloud), resp. C2C (cloud-to-cloud). Klienta v tomto type prenosu predstavuje každý senzor a serverom sú cloudové služby. Na komunikáciu D2C sa štandardne používajú protokoly AMQP, DDS a MQTT, zatiaľ čo na C2C len AMQP a DDS [8].

b) Štandardné služby REST a SOAP – protokoly využívajúce prístup požiadavka/odpoveď (z angl. request/response – R/R) alebo publikovanie/odber (z angl. publish/subscribe – P/S). Prvý prípad je typický pre služby REST a SOAP a využívajú ho protokoly CoAP, DDS a MQTT [8]. Znamená to, že napríklad pri požadovaní dát zo senzora serverom server vygeneruje žiadosť o dáta a klient vygeneruje odpoveď obsahujúcu predmetné dáta. Tento prístup je vhodný na riedke vzorkovanie dát (napr. jeden záznam zo senzora za hodinu). Druhý prípad sa využíva v určitom ohľade šetrnejšie k objemu prenesených dát. Tento prístup vyžaduje, aby sa všetky zariadenia, ktoré požadujú dáta zo senzora, zaregistrovali na odber udalostí a ak senzor zaznamená spúšťaciu udalosť, odošle dáta všetkým odberateľom, t. j. publikuje ich. Príkladom vhodného využitia sú nepravidelné udalosti, ako sú napríklad alarmy alebo senzory určené na monitorovanie atypických situácií.

2. Peer-to-Peer (P2P) – predstavuje ad-hoc sieť medzi dvoma a viacerými klientmi, ktoré sú na identickej hierarchickej úrovni z hľadiska komunikácie. V oblasti smart zariadení sa zvykne P2P komunikácia označovať aj ako device-to-device (D2D) alebo machine-to-machine (M2M) sieť:

a) Privátne lokálne siete (PAN) predstavujú väčšinou ad-hoc siete vytvorené na komunikáciu medzi geograficky blízkymi zariadeniami. Štandardne sa používajú pre izolovateľné systémy, napr. automobil (Controller area network – CAN), smart domácnosť (Home area network – HAN), človeka (Body area network – BAN) a pod.

b) Oportunistické P2P siete – v oblasti tzv. pervazívneho počítania [9] existuje koncepcia oportunistického sieťovania [9], ktorá opisuje vytváranie ad-hoc siete na základe vzájomnej blízkosti zariadení. Túto blízkosť však pervazívne počítanie chápe nielen ako geografickú vzdialenosť, ale najmä ako metriku vzdialenosti medzi dvoma zariadeniami v určitom doménovom kontexte. Príkladom sú smart zariadenia patriace jednej rodine (smart domácnosť, smartfóny, automobily, kamery, nositeľné zariadenia, a. i.). Je možné, že tieto zariadenia sú geograficky od seba vzdialené, ale sú vzájomne blízke zo sociálneho hľadiska a mali by patriť do jednej logickej siete. Senzorika môže využívať tieto prístupy podobne aj v priemyselnej alebo verejnej oblasti, napr. na zabezpečenie kontextuálnych dát. Napríklad lokálny zber dát z lambda sond z CAN zberníc áut v určitej lokalite, ktoré sú odosielané statickému majáku (oportunistické sieťové zariadenie umiestnené napr. v blízkosti križovatky) môže pomôcť predikovať smogovú situáciu v okolí majáku, resp. vybudovať profil križovatiek a ciest bez potreby sledovať situáciu kamerou, rýchlostným radarom, senzorom smogu a množstvom iných senzorov. Všetky tieto kontextuálne dáta sú zabezpečené agregovaním lokálnej telemetrie, ktorú štandardne generuje prevádzka každého automobilu.

Tab. 1 Špecifiká protokolov na komunikáciu smart a IoT zariadení [8]

Protokoly určené pre smart a IoT zariadenia musia počítať s nespoľahlivosťou prenosu, a teda s možnou nedostupnosťou senzorov a fluktuujúcou vzorkovacou periódou. Táto vlastnosť sietí je jedným z pilierov koncepcie pervazívneho počítania [9]. Práve z toho dôvodu niektoré aplikačné protokoly vrátane spomínaného CoAP využívajú transportný protokol UDP. Alternatívami sú teda protokoly postavené na TCP transportnom protokole, napríklad AMQP (z angl. Advanced Message Queuing Protocol – ISO/IEC 19464) [10] a MQTT (Message Queuing Telemetry Transport – ISO/IEC PRF 20922) [11]. Protokol DDS (z angl. Data Distribution Service) je naopak aplikovateľný univerzálne pri použití UDP alebo TCP transportného protokolu [8].

S uvedenými protokolmi na prenos a ich náročnosťou na objem prenesených dát súvisia aj technológie, ktoré tieto väčšinou bezdrôtové prenosy zabezpečujú. Nakoľko je táto tematika pomerne rozsiahla, najpoužívanejšie technológie len vymenujeme: WiFi, Bluetooth Low-Energy (BLE), Zigbee, Z-Wave, 6LowPAN, Thread, Sigfox, LoRaWAN.

Ukladanie senzorických dát

V závislosti od spôsobu prenosu a komunikácie môžu byť dáta ukladané lokálne alebo na vzdialený server, resp. gateway. Pamäťová a výpočtová kapacita je kľúčovým faktorom pri zariadeniach, ktoré by mali dáta ukladať lokálne hoci len dočasne. Pri smart a IoT zariadeniach je tento fakt obzvlášť dôležitý, najmä preto, že väčšinou fungujú relatívne izolovane, t. j. disponujú obmedzeným napájacím zdrojom (batérie), sú ťažko dostupné, môžu sa nachádzať na geograficky rozsiahlom území. Práve preto sa treba pri ukladaní sústrediť na osobitosti každého zariadenia a určiť spôsob, interval a miesto ukladania dát. Formát, v ktorom sa dáta ukladajú, by mal zodpovedať požiadavkám na jednoduché spracovanie (kódovanie/kompresiu) pri odosielaní.

Ako príklad možno uviesť už spomínané senzory na analýzu smogu. Tie spĺňajú spomenuté kritériá, čo znamená, že sa nachádzajú na geograficky rozsiahlom území (napr. mesto), v ťažšie dostupnom teréne (napr. na stĺpoch verejného osvetlenia, semaforoch alebo meteostaniciach) s obmedzeným napájaním (batérie). V ideálnom prípade je pre senzory k dispozícii externé napájanie v podobe fotovoltického panela alebo napájania meteostanice. Lokálne by sa preto mali ukladať len tie dáta, ktoré senzor potrebuje na okamžité spracovanie alebo sú inak nevyhnutné pre funkčnú koncepciu odosielania (napr. odosiela sa len agregovaný údaj z fixného časového úseku, nie každá vzorka).

Záver

V tomto článku sme poukázali na úlohy, ktoré treba riešiť pri nasadzovaní smart a IoT riešení, a predovšetkým na spôsoby, štandardy a protokoly, akými sa tieto úlohy v súčasnosti riešia. Zamerali sme sa na úlohy kódovania a formátovania, prenos a komunikáciu medzi zariadeniami a ukladanie dát, ktoré generujú smart a IoT zariadenia vďaka svojim senzorom. Tiež sme upozornili na dôležitosť a miesto syntetických senzorov vo svete smart zariadení.

Zdroje

[1] Bray, T. – Ed.: The JavaScript Object Notation (JSON) Data Interchange Format. [online]. 12/2017. ISSN 2070-1721. Dostupné na: https://tools.ietf.org/html/rfc8259.

[2] Deutsch, P.: Deflate Compressed Data Format Specification version 1.3. Aladdin Enterprises. [online]. 5/1996. IETF RFC 1951. Dostupné na: https://tools.ietf.org/html/rfc1951.

[3] Deutsch, P.: GZIP file format specification version 4.3. Aladdin Enterprises. [online]. 5/1996. IETF RFC 1952. Dostupné na: https://tools.ietf.org/html/rfc1952.

[4] Bormann, C. – Hoffman, P.: Concise binary Object Representation. [online]. 10/2013. IETF RFC 7049. ISSN 2070-1721. Dostupné na: https://tools.ietf.org/html/rfc7049.

[5] Bormann, C. – Lemay, S. – Tschofenig, H. – Hartke, K. – Silverajan, B. – Raymor, B. (Ed.): CoAP (Constrained Application Protocol) over TCP, TLS, and WebSockets. [online]. 2/2018. IETF RFC 8323. ISSN 2070-1721. Dostupné na: https://tools.ietf.org/html/rfc8323.

[6] Hollenbeck, S. – Rose, M. – Masinter, L.: Guidelines for the Use of Extensible Markup Language (XML) withing IETF Protocols. [online]. IETF RFC 3470. Dostupné na: https://tools.ietf.org/html/rfc3470.

[7] Schneider, J. – Kamiya, T. – Peintner, D. – Kyusakov, R.: Efficient XML Interchange (EXI) Format 1.0. W3C odporúčanie z 11. 2. 2014. [online]. Dostupné na: https://www.w3.org/TR/2014/REC-exi-20140211/.

[8] Data-Distribution service specification at Object Management group (OMG). [online]. Dostupné na: https://www.omg.org/intro/DDS.pdf.

[9] Vastardis, N. – Yang, K.: Mobile Social Networks: Architectures, Social Properties, and Key research Challenges. In: IEEE Communication Surveys and Tutorials, 2013, vol. 15, no. 3, pp. 1 355. ISSN 1553-877X.

[10] ISO/IEC 19464:2014 Advanced Message Queuing Protocol v 1.0. [online]. Dostupné na: https://www.iso.org/standard/64955.html.

[11] ISO/IEC 20922: 2016 Message Queuing Telemetry Transport v 3.1.1. [online]. Dostupné na: https://www.iso.org/standard/69466.html.

Poďakovanie

Táto séria článkov vznikla vďaka realizácii projektov podporených Kultúrno-edukačnou grantovou agentúrou Ministerstva školstva, vedy, výskumu a športu SR a Slovenskej akadémie vied pod číslom 05TUKE-4/2017 a Agentúrou na podporu výskumu a vývoja na základe zmluvy č. APVV-16-0213.

Ing. Pavol Šatala
pavol.satala@tuke.sk

Ing. Vladimír Gašpar, PhD.
vladimir.gaspar@tuke.sk

doc. Ing. Peter Butka, PhD.
peter.butka@tuke.sk

Technická Univerzita v Košiciach
Fakulta elektrotechniky a informatiky
Katedra kybernetiky a umelej inteligencie
– Oddelenie hospodárskej informatiky
Laboratórium chytrých technológií
Vysokoškolská 4, 042 00 Košice
http://kkui.fei.tuke.sk/chi/smart