Modbus RTU и Modbus TCP: Что внутри протокола и почему «по Ethernet» – не всегда лучше
2026-02-09 12:59
Modbus – это тот самый протокол, который пережил десятки «убийц индустрии», потому что он прост, предсказуем и понятен даже в три часа ночи на пусконаладке. Но как только в одном проекте встречаются Modbus RTU и Modbus TCP, начинается вечная путаница: «Это же один Modbus, значит разницы почти нет?» Разница есть. И она не только в кабеле.
На бумаге Modbus RTU и Modbus TCP выглядят как "один и тот же протокол в разной упаковке". На объекте все иначе: проект может работать неделями стабильно, а потом внезапно ловить фантомные таймауты, скачки задержек и чтение "не тех" регистров.
В 90% случаев проблема не в самом Modbus. Проблема в инженерной дисциплине: адресация, карта регистров, опрос, физика линии RS-485 или архитектура Ethernet. Именно это и разделяет "собрали и забыли" от "постоянно тушим пожар".
Ниже - не теория, а прикладной разбор того, как выбрать RTU/TCP и не похоронить проект на пусконаладке.
Блок "Короткий ответ"
RTU чаще выигрывает в простых локальных шинах с предсказуемой физикой. TCP удобнее для масштабирования и распределенных объектов. Большинство сбоев появляется из-за ошибок адресации, опроса и сетевой архитектуры, а не из-за "плохого протокола".
Что такое Modbus по сути
Modbus – это протокол прикладного уровня с моделью клиент–сервер (исторически говорили “master–slave”). Клиент инициирует запрос, сервер отвечает. В Modbus нет “самопроизвольных” сообщений по инициативе устройства – почти всегда опрос.
В основе Modbus лежат две идеи:
Адресуемые данные (регистры/входы/выходы), которые читают и пишут по номерам.
Функциональные коды, которые говорят устройству, что сделать: прочитать регистры, записать регистр, записать несколько и т.д.
Важно: Modbus – не про семантику данных. Протокол не знает, что такое “температура” или “давление”. Он знает только “регистр 40021, 16 бит”. Всё остальное – договорённость между производителем устройства и интегратором.
Modbus RTU: кадр, тайминги и RS-485 «как оно работает в цеху»
Физика и канал
Modbus RTU почти всегда живёт поверх RS-485 (реже RS-232). Это многоточечная шина: один сегмент, несколько устройств, общая линия. Полудуплекс, терминаторы, поляризация – классика.
Как выглядит кадр RTU
RTU – двоичный формат. В запросе и ответе есть:
Адрес устройства (1 байт)
Функциональный код (1 байт)
Данные (N байт)
CRC16 (2 байта) – контроль целостности
Кадр в RTU отделяется не специальными символами, а паузой по времени: “тишина” на линии должна быть минимум 3.5 символа (в терминах времени передачи на данной скорости). Отсюда главный практический вывод: RTU очень чувствителен к таймингам, “творческим” USB-RS485 адаптерам и неправильным настройкам порта.
Адресация
В RTU адрес – это байт 1…247 (0 иногда используют как broadcast без ответа). То есть в одной шине вы физически “сопоставляете” адрес устройству.
Modbus TCP: тот же Modbus, но в упаковке TCP/IP
Физика и канал
Modbus TCP работает поверх Ethernet/IP и транспорта TCP (обычно порт 502). Это уже не общая шина, а сеть со свитчами, маршрутизацией, разными сегментами и нормальным full-duplex.
Что внутри пакета Modbus TCP
В Modbus TCP тот же PDU (функциональный код + данные), но добавляется заголовок MBAP (Modbus Application Protocol header):
Transaction ID (2 байта) – чтобы сопоставить ответы запросам
Protocol ID (2 байта) – обычно 0
Length (2 байта) – длина последующей части
Unit ID (1 байт) – “адрес устройства” внутри
И важный момент: CRC в TCP нет, потому что целостность обеспечивает Ethernet (FCS) + TCP (checksum и контроль доставки). Поэтому кадр короче и меньше “привязан” к таймингам линии.
Unit ID – зачем он вообще нужен
В чистом Modbus TCP, когда вы общаетесь с одним IP-устройством, Unit ID часто ставят 1 и забывают. Но Unit ID становится важным, когда Modbus TCP используется как “туннель” к RTU через шлюз: IP-шлюз принимает TCP-запрос, по Unit ID выбирает RTU-адрес и уже на RS-485 идёт к нужному прибору.
Общая логика данных: “coils” и “registers” без мистики
В реальном кадре “0xxxx/4xxxx” не передаются – передаётся адрес смещения (обычно 0-based) и количество.
И тут родилась самая популярная ошибка: документация пишет “40001”, а устройство ждёт “адрес 0”. Или наоборот. В одном проекте это лечится таблицей соответствий и дисциплиной: фиксируете, как именно трактует адреса конкретное устройство и конкретная библиотека/SCADA.
Ключевые различия RTU vs TCP – коротко и по делу
Ниже – таблица, которую удобно держать в голове при выборе архитектуры.
Характеристика
Modbus RTU
Modbus TCP
Среда передачи
RS-485/RS-232
Ethernet/IP
Топология
Шина (многоточечная)
Сеть (звезда/иерархия через свитчи)
Разделение кадров
Пауза по времени
Длина в заголовке (MBAP), TCP-поток
Контроль целостности
CRC16 внутри кадра
Встроенные механизмы Ethernet/TCP
Адресация устройств
1…247
IP + Unit ID
Задержки/джиттер
Обычно стабильные, но зависят от опроса и шины
Могут быть “плавающими” из-за сети
Скорость и масштаб
Ограничено скоростью порта и шиной
Масштабируется лучше, но требует сетевой дисциплины
Главная мысль: TCP не делает Modbus “промышленнее”. Он делает его удобнее для распределённых сетей и больших расстояний, но добавляет сетевые риски.
Производительность: почему “TCP быстрее” – не универсальная истина
Да, Ethernet 100 Мбит/с выглядит как космос по сравнению с RS-485 на 9600 бод. Но Modbus упирается не только в физическую скорость. Упирается в:
частоту опроса и длину запросов,
время реакции устройств,
ограничения на количество регистров за один запрос (часто 125 регистров чтения),
нагрузку на мастер/клиент и на сервер,
организацию сети (в TCP).
RTU может быть “быстрым” на короткой линии с хорошей дисциплиной опроса. TCP может стать “медленным” в сети, где одновременно крутятся тяжёлые потоки, свитчи перегружены, а кто-то ещё и Wi-Fi мост поставил “временно, на испытания”.
Надёжность: почему RTU иногда живее всех живых
У RTU есть простое преимущество: физически понятный канал. Один кабель, терминаторы, скорость, чёткая диагностика осциллографом. Если линия нормальная – работает годами.
TCP хорош, когда сеть построена правильно: сегментация, QoS при необходимости, промышленное железо, отсутствие “сюрпризов” вроде бытовых роутеров в шкафу управления.
Правильный вывод: RTU – это про устойчивость на простом физическом уровне. TCP – про масштабирование при условии сетевой дисциплины.
Типовые ошибки, которые ломают проекты
1) Смешали адресацию 0-based и 1-based
Это причина “регистры читаются, но не те”. Лечится только одним способом: проверка на реальном устройстве и фиксация правила в проектной документации.
2) В RTU забыли про физику RS-485
Терминаторы не там, поляризация отсутствует, экран заземлён “как получилось”, кабель не витая пара – а потом удивление: “почему ночью ошибки CRC”. RS-485 – не магия, он любит дисциплину.
3) В TCP не учли, что сеть – это тоже система
Порт 502 блокируется, NAT портит сессии, “умный” firewall режет соединения, свитч в кольце без нормального протокола резервирования – и всё превращается в непредсказуемость.
4) Опрос построили «как попало»
Сто запросов по одному регистру хуже, чем один запрос пачкой. В обоих мирах (RTU и TCP) оптимизация опроса решает половину проблем с нагрузкой и задержками.
Как выбрать: RTU или TCP в конкретной задаче
Если говорить инженерно, выбор обычно сводится к условиям площадки:
Один шкаф/одна линия/куча приборов рядом → RTU часто проще и дешевле.
Есть приборы только с RS-485, но сеть уже Ethernet → ставите шлюз RTU↔TCP и аккуратно ведёте Unit ID.
В нормальной архитектуре часто встречается гибрид: “на местах” RTU как полевая шина, “вверх” – TCP до SCADA/серверов. Один раз упомяну нативно: в таких схемах удобно, когда контроллер/шлюз (в том числе из линейки СТАБУР) умеет и RS-485 Modbus RTU, и Ethernet Modbus TCP – тогда сбор данных и маршрутизация делаются без зоопарка внешних конвертеров.
FAQ
Почему "читается, но не то значение"?
Обычно перепутана 0-based/1-based адресация или неверно собрана карта регистров конкретного устройства.
Нужно ли всегда переходить на TCP, если есть Ethernet?
Нет. Если топология простая и локальная, RTU может быть устойчивее и дешевле в эксплуатации.
Зачем Unit ID в Modbus TCP?
Unit ID критичен при работе через шлюзы TCP-RTU, где нужно адресовать конечное устройство на RS-485.
Как снизить таймауты и "плавающие" отказы?
Оптимизировать опрос пакетами, навести порядок в карте регистров, проверить физику RS-485 или сегментацию сети для TCP.
Итог: чем они реально отличаются
Modbus RTU – компактный двоичный протокол для последовательных линий, где кадр держится на таймингах и CRC, а надёжность – на качестве RS-485.
Modbus TCP – тот же смысловой Modbus, но упакованный в TCP/IP с MBAP-заголовком, где кадры живут в сетевой логике и зависят от архитектуры Ethernet.
Если помнить, что Modbus не про “умную автоматизацию”, а про честную доставку регистров, то RTU и TCP перестают быть “религией”. Они становятся инструментами под разные условия. И тогда вместо вечного “что лучше?” появляется нормальный вопрос: что устойчивее и дешевле именно для этой площадки и этой сети.
Практически удобнее архитектуры, где оборудование поддерживает оба режима обмена - RTU и TCP. К такому оборудованию и относится ПЛК СТАБУР. Это снижает число промежуточных конвертеров и упрощает миграцию существующих узлов без полной переделки проекта.