What PIM users need to know about the Digital Product Pass (DPP)

11.02.2025 | Thomas Kern

Digital Product Passport (DPP) - what may initially seem like another bureaucratic challenge from the EU also offers opportunities. After all, transparency strengthens consumer trust and ensures sustainable customer relationships. But what exactly do the regulations require and how can companies implement these requirements efficiently?

There is already a wealth of information on this topic from service providers, associations, authorities and universities. I would like to place this information in the context of PIM.

What is the background?

The Digital Product Passport (DPP) is a measure within the Green Deal or Sustainable Products Regulation (ESPR). In short, the aim is to create a sustainable product life cycle ("circular economy"). In order to achieve this goal, the buyer should be fully informed about the product ("purchase decision"), as should the authorities ("compliance with laws"). Authorities naturally require different product information than the buyer.

Was ist das Vorhaben und der Zeitplan?

Ab 2026 bis 2030 sollen schrittweise alle relevanten Produktgruppen einen DPP erhalten (ausgenommen sind Lebens- und Futtermittel sowie Arzneimittel). Das bedeutet, dass jedes Produkt identifiziert (QR-Code, Chip) und über die Id die Informationen eingesehen werden können. Im Prinzip betrifft dies alle industriellen Hersteller und Händler.

Der DPP ist im Prinzip ein Datensatz. Ich vergleiche das gerne mit Datensätzen in BMEcat oder ähnlichen Formaten. Der Datensatz muss Käufern und Behörden auf Knopfdruck zur Verfügung stehen. Dafür sind direkte Zugriffe auf Datenbanksysteme notwendig. Die Visualisierung für Käufer kann bspw. auf Weboberflächen oder Apps erfolgen. Für Behörden oder B2B-Kunden kann der Datensatz über sogenannte API-Schnittstellen bereitgestellt werden.

Welche Produktinformationen sind in dem DPP-Datensatz enthalten?

Das wird eine ganze Menge an Inhalten sein und sich laufend erweitern; ich sage mal, der Phantasie sind hier keine Grenzen gesetzt:

• Produktidentifizierungen (Artikelnummer, EAN, Bezeichnung usw.)
• Produktbeschreibungen
• Technische Produktdaten (Abmessungen, Material/Oberfläche, elektrische und mechanische Eigenschaften usw.)
• Logistische Daten (Verpackung, Gewicht, Zolltarifnummer usw.)
• Produktbilder (Fotos, Zeichnungen)
• Zulassungen, Zertifikate
• Produktbeziehungen (Ersatzteile, Zubehör, Lieferumfang)
• Bedien- und Montageinformationen
• Reparaturhinweise
• Sicherheitshinweise
• Bestandteile des Produkts (bspw. relevant für Entsorgung)
• Daten zur Ermittlung von CO2-Fußabdruck und H2O-Fußabdruck

Abbildung der Produktinformationen im DPP-Datensatz

Jetzt kann man sich bildlich vorstellen was dies an riesigen Datenmengen verursacht. Es gibt ja eine Vielzahl von völlig unterschiedlichen Produkten mit unterschiedlichen Beschreibungen. Anderseits werden auch die unterschiedlichsten Begriffe für Eigenschaften verwendet. Manche sprechen beispielsweise bei einem Kunststoffrohr vom Durchmesser, andere vom Innendurchmesser oder Rohrdurchmesser.
Das heißt die Beschreibung und die Sprache sollten produktgruppenspezifisch genormt bzw. klassifiziert werden. Da gibt es glücklicherweise seit Jahrzehnten schon gebräuchliche Klassifizierungssysteme wie ECLASS oder ETIM, die man hierfür einsetzen kann.

Technische Umsetzung von DPP

„Just another tool“. Die technische Umsetzung erfordert folgende Komponenten:

• Ein Datenbanksystem, genauer gesagt ein Product Information System (PIM). Die Daten müssen validiert vorliegen
• Integrierte Standardklassifikationen (ECLASS, ETIM), wie oben erwähnt
• Channel Output Management zur Ausgabesteuerung der DPP-relevanten Artikel (mindestens die Artikel, die ab 2026 verkauft wurden bzw. werden) und der erforderlichen Inhalte und Sprachen
• REST-API („Json“) zur Datenbereitstellung in einem Format X für den direkten und sicheren Datenzugriff, wie oben erwähnt

Das Format X ist noch nicht bekannt. Verschiedene Player, ich sage mal so „bringen sich hier ein“. Ich nehme an, dass sich das Asset Administration Shell (AAS)-Format durchsetzen wird, siehe https://industrialdigitaltwin.org.

Aus meiner Sicht hat dieses Modell unter anderem folgende Vorteile:

• Die Beschreibung anhand von Submodellen ist fortgeschritten, u. a. Nameplate (Produktidentifizierung), Reliability (Elektrokomponenten), Technical Data, Contact Informations (Kontaktdaten). Siehe: https://industrialdigitaltwin.org/content-hub/teilmodelle
• Standardklassifikation ECLASS ist im „Submodel Technical Data“ eingebunden

Fazit

Ohne PIM kein DPP. Haben Sie bereits ein PIM mit ECLASS, REST-API und Ausgabesteuerung dann können Sie sich recht entspannt zurücklehnen – zumindest was den technischen Part betrifft. REST-API und Ausgabesteuerung sind typischerweise beim PIM-System standardmäßig enthalten. Sollten Sie noch kein ECLASS haben, dann empfehle ich den Einsatz, optimalerweise integriert im PIM, zu prüfen.

Inhaltlich ist es sicher notwendig Informationen zu ergänzen. Dazu sind die inhaltlichen Anforderungen an DPP-Daten zu listen, mit den bestehenden Daten im PIM abzugleichen und das Delta zu prüfen, sprich wo die fehlenden Daten zu pflegen sind (bspw. im ERP oder im PIM). Diesen Prozess kann man nicht früh genug beginnen, weil er erfahrungsgemäß am aufwändigsten ist.