Підтримувані протоколи зв’язку

Огляд промислових та IoT-протоколів зв’язку, які підтримує платформа, — Modbus, OPC UA, MQTT і DLMS/COSEM.

Modbus (RTU / TCP)

Призначення та опис

Простий і широко вживаний промисловий протокол для обміну технологічними даними між контролерами, давачами та виконавчими механізмами. Розроблений 1979 року компанією Modicon (нині Schneider Electric), він став фактичним стандартом промислової автоматизації. Застосовується в системах SCADA, ПЛК, частотних перетворювачах, вимірювальних приладах і давачах. Завдяки простоті реалізації та мінімальним вимогам до обчислювальних ресурсів протокол ідеально підходить для вбудованих систем і пристроїв з обмеженим обсягом пам’яті.

Архітектура та модель даних

Регістрова модель даних побудована на чотирьох типах адресного простору:

  • Coils (0x) — дискретні виходи (читання/запис бітових значень)
  • Discrete Inputs (1x) — дискретні входи (лише читання)
  • Input Registers (3x) — 16-бітні вхідні регістри (лише читання)
  • Holding Registers (4x) — 16-бітні регістри зберігання (читання/запис)

Архітектура «клієнт — сервер» (master — slave): провідний пристрій (master) ініціює запити, ведені (slave) відповідають. Кожен ведений пристрій має унікальну адресу (1–247). Протокол не містить вбудованої семантики даних — інтерпретація значень регістрів визначається на прикладному рівні та в документації пристрою. Підтримує операції читання й запису для одного та кількох регістрів.

Транспорт

Modbus RTU:

  • Послідовні лінії RS-485 (до 32 пристроїв на шину, відстань до 1200 м) або RS-232 (з’єднання «точка — точка»)
  • Двійкове подання даних
  • Перевірка цілісності за допомогою CRC-16
  • Швидкість передавання: від 1200 до 115200 бод
  • Напівдуплексне передавання

Modbus TCP:

  • Інкапсуляція кадрів Modbus у TCP/IP (порт 502)
  • Заголовок MBAP (Modbus Application Protocol) для ідентифікації транзакцій
  • Повнодуплексне передавання
  • Можливість одночасної роботи з кількома пристроями
  • Контрольна сума не потрібна (надійність забезпечує TCP)

Ключові можливості

  • Читання й запис дискретних сигналів (Coils) та регістрів
  • Підтримка стандартних кодів функцій (FC 01–06, 15–16, 23)
  • Діагностичні функції (FC 08)
  • Читання ідентифікаційних даних пристрою (FC 17, 43)
  • Мінімальні вимоги до обчислювальних ресурсів пристроїв
  • Проста реалізація та налагодження
  • Низька вартість упровадження
  • Обробка винятків і коди помилок
  • Підтримка широкомовних повідомлень (адреса 0) у режимі RTU
  • Масштабованість до 247 пристроїв на лінії (RTU) або без обмежень через TCP

OPC UA

Призначення та опис

Універсальний кросплатформний стандарт (OPC Unified Architecture, IEC 62541) для безпечного та структурованого обміну промисловими даними, метаданими й семантичною інформацією. Розроблений організацією OPC Foundation як наступник класичних специфікацій OPC DA/AE/HDA, він усуває залежність від технологій Microsoft DCOM. Уможливлює вертикальну та горизонтальну інтеграцію у промислових системах — від польового рівня до корпоративних інформаційних систем (ERP, MES). Підтримує концепції Industrie 4.0 та цифрових двійників завдяки розвиненим можливостям інформаційного моделювання.

Архітектура та модель даних

Об’єктно-орієнтована модель даних подає інформацію у вигляді адресованого простору вузлів (Address Space):

  • Вузли (Nodes) різних типів: Variable, Object, Method, View, DataType, ReferenceType
  • Атрибути вузлів: Value, DataType, AccessLevel, Timestamp, Quality, DisplayName тощо
  • Зв’язки (References) між вузлами: ієрархічні, асоціативні, компонентні
  • Типи даних: примітиви, структури, масиви, переліки

Підтримувані служби:

  • Subscription — моніторинг змін даних із налаштовуваними інтервалами вибірки та фільтрами
  • Events & Alarms — асинхронні сповіщення про події, тривоги та стани
  • Historical Access — доступ до архівних даних і подій
  • Methods — віддалений виклик процедур на пристроях

