Datendurchgängigkeit in der Industrie: Wie sich Software und IT verändern

Digitale Plattformen: IT-Trends verstehen

Veröffentlicht 14.12.2021

In allen Entscheidermedien begegnet Ihnen das Warndreieck „Die Industrie muss bei der digitalen Transformation aufholen!“ Richtig, es stimmt jedoch auch, dass die Plattformökonomie bereits viele Veränderungen in der IT-Landschaft mit sich gebracht hat. Damit Sie diesen Wandel besser einordnen können, haben wir Nikolai D’Agostino als Experten für die Digitale Fabrik gefragt, welche IT-Trends für Manager aus Fertigungsunternehmen interessant sein können. Lesen Sie hier in sieben Thesen, wie er die Entwicklungen beschreibt und einordnet.

Datendurchgängigkeit in der Industrie: Wie sich Software und IT verändern

Die Corona-Krise fordert Industrieunternehmen in einem noch nie gekannten Ausmaß heraus. Umsätze, ganze Märkte brechen ein und Wertschöpfungsketten stocken. In den zurückliegenden Jahren haben viele Entscheider über die Vor- und vermeintlichen Nachteile der Digitalisierung der Fertigung diskutiert. Die 2011 ausgerufene 4. Industrielle Revolution – übrigens die erste industrielle Revolution, die ausgerufen wurde, bevor sie stattgefunden hat – kommt nicht in dem Maße voran, wie man sich das vorgestellt hat. Durch die Krise hat sich jetzt eine Situation ergeben, die den Umbruch stark begünstigen könnte.

Ein wesentlicher Aspekt in diesem Zusammenhang ist die Kluft zwischen IT – bezogen auf die Automatisierungspyramide sind das die oberen Ebenen – und Operational Technology (OT), die fertigungsnahe Prozesse auf der Feldebene steuert.

Gefühlt hinkt die Operational Technology der IT um einige Jahre hinterher, wenn es um Softwaretechnologie-Themen wie Serviceorientierung, Objektorientierung oder Kommunikation in verteilten Systemen (Pub-Sub vs. Client-Server) geht.

Dies ist zu einem guten Teil den langen Produktlebenszyklen hochwertiger Investitionsgüter wie Automatisierungsanlagen sowie speziellen Anforderungen wie dem notwendigen zeitdeterministischen (Echtzeit-)Verhalten geschuldet.

