Bachelor + Master Publishing
811 Bachelorarbeiten, 533 Masterarbeiten, 10.103 Diplomarbeiten

Konzeption und Realisierung einer Middleware zur Unterstützung der Interoperabilität verteilter Software-Komponenten in der Automation

Konzeption und Realisierung einer Middleware zur Unterstützung der Interoperabilität verteilter Software-Komponenten in der Automation
Über dieses Buch
  • Art: MA-Thesis / Master
  • Autor: Robert Neuwirth
  • Abgabedatum: Januar 2005
  • Umfang: 248 Seiten
  • Dateigröße: 3,7 MB
  • Note: 1,5
  • Institution / Hochschule: Fachhochschule Reutlingen Deutschland
  • ISBN (eBook): 978-3-8324-9531-2
  • ISBN (Paperback) :
    978-3-8324-9531-2 P
  • ISBN (CD) :978-3-8324-9531-2 CD
  • Sprache: Deutsch
  • Prämierung:
  • Arbeit zitieren: Neuwirth, Robert Januar 2005: Konzeption und Realisierung einer Middleware zur Unterstützung der Interoperabilität verteilter Software-Komponenten in der Automation, Hamburg: Diplomica Verlag
  • Schlagworte: Mechatronik, Computer based Engineering, Verteilte Software Systeme, Aibo, Automatisierungstechnik

MA-Thesis / Master von Robert Neuwirth

Zusammenfassung:

Aufgrund der Beispiele einer Fertigungslinie, Kommissionieranlage sowie einer Gebäudeautomation wurden in Kapitel 2 die dort auftretenden Anforderungen an ein Software-System zur Unterstützung von automatisierten Anlagen aufgezeigt. Auf Basis dieser, bewusst recht unterschiedlich gewählten Beispiele, wurden die jeweiligen anlagenspezifischen Anforderungen analysiert und ausgewertet. Aus diesen spezifischen Anforderungen wurden dann in Kapitel 3 allgemeine Anforderungen abgeleitet und erarbeitet, die für alle beschriebenen Fälle einsetzbar sind und als eine Basis für die Entwicklung einer generell einsetzbaren Middleware dienen. In einem weiteren Schritt wurden in Kapitel 4 klassische Architekturen verteilter Software-Systeme auf ihre Verwendbarkeit in Bezug auf die ermittelten Anforderungen beleuchtet, sowie vorhandene Middleware-Lösungen wie CORBA, OPC und JINI auf deren Verwendungsmöglichkeiten und Grenzen untersucht.

In Kapitel 6 wurden daraufhin eine Anzahl konkreter Spezifikationen für die Realisierung von allgemein einsetzbaren Funktionen beschrieben, die sich aus den in Kapitel 3 erarbeiteten Anforderungen ableiten. Diese Funktionen wurden als von der Middleware bereitzustellende Dienste definiert. Die Dienste sind so konzipiert, dass sie in allen in Kapitel 3 beschriebenen Beispielen verwendet werden können und damit in der Automation universell einsetzbar sein sollten.

Das Kapitel 7 beschreibt die Implementierung eines Code-Generators mittels Einsatz der Werkzeuge Flex und Bison, als auch ein Vorschlag für den Einsatz von geeigneten Verschlüsselungsverfahren zur Realisierung eines Sicherheitskonzeptes.

Um die entwickelte Middleware auf ihre Verwendbarkeit zu prüfen, wurde schlussendlich eine reale Anwendung erstellt, die beispielhaft eine Kommunikation zwischen zwei recht unterschiedlichen Robotern demonstriert. Die Beschreibung der Anwendung sowie ein Erfahrungsbericht ist in Kapitel 8 zu finden.

Die umfassende Beschäftigung mit dem Thema verteilter Systeme in der Automation hat viele interessante Aspekte und Lösungsansätze für die Architektur einer unterstützenden Middleware in diesem Bereich aufgezeigt. Die erstellte Beispiel-Anwendung hat neben der Demonstration einer grundsätzlichen Machbarkeit auch Grenzen aufgezeigt, die zunächst nicht ersichtlich waren. Durch die Probleme bei der Entwicklung des Dispatchers und der API im Rahmen der Partner-Thesis ist zwar eine Umsetzung der vorgeschlagenen Middleware nur bedingt erfolgt, jedoch spricht dies nicht gegen das erstellte Konzept an sich.

