Webmail zum Lesen von E-Mails ist seit langem akzeptiert. ERP-Systeme haben Browser-Schnittstellen. Und Google hat uns gezeigt, wie sogar typische Office-Anwendungen in der Cloud verfügbar sind. Auch in der Automatisierung verbreiten sich Web-Anwendungen, allerdings vor allem in den Bereichen Maintenance und HMI. Nicht zuletzt sind Buzzwords wie Web 2.0 – inzwischen etwas in die Jahre gekommen – oder Industrie 4.0 in aller Munde. Nur beim Engineering ist alles anders: Automatisierer möchten scheinbar nach wie vor Software auf ihrem PC installieren und Dongles mit sich herumschleppen.

Was die SPS-Programmierung betrifft, ist heute die IEC 61131 der Standard. Die Programmiersprachen sind normiert und bedarfsgerecht definiert. Entwicklungsumgebungen unterschiedlicher Hersteller buhlen um die Anwender. Die verschiedenen Systeme implementieren die IEC 61131-3 unterschiedlich und jeder Hersteller legt seinen Fokus auf andere Features der Norm. Aber egal, wo der Fokus liegt – kleine oder große Projekte, textuelle Sprachen wie AWL und ST oder grafische Sprachen wie FBD, KOP und SFC – alle haben eins gemeinsam: Die Entwicklungsumgebung und alles was dazugehört laufen immer auf einem PC. Ob dieser unter Windows oder Linux läuft – oder sogar Apples MacOS unterstützt wird –, eine echte Endgeräte-Unabhängigkeit ist bis heute nicht gegeben. So manches System unterstützt zwar das Arbeiten im Netzwerk, aber von Industrie 4.0 im eigentlichen Sinne ist noch wenig erkennbar.

Wie kann oder sollte vor diesem Hintergrund ein neuer Weg in der SPS-Programmierung aussehen?

Cross-Plattform-Kompatibilität lautet das Schlagwort

Im 21. Jahrhundert wollen die wenigsten Anwender darüber diskutieren, welcher Computertyp oder welches Betriebssystem unterstützt wird. Und nachdem sich Smartphones und Tablets allen Unkenrufen zum Trotz in den letzten Jahren durchgesetzt haben, soll auch mit diesen Geräten automatisiert werden. Cross-Plattform-Kompatibilität ist demnach das Schlagwort, das zumindest im Office-Bereich bereits immer mehr umgesetzt wird. So ist es für uns mittlerweile  Normalität, E-Mails und Dokumente am PC im Büro genauso zu bearbeiten wie am Notebook in der Besprechung oder zwischendurch am Smartphone. Und wie selbstverständlich zeigen uns Firmen wie Apple, wie sich die Daten von beliebigen Geräten aus gemeinsam nutzen lassen – allerdings nur, solange es sich um Geräte von Apple handelt. Diverse "Brückenlösungen" für andere Systeme gibt es zwar, werden meist aber stiefmütterlich behandelt.

Beispiel für ein "Google Drive Spreadsheet": In der Bedienung fast nicht von Microsoft Excel zu unterscheiden.

© qmd4

Nicht wenige Software-Produkte großer Unternehmen gibt es in Versionen für Windows, Linux oder Apples Mac-OS beziehungsweise – im Fall der Apps – für iOS und Android. Allerdings sind sie oftmals vom Versionsstand und vom Funktionsumfang sehr unterschiedlich. Und ein Produkt für verschiedene Betriebssysteme und/oder Geräte zu pflegen, erfordert einen nicht unbeträchtlichen Aufwand. Die Folge ist, dass meist nur die Mainstream-Plattform wirklich gut unterstützt wird. Und immer noch ist die Software auf den unterschiedlichen Geräten zu installieren und jeder muss sich wieder Gedanken machen, wie das eigene Smartphone und der PC auf ein und dieselben Daten zugreifen können.

In letzter Zeit begegnen uns Software-Produkte, die diesen Problemen auf eine ganz andere Art und Weise begegnen: Sie laufen im Webbrowser. Denn spätestens seit HTML5 gibt es ausreichend Möglichkeiten, ansprechende Anwendungen auch für den Browser zur Verfügung zu stellen. Löste früher eine Web-Applikation zwar die großen Probleme der Plattform-Unabhängigkeit und des Datenaustauschs, so handelte es sich dabei oft um lieblos wirkende Ansammlungen von  HTML-Seiten, die noch dazu sehr träge auf Benutzereingaben reagierten.

Dass es auch anders geht, haben wir von Google gelernt. Schon 2005 gab es eine erste Version von "Google Drive", damals noch unter dem Namen "Writely" bekannt und kurze Zeit später auch unter "Google Spreadsheets" (Gears). Writely war eine vollständige im Webbrowser laufende Textverarbeitung mit all dem Komfort und Features, die man vorher nur von herkömmlichen PC- oder Mac-Programmen kannte. Echtes WYSIWYG (what you see is what you get), eine Microsoft Word ähnelnde Bedienung und eine hervorragende Performance überraschten viele Anwender und zeigten schon damals, was eine Web-Anwendung möglich macht. Die Dokumente wurden bei Google abgespeichert und der Zugriff war anfangs nur Online möglich. Aber egal von welchem Ort der Welt aus – mit einer Internetverbindung und einem halbwegs modernen Webbrowser konnte man die Software vollständig nutzen.

