- IT&Production - https://www.it-production.com -

Auf die Interoperabilität kommt es an

IIoT-Lösungen auslegen und integrieren

Auf die Interoperabilität kommt es an

Lösungen rund ums IIoT adressieren vielfältige industrielle Anwendungsbereiche. Um von der Plattform zum Management von Sensoren und Aktoren bis hin zur integrierten Manufacturing Plattform die passende zu finden, sollten sich Firmen zunächst ein Bild von der Standardisierung im IT/OT-Umfeld verschaffen. Erst mit dieser Einordnung auf allen Ebenen der Automatisierungspyramide lassen sich die Anforderungen an das eigene IIoT definieren.

Die verschiedenen Ebenen der Automatisierungspyramide (Bild: Unity AG) [1]

Die verschiedenen Ebenen der Automatisierungspyramide (Bild: Unity AG)

Die Operational Technology (OT) ist auf dem Weg zur Industrie 4.0 in den vergangenen Jahren schnell und nicht immer einheitlich gewachsen. Hintergrund dieser Heterogenität ist, dass die Hersteller der einzelnen Komponenten unabhängig unterschiedliche Technologieentscheidungen zur Integrationsfähigkeit getroffen haben. Diese unabhängigen Entscheidungen führen auf Anwenderseite zu der Herausforderung, diese unterschiedlichen Technologien mit teilweise erheblichem Aufwand in die eigene OT-Landschaft zu integrieren und in dieser zu betreiben. Auf den verschiedenen Ebenen der Automatisierungspyramide ergeben sich Ansätze und Standards, die diese Integrationsaufgabe erheblich erleichtern. Der Artikel betrachtet insbesondere die Integration von Layer 2 bis Layer 4, bevor die Integration der IIoT-Lösungen selbst behandelt werden.

Einheitliche Datenmodelle mit OPC UA

Für die Vereinheitlichung der Kommunikation ist OPC UA (Open Platform Communications Unified Architecture) der Defacto-Standard. SCADA-Komponenten (Supervisory Control and Data Acquisition) unterstützen OPC UA teilweise nativ. Komponenten, die dies nicht tun, jedoch wegen ihrer hohen Nutzungsdauer noch länger im Einsatz bleiben, können über schlanke Adapter-Lösungen für OPC UA befähigt werden. OPC UA bietet dabei zwei Vorteile: Erstens vereinheitlicht das Protokoll selbst die Kommunikation. Zweitens werden durch anwendungsspezifische Companion Specifications auch semantisch einheitliche Datenmodelle bereitgestellt. Damit kann abhängig vom Anwendungskontext ein hoher bis sehr hoher Grad an Standardisierung erreicht werden. Zur Anlagen- und Layer-übergreifenden Kommunikation gibt es mehrere Lösungen, die das Prinzip eines Data Integration Layers auf Basis von OPC UA umsetzen. Der Fokus dieser Lösungen liegt auf der Integration von Datenquellen und deren einheitlicher Darstellung für die nutzenden Manufacturing Execution-Systeme (MES). Data Integration Layer stellen also eine standardisierte Kommunikation zwischen MES-Komponenten auf Layer 3 und der SCADA-Welt auf Layer 2 sicher.

Prozesse mit Micro-Services abbilden

Auf dem MES-Layer ist ebenfalls eine heterogene Welt von Lösungen rund um die Themen Fertigungssteuerung, computergestützte Qualitätssicherung, Instandhaltung usw. entstanden. Klassische Systeme auf diesem Layer bringen Funktionen aus mehreren Bereichen mit und haben verschiedene fachliche Schwerpunkte. Diese Systeme ermöglichen eine modulweise Integration meist nur schwer oder gar nicht. Viele moderne Software-Architekturen setzen auf einen anderen Ansatz. Software wird modularer und über definierte Application Programming Interfaces (APIs) offen und integrationsfähig. Dabei kann die Software zwischen einem komplexen internen Datenmodell und einem zur Integration vereinfachten externen Datenmodell unterscheiden. Über das externe Datenmodell ist es möglich, einen offenen Datenaustausch mit anderen Komponenten zu realisieren. Aus Sicht eines Software-Architekten ist diese Form der Softwarebereitstellung als Micro-Service-Architektur umzusetzen. Jeder Micro-Service stellt eine in sich gekapselte und unabhängige Funktionalität bereit, die sich zur Abbildung von Prozessen mit anderen Micro-Services orchestrieren lässt. Die Software-Anbieter öffnen inzwischen ihre Software für eine offene Integration im Sinne von Micro-Services. Die APIs bieten die Möglichkeit, ereignisbasiert zu kommunizieren. Auf Ereignisse und verbundene Daten eines Micro-Services können sich andere Micro-Services registrieren. Tritt das Ereignis ein, werden die registrierten Abonnenten benachrichtigt und die Daten direkt übergeben.

Streben nach Standardisierung

Um diesen Mechanismus auch in einer komplexen Systemlandschaft skalierbar zu nutzen, kann zusätzlich ein Message Bus eingesetzt werden, der die Ereignisse und Daten entgegennimmt und für eine performante und garantierte Zustellung der Nachrichten in einer verteilten Systemlandschaft sorgt. Die so integrierten Software-Komponenten (Micro-Services) lassen sich über die Einführung einer Integrationsplattform weiter standardisieren. Die Plattform übernimmt in diesem Fall die Basisfunktionen, wie Identitätsmanagement oder Rollen- und Rechtemanagement. Außerdem erfolgt die Bereitstellung der Laufzeitumgebung für Micro-Services auf Basis von virtualisierter Infrastruktur, Containern oder Serverless-Technologien. Der Betreiber der Plattform kann so die Integrationsaufgaben fokussieren. Integrationsplattformen entstehen hier teils domänenspezifisch (Produktion, PDM/PLM, …) oder domänenneutral.

