MachineSignals

MachineSignals начинался как ICS, внутренний проект промышленных систем управления, до ребрендинга. Железо в нём настоящее: узлы-датчики на Arduino Uno общаются через mesh-сеть nRF24L01 (RF24Network/RF24Mesh), у каждого узла свой аппаратный ID на чипе DS2401, датчик DHT11 меряет температуру и влажность, до трёх аналоговых датчиков давления и прерывание считает импульсы оптического счётчика производства. Шлюз на ESP32 (TinyGSM плюс PubSubClient) связывает mesh-сеть с MQTT и публикует в те же топики v1/telemetry, на которые подписан hardware-listener бэкенда.

За шлюзом два сервиса на NestJS делят одну базу MySQL и один брокер Mosquitto: HTTP API и воркер, читающий поток MQTT. Третий сервис отвечает только за временные ряды: держит собственные буферы в памяти и отдаёт их дашборду на Vue/Vuetify через WebSocket, поэтому графики датчиков обновляются вживую без опроса.

Главная цифра на дашборде — OEE: доступность умножить на эффективность умножить на качество, посчитанная напрямую по сырому потоку оптических датчиков, температуры, влажности, давления и тока, без синтетической подгонки.

Когда мы подняли стенд, вскрылись два настоящих бага, не подстроенных для демонстрации. Гонка при регистрации шлюза позволяла двум узлам с одинаковым серийным номером конфликтовать друг с другом. На любом узле с несколькими оптическими датчиками расчёт OEE брал GUID первого датчика из списка вместо того, который реально измерялся: один узел с пятью оптическими датчиками показывал эффективность 19 102% до исправления. Оба бага исправлены и стенд работает с фиксом.

OEE сообщает о поломке машины постфактум. Мы двигаемся к тому, чтобы ловить её заранее: таблица журнала обслуживания теперь фиксирует каждое плановое и внеплановое событие по узлу. Это размеченные данные, без которых не построить модель обнаружения аномалий, и их нельзя добавить задним числом в готовую IIoT-платформу. Следующий шаг — датчики вибрации.