ISO/IEC JTC 5: DPP-arkkitehtuurin valmistaminen yhteentoimivuutta varten

Miksi arkkitehtuuri tulee nyt nostaa asialistalle

Digitaalinen tuotepassi otetaan Euroopassa vaiheittain käyttöön alakohtaisilla säädöksillä. Yrityksille voi helposti syntyä vaikutelma, että jokainen tuoteryhmä tarvitsee oman tietomallinsa, oman tietovälineensä ja oman integrointilogiikkansa. Juuri tässä rajapinnassa alkaa ISO/IEC JTC 5:n työ: yhteinen tekninen komitea perustettiin vuonna 2026, ja sen tehtävänä on kehittää perusteet alojen ja järjestelmien väliselle DPP-yhteentoimivuudelle. Sen ensimmäinen ilmoitettu kokous järjestetään 7.–9. syyskuuta 2026 Berliinissä. ISO/IEC JTC 5 kuvaa tehtävänsä nimenomaisesti DPP-järjestelmän ja DPP-ekosysteemin kehykseksi; alakohtaiset standardit jäävät toimivaltaisten asiantuntijakomiteoiden vastuulle.

Kyseessä ei ole uusi lakisääteinen velvoite eikä julkaistu ISO-standardi. Se on kuitenkin vankka syy erottaa oma arkkitehtuuri lyhytaikaisista tietokentistä. Ensimmäinen työaihe, ISO/AWI 25534-1, on vielä projektivaiheessa 10.99; projekti hyväksyttiin 12. helmikuuta 2026. ISOn mukaan aiheina ovat käsitteet, perusperiaatteet, tietoluokat sekä hallinta- ja luottamusmekanismit. Julkisessa projektimerkinnässä mainitaan nimenomaisesti ”under development”. Jos tästä johdetaan jo nyt sertifiointivelvoite tai valmis tiedonsiirtomuoto, mennään asioiden edelle.

Miten kansainvälinen kehys eroaa EU:n vaatimuksista

EU asettaa jo konkreettiset suuntaviivat. Komissio selittää, että DPP mahdollistaa tuotteeseen liittyvien tietojen saatavuuden hajautetussa mallissa: täydelliset tiedot säilyvät talouden toimijalla tai DPP-palveluntarjoajalla; rekisteri sisältää yksiselitteiset tunnisteet ja vaaditut rekisteröintitiedot. Tietoväline, kuten QR-koodi, yhdistää fyysisen tuotteen sen passiin. Komission DPP-sivulla mainitaan lisäksi roolikohtaiset käyttöoikeudet ja alakohtaiset aikataulut.

Tämän rinnalla ovat eurooppalaiset yhdenmukaistetut standardit. Täytäntöönpanopäätöksessä (EU) 2026/1736, annettu 14. heinäkuuta 2026, viitataan kuuteen DPP-standardiin, jotka koskevat muun muassa tunnisteita, yhteentoimivuutta, tietovälineitä, rajapintoja, tietojenvaihtoa ja tietojen tallennusta. Niiden rooli on konkreettinen: niiden kattamien vaatimusten osalta noudattaminen voi tukea vaatimustenmukaisuusolettamaa ESPR:n 10 ja 11 artiklan nojalla.

JTC 5 ei korvaa näitä tasoja. Se työskentelee niiden yläpuolella: alaneutraalin kehyksen on tarkoitus auttaa selittämään, miten käsitteet, tietoluokat, luottamus ja hallinta liittyvät toisiinsa järjestelmien välillä. Käytännön seuraus on tärkeä. Valmistajan ei pitäisi odottaa tulevaa ISO-julkaisua voidakseen asettaa akku-, tekstiili- tai terästietonsa saataville. Sen tulisi kuitenkin välttää nykyisten toimialakohtaisten kenttien vahvistamista muuttumattomaksi koko yrityksen laajuisen DPP-mallin ytimeksi.

Kolme arkkitehtuuripäätöstä, jotka ovat järkeviä jo nyt

1. Erota vakaa identiteetti toiminnallisista profiileista

Passi tarvitsee pitkäikäisen teknisen identiteetin: tuotteen, muunnelman, erän tai yksittäiskappaleen; vastuullisen talouden toimijan; sekä tietovälineen kautta tapahtuvan resoluution. Oikeusperusta määrittää tämän jälkeen, mitä toiminnallisia tietoja sitä varten tarvitaan. Nämä toiminnalliset tiedot kuuluvat versioituihin profiileihin. CO₂- tai State-of-Health-tietoja sisältävä akkuyksikkö ei siksi ole yleinen perusskeema. Myöskään materiaali-, korjaus- tai kierrätystietoja ei pidä tallentaa yleiseen passiin ainoastaan jäsentämättömänä vapaana tekstinä.

