Hej, kære tilhængere af Internet of Things. I denne artikel vil jeg igen gerne tale om boligsektoren og måleraflæsning.
Periodisk fortæller en stor spiller i telekommunikationsbranchen, hvordan de snart vil trænge ind på dette marked og overtage det hele. Hver gang jeg hører sådanne historier, tænker jeg: "Held og lykke, folkens!"
I kan slet ikke forestille jer, hvad I går ind til.
For at I skal forstå omfanget af problemet, vil jeg kort dele noget af vores erfaring med udviklingen af platformen 'Smart City'. Den del, der omhandler dispatching.
Den overordnede idé og de første udfordringer
Hvis vi ser på de målere, der ikke er individuelle, men de der står i kældre, kedler og på virksomheder, så er størstedelen af dem nu udstyret med telemetrisk output. Sjældnere impuls-output, oftere - RS-485/232 eller Ethernet. Som regel er de mest værdifulde målere dem, der måler varme. Det er dem, der er klar til at betale for deres dispatching først.
Jeg har allerede detaljeret omtalt egenskaberne ved RS-485 i min artikel. Kort sagt - det er blot en datatransmissionsgrænseflade. I bund og grund er det kravene til elektriske impulser og kommunikationslinjen. Beskrivelsen af pakkerne går et niveau højere op i datatransmissionsstandarden, som fungerer oven på RS-485. Hvilken standard der vil være, overlades til producenten. Ofte Modbus, men ikke nødvendigvis. Selv hvis det er Modbus, kan det være lidt modificeret.
I bund og grund har hver måler brug for sit eget skript til aflæsning, som kan 'tale' med den og aflæse den. Det betyder, at dispatchingsystemet er et sæt skripter til hver enkelt tæller. Een database, hvor alt dette opbevares. Og en brugergrænseflade, hvor brugeren kan generere den ønskede rapport.
Det ser ikke svært ud. Djævelen ligger, som altid, i detaljerne.
Lad os starte med den første del.
Skripter
Hvordan skriver man dem? Nå, det er åbenlyst, du skal købe en måler, skille den ad, lære at kommunikere med den og integrere den i den samlede platform.
Desværre vil denne løsning kun dække en del af vores behov. Generelt har en populær tæller flere generationer, og skripterne for hver generation kan variere. Nogle gange en smule, andre gange betydeligt. Når du køber noget, får du den nyeste generation. Abonnenten vil sandsynligvis have noget, der er mere gammeldags. Det kan allerede ikke købes i butikkerne. Og abonnenten vil ikke ændre tælleenheden.
Her opstår det første problem. At skrive sådanne skripter kræver et tæt samarbejde mellem softwareudviklere og ingeniører "i marken". Vi købte den nyeste generation, skrev en slags indledende skabelon og modificerede den derefter på de faktiske enheder. At gøre det i et laboratorium er umuligt, kun ved at arbejde med rigtige abonnenter.
Vi brugte en del tid på at skabe et sådant samarbejde. Nu er algoritmen arbejdet igennem. De indledende skabeloner blev konstant justeret og suppleres afhængigt af det, vi mødte i vores praksis. Selvfølgelig blev abonnenterne informeret, hvis deres tæller viste sig at være lidt "andersledes". Når en sådan enhed dukker op, bliver den tilsluttet efter standardordningen, og skriptet til forespørgslen modificeres undervejs. I integrationsperioden arbejder abonnenten gratis. De informeres om, at de i øjeblikket er i testtilstand. Selve integrationsprocessen er en ret uforudsigelig ting. Nogle gange skal der kun laves minimale rettelser. Andre gange er det en kompliceret proces, der kræver besøg på stedet, gennemgang af litteratur og sekventiel overvindelse af forhindringer.
Opgaven er ikke nem, men den kan løses. Resultatet er et fungerende skript. Jo større biblioteket af skripter er, jo lettere er det at arbejde.
Det andet problem.
Teknologiske tilslutningskort
For at du forstår kompleksiteten af dette arbejde, vil jeg give et eksempel. Lad os tage den yderst populære varmertæller VKT-7.
Selve navnet siger os ikke meget. VKT-7 har flere hardwareløsninger. Hvilken type interface har den indeni?
Der er forskellige muligheder. Den kan have udgang i en standard DB-9 terminal (det er RS-232). Den kan også blot have en terminalblok med RS-485 kontakter. Den kan endda have et netværkskort med RJ-45 (i så fald pakkes ModBus ind i Ethernet).
Eller måske slet ikke noget. Bare en rå måler. Der kan installeres en interfaceudgang, som sælges separat af producenten og koster penge. Det største problem er, at installationen kræver, at måleren åbnes og sealingerne brydes. Det betyder, at det involverer forsyningsselskabet. De bliver informeret om, at sealingerne vil blive brudt, en dag fastsættes, og vores ingeniør udfører de nødvendige ændringer i nærværelse af en repræsentant fra forsyningsselskabet, hvorefter måleren bliver forseglet igen.
Afhænger af den installerede interface. For eksempel besluttede vi at tilslutte måleren via kabel. Dette er den mest enkle løsning; hvis der er vores switch inden for 100 meters rækkevidde, så er det overflødigt at besvære sig med LoRa. Det er lettere med kabel til vores netværk, i et isoleret VLAN.
For RS-485/232 er der brug for en konverter til Ethernet. Mange vil straks huske MOXA, men det er dyrt. Til vores løsninger har vi fundet en kinesisk løsning til en bedre pris.
Hvis udgangen er direkte Ethernet, er der ikke brug for en konverter.
Spørgsmål. Antag, at vi selv installerer interfaceudgang. Kan vi gøre vores liv lettere og sætte Ethernet overalt med det samme?
Det er ikke altid muligt. Man skal se på kabinetudførelsen. Der kan mangle det nødvendige hul, så interface monteres korrekt. Og måleren, mindes jeg, står i vores kælder. Eller i kedelrummet. Der er høj luftfugtighed, og vi må ikke bryde tætheden. At tilpasse kabinettet med en fil er en dårlig idé. Det er bedre at installere noget, der oprindeligt ikke kræver store ændringer. Ofte er RS-485 den eneste løsning.
Dernæst. Er måleren tilsluttet en garanteret strømforsyning? Hvis ikke, så lever den på et batteri. I denne tilstand er den beregnet til manuel aflæsning en gang om måneden i tre minutter. Kontinuerlig adgang til VKT-7 vil tømme dens batteri. Så der skal trækkes garanteret strøm og installeres en spændingsomformer.
For hver producent af målere er strømmodulet forskellig. Det kan være en ekstern enhed til DIN-skinne eller en indbygget omformer.
Det viser sig, at vi altid skal have et sortiment af forskellige interfaces og strømmoduler til hver måler på vores lager. Sortimentet er imponerende.
Selvfølgelig, det er i sidste ende abonnenten, der betaler for det hele. Men han vil ikke vente en måned på, at den nødvendige enhed kommer. Han har brug for et tilbud på forbindelsen her og nu. Så det teknologiske ansvar ligger på vores skuldre.
Alt, hvad jeg har beskrevet, omsættes til et klart teknisk kort for forbindelsen, så ingeniørerne ude i marken ikke står ansigt til ansigt med noget ukendt i endnu en kælder og ved, hvad der kræves for at få det til at fungere.
Teknisk kort går hånd i hånd med den generelle retningslinje for tilslutning. For det er ikke nok blot at tilslutte tælleren til vores netværk; man skal også tilføje den omtalte VLAN til switchporten, udføre diagnostik og lave en prøvemåling. Vi stræber efter at maksimere automatiseringen af hele processen for at undgå fejl og ikke involvere unødvendige tekniske ressourcer.
Godt, vi har skrevet tekniske kort, retningslinje og automatisering. Vi har ordnet logistikken.
Hvor ligger der flere skjulte udfordringer?
Data læses og strømmer ind i databasen.
Abonnenten har ikke meget udbytte af disse tal. Han har brug for en rapport. Gerne i den form, han er vant til. Endnu bedre, hvis det straks er i en letforståelig rapport, som han kan udskrive, underskrive og aflevere. Det betyder, at der er brug for en enkel og klar brugerflade, der viser oplysninger om måleudstyret og kan generere rapporter automatisk.
Her fortsætter vores zoo. Sagen er, at der findes forskellige typer rapporter. De afspejler egentlig det samme (forbrugt varme), men på forskellige måder.
Nogle abonnenter rapporterer i absolutte værdier (det vil sige, i forbrugsfeltet skrives værdierne fra installationen af tælleren), mens andre rapporterer i forskelle (det er når vi angiver forbruget over en tidsperiode uden henvisning til startværdierne). I praksis anvender de ikke en entydig standard, men snarere en etableret praksis. Der har været tilfælde, hvor abonnenter ser alle de værdier, de har brug for (mængden af forbrugt varme, mængden af tilført og afgået varmebærer, temperaturforskellen), men kolonnerne i rapporten er ikke i den rigtige rækkefølge.
Derfor er næste skridt, at rapporten skal være tilpasselig. Det vil sige, at abonnenten selv vælger, hvilken rækkefølge elementerne skal være i, og hvilke ressourcer der finns i hans dokument.
Her er et interessant punkt. Alt er godt, hvis vores måleapparat er installeret korrekt. Men der kan opstå situationer, hvor installationsfirmaet, ved installationen af ITP, har lavet fejl og forkert har indstillet tiden på måleapparatet. Vi har set enheder, der tror — det er 2010. I vores system vil det se ud som nul værdier på den aktuelle dato, mens det reelle forbrug vil være, hvis man vælger 2010. Her er delfunktionerne en stor hjælp. Det vil sige, at vi siger, at der i de seneste 24 timer har været så og så meget.
Det kunne synes unødvendigt kompliceret? Er det så svært at indstille urene?
Netop med VKТ-7 vil det føre til en fuldstændig nulstilling af tælleren og sletning af arkiverne fra den.
Abonnenten vil blive tvunget til at bevise over for forsyningsselskaberne, at han installerede ITP for mere end et par dage siden, men nærmere for fem år siden.
Og til slut, kirsebæret på toppen.
Certificering
Vi har et måleapparat, vi har en rapport. Mellem dem står vores system, der genererer denne rapport. Stoler du på det?
Jeg gør. Men hvordan kan vi bevise, at der ikke ændres noget indeni, og at vi ikke forvrænger værdierne? Det er et spørgsmål om certificering. Systemet skal nødvendigvis have en certificering, der bekræfter dets objektivitet. Alle større systemer, såsom ЛЭРС, Я Энергетик og lignende, har sådan en certificering. Vi har også fået det, selvom det er dyrt og tager lang tid.
Selvfølgelig kan man altid tage genvejen og købe noget færdigt. Men det vil koste udvikleren. Og udvikleren kan bede om ikke kun et indskud, men også en abonnementsbetaling. Det vil sige, at vi vil være nødt til at dele en del af vores kage med ham.
Hvorfor alt dette?
Hovedproblemet ligger ikke her. At udvikle sit eget system er også meget dyrt og langt mere kompliceret. Men det giver en vigtig fordel. Vi forstår præcist, hvordan det fungerer. Vi kan nemt skalere det, vi kan modificere det, hvis der pludselig opstår et behov. Abonnenten får en mere omfattende service, og fra vores side har vi 100% kontrol over processen.
Netop derfor valgte vi den anden vej. I det har vi investeret et år af vores udvikleres og feltteknikeres liv. Men nu forstår vi klart, hvordan hele kæden fungerer.
Når jeg ser tilbage, forstår jeg, at uden de opnåede viden ville jeg simpelthen ikke have været i stand til at tolke unormalt adfærd af den ene eller den anden tæller korrekt.
Desuden kan der bygges noget mere på baggrund af dispatch-systemet. Alarmer ved overskridelse af forbrug, rapport om hændelser. Vi har snart et mobilapp klar.
Vi er gået endnu længere og har tilføjet muligheden for at modtage henvendelser fra beboere til vores platform (ellers kan man ikke kalde det noget andet), samt styring af vores "smarte dørtelefoner", kontrol over gadebelysning og flere projekter, som jeg endnu ikke har skrevet om.
Alt dette er kompliceret, hjernedræbende og tager lang tid. Men resultatet er det værd. Abonnenterne får et klarlagt, omfattende produkt.
Hver operatør, der planlægger at komme ind i boligsektoren, vil helt sikkert gå denne vej. Vil de gennemføre det?
Her er spørgsmålet. Det handler ikke engang om pengene. Som jeg nævnte tidligere, kræver det netop denne kombination af arbejde i marken og udvikling. Ikke alle store aktører er vant til det. Hvis jeres udviklere sidder i Moskva, mens installationerne udføres i Novosibirsk, vil det tage betydeligt længere tid at få produktet klar.
Tiden vil vise, hvem der vil forblive på dette marked, og hvem der vil sige — nej tak til det! Men én ting ved jeg helt klart — man kan ikke komme ind og tage en markedsandel kun med penge. Denne proces kræver kreative tilgange, dygtige ingeniører, dykning i reguleringer, kommunikation med ressourcer og abonnenter samt konstant identifikation og overvinde forhindringer.
P. S. I denne artikel har jeg bevidst fokuseret på varme og nævner ikke elektricitet eller vand. Jeg beskriver også tilslutning via kabel. Hvis vi har pulserende udgange — er der sine egne nuancer, såsom obligatoriske tjek efter installation. Det kan ske, at man ikke kan nå frem med en ledning, så træder LoRaWAN i brug. At beskrive hele vores platform og faserne i dens udvikling i én artikel er simpelthen umuligt.
Kilde: habr.com
