Позавчера коллега спросил меня: «Слушай, мне нужно связать старый ПЛК с облаком. Что лучше — Modbus или MQTT?» Я ответил встречным вопросом: «А зачем тебе облако, если у тебя локальная котельная?» Оказалось, заказчик хочет мониторить температуру из дома через смартфон. Вот вам классический пример, когда выбор протокола зависит не от технологии, а от задачи.
В этой статье я разберу три кита промышленной связи — Modbus, MQTT и OPC UA — и покажу, когда какой использовать, чтобы не переплатить и не наступить на грабли.
Что такое промышленные протоколы и зачем они нужны?
Промышленный протокол — это язык, на котором общаются устройства в АСУ ТП. Датчик давления «говорит» контроллеру: «У меня 5.2 бара». Контроллер отвечает клапану: «Открыться на 30%». SCADA-система спрашивает у всех: «Как дела?»
Без протокола это был бы хаос, как если бы на заводе одновременно работали русские, китайцы и немцы, не зная языков друг друга.
Основные требования к промышленным протоколам:
- Надежность — данные не должны теряться или искажаться
- Детерминированность — ответ должен приходить в строго определенное время
- Простота — чем проще протокол, тем легче его настроить и отладить
- Совместимость — желательно, чтобы оборудование разных производителей понимало друг друга
Modbus: старый добрый ветеран
Что это такое?
Modbus — это протокол, который появился в 1979 году. Да, ему уже 45+ лет, но он до сих пор жив и активно используется. Это как «Жигули» в мире автоматизации — простой, надежный, ремонтопригодный.
Существует две основные версии:
- Modbus RTU — работает по RS-485 (физический кабель)
- Modbus TCP — работает по Ethernet (сетевой кабель)
Как это работает?
Modbus работает по принципу «мастер-слейв» (ведущий-ведомый). Один мастер (обычно ПЛК или SCADA) опрашивает слейвов (датчики, частотники, счетчики). Слейвы сами ничего не инициируют — только отвечают на запросы.
Пример запроса:
Мастер → Слейв (адрес 1): "Дай мне значение регистра 40001"
Слейв → Мастер: "Держи: 1523" (это может быть температура 15.23°C)
Когда использовать Modbus?
✅ Хорошо подходит для:
- Локальных систем (в пределах одного здания/цеха)
- Связи с legacy-оборудованием (старые ПЛК, частотники)
- Простых задач мониторинга и управления
- Бюджетных проектов (почти все устройства поддерживают Modbus из коробки)
❌ Плохо подходит для:
- Больших распределенных систем (сотни устройств)
- Передачи данных через интернет (нет встроенной безопасности)
- Сложных структур данных (только числа, нет JSON/XML)
Реальный кейс: Modbus RTU в котельной
На одном объекте мы автоматизировали котельную на 3 котла. Использовали:
- ПЛК Siemens S7-1200 (мастер)
- 3 частотных преобразователя на насосах (Modbus RTU)
- 12 датчиков температуры с преобразователями (Modbus RTU)
- Счетчик газа (Modbus RTU)
Все подключили по одной линии RS-485. Скорость — 9600 бод. Работает уже 5 лет без единого сбоя.
Почему выбрали Modbus RTU:
- Все оборудование поддерживало его из коробки
- Расстояния небольшие (до 100 метров)
- Не нужна была высокая скорость опроса
- Бюджет был ограничен
MQTT: протокол для интернета вещей
Что это такое?
MQTT (Message Queuing Telemetry Transport) — это легковесный протокол, созданный для передачи данных в условиях плохой связи. Изначально его разработали для нефтепроводов в пустыне, где интернет работает через спутник.
Сегодня MQTT — это стандарт де-факто для IIoT (промышленного интернета вещей).
Как это работает?
MQTT работает по модели «издатель-подписчик» (publish-subscribe) через посредника — брокера.
Пример:
Датчик температуры → Брокер: "Публикую в топик 'котельная/котел1/температура': 85°C"
SCADA-система → Брокер: "Подписываюсь на топик 'котельная/котел1/температура'"
Брокер → SCADA: "Новое значение: 85°C"
Ключевое отличие от Modbus: устройства не знают друг о друге. Они общаются через брокера.
Когда использовать MQTT?
✅ Хорошо подходит для:
- Удаленных объектов (скважины, ветряки, солнечные станции)
- Передачи данных через интернет (3G/4G/5G)
- Облачных решений (AWS IoT, Azure IoT Hub)
- Систем с нестабильной связью (автоматическое переподключение)
❌ Плохо подходит для:
- Управления в реальном времени (есть задержки через брокера)
- Критичных систем безопасности (ПАЗ, emergency stop)
- Локальных сетей, где проще использовать Modbus
Реальный кейс: MQTT для мониторинга теплиц
Недавно делали проект для агрохолдинга: 15 теплиц, разбросанных по области. В каждой — датчики температуры, влажности, CO2, освещенности.
Архитектура:
- В каждой теплице: Raspberry Pi + датчики
- MQTT-брокер: Mosquitto на VPS в облаке
- Веб-интерфейс: Node-RED для визуализации
- Мобильное приложение для агронома
Данные передаются каждые 5 минут. Если связь пропадает (бывает в деревне), устройство накапливает данные и отправляет пакетом, когда связь восстанавливается.
Почему выбрали MQTT:
- Объекты удаленные (до 200 км от центрального офиса)
- Связь нестабильная (сельская местность)
- Нужен был доступ через интернет (агроном проверяет с телефона)
- Легко масштабируется (добавили еще 5 теплиц без переделки архитектуры)
OPC UA: современный стандарт
Что это такое?
OPC UA (Open Platform Communications Unified Architecture) — это современный промышленный стандарт, который объединяет лучшее из всех миров. Это не просто протокол передачи данных, а целая платформа для обмена информацией между устройствами, системами и облаками.
OPC UA появился в 2008 году как замена старого OPC Classic (который работал только на Windows).
Как это работает?
OPC UA использует модель «клиент-сервер», но гораздо более продвинутую, чем Modbus.
Ключевые особенности:
- Информационная модель — данные структурированы в виде дерева объектов (как файловая система)
- Встроенная безопасность — шифрование, аутентификация, сертификаты
- Платформонезависимость — работает на Windows, Linux, embedded-системах
- Семантика — данные имеют не только значение, но и описание (единицы измерения, диапазоны, тип)
Пример:
OPC UA сервер предоставляет объект "Котел1":
├── Температура (Float, °C, диапазон 0-120)
├── Давление (Float, бар, диапазон 0-10)
├── Состояние (Boolean, вкл/выкл)
└── Аварии (Array of Strings)
Когда использовать OPC UA?
✅ Хорошо подходит для:
- Интеграции разнородного оборудования (Siemens + Schneider + ABB)
- Передачи данных в MES/ERP системы
- Проектов с требованиями к кибербезопасности
- Индустрии 4.0 и цифровых двойников
❌ Плохо подходит для:
- Простых задач (избыточная сложность)
- Бюджетных проектов (дороже в настройке и поддержке)
- Старого оборудования (нужна поддержка OPC UA)
Реальный кейс: OPC UA на металлургическом заводе
На металлургическом комбинате внедряли систему сбора данных с 50+ единиц оборудования разных производителей: Siemens, Schneider, Mitsubishi, отечественные ПЛК.
Проблема: каждый производитель использовал свой протокол. Нужен был единый шлюз для передачи данных в корпоративную систему SAP.
Решение: OPC UA сервер на промышленном ПК, который:
- Собирает данные со всех ПЛК (через Modbus, Profinet, EtherNet/IP)
- Преобразует их в единую информационную модель OPC UA
- Передает в SAP через OPC UA клиент
Почему выбрали OPC UA:
- Нужна была интеграция разнородного оборудования
- Требования к безопасности (сертификация по IEC 62443)
- Масштабируемость (планируется подключение еще 100+ устройств)
- Заказчик хотел «современное решение на перспективу»
Сравнительная таблица: Modbus vs MQTT vs OPC UA
Критерий Modbus RTU/TCP MQTT OPC UA
Год появления 1979 1999 2008
Архитектура Мастер-слейв Издатель-подписчик Клиент-сервер
Скорость передачи Низкая-средняя Средняя Средняя-высокая
Надежность ⭐⭐⭐⭐⭐ ⭐⭐⭐⭐ ⭐⭐⭐⭐⭐
Безопасность ❌ Нет ⚠️ Опционально (TLS) ✅ Встроенная
Сложность настройки ⭐ Простая ⭐⭐ Средняя ⭐⭐⭐⭐ Сложная
Стоимость внедрения 💰 Низкая 💰💰 Средняя 💰💰💰 Высокая
Поддержка старого оборудования ✅ Отлично ❌ Плохо ⚠️ Через шлюзы
Работа через интернет ❌ Не рекомендуется ✅ Идеально ✅ Да
Масштабируемость ⚠️ До 247 устройств ✅ Тысячи устройств ✅ Тысячи устройств
Типичная область Локальные АСУ ТП IIoT, удаленный мониторинг Интеграция систем, Индустрия 4.0
Как выбрать протокол: чек-лист для вашего проекта
Ответьте на эти вопросы, и выбор станет очевиден:
1. Где находятся ваши устройства?
- В одном помещении/здании → Modbus RTU/TCP
- Разбросаны по городу/области → MQTT
- Разные площадки, нужна интеграция → OPC UA
2. Какое у вас оборудование?
- Старые ПЛК, частотники, датчики → Modbus
- Современные контроллеры с Ethernet → OPC UA или Modbus TCP
- Самодельные устройства (Arduino, Raspberry Pi) → MQTT
3. Нужен ли доступ через интернет?
- Нет, только локальная сеть → Modbus TCP
- Да, нужен удаленный мониторинг → MQTT или OPC UA
- Да, и нужна высокая безопасность → OPC UA
4. Какой у вас бюджет?
- Минимальный → Modbus
- Средний → MQTT
- Есть деньги на качественное решение → OPC UA
5. Какие требования к скорости?
- Опрос раз в минуту — достаточно → MQTT
- Нужен опрос каждые 100-500 мс → Modbus TCP
- Критичное управление в реальном времени → Profinet/EtherCAT (не рассмотрены в статье)
Частые ошибки при выборе протокола
Ошибка 1: «Возьму OPC UA, потому что это современно»
Недавно видел проект, где для простой котельной на 2 котла выбрали OPC UA. В итоге:
- Потратили в 3 раза больше времени на настройку
- Переплатили за лицензии
- Система работает, но избыточно сложная для такой задачи
Правило: Не используйте пушку для охоты на воробьев.
Ошибка 2: «Modbus устарел, его никто не использует»
Это миф. Modbus — самый распространенный протокол в промышленности. 80% оборудования поддерживает его из коробки. Если ваша задача — связать 10 датчиков с ПЛК в пределах цеха, Modbus справится идеально.
Ошибка 3: «MQTT — это только для IoT-игрушек»
MQTT активно используется в серьезных промышленных проектах: мониторинг нефтепроводов, ветропарки, солнечные станции. Главное — правильно настроить брокер и обеспечить резервирование.
Можно ли комбинировать протоколы?
Да, и это часто лучшее решение!
Типичная архитектура:
1. Уровень поля (датчики ↔ ПЛК) — Modbus RTU
2. Уровень контроллеров (ПЛК ↔ SCADA) — Modbus TCP или OPC UA
3. Уровень облака (SCADA ↔ Cloud) — MQTT или OPC UA
Пример из жизни:
На одном заводе мы сделали так:
- Старые датчики и частотники → Modbus RTU → ПЛК
- ПЛК → OPC UA сервер → локальная SCADA
- OPC UA сервер → MQTT-брокер → облачная аналитика
Получилась гибридная система, где каждый протокол используется там, где он лучше всего подходит.
Заключение
Выбор протокола — это не вопрос «что лучше», а вопрос «что подходит для моей задачи».
Краткая шпаргалка:
- Modbus — для простых локальных систем и legacy-оборудования
- MQTT — для удаленного мониторинга и IIoT
- OPC UA — для интеграции разнородных систем и Индустрии 4.0
Не гонитесь за модой. Иногда старый добрый Modbus решает задачу лучше, чем навороченный OPC UA. А иногда без OPC UA не обойтись.
Главное правило: Выбирайте протокол под задачу, а не задачу под протокол.
А какой протокол используете вы? Сталкивались ли с проблемами при выборе? Делитесь опытом в комментариях!
Пример статьи. Почему таблицы плохо копируются в Дзен? Как исправлять? Вручную не предлагать.