Anteckningar från IoT-leverantören. Fallgropar i mätarundersökningen för bostadsräkningar.

Hej, kära entusiastiska av Internet of Things. I den här artikeln vill jag återigen diskutera frågor inom bostadsförvaltning och mätinstrumentens datainsamling.

Periodiskt berättar en ny stor aktör inom telekom hur snart de kommer att gå in på denna marknad och ta kontroll över den. Varje gång jag hör sådana berättelser tänker jag: "Lycka till, grabbar!"
Ni har ingen aning om vad ni ger er in på.

För att ni ska förstå omfattningen av problemet, låt mig kort berätta en del av vår erfarenhet av utvecklingen av plattformen "Smart Stad". Den del som ansvarar för datainsamling.

Den allmänna idén och de första svårigheterna

Om vi pratar om gemensamma mätinstrument som finns i källare, värmekraftverk och företag, så är en stor del av dem nu utrustade med telemetrisk utgång. Sällan impulsutgång, som oftast är RS-485/232 eller Ethernet. Som regel är de mest "lönsamma" mätinstrumenten de som mäter värme. Det är för deras datainsamling man är mest villig att betala.
Jag har redan detaljerat diskuterat egenskaperna hos RS-485 i min artikel. Kort sagt — det är bara en datakommunikationsgränssnitt. I huvudsak handlar det om krav på elektriska impulser och kommunikationslinje. Paketbeskrivningen kommer på en högre nivå, i datakommunikationsstandarden som fungerar ovanpå RS-485. Och vilken standard det blir — det överlämnas till tillverkaren. Oftast Modbus, men inte nödvändigtvis. Även om det är Modbus kan den ändå vara något modifierad.

I grund och botten behöver varje mätinstrument sitt eget insamlingesskript som kan "prata" med det och hämta data. Det betyder att datainsamlingssystemet är en uppsättning skript för varje individuell mätare. En databas där allt detta lagras. Och en användargränssnitt där användaren kan skapa den rapport som han behöver.

Det ser inte svårt ut. Djävulen ligger, som alltid, i detaljerna.

Låt oss börja med den första delen.

Skript

Hur skriver man dem? Tja, uppenbarligen, köp ett mätinstrument, öppna det, lär dig att kommunicera med det och integrera det i den övergripande plattformen.

Tyvärr täcker denna lösning bara en del av våra behov. Vanligtvis har en populär mätare flera generationer, och skriptet för varje generation kan skilja sig åt. Ibland lite, ibland betydligt. När du köper något får du den senaste generationen. Den abonnent som använder mätaren har troligen något äldre. Det finns inte längre i butikerna. Och abonnenten kommer inte att byta ut mätaren.

Härifrån uppstår det första problemet. Att skriva sådana skript kräver en nära koppling mellan mjukvaruutvecklare och ingenjörer "på fältet". Vi köpte den senaste generationen, skrev en viss grundmall och modifierade den sedan på verkliga enheter. Att göra detta i ett laboratorium är omöjligt, det kan endast göras under arbetet med riktiga abonnenter.

Vi la ner mycket tid på att skapa en sådan koppling. Nu är algoritmen mer eller mindre etablerad. Grundmallarna har ständigt korrigerats och kompletterats, beroende på vad vi har stött på i vår praktik. Självklart informerades abonnenten om det skulle visa sig att deras mätare var något "annorlunda". När en sådan enhet dyker upp, ansluts den enligt standardproceduren och skriptet för avläsning modifieras under loppet av arbetet. Under integreringstiden arbetar abonnenten kostnadsfritt. De informeras om att de för tillfället lever i testläge. Själva integreringsprocessen är ganska oförutsägbar. Ibland krävs det minimala justeringar. Ibland är det en komplicerad process med fältbesök, genomgång av litteratur och steg-för-steg övervinna hinder.

Uppgiften är inte enkel, men lösbar. Resultatet blir ett fungerande skript. Ju större biblioteket av skript är, desto lättare blir det att arbeta.

Det andra problemet.

Tekniska anslutningskarter

För att förstå komplexiteten i detta arbete, låt mig ge ett exempel. Vi tar en extremt populär värmemätare, VKT-7.

Själva namnet säger oss inte så mycket. VKT-7 har flera hårdvarulösningar. Vilken typ av gränssnitt har den inuti?

Det finns olika alternativ. Det kan vara utgång i en standardanslutning DB-9 (det vill säga RS-232). Det kan vara en enkel klämblock med RS-485-kontakter. Det kan till och med vara ett nätverkskort med RJ-45 (i så fall packas ModBus i Ethernet).

