A digitális termékútlevél naprakészen tartása: így működnek az DPP-frissítések

Miért nem elég egyszer kitölteni?

A digitális termékútlevél (DPP) nem statikus PDF-fájl, amelyet egyszer létrehoznak, majd archiválnak. A 2023/1542/EU akkumulátorrendelet kifejezetten előírja, hogy bizonyos adatpontoknak az akkumulátor teljes életciklusa során frissíthetőnek kell maradniuk. Aki forgalomba hozatalkor kitölti az útlevelet, majd többé nem nyúl hozzá, nem tesz teljes mértékben eleget ezeknek a követelményeknek — és 2027. február 18-tól komoly megfelelőségi problémákat kockáztat.

Ez triviálisnak hangzik, de nem az. A Minespider 2026-os megvalósítási jelentése két strukturális gyenge pontot azonosít, amelyek az egész iparágban jelen vannak: az ellátási lánc menti adatszéttagoltságot és a dinamikus adatfrissítésekhez szükséges folyamatok hiányát. A kettő együtt megnehezíti egy DPP működés közbeni konzisztens naprakészen tartását.

Ez a cikk bemutatja, mely adatoknak mikor kell változniuk, hogyan néz ki a frissítések technikai infrastruktúrája, és milyen szervezeti folyamatokat kell a gyártóknak és az üzemeltetőknek most kiépíteniük.

Mi változik — és mikor?

Statikus és dinamikus adatpontok

Egy DPP minden mezője nem egyformán változékony. Nagyjából két kategóriát különböztethetünk meg:

A statikus adatokat a forgalomba hozatalkor rögzítik, és ezt követően rendszerint már nem változnak:

• Anyagösszetétel és veszélyes anyagok
• Gyártói azonosító és gyártási helyszín
• A piaci bevezetés időpontjában érvényes tanúsítványok

A dinamikus adatok ezzel szemben a termék életútja során változnak:

• State of Health (SoH) és State of Charge (SoC) akkumulátoroknál — mindkét érték minden töltési és kisütési ciklussal változik
• Javítási és karbantartási előzmények
• Tulajdonosváltások és helyszínadatok
• Az első életciklus végén végzett újrafeldolgozási vizsgálatok eredményei

Különösen azoknál az akkumulátoroknál, amelyek elektromos járműben való használatuk után helyhez kötött tárolóként második életet kezdenek, a naprakész állapotadatok nemcsak szabályozási szempontból kötelezőek, hanem gazdaságilag is jelentősek: egy másodlagos tároló üzemeltetőjének tudnia kell, hogy ténylegesen mekkora fennmaradó kapacitást vásárol.

A kötelező frissítések kiváltói

A rendelet nem határoz meg pontos frissítési időközöket, de meghatároz olyan eseményeket, amelyek frissítést váltanak ki:

• Karbantartás vagy javítás befejezése
• Átmenet egy új használati szakaszba (első életciklus → második életciklus)
• A tulajdonos vagy az üzemeltető megváltozása
• Új mérési értékek a BMS-rendszerekből (Battery Management System)
• Visszahívás vagy biztonsági tájékoztató

Aki ezeket az eseményeket nem rögzítette belső folyamatában, az a napi üzletmenet során figyelmen kívül fogja hagyni őket.

Az DPP-frissítések technikai architektúrája

Az GS1 Digital Link mint stabil horgony

A fizikai akkumulátor és a digitális útlevél összekapcsolása egy GS1 Digital Link segítségével történik — ez egy szabványos URI, amely kódolja az GTIN-t és a sorozatszámot, és a hozzá tartozó adatrekordra mutat. A lényeg: a terméken található hivatkozás (például QR-kódként rányomtatva) változatlan marad. Csak az általa elérhető adatrekord frissül.

Egy akkumulátor tipikus GS1 Digital Link-ja így néz ki:

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

• 01 = GTIN-minősítő
• 04012345678901 = az akkumulátor GTIN-ja
• 21 = sorozatszám-minősítő
• ABC-0042 = egyedi sorozatszám

Ez egy kizárólag szemléltető példa-URL, amely az GS1 Digital Link URI-sémáját mutatja be. Az ilyen URL mögötti feloldó az aktuális DPP-adatrekordra irányít. Ha az adatrekord megváltozik, a terméken lévő QR-kód változatlan marad — csak a háttérrendszerben lévő cél frissül. Ez a dinamikus adatkarbantartás koncepcionális lényege.

API-alapú frissítések: az alapelv

A modern DPP-platformok REST API-kat biztosítanak, amelyeken keresztül az adatpontok célzottan frissíthetők anélkül, hogy a teljes útlevelet újra kellene írni. Egy DPP API ellen indított tipikus PATCH-kérés így nézhet ki:

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"
}

A teljes PUT-tal szembeni előny: csak a megváltozott mezők kerülnek továbbításra, a verziókezelés nyomon követhető marad, és az auditnapló sem növekszik szükségtelenül.

