На машиностроительном заводе с цехом в несколько десятков единиц оборудования загрузка станков всю жизнь считалась «на глаз» — сменный мастер периодически обходил цех и делал отметки в бумажном журнале. Но сколько именно часов конкретный токарный станок фактически резал металл, а сколько просто стоял включенным вхолостую — без цифрового инструмента понять это было невозможно. В этой статье я разберу конкретное решение на базе беспроводной Zigbee-сети. Простой и дешевый мониторинг вместо кабелей и полностью открытый программный стек.
Классическое возражение производственников: «у нас помехи для Wi-Fi, придется тянуть слаботочку, возможно, что даже останавливать оборудование, вызывать электриков для запитки роутеров». Все это — затраты времени и денег еще до того, как система хоть что-то измерила. Плюс типичный сценарий с проприетарной SCADA: покупаешь железо у одного вендора, ПО у другого, потом обнаруживаешь, что они работают только вместе, а подписка на обновление стоит как первоначальная интеграция.
Железо: Industrial PC модели FCU3308PZ и токовые датчики
На каждый станок ставится FCU3308PZ — небольшой индустриальный компьютер под управлением NapiLinux (Buildroot-based дистрибутив), в корпусе на DIN-рейку. Внутри — встроенный датчик тока с трансформатором тока (CT — current transformer), который накидывается на питающий кабель станка без разрыва цепи. Монтаж занимает 5–10 минут на одну точку.
Что измеряет каждый узел:
- ток 0–100 А через токовый трансформатор
- активную мощность (Вт)
- напряжение (В)
- частоту питающей сети (Гц)
- накопленное потребление (кВт·ч)
Частота опроса — 1 Гц (раз в секунду). Для задачи определения «работает станок или нет» этого более чем достаточно. Сам порог по току «вкл или выкл» выставляется по станку однократно при настройке и дальше не требует внимания.
Питание устройства — от сети 220 В через встроенный источник питания. Кабель данных отсутствует полностью.
Внутри устройства Modbus RTU связывает вычислительный модуль с датчиком. Пакет modlink опрашивает Modbus-регистры по расписанию и транслирует значения в Zigbee-передатчик через последовательный интерфейс. Прошивка Zigbee-модуля — PTVO (ptvo.info), она превращает произвольные числовые данные в стандартные Zigbee-кластеры (ZCL), которые понимает любой Zigbee2MQTT-координатор.
Мы рассматривали еще Wi-Fi и LoRa, но выбрали Zigbee
У всех, кто прочтет статью, одним из первых будет вопрос по выбору технологии связи. Коротко по альтернативам:
Wi-Fi 6 — очевидный первый кандидат. Проблема в том, что промышленный цех — это металлические корпуса станков, экранирующие переборки, частые переотражения сигнала. Сеть 2.4 ГГц и даже 5 ГГц в таких условиях деградирует и работает предсказуемо плохо. Плюс Wi-Fi требует управления IP-адресами, аутентификации по SSID/PSK, нагрузки на корпоративную сеть. Для 30–50 датчиков это управляемо, но уже м.б. не тривиально в будущем поддерживать для заводского админа с грубыми замасленными руками.
Плюс есть и такая проблема: назовем ее «Внезапные указания регионального МЧС по отключению как мобильной связи в данной локации, так и Wi-Fi на производственных объектах».
Длиться это может многие часы, пока не придет команда «отбой». А если брать промышленный Wi-Fi в целом по отраслевым заводам, его не везде вообще разрешает запускать местная служба безопасности.
LoRa/LoRaWAN — как физический канал 868 МГц подходит для датчиков с редкими передачами (раз в минуту или реже) и большими расстояниями. Частота 1 Гц при десятках устройств начинает конкурировать за эфир, а потенциальная многокилометровая дальность — избыточна для размеров одного цеха.
Zigbee — беспроводной протокол связи, разработанный для создания энергоэффективных сетей с низкой скоростью передачи данных. Он широко используется в устройствах Интернета вещей (IoT) и системах «Умный дом» (датчики, розетки, лампы) благодаря высокой надежности и минимальному расходу энергии. Работает очень медленно, но бьет далеко.
Zigbee в данном проекте выигрывает за счет трех свойств:
- Mesh-топология (ячеистая сеть) — каждый сетевой узел (router-role) ретранслирует трафик соседей. Добавляешь новый датчик — он автоматически усиливает покрытие для других.
- Низкое энергопотребление протокола — в данном случае это неважно (питание от стационарной электросети), зато важна предсказуемость задержек.
- Зрелая экосистема — Zigbee2MQTT поддерживает несколько сотен устройств, документация обширна, сообщество активно.
Диапазон 2.4 ГГц у Zigbee тот же, что у Wi-Fi, но меньшая мощность передатчика и mesh компенсируют возможные провалы покрытия. На практике в цехе площадью ~2000 м² сеть из 15–20 устройств работает без ретрансляторов — но при необходимости любой маршрутизирующий узел Zigbee (router, не end device) автоматически становится ретранслятором.
Программный стек: от MQTT до Grafana
Принципиальное архитектурное решение — никакого проприетарного ПО, только open source. Весь стек живет в Docker-контейнерах на локальном сервере (или Edge-компьютере в цеху).
|
Слой |
Компонент |
Назначение |
|
Датчик |
NapiLinux + modlink |
ОС датчика; пакет modlink опрашивает Modbus-регистры и транслирует данные в Zigbee-передатчик |
|
Zigbee-сеть |
PTVO firmware |
Прошивка Zigbee-модуля; превращает произвольные данные в стандартные Zigbee-кластеры |
|
Координатор |
Zigbee2MQTT + Mosquitto |
Napi-C (RK3308) собирает все Zigbee-устройства и публикует данные в MQTT-брокер |
|
Транспорт |
Telegraf |
Читает MQTT-топики и пишет временные ряды в InfluxDB |
|
База данных |
InfluxDB 2.x |
Хранение временных рядов с минутным разрешением по каждому станку; всё локально |
|
Визуализация |
Grafana |
Дашборды, исторические графики, алерты; весь стек в Docker на локальном сервере |
Вот по какому пути идет сбор данных:
Станок → FCU3308PZ → Zigbee mesh → Napi-C координатор → Zigbee2MQTT → Mosquitto → Telegraf → InfluxDB → Grafana
Каждый FCU3308PZ опрашивает встроенный датчик по Modbus и через пакет modlink транслирует данные в Zigbee-передатчик.
— Координатор на базе Napi-C (RK3308) принимает данные от всех датчиков через Zigbee2MQTT и публикует их в MQTT-брокер Mosquitto.
— Telegraf подписывается на нужные топики и пишет данные в InfluxDB.
— Grafana строит дашборды и отправляет алерты.
А теперь разберем каждый слой.
Zigbee2MQTT + Mosquitto
Zigbee2MQTT — open source мост между Zigbee-сетью и MQTT-брокером. Координатор (в данном случае Napi-C на базе RK3308) подключается по USB или UART, Zigbee2MQTT принимает данные от всех устройств и публикует их в топики такого вида:
zigbee2mqtt/станок-01/current → 12.4
zigbee2mqtt/станок-01/power → 2720
zigbee2mqtt/станок-01/voltage → 220.1
zigbee2mqtt/станок-01/energy → 1847.3
Каждое устройство видно в веб-интерфейсе Zigbee2MQTT: статус подключения, LQI (Link Quality Indicator — качество радиосигнала 0–255), время последнего обновления. Это важно для диагностики: если датчик перестал присылать данные, причину видно сразу.
Mosquitto — легковесный MQTT-брокер. Никакой конфигурации, кроме базовой: порт 1883, опционально TLS и аутентификация для внутренней сети.
Telegraf
Telegraf подписывается на MQTT-топики через плагин inputs.mqtt_consumer и пишет данные в InfluxDB. Конфигурация минимальна:
[[inputs.mqtt_consumer]]
servers = [«tcp://localhost:1883»]
topics = [«zigbee2mqtt/+/#»]
data_format = «json»
[[outputs.influxdb_v2]]
urls = [«http://localhost:8086»]
token = «$INFLUX_TOKEN»
organization = «factory»
bucket = «machines»
Telegraf хранит данные с меткой времени из момента приема, добавляет теги из топика (имя станка), и передает в хранилище. Если InfluxDB временно недоступен, Telegraf буферизует данные в памяти и отправляет при восстановлении.
InfluxDB 2.x
Временные ряды — именно здесь структура данных, которая нужна для мониторинга оборудования. InfluxDB хранит измерения с меткой времени, поддерживает политики хранения (retention policies — автоматическое удаление старых данных) и агрегации через Flux-запросы.
Пример Flux-запроса для вычисления машинного времени за смену (порог тока 5 А = станок работает):
from(bucket: «machines»)
|> range(start: -8h)
|> filter(fn: (r) => r._measurement == «mqtt_consumer» and r._field == «current»)
|> filter(fn: (r) => r.topic =~ /станок-01/)
|> map(fn: (r) => ({ r with value: if r.value > 5.0 then 1.0 else 0.0 }))
|> aggregateWindow(every: 1m, fn: mean)
|> sum()
Результат — количество минут за последние 8 часов, когда ток превышал заданный порог. Умножаем на 1/60 — получаем машино-часы.
Grafana
На выходе — дашборды с реальным временем и историей. Типовые панели для производственного мониторинга:
- Stat-панель — текущий статус каждого станка (работает / простой / выключен) с цветовой индикацией.
- Time series — график тока или мощности за смену; наглядно видно пики нагрузки, паузы, переходные процессы.
- Bar gauge — загрузка в процентах за смену по всем станкам.
- Heatmap — тепловая карта по дням и часам: когда оборудование загружено, а когда нет.
Алерты в Grafana настраиваются через Alerting → Alert rules. Условие типа «ток на станке X вырос более чем на 20% от среднего за последние 30 минут» — это несколько кликов в интерфейсе. Уведомление уходит в Telegram, Email или любой webhook.
Все датчики цеха видны в едином интерфейсе Zigbee2MQTT — статус подключения, качество радиосигнала, время последнего обновления: Ниже — примеры экранов.
Итоговая архитектура
|
Слой |
Компонент |
Лицензия |
|
Датчик |
NapiLinux + modlink |
GPL / проприетарная прошивка устройства |
|
Zigbee firmware |
PTVO |
Freeware |
|
Координатор |
Zigbee2MQTT |
GPL-3.0 |
|
Брокер |
Mosquitto |
EPL-2.0 |
|
Транспорт |
Telegraf |
MIT |
|
БД |
InfluxDB 2.x |
MIT (core) |
|
Визуализация |
Grafana |
AGPL-3.0 |
Все компоненты, кроме прошивки самого устройства, имеют открытый исходный код. Данные хранятся локально. Нет облачной зависимости, нет абонентской платы за доступ к своим же данным.
Что получил завод
После запуска системы на заводе, первые выводы появились уже через несколько дней работы.
- Три станка из двенадцати не выключались по окончании смены. На графике тока это выгляделокак ненулевой базовый ток (холостой ход двигателя) в период, когда шпиндель не нагружен. Операторы — лентяи, просто не выключали оборудование. Сумма по двенадцати часам в сутки и по трем станкам дает ощутимую цифру в киловатт-часах.
- Реальная загрузка отличалась от плановой. После недели наблюдений стала видна структура смены: первые три часа — пиковая загрузка, потом просадка. Это позволило скорректировать подачу заготовок и распределение операторов, фактическое машинное время выросло без изменения состава оборудования.
- Система предупредила об аварии. На одном из токарных станков начал аномально расти ток при неизменной нагрузке — Grafana подняла алерт по правилу отклонения от скользящего среднего. Механики проверили привод и обнаружили изношенный подшипник. Плановая замена заняла два часа. Внеплановый аварийный простой занял бы значительно больше.
Про масштабирование и расширение
Zigbee-сеть в mesh-режиме масштабируется добавлением узлов: новый датчик автоматически встраивается в топологию. Конфигурация Zigbee2MQTT обновляется на лету без перезапуска системы.
FCU3308PZ имеет интерфейс Modbus RTU/TCP, к которому подключаются любые датчики со стандартным Modbus-протоколом: датчики давления, температуры подшипников, вибрации, расхода охлаждающей жидкости. Все они попадают в ту же шину данных и тот же InfluxDB.
Если нужна интеграция с ERP или MES — MQTT-топики доступны любому сервису в сети. Node-RED, Python-скрипт, самописный микросервис — подключить к Mosquitto проще, чем к большинству промышленных шин.
С чем столкнулись и что учесть при внедрении
Радиопомехи. Промышленный цех — это источники ЭМИ: частотные преобразователи, сварочное оборудование, крупные электродвигатели. Zigbee работает на 2.4 ГГц и будет страдать от промышленных помех. На практике металлический корпус FCU3308PZ дает некоторое экранирование, а mesh компенсирует единичные потери пакетов. Если LQI конкретного устройства стабильно ниже 100 — стоит добавить промежуточный маршрутизирующий узел.
Синхронизация времени. InfluxDB критичен к точности временных меток. NTP на координаторе и на сервере — обязательно. Расхождение часов между узлами приводит к некорректным временным рядам.
Порог срабатывания. Ток холостого хода у разных станков сильно отличается. Фрезерный обрабатывающий центр с ЧПУ потребляет на холостом ходу несколько ампер. Порог «работает / не работает» нужно калибровать под каждый тип оборудования отдельно — это разовая настройка при вводе в эксплуатацию.
Хранение данных. При частоте сбора данных 1 Гц на 20 датчиках получается 20 точек в секунду, 1.7 млн точек в сутки. InfluxDB справляется с такой нагрузкой на обычном сервере, но retention policy стоит настроить: raw-данные с секундным разрешением можно хранить неделю, агрегированные поминутные — год, агрегированные почасовые — без ограничений.
Выводы: почему это будет работать и у других
Система мониторинга загрузки оборудования на базе Zigbee + open source стека решает три задачи одновременно: разворачивается без кабельных работ, не привязывает к конкретному вендору и стоимость проекта принципиально меньше проприетарных SCADA-решений с аналогичной функциональностью. При этом данные остаются на предприятии, стек поддерживается любым заводским инженером, знакомым с Linux и Docker.
Mesh-топология Zigbee — ключевое свойство для производственного применения: сеть деградирует gracefully, потеря одного узла не обрывает остальных. А открытый протокол MQTT на выходе координатора позволяет подключать любые downstream-системы без доработки нижнего уровня.
Сухой остаток:
- Vendor-unlock с первого дня. Linux, Zigbee2MQTT, Mosquitto, Telegraf, InfluxDB, Grafana — проекты с открытым исходным кодом. Вы не зависите от нашей лицензии, нашего сервера или нашего будущего. Данные ваши, стек ваш.
- Расширяется под любую задачу. FCU3308PZ передаёт не только данные встроенного датчика тока — через Modbus RTU/TCP к нему подключаются любые датчики: давление, температура, вибрация, расход. Zigbee-сеть объединяет их всех.
- Все локально — нет облака. Данные хранятся на корпоративном сервере (или на Edge-сервере в цеху). Никаких подписок, никаких рисков при отключении интернета. Полный контроль над данными производства.
- Масштабируется без переделки. Добавить новый станок — поставить ещё один FCU3308PZ и подключить к той же Zigbee-сети. Конфигурация Zigbee2MQTT обновляется без остановки системы.
Справка: FCU3308PZ производится в России. PTVO — прошивка для Zigbee-устройств. Остальные компоненты стека — стандартные open source проекты.
Источник: https://habr.com/ru/articles/1049712/