Allerdings erweist sich dies zunehmend als Hürde, flexibel vernetzte Systeme im Sinne von Industrie 4.0 aufzubauen, wozu es einer Konvergenz zwischen IT und OT bedarf.

  1.  Open Source

    Industrieunternehmen setzen verstärkt Open Source-Anwendungen für ihre Automatisierungs- und Produktionsprojekte ein. Viele Anwendungen im Bereich Machine Learning und KI setzen heute bereits auf Open Source (beispielsweise Rapidminer oder TensorFlow).

    Dieser Trend bedeutet ein Umdenken – bei der Entwicklung genauso wie bei der Anwendung und Nutzung von Software. Open Source ist eine wichtige Voraussetzung, um offene Datenmarktplätze und Kundenplattformen entstehen zu lassen. Gleichzeitig befördern Open Source-Ansätze neue Impulse aus der IT-Industrie, welche die angestrebte Konvergenz von OT und IT begünstigen kann.

    Noch etwas spricht für die wachsende Bedeutung von offenen Standards und Open Source: Unternehmen wollen sich nicht an einen Anbieter binden. Die Corona-Krise wird das vielleicht sogar noch verstärken.
     

  2. Low Code

    Ein weiterer Trend im Zusammenhang mit Open Source ist Low CodeDiese Technologie ermöglicht es, über visuelle Ansätze Applikationen zu entwickeln, die bislang nur mit Hilfe von Kontrollstrukturen in einer Hochsprache umgesetzt werden können. Ein Beispiel ist das visuelle Verdrahten von Funktionsblöcken.

    Low Code ermöglicht es Ingenieuren ohne tiefes Coding-Vorwissen, selbst Applikationen bzw. Softwarebausteine zu entwickeln. Geübte können mit der neuen Form der Programmierung innerhalb kurzer Zeit Prototypen bauen, sie mit dem Kunden testen und dann weiterentwickeln.

    Der Einsatz von Low Code erhöht somit die Flexibilität, reduziert die Entwicklungszeiten- und Kosten und forciert App-Entwicklungen für Plattformen, um neue Geschäftsmodelle schneller zu testen und erfolgreich weiterzuführen.  
     

  3. Software Defined Manufacturing

    Der Konvergenz von IT und OT kommt insbesondere bei der Programmierung von Anlagensteuerungen eine besondere Bedeutung zu. Stand heute ist ein Großteil der Businesslogik tief in den SPS (Speicherprogrammierbare Steuerungen) verborgen. Die auf dem Standard IEC 61131-3 basierenden Logikprogramme sind in der Regel starr programmiert und erlauben nur einen begrenzten Grad an Flexibilität.

    Hier wäre es wünschenswert, nur noch Basisfunktionen, die zwingend einen zyklisch ablaufenden Zeitdeterminismus (Echtzeit) erfordern, in der Steuerung direkt bereitzustellen und ereignisgesteuerte Businesslogik in übergeordneten System über eine API anzubinden.

    Dies würde es erlauben, flexiblere Anpassungen der Businesslogik mit Hilfe von Hochsprachen oder mit Low Code zu entwickeln.

    Der Ansatz, die Funktionalität von Produktionssystemen noch stärker in Richtung Software zu verlagern, spiegelt sich in dem immer höheren Anteil der Wertschöpfung der Software bei der Entwicklung von Produktionsanlagen wider.

    Das Thema „Software Defined X“ gibt es im Übrigen schon in vielen Bereichen. Grundsätzlich steht "Software Defined X" dafür, dass ausschließlich Software verwendet wird, um Funktionalitäten zu realisieren, ohne Änderungen an der zugrundeliegenden Hardware vorzunehmen. Beispiele sind Smartphones, Software Defined Networking, Software Defined Radio, Software Defined Infrastructure…

    Software Defined Manufacturing ist die Übertragung dieses Ansatzes auf die Produktionstechnik. Eine wesentliche Rolle spielt hier das Konzept des digitalen Zwillings in der Produktion und beim Engineering von Automatisierungsanlagen, auf das später noch eingegangen wird.
     

  4. Middleware

    Um solche Konzepte einer konvergenten Kommunikation zu realisieren, bedarf es einer vereinheitlichten Kommunikationsschicht, die sämtliche angebundenen Systeme über eine gemeinsame Softwareschnittstelle (API) ansprechen kann. Dies erlaubt auch die Realisierung service-orientierter Architekturen, die es ermöglichen, Systeme lose anzubinden. Auch hier bietet die Open Source Community eine ganze Reihe von so genannten Middleware-Systemen wie z. B. Camel, Kafka, und viele andere mehr.

    Die Integrationsfähigkeit von Softwaresystemen mit einer solchen Middleware ist die Basis für die Realisierung datendurchgängiger Kommunikationssysteme nach dem Beispiel eines Enterprise- oder Manufacturing Service Bus.
     

  5. Konnektivität

    Bei der Vielfalt der inzwischen zur Verfügung stehenden Middleware-Systemen stellt sich die Frage, wie sichergestellt werden kann, dass über unterschiedlichste Systeme hinweg Konnektivität und Interoperabilität realisiert werden können.

    Der Standardisierung kommt dabei eine wesentliche Rolle zu und ein wichtiger Standard der industriellen Kommunikation ist OPC UAAufgrund eines integrierten Datenmodells erlaubt OPC UA Stand heute bereits Konnektivität mit einem hohen Abstraktionsgrad der Daten.

    Industrieverbände wie der VDW leisten hier Aufbauarbeit. Die Initiative UMATI unterstützt das Thema Datenmodell für den Datenaustausch in der Anwendungsdomäne der Werkzeugmaschinen. Das Ergebnis wird eine so genannte OPC UA Companion Specification sein, also ein spezifisches Datenmodell für diese Anwendungsdomäne.
     

  6. Interoperabilität

    Eine weitere wichtige Standardisierungsinitiative ist die Verwaltungsschale oder Asset Administration Shell, die sich aus dem RAMI 4.0 ableitet (Referenzarchitekturmodell Industrie 4.0). Die Verwaltungsschale hat das Ziel, in Zukunft Systeme mit einem Grad an Integration zu erstellen, die es erlauben sollen, Selbstorganisation in Produktionsprozessen zu ermöglichen und damit letztendlich eine Smart Factory zu realisieren.

    Die Verwaltungsschale kann dabei als eine standardisierte Version eines digitalen Zwillings angesehen werden. Sämtliche Spezifikationen zur Verwaltungsschale sind offen gelegt und frei verfügbar. Mit Hilfe der Open Source Anwendung AASX kann sich jeder mit dem Konzept der Verwaltungsschale vertraut machen und erste Prototypen durchspielen.

    Es gibt bislang aus meiner Sicht keine eindeutige Definition des digitalen Zwillings. Tatsächlich kann der digitale Zwilling auf einem sehr generischen Level als digitale Repräsentation eines Gegenstandes von Relevanz in der betrachteten Anwendungsdomäne angesehen werden.

    Damit kann ein kinematisches 3D-Simulationsmodell ebenso ein digitaler Zwilling einer entsprechenden physischen Produktionsanlage sein wie dessen logisches Steuerungsmodell, welche jeweils als Submodell in der gemeinsamen Verwaltungsschale existieren. Die Verwaltungsschale repräsentiert die physische Produktionsanlage in der digitalen Welt und kann sowohl Laufzeitinformationen bereitstellen als auch als Schnittstelle für steuernde Eingriffe aus der digitalen Welt dienen.

    Diese Eigenschaft macht die Verwaltungsschale in Verbindung mit dem repräsentierten Gegenstand zu einem wichtigen Baustein für eine zukünftige Smart Factory (cyberphysisches System).

    Eine eingängige Analogie zum Digitalen Zwilling ist ein LinkedIn-Profil. Jemand repräsentiert seine Fähigkeiten und Angebote in der digitalen Welt und kann sich so mit anderen Teilnehmern über deren digitale Repräsentation vernetzen.

    Ähnlich muss man sich dies in der Produktionstechnik vorstellen, bei der der digitale Zwilling eines Produktes mit dem digitalen Zwilling einer Fertigungsanlage seine eigene Herstellung aushandelt.

    Technische Ansätze dazu wie die fähigkeitsbasierte Fertigungsplanung sind in der Entwicklung. Eine weitere eingängige Analogie dazu ist die USB-Schnittstelle für Computerperipherie. Diese erlaubt es, unterschiedlichste Geräte automatisiert zu konfigurieren, durch Mechanismen zur Selbstbeschreibung, die wir in Zukunft auch in der Automatisierungstechnik wiederfinden werden. Voraussetzung dazu ist ein durchgängiger semantischer Datenaustausch.
     

  7. Durchgängiger semantischer Datenaustausch

    Für den Datenaustausch braucht es auch bei der Verwaltungsschale Datenformate, die von allen Teilnehmern verstanden und verarbeitet werden können. Ein vielversprechender Ansatz ist der Standard AutomationML, der im Zusammenhang mit der Verwaltungsschale eine Daten-Serialisierung, und damit den Datenaustausch auch der komplexen internen Datenstrukturen, vollständig und verlustfrei ermöglicht.

    AutomationML verwendet dazu ein Konzept, welches die Bedeutung (Semantik) der Datenobjekte über entsprechende Bibliotheken mitliefert und somit das Potential für den oben beschriebenen Selbstbeschreibungsmechanismus bietet. So können z. B. so genannte Untermodelle, aus denen eine Verwaltungsschale besteht, vollständige Beschreibungen von Automatisierungskomponenten enthalten, die neben der 3D-Geometrie auch die Kinematik, Verhaltensmodelle und Steuerungsprogramme beinhalten. AutomationML ist ein neutrales, XML-basiertes Datenformat für die Speicherung und zum Austausch von Anlagenplanungsdaten, das als offener Standard frei zur Verfügung steht.

    Ursprüngliches Ziel des Standards AutomationML ist der Austausch von Engineering-Daten in einer heterogenen Tool-Landschaft von Engineering-Werkzeugen für verschiedene Disziplinen, wie zum Beispiel Mechanisches Design, Elektrisches Design, HMI-Entwicklung, SPS-Programmierung oder Robotersteuerung.

    AutomationML wird aber zunehmend als Metadatenformat eingesetzt, welches als Universalwerkzeug zur Lösung von Datenaustauschproblemen verwendet werden kann. Für das Metadatenmodell von AutomationML gibt es inzwischen auch eine OPC UA Companion Specification, die das Metadatenmodell von AutomationML auf der spezifischen Datenmodellrepräsentation eines OPC UA Servers (Name Space) abbildet. Dies erlaubt es, automatisiert mit AutomationML beschriebene Datenmodelle über einen OPC UA Server bereitzustellen, was beide Standards sinnvoll ergänzt. 

 

Soweit meine Ansichten zu den wichtigen IT-Trends in der Industrie. Haben Sie ein Thema vermisst? Möchten Sie mehr Details erfahren? Melden Sie sich gerne!

Jetzt abonnieren - bleiben wir in Kontakt?