
Ключови изводи
Кратък отговор: Общите кодове за грешки губят време за диагностика. Добре проектираните кодове именуват конкретното устройство, конкретното състояние и предлагат стъпка за възстановяване. Дисциплината струва повече в началото, но спестява часове на грешка за постоянно. Вижте също Проектиране на кодове за причини за престой.
„Sensor Fault“ не казва на оператора нищо, което може да се приложи. Кой датчик? Какъв тип грешка? Какво да се провери първо?
Резултат: операторът разследва от нулата. Средното време за диагностика се увеличава. OEE страда.
Пример лош: FLT_SENSOR. Пример добър: FLT_PE_INFEED_LOW_LOW с описание „Сензорът за приемане отчита ниска стойност за 2 с, проверете лещата за замърсявания.“
Последователен префикс, устройство, състояние. Операторите научават шаблона.
Документирайте всеки код за грешка: идентификатор, описание, предложено действие, ескалация. Операторите го използват като справочник; CMMS свързва заявки за работа с кодовете.
Кодът за грешка подава причината в CMMS. Отчетите показват най-честите кодове по линия. Разследванията са насочени към най-сериозните.
1. Кодове, написани от програмиста без преглед от оператора. Кодовете имат смисъл за програмиста; не и за оператора в 3 сутринта.
2. Липса на документация. Библиотеката с кодове живее в главата на програмиста.
3. Генерични обобщения. „Other Fault“ крие истинската причина.
4. Кодове, които се променят между ревизиите на PLC. Историческите данни стават неизползваеми.
Достъпността (Availability) в OEE се определя предимно от престоя. Кодовете за грешки подават категоризацията на причините за престой. Конкретните кодове дават ясен Парето анализ; общите кодове водят до безсмислена 30% част, означена като „Sensor Fault“.
Модулът OEE на Fabrico приема кодове за грешки от PLC чрез OPC UA / Modbus, картографира ги към кодове за причина и генерира Парето отчети, които подпомагат подобрения в дизайна.
Вижте как Fabrico улавя това автоматично, разгледайте OEE за производство или заявете демонстрация.
Инженеринг на контролните системи с участие на оператори и отдел поддръжка.
Да. Преработете при следващата ревизия на програмата.
Променливо. Десетки до стотици е нормално.
Често минути на грешка. Накопено, часове на седмица.
Кратък отговор: Общите кодове за грешки губят време за диагностика. Добре проектираните кодове посочват конкретното устройство, конкретното състояние и предлагат стъпка за възстановяване. Дисциплината струва повече в началото, но спестява часове за всяка грешка занапред.
„Sensor Fault“ не казва на оператора нищо приложимо. Кой датчик? Какъв вид повреда? Какво да се провери първо?
Резултат: операторът разследва от нулата. Средното време за диагностика се увеличава. OEE страда.
Пример лош: FLT_SENSOR. Пример добър: FLT_PE_INFEED_LOW_LOW с описание „Четенето на фотодатчика на подаването е ниско за 2 с, проверете лещата за замърсявания.“
Последователен префикс, устройство, състояние. Операторите научават модела.
Документирайте всеки код за грешка: идентификатор, описание, предложено действие, ескалация. Операторите ги използват като справка; CMMS свързва работни поръчки с кодовете.
Кодът за грешка подава причината в CMMS. Отчетите показват най-честите кодове по линия. Разследванията са насочени към най‑сериозните.
1. Кодове, написани от програмиста без преглед от оператора. Кодове, които имат смисъл за програмиста, но не и за оператора в 3 сутринта.
2. Липса на документация. Библиотеката с кодове живее в главата на програмиста.
3. Общи „catch‑all“ кодове. „Other Fault“ прикрива действителната причина.
4. Кодове, които се променят между ревизиите на PLC. Историческите данни стават неизползваеми.
Достъпността (Availability) в OEE се определя основно от престой. Кодовете за грешки захранват категоризацията на причините за престой. Конкретните кодове дават конкретни Парето резултати; общите кодове водят до безсмислен дял от 30% „Sensor Fault“.
OEE модулът на Fabrico приема кодовете за грешки от PLC чрез OPC UA / Modbus, картографира ги към кодове за причина и генерира Парето отчети, които водят до подобрения в дизайна.
Инженерите по системи за управление, с участието на оператори и екипа за поддръжка.
Да. Рефакторирайте при следващата ревизия на програмата.
Зависи. Десетки до стотици са нормални.
Често няколко минути на грешка. Натрупано, часове на седмица.