Håll det digitala produktpasset aktuellt: Så fungerar DPP-uppdateringar

Varför det inte räcker att fylla i uppgifterna en gång

Ett digitalt produktpass (DPP) är ingen statisk PDF-fil som skapas en gång och sedan arkiveras. Batteriförordningen (EU) 2023/1542 föreskriver uttryckligen att vissa datapunkter måste kunna uppdateras under ett batteris hela livscykel. Den som fyller i sitt pass när produkten släpps ut på marknaden och sedan inte längre ändrar det uppfyller inte dessa krav fullt ut — och riskerar allvarliga problem med regelefterlevnaden från och med 18 februari 2027.

Det låter trivialt, men är det inte. Implementeringsrapporten från Minespider 2026 identifierar två strukturella svagheter som går igenom hela branschen: datafragmentering längs leveranskedjan och bristande processer för dynamiska datauppdateringar. Tillsammans gör de det svårt att hålla ett DPP konsekvent uppdaterat under drift.

Den här artikeln förklarar vilka data som måste ändras och när, hur den tekniska infrastrukturen för uppdateringar ser ut och vilka organisatoriska processer tillverkare och operatörer bör bygga upp nu.

Vad som ändras — och när

Statiska kontra dynamiska datapunkter

Alla fält i ett DPP har inte samma förändringstakt. Grovt sett kan man skilja mellan två kategorier:

Statiska data fastställs när produkten släpps ut på marknaden och ändras därefter vanligtvis inte längre:

• Materialsammansättning och farliga ämnen
• Tillverkaridentifikation och produktionsort
• Certifieringar vid tidpunkten för marknadsintroduktionen

Dynamiska data förändras däremot under produktens livslängd:

• State of Health (SoH) och State of Charge (SoC) för batterier — båda värdena förändras vid varje laddnings- och urladdningscykel
• Reparations- och underhållshistorik
• Ägarbyten och platsdata
• Resultat från rekonditioneringskontroller vid slutet av det första livet

Särskilt för batterier som får ett andra liv som stationär lagringsenhet efter användning i elfordon är aktuella tillståndsdata inte bara regulatoriskt föreskrivna, utan även ekonomiskt relevanta: En operatör av ett sekundärt lagringssystem måste veta hur stor återstående kapacitet som faktiskt köps in.

Utlösare för obligatoriska uppdateringar

Förordningen anger inga exakta uppdateringsintervall, men definierar händelser som utlöser en uppdatering:

• Slutförande av underhåll eller reparation
• Övergång till en ny användningsfas (första livet → andra livet)
• Byte av ägare eller operatör
• Nya mätvärden från BMS-system (Battery Management System)
• Återkallelse eller säkerhetsmeddelande

Den som inte har förankrat dessa händelser i sina interna processer kommer att missa dem i det dagliga arbetet.

Den tekniska arkitekturen för DPP-uppdateringar

GS1 Digital Link som stabil förankring

Kopplingen mellan det fysiska batteriet och det digitala passet sker via en GS1 Digital Link — en standardiserad URI som kodar GTIN och serienummer och pekar på den tillhörande dataposten. Det avgörande är att länken på produkten (t.ex. tryckt som en QR-kod) förblir oföränderlig. Endast dataposten som den pekar på uppdateras.

En typisk GS1 Digital Link för ett batteri ser ut så här:

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

• 01 = GTIN-kvalificerare
• 04012345678901 = GTIN för batteriet
• 21 = serienummerkvalificerare
• ABC-0042 = individuellt serienummer

Detta är en rent illustrativ exempel-URL som visar URI-schemat för GS1 Digital Link. Resolvern bakom en sådan URL vidarebefordrar till den aktuella DPP-posten. Om dataposten ändras förblir QR-koden på produkten identisk — endast målet i backend uppdateras. Detta är den konceptuella kärnan i den dynamiska datahanteringen.

API-baserade uppdateringar: Grundprincipen

Moderna DPP-plattformar tillhandahåller REST-API:er som gör det möjligt att uppdatera datapunkter selektivt utan att skriva om hela passet. En typisk PATCH-begäran mot ett DPP-API skulle kunna se ut så här:

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

