Промышленные протоколы IIoT: Modbus, OPC UA, MQTT, Profinet

Промышленные протоколы — фундамент всей связки от датчика до облака. От правильного выбора протоколов на каждом уровне зависит, насколько надёжно работает связка PLC ↔ SCADA, насколько просто интегрируется новое оборудование, и насколько защищена система от атак. Ошибки в архитектуре протоколов выявляются при первой попытке масштабирования или интеграции — и стоят месяцы переделок.

Эта статья — для архитектора промышленных систем, embedded-инженера, главного инженера или CTO. Без академической теории, с конкретным сравнением Modbus, OPC UA, MQTT, Profinet, CAN, реализацией на embedded и SCADA, требованиями к безопасности и типовыми ошибками.

Архитектура промышленной связи: 4 уровня

Современный промышленный IIoT-проект использует разные протоколы на разных уровнях:

Уровень 0: Полевые сенсоры и приборы.

• Аналоговые сигналы (4-20 мА, 0-10 В) для простых датчиков
• HART для умных датчиков (поверх 4-20 мА)
• Modbus RTU для базовых сетевых датчиков
• IO-Link для современных датчиков с цифровой связью

Уровень 1: PLC ↔ полевое оборудование.

• Modbus RTU/TCP — самый массовый
• Profinet — для Siemens-оборудования
• EtherNet/IP — для Allen-Bradley
• CANopen — для приборного учёта и автомобильной техники
• DeviceNet, AS-i — нишевые применения

Уровень 2: SCADA ↔ PLC.

• Modbus TCP — массовый стандарт
• OPC UA — современный стандарт для серьёзных систем
• Profinet (если SCADA поддерживает)
• Native-протоколы PLC (S7 для Siemens, специфические для других вендоров)

Уровень 3: Передача в облако / MES / ERP.

• MQTT — основной для IIoT-устройств
• HTTPS — для редких запросов и веб-сервисов
• AMQP — для enterprise-сценариев
• OPC UA over TCP — для интеграции с MES
• LoRaWAN — для дальней связи в utility-применениях
• NB-IoT — мобильная связь с низким энергопотреблением

Modbus: рабочая лошадка промышленности

Modbus — самый массовый промышленный протокол, существует с 1979 года и до сих пор не имеет реальной замены в нишах простых устройств.

Modbus RTU. Работает по последовательному интерфейсу (RS-485, реже RS-232). Технические характеристики:

• Кабель до 1200 м по RS-485
• Скорости 9600-115200 бод
• До 247 устройств на шине (физический предел RS-485 — 32, дальше нужны репитеры)
• Master-slave архитектура: один master опрашивает множество slave
• Минимальная реализация на embedded — 5-10 КБ кода

Modbus TCP. То же по Ethernet:

• Без ограничений по дистанции (в пределах локальной сети)
• Скорость гигабитная
• Множественные сессии (несколько клиентов могут одновременно опрашивать один сервер)
• Минимальная реализация — 5-15 КБ кода

Команды Modbus:

• 0x01: Read Coils (чтение дискретных выходов)
• 0x02: Read Discrete Inputs (чтение дискретных входов)
• 0x03: Read Holding Registers (чтение регистров хранения)
• 0x04: Read Input Registers (чтение регистров ввода)
• 0x05: Write Single Coil
• 0x06: Write Single Register
• 0x0F: Write Multiple Coils
• 0x10: Write Multiple Registers

Регистры — 16-битные. Для чисел больше 16 бит используется упаковка в два или четыре регистра (стандарт не определяет порядок байт — приходится договариваться или читать документацию устройства).

Ограничения Modbus:

• Нет встроенной безопасности (нужен TLS для публичной сети)
• Нет метаданных (что значит регистр 40001 — нужно из документации)
• Нет события и подписок — только polling
• Нет арбитража множественных мастеров

Подробнее — гайд по Modbus в embedded-разработке.

OPC UA: современный стандарт

OPC UA (Unified Architecture) — стандарт промышленной связи, разработан OPC Foundation как замена устаревшему OPC DA / OPC Classic.

Ключевые особенности:

1. Объектная модель. Данные структурированы как иерархическое дерево объектов, переменных, методов, событий. Не «регистр 40001», а «Объект.Двигатель.Скорость» с типом, единицами измерения, диапазоном.

2. Безопасность. Встроенные security profiles: Basic128Rsa15, Basic256Sha256, Aes128Sha256RsaOaep. Аутентификация по сертификатам, шифрование, цифровые подписи.

