Digitaal productpaspoort actueel houden: zo werken DPP-updates

Waarom eenmalig invullen niet volstaat

Een digitaal productpaspoort (DPP) is geen statisch pdf-bestand dat eenmaal wordt aangemaakt en vervolgens gearchiveerd. De batterijverordening (EU) 2023/1542 schrijft uitdrukkelijk voor dat bepaalde datapunten gedurende de volledige levenscyclus van een batterij kunnen worden bijgewerkt. Wie zijn pas bij het in de handel brengen invult en daarna niet meer aanpast, voldoet niet volledig aan deze vereisten — en riskeert vanaf 18 februari 2027 ernstige complianceproblemen.

Dat klinkt triviaal, maar is het niet. Het Minespider-implementatierapport 2026 identificeert twee structurele zwakke punten die in de hele sector terugkomen: gegevensfragmentatie in de toeleveringsketen en ontbrekende processen voor dynamische gegevensupdates. Samen maken die het moeilijk om een DPP tijdens het gebruik consistent te houden.

Dit artikel legt uit welke gegevens wanneer moeten veranderen, hoe de technische infrastructuur voor updates eruitziet en welke organisatorische processen fabrikanten en exploitanten nu moeten opzetten.

Wat verandert er — en wanneer

Statische versus dynamische datapunten

Niet alle velden van een DPP zijn even veranderlijk. In grote lijnen zijn er twee categorieën:

Statische gegevens worden bij het in de handel brengen vastgesteld en veranderen daarna doorgaans niet meer:

• Materiaalsamenstelling en gevaarlijke stoffen
• Identificatie van de fabrikant en productielocatie
• Certificeringen op het moment van marktintroductie

Dynamische gegevens veranderen daarentegen gedurende de levensduur van het product:

• State of Health (SoH) en State of Charge (SoC) bij batterijen — beide waarden veranderen bij elke laad- en ontlaadcyclus
• Reparatie- en onderhoudshistorie
• Wisselingen van eigenaar en locatiegegevens
• Resultaten van tests voor revisie aan het einde van het eerste leven

Vooral bij batterijen die na gebruik in een elektrisch voertuig een tweede leven als stationaire opslag doorlopen, zijn actuele statusgegevens niet alleen wettelijk verplicht, maar ook economisch relevant: een exploitant van secundaire opslag moet weten hoeveel restcapaciteit hij daadwerkelijk inkoopt.

Triggers voor verplichte updates

De verordening noemt geen exacte update-intervallen, maar definieert wel gebeurtenissen die een update activeren:

• Voltooiing van onderhoud of reparatie
• Overgang naar een nieuwe gebruiksfase (eerste leven → tweede leven)
• Wijziging van eigenaar of exploitant
• Nieuwe meetwaarden uit BMS-systemen (Battery Management System)
• Terugroepactie of veiligheidswaarschuwing

Wie deze gebeurtenissen niet in het interne proces heeft verankerd, zal ze in de dagelijkse praktijk over het hoofd zien.

De technische architectuur voor DPP-updates

GS1 Digital Link als stabiel anker

De koppeling tussen de fysieke batterij en het digitale paspoort verloopt via een GS1 Digital Link — een gestandaardiseerde URI die GTIN en serienummer codeert en naar de bijbehorende gegevensset verwijst. Het cruciale punt: de link op het product (bijvoorbeeld als QR-code afgedrukt) blijft onveranderlijk. Alleen de gegevensset waarnaar hij verwijst, wordt bijgewerkt.

Een typische GS1 Digital Link voor een batterij ziet er als volgt uit:

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

• 01 = GTIN-kwalificatie
• 04012345678901 = GTIN van de batterij
• 21 = serienummerkwalificatie
• ABC-0042 = individueel serienummer

Dit is een puur illustratieve voorbeeld-URL die het URI-schema van GS1 Digital Link verduidelijkt. De resolver achter zo'n URL verwijst door naar de actuele DPP-gegevensset. Als de gegevensset verandert, blijft de QR-code op het product identiek — alleen het doel in de backend wordt bijgewerkt. Dat is de conceptuele kern van dynamisch gegevensbeheer.

API-gebaseerde updates: het basisprincipe

Moderne DPP-platforms bieden REST-API's waarmee datapunten gericht kunnen worden bijgewerkt, zonder het volledige paspoort opnieuw te schrijven. Een typisch PATCH-verzoek aan een DPP-API zou er als volgt uit kunnen zien:

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

Het voordeel ten opzichte van een volledige PUT: alleen de gewijzigde velden worden overgedragen, de versiegeschiedenis blijft traceerbaar en het auditlog groeit niet onnodig.

