Здравейте, уважаеми любители на Интернет на нещата. В тази статия бих искал отново да говоря за ЖКХ и анкетата относно измервателните уреди.
Периодично, някой голям играч в телекомуникациите обявява как скоро ще навлезе на този пазар и ще прилапа всичко. Всеки път, когато чувам подобни истории, си мисля: «Успех, момчета!»
Вие дори не можете да си представите в какво се заблуждавате.
За да разберете мащаба на проблема, ще споделя кратка част от нашия опит в разработката на платформата «Умен Град». Става въпрос за частта, която отговаря за диспечерирането.
Общата идея и първоначалните трудности
Ако говорим не за индивидуални измервателни уреди, а за тези, които се намират в мазета, котли и предприятия, то по-голямата част от тях в момента са оборудвани с телеметричен изход. Рядко импулсен, по-често — RS-485/232 или Ethernet. Като правило, най-„печелившите“ измервателни уреди са тези, които измерват топлина. Именно за тяхното диспечериране са готови да платят на първо място.
Вече подробно разглеждах в статията си особеностите на RS-485. Накратко — това е просто интерфейс за предаване на данни. Всъщност — изисквания към електрическите импулси и линията на свързване. Описанието на пакетите е на едно по-високо ниво, в стандарта за предаване на данни, който работи над RS-485. Какъв стандарт ще бъде там — е оставено на производителя. Често е Modbus, но не е задължително. Дори и да е Modbus, той все пак може да бъде известна модификация.
Всъщност, за всеки измервателен уред е нужен свой собствен скрипт за запитване, който да може да „разговаря“ с него и да го запитва. Това означава, че системата за диспечериране — е набор от скриптове за всеки отделен брояч. База данни, в която всичко това се съхранява. И някакъв интерфейс за потребителя, в който той може да състави необходимия му отчет.
Изглежда несложно. Дяволът, както винаги, е в детайлите.
Нека започнем с първата част.
Скриптове
Как да ги напишем? Очевидно, трябва да купим измервателен уред, да го разглобим, да научим как да комуникираме с него и да го интегрираме в основната платформа.
За съжаление, това решение ще покрие само част от нашите нужди. Обикновено популярният измервател имат няколко поколения, и скриптът за всяко поколение може да се различава. Понякога малко, понякога значително. Купувайки нещо, получавате последното поколение. Докато абонатът с висока вероятност ще има нещо по-стара. То вече не се продава в магазините. А абонатът няма да иска да смени измервателния уред.
Оттук идва и първият проблем. Написването на такива скриптове е стриктна свързаност на софтуерните разработчици и инженерите на място. Купувахме последното поколение, пишехме някакъв начален шаблон и после го модифицирахме на реални устройства. Да се направи това в лаборатория е нереалистично, само по време на работа с живи абонати.
Отне ни доста време да създадем такава свързаност. Сега алгоритмът е отработен. Началните шаблони постоянно се коригираха и допълваха в зависимост от това, което срещахме в практиката си. Разбира се, абонатът беше предупреден, ако случайно неговият измервател не се оказа точно "такъв". При появата на такова устройство, то се свързва по стандартната схема и скриптът за опит се модифицира по време на работа. През времето на интеграцията абонатът работи безплатно. Уведомяват го, че в момента е в тестов режим. Самият процес на интеграция е доста непредсказуем. Понякога е необходимо да се направят минимални корекции. Понякога е сложен процес с излизане на обекта, проучване на литературата и последователно преодоляване на трудности.
Задачата не е лесна, но е решима. Резултатът е работещ скрипт. Колкото по-голяма е библиотеката от скриптове, толкова по-лесно е животът.
Вторият проблем.
Технологични карти за свързване
За да осъзнаете сложността на тази работа, ще дам пример. Нека вземем изключително популярния топломер ВКТ-7.
Самото име не означава нищо конкретно. ВКТ-7 има няколко хардуерни решения. Какъв интерфейс има вътре?
Има различни варианти. Може да има изход на стандартен конектор DB-9 (това е RS-232). Може да е просто клемна кутия с контакти RS-485. Може дори да има мрежова карта с RJ-45 (в този случай ModBus се опакова в Ethernet).
А може и нищо. Просто гол уред за отчитане. В него може да се инсталира интерфейсен изход, който се продава отделно от производителя и струва пари. Основният проблем е, че за неговата инсталация трябва да се наруши запечатването на измервателя. Тоест, в този процес се включва организацията, предоставяща ресурсите. Те трябва да бъдат уведомени, че запечатването ще бъде счупено, назначава се ден, а нашият инженер в присъствието на представител на ресурсите извършва необходимите довършителни работи, след което устройството отново се запечатва.
В зависимост от инсталирания интерфейс се извършват допълнителни обработка. Например, решихме да свържем устройството за отчитане с кабел. Това е най-простият вариант; ако в 100-метрова достъпност имаме нашия комутатор, то мудренето с LoRa е излишно. По-добре е с кабел в нашата мрежа, в изолирана VLAN.
За RS-485/232 е нужен конвертор в Ethernet. Много хора веднага си спомнят за МОХА, но това е скъпо. За нашите решения избрахме китайско решение на по-ниска цена.
Ако изходът веднага е Ethernet, то конвертор не е нужен.
Въпрос. Да приемем, че сами инсталираме интерфейсен изход. Може ли да си улесним живота и веднага да поставим Ethernet навсякъде?
Не винаги е възможно. Трябва да се гледа на конструкцията на корпуса. Може да няма необходимата дупка, за да влезе интерфейсът както трябва. И да напомня, че измервателят е поставен в мазето. Или в котелното. Там влажността е висока, не може да се нарушава херметичността. Подобрявањето на корпуса с фин търговец е лоша идея. По-добре е да се постави нещо, което първоначално не изисква големи преизчисления. Често RS-485 е единственото решение.
Следващият въпрос. Свързан ли е измервателят с гарантирано захранване? Ако не, той работи на батерии. В този режим е предвиден за ръчен обход веднъж на месец за три минути. Постоянното обаждане към ВКТ-7 ще изтощи батерията му. Следователно, трябва да се изтегли гарантирано захранване и да се постави преобразувател на напрежение.
За всеки производител на измерватели модулът за захранване е различен. Това може да е външен блок на DIN шина или вграден преобразувател.
Оказва се, че на нашия склад винаги трябва да се съхранява набор от различни интерфейси и модули за захранване за всеки измервател. Номенклатурата е внушителна.
Разбира се, в крайна сметка всичко това ще бъде платено от абоната. Но той няма да чака един месец, за да получи необходимото устройство. И му е нужна оферта за свързване тук и сега. Така че технологичната тежест пада на нашите плещи.
Всичко, което описах, се обогатява в ясна техническа карта за свързване, за да не се чудят инженерите на място какво е това животно, с което се сблъскват в поредния мазе и какво им е нужно, за да работи.
Техническата карта съжителства с общите правила за свързване. Все пак не е достатъчно просто да включим брояча в нашата мрежа, на порта на комутатора трябва да добавим съответния VLAN, необходимо е да проведем диагностика и да направим пробно запитване. Целият процес се стремим да автоматизираме максимално, за да избегнем грешки и да не ангажираме излишни сили на инженерите.
Добре, написахме технически карти, правила, автоматизация. Наложихме логистика.
Къде още се крият подводни камъни?
Данните се четат и постъпват в базата.
На абоната тези цифри не му е горещо и не му е студено. Нему е нужен отчет. Желателно в вида, в който е свикнал. Още по-добре, ако веднага е в разбираем за него формат, който може да отпечата, да сложи подпис и да предаде. Значи, нужен е прост и разбираем интерфейс, който показва информация за измервателния уред и може автоматично да генерира отчет.
Тук нашият зоопарк продължава. Работата е там, че отчетите са няколко. По същество те отразяват едно и също (изразходеното топло), но по различни начини.
Някои от абонатите докладват в абсолютни стойности (тоест в колоната за потребление на топло се записват стойности, започващи от инсталирането на брояча), а някои в делти (това е когато записваме потреблението за период от време без привязване към началните стойности). Всъщност, те използват не единни стандарти, а утвърдена практика. Имало е случаи, когато абонатите виждат всички тези стойности, от които се нуждаят (количеството изразходено топло, обема на подаденото и изтегленото топлоносител, разликата в температурите), но колоните в отчета не са в правилната последователност.
Оттук следващата стъпка — отчетът трябва да е настройваем. Тоест, абонатът сам избира какво да бъде в каква последователност и какви ресурси са налични в неговия документ.
Тук е интересен момент. Всичко е наред, ако нашият измервателен уред е инсталиран правилно. Но понякога монтажната организация сбърква и неправилно настройва времето на измервателя. Срещали сме устройства, които мислят, че е 2010 година. В нашата система това ще изглежда като нулеви показания за текущата дата, а реалното потребление — ако изберем 2010 година. Тук много помагат делтите. Тоест, казваме, че през последните 24 часа е набрало толкова.
Изглежда, защо са тези сложности? Толкова трудно ли е да се настроят часовете?
Точно с ВКТ-7 това ще доведе до пълно нулиране на измервателя и изтриване на архивите от него.
Абонатът ще бъде принуден да доказва на ресурсите, че е инсталирал ИТП не вчера, а вече пет години.
И накрая, вишенката на тортата.
Сертификация
Имаме измервателен уред, имаме отчет. Между тях е нашата система, която генерира този отчет. Вярвате ли й?
Аз — да. Но как да докажа, че вътре нищо не се променя, че не изопачаваме стойностите. Това вече е въпрос на сертификация. Системата за опрос трябва задължително да има сертификат, който потвърджава нейната безпристрастност. Всички големи системи, като ЛЕРС, Я Енергетик и други, имат подобен сертификат. Получихме го и ние, въпреки че струва скъпо и отнема много време.
Разбира се, винаги може да се реже ъгъл и да се купи нещо готово. Но за това ще се наложи да платим на разработчика. И разработчикът може да поиска не само входяща такса, но и абонаментна такса. Тоест, ще бъдем принудени да споделяме част от нашия пай с него.
Защо всичко това?
Основният проблем не е в това. Разработката на собствена система също е много скъпа и многократно по-трудна. Въпреки това, тя дава важно предимство. Ние ясно разбираме как работи. Лесно е да я мащабираме, можем да я модифицираме, ако внезапно се появи такава нужда. Абонатът получава по-пълен сервис, а от наша страна — сто процента контрол над процеса.
Точно затова избрахме втория път. В него вложихме година живот на нашите разработчици и полеви инженери. Затова сега ясно разбираме работата на цялата верига.
Оглядайки се назад, разбирам, че без получените знания просто не бих могъл правилно да интерпретирам нештатното поведение на този или онзи измервател.
Освен това, на базата на системата за диспечеризация можем да изградим нещо по-голямо. Аларми за превишаване на потреблението, отчет за инциденти. Скоро ще пуснем мобилно приложение.
Отидохме още по-далеч и в нашата платформа (иначе не може да се нарече) добавихме възможността да приемаме запитвания от жителите, управление на нашите "умни домофони", контрол на уличното осветление и още няколко проекта, за които все още не съм писал.
Всичко това е сложно, мозъколомно и времево обременително. Но усилията си заслужават. Абонатите получават готов всестранен продукт.
Всеки оператор, който планира да навлезе в ЖКХ, задължително ще поеме по този път. Дали ще успее?
Тук е въпросът. Работата не е само в парите. Както писах по-горе, необходима е точно връзката между полевата работа и разработката. Не всички големи играчи са свикнали с подобно нещо. Ако вашите разработчици са в Москва, а свързванията се правят в Новосибирск, времето ви за готов продукт ще се удължи значително.
Времето ще покаже кой ще се задържи на този пазар и кой ще каже — да, но оставам настрана! Но едно знам със сигурност — да дойдеш и да заемеш пазарен дял само с пари, няма да стане. Този процес изисква нестандартни подходи, добри инженери, проучване на регулациите, комуникация с ресурсоснабдителите и абонатите, постоянно откриване и преодоляване на трудности.
P. S. В тази статия умишлено се фокусирах на топлината и не споменавам електричество или вода. Също така описвам свързването по кабел. Ако имаме пулсов изход, там има свои нюанси, като например задължителни сверки след инсталиране. Може да се случи така, че да не може да се достигне с кабел, тогава се използва LoRaWAN. Описването на цялата наша платформа и етапите на нейното разработване в една статия е просто невъзможно.
Източник: habr.com
