Erweiterung einer flexiblen Objektstruktur für die Kommunikation mit Datenservern um Möglichkeiten zur Fernalarmierung

Inhaltsverzeichnis

1. EINLEITUNG

2. EINORDNUNG DER ARBEIT
2.1.ALLGEMEINE BESCHREIBUNG (ISTZUSTAND)
2.1.1.XVCML
2.1.1.1.VISUALISIERUNGSKOMPONENTEN
2.1.1.2.FUNKTIONSKOMPONENTEN
2.1.1.3.KOMPONENTE SERVERCONNECTION
2.1.1.4.ARBEITSWEISE DER PROZESSVISUALISIERUNG
2.1.2.PROZESSDATENSERVER ZUR LAUFZEIT
2.2.AUFGABENSTELLUNG/ SOLLZUSTAND
2.2.1.FUNKTIONALE ANFORDERUNGEN
2.2.2.ANFORDERUNGEN AN DIE SYSTEMTECHNIK
2.2.3.RANDBEDINGUNGEN, NICHT FUNKTIONALE ANFORDERUNGEN
2.2.4.QUALITÄTSMERKMALE

3. FERNALARMIERUNG
3.1.EINLEITUNG
3.2.PRAKTISCHER EINSATZ
3.3.E-MAIL
3.3.1.ABLAUF DER KOMMUNIKATION
3.3.2.ZUVERLÄSSIGKEIT DER NACHRICHTENÜBERTRAGUNG
3.4.SMS
3.4.1.ABLAUF DER KOMMUNIKATION
3.4.2.ZUVERLÄSSIGKEIT DER NACHRICHTENÜBERTRAGUNG
3.5.MOBILFUNKANRUF
3.5.1.ABLAUF DER KOMMUNIKATION
3.5.2.ZUVERLÄSSIGKEIT DER NACHRICHTENÜBERTRAGUNG
3.6.DIENSTKOMBINATIONEN
3.6.1.E-MAIL TO SMS
3.6.2.SMS TO E-MAIL
3.6.3.DIREKTER KONTAKT ZUR SMSC

4. DARSTELLUNGSPRINZIPIEN FÜR MOBILE DISPLAYS
4.1.EINLEITUNG
4.2.GRUNDLAGEN
4.3.SPEZIELLE PROBLEME MOBILER GERÄTE
4.4.FOLGEN
4.5.SPEZIELLE KRITERIEN FÜR MOBILE GERÄTE
4.6.NAVIGATIONSPARADIGMEN

5. SYSTEMENTWURF
5.1.EINLEITUNG
5.2.VORBETRACHTUNGEN
5.2.1.MASTERWS
5.2.2.FERNALARMIERUNG
5.2.3.ALARM-MODELL
5.3.ENTWURFSZEIT
5.3.1.ANWENDUNGSFALLDIAGRAMM
5.3.2.ANWENDUNGSFÄLLE
5.3.3.LÖSUNGSENTWURF
5.3.3.1.SERVERSEITEIGER ENTWURF
5.3.3.2.CLIENTSEITIGER ENTWURF
5.4.LAUFZEIT
5.4.1.ANWENDUNGSFALLDIAGRAMM
5.4.2.ANWENDUNGSFÄLLE
5.4.3.BESCHREIBUNG AUSGEWÄHLTER ANWENDUNGSFÄLLE
5.4.3.1.PROZESS ÜBERWACHEN
5.4.3.2.ALARM WEITERLEITEN
5.4.3.3.ALARMSTATUS ANPASSEN
5.4.4.LÖSUNGSENTWURF
5.4.4.1.SERVER - MASTERWS
5.4.4.2.CLIENT - MOBILE ANWENDUNG
5.4.4.3.OBERFLÄCHENENTWURF
5.5.ZUSAMMENFASSUNG
5.5.1.SERVERSEITIGE KOMPONENTEN
5.5.2.CLIENTSEITIGE KOMPONENTEN

6. IMPLEMENTIERUNG
6.1.ENTWURFSZEIT
6.1.1.ALARM-MODELL
6.1.2.SERVER-KONFIGURATION
6.1.3.CLIENT-REGISTRIERUNG
6.1.4.KOMPONENTE SERVERCONNECTION
6.2.LAUFZEIT
6.2.1.SERVERSEITIGE PROZESSÜBERWACHUNG
6.2.1.1.ALARMWEITERLEITUNG
6.2.1.2.ANRUF-BIBLIOTHEK JDUN
6.2.1.3.E-MAIL WEITERLEITUNG
6.2.2.CLIENT-REGISTRIERUNG
6.2.3.KOMPONENTE SERVERCONNECTION
6.2.4.KOMPONENTE VISUALISIERUNG

7. AUSWERTUNG
7.1.SERVER-ANWENDUNG
7.2.CLIENT-ANWENDUNG

8. ZUSAMMENFASSUNG UND AUSBLICK

9. ABBILDUNGSVERZEICHNIS

10. LITERATURVERZEICHNIS