Aufgrund der hier erstellten Konzeption kann die Realisierung einzelner Teile des Systems erfolgen, die wiederum als Grundlage für Untersuchungen dienen. Speziell die Frage nach realisierbaren Anforderungen im Rahmen einer weichen Echtzeit stellt ein spannendes Forschungsfeld dar. Schon die Demo-Anwendung hat gezeigt, dass mit ein paar wenigen Programmen der Einsatz der Middleware möglich ist. Somit ist mit relativ wenig Aufwand die Bildung einer Basis für solche Untersuchungen möglich.

Zunächst muss aber ein funktionierender Dispatcher programmiert werden. Dessen Funktionsweise kann dann mittels eines Simulations-Programmes getestet werden. In einer weiteren Test- und Verifizierungsphase kann die erstellte Beispiel-Anwendung verwendet werden, in dem der dort eingesetzten KSD gegen den MIDAS-Dispatcher ausgetauscht wird. Die weiteren Schritte könnten in einer schrittweisen Umsetzung der vorgeschlagenen Dienste liegen, wobei der Event-Viewer wohl eine der interessantesten Anwendungen darstellt. Auch die Protokollierung des Telegrammverkehrs inklusive Zeitstempeln stellt eine Grundlage für Auswertungen des System-Verhaltens dar, so dass die Entwicklung von Logging-Mechanismen sicher auch einer der ersten zu erstellenden Dienste darstellt.

Fazit: Verteilte Systeme in der Automation sind ein spannendes und hochaktuelles Thema das viele Entwicklungs- und Erweiterungsmöglichkeiten bereithält. Die vorliegende Thesis kann als eine Basis für die sukzessive Entwicklung einer umfangreichen Middleware verstanden werden.

Gang der Untersuchung:

Die vorliegende Thesis nähert sich aufgrund von beispielhaften Anwendungsfällen den Anforderungen an ein die Interoperabilität unterstützendes Software-System. In diesem Rahmen wird die Notwendigkeit der Ableitung applikationsübergreifender Funktionalitäten dargestellt. Darüber hinaus werden Vorteile sowie Nutzen des Einsatzes eines Software-Systems zur Unterstützung der Entwickler von verteilten Anwendungen, sowie Lösungsansätze zur Aufnahme von allgemein nützlichen Funktionen beschrieben. Das Software-System wird im Folgenden als Middleware bezeichnet:

„Unter Middleware versteht man Software, die zwischen der Anwendungssoftware und der Betriebssystemsoftware angesiedelt ist. Kommunikations-Middleware dient der vereinfachten und standardisierten Kommunikation der Komponenten eines verteilten Systems.“ Dem Autor ist bewusst, dass schon eine ganze Reihe von Middleware-Lösungen auf dem Markt verfügbar sind. Daher wird in Kapitel 4.2 zum Zwecke der Abgrenzung eine Untersuchung von gängigen Produkten wie CORBA, OPC und Jini durchgeführt.

Inhaltsverzeichnis:

1. EINLEITUNG 7
1.1 Motivation 7
1.2 Vorgehensweise 7
1.3 Aufteilung auf zwei Thesen 8
2. EXEMPLARISCHE ANWENDUNGSFÄLLE 9
2.1 Fertigungslinie 9
2.1.1 Visualisierung, Überwachung 10
2.1.2 Manufacturing Execution System (MES) 11
2.1.3 Flexibilität 12
2.1.4 Programmverwaltung 12
2.1.5 Kopplung mit Logistiksystemen 12
2.1.6 Kopplung mit übergelagerten Verwaltungssystemen 13
2.1.7 Anlagenkonfiguration, Backup-Mechanismen 13
2.1.8 Extrahierte spezifische Anforderungen 14
2.2 Kommissionieranlage 15
2.2.1 Spontaneous Networking 16
2.2.2 Lagerorte 16
2.2.3 Transaktionen 17
2.2.4 Optimierungen 19
2.2.5 Anlagenauslastung 19
2.2.6 Echtzeitanforderungen (Realtime) 19
2.2.7 Extrahierte spezifische Anforderungen 22
2.3 Gebäudeautomation 23
2.3.1 Ortstransparente Interkommunikation 23
2.3.2 Entscheidungsfindungen 24
2.3.3 Priorisierungen 24
2.3.4 Statistiken 24
2.3.5 Sicherheit 25
2.3.6 Heterogene Produktsituation 25
2.3.7 Extrahierte spezifische Anforderungen 25
2.4 Warenwirtschaftssystem (WWS) 26
2.4.2 Extrahierte spezifische Anforderungen 32
2.5 Resumee 33
3. BESCHREIBUNG DER ANFORDERUNGEN AN EIN SYSTEMDESIGN 35
3.1 Unabhängigkeit 35
3.2 Unterstützung der Applikationsentwicklung 36
3.3 Ausfallsicherheit 37
3.4 Fehlertoleranz 38
3.5 Erweiterbarkeit 39
3.6 Zugriffssicherheit (Security) 39
3.7 Laufzeit-Optimierungen 40
3.8 Zeitsynchronisierung 40
3.8.1 Beispiel Papiermaschine 41
4. VERGLEICH ZU KLASSISCHEN ARCHITEKTUREN 43
4.1 Arten der Interaktionen in verteilten Systemen 43
4.1.1 Client/Server-Architektur 43
4.1.2 Peer to Peer (P2P)-Architektur 44
4.1.3 Grid Computing 45
4.1.4 Agenten 46
4.2 Abgrenzung zu bestehenden Middleware-Lösungen 48
4.2.1 Objektbasierte Systeme 48
4.2.2 Koordinationsbasierte Systeme 51
5. ENTWURF DER MIDDLEWARE 53
5.1 Begriffsdefinition 54
5.1.1 Applikation 54
5.1.2 Dispatcher 54
5.1.3 Task 54
5.2 Implementierungsaspekte 55
5.2.1 Dispatcher-Start 55
5.2.2 Telegramme 56
5.2.3 Socket-Verbindung 57
5.2.4 Connect-Aufbau 58
5.2.5 Watchdogs 59
5.3 Physische Verteilung im Netz 60
6. SPEZIFIKATION ALLGEMEINER DIENSTE UND FUNKTIONEN 62
6.1 Interne Dienste 63
6.1.1 Taskgruppen 63
6.1.2 Abonnement 66
6.1.3 Telegrammgruppen 68
6.1.4 Persistenz 68
6.1.5 Migration eines Tasks oder Dispatchers 69
6.1.6 Zeitsynchronisierung der Dispatcher 70
6.2 Externe Dienste 72
6.2.1 Task-Simulator 72
6.2.2 Externer Speicher 73
6.2.3 Konfigurations-Datenbank 74
6.2.4 Security Server 74
6.2.5 Logging und Monitoring 75
6.2.6 Datenbank-Connect 77
6.2.7 Middleware-Konfigurationsmanager 80
6.2.8 EventViewer 81
6.2.9 Versions-Repository 84
6.2.10 PrintDaemon 85
6.3 Application Programmer Interface (API) 86
6.3.1 Sprachunabhängigkeit 86
6.3.2 Operative Funktionen 87
6.3.3 Unterstützung bei der Telegramm-Definition 88
7. IMPLEMENTIERUNG AUSGEWÄHLTER BEREICHE 89
7.1 Code-Generator für Telegramme 89
7.1.1 Flex und Bison – eine Übersicht 90
7.1.2 Ablauf der Generierung 91
7.2 Überlegungen zur Implementierung von Security-Funktionen 93
7.2.1 Verschlüsselung 94
7.2.2 Schlüsselverteilung 95
7.2.3 Vorhandene Verschlüsselungsverfahren 96
7.2.4 Eigener Vorschlag für eine Verschlüsselung 97
7.2.5 Authentifizierung 98
7.2.6 Autorisierung 101
7.2.7 Verschlüsselung des Telegrammverkehrs 102
7.2.8 Erweiterte Schutzmassnahmen 102
8. BEISPIELANWENDUNG 103
8.1 Entwurf der Anwendung 103
8.1.1 Aussageziel 105
8.1.2 Aufbau und Schnittstellen der verwendeten Roboter 105
8.2 Umsetzung 111
8.2.1 Aico-Zelle 113
8.2.2 Eingesetzte Sprachen und Entwicklungsumgebungen 114
8.3 Programmdokumentation 116
8.3.1 Aibo-Frontend 116
8.3.2 Aico-Frontend 119
8.3.3 Dispatcher (KSD) 122
8.3.4 KSD Monitor 123
8.4 Erfahrungsbericht 124
8.4.1 Aico-Zelle 124
8.4.2 Zusammenspiel 124
8.4.3 Visualisierungen 125
9. ZUSAMMENFASSUNG 126
9.1 Was wurde erreicht? 127
9.2 Ansätze zur Fortführung 127
10. ANHANG 128
10.1 Literaturverzeichnis 128
10.2 Abkürzungsverzeichnis 131
10.3 Installation 133
10.3.1 Installation auf einem PC 133
10.3.2 Verteilte Installation 134
10.4 Quelltexte 139
10.4.1 Übersicht 139
10.4.2 rnControl 141
10.4.3 ACOTelnet 147
10.4.4 WinAiboCtrl 168
10.4.5 AicoControl 191
10.4.6 MIDAS Telegramm-Definitionen 218
10.4.7 Code-Generator 222

