Rok 2016 byl z pohledu IoT rokem příchodu nízkopříkonových rádiových technologií (LPWAN) minimálně na náš trh. Do komerčního provozu byly uvedeny hned dvě národní infrastruktury - Sigfox, provozována společností Simple Cell Networks a.s. a také infrastruktura nad standardem LoRaWAN, kterou spustily České Radiokomunikace a.s. Zatímco první zmíněná infrastruktura je nyní poměrně dobře dostupná na území České Republiky a z její podstaty také v mnoha státech nejen Evropy, pak LoRaWAN započala svůj rozjezd opatrně v krajských městech, ale nyní se úspěšně rozvíji dále tak, aby rovněž dosáhla přívlastku - národní. V roce 2016 jsme také zaznamenali několik více či méně úspěchů o rozjetí privátních či izolovaných infrastruktur na LoRaWAN a za zmínku jistě v tomto ohledu stojí síť budovaná kolem Plzně pod zájmovým sdružením PlzenecNET. Všechny tyto aktivity posunuly i počáteční nesmělé krůčky kolem prvních IoT LPWAN projektů o pořádný kus dopředu a jeden zcela konkrétní projekt bych chtěl popsat v následujícím textu.
Mikropilot odečtů vodoměrů pro SmVaK
Myšlenka odečtů vodoměrů dálkovým způsobem je poměrně stará a v mnoha případech také realizovaná s využitím těch technologií, které byly k dispozici v době uvedení těchto myšlenek do praxe. Vesměs se jedná buď o lokální rádiové odečty systémy typu read-by-walk nebo jejich modifikace, které přenášejí lokálně nashromážďená data pomoci technologie gsm nebo některé ryze síťové technologie (ethernet, wifi) do databází provozovatele distribuční vodárenské sítě. Snad jedinou výjimkou je zde existence rádiové sítě na 169MHz, kterou by bylo možné považovat za jekéhosi průkopníka LPWAN, ovšem ne tak při pohledu na cenu za koncovou jednotku a následně přenos dat. Naše společnost se rozhodla na základě přání zákazníka vyvinout kompletní odečítací jednotku vodoměru Sensus 420 a otestovat přicházející IoT LPWAN technologie v praxi.
Ve vytipovaných lokalitách okresu Frýdek-Místek bylo nasazeno celkem 10 jednotek, které dokázaly načítat reálnou spotřebu vody proudící sledovaným vodoměrem, sestavit z ní paket vhodný pro přenos a odvysílat jej. Následně pak z tzv. backendu s využitím popsaného API, kam data dorazila, přečíst sledovanou spotřebu a vizualizovat či exportovat ji pro další využití na straně uživatele. Vznikl tak celý ekosystém typu čidlo-infrastruktura-aplikace, který prokázal živatoschopnost toho, co už více než rok posloucháme na různých fórech, čteme na internetu apod.
Pro uvedení myšlenek do praxe jsme zvolili infrastrukturu Sigfox díky její dostupnosti v uvažovaných lokalitách instalace a také díky vstřícnému postoji operátora. Byli jsme poměrně příjemně překvapení zejména dostupností v těžkých indoor podmínkách a také poměrně dobré spolehlivosti přenášených dat tam, kde signál splňoval kritéria pro garanci přenosů. Objektivně řečeno, pokud jsme instalovali zařízení do cca 5km od nejbližší BTS, pak bylo možné počítat i s těžkým indoor pokrytím a prakticky bezeztrátovým provozem. Snad za vše hovoří naše nejtěžší místo - kanálová šachta, kde bylo čidlo umístěno cca 30cm pod zemský povrch a nejbližší BTS nebyla blíže než zhruba 7km. Přesto se podařilo přenést 80% zpráv a v pohodě z nich rekonstruovat např. průtokovou křivku, či mít poměrně přesnou informaci o stavu vodoměrů z této lokality.
Závěrem tedy bylo konstatováno, že Sigfox je pro tyto účely a tak, jak je v ČR budován velmi vhodnou technologií. Nicméně jsme se i tak rozhodli otestovat v praxi i síť LoRaWAN, ačkoliv jsme si byli vědomí, že se bude jen velmi těžko srovnávat narrowband technologie Sigfox s relativně široké pásmo zabírající technologií LoRaWAN. Právě šířka pásma velmi hraje do karet technologii Sigfox, protože z principu zajišťuje daleko lepší penetraci do indoor prostředí. Motivaci pro otestování LoRaWAN byla zvláště pak její otevřenost a nepoměrně širší aplikační pole při využití HW koncové odečítací jednotky. Naše testy dopadly nad očekávání dobře a pouze pro shrnutí lze konstatovat, že se potvrdila horší penetrace do indoor prostředí tak, jak jsme očekávali, nicméně to platí při věších vzdálenostech od GW. Naštěstí si tento nedostatek uvědomují plánovači sítě a jak České Radiokomunikace, tak PlzenecNET avizují zhruba 3x větší počet GW než má Sigfox BTSek, což by mělo vést ke srovnatelnému pokrytí.
Při testech obou technologií jsme si ale začali uvědomovat fakt, že se jistě vyskytnou místa, kde neuspějeme ani s jednou ze zmíněných technologií. Z tohoto důvodu jsme se zamýšleli nad jakýmsi repeaterem pro jednu či druhou technologii a zde zase pro změnu dominuje LoRaWAN tak, jak je otevřen její standard i pro nestandardní kousky. S využím dostupných transceiverů LoRaWAN lze totiž poměrně snadno realizovat pouhým doplněním FW tzv. přímý rádiový mód, kdy lze využít pro přenos jak pásmo 868MHz, tak 433MHz a data z velmi těžko dostupných míst přenést LoRa modulací k místu, kde je dostupný infrastrukturní signál. Na tomto místě pak poslouchá opět přijímač LoRa a v momentě, kdy obdrží data, pak se opět pomocí mechanismu ve FW přepne do infrastrukturního módu a data odkomunikuje. Takový přijímač - repeater pak může spolupracovat i s více jednotkami a vytvořit tak velmi lacinou mini GW. Naše společnost již vybavuje vhodným FW čidla, která vyrábíme a z každého čidla lze pouhou konfiguraci vyrobit repeater, proprietární nebo infrastrukturní čidlo. Tím se otevírají ještě další možnosti, např. pro již zmíněné read-by-walk systémy, kdy nepotřebujete žádný jiný HW. Žel technologie Sigfox je v tomto ohledu nepoměrně komplikovanější, což plyne z její uzavřenosti. Realizovat podobný repeater by představovalo doplnit stávající HW o další přenosový prostředek, což má negatívní vliv na cenu koncového zařízení a v konečném důsledku taky na jeho spotřebu. Je ovšem otázkou, zda Sigfox vůbec něco takového bude potřebovat, když vezmeme v úvahu jeho dost dobré penetrační schopnosti. Nicméně je to na zvážení a konkrétní aplikaci - co všechno po ní budeme chtít.
Celý ekosystém IoT je pochopitelně potřeba uzavřít nějakou smysluplnou vizualizaci / aplikaci, i zde jsme tedy nelenili a s partnerskou firmou vyvinuli alespoň základní pohled na přenášená data. Pochopitelně tato data čeká spíše ještě transport do zákaznických systémů pro účely fakturace, či do jiných aplikací za účelem archivace nebo následné analýzy.
