Digitális akkumulátor-útlevél: így tartsa naprakészen adatait

2027 februárjától kötelező: hogyan frissíthetik a gyártók jogszerűen a dinamikus adatokat a Digitális akkumulátor-útlevélben – a SoH-tól a CO₂-lábnyomig.

szerző: QR3 Redaktion

Digitális akkumulátor-útlevél: így tartsa naprakészen adatait

Miért nem elég „egyszer feltölteni”?

A Digitális akkumulátor-útlevél (DBP) nem statikus adatlap. A Batterieverordnung (EU) 2023/1542 kifejezetten előírja, hogy bizonyos adatpontoknak az akkumulátor teljes életciklusa alatt frissíthetőnek kell maradniuk. Aki az útlevelét egyszer, forgalomba hozatalkor feltölti, majd többé nem nyúl hozzá, nem teljesíti maradéktalanul a követelményeket — és 2027. február 18-tól komoly megfelelőségi problémákat kockáztat.

Ez magától értetődőnek hangzik, a gyakorlatban azonban jelentős operatív problémát jelent. A Minespider 2026-os megvalósítási jelentése két strukturális gyenge pontot azonosít, amelyek az egész iparágon átívelnek: az ellátási lánc mentén jelentkező adattöredezettséget, valamint a dinamikus adatfrissítésekhez szükséges folyamatok hiányát. Mindkét probléma megoldható — de csak világos műszaki és szervezeti stratégiával.


Mikor és minek kell változnia: a három frissítési kategória

A DBP-ben szereplő adatmezőkre nem ugyanazok a frissítési kötelezettségek vonatkoznak. Érdemes kezdettől fogva három kategóriát megkülönböztetni:

1. Statikus törzsadatok (egyszer, forgalomba hozatalkor)

Ide tartozik a kémiai összetétel, a cellatechnológia, a gyártó azonosítása és a sorozatszám. Ezeket a mezőket az első feltöltéskor állítják be, és nem változnak. Ezek alkotják az útlevél változatlan magját.

2. Tételspecifikus CO₂-adatok (egyszer, de részletesen)

A termékspecifikus CO₂-lábnyomot (PCF) az ISO 14067-kompatiblen módszerei szerint kell kiszámítani, és tételszinten kell megadni. Az Európai Bizottság JRC-tervezete egyértelművé teszi: a különböző gyártóüzemek adatainak összevonása nem megengedett. Minden akkumulátormodell minden gyártóhelyhez saját PCF-értéket kap. Ez azt jelenti, hogy minden új tétel esetén új adatrekordot kell létrehozni, és azt össze kell kapcsolni a megfelelő útlevéllel — az előző modell egyszerű másolása nem megfelelő.

A gyakorlatban ez azt jelenti: ha az Ön gyártási rendszere nem szolgáltat tételspecifikus CO₂-számításokat, akkor az útlevél feltöltése előtt módosítani kell az upstream folyamatot.

3. Állapotadatok (folyamatosan, a teljes életciklus alatt)

Ez a legnagyobb kihívást jelentő kategória. A State of Health (SoH) és a State of Charge (SoC) minden töltési és kisütési ciklussal változik. A második életükben — például az elektromos járműben való használat után helyhez kötött tárolóként — továbbhasznált akkumulátorok esetében a naprakész állapotadatok nemcsak szabályozási szempontból előírtak, hanem gazdasági jelentőséggel is bírnak: megbízható SoH-adatok nélkül nem határozható meg tisztességes piaci érték a second-life piacon.


A műszaki megvalósítás: három megközelítés összehasonlítása

Hogyan kerülnek az adatok az útlevélbe? És hogyan maradnak naprakészek? Ehhez alapvetően három architektúra-megközelítés áll rendelkezésre:

Megközelítés Alkalmas Előny Kockázat
Push REST API-n keresztül Saját MES/ERP-rendszerrel rendelkező gyártók Teljesen automatikus, valós időre alkalmas Függőség a belső IT-infrastruktúrától
Tömeges import (CSV/JSON) API-kapcsolattal nem rendelkező beszállítók Alacsony belépési küszöb Manuális hibalehetőségek, késések
Érzékelőtől a DPP-ig (IoT) Helyhez kötött tárolók, flottamenedzsment Folyamatos SoH-frissítés Összetett adatfolyam, szigorú késleltetési követelmények

A legtöbb gyártó számára a hibrid megközelítés lesz célszerű: a törzs- és PCF-adatok tömeges importtal vagy API-n keresztül érkeznek az ERP-ből, míg az állapotadatokat IoT-adatfolyam frissíti.

API-frissítés: minimális példa

Aki REST API-t használ az állapotadatok frissítésére, annak verziózott végpontstruktúrát kell alkalmaznia, amely támogatja a részleges frissítéseket (PATCH) is:

// 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',
    }),
  }
);

Az időbélyeg (measuredAt) nem opcionális mező — alapvető fontosságú a nyomon követhetőség és a piacfelügyeleti hatóságok általi ellenőrzés szempontjából.


