Märkmed IoT-teenuse pakkujalt. Probleemid korterite kommunaalmaksete arvestite küsitlemisel.

Tere, austatud Interneti-asjade huvilised. Selles artiklis soovin taas rääkida korteriühistutest ja mõõteseadmestikku küsitlemisest.

Perioodiliselt räägib mõni suur telekomiettevõte, kuidas nad varsti sellele turule tulevad ja kõik enda alla neelavad. Iga kord, kui selliseid jutte kuulen, mõtlen: „mehed, palju õnne!”
Te isegi ei kujuta ette, kuhu te astute.

Kuna te mõistaksite probleemi suurust, räägin lühidalt meie kogemusest „Targa Linna” platvormi arendamisel, täpsemalt selle osa kohta, mis vastutab jaotamise eest.

Üldine idee ja esimesed raskused

Kui rääkida mitte individuaalsetest mõõteseadmetest, vaid nendest, mis asuvad keldrites, katlamajades ja ettevõtetes, siis enamus neist on praegu varustatud telemeetriaväljundiga. Harvem impulssväljundiga, sagedamini — RS-485/232 või Ethernetiga. Üldiselt on kõige „kasumlikumad” mõõteseadmed need, mis arvutavad soojust. Just nende jaotamise eest ollakse valmis kõigepealt maksma.
Olen oma eelnevas artiklis juba põhjalikult peatunud RS-485 eripäradel. Lühidalt — see on vaid andmeedastuse liides. Sisuliselt on see nõuded elektriliste impulsside ja kommunikatsiooniliini jaoks. Pakettide kirjeldus toimub kõrgemal tasemel andmeedastusstandardi kaudu, mis töötab RS-485 peal. Ja mis see standard seal olema hakkab, see on usaldatud tootja enda otsustada. Sageli on see Modbus, kuid see ei ole kohustuslik. Isegi kui see on Modbus, võib see siiski olla mõnes mõttes modifitseeritud.

Sisuliselt vajab iga mõõteseade oma küsitluse skripti, mis oskab sellega „rääkida” ja seda küsitleda. Seega on jaotussüsteem skriptide kogum iga eraldi arvesti jaoks. Andmebaas, kus kõike seda hoitakse. Ja mingisugune kasutajaliides, milles ta suudab koostada talle vajaliku aruande.

See ei paista keeruline. Saatan peitub, nagu alati, detailides.

Alustame esimesest osast.

Skripti

Kuidas neid kirjutada? No, ilmselt peate ostma mõõteseadme, selle lahti võtma, õppima sellega suhtlema ja integreerima selle üldisesse platvormi.

Kahjuks katab see lahendus vaid osa meie vajadustest. Tüüpiliselt on populaarsetel arvutitel mitmeid põlvkondi, ja iga põlvkonna skript võib erineda. Mõnikord veidi, mõnikord oluliselt. Ostes midagi, saad sa viimase põlvkonna. Ent abonendil on suure tõenäosusega vanem seade. See ei müüda enam poodides. Ja abonent ei vaheta arvestit.

Sealt tuleb esimene probleem. Selliste skriptide kirjutamine nõuab tihedat koostööd tarkvaraarendajate ja inseneride vahel „maapealses” keskkonnas. Ostame viimase põlvkonna, kirjutame mingi algse mall ja seejärel muudame seda reaalses seadmes. Sellist tööd laboratooriumis teha on võimatu, ainult reaalses koostöös elavate abonentidega.

Meil kulus pikka aega sellise koostöö loomisele. Praegu on algoritm väljatöötatud. Algseid malle on pidevalt muudetud ja täiendatud vastavalt sellele, mida oma praktikas kohtasime. Loomulikult teavitati abonenti, kui tema arvesti osutus natuke „teistsuguseks”. Kui selline seade ilmneb, ühendatakse see standardse skeemi järgi ning küsitluse skripti muudetakse protsessi käigus. Integreerimise ajal töötab abonent tasuta. Teda teavitatakse, et ta elab praegu katseaegadel. Ise integreerimisprotsess on üsna ettearvamatu. Mõnikord peab tegema minimaalsed parandused. Mõnikord on keeruline protsess, mis nõuab objektile sõitmist, kirjanduse läbi töötamist ja järjestikku takistuste ületamist.

Ülesanne on keeruline, kuid lahendatav. Tulemuseks on töötav skript. Mida suurem on skriptide raamatukogu, seda lihtsam on elada.

Teine probleem.

Ühendamise tehnilised kaardid

Kuna te mõistate, kui keeruline see töö on, toob välja ühe näite. Vaatame äärmiselt populaarset soojusarvestit VKT-7.

Isegi nimi ei ütle meile veel midagi. VKT-7-l on mitmeid riistvaralahendusi. Milline liides tal siis sees on?

On erinevaid variante. Võib olla väljund standardse DB-9 pesaga (see on RS-232). Võib olla ka lihtsalt terminal jaotur RS-485 kontaktidega. Võib isegi olla võrgukaart RJ-45 (sel juhul pakitakse ModBus Ethernetisse).

