Как провести хронометраж роботизированной ячейки и правильно посчитать время цикла ART-025

Сначала определите, что именно вы называете одним циклом

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

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

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

Не стоит называть временем цикла только сумму движений манипулятора. Робот может значительную часть реального цикла ждать станок, а станок — робота. Для пропускной способности важна не занятость одного механизма, а календарный интервал между повторяемыми выходами системы.

Хронометраж начинается с событий, а не с впечатления «робот долго стоит»

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

Для каждого события достаточно фиксировать:

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

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

Если контроллер или производственная система уже ведет журналы событий и времени цикла, их стоит сопоставить с живым наблюдением. ABB, например, в своих инструментах аналитики роботизированных систем отдельно использует Cycle Time и Event Logs как разные представления производственных данных: одна цифра показывает тенденцию цикла, а журнал событий помогает понять, что происходило внутри.

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

Последовательное время складывается, параллельное — нет

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

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

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

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

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

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

Иллюстративный пример: почему 6 + 24 + 9 не обязательно равно циклу

Ниже — не норматив для роботов и не рекомендуемые скорости. Это только арифметический пример, который показывает логику перекрытия.

Предположим, после завершения одной детали:

• робот тратит 6 с на выгрузку готовой и установку новой детали;
• технологическая машина после этого работает 24 с;
• пока машина работает, робот тратит 9 с на подготовку следующей заготовки в отдельном доступном буфере.

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

Время от завершения одной детали до завершения следующей в таком иллюстративном сценарии:

`T_цикла = 6 с + 24 с = 30 с`

а не `6 + 24 + 9 = 39 с`.

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

`T_цикла = 5 с ожидания + 6 с обмена + 24 с процесса = 35 с`

Цифры здесь намеренно вымышлены. Важен не результат 30 или 35 секунд, а способ проверки: каждый интервал виден на временной шкале, а параллельное время не учитывается дважды.

Ожидание нужно записывать как отдельное состояние с причиной

Фраза «робот стоял 12 секунд» почти ничего не объясняет. Нужно знать, чего он ждал и увеличило ли это ожидание интервал между годными деталями.

На практике полезно разделять как минимум такие состояния:

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

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

Переналадку не стоит прятать внутри «среднего цикла»

Повторяемое время одной стабильной детали и переход между разными работами — разные производственные явления.

Если смена захвата, приспособления, программы, позиции или другой конфигурации происходит один раз на партию, ее полезно измерять отдельно:

• от начала остановки предыдущей работы;
• до момента, когда новая работа способна стабильно выпускать годные детали.

После этого можно считать две разные метрики.

Стабильное время цикла показывает, как работает ячейка внутри повторяемой серии.

Фактическое время партии показывает календарь от начала переналадки до выхода последней годной детали.

Для планирования коротких партий иногда полезна производная величина:

`T_на_годную_деталь_в_партии = T_фактическое_время_партии / N_годных_деталей`

Это не «настоящий цикл робота» и не характеристика оборудования. Это плановая метрика конкретной партии, которая позволяет увидеть, насколько переналадка и паузы влияют на небольшой объем.

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

Один красивый демонстрационный цикл не описывает производство

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

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

Не обязательно сразу сводить все к одному среднему. Сначала разделите:

• стабильные повторяемые циклы;
• циклы с блокирующим ожиданием;
• циклы после переналадки;
• циклы с ручным вмешательством;
• циклы в другом состоянии буфера или следующей операции.

Только после такого разделения среднее значение становится понятным: видно, какие состояния оно смешивает.

Для цифрового мониторинга логика та же. ABB OptiFact, например, отдельно показывает тренды Cycle Time и Event Logs; это полезное напоминание, что одна временная метрика без контекста событий не объясняет причину изменения.

Граница ячейки заканчивается там, где следующая операция перестает ее блокировать

Нужно заранее договориться, что именно измеряется: внутренний цикл робота, цикл отдельной технологической машины, полная роботизированная ячейка или пропускная способность более крупной линии.

Если робот кладет деталь в буфер и этот буфер почти всегда имеет свободное место, более медленная следующая операция может не менять внутренний цикл ячейки — по крайней мере пока буфер не заполнился.

Но когда готовую деталь некуда передать, ограничение следующей операции входит в критический путь. Тогда корректно говорить не «робот стал медленнее», а «ячейка заблокирована следующим ресурсом».

Это особенно важно при сравнении демонстрационного цикла с реальным участком. На отдельном тесте выходная тара может быть пустой, заготовки — всегда готовыми, а оператор — постоянно рядом. В производстве эти условия могут меняться, и хронометраж должен показывать их отдельными состояниями, а не скрывать одним коэффициентом.

Симуляция и реальный хронометраж отвечают на разные вопросы

Офлайн-симуляция полезна еще до запуска ячейки: она позволяет сравнивать траектории, последовательности и проектные варианты. Fronius Pathfinder, например, прямо включает определение времени цикла и моделирование последовательности роботизированной сварки.

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

Поэтому сильная проверка имеет два слоя:

1. проектная временная модель — что должно выполняться последовательно, что может перекрываться и какие зависимости заложены в архитектуру; 2. фактический хронометраж — происходит ли это перекрытие на реальной системе и какие дополнительные блокирующие состояния возникают в производстве.

Расхождение между ними само по себе не означает ошибку интегратора или оборудования. Сначала нужно найти конкретный интервал, которого нет в проектной модели или который в реальности оказался длиннее из-за другого условия.

Практический порядок анализа

Чтобы получить полезную модель, не нужна сложная система аналитики. Достаточно пройти последовательность:

1. Определить повторяемое событие начала и конца цикла. 2. Нарисовать отдельные временные дорожки для робота, основного процесса, оператора и критических буферов. 3. Записать фактические начало и конец каждого действия. 4. Отметить, какое действие блокирует следующее повторение. 5. Отдельно отметить реально подтвержденное перекрытие. 6. Каждое ожидание подписать причиной. 7. Переналадку вынести за пределы стабильного повторяемого цикла. 8. Проверить несколько состояний: нормальный поток, другая деталь/партия, заполненный или пустой буфер, участие оператора — только те, которые реально встречаются в вашем производстве. 9. Сравнивать улучшения не по тому, «насколько быстрее движется робот», а по тому, насколько сокращается самая длинная неперекрывающаяся цепочка или исчезает конкретное блокирующее ожидание.

Если нужна простая фактическая проверка без восстановления всех микродействий, можно использовать сами граничные события:

`T_цикла,k = t_начало,k+1 − t_начало,k`

где `t_начало` — одно и то же повторяемое событие для соседних циклов.

А для пропускной способности за реальное окно наблюдения:

`Q = N_годных_деталей / T_наблюдения`

Здесь важно не подменять метрики. `T_цикла` помогает разбирать механику одного повторения, а `Q` показывает фактический выпуск за календарь, в который в зависимости от выбранного окна уже могут входить ожидания, блокировки и переналадки.

Какие данные стоит принести на разговор о роботизации

Для предметного обсуждения не нужен «идеальный OEE». Намного полезнее:

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