Dipl.-Ing. Christian Baumann

Distributed Information Exchange

Auszug aus der Dissertation "Company Wide Web (CWW) - Einsatz von Intranets im Bereich der industriellen Kommunikation"
Institut für Fertigungstechnik, Technische Universität Wien, August 1997, Veröffentlichungstermin: Jänner 1998.

Inhaltsverzeichnis

1 Einleitung
2 Anforderungen

2.1 Kommunikationsarchitektur
2.2 Protokoll
2.3 Interface

3 Aufbau der Architektur DIE

3.1 Application
3.2 Interface
3.3 Objects
3.4 Object-Handler
3.5 Channel

4 Das Protokoll DIEP

4.1 Funktionsweise
4.2 Strukturierung der Daten
4.3 Anfrage (Request)
4.4 Antwort (Reply)

5 IIPLS als DIE-Prototyp

5.1 Einleitung
5.2 IIPLS-Variablenserver
5.3 DIE-Tester
5.4 IIPLS-Variablenbrowser

6 Zusammenfassung

7 Literatur

1 Einleitung

Wie z.B. in [CB96] und [CB97] beschrieben, stößt der Einsatz von Internet-Technologien für industrielle Kommunikationssysteme in manchen Anwendungsbereichen an seine Grenzen, d.h. daß manche Anforderungen durch den Einsatz von Intranets nicht optimal zu erfüllen sind. Dies führt zur Forderung, für diese Problembereiche neue Lösungen zu realisieren, was in diesem Kapitel durch die Entwicklung eines neuen Kommunikationskonzeptes durchgeführt wird. Dieses Konzept, vom Autor "D.I.E.P.E." - "Distributed Information Exchange in Production Environments" benannt, benutzt dabei die vorhandenen Internet-Technologien als Basis und ergänzt bzw. erweitert sie in den angesprochenen Problembereichen.
D.I.E.P.E. basiert einerseits auf den praktischen Erfahrungen, andererseits auf den theoretischen Erkenntnissen des Autors. Es ist daher sowohl durchgängig konzipiert und daher in weiten Bereichen anwendbar, als auch gleichzeitig mit angemessenem Aufwand zu implementieren und damit praxistauglich.
Das Konzept besteht aus einer Kommunikationsarchitektur, welche ein Kommunkationsprotokoll benutzt. Um externe Systeme in die Architektur zu intregrieren, müssen entsprechende Schnittstellen definiert werden. Im folgenden werden die Anforderungen an diese Komponenten von "D.I.E." zusammengefaßt.

Zurück zum Inhaltsverzeichnis

2 Anforderungen

2.1 Kommunikationsarchitektur

Einen integralen Bestandteil des gesamten Konzeptes bildet die Definition und Entwicklung einer neuartigen Kommunikationsarchitektur ("D.I.E" - "Distributed-Information-Exchange"), die folgende Zielsetzungen erfüllen muß:

• Die Definition von DIE baut auf die bestehende Architektur des Inter-/Intranet bzw. des WWW auf, soll sie also erweitern und nicht ersetzen.

• Mehrere Kommunikationsverbindungen müssen ungehindert parallel abgewickelt werden können, z.B. Kommunikation nach DIE, Intranetanwendungen, Web-Anwendungen, proprietäre Anwendungen, die über TCP/IP kommunizieren, sowie Datenübertragung über andere Netzwerkprotokolle, die parallel mit TCP/IP betrieben werden können.

• Die Einrichtung eines Multi-Client/Multi-Server-Systems muß möglich sein. Das bedeutet, daß Informationen möglichst direkt am Ort ihres Entstehens von entsprechend "kleinen" und autarken Servereinheiten zum Abruf bereitgehalten werden. Die Daten werden direkt an eine oder mehrere Partnerapplikationen verteilt.

• Parallel dazu muß nach wie vor der Einsatz des klassichen Client-Server Modells möglich sein, d.h. wenige "mächtige" Server, die Daten von vielen Quellen verarbeiten.

• Die Möglicheit für einen synchronen Datenaustausch muß gegeben sein, d.h. ein Server muß von sich aus die Kommunikation mit einem Client initiieren können.

• Die Definition von Ereignissen, die Datensendungen auslösen, muß möglich sein. Dabei sind Prioritätsmechanismen vorzusehen, d.h. bestimmte Applikationen erhalten die Daten vor anderen.

• Die effiziente Übertragung hoch- und höchstdynamischer Daten muß ermöglicht werden, dabei darf kein unnötiger Overhead entstehen.

• Die Architektur soll besonders an die Gegebenheiten in LANs angepaßt sein, d.h. deren Vorteile (Bandbreite etc.) gegenüber WANs sollen genutzt werden.

2.2 Protokoll

Zur Realisierung der Architektur ist die Entwicklung eines Übertragungsprotokolls ("D.I.E.P." - "Distributed-Information-Exchange-Protocol") nötig, welches folgenden Anforderungen nachkommt:

• DIEP dient zum flexiblen (zyklischen und/oder ereignisgesteuerten), synchronen Austausch von Anwendungsdaten innerhalb einer Multi-Client/Multi-Server-Architektur.

• Darüber hinaus werden mit DIEP Statusinformationen der beteiligten Partnersysteme ausgetauscht.

• Die Funktionsweise von DIEP ähnelt den existierenden TCP/IP-Protokollen (wie z.B. HTTP), allerdings mit der grundlegenden Erweiterung, daß eine Kommunikation sowohl client- als auch serverseitig initiiert werden kann.

• Die Basis des Protokolls ist TCP/IP. DIEP ist in der Schicht 5 (Anwendungsschicht) der TCP/IP Protocol-Suite angesiedelt, vergleichbar mit den Protokollen FTP, Telnet oder HTTP.

