ML срещу базирано на правила откриване на аномалии: два подхода към един и същи проблем, различни компромиси Ключови изводи - Откриване на аномалии, базирано на правила = прагове и правила за шаблони, създадени от инженери. - Откриване на аномалии с ML = модели, които научават нормалните модели и сигнализират отклонения.
- Правилата улавят известни режими на повреда; ML улавя това, което не е било специфицирано. - Правилата са проверяеми и лесни за обяснение; ML може да превъзхожда при сложни мултивариантни сигнали. - Повечето заводи печелят и от двете: правила за известните модели, ML за останалото.
Кратък отговор: Подходът за откриване на аномалии, базиран на правила, използва прагове и инженерни шаблони за сигнализиране на познати режими на повреда. Откриването с ML научава нормалните модели от данните и сигнализира отклонения, които инженерите не са специфицирали. Правилата са проверяеми и лесни за обяснение; ML често превъзхожда при сложни мултивариантни сигнали.
Повечето заводи се възползват от комбинация, правила за познатото, ML за неизвестното. Вижте също Използване на машината спрямо натоварване (/bg/blog/machine-utilization-vs-loading/). С какво се справя добре подходът, базиран на правила - Проверяемо. Всяко предупреждение може да се проследи до конкретно правило. - Обяснимо. Операторите разбират какво е задействало предупреждението. - Нужда от малко данни.
Работи от първия ден. - Настройваемо. Инженерите коригират праговете. Какво пропуска подходът, базиран на правила - Режими на повреда, които никой не е предвидил. - Мултивариантни шаблони, обхващащи много сензори. - Слаби дрейфове в рамките на отделни прагове. - Корелирани промени в няколко сигнала. С какво се справя добре ML - Улавя неочаквани модели.
- Мултивариантен анализ. - Адаптира се към различни експлоатационни режими. - Подобрява се с повече данни. С какво ML има затруднения - Обяснимост. „Защо беше пуснато предупреждение?“ е по-труден въпрос. - Нужда от данни. Изисква месеци до години история. - Дрейф. Необходимо е преобучаване на моделите. - Процент на фалшиво положителни.
Критично е да се настрои. Кога правилата са за предпочитане - Добре разбирани режими на повреда. - Регулирани среди, изискващи проверяемост. - Нови внедрявания без историческа информация. - Стандарти, базирани на прагове (ISO 10816 вибрации). Кога ML е за предпочитане - Сложни мултивариантни процеси. - Заводи с богата историческа база данни.
- Режими на повреда, които инженерите не могат пълно да специфицират. - Операции, при които пропуските са много скъпи. Хибридният модел Повечето зрели заводи използват и двата подхода: - Правилата покриват известните режими на повреда с висока увереност. - ML улавя неизвестното. - Несъответствията между двата подхода задействат разследване.
- ML предупреждения, потвърдени чрез проверка по правилата, често се превръщат в нови правила. Комбинацията превъзхожда всеки от двата подхода поотделно. Чести грешки 1. ML без история. Моделите, обучени на недостатъчно данни, се провалят. 2. Правила без покритие. Инженерите не специфицират всички режими на повреда. 3. Замяна на правилата с ML. Губи се проверяемостта. 4.
Липса на настройка. Високият процент фалшиво положителни сигнали убива двата подхода, ако не се управлява. Проблемът с проверяемостта ML в регулирани среди изисква обяснимост. Подходи: - Използване на интерпретируеми модели (дървета за решения, обобщени линейни модели). - Използване на дълбоко обучение с механизми на внимание или визуализация на важността на признаците.
- Използване на ML за маркиране на кандидати, а верификацията преди действие да става чрез правила. - Документиране на тренировъчните данни и валидацията на модела. Регулаторното приемане на ML се увеличава, но не е универсално. Проблемът с дрейфа Процесите се променят, оборудването остарява, рецептурите еволюират.
Моделите, обучени на старите норми, се държат различно спрямо новите норми. Мерки за смекчаване: - Периодично преобучение. - Откриване на дрейф. - Използване на плъзгащ прозорец или онлайн обучение. Чести грешки 1. ML предупреждения, които никой не разследва. Както при всяка система за детекция, предупрежденията трябва да се обработват. 2.
Липса на база за това какво означава точността на модела. Без сравнение представянето е непрозрачно. 3. Отнасяне към ML като „plug-and-play“. Моделите изискват инженеринг на данни, валидация и наблюдение. Интеграция с CMMS И при правилата, и при ML предупрежденията трябва автоматично да генерират задачи за поддръжка (CMMS WOs).
Нивата на увереност могат да управляват приоритета (висока увереност → незабавна задача; по-ниска увереност → опашка за разследване). Как се отнася OEE И двата подхода захранват мониторинг на състоянието, който влияе на OEE. Установените проблеми стават планирана поддръжка; пропуснатите проблеми, непланирани престои.
Заводи, които сравняват достъпността (Availability) на OEE преди и след зряла програма за откриване на аномалии, обикновено виждат покачване на достъпността.
Как модерна OEE платформа поддържа и двата подхода Модерна OEE платформа поддържа прагове и правила за известни модели и ML-базирано откриване на аномалии за неочаквани модели, като и двата типа подават въвеждания към CMMS за разследване и действие.
Модулът OEE на Fabrico поддържа както базирано на правила, така и ML-базирано откриване на аномалии, като и двата подават работни потоци към CMMS за разследване и действие. Вижте как Fabrico улавя това автоматично, разгледайте OEE за производство (/bg/blog/oee-for-manufacturing/) или запазете демо (/bg/demo/).
Свързано четиво - Използване на машината спрямо натоварване (/bg/blog/machine-utilization-vs-loading/) - Производители на машини срещу системни интегратори (/bg/blog/machine-builders-vs-systems-integrators/) Често задавани въпроси Трябва ли винаги да ползвам ML? Не. Правилата работят добре за известни модели; ML добавя стойност за неочакваните случаи. Колко данни са нужни за ML? Много вариращо.
Често правило: достатъчно, за да покрие нормалната експлоатационна вариативност (сезонност, смес от продукти и т.н.). Дали базираното на правила е твърде просто? Не. Правилата се справят добре с повечето известни режими на повреда. ML е за остатъка. Как да избегна фалшиво положителни сигнали?
Настройвайте праговете за увереност; изисквайте многосигнални потвърждения; учете се от обратната връзка на операторите. Може ли ML да предскаже конкретни режими на повреда? Ако е обучен върху означени (labeled) данни за повреди, да. Без етикети ML може само да открие аномалия, без да определи типа.
Вход
Блог
