IoT szolgáltató jegyzetei. A közszolgáltatói mérők felmérésének buktatói

Üdvözöljük, kedves Internet of Things (IoT) kedvelők. Ebben a cikkben újra szeretnék beszélni a közszolgáltatásokról és a mérőeszközök kérdőívéről.

Időről időre egy újabb nagy szereplő a telekommunikációs piacon arról mesél, hogy hamarosan belép erre a piacra, és mindenkit alá fog húzni. Minden alkalommal, amikor hallgatom ezeket a meséket, azt gondolom: „srácok, sok szerencsét!”
El sem tudjátok képzelni, mibe vágtok bele.

Hogy megértsétek a probléma nagyságát, röviden elmesélem a tapasztalatunk egy részét az „Okos Város” platform kifejlesztéséről. Azokról a részekről, amelyek a diszpécser szolgáltatásokért felelnek.

IoT szolgáltató jegyzetei. A közszolgáltatói mérők felmérésének buktatói

Általános ötlet és az első nehézségek

Ha nem az egyéni mérőeszközökről beszélünk, hanem azokból, amelyek a pincékben, kazánházakban és vállalatoknál találhatók, akkor ezek túlnyomó többsége mostanra telemetrikus kimenettel van ellátva. Ritkábban impulzusos, gyakrabban – RS-485/232 vagy Ethernet. Általában a legjobban fizetett mérőeszközök azok, amelyek hőt mérnek. Éppen ezért a diszpécser szolgáltatásaikért hajlandók elsőként fizetni.
Már részletesen kifejtettem a cikkemben az RS-485 sajátosságait. Röviden: ez csupán egy adatátviteli interfész. Alapvetően az elektromos impulzusok és a kommunikációs vonalak követelményeit szabja meg. A csomagok leírása egy szinttel fentebb történik, az adatátviteli szabvány szerint, amely az RS-485 fölött működik. Hogy mi lesz ott a szabvány, az a gyártóra van bízva. Gyakran Modbus, de nem elengedhetetlen. Még ha Modbus is, lehet, hogy egy kicsit módosított verziója.

Alapvetően minden mérőeszközhöz saját lekérdező szkriptre van szükség, amely képes „beszélgetni” vele és lekérdezni azt. Ezért a diszpécser rendszer egy szkriptek gyűjteménye minden egyes számlálóhoz. Egy adatbázis, ahol mindez tárolva van. És egy felhasználói felület, amelyben létrehozhatja a szükséges jelentését.

IoT szolgáltató jegyzetei. A közszolgáltatói mérők felmérésének buktatói

Elsőre nem tűnik bonyolultnak. A gonosz, mint mindig, a részletekben rejlik.

Kezdjük az első résznél.

Szkriptek

Hogyan írjuk meg őket? Nos, nyilvánvalóan vásárolni kell egy mérőeszközt, szétszedni, megtanulni kommunikálni vele, és integrálni a közös platformba.

Sajnos ez a megoldás csak igényeink egy részét fogja kielégíteni. Általában egy népszerű mérőnek több generációja van, és a minden generációhoz tartozó szkript eltérő lehet. Néha kicsit, néha jelentősen. Amikor vásárolsz valamit, megkapod az utolsó generációt. A felhasználónak pedig valószínűleg régebbi verziója van. Az már nem kapható a boltokban. És a felhasználó nem fogja cserélni a mérőeszközt.

Itt van az első probléma. Az ilyen szkriptek írása szoros kapcsolatot igényel a szoftverfejlesztők és a „helyszíni” mérnökök között. Mi az utolsó generációt vásároltuk, írtunk egy alap sablont, majd ezt valós készülékekre módosítottuk. Ilyen laboratóriumi körülmények között nem valósítható meg, csak élő felhasználókkal folytatott munka során.

