Записи за повреди на оборудване: Модел на данни за надеждност

Основни изводи - Запис за повреда на оборудване е структурирано регистриране на едно авариране: активът, режимът на повреда, причината, начинът на откриване, начало и край на престоя, време за ремонт и използвани части. - Записите за повреди са полезни само когато режимът на повреда (наблюдаваният симптом) и причината (основната причина) се улавят като отделни, кодирани полета, а не като свободен текст. - Чистите записи са суровината за MTBF, MTTR, достъпността в OEE и FMEA. Невярни записи правят всяка последваща метрика за надеждност ненадеждна. - Най-големият риск за качеството на данните е предположената причина. Улавянето на истинската причина за престоя в момента, в който той се случва, запазва честността на целия модел за данни за надеждност. Запис за повреда на оборудване е структурирано документиране на едно събитие на повреда, улавящо актива, режима на повреда, причината, метода на откриване, началото и края на престоя, времето за ремонт и използваните части. Последователните, кодирани записи са суровите данни зад MTBF, MTTR, достъпността в OEE и анализите за надеждност като FMEA. Какво е запис за повреда на оборудване? Запис за повреда на оборудване е структурирана документация за едно събитие на повреда на един актив. Той отговаря какво се е повредило, как се е повредило, защо се е повредило, колко време е било спряно, какво е направено за отстраняване и какви части са били използвани. Един запис = една повреда, с времеви печат и кодове, за да може по-късно да се брои, сортира и анализира. Записът за повреда не е същото като работна поръчка. Работната поръчка е инструкцията за извършване на ремонта. Записът за повреда е доказателството за надеждност, което ремонтът оставя след себе си. Както Reliabilityweb посочва, без точни данни за повреди „всичко, което имате, е система за работни билети“, и същият източник отбелязва, че „без режимите на повреда всичко, което имате, е куп кодове.“ Записът е това, което превръща затворения билет в данни, от които може да се извлече поука. Това е важно, защото почти всяка метрика за надеждност, която отчита вашият завод, се изгражда върху тези записи. Ако записите са неясни, предположени или неконсистентно кодирани, тогава MTBF, MTTR и компонентът за достъпност на OEE са изградените върху пясък. Кои полета принадлежат в един запис за повреда на оборудване? Пълен запис за повреда улавя актива, самата повреда, времевите данни, реакцията и ресурсите. Липсата на някое от тези полета разваля последващите изчисления. По-долу са основните полета, какво улавя всяко и често срещаните грешки при качеството на данните. Поле: Идентификатор на актива - Какво улавя: Точното оборудване, до нивото на компонент - Къде се използва: Пер-активен Парето анализ, класиране по критичност - Честа грешка: Записано срещу родителска линия, а не срещу повредилия блок Поле: Режим на повреда - Какво улавя: Наблюдаваният симптом (напр. блокирано лагер, прегрял мотор) - Къде се използва: FMEA, анализ на модели на повреди - Честа грешка: Свободен текст вместо кодиран стойност Поле: Причина - Какво улавя: Основната причина (напр. изкривяване, замърсяване) - Къде се използва: Коренова причина, предотвратяване на повтарящи се повреди - Честа грешка: Предположение, празно поле или слито с режима Поле: Метод на откриване - Какво улавя: Как е била открита повредата (оператор, аларма, инспекция) - Къде се използва: Оценка на откриваемостта в FMEA - Честа грешка: Не е записано изобщо Поле: Начало / край на престоя - Какво улавя: Кога активът е спрял и кога е възобновил производството - Къде се използва: Достъпност в OEE, общо време на престой - Честа грешка: Закръглено или попълнено по спомен Поле: Време за ремонт - Какво улавя: Активно време с инструменти за възстановяване на функцията - Къде се използва: MTTR - Честа грешка: Бърка се с общото време на престой Поле: Използвани части - Какво улавя: Компоненти и използвани количества - Къде се използва: Анализ на разходи, планиране на резервни части - Честа грешка: Записано след факта, непълно Поле: Предприето действие - Какво улавя: Корективната работа, която е извършена - Къде се използва: Библиотека с мерки, повторна употреба на знания - Честа грешка: Слято в полето за причина Фин детайл: престой и време за ремонт са различни полета. Престоят е целият часовник от спиране до стартиране, включително чакане на техник и чакане на части. Времето за ремонт е само активната ремонтна работа. Съхраняването им отделно позволява по-късно да разпознаете проблем, свързан с бавен отговор, от труден за отстраняване проблем. Защо режимът на повреда и причината трябва да са отделни полета? Защото режимът на повреда е това, което техникът наблюдава, а причината е това, което той изводи. Режимът обикновено е правилен. Причината често е предположение. Ако ги обедините в едно поле, никога няма да можете да разграничите надеждно наблюдение от желано допускане и качеството на данните ви тихо ще се влоши. Разделянето им също така позволява най-ценния въпрос за надеждността: дали един и същ режим продължава да се повтаря от една и съща причина? Reliabilityweb описва капана директно, предупреждавайки, че „новото лагерче, което току-що инсталирахте, може да се повреди 2–3 месеца по-късно, защото истинската причина не е била разрешена.“ Отделните полета изваждат този модел наяве. Какво е код за повреда и защо таксономията има значение? Код за повреда е стандартизирана стойност, избираема от падащо меню, която класифицира повредата вместо да я описва със свободен текст. Кодираната таксономия превръща хиляди аварии в броим набор от данни. Свободният текст ги превръща в куп неизследваеми бележки. Референтният стандарт тук е ISO 14224, международният стандарт за събиране и обмен на данни за надеждност и поддръжка на оборудване. Той дефинира общ език за надеждност: слоеста таксономия на оборудването плюс стандартизирани категории за данни за повреди, обхващащи данни за оборудването, данни за повреди като причина и последствие, и данни за поддръжка като извършено действие и време на престой. Дори извън нефтения и газов сектор, където произлиза, ISO 14224 е еталонът за това как да структурирате записите за повреди, така че те да се обединяват в една статистически валидна база данни (ISO 14224:2016). Практичният урок за всеки завод: изградете контролирана лексика на режими и причини на повреди за всеки клас оборудване, налагайте я чрез падащи менюта и направете полето за режим на повреда задължително преди да може да се затвори корективна работна поръчка. Това едно правило прави повече за качеството на данните от всеки аналитичен инструмент. Как записите за повреди захранват MTBF, MTTR и OEE? Записите за повреди са входните данни за основните метрики за надеждност. Всяка метрика е прост коефициент, но всеки член в този коефициент идва директно от вашите записи, което е точно причината качеството на записите да определя качеството на метриките. MTBF (Средно време между повреди) = Общо време на работа / брой повреди - Полета в записите: Брой повреди, време на работа между записите MTTR (Средно време за ремонт) = Общо време за ремонт / брой ремонти - Полета в записите: Поле време за ремонт, брой повреди OEE - достъпност = Време на работа / планирано време за производство - Полета в записите: Начало и край на престоя за всеки запис Формулите са умишлено прости. MTBF е общото време на работа, разделено на броя повреди, а MTTR е общото време за ремонт, разделено на броя ремонти. Забележете, че и двете зависят от точен брой повреди. Ако малките спирания не се записват, броят на повредите е твърде нисък и MTBF изглежда изкуствено добър. Ако времевите печати за престой са небрежни, достъпността е погрешна. Как чистите записи позволяват FMEA и анализи за надеждност? FMEA (Анализ на режимите и ефектите от повредите) е добра само колкото историята на повреди, върху която е изградена. FMEA класира рисковете, използвайки тежест, честота и откриваемост. Вашите записи за повреди доставят реалните данни за честота (колко често всъщност се случва всеки режим) и данните за откриване (как е била намерена повредата). Без кодирани записи тези оценки са мнения. С кодирани записи те са доказателства. Чистите записи също задвижват класирането по критичност на активите и ви позволяват да изградите програма за превантивна поддръжка, ръководена от данни, вместо календарно-базирани предположения. Повтарящ се режим на повреда при критичен актив е учебният пример за това кога да се превърне реактивният ремонт в планирана PM задача. Какви са най-честите проблеми с качеството на данните в записите за повреди? Най-честият проблем е предположената причина: техникът затваря задачата, избира правдоподобна причина от падащия списък и продължава нататък. Вторият е изцяло липсващи записи, където кратките спирания никога не се логват. Заедно те развалят както данните за причините, така и броя на повредите, което е причината Reliabilityweb да докладва, че „70 процента от всички инсталации на CMMS никога не са извършвали успешно базов анализ на повреди.“ Използвайте този контролен списък, за да одитирате дисциплината си за записване на повреди: - Задължителен режим на повреда при всяко затваряне на корективна работна поръчка, избран от контролиран списък. - Отделни полета за режим на повреда, причина и предприето действие, никога едно слито поле. - Времеви печати улавяни в момента на събитието, не реконструирани от паметта в края на смяната. - Кратките спирания се броят, за да е реален броят на повредите (виж рамката „шест големи загуби“). - Контролирана таксономия за всеки клас оборудване, идеално съобразена със структурата на ISO 14224. - Причината да се базира на доказателства, а не на най-удобната стойност от падащото меню. Как Fabrico поддържа записите за повреди точни, а не предположени? Повечето CMMS записи за повреди се въвеждат след факта от техник, който реконструира какво се е случило. Fabrico променя източника на данните. Тъй като Fabrico се свързва директно с PLC на машините, началните и крайните времеви печати за престой се улавят автоматично от линията, а не се въвеждат ръчно, така че данните за достъпността, подаващи OEE, са точни, а не закръглени. За най-трудното поле от всички — причината — Fabrico използва компютърно зрение, за да улови истинската причина за престоя в момента, в който настъпи спирането. Това премахва най-големия риск за качеството на данните в който и да е модел за данни за надеждност: предположена причина, записана часове по-късно. Проблемът след това се превръща в приоритетна дигитална работна поръчка, готова с части на телефона на техника, с QR-натоварени контролни списъци, така че корективното действие и използваните части да се записват в момента на извършване, а не по спомен след това. Резултатът е затворен цикъл от повреда до отстраняване, където записът за повреда е побочен продукт от работата, точен по конструкция. Като платформа, изградена в ЕС с данни, съхранявани в ЕС, Fabrico държи тези данни за надеждност в ясна рамка за управление. [INSERT VERIFIED PROOF POINT - операторът да потвърди] Ако вашите записи за повреди са пълни с предположени причини и закръглени времеви печати, вашите MTBF и OEE числа също са предположения. Вижте как Fabrico улавя истинската причина и превръща всяка повреда в чисти, готови за анализ данни. Често задавани въпроси Каква е разликата между запис за повреда на оборудване и работна поръчка? - Работната поръчка е инструкцията за извършване на ремонт. Записът за повреда на оборудване е структурираното доказателство за надеждност, което ремонтът оставя след себе си: активът, режимът на повреда, причината, престоят, времето за ремонт и частите. Едното записва какво да се прави, другото записва какво се е случило и защо, за да може по-късно да се брои и анализира. Какви полета трябва да съдържа запис за повреда на оборудване? - Минимално: идентификатор на актива, режим на повреда (наблюдаваният симптом), причина (основният мотив), метод на откриване, начало и край на престоя, време за ремонт, използвани части и предприето действие. Режимът на повреда и причината трябва да са отделни, кодирани полета, а престоят трябва да се съхранява отделно от активното време за ремонт. Защо режимът на повреда и причината за повредата трябва да са отделни полета? - Защото режимът на повреда е това, което техникът наблюдава и обикновено е правилно, докато причината е това, което той изводи и често е предположение. Разделянето им позволява да различите надеждните наблюдения от предположенията и да разберете дали един и същ режим продължава да се повтаря поради една и съща нерешена причина. Как записите за повреди захранват MTBF и MTTR? - MTBF е общото време на работа, разделено на броя повреди, а MTTR е общото време за ремонт, разделено на броя ремонти. И двете черпят директно от записите за повреди: броя на повредите, времето на работа между повреди и полето за време за ремонт. Неточни или липсващи записи правят и двете метрики грешни. Какво е ISO 14224 и защо е важен за записите за повреди? - ISO 14224 е международният стандарт за събиране и обмен на данни за надеждност и поддръжка на оборудване. Той дефинира обща таксономия на оборудването и стандартизирани категории за данни за повреди, включително причина за повреда, последствие и време на престой, така че записите да могат да се обединяват в една статистически валидна база данни. Той е еталонът за последователна структура на записите за повреди. Кой е най-честият проблем с качеството на данните в записите за повреди? - Най-честият проблем е предположената причина: техникът избира правдоподобна стойност от падащото меню след факта, вместо да улови истинската причина. В комбинация с непрезаписани кратки спирания, това разваля както данните за причините, така и броя на повредите, което е причината повечето инсталации на CMMS да не извършват успешно базов анализ на повреди.