Данные с оборудования разных лет: простои, выпуск и причины остановок
Простой на экране совпадает с фактом на линии, а причину называет оператор, а не догадка системы
Проверяется: сверка простоев с журналом смены
ПромышленностьРаботаем по NDA
На участке работают станки и линии, купленные в разные годы. Новые отдают сигналы по стандартным протоколам, старые вообще не отдают. Простои оператор записывает в журнал в конце смены. Руководитель хочет видеть выпуск, простои и причины в течение смены и сравнивать смены между собой.
Что съедает срок и бюджет на самом деле
Самая сложная часть здесь не панель, а доверие к цифрам. Ниже, что обычно мешает.
У старых станков нет выхода данных
приходится ставить внешние датчики тока, счётчики или считыватели. Каждое такое решение даёт приближение, и его нужно проверять.
Сигнал и событие это разные вещи
станок включён, но не работает, или работает вхолостую. Из сырых сигналов состояние получается правилами, и правила согласуют с технологом.
Причину простоя знает только человек
система видит остановку, а причину выбирает оператор. Если выбор долог, поле забивают значением «прочее».
Цифры спорят с журналом смены
пока расхождение не объяснено, руководитель не доверяет экрану и ведёт параллельный учёт.
Ограничение, которое определяет решение
Сеть оборудования обычно закрыта от общей сети предприятия, и данные выходят наружу только через шлюз с односторонней передачей. Система съёма собирается так, чтобы не влиять на работу оборудования: мы только читаем сигналы и не управляем станками. Мы не заменяем систему управления технологическим процессом и не проектируем её.
Как проверить, что работа сделана
Приёмка держится на сопоставлении с фактом. Сверка простоев: за согласованный период простои на экране сравниваются с журналом смены и с наблюдением технолога, расхождения разбираются по каждому.
Сверка выпуска: счётчик продукции сравнивается с учётным количеством по сменному заданию.
Поведение при потере связи: если шлюз недоступен, данные накапливаются на месте и догружаются, а на экране видна пометка «нет данных», а не нулевой выпуск.
О чём спросить любого подрядчика
- Как подрядчик получит данные со станков без выхода данных и как проверит точность такого способа.
- Кто и как определяет правила состояния «работает, простаивает, остановлен» и подписывает их.
- Как оператор выбирает причину и сколько это занимает времени.
- Что видит руководитель при потере связи.
- Влияет ли система на оборудование: допустимый ответ — только чтение.
Как мы идём по этапам
На каждом этапе назван результат, который остаётся у заказчика. Остановиться можно после любого.
- Опись оборудованияСоставляем перечень станков, протоколов и точек съёма. Результат: таблица «станок, способ, надёжность».
- Правила состоянийВместе с технологом записываем, что считать работой и простоем. Результат: документ с примерами.
- Съём и шлюзПодключаем чтение сигналов, ставим шлюз, проверяем потерю связи. Результат: поток данных на тестовом участке.
- Причины и журналНастраиваем выбор причины оператором и сопоставление со сменным журналом. Результат: отчёт по сменам.
- Один участок, потом остальныеЗапускаем на одном участке, смотрим расхождения, потом расширяем. Передаём инструкцию и регламент сопровождения.
Как это обычно устроено внутри
Типовая схема: на станках считываются сигналы по стандартным протоколам (OPC UA, Modbus) или с внешних датчиков, шлюз накапливает данные и передаёт их наружу односторонне. Брокер сообщений принимает поток, правила состояний превращают сигналы в события, события хранятся во временной базе. Панель показывает выпуск и простои и отмечает отсутствие данных.
- OPC UA
- Modbus
- MQTT
- Временная база данных
- PostgreSQL
- Шлюз односторонней передачи
Похожая задача у вас?
Разберём её на созвоне за 40 минут: назовём объём работ, ограничения контура и по каким числам вы будете принимать результат. Если задача не наша — скажем прямо.