ISO/IEC JTC 5: parengti architektūrą sąveikai DPP

Kodėl dabar į darbotvarkę įtraukiamas architektūros klausimas

Skaitmeninis produkto pasas Europoje palaipsniui diegiamas pagal sektorių teisės aktus. Įmonėms todėl gali susidaryti įspūdis, kad kiekvienai produktų grupei reikia atskiro duomenų modelio, duomenų laikmenos ir integravimo logikos. Būtent šioje sąsajoje prasideda ISO/IEC JTC 5 darbas: bendrasis techninis komitetas įsteigtas 2026 m. ir turi parengti pagrindus sektorių bei sistemų tarpusavio DPP sąveikai. Pirmasis paskelbtas jo posėdis vyks 2026 m. rugsėjo 7–9 d. Berlyne. ISO/IEC JTC 5 savo užduotį aiškiai apibūdina kaip DPP sistemos ir DPP ekosistemos pagrindą; už sektoriams skirtus standartus ir toliau atsakingi atitinkami specializuoti komitetai.

Tai nėra nauja teisinė prievolė ir nepublikuotas ISO standartas. Tačiau tai patikima priežastis atskirti savo architektūrą nuo trumpalaikių duomenų laukų. Pirmasis darbo punktas, ISO/AWI 25534-1, tebėra projekto stadijoje 10.99; projektas patvirtintas 2026 m. vasario 12 d. ISO duomenimis, jame nagrinėjamos sąvokos, pagrindiniai principai, duomenų kategorijos, taip pat valdymo ir pasitikėjimo mechanizmai. Viešame projekto įraše aiškiai nurodyta „under development“. Kas šiandien iš to išveda sertifikavimo prievolę ar parengtą keitimosi formatą, skuba daryti išvadas.

Kas skiria tarptautinę sistemą nuo ES reikalavimų

ES jau nustato konkrečias gaires. Komisija aiškina, kad DPP decentralizuotu modeliu suteikia prieigą prie su produktu susijusios informacijos: visi duomenys lieka ekonominės veiklos vykdytojui arba DPP paslaugų teikėjui; registre saugomi unikalūs identifikatoriai ir privalomi registracijos duomenys. Duomenų laikmena, pavyzdžiui, QR kodas, susieja fizinį produktą su jo pasu. Komisijos DPP puslapyje taip pat nurodomos skirtingos prieigos pagal vaidmenis ir sektorių tvarkaraščiai.

Be to, taikomi Europos darnieji standartai. 2026 m. liepos 14 d. įgyvendinimo sprendime (ES) 2026/1736 daroma nuoroda į šešis DPP standartus, be kita ko, susijusius su identifikatoriais, sąveika, duomenų laikmenomis, API, keitimusi duomenimis ir duomenų saugojimu. Jų paskirtis konkreti: reikalavimų, kuriuos jie apima, laikymasis gali pagrįsti atitikties prezumpciją pagal ESPR 10 ir 11 straipsnius.

JTC 5 nepakeičia šių lygmenų. Jis veikia virš jų: sektoriams neutrali sistema turėtų padėti paaiškinti, kaip skirtingose sistemose tarpusavyje siejasi sąvokos, duomenų kategorijos, pasitikėjimas ir valdymas. Praktinė pasekmė svarbi. Gamintojas neturėtų laukti būsimo ISO leidimo, kad pateiktų informaciją apie baterijas, tekstilę ar plieną. Tačiau jis turėtų vengti šiandienos sektoriaus laukus įtvirtinti kaip nekintamą visos įmonės DPP modelio branduolį.

Trys architektūros sprendimai, kurie šiandien prasmingi

1. Atskirti stabilią tapatybę nuo dalykinių profilių

Pasui reikia ilgalaikės techninės tapatybės: produkto, varianto, partijos ar atskiro vieneto; atsakingo ekonominės veiklos vykdytojo; išsprendimo naudojant duomenų laikmeną. Teisinis pagrindas vėliau nustato, kokia dalykinė informacija tam reikalinga. Ši dalykinė informacija turi būti laikoma versijuotuose profiliuose. Todėl baterijos modulio CO₂ ar būsenos duomenų profilis nėra bendra bazinė schema. Taip pat medžiagų, remonto ar perdirbimo duomenys neturėtų būti pateikiami tik kaip nestruktūrizuotas laisvasis tekstas bendrame pase.