11. ANHANG
11.1.A2-1 WSDL DATEI DES VERWENDETEN WEBSERVICE „MASTERWS“
11.2.A5-1 UMTS VERFÜGBARKEIT IN DEUTSCHLAND
11.3.A6-1 XSL TRANSFORMATIONSVORSCHRIFT DER SERVER KONFIGURATIONSDATEI
11.4.A6-2 XML CODIERTE SERVER-KONFIGURATIONSDATEI ALS TRANSFORMATIONSERGEBNIS
11.5.A6-3 VOLLSTÄNDIGE XSL TRANSFORMATIONSVROSCHRIFT DER REGISTRIERUNGSKLASSE
11.6.A6-4 VOLLSTÄNDIGE XSL TRANSFORMATIONSVORSCHRIFT DER SERVER- KOMMUNIKATIONS-KLASSEN
11.7.A6-5 VOLLSTÄNDIGE XSL TRANSFORMATIONSVORSCHRIFT DER KLASSE WEBSERVICECOMMUNICATION
11.8.A6-6 XSL TRANSFORMATIONSVORSCHRIFT DER KLASSE WEBSERVICEEVENTS
11.9.A6-7 XSL TRANSFORMATIONSVORSCHRIFT DER KLASSE WEBSERVICEEVENTARGS
11.10.A6-8 TRANSFORMIERTER C# CODE DES INTERFACE IREGISTRATION
11.11.6-9 TRANSFORMIERTER C# CODE FÜR DIE REGISTRIERUNG ANKOMMENDER ALARME PER ANRUF
11.12.A6-10 TRANSFORMIERTER C# CODE FÜR DIE REGISTRIERUNG ANKOMMENDER ALARME VIA E-MAIL
11.13.A6-11 TRANSFORMIERTER C# CODE DER KOMMUNIKATIONSKLASSE

Erweiterung einer flexiblen Objektstruktur für die Kommunikation mit Datenservern um Möglichkeiten zur Fernalarmierung

Kurzfassung

Das Institut für Automatisierungstechnik der Technischen Universität Dresden hat auf der Ba- sis eines speziellen XML Dialektes ein Verfahren entwickelt mit dem es möglich ist Prozessvi- sualisierungen technologieunabhängig zu beschreiben und automatisiert in die gewünschte Zieltechnologie zu transformieren. Dabei wurden Transformationsvorschriften für HTML und SVG umgesetzt, so dass ein clientseitiges Steuern über einen beliebigen Web-Browser möglich ist.

Ziel dieser Arbeit ist es, dieses System mit Transformationsvorschriften für Windows Mobile basierte Geräte zu erweitern, so dass der Prozess des Beobachtens und Bedienens über ein mobiles Gerät möglich wird, wobei ein serverseitiges Fern-Alarmsystem den üblichen clientseitigen Polling-Betrieb ersetzen soll.

Abbildung in dieser Leseprobe nicht enthalten

Bei der Analyse industriell verbreiteter Methoden zur Fernalarmierung, wurden die Möglich- keiten E-Mail, SMS und Anruf genauer untersucht und miteinander verglichen. Ebenso war eine intensive Recherche über Darstellungsmöglichkeiten auf mobilen Displays ein wichtiger Teil dieser Arbeit, welcher letztendlich auch großen Einfluss auf die prototypische Umsetzung der Benutzeroberfläche zum Bedienen und Beobachten einer Kleinversuchsanlage hatte.

Insgesamt konnte diese Arbeit den Einsatz mobiler Geräte zur Prozessüberwachung und der Behandlung von Alarmen als zuverlässig einstufen. Dies wurde mit einer prototypischen Implementierung nachgewiesen.

Abbildung in dieser Leseprobe nicht enthalten

Extension of a flexible object based data server communication structure with remote alerting features

Abstract

Based on a specific XML-dialect, a procedure was developed at the Institute of Automation at the Technical University of Dresden, to describe process visualization independent from tech- nology and to automatically transform this into target technology. These transformation rules for HTML and SVG have been implemented, so that client-control by any web browser is pos- sible.

The aim of this work is to extend this system with some transformation rules for Windows Mobile powered devices, to observe and operate an industrial process by mobile devices. Server remote alarm system will replace the usual client-polling mode.

Abbildung in dieser Leseprobe nicht enthalten

While analyzing common industrial methods for remote alarming, the possible options e-mail, SMS and phone call were inspected in detail and compared. Similarly, an important part of this work is the intensive research on possibilities to display some graphical user interface on mobile displays. Finally this exerted dominant influence at the implementation of the user interface for controlling and monitoring a small experimental plant.

Overall, this work confirmed the useful employment of mobile devices for process monitoring and handling of alarms. This was demonstrated by prototype implementation.

Abbildung in dieser Leseprobe nicht enthalten

Aufgabenstellung für die Diplomarbeit

für

Herrn Andreas Wiedenfeld

Erweiterung einer flexiblen Objektstruktur für die Kommunikation mit Datenservern um Möglichkeiten zur Fernalarmierung

Zielsetzung

Am Institut für Automatisierungstechnik werden in aktuellen Arbeiten flexible Softwarekomponenten auf Basis von XML-Technologien entwickelt, die aufgrund der strikten Trennung von Schnittstelle und Implementierung eine effektive und nachhaltige Entwicklung von Visualisierungslösungen für techni- sche Prozesse versprechen. Eine Komponente ServerConnection realisiert eine Kommunikationsbezie- hung mit Prozessdatenservern. Zur Aufnahme der Parametrierungsdaten wird eine flexible Objektstruk- tur genutzt. Im Rahmen dieser Arbeit ist diese Objektstruktur um eine Fernalarmierung - beispielsweise Anruf/SMS/Email - zu erweitern.

Inhalt dieser Diplomarbeit ist deshalb die Erweiterung einer bestehenden Komponente ServerConnection um Dienste zur Fernalarmierung für mobile Endgeräte. Dazu sind zunächst verschiedene Darstellungsmöglichkeiten einer Fernalarmierung auf mobilen Endgeräten und die Komponente hinsichtlich ihrer Erweiterbarkeit zu untersuchen. Der gewählte Ansatz zur Erweiterung der Komponente ist mit einer Implementierung für mobile Endgeräte zu verifizieren.

Arbeitsumfang:

- Evaluation von Möglichkeiten zur Erweiterung der Komponente ServerConnection um SMS/Anruf/Email
- Konzeption von Transformationsvorschriften für die ServerConnection in die Zieltechnologie C# für ein mobiles Endgerät
- Erweiterung eines bestehenden Datenservers um Funktionalitäten zur Fernalarmierung
- Untersuchung von Darstellungsmöglichkeiten einer Fernalarmierung auf mobilen Endgeräten
- Entwicklung einer graphischen Benutzungsoberfläche für ein mobiles Endgerät und Verifikation der Implementierung

