Бележки на IoT доставчика. Клопки на избирателните измервателни уреди

Здравейте, скъпи фенове на Интернет на нещата. В тази статия бих искал отново да говоря за жилищно-комуналните услуги и проучване на измервателните уреди.

От време на време следващият голям телеком играч говори колко скоро ще влезе на този пазар и ще смаже всички под себе си. Всеки път, когато чуя подобни истории, си мисля: „Момчета, успех!“
Дори не знаеш къде отиваш.

За да разберете мащаба на проблема, ще ви разкажа накратко малка част от нашия опит в разработването на платформата Smart City. Тази част от него, която отговаря за изпращането.

Обща идея и първи трудности

Ако не говорим за индивидуални измервателни уреди, а за тези, които са в мазета, котелни помещения и предприятия, тогава повечето от тях вече са оборудвани с телеметричен изход. По-рядко импулсен, по-често - RS-485/232 или Ethernet. По правило най-полезните измервателни устройства са тези, които отчитат топлината. Те са готови да платят за тяхното изпращане на първо място.
Вече разгледах подробно характеристиките на RS-485 в моята статия. Накратко, това е просто интерфейс за пренос на данни. По същество това са изискванията за електрически импулси и комуникационни линии. Описанието на пакетите идва на по-високо ниво, в стандарта за предаване на данни, който работи върху RS-485. А какъв стандарт ще има, остава на производителя. Често Modbus, но не е необходимо. Дори и да е Modbus, пак може да е донякъде модифициран.

Всъщност всеки измервателен уред се нуждае от собствен скрипт за проучване, който може да „говори“ с него и да го разпитва. Това означава, че системата за изпращане е набор от скриптове за всеки отделен брояч. Базата данни, където се съхранява всичко това. И определен потребителски интерфейс, в който той може да генерира отчета, от който се нуждае.

Изглежда лесно. Дяволът, както винаги, е в детайлите.

Да започнем с първата част.

Scripts

Как да ги напиша? Е, разбира се, купете измервателно устройство, бърникайте с него, научете се да комуникирате с него и го интегрирайте в обща платформа.

За съжаление, това решение ще покрие само част от нашите нужди. Обикновено популярният брояч има няколко поколения и скриптът за всяко поколение може да е различен. Понякога малко, понякога много. Когато купувате нещо, вие получавате последно поколение. Абонатът най-вероятно ще има нещо по-старо. Вече не се продава по магазините. И абонатът няма да смени измервателния уред.

Оттук и първият проблем. Писането на такива скриптове е трудна комбинация от разработчици на софтуер и инженери „на място“. Купихме най-новото поколение, написахме някакъв първоначален шаблон и след това го модифицирахме на реални устройства. Невъзможно е да направите това в лаборатория, само докато работите с живи абонати.

Отне ни много време, за да създадем такъв пакет. Алгоритъмът вече е разработен. Първоначалните шаблони непрекъснато се коригираха и допълваха в зависимост от това, което срещахме в практиката си. Разбира се, абонатът беше предупреден, ако внезапно броячът му се оказа малко „изключен“. Когато се появи такова устройство, то се свързва по стандартната схема и скриптът на проучването се променя по пътя. По време на интеграцията абонатът работи безплатно. Информиран е, че в момента живее в тестов режим. Самият процес на интеграция е нещо доста непредвидимо. Понякога трябва да направите само минимални корекции. Може да има сложен процес, включващ ходене на обекта, изхвърляне на литература и последователно преодоляване на рейка.

Задачата не е лесна, но разрешима. Резултатът е работещ скрипт. Колкото по-голяма е библиотеката от скриптове, толкова по-лесен е животът.

Втори проблем.

Карти за технологично свързване

За да разберете сложността на тази работа, ще дам пример. Да вземем изключително популярния топломер VKT-7.

Самото име не ни казва нищо. VKT-7 има няколко железни решения. Какъв интерфейс има вътре?

Има различни варианти. Може да има щифт в стандартен блок DB-9 (това е RS-232). Може да е просто клемен блок с RS-485 контакти. Може би дори мрежова карта с RJ-45 (в този случай ModBus е пакетиран в Ethernet).

