Hei, kjære fans av tingenes internett. I denne artikkelen vil jeg igjen snakke om boliger og fellestjenester og en undersøkelse av måleenheter.
Fra tid til annen snakker den neste store telekomaktøren om hvor snart han vil gå inn på dette markedet og knuse alle under seg. Hver gang jeg hører historier som dette, tenker jeg: «Gutter, lykke til!»
Du vet ikke engang hvor du skal.
For at du skal forstå omfanget av problemet, vil jeg kort fortelle deg en liten del av vår erfaring med å utvikle Smart City-plattformen. Den delen av den som er ansvarlig for utsendelse.
Generell idé og første vanskeligheter
Hvis vi ikke snakker om individuelle måleenheter, men de som er i kjellere, fyrrom og bedrifter, så er de fleste av dem nå utstyrt med en telemetrisk utgang. Mindre ofte pulsert, oftere - RS-485/232 eller Ethernet. Som regel er de mest nyttige måleenhetene de som teller varme. De er villige til å betale for utsendelsen i utgangspunktet.
Jeg har allerede diskutert i detalj funksjonene til RS-485 i artikkelen min. Kort sagt, dette er ganske enkelt et dataoverføringsgrensesnitt. I hovedsak er dette kravene til elektriske impulser og kommunikasjonslinjer. Beskrivelsen av pakkene kommer på et høyere nivå, i dataoverføringsstandarden, som opererer på toppen av RS-485. Og hva slags standard det blir er overlatt til produsenten. Ofte Modbus, men ikke nødvendig. Selv om det er Modbus, kan det fortsatt være noe modifisert.
Faktisk trenger hver måler sitt eget undersøkelsesskript, som kan "snakke" til det og spørre det. Dette betyr at ekspedisjonssystemet er et sett med skript for hver enkelt teller. Databasen hvor alt dette er lagret. Og et visst brukergrensesnitt der han kan generere rapporten han trenger.
Ser lett ut. Djevelen er som alltid i detaljene.
La oss starte med den første delen.
skript
Hvordan skrive dem? Vel, åpenbart, kjøp en måleenhet, triks med den, lær å kommunisere med den og integrer den i en felles plattform.
Dessverre vil denne løsningen bare dekke deler av våre behov. Vanligvis har en populær teller flere generasjoner, og manuset for hver generasjon kan være forskjellig. Noen ganger litt, noen ganger mye. Når du kjøper noe, får du den nyeste generasjonen. Abonnenten vil mest sannsynlig ha noe eldre. Det selges ikke lenger i butikk. Og abonnenten vil ikke endre måleenheten.
Derav det første problemet. Å skrive slike skript er en tøff kombinasjon av programvareutviklere og ingeniører «på bakken». Vi kjøpte den siste generasjonen, skrev en innledende mal og modifiserte den på ekte enheter. Det er umulig å gjøre dette i et laboratorium, bare mens du jobber med live-abonnenter.
Det tok oss mye tid å lage en slik pakke. Algoritmen er nå utarbeidet. De første malene ble hele tiden justert og supplert, avhengig av hva vi møtte i vår praksis. Abonnenten ble selvfølgelig advart hvis måleren hans plutselig viste seg å være litt "av". Når en slik enhet dukker opp, kobles den til i henhold til standardskjemaet og undersøkelsesskriptet endres underveis. Under integrasjonen jobber abonnenten gratis. Han får beskjed om at han for tiden lever i testmodus. Selve integreringsprosessen er en ganske uforutsigbar ting. Noen ganger trenger du bare å gjøre minimale korrigeringer. Det kan være en kompleks prosess som involverer å gå til stedet, måke litteratur og suksessivt overvinne raken.
Oppgaven er ikke lett, men løsbar. Resultatet er et fungerende manus. Jo større bibliotek med skript, jo lettere er livet.
Andre problem.
Teknologiske tilkoblingskort
For å få deg til å forstå kompleksiteten i dette arbeidet, vil jeg gi et eksempel. La oss ta den ekstremt populære varmemåleren VKT-7.
Navnet i seg selv sier oss ingenting. VKT-7 har flere jernkledde løsninger. Hva slags grensesnitt har den inni?
Det finnes ulike alternativer. Det kan være en pinne i en standard DB-9-blokk (dette er RS-232). Det kan bare være en rekkeklemme med RS-485-kontakter. Kanskje til og med et nettverkskort med RJ-45 (i dette tilfellet er ModBus pakket inn i Ethernet).
Eller kanskje ingenting i det hele tatt. Bare en bare måleenhet. Du kan installere en grensesnittutgang i den; den selges separat av produsenten og koster penger. Hovedproblemet er at for å installere det må du åpne måleren og bryte tetningene. Det vil si at den ressursleverende organisasjonen er inkludert i denne prosessen. Hun får beskjed om at forseglingen vil bli brutt, en dag er satt og vår ingeniør, i nærvær av en ressursrepresentant, gjør de nødvendige modifikasjoner, hvoretter måleren forsegles igjen.
Avhengig av det installerte grensesnittet, gjøres ytterligere modifikasjoner. For eksempel bestemte vi oss for å koble måleren via ledning. Dette er det enkleste alternativet, hvis bryteren vår er innenfor 100 meter, er det overflødig å fikle med LoRa. Det er lettere å koble en kabel til nettverket vårt, til et isolert VLAN.
For RS-485/232 trenger du en omformer til Ethernet. Mange vil umiddelbart huske MOHA, men det er dyrt. For våre løsninger valgte vi en billigere kinesisk løsning.
Hvis utgangen er direkte Ethernet, er det ikke nødvendig med en omformer.
Spørsmål. La oss si at vi installerer grensesnittutgangen selv. Kan du gjøre livet ditt enklere og umiddelbart installere Ethernet overalt?
Dette er ikke alltid mulig. Vi må se på utformingen av kroppen. Den har kanskje ikke det nødvendige hullet for at grensesnittet skal passe ordentlig. La meg minne deg på at disken er i kjelleren vår. Eller i fyrrommet. Det er høy luftfuktighet der, forseglingen kan ikke brytes. Å fullføre kroppen med en fil er en dårlig idé. Det er bedre å installere noe som i utgangspunktet ikke krever store endringer. Ofte er RS-485 eneste utvei.
Lengre. Er måleren koblet til garantert strøm? Hvis ikke, går den på batteristrøm. I denne modusen er den designet for manuell polling en gang i måneden i tre minutter. Konstant tilgang til VKT-7 vil tappe batteriet. Dette betyr at du må sørge for garantert strøm og installere en spenningsomformer.
Strømmodulen er forskjellig for hver målerprodusent. Dette kan være en ekstern DIN-skinneenhet eller en innebygd omformer.
Det viser seg at vårt lager alltid skal lagre et sett med forskjellige grensesnitt og strømmoduler for hver måler. Utvalget der er imponerende.
Alt dette vil selvfølgelig til slutt betales av abonnenten. Men han vil ikke vente en måned før den rette enheten kommer. Og han trenger et estimat for tilknytning her og nå. Så den teknologiske reserven faller på skuldrene våre.
Alt jeg beskrev blir til et tydelig teknisk koblingskart, slik at lokale ingeniører ikke tenker på hva slags beist de møtte i neste kjeller og hva de trenger for at det skal fungere.
Teknisk kart ligger i tilknytning til alminnelig forskrift for tilknytning. Tross alt er det ikke nok å inkludere måleren i nettverket vårt; vi må fortsatt koble det samme VLAN til svitsjporten, vi må utføre diagnostikk og gjøre en testundersøkelse. Vi streber etter å automatisere hele prosessen så mye som mulig for å unngå feil og ikke involvere unødvendige ingeniører.
Ok, vi skrev tekniske kart, forskrifter, automatisering. Vi har etablert logistikk.
Hvor ellers er det skjulte fallgruver?
Dataene leses og helles inn i databasen.
Disse tallene gjør at abonnenten verken blir varm eller kald. Han trenger en rapport. Gjerne i den formen han er vant til. Det er enda bedre hvis det umiddelbart er i form av en rapport som han kan forstå, som han kan skrive ut, signere og sende inn. Dette betyr at vi trenger et enkelt og forståelig grensesnitt som viser informasjon på måleren og automatisk kan generere en rapport.
Her fortsetter dyrehagen vår. Faktum er at det finnes flere rapportskjemaer. I kjernen reflekterer de det samme (varmeforbruk), men på forskjellige måter.
Noen abonnenter rapporterer i absolutte verdier (dvs. i varmeforbrukskolonnen skrives verdier fra installasjonen av måleren), andre i delta (dette er når vi skriver forbruk over en periode uten referanse til startverdiene). De bruker faktisk ikke enhetlige standarder, men etablert praksis. Det har vært tilfeller der abonnenter ser alle verdiene de trenger (mengde forbrukt varme, mengde kjølevæske som tilføres og slippes ut, temperaturforskjell), men kolonnene i rapporten er ikke i riktig rekkefølge.
Derav neste trinn - rapporten må kunne tilpasses. Det vil si at abonnenten selv velger hva som går i hvilken rekkefølge og hvilke ressurser som er i dokumentet hans.
Det er et interessant poeng her. Alt er i orden hvis måleren vår er riktig installert. Men det hender at installasjonsfirmaet, da installasjonen av ITP-en, gjorde en feil og satte inn tiden for måleren feil. Vi har kommet over enheter som tror det er 2010. I vårt system vil dette se ut som null avlesninger for gjeldende dato, og reelt forbruk hvis vi velger 2010. Deltaer er veldig nyttige her. Det vil si at vi sier at det har skjedd så mye det siste døgnet.
Det ser ut til, hvorfor slike vanskeligheter? Er det så vanskelig å spole klokken?
Nøyaktig med VKT-7 vil dette føre til en fullstendig tilbakestilling av telleren og sletting av arkiver fra den.
Abonnenten vil bli tvunget til å bevise overfor ressursansvarlige at han installerte ITP ikke i går, men for fem år siden.
Og til slutt, prikken over i-en.
sertifisering
Vi har en måler og en rapport. Mellom dem er systemet vårt, som genererer denne rapporten. Tror du henne?
Jeg gjør. Men hvordan kan vi bevise at ingenting forandrer seg inni oss, at vi ikke forvrider meningen. Dette er allerede et spørsmål om sertifisering. Oppmålingssystemet skal ha et sertifikat som bekrefter dets upartiskhet. Alle store systemer, som LERS, Ya Energetik og andre har tilsvarende sertifikat. Vi fikk den også, selv om den er dyr og tar mye tid.
Du kan selvfølgelig alltids kutte et hjørne og kjøpe noe ferdig. Men utvikleren må betale for dette. Og utvikleren kan kreve ikke bare en inngangsavgift, men også en abonnementsavgift. Det vil si at vi blir tvunget til å dele en del av kaken vår med ham.
Hvorfor er alt?
Dette er ikke hovedproblemet. Å utvikle ditt eget system er også veldig dyrt og mye vanskeligere. Det gir imidlertid en viktig fordel. Vi forstår tydelig hvordan det fungerer. Vi skalerer det enkelt, vi kan modifisere det hvis et slikt behov plutselig oppstår. Abonnenten får en mer komplett tjeneste, og fra vår side XNUMX % kontroll over prosessen.
Derfor valgte vi den andre veien. Vi investerte et år av livene til våre utviklere og feltingeniører i det. Men nå forstår vi helt klart driften av hele kjeden.
Når jeg ser tilbake, forstår jeg at uten kunnskapen jeg har fått, ville jeg rett og slett ikke vært i stand til å tolke den unormale oppførselen til en bestemt teller korrekt.
I tillegg kan det bygges noe mer på grunnlag av ekspedisjonssystemet. Alarmer for merforbruk, ulykkesrapport. Vi forbereder snart lansering av en mobilapplikasjon.
Vi gikk enda lenger og la til plattformen vår (det er ingen annen måte å kalle det) muligheten til å motta forespørsler fra beboere, muligheten til å kontrollere våre "smarte intercoms", kontrollere gatebelysning og flere andre prosjekter som jeg ikke har skrevet om ennå.
Alt dette er vanskelig, hjerneknusende og tidkrevende. Men resultatet er verdt det. Abonnenter får et ferdig, omfattende produkt.
Hver operatør som planlegger å gå inn i bolig- og kommunale tjenester vil definitivt ta denne veien. Vil det gå over?
Her er et spørsmål. Det handler ikke engang om penger. Som jeg skrev ovenfor, er det som trengs her en kombinasjon av feltarbeid og utvikling. Ikke alle store aktører er vant til dette. Hvis utviklerne dine er lokalisert i Moskva, og forbindelser er opprettet i Novosibirsk, er tiden din for det ferdige produktet betydelig forlenget.
Tiden vil vise hvem som blir i dette markedet, og hvem som vil si - vel, dra til helvete! Men en ting jeg vet med sikkerhet er at du ikke vil kunne komme og ta markedsandeler kun med penger. Denne prosessen krever ukonvensjonelle tilnærminger, gode ingeniører, fordyping i regulatorer, kommunikasjon med ressursansvarlige og abonnenter, konstant identifisere og overvinne problemer.
PS I denne artikkelen har jeg bevisst fokusert på varme og har ikke nevnt strøm eller vann. Jeg beskriver også kabeltilkoblingen. Hvis vi har en pulsutgang, er det noen nyanser, for eksempel obligatoriske kontroller etter installasjon. Det kan være at ledningen ikke kan nås, da spiller LoRaWAN inn. Det er rett og slett urealistisk å beskrive hele plattformen vår og utviklingsstadiene i én artikkel.
Kilde: www.habr.com