Sveiki, brangūs daiktų interneto gerbėjai. Šiame straipsnyje norėčiau dar kartą pakalbėti apie būsto ir komunalines paslaugas bei apskaitos prietaisų tyrimą.
Periodiškai kitas stambus telekomunikacijų žaidėjas pasakoja, kaip greitai jis įeis į šią rinką ir sutriuškins visus po jomis. Kiekvieną kartą su tokiomis istorijomis galvoju: „vaikinai, sėkmės!
Tu net nežinai, kur eini.
Kad suprastumėte problemos mastą, trumpai aprašysiu nedidelę dalį mūsų patirties kuriant Smart City platformą. Ta jo dalis, kuri yra atsakinga už siuntimą.
Bendra idėja ir pirmieji sunkumai
Jei mes kalbame ne apie atskirus apskaitos prietaisus, o tuos, kurie yra rūsiuose, katilinėse ir įmonėse, tai dabar daugumoje jų yra telemetrinė išvestis. Rečiau impulsinis, dažniau - RS-485/232 arba Ethernet. Paprastai „duonos“ matavimo prietaisai yra tie, kuriuose atsižvelgiama į šilumą. Pirmiausia jie yra pasirengę mokėti už jų išsiuntimą.
Aš jau išsamiai apsigyvenau savo straipsnyje apie RS-485 ypatybes. Trumpai tariant, tai tik duomenų sąsaja. Tiesą sakant, reikalavimai elektros impulsams ir ryšio linijoms. Paketų aprašymas yra aukštesnis duomenų perdavimo standarte, kuris veikia kartu su RS-485. O kas ten bus už standartą – tai gamintojo malonė. Dažnai Modbus, bet nebūtinai. Net jei „Modbus“, jis vis tiek gali būti šiek tiek pakeistas.
Tiesą sakant, kiekvienam matavimo įrenginiui reikia savo apklausos scenarijaus, kuris galėtų su juo „kalbėti“ ir jį apklausti. Tai reiškia, kad siuntimo sistema yra kiekvieno atskiro skaitiklio scenarijų rinkinys. Duomenų bazė, kurioje visa tai saugoma. Ir tam tikra vartotojo sąsaja, kurioje jis gali sugeneruoti jam reikalingą ataskaitą.
Atrodo lengva. Velnias, kaip visada, slypi detalėse.
Pradėkime nuo pirmosios dalies.
Scenarijai
Kaip juos parašyti? Na, aišku, nusipirkite skaitiklį, atidarykite jį, išmokite su juo bendrauti ir integruoti į bendrą platformą.
Deja, šis sprendimas patenkins tik dalį mūsų poreikių. Paprastai populiarus skaitiklis turi keletą kartų, o kiekvienos kartos scenarijus gali skirtis. Kartais mažai, kartais daug. Kai ką nors perki, gauni naujausios kartos. Abonentas, su didele tikimybe, turės kažką senesnio. Parduotuvėse ji nebeparduodama. O abonentas nekeis apskaitos mazgo.
Taigi pirmoji problema. Rašyti tokius scenarijus yra sunki programinės įrangos kūrėjų ir inžinierių krūva „ant žemės“. Nusipirkome naujausios kartos, parašėme tam tikrą pradinį šabloną ir modifikavome jį tikruose įrenginiuose. Nerealu tai padaryti laboratorijoje, tik dirbant su tiesioginiais abonentais.
Mums prireikė daug laiko sukurti tokį paketą. Dabar algoritmas yra parengtas. Pradiniai šablonai buvo nuolat taisomi ir papildomi, priklausomai nuo to, su kuo susidūrėme savo praktikoje. Žinoma, abonentas buvo įspėtas, jei staiga jo skaitiklis pasirodė šiek tiek „ne toks“. Kai atsiranda toks įrenginys, jis prijungiamas pagal standartinę schemą ir pakeliui keičiamas apklausos scenarijus. Integracijos laikotarpiu abonentas dirba nemokamai. Jam pranešama, kad jis vis dar gyvena bandomuoju režimu. Pats integracijos procesas yra gana nenuspėjamas dalykas. Kartais reikia atlikti minimalius pataisymus. Vyksta sudėtingas procesas su apsilankymu objekte, literatūros kastuvu ir nuosekliu grėblio įveikimu.
Užduotis nėra lengva, bet išsprendžiama. Rezultatas yra darbo scenarijus. Kuo didesnė scenarijų biblioteka, tuo lengviau gyventi.
Antra problema.
Technologinės jungties kortelės
Kad suprastumėte šio darbo sudėtingumą, pateiksiu pavyzdį. Paimkime itin populiarų šilumos skaitiklį VKT-7.
Pats pavadinimas mums nieko nesako. VKT-7 turi keletą techninės įrangos sprendimų. Kokia sąsaja jo viduje?
Yra įvairių variantų. Standartiniame DB-9 bloke (tai yra RS-232) gali būti išvestis. Gal tik gnybtų blokas su RS-485 kontaktais. Galbūt net tinklo plokštė su RJ-45 (šiuo atveju ModBus yra supakuota į Ethernet).
O gal visai nieko. Tik plikas metras. Jame galite įdiegti sąsajos išvestį, ją gamintojas parduoda atskirai ir kainuoja. Pagrindinė bėda ta, kad norint jį sumontuoti reikia atidaryti skaitiklį ir sulaužyti plombas. Tai reiškia, kad išteklius tiekianti organizacija yra įtraukta į šį procesą. Jai pranešama, kad plombos bus sulaužytos, paskiriama diena ir mūsų inžinierius, dalyvaujant resursų darbuotojų atstovui, atlieka reikiamus patobulinimus, po kurių skaitiklis vėl užplombuojamas.
Priklausomai nuo įdiegtos sąsajos, atliekamas tolesnis tobulinimas. Pavyzdžiui, mes nusprendėme prijungti skaitiklį laidu. Tai yra paprasčiausias variantas, jei mūsų jungiklis yra 100 metrų atstumu, tada gudrauti su LoRa yra nereikalinga. Paprasčiau naudojant laidą į mūsų tinklą, į izoliuotą VLAN.
RS-485/232 reikalingas keitiklis į Ethernet. Daugelis iš karto prisimins MOHA, bet ji brangi. Savo sprendimams pasirinkome pigesnį kinišką sprendimą.
Jei išvestis iš karto yra Ethernet, keitiklio nereikia.
Klausimas. Tarkime, kad sąsajos išvestį nustatome patys. Ar galite palengvinti savo gyvenimą ir iš karto įdiegti Ethernet visur?
Tai ne visada įmanoma. Turime pažvelgti į kūno vykdymą. Jis gali neturėti tinkamos skylės, kad sąsaja atsistotų taip, kaip turėtų. O skaitiklis, primenu, yra mūsų rūsyje. Arba katilinėje. Yra didelė drėgmė, sandarumas negali būti pažeistas. Užbaigti bylą su byla yra bloga idėja. Geriau įdėti tai, kas iš pradžių nereikalauja didelių pakeitimų. Dažnai – RS-485 yra vienintelė išeitis.
Toliau. Ar skaitiklis prijungtas prie garantinio maitinimo šaltinio? Jei ne, tada jis gyvena iš baterijų. Šiuo režimu jis skirtas rankiniam balsavimui kartą per mėnesį tris minutes. Nuolat pasiekiant CGT-7, jo baterija išsikraus. Taigi, reikia ištraukti garantuotą maitinimo šaltinį ir sumontuoti įtampos keitiklį.
Kiekvieno skaitiklių gamintojo maitinimo modulis yra skirtingas. Tai gali būti išorinis įrenginys ant DIN bėgio arba įmontuotas keitiklis.
Pasirodo, mūsų sandėlyje visada turėtų būti saugomas įvairių sąsajų ir maitinimo modulių rinkinys kiekvienam skaitikliui. Asortimentas ten įspūdingas.
Žinoma, už visa tai galiausiai sumokės abonentas. Tačiau jis nelauks mėnesio, kol ateis tinkamas įrenginys. Ir jam reikia sąmatos, kaip prisijungti čia ir dabar. Taigi technologinis rezervas krenta ant mūsų pečių.
Viskas, ką aprašiau, virsta aiškia techninio ryšio kortele, kad vietiniai inžinieriai negalvotų, kokį gyvūną sutiko kitame rūsyje ir ko jiems reikia, kad jis veiktų.
Techninis žemėlapis yra greta bendrųjų prisijungimo taisyklių. Juk neužtenka įtraukti skaitiklį į mūsų tinklą, vis tiek reikia mesti tą patį VLAN į jungiklio prievadą, reikia atlikti diagnostiką, atlikti bandomąją apklausą. Stengiamės kiek įmanoma labiau automatizuoti visą procesą, kad išvengtume klaidų ir neįtrauktume nereikalingų inžinierių jėgų.
Na, rašėme techninius žemėlapius, reglamentus, automatiką. Nustatykite logistiką.
Kur dar yra paslėptų spąstų?
Duomenys nuskaitomi ir įkeliami į duomenų bazę.
Abonentas iš šių skaičių nėra karštas ar šaltas. Jam reikia ataskaitos. Pageidautina tokia forma, kokia jis yra įpratęs. Dar geriau, jei iš karto jam suprantama ataskaita, kurią gali atsispausdinti, pasirašyti ir pateikti. Tai reiškia, kad jums reikia paprastos ir suprantamos sąsajos, rodančios informaciją apie skaitiklį ir galinčios automatiškai generuoti ataskaitą.
Čia mūsų zoologijos sodas tęsiasi. Faktas yra tas, kad yra keletas ataskaitos formų. Iš esmės jie atspindi tą patį (suvartotą šilumą), bet skirtingais būdais.
Kai kurie abonentai praneša absoliučiomis reikšmėmis (ty vertės rašomos šilumos suvartojimo stulpelyje nuo skaitiklio įrengimo), kažkas deltomis (tai kai rašome suvartojimą tam tikram laikotarpiui nenurodant pradinių verčių). Tiesą sakant, jie taiko ne vienodus standartus, o nusistovėjusią praktiką. Buvo atvejų, kai abonentai mato visas jiems reikalingas reikšmes (suvartotos šilumos kiekį, tiekiamo ir dingusio aušinimo skysčio kiekį, temperatūros skirtumą), tačiau ataskaitos stulpeliai yra neteisinga seka.
Taigi kitas žingsnis – ataskaita turi būti pritaikoma. Tai yra, abonentas pats pasirenka, kas kokia seka ir kokie ištekliai yra jo dokumente.
Čia yra įdomus momentas. Viskas gerai, jei mūsų skaitiklis sumontuotas teisingai. Tačiau atsitinka taip, kad diegimo organizacija, diegdama ITP, suklydo ir neteisingai nustatė skaitiklio laiką. Matėme įrenginių, kurie mano, kad 2010 m. Mūsų sistemoje tai atrodys kaip nulis dabartinės datos rodmenys ir realus suvartojimas, jei pasirinksime 2010 m. Čia praverčia deltos. Tai yra, mes sakome, kad per pastarąją dieną buvo tiek daug dalykų.
Atrodytų, kam tokie sunkumai? Ar taip sunku susukti laikrodį?
Būtent naudojant VKT-7 bus visiškai iš naujo nustatytas skaitiklis ir iš jo bus pašalinti archyvai.
Abonentas bus priverstas resursų valdytojams įrodyti, kad ITP įdiegė ne vakar, o maždaug prieš penkerius metus.
Ir pabaigai – vyšnia ant torto.
Pažymėjimas
Turime skaitiklį, turime ataskaitą. Tarp jų yra mūsų sistema, kuri generuoja šią ataskaitą. Ar tu ja tiki?
aš taip. Bet kaip įrodyti, kad mūsų viduje niekas nesikeičia, kad mes neiškreipiame prasmės. Tai sertifikavimo reikalas. Balsavimo sistema turi turėti sertifikatą, patvirtinantį jos nešališkumą. Visos didelės sistemos, tokios kaip LERS, Ya Energetik ir kitos, turi panašų sertifikatą. Gavome ir mes, nors brangu ir daug laiko atima.
Žinoma, visada galite nupjauti kampus ir nusipirkti ką nors paruošto. Tačiau kūrėjas turės už tai sumokėti. O kūrėjas gali prašyti ne tik įėjimo, bet ir mėnesinio mokesčio. Tai yra, mes būsime priversti pasidalinti su juo savo pyrago dalimi.
Kodėl viskas?
Pagrindinė problema yra ne tai. Sukurti savo sistemą taip pat labai brangu ir daug kartų sunkiau. Tačiau tai suteikia svarbų pranašumą. Mes aiškiai suprantame, kaip tai veikia. Mes jį nesunkiai padidiname, galime modifikuoti, jei staiga atsiranda toks poreikis. Abonentas gauna pilnesnę paslaugą, o iš mūsų pusės – šimtaprocentinę proceso kontrolę.
Todėl ir pasirinkome antrąjį kelią. Į jį investavome metus savo kūrėjų ir lauko inžinierių. Bet dabar mes aiškiai suprantame visos grandinės darbą.
Žvelgdamas atgal suprantu, kad be įgytų žinių tiesiog negalėjau teisingai interpretuoti konkretaus skaitiklio nenormalaus elgesio.
Be to, dispečerinės sistemos pagrindu galima sukurti kažką daugiau. Vartojimo pertekliaus signalizacija, avarijos ataskaita. Greitai turėsime mobiliąją programėlę.
Mes nuėjome dar toliau ir papildėme savo platformą (kitaip to nepavadinsi) galimybe gauti gyventojų užklausas, galimybę valdyti savo „išmaniuosius telefonspynes“, iš karto valdyti gatvių apšvietimą ir dar keletą projektų, kuriuos aš apie tai dar nerašiau.
Visa tai sudėtinga, laužanti smegenis ir ilga. Bet rezultatas to vertas. Prenumeratoriai gauna paruoštą visapusišką produktą.
Kiekvienas operatorius, planuojantis eiti į būsto ir komunalines paslaugas, tikrai imsis šiuo keliu. Ar praeis?
Čia yra klausimas. Tai net ne apie pinigus. Kaip jau rašiau aukščiau, čia reikia darbo šioje srityje ir tobulėjimo derinio. Ne visi pagrindiniai žaidėjai prie to yra pripratę. Jei jūsų kūrėjai yra Maskvoje, o ryšiai užmegzti Novosibirske, tada jūsų laikas gatavam produktui gerokai pailgėja.
Laikas parodys, kas išsilaikys šioje rinkoje, o kas pasakys – va, jis pateko į pragarą! Bet aš tikrai žinau vieną dalyką, kad ateiti ir užimti rinkos dalį vien pinigais nepavyks. Šis procesas reikalauja netradicinių požiūrių, gerų inžinierių, įsigilinimo į reguliavimą, bendravimo su išteklių valdytojais ir abonentais, nuolatinio identifikavimo ir grėblio įveikimo.
PS Šiame straipsnyje aš sąmoningai sutelkiau dėmesį į šilumą ir nemini elektros ar vandens. Taip pat aprašiau kabelio jungtį. Jei turime impulsų išvestį, yra keletas niuansų, pavyzdžiui, privalomi suderinimai po įdiegimo. Gali būti, kad laido nepavyksta pasiekti, tada naudojamas LoRaWAN. Aprašyti visą mūsų platformą ir jos kūrimo etapus viename straipsnyje tiesiog nerealu.
Šaltinis: www.habr.com