Hej kära fans av Internet of Things. I den här artikeln vill jag återigen prata om bostäder och kommunal service och en undersökning av mätanordningar.
Periodvis berättar en annan stor telekomaktör hur snart han kommer in på denna marknad och krossar alla under honom. Varje gång med sådana historier tänker jag: "grabbar, lycka till!"
Du vet inte ens vart du är på väg.
För att du ska förstå problemets omfattning kommer jag kort att beskriva en liten del av vår erfarenhet av att utveckla Smart City-plattformen. Den del av den som ansvarar för expedieringen.
Allmän idé och första svårigheter
Om vi inte talar om individuella mätanordningar, utan de som finns i källare, pannrum och företag, är de flesta nu utrustade med en telemetriutgång. Mindre ofta pulsad, oftare - RS-485/232 eller Ethernet. Som regel är de mest "bröd" mätanordningarna de som överväger värme. Det är för deras utskick som de är redo att betala i första hand.
Jag har redan bott i detalj i min artikel om funktionerna i RS-485. Kort sagt, det är bara ett datagränssnitt. Faktum är att kraven på elektriska impulser och kommunikationslinjer. Beskrivningen av paketen går en nivå högre, i en dataöverföringsstandard som fungerar ovanpå RS-485. Och vad kommer att finnas där för standarden - det är på tillverkarens nåd. Ofta Modbus, men inte nödvändigtvis. Även om Modbus kan den fortfarande modifieras något.
Faktum är att varje mätenhet behöver sitt eget avfrågningsskript som kan "prata" med den och förhöra den. Detta innebär att utsändningssystemet är en uppsättning skript för varje enskild räknare. Databasen där allt detta lagras. Och något användargränssnitt där han kan generera rapporten han behöver.
Ser lätt ut. Djävulen finns som alltid i detaljerna.
Låt oss börja med den första delen.
Manus
Hur skriver man dem? Tja, uppenbarligen, köp en mätare, öppna den, lär dig hur du kommunicerar med den och integrera den i en gemensam plattform.
Tyvärr täcker denna lösning bara en del av våra behov. Som regel har en populär räknare flera generationer, och manuset för varje generation kan vara annorlunda. Ibland lite, ibland mycket. När du köper något får du den senaste generationen. Abonnenten, med en hög grad av sannolikhet, kommer att ha något äldre. Det säljs inte längre i butik. Och abonnenten kommer inte att ändra mätenheten.
Därav det första problemet. Att skriva sådana skript är ett tufft gäng mjukvaruutvecklare och ingenjörer "på marken". Vi köpte den senaste generationen, skrev en initial mall och modifierade den sedan på riktiga enheter. Det är orealistiskt att göra detta i laboratoriet, bara under arbetet med live-prenumeranter.
Det tog oss mycket tid att skapa ett sådant paket. Nu är algoritmen utarbetad. De initiala mallarna korrigerades och kompletterades hela tiden, beroende på vad vi mötte i vår praktik. Naturligtvis blev abonnenten varnad om det plötsligt var hans disk som visade sig vara lite "inte sån". När en sådan enhet dyker upp ansluts den enligt standardschemat och pollingskriptet modifieras under vägen. Under integrationsperioden arbetar abonnenten kostnadsfritt. Han meddelas att han fortfarande lever i testläge. Själva integrationsprocessen är en ganska oförutsägbar sak. Ibland behöver du göra ett minimum av korrigeringar. Det är en komplex process med ett besök på föremålet, skottning av litteratur och konsekvent övervinnande av krattan.
Uppgiften är inte lätt, men lösbar. Resultatet är ett fungerande manus. Ju större manusbibliotek, desto lättare är det att leva.
Andra problemet.
Teknologiska anslutningskort
För att ge dig en uppfattning om komplexiteten i detta arbete kommer jag att ge ett exempel. Låt oss ta den extremt populära VKT-7 värmemätaren.
Namnet i sig säger oss ingenting. VKT-7 har flera hårdvarulösningar. Vilken typ av gränssnitt har den inuti?
Det finns olika alternativ. Det kan finnas en utgång i ett standard DB-9-block (detta är RS-232). Kanske bara en plint med RS-485-kontakter. Kanske till och med ett nätverkskort med RJ-45 (i detta fall är ModBus förpackat i Ethernet).
Eller kanske ingenting alls. Bara en bar meter. Du kan installera en gränssnittsutgång i den, den säljs av tillverkaren separat och kostar pengar. Det största problemet är att för att installera det måste du öppna mätaren och bryta tätningarna. Det vill säga att den resursförsörjande organisationen ingår i denna process. Hon meddelas att förseglingarna kommer att brytas, en dag utses och vår ingenjör, i närvaro av en representant för resursarbetarna, utför nödvändiga förbättringar, varefter mätaren förseglas igen.
Beroende på det installerade gränssnittet utförs ytterligare förfining. Till exempel bestämde vi oss för att ansluta en mätare med tråd. Detta är det enklaste alternativet, om vår switch är inom 100 meter är det överflödigt att lura med LoRa. Det är enklare med en kabel till vårt nätverk, till ett isolerat VLAN.
RS-485/232 kräver en omvandlare till Ethernet. Många kommer genast ihåg MOHA, men det är dyrt. För våra lösningar har vi valt en billigare kinesisk lösning.
Om utgången omedelbart är Ethernet behövs inte omvandlaren.
Fråga. Låt oss säga att vi ställer in gränssnittsutgången själva. Kan du göra ditt liv enklare och omedelbart sätta Ethernet överallt?
Detta är inte alltid möjligt. Vi måste titta på utförandet av kroppen. Han kanske inte har rätt hål för att gränssnittet ska stå upp som det ska. Och disken, jag påminner dig, finns i vår källare. Eller i pannrummet. Det finns hög luftfuktighet, tätheten kan inte brytas. Att avsluta ärendet med en fil är en dålig idé. Det är bättre att sätta något som initialt inte kräver stora förändringar. Ofta - RS-485 är den enda utvägen.
Ytterligare. Är mätaren ansluten till en garanterad strömförsörjning? Om inte, så lever den på batterier. I detta läge är den designad för manuell polling en gång i månaden i tre minuter. Att ständigt komma åt CGT-7 kommer att ta ur batteriet. Så du måste dra en garanterad strömförsörjning och installera en spänningsomvandlare.
För varje tillverkare av mätare är strömförsörjningsmodulen olika. Det kan vara en extern enhet på en DIN-skena eller en inbyggd omvandlare.
Det visar sig att en uppsättning olika gränssnitt och effektmoduler för varje mätare alltid ska lagras i vårt lager. Utbudet där är imponerande.
Naturligtvis kommer allt detta så småningom att betalas av abonnenten. Men han kommer inte att vänta en månad tills rätt enhet kommer. Och han behöver en uppskattning för att ansluta här och nu. Så den tekniska reserven faller på våra axlar.
Allt som jag beskrev förvandlas till ett tydligt tekniskt kopplingskort så att lokala ingenjörer inte tänker på vilken typ av djur de träffade i nästa källare och vad de behöver för sitt arbete.
Den tekniska kartan ligger i anslutning till de allmänna anslutningsbestämmelserna. När allt kommer omkring räcker det inte att inkludera mätaren i vårt nätverk, du måste fortfarande kasta samma VLAN på switchporten, du måste utföra diagnostik, göra en testundersökning. Vi strävar efter att automatisera hela processen så mycket som möjligt för att undvika fel och inte involvera onödiga ingenjörskrafter.
Jo, vi skrev tekniska kartor, föreskrifter, automation. Ställ in logistik.
Var annars finns dolda fallgropar?
Data läses och hälls in i databasen.
Abonnenten från dessa siffror är inte varm eller kall. Han behöver en rapport. Gärna i den form han är van. Ännu bättre, omedelbart i form av en rapport som han kan förstå, som han kan skriva ut, underteckna och lämna in. Det betyder att du behöver ett enkelt och begripligt gränssnitt som visar information på mätaren och automatiskt kan generera en rapport.
Här fortsätter vår djurpark. Faktum är att det finns flera former av rapporten. I sin kärna reflekterar de samma sak (förbrukad värme), men på olika sätt.
Några av abonnenterna rapporterar i absoluta värden (det vill säga värden skrivs i värmeförbrukningskolumnen med början från installationen av mätaren), någon i delta (det är när vi skriver förbrukning under en tidsperiod utan hänvisning till de initiala värdena). I själva verket använder de inte enhetliga standarder, utan etablerad praxis. Det har förekommit fall när abonnenter ser alla värden som de behöver (mängden förbrukad värme, volymen kylvätska som tillförts och försvunnit, temperaturskillnad), men kolumnerna i rapporten är i fel ordning.
Därav nästa steg - rapporten måste vara anpassningsbar. Det vill säga att abonnenten själv väljer vad som går i vilken ordningsföljd och vilka resurser som finns i hans dokument.
Här är en intressant punkt. Allt är bra om vår mätare är korrekt installerad. Men det händer att installationsorganisationen, vid installationen av ITP:n, trasslade till och felaktigt ställde in tiden för mätaren. Vi har sett enheter som tror att det är 2010. I vårt system kommer detta att se ut som noll avläsningar för det aktuella datumet och verklig förbrukning om vi väljer 2010. Det är här deltan kommer väl till pass. Det vill säga, vi säger att det har tickat så mycket den senaste dagen.
Det verkar, varför sådana svårigheter? Är det så svårt att vrida på klockan?
Det är just med VKT-7 som detta kommer att leda till en fullständig återställning av räknaren och borttagning av arkiv från den.
Prenumeranten kommer att tvingas bevisa för resursförvaltarna att han installerade ITP:n inte igår, utan för ungefär fem år sedan.
Och till sist, grädden på moset.
certifiering
Vi har en mätare, vi har en rapport. Mellan dem finns vårt system som genererar denna rapport. Tror du henne?
Jag är ja. Men hur man bevisar att ingenting förändras inom oss, att vi inte förvränger meningen. Det är en fråga om certifiering. Röstningssystemet måste ha ett intyg som bekräftar dess opartiskhet. Alla stora system, som LERS, Ya Energetik med flera, har ett liknande certifikat. Det fick vi också, även om det är dyrt och tar mycket tid.
Självklart kan du alltid klippa hörn och köpa något färdigt. Men utvecklaren kommer att få betala för detta. Och utvecklaren kan be inte bara om en inträdesavgift, utan också om en månadsavgift. Det vill säga, vi kommer att tvingas dela en del av vår paj med honom.
Varför är allt?
Huvudproblemet är inte detta. Att utveckla ett eget system är också mycket dyrt och många gånger svårare. Det ger dock en viktig fördel. Vi förstår tydligt hur det fungerar. Vi skalar lätt det, vi kan modifiera det om ett sådant behov plötsligt uppstår. Abonnenten får en mer komplett tjänst, och från vår sida hundra procent kontroll över processen.
Det är därför vi valde den andra vägen. Vi har investerat ett år av våra utvecklare och fältingenjörer i det. Men nu förstår vi tydligt hela kedjans arbete.
När jag ser tillbaka förstår jag att utan den kunskap jag fått, kunde jag helt enkelt inte korrekt tolka det onormala beteendet hos en viss räknare.
Dessutom kan något mer byggas utifrån dispatchsystemet. Förbrukningsöverskottslarm, olycksrapport. Vi har en mobilapp som kommer snart.
Vi gick ännu längre och lade till vår plattform (annars kan man inte kalla det något annat) möjligheten att ta emot förfrågningar från invånare, möjligheten att styra våra "smarta porttelefoner", direkt styra gatubelysning och några fler projekt som jag har inte skrivit om än.
Allt detta är komplext, hjärnbrytande och långt. Men resultatet är värt det. Prenumeranter får en färdig heltäckande produkt.
Varje operatör som planerar att gå in i bostäder och kommunala tjänster kommer definitivt att ta denna väg. Kommer det att gå över?
Här är en fråga. Det handlar inte ens om pengarna. Som jag skrev ovan är det som behövs här en kombination av arbete på fältet och utveckling. Alla stora aktörer är inte vana vid detta. Om dina utvecklare är i Moskva och anslutningar görs i Novosibirsk, är din tid för den färdiga produkten avsevärt utsträckt.
Tiden kommer att utvisa vem som kommer att stanna på denna marknad, och vem som kommer att säga - ja, han har gått åt helvete! Men en sak som jag vet säkert är att det inte kommer att fungera att komma och ta marknadsandelar enbart med pengar. Denna process kräver okonventionella tillvägagångssätt, bra ingenjörer, grävande i regleringen, kommunikation med resursförvaltare och abonnenter, konstant identifiering och övervinnande av raken.
PS I den här artikeln har jag medvetet fokuserat på värme och nämner inte el eller vatten. Jag beskriver även kabelanslutningen. Om vi har en pulsutgång finns det några nyanser, till exempel obligatoriska avstämningar efter installation. Det kan vara så att tråden inte kan nås, då används LoRaWAN. Det är helt enkelt orealistiskt att beskriva hela vår plattform och stadierna i dess utveckling i en artikel.
Källa: will.com