Метрики технолога - aps365.ru

О КУРСЕ «ЦИФРОВАЯ ТРАНСФОРМАЦИЯ ПРОИЗВОДСТВА»?

Общие вопросы организации курса

Управление по отклонениям?

Выявление, обработка, предотвращение отклонений производственной системы - важнейший инструмент повышения эффективности производства. Основные потери происходят не от несовершенства производственной системы. её достаточно просто оптимизировать, а от многочисленных простоев, бесполезных и вредных операций вызванных отклонениями в состоянии производственной системы по разным причинам.

ПРОЦЕССНОЕ ПРОИЗВОДСТВО?

Чёрная металлургия Цветная металлургия bathing - фармацевтика - пищевое производство - косметика и парфюмерия - смазки - строительные смеси

#DFT-FAQ Вопросы и ответы цифровизации производства

Метрики производства. Метрики технолога.

Говорят, плох тот технолог, который не хочет убить конструктора. Ну, давайте подумаем, какие еще метрики определяют хорошего технолога и правильную технологию.

Итак, сегодня вторая часть курса, которая позволит технологу судить о состоянии технологии и оперативно  получить ключевые показатели, важные для его работы.

А теперь рассмотрим, какие же метрики важны для технолога. Причем речь идет не о технологических параметрах, которых, на самом деле, очень-очень много, а именно о метриках. То есть показатели, по которым можно сразу судить, все хорошо, или все не очень хорошо.

И в первую очередь технолога интересует, как идет обработка.

  1. Самое срочное – это аварийные остановы или грибок. Если мы применяем автоматизированные системы, то мы можем очень легко посчитать:
  • сколько раз обработка была остановлена аварийно, и какую долю это составит от всех запусков;
  • особенно нас интересует число случаев, когда обработка была прервана вообще, то есть, когда после аварийной остановы ее невозможно было продолжить;
  • ну и хорошо, когда у нас есть возможность отранжировать аварийные остановы: на какие управляющие программы они приходятся, на какие станки, у каких операторов это случилось, и кто разрабатывал управляющие программы, которые привели к аварийной остановке.

Рейтинги вообще очень полезны, потому что они позволяют определить приоритеты и начинать с самого важного.

Ну а теперь отправим кого-нибудь добывать эти метрики из реальных станков.

Далее – видеофрагмент.

Осуществлять анализ аварийных стопов можно с помощью следующих средств и инструментов системы. Все инструменты аналитики, демонстрирующие состояние работы оборудования, в том числе показывают время аварийных стопов. Проведем оценку наличия аварийных стопов за конкретный период на примере аналитики «Загрузки группы станков» ее круговой формы. Данная аналитика позволяет анализировать структурные подразделения либо предприятие в целом. Здесь мы можем зафиксировать наличие аварийных стопов, увидеть их общее время в часах и в процентах от времени за выбранный период.

Для дальнейшего анализа по отдельным станкам можно использовать аналитику «Состояния группы станков». Здесь мы можем увидеть, как распределяется общее время аварийных стопов по отдельным станкам.

Информацию по количеству аварийных стопов за конкретный период времени представляет аналитика «Состояния станка по частоте-длительности возникновения».

Дальнейший анализ в контексте управляющих программ, во время работы которых происходил аварийный стоп, возможен при помощи диаграммы Ганта. Здесь, задав нужный нам период, можно узнать номер управляющей программы, и в дальнейшем узнать имя специалиста, загрузившего ее либо внесшего изменения в текст управляющей программы. Сделать это можно через библиотеку управляющей программы.

Также, изучив аналитику «План-фактный анализ», мы сможем узнать имя оператора станка, выполнявшего задание, в рамках которого мы проводим данный анализ.

Еще один эффективный способ подсчета количества аварийных стопов – это создание соответствующего сигнала в системе. Данный сигнал автоматически будет предупреждать пользователя о срабатывании аварийного стопа на любом из станков. А перечень сработавших сигналов с возможностью поиска и сортировки будет доступен в списке уведомлений.

  1. Второй по важности вопрос для технолога – это перегрузки. На многих современных станках есть динамометры нагрузки, и производителями установлены те пределы, выше которых нагрузка считается чрезмерной. И вот хорошо, если за выбранный период мы можем определить:
  • какое максимальное значение допускалось;
  • какая его длительность, потому что кратковременные перегрузки могут быть вызваны инерцией тяжелых движущихся частей станка;
  • естественно, нам нужно зафиксировать не только факт перегрузки, а и понимать окружение, то есть значения других параметров, когда произошла перегрузка;
  • кроме того, если мы определили временной интервал и группу станков, мы можем посчитать количество таких случаев, когда нагрузка была превышена;
  • посчитать их общее время;
  • и определить количество управляющих программ с перегрузкой на выбранном нами диапазоне данных;
  • а также просуммировать время, когда велась обработка по управляющим программам, которые вызывают перегрузки;
  • а также показать его как долю от количества управляющих программ, то есть, сколько их за этот период выполнялось всего и сколько их них с перегрузкой;
  • и какую часть времени на выбранном диапазоне выполнялась обработка всего, и какую часть времени из этого заняла обработка с перегрузкой.

