WO2001072621A1

WO2001072621A1 - Zielrufsteuerung für aufzüge

Info

Publication number: WO2001072621A1
Application number: PCT/CH2001/000205
Authority: WO
Inventors: Jana Koehler; Kilian Schuster
Original assignee: Inventio Ag
Priority date: 2000-03-29
Filing date: 2001-03-29
Publication date: 2001-10-04
Also published as: US6793044B2; ES2248295T3; CN1420836A; ATE302158T1; EP1276691A1; MXPA02009377A; BR0109529A; CN1220614C; US20030085079A1; EP1276691B1; JP2003528785A; HK1054364B; HK1054364A1; AU4220801A; DK1276691T3; AU2001242208B2; DE50107119D1

Abstract

Diese Zielrufsteuerung zur Organisation des Verkehrs von Aufzügen bietet eine Steigerung der Transportleistung, ist flexibel und robust aufgebaut und kann insbesondere individuelle und/oder kollektive Transportbedürfnisse von Passagieren berücksichtigen. Für die Ermittlung der optimalen Fahrtfolge zur Bedienung von registrierten Zielrufen ist ein Planungssystem vorgesehen, welches mittels situationsbasiertem Suchverfahren für ein fixes, vordefiniertes Optimierungskriterium die Bedienung der Zielrufe berechnet. Bei jeder relevanten Änderung der momentanen Situation des Aufzugs wird eine völlig neue aktuelle Fahrtfolge bestimmt, die der Aufzug dann ausführt. Steuerungstechnische Service-Anforderung können durch die Menge und/oder die Definition verwendeter Operatoren an sich ändernde Kundenbedürfnisse angepasst werden. Mit einem Aufbau der Zielrufsteuerung als Multi-Agentensystem ist die Verkehrsplanung einer beliebigen Anzahl von Aufzügen mit unterschiedlichem Layout, wie beispieweise einer heterogenen Multideckergruppe, möglich.

Description

Zielrufsteuerung für Aufzüge

Die Erfindung betrifft eine Zielrufsteuerung für Aufzuge nach Definition der Patentansprüche.

Bekannter Weise dient eine Aufzugssteuerung dazu, Kabinenrufe auf den verschiedenen Stockwerken eines Gebäudes zu bedienen. Der Antrieb eines Aufzugs kennt als Kommandos lediglich die Anweisungen - Fahrt nach oben - , - Fahrt nach unten - , - Tur auf - und - Tur zu -.

In grosseren Gebäuden ist meist eine Gruppe von zwei bis acht Aufzügen installiert, von denen nun derjenige Aufzug ausgewählt werden muss, der für einen neu eingegangenen Kabinenruf von einem Stockwerk aus, einem sogenannten Stockwerkruf, am geeignetsten erscheint. In der Regel ist dies der Aufzug, der den kürzesten Anfahrtsweg zu diesem Stockwerk hat. Hat nun aber jeder Aufzug der Gruppe auf diesem Anfahrtsweg vorher noch andere Stockwerkrufe zu bedienen, so werden auf diesen Stockwerken Passagiere zusteigen, deren Ziel erst bekannt wird, wenn sie die entsprechenden Kabinenknopfe gedruckt haben. Die Zuweisung eines Stockwerkrufs auf einen Aufzug gestaltet sich damit problematisch, da permanent Unsicherheit über die anzufahrenden Ziele besteht.

In der Aufzugsindustπe können deshalb zahlreiche Versuche beobachtet werden, mittels des Einsatzes von Lernverfahren auf der Basis neuronaler Netze oder genetischer Algorithmen die möglichen Zielstockwerke der Passagiere geschickt zu „erraten". Die Wirkung solcher Verfahren ist jedoch sehr beschrankt, weil lediglich grobe Verkehrsmuster, wie zum Beispiel die morgendliche Aufwartsspitze, mit einiger Sicherheit identifizierbar sind. Aber unklar bleibt etwa, wohin ein Passagier mochte, wenn er beispielsweise an einem Montagmorgen um 10.37 Uhr im 10. Stock eines Bürohochhauses einen Aufzug ruft.

Ein anderer Ansatz zur Losung der Steuerungsaufgabe besteht in sogenannten Zielrufsteuerungen. Bei einer Zielrufsteuerung geben die Passagiere bereits vor dem Betreten eines Aufzugs, bzw. einer Aufzugskabine ihr gewünschtes Zielstockwerk zum Beispiel über eine telefonahnliche Tastatur, ein sogenanntes Terminal, ein. Aus der Position des Terminals ist das Zustiegsstockwerk für die Zielrufsteuerung bekannt. Nach der Eingabe des Zielstockwerks, ermittelt ein Zuteilalgorithmus der Steuerung denjenigen Aufzug der Aufzugsgruppe, welcher für den Passagier den schnellsten und bequemsten Transport zu seinem Ziel ermöglicht. Das Terminal zeigt dem Passagier diesen Aufzug der Gruppe von Aufzügen an und der Passagier kann sich jetzt in Ruhe zum entsprechend markierten Aufzug begeben. Halt der Aufzug zum Einsteigen, so wird das Ziel des Passagiers beispielsweise über eine Anzeigeeinrichtung im Türrahmen bestätigt. In der Kabine selbst sind keine Knopfe zum Eingeben von Zielen mehr vorhanden. Auf diese Weise können durch Verwendung einer Zielrufsteuerung Passagiere mit identischem Transportziel gruppiert werden und dadurch die Transportleistung des Aufzugsystems erhöht werden .

Ein aus der EP 0 699 617 AI bekanntes Beispiel einer solchen Zielrufsteuerung ist daruberhinaus m der Lage, einzelne Passagiere zu identifizieren. Für jeden identifizierten Passagier werden durch den Zugriff auf einen Informationsspeicher zusätzliche Informationen hinsichtlich Ein- und Ausstiegsposition, seines Platzbedarfs und eventuell zusatzlicher Service-Anforderungen, bei der Ermittlung der optimalen Transportmoglichkeit berücksichtigt .

Diese und andere herkömmliche Zielrufsteuerungen basieren auf einem heuristischen Approximierungsalgorithmus auf der Basis von Zuteilungsregeln. Dieser Zuteilungsalgorithmus ist jeweils anforderungsspezifisch entworfen und programmiert. Bei einer Fahrtanfrage, dem Zielruf, werden die über eine entsprechende Sensorik erfassten personen- und anlagenbezogenen Daten an den Zuteilungsalgorithmus weitergeleitet und durchlaufen den Algorithmus zur Bestimmung der Fahrtfolge.

Treten wahrend der Ausfuhrung einer Fahrtfolge neue zusatzliche Fahrtanfragen auf, so wird die bereits berechnete Fahrtfolge dahingehend modifiziert. Dabei können aber nur einfache Modifikationen vorgenommen werden, was dazu fuhren kann, dass nur eine angepasste und zielrufbezogen nicht mehr die im Hinblick auf die geänderten Voraussetzungen optimale Fahrtfolge ausgeführt wird. Hieraus können lange Warte- und/ oder Transportzeiten für die Passagiere entstehen. Weiters sind in einem solchen festprogrammierten Zuteilungsalgorithmus Zusammenhange einzelner Steuerungsoptionen, sogenannte Service- Anforderungen, nicht immer logisch und lückenlos auszudrucken. Zudem wird die zur Berechnung der Fahrtfolge anforderungsspezifisch erstellte Steuerungs-soft-ware als einengend und aufwendig erachtet. Nachteilig ist insbesondere, dass ein einmal erstellter Zuteilungsalgorithmus nachtraglich nur unter erheblichem Aufwand an unterschiedliche kundenspezifische Steuerungsbedurfnisse angepasst werden kann. Praktisch ist zur Anpassung an veränderte Service-Anforderungen jeweils ein neuer aufzugsspezifischer Zuteilungsalgorithmus anzufertigen und gesamthaft zu implementieren.

Der Erfindung liegt die Aufgabe zugrunde, eine Zielrufsteuerung für Aufzugsanlagen anzugeben, die neben einer Steigerung der Transportleistung auch flexibel und robust aufgebaut ist und insbesondere individuelle und/ oder kollektive Transportbedurf isse von Passagieren berücksichtigt .

Zur Losung der Aufgabe ist die Erfindung gegeben durch ein Verfahren zur Fahrtfolgeplanung mit den im Patentanspruch 1 gegebenen Merkmalen, welches insbesondere dadurch gekennzeichnet ist, dass ein situationsbasiertes Suchverfahren zur Ermittlung der optimalen Fahrtfolge vorgesehen ist. Eine vorrichtungsmassige Losung ist durch eine Zielrufsteuerung nach Definition des Patentanspruchs 6 gegeben, welche eine Organisation des Verkehrsaufkommens unter Verwendung eines sogenannten Planungssystem vorsieht.

Erfindungsgemass ist also an Stelle eines bisher verwendeten anwendungsspezifisch fest programmierten Steuerungsalgorithmus ein an sich bekanntes Planungssystem vorgesehen. Das Planungssystem arbeitet nach einem situationsbasierten Suchverfahren und ermittelt zielrufbezogen ausgehend vom momentanen Betriebszustand der Aufzugsanlage und dem herzustellenden Zielzustand der Aufzugsanlage die situationsspezifisch optimale Fahrtfolge.

