Einfach Komplex – Der Software- und IT-Podcast· Folge 92

Asset Administration Shell (AAS) mit Aaron Zielstorff vom Fraunhofer IESE #92

Dienstag, 9. September 2025 · 1 h 05

MP3

Shownotes

Wie können in der Industrie 4.0 Maschinen, Bauteile und Anlagen verschiedenster Hersteller nahtlos miteinander kommunizieren? Um diese zentrale Frage zu klären, sprechen wir mit Aaron Zielstorff vom Fraunhofer-Institut für Experimentelles Software Engineering (IESE).
Die Antwort liegt in der Asset Administration Shell (AAS), einem standardisierten Digitalen Zwilling für jede Art von industriellem Gut ("Asset"). Man kann sie sich als eine digitale Visitenkarte für jede Komponente vorstellen, die über eine standardisierte Schnittstelle (API) nicht nur ihre Stammdaten (z.B. das Digitale Typenschild) preisgibt, sondern auch ihre Fähigkeiten, Anleitungen oder Echtzeit-Daten.
Das große Ziel dahinter: Echte Interoperabilität und das Versprechen von "Plug & Produce", bei dem neue Komponenten einfach ins System integriert werden und sofort funktionieren. Aaron erklärt den aktuellen Stand des Standards, die Rolle der Industrial Digital Twin Association (IDTA) und wie diese Technologie die Grundlage für Konzepte wie den digitalen Batterie- oder Produktpass bildet.
Links zur Folge
Fraunhofer IESE iese.fraunhofer.de
Aaron auf LinkedIn linkedin.com/in/aaron-zielstorff
Eclipse BaSyx eclipse.dev/basyx
------
Einfach Komplex ist ein Podcast von Heisenware.
Alle Infos und Kontakte findest du
unter heisenware.com?utm_source=podcast&utm_medi…
und im Linktree ⁠⁠⁠linktr.ee/heisenware (linktr.ee/heisenware)
------
Aaron, Burkhard und Gerrit sprechen heute über:
() Intro Aaron & AAS
() Submodel & Submodel Templates
() Definition eines Assets
() Technologie und Implementierungen
() OpenSource Implementierung Eclipse BaSyx™
() AAS als Unternehmen einführen
() Bridging IT and OT
() Mehrwerte und Erfolgsgeschichten
() Angebot Fraunhofer IESE

Transkriptvom Podcast bereitgestellt · Zeitmarken springen hin

Moin, zu einfach komplex mit Euren Hosts Burkhard und Gerrit und heute wieder mit einem Gast und zwar vom Fraunhofer IESE, der Aaron Zielsdorf zum Thema Asset Administration Child Hallo Aaron. Hallo zusammen. Cool, dass du da bist. Magst du dich kurz vorstellen? Für alle Hörerinnen und Hörer, damit Sie wissen, wer du bist?

Und ja, was das FRAUNHOFER IE so macht? Ja klar, sehr gerne und vielen Dank für die Einladung zu Eurem Podcast. Genau. Also mein Name ist Aaron Zielstorf und ich bin Wissenschaftler am Fraunhofer I ESE. Unser Institut beschäftigt sich mit dem effizienten Software Engineering oder ehemals und da auch noch der ursprüngliche Institutskürzel her dem experimentellen Software Engineering. Das wird aber Tatsache häufig falsch verstanden, also es geht nicht darum, dass wir als Experimente im Software Engineering durchführen.

Sondern es geht vielmehr darum, dass wir angewandte Forschung betreiben und das Halt vor allem im Informatikkontext. Genau, ich bin in der Abteilung Digital Twin Engineering tätig, und das passt, glaube ich, auch ganz gut zu dem Thema, weil die AES oder Langen Asset Administration Shell ist nämlich der Standard für digitale Zwillinge und bei mir in der Abteilung. Bin ich letztendlich so eine Art Experte rund um das Thema und bin insbesondere auch Product Owner für eine Implementierung der AES?

Cool. Und wie bist du dahin gekommen? Magst du noch ein bisschen was zu deinem, zu deinem Background erzählen? Ja, sehr gerne. Also ich habe letztendlich angefangen mit dem Thema schon zu meiner Studienzeit, ich habe Elektrotechnik studiert mit vor allem Schwerpunkt Automatisierungstechnik. Also ich komme eher so aus der SPS Welt, industrielle Kommunikation und wir hatten damals ein Forschungsprojekt zusammen mit dem Fraunhofer ESE und dadurch auch der Kontakt dann, das war das Basisforschungsprojekt und in diesem Forschungsprojekt ging es letztendlich genau dadrum eine Technologie zu entwickeln für die AS für den digitalen Zwilling und diese dann Standard fertig zu machen und auszurollen. In die Industrie genau und im

Studium hab ich dann letztendlich meine Bachelor thesis da zu dem Thema auch geschrieben. Meine Master Thesis und bin schon seit einigen Jahren in der Entwicklung mit dabei an Technologien rund um die AES. Sauber OK, absoluter Experte hier. Was erwartet uns denn heute in der Folge? Klar, AES Digital Twins. Vielleicht kannst du es einfach noch mal so ein bisschen in Kontext setzen.

Also für wen ist das besonders relevant und und wo wird es auch angewendet? Ja, also digitale Zwillinge. Ich denke, viele haben es schon gehört, das ist ja ein absolutes Hypthema seit den letzten, ich sag mal vielleicht 45 Jahren schon und ursprünglich kommt das ganze aus dem Kontext Industrie 40 und auch die AES ist ursprünglich dort angesiedelt gewesen. Heutzutage wird die Technologie aber Tatsache nicht nur im industriellen Kontext eingesetzt, sondern domänenübergreifend.

Und das ist auch ein ganz, ganz riesiger Vorteil und auch der Grund meiner Meinung nach, warum die AAS mittlerweile in Europa nen guten Bekanntheitsgrad erreicht hat haben und auch stetig die Community am wachsen ist. Mhm. Und AAS ist eine Technologie, sagst du ja, es ist kein Konzept oder sowas, sondern wirklich anfassbare. In Anführungszeichen anfassbare Technologie. Ja, ja, definitiv.

Also klar, wir sind mal bei einem Konzept gestartet. Ursprünglich geht das ganze Thema aus der Plattform Industrie 40 in Deutschland hervor, da hatte man vor mittlerweile es sind bestimmt schon 10 Jahre angefangen, letztendlich an dem Referenzarchitekturmodell für die Industrie 40 zu arbeiten und als Teil davon hat man sich mit digitalen Zwillingen beschäftigt und eine Technologie gesucht.

Die letztendlich eine ganze Reihe an Anforderungen erfüllt, was die Digitalisierung angeht. Und daraus ist dann die AS entsprungen und ja, letztendlich, heutzutage ist es ein Standard auf der einen Seite und auf der anderen Seite eine fertig einsetzbare Technologie, die stetig erwachsen muss. OK, cool, dann wissen wir mal, woher es kommt, um was es sich grob handelt, aber dann gerne mal im Detail.

Was was bedeutet das eigentlich? Also, was steckt denn jetzt genau dahinter, wenn man von der Asset Administration Shell spricht? Ja, also die LS oder Langen Asset Administration Shell. Letztendlich ist ein digitaler Zwilling eines Assets, was in der Realität existieren kann, also ein Asset wäre für mich zum Beispiel sowas wie ein Auto oder eine Schraube. Es kann aber Tatsache auch.

Es muss nicht sein. Soll ich ein physisches Asset sein, sondern es kann auch ein logisches Asset sein, also ein Stück Software oder eine PDF, die ich habe, oder auch ein KI Modell, das das kann alles Asset sein und die Definition des Assets ist letztendlich, dass es einen ein Gegenstand ist, der für ein Unternehmen von Wert ist.

Und genau eben dieses Asset wollen wir digital repräsentieren mit unserem digitalen Zwilling. Und genau dafür liefert die AES den Standard, um genau das zu tun. Und jetzt stellt sich natürlich die Frage, warum brauchen wir dann überhaupt digitale Zwillinge für unsere Assets und das ist letztendlich die entscheidende Frage und auch der Knackpunkt, warum die AES mittlerweile in der Industrie ja ganz im Munde ist.