Betreuer: Dipl.-Ing. Stefan Hennig

Ausgehändigt am: 1.April 2009

Einzureichen am: 30.September 2009

PD Dr.-Ing. D. Braune

Verantwortlicher Hochschullehrer

Danksagung

An dieser Stelle möchte ich all denen danken, die zu einem erfolgreichen Abschluss dieser Arbeit beigetragen haben. Allen voran mein Betreuer Herr Dipl.-Ing. Stefan Hennig, der mich mit konstruktiver Kritik und hilfreichen Anregungen maßgeblich vorangebracht hat.

Besonderen Dank möchte ich auch meiner Freundin Eva aussprechen, die mich in den letzten Wochen und Monaten, trotz mangelnder Aufmerksamkeit, immer wieder verständnisvoll un- terstützt hat.

Außerdem bedanke ich mich bei Sandra Moses für die Hilfe bei der graphischen Gestaltung, Alexander Lehn, Stefan Jahn und meinem Vater für das Korrekturlesen dieser Arbeit sowie meinem Kommilitonen und Freund René Schmidt, der mein gesamtes Studium durch intensive und produktive Lerngruppenarbeit prägte.

Der Firma 3m5. möchte ich für die ausgezeichnete Arbeitsumgebung und der Bereitstellung aller von mir benötigten Ressourcen danken.

Abschließend möchte ich noch einen besonderen Dank an meine Eltern richten, die mich während des gesamten Studiums nicht nur materiell und finanziell unterstützt haben, sondern mir stets auch beratend zur Seite standen.

Abkürzungsverzeichnis

Abbildung in dieser Leseprobe nicht enthalten

Teil I

Einleitung und Anforderungsspezifikation

1. Einleitung

In den 60er Jahren, als die Mobilfunkverbindung noch vollständig analog war, gab es nicht einmal die Möglichkeit zur Kommunikation mit dem herkömmlichen Telefonnetz. An eine in- dustrielle Nutzung war auch 1986, mit der Umstellung auf eine digitale Signalisierung nicht zu denken. Erst als der GSM Standard in den frühen 90er Jahren eingeführt wurde und damit eine flächendeckende Nutzung möglich wurde, begann ein weltweiter rasanter Aufstieg. Mit der Einführung mobiler Betriebssysteme und der immer schnelleren Entwicklung leis- tungsstärkerer Geräte, scheint das Einsatzgebiet mobiler Geräte mittlerweile grenzenlos.

1993 kommt es in einem o-Nitroanisol-Produktionswerk nahe Frankfurt zu einem Ausfall des Rührwerks. Dadurch steigt der Druck im Reaktor so stark an, dass ein Teil des Kesselinhalts über ein Notfallventil in die Atmosphäre gelangt. Der staubförmige Niederschlag bedeckt weite Bereiche der angrenzenden Stadtteile Frankfurts und muss anschließend sehr aufwändig von Balkonen und öffentlichen Plätzen entfernt werden.

Die Forderungen nach sicherem Betreiben industrieller Anlagen und einer geringen Ausfallrate erfordern ein zuverlässiges Alarmsystem. Da das Alarmmanagement oft Teil der Prozessvisualisierung ist, soll dies ein wichtiger Bestandteil der vorliegenden Arbeit sein.

Aktuelle Arbeiten am Institut für Automatisierungstechnik der Technischen Universität Dresden entwickeln flexible Softwarekomponenten auf Basis von XML-Technologien. Diese versprechen aufgrund der strikten Trennung von Schnittstelle und Implementierung eine effektive und nachhaltige Entwicklung von Visualisierungslösungen für technische Prozesse. Im Rahmen dieser Arbeit sollen Möglichkeiten zur Integration Windows Mobile basierter Geräte in diesen Prozess untersucht werden. Dazu sollen bestehende Komponenten wie ein WebService und die zur Kommunikation mit diesem verantwortliche Komponente ServerConnection um eine Fernalarmierung erweitert werden.

Eine Untersuchung über die Eignung verschiedener Fern-Alarmierungswege wie E-Mail, SMS und Anruf soll ebenso Teil dieser Arbeit sein, wie die Analyse verschiedener Darstellungsmöglichkeiten einer Prozessvisualisierung auf mobilen Endgeräten.

Ziel der Arbeit ist es sowohl die clientseitige Kommunikationskomponente, als auch das serverseitige Alarm-Modell aus einer Hand zu generieren.

Eine prototypische Visualisierungsoberfläche soll über die Komponente ServerConnection das Bedienen und Beobachten der Versuchsanlage sowie das Fern-Alarmierungssystem abschließend evaluieren.

Zunächst erfolgt in Kapitel 2 eine Einleitung in den XVCML-Design-Prozess und die Einord- nung der Arbeit in den derzeitigen Entwicklungsstand. Anschließend werden in Kapitel 3 be- reits eingesetzte Fern-Alarmierungsmethoden untersucht, während Kapitel 4 aktuelle For- schungsergebnisse über Darstellungsprinzipien von Benutzeroberflächen auf mobilen Displays vorstellt.

Am Institut für Automatisierungstechnik wurde eine Kleinversuchsanlage installiert, welche mit Hilfe eines Web Servers überwacht und gesteuert werden kann.

Auf Basis dieses Servers und den gewonnenen Erkenntnissen über Visualisierungsmöglichkeiten auf mobilen Displays, gilt es ein Fern-Alarmierungssystem für mobile Geräte in Kapitel 5 zu entwerfen und anschließend in Kapitel 6 zu implementieren.

Den Schlusspunkt setzen Kapitel 7 und 8, welche die gesamte Arbeit zusammenfassen, bewerten und einen kleinen Ausblick für mögliche Weiterentwicklungen geben.

