System zur dezentralen Materialflusssteuerung

Die Erfindung betrifft ein Materialflusssystem zur Beförderung von Transportgutern, umfassend Komponenten zur Durchfuh ^¬ rung einer Transportaufgabe. Weiterhin betrifft die Erfindung eine Komponente eines Materialflusssystems zur Beförderung von Gutern.

Materialflusssysteme sollen möglichst den optimalen Durchsatz für die zu befordernden Transportguter erreichen. Dazu müssen Materialflussentscheidungen, wie z.B. die Stellungen von Weichen, oder ob neue Transportguter eingelastet werden, so ge- troffen werden, dass es nicht zu Schieflasten oder Staus kommt. Dazu kann der aktuelle Belegungszustand der Anlage sowie, falls vorhanden, Informationen über die geplanten einzulastenden Transportguter für eine Prognose verwendet werden, an welchen Bereichen der Anlage Staus etc. zu erwarten sind. Dann kann mit geeigneten Steuerungsstrategien dem entgegengewirkt werden.

In Systemen mit einem zentralen Materialflussrechner (MFR) verwaltet dieser den aktuellen Belegungszustand zentral und kann damit auch zentral eine Prognose über zukunftige Zustande berechnen. Bei Vorhandensein eines Plans über anstehende einzulastende Transportguter, können diese bei der Berechnung ebenfalls berücksichtigt werden. Die klassischen zentralen Materialflusssysteme verfugen über eine zentrale Instanz, den Materialflussrechner, welche wie oben ausgeführt alle notwendigen Informationen periodisch von den untergelagerten Steuerungen bekommt und so die zukunftige Belegung prognostizieren kann. In der US Patentanmeldung US2007/0078531A1 sind ein System und eine Methode zur dynamischen Simulation von Pro- zessflussen offenbart, wobei eine zentrale Simulationsmaschi ^¬ ne (Simulation Engine) verwendet wird. Zentrale Mateπal- flussrechner (MFR) stellen einen Flaschenhals dar, der die Performance und den Durchsatz des Materialflusssystems beein- trachtigen kann. Bei Ausfall des zentralen Mateπalflussrech- ners kann sich das gesamte Mateπalflusssystem nicht mehr an veränderte Lastbedingungen anpassen.

In der Literatur gibt es Ansätze für dezentrale Mateπal- flusssysteme . Dezentrale Materialflusssysteme können eine zentrale Instanz als Informationsdrehscheibe (z.B. passiv über ein elektronisches Blackboard, oder aktiv ahnlich einem klassischen MFR) einfuhren. Damit gehen aber die Vorteile des dezentralen Ansatzes (kein zentraler Flaschenhals für die

Performance, kein Single-Point-of-Failure, gemeinsame Grenzen von Mechatronik und Steuerung) wieder verloren. Weiterhin schlagen A. Fay und I. Fischer im Artikel „Dezentrale Automatisierungsstrategien für Gepackbeforderungssysteme" in at - Automatisierungstechnik 52 (2004) 7, Oldenbourg Verlag vor, für Mateπalflusssysteme Routing-Mechanismen des Internets zu verwenden. Die vorgeschlagenen dezentralen Ansätze sind aber unflexibel und nicht performant. Z.B. erfolgt keine Aktuali ^¬ sierung im Falle von Routenanderungen .

G. Follert und M. Roidl schlagen in "Evaluation of Routing Strategies for Decentralized Self-Organization in Large Scale Conveyor Systems. Progress in Material Handlmg Research: 2008. Material Handlmg Institute, 160-184, 2008" einen An- satz ohne zentrales Element vor. Dies geschieht durch Fluten der Anlage mit Nachrichten. Die entstehende Kommunikations- last ist dabei sehr groß, da für jede eingelastete Transport ^¬ einheit eine individuelle Bestimmung der Route durch Fluten des Kommunikationsnetzes der Anlage bestimmt wird.

Die Aufgabe der vorliegenden Erfindung ist es, eine Komponente für ein Mateπalflusssystem bereitzustellen, die eine sichere Prognose über die zukunftige Entwicklung des Belegungs- zustandes des Mateπalflusssystem ermöglicht, wobei die Kom ^¬ ponente auf Änderungen im Mateπalflusssystem flexibel und zeitnah reagiert, ohne dass dazu eine zentrale Instanz wie ein Mateπalflussrechner notwendig ist. Die Aufgabe wird mit einem Mateπalflusssystem Insbesondere zur Beförderung von Transportgutern, umfassend Komponenten zur Durchfuhrung einer Transportaufgabe gelost, wobei eine Komponente umfasst: a) ein Mechanikelement zur Forderung der Transportguter; b) eine Sensoπk zum Erfassen von Zustanden des Mecha- nikelementes und/oder des Transportgutes und/oder der Umgebung; c) eine Aktoπk zur mechanischen Beeinflussung des Me- chanikelementes und/oder des Transportgutes; d) eine Steuerungskomponente zur Ansteuerung des Mechanikelements und der Aktoπk, basierend auf den von der Senso- πk gelieferten Daten, auf aktuellen Anlagenzustandsdaten des Mateπalflusssystems und auf Steuerungsparameter der Steuerungskomponente; e) Schnittstellen zu Nachbarkomponenten und zur Umgebung; und f) einen Eigensimulator zur Bestimmung eines komponen- tenspezifischen zukunftigen Zustandes, wobei aus den jeweiligen komponentenspezifischen zukunftigen Zustanden eine Prognose für den zukunftigen Anlagenzustand des Mateπalflusssys ^¬ tems ermittelbar ist.

