Mehr Transparenz und Security: Interview mit Dieter Hess und Manfred Werner, CODESYS Group

Mitte Mai ließen Manfred Werner und Dieter Hess auf dem ersten CODESYS Technology Day die rund 400 Teilnehmer aufhorchen: Sie skizzierten den Status des CODESYS Automation Servers, der zentralen Komponente der kommenden Automatisierungsarchitektur von CODESYS.

Das Interview wurde von Stefan Kuppinger geführt. Es erschien in der Ausgabe 07/18 der IEE.

Auf die Schnelle - Das Wesentliche in 20 Sekunden:

  • CODESYS Automation Server bringt Transparenz in die Steuerungslandschaft
  • Webbasiertes Tool ermöglicht SW-Backups und Downloads
  • Zentrale Instanz für Security- Patches und Firmware-Updates des Maschinenparks
  • Kompatibel mit Codesys V3 und V2 (mit Abstrichen)
  • Anbindung von Fremdsteuerungen vorgesehen
  • Webbasierte Programmierung folgt sukzessive

Herr Hess, Herr Werner, sie machen so kurz nach dem Technology Day einen entspannten Eindruck. Wie fällt denn ihr Resümee aus?

Manfred Werner: Wir freuen uns, dass so viele Leute gekommen sind. Es ist nicht selbstverständlich, dass sich 400 Leute auf den Weg nach Kempten ins Allgäu machen. Offensichtlich haben wir mit unseren Themen einen Nerv getroffen.

CODESYS ist ja nicht irgendein Engineeringsystem. Dementsprechend sind die Automatisierer sicher neugierig, wenn es einen Ausblick auf die kommende Technologieversion 4 von CODESYS gibt.

Manfred Werner: Die aktuelle Version ist CODESYS 3.5 – und diese Version werden wir noch sehr lange weiterführen. Um neue Basiskonzepte wie Webtechnologien zu nutzen, braucht es keine Version 4.0. Eine komplett neue Version würde ja in der Regel mit Kompatibilitätsbrüchen einhergehen. Darauf können wir in diesem Fall verzichten.

Sind Webtechnologien eine Anforderung aus dem Markt? Und was verstehen Sie konkret darunter?

Manfred Werner: Die neuen Möglichkeiten des CODESYS Automation Servers, über den wir später noch sprechen, werden vom Markt gefordert. Dasselbe gilt für eine erweiterte Bedienung über Webtechnologien. Unsere Webvisualisierung haben wir bereits seit fünf Jahren etabliert. Sie erfährt nun eine deutliche Erweiterung, unter anderem um HTML 5. Auch Webelemente anderer Anbieter können künftig eingebunden werden.

Dieter Hess: Das gesamte User Interface des Automation Servers ist als Web-Interface ausgeführt. In Zukunft wird sich auch das Engineering in Richtung Webtechnologie entwickeln. Für ein etabliertes System ist das ein neuartiger Ansatz mit vielen handfesten Vorteilen.

Skizzieren Sie doch bitte diese Vorteile.

Manfred Werner: Eine Steuerung über Webtechnologien zu programmieren, hat erhebliche Vorteile, bei der Projektierung, Archivierung und Wartung; ebenso für geplante Erweiterungen. Denn es handelt sich ja nicht nur um eine Implementierungstechnologie. Der Einsatz von Webtechnologien ermöglicht auch neue interessante Use Cases, etwa kleine Änderungen oder Umverdrahtungen per Tablet.
Und wir sehen die Chance, diese Web-Programmierung ohne einen Technologiebruch zum bisherigen desktoporientierten Engineering zu realisieren. Erste Entwicklungen in diese Richtung haben wir bereits gestartet und auf dem Technology Day vorgestellt.

Wie sehen die ersten Schritte aus?

Dieter Hess: Als erste Komponente haben wir einen Topologie-Editor konzipiert, der sowohl auf dem Desktop in CODESYS läuft, als auch abgesetzt als Webeditor. So können wir nach und nach weitere Editoren aus CODESYS herausziehen und als Webeditoren für Browser anbieten. Das ist der Weg, den wir langfristig einschlagen wollen – ohne Systembruch, einfach als Option. Die Vorteile einer zentralen Plattform für CODESYS-Steuerungen, die uns der Automation Server bieten wird, greifen aber bereits viel früher. Allein die Vorstellung, ein zentrales Tool zu haben, das alle Steuerungen einer Anlage registriert, verwaltet und über das ich Updates und Datensicherungen fahren kann, birgt enorme Einsparungspotenziale.