2. Einordnung der Arbeit

Dieses Kapitel behandelt sämtliche Anforderungen, die sich aus der Aufgabenstellung dieser Arbeit ergeben. Die Struktur orientiert sich an der Gliederungsempfehlung nach VDI/ VDE 3694.

2.1. Allgemeine Beschreibung (Istzustand)

2.1.1. XVCML

Die eXtensible Visualization Components Markup Language (XVCML) ist ein spezieller XMLDialekt, der mit dem Ziel entwickelt wurde, Benutzungsoberflächen, insbesondere für die webbasierte Prozessvisualisierung, technologieunabhängig zu beschreiben[1]. Zum Zeitpunkt der Projektierung (Entwurfszeit) sollen keine Angaben zur ausführenden Zielplattform gemacht werden.

Nach dem Komponentenprinzip werden auf Basis von XML-Technologien Softwarekomponenten entwickelt, die eine strikte Trennung von der Implementierung garantieren. Der Schnittstelle dieser Entwurfszeitkomponenten liegt eine entsprechende XML Schema Beschreibung (XML Schema Description, kurz: XSD) zu Grunde.

Die Softwarekomponenten von XVCML sind in zwei Kategorien unterteilt (Abbildung 2.1.1). Die Visualisierungskomponenten wei- sen eine graphische Repräsentation auf, während die Funktionskomponenten dafür erweiterte Funktionalitäten bereitstellen, ohne graphisch dargestellt zu werden.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.1.1 Beziehung zwischen Softwarekomponenten[1]

Die folgenden Abschnitte werden diese Elemente und ihre Beziehungen untereinander näher erläutern.

2.1.1.1. Visualisierungskomponenten

Aus den in der Prozessvisualisierung häufig wiederkehrenden Grafikobjekten wurden in XVCML elementare Komponenten abgeleitet, welche durch Kombinationen untereinander aufwändige Oberflächen abbilden können. Dazu wurde ein Container-Element (ComplexVisComp) eingeführt, das eine Menge dieser Grundelemente zu einem komplexen Verband vereint.

Zum Ausgangszeitpunkt unterstützt XVCML unter anderem folgende Visualisierungskomponenten, welche durch ein eigenes XSD beschrieben werden:

1) Button
2) Checkbox
3) Data
4) Dropdown
5) Image
6) RadioButton
7) RealTimeTrend
8) Table
9) Tree

Für eine ausführliche Aufführung aller unterstützten Elemente sei auf[1] verwiesen.

Zur Entwurfszeit werden für diese Elemente statische Repräsentationseigenschaften (Representation u.a. Position, Größe, Farbe) definiert, die ihren Charakter zur Laufzeit auf der Zielplattform bestimmen. Dieses Erscheinungsbild kann optional durch eine Dynamisierung (Animation) sowie durch verschiedene Mechanismen zur Reaktion auf Benutzereingaben (Interaction) erweitert werden (Abbildung 2.1.2).

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.1.2 Beziehung der Eigenschaften einer Visualisierungskomponente

2.1.1.2. Funktionskomponenten

Die Funktionskomponenten dienen dazu, die Visualisierungskomponenten mit erweiterten Funktionalitäten auszustatten. Im gegenwärtigen Entwicklungsstand existiert nur die Server- Connection. Sie dient als Schnittstelle zwischen den Visualisierungselementen und mehreren Datenservern.

Zum Entwurfszeitpunkt werden sämtliche Parameter, die zum Aufbau einer Kommunikationsbeziehung mit einem Datenserver benötigt werden, definiert. Während des Transformationsvorgangs werden dann daraus die benötigten Client-Stubs generiert.

Nach erfolgreicher Transformation stellt die Komponente ServerConnec- tion zur Laufzeit die Verbindung zwischen den verwendeten Datenser- vern und den Visualisierungskomponenten her (Abbildung 2.1.3). Dabei implementiert sie für jeden Datenserver eine spezifische Schnitt- stelle (ServerInterface), um eine Kommunikationsbeziehung mit ihm zu etablieren. Außerdem stellt sie eine einheitliche Schnittstelle bereit, um die Prozesswerte den Visualisierungskomponenten zur Verfügung zu stellen (DataInterface).

Nur die ServerConnection selbst hat Kenntnis über den tatsächlichen Zugriff auf einen Prozesswert und den dafür nötigen Datenserver.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.1.3 Funktionskomponente ServerConnection

2.1.1.3. Komponente ServerConnection

Die ServerConnection stellt eine Komponente des Visualisierungssystems dar[2]. Zur Projektierungszeit werden mit ihr sämtliche Parameter, welche für den Aufbau einer Kommunikationsbeziehung mit einem Datenserver benötigt werden, definiert.

Durch eine vereinheitlichte Darstellung der technologiespezifischen Datenpunkte wird eine universelle, generische Schnittstelle zur Verfügung gestellt[2]. Diese implementiert eine entsprechende Variablenbeschreibung (VisComp-Variable).

Die Integration lokaler Variablen, aus dem Speicher des Visualisierungssystems, in die ServerConnection und die Abbildung der VisComp-Variablen auf eine Servervariable bringt den Vorteil[2], dass die einzelnen Visualisierungskomponenten nicht mehr zwischen den verschiedenen Variablen-Typen unterscheiden müssen.

Mehrere interne Komponenten sind im Komponentendiagramm (Abbildung 2.1.4) im Zusammenhang mit den äußeren Schnittstellen des Prozessdatenservers (Dat_IF), den Visualisierungskomponenten (CI_IF) und der Konfigurationsschnittstelle (SC_Conf) dargestellt.

