EU-Batteriepass-Softwarearchitektur: Bereit für Februar 2027

Ab 18. Februar 2027 braucht jede erfasste EV-Batterie, LMT-Batterie und Industriebatterie über 2 kWh beim Inverkehrbringen in der EU einen elektronischen Batteriepass. Baut ihn als langlebiges Identitäts- und Zugriffssystem mit eindeutiger Batterie-ID, stabiler QR-Adresse, geregelten Datenklassen und Lifecycle-Updates.

Der Pass ist kein PDF hinter einem QR-Code. Er ist ein Datenprodukt für Hersteller, Reparatur, Recycling und Aufsicht. Die Leitlinie der Kommission vom August 2026 nennt 71 Datenpunkte.

Welche Systeme sind betroffen?

Designfaktor	Vorgabe	Architekturfolge
Scope	EV, LMT und Industrie über 2 kWh	Scope je SKU und physischer Einheit bestimmen
Identität	Ein Pass je Batterie	Unveränderbare Batterie-ID statt Modell- oder Batch-URL
Zugriff	Öffentliche und eingeschränkte Daten	Feldgenaue Policy und Audit privilegierter Abrufe

Wie sieht die minimale Architektur aus?

Nutzt fünf Schichten: Identität, Ingestion, kanonische Daten, Policy und Veröffentlichung. Die QR-Adresse bleibt stabil. Der Datensatz bewahrt Herkunft, Wirksamkeitsdatum, Einheit, Validierung und ersetzte Werte.

Identity Service für Batterie-ID, Modell, Wirtschaftsakteur und Resolver.
Signierte APIs für Produktion, Tests, Service, State of Health und Recycling.
Versioniertes Schema mit Einheiten, Quelle, Zeit und Qualitätsflags.
Policy Engine für öffentliche und beschränkte Rollen.
Export und Verfügbarkeit ohne proprietäre Portalabhängigkeit.

Wie modelliert ihr 71 Datenpunkte?

Ordnet jeden Datenpunkt einem Quellsystem, Owner, Update-Ereignis, Validierungswert, einer Zugriffsklasse und einem Fehlerverhalten zu. Ein Feld ohne belastbare Quelle ist ein Delivery-Risiko, auch wenn das JSON-Schema vollständig ist.

Statische Modelldaten von unit-spezifischen Lifecycle-Daten trennen.
Maßeinheiten explizit abbilden.
Nachweise und Signaturen an relevante Aussagen hängen.
Korrektur- und Streitprozess für Lieferantendaten vorsehen.

Was scheitert in echten Projekten?

Typische Fehler sind Identitätskollisionen, tote QR-Ziele, Tabellen-Handover, zu breite Veröffentlichung und fehlende Owner nach dem Verkauf. Testet auch schlechte Verbindung und Organisationswechsel.

Keine sensiblen Daten direkt im QR-Payload.
Recycler nicht vom Mitarbeiterlogin des Herstellers abhängig machen.
Exportplan für Insolvenz, Übernahme und Providerwechsel definieren.

Praktische Delivery-Sequenz

Batteriekategorien, Rollen, Märkte und Mengen inventarisieren.
Datenpunkt-Matrix bauen und Quelllücken schließen.
Eine Batterie von Produktion bis Recycling prototypisieren.
Öffentliche und eingeschränkte Sicht mit Berechtigungstests umsetzen.
Interoperabilität, QR, Last, Backup, Export und Lieferantenausfall testen.
Eine Produktlinie pilotieren und vor Februar 2027 skalieren.

Produkt bauen, nicht nur Backlog

Wenn dieser Artikel auf eine echte Produktentscheidung einzahlt, hilft Wavect dir beim Scoping, Bauen, Härten oder Führen der Softwarearbeit mit Senior-Founder-Urteil.

Produkt besprechen

Sinnvolle Service-Wege:

Internet of Things

FAQ zum EU-Batteriepass

Ab wann ist der EU-Batteriepass verpflichtend?

Ab 18. Februar 2027 für erfasste Batterien, die in Verkehr gebracht oder in Betrieb genommen werden.

Ist der Pass nur ein QR-Code?

Nein. Der QR-Code ist der Zugang. Hinzu kommen Identität, geregelte Daten, Updates, Verfügbarkeit und Interoperabilität.

Müssen alle Felder öffentlich sein?

Nein. Die Verordnung unterscheidet allgemein zugängliche von rollenbeschränkten Informationen.

Portal kaufen oder selbst bauen?

Erst Datenquellen, Integration, Identität, Zugriffe, Exit und Betrieb klären. Ein Portal repariert keine fehlenden Quelldaten.

Fazit

Beginnt mit Unit-Identität und Data Ownership. Wer mit einer QR-Demo startet, entdeckt Lifecycle- und Governance-Arbeit meist zu spät.

Primärquellen

Verordnung (EU) 2023/1542. Verbindlicher Scope und Anforderungen
Leitlinie der EU-Kommission. Aktuelle Vorbereitung und 71 Datenpunkte
Digital Product Passport Hub. Aktuelle Ressourcen und Register