Zugegeben: Ob die Daten bei Google sicher abgelegt sind oder ob die Dokumente seit damals jedem zugänglich sind, darüber lässt sich streiten. Denn so angenehm es auch ist, die Daten immer und überall verfügbar zu haben: Ein solcher Ansatz wirft unweigerlich Fragen nach der Verwundbarkeit und den Schwächen eines solchen Systems auf.

Automatisieren à la Google Drive

Die meisten SPS-Programmierumgebungen unterscheiden heute nicht zwischen den Anwendern, die ständig mit der Software arbeiten, und denen, die immer nur kurz kleine Aufgaben damit erledigen. Auch unterscheidet sich die Komplexität diverser Anwendungen massiv, unter anderem im Hinblick auf die benötigte Mächtigkeit des Entwicklungssystems. Wünschenswert wäre, diesbezüglich ein Tailoring des Programmiersystems für unterschiedliche Anwendungen durchführen zu können. Das heißt: Der Anwender wird nur mit den Funktionen konfrontiert, die tatsächlich für die benötigte Aufgabe beziehungsweise die verwendete SPS gebraucht werden und eventuell sogar mit einer vorgefertigten Projekt- und/oder Hardware-Konfiguration. Damit kann der Anwender sofort einsteigen und hat eine flache Lernkurve, die den aktuellen Anforderungen entspricht. Daneben steht für komplexere Systeme oder erfahrene Anwender trotzdem die volle Leistungsfähigkeit des Entwicklungssystems zur Verfügung.

Nicht zu vergessen sind die Wartungsaufgaben für die ­Lebensdauer des Systems, wie das Einspielen und Testen von Updates beziehungsweise das Beheben von Inkompatibili­täten von "alten" Projekten mit neuen Produktversionen oder auch die Zusammenarbeit an Projekten innerhalb eines ­Projektteams.

Ist die Security der Daten sichergestellt, könnte eine Anwendung auf einer Basis wie das jetzige Google Drive für die SPS-Programmierung durchaus ein zukunftsfähiger Ansatz sein – unabhängig vom Gerät, vom Betriebssystem und vor allem ohne langwierige Installation und Konfiguration! Ist dies nicht etwas, das wir uns schon lange wünschen?

Neben Funktionsplan (FBD) und Ablaufsprache (AS) unterstützt die Programmiersoftware auch die textuelle Programmiersprache ST, hier zu sehen im Firefox-Browser auf einem Windows 7 PC.

© qmd4

Das Konzept hinter dieser Idee: Je nach Anforderungen läuft die Anwendung auf dem Cloud-Server des Steuerungsherstellers oder auf einem eigenen Arbeitsgruppenserver im lokalen Netz. Spätestens mit dem Arbeitsgruppen-Server ist selbst das Thema Datenschutz vom Tisch beziehungsweise reduziert sich auf die Probleme, die auch beim Arbeiten im normalen Office-Umfeld bestehen. Ist die Hardware der Steuerung ausreichend leistungsfähig, um einen Webserver zu betreiben, kann dieser ebenso als „Cloud-Server“ eingesetzt werden.

Bei einer Web-Anwendung ist es nicht nötig, die einzelnen Arbeitsplatzrechner der Automatisierer entsprechend "up to date" zu halten. Hier wird nur der zentrale Server – je nach Konfiguration sogar der beim SPS-Hersteller stehende Applikationsserver – gewartet. Das heißt: Er wird nur einmal getestet, nur einmal aktualisiert und alle arbeiten wieder mit derselben Softwareversion.

Ist ein altes Projekt zu bearbeiten und möchte man den Umstieg auf eine neue Version der Programmierumgebung nicht riskieren, so können bei ent­sprechender Trennung der verwendeten Ressourcen (zum Beispiel Scripts, ­Datenbank oder Programme) auf dem  Server mehrere Versionen derselben ­Programmiersoftware zum quasi gleichzeitigen Zugriff gespeichert werden. Das heißt, dass auch für den Fall der Änderung einer Automatisierungslösung mit genau demselben Softwarestand weitergearbeitet werden kann, mit dem die Lösung anfangs erstellt worden ist. Zwar kann es sein, dass dabei neue Funktionen oder neuer Komfort außen vor bleiben; andererseits werden dadurch aber auch garantiert keine neuen Fehler provoziert, die erst durch ein Software-Update auftreten.

Wie bereits zuvor angesprochen, sind Web-Anwendungen für Probleme hinsichtlich Datenschutz- und -sicherung anfälliger als traditionelle Applikationen. Dies gilt aber nur, wenn die entsprechenden Serversysteme von außen ebenfalls erreichbar sind. Mit denselben Problemen ist allerdings jeder von uns in anderen Bereichen ständig konfrontiert und dort werden die eingesetzten Sicherungsmaßnahmen als ausreichend erachtet: Die Rede ist vom Online-Banking. Die verwendeten Maßnahmen zur Absicherung der Kommunikationsverbindung – zumeist SSL – gelten generell als sicher. Unsicher ist hier meist der „Faktor Mensch“, der Passwörter notiert, das Telefon für die Pin-Eingabe beim Online-Banking achtlos liegenlässt oder auf gefälschten Login-Seiten trotz Warnung des Browsers Benutzername und Passwörter eingibt.

