14. Aug. 2025
Skalierbarkeitsanalyse von AAS-Lösungen
Die Skalierbarkeit von Asset-Administration-Shell-Lösungen ist entscheidend, damit die Technologie ihr Potenzial in der digitalen Transformation der Industrie voll ausschöpfen kann. Der Fokus liegt auf drei Open-Source-Implementierungen: Eclipse BaSyx, FA³ST und Tractus-X SLDT Registry. Die Asset-Administration-Shell (AAS) bietet einen standardisierten Ansatz zur Darstellung digitaler Zwillinge in der Industrie 4.0 und erleichtert so die Zusammenarbeit entlang komplexer Lieferketten. Gleichzeitig stellt die Skalierbarkeit eine zentrale Herausforderung dar, die über die breite Einführung dieser Technologie entscheidet.
Dieser Blogbeitrag basiert auf der Bachelorarbeit von Niklas Sirch, die in Zusammenarbeit mit XITASO durchgeführt wurde und bietet praktische Einblicke in die Skalierbarkeit aktueller AAS-Implementierungen.
Hintergrund
Obwohl die AAS erhebliches Potenzial zur Förderung der digitalen Transformation in der Industrie bietet, muss diese Technologie hoch-skalierbar bleiben. Es werden mehrere Open-Source Implementierung untersucht hinsichtlich der Frage der Skalierbarkeit: Können aktuelle AAS-Implementierungen effizient mit zunehmenden Datenmengen und Benutzeranforderungen umgehen, wenn die Einführung wächst? Die Bewältigung der Skalierbarkeit ist entscheidend, damit sich die AAS als nachhaltiger Industriestandard etablieren kann.
Mit regulatorischen Initiativen wie dem Digital Product Passport (DPP) sind objektive Bewertungen der Skalierbarkeit zunehmend wichtig geworden. Die Asset Administration Shell (AAS) bietet dabei eine ideale Grundlage, um die Anforderungen des DPP wirksam umzusetzen. Dieser Artikel soll unvoreingenommene Einblicke liefern, inwiefern aktuelle Implementierungen schon skalierbar sind. Die dahinterliegende Arbeit entstand Anfang 2025.
Bewertete Implementierungen
1. Eclipse BaSyx (2.0.0-milestone-04)
Entwickelt vom Fraunhofer IESE, ist BaSyx eine modulare, Java-basierte Plattform, die die vollständige AAS-API unterstützt. Sie teilt Dienste in einzelne Spring Boot-Dienste für flexible Skalierung auf und wird in der Industrie weit verbreitet eingesetzt.
2. FA³ST Service (1.2.0) & Registry (1.1.0)
Vom Fraunhofer IOSB entwickelt, konzentriert sich FA³ST auf Szenarien mit Edge-Geräten. Es unterstützt AAS-Verwaltung, Entdeckung und Konzeptbeschreibungen, mit MQTT- und OPC-UA-Integrationen alles in einem. Es bietet zudem eine Registry-Komponente.
3. Tractus-X SLDT Registry (0.6.2)
Als Teil des Catena-X-Ökosystems bietet Tractus-X eine Komponente welche unter anderem das AAS-Registry Interface implementiert. Diese Registrykomponente, im Zusammenspiel mit anderen Komponenten, nimmt eine Schlüsselrolle bei der Ermöglichung eines sicheren, dezentralen Datenaustauschs ein.
Skalierbarkeitskriterien
Umfang der Analyse
Die Analyse schließt APIs mit minimaler Skalierbarkeitsrelevanz und redundante Komponenten aus. Sie konzentriert sich auf praktische Skalierbarkeitsanforderungen in industriellen Umgebungen.
Funktionale Anforderungen
- Pagination: Effizienter seitenbasierter Zugriff auf große Datensätze.
- Horizontale Skalierbarkeit: Fähigkeit, mit minimalem Setup auf mehreren Servern zu laufen.
Leistungsanforderungen
- Stabile CRUD-Operationen: Antwortzeiten unter 1 Sekunde bei vielen AAS-Instanzen.
- Effiziente Entdeckung: Lineare Skalierung der Suchzeiten mit der Datenmenge.
- Vertikale und horizontale Skalierung: Erhöhte Ressourcen sollten den Durchsatz verbessern.
- Cloud-Bereitschaft: Unterstützung für elastische Skalierung in Plattformen wie Kubernetes.
Leistungsanalyse
Ansatz
Die Leistung wird basierend auf der durchschnittlichen Antwortzeit von API-Endpunkten bei der Durchführung von CRUD-Operationen bewertet. 100 Anfragen werden gemittelt, um Schwankungen zu minimieren. Tests werden mit einem einzigen virtuellen Benutzer durchgeführt, um Konsistenz zu gewährleisten, wobei die Ergebnisse aus lokalen Tests auf einem Intel Core i7 der 13. Generation mit 16 GB RAM stammen.
Ergebnisse der Repositories
BaSyx
Die Antwortzeiten für BaSyx blieben bei unterschiedlichen Instanzzahlen konstant unter 10ms, was Stabilität auch bei hoher Last zeigt und auf effektives Datenbankmanagement hinweist.
FA³ST-Service
Im Gegensatz dazu stiegen die Antwortzeiten des FA³ST-Service bei 30.000 Instanzen deutlich über 1 Sekunde, was auf Einschränkungen und Ineffizienzen hinweist, möglicherweise aufgrund suboptimaler Interaktion mit MongoDB. Hinweis: FA³ST-Service hat Skalierbarkeit nicht als primären Fokus, da es für Edge-Geräte konzipiert ist.
Ergebnisse der AAS-Registries
BaSyx
Das BaSyx-Register hielt stabile Antwortzeiten unter 15 ms aufrecht, was die Effizienz seiner Datenbankverwaltung hervorhebt.
FA³ST-Registry
Die Antwortzeiten stiegen bei mehr Einträgen stark an und überschritten bei 150.000 die tolerierbaren Grenzen, was erhebliche Skalierbarkeitsprobleme offenbart.
Tractus-X
Ähnlich erlebte Tractus-X steigende Antwortzeiten, die bei 300.000 Einträgen unzumutbare Ladezeiten erreichten, insbesondere für Leseoperationen, die in der Datennutzung entscheidend sind.
Discovery-Service-Analyse
Sowohl BaSyx- als auch FA³ST-Implementierungen hatten Schwierigkeiten mit den Antwortzeiten beim Skalieren der Anzahl gespeicherter Einträge, was auf ineffiziente Datenbankabfrageverarbeitung hinweist. Verbesserungen könnten die Optimierung von Datenabfragen auf Datenbankebene umfassen, um den Speicherverbrauch zu reduzieren.
Pagination
Die Unterstützung für Pagination variierte zwischen den Implementierungen. BaSyx, obwohl es den Spezifikationen entspricht, hatte Schwierigkeiten mit Speicherüberlastung, was auf einen Bedarf an effizienter Pagination-Verarbeitung hinweist. FA³ST fehlt die Pagination, ein kritischer Mangel angesichts erhöhter Datenlasten, während Tractus-X erfolgreich Pagination über SQL implementierte.
Die allgemeinen Beobachtungen deuteten auf einen Bedarf an standardisierten Pagination-Einstellungen hin, um Speicher- und Netzwerkeffizienz über AAS-Tools hinweg auszugleichen.
Fazit
Die Skalierbarkeitsanalyse hebt die unterschiedliche Effektivität von BaSyx, FA³ST und Tractus-X bei der Handhabung von realen Daten hervor. BaSyx zeigt vielversprechende stabile Leistung, während FA³ST und Tractus-X Optimierung benötigen, insbesondere in Bezug auf Datenbankabfragen und Pagination. Die Beseitigung dieser Engpässe wird die Fähigkeit jedes Tools verbessern, größere Datensätze effektiv zu verwalten.
Vertikale Skalierbarkeit
Vertikale Skalierbarkeit bezieht sich auf die Verbesserung der Leistung eines Softwaresystems durch Erhöhung der Hardware-Ressourcen wie CPU und RAM. Dieser Abschnitt bewertet, wie die getesteten AAS-Implementierungen auf zusätzliche Ressourcen reagieren.
Ansatz
CPU und Speicher sind Schlüsselfaktoren für die vertikale Skalierung. Die Erhöhung des RAM hatte aufgrund der leichten Operationen der AAS-APIs und des Fehlens von Caching nur minimale Auswirkungen auf die Leistung. Erhebliche RAM-Anforderungen treten nur bei großen Datenoperationen auf. Die Erhöhung der CPU-Kerne verbesserte jedoch den Durchsatz erheblich.
Ergebnisse
Repositories
BaSyx erreichte im Vergleich zum FA³ST-Service überlegene Durchsatzraten, insbesondere bei höheren CPU-Kernzahlen. Während FA³ST bei vier Kernen stagnierte, skalierte BaSyx weiterhin effektiv.
Registries
Die BaSyx-Registry übertraf die FA³ST- und Tractus-X-Registries und zeigte bessere horizontale Skalierbarkeit bei erhöhten Kernzahlen.
Discovery-Service
Der FA³ST-Service zeigte bessere Skalierbarkeit als BaSyx bei gemischten CRUD-Operationen, wobei der Durchsatz größtenteils linear mit erhöhten Kernen skalierte.
Horizontale Skalierbarkeit
Horizontale Skalierbarkeit umfasst die Verbesserung der Systemleistung durch Hinzufügen weiterer Instanzen. Alle Implementierungen skalierten vergleichbar zu größeren Einzel-Systemen, wenn die Anzahl der Instanzen erhöht wurde, und hielten einen konsistenten Durchsatz aufrecht.
Ergebnisse
Während der FA³ST-Service eine Ausnahme darstellte, indem er Dateien innerhalb seines Systems zwischenspeicherte, entkoppelten andere Implementierungen den persistenten Zustand effektiv, um Konsistenz und Skalierbarkeit über Instanzen hinweg zu gewährleisten. Hinweis: FA³ST-Service hat Skalierbarkeit nicht als primären Fokus, da es für Edge-Geräte konzipiert ist.
| Testfall | CPX31 | 2xCX22 | Δ% | CPX51 | 4xCPX31 | Δ% |
|---|---|---|---|---|---|---|
| BaSyx Submodel | 92.8 | 114.0 | 22.8% | 378.0 | 409.11 | 8.2% |
| BaSyx AAS Discovery | 11.0 | 20.3 | 84.5% | 17.4 | 34.4 | 97.7% |
| BaSyx AAS-Registry | 356.65 | 380.4 | 6.7% | 986.7 | 954.3 | -3.3% |
| FA³ST-Service Submodel | 105.4 | 104.8 | -0.6% | 308.4 | 238.0 | -22.8% |
| FA³ST-Service Discovery | 33.5 | 32.1 | -4.2% | 112.37 | 153.3 | 36.4% |
| FA³ST-Registry | 5.7 | 5.3 | -7.0% | 6.3 | 7.0 | 11.1% |
| Tractus-X AAS-Registry | 57.5 | 40.4 | -29.7% | 47.5 | 50.3 | 5.9% |
Cloud-Umgebungen
Die Cloud-Eignung konzentriert sich auf schnelle Elastizität – wie effizient ein System auf sich ändernde Anforderungen reagiert. Kubernetes erleichtert diese Skalierung, wobei die Bereitschaftszeit ein kritisches Maß ist.
Ergebnisse
FA³ST-Service und Registry hatten die kürzesten Bereitschaftszeiten, was sie gut für dynamische Cloud-Umgebungen geeignet macht. BaSyx-Komponenten zeigten längere Bereitschaftszeiten, was auf einen Optimierungsbedarf hinweist.
| Software | Bereitschaftszeit |
|---|---|
| BaSyx AAS Environment | 9s |
| BaSyx AAS Discovery | 7s |
| BaSyx AAS-Registry | 19s |
| BaSyx Submodel-Registry | 19s |
| FA³ST-Service | 4s |
| FA³ST-Registry | 5s |
| Tractus-X-Registry | 11s |
Zusammenfassend sind die meisten AAS-Implementierungen für die Cloud-Bereitstellung geeignet, insbesondere die FA³ST-Komponenten zeigen aufgrund ihrer effizienten Bereitschaftszeiten vielversprechende Ergebnisse in dynamischen Umgebungen. BaSyx könnte von Leistungsverbesserungen profitieren, möglicherweise durch die Verfeinerung der Spring Boot-Konfigurationen.
Fazit
Um praktischen Erfolg zu gewährleisten, sind skalierbare Lösungen unverzichtbar. Diese Analyse konzentriert sich hauptsächlich auf Eclipse BaSyx, FA³ST und Eclipse Tractus-X SLDT Registry.
Technische Details
Die Skalierbarkeitsanalyse wurde mit dem JavaScript-basierten k6 Lasttest-Tool durchgeführt, das aufgrund seiner Effektivität bei der Bewertung der REST-API-Leistung ausgewählt wurde. k6 ermöglichte die Simulation verschiedener Szenarien, wie unterschiedliche Zahlen von gleichzeitigen Benutzern, Anforderungsraten und Datenmengen. Trotz seiner Stärken stellten die Standardberichterstattung und Datenexportfähigkeiten von k6 Herausforderungen für direkte Vergleichsimplementierungen dar, da das Aggregieren und Serialisieren von Ergebnissen zusätzlichen Aufwand und benutzerdefinierte Tools erforderten.
Um effektivere Vergleichsimplementierungen zu ermöglichen, müssen die Lasttestskripte für eine verbesserte Ergebnisaggregation und Analyse umgestaltet werden. Die aktuellen Testskripte finden Sie in der Mnestix GitHub-Organisation.
Zusammenfassung
Eclipse BaSyx zeichnet sich durch seine breite Funktionalität und regelmäßige Updates aus und zeigt effektive Skalierbarkeit in verschiedenen Anwendungen. Im Gegensatz dazu offenbaren FA³ST und Tractus-X Registry Skalierbarkeitsherausforderungen, insbesondere beim Umgang mit großen Mengen von AAS-Instanzen.
Obwohl die Leistung von BaSyx gut ist, gibt es noch Raum für Verbesserungen, insbesondere bei der AAS-Discovery.
Ausblick
Zukünftige Entwicklungen in der AAS sollten sich auf die Verbesserung der Skalierbarkeit konzentrieren, insbesondere für Anwendungen mit hohen Datenvolumen. Darüber hinaus könnte die Verfeinerung und Erweiterung der AAS-API-Spezifikation die Interoperabilität zwischen verschiedenen Implementierungen verbessern.
Reflexion
Mehrere Implementierungen eines Standards fördern Innovationen und verbessern Spezifikationen, indem sie unterschiedliche Perspektiven einbeziehen und den Benutzern eine reiche Auswahl bieten. Eine erhebliche Differenzierung zwischen den Lösungen ist jedoch erforderlich, um echte Alternativen zu bieten. Während diese Implementierungen interessante Konzepte verfolgen, teilen sie eine gemeinsame AAS-Grundlage. Leistungsunterschiede heben Verbesserungsmöglichkeiten hervor, insbesondere die Optimierung von Datenbankverbindungen als wesentliche Treiber der Skalierbarkeit. Alle Tests wurden ohne die Berücksichtigung einer Zugriffskontrolle durchgeführt.
Autoren
Moritz Hofer
Niklas Sirch