Pidä digitaalinen tuotepassi ajan tasalla: näin DPP-päivitykset toimivat

Miksi kertaluonteinen täyttäminen ei riitä

Digitaalinen tuotepassi (DPP) ei ole staattinen PDF-tiedosto, joka luodaan kerran ja arkistoidaan sen jälkeen. Akkuasetus (EU) 2023/1542 edellyttää nimenomaisesti, että tietyt tietopisteet voidaan pitää päivitettävinä akun koko elinkaaren ajan. Jos passi täytetään tuotteen markkinoille saattamisen yhteydessä eikä siihen sen jälkeen enää kosketa, näitä vaatimuksia ei täytetä kokonaan — ja seurauksena voi olla vakavia vaatimustenmukaisuusongelmia 18. helmikuuta 2027 alkaen.

Tämä kuulostaa yksinkertaiselta, mutta ei ole sitä. Minespiderin vuoden 2026 toteutusraportti tunnistaa kaksi rakenteellista heikkoutta, jotka ulottuvat koko toimialalle: toimitusketjun varrella pirstoutuvat tiedot ja dynaamisten tietopäivitysten puuttuvat prosessit. Yhdessä nämä vaikeuttavat DPP:n pitämistä yhdenmukaisena käytön aikana.

Tässä artikkelissa kerrotaan, mitkä tiedot muuttuvat ja milloin, miltä päivitysten tekninen infrastruktuuri näyttää sekä millaisia organisatorisia prosesseja valmistajien ja käyttäjäorganisaatioiden tulisi nyt rakentaa.

Mitä muuttuu — ja milloin

Staattiset ja dynaamiset tietopisteet

Kaikki DPP:n kentät eivät muutu yhtä usein. Karkeasti voidaan erottaa kaksi luokkaa:

Staattiset tiedot määritetään markkinoille saattamisen yhteydessä, eivätkä ne yleensä muutu sen jälkeen:

• Materiaalikoostumus ja vaaralliset aineet
• Valmistajan tunnistetiedot ja tuotantopaikka
• Sertifioinnit markkinoille tulon ajankohtana

Dynaamiset tiedot puolestaan muuttuvat tuotteen elinkaaren aikana:

• Akkujen State of Health (SoH) ja State of Charge (SoC) — molemmat arvot muuttuvat jokaisen lataus- ja purkaussyklin myötä
• Korjaus- ja huoltohistoria
• Omistajanvaihdokset ja sijaintitiedot
• Ensimmäisen käyttöiän lopussa tehtyjen kunnostustarkastusten tulokset

Erityisesti akuissa, jotka saavat sähköajoneuvokäytön jälkeen toisen elämän kiinteinä energiavarastoina, ajantasaiset tilatiedot eivät ole vain sääntelyn edellyttämiä vaan myös taloudellisesti merkityksellisiä: sekundäärisen energiavaraston käyttäjän on tiedettävä, kuinka paljon jäljellä olevaa kapasiteettia hän tosiasiassa ostaa.

Pakollisten päivitysten laukaisevat tapahtumat

Asetuksessa ei nimetä täsmällisiä päivitysvälejä, mutta siinä määritellään tapahtumia, jotka laukaisevat päivityksen:

• Huollon tai korjauksen valmistuminen
• Siirtyminen uuteen käyttö­vaiheeseen (ensimmäinen käyttöikä → toinen käyttöikä)
• Omistajan tai käyttäjän vaihtuminen
• BMS-järjestelmistä saatavat uudet mittausarvot (Battery Management System)
• Takaisinkutsu tai turvallisuusilmoitus

Jos näitä tapahtumia ei ole sisällytetty organisaation sisäiseen prosessiin, ne jäävät päivittäisessä toiminnassa huomaamatta.

DPP-päivitysten tekninen arkkitehtuuri

GS1 Digital Link vakaana ankkurina

Fyysisen akun ja digitaalisen passin välinen yhteys muodostetaan GS1 Digital Link avulla — kyseessä on standardoitu URI, joka koodaa GTIN:n ja sarjanumeron ja osoittaa niihin liittyvään tietueeseen. Olennaista on, että tuotteessa oleva linkki (esimerkiksi QR-koodina painettu) säilyy muuttumattomana. Vain tietuetta, johon se osoittaa, päivitetään.

Tyypillinen akun GS1 Digital Link näyttää tältä:

https://id.example.com/01/04012345678901/21/ABC-0042

• 01 = GTIN-tunniste
• 04012345678901 = akun GTIN
• 21 = sarjanumeron tunniste
• ABC-0042 = yksilöllinen sarjanumero

Kyseessä on puhtaasti havainnollistava esimerkki-URL, joka havainnollistaa GS1 Digital Link:n URI-rakennetta. Tällaisen URL-osoitteen takana oleva resolveri ohjaa ajantasaiseen DPP-tietueeseen. Jos tietue muuttuu, tuotteessa oleva QR-koodi pysyy samana — vain kohde taustajärjestelmässä päivittyy. Tämä on dynaamisen tiedon ylläpidon perusajatus.

API-pohjaiset päivitykset: perusperiaate

Nykyaikaiset DPP-alustat tarjoavat REST-rajapintoja, joiden kautta tietopisteitä voidaan päivittää kohdennetusti ilman koko passin uudelleenkirjoittamista. Tyypillinen PATCH-pyyntö DPP-rajapintaan voisi näyttää tältä:

PATCH /dpp/v1/batteries/04012345678901/21/ABC-0042
Content-Type: application/json
Authorization: Bearer <token>

{
  "stateOfHealth": 0.83,
  "lastMeasuredAt": "2026-06-20T14:32:00Z",
  "measuredBy": "operator:fleet-mgmt-system-v2"
}