Или може би нищо. Просто голо измервателно устройство. Можете да инсталирате интерфейсен изход в него, той се продава отделно от производителя и струва пари. Основният проблем е, че за да го инсталирате, трябва да отворите измервателния уред и да счупите пломбите. Това означава, че организацията, доставяща ресурси, е включена в този процес. Тя е уведомена, че пломбите ще бъдат счупени, определя се ден и нашият инженер в присъствието на представител на ресурса прави необходимите промени, след което водомерът се пломбира отново.

В зависимост от инсталирания интерфейс се правят допълнителни модификации. Например, решихме да свържем измервателния уред чрез проводник. Това е най-простият вариант, ако превключвателят ни е в рамките на 100 метра, тогава работата с LoRa е излишна. По-лесно е да свържете кабел към нашата мрежа, към изолирана VLAN.

За RS-485/232 ви трябва конвертор към Ethernet. Мнозина веднага ще си спомнят MOHA, но е скъпо. За нашите решения избрахме по-евтино китайско решение.

Ако изходът е директно Ethernet, тогава не е необходим конвертор.

Въпрос. Да кажем, че сами инсталираме изхода на интерфейса. Можете ли да улесните живота си и веднага да инсталирате Ethernet навсякъде?

Това не винаги е възможно. Трябва да разгледаме дизайна на тялото. Може да няма необходимия отвор за интерфейса, за да пасне правилно. Напомням, че гишето е в мазето ни. Или в котелното помещение. Там има висока влажност, уплътнението не може да се счупи. Завършването на тялото с пила е лоша идея. По-добре е да инсталирате нещо, което първоначално не изисква големи промени. Често RS-485 е единственият изход.

По-нататък. Измервателният уред свързан ли е към гарантирано захранване? Ако не, тогава работи на батерия. В този режим той е предназначен за ръчно анкетиране веднъж месечно за три минути. Постоянният достъп до VKT-7 ще изтощи батерията му. Това означава, че трябва да осигурите гарантирано захранване и да инсталирате преобразувател на напрежение.

Захранващият модул е ​​различен за всеки производител на електромера. Това може да бъде външен модул за DIN шина или вграден конвертор.

Оказва се, че нашият склад винаги трябва да съхранява набор от различни интерфейси и захранващи модули за всеки измервателен уред. Обхватът там е впечатляващ.

Разбира се, всичко това в крайна сметка ще бъде платено от абоната. Но той няма да чака месец, докато пристигне правилното устройство. И той има нужда от оценка за връзка тук и сега. Така че технологичният резерв пада върху нашите плещи.

Всичко, което описах, се превръща в ясна техническа карта на връзката, така че местните инженери да не мислят какъв вид звяр са срещнали в следващото мазе и какво им е необходимо, за да работи.

Техническата карта е в непосредствена близост до общите разпоредби за присъединяване. В края на краищата не е достатъчно да включим измервателния уред в нашата мрежа; все още трябва да прикрепим същата VLAN към порта на комутатора, трябва да извършим диагностика и да направим тестово проучване. Ние се стремим да автоматизираме целия процес, доколкото е възможно, за да избегнем грешки и да не ангажираме излишни инженери.

Добре, написахме технически карти, наредби, автоматизация. Имаме изградена логистика.

Къде другаде има скрити капани?

Данните се четат и изсипват в базата данни.

Тези номера не правят абоната нито горещ, нито студен. Има нужда от доклад. За предпочитане във формата, в която е свикнал. Още по-добре е, ако е веднага под формата на отчет, който той може да разбере, който той може да разпечата, подпише и изпрати. Това означава, че се нуждаем от прост и разбираем интерфейс, който показва информация на измервателния уред и може автоматично да генерира отчет.

Тук нашата зоологическа градина продължава. Факт е, че има няколко формуляра за отчет. В основата си те отразяват едно и също нещо (консумирана топлина), но по различни начини.

Някои абонати отчитат в абсолютни стойности (т.е. в колоната за потребление на топлина стойностите се записват, започвайки от инсталирането на измервателния уред), други в делта (това е, когато пишем потреблението за определен период от време без позоваване на първоначалните стойности). Всъщност те не използват единни стандарти, а установени практики. Има случаи, когато абонатите виждат всички стойности, от които се нуждаят (количество консумирана топлина, обем на подаваната и изпускана охлаждаща течност, температурна разлика), но колоните в отчета не са в правилната последователност.
Следователно следващата стъпка - отчетът трябва да може да се персонализира. Тоест, абонатът сам избира какво да върви в каква последователност и какви ресурси има в неговия документ.