Võib-olla ei tarvitse üldse midagi. Lihtsalt paljas mõõteseade. Sisse saab paigaldada liidest, mida tootja müüb eraldi ning see maksab raha. Peamine probleem on selles, et selle paigaldamiseks tuleb avada mõõteseade ja rikkuda pitserid. See tähendab, et sellesse protsessi kaasatakse energiaettevõte. Neid teavitatakse, et pitserid eemaldatakse, määratakse päev ja meie insener koos energiaettevõtte esindajaga teeb vajalikud muudatused, pärast mida mõõteseade pitseeritakse uuesti.

Eraisik jaam liidese paigaldamise järgi viiakse edasi. Näiteks otsustasime ühendada mõõteseadmest traadi kaudu. See on kõige lihtsam variant, kui meie lüliti on 100 meetri kaugusel, siis ei ole mõtet LoRa'ga jamada – lihtsam on kaabeldada meie võrku, isoleeritud VLAN-i.

RS-485/232 jaoks on vajalik Etherneti konverter. Paljud meenutavad kohe MOXA-d, aga see on kallis. Meie lahenduste jaoks valisime odavama hiina alternatiivi.

Kui väljund on kohe Ethernet, siis konverterit ei vajata.

Küsimus. Oletame, et paigaldame liidese ise. Kas ei oleks lihtsam ja panna kohe igale poole Ethernet?

See ei ole alati võimalik. Tuleb vaadata korpuse täitvust. Seal võib mitte olla vajalikku auku, et liides paigaldada. Ja mõõteseade, meenutame, on meil keldris. Või katlamajas. Seal on kõrge niiskus, hermeetilisust ei tohi rikkuda. Korpuse lihvimine on halb idee. Paremini on paigaldada midagi, mis ei nõua suuri muudatusi. Tihti on RS-485 ainus lahendus.

Edasi. Kas mõõteseade on ühendatud garanteeritud toiteallikaga? Kui ei, siis töötab see patarei peal. Sellises režiimis on see mõeldud käsitsi küsitamiseks kord kuus kolme minuti jooksul. Pidev pöördumine VKT-7 tühjendab patarei. See tähendab, et on vaja vedada garanteeritud toide ja paigaldada pingemuundur.

Iga mõõteseadme tootja toide erineb. See võib olla väline plokk DIN-riiulile või sisseehitatud muundur.

Tuleb välja, et meie laos peab alati olema erinevate liideste ja toiteplokkide komplekt iga mõõteseadme jaoks. Nomenklatuur on seal muljetavaldav.

Muidugi maksab kõik selle lõpuks abonent. Kuid ta ei ootama kuu, kuni vajalik seade tuleb. Ja tal on vaja hinnangut ühendamiseks siin ja praegu. Nii et tehnoloogiline varu langetatakse meie õlgadele.

Kõik, mida ma kirjeldasin, pannakse selgesse tehnilisse kaardistamisse, et insenerid kohapeal ei mõtleks, millega nad kokku puutuvad ja mis on vajalik selle töötamiseks.

Tehnikakaart on seotud üldise ühendamisreegliga. Lõppude lõpuks on arvuti liitmine meie võrguga vaid üks osa - kommutaatori pordile tuleb lisada VLAN, läbi viia diagnostika ja teha testküsimus. Kogu protsessi püüame võimalikult automatiseerida, et vältida vigu ja mitte kaasata liigseid insenere.

Hästi, oleme kirjutanud tehnikakaardid, eeskirjad ja automatiseerimise. Oleme korraldanud logistika.

Kus veel peidavad end varjatud ohud?

Andmed loetakse ja voolavad andmebaasi.

Abonent ei tunne nende numbrite tõttu ei külma ega kuuma. Tal on vaja aruannet. Soovitavalt sellisel kujul, millega ta on harjunud. Veel parem, kui see on kohe arusaadava aruande kujul, mille ta saab välja printida, allkirjastada ja esitada. Seega on vajalik lihtne ja selge liides, mis näitab teavet mõõdikute kohta ja suudab automaatselt aruande genereerida.

Siin meie loomaaed jätkub. Asi on selles, et aruande vorme on mitu. Oma olemuselt kajastavad nad ühte ja sama (kasutatud soojus), kuid erinevate teede kaudu.

Mõned abonendid esitavad aruande absoluutväärtustes (ehk tarbitud soojuse veerus kajastuvad väärtused alates mõõdiku paigaldamisest), teised delftides (kui kirjutame tarbimise perioodi kohta, ilma et oleks seos algsete väärtustega). Tegelikult kasutavad nad erinevaid standardeid, vaid väljakujunenud praktikat. On juhtumeid, kus abonendid näevad kõiki vajalikke väärtusi (tarbitud soojust, tarnitud ja ära läinud soojusvedelikku, temperatuuride erinevust), kuid aruande veerud ei seisa õiges järjestuses.
Sealt edasi on järgmine samm - aruanne peab olema seadistatav. Ehk siis, abonent valib ise, mis järjekorras see käib ja millised ressursid tema dokumendis on.

