Apollo Tyres скоротила брак на 26% через AI

Причина браку крилась не в устаткуванні, а в самому процесі переналаштування. На заводі Apollo Tyres в Андхра-Прадеш кожна зміна рецептури — через нову модель шини чи заміну оснастки — вимагала, щоб оператор вручну підбирав швидкість лінії, поки протектор і бокова частина не увійдуть у допуски по вазі й ширині. На це йшло 2–3 хвилини, і весь цей матеріал або переробляли, або списували.

Крім прямих втрат матеріалу (5–6% обсягу випуску), ручний режим підвищував енергоспоживання, знижував пропускну спроможність лінії і створював ризики для безпеки — персонал вручну обробляв бракований матеріал. Результат сильно залежав від досвіду конкретного оператора: однакового старту на однаковій рецептурі різні зміни досягали по-різному.

Як влаштована система: два шари, а не один алгоритм

Перший шар — предиктивна edge-модель на Amazon SageMaker. Перед стартом екструзії вона аналізує понад 200 параметрів процесу, рецептуру, склад суміші й умови середовища і одразу видає прогнозовану оптимальну швидкість лінії, яку система записує в PLC (контролер лінії). Оператор бачить це значення на HMI-панелі.

Другий шар вмикається вже під час виробництва. AI-агент на Amazon Bedrock у реальному часі звіряє виміряну вагу протектора і ширину бокової частини з нижніх ваг і датчиків із заданими межами. Якщо профіль матеріалу відхиляється, агент через закритий контур зворотного зв'язку сам коригує швидкість лінії — не чекаючи, поки оператор помітить відхилення.

Передача команд на PLC відбувається через AWS IoT Greengrass — це забезпечує низьку затримку в реагуванні. Дані з датчиків і PLC стікаються через Kinesis у сховище (S3, Redshift), де й тренуються та переоцінюються моделі.

Чому це впровадили як частину системи якості, а не як окремий AI-пілот

Команда цифрових інновацій Apollo Tyres свідомо не запускала проєкт як демонстрацію технології. Рішення вбудували в наявний контур Total Quality Management і Daily Work Management, а розробку вели за фірмовою методологією I5 Agile (Initiate–Inspect–Iterate–Improve–Integrate) зі спринтами й міжфункціональними ревʼю.

Спершу команда застосувала APSA (Analyze–Prioritize–Set Target–Assign): порахували втрати від браку при старті, поставили конкретну ціль зниження на 25% у наступному фінансовому році й призначили відповідальних із виробництва, якості, процесного інжинірингу та цифрової команди. Далі саме впровадження провели за циклом OPDCA:

• Observe — вивчення процесу безпосередньо на дільниці (Gemba) показало, що головне джерело нестабільності — саме ручне регулювання швидкості
• Plan — діаграма Ісікави та аналіз «5 чому» виявили як корінні причини ручний контроль, розкид між операторами й відсутність предиктивної підказки
• Do — паралельно розробили предиктивну модель швидкості та контролер закритого контуру, що стежить за профілем матеріалу
• Check — результат перевірили статистичним порівнянням «до / після» за відсотком браку, часом стабілізації та показником First Time Right
• Act — оформили стандартні операційні процедури, впровадили управління моделлю і почали тиражування на інші лінії екструзії

Межі підходу і що перевірити перед довірою до результату

Систему не запустили одразу в автономному режимі. Спочатку рекомендації моделі підтверджував оператор (Human-in-the-Loop), і лише після того, як довіра до прогнозів підтвердилась на практиці, перейшли до режиму Human-on-the-Loop — автономної корекції під наглядом людини, з запобіжниками безпеки. У компанії відзначають, що саме поетапне нарощування автономності, а не одразу повна автоматизація, забезпечило безпечне впровадження і прийняття персоналом.

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

Матеріал не вказує, скільки часу зайняло впровадження і скільки воно коштувало.