Digitalt batteripas: Sådan holder du dine data opdaterede

Hvorfor det ikke er nok at udfylde det én gang

Det digitale batteripas (DBP) er ikke et statisk datablad. Batteriforordningen (EU) 2023/1542 foreskriver udtrykkeligt, at bestemte datapunkter skal kunne opdateres gennem hele et batteris livscyklus. Den, der udfylder sit pas én gang ved markedsføringen og derefter ikke rører det igen, opfylder ikke kravene fuldt ud — og risikerer alvorlige compliance-problemer fra 18. februar 2027.

Det lyder som en selvfølge, men er i praksis et betydeligt operationelt problem. Minespiders implementeringsrapport fra 2026 identificerer to strukturelle svagheder, der går igen i hele branchen: datafragmentering langs forsyningskæden og manglende processer for dynamiske dataopdateringer. Begge problemer kan løses — men kun med en klar teknisk og organisatorisk strategi.

Hvad skal ændres hvornår: De tre opdateringskategorier

Ikke alle datafelter i DBP er underlagt de samme opdateringsforpligtelser. Det kan betale sig fra starten at skelne mellem tre kategorier:

1. Statiske stamdata (én gang ved markedsføring)

Det omfatter kemi, celleteknologi, producentidentifikation og serienummeret. Disse felter sættes ved den første udfyldning og ændres ikke. De udgør passets uforanderlige kerne.

2. Partispecifikke CO₂-data (én gang, men granulært)

Det produktspecifikke CO₂-aftryk (PCF) skal beregnes efter ISO 14067-kompatiblen metoder og angives på partiniveau. Europa-Kommissionens JRC-udkast præciserer: En aggregering på tværs af forskellige produktionsanlæg er ikke tilladt. Hver batterimodel får sin egen PCF-værdi pr. produktionssted. Det betyder, at der skal oprettes et nyt datasæt for hvert nyt parti og knyttes til det tilsvarende pas — ingen copy-paste fra den tidligere model.

I praksis betyder det: Hvis jeres produktionssystem ikke leverer partispecifikke CO₂-beregninger, skal den forudgående proces tilpasses, før passet overhovedet kan udfyldes.

3. Tilstandsdata (løbende, gennem hele livscyklussen)

Dette er den mest krævende kategori. State of Health (SoH) og State of Charge (SoC) ændrer sig med hver opladnings- og afladningscyklus. For batterier, der genanvendes i et andet liv — eksempelvis som stationært lager efter brug i et elektrisk køretøj — er aktuelle tilstandsdata ikke kun lovmæssigt påkrævede, men også økonomisk relevante: Uden pålidelige SoH-angivelser kan der ikke fastsættes en fair markedsværdi på second-life-markedet.

Den tekniske implementering: Tre tilgange sammenlignet

Hvordan kommer dataene ind i passet? Og hvordan holdes de aktuelle? Grundlæggende findes der tre arkitekturtilgange:

Tilgang	Egnet til	Fordel	Risiko
Push via REST-API	Producenter med eget MES/ERP	Fuldautomatisk, egnet til realtid	Afhængighed af intern IT-infrastruktur
Bulkimport (CSV/JSON)	Leverandører uden API-forbindelse	Lav adgangstærskel	Manuelle fejlkilder, forsinkelser
Sensor-to-DPP (IoT)	Stationære lagre, fleet management	Løbende SoH-opdatering	Kompleks datapipeline, høje krav til latenstid

For de fleste producenter vil en hybridtilgang være hensigtsmæssig: Stam- og PCF-data kommer via bulkimport eller API fra ERP-systemet, mens tilstandsdata tilføres via en IoT-pipeline.

API-opdatering: Et minimalt eksempel

Den, der bruger en REST-API til at opdatere tilstandsdata, bør anvende en versioneret endpoint-struktur, som også understøtter delvise opdateringer (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',
    }),
  }
);

Tidsstemplet (measuredAt) er ikke et valgfrit felt — det er afgørende for sporbarheden og kontrollen fra markedsovervågningsmyndigheder.