Причем еще раз обращаю внимание, что это всего лишь метрики, то есть которые показывают, были перегрузки или не были и масштаб катастрофы. А о том, какая их реальная величина и искать их причины нужно уже рассматривая параметры обработки. Ну и опять же, хорошо, когда мы можем отранжировать выборку по управляющим программам, по оборудованию, по оператору, который допустил эти перегрузки, и кто технолог, разработавший эти управляющие программы.

Ну а теперь отправим кого-нибудь добывать эти метрики из реальных станков.

Далее – видеофрагмент.

Возможности системы позволяют фиксировать нарушения, связанные с превышением допустимого уровня скоростей и нагрузок во время работы оборудования. Наиболее эффективным инструментом в данном случае является модуль сигнала. Он позволяет задавать сигналы, которые в дальнейшем будут автоматически оповещать пользователя о всех случаях превышения. И при этом логика сигналов может быть самой разнообразной. Мы можем задать конкретное время превышения того или иного параметра или же задать условием срабатывания сигнала превышение нескольких параметров. Впоследствии список сработавших сигналов с возможностью поиска и сортировки будет доступен в разделе «Уведомления».

Параллельный анализ всех параметров одного станка возможен с помощью диаграммы Ганта. Здесь мы можем вывести все параметры и увидеть, что происходило с ними в момент превышения одного из них. Также наблюдение всех параметров одновременно в режиме реального времени возможно с помощью технологической диаграммы.

Анализ отдельных параметров для одного станка возможен с помощью аналитики «Индикаторы». Данная аналитика поддерживает сортировку по возрастанию либо убыванию значений выбранного параметра с целью выявления максимального превышения.

  1. Ну и нарушения обработки, которые происходят от намеренных действий оператора. В первую очередь это увеличение скорости или разгон станков. Опять же, нас интересует:
  • максимальное значение, до которого была увеличена или уменьшена скорость;
  • его длительность, как долго этот параметр был в измененном состоянии;
  • и нам нужна возможность посмотреть, какие при этом были другие параметры окружения;
  • а также посчитать количество превышений, сколько раз достигало;
  • их общее время за выбранный период;
  • количество управляющих программ, на которых была допущена коррекция;
  • их суммарное время;
  • их доля в общем количестве программ;
  • и та часть времени от общей выборки, которую продолжались управляющие программы с корректировками.

Опять же, метрики – это не технологические параметры. То есть мы не можем судить, насколько серьезно вмешивался оператор. Метрики – это те величины, которые позволят сразу определить: вмешивался-не вмешивался и насколько долго. И насколько часто. То есть, есть нам смысл смотреть технологические параметры или нет. Если метрики показывают, что ситуация угрожающая, мы смотрим технологические параметры. Если метрики показывают, что вмешательства не было, мы можем глубоко не лазить.

  1. Точно так же и с корректором подачи:
  • мы определяем максимальное значение, на которое он был увеличен, если он был увеличен;
  • как надолго его увеличили;
  • какие при этом были окружающие значения;
  • как часто, сколько раз, было допущено увеличение корректора подачи;
  • сколько времени продлилась работа, увеличенная подачей;
  • сколько было всего управляющих программ, на которых подача корректировалась;
  • какова общая длительность этих управляющих программ;
  • какой процент составили программы, на которых допускалась коррекция подачи от общего количества выполненных управляющих программ за этот период;
  • и какую часть времени они выполнялись.

Какие еще метрики интересуют технолога? Это параметры управляющих программ для оборудования с ЧПУ.

  1. Итак, какие метрики у нас для УП?
  • Сколько всего было пусков. Если мы выбрали какой-то диапазон оборудований и временной диапазон – сколько всего раз были запущены управляющие программы;
  • сколько из них завершились в штатном режиме, то есть отработали так, как нужно;
  • какое их количество и какой процент от общих запусков.

