Poznámky poskytovatele IoT. Úskalí dotazování měřičů energií.

Dobrý den, vážení milovníci Internetu věcí. V tomto článku bych opět chtěl hovořit o energii a o dotazování měřicích přístrojů.

Pravidelně se nějaký velký hráč v telekomunikacích zmiňuje o tom, jak brzy vstoupí na tento trh a všechny ostatní podmaní. Každýkrát, když slyším takové příběhy, si říkám: „Chlapi, hodně štěstí!“
Ani netušíte, do čeho se pouštíte.

Abychom porozuměli měřítku problému, stručně se podělím o část našich zkušeností s vývojem platformy „Chytré Město“. O té části, která se zabývá dispečerským řízením.

Poznámky poskytovatele IoT. Úskalí dotazování měřičů energií.

Obecná myšlenka a první potíže

Pokud mluvíme o měřicích přístrojích, které se nacházejí ve sklepech, kotelnách a podnicích, většina z nich je nyní vybavena telemetrickým výstupem. Méně často impulsním, častěji — RS-485/232 nebo Ethernet. Obvykle jsou nejziskovější měřicí přístroje ty, které měří teplo. Právě za jejich dispečerské řízení jsou ochotni nejprve zaplatit.
Podrobně jsem se v minulém článku zabýval zvláštnostmi RS-485. Jinými slovy — je to jen datový přenosový rozhraní. V podstatě — požadavky na elektrické impulsy a komunikační linky. Popis paketu se nachází na vyšší úrovni, ve standardu přenosu dat, který funguje nad RS-485. Jaký standard tam bude — závisí na výrobci. Často Modbus, ale nemusí to být jen tak. I když to je Modbus, stejně může být mírně upraven.

V podstatě potřebuje každý měřicí přístroj svůj vlastní dotazovací skript, který s ním umí „komunikovat“ a provádět jeho dotazování. To znamená, že dispečerský systém — je souhrn skriptů pro každý jednotlivý měřič. Databáze, kde je to všechno uloženo. A nějaké uživatelské rozhraní, v kterém si může vytvořit potřebnou zprávu.

Poznámky poskytovatele IoT. Úskalí dotazování měřičů energií.

Vypadá to jednoduše. Ďábel, jako vždy, se skrývá v detailech.

Začněme s první částí.

Skripty

Jak je napsat? No, zřejmě koupit měřicí přístroj, rozebrat ho, naučit se s ním komunikovat a integrovat ho do celkové platformy.

Bohužel, toto řešení pokryje pouze část našich potřeb. Obvykle má populární měřič několik generací a skript pro každou generaci se může lišit. Někdy jen trochu, jindy výrazně. Když něco koupíte, dostanete poslední generaci. Odběratel však pravděpodobně bude mít něco staršího. To už se v obchodech neprodává. A měnit měřicí uzel odběratel nebude.

Odtud plyne první problém. Psaní takových skriptů je tvrdou vazbou mezi vývojáři softwaru a inženýry „na místě“. Koupili jsme poslední generaci, napsali jsme jakýsi počáteční šablonu a dále ji modifikovali již na reálných zařízeních. Udělat něco takového v laboratoři je nemožné, pouze během práce s živými odběrateli.

Strávili jsme spoustu času vytvářením takové vazby. Nyní je algoritmus vypracován. Počáteční šablony byly neustále upravovány a doplňovány v závislosti na tom, co jsme potkávali v naší praxi. Samozřejmě, odběratel byl varován, pokud se jeho měřič ukázal jako „něco jiného“. Při objevení takového zařízení se připojí podle standardního schématu a skript pro vyžádání se modifikuje za chodu. Počas integrace pracuje odběratel zdarma. Je informován, že zatím žije v testovacím režimu. Samotný proces integrace je poměrně nepředvídatelná záležitost. Někdy je potřeba provést minimální úpravy. Jindy je to složitý proces s výjezdem na místo, procházením literatury a postupným překonáváním překážek.

Úkol není jednoduchý, ale řešitelný. Výsledkem je funkční skript. Čím větší knihovna skriptů, tím snadnější život.

Druhý problém.

Technologické mapy připojení

Abychom pochopili složitost této práce, uvedu příklad. Berme velmi populární teploměr VKT-7.

Samo o sobě nám název ještě nic neříká. VKT-7 má několik hardwarových řešení. Jaký má uvnitř rozhraní?

Poznámky poskytovatele IoT. Úskalí dotazování měřičů energií.

Existují různé varianty. Může mít výstup na standardním konektoru DB-9 (to je RS-232). Může mít také jen svorkovnici s kontakty RS-485. Může mít dokonce síťovou kartu s RJ-45 (v tomto případě se ModBus obaluje do Ethernetu).