Und zwar? Existieren gleich mehrere Probleme, so wie wir sie oder wie wir aus der Industrie 3.0 nennen, es jetzt einfach mal kennen. Und zwar haben wir ja all unsere Maschinen, unsere Anlagen automatisieren können, aber wir haben ganz, ganz viele proprietäre Lösungen auf dem Markt, also wir haben verschiedenste SPS Hersteller, Wir haben verschiedenste Softwarelösungen, also ich sag einfach mal ein paar Codesys oder das tia Portal. Wir haben verschiedenste Kommunikationsprotokolle und mittlerweile auch sehr, sehr komplexe Systeme in der Industrie und damit ist es unglaublich schwierig geworden, Bestandsanlagen zu erweitern, Informationen digital einzusammeln, eine Interoperabilität zwischen mehreren Maschinen oder

Komponenten herzustellen und allgemein überhaupt auch Herr der Komplexität zu werden und. Die notwendigen Informationen, die ich letztendlich in dem Lebenszyklus meines Assets immer wieder brauche und auch drauf zugreifen muss, an einem Ort zu haben und letztendlich mit diesen. Alten Paradigmen, so wie wir sie aus der Industrie 3.0 noch kennen, ist es so gut wie unmöglich, zum Beispiel Plug and Play oder Plug and produce umzusetzen.

Und genau an dem Punkt setzt die AES an, weil wir letztendlich sowohl für das Datenmodell, was wir zugrunde legen, zu unserem digitalen Zwilling einen Standard haben, als auch für die Schnittstellen. Und letztendlich ermöglicht es uns, das auf der einen Seite Assets anzubinden, an unseren digitalen Zwilling, sodass wir letztendlich Informationen austauschen können. Asset AS.

Dass es dann weiterhin mit den proprietären Protokollen, die wir aus der Industrie kennen, aber letztendlich in Richtung der digitalen Welt, haben wir eine einheitliche Schnittstelle, so dass wir mit jedem Asset, ich sag jetzt mal umgangssprachlich reden können und letztendlich auch eine Schnittstelle haben, um mehrere Assets zusammenzuführen zu einem großen Composite. Moin Moin an alle, ich hab noch gar nichts gesagt heute. Ich fang mal an, jetzt wird es spannend für mich. Wir haben n bisschen technisch geredet, Asset Administration Shell, ich versuch mal gerade noch mal n Bild aufzumachen. Also du hast gesagt, du hast ziemlich krasse Sachen gesagt, du hast gesagt ne Schraube und n

Auto kann Asset also das ist ja schon von der Komplexität her schon mal n ordentlicher Schwung. Ja für mich sind ja auch schon mal schrauben in einem Auto und so weiter da stell ich aber gleich ne Frage zu, also die Shell als Schale im Deutschen kann man sich jetzt vorstellen, ich hab ne Schraube oder ne n Auto oder ne Maschine oder was auch wie immer n kleinen Motor oder Irgendsowas.

Und behandel es technisch digital, weil es ja ein, also ein digitale Implementierung ist. Nicht nur konzeptpapier als hätte ich nen Adapter drauf, also irgendwie ne Art softwareadapter irgendwo werde ich was darüber erfahren können, dann in meinem weiter oben im Nord nördlichen System sagen wir mal wenn man Süden sagt kleine Details und nach Norden sagt komplexere Systeme und du hast gesagt es ist n Standard so jetzt muss ich ja dann und jetzt kommt meine technische Frage. Das heißt sowohl ne Schraube als auch n Auto ist standardmäßig beschrieben und wenn ich jetzt sage Standard, dann stell ich mir sowas vor wie bestimmte Schlüssel und Wertepaare. Also sowas wie nen Name, nen Typ, ne Kategorie oder irgendsowas, was quasi in einem

Schema sogar festgehalten ist. Wie ich erstmal jedes Asset beschreiben muss magst magst du da kurz einmal sogar schon gleich mal technisch irgendwie reingreifen ist es so hab ich da recht. Und welche Technologie nimmt man da? Ja, auf jeden Fall. Also dem, der AS zugrunde liegend ist das sogenannte AS Metamodell und dieses Metamodell definiert letztendlich genau dieses Schema, wovon du geredet hast.

Also letztendlich ein Set von Attributen, die immer wieder verwendet werden, um. Assets digital zu beschreiben und diese Attribute nennen wir in der AS Welt submodel Elements und ich nenne einfach mal ein paar Beispiele, was es dort so gibt. Wir haben als simpelsten Typ von submodel Element das Property, das ist letztendlich wie eine Variable, die hat einen Datentyp und die hat einen Wert, also beispielsweise könnte das ein integer wert sein und die Zahl 6 sag ich einfach mal. Wir haben aber auch deutlich komplexere submodel Elements, aus dem eine AES aufgebaut sein kann. Ich nenne einfach mal noch ein paar weitere Beispiele. Wir haben ein file submodel Element, damit können wir Dateien mit Einbetten in die

AES, wir haben eine submodel Element Collection, das ist die Möglichkeit submodel Elements zu verschachteln, das heißt ich könnte. Beliebig tief eine Struktur aufbauen, eine Baumstruktur, um weitere Informationen zu untergliedern oder generell zu gliedern. Wir haben Referenz Elemente und relationship Elemente, um Beziehungen herzustellen zwischen Attributen als Teil unserer AES und letztendlich mit all diesen verschiedenen Typen von submodel Elements, die. In sich selbst auch wieder standardisiert sind, können wir dann generisch eine Baumstruktur aufbauen, die alle relevanten Informationen enthält zu unserem Asset und auf der obersten Ebene haben wir die sogenannten Submodels und ein Submodel ist letztendlich eine Beschreibung

eines einer spezifischen Eigenschaft oder eines spezifischen Use Cases eines Assets, und um das besser zu verstehen, hier auch ein Beispiel. Ein ein standardisiertes Submodel oder zu Deutsch Time Modell ist das Digital Name Plate oder das digitale Typenschild. Und das kann man sich so ähnlich vorstellen wie das Typenschild, was man zum Beispiel an einem Motor findet und dort an an solch einem Typenschild gibt es ja ein bestimmtes Set an Informationen, was man immer wieder findet, also zum Beispiel die Drehzahl, das Moment oder die Leistung, die der Motor hat. Und genau auf diese Art und Weise definiert das Submodel ein bestimmtes Set an Eigenschaften, die in diesem digitalen Typenschild vorhanden sein

müssen, also zum Beispiel der Herstellername oder der Link zu dem Asset. Oder wann wurde das Asset hergestellt? Und noch viele, viele weitere Informationen und um das Teilmodell. Aufzubauen werden dann auch wieder die Submodel Elements verwendet, also zum Beispiel der Herstellername. Wäre dann ein Property submodel Element mit einem String drin.

Du sagst ein Submodel was es gibt, ist zum Beispiel das digitale Typenschild. Das Nameblade kann ich mir submodels frei erfinden und sage ich mein nehme das irgendwie die das digitale. Pflanzenblatt oder irgend so was. Ja, und das damit beschreibe ich irgendwie, was weiß ich oder gibt es in dem Standard festgelegte Submodels, also Kategorien, weil bis jetzt hat sich so angehört, das ist ich hab ja bin ja dann sehr frei, ne, ich hab ja gefragt gibt es n Schema und so weiter du hast gesagt ja gibt es aber das Schema sind quasi ich sag es mal flach so im Prinzip die Datentypen mit denen wir so umgehen ne das ist ja quasi das niedrigste Level was ich mir als Schema vorstellen kann ne ich sagen kann.

Ich kann ne beliebige Property nehmen, die kann beliebigen Namen haben, beliebigen Datentyp, zum Beispiel Integer, String, bolin oder irgendwas. Dann bin ich ja, dann bin ich ja quasi da, wo ich im Jason zum Beispiel bin und und sage, OK mein mein Schema ist halt, es muss irgendwie in einem Jason Ausdrückbar sein, da kann ich zum Beispiel auch NL reinmachen von von Sachen und so weiter ist das so und hab ich da nicht n riesigen Zoo an an doch ziemlich frei konfigurierbaren Shells.

Ja, absolut. Also grundsätzlich die das Metamodell der AES. Wird in der Regel auch als JSON oder alternativ als XML oder ADF dargestellt. Und grundsätzlich ist es erstmal schon noch eine Einschränkung gegenüber einem ganz generischen json, aber es ist trotzdem noch sehr generisch, so dass man letztendlich jeden beliebigen Use Case trotzdem noch abbilden könnte.

Nichtsdestotrotz gibt es aber auch eine Reihe an standardisierten Submodels. Es ist nicht verpflichtend, diese einzusetzen, erstmal per se, aber es macht natürlich Sinn, wenn ein Standard für ID USE Case existiert oder ein Submodel und diese Standards nennen wir dann submodel Templates, diese auch einzusetzen und.

