Як тільки ідея цифрового паспорта продукту набуває конкретних обрисів, ІТ-відділ ставить питання, яке випереджає всі інші: до яких із наших систем повинна мати доступ ця платформа? Це правильне питання, адже за ним стоять дані доступу, налаштування брандмауера та концепція безпеки, за яку хтось повинен нести відповідальність.
Наша відповідь коротка: жодна. Усі системи, що надають дані для паспорта, знаходяться на стороні джерела і залишаються там. 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, ідентифікатор версії, статус публікації та повідомлення про валідацію. Для сторінки-джерела ці підтвердження є цінними, оскільки посилання на pass можна зберегти в ERP або PIM безпосередньо біля товару. Вони не є доступом. Вони є підтвердженням отримання поставки.
Три моделі, що добре зарекомендували себе на практиці
- Прямо з провідної системи. ERP або PLM надсилає дані через коннектор. Просто та доцільно, коли одне джерело даних явно домінує.
- Через агрегаційний рівень. Проміжне програмне забезпечення (middleware) або iPaaS об’єднує поля ERP, MES та PIM і надає пакет даних. Це типовий випадок, коли задіяно кілька джерел.
- Через підмоделі AAS. Адміністративна оболонка вже використовується, а пакет формується на основі її підмоделей. Це вигідно в середовищах Індустрії 4.0.
Яка модель підходить до якої системної архітектури та як такий проєкт можна реалізувати за два тижні замість трьох місяців, ми описали в Посібнику з підключення до ERP.
Чим Transpareo свідомо не є
Це не друга «система обліку» (System of Record). Платформа зберігає запис про паспорт та його незмінну історію версій, а не оперативні дані виробника. Те, що виправляється в ERP, надходить до паспорта через нову поставку - як нова, простежувана версія, а не як прихована зміна в існуючому записі. Як цей ланцюжок версій підписується та стає доступним для перевірки кожним, описано у статті про підписи та сертифікати.
Таким чином, у рамках вашої концепції безпеки залишається мало чого перевіряти, і саме в цьому полягає мета. Ви не надаєте жодних даних для доступу, не відкриваєте внутрішні порти брандмауера і не підключаєте сторонні системи з правами на читання до вашої ERP-системи. Справжня робота над проєктом переноситься туди, де їй і належить бути: вирішувати, які поля мають бути включені до «паспорта», а не хто і де має право входити в систему.