• DIEP muß die wahlweise Verwendung von TCP und UDP erlauben, wobei für sicherheitskritische Anwendungen TCP eingesetzt wird und UDP dann, wenn höhere Übertragungsgeschwindigkeiten notwendig sind.

• Zum Austausch von Statusinformationen, Rundsendemeldungen etc. wird UDP verwendet.

2.3 Interface

Zur Einbindung von Fremdsystemen sind Schnittstellenspezifikationen zu erstellen. Um dabei besonders auf die Einbindung von technischen/industriellen Anwendungen zu achten, müssen folgende Punkte erfüllt werden:

• Im Softwarebereich müssen die Schnittstellen einen möglichst weiten Bereich abdecken, wie beispielsweise:

• Datenbankschnittstellen (lokal, netzwerkweit),

• Betriebssystemspezifische Schnittstellen (OLE, DDE etc.),

• Fileschnittstellen (binäre und Textfiles),

• Mailer-Schnittstellen etc.

• Vergleichbares gilt für den Hardwarebereich. Schnittstellen zu den gängigsten Systemen im Werkstattbereich müssen vorgesehen werden, z.B. zu

• Feldbus-Systemen

• Sensor-Aktor-Bussen

• seriellen Geräten etc.

• Um den Einsatz von Interfaces so flexibel wie möglich zu gestalten, müssen diese in weiten Bereichen frei konfiguriert werden können.

• Zur Realisierung von Schnittstellen sind APIs in gängigen Programmiersprachen zu definieren (C, Pascal, Java).

In Abbildung 2-1 sind einige der Schnittstellen, die im Bereich der industriellen Kommunikation auftreten, dargestellt.

Abbildung 2-1: DIE Schnittstellen

Zurück zum Inhaltsverzeichnis

3 Aufbau der Architektur DIE

Ziel der Kommunikationsarchitektur ist der effiziente, dynamische und ereignisgesteuerte Austausch von Daten. Diese Daten entstehen an verteilten Quellen und müssen an verteilte Ziele übertragen werden, wobei der Datenaustausch virtuell auf Applikationsebene stattfindet.

Abbildung 3-2: Aufbau von DIE

Der Begriff "Application" wird im Zusammenhang mit DIE als Software verstanden, welche auf einem beliebigen Hardwaresystem ablaufen kann. Die einzige Anforderung an ein solches System ist, daß es in ein TCP/IP-Netzwerk integriert werden kann, also einen Netzwerkanschluß und einen IP-Stack (z.B. im Betriebssystem integriert) aufweisen muß. Die Applikation kann in jeder Programmiersprache realisiert werden, die am Zielsystem zur Verfügung steht und auf den IP-Stack zugreifen kann. Darüber hinaus kann die Applikation über beliebige Interfaces auf weitere sog. "externe Ressourcen" zugreifen (Feldbussysteme, SPS, serielle Geräte etc.). Eine Applikation spricht über ein Interface einen Kommunikationsmodul an, dieser besteht aus "Objects", dem "Object-Handler" sowie einem "Channel".
Abbildung 3-2 zeigt den Aufbau der Kommunikationsarchitektur DIE, im folgenden werden die einzelnen Komponenten beschrieben. Um die Beschreibungen besser darstellen zu können, wird folgendes Beispiel (Abbildung 3-3) herangezogen:

Abbildung 3-3: Beispielsystem DIE

Im Beispielsystem laufen drei Applikationen:

1. Ein Prozeßleitsystem (PLS), welches über eine SPS (externe Ressource) mehrere Anlagen steuert. Am PLS laufen die zwei Kommunikationsmodule C1 und C2. (Bemerkung: Dieselbe Funktionalität könnte auch mit nur einem Modul erzielt werden).

2. Ein Visualisierungssystem mit Bedienfunktion (VIS), welches den Zustand der Anlage darstellt und dem Benutzer die Möglichkeit gibt, die Anlage ein- bzw. auszuschalten. Auch auf diesem System existieren zwei Kommunikationsmodule.

3. Eine Datenbankapplikation, welche alle Daten der Anlage aufzeichnet (LOG). Sie wird über ein Kommunikationsmodul mit Daten beschickt.

Im Beispielsystem sind zwei Objekte definiert. Der Wert des Objekts "Füllstand" wird von PLS geschrieben und an VIS und LOG übergeben. Der Wert von "Betriebszustand Setzen" wird von VIS gesetzt und an PLS und LOG übertragen.

3.1 Application

Wie bereits erwähnt, sind die Applikationen jene Elemente, die virtuell miteinander kommunizieren. Die eigentliche Kommunikation wird aber vom Object-Handler abgewickelt. Abstrakt gesehen stellen Applikationen Daten für Partnersysteme bereit bzw. fordern Daten von diesen an, indem sie Inhalte von Objekten beschreiben bzw. lesen.
Die Zuordnung zwischen Applikationen und Kommunikationsmodulen ist flexibel realisierbar. So kann ein Modul von mehreren Applikationen verwendet werden oder eine Applikation mehrere Module benützen (siehe Abbildung 3-2). Da auf einem Rechnersystem (in einer Multitaskingumgebung) mehrere Applikationen ablaufen können, könnte eine Kommunikation mit DIE auch als lokale Schnittstelle zwischen Anwendungen verwendet werden.
Applikationen, die auch mit externen Ressourcen kommunizieren, sind z.B.:

• Barcodesysteme, die über ein Netzwerk die Daten von verteilten Lesegeräten sammeln.

• BDE-Systeme, die über serielle Leitungen mit den angeschlossenen Terminals kommunizieren.

