Die Umsetzung von Industrie 4.0 Projekten hat viele Hürden. Ein Problem ist allerdings klar gelöst: Es gibt für jede Ausgangs- und Zielsituation eine Möglichkeit, die Anlagenkonnektivität herzustellen. Daten in einer Anlage zu erfassen oder sie aus einer Steuerung auszulösen ist inzwischen einfach möglich. Hier eine Orientierung in einem unübersichtlichen Feld der Fabrikautomatisierung.
Noch vor einigen Jahren war es nur mit hohem Aufwand möglich, auch nur einfache Signale wie z.B. die produzierten Einheiten aus einer Anlage auszulesen. Anlagen waren geschlossene Systeme und eine Kommunikation nach außen war häufig nicht vorgesehen oder so prohibitiv teuer, dass man als Betreiber davon Abstand genommen hat. Mit dem Aufkommen von Industrie 4.0 und der Erkenntnis, dass das Konzept intensiv datenzentriert ist, hat sich die Lage jedoch grundlegend geändert.
Inzwischen gibt es Hardware- und Softwarelösungen für alte und neue Anlagen, welche die ganze Bandbreite von Use Casen abdecken. Die Lösungslandschaft bleibt aber dennoch unübersichtlich, da eine überschneidungsfreie Sortierung der Konnektivitätskonzepte leider unmöglich ist. Daher hier der Versuch einer vereinfachten Beschreibung von Archetypen, in dem Wissen, das die tatsächliche Vielfalt der Lösungen größer ist, und es jeweils eine genaue Betrachtung von Ausgangssituation und angestrebtem Zielzustand benötigt, um eine langfristige, passende Lösung zu gestalten.
Vier Archetypen für Anlagenkonnektvität
In der folgenden Tabelle sind vier Archetypen der Konnektivität dargestellt, die im weiteren Verlauf detailliert beleuchtet werden:
Archetyp | Beschreibung | Anlagenalter und Voraussetzungen | Mögliche Use Case Komplexität |
---|---|---|---|
Plug-&-Play Retro Fit | Ergänzung von z.B. Stückzahl- oder Schwingungssensoren | Egal, keine Voraussetzungen | Gering bis mittel |
Integrated Retro Fit | Ergänzung eines Industrie PCs oder einer Connector-Box | Egal, SPS muss vorhanden sein | Mittel bis hoch |
Software Layer | Nutzung eines “Data Layers” via Industrial Service Bus | Egal, SPS muss vorhanden sein | Mittel bis sehr hoch |
Control Native | Verfügbarkeit einer neuen Steuerungsgeneration mit OPC UA oder REST API | Nur neue Anlagen | Gering bis sehr hoch |
Plug-&-Play Retro Fit – die schnelle Lösung
Die leichtgewichtigste Form der Konnektivität bezeichnen wir als “Plug-&-Play Retro Fit”. Dabei werden zusätzliche Sensoren in die Anlage eingebracht, die autonom ohne weitere Anlagenintegration agieren. So können z.B. Stückzahlen direkt gezählt oder von Schwingungen abgeleitet werden – die Schwingung kann auch selbst ein relevantes Signal sein. Diese Sensoren sind mit oder ohne kabelgebundener Stromversorgung verfügbar und senden ihre Daten im Regelfall – direkt oder z.B. über eine Mesh-Architektur – zur Weiterverarbeitung in die Cloud. Umsetzbar sind damit Use Case mit geringer bis mittlerer Komplexität. Ein Beispiel für einen einfachen Fall ist die Identifikation, ob eine Anlage betrieben wird oder nicht. Dies kann durch einen vernetzten Schwingungssensor realisiert werden.
Für alle Anlagentypen ist diese Konnektvitätsform jedoch nicht geeignet. Während Schwingungen bei eindeutigen Stückzahlen gut zählbar sind, stößt diese Technologie bei der Produktion von beispielsweise Metern oder einem kontinuierlichen Anlagenbetrieb an ihre Grenzen. Auf der Seite der Vorteile hat diese Integrationsform jedoch ihre Einfachheit, den Verzicht auf den Eingriff in die Anlagensteuerung und teilweise sogar der Verzicht auf eine Stromversorgung zu verbuchen.
Integrated Retro Fit – die flexible Lösung
Der nächste Archetyp wird als “Integrated Retro Fit” beschrieben. Dabei wird eine Windows- oder Linux-Computerhardware über Software-Connectoren mit der SPS der Anlage verbunden. Die Connectoren mappen die Daten aus der SPS auf eine auf dem Computer laufende Software, von wo aus die Konnektivität z.B. in die Cloud hergestellt wird. Der Kommunikationsstandard ist dabei abhängig von der genutzten App. Gängig ist hier beispielsweise MQTT. Da eine direkte Verbindung mit der Anlagensteuerung besteht, kann eine Vielzahl von Signalen ausgelesen werden.
Software-Layer – die anspruchsvolle Lösung
Eine weitere Variante der Anlagenkonnektvität stellt ein Software Data-Layer oberhalb der Steuerungen dar, der je nach Anbieter z.B. als Industrial oder Manufacturing Service Bus bezeichnet wird. Dabei handelt es sich um eine Weiterentwicklung von dem, was in der Vergangenheit als “Middleware” bezeichnet wurde. In dieser Variante werden die SPSen der Anlagen mit dem Data-Layer verbunden und liefern dort ihre Informationen ab. Auf diese Ebener können nun Use Case direkt abgebildet werden – z.B. Echtzeit-Konnektivität zwischen verschiedenen Anlagen – oder es kann als Absprungpunkt zu Cloud-Diensten genutzt werden. Mit dieser Infrastruktur können anspruchsvolle und komplexe Use Case abgebildet werden.
Control Nativ – für neue Anlagen
Die letzte Variante der Konnektivität ist wiederum Hardware-gebundenen und wird als “Control Nativ” bezeichnet. Dabei handelt es sich um neue Generationen von Steuerungen, die direkt, als nativ, eine Konnektivität verbaut haben. Beispiele hierfür sind die OPC-UA oder REST-API Technologie, die in der Anlage implementiert sind.
Hybride verwischen die Ordnung
Schwierig macht das Verständnis der Anlagenkonnektivität, dass die obigen Archetypen nicht immer in ihrer Reinform anzutreffen sind, sondern es vielfältige Hybride gibt. So kann beispielsweise eine OPC-UA-Steuerung an einen beliebigen Industrial Service Bus angebunden werden oder es gibt die Variante, dass eine Steuerung eines bestimmten Herstellers mit einem eigenen Data-Layer verfügbar ist.
Und auch bei Retro Fits gilt es, den Anwendungsfall genau vor Augen zu haben: Schwingungen sind nicht für alle Anwendungsfälle eine ausreichende Information während auch nicht jedes Produkt diskret gezählt werden kann.
Zusammenfassung
Was man zusammenfassend sagen kann: Die Möglichkeiten, Daten – sogar in Echtzeit – aus Anlagen auszulesen, sind vielfältig. Die Preise sind dabei nicht prohibitiv hoch, sondern sogar überraschend gering. Da man als Anlagenbetreiber im Regelfall im Besitz eines heterogenen Anlagenparks bezogen auf Hersteller, Technologie und Alter ist, sollte man die geplanten Use Case vor Augen haben, bevor man sich für eine der Technologien entscheidet. Es handelt sich dabei schließlich um eine Infrastrukturentscheidung, die man nicht so schnell wieder rückgängig machen möchte.
Konnektivität zu oee.ai
oee.ai muss als Manufacturing Intelligence Plattform mit Anlagendaten versorgt werden. Eingangsdatum ist dafür, abhängig vom Datum, im Regelfall eine MQTT-Nachricht oder ein REST API Call. Und diese Nachrichten oder Calls können durch alle vier Konnektivitätsvarianten einfach erzeugt werden. oee.ai ist damit konnektivitäts-agnostisch. Für den diskreten, stückzahl-bezogenen, Anwendungsfall stellt oee.ai die Hardware sogar für einen Proof-of-Value zum Test der Funktionalitäten als Paket zur Verfügung. Mit allen Konnektivitätsvarianten haben wir Erfahrungen. Sprechen Sie uns gerne an.