Dezentrale Materialflusssysteme verfugen nicht über einen zentralen Mateπalflussrechner (MFR) , sondern sind aus kooperierenden autonomen Komponenten bzw. Modulen aufgebaut, die jeweils sowohl Mechatronik als auch die zugehörige Steuerung enthalten und sich weitgehend automatisch konfigurieren können. Module eines solchen Systems sind z.B. Förderbänder, Weichen oder Zusammenfuhrungen. In üblichen dezentrale Mate- πalflusssystemen hat keine der Modulsteuerungen den Gesamtüberblick über das Materialflusssystem, und es können nicht ohne weiteres Prognosen über die zukunftige Entwicklung des Belegungszustandes des Mateπalflusssystems gemacht werden. Das erfmdungsgemaße Verfahren ermöglicht aber den Modulen, d.h. den Komponenten, gemeinsam eine verteilte Prognose über die zukunftige Entwicklung des Belegungszustandes der Gesamtanlage durchzufuhren, indem jedes Modul eine Simulation der eigenen zukunftigen Modulzustande mit einem dedizierten (d.h. jeder Komponente zugeordneten) Eigensimulator durchfuhrt. In jede Komponente des Mateπalflusssystems wird eine dezentrale Simulationskomponente integriert. Innerhalb jeder Komponente (Moduls) steht die vollständige Information zur Verfugung, um die künftige eigene Belegung zu simulieren, da die aktuelle Belegung und das eigene Verhalten bekannt sind. Darüber hinaus müssen zusätzlich Informationen über zukunftig zu befordernde Transporteinheiten von den Vorlaufermodulen mitgeteilt werden, und genauso an Nachfolgekomponenten weitergegeben werden. Der genaue Zuschnitt von Modulen in dezentralen Mate- πalflusssystemen ist eine Designentscheidung und nicht Gegenstand dieses Verfahrens. Für das Verfahren ist nur relevant, dass ein Modul (Komponente) eine Entitat ist, welche im dezentralen System als abgeschlossene Einheit betrachtet wird und selbst über die Information seines Verhaltens verfugt. Dadurch, dass kein zentraler Mateπalflussrechner vorhanden ist, wird die Zuverlässigkeit des Systems erhöht. Bei Ausfall einer dezentralen Steuerungskomponente erfolgt kein Totalaus- fall, da die Aufgaben der ausgefallenen Steuerungskomponente von einer Nachbarkomponente übernommen werden können.

Eine erste vorteilhafte Ausgestaltung der Erfindung liegt darin, dass der Eigensimulator basierend auf den aktuellen Anlagenzustandsdaten des Mateπalflusssystems und der Steuerungsparameter der Steuerungskomponente durch Simulation eine Prognose für den komponentenspezifischen zukunftigen Zustand bestimmt. Innerhalb jeder Komponente steht somit die voll- standige Information zur Verfugung, um die künftige eigene Belegung zu simulieren, da die aktuelle Anlagenbelegung und das eigene Verhalten bekannt sind.

Eine weitere vorteilhafte Ausgestaltung der Erfindung liegt darin, dass der Eigensimulator über die Schnittstellen auf Daten von Nachbarkomponenten zugreifen kann und diese Daten zur Simulation verwendet. Dadurch können Informationen über zukunftig zu befordernde Transporteinheiten von den Vorlauferkomponenten mitgeteilt werden, und genauso an Nachfolge- komponenten weitergegeben werden. Dies erhöht die Effektivität und die Genauigkeit der durch die Simulation erstellten Prognose (Belegung, zu erwartende Staus oder Schieflasten im System) .

Eine weitere vorteilhafte Ausgestaltung der Erfindung liegt in einem Steuerungsoptimierer, der basierend auf den durch den Eigensimulator prognostizierten komponentenspezifischen zukunftigen Zustandsdaten, die Steuerungsparameter entspre- chend optimiert. Der Steuerungsoptimierer passt auf Grundlage der prognostizierten zukunftigen Anlagenzustande die Steuerungsparameter entsprechend an. Dadurch werden aus den Ergebnissen der Prognose automatisch Steuerungsparameter abgeleitet.

Eine weitere vorteilhafte Ausgestaltung der Erfindung liegt darin, dass die Eigensimulatoren zyklisch synchron für alle Komponenten aktiviert werden. Die Simulation der Komponenten kann zyklisch synchron für alle Komponenten gleichzeitig an- gestoßen werden. Ein solcher Zyklus kann nach einem festen Zeitraster angestoßen werden, z.B. alle 30s zur vollen und zur halben Minute. Mittels eines geeigneten Protokolls muss sicher gestellt werden, dass alle Komponenten sich auf eine gemeinsame Zeit synchronisieren und den gleichen Zeitplan für die Zyklusstartzeiten verwenden. Ein Beispiel für ein solches Protokoll ist das Internet-Protokoll ntp. Zu Beginn des Zyklus initialisieren sich alle Eigensimulatoren mit den gerade in der Komponente befindlichen Transporteinheiten am aktuellen Aufenthaltsort. Ist die Eigensimulation abgeschlossen, so werden die Daten der gerade neu bestimmten Informationsbasis in der Anlage kommuniziert und ein Zyklus ist abgeschlossen. Es können mehrere Zyklen zusammengeschlossen werden, bevor die neu entstandene Informationsbasis an den Steuerungsoptimierer der Komponenten übergeben wird.

Eine weitere vorteilhafte Ausgestaltung der Erfindung liegt darin, dass die Eigensimulatoren asynchron aktiviert werden. Die Eigensimulatoren der Komponenten können auch asynchron aktiviert werden. Dadurch ist das Verfahren flexibel je nach Anwendungsfall und Materialflusssystem einsetzbar.

Eine weitere vorteilhafte Ausgestaltung der Erfindung liegt darin, dass durch die Eigensimulatoren Schieflasten oder

Stauungen im Materialflusssystem erkannt werden. Dadurch kann im Mateπalflusssystem ein optimaler Durchsatz für die zu befordernden Transportguter erreicht werden. Materialflussent- scheidungen, wie z.B. die Stellungen von Weichen, oder ob neue Transportguter eingelastet werden, können nun so getroffen werden, dass es nicht zu Schieflasten oder Staus kommt.