Sok időt töltöttünk e kapcsolat létrehozásával. Jelenleg az algoritmus működőképes. Az alap sablonokat folyamatosan korrigáltuk és kiegészítettük, a gyakorlatunk során szerzett tapasztalataink alapján. Természetesen értesítettük a felhasználót, ha a mérője kicsit „más” lett. Ha ilyen eszköz jelenik meg, az a szokásos séma szerint csatlakozik, és a lekérdező szkript a helyszínen módosul. Az integráció idején a felhasználó ingyen dolgozik. Tudomására hozzák, hogy jelenleg teszt üzemmódban van. Az integrációs folyamat meglehetősen kiszámíthatatlan dolog. Előfordul, hogy minimális módosításokat kell végrehajtani. Néha bonyolult folyamat következik be, amely telephelyre való kiutazással, irodalom átvizsgálásával és lépésről lépésre történő hibák kiküszöbölésével jár.

A feladat nem egyszerű, de megoldható. Az eredmény — egy működő szkript. Minél nagyobb a szkriptek könyvtára, annál könnyebb élni.

A második probléma.

Csatlakozási technológiai térképek

Hogy érzékelje a munka nehézségét, példának hozom fel a rendkívül népszerű VKT-7 hőmérőt.

A név önmagában még semmit nem mond számunkra. A VKT-7-nek több hardveres megoldása van. Milyen interfész található benne?

IoT szolgáltató jegyzetei. A közszolgáltatói mérők felmérésének buktatói

Több lehetőség is létezik. Lehet szabványos DB-9 csatlakozó (ez RS-232). Lehet sima csavaros terminál RS-485 érintkezőkkel. Sőt, akár RJ-45 hálózati kártya is, ebben az esetben a ModBus Ethernetbe van csomagolva.

Talán nem is kell semmit tenni. Csak egy sima mérőeszköz. Telepíteni lehet egy interfész kimenetet, amit külön értékesít a gyártó, és pénzbe kerül. A fő probléma az, hogy ehhez fel kell bontani a mérőt, és le kell bontani a plombákat. Tehát ebbe a folyamatba bevonják az energiaszolgáltatót. Értesítik őket, hogy a plombák fel lesznek bontva, kitűzik a napot, és mérnökünk a szolgáltató képviselője előtt elvégzi a szükséges módosításokat, majd a mérőeszközt újra plombálják.

A telepített interfésztől függően folytatódik a további fejlesztés. Például, ha úgy döntöttünk, hogy kábellel csatlakoztatjuk a mérőeszközt. Ez a legegyszerűbb megoldás, ha 100 méteres távolságon belül ott van a mi switch-ünk, akkor a LoRa használata felesleges. Egyszerűbb kábelen csatlakozni a hálózatunkhoz, egy izolált VLAN-hoz.

Az RS-485/232-hez Ethernet átalakító szükséges. Sokan azonnal a MOXA-ra gondolnak, de ez drága. Számunkra olcsóbb kínai megoldást választottunk.

Ha azonnal Ethernet kiépítés van, akkor átalakító nem szükséges.

Kérdés. Tegyük fel, hogy mi magunk telepítjük az interfész kimenetet. Megkönnyíthetnénk az életünket, és mindenhova Ethernet-et telepítenénk?

Nem mindig lehetséges. A ház kivitelét kell megnézni. Lehet, hogy nem lesz megfelelő nyílás, hogy az interfész megfelelően elhelyezkedjen. És emlékeztetem, hogy a mérő nálunk a pincében található. Vagy a kazánházban. Ott magas a páratartalom, a hermetikus zárást nem lehet megsérteni. Az ház megmunkálása reszelővel rossz ötlet. Jobb valami olyat választani, ami eleve nem igényel nagy módosításokat. Gyakran az RS-485 az egyetlen lehetőség.

Továbbá. Csatlakoztatva van a mérő biztosított tápellátáshoz? Ha nem, akkor elemmel működik. Ebben a módban havonta egyszer három perces kézi olvasásra van tervezve. A folyamatos megkeresés a VKP-7-et lemeríti. Tehát biztosított tápellátást kell húzni, és feszültségátalakítót kell telepíteni.

Minden mérőgyártónál a tápegység modul eltérő. Ez lehet egy külső blokk DIN sínre, vagy egy beépített átalakító.

Ezért a raktárunkban mindig különféle interfészek és tápegység modulok készletnek kell lennie minden mérőhöz. A választék ott jelentős.

