PatentDe  


Dokumentenidentifikation EP1276691 22.09.2005
EP-Veröffentlichungsnummer 0001276691
Titel ZIELRUFSTEUERUNG FÜR AUFZÜGE
Anmelder Inventio AG, Hergiswil, Nidwalden, CH
Erfinder KOEHLER, Jana, CH-6006 Luzern, CH;
SCHUSTER, Kilian, CH-6275 Ballwil, CH
Vertreter derzeit kein Vertreter bestellt
DE-Aktenzeichen 50107119
Vertragsstaaten AT, BE, CH, CY, DE, DK, ES, FI, FR, GB, GR, IE, IT, LI, LU, MC, NL, PT, SE, TR
Sprache des Dokument DE
EP-Anmeldetag 29.03.2001
EP-Aktenzeichen 019149400
WO-Anmeldetag 29.03.2001
PCT-Aktenzeichen PCT/CH01/00205
WO-Veröffentlichungsnummer 0001072621
WO-Veröffentlichungsdatum 04.10.2001
EP-Offenlegungsdatum 22.01.2003
EP date of grant 17.08.2005
Veröffentlichungstag im Patentblatt 22.09.2005
IPC-Hauptklasse B66B 1/18

Beschreibung[de]

Die Erfindung betrifft eine Zielrufsteuerung für Aufzüge 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 - , - Tür auf - und - Tür zu -.

In grösseren 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 Kabinenknöpfe gedrückt haben. Die Zuweisung eines Stockwerkrufs auf einen Aufzug gestaltet sich damit problematisch, da permanent Unsicherheit über die anzufahrenden Ziele besteht.

In der Aufzugsindustrie 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". Solche Beispiele werden in GB 2311148 und in JP 02052875 beschrieben. Die Wirkung solcher Verfahren ist jedoch sehr beschränkt, weil lediglich grobe Verkehrsmuster, wie zum Beispiel die morgendliche Aufwärtsspitze, mit einiger Sicherheit identifizierbar sind. Aber unklar bleibt etwa, wohin ein Passagier möchte, wenn er beispielsweise an einem Montagmorgen um 10.37 Uhr im 10. Stock eines Bürohochhauses einen Aufzug ruft.

Ein anderer Ansatz zur Lösung 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 telefonähnliche 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. Hält 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 Knöpfe 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 A1 bekanntes Beispiel einer solchen Zielrufsteuerung ist darüberhinaus in 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 zusätzlicher Service-Anforderungen, bei der Ermittlung der optimalen Transportmöglichkeit 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 während der Ausführung einer Fahrtfolge neue zusätzliche Fahrtanfragen auf, so wird die bereits berechnete Fahrtfolge dahingehend modifiziert. Dabei können aber nur einfache Modifikationen vorgenommen werden, was dazu führen 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 Zusammenhänge einzelner Steuerungsoptionen, sogenannte Service-Anforderungen, nicht immer logisch und lückenlos auszudrücken. 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 nachträglich nur unter erheblichem Aufwand an unterschiedliche kundenspezifische Steuerungsbedürfnisse 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 Transportbedürfnisse von Passagieren berücksichtigt.

Zur Lösung 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 vorrichtungsmässige Lösung ist durch eine Zielrufsteuerung nach Definition des Patentanspruchs 6 gegeben, welche eine Organisation des Verkehrsaufkommens unter Verwendung eines sogenannten Planungssystem vorsieht.

Erfindungsgemäss 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 erfindungsgemässe 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 Ausführung einer Fahrtfolge oder dergleichen, im Extremfall nach jedem ausgeführten Fahrtfolgeschritt eine völlig neue aktuelle Fahrtfolge bestimmt wird, und der Aufzugsantrieb diese dann ausführt.

Bei jeder Registrierung einer relevanten Änderung, beispielsweise bei jedem Zielruf, werden jeweils der momentane Betriebszustand und der gewünschte Zielbetriebszustand der Aufzugsanlage auf der Basis von Fakten in einer Zustandsbeschreibung deklarativ zusammengefasst. Diese in der Zustandsbeschreibung dargestellte zu erreichende Zustandsänderung 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 Zustandsänderung bei Ausführung des Fahrtfolgeplans erreicht werden kann.

Eine Aufzugsanlage mit einer Fahrtfolgeplanung gemäss der Erfindung führt 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 Rechenleistung und Speicherbedarf beschränkt sind. Innerhalb dieser beschränkten 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.

Gemäss einer vorteilhaften Ausführung des erfindungsgemässen Suchverfahrens wird die Zustandsbeschreibung vorzugsweise zusammen mit einer Operatorenbeschreibung in der Situationsdarstellung in übersetzter Form dem Planungssystem zugeleitet.

Die Operatorenbeschreibung wird zur Konfigurationszeit, vorzugsweise bei der Installierung des Systems beim Kunden der erfindungsgemässen Zielrufsteuerung mitgeteilt. Sie enthält Operatoren, welche elementare Zustandsübergänge der Aufzugsanlage spezifizieren. Die Operatoren bilden als Elementarbausteine für die zu konstruierende Fahrtfolgelösung die Grundlage des ermittelten Fahrtfolgeplans. Bei jeder Zielrufzuteilung bzw. beim Lösen einer konkreten Planungsaufgabe wählt das Planungssystem die in der Lösung zu verwendenden Operatoren aus der Operatorenbschreibung aus, bestimmt konkrete Werte für Operatorparameter sowie eine Anordnungsreihenfolge, in der Operatoren im Fahrtfolgeplan auftreten. Diese Anordnungsreihenfolge spezifiziert die Ausführungsreihenfolge der Operatoren im Plan, sprich, die Fahrtfolge.

