Протокол Modbus: полное руководство по промышленной связи M2M

от Выкл

Содержание

Что такое Modbus и почему он стал стандартом
История создания и развитие протокола
Физический уровень: где работает Modbus
- Последовательные интерфейсы (RS‑232, RS‑422, RS‑485)
- Сети TCP/IP и Modbus TCP
Логический уровень: разновидности протокола
- Modbus ASCII
- Modbus RTU
- Modbus TCP
Формат пакета Modbus (ADU и PDU)
- Структура сообщения
- Адресация устройств
- Контрольные суммы (CRC, LRC)
Типы регистров и коды функций
- Discrete Inputs (функция 02)
- Coils (функции 01, 05, 15)
- Input Registers (функция 04)
- Holding Registers (функции 03, 06, 16)
Практический пример: чтение данных из устройства через Modbus TCP
- Инструмент modbus-cli
- Разбор даташита
- Формирование запроса и интерпретация ответа
Недостатки протокола Modbus
- Отсутствие аутентификации и шифрования
- Пассивная роль ведомых устройств
- Невозможность детектирования потери связи
Типовое оборудование с поддержкой Modbus
- Модули удалённого ввода‑вывода (I/O)
- Протокольные шлюзы (RTU ↔ TCP)
- Программируемые логические контроллеры (ПЛК)
Примеры применения в промышленности
- Мониторинг теплиц
- Контроль солнечных систем нагрева воды
Заключение: почему Modbus остаётся востребованным

1. Что такое Modbus и почему он стал стандартом

Modbus — это открытый протокол связи прикладного уровня, предназначенный для обмена данными между промышленными электронными устройствами. Он разработан в 1979 году компанией Modicon (ныне часть Schneider Electric) и с тех пор стал де‑факто стандартом в автоматизации.

Ключевые особенности, обеспечившие популярность:

Открытость — спецификация доступна бесплатно, любой производитель может реализовать протокол.
Простота — формат сообщений легко понять и отлаживать.
Универсальность — работает на разных физических средах (RS‑232, RS‑485, Ethernet).
Поддержка — почти все промышленные устройства (датчики, приводы, контроллеры) имеют Modbus.

Протокол используется для:

сбора показаний с датчиков (температура, давление, ток, напряжение);
управления реле, клапанами, приводами;
мониторинга состояния оборудования;
интеграции устройств разных производителей в единую систему.

2. История создания и развитие

1979 год — компания Modicon представляет Modbus для своих программируемых контроллеров. Протокол работает через последовательный интерфейс RS‑232.
1980‑е годы — появляется поддержка RS‑485, что позволяет создавать сети с несколькими ведомыми устройствами на большом расстоянии (до 1200 метров).
1990‑е годы — развитие Modbus ASCII (символьное представление) для работы на модемных линиях с большими задержками.
Конец 1990‑х — рождение Modbus TCP, упаковывающего сообщения в TCP/IP‑пакеты. Это позволило использовать стандартные Ethernet‑сети и интернет.
2004 год — права на протокол переданы некоммерческой организации Modbus Organization, которая поддерживает и развивает стандарт.

В описании Modbus до сих пор используется терминология релейной логики: катушки (coils) — это битовые выходы или флаги.

3. Физический уровень: где работает Modbus

3.1. Последовательные интерфейсы (RS‑232, RS‑422, RS‑485)

Интерфейс	Максимальная длина	Топология	Типичное применение
RS‑232	15 м	точка‑точка	программирование ПЛК, соединение с ПК
RS‑422	1200 м	точка‑точка (полнодуплекс)	высокоскоростные линии
RS‑485	1200 м	многоточечная (до 32 устройств)	промышленные сети Modbus RTU

Последовательные версии Modbus используют RTU (двоичный) или ASCII (текстовый) режим.

3.2. Сети TCP/IP и Modbus TCP

Modbus TCP работает поверх стандартных Ethernet‑сетей. Преимущества:

высокая скорость (100 Мбит/с и выше);
возможность использования готовой IT‑инфраструктуры (коммутаторы, маршрутизаторы);
простота адресации (IP‑адрес вместо номера узла);
поддержка большого количества одновременно подключённых клиентов.

Физическим каналом могут быть любые Ethernet‑интерфейсы: медные или оптические.

4. Логический уровень: разновидности протокола

4.1. Modbus ASCII

