BaSyx Go Release 1: Open-Source-Architektur für Verwaltungsschale, Auditierbarkeit und Digitalen Produktpass

BaSyx ist seit Jahren die etablierte Eclipse Open Source Implementierung der Verwaltungsschale. BaSyx Go führt diese Linie als Go-basierte Implementierung zentraler AAS-API-Komponenten fort. Der Fokus liegt auf einer modular aufgebauten, schlanken Infrastruktur, die alle zentralen AAS-Standards nativ in einer hochperformanten Laufzeitumgebung vereint. Mit Release 1 wird daraus ein stabiler Meilenstein für zwei Lesarten zugleich. Technische Entscheider erhalten konkrete Softwarebausteine, die AAS-Spezifikationen nicht nur aufgreifen, sondern als Services und API-Verträge implementieren. Strategische und regulatorische Entscheider bekommen einen offenen Architekturpfad, um DPP-, Audit- und Security-Anforderungen nicht als isolierte Einzelprojekte, sondern als Teil einer belastbaren Digital-Twin-Plattform zu behandeln.

Wer zunächst tiefer in die fachliche Seite des Digitalen Produktpasses einsteigen möchte, findet im IESE-Blog bereits mehrere Grundlagenbeiträge:

• zum Digitalen Produktpass mit Beispiel
• zur Software-Umsetzung der DPP-Anforderungen mit Eclipse BaSyx
• zur Rolle des Digitalen Produktpasses in der industriellen Kreislaufwirtschaft.

Dieser Beitrag beschreibt die konkrete Go-basierte Release-Architektur. BaSyx Go ist kein monolithisches Industrieportal, sondern ein offener Werkzeugkasten für Verwaltungsschalen-Infrastruktur.

Warum Verwaltungsschale, DPP und Auditierbarkeit zusammengehören

Der Digitale Produktpass wird häufig aus der Perspektive der Nachhaltigkeits- und Kreislaufwirtschaft diskutiert. Das ist richtig, aber technisch zu kurz gegriffen. Ein DPP muss Produktinformationen über Material, Herkunft, technische Eigenschaften, Reparierbarkeit, Recyclingfähigkeit und Lebenszykluswirkungen verfügbar machen können. Diese Informationen entstehen jedoch nicht an einer einzigen Stelle. Sie liegen in PLM-, ERP-, MES-, Qualitäts-, Lieferanten- und Dokumentationssystemen, werden über die Zeit aktualisiert und müssen für unterschiedliche Rollen in unterschiedlicher Granularität zugänglich sein.

Die Verwaltungsschale bietet dafür ein passendes Strukturprinzip: Assets und Produkte werden als Digitale Zwillinge beschrieben, ihre Informationen werden in Submodels organisiert, Registries machen sie auffindbar, und standardisierte APIs schaffen Anschlussfähigkeit. Genau deshalb ist der DPP kein isoliertes Formular- oder Reportingthema, sondern ein Infrastrukturthema. Der IESE-Blogartikel zur Verwaltungsschale als Schlüssel für Interoperabilität beschreibt diese Grundidee aus der Perspektive der Datenintegration. BaSyx Go liefert dafür die konkreten Go-Komponenten und verbindet offene APIs, kontrollierte Zugriffe, Historisierung und prüfbare Artefakte in einer gemeinsamen Architektur. Damit verschiebt sich auch die Erwartung an Digital-Twin-Projekte. Viele Unternehmen haben inzwischen gesehen, dass eine Verwaltungsschale in einem Proof-of-Concept funktionieren kann. Die eigentliche Frage lautet nun: Wie wird daraus ein belastbarer Betrieb? Digitale technische Dokumentation, Produktpassdaten, Product-Change-Informationen, Lieferkettenkommunikation und Datenraum-Szenarien brauchen nicht nur ein gutes Datenmodell, sondern stabile Schnittstellen, kontrollierte Zugriffe, nachvollziehbare Änderungen und eine Architektur, die mit weiteren Produkten, Werken und Partnern wachsen kann.