Der Technology Day war also der Auftakt zum Migrationsprojekt CODESYS-Desktop zu CODESYS Web?

Manfred Werner: Das ist nur ein Aspekt, der erst in einigen Jahren richtig zum Tragen kommt. Viel entscheidender ist das Thema Administration der Steuerungslandschaft, das wir mit dem CODESYS Automation Server abdecken. Der wird neben dem Engineeringtool und der CODESYS Runtime künftig die dritte Säule unseres Produktportfolios bilden. Über diesen Server lassen sich künftig alle Geräte vernetzen, die mit CODESYS programmiert werden, Dienste auf all diesen Geräten gleichzeitig ausführen, Updates installieren, Backups nach einem Gerätetausch aufspielen oder auch Live-Daten zentral sammeln und für andere Cloud-Dienste bereitstellen.
Als absolutes Muss sehen wir natürlich Security. Wenn die Steuerungswelt sich in Richtung Cloud und Internet of Things öffnen soll, dann geht das nicht ohne umfassende und in der Praxis anwendbare Sicherheitsmaßnahmen. Wir investieren daher viel in das Thema.

Dieter Hess: Bei dem Automation Server geht es übrigens nicht primär um das Engineering. Den Server kann man sich vielmehr als Verwaltungsschale vorstellen, um Steuerungen im Netz bequem verwalten und administrieren zu können. Und das funktioniert auch bei V2-Steuerungen. Unser langfristiges Ziel ist es, dass ein Programmdownload künftig auch für Fremdgeräte funktioniert, aber sicherlich nicht in dem Umfang, wie wir es mit CODESYS-kompatiblen Geräten realisieren können.

Inwieweit haben Sie Ihre Anwender bei diesem strategischen Projekt eingebunden?

Dieter Hess: Wir reden oft und intensiv mit unseren Kunden um herauszufinden, welche Anforderungen sie in der Zukunft sehen. Den Server haben wir aber aus eigenem Antrieb entwickelt. Dabei hatten wir die CODESYS-Anwender im Blick, die eine herstellerunabhängige Lösung bevorzugen, weil sie in der Regel viele Maschinen mit Steuerungen unterschiedlicher Hersteller in ihrer Produktion im Einsatz haben.

Können OEMs den CODESYS Automation Server ebenfalls als eigene Lösung labeln, so wie bei den SPS-Runtimes?

Manfred Werner: Bei den Anfängen von CODESYS, als die großen Brandlabeling-Produkte entstanden sind, da war unsere Plattform noch nicht rund. Das muss man einfach sagen. Daher mussten die Unternehmen verschiedene Funktionen dazu bauen.Deswegen ist es aus meiner Sicht schon legitim, dass diese Tools eigene Namen bekommen haben. Beim Automation Server wird das aber nicht mehr notwendig sein, da er von Anfang an ein rundes Paket sein wird.

Dieter Hess: Der Automation Server richtet sich an Betreiber von Steuerungen. Dass die alle von ein und demselben Hersteller kommen, wäre eher untypisch. Daher macht Brandlabeling dort im Gegensatz zum CODESYS Development System keinen Sinn. Geplant ist allerdings ein Partnerprogramm, in dessen Rahmen Drittanbieter oder auch OEMs eigene Funktionen für den Automation Server anbieten können.

Wann begannen die konzeptionellen Überlegungen?

Manfred Werner: Mit ersten Skizzen haben wir vor etwa drei Jahren begonnen.

Wenn die Webprogrammierung ansteht, welche Sprachen werden als erstes zur Verfügung stehen?

Manfred Werner: Beim CODESYS Automation Server liegt in den nächsten zwei bis drei Jahren der Fokus nicht auf der Webprogrammierbarkeit, sondern auf dem Gerätemanagement. Die Webability ist erst der zweite Schritt.