Wie gesagt, das eine Beispiel wäre das digitale Typenschild, aber es gibt noch eine ganze Reihe weiterer standardisierter Submodel Templates. Ich glaube, es sind mittlerweile an die 80 knapp unter 90 und die werden stetig erweitert, und zwar als Teil der Industrial Digital Twin Association, das ist letztendlich eine Organisation, da kann jedes Unternehmen beitreten, was Interesse an dem Standard hat und. Und in Arbeitsgruppen dann weitere Submodel Templates entwickeln oder an dem existierenden Standard weiter arbeiten, weiter feilen an neuen Versionen letztendlich arbeiten also, um die Frage noch mal als Gesamtes zu beantworten. Ja, es ist prinzipiell sehr generisch und es erlaubt letztendlich in viele Richtungen

zu gehen. Aber nichtsdestotrotz haben wir eine Reihe an standardisierten Templates, die verwendet werden sollten. Ist jetzt das Digital Nameplate oder digitale Typenschild also ein Use Case? Korrekt, ja. Und der Use Case wäre also was ist der Nutzen? Ich kann Dinge einfacher identifizieren und gewisse Informationen darüber erfassen.

Korrekt also. Das das Ganze ist letztendlich, wie wenn wir einen QR Code oder einen Barcode auf einem Produkt haben, was wir im Supermarkt kaufen, dann verbirgt sich dahinter ja auch ein Set an Informationen und das sind letztendlich, ich nenn es jetzt mal die Minimalinformationen, die für uns von einem Asset wichtig sind und typischerweise hat man sowas in der Vergangenheit in Papierform wiedergefunden. Ich sag mal, das hätte jetzt auch ein Lieferschein sein können zu einem Produkt was ich wo gekauft hab beim Unternehmen und nun ist es eben ein QR Code, im Zweifelsfall der auf einem Asset Draufgedruckt ist oder ein kleiner AFID Chip, der irgendwie mit eingesetzt ist.

Und den scanne ich dann ein und dann öffnet sich ne Website und dort sehe ich die AS mit all den relevanten Informationen. OK, das Asset kann sagen, was es ist oder kann gewisse. Metainformationen über sich preisgeben über so n ganz nameplate was ist denn noch n anderer Use Case um das mal so in oder n anderes Beispiel für ein Submodel n submodel Template dann um das mal so n bisschen in Kontext zu setzen was es eigentlich noch geben könnte. Mhm ja, also wir haben letztendlich ne ganze Reihe an Templates, einige eher mit statischen Daten, zum Beispiel das Nameplate würde man jetzt auch nicht typischerweise irgendwie als digitalen Zwilling bezeichnen, weil es findet ja keinen.

Live Datenaustausch statt weder in die eine Richtung noch in die andere Richtung. Aber es gibt auch submodel Templates, die genau das als Ziel haben. Ein Beispiel wäre das sogenannte Control Component. Das ist ein Teilmodell, was definiert, wie letztendlich die Schnittstelle zu einem Asset aussieht und wie man zum Beispiel Zustands Transitionen triggern kann an einem Asset.

Ich mach auch hier mal ein Beispiel, ich denke für einige dürfte der Begriff Pack ML ein bekannt sein, das kommt ja ursprünglich aus. Dem Verpackungsbereich wurde aber jetzt auch letztendlich in der Automatisierungstechnik schon übertragen auf ganz, ganz viele andere Anwendungsfälle und die Pack ML ist letztendlich ein ein Standard für Zustandsautomaten. Das heißt, ich könnte auf meiner SPS mit meinem Structure textprogramm oder von mir aus auch ledderlogic oder was auch immer ich verwende, eine Zustandsmaschine implementieren. Und habe dann Zustandsvariablen und Transitionsvariablen, auf die ich zugreifen kann und gebe ich diese Variablen jetzt frei aus meiner SPS über ein Protokoll, sei es jetzt MQTT oder OPCOA oder Modbus, dann

könnte mein Control component, also mein Teilmodell als Teil meiner AES über genau diese Schnittstellen. Mit der Zustandsmaschine reden und dann zustandstransitionen auch triggern. Das heißt, ich könnte dann aus einer digitalen Oberfläche ähnlich wie bei Skada und HMI Themen dann, ich sag mal auf einem Touchpanel oder auf einem Display vom Smartphone dann die Maschine steuern und deswegen auch der Name Control Component. Und letztendlich das Teil Modell ist dann die digitale Repräsentation der Zustandsmaschine in einem digitalen Zwilling und damit das Ganze funktionieren kann, muss ich natürlich beidseitig kommunizieren. Also hier reden wir dann wirklich von einem echten digitalen Zwilling.

Also kann man sagen, haben wir 22 Sorten von Assets im Moment auf dem Tisch liegen. Wir haben die Assets, die sind komplett statisch, sowas wie ne Schraube, die einfach auch gar keine eigene Smartheit hat. Keine. Da ist kein Mikrocontroller drin und nichts. Es ist halt einfach Licht halt da und wird von der Shell quasi nur mit aufgenommen ins System aller Assets und beschrieben.

Und du sagst jetzt als zweites Beispiel, dann hast du nen Asset was zum Beispiel ne SPS selber ist oder ich nehme noch mal n anderes Beispiel halt nen Motor oder irgendwas der halt über ne SPS gesteuert wird schon klar und dann wär dann quasi die SPS oder der Motor mit der SPS Mein Asset und auf einmal ist dieses Asset aber clever und ist nicht mehr statisch sondern je nachdem. Was es halt gerade tut.

Es ist es ist Pferd, es ist auf Standby, es ist auf Error und so weiter und und diese Zustandsänderungen wollen jetzt natürlich übertragen werden in die Shell dieses Assets. Ganz genau so ist. Es soweit, so klar, dann bräuchte ich aber in der, da wird es ja schon wieder n bisschen komplizierter, weil wenn du jetzt was du gesagt hast, ist ja schon n ordentlicher Schwung nach vorne.

Ich geb dem Asset irgendwelche Kommandos quasi ja, also. Zustand wechselt bitte von stehen nach Fahren oder irgend so was, da brauch ich ja schon wieder ganz viel Feedback und so weiter da muss ich ja richtige Protokolle beschreiben, weil das ist ja in der Informatik klingt so einfach auf der Tonspur, aber in Wirklichkeit ist es nicht ja weil ich kann ja sagen fahren und das Ding sagt mir ich fahr nicht weil ich hab error ich hab keinen Strom, ich fahr schon was weiß ich ja und all das muss ich ja wieder reflektieren, auch in meine Schale, ob denn jetzt dieser Befehl überhaupt erfolgreich war und so, ja.

Absolut. Und genau das passiert auch also. So wie wir es jetzt letztendlich sprachlich erstmal formulieren, klingt es wirklich sehr leicht. Aber in der in der Praxis ist es ein ein unglaublich komplexer Anwendungsfall. Genau, und das Teilmodell probiert Tatsache auch genau diese Informationen mit abzubilden. Also es gibt dort eine Collection, die sich nur damit beschäftigt, errormeldungen abzubilden und da kann ich sogar vordefinieren, welche Zustände oder welche. Errorzustände ich erreichen kann, also es ist nicht nur relevant, letztendlich den Idealweg zu modellieren, sondern ich muss natürlich auch den Weg modellieren, was passiert, wenn mal was nicht funktioniert und das kann ja im simpelsten Fall auch einfach sein.

Ja, mein Asset ist gar nicht erreichbar, Stromausfall oder die Verbindung ist gekappt und genau diese Fälle müssen auch berücksichtigt werden und. Auch die Integration der Assets in den digitalen Zwillingen in die Air ist, ist keine leichte Aufgabe, weil wir brauchen uns ja nur einmal die Welt der verschiedenen Protokolle anzugucken.

Also da können wir wahrscheinlich gemeinsam 5060 70 Protokolle aufzählen, am Ende sicherlich sind davon einige häufiger eingesetzt, aber all diese Protokolle auch zu unterstützen, ist keine leichte Aufgabe, aber. Da ergibt sich meiner Meinung nach trotzdem auch die Stärke der AES draus, weil wir es eben nur einmal umsetzen müssen.

