Die Steuerungslandschaft im Griff
Sie wollen wissen, wie viele Roboter bei Daimler in der Produktion arbeiten – dann müssen Sie schon hinfahren und selber zählen. Der Grund: Die Roboter können im Netz nicht gefunden und gezählt werden, da sie in der Regel nicht angebunden sind. Jeder Tintenstrahldrucker aus dem Discounter für 80 Euro erlaubt das, aber die meisten Industriekomponenten können das heute nicht. Hier liegt enormes Innovationspotenzial brach!“
Diese Aussage von Prof. Rainer Drath, einem renommierten Digitalisierungsexperten der Hochschule Pforzheim, überrascht und ernüchtert zugleich. Wie kann es sein, dass teure Industriegeräte nicht mit Technologien ausgestattet sind, die wir heute im Consumer-Bereich finden? Die Frage lässt sich schnell beantworten: Bislang waren die technischen Voraussetzungen dafür einfach nicht gegeben; zumal im industriellen Umfeld meist heterogene Architekturen zum Einsatz kommen und es bislang nur wenig wirklich übergreifende Standards für unterschiedliche Gerätetypen und Einheiten gibt. Hinzu kommen noch andere Aspekte wie IT-Security und Know-how-Schutz, die hier wesentlich kritischer zu bewerten sind als im privaten Bereich.
Voraussetzungen
Aber der Reihe nach: Welche Voraussetzungen müssten in der Fabrikhalle gegeben sein, um dem Betreiber schnell einen Überblick über die intelligenten Geräte in seinem Netzwerk zu geben?
Das Szenario könnte folgendermaßen aussehen: Sämtliche Steuerungen sind im Firmennetzwerk eingebunden und zugänglich. Das bedeutet, dass alle SPSen, Roboter oder intelligenten Subsysteme entweder direkt über einen Ethernet-Anschluss verfügen oder zumindest über ein entsprechendes Gateway eingebunden werden können. Hier sind wir auf einem guten Weg: Fast jede aktuelle Industriesteuerung wird heute mit mindestens einem Ethernetport ausgeliefert, viele Geräte verfügen sogar über zwei oder mehr Ports u. a. für ethernetbasierte Feldbusanbindungen.
Die nächste Voraussetzung: Softwareschnittstellen für einen einheitlichen Zugriff auf die Steuerungen. Viele unterschiedliche Hersteller mit CODESYS-kompatiblen Systemen verwenden dafür einen speziellen Dienst, den sogenannten CODESYS Gateway. Ursprünglich ist er für die Kommunikation zwischen dem Programmiertool und der Runtime auf dem Gerät verantwortlich. So stellt er wichtige Funktionen zur Verfügung, wie z. B. Scannen des lokalen Netzwerks nach kompatiblen Steuerungen oder Download von Applikationen. Klassischerweise läuft er auf Workstation-PCs unter Windows, der Dienst kann aber auch als Teil des Laufzeitsystems direkt auf den kompatiblen Geräten installiert werden. Entsprechend ausgestattete Steuerungen werden damit zum Router zu anderen Subsystemen mit CODESYS-Laufzeitsystem im Netzwerk. Erweitert man den CODESYS Gateway um gängige Kommunikationsprotokolle für Industrie-4.0-Anwendungen, kann er die Informationen von verbundenen Steuerungen bereitstellen, u. a. für die eingangs erwähnte Übersicht der Geräte im Firmennetzwerk. Faktisch realisiert der Dienst damit das Edge Computing, sprich, er verlagert „Daten und Dienste von zentralen Knoten […] weg zu den äußeren Rändern eines Netzwerks“ (Quelle: Wikipedia: Edge Computing), so dass sie für cloudbasierte Systeme zur Verfügung stehen. Entsprechend ausgestattete Geräte werden somit zum Edge Controller und ermöglichen so die Anwendung von Cloud-Technologien im Bereich der industriellen Fertigung.
Der CODESYS Automation Server: Plattform zur Industrie-4.0-Administration
Stehen die Informationen zur Steuerungslandschaft erst einmal an der „Grenze“ zum Internet bereit, so braucht man noch ein passendes Gegenstück, um die Informationen zu administrieren und für die Verwendung bereitzustellen: eine Serversoftware. Installiert auf einem privaten oder öffentlichen Cloudserver, gibt der CODESYS Automation Server als Industrie-4.0-Plattform eine Übersicht über alle CODESYS-kompatiblen Steuerungen im Netzwerk. Das Edge Gateway baut dafür zunächst die Verbindung zum Server auf, wobei die Kommunikation in jedem Fall verschlüsselt und signiert wird. Das bedeutet, dass sowohl auf der Seite des Servers als auch des Edge-Geräts paarweise Zertifikate benötigt werden, um den gegenseitigen Zugriff zu ermöglichen. Ob der Edge-Dienst auf einer leistungsfähigen SPS oder einem separaten Rechner läuft, spielt für die Funktion keine Rolle. Steht die Verbindung, so legt der CODESYS Automation Server für jedes gefundene Gerät einen sogenannten „digitalen Zwilling“ an, der das physikalische Gerät repräsentiert . Handelt es sich um modulare SPSen, intelligente Antriebe oder Panelsteuerungen? Sind alle Geräte störungsfrei aktiv? Welche Applikationen und Versionen führen sie aus? Darüber hinaus kann der Automation Server Steuerungsdaten lesen oder schreiben, um Gerät oder Applikation für eine ganz bestimmte Aufgabenstellung oder einen speziellen Nutzungsort zu parametrieren. So könnte es sein, dass mehrfach die gleiche Steuerung mit einer identischen Applikation in verschiedenen Anlageneinheiten eingesetzt wird. Ob beispielsweise eine Druckeinheit einer Bogenoffset-Maschine cyan oder schwarz druckt, wird nur durch die Befüllung der Farbe bzw. per IP-Adresse der physikalischen Steuerung festgelegt. Dennoch können einheitenspezifische Parameter relevant sein wie die Farbfeuchte, die sich von Druckeinheit zu Druckeinheit unterscheiden kann. Genauso verhält es sich bei vielen vollkommen identischen Gebäudesteuerungen in einem Geschäftsgebäude: Wo diese Steuerungen eingesetzt werden, d. h. in welchem konkreten Raum oder Stockwerk, oder welche Zusatzaufgaben sie für einen Raum haben, kann durch entsprechende Parameter definiert werden. Ein Inbetriebnehmer kann solche Parameter im CODESYS Automation Server für die Aufgabe vor Ort einstellen - ganz ohne den IEC-61131-3 Quellcode oder das Programmiertool.
Wertschöpfung durch digitale Zwillinge
Welchen Nutzen hat ein Anlagenbetreiber durch solch ein digitales Abbild seiner Steuerungen? Sie nicht mehr zählen zu müssen, sondern automatisch einen vollständigen Überblick zu erhalten, ist für sich schon ein Mehrwert. Aber das ist längst nicht alles! Kennt der Betreiber den Zustand aller eingebundenen Geräte, so kann er auch dann auf den Ausfall einer Steuerung reagieren, wenn die Produktion nicht stoppt oder eine entsprechende Alarmmeldung erzeugt wurde. Fällt beispielsweise die Steuerung für ein Aggregat einer mobilen Maschine aus, dessen Funktion nicht täglich verwendet wird, so sieht dies der Betreiber des Maschinenparks im Automation Server dennoch sofort. Das ist insbesondere dann wertvoll, wenn die entsprechende Maschine irgendwo im Feld im Einsatz ist. Per Topologie-Ansicht lässt sich nämlich nicht nur die Anzahl, sondern auch die Position der jeweiligen Geräte im Netzwerk schnell überblicken. Denn der CODESYS Automation Server kennt alle eingebundenen Steuerungen - im Gegensatz zu handelsüblichen Routern liefert er wirklich nützliche und aussagekräftige Informationen . Nicht nur IP-Adresse werden angezeigt, sondern z. B. auch der aktuelle Softwarestand für jedes Gerät, die jeweils aktive Applikation oder die mit dem Gerät verbundenen Applikations-Parametersätze. So erkennt der Maschinenbetreiber sofort, welche Steuerung mit einem Softwareupdate auf Stand gebracht werden sollte. Aktuell wird oft nach der Devise „Never change a running system“ verfahren, selbst dann, wenn durch ein Update die Funktionalität, Leistung oder der Schutz der Applikation gesteigert werden könnte. Kein Wunder: Meist muss das Wartungspersonal für ein Update direkt vor Ort an der Maschine sein und das Programmiertool physikalisch mit der Steuerung verbinden. Auch hier schafft der CODESYS Automation Server Abhilfe: Sämtliche Steuerungsprojekte lassen sich als sogenannte Bootapplikationen, also als ausführbare Dateien für die jeweilige Geräteplattform, auf dem Server ablegen. Für das irgendwann zwingende Update muss diese Bootapplikation dann lediglich vom Server aus auf das Zielsystem übertragen werden. Der Mehrwert ist dabei enorm, wenn ein Update, wie im oben genannten Fall, auf viele gleichartige Geräten gleichzeitig ausgerollt werden soll. Das Update erfolgt dann von einer zentralen Stelle aus an alle ausgewählten Steuerungen – auf Wunsch auch nachts und automatisch per Skript. Einfacher kann man nicht von Innovationen profitieren, die durch die Applikationssoftware zugänglich sind.
Konkrete Schritte zum Anbinden von Geräten
Was ist zu tun, um Steuerungen über den CODESYS Automation Server verwalten zu können? Zunächst ist ein ausreichend leistungsfähiger Edge Gateway notwendig, der die abgesicherte Verbindung zum Server per HTTPS bzw. TLS aufbaut. Das kann eine performante SPS mit einem CODESYS-Laufzeitsystem im Netzwerk sein oder ein dedizierter Edge Controller, der die Verschlüsselung und Signierung über X.509-Zertifikate vornimmt. Mit einem Download des Projekts auf die Zielsteuerung wird das Gerät dann automatisch im Server registriert. Natürlich lässt sich jede Steuerung auch manuell registrieren, und zwar durch Eingabe einer entsprechenden Geräte-ID oder per Scan eines Barcodes. Ein entsprechendes Plug-in im CODESYS Development System legt eine SPS-Applikation direkt auf dem Automation Server als Bootapplikation ab. Diese kann dann direkt über die Weboberfläche des Servers ausgerollt werden, beispielsweise per Tablet oder Smartphone. In der Symbolkonfiguration des CODESYS Development Systems kann der Anwender in seinem Projekt verschiedene Parametersätze für einzelne Aufgaben wie den Datenaustausch per OPC UA oder Visualisierung konfigurieren. Mit solch einem Datensatz kann er auch genau festlegen, welche Applikationsvariablen als Parameter im Server zur Verfügung stehen und direkt von der Serveroberfläche aus gelesen oder geschrieben werden sollen. Somit kann ein Inbetriebnehmer vor Ort die physikalischen Steuerungen per Browser ihrem eigentlichen Ort und ihrer spezifischen Aufgabe zuweisen. Weil die älteren CODESYS-Geräte der Generation V2 ebenfalls per CODESYS Gateway erfasst werden, können auch sie im Server registriert und verwaltet werden. Allerdings können solche Steuerungen aufgrund der fehlenden Kommunikationsverschlüsselung nicht gleichzeitig als Edge eingesetzt werden.
Ausblick
Funktioniert das alles auch mit Systemen, die nicht mit einem CODESYS-Control-Laufzeitsystem ausgerüstet sind? Wie erwähnt, soll die Geräteadministration unabhängig von Herstellern möglich sein. So beschäftigen sich Gremien wie die PLCopen mit einer herstellerunabhängigen Verwaltungsschale, der vom VDMA propagierten Asset Administration Shell (AAS). Diese Shell soll zwischen den proprietären Geräten und der Industrie-4.0-Infrastruktur vermitteln. Wie Prof. Drath erläutert, spricht sie „nach unten z. B. ‚Boschisch‘‚ ‚ABBisch‘ oder ‚Siemensisch‘“, nach oben aber kommuniziert sie mit den standardisierten Industrie-4.0-Schnittstellen. Noch ist dies Zukunftsmusik, aber bereits heute wird intensiv an der Umsetzung dieser Konzepte gearbeitet.
Ist solch ein Standard erst einmal verfügbar und auf den Geräten etabliert, dann gehört das manuelle Zählen von Industriegeräten wohl endgültig der Vergangenheit an. Industrie 4.0 ist dann einheitlich und durchgängig – auch in heterogenen Netzwerken. Die bereits heute vorhandenen Möglichkeiten, mit der serverbasierten Administration eines Firmennetzwerks die Funktionalität von Automatisierungsgeräten optimal auszuschöpfen, stellen nur den Anfang der Wertschöpfung dar. Viele weitere Chancen deuten sich an. Wir dürfen gespannt sein.
Der Artikel von Roland Wagner, Head of Product Marketing bei der CODESYS Group, wurde in der Computer & Automation 11/2018 veröffentlicht.