Hold det digitale produktpas opdateret: Sådan fungerer DPP-opdateringer

Hvorfor det ikke er nok at udfylde det én gang

Et digitalt produktpas (DPP) er ikke en statisk PDF-fil, der oprettes én gang og derefter arkiveres. Batteriforordningen (EU) 2023/1542 foreskriver udtrykkeligt, at bestemte datapunkter skal kunne opdateres gennem hele batteriets livscyklus. Den, der udfylder sit pas ved markedsføringen og derefter ikke rører det igen, opfylder ikke disse krav fuldt ud — og risikerer alvorlige compliance-problemer fra 18. februar 2027.

Det lyder trivielt, men det er det ikke. Minespiders implementeringsrapport for 2026 identificerer to strukturelle svagheder, der går igen i hele branchen: datafragmentering langs forsyningskæden og manglende processer for dynamiske dataopdateringer. Tilsammen gør det det vanskeligt at holde et DPP konsistent i den løbende drift.

Denne artikel forklarer, hvilke data der skal ændres hvornår, hvordan den tekniske infrastruktur til opdateringer ser ud, og hvilke organisatoriske processer producenter og operatører bør opbygge nu.

Hvad ændrer sig — og hvornår

Statiske kontra dynamiske datapunkter

Ikke alle felter i et DPP er lige volatile. Groft sagt kan man skelne mellem to kategorier:

Statiske data fastlægges ved markedsføringen og ændrer sig normalt ikke derefter:

• Materialesammensætning og farlige stoffer
• Producentidentifikation og produktionssted
• Certificeringer på tidspunktet for markedsintroduktionen

Dynamiske data ændrer sig derimod i takt med produktets levetid:

• State of Health (SoH) og State of Charge (SoC) for batterier — begge værdier ændrer sig med hver opladnings- og afladningscyklus
• Reparations- og vedligeholdelseshistorik
• Ejerskifte og placeringsdata
• Resultater af istandsættelseskontroller ved afslutningen af det første liv

Især for batterier, der får et andet liv som stationære lagringsenheder efter brug i et elektrisk køretøj, er aktuelle tilstandsdata ikke kun lovpligtige, men også økonomisk relevante: En operatør af et sekundærlager skal vide, hvor meget restkapacitet der reelt købes.

Udløsere for obligatoriske opdateringer

Forordningen angiver ingen præcise opdateringsintervaller, men definerer hændelser, der udløser en opdatering:

• Afslutning af vedligeholdelse eller reparation
• Overgang til en ny brugsfase (første liv → andet liv)
• Ændring af ejer eller operatør
• Nye måleværdier fra BMS-systemer (Battery Management System)
• Tilbagekaldelse eller sikkerhedsmeddelelse

Hvis disse hændelser ikke er forankret i den interne proces, vil de blive overset i den daglige drift.

Den tekniske arkitektur til DPP-opdateringer

GS1 Digital Link som stabilt anker

Forbindelsen mellem det fysiske batteri og det digitale pas sker via en GS1 Digital Link — en standardiseret URI, der koder GTIN og serienummeret og peger på det tilhørende datasæt. Det afgørende er, at linket på produktet (f.eks. trykt som en QR-kode) forbliver uændret. Kun det datasæt, som det peger på, opdateres.

En typisk GS1 Digital Link for et batteri ser sådan ud:

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

• 01 = GTIN-kvalifikator
• 04012345678901 = GTIN for batteriet
• 21 = serienummerkvalifikator
• ABC-0042 = individuelt serienummer

Der er tale om en rent illustrativ eksempel-URL, der anskueliggør URI-skemaet for GS1 Digital Link. Resolveren bag en sådan URL viderestiller til det aktuelle DPP-datasæt. Hvis datasættet ændres, forbliver QR-koden på produktet identisk — kun destinationen i backend opdateres. Det er det konceptuelle kernepunkt i den dynamiske datavedligeholdelse.

API-baserede opdateringer: Grundprincippet

Moderne DPP-platforme stiller REST-API'er til rådighed, som gør det muligt at opdatere datapunkter målrettet uden at skrive hele passet igen. En typisk PATCH-anmodning til en DPP-API kunne se sådan ud:

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

Fordelen sammenlignet med en fuldstændig PUT er, at kun de ændrede felter overføres, versioneringen forbliver sporbar, og auditloggen ikke vokser unødigt.

