Що насправді варто автоматизувати за допомогою ШІ на виробництві

Долю ШІ-проєкту на виробництві здебільшого вирішує зовсім не моделювання. Це вміння назвати, якого типу задачу ви маєте, перевірити, чи витягнуть її ваші виробничі дані, і продумати, що станеться, коли модель помилиться.

Правила, машинне навчання, оптимізація та мовні моделі: що під яку задачу

Правила та статистика йдуть першими і заслуговують на більшу повагу, ніж мають. Якщо правило, яке інженер може записати на аркуші, дає більшу частину вигоди, то будь-яку модель чесно порівнювати саме з цим правилом.

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

Оптимізація — це окрема дисципліна, яку регулярно видають за ШІ. Планування виробництва зі скінченною потужністю, упорядкування послідовності заради мінімуму переналагоджень, призначення кваліфікованих операторів: це задачі з обмеженнями та цільовою функцією. Їм не потрібні розмічені приклади, але потрібні чесні норми часу й обмеження, які зазвичай доводиться спершу виміряти. Для планування майже завжди правильним інструментом є вирішувач, здатний описати ваші реальні обмеження з оснащенням і сушінням, бо планування за природою є задачею з обмеженнями.

Мовні моделі з'явилися останніми, і їхня ніша цілком конкретна. Їм пасує робота, що має форму документа чи розмови: прочитати вхідний запит і скласти з нього структурований, стиснути довгу історію обслуговування до того, що технік встигне прочитати дорогою до верстата, відповісти, що саме написано в робочій інструкції про наладку. Вони не є вимірювальними приладами: просити мовну модель передбачити вихід підшипника з ладу за даними вібрації означає забивати шуруп молотком.

Які дані насправді потрібні ШІ-проєкту на виробництві

Моделі потрібні приклади, у яких ситуація поєднана з результатом, і достатньо контексту, щоб відрізнити одну ситуацію від іншої: сигнал або набір умов, прив'язані до замовлення, верстата, оснастки, партії матеріалу, оператора і до часової позначки, яка є правдивою. Часова позначка важить більше, ніж прийнято думати. Якщо підтвердження вносять заднім числом наприкінці зміни, всі події цієї зміни мають приблизно однаковий час, і все, що залежить від послідовності чи тривалості, вчиться звичці вводити дані, а сам процес лишається поза увагою.

З результатами зазвичай гірше. Предиктивному обслуговуванню потрібні відмови, записані саме як відмови, з причиною та датою. Позаплановий простій із порожнім полем причини не годиться. Прогнозуванню якості потрібен брак, списаний на конкретну операцію та вид дефекту, який його спричинив. Місячна зведена цифра тут не допоможе. Прогнозуванню попиту потрібна історія споживання, яку не переписали тихцем коригуваннями залишків. На більшості підприємств входи живуть в історіані (historian), а результати записані в зошиті ремонтників або в таблиці однієї людини.

Обсяг історіана в гігабайтах тут нічого не каже. Перевірте, чи можете ви вивантажити для однієї лінії та однієї товарної групи річний масив рядків, де кожен рядок несе умови й результат, і чи погодяться двоє людей, які знають процес, що ці рядки правдиві. Якщо таке вивантаження забирає тиждень ручного звіряння, то проєкт насправді стосується обліку. Саме тому якість даних у MES і в історіані є вузьким місцем, і жодна витонченість моделювання не поверне того, що ніколи не фіксували.

Прогнозування попиту та споживання, де окупність найближча

У прогнозування зазвичай найкоротший шлях до грошей, бо альтернатива помітно слабка: більшість підприємств беруть минулий рік і додають відсоток або питають у продажів цифру, яка насправді є планом. Модель, що використовує історію замовлень, сезонність, структуру клієнтів, відкриту воронку та календарні ефекти, перемагає такий підхід на позиціях із регулярним, повторюваним попитом. На переривчастих і проєктних позиціях (а це часто більшість номенклатури й невелика частка обсягу) зазвичай не перемагає, і наївний базовий рівень або метод Кростона важко перевершити. Чесний варіант спочатку сегментує номенклатуру й лишає ці позиції політиці запасів та здоровому глузду.

Вигода з'являється далі за потоком: змінюється страховий запас, зсувається час закупівлі позицій із довгим терміном постачання, рідшають аварійні переналагодження, які руйнують розклад. Відсоток точності прогнозу на слайді вигодою не є. Вигоду вимірюють днями запасу і кількістю термінових проштовхувань.

Предиктивне обслуговування, лише там, де вид відмови справді передбачуваний

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

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

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

Прогнозування якості та зменшення браку

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

Це працює, коли процес оснащено вимірюваннями з тією ж роздільністю, що й те, що ви хочете передбачити, і коли брак несе справжній код причини, прив'язаний до операції. І це тихо не спрацьовує, коли брак списують наприкінці замовлення на замовлення загалом, бо тоді модель не може сказати, які умови спричинили який дефект.

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

