Про нові підходи до системи диспетчеризації у ЖКГ і не лише

Нині з розвитком новітніх технологій, штучного інтелекту, роботів тощо, одночасно зростає попит на загальну комп'ютеризацію або як зараз заведено говорити диджиталізацію різних сфер нашого життя. Більшість інструментів і методів цієї так званої діджиталізації відбулися або природно сформувалися з сегмента ІТ, який обслуговував банківський сектор, соціальні мережі, інтернет продажу, ґрунтуючись на великих базах даних клієнтів, обробку запитів у браузері, використання особистих даних користувачів з метою реклами чи просування різних онлайн продуктів, або послуг.

В автоматиці просування нових технологій не відбувається так швидко як у ІТ. Пов'язано це в основному з необхідністю вкладення великих коштів та часу для розробки та впровадження нових стандартів, на яких працюють мільйони підприємств, у яких термін окупності вкладених коштів досить довгий. Одного разу куплені машини або верстати повинні відпрацювати кошти, вкладені в них і заробити на нові ще пару десятків років, поки просто не прийдуть у непридатність з механічних причин.

З вищесказаного можна дійти невтішного висновку, що роботи з штучним інтелектом швидше з'являться в іграшковому відділі, а чи не на серйозному підприємстві.

Також це стосується підходів до диспетчеризації або, якщо взяти глобальніше, то навіть можна сказати моніторингу, відстеження, документування та контролю всього життєвого циклу виробництва. (MES систем)

А саме – у чому складність створення подібних систем:

- Зазвичай диспетчеризацією займаються глобально фірми, які мають у своєму складі багато програмістів, які «заточені» під розробку ІТ проектів і мало знайомі з технологією

- технологія поділена на локальні ділянки, за які відповідають та постачають різні, незв'язані між собою фірми (наприклад - ділянка холоду та вентиляції)

- немає домовленості між розробками локальних систем у виборі єдиного інтерфейсу обміну даними, у кожному окремому випадку це можуть бути абсолютно не взаємодіючі між собою протоколи, що призводить до збільшення в загальній мережі різного шлюзу, перетворювачів інтерфейсу і т.д. подорожчання та ускладнення всієї системи в цілому

- замовник не має конкретного ТЗ на бажану систему. Зазвичай все зводитися до фрази: необхідно стежити за всім, контролювати все і що система була зрозуміла і могла обслуговуватися слюсарем, що приходить, або в кращому випадку інженером КВП.

Таким чином отримуємо мега дорогу і ненадійну систему зліплену за образом і подобою системи, народженої в голові у основного підрядника, при тому необхідно переконати кінцевого правовласника, що він отримав найкращу систему у світі за невеликі гроші.

Внаслідок всього вище переліченого напрошується питання про те, як можна поміняти систему побудови диспетчеризації, що б вона природно розвивалася і будувалася за принципом камінь до каменю і крок за кроком, а не побудов замків на піску або хто покладе останній сірник на збудований сірниковий будиночок поки він не звалиться.

Застосування з поділом оплати. Оновлення систем на нові версії із одночасним розвитком стандартів обміну між системами.

Спробуємо визначити ці властивості та основи, на яких повинні будуватися подібні системи.

- Розбиття глобальної системи диспетчеризації на локальні системи за технологіями:

Наприклад, такі як:

1. Електрика (електричні лічильники, аналізатори якості електроенергії, що підводиться, використання генераторів, робота АВР)
2. Теплопункт (лічильники тепла, робота опалення та ГВП – завдання оптимальної температури в приміщенні, зниження споживання на ніч за графіком, миттєва реакція на затоплення теплопункту з додзвоном до відповідних служб, визначення несанкціонованого проникнення, захист від граничних значень температур та вибору оптимальної роботи системи)
3. Прибудинкові системи протипожежного захисту.
4. Робота ліфтів.
5. Розумне освітлення та камери спостереження

Кожна локальна система має вміти працювати незалежно від інших із можливістю підключення до глобальної системи диспетчеризації.

Для цього необхідно визначити другу властивість для локальних систем

- Вибір транспортного рівня, для передачі на інші рівні

На даний момент існує досить багато протоколів яких можна задіяти, але спробуємо виділити ті, які можуть зайняти місце глобальних для з'єднання локальних систем, наприклад:

