Jak zajistit, aby bateriové senzory fungovaly i přes 10 let na běžné baterie a přitom měřily a poskytovaly data každou minutu? Více v článku.
Rozhovor s Hynkem Syrovátkou z IQRF Alliance vede Ivona Spurná.
Podcast: Internet věcí (nejen) po česku https://soundcloud.com/iqrf-iqrf/2021-01-iqrf-news
Videozáznam i IQRF Meetupu 2021: https://youtu.be/_6Uk_CR_FdA
Krásný den všem posluchačům našeho kanálu Internet věcí (nejen) po česku. Dnes bych ráda přivítala Hynka Syrovátku, který je mj. technickým ředitelem IQRF Alliance.
Dobrý den.
Hynku, v posledních měsících získala technologie IQRF další vylepšení. Ti, kdo se zajímají, zřejmě slyšeli o beamingu, lokálním FRCu a podobně. Můžeš nám tyto funkce přiblížit, vysvětlit, aby i lidé, kteří ještě o IQRF neslyšeli, pochopili, k čemu slouží, pro jaké praktické aplikace se hodí?
Určitě, moc rád. Já myslím, že se to dá shrnout v jedné větě, že jsme přidali nové komunikační protokoly, které pro IQRF, IQMESH otvírají možnosti použití, kde dříve jsme nestáli úplně pevně v kramflecích. Konkrétně je to ohledně třeba asynchronní komunikace, od nějakých kontrolérů, řídicích zařízení, po bateriové senzory s velmi nízkou spotřebou, které v offline režimu vysílají naměřená data a my jsme připravili celou sadu protokolů, díky nimž je možno tato data ze sítě získat.
Tak já bych se možná nejprve zastavil u zmíněného lokálního FRCu. To je nový protokol, který slouží k tomu, abychom mohli asynchronně ovládat z nějakých kontrolérů – můžete si to představit jako tlačítko nebo PIR čidlo – tak, abychom pomocí IQRF zařízení tohoto typu mohli ovládat nějaké akční členy, aktuátory. Můžete si pod nimi představit typicky světla. Typickým scénářem je – za dveřmi mám tlačítko – IQRF tlačítko, přijdu k němu, stisknu ho a rozsvítí se světla v místnosti. Dříve taková asynchronní komunikace také šla udělat, ale ne úplně standardním způsobem, a ne příliš efektivně. Ve smyslu jak spotřeby, tak potvrzení té komunikace apod.
No a lokální FRC je ta novinka. Čím je zvláštní – je vysílán z nodu, ze zařízení. Vy z vás, co znáte FRC a věřím, že je to většina, tak víte, že se vysílá z koordinátora a z něj je to zpravidla použito k tomu, že se stáhnou nějaké FRC hodnoty z nodů, ze zařízení. Tady to je trošku, nechci říct – použito vzhůru nohama, ale je to použito v režimu, kdy zařízení – nod – mluví k jiným nodům. Tzn. ten nod, to zařízení, ten kontrolér, vyšle lokální FRC k nějakým jiným nodům, to jsou ta světla, ty aktuátory, pošle jim samozřejmě nějaká uživatelská data, ve kterých je obsažen příkaz, co mají vykonat, a ty nody mu zpátky odpoví FRC hodnotou, tak, jak to dostává koordinátor od jiných nodů, a v této FRC hodnotě můžou být skryté nějaké užitečné údaje, ale v podstatě hlavně je to způsob potvrzení toho, že ty nody ten FRC příkaz přijaly. Tento FRC oproti tomu běžnému síťovému FRCu je velmi rychlý, protože není routovaný, je to na jeden skok/doslech, chybí tam i ta agregační fáze, tu, kterou známe z normálního FRCu, kde se data seberou z celé sítě a routují se zpět ke koordinátorovi.
Zde je to velmi ořezaný běžný FRC, kde ten kontrolér vyšle broadcastový požadavek na nejbližší nody, které když ho slyší a jsou adresovány, tak ten FRC přijmou a v Custom Handleru, tak jak jsme zvyklí, ho zpracují. Nebo to může být Embeded FRC, takže se to nemusí v Handleru vůbec řešit, ony ho zpracují, odpoví hodnotou, to se stane v té tzv. individuální fázi, ten kontrolér to přijme, může se ještě nějak zachovat, když mu některé nody neodpověděly z nějakého důvodu, které on adresoval, může to zopakovat, ignorovat, nahlásit chybu, ty možnosti jsou různé, a tím se vykonala ta práce. Takže typicky se do toho kontroléru připraví data, která se mají tím FRC commandem poslat, připraví se tam i bitová mapa nodů, které se mají oslovit, vyšle se to, ty nody to zpracují a pošlou zpět.
Na všechno, jak jste asi zvyklí, máme jednoduché příklady. Na toto máme příklad, kód, který má v sobě všechny části, jak tu část pro kontrolér, tak část pro aktuátor. V tom příkladu se používá naše běžné tlačítko pro ovládání a naše LEDky pro indikaci. Tzn. tím kontrolérem ovládáte, tuším, ty červené LEDky na těch jiných nodech, a pak svojí zelenou LEDkou indikujete, že vše bylo v pořádku a naopak.
Je to velmi jednoduché, a je potřeba, aby se to nedalo zneužít, aby se nemohlo stát, že do té sítě budete posílat FRCy např. s příkazem – odbondujte se. Aby to nebylo zneužitelné, tak ten nod musí na druhé straně validovat, že ten lokální FRC je vhodný ke zpracování. Tj. než se vůbec ten lokální FRC vykoná, tak prochází verifikací, kde je potřeba explicitně říct, že je v pořádku, a že je možné ho vykonat. A druhá věc, která tam je, že ten lokální FRC musí být explicitně povolen v konfiguraci těch aktuátorů. Tyto dvě podmínky musí být splněny, aby se ten lokální FRC použil.
Já bych zájemce odkázal na naši nápovědu k DPA, kde v části, kde se o lokálním FRCu hovoří, je i přehledné video s animací, s vysvětlením, kde je krásně vidět, jak to celé funguje a jak se pomocí toho dají dělat i taková ovládání.
Právě kvůli tomu, že ten lokální FRC je ořezaný, mnohem kratší a rychlejší než ten velký FRC, tak ta reakce by měla být velmi rychlá, v takovém časovém intervalu, který je přijatelný třeba pro nás, pro lidi, kde když cvakneme vypínačem, tak čekáme, že se světla rozsvítí prakticky okamžitě, pro to je to vhodné.
Co je ještě důležité, ta komunikace je potvrzená. Tj. ten kontrolér má možnost zjistit, zda-li všechny a případně které nody to vykonaly a které ne.
Na webu iqrf.org je nápověda k DPA, je tam připraveno DPA API volání – DPA API local FRC. Když se tam podíváte, je tam vše vysvětleno, je tam i odkaz na ty příklady a video. Tolik lokální FRC.
Další užitečnou technologií je něco, čemu my interně říkáme beaming. K čemu je to dobré... Je to nějaký styl komunikace, kde zařízení, typicky senzory, čas od času vyšlou podobně jako maják (proto beaming) naměřená data a už se o to dál nestarají, abych to zjednodušil. Tímto způsobem je možné dosáhnout toho, že takové senzory dosáhnou na relativně běžné primární články životnosti 10, 15, klidně i 20 let. I když budou konkrétně každou minutu vysílat naměřené hodnoty, typicky teplotu a relativní vlhkost.
Je to něco, co máme potvrzeno, naměřeno. Samozřejmě, 10, 15 let jsme ještě nečekali, ale máme změřené průměrné spotřeby takových zařízení, a předpoklady a teoretické výpočty ukazují, že zařízení v tomto režimu, kdy každou minutu naměří takové veličiny, by mělo bez spotřeby článku fungovat 15 let. To zařízení je součástí sítě, ale vůbec není na příjmu. Není to třeba. V podstatě 99,9 % času to zařízení je v hlubokém spánku nebo ve spánku, čas od času se probudí, udělá nějaké měření a ty výsledky měření vyšle jednoduchým, standardním způsobem, který máme opět demonstrován v příkladu, vyšle data, ten paket je ve formátu dle našeho IQRF senzorického standardu. Otázka zní, k čemu to je dobré, když to jen vyšle, tak jak se to zpracuje dál. To jsou právě ty další následné novinky.
My celé té sadě novinek, kde právě podporujeme bateriové senzory s dlouhou životností, říkáme beaming. Ale v podstatě ten beaming je tato fáze, to, že ten senzor vyšle ta data. Aby se ta data přijala, zpracovala, a dokázala potom stáhnout, tak jsou tady další novinky.
První je FRC agregace. Funguje to následovně. Beamovací senzor vyšle nazdařbůh data. Třeba 1x za minutu. Předtím, než to vyšle, může udělat nějaký listen-before-talk, tj. udělá test, jestli není v nejbližším okolí nějaká radiová komunikace, aby nezpůsobil kolizi, a když to pak vyšle, jde zase spát. Něco, čemu říkáme FRC agregující repeater, zařízení, které umí dělat FRC agregaci, tento paket slyší. Ten paket s daty přijme, uloží si je do jakési databáze, což je typicky nějaká trochu větší externí RAM paměť, ta data tam „syslí“ pro ty jednotlivé senzory, nody, jejichž nabeamovaná data se jim podařilo přijmout.
Tzn. mají je uložena (dokážete si představit, že při větším počtu senzorů už je to docela hodně dat, proto taky ta externí paměť). V okamžiku, kdy o ta data máme zájem, typicky na bráně, na koordinátorovi, tak se získají normálním, běžným senzorickým FRC, tak jak jsme zvyklí. Chci například vidět hodnotu teploty ze všech senzorů v síti, takže jak jsem zvyklý z dob, než beaming existoval, způsobem čtení hodnot ze senzorů, které jsou online, tak pošlu FRC, standardní senzorický FRC – prosím všechny nody, nechť mi pošlou teplotu, kterou naměřily.
Správná otázka přichází, jak mohou ty nody tu teplotu poskytnout, když spí. Když tu teplotu, kterou naměřily, odeslaly tím beamingem nazdařbůh a někdo ji slyšel. Odpověď je – použije se tzv. agregace FRC. Ta zařízení, typicky routující zařízení v síti, která přijala ten beaming a mají ta data ve své interní databázi, tak můžou použít novou techniku, které říkáme tzv. FRC agregace. Jsou schopné tu hodnotu třeba té teploty přijaté od nodu v podstatě vnutit jakoby do toho výsledku, který se vrátí na bránu, takže to té bráně připadá, jako by ten senzor byl v podstatě online.
Taková virtualizace.
Ano, dá se to tak říct. Ten senzor v podstatě v danou chvíli není přítomen na příjmu v té síti, ale protože se zeptáme na hodnotu jeho teploty, vlhkosti, jakékoli standardní veličiny, jedno které, tak ten FRC ji poskytne, díky té agregaci, díky tomu, že ten FRC se zpracuje na tom repeateru, je tam zachycen. V Custom Handleru, jak jsme zvyklí, se zpracuje, zjistí se, ano, někdo po mně chce standardní senzorickou hodnotu, teplotu, chce to ode mě pro tyto, tyto nody… ten Handler funguje v tom smyslu, že se podívá do databáze, zda-li pro ty nody, pro něž se ten FRC o tu teplotu zajímá, tu hodnotu nemá v databázi. Pokud ano, tak ji podstrčí do toho FRC výsledku, a když se pak všechna ta data zagregují ze všech těchto zařízení a vrátí se zpátky do koordinátora, potažmo do brány, tak se tam ta data objeví.
Takže jak říkáš, jedná se takovou jistou virtualizaci, kde tak zařízení, ač jsou v síti přibondovaná, ale vůbec nekomunikují ve smyslu, že by poslouchala, tak přesto tímto způsobem přes tyto dvě techniky poskytnou data přes FRC tak, jak jsme zvyklí, jakoby byla celou dobu online.
Tato FRC agregace v příští verzi DPA bude plně zdokumentována. Opět, jsou tam na to 2 příklady, jeden velmi jednoduchý a jeden trochu komplikovanější, který právě už umí ty senzorické veličiny, a všichni zájemci, kteří jsou členy aliance, budou mít možnost vybavit svá routující zařízení touto vlastností, tudíž budou schopni FRC beaming celý obsloužit.
Aby to bylo ještě efektivnější, tak se nabízí ještě jedna optimalizace, a to ta skutečnost, že když si představíme, že v síti máme pouze beamující senzory, senzory, které nejsou vůbec online, tak je možné v tom dotazovacím FRCu úplně vynechat tzv. individuální fázi. Ta je prostřední fází běžného FRCu, kdy jednotlivá zařízení pro zvýšení redundace té komunikace toho FRCu vysílají svá data do svého okolí v takových velmi úzkých časových intervalech. Protože ale naše senzory, z nichž chceme vyčíst ty hodnoty, vůbec nekomunikují, spí, tak je možné tuto druhou fázi úplně vynechat. A potom se stane to, že ten FRC má jen dvě fáze. Tu první, kdy se pošle broadcast jen na routující zařízení a pak hned tu sběrnou, žádnou jinou.
Když máme síť, ve které máme 30 beamujících senzorů a na tu síť máme 1, 2 repeatery, tak se celý FRC skládá jen z routingu do těch dvou repeaterů, to jsou dva skoky a pak sběr, agregace, 2 skoky zpátky. Tzn. nyní to je na 2+2 skoky. V minulosti, kdy se ty senzory musely aktivně účastnit toho FRCu, tak tam bylo řekněme dalších 30 individuálních slotů pro tu individuální fázi, což celý FRC částečně zpomalovalo, a během té doby probíhala radiová komunikace, která může způsobovat kolize. Tento tzv. offline FRC je prostě jen normální FRC, jak jsme zvyklí, ale můžeme říct, že chceme vynechat úplně tu individuální fázi, protože všechna data jsou předem připravená v těch agregujících repeaterech. A já nepotřebuji čekat, aby mi ty jednotlivé senzory naměřená data posílaly individuálně, protože ony spí. V realitě ten FRC na těch 30, 60 senzorů trvá několik stovek milisekund, v porovnání třeba i několika jednotek sekund s tím předchozím FRCem, kde se nebeamovalo.
Takže tady máme několik výhod – naprosto razantní prodloužení životnosti těch napájecích článků bateriových senzorů, a zároveň i obrovské zrychlení té FRC komunikace.
Možná mě tady ještě napadá otázka, která by mohla zajímat posluchače, jak se pak s takovými spícími senzory dá komunikovat v případě nějakého updatu/upgradu.
To už je samozřejmě na řešení každého jednotlivého zařízení. Senzory, které mi prošly rukama pro systém IQAROS, tak jsou senzory, které nemají žádné ovládací tlačítko, nicméně je možnost ovládat ten senzor magnetem přes jazýčkový kontakt. Senzor lze značně odolným způsobem, aby se to nestalo omylem, probudit z režimu beamování do režimu online. Tzn. pak jsou v té síti, jsou i na příjmu. Pak s nimi lze komunikovat, ale má to jednu velkou nevýhodu, že, ač v LP režimu, ta spotřeba je výrazně větší, než kdyby spal a beamoval.
A z toho důvodu naše senzory u systému IQAROS mají tu vlastnost, že v tom online režimu zůstanou maximálně 2 minuty, od kdy se s nimi naposledy komunikovalo. Ten senzor je možné uvést do online režimu, je možné s ním komunikovat, provést nějaký update nebo třeba změnu konfigurace, ale v okamžiku, kdy s ním 2 minuty neprohodím slovo, tak on okamžitě skočí do režimu beamování, tj. té nízké spotřeby, třeba v tomto konkrétním případě měření a vysílání dat jednou za minutu.
Jasně, prostě je to na výrobci, jak to bude řešit.
Tak. Když se někdo rozhodne, že bude zařízení uvádět do online režimu nějakým jiným způsobem, třeba pravidelně, cokoliv, proč ne, ale v systému IQAROS pro nás byla důležitá ta výdrž baterie, a dále nulová potřeba mít to zařízení v síti a něco s ním dělat, komunikovat s ním. To zařízení pak už plní v tomto případě jinou roli, měří, vysílá a vydrží dlouho. Víc nepotřebuji.
Toto byly, abych to shrnul, tři nové komunikační techniky, které se skrývají za tím, co my interně označujeme jednoslovně jako beaming.
U beamingu jako takového se jedná o vysílání naměřených dat a la maják.
Druhá věc je agregace těch naměřených dat v rámci FRCu na routujících zařízeních, která tu agregaci podporují a jsou vybavena úložištěm pro uložení těch přijatých, beamovaných dat.
A třetí novinka je offline FRC, tj. optimalizovaný FRC vyslaný z brány, potažmo z koordinátora, kde se zcela vynechá ta individuální fáze, a tudíž je to velmi rychlé a velmi efektivní. A pak si můžeme dovolit, aniž bychom porušovali duty-cycle ve smyslu nařízení telekomunikačního úřadu, když nám senzor vysílá data každou minutu, tak my můžeme pouštět ten FRC třeba každou druhou minutu. A nemusíme se bát, že nějakým způsobem budeme vyvolávat kolize nebo nějak překračovat nějaká nařízení.
Ještě jsou nějaká vylepšení?
Já bych možná přešel na náš software IQRF IDE, kde bych zmínil pár novinek. První věc je, že IDE mě dnes samo upozorňuje, že existuje nová verze, samo stáhne instalátor, samo se přeinstaluje, spustí. Druhá věc, která mě baví, je, že jsme velmi těsně provázali IDE s online nápovědou pro DPA, s online nápovědou na naše standardy, které máme na webu (senzorický, binární výstup, DALI...).
Dnes v IDE, když zadáváte nějaký příkaz v DPA terminálu, standardní senzorický příkaz nebo FRC, tak okamžitě se vám v terminálu píše, o jaký příkaz jde a máte tam přímý prolink na nápovědu k tomu danému příkazu. Řekněme, že třeba vyčtete nějaké senzorické hodnoty ze senzoru, a ten paket, který přijde, si zobrazíte v Packet Inspektoru, který je provázaný s online nápovědou.
Řekněme, že jsme si z nějakého senzoru vyčetli tři veličiny – teplotu, vlhkost, CO2. Pak u těch hodnot mám hned jejich název, což už jsme tedy byli zvyklí, ale ta hodnota je prolinkována s nápovědou příslušného standardu té veličiny a můžu se podívat, co je to za veličinu, jaké má vlastnosti, jaký má rozsah, jaké má rozlišení atd. To je velmi příjemné, člověk ani nemusí mít bokem otevřený prohlížeč s nápovědou, ale všechno z toho IDE lehce dohledá a nemusí použít vyhledávání apod. Takže to je taky věc, která mě hodně baví.
Co připravujeme teď nově je wizard pro rychlé vytváření projektů v IQRF IDE na tvorbu Handlerů. Ten wizard funguje tak, že po jeho spuštění se vás zeptá, pro jakou verzi DPA chcete Handler vytvořit, jestli je to pro nod nebo pro koordinátora, jestli chcete, aby šly hlavičkové soubory přímo k tomu handleru nebo se prolinkovaly, jak se ten Handler má jmenovat. Stejně tak vám dovolíme automaticky do toho projektu, pro který se ten Handler připravuje, přihodit i pluginy pro DPA té konkrétní verze, takže když chcete do toho vašeho modulku ty pluginy nahrát, tak dáte prostě double click a už se nahrávají. Bude tam i automatická notifikace, že je nová verze DPA, což je něco, co nám vývojářům zjednoduší život.
Možná bych ještě zmínil jednu věc, máme tam lepší upozorňování na IQRF novinky, je tam provázání se sociálními sítěmi Twitter, YouTube apod. IQRF IDE má velmi užitečné a zajímavé věci.
Tento nástroj je bezplatně k dispozici všem, kdo potřebují vyvíjet své aplikace na IQRF.
Ještě bych se vrátila k procesu certifikace IQRF Interoperability. Připomenu jen v krátkosti, že pokud si chce člen IQRF Alliance certifikovat zařízení na interoperabilitu IQRF, měl by se v první řadě podívat na web IQRF Alliance, tam prostudovat specifikaci IQRF standardů, a následně si připravit software pro své zařízení, který bude respektovat tyto standardy. Následně posílá zařízení s tímto softwarem do centrály IQRF Alliance, kde se nakonec dostane k tobě a pak následují nějaké iterační kroky, kde se ověří, že je vše tak, jak má být a celý ten proces je podrobně popsán na webu IQRF Alliance.
Certifikoval jsi v poslední době nějaké zařízení na interoperabilitu IQRF?
Neřekl bych to lépe, díky za ten popis. Doplním jen, že máme k dispozici řadu příkladů, Handlerů, pro zařízení, která se mají chovat dle našich standardů pro IQRF interoperabilitu. Nejvíc zajímavé standardy jsou pro senzory, máme tam připravené příklady, zájemci můžou začít ten vývoj po nějakém prvotním studiu těch standardů. Velmi jednoduše si zkopírují ten příklad a začnou ho obohacovat o veličiny ze svých čidel. Myslím, že by ten postup díky těm příkladům měl být velmi rychlý.
Co mi naposledy prošlo rukama? Zajímavé zařízení, které slouží k zapínání/vypínání elektrických spotřebičů na 230 V v elektrorozvodné síti. Je to zařízení, které je určeno pro instalaci do elektroinstalační krabice nebo do podhledu. Zařízení, které umí připojené zařízení nejen zapnout/vypnout dle našeho standardu pro binární výstup, ale co je zajímavé, umí také měřit. Konkrétně umí měřit síťové napětí, odebíraný proud, činný výkon, účiník, kumulovanou spotřebu, takže myslím si, že je to velmi zajímavá věc. Zatím mi procházelo jen rukama, jak a kdy bude k dispozici, to ještě, obzvláště já, říct nemohu, protože to nevím. Tohle je něco, co se mi hodně líbilo.
Takže ve výsledku se takové zařízení dá identifikovat pomocí nějakého hardware profile ID, které je na IQRF repozitáři?
Tak, tak to bude. V tomto okamžiku je tohle konkrétní zařízení ještě ve vývoji, ale jak říkáš, HWPID – jednoznačný identifikátor typu zařízení ho bude identifikovat. Toto zařízení podporuje naše dva standardy, jak standard pro binární výstup pro ovládání toho zařízení, tak senzorický standard, přičemž měří 6 veličin, jestli si dobře pamatuji, od nízkého napětí, přes proud až po tu kumulovanou spotřebu. Takže velmi užitečná věc pro scénáře, kdy potřebuji nejen něco vypínat/zapínat, ale i něco o tom zařízení, potažmo o té elektrické síti vědět.
Takže kdybychom shrnuli tuto oblast certifikace, asi má smysl řídit se podle standardů pro senzory, binární výstup, světla, DALI. Asi jsou i případy, kdy není třeba se certifikací zabývat.
Ano. Takové případy samozřejmě jsou. V okamžiku, kdy mám nějaké velmi specifické potřeby, které jdou mimo tyto oblasti, pak samozřejmě přichází na řadu uživatelské řešení. Ale dovolím si tvrdit, že v okamžiku, kdy chci vyčítat, lidsky řečeno něco měřit, tak si myslím, že náš standard pro senzory je tou správnou volbou. Pokud si dobře pamatuji, tak v současné době máme standardizováno 35 typů veličin.
Samozřejmě by nás napadly i nějaké exotické veličiny. Ještě jsem se třeba nedostali do oblasti ionizujícího záření, takže radioaktivita tam třeba ještě není, ale takové ty běžné věci, fyzikální veličiny, které má smysl v běžných scénářích měřit, nebo je naši zákazníci už měří, tak už jsou v tom standardu. V případě, že budete mít potřebu přidat nějakou veličinu do standardu, obraťte se na nás, dodefinujeme ji ruku v ruce společně, tak, aby to dávalo smysl, a standard obohatíme.
Perfektní. Uzavřel jsi to přesně tím, na co jsem se chtěla zeptat.
Věřím, že to pro posluchače bylo zajímavé i užitečné. Díky.
Díky a přeji hezký den.