ШІ для планування виробництва: чому це задача оптимізації

Якщо план зривається щотижня, причина рідко в браку інтелекту і зазвичай у браку обмежень. Змінює справу планувальник, який враховує спільну оснастку, сімейства переналагоджень, кваліфікації операторів, час витримки та вікна обслуговування, які ви збираєтеся дотримати.

Навчання тут допомагає в одному вузькому, але реальному місці: у нормах часу. Розклад, побудований на нормативах, які роками ніхто не перевимірював, точний щодо неправильних чисел, а фактичні тривалості, зібрані через MES, можуть оновити те, чим оперує планувальник. Оцінюйте пропозицію з планування за обмеженнями, які вона здатна описати, і за швидкістю перепланування, коли щось ламається; план, який перераховується цілу ніч, вранці на нараді все одно перепишуть руками.

Виявлення аномалій у сигналах енергоспоживання та процесу

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

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

ШІ у продажах і роботі з клієнтами, де робота має форму документа

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

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

Два правила не дають цьому зіпсуватися. Модель пише чернетку, а надсилає людина, принаймні доки не стане зрозумілою частота помилок у цьому процесі. І все фактичне (ціна, термін постачання, залишок, обіцяна дата) береться з системи-джерела. Модель має цитувати знайдене значення й ніколи його не вигадувати. Автоматизація CRM, яка вигадує термін постачання, гірша за її відсутність, бо вона зобов'язує компанію.

Оцінка виграшу до того, як щось купувати

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

Далі оцініть, песимістично, яку частку цієї втрати рішення реально здатне закрити. Предиктивне обслуговування не усуває простої; у кращому разі воно перетворює частину позапланових зупинок на планові, і лише для тих видів відмов, які охоплює. Модель якості не прибирає брак; вона скорочує час між тим, як процес пішов не так, і тим, як це хтось помітив.

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

Скільки насправді коштує інтеграція

Модель зазвичай є дешевою частиною; вартість живе у стиках. Спочатку треба зняти сигнали з обладнання, а на реальному підприємстві парк різнорідний: одні активи говорять OPC UA, інші Modbus чи послідовним протоколом, деякі дають лише сухий контакт, а закритим контролерам потрібен додатковий датчик на шпинделі, гідравлічному контурі або силовій лінії. Далі результат має кудись потрапити, щоб спричинити дію: на екран, у який оператор і так дивиться, у наряд на обслуговування, в обмеження для планувальника, у блокування за якістю.

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

Хто експлуатує модель і що відбувається, коли вона помиляється

У кожної впровадженої моделі має бути власник із іменем, і закупівельне питання полягає в тому, хто саме у вашій організації ним буде. Ця людина має знати, на чому модель навчена, які умови лежать поза цим, чому вона видала конкретний результат і як вивести її з контуру, не зупиняючи виробництво. Модель, яка перестала відповідати, має відкотитися до того, що керувало процесом до неї (плану вибіркового контролю, порогу, перевірки оператором). Відкриті ворота чи заблокована лінія тут неприйнятні. Вирішіть, що саме це буде, до запуску в промислову експлуатацію.

Пояснюваність у цеху є умовою прийняття. Рекомендація, яка каже, який сигнал зрушив, наскільки і відносно якого базового рівня, доходить до дії. Оцінка без обґрунтування ігнорується, а щойно ігнорування стає звичним, система перетворюється на прикрасу.

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

Врядування, дрейф і тягар супроводу, якого ніхто не закладає в бюджет

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

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

І закладіть у бюджет постійні зусилля. Модель у промисловій експлуатації — це актив, який обслуговують, ближчий до технологічного обладнання, ніж до придбаного звіту. Якщо ні в кого немає виділеного часу на перенавчання, розбір сповіщень і перевірку того, що дані досі надходять, вона деградуватиме, доки нею не перестануть користуватися.

Реалістичний перший проєкт із критеріями приймання

Візьміть одну названу втрату на одній лінії чи одній товарній групі, сформульовану реченням із числом усередині: ми списуємо в брак стільки-то на цій операції, ми втрачаємо стільки-то годин вузького місця через цей верстат, ми тримаємо стільки-то запасу, бо не вміємо прогнозувати цю групу. Якщо проєкт не формулюється так, він не готовий.

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

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

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

Де тут Meta Smart Factory

Meta Smart Factory є модульною, і тут це важливо, бо модуль ШІ та машинного навчання стоїть саме над рівнем виконання. MES дає події й контекст, IIoT-підключення та OPC UA дають сигнали з обладнання, Якість дає брак із причинами, Обслуговування дає історію відмов, а APS споживає результат там, де відповіддю є саме розклад.

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