Fakultät Elektrotechnik und Informationstechnik Institut für Automatisierungstechnik

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 Basis eines speziellen XML Dialektes ein Verfahren entwickelt mit dem es möglich ist Prozessvisualisierungen 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.

Bei der Analyse industriell verbreiteter Methoden zur Fernalarmierung, wurden die Möglichkeiten 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.

Fakultät Elektrotechnik und Informationstechnik Institut für Automatisierungstechnik

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 technology 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 possible.

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.

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.

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 technische Prozesse versprechen. Eine Komponente ServerConnection realisiert eine Kommunikationsbeziehung mit Prozessdatenservern. Zur Aufnahme der Parametrierungsdaten wird eine flexible Objektstruktur 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 unterstü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.

INHALTSANGABE

Inhaltsverzeichnis   

1.  EINLEITUNG  2

2.  EINORDNUNG DER ARBEIT  3

2.1.ALLGEMEINE  BESCHREIBUNG (ISTZUSTAND)  3

2.1.1.XVCML..............................................................................................................................................   3

2.1.1.1.VISUALISIERUNGSKOMPONENTEN.....................................................................................   4

2.1.1.2.FUNKTIONSKOMPONENTEN..................................................................................................   5

2.1.1.3.KOMPONENTE  SERVERCONNECTION  5

2.1.1.4.ARBEITSWEISE  DER PROZESSVISUALISIERUNG  8

2.1.2.PROZESSDATENSERVER  ZUR LAUFZEIT  9

2.2.AUFGABENSTELLUNG/  SOLLZUSTAND  12

2.2.1.FUNKTIONALE  ANFORDERUNGEN  12

2.2.2.ANFORDERUNGEN  AN DIE SYSTEMTECHNIK  13

2.2.3.RANDBEDINGUNGEN,  NICHT FUNKTIONALE ANFORDERUNGEN  14

2.2.4.QUALITÄTSMERKMALE   15

3.  FERNALARMIERUNG  17

3.1.EINLEITUNG   17

3.2.PRAKTISCHER  EINSATZ  17

3.3.E-MAIL   18

3.3.1.ABLAUF  DER KOMMUNIKATION  18

3.3.2.ZUVERLÄSSIGKEIT  DER NACHRICHTENÜBERTRAGUNG  19

3.4.SMS   20

3.4.1.ABLAUF  DER KOMMUNIKATION  20

3.4.2.ZUVERLÄSSIGKEIT  DER NACHRICHTENÜBERTRAGUNG  21

3.5.MOBILFUNKANRUF   22

3.5.1.ABLAUF  DER KOMMUNIKATION  22

3.5.2.ZUVERLÄSSIGKEIT  DER NACHRICHTENÜBERTRAGUNG  22

3.6.DIENSTKOMBINATIONEN   24

3.6.1.E-MAIL  TO SMS  24

3.6.2.SMS  TO E-MAIL  24

3.6.3.DIREKTER  KONTAKT ZUR SMSC  24

i

INHALTSANGABE

4.  DARSTELLUNGSPRINZIPIEN FÜR MOBILE DISPLAYS.  26

4.1.EINLEITUNG   26

4.2.GRUNDLAGEN   28

4.3.SPEZIELLE  PROBLEME MOBILER GERÄTE  30

4.4.FOLGEN   31

4.5.SPEZIELLE  KRITERIEN FÜR MOBILE GERÄTE  31

4.6.NAVIGATIONSPARADIGMEN   33

5.  SYSTEMENTWURF  38

5.1.EINLEITUNG   38

5.2.VORBETRACHTUNGEN   41

5.2.1.MASTERWS   41

5.2.2.FERNALARMIERUNG   43

5.2.3.ALAR-MMODELL.........................................................................................................................   44

5.3.ENTWURFSZEIT   46

5.3.1.ANWENDUNGSFALLDIAGRAMM   46

5.3.2.ANWENDUNGSFÄLLE   47

5.3.3.LÖSUNGSENTWURF   49

5.3.3.1.SERVERSEITEIGER  ENTWURF  49

5.3.3.2.CLIENTSEITIGER  ENTWURF  50

5.4.LAUFZEIT   53

5.4.1.ANWENDUNGSFALLDIAGRAMM   53

5.4.2.ANWENDUNGSFÄLLE   54