Automatisiert erstellter Textauszug:

Abbildung 6-1 Zeitsynchronisierung zwischen zwei Dispatchern Nach einer (im Schaubild nicht aufgeführten) Anfrage von Dispatcher 2 (D2) sendet Dispatcher 1 (D1) zum Zeitpunkt 63 (D2-Zeit=69) ein Sync-Telegramm. Der Delay (also die benötigte Laufzeit von D1 zu D2) wird hier mit 2ms angesetzt. Das Sync-Telegramm enthält zwar eine eindeutige ID, zunächst jedoch nicht die Startzeit t0 an sich. D2 merkt sich zum Zeitpunkt des Erhalts seine lokale Zeit in t1=71. Daraufhin sendet D1 ein FollowUp-Telegram (mit eindeutiger Referenz zu Sync) zum D1-Zeitpunkt 66 und mit dem Zeitstempel t0=63, also der Sendezeit des zuvorigen Sync-Telegrams. D2 erhält dieses Telegramm zum D2Zeitpunkt 74. Diese zwei Telegramme reichen für eine erste Näherung aus, so dass D2 die Zeit auf 66 korrigiert. Jedoch kann der Delay noch nicht berücksichtigt werden, da er noch nicht bekannt ist. Dieser wird in einem zweiten Schritt ermittelt. D2 sendet hierfür nun ein DelayReq Telegramm an D1 und merkt sich den Zeitpunkt der Anfrage in t2 = 68. D1 erhält diesen zum D1-Zeitpunkt t3 = 72 und sendet diese Information zum D1-Zeitpunkt 74 mittels DelayResp an den D2 zurück. Nun kann die Zeitsynchronisierung unter Berücksichtigung des ermittelten Delays entgültig durchgeführt werden. [...]