Bild: ©fotohansel/stock.adobe.com [2]

Bild: ©fotohansel/stock.adobe.com

Strategischer Wissensaufbau

Aus Sicht eines Anwenderunternehmens ist die Entscheidung für die richtige Plattform davon abhängig, wie viel Integrations-Knowhow im eigenen Unternehmen verankert werden kann und soll. Die domänenspezifischen Plattformen werden von Anbietern der klassischen Lösungen am Markt platziert. Der Einsatz erzeugt eine starke Bindung an einen Lieferanten. Offene Plattformen bieten für den Anwender dagegen die Chance, Komponenten in Zukunft einfacher mit auf die Plattform zu nehmen oder ganz auszutauschen, und damit eine größere Unabhängigkeit von Lieferanten. Dafür muss im eigenen Unternehmen die Umsetzungs- und Betriebskompetenz vorhanden sein oder aufgebaut werden. Unter dem Strich ergibt sich auf Layer 3 der Automatisierungspyramide durch moderne Software-Architekturen die Chance, das Unternehmen schrittweise technologisch zu standardisieren und zu öffnen. Im Einzelnen hängt der richtige Weg dabei von der Unternehmensstrategie ab. Die Unternehmensberater der Unity AG beobachten aber zunehmend den Wunsch von Fertigungsunternehmen nach mehr eigener Kompetenz und Unabhängigkeit im Betrieb dieser Komponenten.

Standards der ERP-Welt nutzen

Schnittstellen klassischer MES-Komponenten zu ERP-Systemen sind typischerweise produktgebunden, als Beispiel seien SAP-zertifizierte Schnittstellen angeführt. Von diesen ist ein Trend hin zu einer Mischung aus verschiedenen Integrationsansätzen zu bemerken. Die Auswahl wird durch den jeweiligen Anwendungskontext bestimmt. Von REST-Services für eine agilere Integration über Integration-Bus-Ansätze mit verbundenen Enterprise Webservices sind hier der Technologie keine Grenzen gesetzt. Generell werden bei der Kommunikation vom MES- zum ERP-Layer nur verdichtete Daten weitergegeben. Massendaten und Rohdaten aus dem Industrial IoT-Kontext werden durch MES-Komponenten verarbeitet.

Der Systems-of-Systems-Ansatz

Auch immer mehr Maschinenhersteller bieten Lösungen zur vertikalen Integration bis zum MES-Layer an. Maschinen werden inklusive verbundener IIoT-Services, etwa in Form eines digitalen Zwillings, über den die Maschinen verwaltet werden können, angeboten und verkauft. Die Wahl einer Plattform zur Abbildung des digitalen Zwillings eines Produkts mag aus Sicht des Herstellers noch verhältnismäßig einfach sein. Die Maschinenbetreiber, die dieses Produkt innerhalb ihrer Produktionen einsetzen und als Teil ihrer Smart Factory-Lösung nutzen möchten, hätten die Wahl vielleicht anders getroffen. Solange sich die Hersteller-IIoT-Plattform an den Architekturprinzipien einer wie oben beschriebenen Software-Architektur orientiert, kann die IIoT-Lösung einfach als Subsystem der Integrationsplattform auf dem MES-Layer integriert werden (vgl. Bild auf Seite 1). Mit ihrer Integration entsteht ein System-of-Systems-Ansatz. Damit integriert man system- oder domänenspezifisches Wissen in eine Gesamtlösung, ohne sich in der Tiefe mit Logik und Daten beschäftigen zu müssen. Dies gelingt, solange die IIoT-Plattform eine offene dokumentierte Schnittstelle zu den Funktionen und Daten des integrierten Produkts bereitstellt. Eine Lösung, die offene Integrationsmöglichkeiten nicht bietet, ist damit eher mit einem klassischen geschlossenen System vergleichbar und sollte vor einer Auswahl sehr genau auf eine Eignung für den Einsatz geprüft werden. Eine passende IIoT-Lösung lässt sich jedoch transparent und serviceorientiert in die eigene OT-Architektur integrieren und verhält sich ab der Integrationsschnittstelle wie alle anderen Komponenten der Plattform. Für den Anwender lässt sich damit die Detailkomplexität in der Umsetzung der Gesamtlösung verringern.

Auswahlfaktor Interoperabilität

Wer eine intelligente, vernetzte Fabrik aufbauen möchte, muss die Integration ganz unterschiedlicher Lösungskomponenten im jeweiligen Anwendungskontext berücksichtigen. Die Interoperabilität der Lösungen wird somit zum zentralen Auswahlfaktor. Daher sind Lösungskomponenten mit standardisierten Schnittstellen, offenen Datenmodellen und APIs meist geeigneter als geschlossene Komponenten, die sich nur schwer integrieren lassen. Viele produzierende Unternehmen müssen dieses Knowhow gerade schrittweise aufbauen. Zur Einführung kann das notwendige Wissen auch extern beschafft werden. Da mit der Einführung von Integrationsplattformen aber auch ein langfristiger Betrieb verbunden ist, haben die Berater der Unity AG die die besten Erfahrungen damit gemacht, entsprechendes Wissen über ein Coaching Schritt für Schritt beim Anwenderunternehmen zu verankern.


Dr. Markus Luckey ist Senior Manager bei Unity AG.

Andreas Linneweber ist Senior Manager bei Unity AG.