Tere, austatud asjade interneti huvilised. Selles artiklis tahaksin taas rääkida eluasemete haldamisest ja mõõteseadmete küsitlusest.
Perioodiliselt teatab järgmine suur telekomimängija, kuidas ta varsti sellele turule siseneb ja kõik enda alla tõmbab. Iga kord selliste lugude puhul mõtlen: "Poisid, edu teile!"
Te isegi ei kujuta ette, kuhu te tungite.
Kuna te mõistaksite probleemi skaala, räägin lühidalt meie kogemusest platvormi "Tark Linn" arendamisel. Just selle osa kohta, mis vastutab dispetcherimise eest.
Üldine idee ja esimesed raskused
Räägides mitte individuaalsetest mõõtmisseadmetest, vaid neist, mis asuvad kelderes, katlamajades ja ettevõtetes, on enamik neist nüüd varustatud telemeetri väljundiga. Harvem impulsi, sagedamini - RS-485/232 või Ethernet. Tava järgi on kõige "kasumlikumad" mõõteseadmed need, mis mõõdavad soojust. Just nende dispetcherimise eest on esimesena valmis maksma.
Olen juba oma artiklis põhjalikult käsitlenud RS-485 eripära. Lühidalt - see on lihtsalt andmete edastamise liides. Tegelikult - nõuded elektriliste impulsside ja sidekanali jaoks. Pakettide kirjeldus toimub ühel tasemel kõrgemal, andmete edastamise standardis, mis töötab RS-485 peal. Ja mis standard see olema hakkab - see on tootja otsustada. Tihti Modbus, aga mitte tingimata. Ieven kui see on Modbus, võib see siiski olla veidi muudetud.
Tegeliselt on iga mõõteseadmest vajalik oma küsitluskava, mis oskab sellega "rääkida" ja seda küsitleda. See tähendab, et dispetcherimise süsteem on skriptide kogum iga eraldi arvesti jaoks. Andmebaas, kus kõik see salvestatakse. Ja mingisugune kasutajaliides, kus saab koostada vajaliku aruande.
See ei näe keeruline välja. Tõde, nagu alati, peitub detailides.
Alustame esimesest osast.
Skriptid
Kuidas neid kirjutada? No, ilmselgelt, tuleb osta mõõteseade, selle seest lahti võtta, õppida, kuidas sellega suhelda ja integreerida see üldisse platvormi.
Kahjuks katab see lahendus vaid osa meie vajadustest. Tavaliselt on populaarsetel arvestitel mitu põlvkonda, ja skript iga põlvkonna jaoks võib erineda. Mõnikord veidi, mõnikord oluliselt. Ostes midagi, saad viimase põlvkonna. Kuid abonendil on tõenäoliselt midagi vanemat. Seda ei müüda enam poodides. Ja abonent ei vaheta arvesti.
Sealt tuleb esimene probleem. Selliste skriptide kirjutamine on tihe seos tarkvaraarendajate ja maapealsete inseneride vahel. Me ostsime viimase põlvkonna, kirjutasime mingi algse šablooni ja seejärel kohandasime seda juba reaalses seadmes. Sellise tegemine laboris on võimatu, ainult töötades elavate abonentidega.
Meil kulus selle sideme loomisele palju aega. Praegu on algoritm välja töötatud. Algse šablooni pidevalt kohandati ja täiendati vastavalt sellele, mida me oma praktikast kohtasime. Loomulikult teavitati abonenti, kui äkki tema arvesti osutus natuke "eriliseks". Kui selline seade ilmub, ühendatakse see standardse skeemi järgi ja küsitlus skripti kohandatakse jooksvalt. Integreerimise ajal töötab abonent tasuta. Teda teavitatakse, et ta elab testrežiimis. Ise integreerimisprotsess on üsna ettearvamatu. Juhtub, et tuleb teha minimaalne muudatus. Juhtub keerulisem protsess, mis hõlmab objekti külastamist, kirjanduse ülevaatamist ja järjestikust takistuste ületamist.
Ülesanne ei ole lihtne, kuid lahendatav. Tulemus - töötav skript. Mida rohkem skriptiraamatukogu on, seda lihtsam on elada.
Teine probleem.
Tehnilised ühenduskaardid
Kuna te mõistaksite selle töö keerukust, toon näite. Võtame äärmiselt populaarse soojusmõõturi VKT-7.
Nimi iseenesest ei räägi meile veel millestki. VKT-7-l on mitu riistvaralist lahendust. Milline liides on tal sees?
On erinevaid variante. See võib olla väljund standardse DB-9 pistiku kaudu (see on RS-232). Võib olla lihtsalt klemmiplokk RS-485 kontaktidega. Võib isegi olla võrgukaart RJ-45 (selle puhul pakitakse ModBus Ethernetisse).
Või ei pruugi olla midagi. Lihtsalt paljas mõõteseade. Sellele võib paigaldada liidesega väljundi, mis müüakse tootja poolt eraldi ja maksab raha. Suurim probleem - selle paigaldamiseks on vajalik arvesti avamine ja pitsatide eemaldamine. See tähendab, et selles protsessis osaleb teenusepakkuja organisatsioon. Teda teavitatakse, et pitsatid eemaldatakse, määratakse päev ja meie insener koos teenusepakkuja esindajaga teeb vajalikud muudatused, peale mida arvesti taas pitsatatakse.
Sõltuvalt paigaldatud liidest toimuvad edasised kohandused. Näiteks, otsustasime ühendada mõõteseadmest juhtme kaudu. See on kõige lihtsam variant, kui 100-meetrise kauguse raadiuses on meie lüliti, siis LoRa kasutamine oleks üleliigne. Lihtsam on kaabli kaudu meie võrku, isolatsiooniga VLAN-i.
RS-485/232 jaoks on vajalik Etherneti konverter. Paljud meenutavad kohe MOXA-d, kuid see on kallis. Meie lahenduste jaoks oleme leidnud odavama Hiina variandi.
Kui väljund on kohe Ethernet, siis konverterit ei ole vaja.
Küsimus. Oletame, et paigaldame ise liidese väljundi. Kas saame endale elu lihtsamaks teha ja kohe igale poole Etherneti paigaldada?
See ei ole alati võimalik. Tuleb tähelepanu pöörata korpuse ehitusele. Sellel ei pruugi olla vajalikke auke, et liides õigesti paigaldada. Ja mõõteseade, nagu me mäletame, asub meil keldris. Või katlamajas. Seal on kõrge niiskus, tihedust ei tohi rikkuda. Korpuse lihvimine viiliga on halb idee. Parem on paigaldada midagi, mis algselt ei vaja suuri muudatusi. Tihti on RS-485 ainus lahendus.
Edasi. Kas mõõteseade on ühendatud garanteeritud toiteallikaga? Kui ei, siis töötab see patarei pealt. Sellises režiimis on see mõeldud käsitsi küsimiseks kord kuus kolmeks minutiks. Pidev pöördumine VKТ-7 poole tühjendab selle patarei. See tähendab, et tuleb viia garanteeritud toide ja paigaldada pingemuundur.
Iga mõõteseadme tootja toiteplokk on erinev. See võib olla välistoiteplokk DIN-raami jaoks või sisse ehitatud muundur.
Tuleb välja, et meie laos peab alati olema erinevate liideste ja toiteplokkide komplekt igasuguste mõõteseadmete jaoks. Nomenklatuur on seal muljetavaldav.
Loomulikult maksab kõik selle lõpuks tellija. Kuid ta ei taha oodata kuud, kuni vajalik seade arrives. Ja tal on vaja hinnangut ühendamiseks siin ja praegu. Seetõttu lasub tehnoloogiline varu meie õlgadel.
Kõik, mida ma kirjeldasin, koondub selgesse tehnilisse kaardisse ühendamiseks, et insenerid kohtades ei arvaks, mis loomaga nad kohtuvad järgmises keldris ja mida neil on selle tööks vaja.
Tehniline kaart on koos üldiste reeglitega ühendamiseks. Lõppude lõpuks pole mõõteseadet lihtsalt meie võrku sisse lülitada, tuleb veel porti teenusesse lisada see VLAN, conduct diagnostics, teha katse küsitlus. Kogu protsessi püüame maksimaalselt automatiseerida, et vigu vältida ja mitte kaasata liigseid insenere.
Hästi, oleme koostanud tehnilised kaardid, määratlenud reeglid, automatiseerinud. Oleme seadnud logistika tööle.
Kus veel peituvad allveekivid?
Andmed loetakse ja voolavad andmebaasi.
Tellijale ei ole nende numbrite järgi ei soe ega külm. Talle on vajalik aruanne. Soovitavalt sellisel kujul, nagu ta on harjunud. Veel parem, kui see on kohe arusaadavas aruandes, mille ta saab printida, allkirjastada ja esitada. Seega on vajalik lihtne ja arusaadav liides, mis näitab teavet mõõteseadmest ja suudab automaatselt aruande koostada.
Siin jätkub meie loomaaed. Fakt on see, et aruande vorme on mitu. Oma olemuselt peegeldavad nad ühte ja sama (tarbitud soojust), kuid erinevaid teid.
Mõned tellijad esitavad aruande absoluutsetes väärtustes (st soojuse tarbimise veerus on toodud väärtused, alates mõõteseadmest), mõned diffeentsides (see on siis, kui kirjutame tarbimise ajavahemikule ilma alustavate väärtuste viiteta). Sisuliselt kasutatakse mitte ühtseid standardeid, vaid väljakujunenud praktikat. On olnud juhtumeid, kui tellijad näevad kõiki neid väärtusi, mis neile on vajalikud (tarbitud soojust, soojusvedeliku mahud, temperatuuride erinevus), kuid veerud aruandes ei seisa õiges järjestuses.
Seega on järgmine samm – aruanne peab olema kohandatav. See tähendab, et tellija valib ise, millises järjekorras see käib ja millised ressursid on tema dokumendis.
Siin on huvitav moment. Kõik on hästi, kui meie mõõteseade on õigesti paigaldatud. Kuid juhtub, et paigaldusorganisatsioon eksib ja paigaldab ITP vale ajaga. Oleme kohanud seadmeid, mis arvavad, et on 2010. aasta. Meie süsteemis näib see olevat nullnäidud praegusele kuupäevale ja tegelik tarbimine oleks, kui valida 2010. aasta. Siin aitavad väga palju diferentid. See tähendab, et me ütleme, et eelmisel päeval oli tarbimine nii palju.
Tundub, et milleks sellised raskused? Kas on nii raske kellad korraldada?
Just see VKТ-7 puhul toob see mõõteseadmest täieliku nullimise ja arhiivide kustutamise.
Tellija peab tõestama ressursside seadusele, et ta paigaldas ITP mitte eile, vaid juba viie aasta eest.
Ja lõpuks, tordil kirsiks.
Sertifitseerimine
Meil on arvestusseade, meil on raport. Nende vahel on meie süsteem, mis seda raportit genereerib. Kas usute sellesse?
Mina usun küll. Kuid kuidas tõestada, et meie sees ei muutu midagi, et me ei moonuta väärtusi? See on juba sertifitseerimise küsimus. Uuringusüsteem peab olema sertifikaat, mis kinnitab selle erapooletust. Kõik suured süsteemid, nagu LERS, Я Энергетик ja teised, omavad sarnast sertifikaati. Meie saime selle ka, kuigi see maksab palju ja võtab aega.
Loomulikult on alati võimalik nurka lõigata ja osta midagi valmiskujul. Kuid selle eest tuleb arendajale maksta. Ja arendaja võib küsida mitte ainult sisenemiseks tasu, vaid ka kuutasu. See tähendab, et me peame jagama temaga osa meie kasumist.
Miks kõik see?
Peamine probleem ei seisne isegi selles. Oma süsteemi arendamine on samuti väga kallis ja tunduvalt keerulisem. Siiski, see annab olulise eelise. Me mõistame selgelt, kuidas see töötab. Me saame seda hõlpsasti skaleerida ja modifitseerida, kui vajame. Klient saab täielikuma teenuse ning meie poolt on protsessi täielik kontroll.
Just seetõttu valisime me teise tee. Sellesse investeerisime ühe aasta oma arendajate ja välitehniliste inseneride elust. Tulemuseks on suur selgus kogu ahela tööprotsessis.
Tagasi vaadates mõistan, et saadud teadmistega ei oleks ma suutnud õigesti tõlgendada mõne arvesti ebatavalist käitumist.
Lisaks sellele saab logistikasüsteemi põhjal luua midagi suurt. Alarmid tarbimise ületamise kohta, avariiraportid. Meie lähiajal on valmimas mobiilirakendus.
Oleme läinud veel kaugemale ja meie platvormile (muidu ei saaks seda nii nimetada) on lisatud võimalus vastu võtta elanike pöördumisi, hallata meie "nutikaid uksesüsteeme", samuti tänavavalgustuse kontroll ja veel mõned projektid, millest ma pole veel rääkinud.
Kõik see on keeruline, ajumurdmis- ja aeganõudev. Kuid tulemus on seda väärt. Klientidel on valmistoode kõik-ühes.
Iga operaator, kes plaanib siseneda korteriomanike turule, peab kindlasti sellele teele astuma. Kas nad suudavad sellega hakkama saada?
See on küsimus. Asi ei ole isegi rahas. Kuidas ma varem ütlesin, on siin vajalik just välitöö ja arenduse side. Mitte kõik suured mängijad pole sellise lähenemisega harjunud. Kui teie arendajad istuvad Moskvas ja ühendused tehakse Novosibirskis, siis venib teie valmistoote saamise aeg märkimisväärselt.
Aeg näitab, kes jääb sellele turule ja kes ütleb — las see minna! Kuid ma tean ühte kindlat — ainult rahaga turuosa saavutamine ei õnnestu. See protsess nõuab mittestandardseid lähenemisi, häid insenere, regulatsioonide süvaanalüüsi, suhtlemist teenusepakkujatega ja klientidega ning pidevat probleemide avastamist ja ületamist.
P. S. Selles artiklis keskendusin teadlikult soojusele ega maini elektrit ega vett. Samuti kirjeldan ma kaabliga ühendamist. Kui meil on impulsi väljund — siis on seal omad nüansid, nagu kohustuslikud kontrollid paigaldamise järel. Võib juhtuda, et kaabliga ei ulatu, siis tuleb kasutada LoRaWANi. Kogu meie platvormi ja selle arendusprotsessi kirjeldamine ühes artiklis on lihtsalt võimatu.
Allikas: habr.com