Eine weitere vorteilhafte Ausgestaltung der Erfindung liegt darin, dass durch den Steuerungsoptimierer Schieflasten oder Stauungen im Materialflusssystem vermieden werden. Dadurch können Materialflussentscheidungen, wie z.B. die Stellungen von Weichen, oder ob neue Transportguter eingelastet werden, automatisch und spezifisch getroffen werden, um Schieflasten oder Staus zu vermeiden.

Eine weitere vorteilhafte Ausgestaltung der Erfindung liegt darin, dass der Eigensimulator Zugriff auf einen Einlastplan des Materialflusssystems hat. Dadurch kann für jeden Einlast ^¬ plan eine zur aktuell vorliegenden Anlagenauslastung und An- lagenkonfiguration abgestimmte Prognose erstellt werden.

Die Aufgabe wird weiterhin gelost mit einer Komponente eines Materialflusssystems, umfassend: a) eine Mechatronik mit Forderelementen, Sensoren und Aktoren zum Transport der Guter; b) eine Steuerung zur Ansteuerung der Mechatronik, c) Schnittstellen zu Nachbarkomponenten und zur Umgebung, d) einen Eigensimulator zur Bestimmung des komponenten- spezifischen zukunftigen Zustandes, wobei der Eigensimulator mit Eigensimulatoren weiterer Komponenten des Materialflusssystems zusammenwirkt, zur Bestimmung des zukunftigen AnIa- genzustandes des Materialflusssystems. Eine Komponente bzw. ein Modul besteht aus der Mechanik der Fordertechnik, der Sensoπk und Aktoπk, der Steuerung, sowie Kommunikations- schnittstellen zu den benachbarten Modulen. Beispiele für Module sind Förderbänder, Weichen oder Zusammenfuhrungen. Kom- ponenten/Module, im Sinne der Erfindung, können auch komplexerer Art sein als die schon aufgeführten Beispiele. Z.B. kann eine Zusammenfuhrung einschließlich der zufuhrenden Förderbänder zu einem Modul zusammengefasst werden. Der genaue Zuschnitt von Modulen m dezentralen Materialflusssystemen ist eine Designentscheidung abhangig von z.B. infrastrukturellen oder anwendungsspezifischen Voraussetzungen (Require- ments) . Für das Verfahren ist nur relevant, dass ein Modul eine Entitat ist, welche im dezentralen System als abgeschlossene Einheit betrachtet wird und selbst über die Infor- mation seines Verhaltens verfugt. In jede Komponente/Modul des Materialflusssystems ist eine dezentrale Simulationskomponente integriert. Innerhalb jedes Moduls steht die voll- standige Information zur Verfugung, um die künftige eigene Belegung zu simulieren, da die aktuelle Belegung und das ei- gene Verhalten bekannt sind. Darüber hinaus müssen zusätzlich Informationen über zukunftig zu befordernde Transporteinheiten von den Vorlaufermodulen mitgeteilt werden, und genauso an Nachfolgemodule weitergegeben werden. Bei Ausfall einer dezentralen Simulationskomponente erfolgt kein Totalausfall, da die Aufgaben der ausgefallenen Simulationskomponente von einer Nachbarkomponente übernommen werden können.

Eine weitere vorteilhafte Ausgestaltung der Erfindung liegt darin, dass die Komponente einen Steuerungsoptimierer um- fasst, der basierend auf den durch den Eigensimulator prognostizierten komponentenspezifischen zukunftigen Zustandsda- ten, die Steuerungsparameter der Steuerung entsprechend an- passt. Dadurch können im Sinne eines Regelkreises automatisch dedizierte Materialflussentscheidungen, wie z.B. die Stellun- gen von Weichen, oder ob neue Transportguter eingelastet werden, automatisch und spezifisch getroffen werden, um optimale Belegungszustande zu erreichen. Eine weitere vorteilhafte Ausgestaltung der Erfindung liegt darin, dass der Steuerungsoptimierer Schieflasten oder Stau ^¬ ungen im Materialflusssystem vermeidet. Dadurch kann im Mate- πalflusssystem ein optimaler Durchsatz für die zu befordern- den Transportguter erreicht werden.

Eine weitere vorteilhafte Ausgestaltung der Erfindung liegt darin, dass der Eigensimulator einer Komponente auf Anlagen- zustandsdaten des Materialflusssystems und/oder auf Einlast- plandaten Zugriff hat. Dadurch kann für jeden Einlastplan eine zur aktuell vorliegenden Anlagenauslastung und Anlagenkon- figuration abgestimmte Prognose erstellt werden.

Eine weitere vorteilhafte Ausgestaltung der Erfindung liegt darin, dass sich die Komponente mit den Nachbarkomponenten über die Schnittstellen bekannt macht und entsprechend der Anzahl und Art der Nachbarkomponenten den Eigensimulator und den Steuerungsoptimierer automatisch konfiguriert. Dies ermöglicht die Selbstkonfiguration der dezentralen Steuerung. Zur Einstellung werden keine Einlastszenaπen benotigt (z.B. im Sinne einer Wissensdatenbank in der hinterlegt ist, wie bei den jeweiligen Einlastszenarien zu verfahren ist) .

Ein Ausfuhrungsbeispiel der Erfindung ist in der Zeichnung dargestellt und wird im Folgenden erläutert.

Dabei zeigen:

FIG 1 eine Architektur für den Einsatz eines klassischen zentralen Steuerungsrechners,

FIG 2 eine beispielhafte Architektur für den Einsatz von dezentralen Steuerungskomponenten unter Verwendung von Eigensimulatoren,

FIG 3 den schematischen Aufbau einer erfindungsgemaßen Komponente am Beispiel einer Weiche, FIG 4 in einem schematischen Ubersichtsdiagiamm den Unterschied zwischen dem mechatronischen Aufbau einer Anlage und deren Abbildung in erfindungsgemaße Module bzw. Komponenten,

