Індустрія 4.0 та Індустрія 5.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.

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

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