Digitalt batteripass: Så håller du dina data aktuella

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

Det digitala batteripasset (DBP) är inget statiskt datablad. 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 en gång när batteriet släpps ut på marknaden och sedan inte rör det igen uppfyller inte kraven fullt ut — och riskerar allvarliga efterlevnadsproblem från och med 18 februari 2027.

Det låter självklart, men är i praktiken ett betydande operativt problem. Minespiders implementeringsrapport 2026 identifierar två strukturella svagheter som genomsyrar hela branschen: datafragmentering längs leveranskedjan och brist på processer för dynamiska datauppdateringar. Båda problemen går att lösa — men bara med en tydlig teknisk och organisatorisk strategi.

Vad måste ändras och när: de tre uppdateringskategorierna

Alla datafält i DBP omfattas inte av samma uppdateringskrav. Det lönar sig att från början skilja mellan tre kategorier:

1. Statiska grunddata (en gång när batteriet släpps ut på marknaden)

Dessa omfattar kemi, cellteknik, tillverkaridentifiering och serienummer. Fälten anges när passet fylls i första gången och ändras inte. De utgör passets oföränderliga kärna.

2. Batchspecifika CO₂-data (en gång, men detaljerat)

Det produktspecifika CO₂-avtrycket (PCF) måste beräknas enligt ISO 14067-kompatiblen-metoder och anges på batchnivå. Europeiska kommissionens JRC-utkast klargör: En aggregering över olika produktionsanläggningar är inte tillåten. Varje batterimodell får ett eget PCF-värde per produktionsanläggning. Det innebär att en ny datapost måste skapas för varje ny batch och kopplas till motsvarande pass — ingen kopiera-och-klistra-in från föregående modell.

I praktiken betyder det att om ert produktionssystem inte levererar batchspecifika CO₂-beräkningar måste den föregående processen anpassas innan passet över huvud taget kan fyllas i.

3. Tillståndsdata (löpande under hela livscykeln)

Detta är den mest krävande kategorin. State of Health (SoH) och State of Charge (SoC) förändras med varje laddnings- och urladdningscykel. För batterier som används vidare i ett andra liv — exempelvis som stationära lagringsenheter efter användning i elfordon — är aktuella tillståndsdata inte bara regulatoriskt föreskrivna, utan också ekonomiskt relevanta: Utan tillförlitliga SoH-uppgifter går det inte att fastställa ett rättvist marknadsvärde på second-life-marknaden.

Den tekniska implementeringen: tre metoder i jämförelse

Hur kommer data in i passet? Och hur hålls den aktuell? I huvudsak finns tre arkitekturmetoder:

Metod	Lämplig för	Fördel	Risk
Push via REST-API	Tillverkare med eget MES/ERP	Helt automatiserad, kan hantera realtid	Beroende av intern IT-infrastruktur
Bulkimport (CSV/JSON)	Leverantörer utan API-anslutning	Låg tröskel för att komma igång	Manuella felkällor, fördröjningar
Sensor-till-DPP (IoT)	Stationära lagringsenheter, fleet management	Kontinuerlig SoH-uppdatering	Komplex datapipeline, höga krav på latens

För de flesta tillverkare är en hybridmetod lämplig: grund- och PCF-data kommer via bulkimport eller API från ERP-systemet, medan tillståndsdata uppdateras via en IoT-pipeline.

API-uppdatering: ett minimalt exempel

Den som använder ett REST-API för att uppdatera tillståndsdata bör välja en versionshanterad endpointstruktur som även stöder partiella uppdateringar (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',
    }),
  }
);

Tidsstämpeln (measuredAt) är inget valfritt fält — den är avgörande för spårbarheten och för granskning av marknadskontrollmyndigheter.

Interoperabilitet: standarder, register och testmiljö

En uppdatering hjälper föga om den mottagande noden inte förstår data. Det är precis här standardiseringsarbetet kommer in. Den 25 juni 2026 höll CEN och CENELEC ett offentligt webbinarium om de nyligen publicerade DPP-standarderna EN 18216 till EN 18223. Dessa sex standarder, som har tagits fram av den tekniska kommittén JTC 24, definierar det produktövergripande ramverket för interoperabilitet och datakonsistens — alltså precis det skikt där uppdateringsprocesser måste standardiseras.

Parallellt lanserade konsortiet BatteryPass-Ready den 24 juni 2026 en offentlig testmiljö för det digitala batteripasset. Tillverkare, underleverantörer och programvaruleverantörer kan validera sina implementeringar mot de regulatoriska kraven där — innan driftsättningen börjar. Den som bygger upp uppdateringsprocesser bör använda denna miljö tidigt för att testa dataformat och API-kompatibilitet.

EU:s centrala DPP-register

Europeiska kommissionen arbetar med ett centralt register där alla DPPs ska registreras och kunna hittas. Orgalim — den europeiska industriföreningen för teknik — har publicerat tydliga rekommendationer om detta: Registret måste stödja automatiserade registreringsprocesser i hög volym och vara skyddat mot driftstörningar. För uppdateringsprocesser innebär det att er interna arkitektur måste fungera även när det centrala registret tillfälligt inte är tillgängligt — planera alltså för lokal cachning och retry-logik.

Kopplingen mellan det fysiska batteriet och det digitala passet sker i praktiken via en GS1 Digital Link — en standardiserad URI som kodar GTIN och serienummer och pekar på motsvarande datapost. Denna länk kodas vanligtvis i en QR-kod på batteriets etikett.

Organisatoriska förutsättningar: Vem ansvarar för uppdateringarna?

Förordningen riktar sig i första hand till den ekonomiska aktör som släpper ut batteriet på marknaden. Men tillståndsdata uppstår ofta långt från tillverkaren — hos fordonsflottans operatör, återvinningsföretaget eller second-life-leverantören. Frågan om skrivrättigheter är därför inte enbart teknisk: Den måste regleras genom avtal.

Följande roller bör definieras tydligt i er styrningsstruktur:

Data Owner: Vem får skriva och skriva över vilka fält?
Audit Trail: Varje ändring måste loggas med tidsstämpel och aktör — inte bara för efterlevnad, utan också vid tvister på second-life-marknaden.
Nödprocess: Vad händer om en sensor slutar fungera eller en leverantör inte levererar data?

Lösningar som partnerskapet mellan Bureau Veritas och Circulor visar hur kontrollorganisationer och dataleverantörer växer samman för att täppa till just dessa luckor i styrningen. Securikett positionerar sig på liknande sätt med sin Codikett-2.0-plattform: manipulationssäkra etiketter som fysiskt kopplar dataposten till produkten och försvårar obehörig skrivåtkomst.

Checklista: Uppdateringsberedskap senast februari 2027

Innan ni betraktar DBP-processen som ”färdig” bör ni ha kontrollerat följande punkter:

PCF-beräkningen är implementerad på batchnivå (inte aggregerad per modell)
Datapipelinen för SoH/SoC är uppbyggd och testad
API-endpoints stöder partiella uppdateringar (PATCH) med tidsstämpel
Skrivrättigheterna är avtalsreglerade med alla relevanta aktörer
Retry-logik för ett eventuellt driftstopp i registret är implementerad
Implementeringen har validerats mot BatteryPass-Ready-testmiljön
GS1 Digital Link är korrekt kodat på etikett och i QR-kod

Februari 2027 närmar sig. Den som börjar bygga upp uppdateringsprocesser först när kravet träder i kraft kommer att upptäcka att det egentliga arbetet inte ligger i att fylla i passet — utan i att hålla det korrekt levande under många år.