Доброго дня, шановні любителі Інтернету Речів. У цій статті я б знову хотів поговорити про ЖКГ та опитування приладів обліку.
Періодично, черговий великий гравець телекому розповідає, коли він зайде на цей ринок і всіх підме під себе. Щоразу за таких розповідей я думаю: «хлопців, удачі!»
Ви навіть не уявляєте, куди лізете.
Щоб ви розуміли масштаб проблеми, коротко розповім невелику частину нашого досвіду з розробки платформи «Розумне Місто». Тієї її частини, що відповідає за диспетчеризацію.
Загальна ідея та перші складності
Якщо говорити не про індивідуальні прилади обліку, а ті, що стоять у підвалах, котельнях і на підприємствах, то більшість із них зараз оснащена телеметричним виходом. Рідше імпульсним, частіше – 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 рік. Тут дуже рятують дельти. Тобто ми говоримо, що минулої доби натикало стільки.
Здавалося б, навіщо такі складнощі? Так важко підвести годинник?
Саме з ВКТ-7 це призведе до повного обнулення лічильника та видалення архівів з нього.
Абонент буде змушений доводити ресурсникам, що поставив ІТП не вчора, а років п'ять як.
І, нарешті, вишенька на торті.
сертифікація
У нас є пристрій обліку, є звіт. Між ними наша система, яка цей звіт формує. Ви їй вірите?
Я так. Але як довести, що у нас усередині нічого не змінюється, що ми не спотворюємо значення. Це вже є питання сертифікації. Система опитування обов'язково повинна мати сертифікат, що підтверджує її неупередженість. Всі великі системи, такі як ЛЕРС, Я Енергетик та інші подібний сертифікат мають. Отримали його і ми, хоч це коштує дорого і займає багато часу.
Звісно, завжди можна зрізати кут і купити щось готове. Але за це доведеться платити розробнику. І розробник може попросити як вступний внесок, а й абонплату. Тобто, ми будемо змушені ділитися з ним частиною нашого пирога.
Навіщо воно все?
Головна проблема не в цьому. Розробка своєї системи - це теж дуже дорого і в рази важче. Однак вона дає важливу перевагу. Ми чітко розуміємо, як це працює. Ми легко її масштабуємо, ми можемо її модифікувати, якщо раптом виникла така потреба. Абонент отримує повніший сервіс, а з нашого боку стовідсотковий контроль за процесом.
Саме тому ми й обрали другий шлях. У нього ми вклали рік життя наших розробників та польових інженерів. Зате тепер ми чітко розуміємо роботу всього ланцюжка.
Озираючись назад, я розумію, що без отриманих знань просто не зміг би правильно інтерпретувати позаштатну поведінку того чи іншого лічильника.
Крім того, на основі системи диспечеризації можна збудувати щось більше. Аларми щодо перевищень споживання, звіт про аварії. У нас незабаром готується вихід мобільного додатку.
Ми пішли ще далі і до нашої платформи (а інакше це вже не назвеш) додали можливість приймати звернення від мешканців, можливість управління нашими «розумними домофонами», тут же контроль вуличного освітлення та ще кілька проектів, про які я поки що не писав.
Все це складно, мозкосломно і довго. Але результат того вартий. Абоненти отримують готовий всеосяжний продукт.
Кожен оператор, який планує йти у ЖКГ, обов'язково стане на цей шлях. Чи минеться?
Тут питання. Справа навіть не в грошах. Як я писав вище, тут потрібна саме зв'язка роботи в полі та розробки. Не всі великі гравці звикли до такого. Якщо ваші розробники сидять у Москві, а підключення робляться в Новосибірську, ваш час на готовий продукт значно розтягується.
Час покаже, хто втримається на цьому ринку, а хто скаже — та ну, його куди подалі! Але одне я знаю чітко — прийти і зайняти частку ринку виключно грошима не вдасться. Цей процес вимагає нешаблонних підходів, хороших інженерів, копання в регуляторі, спілкування з ресурсниками та абонентами, постійного виявлення та подолання граблів.
PS У цій статті я свідомо зосередився на теплі та не згадую електрику чи воду. Також я описую підключення по кабелю. Якщо у нас імпульсний вихід — там свої нюанси, як обов'язкові звіряння після встановлення. Можливо таке, що дротом не дотягнутися, тоді в хід йде LoRaWAN. Описати всю нашу платформу та етапи її розробки в одній статті просто нереально.
Джерело: habr.com