Как только проект «Цифрового паспорта продукта» приобретает конкретные очертания, ИТ-отдел задает вопрос, который стоит выше всех остальных: с какими из наших систем должна взаимодействовать платформа? Это правильный вопрос, ведь за ним стоят учетные данные, настройки брандмауэра и концепция безопасности, за которую кто-то должен нести ответственность.
Наш ответ краток: ни одна. Все системы, предоставляющие данные для паспорта, находятся на стороне источника и остаются там. 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, идентификатор версии, статус публикации и сообщения о валидации. Для исходной стороны эти ответы ценны тем, что ссылку на пропуск можно сохранить в ERP или PIM непосредственно в записи о товаре. Они не являются доступом. Это подтверждение получения поставки.
Три модели, которые хорошо зарекомендовали себя на практике
- Непосредственно из ведущей системы. ERP или PLM отправляет данные через коннектор. Простой и целесообразный подход, когда один источник данных явно доминирует.
- Через агрегирующий уровень. Промежуточное программное обеспечение (middleware) или iPaaS объединяет поля ERP, MES и PIM и формирует единый пакет. Это типичный случай, когда задействовано несколько источников.
- Через подмодели AAS. Управляющая оболочка уже используется, и пакет формируется на основе её подмоделей. Это выгодно в средах «Промышленности 4.0».
Какой шаблон подходит для какой системной среды и как реализовать такой проект за две недели вместо трёх месяцев, мы описали в руководстве по подключению к ERP-системам.
Не у каждого, кто предоставляет данные, есть система, способная их передать. Поставщик, не имеющий собственного корпоративного программного обеспечения , заполняет поля, запрошенные вами, на мобильном телефоне, и в этом случае поток данных также движется только в одном направлении: его ответ поступает к вам в виде предложения, и вы проверяете его, прежде чем он попадает в паспорт данных.
Чем Transpareo сознательно не является
Не ## являетсявторой «системой учета» (System of Record). Платформа хранит запись о паспорте и его неизменяемую историю версий, а не производственные данные производителя. То, что исправляется в ERP, поступает в «паспорт» посредством новой поставки - в виде новой, отслеживаемой версии, а не в виде незаметного изменения в запасах. О том, как эта цепочка версий подписывается и становится доступной для проверки каждым, рассказывается в статье о подписях и сертификатах.
Таким образом, в рамках вашей концепции безопасности остаётся малое количество аспектов, требующих проверки, и именно в этом и заключается замысел. Вы не предоставляете никаких учетных данных, не открываете внутренний пропуск в брандмауэре и не подключаете сторонние системы с правами чтения к вашей 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 второй «системой учета»?
Нет, и это сделано намеренно. Платформа хранит набор данных «Pass» и его неизменяемую историю версий, а не ваши эксплуатационные данные; ваши системы по-прежнему остаются определяющими во всём, что касается их. Таким образом, работа над проектом остаётся там, где ей и положено - в сфере определения того, какие поля должны входить в «паспорт», а не в сфере решения вопроса о том, кому и где разрешено входить в систему.