Wer jedoch den Sicherungsmethoden nach dem heutigen Stand der Technik nicht vertraut, hat immer noch die Op-tion, sowohl Entwicklungsumgebung als auch Daten (SPS-Programme) gesichert auf dem eigenen Server im lokalen Netzwerk abzulegen, sofern dies vom Programmiersystem unterstützt wird.

Vom Wunsch zur Realität

Bearbeitung eines Funktionsplans mit dem Apple-eigenen Safari-Browser auf einem Macbook.

© qmd4

Mit „q4Logix“ bringt das junge österreichische Unternehmen qmd4 zur SPS IPC Drives 2014 eine erste Umsetzung der geschilderten Zukunftsvision auf den Markt. Dabei handelt es sich um eine HTML5-Anwendung ohne Kompromisse – sprich kein Java oder .NET. Das bedeutet freie Wahl des Browsers – egal ob Microsoft Internet Explorer, Mozilla Firefox, Google Chrome oder Apple Safari sowie die entsprechenden Mobilderivate – und das ohne spezielle Plug-ins. Freie Wahl hat der Programmierer zudem beim Endgerät: egal ob nun Windows PC, Linux Workstation, Macbook, Android Tablet oder iPhone.

Die neuartige Programmierumgebung ist ein "Tailoring" der in Entwicklung befindlichen, vollen IEC-61131-Entwicklungsumgebung "q4Prog" und bietet bereits einen vollgrafischen Funktionsplan-Editor nach IEC 61131-3, der auf dem PC mit Maus und Tastatur oder auf dem mobilen Gerät mit Gesten beziehungsweise Touch-Eingabe bedienbar ist. Der zugehörige Server wird entweder vom SPS-Anbieter gehostet, was ein sofortiges Starten mit der Programmierung ermöglicht, sobald die SPS ausgepackt und in Betrieb genommen ist. Alternativ lässt sich die Server-Software auf einem Arbeitsgruppenserver oder sogar auf der Workstation des Automatisierers betreiben. Auf größeren SPS-Systemen mit eigenem Webserver kann die Programmierumgebung auch direkt von der Steuerung geladen und ausgeführt werden. Hier ist es ebenfalls so, dass mehrere Versionen der Software quasi gleichzeitig verfügbar sind. Diese werden von unterschiedlichen "Pfaden" (URLs) vom Server oder aber von unterschiedlichen Servern geladen.

Die Speicherung der Daten erfolgt immer auf dem Datenserver. Bei abgeschlossenen Einzelplatzsystemen ist dies meist die SPS selbst. Auf der Workstation des Automatisierers wird nur dann etwas gespeichert, wenn explizit der Server dort installiert worden ist. Konzipiert ist q4Logix letztlich als ­einfach zu erlernendes System für Anwendungen, bei denen nur die SPS-­Programme auf oberster Ebene mit ­einem voll normkonformen Funktionsplan für die Programmierung erstellt werden. Das Erstellen eigener Bausteine und die Verwendung weiterer Programmiersprachen – wie AS (Ablaufsteuerung) oder ST (Strukturierter Text)  – ist dann dem „großen Bruder“ q4Prog ­vorbehalten.

Die zugehörige Laufzeit-Umgebung (q4PLC) ist so konzipiert, dass eine einfache Portierung auf Kleinsysteme (16-bit- oder 32-bit-Controller ohne Betriebssystem) und auch auf Systeme mit Echtzeit-Betriebssystem möglich ist. Derzeit werden neben ARM-Cortex-M3/M4-basierten Systemen ohne Betriebssystem beziehungsweise mit Free-scale MQX oder FreeRTOS auch Ein- und Mehrkernsysteme mit ARM, PowerPC und x86-basierten CPUs unter Linux, Windows CE, VxWorks, OS-9 und zudem Windows unterstützt. Der von q4Logix erzeugte Code wird interpretativ abgearbeitet. Bei q4Prog steht die Interpreter-Code-Generierung weiterhin zur Verfügung, üblicherweise wird allerdings aus Performance-Gründen auf native Code-Generierung gesetzt (Maschinensprache der CPU). Abhängig vom Timer-Interrupt der SPS wird üblicherweise eine Zykluszeit in Millisekunden-Schritten vergeben. Durch die native Code-Generierung bei q4Prog ist der Cloud-Ansatz für große Applikationen ebenso gut geeignet wie die üblichen PC-basierten Programmierumgebungen. Durch einen entsprechend ausgestatteten Webservers lässt sich der Durchsatz bei der Code-Generierung zudem signifikant optimieren.

Autor: Thomas Baier ist Geschäftsführer von qmd4, Krems (Österreich).