Hallo, geachte liefhebbers van het Internet der Dingen. In dit artikel wil ik opnieuw praten over de nutsvoorzieningen en het peilen van meetapparatuur.
Periodiek vertelt een nieuwe grote speler in de telecomsector hoe hij binnenkort deze markt zal betreden en iedereen onder zijn hoede zal nemen. Bij elke dergelijke aankondiging denk ik: "jongens, veel succes!"
Je kunt je niet voorstellen waar je je mee bezighoudt.
Om je de omvang van het probleem duidelijk te maken, zal ik kort een deel van onze ervaring met de ontwikkeling van het platform "Slimme Stad" toelichten. Het deel dat verantwoordelijk is voor de dispatching.
Het algemene idee en de eerste moeilijkheden
Als we het niet hebben over individuele meetapparatuur, maar over die in kelders, verwarmingsinstallaties en bedrijven, dan is het merendeel momenteel uitgerust met een telemetrie-uitgang. Minder vaak met een impulssignaal, vaker met RS-485/232 of Ethernet. Over het algemeen zijn de meest winstgevende meetapparaten die welke warmte meten. Precisie vanwege hun dispatching worden ze als eerste betaald.
Ik heb al gedetailleerd stilgestaan bij de kenmerken van RS-485 in mijn artikel. Kort gezegd is het gewoon een gegevensoverdrachtsinterface. In wezen zijn dit de vereisten voor elektrische impulsen en communicatielijnen. De beschrijving van de pakketten gaat een niveau hoger, in de gegevensoverdrachtsnorm die bovenop RS-485 werkt. En welke standaard dat zal zijn, is aan de fabrikant overgelaten. Vaak Modbus, maar dat is niet verplicht. Zelfs als het Modbus is, kan het alsnog enigszins gemodificeerd zijn.
In wezen heeft elke meter zijn eigen peilscript nodig, dat ‘decoa’ met hem kan communiceren en het kan peilen. Dit betekent dat het dispatchingsysteem een verzameling scripts is voor elke afzonderlijke meter. Een database waarin dit alles is opgeslagen. En een gebruikersinterface waarin de gebruiker het gewenste rapport kan genereren.
Het lijkt niet moeilijk. De duivel, zoals altijd, schuilt in de details.
Laten we beginnen met het eerste deel.
Scripts
Hoe schrijf je ze? Nou, het is duidelijk, koop een meetapparaat, open het, leer ermee communiceren en integreer het in het algemene platform.
Helaas dekt deze oplossing slechts een deel van onze behoeften. Gewoonlijk heeft een populaire meter verschillende generaties, en het script voor elke generatie kan verschillen. Soms iets, soms aanzienlijk. Door iets te kopen, ontvang je de nieuwste generatie. Een abonnee heeft zeer waarschijnlijk iets oudere. Dit wordt niet meer in de winkels verkocht. En de abonnee zal de meeteenheid niet wijzigen.
Hieruit voortvloeit het eerste probleem. Het schrijven van zulke scripts vereist een nauwe samenwerking tussen softwareontwikkelaars en ingenieurs "op het terrein". We kochten de laatste generatie, schreven een soort standaard sjabloon en modificeerden het daarna al op de werkelijke apparaten. Dit in een laboratorium te doen is onrealistisch, pas bij het werken met echte abonnees.
We hebben aanzienlijke tijd besteed aan het creëren van zo'n koppeling. Het algoritme is nu verfijnd. De initiële sjablonen werden voortdurend aangepast en aangevuld, afhankelijk van wat we in de praktijk tegenkwamen. Uiteraard werden de abonnees gewaarschuwd als hun meter plotseling iets "anders" bleek te zijn. Bij het verschijnen van een dergelijk apparaat wordt het aangesloten volgens het standaard schema en het enquête script wordt on-the-fly gewijzigd. Gedurende de integratie werkt de abonnee gratis. Hij wordt geïnformeerd dat hij voorlopig in testmodus opereert. Het hele integratieproces is een vrij onvoorspelbare aangelegenheid. Soms moeten er minimaal correcties worden aangebracht. Soms is het een ingewikkeld proces met een bezoek ter plaatse, het doorwerken van literatuur en het geleidelijk overwinnen van obstakels.
De taak is uitdagend, maar oplosbaar. Het resultaat is een werkend script. Hoe groter de bibliotheek aan scripts, hoe gemakkelijker het leven.
Het tweede probleem.
Technologische aansluitkaarten
Om u de complexiteit van dit werk te laten begrijpen, geef ik een voorbeeld. Laten we de extreem populaire warmtemeter VKT-7 nemen.
De naam zelf zegt ons nog niets. De VKT-7 heeft verschillende hardware-oplossingen. Wat voor interface heeft het van binnen?
Er zijn verschillende opties. Er kan output zijn via een standaard DB-9 connector (dit is RS-232). Het kan ook gewoon een aansluitblok zijn met RS-485 contacten. Of zelfs een netwerkpoort met RJ-45 (in dit geval wordt ModBus verpakt in Ethernet).
Misschien is het helemaal niets. Gewoon een kaal meetinstrument. Er kan een interface-uitgang in worden geïnstalleerd, deze wordt afzonderlijk door de fabrikant verkocht en kost geld. Het grootste probleem is dat voor de installatie ervan het tellertje opengebroken moet worden en de zegels moeten worden verbroken. Dit betekent dat de energievoorzieningsorganisatie bij dit proces betrokken moet worden. Ze worden geïnformeerd dat de zegels zullen worden verbroken, er wordt een datum vastgesteld en onze ingenieur voert in aanwezigheid van een vertegenwoordiger van de energieleverancier de noodzakelijke aanpassingen uit, waarna het meetinstrument weer wordt verzegeld.
Afhankelijk van de geïnstalleerde interface worden er verdere aanpassingen gemaakt. Bijvoorbeeld, we hebben besloten het meetinstrument bedraad aan te sluiten. Dit is de eenvoudigste optie; als er binnen 100 meter onze switch is, is het overdreven om met LoRa te werken. Simpelweg met een kabel naar ons netwerk, in een geïsoleerde VLAN.
Voor RS-485/232 is een converter naar Ethernet nodig. Velen zullen meteen MOXA herinneren, maar dat is duur. Voor onze oplossingen hebben we een goedkopere Chinese variant gekozen.
Als de uitgang direct Ethernet is, is een converter niet nodig.
Vraag. Stel dat we zelf de interface-uitgang installeren. Kunnen we ons leven makkelijker maken door overal meteen Ethernet te installeren?
Dat is niet altijd mogelijk. We moeten kijken naar de behuizing. Deze heeft misschien niet het juiste gat om de interface goed te plaatsen. En het meetinstrument, ter herinnering, staat in onze kelder. Of in de ketelruimte. Daar is hoge luchtvochtigheid, en de luchtdichtheid mag niet worden beschadigd. De behuizing met een vijl aanpassen is een slecht idee. Het is beter om iets te installeren dat oorspronkelijk niet veel aanpassingen vereist. Vaak is RS-485 de enige optie.
Verder. Is het meetinstrument aangesloten op gegarandeerde voeding? Als dat niet het geval is, werkt het op een batterij. In deze mode is het ontworpen voor een handmatige uitlezing eens per maand van drie minuten. Continue toegang tot de VKT-7 zal de batterij ontladen. Dus, het is nodig om gegarandeerde voeding aan te leggen en een spanningsconverter te installeren.
Voor elke fabrikant van meetinstrumenten verschilt de voedingsmodule. Dit kan een externe blok op de DIN-rail zijn of een ingebouwde converter.
Het resultaat is dat er altijd een set verschillende interfaces en voedingsmodules voor elk meetinstrument op ons magazijn moet worden opgeslagen. Het assortiment daar is aanzienlijk.
Natuurlijk, uiteindelijk betaalt de abonnee hiervoor. Maar hij gaat geen maand wachten tot het benodigde apparaat arriveert. Hij heeft een kostenraming voor de aansluiting hier en nu nodig. Dus de technologische voorraad rust op onze schouders.
Alles wat ik beschreef, wordt omgezet in een duidelijke technische aansluitkaart, zodat ingenieurs ter plaatse niet hoeven na te denken over welke apparaten ze in een andere kelder tegenkomen en wat ze nodig hebben voor hun werking.
De technische kaart gaat samen met de algemene richtlijnen voor de aansluiting. Immers, het is niet genoeg om de meter aan ons netwerk te koppelen; we moeten ook de juiste VLAN op de switchpoort instellen, diagnostiek uitvoeren en een proefafname doen. We proberen het hele proces zo veel mogelijk te automatiseren om fouten te vermijden en onnodige hulp van ingenieurs te voorkomen.
Prima, we hebben technische kaarten, richtlijnen en automatisering geschreven. We hebben de logistiek geregeld.
Waar zijn er nog meer verborgen obstakels?
De gegevens worden gelezen en naar de database gestuurd.
Voor de abonnee betekenen deze cijfers helemaal niets. Hij heeft een rapport nodig. Bij voorkeur in de vorm die hij gewend is. Nog beter is het als het meteen in de begrijpelijke vorm van een rapport is, dat hij kan afdrukken, ondertekenen en indienen. Dat betekent dat we een eenvoudige en duidelijke interface nodig hebben die informatie over de meetinrichting toont en automatisch een rapport kan genereren.
Hier gaat onze chaos verder. Het punt is dat er verschillende rapportformats zijn. In wezen weerspiegelen ze hetzelfde (geconsumeerde warmte), maar op verschillende manieren.
Sommige abonnees rapporteren in absolute waarden (dat wil zeggen, in de kolom van warmteverbruik staan waarden vanaf de installatie van de meter), terwijl anderen rapporteren in veranderingen (dit is wanneer we het verbruik over een bepaalde periode zonder referentie naar de beginwaarden schrijven). In wezen gebruiken ze geen uniforme standaarden, maar de bestaande praktijk. Er waren situaties waarin abonnees alle waarden zagen die ze nodig hadden (hoeveelheid geconsumeerde warmte, hoeveelheid aangevoerde en afgevoerde warmteoverdracht, temperatuurverschil), maar de kolommen in het rapport stonden niet in de juiste volgorde.
Hieruit volgt de volgende stap: het rapport moet configureerbaar zijn. Dat betekent dat de abonnee zelf kiest in welke volgorde de gegevens komen en welke bronnen er in zijn document zijn.
Hier is een interessant punt. Alles is goed, als ons meetinstrument correct is geïnstalleerd. Maar het komt voor dat de installatieorganisatie bij het installeren van de ITP fouten heeft gemaakt en de tijd voor het meetinstrument verkeerd heeft ingesteld. We hebben apparaten gezien die denken dat het 2010 is. In ons systeem zal dit eruitzien zoals nulwaarden op de huidige datum, terwijl het werkelijke verbruik — als je het jaar 2010 kiest. Hier zijn deltas erg nuttig. We zeggen dat er in de afgelopen 24 uur zoveel geregistreerd is.
Het lijkt misschien een ingewikkelde kwestie. Is het zo moeilijk om de klok gelijk te zetten?
Precies met de WKT-7 leidt dit tot een volledige nulstelling van de meter en tot het verwijderen van archieven.
De abonnee zal moeten bewijzen aan de leveranciers dat hij de ITP niet gisteren heeft geplaatst, maar al vijf jaar geleden.
En tot slot, de kers op de taart.
Certificering
We hebben een meetinstrument, we hebben een rapport. Tussen hen in ons systeem dat dit rapport genereert. Geloof je het?
Ja, ik wel. Maar hoe bewijs je dat er intern niets verandert, dat we de waarden niet verdraaien? Dat is al een kwestie van certificering. Het systeem voor enquêtes moet noodzakelijkerwijs een certificaat hebben dat zijn onpartijdigheid bevestigt. Alle grote systemen, zoals LERS, Ik Ben Energie en andere, hebben zo'n certificaat. We hebben het ook ontvangen, hoewel het duur is en veel tijd kost.
Natuurlijk kun je altijd de hoek afsnijden en iets kant-en-klaars kopen. Maar daarvoor moet je de ontwikkelaar betalen. En de ontwikkelaar kan niet alleen een instapvergoeding vragen, maar ook een abonnementsprijs. Dat betekent dat we gedwongen zullen worden een deel van onze taart met hem te delen.
Waar dient dit allemaal voor?
Het belangrijkste probleem ligt niet daar. Het ontwikkelen van ons eigen systeem is ook erg duur en veel moeilijker. Het biedt echter een belangrijk voordeel. We begrijpen precies hoe het werkt. We kunnen het gemakkelijk opschalen en we kunnen het aanpassen indien nodig. De abonnee krijgt een vollediger service, en van onze kant is er 100% controle over het proces.
Precies daarom hebben we voor de tweede optie gekozen. We hebben hier een jaar van het leven van onze ontwikkelaars en veldingenieurs in geïnvesteerd. Maar nu begrijpen we de werking van de gehele keten heel goed.
Als ik terugkijk, besef ik dat ik zonder de verworven kennis gewoon niet in staat zou zijn geweest om de onregelmatige gedragingen van een bepaalde meter correct te interpreteren.
Bovendien kan er op basis van het dispatchingsysteem iets groters worden opgebouwd. Alarmeringen bij overschrijding van verbruiken, rapporten over storingen. We hebben binnenkort de lancering van een mobiele applicatie.
We zijn nog verder gegaan en hebben de mogelijkheid toegevoegd om verzoeken van bewoners te ontvangen in ons platform (anders kunnen we het niet noemen), evenals het beheer van onze 'slimme intercoms', directe controle over straatverlichting en nog een paar projecten waarover ik tot nu toe niet heb geschreven.
Dit alles is complex, breinvermoeiend en tijdrovend. Maar het resultaat is het waard. Abonnees krijgen een kant-en-klaar, allesomvattend product.
Elke operator die van plan is om de woningbouwsector in te gaan, zal onvermijdelijk dit pad moeten bewandelen. Zullen ze dat ook daadwerkelijk doen?
Dat is de vraag. Het gaat zelfs niet om geld. Zoals ik eerder schreef, is er echt een koppeling nodig tussen het werk in het veld en de ontwikkeling. Niet alle grote spelers zijn gewend aan zoiets. Als je ontwikkelaars in Moskou hebt en de aansluitingen in Novosibirsk worden gedaan, dan verlengt dat de tijd tot een kant-en-klaar product aanzienlijk.
De tijd zal leren wie zich op deze markt kan handhaven en wie zegt: laat maar. Maar één ding weet ik zeker — alleen met geld de markt betreden en een aandeel claimen zal niet lukken. Dit proces vereist originele benaderingen, goede ingenieurs, graven in de regelgeving, communicatie met energiebedrijven en abonnees, en constante ontdekking en overwinnen van obstakels.
P.S. In dit artikel heb ik me bewust gericht op warmte en noem ik elektriciteit of water niet. Ik beschrijf ook de aansluiting via kabel. Als we een impulsuitgang hebben, zijn er speciale nuances, zoals verplichte controles na de installatie. Het kan zijn dat je met een draad niet kunt reiken, dan komt LoRaWAN in beeld. Het is gewoon niet mogelijk om ons hele platform en de fasen van de ontwikkeling in één artikel te beschrijven.
Bron: habr.com
