Наиль Муратов, АО «Систэм Электрик»
Большинство полевых устройств с поддержкой передачи данных используют протокол Modbus RTU по шине RS-485. К таким устройствам относятся умные датчики, комнатные контроллеры, контроллеры локальной автоматизации. Когда возникает вопрос о подключении этих устройств к системе автоматизации и диспетчеризации, которая работает в TCP сети, то самым очевидным решением становится применение шлюза Modbus TCP/RTU. Рассмотрим, как работает такой шлюз.
Подключение устройств Modbus RTU Slave через шлюз Modbus TCP/RTU
Шлюз соединяет сети TCP и RTU и выполняет ключевую работу по преобразованию протоколов.
Клиенты в TCP сети, такие как система диспетчеризации, панели ЧМИ, контроллеры формируют запросы к Modbus RTU устройствам и отправляют их на шлюз.
Процесс обработки входящего запроса TCP состоит из нескольких последовательных этапов:
1. Прием и обработка запроса Modbus TCP
Шлюз, как сетевое устройство, принимает TCP-пакет и извлекает из него информацию, какие данные надо запросить на ведомом устройстве, затем формирует RTU-кадр для передачи на ведомое устройство.
- Unit ID из MBAP-заголовка становится Адресом Устройства (Slave Address) в сети Modbus RTU, который добавляется в начало RTU-кадра.
- К RTU-кадру добавляется контрольная сумма CRC.
2. Запрос к устройству Modbus RTU Slave
Шлюз отправляет готовый RTU-кадр через свой последовательный порт (RS-485/RS-232) в шину Modbus RTU. Отправка происходит после того, как будут выполнены имеющиеся в очереди запросы, так как шина является последовательной, и запросы выполняются поочередно.
3. Ответ от Устройства (Modbus RTU Slave)
Ведомое устройство в сети RTU (например, частотный преобразователь или датчик) постоянно прослушивает шину, и если адрес в RTU-кадре совпадает с его собственным (или является широковещательным 0), то устройство обрабатывает запрос и выполняет запрошенное действие (чтение регистров, запись в катушки и т.д.).
После выполнения запроса ведомое устройство формирует ответный RTU-кадр, который содержит данные ответа (значения регистров, статус записи и т.д.) и контрольную сумму CRC, и отправляет этот кадр обратно в шину.
4. Ответ от шлюза
Шлюз, получив RTU-кадр от устройства, проверяет контрольную сумму и извлекает PDU из RTU-кадра.
На основе полученных данных шлюз создает Modbus TCP-кадр, который содержит данные из полученного RTU-кадра и ID транзакции из исходного запросе TCP-запроса, чтобы клиент мог сопоставить запрос и ответ.
Шлюз отправляет готовый TCP-пакет обратно клиенту по IP-сети, и клиент по ID транзакции находит исходный запрос и обрабатывает принятые данные.
Ключевые особенности работы шлюза
Поскольку запрос клиента передается на ведомое устройство Modbus RTU, то производительность опроса со стороны Modbus TCP определяется пропускной способностью шины Modbus RTU, которая на практике обычно составляет 4 800 – 19 200 бод.
Если запросы по Modbus TCP поступают быстрее, чем происходит их обработка по Modbus RTU, то шлюз будет ставить входящие запросы в очередь. В результате, скорость опроса на стороне Modbus TCP уменьшается.
При этом, клиенты (SCADA-системы или контроллеры) имеют настройки тайм-аутов. Если запрос находится в очереди шлюза слишком долго, и клиентский тайм-аут истекает, клиент может посчитать запрос неудачным и повторно отправить его, что только усугубит ситуацию, так как в очередь добавляются новые дублирующиеся запросы.
Увеличение числа TCP-клиентов приводит к дальнейшему снижению скорости опроса RTU-устройств из-за накладных расходов на управление очередью.
Длинные очереди создают также проблемы в управлении – запросы на запись значений в устройства Modbus RTU Slave встают в ту же очередь и выполняются с задержкой, а в случае переполнения очереди могут быть потеряны.
Некоторые модели шлюзов предлагают дополнительные функции по оптимизации производительности, такие как кэширование данных (например, часто запрашиваемых регистров) или приоритетная отправка запросов на запись значений, которые могут смягчить проблему производительности.
Но эти меры не решают проблему полностью. Например, кэширование увеличивает скорость опроса в Modbus TCP, но замедляет обновление реальных данных с устройств Modbus RTU.
Подключение через контроллер
Если применить контроллер автоматизации вместо шлюза Modbus TCP/RTU, то несмотря на внешнее сходство этих схем, взаимодействие устройств в системе происходит по-другому.
Ниже это показано на примере контроллера SystemeHD в роли связующего компонента и комнатных термостатов SystemeRT в качестве устройств Modbus RTU Slave.
1. Контроллер постоянно опрашивает подключенные ведомые устройства Modbus RTU Slave и сохраняет полученные значения в оперативной памяти.
2. Когда контроллер получает запрос от Modbus TCP Client на чтение значения из устройства Modbus RTU Slave, он моментально передает клиенту значение регистра, сохраненное в оперативной памяти.
3. Когда контроллер получает запрос от Modbus TCP Client на запись значения в устройство Modbus RTU Slave, он формирует RTU кадр и отправляет его на ведомое устройство.
Другими словами, контроллер кэширует в оперативной памяти все значения, считанные из устройств Modbus RTU Slave, поэтому запросы на чтение обрабатываются гораздо быстрее: контроллер получает запрос на чтение регистра и отправляет клиенту значение, уже находящееся в оперативной памяти.
Устройствам Modbus RTU Slave передаются только запросы на запись, которые обычно поступают намного реже.
Ключевые особенности работы контроллера
За счет того, что в контроллере опрос ведомых устройств и обработка клиентских запросов работают независимо, такая схема позволяет добиться минимального периода обновления данных и увеличивать число клиентских устройств, не ухудшая скорость опроса.
Кроме того, клиентские запросы на чтение данных выполняются без формирования очереди к последовательному интерфейсу, поэтому выполнение команд записи будет происходить быстрее.
Для контроллера потребуется создать создавать программный проект для опроса ведомых устройств Modbus RTU и сохранения значений в виде опубликованных регистров.
В этой схеме могут быть применены и другие программируемые контроллеры автоматизации: SystemePLC SR / S172 / S250.
Сравнение
Рассмотрим сравнение по параметрам:
Заключение
При подключении устройств Modbus RTU к общей системе автоматизации и диспетчеризации возможны два варианта: на основе непрограммируемого шлюза Modbus TCP/RTU и на основе программируемого контроллера с поддержкой протоколов Modbus TCP/RTU.
Такое устройство, как шлюз Modbus TCP/RTU, будет оптимально для задач, в которых:
- интенсивность опроса со стороны Modbus TCP невелика и находится в пределах пропускной способности шины Modbus RTU;
- количество клиентов Modbus TCP небольшое (1-2) и не ожидается их добавление в процессе эксплуатации системы.
При проектировании и внедрении такой системы критически важно учитывать общую нагрузку на сеть и настраивать тайм-ауты. Желательно выбирать модели шлюзов, имеющие программные функции для оптимизации производительности.
Программируемый контроллер является лучшим вариантом по производительности и стабильности на протяжении всего жизненного цикла для нагруженных и масштабируемых проектов, в которых
- происходит постоянный опрос со стороны клиентов Modbus TCP, и интенсивность опроса превышает пропускную способность шины Modbus RTU;
- в процессе эксплуатации системы возможно добавление дополнительных клиентских устройств Modbus RTU к системе;
- большое количество клиентов Modbus TCP или возможно их подключение в процессе эксплуатации системы.
Обращаем ваше внимание, что у нас есть статья, в которой мы простым языком рассказываем про Modbus RTU, RS-485, Ethernet, TCP/IP и средства связи (шлюзы и контроллеры - что, для чего и когда использовать).
Подписывайтесь на наши каналы «Systeme Electric: Автоматизация» в Telegram и MAX, чтобы быть в курсе всех новостей Автоматизации!