Etuna täyteen PUT-pyyntöön verrattuna on, että vain muuttuneet kentät siirretään, versiointi pysyy jäljitettävänä eikä auditointiloki kasva tarpeettomasti.

Versiointi ja auditointiketju

EN-standardit 18216–18223, jotka CEN ja CENELEC esittelivät 25. kesäkuuta 2026 julkisessa webinaarissa, määrittelevät tiedon yhdenmukaisuutta ja yhteentoimivuutta koskevia vaatimuksia. Niihin kuuluu epäsuorasti myös muutosten jäljitettävyys: kuka muutti mitäkin arvoa ja milloin, ja mihin muutos perustui?

Vähimmäistason versionointistrategiassa tulisi tallentaa jokaisesta päivitystapahtumasta seuraavat kentät:

{
  "version": "3",
  "updatedAt": "2026-06-20T14:32:00Z",
  "updatedBy": "system:bms-connector",
  "changedFields": ["stateOfHealth", "lastMeasuredAt"],
  "previousValues": {
    "stateOfHealth": 0.87
  }
}

Ilman tätä jäljitysketjua ei riitatilanteessa voida osoittaa, että tiedot olivat kyseisenä ajankohtana oikein.

Organisatoriset prosessit: mitä yritysten on nyt rakennettava

Tietovastuut selviksi

Suurin käytännön ongelma ei ole tekninen. Kyse on siitä, kuka organisaatiossa vastaa mistäkin tietopisteestä — ja kuka tarvittaessa käynnistää päivityksen.

Suositeltavaa on käyttää yksinkertaista RACI-matriisia, jossa määritellään jokaisen dynaamisen tietopisteen osalta:

• Responsible: Kuka suorittaa päivityksen?
• Accountable: Kuka vastaa asiasta viranomaiselle?
• Consulted: Kuka toimittaa mittaustiedot?
• Informed: Kenelle muutoksista on ilmoitettava?

Toimitusketju mukaan

Monet dynaamiset tiedot syntyvät muualla kuin valmistajan luona, esimerkiksi toimittajilla, huoltoyrityksissä tai kalustonhallinnassa. Valmistaja vastaa kuitenkin sääntelyn näkökulmasta passin oikeellisuudesta. Tämä edellyttää selkeitä sopimusehtoja ja teknisiä rajapintoja, joiden kautta kolmannet osapuolet voivat toimittaa tietoja — määriteltyine formaatteineen ja validointisääntöineen.

BatteryPass-Ready-konsortio, joka käynnisti julkisen testiympäristön 24. kesäkuuta 2026, tarjoaa juuri tähän neutraalin validointialustan: yritykset voivat testata DPP-ratkaisujaan sääntelyvaatimuksia vasten ennen tuotantokäyttöön siirtymistä.

Keskitetty rekisteri huomioon

Euroopan komissio valmistelee keskitettyä rekisteriä, jonka kautta kaikki DPPs on tarkoitus rekisteröidä ja tehdä löydettäviksi. Orgalim — eurooppalainen teknologiateollisuuden järjestö — on julkaissut asiasta selkeät suositukset: rekisterin on tuettava suuren volyymin automatisoituja rekisteröintiprosesseja ja oltava suojattu käyttökatkoilta.

Yrityksille tämä merkitsee, että niiden päivitysprosessien on toimittava oman alustan lisäksi tulevaisuudessa myös keskitetyn EU-rekisterin kanssa ja oltava synkronoitavissa siihen. Jos nyt valitaan omat erillisratkaisut, myöhemmin syntyy siirtymisestä ylimääräistä työtä.

Käytännön tarkistuslista päivitysprosessia varten

Ennen kuin ensimmäinen DPP siirtyy tuotantoon, seuraavien kohtien tulee olla selvillä:

1. Tietopisteet luokiteltu: Mitkä kentät ovat staattisia ja mitkä dynaamisia?
2. Laukaisevat tapahtumat määritelty: Mitkä tapahtumat käynnistävät pakollisen päivityksen?
3. API-käyttöoikeudet määritelty: Kuka saa muuttaa mitäkin kenttiä ja minkä rajapinnan kautta?
4. Auditointiketju toteutettu: Jokainen muutos tallennetaan aikaleiman, tekijän ja aiemman arvon kanssa.
5. Toimitusketjun rajapinnat testattu: Ulkoiset tietojen toimittajat voivat syöttää kelvollisia päivityksiä.
6. Rekisteriyhteensopivuus tarkistettu: Oma järjestelmä pystyy viestimään tulevan EU-rekisterin kanssa.
7. Testiympäristöä käytetty: BatteryPass-Ready-testialustaa tai vastaavia ympäristöjä on käytetty yhteentoimivuustesteihin.

Yhteenveto

DPP ei ole asiakirja vaan elävä tietue. Akkuasetuksen (EU) 2023/1542 sääntelyvaatimukset ovat tältä osin yksiselitteiset: dynaamiset tietopisteet on pidettävä ajan tasalla koko tuotteen elinkaaren ajan. Jos teknistä ja organisatorista infrastruktuuria ei rakenneta ajoissa, 18. helmikuuta 2027 asetettua määräaikaa ei saavuteta vaatimustenmukaisesti.

Hyvä uutinen on, että tarvittavat rakennuspalikat ovat olemassa. GS1 Digital Link ratkaisee tunnistamisongelman, REST-rajapinnat mahdollistavat tarkkarajaiset päivitykset, ja BatteryPass-Readyn kaltaiset aloitteet tarjoavat testiinfrastruktuurin. Monista yrityksistä puuttuvat kuitenkin sisäiset prosessit ja tietovastuiden selkeä määrittely — ja juuri siitä työn pitäisi alkaa.