1. OPC UA - OPC Unified Architecture [Специфікація OPC UA поєднує всі переваги попередніх специфікацій і відкриває нові горизонти для застосування OPC-технологій. Зокрема, завдяки тому, що відбулася відмова від використання COM-інтерфейсу, забезпечується крос-платформна сумісність. Новий стандарт вже спочатку дозволяє забезпечити більш високий рівень безпеки даних, ніж OPC DA. Крім того, нова специфікація дає можливість організації передачі інформації через мережу інтернет. 
2. API Прикладний програмний інтерфейс у WEB При використанні прикладного програмного інтерфейсу в контексті веброзробки, як правило, ППІ визначається набором повідомлень запиту HTTP, також визначається структура повідомлень-відповідей, зазвичай у розширенні мови розмітки XML або в форматі об'єктного запису JavaScript (JSON). У той час як прикладний програмний інтерфейс у Web історично був практично синонімом для вебслужби, останнім часом тенденція змінилась (так званий Web 2.0) на відхід від Simple Object Access Protocol (SOAP) на основі вебсервісів і сервіс-орієнтованої архітектури (SOA) на більш прямі передачі репрезентативного стану (REST) стилів вебресурсів та ресурсоорієнтованої архітектури (ROA). Частина цієї тенденції пов'язана з рухом Семантичного вебресурсу до Опису Платформ (RDF), Концепції розвитку вебтехнологій інженерних онтологій. Прикладні програмні інтерфейси у Web, що дозволяють комбінувати декількома прикладними програмними інтерфейсами в нові додатки називають гібридними.
3. MQTT Протокол орієнтується на простоту використання, невисоке навантаження на канали зв'язку, роботу у умовах постійної втрати зв'язку, легку вбудовуваність у систему. Основне призначення - робота з телеметрією від різних датчиків і пристроїв. Використання шаблону передплатника забезпечує можливість пристроям виходити на зв'язок і публікувати повідомлення, які не були заздалегідь відомі або зумовлені, зокрема, протокол не вводить обмежень на формат даних, що передаються.

- розподіл локальної системи диспетчеризації на окремі фрагменти у разі більшої кількості контролерів учасників у системі

Наприклад, якщо в системі теплопункту використовується 8 контролерів розосереджених у віддалених системах будинку - опалення, ГВП, підживлення 1 зона (три контролери), опалення, ГВП, підживлення 2 зона (три контролери), опалення паркінг (2 контролери), то надійніше буде розбити диспетчеризацію теплопункту на три фрагменти та використовувати контролер концентратор який буде збирати дані з пльових контролерів наприклад по шині Modbus RTU, а передавати у глобальну систему дані протоколу Modbus TCP/IP. Дане рішення дозволить уникнути довгих ліній передачі, що призведе до зменшення колізій при передачі даних, збільшить надійність і забезпечить простоту обслуговування та діагностування помилок.

Введення нових правил для стандартів передачі в технологічні системи управління із зазначенням можливих використовуваних протоколів, і навіть визначення структури переданих даних.

Наприклад, усі домовляються про те, що необхідно буде використовувати WEB server із встановленим ОРС UA client. Для систем теплопункту дані необхідно передавати з наступною структурою: тип системи (ціле число згідно з певним каталогом систем), аналогові сигнали про температуру (температури подачі, зворотної води, гострої води, зовнішньої води), аналогові вихідні сигнали, режим та стан роботи системи, розклад роботи, аварійні сполучення.

При додаванні систем не буде хаосу в переписуванні програми основної диспетчеризації, по-перше, вона може бути додана в систему на рівні концентратора підрядником, що відповідає за теплопункти, і впроваджена як копія аналогічної системи глобальним будівельником диспетчеризації згідно з певними правилами.

Зворотній зв'язок від розробників локальних систем диспетчеризації до глобальних. Адже саме вони знають технологію, над якою працюють і зможуть вибрати необхідні параметри, для регулювань та конкретні дані для оптимального моніторингу роботи своєї системи.

Таким чином, такий підхід до диспетчеризації може дати простоту в побудові, а саме підготовлені дані на вході для загальної глобальної диспетчеризації, розуміння між замовником, головним підрядником і локальними з метою та методами досягнення результату, сегментовану роботу з поступовим підключенням нових вузлів диспетчеризації. Можливість споживача поетапного застосування з поділом оплати. Оновлення систем на нові версії із одночасним розвитком стандартів обміну між системами.

На цьому малюнку зображено схему побудови локальної диспетчеризації теплопункту.

Для основного пристрою, на якому зібрана диспетчеризація, вибрано міні комп'ютер, на якому встановлені драйвера послідовних портів Modbus RTU, M-BUS, програма яка збирає дані по цих інтерфейсах. WEB server, який може формувати «дашборд», на якому можна бачити поточні значення основних аналогових та дискретних вхідних – вихідних каналів, параметри, архіви трендів та аварійних повідомлень. Аналог SCADA системи із використанням WEB технологій.

Ця система може працювати, як окрема локальна система диспетчеризації. Для цього потрібно організувати локальну мережу Ehternet, наприклад, за допомогою Wi-Fi роутера. При підключенні до цієї мережі з мобільного пристрою або за допомогою провідного підключення ПК, в браузері кінцевого пристрою набираємо локальне посилання головного вікна WEB server(а), на що сервер видає готову HTML сторінку основного «дашборду» (динамічної мнемосхеми).

Також дана система зможе працювати аналогічно вище показаної, але через глобальний інтернет канал. Для цього необхідно підвести інтернет до роутера системи з виділеним статичним IP, який необхідно замовити у провайдера, який має доступ для роздачі інтернету в цьому будинку. Природно, необхідно буде платити щомісячну плату за цю послугу.

У роутері налаштувати FAT табличку, в якій вказати перенаправлення звернення за статичною адресою глобального інтернету на локальну адресу початкової сторінки системи диспетчеризації.

В даному випадку система може працювати як ОРС клієнт Modbus TCP/IP, перетворюючи параметри та значення з локальних інтерфейсів Modbus RTU, M-BUS у глобальний Modbus TCP/IP.

Також для обміну з глобальною диспетчеризацією може бути задіяний механізм API запитів, синтаксис та структура, яких зазначено в інструкції до системи.

Висновок: 

Таким чином, дана система може працювати як локально, так і через інтернет віддалено, збирати дані, аналізуючи які можна приймати оптимізацію всієї системи. Передавати та обмінюватись даними з глобальними системами диспетчеризації або інші суміжні організації типу водоканал або ЖЕК. А також легко модернізована з метою визначення затоплення, проникнення та аварійних ситуацій певним службам та відповідальним особам за SMS чи звуковим повідомленням.

ТОВ НВТ «Автоматика»

097-3123462

 

Джерело: ТОВ НВТ «Автоматика»
Інформацію опубліковано на правах реклами