Im Unterschied zu bisher fest programmierten Zuteilungsalgorithmen 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 späteren Zeitpunkt auf, so muss dem Planungssystem lediglich eine entsprechende Situationsdarstellung mitgeteilt werden, in dem diese Service-Anforderungen formuliert sind. Das System kann dann solche Aufgaben sofort lösen. Treten Service-Anforderungen auf, für die keine Operatoren vorgesehen sind, so sichert die Modularität der Operatoren in einem Planungssystem, dass auf sehr einfache Weise neue Operatoren hinzugefügt oder weggenommen werden können, ohne dass die bereits vorhandenen Operatoren davon beeinflusst werden. Aufzugsanlagen können damit durch das Verändern der Operatormenge, die für die Steuerung zur Verfügung stehen, wie auch durch die Definition der Operatoren selbst, sehr einfach und flexibel an sich ändernde Kundenbedürfnisse im Hinblick auf die Verkehrsorganisation angepasst werden.

Bei der Steuerung einer Gruppe von Aufzügen mit der erfindungsgemässen Zielrufsteuerung erfolgt die Berücksichtigung der Service-Anforderungen im laufenden 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 ausführen 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 Aufzüge. Die Terminals richten ihre Transportanfragen an den zentralen Jobmanager. Der Jobmanager fragt bei jedem der Jobmanager der einzelnen Aufzüge 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 Transportaufträge, 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, läuft. Die Organisation der Jobs erfolgt bei einem zentralen Jobmanager in einer Warteschlange, einer sogenannten "first in-first out" Datenstruktur. Diese Organisation ist einfach und sichert eine eindeutige Abarbeitungsreihenfolge.

Bei dem zentralen Konzept haben die Terminals lediglich die Zielrufeingabe 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 Aufzüge 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 Aufzüge erfolgt vorzugsweise über Verwendung von Kontraktnetzprotokollen. Die Jobmanager der einzelnen Aufzüge 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.

Gemäss 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. Fällt zum Beispiel eine Schachttür 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 ausführen 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 gewährleistet ist.

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

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

  • Fig.1, 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 gemäss dem ersten Ausführungsbeispiels;
  • Fig.4, eine graphische Darstellung des ermittelten Fahrtfolgeplan gemäss dem ersten Ausführungsbeispiel;
  • Fig.5, schematisch den Aufbau eines zweiten Ausführungsbeispiels 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 Ausführungsbeispiel;
  • Fig.8, eine momentane Zustandsbeschreibung des Aufzugs B aus dem zweiten Ausführungsbeispiel;
  • Fig.9, den Aufbau eines Operators mit Stop-Anweisung, wie er im zweiten Ausführungsbeispiel zur Anwendung kommt.

Figur 1 zeigt schematisch den Aufbau einer erfindungsgemässen 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 Zielrufeingabe, sogenannte Terminals 3.1,3.2,3.3, mit einem dezentralen Jobmanager 4 in Verbindung stehen.

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

Bekannte Beispiele für Architekturen zur spontanen Vernetzung sind Jini, Universal Plug and Play oder Bluetooth. In solch einem Kommunikationsneztwerk 2 können sich netzwerkfähige Geräte, sogenannten Agenten, anmelden und miteinander agieren, ohne dass eine Konfiguration oder Administration nötig ist. Die Integration aller dieser Geräte und der darauf implementierten Dienste läuft vollautomatisch ab. Die wichtigsten Methoden eines solchen Kommunikationsnetzwerks 2 sind - register - , - lookup - und- notify -.

  • Durch Registration melden sich die einzelnen Geräte im Netz an und machen ihre Dienste bekannt.
  • Durch Lookup kann ein Gerät ein anderes Gerät oder einen benötigten Dienst finden.
  • Durch Notification kann sich ein Gerät bei einem anderen für die Benachrichtigung über das Eintreten bestimmter Ereignisse anmelden.

In einer Aufzugsgruppe melden sich vorzugsweise Terminals, Antriebe, Kabinentüren, zentrale Jobmanager und/ oder dezentrale Jobmanager als netzwerkfähige Geräte an.

  • Terminals melden sich mit ihrer Stockwerksposition und XY-Koordinate im Netz an und informieren sich über alle vorhandenen Jobmanager.
  • Antriebe repräsentieren die physische Komponente der Aufzugssteuerung. Sie stellen die Information zur Verfügung, welche Stockwerke sie anfahren können, wieviele Schachttüren 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.
  • Kabinentüren melden sich mit Information darüber zu welchem Antrieb sie gehören, auf welchem Deck sie sich befinden und auf welcher Seite sie öffnen. 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 Tür 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 Tür
  • 4 Doppeldeckern, wobei ein Deck mit einer Tür 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 Aufzüge ist in 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 Ein- und Aussteigen der Passagiere über alle vorhandenen Decks,
  • der Taxifahrer des Jobmanagers sendet bei einem Stop die Türöffnungskommandos an alle Türen, die zu Stockwerken öffnen, 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 Türmanager 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 Gebäudelayout, wie zum Beispiel die Anzahl der Stockwerke, Zutrittszonen, Unterteilung der Passagiere in Passagiergruppen, Zutrittsrechte, Service Anforderungen, usw. und Passagierinformationen 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, in die der Broker 6 neue Passagiere einträgt, während der Beobachter 10 beförderte 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, trägt 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 führt 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 stützt 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 Auslösen 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 nachgeführt wird.

Der Taxifahrer 8 fährt 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 planmässig 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, hängt davon ab, in welchem Ausführungszustand 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 führt die Fahr- und Stop-Kommandos aus, die er vom Taxifahrer 8 erhält, ausserdem lernt er die Fahrzeiten des Aufzugs zwischen den einzelnen Stockwerken. Er stellt die Fahrzeitentabelle dem Planer 5 für die Optimierung zur Verfügung und meldet auch, wo der Aufzug sich aktuell befindet und in welche Richtung er fährt oder ob er gerade anhält.

