Schon wenige Jahre nach der Erfindung des World Wide Web und des HTTP-Protokolls wurden die ersten Webbasierten Bedieneroberflächen im industriellen Einsatz (HMI) implementiert. Der Client-Server-Ansatz und die Modularität sowie die Offenheit der Technologie boten von Anfang an eine überaus interessante technologische Plattform. In der Folge hat sich dieses Konzept in der Industrie weitgehend durchgesetzt. Webseiten auf Firmenportalen und industrielle HMIs müssen jedoch unterschiedlichen Anforderungen genügen, und so hat sich von Anfang an die Frage gestellt, welche Technologie sowohl Internet-kompatibel als auch dafür geeignet ist, animierte Prozessbilder und dergleichen mit guter Performance zu ermöglichen. Die Anforderungen der Automation kann man sicherlich nicht auf einen einzigen gemeinsamen Nenner bringen. Dennoch kann man einige grundsätzliche Punkte finden, die für fast alle Anwendungen in diesem Bereich Gültigkeit haben. 1. Industrielle HMI sind immer animiert, das heißt sie müssen den Bildaufbau selbst- ständig und regelmäßig dem aktuellen Prozessbild anpassen. Im Gegensatz dazu sind typische Webseiten Benutzer-getriggert, das heißt auf eine User-Interaktion wird das HMI entsprechend geändert. 2. Das Gros der Anwendungen soll mit einem einfach beherrschbaren, rein grafischen Werkzeug entwickelt werden, um Kosten bei der Entwicklung und der Wartung zu sparen. Die meisten Anwender möchten sich nicht zu tief mit spezifischen Programmiersprachen beschäftigen, sondern sind darauf angewiesen, effizient und kostenorientiert zu arbeiten. 3. Die Lebensdauer einer industriellen Applikation beträgt typisch zehn bis 20 Jahre, was deutlich über der Lebenserwartung der meisten IT-Projekte liegt. Kleine Geschichte der Web-Technologien Die ersten Tools für Web-basierte, industrielle Viusalisierungen verwendeten zur Erfüllung obiger Anforderungen häufig Java Applets oder ActiveX-Komponenten. ActiveX wird mittlerweile eher selten verwendet, weil die entsprechenden Plug-Ins einerseits nur auf Microsoft-Win32-Betriebssystemen und in Microsoft-Produkten, sprich Internet Explorer, funktionieren, andererseits bietet diese Technologie keinerlei Schutzkonzept vor bösartigem Code, weshalb die Verwendung von ActiveX von vielen Firmen strikt unterbunden wird. Außerdem gibt es Lösungen, die Java Script verwenden, anstelle des compilierten Java Applets. Java Script hat prinzipiell ähnliche Möglichkeiten wie compiliertes Java und wird insbesondere auf kommerziellen Web-Sites im Internet gerne verwendet, weil es für die Realisierung von einfachen Aufgaben, die über die Möglichkeiten von rein darstellenden Sprachen wie HTML hinausgehen, eine schlanke und effiziente Ergänzung bietet. Compilierte Java Applets hingegen erfordern für die Ausführung immer zuerst den Start der Virtual Machine, was sie für diese Aufgabenstellung als eher schwerfällig erscheinen lässt. Will man jedoch Java Script dazu einsetzen, um eine umfangreiche Bibliothek mit den typischen Automationsobjekten zu erstellen, kehrt sich das Verhältnis zum compilierten Java genau um. Weil das Script nun recht groß geworden ist, kann die Applet-Variante den Overhead des Startens der Virtual Machine dank des kompakteren und viel schnelleren compilierten Codes längst wieder herausfahren. Rein Java-Script-basierte HMI-Tools haben sich daher nie richtig etablieren können. Aktuelle Lösungen In der letzten Zeit tauchen vermehrt Lösungen auf, die auf eine Kombination einer vektororientierten Seitenbeschreibungssprache zusammen mit einem Script zur Ausführung von logischen Funktionen sowie der Kommunikation mit dem Web-Server setzen. Der Vorteil dieser offenen, Script-basierten Lösungen liegt darin, dass sie relativ einfach mit bestehenden Entwicklungswerkzeugen wie VisualStudio, Eclipse oder Illustrator kombiniert und mit eigenen Elementen und Symbolen ergänzt werden können. In typischen Web-Anwendungen auf dem Internet hat sich in den letzten Jahren eine Unterteilung der Aufgaben in einen rein grafischen und einen logischen Teil entwickelt. Der Hintergrund dazu ist der, dass die Gestaltung der Web-Site durch professionelle Grafiker erfolgt, und dass diese nicht nur (wie früher) Style Guides über die durch die Programmierer umzusetzenden Funktionen vorgeben, sondern die grafischen Elemente und auch deren dynamisches Verhalten mit den geeigneten Werkzeugen gleich selber gestalten können. Die Programmierer implementieren danach das gewünschte logische Verhalten der durch die Grafiker vorgegebenen Controls, das heißt implementieren die verschiedenen Methoden, die durch das Control verwendet werden. Somit gibt es einerseits ein Werkzeug für die grafische Gestaltung, das das gewünschte optische Verhalten von Objekten modellieren und diese in einer vektororientierten Form exportieren kann, andererseits gibt es die eher klassische Programmierumgebung, wo z.B. mit Java-Script-Elementen dann der Unterbau codiert wird. Diese Zweiteilung der Aufgaben eignet sich im Prinzip gut für den Aufbau eines ausbaufähigen Frameworks, das die Scada-Grundfunktionen bietet und durch den Benutzer projektspezifisch erweitert werden kann. Die im Internet aktuell am meisten genutzte Technologie ist wohl \’Flash\‘ des Herstellers Adobe. \’Flash\‘ erfordert zwar ein Plug-In im Browser, dieses ist aber für viele Plattformen verfügbar. Da Adobe im Bereich der grafischen Gestaltung eine starke Position im Markt hat, ist dadurch auch die Flash-Technologie relativ weit verbreitet und gut abgestützt. Microsoft hat in Konkurrenz dazu das Plug-In Silverlight und den darunterliegenden, offen publizierten XAML-Standard vorgestellt. Das Unternehmen kann traditionell auf eine gewisse Gemeinde von Entwicklern zählen. Silverlight braucht im Allgemeinen auch ein Plug-In, das aber auch auf Linux verfügbar ist. SVG (Scalable Vector Graphics) basiert auf einer XML-Syntax und ist vom World Wide Web Consortium im Jahr 2001 vorgeschlagener Standard, der in Kombination mit Java Script verwendet werden kann. SVG ist ein herstellerneutraler Standard, hat dafür aber eben auch den Nachteil, dass keiner der großen Player im Markt den Standard aktiv voranbringt. Im Bereich dieser vorgängig beschriebenen, konkurrierenden Technologien hat sich mittelerweile so etwas wie ein Glaubenskrieg entfacht, welches denn nun eine echte Web-Technologie sei und welcher davon die Zukunft gehört. Es ist klar, dass alle diese Technologien sich in einem sehr schnelllebigen Markt befinden, der sich nicht primär an den Bedürfnissen der Automation orientiert. Hier wird teilweise mit harten Bandagen um die Vorherrschaft im Internet gekämpft. Liest man beispielsweise die Nutzungsbedingungen für die Entwicklerlizenz des iPhones, wird einem klar, auf welche Restriktionen man sich teilweise einlassen muss und mit welch rüden Methoden mittlerweile gekämpft wird, denn auf dieser Plattform darf man nichts entwickeln, was Apple nicht genehm ist. Langzeitverfügbarkeit von Web-Technologien Die Diskussion um die richtige technologische Basis einer Scada-Applikation lenkt leider von einem für die meisten Anwender sehr wichtigen Anforderung ab, nämlich der Lebenserwartung einer Technologie. Die Frage, wie lange man eine selbstentwickelte Software im Markt einsetzen kann, bis diese nicht mehr unterstützt wird, war für die Automation schon von großer Bedeutung. Bei bisherigen Projekten musste man sich an der Verfügbarkeit von kompatiblen Entwicklungswerkzeugen und Betriebssystemen orientieren. Für Web-basierte Scadas gilt dies immer noch, es kommt aber noch dazu, dass man auch die technologische Entwicklung der Browser berücksichtigen muss. Während man früher den Einsatz der Betriebssysteme innerhalb einer eigenen Anlage relativ gut kontrollieren konnte, gibt es mit dem Browser nun eine Vielzahl von Rechnern, auf denen man kaum mehr über einen längeren Zeitraum eine bestimmte Softwarekonfiguration voraussetzen kann. Man denke hier nur an den Fernzugriff mittels externer Rechner oder an den Einsatz von Smartphones. Die Gefahr einer Überalterung einer eigenen SW-Applikation und damit der Verlust der getätigten Investitionen wird im Zeitalter des WWW nicht geringer, sondern verschärft sich in einer nicht zu unterschätzenden Weise. Unter diesem Aspekt scheint es vernünftig, sich die Frage zu stellen, wie dieses Problem am besten gelöst werden kann. Tatsächlich muss man nicht weit suchen. Die Geschichte der SPS zeigt uns, wie man es richtig machen sollte. SPS-Programme sind portabel auf den verschiedensten Betriebssystemen und Prozessoren einsetzbar, und ein IEC61131- oder Step7- Programm kann daher mit großer Wahrscheinlichkeit auch in zehn oder sogar 20 Jahren auf einer dann gebräuchlichen Hardware verwendet werden. Warum ist das so? Die SPS-Hersteller haben auf ihrer Steuerung eine zusätzliche Abstraktionsschicht implementiert, die den eigentlichen Steuerungscode vom Mikroprozessor und vom Betriebssystem trennt. Der SPS-Hersteller übernimmt es, diesen Abstraktionslayer jeweils auf seine neuen Steuerungen zu übernehmen, damit die Software-Investitionen seiner Kunden geschützt sind. Genau dasselbe Konzept sollte man auch für die Entwicklung der HMIs berücksichtigen. Sicherlich ist es verlockend, auch in einer Scada-Applikation mit den neuesten Entwicklungstools schnell noch ein paar Funktionen hinzucodieren zu können. Die langfristigen Kostenfolgen können aber bei vielen Anwendungen erheblich werden. Eine Scada-Toolchain sollte daher genau dasselbe Konzept wie die SPS-Programmierung verfolgen und die eigenen Grafikobjekte über einen Abstraktionslayer von der jeweiligen Visulisierungstechnologie trennen. Dieselbe Funktion, die der Mikroprozessor und sein Maschinencode für ein IEC61131-Programm hat, wird in einer Scada-Applikation durch die Software-Stacks von Java, Flash, Silverlight oder SVG wahrgenommen. Dieselbe Bedeutung, die der einzelne Opcode für die Steuerung hat, hat eine grafische Anweisung wie das Zeichnen einer Linie, eines Kreises oder von Text für die Scada-Applikation. Niemand käme heute mehr auf die Idee, eine Steuerung in Assembler zu programmieren, auch wenn man so die beste Performance erreicht. Aus demselben Grund sollte ein Scada-Paket die damit erstellten Projekte vom Opcode der darunterliegenden Grafikengine trennen. Die Frage, ob die Scada-Applikation Java-, Silverlight- oder SVG-basiert ist, ist für den Anwender sekundär. Sollte die von der Scada-Lösung verwendete Technologie irgendwann obsolet werden, so kann der Hersteller einfach eine Runtime mit einem Abstraktionslayer auf die zu diesem Zeitpunkt aktuelle Technologie anbieten, und der Kunde kann seine Applikationen ohne Probleme und ohne Änderungen weiterverwenden.
iniNet Solutions GmbH