5.4.3.BESCHREIBUNG  AUSGEWÄHLTER ANWENDUNGSFÄLLE  58

5.4.3.1.PROZESS  ÜBERWACHEN  58

5.4.3.2.ALARM  WEITERLEITEN  59

5.4.3.3.ALARMSTATUS  ANPASSEN  63

5.4.4.LÖSUNGSENTWURF   64

5.4.4.1.SERVER  - MASTERWS  64

5.4.4.2.CLIENT  - MOBILE ANWENDUNG.  65

5.4.4.3.OBERFLÄCHENENTWURF   66

5.5.ZUSAMMENFASSUNG   69

5.5.1.SERVERSEITIGE  KOMPONENTEN  70

5.5.2.CLIENTSEITIGE  KOMPONENTEN  71

ii

INHALTSANGABE

6.  IMPLEMENTIERUNG  73

6.1.ENTWURFSZEIT   75

6.1.1.ALAR-MMODELL.........................................................................................................................   75

6.1.2.SERVER-KONFIGURATION   76

6.1.3.CLIENT-REGISTRIERUNG   77

6.1.4.KOMPONENTE  SERVERCONNECTION  81

6.2.LAUFZEIT   83

6.2.1.SERVERSEITIGE  PROZESSÜBERWACHUNG  83

6.2.1.1.ALARMWEITERLEITUNG...................................................................................................   84

6.2.1.2.ANRUF-BIBLIOTHEK  JDUN  85

6.2.1.3.E-MAIL  WEITERLEITUNG  87

6.2.2.CLIENT-REGISTRIERUNG   89

6.2.3.KOMPONENTE  SERVERCONNECTION  93

6.2.4.KOMPONENTE  VISUALISIERUNG  98

7.  AUSWERTUNG  104

7.1.SERVER-ANWENDUNG   104

7.2.CLIENT-ANWENDUNG   105

8.  ZUSAMMENFASSUNG UND AUSBLICK  108

9.  ABBILDUNGSVERZEICHNIS  111

10.  LITERATURVERZEICHNIS  113

iii

INHALTSANGABE

11.  ANHANG  116

11.1.A2-1  WSDL DATEI DES VERWENDETEN WEBSERVICE „MASTERWS“  116

11.2.A5-1  UMTS VERFÜGBARKEIT IN DEUTSCHLAND  117

11.3.A6-1  XSL TRANSFORMATIONSVORSCHRIFT DER SERVER  KONFIGURATIONSDATEI

   120

11.4.A6-2  XML CODIERTE SERVER-KONFIGURATIONSDATEI ALS  

TRANSFORMATIONSERGEBNIS   121

11.5.A6-3  VOLLSTÄNDIGE XSL TRANSFORMATIONSVROSCHRIFT DER  

REGISTRIERUNGSKLASSE   122

11.6.A6-4  VOLLSTÄNDIGE XSL TRANSFORMATIONSVORSCHRIFT DER SERVER-  

KOMMUNIKATIONS  -KLASSEN  127

11.7.A6-5  VOLLSTÄNDIGE XSL TRANSFORMATIONSVORSCHRIFT DER KLASSE  

WEBSERVICECOMMUNICATION   131

11.8.A6-6  XSL TRANSFORMATIONSVORSCHRIFT DER KLASSE WEBSERVICEEVENTS  139

1.9.A6-7  XSL TRANSFORMATIONSVORSCHRIFT DER KLASSE WEBSERVICEEVENTARGS  140

11.10.A6-8  TRANSFORMIERTER C CODE DES INTERFACE IREGISTRATION  141

11.11.6-9  TRANSFORMIERTER C CODE FÜR DIE REGISTRIERUNG ANKOMMENDER  

ALARME  PER ANRUF  142

11.12.A6-10  TRANSFORMIERTER C CODE FÜR DIE REGISTRIERUNG ANKOMMENDER  

ALARME  VIA E-MAIL  145

11.13.A6-11  TRANSFORMIERTER C CODE DER KOMMUNIKATIONSKLASSE  152

iv

Abkürzungsverzeichnis

.NET Dot Net BSC Base Station Controller BTS Base Transceiver Station C# CF GDI GSM GWA HTTP IP MS Microsoft PDA Personal Digital Assistant POP Post Office Protocol RAS Remote Access Service SDF Smart Device Framework SMS SMSC SMTP TCP UMTS