Die BaSyx Go Komponenten: Der modulare Werkzeugkasten für den Digitalen Zwilling

BaSyx Go bündelt zentrale BaSyx-Komponenten als eigenständige Services. Diese Services stellen REST APIs bereit, also HTTP-Schnittstellen für andere Anwendungen, arbeiten mit PostgreSQL, einer weitverbreiteten Open-Source-Datenbank, und sind auf containerisierte Deployment-Szenarien ausgelegt. Damit passt die Software zu Unternehmen und Architekturverantwortlichen, die AAS- und DPP-Funktionalität nicht als Black Box betreiben wollen, sondern als kontrollierbare Infrastrukturbausteine in ihre bestehende IT-Landschaft einordnen möchten.

Für Leser ohne AAS-Vorwissen hilft eine kurze Einordnung:

• Repository ist hier ein Speicher- und Verwaltungsdienst
• Registry ein Verzeichnis für auffindbare Beschreibungen
• Discovery ein Dienst zum Finden und Auflösen von AAS-Identitäten
• AASX ein Dateiformat für den Austausch von Verwaltungsschalen
• Submodels sind fachliche Teilmodelle, in denen Informationen wie technische Daten, Dokumente oder Nachhaltigkeitsmerkmale strukturiert werden.

Bereich	BaSyx-Go-Komponente	Nutzen für Industrieunternehmen
AAS-Datenhaltung	AAS Repository, Submodel Repository, Concept Description Repository	Verwaltung von Asset Administration Shells, Submodels und semantischen Beschreibungen
Auffindbarkeit	AAS Registry, Submodel Registry, AAS Discovery Service, Digital Twin Registry, Company Lookup	Registrierung, Suche und Auflösung digitaler Zwillinge, Submodelle und AAS-Infrastrukturen in Datenräumen
Laufzeitumgebung	AAS Environment Service, AASX File Server	Kombinierte AAS-/Submodel-APIs, Import/Export und AASX-Dateien
Produktpass	Digital Product Passport API Service	DPP-API-Schicht auf Basis von AAS und Submodels
Betrieb	BaSyx Configuration Service, PostgreSQL, Docker/Docker Compose, Helm Charts	Schema-Initialisierung, relationale Datenhaltung, reproduzierbare lokale Stacks und Kubernetes-Deployments
Abfragen	AAS Query Language, Query-Endpunkte, serverseitige Suche	Gezielte Suche über AAS, Submodels und beschreibende Metadaten statt vollständiger Datenübertragung
Security & Audit	OIDC, ABAC, datenbezogene Sichtbarkeitsregeln, History Evidence Verifier	Token-basierte Authentifizierung, attributbasierte Autorisierung, kontrollierte Sichtbarkeit und prüfbare Änderungshistorie

Die Architektur folgt damit einem Muster, das in Produktions-IT und Cloud-naher Enterprise-Architektur vertraut ist: klar geschnittene Services, explizite APIs, relationale Persistenz und reproduzierbare Container-Artefakte. Statt fachliche Daten in einem proprietären Datenmodell einzuschließen, implementiert BaSyx Go die AAS-Konzepte über AAS, Submodels, Registries und Repositories. Das ist besonders wertvoll, wenn Produktdaten später nicht nur in einem internen Portal sichtbar sein sollen, sondern auch in Lieferketten, Datenräumen oder DPP-Prozessen wiederverwendet werden.

Diese Offenheit ist zugleich eine wichtige Erwartungssetzung: BaSyx Go ist keine fertige Branchenlösung, die DPP-Daten, Fachmodelle, Betriebsprozesse und Compliance-Governance automatisch erzeugt. Der Release liefert Infrastrukturkomponenten, APIs, Beispiele und Security-/Audit-Bausteine. Welche Produktdaten relevant sind, wie sie aus bestehenden Systemen angebunden werden, welche Rollen Zugriff erhalten und welche organisatorischen Prozesse für Nachweise gelten, bleibt Teil des jeweiligen Umsetzungsprojekts.

