Dobrý deň, vážení nadšenci Internetu vecí. V tomto článku by som sa znova chcel porozprávať o bytových službách a prieskume meracích prístrojov.
Občas nejaký veľký hráč v telekomunikáciách oznámi, ako čoskoro vstúpi na tento trh a všetkých pohlcuje. Každýkrát, keď počujem takéto vyhlásenia, myslím si: „Držím vám palce!“
Ani si neviete predstaviť, do čoho sa púšťate.
Aby ste pochopili rozsah problému, stručne sa podelím o malú časť našich skúseností pri vývoji platformy 'Inteligentné Mesto'. O tej časti, ktorá zodpovedá za dispečing.
Celkovo myšlienka a prvé ťažkosti
Ak hovoríme nie o individuálnych meracích prístrojoch, ale o tých, ktoré sú v pivniciach, kotolniach a na podnikoch, väčšina z nich je teraz vybavená telemetrickým výstupom. Zriedkavejšie impulzným, častejšie RS-485/232 alebo Ethernet. Zvyčajne najlukratívnejšie meracie prístroje sú tie, ktoré merajú teplo. Práve za ich dispečing sú ochotní platiť predovšetkým.
Už som podrobne hovoril o špecifikách RS-485 vo svojej predchádzajúcej článku. Ak to zjednodušíme — je to len rozhranie na prenos dát. V podstate ide o požiadavky na elektrické impulzy a komunikačné linky. Opis paketov je na vyššej úrovni, v štandarde prenosu dát, ktorý funguje nad RS-485. A čo za štandard tam bude — to je na výrobcovi. Často Modbus, ale nie je to povinné. Aj keď je to Modbus, môže byť aj niekoľko modifikovaný.
V podstate pre každý merací prístroj potrebujete svoj vlastný skript prieskumu, ktorý vie s ním 'rozprávať' a zisťovať informácie. To znamená, že systém dispečingu je súbor skriptov pre každý jednotlivý merací prístroj. Databáza, kde sa to všetko uchováva. A nejaké používateľské rozhranie, v ktorom si môže vytvoriť potrebnú správu.
Vyzerá to jednoducho. Diabol, ako vždy, sa skrýva v detailoch.
Začneme s prvou časťou.
Skripty
Ako ich napísať? Nuž, je zrejmé, že treba kúpiť merací prístroj, rozobrať ho, naučiť sa s ním komunikovať a integrovať ho do celkovej platformy.
Bohužiaľ, toto riešenie pokryje iba časť našich potrieb. Zvyčajne má populárny odpočet niekoľko generácií a skript pre každú generáciu sa môže líšiť. Niekedy len trochu, inokedy zásadne. Pri kúpe niečoho dostanete poslednú generáciu. U predplatiteľa je však s vysokou pravdepodobnosťou niečo staršie. To sa už nepredáva v obchodoch. A predplatiteľ nebude meniť uzol merania.
Odtiaľ prichádza prvý problém. Písanie takýchto skriptov je pevná väzba medzi vývojármi softvéru a inžiniermi „na mieste“. Kúpili sme poslednú generáciu, napísali sme akýsi počiatočný šablón a ďalej sme ho modifikovali už na reálnych zariadeniach. Robiť to laboratórne je nerealistické, len pri práci s živými predplatiteľmi.
Strávili sme veľa času vytváraním takejto väzby. Teraz je algoritmus vyladený. Počiatočné šablóny sa neustále upravovali a dopĺňali v závislosti od toho, čo sme stretli vo svojej praxi. Samozrejme, predplatiteľa sme informovali, ak náhodou jeho odpočet bol o niečo „iný“. Pri objavení takého zariadenia sa pripojí podľa štandardného schémy a skript prieskumu sa modifikuje za behu. Počas integrácie predplatiteľ pracuje bezplatne. Informujú ho, že zatiaľ žije v testovacom režime. Samotný proces integrácie je dosť nepredvídateľná vec. Niekedy je potrebné vykonať minimum opráv. Niekedy je to zložitý proces s výjazdom na miesto, prekopávaním literatúry a postupným prekonávaním prekážok.
Úloha nie je jednoduchá, ale riešiteľná. Výsledok — funkčný skript. Čím väčšia je knižnica skriptov, tým ľahšie je žiť.
Druhý problém.
Technologické schémy pripojenia
Aby ste pochopili zložitost tejto práce, uvediem príklad. Berieme extrémne populárny teplomer VKT-7.
Samo o sebe názov nám ešte nič nehovorí. VKT-7 má niekoľko hardvérových riešení. Aké rozhranie má vo vnútri?
Existujú rôzne varianty. Môže byť výstup v štandardnom konektore DB-9 (to je RS-232). Môže to byť len svorkovnica s kontaktmi RS-485. Môže to byť dokonca sieťová karta s RJ-45 (v tomto prípade je ModBus zabalený do Ethernetu).
Alebo vôbec nič. Len holý merač. Môžeme do neho nainštalovať rozhranie, ktoré predáva výrobca samostatne a stojí peniaze. Hlavný problém je v tom, že na jeho inštaláciu je potrebné otvoriť merač a zrušiť pečate. To znamená, že do procesu sa zapája dodávateľská organizácia. Oznámia jej, že pečate budú zrušené, určí sa deň a náš inžinier za prítomnosti zástupcu dodávateľov vykoná potrebné úpravy, po čom sa merač opäť zapečatí.
V závislosti od inštalovaného rozhrania sa vykonáva ďalšia úprava. Napríklad, rozhodli sme sa pripojiť merač kábli. To je najjednoduchšia možnosť, ak je v 100-metrovom dosahu náš prepínač, tak sa s LoRa zaoberať netreba – je to zbytočné. Lepšie je kábli pripojiť do našej siete, do izolovanej VLAN.
Pre RS-485/232 je potrebný prevodník na Ethernet. Mnohí si hneď spomenú na MOXA, ale to je drahé. Pre naše riešenia sme vybrali lacnejšie čínske riešenie.
Ak je výstup priamo Ethernet, tak prevodník nie je potrebný.
Otázka. Povedzme, že sami inštalujeme rozhranie. Môžeme si uľahčiť život a hneď všade dávať Ethernet?
Nie vždy je to možné. Treba sa pozrieť na konštrukciu skrine. Môže sa stať, že nebude mať potrebný otvor, aby sa rozhranie umiestnilo správne. A merač, pripomínam, máme v suteréne. Alebo v kotolni. Tam je vysoká vlhkosť, hermetickosť sa nesmie porušovať. Upraviť skrinu sústruhom – zlá idea. Lepšie je použiť niečo, čo od začiatku nevyžaduje veľké úpravy. Často je RS-485 jedinou možnosťou.
Ďalej. Je merač pripojený na garantované napájanie? Ak nie, tak žije z batérie. V takom režime je určený na ručné vyžiadanie raz za mesiac na tri minúty. Neustále vyžadovanie z VKP-7 vybije jeho batériu. To znamená, že treba ťahať garantované napájanie a umiestniť menič napätia.
Pre každého výrobcu meračov sa modul napájania líši. Môže to byť externý blok na DIN lištu alebo integrovaný prevodník.
To znamená, že na našom sklade by mala byť vždy k dispozícii sada rôznych rozhraní a modulov napájania pre každý merač. Sortiment je ohromný.
Samozrejme, všetko to nakoniec uhradí odberateľ. Ale nebude čakať mesiac, kým dorazí potrebné zariadenie. A potrebuje rozpočet na pripojenie hneď teraz. Takže technologická záťaž spočíva na našich pleciach.
Všetko, čo som opísal, sa obaluje do jasnej technickej mapy pripojenia, aby inžinieri na mieste neprehliadli, s akým zariadením budú mať dočinenia a čo potrebujú na jeho fungovanie.
Technická mapa sa susedí s celkovým predpisom na pripojenie. Veď stačí zapnúť merač do našej siete, na port switch-a je potrebné pridať ten správny VLAN, vykonať diagnostiku, zrealizovať skúšobný prieskum. Celý proces sa snažíme maximalizovať automatizovať, aby sme predišli chybám a nezapájali zbytočné sily inžinierov.
Dobre, napísali sme technické karty, predpisy, automatizáciu. Upravili sme logistiku.
Kde sa ešte skrývajú skryté nástrahy?
Údaje sa čítajú a ukladajú do databázy.
Odberateľovi z týchto čísel nie je teplo ani zima. Potrebuje správu. Najlepšie v forme, na ktorú je zvyknutý. Ešte lepšie, ak je to hneď vo forme zrozumiteľnej správy, ktorú si môže vytlačiť, podpísať a odovzdať. To znamená, že potrebujeme jednoduché a intuitívne rozhranie, ktoré zobrazuje informácie o meracom prístroji a môže automaticky vytvoriť správu.
Týmto náš zverinec pokračuje. Ide o to, že existuje niekoľko typov správ. V podstate odrážajú to isté (spotrebované teplo), ale rôznymi spôsobmi.
Niektorí odberatelia vykazujú absolútne hodnoty (to znamená, že v stĺpci spotrebovaného tepla sú uvedené hodnoty počnúc inštaláciou merača), niektorí v rozdieloch (to je, keď uvádzame spotrebu za určité obdobie bez odkazu na počiatočné hodnoty). V podstate používajú nie jednotné štandardy, ale zaužívanú prax. Boli prípady, keď odberatelia videli všetky hodnoty, ktoré potrebovali (množstvo spotrebovaného tepla, objem dodaného a odvedeného nosiča tepla, rozdiel teplôt), ale stĺpce v správe neboli v tej správnej sekvencii.
Odtiaľ nasleduje ďalší krok — správa by mala byť prispôsobiteľná. To znamená, že odberateľ si sám vyberie, čo v akej sekvencii ide a aké zdroje sú v jeho dokumente.
Tu je zaujímavý moment. Všetko je v poriadku, ak je náš merací prístroj správne nainštalovaný. Ale stáva sa, že montážna organizácia pri inštalácii ITP urobila chybu a nesprávne nastavila čas meraciemu prístroju. Stretli sme sa so zariadeniami, ktoré si myslia, že je rok 2010. V našej sústave to bude vyzerať ako nulové hodnoty k aktuálnemu dátumu, a skutočná spotreba — ak zvolíme rok 2010. Tu nám veľmi pomáhajú delta. Teda hovoríme, že za uplynulých 24 hodín naskočilo toľko-ľahko.
Zdalo by sa, načo takéto zložitosti? Tak ťažko zohnať správny čas?
Práve s VKT-7 to povedie k úplnému nulovaniu počítadla a odstráneniu archívov z neho.
Odberateľ bude nútený dokázať dodávateľom, že nainštaloval ITP nie včera, ale už pred piatimi rokmi.
A nakoniec, čerešnička na torte.
Certifikácia
Máme merací prístroj, máme report. Medzi nimi je náš systém, ktorý tento report vytvára. Veríte mu?
Ja áno. Ale ako dokázať, že sa v našom systéme nič nemení, že neskrývame hodnoty? To je už otázka certifikácie. Systém dotazovania musí mať certifikát, ktorý potvrdzuje jeho nestrannosť. Všetky veľké systémy, ako LERS, Ja Energetik a iné, majú takýto certifikát. Získali sme ho aj my, aj keď je to drahé a zabera veľa času.
Samozrejme, vždy sa dá skrátka urobiť a kúpiť niečo hotové. Ale za to sa bude musieť platiť developerovi. A developer môže požiadať nielen o vstupný poplatok, ale aj o mesačný poplatok. Teda budeme nútení zdieľať s ním časť nášho koláča.
Načo to všetko?
Hlavný problém nie je v tom. Vývoj vlastného systému je tiež veľmi drahý a omnoho ťažší. Avšak, poskytuje dôležitú výhodu. Presne chápeme, ako to funguje. Ľahko to škálujeme, môžeme to modifikovať, ak sa náhle objaví potreba. Odberateľ dostáva kompletný servis, a z našej strany sto percentný kontrolu nad procesom.
Práve preto sme si vybrali druhú cestu. Investovali sme do nej rok života našich developerov a polných inžinierov. Ale teraz presne chápeme prácu celej reťaze.
Pri spätnom pohľade chápem, že bez získaných vedomostí by som len ťažko interpretoval neštandardné správanie toho alebo onoho počítadla.
Okrem toho, na základe systému dispečerovania je možné vybudovať niečo väčšie. Alarmy na prekročenie spotreby, správa o poruchách. Čoskoro pripravujeme spustenie mobilnej aplikácie.
Išli sme ešte ďalej a do našej platformy (ináč to ani nazvať nejde) sme pridali možnosť prijímať podnety od obyvateľov, možnosť spravovať naše „inteligentné domofóny“, ako aj kontrolu verejného osvetlenia a niekoľko ďalších projektov, o ktorých som zatiaľ nepísal.
To všetko je zložité, mozgové lámanie a trvá to dlho. Ale výsledok stojí za to. Odberatelia dostávajú hotový komplexný produkt.
Každý operátor, ktorý plánuje vstup do sektoru bývania, sa určite vyberie touto cestou. Prejdú?
Toto je otázka. Nejde ani tak o peniaze. Ako som písal vyššie, potrebuje sa tu naozaj spojenie práce v teréne a vývoja. Nie všetci veľkí hráči sú na to zvyknutí. Ak vaši vývojári sedia v Moskve a pripojenia sa robia v Novosibirsku, váš čas na hotový produkt sa výrazne predlžuje.
Čas ukáže, kto na tomto trhu prežije, a kto povie — no, na to zaplať! Ale jedno viem určite — prísť a získať podiel na trhu výlučne s peniazmi sa nepodarí. Tento proces si vyžaduje netradičné prístupy, dobrých inžinierov, prenikanie do regulácií, komunikáciu so zdrojmi a odberateľmi, ako aj neustále odhaľovanie a prekonávanie prekážok.
P. S. V tomto článku som sa zámerne sústredil na teplo a nespomínam elektrinu ani vodu. Taktiež opisujem pripojenie cez kábel. Ak máme impulzový výstup — tam sú svoje nuansy, ako povinné overenia po inštalácii. Môže sa stať, že káblom sa nedostaneme k miestu, vtedy prichádza na rad LoRaWAN. Opísať celú našu platformu a fázy jej vývoja v jednom článku je jednoducho nerealistické.
Zdroj: habr.com
