Як тільки концепція цифрового паспорта продукту набуває конкретних обрисів, ІТ-відділ ставить питання, яке випереджає всі інші: до яких із наших систем має звертатися ця платформа? Це правильне питання, адже за ним стоять дані доступу, налаштування брандмауера та концепція безпеки, за яку хтось має нести відповідальність.
Наша відповідь коротка: жодна. Усі системи, які надають дані для паспорта, знаходяться на стороні джерела і залишаються там. Transpareo є виключно одержувачем на кінці ланцюга; потоки даних надходять на платформу в односторонньому напрямку. У цій статті простежуються ці потоки: що надає кожна система, які правила діють для кожного потоку та що повертається у вигляді підтвердження.
Що кожна система вносить у паспорт
Дані паспорта рідко походять з однієї системи. На практиці вони розподіляються між кількома класами систем, кожна з яких надає лише кілька полів:
- ERP - ідентифікатор товару, матеріали, постачальники та походження, зв’язок із замовленням і партією, кількості. Стабільні базові дані, які рідко змінюються.
- MES - історія виробництва, прив’язка до серії та партії, підтвердження якості, простежуваність. Дані про події, прив’язані до конкретного моменту часу.
- APS - терміни виробництва та розподіл ресурсів. Рідко мають безпосереднє значення для паспорта; найважливіша інформація зазвичай надходить через MES.
- PLM - склад, специфікації, можливість ремонту, запасні частини, стан проектування. З огляду на вимоги Регламенту про екодизайн, це найвичерпніше джерело.
- PIM - описи, зображення, інструкції з догляду та використання, мовні версії. Контент, орієнтований на споживача.
- IoT - дані про стан та використання на етапі експлуатації. Потрібні лише для певних груп товарів, наприклад, для акумуляторів.
- CRM - історія обслуговування та ремонту окремих клієнтів. Як правило, це персональні дані, тому вони не повинні міститися у публічному паспорті.
Адміністративна оболонка стоїть над системами, а не поруч із ними
Одне розмежування важливіше за всі інші: Asset Administration Shell ## нестоїть## поруч ізERP, MES та PIM, а над ними. Вона не генерує даних, а інкапсулює наявні в сумісні підмоделі. Для підключення до Transpareo це означає: AAS - це зручний, але не обов’язковий формат передачі даних. Хто її використовує, той отримує пакет даних із своїх підмоделей; хто ні - надає ті самі поля іншим шляхом. Чому ми все одно вважаємо «Адміністративну оболонку» чудовою основою, описано у статті про AAS.
П’ять правил, що діють для кожного потоку
Напрямок. Усі стрілки вказують на платформу. Transpareo не запитує дані з жодної вихідної системи, і Transpareo не має даних доступу до ERP, MES, PIM або PLM.
Немає жодного з’єднання з вашими системами, яке потрібно було б захищати, оскільки його просто не існує.
Тригер. Ініціатива завжди надходить із боку джерела - від самого виробника, його проміжного програмного забезпечення або уповноваженого постачальника послуг. Платформа очікує; вона не здійснює запит.
Цільове призначення. Передається виключно та частина даних, яка необхідна для «паспорта», а не весь масив даних джерельної системи. «Паспорту» від кожної системи потрібно лише кілька полів; все інше залишається на місці.
Звільнення. Вибір, обсяг та час кожного пакета даних визначає джерельна сторона. Transpareo не може отримати більше, ніж було надано.
Повноваження. Що можна робити з наданими даними на платформі, регулюють визначені права доступу: мінімальні права, а те, що не дозволено прямо, залишається забороненим. Ці правила діють на стороні платформи, ніколи не мають зворотної дії щодо джерела.
У зворотному напрямку передаються лише підтвердження
Повністю обійтися без зворотного каналу неможливо, але він передає не дані, а відповіді: URL-адресу DPP або GS1 Digital Link, ідентифікатор версії, статус публікації та повідомлення про валідацію. Для сторони-джерела ці відповіді є цінними, оскільки посилання на підтвердження можна зберегти в ERP або PIM безпосередньо біля товару. Вони не є доступом. Вони є підтвердженням отримання поставки.
Три моделі, що добре зарекомендували себе на практиці
- Прямо з головної системи. ERP або PLM надсилає дані через коннектор. Просто й доцільно, коли одне джерело даних явно домінує.
- Через агрегаційний рівень. Проміжне програмне забезпечення або iPaaS об’єднує поля ERP, MES та PIM і надає пакет даних. Це типовий випадок, коли задіяно кілька джерел.
- Через підмоделі AAS. Адміністративна оболонка вже використовується, а пакет формується на основі її підмоделей. Це вигідно в середовищах Індустрії 4.0.
Яка модель підходить до якої системної архітектури та як такий проєкт можна реалізувати за два тижні замість трьох місяців, ми описали в посібнику з підключення до ERP.
Чим Transpareo свідомо не є
Не ## єдругою «системою обліку» (System of Record). Платформа зберігає запис про сертифікат та його незмінну історію версій, а не оперативні дані виробника. Те, що виправляється в ERP, надходить у «Pass» через нову поставку - як нова, простежувана версія, а не як прихована зміна в існуючих даних. Про те, як цей ланцюжок версій підписується та стає доступним для перевірки кожним, йдеться у статті про підписи та сертифікати.
Таким чином, у вашій концепції безпеки залишається мало чого перевіряти, і саме в цьому полягає мета. Немає жодних даних доступу, які ви надаєте, жодних отворів у брандмауері всередину та жодної сторонньої системи з правами на читання у вашій ERP-системі.
Власне проектна робота переміщується туди, де їй і належить бути: вирішувати, які поля мають бути в паспорті, - а не те, хто і де може входити в систему.
Питання щодо цього допису
Чи потрібен Transpareo доступ до нашої ERP-системи або іншої системи?
Ні. Кожна система, яка надає дані, розташована на стороні джерела і залишається там, а Transpareo не має даних для доступу до ERP, MES, PIM чи PLM. Не існує жодного з’єднання з вашими системами, яке б потрібно було захищати, оскільки його просто немає. Отже, у рамках вашої концепції безпеки не потрібно надавати жодних даних доступу, створювати жодних внутрішніх шлюзів та перевіряти жодних сторонніх систем із правами на читання у вашій ERP-системі.
Хто ініціює доставку і як часто?
Завжди сторона-джерело. Пуш-повідомлення ініціюється самим виробником, його проміжним програмним забезпеченням або уповноваженим постачальником послуг; платформа лише очікує і ніколи не запитує дані. Вибір, обсяг та час надсилання кожного пакету визначає сторона-джерело, тому Transpareo не може отримати більше, ніж було надано. Як часто ви надсилаєте дані, ви визначаєте самі - стабільні базові дані змінюються рідко, а виробничі події відбуваються тоді, коли вони відбуваються.
Чи потрібна для цього адміністративна оболонка?
Ні. Адміністративна оболонка не існує поряд з ERP, MES та PIM, а стоїть над ними, і вона не генерує власних даних, а інкапсулює наявні в сумісні підмоделі. Таким чином, це зручний, але не обов’язковий формат надання даних. Ті, хто її використовує, отримують пакет даних із її підмоделей. Хто її не використовує, той надає ті самі поля іншим шляхом - безпосередньо з головної системи або через рівень агрегації.
З якої системи почнемо?
З огляду на вимоги Регламенту про екодизайн, PLM є найповнішим окремим джерелом інформації - саме там містяться склад, специфікації, інформація про можливість ремонту, запасні частини та стан розробки. Система ERP забезпечує управління ідентифікацією товарів, матеріалами, постачальниками та походженням, система PIM - текстами та зображеннями для споживачів, а система MES - подіями, пов’язаними з виробництвом та простежуваністю. Для більшості паспортів з кожної системи потрібно лише кілька полів. Почніть з тих полів, яких у вас найбільше, а решту доповнюйте поступово.
Чи потрапляють дані клієнтів із CRM у паспорт?
Ні. Історія обслуговування та ремонту окремих клієнтів, як правило, має особистий характер і тому не повинна включатися до публічного профілю. CRM - це єдиний клас систем у цьому списку, який повністю залишається поза ним. Події, пов’язані з ремонтом та життєвим циклом, все ж можна відображати, але як події, пов’язані з продуктом, а не з конкретною особою.
Що повертається з платформи?
Підтвердження, а не дані. Зворотний канал передає адресу DPP або GS1 Digital Link, ідентифікатор версії, статус публікації та повідомлення про перевірку. Ці підтвердження варто зберігати, оскільки за ними можна безпосередньо відстежити посилання на товар у системі ERP або PIM. Вони не є запитом, а підтвердженням отримання поставки.
Що відбувається, коли значення в системі ERP виправляється?
Виправлення надходить до системи через нову поставку і стає новою, простежуваною версією, а не прихованою зміною в існуючій версії. Кожна попередня версія залишається доступною для перегляду та перевірки, і саме це робить історію версій цінною для аудиту. Про те, як цей ланцюжок версій підписується та стає перевіреним для кожного, йдеться в розділі «Підписи та сертифікати» у DPP.
Чи стане Transpareo другою «системою обліку»?
Ні, і це зроблено навмисно. Платформа зберігає набір даних про паспорт та його незмінну історію версій, а не ваші операційні дані; ваші системи залишаються визначальними щодо всього, що їм належить. Таким чином, робота над проєктом залишається там, де їй і належить - у процесі прийняття рішень про те, які поля мають бути включені до «паспорта», а не в питанні, хто і де має право входити в систему.