Тук има един интересен момент. Всичко е наред, ако нашият измервателен уред е инсталиран правилно. Но се случва инсталационната компания, когато инсталира ITP, да направи грешка и да зададе неправилно времето за измервателния уред. Срещали сме устройства, които си мислят, че са 2010 г. В нашата система това ще изглежда като нулеви показания за текущата дата и реално потребление, ако изберем 2010 г. Делтите са много полезни тук. Тоест казваме, че толкова много са се случили през последните XNUMX часа.

Изглежда, защо такива трудности? Толкова ли е трудно да си навиеш часовника?

Точно при VKT-7 това ще доведе до пълно нулиране на брояча и изтриване на архиви от него.
Абонатът ще бъде принуден да докаже на ресурсните служители, че е инсталирал ITP не вчера, а преди пет години.

И накрая, черешката на тортата.

сертифициране

Имаме измервателен уред и протокол. Между тях е нашата система, която генерира този отчет. вярваш ли й

Правя го. Но как да докажем, че нищо не се променя вътре в нас, че не изкривяваме смисъла. Това вече е въпрос на сертифициране. Системата за проучване трябва да има сертификат, който потвърждава нейната безпристрастност. Всички големи системи, като LERS, Ya Energetik и други имат подобен сертификат. Ние също го получихме, въпреки че е скъпо и отнема много време.

Разбира се, винаги можете да намалите ъгъла и да купите нещо готово. Но разработчикът ще трябва да плати за това. И разработчикът може да поиска не само входна такса, но и абонаментна такса. Тоест ще бъдем принудени да разделим част от баницата си с него.

Защо е всичко?

Това не е основният проблем. Разработването на собствена система също е много скъпо и много по-трудно. Въпреки това, той осигурява важно предимство. Ние ясно разбираме как работи. Лесно го мащабираме, можем да го модифицираме, ако внезапно възникне такава нужда. Абонатът получава по-пълно обслужване, а от наша страна XNUMX% контрол върху процеса.

Затова избрахме втория път. Инвестирахме една година от живота на нашите разработчици и полеви инженери в него. Но сега ние ясно разбираме работата на цялата верига.

Поглеждайки назад, разбирам, че без придобитите знания просто нямаше да мога да интерпретирам правилно необичайното поведение на конкретен брояч.

Освен това на базата на диспечерската система може да се изгради нещо повече. Аларми за прекомерна консумация, протокол за авария. Готвим се скоро да пуснем мобилно приложение.

Отидохме още по-далеч и добавихме към нашата платформа (няма друг начин да го наречем) възможността да получаваме заявки от жители, възможността да контролираме нашите „интелигентни домофони“, да контролираме уличното осветление и няколко други проекта, които не съм писал за още.

Всичко това е трудно, мъчително и отнема много време. Но резултатът си заслужава. Абонатите получават готов, цялостен продукт.

Всеки оператор, който планира да влезе в сектора на жилищните и комуналните услуги, определено ще поеме по този път. ще мине ли
Ето един въпрос. Дори не става въпрос за парите. Както писах по-горе, тук е необходима комбинация от работа на терен и развитие. Не всички големи играчи са свикнали с това. Ако вашите разработчици се намират в Москва и връзките се осъществяват в Новосибирск, тогава вашето време за крайния продукт се удължава значително.

Времето ще покаже кой ще остане на този пазар и кой ще каже - ами върви по дяволите! Но едно нещо знам със сигурност е, че няма да можете да дойдете и да вземете пазарен дял само с пари. Този процес изисква нестандартни подходи, добри инженери, ровене в регулаторите, комуникация с ресурсни служители и абонати, постоянно идентифициране и преодоляване на проблеми.

PS В тази статия съзнателно се фокусирах върху топлината и не споменах електричество или вода. Описвам и кабелната връзка. Ако имаме импулсен изход, има някои нюанси, като задължителни проверки след инсталацията. Възможно е кабелът да не бъде достигнат, тогава LoRaWAN влиза в действие. Просто е нереалистично да опишем цялата ни платформа и етапите на нейното развитие в една статия.

Източник: www.habr.com