Természetesen, végül mindezt az előfizető fizeti. De nem fog egy hónapot várni, amíg megérkezik a szükséges eszköz. Szüksége van a csatlakozásra vonatkozó költségvetésre itt és most. Így a technológiai tartalék a mi vállunkra nehezedik.

Minden, amit leírtam, egy világos technikai térképté alakul át a csatlakozáshoz, hogy a helyszíni mérnökök ne gondolják, hogy micsoda fenevadat látnak a következő pincében, és mi szükséges a működéséhez.

A technikai térkép párhuzamosan fut a csatlakozási általános szabályzattal. Hiszen elég, ha a mérőt csatlakoztatjuk a hálózatunkhoz, a switch portjára még rá kell rakni azt a VLAN-t, diagnosztikát kell végezni, és egy próbafelkérést végrehajtani. Az egész folyamatot maximálisan automatizálni igyekszünk, hogy elkerüljük a hibákat, és ne vonjunk be felesleges mérnöki erőforrásokat.

Jól van, megírtuk a technikai térképeket, a szabályzatot, az automatizálást. Beállítottuk a logisztikát.

Hol bújnak még meg a váratlan buktatók?

Az adatok leolvashatók és az adatbázisba kerülnek.

Az előfizetőt ez a számadatok nem izgatják. Számvitelre van szüksége. Lehetőleg abban a formában, ahogy megszokta. Még jobb, ha rögtön olyan érthető riport formájában, amelyet kinyomtathat, aláírhat és leadhat. Tehát, szükséges egy egyszerű és érthető felület, amely megmutatja a mérőeszköz adatait, és automatikusan képes jelentést generálni.

Itt folytatódik a mi kis állatkertünk. A jelentések formáinak többfélesége létezik. Lényegében ugyanazt tükrözik (a felhasznált hőmennyiséget), de különböző módokon.

Néhány előfizető abszolút értékekben számol (vagyis a hőfogyasztás oszlopába a mérő beszerelésétől kezdve szereplő értékek kerülnek), míg mások deltaértékekkel számolnak (ez akkor történik, amikor a fogyasztást egy időszakon keresztül írják, kezdeti értékekhez nem kötve). Lényegében nem egységes szabványokat használnak, hanem a kialakult gyakorlatot. Volt olyan eset, amikor az előfizetők elértek minden szükséges értéket (a felhasznált hőmennyiség, a bevezetett és távozó hőhordozó mennyisége, a hőmérsékletkülönbség), de az adatok oszlopai nem a megfelelő sorrendben álltak.
Erre a következő lépés — a jelentés testreszabható kell, hogy legyen. Vagyis az előfizető maga választja ki, hogy milyen sorrendben következnek az elemek, és milyen erőforrások állnak rendelkezésére a dokumentumban.

Itt van egy érdekes pont. Minden rendben, ha a mérőeszközünket helyesen telepítették. De néha előfordul, hogy a szerelőcsapat hibázik a hőtermelő telepítésénél, és helytelenül állítja be az időt a mérőeszközön. Találkoztunk olyan készülékekkel, amelyek azt hiszik, hogy 2010-ben járunk. A mi rendszerünkben ez nulla mért értékként jelenik meg a jelenlegi dátumra, míg a valós fogyasztás — ha 2010-es évet választunk. Itt nagyon jól jönnek a delta értékek. Tehát azt mondjuk, hogy az elmúlt 24 órában ennyi és ennyi mértékű érték gyűlt össze.

Úgy tűnne, miért is olyan bonyolult ez? Annyira nehéz volna beállítani az órákat?

Pont a VKP-7 esetében ez teljes nullázáshoz és az archívumok törléséhez vezet.
Az előfizetőnek be kell bizonyítania a szolgáltatóknak, hogy nem tegnap állították be a hőtermelőt, hanem már öt éve.

És végül, a torta csereszinje.

Tanúsítás

Van egy mérőeszközünk, van egy jelentésünk. Kettő között ott van a rendszerünk, ami ezt a jelentést megfogalmazza. Ön bízik benne?