Fördelen jämfört med en fullständig PUT är att endast de ändrade fälten överförs, versionshanteringen förblir spårbar och revisionsloggen växer inte i onödan.

Versionshantering och revisionsspår

EN-standarderna 18216 till 18223, som CEN och CENELEC presenterade vid ett offentligt webbinarium den 25 juni 2026, definierar krav på datakonsistens och interoperabilitet. Där ingår implicit även spårbarhet för ändringar: Vem ändrade vilket värde, när och på vilken grund?

En minimal strategi för versionshantering bör spara följande fält per uppdateringshändelse:

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

Utan detta spår går det i en tvist inte att bevisa att uppgifterna var korrekta vid den aktuella tidpunkten.

Organisatoriska processer: Vad företag måste bygga upp nu

Klargör dataansvaret

Det största praktiska problemet är inte tekniskt. Det handlar om vem i företaget som ansvarar för vilka datapunkter — och vem som vid behov initierar uppdateringen.

En enkel RACI-matris rekommenderas, där det för varje dynamisk datapunkt anges:

• Responsible: Vem genomför uppdateringen?
• Accountable: Vem är ansvarig gentemot myndigheten?
• Consulted: Vem tillhandahåller mätdata?
• Informed: Vem måste informeras om ändringar?

Involvera leveranskedjan

Många dynamiska data uppstår inte hos tillverkaren, utan hos underleverantörer, serviceföretag eller flottansvariga. Tillverkaren förblir dock regulatoriskt ansvarig för passets korrekthet. Det kräver tydliga avtalsbestämmelser och tekniska gränssnitt där tredje parter kan bidra med data — med definierade format och valideringsregler.

BatteryPass-Ready-konsortiet, som startade en offentlig testmiljö den 24 juni 2026, erbjuder just detta: en neutral valideringsplattform där företag kan testa sina DPP-lösningar mot de regulatoriska kraven innan de tas i produktiv drift.

Håll koll på det centrala registret

Europeiska kommissionen arbetar med ett centralt register där alla DPPs ska registreras och göras sökbara. Orgalim — den europeiska teknikindustrins branschorganisation — har publicerat tydliga rekommendationer om detta: Registret måste stödja automatiserade registreringsprocesser med stora volymer och vara skyddat mot driftstörningar.

För företag innebär det att uppdateringsprocesserna inte bara måste fungera mot den egna plattformen, utan framöver även kunna synkroniseras med EU:s centrala register. Den som nu satsar på proprietära särlösningar skapar ett migrationsarbete längre fram.

Praktisk checklista för uppdateringsprocessen

Innan det första DPP tas i produktion bör följande punkter vara klargjorda:

1. Datapunkter klassificerade: Vilka fält är statiska och vilka är dynamiska?
2. Utlösare definierade: Vilka händelser utlöser en obligatorisk uppdatering?
3. API-åtkomst reglerad: Vem får ändra vilka fält via vilket gränssnitt?
4. Revisionsspår implementerat: Varje ändring sparas med tidsstämpel, upphovsperson och tidigare värde.
5. Gränssnitt mot leveranskedjan testade: Externa dataleverantörer kan skicka in giltiga uppdateringar.
6. Registerkompatibilitet kontrollerad: Det egna systemet kan kommunicera med EU:s framtida register.
7. Testmiljö använd: BatteryPass-Ready-testplattformen eller motsvarande miljöer har använts för interoperabilitetstester.

Slutsats

DPP är inget dokument, utan en levande datapost. De regulatoriska kraven i batteriförordningen (EU) 2023/1542 är tydliga i detta avseende: Dynamiska datapunkter måste hållas aktuella — under hela produktens livscykel. Den som inte bygger upp den tekniska och organisatoriska infrastrukturen i tid kommer inte att kunna uppnå regelefterlevnad före tidsfristen den 18 februari 2027.

Den goda nyheten är att byggstenarna finns. GS1 Digital Link löser identifieringsproblemet, REST-API:er möjliggör detaljerade uppdateringar och initiativ som BatteryPass-Ready erbjuder testinfrastruktur. I många företag saknas dock de interna processerna och den tydliga fördelningen av dataansvar — och det är precis där arbetet bör börja.