Как только проект «Цифрового паспорта продукта» приобретает конкретные очертания, ИТ-отдел задает вопрос, который стоит выше всех остальных: к каким из наших систем должна подключаться платформа? Это правильный вопрос, ведь за ним стоят учетные данные, настройки брандмауэра и концепция безопасности, за которую кто-то должен нести ответственность.
Наш ответ краток: ни одна. Все системы, которые предоставляют данные для паспорта, находятся на стороне источника и остаются там. Transpareo выступает исключительно в роли получателя в конце цепочки; потоки данных направлены в одну сторону - к платформе. В этой статье прослеживаются эти потоки: что предоставляет каждая система, какие правила действуют для каждого потока и что возвращается в качестве подтверждения.
Что каждая система вносит в паспорт
Данные паспорта редко поступают из одной системы. На практике они распределяются по нескольким классам систем, каждая из которых вносит лишь несколько полей:
- ERP - идентификация артикула, материалы, поставщики и происхождение, привязка к заказам и партиям, количества. Стабильные базовые данные, которые редко меняются.
- MES - история производства, привязка к сериям и партиям, подтверждения качества, прослеживаемость. Данные о событиях, привязанные к конкретному моменту времени.
- APS - сроки производства и распределение ресурсов. Редко имеют прямое отношение к паспорту; важная информация обычно поступает через MES.
- PLM - состав, спецификации, ремонтопригодность, запасные части, версии конструкции. С точки зрения требований Регламента об экодизайне - наиболее исчерпывающий источник.
- PIM - описания, изображения, инструкции по уходу и эксплуатации, языковые версии. Контент, предназначенный для потребителей.
- IoT - данные о состоянии и использовании, полученные на этапе эксплуатации. Востребованы только для определенных групп продуктов, например, для аккумуляторов.
- CRM - история обслуживания и ремонта отдельных клиентов. По сути, это персональные данные, поэтому они не должны входить в общедоступный паспорт.
Административная оболочка находится над системами, а не рядом с ними
Одно разграничение важнее всех остальных: Asset Administration Shell находится не наряду с ERP, MES и PIM, а над ними. Она не генерирует данные, а инкапсулирует существующие в взаимосовместимые подмодели. Для подключения к Transpareo это означает: AAS - удобный, но не обязательный формат предоставления данных. Те, кто использует его, получают пакет данных из своих подмоделей; те, кто не использует, предоставляют те же поля другим способом. Почему мы всё же считаем «административную оболочку» отличной основой, описано в статье об AAS.
Пять правил, действующих для любого потока данных
Направление. Все стрелки указывают на платформу. Transpareo не запрашивает данные из исходных систем и не имеет доступа к ERP, MES, PIM или PLM. Нет никаких подключений к вашим системам, которые необходимо было бы защищать, потому что их просто нет.
Триггер. Инициация передачи данных всегда происходит со стороны источника - самим производителем, его промежуточным программным обеспечением или уполномоченным поставщиком услуг. Платформа находится в режиме ожидания; она не запрашивает данные.
Целевое назначение. Передаётся исключительно подмножество данных, необходимое для «паспорта», а не весь массив данных исходной системы. «Паспорту» требуется лишь несколько полей из каждой системы; всё остальное остаётся на месте.
Разрешение. Выбор, объём и время отправки каждого пакета данных определяет сторона-источник. Transpareo не может получить больше, чем было передано.
Права доступа. То, что разрешено делать с переданными данными на платформе, регулируется определёнными учетными данными: права минимальны, и всё, что не разрешено явно, остаётся запрещённым. Эти правила действуют на стороне платформы, никогда не распространяются задним числом на источник.
В обратном направлении передаются только подтверждения
Полностью обойтись без обратного канала невозможно, но он передаёт не данные, а ответы: URL DPP или GS1 Digital Link, идентификатор версии, статус публикации и сообщения о валидации. Для исходной стороны эти ответы ценны тем, что ссылку на подтверждение можно сохранить в ERP или PIM непосредственно в записи товара. Они не являются запросом на доступ. Это подтверждение получения поставки.
Три модели, которые хорошо зарекомендовали себя на практике
- Напрямую из ведущей системы. ERP или PLM отправляет данные через коннектор. Просто и целесообразно, если один источник данных явно доминирует.
- Через агрегирующий уровень. Промежуточное программное обеспечение (middleware) или iPaaS объединяет поля ERP, MES и PIM и предоставляет пакет данных. Это типичный случай, когда задействовано несколько источников.
- Через подмодели AAS. Управляющая оболочка уже используется, и пакет формируется на основе её подмоделей. Это выгодно в средах «Промышленности 4.0».
Какой шаблон подходит для какой системной среды и как реализовать такой проект за две недели вместо трёх месяцев, мы описали в Руководстве по подключению к ERP.
Чем Transpareo сознательно не является
Не является второй «системой учета» (System of Record). Платформа хранит запись о паспорте и его неизменяемую историю версий, а не операционные данные производителя. То, что исправляется в ERP, попадает в паспорт через новую поставку - в виде новой, отслеживаемой версии, а не в виде незаметного изменения в существующих данных. О том, как эта цепочка версий подписывается и становится доступной для проверки каждым, рассказывается в статье о подписях и сертификатах.
Таким образом, в рамках вашей концепции безопасности остается мало что проверять, и именно в этом и заключается замысел. Вы не предоставляете никаких учетных данных, не открываете внутренний брандмауэр и не подключаете сторонние системы с правами чтения к вашей ERP-системе. Фактическая работа над проектом перемещается туда, где ей и место: решать, какие поля должны входить в «паспорт», а не кто и где может войти в систему.