Представление данных — шестнадцатеричные числа, закодированные символами ASCII (каждый байт передаётся двумя символами: например, 0xAB → символы ‘A’ и ‘B’).
Разделители пакетов — символ двоеточия (:) в начале, и возврат каретки/перевод строки (CR+LF) в конце.
Контрольная сумма — LRC (8 бит), простая, но менее надёжная.
Область применения — линии с большими задержками, модемные соединения, где сложно выдерживать точные временные интервалы.

4.2. Modbus RTU (Remote Terminal Unit)

Представление данных — двоичное (каждый байт передаётся как есть).
Разделитель пакетов — временная пауза (молчание на линии) длительностью не менее 3.5 символов. Это критично: оборудование должно точно измерять интервалы.
Контрольная сумма — CRC‑16 (2 байта), очень надёжная.
Область применения — большинство промышленных сетей RS‑485. Пакеты компактнее, чем в ASCII.
Недостаток — не работает на каналах с переменной задержкой (например, радиомодемы).

4.3. Modbus TCP

Транспорт — TCP/IP, порт 502 (стандартный) или другой.
Структура — заголовок MBAP (Modbus Application Protocol) длиной 7 байт, затем PDU (как в RTU).
Контрольная сумма — отсутствует в ADU, т.к. TCP обеспечивает свою проверку целостности.
Адресация — вместо номера узла используется IP‑адрес, а поле «адрес устройства» в PDU часто игнорируется или используется для маршрутизации через шлюзы.
Преимущества — высокая скорость, работа через интернет, простота интеграции с IT‑системами.

5. Формат пакета Modbus (ADU и PDU)

5.1. Основные понятия

ADU (Application Data Unit) — полный пакет, который передаётся по физической среде. Включает адрес устройства, PDU и контрольную сумму (для RTU/ASCII).
PDU (Protocol Data Unit) — независимая от среды часть, содержащая код функции и данные. Одинакова для всех реализаций Modbus.

5.2. Структура сообщения

Реализация	Состав ADU
Modbus RTU	[Адрес (1 байт)] + [PDU] + [CRC16 (2 байта)]
Modbus ASCII	`:` + [Адрес (2 символа)] + [PDU] + [LRC (2 символа)] + `CR` + `LF`
Modbus TCP	[MBAP (7 байт: Transaction ID, Protocol ID, Length, Unit ID)] + [PDU]

Пояснение полей:

Адрес устройства — номер ведомого (slave) в сети (1…247). Адрес 0 используется для широковещательных запросов от мастера.
PDU состоит из:
- Код функции (1 байт) — определяет действие (чтение, запись, диагностика).
- Данные (переменная длина) — адреса регистров, количество регистров, записываемые значения.
Контрольная сумма — CRC16 для RTU, LRC8 для ASCII. В Modbus TCP отсутствует.

5.3. Принцип работы «запрос‑ответ»

Master (клиент) инициирует передачу: отправляет запрос с адресом ведомого.
Slave (сервер) с указанным адресом обрабатывает запрос и отправляет ответ (содержащий запрошенные данные или подтверждение записи).
Если адрес не совпадает, slave игнорирует запрос.
При ошибке (неверный код функции, недоступный регистр) slave возвращает исключение с кодом ошибки в поле данных.

6. Типы регистров и коды функций

Modbus оперирует четырьмя основными типами объектов. Исторически их адресация привязана к определённым диапазонам, но современные устройства могут использовать произвольное отображение.

Тип данных	Диапазон адресов (десятичный)	Доступ	Основные функции (чтение/запись)
Discrete Inputs (дискретные входы)	10001 – 19999	только чтение	`02` – чтение группы (до 2000 бит)
Coils (катушки)	20001 – 29999	чтение/запись	`01` – чтение `05` – запись одного `15` – запись нескольких
Input Registers (входные регистры)	30001 – 39999	только чтение	`04` – чтение (16‑битные слова)
Holding Registers (регистры хранения)	40001 – 49999	чтение/запись	`03` – чтение `06` – запись одного `16` – запись нескольких

Важные замечания:

Названия условны. «Вход» или «выход» может означать не физический сигнал, а внутреннюю переменную (счётчик, флаг, уставку). Например, регистр хранения может хранить задание скорости для частотного преобразователя.
Адрес в запросе обычно указывается как смещение от начала диапазона. Например, регистр 40001 соответствует смещению 0. Во многих библиотеках и утилитах адресация начинается с 0 или 1 в зависимости от реализации.
Существуют другие диапазоны (например, 0xxxx для катушек, 1xxxx для дискретных входов), но они используются редко.

