ID 9531
Neuwirth, Robert: Konzeption und Realisierung einer Middleware zur Unterstützung der
Interoperabilität verteilter Software-Komponenten in der Automation -
Schwerpunkt Anforderungsanalyse
Druck Diplomica GmbH, Hamburg, 2006
Zugl.: Fachhochschule Reutlingen, MA-Thesis / Master, 2005
Dieses Werk ist urheberrechtlich geschützt. Die dadurch begründeten Rechte,
insbesondere die der Übersetzung, des Nachdrucks, des Vortrags, der Entnahme von
Abbildungen und Tabellen, der Funksendung, der Mikroverfilmung oder der
Vervielfältigung auf anderen Wegen und der Speicherung in Datenverarbeitungsanlagen,
bleiben, auch bei nur auszugsweiser Verwertung, vorbehalten. Eine Vervielfältigung
dieses Werkes oder von Teilen dieses Werkes ist auch im Einzelfall nur in den Grenzen
der gesetzlichen Bestimmungen des Urheberrechtsgesetzes der Bundesrepublik
Deutschland in der jeweils geltenden Fassung zulässig. Sie ist grundsätzlich
vergütungspflichtig. Zuwiderhandlungen unterliegen den Strafbestimmungen des
Urheberrechtes.
Die Wiedergabe von Gebrauchsnamen, Handelsnamen, Warenbezeichnungen usw. in
diesem Werk berechtigt auch ohne besondere Kennzeichnung nicht zu der Annahme,
dass solche Namen im Sinne der Warenzeichen- und Markenschutz-Gesetzgebung als frei
zu betrachten wären und daher von jedermann benutzt werden dürften.
Die Informationen in diesem Werk wurden mit Sorgfalt erarbeitet. Dennoch können
Fehler nicht vollständig ausgeschlossen werden, und die Diplomarbeiten Agentur, die
Autoren oder Übersetzer übernehmen keine juristische Verantwortung oder irgendeine
Haftung für evtl. verbliebene fehlerhafte Angaben und deren Folgen.
Diplomica GmbH
http://www.diplom.de, Hamburg 2006
Printed in Germany
Inhalt
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
Einleitung
7
1 Einleitung
1.1 Motivation
Die Verbreitung von Computern nimmt besonders außerhalb der klassischen Einsatzgebiete
als Zentralrechner oder PC enorm zu (so sind heutzutage schon Kaffee-Maschinen mit
eigenen Betriebssystemen ausgerüstet). Durch diese Verbreitung stellt sich die Forderung
nach Interkommunikation und Interoperabilität. Auch die erweiterten Möglichkeiten und
Funktionen einer solchen Zusammenarbeit erscheinen verlockend. Jedoch ist bisher relativ
wenig Software auf dem Markt zu finden, die speziell die Interkommunikation in einer
heterogenen Produktlandschaft unterstützt. Dieses Fehlen einer (optimalerweise
standardisierten) Unterstützung ist besonders im Bereich von Projekten in der Automation zu
beobachten. So schreibt Humphrey:
,,Ein echtes Problem stellt für Herstellungsbetriebe jeglicher Art heute immer noch die
fehlende Interoperabilität zwischen den Systemen dar." [DHID1104]
Als Folge müssen oft und mangels fehlenden, beziehungsweise nicht alle Anforderungen
abdeckenden Entwicklungshilfsmitteln, Schnittstellen zwischen einzelnen Geräten und deren
Computern immer wieder neu und speziell erstellt werden. Eine Arbeit auf diesem Gebiet
erscheint daher viel versprechend, nicht nur zur Lösung des Integrations-Dilemmas, sondern
auch im Hinblick auf die erweiterten Möglichkeiten, die solch ein Software-System bieten
könnte.
1.2 Vorgehensweise
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." [SWTI01]
Einleitung
8
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.
1.3 Aufteilung auf zwei Thesen
Sowohl die konzipierte Middleware als auch der realisierten Teile entstanden in enger
Zusammenarbeit mit Stephan Zimmer [zi05]. Als Folge ist die klare Trennung einzelner
Bereiche, sowie die Herkunft zugrunde liegender Ideen (speziell bei der entwickelten
Architektur) im Nachhinein oft nur schwer durchführbar. Somit sollte das Gesamtergebnis als
eine Gemeinschafts-Leistung betrachtet werden. Es wurde trotzdem versucht, aufgrund der
jeweils gesetzten Schwerpunkte die Arbeit in zwei sich ergänzende Thesen aufzuteilen: Die
vorliegende Thesis beschreibt Anforderungen und Konzepte, die anhand von Beispielen
automatisierungstechnischer Anwendungen erarbeitet werden. Die Partner-Thesis [zi05]
geht auf die Umsetzung der Anforderungen in eine Middleware ein. Deren exemplarische
Anwendung am Beispiel einer Interaktion zwischen (in ihrem Aufbau sehr unterschiedlichen)
Robotern ist wiederum in dieser Thesis beschrieben. Bei einigen fachlichen Bereichen war
eine klare Arbeitsteilung möglich, so dass neben der oben beschriebenen Aufteilung einige
ausgewählte Themen der Umsetzung sich in der vorliegenden Thesis widerspiegeln, insofern
sie die Arbeit des Autors betreffen. Die einzelnen Thesen sind so aufgebaut, dass sie als
eigenständige Dokumente betrachtet werden können. Als Folge sind bestimmte Themen in
beiden Thesen zu finden, die je nach den Schwerpunkten der jeweiligen Thesis mehr oder
weniger ausführlich beschrieben sind. So ergibt sich ungeachtet der jeweiligen
Eigenständigkeit das umfassende Gesamtbild der entwickelten Middleware erst durch das
Studium beider Thesen.
Sollte daher der Leser einzelne Aspekte und Bereiche in vorliegendem Dokument nicht oder
nicht ausführlich genug beschrieben wieder finden wird sich zur Vervollständigung ein Blick
in die Partner-Thesis sicher als lohnend erweisen. Dies gilt insbesondere für den Bereich der
Systemarchitektur.
Exemplarische Anwendungsfälle
9
2
Exemplarische
Anwendungsfälle
Im Folgenden werden Anwendungsfälle in der Automation beschrieben, an Hand derer die
geforderten Funktionen der Middleware erarbeitet werden. Sie dienen auch als Grundlage für
die nachfolgenden Konzeptionen. Hierzu gehören die Architektur und für die
Applikationsentwickler bereitzustellende Dienste.
2.1 Fertigungslinie
Die industrielle Produktion wird aufgrund von Rationalisierungsmaßnahmen seit geraumer
Zeit immer weiter automatisiert. Im Maschinenbau werden hierbei einzelne Fertigungsschritte
von Bearbeitungszentren (Zellen) durchgeführt. Zur Abstimmung dient in der Regel ein
übergelagertes Produktionsplanungs- und Steuerungssystem (PPS) das unter anderem
durch geeignete Verteilung der anstehenden Fertigungsaufträge auf die Zellen eine
möglichst hohe Effektivität und Auslastung der Fertigungslinie gewährleisten soll. Darüber
hinaus wird zur Überwachung des laufenden Betriebes meist ein Leitstand eingerichtet, der
sowohl einen Gesamtüberblick verschaffen soll als auch als Sammelstelle für Betriebsdaten
dient:
Leitstand
Produktionszelle
Produktio nszelle
Produkti onszelle
Loka le
Visua lisi erun g
Online-Wart ung,
Kontrolle
PPS, W WS,
Datenbank en
Funknetz
Access Point
Ethernet
Fördersystem
Materialzuführung
Abbildung
2-1
Produktionslinie
Exemplarische Anwendungsfälle
10
Im Bereich des Sondermaschinenbaus (denn bei den Bearbeitungszentren handelt es sich
meist um Spezialanfertigungen) ist in Deutschland eine Vielfalt an Herstellern zu
beobachten, die ihre Konkurrenzfähigkeit auch ganz essentiell durch besonderes
Spezialwissen in Nischengebieten aufrechterhalten. Als Folge ist eine heterogene
Landschaft von Software in Form von Betriebsystemen und Steuerungssystemen
anzutreffen. So sind schon auf Feldbus-Ebene eine ganze Anzahl konkurrierender Lösungen
vorzufinden. Dies setzt sich ganz besonders auf der Ebene der Steuerungs-Software fort.
Hier kommen oft vom jeweiligen Hersteller eigen entwickelte und damit proprietäre Lösungen
zum Einsatz. Diese Situation ist an sich als positiv zu bewerten, da zum einen eine
heterogene Konkurrenzsituation zu begrüßen ist und zum anderen die in der Automation oft
sehr individuellen Anforderungen zum Beispiel an die Funktion von Bearbeitungszentren
jeweils speziell zu entwickelnde Software-Lösungen erfordert.
Um jedoch die komplette Produktion automatisieren zu können, müssen die Zellen in der
Lage sein miteinander zu interagieren. Dies setzt wiederum eine einheitliche Kommunikation
voraus. Ohne erst an die vielfältigen Anforderungen eines PPS oder gar einer kompletten IT-
unterstützten Fertigung durch ,,Computer Integrated Manufacturing" (CIM) zu denken gibt es
hierbei genügend andere wichtige Faktoren der Interoperabilität. Zu nennen sind:
2.1.1 Visualisierung, Überwachung
Die Überwachung einzelner Bearbeitungszentren als auch der Gesamtproduktion erfolgt in
der Regel neben der direkten Visualisierung an der Maschine durch einen Leitstand. Die
Aufgabe des Leitstands besteht hierbei hauptsächlich in der Schaffung eines
Gesamtüberblicks über die aktuell laufende Fertigung. Dies macht eine Aggregation der
Informationsflut notwendig. Hierfür wird unter anderem eine Zwischenschicht zur Schaffung
einer einheitlichen Schnittstelle für die unterschiedlichen Protokolle der einzelnen Zellen
benötigt. Eine weitere Anforderung ist die der Flexibilität: die Einbindung neuer Hardware in
Form von Bearbeitungszentren oder Fördersystemen muss sich so einfach wie möglich
gestalten.
Die Überwachung der Anlage erfolgt teilweise und ergänzend auch außerhalb eines
Leitstandes. Denkbar ist folgendes Szenario: der für die Produktion verantwortliche
Mitarbeiter geht durch die Produktionshalle und kann direkt mittels eines mitgeführten
Personal Digital Assistant (PDA) oder Notebooks Daten über den Zustand der jeweiligen
Maschine anfordern, um kurzfristige Entscheidungen über die Planung von
Wartungstätigkeiten oder ähnlichem treffen zu können.
Exemplarische Anwendungsfälle
11
2.1.2 Manufacturing Execution System (MES)
Ziel einer jeden Automation ist die Kostenersparnis. Der Sinn des Einsatzes einer
Middleware liegt daher primär in der Unterstützung dieses Zieles, unter anderem durch das
Bereitstellen von Auswertungsmöglichkeiten, die unter dem Begriff des MES
zusammengefasst werden. Humphrey schreibt dazu:
,,Einzelne Maschinen und ganze Produktionslinien müssen mit übergeordneten
Geschäftssystemen verbunden werden, um beispielsweise über die Auswertung historischer
Daten präzise feststellen zu können, welche Produktionslinie die Endprodukte pünktlich und
zu minimalen Kosten liefern kann". [DHID1104]
Ein MES dient unter anderem als gemeinsame Datenbasis für die Betriebsdatenerfassung
(BDE) und die Maschinendatenerfassung (MDE) und hat folgende Aufgaben (Beispiele):
-
Laufzeit- und Stückzahlerfassung. Hierbei auch die Erfassung von Stillstandszeiten
als Grundlage für Statistiken und Erhöhung der Auslastung.
-
Zuordnung von Auftragsdaten sowie Störgründen zu den Betriebsdaten.
-
Bedarfsgesteuerte Personaleinsatzplanung inklusive Lohnberechnung. Eine
Herausforderung hierbei ist zum Beispiel die Einbeziehung von Springer-Tätigkeiten.
-
Im Bereich von CAQ: die Überwachung des Werkzeugverbrauchs.
Für diese Aufgaben werden lückenlose Aufzeichnungen über Auslastung, Fehler- und
Ausfallhäufigkeit bei der Bearbeitung der Halbfertigteile sowie die Verfügbarkeit der
jeweiligen Zelle an sich benötigt. Folglich muss ein Datenverlust auch bei zeitweiligem
Ausfall der Datenbank verhindert werden. Und ganz besonders in diesem Bereich stellt sich
die Anforderung nach einer einheitlichen Schnittstelle für die Integration unterschiedlichster
Software-Systeme, denn:
"Während sich im Bereich der Organisationssoftware ... weitestgehend Standards entwickelt
haben, findet man im operativen Bereich der Fertigung eine wilde Ansammlung von
Insellösungen für unterschiedlichste Aufgaben." [ThKoIA42/04]
Zudem liefert ein MES sowohl die Datengrundlage für das PPS-System, als auch für eine
Vor- und Nachkalkulation der Produktionskosten:
,,Durch die mitlaufende Aufzeichnung der einzelnen Arbeitsgänge kann am Ende festgestellt
werden, welche Arbeitszeiten und kosten auf den entsprechenden Auftrag zu verbuchen
sind." [UwBoIA42/2004].
Exemplarische Anwendungsfälle
12
2.1.3 Flexibilität
Die Reaktionszeiten auf unvorhergesehene Situationen, wie zum Beispiel der Ausfall
einzelner Systeme (Zellen, Steuerungen, Fördertechnik) in der Fertigung, sollten so gering
wie möglich gehalten werden. Es wird also eine hohe Flexibilität hinsichtlich von
automatischen Umlagerungen der anstehenden Arbeitsaufträge gefordert, zum Beispiel auf
geeignete andere Zellen innerhalb der Fertigung. Optimalerweise geschieht dies durch das
Gesamtsystem mittels einer Kommunikation zwischen den Zellen und wenn möglich,
zunächst ohne Einschalten der übergelagerten Instanz (in der Regel ein PPS-System). So
könnte eine Zelle, die in der Produktion parallel geschaltet ist und damit die gleiche Aufgabe
erfüllt, eigenständig die offenen Fertigungsaufträge übernehmen. Auch ein Eskalations-
Mechanismus ist vorzusehen: ist eine Lösung der Ausnahmesituation auf der
Produktionsebene nicht möglich, wird die Situation eine oder mehrere Ebenen höher
propagiert. Erfolgt auch dies automatisch, dann ist ein Eingriff durch den Menschen nur noch
in seltenen Fällen notwendig, für die keine vorgesehenen Reaktionsweisen definiert sind.
Zur Flexibilität gehört auch der Umgang mit Ausschussteilen in der Fertigung. Für solch
fehlerhafte Teile müssen geplante Bearbeitungsschritte in der Fertigungskette storniert
werden, was wiederum Auswirkungen auf die Auslastung der betroffenen Zellen hat. Hier ist
eine Kommunikation der Zellen untereinander denkbar, die ihre Auslastung optimieren,
indem sie freigewordene Kapazitäten melden ohne zunächst eine Rücksprache mit
übergelagerten Systemen halten zu müssen.
2.1.4 Programmverwaltung
Eine wichtige Aufgabe eines jeden übergelagerten Software-Systems in einer
Produktionslinie ist die zentrale Verwaltung von Programmen, die für die einzelnen Zellen in
der jeweils dort eingesetzten Programmiersprache geschrieben wurden. Dies erfordert unter
anderem die Bereitstellung einer Versionsverwaltung als auch Suchalgorithmen. Somit bietet
sich für diese Aufgaben der Einsatz einer Datenbank an.
2.1.5 Kopplung mit Logistiksystemen
Die Zuführung der Halbfertigteile zu den einzelnen Zellen kann durch ein automatisches
Fördersystem ergänzt sein. Hier stellt sich neben der Anforderung an eine Kommunikation
mit den Zellen an sich auch die Notwendigkeit einer Zeitsynchronisierung. Zum Beispiel
meldet eine Zelle die geplante Fertigstellung eines gerade bearbeiteten Teiles an das
Fördersystem und fordert für diesen Zeitpunkt gleichzeitig Nachschub an. Hierbei stellen sich
mehrere Anforderungen: zum einen muss diese Meldung persistent sein, darf also bei
zwischenzeitlichem Verbindungsabbruch nicht verloren gehen. Andererseits ist ein Ausfall
Exemplarische Anwendungsfälle
13
des Fördersystems nur relevant, wenn es zum geforderten Zeitpunkt nicht wieder
betriebsbereit und online ist. Folglich ergibt sich die Notwendigkeit einer Implementierung
von ausreichend differenzierten Fehler-Reaktionen sowohl zeitlich als auch in Abhängigkeit
von den zu benachrichtigenden Teilnehmern in Netz.
2.1.6 Kopplung mit übergelagerten Verwaltungssystemen
Neben der parallelen Kommunikation zwischen den Zellen und eventuellen Logistik-
Systemen ist auch die Kopplung mit der übergelagerten Ebene in Form eines
Produktionsplanungs- und Steuerungssystem (PPS) einzubeziehen. So kann aus dem PPS
die Anforderung kommen, einen gerade laufenden Produktionsauftrag abzubrechen oder
zeitlich umzuplanen. Ein PPS arbeitet hierbei auf einer höheren Abstraktionsebene. So wird
die Anforderung einen Produktionsauftrag zu stornieren nur einmal und allgemein der
Fertigung gemeldet. Es liegt in der Verantwortung des Fertigungssystems, die jeweils
betroffenen Teilsysteme über solch eine Änderung zu informieren. So stellt sich die
Anforderung eine Möglichkeit der Definition ineinander verschachtelter Gruppen
bereitzustellen, die sowohl rekursiv als auch meldungsabhängig sein sollten. So sendet zum
Beispiel das PPS eine Meldung über Änderungen von Produktionsaufträgen an eine
bestimmte Zelle. Die Zelle beinhaltet ihrerseits mögliche Subsysteme wie eine Bilderkennung
in Form einer intelligenten Kamera, für die die jeweils anstehende Meldung aber nicht
unbedingt relevant sein muss.
2.1.7 Anlagenkonfiguration, Backup-Mechanismen
Ein weiteres wichtiges Thema ist die Verwaltung von Anlagendaten wie auch Backup-
Mechanismen, die bei Ausfall einer Steuerung deren schnellen Ersatz ermöglichen und
hierdurch die Maschinen-Stillstandszeiten minimieren. Das Beispiel einer Fertigungsstrasse
für Autos verdeutlicht dies auf besonders anschauliche Weise. Wird die Anlage abrupt zum
Stillstand gebracht (zum Beispiel durch Betätigen des Not-Aus-Schalters), verbleiben die
jeweiligen Schweiss-Roboter auf ihren gerade eingenommenen Positionen in der Karosserie
des jeweiligen in der Produktion befindlichen Autos. Bei dieser Aktion kann die Information
über die aktuelle Position des Roboters verloren gehen. Als Folge muss jeder einzelne in
dieser Situation befindliche Roboter mittels Handsteuerung von Mitarbeitern einzeln aus der
Karosserie navigiert werden. Diese Situation könnte durch den Einsatz einer geeigneten
Middleware entschärft werden. Hierfür meldet jeder Roboter während des
Fertigungsprozesses ständig seine aktuelle Position an einen Dienst der Middleware. Da
sich der Dienst auf einem anderen Rechner im Netz befindet, wird die Ablaufgeschwindigkeit
des Roboters an sich nur marginal beeinträchtigt. Voraussetzung ist jedoch eine ausreichend
schnelle Verbindung und Reaktionszeit der Middleware an sich.
Exemplarische Anwendungsfälle
14
2.1.8 Extrahierte spezifische Anforderungen
Aufgrund der betrachteten Produktionslinie können folgende spezifische Anforderungen an
eine unterstützende Middleware extrahiert werden:
-
Die Einführung einer einheitlichen Kommunikation aufgrund der Notwendigkeit ein
heterogenes Produktumfeld miteinander zu kombinieren.
-
Eine vom Sender unabhängige Verteilung von Informationen zur Erreichung von
Unabhängigkeit und Flexibilität.
-
Die Verteilung von Teilaufgaben mit dem Ziel einzelne Teilnehmer zu entlasten, als auch
eine Aggregation und damit Verallgemeinerung zu erreichen.
Exemplarische Anwendungsfälle
15
2.2 Kommissionieranlage
Ein weiteres Einsatzgebiet ist die Logistik-Automation in den diversen Ausprägungen
Kommissionierung sowie unterschiedlichen Arten der Lagerverwaltung.
Abbildung 2-2 Automatisiertes Lager [viastore]
So lohnt sich eine komplette Automatisierung nicht in allen Fällen. Während zum Beispiel ein
vollautomatisiertes Hochregallager eher für größere Mengen eines eingelagerten Artikels
gedacht ist, werden Kleinteile oder auch Artikel in geringen zu pickenden Mengen von Hand
kommissioniert. Zu diesem Zweck hat sich der Einsatz von Personal Digital Assistants
(PDA's) für die Datenerfassung vor Ort durch den Kommissionierer etabliert, oft auch in
Kombination mit einem eingebauten Barcode-Scanner. Das Handheld zeigt ihm dabei den zu
bearbeitenden Kommissionierauftrag und führt ihn zu den Lagerorten. Durch Scannen wird
die Entnahme (der Pick) bestätigt und per Funk dem Lagerverwaltungssystem mitgeteilt. Es
handelt sich also schlussendlich um ein verteiltes System mit auf verschiedenen Ebenen
angesiedelten Teilnehmern: PDA, Warenwirtschaftssystem (Host) sowie Leit- und
Steuerrechner deren unterschiedliche Hardware und Betriebssysteme durch geeignete
Kommunikationstechniken zu kombinieren sind.
Exemplarische Anwendungsfälle
16
2.2.1 Spontaneous Networking
Hierbei ist besonders die Eigenart der dynamischen Verbindungen interessant: Die PDAs
werden in der Regel mittels Funk den Kontakt zum Leitrechner suchen. Es kommt nun vor,
dass der Kontakt abbricht wenn sich zum Beispiel der Kommissionierer hinter einem
besonders hohen Regal befindet, er das Gerät zur Pause ausschaltet oder die Batterie leer
ist. Folglich stellt sich die Anforderung, mit solch temporären Verbindung umgehen zu
können, um die Persistenz der Datenkommunikation zu gewährleisten.
2.2.2 Lagerorte
Für stärker automatisierte Lager- und Kommissionieranlagen kommen oft Förderstrecken in
Form von Rollenförderern zum Einsatz. Ein kritischer Punkt hierbei ist die korrekte
Einlagerung der spezifischen Ware. Denn wird der falsche Lagerort verbucht, so gestaltet
sich das nachträgliche Auffinden der Ware als enorm aufwendig, wenn nicht sogar
unmöglich. Bewirkt darüber hinaus ein essentieller Fehler in der Verbuchung eine generell
falsche Einlagerung, kann der Notstand nur durch eine Inventur in Form einer kompletten
Auslagerung behoben werden. Solche Verbuchungsfehler treten beispielsweise durch einen
nicht geplanten Versatz in der Kommissionierstrecke auf: Die verantwortliche Steuerung
merkt sich hierbei am so genannten Identifikationspunkt (I-Punkt) Art und Inhalt des Paketes
und schickt dieses auf die Förderstrecke. Die Position des Paketes auf dem Weg zum
Lagerort wird mittels Lichtschranken erkannt, wobei die Steuerung sich die Reihenfolge aller
auf der Strecke befindlichen Pakete merkt:
I-Punkt
Materialfluss-
Rechner (MFR)
Legt auf Band
Meldet
an MF R
1
2
3
4
5
Transport zum Lagerort
Abbildung 2-3
Kommissionierung: Reihenfolge auf Band
Exemplarische Anwendungsfälle
17
Verliert nun die Steuerung die Kenntnis über die aktuelle Position und Reihenfolge der
Pakete (zum Beispiel durch Stromausfall), kann die kritische Situation nur durch Entleeren
der Förderstrecke behoben werden. Auch der Einsatz von Identifizierungs-Mechanismen in
Form von Transpondern oder RFIDs
1
für die einzelnen Pakete behebt das Problem nur
teilweise: sie müssen immer noch zur Identifizierung zumindest an einen weiteren I-Punkt
transportiert werden. Eine Middleware könnte für solche Anforderungen den Steuerungen
unterstützende Funktionen in Form von Backup-Mechanismen oder nichtflüchtigen Speicher
bereitstellen, mittels deren eine Wiederherstellung des letzten Zustandes vor dem
Systemausfall möglich ist.
2.2.3 Transaktionen
Der Begriff der Transaktion ist im Bereich der Datenbanken wohl bekannt. Dort dient sie zur
Sicherstellung der Datenkonsistenz. So ist die Transaktion einer Banküberweisung erst dann
abgeschlossen wenn sowohl das Zielkonto als auch das Quellkonto verbucht worden sind.
Schlägt eine dieser Aktionen fehl, dann erfolgt die Herstellung des originalen Zustandes zu
Beginn der Transaktion, auch als ,,Rollback" bezeichnet. Der Begriff der Transaktion kann
jedoch über solche Konsistenzsicherungen hinaus auch auf umfangreichere Abläufe
angewendet werden. Durch die beispielhafte Betrachtung der Ein- und Auslagervorgänge in
einem Lager für Textilien (Stoffe, Knöpfe, Fäden) soll dies näher verdeutlicht werden:
2.2.3.1 Einlagerung
Ein LKW liefert eine Ladung Stoffballen an. Um die Qualität der angelieferten Ware zu
überprüfen werden einige Ballen ausgeschleust um deren Qualität durch Aufspannen auf
einer Schau-Wickelmaschine und folgender Sichtprüfung zu verifizieren. Diese Ballen
werden als so genannte QS-Ballen (in der Qualitätssicherung befindlich) gekennzeichnet. Da
die Vorzone des Lagers für weitere Lieferungen frei gehalten werden muss, wird derweil die
Einlagerung der restlichen Ballen initiiert. Nun erweist sich nach einer gewissen Zeit der QS-
Ballen als fehlerhaft und es wird die Entscheidung getroffen, die gesamte Lieferung anstatt
einzulagern in einen dedizierten Sperrbereich des Lagers zu transportieren. Dies hat
folgende Auswirkungen:
-
Schon eingelagerte Ballen müssen wieder ausgelagert werden,
-
gerade auf der Förderstrecke befindlichen Ballen müssen umgeleitet werden,
-
noch in der Vorzone befindliche Ballen müssen eine neue Zieladresse bekommen.
1
Radio Frequency Identification Devices
Exemplarische Anwendungsfälle
18
Jede dieser Aktionen impliziert eine ganze Anzahl von geänderten und für die Förderstrecke
einzuplanenden Transportaufträge, so dass die klassische Umsetzung dieser Anforderung,
die Umbuchung von einer zentralen Instanz aus, sich als recht aufwendig erweist. Nun kann
der Vorgang ,,Einlagerung aller Stoffballen der Lieferung" auch als eine Transaktion
angesehen werden, die durch die Entscheidung für die Umlagerung ein ,,Rollback mit neuem
Ziel" erfährt und ihrerseits selbständig alle notwendigen Aktionen durchführt.
2.2.3.2 Auslagerung
Transaktionen können auch im Bereich der Kommissionierung auftreten, wie folgendes
Beispiel erläutern soll. Ein Produktionsauftrag benötigt eine durch die Stückliste und die
Anzahl der herzustellenden Fertigteile festgelegte Anzahl an Rohwaren. Diese Rohwaren
müssen zusammengestellt und als Ganzes ausgelagert werden. So werden zum Beispiel für
eine Anzahl zu produzierender Hosen eine definierte Menge Stoff, Faden, Knöpfe, Einlagen
und anderes benötigt. Das übergelagerte Warenwirtschaftssystem sendet daher einen
Auslagerauftrag mit den geforderten Mengen an das Lager, der an sich als eine Transaktion
betrachtet werden kann. Das Lagerverwaltungssystem erzeugt wiederum die benötigten
Transportaufträge, zum Beispiel für die Auslagerung des Stoffes aus dem Hochregallager
sowie die zugehörigen Knöpfe aus dem Kleinteilelager. Während der nebenläufig
ablaufenden Auslagervorgänge trifft nun eine nicht vorhergesehene Situation ein: Knöpfe
fehlen, der Stoff wird beschädigt oder ähnliches. Da der Bedarf für den Produktionsauftrag
nur komplett ausgeliefert werden soll, muss der gesamte Auslagervorgang gestoppt und
eventuell schon ausgelagerte Waren wieder eingelagert werden. Die Auslagerung wird also
storniert was einem klassischen Rollback der Transaktion entspricht und, wie schon beim
Einlagerbeispiel, die Generierung eines Satzes geeigneter Transportaufträge für die
Wiedereinlagerung erfordert.
Besonders das letzte Beispiel verdeutlicht die unterschiedlichen Bedeutungen eines
,,Rollbacks": Das Ziel eines klassischen Rollbacks, wie es bei Datenbanken definiert wird, ist
es, den Urzustand genau wieder herzustellen. Nicht so die Rückführung der schon
ausgelagerten Waren in das Lager. Hier ist es nicht das Ziel, die Waren an genau die gleiche
Stelle wieder einzulagern, von der sie entnommen worden sind. Dieser Lagerort ist
womöglich zwischenzeitlich durch eine unabhängige Einlagerung schon wieder besetzt. Die
Definition ,,Ausgangszustand" ist somit auf einer höheren Ebene angesiedelt: die Ware ist
unabhängig vom tatsächlichen Lagerort wieder in den Zustand ,,am Lager" zu bringen und
damit für weitere Entnahmen verfügbar zum machen.
Exemplarische Anwendungsfälle
19
Bietet nun die Middleware generelle Funktionen an, mit deren Hilfe auf abstrakter Ebene
Entscheidungen und Reaktionen definiert werden können, kann die softwaretechnische
Implementierung solcher Abläufe erheblich vereinfacht werden.
2.2.4 Optimierungen
Prinzipiell begrenzt die jeweils eingesetzte Fördertechnik die maximale Geschwindigkeit des
Systems. So ist die Zeitspanne für ein Doppelspiel in einem Hochregallager - zum Lagerort
hinfahren, Ware holen und zum Auslagerpunkt bringen - hauptsächlich von den
mechanischen Randbedingungen des Regalbediengerätes (RBG) wie Beschleunigung und
maximale Geschwindigkeit abhängig. Um trotzdem einen möglichst hohen Durchsatz zu
erreichen, gibt es verschiedene Ansätze zur Optimierung. So kann durch geeignete
Kombination der Fahraufträge innerhalb eines Doppelspiels eine kombinierte Ein- und
Auslagerung erfolgen. Auch ist sicherzustellen, dass die Zuführung zum RBG ohne
Zeitverlust erfolgt.
2.2.5 Anlagenauslastung
Die Kapazität eines Logistik-Systems ist grundsätzlich begrenzt. Bei Überlastung wird ein
Stau erzeugt, den es so weit wie möglich zu vermeiden gilt. Eine Möglichkeit ist, so genannte
Puffer-Bahnhöfe einzurichten, in denen Ware bei Überlastung zwischengelagert wird. Eine
Überlast in gesonderten Bereichen kann jedoch auch aufgrund von Meldungen vorgelagerter
Transportstrecken vorherberechnet werden, so dass geeignete Maßnahmen getroffen
werden können bevor die Anlage aufgrund eines Staus stehen bleibt. Dies kann
beispielsweise durch eine direkte Kommunikation der einzelnen Steuerungen untereinander
realisiert werden, die - ähnlich einem Agentensystem - Situationen melden und über
alternative Routen verhandeln.
Solche Aufgaben stellen einen Teil des so genannten Materialflussrechners (MFR) dar.
Hierbei handelt es sich um ein Programm, das unter anderem durch die Planung und
Verteilung der Fahraufträge auf die Fördertechnik eine möglichst optimale Auslastung der
Anlage sicherstellen soll. Zur Unterstützung dieses Programms kann die Middleware
zusätzlich Dienste bereitstellen.
2.2.6 Echtzeitanforderungen (Realtime)
Bei bestimmten Abläufen in der Automation können spezielle Anforderungen an ein Echtzeit-
Verhalten gestellt werden. Unter Echtzeit ist hierbei die Rechtzeitigkeit, also die zugesicherte
Reaktion innerhalb eines vorgegebenen Zeitraums zu verstehen. Sie ist folglich nicht
Exemplarische Anwendungsfälle
20
unbedingt mit dem Begriff ,,schnelle Reaktion" gleichzusetzen. Man unterscheidet zwischen
harten und weichen Echtzeitanforderungen. So schreibt Burns:
,,Hard real-time systems are those where it is absolutely imperative that responses occur
within the specific deadline. Soft real-time systems are those where response times are
important but the system will still function correctly if deadlines are occasionally missed."
[BWRS93]
Da die Anforderungen an ein hartes Echtzeitsystem sehr hoch sind, müssen sämtliche
Ebenen echtzeitfähig gestaltet werden. Dies schließt neben einem geeigneten
Transportprotokoll für die Übertragungsschicht ein echtzeitfähiges Betriebssystem bis hin zu
echtzeitfähigen Applikationen ein. Folglich reicht es nicht aus wenn die Middleware als
solches als ,,echtzeitfähig" tituliert wird. Weiche, und damit unkritischere
Echtzeitanforderungen hingegen können zumindest zum Teil auf konventionellen Netzen und
Betriebssystemen umgesetzt werden. Zur Verdeutlichung wird dazu am folgenden Beispiel
der rechtzeitigen Ausschleusung eines Paketes exemplarisch eine weiche
Echtzeitanforderung veranschaulicht
2
. Für die Versendung von Büchern wird eine
automatische Kommissionieranlage eingesetzt. Diese besteht aus einem inneren Kreis für
die mit den Büchern zu füllenden Kartons und Stationen, an denen jeweils eine Teilmenge
aller zu versendenden Bücher positioniert sind:
Station
Station
Station
I
Punkt
Innerer Kreis
Ausschleusung
Abbildung 2-4 Kommissionieranlage Buchversand
2
Beim vorliegenden Beispiel handelt es sich um einen realen Vorfall innerhalb eines Projekts bei dem
der Autor als Software-Entwickler beteiligt war.
Exemplarische Anwendungsfälle
21
Am I-Punkt wird ein leerer Karton auf das Tablar gesetzt und ein Kommissionierauftrag
sowohl mit dem Karton als auch dem Tablar verknüpft
3
. Das Tablar geht auf die Reise im
inneren Ring und soll überall dort ausgeschleust werden, wo dem Auftrag entsprechend
Bücher zu picken sind. Ist der Auftrag komplett befriedigt, wird der volle Karton aus dem
inneren Kreis ausgeschleust und der Versandabteilung zugeführt. Hierfür ist kurz vor der
Station ein Detektor installiert, der die Identifikation des Tablars von seinem Transponder
ausliest:
Tablar
Transponder
Detektor
St
a
ti
o
n
St
a
ti
o
n
A) Tablar wird
identifiziert
B) Tablar wird
ausgeschleust
Abbildung 2-5 Ausschleusung Tablar
Jedes Tablar identifiziert sich etwa einen Meter vor der Ausschleusungsstelle mittels
Auslesen eines Transponders. Die Steuerung startet darauf hin eine Anfrage an den
Leitrechner ob das Tablar an die aktuelle Station ausgeschleust werden soll. Der Leitrechner
überprüft den Status des Auftrages, vergleicht die noch zu pickenden Bücher mit der an der
anfragenden Station befindlichen Teilmenge und beantwortet daraufhin die Anfrage. Die hier
beschriebene Kommunikation muss abgeschlossen sein bevor das sich mit einer definierten
Geschwindigkeit bewegende Tablar die Ausschleusungsstelle passiert. Die Middleware
muss daher auch in Zeiten starker Netzauslastung für diesen Ablauf eine gesicherte
Antwortzeit gewährleisten. Wird das Zeitfenster verpasst, sind die Auswirkungen zwar
unerwünscht aber unkritisch im Hinblick auf das Funktionieren der Anlage an sich: das
Tablar bekommt nach einer Umkreisung wieder die Möglichkeit der Ausschleusung. Somit
handelt es sich um eine weiche Echtzeitanforderung.
3
In der Logistik wird dieser Vorgang auch ,,verheiraten" genannt.
Exemplarische Anwendungsfälle
22
Abbildung 2-6 Bild Tablar-Weiche
2.2.7 Extrahierte spezifische Anforderungen
Aufgrund der betrachteten Logistiksysteme können zusätzlich zu Kapitel 2.1 folgende
spezifische Anforderungen für diesen Bereich an eine unterstützende Middleware extrahiert
werden.
- Die Unterstützung von dynamischen Verbindungen einzelner Kommunikationspartner.
- Funktionen zur Unterstützung von Persistenz damit systemrelevante Daten auch bei
einem Teilausfall einzelner Teilnehmer nicht verloren gehen.
- Die Bereitstellung von Funktionen zur Kapselung von Einzelaufgaben zu einer
Transaktion.
- Unterstützung von Optimierungsmechanismen in Form von Analyse-Werkzeugen, um z.B.
Auslastungen von Teilbereichen der Anlage zu ermitteln.
- Unterstützung weicher Echtzeitanforderungen indem die Möglichkeit von Priorisierungen
der Kommunikation bereitgestellt wird.
Ausschnitt der Kommissionieranlage:
Das Tablar im Vordergrund wird gerade
an die Station ausgeschleust und folgt
dem schon in der Station befindlichen
Tablar.
Im inneren Kreis sind weitere Tablare zu
sehen, die eventuell die Weiche verpasst
haben.
(Da das Foto während der
Inbetriebnahme aufgenommen wurde,
fehlen die zu bepackenden Kartons auf
den Tablaren).
Exemplarische Anwendungsfälle
23
2.3 Gebäudeautomation
Die Automatisierung im Bereich von Wohn- und Bürohäusern - in der Gesamtheit auch als
,,intelligentes Haus" bezeichnet - stellt sich als ein Markt mit hohem Entwicklungspotential
dar. Die kombinierte und automatische Steuerung von Rollläden, Licht, Heizung,
Klimaanlage sowie auch Sicherheits- und Überwachungs-Funktionen (beispielsweise auch
durch Roboter wahrgenommen) sind hierbei nur einige aktuelle Themen. Besonders der
Einsatz in großen Gebäuden (Bürotürme, Hotelanlagen) boomt, denn hier ist in der Regel
auch das notwendige Investitionskapital vorhanden und damit eine Rentabilität eher
gegeben.
Vielfältige Szenarien sind denkbar. So sind die ersten autonomen Service- und
Überwachungsroboter auf dem Markt verfügbar, die über ihren eigentlichen Einsatz als
,,Sicherheitspersonal" hinaus vielfältige Funktionalitäten ermöglichen:
Abbildung 2-7 Überwachungsroboter in einem Gebäude [Wstct2203]
2.3.1 Ortstransparente Interkommunikation
Die Steuerung der Gebäudebeleuchtung ist eine denkbare Funktion: So ist es eine Aufgabe
des Hausmeisters jeden Abend durch die Büroräume zu laufen und das vergessene Licht
auszuschalten. Diese recht stupide Aufgabe kann auch der Roboter übernehmen: er stellt
mittels eines Lichtsensors die Beleuchtung fest und weist das Zimmer daraufhin an, das
Licht auszuschalten (nicht ohne zuvor noch überprüft zu haben ob sich noch jemand im
Zimmer aufhält). Bei diesem relativ simplen Beispiel erkennt man die Notwendigkeit der
Exemplarische Anwendungsfälle
24
Implementierung einer Ortsabhängigkeit: Der Roboter muss abhängig von seiner aktuellen
Position Kontakt zu der jeweils zuständigen lokalen ,,Intelligenz" in Form eines
Verwaltungsprogramms aufnehmen.
2.3.2 Entscheidungsfindungen
Ein weiteres Szenario ist die Reaktion auf unvorhergesehene Ereignisse, die auch den
Zustand des Roboters selbst betreffen können. So könnte ein mobiler Roboter aufgrund von
unvorhergesehenen Hindernissen nicht in der Lage sein, seinen geplanten Weg weiter zu
verfolgen. Nun sollte er in der Lage sein in der Nähe befindlichen ,,Kollegen" diese Situation
kundzutun und um eine Übernahme seiner unvollendeten Aufgabe zu bitten. Hier sind Wahl-
Algorithmen einzusetzen: die verbleibenden Roboter müssen aufgrund unterschiedlicher
Kriterien entscheiden können, wer die Aufgabe übernehmen soll. Darüber hinaus ist eine von
den jeweils aktuellen Teilnehmern abhängige Reaktion vorzusehen: ist zufällig der
Hausmeister in der Nähe (was gleichbedeutend ist mit der Tatsache, dass sich sein PDA
online im Netz befindet), so ist es angebracht, zunächst den Menschen über die
Ausnahmesituation zu benachrichtigen, anstatt einen Alternativroboter auszuwählen.
2.3.3 Priorisierungen
Die Übertragung von Bilddaten einer Anzahl von hoch auflösenden Kameras kann das Netz
so stark belasten, dass andere eventuell wichtigere Meldungen nicht oder nicht rechtzeitig
versendet werden. Hier sind Priorisierungen der Datenleitungen vorzusehen, die ihrerseits
nicht unbedingt an der Art des jeweiligen Gerätes festgemacht werden können. So kann die
Bildübertragung einer Kamera in der Fertigung sich sehr wohl als zeitkritisch erweisen, wenn
es sich zum Beispiel um eine Bilderkennung von Teilen auf einem sich schnell bewegenden
Trägermedium handelt. Ein Beispiel ist die Aussortierung von Schlecht-Teilen durch einen
Roboter, also eine klassische ,,Pick-and-Place"-Anwendung in Kombination mit einer
Bilderkennung. Die Erkennung von Schlechtteilen und deren Meldung an den Roboter muss
so rechtzeitig erfolgen, dass der Roboter das Teil vom Laufband picken kann. Hier erkennt
man auch, dass die Funktionalität der Priorisierung eng verbunden mit der Einhaltung von
Echtzeitanforderungen ist.
2.3.4 Statistiken
Auch in der Gebäudeautomation ist eine BDE-Erfassung wünschenswert. So kann eine
nachträgliche Auswertung der zurückgelegten Fahrstrecken der einzelnen Roboter sowohl
als Grundlage für Optimierungen als auch zur Detektion von nicht überwachten Bereichen in
einem bestimmten Zeitraum dienen.
Exemplarische Anwendungsfälle
25
2.3.5 Sicherheit
Der Schutz gegen unbefugten Zugriff Dritter ist in jedem IT-System ein wichtiges Thema.
Ganz besonders trifft dies für eine Gebäudeautomation zu. So ist es sicher nicht
wünschenswert, dass Unbefugte durch äußere Attacken in der Lage sind, Kameras und
Roboter auszuschalten oder gar das Gebäude zu öffnen. Daher ist die Implementierung von
Sicherheitsmechanismen sowohl für die Authentifizierung und Autorisierung als auch zum
Schutz gegen Attacken wie zum Beispiel einem ,,Denial of Service" (DoS) vorzusehen. Die
Autorisierung einer durch den Roboter detektierten Person kann hierbei wiederum mittels
einer Kommunikation zwischen recht unterschiedlichen Systemen erfolgen. So meldet sich
zum Beispiel das RFID in der Jackentasche der Person und übermittelt einen Autorisierungs-
Code, der gegebenenfalls auch nur für bestimmte Bereiche im Gebäude gültig ist.
2.3.6 Heterogene Produktsituation
Es sind vielfältige Steuerungen im Bereich der Gebäudeautomation verfügbar. Motoren für
Rolläden, Fernsteuerung für Licht bzw. Klimaanlagen sind in jedem Baumarkt erhältlich. Die
Interoperabilität, also die Kombination der Einzelgeräte zu einem Gesamtsystem ist jedoch
noch nicht zufrieden stellend gelöst. Zwar existieren spezielle Feldbusse, wie zum Beispiel
der InstaBus von Siemens. Dieser erfordert jedoch eine spezielle Infrastruktur in Form von
besonderen Datenleitungen, so dass er sich in der Installation als aufwendig erweist. Zudem
ist er proprietär und damit kostenintensiv. Auch eine nachträgliche Verkabelung in
bestehenden Gebäuden gestaltet sich als aufwendig und teuer. Hier bieten sich die neuen
Funktechniken wie Bluetooth und WLAN als preiswerte Alternative an, auch unter dem
Aspekt, dass immer mehr mit obigen Funktechniken ausgestattete Systeme auf den Markt
kommen. Eine Middleware kann neben einer Sammlung von Schnittstellen auch hier Dienste
wie automatischer Verbindungsaufbau, Ausfallsicherheit sowie Wartung zur Verfügung
stellen.
2.3.7 Extrahierte spezifische Anforderungen
Auch hier wird erkenntlich, dass sich eine ganze Reihe von Anforderungen ergeben, die den
Beispielen aus den Kapiteln 2.1 und 2.2 äquivalent sind. Zusätzlich kann genannt werden:
- Ortstransparenz. Die Möglichkeit, die tatsächliche Lokalität einer Teilanwendung zu
verschleiern bzw. zu abstrahieren.
-
Bereitstellung von Funktionen zur Unterstützung von Agentensystemen.
-
Einbau von Sicherheitsmechanismen gegen äußere Angriffe.
Exemplarische Anwendungsfälle
26
2.4 Warenwirtschaftssystem (WWS)
Ein weiterer und nicht zu unterschätzender Aspekt ist die Unterstützung der
Applikationsentwickler durch die Middleware. Um bei der Gelegenheit auch die Universalität
der Vorteile bei dem Einsatz einer Middleware zu veranschaulichen wird - anstatt eines
weiteren Beispiels aus der Automation zu bemühen - anhand der beispielhaften Entwicklung
des operativen Teils eines Warenwirstschaftssystems (WWS) dieser Aspekt näher
beleuchtet. Ein WWS ist in der Regel aus folgenden Teilbereichen aufgebaut:
-
Stammdaten (Stücklisten, Rohwarenstamm, Kunden- und Lieferantenstamm usw.),
- Materialwirtschaft,
Beschaffung,
-
Produktionsplanung und Steuerung (PPS),
- Auftragserfassung,
Marketing,
- Lagerverwaltung,
Kommissionierung,
- Fakturierung,
-
Auswertungen, Übersichten, Listen.
Klassisch besteht solch ein System aus einzelnen Programmen wie zum Beispiel zur
Auftragserfassung oder Lieferscheindruck, deren Zusammenspiel über den Datenaustausch
mittels einer zentralen Datenbank realisiert ist. Die Architektur hat sich bewährt solange es
sich um ein für eine bestimmte Firma speziell entwickeltes System handelt und damit eine
Art Maßanfertigung darstellt. Sie hat den Vorteil, genau auf die Bedürfnisse und den Ablauf
der Firma angepasst zu sein und gewährleistet dadurch ein Optimum an Effektivität und
Produktivität.
Solch eine Speziallösung weist jedoch gravierende Nachteile für den Anwender auf:
- Hohe Beschaffungskosten: da es sich um ein Einzelstück handelt, können die
Entwicklungskosten nicht auf mehrere Kunden verteilt werden.
- Hohe Anpassungskosten: ein WWS muss in der Lage sein sich an neue
Gegebenheiten flexibel anpassen zu können (ein Unternehmen wird zugekauft, neue
Produkte werden hergestellt, Tochterfirmen gegründet usw.). Solche Änderungen
müssen im WWS mit aufgenommen und abgebildet werden.
- Geringer Investitionsschutz: der Anwender ist in hohem Maße vom Ersteller des
Systems (meist ein Softwarehaus) abhängig. Geht dieses Bankrott, fällt im
schlimmsten Fall jeglicher Support und Wartung aus und der Anwender ist
gezwungen, das WWS gegen ein neues auszutauschen.
Aber auch für das Softwarehaus, das die Applikation programmiert hat, ergeben sich
negative Auswirkungen:
Exemplarische Anwendungsfälle
27
- Keine oder nur sehr bedingte Wiederverwendbarkeit: Die Erstellung einer
Maßanfertigung ist an sich schon aufwendig und damit teuer für den Kunden (s.o.).
Als Folge sind große Gewinnspannen nicht realisierbar. Meist kann das
Softwarehaus sich glücklich schätzen, bei der ganzen Sache nicht selbst in die
Verlustzone zu geraten.
- Exponentiell steigender Wartungsaufwand: mit jedem neuen Kunden entsteht ein
neues System, dass gepflegt und gewartet werden muss. Es entstehen
Wissensmonopole: Meist kennt nur ein Entwickler bestimmte Bereiche einer
speziellen Kundenapplikation. Fällt dieser durch Krankheit aus oder verlässt er gar
die Firma, entsteht eine nur schwer zu schließende Wissenslücke.
Es zeigt sich also dass die Erstellung von individuellen und einzigartigen Applikationen nicht
effizient genug ist. Man sucht daher seit vielen Jahren nach Möglichkeiten der
Wiederverwendbarkeit, um die Investitionskosten auf mehrere Endkunden aufteilen zu
können. Folgende mehr oder minder erfolgreichen Ansätze sind zu beobachten:
2.4.1.1 Ansatz a: Der Kunde passt seine Organisation an die Applikation an
Für ein Softwarehaus ist das ein verlockender Gedanke: es erstellt einmal ein WWS, erfindet
bei der Gelegenheit das Ei des Kolumbus und verkauft dieses unverändert an andere
Kunden, die zumindest in der gleichen Branche tätig sind. Branchen übergreifend ist solch
ein Ansatz überhaupt nicht denkbar, da die Unterschiede zwischen den Abläufen bei der
Produktion von z.B. Autos und Textilien doch recht umfangreich sind. Nur wird sich leider
kein Kunde darauf einlassen. Die Firmen sind in der Regel stolz auf ihre Art der
Geschäftsabwicklung und führen meist auch einen Teil ihres Erfolges auf deren individuelle
Organisation zurück, die sich von der Konkurrenz abhebt. Zudem gibt es immer gewachsene
Strukturen zu berücksichtigen, die - einmal abgesehen von ihrem Sinn oder Unsinn - nicht
einfach zerstört werden können und sollten, da diese auch ein guter Teil der jeweiligen
individuellen Firmenkultur wieder spiegeln.
2.4.1.2 Ansatz b: Die Software beinhaltet alle denkbaren Funktionalitäten
Um nun die Vielfältigkeit der Kundenwünsche abbilden zu können, wird daher versucht das
Problem von einer anderen Richtung anzugehen: Die Applikation beinhaltet die Übermenge
aller denkbaren Geschäftsprozesse und wird an die Wünsche und Gegebenheiten des
jeweiligen Unternehmens mittels geeigneter Konfigurierung angepasst. Das ist der Weg, den
unter anderem auch das Softwarehaus SAP eingeschlagen hat. Recht erfolgreich, jedoch mit
ein paar unangenehmen Nebeneffekten belegt: Das SAP-System ist nicht etwa günstig wie
man meinen müsste - ganz im Gegenteil. Der Grund liegt darin, dass die ,,Toolbox" im Laufe
Exemplarische Anwendungsfälle
28
der Jahre und mit steigender Anzahl der Kunden enorm komplex geworden ist. Als Folge
stellt sich die Konfigurierung (in SAP-Kreisen auch ,,Einführung" genannt) als sehr aufwendig
dar und ist nur von gut geschulten und damit teuren Fachkräften durchführbar. Aufgrund
dessen hat SAP sogar eine eigene Sprache entwickelt mit der Folge, dass einzelne Bereiche
wieder spezifisch und damit individuell programmiert werden müssen. Daraus resultiert
jedoch wiederum eine Gefährdung des Investitionsschutzes. Denn trotz aller SAP-Standards
gibt es bei großen Firmen immer einen Satz von speziellen und genau für diese Firma
geschriebenen Modulen, die beim nächsten Release-Wechsel wieder neu angepasst und
umprogrammiert werden müssen. Schlussendlich ist die an sich gute Idee im Laufe der Zeit
doch wieder zu einer Individuallösung mutiert, die nun jedoch aufgrund des Einsatzes einer
Standard-Software an sich als ,,Standard" bezeichnet wird. Zudem lohnt sich der Einsatz für
kleine bzw. mittelständische Unternehmen schon allein wegen der exorbitanten Kosten nicht.
Dort ist eine Spezialanfertigung trotz ihrer Exklusivität meist billiger und zudem effektiver.
2.4.1.3 Ansatz c: Aufteilung in speziell angepasste Module und allgemein gültige
Module
Nachdem festgestellt wurde, dass die beiden oben beschriebenen Extreme nicht das erhoffte
Resultat bringen, erscheint eine Kombination von beiden als ein vielversprechender Ansatz.
Die nahe liegende Lösung ist, hierbei auf der klassischen Architektur aufzusetzen: Bereiche,
in denen es zwischen den Firmen tatsächlich wenig Unterschiede gibt (zum Beispiel die
Benutzerverwaltung oder Menü-Führung) werden standardisiert (Ansatz (a)). Einzelne
Programme, wie die Auftragserfassung werden je nach Kundenwunsch gegen verschiedene
Varianten ausgetauscht (Ansatz (b)). Wenn irgend möglich, wird zudem durch geeignete
OO-Methoden ein Teil des Codes wieder verwendbar gestaltet.
In der Praxis ergaben sich bei dieser Vorgehensweise jedoch einige ungeahnte
Nebenwirkungen: Die Kommunikations-Schnittstelle zwischen den Programmen bildet
weiterhin die zentrale Datenbank. Dies hat zur Folge, dass das Datenmodell so allgemein
wie möglich gehalten werden muss, um für den Einsatz bei unterschiedlichen Kunden gültig
zu bleiben. Dies hat wiederum unerwünschte Folgen, denn schon bei so einfachen aber
essentiellen Kriterien wie der Schlüsseldefinition (Artikelnummern, Kunden-Nummern,
Material-Nummern usw.), unterscheiden sich die Firmen recht stark. Bedenkt man weiter,
dass Schlüssel die identifizierenden Attribute einer Entität darstellen wird ersichtlich, dass
kundenspezifische Anpassungen schnell Auswirkungen auf das komplette Datenmodell
haben können. Eine Lösung ist die möglichst hohe Abstraktion der Daten in allen denkbaren
Bereichen. Beispiele hierzu sind:
-
interne Schlüssel mit einem externen Erscheinungsbild maskieren.
Exemplarische Anwendungsfälle
29
-
Abstraktion von Stammdaten: so ist sowohl ein Kunde als auch ein Lieferant ein
Geschäftspartner mit unterschiedlichen Ausprägungen.
-
Allgemeine Text-Container um Sprachunabhängigkeit oder auch Masken-
beschriftungen anzupassen.
Schon bei diesen Beispielen ist ein massives Ansteigen der Komplexität des Datenmodells
ersichtlich, das sowohl zu einem hohen Aufwand bei der Programmierung als auch zu
Performance-Einbrüchen führt. Eine weitere unerwünschte Auswirkung ergibt sich aus der
zeitlichen Entwicklung eines Software-Systems: eine Applikation wächst mit jedem neuen
Kunden, der seine spezifischen Anforderungen mit einbringt. Dies hat zwangsläufig nicht
vorhersehbare Erweiterungen und Modifikationen im Datenmodell zur Folge. Wird jedoch
das Datenmodell modifiziert, müssen alle betroffenen Programme ebenfalls angepasst
werden. Das wiederum verstößt durch die entstehenden gegenseitigen Abhängigkeiten
eklatant gegen die aufgestellte Prämisse der Wiederverwendbarkeit.
Der Ansatz (b) - Abdeckung aller möglichen Variationen (in unserem Beispiel ein Satz von
Auftragserfassungsprogrammen) - ist ebenfalls nicht zufrieden stellend. In der Realität
erkennt man schnell, dass eigentlich jeder Kunde seine speziell angepasste
Auftragserfassung haben will, auch wenn die Unterschiede oft nur marginal sind. Und somit
sind wir wieder beim maßgeschneiderten Anzug, wenn auch zumindest ein kleiner Teilerfolg
zu verbuchen ist: Die Innentasche stammt aus dem Standardbaukasten und muss nicht neu
entworfen werden.
Der nächste Schritt besteht nun darin die Auftragserfassung in mehrere Module aufzuteilen:
ein austauschbares Front-End für die Erfassungsmasken und ein allgemein gültiges Back-
End für die Datenverarbeitung. Der klassische Ansatz hierfür ist ein Software-Baukasten in
Form einer Klassenbibliothek mit den Business-Objekten
4
die zu einem Programm compiliert
und gelinkt werden. Verfolgt man diesen Ansatz weiter, sind auch mehr als zwei Schichten
denkbar: eine Schicht ,,Oberfläche", eine Schicht ,,Eingabechecks", eine Schicht
,,Verbuchung". (Ähnliche Ansätze sind im Internet bei Erfassungsmasken mit Java-Applets zu
finden). Dies stellt einen viel versprechenden Ansatz dar, hat aber leider wiederum einige
Schönheitsfehler:
- Unzureichende Entkopplung der Einzelentwicklungen. An einem großen Software-
System arbeiten in der Regel eine ganze Reihe von Entwicklern gleichzeitig bzw.
4
Unter einem Business Objekt wird die Kapselung aller notwendigen Aktionen zur Durchführung eines
betriebswirtschaftlichen Vorganges verstanden. Beispiele dazu sind: Verbuchen eines Auftrages,
Zubuchung einer bestimmte Lagermenge und ähnliches
Exemplarische Anwendungsfälle
30
nebenläufig. Stößt hierbei der Entwickler einer spezifischen Oberfläche auf eine neu
benötigte Funktion, muss er warten, bis diese von einem Kollegen in der
Klassenbibliothek implementiert wird bevor er weiter programmieren kann. Diese
Aufgabentrennung ist notwendig um die jeweilige Klassenbibliothek konsistent und
wartbar zu halten.
-
Konsistenz: Nach jeder noch so kleinen Änderung an der Klassenbibliothek müsste
eigentlich ein ,,Rebuild", also eine komplette Übersetzung des gesamten Systems
durchgeführt werden. Solch ein Aufwand ist in der Praxis nicht vertretbar, mit der
Folge, dass zeitweilig verschiedene Versionen der Bibliothek im Einsatz sind, mit all
den damit zusammenhängenden Konsistenzproblemen.
Geht man nun noch einen Schritt weiter, kommt einem die Idee, die einzelnen Module als
komplett eigenständige Programme zu realisieren, die jeweils eine wohl definierte und
eingegrenzte Aufgabe erfüllen und mittels geeigneter Schnittstellen direkt miteinander
kommunizieren (im Gegensatz zu der indirekten Kommunikation über eine Datenbank). Das
hat folgende Vorteile:
-
Solch eine Architektur zwingt die Entwickler automatisch zu modularem Denken: sie
müssen eine an sich komplexe Anforderung in viele kleine aufteilen und zudem eine
geeignete Kommunikation zwischen den Modulen entwerfen. Dies führt zu der
gewünschten fein granulierten Struktur: je mehr kleine Module mit sauber definierten
Schnittstellen vorhanden sind, desto höher ist die Wahrscheinlichkeit, dass einige
davon in zukünftigen Applikationen wieder verwendet werden können.
-
Die Entwicklung im Team ist - im Gegensatz zur direkten Synchronisation über eine
Klassenbibliothek - stärker entkoppelt: zum Beispiel muss der Entwickler der GUI
nicht erst auf fehlende Funktionen warten sondern kann unabhängig und ohne
Zeitverlust an seiner Teilaufgabe weiterarbeiten. Er simuliert die noch fehlenden
Module einfach indem er seinem Programm die jeweils benötigten Telegramme
mittels eines Simulators schickt.
- Gerät ein Software-Projekt unter Termindruck (was recht häufig vorkommt), wird in
der Regel versucht, die Situation durch Einsatz von zusätzlichen Entwicklern zu
entschärfen. Jedoch führt das meist zum gegenteiligen Effekt, denn wie schon das
von Frederick P. Brooks (IBM) postulierte ,,erste Gesetz" es treffend beschreibt:
,,Das Hinzufügen zusätzlicher Arbeitskräfte zu einem verspäteten Software-Projekt
vergrößert die Verspätung". [ArSc2304]. Der Grund liegt darin, dass die notwendige
Einarbeitung der neuen Kollegen zunächst Zeit und Ressourcen bindet, bevor diese
effektiv werden können. Ein drastischer modularer Aufbau wie er hier beschrieben
Exemplarische Anwendungsfälle
31
wird, verringert diesen unerwünschten Effekt ganz erheblich, da der neue Mitarbeiter
sich zunächst nur mit den Schnittstellen befassen muss und seine Tätigkeit in der
Lernphase die Entwicklung anderer Teile der Applikation nicht oder nur marginal
behindert.
- Die Datenbankschicht dient nicht mehr als primäre Kommunikationsplattform und
kann abstrahiert werden: denkbar ist das Zwischenschalten eines Moduls zwischen
Datenbank und der jeweiligen Anwendung. Somit ist die Datenbank selbst entkoppelt.
Änderungen auf das Datenmodell haben zunächst nur Einfluss auf das DB-Connect
Modul und nicht auf das ganze System. Auch ein Austausch der kompletten
Datenbank ist möglich, was zuvor undenkbar wäre.
-
Die Applikation kann einzeln und sukzessive erweitert, ausgetauscht oder auf neue
Software-Technologien migriert werden, wobei die Auswirkungen auf den Rest des
Systems durch die restriktiven Schnittstellen minimal bleiben.
Hinzu kommen all die im folgenden beschriebenen und allgemein bekannten Vorteile eines
verteilten Systems wie Fehlertoleranz, Sicherheit, Auto-Konfiguration und Wartung usw.,
deren Einsatz in klassischen Applikationen wie einem Warenwirtschaftssystem bisher nur
sehr schwer zu implementieren oder gar undenkbar waren.
Die massive Trennung der einzelnen Module in Form von eigenständigen Programmen
erzeugt jedoch zunächst eine neue Schwierigkeit: die Modularität bewirkt im Gegensatz zur
klassischen Architektur die Notwendigkeit einer umfangreichen Interprozess-Kommunikation,
die mit jeder Einbindung eines weiteren neuen Moduls in seiner Komplexität anwächst. Somit
erhöht sich der Entwicklungsaufwand für ein Programm allein dadurch, dass plötzlich
geeignete Protokolle entworfen und implementiert werden müssen. Zudem hat die
entstehende asynchrone Verarbeitung den zusätzlichen Einbau von Synchronisierungs-
mechanismen zur Folge (Transaktionsschutz, Sortierung, Semaphoren, Mutexe).
Und hier setzt die Idee der Middleware ein: Sie kümmert sich um all die unbequemen aber
notwendigen Funktionen, die in jedem verteilten und dadurch parallel arbeitenden Software-
System implementiert werden müssen. Der Entwickler kann sich wieder voll und ganz auf die
Implementierung der jeweils geforderten und damit anwendungsspezifischen Funktionen
konzentrieren.
Die Middleware stellt darüber hinaus eine zweite Dimension der Modularisierung zur
Verfügung: Die bekannte horizontale Aufteilung der einzelnen Geschäftsabläufe wird ergänzt
durch eine vertikal angeordnete Übermittlungsschicht mit grundsätzlichen Funktionalitäten,
die völlig unabhängig von der eigentlichen Applikation ist.
skizze
Exemplarische Anwendungsfälle
32
Die anhand des Warenwirtschaftssystems aufgezeigten Anforderungen sind leicht auf den
Bereich der Automation überführbar. Auch hier werden komplexe Systeme von einer ganzen
Reihe von Programmierern entwickelt, Datenbanken eingesetzt und Programme zur
Steuerung und Visualisierung geschrieben, wobei die Vorteile eines verteilten Systems in der
Automation durch die dort bestehende heterogene Hardware-Landschaft besonders zum
Tragen kommen.
2.4.2 Extrahierte spezifische Anforderungen
Das vorliegende und für den Bereich der Automation etwas unübliche Beispiel verdeutlicht
ganz besonders folgende Anforderungen an eine Middleware:
-
die Unterstützung der Programmierer bei komplexen und verteilten Software-
Systemen durch geeignete Schnittstellen (API) und Werkzeuge.
Exemplarische Anwendungsfälle
33
2.5 Resumee
Der Einsatz einer einheitlichen Middleware für alle möglichen Systeme eröffnet auch die
Möglichkeit einer einheitlichen Basis für die auf unterschiedlichen Ebenen arbeitenden
Applikationen in einem Unternehmen. So müssen sowohl automatisierte Läger als auch
Produktionsanlagen mit einem PPS- oder Warenwirtschaftssystem kommunizieren können.
Die jeweils benötigte Ankopplung wird oft noch mühevoll und mit beträchtlichem Aufwand
speziell und proprietär programmiert. Wäre die gleiche Middleware für beide Systeme im
Einsatz, würde sich dieser Aufwand drastisch minimieren.
1
2
3
4
5
Abbildung 2-8 Einheitliche Kommunikation über die Middleware
Die Entwicklung einer kompletten Middleware mit all ihren Komplexitäten wird sich beim
ersten Einsatz sicher nicht rentieren. Mit jedem neuen Auftrag lohnt sich aber das
Warenwirtschaftssystem
WWS
Middleware
- einheitliche Kommunikation
- allgemein verwendbare Funktionen
Lagerverwaltungssystem
LVS
Produktionsplanungs-
und Steuerungssystem
PPS
Steuerungsebene
Leitebene/Leitstand
Proprietäre Protokolle
wie z.B. Feldbusse
Sonstige Applikationen
Exemplarische Anwendungsfälle
34
Vorhandensein einer solchen, denn sie vereinfacht durch ihre von Haus aus bereitgestellten
Dienste die Entwicklung unterschiedlichster Software-Applikationen an sich und ermöglicht
die lang ersehnte und nicht nur postulierte Wiederverwendbarkeit von Software. Die
Middleware bleibt hierbei dieselbe, egal ob sie für die Produktions-, Gebäudeautomation
oder für klassische Verwaltungsprogramme eingesetzt wird. Sie kapselt vom jeweiligen
Anwendungsgebiet unabhängige Funktionalitäten wie Protokollierung, Verwaltung der
Verbindungen, Ausfallsicherheit, Autorisierung und anderes.
Die Frage stellt sich, was mit einem solchen System erreicht werden kann, das nicht schon
von bestehenden Middleware-Systemen geleistet wird. Dieser Denkansatz führt jedoch in
eine falsche Richtung, denn Systeme von der Komplexität von CORBA, Jini oder
Applikationsservern nach Vor- und Nachteilen zu vergleichen erscheint müßig. Alle diese
Systeme bieten Eigenschaften, die auf bestimmte Einsatzgebiete zugeschnitten sind und
sich - wie jedes Werkzeug in anderen Konstellationen als nachteilig erweisen können. So
werden im Kapitel 4.2 der vorliegenden Thesis diese Systeme näher untersucht, um sowohl
deren Grenzen festzustellen als auch dort realisierte und für die vorliegende
Aufgabenstellung geeignete Lösungsansätze zu übernehmen.
Die Frage die sich stellt ist vielmehr, womit eine maximale Flexibilität für Entwickler
gewährleistet bleibt, die sich nicht auf ein einziges System festlegen wollen oder können. Es
soll also nicht noch ein verteiltes System geschaffen werden, das den Funktionsumfang
vorhandener Middleware-Systeme völlig abdeckt nur damit feststeht, dass es ,,besser" als
diese ist. Das eigentliche Ziel ist zu ermitteln, welche Funktionalitäten man in einem großen
Teil der üblichen Entwicklungsaufgaben ohnehin wieder findet und ob es möglich ist, diese
abzudecken ohne sich deren Nutzen mit zu großen Einschränkungen und zusätzlichem
Entwicklungsaufwand zu erkaufen.
Beschreibung der Anforderungen an ein Systemdesign
35
3 Beschreibung der Anforderungen an ein Systemdesign
Schon bei der Betrachtung von Beispielen und möglichen Einsatzgebieten wurden
bestimmte Anforderungen und bereitzustellende Funktionen an die Middleware ersichtlich.
Im Folgenden sollen diese Anforderungen näher analysiert und spezifiziert werden.
3.1 Unabhängigkeit
Der Software-Markt zeichnet sich durch den Einsatz unterschiedlicher Betriebssysteme und
Programmiersprachen aus. Der daraus resultierende zusätzliche Aufwand für das Erstellen
notwendiger Schnittstellen ist an und für sich zu befürworten, denn eine heterogene
Landschaft unterstützt und fördert grundsätzlich die Entwicklung neuer Technologien. Es ist
auch nicht erstrebenswert ein ultimatives Werkzeug für alle denkbaren Aufgaben zu
erstellen, da Funktionalitäten bei ihrer Kombination sich gegenseitig behindern oder gar
ausschließen können. Die Middleware sollte daher so gestaltet sein, dass sie diese
Heterogenität unterstützt anstatt den Entwickler einzugrenzen oder auf eine bestimmte
Plattform zu zwingen.
3.1.1.1 Plattformunabhängigkeit
Sowohl als Protokoll für die Kommunikation innerhalb des Netzes als auch zwischen Netz
und Applikationen bieten sich die Internet-Protokolle TCP/IP und UDP an. Durch deren
Einsatz wird ein hohes Maß an Unabhängigkeit von zugrunde liegenden Betriebssystemen
und Sprachen erreicht. Denn bei diesen Protokollen handelt es sich um zwei der wenigen
Standards, die sich über Jahrzehnte bewährt haben. Sie sind weit verbreitet und aus der
heutigen IT-Landschaft nicht mehr wegzudenken. Damit zeichnen sie sich gegenüber vielen
anderen Technologien aus, die nach einigen Jahren eine mehr oder weniger starke
Verbreitung erfahren und schließlich in Vergessenheit geraten, oder gar proprietär, also an
Systeme spezifischer Hersteller gebunden sind. Jedoch muss beachtet werden, dass mit
diesen Protokollen die Realisierung von Echtzeitanforderungen nur begrenzt möglich ist. Als
Folge sind harte Echtzeitanforderungen an eine Middleware auf Basis von TCP/IP
grundsätzlich auszuschließen.
3.1.1.2 Unabhängigkeit von Entwicklungsumgebungen
Für den Entwickler besteht der Nutzen einer Sprach- und Plattformunabhängigkeit darin,
dass einmal entwickelte Funktionen über lange Zeit hinweg und möglichst unabhängig von
neu eingesetzten Technologien nutzbar bleiben. Ohne die Kundenvorgaben im Hinblick auf
die einzusetzenden Programmiersprachen, Datenbanken und Ähnlichem missachten zu
Beschreibung der Anforderungen an ein Systemdesign
36
müssen, kann auf eine Bibliothek zurückgegriffen werden, die von jeder Plattform aus
anzusprechen ist. Legt man so viel wie möglich Funktionalität in die Middleware an sich, ist
die Neuentwicklung eines einzelnen Software-Moduls mit relativ geringem Aufwand
verbunden und auf die jeweils benötigte spezielle Funktionalität beschränkt. Darüber hinaus
bietet der Einsatz einer Middleware die Unabhängig von erweiterten Netzfunktionen. Sie
stellt eine Art Bibliothek zur Verfügung, die wiederkehrende Funktionen aus einer großen
Zahl von Anwendungen kapselt und ständig verfügbar macht.
3.2 Unterstützung der Applikationsentwicklung
Eine Middleware wird von Software-Entwicklern eingesetzt. Eine ihrer Hauptaufgaben ist,
diese durch Bereitstellung allgemein benötigter Funktionen zu entlasten und zu unterstützen.
Hierzu gehören:
3.2.1.1 Autokonfiguration
Die Entwickler möchten sich auf ihre eigentliche Aufgabe konzentrieren und sind an
umfangreichen Einarbeitungen oder komplexen Konfigurationen der Middleware an sich
nicht interessiert. Schließlich soll die Middleware ihnen helfen und nicht zusätzliche Arbeit
erzeugen. Ziel ist es daher, ein sich so weit wie möglich selbständig konfigurierendes
System zu entwickeln, das seine Wissensbasis über die Kommunikationsteilnehmer und -
Wege im Gesamtsystem automatisch aufbaut und verwaltet. Stichworte sind automatisches
Routing, Load-Balancing und ähnliches. Auch die spätere Wartung der laufenden Applikation
wird durch eine Autokonfiguration minimiert.
3.2.1.2 Entkopplung
Die gegenseitige Abhängigkeit von Teilmodulen einer Applikation sollte so gering wie
möglich sein. Dies ist der Hauptgrund für den Einsatz von objektorientierten Software-
Techniken. Durch eine noch höher angesiedelte Interprozesskommunikation zwischen
eigenständigen Programmen wird dieser Effekt verstärkt und ermöglicht zudem eine starke
Entkopplung der Entwicklung einzelner Software-Module. Somit sollte sowohl die
Middleware, als auch die mit deren Hilfe entstandenen Applikationen wenn möglich aus
einzelnen, getrennt laufenden Programmen bestehen.
3.2.1.3 Bereitstellung vorgefertigter Schnittstellen (API)
Eine Hauptaufgabe der Middleware ist es, die zwangsläufig entstehende Komplexität beim
Einsatz verteilter Anwendungen so weit wie möglich abzudecken und zu verbergen. Der
Applikationsentwickler soll sich nicht um technische Einzelheiten des Verbindungsaufbaus,
Beschreibung der Anforderungen an ein Systemdesign
37
Versendens oder der Wegefindung (routing) kümmern müssen. Daher muss eine API
entwickelt werden, die all diese Funktionalitäten beinhaltet und dem Entwickler eine einfache
und klare Schnittstelle bereitstellt. Zu beachten ist, dass mit Vereinfachung der Schnittstelle
zum Entwickler hin zwangsläufig die der API innewohnende Komplexität ansteigen wird.
3.2.1.4 Protokollierung
und
Monitoring
Die Protokollierung der Kommunikation innerhalb eines verteilten Systems erscheint
zunächst als banale Funktion, stellt jedoch eines der wichtigsten Werkzeuge zur
Effektivitätssteigerung der Applikationsentwicklung dar. Besonders in der Entwicklungsphase
wie auch zur Fehlersuche im System sind Hilfsmittel zur Überwachung und Protokollierung
der Kommunikation unerlässlich. Ein verteiltes System bietet gegenüber einem
monolithischen Aufbau weit mehr Möglichkeiten der Protokollierung, da die Interprozess-
Kommunikation mittels TCP/IP-Telegrammen außerhalb der Programme erfolgt und damit
offen für Analysen ist. Auch komplette Rekonstruktionen von Abläufen sind relativ leicht
möglich: Hat man den gesamten Telegrammverkehr zu einem bestimmten Zeitraum
gespeichert, dann kann das Verhalten des Systems in diesem Zeitintervall komplett
nachgefahren werden, was die Suche nach Fehlverhalten drastisch erleichtert. Es muss
jedoch beachtet werden, dass gerade durch die offene Struktur der Kommunikation ein
verteiltes System weitaus anfälliger gegen Angriffe von außen ist, so dass der Einbau von
Sicherheitsmechanismen einen hohen Stellenwert darstellt.
3.3 Ausfallsicherheit
In vielen Bereichen (und ganz besonders in der Automation) wird eine möglichst hohe
Ausfallsicherheit gefordert. Dies kann dadurch erreicht werden, dass Teile des Systems bei
Bedarf automatisch und im laufenden Betrieb durch andere ersetzt werden können (Aufbau
von Redundanzen). Optimalerweise sollte dieser Austausch ohne Beeinträchtigung des
Gesamtsystems erfolgen. Hieraus folgt wiederum, dass Module mit einem Monopol für
bestimmte Funktionalitäten zu vermeiden sind (sogenannte SPoF's: single points of failures).
Diese Anforderung klingt zunächst trivial. Jedoch hat sich bei der Entwicklung der
vorliegenden Middleware dieser Aspekt als besonders aufwendig in der Umsetzung
erwiesen.
Zur Ausfallsicherheit gehört auch die Stabilität der Middleware an sich. Fällt diese aus, führt
das zwangsläufig zum Zusammenbruch der kompletten Kommunikation und damit zum
Ausfall aller darauf aufbauenden Applikationen. So ergibt sich die Forderung, dass die
Middleware gegenüber Fehlverhalten der Applikationstasks resistent sein muss. Dies kann
durch eine Kapselung der eigentlichen Middelware-Funktionen mittels eines Application
Beschreibung der Anforderungen an ein Systemdesign
38
Programming Interface (API) erfolgen in der Art, dass ein auftretender Fehler in einem
applikations-spezifischen Programm keine Auswirkungen auf die Middleware an sich hat.
Des Weiteren müssen die Middleware eigenen Module und Programme besonders stabil
laufen, so dass intensive und breitbandige Tests notwendig sind. Jede Erweiterung eines
Programms gefährdet dessen Stabilität durch unvorhergesehene Seiteneffekte auf andere
Bereiche. Solche Effekte können durch den konsequenten Einsatz von objektorientierten
Programmiertechniken zumindest teilweise vermieden werden. Noch optimaler ist es, wenn
das System an sich in komplett eigenständige Programme aufgeteilt ist, so dass bei einer
Erweiterung der Applikation die Notwendigkeit der Modifikation vorhandener und gut
getesteter Programme komplett entfällt.
3.4 Fehlertoleranz
Es erweist sich als unmöglich, jegliche Eventualitäten in einem komplexen und verteilten
Software-System vorherzusehen und abzudecken. Um dennoch die Stabilität der Applikation
gegenüber unvorhersehbaren Situationen zu erhöhen, werden Algorithmen zur
Fehlertoleranz entwickelt. Betrachten wir zunächst die Bedeutung eines Ausfalls.
Tanenbaum schreibt hierzu:
,,Ein System fällt aus, wenn es seine Zusagen nicht mehr einhalten kann" [TaVS03].
Diese Definition ist recht interessant. Sie impliziert, dass der Ausfall einer Komponente in
einem verteilten System nicht unbedingt den Ausfall der gesamten Applikation zur Folge
haben muss. Ganz im Gegenteil zu monolithisch aufgebauten Systemen:
,,Ein charakteristisches Merkmal verteilter Systeme, das sie von Einzelplatz-Systemen
unterscheidet, ist das Konzept des partiellen Ausfalls...Dieser Ausfall kann die korrekte
Arbeitsweise bestimmter Komponenten beeinträchtigen, während er gleichzeitig andere
Komponenten nicht berührt. Im Gegensatz dazu ist ein Ausfall in einem nicht verteilten
System häufig vollständig, weil er alle Komponenten betrifft und leicht die ganze Applikation
zum Absturz bringen kann" [TaVS03].
Folglich ist die Implementierung von Fehlertoleranz überhaupt erst durch den Einsatz von
verteilten Systemen an sich möglich. Für die Implementierung von Fehlertoleranz-
Mechanismen muss zunächst geklärt werden, welche Arten von Fehlern in der zu
entwickelnden Applikation auftreten können. Hierzu gehören neben kompletten Abstürzen
auch Fehler, die nicht gleich offensichtlich zu Tage treten, wie zum Beispiel
Auslassungsfehler, Timing-Fehler, Antwortfehler und ähnliches (siehe dazu [TaVS03]).
Aufgrund dieser Klassifizierung muss dann entschieden werden, welche Strategien für die
Behandlung solcher Fehler anzuwenden sind. So kann ein Ansatz die Fehlermaskierung
Beschreibung der Anforderungen an ein Systemdesign
39
durch Redundanz sein, womit das Auftauchen eines Fehlers gegenüber den restlichen
Teilen der Applikation verborgen wird. Die Plattenspiegelung mittels eines RAID-Systems ist
hierfür ein klassisches Beispiel: fällt eine Festplatte aus, hat dies zunächst, außer einer
höheren Zugriffszeit, keine Auswirkungen auf die Applikationen. Fehlertoleranz muss folglich
zu einem gewissen Teil spezifisch auf die jeweiligen Anforderungen entworfen und
implementiert werden. Jedoch kann eine Middleware Hilfsfunktionen bereitstellen, zum
Beispiel durch geeignete Mechanismen zur Maskierung von bewusst vorhandenen
Redundanzen (siehe dazu auch Gruppen-Funktionalität im Kapitel Dienste).
3.5 Erweiterbarkeit
Die Integration neuer Dienste sollte durch symbolische Namen erfolgen. Es sollte für ein
Modul der Applikation nicht erforderlich sein zu wissen, hinter welcher physischen Adresse
sich ein Kommunikationspartner (zum Beispiel ein benötigter Dienst) verbirgt. Das Wissen
über die physischen Zieladressen sollte zudem verteilt im Netz verwaltet werden, damit
durch den Ausfall eines Knotens diese Information nicht verloren geht. Es wird daher
bewusst auf den Einsatz eines so genannten Name Servers verzichtet. Hierdurch wird
verhindert, dass sämtliche Dienste im Netz nicht mehr verfügbar sind, sobald die Verbindung
zu dem Name Server abbricht.
Eine weitere Erweiterbarkeit in räumlicher Hinsicht sollte ebenfalls durch das System
autonom gehandhabt werden können. Für den Entwickler ist lediglich interessant, ob die
Anwendung, mit der kommuniziert werden soll, verfügbar ist. Ob diese auf dem gleichen
Rechner läuft, oder in einem anderen Teil des Netzes, sollte für jede Anwendung auch dann
noch transparent sein, wenn ein Umzug während des laufenden Betriebs stattfindet.
3.6 Zugriffssicherheit (Security)
Die Erfahrung mit Viren, Trojanern und Ähnlichem im Internet zeigt, dass
Sicherheitsmechanismen gegen Angriffe von außen eine unverzichtbare Funktion einer
Middleware darstellen. Bisher handelte es sich bei automatisierten Anlagen eher um
abgeschlossene Lösungen ohne Anbindung an die Außenwelt. Dieser Zustand ändert sich
jedoch drastisch, denn immer mehr Anlagen kommunizieren direkt und im gleichen Netzwerk
mit übergeordneten Systemen, die ihrerseits mit dem Internet verbunden sind. Als Folge
müssen diese Systeme ebenfalls gegen Angriffe geschützt werden.
Beschreibung der Anforderungen an ein Systemdesign
40
3.7 Laufzeit-Optimierungen
Schon bei der Beschreibung von unterstützenden Hilfsmitteln für den Programmierer wurde
festgestellt, dass sich das System so weit wie möglich selbst konfigurieren sollte. Dies
erstreckt sich auch auf Optimierungs-Mechanismen. Denkbar ist, dass bei Aufnahme neuer
Hardware in das Netz sich die Last automatisch neu verteilt. Dies kann zum Beispiel mittels
geeigneter Verlagerung von einzelnen Programmen auf andere Rechner erfolgen. Eine
notwendige manuelle Konfiguration ist auf alle Fälle zu vermeiden, da der hierdurch
entstehende Administrationsaufwand die Vorteile eines verteilten Systems zunichte machen
würde.
Grundlage für eine automatische Last-Umverteilung sind zuvor implementierte Regeln, die,
aufgrund gesammelter Daten, selbständig die Entscheidungen zur Umverteilung treffen
können. Die Implementierung solcher automatischen Optimierungs-Algorithmen kann sehr
aufwendig werden. Daher ist zunächst einmal sicherzustellen, dass die Middleware in
geeignetem Maße gekapselt wird, so dass Änderungen und Erweiterungen keine
Auswirkungen auf die Schnittstellen nach außen haben.
3.8 Zeitsynchronisierung
Eine weitere und unabdingbare Grundlage für ein verteiltes System ist die
Zeitsynchronisierung der lokalen Uhren aller beteiligten Teilnehmer um, neben
Anforderungen aus der Echtzeit (siehe Beispiel Logistik) auch folgende Punkte abzudecken:
-
Übertragungszeiten messen und Flaschenhälse aufspüren.
- Abläufe
synchronisieren.
-
Transaktionen und Abarbeitungsreihenfolgen realisieren.
-
Erweiterte Sicherheitsmechanismen zum Einsatz bringen.
-
Korrelation dezentral erfasster Messdaten.
-
Vorausberechnende synchronisierte Regelsysteme ermöglichen.
Hierbei muss beachtet werden, dass die Zeitsynchronisierung beim Eintritt in das Netz erfolgt
und somit eine der ersten durchzuführenden Aktionen überhaupt darstellt. Darüber hinaus
sind periodische Neusynchronisierungen vorzusehen um den nicht zu vermeidenden Jitter
5
jeder lokalen Uhr zu kompensieren. Der Einsatz eines Zeitservers (SNTP) ist denkbar, stellt
5
Jitter: Varianz der Latenzzeit. Man unterscheidet auch zwischen Sofware-Jitter und Kommunikations-
Jitter.
Beschreibung der Anforderungen an ein Systemdesign
41
jedoch wiederum einen SPoF dar. Daher bietet es sich an, einen eigenen
Zeitsynchronisierungsmechanismus zu entwickeln.
Zu beachten sind Grenzen der Zeitsynchronisierung: so ist eine Synchronisierung im Nano-
Sekundenbereich nur mittels Einsatz von Hardware-Uhren möglich. Folgendes Beispiel soll
die Anforderung verdeutlichen:
3.8.1 Beispiel Papiermaschine
F
e
ld
b
u
s/
E
th
e
rn
e
t
Steuerung 1
St euerung 2
Leitrechner
Abbildung 3-1
Start einer Papiermaschine
Die einzelnen Walzen der Maschine (alle durch eine separate Intelligenz angesteuert)
müssen synchron anlaufen. Tun sie dies nicht, reißt das eingespannte Papier. Eine
Möglichkeit dies zu realisieren, besteht im Einsatz eines extrem schnellen und realtime-
fähigen Feldbusses, der die quasi zeitgleiche Ankunft des Startbefehls an allen Rollen
sicherstellt. Der Einsatz von Ethernet verbietet sich für solch eine Lösung allein schon durch
das dort verwendete CSMA/CD Verfahren (Carrier Sense Multiple Access / Collision Detect)
und dem damit verbundenen ALOHA-Effekt, der eine Übertragungszeit schon aufgrund
seiner Definition nicht zusichern kann (siehe auch [zi05] bzw. [stev00]).
Die Anforderung ,,zeitgleich starten" könnte jedoch auch durch frühzeitige Planung erfüllt
werden: Der Leitrechner sendet den Einschaltbefehl mit der zusätzlichen Information des
Einschalt-Zeitpunktes den Steuerungen, die den Befehl dann zum gegebenen Zeitpunkt
ausführen. Folglich muss nur eine an Echtzeitsysteme zu stellende Anforderung erfüllt sein:
Beschreibung der Anforderungen an ein Systemdesign
42
die zeitgleiche Reaktion von einzelnen Teilnehmern. Die gesicherte Reaktion des
Betriebssystems in einem bestimmten Zeitintervall ist hierbei nicht gefordert, sehr wohl aber
eine exakte Synchronisierung der lokalen Uhrzeit der einzelnen Steuerungen.
Ende der Leseprobe aus 251 Seiten
- nach oben
Details
- Arbeit zitieren
- , 2005, Konzeption und Realisierung einer Middleware zur Unterstützung der Interoperabilität verteilter Software-Komponenten in der Automation, Hamburg, Bedey Media GmbH, https://www.diplom.de/document/224658
Ähnliche Arbeiten
Kommentare
- Noch keine Kommentare.
Deutschlands größter Sharing Community
Jetzt Zusammenfassungen, Skripte und Klausuren kostenlos downloaden!
Uniturm.de
Ihre Vorteile als Autor
Geld verdienen Für jedes verkaufte Exemplar erhalten Sie Autorenhonorar - bis zu 40%.Kostenlose Buchveröffentlichung
Als eBook-Studie im Original und / oder auf Wunsch zusätzlich als hochwertiges Fachbuch in unserem renommierten Buchverlag.
Renommee als Fachbuchautor
Präsentieren Sie sich als Fachfrau oder Fachmann in Ihrem Fachgebiet und machen Sie sich bekannt.
Persönliche Betreuung
Unser Lektorat wird Sie persönlich betreuen und ist auch telefonisch unter 040-655992-14 erreichbar.
Weltweit im Buchhandel
Ihr Buch ist weltweit im Buchhandel und Online-Buchhandel wie z.B. amazon erhältlich.
Jetzt Autor werden!