Praktiškai tai reiškia, kad stabili pagrindinė ID, dokumentuotas profilio identifikatorius ir profilio versija turi būti susieti. Kiekvienas išduotas paso vaizdas turėtų parodyti, kuris profilis ir jo versija nulėmė turinį. Taip komandos gali įtraukti teisės aktą, sektoriaus taisyklę ar vėliau standartą, neperrašydamos istorinių duomenų ar URL.

2. Atskirai modeliuoti duomenų kilmę ir prieigą

Sąveika nėra vien JSON formatas. Ji priklauso nuo to, ar gavėjas gali įvertinti informacijos kilmę, galiojimą ir vaidmenį. Todėl kiekvienam duomenų elementui ar paketui bent nurodykite šaltinį, taikymo sritį, surinkimo laiką, atsakingą šalį ir dalykinę versiją. Vidinis kokybės įvertis nėra tas pats, kas teisiškai privalomas atitikties teiginys; tiekėjo pateikta informacija nėra tas pats, kas matavimo reikšmė.

Antroji dalis – prieiga. Komisija aprašo skirtingą vartotojų, remonto įmonių, perdirbėjų ir institucijų prieigą prie informacijos. Tam reikia sąmoningai atskirti viešą paso vaizdą, įgaliotą dalykinę prieigą ir vidinę darbo sritį. URL neturi tapti prieigos teise. Vaidmenys, įgaliojimai, duomenų kategorijos ir audituojami sprendimai turi būti tikrinami serverio pusėje.

3. Keitimosi ribas tikrinti kaip sutartis

DPP sistema turi kelias sąsajas: ERP arba PLM teikia pagrindinius duomenis, tiekėjai pateikia įrodymus, paslaugų teikėjas talpina duomenis, registras priima metaduomenis, o išoriniai naudotojai skaito viešą arba apsaugotą vaizdą. Kiekvienai sąsajai reikia mašininiu būdu nuskaitomos sutarties: leistini laukai, identifikatoriai, semantika, klaidų atvejai, versijavimas ir atgalinis suderinamumas.

Tai galima tikrinti jau dabar. Naudingi bandymo atvejai: nežinomos profilio versijos, pasibaigę įrodymai, trūkstama duomenų kilmė, neleistini vaidmenys, dviguba registracija ir duomenų laikmena, nukreipianti į nebepasiekiamą pasą. Bandymas dar neįrodo atitikties būsimam ISO standartui. Tačiau jis sukuria įrodomumą, kurio vėliau trūktų, jei duomenų modelis ir teisės jau būtų neatskiriamai susimaišę.

90 dienų darbo planas be spekuliacijų

Per artimiausias 30 dienų verta susidaryti esamos padėties vaizdą: kokie produktų identifikatoriai egzistuoja, kokie duomenų profiliai iš tikrųjų naudojami ir kokie duomenys yra tik dokumentuose? Tada priimamas architektūros sprendimas: pagrindinis modelis, profilių registras, kilmės modelis ir prieigos matrica. Trečiuoju etapu realus produktas turėtų pereiti visas sąsajas – nuo šaltinio sistemos per pasą iki remonto įmonės ar institucijos vaidmens.

Ribos turi išlikti aiškios. ISO/AWI 25534-1 nėra parengtas standartas; nėra paskelbtų sąlygų, kurias komandos galėtų įgyvendinti. Be to, Komisijos tvarkaraštis yra orientacinis ir nepakeičia konkrečiai produktų grupei taikomo teisės akto patikros. Todėl stebėjimo nauda slypi ne iš anksto pažymėtame atitikties sąrašo punkte, o architektūroje, galinčioje tvarkingai priimti naujus profilius, vaidmenis ir keitimosi taisykles.