Die erfmdungsgemasse Anwendung eines situationsbasierten Suchverfahrens bietet im wesentlichen den Vorteil, dass bei jeder relevanten Änderung der momentanen Situation, wie z.B. bei Registrierung einer neuen Fahrtanfrage, Störungen bei Ausfuhrung einer Fahrtfolge oder dergleichen, im Extremfall nach jedem ausgeführten Fahrtfolgeschπtt eine völlig neue aktuelle Fahrtfolge bestimmt wird, und der Aufzugsantπeb diese dann ausfuhrt.

Bei jeder Registrierung einer relevanten Änderung, beispielsweise bei jedem Zielruf, werden jeweils der momentane Betriebszustand und der gewünschte Zielbetπebszustand der Aufzugsanlage auf der Basis von Fakten in einer Zustandsbeschreibung deklarativ zusammengefasst . Diese in der Zustandsbeschreibung dargestellte zu erreichende Zustandsanderung der Aufzugsanlage wird in übersetzter Form als Teil einer Situationsdarstellung, die weiter unten beschrieben ist, dem Planungssystem zugeleitet. Damit hat das situationsbasierte Suchverfahren bei jedem registrierten Zielruf die vollständige Information über den Verkehrszustand der Aufzugsanlage . Es kann deshalb für ein fixes, vordefiniertes Optimierungskriterium die optimale Bedienung des Zielrufs berechnen. Dieser Berechnungsprozess ist so gestaltet, dass tatsächlich das Optimum auf Basis des gegebenen Kriteriums unter Realzeit Anforderungen gefunden werden kann.

Der ermittelte Fahrtfolgeplan wird durch das Planungssystem derart konstruiert, dass die gewünschte Zustandsanderung bei Ausfuhrung des Fahrtfolgeplans erreicht werden kann.

Eine Aufzugsanlage mit einer Fahrtfolgeplanung gemass der Erfindung fuhrt folglich jeweils ausschliesslich die für die aktuelle Planungssituation das Optimum darstellende Fahrtfolge aus. Die Optimierung kann dabei auf der Basis ganz unterschiedlicher Kriterien erfolgen, wobei sich die Ziele der Optimierung aus der Steigerung der Leistung des Aufzugs, der Reduzierung der Warte- und/ oder Bedien- und Fahrtzeiten der Passagiere oder aber der Verbesserung eines ausgewogenen Fahrtmanagements und dergleichen ergeben.

Der Planungsvorgang wird vorteilhafter Weise zeitlich dadurch begrenzt, dass Rechenle stung und Speicherbedarf beschrankt sind. Innerhalb dieser beschrankten Rechenressourcen findet das Suchverfahren die optimale bzw. annähernd optimale Fahrtfolge. Dem Fachmann sind dafür sogenannte Anytime-Algorithmen bekannt, die für ein solches Suchverfahren zur Anwendung kommen können.

Gemass einer vorteilhaften Ausfuhrung des erfmdungsgemassen Suchverfahrens wird die Zustandsbeschreibung vorzugsweise zusammen mit einer Operatorenbeschreibung m der Situationsdarstellung m übersetzter Form dem Planungssystem zugeleitet .

Die Operatorenbeschreibung wird zur Konfigurationszeit, vorzugsweise bei der Installierung des Systems beim Kunden der erfmdungsgemassen Zielrufsteuerung mitgeteilt. Sie enthalt Operatoren, welche elementare Zustandsubergange der Aufzugsanlage spezifizieren. Die Operatoren bilden als Elementarbausteme für die zu konstruierende Fahrtfolgelosung die Grundlage des ermittelten Fahrtfolgeplans. Bei jeder ZielrufZuteilung bzw. beim Losen einer konkreten Planungsaufgabe wählt das Planungssystem die in der Losung zu verwendenden Operatoren aus der Operatorenbschreibung aus, bestimmt konkrete Werte für Operatorparameter sowie eine Anordnungsreihenfolge, m der Operatoren im Fahrtfolgeplan auftreten. Diese Anordnungsreihenfolge spezifiziert die

Ausfuhrungsreihenfolge der Operatoren im Plan, sprich, die Fahrtfolge .

Im Unterschied zu bisher fest programmierten Zuteilungsalgoπthmen kann das Planungssystem mit einer beliebigen Menge von Operatoren versehen werden, speziell auch solchen, die Service-Anforderungen bedienen können, die kundenseitig zum Installationszeitpunkt noch nicht vorhanden sind. Treten diese Anforderungen zu einem spateren Zeitpunkt auf, so muss dem Planungssystem lediglich eine entsprechende Situationsdarstellung mitgeteilt werden, m dem diese Service-Anforderungen formuliert sind. Das System kann dann solche Aufgaben sofort losen. Treten Service-Anforderungen auf, für die keine Operatoren vorgesehen sind, so sichert die Modularitat der Operatoren einem Planungssystem, dass auf sehr einfache Weise neue Operatoren hinzugefügt oder weggenommen werden können, ohne dass die bereits vorhandenen Operatoren davon beemflusst werden. Aufzugsanlagen können damit durch das Verandern der Operatormenge, die für die Steuerung zur Verfugung stehen, wie auch durch die Definition der Operatoren selbst, sehr einfach und flexibel an sich ändernde Kundenbedurfnisse im Hinblick auf die Verkehrsorganisation angepasst werden.

Bei der Steuerung einer Gruppe von Aufzügen mit der erfmdungsgemassen Zielrufsteuerung erfolgt die Berücksichtigung der Service-Anforderungen im laufender Betrieb der Aufzuganlage ohne dass eine separate Reservierung eines Aufzugs der Aufzugsgruppe für den den jeweiligen Service anfordernden Passagier erfolgen muss. Die Aufzugsteuerung und die Operatoren sind in einer Weise aufeinander abgestimmt, dass grundsätzlich jeder Aufzug jederzeit alle über die Situationsdarstellung vorgegebenen speziellen Service-Anforderungen ausfuhren kann. Bei Bedarf wird die Service-Anforderung quasi in den Gruppenbetrieb rufspezifisch integriert.

Die Einbettung eines Planungssystems als Kern der Zielrufsteuerung ist entweder in einem zentralen Konzept oder in einem dezentralen Konzept oder einer Kombination des zentralen und das dezentralen Konzepts möglich.

Bei einem Aufbau der Zielrufsteuerung mit einem sogenannten zentralen Jobmanager ist dieser entscheidende Schaltstelle zwischen den Terminals und den einzelnen Jobmanagern der Aufzuge. Die Terminals richten ihre Transportanfragen an den zentralen Jobmanager. Der Jobmanager fragt bei jedem der Jobmanager der einzelnen Aufzuge nach einem Transportangebot für den jeweils registrierten Zielruf, den sogenannten Job, an. Dem zentralen Jobmanager allein obliegen die Verwaltung aller aktuellen Transportanfragen von Passagieren, der Zielrufe, und die Buchung der Transportauftrage, sogenannte Jobs, auf den jeweils ausgewählten Aufzug. Vom zentralen Jobmanager erhalten die Terminals als Antwort die Kennung des ausgewählten Aufzugs, die sie daraufhin anzeigen (z.B. „A" oder „B" ) .

Die Kommunikation zwischen den Terminals und den Aufzügen ist einfach zu organisieren, weil sämtliche Kommunikation über eine Zentrale, den zentralen Jobmanager, lauft. Die Organisation der Jobs erfolgt bei einem zentralen Jobmanager in einer Warteschlange, einer sogenannten „first m-first out" Datenstruktur. Diese Organisation ist einfach und sichert eine eindeutige Abarbeitungsreihenfolge. Bei dem zentralen Konzept haben die Terminals lediglich die Zielrufeingäbe des Passagiers sowie die Anzeige des vom zentralen Jobmanager gebuchten Aufzugs zu verarbeiten und benötigen dazu nur eine simple Software. Was die Verwendung einfacher und kostengünstiger Terminals ermöglicht.

Bei einem dezentralen Aufbau des Jobmanagers, stehen Terminals über ein leistungsfähiges Kommunikationsnetzwerk mit den Jobmanagern der einzelnen Aufzuge einer Aufzugsgruppe in Verbindung. Die Terminals fragen direkt bei den Jobmanagern der einzelnen Aufzüge nach einem Transportangebot für den jeweils registrierten Zielruf an. Die Terminals sammeln selbständig diese Angebote ein, vergleichen diese und ermitteln die optimale Buchung des Passagiers. Bei einem dezentralen Jobmanager erfolgt die Organisation der Jobs parallel für mehrere Jobs, wobei eine beliebige Überlagerung von Anfragen und Buchungen möglich ist .

Weitere Vorteile des dezentralen Konzepts der Zielrufsteuerung liegen in der im Vergleich zum zentralen Konzept schnelleren Reaktion der Jobmanager auf Anfragen, einer erhöhten Stabilität des Gesamtsystems durch die Dezentralisierung sowie einer vereinfachten Architektur der Jobmanager, da keine separate Zentrale vorgesehen werden muss .

Sofern die dezentrale Ausgestaltung vorgesehen ist, sind die Terminals mit intelligenter Buchungssoftware ausgestattet. Die Kommunikation zwischen den Terminals und den Jobmanagern der einzelnen Aufzuge erfolgt vorzugsweise über Verwendung von Kontraktnetzprotokollen. Die Jobmanager der einzelnen Aufzuge selbst sind in der Lage, Jobs parallel zu organisieren und ihren Status korrekt zu verwalten.

