 |
| Dieter Hess |
Machen wir uns nichts vor. Die Automatisierungstechnik lebt von Basisprodukten, die ursprünglich für Massenmärkte wie Automotive-Elektronik, Consumer-Elektronik und Personal Computer entwickelt wurden. Dies gilt für praktisch sämtliche verwendete Controller über Bussysteme wie CAN bis hin zu Ethernet mit den darauf implementierten Protokollen. Es war also nur eine Frage der Zeit, bis auch das so erfolgreiche HTTP-Protokoll den Weg in die Automatisierungstechnik finden würde. Verwundert ist man dennoch über die Vielzahl der angebotenen Lösungen, die sich auch in den zahlreichen Beiträgen in diesem Kompendium niederschlagen. Dafür sind im Wesentlichen zwei Gründe denkbar: Entweder ist die Umsetzung für die Automatisierungstechnik sehr einfach, oder aber sie bringt erhebliche Vorteile. Es ist wohl beides der Fall. Ein Webserver, der sich auf einem Gerät befindet, besteht aus wenigen tausend Zeilen und ist gleichzeitig mehrfach frei als Sourcecode im Netz verfügbar. Zum anderen hat man den Vorteil, dass ein Automatisierungsgerät völlig ohne ein installiertes Tool bedient werden kann, da die komplette Applikation zum Bedienen und Parametrieren sich direkt auf dem Gerät befindet. So lässt sich auch der klassische Fehler von unpassenden Tool- und Runtime- Softwareversionen vermeiden. Wie sieht nun in der Praxis der Einsatz von webbasierten Technologien in der Automation aus? Da sind einerseits die Visualisierungen, bei denen der „Web based“-Gedanke offensichtlich ist: Warum sollten die mit entsprechenden Visualisierungseditoren erstellten Masken nicht über einen Internet-Browser dargestellt werden? Diese Software hat heute schließlich jeder PC-Nutzer installiert, in der Windows-Welt sogar zwangsläufig. Um die Daten der Automatisierungsgeräte über das Internet auslesen zu können, sind neben einer eindeutigen IP-Adresse dann nur noch ein Webserver und eine Client-Applikation auf der Hardware erforderlich, etwa in Form eines Java-Applets. Sind die Grafiken selbst, gleichgültig ob vektor- oder pixelorientiert, erst einmal im Browser-Fenster dargestellt, dann holt sich der Runtime-Kernel nur noch die aktuellen Daten für die Animation von der Steuerung. Das mit „www - world wide waiting“ oft scherzhaft angeprangerte Warten auf den Upload der Grafiken ist nur einmalig beim Aufruf erforderlich. Da sind andererseits aber auch die Webtechnologien „unter der Oberfläche“: Es ist sinnvoll, die vorhandene Infrastruktur beispielsweise für die Ablage von Engineering-Daten zu nutzen. Ethernet als physikalisches Medium, TCP/IP bzw. HTTP in der Protokollschicht und XML als Datenformat setzen auf dieselben verteilten Strukturen, wie sie im Internet zu finden sind. Und diese eignen sich hervorragend zur zentralen Verwaltung von IEC61131-3-Bausteinen, Visualisierungsobjekten oder Feldbus-Kon- figurationsdaten. Ob man nun eine Webseite mit Produktinformationen im Internet-Explorer „durchbrowst“ oder eine Automatisierungsdatenbank mit Steuerungsprogrammen im SPS-Programmiersystem - die Technologie ist dieselbe. Hier ist es von Vorteil, dass das HTTP-Protokoll durch Firewalls hindurch betrieben werden kann. Inzwischen findet man auf dem Automatisierungsmarkt eine ganze Reihe unterschiedlicher Produkte und Systeme, die sich die Webtechnologien zu Nutze machen. Manche verschwinden ebenso schnell, wie sie aufgetaucht sind. Denn letztlich entscheidet über die Akzeptanz eines Produkts beim Anwender nicht die Technologie, sondern der Nutzen im praktischen Einsatz. Vollbeitrag als PDF |
| |
|
 |
|