Digitaalinen akkupassi: Näin pidät tietosi ajan tasalla

Miksi ”kerran täyttäminen” ei riitä

Digitaalinen akkupassi (DBP) ei ole staattinen tietolehti. Akkuasetus (EU) 2023/1542 määrää nimenomaisesti, että tiettyjen tietopisteiden on pysyttävä päivitettävinä akun koko elinkaaren ajan. Jos passin täyttää kerran markkinoille saattamisen yhteydessä eikä siihen sen jälkeen enää kosketa, vaatimukset eivät täyty kokonaisuudessaan — ja 18. helmikuuta 2027 alkaen seurauksena voi olla vakavia vaatimustenmukaisuusongelmia.

Tämä kuulostaa itsestäänselvyydeltä, mutta käytännössä kyse on huomattavasta operatiivisesta ongelmasta. Minespiderin vuoden 2026 täytäntöönpanoraportti tunnistaa kaksi rakenteellista heikkoutta, jotka ulottuvat läpi koko toimialan: toimitusketjun tietojen pirstoutuminen ja dynaamisten tietopäivitysten prosessien puuttuminen. Molemmat ongelmat ovat ratkaistavissa — mutta vain selkeällä teknisellä ja organisatorisella strategialla.

Mitä on muutettava ja milloin: kolme päivitysluokkaa

Kaikki DBP:n tietokentät eivät kuulu samojen päivitysvelvoitteiden piiriin. Alusta alkaen kannattaa erottaa toisistaan kolme luokkaa:

1. Staattiset perustiedot (kerran markkinoille saattamisen yhteydessä)

Näihin kuuluvat kemia, kennoteknologia, valmistajan tunnistetiedot ja sarjanumero. Nämä kentät asetetaan ensimmäisen täytön yhteydessä, eivätkä ne muutu. Ne muodostavat passin muuttumattoman ytimen.

2. Eräkohtaiset CO₂-tiedot (kerran, mutta tarkasti eriteltyinä)

Tuotekohtainen hiilijalanjälki (PCF) on laskettava ISO 14067-kompatiblen -menetelmän mukaisesti ja ilmoitettava erätasolla. Euroopan komission JRC-luonnos täsmentää: eri tuotantolaitosten välinen aggregointi ei ole sallittua. Jokainen akkumalli saa oman PCF-arvonsa kutakin tuotantopaikkaa kohden. Tämä tarkoittaa, että jokaisesta uudesta erästä on luotava uusi tietue ja yhdistettävä se vastaavaan passiin — edellisen mallin copy-paste ei riitä.

Käytännössä tämä tarkoittaa seuraavaa: jos tuotantojärjestelmänne ei tuota eräkohtaisia CO₂-laskelmia, aiempaa prosessia on muutettava ennen kuin passia voidaan edes täyttää.

3. Tilatiedot (jatkuvasti koko elinkaaren ajan)

Tämä on vaativin luokka. State of Health (SoH) ja State of Charge (SoC) muuttuvat jokaisen lataus- ja purkusyklin myötä. Toisessa elämässä — esimerkiksi sähköajoneuvossa käytön jälkeen paikallaan olevana energiavarastona — hyödynnettäville akuille ajantasaiset tilatiedot eivät ole ainoastaan sääntelyn edellyttämiä, vaan myös taloudellisesti merkityksellisiä: ilman luotettavia SoH-tietoja second-life-markkinoilla ei voida määrittää oikeudenmukaista markkina-arvoa.

Tekninen toteutus: kolme lähestymistapaa vertailussa

Miten tiedot saadaan passiin? Ja miten ne pidetään ajan tasalla? Tähän on olennaisesti kolme arkkitehtuurivaihtoehtoa:

Lähestymistapa	Soveltuu	Etu	Riski
Push REST-API:n kautta	Valmistajat, joilla on oma MES/ERP	Täysin automaattinen, reaaliaikainen	Riippuvuus sisäisestä IT-infrastruktuurista
Joukkotuonti (CSV/JSON)	Toimittajat ilman API-yhteyttä	Matala aloituskynnys	Manuaaliset virhelähteet, viiveet
Sensor-to-DPP (IoT)	Paikallaan olevat varastot, kalustonhallinta	Jatkuva SoH-päivitys	Monimutkainen dataputki, korkeat latenssivaatimukset

Useimmille valmistajille hybridiratkaisu on järkevä: perus- ja PCF-tiedot tulevat ERP-järjestelmästä joukkotuontina tai API:n kautta, kun taas tilatietoja päivitetään IoT-putken avulla.

API-päivitys: minimaalinen esimerkki

REST-API:a tilatietojen päivittämiseen käyttävien kannattaa hyödyntää versioitua päätepisterakennetta, joka tukee myös osittaisia päivityksiä (PATCH):

// Beispiel: SoH-Update für eine einzelne Batterie-Seriennummer
const response = await fetch(
  'https://api.example.com/v1/batteries/{serialNumber}/state',
  {
    method: 'PATCH',
    headers: {
      'Content-Type': 'application/json',
      'Authorization': `Bearer ${apiToken}`,
    },
    body: JSON.stringify({
      stateOfHealth: 0.87,        // 87 % Restkapazität
      stateOfCharge: 0.52,        // 52 % aktueller Ladestand
      measuredAt: '2026-06-25T14:30:00Z',
      measurementMethod: 'IEC_62660-1',
    }),
  }
);