Галузеві інформаційні моделі (Companion Specifications): машинобудування, енергетика, нафтогазова галузь, фармацевтика.

Транспорт

UA Binary Protocol поверх TCP/IP:

  • Двійковий протокол з оптимізованою серіалізацією (порт 4840)
  • Висока продуктивність і мінімальні службові витрати

HTTPS / SOAP:

  • Профіль Web Services для інтеграції з корпоративними системами
  • Кодування JSON для хмарних застосунків

OPC UA PubSub:

  • Модель «видавець — передплатник» для розподілених систем
  • Транспорт: UDP Multicast, MQTT, AMQP, Ethernet TSN
  • Детерміноване передавання для застосунків, критичних до часу

Безпека:

  • Багаторівневі режими безпеки (None, Sign, SignAndEncrypt)
  • Сертифікати X.509 для автентифікації
  • Шифрування AES, RSA

Ключові можливості

  • Інформаційне моделювання: передавання не лише «сирих» значень, а й складних структурованих даних із семантикою, типізацією та метаданими
  • Підписки з налаштовуваними інтервалами опитування, фільтрами зони нечутливості (deadband) та буферизацією
  • Події та система тривог з умовною фільтрацією
  • Виклик методів для керування пристроями та виконання операцій
  • Доступ до історичних даних з агрегацією
  • Виявлення служб у локальних мережах
  • Вбудована безпека: шифрування каналу, автентифікація за сертифікатами або за ім’ям користувача й паролем, керування доступом на рівні вузлів
  • Резервування серверів і відмовостійкість
  • Кросплатформність: Windows, Linux, VxWorks, QNX та інші ОС
  • Масштабованість: від мікроконтролерів до розподілених систем

MQTT

Призначення та опис

Полегшений протокол обміну повідомленнями (Message Queuing Telemetry Transport) для телеметрії, віддаленого моніторингу та керування IoT-пристроями, оптимізований для ненадійних мереж, обмеженої пропускної здатності та високих затримок. Розроблений 1999 року компанією IBM для моніторингу нафтопроводів, стандартизований організаціями OASIS та ISO/IEC (20922:2016). Широко застосовується у промисловому IoT, розумних будинках, телематиці транспортних засобів і мобільних застосунках. Протокол зосереджений на мінімізації мережевого трафіку та енергоспоживання пристроїв.

Архітектура та модель даних

Асинхронна модель Publish/Subscribe з централізованим брокером:

  • Publisher — пристрій або застосунок, що публікує повідомлення до тем
  • Subscriber — пристрій або застосунок, підписаний на отримання повідомлень із тем
  • Broker — центральний сервер маршрутизації повідомлень (Mosquitto, HiveMQ, EMQ X тощо)

Теми (Topics) — ієрархічна структура шляхів для категоризації повідомлень:

  • Роздільники рівнів: / (наприклад, factory/building1/temperature)
  • Шаблонні символи: + (один рівень), # (кілька рівнів)
  • Приклад підписки: sensors/+/temperature або factory/#

Формат даних визначається застосунком: JSON, Protocol Buffers, XML, двійкові дані, текст.
Збережені повідомлення (Retained messages): брокер зберігає останнє повідомлення для теми та доставляє його новим передплатникам.
Постійні сесії (Persistent sessions): брокер зберігає підписки клієнта після від’єднання.

Транспорт

  • Транспортний рівень: TCP/IP (порт 1883 для незахищених з’єднань)
  • TLS/SSL (порт 8883) для шифрування та автентифікації
  • WebSockets для інтеграції з браузерами та вебзастосунками
  • Версії протоколу: MQTT 3.1.1 (найпоширеніша), MQTT 5.0 (розширені можливості)
  • Розмір заголовка: мінімум 2 байти (фіксований заголовок)
  • Механізм підтримання з’єднання (keep-alive): періодичні PINGREQ/PINGRESP для контролю з’єднання
  • Робота через брокер забезпечує розв’язання видавців і передплатників, горизонтальне масштабування та централізоване керування