А вот сбойные случаи нам лучше рассматривать как обратные величины:

  • сколько управляющих программ были прерваны аварийно;
  • их количество и процент от общих запусков;
  • как часто оператор переводил автоматическую обработку в ручной режим;
  • и сколько было таких случаев, и какой процент от общих пусков они составили;
  • если у нас интегрирована информационная система, то мы можем показать технологу, какой брак отметил ОТК для этих пусков, то есть, сколько было количество выявленного брака, и какой процент он составил от общих запусков УП;
  • ну и точно так же количество брака, который отметил оператор, если мы даем ему такую возможность (ну, то есть, если он оператор-контролер). Сколько было таких случаев, и какой процент они составили;
  • кроме того, на современных УЧПУ мы можем определить, вмешивался ли оператор в код управляющей программы. То есть, какое количество из этих запусков прошли по откорректированному коду, и какой процент они составили от общего количества и от суммарного времени.

Опять же, напоминаю, что это не средство для анализа управляющих программ, что сейчас речь идет о показателях, которые свидетельствуют, все хорошо, или все плохо. То есть, надо ли разбираться более детально или не надо. Если эти показатели кажутся приемлемые, можно заняться другими делами. Если они кажутся неприемлемыми, то можно выполнять более подробный анализ управляющих программ. Ну и хорошо иметь рейтинг. Опять же, в разрезе управляющих программ, в разрезе оборудования, в расшифровке по операторам или по технологам, кто разрабатывал эти управляющие программы.

  1. Следующая группа метрик, относящаяся к технологии. Если у нас технологии разрабатываются в электронной форме, то мы можем и автоматически сформировать параметр, чтобы судить о том, насколько правильно они применяются.
  • Для этого мы показываем технологу количество ДСЕ, используемых в автоматизированной системе, то есть, какое их количество;
  • И какая часть их них не обеспечена техкартами (число и доля от общего количества). Таким образом, мы можем сразу одним взглядом судить, какая часть деталей у нас выполняется по электронным технологиям;
  • в том числе, нас интересует цифра, сколько этих изделий было запущено в производство всего на выбранном интервале времени или выбранном диапазоне оборудования;
  • какое количество ДСЕ запускалось за этот период и их доля от общего количества;
  • ну и также количество и доля необеспеченных техкартами ДСЕ, которые были запущены в производство от общего количества, которое производилось на этом интервале;
  • дальше, если мы используем автоматизированные рабочие места, мы легко можем определить и показать технологу, как часто нарушался порядок операций, описанных в техкартах (сколько было таких случаев, и какую долю от общих производственных операций они составили);
  • точно так же, если мы пытаемся нормировать операции, то нам интересно количество случаев, и как часто это зависело именно от операции наладки. То есть, когда по данной техкарте наладка длилась дольше, чем нужно;
  • точно так же отдельно мы считаем количество и долю операций, где обработка прошла не в соответствии с техкартой;
  • ну и также, какое количество операций остались неотнормированы, какое количество деталей выполняется у нас с технологиями, которые не имеют норм.

Причем, что важно. Что если у нас работа выполняется дольше, чем определено технологией, то это указывает на наше нарушение в производстве. Или то, что технология не до конца отлажена или не до конца понятна. А вот если у нас работа выполняется существенно быстрее технологии, то значит у нас совсем все плохо. То есть, если работа длилась дольше норм, ну, значит, исполнитель не очень старался или не очень умеет. А вот если удалось ее завершить существенно быстрее, то, значит, мы вообще совсем не понимаем ничего в своей технологии. И это чревато серьезным браком. Точно так же, если таких случаев много, то их стоит отранжировать. В первую очередь рассортировать по номенклатуре деталей, по техкартам, обращая внимание на то, что техкарта может содержать альтернативные маршруты, и отклонения могут относиться только к одному из них. Отсортировать по видам применяемых управляющих программ, по станкам из выбранного диапазона, по операторам, которые выполняли обработку по этим технологиям, и по технологам, кто эти техкарты разрабатывал.

  1. Если у нас применяется интегрированная система управления, где передача информации из инженерного контура в производственный идет автоматически, то полезно контролировать еще ряд метрик:
  • то есть, какое количество технологий есть в мастер-системе. Допустим, в PLM или CAM-системе;
  • и какое количество из них оцифровано в производственном контуре;
  • а также автоматически сравнить, какое количество из них полностью совпадает, и какой процент это составляет от общего количества, в каком количестве из них выявлены несоответствия, какое количество из них есть в мастер-системе, но отсутствует в производственном контуре, и какое количество из них есть в производственном контуре, но при этом отсутствует в мастер-системе.

При этом это, опять же, не свидетельствует об объеме отклонений и количестве работы, которое придется выполнить для их ликвидации. Это метрики. То есть они нам только говорят, все хорошо или не очень хорошо. Когда, не прикладывая никаких усилий, мы можем оценить ситуацию и понять, стоит ли разбираться более детально, или ситуация приемлема.