Dieter Hess: Ein typischer Anwendungsfall des Gerätemanagements ist etwa Backup Restore. Man hat eine Maschine, die läuft 15 Jahre wunderbar, bis irgendwann die Steuerung ausfällt. Was machen die Automatisierer heute? Sie müssen meist zuerst einen alten Laptop suchen mit dem passenden Programmiersystem. Und dann muss man irgendwie an das Ablaufprogramm kommen und die Maschine wieder zum Laufen bringen. Das alles braucht Zeit, die keiner mehr hat.
Über den Automation Server ist das in fünf Minuten erledigt, da er alles zentral vorhält: die passende Softwareversion, das Ablaufprogramm und alle Informationen über die SPS-Hardware. Im Server ist hinterlegt welche Steuerung notwendig ist. Nach dem Hardware-Tausch wird die im Server gesicherte Applikation auf die neue Hardware aufgespielt. Das ist ein typischer Fall, der sich momentan nicht so schnell und einfach lösen lässt.

Manfred Werner: Ein anderes Beispiel sind Security-Updates. Auf der Weboberfläche des Automation Servers sieht man sofort, welcher Roboter oder welche Maschine mit welcher Steuerungsversion ausgerüstet ist und welches Securitypatch aufgespielt wurde. Bei Bedarf kann man gleich reagieren.

Voraussetzung ist, dass alle Maschinen und Steuerungen am Netz hängen. Wie sieht denn die Realität bei den Endkunden aus?

Dieter Hess: Da sprechen Sie einen wichtigen Punkt an. Nicht alle Endkunden wollen oder können Ihre Anwendungen ans Netz anbinden. Deshalb haben wir uns nach reiflicher Überlegung entschlossen, den Automation Server in zwei Varianten anzubieten: als Cloudservice und als lokale Installation. Bei der Cloud-Version müssen alle Geräte am Internet hängen. Wer das nicht will, weil er Bedenken hat, Daten in die Cloud zu spielen, kann den Automation Server auf einem eigenen Server in seiner Fabrik installieren und lokal betreiben.

Deswegen auch der Aufwand hinsichtlich Security. Was haben Sie in der Hinsicht alles getan?

Manfred Werner: Generell richten wir uns nach einschlägigen Standards wie der IEC 62443. Bei den einzelnen Maßnahmen müssen wir unterscheiden. Es gibt die Security-Maßnahmen, für die wir als Lieferant der Entwicklungsumgebung und des Automation Servers verantwortlich sind, und zusätzliche IT-Security-Maßnahmen seitens des Betreibers. Wenn wir einen Cloudanbieter nutzen – wir werden hier mit Amazon und Microsoft zusammenarbeiten – dann setzen wir auf die Sicherheitsmechanismen dieser Anbieter auf. Sie werden dafür Sorge tragen, dass die Daten nicht verloren gehen oder manipuliert werden können. Diese Anbieter sind die größten Cloud-Provider der Welt, die in punkto Datensicherheit auf dem neuesten Stand der Technik sind.
Natürlich müssen auch Sicherheitsvorkehrungen für die Steuerung an sich getroffen werden. In der Factory sind die Geräte in einem relativ geschützten Bereich installiert. Dass in diesem Umfeld eine Steuerung direkt, also ohne Firewall oder ähnliches, mit dem Internet verbunden ist, passiert nicht oft. Bei dezentralen Installationen wie Windrädern, Pumpstationen oder Gebäuden ist es schon üblicher, dass ein Gerät direkt mit dem Internet verbunden ist. Daher haben wir viel investiert, um die Kommunikation mit dem Gerät zu verschlüsseln und den Passwortmechanismus zu verbessern. Und wir arbeiten daran, dass sich die Firmware leichter updaten lässt, wenn eine Security-Lücke entdeckt wird. Dieter Hess: Für die Zukunft stellen wir uns vor, dass die Runtime einer Steuerung in zwei Teile getrennt ist, in einen Securityrelevanten Teil und das sonstige System. Dann können wir Securitypatches einspielen, wie etwa bei Windows, jedoch bei laufendem Betrieb.

Ohne den Run-Stop-Schalter zu betätigen?

