На дашборде OEE 78%, руководитель спрашивает, почему линия «всегда в простое», а операторы кивают: «мы крутили». Открываете журнал простоев - половина записей «Прочее», микропростои по 40 секунд слились в один час, а автоматический стоп по межблокировке записан как плановый перерыв. OEE формула работает. Не работают входные данные.
Здесь не внедрение MES и не мотивация персонала KPI. Разбираем качество данных для OEE: справочник причин простоя, ручной ввод, дребезг состояния «работа/стоп», граница микропростоя. Статья не учит считать OEE с нуля - фокус на том, почему цифрам не верят и как починить сбор.
OEE перестают доверять, когда простои собирают из неточных состояний линии: дребезг датчика «в работе», ручной ввод без обязательной причины, разные определения микропростоя в SCADA и MES, отсутствие привязки к журналу оператора. Исправление: согласовать одно условие «линия работает», ввести гистерезис и минимальную длительность события, закрыть справочник причин, связать простой с audit trail.
Если Availability в OEE «плавает» от смены к смене при том же оборудовании - проблема не в формуле, а в границе событий. Сначала чините данные, потом KPI.
Типовая цепочка: датчик или тег «Line_Running» → агрегатор состояний → запись простоя → отчет OEE. На каждом звене возможна потеря смысла. Датчик видит импульс оборота раз в 2 с - между импульсами линия «стоит». Агрегатор без задержки режет 30-секундные паузы на 15 микропростоев. Оператор не выбрал причину - в отчет ушло «Прочее». MES взял время из другого часового пояса - простой «переехал» на соседнюю смену.
Граница SCADA и MES важна: кто владелец таймера простоя, кто справочник причин. Материал «SCADA vs MES: граница уровней и бюджет внедрения» помогает не дублировать счетчики на двух уровнях с разными правилами.
Если в списке 40 причин, а оператору нужно три клика в аврале, он выберет «Прочее» или первую строку. Через месяц 60% простоев необъяснимы - и OEE превращается в декорацию.
Рабочий справочник короткий на смене: 8-12 причин, покрывающих 90% случаев (материал, настройка, механика, электрика, плановый перерыв, переход). Редкие причины - в «Другое с комментарием». Обязательное поле при простое дольше N минут. Сверка раз в неделю: какие причины раздулись, какие не используются.
Автоматика фиксирует «стоп», но не «почему». Без связи с журналом действий оператора нельзя отличить плановую остановку от аварии, которую квитировали и забыли описать. Минимум: при переходе в простой > 3 мин логировать пользователя, экран, из которого ввели причину, и привязку к событию SCADA.
Если причину может ввести только мастер, а ночью мастера нет - утром простой останется без классификации. Либо автоматическая временная причина «требует уточнения», либо право оператора на короткий список.
Сигнал «в работе» часто строят по одному дискретному датчику, по току двигателя или по счетчику импульсов. Короткие провалы - норма: смена флакона, ожидание робота, пауза конвейера. Без гистерезиса и минимальной длительности состояния система насчитывает десятки микропростоев и занижает Availability.
Практика: условие «работает» = комбинация нескольких признаков (главный привод + разрешение цикла), задержка включения 5-10 с, задержка выключения 30-60 с в зависимости от технологии. Отдельно настраивают порог микропростоя: события короче T не пишут в OEE или агрегируют в «накладные потери».
На одном объекте микропростой - меньше 2 минут, на другом - меньше 5. Если SCADA режет на 1 минуте, а отчет Excel на 5, цифры никогда не сойдутся. Зафиксируйте T в паспорте методики OEE и примените везде: historian, MES, дашборд.
Слишком маленький T - шум и недоверие. Слишком большой - прячете реальные потери наладки. Для упаковочных линий часто 3-5 минут; для непрерывных процессов - отдельные правила по участкам.
| Искажение OEE | Источник | Как исправить сбор |
|---|---|---|
| Завышенный простой | дребезг «Line_Running» | гистерезис, комбинированное условие |
| Простой «Прочее» 50%+ | слабый справочник причин | короткий список, обязательный ввод |
| Микропростои как часы | нет порога T | согласовать T, агрегация коротких |
| Расхождение смен | разное время SCADA/MES | NTP, одна зона, одна метка смены |
| Плановый перерыв в аварии | ручной режим без причины | журнал оператора, блокировка класса |
| Performance > 100% | неверный идеальный цикл | пересмотр норматива выпуска |
Недоверие к OEE редко только про Availability. Performance падает, если «идеальный цикл» взят из паспорта 2018 года, а реальный рецепт другой. Quality - если брак регистрируют в конце смены пачкой, а не по событию. Сверьте теги брака с фактическими остановками линии на тренде.
На многих объектах OEE считают в SCADA или Excel из выгрузки historian. Это нормально, если правила сбора задокументированы. Не обязательно ждать MES - обязательно согласовать определения с производством и закрепить в регламенте смены.
Availability = (плановое время - простой) / плановое время. Простой считается от момента, когда тег Line_Running стал FALSE. Если тег дергается каждые 20 секунд, система насчитает 80 микропростоев за смену вместо одной наладки. Цифра OEE падает, цех говорит «мы работали», IT показывает график с зубцами.
Устойчивое условие «работает» строят из нескольких признаков: главный двигатель, цикл «выпуск готов», отсутствие аварии останова. Добавляют таймер: состояние «стоп» учитывается только если длится дольше T секунд. T согласуют с технологами: для линии розлива 45 с - нормальная пауза, для пресса - уже простой.
Экран причины простоя должен открываться автоматически при простое > N минут, не прятаться в меню «Отчеты». Список причин - крупные кнопки, не выпадающий список на 30 строк. Ночная смена заполнит три поля; дневная - ноль, если экран неудобен.
Связь с журналом действий оператора: кто выбрал причину, с какого экрана, было ли подтверждение мастера. Без этого «Прочее» - не лень оператора, а дефект интерфейса.
Технолог называет 40-секундную остановку «микропростоем», учет - «наладкой», MES - «простоем». В отчете OEE три разных числа. На совещании «цифрам не верят», хотя каждая система честна по своим правилам.
Выход - один глоссарий в паспорте методики: микропростой < T1 не пишется; от T1 до T2 - накладные потери; > T2 - простой с обязательной причиной. SCADA и Excel применяют одни пороги. Граница SCADA и MES - кто хранит справочник и кто считает итог смены.
Performance падает, если идеальный цикл взят из паспорта 2018 года, а рецепт изменился. Quality - если брак регистрируют пачкой в конце смены. Сверьте тег брака с трендом остановок: брак должен совпадать с событиями, а не с «удобным» временем ввода.
Если операторы обходят HMI и не фиксируют события, OEE отражает не линию, а дисциплину ввода. Тема «Почему оператор обходит HMI» пересекается с качеством KPI напрямую.
Раз в неделю мастер и инженер разбирают 5-10 случайных простоев: тренд, причина, журнал. Несовпадение в трех из десяти - сигнал менять правила, а не «разъяснять цеху формулу». Такой аудит дешевле, чем месяц споров о достоверности дашборда.
Время смены и отчетного периода сверяют с NTP - иначе простой «переезжает» между сменами и ломает сравнение недель.
Останов на обед с плановым кодом не должен попадать в аварийный простой OEE. Если код не выбран, система классифицирует останов как «неплановый» - Availability падает, хотя линия стояла по графику. В паспорте методики закрепляют: плановые окна задаются расписанием или кодом смены, не только ручным вводом.
Ночная смена иногда не отмечает плановую мойку - утром отчет показывает «час потерь». Это снова про качество ввода, а не про формулу.
Не защищайте цифру слайдом. Покажите один день: тренд Line_Running, список микропростоев, скрин причин, фрагмент журнала оператора. Если цех прав - меняют правило T и справочник. Если прав счетчик - показывают 40 секунд простоя, которые смена не заметила. Доверие к KPI возвращается не точностью формулы до третьего знака, а прозрачностью исходных событий.
Закрепите методику в паспорте объекта: определения, пороги, владелец справочника причин, периодичность аудита. Тогда спор «цифрам не верят» переходит в регламент, а не в политику.
Если Line_Running берут с реле концевика или импульсного датчика без фильтра в ПЛК, один оборот линии дает серию фронтов. Счетчик простоев считает паузы между импульсами. Решение на стороне АСУ ТП: таймер удержания состояния, счетчик оборотов с таймаутом «нет импульса T сек = стоп», или аналоговый признак загрузки. Технологу важно не «подкрутить OEE», а согласовать, что считается работой для данной линии.
Можно ли доверять OEE без ручного ввода причин?
Availability по автоматике - да, с хорошим условием «работает». Разбор потерь без причин - нет.
Кто должен владеть методикой OEE?
Производство + АСУ ТП совместно. Иначе IT или интегратор зафиксируют формулу, которой не пользуются в цехе.
Как проверить качество данных за неделю?
Выборочно 10 простоев: тренд, событие, причина, журнал оператора. Несовпадение в 3+ случаях - сигнал к пересмотру правил.