Digitalni potni list izdelka vedno posodobljen: Tako delujejo posodobitve DPP

Uredba EU o baterijah zahteva dinamično vzdrževanje podatkov. Kdor svoj DPP izpolni enkrat, tvega težave s skladnostjo od februarja 2027. Praktični vodnik.

avtor QR3 Redaktion

Digitalni potni list izdelka vedno posodobljen: Tako delujejo posodobitve DPP

Zakaj enkratno izpolnjevanje ni dovolj

Digitalni potni list izdelka (DPP) ni statična datoteka PDF, ki jo enkrat ustvarimo in nato arhiviramo. Uredba o baterijah (EU) 2023/1542 izrecno določa, da morajo nekateri podatkovni elementi ostati posodobljivi v celotnem življenjskem ciklu baterije. Kdor svoj potni list izpolni ob dajanju na trg in ga nato ne posodablja več, teh zahtev ne izpolnjuje v celoti — in od 18. februarja 2027 tvega resne težave s skladnostjo.

To se sliši preprosto, vendar ni. Poročilo o implementaciji Minespider za leto 2026 opredeljuje dve strukturni šibkosti, ki se pojavljata v celotni panogi: fragmentacijo podatkov vzdolž dobavne verige in pomanjkanje procesov za dinamične posodobitve podatkov. Zaradi obojega je težko DPP med delovanjem ohranjati skladnega.

Ta članek pojasnjuje, kateri podatki se morajo spremeniti in kdaj, kako je videti tehnična infrastruktura za posodobitve ter katere organizacijske procese bi morali proizvajalci in upravljavci vzpostaviti že zdaj.


Kaj se spreminja — in kdaj

Statični in dinamični podatkovni elementi

Vsa polja v DPP niso enako spremenljiva. Na splošno lahko ločimo dve kategoriji:

Statični podatki se določijo ob dajanju na trg in se praviloma pozneje ne spreminjajo več:

  • Sestava materialov in nevarne snovi
  • Identifikacija proizvajalca in proizvodna lokacija
  • Certifikati ob uvedbi na trg

Dinamični podatki pa se spreminjajo s potekom življenjske dobe izdelka:

  • Stanje zdravja (SoH) in stanje napolnjenosti (SoC) baterij — obe vrednosti se spreminjata z vsakim ciklom polnjenja in praznjenja
  • Zgodovina popravil in vzdrževanja
  • Spremembe lastnika in podatki o lokaciji
  • Rezultati pregledov obnove ob koncu prve življenjske dobe

Zlasti pri baterijah, ki po uporabi v električnem vozilu začnejo drugo življenjsko dobo kot stacionarni hranilniki, so aktualni podatki o stanju pomembni ne le z regulativnega, temveč tudi z ekonomskega vidika: upravljavec sekundarnega hranilnika mora vedeti, koliko preostale zmogljivosti dejansko kupuje.

Sprožilci za obvezne posodobitve

Uredba ne določa natančnih intervalov posodabljanja, opredeljuje pa dogodke, ki sprožijo posodobitev:

  • Zaključek vzdrževanja ali popravila
  • Prehod v novo fazo uporabe (prva življenjska doba → druga življenjska doba)
  • Sprememba lastnika ali upravljavca
  • Nove merilne vrednosti iz sistemov BMS (Battery Management System)
  • Odpoklic ali varnostno obvestilo

Kdor teh dogodkov ni vključil v svoj notranji proces, jih bo pri vsakodnevnem delu spregledal.


Tehnična arhitektura za posodobitve DPP

Povezava med fizično baterijo in digitalnim potnim listom poteka prek GS1 Digital Link — standardiziranega URI-ja, ki kodira GTIN in serijsko številko ter kaže na pripadajoči zapis. Ključno je, da povezava na izdelku (npr. natisnjena kot koda QR) ostane nespremenjena. Posodablja se le zapis, na katerega kaže.

Tipičen GS1 Digital Link za baterijo je videti tako:

https://id.example.com/01/04012345678901/21/ABC-0042
  • 01 = kvalifikator GTIN
  • 04012345678901 = GTIN baterije
  • 21 = kvalifikator serijske številke
  • ABC-0042 = individualna serijska številka

Gre za povsem ilustrativen primer URL-ja, ki ponazarja shemo URI-ja GS1 Digital Link. Razreševalnik za takšnim URL-jem preusmeri na aktualni zapis DPP. Če se zapis spremeni, koda QR na izdelku ostane enaka — posodobi se le cilj v zalednem sistemu. To je konceptualno jedro dinamičnega vzdrževanja podatkov.

Posodobitve na podlagi API-ja: osnovno načelo

Sodobne platforme DPP zagotavljajo API-je REST, prek katerih je mogoče ciljno posodabljati podatkovne elemente, ne da bi bilo treba znova zapisati celoten potni list. Tipična zahteva PATCH za API DPP bi lahko bila videti tako:

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

