Един поток, една посока: как данните постъпват в продуктовия паспорт

Един поток, една посока: как данните постъпват в продуктовия паспорт

ERP, MES, PLM и PIM подават данни към цифровия продуктов паспорт, като запазват контрола върху тях. Потокът се движи само в една посока, а в обратна посока се получават единствено потвърждения.

Веднага щом идеята за цифров паспорт на продукта се конкретизира, ИТ-отделът задава един въпрос преди всички останали: Кои от нашите системи трябва да бъдат включени в платформата? Това е правилният въпрос, защото зад него стоят данни за достъп, разрешения за пропускане през защитната стена и концепция за сигурност, за която някой трябва да поеме отговорност.

Отговорът ни е кратък: нито една. Всички системи, които предоставят данни за паспорта, се намират на изходния край и остават там. Transpareo е изключително получател в края на веригата; потоците от данни се насочват еднопосочно към платформата. Тази статия проследява потоците: какво предоставя всяка система, какви правила важат за всеки поток и какво се получава като потвърждение.

Какво допринася всяка система за паспорта

Данните за един паспорт рядко произхождат от една система. На практика те са разпределени в няколко класа системи, като всяка от тях допринася само с няколко полета:

  • ERP - идентификация на артикула, материали, доставчици и произход, връзка с поръчки и партиди, количества. Стабилни базови данни, които рядко се променят.
  • MES - производствена история, присвояване на серийни номера и партиди, сертификати за качество, проследимост. Данни за събития, свързани с конкретен момент във времето.
  • APS - производствени моменти и разпределение на ресурсите. Рядко има пряко значение за паспорта; това, което има значение, обикновено идва чрез MES.
  • PLM - състав, спецификации, възможност за ремонт, резервни части, етапи на проектиране. Съобразно изискванията на Регламента за екодизайн, това е най-изчерпателният източник.
  • PIM - описания, изображения, указания за поддръжка и употреба, езикови варианти. Съдържанието, насочено към потребителите.
  • IoT - данни за състоянието и употребата от фазата на експлоатация. Необходими само при определени групи продукти, например при батериите.
  • CRM - история на обслужването и ремонтите на отделни клиенти. По принцип е свързана с лични данни и затова не принадлежи в публичен паспорт.

Административната обвивка стои над системите, а не редом с тях

Едно разграничение е по-важно от всички останали: Asset Administration Shell не стои редом с ERP, MES и PIM, а над тях. Тя не генерира данни, а капсулира съществуващите в оперативно съвместими подмодели. За свързването с Transpareo това означава: AAS е удобен, но не и задължителен формат на доставка. Който я използва, извлича пакета от данни от нейните подмодели; който не я използва, предоставя същите полета по друг начин. Защо въпреки това считаме Asset Administration Shell за отлична основа, е описано в статията за AAS.

Пет правила, валидни за всеки поток

Посока. Всички стрелки сочат към платформата. Transpareo не извлича данни от нито една източна система и не разполага с данни за достъп до ERP, MES, PIM или PLM. Няма връзка с вашите системи, която да трябва да се защищава, защото такава просто не съществува.

Задействане. Инициативата винаги се задейства от страна на източника - от самия производител, неговия мидълуеър или нает доставчик на услуги. Платформата изчаква; тя не извлича данни.

Целево предназначение. Предава се изключително подмножеството, необходимо за „паспорта“, а не цялата база данни на изходната система. „Паспортът“ се нуждае само от няколко полета от всяка система; всичко останало остава на мястото си.

Одобрение. Изборът, обхватът и моментът на всеки пакет се определят от източника. Transpareo не може да получи повече, отколкото е било доставено.

Права за достъп. Какво може да се прави с доставените данни на платформата се регулира от определени удостоверения за достъп: минимални права, а това, което не е изрично разрешено, остава забранено. Тези правила действат от страна на платформата, никога със задна дата спрямо източника.

В обратна посока се изпращат само потвърждения

Напълно без обратен канал не може, но той не пренася данни, а отговори: DPP-URL или GS1 Digital Link, идентификатора на версията, статуса на публикуване и съобщенията за валидиране. За изходната страница тези отговори са ценни, защото референцията за съответствие може да се съхрани директно към артикула в ERP или PIM. Те не представляват достъп. Те са потвърждение за получена доставка.

Три модела, които се оправдават на практика

  • Директно от водещата система. ERP или PLM изпращат данните чрез конектор. Просто и целесъобразно, когато един източник на данни ясно доминира.
  • Чрез агрегационен слой. Мидълуер или iPaaS обединява полетата от ERP, MES и PIM и предоставя пакет. Това е обичайният случай, когато са замесени няколко източника.
  • Чрез AAS-подмодели. Административната обвивка вече е в употреба, а пакетът се извлича от нейните подмодели. Това е предимство в среди от типа „Индустрия 4.0“.

Кой модел подхожда на коя системна среда и как такъв проект може да бъде реализиран за две седмици вместо за три месеца, сме описали в Наръчника за ERP-интеграция.

Какво Transpareo съзнателно не е

Не е втора „система за запис“ (System of Record). Платформата съхранява записите за паспорта и неговата неизменяема история на версиите, а не оперативните данни на производителя. Това, което се коригира в ERP, достига до паспорта чрез нова доставка - като нова, проследима версия, а не като тиха промяна в наличността. Как тази верига от версии се подписва и става достъпна за проверка от всеки, е описано в статията за подписи и сертификати.

По този начин за вашата концепция за сигурност остава малко за проверка, и точно това е целта. Няма данни за достъп, които да предоставяте, няма отваряне на защитна стена към вътрешната мрежа и няма външна система с права за четене във вашата ERP система. Самата работа по проекта се премества там, където ѝ е мястото: да се реши кои полета да бъдат включени в „паспорта“ - а не кой има право да влиза къде.

Потоци от данни и интерфейси в бюлетина

Как данните за продуктите се въвеждат коректно в каталога - модели за интеграция, системни ограничения и практически ръководства, които получавате всеки месец в пощенската си кутия.