Die Aktionen, welche die Prozessdaten lokalisieren und für die nachfolgende Verarbeitung (je nach Technologie der Datenquelle) aufbereiten, bilden einen logischen Verbund. Dieser wird nachfolgend als Prozessdatenlokalisierer bezeichnet. An ihn werden unverarbeitete Anforderungen anderer Visualisierungskomponenten über die Schnittstelle (SC_IF) herangeführt und anschließend den richtigen Datenquellen zugeordnet.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.1.4 Interner Aufbau der Komponente ServerConnection[2]

Die Daten zum Lesen und Schreiben werden über die interne Schnittstelle PDL_Stubs an eine zweite Subkomponente, den Kommunikationsstub, weitergegeben.

Für jede Zieltechnologie existiert ein speziell angepasster Kommunikationsstub, der die Kommunikation mit der Datenquelle über die äußere Schnittstelle Dat_IF kapselt und so einen transparenten Zugriff auf die Prozessvariablen ermöglicht.

Die Konfiguration der Visualisierungskomponenten impliziert zur Entwurfszeit die dritte Kom- ponente, das lokale Datenabbild. Es synchronisiert explizit zur Laufzeit die vom Visualisie- rungssystem gelesenen und überwachten Variablen mit den Prozessvariablen. Dazu liefert die durch den Prozessdatenlokalisierer bereitgestellte Schnittstelle PDL_Data stets die aktuellen Werte.

Für die Konfiguration (Abbildung 2.1.5) der Komponente ServerConnection wird eine Konfi- gurationsschnittstelle (SC_Conf) benötigt, die ihr die Einstellungen sowohl über die VisComp- Variablen (an den Prozessdatenlokalisierer), als auch über die verschiedenen Server und die Ser- vervariablen (Kommunikationsstub) übergibt.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.1.5 Schnittstellen der Komponente ServerConnection[2]

Dieser Arbeit liegt eine Version der Komponente ServerConnection (Abbildung 2.1.6) zu Grun- de, welche als Server die Datenquellen ModbusTCP, OPC XML DA, OPC UA und MMS unter- stützt.

Dabei werden die Komponenten Kommunikationsstub und Prozessdatenlokalisierer durch die Spezifikationen ServerType und DataType umgesetzt.

Das lokale Datenabbild folgt, wie bereits beschrieben, aus den Spezifikationen der Visualisierungsvariablen.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.1.6 XML-Schema Beschreibung der Komponente ServerConnection

2.1.1.4. Arbeitsweise der Prozessvisualisierung

Dieser Abschnitt soll die grundlegende Arbeitsweise zur XVCML basierten Prozessvisualisierung erläutern.

Um ein Visualisierungssystem auf Basis von XVCML zu entwerfen, müssen zunächst die abstrakten Beschreibungen der benötigten Komponenten aus einer Bibliothek importiert werden (Abbildung 2.1.7).

Dazu werden mit Hilfe von Bildungsvorschriften in Form von XML Schemata die entsprechenden Softwarekomponenten ausgewählt und ein XML Dokument erzeugt. Dieses nimmt alle Daten der parametrierten Schnittstellen auf und repräsentiert somit das gesamte Projekt. Anschließend wird dieses mit Hilfe der Implementierungsvorschriften der entsprechenden Zieltechnologie und einem XSLT-Prozessor in eine einsatzfähige Visualisierungslösung überführt. Die erzeugte Oberfläche beinhaltet dann sowohl Visualisierungs- als auch Funktionskomponenten. Diese sind letztendlich im Quellcode der Zieltechnologie formatiert.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.1.7 XSLT Transformation

2.1.2. Prozessdatenserver zur Laufzeit

Wie im vorherigen Abschnitt 2.1.1.4 beschrieben, dient XVCML dazu Prozessvisualisierungen plattformunabhängig entwerfen zu können. Die Komponente ServerConnection spielt dabei eine entscheidende Rolle, da der in ihr beschriebene, zur Entwurfszeit konfigurierte, Kommunikationsstub für die Prozessdatenanbindung zur Laufzeit verantwortlich ist.

Um eine stetige Verbindung zu den Prozessdaten zu ge- währleisten, wird ein Prozessdatenserver eingesetzt. Dieser stellt zur Laufzeit die Kommunikation zwischen der Visualisierung und der darzustellenden Anlage sowie ihrer Prozesswerte bereit (Abbildung 2.1.8).

Am Institut für Automatisierungstechnik wurde dazu im Rahmen früherer studentischer Arbeiten ein auf dem Axis Webserver basierender Webservice (MasterWS) entwi- ckelt. Zur Zeit der Fertigstellung dieser Arbeit ist der Web-Service unter der Adresse „http://192.168.35.19:8080/“ erreichbar, die zugehörige wsdl-Datei ist dem Anhang A2-1 beigefügt. Der Webser- vice greift über das Protokoll Modbus TCP (Transmission Control Protocol) direkt auf die zu steuernde Anlage ( 1.) zu und stellt die gelesenen Werte mit Hilfe des Hyper- text-Übertragungsprotokolls (engl.: Hypertext Transfer Protocol, http) bereit. Somit ist eine direkte, plattform- unabhängige Verfügbarkeit der Prozessdaten gewährleis- tet.

Die Verbindung zwischen dem Client und dem Web Ser- ver soll durch eine Transformation der zu erweiternden Komponente ServerConnection ermöglicht werden.

Abbildung in dieser Leseprobe nicht enthalten

Abb. 2.1.8 Bereitstellung von Prozesswerten

Komponente MasterWS

Im weiteren Verlauf dieses Projektes wird der „MasterWS“ mit seinen Funktionen zur Steuerung der automatisierten Versuchsanlage die Kernkomponente darstellen. Vier Java-Klassen (siehe Abbildung 2.1.9) bilden die elementaren Bestandteile des Webservice und sichern so eine plattformunabhängige Verfügbarkeit aller Prozessvariablen.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.1.9: Klassendiagramm MasterWS, Kurzform

