J. Nickles: "Internet basierter Zugriff auf technische Anlagen"

<BODY> <H1>www.aud24.net : J. Nickles: "Internet basierter Zugriff auf technische Anlagen"</H1> <P> <BR> [<A href="/">www.aud24.net</A>] [<A href="../index.html">back</A>] </P> <TABLE WIDTH=100% BORDER=0 CELLSPACING=0 CELLPADDING=0> <TR> <TD VALIGN=top> <TABLE WIDTH=100% BORDER=0 CELLSPACING=0 CELLPADDING=0> <TR> <TD VALIGN=TOP CLASS=detailBereichRedaktion>Bereich > Redaktion > <B><FONT color="#CC3300">Fachbeiträge</FONT></B></TD> <TD ALIGN=right VALIGN=bottom CLASS=detailDatum>11.12.2000</TD> </TR> </TABLE> </TD> <TD VALIGN=top> </TD> <TD VALIGN=top> </TD> </TR> <TR> <TD VALIGN=top CLASS=detailFirma ID=topSpace>A&D Fachmedien:</TD> <TD VALIGN=top> </TD> <TD VALIGN=top> </TD> </TR> <TR> <TD VALIGN=top CLASS=detailTitel>J. Nickles: "Internet basierter Zugriff auf technische Anlagen"</TD> <TD VALIGN=top> </TD> <TD VALIGN=top> </TD> </TR> <TR> <TD VALIGN=top CLASS=detailSubtitel>Die Internettechnologie ersetzt die traditionellen Lösungen für das Bedienen und Beobachten</TD> <TD VALIGN=top> </TD> <TD VALIGN=top> </TD> </TR> <TR> <TD VALIGN=top> <TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0> <TR> <TD VALIGN=top CLASS=detailContent>Durch ihre weite Verbreitung sind Webbrowser eine ideale generische Oberfläche für das Bedienen und Beobachten von technischen Anlagen. Die Integration der gesamten Bedienschnittstelle in das Gerät birgt Vorteile sowohl für den Benutzer als auch für den Hersteller. Der Einsatz von etablierten Web-Technologien wie HTTP, HTML und Java ersetzt die aufwendige und kostenintensive Erstellung proprietärer Client Software für den Zugriff auf elektronische Geräte. <BR><BR>Einleitung<BR><BR>Die Basiskomponente, die benötigt wird, um ein Gerät Web-fähig zu machen, ist ein sog. HTTP-Server. Dieser Server unterscheidet sich in vielerlei Hinsicht von Standard HTTP-Servern, die im Internet genutzt werden. Eine technische Anlage hat in der Regel knappe Hardware-Ressourcen und Echtzeitanforderungen. Das Design eines Embedded Servers muß diese Restriktionen berücksichtigen.<BR>Eine wesentliche Eigenschaft eines Embedded HTTP-Servers ist die einfache Integration in eine bestehende Software-Umgebung sowie die Unterstützung einer klaren Schnittstelle, um Zustände der Applikation zu überwachen. Die Möglichkeit, die typischen Request/Response Einschränkungen von HTTP-Servern, wie die fehlende Server-seitige Ereignisbehandlung, zu kompensieren, sind ein weiteres Leistungsmerkmal eines Embedded HTTP-Servers. <BR>Der folgende Beitrag vertieft die technischen Besonderheiten von Embedded HTTP-Servern für den Einsatz in technische Anlagen.<BR><BR>Hauptteil<BR><BR>Traditionelle Methoden<BR>Da Embedded Systeme immer leistungsfähiger werden, nimmt auch die Komplexität ihrer Konfiguration und Parametrierung in extremen Maße zu. Eine leicht bedienbare Schnittstelle verlangt jedoch einen Aufwand an Hardware (zum Beispiel Anzahl der Tasten und Anzeigeinstrumente), der heute kaum noch zu akzeptablen Kosten realisiert werden kann. Insbesondere da es sich bei der Konfiguration und Parametrierung einer Anlage um einen Vorgang handelt, der nur sehr selten durchgeführt wird. In der Regel wird deshalb auf Mehrfachbelegung von Tasten (oder ähnliche Konzepte) zurückgegriffen, die eine Bedienung aber unübersichtlich oder gar unmöglich machen.<BR>Um dem zu begegnen, wurden bislang Service-Programme mit meist graphischen Bedienoberflächen entwickelt, die eine intuitive Konfiguration, Parametrierung und Wartung einer komplexen Anlage ermöglichen sollen. Hierbei handelt es sich jedoch um Software, die unabhängig von der Software für die verschiedenen Funktionalitäten der technischen Anlage selbst entwickelt werden muß. Dabei entstehen zusätzliche Kosten, denn die Anlagen-Software muß um die notwendigen Kommunikationsschichten für die Kopplung mit dem Service-Rechner erweitert werden. Zudem muß diese proprietäre Schnittstellen-Software so ausgelegt sein, daß auch remote, zum Beispiel via Modem auf die Anlage zugegriffen werden kann. Wird die Anlagen-Software modifiziert oder erweitert, so muß dafür meist auch die Service-Software erweitert werden. Nicht zu vernachlässigen ist die Logistik für die Verteilung der neuen Service-Software sowie der Installationsaufwand auf den Service-Rechnern. Die Portierung der Service-Software auf alternative Plattformen bedeutet zusätzlichen Aufwand. <BR><BR>Bedienen und Beobachten via WWW<BR>Den Nachteilen der konventionellen Lösungen steht die Internet-Technologie mit einfachen und kostensparenden Alternativen gegenüber. Agiert eine technische Anlage als HTTP-Server, kann mit Standard Web-Browsern auf sie zugegriffen werden. Auf diese Weise erübrigt sich die Bereitstellung und Installation separat entwickelter Software. <BR>Webbrowser sind für alle relevanten Plattformen verfügbar. Nicht selten ist ein Web-Browser sogar schon im Lieferumfang des Betriebssystems enthalten. Eine eigenständige Software-Entwicklung für das Service-Programm und die damit verbundenen Folgekosten entfallen. Versionskonflikte zwischen Service- und Target-Software entstehen also erst gar nicht. Das jeweilige Gerät hält seine Bedieneroberfläche in Form von Web-Seiten immer zum Abruf durch einen Web-Browser bereit und bietet eine intuitive Bedienmöglichkeit seiner komplexen Funktionalität. <BR>Entscheidend beim Vergleich der beiden Konzepte ist jedoch der Wandel in der Programmiertechnik bei der Erstellung der Service-Anwendung. An die Stelle des Programmierers mit GUI-Erfahrung (Graphical User Interface) tritt der Designer von HTML-Seiten. Nicht die Codierung des Service-Programmes bestimmt die Funktion und den Ablauf der Service-Anwendung, sondern die Gestaltung von HTML-Seiten und deren Verknüpfungen untereinander. Ein Beispiel dafür ist die Integration des Benutzerhandbuches in die Service Anwendung. Wo bisher der Programmierer die Funktionserweiterungen realisieren mußte, werden bei der HTML-Technik einfache Hyperlinks zu den entsprechenden HTML-Seiten des Benutzerhandbuches eingebaut. Genauso einfach ist die Integration von Bildern oder Videosequenzen.<BR><BR>Standard HTTP Eigenschaften<BR>Viele Komponenten der konventionellen HTTP-Server sind auch für Embedded Systeme von Nutzen. Zum Beispiel die Unterstützung persistenter HTTP 1.1 konformer Verbindungen; sie beschleunigen die Transferzeit und reduzieren den Protokoll-Overhead. Oder die Unterstützung von Cookies (RFC 2109), um Benutzer-Sessions durch Konfigurationsschritte einer HTML-Bedienschnittstelle nachzuverfolgen oder um Benutzerprofile und Standardeinstellungen auf dem Client zu speichern.<BR>Aber ein Webserver, der in einer technischen Anlage integriert werden soll, muß darüber hinaus den ganz speziellen Anforderungen eines Embedded Systems gerecht werden.<BR>Das oberste Designziel eines Embedded Servers ist Skalierbarkeit und perfekte Integration in das System. Ein Embedded HTTP-Server wird typischerweise in einem Real Time Operating System (RTOS), parallel zur Applikation eingesetzt. Hier kann er single oder multithreaded mit einer festzulegenden Priorität betrieben werden, ohne daß die Applikation in ihrer Performanz beeinträchtigt wird.<BR>In einer Abstraktionsebene müssen alle betriebssystem- und kommunikationsabhängigen Funktionen zusammengefaßt sein. Dieser Operating System Abstraction Layer (OSAL) garantiert eine gute Portierbarkeit auf die unterschiedlichen Betriebssysteme und TCP/IP Kommunikations-Stacks. Für die Konfiguration, die Skalierung und Erweiterbarkeit der Serverfunktionalität muß eine umfangreiche Application Programmers Interface (API) verfügbar sein. Die HTML-Seiten sollten abgelegt werden können, ohne daß ein physikalisches Dateisystem vorhanden ist. Der Kernel des HTTP-Servers stellt alle Funktionalitäten zur Handhabung der Netzwerkverbindung, zur Bearbeitung von HTTP Anfragen (Requests) und zum Starten dedizierte Dienste zur Verfügung.<BR>Zwecks einer guten Skalierbarkeit wird jeder Dienst des Servers als separates Request Processing Module (RPM) angeboten.<BR> <BR>Resource Pool Management<BR>Speziell für Embedded Systeme ist es von Bedeutung, daß der Server ohne dynamische Ressourcen arbeitet, um zum Beispiel eine Fragmentierung des Speichers zu vermeiden.<BR>Das bedeutet, daß alle Ressourcen (Memory, Threads, Semaphoren etc.) vorab festgelegt werden müssen.<BR>Da ein HTTP-Server eher dynamischer Natur ist, muß er zur Beantwortung asynchroner, externer Requests Ressourcen dynamisch zuweisen können. Dieser Widerspruch kann zum Beispiel durch Ressource Pools (Memory und Thread Pools) gelöst werden. Diese werden mit vom Benutzer bestimmbaren Größen eingerichtet. Die dynamischen Ressource Anforderungen werden dann von diesen Pools zur Verfügung gestellt. Gegenüber anderen Applikationen verhält sich der Server statisch. So wird das Echtzeitverhalten des gesamten Systems nicht gestört.<BR><BR>Schnittstelle zur Applikation<BR>Anders als bei gebräuchlichen Internet HTTP-Servern ist es nicht der Hauptzweck eines Embedded HTTP-Servers, statische HTML Seiten bereitzustellen. Die meisten Seiten, die von Embedded Systemen geladen werden, beinhalten dynamische Daten, die von anderen auf dem System laufenden Applikationen generiert werden. Daher kommt der nahtlosen Integration mit Embedded Applikationen zentrale Bedeutung zu.<BR>Eine Symboltabelle des Servers bietet eine typische generische Schnittstelle zwischen der Applikation und dem HTTP-Server, die den geteilten Zugriff auf die Applikationsvariablen erlaubt. Die Variablen werden aus den HTML Seiten und Java Applets über symbolische Namen referenziert. Eine solche Symboltabelle ordnet Symbolen bestimmte Speicheradressen, mit Typ und Längeninformationen zu. Zusätzlich können Symbole mit Lese-, Schreib oder Trigger-Funktionen ausgestattet werden. Die Ausgabe dynamischer Werte an den Browser erfolgt bequem durch den Gebrauch von Server Side Include Funktionen (SSI). Für alle Standard Ausgaben werden SSI Funktionen von dem Embedded Server bereitgestellt.<BR><BR>Dynamische Formulare<BR>Eine Web-basierte Benutzerschnittstelle läßt sich am einfachsten und ressourcensparendsten mit HTML Formularen implementieren. Diese eignen sich für die Darstellung als auch für die Übertragung dynamischer Information. Üblicherweise wird ein CGI-Script (Common Gateway Interface) verwendet, um ein Formular aus Applikationsvariablen zu generieren. Ein weiteres CGI-Skript wird benötigt, um die dem Server unterbreiteten Werte zu analysieren, die betroffenen Variablen zu initialisieren und Aktionen auszuführen.<BR>Dieser Weg ist jedoch sehr fehleranfällig, da zum Beispiel der Zugriff auf die Applikationsvariablen nicht typisiert erfolgt. Dies ist insbesondere in Hinblick auf das Range-Checking von C-Strings von Bedeutung. Ein weiterer Nachteil dieser Methode ist, daß sie das HTML Design und die Skript-Programmierung vermischt. Bei der Entwicklung von Embedded Systemen werden diese Aufgaben von Entwicklern mit unterschiedlichem Fachwissen übernommen: Man braucht einen Programmierer, der Software für das Embedded System entwickelt, und einen HTML-Designer mit Kenntnissen im Design von Bedienschnittstellen. Die durch den CGI-Ansatz erforderliche intensive Kommunikation zwischen den beiden Stellen kann zu Ineffektivität und Fehlern führen. Unter Verwendung einer Symboltabelle läßt sich eine formale Trennung der beiden Aufgaben erreichen. Dynamische Inhalte können in HTML Seiten mit dem SSI Mechanismus eingefügt werden. Die für die Generierung der Formulare erforderlichen SSI-Funktionen werden von dem Emdedded HTTP-Server automatisch ausgeführt. Ebenso werden die vom Browser kommenden Daten der Formulare automatisch von einem Server RPM evaluiert. Die Variablen werden unter Berücksichtigung der in der Symboltabelle gespeicherten Typen- und Längenrestriktionen mit den neuen Werten aktualisiert.<BR><BR>Publish-Subscriber Protokoll<BR>Eine Unzulänglichkeit des Hypertext Transfer Protokolls (HTTP) für die Gerätesteuerung ist das Fehlen einer Server-seitigen Ereignisbehandlung. Gewöhnlich kann nur der Client eine Verbindung zum Server herstellen. Der Server selbst hat keinerlei Möglichkeit, den Client über Ereignisse zu benachrichtigen.<BR>Ein Embedded HTTP-Server sollte deshalb eine Erweiterung anbieten, die es Java-Applets ermöglicht eine Verbindung zum Server herzustellen und dauerhaft aufrechtzuerhalten. Diese Erweiterung besteht aus einem Kommunikationsmodul (RPM) auf der Server-Seite und einer Java Klassenbibliothek als Kommunikations-Komponente für das zu erstellende Applet. Mit diesen zwei Komponenten wird ein Publish-Subscriber Dienst auf Basis einer persistenten Verbindung zur Verfügung gestellt. Damit wird eine ereignisgesteuerte Datenübertragung möglich oder aber auch ein permanentes Daten-Monitoring. Idealerweise ist das Publish-Subscriber Protokoll HTTP 1.1 konform aufgebaut und kann deshalb auch durch Firewalls verwendet werden.<BR>Das Kommunikations-RPM wird wie alle anderen Request Processing Module des HTTP-Servers konfiguriert. Es werden API-Funktionen zur Verfügung gestellt, um Ereignisse applikationsgesteuert dem Applet mitzuteilen. Der Datenaustausch erfolgt über die Symboltabelle. Das RPM übernimmt außerdem die Synchronisation der Symbole, falls das Applet von mehreren Clients angefordert wurde.<BR>Die Java Kommunikationsklassen realisieren auf der Client-Seite die Kommunikation mit dem Live Control RPM und bieten transparenten Zugang zu allen in der Symboltabelle des Servers registrierten Variablen. Für jedes überwachte Symbol wird ein lokales, als Proxy agierendes Javaobjekt eingerichtet. Die Proxies unterstützen eine automatische Konvertierung zwischen den typisierten Javaobjekten und den Symboltypen der in der Symboltabelle registrierten Variablen. Da die Proxy-Objekte eine JavaBeans konforme Schnittstelle implementieren, können diese Komponenten mit Hilfe eines Bean Builder Tools sehr einfach in eine graphische Bedienschnittstelle eingebunden werden.<BR><BR>Zugangskontrolle und gesicherte Kommunikation<BR>Die Zugangskontrolle eines Embedded HTTP-Servers basiert auf getrennten Modulen, die ersetzt oder auf die Bedürfnisse der Anlage zugeschnitten werden können. Es sollten mindestens Standard RPMs bereitgestellt werden, die Sicherheitsmechanismen über Passwörter und IP Adressen unterstützen und einen grundlegenden Schutz gegen unbefugten Zugriff auf Geräteparameter bieten. Um einen weitreichenden Schutz sensibler Daten zu gewährleisten, muß die Möglichkeit zur Integration für weitere Schutzmechanismen wie der im E-Commerce eingesetzte Secure Socket Layer (SSL) gegeben sein [1].<BR><BR>Zusammenfassung<BR><BR>Die Internet-Technologie vereinfacht die Entwicklung von Bediensoftware für den lokalen als auch für den remote Zugriff auf technische Anlagen. Statt Bedien-Software für viele verschiedene Plattformen zu entwickeln und zu pflegen, ist der www-Browser als Standard Software bereits für alle wichtigen Plattformen verfügbar. Der durchschnittliche Computernutzer ist mit dem Umgang der Software vertraut. Die WWW-Technologie ist als Standard auch für technische Anlagen anwendbar. Die speziellen Anforderungen dieser Systeme werden von Embedded HTTP-Servern berücksichtigt.<BR>Die derzeitigen technischen Einschränkungen von HTML und HTTP können durch Java-Applets umgangen werden, die im Browser Interaktion unterstützen und via einer &bdquo;Live Control“-Verbindung mit einem Embedded HTTP-Server kommunizieren. Durch den Einsatz einiger JavaBeans konformen Kommunikationsklassen ist selbst ein interaktives GUI Design mit Hilfe visueller Application Builder möglich.<BR>Für die Zukunft wird erwartet, daß mehr und mehr Netzwerkgeräte web-fähig sein werden. Im nächsten Schritt werden Geräte, die bisher ihr eigenes Bedienpanel hatten, sich nur durch eine gemeinsame Schnittstelle auszeichnen, über welche diese remote bedient werden können. Auf diese Weise werden wir auf alle Geräte unseres tägliche Lebens zu jederzeit von überall her mittels einer geeigneten Benutzerschnittstelle im vertrautem Look & Feel zugreifen können. Die Schnittstelle wird wahrscheinlich das WWW oder dessen Nachfolger sein.<BR></TD> </TR> <TR> <TD CLASS=detailQuelle> </TD> </TR> </TABLE> </TD> <TD WIDTH=28 VALIGN=top><IMG NAME="" SRC=/pi/spacer.gif WIDTH=1 HEIGHT=1 ALT=""></TD> <TD WIDTH=174 VALIGN=top></TD> </TR> <TR> <TD VALIGN=top><IMG NAME="" SRC=/pi/spacer.gif WIDTH=393 HEIGHT=1 ALT=""></TD> <TD WIDTH=28 VALIGN=top><IMG NAME="" SRC=/pi/spacer.gif WIDTH=28 HEIGHT=1 ALT=""></TD> <TD WIDTH=174 VALIGN=top><IMG NAME="" SRC=/pi/spacer.gif WIDTH=174 HEIGHT=1 ALT=""></TD> </TR> </TABLE> <P><I>Diese Seite wurde am 22.09.2006, 13:54 Uhr aktualisiert</I></P> </BODY>