Interoperabilitás: szabványok, nyilvántartás és tesztkörnyezet

Egy frissítés keveset ér, ha a fogadó csomópont nem érti az adatokat. Pontosan erre irányul a szabványosítási munka. 2026. június 25-én a CEN és a CENELEC nyilvános webináriumot tartott az újonnan közzétett DPP-szabványokról, az EN 18216-tól az EN 18223-ig. A JTC 24 műszaki bizottság által kidolgozott hat szabvány az interoperabilitás és az adatkonszisztencia termékeken átívelő keretrendszerét határozza meg — vagyis pontosan azt a réteget, amelyen a frissítési folyamatokat szabványosítani kell.

Ezzel párhuzamosan a BatteryPass-Ready konzorcium 2026. június 24-én nyilvános tesztkörnyezetet indított a Digitális akkumulátor-útlevélhez. A gyártók, beszállítók és szoftverszolgáltatók a tényleges üzem megkezdése előtt validálhatják ott megvalósításaikat a szabályozási követelményekkel szemben. Aki frissítési folyamatokat épít ki, annak érdemes korán igénybe vennie ezt a környezetet az adatformátumok és az API-kompatibilitás tesztelésére.

Az EU központi DPP-nyilvántartása

Az Európai Bizottság egy központi nyilvántartáson dolgozik, amelyben minden DPPs regisztrálható és kereshető lesz. Az Orgalim — a technológiai ipar európai szövetsége — egyértelmű ajánlásokat tett közzé ezzel kapcsolatban: a nyilvántartásnak támogatnia kell a nagy volumenű, automatizált regisztrációs folyamatokat, és védettnek kell lennie az üzemkimaradásokkal szemben. A frissítési folyamatok szempontjából ez azt jelenti: belső architektúrájának akkor is működnie kell, ha a központi nyilvántartás átmenetileg nem érhető el — vagyis helyi gyorsítótárazást és újrapróbálkozási logikát kell tervezni.

A fizikai akkumulátor és a digitális útlevél összekapcsolása a gyakorlatban egy GS1 Digital Link segítségével történik — ez egy szabványos URI, amely a GTIN-t és a sorozatszámot kódolja, és a kapcsolódó adatrekordra mutat. Ezt a hivatkozást tipikusan az akkumulátor címkéjén található QR-kód kódolja.


Szervezeti előfeltételek: ki felelős a frissítésekért?

A rendelet elsősorban azt a gazdasági szereplőt szólítja meg, aki az akkumulátort forgalomba hozza. Az állapotadatok azonban gyakran a gyártótól távol keletkeznek — a flottakezelőnél, az újrahasznosító vállalatnál vagy a second-life szolgáltatónál. Az írási jogosultságok kérdése ezért nem pusztán műszaki jellegű: szerződésben kell szabályozni.

A következő szerepköröket egyértelműen meg kell határozni az irányítási struktúrában:

  • Adattulajdonos: Ki írhatja és írhatja felül az egyes mezőket?
  • Auditnyom: Minden módosítást időbélyeggel és a végrehajtó szereplővel kell naplózni — nemcsak megfelelőségi okokból, hanem a second-life piacon felmerülő viták miatt is.
  • Vészhelyzeti folyamat: Mi történik, ha egy érzékelő meghibásodik, vagy egy beszállító nem szolgáltat adatot?

A Bureau Veritas és a Circulor közötti partnerséghez hasonló megoldások azt mutatják, hogyan működnek együtt az ellenőrző szervezetek és az adatszolgáltatók e kormányzási hiányosságok megszüntetése érdekében. Hasonló pozíciót foglal el a Securikett a Codikett 2.0 platformjával: hamisításbiztos címkék, amelyek fizikailag összekapcsolják az adatrekordot a termékkel, és megnehezítik az illetéktelen írási hozzáférést.


Ellenőrzőlista: frissítési készenlét 2027 februárjáig

Mielőtt DBP-folyamatát „késznek” tekintené, ellenőrizze a következő pontokat:

  • A PCF-számítás tételszinten van megvalósítva (nem modell szerint aggregálva)
  • A SoH/SoC-adatfolyam ki van építve és tesztelve
  • Az API-végpontok támogatják az időbélyeggel ellátott részleges frissítéseket (PATCH)
  • Az írási jogosultságokat szerződésben szabályozták minden érintett szereplővel
  • A nyilvántartás kiesésére vonatkozó újrapróbálkozási logika megvalósult
  • A megvalósítást validálták a BatteryPass-Ready tesztkörnyezetében
  • A GS1 Digital Link megfelelően van kódolva a címkén és a QR-kódban

2027 februárja közeledik. Aki csak akkor építi ki a frissítési folyamatokat, amikor a kötelezettség hatályba lép, rá fog jönni, hogy az igazi munka nem az útlevél feltöltése — hanem annak éveken át történő, szabályos működtetése.

Források