Індустрія 4.0 та Індустрія 5.0 у цеху: що змінюється насправді

Ця стаття побудована навпаки: від верстата й оператора назовні.

Що Індустрія 4.0 означає в цеху

Якщо прибрати термінологію, Індустрія 4.0 зводиться до одного зсуву: від обладнання, яке не повідомляє нічого, до обладнання, дані якого доходять до рішення.

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

На заводі, де зсув відбувся, зупинку фіксують із PLC за секунди, оператор класифікує причину просто біля верстата, поки її ще видно, система планування бачить, що операція не вкладеться у своє вікно, і наступне замовлення переставляють у черзі або притримують матеріал. Та сама подія тепер має наслідок.

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

Оцифрування теж не те саме. Якщо замінити паперове змінне завдання на PDF, зникне принтер. Затримка залишиться. Індустрія 4.0 починається там, де дані структуровані, мають мітку часу і прив'язані до замовлення, верстата, оснастки й оператора: тільки тоді з ними може щось порахувати наступна ланка.

Рівні системи і місце кожного з них

Більшість суперечок про Індустрію 4.0 виникає тому, що співрозмовники говорять про різні рівні. ISA-95 дає придатний словник, щоб їх розрізняти.

Сигнали обладнання: датчики, PLC, шлюзи. На реальному заводі цей рівень строкатий. Частина верстатів розмовляє OPC UA, а старші знають лише Modbus, послідовний протокол або сухий контакт. Закриті контролери, які постачальник не відкриває, потребують ретрофіт-датчика на шпинделі, гідравлічному контурі чи силовій лінії. Єдиного протоколу не буде, тож закладайте в бюджет ту вперту меншість активів, яку доведеться інструментувати ззовні. Тут же живуть IIoT-шлюзи, а також RTLS, коли треба знати, де візок, прес-форма чи партія перебувають фізично, а не за документами.

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

MES: виконання. Тут цехом керують насправді: видача завдань на дільниці, підтвердження операцій, облік машинного й трудового часу, фіксація браку та переробок із причинами, дотримання маршруту й налагодження, а також простежуваність, яка дозволяє пройти партію назад. На тому самому потоці подій тримаються перевірки якості (QMS), тригери обслуговування (CMMS) і рухи матеріалу (WMS). MES — це система-джерело істини про те, що сталося в цеху. Аналітику можна перебудувати згодом, запис події відновити не вдасться.

Планування: MRP, APS, SCP. MRP та ERP відповідають, що виготовляти і приблизно коли, з роздільністю в дні. APS шикує послідовність під скінченну потужність і ті обмеження, які справді тиснуть: спільна оснастка, родини переналагоджень, атестовані оператори, час сушіння чи витримки. SCP дивиться далі, через постачальників і майданчики. Якість планування впирається у зворотний зв'язок від виконання: план зі скінченною потужністю, побудований на нормативах, яких роками ніхто не переміряв, уже за день переплановуватимуть вручну.

Аналітика, AI/ML і комп'ютерний зір. Цей рівень лежить зверху і без рівнів під ним вартий небагато. Саме з ними пов'язана значна частина цінності: комп'ютерний зір для поверхневих дефектів, перевірки наявності елементів і контролю етикеток, де камера стабільніша за око наприкінці довгої зміни; AI/ML для виявлення аномалій у вібраційних чи енергетичних сигнатурах. Сюди ж належить енергомоніторинг, і корисним він стає тоді, коли споживання прив'язують до випуску. Тоді енергію на деталь можна порівнювати між змінами й верстатами.

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

Що додає Індустрія 5.0 і чого не можна купити

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

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

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

Енергія, виміряна на замовлення й на верстат, щоб зміну технології можна було оцінити і за тактом, і за споживанням.

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

Простежуваність, якої вистачає на точкове відкликання замість списання всієї партії.

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

З чого починати і як не купити платформу, якою ніхто не користується

Справжнє питання стосується послідовності: цифрова трансформація виробництва зривається на порядку кроків. Робочий порядок такий.

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

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

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

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

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

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

Що йде не так

Дані, яким ніхто не вірить. Дві системи показують різні числа за одну й ту саму зміну, і виробнича нарада перетворюється на суперечку про цифру, а втрата за нею лишається без обговорення. Ліки неефектні: до розгортання письмово узгодити одне визначення кожного KPI (зокрема те, як OEE трактує планові простої та переробки) і назвати одну систему-джерело істини.

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

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

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

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

Як відрізнити справжній проєкт від проєкту заради дашбордів

З дашбордами все гаразд. Вони видима частина, і якщо вони і є все, то ви купили дзеркало. Розрізнити допомагають шість питань.

1. Чи спричиняє якесь число дію, чи воно лише змушує людину щось помітити? 2. Дані знімаються в момент і в місці події, чи їх передруковують пізніше з нотаток? 3. Коли змінюється цех, чи змінюється план, чи він лишається таким, як надрукований, поки реальність відходить убік? 4. Чи є система-джерело істини про те, що сталося, чи лише вітрина над іншими системами? 5. Чи переживе рішення звільнення людини, яка його зробила? Залежність від однієї підтримуваної вручну таблиці є попереджувальним сигналом. 6. Що станеться, коли на годину зникне мережа: периферія буферизує й доузгодить дані, чи зміну втрачено?

Якщо чесно відповідаєте «помітити», «передруковують», «лишається як надрукований» і «лише вітрина», то це проєкт звітності. Звітність корисна. Але це не той зсув, з якого починається ця стаття.

Де тут Meta Smart Factory

Meta Smart Factory — модульна платформа, що покриває описані вище рівні: MES, APS і MRP, SCP, WMS і логістика, якість (QMS), обслуговування (CMMS), комп'ютерний зір, AI/ML, енергія, IIoT-обладнання, RTLS та інтеграція з ERP, з розгортанням на власних потужностях або як SaaS.

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

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