Die Komponente „MasterWS“ stellt zur Fernsteuerung der sich am Lehrstuhl Automatisie- rungstechnik der TU Dresden befindlichen Kleinversuchsanlage über einen http - Aufruf fol- gende Funktionen bereit:

getValue(String sSPSVariable)

„sSPSVariable“ ist die SPSVariable deren aktueller Prozesswert zurückgeliefert wird. getValue(String sModbusFunction, int isStartingAddress, int isQuantityOfInputs)

Es wird der Wert einer SPS-Variablen zurückgegeben, wobei die Modbus-Funktion (“sModbusFunction”) direkt mit Startadresse (“isStartingAddress”) und der Länge der Adresse („isQuantityOfInputs“, ModbusTCP unterscheidet daran die Datentypen) aufge- rufen wird.

doIntertankTransfer(int iBehaelterA, int iBehaelterB, int iP3HandstellWert, int iV1HandstellWert, int iV2Handstellwert)

Mit dieser WebMethode kann das Umpumpen zwischen zwei Behältern (iBehalter1 als Quelle, iBehaelter2 als Empfänger) gesteuert werden.

Mittels „iP3Handstellwert“ kann die Pumpe „P3“ prozentual gesteuert werden. Ebenso die Ventile V1 („iV1Handstellwert“) und V2 („iV2Handstellwert“).

stopIntertankTransfer()

beendet die Operation des Umpumpens. getContextualInformation(String sContext)

Liefert alle SPS-Variablen mit deren Werten zu einem bestimmten Kontext („sContext“). getSPSVar(String sName)

Diese Methode liefert alle Informationen einer SPS-Variable („sName“)

Mit diesen Funktionen können clientseitig die Prozesswerte ausgelesen und überwacht werden. Eine Steuerung ist nur im Rahmen des Umpumpens von einem Behälter in einen anderen möglich. Das gezielte Schreiben einzelner Prozessvariablen ist nicht möglich.

2.2. Aufgabenstellung/ Sollzustand

2.2.1. Funktionale Anforderungen

Anforderung 1 Erweiterung des vorhandenen Webservice um Möglichkeiten zur Prozessüberwachung

Die aktuelle Implementierung bietet keinerlei Möglichkeiten zum automatischen serverseitigen Überwachen von Prozessvariablen. Diese Funktion muss hinzugefügt werden. Dabei ist zu entscheiden ob die zyklische Überwachung bereits zur Entwurfszeit, oder erst zur Laufzeit definiert werden soll.

Anforderung 2 Untersuchung des vorhandenen Webservice auf Möglichkeiten der Fernalarmierung

Basierend auf einem Tomcat Webserver ist Java die Laufzeitumgebung des Webservice. Im weiteren Verlauf dieser Arbeit ist zu untersuchen, welche der später (Kapitel 3) vor- gestellten Methoden zur Fernalarmierung (E-Mail, SMS, Anruf), sich auf dem vorhan- denen System umsetzen lassen. Dabei sind Vor- und Nachteile abzuwägen, sowie ein kostengünstiges, effizientes und betriebssicheres Alarm- & Weiterleitungssystem zu entwickeln.

Betriebssicher ist in dieser Arbeit im Sinne von ausfallsicher zu verstehen, d.h. Alarme gehen nicht verloren und werden immer an eine definierte Menge von Empfänger wei- tergeleitet.

Anforderung 3 Visualisierung einer Anlagensteuerung auf kleinem Display

Mit Hilfe der Webserver - Funktionen wird eine Bedienung und Beobachtung der Versuchsanlage ermöglicht. Ziel dieser Arbeit ist es die Funktionen, mit Hilfe eines geeigneten prototypischen Visualisierungssystems, auf einem kleinen mobilen Display anzubieten. Eine XSLT Transformation ist nicht erforderlich.

Anforderung 4 Interaktives Navigieren durch die graphische Benutzeroberfläche

Dem Anwender soll es ermöglicht werden, sich durch die, nach Anforderung 3 entworfene Oberfläche zum Bedienen und Beobachten zu navigieren, sowie dargestellte Prozesse mobil zu überwachen und zu steuern.

Anforderung 5 Weiterentwicklung der ServerConnection

Die im Rahmen der Arbeit[2] entwickelte Komponente ServerConnection muss so er- weitert werden, dass die Konfiguration zur umgesetzten Fernalarmierung (Anforderung

2) mit allen nötigen Parametern in einem geeigneten Format zur Entwurfszeit definiert werden kann.

Anforderung 6 Konzeption von Transformationsvorschriften

Die ServerConnection ist die Grundlage der Client - Server Kommunikation. Dazu sollen Transformationsvorschriften entworfen werden, um die nach Anforderung 5 erweiterte ServerConnection in die Zieltechnologie C# mit dem .NET Compact Framework (.NET CF) für mobile Geräte zu überführen.

2.2.2. Anforderungen an die Systemtechnik

Anforderung 7 SPS Versuchsanlage mit In- ternetzugang

Die Speicher-Programmierbare-Steuerung (SPS) muss über einen Internetzugang ver- fügen, damit sie ferngesteuert werden kann.

Anforderung 8 Apache Tomcat 6.0.18 Web- server mit Axis 1.4 WebSer- vice

Die Kommunikation zur SPS wird über den Tomcat Webserver von Apache realisiert. Dabei stellt der Axis WebService die benötige Java-Laufzeitumgebung bereit.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.2.1 SPS Versuchsanlage

Anforderung 9 MasterWS als WebService

Der bereits in Abschnitt 2.1.2 beschriebene MasterWS ist als Axis - WebService imple- mentiert.

Anforderung 10 mobiles Endgerät (HTC Kaiser TyTN II)

Die Zielplattform der Visualisierung soll ein mobiles Endgerät auf Basis von Windows Mobile (Microsoft .NET Compact Framework 3.5 muss unterstützt werden) sein. Das Gerät muss eine Telefonfunktion bereitstellen, sowie über eine BreitbandInternetverbindung (z.Bsp. UMTS) verfügen.

