Konzeption und Realisierung einer Middleware zur

Leseprobe

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

EINLEITUNG ...7

1.1 Motivation ... 7

1.2 Vorgehensweise ... 7

1.3 Aufteilung

auf

zwei Thesen... 8

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

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

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

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

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

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

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

ZUSAMMENFASSUNG ...126

9.1 Was wurde erreicht?...127

9.2 Ansätze

zur

Fortführung ...127

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

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

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

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

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

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

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

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

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

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

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

Transport zum Lagerort

Abbildung 2-3

Kommissionierung: Reihenfolge auf Band

Exemplarische Anwendungsfälle

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

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.

Radio Frequency Identification Devices

Exemplarische Anwendungsfälle

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

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

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

. 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

Punkt

Innerer Kreis

Ausschleusung

Abbildung 2-4 Kommissionieranlage Buchversand

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

Am I-Punkt wird ein leerer Karton auf das Tablar gesetzt und ein Kommissionierauftrag

sowohl mit dem Karton als auch dem Tablar verknüpft

. 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

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.

In der Logistik wird dieser Vorgang auch ,,verheiraten" genannt.

Exemplarische Anwendungsfälle

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

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

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

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

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

- 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

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

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

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.

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

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

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

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

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.

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

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

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

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

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

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

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

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

jeder lokalen Uhr zu kompensieren. Der Einsatz eines Zeitservers (SNTP) ist denkbar, stellt

Jitter: Varianz der Latenzzeit. Man unterscheidet auch zwischen Sofware-Jitter und Kommunikations-

Jitter.

Beschreibung der Anforderungen an ein Systemdesign

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

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

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

Titel

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

Autor

Robert Neuwirth (Autor)

Jahr

2005

Seiten

251

Katalognummer

V224658

ISBN (eBook)

9783832495312

Dateigröße

3590 KB

Sprache

Deutsch

Schlagworte

verteilte software systeme aibo automatisierungstechnik mechatronik computer engineering

Arbeit zitieren

Robert Neuwirth (Autor)

, 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

Kommentare

Noch keine Kommentare.

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

Autor

Kategorie

Institution / Hochschule

Note

Leseprobe

Details

Ähnliche Arbeiten

Kommentare

Ihre Vorteile als Autor

Passwort vergessen?

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

Autor

Kategorie

Institution / Hochschule

Note

Leseprobe

Details

Ähnliche Arbeiten

Kommentare

Ihre Vorteile als Autor