Eller kanske ingenting alls. Bara en naken mätare. En gränssnittutgång kan installeras, den säljs separat av tillverkaren och kostar pengar. Huvudproblemet är att installationen kräver att mätaren öppnas och förseglingarna bryts. Det vill säga, detta inkluderar leverantören av resurser. De informeras om att förseglingarna kommer att brytas, en dag utsetts och vår ingenjör utför de nödvändiga ändringarna i närvaro av representanten från leverantören, varefter mätaren återigen förseglas.

Beroende på det installerade gränssnittet utförs vidare modifikationer. Till exempel, vi bestämde oss för att ansluta mätaren med kabel. Det är det enklaste alternativet, om det finns en vår switch inom 100 meter, är det överflödigt att krångla med LoRa. Det är enklare att använda kabel till vårt nätverk, i en isolerad VLAN.

För RS-485/232 behövs en konverterare till Ethernet. Många kommer genast att tänka på MOXA, men det är dyrt. För våra lösningar har vi valt en kinesisk lösning som är billigare.

Om utgången är direkt till Ethernet behövs ingen konverterare.

Fråga. Anta att vi installerar gränssnittutgången själva. Kan vi förenkla livet och direkt installera Ethernet överallt?

Det är inte alltid möjligt. Man måste titta på fallets utformning. Det kanske inte finns något hål som gör att gränssnittet får plats som det ska. Och mätaren, påminner jag om, finns i vår källare. Eller i pannrummet. Där är det hög luftfuktighet och man får inte bryta lufttätheten. Att modifiera kroppen med en fil är en dålig idé. Det är bättre att installera något som från början inte kräver stora omarbetningar. Ofta är RS-485 den enda utgången.

Vidare. Är mätaren kopplad till säker strömförsörjning? Om inte, lever den på batteri. I detta läge är den avsedd för manuell avläsning en gång i månaden i tre minuter. Att ständigt använda VK-7 skulle tömma batteriet. Det betyder att man måste dra säker strömförsörjning och installera en spänningskonverterare.

För varje mätartillverkare skiljer sig strömmodulen. Det kan vara en extern enhet för DIN-skena eller en inbyggd konverterare.

Det blir så att vår lagring alltid måste ha en uppsättning av olika gränssnitt och strömmoduler för varje mätare. Sortimentet där är imponerande.

Självklart, i slutändan betalar abonnenten för allt detta. Men han kommer inte att vänta en månad på att den nödvändiga enheten ska anlända. Han behöver en kostnadskalkyl för anslutningen här och nu. Så det tekniska ansvaret faller på våra axlar.

Allt jag har beskrivit sammanfattas i en tydlig teknisk anslutningskarta, så att ingenjörer på plats inte behöver undra vilken typ av utrustning de har att göra med i det senaste källarutrymmet och vad som krävs för att få det att fungera.

Teknikkartan ligger intill den allmänna anslutningsreglementet. Det är nämligen inte tillräckligt att bara koppla in mätaren i vårt nätverk; VLAN måste också läggas till på porten, diagnoser måste göras och en testkälla krävs. Hela processen strävar vi efter att automatisera maximalt för att undvika misstag och inte belasta ingenjörerna i onödan.

Bra, teknikkartor, reglemente och automatisering är skrivna. Logistik har etablerats.

Var finns det fler dolda fällor?

Data läses av och flödar in i databasen.

För abonnenten påverkar dessa siffror varken värme eller kyla. Han behöver en rapport. Helst i det format han är van vid. Det är ännu bättre om det direkt kommer som en begriplig rapport som han kan skriva under och lämna in. Det betyder att vi behöver ett enkelt och förståeligt gränssnitt som visar information om mätutrustningen och kan skapa rapporter automatiskt.

Här fortsätter vår växande flora. Faktum är att det finns flera rapportformat. I sin grundreflekterar de samma sak (förbrukad värme), men på olika sätt.

Några abonnenter rapporterar i absoluta värden (dvs i kolumnen för värmeförbrukning skrivs siffror, från installationen av mätaren), andra i skillnader (det är när vi skriver förbrukningen för en tidsperiod utan koppling till startvärdena). I praktiken används inte enhetliga standarder, utan befintlig praxis. Det har förekommit fall där abonnenter ser alla de värden de behöver (antalet förbrukad värme, volymen av tillfört och avlett värmebärare, temperaturskillnader), men kolumnerna i rapporten visas inte i rätt ordning.
Därifrån blir nästa steg att rapporten måste vara anpassningsbar. Det betyder att abonnenten själv väljer vilken sekvens innehållet ska ha och vilka resurser som finns i hans dokument.