Verziókezelés és auditnyom

Az EN 18216–18223 szabványok, amelyeket a CEN és a CENELEC 2026. június 25-én egy nyilvános webináriumon mutatott be, az adatkonszisztenciára és az interoperabilitásra vonatkozó követelményeket határoznak meg. Ez közvetve a módosítások nyomon követhetőségét is magában foglalja: ki, mikor, melyik értéket módosította, és milyen alapon?

Egy minimális verziókezelési stratégiának frissítési eseményenként a következő mezőket kell tárolnia:

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

E nyom nélkül vita esetén nem bizonyítható, hogy az adatok a kérdéses időpontban helyesek voltak.

Szervezeti folyamatok: mit kell most kiépíteniük a vállalatoknak?

Az adatfelelősség tisztázása

A legnagyobb gyakorlati probléma nem technikai jellegű. Hanem az a kérdés, hogy a vállalaton belül ki felel az egyes adatpontokért — és ki indítja el szükség esetén a frissítést.

Ajánlott egy egyszerű RACI-mátrix, amely minden dinamikus adatponthoz rögzíti:

• Responsible: Ki hajtja végre a frissítést?
• Accountable: Ki felel a hatóság felé?
• Consulted: Ki szolgáltatja a mérési adatokat?
• Informed: Kit kell értesíteni a változásokról?

Az ellátási lánc bevonása

Számos dinamikus adat nem a gyártónál, hanem beszállítóknál, karbantartó vállalkozásoknál vagy flottakezelőknél keletkezik. A gyártó azonban szabályozási szempontból továbbra is felelős az útlevél helyességéért. Ehhez egyértelmű szerződéses szabályozásra és olyan technikai interfészekre van szükség, amelyeken keresztül harmadik felek adatokat szolgáltathatnak — meghatározott formátumokkal és validálási szabályokkal.

A BatteryPass-Ready konzorcium, amely 2026. június 24-én nyilvános tesztkörnyezetet indított, pontosan ehhez kínál semleges validációs platformot: a vállalatok a DPP-megoldásaikat a szabályozási követelményekkel szemben tesztelhetik, mielőtt éles üzembe állítanák őket.

A központi nyilvántartás figyelemmel kísérése

Az Európai Bizottság egy központi nyilvántartáson dolgozik, amelyben minden DPP-t regisztrálni és kereshetővé kívánnak tenni. Az Orgalim — a technológiai ágazat európai iparági szövetsége — ezzel kapcsolatban egyértelmű ajánlásokat tett közzé: 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 vállalatok számára ez azt jelenti, hogy frissítési folyamataiknak nemcsak a saját platformjukkal kell működniük, hanem perspektivikusan a központi uniós nyilvántartással is szinkronizálhatónak kell lenniük. Aki most védett, elszigetelt megoldásokra épít, későbbi migrációs ráfordítást vállal magára.

Gyakorlati ellenőrzőlista a frissítési folyamathoz

Az első DPP éles üzembe állítása előtt a következő pontokat kell tisztázni:

1. Adatpontok osztályozva: Mely mezők statikusak, melyek dinamikusak?
2. Kiváltók meghatározva: Mely események váltanak ki kötelező frissítést?
3. API-hozzáférések szabályozva: Ki, mely mezőket és mely interfészen keresztül módosíthatja?
4. Auditnyom megvalósítva: Minden módosítást időbélyeggel, szerzővel és korábbi értékkel együtt tárolnak.
5. Ellátásilánc-interfészek tesztelve: A külső adatszolgáltatók érvényes frissítéseket tudnak beküldeni.
6. Nyilvántartás-kompatibilitás ellenőrizve: A saját rendszer képes kommunikálni a jövőbeli uniós nyilvántartással.
7. Tesztkörnyezet használva: Az interoperabilitási teszteket a BatteryPass-Ready tesztplatformján vagy azzal egyenértékű környezetekben végezték el.

Összegzés

A DPP nem dokumentum, hanem élő adatrekord. A 2023/1542/EU akkumulátorrendelet szabályozási követelményei e tekintetben egyértelműek: a dinamikus adatpontokat a teljes termék-életciklus alatt naprakészen kell tartani. Aki nem építi ki időben az ehhez szükséges technikai és szervezeti infrastruktúrát, nem fog megfelelőséget biztosítva eleget tenni a 2027. február 18-i határidőnek.

A jó hír: az építőelemek rendelkezésre állnak. Az GS1 Digital Link megoldja az azonosítási problémát, a REST API-k lehetővé teszik a részletes frissítéseket, a BatteryPass-Readyhez hasonló kezdeményezések pedig tesztinfrastruktúrát kínálnak. Sok vállalatnál a belső folyamatok és az adatfelelősség egyértelmű kijelölése hiányzik — ezért a munkát éppen ott kell elkezdeni.