Siin on huvitav punkt. Kõik on hästi, kui meie arvesti on õigesti paigaldatud. Kuid juhtub, et paigaldusorganisatsioon on ITPT paigaldamisel eksinud ja seadistanud arvestile vale aja. Oleme kohanud seadmeid, mis arvavad — on 2010. aasta. Meie süsteemis näeks see välja nagu nullnäidud praegusel kuupäeval, samas kui tegelik tarbimine — kui valida 2010. aasta. Siin tulevad abiks delta-d. See tähendab, et me ütleme, et möödunud ööpäeva jooksul on näidatud nii palju.

Tundub, et miks sellised keerukused? Kas on nii raske kella seadistada?

Just see viib VKT-7 puhul arvesti täieliku nullimiseni ja arhiivide kustutamiseni.
Kliendil tuleb tõestada ressurssidele, et ta ei paigaldanud ITPT-d eile, vaid juba viis aastat tagasi.

Ja lõpuks, kirsiks tordil.

Sertifitseerimine

Meil on arvesti, on aruanne. Nende vahel on meie süsteem, mis selle aruande genereerib. Kas usud sellesse?

Mina usun. Aga kuidas tõestada, et meie sees ei muutu midagi, et me ei moonuta väärtusi? See on juba sertifitseerimise küsimus. Küsimuse küsitlus peab olema kindlasti sertifitseeritud, mis tõestab selle erapooletust. Kõik suured süsteemid, nagu LERS, Ma Energeetika ja teised, omavad seda tüüpi sertifikaati. Saime selle ka meie, kuigi see maksab palju ja võtab palju aega.

Muidugi, alati võib nurka lõigata ja osta midagi valmis. Kuid selle eest tuleb arendajale maksta. Ja arendaja võib küsida mitte ainult liitumistasu, vaid ka kuutasu. See tähendab, et me oleme sunnitud tema ka meie tükist osa jagama.

Miks kõik see?

Peamine probleem ei seisne selles. Oma süsteemi arendamine on samuti väga kallis ja tunnistavalt raskem. Kuid see toob kaasa olulise eelise. Me mõistame selgelt, kuidas see töötab. Me saame seda kergesti skaleerida, saame seda kohandada, kui tekib vajadus. Klient saab täielikku teenust, meie poolt on protsessi täielik kontroll.

Just seepärast valisime me teise tee. Sellesse investeerisime aasta meie arendajate ja väljaõppeinseneride elust. Nüüd mõistame selgelt kogu ahelat.

Tagasi vaadates mõistan, et ilma saadud teadmisteta ei saaks ma lihtsalt õigesti tõlgendada mõne arvesti ebatavalist käitumist.

Lisaks saab põhinedes haldustehnoloogiale luua midagi suuremat. Häired, mis tulenevad tarbimise ületamisest, hädaolukordade raport. Meil on varsti tulemas mobiilirakenduse lansseerimine.

Oleme edasi läinud ja meie platvormi (muidu poleks seda nimetada) oleme lisanud võimaluse vastu võtta rahva päringuid, võimaluse juhtida meie „nutikaid fonolukke”, ning kontrollida tänavavalgustust ja veel mõnda projekti, millest ma seni ei ole kirjutanud.

Kõik see on keeruline, ajuväänav ja aeganõudev. Kuid tulemus on seda väärt. Tellijad saavad valmis tervikliku toote.

Iga operaator, kes plaanib liikuda elamute haldusse, peab kindlasti sellele teele astuma. Kas ta läbib selle?
Siin on küsimus. Asi ei ole isegi rahas. Nagu ma varem mainisin, on vajalik töötamise sidumine ja arendamine. Mitte kõik suuremad tegijad ei ole selliseks harjunud. Kui teie arendajad istuvad Moskvas, aga ühendused tehakse Novosibirskis, siis venib teie aeg valmis tooteni märgatavalt.

Aeg näitab, kes jääb turule ja kes ütleb — ei, las see jääb. Kuid ma tean kindlalt ühte asja — turuosa saamine ainult raha abil ei õnnestu. See protsess vajab mittestandardsed lähenemisi, häid insenere, reguleerimise süvitsi kaevamist, suhtlemist ressursside ja tellijatega ning pidevat tõrgete leidmist ja ületamist.

P. S. Selles artiklis keskendusin teadlikult soojusele ja ei maini elektrit ega vett. Kirjeldan kaabliühendust. Kui meil on impulssväljund — seal on oma nüansid, nagu kohustuslikud kontrollid pärast installatsiooni. Võib juhtuda, et kaabliga ei ulatu, siis tuleb mängu LoRaWAN. Kirjeldada meie platvormi ja selle arenduse etappe ühes artiklis on lihtsalt vale.

Allikas: habr.com