AI-контроль візуальних дефектів (машинний зір)

AI visual defect inspection замінює ручний візуальний контроль на автоматичний аналіз кадрів з виробничої лінії. Система підключається до наявних камер QA-поста або встановлюється новими модулями над конвеєром. Кожен виріб проходить через кадр — модель комп'ютерного зору класифікує його як придатний або бракований, відзначає координати дефекту та передає сигнал до PLC, SCADA або системи моніторингу.

Що відбувається на практиці

1. Камера фіксованого ракурсу знімає кожен виріб у контрольній точці лінії.
2. Пайплайн препроцесингу нормалізує кадр: коригує експозицію, ракурс, масштабує до роздільної здатності моделі.
3. Модель комп'ютерного зору класифікує виріб: тип дефекту, впевненість, bounding box з координатами.
4. Результат звіряється з rubric: які дефекти допустимі для даної партії, клієнта, специфікації.
5. При браку система надає сигнал PLC на наступну станцію — механічне відбракування, позначка, зупинка лінії.
6. Метрики записуються в observability-стек: зміна, оператор, партія, тип дефекту, координати.
7. При сплеску частки браку вище контрольного порогу кидається алерт у месенджер команди або систему тікетів.
8. Всі зображення та вердикти архівуються — слугують аудит-слідом для претензій клієнтів та донавчання моделі.

Чого система не робить

• Не замінює фінальний контроль регламентованих виробів (медтех, авіація, харчова продукція високого ризику). AI дає первинний сигнал, людина підтверджує critical-деталі та ставить підпис.
• Не виявляє типи дефектів, яких не було у навчальній вибірці. Нові класи потребують донавчання та нових розмічених прикладів, що поповнюють датасет.
• Не усуває причини браку. Система виловлює дефект на виході, але root cause analysis залишається на технологах та process engineering.

Система будується з чотирьох підсистем: захоплення зображення, інференс моделі, прийняття рішення, інтеграція з виробництвом. Кожна підсистема критична — слабка ланка зводить ефект цілого до нуля.

Технічний пайплайн

На рівні даних усе починається з камери. Промислова камера з відповідною роздільною здатністю встановлюється над конвеєром або на роботі-маніпуляторі. До неї підводиться контрольоване освітлення: дифузне, коаксіальне, структуроване або UV — вибір залежить від типу дефекту. Тригер кадру надходить від датчика позиції виробу або таймера лінії.

Захоплений кадр потрапляє в edge-інференс-сервер (GPU-машина поруч з лінією) або в хмарний ендпоінт, якщо мережа стабільна і допустима потрібна латентність. Модель складається з двох голів: класифікація (придатне / непридатне) і детекція (локалізація дефекту з bounding box). Під кожен клас дефекту збирається розмічений набір зображень і навчається згорткова нейромережа або vision transformer.

Результат інференсу формалізується в JSON: id виробу, тип дефекту, впевненість, координати, timestamp. Далі — rubric-рушій: правила «який рівень дефекту допустимий» по партії, клієнту, ревізії креслення. Вердикт потрапляє в PLC через промисловий протокол (OPC UA, MQTT) і одночасно в observability-стек, де будуються дашборди по частках браку, хибним спрацюванням і дрейфу моделі.

Кроки впровадження

1. Аудит лінії: де встановити камери, яке освітлення потрібне, скільки контрольних точок, яка латентність допустима.
2. Збір і розмітка даних: розмічена вибірка на кожен клас дефекту, балансування придатних і бракованих виробів, узгодження rubric з QA-відділом.
3. Навчання baseline-моделі: transfer learning від попередньо навченої CV-моделі, валідація на hold-out вибірці.
4. Пілот на одній лінії: паралельна робота з ручним контролем, збір метрик precision/recall, калібрування порогів.
5. Інтеграція з PLC і MES: підписка на тригер, відправка вердикту, автоматичне відбракування.
6. Налаштування observability: дашборди, алерти по зростанню FP/FN, метрики дрейфу моделі по зміні, партії, сезону.
7. Регламент перенавчання: хто розмічає нові помилкові кейси, з якою періодичністю модель оновлюється, як відкотити до попередньої версії.

Типові компоненти

Основне джерело помилок — не модель, а залізо. Відблиск, зсув камери на міліметр, зміна партії плівки на освітленні ламають модель швидше, ніж зміни у виробі. Тому контроль дрейфу — обов'язковий модуль, а не nice-to-have.

Для запуску потрібні три групи передумов: техніка, дані, команда.

Технічна частина:

• Промислова камера з достатньою роздільною здатністю та стабільним кріпленням над контрольною точкою.
• Контрольоване освітлення під тип дефекту (дифузне, коаксіальне, структуроване).
• Edge-сервер з GPU поряд із лінією або стабільний канал до хмарного ендпоінта з допустимою латентністю.
• Доступ до PLC або MES через промисловий протокол (OPC UA, MQTT) або REST для передачі вердиктів.
• Мережа між камерою, сервером інференсу та системою моніторингу.

Дані:

• Розмічена вибірка зображень на кожний клас дефекту з балансом придатних та бракованих зразків.
• Узгоджений rubric: які дефекти допустимі, які — ні, як залежить від партії та клієнта.
• Вибірка edge-cases: рідкісні дефекти та граничні випадки, які пропускає оператор ручного контролю.

Команда:

• QA-інженер, який відповідає за rubric і працює в парі з розмітниками.
• Process engineer, який знає лінію та може виділити вікна для пілота без зупинки виробництва.
• IT / OT-спеціаліст для інтеграції з PLC, MES та observability.
• Data engineer або ML-інженер для навчання та підтримки моделі (власний або підрядник).

Терміни: впровадження середнього сценарію — 6–10 тижнів від аудиту до промислової експлуатації на одній лінії. Масштабування на сусідні лінії займає кілька тижнів на лінію при схожій геометрії та освітленні.