A možná ani nic. Jen holý měřicí přístroj. Do něj lze nainstalovat rozhraní, které se prodává odděleně a něco stojí. Hlavní problém je, že pro jeho instalaci je třeba otevřít měřič a porušit pečeti. To znamená, že do tohoto procesu se zapojuje dodavatelská organizace. Ta je informována, že pečeti budou porušeny, stanoví se den a náš technik v přítomnosti zástupce dodavatele provede potřebné úpravy, po čemž je měřicí přístroj opět pečetěn.

V závislosti na nainstalovaném rozhraní se provádí další úpravy. Například jsme se rozhodli připojit měřicí přístroj pomocí kabelu. To je nejjednodušší varianta, pokud je náš switch dostupný do 100 metrů, než experimentovat s LoRa – to je nadbytečné. Snadněji kabelem do naší sítě, do izolovaného VLAN.

Pro RS-485/232 je potřebný převodník na Ethernet. Mnozí si hned vzpomenou na MOXA, ale to je drahé. Pro naše řešení jsme vybrali levnější čínské řešení.

Pokud je výstup přímo na Ethernet, není převodník potřeba.

Otázka. Předpokládejme, že si sami nainstalujeme rozhraní. Můžeme si ulehčit život a hned všude dávat Ethernet?

Ne vždy je to možné. Je třeba se podívat na provedení skříně. Možná v něm není potřebný otvor, aby rozhraní sedělo, jak má. A měřič, připomínám, máme ve sklepení. Nebo v kotelně. Tam je vysoká vlhkost, nelze narušit těsnost. Upravit skříň pilníkem – špatný nápad. Lepší je použít něco, co od začátku nevyžaduje velké úpravy. Často je RS-485 jedinou možností.

Dále. Je měřič připojen k zajištěnému napájení? Pokud ne, funguje na baterii. V takovém režimu je určen k ručnímu odečtu jednou měsíčně na tři minuty. Neustálý přístup k VKT-7 vybije jeho baterii. To znamená, že je třeba přivést zajištěné napájení a umístit převodník napětí.

Pro každého výrobce měřičů se modul napájení liší. To může být externí blok na DIN lištu nebo vestavěný převodník.

Vychází to tak, že na našem skladu by vždy měl být soubor různých rozhraní a modulů napájení pro každý měřič. Názvosloví je tam působivé.

Samozřejmě, nakonec to všechno zaplatí abonent. Ale nebude čekat měsíc, než přijde potřebné zařízení. A potřebuje rozpočet na připojení tady a teď. Takže technologická zásoba leží na našich bedrech.

Vše, co jsem popsal, se převádí do jasné technické mapy připojení, aby inženýři na místě nemuseli přemýšlet, co je za potvoru, kterou potkali v dalším sklepě, a co přesně potřebují pro její fungování.

Technická mapa sousedí s celkovým regulačním předpisem pro připojení. Vždyť není dost jen zapnout měřič do naší sítě, na port switche je třeba ještě přiřadit ten správný VLAN, provést diagnostiku, udělat zkušební dotaz. Celý proces se snažíme co nejvíce automatizovat, abychom se vyhnuli chybám a nepotřebovali zbytečně inženýry.

Dobře, napsali jsme technické mapy, nařízení a automatizaci. Zorganizovali jsme logistiku.

Kde se ještě skrývají skryté nástrahy?

Data se načítají a ukládají do databáze.

Abonentovi tyto čísla nic neříkají. Potřebuje zprávu. Ideálně v podobě, na kterou je zvyklý. Ještě lépe, pokud ji dostane ve formě přehledné zprávy, kterou si může vytisknout, podepsat a odevzdat. To znamená, že potřebujeme jednoduché a srozumitelné rozhraní, které zobrazuje informace o měřicím přístroji a může automaticky generovat zprávu.

Tady náš zoo park pokračuje. O co se jedná, je, že existuje několik formátů zprávy. Ve své podstatě odrážejí to samé (spotřebované teplo), ale různými způsoby.

Někteří abonenti podávají zprávu v absolutních hodnotách (to znamená, že v columně spotřeby tepla jsou uvedeny hodnoty počínaje instalací měřiče), někdo ve změnách (to je, když uvádíme spotřebu za určité období bez odkazu na počáteční hodnoty). V podstatě používají nejednotné standardy, ale ustálenou praxi. Byly případy, kdy abonenti viděli všechny ty hodnoty, které potřebují (množství spotřebovaného tepla, objem dodaného a odcházejícího teplonosného média, rozdíl teplot), ale sloupce ve zprávě nebyly ve správném pořadí.
Odtud následující krok — zpráva musí být nastavitelná. To znamená, že abonent si sám vybírá, co v jakém pořadí půjde a jaké zdroje má ve svém dokumentu.