Interoperabilitet: Standarder, registry og testmiljø

En opdatering er ikke til megen nytte, hvis den modtagende node ikke forstår dataene. Det er netop her, standardiseringsarbejdet kommer ind i billedet. Den 25. juni 2026 afholdt CEN og CENELEC et offentligt webinar om de nyligt offentliggjorte DPP-standarder EN 18216 til EN 18223. Disse seks standarder, som er udarbejdet af den tekniske komité JTC 24, definerer den produktuafhængige ramme for interoperabilitet og datakonsistens — altså netop det lag, hvor opdateringsprocesser skal standardiseres.

Parallelt hermed lancerede konsortiet BatteryPass-Ready den 24. juni 2026 et offentligt testmiljø for det digitale batteripas. Producenter, underleverandører og softwareudbydere kan validere deres implementeringer i forhold til de lovmæssige krav — og det endda før driftsstart. Den, der opbygger opdateringsprocesser, bør tage dette miljø i brug tidligt for at teste dataformater og API-kompatibilitet.

EU's centrale DPP-registry

Europa-Kommissionen arbejder på et centralt registry, hvor alle DPPs skal registreres og kunne findes. Orgalim — den europæiske brancheorganisation for teknologi — har offentliggjort klare anbefalinger: Registryet skal understøtte automatiserede registreringsprocesser i stor skala og være sikret mod driftsafbrydelser. For opdateringsprocesser betyder det, at jeres interne arkitektur også skal fungere, når det centrale registry midlertidigt ikke er tilgængeligt — planlæg altså lokal caching og retry-logik.

Forbindelsen mellem det fysiske batteri og det digitale pas sker i praksis via en GS1 Digital Link — en standardiseret URI, der koder GTIN og serienummeret og peger på det tilhørende datasæt. Dette link er typisk kodet i en QR-kode på batteriets etiket.

Organisatoriske forudsætninger: Hvem er ansvarlig for opdateringer?

Forordningen retter sig først og fremmest mod den erhvervsdrivende, der markedsfører batteriet. Men tilstandsdata opstår ofte langt fra producenten — hos flådeoperatøren, genanvendelsesvirksomheden eller second-life-udbyderen. Spørgsmålet om skriverettigheder er derfor ikke kun teknisk: Det skal reguleres kontraktligt.

Følgende roller bør defineres klart i jeres governance-struktur:

Data Owner: Hvem må skrive og overskrive hvilke felter?
Audit Trail: Alle ændringer skal logges med tidsstempel og aktør — ikke kun af hensyn til compliance, men også i tilfælde af tvister på second-life-markedet.
Nødproces: Hvad sker der, hvis en sensor svigter, eller en leverandør ikke leverer data?

Løsninger som partnerskabet mellem Bureau Veritas og Circulor viser, hvordan kontrolorganisationer og dataleverandører vokser sammen for at lukke netop disse governance-huller. Securikett positionerer sig på lignende vis med sin Codikett 2.0-platform: manipulationssikre etiketter, der fysisk forbinder datasættet med produktet og gør uautoriseret skriveadgang vanskeligere.

Tjekliste: Opdateringsparathed frem mod februar 2027

Før I betragter jeres DBP-proces som »færdig«, bør I have kontrolleret følgende punkter:

PCF-beregningen er implementeret på partiniveau (ikke aggregeret på modelniveau)
SoH/SoC-datapipeline er etableret og testet
API-endpoints understøtter delvise opdateringer (PATCH) med tidsstempel
Skriverettigheder er reguleret kontraktligt med alle relevante aktører
Retry-logik i tilfælde af et registry-nedbrud er implementeret
Implementeringen er valideret i forhold til BatteryPass-Ready-testmiljøet
GS1 Digital Link er korrekt kodet på etiket og QR-kode

Februar 2027 nærmer sig. Den, der først opbygger opdateringsprocesser, når kravet træder i kraft, vil opdage, at det egentlige arbejde ikke ligger i at udfylde passet — men i at holde det korrekt i live gennem mange år.