In dieser Arbeit wird das HTC Kaiser TyTN II, auch bekannt als MDA Vario III eingesetzt.

2.2.3. Randbedingungen, nicht funktionale Anforderungen

Anforderung 11 stabile Datenverbindung

Um ein zuverlässiges Arbeiten und eine sichere Fernalarmierung zu gewährleisten, muss eine stabile Datenverbindung zwischen WebServer und mobilem Gerät hergestellt sein.

Anforderung 12 Bedienbarkeit

Die Dateneingabe, welche Navigations- und Steuerzwecken dient, soll über einen

Touchscreen mit Hilfe der üblichen Standard-Hardwaretasten erfolgen. Üblicherweise werden als Standard-Hardwaretasten bei mobilen Geräten 4 Richtungspfeile sowie eine Bestätigungstaste vorausgesetzt.

Auf die gerätespezifische Mini - Tastatur soll bei der Eingabe verzichtet werden.

Anforderung 13 Sicherheit

Auf eine passwortgeschützte Benutzeranmeldung soll bei der prototypischen Implementierung verzichtet werden. Das Gerät wird anhand seiner Telefonnummer bzw. E- Mailadresse am WebService für die Alarmierung registriert.

2.2.4. Qualitätsmerkmale

Folgende Qualitätsmerkmale sind im weiteren Entwicklungsverlauf als grundlegend zu be- trachten:

Funktionalität

Es wird eine prototypische graphische Oberfläche gefordert, die das Bedienen und Beobachten mit der Kleinversuchsanlage (Anforderung 7) ermöglicht.

Zuverlässigkeit

Täglicher Einsatz der Software, erfordert eine robuste Applikation mit zuverlässiger Fehler- und Ausnahmebehandlung. Dazu sind geeignete Testfälle zu entwerfen, durchzuführen und auszuwerten.

Teil II

Grundlagen

3. Fernalarmierung

3.1. Einleitung

Fernmeldeanlagen sind laut[3], „Einrichtungen der Informationstechnik, die eine Übertragung von Nachrichten, Daten und Informationen (Sprache, Töne, Bilder oder Zeichen) ermöglichen und in der Regel deren Verarbeitung (Vermittlungstechnik, Fernwirktechnik, Informationsverarbeitung) sowie Ausgabe einschließen.“

„Abhängig von der Funktion der Gefahrenwarnanlagen (GWA) und dem Meldungsereignis sind unterschiedliche Alarmierungsarten gefordert. Diese können zur Warnung anwesender Personen (Internwarnung), zur Abschreckung (Internalarm) und/oder zum Herbeirufen von Hilfe (Fernalarm) dienen.“[4].

Leitstellen sind meist nicht „rund um die Uhr“ besetzt. Trotzdem sollen und müssen wichtige Meldungen und Alarme das zuständige Bereitschaftspersonal erreichen. Bei dem zu informierenden Personenkreis sind sowohl die zeitliche Verfügbarkeit, die fachliche Qualifikation als auch administrative Kriterien zu berücksichtigen. Die Fernüberwachung von Maschinen ist daher in der Industrie weit verbreitet. Die nötigen Sensoren sind hoch entwickelt und arbeiten äußerst zuverlässig[5]. Unter Fernwirken werden gewöhnlich steuerungstechnische, regelungstechnische oder sicherungstechnische Aufgaben verstanden, die „aus der Ferne", also über ein Telekommunikationsnetz ausgeführt werden.

Diese Arbeit soll Möglichkeiten zur serverseitigen Fernalarmierung untersuchen und imple- mentieren. Dazu werden im folgenden Kapitel die in der Prozessleittechnik häufig eingesetz- ten Methoden zur Fernalarmierung analysiert und drei Wege der Kommunikation näher unter- sucht.

3.2. Praktischer Einsatz

Sehr weit verbreitet ist die Möglichkeit, Alarme an einen Großteil des Personals über E-Mail weiter zu leiten. Viele Lösungen in der Prozessleittechnik nutzen außerdem die Kurzmittei- lungsdienste (engl.: Short Message Services, SMS) verschiedener Mobilfunkanbieter, um Mit- arbeiter in Bereitschaft automatisch vom Prozessleitsystem informieren zu lassen. Im Bauge- werbe beispielsweise ist es nicht nur wichtig den aktuellen Aufenthaltsort einer Maschine zu kennen, sondern auch Informationen über die Dauer des Einsatzes zu erhalten, da Ausfallzei- ten sehr teuer sind[5].

Auch in der Sicherheitstechnik bietet sich SMS als effektives Werkzeug in verschiedenen Bereichen an. So ist das Notrufsystem vieler Aufzüge auf Basis von „Global System for Mobile Communications“ (GSM) realisiert. Dabei ist auf dem Dach der Aufzugskabine ein Notrufsystem installiert, welches wie ein Handy arbeitet. Es stellt, nach dem Betätigen des Alarmknopfes innerhalb der Kabine, eine Sprachverbindung zur Notrufzentrale her.

Ebenso werden Web-Oberflächen mit integriertem Polling-Alarm-System angeboten [6, 7]. Dabei haben Techniker von jedem Computer mit Internetzugang Zugriff auf die Prozessüber- wachung.

Mit dem Versenden von Faxnachrichten sowie einem automatischen Anruf mit elektronischer Sprachausgabe und der Nutzung des Paging-Systems werden Alternativen in einigen Automatisierungssystemen[5] angeboten.

3.3. E-Mail

„Electronic Mail“ (elektronische Post), auch bekannt als E-Mail ist der wichtigste und am meisten genutzte Dienst des Internet. Er funktioniert nach dem „Store and Forward - Prinzip“[8], wobei keine direkte Verbindung zwischen den Kommunikationspartnern hergestellt, sondern die Nachricht auf einem Mail-Server im Internet zwischengespeichert wird. Der Empfänger kann diese dann zu einem beliebigen Zeitpunkt abrufen.