Der Türmanager 7 verwaltet alle Türen des Aufzugs und überwacht, dass die Türen korrekt öffnen und schliessen. Dabei können auf verschiedenen Seiten einer Kabine Türen vorhanden sein. Er bestimmt auch die Türöffnungs- 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 ausführt. 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, während 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 Rückbestätigung 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 erhält das Terminal eine entsprechende Rückmeldung.

Figur 2 zeigt einen Pool von angefragten und offerierten Jobs Job1 bis Job4 bei einem dezentralen Jobmanager 4. Jedes Terminal 1, 2 hat in 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 Aufzüge, 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 Aufzüge 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 erfindungsgemässen Zielrufsteuerung gemäss Figur 1 ist nachfolgend am Beispiel eines Planungsproblems einer Aufzugsanlage mit nur einem einzelnen Aufzug mit eintüriger Kabine beschrieben, der ein hier nicht dargestelltes Gebäude mit Haltestellen auf sieben Stockwerken f1 bis f7 bedient. Die Aufzugkabine steht momentan in Stockwerk f4. Ein Passagier P1, wartet auf Stockwerk f2 und möchte ins Stockwerk f7, ein zweiter Passagier P2 befindet sich bereits in der Kabine und möchte von Stockwerk f1 ins Stockwerk f5. Es ist die Fahrtfolge der Kabine erfindungsgemäss 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 in Verbindung mit dem Konfigurationsmanager 11 werden die Eigenschaften der Passagiere P1, P2 und insbesondere die Zielrufe, der Passagiere P1, P2 als Eingangsgrössen der Zielrufsteuerung 1 an den Broker 6 weitergeleitet, der sie in die Situationsdarstellung des Planers 5 einträgt, wie in Figur 2 gezeigt.

So werden bei jedem Planungsvorgang, der z.B. durch Registrierung eines Zielrufs gestartet wird, der ermittelte Betriebszustand und der gewünschte Zielzustand, also die zu erreichende Zustandsänderung des Aufzugs in einer für das Planungssystem verständlichen Zustandsbeschreibung 14 deklarativ zusammengestellt, die in Figur 3 dargestellt ist.

Die hier in Figur 3 abgebildete Zustandsbeschreibung 14 ist in der Plandarstellungssprache PDDL nach McDermott er al. 1998, ausgedrückt. Dem Fachmann sind auch andere Modellierungssprachen bekannt, die sich hinsichtlich ihrer Ausdrucksmächtigkeit 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 mächtige Planungsalgorithmen zur Verfügung stellt.

In der in Figur 3 dargestellten Zustandsbeschreibung 14 werden dem Planungssystem 3 in einer Objektdeklaration 15 zunächst die gemeldeten Passagiere P1, P2 und die Stockwerke f1 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 P1, der sich bereits in der Kabine befindende Passagier P2 und alle sieben Stockwerke f1 bis f7.

