{"id":15437,"date":"2026-05-07T13:21:44","date_gmt":"2026-05-07T11:21:44","guid":{"rendered":"https:\/\/www.iese.fraunhofer.de\/blog\/?p=15437"},"modified":"2026-05-07T13:56:45","modified_gmt":"2026-05-07T11:56:45","slug":"digitaler-produktpass-software-umsetzung-anforderungen","status":"publish","type":"post","link":"https:\/\/www.iese.fraunhofer.de\/blog\/digitaler-produktpass-software-umsetzung-anforderungen\/","title":{"rendered":"Digitaler Produktpass Software: Umsetzung der Anforderungen & IT-Architektur mit Eclipse BaSyx"},"content":{"rendered":"

F\u00fcr viele Unternehmen ist der Digitale Produktpass (DPP) l\u00e4ngst kein Zukunftsthema mehr, sondern mit konkreten Fristen und Berichtspflichten verbunden. In unserem Grundlagenbeitrag zum Digitalen Produktpass<\/a> haben wir erl\u00e4utert, was der DPP ist und welche regulatorischen Vorgaben auf Unternehmen zukommen. Ein weiterer Beitrag zeigt, wie der DPP neue Gesch\u00e4ftsmodelle und Kreislaufstrategien<\/a> erm\u00f6glicht. In diesem Artikel geht es um die n\u00e4chsten Fragen: Wie l\u00e4sst sich der Digitale Produktpass konkret in die Praxis umsetzen? Welche Software wird f\u00fcr den DPP ben\u00f6tigt? Und wie lassen sich die Anforderungen technisch umsetzen?\u00a0<\/strong>Wir zeigen, wie Sie mit der Verwaltungsschale (AAS) und der Open-Source-Middleware Eclipse BaSyx eine IT-Architektur aufbauen, die die kommenden DPP-Standards unterst\u00fctzt und sich in bestehende Systeme integrieren l\u00e4sst.<\/p>\n

Mit der Ecodesign for Sustainable Products Regulation (ESPR)<\/strong> schafft die EU den verbindlichen Rahmen f\u00fcr den Digitalen Produktpass. Unternehmen m\u00fcssen k\u00fcnftig unter anderem den Product Carbon Footprint (PCF)<\/strong>, den Rezyklatanteil<\/strong>, die Reparierbarkeit<\/strong> sowie Informationen zur Materialzusammensetzung<\/strong> digital, standardisiert und \u00fcber den gesamten Lebenszyklus bereitstellen. Diese Anforderungen lassen sich nur effizient erf\u00fcllen, wenn die zugrunde liegende Software- und IT-Architektur von Anfang an auf Interoperabilit\u00e4t, Skalierbarkeit und Sicherheit ausgelegt ist. Insell\u00f6sungen oder manuelle Datensammlungen werden den kommenden Pflichten aus der ESPR auf Dauer nicht gerecht. Mit der Verwaltungsschale (Asset Administration Shell, kurz AAS)<\/a> und der Open-Source-Middleware Eclipse BaSyx<\/a> stehen bereits heute Bausteine bereit, die diese Anforderungen adressieren und sich in bestehende IT-Landschaften integrieren lassen. In diesem Beitrag zeigen wir vom gesetzlichen Rahmen bis zur technischen Umsetzung, welche Standards relevant sind, wie der Digitale Zwilling<\/a> als Fundament dient und wie Sie mit Eclipse BaSyx eine Digitaler-Produktpass-Softwarearchitektur<\/strong> aufbauen k\u00f6nnen.<\/p>\n

Warum die Umsetzung komplexer ist als erwartet<\/h2>\n

Formal wirkt die Umsetzung zun\u00e4chst \u00fcberschaubar: Produktdaten strukturiert erfassen und bereitstellen. Doch drei zentrale Herausforderungen erh\u00f6hen die Komplexit\u00e4t erheblich:<\/p>\n

    \n
  1. Verteilte Datenquellen<\/strong>: Die relevanten Informationen entstehen in unterschiedlichen Systemen wie ERP, Produktion oder Nachhaltigkeitsmanagement und liegen in verschiedenen Formaten vor.<\/li>\n
  2. Lebenszyklus-Dynamik<\/strong>: Produktdaten ver\u00e4ndern sich kontinuierlich, von der Herstellung \u00fcber die Nutzung bis zur Wiederverwertung. Der DPP muss diese Dynamik abbilden und dabei konsistent bleiben.<\/li>\n
  3. Differenzierte Zugriffe<\/strong>: Einige Daten m\u00fcssen \u00f6ffentlich zug\u00e4nglich sein, andere unterliegen klaren Schutzanforderungen. Welche Regeln gelten, h\u00e4ngt vom jeweiligen Akteur entlang der Wertsch\u00f6pfungskette ab.<\/li>\n<\/ol>\n

    Der Digitale Produktpass ist daher kein isoliertes IT-Projekt, sondern eine Architekturaufgabe. <\/strong>Eine geeignete Digitaler-Produktpass-Software muss diese Anforderungen im Zusammenspiel von Systemen, Datenfl\u00fcssen und Sicherheitsmechanismen abbilden. Das gilt insbesondere, wenn die Pflichten aus der ESPR zuverl\u00e4ssig und auditierbar erf\u00fcllt werden sollen.<\/p>\n

    \"Anforderungen
    Abbildung 1: Der Digitale Produktpass muss aus mehreren Systemen, Datenquellen und von\/an Akteuren entlang des gesamten Produktlebenszyklus Produktdaten strukturiert erfassen und bereitstellen. (Visualisiert am Beispiel einer Autobatterie.)<\/figcaption><\/figure>\n

    Welche Standards definieren den Digitalen Produktpass?<\/h2>\n

    Die Umsetzung des Digitalen Produktpasses basiert auf klar definierten Rahmenbedingungen. Die ESPR legt die regulatorischen Anforderungen fest, w\u00e4hrend mehrere miteinander verzahnte Normen unterschiedliche technische Aspekte abdecken. Dazu geh\u00f6ren die Datenstruktur, der Datenaustausch sowie die Absicherung der Systeme:<\/p>\n\n\n\n\n\t\n\n\t\n\t\n\t\n\t\n\t\n\t\n\t\n\t
    Standard<\/th>Fokus<\/th>Bedeutung f\u00fcr die Umsetzung<\/th>\n<\/tr>\n<\/thead>\n
    EN 18219<\/td>Eindeutige Identifikatoren<\/td>Grundlage f\u00fcr die eindeutige Identifikation von Produkten und Akteuren<\/td>\n<\/tr>\n
    EN 18220<\/td>Datentr\u00e4ger<\/td>Verkn\u00fcpfung physischer Produkte mit digitalen Informationen (z. B. QR-Codes)<\/td>\n<\/tr>\n
    EN 18216<\/td>Datenaustauschprotokolle<\/td>Technische Grundlage f\u00fcr den Austausch von DPP-Daten<\/td>\n<\/tr>\n
    EN 18222<\/td>APIs und Zugriff<\/td>Definition von Schnittstellen f\u00fcr Zugriff und Lebenszyklus<\/td>\n<\/tr>\n
    EN 18223<\/td>Datenmodell<\/td>Struktur und semantische Beschreibung des DPP<\/td>\n<\/tr>\n
    EN 18221<\/td>Speicherung und Archivierung<\/td>Anforderungen an Persistenz und Nachvollziehbarkeit<\/td>\n<\/tr>\n
    EN 18239<\/td>Zugriff und Sicherheit<\/td>Regeln f\u00fcr Zugriffsrechte und Datenschutz<\/td>\n<\/tr>\n
    EN 18246<\/td>Integrit\u00e4t und Vertrauen<\/td>Sicherstellung von Authentizit\u00e4t und Datenqualit\u00e4t<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n\n

    Um beispielsweise die gesetzliche Pflicht zur Bereitstellung des Product Carbon Footprint<\/strong> oder des Rezyklatanteils<\/strong> zu erf\u00fcllen, ben\u00f6tigen Unternehmen einerseits diese Normen (etwa die EN 18223<\/strong> f\u00fcr das Datenmodell) und andererseits eine Software- und IT-Architektur, die diese Spezifikationen durchg\u00e4ngig unterst\u00fctzt.<\/p>\n

    Das zeigt: Der Digitale Produktpass ist weit mehr als ein Datenformat<\/strong>. Erst das Zusammenspiel aller Aspekte (Struktur, Austausch, Absicherung und langfristige Verf\u00fcgbarkeit) erm\u00f6glicht einen funktionierenden DPP, der die gesetzlichen Anforderungen abdeckt. F\u00fcr Unternehmen bedeutet das: Es geht nicht darum, eigene Strukturen frei zu definieren, sondern vorhandene Spezifikationen sinnvoll zu nutzen und konsequent in die eigene Architektur zu integrieren.<\/p>\n

    Welche Software wird f\u00fcr den Digitalen Produktpass ben\u00f6tigt?<\/h2>\n

    F\u00fcr viele Unternehmen wirkt es zun\u00e4chst naheliegend, nach einer fertigen \u00bbDigitaler-Produktpass-Software\u00ab zu suchen, die man einmal installiert und damit alle Anforderungen abdeckt. Tats\u00e4chlich entsteht der DPP jedoch aus dem Zusammenspiel bestehender Systeme und einer passenden Middleware f\u00fcr Digitale Zwillinge.<\/p>\n

      \n
    1. Bestehende Systeme:<\/strong> ERP, PLM, MES, Qualit\u00e4ts- und Nachhaltigkeitsl\u00f6sungen, in denen heute bereits ein Gro\u00dfteil der relevanten Informationen entsteht.<\/li>\n
    2. Standardisierte Datenmodelle:<\/strong> etwa die Teilmodelle der Industrial Digital Twin Association (IDTA) f\u00fcr Nameplate, Product Carbon Footprint oder Wartung.<\/li>\n
    3. Middleware f\u00fcr Digitale Zwillinge:<\/strong>\u00a0eine Plattform, die diese Datenquellen \u00fcber Verwaltungsschalen (AAS) verbindet, standardisierte Schnittstellen bereitstellt und Sicherheits- sowie Governance-Anforderungen umsetzt. Eclipse BaSyx \u00fcbernimmt genau diese Rolle: Es stellt die Middleware bereit, mit der sich Digitale Zwillinge auf Basis der AAS verwalten, abfragen und in Datenr\u00e4umen bereitstellen lassen. Statt eine propriet\u00e4re DPP-Software von Grund auf zu entwickeln, k\u00f6nnen Unternehmen BaSyx als\u00a0offene Softwarebasis f\u00fcr den Digitalen Produktpass<\/strong>\u00a0nutzen und ihre bestehenden Systeme daran anbinden.<\/li>\n<\/ol>\n

      Vom Digitalen Zwilling zum Digitalen Produktpass<\/h2>\n

      Modulare Datenstruktur, standardisierte Schnittstellen, Lebenszyklusf\u00e4higkeit: Diese Anforderungen des DPP werden durch das Konzept des Digitalen Zwillings<\/a> bereits adressiert. Die Verwaltungsschale (AAS)<\/strong>\u00a0<\/strong>bietet hierf\u00fcr den etablierten Ansatz: Sie beschreibt ein Asset als Digitalen Zwilling und strukturiert dessen Informationen in modularen Teilmodellen.<\/p>\n

      Metadaten und fachliche Inhalte trennen<\/h3>\n

      Ein zentrales Architekturprinzip ist die Trennung von Metadaten<\/strong> (Identifikation, Versionierung, G\u00fcltigkeit) und fachlichen Inhalten<\/strong> (CO\u2082-Fu\u00dfabdruck bzw. Product Carbon Footprint, Materialzusammensetzung, Wartungsinformationen). Die fachlichen Inhalte werden in eigenst\u00e4ndigen Teilmodellen organisiert, die unabh\u00e4ngig voneinander entwickelt, aktualisiert und wiederverwendet werden k\u00f6nnen.<\/p>\n

      F\u00fcr viele DPP-relevante Inhalte stehen heute bereits IDTA-Teilmodelle<\/strong> zur Verf\u00fcgung, z.B. f\u00fcr Nameplate-Informationen, den Product Carbon Footprint oder Wartungs- und Dokumentationsdaten. Wer diese Templates nutzt, reduziert den Modellierungsaufwand und bleibt kompatibel zu entstehenden Industriestandards.<\/p>\n

      Der DPP als Sicht auf den Digitalen Zwilling<\/h3>\n

      Der entscheidende Punkt: Der DPP muss kein eigenes System sein.<\/strong> Er kann als strukturierte Sicht auf die in einem Digitalen Zwilling bereits vorhandenen Informationen realisiert werden. Wie die folgende Abbildung zeigt, setzt sich der Digitale Produktpass aus Bausteinen der AAS zusammen. Er besteht aus einem dedizierten Metadaten-Element und den jeweils relevanten fachlichen Teilmodellen:<\/p>\n

      \"
      Abbildung 2: Der Digitale Produktpass l\u00e4sst sich auf eine bestehenden Digitaler-Zwilling-Infrastruktur aufbauen und sich als strukturierte Sicht auf bereits vorhandene Informationen (Bausteinen der Verwaltungsschale (AAS)) zusammensetzen.<\/figcaption><\/figure>\n

      F\u00fcr eine Batterie k\u00f6nnen das etwa Teilmodelle zum CO\u2082-Fu\u00dfabdruck<\/a>, zum Anteil recycelter Materialien und zur Komponentenherkunft sein. F\u00fcr eine Maschine stehen stattdessen Energieverbrauch, Wartungshistorie und technische Dokumentation im Fokus. Die zugrunde liegende Struktur bleibt dieselbe. Genau das macht den Ansatz skalierbar und branchen\u00fcbergreifend einsetzbar<\/strong>.<\/p>\n

      \n

      Warum der Digitale Produktpass eine Architekturfrage ist<\/h3>\n

      Der DPP entsteht aus dem Zusammenspiel mehrerer Systeme, Datenquellen und Akteure entlang des gesamten Produktlebenszyklus. Wer den DPP auf einer bestehenden Digital-Twin-Infrastruktur aufsetzt, vermeidet Insell\u00f6sungen. Gleichzeitig lassen sich weitere Anwendungsf\u00e4lle wie Catena\u2011X<\/strong><\/a> oder Manufacturing\u2011X<\/strong><\/a> \u00fcber dieselbe Plattform bedienen.<\/p>\n

       <\/p>\n

      Checkliste: So setzen Sie die Anforderungen an den Digitalen Produktpass mit der richtigen Software um<\/strong><\/h4>\n

      1.\u00a0Quellsysteme identifizieren und DPP-Anforderungen zuordnen<\/strong>
      \nErfassen Sie relevante Systeme (z.\u202fB. ERP, PLM, MES, Qualit\u00e4ts- und Nachhaltigkeitstools) und legen Sie fest, welche DPP-Anforderungen (PCF, Rezyklatanteil, Material, Reparierbarkeit usw.) daraus bedient werden sollen.<\/p>\n

       <\/p>\n

      2.\u00a0Daten auf standardisierte AAS-Teilmodelle mappen<\/strong>
      \nOrdnen Sie fachliche Inhalte wie PCF, Rezyklatanteil, Materialdaten oder Wartungsinformationen passenden IDTA-Teilmodellen zu. Trennen Sie konsequent zwischen Metadaten und fachlichen Inhalten, um Wiederverwendung und Erweiterbarkeit zu erm\u00f6glichen.<\/p>\n

       <\/p>\n

      3.\u00a0DPP-Sicht mit Eclipse BaSyx bereitstellen<\/strong><\/p>\n

      Stellen Sie die DPP-Sicht als Kombination aus Metadaten-Element und ausgew\u00e4hlten Teilmodellen \u00fcber die BaSyx-Middleware bereit. Dies geschieht zun\u00e4chst intern und sp\u00e4ter auch in Datenr\u00e4umen wie Catena-X oder Manufacturing-X. BaSyx \u00fcbernimmt dabei die Rolle der zentralen Digitaler-Produktpass-Softwareplattform f\u00fcr Verwaltung, Abfrage und sicheren Austausch der Daten.<\/p>\n<\/div>\n

      Digitaler Produktpass Software: <\/strong>BaSyx als Open-Source-Basis f\u00fcr den DPP<\/h3>\n

      Wie l\u00e4sst sich diese Architektur konkret realisieren? Hier setzt Eclipse BaSyx<\/a>\u00a0 an: eine vom Fraunhofer IESE koordinierte Open-Source-Middleware zur Realisierung der Verwaltungsschale. BaSyx bildet die zentrale Softwareplattform, auf der Digitale Zwillinge und darauf aufbauend Digitale Produktp\u00e4sse betrieben werden.<\/p>\n

      Was <\/strong>Eclipse BaSyx mitbringt<\/strong><\/h3>\n

      BaSyx stellt die zentralen Infrastrukturkomponenten bereit, die f\u00fcr den Betrieb von Digitalen Zwillingen und damit f\u00fcr den DPP erforderlich sind:<\/p>\n