Ключові можливості

  • QoS (Quality of Service) — три рівні гарантії доставки:
    • QoS 0: не більше одного разу (без підтвердження)
    • QoS 1: щонайменше один раз (з підтвердженням)
    • QoS 2: рівно один раз (чотирикрокове квитування)
  • Мінімальні мережеві службові витрати: 2-байтовий фіксований заголовок, ефективне двійкове кодування
  • LWT (Last Will and Testament): механізм автоматичного сповіщення про неочікуване від’єднання пристрою — брокер публікує заздалегідь визначене повідомлення, якщо клієнт завершує сесію аварійно
  • Clean Session / Persistent Session: можливість відновлення підписок і повідомлень після повторного підключення
  • Retained Messages: доступність найновішого значення для нових передплатників
  • Низьке енергоспоживання: ідеально для пристроїв з живленням від батареї
  • Масштабованість: підтримка мільйонів одночасних з’єднань у кластерах брокерів
  • Підписки із шаблонними символами для гнучкої фільтрації тем

DLMS / COSEM (IEC 62056)

Призначення та опис

Міжнародний стандарт для обміну даними з комунальними лічильниками: електроенергії, газу, води та тепла (Device Language Message Specification / Companion Specification for Energy Metering). Розроблений асоціацією DLMS User Association спільно з IEC для забезпечення сумісності інтелектуальних лічильників у системах автоматизованого обліку та білінгу (AMBS). Уможливлює віддалене знімання показів лічильників, моніторинг якості електроенергії, керування тарифами та виявлення несанкціонованого доступу. Широко застосовується операторами електромереж, постачальниками комунальних послуг та інтеграторами систем Smart Grid.

Архітектура та модель даних

Об’єктна модель COSEM (Companion Specification for Energy Metering):

  • Дані лічильника подаються як логічні об’єкти (об’єкти COSEM) з інтерфейсними класами
  • Коди OBIS (Object Identification System) — шестибайтовий ідентифікатор для універсальної адресації параметрів: A-B:C.D.E*F
    • A — тип енергії (1=електроенергія, 6=тепло, 7=газ, 8=вода)
    • B — канал вимірювання
    • C — фізична величина (наприклад, 1=активна енергія)
    • D — тип вимірювання (8=час інтегрування)
    • E — тарифна зона
    • F — глибина історії

Протокол DLMS:

  • Прикладний рівень за моделлю OSI
  • Асоціації (Associations) з різними правами доступу: Public, Reader, Manager
  • Автентифікація: Low Level Security (LLS), High Level Security (HLS) з механізмом «запит — відповідь»
  • Шифрування: підтримка DLMS Security Suite з алгоритмами AES-GCM-128
  • Профілі навантаження (Load Profiles): буферні об’єкти для зберігання часових рядів даних
  • Система сценаріїв: виконання послідовностей дій на лічильнику

Транспорт

Фізичний рівень і рівень каналу передавання даних:

  • Оптичний порт (IEC 62056-21, flag) — пряме підключення через інфрачервону головку для локального знімання показів
  • RS-485 / RS-232 з протоколом HDLC (High-Level Data Link Control) для багатоточкових мереж
  • TCP/IP (порт 4059) — DLMS поверх TCP або інкапсуляція в IP для віддаленого доступу
  • GSM/GPRS/LTE — передавання даних через мобільні мережі (протоколи-обгортки)
  • PLC (Power Line Communication) — передавання лініями електроживлення (PRIME, G3-PLC)
  • M-Bus — для інтеграції із системами обліку води й тепла

Профілі передавання залежно від реалізації лічильника:

  • IEC 62056-46: COSEM поверх HDLC
  • IEC 62056-47: транспорт COSEM поверх TCP-UDP/IP

Ключові можливості

  • Знімання показів — поточні значення споживання енергії, потужності, напруги, струму, коефіцієнта потужності
  • Профілі навантаження (Load Profiles) — детальні дані з часовими мітками (15-хвилинні, погодинні, добові інтервали)
  • Журнали подій — фіксація розкриття кришки, перебоїв живлення, перенапруг, змін параметрів
  • Багаторівнева автентифікація та авторизація: керування доступом на основі ролей (публічний доступ, читання, конфігурування)
  • Керування тарифами — віддалена зміна тарифних розкладів і ставок
  • Синхронізація часу для точності часових міток
  • Керування реле (підключення/відключення навантаження)
  • Моніторинг якості електроенергії (провали, сплески, гармоніки)
  • Підтримка групових операцій над кількома лічильниками
  • Криптографічний захист даних і цілісність повідомлень

Пов'язані теми

Останнє оновлення

Чи була ця сторінка корисною?