7. Практический пример: чтение данных из устройства через Modbus TCP

7.1. Инструмент `modbus-cli`

Для экспериментов с Modbus TCP удобно использовать консольную утилиту modbus-cli (написана на Ruby). Она позволяет отправлять запросы на чтение и запись без написания кода.

Установка (пример):

bash

gem install modbus-cli

Основные команды:

modbus read <IP> <адрес регистра> <количество>
modbus write <IP> <адрес регистра> <значение>

7.2. Исходные данные: промышленный коммутатор

Предположим, у нас есть управляемый Ethernet‑коммутатор, который предоставляет по Modbus TCP счётчики переданных пакетов для каждого порта. Задача — прочитать количество пакетов, переданных через порт 1.

Информация из документации (Modbus Mapping Table):

Счётчик переданных пакетов для порта 1 хранится в четырёх последовательных 16‑битных регистрах (64‑битное целое число).
Начальный адрес: 38193 (диапазон Input Registers, т.к. 3xxxx).
Формат хранения: шестнадцатеричный, младший байт справа (little‑endian). Например, число 0xAB4130 будет записано как 30 41 AB 00 (по байтам).

7.3. Формирование запроса

Используем команду чтения. Утилита автоматически выберет функцию 04 (чтение входных регистров), так как адрес начинается с 3.

bash

modbus read 192.168.0.17 38193 4

Разбор:

192.168.0.17 — IP‑адрес коммутатора.
38193 — начальный адрес регистра (первый из четырёх).
4 — количество регистров.

7.4. Ответ и интерпретация

Программа выводит значения регистров в шестнадцатеричном виде:

text

38193   0x0000
38194   0x0000
38195   0x0000
38196   0x3459

Мы видим, что первые три регистра равны 0x0000, а четвёртый — 0x3459. В десятичной системе 0x3459 = 13401. Это и есть количество переданных пакетов (коммутатор был включён недавно).

Если бы число было больше 65535, оно заняло бы два или более регистров. Тогда нам пришлось бы объединить их в 32‑битное или 64‑битное значение, учитывая порядок байт (little‑endian).

8. Недостатки протокола Modbus

Несмотря на повсеместное распространение, Modbus имеет серьёзные ограничения, связанные с его возрастом (разработан в 1979 году).

8.1. Отсутствие аутентификации и шифрования

Все данные передаются в открытом виде.
Любой, кто имеет доступ к сети, может отправлять запросы и подменять значения.
Решение: при использовании Modbus TCP необходимо применять дополнительные меры защиты: VLAN, брандмауэры, VPN‑туннели (например, IPsec или OpenVPN). Для последовательных сетей — физическая изоляция.

8.2. Только опросный режим (master‑slave)

Ведомое устройство не может само инициировать передачу данных (например, сообщить об аварии).
Мастер вынужден постоянно опрашивать все ведомые устройства, что создаёт нагрузку на сеть и задерживает реакцию на события.
Решение: использовать дополнительные дискретные сигналы тревоги или переходить на другие протоколы (например, OPC UA, MQTT) там, где требуется асинхронная передача.

8.3. Ведомое устройство не может обнаружить потерю связи

Если мастер перестал опрашивать, ведомое продолжает работать и не знает, что связь потеряна.
Решение: в прикладной программе мастера необходимо реализовать таймауты и контроль heartbeat. Ведомое может следить за временем между запросами (например, параметр P2014 в частотниках Sinamics V20).

8.4. Ограниченные типы данных

Базовый Modbus передаёт только биты и 16‑битные слова. Для передачи 32‑битных чисел (float, int32) нужно использовать два последовательных регистра. При этом возникает проблема порядка байт (endianness), которую по‑разному решают производители.

8.5. Отсутствие стандартизации адресов

Производители вольны размещать любые параметры в любых регистрах. Для работы с устройством всегда нужно обращаться к его документации (Modbus‑карте).

9. Типовое оборудование с поддержкой Modbus

Современный рынок предлагает множество устройств, поддерживающих Modbus. Вот основные категории:

9.1. Модули удалённого ввода‑вывода (Remote I/O)

