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

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

Так, наряди на роботу, чеклісти та історія обладнання доступні на телефонах, планшетах і панелях MSF.

Так. Причини простоїв, зафіксовані в MES, автоматично створюють сповіщення для технічного обслуговування.

Плани планово-попереджувального обслуговування за датами або за напрацюванням, наряди на роботу, резервування запчастин та історія обладнання працюють суто на записах, без жодного входу з датчика. За перші місяці ви отримуєте кодування несправностей, відсоток дотримання плану та історію простоїв. Саме з цією базою потім порівнюватимуть будь-який моніторинг стану. Саме класифікація власних аварійних зупинок за дванадцять місяців показує, на яких одиницях обладнання акселерометр себе виправдає.

Усе, що виходить з ладу без поступової вимірюваної ознаки. Плати керування, модулі вводу/виводу та більшість дискретних датчиків відмовляють майже випадково, а зіткнення, помилки налагодження та пошкодження оператором є подіями, які не розвиваються як процес. Захисний пристрій, як-от запобіжний клапан чи блокування, не подає жодного сигналу, доки не настане подія, від якої він захищає, тому його перевіряють за інтервалом: моніторити тут нічого. Вібрація і струм добре читають механічний знос обертових вузлів, а ці режими не читають узагалі.

Менше, ніж передбачає пропозиція, побудована навколо моделі, бо перші робочі пороги дає інженерний розрахунок, історія для цього не потрібна: частоти дефектів підшипника з геометрії та обертів вала, перепад тиску на фільтрі, перевищення температури над власною нормою верстата за того самого навантаження. Для виявлення аномалій потрібно достатньо напрацювання у справному стані, щоб покрити нормальний розкид за продуктом, швидкістю і зміною. А оцінка залишкового ресурсу потребує прикладів роботи до відмови, яких на більшості підприємств просто немає.

Закладайте окрему відповідальну людину з боку служби обслуговування замість частки тижня від кожного. Основне навантаження припадає на початок: ієрархія обладнання, плани планово-попереджувального обслуговування, які збігаються з тим, що ви справді робите, і схема кодування несправностей, узгоджена один раз. Після запуску регулярна робота полягає в розборі сповіщень і закритті нарядів зі структурованим описом знайденого, витраченими деталями та показаннями лічильників. Налаштуйте кількість сповіщень під те, що одна людина реально встигає перевірити, інакше їх просто перестануть відкривати.

MTBF це час роботи, поділений на кількість відмов, MTTR це сумарний час ремонту, поділений на кількість ремонтів; обидва збираються з полів наряду на роботу: час сповіщення, початок і завершення ремонту. Без лічильника напрацювання або сигналу роботи з MES доступний лише календарний час між відмовами, тож обладнання, що простоює, штучно покращує собі MTBF. Показник ремонту теж означає різне: відлік від сповіщення включає очікування і деталі, а відлік від початку ремонту дає чистий час самих ремонтних робіт.

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

Рідко саме по собі. Попередження допомагає лише тоді, коли воно надійно перевищує термін постачання цієї деталі. А невідомий момент відмови є лише однією з причин, чому існує страховий запас: розкид строків постачання, мінімальні партії замовлення та один артикул на кілька одиниць обладнання нікуди не зникають. Модуль резервує деталі під наряд на роботу і формує замовлення на закупівлю, якщо запасу бракує. Спершу переведіть попередження у заплановані вікна, а до рівнів запасу поверніться після року фактичних даних.