Bei der Entwicklung hatten wir die Betreiber und Maschinenbauer im Blick.

Bei der Entwicklung hatten wir die Betreiber und Maschinenbauer im Blick. Redaktion IEE

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 Security-relevanten 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 abzuwarten.

Bei der Entwicklung hatten wir die Betreiber und Maschinenbauer im Blick. Redaktoin IEE

Security-Updates werden auch im laufenden Betrieb möglich sein. Redaktion IEE

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.

Zentrales Gerätemanagement sorgt für mehr Effizienz. Redaktion IEE

Zentrales Gerätemanagement sorgt für mehr Effizienz. Redaktion IEE

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.

Das Interview führte Stefan Kuppinger

Seite 2 von 212