Dieter Hess: Das ist das Ziel. Denn in der Praxis reagieren die Anwender fast gar nicht auf Security-Vorfälle. Dabei stellen wir nach einem Sicherheitshinweis unseren Kunden zeitnah einen Patch zur Verfügung, der die Lücke schließt.

Was macht der Anwender damit?

Dieter Hess: Auf dem Technology Day haben wir genau diese Frage gestellt: Ob denn jemand schon einmal ein Update auf sein Runtimesystem aufgespielt hat, nachdem er von uns einen Sicherheitshinweis bekommen hat.

Und?

Dieter Hess: Die Antwort war ernüchternd: kein einziger!

Manfred Werner: Über den Automation Server wollen wir Anwender informieren, dass für Ihr Gerät mit einem bestimmten Firmware-Stand ein Patch vorliegt. Stimmt er zu, wird das Update automatisch eingespielt, bei Bedarf vielleicht auch zeitgesteuert, um eine Produktionspause oder einen Produktwechsel abzuwarten.

In einer Fabrik gibt es nie immer nur einen Steuerungstyp. Wie bilden Sie solche heterogenen Maschinenparks ab?

Manfred Werner: Wir rechnen damit, dass es auch fürs Engineering weitergehende Schnittstellen geben wird, so wie OPC UA. OPC UA ist ja ein Standard, der herstellerübergreifend ist und einen Datenaustausch über Herstellergrenzen hinweg erlaubt. Bei der PLCopen gibt es im Moment eine Arbeitsgruppe, die an einer Automation Administrative Shell arbeitet. Ziel ist, über OPC UA standardisierte Meta-Informationen bis hin zu Funktionsbausteinen aus der Steuerung auszulesen.

Wird 3S den Automation Server selbst betreiben?

Manfred Werner: Mit Sicherheit nicht. Vor drei Jahren hätte ich die Frage noch anders beantwortet. Aber wir sehen, dass es extrem aufwendig ist, eine Serverlandschaft mit vielen Anwendern zu betreiben. Es gibt einige große Firmen, die anfangs eine Cloud betrieben haben und dann doch zu Amazon oder Microsoft gegangen sind. Wenn sich weitere Serviceprovider in Deutschland oder Europa durchsetzen, dann ist es für uns ein Einfaches, unseren Automation Server dahin zu portieren. Das ist dann ein kleiner Schritt.

Es war ja auch die Rede davon, dass der Automation Server letztendlich auch als Datensammelstelle fungiert, also für Betriebsdaten. Wie weit ist das fortgeschritten?

Dieter Hess: Das lässt sich weitgehend bei der Applikationserstellung in CODESYS realisieren. Auf dem Technology Day haben wir das für Amazon Web Services und Microsoft Azure gezeigt. Dass das langfristig auch unser Server erledigt, ist ein wünschenswertes Ziel, und wir werden das auch anbieten.

Welche Interfaces unterstützen Sie für die Cloudanbindung?

Dieter Hess: MQTT ist im CODESYS Store verfügbar. Darüber können Anwender mit Microsoft Azure und AWS kommunizieren. Und über das Web-Client-Protokoll, das ebenfalls im Store erhältlich ist, können wir uns mit Clouds wie Thingspeak von Mathworks oder auch mit Alibaba verbinden. Daneben implementieren wir sukzessive weitere, offene standardisierte Protokolle wie OPC Pub/Sub.

Was für ein Zeithorizont schwebt Ihnen bei den verschiedenen Themen vor?

Manfred Werner: Dieses Jahr wird der Automation Server in der Stufe 1 freigegeben, das heißt dann mit Funktionen wie Applikations-Update und Gerätetausch. Backup-Restore und Security- Update des Runtimes folgen später. Bis das komplette CODESYS vollständig im Web laufen wird, wird es schon noch einige Jahre dauern. Erste Dienste wie der Topologie-Editor sind natürlich wesentlich früher verfügbar.

Also man kann davon ausgehen, dass der nächste große Wurf zur SPS IPC Drives kommt?

Manfred Werner: So ist es. In Nürnberg können die Besucher des CODESYS-Stands den Automation Server live ausprobieren.

Ganzer Artikel als PDF zum Download: Mehr Transparenz und Security