XML XSD XSL XSLT XVCML v

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 industrielle 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 leistungsstä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 Einordnung der Arbeit in den derzeitigen Entwicklungsstand. Anschließend werden in Kapitel 3 bereits eingesetzte Fern-Alarmierungsmethoden untersucht, während Kapitel 4 aktuelle Forschungsergebnisse ü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 XML-Dialekt, 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 Ziel-plattform 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 weisen eine graphische Repräsentation auf, während die Funktionskomponenten dafür erweiterte Funktionalitäten bereitstellen, ohne graphisch dargestellt zu werden.

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

DIPLOMARBEIT, ANDREAS WIEDENFELD

3

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 (In- teraction) erweitertwerden (Abbildung 2.1.2).

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 ServerConnection zur Laufzeit die Verbindung zwischen den verwendeten Datenservern und den Visualisierungskomponenten her (Abbildung 2.1.3). Dabei implementiert sie für jeden Datenserver eine spezifische Schnittstelle (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.

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 Server-Connection 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.

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 Komponente, das lokale Datenabbild. Es synchronisiert explizit zur Laufzeit die vom Visualisierungssystem gelesenen und überwachten Variablen mit den Prozessvariablen. Dazu liefert die durch den Prozessdatenlokalisierer bereitgestellte Schnittstelle PDL_Data stets die aktuellen Werte.

2 EINORDNUNG DER ARBEIT

Für die Konfiguration (Abbildung 2.1.5) der

Komponente ServerConnection wird eine Konfigurationsschnittstelle (SC_Conf) benötigt, die ihr die Einstellungen sowohl über die VisComp-Variablen (an den Prozessdatenlokalisierer), als auch über die verschiedenen Server und die Servervariablen (Kommunikationsstub) übergibt.

Dieser Arbeit liegt eine Version der Komponente ServerConnection (Abbildung 2.1.6) zu Grunde, welche als Server die Datenquellen ModbusTCP, OPC XML DA, OPC UA und MMS unterstü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 Visualisie-

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.

2 EINORDNUNG DER ARBEIT

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) entwickelt. Zur Zeit der Fertigstellung dieser Arbeit ist der Web-Service

„http://192.168.35.19:8080/“ erreichbar, die zugehörige wsdl-Datei ist dem Anhang A2-1 beigefügt. Der Webservice 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 Hypertext-Übertragungsprotokolls (engl.: Hypertext Transfer Protocol, http) bereit. Somit ist eine direkte, plattformunabhängige Verfügbarkeit der Prozessdaten gewährleistet.

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

2 EINORDNUNG DER ARBEIT

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.

Die Komponente „MasterWS“ stellt zur Fernsteuerung der sich am Lehrstuhl Automatisierungstechnik der TU Dresden befindlichen Kleinversuchsanlage über einen http - Aufruf folgende 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) aufgerufen 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“).

2 EINORDNUNG DER ARBEIT

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 EINORDNUNG DER ARBEIT

2.2. Aufgabenstellung/ Sollzustand

2.2.1. Funktionale Anforderungen

Anforderung 1

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

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) vorgestellten Methoden zur Fernalarmierung (E-Mail, SMS, Anruf), sich auf dem vorhandenen 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 weitergeleitet.

Visualisierung einer Anlagensteuerung auf kleinem Display Anforderung 3

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. Interaktives Navigieren durch die graphische Benutzeroberfläche Anforderung 4

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. Weiterentwicklung der ServerConnection Anforderung 5

Die im Rahmen der Arbeit [2] entwickelte Komponente ServerConnection muss so erweitert werden, dass die Konfiguration zur umgesetzten Fernalarmierung (Anforderung 2) mit allen nötigen Parametern in einem geeigneten Format zur Entwurfszeit definiert werden kann.

Konzeption von Transformationsvorschriften Anforderung 6

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.

DIPLOMARBEIT, ANDREAS WIEDENFELD

12

2 EINORDNUNG DER ARBEIT

2.2.2. Anforderungen an die Systemtechnik

Anforderung 7

Die Speicher-Programmierbare-Steuerung

(SPS) muss über einen Internetzugang verfügen, damit sie ferngesteuert werden kann.

Anforderung 8