Das heißt, wenn wir ein Protokoll unterstützen, dann können wir das immer wieder verwenden und letztendlich nach Nordseitig hin, also wir nennen das immer in die Connected World oder in die digitale Welt rein kommuniziert haben wir ja dann die einheitliche Schnittstelle, also dahingehend ist es dann ja leichter. Ein kurzer Hinweis in eigener Sache. Kennst du das auch, dass von neuer Software zur Digitalisierung der Produktion zurückgeschreckt wird? Ihr seid gefangen zwischen starrer, veralteter Standardsoftware und endlosen Individual Entwicklungsprojekten unsere Mission bei Heisenware ist es, das zu beenden mit unserem App Baukasten geben wir dir die Möglichkeit, maßgeschneiderte Software für

den Shopfloor schnell und ohne Code zu erstellen Denk an Maschinendatenerfassung moderne Visualisierungen für die Produktionsleiter. Oder eine mobile App zur Buchung von Zeiten direkt am Arbeitsplatz. Und das beste, du kannst deine Lösung ganz einfach ohne it Aufwand selbst betreiben. Kurz gesagt, günstiger als eine externe Entwicklung unendlich passender als Software von der Stange. Weitere Infos und eine kostenlose 30 Tage Testphase findest du auf heisenware.com.

Einfach komplex als Träumhörer bieten wir dir im Anschluss 20% Rabatt auf alle Pakete im ersten Jahr und jetzt viel Spaß mit der weiteren Folge. Ich bringe das noch mal anders auf die Tonspur. Das ist nämlich auch ein Pattern in der Softwarearchitektur, das nennt sich Adapter Pattern, es ist ja immer die Frage, wenn wenn du einen, also was, was ist das Grundproblem, mal ganz abstrakt gesprochen, wir haben einen heterogenen Zoo an Gedöns, was wir irgendwie aber generisch und allgemein übersehen wollen, mit bedienen wollen, verstehen wollen, dann kann ich das, dann kann ich quasi, also muss ich einen Standard etablieren, womit alles funktioniert, ja, und wenn ich den ganz früh etabliere und so verstehe ich die Asset

Administration Shell. Also ganz nah an dem Ding, was halt irgendwie dazu ist. Ja, dann pack ich quasi in ne ne Schale drauf was n Adapter ist und die die Umsetzung auf die Generizität auf den Standard passiert jetzt quasi schon in der Schale. Ja ich nehm mal nander ich nehm mal n Bild vom frühstücksei, ich weiß nicht ob ihr habt, kennt ihr diese Eierwärmer so hat die Oma manchmal noch so gestrickt so die gibt es gibt es ja in allen, gibt es auch kunstvoll irgendsowas aber dann wenn das Frühstücksei noch n bisschen warm bleiben soll das gekocht hat, dann stülp ich da was drüber ja also wenn das Ei meine Asset ist.

Und der Drüberstülper jetzt die Shell ist, dann ist der der komplizierte Prozess passiert, dann beim Überstülpen. Tatsächlich sitzt es erstmal auf dem Ei, fertig, ja weil dann mit der mit dem Eierwärmer können alle sprechen nach Norden ja, aber dazu hab ich natürlich auch noch n paar fragen ich ich akzeptiere mal kurz, dass wir für alle möglichen verschiedenen Assets natürlich den Weg quasi in dem, also in der Innenseite von dem Eierwärmer zum zum Ei hin, da steckt ganz schön gehirnschmalz und da muss unterschiedliche Sachen gemacht werden. Von außen her sehen die halt alle dann gleich aus. Jetzt aber trotzdem noch mal ne Frage und dann hab ich ja aber nach Norden in Deine Digital Connected World wie du es gesagt hast.

Ja trotzdem jetzt also einen ganzen großen Teich von diesen Shells so und da ist das Problem ja noch nicht zu Ende. Jetzt würd ich gern noch mal verstehen, weil dann hab ich noch keinen Mehrwert, ich muss ja jetzt mit diesen Shells sprechen und diese Shells an sich haben wir wahrscheinlich auch noch mal ne verbaumte Struktur, weil wenn du sagst es gibt halt Assets die sind halt irgendwie auf der Komplexität einer Schraube oder eines Motors.

Da kann ich halt als nächstes sagen, ja, aber der aber, der der Kollege XY, der versteht halt die ganze CNC Maschine als Asset und die hat halt irgendwie 730 Motoren drin und weiß nicht wieviel Sensoren und so weiter wo der nächste der PLC Entwickler sagt Halt nee die PLC Maschine ist doch kein Asset sind halt meine Motoren und so weiter weißt du was ich meine?

Also gerechtfertigt verschiedene Perspektiven auf die Komplexität was jetzt n Asset ist. Und garantiert hat das ja auch in dem Standardeinzug gehalten und das kann ich wahrscheinlich irgendwie ausdrücken. Magst du dazu auch irgendwie noch mal was? Sagen ja, absolut. Also genau das ist Tatsache, Teil auch des Standards geworden, dafür gibt es auch ein eigenes submodel Element, damit das Ganze abgebildet werden kann, das ist das sogenannte Entity submodel Element und über das Entity habe ich die Möglichkeit über eine globale ID ein weiteres Asset zu referenzieren. Und da das Entity selbst ein submodel Element ist, als Teil eines Submodels, was wieder Teil einer AES ist, habe ich dann die Möglichkeit in einer AES weitere

Shells letztendlich mit einzubauen. Und dann gibt es standardisierte Teilmodelle hier auch wieder, zum Beispiel Builds of Materials oder Builds of processes. Wo ich dann die Möglichkeit habe, eine Baumstruktur auch von Assets aufzubauen und nicht nur von submodel Elements. Das heißt, ich kann 2 Assets 3 Assets beliebig kombinieren, wieder zu einem zum nächstgrößeren Asset letztendlich und da auch eine hierarchische Struktur wieder aufbauen. Das heißt, für das eine Unternehmen ist es vielleicht nur interessant, die CNC Maschine als ein gesamtes Asset zu verstehen, weil sie es so bei einem anderen Unternehmen gekauft haben.

Aber das Unternehmen was die CNC Maschine selbst hergestellt hat, für die sind die Assets ja wiederum dann die einzelnen Bestandteile, aus der die CNC Maschine zusammengesetzt ist. Also sagen wir mal die Motoren und das Gehäuse. Und dann irgendjemand hat der den Motor auch hergestellt und für die geht es dann vielleicht noch mal eine Ebene tiefer.

Also da ist dann die einzelne Schraube relevant oder der Schleifer oder die Verkabelung und genau das kann auch in der AS abgebildet werden. So, und jetzt Butter bei die Fische, was ist denn da die Shell? Technisch ist es ein HTTP server oder also wir brauchen ja jetzt eine Technologie die ausgesucht hat schon vor längerer Zeit.

Die so gegenwärtig und allgemein und generisch ist, dass sie erstens noch die nächsten 10 Jahre hält, zweitens irgendwie von allen Siemens philipsons und was es alles gibt, ABB und so weiter gesagt wird. OK, können wir machen, ohne dass wir irgendwie ne Krise kriegen und irgendwas nehmen müssen, was wir nicht kennen. Also was ist es jetzt technisch und genau da bin ich jetzt gespannt irgendwie.

Und wie läuft es so zusammen? Unterschieden wird Tatsache erstmal zwischen 3 Typen von Shells. Und im simpelsten Fall kann Shell einfach ein Dokument sein und der Standard definiert das Teil 5 der Spezifikation und die dieser Teil der Spezifikation beschäftigt sich mit dem sogenannten ASX Format und das ist ein eigenes Dateiformat, was letztendlich in sich drin JSON und xml Dateien enthalten kann.

Das heißt die LS selbst ist erstmal. Nicht mehr als eine JSON Datei und das ASX file ist eigentlich nur eine zip Datei mit einer besonderen Dateiendung die dann noch angehängte Dateien beinhalten kann. Also man stelle sich vor ich habe ein file submodel Element und habe da zum Beispiel das Firmenlogo mit eingebettet, dann ist das natürlich nicht Teil des Jsons selbst, aber es kann referenziert werden, dann über einen Pfad aus dem JSON.

Und das ist das, was wir als Typ 1 Verwaltungsschale oder Typ 1 AES bezeichnen. Das ist der simpelste Fall und diese Dateien kann ich dann natürlich austauschen. Ich kann sie per Mail hin und her senden oder per USB Stick, aber das ist natürlich witzlos, also skalieren kann man damit erstmal noch nicht so wirklich und spannend wird es dann ab den Typ 2 verwaltungsschalen und da. Haben wir letztendlich verschiedene Server Implementierungen, also letztendlich AP is und diese AP is wiederum sind auch standardisiert im Teil 2 der AES Spezifikation und was heißt hier standardisiert? Das bedeutet konkret, dass das Datenmodell also aus dem Metamodell als Schema hinterlegt sein muss in den einzelnen Server Applikationen.

