Прозрачная передача Serial-to-TCP или преобразование протоколов: что нужно вашему устройству?
Выбирайте прозрачный шлюз Serial-to-TCP, если ПО хоста продолжит использовать существующий последовательный протокол устройства. Выбирайте преобразование протоколов, если хост ожидает другой прикладной протокол, например Modbus TCP вместо Modbus RTU. Первый вариант передаёт байты, второй интерпретирует и заново формирует сообщения.
Это решение принимают до выбора оборудования. «RS485–Ethernet» описывает интерфейсы, но не обеспечивает совместимость ПО на обоих концах. При грамотном проектировании необходимо также учитывать границы сообщений, управление доступом к шине, повторные запросы и безопасность.
Что на самом деле делает прозрачный последовательный шлюз
В режиме прозрачной передачи необработанных данных шлюз пересылает байты полезной нагрузки последовательного интерфейса через TCP-соединение и записывает принятые байты полезной нагрузки TCP в свой последовательный порт. За команды устройства, контрольные суммы, разбор ответов и смысл команд по-прежнему отвечает приложение. Проверьте выбранный режим: виртуальный COM-порт или режимы управления последовательным портом могут добавлять собственное согласование параметров и требовать соответствующего ПО хоста.
Это полезная отправная точка для проприетарного двоичного протокола или существующего последовательного приложения, способного использовать поддерживаемый драйвер виртуального COM-порта. Уточните, зависит ли приложение от сигналов управления модемом, BREAK, точных временных интервалов или поведения локального драйвера последовательного порта. Шлюз, передающий обычные байты данных, может не воспроизводить эти функции.
Например, если прибор использует документированную команду с префиксом длины, хост может накапливать байты TCP до получения полного ответа на команду. Сопоставление регистров не требуется, но хосту всё равно нужен парсер протокола прибора.
Передача по TCP не сохраняет границы последовательных сообщений
TCP предоставляет надёжный упорядоченный поток байтов. За одно чтение получатель может получить часть прикладного сообщения или сразу несколько сообщений. Сегменты TCP и результаты чтения из сокета не являются прикладными записями. Это следует из транспортной модели в RFC 9293.
Иллюстративный пример: устройство отправляет два восьмибайтовых сообщения, A и B. Принимающее приложение может сначала прочитать первые пять байтов A, а затем оставшиеся три байта A вместе со всеми восемью байтами B. Такие границы чтения приведены лишь для примера и не являются прогнозом поведения сети. Парсер должен буферизовать неполные данные и извлекать целые сообщения по длине, разделителю или другим правилам выделения сообщений, заданным протоколом.
Временные параметры последовательной связи требуют отдельного рассмотрения. Modbus RTU использует паузы для разделения кадров и предъявляет требования к интервалам между символами; они определены в спецификации последовательной линии, раздел 2.5.1.1, включая рекомендацию по таймерам для более высоких скоростей в бодах. Стартовые биты, биты чётности и стоповые биты UART также не являются обычными байтами полезной нагрузки TCP.
Не предполагайте, что интервалы между поступлениями сетевых данных воспроизводят паузы последовательной линии. Шлюзу нужны подходящая буферизация и правила последовательной передачи. Одни только тайм-ауты формирования пакетов не доказывают, что кадр RTU останется целым на последовательном выходе. Проверяйте разбитые входные данные, задержанные байты и запросы, следующие непосредственно друг за другом.
Modbus RTU через туннель отличается от Modbus TCP
Запрос Modbus TCP использует семибайтовый заголовок MBAP и протокольную единицу данных (PDU). Modbus RTU использует последовательный адрес, PDU и CRC. Прозрачный туннель может передавать внутри TCP все байты RTU, включая CRC, однако стандартный клиент Modbus TCP ожидает формат MBAP.
Преобразующий шлюз разбирает MBAP, направляет Unit Identifier к настроенному последовательному адресату, формирует запрос RTU, проверяет CRC ответа и связывает ответ с исходной транзакцией TCP. Поле длины MBAP помогает разбирать сообщения, а идентификатор транзакции связывает запросы с ответами. См. руководство по реализации Modbus TCP/IP, разделы 3.1.2–3.1.3.
Подробный пример, придуманный для иллюстрации: прочитать два регистра хранения, начиная с передаваемого в протоколе адреса ноль, у последовательного устройства 7. Функция 03 и адресация с нуля в передаваемых сообщениях соответствуют спецификации прикладного протокола Modbus, разделы 4.4 и 6.3. Эти байты показывают кодирование, а не результаты испытаний продукта Obeita или карту регистров реального устройства.
- PDU запроса:
03 00 00 00 02. - Запрос Modbus TCP:
00 2A 00 00 00 06 07 03 00 00 00 02. Идентификатор транзакции —002A; длина0006учитывает Unit Identifier и пять байтов PDU. - Соответствующий запрос RTU:
07 03 00 00 00 02 C4 6D. Рассчитанная CRC передаётся младшим байтом вперёд.
В этом примере PDU не изменяется. Преобразование транспортного формата кадров не переводит автоматически проприетарный набор команд, не определяет коэффициенты масштабирования и не разрешает порядок данных, расположенных в нескольких регистрах. Для этого требуется явное сопоставление.
Определите управление последовательной шиной и политику повторов
Модель последовательной линии Modbus допускает одного ведущего, инициирующего обмен, и только одну транзакцию в каждый момент времени. Добавление клиентов Ethernet не увеличивает возможность одновременного обмена по последовательной линии. Если доступ нужен нескольким хостам, потребуйте документированный планировщик, ограничения очереди, обработку тайм-аутов и маршрутизацию ответов. Не подключайте к той же шине другого ведущего, выполняющего активный опрос, без специально спроектированной схемы арбитража.
Уточните, что происходит, когда истекает срок ожидания запроса в очереди, отключается клиент или приходит запоздалый последовательный ответ. Прозрачному серверу, принимающему несколько сокетов, нужны явные правила управления доступом; сама возможность принимать соединения не обеспечивает безопасную работу нескольких клиентов.
Сценарий отказа: устройство выполняет запись, но ответ теряется до его получения клиентом. Повторная попытка приложения может выполнить эту запись ещё раз. Повторная передача TCP внутри соединения отличается от отправки нового прикладного запроса. Идентификатор транзакции Modbus сам по себе не гарантирует постоянное подавление дубликатов.
Классифицируйте команды по их последствиям. Повторное присвоение уставки может быть допустимым, а повтор команды запуска цикла — нет. Для записей с существенными последствиями определите поддерживаемую устройством проверку последовательности, сверку состояния или восстановление оператором вместо безусловных повторов.
Определите границу безопасности развёртывания
Ни незащищённый TCP, ни обычный Modbus TCP сами по себе не предоставляют зашифрованный и аутентифицированный доступ к приложению. Уточните, что действительно поддерживают выбранные шлюз и клиент. Modbus Security определяет TLS и аутентификацию на основе сертификатов; поддержка требуется на обоих концах, а выдачу и обновление сертификатов необходимо запланировать.
В список проверок при развёртывании включите ограничение доступности шлюза разрешёнными системами, изоляцию сети управления, защиту административного доступа и исключение прямого доступа из общедоступного интернета. Одобренный VPN или шлюз безопасности может защищать сетевой путь, но оставшийся локальный сегмент и авторизацию на устройстве всё равно необходимо проверить. Шифрование не определяет, какой аутентифицированный клиент вправе выполнять запись.
Практический список проверок для выбора и приёмки
- Определите оба протокола. Зафиксируйте, что выдаёт устройство и что принимает хост: необработанные последовательные байты, RTU-over-TCP, Modbus TCP или другой документированный формат.
- Проверьте электрические предпосылки. Сверьте с требованиями установки выбор RS232 или RS485, двух- или четырёхпроводное подключение, назначение контактов, скорость в бодах, чётность, стоповые биты, заземление, изоляцию, оконечное согласование и смещение.
- Назначьте ответственного за формирование границ сообщений. Определите компонент, который собирает сообщения и соблюдает временные требования последовательной линии, включая максимальный размер кадра и поведение при некорректных входных данных.
- Задайте доступ и восстановление. Определите управление доступом к шине, поведение одновременных клиентов, разрешения на команды, тайм-ауты, ограничения очереди, обработку переподключений и безопасные повторы записи.
- Проверьте сложные случаи. На стенде протестируйте частичные и объединённые чтения TCP, отсутствующие устройства, запоздалые ответы, переподключения, насыщение очереди и отказ в доступе. Установите критерии успешного прохождения до начала испытаний.
Выбирайте прозрачную пересылку, когда протоколы уже совместимы и границы сообщений можно обрабатывать надёжно. Выбирайте преобразование, когда хосту нужен другой формат сообщений или явно заданная модель данных. Если одна из сторон не документирована, соберите подтверждающие данные, прежде чем окончательно выбирать архитектуру шлюза.
Подготовьте требования к шлюзу для Obeita
Для предметного технического обсуждения с Obeita подготовьте руководство устройства с удалёнными конфиденциальными сведениями, характерные кадры запросов и ответов, настройки последовательного интерфейса, протокол хоста, число устройств, временные требования и ожидаемое поведение при отказах. Удалите учётные данные, идентификаторы клиентов и конфиденциальные технологические данные. Эти материалы позволяют оценить необходимые работы по передаче, преобразованию и проверке.
Ознакомьтесь с услугой Obeita по подключению существующих устройств и сданным проектом адаптации последовательного интерфейса к Ethernet и сотовому DTU (на английском), чтобы узнать о похожих интеграционных работах. Для обсуждения протоколов вашего устройства и хоста свяжитесь с Obeita.