Här är en intressant punkt. Allt går bra om vår mätare är korrekt installerad. Men det händer att installationsföretaget har gjort fel vid installationen av ITP och felaktigt ställt in tiden för mätaren. Vi har träffat på enheter som tror att det är år 2010. I vårt system skulle detta se ut som nollställningsavläsningar på det aktuella datumet, medan det verkliga förbrukningen skulle visas om man valde år 2010. Här hjälper deltaberäkningar mycket. Det vill säga att vi säger att under de senaste 24 timmarna har det registrerats så mycket.

Man skulle kunna undra, varför så många komplikationer? Är det så svårt att justera klockor?

Just med VKT-7 kan detta leda till en fullständig nollställning av mätaren och radering av arkiv från den.
Användaren kommer att tvingas bevisa för leverantörerna att han installerade ITP för länge sedan, snarare än igår.

Och slutligen, pricken över i:t.

Certifiering

Vi har en mätare och en rapport. Mellan dem finns vårt system, som tar fram den rapporten. Litar du på det?

Jag gör det. Men hur kan man bevisa att vi inte ändrar något internt, att vi inte förvanskar värdena? Det handlar redan om certifiering. Systemet för datainsamling måste nödvändigtvis ha ett certifikat som bekräftar dess objektivitet. Alla stora system, som LERS, Jag Energetiker och liknande, har ett sådant certifikat. Vi fick det också, även om det är dyrt och tar mycket tid.

Självklart kan man alltid ta en genväg och köpa något färdigt. Men det får man betala för till utvecklaren. Och utvecklaren kan kräva inte bara en inträdesavgift utan också en abonnemangsavgift. Det vill säga vi kommer att vara tvungna att dela en del av vår kaka med dem.

Vad är poängen med allt detta?

Det största problemet ligger inte där. Att utveckla sitt eget system är också mycket dyrt och oändligt mer komplicerat. Men det ger en viktig fördel. Vi förstår exakt hur det fungerar. Vi kan enkelt skala upp det, vi kan modifiera det om behovet skulle uppstå. Användaren får en mer komplett tjänst, och från vår sida får vi hundraprocentig kontroll över processen.

Det är exakt därför vi valde den andra vägen. Vi har investerat ett år av våra utvecklares och fältteknikers liv i det. Men nu förstår vi tydligt hur hela kedjan fungerar.

När jag ser tillbaka inser jag att utan de kunskaper jag fått skulle jag helt enkelt inte kunna tolka onormalt beteende hos olika mätare korrekt.

Dessutom kan man bygga något mer på grundval av systemet för dispatcher. Larm om överträdelser av förbrukningen, rapporter om olyckor. Snart lanseras vår mobilapplikation.

Vi har gått ett steg längre och lagt till möjligheten att ta emot ärenden från invånarna i vår plattform (annars kan man inte kalla det så), möjlighet att styra våra "smarta dörrtelefoner", kontroll av gatubelysning och ytterligare några projekt som jag inte har skrivit om ännu.

Allt detta är komplicerat, tankekrävande och tidtagande. Men resultatet är värt det. Kunderna får en färdig helhetsprodukt.

Varje operatör som planerar att gå in i bostads- och tjänstesektorn kommer nödvändigtvis att behöva gå den här vägen. Kommer de att klara det?
Det är frågan. Det handlar inte ens om pengarna. Som jag nämnde ovan, här behövs verkligen en kombination av fältarbete och utveckling. Inte alla stora aktörer är vana vid detta. Om dina utvecklare sitter i Moskva och anslutningar görs i Novosibirsk, förlängs din tid för att få en färdig produkt avsevärt.

Tiden kommer att visa vem som kommer att förbli på den här marknaden och vem som säger — nej, tack! Men en sak vet jag klart — att bara komma och ta en marknadsandel bara med pengar kommer inte att fungera. Denna process kräver okonventionella tillvägagångssätt, bra ingenjörer, djupdykning i reglering, kommunikation med resurstillhandahållare och abonnenter, samt ständigt identifiera och övervinna fallgropar.

P.S. I den här artikeln har jag medvetet fokuserat på värme och nämner inte elektricitet eller vatten. Jag beskriver också anslutningen via kabel. Om vi har en pulsgång — finns det egna nyanser, såsom obligatoriska kontroller efter installation. Det kan hända att man inte kan nå med en kabel, då används LoRaWAN. Att beskriva hela vår plattform och stegen i dess utveckling i en artikel är helt enkelt omöjligt.

Källa: habr.com