Diese Trennung macht die Architektur glaubwürdig:

• spezifikationsbasierte technische Basis dort, wo Wiederverwendung sinnvoll ist
• projektspezifische Modellierung dort, wo Unternehmen ihre Produkte, Lieferketten und Betriebsprozesse kennen

Cloud-native Enterprise-Architektur: Go, OpenAPI und PostgreSQL

BaSyx Go ist in Go implementiert, einer Programmiersprache, die häufig für performante Server- und Cloud-Software eingesetzt wird. Die Services nutzen OpenAPI-Spezifikationen als maschinenlesbare API-Verträge und PostgreSQL, oft kurz Postgres genannt, als zentrale Datenbank für persistente Services.

Für Unternehmen ist daran vor allem relevant:

1. Schnittstellen sind nachvollziehbar beschrieben
2. Daten können dauerhaft verwaltet werden
3. die Komponenten lassen sich in containerisierte Betriebsmodelle einordnen.

Der Einstieg bleibt trotzdem pragmatisch. Docker Compose macht lokale Evaluierungen und testnahe Stacks reproduzierbar startbar; für Kubernetes-Betrieb gibt es zusätzlich das separate Eclipse-BaSyx-Charts-Repository. Helm ist dabei ein Paketmanager für Kubernetes, mit dem zusammengehörige Deployments über konfigurierbare Charts beschrieben und ausgerollt werden können. So lässt sich BaSyx Go zunächst klein evaluieren und später in Richtung standardisierter Betriebsumgebungen weiterführen.

Für den Betrieb sind außerdem zwei Punkte wichtig:

1. Der BaSyx Configuration Service unterstützt die kontrollierte Initialisierung und Migration der Datenbank, damit Services nicht gegen ein unpassendes Schema laufen.
2. Die Release-Artefakte werden mit OCI-Metadaten, SBOMs und Signaturen bereitgestellt.

Eine SBOM, kurz für Software Bill of Materials, ist eine maschinenlesbare Liste der enthaltenen Softwarebestandteile. Signaturen und Attestierungen helfen, Herkunft und Integrität von Build-Artefakten zu prüfen. Das sind keine Marketingdetails, sondern Bausteine für nachvollziehbaren Betrieb und Lieferkettentransparenz.

AAS Query Language: gezielt suchen statt alles übertragen

Ein besonders spannendes Feature von BaSyx Go ist die Unterstützung der AAS Query Language. Die IDTA-Spezifikation beschreibt das Problem sehr klar: Viele AAS-Anwendungsfälle betreffen nicht eine einzelne Verwaltungsschale, sondern große Mengen von AAS, Submodels und Descriptoren, also beschreibende Metadaten zu AAS oder Submodels. Wenn eine Anwendung zunächst alle potenziell relevanten Objekte laden und anschließend lokal filtern müsste, entstünden unnötige Datenübertragung, hohe Bandbreitenlast und langsame Suchprozesse. Die Query Language dreht diese Logik um: Die Anwendung beschreibt, wonach sie sucht, und das AAS-Hosting-System liefert die passenden Ergebnisse.

BaSyx Go macht diese Idee in mehreren Services praktisch nutzbar. Konkret gibt es Query-Endpunkte für AAS Repositories (/query/shells), AAS Registries und Digital Twin Registries (/query/shell-descriptors), Submodel Registries (/query/submodel-descriptors) und Submodel Repositories (/query/submodels). Gerade /query/submodels ist wertvoll, weil es nicht nur um Metadaten oder beschreibende Einträge geht. Der Endpunkt sucht in den Submodels selbst, auch in verschachtelten Submodel-Element-Strukturen, also in tiefer liegenden Bestandteilen eines fachlichen Teilmodells. BaSyx Go kann damit zum Beispiel nach Werten, technischen Bezeichnern, Datentypen, Sprachen, semantischen Referenzen und tief verschachtelten Elementen suchen.