Aber genauso auch die Schnittstellen. Und diese Schnittstellenrepräsentation erfolgt dann über eine Open API Definition und genau diese Definitionen werden auch bereitgestellt von der Idta und unterscheiden tun wir hier mehrere Komponenten und die wichtigsten Komponenten sind die Repositories und.

Und das sind letztendlich Server, die die Shells und die Submodels selbst beinhalten und das kann man sich letztendlich als ganz einfache Quad Komponenten vorstellen. Das heißt ich habe ein AES Repository und kann dann dort eine neue AES erstellen, eine existierende AES per Get Recursed abfragen, ich kann sie löschen oder ich kann sie bearbeiten, das ist der simple Fall das.

Dann haben wir das Submodel Repository und hier wird es dann schon ein bisschen komplexer, weil letztendlich haben wir ja die Möglichkeit, beliebig tief eine Verschachtelung von submodel Elements vorzunehmen und das heißt, es reicht also nicht aus, dass ich ein Submodel anlegen kann und das dann wieder von meinem Server fatchen kann, sondern ich brauche auch die Möglichkeit, dann diese Verschachtelung letztendlich über die API abzubilden und. Und das ist letztendlich auch die Komplexität des Ganzen, sowohl auf der Datenbank Ebene, also wie bilde ich das zum Beispiel in einer SQL Datenbank ab, aber genauso auch auf der Endpunktebene, weil ich letztendlich die Möglichkeit brauche auf diese tief

verschachtelten Elemente zugreifbar zu machen und um das ein bisschen besser zu verstehen, führe ich mal einen weiteren Begriff ein. Und zwar hat jedes submodel Element, die sogenannte ID Short, und das ist letztendlich wie eine ID. Aber sie ist nicht global eindeutig, sondern nur eindeutig auf der jeweiligen Hierarchie.

Ebene des Submodel Elements. Und wenn ich jetzt zum Beispiel auf der dritten hierarchischen Ebene eines Submodels jetzt ein ein Property zum Beispiel für. Patcheln möchte mit dem Namen, ich nenn es jetzt mal testproperty, dann muss ich basierend auf diesen id Shorts einen Pfad aufbauen. Das heißt ich gebe zuerst die ID des Submodels an, die muss global eindeutig sein und dann gebe ich mit Punkten separiert den sogenannten ID Short Pass an.

Und aus diesem id Short Pass ergibt sich dann letztendlich wie ein ein Pfad entlang der Baumstruktur, um das Mal so ein bisschen grafisch zu probieren, zu beschreiben. Genau und in Ergänzung zu den Repositories, die die eigentlichen Informationen enthalten, haben wir dann noch Komponenten für die Registrierung in einem Netzwerk, das sind die Registrys, da stehen letztendlich die Endpunkte zu den eigentlichen Daten drin, die.

Dann haben wir noch den Discovery Service, der einen Link herstellt zwischen der eindeutigen ID einer LS und der ID eines Assets, also zum Beispiel das, was wir hinter einem QR Code auf einem Asset verbergen können. Und das sind letztendlich die wesentlichen Komponenten, die wir brauchen, um digitale Zwillinge als Software abbilden zu können. Ich bin mal ein bisschen provokant und sage, ihr braucht die ganze Palette an.

Relationalen Datenbanken und die ganze Power ja an Filtering, curing und so weiter weil wir, weil wir eine heterogene generische Verbaumte tief nestende, also rekursiv. Also es hat ja kein Ende, im Prinzip Struktur aufbauen müssen von verteilten Komponenten, ja absolut alles, Datenbanken, Webserver und so weiter klingt fast so, als wär das gar nicht mehr so richtig krass standardisiert, als wär quasi.

Die erste Administration Shell an dieser Stelle n Stück Papier eher und ob ich da jetzt meinen My Sequel Datenbank oder ne Post crease oder ne Maria DB irgendwie dranhänge um das zu realisieren ist wahrscheinlich Wurst oder ist das auch Teil oder gibt es sogar Implementierungen die fertig sind und da kommen wir wahrscheinlich jetzt da zu dem was wo du product owner bist. Nämlich wahrscheinlich ist nicht richtig verstehe die erste Administration Shell bis zum gewissen Maß auch einfach n stapel Papier und man kann sie implementieren. Was die funktioniert?

Mit einem gewissen Satz an Power, also an Tools, die es ja so gibt. Ja, und das habt Ihr glaube ich gemacht, richtig. Absolut ja. Also um die erste Frage zu beantworten, auf einer technologischen Ebene wird der Standard dann nicht mehr so genau, also es soll keine Vorgabe sein. Ihr müsst jetzt eine Post Curse Datenbank benutzen oder eine Mongo DB, sondern letztendlich die niedrigste Stelle, bis zu der man geht. Es sind wirklich die Submodel Elements und auf einer Technologie Ebene sind es die API Schnittstellen. Und tiefer als das geht das nicht. Also es soll nicht vorgegeben werden. Ja, um die Verwaltungsschale um die AES zu implementieren, müsste jetzt ganz konkret diesen Software Stack einsetzen und das Macht meiner Meinung nach auch

Sinn, weil je nach Anwendungsfall. Eine unterschiedliche Skalierbarkeit auch gebraucht wird und vielleicht manche Features auch gar nicht relevant sind. In dem einen Use Case, aber in dem anderen Use Case unglaublich wichtig sind und wie du schon gesagt hast, wir haben dafür eine Lösung umgesetzt, das ist Eclipse Basics und Eclipse Basics ist auf der einen Seite eine Middleware, also genau diese Implementierung.

Der Server Infrastruktur als als Komponenten, aber auch als SDK. Und woran halten wir uns natürlich an das Meta Modell, also Part 1 der Spezifikation und an die API Spezifikation aber was die Datenbanken angeht, da haben wir uns zum Beispiel in unserem Java SDK für Mongo DB entschieden. In Zukunft werden wir aber Tatsache auf SQL Datenbanken setzen, weil wir dort einige Vorteile erkannt haben.

Und du hattest auch erwähnt, diese tief verschachtelte Struktur ist ja technologisch erstmal ein unglaubliches Problem, wenn wir bestimmte Informationen extrahieren wollen, und das wurde auch so erkannt in in der Community und deswegen wurde Tatsache jetzt in der neuesten Version der Spezifikation eine Query Language für die AES entwickelt und diese Query Language soll es erlauben.

Unabhängig davon, auf welcher Ebene wir uns befinden, jetzt in der hierarchischen Struktur Informationen finden zu können, und das kann entweder über Wildcards funktionieren, also so, dass wir den Pfad zu dem Element nicht kennen, sondern, sagen wir mal nur, ich möchte jetzt nach einem Namen filtern oder nach einem Value, ich kann aber auch ganz konkret sagen, ja, ich möchte jetzt im digitalen Typenschild in den Kontaktdaten. Nach Kontakten filtern die aus dem Bereich, Ich sag mal Kundensupport kommen oder so.

Und letztendlich ergibt sich für die Entwicklerseite da eine unglaubliche Herausforderung, auch was die Implementierung angeht. Also das ganze skalierbar umzusetzen ist nicht leicht. Und in unserem Java SDK setzen wir jetzt zum Beispiel auf Elastic Search, um eine Indizierung vorzunehmen, der Daten und in späteren Implementierungen wollen wir dann eine direkte Übersetzung der LS Curry Language in SQL vornehmen, um dann in relationalen Datenbanken Informationen suchen zu können und da ist dann natürlich das Datenbankschema die große.

Herausforderung du sprichst jetzt häufiger von wer? Wir und bezieht sich dabei auf das Eclipse Basics nehme ich an oder wer ist da wir. Ja, also Eclipse Basics ist erstmal eine Open Source Organisation. Würde ich es jetzt mal nennen. Getrieben wird das Ganze von unserem Institut, also von dem I Ese, aber es gibt auch eine Reihe weiterer Unternehmen, die hier in der Entwicklung mit teilhaben und. Und da es sich um Open Source Software handelt, ist natürlich jeder frei hier auch zu contributen und das das sind ursprünglich natürlich die Unternehmen gewesen aus den Forschungsprojekten, wo wir zusammengearbeitet haben, also aus den Basisprojekten, das sind zum Beispiel Bosch, Rex, Rot oder Festo, immer noch dabei

