Hej, kære fans af Internet of Things. I denne artikel vil jeg igen gerne tale om boliger og kommunale tjenester og en undersøgelse af måleapparater.
Fra tid til anden taler den næste store telekomaktør om, hvor hurtigt han vil komme ind på dette marked og knuse alle under ham. Hver gang jeg hører historier som denne, tænker jeg: "Gutter, held og lykke!"
Du ved ikke engang, hvor du skal hen.
For at du forstår problemets omfang, vil jeg kort fortælle dig en lille del af vores erfaring med at udvikle Smart City platformen. Den del af den, der er ansvarlig for afsendelse.
Generel idé og første vanskeligheder
Hvis vi ikke taler om individuelle måleenheder, men dem, der er i kældre, kedelrum og virksomheder, så er de fleste af dem nu udstyret med en telemetrisk udgang. Mindre ofte pulseret, oftere - RS-485/232 eller Ethernet. Som regel er de mest nyttige måleanordninger dem, der tæller varme. De er villige til at betale for deres afsendelse i første omgang.
Jeg har allerede diskuteret detaljeret funktionerne i RS-485 i min artikel. Kort sagt, dette er simpelthen en dataoverførselsgrænseflade. I bund og grund er disse kravene til elektriske impulser og kommunikationslinjer. Beskrivelsen af pakkerne kommer på et højere niveau, i datatransmissionsstandarden, som fungerer oven på RS-485. Og hvilken slags standard der vil være, er overladt til producenten. Ofte Modbus, men ikke påkrævet. Selvom det er Modbus, kan det stadig være noget modificeret.
Faktisk har hver måler brug for sit eget undersøgelsesscript, som kan "tale" til det og udspørge det. Det betyder, at afsendelsessystemet er et sæt scripts for hver enkelt tæller. Databasen hvor alt dette er gemt. Og en bestemt brugergrænseflade, hvor han kan generere den rapport, han har brug for.
Ser let ud. Djævelen er som altid i detaljerne.
Lad os starte med den første del.
Scripts
Hvordan skriver man dem? Nå, selvfølgelig skal du købe en måleenhed, pille ved den, lære at kommunikere med den og integrere den i en fælles platform.
Desværre dækker denne løsning kun en del af vores behov. Typisk har en populær tæller flere generationer, og scriptet for hver generation kan være forskelligt. Nogle gange lidt, nogle gange meget. Når du køber noget, får du den nyeste generation. Abonnenten vil højst sandsynligt have noget ældre. Det sælges ikke længere i butikkerne. Og abonnenten vil ikke ændre måleenheden.
Derfor det første problem. At skrive sådanne scripts er en hård kombination af softwareudviklere og ingeniører "på jorden". Vi købte den seneste generation, skrev en indledende skabelon og ændrede den derefter på rigtige enheder. Det er umuligt at gøre dette i et laboratorium, kun mens du arbejder med live-abonnenter.
Det tog os meget tid at skabe sådan et bundt. Algoritmen er nu udarbejdet. De indledende skabeloner blev løbende justeret og suppleret, alt efter hvad vi stødte på i vores praksis. Abonnenten blev selvfølgelig advaret, hvis hans måler pludselig viste sig at være lidt "slukket". Når en sådan enhed dukker op, tilsluttes den i henhold til standardskemaet, og undersøgelsesscriptet ændres undervejs. Under integrationen arbejder abonnenten gratis. Han er informeret om, at han i øjeblikket lever i testtilstand. Selve integrationsprocessen er en ret uforudsigelig ting. Nogle gange behøver du kun lave minimale rettelser. Der kan være en kompleks proces, der involverer at gå til stedet, skovle litteratur og successivt overvinde riven.
Opgaven er ikke let, men løsbar. Resultatet er et fungerende script. Jo større bibliotek af scripts, jo lettere er livet.
Andet problem.
Teknologiske tilslutningskort
For at få dig til at forstå kompleksiteten af dette arbejde, vil jeg give et eksempel. Lad os tage den ekstremt populære varmemåler VKT-7.
Selve navnet siger os ikke noget. VKT-7 har flere jernbeklædte løsninger. Hvilken slags grænseflade har den indeni?
Der er forskellige muligheder. Der kan være en stift i en standard DB-9 blok (dette er RS-232). Det kunne bare være en klemrække med RS-485 kontakter. Måske endda et netværkskort med RJ-45 (i dette tilfælde er ModBus pakket ind i Ethernet).
Eller måske slet ikke noget. Bare en blottet måleenhed. Du kan installere en interface-output i den; den sælges separat af producenten og koster penge. Hovedproblemet er, at for at installere det skal du åbne måleren og bryde forseglingerne. Det vil sige, at den ressourceleverende organisation er inkluderet i denne proces. Hun får besked om, at forseglingerne brydes, en dag er fastsat, og vores ingeniør foretager i nærværelse af en ressourcerepræsentant de nødvendige modifikationer, hvorefter måleren forsegles igen.
Afhængigt af den installerede grænseflade foretages yderligere ændringer. For eksempel besluttede vi at forbinde måleren via ledning. Dette er den enkleste mulighed, hvis vores switch er inden for 100 meter, så er det overflødigt at fifle med LoRa. Det er nemmere at tilslutte et kabel til vores netværk, til et isoleret VLAN.
Til RS-485/232 skal du bruge en konverter til Ethernet. Mange vil straks huske MOHA, men det er dyrt. Til vores løsninger valgte vi en billigere kinesisk løsning.
Hvis udgangen er direkte Ethernet, er en konverter ikke nødvendig.
Spørgsmål. Lad os sige, at vi selv installerer interface-outputtet. Kan du gøre dit liv lettere og straks installere Ethernet overalt?
Dette er ikke altid muligt. Vi skal se på kroppens design. Den har muligvis ikke det nødvendige hul for, at grænsefladen passer korrekt. Lad mig minde dig om, at disken er i vores kælder. Eller i fyrrumet. Der er høj luftfugtighed der, forseglingen kan ikke brydes. At afslutte kroppen med en fil er en dårlig idé. Det er bedre at installere noget, der i første omgang ikke kræver større ændringer. Ofte er RS-485 den eneste udvej.
Yderligere. Er måleren tilsluttet garanteret strøm? Hvis ikke, så kører den på batteristrøm. I denne tilstand er den designet til manuel polling en gang om måneden i tre minutter. Konstant adgang til VKT-7 vil dræne batteriet. Det betyder, at du skal levere garanteret strøm og installere en spændingsomformer.
Strømmodulet er forskelligt for hver målerproducent. Dette kan være en ekstern DIN-skinneenhed eller en indbygget konverter.
Det viser sig, at vores lager altid skal opbevare et sæt forskellige grænseflader og strømmoduler for hver måler. Udvalget der er imponerende.
Alt dette vil naturligvis i sidste ende blive betalt af abonnenten. Men han vil ikke vente en måned på, at den rigtige enhed kommer. Og han har brug for et skøn for forbindelse her og nu. Så den teknologiske reserve falder på vores skuldre.
Alt, hvad jeg beskrev, bliver til et klart teknisk forbindelseskort, så de lokale ingeniører ikke tænker på, hvilket slags dyr de stødte på i den næste kælder, og hvad de skal bruge for at det kan fungere.
Det tekniske kort støder op til de almindelige bestemmelser for tilslutning. Når alt kommer til alt, er det ikke nok at inkludere måleren i vores netværk; vi skal stadig tilslutte det samme VLAN til switch-porten, vi skal udføre diagnostik og lave en testafstemning. Vi bestræber os på at automatisere hele processen så meget som muligt for at undgå fejl og ikke involvere unødvendige ingeniører.
Okay, vi skrev tekniske kort, regler, automatisering. Vi har etableret logistik.
Hvor ellers er der skjulte faldgruber?
Dataene læses og hældes ind i databasen.
Disse tal gør abonnenten hverken varm eller kold. Han har brug for en rapport. Helst i den form, han er vant til. Det er endnu bedre, hvis det umiddelbart er i form af en rapport, som han kan forstå, som han kan printe ud, underskrive og indsende. Det betyder, at vi har brug for en enkel og forståelig grænseflade, der viser information på måleren og automatisk kan generere en rapport.
Her fortsætter vores zoologiske have. Faktum er, at der er flere indberetningsskemaer. I deres kerne afspejler de det samme (varmeforbrug), men på forskellige måder.
Nogle abonnenter rapporterer i absolutte værdier (dvs. i varmeforbrugskolonnen skrives værdier fra installationen af måleren), andre i deltaer (det er, når vi skriver forbrug over en periode uden henvisning til startværdierne). Faktisk bruger de ikke ensartede standarder, men etableret praksis. Der har været tilfælde, hvor abonnenter ser alle de værdier, de har brug for (mængde forbrugt varme, mængden af tilført og udledt kølevæske, temperaturforskel), men kolonnerne i rapporten er ikke i den korrekte rækkefølge.
Derfor er det næste skridt - rapporten skal kunne tilpasses. Det vil sige, at abonnenten selv vælger, hvad der går i hvilken rækkefølge, og hvilke ressourcer der er i hans dokument.
Der er en interessant pointe her. Alt er i orden, hvis vores måler er installeret korrekt. Men det sker, at installationsfirmaet ved installationen af ITP'en lavede en fejl og forkert indstillede tiden for måleren. Vi er stødt på enheder, der tror, det er 2010. I vores system vil dette ligne nul aflæsninger for den aktuelle dato og reelt forbrug, hvis vi vælger 2010. Deltas er meget nyttige her. Det vil sige, at vi siger, at der er sket så meget i løbet af det seneste døgn.
Det ser ud til, hvorfor sådanne vanskeligheder? Er det så svært at spole dit ur?
Præcis med VKT-7 vil dette føre til en fuldstændig nulstilling af tælleren og sletning af arkiver fra den.
Abonnenten vil blive tvunget til at bevise over for ressourceansvarlige, at han installerede ITP'en ikke i går, men for fem år siden.
Og til sidst prikken over i'et.
certificering
Vi har en måler og en rapport. Mellem dem er vores system, som genererer denne rapport. Tror du på hende?
Jeg gør. Men hvordan kan vi bevise, at intet ændrer sig indeni os, at vi ikke fordrejer meningen. Dette er allerede et spørgsmål om certificering. Synssystemet skal have et certifikat, der bekræfter dets upartiskhed. Alle store systemer, såsom LERS, Ya Energetik og andre har et lignende certifikat. Vi fik den også, selvom den er dyr og tager meget tid.
Du kan selvfølgelig altid skære et hjørne og købe noget færdiglavet. Men bygherren skal betale for dette. Og udvikleren kan bede om ikke kun et adgangsgebyr, men også et abonnementsgebyr. Det vil sige, at vi bliver tvunget til at dele en del af vores tærte med ham.
Hvorfor er det hele?
Dette er ikke hovedproblemet. At udvikle dit eget system er også meget dyrt og meget vanskeligere. Det giver dog en vigtig fordel. Vi forstår tydeligt, hvordan det fungerer. Vi skalerer det nemt, vi kan ændre det, hvis et sådant behov pludselig opstår. Abonnenten får en mere komplet service, og fra vores side XNUMX% kontrol over processen.
Derfor valgte vi den anden vej. Vi investerede et år af vores udvikleres og feltingeniørers liv i det. Men nu forstår vi helt klart driften af hele kæden.
Når jeg ser tilbage, forstår jeg, at uden den opnåede viden, ville jeg simpelthen ikke have været i stand til at fortolke en bestemt tællers unormale adfærd korrekt.
Derudover kan der bygges noget mere på baggrund af ekspeditionssystemet. Alarmer for overforbrug, ulykkesrapport. Vi forbereder snart at frigive en mobilapplikation.
Vi gik endnu længere og tilføjede til vores platform (der er ingen anden måde at kalde det) muligheden for at modtage anmodninger fra beboere, muligheden for at styre vores "smarte samtaleanlæg", styre gadebelysning og flere andre projekter, som jeg ikke har skrevet om endnu.
Alt dette er svært, hjernebrydende og tidskrævende. Men resultatet er det værd. Abonnenter modtager et færdiglavet, omfattende produkt.
Enhver operatør, der planlægger at gå ind i bolig- og kommunale servicesektoren, vil helt sikkert tage denne vej. Vil det passere?
Her er et spørgsmål. Det handler ikke engang om pengene. Som jeg skrev ovenfor, er det nødvendigt her en kombination af feltarbejde og udvikling. Ikke alle større aktører er vant til dette. Hvis dine udviklere er placeret i Moskva, og forbindelser er lavet i Novosibirsk, forlænges din tid til det færdige produkt betydeligt.
Tiden vil vise, hvem der bliver på dette marked, og hvem der vil sige - jamen, gå ad helvede til! Men en ting, jeg ved med sikkerhed, er, at du ikke vil kunne komme og tage markedsandele udelukkende med penge. Denne proces kræver ukonventionelle tilgange, gode ingeniører, dykning i regulatorer, kommunikation med ressourceansvarlige og abonnenter, konstant identificering og overvindelse af problemer.
PS I denne artikel har jeg bevidst fokuseret på varme og har ikke nævnt el eller vand. Jeg beskriver også kabelforbindelsen. Hvis vi har en pulsudgang, er der nogle nuancer, såsom obligatoriske kontroller efter installation. Det kan være, at ledningen ikke kan nås, så kommer LoRaWAN i spil. Det er simpelthen urealistisk at beskrive hele vores platform og udviklingsstadierne i én artikel.
Kilde: www.habr.com