Käytännössä tämä tarkoittaa, että vakaa ydintunniste, dokumentoitu profiilitunniste ja profiiliversio kuuluvat yhteen. Jokaisesta toimitetusta passinäkymästä pitäisi käydä ilmi, mikä profiili ja mikä versio määrittivät sisällön. Näin tiimit voivat ottaa käyttöön säädöksen, toimialasäännön tai myöhemmin standardin muuttamatta historiallisia tietoja tai URL-osoitteita.

2. Mallinna tietojen alkuperä ja käyttöoikeudet erikseen

Yhteentoimivuus ei ole vain JSON-muoto. Se riippuu siitä, pystyykö vastaanottaja arvioimaan tiedon alkuperää, voimassaoloa ja roolia. Tallentakaa siksi vähintään lähde, soveltamisala, keruuajankohta, vastuullinen osapuoli ja toiminnallinen versio jokaisesta tietoalkiosta tai tietopaketista. Sisäinen laatutieto on eri asia kuin oikeudellisesti sitova vaatimustenmukaisuuslausuma; toimittajan ilmoitus on eri asia kuin mittaustulos.

Toinen osa-alue on käyttöoikeus. Komissio kuvaa kuluttajille, korjausliikkeille, kierrättäjille ja viranomaisille erilaiset tietojen käyttöoikeudet. Tämä edellyttää julkisen passinäkymän, valtuutetun asiantuntijakäytön ja sisäisen työtilan tietoista erottamista. URL-osoitteesta ei saa tehdä käyttöoikeutta. Roolit, valtuutukset, tietoluokat ja lokitettavat päätökset on tarkistettava palvelimella.

3. Testaa tiedonsiirtorajapinnat sopimuksina

DPP-järjestelmässä on useita siirtymiä: ERP tai PLM toimittaa perustiedot, toimittajat toimittavat näytöt, palveluntarjoaja ylläpitää tietoja, rekisteri vastaanottaa metatiedot ja ulkoiset käyttäjät lukevat julkista tai suojattua näkymää. Jokaiselle siirtymälle tarvitaan koneellisesti luettava sopimus: sallitut kentät, tunnisteet, semantiikka, virhetilanteet, versiointi ja taaksepäin yhteensopivuus.

Tätä voidaan testata jo nyt. Hyödyllisiä testitapauksia ovat tuntemattomat profiiliversiot, vanhentuneet näytöt, puuttuvat alkuperätiedot, luvattomat roolit, kaksoisrekisteröinti sekä tietoväline, joka osoittaa passiin, jota ei enää ole saatavilla. Testi ei vielä todista tulevan ISO-standardin vaatimustenmukaisuutta. Se kuitenkin luo osoitettavuuden, joka puuttuu myöhemmin, jos tietomalli ja käyttöoikeudet ovat jo erottamattomasti sekoittuneet.

90 päivän työsuunnitelma ilman spekulointia

Seuraavien 30 päivän aikana kannattaa muodostaa nykytilakuva: mitä tuotetunnisteita on olemassa, mitä tietoprofiileja todella käytetään ja mitkä tiedot ovat vain asiakirjoissa? Sen jälkeen tehdään arkkitehtuuripäätös: ydinskeema, profiilirekisteri, alkuperämalli ja käyttöoikeusmatriisi. Kolmannessa vaiheessa todellinen tuote kannattaa viedä kaikkien siirtymien läpi — lähdejärjestelmästä passin kautta korjausliikkeen tai viranomaisen rooliin.

Rajaukset pysyvät selkeinä. ISO/AWI 25534-1 ei ole valmis standardi; julkaistuja lausekkeita, joita tiimit voisivat toteuttaa, ei ole. Myöskään komission aikajana on suuntaa-antava, eikä se korvaa kyseiseen tuoteryhmään sovellettavan säädöksen tarkistamista. Havainnoinnin hyöty ei siksi ole ennenaikainen rasti vaatimustenmukaisuuslistalla, vaan arkkitehtuuri, johon uudet profiilit, roolit ja tiedonsiirtosäännöt voidaan ottaa hallitusti mukaan.