Das zentrale und dezentrale Konzept des Jobmanagers können auch miteinander in einer Zielrufsteuerung kombiniert werden. In einem Netz können beliebig viele Jobmanager vorliegen, die einen oder mehrere Aufzüge steuern.

Gemass einer besonders bevorzugten Weiterbildung der Erfindung ist die situationsbasierte Zielrufsteuerung als Multi-Angentensystem dargestellt, das die Gesamtsteuerung der Anlage realisiert, wobei das Planungssystem ein Agent in diesem Multi-Angentensystem ist. Die Aufzugsanlage kann eine beliebige Anzahl von Aufzügen mit beliebigem Layout umfassen. So können auch mehrere Aufzüge mit einer unterschiedlichen Anzahl von Decks in einer Gruppe, eine sogenannte heterogene Multidecker Gruppe, zusammenarbeiten.

Der Aufbau als Multi-Agentensystem ermöglicht eine modulare Implementierung der Zielrufsteuerung, in der einzelne Komponenten, die sogenannnten Agenten, wie z.B. Planungssystem, Türen, Antrieb, Taxifahrer beliebig ausgetauscht werden können, ohne dass das Gesamtsystem geändert werden muss.

Eine ereignisgesteuerte Aktivierung der Agenten in einem Multi-Agentensystem macht die Steuerung wesentlich robuster gegenüber auftretenden Fehlern. Fallt zum Beispiel eine Schachttur auf einem Stockwerk aufgrund eines fehlerhaften Kontakts aus, so kann der Jobmanager entweder eine Evakuierungsfahrt veranlassen oder aber den Taxifahrer zunächst den noch vorhandenen Plan ausfuhren lassen. Für weitere Passagieranfragen kann der Fehler dem Konfigurationsmanager mitgeteilt werden, der alle betroffenen Komponenten des Systems informiert, dass dieses Stockwerk von diesem Aufzug vorübergehend nicht bedient werden kann. Ein Ausfall von Komponenten bedeutet nicht den sofortigen Ausfall des Gesamtsystems, so lange die Sicherheit der Passagiere gewahrleistet ist.

Weitere vorteilhafte Ausgestaltungen der Erfindung sind in unabhängigen Ansprüchen enthalten.

Ausfuhrungsbeispiele der Erfindung, bei denen die Zielrufsteuerung als Multi-Agentensystem zur Oganisation des Verkehrs einer Aufzugsanlage ausgebildet ist, sind in der Zeichnung dargestellt und nachfolgend ausfuhrlich beschrieben. Es zeigt:

Fig.l, schematisch den Aufbau eines ersten Ausführungsbeispiels der Zielrufsteuerung mit einem dezentralen Jobmananger für die Steuerung eines einzelnen Aufzugs;

Fig.2, eine schematische Darstellung der Organisation eines Pools von angefragten und offerierten Jobs bei einer Zielrufsteuerung mit einem dezentralen Jobmananger für die Steuerung einer Gruppe von Aufzügen; Fig.3, eine momentane Zustandsbeschreibung gemass dem ersten Ausfuhrungsbeispiels;

Fig.4, eine graphische Darstellung des ermittelten Fahrtfolgeplan gemass dem ersten Ausführungsbeispiel; Fig.5, schematisch den Aufbau eines zweiten Ausfuhrungsbeispiels der Zielrufsteuerung mit zentralem Jobmananger als Schaltstelle zwischen Terminals und den einzelnen Aufzügen; Fig.6, in einem Blockschaltbild die Organisation der Jobs in einer Warteschlage bei einem zentralen Jobmanager; Fig.7, eine momentane Zustandsbeschreibung des Aufzugs A aus dem zweiten Ausfuhrungsbeispiel; Fig.8, eine momentane Zustandsbeschreibung des Aufzugs B aus dem zweiten Ausfuhrungsbeispiel;

Fig.9, den Aufbau eines Operators mit Stop-Anweisung, wie er im zweiten Ausfuhrungsbeispiel zur Anwendung kommt.

Figur 1 zeigt schematisch den Aufbau einer erf dungsgemassen Zielrufsteuerung 1 mit situationsbedingter Fahrtfolgeplanung des Verkehrsaufkommens eines einzelnen Aufzugs. Die Zielrufsteuerung ist als Multi- Agentensystem aufgebaut. Grundlage des Multi-Agentensystems bildet ein leistungsfähiges Kommunikationsneztwerk 2, über welches drei im Gebäude verteilte Einrichtungen zur Zielrufeingäbe, sogenannte Terminals 3.1,3.2,3.3, mit einem dezentralen Jobmanager 4 Verbindung stehen.

Idealerweise, wird als Kommunikationsneztwerk 2 eine Architektur zur spontanen Vernetzung gewählt. Bei dieser Ausfuhrung ist ein an sich bekanntes Ad-hoc Netzwerk mit der Bezeichnung IRON vorgesehen. IRON unterstutzt eine spontane Vernetzung und ist somit eine entscheidende Voraussetzung für eine konfigurierungsfeie Steuerung.

Bekannte Beispiele für Architekturen zur spontanen Vernetzung sind Jim, Universal Plug and Play oder Bluetooth. In solch einem Kommunikationsneztwerk 2 können sich netzwerkfahige Gerate, sogenannten Agenten, anmelden und miteinander agieren, ohne dass eine Konfiguration oder Administration notig ist. Die Integration aller dieser Gerate und der darauf implementierten Dienste lauft vollautomatisch ab. Die wichtigsten Methoden eines solchen Kommunikationsnetzwerks 2 sind - register - , - lookup - und - notify - .

• Durch Registra tion melden sich die einzelnen Gerate im Netz an und machen ihre Dienste bekannt.

• Durch Lookup kann ein Gerat ein anderes Gerat oder einen benotigten Dienst finden.

• Durch Notifica tion kann sich ein Gerat bei einem anderen für die Benachrichtigung über das Eintreten bestimmter

Ereignisse anmelden.

In einer Aufzugsgruppe melden sich vorzugsweise Terminals, Antriebe, Kab enturen, zentrale Jobmanager und/ oder dezentrale Jobmanager als netzwerkfahige Gerate an.

• Terminals melden sich mit ihrer Stockwerksposition und XY-Koordmate im Netz an und informieren sich über alle vorhandenen Jobmanager. • Antriebe repräsentieren die physische Komponente der Aufzugssteuerung. Sie stellen die Information zur Verfugung, welche Stockwerke sie anfahren können, wieviele Schachtturen sich auf einem Stockwerk befinden und auf welcher Seite diese positioniert sind. Desweiteren kann beim Antrieb die Benachrichtigung bestimmter Ereignisse wie Wechsel des Selektors, Wechsel des Zustands (z.B. fahrend, ankommend, stillstehend) abonniert werden.

• Kabmenturen melden sich mit Information darüber zu welchem Antrieb sie gehören, auf welchem Deck sie sich befinden und auf welcher Seite sie offnen. Durch diese Information findet der Jobmanager sofort heraus, wieviele Decks ein Aufzug hat und wieviele Türen pro Deck vorhanden sind.

• Jobmanager melden sich im Netz mit der Information an, welche Antriebe sie vertreten - einen einzelnen im strikt dezentralen Konzept oder alle vorhandenen beim strikt zentralen Konzept.

Prinzipiell können sich im Netz beliebig viele Komponenten anmelden. Das traditionelle Gruppenkonzept von Aufzügen ist damit überflüssig und insbesondere können in einer Gruppe eine beliebige Anzahl von Aufzügen mit ganz unterschiedlichem Layout vorhanden sein.

Melden sich zum Beispiel elf Antriebe, von denen drei nur eine Tur haben, vier jeweils drei Türen auf zwei Decks und vier jeweils sechs Türen gleichverteilt auf drei Decks, so liegt ein Beispiel einer sogenannten heterogene Multideckergruppe vor, bestehend aus

• 3 Singledeckern mit nur einer Tur

• 4 Doppeldeckern, wobei ein Deck mit einer Tur und das andere Deck mit 2 Türen ausgestattet ist

• 4 Tripledeckern, bei denen jedes Deck 2 Türen hat.

Der Jobmanager jedes der einzelnen Aufzuge ist m der Lage, die Anzahl der Decks und Türen seines zugeordneten Antriebs zu erkennen und in der Steuerung korrekt zu verarbeiten. Dies beinhaltet insbesondere:

• das Planungssystem plant bei einem Multidecker das Em- und Aussteigen der Passagiere über alle vorhandenen Decks, • der Taxifahrer des Jobmanagers sendet bei einem Stop die Turoffnungskommandos an alle Türen, die zu Stockwerken offnen, auf denen Passagiere ein- oder aussteigen wollen.

Bei dem hier verwendeten IRON-Kommunikationsneztwerk 2 können sich Agenten gegenseitig ber Änderungen informieren und Informationen aufbereiten und in die eigene Ablauflogik integrieren. Ein Agent kann via Broadcast herausfinden, welche anderen Agenten sich im Netz angemeldet haben sowie Nachrichten an andere Agenten versenden. Ferner kann ein Agent Informationen bei einem anderen Agenten abonnieren.

Die einzelnen Komponenten dieses Multi-Agentensystems, die sogenannten Agenten, ist neben den oben erwähnten Terminals der Jobmanager 4, der alle Komponenten, die für die logische und physische Steuerung eines Aufzugs notwendig sind integriert. Dies sind hier, ein Planungssystem oder Planer 5 5, ein Broker 6, ein Turmanager 7, ein Taxifahrer 8, der Antrieb 9 des Aufzugs und ein Beobachter 10.

