Service und Support | Neoception® Digital Twin Infrastructure

Die Neoception® Digital Twin Infrastructure ist eine fortschrittliche Lösung, die die Erstellung digitaler Zwillinge durch standardisierte Asset Administration Shells (AAS) automatisiert. Diese Technologie ermöglicht es Organisationen, Daten effizient über verschiedene Plattformen hinweg zu verwalten und zu integrieren.

Die Infrastruktur setzt robuste Sicherheitsmaßnahmen ein, darunter mehrstufige Authentifizierung, Datenverschlüsselung und die Einhaltung internationaler Standards. Diese Protokolle stellen sicher, dass sensible Informationen geschützt bleiben und die Integrität der Daten über ihren gesamten Lebenszyklus hinweg gewahrt bleibt.

Die Implementierung erfordert typischerweise eine Bewertung der bestehenden Systeme und Infrastrukturen. Unser Team arbeitet eng mit den Kunden zusammen, um einen nahtlosen Integrationsprozess sicherzustellen, der mit ihren operativen Zielen und technologischen Fähigkeiten übereinstimmt.

Der digitale Zwilling kann als die Aggregation aller AAS mit derselben globalen Asset-ID betrachtet werden, wobei Funktionen wie Web3 für Daten integriert sind, die eine Genehmigung oder einen Nachweis der Richtigkeit erfordern. Beispielsweise betrachten wir zwei AAS für ein einzelnes Asset – eines, das vom Hersteller verwaltet wird, und das andere, das vom Betreiber verwaltet wird. Beide können ein Submodell “aktuelle Position” besitzen, jedoch wird das Submodell des Herstellers nach dem Warenausgang veraltet sein, während das Submodell “aktuelle Position” des Betreibers die genauen Informationen enthält. Die Web3-Technologie kann in Verbindung mit AAS solche Diskrepanzen potenziell lösen. AAS bietet eine umfassende Perspektive auf verschiedene Aspekte eines digitalen Zwillings über den gesamten Lebenszyklus des Assets hinweg.

Nun, nicht unbedingt. Wenn ein Kunde es vorzieht und Submodelle mit eigener Persistenz implementiert, ist das ein valider Ansatz.

In vielen Szenarien ist es jedoch oft vorteilhafter, wenn das AAS Daten “ad-hoc”/”on-demand” aus einem System der Aufzeichnungen (z.B. SAP S/4, MES, Wartungs- oder Anlagenmanagementanwendungen usw.) abruft. In diesem Zusammenhang nutzt der Kunde die “APIs” des AAS. Das AAS, beziehungsweise seine APIs, ermöglichen bzw. fungieren als Proxy für den Zugriff auf das System der Aufzeichnungen.

Alternativ gibt es die Möglichkeit, bestimmte Submodelle und/oder Eigenschaften zu persistieren, während andere auf Abruf abgerufen werden. Die Mechanismen können eingesetzt werden, um sie mit dem entsprechenden System der Aufzeichnungen synchron zu halten.

Ja und nein. Sie können eine XML-Datei mit einer semantischen Definition von strukturierten Elementen verwenden, um ein Asset zu reflektieren, was als “AAS Typ 1” bezeichnet wird. Es gibt jedoch auch “AAS Typ 2”, das eine normalisierte API über einen serviceorientierten Ansatz (REST/JSON) verwendet

Je mehr Submodelle die IDTA (Industrial Digital Twin Association e.V.) standardisiert, desto besser; jedoch sind die standardisierten Submodelle nur eine Säule des gesamten Konzepts, da das AAS-Metamodell und die AAS-APIs unabhängig von standardisierten oder von der IDTA genehmigten Submodellen sind.

Übrigens gibt es eine Parallele zwischen einer OPC UA-Begleit-Spezifikation und einem AAS-IDTA-Submodell: Ähnlich wie bei OPC UA-Begleit-Spezifikationen umfassen AAS-IDTA-Submodelle nicht alle Daten, die eine Maschine bereitstellen kann, und lassen Raum für einen Maschinenbauer, zusätzliche Informationen hinzuzufügen, insbesondere um individuelle Fähigkeiten oder Merkmale hervorzuheben.

Es ist wahrscheinlich, dass spezifische Submodelle entwickelt werden, um mit bestimmten Geschäftssystemen zu interagieren oder in diese zu integrieren, die auch als Systeme von Aufzeichnungen bekannt sind. Zum Beispiel könnte es Submodelle geben, die für eine nahtlose Interaktion mit einem System wie ERP, PLM oder MES, sowie spezifischen Codes für Anlagen, Kunden, Prozesse und Anpassungen entwickelt werden, um sich an die APIs des Legacy-Systems anzupassen.

Der Austausch von Stammdaten zwischen Hersteller und Betreiber oder Engineering-Partner ist ein grundlegender Anwendungsfall, der entscheidend ist, um komplexere Szenarien für digitale Zwillinge zu ermöglichen. In bestimmten Branchen ist die Bearbeitung dieses Aspekts von zentraler Bedeutung, um eine Lücke zu schließen, systematische Fehler zu reduzieren, die manuelle Datenverwaltung zu minimieren und die Gesamtqualität der Stammdaten zu verbessern. Die Interaktion mit AAS, wie das Abrufen der Telefonnummer des letzten Servicetechnikers, der an der Maschine gearbeitet hat, ist ebenso wichtig wie das Einholen oder Pflegen des geplanten Zeitplans (für Wartung oder Produktion) der Maschine in der kommenden Woche.

AAS und seine entsprechenden Submodelle stellen Verbindungen zu Anlageninformationen über Protokolle wie Modbus, MQTT und OPC UA her, wodurch die Darstellung der zuletzt aktualisierten Werte ermöglicht wird, die den aktuellen Zustand einer Maschine widerspiegeln.

Das Konzept des AAS-Registers ist etabliert, um den Endpunkt zum Zugriff auf ein AAS oder seine Submodelle zu bestimmen; daher kann AAS per Definition als ein „verteiltes Dokument“ betrachtet werden. Darüber hinaus dient das AAS als standardisiertes Austauschformat für Asset-Daten und bietet klar definierte Semantiken, die seine Nutzung in dezentralen Umgebungen sowie für verschiedene andere Funktionen fördern.