Система управления техническим обслуживанием (CMMS)

Данные с датчиков устройств META Smart I/O или существующих ПЛК: вибрация, температура, ток и количество циклов являются типичными входными данными.

Да, наряды на работы, чек-листы и история оборудования доступны на телефонах, планшетах и панелях MSF.

Да. Причины простоев, зафиксированные в MES, автоматически создают уведомления для технического обслуживания.

Профилактические планы по датам или по наработке, наряды на работы, резервирование запчастей и история оборудования работают на одних записях, без единого сигнала с датчиков. Первые месяцы дают классификатор отказов, процент соблюдения графика ППР и историю простоев. Это же база сравнения, по которой потом будут оценивать любой мониторинг состояния. Именно разбор собственных внеплановых остановов за двенадцать месяцев показывает, на каких агрегатах акселерометр вообще окупится.

Всё, что отказывает без постепенного измеримого предвестника. Платы управления, модули ввода-вывода и большинство дискретных датчиков отказывают почти случайно, а столкновения, ошибки наладки и повреждения по вине оператора происходят как отдельные события, без постепенного развития. Защитное устройство вроде предохранительного клапана или блокировки не подаёт никаких признаков до самого события, от которого защищает, поэтому его проверяют по регламенту. Мониторинг тут бесполезен. Вибрация и ток хорошо читают механический износ вращающихся узлов и такие отказы не читают вовсе.

Меньше, чем следует из предложения, построенного вокруг моделей, потому что первые рабочие пороги берутся из инженерного расчёта: подшипниковые частоты по геометрии и оборотам вала, перепад давления на фильтре, превышение температуры над собственной нормой станка при той же нагрузке. Поиску аномалий нужен достаточный объём здоровой работы, чтобы покрыть нормальный разброс по номенклатуре, скорости и сменам. А оценка остаточного ресурса требует прогонов до отказа, которых у большинства заводов просто нет.

Закладывайте конкретного ответственного со стороны службы ТОиР. Доля рабочей недели всех подряд здесь не сработает. Основная тяжесть приходится на старт: иерархия оборудования, планы ППР, совпадающие с тем, что реально делается, и один раз согласованный классификатор отказов. После запуска регулярная работа состоит в разборе оповещений и закрытии нарядов со структурированными результатами, списанными запчастями и показаниями счётчиков. Объём оповещений настраивайте под то, что один человек физически успевает отработать, иначе их просто перестают открывать.

MTBF равен времени работы, делённому на число отказов, MTTR равен суммарному времени ремонта, делённому на число ремонтов, и то и другое собирается из полей наряда: время уведомления, начало и окончание ремонта. Без счётчика моточасов или сигнала работы из MES доступно только календарное время между отказами, поэтому простаивающий агрегат приукрашивает собственный MTBF. Цифра по ремонту тоже означает разное: от момента уведомления она включает ожидание и доставку запчастей, а от начала ремонта показывает чистое время работы ключом.

Нет, он работает самостоятельно. Операторы создают уведомления с HMI или из браузера, а планам, нарядам и запчастям больше ничего ставить не требуется. APS добавляет то, что согласованное окно обслуживания доходит до планировщика как ограничение графика, и о нём уже не забудут, как о разговоре в коридоре. Без него окна согласуют с производством вручную. Так начинает множество заводов, и это вполне разумное состояние, в котором можно и остаться.

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