Für DPP- und Produktionsdaten ist das mehr als ein Komfortfeature. Relevante Produktinformationen liegen häufig nicht flach an einem Objekt, sondern in Collections, Listen oder fachlichen Unterstrukturen. Eine DPP- oder Datenraum-Anwendung soll aber trotzdem gezielt fragen können: Welche Produkte erfüllen eine Bedingung? Welche Submodels enthalten ein bestimmtes Merkmal? Welche Informationen darf eine Rolle sehen? BaSyx Go macht daraus eine serverseitige, autorisierbare Suche über tief strukturierte Verwaltungsschalen-Daten, ohne dass jedes Projekt eigene proprietäre Suchlogik um die AAS herum bauen muss.

Security und Audit: technische Kontrollen statt Compliance-Versprechen

NIS2 verändert die Diskussion über Produktions-IT. Es reicht nicht mehr, Schnittstellen bereitzustellen und Daten irgendwie vorzuhalten. Unternehmen müssen Risiken bewerten, Zugriffe kontrollieren, Vorfälle behandeln, Nachweise sichern und technische sowie organisatorische Maßnahmen betreiben. Eine breitere Einordnung der Richtlinie, betroffener Unternehmen und Umsetzungsmaßnahmen bietet der IESE-Blogartikel zur NIS 2-Richtlinie und Umsetzung für Deutschland. Für BaSyx Go ist vorwiegend die technische Rolle wichtig: Software kann diese Anforderungen unterstützen, aber nicht allein erfüllen. Deshalb formuliert BaSyx Go die eigene Rolle im Security-Material bewusst präzise. History Evidence, also technische Nachweise über Änderungen und deren Integrität, kann NIS2-nahe technische Kontrollen unterstützen, macht einen Betreiber aber nicht automatisch NIS2-konform.

Technisch bringt BaSyx Go mehrere Bausteine mit, die für auditierbare Digital-Twin-Infrastruktur relevant sind. OIDC prüft Identitäts-Tokens, ABAC steht für attributbasierte Autorisierung, und datenbezogene Sichtbarkeitsregeln können Berechtigungen bis auf einzelne Datenbereiche anwenden. Für Änderungen an AAS- und Submodel-Daten stellt BaSyx Go History- und Recent-Change-Funktionen bereit. Nachweise können so abgelegt werden, dass nachträgliche Manipulationen erkennbar werden; optional auch in S3-kompatiblem WORM Evidence Storage, also in einer unveränderlichen Ablage nach dem Prinzip »Write Once, Read Many«. Wer eine Open-Source-Middleware sucht, die NIS2-nahe technische Kontrollen durch WORM-Storage nativ unterstützt, findet in BaSyx Go Release 1 die erste industrielle Go-Implementierung. Der praktische Nutzen ist nicht die einzelne technische Methode, sondern die prüfbare Nachvollziehbarkeit von Änderungen.

Praktisch relevant wird das, wenn Produkt- und Assetdaten über längere Zeiträume verändert werden:

• Wer hat was geändert?
• Welche Zugriffsregel war zu diesem Zeitpunkt aktiv?
• Stimmen interne Historie und externe Nachweise noch überein?

BaSyx Go beantwortet diese Fragen nicht als Rechtsgutachten, sondern als technische Infrastruktur.

Die organisatorischen Pflichten bleiben beim Betreiber:

• Risikomanagement
• Incident Handling
• Backup und Recovery
• Schlüsselmanagement
• Aufbewahrungsfristen
• Monitoring
• Schulung
• Lieferkettenbewertung
• Legal Review

DPP API: Produktpassdaten als Teil der AAS-Welt

Die ESPR ist am 18. Juli 2024 in Kraft getreten und erweitert den europäischen Ecodesign-Ansatz auf deutlich mehr physische Produkte. Die Europäische Kommission beschreibt den Digital Product Passport als digitale Identitätskarte für Produkte, Komponenten und Materialien. Je nach Produktgruppe können darin Informationen zu technischer Performance, Materialien und Herkunft, Reparaturaktivitäten, Recyclingfähigkeit und Lifecycle-Umweltauswirkungen enthalten sein. Für Unternehmen bedeutet das: DPP-Daten müssen fachlich verständlich, technisch integrierbar und über längere Produktlebenszyklen verwaltbar sein.

