Auf die Schnelle

Das Wesentlliche in 20 Sek.

  • 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?

Der Automation Server wird das zentrale Service-Portal für Codesys-Steuerungen.

Der Automation Server wird das zentrale Service-Portal für Codesys-Steuerungen. Redaktion IEE

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 Desktop-orientierten 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.

Webtechnologien lassen sich ohne Systembrüche nutzen.

Webtechnologien lassen sich ohne Systembrüche nutzen. Redaktion IEE

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.

Den Automation Server gibt es als lokale oder Cloud-Version.

Den Automation Server gibt es als lokale oder Cloud-Version. Redaktion IEE

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.

Welchen Aufwand 3S beim Thema Security für den Codesys Automation Server betrieben hat.

Seite 1 von 212