Aikaleima (measuredAt) ei ole valinnainen kenttä — se on olennainen jäljitettävyyden ja markkinavalvontaviranomaisten suorittaman tarkastuksen kannalta.

Yhteentoimivuus: standardit, rekisteri ja testiympäristö

Päivityksestä on vain vähän hyötyä, jos vastaanottava solmu ei ymmärrä tietoja. Juuri tähän standardointityö keskittyy. CEN ja CENELEC järjestivät 25. kesäkuuta 2026 julkisen webinaarin hiljattain julkaistuista DPP-standardeista EN 18216–EN 18223. Nämä teknisen komitean JTC 24 laatimat kuusi standardia määrittelevät tuoteryhmät ylittävän yhteentoimivuuden ja tietojen yhdenmukaisuuden viitekehyksen — siis juuri sen kerroksen, jolla päivitysprosessit on standardoitava.

Samanaikaisesti BatteryPass-Ready-konsortio käynnisti 24. kesäkuuta 2026 digitaalisen akkupassin julkisen testiympäristön. Valmistajat, alihankkijat ja ohjelmistotoimittajat voivat validoida siellä toteutuksensa sääntelyvaatimuksia vasten — ennen tuotantokäytön aloittamista. Päivitysprosesseja rakentavien kannattaa hyödyntää tätä ympäristöä varhaisessa vaiheessa tietomuotojen ja API-yhteensopivuuden testaamiseen.

EU:n keskitetty DPP-rekisteri

Euroopan komissio valmistelee keskitettyä rekisteriä, jonka kautta kaikki DPPs voidaan rekisteröidä ja tehdä löydettäviksi. Orgalim — eurooppalainen teknologiasektorin teollisuusjärjestö — on julkaissut aiheesta selkeät suositukset: rekisterin on tuettava suurivolyymisia, automatisoituja rekisteröintiprosesseja ja oltava suojattu käyttökatkoilta. Päivitysprosessien kannalta tämä tarkoittaa, että sisäisen arkkitehtuurin on toimittava myös silloin, kun keskitetty rekisteri ei ole tilapäisesti tavoitettavissa — eli paikallinen välimuisti ja uudelleenyrityslogiikka on suunniteltava mukaan.

Fyysisen akun ja digitaalisen passin välinen yhteys muodostetaan käytännössä GS1 Digital Link avulla — kyseessä on standardoitu URI, joka koodaa GTIN:n ja sarjanumeron ja osoittaa vastaavaan tietueeseen. Tämä linkki on tyypillisesti koodattu akun etiketissä olevaan QR-koodiin.

Organisatoriset edellytykset: Kuka vastaa päivityksistä?

Asetus kohdistuu ensisijaisesti talouden toimijaan, joka saattaa akun markkinoille. Tilatiedot syntyvät kuitenkin usein kaukana valmistajasta — kalusto-operaattorin, kierrätysyrityksen tai second-life-palveluntarjoajan luona. Kysymys kirjoitusoikeuksista ei siksi ole pelkästään tekninen: siitä on sovittava sopimuksin.

Seuraavat roolit on määriteltävä hallintorakenteessa selkeästi:

Data Owner: Kuka saa kirjoittaa ja ylikirjoittaa mitäkin kenttiä?
Audit Trail: Jokainen muutos on kirjattava aikaleiman ja toimijan kanssa — ei ainoastaan vaatimustenmukaisuuden vuoksi, vaan myös second-life-markkinoiden riitatilanteita varten.
Hätätilannemenettely: Mitä tapahtuu, jos anturi vikaantuu tai toimittaja ei toimita tietoja?

Bureau Veritasin ja Circulorin kumppanuuden kaltaiset ratkaisut osoittavat, miten tarkastusorganisaatiot ja datapalveluntarjoajat yhdistävät voimansa juuri näiden hallinnollisten aukkojen täyttämiseksi. Samansuuntaisesti toimii Securikett Codikett 2.0 -alustallaan: väärentämisen kestävät etiketit yhdistävät tietueen fyysisesti tuotteeseen ja vaikeuttavat luvatonta kirjoitusoikeutta.

Tarkistuslista: Päivitysvalmius helmikuuhun 2027 mennessä

Ennen kuin pidätte DBP-prosessianne ”valmiina”, seuraavat kohdat on syytä tarkistaa:

PCF-laskenta on toteutettu erätasolla (ei mallikohtaisesti aggregoituna)
SoH/SoC-dataputki on rakennettu ja testattu
API-päätepisteet tukevat osittaisia päivityksiä (PATCH) aikaleiman kanssa
Kirjoitusoikeuksista on sovittu sopimuksin kaikkien asiaankuuluvien toimijoiden kanssa
Uudelleenyrityslogiikka rekisterin käyttökatkon varalta on toteutettu
Toteutus on validoitu BatteryPass-Ready-testiympäristöä vasten
GS1 Digital Link on koodattu oikein etikettiin ja QR-koodiin

Helmikuu 2027 lähestyy. Jos päivitysprosessit rakennetaan vasta velvoitteen astuttua voimaan, huomataan, ettei varsinainen työ ole passin täyttämisessä — vaan sen pitämisessä asianmukaisesti ajan tasalla vuosien ajan.