Konzeption und Realisierung einer Middleware zur Unterstützung der Interoperabilität verteilter Software-Komponenten in der Automation
- 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
In den Warenkorb
74,00 €
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 |
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. [...]
In den Warenkorb
74,00 €
Link zur Arbeit:
http://www.diplom.de/ean/9783832495312
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



