Веднага щом идеята за цифров паспорт на продукта се конкретизира, ИТ-отделът задава един въпрос преди всички останали: Кои от нашите системи трябва да бъдат включени в платформата? Това е правилният въпрос, защото зад него стоят данни за достъп, разрешения за пропускане през защитната стена и концепция за сигурност, за която някой трябва да поеме отговорност.
Отговорът ни е кратък: нито една. Всички системи, които предоставят данни за паспорта, се намират на изходния край и остават там. 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 система. Самата работа по проекта се премества там, където ѝ е мястото: да се реши кои полета да бъдат включени в „паспорта“ - а не кой има право да влиза къде.