Versionering og revisionsspor

EN-standarderne 18216 til 18223, som CEN og CENELEC præsenterede på et offentligt webinar den 25. juni 2026, definerer krav til datakonsistens og interoperabilitet. Det omfatter implicit også sporbarheden af ændringer: Hvem ændrede hvilken værdi hvornår, og på hvilket grundlag?

En minimal versioneringsstrategi bør gemme følgende felter pr. opdateringshændelse:

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

Uden dette revisionsspor kan det i tilfælde af en tvist ikke dokumenteres, at dataene var korrekte på det pågældende tidspunkt.

Organisatoriske processer: Hvad virksomheder skal opbygge nu

Afklar dataansvaret

Det største praktiske problem er ikke af teknisk karakter. Det er spørgsmålet om, hvem i virksomheden der er ansvarlig for hvilke datapunkter — og hvem der i tvivlstilfælde igangsætter opdateringen.

Det anbefales at bruge en enkel RACI-matrix, der for hvert dynamisk datapunkt fastlægger:

• Responsible: Hvem udfører opdateringen?
• Accountable: Hvem er ansvarlig over for myndigheden?
• Consulted: Hvem leverer måledataene?
• Informed: Hvem skal underrettes om ændringer?

Inddrag forsyningskæden

Mange dynamiske data opstår ikke hos producenten, men hos leverandører, vedligeholdelsesvirksomheder eller flådeadministratorer. Producenten er dog fortsat regulatorisk ansvarlig for passets korrekthed. Det kræver klare kontraktlige bestemmelser og tekniske grænseflader, som tredjeparter kan bruge til at bidrage med data — med definerede formater og valideringsregler.

BatteryPass-Ready-konsortiet, som lancerede et offentligt testmiljø den 24. juni 2026, tilbyder netop en neutral valideringsplatform: Virksomheder kan teste deres DPP-løsninger i forhold til de regulatoriske krav, før de går i produktion.

Hold øje med det centrale register

Europa-Kommissionen arbejder på et centralt register, hvor alle DPPs skal registreres og gøres søgbare. Orgalim — den europæiske brancheorganisation for teknologi — har offentliggjort klare anbefalinger om dette: Registret skal understøtte automatiserede registreringsprocesser i stor skala og være beskyttet mod driftsafbrydelser.

For virksomheder betyder det, at deres opdateringsprocesser ikke kun skal fungere med deres egen platform, men fremover også skal kunne synkroniseres med EU's centrale register. Den, der nu satser på proprietære isolerede løsninger, påtager sig migrationsarbejde senere.

Praktisk tjekliste til opdateringsprocessen

Før det første DPP går i produktion, bør følgende punkter være afklaret:

1. Datapunkter klassificeret: Hvilke felter er statiske, og hvilke er dynamiske?
2. Udløsere defineret: Hvilke hændelser udløser en obligatorisk opdatering?
3. API-adgange reguleret: Hvem må ændre hvilke felter via hvilken grænseflade?
4. Revisionsspor implementeret: Hver ændring gemmes med tidsstempel, ophavsmand og tidligere værdi.
5. Grænseflader til forsyningskæden testet: Eksterne dataleverandører kan indlæse valide opdateringer.
6. Registerkompatibilitet kontrolleret: Det egne system kan kommunikere med det kommende EU-register.
7. Testmiljø anvendt: BatteryPass-Ready-testplatformen eller tilsvarende miljøer er blevet anvendt til interoperabilitetstest.

Konklusion

DPP er ikke et dokument, men et levende datasæt. De regulatoriske krav i Batteriforordningen (EU) 2023/1542 er entydige på dette punkt: Dynamiske datapunkter skal holdes ajour gennem hele produktets livscyklus. Den, der ikke opbygger den tekniske og organisatoriske infrastruktur i tide, vil ikke kunne overholde fristen den 18. februar 2027.

Den gode nyhed er, at byggestenene findes. GS1 Digital Link løser identifikationsproblemet, REST-API'er muliggør granulære opdateringer, og initiativer som BatteryPass-Ready tilbyder testinfrastruktur. I mange virksomheder mangler de interne processer og den klare tildeling af dataansvar — og det er netop dér, arbejdet bør begynde.