Sowohl für die Protokollierung der Kommunikation als auch für Performance-Analysen ist die Synchronisierung der lokalen Uhren aller beteiligter Geräte und Computer unerlässlich. Die tatsächliche Laufzeit eines Telegrammes kann nur gemessen werden, wenn sowohl der Absender als auch der Empfänger über eine synchronisierte Uhrzeit verfügen. Für die Zeitsynchronisierung ist natürlich der Einsatz von vorhandenen Tools wie zum Beispiel einen SNTP-Server (Single Network Time Protokol) denkbar. Um eine möglichst hohe Unabhängigkeit von „Fremdproduktion“ zu erreichen ist aber eine eigene rudimentäre Implementierung vorteilhaft. Zu beachten ist jedoch, dass jegliche Zeitsynchronisierungen auf Software-Basis nur eine endliche Genauigkeit bieten können die in etwa im Millisekunden-Bereich liegt. Erst durch den Einsatz von Hardware-Uhren direkt in den Netzwerkkarten und Switches werden Synchronisierungen im Nanosekunden-Bereich möglich, wie es zum Beispiel die Norm IEEE1588 beschreibt: “IEEE 1588 ist ein »Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems«, kurz Precision Time Protocol (PTP)”. [KTCA01] „Der IEEE 1588 Standard definiert ein Verfahren, das viele, räumlich verteilte Echtzeituhren synchronisiert, die über ein „Paket“-fähiges Netzwerk miteinander verbunden sind“. [HW03] Sowohl bei SNTP als auch bei IEEE1588 kommen zentrale Time-Server für die Zeitsynchronisierung zum Einsatz. Da es sich jedoch um eine essentielle Funktion der Middleware handelt, wird eine Implementierung als interner Dienst ohne einen dedizierten Time-Server vorgeschlagen. Eine Synchronisierung kann nur zwischen zwei direkt verbundenen Dispatchern erfolgen, da bei Hops über mehrere Dispatcher der hierbei entstehende Jitter nicht mehr zu verantwortbare Ausmaße annimmt. Daher erfolgt die Synchronisierung aller lokalen Uhren im Netz nach einem Schneeballprinzip von Dispatcher zu Dispatcher, wobei sich jeder Dispatcher die verstrichene Zeit seit der letzten Synchronisierung in Millisekunden merkt. Ist das konfigurierte Zeitintervall zur Resynchronisierung abgelaufen, fragt der betroffene Dispatcher alle seine DispatcherNachbarn nach deren bisher verstrichenen Zeit seit ihrer letzten Synchronisierung. Er führt daraufhin die Zeitsynchronisierung mit dem Dispatcher durch, deren Zeit zuletzt synchronisiert wurde. Für die eigentliche Zeitsynchronisierung zwischen zwei Dispatchern bietet es sich an, den bei IEEE1588 implementierten zweistufigen Algorithmus mit kleinen Anpassungen zu übernehmen der im folgenden näher beschrieben wird: [...]

( 3.2.1.1 Autokonfiguration) Das manuelle Verteilen von neuen Task- oder Dispatcher-Versionen kann sehr aufwendig werden. Denkbar ist daher eine automatische Verteilung durch einen MigrationsMechanismus. Die Migration erfolgt hierbei fließend: die neue Version wird gestartet während die alte noch läuft. Erst wenn alle Teilnehmer umgezogen sind wird die alte Version gestoppt. Die Migration wird in folgenden Schritten durchgeführt: Neuer Dispatcher wird auf Zielsystem kopiert. Alter Dispatcher wird über Umzug informiert. er startet neuen Dispatcher. Alter Dispatcher wechselt Status in „shutdown“ und nimmt keine neuen Tasks an. Alter Dispatcher sendet an alle Tasks: bitte neuen Dispatcher wählen. Alter Dispatcher beendet sich sobald keine Tasks mehr online sind. [...]

Arbeit zitieren:
Neuwirth, Robert Januar 2005: Konzeption und Realisierung einer Middleware zur Unterstützung der Interoperabilität verteilter Software-Komponenten in der Automation, Hamburg: Diplomica Verlag

Schlagworte:
Mechatronik, Computer based Engineering, Verteilte Software Systeme, Aibo, Automatisierungstechnik

Entdecken Sie mehr zum Thema

diplom.de
Bachelor + Master Publishing

Hermannstal 119 k
22119 Hamburg

Fon: +49 (0) 40 655992-0
Fax: +49 (0) 40 655992-22

Service-Telefon

Rufen Sie uns an:
+49 (0) 40 655992-0

Mo-Fr
09.00-16.00 Uhr

diplom.de in den Medien

Folgen Sie uns bei Twitter & werden Sie diplom.de-Fan bei Facebook!
Schreibtipps unserer Lektoren, Neuigkeiten aus dem Verlagsalltag und das Expertenwissen unserer Autoren als Tweet & Post!
Wir freuen uns auf Sie!

diplom.de BACHELOR + MASTER PUBLISHING

Bachelorarbeiten, Masterarbeiten, Diplomarbeiten, Magisterarbeiten, Dissertationen und andere Abschlussarbeiten aus allen Fachbereichen und Hochschulen können Sie bei uns als eBook sofort per Download beziehen oder sich auf CD oder als Buch zusenden lassen. Seit mehr als 15 Jahren ist diplom.de der seriöse, professionelle und erfolgreiche Partner für die Veröffentlichung wissenschaftlicher Abschlussarbeiten.

© Diplomica Verlag GmbH 1996-2011, AG Hamburg HRB 80293 - GF Björn Bedey, USt-IdNr.: DE214910002 - Verkehrsnummer: 12285 - Impressum
Index der Arbeiten - Index der Autoren