FIG 5 an einem ausgewählten Anlagenszenaπo den beispiel ^¬ haften Einsatz der erfmdungsgemaßen Eigensimulatoren, und

FIG 6 eine Spezialisierung und Fortfuhrung des Beispiels von FIG 5.

FIG 1 zeigt eine Architektur für den Einsatz eines klassi- sehen zentralen Materialflussrechners MRl für die Steuerung eines Materialflusssystems (z.B. Transportsystem zur Beförderung und Zustellung von Gutern) . Der zentrale Materialfluss- rechner MRl wird dabei üblicherweise als Steuerungsrechner und als Verwaltungsrechner (z.B. für eine zentrale Datenspei- cherung, für eine zentrale Einlastplanung oder für die Simulation zur Bestimmung von zu erwartenden Anlagezustanden) eingesetzt. Der zentralen Materialflussrechners MRl kommuni ^¬ ziert mit Steuerungskomponenten SKl (z.B. Speicherprogram ^¬ mierbare Steuerung) der Anlage z.B. über Kabelverbmdungen oder wireless (WLAN, Bluetooth) . Eine Steuerungskomponente

SKl kann auch mit einer oder mehreren Nachbarsteuerungen NSl verbunden sein und Daten mit diesen austauschen oder Steue ^¬ rungsbefehle des zentralen Materialflussrechners MRl weitergeben. Des Weiteren erhalt eine Steuerungskomponente SKl In- put durch Sensoren SEI (Sensoren im Umfeld von Transportsys- temen sind z.B. Lichtschranken oder Bewegungsmelder) und be- einflusst in Abhängigkeit des Anlagenzustandes AZl und der Steuerungsparameter SPl Aktuatoren AKZ (z.B. Stellglieder) . Der zentrale Materialflussrechners MRl hat Zugriff auf die Anlagenzustandsdaten AZl der Anlagenkomponenten und steuert eine Steuerungskomponente SKl der Anlage über den Zugriff und Beeinflussung von deren Steuerungsparameter SPl in Abhangig- keit eines bereitgestellten Einlastplanes EPl. Die Kommunika ^¬ tionsinfrastruktur ist in FIG 1 durch Pfeile dargestellt.

Ein Nachteil des Einsatzes eines zentralen Materialflussrech- ners MRl für die Steuerung eines Materialflusssystems liegt darin, dass alle zentralen Steuerungs- und Verwaltungsfunkti- onen (z.B. Durchfuhrung von Anlagensimulationen, Datenhaltung, Kommunikation mit einer Leitwarte) im zentralen Materialflussrechner MRl gebündelt sind. Wenn der zentrale Materi- alflussrechner MRl ausfallt, kann sich die Anlage veränderten Lastsituationen nicht mehr anpassen, im ungunstigsten Fall steht die gesamte Anlage still. Um eine hohe Ausfallsicher- heit zu gewährleisten, muss ein zusätzlicher Rechner als „standby" zur Verfugung stehen. Dies verursacht zusätzliche Kosten und kann auch oft eine gewisse Ausfallzeit nicht verhindern, da bei einem Systemausfall, die Anlagenkomponenten erst initialisiert werden müssen und der Standby-Rechner (Reserverechner) eine Anlaufzeit benotigt, um die Anlage wieder in Gang zu bringen.

FIG 2 zeigt eine beispielhafte Architektur für den Einsatz von dezentralen Steuerungskomponenten SK2 unter Verwendung von Eigensimulatoren ESl zur Steuerung und zur Anlagensimula- tion (zur Prognose von Belegungszustanden und Vorhersage von Staus und Engpassen und Schieflasten) . Im Unterschied zur Architektur eines klassischen Steuerungsrechners (MRl, FIG 1) verfugt dieser über eine Komponente Eigensimulator ESl, wel ^¬ che Zugriff hat auf den Anlagenzustand AZ2 und die Steuerungsparameter SP2 des Moduls (Komponente) . Darüber hinaus kann der Eigensimulator ESl mit den entsprechenden Komponenten der Nachbarmodule ES2 mittels einer Kommunikationsinfra ^¬ struktur Daten austauschen. Die Kommunikationsinfrastruktur zur Steuerung eines Materialflusssystems kann verdrahtet (z.B. LAN, Ethernet, Busverbindungen), drahtlos (wireless, z.B. WLAN, Funk, Bluetooth) oder in einer Mischform zwischen verdrahtet und wireless realisiert sein. Die Kommunikationsinfrastruktur ist in FIG 2 durch Pfeile dargestellt. Die in FIG 2 dargestellte Komponente (Modul) Kl zum Einsatz in einem Materialflusssystem umfasst eine dezentrale Steuerungskompo ^¬ nente SK2, die mit Nachbarsteuerungen NS2 verbunden ist und über Sensoren SE2 (z.B. Lichtschranke zur Meldung des Eintreffens eines Transportgutes) aus der physikalischen Infra- struktur (Weichen, Förderbänder, Transportbehälter etc.) In- put erhalt. Die Steuerungskomponente SK2 kann z.B. als Spei ^¬ cherprogrammierbare Steuerung (SPS) ausgebildet sein, die in Abhängigkeit des Anlagenzustandes AZ2, der Steuerungsparameter SP2 und des Inputs der Sensoren SE2 für Aktuatoren AK2 (z.B. Stellglieder, Antriebe) einen Output liefert.

Der Eigensimulator ESl bestimmt aus den Daten der Nachbarsimulatoren ES2, aus dem Einlastplan EP2 und dem aktuellen An- lagenzustand AZ2 durch Simulation den zukunftigen Anlagenzu- stand AZ3 (bzw. die Anlagenzustande zu verschiedenen Zeitpunkten in der Zukunft) . Eine Komponente Steuerungsoptimierer SOl passt auf Grundlage der prognostizierten zukunftigen Anlagenzustande die Steuerungsparameter SP2 entsprechend auto ^¬ matisch an. Der Steuerungsoptimierer SOl kann mit einem Nach- barsteuerungsoptimierer SO2 einer Nachbarkomponente (Nachbarmodul) verbunden sein und Steuerungsparameter der Nachbarkomponente abfragen und/oder direkt beeinflussen. Dadurch wird eine weitere Optimierung und Effizienz im Anlagenbetrieb er ^¬ reicht .