Versiebeheer en audittrail

De EN-normen 18216 tot en met 18223, die CEN en CENELEC op 25 juni 2026 tijdens een openbaar webinar hebben gepresenteerd, definiëren vereisten voor gegevensconsistentie en interoperabiliteit. Daaronder valt impliciet ook de traceerbaarheid van wijzigingen: wie heeft wanneer welke waarde gewijzigd, en op basis waarvan?

Een minimale strategie voor versiebeheer moet per updategebeurtenis de volgende velden opslaan:

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

Zonder deze trail kan in geval van een geschil niet worden aangetoond dat de gegevens op het betreffende moment correct waren.

Organisatorische processen: wat bedrijven nu moeten opzetten

Verantwoordelijkheid voor gegevens vastleggen

Het grootste praktische probleem is niet van technische aard. Het gaat om de vraag wie binnen het bedrijf verantwoordelijk is voor welke datapunten — en wie bij twijfel de update initieert.

Een eenvoudige RACI-matrix is aan te bevelen, waarin voor elk dynamisch datapunt wordt vastgelegd:

• Responsible: Wie voert de update uit?
• Accountable: Wie is tegenover de autoriteit verantwoordelijk?
• Consulted: Wie levert de meetgegevens aan?
• Informed: Wie moet over wijzigingen worden geïnformeerd?

De toeleveringsketen betrekken

Veel dynamische gegevens ontstaan niet bij de fabrikant, maar bij toeleveranciers, onderhoudsbedrijven of fleetmanagers. De fabrikant blijft echter regelgevend verantwoordelijk voor de juistheid van het paspoort. Dat vereist duidelijke contractuele afspraken en technische interfaces waarlangs derden gegevens kunnen aanleveren — met vastgelegde formaten en validatieregels.

Het BatteryPass-Ready-consortium, dat op 24 juni 2026 een openbare testomgeving heeft gestart, biedt daarvoor precies een neutraal validatieplatform: bedrijven kunnen hun DPP-oplossingen tegen de wettelijke vereisten testen voordat ze in productie gaan.

De centrale registry in het oog houden

De Europese Commissie werkt aan een centrale registry waarin alle DPPs geregistreerd en vindbaar moeten worden gemaakt. Orgalim — de Europese brancheorganisatie voor technologie — heeft hierover duidelijke aanbevelingen gepubliceerd: de registry moet geautomatiseerde registratieprocessen op grote schaal ondersteunen en tegen bedrijfsuitval worden beschermd.

Voor bedrijven betekent dit dat hun updateprocessen niet alleen met hun eigen platform moeten werken, maar in de toekomst ook met de centrale EU-registry moeten kunnen worden gesynchroniseerd. Wie nu voor propriëtaire eilandoplossingen kiest, creëert later migratiewerk.

Praktische checklist voor het updateproces

Voordat de eerste DPP in productie gaat, moeten de volgende punten zijn verduidelijkt:

1. Datapunten geclassificeerd: Welke velden zijn statisch en welke dynamisch?
2. Triggers gedefinieerd: Welke gebeurtenissen leiden tot een verplichte update?
3. API-toegang geregeld: Wie mag welke velden via welke interface wijzigen?
4. Audittrail geïmplementeerd: Elke wijziging wordt met tijdstempel, auteur en vorige waarde opgeslagen.
5. Interfaces met de toeleveringsketen getest: Externe gegevensleveranciers kunnen geldige updates invoeren.
6. Registrycompatibiliteit gecontroleerd: Het eigen systeem kan met de toekomstige EU-registry communiceren.
7. Testomgeving gebruikt: Het BatteryPass-Ready-testplatform of gelijkwaardige omgevingen zijn voor interoperabiliteitstests ingezet.

Conclusie

Het DPP is geen document, maar een levende gegevensset. De wettelijke vereisten van de batterijverordening (EU) 2023/1542 zijn in dit opzicht duidelijk: dynamische datapunten moeten actueel worden gehouden — gedurende de volledige levenscyclus van het product. Wie de technische en organisatorische infrastructuur daarvoor niet op tijd opbouwt, zal de deadline van 18 februari 2027 niet compliant halen.

Het goede nieuws: de bouwstenen zijn beschikbaar. GS1 Digital Link lost het identificatieprobleem op, REST-API's maken granulaire updates mogelijk en initiatieven zoals BatteryPass-Ready bieden testinfrastructuur. Wat in veel bedrijven ontbreekt, zijn de interne processen en de duidelijke toewijzing van verantwoordelijkheid voor gegevens — en precies daar moet het werk beginnen.