• Ein Prozeßleitsystem, welches über einen Prozeßbus mit den einzelnen Steuerungen verbunden ist.

Applikationen ohne externe Ressourcen sind beispielsweise:

• Datenbankapplikationen wie Progress, Oracle etc. unter den Betriebssystemen Unix, WindowsNT, VMS etc.

• Integrierte Gesamtpakete, wie SAP oder Pro-Alpha.

• Schedulingprogramme (z.B. Preactor);

• Visualisierungspakete;

• Java-Applets, die innerhalb einer HTML-Seite unter Kontrolle eines Webbrowsers ablaufen.

• Java-Programme (unabhängig von der Betriebssystemplattform).

• Weitere beliebige Programme, die den unter 3 geschilderten Anforderungen bezüglich TCP/IP-Integration entsprechen.

Weiters steht die Möglichkeit offen, die Funktionen der Schichten "Application" bis "Object-Handler" in einer einzigen Anwendung zusammenzufassen, um auch spezielle Anforderungen abzudecken, wie z.B. Systeme ohne Multitaskingfähigkeit, mit wenig Speicher, geringer Rechenleistung etc.

3.2 Interface

DIE-Interfaces bilden die Schnittstellen zwischen der Applikation und dem Kommunikationsmodul, indem sie der Applikation Zugriff auf die Objekte ermöglichen. Interfaces können entweder direkt auf (den Speicherbereich der) Objekte zugreifen oder durch Aufruf von Funktionen des Object-Handlers. Die Art des Zugriffs ist davon abhängig, ob ein Interface direkt an die Applikation oder an den Object-Handler gekoppelt ist.
Die direkte Kopplung an die Applikation wird mit Programmbibliotheken realisiert (z.B. DLLs), im anderen Fall werden betriebssystemabhängige Funktionen, wie z.B. DDE oder OLE unter Windows, verwendet. In Abbildung 3-4 werden die beiden Varianten dargestellt.

Abbildung 3-4: Interfacetypen

3.3 Objects

Objekte stellen die zentralen Elemente der Kommunikationsarchitektur aus Sicht der Applikation dar. Sie beinhalten jene Daten, die zwischen den Applikationen ausgetauscht werden. Obwohl sich jedes Objekt physisch auf einem bestimmten Rechner (bzw. in dessen Speicher) befindet, haben alle Anwendungen eine eindeutige Sicht auf alle Objekte.
Ein Objekt ist charakterisiert durch:

• eine systemweit eindeutige Bezeichnung, welche sich aus der Bezeichnung des Kommunikationskanals (s.u.), einem Object-Path und der Object-ID zusammensetzt.

• Einen Datentyp bzw. eine Datenstruktur;

• einen Wert;

• Angabe einer Source, d.h. welche Applikationen haben Schreibzugriff auf die Daten.

• Angabe von Targets, d.h. welche Applikationen können die Daten des Objekts anfordern.

• Definition von Ereignissen, aufgrund derer die Daten an die Targets übertragen werden. Die Übertragung kann einmalig ausgelöst werden, zyklisch oder bei anderen Ereignissen, wie z.B. das Über-/Unterschreiten von Grenzwerten, die absolute oder relative Änderung von Werten oder jede beliebige Kombination daraus.

In den beiden folgenden Tabellen sind die Objektdefinitionen für die im Beispiel gezeigte Konfiguration enthalten.
 

Tabelle 3-1: Objektdefinition für "Füllstand"
 

 Tabelle 3-2: Objektdefinition für "Betriebszustand Setzen"

3.4 Object-Handler

Der Object-Handler ist jener Teil der Architektur, der die eigentliche Kommunikations-funktionalität leistet. Seine Aufgaben sind:

• Die Verwaltung der Objekte, d.h. Anlegen, Ändern und Löschen.

• Der Empfang von Daten über den "Listener"-Teil des Channels (s.u.) und die Verarbeitung, d.h. Setzen des Wertes des entsprechenden Objektes.

• Der Empfang von Objekt-Anforderungen der Partnersysteme und deren Eintrag in die Ereignisliste des Objektes.

• Die Abarbeitung der Ereignislisten und bei Bedarf das Senden der Daten an den/die Partner über den "Talker"-Teil des Kanals.

Provider/User

Die Funktionalität des Object-Handlers kann in zwei Bereiche gegliedert werden, wovon nur ein Teil vorhanden sein muß. Diese Trennung kann verwendet werden, um bei Bedarf die Implementierung zu vereinfachen.
Der Provider-Teil beinhaltet alle Funktionen, die mit der Verwaltung und Bearbeitung der Objekte zusammenhängt. Ein Provider kann Anfragen erhalten und abarbeiten, aber selbst keine fremden Objekte anfordern. Im Gegensatz dazu verwaltet ein User keine lokalen Objekte, sondern kann nur auf Objekte von Providern zugreifen.
Die in Abschnitt 4 vorgestellte Implementierung des DIE-Protokolles zeigt ein Beispiel für eine derartige Trennung. Auch die in der Beispielkonfiguration verwendeten Module können in Provider und User gegliedert werden (siehe auch Tabelle 3-3).

Object-Server

Ein weiterer Sonderfall ist möglich: Der Betrieb eines Object-Handlers ohne übergelagerte Applikation. Auf diese Weise kann z.B. ein Object-Server realisiert werden, dessen Aufgabe darin besteht, (große Mengen an) Daten zu verwalten (anzufordern, zu empfangen, zu speichern, bei definierten Ereignissen weiterzuleiten etc.).

3.5 Channel

