ISO/IEC JTC 5: Подготовка на архитектурата за DPP-оперативна съвместимост

Защо архитектурният въпрос вече е на дневен ред

Цифровият продуктов паспорт се въвежда поетапно в Европа чрез секторни законодателни актове. Това лесно създава у компаниите впечатлението, че всяка продуктова група се нуждае от собствен модел на данни, собствен носител на данни и собствена логика за интеграция. Именно на тази граница започва работата на ISO/IEC JTC 5: съвместният технически комитет е създаден през 2026 г. и трябва да разработи основите за секторна и междусистемна DPP-оперативна съвместимост. Първата му обявена среща ще се проведе от 7 до 9 септември 2026 г. в Берлин. ISO/IEC JTC 5 изрично описва мандата си като рамка за DPP-система и DPP-екосистема; специфичните за секторите стандарти остават отговорност на съответните специализирани органи.

Това не е ново законово задължение, нито публикуван ISO стандарт. Но е надежден повод да отделите собствената си архитектура от краткосрочните полета с данни. Първата работна точка, ISO/AWI 25534-1, все още е на етап проект 10.99; проектът е одобрен на 12 февруари 2026 г. Според ISO става дума за термини, основни принципи, категории данни, както и механизми за управление и доверие. Публичният запис на проекта изрично посочва „under development“. Всеки, който днес извежда от това задължение за сертифициране или готов формат за обмен, избързва.

Какво отделя международната рамка от изискванията на ЕС

ЕС вече поставя конкретни рамки. Комисията обяснява, че DPP предоставя достъп до информация, свързана с продукта, чрез децентрализиран модел: пълните данни остават при икономическия оператор или при DPP-доставчика на услуги; регистърът съдържа уникални идентификатори и задължителни регистрационни данни. Носител на данни като QR код свързва физическия продукт с неговия паспорт. Страницата на Комисията за DPP посочва също различни нива на достъп за ролите и секторни графици.

Наред с това съществуват европейските хармонизирани стандарти. Решение за изпълнение (ЕС) 2026/1736 от 14 юли 2026 г. се позовава на шест DPP-стандарта, наред с други относно идентификатори, оперативна съвместимост, носители на данни, API, обмен и съхранение на данни. Ролята им е конкретна: за изискванията, които обхващат, спазването им може да подкрепи презумпцията за съответствие съгласно членове 10 и 11 от ESPR.

JTC 5 не заменя тези равнища. Той работи над тях: неутрална спрямо секторите рамка трябва да помогне да се обясни как термините, категориите данни, доверието и управлението се отнасят едни към други между системите. Практическото следствие е важно. Производителят не бива да чака бъдещо издание на ISO, за да предостави информацията за своите батерии, текстил или стомана. Но трябва да избягва превръщането на днешните отраслови полета в непроменяемо ядро на общофирмен DPP-модел.

Три архитектурни решения, които имат смисъл още днес

1. Отделете стабилната идентичност от специализираните профили

Един паспорт се нуждае от дълготрайна техническа идентичност: продукт, вариант, партида или единичен екземпляр; отговорен икономически оператор; разрешаване чрез носителя на данни. След това правното основание определя коя специализирана информация е необходима за него. Тази информация трябва да бъде в профили с версии. Затова батериен модул с данни за CO₂ или State-of-Health не е обща базова схема. По същия начин данните за материали, ремонт или рециклиране не бива да попадат в общ паспорт само като неструктуриран свободен текст.

На практика това означава, че стабилен основен идентификатор, документиран идентификатор на профила и версия на профила трябва да се разглеждат заедно. Всеки предоставен изглед на паспорта трябва да показва кой профил и коя версия определят съдържанието. Така екипите могат да добавят законодателен акт, отраслово правило или по-късно стандарт, без да променят исторически данни или URL адреси.

2. Моделирайте отделно произхода на данните и достъпа

Оперативната съвместимост не е само JSON формат. Тя зависи от това дали получателят може да прецени произхода, валидността и ролята на дадена информация. Затова съхранявайте за всеки елемент или пакет от данни най-малко източник, обхват на валидност, момент на събиране, отговорна страна и специализирана версия. Вътрешната оценка за качество е нещо различно от правно обвързващо твърдение за съответствие; информацията от доставчик е нещо различно от измерена стойност.

Втората част е достъпът. Комисията описва различни нива на достъп до информацията за потребители, ремонтни предприятия, рециклиращи предприятия и органи. Това изисква съзнателно разделяне на публичен изглед на паспорта, оторизиран специализиран достъп и вътрешна работна област. URL адресът не бива да се превръща в средство за предоставяне на права. Ролите, мандатите, категориите данни и решенията, които могат да бъдат регистрирани, трябва да се проверяват от страна на сървъра.

3. Тествайте границите на обмена като договори

Една DPP-система има множество преходи: ERP или PLM предоставят основни данни, доставчиците предоставят доказателства, доставчик на услуги хоства данни, регистърът приема метаданни, а външни потребители четат публичен или защитен изглед. За всеки преход е необходим машинночетим договор: допустими полета, идентификатори, семантика, случаи на грешка, управление на версиите и обратна съвместимост.

Това може да се тества още сега. Подходящи тестови случаи са непознати версии на профили, изтекли доказателства, липсващ произход на данните, неразрешени роли, двойна регистрация и носител на данни, който сочи към вече недостъпен паспорт. Тестът все още не доказва съответствие с бъдещ ISO стандарт. Но създава проследимостта, която липсва при по-късния преход, ако моделът на данните и правата вече са неразделно смесени.

90-дневен работен план без спекулации

През следващите 30 дни си струва да се направи инвентаризация: какви идентификатори на продукти съществуват, какви профили на данни действително се използват и кои данни се намират само в документи? След това идва архитектурно решение: основен модел, регистър на профилите, модел на произхода и матрица на достъпа. На трета стъпка реален продукт трябва да премине през всички преходи — от изходната система през паспорта до ролята на ремонтното предприятие или органа.

Границите остават ясни. ISO/AWI 25534-1 не е готов стандарт; няма публикувани клаузи, които екипите да могат да внедрят. Също така графикът на Комисията е ориентировъчен и не заменя проверката на законодателния акт, приложим към съответната продуктова група. Следователно ползата от наблюдението не е предварително поставена отметка в списък за съответствие, а архитектура, която може чисто да поеме нови профили, роли и правила за обмен.