Die Terminals 3.1,3.2,3.3 sind mit intelligenter Buchungssoftware ausgestattet und fragen direkt beim Jobmanager 4 nach einem Transportangebot für den jeweils registrierten Zielruf an. Die Kommunikation zwischen Terminals und Jobmanagern 4 erfolgt mittels Kontraktnetzprotokollen. Jedes der Terminals 3.1,3.2,3.3 ist mit einer Einrichtung zur Identifizierung von Passagieren ausgestattet, zu der ein Konfigurationsmanager 11 gehört.

Im Konfigurationsmanager 11 sind das aktuelle Gebaudelayout, wie zum Beispiel die Anzahl der Stockwerke, Zutrittszonen, Unterteilung der Passagiere Passagiergruppen, Zutrittsrechte, Service Anforderungen, usw. und Passagiermformationen abrufbar gespeichert. Bei der Registrierung eines Zielrufes, kann jedes Terminal Passagierdaten vom Konfigurationsmanager 11 abfragen und an den Broker 6 weiterleiten. So kann jedes Terminal zum Beispiel prüfen, ob der aktuell registrierte Passagier eine Zutrittserlaubnis zum gewünschten Zielstockwerk hat. Ist die Prüfung erfolgreich, so fragt das Terminal den Jobmanager 4 des Aufzugs nach seinem Transportangebot an.

Der Planer 5 plant für sich die optimale Bedienung des neuen Passagiers unter Berücksichtigung der aktuellen, aufzugspezifischen Verkehrssituation und erzeugt dabei einen optimalen Plan, welcher dann zur Steuerung des Antriebs 9 des Aufzugs an den Broker 6 weitergegeben wird, was weiter unten beschrieben ist. Ausgangspunkt für den Planer 5 ist eine zu jedem Zeitpunkt aktuelle Situationsdarstellung, m die der Broker 6 neue Passagiere eintragt, wahrend der Beobachter 10 beforderte Passagiere entfernt.

Der Broker 6 kommuniziert über ein zweistufiges Kontraktnetzprotokoll mit den drei Terminals 3.1,3.2,3.3. Er nimmt die Eingaben der Terminals 3.1,3.2,3.3 entgegen, tragt sie in die Situationsdarstellung des Planers 5 ein, prüft den generierten optimalen Plan daraufhin, wie sich der neu eingeplante Passagier auf den Transport der bereits gebuchten Passagiere auswirkt und teilt dem Terminal das Transportangebot mit. Konnte kein Plan gefunden werden, weil das Problem beispielsweise aufgrund von unlösbaren Konflikten zwischen den Passagiergruppen für diesen Aufzug unlösbar ist, so informiert der Broker 6 das entsprechende Terminal auch darüber. Ist der Passagier gebucht, so sendet der Broker 6 dem Taxifahrer 8 den aktuellen Fahrtfolgeplan. Das Terminal nimmt nun die Anzeige auf dem Display vor. Der Beobachter 10 überwacht den Zustand der Aufzugsanlage und fuhrt die Situationsdarstellung für den Planer 5 nach. Stellt er also fest, dass der Aufzug auf einem Stockwerk gehalten hat und die Türen korrekt geöffnet wurden, so werden alle Passagiere als -served- markiert, für die - boarded- gilt und deren Ziel diesem Stockwerk entspricht. Passagiere, die dort noch warten, werden als -boarded- markiert, da sie zusteigen, wenn der Aufzug bei ihnen angekommen ist. Der Beobachter 10 hat dabei keine Kenntnis des Plans oder der Aktivitäten des Taxifahrers 8, sondern stutzt sich allein auf die Information, die er beim Antrieb 9 und beim Türmanager 7 abonniert hat. Dies ist eine Voraussetzung um auch beim Auftreten eines Sonderbetriebs, wie z.B. dem Auslosen der Brandfallsteuerung, die die Kontrolle über den Antrieb 9 übernimmt und den Taxifahrer- Normalbetrieb unterbricht, sicherzustellen, dass die Situationsdarstellung entsprechend der tatsächlich auftretenden Zustandsänderungen korrekt nachgefuhrt wird.

Der Taxifahrer 8 fahrt seinen jeweils aktuellen Plan ab, d.h. er sendet die entsprechenden Kommandos an den Antrieb 9 des Aufzugs und die Antriebe der Türen. Er weiss aus seinem aktuellen Plan, wo der Aufzug als nächstes planmassig halten soll und wie lange die Türen geöffnet werden müssen, damit alle Passagiere genug Zeit zum Ein- und Aussteigen haben. Wieviele Passagiere an einem Stop den Zustand wechseln, wurde bereits durch den Planer 5 bestimmt. Hat der Taxifahrer 8 keinen Plan mehr, so gibt er den Aufzug frei, damit dieser geparkt werden kann. In jeder beliebigen Situation kann der Taxifahrer 8 seinen aktuellen Fahrplan gegen den aktuellen Plan, der ihm vom Broker 6 geschickt wird, auswechseln. Wie dieses Wechseln erfolgt, hangt davon ab, welchem Ausfuhrungszustand sich der Taxifahrer 8 befindet. So gilt zum Beispiel, dass ein einmal begonnener Stopvorgang aus dem alten Plan erst beendet werden muss, bevor der Taxifahrer 8 den ersten Stop aus dem neuen Plan anfahren kann.

Der Antrieb 9 fuhrt die Fahr- und Stop-Kommandos aus, die er vom Taxifahrer 8 erhalt, ausserdem lernt er die Fahrzeiten des Aufzugs zwischen den einzelnen Stockwerken. Er stellt die Fahrzeitentabelle dem Planer 5 für die Optimierung zur Verfugung und meldet auch, wo der Aufzug sich aktuell befindet und in welche Richtung er fahrt oder ob er gerade anhält .

Der Turmanager 7 verwaltet alle Türen des Aufzugs und überwacht, dass die Türen korrekt offnen und schliessen. Dabei können auf verschiedenen Seiten einer Kabine Türen vorhanden sein. Er bestimmt auch die Turoffnungs- und Schliesszeiten der Türen und teilt sie dem Planer 5 für die Optimierung der Bedienzeiten der Passagiere mit.

Jede der Komponenten ist als selbständiger Agent implementiert, der beim Auftreten bestimmter Ereignisse selbständig Handlungen ausfuhrt. Insbesondere können sich dadurch verschiedenste Ereignisse überlagern. So kann zum Beispiel der Broker 6 gleichzeitig die Anfragen verschiedener Terminals 3.1,3.2,3.3 entgegennehmen und dem Planer 5 vorlegen. Der dezentrale Jobmanager 4 kann parallel für mehrere Jobs ein Angebot abgeben, wahrend die Buchung anderer Jobs noch aussteht. Die Jobs werden erst dann verbindlich, wenn das entsprechende Terminal bucht. Da zwischen der Abgabe des Angebots durch den Broker 6 und der Buchung durch das jeweilige Terminal theoretisch eine beliebig lange Zeitspanne vergehen kann, ist es möglich, dass zwischenzeitlich bereits ein anderes Terminal eine Buchung platziert hat. In dieser Situation muss der Broker 6 prüfen, ob das abgegebene Angebot noch gültig ist, wenn das Terminal jetzt seine Buchung schickt. Diese beliebige Überlagerung von Anfragen und Buchungen erfordert es, dass das Terminal auf eine Ruckbestatigung seiner Buchung wartet und bei fehlender Bestätigung eine alternative Buchung bei einem anderen Jobmanager 4 versucht. Ist auch die Neuplanung erfolglos, weil sich die Situation im Aufzug zum Beispiel derart geändert hat, dass jetzt unlösbare Konflikte zwischen den bereits gebuchten und dem neu zu buchenden Passagier auftreten, so erhalt das Terminal eine entsprechende Ruckmeldung.

Figur 2 zeigt einen Pool von angefragten und offerierten Jobs Jobl bis Job4 bei einem dezentralen Jobmanager 4. Jedes Terminal 1,2 hat m der Regel nur einen konkreten Job Job X bzw Job Y, den es auf einen Aufzug buchen will. Es sendet diesen Job deshalb an alle ihm bekannten Jobmanager 4 der Gruppe von Aufzügen, von denen es aus den Antriebsdaten weiss, ob der dazugehörige Aufzug sowohl Ein- als auch Ausstiegsstockwerk des Passagiers bedienen kann. Unnötige Anfragen an Aufzuge, die für den Transport prinzipiell nicht in Frage kommen, werden damit vermieden.

Am dezentralen Jobmanager 4 liegen zwei Arten von Jobs vor: Einerseits sind dies Jobs, die Jobs X, die angefragt wurden und für die der Jobmanager 4 ein Angebot berechnen muss, andererseits sind die Jobs Y, für die der Jobmanager 4 bereits ein Angebot abgegeben hat, aber noch nicht weiss, ob das Terminal wirklich bei ihm buchen wird.