Die Informationsbasis für die Eigensimulation setzt sich somit aus zwei Teilen zusammen. Zum einen aus den notwendigen Daten für die Eigensimulation und zum zweiten aus den Daten, die für die Steuerung des Materialflusssystems generiert wer- den. Mit Blick auf die notwendige Kommunikation zwischen den Modulen der Anlage, ist eine möglichst große Schnittmenge beider Datenarten zu erreichen. Allgemein lasst sich die Informationsbasis beschreiben als Funktion

&{m, t) := © ⁷ _θ (/77, t) U © ⁷ _s (/77, t) die vom Modul m und der Zeit t abhangt. © ⁷ _Θ (*, ^Φ ) ist der Anteil der Informationsbasis für die Eigensimulation und ©^(v) der Anteil für die Steuerung.

FIG 3 zeigt den schematischen Aufbau einer erfmdungsgemaßen Komponente K2 am Beispiel einer Weiche. Eine Komponente (Mo ^¬ dul) K2 - K5 besteht aus der Mechanik der Fordertechnik FBl,FB2,der Mechanik zum Ausschleusen Wl, der Sensoπk SE3,SE4 (z.B. Lichtschranken, Melder) und Aktorik (z.B. An- triebe, Stellglieder) , der Steuerung SK3, sowie Kommunikati- onsschnittstellen zu den benachbarten Modulen K3-K5. Beispiele für Module sind Förderbänder, Weichen oder Zusammenfuhrungen. Module/Komponenten, im Sinne der Erfindung, können auch komplexerer Art sein als die schon aufgeführten Beispiele. Z.B. kann eine Zusammenfuhrung einschließlich der zufuhrenden Förderbänder zu einem Modul zusammengefasst werden. Die Mo- dulbildung beruht auf Entscheidungen im Anlagenengmeering und kann durch den Technologen oder den Automatisierer erfolgen .

FIG 4 zeigt in einem schematischen Ubersichtsdiagramm den Unterschied zwischen dem mechatronischen Aufbau einer Anlage und deren Abbildung in erfindungsgemaße Module bzw. Komponen ^¬ ten. Teilbild (a) im oberen Teil von FIG 4 zeigt den me- chatronischen Aufbau einer Anlage mit Forderstrecken FB3 - FBlO, Weichen W2 - W4 und Zusammenfuhrungselementen ZUl - ZU3. Teilbild (b) im unteren Teil von FIG 4 zeigt die Abbil ^¬ dung des mechatronischen Aufbaus in die erfmdungsgemaßen Module (Komponenten) ml bis m7.

Zur beispielhaften Erläuterung sind in FIG 4 dem Modul m5 die Forderstrecken FB7 und FB8 sowie die Zusammenfuhrung ZU3 zugeordnet. Der genaue Zuschnitt von Modulen (Komponenten) ml - m7 in dezentralen Mateπalflusssystemen ist eine Designent- Scheidung des Technologen bzw. des Anlagenautomatisierers . Diese Designentscheidung ist abhangig von der vorhandenen Infrastruktur und den Anforderungen an die Anlage. Ein Modul ml - m7 ist eine Entitat, welche im dezentralen System als abgeschlossene Einheit betrachtet wird und selbst über die Information seines Verhaltens verfugt. Innerhalb jedes Moduls ml - m7 steht die vollständige Information zur Verfugung, um die künftige eigene Belegung zu simulieren, da die aktuelle Belegung und das eigene Verhalten bekannt sind. Darüber hinaus müssen zusätzlich Informationen über zukunftig zu befor ^¬ dernde Transporteinheiten von den Vorlaufermodulen mitgeteilt werden, und genauso an Nachfolgemodule weitergegeben werden.

FIG 5 zeigt an einem ausgewählten Anlagenszenario den bei ^¬ spielhaften Einsatz der erfmdungsgemaßen Eigensimulatoren.

Wie schon in FIG 2 erwähnt, lasst sich die Informationsbasis beschreiben als Funktion