In der oberen Schicht der Architektur kommunizieren die Applikationen "virtuell" miteinander. Auf Ebene des Channels wird die Datenübertragung "real" abgewickelt. Da IP den Einschränkungen der Client-Server Architektur unterliegt (Server kann nicht von sich aus Daten an einen Client senden), umfaßt ein DIE-Channel je einen Server- und einen Client-Teil. Um Unklarheiten zu vermeiden, werden bei DIE statt "Client" und "Server" die Begriffe "Talker" und "Listener" verwendet.
Sowohl Talker als auch Listener benötigen für ihre Aufgabe je einen IP-Socket, d.h. einen eindeutigen Kommunikationskanal in einem IP-Netzwerk, bestehend aus IP-Adresse und Portnummer. Aus Sicht der Kommunikationsarchitektur ist nur der Port des Listeners relevant, dieser muß den jeweiligen Partnermodulen bekannt sein. Die Datenübertragung über IP kann wahlweise mit TCP oder UDP erfolgen.
Die Adresse eines Channels muß systemweit eindeutig sein (was bereits durch die IP-Sockets erzwungen wird) und wird wie folgt aufgebaut:
<IP_Adresse_Host>:<Portnummer_Listener>
Alternativ zu diesem Adressierungsschema ist im vorliegenden Konzept auch eine Zuweisung von Namen zu den IP-Adressen bzw. Portnummern angedacht. Dies würde die Übersichtlichkeit der Konfiguration eines Gesamtsystems wesentlich erleichtern, aber ein eigenes Service, vergleichbar mit DNS, erfordern.

In Tabelle 3-3 ist das Adressierungsschema der in diesem Abschnitt verwendeten Beispielkonfiguration angeführt.
 

Tabelle 3-3: Adressierung der Kanäle

Zurück zum Inhaltsverzeichnis

4 Das Protokoll DIEP

4.1 Funktionsweise

In Abbildung 4-5 ist die grundlegende Funktionsweise des Protokolls DIEP dargestellt: Ein User benötigt bestimmte Daten von einem Provider und stellt eine Anfrage. Aufgrund der Objektdefinition ergeben sich die Adresse des Providers (IP-Adresse + Port) und die Adresse des Objekts selbst. Der Talker-Teil des Users sendet die Anfrage an den Listener-Teil des Providers. Der Provider sendet eine Antwort (Reply) über seinen Talker-Teil an den Listener-Teil des Users. Die Zieladresse wird aus dem Request entnommen (s.u.).

Abbildung 4-5: Funktionsweise von DIEP

Dieses Prinzip klingt simpel, unterscheidet sich aber grundlegend von allen anderen Protokollen, die in der TCP/IP Protocol-Suite Verwendung finden:
Der erste Unterschied besteht darin, daß für DIEP immer zwei Sockets verwendet werden. D.h. einerseits, daß nach Übertragung eines Telegrammes (Request oder Reply) der Socket sofort wieder geschlossen bzw. freigegeben werden kann, und somit für andere Kommunikationsverbindungen zur Verfügung steht. Andererseits bedeutet es, daß zur Übertragung entweder das zuverlässigere Protokoll TCP oder das schnellere und flexiblere UDP verwendet werden kann.
Darüber hinaus zeigt sich ein weiterer Unterschied zu den Standard TCP/IP-Protokollen. Da auch der User über einen Listener verfügt, sind Request und Reply voneinander völlig getrennt. Deshalb kann die Antwort vom Provider entweder sofort abgesetzt werden oder einmal bzw. mehrfach zu beliebigen späteren Zeitpunkten, z.B. zyklisch oder bei bestimmten Ereignissen.
Die in 3.4 angedeutete Möglichkeit der Trennung von Provider- und Userfunktionalität läßt eine Anzahl von Varianten zu, die je nach Bedarf bzw. gegebenen Rahmenbedingungen eingesetzt werden können (siehe Abbildung 4-6). In einem Gesamtsystem können beliebige Varianten gemischt werden.

Abbildung 4-6: Provider/User Varianten
 

Variante 1

In dieser Variante sind Provider und User in einem Modul integriert. Beide verwenden einen gemeinsamen DIE-Channel (d.h. Talker und Listener).Variante 1 wird zum Einsatz gebracht, wenn ein System sowohl Objekte zur Verfügung stellt, als auch auf Objekte anderer Provider zugreift. Die Implementierung der Variante ist relativ komplex, dafür ist ein derartiges System flexibler einsetzbar, als z.B. die Varianten 3, 4 und 5. Nach Variante 1 aufgebaute Systeme können mit allen anderen Varianten kommunizieren.

Variante 2

Wie in Variante 1 sind auch in diesem Fall Provider und User in einem Modul integriert. Der Unterschied besteht darin, daß für Provider und User jeweils ein eigener Channel zur Verfügung steht. Durch diese Trennung können Sicherheitsaspekte erfüllt und Performanceprobleme gelöst werden. Der Nachteil der Variante 2 besteht darin, daß sowohl die Implementierung als auch die Verwaltung komplex sind. Darüber hinaus benötigt ein System der Variante 2 vier Sockets. Systeme, die nach den Varianten 1 und 2 aufgebaut sind, können für alle Anwendungszwecke eingesetzt werden. Daher kann kein "typisches" Einsatzgebiet angegeben werden.

Variante 3

In dieser Variante wird nur der Providerteil implementiert und mit Talker und Listener ausgestattet. Diese Art bietet sich an, wenn ein System lediglich Objekte zur Verfügung stellt, aber keinen Zugriff auf Objekte anderer Provider benötigt. Die Implementierung ist weniger komplex als bei den Varianten 1 und 2. Ein typisches Einsatzgebiet für die Variante 3 sind "black-box" Systeme, wie z.B. der in 5.2 beschriebene IIPLS-Variablenserver.

Variante 4