3. Транспортная независимость. Работает по TCP (бинарный), HTTPS (WebSocket с JSON или XML), AMQP.

4. Метаданные. Сервер сам описывает свою структуру (information model). Клиент динамически обнаруживает доступные переменные и методы.

5. События и подписки. Клиент подписывается на изменения переменных, сервер уведомляет о изменениях. Не polling.

6. Companion specifications. Отраслевые расширения: OPC UA for Robotics, for Machinery, for IoT 4 IndustryFusion.

Минусы:

• Большой объём кода (200-500 КБ на embedded)
• Сложнее в реализации, чем Modbus
• Лицензионная стоимость некоторых стеков (хотя есть open source — open62541, FreeOpcUa)

Где использовать:

• Серьёзная интеграция PLC, SCADA, MES в современных производствах
• Архитектуры Industry 4.0
• Крупные промышленные объекты с требованиями к безопасности и метаданным
• Замена устаревших протоколов OPC DA / Classic

MQTT: стандарт IIoT-облачной связи

MQTT (Message Queuing Telemetry Transport) — лёгкий pub-sub протокол, разработан для устройств с ограниченными ресурсами и нестабильной связью.

Архитектура:

• Брокер (Mosquitto, EMQX, Vernemq) — точка обмена
• Издатели (publishers) — отправляют сообщения в топики
• Подписчики (subscribers) — получают сообщения из топиков
• Топики — иерархические строки (device/123/temperature)

QoS уровни:

• QoS 0 — fire and forget. Без гарантии доставки. Подходит для частой телеметрии.
• QoS 1 — гарантированная доставка хотя бы один раз. Может быть дублирование. Подходит для важных уведомлений.
• QoS 2 — гарантированная доставка ровно один раз. Самый надёжный и медленный. Для критических команд.

Retained сообщения. Брокер сохраняет последнее сообщение в топике с флагом retained и отдаёт его новым подписчикам сразу при подключении. Используется для текущего состояния устройства.

Last will (LWT). Сообщение, которое брокер отправит автоматически от имени клиента при разрыве соединения. Стандартный паттерн — устройство устанавливает LWT с сообщением «offline» в свой статусный топик, и при падении другие подписчики узнают об этом.

Преимущества MQTT для IIoT:

• Лёгкий клиент (5-15 КБ на embedded)
• Оптимизирован для нестабильной связи (keep-alive, переподключение)
• Pub-sub архитектура — лёгкая масштабируемость на тысячи устройств
• Низкий трафик (минимальные накладные расходы)

Где использовать:

• Передача телеметрии с IoT-устройств в облако
• Pub-sub архитектуры с большим числом устройств
• Сценарии с нестабильной связью
• Микросервисные интеграции

Profinet, EtherNet/IP, CAN: специализированные

Profinet. Промышленный Ethernet от PROFIBUS & PROFINET International. Стандарт де-факто для оборудования Siemens (и других вендоров, поддерживающих Profinet). Особенности — детерминистическое время отклика (Real-Time, Isochronous Real-Time для motion control), интеграция с TIA Portal. Минусы — лицензионные сертификации, сложность реализации, привязка к экосистеме.

EtherNet/IP. Промышленный Ethernet от ODVA, стандарт для оборудования Allen-Bradley (Rockwell). Используется в Северной Америке и некоторых отраслях.

CAN / CANopen. CAN — физический и канальный уровни автомобильной связи, CANopen — прикладной протокол поверх CAN. Используется в:

• Автомобильной технике
• Приборном учёте (счётчики энергии, воды)
• Медицинском оборудовании
• Мобильной технике (машины, лифты)

Скорость до 1 Мбит/с, дистанция до 40 м на максимальной скорости. Минимальная реализация на embedded — 10-30 КБ.

LoRaWAN: дальняя связь с низким энергопотреблением

LoRaWAN — протокол дальней связи (Long Range Wide Area Network) на нелицензируемых частотах (433/868/915 МГц).

Характеристики:

• Дистанция до 15-20 км в открытой местности, 3-5 км в городе
• Скорость 0.3-50 кбит/с
• Время работы устройства от батареи AA — до 5-10 лет
• Архитектура — устройства → gateway → network server → application server

Где использовать:

• Агро-сенсоры на больших полях
• Утилитарные счётчики (вода, газ) в кварталах
• Мониторинг ёмкостей, насосов, удалённых объектов
• Tracking грузов и животных

Альтернатива — NB-IoT (мобильная связь). Доступна через операторов мобильной связи, меньше дистанция (зона покрытия LTE), но выше скорость и не нужна собственная инфраструктура gateway’ев.

