Компьютерное зрение на производстве — как запустить пилот ОТК, СИЗ и поиска дефектов

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

Начинайте с одной наблюдаемой операции

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

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

Второй — есть момент принятия решения. В ОТК это может быть участок перед запрессовкой, упаковкой или передачей на следующую операцию. Для СИЗ — проход в опасную зону или начало работ на конкретном участке. Для дефектоскопии — точка, где изделие ещё можно отправить на доработку без разборки следующего узла.

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

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

Что фиксировать	Пример для ОТК или СИЗ
Объект наблюдения	Манжета на поршне, каска в зоне прохода, край сварного шва
Событие	Неверный угол установки, отсутствие каски, видимый дефект
Точка контроля	До запрессовки, на входе в участок, после операции сварки
Действие по сигналу	Переустановить, остановить проход и проверить, направить на ОТК
Владелец решения	Мастер участка, начальник ОТК, инженер по охране труда

Формулировка «контролировать качество сборки» слишком широкая. Формулировка «до запрессовки определить перевёрнутую манжету на детали одного типа и включить красный сигнал» уже подходит для пилота. Модель не обязана понимать весь цех. Ей нужно надёжно увидеть один признак в заранее определённой зоне.

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

До запуска посчитайте, что именно должно окупиться

У компьютерного зрения есть две независимые экономики.

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

Вторая — экономика контроля. Сколько времени уходит на ручную проверку, сколько объектов проходит через точку контроля, как часто контролёр отвлекается, сколько ложных сигналов готов обработать оператор. Иногда основная польза заключается в том, что ОТК получает цифровой журнал проверок и перестаёт искать фотографии по личным телефонам и папкам.

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

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

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

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

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

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

До съёмки полезно закрепить положение камеры, расстояние до объекта, область интереса, освещение и способ запуска кадра. Стабильная картинка уменьшает объём данных и упрощает поддержку. Пытаться компенсировать постоянно прыгающую камеру обучением модели обычно дороже, чем нормально закрепить камеру и свет.

Разметка начинается с классификации событий. Для ОТК лучше заранее определить, какие варианты считаются годными, какие относятся к браку, а какие нужно отнести в категорию «не уверен». Для СИЗ отдельно размечают человека в зоне, наличие конкретного средства защиты и ситуацию, где объект закрыт, виден частично или распознать его нельзя.

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

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

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

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

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

Кто отвечает за пилот

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

Роль	Зона ответственности
Владелец процесса	Выбирает операцию, подтверждает действие по сигналу и оценивает эффект
Эксперт предметной области	Определяет норму, брак и спорные случаи при разметке
ИТ и автоматизация	Проверяют контур, сеть, вычислительное оборудование и интеграцию журнала
Оператор или контролёр	Работает с сигналом, фиксирует ложные срабатывания и проблемы интерфейса

Руководителю производства полезно назначить одного владельца со стороны участка. Иначе поставщик показывает метрики, ИТ отвечает за сервер, ОТК ждёт готового результата, а фактическая операция остаётся без хозяина. У владельца должна быть возможность изменить процесс пилота, если красный сигнал появляется поздно, его не видно с рабочего места или оператору непонятно дальнейшее действие.

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

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

Пилотируйте процесс, а не только модель

Пилот разумно вести в два режима.

Сначала система работает в тени. Она получает изображение и выдаёт результат, но не влияет на производство. Оператор или контролёр параллельно фиксирует фактический результат. Так можно увидеть реальные ложные сигналы, пропуски и условия, в которых модель теряет объект.

Затем сигнал включают в процесс на одном участке. Для ОТК это может быть световая колонна и экран с последним кадром. Для СИЗ — уведомление мастеру о необходимости проверить конкретную зону. Для поиска дефекта — создание записи на повторный контроль. Система должна подсказывать действие, а не заставлять сотрудника догадываться, что означал красный прямоугольник на видео.

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

Нужен и владелец спорных случаев. Это не разработчик и не камера. В ОТК им обычно становится технолог или контролёр, в вопросах СИЗ — инженер по охране труда или назначенный руководитель участка. Он просматривает ошибки, уточняет правила разметки и принимает решение, является ли проблема в модели, в камере, в процессе или в самой исходной инструкции.

Подход совпадает с рекомендациями NIST AI RMF. Рамка предлагает проверять ИИ-системы до запуска и во время эксплуатации, документировать тестовые наборы и метрики, а также измерять работу в условиях, похожих на реальные.

Измеряйте качество так, как измеряется риск участка

Одна цифра «точность 98 процентов» для пилота почти бесполезна. На участке, где 98 деталей из 100 годные, система, которая всегда говорит «всё нормально», тоже покажет 98 процентов точности и пропустит каждый дефект.

Для ОТК и поиска дефектов важнее как минимум четыре показателя.

Метрика	Что показывает	Зачем нужна
Полнота	Какую долю реальных нарушений заметила система	Показывает риск пропуска дефекта
Точность сигнала	Какая доля тревог подтвердилась человеком	Показывает нагрузку от ложных срабатываний
Время реакции	Сколько проходит от появления объекта до сигнала	Проверяет, успевает ли процесс отреагировать
Доля спорных кадров	Сколько случаев потребовало ручной оценки	Показывает границу применимости модели

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

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

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

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

Сигнал должен встраиваться в существующий маршрут детали

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

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

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

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

Когда компьютерное зрение не окупится

Остановить пилот — нормальный результат, если он даёт доказательство, что именно эта задача не подходит для автоматизации.

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

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

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

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

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

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

Какой результат должен остаться после пилота

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

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