Die Kommunikation zur SPS wird über den

Tomcat Webserver von Apache realisiert. Dabei stellt der Axis WebService die benötige Java-Laufzeitumgebung bereit.

Anforderung 9

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

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

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 Breitband-Internetverbindung (z.Bsp. UMTS) verfügen.

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

2 EINORDNUNG DER ARBEIT

2.2.3. Randbedingungen, nicht funktionale Anforderungen stabile Datenverbindung Anforderung 11

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

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. Sicherheit Anforderung 13

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 EINORDNUNG DER ARBEIT

2.2.4. Qualitätsmerkmale

Folgende Qualitätsmerkmale sind im weiteren Entwicklungsverlauf als grundlegend zu betrachten: 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.

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 implementieren. Dazu werden im folgenden Kapitel die in der Prozessleittechnik häufig eingesetzten Methoden zur Fernalarmierung analysiert und drei Wege der Kommunikation näher untersucht. 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 Kurzmitteilungsdienste (engl.: Short Message Services, SMS) verschiedener Mobilfunkanbieter, um Mitarbeiter in Bereitschaft automatisch vom Prozessleitsystem informieren zu lassen. Im Baugewerbe beispielsweise ist es nicht nur wichtig den aktuellen Aufenthaltsort einer Maschine zu kennen, sondern auch Informationen über die Dauer des Einsatzes zu erhalten, da Ausfallzeiten 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überwachung.

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. DIPLOMARBEIT, ANDREAS WIEDENFELD

17

3 FERNALARMIERUNG

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/ In- ternet 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.

3 FERNALARMIERUNG

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 FERNALARMIERUNG

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].

3.4.1. Ablauf der Kommunikation

Die Nachricht setzt sich aus einem Header (grundlegende Informationen über Absender, Empfä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, sondern 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. DIPLOMARBEIT, ANDREAS WIEDENFELD

20

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].

3 FERNALARMIERUNG

3.5. Mobilfunkanruf

Ein selektiver Anruf über das Mobilfunknetz ist unmittelbar vergleichbar mit dem Kurzmitteilungsdienst in GSM [10]. Allerdings wird beim Anruf eine direkte Verbindung zwischen Sender und Empfänger aufgebaut.

3.5.1. Ablauf der Kommunikation

Die Kommunikation besteht lediglich aus dem Verbindungsaufbau durch das Anrufen des Empfängers. Dazu wird dessen Nummer von der Sendeeinrichtung gewählt und über das Telefonnetz versucht eine Verbindung herzustellen. Ist das Empfangsgerät erreichbar („es klin-

gelt“), war die Kommunikation erfolgreich, der Empfänger wird dabei allein durch den Anruf über einen vorliegenden Alarmfall in-formiert [Abbildung 3.5.1], die Verbindung wird nach einer bestimmten „Klingelzeit“ serverseitig abgebaut. Bei diesem „Pull-Dienst“ muss der Client nach jedem Aufwecken durch den Server eine eigenständige Anfrage an den Server starten um aktuelle Informationen zu erhalten.

Im Gegensatz dazu ist es bei „Push-Diensten“ wie E-Mail oder SMS möglich, Informationen direkt bei der Alarmweiterleitung serverseitig auszuliefern, und so den Empfänger über aktuelle Geschehnisse zu informieren ohne dass er eine zusätzliche Anfrage starten muss. 3.5.2. Zuverlässigkeit der Nachrichtenübertragung

Während SMS den Empfang einer Nachricht über kurz oder lang garantieren und bestätigen kann, ist ein Fehlschlagen des Anrufs möglich. Es erfolgt jedoch eine sofortige Rückmeldung über den Verbindungsstatus [Abbildung 3.5.2].

Die sehr hohe Netzabdeckung Mitteleuropas [Abbildung 3.5.3] hat entscheidenden Einfluss auf die hohe Zuverlässigkeit der Mobilfunknetze. Die Mobilfunknetze und die SMS-Zentralen sind vom Verband der Sachversicherer (VDS) als Basis für Sicherungssys- teme zugelassen [5].

3  FERNALARMIERUNG  

Abbildung  3.5.3: Verbreitung des Mobilfunknetzes (GSM) in Mittel-Europa  11

DIPLOMARBEIT  , ANDREAS WIEDENFELD  

23