Modbus — один из немногих промышленных протоколов, который не пытается быть «умнее жизни». Он честно делает простую вещь: позволяет читать и записывать данные устройства по адресу. Именно поэтому Modbus живёт десятилетиями и до сих пор встречается в проектах чаще, чем многие более «современные» решения.
Но как только в одном объекте появляются Modbus RTU и Modbus TCP, начинается путаница: «это же Modbus, значит всё одинаково». На уровне смысловой части — да, логика команд и регистров похожа. Но на уровне транспорта, кадрирования и диагностики это два разных мира. Разберёмся без лирики: что внутри RTU и TCP, как формируется кадр, откуда берутся типовые проблемы и когда какой вариант выбирать.
Modbus как идея: запрос–ответ и функциональные коды
Modbus — прикладной протокол с моделью клиент–сервер (раньше говорили master–slave). Инициатива почти всегда у клиента: он отправляет запрос, сервер отвечает. Устройства сами по себе «в эфир» не говорят — поэтому Modbus традиционно завязан на опрос.
Основные сущности протокола:
- Функциональный код: что именно сделать (прочитать регистры, записать регистр, записать несколько и т.д.).
- Адрес и данные: что именно читать/писать и в каком объёме.
Важный нюанс: Modbus не описывает смысл данных. Он не знает, что «это температура», а «это давление». Он знает только: «вот 16-битное значение в таком-то регистре». Дальше всё держится на документации производителя и вашей карте тегов.
Modbus RTU: двоичный кадр и дисциплина таймингов
Где живёт RTU
Modbus RTU чаще всего работает по RS-485 (иногда RS-232). То есть это типичная шина: несколько устройств на одной линии, полудуплекс, общие правила по терминаторам и поляризации.
Из чего состоит кадр RTU
RTU — компактный двоичный формат. В кадре обычно есть:
- Адрес устройства (1 байт)
- Функциональный код (1 байт)
- Поле данных (переменная длина)
- CRC16 (2 байта)
Главная «фишка» RTU — разделение кадров по паузе. Конец кадра определяется не символом, а временем тишины на линии (классическая пауза порядка 3.5 символа относительно текущей скорости). Отсюда два практических вывода:
- RTU чувствителен к настройкам порта (скорость, биты, чётность, стоп-биты).
- RTU чувствителен к «кривым» адаптерам и драйверам, которые ломают тайминги.
Адресация
В RTU адрес устройства — это число 1…247 (0 иногда используют как широковещательный без ответа). Ваша задача — раздать эти адреса приборам и не допустить дублей.
Modbus TCP: Modbus в сетевой упаковке TCP/IP
Где живёт TCP
Modbus TCP работает по Ethernet поверх TCP (обычно порт 502). Здесь уже не общая шина, а сеть со свитчами, сегментацией, маршрутизацией, full-duplex и всем сетевым хозяйством.
Что добавляется в TCP-версии
Смысловая часть Modbus (функция + данные) остаётся той же. Но появляется заголовок MBAP (Modbus Application Protocol), который позволяет работать поверх TCP-потока:
- Transaction ID — чтобы связать ответ с запросом
- Protocol ID — как правило 0
- Length — длина оставшейся части
- Unit ID — идентификатор устройства «внутри»
И важное отличие: в Modbus TCP нет CRC внутри Modbus-кадра. Целостность и доставка обеспечиваются уровнем Ethernet и TCP, поэтому RTU-шный CRC здесь просто не нужен.
Зачем нужен Unit ID
В «чистом» Modbus TCP, когда устройство — это один IP-адрес, Unit ID часто выставляют по умолчанию и не трогают. Но Unit ID становится критичным, когда вы используете шлюз TCP↔RTU: сеть приносит запрос в шлюз, а дальше он по Unit ID выбирает RS-485-адрес прибора.
Таблицы данных Modbus: coils и registers без мифологии
Modbus оперирует четырьмя типами данных (исторически называют “таблицами”):
- дискретные выходы (coils, 1 бит),
- дискретные входы (discrete inputs, 1 бит),
- входные регистры (input registers, 16 бит),
- регистры хранения (holding registers, 16 бит).
В документации это часто пишут как 0xxxx/1xxxx/3xxxx/4xxxx, но в реальном запросе передаётся смещение и количество. И здесь появляется самая известная проблема Modbus: 0-based vs 1-based.
Одна документация говорит «40001», а библиотека/SCADA ждёт адрес «0». Или наоборот. Симптомы обычно такие: «читается, но не то» или «сдвиг на один регистр». Лечится только дисциплиной: для каждого устройства фиксировать, как оно адресуется, и как конкретный драйвер трактует адреса.
RTU и TCP: реальные различия в одном месте
Если убрать философию, различия сводятся к нескольким инженерным пунктам:
- Среда передачи: RTU — последовательная линия, TCP — сеть Ethernet.
- Кадрирование: RTU держится на паузах и таймингах, TCP — на длине и структуре MBAP в TCP-потоке.
- Контроль целостности: RTU использует CRC16 внутри кадра, TCP полагается на сетевые механизмы.
- Адресация: RTU — адрес устройства в кадре; TCP — IP-адрес и при необходимости Unit ID.
- Поведение задержек: RTU чаще даёт стабильные задержки при хорошем RS-485; TCP может давать джиттер из-за сети.
- Масштабирование: TCP удобнее для распределённых объектов и длинных расстояний, RTU проще и дешевле на «локальных» линиях.
Самый полезный вывод: Modbus TCP не делает Modbus автоматически лучше. Он делает его удобнее для сетевых архитектур, но добавляет сетевые риски и требования к инфраструктуре.
Производительность: почему «TCP быстрее» бывает обманчиво
У Ethernet скорости большие, но Modbus редко упирается только в мегабиты. В реальности ограничивающими факторами становятся:
- время ответа устройств (особенно у «тяжёлых» приборов),
- частота опроса,
- количество запросов и их организация,
- ограничение на длину чтения (типично до 125 регистров за раз),
- загрузка клиента/сервера.
RTU может работать очень шустро на аккуратной шине и разумном опросе. TCP может «плыть», если сеть перегружена, сегменты смешаны с офисным трафиком, свитчи слабые или кто-то воткнул беспроводной мост «временно».
Надёжность: RTU часто держится за счёт простоты, TCP — за счёт правильной сети
RTU хорош тем, что его физика проста и диагностируется «в железе»: линия, терминаторы, поляризация, качество кабеля, экранирование, земля. Если всё собрано правильно — работает годами.
TCP требует сетевой культуры: сегментация, грамотные свитчи, отсутствие странных промежуточных устройств, понимание, что firewall/NAT/маршрутизация могут внезапно влиять на устойчивость соединений. Сеть — это тоже система, а не «просто провод потолще».
Типовые ошибки, которые чаще всего портят жизнь
Ошибка №1: адреса регистров.
Смешали 0-based и 1-based — получили «правильные» числа, но из чужих регистров.
Ошибка №2: физика RS-485 в RTU.
Нет терминаторов, нет поляризации, кабель «какой был», экран заземлён хаотично — и начинаются ночные CRC-ошибки или отвал отдельных узлов.
Ошибка №3: сеть в TCP «как получится».
Порт 502 закрыт, firewall рвёт соединения, NAT вмешивается, сеть без сегментации и с тяжёлым трафиком — и вы получаете таймауты, которые «то есть, то нет».
Ошибка №4: опрос мелкими запросами.
Сто чтений по одному регистру почти всегда хуже, чем одно чтение блоком. Оптимизация опроса часто даёт больший эффект, чем замена RTU на TCP.
Что выбирать: RTU или TCP
Если упростить, то выбор обычно диктуется геометрией объекта и инфраструктурой:
- Компактный участок, много приборов рядом, минимум сетевой возни — RTU часто проще и дешевле.
- Распределённые узлы, несколько щитов, большие расстояния, нужна гибкость — TCP удобнее.
- Приборы только RS-485, а вверх нужна Ethernet-интеграция — ставят шлюз RTU↔TCP и аккуратно ведут Unit ID/адреса.
На практике часто живёт гибрид: на нижнем уровне RS-485/RTU, наверх — Ethernet/TCP. Один раз упомяну нативно: в таких схемах удобно, когда контроллер или шлюз (включая решения СТАБУР) умеет и Modbus RTU по RS-485, и Modbus TCP по Ethernet — тогда сбор и маршрутизация данных делаются без россыпи внешних конвертеров.
Итог
Modbus RTU — двоичный протокол для последовательной линии, где кадр держится на таймингах и CRC, а качество связи зависит от физики RS-485 и дисциплины монтажа.
Modbus TCP — тот же Modbus по смыслу, но упакованный в TCP/IP с заголовком MBAP, где всё завязано на сетевую инфраструктуру, маршрутизацию и стабильность TCP-сессий.
Если воспринимать Modbus как инструмент доставки регистров, а не как «умную автоматизацию», тогда RTU и TCP перестают быть предметом спора. Это просто два способа решить одну задачу в разных условиях. И правильный вопрос звучит так: какой вариант будет устойчивее и проще обслуживаться именно на вашей площадке.
Автор: Дмитрий Стабуров, инженер АСУ ТП