Три способа передать данные IO-Link-мастера в SCADA или MES: через ПЛК, REST API и MQTT. Объясняем, чем они отличаются, что проверить в оборудовании и как испытать обмен.
Датчик подключён к IO-Link-мастеру, обмен работает. Теперь измерения и диагностику нужно показать оператору в SCADA, сохранить в MES или отправить на edge-сервер. Как провести данные дальше — через ПЛК, REST API с JSON или MQTT?
Выбор зависит от модели мастера или шлюза, прошивки и настроек. Спецификация JSON Integration помогает согласовать представление данных, но сама по себе не добавляет устройству REST API или MQTT. Сначала нужно проверить, какие интерфейсы действительно поддерживает оборудование.
О подключении датчика к мастеру подробнее рассказано в статье «Как устроен IO-Link».
Где заканчивается IO-Link и начинается обмен со SCADA или MES
IO-Link связывает датчик или исполнительное устройство с портом мастера. Дальше за передачу данных отвечает сам мастер, ПЛК или отдельный шлюз. Получателем может быть SCADA, MES, edge-приложение или сервис аналитики.
На практике используют два основных маршрута:
Датчик → IO-Link-мастер → ПЛК → SCADA / MES
Датчик → IO-Link-мастер или шлюз → REST API / MQTT → SCADA / MES / edge
Не каждый мастер поддерживает оба маршрута. Одни модели работают в основном с ПЛК по промышленной сети, другие имеют REST API или MQTT-клиент. Некоторые поддерживают сразу несколько вариантов. Поэтому канал управления оборудованием и канал сбора диагностики лучше рассматривать отдельно: им не обязательно совпадать.
Верхней системе мало получить набор байтов. Ей нужно понимать, какому прибору принадлежит измерение, в каких единицах оно передано, достоверно ли значение и когда оно обновилось. Формат и доступные поля зависят от реализации мастера или шлюза; SCADA и MES должны правильно их обработать.
Три способа передать данные IO-Link
Способ подключения выбирают под задачу: управление оборудованием, чтение по запросу или передача телеметрии и событий.
Через ПЛК и промышленную сеть
IO-Link-мастер отправляет данные контроллеру по поддерживаемой промышленной сети. В проекте ПЛК им назначают теги, а SCADA получает значения через принятый на предприятии интерфейс. Это привычная схема для объектов, где данные датчика уже участвуют в работе машины.
Плюс такого подхода — связанные между собой теги, состояния оборудования, аварийные сообщения и экраны оператора. Но проект ПЛК придётся настроить: описать карту данных мастера, типы значений, масштабирование, статусы связи и диагностику. Какие сети и какой объём данных доступны, зависит от моделей контроллера и мастера.
Маршрут через ПЛК особенно уместен для штатной работы машины и уже действующей системы автоматизации. При этом MES не получает доступ ко всем тегам автоматически: нужный интерфейс и права чтения задают отдельно.
Через REST API и JSON
Если мастер или шлюз поддерживает REST API, приложение может запросить у него доступный ресурс. Ответ нередко приходит в JSON — текстовом формате с именованными полями. Например, приложение может представить измерение так:
{
"value": 12.4,
"unit": "mm",
"status": "valid",
"timestamp": "2026-10-09T10:15:30Z"
}
Это условный пример, а не стандартный ответ любого IO-Link-мастера. Названия полей, URL, методы запросов, авторизацию и доступные операции нужно смотреть в документации конкретного устройства.
REST API подходит, если сервису нужно периодически считывать измерения, параметры или диагностические данные. До внедрения выясните, сколько запросов и соединений допускает устройство, что происходит при потере связи и как определить актуальность ответа. Подменять таким обменом канал, от которого зависит цикл управления машиной, без отдельной проверки не стоит.
Через MQTT и JSON
MQTT устроен иначе. Источник публикует сообщения в брокер, а SCADA, MES или другое приложение подписывается на нужные темы. Публиковать данные может мастер, шлюз либо edge-приложение — если оно умеет получать данные IO-Link и отправлять их по MQTT. Сам датчик обычно не подключается к брокеру напрямую.
Этот вариант удобен, когда одни и те же измерения или события нужны нескольким системам. Например, мастер отправляет состояние порта, а SCADA и сервис мониторинга получают сообщения через брокер. Такой интерфейс с JSON описан в руководстве SICK для Sensor Integration Gateway SIG350 [6]. Но это пример конкретного устройства, а не возможность, которая есть у любого IO-Link-мастера.
Темы MQTT, содержимое сообщений (payload), период публикации и разрешённые операции определяет реализация. Сам протокол не гарантирует фиксированную задержку или одинаковую доставку независимо от сети и настроек.
У сообщества IO-Link есть спецификация JSON Integration для представления данных и интеграции через REST API и MQTT [1]. Версию 2 опубликовали 9 июня 2026 года. В числе заявленных изменений — поддержка IO-Link Wireless, расширенные возможности MQTT, машиночитаемые описания OpenAPI и AsyncAPI [2]. Но применять эти функции можно только там, где производитель реализовал их и указал поддерживаемую версию.
REST API, MQTT или ПЛК: что выбрать
ПЛК обычно используют там, где данные участвуют в управлении машиной. REST API позволяет читать их по запросу. MQTT помогает отправлять телеметрию и события через брокер сразу нескольким получателям.
Эти способы можно сочетать. Например, ПЛК обслуживает управление и операторские экраны, а MQTT отправляет часть измерений в систему мониторинга. Главное — заранее определить, какие данные кому нужны и как быстро они должны обновляться.
|
Путь |
Как работает |
Когда подходит |
Что проверить |
|---|---|---|---|
|
Мастер → ПЛК → SCADA/MES |
ПЛК принимает данные по промышленной сети и предоставляет их через теги |
Управление машиной, действующая автоматизация |
Совместимость, карту данных, типы, масштабирование, частоту обновления |
|
REST API + JSON |
Приложение запрашивает ресурс у мастера или шлюза |
Чтение по запросу, сервисные приложения и скрипты |
API и его версию, структуру ответа, связь с IODD, доступ и лимиты |
|
MQTT + JSON |
Источник публикует сообщения в брокер; получатели подписываются на темы |
Телеметрия и события для SCADA, MES, edge и аналитики |
Поддержку MQTT, брокер, темы, payload, права, доставку и команды |
Если измерение влияет на работу оборудования, сначала проверьте предусмотренный проектом маршрут через ПЛК. Для чтения по запросу можно использовать REST API, если он есть у устройства. Для отправки событий и телеметрии нескольким системам подойдёт MQTT. Окончательное решение зависит от нужной частоты обновления, надёжности связи и удобства эксплуатации.
Как спроектировать интеграцию: чек-лист
Перед внедрением проверьте не только получение значений, но и их смысл, актуальность, права доступа и поведение системы при сбоях.
- Определите состав данных. Отдельно выпишите рабочие значения, идентификационные сведения, параметры и диагностические события. Для каждого поля укажите, куда оно пойдёт и зачем нужно.
- Проверьте оборудование по всей цепочке. Уточните модель датчика, режим порта, модель и прошивку мастера, доступные интерфейсы, ограничения ПЛК или шлюза. Документация должна соответствовать установленному артикулу.
- Выберите канал под каждую задачу. Не переводите теги с ПЛК на REST или MQTT только ради нового интерфейса. Разделите управление машиной, диагностику и аналитику.
- Разберите структуру данных. При необходимости используйте IODD. Проверьте типы значений, порядок байтов, масштабирование, единицы измерения, допустимые диапазоны и специальные коды.
- Согласуйте формат обмена. Для ПЛК подготовьте список тегов; для REST — ресурсы и ответы; для MQTT — темы, payload и условия публикации. Укажите версию схемы и ответственного за её изменения.
- Передавайте признаки достоверности и актуальности. Вместе с измерением нужен статус качества, время обновления либо другой показатель свежести. При потере связи старое значение нельзя выдавать за актуальное, особенно если оно похоже на нормальный ноль.
- Ограничьте доступ. Настройте сетевые маршруты, учётные записи и разрешённые действия. Для MQTT разграничьте публикацию и подписку на брокере; для API используйте поддерживаемую авторизацию. Не открывайте интерфейс мастера напрямую в интернет.
- Проверьте сбои и восстановление. Отключите кабель, прервите связь с мастером, перезапустите брокер или сервис, проверьте недоступность ПЛК. Убедитесь, что SCADA или MES показывает недостоверность данных и корректно возвращается к обмену.
После испытаний должны остаться карта данных и понятный сценарий отказа: кто замечает проблему, что видит оператор и как восстанавливается связь. Один успешный запрос, который вернул JSON, ещё не подтверждает готовность интеграции.
Частые ошибки при передаче данных
- Считать, что JSON Integration автоматически даёт устройству REST API или MQTT. Возможности зависят от прошивки, интерфейсов и настроек конкретной модели.
- Принимать сырые байты за готовое измерение. Без разбора структуры, масштаба и статуса можно получить правдоподобное, но неверное число.
- Не проверять IODD и ограничения реализации. В документации Balluff BNI XG, например, указано, что часть функций стандартного REST API зависит от IODD, а некоторые операции реализованы не полностью [4]. Это особенность конкретной линейки — проверять нужно свой артикул.
- Показывать последнее полученное значение как текущее. После разрыва связи система должна отмечать его как устаревшее или недостоверное.
- Отправлять в верхнюю систему все поля подряд. Избыточные параметры усложняют модель данных и поддержку. Сначала согласуйте необходимый набор.
- Заменять предусмотренный канал управления на API или MQTT без испытаний. Если важны строго заданные сроки реакции, их нужно подтвердить для всей системы, а не делать вывод по названию протокола.
- Оставлять управляющие команды без ограничений. Если устройство принимает через MQTT команды на выходы или изменение параметров, доступ к публикации нужно ограничить и отдельно проверить.
Какой способ выбрать в итоге
Для данных, которые используются в штатной работе машины, чаще рассматривают маршрут через ПЛК. REST API удобен для чтения по запросу, если устройство поддерживает нужные ресурсы и авторизацию. MQTT пригодится для отправки событий и телеметрии через брокер. На одном объекте все эти способы могут работать вместе.
Перед внедрением сверьте прошивку и интерфейсы, требования к IODD, формат сообщений и реакцию на потерю связи. Если подбираете IO-Link-датчик или мастер для действующей системы, сообщите специалисту модель ПЛК и SCADA, перечень нужных данных и условия подключения. Так будет проще проверить совместимость.
Источники
1. IO-Link Community: интеграция и спецификация JSON Integration
2. PROFIBUS & PROFINET International: выпуск JSON Integration Version 2, 9 июня 2026 года
3. IO-Link Community: каталог официальных спецификаций и материалов по Integration
4. Balluff BNI XG: REST API, MQTT, IODD-зависимости и ограничения отдельных функций
5. Balluff BNI XG: поддерживаемые интерфейсы по вариантам изделия
6. SICK Support: пример обмена данными IO-Link через JSON REST и MQTT