Diese Variante stellt das Gegenstück zu Variante 3 dar. In diesem Fall ist lediglich der User Teil implementiert. D.h. diese Variante kann selbst keine Objekte zur Verfügung stellen, sondern benötigt einen Provider, z.B. Variante 1, 2 oder 3. Ein System dieser Art ist relativ einfach zu implementieren. Ein typisches Einsatzgebiet ist ein Visualisierungssystem, beispielsweise basierend auf Java-Applets, das je nach dargestellter Seite von den entsprechenden Providern nur die notwendigen Objekte anfordert; damit können überflüssige Datenübertragungen vermieden werden. Ein anderes Beispiel für einen User nach Variante 4 ist der in Abschnitt 5.3 beschriebene DIE-Tester.

Variante 5

Diese Variante besteht aus einem User, der lediglich den Listener-Teil des Channels besitzt. Eine derartiger User ist zwar am einfachsten zu implementieren, kann aber von sich aus keine Objekte anfordern und benötigt daher einen Object-Manager (siehe Variante 6). Durch die Möglichkeit der einfachen Implementierung eignet sich ein User der Variante 5 sehr gut zur Realisierung von ereignisgesteuerten Schnittstellen zu Fremdsystemen. Ein typisches Beispiel ist die Schnittstelle zwischen einem PPS- und einem BDE-System. Sobald die BDE neue Daten liefert (z.B. bei Rückmeldungen), werden diese per DIE an das PPS-System übergeben. Eine derartige Implementierung kann herkömmliche Schnittstellen (z.B. Polling) ersetzen.
Auch der in Abschnitt 5.4 entwickelte IIPLS-Variablenbrowser ist nach dieser Variante implementiert.

Variante 6

Mit dieser Variante wird ein Object-Manager implementiert. Der Object-Manager muß eingesetzt werden, wenn in einem Gesamtsystem ein oder mehrere User nach Variante 5 verwendet werden. Diese beinhalten keinen Talker und können daher von sich aus keine Daten anfordern. Diese Aufgabe wird von Variante 6 übernommen. Darüber hinaus kann der Object-Manager auch Daten für andere User (Varianten 1, 2 und 4) anfordern. Der Vorteil dieser Strategie ist, daß in einem Gesamtsystem bei Bedarf an einem zentralen Punkt festgelegt werden kann, welche Provider welche Objekte (Daten) unter welchen Bedingungen an welche User übertragen. Ein System nach Variante 6 benötigt nicht unbedingt einen Listener-Teil. Die Implementierung eines solchen empfiehlt sich aber trotzdem, da damit der Object-Manager selbst z.B. von einem anderen System fernbedient werden kann. Der im Abschnitt 5.3 beschriebene DIE-Tester kann (im manuellen Betrieb) die Funktion eines Object-Managers erfüllen.
 

4.2 Strukturierung der Daten

Die Strukturierung der Daten, die von einem Provider gehalten werden, steht in unmittelbarem Zusammenhang mit der Adressierung der Objekte, die in 3.3 behandelt wurde. Der Provider ist durch seine Kanalbezeichnung eindeutig identifiziert, die Daten werden durch "Object-Path" und "Object-ID" referenziert (siehe z.B. Tabelle 3-1).
Damit entspricht die Strukturierung einem "Baum", wie er auch z.B. bei Verzeichnissen oder einem URL verwendet wird. Die Anzahl der Ebenen des Object-Path ist beliebig wählbar, so können sowohl einfache (flache) als auch komplexe (tiefe) Strukturen abgebildet werden. Abgesehen von den Applikationsdaten (Objekten) sind auch bestimmte Systemobjekte festgelegt. Diese haben vorgegebene Bezeichnungen und beinhalten Informationen über den Provider selbst (Softwarebezeichnung und -version, Protokollversion, Betriebszustand etc.). Folgendes Beispiel soll die Strukturierung der Daten veranschaulichen:

/Anlage_A/Betriebszustand
/Anlage_A/Fuellstand_1/Ist
/Anlage_A/Fuellstand_1/Soll
/Anlage_A/Fuellstand_2/Ist
/Anlage_A/Fuellstand_2/Soll
/Anlage_A/Drehzahl/Ist
/Anlage_A/Drehzahl/Soll
/Anlage_B/...
/...
/sys/protocol
/sys/software
/sys/alive
/...

Zur Auswahl mehrerer Objekte können diese auch mittels Jokerzeichen "*" adressiert werden, beispielsweise