Zde je zajímavý moment. Všechno je v pořádku, pokud je naše měřicí zařízení správně nainstalováno. Ale stává se, že montážní firma udělala chybu při instalaci ITP a nesprávně nastavila čas měřiče. Setkali jsme se se zařízeními, která si myslí, že je rok 2010. V našem systému to bude vypadat jako nulové hodnoty k aktuálnímu datu, zatímco skutečná spotřeba, pokud zvolíme rok 2010. Zde nám velmi pomáhají delta. Říkáme tedy, že za uplynulých 24 hodin se nasbíralo tolik a tolik.

Mohlo by se zdát, proč takové komplikace? Je tak těžké seřídit hodiny?

Právě u VKT-7 to povede k úplnému nulování měřiče a odstranění archivů z něj.
Odběratel bude nucen prokázat dodavatelům, že nainstaloval ITP neb včera, ale už před pěti lety.

A nakonec, třešnička na dortu.

Certifikace

Máme měřicí zařízení, máme zprávu. Mezi nimi je náš systém, který tuto zprávu vytváří. Věříte mu?

Já ano. Ale jak prokázat, že u nás uvnitř se nic nemění, že nezkrucujeme hodnoty. To už je otázka certifikace. Systém sběru dat by měl mít certifikát, který potvrzuje jeho nestrannost. Všechny velké systémy, jako LERS, Já Energetik a podobné, tento certifikát mají. Získali jsme ho i my, i když to stojí hodně a zabere spoustu času.

Samozřejmě, že vždycky můžete zkrátit cestu a koupit něco hotového. Ale za to budete muset zaplatit vývojáři. A vývojář si může říct nejen o vstupní poplatek, ale i o měsíční platbu. To znamená, že budeme nuceni sdílet část našeho koláče s ním.

Proč to všechno?

Hlavní problém není v tom. Vývoj svého systému je také velmi drahý a mnohem obtížnější. Nicméně to poskytuje důležitou výhodu. Jasně rozumíme, jak to funguje. Snadno ji škálujeme, můžeme ji modifikovat, pokud by byla potřeba. Odběratel získává komplexnější servis a z naší strany stoprocentní kontrolu nad procesem.

Právě proto jsme zvolili druhou cestu. Investovali jsme do ní rok života našich vývojářů a terénních techniků. Teď už přesně chápeme práci celého řetězce.

Když se ohlížím zpět, uvědomuji si, že bez získaných znalostí bych prostě nemohl správně interpretovat nenormální chování toho či onoho měřiče.

Kromě toho, na základě systému dispečinků lze vybudovat něco většího. Alarmy na překročení spotřeby, zpráva o haváriích. Brzy se chystáme na vydání mobilní aplikace.

Šli jsme ještě dál a do naší platformy (jinak to už ani nejde nazvat) jsme přidali možnost přijímat dotazy od obyvatel, možnost správy našich „chytrých domofonů“, kontrolu pouličního osvětlení a několik dalších projektů, o nichž jsem zatím ještě nepsal.

Poznámky poskytovatele IoT. Úskalí dotazování měřičů energií.

To vše je složité, na hlavu lámou a trvá to dlouho. Ale výsledek za to stojí. Odběratelé dostávají hotový komplexní produkt.

Každý operátor, který plánuje vstoupit do oblasti bytového hospodářství, se určitě vydá touto cestou. Zda to zvládne?
Zde je otázka. Nejde ani tak o peníze. Jak jsem psal výše, je potřeba žádaná kombinace práce v terénu a vývoje. Ne všichni velcí hráči si na to zvykli. Pokud mají vaši vývojáři sídlo v Moskvě, zatímco připojení se realizují v Novosibirsku, pak se čas na hotový produkt významně prodlužuje.

Čas ukáže, kdo se na tomto trhu udrží, a kdo řekne — ne, to už nechci! Ale jedno vím jistě — přijít a obsadit část trhu jen s penězi se nepodaří. Tento proces vyžaduje netradiční přístupy, dobré inženýry, zkoumání regulací, komunikaci se zdroji a odběrateli, neustálé hledání a překonávání překážek.

P. S. V tomto článku jsem se záměrně soustředil na teplo a nezmiňuji elektrickou energii ani vodu. Také popisuji připojení přes kabel. Pokud máme impulzní výstup — tam jsou své nuance, jako například povinné kontroly po instalaci. Může se stát, že nenatáhnete kabel, pak se používá LoRaWAN. Popsat celou naši platformu a etapy jejího vývoje v jednom článku je prostě nerealistické.

Zdroj: habr.com

Koupit spolehlivý hosting pro webové stránky s ochranou proti DDoS, VPS VDS servery 🔥 Koupit spolehlivý hosting pro webové stránky s ochranou proti DDoS, VPS VDS servery | ProHoster