1. Фон проекта и причины выбора Modbus TCP
Самой первой задачей, с которой я столкнулся при выполнении IoT проекта, было надежное сбор данных с различных устройств на месте.
На площадке были смешаны разнородные устройства от различных производителей, такие как PLC, сенсоры, контроллеры, которые использовали различные способы связи, и необходимо было в реальном времени собирать данные о состоянии каждого устройства и передавать их на верхнюю платформу.
На промышленных объектах используются различные промышленные протоколы, такие как OPC-UA и LS XGT. Я поделюсь опытом реализации драйвера связи IoT-угла на основе наиболее широко используемого протокола Modbus TCP.
Modbus является основным промышленным протоколом, который благодаря своей простой структуре используется на промышленных объектах на протяжении долгого времени. Особенно высока его применимость на местах, так как он поддерживается различным оборудованием независимо от производителя.
Существующий Modbus RTU работал на базе последовательного интерфейса, но Modbus TCP работает в среде Ethernet на базе TCP/IP, что дает преимущества в скорости и масштабируемости.
В проекте было необходимо собирать данные не в секундах, а в миллисекундах из десятков и более установок, поэтому эффективность сети и производительность обработки имели крайне важное значение.
Особенно в условиях edge-среды сеть может быть отключена в любое время, поэтому данные, собранные в оффлайн-состоянии сети, не должны теряться. Кроме того, учитывая особенности edge-среды, вычислительные ресурсы были ограничены, поэтому необходимо было также учитывать использование процессора и объем памяти. В результате, в проекте был разработан коммуникационный драйвер на основе следующих целей.
- Высокоскоростной сбор данных в миллисекундах
- Предотвращение потери данных в условиях разрыва сети
- Реализация структуры передачи данных в реальном времени
- Эффективное использование ограниченных ресурсов на краю
- Надежная поддержка записи для управления оборудованием
- Гибкая структура интеграции с верхним уровнем платформы
Этот проект заключался не просто в анализе пакетов Modbus, а в реализации архитектуры сбора данных, которая может надежно работать в реальных условиях промышленности.
2. Понимание протокола Modbus TCP
Перед тем как приступить к реализации, необходимо было сначала понять структуру протокола Modbus TCP.
Modbus, по сути, следует структуре Клиент-Сервер. Обычно мастер (Клиент) отправляет запрос (Request), а слейв (Сервер) возвращает ответ (Response).
Например, PLC или сенсорное оборудование выполняют роль ведомого, а IoT-шлюз или приложения для сбора данных выполняют роль главного устройства. В Modbus работает по принципу чтения или записи значений, хранящихся по определенному адресу.
В частности, использовались следующие коды функций.
- Чтение регистров хранения
- Чтение входных регистров
- Чтение катушки
- Запись в единственный регистр
- Множественная запись в регистр
В проекте использовались данные на основе регистров удержания и также использовалась функция записи для управления некоторыми устройствами. Modbus TCP является структурой, в которой к пакету Modbus RTU добавлен заголовок MBAP (Modbus Application Protocol).
В заголовке MBAP содержится следующая информация:
- Идентификатор транзакции
- Идентификатор протокола
- Длина
- Идентификатор устройства
Таким образом, нам удалось надежно различать несколько запросов даже в среде на основе TCP. Особенно, поскольку оно работает на основе TCP, скорость выше по сравнению с традиционным последовательным соединением, и гибкость сетевой конфигурации выше. В проекте было необходимо одновременно обрабатывать запросы для нескольких устройств, поэтому структура обработки TCP на основе асинхронности была очень важна.
Кроме того, некоторые устройства также испытывали задержки в ответах или теряли связь на определенное время, поэтому мы также учли обработку тайм-аутов и структуру повторных попыток.
В результате ключевой задачей стало проектирование надежной структуры связи, учитывающей не только простую реализацию протокола, но и ситуации сетевых сбоев.
3. Асинхронная архитектура сбора данных
Одним из самых важных требований проекта было очень быстрое собирание данных на уровне миллисекунд.
Если высшее приложение использует структуру, при которой оно отправляет запросы на чтение на устройство синхронно каждый раз, когда ему нужны данные, то из-за времени ожидания сетевого ввода-вывода было трудно достичь желаемой производительности.
В частности, время ответа полевых устройств было непредсказуемым, и мгновенные сетевые задержки происходили довольно часто.
Для решения этой проблемы архитектура сбора данных была спроектирована на основе асинхронного опроса.
Структура в основном состоит из следующих этапов.
1. Выполнение асинхронного опроса
2. Создание события (Event)
3. Передача MQTT Publisher
4. Публикация на верхнем уровне платформы
Сначала внутренний поток опроса постоянно отправлял асинхронные запросы на чтение к оборудованию Modbus с установленной периодичностью. Собранные данные не передавались сразу, а преобразовывались в объект события и передавались во внутреннюю очередь.
Позже была построена структура, в которой независимый MQTT Publisher потребляет очередь и публикует данные на MQTT Broker. Основным преимуществом такой структуры было полное разделение процессов чтения и публикации.
Даже если скорость публикации MQTT замедляется, поток опроса сам не подвергается влиянию, поэтому удалось стабильно поддерживать период сбора данных. Также удалось снизить связность между потоками, и была обеспечена независимая масштабируемость каждого этапа обработки.
Например, даже если в будущем структура публикации будет изменена на основанную на Kafka, структура опроса останется прежней. В реальной операционной среде необходимо было одновременно выполнять опрос по десяткам устройств, поэтому была применена структура на основе пула потоков, а также проводилась постоянная мониторинг использования CPU и памяти с параллельной оптимизацией.
4. Предотвращение потери данных и резервирование MQTT
В условиях IoT-края сети сбои в сети происходят довольно часто. Особенно в промышленных условиях качество сети может быть нестабильным, и из-за внешних помех соединение с MQTT Broker может внезапно прерываться.
В первоначальной реализации существовала возможность потери всех данных в очереди в случае разрыва соединения MQTT. Для решения этой проблемы была дополнительно спроектирована структура реагирования на сбои.
Во-первых, мы реализовали хранение данных в отдельной InfluxDB, чтобы данные не удалялись немедленно в случае неудачи публикации MQTT.
То есть, данные о сбоях в публикации в реальном времени были настроены для сохранения в временном хранилище, которое представляет собой временную базу данных.
После восстановления соединения MQTT данные, которые были сохранены, считываются и повторно отправляются. Эта структура позволила минимизировать потерю данных даже в условиях сетевых сбоев.
Для предотвращения смешивания старых данных и текущих данных в реальном времени, особенно после восстановления после сбоя, был использован отдельный MQTT Topic.
Например, данные в реальном времени публикуются в Topic .../REALTIME/... , а данные восстановления после сбоя публикуются в Topic .../OFFLINE/... .
Таким образом, на верхних платформах стало возможным четко различать характер данных, что не влияло на логику аналитики в реальном времени. В результате проект смог создать структуру, которая обеспечивала надежное сохранение данных не только при простой обработке в реальном времени, но и в ситуациях с сбоями.
5. Обработка записи на основе синхронизации и обеспечение надежности
В отличие от операций чтения, для функциональности записи, предназначенной для управления оборудованием, требовалась значительно более высокая степень надежности. Запросы на запись, изменяющие состояние оборудования, напрямую связаны с фактической работой устройств, в отличие от простого запроса данных.
Например, команды на запуск и остановку оборудования, управление клапанами и моторами могут привести к сбоям в производственном оборудовании или авариям, если они обрабатываются неверно. По этой причине функциональность записи была реализована в синхронном режиме, а не в асинхронном.
Когда возникает запрос на запись, он сразу выполняет запрос Modbus Write и ожидает результата, пока не получит нормальный ответ (ACK) от оборудования.
Причин, по которым была выбрана такая структура, было две.
Первое - это четкое обеспечение причинно-следственной связи.
Логика управления оборудованием, как правило, работает в виде последовательного управления. То есть, следующий этап управления мог выполняться только после успешного завершения предыдущей операции записи.
Если обрабатывать асинхронно, существует риск того, что следующая логика управления будет выполнена раньше, чем фактическое состояние оборудования изменится.
Второе – это немедленная обработка ошибок.
При сбое записи верхняя система должна была немедленно распознать ситуацию неисправности. В случае Modbus нормальный ответ на запрос записи всегда является значением Echo запрашиваемых данных. Поэтому даже если мы получали ответ, что запрос записи выполнен успешно, требовалось проверить, действительно ли значение было отражено. Для этого после ответа на запрос записи снова проверяли фактическое значение регистра, чтобы дополнительно подтвердить, что запрашиваемое значение было точно отражено. Эта структура позволила осуществлять более надежное управление оборудованием даже в реальных эксплуатационных условиях.
6. Заключение
Этот опыт реализации драйвера IoT на основе Modbus TCP имел значение, выходящее за рамки простого развития протокола.
Изначально казалось, что речь идет лишь о простом обмене пакетами Modbus, но в процессе работы над проектом я ощутил, что самое важное – это насколько надежно можно собирать и передавать данные в условиях ограниченной краевой среды.
Особенно важными были следующие элементы.
- Быстрая сборка данных на основе асинхронной технологии
- Структура реагирования на сетевые сбои
- Предотвращение потери данных
- Надежное управление оборудованием
- Оптимизация ограниченных ресурсов
- Баланс между обработкой в реальном времени и стабильностью
На реальных промышленных объектах качество сети всегда нестабильно, и скорость отклика оборудования также трудно предсказать. Поэтому гораздо важнее было, насколько стабильно система может работать в условиях сбоев, чем простая реализация функций.
В рамках этого проекта я получил опыт проектирования различных IoT-краевых систем, включая проектирование структуры опроса, обработку асинхронных событий, передачу данных на основе MQTT и архитектуру восстановления после сбоев.
В будущем я ожидаю, что подобная архитектура сможет быть расширена и применена в различных промышленных протоколах, таких как Modbus, а также OPC-UA, MQTT Sparkplug, BACnet.
Этот проект еще раз подтвердил, что в среде IoT важнее всего проектирование архитектуры с учетом условий на месте и надежности операций, чем просто технологический стек.
chnsik