/Anlage_A/Fuellstand_*/Ist
/sys/*
...

4.3 Anfrage (Request)

Ein Request wird von einem User an einen Provider abgesetzt. Ein Request betrifft entweder das Lesen (Anfordern des Wertes eines Objektes) oder das Schreiben (Setzen des Wertes) von Daten. Je nach Art einer Anforderung resultiert diese entweder in einer einmaligen oder mehrfachen Antwort. Eine Anfrage hat folgenden Aufbau:

[User_Listening_Channel] Request_Type /Object-Path/Object-ID [?Parameter] <CRLF>

User_Listening_Channel: Dieser wird benötigt, um dem Provider mitzuteilen, an welchen Socket eine Antwort zu senden ist. Abhängig davon, wo sich der User befindet, existieren drei Möglichkeiten.

• Wenn sich der User am selben Rechner wie der Provider befindet (selbe IP-Adresse) und den Defaultwert für den Listeningport (2051) verwendet, kann die Angabe entfallen.

• Wenn Provider und mehrere User am selben Rechner laufen, muß lediglich der jeweilige Port angegeben werden.

• Wenn Provider und User auf verschiedenen Rechnern betrieben werden (was i.d.R. der Fall ist), ist der Wert im Format <Port_Nr@IP_Adresse> zu übertragen, also z.B. "3075@172.16.1.18". Dieses Format muß auch angewendet werden, wenn ein Object-Manager Anfragen im Namen von anderen Usern abschickt.

Request_Type: Ist abhängig davon, ob Daten angefordert oder geschrieben werden, entweder "GET" oder "PUT".

Object-Path/Object-ID: Geben die Adresse des gewünschten Objektes an, wobei auch die Verwendung von Jokerzeichen möglich ist.

Parameter sind abhängig von der Art des Requests. Bei GET können folgende Parameter verwendet werden:

• ONCE: Die einmalige Übertragung von Daten wird angefordert. Dieser Wert ist auch als Defaultverhalten definiert, d.h. wenn bei einer GET-Anfrage kein Parameter vorhanden ist, wird diese vom Provider wie eine Anfrage mit ONCE interpretiert.

• CYCL=<interval>: Die angeforderten Daten sollen vom Provider zyklisch übertragen werden, wobei <interval> den Zeitabstand zwischen den Übertragungen in Millisekunden festlegt. Mit CYCL=-1 wird die zyklische Anfrage gestoppt.

• EVENT=<delta>: Die angeforderten Daten werden vom Provider immer dann gesendet, wenn sich eine Änderung um den Wert <delta> ergeben hat. Abhängig vom Datentyp kann <delta> nur in bestimmten Bereichen liegen, z.B. bei Binärvariablen und Zeichenketten bedeutet <1> soviel wie "jede Änderung". Mit EVENT=-1 wird die ereignisgesteuerte Anfrage beendet.

Bei einem Request mit PUT muß als Parameter der Wert des zu schreibenden Objektes angegeben werden.

"<CRLF>": Dieses Symbol legt das Ende einer Anfrage fest. Da sowohl User als auch Provider auf unterschiedlichen Rechner- bzw. Betriebssystemplattformen implementiert sein können (die verschiedene Zeichen für Zeilenende verwenden), muß jede Kombination der Zeichen (Hex) 0D und 0A als "<CRLF>" erkannt werden.

4.4 Antwort (Reply)

Die Anfragen der User werden vom Provider beantwortet, wobei der Zeitpunkt der Antwort(en) vom Typ des Requests abhängt. PUT und ONCE-Requests werden sofort beantwortet, Anfragen mit CYCL oder EVENT werden in entsprechende Listen eingetragen und abgearbeitet. Das Ziel (IP-Adresse und Port) der Antwort wird aus dem "User_Listening_Channel" des Requests ermittelt, wie oben dargestellt.
Ein Reply besitzt folgenden Aufbau:

ReplyCode<CRLF>
<CRLF>
ReplyString<CRLF>

Beispiel:

200 OK

X/Y/Z=123

ReplyCode: Dieser Code beinhaltet Status- bzw. Fehlerinformationen sowie, im Falle einer Datenübertragung, den Anfragetyp, welcher die Übertragung ausgelöst hat. Wenn kein Fehler auftritt, liegt der Code in einem Bereich von 200 bis 299, im Fehlerfalle darüber. Tabelle 4-4 zeigt die in der derzeitigen Protokollversion definierten Codes, Klassen und Bedeutungen.
 
 

Tabelle 4-4: DIE Replycodes

ReplyString: Wenn der Statuscode aus der Klasse "OK" stammt, beinhaltet dieser String die vom User angeforderten Daten; bei "Error" jenes Objekt, auf welches sich der Fehler bezieht, falls anwendbar. In der vorliegenden Version von DIE darf der Replystring ausschließlich aus ASCII-Zeichen bestehen. Die für eine Übertragung von binären Daten erforderliche Codierung (z.B. lt. MIME) ist für eine spätere Protokollversion vorgesehen.
In Abbildung 4-6 ist ein Beispiel für eine Kommunikation mit dem DIE-Protokoll aufgezeigt (die <CRLF>-Sequenzen wurden in der Darstellung nicht berücksichtigt). Die ersten beiden Zeilen beinhalten eine einmalige Abfrage des Objektes "/VARS/X" mit entsprechender Antwort. In Folge wird "/VARS/Y" vom User zyklisch angefordert und vom Provider alle 5 Sekunden gesendet. Eine ereignisgesteuerte Abfrage würde analog funktionieren. Klarerweise können verschiedene Abfragen zu beliebigen Zeitpunkten gestartet und gestoppt werden, die Antworten des Providers wären dann entsprechend "verzahnt".
 

Tabelle 4-5: DIEP Beispiel

Zurück zum Inhaltsverzeichnis

5 IIPLS als DIE-Prototyp

5.1 Einleitung

Das Prototypsystem "IIPLS" (Prozeßleitsystem auf Basis der Internet/Intranet-Technologie) wurde entwickelt, um eine erste praktische Anwendung der Architektur DIE zu schaffen und das Protokoll DIEP zu testen (siehe auch [HG97]). Aufgabe des Prototyps ist es, ein verteiltes Prozeßvisualisierungssystem zu schaffen, welches als Front-End einen Webbrowser verwendet, in welchem die Prozeßdaten mit Hilfe von Java-Applets dargestellt werden können. Die serverseitig eingesetzte Hardware besteht aus einem "Open-Controller", einem Rechnersystem, welches eine SPS und einen PC vereint. Der OC realisiert u.a. die Schnittstelle zwischen den unterschiedlichen Netzwerkarchitekturen Prozeßbus und LAN (siehe Abbildung 5-7).

Abbildung 5-7: Aufbau von IIPLS

Im Zuge dieser Entwicklung sind drei Komponenten entstanden, die in den folgenden Abschnitten kurz beschrieben werden. Die in diesem Prototyp verwendete Datenübertragung auf der TCP/IP-Transportschicht basiert auf dem Protokoll UDP.

• Der IIPLS-Variablenserver erfüllt einerseits die Funktionalität eines DIE-Providers, Variante 3 (siehe Abbildung 4-6), andererseits ist er für die Anlieferung der Variablen von speicherprogrammierbaren Steuerungen, die durch einen Prozeßbus miteinander verbunden sind, verantwortlich.

• Ein IIPLS-Variablenbrowser dient zur Anzeige und Verarbeitung der Daten. Im vorliegenden Prototyp wurde ein einfacher Variablenbrowser in Form eines JAVA-Applets realisiert, das z.B. in eine HTML-Seite eingebunden wird und als DIE-User (Variante 5) Daten des Providers empfängt und zur Anzeige bringt.

• Mit dem DIE-Tester wurde ein User (Variante 4) realisiert, mit welchem alle Aspekte des Kommunikationsprotokolls manuell bzw. halbautomatisch getestet und verifiziert werden können.

5.2 IIPLS-Variablenserver

Bei der Entwicklung des Prototyps des Variablenservers wurde im ersten Schritt auf eine Anbindung an ein externes System verzichtet, die zur Verfügung gestellten Prozeßvariablen entsprechen zwar von der Struktur her der Realität, werden aber im vorliegenden System lediglich emuliert.
Die Datenstruktur ist folgendermaßen spezifiziert:
/Stationsnummer/Variablentyp/Variablenoffset
Die Stationsnummer gibt die eindeutige Adresse einer SPS am Prozeßbus an, sie liegt im Bereich von 1 bis 254. Der Variablentyp definiert entweder Analogvariable (X,Y,V,P) oder Binärvariable (E,A,I,C), der Variablenoffset bestimmt die Adresse des Wertes und liegt im Bereich von 0 bis 9999. Gültige Objektadressen (Objectpath + Object-ID) sind also beispielsweise:

/1/E/1
/1/P/88
/3/X/123
...
Zur Emulierung von dynamischen Daten werden vom Variablenserver alle P-Werte automatisch inkrementiert.
Der Server ist als Multithreadingprogramm implementiert, wobei der Thread "Listen" für den Empfang und Abarbeitung von Requests zuständig ist. Der Thread "Timer" wird zyklisch gestartet und arbeitet die CYCLE- und EVENT-Anfragen ab. Der zusätzlich vorhandene Thread "Input" erlaubt für Testzwecke manuelle Eingaben von Daten in das Prozeßabbild. Der Server benutzt die in DIEP definierten Default-Listeningports von 2050 für den Provider und 2051 für den User.

Abbildung 5-8: IIPLS-Variablenserver als DIE-Provider

Abbildung 5-8 zeigt die Oberfläche des IIPLS-Variablenservers, auf welcher empfangene Requests und gesendete Replys zu Debugzwecken angezeigt werden.

5.3 DIE-Tester

Das Programm DIE-Tester wurde entwickelt, um ein flexibles Testwerkzeug für verschiedene Arten der Kommunikation mit dem Protokoll DIEP zur Verfügung zu stellen. Prinzipiell ist der DIE-Tester als User (Variante 4) ausgelegt. Er kann aber auch manuell als Provider (Variante 3) oder Object-Manager (Variante 6) betrieben werden.
Abbildung 5-9 zeigt die Benutzeroberfläche des Programmes, welche in zwei Hauptsegmente geteilt ist. Die Funktionen werden mit den üblichen Tastaturkürzeln oder mit der Maus aufgerufen. Im oberen Bereich wird der Talker-Teil manuell gesteuert bzw. werden die vom Listener empfangenen Telegramme angezeigt, wobei die Anzeige wahlweise entweder nur den Datenteil oder das gesamte Telegramm umfaßt. Darunter befinden sich Eingabefelder für die IP-Adresse des Providers und für die Listening-Ports von Provider und User. Die entsprechenden Adressen können zur Laufzeit mit neuen Werten initialisiert werden.
Der untere Bereich ermöglicht das automatisierte Lesen und Schreiben von Objekten des IIPLS-Variablenservers. Im linken Teil kann der Wert der analogen Prozeßvariablen "/1/X/1" in einem Bereich von 0 bis 65535 geändert werden, jegliche Änderung wird sofort per PUT-Request an den Variablenserver gesendet. Das gleiche gilt für die binäre Variable "/1/E/1", die per Checkbox umgeschaltet werden kann. Im rechten unteren Teil der Programmoberfläche werden diese beiden Prozeßvariablen sowie der Analogwert "1/P/1" grafisch dargestellt und vom Listenerteil des Programmes beim Empfangen der entsprechenden Daten aktualisiert.
Durch Absetzen der gewünschten ONCE-, CYCL- oder EVENT-Abfragen im Talker-Teil können somit alle Funktionen eines DIE-Providers getestet werden.

Abbildung 5-9: DIE-Tester

5.4 IIPLS-Variablenbrowser

Ziel des Prototyps des Variablenbrowsers war es, eine Möglichkeit zu schaffen, die vom Variablenserver zur Verfügung gestellten Daten plattformunabhängig darzustellen. Der Browser wurde daher als JAVA-Applet konzipiert, welches einem DIE-User der Variante 5 entspricht. Die Rolle eines Object-Managers kann in diesem Fall vom DIE-Tester übernommen werden. Im folgenden Listing sind die wichtigsten Teile des Sourcecodes des JAVA-Applets dargestellt (siehe auch [CW96]).
Die Hauptaufgabe des Applets wird von der Funktion "run()" erledigt, welche für das Empfangen und die Weiterverarbeitung der DIE-Telegramme sorgt. Diese Funktion wird als eigener Thread definiert und mit "start()" und "stop()" verwaltet. Die Funktion "paint()" ist für die Darstellung der Daten auf der Benutzeroberfläche (in diesem Falle innerhalb des Web-Browsers) verantwortlich und wird vom Thread nach jedem empfangenen Telegramm neu aufgerufen ("repaint()"). Die Darstellung (im vorliegenden Beispiel rein textuell) kann natürlich mit beliebigen grafischen Elementen realisiert werden.

// DIE-User als JAVA-Applet
// Import-Vereinbarungen
import java.lang.*;
import java.awt.*;
import java.applet.*;
import java.net.*;
import java.io.*;
import java.util.*;

public class udp extends Applet implements Runnable {

  String message;
  String message2;
  byte[] buf = new byte[256];
  DatagramPacket packet;
  DatagramSocket socket = null;
  Thread udp_th;
  InetAddress address;
  int port;

// Initialisierung der Variablen
  public void init() {
    ...
    packet = new DatagramPacket(buf, 256);
    System.out.println("START ...");
    try {
       socket = new DatagramSocket(2051);
       System.out.println("DIE-User listening on port: " + socket.getLocalPort());
    } catch (java.net.SocketException e) {
          System.err.println("Could not create datagram socket.");
      }
    if (socket == null)
        return;
  }

// Darstellen der Daten ...
  public void paint(Graphics g) {  ... }

// Empfangen und Parsen von DIE-Telegrammen
// ... diese Routine wird als eigener Thread gestartet
  public void run() {
     while (true) {
        try {
           socket.receive(packet);
           address = packet.getAddress();
           port = packet.getPort();
           System.out.println("Datagram received from: Address: " + address + " Port: " + port);
           String received = new String(packet.getData(), 0);
           System.out.println("Client received packet: " + received);
... Daten verarbeiten ...
           repaint();
         } catch (IOException e) {
              System.err.println("IOException:  " + e);
           }
     }
  }

// Bei Start des Applets Thread kreieren und starten
   public void start() {
     if (udp_th == null) {
        udp_th = new Thread(this);
     }
     udp_th.start();
   }

// vor Applet-Ende auch Thread beenden
  public void stop() {
     if (udp_th != null) {
       udp_th.stop();
       udp_th = null;
     }
  }

// Bei Applet-Ende Socket schließen
   public void destroy() {
        if (socket != null) {
            socket.close();
            socket = null;
            System.out.println("Closing datagram socket.");
        }
    }
}
Listing 5-1: DIE-User als Java-Applet

Das Applet wird mit folgendem HTML-Code in eine HTML-Seite eingebettet und erzeugt, z.B. unter Netscape, eine Ausgabe, wie sie in Abbildung 5-10 dargestellt ist.

<HTML>
  <BODY>
    <STRONG>D.I.E. - User Agent als JAVA-Applet</STRONG><HR>
    <applet code="udp.class" width=500 height=60></applet>
  </BODY>
</HTML>
 

Abbildung 5-10: IIPLS-Variablenbrowser als DIE-User

Zurück zum Inhaltsverzeichnis

6 Zusammenfassung

In diesem     Kapitel wurde das vom Autor der vorliegenden Arbeit entwickelte Konzept des Distributed Information Exchange vorgestellt. Dieses Konzept erweitert die vorhandenen Internet-Technologien derartig, daß auch industrielle Kommunikationssysteme sinnvoll in Intranets integriert werden können. Der Schwerpunkt von DIE liegt in der Übertragung von Informationen, die an verteilten Quellen entstehen, an verteilte Empfänger, bei Bedarf an mehrere gleichzeitig. Dazu kommt die Flexibilität und Performance, die erreicht werden kann, wenn Daten nicht wie bisher durch Polling, sondern aufgrund von definierbaren Ereignisen übermittelt werden.
DIE "demokratisiert" die einzelnen Komponenten eines industriellen Kommunikations-systems, indem es den Aufbau einer Multi-Client/Multi-Server Architektur ermöglicht, ohne aber gleichzeitig den Einsatz des klassischen Client/Server Modells zu verhindern.
Durch die Realisierung und den Test des Prototypsystems wurde erkannt, daß die Idee des Konzeptes korrekt ist und sich weitere Entwicklungen in dieser Richtung lohnen würden.
Bei einem Vergleich mit anderen Architekturen, wie z.B. CORBA, wird klar, daß DIE um vieles einfacher aufgebaut und nicht so "elegant" ist, was aber bedeutet, daß DIE-Applikationen auch einfacher und "schlanker" zu implementieren sind. DIE ist daher besonders zur Integration der Vielzahl an unterschiedlichen Komponenten im Bereich der industriellen Kommunikation in ein Intranet geeignet.

Zurück zum Inhaltsverzeichnis

7 Literatur

[CB96]: C. Baumann: "Intranets - Unternehmensinterne Informations- und Kommunikationssysteme", Proceedings of the 7th International DAAAM Symposium, Wien, Oktober 1996.

[CB97]: C. Baumann: "Distributed Information Exchange in Production Environments", Proceedings of the 8th International DAAAM Symposium, Dubrovnik, Oktober 1997.

[CW96]: M. Campione, K. Walrath: The Java Tutorial - Object Oriented Programming for the Internet., 7/96, ftp://ftp.javasoft.com/docs/tutorial.zip

[HG97]: H. Grömer: IIPLS-Ein Prozeßleitsystem auf Basis der Internet-/Intranet Technologie, 4/97, Wien

Copyright 1997, Dipl.-Ing. Christian Baumann - EMail: cbaumann@baumann.at - WWW: http://www.baumann.at/