Digitalen Produktpass aktuell halten: So funktionieren DPP-Updates

Warum ein einmaliges Befüllen nicht reicht

Ein Digitaler Produktpass (DPP) ist keine statische PDF-Datei, die einmal erstellt und dann archiviert wird. Die Batterieverordnung (EU) 2023/1542 schreibt ausdrücklich vor, dass bestimmte Datenpunkte über den gesamten Lebenszyklus einer Batterie aktualisierbar bleiben müssen. Wer seinen Pass beim Inverkehrbringen befüllt und danach nicht mehr anfasst, erfüllt diese Anforderungen nicht vollständig — und riskiert ab dem 18. Februar 2027 ernsthafte Compliance-Probleme.

Das klingt trivial, ist es aber nicht. Der Minespider-Implementierungsbericht 2026 identifiziert zwei strukturelle Schwachstellen, die sich quer durch die gesamte Branche ziehen: Datenfragmentierung entlang der Lieferkette und fehlende Prozesse für dynamische Datenaktualisierungen. Beides zusammen macht es schwer, einen DPP im laufenden Betrieb konsistent zu halten.

Dieser Artikel erklärt, welche Daten sich wann ändern müssen, wie die technische Infrastruktur für Updates aussieht und welche organisatorischen Prozesse Hersteller und Betreiber jetzt aufbauen sollten.

Was sich ändert — und wann

Statische vs. dynamische Datenpunkte

Nicht alle Felder eines DPP sind gleich volatil. Grob lassen sich zwei Kategorien unterscheiden:

Statische Daten werden beim Inverkehrbringen festgelegt und ändern sich danach in der Regel nicht mehr:

• Materialzusammensetzung und Gefahrstoffe
• Herstelleridentifikation und Produktionsstandort
• Zertifizierungen zum Zeitpunkt der Markteinführung

Dynamische Daten hingegen verändern sich mit dem Produktleben:

• State of Health (SoH) und State of Charge (SoC) bei Batterien — beide Werte verändern sich mit jedem Lade- und Entladezyklus
• Reparatur- und Wartungshistorie
• Eigentümerwechsel und Standortdaten
• Ergebnisse von Wiederaufbereitungsprüfungen am Ende des Erstlebens

Besonders für Batterien, die ein Zweitleben als stationärer Speicher nach dem Einsatz im Elektrofahrzeug absolvieren, sind aktuelle Zustandsdaten nicht nur regulatorisch vorgeschrieben, sondern auch wirtschaftlich relevant: Ein Betreiber eines Sekundärspeichers muss wissen, wie viel Restkapazität er tatsächlich einkauft.

Trigger für Pflicht-Updates

Die Verordnung benennt keine exakten Aktualisierungsintervalle, definiert aber Ereignisse, die eine Aktualisierung auslösen:

• Abschluss einer Wartung oder Reparatur
• Übergang in eine neue Nutzungsphase (Erstleben → Zweitleben)
• Änderung des Eigentümers oder Betreibers
• Neue Messwerte aus BMS-Systemen (Battery Management System)
• Rückruf oder Sicherheitshinweis

Wer diese Ereignisse nicht in seinem internen Prozess verankert hat, wird sie im Tagesgeschäft übersehen.

Die technische Architektur für DPP-Updates

GS1 Digital Link als stabiler Anker

Die Verknüpfung zwischen physischer Batterie und digitalem Pass erfolgt über einen GS1 Digital Link — einen standardisierten URI, der GTIN und Seriennummer kodiert und auf den zugehörigen Datensatz zeigt. Das Entscheidende: Der Link auf dem Produkt (z. B. als QR-Code aufgedruckt) bleibt unveränderlich. Nur der Datensatz, auf den er zeigt, wird aktualisiert.

Ein typischer GS1 Digital Link für eine Batterie sieht so aus:

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

• 01 = GTIN-Qualifier
• 04012345678901 = GTIN der Batterie
• 21 = Seriennummer-Qualifier
• ABC-0042 = individuelle Seriennummer

Hierbei handelt es sich um eine rein illustrative Beispiel-URL, die das URI-Schema von GS1 Digital Link veranschaulicht. Der Resolver hinter einer solchen URL leitet auf den aktuellen DPP-Datensatz weiter. Ändert sich der Datensatz, bleibt der QR-Code auf dem Produkt identisch — nur das Ziel im Backend wird aktualisiert. Das ist der konzeptionelle Kern der dynamischen Datenpflege.

API-basierte Updates: Das Grundprinzip

Moderne DPP-Plattformen stellen REST-APIs bereit, über die Datenpunkte gezielt aktualisiert werden können, ohne den gesamten Pass neu zu schreiben. Ein typisches PATCH-Request gegen eine DPP-API könnte so aussehen:

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