Én igen. De hogyan bizonyítsam, hogy bennünket nem érint, ami belül zajlik, hogy nem torzítjuk az értékeket. Ez már a tanúsítással kapcsolatos kérdés. A kérdő rendszernek kötelezően rendelkeznie kell tanúsítvánnyal, amely igazolja pártatlanságát. Minden nagy rendszer, mint például a LERS, az Én Energetikám és mások, rendelkezik hasonló tanúsítvánnyal. Mi is megkaptuk, bár ez drága és sok időt vesz igénybe.

Természetesen mindig le lehet faragni a sarkokat és venni valamit készítettet. De ezért fizetni kell a fejlesztőnek. A fejlesztő kérheti nemcsak a belépési díjat, hanem havi díjat is. Tehát kénytelenek leszünk megosztani vele a tortánk egy részét.

Miért van ez az egész?

A fő probléma nem is itt van. A saját rendszerünk kidolgozása szintén nagyon drága és többszörösen nehezebb. Azonban fontos előnyt ad. Pontosan értjük, hogyan működik. Könnyen skálázhatjuk, módosíthatjuk, ha szükség adódik. Az előfizető teljes körű szolgáltatást kap, és a mi oldalunkon százszázalékos ellenőrzést biztosítunk a folyamat felett.

Ezért választottuk a második utat. Ebbe fektettük a fejlesztőink és a terepi mérnökeink egy évét. Most viszont pontosan értjük az egész lánc működését.

Visszatekintve rájövök, hogy a megszerzett tudás nélkül egyszerűen képtelen lettem volna helyesen értelmezni a különböző kapcsolatkezelők rendellenes viselkedését.

Ezen kívül a diszpécser-rendszeren alapulva valami többet is létre lehet hozni. Fogyasztási túllépések riasztása, balesetek jelentése. Hamarosan elkészül a mobilalkalmazásunk.

Még tovább mentünk, és a platformunkba (mert másként már nem is lehetne nevezni) beépítettük a lehetőséget, hogy megkereséseket fogadjanak az állampolgároktól, a „smart intercom” kezelését, az utcai világítás ellenőrzését és még néhány projektet, amelyekről eddig nem írtam.

IoT szolgáltató jegyzetei. A közszolgáltatói mérők felmérésének buktatói

Mindez bonyolult, agyterhelő és időigényes. De az eredmény megéri. Az előfizetők egy kész, átfogó terméket kapnak.

Minden szolgáltató, aki a közszolgáltatások piacára lép, kötelezően meg fogja tenni ezt az utat. Meg fogja tudni csinálni?
Ez egy fontos kérdés. A dolog nem is a pénzről szól. Ahogy fentebb írtam, szükség van a terepmunka és a fejlesztés összekapcsolására. Nem minden nagy szereplő szokott hozzá ehhez. Ha a fejlesztők Moszkvában ücsörögnek, míg az csatlakozások Novoszibirszkben történnek, akkor a kész termékhez szükséges idő lényegesen megnő.

Az idő megmutatja, ki tud tartósan megmaradni ezen a piacon, és ki mondja azt, hogy „menj a fenébe!” De egy dolgot biztosan tudok — a piaci részesedés megszerzéséhez pusztán pénzre nem lesz elegendő. Ez a folyamat egyedi megközelítéseket, jó mérnököket, szabályozással való foglalkozást, együttműködést az erőforrás-szolgáltatókkal és az előfizetőkkel, folyamatos problémák felderítését és leküzdését igényli.

P. S. Ebben a cikkben szándékosan a hőre összpontosítottam, és nem említem az elektromosságot vagy a vizet. A kábelcsatlakozást is ismertetem. Ha impulzusos kimenetünk van, ott olyan sajátosságok lépnek fel, mint az installálás utáni kötelező ellenőrzések. Előfordulhat, hogy a vezetékkel nem lehet elérni, akkor jön a LoRaWAN. Teljes mértékben bemutatni a platformunkat és a fejlesztési folyamatait egyetlen cikkben egyszerűen lehetetlen.

Forrás: habr.com

Megbízható hosting vásárlása weboldalak számára, DDoS védelemmel, VPS VDS szerverek. 🔥 Megbízható webtárhely vásárlása DDoS védelemmel, VPS VDS szerverek | ProHoster