Bei dem hier dargestellten und in Figur 1 gezeigten ersten Ausführungsbeispiel ist nur ein einzelner Aufzug vorhanden. Der Aufzug kann aber auch Teil einer Aufzugsgruppe sein. Die Erfindung ist ohne Einschränkung auf solche Aufzugsgruppen anwendbar. Auch bei einer Aufzugsgruppe fragen die Terminals 3.1,3.2,3.3 direkt bei den Jobmanagern 4 der einzelnen Aufzuge nach einem Transportangebot an. Die Terminals 3.1,3.2,3.3 sammeln selbständig diese Angebote ein, vergleichen diese und berechnen die optimale Buchung des Passagiers. Jeder angefragte Aufzug rechnet unabhängig von den anderen unter Berücksichtigung der aktuellen, aufzugspezifischen Verkehrssituation seinen optimalen Fahrtfolgeplan zur Bedienung des neuen Passagiers aus. Das Angebot jedes angefragten Aufzugs wird an das Terminal zurückgesandt, das das beste Angebot auswählt und den entsprechenden Aufzug mit dem Transport des Passagiers beauftragt. Bestätigt der Jobmanager 4 die Buchung gegenüber dem Terminal von dem das Transportangebot angefragt worden ist, so wird die Buchung verbindlich und wird dem Passagier auf dem Terminal angezeigt. Meldet sich ein Jobmanager nicht mehr, so reagiert das Terminal auch darauf und wartet nicht endlos auf das fehlende Angebot.

Die Arbeitsweise der insoweit beschriebenen erfmdungsgemassen Zielrufsteuerung gemass Figur 1 ist nachfolgend am Beispiel eines Planungsproblems einer Aufzugsanlage mit nur einem einzelnen Aufzug mit einturiger Kabine beschrieben, der ein hier nicht dargestelltes Gebäude mit Haltestellen auf sieben Stockwerken fl bis f7 bedient. Die Aufzugkabine steht momentan in Stockwerk f4. Ein Passagier Pl, wartet auf Stockwerk f2 und mochte s Stockwerk f7, ein zweiter Passagier P2 befindet sich bereits m der Kabine und mochte von Stockwerk fl ms Stockwerk f5. Es ist die Fahrtfolge der Kabine erfmdungsgemass mittels Planungssystem 3 zu organisieren.

Vom Beobachter 10 werden die Eigenschaften des Aufzugs, das heisst, der momentane Betriebszustand des Aufzugs erfasst und in der Situationsdarstellung aktualisiert. Über Terminals 3.1,3.2,3.3 m Verbindung mit dem Konfigurationsmanager 11 werden die Eigenschaften der Passagiere Pl, P2 und insbesondere die Zielrufe, der Passagiere Pl, P2 als Eingangsgrossen der Zielrufsteuerung 1 an den Broker 6 weitergeleitet, der sie m die Situationsdarstellung des Planers 5 eintragt, wie m Figur 2 gezeigt .

So werden bei jedem Planungsvorgang, der z.B. durch Registrierung eines Zielrufs gestartet wird, der ermittelte Betπebszustand und der gewünschte Zielzustand, also die zu erreichende Zustandsanderung des Aufzugs einer für das Planungssystem verstandlichen Zustandsbeschreibung 14 deklarativ zusammengestellt, die in Figur 3 dargestellt ist.

Die hier m Figur 3 abgebildete Zustandsbeschreibung 14 ist in der Plandarstellungssprache PDDL nach McDermott er al . 1998, ausgedruckt. Dem Fachmann sind auch andere Modellierungssprachen bekannt, die sich hinsichtlich ihrer Ausdrucksmachtigkeit unterscheiden, und die er zur Beschreibung der Situationdarstellung verwenden kann, ohne dass damit das Wesen der Erfindung ändert. Allerdings ist bei der Wahl eines Planungssystems darauf zu achten, dass dieses der Modellierung entsprechend machtige Planungsalgorithmen zur Verfugung stellt.

In der in Figur 3 dargestellten Zustandsbeschreibung 14 werden dem Planungssystem 3 einer Objektdeklaration 15 zunächst die gemeldeten Passagiere Pl, P2 und die Stockwerke fl bis f7 des Gebäudes bekannt gemacht. Für jedes Objekt wird eine typisierte Konstante eingeführt. Für den hier betrachteten Aufzug sind dies der wartende Passagier Pl, der sich bereits m der Kabine befindende Passagier P2 und alle sieben Stockwerke fl bis f7.

( : objects

(pl - passenger) (p2 - passenger)

(fl,f2,f3,f4,f5,f6,f7 - floor))

Aus dem Konfigurationsmanager 11 erhalt der Broker 6 die Angaben hinsichtlich der Topologie des Gebäudes Diese findet sich als Topologiebeschreibung 16 in der Zustandsbeschreibung 14 wieder m Form von

(upper fl f2) (upper fl f3) (upper fl f4)

(upper fl f5) (upper fl f6) (upper fl f7) (upper f2 f3) (upper f2 f4) (upper f2 f5)

(upper f2 f6) (upper f2 f7) (upper f3 f4)

(upper f3 f5) (upper f3 f6) (upper f3 f7)

(upper f4 f5) (upper f4 f6) (upper f4 f7)

(upper f5 f6) (upper f5 f7) (upper f6 f7).

In der Topologiebeschreibung 16 legen die (upper ''fi^fj) Vorgaben jeweils fest, dass das Stockwerk f oberhalb des Stockwerks fi liegt. Die Darstellung der Gebaudetopologie ist nicht zwingend erforderlich. In Vereinfachung kann anderen Ausfuhrungen des Verfahrens auch auf die explizite Topologiebeschreibung 16 des Gebäudes unter der Annahme verzichtet werden, dass von jedem Stockwerk aus jedes andere Stockwerk durch den Aufzug bedient werden kann.

Der aktuelle Transportauftrag 17 mit den Zielrufen der

Passagiere Pl und P2 stellt sich aus Einstiegsstockwerken, oπgm, und Zielstockwerken , dest , dar als

( : mit (origm pl f2)

(origm p2 fl)

(destm pl f7)

(destm p2 f5) (boarded p2) .

Der Transportauftrag 17 enthalt aus einer früher geplanten Fahrtfolge ausserdem die Information, boarded P2, nämlich, dass Passagier P2 bereits eingestiegen ist und sich in der Kabine befindet. Diese Information wurde vom Beobachter 10 in die Zustandsbeschreibung eingesetzt.

Grundsätzlich nimmt jeder Passagier P1,P2 im Rahmen der Fahrtfolgeplanung die drei Zustande: wartend/waitmg, fahrend/boarded, bedient/served ein, die hier folgendermassen definiert sind:

• Wartend/ waitmg: Der Passagier wartet vor der

Aufzugstur. Hier hat der Aufzug zuerst am Ausgangsort, origm, des Passagiers und erst danach an dem vom

Passagier angegebenen Zielstockwerk, destm, zu halten . • Fahrend/ boarded: Der Passagier befindet sich in der

Aufzugskabine und wird zu seinem Zielstockwerk, destin, transportiert, welches bisher noch nicht angefahren, d.h. bedient worden ist.

• Bedient/ served: Der Passagier hat die Aufzugskabine an seinem Zielstockwerk, destin, verlassen. Dieser Transportauftrag ist erledigt und der Passagier wurde zufriedenstellend vom Aufzug bedient.

Diese drei möglichen Zustände lassen sich mittels der beiden Befehle -boarded ?p- und -served ?p- in der PDDL- Modellierungssprache ausdrücken. Der Passagier Pl wartet auf eine Aufzugkabine und ist deshalb weder als -boarded- noch als -served- registriert.

Der Beobachter 10 setzt die aktuelle Position 18 der Aufzugskabine, die als

(lift-at f4) )

in der Zustandsbeschreibung 14 ausgedruckt ist.

Das Ziel 19 für das Planungssystem 5 wird in der Zustandsbeschreibung 14 formuliert als:

( : goal (forall ( ?p - passenger) (served ?p) ) .

Gesucht ist nun die kürzeste Folge von Stops, die alle Passagiere P1,P2 in den Zustand bedient -served- überfuhrt, die genau dann erreicht ist, wenn sie auf ihrem Zielstockwerk -destin- ausgestiegen sind. Neben den Beschreibungen des Ausgangszustands und des Zielzustands des Planungsproblems durch die Zustandsbeschreibung 14, wird dem Planungssystem 3 auch eine Operatorenbeschreibung übergeben. Im hier dargestellten Ausfuhrungsbeispiel werden in der Operatorenbeschreibung em Stop-Operator sowie ein Operator zum Aufwartsfahren -up- und em Operator zum Abwartsfahren -down- zur Modellierung der Zustandsubergange zwischen Ausgangszustand und Zielzustand des Aufzugs übergeben. Alternativ zu diesen Operatoren - stop-, -up-, -down-, kennt der Fachmann auch andere Operatoren, mit denen sich die gewünschte Änderung des Aufzugszustands erreichen lasst. Gegebenenfalls ändert sich dadurch bei entsprechender Definition der Parameter das Wesen der Erfindung nicht. In PDDL-Syntax gemass McDermott et al. 1998 steht hier folgender Stop Operator zur Verfugung:

(define (domain miconic) (: requirements :adl) (:types passenger - ob ect floor - object)

( :predicates

(origm ?person - passenger ?floor - floor) (destination ?person - passenger ?floor - floor) (boarded ?person - passenger) (served ?person - passenger) (lift-at ?floor - floor) )

( : action stop

:parameters (?f - floor) :precondιtιon (and (lift-at ?f) ) : ef fect ( and ( forall ( ?p - pas s enge r ) ( when ( and ( boarded

?P )

(destination ?p ?f) )

(and (not (boarded ?p) ) (served ?p) ) ) ) (forall ( ?p - passenger) (when (and (origin ?p ?f) (not (served ?p) ) ) (boarded ?p) ) ) ) )

Der Operator zum Aufwartsfahren -up- stellt sich dar als:

( : action up

:parameters (?fl - floor ?f2 - floor) :precondιtion (and (lift-at ?fl) (upper ?fl ?f2)) :effect (and (lift-at ?f2) (not (lift-at ?fl))))

Der Operator zum Abwartsfahren -down- ist ausgedruckt als:

( : action down

:ρarameters (?fl - floor ?f2 - floor) :precondition (and (lift-at ?fl) (upper ?f2 ?fl)) :effect (and (lift-at ?f2) (not (lift-at ?fl))))

Der stop-Operator signalisiert der Steuerung des Antriebs 9 des Aufzugs, dass die Kabine auf einem bestimmten Stockwerk fl bis f7 anzuhalten hat. Der stop-Operator ist im hier dargestellten ersten Ausfuhrungsbeispiel so definiert, dass er das Offnen und Schliessen der Türen mit beinhaltet. Das Offnen und Schliessen der Kabinenturen kann aber auch als separate zus tzliche Grundanweisung an den Turmanager 7 eines Aufzugs berücksichtigt werden oder es kann der stop- Operator dahingehend verfeinert werden, dass em Aufzug auch die Türen offnen und schliessen kann. Die Operatoren zum Aufwartsfahren -up- und Abwartsfahren - down- geben die steuerungstechnische Anweisung an die Antriebssteuerung, den Antrieb 9 m die entsprechende Richtung in Gang zu setzen. Die zeitliche Abfolge, m der die der Antrieb 9 mittels den Operatoren angesteuert wird, gibt der Taxifahrer 8 vor.

Eine Veränderung des Passagierzustands ist grundsätzlich ausschliesslich bei einem Stop der Kabine möglich. Ausgehend von rationalem Verhalten der Passagiere, begeben sich bei einem planmassigen Stop der Aufzugskabine auf einem Stockwerk alle Passagiere, welche auf diesem Stockwerk - origm- warten, um transportiert zu werden die Kabine und alle Passagiere verlassen die Kabine, wenn diese auf ihrem Zielstockwerk -destin- anhält. Die dadurch eingetretene Veränderung wird hier mit Hilfe des Beobachters 10 im Stop- Operator registriert und dadurch bei der Fahrtfolgeplanung vom Planungssystem 5 berücksichtigt. Wie die Operatoren -up- , -down-, so wird auch der stop-Operator dann als Anweisung für den Antrieb 9 wirksam, wenn die in -effect- kodierten Kriterien alle erfüllt bzw. eingetreten sind. Wird in dem hier beschriebenen Beispiel im stop-Operator ?f=f5, gewählt, so steigt P2 entsprechend der Zustandsbeschreibung 14 und des Verhaltensmodells aus, wenn, wie im Stop-Operator als - effekt- der Operatorinstanz stop (f5) beschrieben, -boarded p2- und -destin p2 f5- gelten.

Die insoweit entweder m der Operatorenbeschreibung oder als Daten der Zustandsbeschreibung 14 deklarierten Informationen werden zur Berechnung des optimalen Fahrtfolgeplans an das Planungssystem 5 weitergegeben. Planungssysteme 5 sind aus anderen technischen Gebieten bereits bekannt. In diesem Ausfuhrungsbeispiel sucht em IPP Planungssystem, wie es aus Koehler et al., 1997, Extendmg plannmg graphs to an ADL subset, erschienen in Steel, S, Proceedmgs of the 4^th European Conference on Plannmg, 273- 285 Springer, Band 1348 of LNAI, verfugbar unter http: //www. Informatik. uni-freiburg. de/~koehler/ιpp . html, eine gültige Folge von STOP Anweisungen, welche das PlanungsZiel 13 (: goal (forall (?p - passenger) (served ?p) ) erfüllt. Es können auch andere Planungssysteme verwendet werden, sofern diese in der Lage sind, die momentane Situationsdarstellung gesamthaft zu erfassen und zu verarbeiten.

Grundsatzlich wählt das Planungssystem 5 bei Eingabe der Zustandsbeschreibung 14 selbständig auf Basis der über die Operatorenbeschreibung zur Verfugung gestellten Operatoren Instanzen aus und bestimmt auch noch die Reihenfolge im ermittelten Fahrtfolgeplan 20. Das Planungssystem 5 bestimmt jeweils die Parameter für die drei Operatoren -stop-, -up-, -down-, die eine gewünschte Zustandsanderung bewirken.

Das Ergebnis davon ist bei diesem Ausfuhrungsbeipiel eine geplante Fahrtfolge 20, der optimale Plan, der in graphischer Form in Fig. 3 dargestellt ist.

Time step 0 up f4 f5

Time step 4 up f2 f7

Time step 5 stop f7 Dieser berechnete optimale Plan 13 wird an den Broker 6 weitergegeben. Der Broker 6 prüft den generierten optimalen Plan daraufhin, wie sich der neu eingeplante Passagier Pl auf den Transport des bereits gebuchten Passagiers auswirkt und teilt dem Terminal das Transportangebot mit.

Bei dem hier beschriebenen Ausfuhrungsbeispiel liegt nur em Zielruf zur Planung vor. Folglich ist nur für einen Job em Angebot abzugeben. Deshalb können zwischen der Angebotsberechnung durch den dezentralen Jobmanager 4 und der Buchung durch das jeweilige Terminal, keine anderen Jobs durch andere Terminals 3.1,3.2,3.3 gebucht werden. Aus diesem Grund entfallt auch die Ruckbestatigung seiner Buchung an das Terminal, sondern ist die Buchung sofort verbindlich. Das Terminal nimmt nun die Anzeige auf dem Display vor und der Broker 6 sendet dem Taxifahrer 8 den aktuellen optimalen Fahrtfolgeplan 20.

Der Taxifahrer 8 fahrt diesen aktuellen Fahrtfolgeplan 20 ab, d.h. er sendet die entsprechenden Kommandos m Form der jeweiligen Operatoren an den Antrieb 9 des Aufzugs und den Antrieb der Türe.

Dieser Fahrtfolgeplan 20 bewirkt, dass die Aufzugskabine im Schritt 0 vom aktuellen Stockwerk f4 auf dem sie sich befindet, zum nächsten Halt auf Stockwerk f5 -stop f5- fahrt . Dort halt die Aufzugskabine gemass Schritt 1 -stop f5- an und die Kabmenture in vorgegebener Zeit öffnet und schliesst, so dass der Passagier P2 aussteigt und damit bedient, served, ist. Im Schritt 2 fahrt die Aufzugskabine abwärts von f5 nach f2 -down f5 f2- und halt im Schritt 3 auf Stockwerk f2 -stop f2-. Dort steigt Passagier Pl zu. Im Schritt 4 fahrt der Aufzug aufwärts von Stockwerk f2 nach Stockwerk f7 -up f2 f7- und halt im letzten Schritt 5 auf Stockwerk f7 -stop f7-. Dort kann nun auch Passagier Pl aussteigen. Durch diese Fahrtfolge 13 werden alle Passagiere Pl, P2 in den Zustand -served- überführt und die Zielformulierung 10 der Fahrtfolgenplanung ist damit erreicht .

Während der Taxifahrer 8 den optimalen Fahrtfolgenplan 13 ausfuhrt, überwacht der Beobachter 10 den Zustand der Aufzugsanlage und fuhrt die Situationsdarstellung für den Planer 5 laufend nach. Im Schritt 1 stellt er also fest, dass der Aufzug auf dem Stockwerk f5 angehalten hat und die Türen korrekt geöffnet wurden; er markiert den Passagiere P2 als -served-. Bei Schritt 2 markiert der Beobachter 10 den Passagier Pl, der dort auf Stockwerk f2 wartet, als - boarded- . Schliesslich hält die Aufzugskabine auf dem Stockwerk f7 und nachdem die Türen korrekt geöffnet worden sind, setzt der Beobachter 10 auch den Passagier Pl in der Situationsbeschreibung als served und die aktuelle Postion 9 der Aufzugskabine in der Zustandsdarstellung 5 auf Stockwerk f7.

Dieser erzeugte Fahrtfolgeplan 20 wird nun aber nicht zwingend vollständig ausgeführt, sondern wenn sich Zustand, bzw. die Eigenschaften, von Passagieren und/oder der Anlage relevant andern bevor er komplett ausgeführt ist, wird erfmdungsgemass ein nächster Planungszyklus gestartet und ein für die neue Planungssituation optimaler Fahrtfolgeplan 20 erstellt. Es erfolgt daher keine Planmodifikation.

Figur 5 zeigt schematisch die Struktur und den Grundaufbau eines zweiten Ausfuhrungsbeispiels der erfmdungsgemassen Zielrufsteuerung. Die Zielrufsteuerung 25 umfasst einen zentralen Jobmanager 26 und zwei dezentrale Jobmanager, einen Konfigurationsmanager 29 sowie stellvertretend für alle vorhandenen Terminals em Terminal 30, welche über em Kommunikationsnetzwerk 31 miteinander m Verbindung stehen. Der Aufbau und die Funktion der dezentralen Jobmanagern 27,28 entsprechen im wesentlichen denjenigen des dezentalen Jobmanagers 4 aus dem ersten Ausfuhrungsbeispiels.

Die Zielrufsteuerung organisiert hier als sogenannte Gruppensteuerung den Verkehr einer Aufzugsgruppe mit zwei Aufzügen A und B in einem Gebäude mit Haltestellen auf sieben Stockwerken. Die Planungsaufgabe stellt sich dabei wie folgt dar:

Die Aufzugskabine A fahrt momentan nach oben; sie befindet sich momentan auf Stockwerk f2 und kann das Stockwerk f3 noch erreichen. Die Aufzugskabine B steht momentan auf Stockwerk f1. Aufzug A transportiert einen Passagier Pl mit Zutrittsbeschrankung auf Stockwerk 3 und 4, der als Ziel Stockwerk f7 angegeben hat, wahrend Aufzug B leer ist. In dieser Situation erscheint em neuer Passagier P2, der als VIP vorrangig vor allen anderen Passagieren befordert werden muss. Passagier P2 hat gerade seinen Transportauftrag von Stockwerk 3 nach Stockwerk f7 abgegeben.

Es ist also eine Zuteilung des Passagiers P2 auf einen der beiden im Beispiel bekannten Aufzuge A, B derart vorzunehmen, dass die Passagiere P1,P2 mit möglichst wenigen Stops befordert werden und die gewünschte Service-Anforderungen - VIP - und - Zutrittsbeschrankung - erfüllt sind.

Der zentrale Jobmanager 26 sammelt die Anfragen der Terminals zusammen mit den jeweils erfassten personenbezogenen Daten aus dem Konfigurationsmanager 29 als sogenannte Jobs, hier Job 1 bis Job 4, in einer Warteschlange, wie in Figur 6 dargestellt. Er wählt den ersten Job 1 aus der Schlange aus und sendet diesen an die dezentralen Jobmanager 27,28 der einzelnen Aufzüge. Jeder der dezentralen Jobmanager 27,28 der Aufzuge A,B ermittelt unabhängig von dem anderen mit Hilfe seines Planungssystems seine beste Fahrtfolgenlosung auf der Basis des vorgegebenen Optimierungskriteriums und sendet diese als Angebot an den zentralen Jobmanager 26 zurück. Der zentrale Jobmanager 26 prüft alle Angebote, wählt aus diesen das beste Angebot aus und bucht den Passagier auf den Aufzug mit dem besten Angebot. Die Identifikation des besten Aufzugs wird nach einer erfolgreichen Zuweisung an das Terminal 30 gesendet, auf dem der Job ursprunglich initiert worden ist. Das Terminal 30 fungiert damit lediglich als Display. Der Job 1 ist damit erledigt und wird gestrichen. Der Vorgang wieder holt sich nur mit dem Job 2 usw. , bis alle Jobs der Warteschlage abgearbeitet sind.

Jeder dezentrale Jobmanager 27,28 der Aufzug A, B erstellt für die als Job zur aktuellen Planungsaufgabe übermittelten registrierten Daten/ Informationen zunächst eine Situationsdarstellung, die an das jeweilige Planungssystem 21 übergeben wird. Die Situationsdarstellung enthält eine Zustandsbeschreibung 32 und eine Operatorbeschreibung.

Für Aufzug A werden in einer Objektdeklaration 33 die gemeldeten Passagiere P1,P2 und die Stockwerke fl bis f7 des Gebäudes dem Planungssystem bekannt gemacht. Für jedes Objekt wird eine typisierte Konstante eingeführt. Ausserdem erfolgt in der Objektdeklaration 33 für jeden Passagier P1,P2 eine Zuordnung zu einer oder mehreren Service- Anforderungen, wie z.B. VIP, conflict, gomg_dιrect, usw..

Die Service-Anforderungen sind jeweils im Rahmen der Passagiererkennung aus dem Konfigurationsmanager 29 bekannt und werden von dem zentralen Jobmanager 26 als Teils eines Jobs, bzw. einer Angebotsanfrage, an die dezentralen Jobmanager 27,28 der einzelnen Aufzuge A, B weitergeleitet. Bestimmte Service-Anforderungen für alle oder beliebig ausgewählte Passagiere können m Abhängigkeit vom Zustand der Aufzugsanlage oder des Gebäudes auch tageszeitabhangig aktivierbar vorgesehen werden. Ferner ist durch die Anwendung eines Planungssystems zur Fahrtfolgebestimmung eine flexible Gewichtung der einzelnen Service- Anforderungen, insbesondere der VIP-Anforderung, in Abhängigkeit des Verkehrsaufkommens darstellbar.

Hier sind folgende Service-Anforderungen vorgesehen:

• Einteilung aller Passagiere in zwei Gruppen conflιct_A und conflιct_B, die sich im Aufzug nie begegnen dürfen;

• Passagiere vom Typ never_alone, für die em Begleiter m Form eines

• Passagiers vom Typ attendant im Aufzug wahrend der Fahrt anwesend sein muss. Dabei ist es nicht zwingend erforderlich, dass wahrend der Fahrt immer derselbe Begleiter im Aufzug fahrt, sondern dieser kann auch wechseln;

• Passagiere vom Typ gomg_dιrect, die ohne Zwischenstop zu ihrem Ziel befordert werden;

• Passagiere vom Typ vip, die vorrangig vor allen anderen Passagieren befordert werden; • Passagiere, für die eine Zutrittsbeschrankung auf bestimmten Stockwerken formuliert ist;

• Passagiere vom Typ gomg_up, die ausschliesslich aufwärts transportiert werden; • Passagier vom Typ gomg_down, die ausschliesslich abwärts transportiert werden.

Em Passagier P1,P2 kann damit durchaus Gegenstand einer Vielzahl von Service-Anforderungen sein; allerdings sollten sich diese nicht widersprechen, damit der Passagier auch wirklich befordert werden kann. Em elementarer Widerspruch sind zum Beispiel zwei Passagiere Pl, P2 für die folgende Typisierung deklariert ist:

(Pl (either conflιct__A never_alone) ) (P2 (either conflιct_B attendant) )

Pl darf hier nicht allem im Aufzug fahren und gehört gleichzeitig zur Passagiergruppe A. Der einzige dem System bekannte mögliche Begleiter P2 gehört aber zur Passagiergruppe B, die Passagiergruppe A nie im Aufzug treffen darf. Eine Begleitung verletzt also die Ausschlussbedingung und Pl kann erst befordert werden, wenn dem System e anderer Begleiter bekannt wird, der nicht zur Gruppe B gehört.

Für Aufzug A enthalt die Objektdeklaration 33 den bereits fahrende Passagier Pl, e normaler Passagier, den neuen Passagier P2, em VIP, sowie alle 7 Stockwerke fl bis 7.

( : objects

⁽Pl passenger

( fl , f2 , f 3 , f 4 , f5 , f 6 , f7 - floor ) )

Unter der Annahme, dass von jedem Stockwerk aus jedes andere bedient werden kann, wird bei diesem Ausfuhrungsbeispiel auf eine ausdrückliche Beschreibung der Gebaudetopologie verzichtet .

Der aktuelle registrierte Transportauftrag 34 der Passagiere

Pl und P2 stellt sich dar als

( : mit (origm pl fl)

(origm p2 f3)

(destin pl f7)

(destin p2 f7 ) (boarded pl)

Dem Transportauftrag 34 liegt die Standardannahme zugrunde, dass Passagiere auf dem Stockwerk warten, wenn keine entsprechende boarded-Information vorliegt. Zutreffend bedeutet dies hier, dass Passagier P2 auf dem Stockwerk wartet. Die Zutrittsbeschrankung für Passagier Pl, stellt sich darin dar als

(no-access pl f3) (no-access pl f4)

Die aktuelle Position 35 der Aufzugskabine 2 des Aufzugs A ist als

(lift-at f2) ) m der Zustandsbeschreibung 32 ausgedruckt. Es werden alle aufgeführten Fakten als wahr, alle anderen als falsch gewertet .

Das Ziel 36 für das Planungssystem wird als

(:goal (forall ( ?p - passenger) (served ?p) )

formuliert .

Gesucht ist die kürzeste Folge von Stops, die alle Passagiere Pl, P2 m den Zustand served überfuhrt, der genau dann erreicht ist, wenn sie auf ihrem Zielstockwerk, jeweils Stockwerk f7, ausgestiegen sind.

Da in diesem Ausfuhrungsbeispiel nur eine minimale Stop Folge zu ermitteln ist, erhalt das Planungssystem auch nur einen sogenannten Stop-Operator 37, aus dem es einen gültigen Fahrtfolgeplan konstruieren kann. In Fig. 9 ist em Beispiel eines Stop-Operator 37 dargestellt. Wie zuvor bei der Zustandsbeschreibung 32, dient auch hier die Modeliierungsprache PDDL nach McDermott et al. 1998 zur Veranschaulichung. Der Stop-Operator 37 enthalt, eine Vorgabenbeschreibung 38 m der beschrieben ist, wann em Stop eines Aufzugs A,B auf einem Stockwerk fl bis f7 zulassig ist. Hier sind dies die Zutrittsbeschrankung - no- access -, welche entweder konkret für einen Passagier oder aber für eine Passagiergruppe definiert wird und eine Funktionsanweisung 39 m der festgelegt ist, auf welchem Stockwerk fl bis f7 eine Aufzugskabme bei einem zulassigen Stop halten soll und welche Auswirkung dieser Halt auf den aktuellen Zustand der Aufzugsanlage 18 hat. Vorbedingungen der Funktionsanweisung 39 stellen dabei die anwendungsspezifische Umsetzung der gewünschten Service- Anforderungen dar. Der in Figur 9 gezeigte komplexe Stop- Operator 37 ermöglicht es dem Planungssystem mit allen in der Passagier- und Objektdeklaration 33 eingeführten Service-Anforderungen umzugehen.

Für das hier beschriebene Planungsbeispiel sind nur die in Fig. 9 unterstrichenen Vorbedingungen des Operators 32 relevant, die die Bedingungen an einen Stop auf einem Stockwerk fl bis f7 unter der Anwesenheit von VIPs und Passagieren mit Zutrittsbeschrankung formulieren.

Die insoweit für jeden Aufzug A erstellte momentane Situationsdarstellung 32, wird an das zu dem Aufzug A gehörende Planungssystem weitergegeben.

Die gemass der Erfindung verwendeten geeigneten

Planungssysteme arbeiten unabhängig vom eigentlichen

Planungsproblem. Solche Planungssysteme sind aus anderen technischen Gebieten bereits bekannt.

Auch in diesem zweiten Ausfuhrungsbeispiel sucht jeweils ein IPP Planungssystem, wie es bekannt ist aus Koehler et al., 1997, Extending planning graphs to an ADL subset, erschienen in Steel, Proceedings of the 4^th European Conference on Planning, S. 273-285, Springer, Band 1348 of LNAI und unter http: //www. Informatik. uni-freiburg. de/~koehler/lpp . html verfugbar ist, eine gültige Folge von STOP Anweisungen, welche das Planungsziel 31 erfüllt. Es können auch andere Planungssysteme verwendet werden, sofern diese in der Lage sind, die momentane Situationsdarstellung gesamthaft zu erfassen und zu verarbeiten. Beim Losen einer konkreten Planungsaufgabe wählt das Planungssystem die in dem Fahrtfolgeplan zu verwendenden Operatoren der Operatorbeschreibung aus, hier den Stop- Operator 37. Treten Service-Anforderungen , wie z.B. VIP, going_direct , etc., in der Zustandsbeschreibung 32 auf, so überprüft das Planungssystem selbständig die entsprechende Vorbedingung der Funktionsanweisung 39 des Operators 37. Fehlt eine im Operator 37 als Vorbedingung enthaltene Service-Anforderung in der rufrelevanten Zustandsbeschreibung 32, so wird diese dann überflüssige Vorbedingung des Operators 37 automatisch ignoriert. Em Beispiel einer hier nicht berücksichtigten Service- Anforderungen ist die Vorbedingung -attendant-. Dann bestimmt das konkrete Werte für Operatorparameter sowie eine Anordnungsreihenfolge, in der Operatoren im Fahrtfolgeplan auftreten. Diese Anordnungsreihenfolge spezifiziert die Ausfuhrungsreihenfolge der Operatoren im Fahrtfolgeplan und damit die Fahrtfolge zur Bedienung des jeweiligen Zielrufs.

Für Aufzug A kann das Planungssystem keine Losung finden: Passagier P2 soll sofort befordert werden, d.h. der Aufzug A musste m f3 halten. Allerdings befindet sich Pl im Aufzug, der auf f3 keinen Zutritt hat. Ein Halt auf f3 ist also erst möglich nachdem Pl ausgestiegen ist, d.h. der Aufzug A musste zuerst Stockwerk f7 anfahren; dies ist wiederum nicht gestattet, da die VIP Bedingung erfordert, dass VIP vor allen anderen Passagieren befordert werden.

Für Aufzug B (Figur 8) ist die Situation 42 durch das Planungssystem problemlos losbar, da Aufzug B den Passagier Pl gar nicht kennt, weil dieser ja im Aufzug A unterwegs ist und nur den neuen Passagier P2 gemeldet bekommt. Die Ob ektdeklaration 43 für Aufzug B an das Planungssystem beinhaltet folglich auch nur den neuen Passagier P2, der durch die Service-Anforderung VIP typisiert ist sowie alle 7 Stockwerke fl bis f7.

(:objects

(p2 - vip )

(fl, f2,f3,f4,f5, f6,f7 - floor ))

Wiederum kann von jedem Stockwerk aus jedes andere bedient werden.

Der aktuelle Transportauftrag 44 des Passagiers P2 stellt sich dar als

(:ιnιt

(origm p2 f3) (destin p2 f7 ) .

Die aktuelle Positionsbeschreibung 45 der Aufzugskabine B ist in der Zustandsbeschreibung 42 als

(lift-at fl)

ausgedruckt .

Bei dem Aufzug B ist die Zielformulierung 46 für das Planungssystem identisch mit derjenigen des Aufzugs A. Sie wird zusammen mit der Objektdeklaration 43 und dem oben beschriebenen Stop Operator 37 als Teil der Situationsdarstellung 42 des Aufzugs B an das Planungssystem übergeben. Zur Planung der Fahrtfolge des Aufzugs B ist nur die Operator-Vorbedingung: Stop auf einem Stockwerk unter der Anwesenheit von VIP, relevant, weil die Zustandsbeschreibung 32 für Aufzug B auch nur die Service- Anforderung VIP an das Planungssystem übergibt. Alle übrigen in Form von Vorgaben 33 und Vorbedingungen der Funktionsanweisung 39 des STOP-Operators 37 vorgesehenen Service-Anforderungen bleiben bei dieser Planungssequenz unberücksichtigt und deshalb ohne Wirkung auf den Fahrtfolgeplan .

Das Planungssystem generiert ausgehend von diesem input für Aufzug B folgenden Fahrtfolgeplan

time step 1: (stop 3) time step 2: (stop 7),

der eine minimale Stopfolge zur erfolgreichen Beförderung von Passagier P2 darstellt.

Sind die Ergebnisse der Fahrtfolgeplanung der Aufzuge A, B beim zentralen Jobmanager 26 eingetroffen, dann bewertet dieser die beiden Fahrtfolgeangebote der Aufzuge A,B. Der Aufzug mit dem besten Angebot wird vom zentralen Jobmanager 26 ausgewählt. Die beste Lösung ist hier der einzig mögliche Fahrtfolgeplan des Aufzugs B. Folglich bucht der zentrale Jobmanager 26 den Passagier P2 auf den Aufzug B. Aufzug B aktualisiert nach Erhalt der Buchung auch den Fahrtfolgeplan; alle anderen Aufzuge fahren weiterhin nach ihrem bisherigen Plan.

Claims

Patentansprüche

1. Verfahren zur Fahrtfolgeplanung einer Aufzugsanlage, bei dem für über eine Sensorik erfasste

Fahrtanfragen eine bezüglich eines vorgebbaren Optimierungs-kriteriums optimale Fahrtfolge ermittelt wird, dadurch gekennzeichnet, dass em situationsbasiertes Suchverfahren zur Ermittlung der optimalen Fahrtfolge vorgesehen ist, welches bei jeder relevanten Änderung einer Planungsituation eine aktuelle Fahrtfolge ermittelt.

2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass bei jeder relevanten Änderung einer

Planungssituation planungsrelevante erfasste personen- und anlagenspezifische aktuelle Daten in einer für das Suchverfahren verstandlichen Form in einer Situationsdarstellung zusammengefasst werden.

3. Verfahren nach Anspruch 1 oder 2, dadurch gekennzeichnet, dass m der Situationsdarstellung der aktuelle Betriebszustand der Aufzugsanlage und der herzustellende Zielzustand der Aufzugsanlage sowie em oder mehrere elementare Zustandsubergange der Aufzugsanlage spezifizierende Operatoren dem Suchverfahren zugeleitet werden.

4. Verfahren nach Anspruch 3, dadurch gekennzeichnet, dass planungsrelevante erfasste personen- und anlagenspezifische Daten in einer für das Suchverfahren verstandlichen Form m einer Situationsdarstellung zusammengefasst werden, wobei die Operatoren modular aufgebaut sind, und steuerungstechnische Anweisungen bezuglich Service Anfoderungen beinhalten.

5. Verfahren nach Anspruch 4, dadurch gekennzeichnet, dass bei einer Aufzugsgruppe mehrere Service- Anforderungen gleichzeitig von mehreren Aufzügen der Aufzugsgruppe bedient werden.

6. Zielrufsteuerung für Aufzuge zur Bestimmung der Fahrtfolge einer oder mehrerer Aufzugkabmen einer Aufzuganlage mit mindestens einer Rufregistriereinrichtung zum Erfassen von Fahrtanfragen, einer Verarbeitungseinheit zum Ermitteln einer bezüglich eines gegebenen Optimierungskriteriums optimalen Fahrtfolge für registrierte Fahrtanfragen, dadurch gekennzeichnet, dass als Verarbeitungseinheit em Planungssystem vorgesehen ist, welches die situationsspezifisch optimale Fahrtfolge ermittelt.

7. Zielrufsteuerung nach Anspruch 6, dadurch gekennzeichnet, dass das Planungssystem Teil eines Multi-Agentensystem ist, wobei die Rufregistreiremπchtung über em

Kommunikationsneztwerk mit dem Planungssystem wirkverbunden ist.

8. Aufzugsanlage bestehend aus mindestens einem Aufzug mit einem Deck und mindestens einem Aufzug mit zwei

Decks und einer Zielrufsteuerung nach Anspruch 6.