Az akkumulátor-útlevél 2027. február 18-tól kötelező, és ezzel együtt megjelent egy kérdés, amire eddig nem volt jó válasz: honnan tudod, hogy a szolgáltatód rendszere tényleg megfelel? Egy „szabványkövető vagyok" mondat semmit nem ér. Ezért a BatteryPass-Ready projekt — a 2025 februárjában lezárult Battery Pass utódja, német szövetségi finanszírozással — közzétett egy megfelelőségi vizsgálatot a CEN-CENELEC JTC24 adatmodelljéhez — mi pedig végigcsináltuk: nulláról tizenegy zöld tesztig. Ez a cikk arról szól, mit mértünk közben, mit rontottunk el, és mit érdemes ebből tudnod, akár nálunk vagy, akár máshol.
A séma-validáció és a megfelelőségi vizsgálat nem ugyanaz
A kettőt könnyű összekeverni, pedig egészen mást bizonyítanak.
| Séma-validáció | Megfelelőségi vizsgálat | |
|---|---|---|
| Mit néz? | egy beküldött fájlt | egy futó rendszert, hálózaton keresztül |
| Mire válaszol? | „a leadott adat helyes-e" | „a rendszer úgy viselkedik-e, ahogy a szabvány előírja" |
| Mit NEM lát? | a hiányzó mezőket, a jogosultságokat, a verziózást, a kimenő bejelentéseket | — |
| Mennyi idő? | másodpercek | a rendszert elő kell készíteni: teszt-adapter, hitelesítés, külső szolgáltatók |
A vizsgálat nem fájlt kér tőled, hanem felhív. Előkészíti az állapotot (beszúr útleveleket, kiállít egy hozzáférési tokent), majd lefuttatja a forgatókönyveket a te éles felületeden. Ez sokkal többet bizonyít — és sokkal nehezebb is átmenni rajta.
A legnagyobb tanulság: a zöld validátor nem jelent lefedettséget
A saját akkumulátor-útlevelünk hónapokig „minden teszten átment" a hivatalos validátornál. Ebből azt hittük, hogy a modellünk teljes. Aztán megmértük másképp: fogtuk a hivatalos adatmodell összes levél-mezőjét, és megnéztük, hányat tudunk ténylegesen kiadni.
Az eredmény: a 211-ből 129-et. Vagyis 61%.
Nyolcvankét mező hiányzott — köztük tizennégy olyan mezőcsoport, amit a sémánk egyáltalán nem ismert: az abszolút szénlábnyom, a tanúsított és a maradék hasznos energia, a kadmium/ólom jelölés, a jótállás időtartama, az üzembe helyezés dátuma, a túltöltési és mélykisütési események száma, az ellátási lánc kockázati mutatói. És — ez a legbeszédesebb — az anyagonkénti újrahasznosított tartalom (kobalt, lítium, nikkel, ólom), amit valójában tároltunk, csak más alakban, és emiatt nem képeztük le.
Miért nem szólt erről semmi? Mert a validátor azt vizsgálja, hogy amit leadtál, az helyes-e — nem azt, hogy elég-e. Egy hiányzó opcionális mezőt soha nem fog panaszolni. Ez a legveszélyesebb hibafajta: nyugtat, miközben nincs rá alapod.
Azóta a lefedettséget külön eszköz méri nálunk, és teszt őrzi, hogy ne tudjon némán visszaesni. Jelenleg 100% — egyetlen mezőt hagyunk ki szándékosan, azt is indoklással: a tartalmi specifikáció azonosítójának formátumát a séma nem írja le, és a hivatalos mintadokumentum sem tartalmazza, kitalált azonosítót pedig nem küldünk.
A 11 teszt — és mit jelentenek a gyakorlatban
| Teszt | Mit ellenőriz | Mit jelent a gyakorlatban |
|---|---|---|
| Olvasás azonosítóval | a DPP-azonosítóra pontosan a hozzá tartozó útlevél jön vissza | nem keveredhet össze két útlevél |
| Olvasás termékazonosítóval | a termék aktív verzióját adja | mindig a hatályos adat megy ki, nem egy régi verzió |
| Adatelem olvasása | egyetlen mező kiolvasható önállóan | a partner nem kényszerül a teljes dokumentum letöltésére |
| Hozzáférés-szűrés | a szerepkör szerint mezőnként szűrődik a válasz | a nyilvánosság nem lát olyat, amit nem szabad |
| Visszavont útlevél | a visszavont útlevél nem adható ki normál olvasáson | érvénytelen adat nem kering tovább |
| Teljes módosítás | a módosítás új, ellenőrizhető verziót hoz létre | visszakövethető, mi mikor változott |
| Adatelem módosítása | egy mező pontosan változik, a többi nem | nincs mellékhatás, nem sérül más adat |
| Attribútum hozzáadása | új al-mező felvehető | az útlevél bővíthető, nem befagyott |
| Attribútum törlése | a null érték törli a mezőt | a téves adat eltávolítható, nem csak felülírható |
| Jogosultság-ellenőrzés | írási jog nélkül nem lehet módosítani | nem írhat bele bárki, akinek olvasási linkje van |
| Piacra hozatal | elment-e a másolat a mentés-szolgáltatóhoz, és megtörtént-e a regiszter-bejelentés | a kötelezettség nem nyilatkozat kérdése — ellenőrzik |
Az utolsó sor a legfontosabb. Az (EU) 2023/1542 nem elégszik meg azzal, hogy az adat nálad megvan: független szolgáltatónál is tárolni kell, a piacra hozatalt pedig jelenteni kell. A vizsgálat nem a nyilatkozatodat nézi — hanem azt, hogy a hívás valóban elment-e.
Amit mi rontottunk el — hét konkrét eset
Ez a rész a leghasznosabb, ha te is integrálsz. Minden tétel valódi, mért hiba, nem elmélet; egyik sem derült volna ki séma-validációból.
1. A hibaüzenet alakja is szabvány
A saját {"error":{"code","message"}} alakunkkal indultunk. A specifikáció viszont egy message tömböt vár, elemenként típussal, szöveggel, kóddal és időbélyeggel. Aki a saját hibaformátumát adja, a hibakezelő teszteken bukik — és a partnere sem fogja tudni gépileg értelmezni.
2. Az adatelem-választ a mező NEVÉBE kell csomagolni
Amikor egyetlen adatelemet kérnek, nem a puszta objektumot kell visszaadni, hanem a mező neve alatt:
| Rossz | Jó |
|---|---|
{ "name": "…", "postalAddress": "…" } |
{ "economicOperatorInformation": { "name": "…" } } |
Tartalmilag bitre ugyanazt az adatot adtuk vissza, mégis elbukott — és sokáig értetlenül néztük, míg ki nem írattuk a tesztvezérlő saját eltérés-jelentését.
3. A „módosítva" időbélyeg nem a kiszolgálás pillanata
Ez volt a legalattomosabb. A lastUpdated mezőbe a kiszolgálás idejét írtuk, így két egymás utáni olvasás soha nem adott azonos dokumentumot. Az összehasonlító tesztek (a mi másolatunk ↔ a mentés-szolgáltatónál lévő példány) emiatt másodperc-szerencsétől függtek: hol átmentek, hol nem. Aki ilyet lát a saját rendszerében, ne a hálózatot gyanúsítsa — a mező jelentése az útlevél tényleges módosítási ideje.
4. A visszavont útlevél mindenkinek 404
Azt feltételeztük, hogy a gazdasági szereplő a saját visszavont útlevelét lássa. Tévedés: ezen a gépi felületen a visszavont útlevél senkinek nem adható ki, a tulajdonosnak sem. Megőrizni természetesen meg kell (a hatóság visszamenőleg is kérheti), de a normál olvasás nem szolgálhatja ki.
5. A visszavont állapot a dokumentumból jön
A vizsgálat egy archivált állapotú dokumentumot szúr be, és a státusz magában a dokumentumban áll — nem külön parancs-mezőben. Ha ezt nem veszed át, az útlevél aktívként jön létre, és a „visszavont nem olvasható" vizsgálatnak nincs mit vizsgálnia.
6. Szerepkör-hiány: 401, nem 403
Szemantikailag a 403 (Tiltott) a helyes válasz arra, hogy valaki hitelesítve van, de nincs írási joga. A vizsgálat szótárában viszont ez az eset „Unauthorized", és a 403-ra a tesztvezérlő hibára fut — a választ meg sem vizsgálja. A hivatalos specifikáció a módosításhoz nem is sorol fel 403-at.
7. A regiszter nem a dokumentumot várja
A piacra hozatal bejelentésénél a teljes útlevelet küldtük be. A regiszter viszont három azonosítót kér: Product_ID, Backup_ID, Operator_ID. A Backup_ID az, amit a mentés-szolgáltatótól kapsz vissza — vagyis a sorrend kötött: előbb menteni kell, csak utána bejelenteni. Ez a szabványból nem olvasható ki, csak a hibából.
Ráadásul a mentés-szolgáltató egy nála nem létező útlevélre küldött módosításra 401-et ad, nem 404-et — vagyis a hibakódra nem lehet „ez még nincs fent" logikát építeni. Nálunk ezért a mentés mindkét irányban átvált létrehozás és módosítás között.
A hozzáférési szintek: a legcsendesebb hibaforrás
A JTC24 adatmodell mezőnként megmondja, kinek mit szabad látnia. Ez nem díszítés: a rendeletből következik, és a vizsgálat mezőnként végigméri.
Nálunk négy eltérést talált egy külön erre írt audit. Hármat kiadtunk a nyilvánosságnak, pedig nem lett volna szabad:
- a gazdasági szereplő azonosítója — csak bejelentett szervezet, hatóság és a Bizottság láthatja;
- a gyártó létesítmény azonosítója — ugyanaz a kör;
- a katód-, anód- és elektrolit-anyagok — a javítóknak, újrahasznosítóknak és a vásárlónak jár, a nyilvánosságnak nem.
A negyedik fordítva állt: az átvilágítási jelentést mi elrejtettük, pedig a rendelet szándéka szerint nyilvános. Ez is hiba — csak épp az ellenkező irányba.
Miért veszélyes ez a terület? Mert a hiba néma. Ha egy mező tévedésből nyilvános, semmi nem hibázik, semmi nem jelez, a lap tökéletesen működik — csak több adat megy ki, mint amennyi szabad. Ezt kizárólag célzott méréssel lehet megtalálni.
Ami nem is a szabványon múlt
A tesztek nagy része sokáig azon bukott, hogy a kimenő hívásaink egyáltalán nem értek célba. A hibaüzenet ennyi volt: unable to get local issuer certificate. A kiszolgálónk HTTP-kliensének nem volt használható gyökértanúsítvány-tára, miközben a másik oldal tanúsítvány-lánca hibátlan.
Ez azért tanulságos, mert minden kifelé menő hívást érint — a fizetési szolgáltatót, a levélküldést, a webhookokat is —, és a hiba a másik végén látszik: ott egyszerűen nem történik semmi. Ha a rendszered „bejelentett", de a partnernél nincs nyoma, ezt érdemes először megnézni.
Két tanulság: a gyökértanúsítványokat vidd magaddal a kiszolgálón ne bízz —, és a tanúsítvány-ellenőrzést soha ne kapcsold ki. Útlevél-adatot küldesz ki; egy ellenőrizetlen kapcsolat pont azt a bizalmat törné meg, amiért az egész rendszer van.
„Menthető" és „jogilag teljes" — két külön dolog
Zárásképp egy tanulság, ami nem a szabványról szól, hanem a szoftverről. Minden rendszernek van egy technikai minimuma: az a néhány mező, ami nélkül nem születik értelmes rekord (név, cikkszám, kategória). Nálunk ez 12 mező.
Kitöltöttük pontosan ezt a tizenkettőt egy EV-akkumulátorra, és megmértük a jogszabályi teljességet. Az eredmény: 17%. Ötvennyolc mező hiányzott.
Ha a felület ezt a tizenkettőt „kötelezőnek" hívja, azt üzeni, hogy ennyivel kész vagy — pedig a bírságot nem ez dönti el. Ezért nálunk a szerkesztő ma mentés előtt figyelmeztet, ha az útlevél jogilag hiányos: megmutatja a százalékot, a hiányzó mezőket és a jogforrást. Nem tilt — az adat gyakran szakaszosan gyűlik, és nem a szoftver dolga eldönteni, mikor „kész" egy útlevél —, de nem is engedi csendben kimenni.
Ha szolgáltatót választasz, ezt a különbséget érdemes megkérdezned: a rendszer figyelmeztet-e, ha jogilag hiányos útlevelet adok ki?
Mit NEM jelent a zöld pipa?
Fontos, hogy ezt is kimondjuk, mert a piacon sok a félreérthető állítás:
- Nem hatósági tanúsítvány. A vizsgálat az iparági konzorcium eszköze, nem uniós akkreditáció. Attól, hogy egy rendszer átmegy, még nem „EU-tanúsított".
- Nem a te adatodra vonatkozik. Azt méri, hogy a rendszer megfelelően viselkedik — nem azt, hogy a te útleveled tartalmilag hiánytalan. Az továbbra is a te felelősséged.
- Nem helyettesíti a regisztrációt. Az akkumulátorokra vonatkozó uniós szemantikai katalógus még nem él; amíg nincs, senki nem tud akkumulátor-útlevelet ténylegesen bejegyezni.
- Nem örök. Az adatmodellnek verziói és profiljai vannak; a 2027 februárjától kötelező halmaz szűkebb, mint a teljes modell. Ami ma megfelel, azt a következő verziónál újra kell mérni.
Hét kérdés a szolgáltatódhoz
Ha akkumulátor-útlevelet kell kiadnod, ezek néhány perc alatt kiderítik, hol tart egy rendszer:
- Átmegy a hivatalos megfelelőségi vizsgálaton? Melyik tesztek zöldek? A „szabványkövető" önmagában nem válasz.
- A hivatalos adatmodell hány százalékát tudja kiadni? A séma-validátor erre nem válaszol — ezt külön kell mérni.
- Mezőnként kezeli a hozzáférési szinteket? Kérj konkrét példát: ki látja a gazdasági szereplő azonosítóját?
- Elmegy a másolat a mentés-szolgáltatóhoz, és van-e róla visszakereshető nyom? A „bejelentettük-e" kérdésre igazolható választ kell tudni adni.
- Mi történik a visszavont útlevéllel? Megmarad-e a hatóság számára, de kikerül-e a normál olvasásból?
- Figyelmeztet-e, ha jogilag hiányos útlevelet adok ki? Vagy csendben engedi?
- Mi történik az adatommal, ha szolgáltatót váltok? Az útlevél URL-je a termékhez tartozik, nem a szolgáltatóhoz — erről külön is írtunk a szolgáltatóváltásról szóló cikkben.
Hol tart a Veridyn?
A rendszerünk a BatteryPass-Ready megfelelőségi vizsgálat mind a 11 tesztjén átmegy — háromszor egymás után megismételve, hogy ne a szerencse döntsön —, és a hivatalos adatmodell minden leképezhető mezőjét ki tudja adni. A vizsgálat nem fájlt néz: a futó rendszert szólítja meg, ugyanazon a szabványos felületen (CEN-CENELEC JTC 24 életciklus-API, EN 18222), amit az akkumulátor-ökoszisztéma többi szereplője használ.
A gépi felület leírását a fejlesztői dokumentációban találod, működés közben pedig az élő demóban nézheted meg — ott a JTC24-dokumentum le is tölthető. Ha akkumulátor-útlevelet kell kiadnod, indíts egy ingyenes fiókot.
A számokat — a 11 teszt egyenként, a hivatalos adatmodell lefedettsége adatcsoportonként, a kiadott profilok és egy letölthető minta-dokumentum — az akkumulátor-útlevél lapunkon tettük egy helyre.