Ford, es war mit dabei gewesen und ganz, ganz viele weitere Unternehmen. Und mittlerweile ist Basics zu einem de facto Standard geworden, auch in der Industrie und wird häufig als Grundlage eingesetzt. Und deswegen haben wir auch contribute zum Beispiel von SAP oder von Siemens, die das Ganze dann einsetzen und stetig am wachsen. Wenn das jetzt ein Unternehmen sich entscheidet, das einzusetzen oder die Asset Administration Shell, nee, ich frag noch mal anders.

Dein Unternehmen ja, zum Beispiel jetzt der Motorenhaussteller in deinem Beispiel mit der 10 C Maschine. Ja, die braucht Elektromotoren, die unter anderem in die 10 C Maschine wandern, der entscheidet sich jetzt. Asset Administration Shell ist eine gute Idee oder digitaler Zwilling bietet mehr Vorteile, Interoperabilität haben wir genannt, macht es vielleicht auch in meinen Prozessen einfacher all diese Sachen ja bringt wahrscheinlich auch eine Transparenz in in seine Produktion und seine Lieferkette ja kann man wahrscheinlich viele Vorteile finden, dann können.

Könnte also dieser Hersteller des Elektromotors entscheiden? Ich baue mir das jetzt auf und dafür als Grundlage Eclipse Basics nehmen und würde einen Entwickler daran lassen und das für sich als ein Hersteller implementieren oder für einen Use Case umsetzen oder wie kommt das in die Praxis ist die Frage.

Ja, ja, sehr gute Frage. Also klar, man kann einen Entwickler ransetzen und das SCK einsetzen, aber. Das ist in der Regel gar nicht das Ziel. Hier und vor allem auch nicht besonders realistisch für kleinere oder mittelständische Unternehmen. Und letztendlich braucht man hier eine Lösung von der Stange oder wie wir das nennen, Off The Shelve und Basics bietet eben nicht nur ein Software Development Kit an, sondern auch die sogenannten Off The Shelve Komponenten und das sind.

Kleinsten Fall erstmal Container Images zum Beispiel für Docker, die man dann bei sich einsetzen kann und deployen kann. Auf einem kleinen Server oder als Alternative. Wir bieten auch einen Data Space an, da können wir gleich auch noch mal drauf zu reden kommen auf Data Spaces. Wo dann die Infrastruktur für das Hosting von digitalen Zwillingen letztendlich an einem zentralen Ort liegt und die Hürde, die ein Unternehmen am Anfang zu gehen hat, es erstmal die Überzeugung zu haben, dass das einen Mehrwert bringt, und da können wir auch gleich noch mal drüber sprechen, was die konkreten Mehrwerte sind, und dann, wenn diese Entscheidung getroffen wurde, zu sichten, welche Informationen habe ich

denn eigentlich, die für mich von wert sind. Und in welchem Zustand sind diese Informationen? In welchem Format liegen diese Informationen vor, um dann letztendlich eine Pipeline aufzubauen, um die Informationen in den digitalen Zwilling zu übertragen? Und das könnte im simpelsten Fall sein. Ich habe schon ein Shopsystem, zum Beispiel mit meinen Produkten und muss einfach nur noch verweisen oder ein Mapping vornehmen zwischen meinen eigenen Endpunkten und den standardisierten Endpunkten. Und im schwersten Fall habe ich vielleicht nur papierdokumente, wo ich mich dann wirklich hinsetzen muss an an einen LS Editor, vielleicht eine Schablone erstmal mir erstelle für.

Meine Produkte, die ich habe und dann letztendlich das sukzessive mit Informationen befülle und wie wir das machen in Kundenprojekten ist, wir fangen mit den niedrig hängenden Früchten immer an, und das sind so Themen wie digitales Typenschild oder von mir aus auch der digitale Produktpass, der jetzt in voller Munde ist, einfach aufgrund der gesetzlichen Vorgaben und. Und machen dann weiter mit komplexeren Anwendungsfallen wie Einsammeln von Zeitreihen, Daten oder von mir aus auch das Control Component um wirklich steuerungsaktivitäten da durchzuführen.

Genau. Wir hatten uns vorgenommen, noch ein paar Sachen an zu teasern, also Mehrwert erzeugung und noch so ein paar Sachen sind gespeichert glaube ich in dieser Köpfern nicht, bei nicht bei mir überall. Ich will noch die letzte technische Frage stellen und dann überlasse ich den Rest. Den den den luftigeren Wellen, also den Mehrwerten und so weiter und ich darf noch abtauchen, den Tisch, ja, ja, die Zeit schreitet ja auch schon n bisschen voran, insofern eine Sache finde ich noch total spannend, weil, und das muss, das muss ja irgendwo n Thema sein, weil du sagst ja in der Industrie, also Asset Administration, Shell, digitale Zwillinge und so weiter also ich bin oft im industriellen Kontext unterwegs, das heißt für mich

immer sofort, wir haben halt getrennte. Netzwerke, segmentierte Netzwerke, denn meine Maschinen, meine meine meine PL CS und meine CNC Maschinen so weiter, die stehen ja nicht im Internet direkt nicht verbunden und ich habe dieses klassische Problem OT IT Convergence oder wieso meine Assets, die werden halt zum großen Teil auch Halt in der OT stehen und im OT Netzwerk sein und ich will aber wahrscheinlich im IT Netzwerk von den Datenbanken, den Dashboards in den Auswertungen und so weiter meine Assets da sehen wollen, verwalten wollen, teilen wollen weiß ich nicht.

Das sind ja die Mehrwerte, die wir gleich noch besprechen. Ja, habt ihr da auch n grundsätzlichen Plan? Ich weiß aus eigener Erfahrung, dass das gar nicht so einfach ist. Ja, und das hat ja sehr viel mit Sicherheit zu tun und sehr viel mit Firmenpolitik und und und wie man überhaupt dann, und das muss ja passieren, ein Loch durch die OT Firewall schießt um den Kram in die in die IT Welt rüber zu piepen, ja kannst du da vielleicht technisch auch noch mal so paar Sätze verlieren? Ja, also.

Unser Ziel oder unser Weg ist letztendlich nicht die OT mehr in Richtung der IT zu bringen, sondern wir bringen mehr die IT auch zu OT hin. Das heißt, Eclipse Basics ist zum Beispiel auf Edge Devices oder auf SPSN selbst Deployer, das heißt, im Idealfall hab ich für meine SPS eine Selbstbeschreibung als Form meines digitalen Zwillings und dieser digitale Zwilling selbst läuft auf der SPS.

Und das machen wir unter anderem damit, dass wir unsere Container Images auch für abendbasierte Geräte anbieten, auch für Abend v. 7, sodass wir dann direkt auf Steuerung deployen können, vielleicht nicht auf Steuerung, die 40 Jahre alt sind oder 30 Jahre alt sind, aber definitiv auf Steuerung, die nach 2000 letztendlich auf den Markt gekommen sind und.

Und letztendlich aus dieser Edge Ebene heraus können wir dann ganz konkret, natürlich unter Berücksichtigung aller Security Maßnahmen, dann über die LS Interfaces in die nächst höhere hierarchische Ebene kommunizieren. Das heißt, im Zweifelsfall reden wir nicht direkt mit der AES, die wir in der Produktion deployed haben, sondern da liegt noch mal eine übergeordnete AES da drüber und da schließt sich der Kreis auch wieder. Zu meiner Erklärung von vorhin, das sind die Typ 3 Asset Administration Shells und da haben wir dann letztendlich die Möglichkeit, eine autonome Verschachtelung von. Shells vorzunehmen, sodass letztendlich eine übergeordnete Shell Informationen von untergeordneten Shells einsammelt und Informationen

abstrahiert für die jeweilige hierarchische Ebene, also in unseren EAP und MES Systemen. Wollen wir ja am Ende vielleicht doch gar nicht jede einzelne Information sehen, also jeden einzelnen Sensormesswert oder jede einzelne Schraube. Also wir abstrahieren das ja, je höher wir letztendlich in dieser klassischen Automatisierungspyramide gehen, aber nichtsdestotrotz sind genau diese Schnittstellen auch da, die wir dafür brauchen. Du hast ja gesagt, Open, du hast ja Stichwort genannt, Open API, das ist ja nun mal für unsere Zuhörer, das ist quasi das, das wie es früher was zwegger war und so weiter das beschreibt im Prinzip.

