Eine AASX-Datei bündelt digitale Informationen zu einer Maschine, Komponente oder Anlage, doch ihr Inhalt bleibt ohne passendes Werkzeug oft schwer lesbar. Der AASX Package Explorer hilft dabei, Asset Administration Shells zu öffnen, Submodelle zu prüfen und viele Inhalte direkt zu bearbeiten. Ich zeige, wie das Werkzeug funktioniert, welche Versionen wichtig sind und wann ein Desktop-Programm ausreicht.
Die wichtigsten Punkte für den praktischen Einstieg
- Viewer und Editor für Asset Administration Shells und AASX-Pakete
- AASX-Dateien enthalten Shells, Submodelle und zugehörige Dokumente
- Die aktuelle Entwicklung konzentriert sich auf AAS Version 3
- Für die Desktop-Nutzung stehen Windows-Builds ab Windows 10 bereit
- Vor dem Bearbeiten sollte immer eine Sicherungskopie der Originaldatei erstellt werden
Was der AASX Package Explorer eigentlich öffnet
Der Explorer ist ein grafisches Werkzeug für die Asset Administration Shell, kurz AAS. Diese digitale Verwaltungsschale beschreibt ein reales Asset, etwa einen Motor, einen Roboter, einen Sensor oder eine Produktionslinie, in einer standardisierten Struktur.
Die Datei mit der Endung .aasx ist dabei kein gewöhnliches Dokument wie eine PDF-Datei. Sie funktioniert als Paket, in dem unter anderem AAS-Modelle, Submodelle, Metadaten und verknüpfte Dateien liegen können. Ein Submodell ist ein fachlich abgegrenzter Informationsbereich, beispielsweise für technische Daten, Wartung, Zertifikate oder Energieverbrauch.
Ich finde den Explorer besonders nützlich, weil er die hierarchische Struktur sichtbar macht. Statt XML- oder JSON-Dateien manuell zu durchsuchen, kann ich Shells, Submodelle, Eigenschaften und Referenzen in einer Oberfläche kontrollieren. Das senkt die Einstiegshürde deutlich, ersetzt aber keine Prüfung der fachlichen Datenqualität.
Welche Aufgaben damit möglich sind
- AASX-Pakete öffnen und ihren Inhalt anzeigen
- Asset Administration Shells und Submodelle anlegen oder verändern
- Eigenschaften, Identifikatoren und Referenzen prüfen
- Dokumente oder weitere Dateien im Paket verwalten
- Beispiele für Industrie 4.0 und digitale Zwillinge untersuchen
Das Werkzeug ist damit vor allem für Entwicklung, Schulung, Prototyping und technische Kontrolle gedacht. In einer produktiven Anlage sollte die Bearbeitung zusätzlich durch Rollen, Freigaben und eine Versionsverwaltung abgesichert werden.
Installation und erster Durchlauf
Die veröffentlichten Desktop-Versionen richten sich primär an Windows 10 und neuere Systeme. In der Praxis lade ich eine passende Release-Version herunter, entpacke sie in ein eigenes Verzeichnis und starte die Anwendung über die ausführbare Datei. Eine klassische Installation mit mehreren Assistenten ist nicht zwingend erforderlich.
- Eine aktuelle Release-Version für Windows auswählen.
- Das Archiv in ein lokales Arbeitsverzeichnis entpacken.
- Den Explorer starten und die AASX-Datei über den Öffnen-Dialog laden.
- Die enthaltenen Shells und Submodelle im Strukturbaum kontrollieren.
- Vor Änderungen eine Kopie des Originalpakets anlegen.
Beim ersten Öffnen lohnt sich ein kurzer Rundgang durch die Oberfläche. Ich prüfe zuerst, ob die erwartete AAS vorhanden ist, ob die Identifikatoren plausibel aussehen und ob die Submodelle vollständig geladen werden. Ein leerer oder unvollständiger Baum deutet nicht automatisch auf einen Fehler im Programm hin, sondern kann auch auf ein beschädigtes oder inkompatibles Paket hindeuten.
Wenn das Paket nicht geöffnet wird
Die häufigsten Ursachen sind eine nicht unterstützte AAS-Version, beschädigte Paketdaten oder fehlende Zugriffsrechte. Auch sehr große Pakete mit vielen eingebetteten Dateien können beim Öffnen länger benötigen als einfache Beispieldateien.
Ich gehe dann systematisch vor. Zuerst teste ich eine zweite, bekannte AASX-Datei. Funktioniert diese, liegt das Problem wahrscheinlich im ursprünglichen Paket. Danach prüfe ich, ob die Datei vollständig kopiert wurde und ob die verwendete Programmversion zur Modellversion passt.
AAS und Submodelle sinnvoll bearbeiten
Die Oberfläche ist nicht nur zum Lesen gedacht. Je nach Modell und Version lassen sich Eigenschaften, Einheiten, Werte, Referenzen und Metadaten bearbeiten. Genau hier ist jedoch etwas Disziplin nötig, denn eine formal speicherbare Änderung kann fachlich trotzdem falsch sein.
Ein gutes Beispiel ist ein technischer Messwert. Der Wert allein reicht nicht aus. Auch Einheit, Datentyp, semantische Bedeutung und Zeitbezug müssen stimmen. Eine Drehzahl von „1500“ ist ohne die Einheit Umdrehungen pro Minute oder eine eindeutige Referenz nicht zuverlässig interpretierbar.
Ein sinnvoller Bearbeitungsablauf
- Das betroffene Submodell fachlich identifizieren.
- Den vorhandenen Datentyp und die Einheit prüfen.
- Nur die tatsächlich benötigten Felder ändern.
- Identifikatoren und Referenzen unverändert lassen, sofern kein bewusster Modellwechsel geplant ist.
- Das Paket unter einem neuen Dateinamen speichern.
- Die gespeicherte Datei erneut öffnen und kontrollieren.
Ich speichere Zwischenstände grundsätzlich getrennt, zum Beispiel mit einer Versionsnummer oder einem Datum. Das wirkt zunächst etwas umständlich, spart aber Zeit, wenn eine Änderung später zurückgenommen oder mit einer früheren Variante verglichen werden muss.
Lesen Sie auch: Halbaddierer einfach erklärt - Logik & Funktion verstehen
Typische Fehler beim Editieren
- Einheiten vertauschen, etwa Millimeter und Meter
- Freitext verwenden, obwohl ein definierter Wert oder eine Referenz vorgesehen ist
- Globale Identifikatoren ändern und dadurch Verknüpfungen ungültig machen
- Ein Submodell kopieren, ohne seine semantischen Referenzen zu prüfen
- Das Original überschreiben und dadurch den Ausgangszustand verlieren
Der Explorer unterstützt die Bearbeitung, übernimmt aber nicht automatisch die Verantwortung für den Inhalt. Für verbindliche Freigaben brauche ich deshalb zusätzlich Validierung, fachliche Prüfung und einen klaren Änderungsprozess.
AASX V2 und V3 nicht verwechseln
Ein wichtiger Stolperstein ist die Versionsfrage. Die aktuelle Weiterentwicklung des Eclipse-Projekts konzentriert sich auf AAS Version 3. Ältere AASX-Dateien aus der V2-Welt benötigen je nach Inhalt eine passende ältere Version oder einen dafür vorgesehenen Entwicklungszweig.
Das ist mehr als eine kleine Versionsnummer. Zwischen V2 und V3 haben sich Modellstrukturen, Datentypen und Schnittstellen weiterentwickelt. Ein Paket kann sich zwar öffnen lassen und trotzdem nicht vollständig oder semantisch korrekt dargestellt werden.
| Kriterium | AAS V2 | AAS V3 |
|---|---|---|
| Typischer Einsatz | Bestehende Beispiele und ältere Projekte | Aktuelle Entwicklungs- und Integrationsprojekte |
| Kompatibilität | Benötigt passende ältere Unterstützung | Schwerpunkt der aktuellen Eclipse-Entwicklung |
| Risiko beim Öffnen | V3-Werkzeuge können Inhalte nicht vollständig abbilden | Ältere Werkzeuge können neue Modelle nicht korrekt verstehen |
| Empfehlung | Version des Ursprungsprojekts beibehalten | Bei neuen Projekten aktuelle IDTA-Spezifikationen prüfen |
Mein Rat ist einfach: Vor dem Import kläre ich zuerst, nach welcher Spezifikation das Paket erstellt wurde. Bei einem wichtigen Projekt teste ich die Datei mit einem kleinen Beispieldatensatz, bevor ich produktive AASX-Pakete konvertiere oder überschreibe.
Desktop-Werkzeug, Server und Alternativen im Vergleich
Der AASX Package Explorer passt gut zu einzelnen Dateien und manuellen Prüfungen. Sobald mehrere Abteilungen, Maschinen oder Anwendungen gleichzeitig auf AAS-Daten zugreifen müssen, wird ein zentraler Server oder eine API meist sinnvoller.
| Lösung | Stärke | Grenze | Geeignet für |
|---|---|---|---|
| Desktop-Explorer | Schnelles Öffnen und Bearbeiten | Keine zentrale Mehrbenutzerverwaltung | Analyse, Tests, Einzeldateien |
| AASX-Server | Mehrere Pakete zentral bereitstellen | Höherer Einrichtungs- und Betriebsaufwand | Teams und Integrationsprojekte |
| AAS-Repository | Strukturierter Zugriff über Schnittstellen | Technisches Know-how und Infrastruktur nötig | Produktive Anwendungen |
| Webbasierter Viewer | Kein lokaler Desktop-Start erforderlich | Funktionen hängen vom jeweiligen Anbieter ab | Gemeinsame Ansicht und Demonstrationen |
Für eine Schulung oder die Kontrolle eines Lieferantenpakets würde ich mit dem Desktop-Explorer beginnen. Für eine laufende Produktion mit automatischen Aktualisierungen, Berechtigungen und Schnittstellen reicht ein lokaler Editor dagegen selten aus.
Auch ein internes REST- oder OPC-UA-Szenario sollte nicht vorschnell mit einer vollständigen Produktionsplattform gleichgesetzt werden. Entscheidend sind Authentifizierung, Rechtekonzept, Protokollierung und Datenhoheit. Fehlen diese Punkte, bleibt die Lösung eher ein technischer Demonstrator als ein belastbarer Betriebsdienst.
Eine kurze Entscheidungshilfe für die Praxis
Wer nur wissen möchte, was in einer AASX-Datei steckt, braucht in der Regel keine komplexe Infrastruktur. Der Explorer ist dafür schnell verständlich und besonders hilfreich, wenn technische Teams Modelle gemeinsam betrachten oder erste eigene Shells erstellen.
Für die tägliche Arbeit empfehle ich drei Prüfungen. Erstens muss die Modellversion zum Werkzeug passen. Zweitens sollten Identifikatoren, Einheiten und Referenzen fachlich geprüft werden. Drittens gehört jede Änderung in einen nachvollziehbaren Prozess mit Sicherungskopie und klarer Benennung.
Damit wird aus einem einfachen Dateibetrachter ein nützliches Arbeitsmittel für digitale Zwillinge. Wer später viele AAS zentral verwalten, automatisiert auslesen oder in bestehende Industrie-4.0-Systeme integrieren möchte, kann auf dieser Grundlage gezielt zu Server-, Repository- oder API-Lösungen weitergehen.