(§{m, t) := GS7 _e (/77, t) U ©7 _s (/77, t)

die vom Modul /77 und der Zeit t abhangt, Gs7 _e (v) ist der Anteil der Informationsbasis für die Eigensimulation und Qs7 _s (v) der Anteil für die Steuerung.

Im Folgenden wird eine beispielhafte Simulation, basierend auf Eigensimulatoren der Module (Komponenten) beschrieben. Teilbild (a) im oberen Drittel von FIG 5 zeigt die Ausgangsbasis für das Beispiel, nämlich die Zuordnung des mechatroni- schen Anlagenaufbaus zu Modulen/Komponenten ml - m7, wie in FIG 4 dargestellt. Für dieses Beispiel wird angenommen, dass die Informationsbasis für die Steuerung aus der Anzahl Trans- porteinheiten auf den Modulen m Abhängigkeit von der Zeit besteht. D.h. , (S ⁷ S (m,t) enthalt die Anzahl Transporteinheiten auf dem gesamten Modul /77 zur Zeit t. Im Falle einer Weiche seien es nur die Module bis zur Entscheidungsstelle (in FIG 5 grau hinterlegt im Modullayout dargestellt) . Weiterhin seien für die Steuerung am Modul /77 nur die Werte <sP _s {m',') von Interes ^¬ se, für Module /77' welche von /77 aus im Mateπalfluss erreichbar sind. Die Steuerung legt für ein Modul das Verhalten in Abhängigkeit von der Informationsbasis fest. Allgemein kann man die Steuerung ebenfalls als Funktion

C^(Jk, m, t):x→{m', t)

beschreiben, die einer Transporteinheit X, welche sich zur Zeit kauf dem Entscheidungspunkt des Moduls m befindet, bei Informationsbasis J^ den Eintritt in das Nachfolgemodul /77' zur Zeit f zuordnet . Teilbild (b) in der Mitte von FIG 5 verdeut ^¬ licht diese Zuordnung. Die grau hinterlegten Flachen markieren die Entscheidungspunkte des jeweiligen Moduls. Befinden sich zwei Module gleichzeitig auf den Entscheidungspunkten des Moduls, wie die Transporteinheiten X und Z in Teilbild (b) , so kann die Funktion CX(J^, /77, £)(•) diese zeitlich entzerrt an das Nachfolgemodul weiterleiten. Wird im Beispiel, Teilbild (b) , die Transporteinheit X vor Z im Modul /77? weitergeleitet, so gilt dann für die Eintrittszeitpunkte V und t" von Xbzw. Z in das Modul IT> ₂ . t' < t". Das ist jedoch eine Designentscheidung für die Umsetzung der Eigensimulation. Die Funktion (^ kann sowohl X als auch Z den gleichen Zeitpunkt zuordnen, <s^(J^, m _∑ , t)(x) - (E^(J ₃ , ITI2, t)(z). Die Eigensimulation muss dann entsprechend mit dieser Werten umgehen können.

Weiterhin enthalt J{',') die für die Eigensimulation notwendigen Daten J^(v). Nehmen wir für das Beispiel weiter an, dass im Rahmen der Eigensimulation jedem Modul die Ankunftszeit kommuniziert wird, wann eine Transporteinheit innerhalb der Simulation das Modul erreichen wird. Der Einfachheit halber wird angenommen, dass nach Erreichen eines Moduls /77 eine Transporteinheit nach konstanter Zeit τ _m den Entscheidungs ^¬ punkt des Moduls /77 erreicht, d.h. es wird kein Warten durch Ruckstau berücksichtigt. Dann verlasst eine Transporteinheit X, welche ein Modul /77 zur Zeit t betritt es zur Zeit V und betritt Modul /77', wobei (f, m) = (3?(Jζj, t+τ _m ){x) ist . Bei Modulen mit mehreren Eingangen kann die Transportzeit τ _m noch vom jeweiligen Eingang abhangig sein, siehe Teilbild (c) im unteren Drittel von FIG 5. Somit ist der vollständige Durchlauf der Transporteinheit Xdurch das Modul /77 beschrieben . Die Informa ^¬ tionsbasis ©^(v) zur Eigensimulation muss für das Beispiel ne ^¬ ben den Werten aus Q§7 _s (v) nur noch die Transporteinheiten enthalten, welche ein Modul /77 zur Zeit t erreichen.

Im Fall unseres Beispiels sind von der Informationsbasis <2>(v) für ein Modul /77, sowohl für die Steuerung als auch die Eigen- simulation, nur Werte für Module /77' von Interesse, welche von Modul /77 aus im Materialfluss erreicht werden können. D.h., für die Bereitstellung der Informationsbasis in allen Modulen genügt es, wenn jedes Modul an seine Vorganger die Daten von seinen Nachfolgern sowie seine eigenen weiterkommuniziert. Dabei ist mit einfachen Standardmethoden, das Entstehen endloser Datenzyklen zu vermeiden.

Die Simulation der Module (Komponenten) wird zyklisch synchron für alle Module gleichzeitig angestoßen. Ein solcher Zyklus kann nach einem festen Zeitraster angestoßen werden, z.B. alle 30s zur vollen und zur halben Minute. Mittels eines geeigneten Protokolls muss sicher gestellt werden, dass alle Module sich auf eine gemeinsame Zeit synchronisieren und den gleichen Zeitplan für die Zyklusstartzeiten verwenden. Ein Beispiel für ein solches Protokoll ist das Internet-Protokoll ntp .

Zu Beginn des Zyklus initialisieren sich alle Eigensimulatoren mit den gerade im Modul befindlichen Transporteinheiten am aktuellen Aufenthaltsort. Falls ein Plan über die zu erwartenden Transporteinheiten besteht, können diese an den entsprechenden Modulen, wo sie eingelastet werden sollen, mit ihrem erwarteten Bereitstellungszeitpunkt berücksichtigt wer ^¬ den. Auf Grundlage der letzten Informationsbasis &\',•) werden die Ubergabezeitpunkte an die Nachfolgemodule für die auf dem Modul befindlichen Transporteinheiten bestimmt und an die entsprechenden Module kommuniziert. Für die per Eigensimula- tion virtuell eintreffenden Transporteinheiten wird analog verfahren. Transporteinheiten deren Eintrittszeitpunkt hinter dem zu simulierenden Zeithorizont liegt, werden verworfen. Ist die Eigensimulation abgeschlossen, so werden die Daten der gerade neu bestimmten Informationsbasis 05(v) in der Anla ^¬ ge kommuniziert und ein Zyklus ist abgeschlossen. Es können mehrer Zyklen zusammengeschlossen werden, bevor die neu ent- standene Informationsbasis ®^v) an den Steuerungsoptimierer der Module übergeben wird.

Die Simulation kann für die Module (Komponenten) aber auch asynchron aktiviert werden. Em Modul speichert zu diesem Zweck die virtuell durch die Eigensimulatoren der benachbarten Module eintreffenden Transporteinheiten. Das Modul vermerkt die erwartete Ankunftszeit sowie die weiteren Eigenschaften der virtuell eintreffenden Transporteinheiten.

Bei einer asynchronen Aktivierung sind die Laufe der Eigensimulatoren von verschiedenen Modulen nicht notwendig koordiniert. Ein Lauf einer Eigensimulation eines Moduls ist damit unabhängig von den benachbarten Modulen: Wird die Simulation für ein Modul gestartet, so initialisiert sich der Eigensimu- lator zunächst mit den gerade im Modul befindlichen Transporteinheiten am aktuellen Aufenthaltsort. Weiterhin initialisiert sich der Eigensimulator mit den vom Modul gespeicherten virtuell eingetroffenen Transporteinheiten. Liegt für das Modul ein Plan von an diesem Modul einzulastenden Transport- emheiten vor, so werden auch diese vom Eigensimulator mit ihrem Bereitstellungszeitpunkt berücksichtigt. Auf Grundlage der letzten Informationsbasis o5 ⁷ (*,*) werden die Ubergabe- zeitpunkte an die Nachfolgemodule für alle diese Transporteinheiten bestimmt und an die entsprechenden Module kommuni- ziert. Die Nachfolgemodule speichern die Werte dieser virtuell eingetroffenen Transporteinheiten für die spatere Verwendung in ihrer eigenen Eigensimulation. Damit ist die Simulation für das betrachtete Modul beendet und die Informationsbasis G§7( ^» ,*) wird aktualisiert. Nach ein oder mehreren Ei- gensimulationen wird die neue Informationsbasis Q5 ⁷ (*,*) an die Steuerung des Moduls übergeben. Das beschriebene Verfahren konvergiert aus folgendem Grund: Der betrachtete Zeithorizont ist endlich, z.B. die maximale erlaubte Durchlaufzeit einer Transporteinheit durch die Anlage. Jedes Modul m erzeugt für eine empfangene Nachricht über ein zum Zeitpunkt t zu transportierendes Gut höchstens eine Nachricht, die frühestens den Zeitpunkt t + τ _m ( ⁼ U ⁺ Durchlauf- zeit) betrifft und an ein Nachfolgemodul geht, sowie bei Bedarf eine Nachricht über den konkreten Abnahmezeitpunkt an das Ursprungsmodul der empfangenen Nachricht. D.h., nach endlich vielen Nachrichten ist der Zeithorizont erreicht und es werden keine neuen Nachrichten mehr versendet. Dann steht in jedem Modul eine Prognose über die verschiedenen Lastzustande bis zum Zeithorizont zur Verfugung.

Zur Sicherstellung der Effizienz des Verfahrens ist die Abstimmung zwischen den durch Eigensimulation zu ermittelnden Daten, und den für einen optimalen Betrieb der Anlage notwendigen Daten erforderlich. Die für den optimalen Betrieb der Anlage notwendigen Daten ergeben sich aus der in der einge- setzten Steuerung verwendeten Informationsbasis; die durch die Eigensimulation erzeugten Daten brauchen in ihrer Qualität nicht die von der Steuerung erforderte Qualität zu über ^¬ treffen sofern das nicht für die Informationsbasis ©^ der Ei- gensimulation notwendig ist. Der anfallende Justierungsauf- wand ist nicht von der konkreten Anlage und möglichen Em- lastszenaπen abhangig. Dieser Aufwand fallt nur bei der Entwicklung des entsprechenden generellen Anlagetyps an und ist somit einmalig.

Die Nachteile heutiger Materialflusssysteme mit zentralem Ma- teπalflussrechner (MFRl; FIG 1), nämlich ein zentraler Kom- munikationsengpass, ein Single-Point-of-Failure sowie uneinheitliche Grenzen von Mechatronik, Steuerung und Mateπal- flussoptimierung werden vermieden. Die Vorteile der dezen- tralen, autonomen Module bleiben erhalten, nämlich weitgehende Selbstkonflguration, reduzierter Engineeringaufwand, schnellere Inbetriebsetzung usw. Dabei kann trotzdem eine hochwertige Prognose über zukunftige Lastzustande des Systems erstellt werden als Basis für proaktive Mateπalflussstrate- gien, die qualitativ sonst nur beim Einsatz eines zentralen Mateπalflussrechners möglich sind.

FIG 6 zeigt eine Spezialisierung und Fortfuhrung des Beispiels von FIG 5. Als Beispielanlage wird der in FIG 4 Teil ^¬ bild (a) schematisch dargestellte Ausschnitt einer Anlage verwendet. Die Anlage besteht aus 8 Förderbändern, 3 Weichen und 3 Zusammenfuhrungen. Die Anlage wird in 7 Module aufge- teilt, ein Forderband {mγ), drei Weichen (/772, H7 ₄ , ITIe) und drei Zu ^¬ sammenfuhrungen {m-[, /7? ₃ , /77 ₅ ) (siehe FIG 4 Teilbild (b) , FIG 5 Teilbild (a) und FIG 6 Teilbild (a) ) . Alle Forderelemente sollen die gleiche Geschwindigkeit haben und an einem Eingang eine Transporteinheit je 2 Zeiteinheiten aufnehmen können.

Die Informationsbasis ©^(v) für die Steuerung der Anlage bestehe aus der Anzahl Transporteinheiten auf den Modulen in Abhängigkeit von der Zeit, d.h., QS ⁷ S(/77, t) ist die Anzahl Trans ^¬ porteinheiten auf dem Modul /77 zur Zeit t. Im Falle einer Wei- che seien es nur die Module bis zur Entscheidungsstelle (grau hinterlegt im Modullayout) . Weiterhin seien für die Steuerung am Modul /77 nur die Werte &^ _s {m', •) von Interesse, für Module /77' welche von /77 aus im Mateπalfluss erreichbar sind.

In die Beispielanlage sollen drei Arten von Transporteinheiten eingelastet werden, die sich in der jeweiligen Start/Ziel-Kombmation unterscheiden: die Typen x, y und z. Die Typen x und y gelangen über das Modul /77i in die Anlage und der Typ z über das Modul /77 ₄ . Verlassen sollten die Typen x und z die Anlage über Modul /7?3 und Typ y über Modul IVj. In Teilbild (b) von FIG 6 sind die aktuellen von der Steuerung verwendeten Routen R1-R3 für die drei Typen von Transporteinheiten dargestellt:

R1 R2 R3 (durchgehend) (gestrichelt) (Strich-Punkt)

X y Z Die Anlage sei zum Zeitpunkt t = 10 in der Situation von Abbil ^¬ dung 6 (c) und die Steuerung verwende immer noch die Routen von Abbildung 6 (b) . Weiterhin sei die Transportzeit τ _m für die Module /7?i und A7? ₂ bzw. /77 ₄ gleich 6 bzw. 0 Zeiteinheiten und die Transportzeit vom Entscheidungspunkt zum Eingang des Nachfolgemoduls für alle Module 2 Zeiteinheiten. Die am Modul gezeigte Folge von x3 bis xl sei die dichtest mögliche, d.h., Module A77i und /77 ₂ können maximal 4 Transporteinheiten bis einschließlich zum Entscheidungspunkt aufnehmen. Die Transportgeschwindigkeit ist so, dass nach verlassen des Entschei ^¬ dungspunkts die nächste Transporteinheit frühestens 2 Zeiteinheiten spater eintrifft.

Dann bekommt das Modul /772 folgende Informationen über die An ^¬ kunft von Transporteinheiten:

Da das Modul /77 ₂ die virtuell eintreffenden Transporteinheiten aufnimmt, ergibt sich folgende Informationsbasis G5 ⁷ _S (/77 ₂ , *). Ge ^¬ zahlt werden die Transporteinheiten vom Eingang bis einschließlich dem Entscheidungspunkt, welchen eine Transporteinheit nach 6 Zeiteinheiten erreicht.

Simuliert sich die Beispielanlage nur 11 Zeiteinheiten in die Zukunft, so stellt sich an Modul /77 ₂ eine Überlast ein, da in diesen 11 Zeiteinheiten das Modul /77 ₂ 7 Transporteinheiten aufnehmen musste. Die Maximale Aufnahmekapazitat für diese Zeit- spanne ist jedoch nur 5 Transporteinheiten. In der Informationsbasis erkennt man, dass zu den Zeitpunkten 18, 20 und 21 sich 5 Transporteinheiten auf der Strecke bis zum Entscheidungspunkt von Modul /77 ₂ befinden mussten. Das Modul bietet für maximal 4 Transporteinheiten Platz.

Ist der Zyklus abgeschlossen, z.B. weil der Zeithorizont nur 11 Zeiteinheiten betragt, so werden die gewonnen Daten der Informationsbasis in der Anlage kommuniziert. Im speziellen Fall von Modul /77 ₂ werden seine eigenen Daten, d.h. die obige Tabelle mit den Werten von 25 ⁷ _S (^, •), an die Module /7?3 und IW5 mitgeteilt. Weiterhin muss /7? ₂ die von den Modulen /773 und /77s erhaltenen Daten Q§7 _s (v) zu /77i und ITI4 weiterreichen . Werden in der Steuerung diese genauen Daten nicht benotigt so kann dass Kommunikationsvolumen reduziert werden. Ist für die Steuerung z.B. nur die Information von Relevanz, ob ein Modul zu mehr oder weniger als 50% ausgelastet ist, so genügt es, die Zeit ^¬ spannen 10 - 13 mit maximal 50% Auslastung und 14 - 21 mit mehr als 50% Auslastung zu kommunizieren.

Die Steuerung hatte jetzt die Möglichkeit, die Transporteinheiten vom Typ z über die Route /77 ₄ - /7?5 - /776 - /773 statt /77 ₄ - nri2 - IV3 zu lenkten und dadurch Modul /77 ₂ zu entlasten. Da sich nur noch Transporteinheit Z ₃ vor der letzten Weiche befindet und umge- leitet werden konnte, wurden sich in der dann folgenden Eigensimulation die Werte von cz5 ⁷ _s (/772, t) für t= 20, 21 von 5 auf 4 reduzieren.

Das beschriebene Verfahren ist auch für Anlagen mit einer zentralen Steuerung nutzbringend einsetzbar. In diesem Fall ermöglicht das Verfahren eine Softwarearchitektur, in der die Systemgrenzen der Softwarebausteine und die Grenzen der Me- chatronik zusammenfallen. Dadurch kann die reale Anlage in der Softwarelandschaft der (zentralen) Steuerung im Prinzip spiegelbildlich abgebildet werden. Viele Vorteile, wie eine einfachere Inbetriebnahme mit weitgehender Selbstkonflgurati- on der Steuerung an Hand der vorgegebenen Topologie sowie ein reduzierter Engineeringaufwand lassen sich so von dezentral auf zentral gesteuerte Anlagen übertragen.

Komponente eines Materialflusssystems zur Beförderung von Gutern, umfassend eine Mechatronik mit Forderelementen, Senso- ren und Aktoren zum Transport der Guter, eine Steuerung zur Ansteuerung der Mechatronik, Schnittstellen zu Nachbarkomponenten und zur Umgebung, einen Eigensimulator zur Bestimmung des komponentenspezifischen zukunftigen Zustandes, wobei der Eigensimulator mit Eigensimulatoren weiterer Komponenten des Mateπalflusssystems zusammenwirkt, zur Bestimmung einer

Prognose des zukunftigen Anlagenzustandes des Mateπalflusssystems. Die dezentralen Eigensimulatoren können synchron oder asynchron aktiviert werden.

Bezugs zeichen

MRl Zentraler Materialflussrechner

NSl - NS2 NachbarSteuerung SKl - SK3 Steuerungskomponente

SEI - SE5 Sensor

AKl - AK2 Aktuator

AZl - AZ3 Anlagenzustand

EPl - EP2 Einlastplan SPl - SP2 Steuerungsparameter

SOl - SO2 S teuerungsopt innerer

ESl - ES2 Eigensimulator

K1-K5, ml-m7 Komponente /Modul

FBl - FBlO Forderband Wl - W4 Weiche

ZUl - ZU3 Zusammenfuhrung x, xl - x3 Transporteinheit γ _r yi Transporteinheit z, zl - z3 Transporteinheit Rl - R3 Route