Oder normalerweise, wenn ich jetzt nicht ganz falsch liege, beschreibt das quasi eine vollumfänglich eine West API. Wie die aussehen kann, weil da hab ich auch Freiheitsgrade, kann ja machen wie ich wie ich lustig bin, manuell Endpunkte so nennen wie ich Bock hab und das macht die auch, aber man wenn man es mit einer Open API Beschreibung versieht, dann ist es von außen quasi einsehbar und es ist ganz klar wie diese AP sich verhalten wird nichtsdestoweniger.

Trotzdem haben wir dann eine AP und es geht um Webserver und auch selbst wenn ich aggregierte Informationen durchschieße dann hab ich aber das Problem wenn ich in der OTN Webserver aufmache und. Und da Endpunkte aufmache, dann baue ich eine sogenannte Inbound Connection aus dem Höherliegenden it Level her und das ist, also muss ich quasi einen Port aufmachen der der Durchgeschleift wird durch die Firewall, der dann der dann horcht.

Könnt mir vorstellen also ich kenne ganz viele Firmen die sagen Boah da habe ich aber gar keine Lust zu kriegt ihr das durch wird das gemacht oder nehmt ihr eine andere Technologie? Habt ihr dann tatsächlich da einen Mqtt zum Beispiel zwischendurch der dann. Der dann quasi einfach nach außen wählen kann, wo der Server quasi außerhalb des OT steht. Irgendsowas ich weiß, das ist eine sehr technische, aber es interessiert mich trotzdem, weil das muss ja, das ist sofort immer Thema, wenn du wenn du wenn du Mehrwerte erzeugen willst und Sachen aus dem Shopfloor aus der OT in die IT reinfließen willst, egal auf welchem Abstraktionslevel, dann musst du einmal durch diese technische Barriere durch und dann eine gute Lösung

präsentieren sonst kenne ich viele Firmen, die da keinen Bock haben. Ne und anscheinend gibt es aber viele Firmen, die haben Lust drauf, also muss wahrscheinlich technisch ne gute n guten Weg geben den ihr gefunden habt. Magst du den Vorteil? Ja, also wie du schon sagst, je nach Unternehmen bestimmte Informationen will man ja gar nicht aus der OT rausholen und in der klassischen Automatisierungspyramide, wo wir jetzt auf welcher Layer wir die Verwaltungsschale die AS andocken ist letztendlich erstmal egal. Also wir können das auf der Feldebene oder bis zur Feldebene runter andocken, also wirklich den einzelnen Sensor, aber wir können auch sagen, ja, dann spricht halt eben nur das Edge Diba als sagen wir mal MQTT oder

OPCUA und das ist die einzige Verbindung raus und dann ist es halt eben der Port von MQTT, den wir freigeben müssen, also das Einzige was wir brauchen ist überhaupt ein Informationsfluss, aber es muss nicht zwangsläufig jetzt der HTTP port sein, der dann aus dem OT Bereich rausgeht. OK, cool. Also es ist flexibel genug, dann um solche Fälle dann auch abzusenken.

Gut. Absolut. Safe. Dann würde mich tatsächlich sehr interessieren, noch mal von dir aggregiert und zusammengefasst, die die Mehrwerte noch mal zu nennen und und offen gestanden ist, finde ich Interoperabilität eher noch so. Diese Fluffy ja, also deswegen treffe ich keine Investitionsentscheidung in der Asset Administration.

Shell nehme ich mal an, ne. Nein, also Interoperabilität alleine ist jetzt vielleicht noch nicht ausschlaggebend. Es ist sicherlich das Stichwort, was man sehr, sehr häufig hört, wenn man von der AES spricht, einfach weil das genau das größte Problem war, was man hier gelöst hat, aber es ist nicht unbedingt das, was jetzt viele Unternehmen im ersten Schritt interessiert, wenn sie sich jetzt damit beschäftigen.

Brauchen wir die AES oder nicht? Eigentlich. Ist es ja fast schon ne ne eigentlich ne Lösung wenn etwas also Interoperabilität ist ja die Lösung. Was ist das Problem dahinter? Müsste man vielleicht sogar eher fragen, ne? Genau, ja, absolut. Und ich denke viele dieser Probleme, die dem Ganzen zugrunde liegen, sind auch die Globalisierung, weil wir letztendlich nicht mehr abgeschottet sind als ein einzelnes Unternehmen, und wir machen nur unsere Sache.

Und wir stellen unsere eigenen Produkte her, die wir dann wieder bei uns im Shopfloor verwenden, sondern wir haben eben eine unglaublich hohe Komplexität aufgrund der Heterogenität der Komponenten, die wir einsetzen und uns fehlen auch unglaublich viele Informationen im herkömmlichen zu unseren Assets, also zu unseren Maschinen zum Beispiel.

Ich spreche mal das Thema Wartung an, wir. Wir reden ja immer von prädiktiver Wartung, präventiver Wartung und wollen Wartungszyklen irgendwie optimieren. Wir wollen weniger Ausfallzeiten haben, wir wollen wissen, wie wir auf Informationen Zeitreihendaten zum Beispiel zugreifen können, unsere Assets oder wir brauchen einfach mal nur ein Datenblatt, um nachschauen zu können, was sind die Kennwerte, was sind die technischen Daten und genau diese Informationen sind standaktuell einfach. Stark verteilt und manchmal kaum aufzufinden. Und die AES ist letztendlich als eine Art Lebenszyklusakte dann zu unseren Assets zu verstehen.

Das heißt, wir haben einen zentralen Ort, auf den wir zugreifen können, um alle relevanten Informationen zu finden, sowohl über den gesamten Lebenszyklus als auch zu einem spezifischen Moment für die Informationen, die für die. Rollen, die letztendlich an dem Asset interessiert sind, die Stakeholder relevant sind. Also das kann für den Wartungsingenieur letztendlich die Wartungsinformationen sein oder für den Betriebsleiter können das Stillstandszeiten sein oder das Können Zeitreihen Daten sein, die dann als KPIS verwendet werden. Also all diese Informationen letztendlich das ist das, was den großen Wert bringt und.

Dieses Einsammeln der Informationen, das Anbieten der Informationen von all den Assets, die ich habe, das ist ne unglaublich große Herausforderung. Und wenn ich diese Informationen einmal hab, dann kann ich daraus große Mehrwerte schöpfen, weil ich dann Themen angehen kann wie Plugin produce Optimierung. Anbindung von KI und Machine Learning an meine Produktion also dann öffnet sich mir die ganz, ganz große Welt der Use Cases, die ich auf nur auf einer digitalen Ebene letztendlich durchführen kann und nicht im klassischen Sinne auf auf der OT Ebene und das ist meiner Meinung nach der wesentliche Vorteil der ES und dass wir damit eben auch Interoperabilität schaffen, auch Unternehmensübergreifend, das

ist dann der Edit Bonus. Und der wird dann halt wichtig, wenn wir uns über Themen unterhalten wie den Batteriepass oder den digitalen Produktpass, wo wir letztendlich gesetzliche Vorgaben haben, die erfüllt werden müssen. Also letztendlich für Unternehmen die Verpflichtung, wenn sie Produkte veräußern in der EU, dass gewisse Informationen mit. Weitergegeben werden müssen an Kunden, die diese Produkte kaufen und auch dafür braucht man letztendlich einen Standard. Und ob das am Ende die AES sein wird, das ist natürlich erstmal offen, aber es macht zumindest Sinn, diesen Standard dafür in Erwägung zu ziehen.

Kannst du schon ein bisschen was sagen zur Verbreitung der AES? Gibt es da zahlen, gewisse Fortschrittsdaten vielleicht auch, ob Firmen schon davon davon berichten, dass sie davon profitieren im Sinne von. Es öffnet vielleicht neue Türen ist und so viel Kosten gespart sind, so viel mehr Umsatz klar ist. Schwierig ist natürlich sehr ein sehr großes Feld, aber vielleicht gibt es ja ein paar konkrete coole Beispiele, die du auch nennen darfst kannst.

Ja, ja, das ist natürlich generell erstmal ne unglaublich schwierige Frage, weil dieser Return on Invest von Daten erstmal per se schwer nachzuvollziehen ist. In in einem kurzen Zeitraum aber ob. Die AES ist zumindestens in einem unter einigen Unternehmen schon für längere Zeit im Einsatz und ich nenne mal ganz gerne Bosch Rexrodt als Beispiel.