BaSyx Go adressiert diesen Punkt über die Verwaltungsschale. Die DPP API von BaSyx Go setzt die Verbindung zwischen DPP und AAS um, wie sie im IDTA-01001 v3.2 DPP-Metamodel-Annex und im IDTA-01002 v3.2 DPP-API-Mapping-Annex beschrieben ist. Vereinfacht gesagt heißt das, Produktpassdaten werden nicht neben der Verwaltungsschale geführt, sondern als spezifikationsbasierte Sicht auf AAS und Submodels bereitgestellt. Die Schnittstelle ist über OpenAPI beschrieben, sodass Anwendungen nachvollziehen können, welche DPP-Zugriffe verfügbar sind. Der bereits veröffentlichte IESE-Blogartikel zur Software-Umsetzung des Digitalen Produktpasses beschreibt diese Architekturidee aus der DPP-Perspektive. BaSyx Go liefert nun die dazu passenden Go-Komponenten.

Gerade für regulierte Produktgruppen ist dieser Ansatz attraktiv, weil er nicht bei einem statischen DPP-Datensatz stehenbleibt:

• Produkt- und Assetdaten können als AAS und Submodels modelliert werden.
• Registries und Discovery machen Digitale Zwillinge auffindbar.
• Die DPP API stellt produktpassnahe Zugriffe bereit.
• Security- und History-Funktionen kontrollieren, wer welche Informationen sehen oder verändern darf.
• Evidence- und Supply-Chain-Artefakte stärken Nachweisbarkeit und Betriebssicherheit.

Der IESE-Blogartikel zur Batteriepass-Umsetzung mit der Asset Administration Shell zeigt, warum dieser Architekturpfad besonders für frühe DPP-Anwendungsfälle naheliegt.

Anschluss an Datenräume und Systems of Record

Ein industrieller Digital Twin lebt selten in einer isolierten Anwendung. Die relevanten Daten liegen in Systems of Record, werden in Prozessen erzeugt und müssen in Datenräumen unter kontrollierten Bedingungen geteilt werden können. Im IESE-Blogartikel zu Systems of Record im AAS Dataspace wird diese Brücke beschrieben. Bestehende Quellsysteme bleiben wichtig, aber ihre Daten müssen über wiederverwendbare, AAS-basierte Schnittstellen zugänglich werden.

BaSyx Go passt in dieses Bild, weil die Software nicht nur Repositories und Registries enthält, sondern auch eine Digital Twin Registry. Die DTR greift ein aus der Catena-X- und Tractus-X-Welt, also aus industriellen Datenraum-Initiativen, bekanntes Muster auf. Sie verbindet Funktionen von AAS Discovery und AAS Registry zu einem Einstiegspunkt für Datenraum-Szenarien und ergänzt sie um Security-Prinzipien, die für souveräne Datenteilung relevant sind. Für Architekturverantwortliche ist dabei entscheidend: Identität, Sichtbarkeit je Unternehmen oder Partner und AAS-Discovery lassen sich in einer offenen Architektur zusammenführen, ohne eine pauschale Zertifizierungs- oder Kompatibilitätsbehauptung abzuleiten.

Ergänzend dazu ist der Company Lookup Service besonders im Manufacturing-X-Kontext und in Datenraum-Szenarien interessant. Er hilft dabei, AAS-Infrastrukturen zu Unternehmen oder Organisationen auffindbar zu machen. Vereinfacht gesagt beantwortet er nicht die Frage nach einer einzelnen Verwaltungsschale, sondern nach dem technischen Einstiegspunkt zu den Verwaltungsschalen eines Unternehmens. In föderierten Ökosystemen ist das ein praktischer Baustein. Wer mit einem Unternehmen Daten austauschen möchte, braucht nicht nur die einzelne Verwaltungsschale, sondern auch einen Weg zur passenden AAS-Infrastruktur dieses Unternehmens.