Безопасность промышленных протоколов

Базовый Modbus и MQTT — plain-текстовые протоколы без встроенной защиты. Использование их по сети без дополнительных мер — серьёзная уязвимость.

Стандартные меры защиты:

1. TLS обязательно для публичных сетей:

• Modbus TCP over TLS (порт 802 или нестандартный)
• MQTTS (порт 8883)
• HTTPS вместо HTTP

2. Аутентификация:

• Для MQTT — сертификаты устройств (mTLS) или username/password
• Для Modbus — пароли (опционально, не во всех реализациях)
• Для OPC UA — встроенная аутентификация по сертификатам

3. Сегментация сетей:

• Промышленная сеть отделена от корпоративной межсетевым экраном
• DMZ для устройств, требующих доступа извне
• Сегментация внутри промышленной сети по уровням (полевой, диспетчерский, управленческий)

4. Allowlist по IP/MAC:

• Только разрешённые IP могут опрашивать PLC
• Контроль MAC-адресов в сети

5. Аудит подключений:

• Журналирование всех событий security
• Регулярный анализ журналов

Для объектов КИИ — сертифицированные СКЗИ (КриптоПро, ViPNet) согласно требованиям ФСТЭК. См. защита КИИ на it-fusion.ru.

Связь с другими блоками

См. подробнее:

• Промышленный IoT — общая архитектура IIoT
• Embedded-разработка — реализация протоколов на устройствах
• Разработка SCADA-систем — серверная сторона
• АСУ ТП — место протоколов в архитектуре АСУ ТП
• Edge computing — обработка данных на edge
• Защита промышленных сетей — it-fusion.ru/zashchita-kii/

Типовые ошибки

Ошибка 1: Plain-Modbus TCP по интернету. Modbus TCP без TLS работает через публичный интернет. Любой может подключиться и менять значения регистров. Лечение — VPN или TLS-обёртка, изоляция в отдельной сети.

Ошибка 2: Polling вместо подписок. SCADA опрашивает PLC по Modbus каждые 100 мс по 100 переменным, забивает сеть. Лечение — переход на OPC UA с подписками или MQTT с retained сообщениями.

Ошибка 3: Игнор byte order. Modbus читает 32-битное число из двух регистров без согласования порядка байт (big-endian, little-endian, mixed). Получают мусор. Лечение — обязательная сверка порядка байт с документацией устройства.

Ошибка 4: QoS 2 для всего в MQTT. Команда взять «максимальную надёжность» во всех топиках. Брокер захлёбывается на handshake’ах при тысячах устройств. Лечение — QoS 0 для большинства телеметрии, QoS 1-2 только для критичных сообщений.

FAQ о промышленных протоколах

См. блок FAQ ниже — 7 главных вопросов архитекторов и инженеров.

Промышленные протоколы — фундамент архитектуры IIoT. Выбор зависит от уровня (полевой, диспетчерский, облачный) и задачи (надёжность, дистанция, ресурсы устройства). Modbus — для базовой совместимости, OPC UA — для современных серьёзных систем, MQTT — для облачной связи IIoT, специализированные (Profinet, CAN, LoRaWAN) — для конкретных ниш. Главные риски — игнор безопасности (plain-протоколы по сети), polling вместо событий, ошибки в byte order. Если планируете архитектуру IIoT — закладывайте протоколы каждого уровня на этапе предпроектного обследования, не догоняйте проблемы в проде.

Стандарты и регуляторы

Архитектура и реализация описанных систем опирается на международные и российские стандарты. Эти документы — обязательный справочный фундамент для проектирования и эксплуатации:

• IEC 62541 (OPC UA) — индустриальный стандарт безопасного и совместимого обмена данными между промышленным оборудованием и системами верхнего уровня (SCADA, MES, ERP).
• IEC 61131-3 (Programmable controllers) — стандарт языков программирования промышленных контроллеров (Ladder Diagram, Function Block Diagram, Structured Text, Instruction List, Sequential Function Chart). Российский эквивалент — ГОСТ Р МЭК 61131-3-2016.
• IEC 62443 (Industrial cybersecurity) — серия стандартов кибербезопасности промышленных автоматизированных систем (IACS), включая защиту АСУ ТП, SCADA, PLC. Базовый стандарт для построения защищённой архитектуры объектов КИИ.
• IEC 61511 (Functional safety — SIS) — функциональная безопасность приборных систем безопасности (Safety Instrumented Systems) на технологических объектах: нефтегаз, химия, энергетика.