Предназначены для подключения датчиков и исполнительных механизмов вдали от основного контроллера.
Работают обычно в режиме slave (сервер Modbus). Мастер (ПЛК, SCADA, промышленный ПК) опрашивает модули.
Поддерживают дискретные и аналоговые каналы, счётчики импульсов, термопары.
Многие модели имеют функцию GCL (графическая логика условий) для автономного выполнения простых правил.
Типовые интерфейсы: RS‑485 (Modbus RTU) или Ethernet (Modbus TCP).

9.2. Протокольные шлюзы (Modbus RTU ↔ Modbus TCP)

Zentec M410 программируемый контроллер с Ethernet, WiFi, RS-485, поддержкой Modbus TCP/RTU, MQTT, BACnet, SNMP. Процессор ESP32, 390 КБ памяти.

Позволяют подключать устаревшие или недорогие устройства с последовательным интерфейсом к современным Ethernet‑сетям.
Шлюз получает запросы по Modbus TCP и преобразует их в RTU/ASCII, отправляя через RS‑232/422/485.
Некоторые модели имеют до 4 независимых последовательных портов.

9.3. Программируемые логические контроллеры (ПЛК)

Большинство современных ПЛК (Siemens, Allen‑Bradley, Schneider Electric, OMRON, Mitsubishi) поддерживают Modbus TCP и RTU в качестве мастера или ведомого.
Для некоторых контроллеров (например, Siemens S7‑300) могут потребоваться дополнительные лицензии или шлюзы.

9.4. Датчики и измерительные приборы

Клапаны, расходомеры, анализаторы газов, преобразователи частоты, счётчики электроэнергии — многие имеют Modbus RTU или TCP.

10. Примеры применения в промышленности

10.1. Система мониторинга теплиц

Задача: контролировать температуру, влажность, освещённость, управлять вентиляцией и поливом в нескольких теплицах.

Решение на базе Modbus:

В каждой теплице устанавливаются модули удалённого ввода‑вывода (например, аналоговые входы для датчиков, релейные выходы для управления насосами и вентиляторами).
Модули подключаются к Ethernet‑коммутатору и работают как slave Modbus TCP.
Центральный контроллер (или промышленный ПК) выступает в роли master, циклически опрашивая модули и выполняя логику управления.
Данные отображаются на панели оператора (HMI) и могут передаваться в облачную SCADA для удалённого мониторинга.

Преимущества:

модульность — легко добавить новые теплицы;
дешевизна — стандартные компоненты;
простота замены — любое устройство с Modbus.

10.2. Контроль системы нагрева воды солнечной энергией

Задача: измерять температуру воды на входе и выходе солнечного коллектора, расход, количество полученной энергии, а также управлять циркуляционным насосом. Данные должны записываться и отображаться на локальном ЖК‑дисплее.

Решение:

Датчики температуры (PT100) и расходомер подключаются к аналоговым входам Modbus‑модуля.
Модуль (slave) по RS‑485 передаёт значения на ПЛК (мастер).
ПЛК вычисляет мощность и накопленную энергию, управляет насосом, а также отправляет данные на панель оператора.
История значений сохраняется в ПЛК или на SD‑карте.

Почему Modbus: позволяет легко добавлять новые датчики (до 32 на одну линию RS‑485) и не привязывает к одному производителю.

11. Заключение: почему Modbus остаётся востребованным

Несмотря на технические недостатки и появление более современных протоколов (OPC UA, MQTT, Profinet, EtherNet/IP), Modbus продолжает занимать лидирующие позиции в промышленной автоматизации. Причины:

Открытость и простота — любой инженер за пару часов может освоить основы и отладить обмен.
Низкие требования к ресурсам — реализация возможна даже на 8‑битных микроконтроллерах.
Огромная база установленного оборудования — миллионы устройств уже работают, и их не заменят за один день.
Поддержка всеми SCADA и ПЛК — редко встретишь систему, которая не умеет работать с Modbus.

Для новых проектов, где требуется высокий уровень безопасности или асинхронная передача событий, следует рассмотреть альтернативы. Однако для 80% типовых задач сбора данных и управления Modbus остаётся самым быстрым и экономичным решением.

Рекомендации при использовании Modbus:

Внимательно читайте документацию на устройство (Modbus‑карту).
Учитывайте порядок байт (endianness) при работе с многобайтовыми значениями.
Защищайте Modbus TCP сети VPN или изолируйте их на физическом уровне.
Реализуйте в мастере контроль таймаутов и heartbeat для детектирования потери связи.

РубрикаРуководства