На машиностроительном заводе с цехом в несколько десятков единиц оборудования загрузка станков всю жизнь считалась «на глаз» — сменный мастер периодически обходил цех и делал отметки в бумажном журнале. Но сколько именно часов конкретный токарный станок фактически резал металл, а сколько просто стоял включенным вхолостую — без цифрового инструмента понять это было невозможно. В этой статье я разберу конкретное решение на базе беспроводной 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 в данном проекте выигрывает за счет трех свойств:

1. Mesh-топология (ячеистая сеть) — каждый сетевой узел (router-role) ретранслирует трафик соседей. Добавляешь новый датчик — он автоматически усиливает покрытие для других.

2. Низкое энергопотребление протокола — в данном случае это неважно (питание от стационарной электросети), зато важна предсказуемость задержек.

3. Зрелая экосистема — Zigbee2MQTT поддерживает несколько сотен устройств, документация обширна, сообщество активно.

Диапазон 2.4 ГГц у Zigbee тот же, что у Wi-Fi, но меньшая мощность передатчика и mesh компенсируют возможные провалы покрытия. На практике в цехе площадью ~2000 м² сеть из 15–20 устройств работает без ретрансляторов — но при необходимости любой маршрутизирующий узел Zigbee (router, не end device) автоматически становится ретранслятором.

Программный стек: от MQTT до Grafana

Принципиальное архитектурное решение — никакого проприетарного ПО, только open source. Весь стек живет в Docker-контейнерах на локальном сервере (или Edge-компьютере в цеху).

Вот по какому пути идет сбор данных:

Станок → 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 - статус подключения, качество радиосигнала, время последнего обновления: Ниже — примеры экранов.

Итоговая архитектура

Все компоненты, кроме прошивки самого устройства, имеют открытый исходный код. Данные хранятся локально. Нет облачной зависимости, нет абонентской платы за доступ к своим же данным.

Что получил завод

После запуска системы на заводе, первые выводы появились уже через несколько дней работы.

1. Три станка из двенадцати не выключались по окончании смены. На графике тока это выгляделокак ненулевой базовый ток (холостой ход двигателя) в период, когда шпиндель не нагружен. Операторы - лентяи, просто не выключали оборудование. Сумма по двенадцати часам в сутки и по трем станкам дает ощутимую цифру в киловатт-часах.

2. Реальная загрузка отличалась от плановой. После недели наблюдений стала видна структура смены: первые три часа — пиковая загрузка, потом просадка. Это позволило скорректировать подачу заготовок и распределение операторов, фактическое машинное время выросло без изменения состава оборудования.

3. Система предупредила об аварии. На одном из токарных станков начал аномально расти ток при неизменной нагрузке — 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 проекты.
Если нужны подробности и ссылки, пишите в личку.