Internet der Dinge in der Intralogistik (VDI-Buch) (German Edition)

Internet der Dinge in der Intralogistik

Willibald Günthner • Michael ten Hompel Herausgeber

Internet der Dinge in der Intralogistik

13

Herausgeber Prof. Dr. Willibald Günthner Technische Universität München Lehrstuhl für Fördertechnik Materialfluss Logistik (fml) Boltzmannstr. 15, 85748 Garching Deutschland [email protected]

Prof. Dr. Michael ten Hompel Fraunhofer-Institut für Materialfluss und Logistik (IML) Joseph-von-Fraunhofer-Str. 2-4 44227 Dortmund, Deutschland [email protected]

Dieses Forschungs- und Entwicklungsprojekt wurde mit Mitteln des Bundesministeriums für Bildung und Forschung (BMBF) im Rahmenkonzept „Forschung für die Produktion von morgen“ (02PB3073) gefördert und vom Projektträger Karlsruhe (PTKA) betreut. Die Verantwortung für den Inhalt dieser Veröffentlichung liegt bei den Autoren.

ISBN 978-3-642-04895-1 e-ISBN 978-3-642-04896-8 DOI 10.1007/978-3-642-04896-8 Springer Heidelberg Dordrecht London New York Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über http://dnb.d-nb.de abrufbar. © Springer-Verlag Berlin Heidelberg 2010 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 vom 9. September 1965 in der jeweils geltenden Fassung zulässig. Sie ist grundsätzlich vergütungspflichtig. Zuwiderhandlungen unterliegen den Strafbestimmungen des Urheberrechtsgesetzes. 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. Einbandentwurf: WMXDesign GmbH, Heidelberg Gedruckt auf säurefreiem Papier Springer ist Teil der Fachverlagsgruppe Springer Science+Business Media (www.springer.com)

Vorwort

RFID und das Internet der Dinge sind mehr und mehr auf dem Weg, Eingang in unser tägliches Leben zu finden. Handyhersteller erklären, alle ihre Geräte mit RFID-Readern auszustatten, in tausenden von Projekten wird RFID weltweit in Produktion und Handel eingeführt. So gewinnt der ursprüngliche Gedanke, im Internet der Dinge mehr als nur die Identifikation von Waren mit intelligenten Etiketten zu betreiben, zunehmend an Bedeutung. Die Individualisierung im Sinne immer individueller gestalteter Produkte und Belieferungsformen findet mit dem Internet der Dinge ihre logische Fortsetzung in der Logistik. Insbesondere im Bereich der Intralogistik gewinnt der Gedanke individueller (Selbst-) Steuerung an Bedeutung. Der Grundgedanke ist, jeden Behälter, jede Palette und jedes Paket mit einem digitalen Speicher auszustatten und die gespeicherten Informationen nicht nur zur Identifikation sondern auch zur dezentralen, individuellen Steuerung jedes einzelnen logistischen Objektes zu nutzen. Diese Form des Internet der Dinge ist eine Antwort auf die Forderung nach mehr Flexibilität und die steigende Komplexität, welche als Folge der Individualisierung besonders die Intralogistik als im wahrsten Sinne des Wortes bewegende Instanz betrifft. Mit dem Ruf nach Individualität nimmt die Menge der gespeicherten und ausgetauschten Daten immer mehr zu, Geräte werden immer stärker miteinander vernetzt, das Internet und lokale Intranets bestimmen sowohl unser geschäftliches als auch unser privates Umfeld. Diese Tatsache ist aber nicht nur auf die IT beschränkt, sondern hat Folgen für die gesamte Gesellschaft und somit auch für produzierende Unternehmen, für betriebliche Organisationsstrukturen, für technologische Prozesse und Abläufe. So ist es nur natürlich, dass viele Innovationen vor allem aus dem ITBereich immer mehr in die Bereiche der Prozessgestaltung und -planung und in die Automatisierungstechnik dringen: serviceorientierte Konzepte, Softwareagenten, RFID, intelligente Feldgeräte und Sensornetzwerke sind dabei nur einige wenige Beispiele. Gleichzeitig sinken die Kosten für neue Hard- und Software rapide, sodass ein flächendeckender Einsatz unter wirtschaftlichen Gesichtspunkten möglich wird. Produktions- und Logistiksysteme müssen heutzutage so dynamisch, vernetzt und wandlungsfähig sein wie die individuellen Anforderungen der Kunden, deren Wünsche diese Anlagen zu befriedigen haben. Dabei ist es aber kaum möglich, diesem Umstand mit herkömmlichen Lösungsansätzen gerecht zu werden – auch wenn dabei modernste Technik eingesetzt wird. v

vi

Vorwort

Um eine neue, zukunftsfähige Logistik zu schaffen und damit auch die Technologie- und Wettbewerbsvorteile des „Logistikstandorts Deutschland“ zu wahren und auszubauen, ist ein Paradigmenwechsel unumgänglich. Dieser bezieht sich aber nicht so sehr auf die Technologie an sich, sondern auf die Art und Weise, wie wir sie einsetzen. Zentral gesteuerte, hochkomplexe und starre Systeme müssen durch ein hochflexibles, autoadaptives und hochgradig reaktives Netzwerk aus autonom agierenden Entitäten ersetzt werden. Anders als heute wird es dann möglich sein, Materialflusssysteme einfach zu erstellen, zu verändern und zu erweitern. Experten und Forscher aus Industrie und Wissenschaft haben sich in dem dreijährigen Forschungsprojekt „Internet der Dinge – Wandelbare Echtzeit-Logistiksysteme auf Basis Intelligenter Agenten für den produktionsnahen Bereich“ dieser Herausforderung angenommen und eine Systemarchitektur nach dem Vorbild des Internets entwickelt. So wie Router und Switches Datenpakete durch ein äußerst komplexes, sich ständig veränderndes Netzwerk zum Ziel bringen, stimmen sich autonome Materialflussmodule wie Förderer oder Weichen mit intelligentem Stückgut ab, um so eine dezentrale und hochflexible Materialflusssteuerung zu realisieren. Die Vorteile und Veränderungen, die dieser neue Denkansatz mit sich bringt, betreffen den gesamten Lebenszyklus einer Logistikanlage und bieten zahlreiche technologische und auch wirtschaftliche Vorteile. Das vorliegende Buch beschreibt im ersten Teil die aktuellen Innovationen und technologischen Gegebenheiten, die die Entwicklung eines „Internet der Dinge“ ermöglichen und bestimmen. Darauf aufbauend werden die architektonischen Konzepte wie der Modularisierungsansatz, Kommunikationsschnittstellen, Steuerungsstrategien und notwendige Softwaretools vorgestellt. Der dritte Teil zeigt dann die Veränderungen, die sich durch das Internet-der-Dinge-Modell im Lebenszyklus einer Anlage ergeben und welche Vorteile an welcher Stelle zu erwarten sind. Teil vier beschreibt ausführlich mehrere praktische Umsetzungen in Demonstrationsanlagen und Simulationen und bietet damit Einblick in die Praxis des Internet der Dinge, den dabei auftretenden Herausforderungen und den daraus gewonnenen Erkenntnissen. Dieses Buch und die darin vorgestellten Ergebnisse wurden nur durch die intensive Zusammenarbeit aller Projektpartner ermöglicht: Fraunhofer-Institut für Materialfluss und Logistik, Lanfer Cargotechnik GmbH & Co. KG, Lehrstuhl für Fördertechnik Materialfuss Logistik der TU München, LinogistiX GmbH, PSI Logistics GmbH, J. Schmalz GmbH, Siemens AG Corporate Technology, Stöcklin Logistik GmbH, Swisslog GmbH und viastore systems GmbH. Für die stets gute und produktive Kooperation möchten wir uns bei allen Partnern herzlich bedanken. Ein ganz besonderer Dank gilt dem Bundesministerium für Bildung und Forschung (BMBF) für die Förderung und dem Projektträger Forschungszentrum Karlsruhe (PTKA) für die Betreuung des Projektes. Wir danken auch dem Springer-Verlag für die angenehme Zusammenarbeit bei der Herausgabe unseres Buches. München Dortmund September 2009

Willibald A. Günthner Michael ten Hompel

Inhaltsverzeichnis

Teil I 1

2

3

4

Herausforderungen in der Intralogistik . . . . . . . . . . . . . . . . . . . . . .

1

Individualisierung als logistisch-technisches Prinzip . . . . . . . . . . . . . . Michael ten Hompel 1.1 Individualisierung als Gestaltungsprinzip . . . . . . . . . . . . . . . . . . . . . 1.2 Paradoxien der Informationslogistik . . . . . . . . . . . . . . . . . . . . . . . . . 1.3 Individualisierung als Ziel und als Ausweg . . . . . . . . . . . . . . . . . . . .

3

Neue Anforderungen für die Logistik des 21. Jahrhunderts . . . . . . . . Christoph Hahn-Woernle 2.1 Globalisierung verändert Ansprüche . . . . . . . . . . . . . . . . . . . . . . . . . 2.2 Herausforderungen für die Logistik . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3 Intralogistik kann Logistikprobleme lösen . . . . . . . . . . . . . . . . . . . . 2.4 Innovationspotenziale der Intralogistik . . . . . . . . . . . . . . . . . . . . . . . 2.4.1 Umkehrung der Warenströme . . . . . . . . . . . . . . . . . . . . . . . . 2.4.2 Demografischer Wandel erfordert Automatisierung . . . . . . . 2.4.3 Automatisierung erfordert Standardisierung . . . . . . . . . . . . . 2.4.4 Flexibilität durch Modularität . . . . . . . . . . . . . . . . . . . . . . . .

9

4 4 6

9 10 10 11 11 12 13 13

Materialf lusssteuerung heute und ihre Defizite . . . . . . . . . . . . . . . . . . . Clemens Nieke 3.1 Materialf lusssteuerung heute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2 Grenzen heutiger Systeme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

15

Entwicklungen in der Automatisierungstechnik . . . . . . . . . . . . . . . . . . Jürgen Elger und Carolin Haußner 4.1 Entwicklung der Automatisierungstechnik . . . . . . . . . . . . . . . . . . . . 4.2 Bildung mechatronischer Module . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.3 Konvergenz der Kommunikationstechnik . . . . . . . . . . . . . . . . . . . . . 4.4 Neuartige Kommunikationsmöglichkeiten . . . . . . . . . . . . . . . . . . . . 4.5 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

23

15 18

23 25 26 26 27

vii

viii

5

Inhaltsverzeichnis

Software-Methoden für die Automatisierung . . . . . . . . . . . . . . . . . . . . . Sascha Feldhorst und Sergey Libert 5.1 Software in der Automatisierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.2 Anforderungen an neue Software-Methoden . . . . . . . . . . . . . . . . . . . 5.3 Verteilte Automatisierung nach IEC 61499 . . . . . . . . . . . . . . . . . . . . 5.4 Serviceorientierte Architekturen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.5 Software-Agenten und Agentensysteme . . . . . . . . . . . . . . . . . . . . . . 5.6 Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

30 31 32 33 35 36

Literatur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

39

Teil II

Das Internet der Dinge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

41

Die Vision vom Internet der Dinge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Willibald A. Günthner, Razvan Chisu und Florian Kuzmany 6.1 Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.2 Das Internet als Vorbild . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.3 Paradigmenwechsel in der Intralogistik . . . . . . . . . . . . . . . . . . . . . . . 6.4 Ausblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

43

Echtzeitanforderungen der Materialf lusssteuerung . . . . . . . . . . . . . . . Sergey Libert und Moritz Roidl 7.1 Echtzeitanforderungen auf der Systemebene . . . . . . . . . . . . . . . . . . . 7.2 Echtzeitanforderungen auf der Komponentenebene . . . . . . . . . . . . . 7.3 Aspekte von Echtzeitanforderungen in multiagentengesteuerten Materialf lusssystemen . . . . . . . . . . . . . . . .

47

6

7

8

Die Bausteine des Internet der Dinge . . . . . . . . . . . . . . . . . . . . . . . . . . . Florian Kuzmany, Artur Luft und Razvan Chisu 8.1 Motivation und Anforderungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.2 Die Bausteine des Internet der Dinge . . . . . . . . . . . . . . . . . . . . . . . . 8.2.1 Transporteinheiten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.2.2 Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.2.3 Softwaredienste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.3 Standardisierung und Anpassbarkeit . . . . . . . . . . . . . . . . . . . . . . . . . 8.4 Fähigkeiten der Entitäten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.5 Funktionsklassen für Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.5.1 Verzweigung-/Zusammenführung . . . . . . . . . . . . . . . . . . . . . 8.5.2 Stetigförderer und Schienen . . . . . . . . . . . . . . . . . . . . . . . . . . 8.5.3 Unstetig förderer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.5.4 Arbeitsstation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.6 Beispiel: Gestaltung eines Verzweigungsmoduls . . . . . . . . . . . . . . . . 8.6.1 Aufbau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.6.2 Betriebsablauf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.7 Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

29

43 44 46 46

48 48 50 53 53 54 55 56 56 56 58 58 59 59 60 60 60 61 62 63

Inhaltsverzeichnis

9

10

11

12

ix

Kooperation und Autonomie in selbststeuernden Systemen . . . . . . . Moritz Roidl 9.1 Grundlagen von Agentensystemen . . . . . . . . . . . . . . . . . . . . . . . . 9.2 Agententypen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9.3 Relevante Eigenschaften von Agenten . . . . . . . . . . . . . . . . . . . . . 9.4 Die Umwelt von Agenten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9.5 Multiagentensysteme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9.6 Kooperation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9.7 Kommunikation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9.7.1 Blackboard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9.7.2 Message-Passing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9.7.3 Kommunikationsschichtenmodell . . . . . . . . . . . . . . . . . .

65

Eine Ontologie für das Internet der Dinge . . . . . . . . . . . . . . . . . . . . . Sergey Libert, Razvan Chisu und Konstantin Keutner 10.1 Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.2 Entwicklung einer Kommunikationsontologie . . . . . . . . . . . . . . . 10.2.1 Ontologiebeschreibung . . . . . . . . . . . . . . . . . . . . . . . . . . 10.2.2 Kommunikationsmodell . . . . . . . . . . . . . . . . . . . . . . . . . 10.3 Validierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.3.1 Akteure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.3.2 Kommunikationsszenario . . . . . . . . . . . . . . . . . . . . . . . . 10.4 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

79

Softwarearchitektur für eine agentenbasierte Materialflusssteuerung . . . . . . . . . . . . . . . . . . . . . . . Sergey Libert, Razvan Chisu und Artur Luft 11.1 Anforderungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Bisherige Architekturmodelle für die Materialflusssteuerung . . . 11.3 Agentenbasierte Materialflusssteuerung . . . . . . . . . . . . . . . . . . . 11.3.1 Referenzarchitekturen für Multiagentensysteme . . . . . . 11.3.2 Abstraktes Architekturmodell für das Internet der Dinge . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.3.3 Modellierung der Steuerungsagenten . . . . . . . . . . . . . . . 11.3.4 Echtzeitsteuerung von Modulagenten . . . . . . . . . . . . . . 11.4 Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Rechenplattformen und RFID für das Internet der Dinge . . . . . . . . Andreas Nettsträter und Florian Kuzmany 12.1 Übersicht über die Steuerungshardware . . . . . . . . . . . . . . . . . . . . 12.1.1 Anforderungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12.1.2 Architektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12.1.3 Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12.2 Einsatz von RFID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12.2.1 Frequenzbereiche . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

65 66 69 70 72 72 74 74 75 76

79 81 81 87 89 90 91 93

95 95 96 97 97 100 101 103 106 107 107 108 111 113 113 114

x

Inhaltsverzeichnis

12.2.2 12.2.3 13

14

15

Einsatz im Internet der Dinge . . . . . . . . . . . . . . . . . . . . . Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Strategien für die dezentrale agentenbasierte Steuerung von Materialf lusssystemen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Michael Hofmeister, Georg Baier und Manfred Gärtner 13.1 Einführung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13.2 Lokalisierung von Agenten in der Anlage . . . . . . . . . . . . . . . . . . 13.3 Der Zustandsraum für Agentensysteme . . . . . . . . . . . . . . . . . . . . 13.4 Topologiespezifische Ausprägung strategischer Aspekte am Beispiel zweier Anlagentypen . . . . . . . . . . . . . . . . . 13.4.1 Automatisches Kommissionierlager: Paarbildung, Sequenzbildung, Sortieren . . . . . . . . . . . . . 13.4.2 Flughafen-Gepäckförderanlage: Routing steht im Vordergrund . . . . . . . . . . . . . . . . . . . . . 13.5 Routingverfahren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13.5.1 Topologische Information . . . . . . . . . . . . . . . . . . . . . . . . 13.5.2 Dynamische schnellste Wege . . . . . . . . . . . . . . . . . . . . . 13.5.3 Lastabhängiges strategisches Routing . . . . . . . . . . . . . . 13.6 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Konfiguration und Überwachung einer verteilten Materialf lusssteuerung . . . . . . . . . . . . . . . . . . . . . . . . . . . . Razvan Chisu, Florian Kuzmany und Willibald A. Günthner 14.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14.2 Systemkonfiguration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14.3 Systemüberwachung und -visualisierung . . . . . . . . . . . . . . . . . . . 14.3.1 Allgemeingültigkeit durch regelbasierte Visualisierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14.3.2 Nachverfolgbarkeit und Historien . . . . . . . . . . . . . . . . . 14.3.3 Statistiken . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14.4 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

116 118

119 119 120 121 124 124 129 130 130 132 134 139

141 141 141 144 144 146 147 148

Simulation und Emulation im Internet der Dinge . . . . . . . . . . . . . . . Damian Daniluk und Razvan Chisu 15.1 Simulation – Begriff und Anwendung . . . . . . . . . . . . . . . . . . . . . 15.1.1 Durchführung einer Simulationsstudie . . . . . . . . . . . . . . 15.1.2 Vor- und Nachteile der Simulation . . . . . . . . . . . . . . . . . 15.2 Emulation – Begriff und Anwendung . . . . . . . . . . . . . . . . . . . . . 15.3 Werkzeuge zur Materialf lusssimulation . . . . . . . . . . . . . . . . . . . 15.4 Simulation im Internet der Dinge . . . . . . . . . . . . . . . . . . . . . . . . . 15.5 Emulation im Internet der Dinge . . . . . . . . . . . . . . . . . . . . . . . . . 15.5.1 Einsatz eines gängigen Materialflusssimulators . . . . . . . 15.5.2 Agentenbasierter Emulationsbaukasten . . . . . . . . . . . . . 15.5.3 Emulation in den Lebenszyklusphasen . . . . . . . . . . . . . .

149

Literatur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

167

149 151 153 154 156 158 160 160 161 162

Inhaltsverzeichnis

Teil III 16

17

18

19

Der neue Logistik-Lebenszyklus . . . . . . . . . . . . . . . . . . . . . . . . .

Der Lebenszyklus heutiger Materialf lusssysteme – eine Übersicht . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Carolin Haußner, Jürgen Elger und Florian Kuzmany 16.1 Lebenszyklus eines Materialflusssystems . . . . . . . . . . . . . . . . . . 16.1.1 Planungsphase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16.1.2 Realisierungsphase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16.1.3 Inbetriebnahme/Hochlaufphase . . . . . . . . . . . . . . . . . . . 16.1.4 Betrieb . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16.1.5 Erweiterung/Modernisierung . . . . . . . . . . . . . . . . . . . . . 16.2 Dezentrale Automatisierungssysteme – eine Herleitung . . . . . . . 16.3 Referenzmodell-Methode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16.4 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Die Erstellung eines Baukastens für das Internet der Dinge . . . . . . Clemens Nieke und Martin Henk 17.1 Baukasten für Entitäten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17.2 Basisinformationen einer Entität . . . . . . . . . . . . . . . . . . . . . . . . . 17.3 Additive Komponenten eines Baukastens . . . . . . . . . . . . . . . . . . 17.4 Aggregationen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17.5 Anpassung der Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Der Lebenszyklus eines Internet der Dinge Materialf lusssystems: Planung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Clemens Nieke und Martin Henk 18.1 Qualif izierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18.2 Spezif izieren bei vorgegebener Lösung . . . . . . . . . . . . . . . . . . . . 18.3 Spezif izieren bei nicht vorgegebener Lösung . . . . . . . . . . . . . . . 18.4 Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18.5 Interne Kalkulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18.6 Koordinierung der Zulieferer . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18.7 Projektierung der Steuerungstechnik . . . . . . . . . . . . . . . . . . . . . . 18.8 Projektierung der IT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18.9 Terminplanung des Projekts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Der Lebenszyklus eines Internet der Dinge Materialf lusssystems: Realisierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Clemens Nieke und Martin Henk 19.1 Detailstudie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19.2 Feinplanung und Pf lichtenheft . . . . . . . . . . . . . . . . . . . . . . . . . . . 19.3 Konf iguration/Customizing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19.4 Programmierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19.4.1 Neue mechatronische Entität bzw. neues Modul . . . . . . 19.4.2 Softwaretechnischer Dienst . . . . . . . . . . . . . . . . . . . . . . 19.4.3 Visualisierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19.4.4 Sicherheitskreise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

xi

171

173 174 174 175 177 179 179 180 183 186 187 188 191 191 194 194

197 197 198 199 201 202 203 203 204 204

207 207 208 210 211 212 212 213 213

xii

Inhaltsverzeichnis

19.5 Herstellung einer mechatronischen Entität bzw. eines Moduls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19.6 Inhouse-Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19.7 Dokumentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19.8 Montage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

21

22

Der Lebenszyklus eines Internet der Dinge Materialf lusssystems: Inbetriebnahme und Hochlauf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Andreas Trautmann und Alfred Lanfer 20.1 Referenzanlage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20.2 Phasen der konventionellen Inbetriebnahme . . . . . . . . . . . . . . . . 20.3 Inkrementelle Inbetriebsetzung im Internet der Dinge . . . . . . . . 20.4 Technische Voraussetzungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20.4.1 Standardisierte Laufzeitumgebung und Infrastruktur . . . 20.4.2 Wiederverwendbare Komponenten . . . . . . . . . . . . . . . . . 20.4.3 Diagnosemöglichkeiten und Monitoring . . . . . . . . . . . . 20.4.4 Testen und Emulation . . . . . . . . . . . . . . . . . . . . . . . . . . . 20.5 Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Der Lebenszyklus eines Internet der Dinge Materialf lusssystems: Betrieb . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Jan R. Nopper 21.1 Überblick über Vorteile selbstorganisierter Materialf lusssysteme im Lebenszyklus . . . . . . . . . . . . . . . . . . . . 21.2 Logistische Leistungsfähigkeit . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.3 Quantifizierung und Bewertung der F lexibilität von Materialf lusssystemen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.4 Robustheit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.5 Datenverfügbarkeit und zusätzliche Dienstleistungen . . . . . . . . . 21.6 Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Der Lebenszyklus eines Internet der Dinge Materialflusssystems: Umbau und Modernisierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Alfred Lanfer und Andreas Trautmann 22.1 Erwartete Vorteile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22.2 Anforderungen an den Umbau . . . . . . . . . . . . . . . . . . . . . . . . . . . 22.3 Voraussetzungen und Checkliste zur Vorbereitung . . . . . . . . . . . 22.3.1 Ist-Aufnahme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22.3.2 Soll-Anforderungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22.3.3 Prozessführung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22.3.4 Layout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22.3.5 Sicherheitsanforderungen . . . . . . . . . . . . . . . . . . . . . . . . 22.4 Agentifizierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22.4.1 Umbau einer Referenzanlage . . . . . . . . . . . . . . . . . . . . . 22.5 Technische Umsetzung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22.6 Erfahrungsbericht . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

214 215 215 216

217 217 219 220 221 222 223 223 225 226

229

229 230 231 233 234 235

237 237 238 238 238 239 240 240 241 241 241 243 246

Inhaltsverzeichnis

22.7 22.8 23

Begleitende Dokumentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Zusammenfassung und Fazit: Das Internet der Dinge als neues Vorgehensmodell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Carolin Haußner, Jürgen Elger und Andreas Trautmann 23.1 Grundlagen und technische Aspekte . . . . . . . . . . . . . . . . . . . . . . 23.2 Engineering und Betrieb . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23.3 Der Faktor Mensch und Qualifikation – Gewerkeübergreifendes Arbeiten und vertikale Kompetenzen . . . 23.4 Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

xiii

246 247

249 249 251 254 255

Literatur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

257

Teil IV

261

24

25

Die Anwendung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Realisierung einer agentenbasierten Steuerung für Elektrohängebahnsysteme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Razvan Chisu, Florian Kuzmany und Willibald A. Günthner 24.1 Definition und Einsatz von Elektronhängebahnanlagen . . . . . . . 24.2 Versuchsanlage des Lehrstuhls fml an der TU München . . . . . . . 24.3 Aufgaben- und Szenarienbeschreibung . . . . . . . . . . . . . . . . . . . . 24.4 Modularisierung und Steuerungsarchitektur . . . . . . . . . . . . . . . . 24.5 Funktionsweise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24.6 Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Chancen und Herausforderungen von dezentral gesteuerten Flughafen-Gepäckförderanlagen . . . . . . . . . . . . . . . . . . Jürgen Elger, Carolin Haußner, Michael Hofmeister und Georg Baier 25.1 Allgemeines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25.2 Aufgaben und Funktionsbereiche von Gepäckförderanlagen . . . 25.3 Typische/Domänenspezifische Anforderungen für Gepäckförderanlagen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25.4 Identifikationskonzepte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25.5 Dezentrale Gepäckförderanlage . . . . . . . . . . . . . . . . . . . . . . . . . . 25.5.1 Vorabentwicklung mechatronischer Module . . . . . . . . . 25.5.2 Engineering dezentraler Anlagen . . . . . . . . . . . . . . . . . . 25.5.3 Umbauten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25.5.4 Gepäcktransport in dezentralen Systemen . . . . . . . . . . . 25.6 Konzepte zur Betriebsführung . . . . . . . . . . . . . . . . . . . . . . . . . . . 25.6.1 Simulation als Werkzeug . . . . . . . . . . . . . . . . . . . . . . . . 25.6.2 Strategisches Routingverfahren . . . . . . . . . . . . . . . . . . . 25.6.3 Eigensimulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25.6.4 Ergebnis und Herausforderungen . . . . . . . . . . . . . . . . . . 25.7 Migrationskonzept . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25.8 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

263 263 263 265 266 269 274

275 275 276 278 279 280 280 282 283 283 285 286 288 288 290 291 293

xiv

26

Inhaltsverzeichnis

Ein dezentral gesteuertes Kommissionierlager . . . . . . . . . . . . . . . . . Dirk Gehlich, Artur Luft und Sergey Libert 26.1 Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26.2 Moderne Kommissionierlager . . . . . . . . . . . . . . . . . . . . . . . . . . . 26.3 Referenzanlage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26.4 Konzeptionelle Lösungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26.4.1 RFID-Einsatz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26.4.2 Konzept einer agentenbasierten Steuerung . . . . . . . . . . . 26.5 Integration der Steuerung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26.6 Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

295

27 Agentenbasierte Staplerleitsysteme . . . . . . . . . . . . . . . . . . . . . . . . . . . Stanislav Göhring und Thomas Lorenz 27.1 Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27.2 Definition und Einsatz von Staplerleitsystemen . . . . . . . . . . . . . 27.3 Agentenbasierte Staplerleitsysteme . . . . . . . . . . . . . . . . . . . . . . . 27.4 Moderne Software-Architektur . . . . . . . . . . . . . . . . . . . . . . . . . . 27.5 Operative Funktionen eines aSLS . . . . . . . . . . . . . . . . . . . . . . . . 27.6 Exkurs: Zusammenführung mit IdentProLog . . . . . . . . . . . . . . . 27.7 Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

313

28

Hochf lexible, RFID-gesteuerte Handhabung von Stückgut . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Walter Schaaf und Razvan Chisu 28.1 Anlagenkomponenten und Teilsysteme . . . . . . . . . . . . . . . . . . . 28.2 Anforderungen an die Greiftechnik für das Internet der Dinge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28.3 Systemkonzept der Greiftechnik für RFID-basierten Materialfluss . . . . . . . . . . . . . . . . . . . . . . . . . . . 28.4 Kombination von Greifprinzipien . . . . . . . . . . . . . . . . . . . . . . . 28.5 Konzeption eines Greifers für das Szenario Depalettierroboter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28.6 Realisierte Anlage für das Szenario Depalettierroboter . . . . . . . 28.7 Greifer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28.8 RFID-System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28.9 Erprobung des Szenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28.10 Folgerungen und Erkenntnisse . . . . . . . . . . . . . . . . . . . . . . . . . .

295 296 297 301 301 302 309 310

313 315 316 317 320 325 327

329 329 330 331 332 333 333 336 338 341 343

Literatur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

345

Teil V

Internet der Dinge - Eine Vision wird Wirklichkeit . . . . . . . . . . .

347

Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Willibald A. Günthner

349

Sachverzeichnis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

353

29

Autorenverzeichnis

Georg Baier Siemens AG, Siemens CT PP, Otto-Hahn-Ring 6, 81739 München, Deutschland, [email protected] Razvan Chisu Technische Universität München, Lehrstuhl für Fördertechnik Materialfluss Logistik fml, Boltzmannstr. 15, 85748 Garching, Deutschland, [email protected] Damian Daniluk Fraunhofer-Institut für Materialfluss und Logistik IML, Josephvon-Fraunhofer Straße 2-4, 44227 Dortmund, Deutschland, damian.daniluk@ iml.fraunhofer.de Jürgen Elger Siemens AG, Corporate Technology CT SE 5, Günther-ScharowskyStr. 1, 91058 Erlangen, Deutschland, [email protected] Sascha Feldhorst Technische Universität Dortmund, Lehrstuhl für Förder- und Lagerwesen, Emil-Figge-Str. 73, 44221 Dortmund, Deutschland, sascha. [email protected] Manfred Gärtner viastore systems GmbH, Leiter Materialflusssteuerung, Magirusstraße 13, 70469 Stuttgart, Deutschland, [email protected] Dirk Gehlich viastore systems GmbH, Softwareingenieur Materialflusssysteme, Magirusstraße 13, 70469 Stuttgart, Deutschland, [email protected] Stanislav Göhring PSI Logistics GmbH, Softwareengineering, Am Stadtrand 56, 22047 Hamburg, Deutschland, [email protected] Willibald Günthner Technische Universität München, Lehrstuhl für Fördertechnik Materialfluss Logistik fml, Boltzmannstr. 15, 85748 Garching, Deutschland, [email protected] Christoph Hahn-Woernle viastore systems GmbH, Geschäftsführer Gesellschafter, Magirusstraße 13, 70469 Stuttgart, Deutschland, [email protected] Carolin Haußner Siemens AG, Corporate Technology CT SE 5, Günther-Scharowsky-Str. 1, 91058 Erlangen, Deutschland, [email protected] Martin Henk Stöcklin Logistik GmbH, Untere Industriestraße 20, 57250 Netphen, Deutschland, [email protected] xv

xvi

Autorenverzeichnis

Michael Hofmeister Siemens AG, Corporate Technology, Otto-Hahn-Ring 6, 81739 München, Deutschland, [email protected] Konstantin Keutner Siemens AG, Corporate Technology Software & Engineering, CT SE 2, Otto-Hahn-Ring 6, 81730 München, Deutschland, konstantin. [email protected] Winfried Kugler viastore systems GmbH, Ressortleiter Operations, Magirusstraße 13, 70469 Stuttgart, Deutschland, [email protected] Florian Kuzmany Technische Universität München, Lehrstuhl für Fördertechnik Materialfluss Logistik, Boltzmannstr. 15, 85748 Garching, Deutschland, [email protected] Alfred Lanfer Lanfer, Geschäftsführer, Hoher Weg 13, 46325 Borken, Deutschland, [email protected] Sergey Libert Technische Universität Dortmund, Lehrstuhl für Förder- und Lagerwesen, Emil-Figge-Str. 73, 44221 Dortmund, Deutschland, sergey.libert@flw. mb.tu-dortmund.de Thomas Lorenz PSI Logistics GmbH, Am Stadtrand 56, 22047 Hamburg, Deutschland, [email protected] Artur Luft viastore systems GmbH, Magirusstraße 13, 70469 Stuttgart, Deutschland, [email protected] Andreas Nettsträter Fraunhofer-Institut für Materialfluss und Logistik IML, Joseph-von-Fraunhofer Straße 2-4, 44227 Dortmund, Deutschland, andreas. [email protected] Clemens Nieke Stöcklin Logistik GmbH, Untere Industriestrasse 20, 57250 Netphen, Deutschland, [email protected] Jan R. Nopper Fraunhofer-Institut für Materialfluss und Logistik IML, Abt. Maschinen und Anlagen, Joseph-von-Fraunhofer Straße 2-4, 44227 Dortmund, Deutschland, [email protected] Moritz Roidl Technische Universität Dortmund, Lehrstuhl für Förder- und Lagerwesen, Emil-Figge-Str. 73, 44221 Dortmund, Deutschland, moritz.roidl@flw. mb.tu-dortmund.de Walter Schaaf J. Schmalz GmbH, Leiter Vorentwicklung und Produktentwicklung Vakuum-Komponenten, Aacher Strasse 29, 72293 Glatten, Deutschland, walter. [email protected] Michael ten Hompel Technische Universität Dortmund, Lehrstuhl für Förderund Lagerwesen, Emil-Figge-Str. 73, 44221 Dortmund, Deutschland, michael. [email protected] Andreas Trautmann LinogistiX GmbH, Geschäftsführer, Mallinckrodtstr. 320, 44147 Dortmund, Deutschland, [email protected]

Teil I

Herausforderungen in der Intralogistik

Kapitel 1

Individualisierung als logistisch-technisches Prinzip Michael ten Hompel

Die Individualisierung als postmodernes Lebensprinzip hat mit dem Aufkommen der Internetgesellschaft eine neue Dimension erreicht. Individuelle Lebensentwürfe sind heute ebenso selbstverständlich wie die individuelle Gestaltung der Lebensräume und Produkte oder die zeitlich und räumlich individuelle Versorgung mit Waren und Informationen. Ubiquitäres Computing sorgt für permanente Erreichbarkeit, und virtuelle Habitate überlagern zunehmend die reale Welt. Die Individualisierung als gesellschaftliche Entwicklung setzt sich in bemerkenswerter Stringenz im technologischen (logistischen) Bereich fort. Das Prinzip der Individualisierung erscheint nachgerade als notwendiges und evidentes Grundprinzip der aktuellen technologischen Entwicklung in der Logistik im Allgemeinen und in der logistischen Dienstleistung im Besonderen. Der Grund hierfür ist sicherlich in den stringenten zeitlichen Vorgaben (24 h-Lieferung) einerseits und in der in zunehmendem Maße individuellen Behandlung der Güter und Waren andererseits zu sehen. Dies in Verbindung mit der zum Allgemeinplatz gewordenen „Atomisierung der Warensendungen“ führte zu dem immer lauteren Ruf nach mehr Flexibilität und Adaptivität logistischer Systeme. Der zwangsläufig folgende Versuch, die klassischen Supply Chain Management Systeme „zu flexibilisieren“ basiert allerdings weiterhin auf einer planbaren Zukunft hierarchisch organisierter Prozessketten. Diese Variante des Supply Chain Management geht jedoch – zumindest für die logistische Dienstleistung – offensichtlich allmählich ihrem Ende entgegen. Nun gilt es, Individualisierung nicht nur als Herausforderung, sondern als Methode zu begreifen, die alle Bereiche logistischer (Dienst-) Leistung durchdringt.

M. ten Hompel () Lehrstuhl für Förder-und Lagerwesen, Technische Universität Dortmund Emil-Figge-Str. 73, 44221 Dortmund, Deutschland e-mail: [email protected] W. Günthner, M. ten Hompel (Hrsg.), Internet der Dinge in der Intralogistik, DOI 10.1007/978-3-642-04896-8_1, © Springer-Verlag Berlin Heidelberg 2010





M. ten Hompel

1.1 Individualisierung als Gestaltungsprinzip Die Individualisierung als größte Herausforderung und zugleich gemeinsamer Nenner zukünftiger Logistiksysteme wird von vielen Seiten belegt. „An die Logistik der Zukunft stellt sich die Kundenanforderung nach individualisierten logistischen Services und einer zukünftigen Berücksichtigung von kundenspezifischen Designwünschen“, postuliert unlängst Prof. Frank Straube (Straube 2008) und zeigt damit zugleich auf, dass sich die zukünftige Entwicklung nicht nur um die individuelle Gestaltung logistischer Dienstleistung, sondern gleichwohl um das individuelle Design und die damit verbundene Gestaltung und Organisation logistischer Systeme allgemein dreht. Prof. Willibald Günthner beschreibt die Situation in ähnlicher Weise und kommt zu dem Schluss: „Daher wird es zukünftig nötig sein, mit Hilfe einer leistungsfähigen Logistik eine Vielzahl von Nischenprodukten effizient zu fertigen und zu verteilen. Bewährte Logistikkonzepte werden sich fortan nicht mehr in der Breite anwenden lassen; individualisierte Produkte erfordern vielmehr auch eine maßgeschneiderte Logistik. […] Schwerfällige, zentral gesteuerte Produktionen werden dieser Anforderung jedoch nicht gerecht“ (Günthner et al. 2008). Günthner leitet aus der Individualisierung auch die Notwendigkeit ab, zukünftige Logistiksysteme ereignisgesteuert zu betreiben und damit die klassischen Paradigmen konventionellen Supply Chain Managements weiter zu entwickeln. Wie unvermeidlich dieser Schritt ist, erweist sich bei der Betrachtung der aktuellen Situation des Supply Chain Managements und der informationstechnischen Organisation der Logistik.

1.2 Paradoxien der Informationslogistik Die Organisation und Optimierung logistischer Systeme ist zumeist ein multikriterielles Problem. Häufig gilt es, widerstrebende Ziele wie Wirtschaftlichkeit versus Flexibilität in einem gemeinsamen Lösungsraum zu vereinen. Dies führt in den meisten Fällen zu applikationsspezifischen Heuristiken, deren Koeffizienten im täglichen Betrieb angepasst und deren Wirkungen häufig durch Simulation ermittelt und iterativ verbessert werden. Hierin manifestiert sich ein grundlegendes Dilemma des aktuellen Supply Chain Managements: Einerseits erscheint es notwendig, immer größere Datenmengen, komplexere Modelle und aufwendige, detailreiche Prozessketten zu entwickeln und zu standardisieren, um eine vorgedachte Realität abbilden zu können. Andererseits konterkariert dies die angestrebte Flexibilisierung und Individualisierung logistischer Prozesse. Dieses Dilemma ist täglich gelebte Praxis für alle, die vor der Aufgabe stehen, ihre Logistik auf die Bedarfe der kommenden Stunden und Tage einzustellen. Dieses Dilemma aufzulösen – Individualität zu ermöglichen und zugleich die logistische Effizienz zu verbessern – ist die zentrale Frage und Herausforderung. Dass dies

1  Individualisierung als logistisch-technisches Prinzip



nicht mit den klassischen Methoden des Supply Chain Managements erreichbar ist, zeigen die folgenden, nachgerade klassischen Paradoxien der Informationslogistik. Die Menge logistischer Informationen wächst schneller als die Leistung der Computer Die Datenmenge intralogistischer Systeme ist in den letzten zehn Jahren etwa um den Faktor 1.000 gestiegen. Zur gleichen Zeit stieg die Rechnerleistung etwa um den Faktor 50. Dies führt nicht selten dazu, dass die sogenannte „Berechnungsgrenze“ erreicht wird und die Berechnung (unter Nutzung aller zur Verfügung stehenden Informationen) noch nicht abgeschlossen ist, wenn das Ereignis, das vorausberechnet werden soll, bereits eintritt. Die Paradoxie der informationslogistischen Entscheidung Der Wunsch nach Vorbestimmtheit führt dazu, dass immer mehr Daten gesammelt und in Beziehung gesetzt werden, um eine Entscheidung zu treffen oder einen Prozess zu optimieren. Jede zu Grunde gelegte Information ist jedoch mit einer Fehlerwahrscheinlichkeit verbunden und die Schwelle der Informationsmenge ist längst überschritten, für die gilt: Je mehr (vergangenheitsbezogene) Informationen zur Vorhersage eines Ereignisses in Beziehung gesetzt werden, umso unwahrscheinlicher wird das Eintreffen einer Vorhersage in vorbestimmter Zeit. Die Explosion des Entscheidungsraums Je mehr Informationen einer Entscheidung zugrunde gelegt werden, umso weiter entfernt sich die Entscheidungsinstanz vom Ort des Geschehens. Diese Empirie beruht wiederum auf der stetig steigenden Informationsmenge, deren Aggregationsebene sich immer weiter vom Ort der Entscheidung entfernt. Die zum Teil fatale Wirkung entsteht insbesondere im Echtzeitbereich: Auch einfachste Entscheidungen, zum Beispiel ob ein Behälter an der nächsten Verzweigung ausgeschleust werden soll, erzeugen immer komplexere Abfragen in immer größerer Datenbanken über mehrere Ebenen einer Steuerungshierarchie hinweg. Die Atomisierung der Standardprozesse Immer individuellere logistische Prozesse bedingen immer spezifischere Prozessketten. Um diese in klassischen Supply Chain Management Systemen abbilden zu können, müssen jedoch gemeinsame Standards bzw. standardisierte Prozesse und Prozesskettenelemente definiert werden. Die Abbildungsqualität immer individuellerer logistischer Prozesse führt zu immer detaillierteren und zugleich zahlreicheren, standardisierten Prozesskettenelementen, deren Anzahl mit der Granularität der Systeme überproportional zunimmt. Dies führt dazu, dass eher ein neuer „Standardprozess“ definiert als gefunden wird. Zugleich nimmt die Anzahl der informationstechnischen Schnittstellen überproportional zu. Die „Unschärferelation“ der Logistik Je genauer ein logistischer Prozess in der Zukunft bestimmt wird, umso unwahrscheinlicher wird sein Eintreffen in vorbestimmter Zeit. Diese Erkenntnis erscheint zunächst paradox, aber die Logistik ist noch nicht einmal so vorhersagbar wie das



M. ten Hompel

Wetter von morgen (das nicht selten die logistischen Abläufe wesentlich bestimmt). Zugleich wird damit der untaugliche Versuch beschrieben, die Zukunft vorhersagen zu können, wenn man sie denn nur genau genug plane.

1.3 Individualisierung als Ziel und als Ausweg Das Ziel ist es, einen Weg aus den hiermit verbundenen Dilemmata zu weisen. Die vielfältigen Methoden hierzu beruhen alle auf den Grundprinzipen logistischer Individualisierung. Speicherung individueller Information am (einzelnen) Gut oder Ladehilfsmittel Mit Hilfe von AutoID-Systemen werden Güter nicht nur identifiziert, sondern es werden Informationen am Gut gespeichert, die zu deren individueller, echtzeitnaher Steuerung vor Ort benötigt werden. Damit werden Material- und Informationsfluss vereint und die Schnittstellen individueller Services werden überbrückt. Nicht zuletzt findet das „Internet der Dinge“, wie es in diesem Buch beschrieben wird, hierin seine logische Fortsetzung. Individuelle Entscheidungsfindung auf Basis lokaler Information Um Individualität der logistischen (Steuerungs-) Entscheidung zu ermöglichen, ist es wichtiger, eine vernünftige Entscheidung in begrenzter Zeit zu treffen als eine vermeintlich „optimale“ zu spät. Die zukünftigen Technologien der innerbetrieblichen Materialflusssysteme basieren auf dieser Erkenntnis und nutzen adäquate Technologien wie z. B. Multiagentensysteme. Individuelle Services ersetzen starre Prozessketten und ermöglichen Standardisierung Serviceorientierte Architekturen (SOA) sind ein geeignetes Mittel zur individuellen Gestaltung und Organisation (Orchestrierung) zukünftiger logistischer IT-Systeme. Die „Serviceorientierung“ ist gleichzeitig mit einer neuen Form der Modellierung logistischer Systeme verbunden, innerhalb derer standardisierte physische wie logische Services definiert und „on Demand“ abgerufen werden. Nicht deterministische Systeme ermöglichen Individualität Die Welt, allemal die logistische, ist nicht deterministisch. Mit dieser simplen Erkenntnis verbunden ist das Anerkenntnis einer auf Wahrscheinlichkeiten beruhenden Steuerung der Logistik. Insbesondere für den Echtzeitbereich und damit für die physische Steuerung logistischer Systeme ist dies verbunden mit einem Wechsel weg von der taktgesteuerten, deterministischen, vorgedachten Supply Chain hin zu einer ereignisgesteuerten, stochastischen Steuerung zukünftiger Logistik. Die Notwendigkeit zur Modellierung Individualisierung führt am Ende auch zu der Notwendigkeit, unsere Welt in anderer Weise zu modellieren, zumal der Versuch einer ganzheitlichen und zugleich in-

1  Individualisierung als logistisch-technisches Prinzip



dividuellen Modellierung des Bewegungsraums, also der operativen (Bewegungs-) Ebene und der normativen Auftragsebene klassischer ERP-Systeme, zum Scheitern verurteilt ist. Zu unterschiedlich sind die Zielsetzungen: • Exakte Abbildung von Layout und Topologie auf der Bewegungsebene einerseits, • Produktivitätsmaximierung und Minimierung von Auftragsdurchlaufzeiten auf der normativen Ebene andererseits. Die Trennung von operativem und normativem Entscheidungsraum und der resultierende Paradigmenwechsel in der Optimierung und Individualisierung werden einen erheblichen Teil der logistischen Welt verändern. Mit den genannten Paradigmen und der Trennung von normativer und operativer Ebene bei der Modellierung logistischer Systeme folgend, ergeben sich die zwei Säulen eines zukünftigen, gemeinsamen Logistik-, Produktions- und IT-Designs. Das Internet der Dienste Die normative Auftragssteuerung erfolgt auf Basis serviceorientierter Architekturen. Der Abruf von Services bei Bedarf („on Demand“) ermöglicht Flexibilität und Dynamik jenseits starrer Prozessketten. Dieses neue Verständnis der zwei Seiten einer neuen Logistik 2.0 als autonom interagierenden (operative und normative) Ebenen ist vorgezeichnet. Unabhängig davon, ob man von Diensten, Prozessen oder Services spricht, wird die individuelle Gestaltung unserer Welt nur möglich sein, wenn der Versuch aufgegeben wird, die Welt in ein einheitliches (Prozess-) Schema zu zwängen. Das Internet der Dinge Im Internet der Dinge wird der Bewegungsraum auf Basis autonom interagierender Objekte gesteuert. Alle relevanten Informationen werden damit lokal gespeichert und Entscheidungen werden vor Ort gefällt. Die Menge an Informationen, die einer Entscheidung zu Grunde gelegt wird, ist auf das Notwendigste reduziert. Lokale Information und Informationsaustausch entlang der Kette der logistischen Entitäten führen zu leistungsfähigem Verhalten unter Echtzeitanforderungen. Hierdurch wird es möglich, die Echtzeitebene im Sinne eines Internet der Dinge von der überlagerten, normativen Ebene zu entkoppeln. Dies erlaubt schließlich auch die geeignete und separate Modellierung von operativer und normativer Ebene. In diesem Buch wird das „Internet der Dinge“ als praxisnahes Konzept entwickelt. Gewürdigt werden nicht nur die technischen Aspekte, sondern auch das zukünftige Lifecycle-Management ganzer Systeme von der Entwicklung bis hin zum Betrieb. Es handelt sich also um weit mehr als die Einführung einer neuen Technologie – es ist auch ein neues Managementkonzept.

Kapitel 2

Neue Anforderungen für die Logistik   des 21. Jahrhunderts Christoph Hahn-Woernle

2.1  Globalisierung verändert Ansprüche Wichtige Aspekte der Globalisierung sind die ökonomischen Prinzipien von „global sourcing“, „global production“ und „global selling“. Diese verursachen eine ständige Zunahme der internationalen Arbeitsteilung und lassen das Welthandelsvolumen deutlich stärker ansteigen als die weltweite Produktion. Die geografische Entkoppelung von Rohstofferzeugung, Herstellung, Anbietern und Abnehmern verursacht ein wachsendes Transportaufkommen. Die Aufgabenstellung der Intralogistik ist deshalb, diese Kette so zu gestalten, dass die Anzahl und das Volumen der Transporte möglichst abnehmen. Das ermöglicht eine höhere Variabilität, an welcher Stelle zwischen Rohstofferzeugung und Verbraucher welche Arbeitsschritte angesiedelt sind. Der Großteil des internationalen Handels findet heute zwischen den Wirtschaftszentren Nordamerikas, Europas und Südostasiens statt. In den vergangenen drei Jahrzehnten hat sich der Anteil des weltweiten Warenexports gemessen am globalen Bruttosozialprodukt von zehn auf über 25% erhöht. Seit etwa 20 Jahren lässt sich der Trend beobachten, dass die grenzüberschreitend gehandelten Dienstleistungen noch schneller anwachsen als die internationalen Warenströme. Die enormen Globalisierungsschritte der vergangenen 30 Jahre haben verschiedene Ursachen. Als in den 1980er-Jahren das Konzept der schlanken Fertigung immer mehr an Bedeutung gewann, förderte das auch das Outsourcing und damit die Suche nach immer günstigeren Produktionsmöglichkeiten. Das erforderte leistungsfähige Lieferströme und Umschlagplätze. Seit Mitte der 1990er Jahren verbindet das World Wide Web als der leistungsstarke Informations- und Kommunikationsträger an fast allen Regulierungen vorbei fast alle Menschen und Märkte miteinander. Es vereinfacht den internationalen Handel, indem sämtliche Informationen, die für die Warenströme erforderlich sind, einfach und für alle transparent abgebildet werden können. Doch dieser schnelle und unkomplizierte weltweite InformationsC. Hahn-Woernle () Geschäftsführender Gesellschafter, viastore systems GmbH Magirusstraße 13, 70469 Stuttgart, Deutschland e-mail: [email protected] W. Günthner, M. ten Hompel (Hrsg.), Internet der Dinge in der Intralogistik, DOI 10.1007/978-3-642-04896-8_2, © Springer-Verlag Berlin Heidelberg 2010



10

C. Hahn-Woernle

austausch steigert die Erwartungshaltung der Nutzer. Businesskunden und Endverbraucher erwarten gleichermaßen, dass die per Mausklick bestellte Ware verfügbar ist und just in time, oft sogar über Nacht, geliefert wird – ganz gleich, von woher. Durch die hohe Informationstransparenz werden zudem die Kosten vergleichbarer, was den Wettbewerbsdruck erhöht. Als Folge steigen die Kundenanforderungen, gleichzeitig nimmt die Kundenloyalität aufgrund der hohen Informationsverfügbarkeit ab. Oder anders ausgedrückt: Wer die Ware – zum besseren Preis – verfügbar hat, macht das Geschäft.

2.2  Herausforderungen für die Logistik Das alles hat weltweit enorme Auswirkungen auf die Erzeugung, die Warenhaltung und die Warenverteilung. Die Kunden ordern nicht mehr per Sammelbestellung, sondern genau im Bedarfsfall. Das reduziert zum einen die Menge pro Lieferung, erhöht zum anderen jedoch die Anzahl der Lieferungen deutlich. Was bislang ein Spediteur auf einer Palette gebracht hat, liefern nun verschiedene KEP-Dienstleister in mehreren Paketen und Päckchen. Was bislang aus dem Zentrallager eines Herstellers oder Großhändlers kam, stammt nun aus diversen Lägern und Produktionen von vielen verschiedenen Erzeugern, Handelspartnern und Distributoren aus ganz unterschiedlichen Teilen der Welt – auch dann, wenn die Bestellung mehrerer verschiedener Artikel über ein einziges Portal erfolgt ist. Dadurch nimmt die Anzahl der weltweiten Land-, See- und Lufttransporte deutlich zu. Die Globalisierung führt somit zu einem starken Anstieg des Güterumschlags an logistischen Knotenpunkten mit internationaler Bedeutung und damit zu infrastrukturellen Maßnahmen an Flugund Seehäfen, um durch moderne Materialflusstechnik und Software Durchlaufzeiten zu verkürzen und die Transparenz zu erhöhen. Zentraler Umschlagshub für Europa ist dabei aufgrund der geografischen Lage Deutschland. Damit nimmt auch das Aufkommen auf den verschiedenen Verkehrswegen zu. In welchem Maß, hat der damalige Staatssekretär im Bundesverkehrsministerium anlässlich der Eröffnungsfeier zur CeMAT 2008 in einer Zukunftsstudie zur Verkehrsentwicklung in Deutschland vorgestellt. Diese Studie kommt zu dem Ergebnis, dass das Güterverkehrsaufkommen bis zum Jahr 2025 um knapp die Hälfte gegenüber heute steigen wird – von gut 3,7 Mrd. t auf dann fast 5,5 Mrd. t. Die Güterverkehrsleistung wird sich sogar mehr als verdoppeln, von heute etwas weniger als 600 Mrd. tkm auf dann mehr als 1.200 Mrd. tkm. Die angebotene Lösung waren nicht die Reduzierung des Transportaufkommens, sondern Verkehrsleitsysteme.

2.3  Intralogistik kann Logistikprobleme lösen Die Intralogistik hat wesentlich dazu beigetragen, dass die Globalisierung im heutigen Ausmaß möglich wurde. Die Intralogistik hat auch jetzt Antworten auf die Herausforderung der Güterverkehrsentwicklung. Denn bei vielen Lkw und Bahn-

2  Neue Anforderungen für die Logistik des 21. Jahrhunderts

11

waggons beispielsweise sind weniger als 10% des Ladevolumens genutzt. Häufig können nicht zwei Paletten übereinander gestapelt werden. Hinzu kommt, dass die Um- oder Versandverpackungen der Produkte viel größer als erforderlich sind. Diese Erfahrung musste jeder schon einmal machen, der sich eine PC-Tastatur, Tiernahrung oder andere Produkte über den Versandhandel bestellt hat. Oft werden gerade mal 10% des Versandkartons durch die Produktverpackung ausgefüllt – der Rest ist Polstermaterial, also aufwendig produzierter Müll. Mit der eigentlichen Produktverpackung verhält es sich kaum anders. Ziel muss sein, Verpackung und verpackte Luft auf ein Minimum zu reduzieren. Hier muss die Politik Druck auf alle machen. Für die Unternehmen muss es sich lohnen, die Luft rauszulassen. Die Intralogistik kann dazu Maßgebliches beitragen. Sie kann beispielsweise durch eine Kennzahlenanalyse ermitteln, wie viel Luft alleine schon mit der Umverpackung verschickt wird. Die einzige Voraussetzung dafür sind gepflegte Stammdaten. Mit einem geeigneten WMS kann die Größe eines Umkartons genau vorausberechnet werden. Ein Kartonaufrichter oder eine Spezialmaschine, die den Umkarton auf Maß fertigt – oder noch besser: eine Originalverpackung, die gleich als Versandverpackung genutzt werden kann –, würden den Neubau von Tausenden Autobahnkilometern sparen, den CO2-Ausstoß senken, den Müllberg reduzieren.

2.4  Innovationspotenziale der Intralogistik Logistik und Intralogistik werden durch eine ganze Reihe an Einflüssen geprägt. Der eine Einflussbereich sind übergeordnete, globale Faktoren. Dazu zählen etwa Umwelt, Rohstoffe, Politik, Gesetze, der demografische Wandel oder die Entwicklung von Erzeuger-, Abnehmer-, Arbeits- und Finanzmärkten. Der andere Einflussbereich wird durch prozesstechnische Faktoren bestimmt. Dazu zählen beispielsweise Organisation, Automation, Technologien, Branchentrends, Forschung und Entwicklung, Werkstoffe, Sensorik, RFID, das Internet – und das „Internet der Dinge“.

2.4.1  Umkehrung der Warenströme Bei den globalen Faktoren wird der Trend, mit der Produktion an immer noch billigere Standorte zu ziehen, ein Ende finden. Hinzu kommt, dass für viele Branchen das Heil nicht mehr darin liegt, die Waren in immer größeren Stückzahlen immer arbeitsteiliger herzustellen. Vielmehr wird in Zukunft eine flexible und marktnahe Fertigung der Produkte in kundenspezifischer Ausprägung von Vorteil sein. Damit kann besser auf die steigende Individualisierung der Kundenwünsche reagiert werden. Das spart zudem Transporte und aufgrund der kurzen Wege auch Warenbestände, die sich im Umlauf befinden. Das ist bei den immer kürzeren Produktlebenszyklen von großer Bedeutung. Es vermeidet darüber hinaus Verschwendung und schont letztlich unsere Erde.

12

C. Hahn-Woernle

Dieser Trend führt zu einer Umkehrung der Warenströme, auf die sich die Intralogistik flexibel anzupassen hat. Schon jetzt dient die Intralogistik immer weniger nur als Versorger der Abnehmermärkte, sondern greift direkt in Wertschöpfungsprozesse ein – „Value Added Services“. Denn seit jeher ist das Ziel, mit möglichst geringen Warenbeständen eine möglichst große Vielfalt an Kundenwünschen zu erfüllen. Das erfordert eine leistungsfähige Intralogistik. Ganz entscheidend werden Logistik und Intralogistik dabei durch die Entwicklung des Internets unterstützt – diese Entwicklung steht erst am Anfang. Das WWW knüpft direkt an das Herzstück der Intralogistik, die Datenverarbeitung und die Informations-Technologie, an. Das ist der Schlüssel für alle Veränderungen.

2.4.2  Demografischer Wandel erfordert Automatisierung Eine weitere Herausforderung liegt im demografischen Wandel. Um im internationalen Wettbewerb als Industrienation bestehen zu können, muss der Nachwuchs immer stärker qualifiziert werden. Denn langfristigen Erfolg hat nicht, wer billig arbeitet, sondern wer schnell denkt. Auf der anderen Seite wird gerade durch die breiter angelegte höhere Qualifizierung der jungen Menschen die Anzahl der verfügbaren – und motivierten – Arbeitskräfte im Low-end-Bereich abnehmen. Gleichzeitig wächst der Anteil an älteren Menschen. Das bedeutet: Mittelfristig werden Produktionskräfte fehlen. Für Arbeitsprozesse in der Warenhaltung und der Warenverteilung bedeutet dies eine verstärkte Automatisierung. Davon, dass Automaten die Arbeit des Menschen komplett übernehmen, ist man in der Intralogistik noch weit entfernt. Zu breitgefächert und verschieden sind die Aufgaben in der Intralogistik. Automaten sind jedoch dazu geeignet, begrenzte Spezialaufgaben, bei denen hohe Reproduzierbarkeit und hohe Leistungen gefordert sind, zu erledigen. Im Gegensatz dazu kann der Mensch universelle Aufgaben flexibel lösen. Überschreiten die Anforderungen hier eine bestimmte Grenze, wird eine automatische Lösung unumgänglich. Um Leistungsfähigkeit und Flexibilität zu verbinden, kombiniert man in vielen Bereichen automatische Teilsysteme zu komplexen Einheiten. Ziel wäre der durchgängig automatische Prozess vom Wareneingang über das Palettieren und Depalettieren über das Identifikations-Gate, den Transport, die Einlagerung und Auslagerung sowie der Warenausgang. Derzeit werden Automatisierungsaufgaben immer stärker in Clustern erfüllt. Diese Cluster können sukzessive durch neu entwickelte Spezialzellen ergänzt werden. Aufgaben wie Palettieren, Depalettieren und Kommissionieren werden Teil des beschriebenen automatisierten Prozesses. Das trifft auch auf Ein- und Auslagerprozesse zu, die dank Innovationen in der Sensorik immer schneller und störungsfreier automatisch ablaufen. Auch die rasanten Fortschritte in der Robotik und eine weitere Standardisierung von Ladeeinheiten und Verpackungen gehen der Automatisierung voraus. Je mehr etwas standardisiert wird, desto einfacher kann es automatisiert werden. Das gilt auch für die Software- und Steuerungstechnologie.

2  Neue Anforderungen für die Logistik des 21. Jahrhunderts

13

2.4.3  Automatisierung erfordert Standardisierung Der ausgeprägte Hang in Mitteleuropa, die intralogistischen Prozesse sehr flexibel zu automatisieren, führte zu einem wahren Entwicklungsschub auf vielen Gebieten wie der Sensorik, der Identifikation, der Robotik sowie der software- und steuerungstechnischen Verkettung dieser Komponenten. Dabei ist die Intralogistik selbst keine Branche, die Grundlagenentwicklungen bei neuen Technologien betreibt. Sie ist aber eine Branche, die diese neuen Technologien nutzt, in Systeme integriert und so Anwendungen schafft, die jene Branchen vor neue Herausforderungen stellt, die solche Technologien entwickeln. Ein solches Beispiel ist RFID, das solche Lösungen wie das „Internet der Dinge“ ermöglicht. Denn zum einen stellen die zahlreichen Schnittstellen zwischen den einzelnen Automatisierungs-Komponenten derzeit noch Restriktionen bei der Gestaltung effizienter Intralogistikprozesse dar, sobald die Komponenten und deren Steuerungen nicht mehr aus einer Hand geliefert werden, sondern aus unterschiedlichen Quellen stammen. Zum anderen werden zentrale Materialflusssysteme immer schwerer handhabbar und immer weniger flexibel, wenn zusätzliche Komponenten eingebunden werden sollen. Dezentrale Konzepte können hier den nächsten Innovationsschritt darstellen und maßgeblich zur Standardisierung beitragen, die wesentliche Voraussetzung für eine durchgängige Automatisierung ist.

2.4.4  Flexibilität durch Modularität Unter diesen Voraussetzungen werden sich nicht nur die transportlogistischen Warenströme verändern, sondern auch die Warenströme im Inneren der Systeme. Diese Systeme müssen schnell und flexibel auf Veränderungen reagieren können. Das erreichen sie durch eine Modularisierung, indem die Logik an die Stellen verteilt wird, wo die Entscheidungen stattfinden. Das Materialflusssystem wird dann aus drei Bausteintypen oder Entitäten zusammengesetzt sein: Fördertechnikmodule, intelligente Transporteinheiten und den unterstützenden Softwarediensten. In jedem Fall gilt: Innovative Technologien müssen mit zuverlässiger Leistung und wirtschaftlichem Betrieb einhergehen. Die Grenzen der Automatisierung und damit der Innovationen sind heute noch lange nicht erreicht. Aber die Anwender dürfen nicht in technische Abenteuer gestürzt werden. Der Trend, weiter zu automatisieren, kann nur dann wirtschaftlich und sicher funktionieren, wenn gleichzeitig standardisiert wird. Das macht automatische Systeme sicher einsetzbar. Erst wenn das Lager kein Lager mehr ist, sondern ein Sortierpuffer, wenn Bewegungen vermieden werden, wo immer es geht, wenn DV- und agentengestützte Systeme verfügbar sind, die sich selbst beibringen, wie sie sich an einen veränderten Prozess anpassen, und wenn sich die Programmierung eines Systems auf die fehlersichere Parametrierung reduzieren lässt und damit auch schnelle Inbetriebnahmezeiten ermöglicht, ist das nächste entscheidende Etappenziel erreicht.

Kapitel 3

Materialf lusssteuerung heute und ihre Defizite Clemens Nieke

3.1  Materialf lusssteuerung heute Materialf lusssteuerungen kommen heute immer dann zum Einsatz, wenn Waren innerhalb eines nicht trivialen und vollautomatischen Transport- und/oder Lagersystems bewegt werden. Die Materialf lusssteuerungen kommen in Systemen unterschiedlichster Ausprägung zum Einsatz. Ein wichtiges Einsatzgebiet von Material­ f lusssteuerungen ist beispielsweise der Gepäcktransport in Flughäfen. Durch die ständig wachsenden Bedürfnisse der Logistikanbieter werden die Ansprüche an Materialf lusssteuerungen immer größer. Verstand man früher unter einer Material­ f lusssteuerung überwiegend nur die Einrichtungen, welche den reinen Transport einer Ladungseinheit von einem Ort zu einem anderen ermöglichten, so sind heutige Materialf lusssysteme hoch komplexe und auf die Kundenbedürfnisse optimierte Steuerungs- Visualisierungs- und Kontrollsysteme. Die Materialf lusssteuerung ist somit ein wichtiger Bestandteil des gesamten Supply Chain Managements. Dementsprechend unterliegt sie auch einem ständigen Wandel. Damit ist auch die Notwendigkeit verbunden, sich schnell an neue Situationen und Umfeldbedingungen in der Intralogistik anzupassen. Gerade in globalisierten Märkten ist die Materialflusssteuerung als zentrales Bindeglied zwischen der dispositiv orientierten Warenwirtschaft und den physikalischen Transporteinrichtungen eine der entscheidenden Größen im intralogistischen Prozess. Der Aufgabenumfang, den moderne Materialf lusssteuerungen zu erbringen haben, ist demzufolge sehr weitreichend. Das Ausführen von Transportaufträgen ist hier nur die klassischste aber auch zugleich grundlegendste aller Aufgaben. Aus einer vorgegebenen „Start-Ziel“ Kombination, werden Teiltransporte abgeleitet und schrittweise ausgeführt. Die schrittweise Ausführung der Teiltransporte braucht aber für jede Anlage ein Mindestmaß an strategischen Regeln. Unter Regeln versteht man hier Transportprinzipien wie z. B. FIFO, zeit-, wegoptimierte Teiltransporte

C. Nieke () Stöcklin Logistik GmbH, Untere Industriestrasse 20, 57250 Netphen, Deutschland e-mail: [email protected] W. Günthner, M. ten Hompel (Hrsg.), Internet der Dinge in der Intralogistik, DOI 10.1007/978-3-642-04896-8_3, © Springer-Verlag Berlin Heidelberg 2010

15

16

C. Nieke

aber auch Reihenfolgen und Sequenzierungen, wie sie bei Kommissionier- und Produktionsprozessen sowie bei Pack- bzw. Belademustern benötigt werden. Neben diesen grundlegenden Transportregeln müssen Materialf lusssteuerungen aber auch sicher stellen, dass die transportphysikalischen Ressourcen optimal für die Transportausführung eingesetzt werden. Ein Faktor mit zentraler Bedeutung für die Ressourcenoptimierung ist die Vermeidung von Stau- bzw. Rückstausituationen innerhalb des intralogistischen Transportsystems. Auch wenn ein Stau nicht immer ausgeschlossen werden kann, so muss zumindest zu jeder Zeit sichergestellt sein, dass keine Blockaden entstehen. Ein weiterer wichtiger Faktor bei der Ressourcenoptimierung ist das Finden von alternativen Transportrouten bei gestörten oder längerfristig nicht zur Verfügung stehenden Transportstrecken. Besondere Restriktionen für Transportwege, welche auf Grund von Umgebungseinf lüssen wie Temperatur, Explosionsgefahr und vielem mehr vorhanden sind, bilden weitere wichtige Faktoren für die Ressourcenoptimierung. Die Visualisierung einer Anlage ist eine weitere Aufgabe der Materialf lusssteuerung. Hierbei stehen im Unterschied zu Visualisierungssystemen aus der Chemie und Produktion nicht einzelne und zum Teil sehr detaillierte Informationen wie Geberzustände, Sollwerte, usw. im Vordergrund, sondern mehr die Anzeige der transportspezifischen Einf lussfaktoren und Gesamtzusammenhänge. Die Visualisierung ist nicht nur ein informierendes, sondern vor allem ein steuerndes Interaktionsmedium. Meistens sind heute die Bediener der intralogistischen Anlagen nicht technisch ausgebildete Anwender, sondern angelerntes Personal. Dies erzeugt hohe Ansprüche an die Übersichtlichkeit und einfache Bedienbarkeit von Visualisierungen. Bei der Störungserkennung und -beseitigung muss die Visualisierung den Bediener führen und auch Prozeduren unterstützen, die Anlagen nach Störungen sicher und koordiniert wieder in den automatischen Betriebszustand zurückversetzen können. Für eine höher geschulte ‚Keyusergruppe‛ müssen Funktionen zur Verfügung stehen, welche transportrelevante Daten von Ladeeinheiten anzeigen und vor allem editieren können. Bei der Editierung besteht die Einschränkung, dass eine Ladeeinheit nicht von jedem beliebigen aktuellen Standort alle Ziele erreichen kann. Demzufolge braucht es auch hier Sicherungsmechanismen und nötigenfalls auch Rückmeldungen an andere Systeme innerhalb der intralogistischen Supply Chain. Die Erfassung von Daten und deren Weitergabe an andere Systeme sind ebenfalls Aufgaben einer Materialf lusssteuerung. Die Datenerfassung erfolgt fast immer im Umfeld eines Aufgabeplatzes des Transportsystems. Nicht nur die Konturenerkennung, sondern vor allem die Produktidentifikation und alle Arbeitsschritte im Zusammenhang mit der Qualitätssicherung spielen beim Wareneingang eine wichtige Rolle. Erst wenn diese Daten erfasst wurden, lässt sich für jede Ladeeinheit ein intralogistisch relevantes Ziel bestimmen. Dieser Zielfindungsprozess erfolgt typischer Weise in Kooperation mit einem übergeordneten Enterprise Resource Planning (ERP) System. Für Waren, die sich in Lager- oder Pufferbereichen befinden, muss die Materialflusssteuerung Transportaufträge von einem übergeordneten ERP System entgegen nehmen können und für die Ausführung der Warenbewegungen sorgen. In der Regel meldet die Materialf lusssteuerung alle ausgeführten Transportaufträge an das





3  Materialf lusssteuerung heute und ihre Defizite

17

übergeordnete System zurück. Um all diese Kommunikationsaufgaben erbringen zu können, braucht eine Materialf lusssteuerung leistungsstarke Kommunikationsschnittstellen. Durch die Vielzahl und Vielfalt der Kommunikationspartner werden immer wieder Anpassungen und Umwandlungen der Datenformate und Kommunikationsprotokolle nötig. Ein weiterer großer Aufgabenbereich der Materialf lusssteuerung liegt im Bereich der Protokollierung und der Bereitstellung von transportstatistischen Daten. Die Verfügbarkeit und vor allem das tägliche Warentransportvolumen sind wichtige Kennzahlen für die Steuerung der Geschäftsprozesse entlang der Supply Chain. Neben der Funktionalität der Geschäftsprozesssteuerung spielt die Protokollierung und Statistik aber auch noch eine wichtige Rolle in der Fehler- und Störungsdiagnose. Die Daten helfen systematische Fehler schneller zu erkennen und unterstützen bei der Planung von Serviceintervallen. Heutige Materialf lusssteuerungen sind bis auf wenige Ausnahmen zentral, hierarchisch und pyramidenförmig aufgebaut. Man spricht daher auch von der Steuerungspyramide in der Intralogistik. Die Abb. 3.1 verdeutlicht die verschiedenen Schichten dieser Pyramide. Die Pyramide beschreibt nur die steuerungstechnisch relevanten Schichten. Man geht davon aus, dass die Pyramide auf der Mechanik der Transportanlage, die üblicher Weise nicht dargestellt wird, aufbaut. Die Materialf lusssteuerung erstreckt sich über die drei grundlegenden Ebenen der Pyramide. Die unterste Ebene der Pyramide ist die Feldebene. Alle an den mechanischen Transportelementen angebrachten Aktoren und Sensoren gehören zu dieser Schicht. Die Steuerungselemente der Feldebene bilden zusammen mit der Mechanik den ausführenden Teil der Materialf lusssteuerung. Transporte und Lastübergaben von einem auf das nächste Transportelement werden durch die nächst höhere Schicht koordiniert; das ist die Steuerungsebene. Sie wird meist durch den Einsatz von Speicher-Programmierbaren-Steuerungen (SPS) gebildet. Diese Schicht verarbeitet die Signale der Feldebene und steuert dementsprechend die Aktoren. Weiterhin stellt sie alle sicherheitsrelevanten Funktionen und die entsprechenden Fehlermeldungen zur Verfügung. Auf dieser Ebene ist meistens die manuelle Betriebsart inklusive eines maschinennahen „Human-Machine-Interface“ realisiert. Prozesstechnisch betrachtet überführt diese Schicht das mechanische ERP Leitebene Prozess-Steuerung

Server WMS Clients Materialflussrechner

Steuerungsebene Feldebene

Abb. 3.1   Vereinfachte Steuerungspyramide zentraler Materialf lusssteuerungen

SPS Materialfluss

18

C. Nieke

Layout in ein logisches und platzbezogenes Transportsystem. Das schafft die Grundlage für automatisierte und platzbezogene Teiltransporte. Die Prozesssteuerung bildet die dritte und damit auch höchste Schicht einer Materialf lusssteuerung. Häufig wird diese Schicht auch Materialf lussrechner genannt. Die Steuerungsebene und Prozess-Steuerung sind über eine Kommunikation miteinander verbunden. Der Materialf lussrechner sendet die platzbezogenen „Von-Nach“ Transporte als Vorgabe an die Steuerungsebene. Nach erfolgter Warenverschiebung meldet die Steuerungsebene diese an den Materialf lussrechner zurück. In dieser Schicht der Pyramide ist oft auch die Visualisierung angeordnet. Sie hat hier einerseits Zugriff auf die Signale der Steuerungsschicht und andererseits auch Zugriff auf die Transportauftragsdaten des Materialf lussrechners. Der Materialf lussrechner kommuniziert seinerseits zusätz­ lich mit der nächst höheren Schicht; der Leitebene. In der Leitebene werden alle lagerverwaltungstechnischen Aufgaben realisiert. Ist eine Kommissionierung im System vorhanden, so wird diese auch meistens von der Leitebene aus gesteuert. Über der Leitebene befindet sich die Schicht mit dem Warenwirtschaftssytem (ERP), welches die höherwertigen Geschäftsprozesse abbildet. Für die Rechenhardware werden in der Steuerungsschicht typischer Weise speicherprogrammierbare Automatisierungsgeräte eingesetzt. Ob diese Geräte in der klassischen Bauform einer SPS oder als Industrie-PC mit einer Soft- SPS realisiert werden spielt dabei keine Rolle. Die verwendeten Programmiersprachen richten sich nach dem IEC 61131 Standard oder ähnlichen herstellerabhänigen Vorgaben. Die Sensoren und Aktoren werden häufig über Feldbussysteme, zunehmend aber auch auf der Basis von Ethernet an die Automatisierungsgeräte angebunden. Wichtigstes Kriterium für den Einsatz in dieser Schicht ist die Echtzeitfähigkeit der eingesetzten Komponenten. Je höher eine Komponente in der Pyramide angesiedelt ist, um so weniger Bedeutung hat ihre Echtzeitfähigkeit. Für die Prozesssteuerung werden meist PC basierende Client- Serverlösungen verwendet. Die früher üblichen UNIX basierenden Großrechner verlieren immer mehr an Marktanteil. Moderne PC- Server bieten heute eine gleichwertige Rechenleistung und haben vor allem einheitliche Standards für den Einsatz von relationalen Datenbanken und Festplattenbackups. Quasi alle Kommunikationen beruhen heute auf der Basis von TCP/IP. Für die Programmierung stehen sehr leistungsfähige Programmiersprachen wie C++, C# oder Java in verschiedensten Implementierungen und zum Teil als kostenlose Versionen zur Verfügung. Die Programmierung erfolgt meist nach den Regeln der Objektorientierung.

3.2  Grenzen heutiger Systeme Trotz der großen Verbreitung von zentralen Materialf lusssteuerungen und ihren sehr weit ausgereiften Technologie, stoßen sie immer wieder an ihre Grenzen. Dabei stellt die Leistungsfähigkeit der Rechner bei richtiger Auslegung keine nennenswerte Grenze mehr da. Problematischer wird es bei der Ausfallsicherheit der Server. Hier müssen entsprechend aufwändige Maßnahmen im Vorhinein getroffen werden. Je

3  Materialf lusssteuerung heute und ihre Defizite

19

nach projektspezifischer Anforderung kommen dabei „Warm“ – oder „Hot-Standby“ -Systeme zum Einsatz. Je nach Ausprägung steigen die Kosten für adäquate Systeme sehr schnell an. Hinzu kommt, dass die Lebenszeit der Rechnerhardware auf der Steuerungsebene meist kürzer ist, als die Lebenszeit der Mechanik. Die mechanischen Transporteinrichtungen können durch das Einhalten der vom Hersteller empfohlenen Serviceintervalle sehr leicht die zwei- bis dreifache Lebenszeit im Vergleich zur Steuerungshardware erreichen. Heutige SPS können Betriebszeiten von über 10 Jahren haben. Deutlich schlechter sieht es bei den Servern aus. Keine PC- Hardware wird einen solchen Zeitraum in Betrieb sein, ohne dass sie zu einem unkalkulierbaren Sicherheitsrisiko wird. Bei Servern liegt die Lebenszeit nur etwas über der Hälfte der Automatisierungsgeräte. Somit ist erkennbar, dass während der Lebenszeit einer Anlage die Rechnerhardware mehrfach ausgetauscht werden muss. Dies setzt eine dauerhafte Verfügbarkeit von Ersatzteilen und Rechnerhardware voraus. Ein Hardwareersatz bedingt immer ein erneutes Engineering bezüglich der neuen Rechnerhardware. Dabei ist zu überlegen, ob die anfangs prognostizierten Datenvolumina und Kommunikationsaktivitäten noch ausreichend sind. Oftmals ist dies nicht der Fall, oder es wird zur Sicherheit gleich eine leistungsfähigere Hardware eingesetzt. Dies verteuert den Hardwareersatz aber wesentlich, weil dadurch oft auch Softwareanpassungen notwendig werden. Die unveränderte Nutzungsdauer eines einmal konzipierten intralogistischen Anlagenlayouts wird immer kürzer. Dies ist auf die Globalisierung der Märkte und den dadurch ständig ändernden Anforderungen zurückzuführen. Hierarchisch und zentralistisch aufgebaute Materialf lusssteuerungen sind bei den sich ständig ändernden Marktbedingungen zu schwerfällig und nur mit einem hohen Aufwand anzupassen. Änderungen müssen dabei immer auf allen Ebenen der Steuerungspyramide quasi zeitgleich durchgeführt werden. Zentrale Systeme bieten auf Grund ihrer klaren Strukturierung der Schichten eine immens große Informationsdichte. In der Prozess- Steuerungsschicht herrscht dabei das größte Informationsangebot. Hier f ließen die Transportauftragsdaten vom übergeordneten ERP System mit den Daten und Informationen der Anlagensteuerung zusammen. Dieser Datenpool ist eine ausgezeichnete Basis für die Bildung von Strategien und Transportoptimierungen. Die Informationsvielfalt bewirkt aber auch, dass Optimierungsalgorithmen immer projektspezifischer und vor allem schnell sehr komplex werden. Schon nach kurzer Zeit überblickt kaum jemand mehr alle Optimierungen und deren wechselseitigen Einf lüsse und Bedingungen. Oft kommen noch weiterführende Optimierungswünsche des Kunden während der Hochlaufphase hinzu, die die Situation verschlimmern und zusätzlich zur Unübersichtlichkeit beitragen. Stellen sich zusätzlich noch Konzeptschwächen aus der Planungsphase heraus, führt dies bei zentralen Systemen schnell zu einem hohen Mehraufwand in der Realisierung. Das große Datenangebot verleitet dazu, dass alle möglichen Informationen beliebig tief miteinander verknüpft werden, um die Probleme möglichst schnell zu lösen. Damit wird das System intern immer spezieller und komplexer. Eine hohe Komplexität von Anlagen birgt immer eine ganze Reihe von Gefahren und Risiken. Mit steigender Komplexität reduziert sich automatisch die Anzahl an Mitarbeitern, die ein solches System noch effizient realisieren können. Durch

20

C. Nieke

die Unübersichtlichkeit eines komplexen Systems müssen sich die Programmierer ständig mit der Gesamtheit der Projektaufgaben auseinandersetzen. Dieser ständige Auseinandersetzungsprozess führt dazu, dass weitere Mitarbeiter nur sehr schwer in laufende Projekte eingearbeitet werden können. Je weiter ein Projekt in der Realisierung fortgeschritten ist, desto schwieriger und zeitaufwändiger wird die Einarbeitung. Dieser Effekt führt in der Praxis meist dazu, dass mit zunehmender Projektlaufzeit eher weniger, dafür aber immer die gleichen Personen an der Realisierung eines Projektes arbeiten. Das Projekt wird dadurch sehr personenbezogen. Es bildet sich eine Art geistiger Projektkopf heraus. Die Teamarbeit wird erschwert bzw. findet nur noch in reduziertem Umfang statt. Bei Ausfall eines Mitarbeiters entstehen schnell gravierende Terminprobleme. Eine weitere Grundproblematik dieser personenbezogenen Projektarbeit kommt noch hinzu: Diejenigen Mitarbeiter, welche an komplexen Aufgaben arbeiten und dabei unterbrochen werden, machen mehr Fehler und werden deutlich ineffizienter. Sie müssen sich nach einer Unterbrechung immer wieder in die Problematik einarbeiten, bevor sie produktiv werden können. Alle diese personalbezogenen Erscheinungsformen beim Umgang mit hoch komplexen Aufgaben führen schlussendlich sehr schnell zu einer Abhängigkeit der Herstellerfirmen von einzelnen Mitarbeitern. Hoch komplexe Aufgabenstellungen haben nicht nur weitreichende Auswirkungen auf den Arbeitsablauf der beauftragten Mitarbeiter, sondern erzeugen auch unbewusst systeminterne höchst problematische Effekte: Anstelle von standardisierten Aufgabenlösungen werden in komplexen Systemen sehr schnell punkt- oder kundenspezifische Speziallösungen erstellt und eingesetzt. Zusätzlich werden im turbulenten Alltagsgeschäft unbewusst Vereinfachungen vorgenommen und Annah­ men getroffen. Dadurch kommt es zu einer impliziten logischen Festschreibung von veränderten Annahmen und daraus resultierenden Teilfunktionalitäten, welche dann nicht mehr exakt mit dem eigentlichen geplanten Systementwurf übereinstimmen. Das Projekt läuft Gefahr, eine programmiererabhängige Eigendynamik zu entwickeln. Hinzu kommt, dass schon kleine funktionale Änderungen während der Realisierungsphase sehr schnell auch umfangreiche Änderungen im Gesamtentwurf der bisher erarbeiteten Aufgabenlösung erzeugen können. Bereits erreichte Zwischenergebnisse werden wieder verworfen. Komplexe zentrale Systeme neigen aber nicht nur dazu, von den Vorgaben abzuweichen, sondern werden sehr schnell auch fehleranfällig. Kleine lokale Fehler können sich dabei schnell durch das ganze System fortpf lanzen und so zu einem Schneeballeffekt führen. Da zentrale Systeme immer einen „single point of failure“ darstellen, kann dies dann zu gravierenden Ausfällen führen. Die heutigen Materialf lusssteuerungen sind alle nach herstellerinternen Standards gebaut. Transporttechnische Funktionalitäten, Bedienung und das Fehlerhandling sind dadurch individuelle Lösungen. Eine Kopplung verschiedener Anlagenteile von unterschiedlichen Herstellern ist heutzutage immer noch eine sehr komplexe Angelegenheit und bedarf einer großen Kooperationsbereitschaft auf allen Seiten. Die funktionale Ausprägung der Schichten in der Automatisierungspyramide ist individuell und bei jedem Hersteller eher geschichtlich gewachsen. Aus diesem Grund sind Teil- oder Subsystemgrenzen innerhalb eines Projektes nach herstellerindividuellen Vorgaben gezogen. Dies führt dann schlussendlich zu

3  Materialf lusssteuerung heute und ihre Defizite

21

einer unüberschaubaren Variantenvielfalt von Automatisierungslösungen innerhalb der Steuerungs- und Prozessschicht. Eine standardisierte Vernetzung verschiedener Teilsysteme ist somit quasi unmöglich. Ein weiterer schwieriger Punkt in zentralen Systemen tritt dann zu Tage, wenn bestehende Systeme erweitert oder verändert werden sollen. Vor jeder Erweiterung ist meist eine detaillierte Aufnahme der aktuellen Anlagen notwendig. Dabei müssen alle Funktionalitäten und Optimierungen rekapituliert werden. Dies benötigt einige Zeit und ist besonders aufwändig, wenn die Personen der Erstrealisierung nicht mehr zur Verfügung stehen. Erfolgt die Aufnahme nicht vollumfänglich, so sind später Seiteneffekte und unerwünschte Anlagenverhaltensweisen nicht auszuschließen. Die größeren Probleme beginnen oftmals erst bei der Montage und Inbetriebsetzung, denn durch diese Arbeiten wird in das bestehende System eingegriffen. Betriebsunterbrechungen sind dann nicht zu vermeiden. Kommen noch Arbeiten an Feldbussen oder anderen zentralen Kommunikationselementen hinzu, müssen immer große Anlagenteile für die Arbeiten abgeschaltet werden. Dies erfordert eine sehr aufwändige Terminkoordination auf allen Seiten. Nach der Inbetriebsetzung der veränderten Anlagenteile kann meistens keine kontinuierliche Hochlaufphase erfolgen. Einmal in allen Schichten der Automatisierungspyramide integrierte Erweiterungen müssen mit der bestehenden Anlage sofort von Anfang an zusammenarbeiten. Trotz verschiedener Umbauetappen entsteht immer ein „point of no return“ – ab einer gewissen Eingriffsgröße und Verknüpfungstiefe mit dem bestehenden System können die Änderungen nicht mehr rückgängig gemacht werden. Die Änderungen haben einen zu großen Einf luss auf alle Schichten der Automatisierungspyramide. Man ist darauf angewiesen, dass die alten und neuen Anlagenteile zusammen betrieben werden können. Um dieses Risiko zu verkleinern, werden entsprechende Tests durchgeführt. Diese können aber nicht in dem Umfang erfolgen, wie bei einer Neuinstallation. Bestehende Warenbestände dürfen durch die Tests nicht verändert werden oder müssen nach einem Test im produktiven System meistens manuell nachgebucht werden. Somit bleibt vor Erweiterungen oft nur der Weg, das geänderte System erneut komplett im Vorfeld noch einmal zu simulieren; dies ist aufwändig und sehr kostenintensiv. Für den Bediener entstehen während der Umbauphase Situationen, mit denen er nur schwer zurecht kommt, denn das System reagiert noch nicht in der gewohnten Art und Weise. Hervorgerufen durch die Eingriffe kommen oftmals in den bestehenden Systemteilen neue und zum Teil nicht erwartete Fehler hinzu. Diese Problemlösungen sind dann besonders schwierig und für den Anlagenbetreiber selber kaum mehr handhabbar. Eine weitere Grenze zentraler Systeme ist ihre endliche Summe an Problemlösungen. Die Flexibilität von zentral gesteuerten Anlagen ist nur so groß, wie diese bereits schon im Planungsprozess und in der Realisierung mit berücksichtigt wurde. Zentrale Systeme zeigen somit nur ein Verhalten innerhalb der geplanten und vorgesehenen Grenzen. Treten Situationen ein, für welche kein Anlagenverhalten geplant wurde, ist das Anlagenverhalten unbestimmt. Auf Heuristiken beruhende Optimierungen können sich unter diesen Umstände dann sogar eher als Kontraproduktiv auswirken. Dies führt dann sehr schnell zu Blockaden und Stillstandszeiten der Anlage.

Kapitel 4

Entwicklungen in der Automatisierungstechnik Jürgen Elger und Carolin Haußner

4.1  Entwicklung der Automatisierungstechnik In den letzten Jahren haben sich im industriellen Anlagen- und Lösungsgeschäft die Rahmenbedingungen deutlich verändert. Die Projektlaufzeiten werden immer kürzer, die geforderte Funktionalität und Komplexität steigen, gleichzeitig sinken die erzielbaren Preise. Anlagenbetreiber fragen vermehrt standardisierte Lösungen nach, die gleichzeitig ihre individuellen Anforderungen optimal abdecken können und sich flexibel anpassen und erweitern lassen. Diesem Trend musste die Automatisierungstechnik folgen. Auch die Automatisierungsaufgaben wurden somit immer komplexer und es mussten Möglichkeiten gefunden werden, die Kosten zu senken. Dies hatte sowohl Auswirkungen auf die generelle Systemarchitektur als auch auf die verwendeten Hardware-Komponenten. Dieser Trend wird auch in Zukunft anhalten, er ist im industriellen Anlagen- und Lösungsgeschäft einer der wesentlichen Treiber für die Entwicklung des Internets der Dinge. Bevor nun dieser Trend weiter untersucht wird, soll zunächst die Entwicklung der Automatisierungstechnik in den letzten Jahren betrachtet werden. Siehe hierzu auch (Zankl 2006). In den 80er Jahren wurden die Sensoren und Aktoren einer Anlage, wie z. B. Lichtschranken und Motoren, direkt an den Ein-/Ausgängen der zentralen Anlagensteuerung angeschlossen (s. Abb. 4.1 links). Gegen Ende der 80er Jahre erfolgte die Einführung dezentraler Peripherie (s. Abb. 4.1 rechts). Ursprünglich nur als eine Methode gedacht, um den Aufwand für die Verkabelung von Ein-Ausgängen der Anlagensteuerung zu verringern und die damit verbundenen Kosten zu senken, führte sie gleichzeitig zu kleineren Schaltschränken und einer besser überschaubaren Steuerungstechnik. Die Sensoren und Aktoren wurden nun an die Ein-Ausgänge dezentraler Signalsammler, wie z. B. J. Elger () Corporate Technology CT SE 5, Siemens AG Günther-Scharowsky-Str. 1 91058 Erlangen, Deutschland e-mail: [email protected] W. Günthner, M. ten Hompel (Hrsg.), Internet der Dinge in der Intralogistik, DOI 10.1007/978-3-642-04896-8_4, © Springer-Verlag Berlin Heidelberg 2010

23

24

J. Elger und C. Haußner

Steuerung

Steuerung

Feldbus Signalsammler

Sensor

Aktor

Zentrale Ein-Ausgänge

Sensor

Aktor

Dezentrale Peripherie

Abb. 4.1   Zentrales System, System mit dezentraler Peripherie

Siemens ET 200, angeschlossen. Die Signalsammler wiederum sind über ein serielles Feldbussystem, wie z. B. Profibus, mit der Anlagensteuerung verbunden. Der nächste Schritt wurde getrieben von der Überlegung, Signale, die vor Ort erfasst werden, auch direkt am Ort des Geschehens weiterzuverarbeiten. Hierzu wurde ein Teil der Funktionalität der Anlagensteuerung in die dezentrale Peripherie verlagert, es entstanden intelligente Feldgeräte und Antriebe (s. Abb. 4.2 links). Sie sind zum Teil über einen Feldbus, zum Teil auch schon über Ethernet verbunden. Immer leistungsfähigere Hardware, vor allem immer mehr verfügbare Rechenkapazität bei den intelligenten Feldgeräten, verbunden mit einer starken Miniaturi-

Steuerung

Ethernet, WLAN, ...

Profibus, Ethernet Intelligentes Gerät

Intelligentes Gerät

Intelligente Feldgeräte

Intelligentes Gerät

Intelligentes Gerät

Dezentrales System

Abb. 4.2   System mit intelligenten Feldgeräten, dezentrales System

4  Entwicklungen in der Automatisierungstechnik

25

sierung, führen zum nächsten, konsequenten Schritt in dieser Reihe von Entwicklungen: Auch die bisher noch in der Anlagensteuerung verbliebene Funktionalität wird zukünftig dezentralisiert und – sogar zusammen mit Teilen des (hier nicht dargestellten) Leitsystems – als verteiltes System ohne zentrale Steuerung realisiert werden (s. Abb. 4.2 rechts). Die Geräte kommunizieren direkt miteinander und stimmen sich ab, unter Verwendung von IP-basierten Kommunikationsprotokollen wie Industrial Ethernet oder WLAN.

4.2  Bildung mechatronischer Module Die im vorigen Kapitel beschriebenen intelligenten, dezentralen Geräte wie z. B. ein Motor mit integriertem Umrichter und evtl. weiteren Steuerungsfunktionen, z. B. für die Auswertung von Lichtschranken, die den Motor direkt ein- und ausschalten, weisen typischerweise Bestandteile aus mehreren Ebenen der klassischen Automatisierungspyramide auf. Ein intelligentes Gerät besteht also aus ineinandergreifenden Anteilen von Mechanik, Elektrik und Steuerungstechnik, die modular ausgelegt, d. h. auf das jeweilige Gerät bezogen und begrenzt sind und definierte Schnittstellen zur Außenwelt besitzen. Man spricht daher auch von mechatronischen Modulen. Die Festlegung der Granularität eines mechatronischen Moduls ist hierbei variabel möglich und hängt von der Aufgabenstellung und dem sinnvollen Grad der Wiederverwendung ab. Wenn beispielsweise der oben erwähnte Motor in einer Fördertechnik-Weiche verbaut ist, welche ein Fördergut entweder nach links oder rechts fördern kann, kann auch die Weiche in ihrer Gesamtheit als mechatronisches Modul betrachtet werden, welches aus anderen Modulen aggregiert sein kann. Für die Automatisierungstechnik führt der mechatronische Ansatz zu kleineren, dezentralen Automatisierungseinheiten, die nicht mehr notwendigerweise von einer klassischen Speicherprogrammierbaren Steuerung (SPS) verwaltet werden müssen, sondern auch auf kleineren dezentralen Controllern oder in einer Soft-SPS ablaufen können. Hier sind neue Ansätze zur effektiven Projektabwicklung nötig. Ein generisches Modell für verteilte Automatisierungssysteme ist in (IEC 61499) beschrieben. Eine Entwicklungsmethodik für mechatronische Systeme findet sich in (VDI 2206). Diese fokussiert zwar mehr auf die Entwicklung von Produkten, wie z. B. einer Bremsanlage, lässt sich aber gut auf das industrielle Anlagen- und Lösungsgeschäft übertragen. Ein wesentlicher Vorteil mechatronischer Module ist, dass sich mechanische, elektrische und steuerungstechnische Eigenschaften bereits in der Planungsphase und auch später in der Anlagendokumentation konsistent miteinander verknüpfen lassen, z. B. durch Mechanismen, wie sie aus der Objektorientierung bekannt sind. Wenn beispielsweise ein Motor gegen einen leistungsstärkeren ausgetauscht werden soll, kann festgestellt werden, welche Komponenten zu diesem mechatronischen Modul gehören, ob sie ebenfalls angepasst oder getauscht werden müssen, im Beispiel etwa der Umrichter, das Stromkabel oder der Flansch zur Befestigung des Motors. Dies reduziert den Engineering-Aufwand sowohl für die Erstellung der Anlage als auch für nachträgliche Änderungen.

26

J. Elger und C. Haußner

4.3  Konvergenz der Kommunikationstechnik Die Entwicklung moderner leistungsfähiger Kommunikationstechnik kann ebenfalls den erforderlichen Engineering-Aufwand für eine Anlage senken. Der Fortschritt bei der industriellen Kommunikation wird hierbei auch zukünftig von Entwicklungen im allgemeinen Kommunikationsbereich getrieben werden. Beispielsweise hat das Internet im PC-Massenmarkt dazu geführt, dass leistungsfähige und preisgünstige Netzwerkkarten mit Ethernet und TCP/IP selbstverständlich wurden. Davon profitiert im Nachgang auch die industrielle Kommunikation, hier ist Industrial Ethernet gerade dabei, sich im großen Stil durchzusetzen. Wie man an diesem Beispiel sehen kann, erfolgt die Übertragung solcher Techniken meist nicht 1:1, sondern indem speziell notwendige Anforderungen der industriellen Umgebung Rechnung getragen wird. So bietet das Industrial Ethernet zusätzlich auch Möglichkeiten, Daten in Echtzeit zu übertragen (Realtime Ethernet), womit beispielsweise die taktsynchrone Steuerung von Schrittmotoren im Millisekundenbereich möglich ist, ohne den „normalen“ Datenverkehr zu beeinträchtigen. Diese Entwicklung bedeutet, dass immer mehr Komponenten aus der IT-Infrastruktur in die Automatisierungstechnik Einzug halten, wie z. B. WLAN-Komponenten. Es ist zu erwarten, dass die Automatisierungstechnik eine ähnliche Entwicklung mit tiefgreifenden Veränderungen durchläuft, wie sie die IT-Landschaft in der Folge des Internet-Booms in den letzten Jahren durchlaufen hat. Dies bedeutet auch, dass für die Erstellung von Automatisierungslösungen im Kundenprojekt immer mehr Know-How aus dem Bereich der IT-Systeme erforderlich ist, was nicht zuletzt Auswirkungen auf die benötigte Qualifikation der betroffenen Mitarbeiter hat.

4.4  Neuartige Kommunikationsmöglichkeiten Neben den allgemeinen Verbesserungen in der Kommunikationstechnik, wie der einheitlichen Verwendung von Ethernet-basierten Dienstleistungen, gibt es weitere neuartige Kommunikationsmöglichkeiten, die entscheidend zur Verbreitung der Ideen des Internets der Dinge beitragen. Es sind Techniken, die den „Dingen“, d. h. im industriellen Bereich den Komponenten einer Anlage die Fähigkeit verleihen, ein „Bewusstsein“ für ihre Umwelt zu entwickeln, sie wahrzunehmen und dynamisch mit ihr sowie untereinander zu kommunizieren. Hierzu zählen RFID, WLAN, drahtlose Sensornetzwerke und andere Techniken zur ad-hoc-Vernetzung, wie z. B. ZigBee. Der Auf- und Abbau von Kommunikationsbeziehungen kann hier spontan erfolgen, je nach Erfordernissen, was den bisherigen Aufwand für die Planung und Einrichtung der Kommunikationsbeziehungen reduziert. Im Idealfall finden sich die Kommunikationspartner ohne weiteres Zutun per Plug&Play, d. h. ein neu hinzukommender Kommunikationsteilnehmer meldet sich selbständig im Kommuni-

4  Entwicklungen in der Automatisierungstechnik

27

kationsverbund an, wird von den anderen Teilnehmern aufgenommen und integriert sich in den Verbund. Die Integration einzelner Komponenten zu einem Gesamtsystem wird hierdurch wesentlich vereinfacht. Beispielsweise kann eine Palette mit verderblichen Lebensmitteln mit einem Temperatur-Sensor ausgestattet sein, der wiederum über eine Möglichkeit zum Speichern und Übermitteln von Temperaturwerten verfügt. Die Kühlkette lässt sich damit lückenlos überwachen und protokollieren. Steigt dann während des LKWTransports die Temperatur unzulässig an und die Kühlkette wird unterbrochen, misst und protokolliert der Sensor die Temperaturabweichung. Wenn die Palette dann im Lager ankommt, gibt sie an einem Wareneingangs-Scanner mittels eines angebrachten RFID-Labels ihre Identität bekannt und überträgt gleichzeitig eine Warnung über die Temperaturabweichung. Die Palette kann dann sofort ausgeschleust und der protokollierte Temperaturverlauf ausgelesen und genauer untersucht werden.

4.5  Zusammenfassung Die Veränderungen in der Automatisierungstechnik wurden und werden getrieben von den Anforderungen der Umwelt, in welcher diese Technik eingesetzt wird, wobei das industrielle Anlagen- und Lösungsgeschäft hier eine wesentliche Rolle spielt. Sie führen zu neuen Produkten mit innovativen Eigenschaften. Umgekehrt sind es gerade neue Produkte mit leistungsfähigerer Hardware und verbesserter Technik, die überhaupt erst die Möglichkeiten bieten, solche Anforderungen, deren Umsetzung vor ein paar Jahren technisch noch nicht so einfach möglich gewesen wäre, zu adressieren.

Kapitel 5

Software-Methoden für die Automatisierung Sascha Feldhorst und Sergey Libert

Die Verfügbarkeit von zusätzlichen Berechnungsressourcen in der Feldebene ermöglicht die Verlagerung von Steuerungsfunktionen in die räumliche Nähe der technischen Prozesse (vgl. Kap. 4). Dies macht den Bereich Software zu einem aktuellen und zukünftigen Schwerpunkt für technologische Innovationen in Automatisierungssystemen. Deshalb wird in den nächsten Jahren die Bedeutung von intelligenter Software in der Automatisierungstechnik weiterhin zunehmen (vgl. Favre-Bulle 2005). Schließlich verleiht die Software den Geräten ihre Intelligenz und sorgt für ein sinnvolles Zusammenwirken der einzelnen Geräte. In aktuellen Automatisierungssystemen werden die Steuerungsaufgaben von großen Software-Blöcken übernommen. Die Praxis zeigt jedoch, dass diese monolithischen Blöcke nur mit großem Aufwand den wachsenden Anforderungen der Kunden nach höherer Flexibilität und Komplexität bei gleichbleibender Leistung und Zuverlässigkeit gerecht werden können. Nachdem in den letzten Jahren viel Energie in die Dezentralisierung der Hardware-Komponenten gesteckt wurde, zeichnet sich nun ein Trend zu verteilter Steuerungs-Software ab. In solchen Systemen sind die Steuerungsaufgaben in kleineren Software-Einheiten organisiert, die miteinander kooperieren, um ihre Aufgaben innerhalb des Systems zu erfüllen (vgl. Favre-Bulle 2005, S. 87). Die Effizienz und Qualität der Software-Entwicklung hängt stark mit eingesetzten Entwicklungswerkzeugen zusammen. Viele der aktuellen Entwicklungsmethoden und -werkzeuge in der Automatisierung sind historisch gewachsen und seit vielen Jahren im Einsatz. Dementsprechend sind sie zwar wohl erprobt und führen zu stabilen und leistungsfähigen Systemen, berücksichtigen jedoch den Aspekt der Verteilung von Steuerungsaufgaben nicht oder nur unzureichend. Moderne Ansätze aus der Software-Technik wie objektorientierte Programmierung, komponentenbasierte Software-Entwicklung oder verteilte Software-Architekturen haben deshalb bisher hauptsächlich auf den oberen Steuerungsebenen Einzug gehalten.

S. Feldhorst () Lehrstuhl für Förder- und Lagerwesen, Technische Universität Dortmund Emil-Figge-Str. 73, 44221 Dortmund, Deutschland e-mail: [email protected] W. Günthner, M. ten Hompel (Hrsg.), Internet der Dinge in der Intralogistik, DOI 10.1007/978-3-642-04896-8_5, © Springer-Verlag Berlin Heidelberg 2010

29

30

S. Feldhorst und S. Libert

Ziel dieses Unterkapitels ist es, die aktuellen Anforderungen an die SoftwareWerkzeuge und -Methoden zu identifizieren und Ansätze vorzustellen, welche dabei helfen können, diesen Anforderungen gerecht zu werden. Zunächst soll jedoch ein Überblick darüber gegeben werden, welche Software in der Automatisierungstechnik eingesetzt wird.

5.1 Software in der Automatisierung In der modernen Automatisierungstechnik wird ein wesentlicher Teil der Steuerungsaufgaben von Software übernommen. Die Steuerungsaufgaben lassen sich dabei anhand der zeitlichen Reichweite ihrer Entscheidungen in drei Gruppen unterteilen: strategische, taktische und operative Steuerungen. Strategische Steuerungen übernehmen planerische und dispositive Aufgaben in der Produktion und Logistik. Die entsprechenden Software-Systeme organisieren und verwalten Produktions- und Geschäftsprozesse, lasten Aufträge ins System ein und weisen diesen die verfügbaren Ressourcen unter Beachtung von Leistungsanforderungen zu. Abhängig von der Unternehmensstruktur sind diese Systeme häufig hierarchisch organisiert und sind einem sogenannten Host-System (i. d. R. Enterprise Resource Planing, ERP) untergeordnet. Beispiele für strategische Steuerungen sind Systeme zur Produktionsplanung und Steuerung (PPS) oder Warehouse Management Systeme (WMS). Einige Software-Anbieter, wie z. B. SAP oder Microsoft, bieten komplette Systemlösungen an, die aus einzelnen Funktionsmodulen bestehen und nach Bedarf zusammengestellt und konfiguriert werden. Andere Anbieter schlagen spezialisierte Lösungen vor, die für bestimmte Anwendungen zugeschnitten sind. Taktische Steuerungen setzen speziell in logistischen Anlagen teil- oder vollautomatische Materialflussoperationen um. Zu den Aufgaben der Materialflusssteuerung gehören beispielsweise die Realisierung und Überwachung der Objektbewegung durch eine technische Anlage, die Vermeidung bzw. Lösung von Konfliktsituationen sowie die Optimierung der Anlagenauslastung. Aufgrund der großen Vielfalt von Anwendungsfällen und zu steuernden technischen Anlagen haben sich in diesem Bereich überwiegend proprietäre Software-Lösungen durchgesetzt. Der Grad der Wiederverwendbarkeit der Software bei der Übertragung einer Systemlösung auf andere Systeme liegt dabei i. d. R. unter 50%. Die operative Steuerung übernimmt die Durchführung der Materialbewegung durch Verknüpfung elementarer Arbeitsschritte wie z. B. Lastaufnahme oder Stellen einer Weiche. In modernen intralogistischen Systemen ist diese Art der Steuerung besonders häufig als sogenannte Speicherprogrammierbare Steuerung (SPS) realisiert (s. DIN 19226-5 und VDI/VDE 3683). Aufgrund hoher zeitlicher Anforderungen wird eine SPS häufig in spezieller Hardware umgesetzt, welche Sensorsignale innerhalb einer festen Zykluszeit zu Stellbefehlen für Antriebe verarbeitet. Die Entwicklung der Steuerungs-Software unterliegt dem internationalen Standard IEC 61131

5  Software-Methoden für die Automatisierung

31

und wird durch eine Vielzahl von industriellen Werkzeugen, wie z. B. CoDeSys™ von 3S oder Siemens STEP 7™, unterstützt. Obwohl sich aktuell die Integration von objektorientierten Ansätzen in den Standard IEC 61131 ankündigt, ist die Entwicklung von SPS-Programmen immer hoch individuell. Insbesondere die dynamische Instanziierung von Objekten wird auch in der nächsten Version des Standards voraussichtlich nicht unterstützt, so dass u. a. die E/A-Konfiguration bereits zur Entwicklungszeit festgelegt werden muss. Daraus folgend sind die entstehenden Programme auf andere Systeme nur mit großem Anpassungsaufwand übertragbar. Die hier vorgestellten Steuerungsaufgaben sowie die entsprechenden SoftwareSysteme lassen sich ebenfalls zu einer Steuerungspyramide (vgl. Kap. 3) zusammenfassen. Zukünftig ist es ein erklärtes Ziel diese Hierarchie abzuflachen und mehr Funktionalität aus den höheren Ebenen in die Nähe der Prozesse zu verlagern. Dabei werden neue Software-Werkzeuge, -Methoden sowie konzeptionelle Lösungen zum Einsatz kommen, die im Folgenden diskutiert werden.

5.2 Anforderungen an neue Software-Methoden Wie bereits in den Kap. 2 und 3 thematisiert, haben sich die Anforderungen an industrielle Automatisierungssysteme insbesondere in der Logistik in den vergangenen Jahren nachhaltig geändert. Ein Hauptanliegen vieler Forscher und Unternehmen bei der Auswahl neuer Software-Methoden und -Werkzeuge ist die Vereinfachung der Systemkomposition und -reorganisation bis hin zur Selbstorganisation. Dadurch sollen agilere Systeme entstehen, die sich aufwandsärmer anpassen und weiterentwickeln lassen. Außerdem gilt es, die Integrationslücken zwischen den verschiedenen Steuerungsprogrammen zu schließen und somit auch die bestehende Schnittstellenproblematik zu lösen (vgl. Kap. 2). Erreicht werden soll dies vor allem durch eine bessere Kapselung von Funktionalität, einer Erhöhung der Wiederverwendbarkeit sowie durch den Einsatz von einheitlichen Schnittstellen. Die Entitäten der neuen Methoden sollen so eingesetzt werden können, dass sie auch ohne genaue Kenntnisse der internen Funktionsweise verwendet und miteinander kombiniert werden können. Weiterhin erfordert die zunehmende Systemkomplexität, dass die Funktionen der monolithischen Software-Blöcke auf mehrere kleinere Blöcke verteilt werden können. Die Entitäten der Methoden müssen also in verschiedenen Ausführungsumgebungen ablaufen können. Die nötige Kommunikation soll über standardisierte Kommunikationsmittel und Protokolle abgewickelt werden, wie beispielsweise Ethernet oder Feldbussysteme. Im Folgenden werden drei interessante Ansätze vorgestellt, die sich zur Umsetzung dieser Anforderungen eignen: Verteilte Automatisierung nach IEC 61499, Serviceorientierte Architekturen und Software-Agenten. Außerdem gibt es noch weitere Ansätze, wie beispielsweise OLE for Process Control (OPC) der Firma Microsoft oder AutomationML (vgl. AutomationML 2009), die jedoch im Zuge dieses Kapitels nicht vorgestellt werden.

32

S. Feldhorst und S. Libert

5.3 Verteilte Automatisierung nach IEC 61499 Ein früher Versuch die Software-Entwicklung von operativen Steuerungssystemen zu modernisieren ist der Standard IEC 61499. Im Gegensatz zu den anderen im Folgenden vorgestellten Ansätzen stammt dieser Standard nicht aus der Software-Technik, sondern aus der klassischen Steuerungs- und Automatisierungstechnik und wurde von der Arbeitsgruppe TC65/WG6 des IEC etabliert. Ziel dieser Arbeitsgruppe war es, die Entwicklung von agileren Automatisierungssystemen zu ermöglichen, in denen Steuerungsalgorithmen aufwandsarm wiederverwendet werden können und die sich im Änderungsfall schnell (re-)konfigurieren lassen (vgl. Christensen 2000). Dazu sollten Ansätze aus den Bereichen der Objektorientierung und verteilter Systeme eingesetzt werden. Als Ergebnis wurde im Jahre 2005 der Standard IEC 61499 veröffentlicht. In diesem Standard sind u. a. eine generische Architektur, verschiedene Referenzmodelle und eine Entwicklungsmethodik enthalten, um ein operatives Steuerungssystem aus wiederverwendbaren Entitäten zusammenzusetzen (vgl. IEC 61499-1, 2006, S. 7). Als zentrale Entitäten kommen sogenannte Funktionsbausteine (kurz: FB) zum Einsatz, welche in der Automatisierung bereits ein etabliertes Konzept darstellen – ähnlich den Klassen aus der Objektorientierung. Sie werden verwendet, um Lösungen für industrielle Automatisierungsaufgaben, wie z. B. die Drehzahlregelung für einen Motor, wiederverwendbar zu kapseln und sind in der SPS-Programmierung nach IEC 61131-3 als eigene Programmiersprache enthalten. Die Entwickler können fertige Funktionsbausteine aus Bibliotheken auswählen und diese ohne genaue Kenntnisse über ihre interne Funktionsweise zusammensetzen. Im Standard IEC 61499 wird dieses Konzept in leicht abgewandelter Form eingesetzt, um es den Systementwicklern zu erlauben, verteilte Steuerungssysteme mit Hilfe von logisch verbundenen Funktionsblöcken zu entwickeln (vgl. Lewis 2001). Anders als in einem klassischen System gibt es in einem verteilten System jedoch keine zentralen Tasks, welche die Abläufe koordinieren. Stattdessen wird nach IEC 61499 zwischen den einzelnen Funktionsbausteinen mit Hilfe von Ereignissen kommuniziert. Jeder beteiligte Funktionsbaustein verfügt deshalb über Ein- und Ausgänge für den Austausch von Ereignissen. Damit bei Bedarf auch weitere Informationen ausgetauscht werden können, hat jeder Funktionsbaustein zusätzlich Einund Ausgänge für den Datenaustausch, welche mit den Ereignissen- und -ausgängen verknüpft werden können. Die logische Verknüpfung von Ein- bzw. Ausgängen zweier Funktionsblöcke wird in Anlehnung an die Netzwerkterminologie auch als Ereignis- bzw. Datenverbindung bezeichnet. Grundsätzlich werden im Standard drei Typen von Funktionsbausteinen unterschieden (vgl. Abb. 5.1): Basisfunktionsbausteine, zusammengesetzte Funktionsbausteine und Dienstschnittstellenfunktionsbaustein. Ein Basisfunktionsbaustein besteht aus einer externen Schnittstelle in Form von Ein- und Ausgängen, einer Ausführungssteuerung und einem oder mehreren gekapselten Algorithmen, die von der Ausführungssteuerung bei Bedarf aufgerufen werden. Die Ausführungssteuerung

5  Software-Methoden für die Automatisierung Event Input

Execution Control Chart

Data Input

33

Event Output

Event Input

Event Output

Data Output

Data Input

Data Output

Algorithms

Internal Data

a

Basis FB

b

Zusammengesetzter FB

Abb. 5.1   Einfache und zusammengesetzte Funktionsbausteintypen (IEC 61499-1, 2006)

kann sowohl textuell als auch graphisch beschrieben werden und gibt den kausalen Zusammenhang von eingehenden und ausgehenden Ereignissen eines Funktionsbausteins an (vgl. IEC 61499-1, 2006, S. 12). Die Algorithmen eines Basisfunktionsbausteins können in den geläufigen IEC 61131-3 Programmiersprachen hinterlegt werden. Wie in Abb. 5.1 dargestellt, werden bei zusammengesetzten Funktionsbausteinen die enthaltenen Algorithmen komplett mit Hilfe von verknüpften Funktionsbausteinen beschrieben. Diese können entweder selbst zusammengesetzt oder ein Basisfunktionsbaustein sein. Um einzelne Funktionsbausteinnetzwerke untereinander, mit anderen Anwendungen oder mit dem technischen Prozess zu verbinden, definiert der Standard zusätzlich sogenannte Dienstschnittstellenfunktionsbausteine. Seit seiner Einreichung wurde der Standard in verschiedenen Forschungsprojekten eingesetzt und untersucht. Neben Demonstratoren wurden verschiedene freie und kommerzielle Entwicklungs- und Laufzeitumgebungen entwickelt, von denen einige mittlerweile ausgereift sind und produktiv eingesetzt werden können.

5.4 Serviceorientierte Architekturen Der Begriff der Serviceorientierten Architekturen (kurz: SOA) ist eine feste Größe in der Welt der Software-Technik und wird dort insbesondere als Werkzeug für die Entwicklung von flexiblen, verteilten Anwendungslandschaften verstanden, die mit geringerem Aufwand angepasst und erweitert werden können. Hinter einer SOA verbirgt sich jedoch zunächst keine konkrete Technologie oder Programmiersprache, sondern ein abstraktes und technologieunabhängiges Architekturmuster. Die zentralen Bausteine einer SOA sind sogenannte Dienste. Ein Dienst kapselt eine festdefinierte Leistung, die als Element in größeren Verarbeitungsabläufen

34

S. Feldhorst und S. Libert

(engl. workflows) genutzt werden kann (vgl. Richter et al. 2005). Um seine fachliche Funktionalität für andere nutzbar zu machen, hat jeder Dienst eine eindeutig formulierte und maschinenlesbare Schnittstelle. Innerhalb einer SOA sind alle Teilnehmer Software-Entitäten, so dass auch menschliche Nutzer durch Software-Entitäten (z. B. Client-Anwendungen) vertreten werden. Die einzelnen Teilnehmer einer SOA nehmen stets eine oder mehrere der folgenden Rollen ein: Dienstanbieter, Dienstnutzer oder Dienstvermittler (vgl. Melzer et al. 2007). Anhand dieser Rollen lassen sich die grundlegenden Abläufe und Interaktionen in einer SOA nachvollziehen. Damit ein Dienstnutzer einen Dienst auffinden kann, veröffentlicht jeder Anbieter seine Dienste beim sogenannten Vermittler. Aufgabe des Vermittlers ist es, Anbieter und Nutzer, die nur lose miteinander gekoppelt sind, zusammenzubringen. Will ein Dienstnutzer für einen benötigten Dienst einen Anbieter finden, wendet er sich deshalb an den Vermittler. Der Vermittler durchsucht dann die Liste der bekannten Dienste nach einem verfügbaren Anbieter und teilt das Ergebnis dem anfragenden Nutzer mit. Anschließend kann die sogenannte Dienstbindung zwischen Anbieter und Nutzer durchgeführt werden. Dabei tauschen beide eine formale Dienstbeschreibung und evtl. Richtlinien (engl. policies) bezüglich der Dienstnutzung aus. Ist die Dienstbindung erfolgreich, kann der Dienst genutzt werden. Jede Aktion in einer SOA ist mit Kommunikation verbunden und der Einsatz von standardisierten Verfahren und Protokollen deshalb unabdingbar. Ein Blick hinter die Kulissen offenbart weshalb sich eine SOA für die Entwicklung von flexiblen Systemen eignet. In einer SOA werden die drei bekannten Entwurfsprinzipien aus der Software-Technik geschickt miteinander kombiniert: Kapselung, lose Kopplung und Verteilung. Um Abhängigkeiten zwischen Komponenten einer SOA zu verringern, kapseln Dienste ihre abstrakte Funktionalität hinter einer Schnittstelle. Jeder Dienst, der eine gewisse Schnittstelle anbietet, verpflichtet sich implizit die mit dieser verbundenen Funktionalität zu erbringen. Durch dieses Prinzip, das auch als Information Hiding bezeichnet wird, bleiben Umsetzungsdetails eines Dienstes für den Nutzer verborgen. Ein Austausch verschiedener Dienstimplementierungen ist also ohne Anpassungen beim Nutzer möglich. Weiterhin sind Anbieter und Nutzer nur lose miteinander gekoppelt, d. h. welcher Anbieter mit welchen Nutzern interagiert, stellt sich idealerweise erst zur Laufzeit einer Anwendung heraus. Ferner stellen Anbieter und Nutzer verteilte Anwendungsbausteine dar, sprich sie sind als eigenständige Prozesse realisiert, die miteinander kommunizieren. Die Kommunikation erfolgt dabei mit Hilfe von standardisierten, offenen Protokollen. Durch die Verteilung sind die Bausteine einer SOA nicht an eine bestimmte Programmiersprache oder ein Betriebssystem gebunden. Diese Eigenschaft begünstigt insbesondere den Aufbau von unternehmensübergreifen Anwendungslandschaften, da jede Partei mit den von ihnen favorisierten Werkzeugen arbeiten kann. Weiterhin ist es möglich, Dienste zu Hierarchien zusammenzuschließen und so neue Dienste auf Basis von bereits vorhandenen zu entwickeln (s. Abb. 5.2). Ist für eine Unternehmung eine Dienstlandschaft aufgebaut, können die Geschäftsprozesse als Folge von Dienstnutzungen umgesetzt werden. Die Festlegung des genauen

5  Software-Methoden für die Automatisierung Abb. 5.2   Beispiel einer einfachen Diensthierarchie

3. Ebene

35

Routensuche mit Stauumfahrung

2. Ebene

Routensuche

1. Ebene

Kartendienst

(elementare Dienste)

Staumeldungen

Ablaufs eines Geschäftsprozesses aus Dienstaufrufen wird in der SOA-Welt auch als Orchestrierung bezeichnet. Für die Umsetzung einer SOA stehen verschiedene Technologien zur Auswahl. Die Technologie, welche in der Praxis den größten Zuspruch genießt, sind Web Services (WS). Web Services umfassen eine Vielzahl von Spezifikationen und Standards für die Umsetzung unterschiedlichster Aufgaben innerhalb einer SOA. Als Basis für die WS-Kommunikation dient das Protokoll SOAP, welches zum Austausch von strukturierten Informationen in verteilten Systemen konzipiert wurde (s. Gudgin et al. 2003). Neben Web Services existieren noch weitere Technologien, wie CORBA, Microsoft’s COM/DCOM oder Java RMI, die sich ebenfalls zum Aufbau einer SOA eignen.

5.5 Software-Agenten und Agentensysteme Der Agentenansatz stammt aus dem Gebiet Verteilter Künstlicher Intelligenz (vgl. Russell u. Norvig 2004; Weiß 1999) und hat in den letzten Jahren zunehmend Bedeutung in der Software-Technik erlangt (vgl. Bussmann et al. 2004; Wagner et al. 2003; Parunak 1998). Analog zur objektorientierten Software-Entwicklung wird hier über eine agentenorientierte Software-Entwicklung gesprochen (AOSE) (vgl. Bermon et al. 2005). Die agentenorientierte Software-Entwicklung bietet gegenüber den herkömmlichen Methoden einen besseren Umgang mit der Systemkomplexität. Dabei erfolgt die Dekomposition eines komplexen Problems in einzelne autonome Prozesse (Software-Agenten), die durch einheitliche Schnittstellen lose gekoppelt kommunizieren, voneinander unabhängig entwickelt werden können und deswegen leicht austauschbar sind. Ursprünglich wurde das Agentenkonzept zur Beschreibung von Akteuren in einem verteilten System zur Informationsverarbeitung verwendet (vgl. Hewitt 1977). Agenten kapseln ihren Zustand und Verhalten ähnlich wie Objekten in der objektorientierten Software-Entwicklung. Im Gegensatz zu den Objekten kann ein Agent sowohl reaktiv als auch proaktiv handeln und weist darüber hinaus autonomes aber auch soziales Verhalten auf (Woolridge u. Jennings 1995): In einem Agentensystem treten Agenten in eine Wechselwirkung miteinander und versuchen dabei, individuelle Ziele zu erreichen oder Abhängigkeiten untereinander zu handhaben.

Konventionell Änderungen an einem Systemelement haben Auswirkungen auf das Gesamtsystem

S. Feldhorst und S. Libert

Ausführungssequenz

36

Agentenorientiert

Unabhängigeres Hinzufügen, Entfernen und Ändern von Systemelementen

Abb. 5.3   Änderbarkeit eines Agentensystems in Anlehnung an (Parunak 1998) und (Wagner et al. 2003)

Die oben genannten Agenteneigenschaften machen Agenten zu einem hilfreichen Analyse- und Entwurfswerkzeug für viele praktische und industrielle Problemfelder wie z. B. die Steuerung von Materialflüssen in logistischen Anlagen. Ein effizienter Einsatz von Agenten in der Praxis ist allerdings erst dann möglich, wenn das Problemfeld gewisse Merkmale aufweist. Dazu zählen u. a. Modularität, Dezentralisierung, Änderbarkeit und Komplexität (vgl. Parunak 1998). Diese Merkmale können auch als Anforderungen an das zu entwickelnde Systems formuliert werden. Besondere Vorteile bietet der Agentenansatz, wenn ein System während seines Lebenszyklus stetig Änderungen unterworfen ist. So können beispielsweise in einem Materialflusssystem Modifikation von Betriebsstrategien, Ergänzung von Systemkomponenten oder sogar Erweiterungen der Systemtopologie, nötig sein. Die Modularität der Steuerung allein reicht in diesem Fall nicht aus, um die erforderlichen Anpassungen zu unterstützen. In zentral organisierten Steuerungssystemen mit einem Hauptkontrollfluss kann der Austausch eines Softwaremoduls die Funktionsfähigkeit weiterer Module beeinträchtigen. In einem dezentralen Agentensystem kann dagegen der Modulaustausch mit geringerem Aufwand und Risiko durchgeführt werden (vgl. Abb. 5.3). Bei der Realisierung von Agentensystemen können Entwickler auf verschiedene Methoden und Werkzeugen zurückgreifen (vgl. Weiß 2002; Woolridge u. Ciancarini 2001). Eine wichtige Untermenge von diesen Werkzeugen bilden Entwicklungs- und Laufzeitumgebungen für Software-Agenten (vgl. Telecom Italia Lab 2009; Emorphia Ltd. 2009; Tryllian 2009). Um den Entwicklungsprozess zu vereinheitlichen und die Interoperabilität von Agenten in einem System auch systemübergreifend zu unterstützen, wurden mehrere Spezifikationen und Standards erarbeitet. Die bedeutungsvollsten sind dabei die Spezifikationen, die von der Foundation for Intelligent Physical Agents (FIPA) entwickelt werden (s. Foundation for Intelligent Physical Agents 2009), wie z. B. die Agent Communication Language (FIPA-ACL).

5.6 Fazit Der Bereich Software ist und bleibt ein wichtiger Innovationssektor in der Automatisierung industrieller Anlagen, speziell in der Steuerung von Materialflüssen. Es stehen einige vielversprechende Ansätze zur Auswahl, um die Systementwicklung und -wartung in den kommenden Jahren zu verbessern.

5  Software-Methoden für die Automatisierung

37

Die in diesem Kapitel vorgestellten Ansätze zeigen ein hohes Innovationspotenzial und weisen dabei bestimmte Gemeinsamkeiten auf. Sie kapseln Funktionalität in wiederverwendbaren Entitäten, wie Funktionsbausteinen, Diensten oder Agenten. Ihre Interna verbergen sie dabei hinter einer einheitlichen Schnittstelle und erhöhen so den Grad der Wiederverwendbarkeit. Weiterhin unterstützen alle Ansätze die Modellierung komplexer Systeme in Form von Funktionsbausteinnetzen, Diensthierarchien oder Multiagentensystemen und bieten die Möglichkeit die Entitäten auf verschiedene Ausführungsumgebungen zu verteilen. Dazu setzen alle auf standardisierte Kommunikationsmittel und -protokolle, wie Feldbussysteme, Ethernet, SOAP oder FIPA-ACL. Der Standard IEC 61499 baut auf bewerte Konzepte aus der Automatisierungstechnik. Dazu gehören u. a. Funktionsblöcke, SPS-Programmiersprachen und Feldbussysteme. Dies sollte für eine bessere Akzeptanz seitens der Entwickler sorgen, welche den Umgang mit SPS-Programmiersprachen und Feldbussystemen gewohnt sind. Auf der anderen Seite ist dieser Standard recht komplex, was die Einarbeitung erschwert. SOA und Agenten dagegen sind zwar beide nicht auf die Anwendungsdomäne spezialisiert, stellen aber trotzdem vielversprechende Ansätze dar. Der Vorteil von SOA liegt zum einen in dem einfachen Grundkonzept und zum anderen darin, dass dieses Konzept in vielen Unternehmen bereits auf den höheren Ebenen eingesetzt wird. Dadurch ergibt sich die Möglichkeit innerhalb und zwischen den Unternehmen eine durchgängige IT-Struktur aufzubauen, von den abstrakten Geschäftsprozessen bis hin zu den Geräten der Produktionsstätten. Nachteil einer SOA ist jedoch, dass sie nicht auf die Einhaltung von Echtzeitschranken ausgelegt ist, und jede weitere Ebene der Diensthierarchie die Entscheidungsfindung verlangsamt. Die Stärken von Agenten liegen in der Autonomie der einzelnen Systemteilnehmer und in der Unterstützung des Entwicklungsprozesses durch Software-Methoden (AOSE). Die Hauptherausforderung besteht dabei in der Anpassung agentenbasierter Methoden an die konkrete Anwendungsdomäne. Das Problem der einheitlichen Kommunikationsschnittstellen kann in Agentensystemen mit FIPA-ACL gelöst werden. Eine technologische Umsetzung wird dafür allerdings nicht festgelegt, was die Realisierung einer systemübergreifenden Kommunikation erschwert. Ein denkbarer Lösungsansatz hierfür wäre eine Kombination von Agenten mit einer SOA-Technologie, wie z. B. Web Services. Zusammenfassend kann festgehalten werden, dass die vorgestellten Ansätze dabei helfen können, viele der aktuellen Problemstellungen in der industriellen Automatisierung und somit auch in der Materialflusssteuerung zu lösen. Zuvor muss ihre Einsetzbarkeit im industriellen Rahmen weiter erprobt werden, wobei die bereits bestehenden Systeme die Maßstäbe in puncto Stabilität und Leistungsfähigkeit setzen.

Teil II

Das Internet der Dinge

Kapitel 6

Die Vision vom Internet der Dinge Willibald A. Günthner, Razvan Chisu und Florian Kuzmany

6.1  Einleitung Die Anforderungen an innerbetriebliche Materialflusssysteme haben sich in den letzten Jahren stark geändert und stellen automatisierte Systeme vor immer schwierigere Herausforderungen. Auf der Seite der Materialflusssteuerung kann dabei auch eine gewisse Weiterentwicklung beobachtet werden: Der Trend geht hin zur dezentralisierten Verarbeitung von Sensorsignalen und der Gestaltung leicht wiederverwendbarer und austauschbarer Softwarekomponenten. Dabei ist das grundlegende Modell aber das selbe geblieben: Ein oder wenige Materialflussrechner übernehmen die Steuerung aller logistischen Prozesse eines Systems, die Verarbeitung echtzeitkritischer aber logisch nicht sehr komplexer Aufgaben wird auf eine überschaubare Anzahl SPS verteilt. Diese zentrale Steuerungspyramide ist aber wegen der hohen Komplexität ihrer Komponenten und der sehr anwendungsspezifischen Programmierung zu unflexibel und schwer zu handhaben. Daher ist auch die Logistik gezwungen, denselben Weg zu gehen wie vor vielen Jahren schon die Informatik: zentrale Systeme müssen durch ein kooperierendes Netzwerk kleinskaliger Einheiten ersetzt werden. Diese müssen möglichst weit standardisiert werden und beliebig kombinierbar sein, um transparente Systeme mit geringem Aufwand realisieren und umbauen zu können. Als konzeptionelles Vorbild kann dabei das Internet herangezogen werden, die technologischen Grundlagen sind in Form von dienstorientierten oder agentenbasierten Architekturen bereits in der IT vorhanden. So entsteht ein Materialflusssystem, das dem Prinzip nach wie ein Computernetzwerk funktioniert: Intelligente Infrastruktur stimmt sich mit Transporteinheiten ab und realisiert ein dezentrales, kooperatives und beliebig veränderbares Transportnetzwerk. Dieses „Internet der Dinge“ hat gegenüber herkömmlichen Steuerungsansätzen viele Vorteile und bietet einen Ausweg aus der Komplexitätsfalle, der W. A. Günthner () Lehrstuhl für Fördertechnik Materialfluss Logistik fml, Technische Universität München Boltzmannstr. 15, 85748 Garching, Deutschland e-mail: [email protected] W. Günthner, M. ten Hompel (Hrsg.), Internet der Dinge in der Intralogistik, DOI 10.1007/978-3-642-04896-8_6, © Springer-Verlag Berlin Heidelberg 2010

41

42

W. A. Günthner et al.

heutige Materialflusssysteme immer mehr ausgeliefert sind. Den Ausgangspunkt bildet dabei eine konsequente Modularisierung. Auf der Ebene mechanischer Komponenten wird diese von Herstellern schon seit vielen Jahren verfolgt, denn Förderer, Weichen und Drehtische sind Standardkomponenten, die sehr oft in gleicher oder sehr ähnlicher Ausführung eingesetzt werden. So sind von vielen Anbietern Baukastensysteme erhältlich, aus denen sich ein Materialflusssystem recht einfach aufbauen lässt. Dabei werden solche Modularisierungsansätze jedoch nicht auch auf die Softwarearchitektur der Steuerung angewandt. Denn trotz mechanischer Module werden auch im modernsten Logistiksystem die Entscheidungen von einem zentralen, hoch komplexen und damit schwer beherrschbaren Materialflussrechner getroffen. Komplexe Strukturen mit den sich zwangsläufig ergebenden Schnittstellen sind ein erhebliches Risiko für Funktion, Gestehungskosten und Betriebskosten eines Intralogistiksystems (vgl. Forum Intralogistik VDMA 2006). Der Fokus des Internets der Dinge liegt daher auf einer modularen und dezentralen Steuerungslogik. Diese verteilte Systemarchitektur wird Anlagenbauer in die Lage versetzen, Materialflusssysteme nach dem „Plug & Play“ Prinzip zu erstellen und den Aufwand für Planung, Realisierung, Inbetriebnahme und Umbau somit drastisch senken. Auch Anlagenbetreiber werden davon profitieren, indem Funktionskomponenten bzw. Module verschiedener Hersteller dank standardisierter Schnittstellen problemlos integriert und gegeneinander ausgetauscht werden können.

6.2  Das Internet als Vorbild Das Internet als weltumspannendes Netzwerk, das täglich viele Milliarden Transporteinheiten in Form von Datenpaketen befördert, soll dabei als Vorbild dienen. Seit seinen Anfängen in den 70er Jahren hat sich das Internet vor allem auch durch den WWW-Boom der 90er Jahre zu einer globalen Infrastruktur entwickelt, die immer noch rasant wächst. Und obwohl oder gerade weil dieses „Netzwerk aus Netzwerken“ gänzlich auf zentrale Instanzen verzichtet, ist es hochgradig robust und skalierbar. Die Intralogistik der Zukunft wird daher ebenso wie das Internet dezentral und hierarchielos sein, Materialflussrechner oder verschiedene Steuerungsebenen werden überflüssig. Behälter und Pakete werden autonom und steuern sich selbst zum Ziel, intelligente Förderstrecken und Fahrzeuge setzen dabei die Transportaufträge um. Alle Akteure reagieren auf ihre Umgebung und können sich so an schwankende Auftragslasten oder Ausfälle automatisch anpassen. Dabei soll eine Entwicklung aufgegriffen werden, die zahlreiche Antriebs- und Steuerungshersteller bereits seit einiger Zeit voran treiben. Immer mehr Intelligenz wandert von der SPS, die früher noch ganze Anlagenbereiche steuerte, auf die Feldebene eines Materialflusssystems. So besitzen viele Frequenzumrichter, Elektroantriebe oder Auto-ID-Lesegeräte programmierbare Microcontroller, auf denen

6  Die Vision vom Internet der Dinge

43

eigener Code installiert werden kann. Kleine und kostengünstige Embedded PC bieten die Möglichkeit, Steuerungslogik direkt an den Ort des Geschehens zu verlagern. Viele dieser Komponenten verfügen bereits über Ethernet-Schnittstellen, so dass einer Kommunikation via TCP/IP nichts im Wege steht. So wird es erstmals möglich, das bisherige Baukastenmodell von der Elektrik und Mechanik auch auf die Steuerungstechnik zu erweitern. Diese mechatronische Gestaltung kann zur Entwicklung autonomer Funktionseinheiten verwendet werden. Durch die technologischen Fortschritte im Bereich RFID lässt sich aber nicht nur die Steuerungssoftware und damit die Entscheidungskompetenz dezentralisieren, sondern auch die Datenhaltung. Klassisch wird RFID nur zur Identifikation einzelner Transporteinheiten verwendet. Alle übrigen Informationen werden aus zentralen Datenbanken abgerufen. Doch die Speicherkapazitäten heute erhältlicher RFID-Tags erlauben bereits einen ersten Schritt vom Data-On-Network- hin zum Data-On-Chip-Prinzip. Dabei werden alle zu einer Transporteinheit gehörenden Daten, neben der eindeutigen Identifikationsnummer also auch Informationen über das Transportziel oder den Inhalt und die geometrische Form des Behälters, direkt auf dem mitgeführten RFID-Tag hinterlegt. Diese direkte Kopplung des Informations- und Warenflusses verringert die Kommunikation im System und die Datenredundanz. Durch den Einsatz intelligenter Transporteinheiten rücken dezentral gesteuerte, innerbetriebliche Materialflüsse immer näher an die Funktionsweise des Internets heran. Aufgaben wie die Wegberechnung, die Wegreservierung, die Stauvermeidung und das Schalten von Wegelementen (zum Beispiel Weichen) werden im Internet der Dinge dezentral und selbstständig von den Materialflussmodulen übernommen. Ein übergeordnetes Leitsystem ist damit nicht mehr erforderlich (s. Abb. 6.1).

Abb. 6.1   Das Internet der Dinge ist ein hierarchieloses Materialflusssystem aus autonomen, intelligenten und kooperierenden Einheiten. Jede Einheit übernimmt Aufgaben aus allen Ebenen heutiger Steuerungshierarchien

44

W. A. Günthner et al.

6.3  Paradigmenwechsel in der Intralogistik Das Internet der Dinge erfordert eine tiefgreifende Veränderung der Steuerungsarchitektur von Materialflussanlagen und auch der Denkweise der Anlagenbauer und –programmierer. Denn durch die Abschaffung aller hierarchischen Strukturen müssen für die meisten Probleme neue Lösungen erarbeitet werden – an die Stelle zentral und fest einprogrammierter Abläufe und Strategievorgaben treten dezentrale Verhaltensregeln und Kooperationsmechanismen. Ein Mal entwickelt, führen diese zwar zu einer stark vereinfachten Realisierung der Materialflusssteuerung, jedoch ist der Aufwand für die erstmalige Implementierung dieser Konzepte beträchtlich. Dies liegt zum Teil in der Natur der Autonomie und Kooperation. Das viel größere Hindernis ist jedoch die neue Herangehensweise an die Probleme der Intralogistik: Der gewohnte Blick aus der Perspektive des allwissenden Materialflussrechners, verknüpft mit der allgemeinen und alleinigen Befehlsgewalt ist nicht mehr möglich. An seine Stelle treten die Möglichkeit und die Flexibilität, sich in kurzer Zeit und mit niedrigen Kosten an schwankende Anforderungen und neue Umweltbedingungen anzupassen. Dadurch verändert sich der gesamte Lebenszyklus einer Anlage – Arbeiten und Aufwände verlagern sich, Realisierungsund Inbetriebnahmeprozesse müssen neu gestaltet werden, neue Möglichkeiten zur Planung entstehen.

6.4  Ausblick Die folgenden Kapitel liefern detaillierte Informationen über die technische Gestaltung des Internet der Dinge und erläutern den Einfluss dieser neuen Technologie auf Realisierungs- und Inbetriebnahmeprozesse sowie auf den gesamten Lebenszyklus eines Intralogistiksystems. Diese theoretischen Grundlagen werden anhand konkreter Umsetzungsszenarien aus Industrie und Forschung veranschaulicht und weiter verdeutlicht. Diese Kombination ausgereifter Konzepte und erster technischer Realisierungen zeigt, dass die Vision vom sich selbst steuernden Materialfluss in greifbare Nähe gerückt ist. So wie das Internet unseren täglichen Umgang miteinander und mit der Welt revolutioniert hat, so wird auch das Internet der Dinge einen entscheidenden Wandel in die Logistik bringen. Diese neue Denkweise in der Logistik ist für die Zukunftsfähigkeit dieser Branche nicht nur absolut erforderlich, sondern sie beginnt bereits, konkrete Gestalt anzunehmen.

Kapitel 7

Echtzeitanforderungen der Materialf lusssteuerung Sergey Libert und Moritz Roidl

Eine durchgängige und übergreifende Betrachtung von dezentralen Systemen für die Materialf lusssteuerung erfordert auch eine Berücksichtigung der Echtzeitanforderungen. Ein Echtzeitverhalten setzt die Reaktion eines Systems auf ein äußeres Ereignis in vorbestimmter Zeit voraus. Für das Steuerungsprogramm gilt in diesem Fall: Prozessdaten, Systeminformationen und Benutzereingaben müssen schritthaltend mit dem angeschlossenen technischen Prozess verarbeitet werden. Vorausgesetzt wird dabei sowohl die Gleichzeitigkeit der Bearbeitung als auch die Rechtzeitigkeit der Reaktion auf Benutzeranforderungen (vgl. ten Hompel et al. 2007). Die Echtzeitanforderungen werden im Allgemeinen in weiche und harte Echtzeitanforderungen unterteilt. Unter weichen Echtzeitbedingungen arbeitet ein System i. d. R. alle Ereignisse schnell genug ab. Signifikante Abweichungen werden bis zu einem geringen Prozentsatz toleriert, was bedeutet, dass ihr Auftreten zwar unwahrscheinlich aber möglich ist. Die Konsequenz einer signifikanten Abweichung darf jedoch nicht die Gesamtfunktionalität des Systems bedrohen. Sollte dies der Fall sein, dann arbeitet das System unter harten Echtzeitanforderungen. Die Überschreitung jeder Zeitschranke wird als Fehler gewertet. Die Erfüllung von Echtzeitanforderungen ist eine unabdingbare Voraussetzung bei der Entwicklung von Materialf lusssystemen und deren Steuerungen. Es ist die Basis für die Sicherstellung der Leistung der gesamten Materialf lussanlage. Im Folgenden sollen hier zwei grundsätzliche Problemstellungen betrachtet werden: • Echtzeitanforderungen auf der System- bzw. Auftragsebene und • Echtzeitanforderungen auf der Komponenten- bzw. Prozessebene

S. Libert () Lehrstuhl für Förder- und Lagerwesen, Technische Universität Dortmund Emil-Figge-Str. 73, 44221 Dortmund, Deutschland e-mail: sergey.libert@f lw.mb.tu-dortmund.de W. Günthner, M. ten Hompel (Hrsg.), Internet der Dinge in der Intralogistik, DOI 10.1007/978-3-642-04896-8_7, © Springer-Verlag Berlin Heidelberg 2010

45

46

S. Libert und M. Roidl

7.1 Echtzeitanforderungen auf der Systemebene Bei der Entwicklung, Konstruktion oder Auswahl von Komponenten eines Materialf lusssystems steht die schnelle Ausführung der logistischen Funktion deutlich im Vordergrund. Diese lässt sich formal durch die technische Grenzleistung ausdrücken, deren Berechnungsverfahren für stetige und unstetige Elemente eines automatisierten Materialf lusssystems in der Fachliteratur ausführlich beschrieben sind (vgl. Gudehus 1975a, b, c; Großeschallau 1984). Werden die Komponenten zu einem komplexen System vernetzt, so hängt die Leistung des gesamten Systems von der Grenzleistung der einzelnen Komponenten und den Abfertigungsstrategien an den Stationen und Entscheidungsstellen ab. Die Leistung des gesamten Materialf lusssystems wird dabei oft durch die Kenngrößen Durchsatz und Durchlaufzeit charakterisiert. Der Durchsatz in einem Fördersystem wird im Allgemeinen als Fördermenge definiert, die innerhalb einer bestimmten Zeiteinheit die betrachtete Stelle des Systems passiert. Bei der Gesamtsystembetrachtung ist diese die mittlere Menge von Aufträgen, die in einer Zeiteinheit bearbeitet werden (vgl. VDI 3978; Großeschallau 1984; Gudehus 1999). Die Durchlaufzeit dagegen bezieht sich auf einzelne Aufträge und bezeichnet in einem Materialf lusssystem die Zeit, die ein individueller Auftrag zur Bearbeitung benötigt. Die auftragsbezogene Durchlaufzeit kann als Reaktionszeit des Materialf lusssystems beim Eintritt eines Transportauftrags interpretiert werden. Materialf lusssysteme werden im Ablauf der Planung regelmäßig auf den Durchsatz optimiert. Aufgabe der Materialf lusssteuerung ist somit, einen höchstmöglichen Durchsatz zu erbringen. Diese Optimierung wird häufig zu Lasten der einzelnen Durchlaufzeiten erreicht. Das Steuerungsziel – den Durchsatz zu maximieren – vernachlässigt zu Gunsten des Kollektivs das Individuum. Bei dieser Zielsetzung werden einige Aufträge mit einer großen Verspätung ans Ziel kommen. Weder harte noch weiche Echtzeitanforderungen können so garantiert werden. Für die Realisierung echtzeitfähiger Logistiksysteme müssen diese Ausreißer vermieden werden.

7.2 Echtzeitanforderungen auf der Komponentenebene So wie das technische System aus einzelnen Komponenten besteht, die räumlich und/oder funktionell verteilt sind, lässt sich auch sein Verhalten in eine große Zahl abgrenzbarer Prozesse aufteilen (vgl. Steusloff 2003). Die Kopplung der Prozesse entspricht einer Kommunikation zwischen den Systemkomponenten. Der Begriff der Kommunikation ist dabei im Sinne der Systemtheorie als Austausch von Materie, Energie und Information zu verstehen, was eine formalisierte Prozessbeschreibung ermöglicht (vgl. VDI 3682). In den Materialf lusssystemen liegt der Austausch der Materie in Form eines Materialf lusses vor. Analog zu dem Materialf luss

7  Echtzeitanforderungen der Materialf lusssteuerung

47

werden auch die Begriffe Energief luss und Informationsf luss bzw. Informationsstrom verwendet. Ein wichtiger Teil des intralogistischen Systems ist die Materialf lusssteuerung, die auch für die Verarbeitung der Informationsströme zuständig ist. Von der Richtigkeit und Effizienz dieser Steuerung hängt ab, ob die technischen Prozesse korrekt ablaufen und somit das gesamte Materialf lusssystem seine Funktion erfüllt. Bei einem Materialf luss handelt es sich um einen zeitkritischen Prozess. Die mit dem Prozess verknüpfte Steuerung muss also ihre Aufgabe rechtzeitig vollziehen. Diese Rechtzeitigkeit wird oft Echtzeitfähigkeit der Steuerung genannt (vgl. Halang et al. 1996). Ein qualitativer Zusammenhang zwischen einem technischen Prozess und seiner Steuerung ist in folgendem Dualprinzip formuliert (Heger et al. 1979): Technische Prozesse bestehen aus Teilprozessen, die parallel zueinander ablaufen und miteinander kommunizieren durch Austausch von Materie und/oder Energie. Ein System zur Automatisierung solcher Teilprozesse besteht aus mindestens derselben Anzahl von Rechenprozessen, die mit den jeweiligen Teilprozessen direkt kommunizieren (Sensoren, Aktoren) und untereinander in derselben Weise vernetzt sind, wie die technischen Teilprozesse.

Dieses Dualprinzip verdeutlicht, dass die Realisierung einer echtzeitfähigen Steuerung durch die Parallelität der Prozesse und die Vernetzung der Komponenten erschwert ist (vgl. Libert et al. 2008). Das Problem kann anhand der Abfertigung eines Stückguts an einer Verzweigung in einem Stetigfördersystem demonstriert werden. Nach der Erkennung eines Stückguts bei der Auffahrt zu einer Weiche wird dieses mittels eines Auto-Id-Gerätes identifiziert. Für das erfasste Stückgut wird eine Weganweisung aus einer Datenbank gelesen bzw. eine neue Route berechnet. Nähert sich das Stückgut dem Verzweigungspunkt, so wird der Weichenantrieb eingeschaltet. Die Verarbeitung der Prozessdaten in der Steuerung benötigt eine gewisse Zeit, die sich aus vielen zeitlichen Faktoren zusammensetzt. Diese Faktoren sind beispielsweise die Latenzzeiten der Sensoren, die Dauer des Zugriffes auf persistierte Daten, die Dauer der Datenübertragung zwischen einer speicherprogrammierbaren Steuerung und einem Materialf lussrechner sowie viele andere. Im Fall eines kontinuierlichen Betriebs der Fördertechnik braucht das Stückgut vom Detektions- und Identifikationspunkt bis zu der Weiche eine Zeit, die durch die Physik des Förderers vorgegeben ist (vgl. ten Hompel et al. 2007). Die Steuerungsentscheidung muss innerhalb dieses Zeitraums unter Berücksichtigung der Latenzzeiten der Technik gefallen und umgesetzt sein. Dieses Zeitintervall lässt sich oft durch eine Verschiebung des Identifikationspunktes oder eine Geschwindigkeitsänderung anpassen, was eine Rückwirkung auf den Durchsatz und das Verhalten des Gesamtsystems hat. Das dargestellte Szenario zeigt, dass die Echtzeitfähigkeit von vielen steuerungs- und materialf lusstechnischen Faktoren abhängt. Die Gewährleistung der Echtzeitfähigkeit in der Praxis erfordert die Erstellung aufwändiger Emulationsmodelle für Komponenten sowie zusätzlich viel Erfahrung und zeitintensive Feinjustierung während der Anlagen­ inbetriebnahme.

48

S. Libert und M. Roidl

7.3 Aspekte von Echtzeitanforderungen in multiagentengesteuerten Materialf lusssystemen Die oben genannten Echtzeitanforderungen gelten für zentral wie dezentral gesteuerte Systeme. Im Fall der dezentralen Steuerung muss jedoch zusätzlich die Auswirkung zeitverzögerter Kommunikation betrachtet werden. Prozesse treffen einerseits gleichzeitig Entscheidungen und gleichen andererseits fehlende Information durch Nachrichtenaustausch aus. Dazu kommt, dass durch die zeitverzögerte Nachrichtenübertragung kein Prozess ein sicheres Abbild des globalen Systems erwarten kann. Für einige dezentrale Varianten von üblichen Algorithmen in Materialf lusssystemen hat dieser Umstand Auswirkungen auf das Verhalten unter Echtzeitanforderungen. Als Beispiel sei hier der bekannte Algorithmus von Dijkstra genannt. In seiner dezentralen Variante wird das System vom Quellprozess aus mit Nachrichten entlang der physikalischen Komponenten gef lutet. In den einzelnen Nachrichten, welche die möglichen Routen repräsentieren, wird die Transportzeit summiert. Der Zielprozess kann somit jederzeit die kürzeste Route aus allen bisher eingetroffenen Nachrichten auswählen. Das Problem besteht darin, dass ohne ein agentenübergreifendes Wissen, der Zielprozess zu keinem gegebenen Zeitpunkt entscheiden kann, ob die letzte Nachricht schon angekommen ist. Er weiß somit niemals genau, ob die Nachricht mit der kürzesten Route schon eingetroffen ist. Eine praktikable Lösung bietet ein Timeout, der sicherstellt, dass der Zielprozess nach einer bestimmten Zeitspanne abbricht. Ist diese Zeitspanne gut gewählt, hat die Nachricht mit der kürzesten Route in den meisten Fällen den Zielprozess schon erreicht. Grundsätzlich betrifft der Aspekt der zeitverzögerten Kommunikation alle Protokolle in Multiagentensystemen, die versuchen einen agentenübergreifenden Informationsaustausch herzustellen. Durch die Einführung von Timeouts kann möglichen Problemen mit der Erfüllung von Echtzeitanforderungen entgegengewirkt werden. Dies wird jedoch zum Preis erhöhter algorithmischer Komplexität und durch die Einführung nicht deterministischen Verhaltens erkauft. Im Allgemeinen wird ein längerer Timeout ein Ergebnis liefern, das dem eines zentralen Algorithmus gleicht. Längere Zeitspannen für den Timeout lassen sich natürlich nicht immer umsetzen. Sei der oben beschriebene Fall angenommen und das Fördergut befindet sich in der Auffahrt zu einer Weiche. Dann bleibt nach der Identifikation oft nur eine sehr kurze Zeitspanne zur Entscheidung, die Möglichkeiten einen Timeout zu setzen sind also beschränkt. Betrachtet man jedoch den gesamten Durchlauf eines Förderobjekts durch das System, dann verbraucht die physikalische Bewegung wesentlich mehr Zeit als die Kommunikation zwischen einzelnen Prozessen. Für den Entwurf von dezentralen Algorithmen kann dieser Umstand ausgenutzt werden: Wissen sollte während des physikalischen Transports durch dezentrale Kommunikation im Voraus generiert werden, solange genug Zeit vorhanden ist. Dieses Wissen kann dann an Entscheidungsstellen lokal zwischengespeichert werden, so dass eine sehr schnelle lokale Reaktion möglich ist.

7  Echtzeitanforderungen der Materialf lusssteuerung

49

Zusammenfassend lässt sich sagen, dass gerade die Trennung von autonomen Entitäten, die lokale Datenhaltung und die genau definierte Kommunikation wie sie in der Modellierung von Multiagentensystemen angestrebt wird, die Modellierung von Echtzeitanforderungen erleichtert.

Kapitel 8

Die Bausteine des Internet der Dinge Florian Kuzmany, Artur Luft und Razvan Chisu

8.1  Motivation und Anforderungen Eine der Grundlagen sowohl für die technologische Entwicklung als auch für den wirtschaftlichen Erfolg des Internets der Dinge ist ein Modularisierungskonzept, das die angestrebte Verlagerung von Logik in die unteren Anlagenteile und damit die Abflachung oder gar Abschaffung von Steuerungshierarchien ermöglicht. Der Gedanke der Modularisierung und der Einsatz von Baukastensystemen, vor allem bezüglich der mechanischen Gestaltung von Fördertechnik, wird von Herstellern bereits seit Langem verfolgt – denn die Vorteile, ein komplexes Logistiksystem aus einer überschaubaren Anzahl standardisierter Module wie Weichen, Rollenförderern und Drehtischen flexibel realisieren zu können, liegen klar auf der Hand: die hohen Stückzahlen der Module bringen Kostenvorteile und die standardisierten Schnittstellen erleichtern die Integration (vgl. Günthner et al. 2006). Diese Modularisierung derzeit auf dem Markt erhältlicher Baukastensysteme bezieht sich jedoch in der Regel nur auf den mechanischen Aufbau der Systeme (vgl. Günthner et al. 2008). Ein Modulbaukasten, wie er von vielen Softwareherstellern für die Erstellung der Steuerungssoftware verwandt wird, wird in der Regel unabhängig vom physischen Aufbau des Materialflusssystems entwickelt. Daher verfügt er meist über vollkommen andere Schnittstellen als die Mechanikbaukästen. Eine funktionsorientierte Modularisierung, welche für ein definiertes Funktionsmodul die gleichen Schnittstellen für Mechanik, Energie und Steuerungssoftware besitzt, wird in (Wilke 2006) gefordert. Die Bildung mechatronischer Einheiten unter dem Blickpunkt der Funktionsorientierung ist ein wichtiger Ansatz, um die Planung und den Aufbau von Materialflusssystemen zu erleichtern. Laut Wilke müssen Module dabei über folgende Eigenschaften verfügen:

F. Kuzmany () Lehrstuhl für Fördertechnik Materialfluss Logistik, Technische Universität München Boltzmannstr. 15, 85748 Garching, Deutschland e-mail: [email protected] W. Günthner, M. ten Hompel (Hrsg.), Internet der Dinge in der Intralogistik, DOI 10.1007/978-3-642-04896-8_8, © Springer-Verlag Berlin Heidelberg 2010

51

52

F. Kuzmany et al.

• Zerlegbarkeit: Ein System lässt sich in Subsysteme/Module zerlegen. • Kombinierbarkeit: Module lassen sich frei und unabhängig voneinander zu neuen Systemen und Subsystemen kombinieren. • Verständlichkeit: Die Funktion eines Moduls muss für einen Anwender (Bedie­ ner/Planer) verständlich sein. Die Verwendung eines Moduls erfordert keine Kenntnisse über seinen inneren Aufbau (Black-Box-Prinzip) • Stetigkeit und Geschütztheit (Kapselung): Änderungen im Inneren eines Moduls, welche seine Schnittstellen unverändert lassen, dürfen keine Rückwirkungen auf das übrige System haben. Fehler und Störungen in einem Modul sollten auf das Modul beschränkt bleiben. • Identität der Systemgrenzen: Die Systemgrenzen von Mechanik, Energie und Steuerungstechnik eines Moduls müssen identisch sein. • Funktionsorientierte Betrachtungsweise: Modulgrenzen werden entsprechend der Funktionalität des Moduls gezogen. Das Modul kann seine Funktion ohne Einbettung in ein Gesamtsystem erfüllen. Es lässt sich unabhängig von anderen Modulen testen und in Betrieb nehmen Eine Modularisierung nach diesen Regeln versetzt einen Hersteller von Anlagenkomponenten in die Lage, nicht nur die Mechanik zu entwickeln und zu testen, sondern auch die dazu gehörende Steuerungslogik. Er wird zum Anbieter einer mechatronischen Einheit, welche direkt und mit nur geringem Programmieraufwand einsetzbar ist. Klare Schnittstellen verhindern dann eine Fortpflanzung von Fehlfunktionen in die restliche Anlage und erleichtern damit die Inbetriebnahme. Zudem wird es möglich, einen größeren Anteil der anfallenden Arbeitsaufwände projektunabhängig vorzubereiten. Dies erhöht den Standardisierungsgrad und senkt die projektspezifischen Entwicklungskosten. Das Internet-der-Dinge-Materialflusssystem wird also aus einem modularen Baukasten zusammengestellt, ähnlich wie bei der Erstellung eines Simulationsmodells.

8.2  Die Bausteine des Internet der Dinge In Anlehnung an bereits vorhandene Arbeiten im Bereich der Multiagentensysteme wird die nicht weiter zerlegbare Funktionseinheit im Internet der Dinge als Entität bezeichnet. Entitäten erfüllen autonom eine bestimmte logistische Funktion und interagieren zu diesem Zweck mit anderen gleichberechtigten Entitäten. Jeder Entität wird eine eigene Intelligenz in Form eines Softwareagenten zugeordnet. Dieser befähigt eine Entität, ihre eigenen Aufgaben wahrzunehmen, mit anderen zu kommunizieren oder Verhaltensstrategien umzusetzen. Einer Entität muss daher nur noch mitgeteilt werden was sie zu tun hat – wie dies geschieht, entscheidet die Entität selbst. Zur Steuerung eines Materialflusssystems sind drei verschiedene Typen von Entitäten mit jeweils eigenen Fähigkeiten und Eigenschaften notwendig (s. Abb. 8.1):

8   Die Bausteine des Internet der Dinge

53

Abb. 8.1   Die Entitäten im Internet der Dinge

• Transporteinheiten • Module • Softwaredienste.

8.2.1  Transporteinheiten Eine Transporteinheit (TE) stellt die kleinste Menge dar, welche im Materialflusssystem einzeln bewegt wird. Im Internet der Dinge sind alle TE mittels AutoidentTechnologien wie Barcodes oder RFID-Transpondern (s. Kap. 12) eindeutig identifizierbar. Darüber hinaus können auf einem RFID-Tag jedoch nicht nur die Identifikationsnummer sondern auch weitere Daten, beispielsweise über das Transportziel oder den Inhalt einer Transporteinheit, gespeichert werden. Ist es beispielsweise wegen unzureichender Speicherkapazitäten heutiger RFID-Systeme nicht möglich, alle Informationen direkt am Stückgut zu speichern, können diese vom Agenten der TE verwaltet und auf Anfrage bereitgestellt werden. Jeder TE wird ein Softwareagent zugeordnet, der beispielsweise auf einem stationären Rechner ausgeführt wird. Zwar ist es theoretisch denkbar, jede TE mit einem eigenen Controller auszustatten, allerdings ist dies aus Kostengründen nicht sinnvoll. Der Agent ermöglicht es einer Transporteinheit, mit anderen Entitäten zu kommunizieren, die Ausführung von Funktionen anzufordern und Daten auszutauschen. Beispiele für Transporteinheiten sind VDA Kleinladungsträger, Behälter, Paletten und Kartons.

54

F. Kuzmany et al.

8.2.2  Module Module sind autonom agierende Fördertechnikelemente. Soweit dies wirtschaftlich und technisch machbar ist, ist dabei eine klare Kapselung der Elektrik, Mechanik, Steuerungshardware und Steuerungssoftware anzustreben. Trotzdem ist es auch möglich, die Agenten – also die Steuerungslogik – mehrerer Module auf einem gemeinsamen Rechner auszuführen, was zu geringeren Kosten aber auch zu einer niedrigeren Robustheit und Transparenz des Systems führt. Module erfüllen eine logistische Funktion wie z. B. Transportieren, Sortieren oder Lagern und sind als Dienstleister aufzufassen, die den Transporteinheiten die zur Erfüllung ihres Arbeitsablaufs notwendigen Funktionen anbieten. Außerdem handelt es sich meist um Punkte, an welchen Entscheidungen (z. B. Wegentscheidungen) getroffen werden, wobei es in diesem Zusammenhang keine Rolle spielt, ob diese Entscheidungen mittels Softwarealgorithmen oder über eine Benutzerschnittstelle von einem Menschen getroffen werden. Beispiele für Module sind ein Regalbediengerät, eine Rollenbahn, eine Elektrohängebahnkatze, ein Verschiebewagen oder eine Kommissionierstation.

8.2.3  Softwaredienste Softwaredienste sind reine Softwareprogramme und übernehmen Aufgaben, die nicht einem einzelnen Modul oder einer TE zugeordnet werden können. Sie treten lediglich in Form eines Softwareagenten auf und dienen z. B. der Koordination, Optimierung, Überwachung und Visualisierung. Softwaredienste können auch eine Schnittstelle zu externen Systemen wie dem Lagerverwaltungsrechner realisieren. Beispiele für Softwaredienste sind eine Visualisierungsumgebung, eine Datenaustauschplattform, ein Verkehrsleitsystem und Schnittstellen zu externen Systemen wie dem Lagerverwaltungssystem.

8.3  Standardisierung und Anpassbarkeit Das Internet der Dinge muss, um sich erfolgreich durchsetzen zu können, zwei sich widersprechenden Anforderungen gerecht werden: • Die definierten Bausteine und vor allem deren Schnittstellen müssen so weit wie möglich standardisiert werden, damit sie sich mit nur minimalem Aufwand in beliebig vielen Projekten wiederverwenden lassen. • Kunden- und projektspezifische Wünsche und Anforderungen, die in ihrer Vielfalt unmöglich bei der Erstellung eines Standardbaukastens berücksichtigt werden können, müssen ebenfalls mit möglichst geringem Aufwand umgesetzt werden können. Dieser Zielkonflikt lässt sich jedoch auflösen, indem die zwei Standpunkte aus verschiedenen Perspektiven betrachtet werden. Eine weitgehende Standardisierung

8   Die Bausteine des Internet der Dinge

55

lässt sich mit abnehmender Granularität immer einfacher durchführen, denn je kleiner bzw. weniger komplex ein Baustein ist, desto leichter lassen sich seine Funktionen und Schnittstellen beschreiben, definieren und wieder verwenden. Bezogen auf allgemeine technischen Vorgänge bei der Produktion von Konsumund Investitionsgütern, und damit auf den Materialfluss im speziellen, lassen sich laut (Arnold 1995) alle Prozesse unter folgenden Oberbegriffen einordnen: Bearbeiten, Montieren, Prüfen, Handhaben, Fördern (Transportieren), Lagern (Speichern, Puffern), Sammeln, Verteilen, Sortieren und Verpacken. Diese logistischen Funktionen stellen somit die am besten geeignete Betrachtungsebene für eine Modularisierung im Internet der Dinge dar und werden, da zu ihrer Durchführung mechanische und/oder elektrische Komponenten benötigt werden, je einem Modul zugeordnet. Kundenspezifische Anforderungen beziehen sich im Normalfall aber nicht so sehr auf die einzelnen logistischen Funktionen an sich, sondern auf die in einer Anlage zu realisierenden Prozesse. Diese können als serielle oder parallele Verkettung einzelner Funktionen bzw. als Zusammenspiel mehrerer Komponenten angesehen werden. Dieses Zusammenspiel muss daher als von der eigentlichen Modullogik unabhängig betrachtet und so gesteuert werden können, dass es beliebig konfiguriert und bei Bedarf verändert werden kann. Im Zentrum der Betrachtung stehen dabei nicht die Module oder die logistischen Funktionen, sondern die Transporteinheiten. Denn diese sind es, die – unter Einhaltung der Geschäftslogik des Systems – transportiert, gelagert, sortiert oder verpackt werden müssen. Wie bereits beschrieben wird im Internet der Dinge jeder TE ein Agent zugeordnet, der alle zur Transporteinheit gehörenden Daten kennt und verwaltet und, wie jede Entität, in der Lage ist, mit anderen Einheiten zu interagieren. TE-Agenten werden daher mit der Fähigkeit ausgestattet, Arbeitsabläufe bzw. „Workflows“ zu verwalten und abzuarbeiten. Ein Workflow kann als Verkettung einzelner Arbeitsschritte angesehen werden, wobei jeder Schritt einer logistischen Funktion entspricht, die wiederum von einem Modul erbracht werden kann (s. a. Kap. 10). Dabei sind nicht nur lineare Sequenzen möglich, sondern auch Alternativen, die anhand von Verfügbarkeiten, Prioritäten oder anderen Faktoren ausgewählt werden. Solche Workflows können von einem Bediener oder Anlagenprogrammierer auf formale und allgemeingültige Art beschrieben und von TE-Agenten automatisiert interpretiert und abgearbeitet werden. Die Abarbeitung eines Workflows durch einen TE-Agenten gestaltet sich nun wie folgt: • Der Agent sucht Module, die die vom aktuellen Arbeitsschritt erforderte Funktion erfüllen. Diese Funktion wird für den TE-Agenten als einfache Zeichenfolge dargestellt – beispielsweise „Verpacken“ – der Agent besitzt und benötigt aber keine Informationen darüber, was dies nun eigentlich bedeutet. • Stehen mehrere Module zur Verfügung, wird eines ausgewählt – beispielsweise mittels einer Auktion, wobei das günstigste Modul den Zuschlag erhält. Dieses Modul wird zum aktuellen Transportziel. • Es werden Module gesucht, die die Transporteinheit zum gewählten Ziel transportieren können, wobei ein Transport über mehrere Module hinweg ebenfalls möglich ist.

56

F. Kuzmany et al.

• Am Ziel angekommen fordert der TE-Agent dazu auf, die entsprechende Funktion auszuführen. • Das Ergebnis der Funktionsausführung oder dabei evtl. aufgetretene Fehler dienen als Grundlage für die Wahl des nächsten Arbeitsschrittes innerhalb des vorgegebenen Workflows.

8.4  Fähigkeiten der Entitäten Das Internet der Dinge ist ein Netzwerk kooperierender Entitäten. Dieses Zusammenspiel kann jedoch nur erreicht werden, wenn alle Entitäten über eine bestimmte Grundfunktionalität verfügen, nämlich: • Kommunikation mit anderen Entitäten • Bekanntgabe eigener Eigenschaften und Funktionen • Verwalten des eigenen Zustands (sowohl Belegungs- als auch Fehlerzustände) und Absenden von Rück- und Statusmeldungen Darüber hinaus sind je nach Ausprägung einer Entität noch weitere Fähigkeiten notwendig. Transporteinheiten tragen beispielsweise die Verantwortung für ihren eigenen Transport. Daher müssen sie alle ihre Ziele und Zwischenziele kennen, mit Modulen ihre Beförderung verhandeln und letztere überwachen. Je nach Anforderungen in einer Materialflussanlage können Transporteinheiten auch Zusatzfähigkeiten wie z. B. Pulkfahren oder Prioritätsregelungen implementieren.

8.5  Funktionsklassen für Module Module bilden steuerungstechnisch betrachtet die komplexesten Bausteine des Materialflusssystems und bieten daher auch vielfältige Fähigkeiten an. Sie übernehmen Aufgaben wie die Überwachung und Ansteuerung ihrer Sensorik und Aktorik, führen Wegplanungen und Lastübergaben durch und stimmen sich mit anderen Modulen ab, um spezielle Materialflussstrategien zu realisieren. Daher ist es sinnvoll Module nochmals in Klassen zu unterteilen, welche ähnliche Fähigkeiten haben (s. Abb. 8.2).

Modul

Funktionsklasse

Funktionsklasse

Funktionsklasse

Funktionsklasse

Verzweigung / Zusammenführung

Stetigförderer und Schienen

Unstetigförderer

Arbeitsstation

Abb. 8.2   Funktionsklassen im Internet der Dinge

8   Die Bausteine des Internet der Dinge

57

Jede der nachfolgend genannten Klassen beschreibt Grundfähigkeiten, welche immer angeboten werden müssen. Es steht jedoch dem Programmierer frei, diese Grundklassen um weitere Fähigkeiten zu erweitern.

8.5.1  Verzweigung-/Zusammenführung Laut VDI-Richtlinie 3647 gibt es für alle Systeme Verzweigungs- und Zusammenführungsstellen, so dass Förderbehälter von einer auf eine andere Strecke umgeleitet werden können. Alle Verzweigungs- und Zusammenführungselemente müssen folgende Grundfunktionen zur Verfügung stellen: • Herstellen von unterschiedlichen Quelle-Ziel Verbindungen (z. B. Schalten von Streckenverbindungen) • Prioritätenregelung • Kollisionsschutz (bei Zusammenführungen) • Verwalten/Bereitstellen eines Aufsetzpunktes/Übergabeplatzes Verzweigungselemente innerhalb eines stetigen Güterstroms müssen, anders als Verzweigungen innerhalb eines Unstetigfördersystems, zusätzlich folgende Funktionen erfüllen: • Ermittlung aller für die Modulfunktion relevanten Eigenschaften einer Transporteinheit (entweder durch Anfrage bei anderen Entitäten oder durch Identifikation direkt auf dem Verzweigungselement) • Ausführen der Transportaufträge Beispiele für Verzweigungselemente sind: Rollenbahnweiche, Querverschiebewagen, Drehtisch.

8.5.2  Stetigförderer und Schienen Stetigförderer sind laut DIN 15201-1 mechanische, pneumatische und hydraulische Fördereinrichtungen, bei denen das Fördergut auf festgelegtem Förderweg von Aufgabe zu Abgabestelle stetig, mit wechselnder Geschwindigkeit oder im Takt bewegt wird. Laut VDI-Richtlinie 3647 dient eine Schiene dem Tragen und der Führung des Laufwerks, z. B. eines Unstetigförderers, und erfüllt aus der Perspektive des Internet der Dinge eine ähnliche Funktion wie die erwähnten Stetigförderer. Daher werden die beiden Elemente einer einzigen Kategorie zugeordnet. Alle Stetigförderer und Schienen müssen folgende Grundfähigkeit zur Verfügung stellen: • Transport von Transporteinheiten (bzw. Führen der Unstetigförderer) von Aufgabe- zu Abgabestelle des Moduls Beispiele für Stetigförderer sind: Senkrechtförderer, Gurtförderer, Rollenbahn, Elektrohängebahn-Strecke.

58

F. Kuzmany et al.

8.5.3  Unstetig förderer Unstetigförderer sind flurgebundene, aufgeständerte oder flurfreie Fördereinrichtungen, bei denen das Fördergut von Aufgabe- zu Abgabestelle in einzelnen Arbeitsspielen bewegt wird. Die Be- und Entladung erfolgt dabei während des Stillstandes des Fördermittels. Alle Unstetigförderer müssen folgende Grundfunktionen zur Verfügung stellen: • • • •

Ausführen der Transportaufträge Kollisionskontrolle Verwaltung der eigenen Plätze Ermittlung aller für die Modulfunktion relevanten Eigenschaften einer Transporteinheit (entweder durch Anfrage bei anderen Entitäten oder durch Identifikation direkt auf dem Förderelement)

Eine wichtige Zusatzfähigkeit von Unstetigförderern ist die Wegplanung im eigenen Aktionsbereich. Beispiele für Unstetigförderer sind: Elektrohängebahn-Katze, Stapler mit Leitsystem, Regalbediengerät, Fahrerloses Transportfahrzeug (FTF).

8.5.4  Arbeitsstation Arbeitsstationen dienen der Veränderung von Eigenschaften der Transporteinheiten, beispielsweise durch Veränderung ihres Inhalts während der Kommissionierung. Alle Arbeitsstationen müssen folgende Grundfunktionen zur Verfügung stellen: • Meldungen über veränderte Eigenschaften der TE • Einlasten von TE in den Materialfluss (über einen Übergabeplatz) Darüber hinaus können beispielsweise folgende Funktionen notwendig sein: • Verwaltung der gerade verfügbaren TE bzw. Artikel • Anzeige von Auftragsinformationen für einen Bediener • Meldungen über Fehlmengen bei der Kommissionierung Beispiele für Arbeitsstationen sind: Kommissionierarbeitsplatz, Produktionsmaschine.

8.6  Beispiel: Gestaltung eines Verzweigungsmoduls Wie eingangs erwähnt, werden Fördertechnikelemente bereits heute von den meisten Herstellern als ein Element nach dem Baukastenprinzip angeboten. Aus fertigen Elementen wird bei der Projektierung eines Materialflusssystems das

8   Die Bausteine des Internet der Dinge

59

erforderliche Layout der Anlage zusammengesetzt. Für die Realisierung werden die Elemente an ihre Aufgabe angepasst und mit Sensoren ausgerüstet. Die Steuerungslogik wird für jedes Modul in einem zentralen System explizit angepasst bzw. implementiert. Dieser Vorgang wiederholt sich bei jeder Neuanlage und erfordert einen enormen Engineeringaufwand. Nachträgliche Erweiterungen eines automatisierten Lagers mittlerer Größe benötigen bei heutigen Lösungen einen sehr hohen Anpassungsaufwand, speziell für die Steuerungssoftware des Materialflusssystems. Für den Einsatz im Internet der Dinge muss für Module eine einheitliche Basis bereitgestellt werden, die Erweiterungen vorsieht und/oder über Schnittstellen verfügen, welche eine flexible Auslegung der notwendigen Module ermöglichen. Ein solches Modul soll am Beispiel eines Riemen-Ein/-Ausschleusers (s. Abb. 8.3) näher beschrieben werden.

8.6.1  Auf bau Ein Riemen-Ein/-Ausschleuser ist ein Rollenförderer und dient zum Umlenken des Förderguts auf senkrecht oder parallel angeordneten Bahnen. Er verfügt über eine Zuführ- und zwei Abtransportstrecken (s. Abb. 8.4). Je nach eingesetzter Fördertechnik können Fördergeschwindigkeiten zwischen 0,3 und 1 m/s erreicht werden. Die Rollen werden in der Regel permanent von einem Elektromotor angetrieben. Die Ausschleusung erfolgt indem ein pneumatisches Hubwerk einen Riemenförderer

Abb. 8.3   Riemen-Ein/-Ausschleuser (Bild: Stöcklin Logistik GmbH)

60

F. Kuzmany et al. 1101

Legende:

ID

1102 B

- Modulnummer - Materialfllussrichtung

B

- Belegmelder (physikalisch)

R

- Readerplatz

Abb. 8.4   Riemen-Ein/-Ausschleuser (schematisch)

unterhalb der Transporteinheit leicht anhebt. Dieser Riemenförderer transportiert die TE dann senkrecht zu Förderrichtung. Hierzu wird ein eigener elektrischer Antrieb benötigt. Dieser Vorgang wird in der Regel „fliegend“ realisiert, so dass nachfolgende TE nicht angehalten werden müssen. Die Auslegung der Motorleistung und die Anzahl der Riemenführungen sind dabei stark von der Größe und dem Gewicht der Transporteinheiten abhängig. Auf Sensorseite ist das Modul mit zwei Lichttastern, welche den Eintritt bzw. das Verlassen einer TE erkennen, und einem Identifikationssystem ausgestattet, das die eindeutige Identifikationsnummer der Transporteinheit bestimmen oder weitere Daten auslesen kann. Im Internet der Dinge kommt im Normalfall RFID als Identifikationssystem zum Einsatz, jedoch sind prinzipiell auch andere ID-Systeme erlaubt. Als Steuerungseinheit können sowohl ethernetbasierte, verteilte Steuerungssysteme als auch zentrale Lösungen eingesetzt werden. Nach den Vorgaben der funktionsorientierten Modularisierung sollte jedoch, sofern wirtschaftlich machbar, jedem Modul eine eigene Steuerungseinheit zugeordnet und auf eine zentrale Lösung verzichtet werden. Die Anbindung der Sensoren und Aktoren kann beispielsweise über einen ASi-Bus realisiert werden. Die Softwarearchitektur ist, wie in Kap. 11 beschrieben, als zwei-Schicht-Architektur mit einer logischen, agentenorientierten Schicht für die Verwaltung und einer zweiten Schicht für die echtzeitfähige Steuerung der Module ausgeführt. Zwischen diesen Schichten regelt eine Middleware die Kommunikation. Diese Kapselung sorgt dafür, dass der Softwareagent unabhängig von dem eingesetzten Bussystem implementiert werden kann.

8.6.2  Betriebsablauf Um eine Entscheidung für den weiteren Transport zu treffen muss die TE zunächst an der Zuführstrecke physikalisch erkannt und eindeutig identifiziert werden. Dies geschieht noch vor der Verzweigungsstelle durch eine Unterbrechung einer Lichtschranke, welche auch das Startsignal für den Auslesevorgang des ID-Systems liefert. Nun wird die Identifikationsnummer der Transporteinheit ausgelesen. Ist diese bereits im System bekannt, so ist das Modul damit in der Lage, den entsprechenden Agenten der Transporteinheit zu finden und mit ihm den weiteren Transport

8   Die Bausteine des Internet der Dinge ID-System

Modul-Agent 1101

61 Steuerung/ Feldebene

TE-Agent

Belegmelder

1. Triggersignal

2. TE-Info. lesen 3. TE-Info. übergeben 4. Zuständigen Agenten suchen 5. TE-Agenten aktivieren 7. Richtung/ nächster Platz

6. Route berechnen

8. Ansteuerung/Richtungsvorgabe 9. Belegmeldersignal

10. Weiterleitung der TE

Abb. 8.5   Ablauf beim Betrieb des Riemen-Ein/-Ausschleusers als UML-Diagramm

zu verhandeln. Handelt es sich um eine bis dato unbekannte Transporteinheit, so wird ein neuer Agent instanziiert und der Transporteinheit zugeordnet. Zur Aufgabe dieses Agenten gehört nun die Berechnung der günstigsten Route anhand der aktuellen Position, dem vorgegebenen Ziel und der momentanen Auslastung der Anlage. Als Ergebnis wird der nächste anzufahrende Platz bzw. die Richtung für die Weiterleitung der TE ermittelt und an den Modul-Agenten zurückgegeben. Anschließend gibt letzterer die Informationen an die Steuerungseinheit weiter und mit der Ankunft der TE an der Verzweigungsstelle (wird durch eine weitere Lichtschranke erkannt) der Riemen-Ein/-Ausschleuser entsprechend angesteuert. Der beschriebene Ablauf ist in Abb. 8.5 in einem UML-Diagramm vereinfacht dargestellt. Zu beachten ist, dass diese Vorgänge innerhalb von Sekundenbruchteilen ablaufen müssen damit ein reibungsloser Transport weiterhin gewährleistet ist und keine Transporteinheit anhalten muss, um auf die Richtungsentscheidung zu warten. Durch die Zwei-Schicht-Architektur wird jedoch eine eindeutige Skalierung des Systems erreicht und somit kann eine echtzeitfähige Ansteuerung realisiert werden.

8.7  Fazit Wie das vorangegangene Beispiel gezeigt hat, verfügt eine Entität im Internet der Dinge über weit mehr als nur die mechanische Konstruktion und die Antriebe. Hinzu kommen die für ihre Aufgabe erforderlichen Sensoren und ein Identi­ fikationssystem. Für die Entscheidungsfindung und die Weiterleitung verfügt das

62

F. Kuzmany et al.

Modul über eine Steuerung, die sich wiederrum in einen logisch/strategischen und einen maschinennahen Anteil aufteilen lässt. Ersterer übernimmt die Verwaltung des Moduls und stellt Mechanismen für die Kommunikation mit seiner Umgebung bzw. weiteren Software-Agenten bereit. Der zweite Teil übernimmt die Verarbeitung eingehender Sensorsignale und die Ansteuerung der Aktoren und kann als speicherprogrammierbare Steuerung ausgeführt sein (s. Kap. 12). Eine Abstraktionsschicht bzw. Middelware stellt das Bindeglied zwischen diesen beiden Schichten dar. Zusammenfassend gehören zu den Aufgaben eines Riemen-Ein/-Ausschleusers: • • • • •

das Überwachen von Eingängen (Belegmelder z. B. optisch, induktiv), das kollisionsfreie Weiterleiten der TE, das Einlesen und Verarbeiten von ID-Informationen (z. B. RFID), die Netzwerkkommunikation zwischen den Agenten und die echtzeitfähige Ansteuerung der Aktoren.

Der wesentliche Vorteil dieser Vorgehensweise liegt in der Kapselung von Funktionen in einem in sich funktionsfähigen Modul. Diese Kapselung sorgt zum einen dafür, dass die Steuerungslogik der Module genauso wie bisher die Mechanik aus einem Baukasten zusammengesetzt werden kann. Zum anderen werden Inbetriebnahme und Fehlersuche erleichtert, da klare Schnittstellen eine Fortpflanzung der Fehler in andere Anlagenteile verhindern.

Kapitel 9

Kooperation und Autonomie   in selbststeuernden Systemen Moritz Roidl

Die Steuerung von Materialflusssystemen kann als ein übergreifendes Problem aufgefasst werden, das vom Steuerungssystem gelöst wird. Der Problemlösungsprozess lässt sich im Allgemeinen in drei aufeinanderfolgenden Phasen beschreiben: die Zerlegung des Problems, die Lösung der Teilprobleme und die anschließende Zusammenführung der Teillösungen. Je besser sich die Teilprobleme trennen lassen, desto einfacher führt eine gleichzeitige Lösung der Teile zu einer systemweiten Lösung. In Multiagentensystemen wird die Lösung der Teilprobleme an einzelne Agenten übergeben, die eigenständig arbeiten. Der einzelne Agent als autonome Einheit steht daher am Anfang der folgenden Betrachtung von Agentensystemen. Die lokalen Fähigkeiten des einzelnen Agenten bilden in einem verteilten Netzwerk jedoch nur die Grundbausteine für systemweite Funktionalität. Der entscheidende Aspekt, einen Nutzen aus der Verteilung lokaler Fähigkeiten zu ziehen ist die Kooperation zwischen Agenten. Der zweite Abschnitt befasst sich daher mit der Zusammenarbeit von mehreren Agenten und betrachtet dabei insbesondere die Kommunikation.

9.1  Grundlagen von Agentensystemen Es gibt bereits weithin akzeptierte Agentendefinitionen verschiedener Autoren, die in (Krumnacker 2001) mit Blick auf die Anwendung in Logistiksystemen beschrieben werden. Bisher hat sich jedoch keine allgemeingültige Definition durchsetzen können. Das Konzept der Modellierung mit Hilfe von Agenten kommt ursprünglich aus dem Bereich der Künstlichen Intelligenz. Die Struktur eines Agenten wird in (Russel u. Norvig 2004) folgendermaßen definiert: Agent = Agentenprogramm + Architektur M. Roidl () Lehrstuhl für Förder- und Lagerwesen, Technische Universität Dortmund Emil-Figge-Str. 73, 44221 Dortmund, Deutschland e-mail: moritz.roidl@f lw.mb.tu-dortmund.de W. Günthner, M. ten Hompel (Hrsg.), Internet der Dinge in der Intralogistik, DOI 10.1007/978-3-642-04896-8_9, © Springer-Verlag Berlin Heidelberg 2010

63

64

M. Roidl

Der Agent bezeichnet dabei das abstrakte Konzept, das als Agentenprogramm realisiert wird. Dieses bildet Wahrnehmungsfolgen auf Aktionen ab, die von der Architektur unterstützt werden. Soll ein Agent die Aktion „Laufen“ ausführen können, dann muss die Architektur Füße bereitstellen. In Materialflusssystemen wird die Architektur von der vorhandenen Fördertechnik und der Steuerungsinfrastruktur bestimmt.

9.2  Agententypen In (Russel u. Norvig 2004) werden vier grundlegende Arten von Agentenprogrammen unterschieden, die verschiedene Agentenkonzepte verkörpern. Diese sollen hier im Kontext der Materialflusssteuerung vorgestellt werden. Für jeden Typus wird ein einfacher Anwendungsfall beschrieben. Abbildung 9.1 zeigt die vier Grundtypen von Agenten. Die Typen bauen aufeinander auf und repräsentieren eine Hierarchie, mit der einfache und komplexe Agenten voneinander unterschieden werden können. Einfacher Reflexagent Ein Reflexagent wählt seine Aktionen nur aufgrund seiner aktuellen Wahrnehmung und ignoriert den bisherigen Wahrnehmungsverlauf. Ein Beispiel für einen einfachen Reflexagenten in einem Produktionssystem wäre ein Verpackungsagent, dessen Aufgabe es ist, für jedes Produkt die richtige Verpackung zu wählen. Für die Entscheidung sind dabei nur die Eigenschaften des aktuell betrachteten Produkts wichtig, wie zum Beispiel Größe, Volumen und Form, und nicht die bisher bearbeiteten Produkte. Modellbasierter Reflexagent Ein modellbasierter Reflexagent wählt seine Aktionen abhängig von einem Modell der Umwelt aus. Dieses Modell wird durch Wahrnehmungen verändert und erlaubt dem Agenten auch Teile der Welt zu verwalten, die er aktuell nicht wahrnehmen kann. Der Agent führt damit eine Art inneren Zustand, der die bisherigen Wahrnehmungen darstellt. Dieser wird zusammen mit den aktuellen Wahrnehmungen zur Entscheidungsfindung herangezogen. Ein gutes Beispiel für einen modellbasierten Reflexagenten ist die lokale Steuerung eines einfachen Förderbandes. Dieses hat als Sensoren zwei Lichtschranken am Anfang und am Ende sowie als Aktor einen Motor, der das Förderband antreibt. Der Agent zur Steuerung dieses Förderbands hat ein inneres Modell des Förderelements und kann so aus einer Unterbrechung der Lichtschranke am Anfang schließen, dass sich dort ein Lastobjekt befindet. Daraufhin stellt er den Motor an und erwartet, dass die Lichtschranke am Anfang nach kurzer Zeit nicht mehr unterbrochen ist, da das Lastobjekt bewegt wurde. Der Agent wartet nun auf die

Umgebung

Abb. 9.1   Klassifikation von Agenten nach (Russel u. Norvig 2004)

Zielbasierter Agent

Nächste Aktion?

Ziele

Aktuatoren

Weltzustand nach Aktion?

Umgebung

Aktionsfolgen

Weltzustand

Sensoren

Aktuatoren

Agent

Aktuatoren

Nächste Aktion?

Weltzustand

Sensoren

Aktuatoren

Nächste Aktion?

Nützlich?

Weltzustand nach Aktion?

Weltzustand

Sensoren

Nützlichkeitsbasierter Agent

Nutzenfunktion

Aktionsfolgen

Weiterverhalten

Zustand

Agent

Reflexagent mit internem zustand

Regeln

Aktionsfolgen

Weiterverhalten

Zustand Umgebung

Weiterverhalten

Zustand

Agent

Weltzustand

Sensoren

Nächste Aktion?

Einfacher Reflexagent

Regeln

Agent

9  Kooperation und Autonomie in selbststeuernden Systemen 65

Umgebung

66

M. Roidl

Unterbrechung der Lichtschranke am Ende des Bandes, da sein Modell vorgibt, dass das Lastobjekt dort nach ein paar Sekunden eintrifft. Danach wartet der Agent auf die Freigabe der Lichtschranke, da sein inneres Modell ihn erwarten lässt, dass das Lastobjekt das Förderband verlassen wird. Danach kann der Agent den Motor abstellen, da sich nach seinem Modell kein weiteres Lastobjekt auf dem Förderer befindet, wenn in der Zwischenzeit die Lichtschranke am Anfang nicht wieder unterbrochen wurde. Der Unterschied zwischen einfachen und modellbasierten Reflexagenten besteht in der Möglichkeit unerwartete Situation erkennen zu können. Der modellbasierte Agent kann erkennen, wenn ein Lastobjekt auf dem Förderband hängen bleibt, da die erwartete Unterbrechung der hinteren Lichtschranke ausbleibt. Er kann dann den Motor stoppen und eine Fehlermeldung an das Bedienpersonal schicken. Der einfache Reflexagent muss den Motor weiterlaufen lassen, da er keine Möglichkeit hat, aus den aktuellen Sensorinformationen einen nicht erwünschten Zustand zu erkennen. Zielbasierter Agent Das Wissen um den aktuellen Zustand einer Umgebung ist nicht immer ausreichend zur Entscheidungsfindung. Zielbasierte Agenten haben zusätzlich zum inneren Zustand eine Zielinformation, die einen wünschenswerten Zustand beschreibt. Zum Beispiel erhält ein Fahrerloses Transportsystem (FTS) einen Behälter zusammen mit einer Zielinformation und versucht den Behälter durch Transportaktionen zu diesem Zielort zu bringen. Dabei werden die Wahrnehmungen weiterhin zur Zustandsänderung des inneren Modells verwendet, aber Aktionen werden abhängig von diesem Zustand und von der Zielinformation ausgeführt. So biegt das FTS an einer Verzweigung je nach Zielort rechts oder links ab, obwohl das innere Modell in beiden Fällen den gleichen inneren Zustand hat. Nutzenbasierter Agent Das einfache Erreichen eines Ziels genügt häufig nicht den Qualitätsansprüchen einer Umgebung. Es ist nicht alleine wichtig, dass ein Agent sein Ziel erreicht, sondern auch wie er es erreicht. Ein gutes Beispiel ist hier wiederum das FTS, welches nicht einen Weg zum Ziel finden soll, sondern auch den günstigsten Weg. Welches der günstigste Weg ist bestimmt die Nutzenfunktion, die eine Auswahl zwischen mehreren möglichen Lösungen trifft. Die klassische Nutzenfunktion in der Materialflusssteuerung ist der Zeitverbrauch eines Weges und damit die Durchlaufzeit eines Lastobjekts durch das System. Die Nutzenfunktion ist nicht nur bedeutend, wenn eine Auswahl zwischen mehreren Lösungen getroffen werden muss, sondern auch wenn es mehrere zueinander in Konflikt stehende Ziele gibt. Hier gibt die Nutzenfunktion eine geeignete Abwägung an. Ein Beispiel für eine solche Situation in Materialflusssystemen ist, wenn die Minimierung von Durchlaufzeiten und des Energieverbrauchs angestrebt wird. Eine abwägende Nutzenfunktion könnte beispielsweise Motoren langsamerer laufen lassen und so Energie sparen, wenn ein Lastobjekt erst zu einem in der ferneren Zukunft liegenden Termin am Bestimmungsort ankommen muss.

9  Kooperation und Autonomie in selbststeuernden Systemen

67

9.3  Relevante Eigenschaften von Agenten In (Klügel 2001) werden die charakteristischen Eigenschaften von Agenten beschrieben, die informell das Verständnis des Wesens des Agentenkonzeptes vereinfachen sollen. Diese Eigenschaften sollen im Folgenden einzeln mit Blick auf die Anwendung in Materialflusssystemen untersucht werden. „Situated“ Dieser schwer zu übersetzende Begriff bezeichnet die Eigenschaft des sich in einer Umgebung Befindens. Er umschreibt die allgemeine Definition eines Agenten aus (Russel u. Norvig 2004) und stellt die Bedeutung der Abhängigkeit von Agent und Umgebung heraus: ein Agent kann ohne Umwelt nicht existieren. Die Umwelt kann dabei real sein oder auch virtuell. In Materialflusssystemen entspricht die Umwelt zum einen der realen Ausführungsumgebung des abgebildeten Logistikprozesses, sei es ein Lagerhaus oder auch das Verkehrsnetz eines Landes. Zum anderen besteht sie aus der Informationsinfrastruktur in dieser Ausführungsumgebung, aus der die Möglichkeiten zum Informationsfluss resultieren. Reaktiv Ein Agent ist reaktiv, wenn er die Informationen aus seiner Umgebung nicht nur aufnimmt, sondern sein Verhalten daraufhin anpasst. Ein reaktiver Agent kann also nicht eine im Vorhinein festgelegte Abfolge von Aktionen ausführen, sondern muss auf Ereignisse aus seiner Umgebung reagieren. In Materialflusssystemen werden solche Ereignisse durch Sensoren in der Fördertechnik vermittelt oder aber auch durch Eingaben des Bedienpersonals. Ein reaktiver Agent kann beispielsweise ein Förderband steuern und dieses nur anschalten, wenn eine Lichtschranke eine Unterbrechung meldet. Ein nicht-reaktiver Agent muss das Förderband immer laufen lassen, um sich sicher zu sein, alle Objekte darauf zu befördern. Autonom (Russel u. Norvig 2004) definieren die Autonomie eines Agenten als eine Form der Verhaltensautonomie, in der dieser nicht nur die Ausführung seines Verhaltens, sondern auch dessen Programmierung bestimmen kann. Diese sehr anspruchsvolle Definition wird nach (Klügel 2001) in Arbeiten anderer Autoren abgeschwächt verwandt und Kontrollautonomie genannt. Bei dieser gilt ein Agent schon als autonom, wenn er die Ausführung seines Verhaltens bestimmen kann. Sozial Auch hier gibt es nach (Klügel 2001) stärkere und schwächere Definitionen: sozial kann ein Agent schon dann sein, wenn er mit anderen Agenten über eine gemeinsame Sprache kommunizieren kann oder aber er muss sich anderer Agenten bewusst sein und soziale Beziehungen in Form von gemeinsamen Plänen usw. kennen. Soziales Verhalten ist die Grundlage von funktionierenden Multiagentensystemen, die im nächsten Abschnitt erläutert werden.

68

M. Roidl

Rational Rationalität eines Agenten bezeichnet die Fähigkeit, Aktionen so auszuführen, dass ein bestimmtes Ziel erreicht wird. Ein Beförderungsagent im Materialflusssystem führt daher gezielte Ortswechsel aus, so dass das Lastobjekt seinen Bestimmungsort erreicht. Anthropomorph Agenten werden oft als Abbild des Menschen dargestellt, so dass mentale Konzepte wie Wünsche, Absichten und Glaubwürdigkeit in den Sprachgebrauch von Agentenentwicklern übergegangen sind. Grundsätzlich bietet sich diese Sichtweise auch für Materialflusssysteme an, da gerade die Komponenten von automatisierten Systemen Arbeiten übernehmen, die vorher von Menschen geleistet wurden. So ist ein Programm zur Erstellung von Terminplänen einfach zu vergleichen mit einem Lagerleiter in einem nichtautomatisierten System.

9.4  Die Umwelt von Agenten Die Umwelt oder Umgebung eines Agenten bestimmt die Möglichkeiten, welche Informationen er erhält und welche Aktionen er ausführen kann. Die entsprechenden Sensoren und Aktuatoren bilden die Architektur eines Agenten, über die er an die Umwelt gebunden ist. In (Klügel 2001) werden die folgenden Konzepte zur Umwelt eines Agenten unterschieden. Zugänglichkeit Die Art der Informationen und ihre Zuverlässigkeit sind ein wichtiges Merkmal der Umwelt. Die Zugänglichkeit der Umwelt bestimmt, wie viel der Agent über seine Umwelt erfahren kann. Die Zugänglichkeit wird in Materialflusssystemen über Sensorik an der Fördertechnik realisiert, wie zum Beispiel Lichtschranken. Dabei gilt natürlich, dass eine größere Anzahl von Sensoren mehr Zugänglichkeit bedeutet, gegenläufig dazu aber die Kosten eines Systems ansteigen. Da gute Sensorik sehr viel kosten kann, ist es ein Ziel bei der Planung von Materialflusssystemen, so wenig Sensoren wie möglich einzusetzen. Einfache Sensoren, wie etwa Lichtschranken, sind dabei weitaus zuverlässiger als komplexe Sensorsysteme wie eine Bilderkennung. Durch Standardisierung der Lastobjekte, wie zum Beispiel die Einführung von Euro-Paletten, die genau definierte Abmaße haben, kann die Zugänglichkeit eines Systems weiter erhöht werden. Determiniertheit Die Determiniertheit bestimmt die Sicherheit, mit der ein Agent Informationen erhält und wie vorhersagbar die Resultate von ausgeführten Aktionen sind. Dabei kann sich die Umwelt selbst nicht-deterministisch verhalten. Doch selbst wenn sie es ist, kann es sein, dass die Zugänglichkeit der Umwelt einem Agenten nicht genug Informationen liefert und so auf ihn nicht-deterministisch wirkt.

9  Kooperation und Autonomie in selbststeuernden Systemen

69

Materialflusssysteme werden grundsätzlich als deterministisch betrachtet. Da die Systeme jedoch häufig zu komplex sind, um sie vollständig betrachten zu können, basieren viele Methoden der analytischen Materialflusslehre auf einer stochastischen Betrachtungsweise. Episodenhaftigkeit Hiermit ist die Relevanz der Historie von Beobachtungen durch den Agenten gemeint. Muss ein Agent alle bisherigen Beobachtungen berücksichtigen, wenn er Entscheidungen trifft oder kann er sich nur auf aktuelle Sensorinformationen stützen? In Materialflusssystemen sind beide Situationen vorstellbar. Wie im Abschnitt über die Modellierung von Materialflusssystemen beschrieben, hängt die Durchlaufzeit eines Lastobjekts von anderen Lastobjekten im System ab. Ein Routenfindungsagent kann daher nicht davon ausgehen, dass eine einmal gefundene optimale Route immer optimal bleiben wird, da der Verkehr auf dieser Route von vorherigen Routingentscheidungen beeinflusst wird. Ein anderer vorstellbarer Agententyp könnte ein Produkt auf Fehler prüfen. In diesem Fall wären die vorherigen Beobachtungen nicht relevant, da die Beschaffenheit der Produkte nicht voneinander abhängt. Dynamik Da Agenten für ihre Entscheidungsfindung Zeit verbrauchen, was insbesondere für komplexe Planungsalgorithmen gilt, spielt die Dynamik einer Umgebung eine wichtige Rolle. Sie bestimmt die Rate, mit der relevante Änderungen im System auftreten, die ein Agent bei seinen Planungen berücksichtigen muss. Dynamik und Echtzeitverhalten sind wichtige Charakteristika von Materialflusssystemen und müssen bei der Entwicklung von Agenten berücksichtigt werden. Ein Beispiel für dynamisches Verhalten kann die ungleichmäßige Belastung von Flughafengepäckförderanlagen sein. Hier ist es üblich, dass plötzlich große Mengen an Lastobjekten in das System eintreten, wenn ein Großraumflugzeug gelandet ist. Die große Menge an Gepäckstücken, die gleichzeitig an einer Stelle in das System eintritt, wird dort eine lokale Überlastung verursachen. Beförderungsagenten sollten auf diese Überlastung reagieren können und andere Gepäckstücke nachträglich um den örtlichen Stau herumleiten. Diskretheit Die Diskretheit einer Umgebung bestimmt den Wertebereich der zugänglichen Informationen und die Kontrollmöglichkeiten eines Agenten über die Aktuatoren. In Materialflusssystemen liefern Sensoren immer diskrete Informationen, da Sensoren alle Eingaben digitalisieren. Dennoch besteht ein Unterschied zwischen Lichtschranken, die nur zwei Werte kennen, und Laserentfernungsmessern, die Entfernungen millimetergenau angeben können. Ein gutes Beispiel für Aktoren ist die Geschwindigkeitseinstellung von Motoren. In vielen Materialflusssystemen haben Motoren eine festeingestellte Geschwindigkeit und können somit von der Steuerung nur ein- oder ausgeschaltet werden. In neueren Systemen werden hingegen Frequenzumrichter eingesetzt, die eine stufenlose Einstellung der Geschwindigkeit erlauben.

70

M. Roidl

9.5  Multiagentensysteme Die bisher betrachteten Eigenschaften von Agenten galten für einen einzelnen Agenten in seiner Umwelt. Wenn mehr als ein Agent in derselben Umgebung agiert, entsteht ein Multiagentensystem, dessen Wesen in Eigenschaften ausgedrückt werden kann, die es in Systemen mit einem einzelnen Agenten nicht gibt oder die in jenen keine Bedeutung spielen. Diese weiteren Eigenschaften ergeben sich nach (Klügel 2001) aus der mehr oder weniger ausgeprägten Autonomie der Agenten. Die folgenden allgemeinen Eigenschaften gelten nicht nur für Materialflusssysteme. Beschränktheit des Einzelnen In Multiagentensystemen besitzen Agenten üblicherweise eine beschränkte Wahrnehmung oder beschränkte Fähigkeiten, die dem Agenten die Fähigkeit nehmen, ein Ziel alleine zu erreichen. Lokalität von Daten und Berechnungen Jeder Agent verwaltet seine Daten lokal und führt seine Berechnungen lokal aus. Dabei sollten die Berechnungen von Agenten im Idealfall nebenläufig sein. Abwesenheit von zentraler Kontrolle Ein ideales Multiagentensystem besitzt keinerlei zentrale Kontrolle der Agenten. Das ist eine direkte Folge der Eigenschaft der Kontrollautonomie der Einzelagenten. Materialflusssysteme lassen sich als Multiagentensysteme darstellen, da sich die für Multiagentensystem beschriebenen Eigenschaften auch dort wiederfinden lassen. Dies ist möglich obwohl bisherige Steuerungssysteme eine zentrale Kontrolle über die einzelnen Komponenten ausüben. Betrachtet man die Systemkomponenten jedoch einzeln, so lassen sich Sensoren und Aktuatoren jeweils einer örtlich begrenzten Einheit zuordnen, dem Fördertechnikelement. Dieses Element ist in seiner Wahrnehmung lokal beschränkt und kann Aktionen auch nur lokal ausführen. Erst eine Menge an zusammenhängenden Förderelementen kann das Systemziel, den Transport von Lastobjekten zu ihren Bestimmungsorten, erreichen. So gleicht der physische Teil eines Materialflusssystems unabhängig vom Wesen seiner Steuerung bereits einem Multiagentensystem. Dabei dienen die einzelnen Teile des Systems dem Erreichen eines globalen Systemziels.

9.6  Kooperation In Multiagentensystemen ist Kooperation zwischen den Agenten ein entscheidender Aspekt, welcher es erst ermöglicht Nutzen aus der Verteilung der lokalen Fähigkeiten zu ziehen (s. Müller 1993). Jeder einzelne Agent kann zwar autonom gegenüber den anderen bezüglich seiner Existenz und seinen Fähigkeiten sein, doch nur durch die Zusammenarbeit erreicht die Gruppe ein höheres Maß an Leistung als der Einzelne.

9  Kooperation und Autonomie in selbststeuernden Systemen

71

Dies gilt natürlich insbesondere für Materialflusssysteme und ihre technischen Einzelkomponenten. Nur durch die Verkettung von einzelnen Transportoperationen wird beispielsweise das Gesamtziel eines Transportauftrags erreicht. Kooperation ist hier eine Form der Koordination, daher ein Interaktionsprozess, bei dem die Agenten ihre Aktionen aufeinander abstimmen Wenn ein Problem innerhalb eines Multiagentensystems von verteilten Agenten bearbeitet werden soll, dann steht an erster Stelle die Betrachtung einer strategischen Vorgehensweise bezüglich des Problemlösungsprozesses (s. Brenner et al. 1998). Erst danach können konkrete Überlegungen zu möglichen Kommunikations- und Kooperationsstrategien angestellt werden. Der Problemlösungsprozess lässt sich im Allgemeinen in drei aufeinanderfolgenden Phasen beschreiben: • Problemzerlegung, • Lösung der Teilprobleme • und Zusammenführung der Teillösungen. In der Phase der Problemzerlegung wird das Gesamtproblem in eine Reihe von Teilproblemen zerlegt. Auch im Fall von Intralogistiksystemen muss bei der Zerlegung entschieden werden, wie sie konkret ermittelt werden kann und wie die Agenten auf die Teilprobleme abgebildet werden. In diesem speziellen Fall hilft die Erkenntnis, dass alle Probleme der Logistik ihrem Wesen nach verteilte Probleme sind. Erst durch die örtliche Trennung von Dingen und die Notwendigkeit, sie von einem Ort zu einem anderen zu bewegen, entstehen die Probleme der effizienten Transportkoordination. So können alle Systeme in der Intralogistik als Netzwerke bzw. Graphen mit Knoten und Kanten abgebildet werden. Eine Abbildung der Agenten auf diese Elemente ist so sehr einfach und intuitiv durchzuführen. Die zweite Phase, die Lösung der Teilprobleme, ist im allgemeinen Fall häufig primär die Aufgabe eines einzelnen Agenten oder einer kleinen Gruppe von lokal beschränkten Agenten. Bei der dezentralen Wegesuche können dies beispielsweise die Agenten sein, die einen bestimmten Weg repräsentieren. Im Gegensatz zu einem Zentralsystem wissen diese Agenten nichts über möglicherweise alternative Wege. Die Zusammenführung der Teillösungen in der dritten Phase gestaltet sich im Fall von Materialflusssystemen meist unproblematisch. Probleme könnten auftreten wenn Teillösungen nicht eindeutig bzw. nicht vergleichbar wären. Da es sich bei intralogistischen Problemstellung aber sehr häufig um Optimierungsprobleme handelt, deren Teillösungen per Definition vergleichbar sein müssen (wie z. B. bei der kürzesten Wegesuche) tritt diese Problem hier nicht auf. Allerdings müssen meist Echtzeitanforderungen berücksichtigt werden (s. Kap. 7). Dies kann zur Folge haben, dass nicht alle Lösungen in dem gegebenen Zeitrahmen berücksichtigt werden können. Zusammenfassend kann Kooperation in multiagentengesteuerten Materialflusssystemen generell als eine Form der Koordination beschrieben werden. Die häufigste Umsetzungsform dieser Interaktionsprozesse soll nun im folgenden Abschnitt beschrieben werden.

72

M. Roidl

9.7  Kommunikation Kommunikation beschreibt einen Akt des direkten Informationsaustausches zwischen Agenten. Kommunikation bildet in Multiagentensystemen die Grundlage von Kommunikationsprozessen. Dabei liefert die menschliche Kommunikation die Ideengrundlage zu den konkreten Kommunikationsabläufen. Dementsprechend bildet eine Folge von Nachrichten einen Dialog. Die Spezifikation von Dialogstrukturen führt zum Begriff des Protokolls. Im folgenden Abschnitt werden die verschiedenen Arten der Kommunikation beschrieben. Die einfachste Form der Kommunikation ist der Aufruf einer Prozedur eines Agenten durch einen anderen Agenten. Über Parameter können Informationen übermittelt werden, eine Antwort kann synchron als Rückgabewert erfolgen oder durch einen späteren Prozeduraufruf (Callback-Verfahren). Diese technische Sichtweise der Kommunikation beschreibt jedoch nicht alle Möglichkeiten Kommunikationsprozesse abzubilden (s. Brenner et al. 1998). Im Folgenden sollen daher zwei Modellansätze zur Kommunikation betrachtet werden: Blackboard und Message Passing. Beide Verfahren repräsentieren Möglichkeiten den Prozess der Kommunikation zu verstehen.

9.7.1  Blackboard Unter der Blackboard-Metapher steht den Agenten ein gemeinsamer Speicherbereich zur Verfügung, den jeder Agent lesen und beschreiben kann. Somit können die Agenten untereinander Daten, Wissen und Informationen austauschen. Ein schreibender Agent veröffentlicht seine Informationen in der Regel ohne Adressaten. Lesende Agenten entscheiden, ob die Information für sie von Belang ist. Von der Idee her beschreibt die Blackboard-Metapher eine Gruppe von Experten, die gemeinsam vor einer Tafel (engl. Blackboard) stehen, welche den aktuellen Problemlösungszustand abbildet. Jeder Experte kann nun zur Problemlösung beitragen, wenn er erkannt hat, dass er dazu in der Lage ist. Ein wichtiges Merkmal von Blackboards ist die Unabhängigkeit der Teilnehmer untereinander. Ein Agent kann hinzugefügt und entfernt werden, ohne dass andere Agenten davon betroffen sind. Ein Agent muss gar nicht wissen, wie viele andere Agenten beteiligt sind oder welche Fähigkeiten sie besitzen. So können unterschiedliche Problemlösungstechniken angewendet werden. Dies setzt allerdings voraus, dass eine einheitliche Repräsentation der Informationen existiert. Nur so kann ein individueller Agent den Zustand der Problemlösung erkennen und beurteilen. Technisch gesehen kann ein einfaches Blackboard über eine Datenbank bzw. Datenbanktabelle realisiert werden. Komplexere Blackboardstrukturen können aber andere technische Lösungen erfordern. Insbesondere der Aspekt der Benachrichtigung von Agenten verdient eine genauere Betrachtung. Im Prinzip kann jeder Agent beliebig oft das Blackboard lesen und nach relevanten Informationen suchen. Bei

9  Kooperation und Autonomie in selbststeuernden Systemen

73

einer solchen Verfahrensweise, bei einer großen Zahl von Agenten und einer großen Informationsmenge entstehen hohe Anforderungen an die technische Belastbarkeit der Blackboard-Implementierung. Lösungsansätze können eine Segmentierung des Blackboards in verschiedene Themenbereiche, der Einsatz mehrerer Blackboards oder eine ereignisbasierte Aktivierung von Agenten sein.

9.7.2  Message-Passing Der direkte Nachrichtenaustausch (engl. Message-Passing) zwischen Agenten ist ein Kommunikationsmodell, das zwei Rollen kennt: die des Senders und die des Empfängers. Ein Kommunikationsvorgang besteht immer aus einem Sender, der eine Nachricht vorbereitet und anschließend an einen oder mehrere Empfänger sendet. Eine solche Nachricht besteht aus einem Inhalt, dessen Semantik alle beteiligten Agenten bekannt sein muss. Für den technischen Vorgang des Versands kodiert der Sender die Nachricht, d. h. er übersetzt die Nachricht in eine Kommunikationssprache. Eine solche Sprache kann z. B. ein XML-Dialekt sein oder auch ein proprietäres Binärformat. Damit der Empfänger die Nachricht nicht nur dekodieren, sondern auch verstehen kann, muss ihm die Semantik der verwendeten Kommunikationssprache bekannt sein. Das Umfeld der Kommunikation per Nachrichtenaustausch besteht also aus mehreren Bereichen: • Kommunikationsthema, • Kommunikationsprozess und • Kommunikationsablauf Ein Kommunikationsablauf besteht aus einer Folge von Kommunikationsvorgängen, bei denen die Rollen von Sender und Empfänger mehrfach wechseln können. Diese Folge wird dann ein Dialog genannt. Ist der Ablauf eines Dialogs spezifiziert heißt die Spezifikation Protokoll. Auch wenn das eigentliche Kommunikationsthema von der Anwendung abhängt, können Nachrichtentypen und Dialoge anwendungsunabhängig beschrieben werden. Dazu wird häufig auf die sogenannte Sprechakttheorie zurückgegriffen. Hier besteht eine Nachricht nicht einfach nur aus Fakten oder Befehlen, sondern sie repräsentiert eine Absicht eines Agenten, der ein Ziel erreichen möchte. Dieses Ziel kann er häufig nur durch Aktionen anderer Agenten erreichen, so entsteht der Begriff des Sprechaktes. Eine Nachricht als Sprechakt definiert sich nicht alleine über eine Wissensaussage, die z. B. wahr oder falsch sein könnte, sondern nimmt direkten Einfluss auf die Umwelt der Agenten. Die Änderung bezieht sich zuerst auf den Empfänger der Nachricht, der sie bewertet und seinen inneren Zustand ändert. Daraufhin wird er eventuell eine Aktion ausführen, d. h. direkt Einfluss auf seine Umwelt nehmen oder weitere Sprechakte durchführen. Eine Folge der Autonomie der Agenten ist, dass kein Agent formal verpflichtet ist, bestimmte Aktionen durchzuführen. Beispielsweise kann er die Durchführung einer Aktion verweigern, wenn der Sender nicht über eine geeignete Autorisierung verfügt. Eine

74

M. Roidl

solche Modellierung von Kommunikationsprozessen erlaubt so z. B. die direkte Integration von Sicherheitsaspekten in die Systemarchitektur. Zur gemeinsamen Kooperation mit Hilfe von Sprechakten werden Sprechakttypen definiert, die sich an menschlicher Kommunikation orientieren. Die klassische Sprechakttheorie unterscheidet fünf Klassen von Sprechakttypen: die Urteilssprechung, die Ausübung von Macht, die Verpflichtung, Verhaltensweisen und Darstellungen. Für jede dieser Klassen lassen sich Beispiele von Sprechakttypen finden, wie etwa ein Befehl, ein Versprechen, eine Korrektur oder eine Analyse. Die grundsätzliche Absicht eines Agenten sollte aus dem Sprechakttypen hervorgehen und somit den Nachrichtentyp bestimmen. Stellt er eine Anfrage, dann sendet er eine Nachricht vom Typ „Anfrage“ usw. Die Auswahl einer Menge von Sprechakttypen wird von der jeweiligen Anwendung bestimmt. Ist die Auswahl jedoch einmal getroffen, so muss jedem beteiligten Agenten die Semantik bekannt sein, so dass Sender und Empfänger jede Nachricht gleich interpretieren. Wie bereits erwähnt, besteht ein Kommunikationsablauf in der Regel aus mehr als einer isolierten Nachricht. Beispielsweise erwartet der Sender einer Anfrage eine Antwort vom Empfänger. So entsteht ein Dialog. Genau so wie es Sprechakttypen gibt, deren Semantik global bekannt ist, können Dialogtypen spezifiziert werden. Diese Spezifikationen heißen Protokolle. Auch die Semantik der Protokolle muss global bekannt sein, damit Agenten bestimmte Erwartung an ihr Verhalten auch erfüllen können. So könnte ein Protokoll dem Empfänger eines Befehls freistellen diesen abzulehnen. Was genau befohlen wurde, ist Sache der Anwendung, die Möglichkeit Befehle abzulehnen kann durch ein allgemeines Protokoll festgelegt werden. Ein Beispiel für ein einfaches Protokoll in Materialflusssystemen wäre die Kommunikation zwischen zwei aufeinanderfolgenden Modulen während einer Paketübergabe. Das Vorgängermodul könnte eine Anfrage auf Transportübernahme an das Nachfolgermodul stellen. Das Nachfolgermodul kann diese Anfrage ablehnen oder annehmen. Nach der Annahme kann der physikalische Transport erfolgen und wird eventuell durch eine Quittung bestätigt. Im folgenden Kapitel werden solche Protokolle für Materialflusssysteme entwickelt.

9.7.3  Kommunikationsschichtenmodell Die in den vorherigen Abschnitten betrachteten Kommunikationsmodelle können und sollen natürlich nicht isoliert betrachtet werden. Dies bedeutet, dass sich die Modelle für Multiagentensysteme natürlich auch zu bisherigen Modellen für verteilte Systeme in Beziehung setzen lassen. Daher soll hier beispielhaft ein standardisiertes Kommunikationsmodell vorgestellt werden, welches die bereits vorgestellten Kommunikationsaspekte in Multiagentensystemen in einer Schichtstruktur ordnet. Abbildung 9.2 stellt den Zusammenhang und die Schichtenmodelle des ISO/OSIStandards, von TCP/IP und den FIPA-ACL-Standard dar. Der FIPA-ACL-Standard

9  Kooperation und Autonomie in selbststeuernden Systemen

75 Protokolle Kommunikationsakte Ausdrücke Ontologien Nachrichtenübertragung Kodierung, z.B. XML

Anwendung

Anwendung, z.B. HTTP

Transport, z.B. HTTP

Darstellung Sitzung Transport

Transport, z.B. TCP

Vermittlung

Vermittlung, z.B. IP

Sicherung

Sicherung & Bitübetragung, z.B. Ethernet

Bitübertragung OSI

TCP/IP

FIPA ACL

Abb. 9.2   Kommunikationsschichtenmodelle im Vergleich nach (Poslad 2006)

ist Teil einer Gruppe von Spezifikationen für Agentensysteme und wird von der Foundation for Intelligent Physical Agents (FIPA) entwickelt (s. FIPA ACL 2009). ACL steht dabei für Agent Communication Language. Es ist gut zu erkennen, dass die Multiagentenkommunikation als eine Erweiterung der Anwendungsschicht der altbekannten Modelle zu verstehen ist (s. Poslad 2006). Der FIPA-ACL-Standard definiert sieben Schichten, die im Folgenden kurz beschrieben werden sollen: • Die Transportebene ist die unterste Ebene des FIPA-ACL-Protokollstapels. Diese Ebene kann z. B. in HTTP implementiert sein. • FIPA-ACL-Nachrichten sind standardmäßig nicht bytekodiert, sondern Nutzen Datenstrukturen wie etwa XML. Die Kodierungsebene nach FIPA erlaubt aber auch effizientere Kodierungsarten. • Die Nachrichtenübertragungsebene spezifiziert Standarddatenfelder für die Nachrichtenstrukturen, die neben dem eigentlichen Inhalt übertragen werden. Diese enthalten Sender, Empfänger, Nachrichtentyp usw. • Die Ontologieebene beschreibt die anwendungsspezifische Struktur des Nachrichteninhalts. In Kap. 10 wird eine solche Ontologie für intralogistische Materialflusssysteme entwickelt. • Die Ebene der Ausdrücke wird in FIPA-ACL getrennt von der Ontologieebene beschrieben. Dies ermöglicht eine anwendungsunabhängige Darstellung von Regeln und Aussagen.

76

M. Roidl

• Die Ebene der Kommunikationsakte bezieht sich wieder auf die bereits beschriebene Sprechakttheorie. Der FIPA-Standard spezifiziert eine große Zahl von Kommunikationsakten und stellt somit eine global eindeutige Semantik zur Verfügung, die von allen FIPA-konformen Agenten verstanden wird. • Die Protokollebene beschreibt Interaktionsabläufe zwischen Agenten. FIPA hat mehrere allgemeine Interaktionsprotokolle standardisiert, die von Anwendungen genutzt werden können. Über ein standardisiertes Kommunikationsschichtenmodell wie es die FIPA-ACLSpezifikationen beschreiben, wird die Multiagentenkommunikation als Erweiterung bestehender Kommunikationsmodelle dargestellt. Die Bedeutung der Standardisierung ist dabei nicht zu unterschätzen. Denn die Vorteile der Autonomie von Agenten können erst vollkommen ausgeschöpft werden, wenn die notwendige Kooperationsfähigkeit vorhanden ist. Dies bedeutet, dass jegliche Ziele, die kooperativ zu erreichen sind, einer global vorhandenen Kommunikationsfähigkeit bedürfen. Ein herstellerübergreifender Standard wie FIPA-ACL kann diese globale Fähigkeit, zumindest anwendungsunabhängig, bereitstellen. Denn nur durch die Standardisierung der Kommunikation können autonome und wiederverwendbare Agenten entstehen. Der konkrete Anwendungsfall erfordert natürlich eine domänenspezifische Modellierung der inhaltlichen Nachrichtenstruktur und Interaktionsprotokolle. Das folgende Kapitel entwickelt ein solches anwendungsbezogenes Kommunikationsmodell für das Internet der Dinge in der Intralogistik.

Kapitel 10

Eine Ontologie für das Internet der Dinge Sergey Libert, Razvan Chisu und Konstantin Keutner

10.1  Einleitung Ein wichtiger Schritt bei der Konzeption und Umsetzung des Internet der Dinge besteht in der Formalisierung von Funktionen und Informationen, die zur Steuerung innerbetrieblicher Materialflüsse nötig sind. Kommunikationsmodelle spielen dabei eine besondere Rolle, da erst sie die Interoperabilität zwischen verteilten Steuerungskomponenten ermöglichen. Im vorliegenden Kapitel wird daher ein solches Modell in Form einer Systemontologie vorgestellt. Diese stellt einen notwendigen Baustein für die Gestaltung der Kommunikation innerhalb eines verteilten Steuerungssystems dar. Für die Validierung der Ontologie wird ein Beispielszenario herangezogen. Das Konzept einer dezentralen Steuerung als Netzwerk kooperierender logistischer Entitäten bietet bereits die Grundlage für die Ableitung von Methoden zur Gestaltung der Kommunikation und die Modellierung der Kommunikationsinhalte. Für die Abbildung und Umsetzung dieser autonomen und kooperierenden Entitäten wird im Internet der Dinge auf Methoden und Theorien aus dem Bereich der Multiagentensysteme zurückgegriffen. Die Kooperation in einem agentenbasierten Steuerungssystem wird technisch als Nachrichtenaustausch realisiert. Ein Modell hierfür wurde 1992 von der DARPA im Rahmen des Knowledge Sharing Effort (KSE) entwickelt. Dieses Modell besteht aus drei Ebenen: Kommunikation, Nachrichten und Inhalte (vgl. Patil et al. 1992). Aufbauend auf diesem Modell spezifiziert die Foundation for Intelligent S. Libert () Lehrstuhl für Förder- und Lagerwesen FLW, Technische Universität Dortmund Emil-Figge-Str. 73, 44221 Dortmund, Deutschland e-mail: [email protected]  

Defense Advanced Research Projects Agency (DARPA) ist eine Behörde des Verteidigungsministeriums der Vereinigten Staaten, die Forschungsprojekte für das US-Militär durchführt. Als bekanntestes und erfolgreichstes Projekt von DARPA kann das ARPANET angesehen werden, aus welchem das heutige Internet hervorging. W. Günthner, M. ten Hompel (Hrsg.), Internet der Dinge in der Intralogistik, DOI 10.1007/978-3-642-04896-8_10, © Springer-Verlag Berlin Heidelberg 2010

79

80

S. Libert et al.

Physical Agents (FIPA) drei Ebenen der Agentenkommunikation (vgl. Foundation for Intelligent Physical Agents 2009): • Kommunikationsprotokolle, • Sprache und • Ontologie. Ein Protokoll beschreibt den Ablauf einer Kommunikation, die aus einzelnen Sprechakten besteht. Dabei sind die Darstellung und Bedeutung der Informationen in einem Sprechakt für Protokolle irrelevant. Die Struktur einer Nachricht ist dagegen ein wichtiger Bestandteil eines gut spezifizierten Protokolls (vgl. Defense Advanced Research Projects Agency 1993, Foundation for Intelligent Physical Agents 2002). FIPA spezifiziert beispielsweise eine ganze Reihe von Kommunikations­ protokollen, die für die meisten Aufgaben in einer agentenbasierten Materialfluss­ steuerung ausreichen. Vier relevante Beispiele von FIPA Interaktionsprotokollen sind in Tab. 10.1 aufgelistet. Die Protokolle definieren zwar die Nachrichtenstruktur, beschreiben aber nicht die Nachrichteninhalte. Die Semantik von Nachrichten wird in einer Kommunikationsontologie festgelegt und mit einer Inhaltsprache dargestellt. Als Beispiele für Inhaltssprachen können hier spezielle Agentensprachen wie KIF, SL oder LEAP aber auch XML-Dialekte wie DAML+OIL genannt werden (vgl. Bellifemine et al. 2007, Woolridge 2002, Botelho et al. 2009, Defense Advanced Research Projects Agency 1993). Die Auswahl einer passenden Inhaltssprache hängt vom Entwickler ab. Die für die Auswahl relevanten Faktoren sind beispielsweise Transparenz (Klartext oder codiert), die zu übertragende Datenmenge (Overhead) aber auch die Akzeptanz bei anderen Systementwicklern. Sollen zwei voneinander unabhängig entwickelte Agenten miteinander kommunizieren, so müssen diese mindestens eine gemeinsame Sprache beherrschen. Die Ontologie stellt die dritte Ebene der Agentenkommunikation dar. Eine Ontologie bildet den Kommunikationskontext in Form eines Weltmodells ab, dessen Zweck es ist, die Eindeutigkeit der Inhalte beim Wissensaustausch zu gewährleisten. Aus diesem Grund muss für jeden Anwendungsfall bzw. jede Anwendungsdomäne eine spezielle Ontologie festgelegt werden.

Tab. 10.1   Relevante FIPA Interaktionsprotokolle in Übersicht Kürzel

Protokollname

Zweck/Bedeutung

QUERY REQUEST CFP SUBSCRIBE

Query Interaction Protocol Request Interaction Protocol Contract Net Interaction Protocol Subscribe Interaction Protocol

Informationsabfrage Beauftragung einer Aktion Verhandlung über ein Angebot Anmeldung für Nachrichten

 

Foundation for Intelligent Physical Agents (FIPA) ist eine internationale Organisation, die sich mit der Entwicklung und Standardisierung von Multiagenten-Systemen beschäftigt.

10  Eine Ontologie für das Internet der Dinge

81

10.2  Entwicklung einer Kommunikationsontologie Der Begriff Ontologie stammt aus der Philosophie und wird in der theoretischen Informatik zur Bezeichnung formaler Begriffsbildung verwendet. Gruber definiert Ontologie als „…eine explizite formale Spezifikation einer gemeinsamen Konzeptualisierung (Begriffsbildung)“ (vgl. Gruber 1993). In einem Multiagentensystem wird das in einer Ontologie festgelegte Vokabular für Agentenkommunikation verwendet. Erst diese gemeinsame Begriffsbasis macht eine sinnbehaftete Kommunikation überhaupt möglich. Eine Ontologie grenzt den Kommunikationskontext ab. So werden in der Ontologie für das Internet der Dinge nur die Begriffe definiert, die für die Wissensbeschreibung in einer Materialflusssteuerung von Bedeutung sind. Der Wissensgehalt wird in einer Ontologie mittels einer semantischen Verknüpfung von Begriffen dargestellt. Die Begriffe selbst werden im Kontext der Agentenkommunikation in drei Kategorien unterteilt (vgl. Foundation for Intelligent Physical Agents 2000, Cossentino u. Potts 2002): • Konzepte beschreiben Bestandteile der Anwendungsdomäne. Im Internet der Dinge finden sich beispielsweise die Konzepte Transportauftrag, Kosten aber auch Modul und Transporteinheit. • Prädikate sind Ausdrücke, die etwas über Weltzustände aussagen und entwe­‑ der wahr oder falsch sein können. So kann ein Prädikat angeben, ob ein Modul eine bestimmte Funktion anbietet oder ob sich eine Transporteinheit an einem bestimmten Ort befindet. • Aktionen sind Sprachausdrücke, die die Durchführung einer Aktivität von einem Anderen verlangen bzw. um diese bitten. Ein typisches Beispiel für eine Aktion ist die Durchführung eines Transportauftrages. Im Weiteren wird eine Basisontologie für das Internet der Dinge erarbeitet und präsentiert. Die Vorstellung erfolgt in zwei Schritten. Im ersten Schritt werden Begriffe der Basisontologie definiert. Im zweiten Schritt wird die Anwendung der Ontologie anhand eines Kommunikationsmodells für typische Steuerungsaufgaben erläutert. Zur Visualisierung der beiden Schritte werden Diagramme des Agenten-Gesellschaftsmodells (engl. Agent Society Model) der PASSI-Methodologie verwendet (vgl. Institute of High Performance Computing and Networking 2009).

10.2.1  Ontologiebeschreibung Einen Überblick über Begriffe der Basisontologie für das Internet der Dinge bietet das Ontologie-Beschreibungsdiagramm in Abb. 10.1. Das Diagramm benutzt die UML-­­  

Die PASSI-Methodologie ist eine Vorgehensweise im Rahmen der agentenorientierten Softwareentwicklung (AOSE). Sie ermöglicht eine systematische Entwicklung von agentenbasierten Applikationen von der Anforderungsspezifikation bis in die Implementierung.

2

0..N

2

-TE -Übergabe

-Vorgänger -Nachfolger

<<predicate>> IstNachfolger

-Auftrag -Pfad

0..1

<<predicate>> TEGeortet -TE -Ort

0..1

<> Transportauftrag -Id -Quelle -Ziel

<> WorkflowSchritt -Aufgabe -Status

0..1 <> TE (Transporteinheit) -Id

<> FunktionAnwenden -Akteur -Funktion

<> Puffern

<<predicate>> ÜbergabeErlaubt

0..1

<<predicate>> PfadRealisiertauftrag

<> Übergabepunkt

-Quelle -Ziel

<> Transport

<> Funktion

<> Lagern

Abb. 10.1   Basisontologie für das Internet der Dinge

2

<> Ort -Adresse

<> Kosten

-Anbieter -Funktion -Kosten -TE

<<predicate>> FunktionKostet

<<predicate>> BietetFunktion -Anbieter -Funktion

<> Pfad -Schritte -Kosten

0..1

0..1

<<predicate>> OrtGehortZuModul -Modul -Ort

<> Modul -Id -Adresse

<> Dienst -Id

<> WorkflowSequenz

<> AlternativWorkflow

<> Workflow -Status -Schritte -AktuellerSchritt -TE

<> WorkflowAusführen -Workflow

82 S. Libert et al.

10  Eine Ontologie für das Internet der Dinge

83

Klassendarstellung, um Konzepte, Prädikate und Aktionen zu visualisieren (vgl. Cossentino u. Potts 2002). Die semantische Verknüpfung zwischen den Begriffen kann zwei Formen annehmen: einfache Abhängigkeit und Verknüpfung. Die Abhän­ gigkeiten sind gerichtet. Die Kardinalität gibt vor, wie viele entsprechende Konzept­ objekte an einer Abhängigkeit beteiligt sind. Durch den Vererbungsmechanismus ist eine weitere Spezialisierung der Basisbegriffe möglich. Die Begriffe der Basisontologie lassen sich in vier Gruppen unterteilen: Kernontologie, Funktionenontologie, Workflow-Ontologie und Transportontologie. Diese werden im Folgenden der Reihe nach erläutert. Die vorgeschlagenen Begriffe bieten ein Grundgerüst für die Wissensrepräsentation in einem Materialflusssystem und können bei Bedarf erweitert werden. 10.2.1.1  Kernontologie Die Kernontologie beinhaltet Konzepte zur Beschreibung von Systementitäten. Diese Konzepte referenzieren Systemteilnehmer einer Kommunikation innerhalb der Multiagentensteuerung. • Modul Mit dem Konzept Modul werden Agenten referenziert, die mechatronische Komponenten einer Materialflussanlage (z. B. Unstetigförderer wie Stapler oder Regalbediengeräte, Stetigförderer wie Förderbänder oder Weichen und Arbeitsstationen wie z. B. Kommissionierplätze) in dem Steuerungssystem repräsentieren. Jedes Modul wird durch einen Namen und eine physikalische Adresse eindeutig identifiziert. Über den eindeutigen Namen können Modulagenten in einem Multiagentensystem zu jedem Zeitpunkt gefunden werden. Eine physikalische Adresse dient zur Wegfindung im Transportnetzwerk der Anlage. • TE (Transporteinheit) Das Konzept Transporteinheit referenziert Agenten im Materialfluss, die einem transportierten Stückgut zugeordnet sind und dessen Belange aktiv vertreten. Sowohl das physikalische Stückgut als auch die TE-Agenten müssen im System eindeutig gekennzeichnet werden. Für beide Aufgaben kann ein und derselbe Kennzeichner verwendet werden. Als solcher kann beispielsweise ein Elektronischer Produktcode (EPC) eingesetzt werden, welcher auf dem RFID-Tag des Behälters gespeichert wird und zusätzlich zur Adressierung von TE-Agenten im Steuerungssystem dient. • Dienst Dienste repräsentieren in der Steuerung Funktionen, die keiner hardwaretechnischen Komponente zugeordnet werden können und somit als reiner Softwarebaustein existieren. Auch Dienste werden im System als Agenten realisiert und durch das Dienstkonzept in der Kernontologie referenziert. So wie Module  

Unified Modeling Language ist eine Modellierungssprache, die sich in der objektorientierten Softwareentwicklung etabliert hat.

84

S. Libert et al.

und TE sind auch Dienste durch einen eindeutigen Namen gekennzeichnet, der gleichzeitig als Kommunikationsadresse dient. 10.2.1.2  Funktionenontologie Die Funktionenontologie definiert das Vokabular, das zur Anfrage angebotener Funktionen und deren Nutzung benötigt wird. Mit Hilfe dieser Ontologie können Abfragen wie „Welche Funktionen sind im Materialflusssystem verfügbar?“, oder „Welcher Dienst bzw. welches Modul kann eine bestimmte Funktion für eine Transporteinheit anbieten, zu welchen Kosten?“ ausgedrückt werden. • Funktion Das Konzept Funktion repräsentiert eine Dienstleistung, die ein Modul oder ein Dienst erbringen kann. Einige Funktionen dienen dem Transport oder der Handhabung von Transporteinheiten, wie zum Beispiel Identifikation, Wiegen oder Konturenkontrolle, und werden durch Module realisiert. Die durch Dienste realisierten Funktionen beziehen sich ausschließlich auf die Verarbeitung, Aufbereitung oder Darstellung von Informationen. • FunktionAnwenden Mit der Aktion FunktionAnwenden wird ein Dienst oder ein Modul mit der Ausführung einer Funktion beauftragt. Als Beispiel kann eine TE, die sich gerade im Bereich eines Palettierroboters befindet, den Umladevorgang auslösen. • BietetFunktion Mithilfe des Prädikats BietetFunktion ist es möglich, eine Auskunft über die von einem Dienst- oder Modul angebotenen Dienstleistungen zu erhalten. Auf diesem Prädikat aufbauend kann auch eine Anfrage formuliert werden, um die Kommunikationsadressen der entsprechenden Agenten zu ermitteln. • Kosten Das Konzept Kosten wird zum Vergleich verschiedener Handlungsalternativen verwendet. Kosten beschreiben den Umsetzungsaufwand der jeweiligen Handlung in einem Materialflusssystem. Sie können aus den für die Systemleistung relevanten Faktoren abgeleitet werden. Ein Beispiel dafür ist der Faktor Zeit. Kosten für die Abfertigung eines Transportauftrages können als Summe der Zeitaufwände einzelner Transport- bzw. Handlungsschritte addiert werden. • FunktionKostet Mit dem Prädikat FunktionKostet kann eine Auskunft über die Kosten einer bestimmten Funktion erteilt werden. Beispielsweise können Kosten für das Wiegen an einer automatisierten Waage durch die Verzögerung aufgrund einer Warteschlange ansteigen. Diese Information kann einer TE als Entscheidungsbasis dienen, um zwischen mehreren Waagen mit verschieden hohen Kosten die günstigste Alternative auswählen zu können. Die bereits genannten Begriffe der Funktionenontologie können für konkrete Anwendungsfälle erweitert und verfeinert werden. Spezielle Funktionen werden dabei vom Konzept Funktion abgeleitet. Exemplarisch werden in Abb. 10.1 die Konzepte

10  Eine Ontologie für das Internet der Dinge

85

Lagern, Puffern und Transport dargestellt. Weitere Beispiele für spezielle Funktionen sind Gewichtskontrolle, Sicherheitskontrolle, Konturenkontrolle oder Verpackung. 10.2.1.3  Workflowontologie Während sich die Funktionenontologie auf die Abarbeitung einzelner Arbeitsschritte bezieht, ermöglicht die Workflowontologie die Formulierung und Vergabe komplexer Arbeitsabläufe. • Workflow Das Konzept Workflow repräsentiert einen Arbeitsablauf für Transporteinheiten. Ein Arbeitsablauf kann aus einem oder mehreren Arbeitsschritten bestehen. Die Schritte können in einer fest vorgegebenen oder in einer frei wählbaren Reihenfolge abgearbeitet werden. Konkrete Ausprägungen eines Arbeitsablaufs werden vom Konzept Workflow abgeleitet. • Workflowschritt Im einfachsten Fall besteht der Arbeitsablauf aus einem einzelnen Arbeitsschritt. Dieser bezieht sich auf genau eine Funktion, die für eine TE ausgeführt werden muss. Diese Funktion kann im System von mehreren Modulen oder Diensten angeboten werden, so dass die referenzierte TE selbst entscheidet, von welchem Modul oder Dienst diese Funktion erbracht werden soll. Die Angabe der Transporteinheit ist allerdings optional, so dass ein generischer Arbeitsschritt formuliert werden kann. • Workflowsequenz, Alternativworkflow Ein Arbeitsablauf kann aus mehreren Unterabläufen zusammengesetzt werden. Wie die einzelnen Arbeitsschritte können die Unterabläufe in einer fest vor­ gegebenen oder flexiblen Reihenfolge nacheinander ausgeführt werden. Sol­‑ che sequenziellen Arbeitsabläufe werden mit dem Konzept Workflowsequenz abgebildet. Besteht ein Arbeitsablauf aus zwei oder mehreren Unterabläufen, die alternativ zueinander abgearbeitet werden sollen, so sprechen wir über einen Alternativworkflow. • WorkflowAusführen Mit der Aktion WorkflowAusführen wird eine TE mit der Ausführung eines Arbeitsablaufs beauftragt. Der Arbeitsablauf kann auch während der Durchführung modifiziert oder neu erteilt werden.

10.2.1.4  Transportontologie Der Transport ist eine der wichtigsten Aufgaben eines Materialflusssystems und eine Funktion, die von den meisten Modulen einer Anlage gewährleistet wird. Aus diesem Grund werden die Begriffe, die zur Realisierung der Transportfunktion benötigt werden, in einer speziellen Transportontologie hervorgehoben.

86

S. Libert et al.

• Transportauftrag Das Konzept Transportauftrag stellt einen speziellen Arbeitsschritt dar, über welchen zwei Orte, ein Startort und ein Zielort, im System miteinander verknüpft werden. Zur Ausführung des Transportauftrages wird die Funktion Transport benötigt. • Transport Die Aufgabe der Transportfunktion besteht in der Ausführung eines Fahrauftrages durch ein Modul. Entsprechend dem Fahrauftrag wird eine Transporteinheit zwischen zwei Orten dieses Moduls befördert. • Ort Ein Ort ist eindeutig durch seine Adresse identifiziert. Diese kann sowohl eine absolute Adresse in einem Koordinatensystem als auch eine logische Adresse sein. Orte sind jeweils einem Modul zugeordnet und repräsentieren besondere Positionen auf diesem Modul, wie beispielsweise Kontroll- oder Handhabungsstationen. • Übergabepunkt Ein spezieller Fall eines Ortes ist der Übergabepunkt, der mehreren Modulen zugeordnet ist. Das Konzept Übergabepunkt modelliert die materialflusstechnische Schnittstelle eines Moduls, welche die Übergabe einer Transporteinheit von einem Modul zum Nächsten ermöglicht. • OrtGehörtZuModul Mit dem Prädikat OrtGehörtZuModul kann die Zugehörigkeit eines Ortes zu einem Modul dargestellt werden. Stimmt die Beziehung zwischen einem Ort und einem Modul, so nimmt das Prädikat den Wert wahr an. • IstNachfolger Das Prädikat IstNachfolger bezieht sich auf zwei Orte eines Moduls und ist wahr, wenn vom Vorgängerort der Nachfolgerort erreicht werden kann. • TEÜbergabeErlaubt Das Prädikat kapselt die Aussage, ob der Transport einer TE über einen Überga­ bepunkt erlaubt ist. Bei einem nicht trivialen Lastwechsel zwischen zwei Modulen können die Beteiligten über dieses Prädikat ihre Bereitschaft zur Übergabe abstimmen. • Pfad Das Konzept Pfad beschreibt einen möglichen Weg zwischen zwei Orten, welchen eine TE gemäß einem Transportauftrag folgen kann. Um verschiedene Wege miteinander vergleichen zu können, werden Pfade mit Kosten belegt. Ein Pfad besteht aus einer Reihe von Orten, die einzelne Schritte auf dem Weg vom Startort zum Zielort darstellen. Ein möglicher Pfad lässt sich beispielsweise als Folge von Übergabepunkten entsprechender Fördertechnikmodule realisieren. • PfadRealisiertAuftrag Das Prädikat PfadRealisiertAuftrag definiert eine Beziehung zwischen einem Transportauftrag und einem Pfad. Ein sinnvoller Einsatz dieses Prädikates ist die Realisierung einer Routensuche. • TEGeortet Mit diesem Prädikat kann Information über den aktuellen Aufenthaltsort einer TE ausgetauscht werden. Besitzt beispielsweise eine TE keine Ortungsfunktion,

10  Eine Ontologie für das Internet der Dinge

87

so kann der entsprechende TE-Agent von einem Modulagent über sein Aufenthaltsort informieren werden. Die hier vorgeschlagene Basisontologie definiert die wichtigsten Begriffe, die für die Modellierung und Steuerung von Materialflusssystemen notwendig sind sowie die Beziehung zwischen diesen Begriffen. Die Erweiterbarkeit der Begriffsbasis wird durch den Vererbungsmechanismus gewährleistet. Darüber hinaus können die bereits bestehenden Begriffe durch weitere Konzepte, Prädikate oder Aktionen ergänzt werden, so dass spezielle Ontologien, beispielsweise für Prozesse im automatisierten Lager, entstehen.

10.2.2  Kommunikationsmodell Die Anwendung der Ontologie für die Kommunikation in einer agentenbasierten Materialflusssteuerung wird anhand eines Kommunikationsmodells erläutert. Das Modell wird in Form eines speziellen Klassendiagramms in Abb. 10.2 dargestellt. In diesem Diagramm sind die Kommunikationsteilnehmer als Klassen und die Kommunikationsrichtung als Assoziationspfeile zwischen diesen Klassen abgebildet (vgl. Cossentino u. Potts 2002). Jede Kommunikation wird durch eine Assoziationsklasse dargestellt. Sie stellt die Instanzen der zwei beteiligten Agenten in Beziehung und schafft eine Korrespondenz zwischen deren Wissen. <> WorkflowAusführen

<> PfadRealisiertAuftrag -Protocol : QUERY

-Protocol : REQUEST

<> Rounting-Dienst

<> PfadRealisiertAuftrag

<> TE-Agent

<> BietetFunktion -Protocol : QUERY <> FunktionKostet -Protocol : QUERY

<> TEGeortet -Protocol : INFORM

<> FunktionAnweden -Protocol : REQUEST

-Protocol : QUERY

<> TEÜbergabeErlaubt -Protocol : QUERY

<> IstNachfolger -Protocol : QUERY <> OrtGehörtZuModul -Protocol : QUERY

<> Auftragsmanager

<> FunktionKostet -Protocol : QUERY

<> ModulAgent

Abb. 10.2   Kommunikationsontologie für das Internet der Dinge

<> FunktionAnwenden -Protocol : REQUEST

88

S. Libert et al.

Die Kommunikationsteilnehmer sind die Agenten eines Internet-der-DingeSteuerungssystems. In dem vorliegenden Kommunikationsmodell sind neben den bereits genannten Transporteinheit- und Modul-Agenten folgende weitere Entitäten definiert: • Auftragsmanager-Dienst Der Auftragsmanager realisiert eine Schnittstelle zur Planungsebene, z. B. einem Lagerverwaltungssystem und vermittelt die Arbeitsaufträge an die Agentensteuerung. • Routing-Dienst Eine mögliche Umsetzung der Wegsuchfunktion sind ein oder mehrere Dienste mit der Aufgabe, die Systemtopologie zu überwachen und die Weganweisungen den Transporteinheiten per Anfrage zur Verfügung zu stellen. Alternativ dazu kann die Wegsuchfunktion innerhalb der jeweiligen Modulagenten (z. B. Weiche, Verschiebewagen) realisiert werden. Für eine bessere Übersicht wird in dem vorliegenden Modell der erste Einsatz weiter verfolgt. In Abb. 10.2 wird jede Kommunikation mit einem Protokoll charakterisiert. Eine einfache Nachrichtenübermittlung wird dabei mit dem Sprechakttyp INFORM gekennzeichnet. Für komplexere Nachrichtenstrukturen werden FIPA Interaktionsprotokolle verwendet. Zwei weitere Aspekte der Agentenkommunikation – Ontologie und Sprache – werden nicht speziell notiert: Die Ontologie ist für alle Kommunikationen dieselbe (Basisontologie des Internet der Dinge) und die Sprache kann vom Entwickler zu einem späteren Zeitpunkt festgelegt werden. Im Weiteren wird die Kommunikation anhand von typischen Steuerungsabläufen erläutert. • Workflow initialisieren oder ändern Ein Auftragsmanager-Dienst beauftragt jede Transporteinheit mit einem Arbeitsablauf (WorkflowAusführen), beispielsweise beim Betreten des Systems oder wenn eine Auslagerung angestoßen wird. Die Beauftragung des TE-Agenten erfolgt über das FIPA Request Protokoll. • Modulsuche Die Transporteinheit muss für jeden Einzelschritt des Arbeitsablaufs das Modul finden, das die notwendige Funktion zum niedrigsten Preis anbietet. Im einfachsten Fall kann diese Kommunikation über Abfragen von angebotenen Funktionen und Kosten (BietetFunktion, FunktionKostet) mit dem FIPA Query Protokoll realisiert werden. Betrachtet man das Vorgehen als Auktion, bei der der TEAgent Gebote von mehreren Modulagenten einholt und miteinander vergleicht, so kann diese Verhandlung über das FIPA Contract Net Interaction Protockoll geregelt werden. Bei der Kostenbewertung können die Transportkosten bis zu den betreffenden Anbietern berücksichtigt werden. • Wegsuche Um einen Pfad von der aktuellen Position zu einem bestimmten Modul bzw. Ort zu finden, kann der TE-Agent einen Routing-Dienst befragen (PfadRealisiertAuf­ trag). Gemäß dem Query-Protokoll werden, falls vorhanden, einer oder mehrere solcher Pfade als Antwort zurück gegeben. Bei einer verteilten Wegsuchfunktion

10  Eine Ontologie für das Internet der Dinge

•

•

•

•

89

können mehrere Routing-Dienste (z. B. einer pro Verteilelement) untereinander Informationen austauschen. Topologieerzeugung Damit eine Wegsuche überhaupt möglich ist, müssen die Zugehörigkeit von Orten zu Modulen, die Abfolge von Modulen sowie die Transportwege durch Module bekannt sein. Zu berücksichtigen ist dabei die Kosteninformation, die sich unter Umständen dynamisch ändern kann. Die entsprechenden Kommunikationen (OrtGehörtZuModul, IstNachfolger und FunktionKostet) können beispielsweise über das Query-Protokoll umgesetzt werden. Transport, Anwenden von Funktionen Wurde für einen Transportauftrag ein Pfad bzw. nächster Transportschritt ausgewählt, muss die TE das entsprechende Modul auffordern, sie zu ihrem Ziel zu befördern. Ist die Transporteinheit beim Zielmodul angelangt, muss die im Workflow spezifizierte Funktion vom Modul ausgeführt werden. Sowohl für den Transport als auch für die weiteren Funktionen wird die Aktion FunktionAnwenden über das Request-Protokoll aufgerufen. Auf dieselbe Weise können auch Module untereinander Funktionen anfordern, beispielsweise wenn eine Katze in einem Elektrohängebahn-System das Schalten einer Weiche veranlassen muss. Transporteinheit orten Während des Transports durch die Anlage kann eine TE an verschiedenen Orten mit einem Barcode-Scanner oder RFID-Reader identifiziert oder mit anderen Sensoren an einer bestimmten Position geortet werden. Das entsprechende Modul soll dabei die Transporteinheit über ihre aktuelle Position informieren (TEGeortet). Lastwechsel Beim Wechseln einer TE zwischen zwei Modulen ist häufig eine Abstimmung zwischen den beteiligten Modulen erforderlich. Die Synchronisation der Übergabe (TEÜbergabeErlaubt) kann über das Query-Protokoll realisiert werden.

10.3  Validierung In diesem Abschnitt wird die vorgestellte Ontologie für eine agentenbasierte Materialflusssteuerung anhand eines konkreten Beispielszenarios validiert. Bei diesem Szenario handelt es sich um typische Abläufe, die in einem Palettenlager stattfinden. Im Folgenden wird zunächst der logistische Prozess in einer stark vereinfachten Form dargestellt. Des Weiteren werden die Akteure vorgestellt, die als Steuerungsagenten und Systemdienste modelliert werden. Anschließend wird das Kommunikationsszenario anhand eines Sequenzdiagramms erläutert. Das Szenario beschreibt die Abläufe rund um eine Palette vom Eintritt dieser Palette in das System bis zur Einlagerung. Eine Palette betritt das System und wird an dem Wareneingang (I-Punkt) identifiziert. Nach der Identifizierung wird der Palette ein Lagerfach bzw. ein Lagerbereich zugeordnet. Ein Stapler übernimmt den

90

S. Libert et al.

Transport zu einem freien Übergabeplatz in der Lagervorzone. Die Fördertechnik führt einen weiteren Transport zu einem Querverteilwagen durch. Zum Zweck der Einlagerungskontrolle ist der Querverteilwagen mit einer Gewichts- und Konturenmessung ausgestattet. Zum Schluss wird die Palette an einem Übergangsplatz eines Regalbediengerätes abgestellt und schließlich eingelagert.

10.3.1  Akteure Zur Abbildung des skizzierten Ablaufs in einer Multiagentensteuerung werden im System folgende Entitäten definiert: • Auftragsmanager (Dienst) Der Auftragsmanager ist ein Schnittstellenagent, welcher einen Austausch von Auftragsdaten mit einem Lagerverwaltungssystem (LVS) realisiert. • Routing (Dienst) Ein Routing-Dienst kann als Funktion in den Modulagenten implementiert werden, ist allerdings in dem vorliegenden Beispielszenario als unabhängiger Systemdienst verfügbar. • Verzeichnis (Dienst) Das Verzeichnis ermöglicht die Suche nach Entitäten, die eine bestimmte Funktion anbieten. • I- Punkt (Modul) Dieses Modul stellt den Wareneingang dar und ist in der Lage, die das System betretenden Paletten über RFID oder Barcodes zu identifizieren. • Stapler (Modul) Stapler realisieren eine Transportverbindung zwischen dem I-Punkt und der Lagervorzone. Ein Staplersystem besteht aus mehreren Fahrzeugen, wobei jedes dieser Fahrzeuge als ein autonomes Modul bzw. Agent realisiert wird. • Fördertechnik (Modul) In diesem Szenario wird ein Abschnitt der Fördertechnik zwischen einem Übergabeplatz und dem Querverteilwagen in der Lagervorzone als ein einziger Förderstreckenagent modelliert. • Querverteilwagen (Modul) Die Verteilung von Paletten von der Fördertechnik auf die Regalbediengeräte in der Lagervorzone wird von einem Querverteilwagen (QVW) mit integrierten Gewichts- und Konturenmessfunktionen durchgeführt. Ein QVW wird in der Steuerung ebenfalls als autonomer Softwareagent umgesetzt. • Palette(TE) Palettenagenten übernehmen eine führende Rolle in der gesamten Prozesssteuerung. Diese werden an der Systemgrenze (Wareneingang) erstellt. Danach folgen sie einem Arbeitsablauf auf dem Weg ins Lager und beauftragen die zu diesem Zweck erforderlichen Transportressourcen.

10  Eine Ontologie für das Internet der Dinge

91

10.3.2  Kommunikationsszenario Abbildung 10.3 stellt in einem Sequenzdiagram einen Kommunikationsablauf dar, welcher auf der IdD-Basisontologie aufbaut. Im Mittelpunkt des Kommunikationsszenarios steht eine Palette bzw. ein Palettenagent. Dieser Agent wird erzeugt, wenn die Palette an einem I-Punkt identifiziert wird. Mithilfe einer TEGeortetNachricht wird der Palettenagent über den aktuellen Standort benachrichtigt. Die gleiche Nachricht triggert die Vergabe eines Auftrages von dem Auftragsmanager (WorkflowAusführen). Dabei besteht der Arbeitsablauf aus zwei wesentlichen Schritten: Konturenmessung und Einlagerung, die die Ausführung entsprechender Funktionen im System erwarten. Ein weiterer Arbeitsschritt Transport wird dazwischen geschaltet, um die Beförderung der Palette zwischen den Zielorten zu gewährleisten. Der Palettenagent fängt die Ausführung seines Arbeitsablaufs mit der Abfrage des Verzeichnis-Dienstes an. Ziel dieser Abfrage ist es, die Adressen der Module zu finden, welche die Konturenmessung anbieten (BietetFunktion). Durch eine direkte Anfrage an die entsprechenden Module können nun die Kosten für die Funktion ermittelt (FunktionKostet) und miteinander verglichen werden. Für bessere Übersicht wird in dem Diagramm nur ein QVW-Modul dargestellt, welcher die Funktion Konturenmessung realisiert. Bei der Suche nach dem Weg zu dem Querverteilwagen kommuniziert der Palettenagent mit dem Routing-Dienst (PfadRealisiertAuftrag). Der Routing-Dienst verfügt über erforderliche Weginformationen, die bei Systeminitialisierung gesammelt worden sind (IstNachfolger, OrtGehörtZuModul) und stetig aktualisiert werden. Eine zusätzliche Abfrage über aktuelle Transportkosten ermöglicht es dabei, eine optimale Route zu planen (FunktionKostet). Die Beförderung der Palette erfolgt in mehreren ähnlichen Schritten: Ein Fahrauftrag wird an das entsprechende Transportmodul erteilt (FunktionAnwenden(Transport)). Nach der Ortung der Palette an einem neuen Ort (TEGeortet) wird der Transportvorgang fortgesetzt, solange die Palette ihren Zielort nicht erreicht hat. Gelingt es der Palette an dem Querverteilwagen anzukommen, so wird der Palettenagent den ersten Schritt seines Arbeitsablaufs, die Konturenmessung, ausführen, indem er die entsprechende Funktion von dem QVW-Agenten anfordert (FunktionAnwenden(Konturenkontrolle)). Der Vorgang wird auf ähnliche Weise fortgeführt, bis die Palette an der Position ankommt, wo sie eingelagert werden kann. Das vorgestellte Szenario hat keinen Anspruch auf Vollständigkeit. Die skizzierten Abläufe dienen allein dem Zweck, die Anwendbarkeit der Ontologie in der agentenbasierten Steuerung zu demonstrieren. Das Szenario zeigt dennoch, dass sich viele Prozesse im Lager mit dem vorgeschlagenen Ansatz leicht modellieren lassen. Auch viele weitere Abläufe können mit der Basisontologie dargestellt werden, obwohl für bestimmte Sondersituationen eine Erweiterung bzw. Spezialisierung der Ontologie und ggf. der Kommunikationsprotokolle erforderlich sein kann.

Stapler

21: REQUEST: FunktionAnwenden(Konturekontrolle)

20: INFORM: TEGeortet

17: REQUEST: FunktionAnwenden(Transport)

16: INFORM: TEGeortet

13: REQUEST: FunktionAnwenden(Transport)

12: QUERY: FunktionKoset(Transport)

11: QUERY: FunktionKoset(Transport)

10: QUERY: PfadRealisiertAuftrag

9: QUERY: FunktionKostet(Konturenkontrolle)

14: Transport

Fördertechnik

QVW

19: QUERY: TEÜbergabeErlaubt

18: Transport

15: QUERY: TEÜbergabeErlaubt

3: QUERY: IstNachfolger, OrtGehörtZuModul

2: QUERY: IstNachfolger, OrtGehörtZuModul

8: QUERY: BietetFunktion(Konturenkontrolle)

Palette

Verzeichnis

1: QUERY: IstNachfolger, OrtGehörtZuModul

Routing

Abb. 10.3   Einsatz von Ontologien in einem Beispielszenario

7: REQUEST WorkflowAusführen (Konturenkontrolle, Einlagerung)

5: INFORM: TEGeortet

4: Instanziieren

I-Punkt

6: INFORM: TEGeortet

Auftragsmanager

92 S. Libert et al.

10  Eine Ontologie für das Internet der Dinge

93

10.4  Zusammenfassung Die in diesem Kapitel vorgestellte Ontologie legt die Grundlage für die Modellierung der Kommunikation zwischen autonomen Entitäten in einer dezentralen Materialflusssteuerung. Die wichtigsten Begriffe zum Erteilen von Aufträgen, für die Informationsgewinnung und die Beschreibung steuerungsrelevanter Informationen sind definiert und mit Aktionen, Prädikaten und Konzepten in der Basisontologie abgebildet. Der Einsatz der Ontologie in einer agentenbasierten Steuerung wird anhand eines Kommunikationsmodells erläutert. Dabei baut jede Kommunikation zwischen zwei Teilnehmern auf einem Ontologieelement auf und ist mit einem Kommunikationsprotokoll versehen. Die Validierung erfolgt anhand eines konkreten Beispielszenarios, indem Prozesse in einem Palettenlager in Form eines Kommunikationsablaufs und mit Hilfe der Basisontologie modelliert werden. Die Basisontologie für das Internet der Dinge legt das wesentliche Vokabular fest, welches die Modellierung und Umsetzung vieler Steuerungsaufgaben ermöglicht. Die Begriffe werden so abstrakt gehalten, dass die Allgemeingültigkeit erhalten bleibt und damit ein breites Einsatzspektrum ermöglicht wird. Eine Spezialisierung der Basisontologie kann dennoch für bestimmte Anwendungsfälle erforderlich sein. Zu diesem Zweck müssen die bestehenden Begriffe durch Ableitung erweitert werden. Eine weitere Möglichkeit besteht in der Ergänzung der Basisontologie durch neue Begriffe und Beziehungen zwischen diesen. Auf diese Weise können neue Ontologien für spezielle Anwendungsfälle und Sonderprozesse entstehen.

Kapitel 11

Softwarearchitektur für eine agentenbasierte Materialflusssteuerung Sergey Libert, Razvan Chisu und Artur Luft

11.1  Anforderungen Eine der grundlegenden technischen Voraussetzungen für die Realisierung und den erfolgreichen Einsatz des Internet der Dinge in der Industrie ist eine allgemeingültige, erweiterbare und nicht zuletzt einfach handhabbare Softwarearchitektur. Diese muss sowohl die Interaktion und das Management zahlreicher Entitäten als auch die einfache Implementierung neuer Agenten gewährleisten. Dabei muss die Software einem hohen Qualitätsstandard genügen und vor dem Einsatz ausgiebig getestet werden. Denn gerade im industriellen Bereich können unentdeckte Softwarebugs zu sehr teuren und auch für Menschen gefährlichen Fehlfunktionen führen. Die Robustheit und Zuverlässigkeit der Steuerungslogik sind also von zentraler Bedeutung. Doch auch die Funktionalität und vor allem die einfache Konfigurierbarkeit bzw. Erweiterbarkeit sind als sehr wichtig einzustufen. Materialflusssysteme müssen sehr unterschiedliche Prozesse realisieren und bauen dabei auf eine große Vielfalt mechanischer Komponenten auf. Da Erweiterungen und Modifikationen der Software häufig zu erwarten sind, müssen die eingesetzten Bibliotheken bzw. der angestrebte Agentenbaukasten so gestaltet sein, dass ein großer Anteil der Anpassungen durch reine Konfigurierung erfolgen kann. Darüber hinaus müssen auch komplett neue Funktionsblöcke mit möglichst geringem Aufwand in die bestehende Logik integriert werden können. Ein dritter sehr relevanter Aspekt, der im industriellen Einsatz zum Tragen kommt, ist die Recheneffizienz und Skalierbarkeit der Software. Entscheidungen in Materialflusssystemen müssen oftmals sehr schnell getroffen werden, wobei solche Systeme sehr komplex werden bzw. aus einer sehr großen Anzahl an Agenten bestehen können. Daher müssen die Systemarchitektur und die einzelnen Steuerungsalgorithmen so gestaltet werden, dass ihre Performanz von der Anlagengröße weitestgehend unabhängig sind.

S. Libert () Lehrstuhl für Förder- und Lagerwesen, Technische Universität Dortmund Emil-Figge-Str. 73, 44221 Dortmund, Deutschland e-mail: [email protected] W. Günthner, M. ten Hompel (Hrsg.), Internet der Dinge in der Intralogistik, DOI 10.1007/978-3-642-04896-8_11, © Springer-Verlag Berlin Heidelberg 2010

95

96

S. Libert et al.

Das vorliegende Kapitel beginnt mit einer kurzen Übersicht heutiger Materialflusssteuerungen und leitet aus deren Defiziten Anforderungen für eine flexible, skalierbare und robuste dezentrale Steuerungsarchitektur ab. Auf Grundlage existierender Standards und Vorgaben für allgemeine Multiagentensysteme wird eine agentenbasierte und hierarchielose Anlagensteuerung vorgeschlagen. Diese ist in der Lage, Module, Transporteinheiten und Dienste abzubilden und minimiert dabei den Entwicklungsaufwand durch den durchgehenden Einsatz objektorientierter Programmiertechniken. Anschließend werden unterschiedliche Anforderungen bei der Steuerung logistischer und maschinennaher Prozesse untersucht, durch den Einsatz geeigneter Hard- und Softwareumgebungen adressiert und in einem schlüssigen Gesamtkonzept kombiniert.

11.2  B  isherige Architekturmodelle für die Materialflusssteuerung In herkömmlichen Materialflusssteuerungen werden technische Komponenten, Systeme und Subsysteme mittels einer hierarchischen Struktur mit mehreren Ebenen umgesetzt (vgl. Jünemann u. Beyer 1998). Diese Strukturmodelle dienen zur Vereinfachung der Koordination einzelner Hersteller bei der Planung und Ausführung von Materialflusssystemen. Das Ebenenmodell nach dem VDMA-Einheitsblatt 15276 „Datenschnittstellen in Materialflusssteuerungen“ gliedert die Materialflusssteuerung in insgesamt sechs Ebenen mit festgelegter Funktionalität und Schnittstellen: • • • • • •

Ebene 6: Darstellung und Kommunikation, Ebene 5: Systemsteuerung, Ebene 4: Subsystemsteuerung, Ebene 3: Bereichsteuerung, Ebene 2: Elementsteuerung, Ebene 1: Antriebe und Sensoren.

Diese Ebenen können je nach Systemkomplexität einzeln aber auch zusammengefasst auf einer Hardwareplattform realisiert werden. Dabei wird das operative Ansteuern von Sensoren und Aktuatoren häufig auf mehrere Speicherprogrammierbare Steuerungen (SPS) verteilt, während die strategischen Aufgaben wie zum Beispiel die Auftragsdisposition oder die Transportkoordination von einem zentralen Materialflussrechner übernommen werden. Die vom Forum Intralogistik des VDMA entwickelte Systemarchitektur für die Intralogistik (SAIL) spezifiziert eine andere Form hierarchischer Steuerung, die auf einer funktionsorientierten Gestaltung intralogistischer Systeme beruht (vgl. Thomas 2008). Die Anlagensteuerung besteht dabei nicht mehr aus Ebenen, sondern aus den folgenden standardisierten Funktionen: • Anlagensteuerung, • Informationsgewinnung,

11  Softwarearchitektur für eine agentenbasierte Materialflusssteuerung

97

• Richtungssteuerung, • Fahrtauftragsverwaltung, • Ressourcennutzung. Ein Steuerungssystem besteht in diesem Fall aus mehreren Softwarekomponenten, wobei jede Komponente jeweils eine SAIL-Funktion realisiert. Die Komponenten haben einheitliche Schnittstellen, die zur Übertragung von Parametern, Steuerdaten, Aufträgen, Quittierungen, Statuswerten und Diagnosedaten dienen. Das SAIL-Modell strebt durch die einheitliche Darstellung von Funktionen und Komponenten eine verbesserte Transparenz von Materialflusssystemen an und ermöglicht eine bessere Strukturierung des Aufgabenbereiches. Durch SAIL wird eine technikbedingte Hierarchie der Steuerung aufgelöst, allerdings wird diese durch eine funktionale Hierarchie ersetzt. Bei allen hierarchischen Systemen führt die Konzentration der gesamten höherwertigen Logik in einem oder wenigen zentralen Systemen zwangsläufig zu einer Komplexität, die nur mit großem Aufwand zu beherrschen ist. Zahlreiche Subsysteme und Komponenten müssen projekt- und kundenspezifisch ausgelegt, integriert und mit großem Aufwand aufeinander abgestimmt werden. Die hohen Aufwände sind zudem nicht nur bei der Erstrealisierung sondern insbesondere bei jeder Erweiterung und jedem Umbau des Systems zu bewältigen. Daher sind neue Architekturen notwendig, die den Anforderungen heutiger Materialflusssysteme gerecht werden.

11.3  Agentenbasierte Materialflusssteuerung Im Gegenteil zu gängigen Steuerungsarchitekturen stellt das Internet der Dinge die Vision eines hierarchielosen Steuerungsprinzips aus kooperierenden autonomen Einheiten dar. Diesem Prinzip liegt eine dezentrale Steuerungsarchitektur zugrunde, die sich mit Hilfe der Agententechnologie realisieren lässt (vgl. Abschn. 2.3 Softwaretechnik).

11.3.1  Referenzarchitekturen für Multiagentensysteme Eine agentenbasierte Materialflusssteuerung stellt ein Softwaresystem dar, welches aus Softwareagenten besteht. Das Ausführen und Verwalten von Agenten übernimmt eine spezielle Umgebung, die so genannte Softwareagentenplattform. Für Agentenmodelle (Agenten, Agentensystem, Kommunikation zwischen den Agenten) und Anforderungen an Agentenplattformen existiert eine Reihe von Standards, die von mehreren Initiativen erarbeitet werden. Besonders relevant sind dabei der FIPA-Standard der Foundation for Intelligent Physical Agents (s. Foundation for Intelligent Physical Agents 2009) und die Mobile Agent Facility Specification (MAF) der Object Management Group (OMG) (s. Object Management Group 2009).

98

S. Libert et al.

11.3.1.1  FIPA Agent Management Reference Model Ein allgemeines Referenzmodell für Multiagentensysteme wird in der FIPA Management Specification (s. Foundation for Intelligent Physical Agents 2000b) festgelegt. Dieses Modell beschreibt eine abstrakte Agentenplattform und definiert Dienste für die Erzeugung, Registrierung, Auffindung, Kommunikation sowie für das Vernichten von Agenten. In dem Agent Management Reference Model (s. Abb. 11.1) ist jeder Agent mit einem eindeutigen Agentenidentifikator (AID) gekennzeichnet, welcher im Agent Management System (AMS) verwaltet wird. Zusätzlich überwacht das AMS die Agentenlaufzeitumgebung und realisiert mit einem Lifecycle Service den Agentenlebenszyklus. Der Directory Facilitator (DF) stellt einen Verzeichnisdienst bereit. Agenten können sich mit ihrem Angebot an Diensten beim DF anmelden und auch Auskünfte über die Dienstprofile anderer Agenten erhalten. Die Kommunikation zwischen den Agenten verläuft über das Message Transport System (MTS). Bei einer verteilten Agentenapplikation oder bei mehreren Agentenapplikationen auf unterschiedlichen Plattformen unterhalten sich die jeweiligen Agenten über die MTS ihrer Plattform. Gemeinsam bilden AMS, DF und MTS eine Agentenplattform und realisieren die Agent Management Services der FIPA. AMS und DF werden dabei selbst als Agenten umgesetzt. Die Kommunikation mit einer angrenzenden, nicht agentenorientierten Software wird dabei nicht weiter spezifiziert. 11.3.1.2  Mobile Agent Facility Specification Während die FIPA-Standards die Systemarchitekturen und die Kommunikation für intelligente Agenten spezifizieren, stehen in der MAF-Spezifikation das

Software

Agent Platform

Agent

Agent Management System

Message Transport System

Agent Platform Directory Facilitator

MTS

Abb. 11.1   Agent Management Reference Model der FIPA (vgl. Foundation for Intelligent Physical Agents 2000b)

11  Softwarearchitektur für eine agentenbasierte Materialflusssteuerung

99

CORBA Facilities MAFClient

MAFClient

MAFAgent System

MAFFinder

...

ORB

Naming

Lifecycle

Externalization

Security

...

CORBA Services

Abb. 11.2   Einordnung von MAF in die Object Management Architecture (vgl. Horn u. Reinke 2005)

Management von mobilen Agenten und die Agentenmigration im Vordergrund (vgl. Milojicic et al. 1999). Die MAF-Spezifikation baut auf dem CORBA-Standard auf und erweitert diesen um agentenspezifische Konzepte und Funktionen. Eine agentenorientierte Applikation kann somit die CORBA-Infrastruktur (ORB und CORBA-Services) und deren Vorteile nutzen. Die Einordnung von MAF in die CORBA-Infrastruktur wird in Abb. 11.2 erläutert. Ein MAF-Client stellt dabei eine agentenorientierte Applikation dar. Die Mobile Agent Facility besteht aus dem Mobile Agent System und dem Mobile Agent Finder. Das Mobile Agent System definiert eine IDL-Schnittstelle zum Erzeugen, Vernichten und Transferieren von Agenten. Der MAF-Finder dient der Suche von Agenten und ihrer Schnittstellen und liegt ebenfalls als IDL-Spezifikation vor. 11.3.1.3  Bewertung und Vergleich Für die Entwicklung einer agentenbasierten Steuerung für industrielle Anwendungen eignet sich der FIPA-Standard am besten. Im Gegensatz zu anderen Spezifikationen ist FIPA detailliert dokumentiert, umfasst alle wesentlichen Aspekte von Multiagentensystemen, bietet ein Modellierungskonzept auf Basis von UML 2.0 (vgl. Foundation for Intelligent Physical Agents 2007) und wird mit einer Vielzahl von Entwicklungswerkzeugen unterstützt.

  Die Common Object Request Broker Architecture (CORBA) ist eine Middleware-Architektur, die ebenfalls von der OMG standardisiert ist.   Die Interface Definition Language (IDL) ist eine Schnittstellenbeschreibungssprache. Die CORBA-IDL ist eine speziell für CORBA angepasste IDL.

100

S. Libert et al.

Die MAF-Spezifikation definiert einige im FIPA-Standard bereits festgelegte Begriffe neu. Die Systemfunktionen wie die Verwaltung des Agentenlebenszyklus, Agentenidentifikation und Namengebung werden hier CORBA-konform spezifiziert. Dennoch kann MAF als eine Erweiterung des FIPA-Standards angesehen werden, die zusätzliche Systemeigenschaften wie die Agentenmobilität und Sicherheit in den Mittelpunkt der Betrachtung stellt.

11.3.2  Abstraktes Architekturmodell für das Internet der Dinge Die Referenzarchitektur der FIPA-Spezifikation wurde in mehreren Agentenplattformen umgesetzt, beispielsweise FIPA-OS (s. Emorphia Ltd. 2009), Jade (s. Telecom Italia Lab 2009), Tryllian Agent Development Kit (s. Tryllian 2009) und einige weitere. Diese Laufzeitumgebungen für Softwareagenten nehmen dem Entwickler die Realisierung allgemeiner Verwaltungsaufgaben in einem Agentensystem ab und garantieren die Kompatibilität mit den bestehenden Agentenstandards. Die Steuerungsagenten im Internet der Dinge existieren in einer verteilten Plattform, welche nach den Konventionen der FIPA-Referenzarchitektur realisiert wird. Für die Kommunikation untereinander benutzen die Steuerungsagenten die Mechanismen, die die Agentenplattform zur Verfügung stellt. Die Integration des Agentensystems in seine automatisierungstechnische Umgebung wird im Folgenden anhand eines abstrakten Architekturmodells erläutert (s. Abb. 11.3). Für die Realisierung der Agentenlogik für komplexe Steuerungsaufgaben bietet sich z. B. der Einsatz so genannter IPC (Industrie-PC), einer PC-ähnlichen Rechenplattform, an. Dank der PC-basierten Architektur dieser Steuerungsrechner können Steuerungsagenten und die Agentenplattform in einer höheren Programmiersprache Nachbarschaftssystem

Steuerungsrechner

SR

SR

SR

SR

SR

Verteilte Agentenplattform TE-Agent Schnittstellen -agent

TE-Agent

TE-Agent Modulagent

Abstraktionsschicht

Legende: TE–Transporteinheit SR-Steuerungsrechner

Technische Anlage

Sensoren

Aktoren

Abb. 11.3   Architekturmodell für agentenbasierte Steuerung

Dienstagent Dienstagent

11  Softwarearchitektur für eine agentenbasierte Materialflusssteuerung

101

realisiert werden. Dabei wird auf jedem Steuerungsrechner ein Teil einer verteilten Agentenplattform installiert und ein oder mehrere Agenten instanziiert. Die Verteilung der Agentenplattform auf mehrere Steuerungsrechner hält die Rechnerauslastung gering und erlaubt den Einsatz leistungsschwächerer und somit günstigerer Hardware. Erst diese Verteilung ermöglicht das Zusammensetzen mechatronischer Module (mechanische Einheit + Rechnereinheit + Steuerungseinheit) und, als Folge, einen problemlosen Modulaustausch (s. a. Kap. 12). Während die Agentenplattform eine Grundfunktionalität für Verwaltung und Kommunikation in einer agentenbasierten Steuerung anbietet, entsteht die eigentliche Steuerungslogik durch Interaktion einzelner Steuerungsagenten (vgl. Kap. 9). Im System sind mehrere Agententypen definiert, die im nachfolgenden Abschnitt beschrieben werden. Einen Sonderfall bilden dabei so genannte „Schnittstellenagenten“. Diese haben keinen direkten Einfluss auf die Materialflusssteuerung an sich, ermöglichen aber den Datenaustausch (Aufträge, Strategievorgaben, Statuswerte usw.) mit benachbarten IT- und Steuerungssystemen, die nicht nach Konventionen des Internet der Dinge aufgebaut sind. Diese Schnittstellenagenten können als „Adapter“ aufgefasst werden, welche die Anpassung externer Protokolle und Nachrichteninhalte übernehmen. Zeitkritische Aufgaben zur Ansteuerung von Sensoren und Aktoren einer intralogistischen Anlage werden aus verschiedenen Gründen nicht im Agenten sondern in herkömmlichen SPS-Programmen implementiert. Diese maschinennahe Steuerung der technischen Anlage sowie eine zwischen Maschinensteuerung und Agent vermittelnde Abstraktionsschicht werden in diesem Kapitel im Abschnitt „Echtzeitsteuerung von Modulagenten“ eingehend erklärt.

11.3.3  Modellierung der Steuerungsagenten Nachdem die abstrakte Systemarchitektur festgelegt ist, werden nun in einem weiteren Schritt die Agenten modelliert, welche eine dezentrale Steuerungslogik im Internet der Dinge bewerkstelligen. Den Ausgangspunkt für diese Modellierung bieten die funktionalen Komponenten des Systems, so wie sie in Kap. 8 definiert sind. Die elementare Einheit des Internet der Dinge wird als Entität bezeichnet und beinhaltet sowohl den Softwareagenten als auch, im Fall der Module, physikalische und elektrische Bauteile. Die nachfolgenden Betrachtungen fokussieren jedoch nur den Aufbau der Software. Module, Transporteinheiten und Dienste stellen eine erste Stufe der Spezialisierung einer Entität dar. Diese drei Klassen können wiederum und in beliebig vielen Stufen weiter spezialisiert werden, bis ein Agent die gewünschte Funktionalität erbringt und für die Steuerung einer Anlagenkomponente genutzt werden kann. Diese Vererbungsbeziehungen können in Form eines einfachen Klassendiagramms dargestellt werden (s. Abb. 11.4).

102

S. Libert et al.

Entität

Transporteinheit

Stetigförderer

Unstetigförderer

Modul

Verzweigung, Zusammenführung

Dienst

Arbeitsstation

Lagerfach

Abb. 11.4   Vererbung der Agenten im Internet der Dinge

Dienste und vor allem Module können dabei als Dienstleister angesehen werden, die auf Anfrage einer Transporteinheit oder eines anderen Moduls eine bestimmte Funktion ausführen. Die gesamte Interaktion zwischen den Entitäten des Internet der Dinge kann also als dynamischer Marktplatz aufgefasst werden, in dem verschiedene Dienstleistungen bzw. Funktionen gesucht, angefordert und erbracht werden. Dabei sind im einfachsten Fall Transporteinheiten als Kunden bzw. Funktionsnutzer, Dienste als Anbieter bzw. Funktionserbringer und Module sowohl als Kunden als auch als Anbieter anzusehen. Diese Situation kann aber nicht als allgemeingültig angesehen werden: In Systemen mit komplexeren Abläufen kann es durchaus sinnvoll oder gar notwendig sein, Transporteinheiten ebenfalls als Funktionsanbieter zu modellieren – soll beispielsweise eine Pulkfahrt realisiert werden, kann die erste Transporteinheit eine Führungsfunktion für den gesamten Zug übernehmen. Ebenso ist es möglich, Softwaredienste als Funktionsnutzer anzusehen, wenn sie beispielsweise andere Dienste benötigen, um korrekt zu funktionieren. Ein mögliches Beispiel ist hierbei ein Visualisierungsdienst, der wiederum auf einen Tracking- and TracingDienst zurück greifen muss, um die anzuzeigenden Daten zu besorgen. Im allgemeinsten Fall sind also alle Entitäten des Internets der Dinge sowohl Anbieter als auch Nutzer verschiedener Funktionsumfänge. Somit muss bereits die Entitätsklasse grundlegende Mechanismen zum Nachrichtenaustausch, zum Registrieren und Suchen von Funktionen und zum Abarbeiten festgelegter Kommunikations- und Interaktionsprotokolle, beispielsweise Auktionen, implementieren. Diese werden so gestaltet, dass sie zum einen allgemein genug sind, um beliebigen Situationen und Anforderungen innerhalb eines Materialflusssystems gerecht zu werden, zum anderen aber so stark ausdetailliert, dass sie möglichst direkt und ohne überflüssigen Konfigurationsaufwand verwendet werden können. Die Entitätsklasse ergänzt also die grundlegenden Funktionen eines Softwareagenten durch materialflussspezifische Kommunikationsfunktionen und -mechanismen und bietet

11  Softwarearchitektur für eine agentenbasierte Materialflusssteuerung

103

dem Programmierer eine einfache Möglichkeit zur Realisierung von Abläufen und Strategien für die Steuerung von Logistikprozessen. Transporteinheiten, Dienste und Module erben diese Funktionalität von der Entitätsklasse und ergänzen sie durch weitere, spezifische Fähigkeiten. Transporteinheiten besitzen eine Komponente zur Verwaltung von Arbeitsabläufen und evtl. zum Berechnen von Routen zu ihrem jeweiligen Zielort (s. a. Kap. 10). Diensten lässt sich, wegen ihrer sehr allgemeinen Natur, standardmäßig keine bestimmte Funktionalität zuordnen. Zwei typische Klassen von Diensten sind Schnittstellenagenten für die Kommunikation mit externen Systemen und HMI-Agenten, die es einem Systembediener erlauben, über eine GUI oder eine andere MenschMaschine-Schnittstelle mit dem Internet der Dinge bzw. den Softwareagenten zu interagieren oder diese zu überwachen. Module allerdings verdienen besondere Aufmerksamkeit, da sie sich einfacher als Transporteinheiten oder Dienste in verschiedene Kategorien mit mehreren Detaillierungsstufen und jeweils typischen Aufgaben gliedern lassen. Allen Modulen gemeinsam ist die Fähigkeit zur Ansteuerung und Überwachung mechanischer und elektrischer Komponenten. Darüber hinaus sind auch die Verwaltung der eigenen Belegung unter Berücksichtigung der Kapazitätsgrenzen und Abstimmungsmechanismen für die Lastübergabe Funktionen, die von sämtlichen Fördertechnikmodulen benötigt werden und daher in der Modulklasse implementiert werden. Darüber hinaus wird jedoch eine Differenzierung verschiedener Funktionsklassen notwendig, so wie sie in Kap. 8 beschrieben wurden.

11.3.4  Echtzeitsteuerung von Modulagenten Die für die Steuerungsagenten des Internet der Dinge eingesetzten Agentensysteme und Programmiersprachen aus dem PC-Bereich haben aus softwaretechnischer Sicht Vorteile gegenüber Automatisierungssprachen. Dabei ist jedoch zu beachten, dass sie die Anforderungen an die Steuerung von Fördertechnikmodulen nicht vollständig erfüllen. Denn das Überwachen und Ansteuern von Sensoren und Aktoren erfordert eine Reaktion in Echtzeit, die auf PC-Betriebssystemen und vor allem in Managed-Code-Laufzeitumgebungen wie .Net oder Java nicht immer möglich ist. Prinzipiell muss aber bei der Steuerung von Materialflusssystemen zwischen zwei Ebenen mit verschiedenen Echtzeitanforderungen unterschieden werden: zum einen die Auftragssteuerung auf der Systemebene – im Internet der Dinge abgebildet durch das Agentensystem – und zum anderen die maschinennahe Steuerung auf der Komponenten- bzw. Modulebene. Nur wenn beide aufeinander abgestimmt sind und in jedem Betriebszustand korrekt arbeiten, ist eine garantierte maximale Durchlaufzeit im Materialflusssystem sichergestellt. Dabei ist zu beachten, dass die Steigerung der Durchsätze auch immer höhere Fördergeschwindigkeiten erfordert. Bereits heute erreichen Hochleistungsbehälterförderanlagen Geschwindigkeiten v ≥ 2 m/s und stellen damit Software und

104

S. Libert et al. ID-System Sensor/Taster

ID-System Sensor/Taster

t

TE

TE

Vorher

t

TE

TE

TE

Nachher

Abb. 11.5   Reaktionszeit an einer Entscheidungsstelle

Hardware vor schwierige Aufgaben, welche ohne eine geeignete Strategie unlösbar werden. Die Reaktionszeiten werden somit unmittelbar von den steigenden Fördergeschwindigkeiten bestimmt. Abbildung 11.5 stellt den Sachverhalt am Beispiel einer Weiche im Materialflusssystem dar: Die Reaktionszeit tr beschreibt die Zeit von der Identifikation der TE durch ein Sensorsystem, der Kommunikation zwischen der Maschinen- und Agentenebene, dem Routing bis hin zu Entscheidung, in welche Richtung die TE transportiert werden soll und der entsprechenden Ansteuerung der Aktoren. In der Regel werden hier sogenannte „voreilende“ Belegmeldungen eingesetzt. Das bedeutet, dass die Berechnung der Route nach der Identifikation unter der Annahme stattfindet, der Behälter sei bereits an der Verzweigungsstelle angekommen. Dadurch kann die Richtung für den weiteren Transport der TE schon vor der physikalischen Ankunft der TE (die durch einen Sensor erfasst wird) bestimmt werden, sodass beim auslösen des Sensorsignals die TE ohne Unterbrechung weitergeleitet wird. Für den gesamten Prozess steht jedoch nur eine begrenzte Zeit zur Verfügung, die im Wesentlichen vom Abstand zwischen ID-System und Sensor und der Fördergeschwindigkeit abhängt. Dieser Abstand ist wiederum an die Länge der TE gebunden, denn wenn die erste TE das ID-System passiert hat und verarbeitet wird, folgt im Regelfall in geringem Abstand die nächste Transporteinheit. Bei Behälteranlagen sind Behälter der Größe 600 × 400 mm weit verbreitet. Bei den genannten Anforderungen und optimalen Bedingungen müssen bei der Realisierung moderner Materialflusssysteme Reaktionszeiten für den gesamten Steuerungsvorgang tr ≤ 250 ms garantiert werden. Das garantierte Einhalten von Rechenzeiten ist aber nur auf echtzeitfähigen Hard- und Softwareplattformen möglich. Vor allem die in der Automatisierungstechnik etablierten speicherprogrammierbaren Steuerungen (SPS) sind auf die Abarbeitung von Programmen mit fester, garantierter Zykluszeit ausgelegt. Schon aus diesem Grund ist für das Ansteuern der mechanischen Komponenten bzw. für das Treffen zeitkritischer Entscheidungen die Nutzung einer SPS oder auch Soft-SPS (eine auf gängiger PC-Hardware laufende und dennoch echtzeitfähige Softwareumgebung für das Ausführen von SPS-Programmen) zum empfehlen. Weiterhin ist aber auch die Implementierung logischer Konstrukte und anderer Mechanismen wie Zeitschaltuhren für die hardwarenahe Überwachung von Einund Ausgängen in dedizierten SPS-Sprachen auf intuitivere und oftmals einfachere

11  Softwarearchitektur für eine agentenbasierte Materialflusssteuerung

105

Weise möglich als in Hochsprachen. Daher wird die Steuerungslogik eines Moduls in zwei Schichten gegliedert: • Der Softwareagent wird in einer objektorientierten Hochsprache programmiert und erlaubt es somit, bei der Entwicklung und Implementierung der Materialflusssteuerung alle Vorteile der Kapselung und Vererbung zu nutzen. Weiterhin kann auf diese Weise auch auf existierende Agentenframeworks zurück gegriffen werden. Da die Agentenlogik als „verteilter Materialflussrechner“ aufgefasst werden kann und vor allem standardisierbare logistische Funktionen oder Strategien implementiert, kann sie hardwareunabhängig gestaltet werden, was eine weitere wichtige Voraussetzung für die Wiederverwendbarkeit des Codes ist. Der Agent kann auch in einer nicht echtzeitfähigen Umgebung ausgeführt werden, da seine Aufgaben – die Kommunikation, Kooperation und Koordination mit anderen Entitäten sowie das Treffen komplexer Entscheidungen – im Regelfall keinen strikten Echtzeitanforderungen unterliegen. • Die Maschinensteuerungsebene übernimmt die Verarbeitung der digitalen oder analogen Ein- und Ausgänge der technischen Anlage. Wegen der großen Vielfalt mechanischer Komponenten muss die Maschinensteuerung hardwarespezifisch ausgeführt bzw. neu programmiert werden. Wird die Mechanik von externen Herstellern zugekauft, wird die Maschinensteuerung im Regelfall vom Lieferanten programmiert bzw. die notwendigen Bibliotheken zum Auslesen der Sensorinformationen und für die Ansteuerung der Aktoren mitgeliefert. Hierfür müssen einheitliche Schnittstellen und Standards definiert werden. Über die E/A-Ansteuerung hinaus können hier aber auch andere Funktionen, für die eine sehr kurze und garantierte Reaktionszeit notwendig ist, implementiert werden. Denkbar ist zum Beispiel, dass auf sehr schneller Fördertechnik die Entscheidung, ob an einer Weiche eine Transporteinheit gerade aus weiter gefördert oder ausgeschleust wird, ebenfalls in der Maschinensteuerung getroffen wird. Die Entscheidungsgrundlage dafür wird aber, beispielsweise in Form einer periodisch aktualisierten Routingtabelle, vom Agenten generiert und an die Maschinensteuerung weitergereicht. Diese Aufteilung der Steuerungslogik eines Moduls erlaubt zwar die gleichzeitige Nutzung zweier Programmierwelten und deren Vorteile, erzeugt aber dafür eine zusätzliche Schnittstelle zwischen den beiden Steuerungsschichten. Eine einfache Integration der zwei Ebenen und damit die hohe Wiederverwendbarkeit des Agentencodes sind aber nur möglich, wenn diese Schnittstelle universell und herstellerunabhängig einsetzbar ist – also mit nur minimalem Konfigurationsaufwand die Kommunikation zwischen beliebigen Agenten und beliebigen SPS-Programmen auf beliebiger Hardware ermöglicht. Allerdings sind die für den Datenaustausch zwischen den beiden Ebenen in Frage kommenden Datenübertragungsprotokolle sehr vielfältig und oftmals herstellerspezifisch. Daher ist eine weitere Ebene notwendig, die die verschiedenen Protokolle zur Kommunikation zwischen Agent und Maschinensteuerung kapselt und abstrahiert (s. Abb. 11.3). Diese Abstraktionsschicht agiert als eine Art „Middleware“, die sehr flexibel ausgelegt wird und frei konfigurierbar ist. Über eine Konfigurationsdatei

106

S. Libert et al.

werden auszutauschende Dateninhalte bzw. Variablen, deren Datentyp und das zur Übertragung einzusetzende Protokoll definiert, wobei beliebig viele Variablen deklariert und auch über unterschiedliche Protokolle ausgetauscht werden können. Durch das Einfügen einer solchen Middleware zwischen Agent und Maschinensteuerung werden alle Aspekte der Mechanikansteuerung vor dem Agenten versteckt, sodass dieser unabhängig von der Modulhardware implementiert werden kann. Dieses Vorgehen erlaubt aber nicht nur das Verwenden desselben Modulagenten mit verschiedenen Ausprägungen der zu steuernden Mechanik sondern auch seine Anbindung an einen Emulator oder eine Simulationsumgebung, die das Verhalten der Maschinensteuerung nachbildet (s. a. Kap. 15). Vor allem während der Entwicklung und dem Test von Agenten ist damit die Möglichkeit zum Einsatz einer virtuellen Test- und Ausführungsumgebung geschaffen. Auf diese Weise lassen sich Steuerungsalgorithmen einzelner Module oder auch das Zusammenspiel größerer Anlagenbereiche testen, ohne dass die Mechanik verfügbar oder einsatzbereit sein muss.

11.4  Fazit Die vorgestellte Softwarearchitektur beruht auf gängigen Standards für Multiagentensysteme und bietet die Grundlage für die Implementierung einer dezentralen Materialflusssteuerung. Zeitkritische Steuerungsaufgaben, die mit der der Agententechnik nur schwer umzusetzen sind, werden in einer eigenen Schicht realisiert, beispielsweise als SPS-Programm. Eine Abstraktionsschicht zwischen Agenten und dieser maschinennahen Steuerung ermöglicht dabei eine leichte Austauschbarkeit und direkte Kopplung des Agentensystems an einen Emulator.

Kapitel 12

Rechenplattformen und RFID für das Internet der Dinge Andreas Nettsträter und Florian Kuzmany

Das folgende Kapitel beschreibt zum einen die Steuerungshardware, welche als Plattform für die Entitäten des Internet der Dinge dient und zum anderem den Einsatz der Radio Frequenz Identifikation (RFID). Letztere kann eingesetzt werden, um direkt auf der Transporteinheit alle für die Identifikation und den Transport notwendigen Daten zu speichern.

12.1  Übersicht über die Steuerungshardware Neben der Modularisierung der Steuerungssoftware nach dem Konzept des Internet der Dinge ist die Hardware, auf der die jeweiligen Steuerungsagenten ausgeführt werden sollen, ebenfalls anzupassen. Dazu erfolgt parallel zur Softwareseite eine Modularisierung der Hardware. Die klassische Architektur, welche vorsieht, dass eine SPS einen kompletten Anlagenbereich steuert, soll so durch eine verteilte Architektur abgelöst werden. Diese ordnet, soweit technisch und wirtschaftlich sinnvoll, jedem Modul eine eigene Hardwareplattform zu. Hier kann der Planer grundsätzlich zwischen zwei Hardwareausprägungen, nämlich PC und Speicherprogrammierbarer Steuerung (SPS), wählen. Die folgenden Abschnitte beschreiben die Anforderungen und den möglichen Aufbau einer Hardwareumgebung für die Module des Internet der Dinge, wobei die aktuellen Entwicklungen im PC- und SPS-Bereich in die Betrachtung mit einbezogen werden.

A. Nettsträter () Fraunhofer-Institut für Materialfluss und Logistik IML Joseph-von-Fraunhofer Straße 2-4, 44227 Dortmund, Deutschland e-mail: [email protected] W. Günthner, M. ten Hompel (Hrsg.), Internet der Dinge in der Intralogistik, DOI 10.1007/978-3-642-04896-8_12, © Springer-Verlag Berlin Heidelberg 2010

107

108

A. Nettsträter und F. Kuzmany

12.1.1  Anforderungen Die Anforderungen an die Steuerungshardware für die Elemente eines Materialflusssystems lassen sich in wirtschaftliche und technische Anforderungen sowie Anforderungen an die Benutzerfreundlichkeit unterteilen.

12.1.1.1  Wirtschaftliche Anforderungen Für den Hersteller und späteren Betreiber steht der Preis der benötigten Hardware oftmals im Vordergrund. Laut Moores Gesetz (s. Moore 1965), das bereits 1965 ausgestellt wurde, verdoppelt sich die Leistungsfähigkeit der Prozessoren alle an­‑ derthalb Jahre, wobei der Preis und die Baugröße meist zusätzlich abnehmen. Hier haben sich in den letzten Jahren große Fortschritte speziell im Bereich der PC-Technologie ergeben. Bei den heute verfügbaren SPS-Lösungen kann dieser Trend ebenfalls festgestellt werden, jedoch nicht ganz so dramatisch wie bei den PC. Hersteller von SPS verwenden beispielsweise meist nicht die neueste Prozessorgeneration, sondern Vorgängergenerationen, die bereits seit längerer Zeit im Einsatz sind und so eine robuste Technologiebasis bieten. Zusätzlich verfügen die Hersteller über ausreichende Lagerbestände, um sicher zu stellen, dass ein Kunde auch nach einigen Jahren Ersatzteile für die Baugruppen erhält. Die gesicherte Ersatzteilversorgung ist ein nicht zu vernachlässigender Vorteil beim Einsatz einer SPS.

12.1.1.2  Technische Anforderungen Eine Klassische Anforderung an die in Materialflusssystemen eingesetzte Steuerungstechnik ist eine hohe Verfügbarkeit und Robustheit der Komponenten, denn ein Ausfall führt in der Regel zum Stillstand eines Teils der Produktionsanlage und zieht daher hohe Kosten nach sich. SPS wurden speziell vor diesem Hintergrund entwickelt und können daher eine hohe Verfügbarkeit aufweisen. Zudem sind SPS so ausgelegt, dass sie eine sehr kurze Hochlaufzeit nach einem Stromausfall oder einer geplanten Abschaltung garantieren. Hier können die Betriebssysteme und Hardwarekomponenten der PC, die zumeist aus angepassten Standardsystemen bestehen, nicht mithalten. Die Hardware einer feldnahen Steuerung muss zudem in der Lage sein, rechtzeitig auf Veränderungen in ihrem Zuständigkeitsbereich zu reagieren. Eine Änderung im Eingangsbild der Steuerung, wie beispielsweise die Unterbrechung einer Lichtschranke, muss in einer garantierten Zeitspanne auch eine adäquate Reaktion nach sich ziehen. Dies kann beispielsweise das Schalten von Antrieben oder Ventilen sein. Diese Fähigkeit eines Systems wird als Echtzeitfähigkeit bezeichnet, wobei die garantierte Reaktionszeit in klassischen Speicherprogrammierbaren Steuerungen der doppelten Zykluszeit entspricht. Die Zykluszeit ist die Zeit, die für das

12  Rechenplattformen und RFID für das Internet der Dinge

109

Einlesen der Eingangszustände, die Verarbeitung des Steuerungsprogramms und das Schreiben der Ausgänge benötigt wird. Sie ist stark von der Hardware und der Komplexität der Steuerungsaufgabe abhängig. Für die Ansteuerung der Fördertechnik eines Materialflusssystems bewegt sie sich in der Regel zwischen 3 und 200 ms. PC-basierte Systeme dagegen benötigen echtzeitfähige Betriebssysteme wie Windows CE oder Realtime-Linux, um dieser Anforderung gerecht zu werden. Zudem muss die Rechengeschwindigkeit des verwendeten Systems groß genug sein, um eine für die jeweilige Aufgabe ausreichende Zykluszeit garantieren zu können. Diese Anforderung erfüllen für herkömmliche Anwendungen sowohl eine SPS als auch ein PC. Da die Kommunikation zwischen den Entitäten im Internet der Dinge ausschließlich über Ethernet durchgeführt wird, muss die eingesetzte Hardware auch über entsprechende Schnittstellen verfügen. Hier haben die SPS in den letzten Jahren aufgeholt. Inzwischen gilt eine Ethernetschnittstelle nach IEEE-Norm 802.3 auch in diesem Bereich als Standard. Weiterentwicklungen auf Basis des herkömmlichen Ethernet, wie EtherCAT, PROFINET oder ETHERNET/IP, ermöglichen sogar Echtzeitkommunikation. Zusätzlich sind nach wie vor klassische Feldbussysteme wie z. B. CAN oder PROFIBUS im Einsatz, die auf absehbare Zeit weiterhin Verwendung finden werden. Dies stellt bei SPS kein Hindernis dar und bei PC sind entsprechende Schnittstellenkarten auf dem Markt erhältlich. Einige Hersteller bieten auch integrierte Kleinstrechner an, welche über klassische Feldbusschnittstellen verfügen. Mit zunehmender Vernetzung und der Anbindung an das World Wide Web rückt auch die Sicherheit eines Steuerungssystems immer mehr in den Vordergrund. Zum einen muss die Steuerungskomponente nach außen mit Firewalls gesichert werden, zum anderen sollte böswillige Software auch direkt auf den eingesetzten Systemen auffindbar und zu beseitigen sein. Bei PC wird dieser Problematik mit Virenscannern begegnet, welche mit geringem administrativem Aufwand aktuell gehalten werden und regelmäßige Scanvorgänge im Hintergrund durchführen. Auf SPS sind bisher keine Viren bekannt und daher auch keine Virenscanner verfügbar. Ob sich dieser Zustand in Zukunft ändern wird, kann noch nicht vorher gesagt werden. Eine Sicherung der Programme gegen die Veränderung durch unbefugte Personen, welche sich bereits im eigenen Unternehmen befinden, wird auf beiden Systemen durch die Verwendung von Passwörtern garantiert. 12.1.1.3  Anforderungen an die Benutzerfreundlichkeit Eine Hardwarekomponente sollte, um den Programmier- und Inbetriebnahmeaufwand zu begrenzen, möglichst einfach handhabbar sein und dem Benutzer bzw. Programmierer seine Arbeit erleichtern. Dies beginnt bereits bei der richtigen Programmiersprache und -umgebung. Klassische Steuerungsaufgaben, wie die Verarbeitung von Eingangssignalen, Zeitschaltmechanismen, eine Antriebsregelung oder die Kommunikation über Feldbusnetzwerke werden am einfachsten mit den unter (IEC 61131-3 1993) genormten Programmiersprachen gelöst. SPS

110

A. Nettsträter und F. Kuzmany

werden zusammen mit einer Entwicklungsumgebung für diese Sprachen angeboten und liefern bereits Bausteine, welche genau auf die erwähnten Einsatzfelder zugeschnitten sind. Darüber hinaus sind zahlreiche herstellerspezifische Lösungen verfügbar, welche sich leicht in eigene Programme einbinden lassen. Zusätzlich können Fehler in der Programmlogik oder falsch angeschlossene Sensoren und Aktoren sehr leicht aufgefunden werden, da die Entwicklungsumgebungen umfangreiche Hilfsmittel zur Überwachung und Fehlerbehebung zur Verfügung stellen. Die Visualisierung aktueller Ein- und Ausgangs- sowie Variablenzustände während der Laufzeit ist nur eine der komfortablen Möglichkeiten zum Debugging von SPS-Programmen. Es ist sogar vorgesehen, neue Programmlogik auch während des Betriebs einzuspielen. Generell ist es auch nicht mehr notwendig, für die Fehlerbehebung vor Ort zu sein. Moderne SPS werden grundsätzlich über eine Netzwerkverbindung angesprochen, so dass der Standort des Programmierers unerheblich ist. Auf dem PC übliche Entwicklungsumgebungen für Hochsprachen wie C++, C# oder Java, bieten ähnliche Möglichkeiten zur Fehlersuche und für den Fernzugriff. Eine Darstellung aller Umgebungsvariablen während der Laufzeit oder das Einspielen neuer Programme im Online-Betrieb ist hier jedoch in der Regel nicht möglich. Trotzdem kann der PC gerade bei Aufgaben sein Potenzial ausspielen, welche nicht direkt im Zusammenhang mit der eingesetzten Sensorik und Aktorik stehen. Die Verarbeitung komplexer Daten, wie z. B. die Interpretation einer XML-codierten Nachricht, ist auf einer SPS, wenn überhaupt, dann nur mit großem Aufwand zu realisieren. Hochsprachen verfügen jedoch über Klassenbibliotheken, welche diese Aufgabe recht einfach implementierbar machen. Auch ist eine Anbindung an Datenbanksysteme oder ein Routingalgorithmus für Transporteinheiten in Hochsprachen sehr leicht umzusetzen, während hier IEC 61131-3 Sprachen schnell an ihre Grenzen stoßen. Die Programmierung einer Benutzerschnittstelle zur Veränderung von Mate­ rialflussstrategien während des Betriebs und die Visualisierung der Anlagenzu­ stände und Transportvorgänge können mit Hochsprachen ebenfalls sehr komfortabel abgebildet werden. Zahlreiche Entwicklungsumgebungen stellen Editoren zur Verfügung, welche auf eine umfangreiche Bibliothek von grafischen Benutzerelementen zurück greifen und so die Gestaltung von Benutzeroberflächen erheblich unterstützen. Für SPS existieren Softwarepakete zur Visualisierung von Anlagenzuständen. Diese sind für einfache Visualisierungsaufgaben, z. B. für die Darstellung des Zustands einzelner Anlagenelemente recht gut vorbereitet. Eine eher abstrakte Sicht auf ein komplexes Materialflusssystem lässt sich damit jedoch nur eingeschränkt bewerkstelligen. Tabelle 12.1 bietet einen Überblick der Vor- und Nachteile von PC und SPS. An die einzusetzende Steuerungshardware sind also unterschiedliche Anforderungen gestellt. Für maschinennahe Aufgaben ist die SPS nach wie vor die beste Lösung. Übergeordnete Aufgaben, welche bisher von einem Materialflussrechner übernommen wurden, wie z. B. die strategische Koordination und Kommunikation lassen sich jedoch besser auf einem PC-basierten System abbilden.

12  Rechenplattformen und RFID für das Internet der Dinge

111

Tab. 12.1   Gegenüberstellung SPS – PC Anforderung SPS Preis o Nachkaufsicherheit ++ Verfügbarkeit/Robustheit ++ Hochlaufzeit + Echtezeitfähigkeit ++ Rechengeschwindigkeit o Ethernetanbindung + Feldbusanbindung ++ Sicherheit gegen Angriffe o Debugging ++ Fernzugriff ++ Überwachung/Steuerung von Ein-/Ausgängen ++ Kommunikation komplexer Datenstrukturen (z. B. XML) –– Anbindung an Datenbanken – Umsetzung komplexer Steuerungsalgorithmen (z. B. Routing) – Darstellung einer Benutzerschnittstelle/Visualisierung o Erfüllung der Anforderung (–– sehr schlecht, – schlecht, o neutral, + gut, ++ sehr gut)

PC + – o – + + ++ o – + + o ++ ++ ++ ++

12.1.2  Architektur Die in Kap. 11 vorgestellte Softwarearchitektur beschreibt ein Ebenenmodell für Module im Internet der Dinge, das über eine Agentenebene und eine Maschinensteuerungsebene verfügt. Die Agentenebene führt dabei eher strategische Aufgaben wie die Koordination und Kommunikation mit anderen Modulen durch, während die Maschinensteuerungsebene alle maschinennahen und echtzeitkritischen Aufgaben wahrnimmt. Durch die Unabhängigkeit der Ebenen untereinander sind verschiedene Ausprägungen der tatsächlichen Steuerungshardware denkbar. Eine vorgegebene universelle optimale Lösung existiert nicht, da diese für jeden Einsatzfall und – bereich unterschiedlich ausfallen kann. In den folgenden Anschnitten werden mehrere Konzepte, die auf SPS, PC und/oder EPC (Embedded PC) basieren, kurz vorgestellt (s. Abb. 12.1): 12.1.2.1  Konzept I: Einsatz einer SPS Grundsätzlich kann ein Internet der Dinge Materialflusssystem ausschließlich mit der SPS-Technologie aufgebaut werden. Hier müssen sowohl die Agentenebene als auch die Maschinensteuerungsebene auf einer SPS implementiert werden. Die Vorteile liegen in der Reduzierung des Kommunikationsaufkommens und dem Einsatz einer einheitlichen Programmierumgebung. Der große Nachteil dieser Lösung liegt in der Umsetzung der steuerungslogischen Funktionen in IEC 61131-3. Für den Programmierer stellt sich hier das Problem, eine Agentenumgebung und deren Kommunikation in Sprachen zu implementieren, die für diese Aufgaben nicht

A. Nettsträter und F. Kuzmany I

II

Modul

Modul

Fördertechn. Ebene

III Modul

SPS

EPC

PC

DIN EN 61131-3

Hochsprachen

Hochsprachen

Maschinensteuerungsebene

Agentenebene

112

Sensorik / Aktorik

Sensorik / Aktorik

IV Modul

Modul EPC Hochsprachen

SPS IEC 61131-3

SPS IEC 61131-3

Sensorik / Aktorik

Sensorik / Aktorik

SoftSPS mit IEC 61131-3

Sensorik / Aktorik

Abb. 12.1   Mögliche Hardwarekonzepte im Internet der Dinge

geeignet sind. Auf die beim PC bereits vorhandenen Agentenframeworks kann hier nicht zurück gegriffen werden. 12.1.2.2  Konzept II: Einsatz eines Embedded-PC ohne Soft-SPS Ein Embedded-PC ohne Soft-SPS vereint die Agenten- und die Maschinensteuerungsebene auf einer Plattform und einem Betriebssystem. Eventuell muss ein Betriebssystem mit Echtzeitfähigkeit eingesetzt werden, um die Funktionen der steuerungstechnischen Ebene korrekt umsetzen zu können. Der Vorteil der durch den Einsatz eines Embedded-PC ohne Soft-SPS entsteht, ist die Reduzierung der Kosten des Moduls, da das Soft-SPS-Betriebssystem nicht lizenziert werden muss. Ein Nachteil, der durch diese Vorgehensweise entsteht, ist die Umsetzung der steuerungstechnischen Ebene in Hochsprachen, da diese Umsetzung neue softwaretechnische Konzepte erfordert und nicht in IEC 61131-Sprachen erfolgen kann. 12.1.2.3  Konzept III: Kombination aus PC und SPS Die Kombination aus einem Standard-PC und einer SPS kann als Übergangslösung für die Migration eines bestehenden zentralgesteuerten Materialflusssystems auf das dezentrale Konzept des Internet der Dinge gesehen werden. Der PC stellt dabei die Rechenplattform für die Softwareagenten sowie die Ethernet-Anbindung zur Kommunikation mit anderen Modulen zur Verfügung. Der PC deckt die Agentenebene ab. Die Kommunikation zur SPS, welche die Maschinensteuerungsebene abbildet, kann beispielsweise über ein Feldbussystem oder ebenfalls über Ethernet erfolgen.

12  Rechenplattformen und RFID für das Internet der Dinge

113

Die Vorteile dieser Lösung liegen in dem relativ geringen Aufwand zur Einrichtung des Agentensystems auf dem PC und der einfachen Feldsteuerung über die SPS. Die Nachteile ergeben sich durch den hohen Kommunikationsaufwand zwischen PC und SPS. Zudem stellt der PC einen Single Point Of Failure dar, der damit die Robustheit eines dezentral organisierten Systems wie dem Internet der Dinge in Frage stellt. 12.1.2.4  Konzept IV: Einsatz eines Embedded-PC mit Soft-SPS Ein Embedded-PC (EPC) mit Soft-SPS ist ein modular aufgebauter, kleiner Industrie-PC, der sowohl über ein herkömmliches Betriebssystem (beispielsweise Windows oder Linux) als auch über ein SPS-Betriebssystem, das mit IEC 61131-3 Sprachen programmiert werden kann, verfügt. Diese Variante vereint die Vorteile der beiden vorher genannten Lösungen. Die Soft-SPS bildet die Maschinensteuerungsebene, samt der echtzeitrelevanten Vorgänge ab, die Agentenebene wird im herkömmlichen (PC)-Betriebssystem in Hochsprachen implementiert. Die Vorteile liegen in der einfachen Programmierung der maschinennahen Funktionen in IEC 61131-3 und der Softwareagenten in Hochsprachen. Durch den Einsatz einer einzigen Hardware-Plattform entfällt die externe Schnittstelle. Der Nachteil besteht allerdings im noch relativ hohen Preis der Hardware.

12.1.3  Fazit Ein Embedded PC mit SoftSPS erfüllt, abgesehen vom Kaufpreis, die eingangs beschriebenen Anforderungen am besten. Daher kann diese Lösung durchaus als Grundlage für das Internet der Dinge empfohlen werden. Es ist jedoch im Einzelfall zu prüfen, ob diese Investition notwendig ist, oder ob aus Kostengründen andere Konzepte angewandt werden sollen. Dies kann z. B. der Fall sein, wenn die Maschinenebene nur einen geringen Komplexitätsgrad und Umfang hat. Diese Ebene in Hochsprachen statt in IEC 61131-3 zu implementieren wäre dann keine große Einschränkung und es kann das Konzept II angewendet werden. Die Agentenebene sollte grundsätzlich in Hochsprachen implementiert werden, da der Aufwand, diese auf einer SPS zu implementieren, in keinem Verhältnis zum Nutzen steht. Aus diesem Grund sollte vom Konzept I prinzipiell Abstand genommen werden.

12.2  Einsatz von RFID Neben klassischen Barcodesystemen zur Identifikation gewinnt die RFID-Technologie immer mehr an Bedeutung. RFID ist ein Verfahren, binär codierte Daten berührungslos und ohne Sichtkontakt zu erfassen und zu übertragen. Der Datenaus-

114

A. Nettsträter und F. Kuzmany

Abb. 12.2   Passive Transponder in verschiedenen Bauformen

tausch erfolgt dabei mittels induktiver Kopplung oder elektromagnetischer Wellen. Ein RFID-System besteht aus mindestens einem Transponder, auch Tag genannt, sowie mindestens einer Schreib-/Lesestation. Einer der größten Vorteile gegenüber Barcodesystemen liegt in der (Wieder-)Beschreibbarkeit der Transponder, welche neben reinen Lesevorgängen auch Schreibvorgänge erlauben. Bei den Transpondern wird zwischen Transpondern mit passiver und aktiver Energieversorgung unterschieden. Passive Transponder (s. Abb. 12.2) haben keine eigene Energieversorgung, sondern beziehen die für den Sendevorgang benötigte Energie über ein vom Lese-/Schreibgerät erzeugtes elektromagnetisches Feld. Die Vorteile der passiven Transponder liegen beim Kaufpreis und ihrer Langlebigkeit. Nachteilig sind die Datenübertragungsrate und die relativ kurzen Übertragungsdistanzen. Aktive Transponder besitzen eine eigene Energieversorgung, beispielsweise eine Batterie. Die Datenübertragungen können vom Chip selbstständig und ohne entsprechendes Lesefeld angestoßen werden. Dies erlaubt die Überbrückung größerer Distanzen und höhere Übertragungsraten. Die Lebensdauer ist abhängig von der Art der Energieversorgung und den Umgebungsbedingungen am Einsatzort. Daher sind die passiven Transponder ohne eigene Energieversorgung in der Regel langlebiger als die aktiven. (ten Hompel et al. 2008, S. 103 ff.).

12.2.1  Frequenzbereiche RFID arbeitet in unterschiedlichen Frequenzbereichen, welche wie folgt unterteilt sind: LF (Low Frequency), HF (High Frequency), UHF (Ultra High Frequency)

12  Rechenplattformen und RFID für das Internet der Dinge

115

Tab. 12.2   Übersicht über RFID-Frequenzen in Anlehnung an (ten Hompel et al. 2008, S. 106) LF

HF

UHF

Mikrowelle

Frequenz (EU) Wellenlänge Energieübertragung Besonderheiten

125 kHz 2400 m Induktive Kopplung Nahfeld Auf Metall lesbar

13,56 MHz 22 m Induktive Kopplung Nahfeld Durch Dielektrikum lesbar, Pulkerfassung möglich

Reichweite Bandbreite (EU)

1 m 5 kHz

3 m 14 kHz

868 MHz 35 cm Elektromagnetische Welle Reflektion an Metalloberfläche, Pulkerfassung möglich 10 m 3 MHz

2,45 GHz 12 cm Elektromagnetische Welle Reflektion an Metalloberfläche, Pulkerfassung möglich > 10 m 9 MHz

und Mikrowelle. Jeder Frequenzbereich hat unterschiedliche Vor- und Nachteile. Tabelle 12.2 gibt einen Überblick mit Angabe der in Europa zulässigen Frequenzen. Diese Frequenzen sind nicht weltweit standardisiert, sondern unterliegen nationalen Bestimmungen. Für den Einsatz in Materialflussanlagen im Allgemeinen und für Anlagen nach dem Konzept des Internets der Dinge im Speziellen ergeben sich erweiterte Anforderungen für die Transponder und Frequenzbereiche. Für Materialflussanlagen muss hohe Verfügbarkeit und Lesesicherheit gegeben sein. Einen großen Einfluss auf die Verfügbarkeit und Lesesicherheit der RFID-Systeme hat die Einsatzumgebung. Diese besteht in Materialflusssystemen in der Regel aus metallischen Komponenten. Gerade für die hochfrequenten Systeme (UHF, Mikrowelle) ist diese metallische Umgebung problematisch, da diese durch Reflexionen der elektromagnetischen Wellen an den Metalloberflächen gestört werden. Hier kann durch Einsatz mehrerer Antennen und der geschickten Anordnung dieser Antennen eine praktikable Lösung gefunden werden. Die Verbindung zwischen Transportgut und dem steuernden Softwareagenten erfolgt in heutigen Systemen nach dem Konzept Internet der Dinge über die Transponder (s. Abschnitt Einsatz im Internet der Dinge). Konnte ein Transponder nicht fehlerfrei gelesen werden, kann das Transportgut auch nicht eindeutig einem Softwareagenten zugeordnet werden. Dies führt unter Umständen dazu, dass keine korrekte Zustellung zum Ziel möglich ist. Für diese Systeme ist eine hohe Lesesicherheit entscheidend. Eine weitere Anforderung stellt die Lokalisierung bzw. die Abstandsbestimmung dar. Hier muss die Entfernung der Transponder zu den RFID-Antennen bestimmt werden. Dabei ist im Falle eines Materialflusssystems nicht der zentimetergenaue Abstand, sondern die Reihenfolge des Transportguts auf einer bestimmten Förderstrecke relevant. Die Information, welches Transportgut sich am nächsten zur RFID-Antenne befindet, wird beispielsweise für die Steuerung von Weichen oder Staustrecken benötigt. Hier muss sichergestellt sein, dass die Transporteinheit mit dem aktuell gelesenen Transponder auch diejenige ist, welche am nächsten an der zu stellenden Weiche, bzw. als vorderste in der Staustrecke ist. Diese Anforderung ist vor allem für Systeme mit hohen Frequenzen (UHF, Mikrowelle) problematisch, da hier neben den Reflexionen auch die große Lesereichweite störend ist.

116

A. Nettsträter und F. Kuzmany

Die Reflexionen können dazu führen, dass weiter entfernte Transponder als nah erkannt werden und umgekehrt. Dieser Effekt wird durch eine hohe Lesereichweite noch verstärkt, da potenziell mehr Transponder im Lesebereich liegen. Systeme mit niedrigen Frequenzen (LF, HF) haben diese Probleme nur bedingt oder gar nicht. Durch die geringe Lesereichweite und die Anpassung der Signalstärke des Lesefelds wird zwangsläufig nur das Transportgut erkannt, welches am nächsten zur Antenne steht. Die Lese- und Schreibgeschwindigkeit des einzusetzenden RFID-Systems muss in direkter Abhängigkeit zur Fördergeschwindigkeit der Materialflussanlage und der zu lesenden Datenmenge ausgelegt werden. Die Daten der Transponder müssen zwangsläufig in der Zeitspanne gelesen werden, in der sich das Transportgut im Lesefeld der RFID-Antenne befindet. Dies heißt für Materialflussanlagen mit einer sehr hohen Fördergeschwindigkeit, dass ein unterbrechungsfreier Betrieb nur gewährleistet werden kann, wenn das RFID-System entsprechend schnell die benötigten Transponderdaten lesen und schreiben kann. Hier haben die RFID-Systeme mit hohen Frequenzen (UHF, Mikrowelle) auf Grund der großen Lesereichweite und der hohen Bandbreite Vorteile. Eine Anforderung, die vor allem für Palettentransporte Relevanz hat, ist die Pulkerfassung mehrerer Transponder. Bei diesem Vorgang wird nicht nur ein Transponder gelesen, sondern alle Transponder, die sich im Lesebereich einer RFID-Antenne befinden. Eingesetzt wird diese Technik vor allem zur Erfassung aller Waren, die sich auf einer Palette befinden. Dazu wird die Palette durch ein so genanntes RFIDGate gefahren, welches im Regelfall aus einem RFID-Gerät mit mehreren Antennen besteht. Die Möglichkeit der Pulkerfassung bieten die RFID-Systeme der Frequenzbereiche HF, UHF und Mikrowelle.

12.2.2  Einsatz im Internet der Dinge Neben der Auswahl einer geeigneten RFID-Technologie müssen auch die Informationen betrachtet werden, welche auf einem Transponder im Internet der Dinge gespeichert werden. Hier existieren folgende drei Alternativen: 12.2.2.1  Id-on-tag Id-on-tag bezeichnet die klassische Variante der Identifikationssysteme, bei denen ein eindeutiges Identifikationsmerkmal zur Erkennung genutzt wird. Für RFID bedeutet dieses Vorgehen, dass nur die Identifikationsnummer, die im Regelfall bereits auf dem Transponder vorhanden ist, gelesen wird. Anhand dieser Identifikation wird im Internet der Dinge der zugehörige Agent der Transporteinheit gefunden bzw. neu instanziiert. Für dieses Konzept genügen RFID-Transponder, die nicht wiederbeschreibbar sind oder nur eine sehr geringe Speicherkapazität haben.

12  Rechenplattformen und RFID für das Internet der Dinge

117

Der Vorteil dieses Konzepts liegt darin, dass nur die Identifikationsnummer gelesen werden muss. Dies erfolgt sehr schnell und ermöglicht somit eine hohe Fördergeschwindigkeit zum Lesezeitpunkt. Die Nachteile liegen in der Datenhaltung der dynamischen Daten. Diese liegen komplett bei den Agenten und müssen von diesen auch für den Fall eines möglichen Systemausfalls persistiert werden. Die Softwareagenten müssen also dafür sorgen, dass aktuelle Zustandsdaten, wie beispielsweise der Status des aktuellen Auftrags, auch nach einem Systemausfall zur Verfügung stehen. Dies erfolgt im Regelfall durch die Speicherung in einer Datenbank oder einem Datensystem. 12.2.2.2  Data-on-tag Das Konzept Data-on-tag umfasst neben der reinen Identifikationsnummer auch Nutzdaten, die für die Systemsteuerung genutzt werden. Diese können beispielsweise Zielvorgaben, Routinginformationen oder auch transportgutspezifische Angaben sein. Die RFID-Transponder müssen einen entsprechend zur Datenmenge passenden Speicher aufweisen. Der Vorteil dieses Ansatzes liegt darin, dass relevante Daten direkt auf dem Transponder gespeichert sind, sodass ein Softwareagent diese direkt verwenden kann. Das Persistieren der Daten geschieht direkt auf dem Transponder. Als weiteren positiven Effekt kann, wenn das Transportgut das aktuelle System verlässt, das Nachfolgesystem diese Daten ebenfalls nutzen. Der Nachteil liegt in dem aufwendigeren Lese- und Schreibvorgang. Je nach Datenmenge muss die Fördergeschwindigkeit an die Lese- und Schreibgeschwindigkeit der RFID-Transponder angepasst werden. 12.2.2.3  Agent-on-tag Neben der Identifikationsnummer liegen bei Agent-on-tag nicht mehr reine Nutzdaten im Speicher des Transponders, sondern der gesamte ausführbare Softwareagent. Bei diesem Konzept wandert der Agent also direkt auf dem Transportgut von Modul zu Modul. Alle benötigten Daten, sowohl der ausführbare Programmteil des Agenten wie sein aktueller Zustand, werden auf dem Transponder persistiert. Wird so ein Agent-on-tag-Transponder von einem Lesegerät erfasst, lädt dieses den Agentencode vom Transponder und lässt ihn in einer sicheren Ausführungsumgebung ablaufen. Kurz bevor der Transponder den Lese-/Schreibbereich der Station verlässt, wird der Agent wieder zurück auf den Transponder geschrieben. Der Vorteil dieses Konzepts liegt in der kompletten Daten- und Programmhaltung auf dem Transponder. Dies ermöglicht, dass jedes Transportgut einen eigenen unabhängigen Agenten, der dem Transportsystem nicht bekannt sein muss, nutzen kann. Die Nachteile liegen in der extrem großen Datenmenge, die sich sowohl in einer langen Lese- und Schreibdauer, wie auch in einem großen Datenspeicher niederschlägt.

118

A. Nettsträter und F. Kuzmany

12.2.3  Fazit Aus den beschriebenen Anforderungen und den möglichen Konzepten zur Informationsspeicherung ergeben sich die folgenden sinnvollen Kombinationen. Um die Vorteile des Konzepts Internet der Dinge nutzen zu können, sollte mehr als die Identifikation eines RFID-Transponders genutzt werden. Id-on-tag ist daher nicht empfehlenswert. Die größtmögliche Flexibilität wird durch Agent-on-tag erreicht, allerdings ist die technische und preisliche Entwicklung im RFID-Bereich noch nicht weit genug fortgeschritten. Der Mittelweg Data-on-tag ist zum aktuellen Zeitpunkt die wirtschaftlich und technisch interessanteste Alternative. Zusammen mit den RFID-Systemen HF und UHF lässt sich dieses Konzept erfolgversprechend nutzen. Die Entscheidung, welches der beiden Systeme sinnvoller ist, muss je nach Einsatzort und -zweck getroffen werden. Für Materialflussanlagen mit hohen Fördergeschwindigkeiten und großem Datenmengen, die auf den Transpondern gespeichert werden sollen, eignet sich UHF eher als HF. Für Anlagen, bei denen es aufgrund der Umgebung zu starken Reflexionen kommen kann ist es umgekehrt.

Kapitel 13

Strategien für die dezentrale agentenbasierte Steuerung von Materialf lusssystemen Michael Hofmeister, Georg Baier und Manfred Gärtner

13.1  Einführung Die Aufgaben, die Agenten in der dezentralen Steuerung von Anlagen auszuführen haben, sind außerordentlich vielfältig. Sie müssen die zu transportierenden Stückgüter unter Beachtung einer Vielzahl von Nebenbedingungen durch die Anlage führen und dabei sicherstellen, dass die Güter rechtzeitig an den jeweiligen Übergabestellen ausgeliefert werden. Sie müssen dabei über Strategien verfügen, die nicht nur das jeweilige zu transportierende Stückgut betreffen, für dessen Transport sie gerade verantwortlich sind. Sie müssen auch über geeignete Kommunikationsmechanismen verfügen, die es erlauben, Störungen auf der Anlage wie der Ausfall einzelner Module, Staustrecken o. ä. auszuregeln und aufzulösen. Wegen der Forderung der Dezentralität müssen dies die Agenten weitgehend unter sich aushandeln. Der Grad an Intelligenz, Kommunikationsmechanismen und erforderlichen Strategien, über den die Agenten verfügen müssen, ist dabei wesentlich von der jeweiligen Anlage abhängig. So gibt es Anlagen, die über ein hohes Maß an Vernetztheit verfügen, so dass die Auswahl einer Route für das gerade zu befördernde Transportgut zu seinem Ziel unter Beachtung der aktuellen Lastsituation der Anlagenteile eine fundamentale Aufgabe für die Agenten ist; Gepäckförderanlagen in großen Flughäfen sind Beispiele hierfür. Hingegen ist die Topologie vieler Lager- und Kommissioniersysteme so gestaltet, dass es nur eine einzige mögliche Route für das Stückgut gibt. In solchen Anlagen stehen dann häufig Aufgaben wie die Sequenz- und Paarbildung oder Sortierverfahren im Vordergrund.

M. Hofmeister () Corporate Technology, Siemens AG Otto-Hahn-Ring 6, 81739 München, Deutschland e-mail: [email protected] W. Günthner, M. ten Hompel (Hrsg.), Internet der Dinge in der Intralogistik, DOI 10.1007/978-3-642-04896-8_13, © Springer-Verlag Berlin Heidelberg 2010

119

120

M. Hofmeister et al.

13.2  Lokalisierung von Agenten in der Anlage Materialf lusssysteme im Sinne des Internets der Dinge bestehen aus drei Arten autonomer Entitäten: Dienste, Transporteinheiten und Module, die sich wiederum in Stetig- und Unstetigförderer, Verzweigungen, Arbeitsstationen und Lagerfächer einteilen lassen (s. Kap. 8). In einer zentral gesteuerten Anlage übernimmt der Leitrechner die Koordination der einzelnen über IT vernetzten Anlagenteile. Im dezentral gesteuerten Fall erfolgt dies über die Agenten. Eine wichtige Frage dabei ist, wo die Agenten, vor allem im Fall der Module und der Transporteinheiten, lokalisiert sind. Arbeitsstationen betreiben ein lokales Management. Sie erhalten über eine Input-Schnittstelle das Transportgut und bearbeiten es gemäß ihres Arbeitsauftrags. Nach Beendigung geben sie es über eine Output-Schnittstelle an ein anderes Modul ab, in der Regel an ein Förderelement. Sie haben keine unmittelbar logistischen Aufgaben. Für die aktive Steuerung der Anlage und damit als Lokalisierung der Agenten sind sie damit von untergeordneter Bedeutung. Förderer und Verzweigungen tragen aktiv zum Materialf luss bei. So kann ein Förderband je nach Auslegung der Fördertechnik und der zugehörigen Regelung über die Fördergeschwindigkeit Einf luss nehmen. Weichen greifen aktiv in das Routing ein, indem sie einem Stückgut eine weitere Verlaufsrichtung geben. Trays bewegen sich durch die Anlage und haben als Auftrag die Beförderung eines Stückgutes durch die Anlage von einem Startpunkt zu einem Ziel. Die Förderelemente kommen damit unmittelbar als Kandidaten für die Lokalisierung von Agenten in Frage. Weiterhin kann es sein, dass auch das Transportgut selbst Träger von Agenten ist. Dieser Fall führt zu einem unmittelbaren Vergleich mit der Situation im öffentlichen Straßenverkehr: Das Transportgut korrespondiert zum Verkehrsteilnehmer, der sich von einem Startpunkt zu einem Ziel im Netz bewegen möchte und eigenständige Entscheidungen über Route, Geschwindigkeit, Zwischenstationen usw. trifft. Zur Verfügung stehen ihm hierzu Informationen über die Netztopologie, in gewissem Umfang über die aktuelle Verkehrslast des Netzes (Verkehrsfunk) oder zu erwartende Reisezeiten. Im Unterschied zum Straßenverkehr verfügt der Betreiber eines Materialf lusssystems jedoch über einen entscheidenden Vorteil: Er definiert die Strategien, über die die Agenten verfügen sollen, damit sein Ziel bestmöglich erfüllt werden kann. Zu denken ist beispielsweise an Restriktionen wie Zeitvorgaben (zum Beispiel Liefertermine) oder einen Workf low (Röntgengeräte für Koffer). Die unterschiedlichen Lokalisierungsmöglichkeiten für die Agenten ergeben jeweils Paradigmen für die prinzipielle Ausgestaltung agentenbasierter Materialf lusssysteme. Diese sind nicht immer miteinander verträglich. Konf likte zwischen einem Transportgut, das sich für eine bestimmte Route entschieden hat, und einer Weiche, die darauf besteht, es auf eine andere Route zu schicken, sind denkbar. Es muss daher bereits bei der Systemplanung festgelegt werden, welchem Paradigma die Auslegung der Agenten folgen soll. Beispielsweise bietet es sich an, bei Anlagen mit einem hohen Maß an möglichen Routenentscheidungen die Intelligenz stärker in das Stückgut oder in Trays, die das Stückgut von der Quelle bis zum Ziel transportieren,

13  Strategien für die dezentrale agentenbasierte Steuerung von Materialf lusssystemen

121

zu legen. Bei Anlagentypen ohne Routenvielfalt ist die Lokalisation in den Förderelementen die sinnvollere Alternative. Als weitere Designentscheidung ist bereits in der Anlagenplanung festzulegen, ob die Agenten physikalisch an „ihre“ Objekte gebunden sind, etwa in Form von RFID-Tags für das Transportgut oder Rechenleistung in den Förderelementen, oder ob die Kopplung „nur“ logisch geschieht. Der erste Fall unterstützt die vertikale Modularisierung der Anlage. Die für den Anlagenbetrieb erforderliche IT-Struktur ergibt sich automatisch mit dem technologischen und maschinenbaulichen Engineering. Häufig steht jedoch die verfügbare Palette an Förderelementen diesem auch hinsichtlich der IT modularisierten Ansatz entgegen. Will man trotzdem auf eine agentenbasierte Steuerung nicht verzichten, steht nach wie vor der zweite Ansatz offen, bei dem die Agenten zwar logisch Komponenten zugeordnet, aber parallel auf einem Leitrechner realisiert sind (s. a. Kap. 12).

13.3  Der Zustandsraum für Agentensysteme Beim Design eines Agentensystems für Steuerungssysteme von Materialf lussanlagen hat man je nach Anlagentyp drei Dimensionen zu berücksichtigen, die für die Auslegung der Agenten von Bedeutung sind und im Wesentlichen von Engineeringund Funktionalitätsaspekten der Anlage beeinf lusst werden (Abb. 13.1): 1. Topologie: An erster Stelle steht die Topologie des jeweiligen Anlagentyps, die sich aus der zu erbringenden Funktionalität ergibt. Wie bereits skizziert, ergeben sich daraus Hinweise auf die Lokalisierung von Agenten und die wichtige Frage, an welche Objekte Intelligenz in Form von Agenten gebunden werden soll. 2. Verfügbare Information: Des Weiteren ist zu klären, über welche Art von Information die Agenten verfügen sollen. Einerseits bedingt ein hohes Maß von Information eine gute Entscheidungsvorlage für die Handlungsfähigkeit der Agenten. Falls der Agent nur Informationen aus seiner unmittelbaren Umgebung zur Verfügung hat, kann er auch seine Entscheidungen nur anhand lokaler Kriterien fällen. Routingentscheidungen an einer Weiche können von einem Transportgut­ agent etwa anhand von Routingtabellen getroffen werden. Eine Weiche könnte hier anhand einfacher Aufteilungsregeln agieren (z. B. 2 rechts, 1 links). Es liegt auf der Hand, dass solche lokalen heuristischen Regeln kaum geeignet sind, zum Beispiel Staus in der Anlage auszuregeln. Andererseits ist für die Ausweitung der zur Verfügung gestellten Information ein Preis zu zahlen: Entweder in Form der Aufweichung des Dezentralisierungsansatzes, zum Beispiel durch Bereitstellung eines „Blackboards“, auf das alle Agenten zugreifen können, um globale Informationen zu erhalten, oder dadurch, dass globale Information durch das Netzwerk propagiert wird, was zum einen den Informationsf luss und die Kommunikation im Netzwerk und zum anderen den Aufwand für die Realisierung der Agenten deutlich erhöht. 3. Algorithmische Komplexität: Ein Agent sollte in der Lage sein, aus den ihm zur Verfügung stehenden Informationen die richtigen Schlüsse im Sinne des

122

M. Hofmeister et al.

Anlagenbetreibers zu ziehen. Die Komplexität der Berechnungen, die ein Agent zu diesem Zweck durchführen können sollte, steht natürlich auch in einem gewissen Zusammenhang mit der Information, über die er verfügen kann oder die er sich anhand seiner Kommunikationsmechanismen beschaffen kann. Ein Agent einer Transporteinheit kann etwa an jeder Weiche zur Aktualisierung seiner weiteren Route Shortest Path Algorithmen anwenden, wobei er globale Information zum Beispiel über Staus in Form von Straf kosten einbezieht. Er könnte aber auch aufgrund einer einfachen heuristischen Regel entscheiden, welche der beiden Möglichkeiten er für seine weitere Route wählt. Eine solche Regel könnte in der Nutzung von „Wegweisern“ bestehen, die der Weiche zugeordnet sind und darüber informieren, welche der beiden Richtungen auf Pfaden zum Ziel der Transporteinheit liegen. Es gilt also, zur Unterstützung des Engineerings von dezentral gesteuerten Anlagen im Vorfeld je nach Anlagentyp neben der Lokalisierung der Agenten festzulegen, über wie viel Information sie verfügen müssen und wie viel Intelligenz sie benötigen, um aus der Information ein optimales Verhalten im Sinne des Anlagenbetriebs zu erzeugen. Dabei ist ein Trade Off zwischen Leistungsfähigkeit und Aufwand für die Realisierung anzustreben. Die Erfahrung zeigt, dass die dynamischen Einf lüsse des Geschehens im Netz häufig so groß sind, dass Prognosen über die weitere Lastverteilung im Netz, die der Agent für seine weiteren Aktionen nutzen kann, sehr unzuverlässig sind. Ein Beispiel für eine einfache Routingstrategie: Man betrachte die Anlagentopologie aus Abb. 13.2, bei der vorausgesetzt ist, dass alle Förderstrecken nur in der einen angegebenen Richtung fördern können. Die Förderstrecken haben jeweils eine konstante Geschwindigkeit, so dass die Transporteinheiten, die von Links im System erscheinen, entweder die Geschwindigkeit der Förderstrecke haben, oder aber – im Fall eines Staus – die Geschwindigkeit null. Die Transporteinheiten sind sämtlich von gleicher Art. Alle Transporteinheiten haben das gleiche Ziel, womit Routingentscheidungen nicht vom Ziel abhängen. Dieses Ziel ist von jedem Punkt in der Anlage zu erreichen. Verfügbare Information

Viel

Wenig

Abb. 13.1   Zustandsraum für das Design von Agentensystemen

Wenig Anlagentopologie

Viel

Algorithmische Komplexität

13  Strategien für die dezentrale agentenbasierte Steuerung von Materialf lusssystemen

123

Abb. 13.2   Eine einfache Anlagentopologie sowie störungsfreier Betrieb

In dieser Situation bietet sich folgende Positionierung im Zustandsraum beim Entwurf des Agentensystems an: 1. Da die Transporteinheiten sich nicht hinsichtlich individueller Eigenschaften und Ziel unterscheiden, werden die Agenten den Weichen und Zusammenführungen zugeordnet. 2. Die Weichen-Agenten verfügen als Information nur über den aktuellen Auslastungsgrad der direkt nachgeordneten Förderstrecken, wogegen die Zusammenführungs-Agenten den Auslastungsgrad der vorgeordneten Förderstrecken kennen. Ist F eine Förderstrecke, so sei cF deren Kapazität, und aF( t) die aktuelle Kapazitätsnutzung zur Zeit t. Der Auslastungsgrad von F ist definiert als κF (t) = aFcF(t) . Die Zusammenführungsagenten verfügen analog über den Auslastungsgrad der beiden vorgeordneten Förderstrecken. 3. Erreicht eine Transporteinheit zur Zeit t eine Weiche mit nachgeordneten Förderstrecken F1 und F2, so verfährt sie wie folgt: Ist κ1( t) + κ2( t) < 2, so überführt die Weiche die Transporteinheit auf Förderer Fi mit der Wahrscheinlichkeit i (t) Wi := 2−κ1−κ (i = 1,2). Ist hingegen κ1( t) + κ2( t) = 2, so blockiert sie, solange 1 (t)−κ2 (t) dieser Zustand anhält. Eine analoge Regel gilt für Zusammenführungen. Wie man Abb. 13.2 weiter entnehmen kann, verteilen sich die Transporteinheiten zunächst gleichförmig über alle Pfade. Nach einer Weile tritt an einer Förderstrecke eine Störung auf. Man erkennt in Abb. 13.3, dass sich die Förderrate hin zu der 1

2 3

4

Abb. 13.3   Eintritt einer Störung

124

M. Hofmeister et al.

Störungsstelle reduziert hat; an der Störungsstelle kommt es zum Stillstand. Es werden trotzdem weiterhin einige Transporteinheiten in Richtung der Störung geleitet. Erst wenn die Sackgasse Richtung Störung vollständig durch Transporteinheiten blockiert ist, wird sie nicht mehr genutzt. An der ersten Weiche wird trotzdem weiter im Verhältnis 1:1 in beide Richtungen geroutet. Befinden sich an den markierten Stellen 1, …, 4 Bearbeitungspunkte, so wäre die Anlage in einer Schief last: Bearbeitungspunkt 2 muss allein genauso viele Transporteinheiten bearbeiten wie Bearbeitungspunkte 3 und 4 zusammen.

13.4  T  opologiespezifische Ausprägung strategischer Aspekte am Beispiel zweier Anlagentypen Materialf lusssysteme existieren in verschiedensten Ausprägungen und stellen entsprechend unterschiedliche Anforderungen an die Leistungsfähigkeit der Steuerungen. Betrachtet man den in Abb. 13.1 gezeigten Zustandsraum für das Design von Agentensystemen, so fällt auf, dass die Achse „Anlagentopologie“ nicht weiter beschriftet ist. Diese Achse verkörpert eigentlich einen eigenen Raum, der sich jedoch nicht so leicht weiter formalisieren lässt. Am ehesten ist er aus Sicht eines konkreten Anwendungsfeldes einzugrenzen. Für zwei Fälle wird im Folgenden eine Differenzierung und Eingrenzung in diesem Sinne unternommen: Zum einen für ein automatisches Kommissionierlager nach dem Prinzip „Ware zum Mann“, bei dem vor allem die Paar- und Sequenzbildung sowie das Sortieren im Vordergrund stehen, und zum anderen für eine Gepäckförderanlage eines Flughafens, bei der vor allem das Routing primäre Aufgabe ist.

13.4.1  A  utomatisches Kommissionierlager: Paarbildung, Sequenzbildung, Sortieren Betrachtet werden in diesem Kapitel die Abläufe in einem Kommissionierlager mit dem Prinzip „Ware zum Mann“. Dabei werden sowohl die Transporteinheiten, in denen die erforderliche Ware, im folgenden als Lager-TE, als auch die Transporteinheiten, in die die geforderte Ware in auftragsspezifischen Mengen kommissioniert werden, im folgenden als Komm-TE bezeichnet, über ein automatisches Materialf lusssystem zum Arbeitsbereich des Kommissionierers transportiert. Jede Lager-TE und Komm-TE ist über eine systemweit eindeutige TE-ID identifiziert. Diese TE-ID ist in konventionellen Systemen auf einem Etikett als Barcode hinterlegt. In einem Kommissionierlager basierend auf den Konzepten des „Internet der Dinge“ wird die TE-ID im RFID-Tag der TE abgespeichert. Auf bau und Abläufe innerhalb eines Kommissionierlagers sind sehr kundenspezifisch. Im Folgenden werden zwei Fallbeispiele vorgestellt, die die wesentlichen

13  Strategien für die dezentrale agentenbasierte Steuerung von Materialf lusssystemen

125

Abb. 13.4   Layout Kommissionierlager mit Kommissionierbahnhöfen mit Greif kanälen

Aufgaben eines Materialf lusssteuerungssystems innerhalb eines Kommissionierlagers erörtern. Fallbeispiel 1: Kommissionierlager mit direktem Zugriff des Kommissionierers zu den bereitgestellten Lager-TE (Kommissionierbahnhof mit Greif kanälen) Das Kommissionierlager besteht aus mehreren Kommissionierbahnhöfen und zugeordneten Nachschubgassen. Die Versorgung eines Kommissionierbahnhofs mit Lager-TE erfolgt über Greif kanäle, die in die Nachschubgassen integriert sind (Abb. 13.4). Die Greif kanäle werden über das Regalbediengerät der Nachschubgasse automatisch mit den benötigten Lager-TE versorgt. Nicht mehr benötigte sowie leere Lager-TE werden ebenfalls über das Regalbediengerät automatisch entsorgt. Der Kommissionierer hat wahlfreien Zugriff auf die Lager-TE, die in den zugeordneten Greif kanälen bereitgestellt werden. Die Komm-TE, in die die auftragsbezogenen Artikel kommissioniert werden sollen, können ein bis mehrere Kommissionierbahnhöfe anfahren. D. h. jeder Komm-TE ist eine Liste der anzufahrenden Kommissionierbahnhöfe zugeordnet. Für jeden von der Komm-TE anzufahrenden Bahnhof muss gewährleistet sein, dass die benötigte Ware in den zugeordneten Greif kanälen für den Kommissionierer verfügbar ist (Abb. 13.5). Diese Liste kann in dem RFID-Tag der Komm-TE abgespeichert werden. Das Materialf lusssteuerungssystem arbeitet diese Liste entsprechend des aktuellen Füllstands der Pufferstrecke vor den Kommissionierbahnhöfen ab. Erfolgreich abgearbeitete Bahnhöfe werden aus der Liste ausgetragen bzw. als bearbeitet markiert. Sind alle Bahnhöfe abgefahren, wird die Komm-TE zum nachgeschalteten Versandsorter transportiert. Für die technische Realisierung sind an den Loop-Ausschleusplätzen sowie an den Kommissionier-Arbeitsplätzen geeignete Module entsprechend Kap. 8 einzusetzen.

126

M. Hofmeister et al.

Abb. 13.5   Arbeitsablauf und Materialf luss eines Kommissionierlagers mit Kommissionierbahnhöfen mit Greif kanälen

Fallbeispiel 2: Kommissionierlager mit vorgeschaltetem Puffer für Lager-TE ohne direkten Zugriff für den Kommissionierer Bei dieser Ausprägung eines Kommissionier-Arbeitsplatzes werden die erforderlichen Lager-TE in einem Pufferspeicher zwischengelagert und bei Bedarf dem Kommissionierer auf dem vorgesehenen Bereitstellplatz angedient (Abb. 13.6). Das Materialf lusssteuerungssystem hat wahlfreien Zugriff auf die Lager-TE im Pufferspeicher. Der Kommissionierer hat keinen direkten Zugriff auf eine Lager-TE im Speicher. Damit der Kommissionierer die gewünschte Ware in die am vorgesehenen Bereitstellplatz befindliche Komm-TE kommissionieren kann, muss das Materialf lusssteuerungssystem die zugeordnete Lager-TE aus dem Pufferspeicher zum Bereitstellplatz der Lager-TE transportieren.

10-gassiges AKL

Behälter-FT für Larger-TE (Behälter) Pufferspeicher für Lager-TE Bereitstellplatz Lager-LE (Behälter) Bereitstellplatz Komm-TE Behälter-FT für Komm-TE (Tray + Karton)

Abb. 13.6   Kommissionierlager mit zugeordneten Bereitstellplätzen für Lager-TE und Komm-TE

13  Strategien für die dezentrale agentenbasierte Steuerung von Materialf lusssystemen

127

Die Komm-TE werden dem Kommissionierer über eine getrennte Fördertechnik in einer vom Lagerverwaltungssystem fest vorgegebenen Reihenfolge (Sequenz) angedient. Diese Reihenfolge muss vom Materialf lusssteuerungssystem an dem Weichenplatz vor dem Kommissionier-Arbeitsplatz bei der Entscheidung, ob die Komm-TE ausgeschleust werden darf, berücksichtigt werden. In Abhängigkeit von der Ankunftsreihenfolge der Komm-TE am Bereitstellplatz muss die zugeordnete Lager-TE ebenfalls am dafür vorgesehenen FördertechnikPlatz bereitgestellt werden. Diese Zusammenführung von Komm-TE und Lager-TE am Kommissionierplatz (Paarbildung) muss zeitnah erfolgen, damit beim Kommissioniervorgang keine Wartezeiten entstehen. Dabei ist zu berücksichtigen, dass einer Komm-TE 1, …, n Lager-TE, aber auch einer Lager-TE 1, …, m Komm-TE zugeordnet sein können. Z. B. können für eine Komm-TE drei Lager-TE in einer bestimmten Reihenfolge am Kommissionierplatz benötigt werden. Dabei bleibt die Komm-TE am Kommissionierplatz stehen, bis aus den drei Lager-TE die benötigte Ware sequentiell entnommen wurde. Beispielhafte Beschreibung der Strategie Reihenfolgesteuerung: In einem automatisierten Kommissionierlager sind die Materialf lusselemente den Arbeitsabläufen des Kunden angepasst und somit topologisch individuell ausgeprägt. Die Hauptaufgaben liegen im Lagern von Gütern und Komissionieren von Ware. Die Ware wird auftragsrein in einer festgelegten Reihenfolge ausgelagert und kommissioniert, um eine Vermischung von Aufträgen zu verhindern. Diese Sequenzbildung findet in mehreren Ebenen statt, wie Abb. 13.7 darstellt. Die primäre Sortierung findet auf der Ebene der Regalbediengeräte statt. Diese lagern einen Folgeauftrag erst aus, wenn der aktuell laufende Auftrag vollständig ausgelagert wurde. Da sich diese Aufträge aufgrund der unterschiedlichen Transportwege von einem Auslagerplatz eines Regalbediengerätes zu einem bestimmten Ziel vermischen können, ist es notwendig, eine weitere Sortierung durchzuführen. Diese findet am zweiten Point-Of-No-Return statt. Dieser Punkt definiert den letzten Entscheidungspunkt, nachdem sich die Aufträge aufgrund der Topologie nicht mehr vermischen können. Ist der aktuell laufende Auftrag nicht abgeschlossen, so fährt jede Transporteinheit eines Folgeauftrags eine weitere Runde im Loop. Diese sekundäre Sortierung kann ebenso in einem Turmspeicher stattfinden, der sich ähnlich wie ein Regalbediengerät verhält und einen Puffer vor einem Kommissionierplatz darstellt. Dieser sammelt Transporteinheiten für unterschiedliche Aufträge und fährt diese, sobald vollständig, auftragsrein zu dem entsprechenden Kommissionierplatz. In einem automatisierten Kommissionierlager existieren sehr wenige redundante Strecken, so dass Alternativrouten selten genutzt werden können. In sehr großen Anlagen existieren teilweise Alternativrouten, die jedoch, da sie verschiedene Lagerbereiche verbinden, eine sehr frühzeitige Entscheidung benötigen. Dies kann sich unter Umständen negativ auf die Transportdauer auswirken. Eine Lastverteilung kann an Kommissionierbahnhöfen stattfinden, wenn die zu kommissionierende Ware redundant an mehreren Bahnhöfen gelagert wird. Dies kann sich positiv auf die entsprechenden Strategien auswirken.

128

M. Hofmeister et al.

O1WS3

O2WS1

O1WS2

O1WS3

O2WS1

O2WS1

O1WS1

O1WS1

O1WS1

O1WS1

SRM3

Point of no return für primäre Sortierung

O1WS3

SRM1

Primäre Sortierung

O2WS1

SRM2

O1WS2

Sekundäre Sortierung (loopscanner)

Point of no return für sekundäre Sortierung

Mischung von Aufträgen möglich

Loop = Möglichkeit Aufträge zu sortieren

O2WS1 O2WS1 O2WS1 O2WS1 O1WS1 O1WS1

O1WS3

O1WS1

O1WS2

O1WS3

O1WS1

O1WS2

O1WS3

Workst. WS21

Workst. WS2

Workst. WS3

Abb. 13.7   Mehrschichtige Sequenzbildung

13  Strategien für die dezentrale agentenbasierte Steuerung von Materialf lusssystemen

129

13.4.2  F  lughafen-Gepäckförderanlage: Routing steht im Vordergrund Gepäckförderanlagen von Flughäfen weisen hinsichtlich ihrer Topologie, Aufgaben und des zu bewältigenden Transportauf kommens Spezifika auf, welche bei einer agentenbasierten Steuerung berücksichtigt werden müssen. Diese Besonderheiten sollen im Folgenden kurz zusammengefasst werden. Gepäckförderanlagen haben hinsichtlich ihrer Ausdehnung und Komplexität eine große Spannbreite, sie reicht von wenigen bis zu hundert Kilometern Förderstrecke. Gemeinsam ist allen Anlagen, dass sie auf Grund der notwendigen Verfügbarkeit über eine vernetzte Topologie verfügen. Unterschiedliche Einschränkungen wie normales und Sperrgepäck oder weitere Sicherheitskontrollen für auffälliges Gepäck führen zu einer Vielzahl von Wegen zur Erreichung ein und desselben Ziels. In hinsichtlich der Fläche ausgedehnten Flughäfen gibt es zum Beispiel Förderstrecken mit sehr hoher Geschwindigkeit, um den Gepäcktransport für Transferpassagiere mit den heute üblichen kurzen Umsteigezeiten zu ermöglichen. Weiterhin müssen die Gepäckförderanlagen den Workf low für ein Transportgut ermöglichen. Dazu unterteilt sich die Anlage in mehrere Funktionsbereiche, welche die Anzahl der möglichen Wege zum Ziel weiter erhöht. Abbildung 13.8 zeigt eine vereinfachte Topologie der Gepäckförderanlage eines Flughafens mit Funktionsbereichen. Transportgüter werden an den mit „Check-In“ oder „Transfer“ gekennzeichneten Stellen in den Materialf luss eingeschleust. Die grau hinterlegten Stellen bezeichnen Sicherheitsdurchleuchtungsstellen der Stufe 1 und 2 (a) beziehungsweise (b), sowie die Ausschleusstellen zur Handkontrolle (c). Zu den Gates führen die Ausschleusstellen der beiden Sortierkreise. Die Topologie garantiert, dass ein Transportgut seinen Workf low auf dem Weg zu seinem Ziel, dem Gate, erfüllen kann. Es ist jedoch nicht möglich, von jedem Punkt der Anlage noch das Ziel zu erreichen. Hat ein

transfer

sorter

Check in

(c)

(c) (a)

(b) sorter

Abb. 13.8   Beispiel für eine vereinfachte Topologie der Gepäckförderanlage eines Flughafens

130

M. Hofmeister et al.

Transportgut ein gestricheltes (gepunktetes) Modul erreicht, so kann es nur noch ein Gate am gestrichelten (gepunkteten) Sortierkreisel erreichen. Die von einer Gepäckförderanlage zu bewältigenden Transportaufträge unterliegen großen Schwankungen. Das Auf kommen an abf liegenden, umsteigenden und ankommenden Passagieren und dem damit verbundenen Gepäck unterliegt starken Schwankungen über den Tag und über die Tage der Woche. Des Weiteren kann die zukünftige Entwicklung des Passagier- und Gepäckauf kommens nur abgeschätzt werden. Gepäckförderanlagen müssen daher sehr robust gegen schnelle und langsame Änderungen der Einlastsituation sein. Ein Stellmittel, um diese enorme Varianz handhaben zu können, ist die Wahl der Routen. Diese muss garantieren, dass alle Anforderungen aus dem Workf low erfüllt werden (zum Beispiel Sicherheitsüberprüfungen), nur für das Transportgut zugelas­sene Förderstrecken benutzt werden (zum Beispiel Sperrgepäck) und die Zeitre­ striktionen eingehalten werden. Des Weiteren darf die Anlage nicht in eine Schief  last geraten, um immer einen hohen Durchsatz gewährleisten zu können. Eine technische Beschreibung von Aufgaben und Funktionsbereichen einer Gepäckförderanlage in Flughäfen sowie ein exemplarischer Ablauf eines Transportvorgangs werden in Kap. 25 gegeben.

13.5  Routingverfahren Routingverfahren im Sinne einer Strategie für die dezentrale Steuerung von Materialf lusssystemen sind nur von Relevanz, wenn die Materialf lussanlage über eine Topologie verfügt, welche zur Erfüllung des jeweiligen Workf lows verschiedene Wegalternativen ermöglicht. In vorigen Abschnitt wurde am Beispiel der Gepäckförderanlage eines Flughafens gezeigt, dass das effiziente Routing sogar zu einer zentralen Aufgabe eines Materialf lusssystems avancieren kann. Die im Folgenden dargestellten Verfahren beziehen sich daher auf die Situation in Gepäckförderanlagen von Flughäfen.

13.5.1  Topologische Information Vor einem Routingverfahren steht die Frage nach dem Zugang und der Gewinnung von Information über die Anlagentopologie. Diese Frage ist in dezentralen Anlagen in zweierlei Hinsicht von Bedeutung. Zum Einen ist die physikalische Anlagentopologie gemäß dem Prinzip Plug&Convey variabel. Während des Aussowie Umbaus der Anlage ändert sich die Topologie, ohne dass die Anlage dazu vollständig gestoppt werden soll. Zum Anderen ist die „verfügbare Topologie“ der Anlage dynamisch, zum Beispiel durch Störungen. Die beschriebenen Situationen erfordern eine unterschiedliche Berücksichtigung bei der Entwicklung von dezentralen Steuerungen. Eine Störung ist im Allgemeinen kurzzeitig, und innerhalb der Anlage befinden sich Transporteinheiten, deren weiterer Transport von der Störung betroffen ist. Ein Um- sowie Ausbau dauert länger und der Anlage

13  Strategien für die dezentrale agentenbasierte Steuerung von Materialf lusssystemen

131

Topologie Verteilte Information (aufgabenbezogen) Wenig Redundanz (inkrementell)

Viel Redundanz

Globale Information

Redundanzfrei

Redundant

Abb. 13.9   Zugriffsvarianten auf topologische Information

steht mehr Zeit zur Verfügung, um die neue Situation zu antizipieren. Die Motivation, warum eine bestimmte Topologieinformation benötigt wird, ist daher von wesentlicher Bedeutung, wenn es um die Art der Gewinnung dieser Information geht. Welche Arten der Gewinnung und Vorhaltung von Topologieinformation, unter Berücksichtigung der gerade beschriebenen Sichtweise, zur Verfügung stehen, ist grob in Abb. 13.9 dargestellt. Die erste Stufe der Unterscheidung betrifft die prinzipielle Art, wie die Information zur Topologie gespeichert wird. Der einfachere Fall ist die Speicherung globaler Information, das heißt, die Topologieinformation wird mittels dezentraler Verfahren erstellt und steht an einer Stelle als globales Gesamtbild zur Verfügung. Der komplexere, aus Sicht einer dezentralen Anlage natürlichere Fall ist die (aufgabenbezogene) dezentrale Information. Hierbei steht an keiner Stelle die vollständige Information zur Verfügung. Die Information ist verteilt über die gesamte Anlage so aufbereitet, dass die für einen Agenten notwendige Information erstellt werden kann. Weiterhin kann die Information zur Topologie redundant oder möglichst redundanzfrei gespeichert werden. Die Speicherung redundanter Information ermöglicht den schnellen Zugriff auf spezielle Information, welche sonst nur durch weitere Berechnungen gewonnen werden kann. Soll im Fall globaler Information zum Beispiel vor einer Entscheidung bestimmt werden, ob in einem bestimmten Teilssystem keine Störung vorliegt, so sind folgende zwei Varianten naheliegend: (1) Es wird mit Hilfe der globalen Topologieinformation überprüft, ob eine Störung vorliegt. (2) Es existiert eine globale Liste aller aktuell gestörten Module. Für diese Liste wird geprüft, ob ein Modul im relevanten Teilsystem liegt. Je nach Situation ist eine der Versionen effizienter als die andere. Treten nur sehr wenige Störungen gleichzeitig auf, so ist die zweite Variante sehr effizient, benötigt jedoch eine Synchronisation der redundanten Information. Ein gutes Beispiel dezentral gespeicherter Topologieinformation sind Routingtabellen. Die Routingtabelle eines Moduls enthält für jedes erreichbare Ziel eine Information über den weiteren Weg zu diesem Ziel. Benötigt ein Agent nur diese inkrementelle Information an diesem Modul, so ist eine Routingtabelle ausreichend. Benötigt der Agent jedoch den gesamten Restweg bis zum Ziel, so muss entweder dieser Weg am Modul vorliegen, oder erst durch Kommunikation mit den Nachbarmodulen bestimmt werden. Je nach Häufigkeit und erforderter Reaktionszeit muss unter Umständen eine Gesamtinformation aus der Sicht des einzelnen Moduls für spezielle Aufgaben erstellt und redundant verwaltet werden.

132

M. Hofmeister et al.

Routingtabellen lassen sich mit Hilfe von Richtungstabellen bestimmen. Eine Richtungstabelle enthält für jeden Zielpunkt die Richtung, Nachfolgemodul, sowie die Entfernung zum Ziel in dieser Richtung. Eine sehr f lexible Möglichkeit zur dezentralen Bestimmung dieser Tabellen ist ein verteilter Label-Correction-Algorithmus, eine verteilte Variante des Algorithmus von Dijkstra (s. Dijkstra 1959). Ein Label entspricht dabei einer Richtungstabelle. Fragt ein Modul regelmäßig die Label seiner Nachfolgemodule ab und aktualisiert die Richtungen und Entfernungen seines Labels, wenn sich eine kürzere Richtung für ein Ziel ergeben hat, so wird dieser Prozess stationär (vorausgesetzt die Topologie ändert sich nicht). Die resultierenden Label der Module enthalten die Richtungen für die kürzesten Wege für jedes erreichbare Ziel. Dieses Verfahren ist langsam, jedoch von sehr einfacher und klarer Struktur. Es lässt sich auf vielfältige Weise erweitern und effizienter gestalten. Zum Beispiel kann statt des passiven Wartens und wiederholten Abfragens einer Veränderung ein Modul aktiv seine Vorgänger informieren, wenn sich eine Entfernung geändert hat. Durch Störungen ändert sich die (verfügbare) Topologie wiederholt. Die sich ergebenden Veränderungen können für von der Störungsstelle weit entfernte Module sehr gering sein. Daher kann es sinnvoll sein, Änderungen erst an Vorgängermodule zu melden, wenn diese einen bestimmten Schwellenwert überschritten haben. Hinzuweisen ist im Zusammenhang dynamischer Topologien auf das Phänomen des „Looping“: In einem Kreis ist jedes erreichbare Ziel auch durch einen nochmaligen Durchlauf durch den Kreis zu erreichen. Wird ein Ziel vollständig unzugänglich, zum Beispiel auf Grund einer Störung, so bleibt es in dem Kreis weiterhin als erreichbares Ziel erhalten. Die Möglichkeiten der Erweiterung des verteilten LabelCorrection-Algorithmus sind zahlreich, die zentrale Frage bei der Anpassung ist die nach der erforderlichen Qualität der dezentral gespeicherten Information. Die Antwort entscheidet über die notwendigen Anpassungen sowie die Einsatzfähigkeit dieses Verfahrens. Hervorzuheben ist noch, dass es keinerlei globaler Abstimmung bedarf. Jedes Modul initialisiert zunächst seine Routingtabelle mit seinen eigenen Endpunkten und fügt neue Zielpunkte hinzu, wenn diese in den Routingtabellen der Nachfolgemodule enthalten sind.

13.5.2  Dynamische schnellste Wege Zu Beginn des Kapitels wurde schon auf die Korrelation zwischen agentengesteuerten Materialf lussanlagen und dem öffentlichen Straßenverkehr hingewiesen. Unter Vernachlässigung von Touristen wählen alle Verkehrsteilnehmer den aus ihrer Sicht schnellsten Weg, um ans Ziel zu gelangen. Dieser Weg muss nicht notwendig der geographisch kürzeste Weg sein. Ein Umweg über eine Autobahn kann die Fahrzeit zum Ziel erheblich verkürzen, trotz geographisch längerer Strecke. Dieses Verhalten kann durch die Wahl geeigneter Routingverfahren in Materialf lussanlagen nachempfunden werden. In gewissem Sinne kann dieses egoistische Verhalten der Fahrer beziehungsweise der korrespondierenden Agenten als wünschenswert be-

13  Strategien für die dezentrale agentenbasierte Steuerung von Materialf lusssystemen

133

trachtet werden. Verlassen die Transportgüter die Materialf lussanlage so schnell wie möglich, so nehmen sie auch keine weiteren Anlagenressourcen mehr in Anspruch. Da der optimale Weg gewählt wurde, nämlich der schnellste, werden die Anlagenressourcen somit best möglich genutzt. Diese Sichtweise wird dem systemischen Verhalten so komplexer Systeme nicht gerecht. Aus der Verkehrsforschung ist beispielsweise bekannt, dass das sich einstellende dynamische Gleichgewicht beliebig schlecht sein kann (vgl. Sheffi 1985). Der in diesem Zusammenhang betrachtete Vergleichswert ist die Gesamtfahrzeit aller Verkehrsteilnehmer. Dieser gibt die wirkliche Belastung des Systems „öffentlicher Straßenverkehr“ oder Materialf lussanlage durch die egoistische Routenauswahl der Teilnehmer an. In der Gepäckförderanlage eines Flughafens kann diese Diskrepanz noch leichter sichtbar gemacht werden. Wird zum Beispiel zur Einhaltung einer noch kürzeren Transferzeit für Umsteigepassagiere eine Schnellstrecke für sehr eiliges Gepäck parallel zu den bestehenden Strecken gebaut, so wird diese Strecke sofort von allen Agenten bevorzugt. Fällt eiliges Gepäck an, so kann es das normale Gepäck nicht mehr überholen. Im ungünstigsten Fall entscheiden sich, auf Grund der kürzeren Fahrzeit auf der Schnellstrecke, weitere Agenten ihren Weg zu ändern und führen dadurch eine noch größere Last auf der Schnellstrecke herbei. Eiliges Gepäck würde danach nicht schneller transportiert werden als vor dem Bau der Schnellstrecke. Sperrt man hingegen die schnelle Strecke für nicht eiliges Gepäck, so vergeudet man wertvolle Transportkapazitäten. Im öffentlichen Straßenverkehr, bei dem im Unterschied zu Gepäckförderanlagen die Geschwindigkeit mit zunehmender Verkehrsdichte sinkt, ist dieses Phänomen als Braess-Paradoxon bekannt (s. Braess 1968). Danach kann durch den Neubau einer Straße die Fahrzeit für alle Verkehrsteilnehmer ansteigen. Dem gerade beschriebenen Verhalten versucht man häufig durch die Einführung von Straf kosten zu begegnen. Wird ein Modul stark ausgelastet, so wird seine Benutzung verteuert; für schnellste Wege wird eine Strafzeit aufgeschlagen. Dieses System hat sich vielfältig bewährt und führt zu einer Lastverteilung. Sehr fallspezifisch ist dabei die Festlegung der Straf kosten: ab wann fallen sie an, wie hoch sind sie und wie ändern sie sich in Abhängigkeit von welchen Parametern? In sehr dynamischen Systemen findet dieser Ansatz schnell seine Grenzen. In Materialf luss­ anlagen ist der Durchlauf durch ein Modul im Verhältnis zur gesamten Verweilzeit in der Anlage relativ klein, jedoch belegt ein Transportstrom nicht zeitgleich den gesamten Weg von der Quelle bis zum Ziel. Strafzeiten betreffen jedoch alle Transportströme, unabhängig von deren räumlich-zeitlicher Ausdehnung. Die Bestimmung schnellster oder kürzester Wege bezüglich einer beliebigen nicht-negativen Längenfunktion ist eine dezentral gut umsetzbare Aufgabe. Da sich die kürzesten Wege je nach Lastsituation ändern, müssen diese auch individuell für die einzelnen Transportgüter bestimmt werden. Aus Sicht des Software-Engineering ist die einfachste Variante die individuelle Bestimmung des aktuell kürzesten Weges für jedes Transportgut, zum Beispiel durch ein auf Fluten basierendes Verfahren. Das führt zu einem sehr hohen Kommunikationsauf kommen zwischen den Modulen, einzig zur Bestimmung eines einzelnen Weges. Des weiteren muss der Weg später wiederholt neu bestimmt werden, da sich in der Zeit seit der Einlastung des Gutes die Situation auf dem Restweg stark verändert haben kann, zum Bei-

134

M. Hofmeister et al.

spiel durch Ausfall eines Moduls oder durch Einlastung weiterer Transportgüter. Alternativ bietet sich die im vorigen Abschnitt vorgestellte Nutzung von ständig aktualisierten Routingtabellen an. Der Einsatz dynamischer schnellster Wege zur Routenwahl ist ein attraktiver Zugang. Er ermöglicht zum Einen den Einsatz bekannter, gut untersuchter und ständigen Verbesserungen unterliegenden dezentralen Verfahren zur Bestimmung dieser Wege. Zum Anderen ist das Verfahren durch Einführung von Straf kosten leicht adaptiv zu gestalten. Schwierig ist die zielgenaue Auswahl der Straf kosten.

13.5.3  Lastabhängiges strategisches Routing Das im vorigen Abschnitt vorgestellte Routingverfahren berücksichtigt die Auslastung der Module. Es „berücksichtigt“ aber auch nicht stattfindende Kollisionen. So können in einer Gepäckförderanlage zwei Ströme von Transfergepäck aus unterschiedlichen Flugzeugen ein gemeinsames Modul benutzen, jedoch auf Grund der zeitlichen Reihenfolge dieses gar nicht zeitgleich erreichen. Führt die vermeintliche Kollision beider Ströme auf dem Modul zu Straf kosten, so werden Transportgüter um die „Staustelle“ herumgeleitet, ohne dass es dort zu einem Stau gekommen wäre. Insbesondere kann durch die gutgemeinte Umleitung die Gesamtbelastung der Anlage erhöht werden: Ein Teil der Transportgüter verbleibt länger als notwendig in der Anlage, der Durchsatz der Anlage sinkt. Grund für dieses Verhalten ist der fehlende zeitliche Bezug bei der Berücksichtigung der Last. Beheben lässt sich diese Situation durch einen Reservierungsmechanismus. Jedes Transportgut reserviert nur die von ihm auf einem Modul beanspruchte Zeit. Die zeitlichen Schwankungen in der Realität sind so groß, dass die reservierten Zeitintervalle entweder sehr groß sein müssen, was den Durchsatz der Anlage stark reduziert, oder die Reservierungen müssen ständig aktualisiert werden, was viel Kommunikations- und Rechaufwand erfordert. Insbesondere muss zur Änderung einer Reservierung die Situation komplex analysiert werden, sonst führt die Aktualisierung nur zu einem Analogon sehr großer Reservierungszeitfenster. Reservierungsverfahren und lastabhängige Straf kosten können als zwei Extrema hinsichtlich der Zeitberücksichtigung betrachtet werden. Bei der Reservierung wird die Zeit sehr genau berücksichtigt, bei den einfachen lastabhängigen Straf kosten wird die Zeit vernachlässigt. Zwischen beiden Extrema finden sich Möglichkeiten zur Berücksichtigung der Zeit, mit vertretbarem Rechenaufwand. Würde es an einem Flughafen am Tag nur zwei Ströme von Transportaufträgen geben, einen am Vormittag und einen am Nachmittag, so wäre die Zeit hinreichend berücksichtigt, wenn die Last eines Moduls differenziert nach Vormittag und Nachmittag bestimmt wird. Dieser Idee folgend kann die Zeit in Intervalle beliebig kleiner Länge unterteilt werden. Sind die Intervalle etwa 10 s lang, so kann ein Transportgut einige Sekunden früher oder später an einem Modul ankommen, ohne dass sich das Ankunftszeitfenster ändert. Auf der anderen Seite können jetzt alle Transportgüter innerhalb eines Zeitfensters fast zum gleichen Zeitpunkt eintreffen, ohne dass sich

13  Strategien für die dezentrale agentenbasierte Steuerung von Materialf lusssystemen Abb. 13.10   Die Routenzuordnung ermöglicht die Bestimmung des Eintrittszeitfensters

135

70sec

t = 10sec

t

0

30

60

90

120

em(t)

0

1

4+1

4

1

diese Situation von einer schönen gleichmäßigen Verteilung über das Zeitfenster unterscheidet. Mithin dürfen die Zeitfenster nicht zu klein sein, um robust gegen zeitliche Schwankungen zu bleiben, und auch nicht zu groß, um das Zusammenfallen zu vieler Ankunftszeitpunkte zu verhindern. Im Rest des Abschnitts werden die Hauptbereiche, aus denen sich ein solches Verfahren zusammensetzt, dargestellt: die Erstellung der Prognosezähler, die Bewertungsfunktion und die Bestimmung der verwendeten Wege. Prognose Grundlage zur Erstellung der Prognose ist die Zuordnung eines Weges zu jedem Transportgut. Auf Grund des Wissens über den (voraussichtlichen) Weg des Transportguts kann der erwartete Eintrittszeitpunkt des Guts an den Modulen entlang des Weges bestimmt werden. Das Transportgut kann somit im zugehörigen Zeitfenster bei der Prognose für das Modul berücksichtigt werden. Abbildung 13.10 verdeutlicht die Bestimmung der Prognosewerte: Dem weißen Transportgut ist der dargestellte Weg zugeordnet. Bis zum Erreichen des letzten Moduls m auf dem Weg benötige das Gut 70 s. Bei aktueller absoluter Zeit t  = 10 s wird das Transportgut im Zeitfenster 60–90 s erwartet und der Prognosewert em(60) entsprechend um 1 erhöht. Die Prognosewerte werden durch aufeinander abgestimmte Aktualisierungs- und Zerfallsprozesse bestimmt. Der exponentielle Zerfallsprozess ermöglicht den Verzicht auf einen expliziten Reservierung-Freigabe-Mechanismus. Wird ein Progno  Die Anforderung einer exklusiven Zuordnung eines Weges zu einem Transportgut ist nicht notwendig. Zum besseren Verständnis ist das Bild einer festen Zuordnung jedoch geeignet.

136

M. Hofmeister et al.

sewert durch den Aktualisierungsprozess nicht vergrößert, so fällt sein Wert schnell gegen Null. Der Aktualisierungsprozess muss auf der anderen Seite dem Zerfallsprozess so entgegenarbeiten, dass der Prognosewert eine Abschätzung für die erwartete Anzahl Transportgüter ist. Das Verfahren besteht somit aus zwei Teilen: (1) In einem festen Rhythmus ∆ werden für jedes Transportgut einzeln die Prognosewerte der erwarteten Eintrittzeitfenster an den Modulen entlang des Restwegs um 1 erhöht. (2) Im Rhythmus gleicher Länge ∆ werden alle Prognosewerte aller Module mit ½ skaliert. Der Zerfallsprozess (2) operiert rein lokal und benötigt dafür keine Information von außen. Für den Aktualisierungsprozess (1) sind hingegen die erwarteten Eintrittszeitpunkte der Güter an den Modulen notwendig. Diese Information müssen die Module von außen erhalten, in Abschn. 25.6.3 wird ein dezentrales Verfahren zur Erzeugung dieser Information vorgestellt. Die mit diesem Vorgehen bestimmten Prognosewerte sind somit gebrochene Zahlen. Daher kann ein Transportgut, welches gegen Ende eines Zeitfensters an einem Modul erwartet wird, bei der Prognose auch im nachfolgenden Zeitfenstern schon anteilig berücksichtigt werden. Im Mittel beschreiben die Prognosewerte dann die erwartete Anzahl Transportgüter im zugehörigen Zeitfenster. Stehen Daten für zukünftig zu erwartende Transportaufträge zur Verfügung, so können diese ebenfalls berücksichtigt werden. Dem erwarteten Transportgut wird wie allen anderen Transportgütern ein Weg zugeordnet. Nur der Startzeitpunkt für den Weg unterscheidet sich, statt der aktuellen Zeit wird der erwartete Einlastzeitpunkt verwendet. Das noch nicht eingelastete Transportgut wird dadurch schon in der zukünftigen Auslastung der Anlage berücksichtigt. Bewertungsfunktion Die Bewertungsfunktion zur Bestimmung der Weglängen ist das Kernelement zur Lastverteilung. Die zum Transport zu wählenden Routen werden als kürzeste Wege bezüglich dieser Bewertungsfunktion bestimmt. Sie steuert somit, welche Wege für Transportaufträge unter der aktuellen Prognose benutzt werden. Die Bewertungsfunktion besteht aus zwei Teilen: 1. den Standarddurchlaufzeiten für die Module, sowie 2. der Straf komponente je Modul, welche sich aus der prognostizierten Anzahl Transportgüter im erwarteten Eintrittszeitfenster für das Modul bestimmt. Die ausschließliche Nutzung der Standarddurchlaufzeiten würde einer statischen Version des in Abschn. 13.5.2 beschriebenen Verfahrens der schnellsten Wege entsprechen. Adaptiv wird das Verfahren durch die Straf komponente. Generelle Idee ist die Einführung von Straf kosten proportional zu den erwarteten Wartezeiten, wenn man das Materialf lusssystem als Warteschlangensystem betrachtet. Sei x die relative Auslastung eines Moduls in einem Zeitfenster und f( x) die Funktion zur Berechnung der Straf komponente. Die Funktion f( x) ist monoton wachsend und sollte umso schneller wachsen, je größer die relative Auslastung x ist. Beachtet werden muss, dass der Prognosewert die Kapazität des Moduls in einem Zeitfenster übersteigen kann. Die relative Auslastung x, der Quotient von erwarteter Anzahl und maximaler Anzahl Transportgüter, welche innerhalb eines Zeitfensters in das Mo-

13  Strategien für die dezentrale agentenbasierte Steuerung von Materialf lusssystemen

137

dul eintreten könnten, wäre im betrachteten Zeitintervall größer als 1. Die Funktion f( x) muss daher auch für Werte größer oder gleich 1 wohldefiniert sein. Routenauswahl Die Route für ein einzelnes Transportgut zu seinem Ziel bestimmt sich prinzipiell als kürzester Weg zum Ziel, wobei möglicherweise weitere Nebenbedingungen berücksichtigt werden müssen. Wie im Abschnitt zur Bewertungsfunktion beschrieben, berücksichtigt diese die erwartete Auslastung der Module zum wahrscheinlichen Eintrittszeitpunkt des Transportguts. Die erwartete Auslastung der Module ändert sich mit der Einlastung neuer Güter sowie dem Transport der in der Anlage befindlichen Güter. Um dem Rechnung zu tragen, müssen die Routen der Transportgüter in regelmäßigen Abständen neu bestimmt werden. Wie schon beim Verfahren der schnellsten Wege verbietet sich auf Grund der Kommunikationsdatenf lut die explizite Durchführung einer eigenen Berechnung des kürzesten Weges für jedes Transportgut auf Basis von Fluten. Die einfachste, direkte Möglichkeit ist eine Variante des verteilten Label-Correction-Algorithmus, Abschn. 13.5.1. Als Label kommen um die zeitliche Dimension erweiterte Richtungstabellen zur Anwendung. Eine erweiterte Richtungstabelle für ein Modul m enthält für jedes mögliche Ziel x in der Materialf lussanlage eine Entfernungstabelle dist( m, x). Die Entfernungstabelle dist( m, x) enthält für alle Prognosezeitfenster, beginnend mit dem aktuellen Zeitfenster bis zum maximalen Prognosezeithorizont, die Entfernung zum Ziel sowie das Nachfolgemodul, über welches diese Distanz bestimmt wurde. Abbildung 13.11 zeigt schematisch die Relationen von Modul, Richtungstabelle und Entfernungstabelle. Stehen diese Tabellen an jedem Modul zur Verfügung, so ist die Bestimmung eines kürzesten Weges sehr einfach. Befindet sich die Transporteinheit im aktuellen Zeitfenster t1 = 0 auf dem Modul m1 und hat das Ziel x, so ist das Nachfolgemodul das Modul in der Spalte t1 von Tabelle dist( m1, x); m2 bezeichne das entsprechende Modul. Weiterhin bestimmt Modul m1 den Eintrittszeitpunkt und das Eintrittszeitfenster t2 in das Modul m2. Diese Werte werden zusammen mit dem bisherigen Weg,

Modul Richtungstabelle ··· ···

Ziel

X

Entfernungstabelle

···

···

Y

Entfernungstabelle Zeitfenster

dist(m,x) =

Abb. 13.11   Erweiterte Richtungstabelle zu einem Modul

0

10

···

Entfernung

13

8

···

Modul

m1

m2

···

138

M. Hofmeister et al.

[m1], an das Modul m2 übergeben. Modul m2 bestimmt aus der Spalte t2 von Tabelle dist( m2, x) das Nachfolgemodul, m3, sowie den Eintrittszeitpunkt und das Eintrittszeitfenster t3 in das Modul m3. Diese Werte werden zusammen mit dem bisherigen Weg, [m1, m2], an Modul m3 übergeben. Modul m3 und alle nachfolgenden Module verfahren analog, bis ein Modul mit Endpunkt x erreicht ist. Falls erforderlich, wird der erzeugte Weg, [m1, m2, m3, …], zurück an Modul m1 kommuniziert. Die Erstellung der erweiterten Richtungstabellen erfolgt analog der klassischen Version eines verteilten Label-Correction-Algorithmus. Da sich die Entfernungen (lastabhängigen Bewertungen der Module) kontinuierlich ändern, aktualisiert ein Modul regelmäßig seine Richtungstabelle an Hand der Richtungstabellen seiner direkten Nachfolgemodule. Das heißt, Modul m aktualisiert für jedes mögliche Ziel x in der Materialf lussanlage die Entfernungstabelle dist( m, x) an Hand der Entfernungstabellen dist( m1, x), …, dist( mk, x) seiner Nachfolgemodule m1, …, mk. Zur Vereinfachung der Beschreibung seien zunächst alle Durchlaufzeiten durch ein Modul Vielfache der Zeitfensterlänge ∆. Die Durchlaufzeit durch Modul m im Zeitfenster t sei nt ⋅ ∆. Aktualisiert ein Modul m die Entfernungstabelle dist( m, x) zum Ziel x, so bestimmt es folgendes Minimum

dist(m, x)[t] = dm,t + min{dist(m , x)[t + nt ]|m = m1 , . . . , mk },

wobei dist( m, x)[t] den Entfernungseintrag in der Spalte t von Tabelle dist( m, x) bezeichne und dm,t den Wert der Bewertungsfunktion für Modul m im Zeitfenster t. Der Wert sei ∞, wenn das Ziel x nicht über das Modul erreicht werden kann. Weiterhin wird zu dem Entfernungseintrag das Modul mj gespeichert, an welchem das Minimum angenommen wurde. Würde sich die Bewertung der Module, die Länge aus Sicht des Label-Correction-Algorithmus, nicht ändern, so enthielten die Richtungstabellen nach einiger Zeit die kürzesten Wege. Die Bewertung der Module ist jedoch ständigen Änderungen unterworfen. Durch den dynamischen Prozess der Lastprognoseerstellung für die Module ändern sich auch deren Bewertungen. Des weiteren ist die Bewertung dm,t der Module nur ein Hilfsmittel, um die Auslastung zu beurteilen. Eine exakte Bestimmung der kürzesten Wege ist somit nicht notwendig. Daher können die Richtungstabellen unabhängig, asynchron durch die Module aktualisiert werden. Die auf Basis dieser Richtungstabellen gefundenen Wege sind von ausreichender Qualität. Basierend auf den drei beschriebenen Komponenten Prognose, Bewertungsfunktion und Routenauswahl, lässt sich ein lastabhängiges strategisches Routingverfahren vollständig dezentral umsetzen. Die zu erzeugende Information beschränkt sich auf die erweiterten Richtungstabellen der Module. Neben Parametern wie Zeitfenstergröße oder maximaler zeitlicher Schätzhorizont sind keinerlei global vorzugebende Daten mit Bezug zur Gesamttopologie notwendig. Insbesondere wird kein Wissen über erwartete Einlastszenarien verwendet. Im Abschn. 25.6 werden Resultate und Erkenntnisse mit diesem Verfahren bei der Simulation der Gepäckförderanlage eines Flughafens vorgestellt.

13  Strategien für die dezentrale agentenbasierte Steuerung von Materialf lusssystemen

139

13.6  Zusammenfassung Die Entwicklung von Strategien für dezentrale agentenbasierte Steuerungen von Materialf lusssystemen ist eine komplexe Aufgabe. Als Hilfsmittel zur Strukturierung der Aufgabe wurde ein Zustandsraum für Agentensysteme vorgestellt. Zwei Dimensionen unterscheiden nach der verfügbaren Information sowie der erlaubten Komplexität eingesetzter Algorithmen. Die dritte Dimension sind die strategischen Aspekte auf Grund topologischer Eigenschaften. Am Beispiel der Routenauswahl in einer stärker vernetzten Topologie wurden dezentrale Lösungsansätze vorgestellt. Eine systemische Betrachtungsweise der Routenauswahl lenkt den Fokus auf die zeitlichen Auswirkungen von Routenentscheidungen. Dazu wurde ein generisches Konzept zur Erstellung einer Routauswahlstrategie vorgestellt, welches die Materialströme in ihrer zeitlichen und räumlichen Dimension berücksichtigt. Der mathematisch interessierte Leser findet eine tiefgehende Untersuchung von Systemen autonomer Akteure mit Hilfe von spieltheoretischen Methoden in dem Buch von (Nisan et al. 2007).

Kapitel 14

Konfiguration und Überwachung einer verteilten Materialf lusssteuerung Razvan Chisu, Florian Kuzmany und Willibald A. Günthner

14.1  Motivation Die Konzepte des Internet der Dinge ermöglichen eine vollständig dezentral organisierte Steuerung eines Materialflusssystems. Trotzdem gibt es auch hier Aufgaben, welche im Sinne des Systemherstellers bzw. -bedieners nicht dezentralisiert werden können. Wichtige Beispiele dafür sind die Erstellung der Topologie, die Konfiguration der Entitäten und deren Workflows und die Überwachung der Materialflussanlage mit einer Visualisierungsumgebung. Sowohl die Topologieerestellung als auch die Konfiguration können dabei als vorgelagerte Tätigkeiten aufgefasst werden: Sie müssen ausgeführt werden, bevor ein Internet-der-Dinge-System einsatzbereit ist und die gewünschte Gesamtfunktion erbringen kann. Die Überwachung des Systems findet hingegen während des Betriebs der Anlage statt. Für diese Aufgaben werden Softwarewerkzeuge benötigt, die es Planern, Anlagenbauern und Anlagenbetreibern von einem zentralen Ort aus ermöglichen, das Internet der Dinge an den jeweiligen Einsatzfall anzupassen.

14.2  Systemkonfiguration Eine dezentral gesteuerte Materialflussanlage kann aus autonomen Entitäten erzeugt werden. Dabei muss das Gesamtsystem bzw. seine Komponenten auf verschiedenen Ebenen konfiguriert werden: • Anlagentopologie Es ist notwendig, die Nachbarschaftsbeziehungen zwischen den Modulen zu deklarieren. Technologien zur automatischen Topologiefindung sind zwar R. Chisu () Lehrstuhl für Fördertechnik Materialfluss Logistik fml, Technische Universität München Boltzmannstr. 15, 85748 Garching, Deutschland e-mail: [email protected] W. Günthner, M. ten Hompel (Hrsg.), Internet der Dinge in der Intralogistik, DOI 10.1007/978-3-642-04896-8_14, © Springer-Verlag Berlin Heidelberg 2010

139

140

•

•



•

R. Chisu et al.

bereits bekannt (s. z. B. Mayer 2009), allerdings erfordert dieser Ansatz den phy­ sikalischen Aufbau der Gesamtanlage und ist damit für Planungs- oder Simulationszwecke ungeeignet. Arbeitsabläufe bzw. Workflows Die Steuerung des Materialflusses inkl. der dazu notwendigen Strategien wird zwar dezentral umgesetzt, allerdings muss die Festlegung der eigentlichen Geschäftslogik, also der erwünschten Gesamtfunktion, immer noch von einem Planer oder Bediener vorgenommen werden. Dazu werden Arbeitsabläufe und Workflows definiert (s. a. Kap. 10). Konfiguration der einzelnen Module Um einen hohen Wiederverwendungsgrad der Steuerungssoftware zu erzielen, sollten ähnlich ausgeprägte Module von den gleichen Agenten gesteuert werden. Damit diese Agenten trotzdem mit der jeweiligen Mechanik zusammen arbeiten können, muss diesen genau mitgeteilt werden, welcher Mechanik sie zugeordnet sind bzw. wie sie mit der Maschinensteuerung kommunizieren können. Dies führt beispielsweise zur Anpassung der Middlewareschicht zwischen Agen­ ten- und Maschinensteuerungsebene (s. Kap. 11) oder der Definition sonsti‑ ger modulspezifischer Eigenschaften wie z. B. die Anzahl an Pufferplätzen auf einem Stauförderer. Verteilung der Steuerungssoftware Im Rahmen der Inbetriebnahme werden die erstellten Steuerungsprogramme und Agenten auf die jeweiligen Endgeräte verteilt. Wird ein strikt mechatronischer Aufbau des Systems verfolgt, kann das manuelle Kopieren der Software auf Hunderte oder, im Fall sehr komplexer Anlagen, sogar Tausende von Controllern ein sehr zeitraubender Vorgang sein. Hier ist ein automatisierter Prozess für das Kopieren der Steuerungslogik, der Konfigurationsdateien und evtl. der Topologie auf die verteilte und an einem Datennetz angeschlossene Steuerungshardware anzustreben.

Ein Werkzeug, das diese Funktionen erfüllt und somit zum Systemmanagement eingesetzt werden kann, kann selbst nicht Teil des zu administrierenden Systems sein, sondern stellt ein alleinstehendes Tool dar. Ein solcher „Internet der Dinge Manager“ muss zum einen eine intuitive und für den Benutzer leicht handhabbare grafische Oberfläche besitzen, zum anderen müssen von den Modulen lesbare Konfigurationsdateien, beispielsweise im XML-Format, einfach exportiert und verteilt werden können. In Abb. 14.1 ist die prototypenhafte Umsetzung eines solchen Management-Tools zu sehen, welches die oben beschriebenen Anforderungen erfüllt und am Lehrstuhl für Fördertechnik Materialfluss Logistik fml der TU München entwickelt wurde. Um das steuerungslogische Modell einer Materialflussanlage zu erstellen, werden aus einer Bibliothek vorgefertigte Fördertechnikmodule ausgewählt und auf dem Bildschirm platziert. Diese Module verfügen über Ein- und Ausgänge, welche sich wiederum miteinander verbinden lassen. Auf diese Weise ist der Anwender in der Lage, in relativ kurzer Zeit die Topologie einer gesamten Materialflussanlage zusammen zu stellen. Dabei können die Verbindungspunkte nicht nur durch konkrete

14  Konfiguration und Überwachung einer verteilten Materialf  lusssteuerung

141

Abb. 14.1   GUI-basierte Definition einer Anlagentopologie

Module definiert sein, sondern auch durch logistische Dienstleistungen bzw. Funktionen. Das bedeutet zum Beispiel im Fall eines Fahrerlosen Transportsystems, dass ankommende Transporteinheiten von einem beliebigen Fahrzeug transportiert werden dürfen, das einen entsprechenden Transportdienst anbietet. Diese Zuordnung über logistische Funktionen sorgt dafür, dass bei einer späteren Erweiterung des Systems, beispielsweise durch den Einsatz zusätzlicher Fahrzeuge, keine Änderung der Topologiebeschreibung bzw. der Steuerungsprogrammierung durchgeführt werden muss. Das neue Fahrzeug wird lediglich als Erbringer der jeweiligen Funktion registriert und kann sofort eingesetzt und von anderen Modulen gefunden und angesprochen werden. Die angebotenen Funktionen werden als Informationen im Datensatz eines Moduls hinterlegt. Hier werden beispielsweise auch eine eindeutige ID des Moduls und die IP-Adresse der Steuerungshardware eingestellt. Außerdem kann die Schnittstel­ le zwischen der Agentenebene und der Maschinensteuerungsebene bzw. zum jewei­ ligen Emulator konfiguriert werden (s. Kap. 11 und 12). Auch die physikalische Ausprägung eines Moduls ist in weiten Grenzen konfigurierbar: Dies kann die Länge eines Förderers, die Anzahl und Position der Stauplätze oder ein spezielles Lastaufnahmemittel für ein Regalbediengerät sein.

142

R. Chisu et al.

Sind diese Einstellungen vorgenommen, kann der Benutzer die fertig konfigurierten Steuerungsagenten und alle Topologieinformationen abspeichern und in einer Testumgebung das Anlagenverhalten simulieren. Verläuft dieser Test erfolgreich, so werden die erstellten Daten automatisch auf die realen Steuerungskomponenten ver­ teilt. Diese Vorgehensweise sorgt für eine aufwandsarme und frühe Fehlererkennung und vermindert den Inbetriebnahmeaufwand erheblich.

14.3  Systemüberwachung und -visualisierung Obwohl das Internet der Dinge autonom und hochdynamisch auf verschiedene Gegebenheiten und Einflüsse reagiert, müssen auch Bediener in der Lage sein, das System in seiner Gesamtheit zu überwachen und auf evtl. Störungen zu reagieren. Abläufe und Prozesse müssen, vor Allem wenn mehrere Entitäten beteiligt sind, für den Anlagenbetreiber verständlich und nachvollziehbar sein, denn dies ist sowohl für die Gewährleistung der sicheren und effizienten Funktionsweise des Systems als auch zur Steigerung der Kundenakzeptanz erforderlich. Dabei unterscheidet sich das Monitoring von den meisten anderen Funktionen in einem Materialflusssystem dadurch, dass Informationen über einen Großteil oder über alle Entitäten im Gesamtsystem an einer zentralen Stelle, z. B. einer Visualisierungsstation, zusammengeführt und bereitgestellt werden. Um eine möglichst große Übereinstimmung zwischen dem angezeigten und dem tatsächlichen Anlagenzustand zu gewährleisten, müssen diese systemweiten Informationen so schnell bzw. häufig wie möglich gesammelt werden, ohne dabei die Kommunikationslast im System so stark ansteigen zu lassen, dass die Anlagenfunktion beeinträchtigt wird. Dies ist vor allem bei blackboardbasierter Kommunikation allerdings kein größeres Problem, da ohnehin alle relevanten Informationen an einer zentralen Stelle verfügbar sind. Neben der benutzerfreundlichen Anzeige von Informationen bietet ein Monito‑ ringdienst bzw. eine Visualisierungsumgebung im Normalfall aber auch die Möglich­ keit, in die Steuerung des Systems manuell einzugreifen. So müssen beispielsweise während der Wartung betroffene Förderer oder Transportmittel in einen passiven Be‑ triebszustand versetzt und anschließend wieder aktiviert werden.

14.3.1  Allgemeingültigkeit durch regelbasierte Visualisierung Die Überwachung eines komplexen Systems erfordert sowohl textuelle als auch grafische Darstellungsmöglichkeiten. Dabei muss aber vor allem die grafische Ausgabe durch den Bediener in möglichst großem Umfang konfigurierbar sein, um die Übertragbarkeit bzw. Wiederverwendbarkeit der Visualisierungssoftware für verschiedene Systeme zu ermöglichen. Zu diesem Zweck wird der Leitgedanke des Internet der Dinge auch auf die Visualisierungsumgebung an sich übertragen: statt eine Anwendung zu implementieren, die auf die Logik eines bestimmten Materialflusssystems oder auf bestimmte

14  Konfiguration und Überwachung einer verteilten Materialf  lusssteuerung

143

Abb. 14.2   Regelbasierte 2D-Visualisierung einer EHB-Anlage

Fördermodule zugeschnitten ist, werden nur grundlegende Visualisierungsfunktionen hinterlegt, die dann vom Bediener angepasst und verknüpft werden. Auf diese Weise können mit derselben Applikation verschiedenste Materialflusssysteme oder auch andere Daten und deren Beziehungen dargestellt werden (s. Abb. 14.2). Jede Informationseinheit im System – z. B. eine Entität bzw. deren Zustands­ information oder auch ein anderes Element der Ontologie, z. B. ein Transportauftrag – wird als Datenobjekt mit verschiedenen Parametern aufgefasst. So entspricht einem Unstetigförderer beispielsweise ein Datenobjekt mit den Parametern Betriebszustand, aktuelle Position und aktuell bearbeiteter Auftrag, während eine Transporteinheit beispielsweise ihr aktuelles Ziel und den zuletzt passierten Identifikationspunkt kennt. Dabei kann eine Visualisierung mit beliebigen Datenobjekten und Parametern umgehen und ist nicht auf eine im Voraus definierte Ontologie bzw. Datenformat angewiesen. Werden die Informationen in einem flexiblen und erweiterbaren Format mit dazugehörigen Metadaten bereitgestellt, z. B. als XML, kann ein Monitoring-Tool unterschiedlichste Datenstrukturen bearbeiten und anzeigen.

144

R. Chisu et al.

Die vorhandenen Daten können vom Benutzer im Textformat direkt eingesehen werden, während für die Erzeugung und Animation von 2D oder auch 3D Grafiken folgende Funktionen zur Verfügung stehen: • Grafische Anzeige eines Datenobjekts als geometrische Form, Text oder 2DBild bzw. 3D-Modell an einer festen Position im 2D-/3D-Raum und mit einer festen Größe und Farbe • Dynamisches Anzeigen bzw. Verstecken eines Datenobjekts in Abhängigkeit eines oder mehrerer Parameter • Dynamisches Ändern der Farbe, der Größe oder des Bildes eines Datenobjekts in Abhängigkeit seiner Parameter • Neuberechnung der Position eines Datenobjekts im 2D-/3D-Raum auf Grund seiner Parameter, relativ zum Ursprung des Koordinatensystems oder relativ zu einem anderen Datenobjekt. Ebenso kann auch das Versenden von Nachrichten durch den Benutzer an die einzelnen Agenten, beispielsweise zum Verändern von Betriebsarten, auf ähnliche Weise durch frei konfigurierbare Regeln abgedeckt werden. Den angezeigten Objekten können Menüs oder andere Eingabeaufforderungen zugeordnet werden, die auf Mausclick eine bestimmte Nachricht an die zugehörige Entität versenden.

14.3.2  Nachverfolgbarkeit und Historien Die Anzeige des aktuellen Systemzustands genügt im Normalfall für die Identifikation von Fehlern oder anderen besonderen Situationen, wie z. B. Staus. Befindet sich die Anlage oder ein Teil davon in einem kritischen Zustand, stellt sich aber meist auch die Frage, wie und warum es zu dieser Situation gekommen ist, was allein am Ist-Zustand meistens nicht mehr zu erkennen ist. Deswegen müssen in einem Materialflusssystem Abläufe und Ereignisse auch über längere Zeiträume aufgezeichnet und rückverfolgt werden können. In einer klassischen, zentral gesteuerten Anlage ist dies verhältnismäßig einfach: der Materialflussrechner und die SPS können eigene Historien aufzeichnen und diese beispielsweise in Form von Logfiles speichern. Dadurch können interne Zustandsabfolgen, Ereignisse und Entscheidungen des jeweiligen Rechensystems bei Bedarf grafisch oder textuell angezeigt und einzeln analysiert werden. Das Aufzeichnen solcher lokaler Logfiles ist im Internet der Dinge genau wie in klassischen Systemen möglich. Neben den lokalen Entscheidungen ist in einem dezentralen, kooperativen Netzwerk aber auch die Interaktion bzw. Kommunikation zwischen den zahlreichen Einheiten ausschlaggebend für das Gesamtverhalten. Daher sind Konzepte und Tools erforderlich, die es erlauben: • die Historien bzw. Logfiles mehrerer Entitäten zusammenzuführen und die einzelnen Entscheidungen in zeitlich korrekter Reihenfolge darzustellen, und • die Kommunikation im Netzwerk aufzuzeichnen, um diese auf der Ebene einzelner Nachrichten und Sender-Empfänger-Beziehungen nachverfolgen und analysieren zu können.

14  Konfiguration und Überwachung einer verteilten Materialf  lusssteuerung

145

Die Zusammenführung mehrerer Logfiles ist nur dann sinnvoll, wenn die aufgezeichneten Ereignisse mit einem Zeitstempel versehen sind und die Uhren der Rechenplattformen, auf denen die Historien aufgezeichnet wurden, mit möglichst hoher Genauigkeit synchronisiert wurden. Zur Synchronisation von Uhren mehrerer vernetzter Rechner sind Protokolle wie das Network-Time-Protocol NTP bekannt und auch in den meisten gängigen Betriebssystemen (UNIX, Windows ab der Version XP) bereits implementiert. In der Version 4 bietet NTP bereits über das Internet eine Genauigkeit von 10 ms, in lokalen Netzwerken können sogar Genauigkeiten im Mikrosekunden-Bereich erzielt werden. Damit ist die wichtigste Voraussetzung für die Analyse verteilter Entscheidungsprozesse bereits gegeben. Zur Aufzeichnung des Nachrichtenverkehrs kann auf Tools zurück gegriffen werden, die direkt auf der Ebene des Kommunikationsnetzwerks den gesamten Nachrichtenverkehr aufzeichnen. So genannte Sniffer sind sowohl für EthernetNetzwerke als auch für verschiedene Bussysteme wie z. B. CAN verfügbar. Der Nachteil einer Kommunikationsanalyse auf der Ebene einzelner Nachrichten besteht allerdings in der manuell zu bewältigenden „Datenflut“. Das Einrichten von Filtern reduziert diese zwar im Normalfall, indem nur Nachrichten aufgezeichnet werden, die bestimmte Kriterien erfüllen – beispielsweise also einen bestimmten Absender oder Empfänger oder einen gewissen Inhalt haben. Das Nachvollziehen der Interaktion zwischen mehreren Agenten erfordert aber dennoch eine gute Kenntnis der im System eingesetzten Protokolle. Möchte ein Operator z. B. nachvollziehen, warum ein bestimmtes Modul einen Transportauftrag angenommen hat, und nicht ein anderes, muss er das eingesetzte Kommunikationsprotokoll für die Auftragsvergabe kennen und wissen, in welcher Reihenfolge die verschiedenen Teilnehmer welche Informationen austauschen bzw. austauschen sollten. Der aufgezeichnete Nachrichtenverkehr kann dann mit dem Protokoll abgeglichen werden, wodurch fehlende oder fehlerhafte Informationen oder sonstige Unstimmigkeiten aufgedeckt werden können. Dabei ist anzumerken, dass mit zunehmendem Vernetzungsgrad der Einheiten die Analyse und Nachvollziehbarkeit der Kommunikation schwieriger wird.

14.3.3  Statistiken Neben der Nachverfolgbarkeit und Nachvollziehbarkeit der Vorgänge im System sind für den Anlagenbetreiber oftmals auch Statistiken wichtig, denn diese geben Auskunft über erreichte Durchsätze, Auslastungen oder Wartezeiten. Die Grundlage für eine statistische Auswertung von Systemzuständen wird bereits durch die Möglichkeit zur Nachverfolgbarkeit des Nachrichtenaustausches und vor Allem der Speicherung von Historien gegeben, denn diese enthalten bereits alle Zustände und Zustandsübergänge des Systems in einem bestimmten Zeitraum. Die grafische Aufbereitung von Informationen kann auch in diesem Fall individuell definiert werden, ähnlich wie es von Tabellenkalkulationsprogrammen bekannt ist. So kann aus Historien einzelner Entitäten beispielsweise berechnet werden, wie lange sie in welchem Zustand verbracht haben und damit zu wie viel Prozent sie

146

R. Chisu et al. Visualisierungsumgebung

Workflowdefinition

X

X

X

Realisierung

Topologiedefinition

X

X

X

X

Simulation

Planung

Modulkonfiguration

Betrieb

IdD-Manager

Softwareverteilung

Visualisierungsregeln

Onlinebefehle

X

X

X

X

X

X

X

Abb. 14.3   Zentral durchzuführende Tätigkeiten und ihre Abdeckung durch Softwaretools

ausgelastet waren. Durch die Kombination der Historien mehrerer Entitäten lässt sich dann z. B. auch die Verteilung der Gesamtsystemlast auf einzelne Einheiten bestimmen, was das Aufspüren von Ungleichgewichten bei der Ressourcen- oder Auftragsdisposition ermöglicht. Diese und ähnliche Zusammenhänge können als Kreis-, Linien- oder Balkendiagramme angezeigt werden.

14.4  Zusammenfassung Auch im Internet der Dinge lassen sich zentral durchzuführende Tätigkeiten finden. Diese beziehen sich zum einen auf die Planung einer materialflusstechnischen Anlage und die Konfiguration ihrer Komponenten und zum anderen auf die Systemüberwachung. Beide Bereiche sind durch geeignete Softwaretools abzudecken, die unter anderem die grafische Definition von Topologien, Workflows und Visualisierungsstrategien erlauben müssen (s. Abb. 14.3).

Kapitel 15

Simulation und Emulation im Internet  der Dinge Damian Daniluk und Razvan Chisu

Zur Untersuchung eines komplexen Systems kommen zunächst mehrere Techniken in Frage (Abb. 15.1). Neben der Durchführung von Experimenten am realen System kann auch ein physisches Modell zur Analyse genutzt werden. Nachteilig wirken sich bei dieser Methode der hohe Aufwand verbunden mit hohen Kosten sowie möglicherweise ungenaue Ergebnisdaten aus. Eine Alternative zum physischen Modell kann daher das mathematische Modell, beispielsweise in Form einer analytischen Betrachtungsweise, sein. Hierbei ist jedoch zu berücksichtigen, dass analytische Modelle bei komplexen, dynamischen Wirkzusammenhängen und bei Berücksichtigung stochastischer Einflüsse werden müssen, schnell an ihre Grenzen stoßen. Eine weitere Methode zur Untersuchung eines Systems stellt die Simulation dar. Die folgenden Abschnitte vermitteln die Grundlagen der Simulation und gehen auf die Emulation als eine wichtige Spezialanwendung der Simulation ein. Nach der Darstellung der Anwendungsfelder werden die Nutzungsmöglichkeiten dieser Techniken im Umfeld des Internet der Dinge diskutiert.

15.1  Simulation – Begriff und Anwendung Der Begriff der Simulation ist nach der VDI-Richtlinie 3633, welche sich mit der Simulation von Logistik-, Materialfluss- und Produktionssystemen befasst, definiert als „…ein Verfahren zur Nachbildung eines Systems mit seinen dynamischen Prozessen in einem experimentierbaren Modell, um zu Erkenntnissen zu gelangen, die auf die Wirklichkeit übertragbar sind. Im weiteren Sinne wird unter Simulation das Vorbereiten, Durchführen und Auswerten gezielter Experimente mit einem Simulationsmodell verstanden. Mit Hilfe der Simulation kann das zeitliche Ablaufverhalten komplexer Systeme untersucht werden.“

D. Daniluk () Fraunhofer-Institut für Materialf luss und Logistik IML Joseph-von-Fraunhofer Straße 2-4, 44227 Dortmund, Deutschland e-mail: [email protected] W. Günthner, M. ten Hompel (Hrsg.), Internet der Dinge in der Intralogistik, DOI 10.1007/978-3-642-04896-8_15, © Springer-Verlag Berlin Heidelberg 2010

147

148

D. Daniluk und R. Chisu System

Experiment am realen System

Experiment am Modell physisches Modell

mathematisches Modell analytische Lösung

Simulation

Abb. 15.1   Methoden zur Untersuchung eines Systems

Die Simulation stellt längst ein anerkanntes Hilfsmittel für verschiedene Fachrichtungen wie Technik, Naturwissenschaften und Gesellschaftswissenschaften dar. Der Einsatz von Simulation erfolgt typischerweise in Situationen, in denen • • • • •

Neuland beschritten wird die Grenzen analytischer Methoden erreicht sind komplexe Wirkzusammenhänge die menschliche Vorstellungskraft überfordern das Experimentieren am realen Modell nicht möglich bzw. zu kostenintensiv ist das zeitliche Ablaufverhalten einer Anlage untersucht werden soll

Lag die Anwendung der Simulationstechnik im Bereich der Produktion und Logistik ursprünglich auf der Absicherung der Planung, reicht die Anwendung heute von der ersten Planung über die Realisierung bis hin zum Betrieb von logistischen Systemen (s. Tab. 15.1). Somit findet die Simulation im gesamten Lebenszyklus von technischen Systemen ihren Einsatz. Insbesondere zur Analyse von hochdynamischen Abläufen bei Materialflusssys­ temen ist die Simulation nicht wegzudenken. Auch wenn beispielsweise alle Komponenten eines Distributionslagers, von dem Gabelstapler bis zur Fördertechnik, Tab. 15.1   Anwendungsfelder der Simulation in Produktion und Logistik Phase Anwendungsfelder der Simulation Planung

Realisierung Betrieb

•  Verbesserung vorhandener Anlagen (Redesign, Tuning) •  Überprüfung neugeplanter Anlagenkonzepte •  Entwurf von Steuerungsstrategien •  Bewertung von Alternativen •  Entwicklung und Test von Steuerungssoftware •  Ermittlung des Anlaufverhaltens der Anlage •  Mitarbeiterschulung • Vergleichende Untersuchung von Strategien und Ablaufvarianten •  Reihenfolgeoptimierung von Prozessabläufen •  Strategien bei Störfällen •  Mitarbeiterschulung

15  Simulation und Emulation im Internet der Dinge

149

einen geforderten Maximaldurchsatz mühelos erfüllen, so kann doch das Zusam­ menspiel dieser Komponenten zu Situationen führen, in denen es zu Engpässen kommt und der geforderte Gesamtdurchsatz nicht erreicht wird. Eben dieses dynamische Zusammenspiel vieler unterschiedlicher Materialflusskomponenten und stochastischer Einf lüsse ist mit mathematisch-analytischen Mitteln kaum handhabbar, so dass hier die Simulationstechnik oftmals die einzige anwendbare Methode ist. Einige beispielhafte Fragestellungen, die bei der Planung eines Distributionssystems auftauchen, sind: • Wo befinden sich die Engpässe und Schwachstellen des Systems? • Wie hoch sind die Durchlaufzeiten von Aufträgen und wie ist hier die Streuung? • Kann das System einen vorgegebenen Auftragsmix wie gefordert bewältigen? • Wie verhält sich das System bei Störungen oder Spitzenbelastungen? • Welches Anlaufverhalten weist das System zu Beginn einer Schicht auf ? Im Laufe einer Simulationsstudie werden diese Fragen durch konkrete Frageste­ llungen ergänzt. Die prinzipielle Vorgehensweise bei der Durchführung einer Simu­ lationsstudie ist ein sich wiederholender Prozess aus Analyse-, Entwicklungs- und Interpretationsschritten (Abb. 15.2). Die wesentlichen Schritte einer Simulationsstudie sind die Vorbereitung, die Durchführung und die Auswertung.

15.1.1  Durchführung einer Simulationsstudie 15.1.1.1  Vorbereitung Bevor mit einer Simulationsstudie begonnen werden kann, muss zunächst eine Grundsatzentscheidung über die Simulationswürdigkeit einer zuvor definierten Problemstellung getroffen werden. Dazu gehört neben dem Sammeln und Prüfen alternativer Lösungstechniken (Abb. 15.1) die Gegenüberstellung des zeitlichen und monetären Aufwandes einer Simulationsstudie zu ihrem Nutzen. Weiterhin ist ein Zielsystem festzulegen, welches das Gesamtziel sowie die miteinander in Wechselwirkung stehenden Teilziele spezifiziert.

reales System

Modellierung Abstraktion

Simulationsmodell Experimente

Folgerung für das reale System

Übertragung Interpretation

Abb. 15.2   Ablauf einer Simulationsstudie

formale Ergebnisse

150

D. Daniluk und R. Chisu

Ist das Zielsystem definiert, kann der Aufbau der Datenbasis erfolgen, welche alle für die Simulation benötigten Daten enthält (z. B. Daten zur Beschreibung der Systemkomponenten oder der Systemlast). An dieser Stelle ist zu unterscheiden, ob es sich bei dem zu modellierenden System um ein bereits bestehendes oder ein geplantes System handelt. Bei Letzterem stellt sich die Datenbeschaffung schwieriger dar, da in der Regel keine Erfahrungswerte oder konkrete Daten in Form von Arbeitsplänen etc. existieren. Hier können Daten ähnlicher, bereits bestehender Systeme hilfreich sein. Nach erfolgter Aufbereitung und Abstimmung der Daten ist der Grundstein für das zu erstellende Simulationsmodell gelegt. Im nächsten Schritt führt die Abstraktion eines real vorhandenen oder auch gedanklich konzipierten Systems in einem Modellierungsprozess zu einem Modell. Ziel dabei ist die vereinfachte Beschreibung des realen Systems. Mit Hilfe der Abstraktion, Vereinfachung, Vernachlässigung oder Formalisierung von Teilen des Ausgangssystems ist eine deutliche Reduzierung der Komplexität im Modell möglich. Dabei gilt der Grundsatz, dass das Maß der Komplexität eines Simulationsmodells nur so hoch wie nötig sein und das Modell keine in Hinblick auf die Fragestellung unnötigen Elemente enthalten sollte. Der Modellierungsprozess führt zunächst zu einem konzeptuellen Modell, welches die Grenzen des Realsystems festlegt. Danach wird das logische Modell erstellt, welches die Struktur und den Materialfluss des Ausgangssystems beispielsweise in Form von Fluss- oder Blockdiagrammen abbildet. Die Erstellung eines solchen logischen Modells ist ein wesentliches Qualitätskriterium für eine hochwertige Simulationsstudie. Diesem Schritt folgt die Erstellung des Simulationsmodells mit einem Simulationswerkzeug, indem Teile des konzeptuellen Modells schrittweise umgesetzt und – soweit dies notwendig ist – verfeinert werden. Zur Kontrolle der Umsetzung des logischen Modells in Programmcode erfolgt die Verifizierung. Diese dient dem formalen Nachweis der Korrektheit des Programmcodes und wird in der Regel softwaretechnisch unterstützt. Während des gesamten Modellierungsprozesses hat mit der Validierung ein iterativer Prüf- und Korrekturprozess stattzufinden, welcher die hinreichende Übereinstimmung zwischen Original und Modell sicherstellt. 15.1.1.2  Durchführung Der Implementierung des Modells folgen die Simulationsläufe. Hierbei werden in Hinblick auf das definierte Ziel sinnvolle Versuchsreihen aufgestellt, in deren Rahmen das Simulationsmodell mit verschiedenen Parametern ausgeführt wird. Diese gezielte Untersuchung des Modellverhaltens wird auch als Experiment bezeichnet. 15.1.1.3  Auswertung Die während oder am Ende von Experimenten am Simulationsmodell gewonnenen Daten müssen nun auf   bereitet, verdichtet und anschließend interpretiert werden,

15  Simulation und Emulation im Internet der Dinge

151

um Rückschlüsse auf das Verhalten des realen Systems ziehen zu können. Die Darstellungsformen der Simulationsergebnisse lassen sich dabei in Animation (dynamische Anzeige der Zustandsänderungen des Modells während der Simulation), Monitoring (dynamische Anzeige von Zustandsgrößen wie beispielsweise Durchsatz in graphischer oder textueller Form während des Simulationslaufs) und Statistiken (Darstellung der Ergebnisdaten der Simulation in textueller oder graphischer Form am Ende der Simulation) gliedern. Die meisten am Markt erhältlichen Simulationswerkzeuge sammeln bereits automatisch wichtige Informationen und Kennzahlen zum Simulationsmodell. Weitere modellspezifische Kennzahlen müssen benutzerdefiniert erhoben werden.

15.1.2  Vor- und Nachteile der Simulation 15.1.2.1  Vorteile Die Simulation erlaubt die Durchführung von Experimenten in verkürzter Zeit. Prozesse, die in der Realität lange Laufzeiten benötigen, können mit Hilfe der Simulation in einem Bruchteil dieser Zeit betrachtet werden. Daraus ergibt sich unmittelbar der weitere Vorteil, durch vielfache Durchführung eines Simulationslaufs die statistische Genauigkeit der Simulationsergebnisse und damit die Validität des Modells deutlich erhöhen zu können. Insgesamt lassen sich durch die quantifizierbaren Ergebnisse einer Simulationsstudie Fehlplanungen frühzeitig erkennen und Vorgehensweisen objektiv argumentieren. Der Einsatz der Simulation führt außerdem zum Durchbruch der Grenzen analytischer Methoden. Die Komplexität großer logistischer Systeme und die Untersuchung ihres dynamischen Verhaltens stellen die analytischen Methoden meist vor unüberwindbare Probleme. Ein simulationstechnischer Ansatz verspricht hier Abhilfe. Zudem verschafft hier die Möglichkeit der (3D-)Animation, welche durch viele Simulationswerkzeuge im Bereich der Logistik unterstützt wird, auch fachfremden Personen Zugang zum Verständnis des Gesamtsystems. Auf diese Weise können komplizierte Wirkzusammenhänge verständlicher und einfacher fassbar gemacht werden. 15.1.2.2  Nachteile Einfache Antworten auf komplexe Fragestellungen kann die Simulation jedoch nicht liefern. Hat das Simulationsmodell aufgrund der Fragestellung einen erheblichen Umfang und ist die Vielfalt der Einflüsse auf die abgebildeten Abläufe groß, so ist ein entsprechend hoher Aufwand bei der Modellerstellung und der Interpretation der Simulationsergebnisse notwendig. Einleuchtend ist auch die Tatsache, dass Simulation keine wertvollen Ergebnisdaten liefern kann, wenn die Güte der Eingangsdaten unzureichend ist. Die Datenbeschaffung als der kritischste und wesentlichste Bestandteil einer Simulationsstudie trägt dafür

152

D. Daniluk und R. Chisu

Sorge, dass die in Simulationsläufen betrachteten Vorgänge und gesammelten Daten vertrauenswürdige Schlussfolgerungen auf das reale System zulassen.

15.2  Emulation – Begriff und Anwendung Die Emulation bildet einen Spezialfall der Simulation. Ein Emulationsmodell kann als ein Simulationsmodell angesehen werden, das mit teils realen Funktionskomponenten gekoppelt wird. Hinsichtlich der Nutzung und dem Betrieb von Simulations- und Emulationsmodellen existieren signifikante Unterschiede. Simulationsmodelle werden für umfassendes Experimentieren genutzt, indem das Simulationsmodell vielen Simulationsläufen unterzogen wird, so dass durch Parametervariationen Alternativen miteinander verglichen werden können. Bei Emulationsmodellen ist dies nur in eingeschränkter Weise möglich, da hier die Ausführungsgeschwindigkeit durch die Beschaffenheit des Steuerungssystems häufig auf die Realzeit beschränkt ist. Auch ist bei der Emulation der Anwendungsbereich deutlich enger umrissen, als dies bei der Simulation der Fall ist. Das hängt damit zusammen, dass mit einem Emulationsmodell ein Ausschnitt eines physischen Systems durch Einbeziehung einer realen Funktionskomponente sehr zielgerichtet betrachtet wird. In der Regel müssen die einzelnen Systemkomponenten daher im Emulationsmodell detailgetreuer abgebildet werden als dies bei Simulationsstudien der Fall ist. Emulation wird typischerweise zunehmend als Hilfsmittel zur Entwicklung und Inbetriebnahme von Steuerungssystemen herangezogen. Bei der Durchführung von Tests von Steuerungssystemen sind prinzipiell vier Möglichkeiten zu unterscheiden. In Abb. 15.3 sind diese Möglichkeiten aufgezeigt. Demnach kann ein Steuerungssystem zum einen nach der Installation am realen Einsatzort getestet werden (1). Dies entspricht der am häufigsten praktizierten und herkömmlichen Vorgehensweise. Eine andere Methode besteht darin, die Kombination aus Steuerungssystem und dem logistischen System rein simulativ zu testen (4). In der Planungsphase von logistischen Anlagen (auch: Lagerkonzeptplanung) ist dies die gängige Vorgehensweise. Die Verknüpfung zwischen Realität und Simulation

Realität

Simulation

Steuerungssystem

Steuerungssystem

1

Abb. 15.3   Methoden zum Test von Steuerungs­systemen

2

zu steuerndes System

3

4

zu steuerndes System

15  Simulation und Emulation im Internet der Dinge

153

stellen die Ansätze (2) und (3) aus Abb. 15.3 her. Somit handelt es sich bei diesen Ansätzen um Emulationsmethoden. Bei Ansatz (2) werden reale Teile einer logistischen Anlage in eine Simulation integriert, welche die Ablauffunktionen aller übrigen Prozesse übernimmt. Ansatz (3) ermöglicht durch die Kopplung von realem Steuerungssystem und Simulator die Inbetriebnahme von Steuerungssystemen in einer Softwareumgebung. Im allgemeinen Sprachgebrauch sowie im vorliegenden Buch bezeichnet der Begriff der Emulation (auch: Online-Simulation) den Ansatz (3). Der Testaufwand für Software und damit insbesondere auch für Steuerungs­ software ist beträchtlich. Er schwankt zwischen 15% und 50% des Gesamtentwicklungsaufwandes, abhängig von den Anforderungen, die an die Zuverlässigkeit der Software gestellt werden. Ein Teil der Fehler kann durch erste Modultests während der Entwicklungsphase aufgedeckt werden. Das Zusammenspiel aller Systemkomponenten der Steuerungssoftware wird heute jedoch in der Regel erst an der realen Anlage geprüft. Diese Prüfung stellt allerdings den wesentlichen Teil der Testphase dar. Betrachtet man nun den Verlauf eines Projektes von der Planung bis zur Realisierung und Inbetriebnahme eines Lagers, so ist die nach der mechanischen Anlagenfertigstellung erfolgende Inbetriebnahme eines Steuerungssystems kostenintensiv und langwierig. Hinzu kommt, dass sich die in Produktdefinitionen von Steuerungssystemen definierten Anforderungen nicht nur auf die Funktionalität der Software allein, sondern in der Regel auch auf das Gesamtsystem beziehen, in welchem die Software eingesetzt wird. Selbst wenn die Software in funktionaler Hinsicht keine Fehler aufweist, so kann ein Abnahmetest dennoch fehlschlagen, weil beispielsweise der geforderte Systemdurchsatz nicht erfüllt worden ist. Erst durch Testläufe kann ein Steuerungssystem auf solche Aspekte hin untersucht werden. Wird während des Projektes die Simulation zur Unterstützung herangezogen, so kann das im Rahmen der Lagerkonzeptplanung erstellte Simulationsmodell nach einigen Modifikationen bereits im Laufe der Entwicklung eines Steuerungssystems zu Testzwecken genutzt werden. Durch die Emulation lassen sich Experimente mit der Steuerungssoftware am Computer durchführen. Die Experimentdurchführung wird dadurch einfacher und kann schneller als bei dem Einsatz in der realen Anlage erfolgen. Können die Entwicklungsarbeiten der Projektteams für das Simulationsmodell der Planungsphase und der Steuerungssoftware zudem parallelisiert werden, so kann der Aufwand für die wiederholte Implementierung der Steuerungsstrategien (einmal im Simulationsmodell der Planungsphase und zusätzlich im Steuerungssystem selbst) vermieden werden. Das Vorziehen der Testaktivitäten führt zu einer verkürzten Dauer des Gesamt­ projektes, da der Umfang der im realen Betrieb durchzuführenden Tests deutlich abnimmt. Zu berücksichtigen ist auch, dass bei eventuellen Änderungen, Aktualisierungen oder Erweiterungen der Steuerungssoftware zu einem Zeitpunkt, zu dem die reale Anlage bereits in Betrieb ist, das Emulationsmodell herangezogen werden kann, um die Funktionalität der Steuerungssoftware vor dem Einsatz im realen Betrieb zu testen. Mit geringfügigen Anpassungen des Simulationsmodells können ebenso die Auswirkungen von Änderungen/Erweiterungen der realen Anlage analysiert werden.

154

D. Daniluk und R. Chisu

Die Vorteile des Einsatzes von Emulation bei Steuerungssystemen sind zusam­ menfassend: • Unterstützung bei der frühzeitigen Erkennung von Fehlern sowie systematischere und effizientere Fehlersuche und -behebung ohne Beeinträchtigung des Betriebes der realen Anlage • Reduzierung der Kosten bei Inbetriebnahme von Steuerungssystemen durch Verkürzung der Inbetriebnahmezeit und die damit verbundene Verringerung des Risikos der Überschreitung eines Projektendtermins • Vermeidung des Aufwandes und der Fehler durch wiederholte Implementierung von Algorithmen und Kontrolllogik im Simulationsmodell der Planungsphase und im Steuerungssystem selbst • Einsatz als Trainingswerkzeug zum Erlernen der Anlagensteuerung • Unterstützung bei der Erstellung von Lasten- und Pflichtenheften für das Steuerungssystem • Unterstützung bei der Erstellung von Steuerungsstrategien der Steuerungssoftware • Analyse von Auswirkungen von Änderungen der Steuerungssoftware oder der realen Anlage Ein weiterer Vorteil der Emulation in Zusammenhang mit auf dem MultiagentenParadigma basierenden Steuerungssystemen ist die Möglichkeit des Trainings der selbstlernenden Software-Agenten und deren Optimierung in Hinblick auf den Einsatz im realen Betrieb. Gerade bei der Entwicklung von dezentralen Steuerungssystemen kann die Emulation eine große Hilfe darstellen, da der Test dieser Systeme in komplexen Materialflussumgebungen schwer zu koordinieren ist.

15.3  Werkzeuge zur Materialf lusssimulation Die Modellerstellung wird von den am Markt erhältlichen Materialf lusssimulatoren typischerweise durch die Platzierung graphischer Bausteine sowie mit Hilfe von Auswahlmenüs und Dialog-Fenstern unterstützt. Die Bausteine können ein bereits vorprogrammiertes Verhalten aufweisen, wodurch die Programmierarbeit entfällt. Mittels großer Bibliotheken, welche vordefinierte Bausteine enthalten, können viele Simulationsszenarien abgedeckt werden. Zur Erhöhung der Flexibilität bieten die meisten Materialf lusssimulatoren neben der Möglichkeit der Modellierung mittels Bausteinen auch die Möglichkeit der spezifischen Anpassung des Modellverhaltens durch Programmierung. So können die Vorteile beider Welten genutzt werden. Ein wichtiges Kriterium bei der Klassifikation von Simulatoren stellt ihr zeitliches Verhalten dar. Unterschieden wird hierbei zwischen diskreten, kontinuierlichen und hybriden Simulatoren. In einem kontinuierlichen Simulationsmodell ändern sich die betrachteten Größen über die Zeit hinweg kontinuierlich. Die Systemzustandsänderungen können hier als Funktion der Zeit beschrieben werden. Eine Anwendung findet sich beispielsweise in der Simulation von Fließprozessen.

15  Simulation und Emulation im Internet der Dinge

155

Diskrete Simulationsmodelle hingegen bilden betrachtete Größen diskontinuierlich ab. Änderungen des Systemzustandes erfolgen zu diskreten Zeitpunkten. Ein Beispiel hierfür ist die Menge von Objekten auf einem Förderband. Die Menge ändert sich nur zu bestimmten Zeitpunkten, nicht jedoch kontinuierlich über einen Zeitabschnitt hinweg. Ändern sich in einem Simulationsmodell einige Größen diskret und andere kontinuierlich, so spricht man von einem hybriden Simulationsmodell. Im Bereich der Materialflusssimulation sind ereignisdiskrete Simulatoren am weitesten verbreitet. Die meisten am Markt vorhandenen Materialflusssimulatoren arbeiten ereignis­ diskret. Die Zeitfortschreibung bei der Simulation erfolgt immer dann, wenn ein Ereignis, d. h. eine Zustandsänderung im Simulationsmodell eintritt. Die wesentlichen Bestandteile eines ereignisdiskreten Simulators sind: • eine Ereignisliste, in der die noch nicht verarbeiteten Ereignisse in der aufsteigenden Reihenfolge ihrer Zeitstempel vorgehalten werden, • eine Simulationszeitvariable, die die gegenwertige Simulationszeit der Simulation speichert, • eine Menge globaler Datenstrukturen bzw. Zustandsvariablen zur Beschreibung des Zustands des Simulationsmodells sowie • die mit den Ereignissen in der Ereignisliste assoziierten Ereignisroutinen. Mit der Menge der Zustandsvariablen sind alle Informationen gegeben, welche ein Simulationsmodell zu einem bestimmten Zeitpunkt vollständig beschreiben. Da der Zustand des Simulationsmodells zwischen zwei Ereignissen keinerlei Änderung erfährt, erfolgt der Zeitfortschritt in ereignisdiskreten Systemen „sprunghaft“ von Ereignis zu Ereignis. Jedes Ereignis ist mit einem Zeitstempel versehen, der bestimmt, zu welchem Zeitpunkt innerhalb einer Simulation das Ereignis eintreten wird. Vor der Ausführung des Ereignisses wird die Simulationszeit auf den Wert des Zeitstempels des nächsten Ereignisses aus der Ereignisliste gesetzt. Nachdem durch Ausführung eines Ereignisses bzw. der entsprechenden Ereignisroutine alle Zustandsänderungen im System vollzogen und ggf. neue Ereignisse in die Ereignisliste eingeplant worden sind, wird die Simulationszeit wiederum auf die Zeit des nächsten Ereignisses in der Ereignisliste erhöht und dieses anschließend ausgeführt. Da die Zeit zwischen zwei aufeinander folgenden Ereignissen nicht betrachtet wird, kann – ausreichende Rechnerleistung vorausgesetzt – verglichen mit der Realität eine deutliche Zeitraffung der betrachteten Abläufe im Simulationsmodell erreicht werden. Dabei kann ein ereignisgesteuerter Simulator in Hinblick auf die Beziehung zwischen Simulations- und Realzeit grundsätzlich drei verschiedene Ausführungsarten unterstützten: • Echtzeit: Die Simulationszeit schreitet synchron mit der Realzeit voran. • skalierte Echtzeit: Die Simulationszeit schreitet um einen konstanten Faktor schneller oder langsamer als die Realzeit voran. • schnellstmöglich: In Simulationen, bei welchen keine Interaktion mit Personen oder physischen Komponenten stattfindet, besteht im Regelfall kein Zusammenhang zwischen Simulations- und Realzeit. Die Erhöhung der Simulationszeit um eine Einheit ist ausschließlich von der benötigten Rechenzeit abhängig. Der Zeitfortschritt der Simulationszeit erfolgt damit „so schnell wie möglich“.

156

D. Daniluk und R. Chisu

15.4  Simulation im Internet der Dinge Eine Experimentierumgebung sollte es ermöglichen, auch einzelne Aspekte von Multiagentensteuerungen zu untersuchen. Da die kommerziellen ereignisdiskreten Materialflusssimulatoren die Abbildung von agentenbasierten Steuerungskonzepten nicht unterstützen, muss die Agentenlogik zunächst in ein existierendes Simulationsmodell eingefügt werden. Bei hinreichend großen Modellen gestaltet sich eine manuelle Anpassung des Simulationsmodells sehr aufwändig und ist deshalb nicht praktikabel. Aus diesem Grund ist eine automatische Verarbeitung und Anpassung des Simulationsmodells erstrebenswert. Eine mögliche Vorgehensweise hierzu ist in Abb. 15.4 skizziert. Das bestehende Simulationsmodell wird im ersten Schritt in eine abstrahierte Darstellung, den Materialf lussgraph, überführt. Anhand des Materialf lussgraphen und der Auswahl des zu untersuchenden Agentenkonzeptes kann bestimmt werden, an welchen Stellen im Quellcode des Simulationsmodells die Agentensteuerung einzufügen ist. Darüber hinaus muss in dem ereignisdiskreten Simulationswerkzeug die von den Agenten genutzte Kommunikationsinfrastruktur abgebildet werden. Die Herausforderung besteht darin, die Agentenkommunikation zu simulieren. Die Zeitverzögerung beim Versand der Nachrichten muss dabei ebenso berücksichtigt werden wie die korrekte Nachbildung der Nachrichtenprotokolle. Im Simulationswerkzeug lassen sich Agenten, Vorwissen und Nachrichten in einer objektorientierten Datenstruktur darstellen. Während der Ausführung der Agentenprogramme in der Simulation senden Agenten Nachrichten an andere Agenten, indem sie über Methodenaufrufe die Nachrichten als Parameter übergeben. Die Methodenaufrufe werden nicht sofort ausgeführt, sondern in die zukünftige Ereignisliste des Simulationsprogramms eingeordnet. So lässt sich die Zeitverzögerung während des Versands der Nachrichten abbilden. Nachrichtenverluste

existierendes Simulationsmodell

Materialflussgraph

Agentenkonzept

Algorithmus zur Bestimmung der Agentenposition

Agentenprogramm

Kommunikationsinfrastruktur

Multiagentengesteuertes Simulationsmodell

Abb. 15.4   Generierung von agentengesteuerten Simulationsmodellen

15  Simulation und Emulation im Internet der Dinge

157

können abgebildet werden, indem Methodenaufrufe stochastisch verteilt nicht in die Ereignisliste eingeordnet, sondern verworfen werden. Nach dem in Abb. 15.4 skizzierten Konzept wurde eine Simulation einer Gepäckförderanlage eines großen Flughafens realisiert (vgl. Follert u. Roidl 2008). Die Materialf lusssteuerung erfolgte unter Verwendung eines dezentralen Steuerungskonzeptes, bei dem ausgewählten Förderstreckenelementen Agenten zugeordnet wurden, die ein dezentrales Routing der Gepäckstücke auf Grundlage des Dynamic Source Routing (vgl. Johnson und Maltz) und des Kürzeste-Wege-Algorithmus von Djikstra (vgl. Sedgewick 2002, S. 516 ff.) realisierten. Das Routing bestimmt, über welche Förderstrecken die einzelnen Gepäckstücke geleitet werden, um ausgehend von der Einschleusung in die Gepäckförderanlage rechtzeitig ihren Zielpunkt (z. B. ein bestimmtes Abf lug-Gate) zu erreichen. Flughafengepäckförderanlagen stellen derzeit eine der größten Herausforderungen für das Routing in Intralogistiksystemen dar. Die strukturelle und dynamische Komplexität dieser Anlagen ist besonders hoch, so dass zentrale Steuerungsansätze aufgrund der hohen Anforderungen an die benötigte Rechenleistung sowie die Robustheit und Flexibilität solcher Systeme schnell an ihre Grenzen stoßen. Das betrachtete Modell gehört mit rund 12.000 Fördertechnikelementen zu den größten Gepäckförderanlagen ihrer Art. Mit der Simulation der Gepäckförderanlage unter Verwendung eines dezentralen Steuerungsansatzes konnte gezeigt werden, dass: • der Einsatz eines multiagentenbasierten Steuerungskonzeptes geeignet ist, um den Materialf lusses in großen Fördertechniksystemen zu steuern • durch die Formalisierung der Gepäckförderanlage in Form eines Materialf lussgraphen eine effiziente Zuordnung von Agenten zu Fördertechnikelementen möglich ist • für die einzelnen Agenten ein universeller Algorithmus von unter 400 Zeilen Quellcode ausreicht, um eine effizientes Routing der Gepäckstücke zu realisieren • der Kommunikationsaufwand zwischen den Agenten einen wesentlichen Ein­ f luss auf die Leistungsfähigkeit der dezentralen Steuerung hat. Insgesamt stellt die Simulation von großen Materialflussmodellen immer noch sehr hohe Anforderungen an die ausführende Hardware. Gerade die auf dem Konzept des Internet der Dinge basierenden Steuerungsphilosophien wie die Verkürzung von Anlaufphasen komplexer Fördersysteme oder die flexible Reaktion auf kurzfristige Systemzustandsänderungen zeigen bei von hoher Komplexität geprägten logistischen Strukturen ihre Vorteile. Daher ist insbesondere die Untersuchung von detaillierten Simulationsmodellen im Umfeld des Internet der Dinge von großem Interesse. Um Experimentierumgebungen zu schaffen, die eine hohe Ausführungsgeschwindigkeit der Simulation erlauben, ist neben dem Einsatz leistungsfähiger Rechner die Nutzung von verteilter Simulation von großem Interesse (vgl. Fujimoto 2000). Bei der verteilten Simulation wird das Simulationsmodell in mehrere von einander abhängige Teilmodelle zerlegt bzw. partitioniert. Die einzelnen Teilmodelle können auf unterschiedlichen Rechnern parallel ausgeführt werden. Die Herausforderungen

158

D. Daniluk und R. Chisu

liegen derzeit in der Entwicklung effizienter und Anwendungsfeld-optimierter Algorithmen, die eine möglichst hohe Parallelität bei der Ausführung der einzelnen Teilmodelle im Rahmen der verteilten Simulation erlauben sowie in einer weitgehend aufwandsarmen und damit automatisierten Partitionierung des Simulationsmodells. Ein hoher Detaillierungsgrad des betrachteten Modells ist insbesondere auch bei der Emulation von hoher Bedeutung. Das Emulationsmodell soll sich weitestgehend analog zu der realen Anlage verhalten und muss dazu das Verhalten der einzelnen Anlagenkomponenten originalgetreu abbilden. Ist die Abbildung des Materialflusssystems im Emulationsmodell hinreichend genau, steht mit der Emulation insbesondere im Internet der Dinge ein mächtiges Werkzeug zur Verfügung, welches in verschiedenen Phasen im Lebenszyklus eines Materialflusssystems eingesetzt werden kann. Mit den Vorteilen und Einsatzmöglichkeiten der Emulation im Internet der Dinge befasst sich der nachfolgende Abschnitt.

15.5  Emulation im Internet der Dinge Einer der wichtigsten Vorteile des Internet der Dinge gegenüber klassischen Steuerungsarchitekturen besteht darin, dass die Steuerungslogik in Form eines Agenten­ baukastens für verschiedene Projekte wieder verwendet werden kann. Im speziellen Bezug auf die Simulation bedeutet dies auch, dass das Steuerungssystem bereits in der Planungsphase zur Verfügung steht, sofern es im Rahmen früherer Projekte oder in einer projektunabhängigen Entwicklungsphase implementiert wurde. Dabei ist auch zu beachten, dass die Agenten des Internet der Dinge, wie in Kap. 11 beschrieben, durch die Konfiguration von Schnittstellen und ohne Programmieraufwand sowohl mit einer realen als auch mit einer simulierten logistischen Anlage kommunizieren können. Somit ist die Erstellung einer Emulation des Typs (3) (s. Abb. 15.3) zu jedem Zeitpunkt im Lebenszyklus einer Anlage technisch möglich. Dabei stehen für die Simulation des zu steuernden Systems, also des Verhaltens der physikalischen Anlagenkomponenten, zwei Möglichkeiten zur Verfügung: der Einsatz eines gängigen (kommerziellen) Materialf lusssimulators und der Einsatz eines agentenbasierten Simulationsbaukasten.

15.5.1  Einsatz eines gängigen Materialflusssimulators Ein bereits am Markt verfügbares Werkzeug dient als Ausführungs- bzw. Simulationsumgebung für ein eigens erstelltes Modell der Anlagenphysik. Dieses Modell enthält die Topologie der Anlage sowie alle Parameter, die sich direkt auf die mechanischen Komponenten beziehen, wie z. B. Fördergeschwindigkeiten, Verarbeitungszeiten oder Kapazitäten. Dabei trifft das überlagerte Agentensystem alle strategischen Entscheidungen während im Simulator der reine fördertechnische Prozess abgearbeitet und wichtige Kennzahlen wie Durchsätze oder Durchlaufzeiten

15  Simulation und Emulation im Internet der Dinge

159

bestimmt werden. Der Vorteil dieses Vorgehens besteht im hohen Grad der erreichbaren Simulationsgenauigkeit für das zu steuernde System bzw. für die Anlagenmechanik. Ein aufwandsarmer Einsatz dieser Methode ist allerdings nur unter der Voraus­ setzung möglich, dass eine direkte Zuordnung zwischen den Bausteinen des Simulators und den Steuerungsagenten gegeben ist. So muss für jeden die Anlage steuernden Agenten ein entsprechender Fördertechnikbaustein vorhanden sein. Die Simulationsumgebung muss also, je nach Szenario, Stetig- und Unstetigförderer, Verzweigungen, Zusammenführungen sowie Arbeitsstationen und Lagerplätze (s. Kap. 8) abbilden können. Wünschenswert für die Kopplung zwischen einem Steuerungssystem und einem Simulator ist, dass ein als Grundlage dienendes Simulationsmodell möglichst nur einige wenige Kommunikationsbausteine, die die Verbindung zum Agentensystem herstellen, benötigt. Dabei sollten diese Bausteine bzw. die Schnittstelle zum Agentensystem mit geringem Aufwand deaktiviert und durch ein ebenfalls simuliertes Steuerungssystem ersetzt werden können. Dadurch kann die simulierte Anlagenphysik, die beispielsweise in der Planungsphase im Rahmen einer Emulation verwendet wird, in der Realisierungsphase für eine komplette Simulation des Systems wiederverwendet werden, wenn eine solche notwendig oder erwünscht ist. Der Informationsaustausch zwischen agentenbasiertem Steuerungs- und dem simulierten zu steuernden System kann prinzipiell auf zwei Arten geschehen: • Sockets: Die Kommunikation zwischen Steuerungssystem und Simulator erfolgt durch Telegrammaustausch, beispielsweise unter Verwendung des TCP/IP-Protokolls über so genannte Sockets. Als Socket wird eine bidirektionale SoftwareSchnittstelle bezeichnet, welche Anwendungen mittels eines Netzwerkprotokolls wie TCP/IP miteinander verbindet. • Datenbank: Steuerungssystem und Simulator greifen auf eine (Echtzeit-) Datenbank zu. Alle Zustandsänderungen, die sich im Simulationsmodell ergeben, werden in der Datenbank mitgeführt. Umgekehrt werden die Prozesse im Simulationsmodell durch Zustandsänderungen der Datenbank gesteuert, die sich aufgrund von Zugriffen des Steuerungssystems auf die Datenbank ergeben. Zum Zugriff auf die Datenbank kann beispielsweise eine standardisierte SQL-Schnittelle (z. B. ODBC-Schnittstelle) verwendet werden.

15.5.2  Agentenbasierter Emulationsbaukasten Jedem Steuerungsagenten wird ein Emulatoragent zugeordnet, der die Funktion der Mechanik bzw. der Maschinensteuerungsebene (s. Kap. 11) abbildet. Da die Steuerungslogik des Internet der Dinge aus einem Standardbaukasten von Softwareagenten besteht, kann zusätzlich ein Standardbaukasten für Emulatoren entwickelt werden, die den Steuerungsagenten in einer direkten 1:1 Beziehung zugeordnet werden können. Diese Emulatoren können innerhalb derselben Laufzeitumgebung wie die Steuerungsagenten ausgeführt werden und benötigen somit kein externes Simulationswerkzeug. Ein Nachteil dieser Methode liegt in dem

160

D. Daniluk und R. Chisu

Aufwand für die Erstellung des Emulatorbaukastens, da Funktionen wie die Berechnung logistischer Kenngrößen wie dem Durchsatz sowie Mechanismen für die zeitliche Synchronisation der zahlreichen Emulatoren manuell implementiert werden müssen. Für den Datenaustausch zwischen Steuerungssystem und Emulatoragenten sind dabei keine besonderen Kommunikationsbausteine oder zusätzlichen Schnittstellen notwendig, da sämtliche Kommunikation über die Mechanismen des eingesetzten Agentensystems sichergestellt ist.

15.5.3  Emulation in den Lebenszyklusphasen In den einzelnen Phasen des Lebenszyklus eines Materialf lusssystems kann die Emulation unterschiedlich eingesetzt werden. 15.5.3.1  Projektunabhängige Implementierung des Agentenbaukastens Während der projektunabhängigen Implementierung des Agentenbaukastens ist sie ein Werkzeug für die Entwicklung, den Test und die Optimierung der Agentenlogik. Vor allem Module, die einen komplexen Ablauf steuern und sich mit anderen Modulen abstimmen müssen, um Materialflussstrategien oder höherwertige Funktionen umzusetzen, sind hierbei von Bedeutung, da die Entwicklung der Kooperations- und Koordinationsstrategien ein unter Umständen komplexer Prozess ist. Steuerungskonzepte für aggregierte Module, beispielsweise die einzelnen Bahnen eines Sorters mit oder ohne Paarbidung (s. Kap. 13), können im Rahmen einer Emulation getestet und optimiert werden. Der Vorteil dieser emulationsbasierten Entwicklung der Systemsteuerungslogik besteht darin, dass eine gesonderte und evtl. iterative Übertragung von Programmcode zwischen simuliertem und realem Steuerungssystem entfällt: zeigt ein Agent in einer Emulation das gewünschte Verhalten, kann er direkt für die Steuerung einer realen Anlage eingesetzt werden. Zusätzlich muss hier erwähnt werden, dass sich die physikalischen Komponenten, die eine simulative Abbildung erfordern, im Regelfall nicht ändern, wenn der Steuerungsagent um höherwertige Funktionalität ergänzt wird. Wurde also die Mechanik und das physikalische Verhalten eines Rollenförderers einmal in einer Simulation als Baustein abgebildet, kann dieser sowohl für die Entwicklung eines einfachen Stetigfördereragenten als auch für die Implementierung einer Sorterbahn mit kooperativer Paarbildungsfunktion herangezogen werden. 15.5.3.2  Planungsphase In der Planungsphase ergibt sich im Internet der Dinge durch das Erstellen des Layouts einer Anlage, also der Auswahl und Platzierung der Fördertechnikmodule, das Steuerungssystem auf direkte Weise – denn die den Modulen zugeordneten Agenten

15  Simulation und Emulation im Internet der Dinge

161

stehen mit dem Anlagenlayout fest und können direkt instanziiert und ausgeführt werden. Zwar können Anpassungen und Optimierungen des Steuerungssystems bzw. einzelner Agenten während der Realisierungsphase notwendig werden, aber der Einsatz eines standardisierten und vordefinierten Agentenbaukastens erlaubt bereits in der Planungsphase eine detailliertere und genauere Analyse des Anlagenverhaltens, als das bisher möglich ist. 15.5.3.3  Realisierungsphase In der Realisierungsphase können neue, anlagenspezifische Strategien und Optimierungsmaßnahmen in einer Emulation getestet werden. Zwar bietet eine Emulation keine Reproduzierbarkeit von Versuchen zur Bestimmung logistischer Kenngrößen wie eine reine Simulation. Dafür kann das reale Steuerungssystem bereits vor dem Einsatz in der realen Anlage ausgiebig getestet werden, so dass die Inbetriebnahme deutlich verkürzt werden kann. In Abb. 15.6 ist das Kommunikationsverhalten eines multiagentenbasierten Steuerungssystems im Rahmen der Kopplung an das in Abb. 15.5 abgebildete Emulationsmodell dargestellt (s. Trautmann u. Daniluk 2006). Als Kommunikationsschnittstelle wurde eine Middleware, die so genannte High Level Architecture (HLA) eingesetzt. Insgesamt zeigen die Ergebnisse in Abb. 15.6, dass bei der Telegrammkommunikation im Rahmen der Emulation ein realitätsnahes Zeitverhalten erzielt werden kann. Hier sind die Ergebnisse eines Emulationslaufs zu sehen, bei dem zwei Transportaufträge vom Steuerungssystem an den Simulator gesendet wurden. Dasselbe Szenario wurde anschließend mit dem an die reale Pilotanlage gekoppelten Steuerungssystem durchgeführt. In Abb. 15.5 sind zwischen Realität und Emulation vergleichend die kommunizierten Telegramme kumuliert über die verstrichene Zeit in Sekunden während des jeweiligen Transportauftrags aufgetragen. Initiiert durch einen Transportauftrag des Steuerungssystems wird ein Behälter von einem Quell-Lagerplatz aufgenommen und an einem Ziel-Lagerplatz TP: Transfer Point (Behälterübergabepunkt) Dreh- TP 03 umsetzer Inaktive Shuttles

TP 02 Horizontalumsetzer

Lift

TP 01

TP 04 Lastobjekt

Abb. 15.5   Ein mit dem kommerziellen Materialf lusssimulator AutoMod erstelltes Emulationsmodell zum Testen eines multiagentenbasierten Steuerungssystems in der Realisierungsphase

162

D. Daniluk und R. Chisu

Transferpunkt 02 40

Hochregal, 3. Ebene, 7. Fach links

Anz. Telegramme

30

Transportauftrag beendet

Behälter abgeben

20

Behälter aufgenommen

10

Lift erreicht

Realität Emulation

0

0

5

10

Hochregal, 3. Ebene, 7. Fach links 40

15

20

25

30

Hochregal, 4. Ebene, 7. Fach links

Anz. Telegramme Lift erreicht

30

Behälter abgeben

Behälter aufgenommen

20 10

Transportauftrag beendet Realität Emulation

0

Sec.

0

5

10

15

20

25

Sec. 30

Abb. 15.6   Experimenteller Vergleich der Telegrammkommunikation zwischen Realität und Emulation bezogen auf das Emulationsmodell in Abb. 15.5

eingelagert. Der Fahrauftrag wird von genau einem autonomen Behälterfahrzeug (Shuttle) durchgeführt. Für den ersten Transportauftrag liegt die Startposition des Shuttles zwischen den Transferpunkten TP02 und TP03 (vgl. Abb. 15.5). Die Transportanweisungen des Steuerungssystems an das Shuttle bestehen darin, einen Behälter vom Transferpunkt TP02 zu entnehmen und diesen im Hochregal einzulagern. Das Shuttle muss dazu nach der Behälteraufnahme genau zehn Positionen in Vorwärtsrichtung fahren, um anschließend den Behälter abzugeben. Der zweite Transportauftrag besteht darin, den nach dem vorangegangenen Transportauftrag eingelagerten Behälter wieder auszulagern und in das im Hochregal eine Ebene höher liegende Fach einzulagern. Die Abweichungen der Kurven in Abb. 15.6 liegen darin begründet, dass im realisierten Emulationsmodell einige Eigenschaften der physischen Komponenten nicht abgebildet worden sind. Um das Fahrverhalten der Shuttles im Modell dem Verhalten der realen Fahrzeugen anzugleichen, müsste beispielsweise das zweistufige Abbrems- und Beschleunigungsverhalten der Shuttles modelliert werden. Die Diagramme und die während der Experimentierphase gemessenen Antwortzeiten lassen den Schluss zu, dass es durch einen höheren Modellierungsaufwand möglich ist, das reale System sehr präzise abzubilden. Erforderlich ist hierzu

15  Simulation und Emulation im Internet der Dinge

163

ein Materialf lusssimulator, der eine entsprechend f lexible Programmierung der physischen Eigenschaften des modellierten Materialf lusssystems zulässt. 15.5.3.4  Betrieb Auch im Betrieb sind Szenarien denkbar, in denen eine Emulation eingesetzt werden kann. Vor allem wenn Erweiterungen oder Änderungen einer Anlage in Erwägung

Abb. 15.7   Mischbetrieb eines realen Elektrohängebahnsystems (dunkelgrau) und einer simulierten Anlagenerweiterung (hellgrau) in der Betriebsphase unter Verwendung eines agentenbasierten Emulationsbaukastens

164

D. Daniluk und R. Chisu

gezogen werden, kann die Mechanik der neuen Bereiche als Simulation abgebildet, deren Steuerung aber mit realen Agenten umgesetzt werden. Dabei können diese mit den bereits instanziierten, die reale Anlage steuernden Agenten innerhalb derselben Umgebung ausgeführt werden und mit ihnen interagieren. Dies entspricht einem Mischbetrieb aus realen und emulierten Komponenten, der als Vorabtest einer geplanten Systemerweiterung wichtige Daten über die zukünftige Systemleistung bieten kann – ohne dabei eine Simulation oder Emulation des bereits im Betrieb befindlichen Anlagenteile zu erfordern (s. Abb. 15.7). Dieses Vorgehen ist somit eine Kombination der Möglichkeiten (1) und (3) aus Abb. 15.3.

Teil III

Der neue Logistik-Lebenszyklus

Kapitel 16

Der Lebenszyklus heutiger Materialf lusssysteme – eine Übersicht Carolin Haußner, Jürgen Elger und Florian Kuzmany

Aktuelle Ansätze für dezentrale Automatisierungssysteme werden insbesondere wegen der damit verbundenen, gewünschten Verbesserungen und Vorteile während des Betriebs untersucht. Die Nutzung dieser Systeme hat allerdings weitreichende Folgen – nicht nur für den Betrieb sondern insbesondere für das Engineering, in welchem zunächst die Grundlagen für die neue Technologie gelegt und sie anschließend projektspezifisch angewandt werden müssen. Die Einführung solcher Systeme ist damit erst dann tragbar, wenn die Auswirkungen auf den gesamten Lebenszyklus von Automatisierungslösungen auch deutlich werden. Das Problem hierbei ist, dass dies vor einer breiten Praxisanwendung geschehen muss. Ein Vergleich auf Basis monetärer Zahlen ist deshalb schwer möglich. In diesem Kapitel soll zunächst allgemein der Lebenszyklus und die heute aufwändigen Tätigkeiten im Rahmen der Erstellung von zentralen Automatisierungssystemen dargestellt werden. Im Anschluss wird ein dezentrales Automatisierungskonzept vorgestellt, welches einen konsequenten modularen Ansatz verwendet. Schon an diesem Beispiel werden erste Auswirkungen des Systems auf die zu leistenden Engineering-Tätigkeiten deutlich. In den nachfolgenden Kapiteln (Kap. 17–22) werden die Auswirkungen eines dezentralen Automatisierungssystems auf den Lebenszyklus detailliert beschrieben. Für eine mögliche, qualitative Bewertung der Vor- und Nachteile eines Automatisierungskonzepts bezogen auf den gesamten Lebenszyklus wird schließlich eine von Siemens entwickelte Methodik eingeführt und mögliche Ergebnisse dargestellt. Eine Analyse, welche mit dieser Methodik durchgeführt wurde, findet sich in Kap. 23.

C. Haußner () Corporate Technology CT SE 5 Günther-Scharowsky-Str. 1, 91058 Erlangen, Deutschland e-mail: [email protected] W. Günthner, M. ten Hompel (Hrsg.), Internet der Dinge in der Intralogistik, DOI 10.1007/978-3-642-04896-8_16, © Springer-Verlag Berlin Heidelberg 2010

167

168

C. Haußner et al.

16.1 Lebenszyklus eines Materialflusssystems Bei der Entstehung einer konventionellen, zentral gesteuerten Materialflussanlage fallen vielfältige Tätigkeiten an, welche ganz unterschiedliche Anforderungen an Technik und Personal von Anlagenbauern stellen (s. Abb. 16.1). Expertenbefragungen zeigen, dass ein erheblicher Anteil dieses Aufwands mit einer Veränderung des Materialflusskonzepts und damit verbundenen Änderungen in der Handhabung der Technologie beeinflusst werden könnten (Günthner et al. 2008). Die folgende Betrachtung des Lebenszyklus eines herkömmlichen, zentral gesteuerten Materialflusssystems gibt Aufschluss darüber, welche Prozesse und Tätigkeiten grundsätzlich durchgeführt werden und damit auch welche Optimierungsmöglichkeiten bei der Nutzung eines dezentralen Steuerungskonzepts existieren.

16.1.1  Planungsphase In der Planungsphase erfasst der Systemanbieter zusammen mit dem Kunden möglichst genau die Anforderungen an das spätere System. Im Rahmen einer Studie wird nun die prinzipielle Machbarkeit geprüft. Dies umfasst bei größeren Projekten auch die Erstellung eines oder mehrerer Simulationsmodelle, um verschiedene Lösungsalternativen zu überprüfen. Dabei werden jedoch noch keine komplexen Materialflussstrategien implementiert, sondern lediglich einfache Abläufe hinterlegt. Nach der Entscheidung für ein Lösungskonzept kann eine erste Kostenrechnung die Grundlage für das spätere Angebot liefern. Dazu wird eine grobe Projektierung der Steuerungstechnik und IT durchgeführt und entschieden, welcher Anteil des zu erstellenden Systems zugekauft und welcher selbst erstellt werden kann (Make Or Buy – Entscheidung). Sind Kosten für den Eigenanteil abgeschätzt, werden bereits die Zulieferer in die Gespräche mit einbezogen, welche ebenfalls eine Kostenabschätzung abgeben. Bei den tatsächlichen Erstellungskosten der Anlage und der Kostenrechnung selbst spielt es eine große Rolle, ob bereits Projekte durchgeführt wurden, welche eine starke Ähnlichkeit zu der nun zu realisierenden Anlage haben. In der Regel können auf diese Weise ca. 60–70% der geplanten Umfänge beibehalten bzw. wiederverwendet werden. Dies sind z. B. Softwarekomponenten, Schaltschrankkonzepte, Steuerungskonzepte oder Dokumentation. Ein hoher Wiederverwendungsanteil senkt dabei auch im Fall der mechanischen Komponenten die Erstellungskosten und erhöht die Sicherheit der Kostenabschätzung. Alle Ergebnisse dieser Phase fließen in die Angebotsunterlagen ein, welche dann dem Kunden vorgelegt werden. Besonders aufwändige Arbeiten sind in der Planungsphase die Layoutplanung, die Koordinierung der Zulieferer und bei Großprojekten die Simulationsstudie.

Planung Realisierung

• Anforderungserfassung / Lastenheft • Studie • Simulation • Angebot

• • • • •

Detailstudie Feinplanung / Feinpflichtenheft Konfigurierung Programmierung Inhouse-Test

• • • • • • •

Sichtkontrolle Offline-Abnahme Kopplungstest / Integration Online – Funktionstest Schulung Key-User Probebetrieb Online-Leistungsabnahme

169

• Layout • Interne Kalkulation • Koordinierung Zulieferer und Bau • Übergabe an die ausführenden Kräfte • Dokumentation • Fertigung / Montage • Einzelinbetriebnahme

Betrieb

Gesamtabnahme

Inbetriebnahme / Hochlauf

Einzelabnahme

Auftrag

Angebotsfreigabe

16   Der Lebenszyklus heutiger Materialflusssysteme – eine Übersicht

• Operation • Wartung

Abb. 16.1   Lebenszyklus eines Materialflusssystems

16.1.2  Realisierungsphase Hat der Kunde den Auftrag erteilt, kann in die Realisierungsphase eingetreten werden. Die in der Planungsphase erstellte Studie wird dabei weiter detailliert. Bei größeren Projekten liegt wie beschrieben bereits ein erstes Simulationsmodell vor. Dieses Modell kann nun um auftragsspezifische Materialflussstrategien erweitert

170

C. Haußner et al.

werden. Dies können Betriebstrategien von Regalbediengeräten oder auch Algorithmen für die Auftragsdisposition oder Wegplanung sein. Hier kann meist auf einen Baukasten zurück gegriffen werden, welcher bereits Simulationsmodelle für einzelne Materialflusselemente enthält. Damit lassen sich bereits einfache Simulationen erstellen, die beispielsweise das Überprüfen von Fördertechnik-Durchsätzen an bestimmten Punkten in der Anlage ermöglichen. Soll darüber hinaus auch eine Simulation von (kundenspezifischen und layoutbezogenen) Business-Strategien erfolgen, z. B. durch die Berücksichtigung von Prioritäten, Reihenfolgen oder anderen Abhängigkeiten, müssen sowohl die projektspezifischen Simulationsbausteine als auch die Business-Strategien neu erstellt bzw. angepasst werden. Ein so erweitertes Simulationsmodell liefert verfeinerte Aussagen über die zu erwartende Durchsatzleistung des zu erstellenden Systems. In kleineren Projekten wird entweder ganz auf die Simulation verzichtet oder nur ein sehr grobes Simulationsmodell erstellt. Weiterhin wird das Layout im Rahmen eines Feinlayoutplans genauer ausgearbeitet. Dazu wird die konkrete Ausprägung der eingesetzten Fördertechnik bestimmt und die Anzahl der Fördertechnikabschnitte auf den Wegstrecken festgelegt. Für diese Aufgabe verfügen die Hersteller meist über einen Mechanikbaukasten, welcher gängige Fördertechnikmodule enthält, dessen Schnittstellen jedoch anders gezogen sind, als die der Softwarebaukästen für Steuerung und Simulation des Systems. Die so ausgewählten Fördertechnikmodule werden nun auf dem Layoutplan platziert und Raumeinteilung bzw. Zugänglichkeit abgestimmt. Aus dem Layout lassen sich weitere Festlegungen ableiten. Beispiele hierfür sind • die Festlegung des Steuerungskonzepts d. h. der Punkte an welchen die Transporteinheiten identifiziert werden müssen. • die Bestimmung von Bereichen, welche in einem Notauskreis zusammen geschaltet werden müssen. Zusätzlich wird auch die Systemarchitektur aus der Planungsphase weiter detailliert. Das Steuerungskonzept bestimmt, welche Steuerungsaufgaben auf welcher Ebene der klassischen Automatisierungspyramide (VDMA 15276) welche Aufgaben implementiert werden sollen. Außerdem wird die Systemhardware (Leitrechner, Materialflussrechner, Automatisierungsgeräte) festgelegt und Datensicherheitskonzepte bzw. Notstrategien für den Ausfall dieser Komponenten entwickelt. Es werden die Systemschnittstellen definiert. Eine klare Schnittstellendefinition erleichtert besonders die spätere Zusammenarbeit mit den Zulieferern und die Koordination der Gewerke bei der Erstellung des Systems. Vorteile ergeben sich aber darüberhinaus auch in allen weiteren Lebenszyklusphasen. Die vorgesehenen Abläufe des Systems werden in Form von Ablauf- und Arbeitsplatzbeschreibungen festgehalten. Ebenso wie bei der Simulationserstellung werden auch bei der Steuerungsprogrammierung in der Regel vorgefertigte Bausteine verwendet. Auch in diesem Fall sind meist umfangreiche kundenspezifische Änderungen und Anpassungen durchzuführen, welche einen erheblichen Arbeitsaufwand bedeuten. Die Bausteine aus einem evtl. vorhandenen Simulationsmodell

16   Der Lebenszyklus heutiger Materialflusssysteme – eine Übersicht

171

können dabei jedoch nicht direkt wieder verwendet werden, da diese im Allgemeinen eine andere Ablaufumgebung und Logik besitzen als das tatsächlich eingesetzte System. Die Ebenen der Automatisierungspyramide sind dort ebenfalls nicht abgebildet, beispielsweise wird die Aktorik und Sensorik-Ebene in diesem Rahmen nicht mitsimuliert. Zusätzlich benötigt ein Materialflusssystem eine Visualisierungsumgebung, welche dem Betreiber sowohl die Überwachung aktueller Systemzustände als auch den Eingriff in den aktuellen Betrieb der Anlage ermöglichen muss. Diese Visualisierungsumgebung wird ebenfalls im Rahmen der Realisierungsphase erstellt. Die Steuerungsprogramme auf Materialflussrechner- und SPS-Ebene werden einzeln und im Gesamtzusammenspiel bereits beim Softwareersteller getestet und um Fehler bereinigt, so dass beim späteren Einspielen der Software auf der Baustelle möglichst wenige Nacharbeiten durchzuführen sind. Während diese Programme noch erstellt und getestet werden, kann mit dem Aufbau der Anlage beim Kunden begonnen werden. Im Anschluss an die Errichtung der Mechanik (z. B. Förderer) erfolgt der Aufbau der Elektrik (z. B. Motoren, Sensoren, Umrichter) und der Steuerungstechnik einschließlich Verkabelung. Der Aufbau der physischen Anlagenkomponenten wird dabei gewerkeweise durchgeführt. Schließlich werden die einzelnen Anlagenteile im Rahmen einer ersten Inbetriebnahme in Bewegung versetzt und auf korrekte Funktionalität überprüft. Diese Einzelinbetriebnahme nimmt den größten Teil der Arbeitsumfänge in der Realisierungsphase ein.

16.1.3  Inbetriebnahme/Hochlaufphase Die Inbetriebnahme/Hochlaufphase ist gekennzeichnet von mehreren aufeinander aufbauenden Test- und Abnahmevorgängen, die letzte Fehler im Aufbau, der Steuerungsprogrammierung und beim späteren Betrieb der Anlage aufzeigen sollen. Treten hier noch Fehler auf, wird umgehend nachgebessert. Dies führt dazu, dass speziell in dieser Phase, je nach Anlagengröße, eine mehr oder weniger umfangreiche Expertenmannschaft vorgehalten werden muss. Vor Beginn dieser Phase wird, wie bereits beschrieben, das Materialflusssystem mechanisch aufgebaut, die Verkabelung durchgeführt und die Steuerungsprogramme eingespielt. Im Rahmen einer Sichtkontrolle wird die Vollständigkeit dieser Arbeiten bzgl. der handwerklichen Qualität und der statischen Eigenschaften der Fördertechnik geprüft. Eine Offline-Abnahme zeigt die Funktionsfähigkeit einzelner Anlagenteile ohne Anbindung des Materialflussrechners. Hier werden Handbetrieb- und Halbautomatikfunktionen getestet und die Einzelleistung dieser Anlagenteile geprüft. Der daran anschließende Kopplungstest ist besonders wichtig, um den fehlerfreien Nachrichtenaustausch zu überprüfen. Dies betrifft z. B. den Auf- und Abbau von Kommunikationsverbindungen bzw. das Verhalten bei doppelten oder fehlenden Telegrammen.

172

C. Haußner et al.

Der Online-Funktionstest kommt der Betriebsphase der Anlage schon recht nahe, indem hier detaillierte Testszenarien gefahren werden, welche in der Realität auch zu erwarten sind. Treten hier noch Fehler auf, welche sich auf die Koordination und Kooperation von Anlagenteilen – beispielsweise auf die Strategie zur Steuerung mehrerer Verschiebewägen auf derselben Schiene – beziehen, so können Änderungen sehr aufwendig werden. Hier kann es vorkommen, dass die Steuerungsarchitektur in allen Abhängigkeiten und über alle Ebenen der Automatisierungspyramide angepasst werden muss. Dies bedeutet Eingriffe sowohl in die Programmierung des Materialflussrechners als auch in die der Speicherprogrammierbaren Steuerungen. Bereits während diese letzten Tests durchlaufen werden, kann mit der Schulung der späteren Bediener der Anlage begonnen werden. Zu diesem Zeitpunkt findet meist auch der Gefahrenübergang vom Anlagenhersteller auf den Betreiber statt. Der Betreiber der Anlage übernimmt damit die Verantwortung für eventuelle Schäden, welche durch die Bediener verursacht werden. Im Rahmen der Schulung erlernen die Bediener den Umgang mit den MenschMaschine-Schnittstellen und die Arbeitsabläufe an ihren Arbeitsplätzen. Besonderes Augenmerk gilt hierbei der Bedienung der Visualisierungsumgebung zur Erkennung von Fehlfunktionen und zur geplanten Veränderung von Anlagenstrategien für bestimmte Szenarien. Dies ist beispielsweise dann relevant, wenn zu einer bestimmten Tageszeit eine hohe Auslastung von Streckenabschnitten zu erwarten ist und daher der Materialfluss manuell auf weitere Strecken verteilt werden muss. Dies ist beispielsweise in einem Versandzentrum für Lebensmittel der Fall, wenn die frische Ware morgens angeliefert, während des Tages kommissioniert und abends versandt wird. Den letzten Schritt vor der Gesamtabnahme stellt eine Online-Leistungsabnahme dar. Im Gegensatz zu allen vorherigen Tests wird die gesamte Anlage dabei an ihre in der Ausschreibung geforderte Leistungsgrenze gebracht. Es wird anhand von vordefinierten Szenarien gezeigt, dass das System die dort definierten Durchsätze und Antwortzeiten erbringen kann und über einen definierten Zeitraum keine Fehler auftreten die den Betrieb deutlich behindern. Die hohe Komplexität dieser Aufgabe besteht darin, hunderte Materialflusselemente und ihr Zusammenspiel zu koordinieren. Auch hier gilt: Je später eine Fehlfunktion entdeckt wird, desto aufwändiger ist ihre Behebung. Daher sollte in den früheren Phasen so gearbeitet werden, dass hier keine bzw. nur noch geringe Fehler auftreten können. Dies ist allerdings normalerweise noch nicht der Fall, was sich daran zeigt, dass Experten bei Befragungen die Online-Leistungsabnahme als die arbeitsaufwändigste Tätigkeit in der Inbetriebnahme/Hochlaufphase beschreiben. Üblicherweise schließt sich an die beschriebenen Leistungstest ein Probebetreib an, der mehrere Wochen dauert und in welchem die Anlage neben dem Durchsatz auch eine festgelegte Verfügbarkeit erreichen muss. Aufgrund des hohen Integrationsrisikos und der Vielzahl der durchzuführenden Tests stellt die Inbetriebnahme/Hochlaufphase für den Anlagenersteller eine der aufwändigsten Phasen im gesamten Lebenszyklus eines Materialflusssystems dar.

16   Der Lebenszyklus heutiger Materialflusssysteme – eine Übersicht

173

16.1.4  Betrieb In der Betriebsphase muss der Anlagenersteller im Rahmen seiner Gewährleistungspflicht noch die von ihm zu verantwortenden Mängel beseitigen, darüber hinaus wechselt er, wenn vom Kunden gewünscht und bestellt, in die Rolle des Service-Dienstleisters. Ein Service-Vertrag legt dabei den Umfang dieser Dienstleistung fest. Der Betreiber kann zwar die Betriebszustände der Anlage überwachen, Fehlfunktionen feststellen und kleinere Störungen selbst beheben. Ist er jedoch dazu nicht in der Lage ist er auf die schnelle Hilfe des Anlagenerstellers angewiesen. In der Regel wird dabei in einem dreistufigen System gearbeitet, das sich nach der Problemkomplexität richtet. Die erste Anlaufstelle für relativ einfache Problemstellungen stellt eine Hotline dar, welche vom Anlagenersteller zur Verfügung gestellt wird. Ist das Problem in dieser Stufe noch nicht zu lösen, so wird in einem zweiten Schritt z. B. anhand von Logdateien eine genauere Analyse des Fehlerzustands vorgenommen und eventuell eine neue Software zur Fehlerbehebung eingespielt. Dies kann eventuell über eine Fernwartungsverbindung geschehen oder, falls dies nicht möglich ist, einen Besuch des Wartungspersonals vor Ort erfordern. Die dritte Stufe des Wartungskonzeptes ist komplexen Problemstellungen vorbehalten. Hier müssen sich die Systementwickler selbst mit der Fehlerbehebung (vor Ort oder über Fernwartung) auseinandersetzen. Die Kosten für diese Serviceleistungen hängen daher stark von einer klaren Strukturierung der Systemarchitektur ab, welche es ermöglichen sollte, das Problem schnell und strukturiert eingrenzen und identifizieren zu können. Außerdem spielt die Fernwartbarkeit des Systems eine zentrale Rolle: Je besser ein Fehler bereits via Ferndiagnose eingegrenzt werden kann, desto gezielter und damit kürzer gestaltet sich die Suche des Personals vor Ort. Eine weitere Aufgabe des Anlagenerstellers stellt die Wartung des Systems dar. Zwar sollten in vorher festgelegten Wartungsintervallen mechanische und steuerungstechnische Komponenten getauscht bzw. überprüft werden, um eine hohe Anlagenverfügbarkeit zu garantieren, in der Realität wird die Anlage jedoch häufig bis zum Ausfall betrieben. Je nach Wartungsarbeit müssen dann Teile oder die komplette Anlage still gelegt werden. Dies wird meist nur in betriebsfreien Zeiten, d. h. nachts oder an Wochenenden und Feiertagen möglich sein und erhöht daher zusätzlich die Kosten für das eingesetzte Wartungspersonal.

16.1.5  Erweiterung/Modernisierung Nach einigen Jahren wird in vielen Fällen eine Erweiterung oder Modernisierung einer bestehenden Anlage notwendig. Dies wird z. B. durch erhöhte Anforderungen an Durchsatz, Lagerkapazität oder ein verändertes Produktspektrum ausgelöst. Prinzipiell wird in einem solchem Fall der Lebenszyklus der Anlage, aus Sicht des

174

C. Haußner et al. Erweiterung / Modernisierung

Planung

Realisierung

Inbetriebnahme / Hochlauf

Betrieb

Entsorgung

Abb. 16.2   Die Erweiterung/Modernisierung im Lebenszyklus eines Materialflusssystems

Anlagenerstellers, nochmals durchlaufen. Jedoch in diesem Fall speziell für den neu zu erstellenden bzw. zu modernisierenden Teil der Anlage (s. Abb. 16.2). Der maßgebliche Unterschied bei den nun ablaufenden Tätigkeiten ist hier die Integration der neuen Gewerke in bereits bestehende Anlagenteile. Dies ist sowohl mechanisch als auch softwaretechnisch zu realisieren. Speziell die Anpassung einer bestehenden Materialflussrechnersoftware stellt dabei einen hohen Aufwand dar, da in alle steuerungslogischen Ebenen eingegriffen werden muss. Je nach Tätigkeit ist dazu in vielen Fällen eine komplette Stilllegung der Materialflussanlage notwendig, was wiederum zu erheblichen Kosten führen kann. Den größten Aufwand stellt in dieser Phase die Inbetriebnahme dar, während an zweiter Stelle bereits die Umprogrammierung des Materialflussrechners zu sehen ist (Günthner et al. 2008). Es bietet sich also an, ein Materialflusssystem bereits bei der ersten Erstellung auf diesen Fall vorzubereiten, um diese Aufwände so weit wie möglich zu reduzieren.

16.2 Dezentrale Automatisierungssysteme – eine Herleitung Die im vorherigen Kapitel beschriebenen Tätigkeiten innerhalb der einzelnen Lebenszyklus-Phasen werden sich bei der Handhabung und Entwicklung dezentraler Systeme entscheidend ändern. Um die Auswirkungen eines dezentralen Automatisierungssystems auf den Lebenszyklus einer Anlage besser verstehen zu können, soll zunächst ein Fallbeispiel eines dezentralen, modularen Systems dargestellt werden. Dezentrale Automatisierungssysteme sind nicht per se von Vorteil, sondern vielmehr als Mittel zum Zweck anzusehen, um bestimmte Nutzen und Ziele zu erreichen. Beispiele im Umfeld der Intralogistik, welche auch im Rahmen des Forschungsprojekts Internet der Dinge betrachtet wurden, sind hierfür: • Erhöhung der Flexibilität und bessere Anpassbarkeit der Automatisierungslösungen • Reduzierung des Aufwands für Engineering und Inbetriebnahme • Bessere Handhabbarkeit der Komplexität von Automatisierungslösungen Zielsetzung im Forschungsprojekt „Internet der Dinge“ war die Untersuchung bzw. Entwicklung von wandelbaren Echtzeit-Logistiksystemen. Ein mögliches Anwendungsbeispiel aus der Praxis ist das zunehmende 3rd-Party Geschäft im Intralogistikbereich, bei dem Logistikunternehmen Lager- und Versand-Dienstleistungen für

16   Der Lebenszyklus heutiger Materialflusssysteme – eine Übersicht

175

einen oder mehrere Kunden erbringen. Durch die häufig sehr kurzen Vertragslaufzeiten ergibt sich die Notwendigkeit, eine solche Anlage schnell an sich ändernde Bedürfnisse anzupassen. Neue Kunden können z. B. veränderte Geschäftsprozesse und damit veränderte Arbeitsabläufe, andere Produktpaletten und damit andere Anforderungen an Lagerung und Transport fordern. Solche Änderungen würden häufig einen Umbau der Anlagen erfordern, was aus Aufwandsgründen aber nur eingeschränkt durchgeführt wird. Damit wird ein Teil des möglichen Nutzenpotentials nicht gehoben. Durch Schaffung einer höheren Flexibilität im Sinne einer (möglicherweise sogar im Wortsinne) „mobilen“ und wandelbaren Anlage auf einfache und kostengünstige Weise, könnten 3rd-Party-Logistikanbieter einen deutlichen Kostenvorteil erreichen. Eine Lösung für die Umsetzung der eingangs genannten Nutzen und Ziele erwartet man sich durch eine konsequente Modularisierung entsprechender Automatisierungssysteme. Dabei soll ein Zusammenstellen der Anlage aus Modulen ermöglicht werden, welche • projektspezifisch einfach zu handhaben sind, • geringe Abhängigkeit untereinander aufweisen, sowie • die Komplexität vor dem Anwender verstecken. Bisherige Ansätze von Anlagenlieferanten zur Modulbildung zielten dabei vor allem auf eine horizontale Modularisierung, d. h. innerhalb der beteiligten Gewerke wie z. B. Mechanik, Elektrik, Automatisierungstechnik ab. Jedes Gewerk schafft sich hier seine „optimalen“ Module und Standards. Problematisch hierbei ist, dass die Integration zwischen den Gewerken durch einen solchen horizontalen Ansatz nicht adressiert wird und deshalb projektspezifisch durchgeführt werden muss, was erfahrungsgemäß zu erheblichem Zusatzaufwand speziell während der Inbetriebnahmephase führt. Speziell für die Reduzierung der Engineering- und Inbetriebnahmeaufwände erscheint daher die Nutzung von vorintegrierten, funktionalen Modulen notwendig. Diese Komponenten beinhalten sowohl einen mechanischen als auch elektrischen und steuerungstechnischen Anteil; die Schnittstellen zwischen den Gewerken sind abgestimmt. Damit die Module möglichst unabhängig voneinander und (beliebig) kombinierbar sind, werden in diese Überlegungen auch Teile der bisher zentral vorhandenen Leitsystemebene einbezogen. Dies führt zur „Zerschneidung“ der ehemals zentral vorhandenen Funktionalität und somit zu einer Dezentralisierung dieser Systeme, wie dies in (Elger 2007) gezeigt wurde (s. a. Abb. 16.3). Die Automatisierungspyramide im klassischen Sinn wird damit weitgehend aufgelöst. Die Gesamtfunktionalität wird in unabhängige Teilfunktionalitäten zerlegt, welche sich dann zur Laufzeit wieder integrieren. Dieser Verlust zentral strukturierter Funktionen bedeutet, dass bisher von einer Stelle aus durchgeführte Entscheidungen nun dezentral durch „Abstimmung“ unter den Modulen getroffen werden müssen. Hierfür werden die Module mit Mechanismen zur Kommunikation untereinander, zur gegenseitigen Identifikation und zur Abstimmung untereinander versehen. Die verteilten, intelligenten Einheiten treffen auf Basis dieser Mechanismen über Verhaltensregeln Entscheidungen wie das Finden eines (kürzesten) Transportweges

Abb. 16.3   Modularisierung und Dezentralisierung

176 C. Haußner et al.

16   Der Lebenszyklus heutiger Materialflusssysteme – eine Übersicht

177

von A nach B oder der Zuweisung einer logistischen Aufgabe auf ein Element, welches eine entsprechende Funktion anbietet. Im Forschungsprojekt Internet der Dinge (vgl. Internet der Dinge 2006) wurde die verteilte Intelligenz z. B. durch ein Multi-Agenten-System umgesetzt. Es sind allerdings auch andere softwaretechnische Umsetzungen denkbar. Für eine effiziente und kostengünstige Nutzung der mechatronischen Module im Rahmen der Planungs- und Realisierungsphase wird ein mechatronischer ModulBaukasten projektunabhängig im Vorfeld definiert und entwickelt (im wesentlichen als Einmalaufwand, plus Pflegeaufwand). Dieser unterstützt die in der Realisierung übliche Top-Down-Vorgehensweise durch die Bereitstellung von Modulbeschreibungen, mit denen das anfangs noch grobe Anlagenlayout sukzessive verfeinert werden kann. In der Inbetriebnahmephase führen die Nutzung vorintegrierter Module, die Kapselung der Funktionalitäten sowie die Fähigkeiten der Identifikation und Abstimmung der Module untereinander dazu, dass die Module im wesentlich automatisierungstechnisch per „Plug&Play“ zu einer Gesamtanlage zusammengefügt werden können. Insbesondere wird durch die Nutzung der vorintegrierten Module eine funktionell orientierte Installation der Anlage unterstützt (z. B. Errichtung nach Funktionseinheiten wie einem Sortierkreis). Das hier beschriebene dezentrale Automatisierungssystem wurde mit einer eigens am Fachzentrum für „Systems Engineering“ von Siemens Corporate Technology entwickelten Methodik auf seine Vor- und Nachteile über den Lebenszyklus einer Automatisierungslösung hinweg untersucht. Die detaillierte Analyse findet sich in Kap. 18. Im Folgenden soll kurz die angewandte Referenz-Modell Methodik erläutert werden, detailliertere Beschreibungen finden sich in (Wagner u. Elger 2008).

16.3 Referenzmodell-Methode Wie bereits erwähnt sind dezentrale Automatisierungskonzepte nicht per se von Vorteil sondern sollen gezielt bestimmte Nutzen erbringen. Diese erhofften Auswirkungen beziehen sich häufig auf die Betriebsphase. Hierfür lässt sich der Nutzen eines bestimmten Automatisierungskonzeptes relativ gut nachweisen, z. B. durch Simulation oder Prototypen, verbunden mit der Auswertung von Key Performance Indicators, wie Durchsatz, (gleichmäßige) Verteilung der Lasten oder Transportdauer. Für die Planungs-, Realisierungs- und Inbetriebnahmephase jedoch gibt es kaum Vorgehensweisen, wie der Mehrwert eines Automatisierungskonzepts festgestellt werden kann. Gerade bei einer Neuentwicklung solcher Konzepte ist es jedoch wichtig, vor dem tatsächlichen praktischen Einsatz eine Untersuchung von Nutzen und Risiken durchzuführen, u. a. für eine erhöhte Kundenakzeptanz und eigene Planungssicherheit. Zwar wäre eine aufwands- und kostenbasierte Bewertung wünschenswert, mangels durchgeführter Projekte und verlässlicher, vorliegender

178

C. Haußner et al.

Zahlen ist dies aber nur schwer möglich. Die Aussagen können aber auf Basis qualitativer, vergleichender Analysen gewonnen werden. Jedoch sind hierfür bislang kaum systematische Ansätze bekannt. Im Rahmen der Forschungsprojekte (PABADIS’PROMISE 2009) und Internet der Dinge (s. Internet der Dinge 2006) wurde eine Evaluierungsstrategie entwickelt, um diese Lücke zu schließen. Die Grundidee der Methode beruht auf der Schaffung von Referenzmodellen für Prozesse und Tätigkeiten entlang des Lebenszyklus einer Automatisierungslösung auf Basis der jeweiligen Automatisierungskonzepte. Der Schwerpunkt liegt dabei vor allem auf den Phasen des Engineering und der Inbetriebnahme von Anlagen. Die Modellbildung erfolgt durch Unterteilung des Lebenszyklus einer Anlage in seine Phasen, durch die Zerlegung der Prozesse (z. B. Layoutplanung) innerhalb der einzelnen Phasen in einzelne Tätigkeiten und durch Identifikation ihrer Zusammenhänge mit der Automatisierungstechnik. Die Vergleichbarkeit verschiedener Modelle (entsprechend zu den unterschiedlichen Automatisierungskonzepten) wird durch die Nutzung eines Meta-Modells gewährleistet, welches die Strukturierung sowie die benötigten Informationen und Features definiert und festlegt (s. Abb. 16.4). Die Tätigkeit (Activity) selbst steht dabei im Mittelpunkt der Betrachtung und besitzt Attribute wie benötigte Kenntnisse (Skills), Vor- und Nachbedingungen (pre/postconditions) oder verwendete Tools. Darüber hinaus wird die Tätigkeit einer Phase und diese einem Prozess zugeordnet. Jede Tätigkeit kann Input bestehend aus Artefakten erhalten. Artefakte bezeichnen in diesem Zusammenhang End- oder Zwischenprodukte wie Spezifikationen, Pläne oder auch Komponenten wie Motoren oder Mechanikbauteile. Diese können wiederum im Rahmen vorhergehender Prozesse entstanden sein oder z. B. zugekauft werden. Ergebnisse der Tätigkeit Actor

owns

Process

e.g. System Integrator

part of

Phase outputs part of

Type is input for

Role (technical discipine)

executed by

Activity

Description

Skills

Effects towards automation has impact on the design of a

Type Skills Tools

Subsystem

Location Effort

Abb. 16.4   Metamodell

Formal Template Reuse

Goal Pre- / postconditions

Description

Artifact

16   Der Lebenszyklus heutiger Materialflusssysteme – eine Übersicht

179

Tab. 16.1   Beispiel Abschnitt Fragenkatalogs Characteristic Functionality (acc. ISO 9126) Ref. Sub- Criteria charact. Suitability Customer requirements

Interoperability

Question

Details

Which customer require- • Typical customer requirements today  aims of system ments are relevant for • Control architecture specific the system integrator requirements in order to design and realize the plant? Can these requirements be met by the current systems? • E.g. highly redundant (and costly) Appropriateness Are the requirements considered in a suitable automationsystem in case of way? non-time-critical processes is not appropriate • E.g. required information from Content-related Which dependencies during engineering-pro- mechanical engineering, electrical dependencies engineering cess do exist between between automation engineering • E.g. mechanical plant layout activities • E.g. processes to be controlled/ and other disciplines? monitored, list of process signals • E.g. Sensors/variables to measure the process • E.g. Actuators/variables to influence the process • E.g. integrated information models View Integration How is seamless connection of technical like multi-discipline information disciplines supported? objects

(Output) sind wiederum Artefakte, welche als Input für nachfolgende Prozesse dienen können. Dieses Meta-Modell diente als Referenzbasis und Grundlage für die Erststellung von Templates zur strukturierten Erfassung der Tätigkeiten im Rahmen der Evaluierung. Die Evaluierung erfolgt durch eine vergleichende Bewertung auf Basis eines Kriterienkatalogs. Zentrale Herausforderungen und Hebel im Engineering von Anlagen dienen hierfür als Grundlage, wie z. B. Möglichkeiten des gewerkeübergreifenden Arbeitens, der Wiederverwendung oder auch die verbesserte Handhabbarkeit der Technologie. Zudem wurde die Norm ISO/IEC 9126, welche zur Sicherstellung der Software-Qualität dient, untersucht und die dort enthaltenen Qualitäts-Charakteristiken in einer Analogiebetrachtung mit Blick auf das Anlagengeschäft übertragen, angepasst und ergänzt. Der somit entstandene Kriterienkatalog dient als weitere Grundlage für die Evaluierung. Ein Abschnitt des Fragekatalogs wird in Tab. 16.1 dargestellt. Das Vorgehen für die Evaluierung ist das Folgende: Für einen Vergleich der Auswirkungen zweier Automatisierungskonzepte auf den Lebenszyklus einer Automatisierungslösung ist zunächst die Definition der Zieldomäne(n) und die damit verbundenen speziellen Anforderungen wichtig. Zudem ist es wesentlich, sich über

180

C. Haußner et al.

die Gesamtzielsetzung bewusst zu werden, dies können z. B. Anforderungen wie die Reduzierung von Aufwänden bei der Inbetriebnahme beinhalten. Darauf aufbauend soll zunächst beantwortet werden können, wie die jeweiligen Automatisierungskonzepte diese Aufgabenstellungen adressieren. Nun erfolgt durch eine template-basierte Erfassung der Prozesse die Modellierung der Referenzmodelle. Diese werden mit dem Kriterienkatalog abgeglichen, um zu überprüfen, ob auf Basis der bisher erfassten Informationen bereits alle Fragen beantwortet werden können. Ist dies nicht der Fall, muss das entstandene Modell weiter verfeinert werden. Zum Schluss werden die Ergebnisse der Kriterienkataloge beider Systeme analysiert und im Hinblick auf Vor- und Nachteile bewertet.

16.4 Zusammenfassung Dezentrale Automatisierungskonzepte sind nicht per se von Vorteil sondern werden entwickelt und analysiert, um erwartete Vorteile z. B. im Hinblick auf Flexibilität im Betrieb zu heben. Dabei muss allerdings berücksichtigt werden, dass sich damit auch Auswirkungen auf alle weiteren Lebenszyklusphasen ergeben. So müssen im Betrieb hoch flexible Automatisierungssysteme im Engineering handhabbar bleiben. Eine Vereinfachung der Inbetriebnahme durch modulare, vorintegrierte Komponenten, wie im Internet der Dinge angestrebt, bedeutet aber, dass auch ein mechatronischer Entwicklungsprozess einzuführen ist. Die Untersuchung dezentraler/modularer Logistikanlagen im Forschungsprojekt Internet der Dinge hatte deshalb von Anfang an auch die Auswirkungen wandlungsfähiger Anlagen auf die Erstellung des Systems im Fokus. Die in diesem Kapitel aufgeführten heutigen Tätigkeiten für die Erstellung und Nutzung von automatisierten Intralogistikanlagen dienen als Grundlage für eine Untersuchung der zukünftigen Änderungen. Zwar werden die einzelnen, durchzuführende Phasen ähnlich bleiben wie in diesem Kapitel dargestellt, allerdings verändert sich z. B. die Gewichtung einzelner Prozesse sowie die damit verbundenen Tätigkeiten. Detaillierte Ausarbeitungen ebendieser Änderungen finden sich in den folgenden Kapiteln.

Kapitel 17

Die Erstellung eines Baukastens für das Internet der Dinge Clemens Nieke und Martin Henk

Hinter dem Begriff der Vorarbeiten verbergen sich alle Aufwendungen, die vor dem Start des ersten Projektes nach der „Internet der Dinge“ Technologie erbracht werden müssen. Sie lassen sich als die Konzeptentwicklung und das Erstellen der elementaren Bausteine für künftige Projekte umschreiben. Unter dem allgemeinen Blickwinkel des neuen Lifecycles entsprechen sie der Produktentwicklung, wie sie bisher auch für herkömmliche Projekte notwendig war. Damit gehören die Vor­ arbeiten zu den projektunabhängigen Tätigkeiten. Sie werden nur einmal zu Beginn des neuen Lifecycles ausgeführt. Im Vergleich zu herkömmlichen Projekten ver­ lagert das „Internet der Dinge“ Tätigkeiten aus den projektspezifischen Phasen in die Vorarbeiten und verkürzt damit die Realisierungsphase. Diese Eigenschaft zeigt das große Einsparpotential der „Internets der Dinge“ Philosophie. Dem gegenüber steht der erhöhte Initialaufwand, der in dieser Phase des neuen Lifecycles erbracht werden muss. Abbildung 17.1 verdeutlicht die Unterschiede im Lebenszyklus zwischen her­ kömmlichen Projektphasen und den Phasen im Internet der Dinge. Sie beschreibt die Verhältnisse qualitativ aus heutiger Sicht. Die Vorarbeiten enden in der Erstel­ lung eines Baukastens, der Lösungen für immer wiederkehrende intralogistische Funktionalitäten enthält. Die Vorarbeiten werden nur einmal im ersten Projekt er­ bracht, welches nach der „Internet der Dinge“ Technologie realisiert wird. Die An­ passungen und Ergänzungen des Baukastens nach realisierten Projekten führen zu einer verbesserten Grundlage für alle Folgeprojekte. Dieser Verbesserungsprozess wiederholt sich mit den folgenden Projekten immer wieder und verbessert auf diese Art und Weise kontinuierlich über die Jahre hinweg den Baukasten. Durch die stän­ dig wachsende Baukastenqualität werden gegenüber herkömmlichen Projekten eine deutliche Effizienz und Qualitätssicherung in den wiederkehrenden Projektphasen Planung, Realisierung und Hochlauf erzielt.

C. Nieke () Stöcklin Logistik GmbH Untere Industriestrasse 20, 57250 Netphen, Deutschland e-mail: [email protected] W. Günthner, M. ten Hompel (Hrsg.), Internet der Dinge in der Intralogistik, DOI 10.1007/978-3-642-04896-8_17, © Springer-Verlag Berlin Heidelberg 2010

181

182

Projektphasen (herkömmlich)

Projektphasen (Internet der Dinge) Einführungsprojekt

Projektphasen (Internet der Dinge) Folgeprojekte

C. Nieke und M. Henk Projektunabhängige Aufwände

Projektspezifische Aufwände Planung

Vorarbeiten

Standardisierung Testbetrieb / Hochlauf

Realisierung

Planung

Realisierung

Testbetrieb / Hochlauf

Erspamis

Planung

Realisierung

Testbetrieb / Hochlauf

Erspamis

Modulentwicklung

Anpassung Baukasten

Anpassung Baukasten

Erspamis

Erspamis

Abb. 17.1  Projektphasen des neuen Lifecycle

17.1 Baukasten für Entitäten Die Verlagerung der projektspezifischen Aufwände in den Bereich der Vorarbeiten setzt eine Systematik voraus, die es erlaubt, alle Projekte aus universellen Baustei­ nen zu generieren. Diese Bausteine werden in einem Baukastensystem zusammen­ gefasst. Der Baukasten ist das zentrale Werkzeug im Projektverlauf nach dem neuen Lifecycle. Mit den Bausteinen aus dem Baukasten wird quasi das Grundgerippe eines Projektes erstellt. Daher muss bei der Erstellung des Baukastens besonderes Augenmerk auf die Funktionalität der enthaltenen Elemente gelegt werden. Die Kernaufgabe jedes der Elemente des Baukastens ist das Erfüllen einer logischen lo­ gistischen Teilfunktion, die in der späteren Anlage durch eine Entität wahrgenommen wird. Die Elemente bilden die Logik der Anlage ab und repräsentieren sie innerhalb des Baukastens. Aufgrund der universellen Einsetzbarkeit der Baukastenelemente müssen sie eine klar umrissene und möglichst allgemeine Aufgabenlösung bieten. Funktionen solcher Elemente sind beispielsweise Verzweigungen, Zusammenfüh­ rungen, Auf- und Abgabestellen oder einfache Transportstrecken. Weitere Entitäten des Baukastens bieten besondere Dienstleistungen an. Eine solche Entität kann zum Beispiel eine Profilkontrolle, Röntgenstation oder Umreifungsanlage sein. Die Abstraktionsebene der Entitäten des Baukastens ermöglicht eine hohe Pro­ zessflexibilität. Die Kombination und Verkettung der Entitäten bestimmt die Pro­ zesse, die die Anlage ausführen kann. Die Entitäten des Baukastens können also ohne Änderungen in unterschiedlichen Anlagen eingesetzt werden. Eine Anpassung der Entitäten erfolgt lediglich durch Einstellung ihrer Parameter. Die Erweiterung oder umfassende Anpassung der logistischen Funktion einer Entität führt zu einer neuen Entität im Baukasten. Die Entitäten des Baukastens treffen zunächst keine Aussage zu den mechanischen Varianten und Ausführungen. Beispielsweise kann eine Förderstrecke für Paletten als Rollenbahn oder als Kettenförderer ausgeführt sein, ihre logistische Funktion ist in beiden Fällen gleich. Im genannten Beispiel ist der Hochsprachenanteil im Softwareagent identisch. Die Programmsequenzen der maschinennahen Steuerung können im Gegensatz dazu leichte Unterschiede aufweisen. Darüber hinaus können auch abgewandelte mechanische Konstruktio­ nen geänderte Programmsequenzen für die maschinennahe Steuerung einer Entität

17  Die Erstellung eines Baukastens für das Internet der Dinge

183

erfordern. Die logistische Funktion und damit auch die entsprechende Entität des Baukastens werden von diesen Varianten aber nicht berührt. Insbesondere sollten mechatronische Entitäten im „Internet der Dinge“ so gestaltet werden, dass unter­ schiedliche mechanische Ausführungen möglich sind. Die Bildung der Grenzen einer Entität erfolgt einerseits nach den Regeln des „Internets der Dinge“ und ande­ rerseits nach firmenspezifischen Festlegungen. Es bleibt den Herstellen überlassen, ob jedes einzelne fördertechnische Element einer Anlage oder kleine Bereiche eine Entität bilden. Je kleiner die Entitäten geschnitten sind, umso größer ist die Red­ undanz innerhalb einer Anlage und umso stärker bietet sich eine mechatronische Umsetzung an. Schneidet man im Gegensatz dazu die Entitäten größer zu, verliert eine Anlage ihre feingranulare Modulhaftigkeit. Dies hätte schlussendlich zur Fol­ ge, dass die Anlage wieder die Eigenschaften von heutigen zentralen Systemen an­ nimmt. Damit wären dann wieder die gleichen Probleme wie heute vorhanden und der Mehrwert des „Internet der Dinge“ verloren. Die im Baukasten implementierten Entitäten werden durch Softwareagenten vertreten, welche eine gemeinsame Ontologie (s. Kap. 10) besitzen. Dadurch wird die Grundlage für die Kommunikation der Entitäten untereinander geschaffen. Über die eigentlichen materialflusstechnischen Grundfunktionen hinaus besitzen die Softwareagenten weitere standardisierte Funktionen, die je nach Ausprägung des Gesamtsystems benutzt werden können. Dazu gehören beispielsweise statisti­ sche Grundfunktionen oder Visualisierungsinformationen. Zur besseren Übersicht und Handhabbarkeit eines Baukastensystems können die Entitäten in Gruppen und Familien zusammengefasst werden. Die spätere Konzipierung einer Anlage benötigt aufgrund dieses Systems nur noch wenige Schritte, die bereits nach kurzer Zeit belastbare Ergebnisse liefern. Die Grundfunktionalität der Anlage entsteht durch die Verkettung der einzelnen Entitäten zu einer Gesamtanlage. Anschließend werden die Geschäftsprozesse des Kunden auf diesem Grundgerüst abgebildet. Um dieses Ziel zu erreichen, müssen die Geschäftsprozesse in Form eines Workflows umgesetzt werden. Der Workflow wird anschließend in den Softwareagenten der Ladeeinheiten abgebildet, die an­ hand dieser Informationen unter Zuhilfenahme der Anlage ihre Aufgaben abarbei­ ten. Dieses Vorgehen wurde in Kap. 10 ausführlich beschrieben. Grundsätzlich werden die Entitäten im Baukasten durch einen Softwareagenten repräsentiert. Diese Agenten erfüllen primär die materialflusstechnischen Funktio­ nen einer Entität und sind für die Kommunikation im System verantwortlich. Die Entitäten des Baukastens, welche Anlagenteile bzw. Module repräsentieren, verfü­ gen zusätzlich über einen echtzeitfähigen Softwareanteil, der für die maschinenna­ he Steuerung der Entität verantwortlich ist (s. Kap. 11). Innerhalb des Baukastens wird dieser Softwareanteil durch einen Emulator ersetzt, welcher die noch nicht existierende Hardware abbildet. Die Kommunikation zwischen Softwareagent und Hardwaresteuerung wird, wie Abb. 17.2 verdeutlicht, über eine Middleware bzw. Abstraktionsebene abgewickelt. Diese Middleware ermöglicht den schnellen Aus­ tausch des Emulators gegen die Software der realen Maschinensteuerung, indem sie die auszutauschenden Variablen formal beschreibt und zwischen den beiden Soft­ warepartnern vermittelt. Der Austausch des Emulators gegen die echte Steuerung

184

Abb. 17.2  Grundlegender interner Systemaufbau einer Entität

Abb. 17.3  Systemaufbau zum Test der maschinennahen Software

C. Nieke und M. Henk

17  Die Erstellung eines Baukastens für das Internet der Dinge

185

kann somit ohne Einfluss auf den Softwareagenten erfolgen. Ebenso ermöglicht sie die parallele Entwicklung der Maschinensteuerung und des Softwareagenten. Zur Entwicklung einer Entität für den Baukasten gehört neben der mechanischen Konstruktion auch die Programmierung der Maschinensteuerung dieser Entität. Sinn­ vollerweise wird die Maschinensteuerungssoftware anhand einer gebergenauen Si­ mulation verifiziert. Die Simulation ersetzt die reale Anlage und hilft, ein fehlerfreies Programm für die Maschinensteuerung zu erstellen. Außerdem können auf diese Wei­ se schon im Vorfeld wichtige Parameter für die Einstellung einzelner Komponenten der Entität ermittelt werden. Zusätzlich liefert das Duo aus Maschinensteuerung und Simulation exakte Kennzahlen zum Erstellen eines Emulators für die Maschinen­ steuerung. Abbildung 17.3 zeigt, dass auch hier die Middleware den Austausch des Softwarepartners rückwirkungsfrei ermöglicht. Für den Test der Maschinensteuerung wird in diesem Fall der Softwareagent durch einen entsprechenden Emulator ersetzt. Als Ergebnis erhält man Entitäten, deren gesamte Software, einschließlich des mate­ rialflusstechnischen Anteils, im Vorfeld ausführlich getestet wurde.

17.2 Basisinformationen einer Entität Jede Entität, welche als Standardelement in den Baukasten aufgenommen werden soll, muss bestimmte Basisinformationen besitzen, die von der jeweiligen Ausprä­ gung des Entitätstyps abhängig sind. Die Basisinformationen werden sich dahinge­ hend stark unterschieden, ob eine Entität ein Softwaredienst, ein mechatronisches Förderelement oder eine Transporteinheit repräsentiert. Alle Entitäten müssen als Basisinformation die Information haben, welche Funktionen sie im System anbie­ ten können. Weiterhin müssen sie in der Lage sein, ihre spätere Adressierung im Netzwerk zu kennen und diese auch zur Verfügung zu stellen. Neben diesen beiden allgemeingültigen Basisinforationen können die Entitäten noch weiterte Informa­ tion besitzen. Bei mechatronischen Entitäten sind das z. B. die maximale Anzahl an Plätzen für Transporteinheiten. Eng mit dieser Information verbunden sind der zur Laufzeit des Agenten vorhandene Belegungszustand und der Betriebsstatus. Zu­ sätzlich werden die Grunddaten für Visualisierungen und Statistiken in den Basis­ informationen mit integriert sein. Auf eine genauere und weiterführende Beschrei­ bung dieser Information wird an dieser Stelle verzichtet, da dies schon zuvor im grundlegenden Aufbau der Entität erläutert wurde.

17.3 Additive Komponenten eines Baukastens Ein Baukasten bietet zusätzlich die Möglichkeit, für jede Entität weitere optionale Komponente mit einzuarbeiten. Diese können die Herstellung der Entität und den Umgang mit dieser in allen Phasen des neuen Lifecycle erleichtern oder komfor­ tabel gestalten. Es sei an dieser Stelle ausdrücklich darauf hingewiesen, dass diese

186

C. Nieke und M. Henk

Komponenten nicht zum Grundaufbau einer Internet-der-Dinge-Entität gehören. Gleichwohl können über diese additiven Komponenten im gesamten Projektablauf viele zusätzliche positive Effekte zur Steigerung der Effizienz und zur Qualitätssi­ cherung erzielt werden. Aus diesem Grund werden nachfolgend einige dieser Kom­ ponenten vorgestellt. Die Komponentenauflistung in Abb. 17.4 veranschaulicht den Einsatz additiver Komponenten während des neuen Lifecycles und erhebt keinerlei Anspruch auf Vollständigkeit. • Layouterstellung auf Basis logistischer Funktionen: Mit Hilfe des Baukastens werden die einzelnen logistischen Funktionen gra­ phisch aneinandergereiht. Auf diese Weise entsteht die Topologie der geplanten Anlage inklusive der verwendeten Entitäten. Diese Informationen können für eine Generierung des Layouts in einem optionalen Planungstool verwendet wer­ den, das ein dreidimensionales Bild der logistischen Anlage auf Basis abstrakter Förderelemente generiert.

Abb. 17.4  Additive Komponenten

17  Die Erstellung eines Baukastens für das Internet der Dinge

187

• Mengengerüst für Budgetpreisschätzung: Das Mengengerüst einer Entität listet die eingesetzten Bauteile auf. Sind die Prei­ se der einzelnen Bauteile bekannt, können die Herstellungskosten abgeschätzt werden. Diese Kosten können zusätzlich in verschiedene Bereiche gegliedert werden, beispielsweise in fixe Basiskosten und einen variablen Bereich für die optionalen Ausführungen der Entität. Die Summe der Mengengerüste aller in einem Projekt verwendeten Entitäten führt zu einer belastbaren Grundlage für die Abschätzung der Herstellungskosten einer Anlage. • Emulator für Maschinensteuerung: Die Emulatoren ersetzten in jeder Entität die maschinennahe Steuerung im Bau­ kasten. Jede Entität verhält sich in einer Simulation des Materialflusses dadurch genauso wie später in der Anlage. Diskrepanzen zwischen Simulation und Reali­ tät werden dadurch minimiert. • Mechanisches Layout: Jede Entität des Baukastens kann ihre eigene grundlegende mechanische Kons­ truktionszeichnung mitbringen. Projektspezifische Anpassungen und Ergänzu­n­gen können auf diesen Zeichnungen als Grundlage aufbauen. Mit einer projekt­ spezifischen topologischen Information kann eine grundlegende CAD-Konst­ ruktion der gesamten Anlage erzeugt werden. • Elektroschema: Das Elektroschema kann ebenso wie die mechanische Konstruktion ein Bestand­ teil einer Entität des Baukastens sein. Die Summe dieser Schemata bildet das Grundgerüst für das Elektroschema der gesamten Anlage. • Stücklisten: Zu jeder Entität können bereits im Baukasten Basis-Stücklisten hinzugefügt wer­ den. Diese Stücklisten müssen zur Realisierung eines Projektes später nur noch um die spezifischen oder optionalen Bauteillisten ergänzt werden. • Sicherheitsanalyse: Eine Sicherheitsanalyse ist für jede Entität bereits im Vorfeld zwingend erforder­ lich. Die entsprechende Analyse kann nun ebenfalls als Bestandteil der Entität im Baukasten mitgeführt werden. Die einzelnen Analysen jeder Entität bilden in Summe bei einem Projekt die Grundlage für die sicherheitstechnische Einschät­ zung der Gesamtanlage. • Normen und Konformitätserklärungen: Ebenso wie die Sicherheitsanalyse können die für die Entität angewendeten Nor­ men und Vorschriften in dieser Komponente hinterlegt werden. Sie bilden in Sum­ me die Grundlage für eine spätere Konformitätserklärung der gesamten Anlage. • Inbetriebnahme und Installationsanleitungen: Mit dieser ergänzenden Komponente kann die Montage der Entität unterstützt werden. Jede Entität des Baukastens kann mit individuellen Installations- und Anschlussvorschriften ergänzt werden. Darüber hinaus können noch weiterfüh­ rende Anweisungen und Regelwerke hinterlegt werden, wie zum Beispiel die Vorschriften für eine Inbetriebsetzung nach GMP. • Einstell- und Prüfvorschriften: Ebenso wie die Installationsanleitungen können den Entitäten des Baukastens Einstell- und Prüfvorschriften hinzugefügt werden. Diese Dokumente können

188

C. Nieke und M. Henk

zusätzlich Parameterlisten für komplexe Komponenten sowie Prüfbücher be­ inhalten. • Bedienungsanleitungen: Jede Entität des Baukastens ist eine in sich abgeschlossene Einheit. Daher kann als weitere additive Komponente die Bedienungs- und Wartungsanleitung im Baukastensystem hinterlegt werden. Zusammen mit den Stromlaufplänen und dem mechanischen Aufbau stellen sie die Grundlage für die Dokumentation der Entität dar. Diese Entitätsdokumentation ist herstellerspezifisch ausgeführt und ergibt in Summe das Grundgerüst der Anlagendokumentation.

17.4 Aggregationen Aggregationen haben im „Internet der Dinge“ den Zweck, aus den Baukastenele­ menten eine höherwertige Funktion entstehen zu lassen. Die beteiligten Elemen­ te können diese höherwertige Funktion in der Regel nicht alleine erbringen und werden durch zusätzliche gemeinsame Dienste erweitert. Stellt man sich einen be­ stimmten Sortertyp vor, welcher immer gleich aufgebaut ist, wäre dies ein Beispiel für eine solche Aggregation. Besonders wenn die Aggregation den Charakter eines in sich geschlossenen Subsystems hat und auch als solches vermarktet wird, kann es Sinn machen, die Aggregationen als standardisiertes Element in den Baukasten aufzunehmen. Dieses Vorgehen hat aber auch eine negative Seite. Eine in einem Projekt eingesetzte Aggregation aus dem Baukasten verringert unter Umständen die Flexibilität des gesamten Projektes wesentlich. Dies kommt dadurch zustande, dass die einzelnen Elemente der Baukastenaggregation nicht mehr frei mit den anderen Entitäten der Anlage interagieren können. Sie können nur in ihrer Gesamtheit am System teilnehmen. Diese ambivalente Eigenschaft der Aggregation kann in Projek­ ten hilfreich sein, wenn deterministische Abläufe realisiert werden müssen, bringt aber auch immer einen Flexibilitätsverlust mit sich. Somit ist mit jedem Projekt erneut zu klären, ob solche Aggregationen eingesetzt werden sollen oder Lösungen auf der Basis von einzelnen Entitäten bevorzugt werden.

17.5 Anpassung der Tools Um ein Projekt nach den Methoden des „Internet der Dinge“ effizient bearbeiten zu können, sind verschiedene Tools zur Unterstützung notwendig. Einige davon wurden bereits in Kap. 14 vorgestellt. Im Rahmen der Vorarbeiten müssen die Bau­ kastenelemente nun mit diesen Tools verknüpft bzw. eingepflegt werden. Erst durch diese Verknüpfungen werden die vielen positiven Eigenschaften der Internet-derDinge-Methoden zusammengeführt. Dadurch entsteht die Leistungsfähigkeit und Schlagkraft der Gesamtkonzeption „Internet der Dinge“. Das Handling der Tools

17  Die Erstellung eines Baukastens für das Internet der Dinge

189

muss an die unterschiedlichen Bedürfnisse der Anwender aus den verschiedenen Phasen des Lebenszyklus optimal angepasst werden. Zu erwarten ist auch, dass in die Baukastenelemente eventuell noch zusätzliche Informationen eingearbeitet werden müssen, damit die Arbeitsabläufe während der Anwendung der Tools ent­ sprechend optimal verlaufen. Die Anpassungsarbeit der Tools ist in dieser Phase von großer Wichtigkeit, weil durch die Tools das Internet der Dinge umgesetzt wird. Die Erscheinungsformen der Tools sind eine Art Visitenkarte des Internets der Dinge. Diese Visitenkarte ist entscheidend für die Akzeptanz, die der jeweilige Personenkreis dem neuen Model entgegenbringt. Verdeutlichen kann man die Re­ levanz der Toolanpassung z. B. bei der Erstellung der Topologie. Durch Informatio­ nen aus dem Baukasten kann der Bediener bei der Topologieerstellung unterstützt und geführt werden. Er wird somit intuitiv in der Lage sein, ein in sich konsistentes Anlagenlayout zu projektieren. Sind additive Komponente in den Elementen des Baukasten vorhanden, werden diese hier zu einem Mehrwert an Information und Benutzerfreundlichkeit führen. Eine saubere Toolfunktion wird alle Beteiligten mo­ tivieren und dadurch wesentlich zum Gesamterfolg und vor allem zur Akzeptanz dieser Technologie beitragen.

Kapitel 18

Der Lebenszyklus eines Internet der Dinge Materialf  lusssystems: Planung Clemens Nieke und Martin Henk

18.1  Qualif izierung Der Start eines neuen Projektes kann prinzipiell von zwei unterschiedlichen Ausgangspositionen erfolgen. Es gibt einerseits Projekte mit konkreter Lösung der logistischen Aufgabe und andererseits Projekte ohne Lösungsvorschlag der logistischen Aufgabe. Entsprechend unterschiedlich sind auch die Anforderungen, die an den Hersteller einer Anlage gerichtet werden. In Projekten mit konkreter Lösung der logistischen Aufgabe haben Planer die Problemstellung des Kunden in einen konkreten Entwurf umzusetzen. Diese Umsetzung erfolgt normalerweise, bevor ein Anlagenlieferant in das Projekt involviert wird. Der Planer legt den Projektumfang inklusive Layout der Anlage gemeinsam mit dem Kunden fest. Die Geschäftsprozesse des Kunden werden vom Planer auf die Anlage abgebildet. Zusätzlich werden vom Planer die relevanten Daten aus dem Artikelstamm des Kunden extrahiert und zur Verfügung gestellt. Aus diesen Artikeldaten werden vom Planer Leistungsdaten für die Schlüsselpunkte der neuen Anlage abgeleitet. Darüber hinaus werden normalerweise auch die zu verwendende Mechanik und die IT-Strukturen der geplanten Anlage festgelegt. In Projekten ohne vorgegebene logistische Problemlösung wird die Aufgabe vom Lieferanten zusammen mit dem Kunden erarbeitet. Der Kunde tritt mit einer Problemstellung an den Lieferanten heran und hat in der Regel nur vage Vorstellungen davon, wie die Lösung seiner Aufgabe aussehen könnte. Der Lieferant muss nun ähnliche Schritte wie ein Planer unternehmen, um zu einem fundierten Ergebnis zu gelangen. Zusätzlich kann der Lieferant seine eigenen Vorstellungen in die Problemlösung einbringen. Die Lösung der vom Kunden gestellten Aufgabe entspricht daher normalerweise einer bewährten Lösung aus dem Angebot des Lieferanten. In den Projekten, in denen die Lösung vom Lieferanten zusammen mit dem Kunden erarbeitet wird, ist das Risiko einer Fehleinschätzung des Projektaufwandes C. Nieke () Stöcklin Logistik GmbH Untere Industriestrasse 20, 57250 Netphen, Deutschland e-mail: [email protected] W. Günthner, M. ten Hompel (Hrsg.), Internet der Dinge in der Intralogistik, DOI 10.1007/978-3-642-04896-8_18, © Springer-Verlag Berlin Heidelberg 2010

191

192

C. Nieke und M. Henk

und der Komplexität des Projektes deutlich geringer. Dies begründet sich dadurch, dass der Anteil der bekannten Bauelemente höher ist und sie verlässliche Funktionen bieten. In den Projekten mit vorgegebener Lösung sind oft Anpassungen der herstellereigenen Produkte nötig, um den Vorgaben der Planung zu genügen. Daher steigen in diesem Fall oft das Risiko und die Kosten für ein Projekt. Für beide Projekttypen erfolgen Betrachtungen der für die Gesamtfunktion wichtigen Schlüsselpunkte, die eine Risikoabschätzung für das Projekt ermöglichen. Insbesondere zählen hierzu Flaschenhälse im Layout oder der Kommissionierung und eine Abschätzung zur technischen Realisierung. Weiterhin müssen die allgemeinen Umstände und die Vorschriftenlage im Land der Realisierung berücksichtigt werden. Abschließend werden die eigen Ressourcen für die Realisierung des Projektes abgeschätzt.

18.2  Spezif izieren bei vorgegebener Lösung Die Projekte mit fertiger Planung ermöglichen normalerweise keine Variationen der vorgezeichneten Lösung. Vielmehr stellt sich hier die zentrale Frage, wie gut die Entitäten des Baukastens die geforderte Lösung erfüllen können. Bevor jedoch diese zum Teil recht detaillierten Betrachtungen vorgenommen werden, muss zunächst die Planung auf Konsistenz und Vollständigkeit geprüft werden. Sollten die vorgegebenen Daten unvollständig sein, müssen die entsprechenden Informationen vom Planer oder Kunden eingeholt werden. Danach wird geprüft, ob die Eckdaten und Rahmenbedingungen der Planung realistisch sind. Der Durchsatz der geplanten Anlage muss mit dem vorgegebenen Layout unter Berücksichtigung der Leistung der einzelnen Entitäten zu erreichen sein. Wurden keine Unstimmigkeiten im Konzept der Anlage entdeckt, erfolgt die Umsetzung der vorgegebenen Lösung mit den Entitäten des Baukastens. Entsprechend den Vorgaben der Planung wird das Layout aus den Entitäten des Baukastens zusammengestellt, wobei auch überprüft wird, inwieweit die spezifizierten Anlagenteile mit den vorhandenen Entitäten realisiert werden können. Dabei werden besonders die Eigenschaften und das Leistungsspektrum der Entitäten innerhalb ihrer Anpassbarkeit überprüft. Eine Entität muss die Anforderungen erfüllen können, wenn sie innerhalb ihrer normalen Parameter betrieben wird. Sind die grundsätzlichen Bedingungen erfüllt, müssen anschließend die Details der Entitäten auf ihre Konformität hin überprüft werden. Diese Prüfung ergibt den Anpassungsgrad, der für diese Entitäten notwendig ist. Sind additive Komponenten (s. Kap. 17) vorhanden, vereinfachen diese die Überprüfung. Die einfachste Möglichkeit liegt vor, wenn die Details der Entitäten lediglich parametriert werden müssen. Gleiches gilt auch für die additiven Komponenten, sofern sie vorhanden sind. Umfangreiche Anpassungen führen automatisch zu einer vollständig neuen Ausführung der Entität. Diese neue Ausführung kann sich unter Umständen sehr stark von der ursprünglichen Baukastenentität unterscheiden und kann dann als neue projektspezifische Entität ausgeführt werden. Die meisten vorgezeichneten Projekte werden weitere Aufgabenstellungen enthalten, die mit den Elementen des Baukastens nicht abgedeckt werden können.

18 ��������������������������������������������������������������������������������� Der Lebenszyklus eines Internet der Dinge Materialf  lusssystems: Planung

193

Diese Teilaufgaben können prinzipiell durch Neuentwicklungen oder zugekaufte Lösungen erledigt werden. Wenn Lösungen geplant sind, die teilweise oder komplett zugekauft werden, müssen entsprechende Schnittstellen mit dem Sublieferanten definiert werden. Für diese Schnittstelle bieten sich bestimmte Varianten an, die sich am logischen Zuschnitt der Entität orientieren können. Der einfachste Fall ist, wenn der Sublieferant die gesamte Entität inklusive Software liefert. Weitere Abgrenzungsmöglichkeiten bestehen zwischen der Agentensoftware und der Maschinensteuerung oder zwischen der Software und der Hardware einer Entität. Ein weiterer wichtiger Planungspunkt ist die Festlegung der HMI-Schnittstelle. Auch wenn der Projektumfang fest vorgeschrieben ist, bestehen häufig Lücken in den Festlegungen zur Bedienung und Beobachtung der Anlage. Die Anforderungen sind in diesen Punkten meist allgemein gehalten. So ist beispielsweise die Art und Anzahl der Bedieneinheiten festzulegen. Ebenso müssen die Konfigurationsmöglichkeiten festgelegt werden, die ein Bediener während des Betriebes der Anlage haben soll. Die abschließende Arbeit bei der Spezifikation einer Anlage mit vorgegebener Lösung besteht darin, dass das vom Planer vorgegebene Lastenheft in ein hersteller- und projektspezifisches Pflichtenheft umgewandelt wird. Bei dieser Umwandlung wird der Hersteller den Aufbau der Anlage mit seiner Technologie darstellen. Das Pflichtenheft wird sich im Internet der Dinge stark an den Entitäten des Baukastens orientieren.

18.3  Spezif izieren bei nicht vorgegebener Lösung Die Lösung der Problemstellung wird in Zusammenarbeit mit dem Kunden erbracht. Um die Grundlage der Problemlösung in diesen Projekten zu schaffen, müssen intensive Gespräche mit dem Kunden stattfinden. In diesen Gesprächen werden die Probleme zunächst identifiziert. Der Hersteller überführt anschließend die Problemstellung mit Hilfe eigener Konzepte in eine Lösung. Die erarbeitete Lösung muss dann teilweise, wie im vorigen Abschnitt beschrieben, überarbeitet und validiert werden. Prinzipiell stehen bei dieser Projektart mehr relevante Daten zur Verfügung, da hier das Konzept selbst erarbeitet wurde. Es müssen nicht mehr alle Überprüfungen durchgeführt werden. Die Umsetzung der Projekte kann schneller und kostengünstiger erfolgen, da die Lösung weitgehend auf den eigenen Entitäten des Baukastens beruht. Die anfängliche Erfassung der Anforderungen des Kunden wird sich auch im Internet der Dinge grundsätzlich nicht von den heutigen Vorgehensweisen unterscheiden. Mit der Verbreitung von Anlagen nach der Internet-der-Dinge-Technologie werden die Ansprüche der Kunden an die Anlagen steigen. Insbesondere wird die Flexibilität im Betrieb und die Flexibilität bei späteren Erweiterungen das Anforderungsprofil der Kunden wesentlich verändern. Die Grundlagen einer Projektanalyse basieren auf den qualitativen und quantitativen Zielsetzungen des Projektes. Nachdem die Zielsetzungen herausgestellt sind, wird das Transport- und Lagervolumen des Projektes skizziert. Unter Einbeziehung verschiedener Rahmen- und Randbedingungen können die Anforderungen

194

C. Nieke und M. Henk

detaillierter formuliert werden. Beispielsweise gehören dazu die voraussichtlichen Betriebszeiten, die Ladehilfsmittel und Umgebungsbedingungen wie Temperatur oder Witterung. Schließlich müssen noch formale Randbedingungen festgelegt werden. Insbesondere gehören spezielle Werksvorschriften dazu, die der Kunde festgelegt hat. Zusätzlich kann der spätere Aufbau der Anlage durch bestimmte Vorschriften beeinflusst werden, wie beispielsweise GMP (Good Manufacturing Practice). In Absprache mit dem Kunden erfolgt nach der Klärung der Eckpunkte die Umsetzung der Aufgabenstellung mit den Mitteln des eigenen Produktspektrums. Zur Feinplanung der Anlage wird zunächst auf bekannte Umsetzungen ähnlicher Anlagen oder frühere Planungen zurückgegriffen. Wenn bereits ähnliche Projekte realisiert wurden, können diese Informationen oft als Basis für weitere Schritte herangezogen werden. Die Geschäftsprozesse des Kunden müssen detailliert aufgenommen und in einem zugehörigen Layout mit entsprechendem Workflow umgesetzt werden. Die Aufnahme der Geschäftsprozesse berücksichtigt insbesondere auch das Produktspektrum mit Artikelstamm und Handlings-Vorschriften. Zur Umsetzung wird unter Zuhilfenahme des Baukastens und der Gebäudepläne eine entsprechende Topologie zusammengestellt. Der Baukasten unterstützt den Projektierer dabei durch diverse Hilfsmittel und zusätzliche Informationen aus den Entitäten. Die Umsetzung des Workflows in Arbeitsanweisungen für TE-Agenten bildet die Grundlage für die späteren Funktionen. Einen entscheidenden Einfluss auf das Layout haben die Eckdaten der Anlage, welche sich zum Teil aus dem Workflow ergeben. Die Leistungen der eingesetzten Elemente und ihre Anzahl müssen sich an dem geforderten Durchsatz und der voraussichtlichen täglichen Betriebszeit orientieren. Dabei sind insbesondere die markanten Punkte wie Pickleistungen in der Kommissionierung oder das maximale Spitzentransportvolumen zu berücksichtigen. In die Leistungsbetrachtung fließt zusätzlich die gewünschte Redundanz für das System und die Verfügbarkeit der einzelnen Komponenten ein. Dabei müssen auch eventuell vorhandene Normen und Regelwerke (FEM) berücksichtigt werden. Mit Hilfe der erstellten Topologie kann unter Berücksichtigung der Gleichzeitigkeitsfaktoren eine Energiebilanz der Anlage erstellt werden. Energieversorgung und Kommunikationsnetzwerke müssen entsprechend dem Bedarf projektiert werden. Das Layout der Anlage muss normalerweise an die baulichen Gegebenheiten angepasst werden. Zu den Umgebungsgegebenheiten gehören neben klimatischen Bedingungen (Temperatur, Staub, Feuchtigkeit, Explosionsgefahr) auch Brandschutzeinrichtungen sowie die Kooperation mit diesen Einrichtungen. Die physikalische Ausprägung der Anlage richtet sich auch nach den Ladehilfsmitteln, den physikalischen Eigenschaften des Transportgutes und der vorgesehenen Transportart. Eine Anlage, deren Transportmittel aus automatischer Fördertechnik, Gabelstaplern, fahrerlosen Transportsystemen, usw. besteht, ist sicherlich anders aufgebaut als eine Behälterfördertechnik. Sind im Baukasten zusätzliche mechanische Informationen zu den Entitäten enthalten, unterstützen diese den Projektierer beim Entwurf der Anlage. Besonderen Planungsaufwand verlangen die Schnittstellen zu externen Systemen. Zum einen ist hier die Kommunikation zu übergeordneten Systemen zu betrachten, und zum anderen können eventuell vorhandene Subsysteme in die Anlage

18 ��������������������������������������������������������������������������������� Der Lebenszyklus eines Internet der Dinge Materialf  lusssystems: Planung

195

integriert werden. Für den Datenaustausch zu den LVS/ERP-Systemen müssen die Punkte der Anlage festgelegt werden, an denen mit diesen Systemen kommuniziert werden soll. Dazu gehören neben den Stellen zur Datenerfassung auch Meldepunkte, die die übergeordneten Systeme aufgrund physikalischer Ereignisse benachrichtigen. Die Subsysteme können durchaus größere Dimensionen besitzen. Beispielsweise bilden Stapler- oder Handtransportstrecken, Fahrerlose Transportsysteme oder komplexe Bearbeitungsstationen eigene Systeme, die eventuell auch eigene Entscheidungen bezüglich ihres Materialflussanteiles treffen können. Gleiches gilt für herkömmliche Anlagenteile, die klassisch mit einem Materialflussrechner gesteuert werden. Sind im Baukasten entsprechende Entitäten zur Kommunikation mit den benachbarten Systemen vorhanden, könne diese eingesetzt und parametriert werden. Eventuell müssen auch neue Entitäten in Form von Diensten geschaffen werden, die als Interface zwischen den Systemen agieren. Eine ähnliche Problematik besteht für die Datenstruktur und den Datenumfang des TE- Datenträgers, welcher zusammen mit der Ladeeinheit durch die Anlage transportiert wird. Hier muss festgelegt werden, welche Informationen mit einem Artikel oder Gebinde kombiniert werden sollen und wie diese Informationen gespeichert werden. Dabei reicht die Spanne der Möglichkeiten von der Datenhaltung im TE-Agenten und der Identifizierung via Barcode, über Datenhaltung auf passiven RFID-Chips bis hin zu aktiven Datenspeichern, die während des Transports ihre Datensätze selbständig ergänzen (s. a. Kap. 12). Zur Bedienung der Anlage ist die Art und Weise der Visualisierung sowie der Umfang der Bedienung festzulegen. Neben der Anzahl der Visualisierungsstationen sind auch die Eingriffsmöglichkeiten der Bediener und der Detaillierungsgrad der Visualisierung zu definieren. Ebenso ist das Datenvolumen zur statistischen Auswertung und der dafür notwendige Speicherplatz zu bestimmen. Die Visualisierung setzt sich zunächst aus den Topologie-Informationen, den Daten der TE-Agenten und den Betriebszuständen der Fördertechnikelemente zusammen. Jede Entität kann über sich selbst Informationen für die Statistik, Visualisierung und über ihre Parameter zur Verfügung stellen. Mit diesen Informationen kann eine grundlegende Visualisierungs- und Bedienoberfläche generiert werden. Je mehr Visualisierungselemente im Baukasten vorhanden sind und je mehr Informationen von den Entitäten angeboten werden, umso detaillierter können die Informationen aufbereitet werden. Die Spezifizierung einer selbstgeplanten Anlage schließt mit der Erstellung eines Pflichtenheftes ab. Durch die hohe Konformität der Anlage mit dem Baukasten ist das Pflichtenheft sehr schnell und vor allem detailliert erstellbar.

18.4  Simulation Die Simulation einer Anlage dient einerseits der Validierung des Konzeptes für die Umsetzung der Geschäftsprozesse des Kunden und andererseits der Validierung der maschinennahen Steuerprogramme. Im Internet der Dinge spielt die Simulation zur Validierung der maschinennahen Steuerprogramme nur eine untergeordnete Rolle. Einerseits werden die gleichen Programme immer wieder fast unverändert eingesetzt

196

C. Nieke und M. Henk

und andererseits gibt es Szenarien, die ohne entsprechende Programme auskommen. Beispielsweise ist ein Stapler-Leitsystem nicht auf eine maschinennahe Steuerung angewiesen. Die Simulation der Anlage erfolgt anhand ihrer Topologie und dem Workflow. Im Internet der Dinge liegt hier der entscheidende Unterschied. Die realen Agenten werden in die Simulation eingesetzt. Diese getesteten Agenten werden später in der Anlage zum Einsatz kommen. Damit die Agenten in der Simulation auch auf physikalische Ereignisse reagieren können, werden die maschinennahen Steuerungen durch Emulatoren ersetzt. Sollten in der geplanten Anlage Entitäten vorhanden sein, die zugekauft werden oder neu im Baukasten sind, muss spätestens jetzt die Agentensteuerung und der Emulator für diese Entitäten vorhanden sein. Als Simulator können handelsübliche Simulationstools verwendet werden, für die eine Importmöglichkeit existiert. Ebenso können herstellereigene, passend zugeschnittene Systeme verwendet werden, in dem der Materialfluss durch die Interaktion der Agenten entsteht. Das Ziel dieser Simulation ist die Validierung des Layouts und des Workflows unter Berücksichtigung der Eckdaten der Anlage. Besonderes Augenmerk liegt dabei auf den strategisch wichtigen Punkten der Anlage. Eventuell muss das erstellte Layout oder der Workflow aufgrund der Simulationsergebnisse angepasst werden. Zur vollständigen Simulation der Anlage gehört auch der Einsatz der HMI-Schnittstelle, insoweit sie sich nicht auf den maschinennahen Teil der Anlage bezieht. Die Leitstandfunktionalität kann mittels der Simulation genauso getestet werden wie die Anlagenfunktionalität. Die Simulation des Leitstandes ermöglicht neben dem Test des Gesamtsystems auch die Schulung der Key-User, bevor die Anlage fertig aufgebaut ist. Durch die Schulung der Key-User können zu einem frühen Zeitpunkt Anpassungen der Bedienung oder der Funktionalität vorgenommen werden.

18.5  Interne Kalkulation Die interne Kalkulation der geplanten Anlage schätzt die Herstellungskosten auf Basis des endgültigen Entwurfs ab, der nach erfolgreicher Simulation festgeschrieben wurde. Als bekannter Teil für die Kalkulation können die Kosten der Entitäten herangezogen werden, welche dem Baukasten entnommen wurden. Diese Kosten müssen noch um die projektspezifischen Änderungen ergänzt werden. Je nach Vorhandensein oder Qualität der additiven Komponenten kann die Aufstellung der jeweiligen Kosten einer Entität zügig abgearbeitet werden. Die Kosten neuer Entitäten müssen vollständig abgeschätzt werden. Für alle Entitäten, die zugekauft werden sollen, müssen entsprechende Angebote der Lieferanten eingeholt werden. Zusätzlich zu den Kosten dieser zugekauften Entitäten müssen die Kosten für die Angebotseinholung, Abwicklung, Kontrolle und die Koordination der Schnittstellen berücksichtigt werden. Die Kosten der entitätenübergreifenden Installationen können nicht mehr aus dem Baukasten abgeleitet werden. Zu diesem Bereich gehören vor allem die Kosten für die Sicherheitstechnik der Anlage, soweit sie nicht sowieso zu den Entitäten gehört. Beispielsweise müssen Umwehrungen einer Anlage immer individuell angepasst und steuerungstechnisch

18 ��������������������������������������������������������������������������������� Der Lebenszyklus eines Internet der Dinge Materialf  lusssystems: Planung

197

abgesichert werden. Ebenso fallen zusätzliche Kabeltrassen oder der Aufbau eines Netzwerkes in diese Kategorie. Die Abschätzung der anfallenden Datenvolumina, die archiviert werden sollen, führt zur Abschätzung der Kosten für die notwendigen Speichereinrichtungen. Ebenso müssen die Kosten für die notwendige Rechenleistung und Datensicherheit, sowie die erforderliche Netzwerktechnik berücksichtigt werden, sofern diese Leistungen erforderlich sind oder nicht kundenseitig erbracht werden. Alle projektspezifischen Erweiterungen erfordern auch einen erhöhten Dokumentationsaufwand, der nicht durch die Standarddokumentation abgedeckt wird. Insbesondere fallen hier die Kosten für erweiterte Dokumentationen der Sicherheitsmaßnamen ins Gewicht. Schließlich müssen die Kosten für besondere Kunden- oder länderspezifische Vorschriften berücksichtigt werden. Diese Vorschriften können sich auch auf die Montage und Inbetriebnahme erstrecken, die länderspezifisch sind und sich meist kostensteigernd auswirken. Die Betrachtung des Aufwands für die Unterstützung in der Hochlaufphase, sowie Schulungen und die Projektleitung runden die Kalkulation der Kosten für die geplante Anlage ab. Die Kostenermittlung gestaltet sich in vielen Bereichen einer Anlage, die nach Internet der Dinge aufgebaut ist, deutlich einfacher und damit präziser als für eine herkömmliche Anlage. Voraussetzung dafür ist ein gut ausgearbeiteter Baukasten mit entsprechenden Informationen zu den enthaltenen Entitäten.

18.6  Koordinierung der Zulieferer Für die Koordinierung der Zulieferer ist ein Terminplan für die Bereitstellung der Leistungen der Zulieferer aufzustellen. Zum Abgrenzen des Leistungsumfangs werden die technischen Detailangaben spezifiziert und mit den Lieferanten vereinbart. Eventuell müssen den Lieferanten Arbeitsvorschriften und Montagebedingungen des Kunden übermittelt werden. Nach erfolgter Lieferung sind Funktionstest und Abnahme der gelieferten Komponenten erforderlich. Die Lieferungen werden durch die Bereitstellung der Dokumentationen und Konformitätserklärungen zu den gelieferten Komponenten vervollständigt. Die Koordination der Zulieferer kann aufgrund der vielfältigen Möglichkeiten im Internet der Dinge extrem unterschiedlich ausfallen. Die Zulieferung kann sich von kleinen Komponenten über komplette Mechanik bis hin zu vollständigen Entitäten erstrecken. Je nach Leistungsumfang kann ein erhöhter Koordinierungsaufwand entstehen.

18.7  Projektierung der Steuerungstechnik Die Steuerungstechnik einer Internet-der-Dinge-Anlage kann je nach Ausführung der Anlage unterschiedlich komplex sein. Werden Entitäten aus dem Baukasten verwendet, ist die Steuerungstechnik in weiten Bereichen schon festgelegt.

198

C. Nieke und M. Henk

Insbesondere bei Verwendung mechatronischer Komponenten sind die Aufwendungen sehr gering. Benutzen mehrere Entitäten gemeinsame Ressourcen wie z. B. Controller oder Feldbussysteme, steigt der Aufwand für die steuerungstechnische Projektierung (s. a. Kap. 12). Bei allen Anlagen mit steuerungstechnischen Komponenten muss das Energieversorgungs- und Erdungskonzept sowie die Vernetzung der Komponenten projektiert werden. Dazu gehören auch die sicherheitstechnischen Komponenten sowie die Anbindung an Gebäudeleitsysteme. Bei der Projektierung der HMI-Schnittstellen ist nicht nur die Visualisierung mit Leitstandfunktionalität, sondern auch die Bedienung der Anlage vor Ort zu berücksichtigen. Hier kommt es darauf an, welche Bedienmöglichkeiten die Entitäten von sich aus schon vorsehen. Eventuell müssen Anschlusspunkte für die maschinennahen Bedienpanels oder Accesspoints für drahtlosen Zugang eingeplant werden. Für die Bedienungseinrichtungen mit Leitstandfunktionalität werden die Standorte und die damit erforderliche Anschlusstechnik projektiert. Das gilt sowohl für die Energieversorgung wie auch für den Netzwerkanschluss.

18.8  Projektierung der IT Die Auslegung der datentechnischen Anlagenvernetzung hat ähnlich wie bei der Projektierung der Steuerungstechnik einen entscheidenden Einfluss auf die Planungsphase. Die Vernetzung vieler Entitäten mit eingebautem Controller und integriertem Switch eignet sich zum Aufbau einer Linienstruktur des Netzwerkes. Anlagen mit wenigen Controllern können hingegen klassisch vernetzt werden und benötigen dann einen zentralen Switch inklusive Schaltschrank. Die benötigte Leistungsfähigkeit des Netzwerkes kann aus der Simulation und den topologischen Grundlagen der Anlage abgeleitet werden. In den Anlagen können zusätzlich Redundanzen mittels Ringstrukturen vorgesehen werden. Außerdem können Segmentierungen des Netzwerkes mit entsprechenden Netzübergängen erforderlich sein. An den Netzübergängen zu externen Systemen müssen die üblichen Schutzmechanismen gegen unbefugten Zugriff, wie zum Beispiel Proxy-Server oder Firewalls, projektiert werden. Zusätzlich müssen definierte Zugriffsmöglichkeiten geschaffen werden, die neben der üblichen Kommunikation mit der Anlage auch die Fernwartung erlauben.

18.9  Terminplanung des Projekts Die terminliche Planung des gesamten Projektablaufs erfolgt üblicherweise von einem fixen Endtermin aus rückwärts. Für einen detaillierten Projektplan müssen die Ecktermine für das Pflichtenheft, den Start der Realisierung, das Einbringen der Fördertechnik beim Kunden, die Inbetriebsetzung, der Zeitraum des Test und

18 ��������������������������������������������������������������������������������� Der Lebenszyklus eines Internet der Dinge Materialf  lusssystems: Planung

199

Hochlaufes und den Zeitpunkt für die Anlagenübergabe an den Kunden festgesetzt werden. Im Internet der Dinge müssen diese Arbeiten nicht mehr streng sequenziell geplant sein. Manche Arbeiten können mit einem kleinen zeitlichen Versatz quasiparallel erfolgen. Die Produktion kann zum Teil parallel zur Montage und Inbetriebsetzung geplant werden. Dies ist im Internet der Dinge möglich, weil die Anlage entsprechend dem Entitätszuschnitt aufgebaut und in Betrieb gesetzt werden kann. Dadurch können Teilbereiche einer Anlage schon vorzeitig autark betrieben werden, auch wenn andere Anlagenbereiche sich noch im Aufbau befinden. Die entsprechenden Zeiträume müssen in einem Aufbauplan projektiert werden. Ein solches Vorgehen ist nur möglich, wenn alle anderen Gewerke wie z. B. Dach, Wand und Beleuchtung im betreffenden Gebäudebereich keine Einschränkungen für den geplanten Arbeitsablauf erzeugen. Parallel zur Inbetriebnahme der letzten Entitäten kann der Startzeitpunkt für die Hochlaufphase der Anlage festgesetzt werden. Die in diesem Kapitel gemachten Ausführungen zeigen, dass die Qualifizierung eines Projektes und die Ermittlung der Kundenbedürfnisse in einem Projekt im Internet der Dinge sich nicht vom bisherigen Vorgehen unterscheiden. Im Vergleich zum heute üblichen Vorgehen wird durch das Baukastenkonzept die Planung der Anlage aber durchgehender und dadurch effizienter. Diese Effizienz beginnt bereits schon in der Verkaufsphase. Besitzt der Baukasten eine gute und umfangreiche Qualität und ist er mit vielen additiven Komponenten angereichert, wird die Planungsphase markant verkürzt.

Kapitel 19

Der Lebenszyklus eines Internet der Dinge Materialf  lusssystems: Realisierung Clemens Nieke und Martin Henk

Bei einem Kundenprojekt wurden vor dieser Phase schon viele Anforderungen und grundlegende Informationen über eine Anlage zusammengetragen. Nun gilt es, aus all diesen Informationen die für den Kunden bestmögliche und technisch fundierte Umsetzung zu erreichen. Entscheidend ist in dieser Phase, die bisher erarbeiteten Teilergebnisse noch einmal zu überprüfen, um eventuelle Schwächen der bis dahin meist nur theoretischen Lösungsansätze aufzudecken.

19.1  Detailstudie Die Phase der Realisierung beginnt mit der Detailstudie. Typischerweise wird man sich zu Beginn der Realisierungsphase erneut mit dem bisher geplanten Workflow der Anlage beschäftigen. Dies bewirkt, dass die einzelnen funktionalen Transportsequenzen detailliert betrachtet werden. Die wechselseitigen Bedingungen und Eigenschaften der mechanischen Entitäten und der Transporteinheiten bestimmen hier den Blickwinkel. Durch dieses Vorgehen werden die für die Gesamtanlage wichtigen Schlüsselpunkte identifiziert. Mit den Durchsatzmengen aus der Simulation lassen sich für jeden dieser Schlüsselpunkte die genauen Funktionalitäten festlegen. Mit dieser funktionalen Festlegung kann noch einmal verifiziert werden, ob die für diesen Anlagenpunkt ausgesuchten Entitäten auch wirklich alle Eigenschaften besitzen, welche für die funktionale Realisierung von Nöten sind. Ergeben sich hier wider Erwarten noch Unterschiede, so muss mit Hilfe der Simulation noch einmal nach den Ursachen geforscht werden. Um diese Probleme lösen zu können, kann es unter Umständen notwendig werden, leichte Veränderungen des Analgenlayouts vorzunehmen. Nach der Bearbeitung der Schlüsselpunkte muss auch für den restlichen Anlagenteil die jeweilige Funktionalität überprüft werden. Die Überprüfungen sollten selten Korrekturen zur Folge haben, da der Entitätsbaukasten durch seine C. Nieke () Stöcklin Logistik GmbH, Untere Industriestrasse 20 57250 Netphen, Deutschland e-mail: [email protected] W. Günthner, M. ten Hompel (Hrsg.), Internet der Dinge in der Intralogistik, DOI 10.1007/978-3-642-04896-8_19, © Springer-Verlag Berlin Heidelberg 2010

201

202

C. Nieke und M. Henk

Charakteristik solche Probleme schon im Vorfeld verhindert. Nach der Überprüfung ist ein komplettes Gesamtbild der Anlagenfunktionalität entstanden. Dieses Gesamtbild muss mit den Anforderungen aus dem Pflichtenheft übereinstimmen. Der auf die Anlagenfunktion bezogene Teil der Detailstudie wird durch die Verifizierung der Identifikationspunkte der TE in der Anlage abgeschlossen. Dies ist besonders wichtig, da an diesen Anlagenpunkten jeder TE- Agent sich in einem Bereich einer RFID Schreib- und Leseeinheit befindet und somit garantiert die Daten des RFID Chip bearbeitet werden können; bei Transporteinheiten mit passivem Chip ist dies sogar von existenzieller Wichtigkeit. Es ist dabei Voraussetzung, dass die Chiptechnologie und Frequenz der Schreib- Leseeinrichtungen zusammen passen. Nach diesen auf die anwenderfunktionalen Grundlagen des Systems fokussierten Arbeiten muss in der Detailstudie die Sicherheitskategorie der Anlage festgelegt werden. Die Einstufung einer Anlage muss nicht einheitlich sein. Entsprechend den Anforderungen der TE und/oder den Umweltfaktoren können Bereiche mit unterschiedlichen Sicherheitskategorien in einer Installation vorhanden sein. Eine erste Unterscheidung muss hier typischer Weise bezüglich des Explosions- und Spritzwasserschutzes sowie der Umgebungstemperatur erfolgen. Diese grundlegende Unterscheidung reicht aber oft nicht aus. Es müssen noch die allgemeinen Rahmenvorschriften aus dem Aufstellungsland der Anlage berücksichtigt werden. Den Werksvorschriften des Kunden ist ebenso Rechnung zu tragen. Zuletzt ist zu ermitteln, ob weitere spezielle Ansprüche bezüglich der Sicherheit von Seiten der Prüfvereinigungen wie z. B. TÜV bestehen. Ein weiterer zentraler Arbeitsschritt der Detailplanung beschäftigt sich mit der Kommunikation und Datengewinnung innerhalb der Anlage. Bei der Datengewinnung gilt es, zwei Richtungen zu betrachten. Die eine Informationsrichtung liegt zwischen Softwareagent und den Steuerungselementen, die zweite Richtung ist die Datenübertragung zu übergeordneten Systemen. Umfangreiche hardwarenahe Informationen aus der Anlage oder die Ansteuerung komplexer Steuerungskomponenten wie z. B. Antriebsregler können es notwendig machen, entsprechende Feldbussysteme innerhalb einer Entität einzusetzen. Umgekehrt können aber auch Daten aus der LVS/ERP Ebene in Richtung der Anlage fließen. Durch die Vernetzung der Entitäten ist das Ethernet schon vorhanden und muss daher nicht zusätzlich geplant werden. Die Dateninhalte sind unabhängig von der Datenrichtung und müssen in der Detailstudie ermittelt werden. Abschließend kann nun festgestellt werden, wie nahe die gesamte Projektlösung an einer früher bereits realisierten Anlage ist. Dadurch wird bestimmt, wie groß die direkte Wiederverwertung bestehender Entitäten ist.

19.2  Feinplanung und Pf lichtenheft Ging es bei der Detailplanung im Prinzip darum, die projektspezifischen Anforderungen und Besonderheiten in einen Lösungsansatz zu überführen, so arbeitet die Feinplanung diesen Lösungsansatz weiter aus und erzeugt die direkte Arbeitsanweisung für die Realisierung. Die Arbeiten innerhalb der Detail- und Feinplanung

19 ������������������������������������������������������������������������������������� Der Lebenszyklus eines Internet der Dinge Materialf  lusssystems: Realisierung

203

sind im alltäglichen Projektgeschäft meist nicht genau voneinander zu trennen. Entsprechend dem Komplexitätsgrad der einzelnen Teilaufgaben werden die Arbeitsschritte oftmals gemeinsam erledigt. Das folgende Beispiel der Kabelbeschriftung kann dies verdeutlichen. Während das prinzipielle Beschriftungskonzept zur Detailplanung gehört, ist die Beschriftungsart und die dazu verwendeten Tools, wie z. B. Ringnummern oder Druckstempel eine Sache, die zur Feinplanung gehört. Da die Gesamtaufgabe der Kabelbeschriftung nicht sehr komplex ist, werden im Normalfall beide Tätigkeiten in einem Arbeitsgang erledigt. Bei komplexeren Aufgaben sieht dies natürlich anders aus. Zur Feinplanung gehört die funktionale Beschreibung der einzelnen Arbeitsplätze in der Anlage. Deshalb ist es erforderlich, jede Transportaktivität und die dazugehörige Bedieneraktion genau zu beschreiben. Beschrieben werden müssen auch die Steuerungskomponenten, welche für den Bediener von Bedeutung sind. Dies könnte die Funktionsweise eines Scanners am Arbeitsplatz oder die Funktion von Bedienelementen der Anlage sein. Diese Beschreibungen der einzelnen Abläufe bewirken eine implizite Überprüfung der eingesetzten Entitäten. Sollten sich bei der bisherigen Entitätsauswahl Fehler eingeschlichen haben, so treten diese hier zu Tage und können rechtzeitig vor Fertigungsbeginn korrigiert werden. Auch die eingesetzten Aggregationen werden durch die genauen Funktionsbeschreibungen noch einmal auf ihre richtige Zusammensetzung aus den Grundentitäten des Baukastens überprüft. Ein Kundenprojekt wird nur sehr selten rein aus den Entitäten des Baukastens realisiert werden können. Aus diesem Grund ist in der Feinplanungsphase eine Trennung zwischen den bereits vorhandenen und den noch zu erstellenden Entitäten notwendig. Das weitere Vorgehen verändert sich in Abhängigkeit dieser Trennung. Die Weiterbearbeitung erfolgt in den später folgenden Teilphasen des Customizing oder mit Hilfe der Programmierung. Zuvor ist in der Feinplanung noch die Sicherheitstechnik zu vervollständigen. Alle Vorschriften sowie der Informationsaustausch zu Brandschutzanlagen und eventuell vorhandenen Klimatisierungseinrichtungen oder Gebäudeleitsystemen müssen zum endgültigen Gesamtkonzept zusammengeführt werden. Dazu gehört auch die Abstimmung der eingesetzten Komponenten und Elemente, welche dann später zu den Sicherheitseinrichtungen verbaut werden. Neben der Bestimmung der Bauelemente für die Sicherheitstechnik müssen auch die grundlegenden Typenbzw. Baureihen der in den Entitäten einzusetzenden Steuerungselemente wie Sensoren, Schalteinrichtungen, Regler und Automatisierungsgeräte festgelegt werden. Daran kann anschließend der endgültige Energiebedarf und somit die realen Anforderungen an die Energieversorgungen ermittelt werden. In diesem Zusammenhang muss geprüft werden, an welchen Stellen der Anlage eine unterbrechungsfreie oder zumindest zeitlich gepufferte Energieversorgung benötigt wird. Das können in der Praxis batteriebetriebene unterbrechungsfreie Stromversorgungen für Freifahrsteuerungen, Druckluftreserven oder auf der Basis von fossilen Brennstoffen betriebene Notstromaggregate sein. Die Grundlagen für die Energiebedarfsermittlung wurden schon in der Planungsphase gelegt und werden in dieser Teilphase zum Abschluss gebracht. Eng verbunden mit der Auslegung der steuerungstechnischen Bauelemente ist auch die Einrichtung und Segmentierung der Feldbussysteme.

204

C. Nieke und M. Henk

In einem letzten Feinplanungsschritt sind die Belange der Kommunikation bzw. der Datenerhebung und Speicherung zu berücksichtigen. Für alle Schnittstellen zu anderen Systemen müssen die genauen Dateninhalte und besonders auch die Datenformate ausgearbeitet werden. Im Gegensatz hierzu ist die Kommunikation zwischen den Entitäten durch die Ontologie des “Internet der Dinge“ schon bereits festgelegt. Jeder Datenaustausch benötigt einen Speicherplatz für die entsprechenden Trace- und Logdateien. Diese Ressourcen und Speicherbereiche müssen projektiert werden und schließen somit die gesamte Planung ab.

19.3  Konf iguration/Customizing Das Customizing ist die Stelle, an der sich das Gesamtkonzept „Internet der Dinge“ mit seinen vielfältigen Stärken am deutlichsten auswirkt. Betrachtet man den neuen Lifecycle eines Logistikprojektes, so ist hier sicherlich die größte zeitliche Ersparnis zu erwarten. Die Baukastenphilosophie, verbunden mit der durchgängigen Projektierung und Simulation bewirkt, dass der weitaus größte Teil einer Anlage durch eine Konfiguration, anstelle der bisher üblichen Programmierung, erstellt werden kann. Im Customizing geht es um die Anpassung der Entitäten aus dem Baukasten an die jeweilige Projektsituation. Idealerweise sind diese Aufwände sehr gering, da jede Entität eine eigene Rechnerressource besitzt. Sind Rechnersysteme vorhanden, die mehreren Agenten einen Lebensraum bieten, müssen diese entsprechend eingerichtet und systemintern bekannt gemacht werden. Die notwendigen Vorgaben für die Konfiguration des Systems können dabei aus dem Internet-der-Dinge-Manager (s. Kap. 14) entnommen und somit direkt aus der projektierten Topologie abgeleitet werden. Eine entsprechende Exportmöglichkeit des Internet-der-Dinge-Managers stellt sicher, dass dies sehr schnell und einfach vonstatten gehen kann. Sind in einem Projekt Informationsaustauschbörsen wie Black-Boards vorgesehen, so müssen auch diese in der Teilphase des Customizing eingerichtet und entsprechend konfiguriert werden. Eine letzte Umfeldkonfiguration ist die Speicherorteinrichtung für die Langzeitprotokollierung der Trace- und Statistikdaten nach den aus der Feinplanung entwickelten Vorgaben. Nach dem Customizing des Umfeldes erfolgt die Konfiguration der Agenten. Fördertechnische Agenten benötigen eine eindeutige Adresse. Mit dieser Adresse können sie im Netzwerk ihre Vorgänger- und Nachfolgerbeziehungen ermitteln und vor allem ihre Dienste zur Verfügung stellen. Entitätsintern ist bei mechatronischen Agenten noch die Middleware zu konfigurieren, damit die entsprechenden Sensoren und Aktoren angesprochen werden können. Hat eine Entität aus dem Baukasten mehrere interne standardisierte Funktionsvarianten, so kann das gewünschte Verhalten ebenfalls konfiguriert werden. Dies ist aber abhängig vom internen Aufbau der Baukastenentität und sollte nur in sehr geringem Umfang erforderlich sein. Wurden die Entitäten zuvor schon in der Simulation verwendet, so müssen auf der Ebene der Maschinensteuerung die emulierenden Bausteine gegen die realen Steuerungsbausteine ausgetauscht werden. Die Agenten für die Transporteinheiten sollten im Normalfall unverändert in jedes Projekt übernommen werden können. Grundsätzlich ist es aber auch hier denkbar,

19 ������������������������������������������������������������������������������������� Der Lebenszyklus eines Internet der Dinge Materialf  lusssystems: Realisierung

205

dass die TE-Agenten intern einen gewissen frei verfügbaren Speicherbereich haben, der sich für eine Konfiguration von zusätzlichen Informationen eignet. Eine weitere Parametrierungsarbeit ist die Übernahme des geplanten Workflows für die Gesamtanlage. Die Grundlagen hierzu wurden schon in der Projektierungsphase erstellt. Bei der Realisierung werden diese Grundlagen übernommen und eventuell noch einmal leicht modifiziert, damit die Transportkapazität der Anlage ein Optimum erreicht. Sind alle für das Projekt notwendigen Entitäten konfiguriert, können diese in das Agentenframework eingesetzt werden. Damit ist das fördertechnische Anlagenlayout in eine funktionstüchtige Anlage umgesetzt worden. Für den Alltagsbetrieb werden aber noch weitere Funktionalitäten benötigt, wie zum Beispiel Statistiken. Viele Entitäten werden interne Möglichkeiten aufweisen, Daten über die Anzahl der transportierten TE zu protokollieren, Betriebsstunden der Fördertechnik zu erfassen und/oder Störungs- und Stillstandszeiten zu ermitteln. Alle diese Daten können zusammengeführt werden und ergeben so eine Gesamtstatistik für die Anlage. Sehr ähnlich wird auch der Prozess für die Zusammenstellung der Visualisierungsinformationen sein. Jede Entität stellt auch ihre internen Informationen für die Gesamtvisualisierung zur Verfügung. Statistik und Visualisierung haben somit im „Internet der Dinge“ einen aus den Entitäten und der in der Projektierung erstellten Topologie abgeleiteten, standardisierten und parametrierbaren Umfang. Wünscht ein Kunde darüber hinausgehende Auswertungen oder Anzeigen, so werden diese zusätzlichen Wünsche projektspezifisch in der Teilphase der Programmierung erstellt. Das Customizing wird im Internet der Dinge nicht nur auf die kundenorientierten Projektbedürfnisse bezogen. Auch auf Seiten des Anlagenherstellers gibt es Bereiche, in denen eine Konfiguration vorgesehen ist. Typisch für eine solche Konfiguration ist der Fernwartungszugang für die Anlage. Die meisten Kunden haben ein standardisiertes Vorgehen, das angibt, wie der Netzwerkzugang von externer Stelle vonstatten zu gehen hat. Demzufolge muss auf Herstellerseite der Supportzugang konfiguriert werden. Eine ganz andere Art der Konfiguration wird für die werksinternen Produktions- und Inbetriebnahmeschritte von mechatronischen Entitäten benötigt. Intelligente Steuerungselemente wie Regler, Scanner, Waagen und parametrierbare Sicherheitseinrichtungen benötigen eine Anpassung an die projektspezifische Situation. Die Gerätehersteller stellen dafür produktspezifische Softwaretools zur Verfügung. Die projektbezogenen Anpassungen erfolgen mit diesen Tools meist über Parameterlisten. Diese Listen sind ein Bestandteil der additiven Komponenten der Entitäten und müssen dementsprechend auch an die Projektsituation angepasst werden. Werden innerhalb einer Entität Steuerungselemente verwendet, welche über ein Bussystem miteinander verbunden sind, so muss auch das interne Bussystem konfiguriert werden.

19.4  Programmierung Auch ein noch so gut entwickelter und gepflegter Baukasten wird einen Anlagenhersteller nicht in die Lage versetzten, alle bisherigen und zukünftigen Kundenbedürfnisse lückenlos abzudecken. Der Aufwand für einen Baukasten, welcher diesem

206

C. Nieke und M. Henk

Anspruch gerecht wird, wäre so groß, dass der Erstellungsaufwand bei Weitem den Nutzen überschreiten würde. Die individuellen Wünsche der Kundschaft tragen zusätzlich dazu bei, dass es in jedem Projekt noch einen restlichen Anteil Programmierarbeit geben wird. Bei der Konzeption des „Internets der Dinge“ wurden diese Tatsachen von Anfang an mit berücksichtigt. Es sei an dieser Stelle noch einmal in Erinnerung gerufen, dass die überwiegende Programmierarbeit schon bei der Erstellung der Entitäten für den Baukasten erbracht wird. Die restliche projektbezogene Programmierung hängt in dieser Teilphase der Realisierung nur noch von den konkreten Bedingungen des Projektes ab. Wie groß der gesamte Programmieraufwand in einem Projekt sein wird, lässt sich somit nicht pauschal sagen. In diesem Schritt müssen neben der Codegenerierung auch noch die additiven Bestandteile der Entität erstellt werden. Dies umfasst die gesamte Dokumentation der Entität. Die bei der Programmierung anfallenden Arbeiten können von ihrer Struktur her sehr unterschiedlich sein. Um trotz dieser Unterschiede das Vorgehen in der Phase der Programmierung verdeutlichen zu können, werden hier exemplarisch vier Teilbereiche betrachtet.

19.4.1  Neue mechatronische Entität bzw. neues Modul Ein neuer Agent für eine mechatronische Einheit wird dann programmiert, wenn ein Projekt nicht aus den vorhandenen Baukastenentitäten realisiert werden kann. Aus der Entitätenspezifikation werden die vorgesehenen physikalischen In-/Outputsignale verifiziert und dann übernommen. Diese Signale werden in der Middleware deklariert und stehen somit innerhalb der Agentensoftware zur Verfügung. Nach diesem Arbeitsschritt kann nun der neue Agent in der Entwicklungsumgebung erstellt werden. Für den weiteren Fortgang spielt es keine Rolle, ob erst die maschinennahen echtzeitbezogenen Funktionalitäten oder die funktionale Gesamtlogik der Entität mit Hilfe einer Hochsprache programmiert wird. Es ist sogar ein paralleles Arbeiten durch unterschiedliche Programmierer möglich. Daran schließt sich der Gesamttest der Entität innerhalb der Entwicklungsumgebungen an. Die erfolgreiche Absolvierung dieses Softwaretests ist die Grundlage für den Inhouse-Test oder, falls erforderlich, für weitere Tests zur Validierung.

19.4.2  Softwaretechnischer Dienst Ein Dienst ist eine Entität, die z. B. eine Kommunikation mit externen Systemen realisieren kann. Neben Kommunikationen fallen unter die Dienste auch alle projektspezifischen Sonderaufgaben und Optimierungen. Die aufwändigste Programmierungsarbeit erfolgt im Unterschied zur mechatronischen Entität bei einem Dienst in dem nicht echtzeitfähigen und somit hochsprachenorientierten Agententeil. Grundsätzlich sind aber auch Agenten mit einer Hardwareansteuerung

19 ������������������������������������������������������������������������������������� Der Lebenszyklus eines Internet der Dinge Materialf  lusssystems: Realisierung

207

vorstellbar, werden aber eher selten sein. Dies ist z. B. der Fall bei gewerkeübergreifenden projektspezifischen Störungshinweislampen, die nicht eindeutig einer mechatronischen Entität zugeordnet werden können. Durch die gekapselte Form der Agenten kann bei der Programmierung schon quasi gleichzeitig eine direkte Vorabtestung der Software vorgenommen werden. Besonders effektiv kann diese Parallelität aus Programmierung und Test bei externen Schnittstellen und Kommunikationen erfolgen, da üblicher Weise Simulatoren für die Fremdsysteme erstellt werden. Somit kann ein realistischer Test anhand dieser Simulatoren erfolgen. Eine weitere und etwas umfangreichere Programmierarbeit wird bei Diensten entstehen, welche Protokollierungs- und Statistikfunktionalitäten realisieren. Diese sind oftmals stark projektabhängig und müssen während der Projektlaufzeit auf Grund von veränderten Kundenwünschen angepasst werden. Bei den Programmiermethoden innerhalb eines Agenten macht das „Internet der Dinge“ keine Vorgaben. Jeder Hersteller kann weiterhin seine eigenen Standards verwenden. Gleiches gilt auch für die verwendete Programmiersprache (s. a. Kap. 11).

19.4.3  Visualisierung Die Vorstellungen und Ansprüche über den Grad und die Granularität einer Anlagenvisualisierung sind sehr unterschiedlich. Außer ein paar grundlegenden Empfehlungen für die Bildschirmgestaltung gibt es hier keine allgemeingültigen Standards. Wichtig ist dabei, dass der Kunde sich mit dem Grundlayout der Visualisierung anfreunden kann, welches über den Topologiemanager entstand ist. Ist dies nicht der Fall, so werden die Arbeiten an der Visualisierung sehr schnell extrem aufwändig. Im Normalfall sollten sich aber die Anpassungen in Grenzen halten. Eine Projektrealisierung ohne Anpassungen bezüglich der Visualisierung ist auch im „Internet der Dinge“ nicht realistisch. Durch die starke Projektabhängigkeit lässt sich auch hier der Aufwand generell nicht abschätzen. Durch die offene Systemarchitektur können alle Arten von zusätzlichen Visualisierungswünschen mit in ein Internet-der-DingeProjekt eingearbeitet werden. Ein Beispiel für eine Erweiterung der Visualisierung könnte sein, dass live Videobilder der Anlage mit in die Visualisierung eingeblendet werden. Für die Datenaufbereitung und die Steuerung der Kameras wird ein eigener Agent erstellt. Dies hätte den Vorteil, dass er nach den allgemeinen Kommunikationsregeln des Agentenframeworks in das System integriert werden kann.

19.4.4  Sicherheitskreise Die Sicherheitstechnik nimmt in jedem intralogistischen Projekt einen immer größer werdenden Stellenwert ein. Diese Anforderungen sind heute meist durch entsprechende diskrete Schaltungstechnik realisiert. Es lässt sich aber ein Trend feststellen, dass in Zukunft diese Funktionalitäten analog zu einer SPS auf ent-

208

C. Nieke und M. Henk

sprechenden Auswertegeräten programmiert werden. Hierfür bieten fast alle SPSHersteller entsprechende fehlersichere Geräte an. An diese Geräte werden dann die sicherheitsrelevanten Geber angeschlossen und geräteintern logisch mit einer Software verknüpft. Weiterhin stellen die Geräte entsprechende Ausgangssignale bzw. Kontakte und Statusinformationen für die übergeordnete Steuerungslogik zur Verfügung. Die gesamte Sicherheitslogik ist dabei für jedes Projekt neu zu erstellen.

19.5  H  erstellung einer mechatronischen Entität  bzw. eines Moduls Bei der Herstellung eines Internet-der-Dinge-Moduls geht es um den steuerungstechnischen Anteil eines Förderelementes. Der mechanische Aufbau des Förderelementes wird dabei als vorhanden vorausgesetzt. In einem der vorhergehenden Unterpunkte wurden schon die für die Programmierung notwendigen Arbeitsschritte beschrieben. Aus diesem Grund geht es nun in diesem Teil der Realisierung nur noch um die Herstellung der eigentlichen elektrischen Steuerung. Zentral sind dabei die Erstellung der elektrischen Hardwareverdrahtung und die Dimensionierung der Schaltelemente. Diese Arbeit wird sich von dem heutigen Vorgehen dahingehend unterscheiden, dass jede mechatronische Entität eine eigene Stromeinspeisung und einen Netzwerkanschluss benötigt. Dies ist die Konsequenz aus der grundlegenden Entitätsdefinition im Internet der Dinge. Alle anderen Erstellungsarbeiten bezüglich der elektrischen Steuerungstechnik werden sich nicht wesentlich von der heutigen Art und Weise unterscheiden, wie Modulsteuerungen hergestellt werden. Es können somit vorhandene Schaltpläne, eventuell mit leichten Modifizierungen, zu einem großen Teil übernommen werden. Bei der Auswahl eines geeigneten Automatisierungsgerätes für die Entität sind zwei Varianten möglich. 1. Hat die Entität eine eigene Rechnereinheit für den Softwareagenten, so können Kleinsteuerungen direkt im Schaltschrank der Entität mit eingebaut werden. Soll der Softwareagent auf einer Recheneinheit außerhalb der Entität mit anderen Agenten zusammen laufen, so muss eine entsprechende datentechnische Verbindung z. B. Profibus zu den Sensoren und Aktoren eingeplant werden. 2. Sind die Schaltschränke gebaut, können diese am Modul befestigt werden. Die Verkabelung der Sensoren und Aktoren kann daraufhin erfolgen. Die nun folgenden Arbeitsschritte unterscheiden sich kaum von den bisherigen. Die Voreinstellung der Sensoren und Aktoren sowie ein Check der digitalen In-/Outputsignale sind hierbei gewohnte Arbeitsschritte. Das gleiche gilt auch für die Inbetriebnahme entitätsinterne Feld- und Steuerungsbusse. Schließlich wird noch die Sicherheitstechnik verdrahtet und getestet.

19 ������������������������������������������������������������������������������������� Der Lebenszyklus eines Internet der Dinge Materialf  lusssystems: Realisierung

209

19.6  Inhouse-Test Bei mechatronischen Entitäten mit eigener Rechnerhardware wird die Software direkt auf das Automatisierungsgerät aufgespielt. Die Entität kann dann komplett in Betrieb genommen werden. Alle Sensoren werden feinjustiert und intelligente Steuerungselemente wie z. B. Antriebsregler eingestellt. Daraufhin erfolgt die zeitliche und funktionale Optimierung des Zusammenspiels von Sensoren und Aktoren. Stehen projekttypische Transporteinheiten zur Verfügung, können auch alle funktionellen Teilabläufe innerhalb der Entität unter realen Bedingungen getestet werden. Da weiterhin auch alle sicherheitstechnisch relevanten Tests und die Funktionstüchtigkeit von Notabschaltungen getestet werden können, kann die Entität sowohl mechanisch wie auch elektrisch abgenommen werden. Die Erstellung von Zertifikaten wie z. B. die CE-Erklärung können nach dem ausgeführten Inhouse-Test für die Entität ebenfalls schon erfolgen. Die Entität ist damit komplett funktionstüchtig zur Auslieferung und Montage bereit. Etwas anders stellt sich der Inhouse-Test dar, wenn keine fördertechnische Mechanik zur Verfügung steht. Dies ist der Fall, wenn die Mechanik von einem anderen Hersteller produziert und direkt zum Kunden transportiert wird. Für den Inhouse-Test kommt dann wieder die Möglichkeit der Emulation zum Tragen, wie es schon in den vorigen Kapiteln beschrieben wurde. Alle anderen Arbeitsschritte zur Zusammenführung von Mechanik und Agentensteuerung müssen in diesem Fall vor Ort beim Kunden oder beim Hersteller der Mechanik stattfinden. Unabhängig von den mechanischen Gegebenheiten kann im Inhouse-Test auf der Basis der Emulation die Gesamtfunktionalität der Anlage vor der Auslieferung überprüft werden. Hierdurch zeigt sich für jedes Projekt, dass die in den vorhergehenden Phasen des Lebenszyklus festgelegten Funktionalitäten und Durchsatzleistungen auch real erreicht werden können. Für jeden Schlüsselpunkt lässt sich verifizieren, ob die Steuerung sich so verhält, wie dies gewünscht wird. Erweitert man das Testvorgehen um Situationen mit Störungen oder Überlastungen von Teilbereichen der Transportanlage, so lässt sich auch eine Aussage über die Robustheit und Flexibilität der Anlage machen. Die Statistikfunktionalitäten und die deterministischen Systemeigenschaften des Internet der Dinge bieten hier eine fundierte Basis für qualitative und quantitative Aussagen. Betrachtet man alles zusammen, dann trägt der Inhouse-Test wesentlich zur der im „Internet der Dinge“ erwarteten Verkürzung der gesamten Projektlaufzeit bei. Gleichzeitig wird aber auch eine Qualitätssteigerung erreicht, wie sie bisher nicht zu realisieren ist.

19.7  Dokumentation Das Thema Dokumentation wurde schon bei der Realisierung der einzelnen Entitäten und in den Planungsphasen behandelt. In der Realisierungsphase müssen diese Teildokumentationen nun zusammengeführt werden. Es entsteht dadurch

210

C. Nieke und M. Henk

eine Gesamtdokumentation für das Projekt, die noch um projektspezifische Teile ergänzt werden muss. Diese Gesamtdokumentation kann im Idealfall auch schon die Berichte aus dem Inhouse-Test beinhalten. Daran anschließend werden noch alle rechtlich erforderlichen Abnahmeprotokolle für die Gesamtanlage erstellt (z. B. GMP Protokolle, usw.)

19.8  Montage Die Montage ist der letzte wichtige Teilbereich innerhalb der Realisierungsphase. Dieser Bereich wird sich durch das „Internet der Dinge“ ebenfalls stark verändern. Durch die Modulhaftigkeit des Internet der Dinge bietet es sich an, beim Kunden die Montage entitätsbezogen vorzunehmen. Dies bringt wesentliche Vorteile im Baustellenablauf gegenüber der heutigen sehr sequenziellen und stark aufeinander aufbauenden Arbeitsweise. Am stärksten wird diese Vorgehensweise unterstützt, wenn bei der Herstellung der Entitäten ein mechatronischer Ansatz verfolgt wird. Eine Auflistung aller vorhandenen Entitäten und die Darstellung der Topologie stellen schon fast eine Art Montageplan dar. Es wird lediglich eine zeitliche Koordinierung der einzelnen Aufbauschritte benötigt. Jede Entität kann eigenständig montiert und in Betrieb genommen werden. Sind die Sensoren durch den Transport leicht verstellt, ist nur noch eine Nachjustierung erforderlich. Ansonsten wird jede Entität direkt an die Stromversorgung und das Netzwerk angeschlossen. Als letztes muss noch der Signalaustausch für die Sicherheitsabschaltungen und Notausketten mit den direkt benachbarten Entitäten installiert werden. Die Funktionstüchtigkeit jeder Entität kann sofort hergestellt werden. Bilden mehrere Entitäten eine funktionale Einheit, so kann dieser Anlagenteil im gesamten getestet werden. Die nachfolgende Inbetriebnahmephase wird wesentlich entlastet. Dies wird in dem nachfolgenden Kapitel noch detailliert beschrieben. Die in diesem Kapitel gemachten Ausführungen spiegeln die Vielfalt der in dieser Phase möglichen Arbeiten wieder. Dabei darf man sich nicht von dem Gedanken leiten lassen, dass alle erwähnten Arbeiten bei jedem Projekt vonnöten sind. Bei einer guten Baukastenqualität wird in einem Internet-der-Dinge-Projekt nur ein kleiner Teil der Arbeiten notwendig sein. Grundsätzlich wird man aber nicht ganz auf die Programmierarbeit verzichten können. Dies hängt mit den individuellen Wünschen der Kunden zusammen. Das „Internet der Dinge“ hat von seiner Grundkonzeption her viele Eigenschaften und Methoden, welche die Arbeiten in diesem Bereich wesentlich vereinfachen und beschleunigen. Die über alle Bereiche des Lebenszyklus integrierte Simulation/Emulation bewirkt besonders in der Realisierung, dass diese Projektphase schneller und effizienter abgeschlossen werden kann.

Kapitel 20

Der Lebenszyklus eines Internet der Dinge Materialflusssystems: Inbetriebnahme   und Hochlauf Andreas Trautmann und Alfred Lanfer

Das fortwährende Streben nach Effizienz erfordert die Erhöhung der Produktivität über den gesamten Lebenszyklus materialflusstechnischer Anlagen. In der Vergangenheit hat sich gezeigt, dass der kritische Faktor für den erfolgreichen Einsatz und Betrieb, einer fördertechnischen Anlage, deren Inbetriebnahme ist. Hersteller wie Anbieter unternehmen deshalb große Anstrengungen um Zeit, Kosten und vor allem das Risiko der Inbetriebnahme zu minimieren. Gleichzeitig erhöht sich der Grad der Komplexität durch die Verknüpfung von Mechanik, Elektronik und Software im Internet der Dinge kontinuierlich. Um trotzdem die Test- und Inbetriebnahmephase weiter zu verkürzen, müssen parallel zur Entwicklung neuer Anlagen- und Steuerungskonzepte geeignete Inbetriebnahmekonzepte entworfen werden, die in den vorangegangenen Kapiteln beschriebene Dezentralisierung und den stärkeren Vernetzungsgrad der Entitäten und Module berücksichtigen.

20.1  Referenzanlage Die technischen Grundlagen des Internets der Dinge wurden im Teil II beleuchtet. Um die Frage zu beantworten, wie sich die entwickelten Konzepte in einer realen Anlage verwirklichen lassen, sind mehrere Demonstrationsanlagen (vgl. Teil IV) umgesetzt worden. Merkmal dieser Umsetzung war vor allem die hohe Beteiligung von wissenschaftlichen Mitarbeitern der im Verbundprojekt Internet der Dinge des Bundesministeriums für Bildung und Forschung beteiligten Forschungsinstitute. Um nach dem Beweis der technischen Machbarkeit auch Aussagen über die spätere Realisierung durch Unternehmen aus der Intralogistik-Branche zu gewinnen, wurde die in Abb. 20.1 gezeigte Anlage geplant und wird aktuell durch Mitarbeiter der beteiligten Partnerfirmen in Betrieb genommen.

A. Trautmann () Geschäftsführer, LinogistiX GmbH Mallinckrodtstr. 320, 44147 Dortmund, Deutschland e-mail: [email protected] W. Günthner, M. ten Hompel (Hrsg.), Internet der Dinge in der Intralogistik, DOI 10.1007/978-3-642-04896-8_20, © Springer-Verlag Berlin Heidelberg 2010

211

Abb. 20.1   Referenzmodell einer fördertechnischen Anlage (l) und Anordnung der RFID Controller bzw. Antennen (r)

212 A. Trautmann und A. Lanfer

20  Der Lebenszyklus eines Internet der Dinge Materialfluss­systems

213

Die Förderstrecke besteht aus drei Kreisläufen, die untereinander mit Weichen bzw. Umsetzern verbunden sind. Jeder Kreislauf besteht aus mehreren bidirektionalen Rollenbahnen, je einem Controller und RFID-Systemen. Jedes Rollenbahnen-Element ist mit Lichtschranken ausgestattet, um das Einfahren, Verweilen und Ausfahren eines Behälters auf der Rollenbahn zu erkennen. Des Weiteren sind auf den Kreisläufen Entnahme-, Zuführungs- und Bearbeitungspunkte verteilt. Auf der Anlage lassen sich verschiedene Szenarien zeigen. Im einfachsten Szenario muss ein Behälter zum Platz „A“ und anschließend zum Platz „B“ gefördert werden. Im Anschluss erfolgt eine Gewichtskontrolle. Ist das Gewicht innerhalb der Toleranz, fährt der Behälter zum Ausschleuse-Punkt „F“, ansonsten zum NIO Punkt „E“. Ergänzend zu diesem Szenario wird ein Störfallszenario definiert, indem der Querförderer von Weiche W3 ausfällt. Der Behälter muss also den Weg von Platz „A“ nach Platz „B“, z. B. über die Weichen „W2“ und „W4“, nehmen. Weitere Szenarien berücksichtigen das Ausweichen von Behältern mit identischen Zielen sowie das Adhoc-Umdefinieren von Arbeitspunkten. Durch den durchgängigen Einsatz von bidirektionalen Förderelementen erlaubt die Anlage, trotz der kompakten Bauweise, ein Höchstmaß an Bewegungsvarianten und Alternativrouten. Diesbezügliche Fragestellungen werden an anderer Stelle in diesem Buch behandelt (vgl. Abschn. 7.2). In den folgenden Abschnitten wird vordergründig der Aspekt der Inbetriebnahme eines solchen Systems dargestellt. Dazu wird zunächst das Phasenkonzept der konventionellen Inbetriebnahme um ein inkrementelles Inbetriebsetzen und Testen auf Entitäten- bzw. Modulebene erweitert. Zielsetzung dieses Vorgehens ist die Reduzierung der Zeit, der Kosten und vor allem des Risikos bei der Inbetriebnahme.

20.2  Phasen der konventionellen Inbetriebnahme Die klassischen sieben Phasen der Inbetriebnahme umfassen im Regelfall: Phase 1 Prüfung auf Vollständigkeit: Die Installation wird durch Inaugenscheinnahme auf Vollständigkeit und Richtigkeit kontrolliert. Phase 2 Elektrische Inbetriebsetzung: Die elektrischen Einrichtungen werden unter Spannung gesetzt und auf Korrektheit geprüft. Phase 3 I/O Tests: Die zum Modul gehörigen Feldgeräte, Aktoren und Sensoren werden auf I/O Ebene auf Funktion getestet. Phase 4 Inbetriebsetzung und Funktionstests: Die Automations- und Steuergeräte werden abschnittsweise und-/oder gewerkeweise in Betrieb gesetzt und losgelöst voneinander auf spezifikationsgemäßes Funktionieren getestet. Getestet wird vorwiegend im Handbetrieb. Phase 5 Integrationstest: Das Zusammenspiel der Gewerke und Abschnitte wird im Gesamtprozess getestet. Wichtig ist das Durchlaufen vorher festgelegter Szenarien, die neben dem „Gutlauf“ insbesondere Störfälle berücksichtigen. Getestet wird vorwiegend im Automatikbetrieb.

214

A. Trautmann und A. Lanfer

Phase 6 Sicherheitstests: Es finden abschließende Tests von sicherheitsrelevanten Funktionen wie Not-Aus, Not-Halt oder das Schließen von Brandschutzklappen statt. Getestet wird vorwiegend im Sonderbetrieb. Phase 7 Abnahme: Grundlage der Abnahme ist der ordnungsgemäße und fehlerfreie Durchlauf der vorherigen Phasen. Mit der Abnahme durch den Kunden, gemäß eines vorher festgelegten Protokolls, geht die Erfüllung des Werkvertrages einher.

20.3  Inkrementelle Inbetriebsetzung im Internet der Dinge Das inkrementelle Vorgehen sieht im Gegensatz zum klassischen Konzept, in dem alle Schritte an der Gesamtanlage − von der Prüfung auf Vollständigkeit über die elektrische Inbetriebsetzung, Signal-/ Funktions-/ Integrations- und Sicherheitstests bis zur Abnahme − sequentiell durchlaufen werden, ein Durchlaufen der Phasen 3–5 für einzelne Module und Modulgruppen vor. Grundgedanke ist es, die vor Ort nur unter hohem personellen Einsatz durchzuführenden funktionalen und integrativen Tests zeitlich und örtlich zu verlagern, so dass die Tests während der EngineeringPhase beim Anlagenhersteller durchgeführt und abgeschlossen werden können. Die dafür notwendigen technischen Voraussetzungen werden ausführlich im nächsten Kapitel beleuchtet. Vor der Inbetriebnahme beim Hersteller werden nun folgende Schritte (s. Abb. 20.2) iterativ und inkrementell durchlaufen: Elektrische Inbetriebsetzung des Moduls: Die elektrischen Einrichtungen wer­ den unter Spannung gesetzt und auf Korrektheit geprüft. I/O Tests: Die zum Modul gehörigen Feldgeräte, Aktoren und Sensoren werden auf I/O Ebene auf Funktion getestet. Funktionstests des Moduls: Die Automations- und Steuergeräte eines Moduls werden in Betrieb gesetzt und auf spezifikationsgemäßes Funktionieren getestet. Getestet wird vorwiegend im Handbetrieb. Diese Schritte werden für andere Module wiederholt. Ist eine Gruppe materiaflusstechnisch verbundener Module auf diese Weise getestet, kann ein übergreifender Teil-Integrationstest erfolgen. Das Zusammenspiel der Module wird in einem Teilprozess getestet. Auch hier müssen insbesondere Störfälle definiert und getestet werden. Um im Automatikbetrieb zu testen ohne die mechanischen Anlagenkomponenten aufbauen zu müssen, kommt die Methode der Emulation zum Einsatz. Zur eigentlichen Inbetriebnahme werden die, so vorab getesteten und später installierten, Komponenten wie gewohnt auf Vollständigkeit geprüft. Auch die elektrische Inbetriebsetzung vollzieht sich ohne Änderung. Danach allerdings reduziert sich der Aufwand zum Testen drastisch. Nach einfachen und bestandenen Initialisierungstests kann mit einem hohen Maß an Sicherheit davon ausgegangen werden, dass die Anlage im Gesamtablauf spezifikationsgemäß funktioniert. Abschließende Sicherheit gibt ein letzter Gesamt-Integrationstests, der wiederum mit deutlich geringerem Zeitaufwand als bei der konventionellen Methode durchgeführt werden kann.

215

20  Der Lebenszyklus eines Internet der Dinge Materialfluss­systems Inkrementell & iterativ

Testen Off-Site

Elektrische Inbetriebsetzung

Phase 1 Prüfung auf Vollständigkeit z.B. 2 Wochen

z.B. 3-8 Wochen

Phase 4 Inbetriebsetzung und Funktionstests

Inbetriebsetzung und Funktionstests

Phase 1 Prüfung auf Vollständigkeit

Phase 2 Elektrische Inbetriebsetzung

Phase 3 I/O Tests

I/O Tests

TeilIntegrationstest

Phase 5 Integrationstest

Phase 2 Elektrische Inbetriebsetzung und Initialisierungstests Phase 3 Gesamt-Integrationstest Phase 4: Sicherheitstests Phase 5 Abnahme

Phase 6: Sicherheitstests Phase 7 Abnahme

Abb. 20.2   Phasen der klassischen IBS (l) und inkrementelle IBS im Internet der Dinge (r)

Die Sicherheitstests hingegen dürfen nur im Gesamtzusammenhang an der realen Anlage durchgeführt werden und vollziehen sich ohne weiteres Optimierungspotenzial.

20.4  Technische Voraussetzungen Wesentliche Bausteine dieses Inbetriebnahme-Konzepts sind die Verfügbarkeit einer standardisierten Laufzeitumgebung und Infrastruktur, der Einsatz wiederverwendbare Komponenten, hinreichend gute Diagnosemöglichkeiten sowie der Einsatz der Emulation zur virtuellen Vor- und Teilinbetriebnahme.

216

A. Trautmann und A. Lanfer

20.4.1  Standardisierte Laufzeitumgebung und Infrastruktur Multiagentensysteme stellen verteilte Anwendungen dar, welche besondere Anforderungen an die Skalierbarkeit und die Komplexität der Zusammenarbeit zwischen den verschiedenen Agenten stellen. Agenten können prinzipiell auf unterschiedlichen Hardware-Plattformen ablaufen, vom vollwertigen Server bis zum eingebetteten System. Für die Referenzanlage wurde konsequent auf den Einsatz gleicher Controller geachtet. Diese zeichnen sich durch ein offenes Betriebssystem aus (Linux). Es können sowohl C/C++ als auch Java Programme zur Ausführung gebracht werden. Darüber hinaus wird eine echtzeitfähige Soft-SPS angeboten. Um die Durchgängigkeit der Entwicklungswerkzeuge (Tooling) und Programmiersprachen zu erhalten, wird im Referenzprojekt jedoch weitestgehend die Java Unterstützung genutzt. Abbildung 20.3 zeigt die Architektur innerhalb eines Controllers. Auf dem Controller läuft mindestens eine Abstraktionsschicht (udc/cp) zur Implementierung von steuerungsnaher Agentenfunktion in Form von Schrittketten oder Zustandsautomaten (I/O Kommunikation). Jeder Controller verfügt darüber hinaus über einen oder mehrere Agenten mit höherer Logik (Routing, Kommunikation untereinander, Ereignisbehandlung). Diese Agenten können wahlweise auf dem Controller oder auf einem separaten Server ablaufen, da die Schnittstelle netzwerkfähig ist.

Multiagentensystem (JADE?)

Leitstand

WebServices (DPWS)

WebServices (DPWS)

HTTP

WebServices (DPWS) Abstraktionsschicht (udc/cp) JNI

KBusLib (JNI)

Abb. 20.3   Architektur innerhalb eines Controllers und Anbindung an einen zentralen Leitstand. Die Agenten können wahlweise auf dem Controller wie in der Referenzanlage realisiert oder auf einem separaten Server ablaufen

Echtzeitfähige Programme in C/C++ KBus S

Feldbus A

S

A

KBus S

A

20  Der Lebenszyklus eines Internet der Dinge Materialfluss­systems

217

Zur Anbindung an einen zentralen Leitstand verfügt jeder Controller über eine standardisierte Schnittstelle zur Übermittlung bzw. Erfragung von Statusinformationen.

20.4.2  Wiederverwendbare Komponenten Ein hohes Maß an wiederverwendbare Modulen und Softwarebausteinen ermöglicht es, den notwenigen Testaufwand insgesamt weiter zu reduzieren. Dazu müssen die Komponenten allerdings selbst zuverlässig und frei von Implementierungsfehlern sein. Das setzt voraus, dass jede Komponente (mit allen Konfigurationskombinationen) vor dem Einsatz ausgiebig getestet wurde. Der Grad der Wiederverwendung richtet sich dann nach: • Generalität der implementierten Funktion • Unveränderlichkeit der Komponente oder Möglichkeit der Parametrisierung • Objektorientierung (Datenkapselung) und einheitliches Objektmodell auf allen Modulebenen • Unabhängigkeit von Hardware oder Betriebssystem • Starker Zusammenhalt innerhalb der Komponenten, minimale Kopplungseffekte zwischen Komponenten • Verwendung eines einheitlichen Architekturmodells, integrierter Schnittstellen und die Verwendung einheitlicher Bussysteme auf Feldebene • Verwendung von Programmier- und Namenskonventionen

20.4.3  Diagnosemöglichkeiten und Monitoring Die Ursachenforschung für Störfälle oder unerwartete Betriebszuständen während der Inbetriebnahme ist in dezentralen Systemen schwieriger als in zentralen, weil zeitliche Abhängigkeiten und Ereignisreihenfolgen in Bezug zu dem Ergebnis der lokalen Entscheidungsintelligenz gesetzt werden müssen. In einem System, das den Eingriff in die Steuerung und Kontrolle des Materialflusses auf mehreren Modulebenen gestattet und nur einer sehr schwachen hierarchischen Ordnung unterworfen ist, besteht die zusätzliche Forderung an ein Monitoring, dass die befehlsgebenden Instanzen überwacht werden können. Es muss jederzeit überprüf- und nachvollziehbar sein, welche Instanz wann, welchen Befehl gegeben hat. Das Monitoring muss auf mehreren Ebenen stattfinden und dabei mindestens die Überwachung der: • • • • •

Artikel und Güter, Hardware, Instanzen, Controller und Schrittketten

7: Ziel gelesen

4: ID gelesen

Aktor (Weiche)

10: Weiche geschaltet

Reader (Lesegerat)

Abb. 20.4   Ablauf einer Schrittkette innerhalb von udc/cp und Beispiel einer Diagnoseausgabe

11: Weiche geschaltet

9: Weiche schalten

8: Ziel gelesen

6: Ziel lesen

5: ID gelesen

3: ID lesen

Trigger (Lichtschranke)

1: TriggerEvent

Device

2: TriggerEvent

Controller

218 A. Trautmann und A. Lanfer

20  Der Lebenszyklus eines Internet der Dinge Materialfluss­systems

219

komfortabel ermöglichen. Da das Debuggen in verteilten und nebenläufigen Anwendungen grundsätzlich schwierig ist und auf der verwendeten Hardware nur bedingt in Frage kommt, muss bei Bedarf die Auswertung eines Protokolls möglich sein. Dies wiederum erfordert eine Klassifizierung der verschiedenen Befehle und Nachrichten in zusammengehörenden Blöcken und eine Protokollierung der einzelnen Schritte (s. Abb. 20.4), um später die zusammengehörenden Schrittketten nachbilden und analysieren zu können. Auf der Ebene der hardwarenahen I/O Funktionen eignen sich DiagnoseSchalter. Diagnose-Schalter sind Variablen im Steuerungsprogramm, mit ihnen werden Protokollierungs-Funktionen ein- bzw. ausgeschaltet oder einmalig ausgeführt. Die Diagnosevariablen enthalten neben dem Ein-/Aus-Flag einen Namen, der im Programm einmalig festgelegt wird. Beim Booten der Steuerung werden die Diagnosevariablen in einer Liste eingetragen. Durch diese Liste können webbasiert die verfügbaren Diagnose-Schalter abgefragt und gesetzt werden. Bei Programmänderungen/-erweiterungen lässt sich die Diagnoseoberfläche aktualisieren. Die Bedienung erfolgt mit Hilfe eines Browsers. Auf Ebene der Agenten mit höherer Logik eignen sich Webservice-basierte Dienste, die das operationale Verhalten der Agenten wiedergeben und echtzeitnah durch eine zentralen Leitsysteminstanz (z. B. Siemens WinCC oder die Open Source Lösung Nagios) abgefragt werden können. Dies beinhaltet mindestens den Status der Entität. Vorgegebene Statuswerte sind: • ALIVE meldet, dass das zugehörige Gerät gerade überprüft wurde und fehlerfrei arbeitet. • NOREACTION zeigt an, dass das zugehörige Gerät auf eine Überprüfungsanfrage nicht oder fehlerhaft geantwortet hat. • NOTQUERYABLE wird zurückgeliefert, wenn das Gerät nicht abfragbar ist. • DEACTIVATED ist das Ergebnis einer Anfrage an eine Entität, die noch nicht initialisiert oder deaktiviert wurde. Darüber hinaus speichert jeder Agent eine Historie von logistischen Datensätzen, die erfassen, wer, also welcher Controller, wann welche Information von welchem Datenträger gelesen bzw. geschrieben hat.

20.4.4  Testen und Emulation Das Mittel der Emulation (vgl. Kap. 15) bietet die Möglichkeit der virtuellen Inbetriebnahme. Die Softwareagenten können einzeln und in ihrem Zusammenwirken vor der Inbetriebnahme ohne die mechanischen Komponenten getestet werden. Durch dieses Vorgehen werden Fehler bereits vor der eigentlichen Inbetriebnahme erkannt und kritische Anpassungen während der Inbetriebnahme an der bestehenden Anlage ausgeschlossen. Identische I/O-Schnittstellen für Emulationsmodell, physische Entität und die Abbildung eines hinreichend genauen Zeitverhaltens sind die Grundvoraus- setzungen

220

A. Trautmann und A. Lanfer

dafür. Eine Effizienzsteigerung lässt sich durch die Verwendung derselben MetaInformationensowohlfürdieSteuerungs-Agenten,alsauchderEmulationskomponenten erreichen. Dazu zählen beispielsweise XML kodierte Topologie-Informationen oder Workflowbeschreibungen. Im Sinne des inkrementellen Vorgehens bei der Inbetriebnahme von Anlagen im Internet der Dinge, können durch die gleichzeitige Verwendung von vorhandenen, realen Modulen und Emulationsmodellen für noch nicht vorhandene Module, Teilinbetriebnahmen durchgeführt werden. Um den damit einhergehenden Bruch in der physischen Durchgängigkeit zu „heilen“, sind in den Schrittketten-Komponenten der Agenten Steuervariablen-implantiert, die zur Simulation von I/O-Vorgängen dienen. So können virtuelle Behälter über reale Module geschleust werden und durch emulierte Module, um Transportaufträge durchgängig testen zu können. Der Einsatz der Teilinbetriebnahme ist dann sinnvoll, wenn aufgrund von zeitlichen Vorgaben und Lieferterminen oder einer hohen Anlagenkomplexität die Inbetriebnahme versetzt erfolgen muss.

20.5  Fazit Es wurde ein Inbetriebnahmekonzept vorgestellt, dass eine deutliche Reduktion der Inbetriebnahmezeit und des Risikos ermöglicht. Solch ein Konzept ist nicht auf das Internet der Dinge beschränkt. Tatsächlich wird es bereits heute erfolgreich von einigen Herstellern umgesetzt, wenn die Anlagenkomplexität hoch ist. Anlagen, die nach dem Prinzip des Internet der Dinge aufgebaut sind, eignen sich aber in besonderer Weise für eine Inbetriebnahme gemäß des vorgestellten Konzepts, da klare Modulgrenzen gegeben sind. Das Hilfsmittel der Emulation ist ebenfalls technisch erprobt und entsprechende Werkzeuge und Simulatoren sind am Markt verfügbar. Der Grad der Wiederverwendbarkeit der Komponenten hingegen ist noch nicht in dem Maße ausgereift, wie es technisch möglich ist. Demzufolge mussten bei der Inbetriebsetzung der Referenzanlage Komponenten erweitert werden. Es hat sich aber gezeigt, dass sehr wohl einige Komponenten aus den vorangegangen Implementierungen der Demonstrationsanlagen fast unverändert genutzt werden konnten. Erweitert werden mussten die Komponenten um die Fähigkeit der Diagnose und des Monitorings. Speziell an dieser Stelle ist die Erfahrung der Inbetriebnahmeerprobten Mitarbeiter der Hersteller in die Definition der Anforderung eingeflossen. Die in diesem Rahmen entwickelten Komponenten stehen nun für weitere Projekte zur Verfügung. Ein Punkt darf abschließend nicht unberücksichtigt bleiben: Da in der Referenzanlage alle notwendigen Funktionen (abgesehen von der Leitebene), die heute konventionell über die einzelnen Hierarchieebenen der Automatisierungspyramide verteilt sind, auf einem Gerät integriert sind, steigen die Anforderungen an die Qualifikation des Mitarbeiters. Wünschenswert wäre sicher ein Entwickler mit einer sehr hohen vertikalen Kompetenz, um alle auf dem Gerät befindlichen Komponenten zu

20  Der Lebenszyklus eines Internet der Dinge Materialfluss­systems

221

entwickeln. Da dies heute im Regelfall nicht gegeben ist, sind an der Entwicklung der Softwarekomponenten Mitarbeiter aus unterschiedlichen Fachgebieten gemeinsam beteiligt gewesen. In Form von Workshops und durch die gemeinsame Arbeit „auf einem Controller“ gelingt es, Grundlagenwissen über die fachfremde Disziplin zu vermitteln. In der Zukunft liegt aber sicher weiteres Optimierungspotenzial in der, entsprechend übergreifenden, Qualifikation der Mitarbeiter.

Kapitel 21

Der Lebenszyklus eines Internet der Dinge Materialf  lusssystems: Betrieb Jan R. Nopper

Selbstorganisierte, dezentrale Materialf  lusssysteme – das Internet der Dinge in der Intralogistik – können über den Lebenszyklus deutliche Vorteile gegenüber herkömmlichen, zentral gesteuerten Systemen aufweisen. Neben der durch den modularen Auf   bau der Steuerung erleichterten Inbetriebnahme ergeben sich auch Vorteile, die erst später zum Tragen kommen: Relevant sind dabei vor allem eine erhöhte F lexibilität bezüglich Änderungen und Erweiterungen, eine höhere Robustheit und die durch den Einsatz von RFID bedingte Verfügbarkeit von Echtzeitdaten über das System. Der vorliegende Beitrag geht nach einer kurzen Einführung auf diese Vorteile ein. Vor allem die erhöhte F lexibilität durch den modularen Auf bau der Steuerung verspricht deutliche Vorteile über den Lebenszyklus – für diese wird daher eine mögliche Bewertungsmethodik vorgestellt und erläutert.

21.1  Ü  berblick über Vorteile selbstorganisierter Materialf  lusssysteme im Lebenszyklus Selbstorganisierte Systeme versprechen über den Lebenszyklus eine Vielzahl von Vorteilen, insbesondere (vgl. Tab. 21.1) • eine erhöhte F lexibilität, • eine erhöhte Robustheit, • sowie Vorteile durch erhöhte Datenverfügbarkeit durch den Einsatz von RFID. Dabei wird in der Regel davon ausgegangen, dass die eigentliche logistische Leistungsfähigkeit des Systems – also Durchlaufzeit, Auslastung der Komponenten, Termintreue und Bestände bei gegebenem Durchsatz (Nyhuis 2006) – gegenüber einem herkömmlichen System unverändert bleibt. Hierauf wird im nächsten Abschnitt näher eingegangen. J. R. Nopper () Abt. Maschinen und Anlagen, Fraunhofer-Institut für Materialf  luss und Logistik IML Joseph-von-Fraunhofer Straße 2-4, 44227 Dortmund, Deutschland e-mail: [email protected] W. Günthner, M. ten Hompel (Hrsg.), Internet der Dinge in der Intralogistik, DOI 10.1007/978-3-642-04896-8_21, © Springer-Verlag Berlin Heidelberg 2010

223

224

J. R. Nopper

Tab. 21.1   Vorteile selbstorganisierter dezentraler Systeme auf Basis von RFID in der Intralogistik Vorteil Höhere F lexibilität, vereinfachte Integration und Inbetriebnahme bei Auf  bau, Umbau und Erweiterung

Höhere Robustheit

Erhöhte Datenverfügbarkeit, zusätzliche Services

Referenzen Jennings 2001; Jedermann et al. 2006; ten Hompel 2006; Arndt u. Müller-Christ 2007; Bullinger u. ten Hompel 2007; Scholz-Reiter u. Schulz 2007; Günthner et al. 2008a, b; Kohagen 2008; ten Hompel et al. 2008 Jedermann et al. 2006; Arndt u. Müller-Christ 2007; Bullinger u. ten Hompel 2007; Scholz-Reiter et al. 2007; Günthner et al. 2008a; ten Hompel et al. 2008 ten Hompel u. Lange 2004; Jansen u. Mannel 2007; Hellingrath et al. 2008; Windt 2008

21.2  Logistische Leistungsfähigkeit Die angenommene vergleichbare logistische Leistungsfähigkeit dezentraler, selbstorganisierter Systeme und herkömmlicher zentraler Steuerungen beruht im Wesentlichen auf der Erkenntnis, dass alle zentralen Algorithmen dezentralisierbar sind und umgekehrt. Diese Annahme wird allerdings teilweise hinterfragt. Sehr kritisch äußert sich zum Beispiel (Boone 2007). Er sieht für dezentrale Systeme die Gefahr möglicher Aufschaukelungseffekte – vergleichbar einem Schmetterlingseffekt – und eine mangelhaft praktische Implementierbarkeit selbstorganisierter Systeme. Beides wird allerdings nicht weiter ausgeführt, sondern lediglich qualitativ begründet. (Scholz-Reiter et al. 2005; Böse u. Windt 2007; Windt 2008) vermuten ebenfalls einen deutlichen Einf luss des Selbststeuerungsgrads auf die logistische Zielerreichung und schlagen einen Bewertungsansatz vor, mit dem die „Grenzen der Selbststeuerung“ in Abhängigkeit vom Komplexitätsgrad des Systems messbar gemacht werden sollen. Erste quantitative Untersuchungen deuten jedoch darauf hin, dass die angenommene vergleichbare Leistungsfähigkeit realistisch ist. So weisen (ten Hompel et al. 2008) in einer aufwändigen Simulationsstudie für ein Gepäckfördersystem eines Großf lughafens nach, dass die logistischen Leistungsparameter einer sehr einfachen dezentralen Steuerung vergleichbar mit entsprechenden dezentralen Steuerungen sind. (Nopper u. ten Hompel 2009) untersuchen am Beispiel eines Stückgutstetigfördersystems mit einem frei skalierbaren Manhattan-Layout den grundsätzlichen Zusammenhang zwischen der logistischen Leistungsfähigkeit, der Komplexität und den der Steuerung zur Verfügung stehenden Informationen über das System. Dabei zeigen sie, dass im Falle höherer Komplexität selbst der Leistungsunterschied zwischen extremen Grenzfällen kleiner als 10% ist (vgl. Abb. 21.1). Da dies dem maximalen Leistungsunterschied zwischen verschiedenen Steuerungsvarianten entspricht, ist der entsprechende Unterschied zwischen selbstorganisierten und herkömmlichen zentralen Systemen aller Voraussicht nach entsprechend kleiner.

21 �������������������������������������������������������������������������������� Der Lebenszyklus eines Internet der Dinge Materialf  lusssystems: Betrieb

225

ø Elementbelastung bezogen auf Gesamtdurchsatz

DLZ (s) 800

Obere Schranke (best case) Untere Schranke (worst case)

0.60

Obere Schranke (best case) Untere Schranke (worst case)

0.58

600

0.56 400 0.54 200

0

a

0.52

0

2

4

6 8 10 12 14 16 18 20 Anzahl der Weichen

0.50

b

0

2

4

6 8 10 12 14 16 18 20 Anzahl der Weichen

Abb. 21.1   Vergleich der Durchlaufzeit (a) und der durchschnittlichen Elementbelastung (b) in Abhängigkeit der Komplexität des Systems für zwei Grenzfälle bezüglich der der Steuerung zur Verfügung stehenden Informationen (Nopper u. ten Hompel 2009)

21.3  Q  uantifizierung und Bewertung der F lexibilität   von Materialf  lusssystemen Um eine erhöhte F lexibilität selbstorganisierter Systeme über den Lebenszyklus zu quantifizieren, kann auf umfangreiche Vorarbeiten aus der Literatur zurückgegriffen werden. Auf  bauend auf der Arbeit von (Slack 1983) wird F lexibilität in der Regel entlang der Kategorien F lexibilitätsart, Reichweite der Änderung (im Sinn möglicher Systemzustände) und Kosten/Zeitbedarf je Zustandswechsel definiert (vgl. z. B. auch Sethi u. Sethi 1990; Upton 1994; Chryssolouris 1996; Möller 2008). Slack (1983) beschreibt eine hohe F lexibilität eines Systems (oder ein hohes ‚F lexibilitätsange­ bot des Systems‘) als einen geringen Widerstand gegen Änderungen. (Heinecker 2006; Wilke 2006) schlagen für die Intralogistik Durchsatz, Layout und Fördergut als relevante F lexibilitätsarten vor. Damit ist bei einem Vergleich zweier Systeme bezüglich der F lexibilitätsart Durchsatz beispielsweise das System f lexibler, bei dem sich Änderungen des maximal möglichen Durchsatzes mit geringerem Aufwand realisieren lassen. Nach der Bestimmung der zu betrachtenden F lexibilitätsarten können die Vorteile f lexibler Systeme über den Lebenszyklus quantifiziert werden. Hierfür ist zunächst der prognostizierte Bedarf an Systemgröße für die zukünftige Lebensdauer des Systems abzuschätzen oder ein entsprechender Zeitraum aus der Vergangenheit zu analysieren. Anschließend sind für alle zu vergleichenden Systemvarianten folgende Kostenfunktionen zu bestimmen: • Investitionskosten in Abhängigkeit von der Änderung des Systems unter besonderer Berücksichtigung fixer Komponenten (z. B. notwendige Genehmigungen, Planungen),

226

J. R. Nopper

• Betriebskosten in Abhängigkeit von der Größe des Systems, sowie • Kosten, die durch zu geringe Systemgröße entstehen ( Stauungskosten oder congestion costs) Typisch für f lexible Systeme sind insbesondere geringere Fixkosten in den Investitionskosten im Vergleich zu weniger f lexiblen Systemen. Damit verursachen kleine Anpassungen des Systems bei f lexiblen Systemen deutlich weniger Aufwand. Anschließend können mit Hilfe einer dynamischen Optimierung für jedes zu vergleichende System die optimalen Anpassungszeitpunkte und – umfänge bestimmt werden und für diese jeweils die Lebenszykluskosten verglichen werden. Dabei zeigt sich, dass f lexiblere Systeme neben dem offensichtlichen Vorteil geringerer fixer Investitionskosten in der Regel folgende weiteren Vorteile aufweisen: • geringere Betriebskosten durch eine im Durchschnitt geringere Systemgröße, • geringere Stauungskosten, • geringere Investitionskosten bei Berücksichtigung von Zinseffekten durch spätere Investitionszeitpunkte, • „Versicherung gegen Unsicherheit“ – Systemanpassungen können vom entsprechenden Bedarf abhängig gemacht werden und basieren weniger auf der Güte von Prognosen Besonders vorteilhaft erweisen sich f lexiblere Systeme für dynamische Bedarfsänderungen sowie im Falle geringer Prognosegenauigkeit. Beides ist relevant für Materialf lusssysteme: So zeigt Abb. 21.2 beispielhaft die sehr dynamische Entwicklung des Passagieraufkommens am F lughafen München, die im Wesentlichen auch den Bedarf an Förderleistung der entsprechenden Gepäckförderanlage bestimmt. Die vorgestellte Methodik zur Quantifizierung von F lexibilität wurde am Fraunhofer Institut für Materialf luss und Logistik in Dortmund näher ausgearbeitet und wird in weiteren Schritten auf praktische Beispiele selbstorganisierter Steuerungen angewandt. Der erwähnte Vorteil selbstorganisierter, dezentraler Systeme wird deutlich bei einer Interpretation von F lexibilität als „geringer Widerstand gegen Änderungen“. Dieser ergibt sich für selbstorganisierte System beispielsweise durch • eine einfache Anpassung von Steuerungssoftware durch den modularen Auf bau („Plug&Play“), • ein sich hieraus ergebendes geringeres notwendiges Qualifikationsniveau beteiligter Mitarbeiter, • ein vereinfachtes Planungsverfahren durch Verwendung standardisierter Module, • eine einfachere Kombinierbarkeit von Modulen verschiedener Hersteller durch standardisierte Schnittstellen, sowie • ein vereinfachtes Genehmigungsverfahren („Musterzulassung“).   Dieser Vorteil f lexibler Systeme kann als eine Realoption betrachtet werden. Es gibt eine Vielzahl von Arbeit, die eine Quantifizierung von F lexibilität über Realoptionen vornehmen, z. B. (Möller 2008; Steffens 2003).

21 �������������������������������������������������������������������������������� Der Lebenszyklus eines Internet der Dinge Materialf  lusssystems: Betrieb

227

40.000.000

Passagieraufkommen

30.000.000

20.000.000

10.000.000

0 1950 1955 1960 1965 1970 1975 1980 1985 1990 1995 2000 2005 2010

Abb. 21.2   Gewerbliches Passagieraufkommen am F lughafen München (F lughafen München 2008)

Selbstverständlich sind diese Vorteile nicht nur für Erweiterungen und Umbauten relevant, sondern auch für entsprechende Wartungs- und Reparaturmaßnahmen, die durch die angestrebte Plug&Play-Fähigkeit ebenfalls deutlich vereinfacht werden.

21.4  Robustheit Im Zusammenhang mit selbstorganisierten Systemen ist ein Verständnis der Robustheit als ein definiertes Verhalten des Systems bei sich ändernden Umwelteinf lüssen zielführend. In diesem Sinne führt eine vollständige Beschreibung des Systemverhaltens zu einem robusten System, da stets eine definierte Reaktion ausgelöst wird. Dezentrale, selbstorganisierte Steuerungen erlauben durch den modularen Aufbau eine vereinfachte Implementierung robuster Steuerungsalgorithmen. So zeigen (ten Hompel et al. 2008), dass sich die Anzahl der für die Steuerung eines Gepäckfördersystems an F lughäfen notwendigen Codezeilen im Falle selbstorganisierter Systeme etwa um einen Faktor 10 verringern lässt. Das führt zu einer höheren Übersichtlichkeit der Steuerungssoftware (ten Hompel et al. 2008), die ein schnelleres Auffinden von Fehlern und eine Vereinfachung der heute sehr aufwändigen Tests verschiedener Steuerungsstrategien erlaubt. Die wesentlichen Umwelteinf lüsse, gegen die ein System im oben definierten Sinn robust sein kann, sind die Bereiche

228

J. R. Nopper

• Information/Bedienung (insbesondere Fehlinformationen) • Fördergut (z. B. Ladehilfsmittel, Verschmutzung) • Umwelteinf lüsse (z. B. elektrische Versorgung, Strahlung) Mögliche Vorteile selbstorganisierter Systeme hinsichtlich der Robustheit sind vor allem bezüglich der Bereiche Information/Bedienung sowie Umwelteinf lüsse leicht zu erkennen: so führt ein Stromausfall oder eine Fehlinformation an einer Stelle des Systems nicht zu einem umfangreichen Datenverlust, da wesentliche Daten direkt an den Objekten gespeichert sind. Wirtschaftlich kann sich so eine höhere Robustheit wie eine höhere Anlagenverfügbarkeit auswirken, da diese bei entsprechenden Fehlern nicht ausfällt oder schneller wieder zur Verfügung steht. Es ist möglich, Vorteile durch eine erhöhte Robustheit zu quantifizieren: Grundsätzlich sind dafür über den Lebenslauf die relevanten technischen Eigenschaften des Systems – also das ‚Robustheitsangebot‘ des Systems – zu bestimmen. Anschließend können diese mit dem Bedarf der Umgebung an die jeweilige Robustheitsart – dem ‚Robustheitsbedarf‘ – verknüpft werden. Letzterer ergibt sich aus der konkreten Anwendung, also beispielsweise der Häufigkeit von Ausfällen der Energieversorgung.

21.5  Datenverfügbarkeit und zusätzliche Dienstleistungen Dezentrale, selbstorganisierte Steuerungen in der Intralogistik basieren oft auf einem Einsatz von RFID-Tags am Fördergut. Obwohl dies keine zwingende Voraussetzung für die Realisierung dezentraler Steuerungen ist, können sich aus der hieraus resultierenden höheren Datenverfügbarkeit zusätzliche Vorteile ergeben. Die durch einen Einsatz von RFID entstehenden Kosten liegen jedoch in der Regel deutlich über den Kosten entsprechender Barcode-Kennzeichnungen. Die Quantifizierung der Kostenunterschiede bei der Realisierung selbstorganisierter Systeme in Folge unterschiedlicher Identifizierungstechnologien ist vergleichsweise einfach und sollte in einem ersten Schritt vorgenommen werden. Diese Komponente ist bei einer entsprechenden Wirtschaftlichkeitsberechnung in jedem Fall zu berücksichtigen, wobei gegebenenfalls eine unternehmensübergreifende Verwendung oder eine Mehrfachverwendung der Identifizierungstechnologie (‚closed loop‘) geeignet berücksichtigt werden müssen. Die Bewertung möglicher Vorteile durch eine erhöhte Datenverfügbarkeit ist dagegen in der Regel schwieriger (Hellingrath et al. 2008) und direkt von der entsprechenden Anwendung abhängig. In einem ersten Schritt sind mögliche Vorteile durch erhöhte Datenverfügbarkeit zu sammeln und hinsichtlich ihrer Auswirkungen auf die Lebenszykluskosten zu beurteilen. Bei unklarem Nutzenprofil und daraus folgender schwieriger Quantifizierbarkeit sollte der betrachtete Vorteil nicht weiter analysiert werden, was insgesamt einer tendenziell zu konservativen Bewertung selbstorganisierter Systeme entspricht. Das erscheint zulässig, da ein im Vergleich zu anderen Komponenten (z. B. im Vergleich mit der der erhöhten F lexibilität) geringer Vorteil durch erhöhte Datenverfügbarkeit wahrscheinlich ist.

21 �������������������������������������������������������������������������������� Der Lebenszyklus eines Internet der Dinge Materialf  lusssystems: Betrieb

229

Bei der Suche nach möglichen Vorteilen im Zusammenhang mit selbstorganisierten Materialf lusssteuerungen sind drei Bereiche näher zu prüfen (Jansen u. Mannel 2007) • Effekte auf der Prozessebene, z. B. erleichterte Kontrollvorgänge, geringere Inventurkosten, Diebstahlsicherheit. • Effekte auf der Netzwerkebene, z. B. verbesserte Prognosegüte, Weiterverwendung von RFID-Tags in vorgelagerten oder nachgelagerten Prozessschritten • Neue Umsatzmöglichkeiten, z. B. durch Weitergabe von Echtzeitinformationen

21.6  Fazit Durch den Einsatz selbstorganisierter, dezentraler Steuerungen für Materialf lusss­ ysteme – dem Internet der Dinge in der Intralogistik – lassen sich vielfältige Vor­teile über den Lebenszyklus erzielen. Hier erscheint vor allem die erhöhte Flexibilität vielversprechend. Für diese wurde am Fraunhofer-Institut für Materialf luss und Logistik eine Methodik zur Quantifizierung erarbeitet und auf verschiedene Materialf lusssysteme angewandt. Die sich ergebenden Vorteile hängen neben den technischen Eigenschaften des Systems auch entscheidend von den Parametern der Anwendung ab – insbesondere von der Dynamik der Bedarfsentwicklung und der Prognosegüte. Weitere Vorteile wie eine erhöhte Robustheit oder Verfügbarkeit von Daten über das System sind schwieriger zu quantifizieren, stellen jedoch in jedem Fall eine weiteren Zusatznutzen dar, der neben der F lexibilität zu weiteren Leistungs- und Kostenvorteilen im Lebenszyklus führen kann.

Kapitel 22

Der Lebenszyklus eines Internet der   Dinge Materialflusssystems: Umbau   und Modernisierung Alfred Lanfer und Andreas Trautmann

Viele Anlagenbetreiber sehen sich mit der Notwendigkeit konfrontiert, die Steuerung bestehender Hochregalläger oder Materialflusssysteme zu modernisieren. Auslaufende Herstellerwartungen für die eingesetzten speicherprogrammierbaren Steuerungen, veraltete Hardware für den Materialflussrechner und knapper werdende Ersatzteile sind eine hinreichende Motivation. Zielsetzung ist die reibungslose Migration auf den aktuellen Stand der Technik. Wie kann nun die Migration einer bestehenden Anlage auf den Stand des Internet der Dinge erfolgen? Wann ist dies sinnvoll? Antworten auf diese Frage werden in diesem Kapitel gegeben.

22.1  Erwartete Vorteile Die in Zukunft an intralogistische Anlagen gestellten Erfordernisse gehen weit über heutige leistungsfähige Anlagen auf Feldebene hinaus. Der vernetzte Warenfluss erfordert eine echte Synchronisation der intralogistischen Systeme mit Warenwirtschaftssystemen und Produktionssystemen. Ähnlich der Produktion erfolgen auch die Planung, das Engineering, die Inbetriebsetzung und der Umbau der entsprechenden Materialflussanlagen unter immer größerem Zeit- und Kostendruck. Da der Anlagenbetreiber vermehrt nach individuellen Anlagen verlangt, müssen Umbauarbeiten on Demand, und in Realtime beherrscht werden. Mithilfe intelligenter und modularer Mechatroniksysteme werden sich Modernisierungsprojekte und spätere Änderungswünsche schnell und flexibel umsetzen lassen. Die Vorteile, die das Internet der Dinge in diesem Zusammenhang bietet, sind an anderer Stelle in diesem Buch untersucht (vgl. Kap. 21). Die skizzierten Vorteile (vgl. Kap. 20) für die Inbetriebnahme, die mit der Verwendung standardisierter mechatronischer Komponenten und der digitalen Vernetzung zwischen mechanischer A. Lanfer () Geschäftsführer, Lanfer, Hoher Weg 13, 46325 Borken, Deutschland e-mail: [email protected] W. Günthner, M. ten Hompel (Hrsg.), Internet der Dinge in der Intralogistik, DOI 10.1007/978-3-642-04896-8_22, © Springer-Verlag Berlin Heidelberg 2010

231

232

A. Lanfer und A. Trautmann

Konstruktion und Steuerungstechnik einhergeht, gelten unverändert auch für die Inbetriebnahme im Rahmen eines Modernisierungsprojekts.

22.2  Anforderungen an den Umbau Stellt bereits die Inbetriebnahme hohe Anforderungen an den Engineering-Prozess, gilt dies für Modernisierungs- und Retrofitting Projekte in besonderer Weise, weil sich die Anlagen im operativen Betrieb befinden und ein Ausfall als unternehmenskritisch einzustufen ist. Eine Stillsetzung für einen längeren Zeitraum kommt in den meisten Fällen nicht in Betracht. Die Umbauarbeiten müssen demzufolge im Pa­ rallelbetrieb und/oder in betriebsarmen Zeiten, oft am Wochenende oder an Feiertagen, erfolgen. Ein Zurückschalten auf das alte Steuerungssystem muss jederzeit möglich sein, bei Sicherstellung von konsistenten Daten und Betriebszuständen, um das Anlaufen der Anlage zu ermöglichen. In der Vorbereitungsphase wird die neue Technik parallel zur bestehenden in den Schaltschrank installiert, ohne dass das bestehende System beeinflusst wird. Dies gilt für klassische Retrofitting Projekte (z. B. Modernisierung der Steuerung von Siemens S5 auf S7) ebenso wie für Retrofitting-Projekte, die eine Umsetzung des Internet der Dinge-Konzepts beinhalten.

22.3  Voraussetzungen und Checkliste zur Vorbereitung Ob ein Umbau einer vorhandenen Anlage auf eine Steuerung, die gemäß des Funktionsprinzips Internet der Dinge arbeitet, sinnvoll ist, hängt von vielen Faktoren ab. Diese Faktoren werden vorab in einer Agentifizierungs-Potentialanalyse untersucht. Zu den betrachteten Fragestellungen gehören: • Ist-Aufnahme der bestehenden Hardware und Steuerungstechnik • Soll-Anforderung des Kunden bezüglich der Modernisierung oder Weiternutzung der mechanischen Komponenten sowie der Energieversorgungs- und Signalleitungsinfrastruktur • Herausarbeitung neuer Anforderungen an das alte System durch Prozessänderungen oder erkannte Unzulänglichkeiten • Adaptivitätsgrad des vorhandenen Layouts • Neue Sicherheitsanforderungen • Detailliertes Umbaukonzept

22.3.1  Ist-Aufnahme Bei der Ist-Aufnahme wird die bestehende Hardware und Steuerungstechnik erfasst und beschrieben. Unerlässlich ist die Sichtung vorhandener Dokumentation. Diese umfasst typischerweise:

22 ����������������������������������������������������������������� Der Lebenszyklus eines Internet der Dinge Materialflusssystems

• • • • •

233

Schaltpläne (z. B. ePlan) Layoutpläne Wartungspläne, Fehlerprotokolle Last- und Pflichtenheft der einzelnen Gewerke Schnittstellendokumentation

In Workshops mit dem Anlagenbetreiber muss die vorhandene Dokumentation auf Konsistenz, Vollständigkeit und Aktualität geprüft werden. Es kommt durchaus vor, dass eine Dokumentation zwar vorhanden ist, aber nur den Stand zur Inbetriebnahme beschreibt und spätere Erweiterungen nicht nachgepflegt wurden. In diesem Fall (oder falls eine Dokumentation komplett fehlt), ist eine aufwändige Nachdokumentation erforderlich. Sind beispielsweise Schnittstellen zwischen Materialflussrechner (MFR) und Speicherprogrammierbarer Steuerung (SPS) nicht dokumentiert, muss über Werkzeuge zum Mitschneiden des Telegrammverkehrs Aufschluss über dessen Aufbau sowie die Bedeutung der einzelnen Telegramme und Datenfelder gewonnen werden. Für eine spätere Überlegung, ob die Anlage durch eine Internet-der-DingeSteuerung gesteuert werden soll, sind weiterhin das Alter und die Art der Sensoren, der Zustand der mechanischen Komponenten sowie das vorhandene Bussystem relevant. Ebenso gilt es nach der Modernisierung weiterbestehende Systeme zu identifizieren und deren Schnittstellen und Abhängigkeiten herauszuarbeiten. Positiv wirkt sich aus, wenn eine Modernisierung der Energieversorgungs- und Signalleitungsinfrastruktur unabhängig vom Steuerungskonzept notwendig ist. So wird beispielsweise kundenseitig oft eine Umstellung der Kommunikation auf Transmission Control Protocol / Internet Protocol (TCP/IP) ins Auge gefasst, auch wenn es sich um eine „konventionelle“ Modernisierung handelt. Ebenso vorteilhaft stellt sich das Antreffen von vorhandenen mechanischen Komponenten dar, die unverändert weitergenutzt und mit wenig Aufwand durch dezentrale Steuerungskomponenten ergänzt werden können.

22.3.2  Soll-Anforderungen Im nächsten Schritt werden die Anforderungen des Kunden untersucht. Je nach Projekt gilt es ein oder mehrere der folgenden Systeme zu modernisieren bzw. auszutauschen: • MFR • SPS • mechanische und elektrische Komponenten Ein Austausch des MFR wird oft motiviert durch veraltete Server-Hardware, deren Verfügbarkeit nicht mehr gewährleistet werden kann. Der Installationsaufwand eines neuen MFR klassischer Prägung ist dann gering, wenn lediglich Standardfunktionen, die in bereits am Markt erhältlichen MFR-Lösungen vorhanden sind, genutzt werden

234

A. Lanfer und A. Trautmann

können und nicht kundenspezifisch programmiert werden müssen. Die eigentliche Anpassung liegt dann in der Anpassung der Softwareschnittstellen zu anderen Systemen. Ein Austausch der SPS ist ähnlich motiviert, bedeutet aber häufig einen höheren Installationsaufwand, da mehr elektrische/signaltechnische Schnittstellen anzubinden sind und diese auf der SPS häufig kunden- bzw. projektspezifisch programmiert worden sind. Bei den mechanischen und elektrischen Komponenten ist eine häufig anzutreffende Anforderung der Austausch vorhandener Gleichstrommotoren gegen moderne Drehstrommotoren und der damit verbundenen Regelsysteme.

22.3.3  Prozessführung Ebenfalls zu Aufnahme der Anforderungen gehört eine Beschreibung der gewünschten funktionalen Erweiterungen. Oft ist es nicht ausreichend, den vorhandenen Funktionsumfang nachzubilden. Durch geänderte Prozesse und neue Anforderungen (z. B. Einführung und Rückverfolgbarkeit von Chargen) werden neue Funktionen auf Materialfluss-Ebene benötigt. Selbst wenn, die vom Altsystem angebotenen Funktionen ohne funktionale Erweiterung erhalten bleiben sollen, hat sich in den meisten Fällen durch die Erfahrung des Bedienpersonals im langjährigen Betrieb der Anlage, eine Wunschliste von Hilfsmitteln zur Fehlerdiagnose und deren Behebung gebildet, die für den operativen Betrieb als notwendig erachtet werden. In diesem Fall ist die Erstellung eines Lastenhefts erforderlich. Es ist gut möglich, dass das Konzept Internet der Dinge per se signifikante Prozessvorteile ermöglicht. Diese gilt es herauszuarbeiten. Für eine spätere Agentifizierungs-Potenzialanalyse müssen sämtliche Kundenanforderungen zunächst losgelöst vom späteren Realisierungskonzept betrachtet werden.

22.3.4  Layout Die Vorteile des Internet der Dinge liegen vor allem in einer hohen Anpassungs­ fähigkeit des Materialflusssystems. Um die steuerungstechnischen Möglichkeiten nutzen zu können, bedarf es flexibler Materialflussstrukturen. Deren Flexibilität manifestiert sich vor allem im Layout einer Anlage sowie der Anpassungsfähigkeit der einzelnen Module. Für den Bereich der Stetigfördertechnik bedeutet ein flexibles Layout vor allem die Möglichkeit der Pufferung und Speicherung (mit wahlfreiem Zugriff) von Transporteinheiten, sowie die Möglichkeit zwischen alternativen Routen für die gleiche Quelle-/Ziel-Relation auswählen zu können. Bezüglich der Anpassungsfähigkeit einzelner Stetigförder-Module ist beispielsweise zu unterscheiden, ob sie reversibel betrieben werden können und dies auch sinnvoll möglich ist. Hier bleibt festzuhalten, dass viele fördertechnische Anlagen heute solch eine Flexibilität nicht besitzen. Ausnahmen bilden komplexe Kommissioniersysteme mit Sorter-Funktionalität und natürlich die großen Gepäckfördersysteme (vgl. Kap. 4).

22 ����������������������������������������������������������������� Der Lebenszyklus eines Internet der Dinge Materialflusssystems

235

22.3.5  Sicherheitsanforderungen Bei einer Modernisierung ist zu klären, inwieweit neue Sicherheitsanforderungen zwingend berücksichtigt werden müssen. Bei bestehenden Anlagen kann zwar bedingt Bestandsschutz geltend gemacht werden, gerade das Not-Aus Konzept (z. B. Anzahl der Not-Aus Kreise) oder Maßnahmen zum Brandschutz sollten aber im Eigeninteresse des Betreibers im Rahmen der Modernisierung auf den neuesten Stand der Technik gebracht werden. Neben den gesetzlichen Bestimmungen und gültigen Verordnungen bietet auch das Richtlinienwerk der Deutschen Sachversicherer einen guten Anhaltspunkt.

22.4  Agentifizierung Kommt die Agentifizierungs-Potenzialanalayse zu einem positiven Ergebnis, umfasst die anschließende Agentifizierung typischerweise folgende Schritte: • Definition der Modulgrenzen und Entitäten (vgl. Kap. 8) • Identifizierung und Modellierung der Agenten mit einer geeigneten Modellierungssprache z. B. Unified Modeling Language (UML) • Geräteauswahl der Controller unter Berücksichtigung des Funktionsumfangs der einzelnen Module • Programmierung der Agenten • Inkrementelle Inbetriebnahme (vgl. Kap. 20) mit Funktionstest am Emulationsmodell • Sicherung des SPS-Programms der Alt-Steuerung und Vorbereitung für den Parallelbetrieb • Einbau der neuen Controller in der Anlage und signaltechnische Integration • Integrationstests Durch das Zurückschalten auf die Alt-Steuerung kann die Inbetriebnahme in mehreren Sequenzen erfolgen. Dadurch können einzelne Abschnitte über mehrere Wochenenden hinweg in Betrieb genommen werden. Länger andauernde Integrationstests können dadurch ebenfalls auf die zur Verfügung stehenden Zeitscheiben aufgeteilt werden. Zu beachten ist, dass vor dem Zurückschalten auf die Alt-Steuerung der erwartete, d. h. zuletzt gültige Anlagenzustand, wiederhergestellt wird. Das Vorgehen wird im Folgenden anhand einer Referenzanlage verdeutlicht.

22.4.1  Umbau einer Referenzanlage Im Rahmen des Verbundprojekts Internet der Dinge des BMBF und anderer Vorlaufprojekte wurde ein Umbauszenario an einer bestehenden Anlage (s. Abb. 22.1) definiert und umgesetzt. Der Fokus bezüglich der Teilsysteme liegt auf stationä-­ ren mechatronischen Komponenten und Modulen zur Stetigfördertechnik, wie sie

Reader

POST PICK

Reader

Reader

PREBUF

TURNTABLE

SWITCH BUF

PICKPOINT

Reader

Reader

SCALE

Reader

Reader

BUF1

BUF2

Abb. 22.1   Topologie der Umbauanlage mit Fokus auf dem Waage-Kreislauf (SCALE)

TO STORE

FROM STORE

Reader

BUF3

SORTER

SWITCH PICK Reader

236 A. Lanfer und A. Trautmann

22 ����������������������������������������������������������������� Der Lebenszyklus eines Internet der Dinge Materialflusssystems

237

insbesondere innerhalb von Kommissionieranlagen anzutreffen sind. Neben der Fördertechnik umfasste das Szenario einen Waage-Kreislauf (s. Abb. 22.2), Pufferstrecken und Ein-/Ausschleusstellen. Die gesamte Anlage wurde im Urzustand durch eine SPS gesteuert. Jetzt übernehmen neun RFID Schreib-/Lesegeräte die Steuerung der Anlage.

22.5  Technische Umsetzung Zunächst wurden für die bestehenden Anlage neue Modulgrenzen und Entitäten definiert (s. Abb. 22.3). Ausgehend von der in Kap. 2 beschriebenen Methode wurden daran anschließend die Agenten identifiziert und mit der Modellierungssprache UML modelliert. Ausgehend von dem Funktionsumfang der einzelnen Module erfolgte die Auswahl der Controller. Zur Steuerung der Weichen kommen integrierte Controller (s. Abb. 22.4) zum Einsatz, die neben dem Anschluss für die RFID Antenne, über einen webfähigen, frei programmierbaren Controller verfügen. Durch digitale Ein- und Ausgänge im Industriestandard übernehmen sie Steuerungsaufgaben, die sich aus den gelesenen RFID Daten ergeben. Weichen, Lifte und andere Aktuatoren werden so dezentral und autonom gesteuert. Innerhalb des Waagekreislaufs wurde ein Controller mit Linux-Betriebssystem eingebaut, der über eine 32 Bit RISC CPU, 4 MB Flash und 16 MB SDRAM verfügt. Unter Berücksichtigung der Leistungsfähigkeit der einzelnen Controller erfolgte die Programmierung der Agenten. Gemäß der in Kap. 20 beschriebenen inkrementellen Inbetriebnahme stand ein Emulationsmodell der Anlage zur Verfügung, an dem die Funktionstests der Agenten durchgeführt wurden. Daran anschließend erfolgte der Einbau der Geräte in die Anlage. Die Signaltechnische Anbindung erfolgte nun über ein Ethernet-Netzwerk mit Anschlussmöglichkeiten an jedem Installationspunkt. Die Geräte, die über keine EthernetSchnittstelle sondern über eine RS232-Schnittstelle verfügen, wurden mit einem RS232/Ethernet-Wandler ausgerüstet. Bis zu diesem Zeitpunkt waren die alte und neue Installation komplett separiert voneinander. Der nächste Schritt erforderte die Anbindung der vorhandenen Lichtschranken und Sensoren. Um einen Parallelbetrieb zu ermöglichen wurden die digitalen Eingänge der SPS dort belassen und zu den dezentralen Controllern durchgeschleift. Durch eine Erweiterung des SPS-Programms um einen Betriebsmodus Internet der Dinge, kann nun die Anlage per Schalter in den Automatik-Modus (ehemals Hauptbetriebsmodus) und den neuen Modus umgeschaltet werden. Vor den Änderungen des SPS-Programms wurde selbstverständlich ein Abzug des Orginalprogramms gezogen und konserviert, um bei Bedarf als Rückfalloption zu dienen. Nach bestandenen Integrationstests könnte nun die SPS durch eine einfache I/OKlemme ersetzt und ausgebaut werden.

238

A. Lanfer und A. Trautmann

SH81 E40.1 300

E51.0 Waage BB E51.1 Waage Ein

B161 E48.1

B160 E48.0

B177 E39.7

Waage 315

340

320

M K300: A5.1

Y340 auf: A9.3 330

B162 E48.2 322 M K322: A5.4

M K320: A5.3

B163 E48.3

B166 E48.6

Y322 auf: A9.4

332 M Y332 ab: A9.5

M K340: A5.6

B165 E48.5

K330: A5.5

B164 E48.4 B167 E48.7

E40.4 Steuerung Ein & kein NOTAUS E40.5 MSS Q300-Q350, FU350 BB E40.6 Druckluft OK E40.7 Automatik Ein

350

M B157 E47.7 A1.6 FT Bereit A7.3 FT BB

Skizze Kommisionierung E47.0 FTF Bereit E47.3 FTF Aufnehm.

A0.6 FU vor A1.7 FT nicht belegt A6.6 FT Aktiv

Abb. 22.2   Installationsskizze für den Waagen-Kreislauf

SH81 E40.1 IR1 Nr1 RFID 300

E51.0 Waage BB E51.1 Waage Ein

B161 E48.1

B160 E48.0

MRT-Fox

Waage

M K300: A5.1

Y340 auf: A9.3 330

B162 E48.2

RFID 320

315

340

B177 E39.7

IR1 Nr2

RFID 322 M K322: A5.4

M K320: A5.3

B166 E48.6

B163 E48.3 Y322 auf: A9.4

332 M M K340: A5.6

Y332 ab: A9.5

K330: A5.5

Ebene Aufteilung B165 E48.5

E40.4 Steuerung Ein & kein NOTAUS E40.5 MSS Q300-Q350, FU350 BB E40.6 Druckluft OK E40.7 Automatik Ein

B164 E48.4 B167 E48.7

350

M B157 E47.7

Skizze Kommisionierung E47.0 FTF Bereit E47.3 FTF Aufnehm.

Abb. 22.3   Aufteilung des Waage-Kreislaufs in Entitäten

A1.6 FT Bereit A7.3 FT BB

A0.6 FU vor A1.7 FT nicht belegt A6.6 FT Aktiv

V24

V24

Dig. IO

EATransfer

UDC/CP Agenten

UI Diagnose Diagnose - Logging

ERP

UDP-Client-Server

UDP-IP

UDP-Client-Server

Auftrags- / Status / Ereignis-Telegramme

UDP-Client-Server

UDP-Client-Server

SteuerungsDIAG

Steuerungsabläufe

RTOS 80186

FileSystem

Borland IDE

FileZilla.exe

TCP-IP

Abb. 22.4   RFID Controller Huf Tools IR1 (l) und Foxboard (r). Innerer Aufbau und externe Komponenten (u)

Gateway

Zyklusmessung

Firmware

RFID Antenne

22 ����������������������������������������������������������������� Der Lebenszyklus eines Internet der Dinge Materialflusssystems 239

240

A. Lanfer und A. Trautmann

22.6  Erfahrungsbericht Durch den Umbau der Anlage konnte gezeigt werden, dass eine Modernisierung einer bestehenden Anlage auf den Stand der Technik des Internet der Dinge technisch zuverlässig beherrschbar ist. Insbesondere hat sich bestätigt, dass sich durch den Einsatz der Agententechnologie heterogene Automatisierungskomponenten in ein ganzheitliches System integrieren lassen. Auf diese Weise lassen sich Automatisierungsaufgaben sehr effizient lösen, da für jede Aufgabe die optimale Komponente ausgewählt werden kann und so eine Überdimensionierung vermieden wird. Erst mit Hilfe der Diagnose- und Steuerungsmöglichkeiten (vgl. Kap. 20) ist eine effiziente Programmierung der Controller in Hochsprache möglich. Dieses konnte beim Redesign der Fahraufträge und des Protokolls für Fahraufträge gezeigt werden. Das Diagnosekonzept kann auf andere Controller übertragen werden. Durch die Controller-Steuerungen in Hochsprache und das implementierte Diagnosekonzept gestaltet sich die Programmerstellung und Inbetriebnahme effizienter als bei einer SPS. Durch den Einsatz heterogener Komponenten musste zum Teil auf unterschiedliche Entwicklungsumgebungen zurückgegriffen werden. Hier ist ein deutlicher Unterschied zwischen modernen, freien Entwicklungsumgebungen wie Eclipse und den teilweise veralteten und von den Herstellern der Controller zur Verfügung gestellten Entwicklungsumgebungen festzustellen. Ein einheitlicher Werkzeugeinsatz würde eine weitere Effizienzsteigerung ermöglichen. Für das Verteilen der Software auf die Controller ist ein automatischer Ablauf wünschenswert, der Abhängigkeiten und Versionsstände berücksichtigt. Erste Ideen dazu wurden erarbeitet, eine Umsetzung ist jedoch Gegenstand der weiteren Entwicklung. Ohne einen solchen Automatismus gestaltet sich das Verteilen der Software „von Hand“ aufwändig durch den dezentralen Ansatz.

22.7  Begleitende Dokumentation Umbauprojekte zeichnen sich dadurch aus, dass während der Inbetriebnahme Informationen über das vorhandene System gewonnen werden, die vorher nicht erfasst worden sind, aber für die weiteren Arbeiten dokumentiert und ggfs. anderen Mitarbeitern zur Verfügung gestellt werden müssen. Dies ist regelmäßig der Fall, auch trotz einer umfangreichen Analysephase. Die während dieser Analysephase erarbeiteten Informationen müssen während des Umbaus schnell verfügbar sein. Beispielsweise betrifft das folgende Informationen: • • • • • •

Handbücher zur Bedienung des Altsystems Leitfäden und Arbeitsanweisungen zum Umbau Besonderheiten der Anlage, z. B. Initialisierunsreihenfolgen Fehlerprotokoll Testplan Abnahmeprotokoll

22 ����������������������������������������������������������������� Der Lebenszyklus eines Internet der Dinge Materialflusssystems

241

Zur Dokumentation haben sich Wiki-Systeme etabliert. Wikis sind webbasierte Systeme, deren Inhalte von den Benutzern gelesen und vor allem auf sehr schnelle und einfache Art und Weise online geändert werden können. Mitarbeiter können so neu gewonnene Informationen auf der Baustelle schnell dokumentieren und anderen (authentifizierten) Nutzern zur Verfügung stellen. Hinterlegte Informationen lassen sich gut strukturiert und suchbar hinterlegen. Damit stellen Wikis eine gute Plattform zur Dokumentation des gesamten Umbauprozesses im Internet der Dinge dar.

22.8  Fazit Es muss im Vorfeld einer geplanten Umbau- oder Modernisierungsphase analysiert werden, ob eine Einführung des Internet der Dinge sinnvoll ist. Es erscheint dann sinnvoll, wenn folgende Bedingungen erfüllt sind: • Eine Modernisierung der Energieversorgungs- und Signalleitungsinfrastruktur ist unabhängig vom zukünftigen Steuerungskonzept notwendig • Die vorhandenen mechanischen Komponenten lassen sich mit dezentralen Steuerungskomponenten ergänzen • Das alte Anlagenlayout ermöglicht eine hohe Flexibilität des Materialflusses • Das Konzept Internet der Dinge verspricht signifikante Prozessvorteile Es wurde weiterhin ein allgemeines Konzept zur Realisierung eines solchen Umbaus vorgestellt. Der Erfahrungsbericht der Referenzanlage zeigt, dass ein Umbau bei entsprechender Vorbereitung problemlos möglich ist, vorausgesetzt die entsprechenden Hilfsmittel zu Systemdiagnose sind vorhanden.

Kapitel 23

Zusammenfassung und Fazit: Das Internet der Dinge als neues Vorgehensmodell Carolin Haußner, Jürgen Elger und Andreas Trautmann

Für eine systematische Analyse der Auswirkungen dezentraler Automatisierungssysteme wurde wie in Kap. 16 beschrieben eine Referenz-Modell Methodik entwickelt. Dieses Vorgehen wurde angewendet um die Auswirkungen des ebenfalls in diesem Kapitel dargestellten modular-mechatronisch motivierten Automatisierungssystems zu untersuchen. Die in den Kap. 17–22 beschriebenen Auswirkungen auf die Tätigkeiten entlang des Lebenszyklus einer dezentralen Automatisierungslösung flossen in die vergleichende Evaluierung zwischen einem klassisch entwickelten zentralen System und einem nach den Grundsätzen des Internet der Dinge entwickelten dezentralmechatronischen System ein. Dabei wurden die folgenden Ergebnisse im Hinblick auf Vor- und Nachteile beziehungsweise Chancen und Risiken des Einsatzes von dezentralen Systemen herausgearbeitet, gegliedert nach • Grundlagen und technischen Aspekten, • den Auswirkungen auf den Engineeringprozess und den Betrieb • daraus resultierende Anforderungen an den Menschen.

23.1  Grundlagen und technische Aspekte Wiederverwendung/Standardisierung: Durch standardisierte mechatronische Module kann ein erhöhter Wiederverwendungsgrad erreicht werden. Wichtig ist dabei, dass die Granularität der Module sinnvoll gewählt wird. Ein Modul einer Fördertechnik muss z. B. nicht zwingend auf der Ebene der einzelnen Förderelemente (Weiche, Kurve, etc.) gebildet werden, es bieten sich hier (abhängig von der erreichbaren Wiederverwendbarkeit) auch größere Einheiten an. Nicht in jeder Domäne ist jedoch von Projekt zu Projekt eine ausreichende Wiederverwendung gegeben. Nicht C. Haußner () Corporate Technology CT SE 5, Siemens AG Günther-Scharowsky-Str. 1, 91058 Erlangen, Deutschland e-mail: [email protected] W. Günthner, M. ten Hompel (Hrsg.), Internet der Dinge in der Intralogistik, DOI 10.1007/978-3-642-04896-8_23, © Springer-Verlag Berlin Heidelberg 2010

249

250

C. Haußner et al.

überall ist daher die Erstellung eines umfangreichen Modulbaukastens wirtschaftlich sinnvoll. Es ist individuell zu prüfen, welcher Aufwand für den Modulbaukasten angemessen ist und wie viel Leistung projektspezifisch erbracht werden soll. Grundsätzlich erzwingt die Standardisierung geradezu eine strukturierte, wiederholbare Vorgehensweise, die sich positiv auf die Qualität des Gesamtsystems auswirkt. Aufgabenverteilung/Automatisierungspyramide: Die streng hierarchische Automatisierungspyramide wird weitgehend aufgelöst. Entscheidungen der bisherigen Leitebene rücken näher an die Feldebene, d. h. die Entscheidungen werden näher am Ort des Geschehens getroffen. Es wird allerdings nach wie vor eine Schichtung innerhalb der Automatisierungs-Software geben, da die direkte Ansteuerung von Feldgeräten z. B. durch ein dezentrales Leitsystem auf Basis eines Agentenframeworks aufgrund mangelhafter Echtzeiteigenschaften unwahrscheinlich erscheint. In aktuellen Implementierungen im Forschungsprojekt Internet der Dinge dient z. B. eine Middleware als Kopplung zwischen Echtzeitsteuerung und übergeordneter Steuerungslogik. Damit gibt es auch nach wie vor eine gewisse Trennung zwischen den Schichten, sowohl nach unten zur Feldebene als auch nach oben zur Leitsystemebene, s. Abb. 23.1. Es hat sich gezeigt, dass eine Verteilung insbesondere vorteilhaft ist, wenn eine Anlage in funktional getrennte Bereiche gegliedert wird und nicht für Entscheidungen häufig Informationen über den Gesamtzustand nötig sind. In diesem Fall wäre ein sehr hoher Kommunikation-/Abstimmungsaufwand erforderlich, Informationen müssten redundant gehalten werden. Um dieses Hindernis zu umgehen bedarf es der zusätzlichen Erforschung geeigneter, auf den Austausch reduzierter Informationen zugeschnittener Algorithmen. Determinismus: Auch heutige Logistiksysteme sind nicht als streng deterministisch zu bezeichnen. Denkt man etwa an ein Gepäckfördersystem, so ist z. B. das Routing von so vielen Eingangsgrößen abhängig, dass Entscheidungen schwer vorhersehbar und v. a. wiederholbar sind. Diese Entwicklung verstärkt sich noch durch die Steuerung von Prozessen durch verteilte Intelligenz, da die Abarbeitungslogik solcher Systeme nicht durch zentrale Algorithmen festgelegt wird sondern auf Basis mehr oder weniger generischer Regeln erfolgt.

MES/ERP-Ebene

Prozess-/Leitebene

Steuerungsebene Feldebene

Abb. 23.1  Auflösung der Automatisierungspyramide im dezentralen System

23  Zusammenfassung und Fazit: Das Internet der Dinge als neues Vorgehensmodell

251

Nachvollziehbarkeit: Voraussetzung für das zeitlich korrekte Nachvollziehen von Ereignissen in der Anlage sind entsprechende Synchronisationsmechanismen, welche die in den einzelnen dezentralen Modulen gespeicherten (Teil-) Ereignisse zeitlich ordnen und zu einem Gesamtbild zusammenführen können. Diese Fähigkeiten werden für die Fehlersuche im Rahmen der Engineeringtätigkeiten, insbesondere während Inbetriebnahme und Abnahme sowie für den Betrieb zwingend benötigt und sind unabdingbar für die Kundenakzeptanz. Erforderlich ist eine Protokollierung des Kommunikationsverkehrs und der Zustandswechsel der in den Agenten implementierten Zustandsautomaten mit synchronisierten Zeitstempeln. Bewährt hat sich beispielsweise die Visualisierung dieser Informationen in Form von Sequenzdiagrammen. Die prototypisch implementierten Mechanismen zur Unterstützung der Fehlersuche bei dezentralen Systemen müssen noch weiterentwickelt werden. Anpassungs-/Änderungsfähigkeit, dynamisches Verhalten: Gerade das flexible, anpassungsfähige Verhalten von verteilter Intelligenz wird als Vorteil im Betrieb betrachtet. Regelbasierte Abstimmmechanismen erlauben die Reaktion auf nicht genau eingeplante Ereignisse. Allerdings nur, sofern die Auswirkungen vorgedacht waren im Hinblick auf die Systemeigenschaften, auf die reagiert werden muss, z. B. die Überlastung einer Förderstrecke und entsprechende Redundanzen in der Anlagenmechanik (z. B. Ausweichförderstrecken) vorhanden sind. Diese Vorteile zahlen sich bei Ausfall oder Reparatur einzelner Komponenten ebenso aus wie bei unterschiedlichen Lastsituationen. Robustheit: Durch das Auflösen des zentralen Leitrechners und somit eines Single Point of Failures sind die Auswirkungen bei einem Ausfall von dezentralen Automatisierungskomponenten in der Regel lokal begrenzt. Dem stehen noch zu untersuchende Fragestellungen z. B. im Hinblick auf die Datenhaltung und Datensicherheit entgegen. Konzepte zur Transaktionssicherung, Datenverteilung, Persistenz, sowie für Redundanzen, das Backup bzw. die Wiederherstellung sind zwar bekannt, müssen jedoch noch für die Belange der industriellen Automation weiterentwickelt bzw. umgesetzt werden.

23.2  Engineering und Betrieb Implementierung und Komponenten-Engineering: Die Verständlichkeit eines verteilten, dezentralen Automatisierungssystems vor allem in Hinblick auf automatisierungstechnische und IT-Funktionalitäten muss nach wie vor gewährleistet werden, wobei zwischen der Erstellung der Module im Rahmen der Entwicklung und ihrer Anwendung im Projekt unterschieden werden muss. Insgesamt ist zu erwarten, dass der Implementierungsaufwand und die Komplexität für die Erstellung steigen. Hier müssen die Grundlagen für konfigurierbare Module, welche in sich abgeschlossen, voneinander unabhängig und (selbsttätig) integrierbar sind, geschaffen werden, was komplexes Expertenwissen und ein Verständnis für die Kernfunktionalität der Module erfordert.

252

C. Haußner et al.

Ziel ist die Schaffung integrierter Schnittstellen und die Verwendung einheitlicher Bussysteme auf Feldebene. Bei dem betrachteten Referenzmodell kommen beispielsweise durchgängig ethernetbasierte Schnittstellen zum Einsatz. Ferner ist ein durchgängiger Werkzeugeinsatz zu empfehlen (Tooling). Darunter fallen Entwicklungsumgebungen und Debug-Hilfsmittel ebenso wie Versionsverwaltung und Dokumentationserstellung. Im Referenzmodell konnte gezeigt werden, dass sich heute der Einsatz von plattformunabhängigen objektorientierten Programmiersprachen (Java) durchgängig, sogar auf geeigneten Automatisierungsgeräten und Steuerungen, realisieren lässt. Projektspezifisches Engineering Bei der projektspezifischen Nutzung der vorgefertigten Module wird das Engineering erleichtert. Je mehr „Plug&Play“-Funktionalitäten vorhanden sind, umso weniger Aufwand entsteht in den EngineeringPhasen. Zudem kann das projektspezifische Risiko reduziert werden durch eine frühzeitige, realistische Nutzung der Simulation und dem damit verbundenen Überprüfen der Kundenanforderungen. Dies gilt allerdings nur, sofern nur Änderungen erforderlich sind, welche durch Konfiguration, Parametrierungen oder Einbringen von Änderungen/Erweiterungen an hierfür vorgesehenen Stellen (z. B. Plug-ins in der Software) notwendig sind und keine Änderungen an der Kernfunktionalität durchgeführt werden müssen. Dann ist keine Kenntnis der inneren Struktur der Module erforderlich, sie können als Black Box betrachtet werden. Ergo ist ein Verständnis der konfigurierbaren Funktionalität, Schnittstellen und eventueller Abhängigkeiten wesentlich. Bei projektspezifischen Anpassungen an den Kernfunktionalitäten bedarf es eines tiefen technischen Verständnisses z. B. im Bezug auf das Zusammenspiel zwischen den Modulen. Damit ist analog zur Erstellung der Module mit einer erhöhten Komplexität zu rechnen. Ziel ist daher das Finden eines optimalen Arbeitspunktes durch eine adäquate Definition und Schneidung der Anlage und der damit verbundenen Aufgaben zu Modulen. Inbetriebnahme: Das fortwährende Streben nach Effizienz erfordert die Erhöhung der Produktivität über den gesamten Lebenszyklus materialflusstechnischer Anlagen. Mit der beschriebenen Dezentralisierung und dem stärkeren Vernetzungsgrad der Entitäten und Module wächst der Grad der Komplexität durch die Verknüpfung von Mechanik, Elektronik und Software im Internet der Dinge kontinuierlich. In Kap. 20 wurde ein Inbetriebnahmekonzept vorgestellt, dass diesen Anforderungen Rechnung trägt und zu einer Reduzierung der Zeit, der Kosten und vor allem des Risikos bei der Inbetriebnahme beiträgt. Dieses Konzept erweitert die klassischen Phasen der Inbetriebnahme – von der Prüfung auf Vollständigkeit über die elektrische Inbetriebsetzung, Signal-/Funktions-/Integrations- und Sicherheitstests bis zur Abnahme – um ein inkrementelles Inbetriebsetzen und Testen auf Entitäten- bzw. Modulebene. Wichtige Voraussetzungen für eine reibungslose Inbetriebnahme sind zusammengefasst: • Einsatz der Emulation zur virtuellen Vor- und Teilinbetriebnahme. Identische I/ O-Schnittstellen für Emulationsmodell und physische Entität und die Abbildung eines hinreichend genauen Zeitverhaltens sind die Grundvoraussetzungen. Eine Effizienzsteigerung lässt sich durch die Verwendung derselben Meta-Informationen sowohl für die Steuerungs-Agenten als auch der Emulationskomponenten

23  Zusammenfassung und Fazit: Das Internet der Dinge als neues Vorgehensmodell

253

erreichen. Dazu zählen beispielsweise XML kodierte Topologie-Informationen oder Workflowbeschreibungen. • Hinreichend gute Diagnosemöglichkeiten. Die Ursachenforschung für Störfälle oder unerwartete Betriebszuständen während der Inbetriebnahme ist in dezen­ tralen Systemen schwieriger als in zentralen, weil zeitliche Abhängigkeiten und Ereignisreihenfolgen in Bezug zu dem Ergebnis der lokalen Entscheidungsintelligenz gesetzt werden müssen (vgl. Nachvollziehbarkeit). Betriebsphase und Bedienbarkeit: Für die Betriebsphase ist wichtig, dass die innere Komplexität des Systems nicht nach außen in Erscheinung tritt und sich eine Vereinfachung – zumindest jedoch keiner Verschlechterung – im Vergleich zu konventionellen Anlagen in Hinblick auf die Bedienbarkeit während des Betriebs ergibt. Bisher vorhandene Interaktions- und Visualisierungsmöglichkeiten müssen nach wie vor gegeben sein, was bedeutet, dass bisher zentral gehaltene Informationen nun verteilt abgefragt werden müssen. Hierfür müssen geeignete Mechanismen und Hilfsmittel geschaffen werden. Prototypisch ist das für das Referenzmodell erfolgt. Es hat sich gezeigt, dass die Konsolidierung und Vorabaufbereitung von Daten sinnvoll ist. Dazu können auf den Controllern Diagnoseschalter und Kontroll-Variablen in das Quellprogramm integriert werden, die über das http Protkoll abgefragt werden können und so in zentralen, webbasierten Monitoring-Lösungen angezeigt werden können. Umbau: Stellt bereits die Inbetriebnahme hohe Anforderungen an den Engineering-Prozess gilt dies für Umbau- und Retrofitting Projekte in besonderer Weise. Die oben skizzierten Randbedingungen und Lösungskonzepte gelten entsprechend. Als zusätzliche Herausforderung ist hier der Umbau einer Anlage, die sich im operativen Betrieb befindet, zu beachten. Da diese Anlagen häufig „mission critical“ sind kommt eine Stillsetzung für einen längeren Zeitraum nicht in Betracht. Umbauarbeiten müssen demzufolge in betriebsarmen Zeiten, oft am Wochenende erfolgen. Ein Zurückschalten auf das alte Steuerungssystem muss jederzeit möglich sein bei Sicherstellung von konsistenten Daten und Betriebszuständen, um das Anlaufen der Anlage zu ermöglichen. Dies gilt für klassische Retrofitting Projekte (Modernisierung der Steuerung von Siemens S5 auf S7) ebenso wie für Retrofitting Projekte, die eine Umsetzung des Internet der Dinge Konzepts beinhalten. In letzterem Fall kommt erschwerend hinzu, dass die vorhandene Energieversorgungs- und Signalleitungsinfrastruktur im Regelfall nicht weiter genutzt werden kann. Aus diesem Grund erscheint ein Umbau dann sinnvoll wenn eine „Agentifizierung“-Potenzial-Analyse ein positives Ergebnis liefert. Die Voraussetzungen dafür sind gegeben wenn: • Eine Modernisierung der Energieversorgungs- und Signalleitungsinfrastruktur unabhängig vom Steuerungskonzept notwendig ist. • Die vorhandenden und häufig unverändert weitergenutzten mechanischen Komponenten mit dezentralen Steuerungskomponenten ergänzt werden können. • Das alte Anlagenlayout eine hohe Flexibilität des Materialflusses strukturell ermöglicht. Dies bedingt bei Stetigfördertechnikanlagen beispielsweise das Vorhandensein von Alternativrouten. Gerade dieser Umstand ist häufig nicht gegeben.

254

C. Haußner et al.

• Das Konzept Internet der Dinge signifikante Prozessvorteile ermöglicht und gegebenenfalls dazu auch eine strukturelle mechanische Erweiterung in Kauf genommen wird.

23.3  D  er Faktor Mensch und Qualifikation – Gewerkeübergreifendes Arbeiten und vertikale Kompetenzen Ein häufig genanntes Problem im Engineering ist die mangelnde gewerkeübergreifende Zusammenarbeit und die Sicherstellung eines konsistenten Austausches von Informationen. Heute arbeiten spezialisierte Mitarbeiter auf unterschiedlichen (Automatisierungs-) Ebenen und zu meist unterschiedlichen Phasen. Darüber hinaus sind z. B. bei der Inbetriebsetzung häufig auch Mitarbeiter aus dem Engineering erforderlich. Die Rollenverteilung und Kompetenzen sind klar gegliedert und umfassen • • • •

Mechaniker Elektriker SPS Programmierer Java/C++ Anwendungsentwickler

Durch einen mechatronischen Ansatz kann das bisherige Denken und Handeln in Gewerken aufgelöst werden. Bei Arbeiten an den Referenzanlagen hat sich gezeigt, dass dort dieselben Mitarbeiter, die bis jetzt in den jeweiligen Ebenen der Automatisierungspyramide getrennt voneinander gearbeitet haben, nun gemeinsam auf einem Fördertechnikmodul/Gerät/Controller arbeiten. Das fördert zwar das „gewerkeübergreifende“ Arbeiten und eine gemeinsame Sprache, birgt aber gleichzeitig auch organisatorische Herausforderungen und erfordert einen hohen Ressourceneinsatz. Zwar werden auch weiterhin für die einzelnen Disziplinen Spezialisten notwendig sein, diese bearbeiten jedoch z. B. während des Engineering im Team ein in sich konsistentes mechatronisches Modul, das idealerweise auf einem gemeinsamen Objektmodell basiert. Dieses wird im Rahmen der Projektabwicklung erweitert und verfeinert und bietet je nach Anforderung verschiedene konsistente Sichten (mechanisch, elektrisch, automatisierungstechnisch). Hierzu sollen Engineeringwerkzeuge verwendet werden, die ein mechatronisch orientiertes Arbeiten unterstützen (z. B. Comos). Die langfristige Zielsetzung bei den Herstellern muss deswegen neben der Ausbildung von Spezialisten in den Gewerken auch die Erreichung einer hochqualifizierten vertikalen Engineeringkompetenz bei einzelnen Mitarbeitern sein (vgl. Abb. 23.2). Zudem gilt es für die Inbetriebnahme Mitarbeiter speziell zu qualifizieren. Die technische Qualifikation kann bei diesen Mitarbeitern durch den angestrebten „Plug&Play“ Ansatz geringer ausfallen.

23  Zusammenfassung und Fazit: Das Internet der Dinge als neues Vorgehensmodell

255

MES/ERP Prozess

Steuerungsebene Feldebene

Abb. 23.2  Von spezialisierten Mitarbeitern zu vertikaler Engineering-Kompetenz

23.4  Fazit Die Vorteile dezentraler Automatisierungslösungen im Internet der Dinge hinsichtlich Anpassungs-/Änderungsfähigkeit, dynamischen Verhaltens und Robustheit sind gegeben und wurden in den vorangegangenen Kapiteln aus unterschiedlichen Blickwinkeln untersucht. Es hat sich gezeigt, dass eine Realisierung von Anlagen gemäß des Konzepts Internet der Dinge mit dem Stand der Technik und den entwickelten Konzepten heute möglich ist und sinnvoll sein kann, Es zeigt sich aber auch, dass weiterführende Lösungen zu entwickeln bzw. konzeptionell erarbeitete Lösungen umzusetzen sind, um industriell und in größerem Maßstab Anlagen gemäß des Konzepts Internet der Dinge wirtschaftlich zu realisieren. Dies betrifft vor allem den durchgängigen Werkzeugeinsatz beim Engineering und Konzepte zur praxistauglichen Nachvollziehbarkeit von Materialflussentscheidungen. Durch die praktischen Erfahrungen bei der Implementierung der Referenzanlage ist als zentraler Aspekt der Wissenstransfer zwischen Mitarbeitern aus den einzelnen Schichten der Automatisierungspyramide hervorgetreten. Dies umfasste einerseits das Wissen über die Implementierung von Agentensystemen, das sich diejenigen SPS Programmierer aneignen mussten, die Agenten auf Controller-Ebene programmieren. Andererseits brachten diese Mitarbeiter wichtiges Feedback über die Praxistauglichkeit der entwickelten Modellierung der Agenten in die Diskussion ein. Als Resümee kann festgehalten werden, dass neben den technischen Aspekten in einer angepassten Qualifikation der Mitarbeiter ein wichtiger Schlüssel zum Erfolg des Internets der Dinge liegt.

Teil IV

Die Anwendung

Kapitel 24

Realisierung einer agentenbasierten Steuerung für Elektrohängebahnsysteme Razvan Chisu, Florian Kuzmany und Willibald A. Günthner

24.1  Definition und Einsatz von Elektronhängebahnanlagen Elektrohängebahn- bzw. EHB-Anlagen bestehen aus zwangsgeführten, einzeln angetriebenen Fahrzeugen und einem flurfreien Streckennetz aus Fahrschienen und verschiedenen Arten von Verzweigungen, Zusammenführungen und Hubeinrichtungen (vgl. VDI 2345). Sie werden meist zur Teilezuführung für die Produktion, beispielsweise in der Automobilindustrie, oder auch in Lagervorzonen eingesetzt. Die Verlagerung der Materialflusstechnik in den Überflurbereich mit EHB-Anlagen und EHB-Kranfeldern führt zu einer höheren Layoutflexibilität und einer besseren Erreichbarkeit von Lager- oder Produktionseinrichtungen (vgl. Wilke 2006). Speziell unterhalb der Kranfelder können Fertigungsmaschinen oder die dazugehörenden Lastübergabeplätze bei Bedarf verschoben werden, ohne dass eine Änderung des Materialflusssystems notwendig wäre.

24.2  Versuchsanlage des Lehrstuhls fml an der TU München Dem Lehrstuhl für Fördertechnik Materialfluss Logistik der Technischen Universität München stehen für die Erforschung und Erprobung dezentraler Steuerungskonzepte für innerbetriebliche Materialflusssysteme unter Anderem eine EHB-Anlage (s. Abb. 24.1) sowie ein unter dem Schienennetz verlaufender Rollenförderer zur Verfügung. Die EHB-Anlage besteht aus zwei für den Transport von VDA-Kleinladungsträgern (KLT) und mit einer Nutzlast von 50kg ausgelegten Einschienenkatzen, drei Weichen und einem Einträgerkran, welcher von den Katzen befahren werden kann. Zusätzlich kann auf eine Zweischienenkatze für den Transport von Großladungsträgern bis R. Chisu () Lehrstuhl für Fördertechnik Materialfluss Logistik fml Technische Universität München, Boltzmannstr. 15, 85748 Garching, Deutschland e-mail: [email protected] W. Günthner, M. ten Hompel (Hrsg.), Internet der Dinge in der Intralogistik, DOI 10.1007/978-3-642-04896-8_24, © Springer-Verlag Berlin Heidelberg 2010

253

254

R. Chisu et al.

Abb. 24.1  Internet der Dinge Demonstrationsfeld am Lehrstuhl fml, TU München

1000 kg und auf einen Zweiträgerkran zugegriffen werden. Der Ein- und Zweiträgerkran verfahren dabei im selben Kranfeld (s. Abb. 24.2). Die Fahrzeuge sind mit einem Lastaufnahmemittel (LAM) mit Hebe- und Senkvorrichtung ausgestattet, wobei eine der Einschienenkatzen mit einem automatischen und die andere mit einem manuellen LAM versehen ist. Die Zweischienenkatze verfügt über ein automatisches Lastaufnahmemittel. Klein- und Großladungsträger können von den EHB-Katzen aus einem Lagerbereich sowie an drei weiteren in der Versuchshalle eingerichteten Lastübergabeplätzen aufgenommen und abgegeben werden. Zusätzlich können die Einschienenkatzen KLT von einem unter dem EHB-Streckennetz verlaufenden Rollenförderer abnehmen. Für die Positionsbestimmung der Fahrzeuge wird zum einen ein Wegmesssystem auf Basis eines Lochstreifens verwendet. Dieser kodiert eine absolute Millimeterposition und wird für die Feinpositionierung beim Erreichen eines Lastübergabeplatzes verwendet. Die Grobpositionierung bzw. die Navigation im Streckennetz geschieht über an den Schienen angebrachte RFID-Transponder, die in Form zweier ganzzahliger Werte die ID eines Streckenstücks oder auch einer Weiche sowie die ID des aktuellen Verbindungspunktes des Streckenelements kodieren. Die unter dem Schienennetz verlaufende Förderstrecke ist für den Transport von Kleinladungsträgern ausgelegt und stellt eine Verbindung zwischen einer mit einem Sechs-Achs-Roboter automatisierten Lagervorzone (s. Kap. 28) und dem EHB-Bereich her. Die Förderstrecke besteht aus zwei mechanisch unabhängigen Rollenförderern mit eigenen Antrieben, wobei der erste (in Förderrichtung gesehen) gerade

24  Realisierung einer agentenbasierten Steuerung für Elektrohängebahnsysteme Einträgerkran

Zweiträgerkran

Einschienenkatze

Kranfeld

Lagerbereich

255

Zweischienenkatze

RFID-SchreibLese-Einheit

Stauplatz

Anbindung an Kommissionierroboter Weiche

Weiche

Förderrichtung

RFID-SchreibLese-Einheit

Einschienenkatze

Weiche

Abb. 24.2   EHB-Anlage und Rollenförderermodule mit drei bzw. vier Stauplätzen und zwei RFID-Schreib-Lese-Einheiten

ist und einen Stauplatz am Eingang, also an der Schnittstelle zur Lagervorzone, und drei weitere Stauplätze am Ausgang besitzt. Der zweite Rollenförderer besteht aus zwei geraden Bereichen mit einem 90°-Kurvenstück in der Mitte und besitzt am Ende drei Stauplätze. Am jeweils letzten Stauplatz der beiden Förderer ist die Übergabe eines Behälters an eine EHB-Katze möglich (s. Abb. 24.2).

24.3  Aufgaben- und Szenarienbeschreibung Das betrachtete Materialflussszenario besteht aus folgenden Schritten: 1. Ein VDA-KLT wird vom Depalettierroboter in der Lagervorzone auf den Rollenförderer gelegt. Die Transporteinheit ist mit einem RFID-Tag ausgestattet, auf dem neben einer eindeutigen ID auch das Ziel des Behälters gespeichert wird. 2. Der Behälter wird, je nach seinem Ziel, bis zum ersten oder zweiten Übergabepunkt zwischen Rollenförderer und EHB-Anlage gefördert. 3. Ein neuer Transportauftrag wird generiert, über dessen Zuteilung die zwei EHBEinschienenkatzen selbständig miteinander verhandeln müssen. 4. Eine der EHB-Katzen nimmt den Auftrag an und berechnet selbständig einen Weg von ihrem eigenen Standort zu dem des Behälters. 5. Bei der Lastübergabe zwischen Rollenförderer und Katze findet eine Abstimmung zwischen den zwei Modulen statt.

256

R. Chisu et al.

6. Die Katze führt eine neue Wegplanung durch und fördert den aufgenommenen Behälter zu seinem Ziel. Dabei fordert die Katze evtl. von den Weichen und der Kranbrücke das Herstellen bestimmter Wegverbindungen an. 7. Die Fahrzeuge sind zusätzlich in der Lage, der jeweils anderen Katze einen Ausweichauftrag zuzuteilen, wenn diese den Zielort belegt hält.

24.4  Modularisierung und Steuerungsarchitektur Entsprechend des in Kap. 8 erläuterten Konzepts wurde die Versuchsanlage in folgende zehn Module untergliedert: • • • • • •

2 x Einschienenkatze 3 x Einträgerweiche 1 x Einträgerkran 1 x Zweischienenkatze 1 x Zweiträgerkran 2 x Rollenförderer

Dabei werden Unterschiede in der mechanischen Auslegung bei Modulen gleichen Typs, also die Unterscheidung zwischen einem manuellen und einem automatischen Lastaufnahmemittel bei den Einschienenkatzen oder die Festlegung der Anzahl und der Position der Pufferplätze bei den Rollenförderern, den Steuerungsagenten über Konfigurationsdateien bekannt gemacht – eine unterschiedliche Programmierung ist weder auf der Ebene des Agenten noch auf Ebene der Maschinensteuerung (s. a. Kap. 11) notwendig. Die Modullogik wurde als eine Software in zwei Schichten realisiert, wobei die Softwareagenten als Java-Programm ausgeführt wurden und auf dem JADE-Framework mit Leap-Addon basieren, während die Maschinensteuerung als IEC-61131-3 Programm implementiert wurde. Die dazwischen vermittelnde Middleware wurde in Form einer Sammlung von Java-Klassen realisiert, die in jedem Agenten instanziiert werden und entsprechend den Angaben in einer XML-Konfigurationsdatei Informationen zwischen dem Agenten und der Maschinensteuerung oder zwischen dem Agenten und einem Emulator überträgt. Die Emulation der Maschinensteuerungsschicht ermöglicht dabei einen von der realen Anlagenphysik unabhängigen Test, welcher Fehler in der Steuerungsprogrammierung aufzeigen kann. Die gesamte zur Steuerung eines Moduls notwendige Software wird während des Anlagenbetriebs auf einem am Gerät angebrachten Controller ausgeführt, kann aber zu Entwicklungszwecken auch auf einem PC gestartet werden. Als Steuerungshardware für die Fördermodule werden durchgehend Embedded PC der Firma Beckhoff (Modell CX9010) eingesetzt, die mit Windows® CE 5 und Soft-SPS sowie einem Intel® IXP 420 Prozessor mit 533 MHz ausgerüstet sind. Für die Kommunikation der Module untereinander wird Ethernet bzw. WLAN eingesetzt. Je nach Modultyp sind diese mit mehreren digitalen E/A-Klemmen und evtl. CAN-Bus-Kopplern ausgerüstet. Aus Kostengründen wurde jedoch nicht jedes der oben aufgeführten Fördermodule mit einem eigenen Rechner ausgestattet, sodass

24  Realisierung einer agentenbasierten Steuerung für Elektrohängebahnsysteme

257

auf manchen Controllern mehrere Agenten und SPS-Tasks ausgeführt werden. Insgesamt wurden sieben Rechner nach folgendem Muster verbaut: • • • •

je ein Embedded PC pro Ein- bzw. Zweischienenkatze, je ein Embedded PC für den Ein- und Zweiträgerkran, ein gemeinsamer Embedded PC für die drei EHB-Weichen und ein gemeinsamer Embedded PC für die zwei Rollenförderer.

Ein mit vier Antennen ausgestatteter RFID-Reader der Firma Siemens wird für die Identifikation von Transporteinheiten an den zwei Übergabepunkten zwischen Rollenförderern und EHB-Anlage eingesetzt. Dieser wird von beiden Rollenfördereragenten über ihre Middleware angesprochen. Darüber hinaus wurden mehrere Dienste realisiert, die zum Datenaustausch zwischen Entitäten und zur Interaktion mit einem Benutzer eingesetzt werden. Die Dienste wurden ebenfalls in Form von JADE-Leap-Agenten implementiert und können auf einem oder mehreren Windows-PC ausgeführt werden. Anders als bei den Modulen wurde für die Programmierung jedoch nicht Java sondern C# .Net eingesetzt, um die Interoperabilität zwischen verschiedenen Laufzeitumgebungen (Embedded PC mit Windows CE, PC mit Windows XP) und Programmiersprachen (Java, .Net) zu demonstrieren. Implementiert wurden: • Eine Datenaustauschplattform, auch Blackboard genannt, wird zur Speicherung systemweit relevanter Daten wie z. B. der Anlagentopologie, Wegreservierungen oder offenen Transportaufträgen genutzt. Der Einsatz eines Blackboards garantiert die Datenkonsistenz und entkoppelt Sender und Empfänger einer Nachricht, sodass die Kommunikationskomplexität des Systems gesenkt wird (s. Abb. 24.3). Um eine persistente Speicherung der Daten zu ermöglichen, ist das Blackboard an einen Microsoft® SQL Server gekoppelt und übersetzt Dateninhalte aus dem im Agentensystem eingesetzten XML-Format in SQL-Befehle, die an den MSSQLServer weitergeleitet werden, wobei die für XML-Inhalte typische Baumstruktur

Qu

g

itti

tra

rag

Fe h

ler

ft Au me

ldu

ng

Quittierung

g ldun

g

ng

Sta tusm e

un

ieru

Statusmeldung

dung Fehlermel

er

itt Qu

f Au

Auftrag

Abb. 24.3  Verwendung eines Blackboards zum Datenaustausch

Aufträge Quittierungen Status- und Fehlermeldungen

258

R. Chisu et al.

auch in der SQL-Datenbank nachgebildet wird und somit erhalten bleibt. Das Blackboard ist in der Lage, Datenbanktabellen dynamisch aufzubauen und zu verändern und somit beliebige, als XML codierbare, Daten zu speichern, zu durchsuchen und auf Anfrage zurück zu liefern. Weiterhin benachrichtigt das Blackboard andere Entitäten aktiv über Datenänderungen und unterstützt somit den Datenaustausch sowohl nach dem Pull- als auch nach dem Push-Prinzip. • Eine Visualisierungsumgebung dient zur grafischen und textuellen Anzeige der auf dem Blackboard gespeicherten Daten (s. a. Kap. 14) und wird zu diesem Zweck über alle Datenänderungen vom Blackboard benachrichtigt. Dabei wird nicht nur der aktuelle Stand der Informationen gespeichert sondern auch eine Historie generiert – so kann ein Bediener einsehen, welche Daten wann von wem geändert wurden. Dies ermöglicht eine leichtere Diagnose von Fehlerfällen und das Nachvollziehen auch komplexer Vorgänge. Neben der einfachen Ansicht der Informationen in Form einer XML-Baumstruktur können beliebige 2D- und 3D-Visualisierungsstrategien anhand einfacher Visualisierungsregeln definiert werden (s. Abb. 24.4). Da dieses Werkzeug keine für EHB-Anlagen oder für Materialflusssysteme im Allgemeinen spezifische Logik enthält, sondern auf frei kombinierbaren Regeln basiert, ist es äußerst flexibel und kann für verschiedenste Szenarien eingesetzt bzw. wiederverwendet

Abb. 24.4  Screenshot der Visualisierungsumgebung mit textueller und grafischer Anzeige in 2D und 3D

24  Realisierung einer agentenbasierten Steuerung für Elektrohängebahnsysteme

259

werden. Darüber hinaus ist die Visualisierung in der Lage, den aktuellen Datenzustand oder ganze Historien in Form von frei definierbaren Linien- oder Kreisdiagrammen darzustellen. Diese Möglichkeit zur statistischen Auswertung verschiedener Zusammenhänge bilden die Grundlage für die Bewertung und Analyse der Gesamtsystemleistung. Wie auch das Blackboard kann die Visualisierung mit beliebigen XML-codierten Datenformaten umgehen und ist nicht auf eine bestimmte Ontologie oder bestimmte Datenstrukturen festgelegt. • Ein Editor bietet einem Benutzer über eine grafische Schnittstelle (GUI) die Möglichkeit, die Dateninhalte des Blackboards bzw. Tabellen der SQL-Datenbank manuell zu verändern. Ebenso erlaubt es dieses Werkzeug, Nachrichten direkt an andere Agenten zu versenden, beispielsweise um die Betriebsart einer EHB-Katze vom Automatikbetrieb auf manuellen Betrieb umzustellen. • Eine Auftragsverwaltung erlaubt es einem Benutzer, Transportaufträge manuell einzugeben oder automatisch generierte Aufträge einzusehen. Neben allen Details zum Start- und Zielpunkt wird auch angezeigt, ob ein Auftrag erfüllt wurde, oder ob er gerade bearbeitet wird. Für Transporteinheiten wurden keine Agenten implementiert – die KLT sind also völlig passiv, werden aber mit einem UHF-RFID-Chip ausgestattet. Dieser speichert neben der eindeutigen ID des Behälters zusätzliche Informationen zum Behältertyp und seinem Inhalt sowie seinem Zielpunkt. Dies entspricht dem Data-on-tag Prinzip, das in Kap. 12 beschrieben wurde.

24.5  Funktionsweise Beim Hochfahren des Systems verbinden sich die EHB-Katzen mit dem Blackboard und rufen die Anlagentopologie ab (s. UML-Diagramm in Abb. 24.5). Diese Information bildet die wichtigste Grundlage für alle zukünftigen Wegplanungen bzw. -entscheidungen. Die Rollenförderer tragen sich im Verzeichnisdienst der Agentenplattform, dem so genannten Directory Facilitator oder DF, als Anbieter einer Lastwechselkoordinationsfunktion an ihrer jeweiligen Koordinate in der Versuchshalle Blackboard

EHB-Katze

1: Topologie abfragen

Rollenförderer

2: Lastwechselfunktion eintragen

3: Topologie 4: Transportfunktion eintragen

Abb. 24.5  Initialisierungsphase

DF

260

R. Chisu et al.

ein. Diese Information bildet für Katzen die Grundlage, um vor einem Lastwechsel entscheiden zu können, ob sie sich dabei mit einem anderen Modul abstimmen müssen oder den Lasttransfer in Eigenregie durchführen können. Ein mit einem RFID-Chip ausgestatteter VDA-KLT wird vom Depalettierroboter auf den Rollenförderer gelegt. Der Förderer führt intern und auf der Ebene der Maschinensteuerung eine Verwaltung der eigenen Pufferplätze durch und fördert den Behälter bis zum letzten freien Stauplatz. Kommt ein KLT auf dem letzten Stauplatz des Förderers an, gelangt er in das Lesefeld des RFID-Readers. Die gelesenen Daten werden dem Agenten des Rollenförderers zur Verfügung gestellt, der anhand der Zielinformationen auf dem Transponder entscheidet, ob der Behälter an den nächsten Rollenförderer oder an eine EHB-Katze abgegeben werden muss. Wird der Behälter an den zweiten Rollenförderer übergeben, wiederholt sich der gerade beschriebene Ablauf, bis die Transporteinheit wiederum am letzten Stauplatz ankommt. Von dort aus ist eine Übergabe zur EHB die einzig mögliche Alternative (s. UML-Sequenzdiagramm in Abb. 24.6). Der Rollenförderer erzeugt einen Transportauftrag, der als Startpunkt die Position des eigenen Übergabeplatzes und als Ziel den auf dem RFIDTag angegebenen Ort hat. Dieser Auftrag wird in Form einer XML-Nachricht auf das Blackboard geschrieben, von wo aus er von den EHB-Katzen abgerufen wird.

Rollenförderer 1

Rollenförderer 2

Blackboard

1: TE übergeben

2: Bis zum letzten Platz fördem

3: RFID-Tag lesen 4: TE übergeben

5: Bis zum letzten Platz fördem

6: RFID-Tag lesen 7: EHB-Auftrag eintragen

Abb. 24.6  Transport über Rollenförderer

24  Realisierung einer agentenbasierten Steuerung für Elektrohängebahnsysteme

261

Erhält eine Katze einen neuen Auftrag, dessen Start- und Zielpunkt sie erreichen kann, prüft sie zuerst, ob andere freie Katzen im System existieren und somit eine Verhandlung notwendig ist, um den Auftrag zuzuteilen. Diese Information wird über den Directory Facilitator abgerufen. Ist kein anderes freies Fahrzeug verfügbar, nimmt die Katze den Auftrag an und trägt auf dem Blackboard einen entsprechenden Vermerk ein. Ist eine Verhandlung notwendig, berechnen die beteiligten Katzen im ersten Schritt ein Gebot, das sich aus der Länge des kürzesten reservierbaren Weges zum Startpunkt ergibt. Beide Katzen schreiben ihr eigenes Gebot auf das Blackboard und rufen nach einer fest definierten Zeit alle vorhandenen Gebote ab. Damit kennt jedes Fahrzeug die Gebote aller anderen Teilnehmer und kann somit erkennen, ob es die Auktion gewonnen hat (s. UML-Sequenzdiagramm in Abb. 24.7). Der Gewinner der Auktion reserviert den Auftrag auf dem Blackboard in seinem Namen, womit auch doppelte Reservierungen verhindert werden, und beginnt mit der Bearbeitung. Als erstes verändert die Katze ihren Eintrag im Directory Facilitator, um vom anderen Fahrzeug nicht mehr als frei erkannt zu werden – dies verhindert beim EHB-Katze 1

Blackboard

1: Aufträge abfragen

DF

EHB-Katze 2

2: Aufträge abfragen 4: Auftrag

3: Auftrag

5: Andere Katzen suchen

6: Andere Katzen suchen

7: Wegplanung 9: Gebot eintragen

10: Gebot eintragen

8: Wegplanung

11: Ende der Auktion abwarten 13: Gebote abfragen 15: Gebote

14: Gebote abfragen 12: Ende der Auktion abwarten 16: Gebote

17: Auktion gewornen 19: Auftrag reservieren 18: Auktion verloren 20: Eintrag ändern (”beschäftigt”)

Abb. 24.7  Auftragsdisposition im EHB-System

262

R. Chisu et al.

Einlasten eines neuen Auftrags eine unnötige Auktion mit nur einem Teilnehmer. Die Berechnung eines Weges vom aktuellen Standort der Katze zum Rollenförderer, von dem der Behälter abzuholen ist, wird mit einem Dijkstra-Algorithmus durchgeführt. Dieser berücksichtigt zum einen die (statische) Anlagentopologie, die bei der Initialisierung abgerufen wurde. Zum anderen wird aber auch der dynamische Zustand des Systems – so z. B. der Aufenthaltsort anderer Fahrzeuge, Wegreservierungen oder manuell eingetragene Streckensperrungen – berücksichtigt. All diese Informationen sind auf dem Blackboard verfügbar, was die Aktualität und Korrektheit der Daten garantiert. Hat die Katze einen oder mehrere Wege gefunden und sich für den kürzesten entschieden, trägt sie Reservierungen für die zu befahrenden

EHB-Katze

Blackboard

EHB-Weiche

1: Topologie abfragen

2: Topologie

3: Wegplanung 4: Reservierungen eintragen

5: Bis Weiche fahren 6: Schaltauftrag 7: Schaltvorgang 8: Bestätigung

9: Fahren

10: Reservierung löschen

11: Feinpositionierung

Abb. 24.8   Auftragsbearbeitung durch EHB-Katze

24  Realisierung einer agentenbasierten Steuerung für Elektrohängebahnsysteme

263

Streckenstücke und Weichen in die Topologie ein. Diese sind notwendig, um Kollisionen mit anderen Fahrzeugen zu vermeiden, vor allem unter dem Gesichtspunkt, dass das Streckennetz in beide Richtungen befahren wird. Nachdem ein Streckenstück oder eine Weiche verlassen wurde, wird die entsprechende Reservierung sofort gelöscht. Details zum Wegplanungs- und Fahrzeugsteuerungskonzept finden sich auch in (Wilke 2006). Während der Fahrt orientiert sich das Fahrzeug an den an der Fahrschiene angebrachten Transpondern und führt nach Passieren des letzten Wegpunktes anhand des Absolutwegmesssystems die Feinpositionierung durch (s. UML-Sequenzdiagramm in Abb. 24.8). Am Startpunkt des Auftrags angekommen prüft die Katze zuerst, ob an dieser Stelle eine Lastwechselkoordination notwendig ist. Wird im Directory Facilitator ein Rollenförderer für die entsprechenden Koordinaten aufgeführt, wird über einen einfachen Nachrichtenaustausch vor dem Lastwechsel sichergestellt, dass sich beide Module in einem für den Lasttransfer sicheren Zustand befinden. Dies berücksichtigt das Erreichen der korrekten Position, das Ausschalten der Antriebe, das Vorhandensein eines KLT auf dem Rollenförderer und die Bereitschaft der Katze, den Behälter aufzunehmen. Das Lastaufnahmemittel der Katze wird gesenkt und, im Fall des automatischen Lastaufnahmemittels, nach dem Greifen des Behälters wieder angehoben. Besitzt die Katze ein manuelles Lastaufnahmemittel, muss ein Bediener den Greifvorgang durchführen und das LAM anschließend hochfahren. Die erfolgreiche Beendigung der Lastübergabe wird über einen weiteren Nachrichtenaustausch quittiert, nach dem die zwei Module mit ihren jeweiligen Transportaufträgen fortfahren können (s. UML-Sequenzdiagramm in Abb. 24.9). EHB-Katze

DF

1: Suche nach zweitem Modul für Lastwechsel 2: “Rollenförderer”

3: Lastwechsel beginnen 4: Bestätigung

5: Behälter aufnehmen 6: Lastwechsel beendet 7: Bestätigung

Abb. 24.9  Lastwechsel zwischen Katze und Rollenförderer

Rollenförderer

264

R. Chisu et al.

Die Katze fährt nun das endgültige Ziel an und wiederholt dabei den beschriebenen Vorgang der Wegplanung, des Transports und des Lastwechsels. Wurde der Auftrag erfüllt, wird auch dies auf dem Blackboard eingetragen, sodass sich ein Bediener über den Auftragsverwaltungs- oder die Visualisierungsdienst jederzeit einen Überblick der abgearbeiteten oder noch offenen Aufträge machen kann.

24.6  Fazit Im Rahmen des BMBF-Forschungsprojekts „Internet der Dinge“ wurde die beschriebene EHB-Anlage zur praktischen Erprobung und Demonstration des entwickelten Modularisierungs- und Steuerungskonzeptes herangezogen. Die Umsetzung zeigt, dass ein agentengesteuertes System aus mehreren mechatronisch gestalteten Modulen, Softwarediensten und mit RFID-Tags gekennzeichneten Transporteinheiten in der Lage ist, Transporte ohne zentralen Materialflussrechner durchzuführen. Außerdem kann das Materialflusssystem auf veränderte Rahmenbedingungen wie z. B. die Anzahl der Fahrzeuge im System oder Ausfälle von Weichen oder Strecken dynamisch reagieren. Die Implementierung des Steuerungskonzepts des Internets der Dinge in einer realen Anlage lieferte viele Anhaltspunkte bzgl. der industriellen Anforderungen und zeigte bei der Inbetriebnahme schon erste Vorteile dieses modularen Anlagenkonzepts gegenüber herkömmlichen Lösungen, da durch eine Emulation umfangreiche Nacharbeiten in der Realisierungsphase vermieden werden konnten. Daher stellte diese erste Umsetzung eineBasis für die Entwicklung bzw. Verfeinerung vieler der im Rahmen dieses Buches vorgestellten Konzepte dar.

Kapitel 25

Chancen und Herausforderungen von dezentral gesteuerten Flughafen-Gepäckförderanlagen Jürgen Elger, Carolin Haußner, Michael Hofmeister und Georg Baier

25.1  Allgemeines Für eine Darstellung der Chancen und Herausforderungen dezentraler Gepäckförderanlagen erfolgt in diesem Beitrag zunächst ein grober Überblick über die Aufgaben und Funktionsbereiche einer Flughafen-Gepäckförderanlage. Dies wurde bereits in (Liekenbrock u. Elger 2007) behandelt, soll aber an dieser Stelle zu einem besseren Verständnis des Szenarios Gepäcktransport in einem dezentralen System in Abschn. 25.5.4 nochmals dargestellt werden. Danach werden Anforderungen für Gepäckfördersysteme aufgezeigt, welche insbesondere durch dezentral gesteuerte Gepäckförderanlagen berücksichtigt werden müssen. Die in Teil III beschriebenen Auswirkungen einer dezentralen Automatisierung auf den Lebenszyklus werden im Anschluss auf Gepäckförderanlagen übertragen. Dazu zählen zum einen Veränderungen im Engineering oder bei Umbauten. Darüber hinaus wird exemplarisch ein Szenario beschrieben, wie der Betrieb einer zukünftigen Gepäckförderanlage aussehen könnte. Die logischen Abläufe des Systems ergeben sich im dezentralen Fall nicht mehr durch einen zentralen Algorithmus, sondern durch das Zusammenspiel zunächst unabhängiger Module und damit durch deren Interaktion. Um eine korrekte Erfüllung aller Anforderungen sicherzustellen, wird damit die Nutzung dezentraler Systeme eine erhöhte Gewichtung der Simulation nach sich ziehen. Als Vorteil erweist sich dabei, dass durch die modulare Kapselung der Funktionalitäten die auch im Feld eingesetzten SW-Module direkt für Simulation bzw. Emulation verwendet werden können. Damit wird auch ein realitätsnäherer Einsatz gewährleistet. Unter diesem Gesichtspunkt sollen anschließend Untersuchungen und Ergebnisse der Siemens AG speziell im Hinblick auf Simulationen von Steuerungsstrategien für Gepäckförderanlagen vorgestellt werden.

J. Elger () Corporate Technology CT SE 5, Siemens AG Günther-Scharowsky-Str. 1, 91058 Erlangen, Deutschland e-mail: [email protected] W. Günthner, M. ten Hompel (Hrsg.), Internet der Dinge in der Intralogistik, DOI 10.1007/978-3-642-04896-8_25, © Springer-Verlag Berlin Heidelberg 2010

265

266

J. Elger et al.

Zusammenfassend wird auf die Erkenntnisse bzgl. Chancen und Herausforderungen dezentraler Anlagen eingegangen. Davon ausgehend wird eine Möglichkeit zur Migration von heutigen, zentral strukturierten Anlagen hin zu dezentralen Systemen skizziert.

25.2  A  ufgaben und Funktionsbereiche von Gepäckförderanlagen Ein ständig steigendes Passagieraufkommen, (s. Abb. 25.1), führte über die Jahre auf den Flughäfen zu immer mehr Gepäck, das in immer kürzerer Zeit abgefertigt werden musste. Anspruchsvolle Kunden der First- und Business-Class erwarten heute von den Airlines und den Flughafenbetreibern einen hohen Standard bei der Gepäckbehandlung, wie komfortable Möglichkeiten zum Check-In und minimale Umsteigezeiten, die bei modernen Flughäfen in der Größenordnung von gerade einmal 30 Min liegen. Wenn man sich die räumliche Ausdehnung eines großen Flughafens vor Augen führt, wird schnell klar, dass eine rein personelle Abwicklung des Gepäcktransportes hier sehr schnell an Grenzen stößt. Aus diesem Grund besteht das Rückgrat des Gepäcktransportes der wichtigsten internationalen Flughäfen aus einem automatischen Transportsystem, dem Baggage Handling System (BHS). Ein wesentliches Unterscheidungsmerkmal bei Baggage Handling Systemen ist die Art und Weise des Gepäcktransportes. Man unterscheidet:

2500

Internationaler Verkehr Inlandsverkehr

2000 1500 1000 500

Jahreszahlen

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

0 1997

Abb. 25.1   Entwicklung des Passagieraufkommens im weltweiten Flugverkehr [ICAO]

Beförderte Passagiere in Mio.

• Gurtfördersysteme (inkl. zugehöriger weiterer Komponenten wie z. B. Sorter) Bei Gurtförderern liegen die Koffer unmittelbar auf dem Gurt (Förderband), s. Abb. 25.2 links. Durch den direkten Kontakt mit dem Förder-Medium ergibt sich eine erhöhte mechanische Belastung für die Gepäckstücke. Ein Gurtfördersystem muss in der Lage sein, Gepäckstücke in unterschiedlichsten Formen und Beschaffenheiten (Koffer, Tasche, Paket, Ausrüstungsgegenstände wie Zelte, Schlafsäcke, Sportgeräte) zuverlässig zu transportieren, da es ansonsten bei

25   Chancen und Herausforderungen von dezentral gesteuerten

267

Abb. 25.2   Gurtfördersystem bzw. Behälterfördersystem mit Tray

Verklemmungen zu Staus oder Blockaden auf der Fördertechnik kommen kann, was einen manuellen Eingriff bedingt. • Behälterfördersysteme: In Behälterfördersystemen werden die Gepäckstücke in Behälter (Trays) gelegt, die sich in der Gepäckförderanlage bewegen, s. Abb. 25.2 rechts. Behältersysteme sind gutschonender und erreichen aufgrund der stabileren Gepäcklage im Behälter höhere Fördergeschwindigkeiten. Außerdem sind sie unempfindlicher gegenüber der Form und Beschaffenheit der Gepäckstücke. Die fest am Behälter angebrachte Identifikation bewirkt auch eine leichtere Lesbarkeit und ein besseres Tracking. Behälterfördersysteme sind allerdings auch deutlich teuerer als Gurtfördersysteme. Sie sind wegen der erforderlichen Leerbehälterrückführung auch aufwendiger. Für den Reisenden ist nur ein kleiner Teil des Baggage Handling Systems sichtbar, nämlich der Check-In-Bereich und die Gepäckausgabe, s. Abb. 25.3. Wie dort angedeutet, sorgt hinter den Kulissen ein komplexes Netzwerk von Systemen für den reibungslosen Ablauf. Die hauptsächlichen Funktionsbereiche und Aufgaben eines BHS sind in Abb. 25.4 dargestellt. • Die Aufgabe von Gepäck erfolgt am Check-In, die Rückgabe von Gepäck im Reclaim-Bereich. • Kilometerlange fördertechnische Systeme verbinden alle Quellen und Ziele des Gepäcktransports in geeigneter Weise. So umfasst allein das zu den olympischen Spielen 2008 in Peking neu errichtete Terminal T3 des Beijing Capital International Airport insgesamt 68 km Fördertechnik.

Abb. 25.3   Überblick Baggage Handling System

268 Abb. 25.4   Hauptsächliche Funktionsbereiche eines Baggage Handling Systems

J. Elger et al. reclaim

unload storage

load

sorting

transfer

screening

check-In

• Röntgensysteme, so genannte Hold Baggage Screening Systems (HBS), überprüfen den Gepäckinhalt auf möglicherweise gefährliche Gegenstände oder Güter. • Als zusätzlichen Service bieten Fluggesellschaften dem Reisenden oft die Möglichkeit, sein Gepäck komfortabel schon am Vortag der Abreise einzuchecken. Solches Gepäck wird bis zum Abflugtermin in so genannten Early Baggage Stores gepuffert. • Auf dem Vorfeld des Flughafens unterstützen die Einrichtungen des BHS das Laden und Entladen von Gepäck. Umfangreiche Sortiermöglichkeiten sorgen dafür, dass die Gepäckstücke einen optimierten Weg durch die Anlage finden und schließlich am richtigen Ziel ankommen. • Entladenes Gepäck, das für einen Weiterflug bestimmt ist (Transfer-Gepäck) wird über das BHS direkt für den richtigen Anschlussflug bereitgestellt.

25.3  T  ypische/Domänenspezifische Anforderungen für Gepäckförderanlagen Die beschriebenen Aufgaben eines BHS führen zu spezifischen Anforderungen an die Anlage: • hoher benötigter Durchsatz (Gepäckstücke pro Zeit) • niedrige Transportkosten Das Verhältnis „Euro pro gefahrenem Gepäck-Meter“ wird in Zukunft eine noch wichtigere Rolle bei der Auslegung von BHS-Systemen spielen, wobei zukünftig noch stärker eine ganzheitliche Betrachtung der Kosten über den Lebenszyklus der Anlage hinweg als „Total Cost of Ownership“ (TCO) anstelle der reinen Investitionskosten in den Vordergrund treten wird. • Hohe Verfügbarkeit (24 h pro Tag, 365 Tage pro Jahr) • Zuverlässiger Transport zum vorgesehenen Ziel mit minimalen Fehlerraten (z. B. verursacht durch nicht lesbare Identifikation) • Fähigkeit, Spitzenlasten zu bewältigen und eine Lastverteilung herbeizuführen. Diese Anforderung wird zukünftig noch höheres Gewicht erhalten angesichts des zunehmenden Anteils an Großraumflugzeugen wie dem Airbus A 380.

25   Chancen und Herausforderungen von dezentral gesteuerten

269

• Im Allgemeinen mehrere Routen von einer Quelle zu einem Ziel • Minimierte Transferzeiten von ca. 30 Min. (s. z. B. Irrgang 2008; Siemens 2009) Die Erwartungshaltung an zukünftige Automatisierungskonzepte ist, dass sie diese Anforderungen noch besser als heutige Gepäckförderanlagen erfüllen.

25.4  Identifikationskonzepte Heute erfolgt die Identifikation von Gepäckstücken über ein „Bag-Tag“, ein Band, welches beim Check-In an dem Gepäckstück angebracht wird und einen Barcode mit den relevanten Daten enthält. In Gurtfördersystemen ist die Identifikation aufwendig, da sich das Gepäckstück mit dem Bag Tag prinzipiell in beliebiger Lage auf dem Förderer befinden kann und somit eine Einrichtung erforderlich ist, die ein Rundum-Lesen aus verschiedenen Winkeln erlaubt. Dieses Problem reduziert sich bei Behälterfördersystemen. Nach dem Check-In wird das Gepäckstück auf ein Tray gelegt, welches einen fest eingebauten RFID-Tag besitzt. Gepäckstück und Tray werden datentechnisch „verheiratet“, die weitere Identifikation in der Fördertechnik erfolgt dann nur noch über das RFID-Tag, welches sich an einer definierten Stelle des Trays befindet, was die Lesbarkeit stark erleichtert. Es wird angestrebt, dass zukünftig auch der Barcode des Bag Tags durch ein RFID Tag ergänzt oder ersetzt wird, ausgewählte Flughäfen erproben diese Variante bereits im Testbetrieb. Der Vorteil besteht in einer leichteren Lesbarkeit des Tags, da die Lage des Tags relativ zur Leseeinrichtung hier nur eine untergeordnete Rolle spielt. Allerdings muss hier sichergestellt sein, dass auch das „richtige“ Tag gelesen wird und nicht etwa das des vorausfahrenden oder nachfolgenden Gepäckstücks. In einem nächsten Schritt könnte das RFID-Tag als weltweit eindeutiger Ident fest auf dem Koffer angebracht oder in dem Koffer integriert sein und das angebrachte Band mit dem Bag Tag ganz entfallen. Dies würde den Check-In-Vorgang vereinfachen, die Problematik eines verloren gegangenen Bag Tags eliminieren und das Wiederauffinden von fehlgeleitetem Gepäck erleichtern, da eine eindeutige Zuordnung zum Eigentümer möglich ist. Einen wichtigen Gesichtspunkt stellen hier zurzeit aber nach wie vor die Kosten des Tags dar. Für die Zukunft ist zu erwarten, dass RFID-Chips immer günstiger werden, sowohl solche, die nur ausgelesen werden können, als auch wiederbeschreibbare. Damit besteht die Möglichkeit, diese Identifikationstechnik zukünftig verstärkt zu nutzen. Dies ergibt grundsätzlich neue Chancen in der Handhabung von Gepäckstücken mit den bereits erwähnten Vorteilen. Für ein „Internet der Dinge“ ergibt sich damit die Möglichkeit „intelligenter“ Objekte, in diesem Fall der Koffer selbst, welche über alle benötigten Informationen selbst verfügen und ihren Weg durch die Anlage beeinflussen und steuern können. Dabei hängt es stark von der Systemarchitektur ab, wieviel Informationen tatsächlich auf dem RFID-Tag gehalten werden sollen und wie viele aus Archivierungs- und Datensicherheitsgründen rechnerseitig gespeichert werden sollen.

270

J. Elger et al.

25.5  Dezentrale Gepäckförderanlage Innovationen im Hardware-Bereich, wie z. B. günstigere RFID-Chips oder günstigere, leistungsfähigere kleine Steuerungen führen dazu, dass Ideen für neue Automatisierungskonzepte, welche schon lange immer wieder diskutiert werden heute immer realistischer werden. Dazu zählt auch eine stärkere Fokussierung auf eine Modularisierung und Dezentralisierung von Automatisierungsanlagen. Ziele bei einer Untersuchung solcher Konzepte sind neben erhöhter Flexibilität im Betrieb auch Vereinfachungen im Engineering und der Inbetriebnahme von Anlagen, welche immer komplexer werden. Im Projekt Internet der Dinge sollte speziell die Entwicklung eines wandlungsfähigen, leicht anpassbaren Materialflusssystems untersucht werden. Dieser Grundgedanke wird durch eine konsequente, funktionale Modularisierung adressiert, (s. Abb. 25.5). Dies beinhaltet die folgenden Kernaspekte: • Die Nutzung mechatronischer, funktional orientierter Module erleichtert den projektspezifischen Einsatz. • Die Unabhängigkeit der Module untereinander sorgt für eine weitgehend flexible, vereinfachte Zusammensetzung in Projekten. • Die Einbeziehung von Steuerungsfunktionalität und IT bewirkt eine Verteilung der Logik auf unabhängige Module. Dies führt zu einer Dezentralisierung der Ablaufsteuerung. • Die mechatronischen Module bieten Möglichkeiten für kundenspezifische Anpassungen. Wie in Teil III ausführlich beleuchtet ist es vor einer tatsächlichen Nutzung neuer Automatisierungskonzepte in jedem Fall notwendig, die Auswirkungen auf den gesamten Lebenszyklus einer Anlage zu untersuchen. Dies soll in diesem Kapitel speziell im Hinblick auf die Auswirkungen dezentraler Gepäckförderanlagen geschehen. Vor einer Darstellung eines möglichen Ablaufs bei dezentraler Gepäckbeförderung, d. h. also der Auswirkungen eines dezentralen Systems auf den Betrieb, soll die in den vorausgegangen Kap. 16–23 ausführlich diskutierte Vorgehensweise für das Engineering von dezentralen Anlagen hier kurz gefasst auf Gepäckförderanlagen fokussiert werden. Eine Analyse der Auswirkungen führt schließlich zu der Darstellung eines möglichen Migrationskonzepts von zentralen zu dezentralen Gepäckförderanlagen.

25.5.1  Vorabentwicklung mechatronischer Module Um den projektspezifischen Aufwand bei der Nutzung mechtronischer, vorintegrierter Module möglichst gering zu halten, müssen diese im vorab möglichst gut definiert und spezifiziert werden. Dies bedeutet die Erstellung eines mechatronischen

271

Abb. 25.5   Funktionale Modularisierung

25   Chancen und Herausforderungen von dezentral gesteuerten

272

J. Elger et al.

Modulbaukastens, der projektunabhängig im Vorfeld definiert und entwickelt wird (im Wesentlichen als Einmalaufwand, verbunden mit einem laufenden Pflegeaufwand) und es erlaubt, den einzelnen Gewerken ihre jeweiligen Sichten auf ein konsistentes Modell zur Verfügung zu stellen. Der Baukasten unterstützt die in der Designphase übliche Top-Down-Vorgehensweise durch die Bereitstellung von Modulbeschreibungen, mit denen das anfangs noch grobe Anlagenlayout sukzessive verfeinert werden kann. Standardisierte Beschreibungsmittel müssen bereitgestellt werden. Diese beinhalten benötigte Maschineninformationen z. B. bzgl. der verschiedenen Gewerke oder bzgl. der angebotenen (Transport-) Dienste. In einer Gepäckförderanlage gibt es Funktionalitäten, welche übergreifende Informationen benötigen, wie z. B. das Routing eines Koffers zu seinem Bestimmungsort oder die Zuweisung von Anlagenressourcen zu Aufgaben anhand von Auslastungen (z. B. Auswahl eines Röntgengeräts). Diese werden bisher durch zentrale Systeme ausgeführt. Solche Funktionalitäten müssen bei dezentralen Anlagen durch andere Mechanismen ersetzt werden. Dazu zählen Konzepte für die Abbildung und Verteilung dieser Steuerungslogiken, Möglichkeiten zur Kommunikation und zur Abstimmung der Module, wie z. B. Auktionen. Entsprechende Mechanismen, Technologien und Steuerungsfunktionalitäten müssen in einer Vorentwicklung für den Praxisbetrieb entwickelt werden.

25.5.2  Engineering dezentraler Anlagen Ein wesentlicher Treiber bei der Nutzung modular-dezentraler Anlagen ist der Wunsch, den projektspezifischen Engineeringaufwand bei der Erstellung und Inbetriebnahme einer solchen Anlage deutlich zu reduzieren und zu wiederholbaren Vorgängen zu kommen. Hierzu dient ein Modulbaukasten aus mechatronischen Modulen, der eine einfachere Zusammenstellung der Anlage top-down bereits während früher Planungsphasen unterstützt. Im Idealfall stellt der Vertriebsmitarbeiter bereits gemeinsam mit dem Kunden das Layout der Anlage aus diesem Baukasten zusammen, der zu diesem Zeitpunkt noch keine detaillierten Informationen, wie z. B. Fabrikat des Antriebsmotors eines Förderers enthalten muss. Allerdings muss bei Verwendung dieses Baukastens sichergestellt werden, dass, soweit möglich, auf Standard-Komponenten zurückgegriffen wird. Die weitere Detaillierung erfolgt topdown, unter Zuhilfenahme des mechatronischen Modulbaukastens. Mechatronisch bedeutet, dass ein Modul als ein „Objekt“ (wie aus der Objektorientierten Programmierung bekannt) behandelt wird, welches Anteile aus Mechanik, Elektrik, Steuerungs- und Leittechnik des bisherigen Materialflusssystems besitzt und verschiedene Sichten zu seiner Betrachtung (mechanisch, elektrisch, steuerungstechnisch, leittechnisch, etc.) bietet. Wird an einem Anteil des Objekts etwas verändert, kommt z. B. eine Lichtschranke zu einem Förderer hinzu, werden die anderen Gewerke automatisch benachrichtigt. Es existieren bereits mechatronisch orientierte Engineering-Werkzeuge, wie etwa Comos oder Automation Designer, die eine solche

25   Chancen und Herausforderungen von dezentral gesteuerten

273

Vorgehensweise unterstützen und dabei helfen, die Konsistenz und Aktualität der Daten zwischen den Gewerken sicherzustellen. Die ausgewählten Module können nun anhand der Anforderungen immer weiter konkretisiert und konfiguriert werden. Am Ende der Engineeringphase liegen dann detaillierte Planungsunterlagen für ein dezentrales System aus mechatronischen Einheiten vor. Der Aufbau und die Inbetriebnahme einer dezentralen Anlage werden durch die Nutzung mechatronischer vorintegrierter Module erleichtert. Ein wichtiger Faktor hierbei ist die Reduzierung des Integrationsrisikos durch die Verwendung mechatronischer, vorintegrierter Komponenten sowie ein frühzeitiges, realistisches Nutzen der Simulation. Darüber hinaus kann z. B. durch die Fähigkeiten der Module, untereinander zu kommunizieren ein vereinfachtes Zusammenfinden der Module erfolgen („Plug&Play“-Konzept). Die Anlagentopologie entsteht dabei letztlich dynamisch durch Abstimmung der Module. Es existieren bereits standardisierte, mechatronisch orientierte Gepäckförderanlagen, die diese beschriebenen dezentral orientierten Engineeringvorgänge unterstützen, wie z. B. Siemens SIBAG SMART, welche auf kleinere und mittlere Flughäfen abgestimmt ist (Aschenbrenner 2007).

25.5.3  Umbauten Ein weiterer Treiber für Modularisierung und Dezentralisierung ist der Bedarf, auch im Flughafenbereich mehr Flexibilität für die Betriebsphase und einfachere Umbauvorgänge zu erreichen und ein evolutionäres Wachstumskonzept im Sinne von „pay as you grow“ zu installieren (Siemens 2009). Dahinter steht die Idee, jeweils nur so viel Flughafen-Infrastruktur anzuschaffen, wie für das aktuelle Passagieraufkommen tatsächlich benötigt wird. Flughafenbetreiber möchten sich flexibel auf zukünftige Wachstumsraten einstellen und ihre Kapazitäten in kleinen Schritten ausbauen können, um teure Überkapazitäten zu vermeiden und ihr wirtschaftliches Risiko zu begrenzen. Dass das tatsächliche Wachstum der Passagierzahlen schnell und signifikant von dem prognostizierten abweichen kann, hat die Weltwirtschaftskrise in 2008 eindrucksvoll gezeigt. Da solche Umbauten im laufenden Betrieb stattfinden müssen, ist zur Risikominimierung ein Konzept vorteilhaft, bei dem das Wegnehmen bzw. Hinzufügen von Komponenten einer Gepäckförderanlage im Sinne von Plug&Play (vereinfachte Inbetriebnahme durch mechatronische, vorintegrierte Module) bereits vorgedacht und vorgetestet ist sowohl mechanisch, als auch elektrisch und steuerungstechnisch.

25.5.4  Gepäcktransport in dezentralen Systemen Um einen Eindruck zu vermitteln, wie zukünftig der Ablauf eines Transportvorganges in einem dezentralen System erfolgt, wird beispielhaft (und stark vereinfacht)

274

J. Elger et al.

ein Transportvorgang beschrieben, beginnend beim Check-In und endend bei der Verladung auf das Flugzeug. Hier wird bewusst nur die logische, nicht die räumliche Zuordnung der Funktionen beschrieben. Außerdem wird der Einfachheit halber von einem Gurtfördersystem ausgegangen (ohne Trays). Jedes Gepäckstück verfügt über ein beschreibbares RFID-Tag. Die IT-technischen Stellvertreter der beteiligten Module werden hier als „Agenten“ bezeichnet. Dies bedeutet aber nicht zwingend die Verwendung eines Agentenframeworks wie etwa JADE. Es können beispielsweise auch bekannte objektorientierte Programmiertechniken verwendet werden. Agenten repräsentieren sowohl die zu transportierenden Güter (TransportgutAgent) als auch die mechatronischen Module der Anlage, welche entsprechend benötigte (Transport-) Dienste anbieten (Fördertechnik-Agenten). Das Gepäckstück, bzw. sein Agenten-Stellvertreter kümmert sich aktiv um die Durchführung des Transports vom Ausgangspunkt zum Ziel sowie aller dazwischen benötigten Dienste wie z. B. die vorgeschriebene Durchleuchtung der Gepäckstücke. Die Zuordnung von (Transport-) Diensten zu Modulen, welche die entsprechenden Dienste anbieten erfolgt durch Auktionen (Zuteilung von Ausschreibungen und Angeboten). Es wird weiter vorausgesetzt, dass eine Anbindung an die Leitebene, welche übergreifende Informationen wie Flugpläne, Sortierpläne, Gepäck- und Passagierdaten enthält, existiert. Diese Ebene wird nachfolgend als Airport Management System (AMS) bezeichnet, sie wird von einem spezialisierten Agenten bedient, der die Kommunikation zu dem AMS als Dienst zur Verfügung stellt. Prinzipieller Ablauf des Transports:   1. Am Check-In beschreibt ein Angestellter das RFID-Tag mit Passagier- und Flugdaten, befestigt das Tag am Koffer (sofern der Koffer nicht bereits ein eingebautes Tag enthält), schaltet das Förderband an und veranlasst so den Abtransport.   2. Für das Gepäckstück wird ein Transportgut-Agent erzeugt (z. B. auf einem Controller, einer SPS, einem PC oder einer sonstigen Ablaufumgebung). Seine agentenbezogenen Daten können sowohl direkt auf dem RFID-Chip des Transportgutes gespeichert werden oder rechnerseitig hinterlegt sein.   3. Der Transportgut-Agent hat noch kein konkretes Transport-Ziel vorgegeben sondern kennt nur den Flug zu welchem das Transportgut zugeordnet ist. Er startet über den AMS-Schnittstellendienst eine Abfrage, welcher Workflow abgearbeitet werden muss und zu welchem Gate der Flug zugeordnet ist, wie z. B.: „Welche Ziele müssen abgearbeitet werden?“ Das Ergebnis ist ein Zielbaum mit Einzelzielen, wie z. B.:   a)  Hole Freigabe von Sicherheitsdurchleuchtung (Röntgen) Stufe 1   b)  Fahre zu deinem Gate   4. Der Transportgut-Agent braucht nun die Zuteilung eines Moduls, das Aufgabe a) erfüllen kann. Er startet eine Ausschreibung: „Wer kann Freigabe Sicherheitsdurchleuchtung Stufe 1 geben?“. Die Auswahl im Rahmen einer Auktion kann nun entweder so erfolgen, dass die Agenten der Röntgeneinrichtungen jeweils ein Angebot abgeben, welches die relevanten Parameter, wie z. B. Länge des Weges dorthin, Länge ihrer Warteschlangen enthält und sich der Gepäckstück-Agent nach vorher festgelegten Regeln für eine bestimmte Röntgenanlage entscheidet

25   Chancen und Herausforderungen von dezentral gesteuerten

„Ich muss jetzt durchleuchtet werden“

Auktion

275 „Ich kann durchleuchten“

„Ich kann durchleuchten“

Abb. 25.6   Nachfrage und Angebot zur Auswahl von Ressourcen

oder aber die Agenten der Röntgenanlagen verhandeln untereinander, wer den Zuschlag zum Röntgen für dieses Gepäckstück bekommt und senden dem Gepäckstück-Agenten eine entsprechende Information, zu welcher Röntgenanlage er fahren soll. Dieses Prinzip von Nachfrage und Angebot ist in Abb. 25.6 dargestellt. Diese Abstimmmechanismen erlauben eine sehr flexible Reaktion auf Auslastungsschwankungen bzw. Störungen der Fördertechnikmodule.   5. Der neue Zustand des Transportgut-Auftrags („auf dem Weg zum ersten Röntgen in Röntgenanlage x“) wird auf das Tag geschrieben.   6. Bei jeder Entscheidungsstelle (z. B. Weiche) fragt der Transportgut-Agent den zugehörigen Fördertechnik-Agenten nach dem Weg zu seinem Ziel („Wo geht es hier zu Röntgenanlage x?“). Dieser verfügt durch Kommunikation mit seinem Nachbarn über die benötigte dezentrale Routing-Information, welche erzeugt wird, indem Information über vorhandene bzw. verfügbare Module entgegen der Förderrichtung „upstream“ an die Vorgänger-Module propagiert werden. Aufgrund dieser Informationen sorgt der Entscheidungsstellen-Agent für den Weitertransport in Richtung Röntgenanlage x. Siehe hierzu auch Abschn. 13.5.1.   7. Bei Ankunft im HBS-12 wird die Sicherheitsdurchleuchtung durchgeführt (Anfrage: „Gib mir Freigabe Stufe 1“). Wenn die Durchleuchtung erfolgreich war, wird das Ziel als erledigt markiert, anderenfalls kann HBS-12 das aktuelle Ziel gemäß seinem Workflow ersetzen: „Hole Freigabe Stufe 2 ein“.   8. Nachdem Schritt a) abgearbeitet ist, wiederholt der Transportgut-Agent Schritt 4 mit Ziel b). Jetzt meldet sich z. B. Gate 08.   9. Der neue Zustand des Transportgut-Agenten wird wieder auf das Tag geschrieben. 10. Analog zu 6. und 7. fährt das Transportgut jetzt zu Gate 08. 11. Dort angekommen wird das Ziel als erfüllt markiert, der Zustand wieder auf dem Tag abgespeichert.

25.6  Konzepte zur Betriebsführung In den vorausgegangenen Kapiteln wurde die Bedeutung des Engineerings für den Erfolg dezentraler Konzepte betrachtet. Wie in Kap. 13 und Abschn. 25.5.1 bereits ausgeführt, müssen auch Gesichtspunkte und Konzepte der Betriebsführung solcher

276

J. Elger et al.

Anlagen bereits beim Entwurf des modularen Baukastensystems mit vorausgedacht werden, um aus den Teilfunktionalitäten der Module im Zusammenspiel eine insgesamt funktionsfähige Anlage zu erhalten. Da sich die Gesamtfunktionalität des Systems erst durch die Interaktion aller Module zur Laufzeit ergibt, ist es hilfreich wenn nicht gar notwendig, die Simulation als Werkzeug bereits während des Engineerings von Gepäckförderanlagen zu nutzen. Simulation ist ein sehr effizientes Werkzeug, um Lösungen für komplexe Systeme zu verifizieren. Simulation kann aber auch Teil der Lösung sein. In diesem Abschnitt wird die Verwendung von Simulationstechniken für beide Varianten betrachtet. Zunächst werden die Erkenntnisse aus den Simulationsstudien einer Gepäckförderanlage eines Flughafens mittlerer Größe zusammengefasst, die im Rahmen des Forschungsprojekts „Internet der Dinge“ entstanden sind. Im Weiteren wird skizziert, wie Simulation zur dezentralen Steuerung einer Gepäckförderanlage gewinnbringend eingesetzt werden kann.

25.6.1  Simulation als Werkzeug Die optimale Einstellung und Überprüfung von Abläufen und Steuerungsstrategien großer Gepäckförderanlagen sind auf Grund ihrer enormen Komplexität ohne Simulation nur schwer durchführbar. Über die Simulation wird das Verhalten nachvollziehbar und sie ist damit ein wichtiger Schritt bei der Untersuchung der Chancen und Herausforderungen beim Betrieb von dezentral gesteuerten Anlagen. Betrachtet man den in Abschn. 25.5.4 beschriebenen prinzipiellen Ablauf eines Transports, so treten die Punkte 4. und 6. auf Grund ihrer strategischen Natur hervor. Die beiden beteiligten Agenten, der Transportgut- und der Entscheidungsstellen-Agent, müssen nicht nur die Umsetzung der verschiedenen Transportbedingungen sicherstellen. Ihre Entscheidungen bestimmen die Lastsituation in der gesamten Anlage und somit den erfolgreichen Transport nur mittelbar betroffener Transportgüter. Am Beispiel des Entscheidungsstellen-Agenten soll dargestellt werden, dass naheliegende Lösungen in dezentralen Anlagen sich als weniger geeignet herausstellen können. Weiterhin wird gezeigt, dass sich die Aufgabe des Entscheidungsstellen-Agenten sehr gut lösen lässt, durch den Einsatz von der dezentralen Situation angepassten Strategien. Zunächst soll ein vergleichsweise einfaches Routingverfahren mit Hilfe von Simulation untersucht werden. Das Verfahren wählt für einen Transportauftrag den schnellsten Weg zum Ziel. Von diesem Weg weicht es erst sehr spät ab, wenn ein Modul auf dem Weg fast vollständig ausgelastet ist. Derartige Verfahren werden in vielen Bereichen erfolgreich eingesetzt. Ihnen liegt die Idee zu Grunde, dass eine möglichst kurze Verweildauer im System zu einer geringen Systemlast führen sollte. Abbildung 25.7 zeigt die Situation in einer Beispielanlage kurz nach Einlastbeginn der ersten Transportgüter. Im dargestellten Szenario ist der größte Teil der den Transportgütern zugeordneten Gates nur über den unteren Sortierkreis zu erreichen.

25   Chancen und Herausforderungen von dezentral gesteuerten

sorter

check in

transfer

277

sorter

Abb. 25.7   Situation kurz nach Einlastbeginn bei einem einfachen Routingverfahren

Diese Strategie führt zu einer ungleichmäßigen Belastung der verschiedenen Zuführungen zum unteren Sortierkreis. Diese Schieflast ist ungünstig, sobald sich der Durchsatz auf den benutzten Strecken dem Maximum nähert. Die Robustheit der Anlage gegen kurze Unterbrechungen oder andere Ereignisse sinkt. Ein Verfahren, nach welchem Abweichungen des Transportgutes vom schnellsten Weg zulässig sind, muss eine strategische Komponente beinhalten, welche die zusätzliche Verweilzeit in der Anlage gegen Vorteile im Anlagenzustand abwägt. Abbildung 25.8 zeigt die analoge Situation zu Abb. 25.7 bei Verwendung eines entsprechenden Routingverfahrens. Die Transportgüter sind auf die verschiedenen Wege zum unteren Sortierkreis verteilt. Einige Transportgüter verbleiben daher länger in der Anlage. Da jedoch alle Teile der Anlage unterhalb des maximalen Durchsatzes gefahren werden, ist der Anlagenzustand robuster und die Gesamtverweil-

sorter

check in

transfer

sorter

Abb. 25.8   Situation kurz nach Einlastbeginn bei einem strategischen Routing

278

J. Elger et al.

dauer aller Transportgüter kann durchaus kleiner sein als beim ersten Verfahren. Das im Kontext dezentraler Anlagen Entscheidende an diesem Verfahren ist, dass es kein spezifisches Wissen über mögliche Einlastszenarien oder Besonderheiten der Topologie erfordert. Es kann sich vollständig selbst konfigurieren. Bisher ist Simulation nur als Werkzeug zum Testen und Vergleichen unterschiedlicher Fragestellungen wie z. B. Routingverfahren während der Designphase eingesetzt worden. Wie Simulation darüber hinaus als Bestandteil eines effizienten Routingverfahrens in der Betriebsphase genutzt werden kann, wird nach der Überblicksbeschreibung des strategischen Routingverfahrens skizziert.

25.6.2  Strategisches Routingverfahren In der der Abb. 25.8 zu Grunde liegenden Simulation wurde das Verfahren aus Abschn. 13.5.3 eingesetzt. Das Verfahren lässt sich kurz zusammengefasst wie folgt beschreiben. Die Zeit wird diskretisiert in Zeitfenster gleicher Größe, in obiger Simulation 20 s. Einem Transportgut ist immer sein Restweg zum Ziel zugeordnet. Auf Basis dieses Restwegs werden die Zeitfenster bestimmt, zu denen das Transportgut die Module auf seinem voraussichtlichen Weg erreichen wird. Jedes Modul verfügt für jedes zukünftige Zeitfenster (bis zu einem maximalen Zeithorizont) über einen Zähler, der die Anzahl erwarteter Transportgüter innerhalb des Zeitfensters repräsentieren soll. Diese Zähler werden verwendet, um Strafzeiten bei Benutzung des entsprechenden Moduls zuzuweisen; je höher die im Eintrittzeitfenster prognostizierte Auslastung des Moduls, umso höher ist die Strafzeit. Die Bestimmung eines schnellsten Weges schließt diese Strafzeiten mit ein. Von Zeit zu Zeit wird der einem Transportgut zugeordnete Weg als neuer schnellster Weg bestimmt. Der entscheidende offene Punkt ist die Bestimmung der Anzahl der in einem Zeitfenster am Modul erwarteten Transporteinheiten. Diese Zählerwerte werden durch eine zyklische Erhöhung, die durch die Eigensimulation der Transportgüter ausgelöst wird, und einen exponentiellen Zerfallsprozess, der die sukzessive Leerung der jeweiligen Transportbänder simuliert, festgelegt. In dezentralen Anlagen ist das durch eine Eigensimulation der Anlage wie im folgenden Kapitel beschrieben realisierbar.

25.6.3  Eigensimulation Die Bestimmung der zukünftig an einem Modul zu erwartenden Transportgüter stellt sich vordergründig als nur zentral zu lösenden Aufgabe dar. Dem stehen die Anforderungen eines echten mechatronischen Modulbaukastens entgegen, dass ein Modul vollständig über alle Gewerke nach außen abgekapselt ist, s. Abschn. 25.5.2. Diese Anforderungen beinhalten im Fall von Gepäckförderanlagen eine große Chance, denn auf Grund der vollständigen Abgeschlossenheit kann für ein Modul

25   Chancen und Herausforderungen von dezentral gesteuerten

279

zum Zeitpunkt des Engineering das Bearbeitungsverhalten des Moduls für einen spezifischen Transportauftrag formal beschrieben werden. Wird einem Modul per IT-Struktur die Ankunft eines Transportguts zu einem bestimmten Zeitpunkt mitgeteilt, so kann das Modul auf Basis des eigenen und des bekannten Umgebungszustands die Bearbeitung dieses Transportauftrags simulieren. Mithin ist eine dezentrale Gepäckförderanlage in der Lage, ihr eigenes zukünftiges Verhalten selbst zu simulieren. Die Transportgüter werden dabei, in Vorwegnahme der Zukunft, per IT-Struktur virtuell von einem Modul an das nächste übergeben. Am Ende einer solchen, schnellen Eigensimulation der Gepäckförderanlage stehen die benötigten zukünftigen Lastdaten aller Module zur Verfügung. Dem zu implementierenden Routingverfahren müssen diese Daten nur noch zugänglich gemacht werden. Abbildung 25.9 verdeutlicht den prinzipiellen Aufbau eines Steuerungsrechners mit einer Eigensimulationskomponente. Die konsequente Dezentralisierung ermöglicht somit eine sehr transparente Umsetzung einer vermeintlich nur zentral zur lösenden Aufgabe. Nach Festlegung der Datenschnittstellen für die Eigensimulation und das Routingverfahren integriert sich jedes neu entwickelte Modul sofort, ohne dass es einer Anpassung der strategischen Komponente der Steuerung bedarf. Dabei ist unerheblich, wo die Eigensimulatoren lokalisiert sind: Sie können entweder physikalisch oder nur logisch an ihre Module gekoppelt sein, wobei sie im letzteren Fall

Nachbarsteuerungen

Aktuatoren Sensoren

Input

Steuerungskomponente

Anlagenzustand

Steuerungsparameter

Eigensimulator

Steuerungsoptimierer

Output

Einlastplan

zukünftiger Anlagenzustand

Nachbareigensimulatoren

Abb. 25.9   Architektur eines Steuerungsrechners mit Eigensimulator

Nachbarsteuerungsoptimierer

280

J. Elger et al.

z. B. IT-technisch auf einem Leitrechner realisiert sind und als parallele Prozesse arbeiten. Die Eigensimulation muss nicht so genau wie möglich die vermutliche Zukunft vorweg nehmen. Bei dem in Abb. 25.8 verwendeten Verfahren wurden z. B. Stausituationen vernachlässigt: Ein Modul m, welches über die virtuelle Ankunft eines Transportguts zur Zeit t informiert wird, meldet an das entsprechende Nachfolgemodul die virtuelle Ankunft des Transportguts zur Zeit t + , wobei  die Durchlaufzeit durch Modul m bei Last null ist. Die Interpretation dieser einfachen Simulation der nahen Zukunft erfolgt durch das eingesetzte Routingverfahren. Die auf Basis der Eigensimulationsergebnisse modifizierte Routenwahl führt zu einer Rückkopplung bei Durchführung der nächsten Eigensimulation: Ist ein Modul von starkem Stau bedroht, so ist es auch sehr stark ausgelastet und wird mit einer hohen Strafzeit belegt.

25.6.4  Ergebnis und Herausforderungen Hoch dynamische Anlagen mit einem großen zeitlichen Verzug zwischen der zu treffenden Entscheidung und dem messbaren Eintreten der Konsequenzen erfordern strategisch orientierte Steuerungen, Gepäckförderanlagen in Flughäfen sind dafür ein Beispiel. Globale Informationen ermöglichen solche strategischen Steuerungen. Die Gewinnung globaler Information ist jedoch oft mit einem hohen Kommunikationsaufkommen sowie Rechenaufwand verbunden. Hat die Information auf Grund der Dynamik in der Anlage keinen langen Bestand, so ist sie meist schon mit Abschluss der Berechnungen veraltet und im schlimmsten Fall nicht mehr verwertbar. Die mit Hilfe von Simulation durchgeführten Untersuchungen haben gezeigt, dass in dezentralen Anlagen sehr effiziente strategisch orientierte Steuerungen realisiert werden können. Dabei kann weitgehend auf die Gewinnung globaler Informationen verzichtet werden. Insbesondere ist keine zentrale oder duplizierend dezentrale Speicherung von globaler Information notwendig. Die Untersuchungen haben zu dem gezeigt, dass die Wahl der richtigen Informationsgenauigkeit entscheidend für die Effizienz dezentraler Verfahren ist. Die gewonnenen Daten müssen einerseits ausreichend detailliert sein, um strategische Entscheidungen zu ermöglichen. Andererseits darf der erforderliche Kommunikations- und Rechenaufwand nicht zu hoch werden, um die Daten zur rechten Zeit bereitstellen zu können. Hervorzuheben ist mit Blick auf eine zukünftige Realisierung dezentraler Anlagen, dass sie auf unterster Ebene mit dem Aufbau heutiger Anlagen übereinstimmen können. Betrachtet man die Architektur einer klassischen Steuerung mit Materialflussrechner mit derjenigen Architektur aus Abschn. 25.6.3, so sind die Gemeinsamkeiten offensichtlich, vgl. Abb. 25.9 u. 25.10. Auch in der dezentralen Anlage können die einzustellenden Steuerparameter klassische Routingtabellen sein. Der Übergang von einer zentral gesteuerten und geplanten Anlage zu einer dezentral gesteuerten Anlage kann daher in wichtigen Teilen evolutionär gestaltet werden. Insbesondere für den noch ausstehenden Nachweis einer echtzeitfähigen, strategisch orientierten Steuerung einschließlich IT-Infrastruktur ist diese flache Einstiegshürde von Vorteil.

25   Chancen und Herausforderungen von dezentral gesteuerten

281

Nachbarsteuerungen

Sensoren

Input

Aktuatoren

Steuerungskomponente

Anlagenzustand

Einlastplan

Steuerungsparameter

Output

zentraler Materialflussrechner

Abb. 25.10   Klassische Architektur mit zentralem Materialflussrechner

25.7  Migrationskonzept In den vorausgegangenen Kapiteln wurde gezeigt, dass dezentrale Systeme ihre Stärken in unterschiedlichen Phasen des Anlagen-Lebenszyklus ausspielen können. Während des Engineerings bieten solche Systeme die Chance, die bisherige nach Gewerken getrennte Vorgehensweise durch einen integrierten, mechatronisch orientierten Ansatz aufzubrechen. Ein gemeinsames, mechatronisches Datenmodell bzw. Objektmodell bietet die Chance, Datendurchgängigkeit zu erreichen und den beteiligten Disziplinen ihre jeweils benötigten Sichten auf dieselben Daten zur Verfügung zu stellen. Dies verringert die Gefahr inkonsistenter Daten, vor allem bei nachträglichen technischen Änderungen. Der Aufbau und die Inbetriebnahme einer Anlage aus dezentralen Komponenten können durch ein Plug&Play-Konzept unterstützt werden, bei dem sich die einzelnen Komponenten einfach zusammenfügen lassen und sich selbst konfigurieren. Dies ist für lokal vorhandene Funktionalität gut vorstellbar, beispielsweise können einzelne Förderelemente sich auf diese Art mechanisch, elektrisch und steuerungstechnisch miteinander verbinden. Die Vorteile dezentraler Automatisierungstechnik während des Betriebs und bei Umbauten zeigen sich in der Flexibilität sowohl im Hinblick auf Änderungen der Arbeitslasten oder von Workflows als auch bei Ausfall, Reparatur oder Erweiterung von Komponenten. Damit ist es möglich, dynamisch auch auf unvorhergesehene Ereignisse zu reagieren. Im Hinblick auf die Systemarchitektur stellt sich die Frage, ob es technisch und wirtschaftlich sinnvoll ist, jedes Förderelement mit einer eigenen Steuerung auszustatten. Schwieriger wird dies noch bei Funktionen, die bisher zentral vorhanden sind, beispielsweise einem Leitsystem oder einem Visualisierungssystem. Es genügt dabei nicht, diese Funktionen einfach nur geschickt zu verteilen, es sind neuartige

282

J. Elger et al.

Konzepte nötig, die dazu führen, dass die Struktur der bisherigen Automatisierungsund Leitebene sich grundlegend ändert. Solche dezentralisierten Systeme arbeiten somit auf einem anderen Abstraktionsniveau, statt konkreter Funktionalität werden Regeln für die Zusammenarbeit definiert, die dann z. B. von einem Agentenframework in Form von Auktionen oder anderen Mechanismen abgearbeitet werden. Bisherige Implementierungen basierten vor allem auf Entwicklungen im universitären Umfeld. Erste Schritte im Hinblick auf einen Transfer in die Praxis, d. h. auf eine Anpassung an industrielle Anwendungen speziell im Automatisierungsumfeld, werden gegenwärtig durch die Erstellung von Demoanlagen bei den Industriepartnern des Internet-der-Dinge-Projektes begonnen und sollen in Folgeprojekten fortgeführt und vertieft werden. Ein weiterer wichtiger Aspekt für die wirtschaftliche Machbarkeit dezentraler Systeme sind auch die domänenspezifischen Anforderungen der Kunden. Beispielsweise existieren für Gepäckförderanlagen umfangreiche und sehr konkrete Festlegungen der Kunden (i. a. Flughafenbetreiber), wie die Automatisierungsarchitektur einer solche Anlage aufgebaut sein muss. Ein solches System muss auch mit entsprechender Sicherheit ausgestattet sein. In diesem Zusammenhang sind im Hinblick auf Datenhaltung und Datensicherheit noch einige Fragestellungen zu klären, wie z. B. Transaktionssicherung, Datenverteilung/-persistenz, Redundanzen, Backup-/Wiederherstellungskonzepte, Logging/Tracing von Ereignissen, etc. Um diesen Erkenntnissen Rechnung zu tragen und trotzdem die Vorteile eines dezentralen Ansatzes nutzen zu können, wird die nachfolgend skizzierte Vorgehensweise vorgeschlagen. Dies geschieht in Anlehnung an die Richtlinie VDI2206, welche die Entwicklungsmethodik für mechatronische Systeme beschreibt. Dabei wird zwischen einer funktionalen und räumlichen Sicht auf die mechatronischen Module unterschieden: „Die funktionale Integration von mechanischen und elektrischen/ elektronischen Komponenten erfolgt durch Verbindung mittels Stoff-, Energie- und Informationsflüssen. Die Komponenten können hierbei räumlich getrennt angeordnet sein. Bei der räumlichen Integration bilden die mechanischen und elektrischen/ elektronischen Komponenten eine bauliche Einheit im Sinne einer gemeinsamen Gestalt.“ (VDI 2206, 2004) Auch wenn diese Richtlinie mehr auf den Bau von mechatronischen Produkten, wie z. B. eine Bremsanlage abzielt und weniger das Anlagenengineering im Fokus hat, lassen sich die dort festgehaltenen Erkenntnisse gut verwenden. Ein vielversprechender Ansatz in diesem Zusammenhang besteht darin, einerseits das Engineering mechatronisch, d. h. unter Zuhilfenahme eines Baukastens aus unabhängigen mechatronischen Komponenten logisch dezentral durchzuführen, andererseits die eigentliche Anlage aber physisch/technisch zentral (z. B. mit zentralem Leitsystem) aufzubauen. Beispielsweise enthält eine solche mechatronische Komponente auch Steuerungscode für ein SPS-Programm, welches im Rahmen der Planung und des Engineerings als logisch integrierter Bestandteil der mechatronischen Komponente behandelt wird. Im Rahmen der Anlageninstallation verzichtet man dann auf die räumliche (d. h. vollständig dezentrale) Integration, und führt stattdessen ein Mapping auf ein zentrales Automatisierungssystem durch, s. Abb. 25.11. Oben erwähnter Steuerungscode

25   Chancen und Herausforderungen von dezentral gesteuerten

283

Abb. 25.11   Anlageninstallation – Migrationskonzept

einer Komponente würde nach dieser Logik nicht auf einem dezentralen Controller ablaufen, der auch räumlich an der mechatronischen Komponente befestigt ist, sondern einer SPS zugewiesen werden, auf der er zum Ablauf kommt und sich, da vorgetestet und mit entsprechenden Mechanismen ausgestattet, einfach integriert. Der Begriff SPS steht hier stellvertretend für eine klassische SPS, eine Soft-SPS wie Win AC, eine Einschubkarte oder andere Lösungen, z. B. auf PC-Basis. Hierdurch ist es zum einen möglich auf bewährte Anlagentechnik aufzusetzen und trotzdem bereits die Vorteile eines mechatronisch basierten Engineerings zu nutzen. Zum anderen lässt sich ein Migrationskonzept hin zu tatsächlich dezentral aufgebauten Anlagen entwickeln. Die so entstandene Anlage hat „von außen“ betrachtet im Wesentlichen das gleiche Aussehen wie eine bisherige, zentrale Anlage, ist aber auf andere Art und Weise entstanden und in ihrem Inneren anders aufgebaut. In nachgelagerten Schritten kann dann eine weitergehende räumliche Dezentralisierung erfolgen.

25.8  Zusammenfassung Dezentrale Automatisierungssysteme müssen wie auch heutige Systeme die domänenspezifischen Anforderungen an Gepäckförderanlagen z. B. im Hinblick auf Transportdienste und Routing erfüllen. Im Rahmen des Forschungsprojekts Internet

284

J. Elger et al.

der Dinge konnte an exemplarischen Systemen eine entsprechende, theoretische Machbarkeit nachgewiesen werden. Darüber hinaus ergeben sich durch ein modular-dezentrales System u. a. die folgenden Vorteile: • Das Arbeiten mit einem mechatronischen Modulbaukasten führt zu einem effizienteren Engineering, da die verschiedenen gewerkespezifischen Sichten auf die Module konsistent zusammengehalten werden können. • Die Verteilung und Kapselung der logistischen Funktionalitäten bewirken eine weitgehend unabhängige Entwicklung der einzelnen Module. • Vorintegrierte Module erleichtern Inbetriebnahme und Umbauten. • Das System ermöglicht eine flexible und adaptive Betriebsführung, z. B. bei Änderungen der Arbeitslasten oder Ausfall einzelner Module. Wie in Abschn. 25.7 aufgezeigt existieren allerdings noch einige Herausforderungen bzw. offene Punkte: • Der technisch und wirtschaftlich sinnvolle Grad der Dezentralisierung ist domänen- und geschäftsspezifisch zu ermitteln (z. B. Ausstattung jedes mechatronischen Moduls mit einer eigenen Steuerung vs. Aggregation zu größeren Einheiten) • Die Ausgestaltung eines modularen Baukastens ist festzulegen. Ein wichtiger Aspekt hierbei ist das Finden einer geeigneten, praxisgerechten Granularität der Module. • Die bisherigen, eher theoretischen Ergebnisse müssen in die industrielle Praxis überführt werden, insbesondere unter Berücksichtigung von Anforderungen im Automatisierungsumfeld. Auf Grund der Vorteile und bisheriger (teils theoretischer) Ergebnisse sind Modularisierung und Dezentralisierung auch bei Gepäckförderanlagen zukunftsweisende Themen – eine mögliche Form der Migration wurde in Abschn. 25.7 skizziert. Dieser Weg erlaubt eine schrittweise Einführung dezentraler Systeme ohne technologischen Bruch und parallel die Beantwortung der aktuell noch offenen Fragen. Eine industrietaugliche Implementierung der Forschungsergebnisse ist bereits in einem nachfolgenden Forschungsprojekt vorgesehen.

Kapitel 26

Ein dezentral gesteuertes Kommissionierlager Dirk Gehlich, Artur Luft und Sergey Libert

26.1  Einleitung Das Kommissionieren wird in der VDI-Richtlinie 3590 als die Aufgabe definiert, „aus einer Gesamtmenge von Gütern (Sortiment) Teilmengen aufgrund von Anforderungen (Aufträge) zusammenzustellen“. Die Abläufe in einem Kommissionierlager sind ein nachgelagerter Prozess der Produktion, welcher den Warenfluss zwischen dem Hersteller und dem Endverbraucher regelt und als Puffer dient. Der Vorgang Kommissionieren regelt eine meist auftragsbezogene Zusammensetzung von Gütern und Waren aus Ganz- oder Teilladeeinheiten. Aufgrund unterschiedlicher Anforderungen und branchentypischer Besonderheiten existieren Lager in verschiedenen Ausprägungen. Sie lassen sich nach der zu fördernden Transporteinheit (TE) (z. B. Paletten oder Behälter), nach dem Verwendungszweck (z. B. Puffer-, Nachschub-, Versand-, Zolllager), nach der Branche (Chemie-, Nahrungsmittel-, Automobilbranche oder Großhandel) oder in manuelle, funkgesteuerte und halboder vollautomatisierte Lager unterscheiden. Steigender Kostendruck und die Forderung nach immer kürzeren Lieferzeiten haben in der Vergangenheit dazu geführt, dass automatisierte Lager immer weitere Verbreitung gefunden haben. Aufgrund des Preisverfalls der letzten Jahre ist ein teilweise oder voll automatisiertes Lager zunehmend auch für kleinere bis mittlere Unternehmen attraktiv. Ansätze wie Just-In-Time und Just-In-Sequence prägen heute die Produktion und stellen hohe Anforderungen an die gesamte Lieferkette (Bullinger u. ten Hompel 2007). Unabhängig von der Steuerungsphilosophie steigen in diesem Zusammenhang die Anforderungen an die Ausfallsicherheit und eine hohe Flexibilität der Materialflusssysteme. Durchsatzoptimierung und Durchsatzsteigerung verbunden mit ressourcen-, tages- und produktionsbezogener Lastverteilung erhöhen die Komplexität, die eine hohe Abhängigkeit verschiedener Prozesse aller beteiligten Systemkomponenten untereinander herbeiführt. Insbesondere bei D. Gehlich () Softwareingenieur Materialflusssysteme, viastore systems GmbH Magirusstraße 13, 70469 Stuttgart, Deutschland e-mail: [email protected] W. Günthner, M. ten Hompel (Hrsg.), Internet der Dinge in der Intralogistik, DOI 10.1007/978-3-642-04896-8_26, © Springer-Verlag Berlin Heidelberg 2010

295

296

D. Gehlich et al.

den Hochleistungsbehälterförderanlagen (Fördergeschwindigkeit ≥ 2 m/s) erreichen Rechner und Netzwerke ihren Grenzbereich. Heute bekannte Materialflusssysteme zeichnen sich durch zentralisierte, statische Lösungen aus. Zum Beispiel basiert die Wegfindung von Transporteinheiten auf festgelegten Routen, die keine Anpassung während des Betriebs zulassen. Sämtliche Adressierungs- und Routinginformationen sind in einem zentralen Datenbestand des Materialflusssystems abgelegt. Somit ist die Verarbeitung der Informationen nicht optimal auf Controller und Steuerungsrechner verteilt und es entsteht eine unnötig hohe Netzlast. Das neue Steuerungsparadigma Internet der Dinge erlaubt eine Verteilung der Steuerungsaufgaben auf mehrere Knotenrechner, bei gleichzeitiger Verringerung der Softwarekomplexität. Aktuell werden die steuerungsrelevanten Informationen in unterschiedlichen Steuerungssystemen (z. B. LVS, MFS, RBG, FT) erfasst und verwaltet. Ändert sich beispielsweise der Status einer Transporteinheit (z. B. Ortswechsel oder Änderung des Auftragsstatus), so müssen entsprechende Datensätze in den unterschiedlichen Lagersteuerungssystemen durch aufwendige Kommunikationsabläufe aktualisiert werden. Im Fehlerfall kann dies zu inkonsistenten Datenbeständen und zu einem Fehlverhalten des Lagersteuerungssystems führen. Diese Problematik kann im Internet der Dinge durch die Verlagerung der Datenhaltung auf die Transporteinheiten unter Verwendung aktueller RFID-Technologie gelöst werden.

26.2  Moderne Kommissionierlager Im Laufe der Zeit haben sich verschiedene Lagerformen entwickelt, die sich für unterschiedliche Anwendungsfälle eignen. Prinzipiell können drei Grundformen unterschieden werden: manuelle, funkgesteuerte und automatische Lager. Manuelle Lager Das manuelle Lager ist die klassische Form des Lagers. Die Ware wird in nahezu beliebiger Weise in Regalen oder auf der Fläche gelagert. Die Bedienung des Lagers erfolgt manuell durch die Bediener, indem sie sich zu Fuß oder mit Staplern zur Ware hin bewegen, um diese zu holen. Daher wird dieses Prinzip Mann-zur-Ware genannt. Funkgesteuerte Lager Das Funklager arbeitet wie das manuelle Lager nach dem Prinzip Mann-zur-Ware. Die Bediener fahren mit Staplern zur Ware, die in Regalen oder in der Fläche gelagert ist. Im Unterschied zum manuellen Lager sind die Bediener dabei aber mit Funk-Terminal und Scanner ausgestattet. Automatische Lager Das Automatiklager unterscheidet sich grundlegend von den anderen beiden Formen. In ihm wird die Ware mit Hilfe von automatischer Fördertechnik aus den

26  Ein dezentral gesteuertes Kommissionierlager

297

Abb. 26.1   Automatisches Palettenlager mit Vorzone

Regalen hin zum Arbeitsplatz (Kommissionierplatz) gebracht. Das Prinzip wird daher auch Ware-zum-Mann genannt. Abbildung 26.1 zeigt beispielhaft den Aufbau eines automatischen Palettenlagers. Das Regalbediengerät (RBG) (1) holt die palettierte Ware aus den Regalen und bringt sie zu den Förderbändern, die sie bis zum Arbeitsplatz (2) transportieren. Hier kann der Bediener die benötigte Menge, die ihm auf seinem Bildschirm angezeigt wird, entnehmen. Die Palette mit der Restmenge wird danach in das Regalfach zurückgebracht. Wird eine vollständige Palette benötigt, kann sie über die Stichstrecke (3) aus dem Lager gefahren und von einem Stapler aufgenommen werden. Bei entsprechender Ausstattung können hier auch neue Paletten aufgesetzt und von der Fördertechnik in freie Fächer eingelagert werden. Die Steuerung aller Abläufe von der Auftragsverarbeitung über die Aktivierung des Regalbediengeräts bis hin zur Darstellung der relevanten Daten auf dem Arbeitsplatzbildschirm wird vom Lagerverwaltungssystem und den integrierten bzw. untergeordnetem Materialflusssteuerungen übernommen. Die Förderstrecke zwischen den Regalen und dem Arbeitsplatz kann dabei beliebige Länge und Struktur annehmen.

26.3  Referenzanlage Um möglichst viele Ablaufszenarien einer Materialflusssteuerung abzubilden und typische Abläufe in einem Kommissionierlager darzustellen, wird im Folgenden eine Referenzanlage der viastore systems GmbH im Internet der Dinge beschrieben. Das Lager erstreckt sich über fünf Ebenen und dient als Puffer zwischen Produktion und Versand. Es ist in spezielle Lagerbereiche unterteilt, die durch ein Materialflusssystem miteinander verbunden sind (s. Abb. 26.2).

298

D. Gehlich et al. Warenausgang

Kartonaufrichter

A-Lager

B/C-Lager

Sorter

Universalpackplätze

Abb. 26.2   Lagerbereiche der Referenzanlage (viastore systems GmbH)

Die Ladeeinheiten werden auf der Fördertechnik, bestehend aus Rollen-, Bandbzw. Kettenförderern und den Fördertechnikplätzen (conveyor location, ConvLoc), durch das Lager transportiert. Zu Beginn jedes Versandauftrags, der mehrere Kartons umfassen kann, wird der Karton beim Kartonaufrichter mit der Kommissioniertransporteinheit (KTE) gemeinsam eingescannt und somit logisch für die Transportdauer mit ihr verknüpft. Die KTE wird zunächst, je nach Auftragspositionen, zum A-Lager und/oder zum B/C-Lager befördert. Im A-Lager befinden sich Waren, die häufig nachgefragt werden. Dieses Lager verfügt über 29 Kommissionierbahnhöfe, die einzeln von den KTE angefahren werden können. An den Bahnhöfen werden die Artikel vom Bedienpersonal in der angezeigten Menge aus dem Lagerbehälter entnommen und in die KTE gelegt. Die Bahnhöfe werden direkt von den RBGs mit Nachschub aus dem Lager versorgt. Im B-Lager befinden sich seltener nachgefragte Waren (s. Abb. 26.3). In diesem Bereich wird die KTE zum Kommissionierbahnhof befördert, während zeitgleich die benötigte Ware bereitgestellt wird. Die Ware wird in Transporteinheiten aus dem Lager zum Kommissionierbahnhof befördert. Um sicherzustellen, dass diese am Kommissionierbahnhof zeitgleich ankommen, werden die Transporteinheiten auftragsbezogen aus einem automatischen Kleinteilelager (AKL) entnommen und zwecks Zwischenspeicherung zu einem Turmspeicher befördert. Bei der Ankunft der KTE am Kommissionierbahnhof wird dem Bediener die Ware auftragsbezogen aus dem Turmspeicher bereitgestellt. Sind noch Auftragspositionen im C-Lager vorhanden, so wird die KTE anschließend in das C-Lager transportiert. Die C-Kommissionierung betrifft sehr selten benötigte Waren, die meist auf Paletten gelagert werden. Anschließend werden Aufträge, die mehrere Kartons umfassen, vor dem Warenausgang zusammengeführt. Diese Aufgabe übernimmt eine Sortieranlage (s. Abb. 26.4), bestehend aus zwei RBGs und einem Kreislauf (Loop). Die KTE eines Auftrags verlassen den Kreislauf in Richtung der Universalpackplätze. Die KTE, die nicht zu dem aktuellen Auftrag gehören, verbleiben so lange im Kreislauf, bis der aktuelle Auftrag abgeschlossen ist und die Bearbeitung des entsprechenden Auftrags begonnen werden kann.

4212 EP10 4210 RBG 10

4193

Abb. 26.3   B-Kommissionierung

Fördertechnik für die TE mit der Auftragsposition

4213

4211

4194

4182 4180 EP08 RBG 8

4192 4190 EP09 RBG 9 4183

4181

4184 4191

4044 4045

4214

RBG (10 Gassen) - Verbindung zu B-Lager

4301

B-Kommisionierbahnhof

4302

4045

TS01 4410

4311

4312

AÜP_U 4313

4314

Fördertechnik für die Kommissionier-TE

Puffer für TE mit Auftragsposition

4316

4315

4044

26  Ein dezentral gesteuertes Kommissionierlager 299

300

D. Gehlich et al. 304 2

3110 3120

301 7

301 3

301 6

Z=02 Z=01 3130

301 301 5 4 RBG 1

3140

Z= 01

301 2 SC30 12 Z=02 301 1

301 8

3150

Zu Paketsorter EP01

3160

300 1 300 2

3180

LOOP 3040

3170

Zu Paketsorter EP02

3190 3200

3210 3220 RBG 2 302 5

302 1

3230 3240 302 8

3250

304 1

Z=02 Z=01 302 302 6 7

Z=01 Z=02 302 302 3 2

Abb. 26.4   Sortieranlage

302 4

26  Ein dezentral gesteuertes Kommissionierlager

301

26.4  Konzeptionelle Lösungen 26.4.1  RFID-Einsatz Die RFID-Technik ist für den Einsatz in Materialflusssystemen eine vielversprechende Alternative zu der noch vorherrschenden Barcodetechnik. Ein Vorteil dabei liegt darin, dass auf einem RFID-Tag auch zusätzliche auftrags- und steuerungsrelevante Daten dynamisch gespeichert und zur Laufzeit geändert werden können. Dies kann dazu dienen, Daten über das Produkt, aber auch Weginformationen auf dem Fördergut zu speichern und damit für die Verarbeitung in einer lokalen Steuerung sofort verfügbar zu haben. Diese Art der Datenverwaltung wird als Data-on-Tag bezeichnet. Um die steuerrelevanten Informationen des MFS verarbeiten zu können, müssen an allen Entscheidungsplätzen der Fördertechnik sowie an den Einlagerplätzen und ggf. auf dem Lastaufnahmemittel (LAM) des Regalbediengerätes (RBG) RFID-Lese-/Schreibstationen angebracht sein. An diesen Stellen kann das MFS den nächsten anzufahrenden Platz bestimmen und die TE in die ermittelte Richtung weiterleiten. Dazu benötigt es die in dem RFID-Tag gespeicherten Routeninformation und das der TE zugeordnete Ziel. Die zu schreibende Datenmenge ist abhängig vom Ort des Beschreibens. Ist ein steuerrelevanter Datenaustausch an jeder Entscheidungsstelle notwendig (z. B. durch Auswertung und ggf. Korrektur von Routeninformationen), so ist die maximal mögliche Datenmenge abhängig von der Fördergeschwindigkeit und der Feldbreite. Diese ist bei Hochleistungsanlagen stark eingeschränkt und beläuft sich auf wenige Kilobyte. An Verwaltungsplätzen wie Kommissionierplätzen, Aufsetzpunkten etc. können große Datenmengen geschrieben werden, da sich die Behälter an diesen Plätzen im Ruhezustand befinden. Informationen für das Lagerverwaltungssystem und für das ERP-System können somit auf dem Transponder gespeichert und verwaltet werden. Somit ist auch eine standortübergreifende Verwaltung von Transportgütern möglich. Der gesamte zur Verfügung stehende Speicherbereich eines RFID-Tags setzt sich somit wie folgt zusammen (Tab. 26.1). Die Behälter werden bei der Referenzanlage auf Rollen transportiert und fahren über eine circa 400 mm breite Fördertechnikstrecke. Die Fördergeschwindigkeit beträgt im Normalfall 1 m/s. Verschiedene Materialien haben unterschiedliche Einflüsse auf das RFID-Feld und sind somit entscheidend für die Auswahl einer geeigneten Frequenz. In der Regel sind Fördertechnikmodule und Rollen eine Stahlkonstruktion. Aufgrund der Anforderungen für hohe Übertragungsgeschwindigkeiten sowie des geringen Einflusses von Metall empfiehlt sich der Einsatz der HF-Technologie mit einer Frequenz von 13,56 MHz. Der heutige Stand der Technik Tab. 26.1   Mögliche Speicheraufteilung eines RFID-Tags Speicherbereich Feste Daten Steuerungsdaten Nutzdaten UID Ziel Route Artikelnummer

Gewicht

Menge

302

D. Gehlich et al.

Abb. 26.5   Positionierung der RFID-Schreib-/Leseeinheit auf der Fördertechnik (viastore systems GmbH)

bietet Geräte, die auf Metall abgestimmt sind und somit keinen negativen Einfluss durch dieses erfahren. Da RFID Transponder im Gegensatz zu Barcodes dynamisch mit Daten beschrieben werden können, darf an jedem Behälter nur ein RFID-Tag angebracht sein. Dieser kann entweder zentral positioniert werden (s. Abb. 26.5) oder es muss je eine Antenne für jede Seite des Behälters installiert werden. Bei der Referenzanlage eignet sich die Mitte des Behälterbodens am besten, da durch das Anbringen der Antenne zwischen den Rollen der Fördertechnik ein Abstand zwischen Antenne und Tag garantiert ist und lediglich eine Antenne verbaut werden muss.

26.4.2  Konzept einer agentenbasierten Steuerung Ein dezentrales Steuerungskonzept für den Materialflussbereich setzt eine Modularisierung der Elemente des Lagers voraus. In Bezug auf ein Agentensystem werden diese Module durch Modulagenten repräsentiert. Auch die Transporteinheiten und deren Aufgaben sind im System als TE-Agenten aktiv. Ein TE-Agent existiert für die gesamte Transportdauer der TE, vom Aufsetzen auf die Fördertechnik bis hin zur Einlagerung. Der Agent selbst kann sich dabei an einem beliebigen Ort innerhalb des Netzwerks befinden. Abbildung 26.6 verdeutlicht die Verarbeitung einer Transporteinheit an einem Identifikationspunkt im bestehenden Grundkonzept. Die exakte globale Adresse

26  Ein dezentral gesteuertes Kommissionierlager

303

Agentplatform n

ConvLoc-Agent 1 ConvLoc-Agent 2 ConvLoc-Agent n 3

3 3

TE-Agent1 4

2

Agentenplattform 2

ConvLoc-Agent 4242 Weichen-Agent 5

Agentenplattform 1

7

6

ConvLoc: 4242

RFID-Schrelb-/Leseeinheit

TE: 1

Abb. 26.6   Grundkonzept des Agentensystems

des Agenten befindet sich in einem RFID-Chip der Transporteinheit und wird im ersten Schritt vom ConvLoc-Agenten 4242 ausgelesen (Schritt 1). Ein ConvLocAgent repräsentiert einen bestimmten Platz (hier einen Identifikationspunkt) im Lager. Dabei kann ein ConvLoc-Agent mit einem weiteren speziellen Agenten an diesem Platz verbunden sein. In diesem Fall ist das ein Weichenagent, der die Aufgabe hat, die Weiche anzusteuern und direkt mit der Fördertechnik zu kommunizieren. Die Verbindung zweier Fördertechnikplätze stellt eine Strecke dar. Diese wird von einem der beiden ConvLoc-Agenten verwaltet und wird nicht gesondert über einen Streckenagenten repräsentiert. Zusätzlich sind im System weitere Agenten vorhanden, die spezielle Aufgaben übernehmen. Hierzu zählen beispielsweise Loop-Agenten, Einlager-Agenten und Verschiebewagen-Agenten. Diese lassen sich einem ConvLoc-Agenten als eine übergeordnete Instanz zuordnen. Der ConvLoc-Agent nimmt nun mit Hilfe der ausgelesenen globalen Adresse Kontakt zu dem zur TE gehörenden Agenten auf und teilt ihm die aktuelle Platznummer mit (Schritt 2). Der zur TE gehörige Agent ermittelt im ersten Schritt alle möglichen Routen zum Ziel der TE, welches er bei der Auftragserstellung gespeichert hat. Daraufhin kontaktiert er alle beteiligten ConvLoc-Agenten und holt Informationen über die zugehörigen Streckenabschnitte ein (Aktivität, Auslastung, etc.)

304

D. Gehlich et al.

und passt dementsprechend seine Routingtabelle an (Schritt 3). Nachdem die Dijkstra-Berechnung durchgeführt worden ist, teilt er dem ConvLoc-Agenten, auf dessen Platz die TE aktuell steht, den nächsten anzufahrenden Platz mit (Schritt 4). Der ConvLoc-Agent wiederum gibt diese Information an den Weichenagenten weiter, der den Auftrag zur Weichensetzung erteilt (Schritt 5 und 6). Neben der Identifizierung von Transporteinheiten entstehen im Lager auch weitere Steuerungsaufgaben wie die Auftragsreihenfolgebildung, die Loopsteuerung und die Gruppenzielverfolgung. Konzeptionelle Lösungen mit dem Agentenansatz werden im Folgenden für zwei dieser Aufgaben genauer beleuchtet. 26.4.2.1  Platz-zu-Platz-Steuerung Die Platz-zu-Platz-Steuerung setzt die Grundaufgabe der Materialflusssteuerung um. Hierbei sollen die TE-Agenten an Fördertechnikkreuzungen entscheiden, in welche Richtung sie weiter fahren, um ihr Ziel zu erreichen. Bisher wurden diese Entscheidungen offline getroffen und statisch in Routing-Tabellen abgelegt. Mit Hilfe des Wegfindungsalgorithmus nach Dijkstra sollen diese Entscheidungen der Anlagendynamik angepasst werden. Entscheidend hierbei ist der Informationsaustausch zwischen dem TE-Agenten und den ConvLoc-Agenten, um aktuelle Lasteigenschaften beteiligter Strecken zu erhalten. Abbildung 26.7 stellt einen Ablauf der Kommunikation zwischen den Agenten in Form eines Sequenzdiagramms dar. In diesem Szenario fährt die TE, repräsentiert in der Steuerung durch TEAgent1, von Platz 4001 nach 4002. Der Platz 4001 erhält von der Maschinensteuerung eine Ankunftsmeldung inklusive der eindeutigen ID, die durch ein an dem Platz angeschlossenes RFID-System ausgelesen wird. Diese Information wird dem Platz-Agenten mitgeteilt. Anhand dieser Informationen kann der Platz 4001 dem TE-Agenten seine aktuelle Position mitteilen ( setActConvLoc()). Nachdem der TE-Agent1 die aktuelle Position der Transporteinheit mitgeteilt bekommen hat, berechnet er den optimalen Weg zum Ziel von dieser Position aus. Da hierfür die Lastinformationen aller beteiligten Strecken erforderlich sind, sollten im Vorfeld Nachrichten an die ConvLocs verschickt werden ( getTrackState()). Da bis dato nicht feststeht, welche Strecken beteiligt sein können, müsste eine Nachricht an alle ConvLoc-Agenten geschickt werden. Bei einer Lagergröße von 180 Plätzen sind das 360 Nachrichten für eine einzelne TE (180 Anfragen + 180 Antworten). Bei einer Dichte von 100 parallel arbeitenden TE-Agenten steigt die Zahl der verschickten Nachrichten auf 36.000 im gleichen Zeitspektrum. Diese Masse an Informationen ist schwer zu verarbeiten. Zum einen entsteht ein hoher Netzwerkverkehr und zum anderen muss jeder ConvLoc-Agent ständig eine Vielzahl an Nachrichten verarbeiten und sie zeitgemäß beantworten können. Unter

  Der Dijkstra-Algorithmus ist ein informierter Suchalgorithmus. Er wird zur Routenplanung eingesetzt, um den optimalen Weg zwischen zwei Orten unter Berücksichtigung ihrer Streckeneigenschaften zu bestimmen.

getTrackState() : trackState

getTrackState() : trackState

addPlannedLoad(4004)

addPlannedLoad(4002)

addPlannedLoad(4001)

addCurrentLoad(4001)

Abb. 26.7   Sequenzdiagramm Platz-zu-Platz-Steuerung

setOutputs()

setNextConvLoc(4002)

ConvLoc4004

getTrackState() : trackState

getTrackState()

getTrackState()

getWay()

ConvLoc4002

getTrackState() : trackState

TE-Agent1

setActConvLoc(4001)

ConvLoc4001

identRFID()

Maschinensteuerung

ConvLoc4301

26  Ein dezentral gesteuertes Kommissionierlager 305

306

D. Gehlich et al.

Berücksichtigung der Art der Nachrichtenverarbeitung und ihrer Quasi-Parallelität kann hier ein Engpass entstehen. Eine Optimierung dieser Strategie besteht darin, zunächst den Weg aufgrund rein statischer Informationen zu berechnen. Zu diesem Zweck kennt jeder ConvLoc-Agent die gesamte Topologie und die zu den Strecken gehörigen statischen Eigenschaften. Diese beinhalten die Fördergeschwindigkeit, die Streckenlänge und die damit verbundene maximale Streckenkapazität. Anschließend werden nur relevante ConvLocs auf die dynamischen Eigenschaften der Strecken befragt. In dem obigen Szenario wird dieser Sachverhalt durch Nachrichten an die ConvLocs 4002, 4004 und 4301 deutlich. Nur diese ConvLocs liegen auf dem aus statischer Sicht optimalen Weg. Sind alle Streckenabschnitte aktiv und liegt die Auslastung unterhalb der vorhandenen Streckenkapazität, so kann dieser berechnete Weg befahren werden. Andernfalls werden die Kosten für die nicht befahrbaren Abschnitte hoch gesetzt und der Weg erneut berechnet. Aufgrund der Tatsache, dass erneute Routenberechnungen nur dann durchgeführt werden müssen, wenn Streckenabschnitte voll oder defekt sind, verringert sich die Anzahl der zu sendenden Nachrichten. Dabei werden nur die Nachrichten benötigt, die den TE-Agenten über den Zustand der noch zu befahrenden Abschnitte vom aktuellen Platz zum Ziel informieren, im genannten Szenario also 3 statt 180. Damit die ConvLocs ihre Streckeninformationen aktualisieren können, werden die geplanten Streckentransporte des TE-Agenten als Auslastungsinformation an die ConvLoc-Agenten gesendet ( addPlannedLoad(convLoc)), wobei der Parameter convLoc dem Platz entspricht, von dem eine TE zu dem geplanten Platz fährt. Nun kann dem ConvLoc 4001 der Fahrbefehl zum Platz 4002 mitgeteilt werden ( setNextConvLoc()). Dabei ist der ConvLoc selbst dafür verantwortlich, wie die Einheit von Platz zu Platz fährt. Es ist also nicht entscheidend, ob der TE-Agent einem einfachen Förderer oder einem speziellen Platz wie einem Verschiebewagen den Auftrag erteilt. Die interne Verarbeitung ist dem Platz selbst überlassen. Da die Transporteinheit nun die Strecke von 4001 nach 4002 aktiv nutzen möchte, muss dies dem ConvLoc-Agenten 4002 mitgeteilt werden, damit dieser die geplante Auslastung mit der aktuellen Auslastung synchronisieren kann. Desweiteren kann zu jeder Zeit festgestellt werden, auf welchem Streckenabschnitt sich eine bestimmte Transporteinheit befindet, da die momentane und geplante Auslastung der Strecken inklusive der TE-Identifikationsnummer in jedem ConvLoc-Agenten hinterlegt ist. 26.4.2.2  Steuerung der Auftragsreihenfolge Gehören einem Auftrag mehrere Fahrbefehle an, so müssen sie als Gruppenauftrag identifiziert und entsprechend auf der Fördertechnik zusammengeführt werden. Zu diesem Zweck existiert eine Auftragsnummer (ANR). In dem Szenario für die Dieses Szenario wurde mit JADE-Framework umgesetzt, welches zur Verarbeitung von Nachrichten innerhalb eines Agenten das Round-Robin-Verfahren verwendet.

 

26  Ein dezentral gesteuertes Kommissionierlager Tab. 26.2   Auftragsnummern Auftragsnummer 00 01 10–99

307

Beschreibung Eilauftrag (unmittelbare Auslagerung) Auslagerauftrag mit einem Auslagerbefehl Auslagerauftrag mit mehreren Auslagerbefehlen

Referenzanlage wird eine zweistellige Auftragsnummer verwendet. Sie beginnt im Normalfall bei 10 und läuft bis 99 (s. Tab. 26.2). Danach wird die laufende Nummer zurückgesetzt und beginnt von vorne. Aufträge mit der Nummer 01 sind Kleinaufträge und umfassen nur einen Auslagerbefehl. Die Auftragsnummer 00 legt einen Eilauftrag fest, der höchste Priorität genießt. Bevor nun die Aufträge an das RBG weitergeleitet werden, müssen die TEAgenten untereinander aushandeln, welcher Auftrag als nächster gefahren werden darf. Der Ablauf dieses Kommunikationsaktes ist im Sequenzdiagramm in Abb. 26.8 dargestellt. Der WMS-Agent bekommt vom Lagerverwaltungssystem einen Auslagerauftrag in Form eines Telegramms inklusive einer Auftrags- und ggf. Sortiernummer. Aufgrund dieses Telegramms erteilt der WMS-Agent dem entsprechenden TE-Agenten den Auftrag auszulagern und zum Ziel zu fahren. Dieser erfragt vom zuständigen Directory Facilitator (DF) (vgl. Kap. 11) alle TE-Agenten, die durch den Service mit dem Servicetyp JobOrder und dem Servicenamen convLocXY registriert sind. convLocXY entspricht dabei einem Zielort im System. Dieser ist meistens ein Kommissionierbahnhof. Das Ergebnis wird in Form von Agent IDentifications (AID) zurückgegeben. Diese sind die eindeutigen Identifikationsnamen der jeweiligen TE-Agenten. Nun muss der TE-Agent alle im Ergebnis enthaltenen TE-Agenten über den Status des Auftrags ausfragen. Ein Auftrag gilt so lange als aktiv, bis alle Transporteinheiten dieses Auftrages den Point-of-no-return erreicht haben. Dieser Punkt entspricht einer Entscheidungsstelle in der Anlage, nach welcher sich die Transporteinheiten auf dem Weg zum Ziel nicht mehr über andere Routen überholen und somit die Auftragsreihenfolge unterbrechen können. Ist der Auftrag aktiv, so darf die Transporteinheit ausgelagert werden. Im Demo-Szenario bekommt der TE-Agent1 als Ergebnis die AID von TE-Agent2 und TE-Agent3 zurückgeliefert. Diese werden nun über den Auftragsstatus befragt ( isRBGJobOrderActive()), und die Antworten werden ausgewertet. Dem RBGAgenten wird nun der Auftrag über die Auslagerung mit der entsprechenden Auftragsnummer angeboten. Er fügt den Auftrag seiner Auftragsliste hinzu und sendet eine positive Antwort zurück. Damit andere TE-Agenten über die anstehende Auslagerung Bescheid wissen, registriert der TE-Agent1 einen neuen Service mit dem Servicetyp JobOrder, dem Zielplatz 4301 und der Auftragsnummer (z. B. ANR = 10). In diesem Szenario ist die Dezentralität des Materialflusssystems besonders gut zu erkennen. Während in einer konventionellen Steuerung eine zentrale Entscheidungsstelle nötig ist, handeln hier die Agenten untereinander aus, welche TE ausgelagert werden darf. Das Hauptaugenmerk liegt dabei auf der Informationsbeschaffung für die Entscheidung.

doObo()

addJobOrder() : accept

addJobOrder(10)

WMSAgent

DF

TE-Agent2

register(anr, 10)

register(JobOrder, 4301)

isSameJobOrderNr()

isRBGJobOrdrActiveAnswer() : yes

isRBGJobOrdrActiveAnswer() : yes

isRBGJobOrdrActive()

isRBGJobOrdrActive()

search(JobOrder, 4301) : result

search(JobOrder, 4301)

TE-Agent1

Abb. 26.8   Sequenzdiagramm Auftragsreihenfolge

RBGAgent

TE-Agent3

308 D. Gehlich et al.

26  Ein dezentral gesteuertes Kommissionierlager

309

26.5  Integration der Steuerung Für die Umsetzung dieses dezentralen Konzepts ist eine Verteilung der Steuerungshardware notwendig. Für Module werden netzwerkfähige Embedded-Controller mit digitalen I/O eingesetzt. Wegen der hohen Echtzeitanforderungen wird eine ZweiSchicht-Architektur (vgl. Kap. 11) eingesetzt. Dabei spielt eine geeignete Laufzeitumgebung für die verwendete Software eine entscheidende Rolle. Immer häufiger findet man im Bereich verteilter Anwendungen und Steuerungen den Einsatz von Linux-Betriebssystemen mit einer Echtzeiterweiterung. Die Abb. 26.9 zeigt eine beispielhafte Integration des entwickelten Schichtenmodels auf der Grundlage von RTAI-Linux. Die Steuerungseinheit ist über Ethernet im Netzwerk mit anderen Modulen verbunden, um die Agenten-Kommunikation zu ermöglichen. Der Informationsaustausch zwischen den Agenten findet über den von der Agentenplattform bereitgestellten Nachrichtentransportdienst (vgl. Kap. 11) statt. Die Kommunikation mit benachbarten Systemen erfolgt über eine TCP/IPSchnittstelle. Die Agentenplattform ist im User-Space als niedrig priorisierte Linux-Task zu finden. Innerhalb der Agentenplattform fungieren Software-Agenten als feste Bestandteile jeder dezentralen Steuerungseinheit. Dabei ist es zunächst unerheblich, ob auf einem Steuerungsrechner nur ein Modul-Agent zur Ansteuerung des entsprechenden Fördermoduls läuft oder ob die Hardware für die Installation mehrerer Modul-Agenten und somit für die Verwaltung mehrerer Fördermodule genutzt wird. Eine Verbindung zwischen der Agentensteuerung und der Maschinensteuerung wird über eine Interprozesskommunikation hergestellt. Wichtig ist hierbei nicht, wie die Daten, sondern welche Daten über die Schnittstelle ausgetauscht werden. Die SW-Agent

SW-Agent

SW-Agent

RTAI-Linux-Laufzeitumgebung Agentensteuerung

Linux-Task

Datenaustausch (asynchorn)

Interprozesskommunikation Maschinensteuerung

ID-System

Abb. 26.9   Integrationsbeispiel

Schicht 2 zeitunkritisch

Echtzeit-Task

M

Schicht 1 zeitkritisch

310

D. Gehlich et al.

Maschinensteuerung nutzt die Vorteile der RTAI-Erweiterung als Echtzeit-Task und erfüllt somit die Echtzeitanforderungen. Der Steuerungsablauf sollte im Idealfall für jede Entität identisch sein, jedoch stößt man hierbei auf folgende Herausforderung. Reale Anlagen bestehen meist aus einer Vielzahl unterschiedlicher Förderelemente von verschiedenen Herstellern mit verschiedenen mechanischen Komponenten und Antriebstechniken. Jedes Förderelement wird auf unterschiedliche Art und Weise angesteuert. Um dem entgegenzuwirken, muss es eine Möglichkeit geben, die Ansteuerung der Elemente dem eigentlichen Steuerungsablauf hinzuzufügen. Dies kann über Bibliotheken oder Hardwaretreiber bzw. I/O-Treiber erfolgen, die bereits durch den Hersteller bereitgestellt werden oder frei programmierbar sind. Zusätzlich ist für die Weiterleitung der Transporteinheiten eine Schnittstelle zum RFID-System notwendig, um die TE zu identifizieren. Die RFID-Einheit und die I/O-Gruppe können sich sowohl innerhalb als auch außerhalb des Moduls befinden.

26.6  Fazit Moderne Kommissionierlager zeichnen sich durch den stetig steigenden Grad der Automatisierung aus. Auch bei kleinen bis mittleren Unternehmen kommen vollautomatisierte Kommissioniersysteme immer häufiger zum Einsatz. Gleichzeitig werden diese Systeme komplexer und müssen flexibler gegenüber aktuellen Marktanforderungen werden. Abhilfe verspricht das neue Steuerungsparadigma Internet der Dinge, welches Vorteile der RFID-Technologie mit einem dezentralen Steuerungskonzept zusammenbringt. Für die Realisierung der Materialflusssteuerung wird in diesem Konzept der Einsatz von Softwareagenten empfohlen. Zur Überprüfung der Anwendbarkeit dieses Steuerungsparadigmas für die Domäne Kommissionierung besteht eine Referenzanlage, welche eine Reihe typischer Materialflüsse in einem automatischen Kommissionierlager integriert. Die anstehenden Steuerungsaufgaben wurden in einem Betriebsszenario abgebildet und sind sowohl konzeptionell als auch teilweise in einer Demo-Applikation umgesetzt. Eine Herausforderung beim Entwurf der agentenbasierten Steuerung bestand in der Modularisierung der technischen Anlage sowie der Identifizierung einzelner Steuerungsagenten. Dabei mussten die lokal benötigten Informationen und Funktionen erkannt und innerhalb eines Agenten gekapselt werden. Eine weitere Herausforderung bezieht sich auf die Abbildung der Steuerungslogik in Form von Interagentenkommunikation. Die ansatzweise Umsetzung der Steuerung nach dem Prinzip des Internet der Dinge ermöglicht folgende Aussagen über den Reifegrad und die Einsetzbarkeit der verwendeten Technologien. • Der Einsatz der RFID-Technik in Kommissionier- und Förderanlagen weist einige Verbesserungspotenziale auf, insbesondere in Bezug auf die Lese- und

26  Ein dezentral gesteuertes Kommissionierlager

311

Schreibgeschwindigkeit. Die Zuverlässigkeit des Lesens hängt unmittelbar von der eingesetzten Technik (Frequenz, Antennentyp, Transpondertyp usw.) und der Installation (Antennenausrichtung, Einstellung der Feldstärke usw.) ab. • Die Kosten für PC-basierte Steuerungsrechner sind zurzeit noch relativ hoch. Ein sinnvoller Ansatz dabei ist es, die Steuerung mehrerer technischer Module auf einem Rechnerknoten zu vereinen. • Die Erfüllung der Echtzeitanforderung gilt weiterhin als eine Herausforderung. Abhilfe schafft die Kapselung zeitkritischer Funktionen eines Moduls in einer echtzeitfähigen Maschinensteuerung. In einer Steuerung auf PC-Basis ist dies allerdings nur mit speziellen Werkzeugen (wie z. B. Echtzeit-Betriebssysteme oder Soft-SPS) zu bewältigen. • Der Reifegrad der Agentenplattformen in Bezug auf die Implementierung von Agentensystemen mit einer großen Anzahl von Steuerungsagenten wurde bisher nicht ausreichend untersucht, um die Grenzen bestehender Werkzeuge zu erkennen. Trotz einiger noch offener Fragestellungen lässt sich das Internet der Dinge im beschriebenen Anwendungsfall sehr gut bewerten. Mit dem Einsatz der RFID-Technik werden die Materialflüsse transparenter. Die lokal vorhandene Information (Data-on-Tag) ermöglicht lokale Entscheidungen und damit eine dezentrale Anlagensteuerung. Die Agententechnik bietet einen guten konzeptionellen Ansatz für die Dekomposition eines komplexen Steuerungsproblems in einzelne Teilprobleme und trägt somit zur Komplexitätsreduktion bei. Technische Module und Transporteinheiten mit ähnlichen Funktionalitäten bekommen dieselbe Steuerungslogik, die im Agentenkonzept gekapselt ist. Somit wird die Wiederverwendbarkeit der Softwareblöcke (Modulagenten) garantiert. Ein Modulagent, seine Rechnerplattform und der dazugehörige Fördertechnikabschnitt bilden im Idealfall ein mechatronisches Modul, welches bei Bedarf leicht ausgetauscht werden kann.

Kapitel 27

Agentenbasierte Staplerleitsysteme Stanislav Göhring und Thomas Lorenz

27.1  Einleitung Die Software ist der informatorische Backbone der Logistik. Daher ist es nur folgerichtig, ihre Entwicklungen in nachhaltig prägende Projekte wie dem vom BMBF geförderten Forschungsprojekt „Internet der Dinge – Wandelbare Echtzeit-Logistiksysteme auf Basis intelligenter Agenten für den produktionsnahen Bereich“ an maßgeblicher Stelle einzubinden. Mit dem Internet der Dinge werden Sendungen vor allem in der Intralogistik ihre Zielorte selbst mitteilen und autonom entsprechende Prozesse anstoßen. Dabei wird auf die Nutzung bewährter Instrumente wie etwa mobile Förderzeuge und Datenterminals kaum verzichtet werden können. Mit Blick auf künftige Entwicklungspotenziale im Rahmen der Vision vom Internet der Dinge gilt es nun, moderne Technologien in das Gesamtkonzept einzubinden und ihren Nutzen für spezifische Anwendungen zu hinterfragen. Mit diesem Grundgedanken ist PSI Logistics seit 2006 in dem Forschungsprojekt engagiert. Zielvorgabe war es, Möglichkeiten zu eruieren, wie und in welchen Anwendungen die so genannte Agententechnologie Vorteile im Umfeld des Internet der Dinge bieten kann. Als Basis für die entsprechende Forschungsarbeit galt es, dabei zunächst die Agenten-Umgebung, die Gestaltung der Verfahren und der Ontologie, also der Sprache, in der die Agenten miteinander reden, zu definieren. Weiterhin hat PSI Logistics maßgeblich Entwurf und Implementierung der Agenten-Prototypen für das Test-Fördersystem beim IML geprägt. Basierend auf den im Forschungsprojekt gewonnenen Ergebnissen hinsichtlich der Agenten-Charakteristika sollen am Beispiel eines dezentralen, Agenten-basierten Staplerleitsystems (aSLS) nun Optionen vorgestellt und geprüft werden, wie diese standardisierten Komponenten mit dezentraler Eigenintelligenz (Entitäten) auszustatten und wie sie auf sich selbst organisierende und sich selbst steuernde, dezentrale Strukturen auszurichten sind.

S. Göhring () Softwareengineering, PSI Logistics GmbH Am Stadtrand 56, 22047 Hamburg, Deutschland e-mail: [email protected] W. Günthner, M. ten Hompel (Hrsg.), Internet der Dinge in der Intralogistik, DOI 10.1007/978-3-642-04896-8_27, © Springer-Verlag Berlin Heidelberg 2010

303

304

S. Göhring und T. Lorenz

Hintergrund für die Konzentration auf ein aSLS: Die Fokussierung auf Einsatz und Steuerung von Flurförderzeugen umfasst ein überschaubares, gleichwohl praxisorientiertes Segment. Software-Komponenten wie das Staplerleitsystem (SLS) von PSI Logistics können deren Einsatz bereits heute durch optimierte Wege- und Auftragsvergabe sehr effizient gestalten. Solche herkömmlichen Staplerleitsysteme organisieren die Steuerung von Staplern und Kommissionierern und optimieren die Materialbewegungen in Lagern. Bei der Datenübertragung zu mobilen Datenterminals (MDT) bildet das Staplerleitsystem das Bindeglied zwischen Warehouse Management System (WMS) und dem Funk-Controller. Diese konventionell verwendeten SLS-Lösungen sind strikt hierarchisch aufgebaut und von einer zentralen Verwaltung abhängig. Kennzeichnend für die Theorie vom Internet der Dinge sind hingegen sich selbst organisierende und steuernde, dezentrale Strukturen. Für Steuerungssysteme von Staplerflotten ist damit ein markanter Paradigmenwechsel verbunden. Gleichwohl gilt es, den bewährten Funktionsumfang eines SLS zu erhalten und auf ein Agentenbasiertes System zu übertragen beziehungsweise die Funktionen durch das aSLS zu optimieren. Dies betrifft insbesondere die Kommunikation mit dem überlagerten WMS, das Optimierungsverfahren bei der Beauftragung der Fahrzeuge (optional auch mit Hilfe einer Lagersimulation) sowie die Abwicklung von belegloser Kommissionierung, Inventur und Transporten. Diese Funktionsvorgaben sind an den Konzeptzielen für die Entwicklung eines aSLS auszurichten. Dabei zeigt sich, dass die dezentralen Strukturen markante Änderungen prägen: Die eingesetzten Stapler können die vom WMS eingehenden Aufgabenlisten (Fahraufträge, Kommissionierlisten, Inventurlisten) lokal auf dem Flurförderzeug speichern und sie können im Online-/Offline-Staplermischbetrieb geführt werden. Für neu eingestellte, zusätzliche Stapler gilt eine mühelose Plug&Play-Integration ohne nennenswerten Programmieraufwand. Als wünschenswert resultiert daraus zudem, dass an den verwendeten Terminals eine benutzerfreundliche Bedienoberfläche sowie ein praxisgerechtes Zeit-Antwort-Verhalten realisiert werden kann. Die Ziele und Herausforderungen bei der Einbindung der Agententechnologie in die Gestaltung eines dezentralen, Agenten-basierten Staplerleitsystems stellen sich zusammenfassend demnach wie folgt dar: • Aufhebung zentraler Steuerungsinstanzen • Erstellung eines Materialflusssystems aus lokal agierenden Einheiten • Gestaltung eines robusten Systems, das die erforderlichen logistischen Aufgaben auch unter widrigen Umständen erfüllt • prozessorientierte Ausrichtung auf den logistischen Gesamtprozess • Fähigkeit des Systems, sich selbständig an geänderte Randbedingungen, beispielsweise dynamische Auftragslasten, anzupassen (Adaptivität) • einfache Integration unter-, über- und beigeordneter Systeme • schnelle und abgesicherte Inbetriebnahme nach Installation oder Änderung und Verkürzung der Engineering-Zeiten • effizienter Einsatz der Staplerflotte

27  Agentenbasierte Staplerleitsysteme

305

27.2  Definition und Einsatz von Staplerleitsystemen Beim innerbetrieblichen Transport in manuellen Lagern arbeiten Flurförderzeuge unter anderem bei der Ein- und Auslagerung, bei der Kommissionierung, Bereitstellung, Verdichtung und Inventur oder bei der Nachschubversorgung eine Vielzahl von Transportaufträgen ab. Mit Einsatz eines in die IT-Infrastruktur integrierten Staplerleitsystems (SLS, s. Abb. 27.1) lassen sich die Transporte von Transporteinheiten (TE) durch Stapler, Handkommissionierer oder Fahrerlose Transportsysteme wege- und auftragsoptimiert gestalten. Die erforderlichen Transportbedarfe erhält das SLS vom übergeordneten (Warehouse Management) System oder – im Stand-Alone-Einsatz – direkt vom Host. Vom SLS werden daraus Transportaufträge generiert und beleglos über WLAN an ein mobiles Datenfunkterminal (MDT) mit Scanner auf den Staplern übertragen. Die Aufträge werden vom Stapler dialoggeführt abgearbeitet. Die Auftragsbearbeitung wird an den Stellplätzen über Barcodescanner bestätigt. Das ermöglicht überdies eine lückenlose innerbetriebliche Rückverfolgung von Waren und Chargen. Dabei bündelt das SLS die Aufträge und steuert nach speziellen Algorithmen zur Leerfahrtenvermeidung oder zur Beachtung von Prioritäten die Transporte und den Einsatz der Flurförderzeuge (FFZ). Nachdem ein Auftrag abgearbeitet ist, wird der nächste übertragen. Die automatische Vergabe neuer Fahraufträge erfolgt möglichst an jene verfügbaren FFZ, die dem jeweiligen Aufnahmepunkt am nächsten sind. Durch die SLS-gestützte Einsatzsteuerung werden eine optimale Auslastung der verfügbaren Kapazitäten und eine hohe Kommissionierqualität erzielt. Zudem steigert der Einsatz eines SLS die Effizienz der Disposition sowie die Transparenz der Prozesse.

Abb. 27.1   Funktionsweise eines Staplerleitsystems

306

S. Göhring und T. Lorenz

27.3  Agentenbasierte Staplerleitsysteme Neben den typischen systemimmanenten Perspektiven des Internet der Dinge sind von der Entwicklung eines Agenten-basierten Staplerleitsystems (aSLS) nachhaltig positive Auswirkungen hinsichtlich Flexibilität, Integration und Effizienz zu erwarten. Ein serientaugliches aSLS soll sich jenseits seiner Steuerungsfunktionen innerhalb des Internet der Dinge über seine Architektur, Modularität und Kapselung als höchst anpassungsfähig und wandelbar erweisen. Es wird ein System mit definierten Schnittstellen sein, das einerseits Update-fähig ist, zum anderen jedoch bei Retrofitting oder Software-Anpassungen weniger Hersteller-Abhängigkeiten als üblich aufweist. Standards und Kapselungen sowie die Einbindung der Radio Frequency Identification (RFID) (s. hierzu Abschn. 27.6) sorgen überdies für geringen Wartungsaufwand sowie kurze Implementierungs- und Inbetriebnahmephasen. Dabei ist das dezentrale, Agenten-basierte Staplerleitsystems (aSLS) im Folgenden als Synonym zu verstehen: Es beschränkt sich nicht allein auf die Kommunikation mit Staplern, sondern umfasst von Handterminals über KommissionierwagenTerminals bis hin zu den unterschiedlichen Staplertypen-Terminals die verschiedensten mobilen Terminalarten. In dieser Konzeptbeschreibung wird aSLS folglich lediglich als praxisbezogenes Beispiel speziell am Einsatz in Stapler-Terminals demonstriert und – hinsichtlich der Architektur – auf Stapler-Agenten bezogen. Systemische Forschungs- und Arbeitsgrundlage zur Entwicklung eines aSLS bildet exemplarisch das als Software-Modul im Warehouse Management System PSIwms vorhandene SLS von PSI Logistics. Die Forschungsumgebung unterliegt zudem praxisorientierten Prämissen. So soll das aSLS als Bindeglied zwischen Warehouse Management System und physischem Materialfluss dienen (s. Abb. 27.2). Dabei wird ein autark funktionsfähiges System fokussiert, das auch unabhängig von anderen Softwareprodukten eigenständig in Betrieb genommen werden kann.

aSLS Stapler Agent

Stapler Agent

Stapler Agent

Stapler Agent

Abb. 27.2   Logische aSLS-Architektur

Schnittstellen Agent Manager Agent

WMS

27  Agentenbasierte Staplerleitsysteme Abb. 27.3   Physikalische aSLS-Architektur

307

WLAN

aSLS

Die Prozessabläufe sehen wie folgt aus: Zur Koordination der Transporte, Kommissionierungen und Inventuren beauftragt das aSLS die WMS-Domänen Transportmanagement, Kommissioniermanagement und Inventurmanagement. Die Domänen kommunizieren mit dem aSLS-Management über ein Funkcontrollersystem (s. Abb. 27.3). An diesem sind die mobilen Datenterminals (MDT) angeschlossen. Das aSLS-Management erfordert zudem Konfigurations-Definitionen über die Topologie der Verbindungsstruktur, die Fahrzeuge, die Bewegungsbereiche der eingesetzten Fahrzeugtypen sowie der Mobilen Datenterminals. Die erforderliche Intelligenz wird mittels Agenten in die Terminalumgebung transferiert. Entscheidender Vorteil gegenüber herkömmlichen SLS: Durch diesen Transfer können die MDT sowohl im Online-Betrieb als auch im Offline-Betrieb eingesetzt werden. Diese Möglichkeit wird zu einem der wesentlichen Aspekte des Konzeptes. In Form von Terminal-Agenten läuft die Software auf den lokalen MDT. Auf diese Weise ist beispielsweise ein Stapler-Agent mit wenigen Daten über die physikalischen Eigenschaften des Staplers ausreichend konfiguriert. Diese Konfigurationsdaten müssen jedoch von einer zentralen Instanz auf den Stapler geladen werden. Dadurch wird auch beim Modell des aSLS zumindest auf dieser Ebene eine zentrale Datenhaltung und Steuerung – allerdings in Form verschiedener ManagerAgenten (etwa für Anforderungen von TE zum Transport, Optimierung der Trade Promotion Authority-(TPA)-Vergabe, Simulation) – notwendig bleiben.

27.4  Moderne Software-Architektur Neben der Beschreibung der Prozesse erfordert die Organisation eines Agentenbasierten Staplerleitsystems (aSLS) nachhaltige Modifizierungen der SoftwareArchitektur. Vor dem Hintergrund der Anforderungen wie sie das Internet der Dinge stellt, bildet hinsichtlich der Architektur die Verwendung so genannter Agenten ein probates Mittel, die geforderten Aufgaben zu lösen. Solche Agenten lassen sich als Systeme beschreiben, die im Rahmen bestimmter Entwicklungsziele selbstständig

308

S. Göhring und T. Lorenz

kritische Entscheidungen treffen können. Ihre Autonomie, ihre Fähigkeit, Aktionen ohne Eingriff weiterer Systeme oder Benutzer auszuführen, prädestiniert sie geradezu für die Verwendung in Umgebungen, die dem Internet der Dinge zugeschrieben werden können. Dabei können Agenten nicht nur auf Veränderungen in ihrer Umgebung reagieren, sondern auch proaktiv Initiativen zu einer situativen Verbesserung ergreifen und darüber hinaus mit anderen Agenten interagieren, um bestimmte Ziele zu erreichen. Solche Multi-Agentensysteme aus lose gekoppelten, zielorientiert autonomen Agenten lassen sich derart koordinieren, dass sie Lösungen für Gesamtaufgaben finden. Damit eignen sie sich hervorragend zur Lösung zahlreicher Koordinations- und Kooperationsaufgaben. Die Einbindung solcher Agentensysteme in die Softwarearchitektur eines aSLS betrifft im Wesentlichen die fünf Entitäten und Aufgaben an der Systemschnittstelle (ST-Agent), der Transporteinheit (TE-Agent), den Staplern (Stapler-Agent), am Auftragsmanager (AM-Agent) und am Ressourcenmanager (RM-Agent). Die Aufgaben und das Zusammenspiel dieser Entitäten lassen sich wie folgt beschreiben (s. Abb. 27.4): Der Auftragsmanager-Agent läuft auf der Server-Plattform. Er kapselt die auftragsverwaltungsbezogenen Funktionen eines WMS in Form von Dienstleistungen (z. B. Web Services). Auf diese Weise verwaltet der Auftragsmanager-Agent die Auftragslisten und übernimmt dann die Stellplatz- beziehungsweise Transportzielvergabe. Der Ressourcenmanager-Agent kapselt die entsprechenden Funktionen eines konventionellen SLS-Systems in Form von Diensten. Er legt die Transportprioritäten

Agent

Terminal

Handterminal

Stapler

Geländestapler

Abb. 27.4   Klassendiagramm

Transporteinheit

Schnittstelle

Kommissionierwagen

Schubmaststapler

Manager

Auftragsmanager

Mehrwegestapler

Ressourcenmanager

27  Agentenbasierte Staplerleitsysteme

309

für Transportaufträge (verkörpert durch TE) fest und ordnet den Transportmitteln Transportaufträge nach deren Prioritäten zu. Darüber hinaus übermittelt er Aktualisierungen und Veränderungen von Auftragsprioritäten sowie Umlagerungen von Transportaufträgen. Dabei erfolgt für beteiligte Stellplätze eine Berücksichtigung der Kapazität. Die kann wahlweise auch über die Einbindung eines TopologieAgenten realisiert werden. Der Systemschnittstellen-Agent modelliert die Ein- und Ausgangspunkte des Systems. Sie ermöglicht eine Übergabe von Transporteinheiten wie etwa Europaletten oder Gitterboxen zwischen verschiedenen Transportsystemen. Dabei wird der TE-Agent aus einem angrenzenden Fremdsystem übernommen beziehungsweise nach Konventionen dieses Systems neu erstellt. Die Systemschnittstelle verfügt über eine eigene Laufzeitumgebung (Agentenplattform). Die in das System eintretenden TE-Agenten betreten dieselbe Plattform und können zu den Agentenplattformen von Staplern migrieren. Überdies werden lokale TE-ID vergeben beziehungsweise globale ID (etwa GID nach EPC-96) sowie relevante Auftragsdaten übernommen. Schließlich erteilt der Agent der Systemschnittstelle den TE-Agenten den lokalen Workflow beziehungsweise die erforderlichen Fahraufträge. Diese werden gegebenenfalls einem WMS-Vermittler entnommen. Der Transporteinheiten-Agent bildet die Logik einer Transporteinheit ab, die von dem Staplersystem transportiert wird. Sie verfügt über einen Transportauftrag, welcher der Ressourcenverwaltung bekannt gegeben wird. Von der Ressourcenverwaltung wiederum bekommt die Transporteinheit den für die Transportrealisierung zuständigen Stapler zugewiesen. Anschließend migriert die TE in die Laufzeitumgebung des Stapler-Agenten und kommuniziert mit ihm zur Auftragsumsetzung. Abschließend meldet sie den Auftragsstatus zurück an die Auftragsverwaltung. Der Stapler-Agent repräsentiert die mitfahrende Steuerung eines Flurförderzeuges. Der Stapler-Agent agiert in der Laufzeitumgebung des jeweiligen Staplers. Der Stapler kann zu jedem Zeitpunkt entweder genau einen Transportauftrag abarbeiten (eine TE transportieren) oder frei verfügbar sein. Der TE-Agent eines aktuellen Transportauftrags läuft in der Laufzeitumgebung des Staplers. Weitere Transportaufträge im Online-Betrieb werden in einer Auftragsliste des Stapleragenten reserviert. Die entsprechenden TE-Agenten migrieren dabei in die Laufzeitumgebung des Staplers. Im Offline-Betrieb, wenn keine Verbindung zum Accesspoint vorhanden ist, werden die Transportaufträge aus dem Auftragspuffer abgearbeitet. Dafür besteht in der lokalen Laufzeitumgebung des Staplers eine interne Agentenkommunikation zwischen dem Stapler-Agenten und den entsprechenden TE-Agenten. Nach einer Auftragsfertigstellung im Online-Betrieb erfolgen eine Rückmeldung an die Ressourcenverwaltung sowie eine Vervollständigung und gegebenenfalls eine Aktualisierung der Auftragsliste. TE-Agenten migrieren dabei zwischen den Stapler-Umgebungen und der Umgebung des Servers, auf dem die Manager- beziehungsweise Schnittstellen-Agenten laufen. Diese Interaktion der unterschiedlichen Ebenen lässt sich auch als Schichtenmodell betrachten (s. Abb. 27.5):

310

S. Göhring und T. Lorenz

Abb. 27.5   Schichtenmodell

HOST

WMS

aSLS Sitzungsebene Verwaltungsebene Stapler Ausführungsebene Präsentationsebene

GUI

Anwender

Die Agenten der Sitzungs-/Verwaltungsebenen sollen grundsätzlich auf einem Server laufen. Auf der Sitzungsebene sind die Schnittstellen-Agenten für die Kommunikation mit den übergeordneten beziehungsweise Fremdsystemen zuständig. Die Manager-Agenten übernehmen auf der Verwaltungsebene die Aufgabenkapselung sowie die Bewahrung und Verteilung der Aufgaben zwischen den TerminalAgenten. Die Agenten der Ausführungs-/Präsentationsebene laufen auf dem MDT. Auf der Ausführungsebene sind die Terminal- und die TE-Agenten für die direkte Ausführung der übertragenen Aufgaben wie Abarbeitung von Transportaufträgen, Kommissionieraufträgen oder der Inventur zuständig. Über die Terminal-Agenten erfolgt auf der Präsentationsebene die Kommunikation zwischen der Ausführungsebene und den Endanwendern. Die Kommunikation erfolgt über das Graphical User Interface (GUI).

27.5  Operative Funktionen eines aSLS In einer möglichen Versuchsumgebung läuft die Software des aSLS in Form von Terminal-Agenten auf den lokalen MDT. Die Dialogführung zwischen Stapler und Fahrer erfolgt auf Basis lokal vorhandener Daten und nicht mehr durch das zentrale SLS. Dies ist die wesentliche Voraussetzung für den bereits erwähnten Offline-Betrieb etwa zur Abarbeitung der vom Stapler-Agent im Transportmodus verwalteten, eigenen Aufgaben-Warteschlange mit Transporteinheits-Agenten. Diese Warte-

27  Agentenbasierte Staplerleitsysteme

311

schlange wird im Online-Modus regelmäßig überprüft und aktualisiert. Denn zur Vermeidung von Wartezeiten der TE und einer weiteren Optimierung des Gesamtprozesses können die TE-Agenten, die sich in der Warteschlange eines Terminals befinden, nach Bedarf die Warteschlange verlassen und zu anderen Terminal-Agenten migrieren. Ebenso führen die durch RFID oder per MDT-Eingabe erfassten Ortswechsel jeweils zu einem Neuladen (Austauschen/Verwerfen) der Arbeitspakete. Natürlich muss auch die Abmeldung eines Benutzerterminals dazu führen, dass die TE-Agenten, die sich in der Warteschlange des jeweiligen Terminals befinden, sofort auf die anderen tätigen Terminals neu verteilt werden. Die wichtigste Aufgabe der Manager-Agenten ist jedoch die Ermittlung von Aufträgen auf Anforderung der MDT-Anwender. Dabei spricht der MDT-Anwender über das Graphical User Interface automatisch den dahinter liegenden StaplerAgent an. Dieser prüft, ob er die Aufgabe selbst lösen kann. Wenn nicht, dann leitet er die Anfrage per Funk an den Server weiter. Dort ermittelt dann der ManagerAgent eine passende Lösung. Grundsätzlich jedoch wird für jedes MDT ein Auftragsmodus definiert. Möglich sind die drei Modi „Transport automatisch/frei“, „Kommissionierung automatisch/ frei“ und „Inventur“. Für jeden Auftragsmodus werden gesonderte Strategien angewendet. Die detaillierte Beschreibung dieser Merkmale verdeutlicht die Prozessschritte. Im Modus „Transport automatisch/frei“ koordiniert das aSLS physische Transporte von TE über Transportaufträge (TPA). Dabei bezieht sich jeder TPA immer auf eine Transporteinheit, einen Ist-Platz und den einen End-Zielplatz. Als Transportarten sind Einfachtransporte, Mehrfachtransporte und Einlagertouren vorgesehen. Beim Einfachtransport wird dem Staplerfahrer auf dem MDT der Transportauftrag angezeigt und vorgegeben, zu welchem Platz er fahren und welche TE er aufnehmen soll. Durch eine obligatorische Prüfscannung bei TE-Aufnahme wird automatisch der Zielplatz für die TE auf dem MDT angegeben. Für einen Mehrfachtransport muss das Fahrzeug mehr als eine TE aufnehmen können. Die TE werden jedoch unabhängig voneinander behandelt. Bei Einlagertouren muss das Förderzeug mehr als eine TE aufnehmen können. Die TE sind abhängig voneinander, gehören aber zu einer Gruppe. Während der Transporte bleibt die TE bis zum Abschluss des Fahrauftrags auf ihren letzten Melde-Platz gebucht. Bei Bedarf unterteilt das aSLS einen TPA in mehrere Teiltransporte, die über Folgeziele durchgeführt werden. Die Gliederung in Teiltransporte erfolgt anhand der konfigurierten Wege und richtet sich dynamisch nach den Plätzen, an denen die TE während der Transportdurchführung gemeldet wird. Jeder der Teiltransporte bezieht sich auf eine konkrete Wegstrecke im GesamtTPA, die von einer Transportressource befahren werden kann. Das aSLS ermittelt kontinuierlich neue, zum Endziel führende Folgeziele, bis die TE am Zielplatz gemeldet wird. Damit ist ein Transportauftrag abgeschlossen. Für den Modus „Transport automatisch“ werden die Aufträge dem MDT auf Initiative des aSLS-Managements zugewiesen. Das aSLS-Management ermittelt den nächsten Auftrag. Solange der Stapler-Agent online ist, nimmt er den nächstbesten TPA aus dem TPA-Pool und aktualisiert seine eigene TPA-Offline-Liste (TPA-OL).

312

S. Göhring und T. Lorenz

Wenn der TPA ausgeführt und der Stapler offline ist, wird der nächste TPA aus der TPA-OL ermittelt. Die Rückmeldungen zu den ausgeführten Aufträgen (Bestätigungen, Alarme und dergleichen) sowie weitere Aktualisierungen sind erst wieder möglich, wenn der Stapler online ist. Hierzu wird ein Verfahren angewendet, das in Abhängigkeit von Fahrzeugtyp und Aufenthaltsort des Anwenders beziehungsweise Fahrzeugs den optimalen Auftrag ermittelt. Im Modus „Transport frei“ werden die Aufträge vom Anwender beim ManagerAgenten angefordert. Die Fahrer können selbst entscheiden, welche Transportaufträge sie durchführen möchten. Dafür ist die Eingabe der entsprechenden TE notwendig. Der Anwender meldet am MDT eine TE. Das aSLS-Management prüft, ob für die gemeldete TE ein Transportauftrag vorhanden ist, ob der Anwender diesen Transportauftrag durchführen kann und darf und meldet den Transportauftrag mit Angabe des Ziels an den Anwender. Das weitere Vorgehen erfolgt analog zum automatischen Transportauftrag. Ähnlich die Optionen bei den Auftragsmodi „Kommissionierung automatisch/ frei“: Kommissionierung ist das Zusammenstellen von bestimmten Teilmengen (Artikeln) aus einer bereitgestellten Gesamtmenge (Sortiment) aufgrund eines Auftrages. Alle zur Kommissionierung benötigten Informationen kommen über die Schnittstelle vom übergeordneten Warehouse Management System. Bei einer aSLS-geführten Mann-zur-Ware-Kommissionierung werden die Kommissionierer in Einzelschritten über das mobile Datenterminal (MDT) geführt. Die aSLS-Führung berücksichtigt Einschränkungen, die beispielsweise dem Förderzeug geschuldet sind. Entnahmebuchungen erfolgen online per MDT oder werden lokal im Terminal gespeichert, wenn der Stapler offline ist. Die jeweiligen Bestätigungen erfolgen dann, wenn das Terminal wieder online ist. Für Reservierungen werden auf dem MDT Artikel, Bezeichnung, Entnahmemenge, Mengeneinheit angezeigt. Nach der Pickbestätigung wird die jeweilige Entnahmemenge in einer Ziel-TE verstaut und die Identifikationsnummer der Ziel-TE gescannt. Bei Bedarf können Etiketten gedruckt werden. Schließlich wird die Entnahmemenge auf die Ziel-TE umgebucht. Bei eventuell auftretenden Abweichungen vom Soll ist eine Online-Dialogführung via MDT vorgesehen. Als Kommissionierarten sind auftragsreine Picks und Multiorderpicks vorgesehen. Bei Multiorderpicks wird die Kommissionierung gleichzeitig für mehrere Ziel-TE durchgeführt. Die erforderlichen Entnahmeschritte sind mit denen der Einfachkommissionierung identisch. Dabei ist für jeden Auftrag zunächst die Ziel-TE einzugeben, die die zu kommissionierende Ware aufnehmen soll (Träger-TE). Wird die vorgegebene TE korrekt bestätigt, erscheinen die notwendigen Informationen für die Entnahme. Die Entnahme der korrekten Menge muss durch die Eingabe der Ziel-TE bestätigt werden. Danach wird – wenn vorhanden – der nächste Quellplatz angezeigt. Sind alle Artikelmengen kommissioniert, wird dem Fahrer der anzufahrende Zielplatz angegeben. Dieser Vorgang muss wiederum mit dem Lagerplatzcode bestätigt werden. Wichtigster Unterschied zwischen dem Modus „Kommissionierung automatisch“ und „Kommissionierung frei“ ist die Art, wie die Kommissionierliste erstellt

27  Agentenbasierte Staplerleitsysteme

313

wird. Im Automatik-Modus wird die Pickliste zentral generiert. Anhand dieser Pickliste ermittelt das WMS für den Anwender die zu kommissionierenden Artikel. Bei der Kommissionierung werden Bestände von einer Quell-TE entnommen und in eine Ziel-TE umgebucht. Im Modus „Kommissionierung frei“, der nur dann gewählt werden kann, wenn der Stapler online ist, muss die Pickliste vorher generiert und dem Staplerfahrer bekannt gemacht worden sein. Dabei wird die entsprechende Picklisten-Nummer im MDT eingegeben. Das WMS ermittelt anhand dieser Nummer die zu kommissionierenden Artikel. Der weitere Ablauf erfolgt analog der automatischen Kommissionierung. Die Kommissionierprozesse können sowohl online als auch offline durch­ geführt werden. Denn in beiden Fällen werden die Informationen zunächst lokal bearbeitet – lediglich ihre Weiterleitung erfolgt zu unterschiedlichen Zeitpunkten: Im Online-Modus kann die Rückmeldung an das WMS sofort nach der Bearbeitung erfolgen. Wenn der Stapler offline ist, werden die Ergebnisse zunächst in einem Puffer gespeichert, was einer Pickzettel-Kommissionierung ähnelt. Der wesentliche Unterschied von aSLS-Kommissionierung zur konventionellen Pickzet­ tel-Kommissionierung besteht darin, dass eine Rückmeldung früher erfolgen kann als nach vollständiger Abarbeitung der Kommissionierliste. In dem Moment, wenn ein Stapler online geht, werden die vorhandenen Daten sofort übertragen. Die Anwender erhalten bei diesem Prinzip ausschließlich Aufträge für Kommissionierungen. Dazu wird der Anwender zuerst beauftragt, eine Ziel-TE aufzunehmen. Pro Kommissionierung wird eine separate Warteschlange verwaltet, die nach Bedarf unterbrochen werden kann. Dies wird beispielsweise gewünscht, um während der Abarbeitung einer langen Pickliste zwischendurch mit demselben MDT einen Eilauftrag kommissionieren zu können. Nach der Abarbeitung des Eilauftrags kann dann mit den Aufträgen der ursprünglichen Kommissionierliste fortgefahren werden. Um vom Kommissioniermodus zum Transportmodus (und umgekehrt) zu wechseln, muss der Stapler online sein. Bei einem solchen Wechsel werden vorhandene Aufträge/Kommissionierungen/Inventurlisten zurück in den Pool gegeben. Der Inventur-Modus zielt auf die Kontrolle der im Lager vorhandenen Bestände. Pro Inventur bekommt jedes MDT eine Liste mit TE-Positionen, die kontrolliert werden sollen. Alle in der Inventur-Liste angegebenen TE erhalten dabei eine Inventursperre für andere MDT. Sie können dann weder reserviert noch ausgelagert, kommissioniert oder zugelagert werden. Durch diese Sperrung können Inventuren unproblematisch sowohl im Online als auch Offline-Betrieb durchgeführt werden. Die Ergebnisse der Inventur werden erst lokal im Stapler-Agent gespeichert und erst nach dem Inventur-Ende zum Manager-Agent weitergeleitet. Das aSLS-Management kann jedem Anwender mehrere Inventuraufträge zuweisen. Auf gleiche Weise wie bei der Kommissionierung wird für die Inventur eine separate Warteschlange verwaltet, deren Abarbeitung in den dringenden Fällen auch unterbrochen und später fortgesetzt werden kann. Für solche Inventuren legt das WMS Inventuraufträge aus einer vom Host übernommenen Liste von Stichproben-Artikeln an. Aus den Inventuraufträgen werden Sätze im Inventurpool und daraus die Inventur-Listen erzeugt. Zur Durchführung der operativen Prozessschritte werden Platz und Artikel auf dem MDT angezeigt. Nach

314

S. Göhring und T. Lorenz

Zählung der Bestände wird die ermittelte Bestandsmenge eingegeben und mit der Funktion „buchen“ bestätigt. Danach erfolgt die Bearbeitung der nächsten InventurPosition. Wenn alle Inventurlistenpositionen, die zu einer Inventurauftragsposition gehören, abgearbeitet sind, wird die Inventurauftragsposition im WMS abgeschlossen. Mit Abschluss einer Inventur-Liste ist zugleich die Inventur der in der Liste enthaltenen Bestände beendet. Als Ergebnis der Inventur werden die gegebenenfalls ermittelten Bestandsdifferenzen direkt vom aSLS oder über das WMS an das Hostsystem übermittelt. In tabellarischer Übersicht lassen sich die Strategien und die Vorteile für die logistischen Prozesse unter Verwendung eines aSLS wie folgt zusammenfassen (s. Tab. 27.1). Dabei beschreiben die Buchungstypen „Fest“ und „Frei“, Determinanten der Prozesse, die Kennzeichnungen „+“ und „−“ verschiedene Modi der angegebenen Funktionen. Beim Buchungstyp „Fest“ weist das System dem Anwender genau zu, wo die Artikel abzulegen sind. Der Stellplatz ist exakt vorgegeben. Ein anderer darf nicht genutzt werden. Der Buchungstyp „Frei“ bietet hingegen Optionen: Das System gibt den Ablageplatz vor, aber der Anwender darf bei Bedarf auch einen anderen Platz nutzen. An dieser Stelle kann es zu konzeptionellen Inkonsistenzen („+/−“) kommen („Frei“, „Offline“). Für diese Problematik muss in weiteren Entwicklungsschritten ein Lösungskonzept generiert werden. Tab. 27.1   Vergleich Online- und Offline-Modus Grundfunktion Buchungstyp Sonderfälle Transport Einfach Mehrfach Einlagetour

Fest Frei Fest Frei Fest Frei Fach voll Fach leer

Kommissionierung Einfach Multipickorder Quelle leer TE voll Fehlmenge (Nahe-) Null-Inventurzählung Zu viel Bestand auf Quell-TE Artikelfehler Inventur Information

Online

Offline

+ + + + + + + +

+ − + − + − +/− +

+ + + + + + + + + +

+ + + + + − + + + −

27  Agentenbasierte Staplerleitsysteme

315

Überdies können weitere Sonderfälle auftreten, in denen es gegebenenfalls problematisch werden könnte, gestellte Aufträge oder Anforderungen im Offline-Modus abzuarbeiten. Zur Deskription und Lösungsfindung solcher Fälle sind weitere Untersuchungen und Konzipierungen erforderlich. Die Funktionalität ist in der nachfolgenden Tabelle in unterschiedlichen Modi als „+“ (problemlos), „−“ (Inkonsistenzen möglich) und „+/−“ (spezielle Lösungen erforderlich) charakterisiert. Die Tabelle veranschaulicht deutlich, dass der wesentliche Unterschied zwischen herkömmlichen SLS und einem aSLS im dezentralen Management der Stapleraufträge liegt. Während die Funktionen eines SLS ausschließlich im Online-Betrieb genutzt werden können, ermöglicht die Einbindung der Agententechnologie selbst eine sequenzielle Auftragsbearbeitung auch offline – und damit eine weitgehende Unabhängigkeit von der zentralen Transportauftragsverwaltung.

27.6  Exkurs: Zusammenführung mit IdentProLog Neben dem Forschungsprojekt „Internet der Dinge“ ist PSI Logistics unter anderem an dem Forschungsprojekt „IdentProLog“ beteiligt. Hauptziel dieses Projektes ist es, auf Basis von RFID-Anwendungen ein Zielführungssystem zur durchgängigen Steuerung des Materialflusses in einem Produktionsbetrieb zu entwickeln (s. Abb. 27.6). Maxime des Projektes: Erkennen statt Scannen. Dabei werden Flurförderzeuge als Schlüsselelement zur Selbststeuerung von Logistiksystemen eingesetzt. Durch den Einsatz von RFID-Technik und modernem Datenfunk soll das Flurförderzeug als „mobiles Gate“ zur automatischen Erfassung der Produktladungsträger im innerbetrieblichen Bereich dienen und als Koppelelement zu den Leit-, Führungs- und Managementebenen fungieren. Von einem derartigen System sollen möglichst viele Branchen profitieren, die Flurförderzeuge und Ladungsträger einsetzen. Daher wird im Laufe des Projektes bei der Identifizierung der Ladungsträger ein allgemeiner Standard angestrebt, auch im Hinblick auf Poolfähigkeit. Die Modularisierung der Komponenten dieses Zielführungssystems ermöglicht die Entwicklung einer flexiblen Lösung, die an die Anforderungen verschiedener Anwender angepasst werden kann. Hauptaufgabe der PSI Logistics in diesem Forschungsprojekt ist die Entwicklung der entsprechenden Algorithmen, Datenmodelle und Funktionsabläufe, sowie die Realisierung einer Software-Demonstrationslösung zur Verifizierung der Ergebnisse. Im Zusammenhang mit dem Forschungsprojekt „Internet der Dinge“ lassen sich aus den Ergebnissen von IdentProLog interessante Optionen ableiten. Wichtigste Komponente von IdentProLog ist ein Software-Kommunikationsmodul im Datenterminal auf dem Stapler. Dieses Zielführungssystem (ZFS), die so genannte Ereignisbox, ermittelt anhand der RFID-Daten Prozessereignisse und meldet sie über das Kommunikationsmodul als definierte Standardschnittstelle an das Staplerleitsystem. Die Prozessdatenerfassung wird auf diese Weise durchgängig automatisiert.

316

S. Göhring und T. Lorenz

Produktion

Intralogistik Umschlagsstation z.B. Regal

„mobiles Gate“

WLAN, Datenfunk

RFID

Ladungstrager

zentrale DV-Systeme PPS

ERP

WMS

Abb. 27.6   Erkennen statt scannen – Informationserfassung bei IdentProLog (http://www. identprolog.de/projektziele.html)

Es ist nun vorstellbar, das aSLS-Konzept und IdentProlog in künftigen Entwicklungsschritten zusammenzuführen (s. Abb. 27.7). Zusätzlich zum ZFS aus dem IdentProLog wird das Staplerterminal mit der aSLS-Software ausgestattet. Das führt dazu, dass die staplerspezifischen Daten wie Staplertyp, Hubhöhe, Lastaufnahmemittel, maximale Gewichtaufnahme oder Restlaufzeit mit Hilfe der Stapler-Ereignisbox und des RFID-Lesegerätes über USB-Anschluss an den aSLSStapler-Agenten weitergeleitet werden. Diese Daten können dann ohne nennenswerten Aufwand per Plug&Play in das Gesamtsystem übernommen werden. Die Einsatzbereiche des neuen Flurförderzeuges/Terminals sind im Warehouse Management System PSIwms hinterlegt. Damit ist das Terminal sofort verfügbar, der Stapler ohne aufwändige Programmierungen umgehend in die Prozesse integrierbar. Das aSLS wäre in einer solchen Anwendung für die dezentrale Staplerführung und die Transportauftragsberechnung verantwortlich. Das Konzept einer solchen Anbindung des Terminals an die Steuerung des Staplers existiert bereits. Aber praxisfreie Anwendungen erfordern weitere Untersuchung und Kooperationsprojekte mit den Staplerherstellern.

27  Agentenbasierte Staplerleitsysteme

317

Staplerterminal

aSLS

WLAN

Kommunikations modul

Server aSLS WMS

Ereignisbox RFID

Abb. 27.7   Zusammenführung von aSLS und IdentProLog

27.7  Fazit Die Entwicklung eines Agenten-basierten Staplerleitsystems (aSLS), das zeigen die genannten Beispiele, kann den Anwendern eine Reihe nachhaltige Vorteile bieten (s. Tab. 27.2). Notwendige Voraussetzung ist eine aSLS-Implementierung, die eine Schnittstelle innerhalb des WMS nutzen kann. Darüber hinaus müssen die MDTHersteller bezüglich der Staplerlaufzeitumgebung an einem Hardware-/SoftwareStandard arbeiten, um ein reibungsloses Funktionsspektrum des Systems gewährleisten zu können. Gleichwohl ermöglicht das aSLS gegenüber einem herkömmlichen SLS einen erhöhten Grad an Skalierbarkeit. Die hohe Standardisierung des Systems birgt zudem ein großes Potenzial sowohl hinsichtlich einer schnellen Verfügbarkeit als auch mit Blick auf künftige Veränderungen des Gesamtsystems. Die Einbindung weiterer oder der Austausch vorhandener MDT ist ebenso komfortabel realisierbar wie, basierend auf den definierten Standardschnittstellen, die Integration des aSLS selbst in vorhandene IT-Infrastrukturen beziehungsweise die Einbindung oder Ablösung umgebender Systeme. Die verfügbaren Simulationsoptionen bieten Tab. 27.2   Vor- und Nachteile eines aSLS Vorteile • Standardisierbarkeit • Skalierbarkeit • Offline Betriebsmodus • Simulation • Terminal-Austauschbarkeit • Rechenleistungsverteilung

Nachteile • Offline Betriebsmodus ist nur bedingt möglich • Entwicklungsaufwand

318

S. Göhring und T. Lorenz

effiziente Grundlagen zur Dimensionierung der Förderzeug-Flotte sowie zur Optimierung der Einsätze vorhandener Flurförderzeuge. Mit ihrer Hilfe lassen sich zudem Systemerweiterungen deutlich vereinfachen. Die Verteilung der Rechenleistung vom zentralen System auf die dezentralen Terminals erschließt überdies Systempotenziale im IT-Bereich. Besonders interessant erscheinen die Potenziale des Offline-Betriebsmodus. Die Aufgabenverteilung, die Abarbeitung von Aufträgen bei gleichzeitiger Sperrung oder Reservierung der benötigten Ladungseinheiten (LE) sowie die selbstständig ausgeübten Ausgleichsprozesse bei Sollabweichungen erschließen vielfältige Optionen für individuelle Kommissionierstrategien und Auftragsmanagement. Kritisch ist anzumerken, dass der Offline-Betriebsmodus beim gegenwärtigen Entwicklungsstand jedoch nur bedingt möglich ist, weil er keine Spontanreaktion auf Änderungen im Zentralsystem oder auf Fehlersituationen bei Auftragsausführung zulässt. Gegen eine breite Anwendung von aSLS-Lösungen spricht zudem der gegenwärtige Stand im Bereich der Software-Architektur herkömmlicher Warehouse Management Systeme. Viele von ihnen sind auf eine Service-orientierte Architektur und die Integration der Agententechnologie noch gar nicht ausgerichtet. Und nicht nur auf diesem Terrain sind noch einige, mehrjährige Entwicklungs- und Implementierungsschritte zu gehen. Ungeachtet der vielen Vorteile, die das Agenten-basierte Staplerleitsystem bietet, sind für eine Weiterentwicklung des Konzeptes über den gegenwärtigen Entwicklungsstand hinaus noch einige Hürden zu nehmen. Chancen für eine Fortführung böten sich in einer konzertierten Aktion etwa mit Stapler-Herstellern und Integratoren, die deutlich von den Systemvorteilen profitieren können. Die Integration des Systems etwa im Rahmen von Miet- und Servicekonzepten kann den Rahmen dafür bieten, die Entwicklung noch fehlender Details für eine umfassende aSLS-Lösung mit einem wirtschaftlichen Interesse zu verknüpfen. In jedem Fall sind mit dem gegenwärtigen aSLS-Konzept die Grundlagen für ein weiteres Mosaiksteinchen zur Verwirklichung der Vision von Internet der Dinge gelegt.

Kapitel 28

Hochflexible, RFID-gesteuerte   Handhabung von Stückgut Walter Schaaf und Razvan Chisu

Das Internet der Dinge zielt auf die Schaffung wandelbarer Materialflusssysteme. Solche Anlagen müssen, neben einer hohen Durchsatz- und Layoutflexibilität auch eine hohe Fördergutflexibilität aufweisen (Wilke 2006). Ein wichtiges Szenario dabei ist das Depalettieren und Vereinzeln unterschiedlicher Produkte in Primär- und Sekundärverpackungen oder Gebinden unter Einsatz von Industrierobotern (Schaaf 2006). Beispiele für dieses Szenario sind das Einund Auslagern im innerbetrieblichen Materialfluss oder insbesondere der internetbasierte Versandhandel. Es ist daher eine Schlüsselaufgabe, die Funktionsweise und den Nutzen eines RFID-basierten Materialflusses im Sinne des „Internet der Dinge“ an diesem Szenario exemplarisch umzusetzen und zu validieren.

28.1  Anlagenkomponenten und Teilsysteme Das Szenario Depalettierroboter umfasst im Allgemeinen folgende Anlagenkomponenten, Teilsysteme und Elemente: • für die Intralogistik und den Versandhandel typische Objekte (z. B. Schachteln, Behälter, Gebinde, Beutel) • Objektträger, in oder auf welchen die Objekte transportiert werden (z. B. Paletten, Gitterboxen, Behälter) • Handhabungssystem bzw. Industrieroboter mit für diesen Einsatzfall typischer Kinematik und Leistung (z. B. 4-Achs-Palettierroboter, 6-Achs-Knickarm-Robo­ ter, Portalsysteme) • Lastaufnahmemittel bzw. Robotergreifer mit vorteilhaft kombinierten Greifprinzipien für hohe Flexibilität sowie Prozesskontrolle und Zustandsvisualisierung

W. Schaaf () Leiter Vorentwicklung und Produktentwicklung Vakuum-Komponenten, J. Schmalz GmbH Aacher Strasse 29, 72293 Glatten, Deutschland e-mail: [email protected] W. Günthner, M. ten Hompel (Hrsg.), Internet der Dinge in der Intralogistik, DOI 10.1007/978-3-642-04896-8_28, © Springer-Verlag Berlin Heidelberg 2010

319

320

W. Schaaf und R. Chisu

• Zuführeinrichtungen mit Übergabeplätzen, die die Objektträger und Objekte in die Roboterzelle bringen (z. B. Rollenbahnen, Förderbänder) • Lager- oder Transporteinrichtungen, an die die Objekte oder Objektträger abge­ geben werden und diese aus der Zelle transportieren • RFID-System mit Transpondern, die entweder an den Objekten oder an den Objektträgern angebracht sind sowie Lese- und ggf. Schreib-Einheiten, die am Lastaufnahmemittel oder an den Übergabeplätzen angebracht sind • Anlagen-, Roboter und ggf. Greifersteuerung

28.2  A  nforderungen an die Greiftechnik   für das Internet der Dinge Aus dem Paradigma „Internet der Dinge“ mit dezentral über RFID gesteuertem Materialfluss, dem Szenario Depalettierroboter sowie allgemeinen Trends ergeben sich grundlegende Anforderungen an die Greiftechnik. Um ein möglichst großes und ggf. wechselndes Produktspektrum abzudecken ist es vorteilhaft, unterschiedliche Greifprinzipien in einem Greifer zu kombinieren. Je nach Eigenschaften des zu greifenden Objekts wie Abmessungen, Gewicht, Oberflächenbeschaffenheit, Material und Schwerpunkt kann dann das jeweils geeignete Greifprinzip angewendet werden. Die Kombination von Greifprinzipien bei einem bestimmten Objekt kann auch zur Erhöhung der Prozesssicherheit und der Prozessgeschwindigkeit beitragen. Neben der Flexibilität hinsichtlich einem bekannten und vorhersehbaren Produktspektrum wird unter dem Begriff Wandelbarkeit oft das Abdecken bisher unbekannter Anforderungen und damit beispielsweise die Adaptiviät auf vorher unbekannte Greifobjekte verstanden. In diesem Sinne soll die Greiftechnik möglichst flexibel und wandelbar bezüglich des vorgesehenen und unvorhergesehenen Produktspektrums sein. Wird der Begriff Wandelbarkeit auf die Greiftechnik selbst bezogen, bietet es sich an, darunter die Fähigkeit zu verstehen, möglichst schnell durch manuellen oder automatischen Eingriff auf neue Anforderungen angepasst werden zu können. Dies setzt eine modulare Bauweise in Funktionsbausteinen und definierte Schnittstellen voraus und wird durch Wireless-Technologien erleichtert. Die Greifprinzipien sollten bezüglich Greifraum und -kraft skalierbar sein, damit die Objekte schonend und beschädigungsfrei gegriffen werden können. Eine Skalierbarkeit der Greifkraft trägt auch dem allgemeinen Trend zur Energieeffizienz Rechnung, indem der Energieverbrauch genau auf die tatsächlich erforderliche Greifkraft angepasst wird. Auf Basis der RFID-Daten der Objekte ist der Greifprozess so zu steuern, dass Prozesssicherheit und -geschwindigkeit maximiert und gleichzeitig der Energieeinsatz minimiert wird. Dies bedeutet, dass aus den Objekt- und Zieldaten, die in den Transpondern abgelegt sind, mittels geeigneter Prozessmodelle Greifparameter berechnet werden.

28  Hochflexible, RFID-gesteuerte Handhabung von Stückgut

321

Für eine hohe Prozesssicherheit und Anlagenverfügbarkeit ist eine Prozessüberwachung und Zustandsvisualisierung des Greifprozesses wünschenswert. Die Greifparameter können hierzu durch geeignete Sensorik erfasst und von der Greifersteuerung online ausgewertet werden. Alle relevanten Daten des Greifsprozesses können mittels Web-Technologien für eine Zustandsvisualisierung zugänglich gemacht werden. Selbstverständlich sind bei der Auslegung der Greiftechnik auch die Randbedingungen der Anlagentechnik und des Layouts zu berücksichtigen. Maximale Nutzlasten des Handhabungssystems dürfen nicht überschritten werden. Störkonturen von Greifern und Objekten dürfen beim Greifvorgang und beim Transport keine Kollisionen verursachen. Die Zugänglichkeit an den Übergabe- und Abgabeplätzen muss gewährleistet sein. All dies ist insbesondere dann nochmals zu überprüfen, wenn unvorhergesehene Produktwechsel stattfinden, bei denen Objekte mit anderen Eigenschaften als bisher vorkommen.

28.3  S  ystemkonzept der Greiftechnik für RFID-basierten Materialfluss Gemäß den Anforderungen wurde das in Abb. 28.1 dargestellte Systemkonzept der RFID-basierten Greiftechnik für das Internet der Dinge entwickelt. Die Abbildung zeigt eine Kombination von mechanischem Klemmgreifen und Sauggreifern. Ausgehend von den durch die RFID-Lesegeräte zur Verfügung gestellten Daten der Greifobjekte wird der Greifprozess von der Greifersteuerung oder der übergeordneten Steuerung der Handhabungseinrichtung bzw. des Industrieroboters gesteuert. Das in der Steuerung hinterlegte Prozessmodell berechnet dabei aus den Zieldaten und Objektdaten wie Gewicht, Abmessungen, Schwerpunkt, Porosität, Oberfläche und Stabilität die je nach anzuwendendem Greifprinzip erforderlichen Greif- und Prozessparameter wie Verfahrgeschwindigkeit und -beschleunigung, Klemmkraft bei mechanischem Greifen, erforderlicher Unterdruck und Saugvolumenstrom bei Sauggreifern, Verbrauch an elektrischer Energie und Druckluft. Für hohe Verfahrgeschwindigkeiten und damit -beschleunigungen sind grundsätzlich höhere Klemmund Saugkräfte und damit höherer Energieeinsatz für das Greifen erforderlich. Im allgemeinen Fall muss die Auswertung der RFID-Objektdaten nicht unbedingt von der Greifer- oder Robotersteuerung vorgenommen werden. Im Sinne von Komponenten mit „dezentraler Intelligenz“ ist zukünftig auch die direkte Anpassung einzelner Komponenten des Greifsystems ohne den Umweg über eine übergeordnete Steuerung denkbar. In dieser Vision werden dann beispielsweise Sauggreifer, Ventile, Vakuumerzeuger und Antriebe direkt vom Objekt durch dessen RFID-Daten gesteuert. Im Sinne der oben genannten Wandelbarkeit als Fähigkeit des Greifsystems auf unvorhergesehene neue Anforderungen mit geringem Aufwand manuell oder automatisch angepasst zu werden, ist ein weiteres visionäres Konzept denkbar. Hierbei

322

Gewicht Abmessungen

W. Schaaf und R. Chisu Handhabungseinrichtung / Steuerung Roboter / Robotersteuerung

Beschleunigung

Greifer / -steuerung

Geschwindigkeit

Schwerpunkt Porosität Oberfläche

... Ventil

max. Unterdruck

Ventil

...

Dichte Stabilität

Saugvolumenstrom

IDD-Objekt

Klemmkraft Energieverbrauch (elektrisch) Druckluftverbrauch

Abb. 28.1   Systemkonzept der RFID-basierten Greiftechnik für das Internet der Dinge

sind die Greiferkomponenten selbst mit RFID-Transpondern ausgestattet. Die übergeordnete Steuerung kann dann zum einen die richtige Zusammenstellung der Komponenten zu einem Gesamtsystem überprüfen und zum anderen die Fähigkeit des Gesamtsystems ermitteln.

28.4  Kombination von Greifprinzipien Die Forderungen nach einem möglichst großen Produktspektrum, hoher Produktflexibilität sowie hoher Prozesssicherheit insbesondere bei hohen Verfahrgeschwindigkeiten und -beschleunigungen kann durch die Realisierung nur eines Greifprinzips alleine oft nicht erfüllt werden. Die Lösung hierzu besteht darin, mehrere unterschiedliche Greifprinzipien zu kombinieren und je nach Phase des Greifvorgangs oder an bestimmten Greifflächen am Objekt zur Anwendung zu bringen. Beispielsweise kann eine Schachtel zunächst mit Sauggreifern an der Oberseite aufgenommen werden, vor dem schnellen Transport mit einem mechanischen Untergriff gesichert und in einem Klemmgriff, der an gegenüberliegenden Seiten angreift, in ein schmales Regal abgelegt werden. Bei Bedarf können folgende Phasen eines Greifzyklusses unterschieden werden, denen unterschiedliche Greifkonfigurationen zugeordnet werden können und die ggf. unterschiedliche Prozessüberwachungsfunktionen je nach Greifprinzip erfordern: • Phase 1: Anfahren, wobei das Handhabungssystem den Greifer die Nähe des Objekts bringt • Phase 2: Auf- bzw. Ansetzen, wobei meist mit reduzierter Geschwindigkeit die erste Berührung zwischen Objekt und Greifer stattfindet und das Objekt oft Positionsungenauigkeiten bzw. -toleranzen relativ zum Greifer ausgleicht • Phase 3: Greifkraft aufbringen, z. B. Klemmen oder Ansaugen • Phase 4: Anheben, z. B. mit reduzierter Geschwindigkeit

28  Hochflexible, RFID-gesteuerte Handhabung von Stückgut

323

• Phase 5: Transportieren, z. B. mit erhöhter Geschwindigkeit unter Berücksichtigung der Prozesssicherheit • Phase 6: Ablegen, wobei vorher ggf. unter Berücksichtigung der Platzverhältnisse die Greifkonfiguration zu wechseln ist • Phase 7: Abheben bzw. Wegfahren des Greifers vom Objekt, wobei der Kontakt des Greifers zum Objekt gelöst wird Für die systematische Auslegung von Greifsystemen wurden für das Szenario Depalettierroboter relevante Greifprinzipien und deren Parameter identifiziert. Die Abb. 28.2 zeigt diese Greifprinzipien sowie eine Methode zur Ableitung von Greifkonfigurationen am Beispiel eines quaderförmigen Greifobjekts. Das dargestellte Beispiel zeigt die Kombination von Sauggreifern an der Oberseite des Objekts mit einem mechanischen Klemmgriff durch Haftreibung an zwei seitlichen Flächen. So definierte Greifkonfigurationen können dann Greifobjekten und -phasen zugeordnet werden. Hierzu werden die Greifkonfigurationen im Prozessmodell der Steuerung hinterlegt und je nach RFID-Daten des Objekts und Ablaufschritt des Greifvorgangs aktiviert. Die abstrahierten Greifkonfigurationen werden dann von der Greifersteuerung in Stellparameter des Greifers übersetzt, um den Greifer selbst in den für diese Greifkonfiguration erforderlichen Modus zu bringen.

28.5  K  onzeption eines Greifers für das Szenario Depalettierroboter Bei der Konzeption eines Greifers für das Szenario Depalettierroboter wurde das Ablaufschema in Abb. 28.3 angewendet. Für die zu realisierende Roboterzelle wurde zunächst das zu berücksichtigende Produktspektrum analysiert. Für das Szenario wurde vereinbart, dass Leerpaletten, große Kartons, Kleinladungsträger bzw. VDA-Behälter sowie kleine Kartons gegriffen werden sollen. Kartons und Behälter werden auf den Paletten bereit gestellt. Kleine Kartons können sich auch in Behältern befinden, aus denen sie herausgegriffen werden müssen. Unter Berücksichtigung der Prozesssicherheit und der Greiferkosten wurden aus den Greifprinzipien in Abb. 28.2 das formschlüssige Greifen, das Klemmen und Ansaugen mit Unterdruck ausgewählt und den Greifflächen der unterschiedlichen Objekte zugeordnet. Durch Synthese der zu realisierenden Greifkonfigurationen wurde das Gesamtkonzept des Greifers abgeleitet.

28.6  Realisierte Anlage für das Szenario Depalettierroboter Abbildung 28.4 zeigt die am Lehrstuhl für Fördertechnik Materialfluss Logistik der TU München realisierte Demonstrationsanlage zur Verifikation des RFID-basierten Materialflusses. Zum Einsatz kommt ein Sechs-Achs-Knickarmroboter der Firma

C

G

FR,G/H

Aufrollgreifer

S6

S1

S3

S2

Technischer Schaum

F

G

∼ΣFV,i

pU

fluidisch

Beispiel

Greifprinzip

Objektseite E

S1

B

Paket

S2

-

S3

B

S5

G

FW

-

S6

H

Q

Paket / E B - - B -

V

AQ A

“Staubsauger” FW = 1/2 ρ CW V2 A mit v ≈ Q / AQ

Greifkonfiguration:

-

S4

G

G

FV

pU

Luftstrom Q Globale Saugzelle

“Vorhang” FV = pU *A

Vakuum FV = pU A

Abb. 28.2   Greifprinzipien und Methode zur Ableitung von Greifkonfigurationen

S5

S4

E

G

ΣFV,i

pU

Sauggreifer

i lokale Saugzellen FV = Σ FV,i

Greifprinzipien

Zuordnungstabelle Objektseite/Greifprinzip

D

G

FR,G

Reibgreifer

Gleitreibung FR,G = µR FN

Reibschluss F = µ FN

Beschreibung quaderförmiger Objekte

B

G

G

A

FR,H

Haftreibung FR,H = µH FN

-G

Formschluss F=ma

mechanisch

324 W. Schaaf und R. Chisu

28  Hochflexible, RFID-gesteuerte Handhabung von Stückgut

325

0

80

Analyse des Produktspektrums

1200

0

VDA

0

30

500

0

30

klK Zuordnung von Greifprinzipien unter dem Aspekt der Prozesssicherheit

150

S1

S4

S2 S3

S5

A

Definition der erforderlichen Greifkonfigurationen

0

15

500

100

595

200

grk

5

38

300

700

280

Pal

300

50

Pal / -----A

B

VDA / -A--A-

S6

E

grk / EB--B-

grk / E----A

klK / E-----

Gesamtkonzept des Greifers durch Synthese der Greifkonfigurationen

Abb. 28.3   Konzeption eines Greifers für das Szenario Depalettierroboter

Kuka und des Typs KR210 L150, der mit dem von der Firma Schmalz entwickelten Greifer ausgestattet ist. Die Roboterzelle wird über eine Schwerlastrollenbahn mit Europaletten mit VDA-Kleinladungsträgern (KLT) mit den Maßen 400×600 mm und/oder Kartons der Roboterzelle versorgt. Eine weitere Schwerlastrollenbahn dient dem Abtransport von Paletten aus der Roboterzelle (s. Abb. 28.4). Ein dritter Rollenförderer für KLTs schafft eine Verbindung zwischen der Roboterzelle und einer Elektrohängebahnanlage (s. Kap. 24). Depalettierte Einheiten können vom Roboter in ein Regal eingelagert werden, das von der anderen Seite von einem AKL bedient werden kann. Weiterhin befindet sich in der Roboterzelle ein Kommissioniertisch, der als temporäre Ablage für zu entleerende bzw. zu befüllende VDA-Behälter und als Blocklager für die aus den Behältern entnommenen Artikel bzw. Kartons dient.

326

W. Schaaf und R. Chisu

Abb. 28.4   Pilotzelle für das Szenario Depalettierroboter

Dabei werden sowohl die Paletten als auch die darauf befindlichen VDA-KLTs bzw. Kartons mit RFID-Transpondern ausgestattet, die neben einer eindeutigen ID auch Informationen über den Typ der Transporteinheit, deren Inhalt und deren Ziel enthalten. Diese Daten werden vor bzw. während des Depalettiervorgangs gelesen und bilden so die Grundlage für die Auswahl einer Greiferkonfiguration bzw. für die Bestimmung des Zielorts. Auslager- und Palettiervorgänge können über eine graphische Oberfläche von einem Bediener eingegeben werden, wobei externe Vorgaben durch beispielsweise ein Lagerverwaltungssystem ebenfalls denkbar sind.

28.7  Greifer Den für das Szenario Depalettierroboter gemäß den Anforderungen und der Konzeption realisierten Greifer zeigt Abb. 28.5. Ein horizontal angeordnetes und in zRichtung höhenverstellbares Vakuum-Modul trägt für das Ansaugen von Objekten eine große Saugplatte mit Faltenbalgsauggreifern sowie eine an der gegenüberliegenden Seite angebrachte kleine schwenkbare Saugplatte zur Entnahme von kleinen Kartons aus VDA-Behältern. Zum seitlichen Klemmen von Objekten dienen zwei in x- und y-Richtung verschiebliche Holme. Mit diesen Holmen kann auch ein formschlüssiger Untergriff bei von oben mittels der großen Saugplatte angesaug-

28  Hochflexible, RFID-gesteuerte Handhabung von Stückgut

327

Abb. 28.5   Für das Szenario Depalettierroboter entwickelter Greifer

ten Objekten realisiert werden. Leere Paletten werden dadurch gegriffen, dass die Holme unter den Palettenstegen eingeführt werden und nach Anheben des Greifers darauf aufliegen. Zum Greifen von VDA-Behältern werden die Holme in die seitlichen Schienen des Behälters in x-Richtung eingefahren, während der Behälter von vorne mit einem Sauggreifer festgehalten wird um ein Verschieben nach hinten zu verhindern. Die Vakuumerzeugung für die Sauggreifer der großen Platte erfolgt durch leistungsstarke Mehrstufenejektoren mit hohem Saugvolumenstrom, um die Luftdurchlässigkeit der Kartons auszugleichen. Der einzelne Sauggreifer zum Festhalten der VDA-Behälter wird mit einem Inline-Ejektor betrieben. Der zum Ansaugen erforderliche Unterdruck wird durch Vakuumsensoren überwacht. Die gesamte Steuerungskonfiguration inklusive Pneumatik und Elektrik ist in Abb. 28.6 skizziert. Die Antriebe für das höhenverstellbare Vakuum-Modul und die ausfahrbaren Holme sind geregelte Servomotoren, mit denen Positionen genau angefahren werden können. Zusätzlich werden die End-Positionen durch Endschalter überwacht. Die Frequenzumrichter und die Greifersteuerung mit Eingangs- und Ausgangsmodulen befindet sich in einem separaten Gehäuse, welches auf dem Roboterarm angebracht ist. Auf der Greifersteuerung läuft ein Web-Server, der alle relevanten Prozess- und Steuerungsparameter nach außen bereitstellen kann. So zeigt Abb. 28.7 die realisierte Prozessüberwachung mit Angaben zu den Objektabmessungen, Vakuumwerten sowie der Möglichkeit einzelne Vakuum-Module anzusteuern.

328

W. Schaaf und R. Chisu

SEM Druckluftverteiler auf Roboterarm

Phoenix ILC 330 ETH auf Roboterarm

M

FU Z FU Y FU XM FU XS

ES se SE ES se M VS M

M

ES x

Y

Z

Interbus

ES y

X ES x VS

ES z LT SLP

LT

V

V

V

V

Robotersteuerung z

V

SEM

SEM

x

y Aktoren: M ... Servomotor SE ... Schwenkeinheit V ... Ventil

Sensoren: LT ... Lichtschranke VS ... Vakuumsensor ES ... Endschalter

Vakuumerzeuger: SEM ... Mehrstufenejektor SLP ... Inline-Ejektor

elektrisch pneumatisch Busleitung Vakuumanschluss

Abb. 28.6   Steuerungskonfiguration des realisierten Greifers

28.8  RFID-System Für die Kennzeichnung der Paletten, Kartons und VDA-Behälter werden durchgängig UHF-RFID-Chips eingesetzt. Die eingesetzten Tags besitzen eine Kapazität von 96 Bit bzw. 12 Byte und sind auf die Speicherung eines Elektronischen Produktcodes (EPC) ausgelegt. Bei der Festlegung eines Schemas für die Belegung bzw. Bedeutung der einzelnen Bits wurde auf die EPC-NVE-96 Norm zurück gegriffen. Diese steht für Nummer der Versandeinheit (bzw. Serial Shipping Container Code, EPC-SSCC-96) und erlaubt die weltweit eindeutige Identifikation einer logistischen Einheit anhand einer unternehmensspezifischen „Basisnummer“ und einer ladeeinheitsspezifischen „Seriennummer“ (s. Abb. 28.8). Dabei bleiben 24 der insgesamt zur Verfügung stehenden 96 Bit ungenutzt, wobei eine Standardkonformität nur dann gegeben ist, wenn dieser Bereich frei bleibt. Da aber zumindest derzeit keine Standards verfügbar sind, die eine Codierung von Informationen für die Steuerung von Materialflüssen oder Produktions- und Handhabungsprozessen vorsehen, wurden im vorliegenden Szenario diese 3 Byte zur

Achssteuerung

150

395

165

590

144

280

130

230

Höhe:

Prozessüberwachung

800

390

590

1200

Breite:

Länge:

Abmessungen [mm] No Messa

Zu niedrig

Grenzberalch

Optimal

Vakuumüberwachung Große Platte

No Messa mbar

Einzelzauger

mbar

No Messa mbar Kleine Platte

Ein- / Ausgänge

Abb. 28.7   Webbasierte Prozessüberwachung für den Greifer

Startseite

Handhabungsobjekt

Große Platte

Vakuumanzeige

Prozessüberwachung

1.

Saugerplatte Klein runter

Vakuum Gr. Platte

Vakuum Kl. Platte

Vakuum Einzelsauger

Bedienelemente

1.

28  Hochflexible, RFID-gesteuerte Handhabung von Stückgut 329

330

W. Schaaf und R. Chisu

EPC-NVE-96

Länge (Bit)

Header

Filter

Partition

Basisnr.

Seriennr.

Unbesetzt

8

3

3

20-40

38-18

24

96

Abb. 28.8   EPC-NVE-96

Speicherung der für das Internet der Dinge relevanten Daten benutzt. Damit ist zwar keine strikte Einhaltung der EPC-NVE-96 Vorgaben gegeben, trotzdem wird damit gezeigt, dass bereits im Rahmen der recht kleinen Kapazität von 12 Byte eine Speicherung sowohl einer eindeutigen Unternehmens- und Transporteinheitsnummer als auch von Internet-der-Dinge-Daten möglich ist. Die Belegung der besagten 24 Bit wird in Abb. 28.9 dargestellt. Dabei werden das Transportziel und der Inhalt einer Transporteinheit über folgende fünf Felder beschrieben: • Zielbereich (4 Bit) gibt den Bereich einer Anlage an, z. B. Hochregallager, Zwischenlager, Produktion oder Warenausgang. Die 4 Bit erlauben somit die Differenzierung zwischen 16 verschiedenen Bereichen. In der Demonstrationsanlage wurden drei Bereiche definiert: HRL, EHB-Bereich, Warenausgang. • Zielmodul (8 Bit) bezieht sich auf ein bestimmtes Fördertechnikmodul oder auch eine Fertigungsmaschine innerhalb eines Bereiches. Im vorliegenden Fall wurde über das Feld Zielmodul ein Streckenstück oder ein Kranfeld im Elektrohängebahnbereich angegeben. • Zielort (4 Bit) benennt einen bestimmten Punkt, der zum gewählten Zielmodul gehört, beispielsweise ein Lastübergabe- oder ein Kommissionierplatz. • Inhalt Anzahl (6 Bit) beschreibt die Anzahl an Transporteinheiten, die sich in bzw. auf der aktuellen Ladeeinheit bzw. Ladehilfsmittel befinden. Die 6 Bit beschreiben somit, wie viele Kartons oder VDA-KLTs auf einer Palette oder wie viele Kartons in einem VDA-KLT liegen. • Inhalt (2 Bit) gibt an, ob die aktuelle Transporteinheit beispielweise mit Kartons, VDA-KLTs oder beidem bestückt ist.

Länge (Bit)

Header

Filter

Partition

Basisnr.

Seriennr.

Internet der Dinge

8

3

3

20-40

38-18

24

Länge (Bit)

96

Zielbereich

Zielmodul

Zielort

Inhalt Anz.

Inhalt

4

8

4

6

2

Abb. 28.9   Auf EPC-NVE-96 basierendes Datenformat für das Internet der Dinge

28  Hochflexible, RFID-gesteuerte Handhabung von Stückgut

331

28.9  Erprobung des Szenarios Die Steuerungsarchitektur des Demonstrators sowie die zwischen den einzelnen Komponenten ausgetauschten Daten werden in Abb. 28.10 dargestellt. Das RFID-gesteuerte Depalettieren wurde anhand des folgenden Ablaufs ge­ testet: • Eine Palette wird von einem Stapler auf die Schwerlastrollenbahn gelegt und in die Roboterzelle gefördert. Dabei wird der RFID-Transponder der Palette von einem unter der Rollenbahn angebrachten Reader gelesen und einem Softwareprogramm zur Verfügung gestellt, das die Auftrags- und Lagerverwaltung der Roboterzelle übernimmt. Aus den Datenfeldern „Inhalt“ und „Inhalt Anzahl“ wird das Palettiermuster berechnet, wobei wegen der niedrigen Speicherkapazität der Tags folgende Einschränkungen bestehen: − Auf der Palette müssen sich vier Stapel gleicher Höhe befinden, „Inhalt Anzahl“ enthält somit einen Wert der Form 4k. − Auf der Palette dürfen sich entweder vier Stapel Kartons oder VDA-Kleinladungsträger oder zwei Stapel VDA-KLTs (in Förderrichtung vorne) und zwei Stapel Kartons (in Förderrichtung hinten) befinden. Diese Einschränkungen können in einem realen Einsatzfall umgangen werden, indem entweder RFID-Tags mit größerer Kapazität eingesetzt werden oder ein Softwareagent für die Palette programmiert wird, der detaillierte Informationen zum Palettiermuster bereit stellt. • Es werden automatisch so viele Depalettieraufträge generiert, wie auf der Palette Behälter bzw. Kartons vorhanden sind. Diese Aufträge werden von der Zellensteuerung dann einzeln an die Robotersteuerung übermittelt. • Der Roboter setzt bei jedem Depalettierauftrag als Erstes die für VDA-KLTs bzw. Kartons korrekte Greiferkonfiguration. Dies geschieht durch das Übermitteln der X-, Y- und Z-Sollwerte an die Greifersteuerung. • Danach wird die aus dem Palettiermuster, dem Index der nun zu greifenden Transporteinheit und deren Höhe die Position der Ladeeinheit berechnet und angefahren. Die Feinpositionierung geschieht anschließend über zwei am Greifer angebrachte Lichttaster. • Die Ladeeinheit wird mit der dafür vorgesehenen Greiferkonfiguration aufgenommen und in das Lesefeld eines zweiten RFID-Readers geführt. • Die Zellensteuerung wertet diese Daten nun aus und generiert einen Folgeauftrag, der wiederum an die Roboterzelle übermittelt wird. Dabei werden Kartons immer eingelagert. Bei VDA-KLTs wird zum einen das Feld „Inhalt Anzahl“ ausgewertet. Dieses gibt an, ob sich im Behälter weitere, zu entnehmende Kartons befinden. Ist dies der Fall, wird der Behälter auf einen Kommissioniertisch gelegt, die Kartons aus dem Behälter gegriffen und der leere KLT anschließend eingelagert. Ist der Behälter von vorne herein leer, oder ist er nicht mit Kartons befüllt, findet eine Unterscheidung des Zielbereichs statt – KLTs mit Ziel „HRL“ werden eingelagert, KLTs mit Ziel „EHB-Bereich“ werden auf einen Kleinteile-

EPC

• Auftragstyp • TE-Nr. • Fach-Nr. • Quittierungen

EPC

• Positionsberechnung • Bewegungsabläufe • Vorgabe Greiferkonfiguration

Robotersteuerung

• Europalette / Karton / VDA-KLT • RFID, 96 Bit

Transporteinheit

Abb. 28.10   Steuerung und Kommunikation des Demonstrators

• Auftragsverwaltung • Lagerfachverwaltung • GUI • Schnittstelle zu LVS

Zellensteuerung

• UHF • Lesen der Transponder

RFID-Reader

• Greiferkonfig. • Lichttaster • Vakuum-Status

• Greiferkonfiguration • Vakuumüberwachung • Webserver

Greifersteuerung

332 W. Schaaf und R. Chisu

28  Hochflexible, RFID-gesteuerte Handhabung von Stückgut

333

förderer gelegt. Behälter und Kartons, deren RFID-Chip nicht gelesen werden konnte bzw. fehlerhafte Daten enthält, werden ebenfalls eingelagert und eine entsprechende Fehlermeldung für den Bediener ausgegeben. • Wurden alle Ladeeinheiten von der Palette entfernt, generiert die Zellensteuerung einen Auftrag zum Entfernen der Leerpalette von der Schwerlastrollenbahn. • Auslager- und Kommissionieraufträge müssen von einem Bediener über die GUI der Zellensteuerung eingegeben werden, wobei eine Schnittstelle zu einem externen System, z. B. einem Lagerverwaltungsrechner, ebenfalls denkbar ist. Dabei ist es möglich, Kartons und VDA-Behälter aus dem Regal zu entnehmen und auch Kartons in einen leeren VDA-Behälter zu kommissionieren. Ladeeinheiten werden dann auf eine Palette auf der zweiten Schwerlastrollenbahn oder auch auf den zum EHB-Bereich führenden Kleinteileförderer gelegt. Zum Test des entwickelten Greifers sowie der Depalettierungssteuerung mit RFID wurden mehrere Hundert Palettier- und Depalettieraufträge durchgeführt. Der dabei einzige fehleranfällige Prozess ist das Kommissionieren von Kartons aus bzw. in Behälter. Für diese Aufgabe wäre ein Kamerasystem mit Bildverarbeitung notwendig, das die genaue Position der Ladeeinheiten innerhalb des KLTs bestimmen und dem Roboter zur Verfügung stellen kann. Bei der Handhabung anderer TE sind keine Fehler aufgetreten.

28.10  Folgerungen und Erkenntnisse Die Realisierung und Erprobung hat gezeigt, dass das Paradigma „Internet der Dinge“ auf das Szenario Depalettierroboter angewendet werden kann. Die hierzu entwickelten Konzepte und Verfahren sind dazu geeignet, einen RFID-gesteuerten Materialfluss umzusetzen. Das erstmals vorgeschlagene Verfahren zur Definition von Greifkonfigurationen ist für eine systematische Auslegung von Lastaufnahmemitteln bzw. Greifern gut geeignet und bezüglich Greifprinzipien und Objektgeometrien erweiterbar. Das definierte Konzept für die Speicherung von Ziel- und Inhaltsinformationen auf passiven RFID-Transpondern zeigt, dass bereits günstige und standardisierte Tags mit einem Speicher von nur 12 Byte genügen, um Materialfluss- und auch Kommissionierprozesse dezentral zu steuern.

Teil V

Internet der Dinge Eine Vision wird Wirklichkeit

Kapitel 29

Fazit

Willibald A. Günthner

Für den heutigen Verbraucher sind eine riesige Auswahl an Konsumgütern bis hin zum individualisierten, selbst gestalteten Produkt, minimale Lieferzeiten und günstige Preise zu einer Selbstverständlichkeit geworden. Aber um diesen Anforderungen gerecht zu werden, müssen Produktion und Logistik hinter den Kulissen des Einzel- und Onlinehandels immer komplexere Aufgaben erfüllen und sich an ständig neue und nicht planbare Situationen anpassen: Das von Trends und Hypes bestimmte Kundenverhalten macht Absatzmärkte fast unprognostizierbar, die globale Vernetzung von Unternehmen verringert die Transparenz von Beschaffungsmärkten und Lieferketten. Systeme und ganze Unternehmen müssen sich in ihrer Organisation und den technischen Prozessen schnell an neue Umweltbedingungen anpassen, um so auf Marktveränderungen reagieren zu können und mit den Kundenwünschen Schritt zu halten. Somit sind Flexibilität und Wandelbarkeit zwei der Schlüsselkriterien für den heutigen Erfolg. Besonders gefordert ist hierbei die Logistik – denn diese sorgt dafür, dass Güter und Informationen zur richtigen Zeit am richtigen Ort verfügbar sind und macht dadurch eine effiziente Durchführung von Fertigungsoder Distributionsprozessen erst möglich. Heutige Materialflusssysteme sind aber weit davon entfernt, die stetig wachsenden Anforderungen an Wandelbarkeit und Dynamik zu erfüllen. Dies liegt weniger an der verfügbaren Technik, sondern viel mehr am eigentlichen Lösungsansatz. Herkömmliche Steuerungsarchitekturen beruhen auf dem Gedanken der genauen Planbarkeit, der deterministischen Abarbeitung und der zentralen Steuerung fester, im Voraus bekannter Prozesse. Diese Sichtweise hatte in den Zeiten der marktorientierten Serien- und Massenfertigung durchaus ihre Berechtigung – mit dem digitalen Zeitalter ist diese aber endgültig überholt. Nach klassischen Modellen erstellte Anlagen können meist nur mit sehr großem Aufwand an neue und unvorhergesehene Aufgabenstellungen angepasst werden, denn sowohl die stark projektspezifisch gestaltete Steuerungslogik als auch deren kaum beherrschbare Komplexität stellen technologische Hindernisse dar, deren Überwindung viel Zeit und Geld erfordert. W. A. Günthner () Lehrstuhl für Fördertechnik Materialfluss Logistik fml, Technische Universität München Boltzmannstr. 15, 85748 Garching, Deutschland e-mail: [email protected] W. Günthner, M. ten Hompel (Hrsg.), Internet der Dinge in der Intralogistik, DOI 10.1007/978-3-642-04896-8_29, © Springer-Verlag Berlin Heidelberg 2010

337

338

W. A. Günthner

Um heutigen und zukünftigen Anforderungen auf der Ebene der technischen Logistik begegnen zu können, sind daher ein radikales Umdenken und eine neue Herangehensweise notwendig. Dabei ist es hilfreich, sich zuerst einmal die treibende Kraft der neuen Märkte bzw. die Ursache des heutigen Kundenverhaltens vor Augen zu führen. Diese lässt sich in den durch das Internet bzw. das World Wide Web geschaffenen Möglichkeiten finden: Umfangreiche Informationen lassen sich immer und überall abrufen, Internetnutzer können uneingeschränkt miteinander kommunizieren, neue und auch mobile Geräte können jederzeit angeschlossen oder vom Netz getrennt werden. Dabei ist das Internet von Grund auf dezentral aufgebaut. Netzwerkrouter und Switches werden über Datenleitungen miteinander verbunden und koordinieren sich selbständig in ihrem Verhalten. Datenpakete werden je nach Auslastung und Verfügbarkeit von Routen dynamisch an ihr Ziel transportiert, bei der Datenübertragung auftretende Fehler werden automatisch erkannt und soweit möglich behoben. Die dabei eingesetzten Steuerungs- und Routingverfahren sind im Allgemeinen sehr einfach und schon seit Jahrzehnten bekannt. Diese mussten – trotz einer stetig wachsenden Anzahl an Internetnutzern und immer neuen Anwendungen – kaum geändert werden. Der Erfolg des Internets beruht also auf seiner Einfachheit: Autonome Einheiten mit klar abgegrenzten Entscheidungskompetenzen und Funktionen können beliebig miteinander vernetzt werden und erkennen dabei selbständig, welche Routen optimal sind. Eine zentrale Steuerung ist dabei weder für die Konfiguration der Internettopologie, noch für die Steuerung und Optimierung der Datenübertragung notwendig. Dieser Ansatz muss nun auch für die Logistik nutzbar gemacht werden, denn ein dezentrales und wandelbares Materialflusssystem bietet wirtschaftliche und technische Vorteile, die nicht nur erstrebenswert, sondern heutzutage sogar notwendig sind. Denn spontane Vernetzung, hohe Dynamik und ein höchstmögliches Maß an Flexibilität bilden die Basis für die geänderten Wünsche und die Anforderungen der heutigen Kunden und müssen daher auch in die technischen Systeme integriert werden, die zur Erfüllung dieser Wünsche notwendig sind. Das Internet der Dinge beschreibt dabei nicht nur eine technologische Weiterentwicklung der Materialflusssteuerung, sondern eine komplett neue und zukunftsorientierte Denkweise in der Intralogistik: Zentrale Steuerungsinstanzen werden von einem Netzwerk aus autonom agierenden, frei kombinierbaren logistischen Modulen abgelöst. Diese Vision von einem Internet der realen Welt, das nicht nur Datenpakete und Emails, sondern echte Behälter und Paletten befördert, vermag sofort zu begeistern und stellt schon rein intuitiv die richtige Richtung dar. Unser täglicher Umgang mit dem WWW hat uns gezeigt, wie einfach das Versenden und Empfangen von Nachrichten ist – Programmierer, Inbetriebnehmer und Betreiber von Materialflusssystemen hingegen wissen, wie schwierig sich die Steuerung und vor allem Modifikation intralogistischer Anlagen gestaltet. Obwohl dieser und ähnliche Ansätze schon seit mehreren Jahren in der Forschungslandschaft untersucht werden, haben sich dezentral gesteuerte Materialflusssysteme in der Industrie bisher nicht recht durchsetzen können. Zu groß waren die Fragezeichen nach der tatsächlichen technischen Realisierbarkeit eines solchen Systems, zu Ungewiss der technologische und vor Allem wirtschaftliche Nutzen eines solchen Paradigmenwechsels.

29    Fazit

339

Die Industrie- und Forschungspartner im vom BMBF geförderten Forschungsprojekt „Internet der Dinge“ haben sich vor diesem Hintergrund das hohe Ziel gesetzt, die Vision zur Wirklichkeit zu machen. Die in diesem Buch zusammengefassten Entwicklungsergebnisse zeigen zum einen die technologischen Grundlagen für einen Materialfluss nach dem Vorbild des Internets auf. Dabei wird auf erprobte Standards und Modellierungsmethoden aus der Informatik aufgebaut, um eine an die Anforderungen der Intralogistik angepasste Softwarearchitektur und die notwendigen Algorithmen und Protokolle zu spezifizieren. Zum anderen werden aber auch die Veränderungen analysiert, die die neue Technologie mit sich bringt. Eine detaillierte Betrachtung der einzelnen Phasen im Lebenszyklus einer Materialflussanlage liefert einen guten Überblick der Stärken oder auch Schwächen des Internets der Dinge in Bezug auf die konkreten Aufgaben der Planung, Realisierung, Inbetriebnahme und während des Betriebs. Eine detaillierte Beschreibung unterschiedlicher Einsatzszenarien für das Internet der Dinge – von Gepäckförderanlagen über Kommissionierlager und bis zu Staplerleitsystemen – zeigt anhand bereits realisierter Demonstratoren und Pilotanlagen den praktischen Einsatz dieser neuen Steuerungsarchitektur und auch die sich dabei ergebenden Herausforderungen auf. Diese ganzheitliche Betrachtungsweise, die sowohl die Technologie als auch ihre Folgen wie auch praktische Erfahrungsberichte zusammenfasst, ist es, die die vorgestellten Arbeiten zu einer essenziellen Grundlage für weitere Forschungsarbeiten und auch erste industrielle Internet-der-Dinge-Anlagen macht. Zwar ist vor allem im Bereich der Schnittstellen- und Kommunikationsstandards noch einiges an Entwicklungsarbeit zu leisten, trotzdem lässt sich jetzt schon sagen, dass das Internet der Dinge in naher Zukunft zur Realität werden und sowohl den Anbietern als auch Betreibern automatisierter Materialflusssysteme zahlreiche Vorteile bieten wird. Damit wird auch ein erheblicher Beitrag zur Wahrung der Technologieführerschaft und damit der Wettbewerbsvorteile Deutschlands in der Branche der Intralogistik geleistet.

Sachverzeichnis

A Agent anthropomorpher, 70 autonomer, 69 Identification (AID), 307 Lokalisierung, 122 Management Reference Model, 98 Management System (AMS), 98 nutzenbasierter, 68 rationaler, 70 reaktiver, 69 situated, 69 sozialer, 69 Umwelt Determiniertheit, 70 Diskretheit, 71 Dynamik, 71 Episodenhaftigkeit, 71 Zugänglichkeit, 70 zielbasierter, 68 Agent-on-tag, 117 Agentenbaukasten projektunabhängige Implementierung, 162 Agentenebene, 143 Agentenidentifikator (AID), 98 Agentenorientierte Software-Entwicklung (AOSE), 35, 37 Agentenplattform, 269, 319 Agentensystem Grundlagen, 65 Zustandsraum, 123 Agentifizierungs-Potentialanalyse, 238, 240, 241, 253 Agentkommunikation Aktion, 81 Konzept, 81 Prädikat, 81 Aggregation, 194 Airport Management System (AMS), 284

Anlageninstillation, 292 Anlagenlayout, intralogistisches, 19 Anlagenmechanik, 251 Anlagenphysik, simulierte 161 Anlagentopologie, 124, 141, 269 GUI-basierte Definition, 143 Anlagenverhalten, 21 Arbeitsstation, 60, 120 Architektur, serviceorientierte (SOA), 6 aSLS, s. Staplerleitsystem Atomisierung der Standardprozesse, 5 der Warensendung, 3 Auftragsmanager, 90, 91, 318 Dienst, 88 Auftragsverwaltung, 269 AutoID-System, 6 Automation Designer, 282 AutomationML, 31 Automatisierung Cluster, 12 Software-Methoden, 29 verteilte, nach IEC 61499, 32 Automatisierungsarchitektur, 292 Automatisierungskonzept, Evaluierung, 185 Automatisierungspyramide, 20, 21, 178, 226, 250, 254 Automatisierungssystem, dezentrales, 180, 251 Automatisierungstechnik, Entwicklung, 23 B Bag-Tag, 279 Baggage Handling System (BHS), 276, 277 Barcode, 55, 234 Basisfunktionsbaustein, 32 Basisontologie, 83 Baukasten für Entitäten, 188 Baukastensystem, 53 353

354 Behälterfördersystem, 277 Berechnungsgrenze, 5 Betriebskosten, 232 Bewertungsprozess, 136 Black Box, 54, 252 Blackboard, 74, 121, 210, 267, 268, 271 Braess-Paradoxon, 133 C Callback-Verfahren, 74 Comos, 282 Congestion cost, s. Stauungskosten Controller, 204, 222 integrierter, 242 Programmierung, 245 ConvLoc-Agent, 303, 304, 306 CORBA-Infrastruktur, 99 Customizing, 209, 210 D Data-on-network, 45 Data-on-tag, 117 Data-on-Chip-Prinzip, 45 Datenaustauschplattform, 267 Datenbank, 161 Datenverfügbarkeit, 234 Depalettierroboter, 330, 333, 336, 343 Determinismus, 250 Diagnose-Schalter, 225, 253 Dienste, 33, 37, 75, 103 softwaretechnischer, 212 Webservice-basierte, 225 Dienstleistung, logistische, 3 Directory Facilitator (DF), 98, 269, 271, 273, 307 Dokumentation, 215 Dynamic Source Routing, 159 E Early Baggage Store, 278 Echtzeit-Logistiksystem, 180, 313 Echtzeitfähigkeit der Steuerung, 49 Echtzeitsteuerung, Modulagent, 103 Echtzeitverhalten, 47 Komponentenebene, 48 Systemebene, 48 Einheit, mechatronische, 53 Einträgerkran, 264 Elektrohängebahnanlage, 263 Elektronischer Produktcode (EPC), 83, 338 Embedded Controller, netzwerkfähiger, 309 PC, 45, 112, 113, 266

Sachverzeichnis Emulation, 149, 154, 225, 252, 275 im Betrieb, 166 in den Lebenszyklusphasen, 162 Maschinensteuerung, 193 Emulationsbaukasten, agentenbasierter, 161 Engineering Bedienbarkeit, 253 Betriebsphase, 253 dezentraler Anlagen, 282 Kompetenz, vertikale, 255 Migrationskonzept, 291 projektspezifisches, 252 Enterprise Resource Planning (ERP), 16, 19, 30 Entfernungstabelle, 137, 138 Entität Basisinformation, 191 Baukasten, 189 mechatronische, 189, 212, 214 Mengengerüst, 193 Sicherheitsanalyse, 193 Entscheidung, informationslogistische, 5 Entscheidungsraum, 7 Entwicklungswerkzeug, 222 Ereignisliste, 157 Ereignisroutine, 157 Ethernet, 24, 26, 31, 112 Netzwerk, 242 Schnittstelle, 45, 109 F Fahrerloses Transportsystem (FTS), 68 Feldbussystem, 24, 31, 37, 109, 112, 204, 208 FIFO, 15 FIPA ACL-Nachrichten, 77 Interaktionsprotokoll, 88 Management Specification, 98 Referenzarchitektur, 100 Request-Protokoll, 88 Flexibilitätsangebot, 231 Flughafen Gepäckförderanlage, 275 Infrastruktur, 283 Fördergutflexibilität, 329 Fördertechnik, 56, 90, 284, 302 Agent, 285 Fördertechnikmodul, 176 Foundation for Intelligent Physical Agent (FIPA), 77 Funktion, logistische, 57

Sachverzeichnis Funktionsbaustein, 32, 37 zusammengesetzter, 33 Funktionsontologie, 84 G Gepäckförderanlage, 128, 134, 159, 250, 275, 286, 288, 290 dezentrale, 280 Gepäckstückidentifikation, 279 Gepäcktransport im dezentralen System, 283 Gesamt-Integrationstest, 220 Geschäftsprozesssteuerung, 17 Globalisierung, 9 Greifer, 329, 336 Greifkonfiguration, 332, 343 Greifparameter, 330 Greifprinzip, 330 Greiftechnik, 331 Gurtfördersystem, 276, 277, 284 H Hardware, 107, 238 High Level Architecture (HLA), 163 HMI Agent, 103 Schnittstelle, 199, 202 Hold Baggage Screening System (HBS), 278 Host-System, 30 Human-Machine Interface, 17 I Id-on-tag, 116 Identifikation, 13 von Fehlern, 146 Identifikationssystem, 116 Identifizierungstechnologie, 234 IdentProLog, 325, 326 Individualisierung, 3 Industrial Ethernet, 25 Industrie-PC (IPC), 100 Industrieroboter, 329 Information Hiding, 34 Informationsaustausch, direkter, 74 Inhouse-Test, 215 Intelligenz dezentrale, 331 verteilte künstliche, 35 Interface Definition Language (IDL), 99 Internet, 44 der Dienste, 7 der Dinge, 7, 43 abstraktes Architekturmodell, 100 Bausteine, 54 Emulation, 160

355 Manager, 210 Ontologie, 79 Projekt, 213 Simulation, 158 Interprozesskommunikation, 309 Intralogistik, 9, 10, 44, 329 Paradigmenwechsel, 46, 350 Investitionskosten, 231 IT-Infrastruktur, 315 J JADE, 284 K Kalkulation, interne, 202 Kernontologie, 83 Kleinladungsträger (KLT), 335 Kleinteilelager, automatisches, 298 Knowledge Sharing Effort (KSE), 79 Kommissionierbahnhof, 126 Kommissionierlager, 125 automatisches, 124, 296 dezentral gesteuertes, 295 funkgesteuertes, 296 manuelles, 296 Kommissionierprozess, 323 Kommissionierung automatische, 322 freie, 322 Kommunikation, 74 blackboardbasierte, 144 Modellierung, 93 Ontologie, 81 Protokoll, 80 Schichtenmodell, 76 zwischen den Systemkomponenten, 48 Kommunikationsablauf, 75 Kommunikationsakt, 78 Kommunikationsmodell, Ontologie, 87 Komponenten-Engineering, 251 Koordinierung der Zulieferer, 203 Kürzeste-Wege-Algorithmus, 159 L Label-Correction-Algorithmus, 132, 137, 138 Lastaufnahmemittel (LAM), 264, 266, 273, 301 Lastprognoseerstellung, 138 Lastwechselkoordination, 273 Layout, mechanisches, 193 Lebenszyklus, 173 Leistungsfähigkeit, logistische, 230 Leitrechner, 120 Leitsystemebene, 250

356 Lifecycle-Management, 7 Logistik, 3, 349 Unschärferelation, 5 Logistiksystem, 65 M Marktplatz, dynamischer, 102 Maschinensteuerungsebene, 105, 143 Materialflussanlage, steuerungslogisches Modell, 142 Materialflussrechner, 18, 239 Materialflusssimulation, 160 Werkzeuge, 156 Materialflusssteuerung, 15, 43 agentenbasierte, 97 Architekturmodelle, 96 Datenerfassung, 16 dezentral gesteuerte, 141 Echtzeitanforderungen, 47 Protokollierung, 17 verteilte, 141 Visualisierung, 16, 144 Materialflusssystem, 36, 43 Betrieb, 179, 229 Durchlaufzeit, 48 Durchsatz, 48 Erweiterung/Modernisierung, 179 Flexibilität, 231 Inbetriebnahme, 177, 217 Layout, 249 Lebenszyklus, 173, 197 Modernisierung, 237 Planungsphase, 174 Realisierungsphase, 175, 207 Simulation, 150 Steuerung, 65 Steuerungsarchitektur, 46 Umbau, 237 Mechanikbaukasten, 53 Mensch-Maschine-Schnittstelle, 103, 178 Message Passing, 75 Transport System (MTS), 98 Microcontroller, programmierbarer, 44 Middleware, 62, 64, 105, 142, 189, 210, 250, 266 Mobile Agent Facility Specification, 98 Mobiles Datenterminal (MDT), 314, 315, 322 Modellierungsprozess, 152 Modul, 56 Funktionsklasse, 58 Herstellung, 214 mechatronisches, 25, 249

Sachverzeichnis vorintegriertes, 280 wiederverwendbares, 223, 249 Modularisierung, 44, 53, 54, 266 Modularität, 13 Modulbaukasten, 53 Monitoring, 144, 145, 223 Montageplan, 216 Multiagentensystem, 222, 318 Referenzarchitektur, 97 Multiagentsteuerung, 90 Multiagentensystem, 6, 50, 54, 72 Kooperation zwischen den Agenten, 72 Ontologie, 81 N Nachrichtenaustausch, 50 Network-Time-Protocol (NTP), 147 Notaus-Konzept, 241 O Online-Simulation, 155 Ontologie, 80, 81 Beschreibung, 81 Validierung, 89 P Palettenagent, 90, 91 Peripherie, dezentrale, 23 Pflichtenheft, 208 Plug&Convey, 130 Plug&Play, 183, 254, 283 Problemlösungsprozess, 73 Problemlösungstechnik, 74 Produktcode, elektronischer, 83, 338 Produktionsplanung und Steuerung (PPS), 30 Produktionssystem, 237 Prognosezeitfenster, 137 Programmiersprache, 18, 109, 222 Programmierung, 211 Projekt Analyse, 199 Terminplanung, 204 Projektplanung, 197 Protokoll, 74, 75, 80 Protokollierungsfunktion, 225 Prototyp, 183 Prozessüberwachung, 331, 332 Q Querverteilwagen, 90 R Radio-Frequenz-Identifikation (RFID), 13, 26, 45, 62, 107, 113, 296, 316, 330

Sachverzeichnis Antenne, 116, 242 Chip, 208, 270, 280 Frequenzbereich, 114 Gate, 116 Reader, 267, 270 Tag, 121, 234, 279, 284, 301 Topologie, 121 Transponder, 55, 114, 117, 264 verfügbare Information, 121 Realtime, 237 Rechnerhardware, 19 Referenz-Modell-Methodik, 249 Referenzanlage, 217, 297 Umbau, 241 Referenzmodell-Methode, 183 Reflexagent einfacher, 66 modelbasierter, 66 Regalbediengerät (RBG), 297, 301 Reihenfolgesteuerung, 127 Reservierungsverfahren, 134 Ressourcenmanager, 318 Ressourcenoptimierung, 16 Retrofitting, 238, 253 RFID, s. Radio Frequenz Identifikation Richtungstabelle, 132, 138 Riemen-Ein-/Ausschleuser, 61, 64 Robotergreifer, s. Greifer Robustheit, 233 Routenfindungsagent, 71 Routing, 90 Routing-Dienst, 88, 91 Routinginformation, 285, 296 Routingstrategie, 122 Routingtabelle, 131, 290, 304 Routingverfahren, 130, 134, 287, 288, 289, 350 strategisches, 288 topologische Information, 130 S Sauggreifer, s. Greifer Schieflast, 287 Schnittstelle, grafische, 269 Schnittstellenagent, 101, 103 Serviceorientierte Architektur (SOA), 6 Sicherheitstechnik, 209 Signalsammler, 24 Simulation, 149, 183, 201, 207, 275 Ablauf, 152 als Werkzeug, 286 Anwendungsfehler, 150 Vor- und Nachteile, 153 Simulationsmodell, 155, 174 agentengesteuertes, 158

357 Simulationsstudie, 151 Simulationstool, 202 Simulationszeit, 157 Simulationszeitvariable, 157 Single Point of Failure, 113 SLS, s. Staplerleitsystem Sniffer, 147 SOAP, 35 Sockets, 161 Soft-SPS, 112, 113 Software Agent, 35, 64, 100, 105 selbstlernender, 156 Anforderungen, 31 Architektur, 95, 111, 317 Entwicklung, 29 agentenorientierte, 35 in der Automatisierung, 30 Technologie, 12 Softwareagentenplattform, 97 Softwaredienst, 56 Speicherprogrammierbare Steuerung (SPS), 15, 17, 30, 37, 96, 104, 107, 111, 242 Sprechakttheorie, 75, 80 Sprechakttyp, 76 SQL Befehl, 267 Datenbank, 268 Standarddurchlaufzeit, 136 Standardisierung, 13 Stapler, 90, 319 Staplerleitsystem, agentenbasiertes, 313, 316 Statistik, 147 Stetigförderer, 59, 240 Stetigfördertechnik, 241 Steuerprogramm, maschinennahes, 201 Steuerung agentenbasierte, 302 der Auftragsreihenfolge, 306 dezentrale, 50, 119 Echtzeitfähigkeit, 49 Hardware, 107 Integration, 309 Steuerungsagent, Modellierung, 101 Steuerungsalgorithmus, 32, 95 robuster, 233 Steuerungsarchitektur, 266, 341 dezentrale, 96 Steuerungshardware, 111 Anforderungen, 108 Steuerungspyramide, 43 Steuerungssoftware, 29 Verteilung, 142

358 Steuerungstechnik, 203, 238 Baukastenmodell, 45 Steuerungstechnologie, 12 Steuerungsverfahren, 350 Strafkosten, lastabhängige, 134 Supply Chain Management System, 3, 4, 15 Switch, 350 Synchronisationsmechanismus, 251 Systemarchitektur für die Intralogistik, 96 Systemontologie, 79 Systemschnittstelle, 319 Systemüberwachung, 144 Systemvisualisierung, 144 Systemzustand, statistische Auswertung, 147 T TCP/IP, 26 Teil-Integrationstest, 220, 239 Telegrammkommunikation, 164 Tooling, 222, 252 Topologieinformation, 131 Total Cost of Ownership (TCO), 278 Tracing-Dienst, 102 Tracking-Dienst, 102 Transponder, 114 Transport automatischer, 321 freier, 321 Ressource, 321 Transporteinheit (TE), 55, 57, 102, 122, 315, 319 Transportgut, 286, 287 Agent, 284 Auftrag, 285 Routenauswahl, 137 Transportmodul, 91 Transportnetzwerk, 43 Transportontologie, 85 Transportsystem fahrerloses (FTS), 68 intralogistisches, 16 platzbezogenes, 18 U UHF, 115 Umbauprojekt, Dokumentation, 245 Unstetigförderer, 60, 145

Sachverzeichnis V Verkehrsforschung, 133 Verzeichnis, 90 Verzweigung, 59 Visualisierung, 16, 213 regelbasierte, 144 Visualisierungsstation, 144, 201 Visualisierungsumgebung, 268 W Wandelbarkeit, 330 Warehouse Management System (WMS), 30, 314 Warenwirtschaftssystem, 18, 237 Web Service, 35, 37 Weglängenbestimmung, 136 Weichen-Agent, 123 Wettbewerbsdruck, 10 Wiki-System, 247 WLAN, 25, 26, 266 Workflow, 34, 57, 142, 189, 200, 207, 291 Ontologie, 85 X XML Dialekt, 75 Format, 142 Konfigurationsdatei, 266 Nachricht, 270 Z Zeit-Antwort-Verhalten, 314 ZigBee, 26

Zusammenarbeit, gewerkeübergreifende, 254 Zusammenführungsagent, 123 Zusammenführungsstelle, 59 Zustandsvisualisierung, 331 Zustandvariable, 157 Zweiträgerkran, 264