(:objects

(p1   - passenger)

(p2   - passenger)

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

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

  • (upper f1 f2)   (upper f1 f3)   (upper f1 f4)
  • (upper f1 f5)   (upper f1 f6)   (upper f1 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 fj oberhalb des Stockwerks fi liegt. Die Darstellung der Gebäudetopologie ist nicht zwingend erforderlich. In Vereinfachung kann in anderen Ausführungen 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 P1 und P2 stellt sich aus Einstiegsstockwerken, origin, und Zielstockwerken , destin, dar als

(:init (origin p1 f2)

(origin p2 f1)

(destin p1 f7)

(destin p2 f5)

(boarded p2) .

Der Transportauftrag 17 enthält 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 Zustände: wartend/waiting, fahrend/boarded, bedient/served ein, die hier folgendermassen definiert sind:

  • Wartend/ waiting: Der Passagier wartet vor der Aufzugstür. Hier hat der Aufzug zuerst am Ausgangsort, origin, des Passagiers und erst danach an dem vom Passagier angegebenen Zielstockwerk, destin, 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 P1 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 ausgedrückt 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- überführt, 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 Ausführungsbeispiel werden in der Operatorenbeschreibung ein Stop-Operator sowie ein Operator zum Aufwärtsfahren -up- und ein Operator zum Abwärtsfahren -down- zur Modellierung der Zustandsübergänge 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 lässt. Gegebenenfalls ändert sich dadurch bei entsprechender Definition der Parameter das Wesen der Erfindung nicht. In PDDL-Syntax gemäss McDermott et al. 1998 steht hier folgender Stop Operator zur Verfügung:

(define (domain miconic)

(:requirements :adl)

   (:types passenger - object

      floor - object)

(:predicates

(origin ?person - passenger ?floor - floor)

(destination ?person - passenger ?floor - floor)

(boarded ?person - passenger)

(served ?person - passenger)

(lift-at ?floor - floor))

(:action stop

   :parameters (?f - floor)

   :precondition (and (lift-at ?f))

:effect (and (forall (?p - passenger) (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 Aufwärtsfahren -up- stellt sich dar als:

(:action up

   :parameters (?f1 - floor ?f2 - floor)

   :precondition (and (lift-at ?f1) (upper ?f1 ?f2))

   :effect (and (lift-at ?f2) (not (lift-at ?f1))))

Der Operator zum Abwärtsfahren -down- ist ausgedrückt als:

(:action down

   :parameters (?f1 - floor ?f2 - floor)

   :precondition (and (lift-at ?f1) (upper ?f2 ?f1))

   :effect (and (lift-at ?f2) (not (lift-at ?f1))))

Der stop-Operator signalisiert der Steuerung des Antriebs 9 des Aufzugs, dass die Kabine auf einem bestimmten Stockwerk f1 bis f7 anzuhalten hat. Der stop-Operator ist im hier dargestellten ersten Ausführungsbeispiel so definiert, dass er das Öffnen und Schliessen der Türen mit beinhaltet. Das Öffnen und Schliessen der Kabinentüren kann aber auch als separate zusätzliche Grundanweisung an den Türmanager 7 eines Aufzugs berücksichtigt werden oder es kann der stop-Operator dahingehend verfeinert werden, dass ein Aufzug auch die Türen öffnen und schliessen kann.

Die Operatoren zum Aufwärtsfahren -up- und Abwärtsfahren - down- geben die steuerungstechnische Anweisung an die Antriebssteuerung, den Antrieb 9 in die entsprechende Richtung in Gang zu setzen. Die zeitliche Abfolge, in 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 planmässigen Stop der Aufzugskabine auf einem Stockwerk alle Passagiere, welche auf diesem Stockwerk - origin- warten, um transportiert zu werden in 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 in 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 Ausführungsbeispiel sucht ein IPP Planungssystem, wie es aus Koehler et al., 1997, Extending planning graphs to an ADL subset, erschienen in Steel, S, Proceedings of the 4th European Conference on Planning, 273-285 Springer, Band 1348 of LNAI, verfügbar unter http://www.informatik.uni-freiburg.de/~koehler/ipp.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.

Grundsätzlich wählt das Planungssystem 5 bei Eingabe der Zustandsbeschreibung 14 selbständig auf Basis der über die Operatorenbeschreibung zur Verfügung 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 Zustandsänderung bewirken.

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

  • Time step 0: up f4 f5
  • Time step 1: stop f5
  • Iime step 2: down f5 f2
  • Time step 3: stop f2
  • 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 P1 auf den Transport des bereits gebuchten Passagiers auswirkt und teilt dem Terminal das Transportangebot mit.

Bei dem hier beschriebenen Ausführungsbeispiel liegt nur ein Zielruf zur Planung vor. Folglich ist nur für einen Job ein 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 entfällt auch die Rückbestätigung 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 fährt diesen aktuellen Fahrtfolgeplan 20 ab, d.h. er sendet die entsprechenden Kommandos in 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-fährt. Dort hält die Aufzugskabine gemäss Schritt 1 -stop f5- an und die Kabinentüre in vorgegebener Zeit öffnet und schliesst, so dass der Passagier P2 aussteigt und damit bedient, served, ist. Im Schritt 2 fährt die Aufzugskabine abwärts von f5 nach f2 -down f5 f2- und hält im Schritt 3 auf Stockwerk f2 -stop f2-. Dort steigt Passagier P1 zu. Im Schritt 4 fährt der Aufzug aufwärts von Stockwerk f2 nach Stockwerk f7 -up f2 f7- und hält im letzten Schritt 5 auf Stockwerk f7 -stop f7-. Dort kann nun auch Passagier P1 aussteigen. Durch diese Fahrtfolge 13 werden alle Passagiere P1,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 ausführt, überwacht der Beobachter 10 den Zustand der Aufzugsanlage und führt 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 P1, 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 P1 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 ändern bevor er komplett ausgeführt ist, wird erfindungsgemäss 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 Ausführungsbeispiels der erfindungsgemässen Zielrufsteuerung. Die Zielrufsteuerung 25 umfasst einen zentralen Jobmanager 26 und zwei dezentrale Jobmanager, einen Konfigurationsmanager 29 sowie stellvertretend für alle vorhandenen Terminals ein Terminal 30, welche über ein Kommunikationsnetzwerk 31 miteinander in Verbindung stehen. Der Aufbau und die Funktion der dezentralen Jobmanagern 27,28 entsprechen im wesentlichen denjenigen des dezentalen Jobmanagers 4 aus dem ersten Ausführungsbeispiels.

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 fährt 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 P1 mit Zutrittsbeschränkung auf Stockwerk 3 und 4, der als Ziel Stockwerk f7 angegeben hat, während Aufzug B leer ist. In dieser Situation erscheint ein neuer Passagier P2, der als VIP vorrangig vor allen anderen Passagieren befördert 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 Aufzüge A,B derart vorzunehmen, dass die Passagiere P1,P2 mit möglichst wenigen Stops befördert werden und die gewünschte Service-Anforderungen - VIP - und - Zutrittsbeschränkung - 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 Aufzüge A,B ermittelt unabhängig von dem anderen mit Hilfe seines Planungssystems seine beste Fahrtfolgenlösung 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 ursprünglich 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 Aufzüg 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 f1 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, going_direct, 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 Aufzüge A,B weitergeleitet. Bestimmte Service-Anforderungen für alle oder beliebig ausgewählte Passagiere können in Abhängigkeit vom Zustand der Aufzugsanlage oder des Gebäudes auch tageszeitabhängig 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 conflict_A und conflict_B, die sich im Aufzug nie begegnen dürfen;
  • Passagiere vom Typ never_alone, für die ein Begleiter in Form eines
  • Passagiers vom Typ attendant im Aufzug während der Fahrt anwesend sein muss. Dabei ist es nicht zwingend erforderlich, dass während der Fahrt immer derselbe Begleiter im Aufzug fährt, sondern dieser kann auch wechseln;
  • Passagiere vom Typ going_direct, die ohne Zwischenstop zu ihrem Ziel befördert werden;
  • Passagiere vom Typ vip, die vorrangig vor allen anderen Passagieren befördert werden;
  • Passagiere, für die eine Zutrittsbeschränkung auf bestimmten Stockwerken formuliert ist;
  • Passagiere vom Typ going_up, die ausschliesslich aufwärts transportiert werden;
  • Passagier vom Typ going_down, die ausschliesslich abwärts transportiert werden.

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

  • (P1 (either conflict_A never_alone))
  • (P2 (either conflict_B attendant))

P1 darf hier nicht allein 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 P1 kann erst befördert werden, wenn dem System ein anderer Begleiter bekannt wird, der nicht zur Gruppe B gehört.

Für Aufzug A enthält die Objektdeklaration 33 den bereits fahrende Passagier P1, ein normaler Passagier, den neuen Passagier P2, ein VIP, sowie alle 7 Stockwerke f1 bis f7.

(:objects

(p1   - passenger )

(p2   - vip )

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

Unter der Annahme, dass von jedem Stockwerk aus jedes andere bedient werden kann, wird bei diesem Ausführungsbeispiel auf eine ausdrückliche Beschreibung der Gebäudetopologie verzichtet.

Der aktuelle registrierte Transportauftrag 34 der Passagiere P1 und P2 stellt sich dar als

(:init (origin p1 f1)

(origin p2 f3)

(destin p1 f7)

(destin p2 f7)

(boarded p1)

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 Zutrittsbeschränkung für Passagier P1, stellt sich darin dar als

(no-access p1 f3)

(no-access p1 f4)

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

(lift-at f2))

in der Zustandsbeschreibung 32 ausgedrückt. 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 P1, P2 in den Zustand served überführt, der genau dann erreicht ist, wenn sie auf ihrem Zielstockwerk, jeweils Stockwerk f7, ausgestiegen sind.

Da in diesem Ausführungsbeispiel nur eine minimale Stop Folge zu ermitteln ist, erhält das Planungssystem auch nur einen sogenannten Stop-Operator 37, aus dem es einen gültigen Fahrtfolgeplan konstruieren kann. In Fig. 9 ist ein Beispiel eines Stop-Operator 37 dargestellt. Wie zuvor bei der Zustandsbeschreibung 32, dient auch hier die Modellierungsprache PDDL nach McDermott et al. 1998 zur Veranschaulichung. Der Stop-Operator 37 enthält, eine Vorgabenbeschreibung 38 in der beschrieben ist, wann ein Stop eines Aufzugs A,B auf einem Stockwerk f1 bis f7 zulässig ist. Hier sind dies die Zutrittsbeschränkung - no-access -, welche entweder konkret für einen Passagier oder aber für eine Passagiergruppe definiert wird und eine Funktionsanweisung 39 in der festgelegt ist, auf welchem Stockwerk f1 bis f7 eine Aufzugskabine bei einem zulässigen 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 f1 bis f7 unter der Anwesenheit von VIPs und Passagieren mit Zutrittsbeschränkung formulieren.

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

Die gemäss der Erfindung verwendeten geeigneten Planungssysteme arbeiten unabhängig vom eigentlichen Planungsproblem. Solche Planungssysteme sind aus anderen technischen Gebieten bereits bekannt.

Auch in diesem zweiten Ausführungsbeispiel 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 4th European Conference on Planning, S. 273-285, Springer, Band 1348 of LNAI und unter http://www.informatik.uni-freiburg.de/~koehler/ipp.html verfügbar 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 Lösen 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. Ein 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 Ausführungsreihenfolge der Operatoren im Fahrtfolgeplan und damit die Fahrtfolge zur Bedienung des jeweiligen Zielrufs.

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

Für Aufzug B (Figur 8) ist die Situation 42 durch das Planungssystem problemlos lösbar, da Aufzug B den Passagier P1 gar nicht kennt, weil dieser ja im Aufzug A unterwegs ist und nur den neuen Passagier P2 gemeldet bekommt. Die Objektdeklaration 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 f1 bis f7.

(:objects

(p2   - vip)

(f1,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

(:init

(origin p2 f3)

(destin p2 f7).

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

(lift-at f1)

ausgedrückt.

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 Aufzüge A,B beim zentralen Jobmanager 26 eingetroffen, dann bewertet dieser die beiden Fahrtfolgeangebote der Aufzüge 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 Aufzüge fahren weiterhin nach ihrem bisherigen Plan.


Anspruch[de]
  1. Verfahren zur Fahrtfolgeplanung einer Aufzugsanlage, die mindestens einen Aufzug umfasst, bestehend aus:
    • a. dem Registrieren von Zielrufen durch eine an Stockwerken der Aufzugsanlage angeordnete Sensorik (3.1,3.2,3.3),

      gekennzeichnet durch die folgende Verfahrenschritte:
    • b. Eintragen von Zielrufen in eine Situationsdarstellung (12) für jeden Aufzug, welche Situationsdarstellung (12) den momentanen Betriebszustand (18) und die Verkehrssituation (15,17) des Aufzugs definiert,
    • c. Berechnen einer optimale Fahrtfolge für jede Situationsdarstellung (12) unter Berücksichtigung eines vorgewählten Optimierungskriteriums wie minimale Warte- und/oder Bedien- und/oder Fahrtzeiten der Passagiere, und
    • d. Buchen des Aufzugs, der der besten der jeweiligen optimalen Fahrtfolge entspricht, um den Zielruf zu erfüllen.
  2. Verfahren nach Anspruch 1, dadurch gekennzeichnet,

    dass Zielrufe in einer Aufzugsanlage mit mehreren Aufzügen registriert werden,

    dass diese registrierten Zielrufe an einen zentralen Jobmanager (26) übermittelt werden,

    dass jeder Aufzug einen Jobmanager (27,28) aufweist, welche vom zentralen Jobmanager (26) für jeden registrierten Zielruf um ein Transportangebot angefragt werden,

    dass von diesen Jobmanagern (27,28) der Anfrage entsprechende Transportangebote an den zentralen Jobmanager (26) übermittelt werden, und

    dass vom zentralen Jobmanager (26) aus den übermittelten Transportangeboten für einen registrierten Zielruf eine bezüglich des Optimierungskriteriums optimale Fahrtfolge gebucht wird.
  3. Verfahren nach Anspruch 1, dadurch gekennzeichnet,

    dass Zielrufe in einer Aufzugsanlage mit mehreren Aufzügen registriert werden,

    dass jeder Aufzug einen Jobmanager (4) aufweist, welche Jobmanager (4) für jeden registrierten Zielruf um ein Transportangebot angefragt werden,

    dass von den Jobmanagern (4) der Anfrage entsprechende Transportangebote gemacht werden, und

    dass aus diesen Transportangeboten für einen registrierten Zielruf eine bezüglich des Optimierungskriteriums optimale Fahrtfolge gebucht wird.
  4. Verfahren nach einem der Ansprüche 1 bis 3, dadurch gekennzeichnet, dass Zielrufe an Registriereinrichtungen (3.1,3.2,3.3) der Stockwerke registriert werden, und

    dass ein Aufzug, welcher einer gebuchten Fahrtfolge entspricht, an der Registriereinrichtung (3.1,3.2,3.3) angezeigt wird, welche den Zielruf registriert hat.
  5. Verfahren nach einem der Ansprüche 1 bis 4, dadurch gekennzeichnet,

    dass die Situationsdarstellung Operatoren enthält, welche elementaren Zustandsübergänge (16) der Aufzugsanlage spezifizieren,

    dass zu verwendende Operatoren bezüglich des Optimierungskriteriums auswählt werden,

    dass für diese Operatoren konkrete Werte für Operatorenparameter bestimmt werden, und

    dass eine Anordnungsreihenfolge, in der diese Operatoren in der Fahrtfolgeplanung auftreten, bestimmt wird.
  6. Verfahren nach Anspruch 5, dadurch gekennzeichnet,

    dass Operatoren ausgewählt werden, welche steuerungstechnische Anweisungen bezüglich Service-Anforderungen beinhalten.
  7. Zielrufsteuerung für eine Aufzugsanlage zur Bestimmung der Fahrtfolge einer oder mehrerer Aufzüge der Aufzugsanlage mit Registriereinrichtungen (3.1,3.2,3.3) an Stockwerken der Aufzugsanlage zum Registrieren von Zielrufen,

    dadurch gekennzeichnet, dass

    eine Verarbeitungseinheit (4) vorgesehen ist, die für jeden Aufzug eine Situationsdarstellung (12) und einen Planer (5) umfasst, welche Situationsdarstellung (12) den momentanen Betriebszustand (18) und die Verkehrssituation (15,17) des Aufzugs definiert, und welcher Planer (5) eine optimale Fahrtfolge für jede Situationsdarstellung (12) berechnet unter Berücksichtigung eines vorgewählten Optimierungskriteriums wie minimale Warte- und/oder Bedien- und/oder Fahrtzeiten der Passagiere.
  8. Zielrufsteuerung nach Anspruch 7, dadurch gekennzeichnet,

    dass die Situationsdarstellung Parametern über den aktuellen Betriebszustand der Aufzugsanlage und den herzustellenden Zielzustand der Aufzugsanlage enthält, und

    dass die Situationsdarstellung Parametern enthält, welche elementaren Zustandsübergänge (16) der Aufzugsanlage spezifizieren.
  9. Zielrufsteuerung nach Anspruch 7 oder 8, dadurch gekennzeichnet,

    dass die Aufzugsanlage mehrere Aufzüge aufweist,

    dass ein zentraler Jobmanager (26) vorgesehen ist, welcher über ein Kommunikationsnetzwerk von den Registriereinrichtungen (3.1,3.2.3.3) alle registrierten Zielrufe empfängt,

    dass jeder Aufzug einen Jobmanager (27,28) aufweist,

    dass der zentrale Jobmanager (26) diese Jobmanager (27,28) über das über das Kommunikationsnetzwerk (2) für jeden registrierten Zielruf um ein Transportangebot anfragt,

    dass diese Jobmanagern (27,28) der Anfrage entsprechende Transportangebote über das Kommunikationsnetzwerk (2) an den zentralen Jobmanager (27,28) übermitteln, und

    dass der zentrale Jobmanager (26) für einen registrierten Zielruf aus den übermittelten Transportangeboten einer bezüglich des Optimierungskriteriums optimalen Fahrtfolge bucht.
  10. Zielrufsteuerung nach Anspruch 7 oder 8, dadurch gekennzeichnet,

    dass die Aufzugsanlage mehrere Aufzüge aufweist,

    dass jeder Aufzug einen Jobmanager (4) aufweist,

    dass eine Registriereinrichtung (3.1,3.2,3.3) diese Jobmanager (4) über ein Kommunikationsnetzwerk (2) für jeden registrierten Zielruf um ein Transportangebot anfragt,

    dass diese Jobmanager (4) der Anfrage entsprechende Transportangebote über das Kommunikationsnetzwerk (2) an die anfragende Registriereinrichtung (3.1,3.2,3.3) übermitteln, und

    dass diese Registriereinrichtung (3.1,3.2,3.3) für den registrierten Zielruf aus diesen Transportangeboten einer bezüglich des Optimierungskriteriums optimalen Fahrtfolge bucht.
  11. Zielrufsteuerung nach Anspruch 9 oder 10, dadurch gekennzeichnet,

    dass eine Registriereinrichtung (3.1,3.2,3.3) welche einen Zielruf registriert hat, den Aufzug anzeigt, welcher einem gebuchten Fahrtfolge entspricht.
  12. Aufzugsanlage bestehend aus mindestens einem Aufzug mit einem Deck und mindestens einem Aufzug mit zwei Decks und einer Zielrufsteuerung nach einem der Ansprüche 7 bis 11.
Anspruch[en]
  1. Method for journey sequence planning of a lift installation, which comprises at least one lift, consisting of:
    • a. registration of destination calls by a sensor system (3.1, 3.2, 3.3) arranged at storeys of the lift installation,

      characterised by the following method steps:
    • b. entry of destination calls in a situation representation (12) for each lift, which situation representation (12) defines the instantaneous operational state (18) and the traffic situation (15, 17) of the lift,
    • c. calculation of an optimal journey sequence for each situation representation (12) with consideration of a preselected optimisation criterion such as minimal waiting times and/or operating times and/or travel times of the passengers, and
    • d. booking of the lift, which best corresponds with the respective optimal journey sequence, in order to fulfil the destination call.
  2. Method according to claim 1, characterised in that destination calls are registered in a lift installation with several lifts, that these registered destination calls are communicated to a central job manager (26), that each lift has a job manager (27, 28), which job managers are asked, for each registered destination call, by the central job manager (26) for a transport offer, that transport offers corresponding with the requests are communicated by these job managers (27, 28) to the central job manager (26) and that a journey sequence optimal with respect to the optimisation criterion is booked by the central job manager (26) from the communicated transport offers for a registered destination call.
  3. Method according to claim 1, characterised in that destination calls are registered in a lift installation with several lifts, that each lift has a job manager (4), which job managers (4) are, for each registered destination call, asked for a transport offer, that transport offers corresponding with the request are made by the job managers (4) and that a journey sequence optimal with respect to the optimisation criterion is booked from these transport offers for a registered destination call.
  4. Method according to one of claims 1 to 3, characterised in that destination calls are registered at registration devices (3.1, 3.2, 3.3) of the storey and that a lift corresponding with a booked journey sequence is indicated at the registration device (3.1, 3.2, 3.3) which has registered the destination call.
  5. Method according to one of claims 1 to 4, characterised in that the situation representation contains operators which specify elemental state transitions (16) of the lift installation, that operators to be used are selected with respect to the optimisation criterion, that concrete values for operator parameters are determined for these operators and that an arrangement sequence in which these operators occur in the journey sequence planning is determined.
  6. Method according to claim 5, characterised in that operators are selected which contain control instructions with respect to service requirements.
  7. Destination call control for a lift installation for determining the journey sequence of one or more lifts of the lift installation with registration devices (3.1, 3.2, 3.3) at storeys of the lift installation for registration of destination calls, characterised in that a processing unit (4) is provided, which has for each lift a situation representation (12) and a planner (5), which situation representation (12) defines the instantaneous operational state (18) and the traffic situation (15, 17) of the lift and which planner (5) calculates an optimal journey sequence for each situation representation (12) with consideration of a preselected optimisation criterion such as minimal waiting times and/or operating times and/or travel times of the passengers.
  8. Destination call control according to claim 7, characterised in that the situation representation contains parameters about the current operational state of the lift installation and the destination state, which is to be produced, of the lift installation and that the situation representation contains parameters which specify elemental state transitions (16) of the lift installation.
  9. Destination call control according to claim 7 or 8, characterised in that lift installation comprises several lifts, that a central job manager (26) is provided, which receives all registered destination calls by way of communications network from the registration devices (3.1, 3.2, 3.3), that each lift comprises a job manager (27, 28), that the central job manager (26) asks, for each registered destination call, these job managers (27, 28) by way of the communications network (2) for a transport offer, that these job managers (27, 28) communicate transport offers, which correspond with the request, to the central job manager (27, 28) by way of the communications network (2) and that the central job manager (26) books, for a registered destination call, from the communicated transport offers a journey sequence optimal with respect to the optimisation criterion.
  10. Destination call control according to claim 7 or 8, characterised in that the lift installation comprises several lifts, that each lift comprises a job manager (4), that a registration device (3.1, 3.2, 3.3) asks, for each registered destination call, these job managers (4) by way of a communications network (2) for a transport offer, that these job managers (4) communicate transport offers, which correspond with the request, by way of the communications network (2) to the requesting registration device (3.1, 3.2, 3.3) and that this registration device (3.1, 3.2, 3.3) books, for the registered destination call, from these transport offers a journey sequence optimal with respect to the optimisation criterion.
  11. Destination call control according to claim 9 or 10, characterised in that a registration device (3.1, 3.2, 3.3) which has registered a destination call indicates the lift corresponding with a booked journey sequence.
  12. Lift control consisting of at least one lift with one deck and at least one lift with two decks and a destination call.control according to one of claims 7 to 11.
Anspruch[fr]
  1. Procédé pour la planification de séquence de trajet d'une installation d'ascenseur avec au moins un ascenseur, comprenant
    • a. l'enregistrement d'appels de destination à l'aide d'un système de capteurs (3.1, 3.2, 3.3) disposé aux étages de l'installation d'ascenseur,

      caractérisé par les étapes suivantes :
    • b. l'inscription d'appels de destination dans une représentation de situation (12) pour chaque ascenseur, laquelle représentation de situation (12) définit l'état de fonctionnement momentané (18) et la situation de trafic (15, 17) de l'ascenseur,
    • c. le calcul d'une séquence de trajet optimale pour chaque représentation de situation (12) compte tenu d'un critère d'optimisation présélectionné comme les temps d'attente et/ou de desserte et/ou de trajet minimaux pour les passagers, et
    • d.la réservation de l'ascenseur qui correspond à la meilleure séquence de trajet optimale, pour satisfaire l'appel de destination.
  2. Procédé selon la revendication 1, caractérisé en ce que les appels de destination sont enregistrés dans une installation d'ascenseur avec plusieurs ascenseurs,

       en ce que ces appels de destination enregistrés sont transmis à un gestionnaire de travaux centralisé (26),

       en ce que chaque ascenseur comporte un gestionnaire de travaux (27, 28) auquel le gestionnaire de travaux centralisé (26) demande une offre de transport pour chaque appel de destination enregistré,

       en ce que les gestionnaires de travaux (27, 28) transmettent au gestionnaire de travaux centralisé (26) des offres de transport correspondant à la demande, et

       en ce que le gestionnaire centralisé (26), à partir des offres de transport transmises, réserve pour un appel de destination enregistré une séquence de trajet optimale par rapport au critère d'optimisation.
  3. Procédé selon la revendication 1, caractérisé en ce que les appels de destination sont enregistrés dans une installation d'ascenseur avec plusieurs ascenseurs,

       en ce que chaque ascenseur comporte un gestionnaire de travaux (4), les gestionnaires de travaux (4) recevant pour chaque appel de destination enregistré une demande d'offre de transport,

       en ce que les gestionnaires de travaux (4) font des offres de transport correspondant à la demande, et

       en ce qu'à partir de ces offres de transport pour un appel de destination enregistré, une séquence de trajet optimale par rapport au critère d'optimisation est réservée.
  4. Procédé selon l'une des revendications 1 à 3,caractérisé en ce que les appels de destination sont enregistrés sur des dispositifs d'enregistrement (3.1, 3.2, 3.3) des étages, et

       en ce qu'un ascenseur qui correspond à une séquence de trajet réservée est indiqué au dispositif d'enregistrement (3.1, 3.2, 3.3) qui a enregistré l'appel de destination.
  5. Procédé selon l'une des revendications 1 à 4,caractérisé en ce que la représentation de situation contient des opérateurs qui spécifient des passages d'état élémentaires (16) de l'installation d'ascenseur,

       en ce que les opérateurs à utiliser sont sélectionnés par rapport au critère d'optimisation,

       en ce que des valeurs concrètes pour ces opérateurs sont définies pour des paramètres d'opérateurs, et

       en ce qu'une suite de dispositions dans laquelle ces opérateurs apparaissent dans la planification de séquence de trajet est définie.
  6. Procédé selon la revendication 5, caractérisé en ce que des opérateurs qui contiennent des instructions techniques de commande relatives à des exigences de service sont sélectionnés.
  7. Commande d'appels de destination pour une installation d'ascenseur, destinée à définir la séquence de trajet d'un ou plusieurs ascenseurs de ladite installation, comportant des dispositifs d'enregistrement (3.1, 3.2, 3.3) aux étages de l'installation, pour enregistrer les appels de destination,

       caractérisée en ce qu'il est prévu une unité de traitement (4) qui comprend pour chaque ascenseur une représentation de situation (12) et un planificateur (5), la représentation de situation (12) définissant l'état de fonctionnement momentané (18) et la situation du trafic (15, 17) de l'ascenseur tandis que le planificateur (5) calcule pour chaque représentation de situation (12) une séquence de trajet optimale compte tenu d'un critère d'optimisation présélectionné tel que des temps d'attente et/ou de desserte et/ou de trajet minimaux pour les passagers.
  8. Commande d'appels de destination selon la revendication 7, caractérisée en ce que la représentation de situation contient des paramètres sur l'état de fonctionnement actuel de l'installation d'ascenseur et sur l'état de destination de l'installation d'ascenseur à réaliser, et

       en ce que la représentation de situation contient des paramètres qui spécifient les passages d'état élémentaires (16) de l'installation d'ascenseur.
  9. Commande d'appels de destination selon la revendication 7 ou 8, caractérisée en ce que l'installation d'ascenseur comporte plusieurs ascenseurs,

       en ce qu'il est prévu un gestionnaire centralisé (26) qui reçoit à partir des dispositifs d'enregistrement (3.1, 3.2, 3.3), par l'intermédiaire d'un réseau de communication, tous les appels de destination enregistrés,

       en ce que chaque ascenseur a un gestionnaire de travaux (27, 28),

       en ce que le gestionnaire de travaux centralisé (26) demande à ces gestionnaires de travaux (27, 28), par l'intermédiaire du réseau de communication (2), une offre de transport pour chaque appel de destination enregistré,    en ce que ces gestionnaires de travaux (27, 28) transmettent au gestionnaire de travaux centralisé (26), par l'intermédiaire du réseau de communication (2), des offres de transport correspondant à la demande, et

       en ce que le gestionnaire de travaux centralisé (26) réserve pour un appel de destination enregistré, à partir des offres de transport transmises, une séquence de trajet optimale par rapport au critère d'optimisation.
  10. Commande d'appels de destination selon la revendication 7 ou 8, caractérisée en ce que l'installation d'ascenseur comprend plusieurs ascenseurs,

       en ce que chaque ascenseur a un gestionnaire de travaux (4),

       en ce qu'un dispositif d'enregistrement (3.1, 3.2, 3.3) demande à ces gestionnaires de travaux, par l'intermédiaire d'un réseau de communication (2), une offre de transport pour chaque appel de destination enregistré,

       en ce que ces gestionnaires de travaux (4) transmettent au dispositif d'enregistrement demandeur (3.1, 3.2, 3.3), par l'intermédiaire du réseau de communication (2), des offres de transport correspondant à la demande, et

       en ce que ce dispositif d'enregistrement (3.1, 3.2, 3.3) réserve pour l'appel de destination enregistré, à partir de ces offres de transport, une séquence de trajet optimale par rapport au critère d'optimisation.
  11. Commande d'appels de destination selon la revendication 9 ou 10, caractérisée en ce qu'un dispositif d'enregistrement (3.1, 3.2, 3.3) qui a enregistré un appel de destination indique l'ascenseur qui correspond à une séquence de trajet réservée.
  12. Installation d'ascenseur composée d'au moins un ascenseur à un niveau et d'au moins un ascenseur à deux niveaux, et d'une commande d'appels de destination selon l'une des revendications 7 à 11.






IPC
A Täglicher Lebensbedarf
B Arbeitsverfahren; Transportieren
C Chemie; Hüttenwesen
D Textilien; Papier
E Bauwesen; Erdbohren; Bergbau
F Maschinenbau; Beleuchtung; Heizung; Waffen; Sprengen
G Physik
H Elektrotechnik

Anmelder
Datum

Patentrecherche

Patent Zeichnungen (PDF)

Copyright © 2008 Patent-De Alle Rechte vorbehalten. eMail: info@patent-de.com