Що таке промислова модель даних

Фабрика може збирати величезні обсяги даних і все одно мати труднощі з відповіддю на базове операційне запитання: на що саме впливає ця подія?

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

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

БАГАТО СИСТЕМ — НЕМАЄ СПІЛЬНОГО ЗМІСТУ
Сучасне підприємство вже має спеціалізовані системи майже для кожного важливого завдання. ERP керує попитом і зобов'язаннями. MES керує виконанням. ПЛК управляють обладнанням. SCADA відображає стан машин. Історики зберігають технологічні дані. Системи технічного обслуговування керують активами та сервісними роботами. Системи якості ведуть записи контролю, а Power BI може об'єднувати інформацію для звітності.

Кожна система існує з певною метою. Проблема починається тоді, коли один і той самий реальний об'єкт виглядає по-різному в кожній з них. Верстат може бути представлений як робочий центр в ERP, як номер активу в системі обслуговування, як ресурс в MES, як група вузлів OPC UA у системі керування і як зовсім інша зрозуміла назва на виробничій ділянці.

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

ЩО НАСПРАВДІ ЯВЛЯЄ СОБОЮ ПРОМИСЛОВА МОДЕЛЬ ДАНИХ
Промислова модель даних — це спільний набір правил, що описує, що важливо на фабриці і як ці речі пов'язані між собою.

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

Модель може описувати:
• Типи об'єктів та їхню ідентичність
• Властивості та стани
• Зв'язки між об'єктами фабрики
• Посилання на вихідні системи
• Дати дії та версії
• Умови, прикріплені до зв'язків
• Власників визначень і правил

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

МОДЕЛЬ — НЕ ЦЕ ПЛАТФОРМА ДАНИХ
Microsoft Fabric, SQL-бази даних, історики, озера даних та інші платформи корисні для зберігання, переміщення, управління та аналізу інформації. Але жодна з них не може визначити, що означає робочий центр на вашій фабриці, лише тому, що записи зберігаються разом.

Ви можете завантажити замовлення з ERP, результати виконання з MES, події обслуговування, результати якості та дані телеметрії верстатів в одне Lakehouse і все ж не мати змоги відповісти, чи може конкретне замовлення перейти на інший верстат до кінця зміни.
Ця відповідь залежить від зв'язків.

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

ЧОМУ ЛИШЕ ТАБЛИЦІ ЧАСТО СТАЮТЬ ПРОБЛЕМОЮ
Реляційні таблиці самі по собі не є проблемою. ERP, MES, системи обслуговування та багато виробничих застосунків спираються на реляційні моделі, бо вони чудово підходять для транзакцій і структурованих записів.

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

Усе це можна подати в таблицях, але логіка часто розпорошується між звітами, SQL-запитами, електронними таблицями та локальними списками винятків. Різні звіти потім по-різному відтворюють ті самі зв'язки фабрики.

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

PPR — ПРОДУКТ, ПРОЦЕС, РЕСУРС

Практична стартова структура — PPR: Product, Process, Resource (Продукт, Процес, Ресурс).
Продукт відповідає на запитання: що ми виготовляємо?
Процес відповідає: як має відбуватися робота?
Ресурс відповідає: що може виконувати цю роботу за реальних виробничих умов?

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

ПРОДУКТ — ЦЕ БІЛЬШЕ, НІЖ НОМЕР ДЕТАЛІ
Визначення продукту може включати сімейство продукту, конкретний варіант, ревізію, специфікацію матеріалів, конфігурацію для клієнта, вимоги до матеріалів, вимоги контролю та правила якості.
Це важливо, бо два записи з однаковим загальним номером деталі можуть не бути взаємозамінними. Нова ревізія може вимагати жорсткіших допусків, інших параметрів процесу, додаткового кроку контролю або обладнання з вищою здатністю.

Інженерні системи, такі як PLM, можуть володіти задумом конструкції. ERP може зберігати майстер-дані матеріалів і версію планування. MES може мати виробниче визначення. Якість може підтримувати план контролю.
Промислова модель з'єднує ці посилання, тож виробництво може відповісти на набагато важливіше запитання, ніж «який це номер деталі?»

Вона може відповісти: чи виготовляємо ми правильну ревізію за правилами, що наразі діють?

ПРОЦЕС ВИЗНАЧАЄ, ЯК МАЄ ВІДБУВАТИСЯ РОБОТА
Процесна сторона описує схвалений маршрут через виробництво. Вона охоплює більше, ніж перелік верстатів.

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

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

РЕСУРС ОЗНАЧАЄ МОЖЛИВІСТЬ — А НЕ ЛИШЕ ВЕРСТАТ
Виробничим ресурсом може бути верстат, лінія, робоче місце, інструмент, пристосування, оператор, випробувальний стенд, транспортна система або інша можливість, необхідна для виконання роботи.
Це розрізнення критично важливе, бо верстат може технічно бути доступним, тоді як операція залишається неможливою.

Потрібне пристосування може використовуватися деінде. Інструмент може бути з простроченою калібровкою. Єдиний кваліфікований оператор може не бути на поточній зміні. Верстат може підтримувати сімейство продукту, але не поточну ревізію.