Три режима Modbus: RTU, TCP и RTU-over-TCP - когда какой и почему ломаются опросы
2026-05-11 10:53
В одном проекте в драйвере стоит «Modbus TCP», а шлюз ждёт «сырой RTU внутри сокета». В другом - на RS-485 всё летает, а через конвертер в Ethernet «то 0x03, то тишина». Третий - Wireshark на TCP показывает красивые пакеты, а SCADA ругается на CRC, потому что оператор включил не тот режим разбора кадра.
Ниже - различие фрейминга, типичные шлюзы и конвертеры, ловушки задержки и буферов, высокоуровневая диагностика tcpdump/Wireshark и блок про пять типовых ошибок конфигурации и как их быстро распознать.
Короткий ответ
Modbus RTU - последовательная шина: кадр ограничен таймингом (пауза между кадрами), адрес, PDU, CRC16.
Modbus TCP - обмен запрос-ответ в TCP: перед PDU идёт заголовок MBAP (в т. ч. Transaction ID, Unit ID, длина), CRC Modbus в кадр не входит - целостность на уровне TCP/IP.
RTU-over-TCP (в документации часто «RTU over Ethernet/TCP», «serial framing over TCP») - в TCP уходит последовательность байт в стиле RTU, иногда с CRC, иногда по вендорским правилам; это не тот же разбор, что у чистого Modbus TCP, если только устройство явно не документирует обратное.
Опросы «ломаются», когда режим клиента, режим шлюза и фактический формат на проводе расходятся хотя бы в одной точке.
Modbus RTU: фрейминг и где ломается
На RS-485 (или RS-232) кадр RTU - это непрерывный блок байт с адресом, кодом функции, данными, CRC. Конец кадра для приёмника определяется паузой не меньше времени 3,5 символа при текущей скорости (на практике ещё и аппаратные буферы UART).
Типичные поломки:
•Слишком короткие таймауты между запросами - второй кадр «накладывается» на хвост первого.
•Неверные скорость/чётность/stop - «мусор» и вечные CRC error.
•Терминирование и топология RS-485 - отражения и искажения длительности фронтов, что для некоторых приборов эквивалентно порче тайминга.
•Два мастера на одной шине без арбитража.
Modbus TCP: фрейминг и где ломается
Здесь нет «паузы 3,5 символа» как критерия кадра. Граница сообщения задаётся MBAP Length и логикой TCP-потока: приложение читает из сокета столько байт, сколько объявлено в заголовке.
Типичные поломки:
•Неверный Unit ID при маршрутизации через шлюз к RTU-адресам.
•Разные таймауты TCP и приложения Modbus (NAT, полусухая сессия) - см. отдельный разбор в материале про TCP для интегратора.
•Несколько клиентов на один слейв без поддержки.
RTU-over-TCP: что обычно имеют в виду
В инженерной речи под RTU-over-TCP чаще всего попадают три разных зверя - их стоит развести в паспорте объекта:
1.Формально Modbus TCP по спецификации, но в поле Unit ID шлюз подставляет адрес RTU - снаружи это TCP с MBAP, внутри шлюза - RTU. Это всё ещё «правильный» Modbus TCP для клиента, а RTU остаётся за шлюзом.
2.Поток байт RTU (иногда с CRC) внутри TCP без MBAP или с нестандартной обёрткой - реализация серийных серверов и части прозрачных туннелей. Клиент должен уметь именно так собирать кадры (иногда драйвер называет это «RTU over TCP»).
3.Modbus RTU через UDP или иной транспорт - редко, но встречается в старых утилитах; важно не смешивать с п. 2 при диагностике.
Если в Wireshark вы видите MBAP (длина, Protocol ID = 0) - вы на Modbus TCP. Если видите старт сразу с адреса RTU и CRC в конце в TCP payload - это уже территория RTU-over-TCP в смысле п. 2.
Шлюзы и конвертеры: что они делают с кадром
Прозрачный serial device server - перекидывает байты; ответственность за тайминг RTU и целостность кадра частично переезжает на прошивку шлюза (как он склеивает буфер из TCP в UART).
Полноценный Modbus TCP - RTU шлюз - принимает MBAP+PDU, сам опрашивает RS-485 по RTU, агрегирует ошибки. Здесь ищите очереди, таймауты RTU-стороны, лимит запросов в секунду.
Двухпортовый «мост» - может вводить задержку на рестарт шины после тяжёлого запроса.
Практическое правило: на схеме проекта у каждого такого узла должна быть строка «вход: режим A, выход: режим B, макс. N запрос/с».
Латентность и буферизация
TCP добавляет джиттер: буферы сетевых стеков, Nagle (реже мешает Modbus), очереди в ОС. Для RTU это было бы недопустимо как «транспорт кадра», но для Modbus TCP это нормальный мир - там кадр определяется длиной, а не паузой.
Для RTU-over-TCP снова всплывает чувствительность к склейке и разрезанию TCP: шлюз или клиент может получить половину RTU-кадра в одном read и вторую - в следующем; парсер обязан ждать полный кадр по CRC/длине, а не «обрабатывать сразу».
Симптом: на низкой нагрузке всё ок, под нагрузкой поползли таймауты - смотрите размер очереди и агрессивность опроса.
Диагностика: Wireshark и tcpdump (высокий уровень)
•Сверяйте Transaction ID и длину; ищите RST, повторные SYN, длинные интервалы между запросом и ответом.
RTU-over-TCP
•В том же TCP payload смотрите, есть ли MBAP. Если нет - ваш «TCP» в драйвере должен быть в режиме RTU-over-TCP (или аналогичном названии вендора).
•Полезно сравнить два захвата: на Ethernet у клиента и (если возможно) на RS-485 у шлюза - расходится ли количество кадров и их порядок.
Modbus RTU (последовательный порт)
•На ПК - COM-захват или лог адаптера; на объекте - осциллограф/логический анализатор только если есть навык; чаще достаточно USB-RS485 с мониторингом в утилите производителя.
Пять типовых ошибок конфигурации и как их распознать
1. В драйвере выбран «Modbus TCP», а устройство отдаёт RTU в TCP
Признаки: в Wireshark нет MBAP, виден CRC в хвосте, SCADA или библиотека ругается на «неверный заголовок» или CRC на уровне приложения.
Что сделать: переключить драйвер в RTU-over-TCP (или как у вас назван режим), либо поставить нормализующий шлюз, который снаружи говорит чистым Modbus TCP.
2. Шлюз Modbus TCP - RTU, а Unit ID не совпадает с адресом RTU
Признаки: TCP-сессия живая, в Modbus TCP видны корректные запросы, но исключение «нет такого устройства» или ответы «с другого адреса».
Что сделать: выровнять Unit ID в MBAP с адресом на шине согласно мануалу шлюза (или наоборот - фиксировать адрес на шлюзе и не трогать поле).
3. На RS-485 «всё верно», но через конвертер «плавает» CRC
Признаки: ошибки растут с частотой опроса; на прямом коротком шлейфе без конвертера лучше.
Что сделать: проверить терминаторы, GND/экран, скорость, задержку inter-frame в мастере; в настройках сервера последовательного порта - UART latency, буферизация, FIFO.
4. Дублирование мастеров: RTU и TCP одновременно в один слейв
Признаки:случайные таймауты, «ломающиеся» длинные ответы, растущие счётчики ошибок при подключении второй системы.
Что сделать: оставить одного мастера на линию или ввести мультиплексор/арбитраж осознанно.
5. Слишком агрессивный опрос через шлюз без учёта его очереди
Признаки:рост задержки ответа Modbus TCP линейно от числа тегов; на стороне RS-485 шлюза переполнение или дроп кадров.
Что сделать:группировать регистры, снизить частоту, включить приоритеты в SCADA, разнести тяжёлые устройства по разным портам шлюза.
Где уместен СТАБУР
В проектах на базе СТАБУР разумно зафиксировать глоссарий транспорта Modbus в исполнительной документации: где чистый TCP с MBAP, где RTU на меди, где туннель, какие таймауты и лимиты RPS на шлюзах. Это снижает количество «магических» переключений галочек в драйверах при сдаче объекта.
Заключение
RTU, TCP и RTU-over-TCP - это не три «одинаковых Modbus с разным проводом», а три разных представления кадра на проводе. Пока интегратор не назовёт явно формат на каждом сегменте и в каждом драйвере, опросы будут ломаться ровно на границах - там, где один мир ждёт MBAP, а другой - паузу и CRC.
FAQ
Можно ли считать RTU-over-TCP «устаревшим»?
Нет как категории: это реальность серийных серверов. Важно не название, а совпадение формата с драйвером.
Почему на Wireshark «всё зелёное», а в SCADA ошибка?
Потому что зелёное - про TCP, а ошибка может быть в семантике Modbus, Unit ID или в режиме разбора PDU.
Нужен ли отдельный VLAN только под Modbus TCP?
Иногда да, если смешение с шумным трафиком даёт джиттер; базовая гигиена сети описана в материале про VLAN в OT.
Один порт 502 - всегда стандарт?
Часто да, но встречаются нестандартные порты - фиксируйте в проекте.
Стоит ли гнать Modbus TCP через VPN без ограничений?
Только с пониманием задержки и MTU: фрагментация и потери усиливают влияние на таймауты опроса.