Der Vorteil gegenüber einem vollständigen PUT: Nur die geänderten Felder werden übertragen, die Versionierung bleibt nachvollziehbar, und das Audit-Log wächst nicht unnötig.

Versionierung und Audit-Trail

Die EN-Normen 18216 bis 18223, die CEN und CENELEC am 25. Juni 2026 in einem öffentlichen Webinar vorgestellt haben, definieren Anforderungen an Datenkonsistenz und Interoperabilität. Dazu gehört implizit auch die Nachvollziehbarkeit von Änderungen: Wer hat wann welchen Wert geändert, und auf welcher Grundlage?

Eine minimale Versionierungsstrategie sollte folgende Felder pro Update-Event speichern:

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

Ohne diesen Trail lässt sich im Streitfall nicht nachweisen, dass die Daten zum fraglichen Zeitpunkt korrekt waren.

Organisatorische Prozesse: Was Unternehmen jetzt aufbauen müssen

Datenverantwortung klären

Das größte praktische Problem ist nicht technischer Natur. Es ist die Frage, wer im Unternehmen für welche Datenpunkte verantwortlich ist — und wer im Zweifelsfall die Aktualisierung anstößt.

Empfehlenswert ist eine einfache RACI-Matrix, die für jeden dynamischen Datenpunkt festhält:

• Responsible: Wer führt das Update durch?
• Accountable: Wer ist gegenüber der Behörde verantwortlich?
• Consulted: Wer liefert die Messdaten?
• Informed: Wer muss über Änderungen benachrichtigt werden?

Lieferkette einbinden

Viele dynamische Daten entstehen nicht beim Hersteller, sondern bei Zulieferern, Wartungsbetrieben oder Flottenmanagern. Der Hersteller bleibt aber regulatorisch verantwortlich für die Korrektheit des Passes. Das erfordert klare vertragliche Regelungen und technische Schnittstellen, über die Dritte Daten beisteuern können — mit definierten Formaten und Validierungsregeln.

Das BatteryPass-Ready-Konsortium, das am 24. Juni 2026 eine öffentliche Testumgebung gestartet hat, bietet genau dafür eine neutrale Validierungsplattform: Unternehmen können ihre DPP-Lösungen gegen die regulatorischen Anforderungen testen, bevor sie in den Produktivbetrieb gehen.

Zentrale Registry im Blick behalten

Die Europäische Kommission arbeitet an einer zentralen Registry, über die alle DPPs registriert und auffindbar gemacht werden sollen. Orgalim — der europäische Industrieverband für Technologie — hat dazu klare Empfehlungen veröffentlicht: Die Registry muss hochvolumige, automatisierte Registrierungsprozesse unterstützen und gegen Betriebsausfälle abgesichert sein.

Für Unternehmen bedeutet das: Ihre Update-Prozesse müssen nicht nur gegen die eigene Plattform funktionieren, sondern perspektivisch auch mit der zentralen EU-Registry synchronisiert werden können. Wer jetzt auf proprietäre Insellösungen setzt, baut sich Migrationsaufwand für später.

Praktische Checkliste für den Update-Prozess

Bevor der erste DPP in Produktion geht, sollten folgende Punkte geklärt sein:

1. Datenpunkte klassifiziert: Welche Felder sind statisch, welche dynamisch?
2. Trigger definiert: Welche Ereignisse lösen ein Pflicht-Update aus?
3. API-Zugriffe geregelt: Wer darf welche Felder über welche Schnittstelle ändern?
4. Audit-Trail implementiert: Jede Änderung wird mit Zeitstempel, Urheber und Vorwert gespeichert.
5. Lieferketten-Schnittstellen getestet: Externe Datenlieferanten können valide Updates einspielen.
6. Registry-Kompatibilität geprüft: Das eigene System kann mit der künftigen EU-Registry kommunizieren.
7. Testumgebung genutzt: Die BatteryPass-Ready-Testplattform oder äquivalente Umgebungen wurden für Interoperabilitätstests eingesetzt.

Fazit

Der DPP ist kein Dokument, sondern ein lebendiger Datensatz. Die regulatorischen Anforderungen der Batterieverordnung (EU) 2023/1542 sind in dieser Hinsicht eindeutig: Dynamische Datenpunkte müssen aktuell gehalten werden — über den gesamten Produktlebenszyklus. Wer die technische und organisatorische Infrastruktur dafür nicht rechtzeitig aufbaut, wird den Frist des 18. Februar 2027 nicht compliant erreichen.

Die gute Nachricht: Die Bausteine sind vorhanden. GS1 Digital Link löst das Identifikationsproblem, REST-APIs ermöglichen granulare Updates, und Initiativen wie BatteryPass-Ready bieten Testinfrastruktur. Was fehlt, sind in vielen Unternehmen die internen Prozesse und die klare Zuweisung von Datenverantwortung — und genau dort sollte die Arbeit beginnen.