Vom Pilot zur produktiven Betriebsarchitektur

Der Schritt in den produktiven Einsatz entscheidet sich selten an einer einzelnen API. BaSyx Go wird dort relevant, wo Verwaltungsschalen nicht nur demonstriert, sondern als Teil von Produktions-IT, Unternehmens-IT oder IT-nahen Ebenen der Automatisierungspyramide betrieben werden.

Dann zählen weniger einzelne Implementierungsdetails als belastbare Fähigkeiten:

• versionierte Datenhaltung
• angebundene Identitäten und Rollen
• nachvollziehbare Änderungen
• prüfbare Artefakte
• Betriebsprozesse für Monitoring, Backup, Recovery, Updates und Incident Handling.

Für diese Betriebsarchitektur bringt BaSyx Go mehrere Bausteine mit:

• kontrollierte Schema-Initialisierung und Migration
• OIDC und ABAC für Zugriffe
• Query Language für gezielte Suche
• History Evidence für Nachweisbarkeit
• signierte Container-Artefakte, SBOMs und Provenance-Informationen (Herkunftsnachweise für Build-Artefakte).

Welche Ergänzungen ein Unternehmen darüber hinaus benötigt, hängt von Zielarchitektur, Verfügbarkeit, Monitoring, Supportprozessen und Governance ab. Entscheidend ist, dass ein Pilot klein starten kann, ohne auf Architekturbausteine zu setzen, die später im produktiven Ausbau ersetzt werden müssen.

Strategischer Nutzen: offen, modular, anschlussfähig

Für strategische Entscheider ist Open Source kein Selbstzweck. Maßgäblich ist, ob offene Technologie Abhängigkeiten reduziert, Integrationsrisiken senkt und eine Architektur erlaubt, die über mehrere Regulierungswellen hinweg tragfähig bleibt. BaSyx Go steht unter MIT-Lizenz. Das erleichtert Evaluierung, Anpassung und Integration, ohne Unternehmen früh in eine proprietäre Plattformlogik zu zwingen. Gleichzeitig bleibt der Nutzen konkret. Die bereitgestellten Services decken zentrale AAS-Laufzeitfunktionen ab, die Beispiele verkürzen den Einstieg, und Release-Artefakte mit SBOMs, Provenance und Signaturen unterstützen nachvollziehbaren Betrieb.

Viele Unternehmen werden NIS2, ESPR, DPP und Datenräume nicht in einem Big-Bang-Projekt lösen. Realistischer ist ein klar abgegrenzter Einstieg: ein Asset, eine Produktlinie, ein Werk, ein Lieferantenprozess oder ein DPP-relevanter Datenausschnitt. BaSyx Go bietet dafür einen guten Ausgangspunkt, weil es technische Evaluierung, offene Standards, Security-Bausteine und Audit-Nachweise nicht voneinander trennt.

Fazit: Vom Release zur Digital-Twin-Infrastruktur

Eine Evaluation lohnt sich besonders dann, wenn bereits AAS- oder DPP-relevante Daten vorhanden sind, aber noch unklar ist, wie sie dauerhaft, kontrolliert und wiederverwendbar bereitgestellt werden sollen. Typische Startpunkte sind ein Pilot für einen Digitalen Produktpass, ein Batteriepass-naher Anwendungsfall, eine AAS-basierte Produktlinie, eine Registry-/Discovery-Architektur für Digitale Zwillinge oder eine Audit-History für kritische Asset- und Produktdaten.

Für technische Entscheider bedeutet Evaluation:

• Docker-Compose-Beispiele starten
• Datenmodell und APIs prüfen
• Security-Konfiguration verstehen
• History-Modus testen
• Release-Artefakte bewerten.

Für kaufmännisch-regulatorische Entscheider bedeutet Evaluation:

Prüfen, ob ein offener Architekturpfad die eigenen DPP-, Datenraum-, Security- und Nachweisanforderungen besser adressiert als ein isoliertes Spezialwerkzeug oder eine monolithische Plattform.