3.3.1. Ablauf der Kommunikation

Eine Nachricht besteht aus dem korrekten Empfänger, einem optionalen Betreff und dem Body, welcher sich aus Texten, Bildern und anderen Dateianhängen zusammensetzen kann. Zum Versenden der E-Mail [Abbildung 3.2.1] wird eine TCP/ IP (Transmission Control Protocol/ Internet Protocol) Verbindung (üblicherweise über Port 25) vom Sender (1) zu einem SMTP (Simple Mail Transfer Protocol) Server (2) hergestellt. Nach dem Abschicken wird die Verbindung zum Server wieder getrennt.

Anschließend leitet der SMTP Server die Nachricht an die Mailbox des Empfängers weiter. Über die Adresse ermittelt er dessen Domäne und leitet die Nachricht ins Empfängernetz weiter (liegt der Adressat in einer anderen Domäne, wird die IP-Adresse von einem Domain-Name- Server (DNS) geliefert). Dort angekommen wird die Nachricht in der Mailbox des Adressaten (3) gespeichert.

Nun kann der Empfänger (4) die Nachricht abrufen Er baut dazu eine TCP/ IP Verbindung (zum Beispiel über Port 110) zum Empfangsserver (beispielsweise ein POP3-Server) auf und fragt alle neuen Nachrichten ab. Anschließend wird die Verbindung zum Server wieder getrennt.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3.2.1 Prinzip des E-Mail-Versands

3.3.2. Zuverlässigkeit der Nachrichtenübertragung

Die Zuverlässigkeit der E-Mail-Übertragung hängt stark von den Zwischenservern ab, die bei der Übertragung zum Einsatz kommen. Der weiterleitende Rechner versucht eine Verbindung zum nächsten Server aufzubauen, um die Nachricht weiterzuleiten und anschließend aus dem eigenen Speicher zu löschen. Schlägt der Verbindungsaufbau fehl, speichert er die Nachricht für eine bestimmte Zeit zwischen, um es dann erneut zu versuchen. Kann die Nachricht nicht mehr weitergeleitet werden (etwa durch falsche Adressierung), wird der Absender mit einer entsprechenden Fehlermeldung darüber informiert.

Ein hohes Maß an Sicherheit kann der E-Mail in Bezug auf die reine Datenübertragung zugesprochen werden[9], während die Dauer der Übertragung nicht sicher vorausgesagt werden kann, da der tatsächliche Übertragungsweg nicht vorherbestimmt werden kann.

3.4. SMS

Der Kurznachrichtendienst SMS ist ein Telekommunikationsdienst zur Übertragung kurzer, auf maximal 160 Zeichen begrenzter Nachrichten. Ursprünglich als Nebenprodukt des Signalisierungskanals beim Rufaufbau im GSM entwickelt, dient der Dienst heute zum weltweiten Verschicken kurzer Texte, teilweise sogar über das Festnetz.

Wie beim Senden und Empfangen von E-Mails, folgt SMS dem „Store and Forward“ Prinzip“ [Abbildung 3.4.1].

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3.4.1: Senden einer SMS im gleichen Netz

3.4.1. Ablauf der Kommunikation

Die Nachricht setzt sich aus einem Header (grundlegende Informationen über Absender, Emp- fänger, Codierung) und einem Body (zu sendender Text) zusammen und wird über die aktuell registrierte Empfangsstation (BTS=Base Transceiver Station) an die Basisstation (BSC = Base Station controller) geschickt. Von dort wird sie an die netzeigene Kurzmitteilungszentrale (SMSC = Short Message Service Center) weitergeleitet, wo eine anschließende Auswertung des Empfängers erfolgt[10].

Das SMSC versucht den Adressaten zu ermitteln. Befindet er sich im selben Netz, wird er zur Nachrichtenübermittlung direkt (über BSC und BTS) kontaktiert [Abbildung 3.4.2], andernfalls wird die Nachricht an die zugehörige Zentrale des Empfängernetzes weitergeleitet, wo sie dann erneut ausgewertet wird[10].

Ist das Weiterleiten erfolgreich, löscht das SMSC die Nachricht. Kann die Nachricht nicht weitergeleitet werden, speichert die Kurzmitteilungszentrale diese für eine bestimmte Zeit und versucht es dann (mehrfach) erneut, wobei das Intervall zwischen den einzelnen Versuchen in der Regel erhöht wird[10].

Zur Übertragung wird nicht der eigentliche Sprachkanal des GSM Standards verwendet, son- dern der Signalisierungskanal, welcher Gespräche aufbaut und die Verbindungen aufrecht erhält. So können Kurznachrichten auch während eines Telefonates versendet und empfangen werden.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3.4.2: Sequenzdiagramm, Versenden einer SMS, 1-6 skizziert einen sofort erfolgreichen Sendevorgang, 7-16 zeigt das verzögerte Übertragen

3.4.2. Zuverlässigkeit der Nachrichtenübertragung

Die heutigen terrestrischen Mobilfunknetze erreichen über 80% der Weltbevölkerung[11], wobei über Satelliten noch Flächen abgedeckt werden, die für einen Sendemast unerreichbar sind. Trotz dieser gut ausgebauten Mobilfunknetze gibt es keine Garantie bei der Zustellzeit einer SMS, da eventuelle Engpässe Verzögerungen zur Folge haben. Je nachdem wie lange der Empfänger nicht erreichbar war und wie viele Zustellversuche das SMSC schon unternommen hat, kann die Verzögerung einige Sekunden, aber auch einige Stunden betragen. Prinzipiell kann mit GSM aber ein Empfang der Nachricht garantiert werden[10].

[...]