Das ICS@Cloud-System (ICS = Industrial Control System) erlaubt auf sehr einfache Art und Weise die nachträgliche Aufrüstung beliebiger Sensoren und Steuerungen in der OT-Ebene (OT = Operational Technology) sowohl mit einer OPC UA-Schnittstelle als auch einer hochsicheren Cloud-Anbindung. Dies ermöglicht auch vollständige Daten-Retrofit-Lösungen für Maschinen- und Anlagen mittels nicht-invasiver Sensorik.
Ein ICS@Cloud-System besteht aus einem Gateway (z. B. aus der IGW/9xx-Familie), optionalen I/O-Baugruppen mit Sensorschnittstellen, einer modularen Datenfluss-Laufzeit- und Konfigurationsumgebung sowie dem sog. Remote Deployment Service (RDS).
Durch die integrierte Datenfluss-Software Node-RED, die per Internet mit beliebigen Steuerungs-, Sensor- und Cloud-Treibern an die individuellen Bedürfnisse angepasst werden kann, existiert in Richtung Cloud eine bisher unerreichte Flexibilität.
Dadurch werden Abhängigkeiten von einer bestimmten Cloud-Plattform vermieden und Redundanzkonzepte ermöglicht (z. B. die gleichzeitige Verbindung zu mehr als einer Cloud).
ICS@Cloud unterstützt sowohl die horizontale als auch die vertikale Vernetzung durch flexible Kommunikations- und Datenschnittstellen. Die dabei zum Einsatz kommende Datenflusstechnik bietet deutlich weiterreichende Möglichkeiten und einen höheren Abstraktionsgrad als IEC61131-Lösungen.
Abb. 1: Schematische Darstellung eines ICS@Cloud-Systems
Auf Grund der nahezu unüberschaubaren Vielfalt an Cloud- und IoT-Plattformen und der damit einhergehenden Problematik bzgl. voneinander abweichender Protokoll-, Daten- und IT-Security-Vorgaben durch den jeweiligen Plattformbetreiber wurde der Remote Deployment Service entwickelt.
Diese Fernzugriffsschnittstelle für unsere Experten entlastet den Anwender von den komplexen Protokoll-, Security- und Datendetails anspruchsvoller Digitalisierungslösungen.
Das bedeutet in der Praxis, dass der Anwender eines ICS@Cloud-Systems sich einfach einen passenden Cloud-Anbieter sucht, das Gateway vor Ort installiert, die Sensoren und Steuerungen verbindet und den RDS-Zugriff autorisiert.
Danach schaltet sich ein SSV-Experte per VPN gesichert auf das Gateway, konfiguriert die Datenflussumgebung vom Sensor bis zur Cloud und erstellt auf Wunsch ein XML-basiertes Informationsmodell der Datenpunkte in der OT-Ebene.
Ein ICS@Cloud-System ermöglicht datenbasierte Lösungen in der Automatisierung, die dem aktuellen Stand der IT-Technik entsprechen, ohne unternehmensintern komplexe Projekte aufsetzen und qualifiziertes Personal einstellen zu müssen.
Die Anwendungsbandbreite reicht dabei von der klassischen Zustandsvisualisierung über OPC UA-basierte IT-Anbindungen (MES/ERP/CRM) bis hin zum Einsatz hochkomplexer Machine-Learning-Algorithmen, die in Cloud- und IoT-Plattformen als Services angeboten werden.
Dadurch lassen sich Predictive Analytics-Anwendungen, wie bspw. Predictive Maintenance, Predictive Quality oder Energieeffizienzoptimierungen per Machine Learning realisieren.
Das ICS@Cloud-System bietet dem Anwender eine flexible, zukunftssichere und vor allem Update-fähige Datenschnittstelle für die OT-Ebene.
Im Zusammenspiel mit dem Remote Deployment Service wird ICS@Cloud besonders beim zukünftigen Einsatz von Künstlicher Intelligenz im Umfeld von Maschinen und Anlagen seinen vollen Nutzen entfalten können.
Inflexible Edge-Gateway-Alternativen mit einer festen Cloudanbieter-Anbindung können bereits in wenigen Jahren wegen des sog. "Vendor-Lock-in" zum Kostenproblem werden.
Durch einen im ICS@Cloud-Gateway integrierten OPC UA-Client lassen sich Datenpunkte externer OPC UA-Server einbeziehen.
Der OPC UA-Client wird innerhalb der Datenfluss-Laufzeitumgebung konfiguriert und ausgeführt.
Auf die per OPC UA erhaltenen Daten lassen sich anschließend die gleichen Berechnungen und Signalbewertungen anwenden, wie sie zuvor für die Sensoren beschrieben wurden.
Das Gateway kann auf verschiedene Datenpunkte in einer Steuerung zugreifen und zyklisch auslesen, z. B. als Modbus-Master oder RFC1006-Client (ISO-on-TCP-Client).
Alternativ ist auch eine passive Rolle denkbar – das Gateway ist in diesem Fall aus Sicht der SPS bspw. ein Profinet- oder Modbus-Slave.
In einem solchen Szenario bestimmt allerdings die Steuerung, wann und wie oft jeweils neue Werte übergeben werden.
Sensoren verbinden sich mit dem Gateway je nach Schnittstelle direkt oder über eine Digitalisierungsstufe bzw. Schnittstellenkonvertierung.
Die Signalaufbereitung erfolgt in der Regel im Gateway. Dafür bietet die Datenfluss-Umgebung umfangreiche Funktionen, die einfache Berechnungen, digitale Filterfunktionen bis hin zu Spektralanalysen (FFT) und anspruchsvollen Signalbewertungen (z. B. Sensordatenfusion, Clusterbildung, Klassifizierung, Mustererkennung und Ereignisvorhersage) ermöglichen.
Jede Cloud-Verbindung erhält jeweils ein X.509-Zertifikat mit eigener PKI und kann per REST oder MQTT erfolgen. Die erlaubten Datenformate werden üblicherweise durch die Cloud- bzw. IoT-Plattform vorgegeben.
Da REST und MQTT datenagnostisch sind, ist es möglich, die Daten in jedem Format zu übertragen. Die Anpassung der Datenformate der OPC UA-, SPS- und Sensoreingänge erfolgt innerhalb der Datenfluss-Umgebung.
Alle Eingangsdaten sowie die durch Berechnungen und Verknüpfungen gewonnenen zusätzlichen Datenelemente lassen sich über den im Gateway installierten OPC UA-Server anderen Anwendungen zur Verfügung stellen.
Der OPC UA-Server sowie die einzelnen Verknüpfungen mit den jeweiligen Datenpunkten werden vollständig innerhalb der Datenfluss-Umgebung konfiguriert.
Viele Datenanalyse-Plattformen, die typischerweise für Data-Science-Aufgaben benutzt werden, erwarten CSV-Dateien als Dateneingangsformat.
Daher bietet ein ICS@Cloud-Gateway auch eine spezielle HTTPS-GET-Schnittstelle.
Diese Schnittstelle ermöglicht einer Data-Science-Anwendung den Abruf der gewünschten Daten im CSV-Format.
Ein typischer ICS@Cloud-Anwendungsfall wäre ein Produktionsbetrieb mit drei Standorten in unterschiedlichen Ländern, der drei Maschinen gleichen Typs per Daten-Retrofit mit der Cumulocity-Cloud verbinden will, um zum Beispiel automatisch Anomalien zu erkennen.
Des Weiteren soll eine OEE (Overall Equipment Effectiveness) für jede einzelne Maschine gebildet werden, um die Standorte und Schichten besser miteinander vergleichen zu können.
Aus Sicht der Cumulocity-Cloud sind die dafür erforderlichen Sensoren in einem Sensor Network zusammengefasst (siehe linken Bereich in Abbildung 2).
Dieses Sensor Network ist (südseitig) an einen Agenten gekoppelt, der per REST-API (REST = REpresentational State Transfer, spezielle Software-Schnittstelle, die das HTTP(S)-Protokoll nutzt) in nördlicher Richtung mit der Cumulocity-Cloud kommuniziert.
Abb. 2: ICS@Cloud in Verbindung mit der Cloud-Plattform Cumulocity
Alle Sensoren an einer Maschine werden aus der Cumulocity-Perspektive zu einem Device Object (Device) zusammengefasst. Für den Agenten sind in der Cumulocity-Welt in diesem Anwendungsbeispiel drei Aufgabenbereiche vorgesehen:
In Richtung Cloud erfolgt eine HTTPS-basierte Kommunikation per REST. Als Datenformat für die HTTPS-Payload kommt JSON zum Einsatz.
Zur Anbindung der Sensoren existieren unterschiedlichste Protokolle und Datenformate. Der Agent muss daher alle Sensordaten im Push- oder Poll-Betrieb ein- bzw. auslesen, in das passende JSON-Format umwandeln und per HTTPS-Request an die Cloud senden. Dabei muss er zwischen Konfigurations-, Messwert-, Alarm- und Ereignisdaten differenzieren, die jeweils andere Request-Formate benötigen.
Für alle Devices und die Sensoren eines Devices werden in der Cloud spezielle Namen und Einheiten (z. B. kWh) als Cumulocity-spezifisches Modell angelegt.
In einem einzelnen Sensorelement sind die jeweiligen Rohdaten aber in einem völlig anderen Modell oder mit anderen Einheiten (z. B. Spannung U und Strom I) präsent.
Die Anpassung der Datenmodelle und das Umrechnen der Einheiten erfolgt daher ebenfalls durch den Agenten.
Ein Agent kann sich innerhalb der Cloud oder direkt in nächster Nähe zum Sensor Network befinden. Für dieses Beispiel gehen wir vom zweiten Fall aus.
Hier muss der Agent die HTTPS-Übertragung der Sensordaten zur Cloud mit einer dem Stand der Technik entsprechenden Security absichern. Daher sollte sich diese Funktion des Agenten über OTA (Over-the-Air) Remote Updates auch an sich verändernde Sicherheitsanforderungen anpassen lassen können.
In einer ICS@Cloud-Lösung bildet ein SSV-Gateway den Agenten zwischen Sensor Network und Cumulocity-REST-API (siehe rechten Bereich in Abbildung 2). Das Gateway ist daher für die drei Aufgaben „Protokolle übersetzen, Datenmodelle anpassen und Kommunikation zur Cloud sichern“ zuständig.
Die Cumulocity-REST-API ist in verschiedene Bereiche unterteilt. Die Messwerte eines Sensors werden z. B. per Measurement API an die Cloud übermittelt. Für Ereignismeldungen ist die Event API zuständig und Alarme werden mit Hilfe der Alarm API zur Cloud übertragen.
Abb. 3: Schematische Darstellung der Node-RED-Datenflussumgebung
Die Übersetzung der unterschiedlichen Protokolle zwischen Sensoren und Cloud sowie das Anpassen der Datenmodelle erfolgen auf dem Gateway mit Hilfe der integrierten Datenflussumgebung Node-RED.
Für die Security in Richtung Cloud sind auf einem SSV-Gateway der IGW/9xx-Familie keine zusätzlichen Erweiterungen oder Anpassungen erforderlich, da sowohl HTTPS als auch der VPN-Betrieb zum Standardfunktionsumfang gehören.
SSV Software Systems GmbH
Dünenweg 5
30419 Hannover
Fon: +49(0)511 · 40 000-0
Fax: +49(0)511 · 40 000-40
Impressum · Datenschutz · AGB
© 2024 SSV SOFTWARE SYSTEMS GmbH. Alle Rechte vorbehalten.
ISO 9001:2015