Prednost v primerjavi s popolnim PUT-om je, da se prenesejo le spremenjena polja, različice ostanejo sledljive, revizijska dnevniška datoteka pa se ne povečuje po nepotrebnem.

Različice in revizijska sled

Standardi EN 18216 do 18223, ki sta jih CEN in CENELEC predstavila 25. junija 2026 na javnem spletnem seminarju, opredeljujejo zahteve za skladnost podatkov in interoperabilnost. To implicitno vključuje tudi sledljivost sprememb: kdo je kdaj spremenil katero vrednost in na kateri podlagi?

Minimalna strategija različic bi morala za vsak dogodek posodobitve shraniti naslednja polja:

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

Brez te sledi v primeru spora ni mogoče dokazati, da so bili podatki v zadevnem trenutku pravilni.


Organizacijski procesi: kaj morajo podjetja vzpostaviti zdaj

Razjasniti odgovornost za podatke

Največji praktični problem ni tehnične narave. Gre za vprašanje, kdo je v podjetju odgovoren za posamezne podatkovne elemente — in kdo po potrebi sproži posodobitev.

Priporočljiva je preprosta matrika RACI, ki za vsak dinamični podatkovni element določa:

  • Responsible: Kdo izvede posodobitev?
  • Accountable: Kdo je odgovoren do pristojnega organa?
  • Consulted: Kdo zagotovi merilne podatke?
  • Informed: Koga je treba obvestiti o spremembah?

Vključiti dobavno verigo

Veliko dinamičnih podatkov ne nastane pri proizvajalcu, temveč pri dobaviteljih, vzdrževalcih ali upravljavcih voznih parkov. Proizvajalec pa ostaja regulativno odgovoren za pravilnost potnega lista. To zahteva jasna pogodbena pravila in tehnične vmesnike, prek katerih lahko tretje osebe prispevajo podatke — z opredeljenimi formati in pravili preverjanja.

Konzorcij BatteryPass-Ready, ki je 24. junija 2026 zagnal javno testno okolje, ponuja prav za ta namen nevtralno validacijsko platformo: podjetja lahko svoje rešitve DPP preverijo glede na regulativne zahteve, preden jih uvedejo v produkcijsko okolje.

Spremljati centralni register

Evropska komisija pripravlja centralni register, prek katerega naj bi bili vsi DPP registrirani in jih bo mogoče poiskati. Orgalim — evropsko industrijsko združenje za tehnologijo — je v zvezi s tem objavilo jasna priporočila: register mora podpirati avtomatizirane registracijske procese velikega obsega in biti zaščiten pred izpadi delovanja.

Za podjetja to pomeni, da njihovi procesi posodabljanja ne smejo delovati le z njihovo lastno platformo, temveč se morajo v prihodnje znati sinhronizirati tudi s centralnim registrom EU. Kdor se zdaj odloči za lastniške izolirane rešitve, si ustvarja poznejše stroške migracije.


Praktični kontrolni seznam za proces posodabljanja

Preden gre prvi DPP v produkcijo, je treba razjasniti naslednje točke:

  1. Podatkovni elementi razvrščeni: Katera polja so statična in katera dinamična?
  2. Sprožilci opredeljeni: Kateri dogodki sprožijo obvezno posodobitev?
  3. Dostopi do API-ja urejeni: Kdo lahko katera polja spreminja prek katerega vmesnika?
  4. Revizijska sled uvedena: Vsaka sprememba se shrani s časovnim žigom, avtorjem in prejšnjo vrednostjo.
  5. Vmesniki dobavne verige preizkušeni: Zunanji dobavitelji podatkov lahko vnesejo veljavne posodobitve.
  6. Združljivost z registrom preverjena: Lastni sistem lahko komunicira s prihodnjim registrom EU.
  7. Testno okolje uporabljeno: Testna platforma BatteryPass-Ready ali enakovredna okolja so bila uporabljena za preizkuse interoperabilnosti.

Sklep

DPP ni dokument, temveč živ podatkovni zapis. Regulativne zahteve uredbe o baterijah (EU) 2023/1542 so v tem pogledu jasne: dinamične podatkovne elemente je treba ohranjati aktualne — v celotnem življenjskem ciklu izdelka. Kdor tehnične in organizacijske infrastrukture za to ne bo pravočasno vzpostavil, do roka 18. februarja 2027 ne bo mogel doseči skladnosti.

Dobra novica je, da so gradniki na voljo. GS1 Digital Link rešuje težavo identifikacije, API-ji REST omogočajo podrobne posodobitve, pobude, kot je BatteryPass-Ready, pa zagotavljajo testno infrastrukturo. V številnih podjetjih manjkajo predvsem notranji procesi in jasna dodelitev odgovornosti za podatke — prav tam bi se moralo delo začeti.