Die haben unglaublich früh angefangen sich mit der AES zu beschäftigen, waren ja auch in den Basisprojekten mit dabei gewesen, haben die Technologie führend mit vorangetrieben und haben jetzt mehrere Millionen Shells bei sich in der Produktion, also wirklich produktiv im Einsatz und können dann aus diesen dann. Daten Mehrwerte generieren und der Bosch Semantic Stack setzt letztendlich genau auch auf dieser Technologie auf und das Ganze wird dann auch über die Control X Plattform von Bosch Rexrodt verbreitet.

In Systeme, wo zum Beispiel Bosch SPS eingesetzt werden. Aber genauso kann man hier auch erwähnen, Siemens, die das in verschiedensten Domänen vorantreiben, sei es die Pharmaindustrie, sei es die Prozessautomatisierung oder sei es von mir aus auch generell der Bereich Manufacturing. Also hier gibt es unglaublich viele Interessenten, auch auf verschiedensten Ebenen in der Automatisierungspyramide vorhin schon SAP erwähnt, da sind wir ja in der ERP Ebene unterwegs und wenn. Wenn ich mich richtig erinnere, hat die ATP in einem Beitrag mal gesagt, die Hälfte der deutschen Industrieunternehmen denkt über den Einsatz der AAS nach oder setzt diese schon ein. Wie vertrauenswürdig die Zahl ist, kann ich jetzt nicht persönlich bestätigen, aber es

ist zumindestens in Deutschland ein unglaublich relevantes Thema geworden. Und das, das sieht man auch an der Hannover Messe, also die Idta ist letztendlich in der größten Halle immer mit dabei, mit all den prominenten Industrieunternehmen, die man sich so vorstellen kann. Also es ist schon sehr, sehr wichtig geworden.

Würdest du sagen, dass die es für jedes Einzelunternehmen mehr wert ist, je mehr andere Unternehmen irgendwie auch damit arbeiten? Ja, ja, ganz klar. Also das ist ein absolutes Jahr. Weil daraus ergeben sich ja dann erst die Skalierungsfaktoren, bin ich das einzige Unternehmen, was die AS einsetzt. Aber meine Zulieferer machen das nicht, dann habe ich diesen Bruch letztendlich in der Informationskette, das heißt in in der Lieferkette habe ich erst ab einem bestimmten Zeitpunkt die AS und betreibe im Zweifelsfall auch riesigen Aufwand, erstmal die Informationen in das Format zu bringen, aber.

Aber hab ich jetzt die gesamte Wertschöpfungskette mit der AES ausgestattet, dann ergibt das große Mehrwerte und das beste Beispiel ist die Automobilindustrie in Deutschland, aber auch Europa. Vielleicht habt ihr schon von Catena X mal gehört, das ist der Data Space für die Automobilindustrie. Und hier werden auch Standards wie die AES gelebt und letztendlich reden dann verschiedenste Unternehmen über Data Spaces miteinander und die ausgetauschten Informationen können dann im Format der AES auch vorliegen und damit versteht letztendlich jeder diese Informationen, auch das heißt, es kann gehandelt werden.

Über den Data Spaces können sogenannte Smart Contracts darüber erstellt werden und. Und diese Skalierungsfaktoren machen dann die Technologie auch wertvoll in einem globaleren Kontext. Jetzt hast du sogar direkt die Data Spaces noch mit erklärt. Hast du vorhin gesagt, willst du noch mal drauf zurückkommen? Zumindest das mal erwähnt haben.

Genau, wir haben auch unseren eigenen Data Space für Einsteiger, das ist der AS Data Space für Everybody, der läuft bei uns am Institut, da arbeiten wir mit der Firma Netab zusammen, die haben uns. Dankenswerterweise sehr, sehr kompetente Infrastruktur bereitgestellt, Server, Infrastruktur und da deployen wir unsere Basics, Infrastruktur, Komponenten, um dann Millionen 100000000 Shells Submodels zu hosten von verschiedenen Unternehmen, die letztendlich einsteigen wollen in die Thematik und Unternehmensübergreifend auch über den Standard kommunizieren möchten. Ok, Burkhard.

Hier keine Fragezeichen mehr in deinen Augen. Nee, alles gut war glaub ich n großes Bild was wir heute gemacht haben. Bisschen Technik, bisschen eingesortiert, ja. Ja, es ist ja auch. Es ist ja auch durchaus spannend irgendwie und vielschichtig, so von Standard hinzu Implementierung hinzu konkreten Unternehmen, wie sie es, wie sie es nutzen, da ist ja einiges dabei und jetzt hab ich dich so verstanden, Aaron, vorhin hast du Kundenprojekte erwähnt, also das heißt oder?

Beziehungsweise wie sieht so n Kundenprojekt für euch aus? Inwiefern seid ihr tätig in dem Ganzen? Neben der Entwicklung von von Basics? Genau, also Kundenprojekte bedeutet für uns, dass wir Eclipse Basics einsetzen bei einem Unternehmen, was Interesse hat, sich mit der Verwaltungsschale mit der EES zu beschäftigen. Ich hatte vorhin diese niedrig hängenden Früchte erwähnt, also es gibt teilweise Projekte, die sind sehr, sehr klein, wo wir einfach mal.

Gucken ja, welche Daten hat das Unternehmen jetzt eigentlich? Und mal beispielhaft so eine AS händisch zusammenbauen für ein Produkt um da eine Schablone letztendlich zu haben, dann deployen wir das in unserer Infrastruktur und haben einfach mal einen Eindruck davon zu bekommen, welche Schritte müssen hier gegangen werden und im Zweifelsfall fällt dann am Ende ein. Tool raus, was dann automatisch aus existierenden Daten shells für das jeweilige Unternehmen erzeugt. Das ist so ein simpler, so ein simples Szenario, wir haben aber auch Kunden, die wollen das Thema wirklich in in seiner Komplettheit betrachten, also keine Abkürzung gehen, sondern die Committen sich dann komplett auf die Thematik und da wird dann erstmal auf einer Concept

Ebene angefangen, also. Was brauche ich zum Beispiel an physischer Infrastruktur in meinem Unternehmen? Was brauche ich für Informationen als Grundlage, wie kann ich meine Engineering Modelle mit einbetten, wie kann ich das verbinden mit den Protokollen, die bei uns in der Produktion zum Einsatz kommen, wie kann ich das anschließen an unsere Business Process Ebene nenne ich es mal.

Also an meine MES und ERP Systeme und das sind dann deutlich aufwendigere Projekte. Wo letztendlich mit vielen Stakeholdern erst gesprochen werden muss und ganz konkrete Equirements auch erstmal eingesammelt werden müssen, bevor es dann überhaupt zu dem Punkt kommt, dass wir jetzt sagen, ja, wir deployen Eclipse Basics und wir, wir binden jetzt alle Assets an, also es gibt da keine eine Antwort, so, so läuft es nach dem Schema X. Gut, aber du hast uns mal Überblick gegeben über die Dienstleistungen und das Angebot, was wir dort bieten. Bieten könnt.

Dann würde ich auch entsprechend euch verlinken. Dich verlinken darf man dich ansprechen zum Thema AES und digitaler Zwilling. Auf jeden Fall das. Das würde mich sehr freuen. Also Diskussion führe ich eh immer sehr gerne zu dem Thema. Ja, also ja. Ja, OK, begleitet dich jetzt auch schon wirklich lange so wie es aussieht. Ja, ein paar Jahre schon, das stimmt, OK. Müssen wir sonst noch irgendwas erwähnen oder möchtest du noch etwas erwähnen, was wir vielleicht vergessen haben wo du sagst das ist unbedingt noch wichtig, dass es auf die Tonspur kommt.

Ich glaube, das reicht. Also wir haben über sehr, sehr viele Sachen geredet, wir könnten jetzt noch ne weitere Stunde reden und würden immer noch Themen finden, aber zumindestens was den industriellen oder Industrie 40 Bereich angeht und die wesentlichen Themenpunkte haben wir alles. Perfekt. Dann sag ich vielen dank Aaron, viel Spaß gemacht, ja und?

Vielleicht bis zum nächsten Mal. Tschau tschau. Ja, danke für die Einladung. Noch mal hat mir auch sehr viel Freude bereitet. Ich schließe mich euch an. Vielen Dank. Aaron war cool, wieder viel gelernt, AAS mal in einer Stunde auf die Turnspur gelegt, sehr gut, dann Tschüss aus Hamburg. Einfach komplex wird produziert und präsentiert von Heisenware. Heisenware ist deine Low Coop Plattform zur Erstellung und zum Betrieb interaktiver Apps rund um den Shopfloor. Starte noch heute dein Free Trial unterheisenware.com einfach komplex.

0:00 / 0:00