EP1276691B1 - Targeted call control for lifts - Google Patents

Abstract

A method and an apparatus for determining the optimal travel sequence for an elevator installation includes smart terminals sending destination specific travel requests and other planning information to a job manager for each elevator car. The job managers perform a situation-based search process to determine the optimal travel sequence plan for the associated elevator and submit an offer to the terminal sending the travel request. The terminal compares offers and books a selected one. The job managers are responsive to relevant changes in the situation upon which the plan is based for determining a changed actual travel sequence and associated changed offer.

Description

The invention relates to a destination call control for elevators as defined in the claims.

As is known, an elevator control is used to Cabin calls on the different floors of a building to use. The drive of an elevator knows as commands just the instructions - drive up -, - drive to below -, - door open - and - door closed -.

In larger buildings is usually a group of two to eight elevators installed, of which now the elevator must be selected for a newly received Cabin call from one floor, a so-called Floor call, most appropriate appears. In general it is this is the elevator that has the shortest access to this Floor has. But now every elevator has the group on This approach before other floor calls too operate, then become on these floors passengers get on board, the destination of which will not be known until they reach the end pressed corresponding cabin buttons. The assignment a floor call on an elevator turns out so problematic because of permanent uncertainty about the to be reached goals.

Therefore, numerous attempts can be made in the elevator industry be observed through the use of learning methods based on neural networks or genetic algorithms sent the possible destination floors to the passengers too "guess". Such examples are described in GB 2311148 and JP 02052875. However, the effect of such methods is very great limited, because only rough traffic patterns, such as Example the morning up-peak, with some Safety are identifiable. But it remains unclear, where a passenger wants, for example, if he wants to Monday morning at 10.37 on the 10th floor of an office tower calling a lift.

Another approach to solving the control task exists in so-called destination call controls. At a Destination call control give the passengers already before the Entering an elevator, or an elevator car her desired destination floor, for example via a telephone-like keyboard, a so-called terminal. Out the position of the terminal is the access floor for the Destination call control known. After entering the Destination floor, determines an allocation algorithm of Control the elevator of the elevator group, which for the passenger the fastest and most comfortable transport his goal. The terminal shows the passenger this elevator the group of elevators and the passenger can now rest in the appropriate marked elevator issued. If the elevator stops to get in, the destination will be of the passenger, for example via a display device confirmed in the door frame. In the cabin itself are no Buttons for entering targets more available. To this Way, by using a destination call control Passengers with identical transport destination are grouped and thereby increases the transport capacity of the elevator system become.

An example known from EP 0 699 617 A1 Destination call control is also capable of individual Identify passengers. For each identified Passengers are granted access to one Information store additional information regarding Entry and exit position, its space requirements and possibly additional service requirements, in which Determination of the optimal transport option considered.

These and other conventional destination call controls are based on a heuristic approximation algorithm on the Basis of allocation rules. This allocation algorithm is each designed and programmed according to requirements. In a journey request, the destination call, which are about a appropriate sensors detected personal and system-related data to the allocation algorithm forwarded and go through the algorithm for Determination of the sequence of the journey.

Enter new during the execution of a journey additional travel requests, that's already calculated driving sequence modified to the effect. It can but only simple modifications are made, which that can only lead to a customized and destination-related no longer those with regard to the changed Conditions optimal sequence is executed. From this can have long waiting and / or transportation times for the Passengers arise. Furthermore, in such a hard-coded allocation algorithm relationships individual control options, so-called service requirements, not always logical and complete express. In addition, the calculation of the journey sequence requirement-specific created control software as constricting and expensive. The disadvantage is in particular, that once created Allocation algorithm subsequently only under considerable Expenditure on different customer-specific Control needs can be adjusted. Practical to adapt to changing service requirements respectively a new elevator-specific allocation algorithm to make and to implement in their entirety.

The invention is based on the object Specify destination call control for elevator systems, which are next to an increase in transport performance also flexible and is robust and in particular individual and / or collective transport needs of passengers considered.

To solve the problem, the invention is given by a Method for sequence planning with the in claim 1 given characteristics, which in particular thereby that is a situation-based Search method for determining the optimal driving sequence is provided. A device-based solution is through a destination call control according to the definition of claim 6 given, which is an organization of traffic using a so-called planning system.

According to the invention is thus in place of a previously used application-specifically programmed Control algorithm a per se known planning system intended. The planning system works according to one situation-based search method and determined destination call based on the current operating state of Elevator installation and the target state to be produced Elevator installation the situation-specific optimum driving sequence.

The inventive application of a situation-based Search method essentially offers the advantage that at any relevant change in the current situation, such as upon registration of a new trip request, errors in Execution of a sequence or the like, in extreme cases after each running sequence a completely new one current driving sequence is determined, and the elevator drive then do this.

Each time a relevant change is registered, For example, with each destination call, each of the current operating status and the desired Target operating state of the elevator system on the basis of Facts in a state description declarative summarized. This in the description of the condition shown to be reached state change of Elevator system is in translated form as part of a Situation diagram, which is described below, the Planning system forwarded. This has the situation-based Search method for each registered destination call the complete information about the traffic conditions of the Lift system. It can therefore be for a fixed, predefined Optimization criterion the optimal operation of the destination call to calculate. This calculation process is designed so that actually the optimum on the basis of the given criterion under real-time requirements can be found.

The determined driving sequence plan is determined by the planning system designed so that the desired state change in Execution of the driving sequence plan can be achieved.

An elevator installation with a sequence planning according to Consequently, each invention leads exclusively for the current planning situation represents the optimum Drive sequence. The optimization can be based on that very different criteria, whereby the Objectives of optimization from increasing the performance of the Elevator, reducing the waiting and / or operating and Travel times of the passengers or the improvement of a balanced ride management and the like.

The planning process advantageously takes time thereby limiting that computing power and memory requirements are limited. Within this limited Computing resources, the search method finds the optimal or nearly optimal driving sequence. The expert is for it so-called anytime algorithms known for such Search method can be used.

According to an advantageous embodiment of the inventive Search method, the state description is preferred together with an operator description in the Presentation of the situation in translated form to the planning system fed.

The operator description becomes the configuration time, preferably when installing the system at the customer communicated the inventive destination call control. she contains operators, which elementary state transitions of Specify lift system. The operators form as Elementary building blocks for the to be constructed Road trip solution the basis of the determined Driving sequence plan. At each destination call allocation or at release In a concrete planning task, the planning system chooses the Operators to be used in the solution Operators description off, determines concrete values for Operator parameter as well as an arrangement order in which Operators occur in the driving sequence plan. These Order of arrangement specifies the Execution order of the operators in the plan, that is, the Ride a row.

In contrast to previously firmly programmed Allocation algorithms can with a planning system arbitrary set of operators, specifically even those who can service requirements, the Customer not yet available at installation time are. These requirements come at a later date on, so the planning system has only a corresponding Situations are communicated in which this Service requirements are formulated. The system can then solve such tasks immediately. Enter service requirements on, for which no operators are provided, so secure the modularity of the operators in a planning system that added new operators in a very simple way or can be taken without the existing ones Operators are influenced by it. Elevator facilities can by changing the amount of operators responsible for the Control are available, as well as by the Definition of the operators themselves, very simple and flexible to changing customer needs in terms of Be adapted to the traffic organization.

When controlling a group of elevators with the the destination call control according to the invention takes place Consideration of service requirements in the current Operation of the lift without a separate Reservation of a lift of the elevator group for the respective service requesting passenger must be made. The Elevator control and the operators are in a way coordinated, that basically every elevator all at any given time about the situation presentation can perform special service requests. If necessary the service request becomes quasi group operation call-specific integrated.

The embedding of a planning system as the core of Destination call control is either in a central concept or in a decentralized concept or a combination of centralized and decentralized concept possible.

In a structure of the destination call control with a so-called Central Job Manager is this crucial hub between the terminals and the individual job managers the Lifts. The terminals address their transport requests to the central job manager. The job manager asks at each of the Job manager of the individual lifts after a transport offer for the registered destination call, the so-called job, at. The central job manager alone is responsible for the administration all current transport requests from passengers, the Destination calls, and the posting of transfer orders, so-called Jobs, on the selected elevator. From the central Job Manager receive the terminal as an answer the identifier the selected elevator, which they then display (e.g. "A or B").

The communication between the terminals and the elevators is easy to organize because all communication via a central office, the central job manager, runs. The Jobs are organized by a central job manager in a queue, a so-called "first in-first out "data structure. This organization is simple and ensures a clear processing order.

In the central concept, the terminals have only the Destination call input of the passenger and the display of the central Jobmanager booked elevator to process and All you need is a simple software. What the use simpler and cheaper terminals.

In a decentralized structure of the job manager, stand Terminals via a powerful communication network with the job managers of the individual elevators one Elevator group in connection. The terminals ask directly the job managers of each elevator after one Transport offer for the registered destination call. The terminals independently collect these offers, compare these and determine the optimal booking of the Passenger. In a decentralized job manager, the Organization of jobs in parallel for multiple jobs, with one Any overlay of inquiries and bookings possible is.

Further advantages of the decentralized concept of Destination call control are in the compared to the central Concept faster response of job managers to inquiries, increased stability of the overall system by the Decentralization and a simplified architecture of the Job Manager, as no separate center is provided got to.

If the decentralized design is provided, the Terminals equipped with intelligent booking software. The communication between the terminals and the job managers the individual elevators are preferably made use of of contract network protocols. The job manager of the individual Elevators themselves are able to parallel jobs organize and manage their status correctly.

The central and decentralized concept of the job manager can also combined with each other in a destination call control become. Any number of job managers can work in a network present, which control one or more elevators.

According to a particularly preferred embodiment of Invention is the situation-based destination call control as Multi-Angent system shown that the overall control the investment is realized, whereby the planning system is an agent in this multi-stake system is. The elevator can be a any number of elevators with any layout include. So can several elevators with one different number of decks in a group, one so-called heterogeneous multidecker group, work together.

The structure as a multi-agent system enables a modular Implementation of destination call control, in which individual Components, the so-called agents, e.g. Planning system, doors, drive, taxi driver arbitrary can be exchanged without affecting the overall system must be changed.

An event-driven activation of the agents in one Multi-agent system makes the control much more robust against occurring errors. For example, one falls Landing door on a floor due to a faulty Contact, the job manager can either Arrange evacuation drive or the taxi driver first have the plan still running. For further passenger requests may be the error Configuration Manager will be notified, all affected components of the system informed that this Floor of this elevator temporarily unattended can be. Failure of components does not mean that immediate failure of the overall system, as long as the Safety of passengers is ensured.

Further advantageous embodiments of the invention are in independent claims included.

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.

Embodiments of the invention in which the destination call control is designed as a multi-agent system for Oganisation the traffic of an elevator system are shown in the drawing and described in detail below. It shows:

1 schematically shows the structure of a first embodiment of the destination call control with a decentralized job manager for the control of a single elevator;

2 shows a schematic representation of the organization of a pool of requested and offered jobs in a destination call control with a decentralized job manager for the control of a group of elevators;

3, a current state description according to the first embodiment;

4, a graphical representation of the ascertained driving sequence plan according to the first embodiment;

5 shows schematically the structure of a second embodiment of the destination call control with a central job manager as a switching point between terminals and the individual elevators;

6 shows a block diagram of the organization of the jobs in a queue with a central job manager;

Fig. 7 is an instantaneous state description of the elevator A of the second embodiment;

Fig. 8 is an instantaneous state description of the elevator B of the second embodiment;

9, the structure of an operator with stop instruction, as it comes in the second embodiment used.

Figure 1 shows schematically the structure of a inventive destination call control 1 with situational sequence planning of the traffic volume a single lift. The destination call control is as a multi-agent system built up. Basis of the multi-agent system makes a powerful communication network 2, over which three distributed in the building facilities for Destination call input, so-called terminals 3.1,3.2,3.3, with a decentralized job manager 4.

Ideally, as a communication network 2 is a Architecture chosen for spontaneous networking. At this Execution is a well-known ad-hoc network with the Designation IRON provided. IRON supports a spontaneous Networking and is therefore a crucial requirement for a configuration control.

• 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.

Well-known examples of spontaneous networking architectures are Jini, Universal Plug and Play or Bluetooth. In such a communication network 2, network-capable devices, so-called agents, can log in and interact with each other without the need for configuration or administration. The integration of all these devices and the services implemented on them is fully automatic. The most important methods of such a communication network 2 are - register -, - lookup - and - notify -.

• By registration , the individual devices in the network and announce their services.
• Lookup allows a device to find another device or service.
• Notification allows one device to log in to another for notification of the occurrence of certain events.

• 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.

In an elevator group, terminals, drives, car doors, central job managers and / or decentralized job managers preferably register as network-capable devices.

• Terminals log in with their floor position and XY coordinate in the network and find out about all existing job managers.
• Drives represent the physical component of the elevator control. They provide the information on which floors they can approach, how many shaft doors are on a floor and on which side they are positioned. Furthermore, the drive can be subscribed to the notification of certain events such as change of the selector, change of state (eg driving, arriving, stationary).
• Cabin doors log in with information about which drive they belong to, which deck they are on and which side they open. With this information, the job manager instantly finds out how many decks an elevator has and how many doors per deck are available.
• Job managers log into the network with the information about which drives they represent - a single, strictly decentralized concept or all existing concepts that are strictly central.

In principle, any number of components can be in the network Sign in. The traditional group concept of elevators is thus superfluous and in particular can be in a group any number of elevators with whole different layout be present.

• 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.

For example, if there are eleven drives, of which three have only one door, four three doors each on two decks, and four each six doors equally distributed on three decks, then there is an example of a so-called heterogeneous multi-decker group consisting of

• 3 Singledeckern with only one door
• 4 biplanes, one with a door and the other with 2 doors
• 4 tripledecks where each deck has 2 doors.

• 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.

The job manager of each of the elevators is capable of detecting the number of decks and doors of its associated drive and processing them correctly in the controller. This includes in particular:

• the planning system plans to use a multi-decker to get passengers in and out of all existing decks,
• The taxi driver of the job manager sends the door opening commands at a stop to all doors that open to floors where passengers want to get on or off.

In the case of the IRON communication network 2 used here Agents can inform each other about changes and prepare information and your own flow logic integrate. An agent can find out via broadcast which other agents have logged into the network as well Send messages to other agents. Furthermore, a Subscribe agent information to another agent.

The individual components of this multi-agent system, the so-called agents, is next to the terminals mentioned above the job manager 4, which has all the components necessary for the logical and physical control of an elevator are necessary integrated. These are here, a planning system or planner 5 5, a broker 6, a door manager 7, a taxi driver 8, the Drive 9 of the elevator and an observer 10.

The terminals 3.1.3.2.3.3 are more intelligent Equipped booking software and ask directly at Job Manager 4 for a transport offer for each registered destination call. The communication between Terminals and job managers 4 takes place by means of Contract network protocols. Each of the terminals is 3.1.3.2.3.3 with a device for the identification of passengers equipped to which a configuration manager 11 belongs.

In the configuration manager 11 are the current building layout, such as the number of floors, access zones, Subdivision of passengers into passenger groups, Access rights, service requirements, etc. and Passenger information stored retrievable. In the Registration of a destination call, each terminal can Interrogate passenger data from configuration manager 11 and on forward the broker 6. So every terminal can be used for Example check whether the currently registered passenger has a Has access permission to the desired destination floor. Is the Checking successfully, the terminal asks the job manager 4 of the elevator after his transport offer.

The planner 5 plans the optimal operation of the new one Passengers taking into account the current, lift-specific traffic situation and generates one optimal plan, which then to control the drive. 9 the elevator is passed on to broker 6, which continues is described below. Starting point for the planner 5 is an always present situation representation, in the broker enters 6 new passengers during the Observer removed 10 passengers carried.

The broker 6 communicates over a two-stage Contract network protocol with the three terminals 3.1.3.2.3.3. He accepts the entries of the terminals 3.1.3.2.3.3, carries she in the situation representation of the planner 5, checks The generated optimal plan then, how the new scheduled passenger on the transport already booked passengers affects and tells the terminal that Transport offer with. No plan could be found because the problem for example due to insoluble Conflicts between the passenger groups for this elevator insoluble, so informed the broker 6 the corresponding Terminal also above. If the passenger is booked, send the broker 6 the taxi driver 8 the current driving sequence plan. The terminal will now display on the display.

The observer 10 monitors the condition of the elevator installation and follows up the situation representation for the planner 5. Thus, if he finds that the elevator has stopped on one floor and the doors have been opened correctly, then all passengers are marked as " served ", to whom boarded is valid and whose destination corresponds to this floor. Passengers waiting there will be marked -boarded as they board when the elevator arrives. The observer 10 has no knowledge of the plan or activities of the taxi driver 8, but relies solely on the information he has subscribed to the drive 9 and the door manager 7. This is a prerequisite in order to ensure that the situation representation is tracked correctly according to the actually occurring state changes even when a special operation, such as triggering the fire control, which takes over the control of the drive 9 and interrupts the taxi driver normal operation.

The taxi driver 8 moves his current plan, i.e. he sends the appropriate commands to the drive 9 the elevator and the drives of the doors. He knows from his current plan, where the elevator next scheduled to keep should and how long the doors need to be opened so that all passengers have enough time to get in and out. How many passengers at a stop change state, was already determined by the planner 5. Does that have Taxi driver 8 no plan, so he releases the elevator, so that it can be parked. In any Situation allows the taxi driver 8 his current timetable against the current plan sent to him by broker 6 will, replace. How this change takes place depends on it in which execution state the taxi driver 8 located. For example, a once started Stop process from the old plan has to be finished first, before the taxi driver 8 the first stop from the new plan can start.

The drive 9 executes the drive and stop commands that he From the taxi driver 8 receives, he also learns the travel times the elevator between each floor. Created the time table to the optimizer 5 for the optimization Available and also reports where the elevator is currently located and in which direction he drives or whether he is straight stops.

The door manager 7 manages all the doors of the elevator and monitors that the doors open and close correctly. It can doors on different sides of a cabin to be available. He also determines the door opening and Close the doors and tell the planner 5 for the doors Optimizing the service times of passengers with.

Each of the components is as an independent agent implemented when certain events occur independently carries out actions. In particular, can thereby superimposing various events. So can to Example of the broker 6 at the same time the inquiries various terminals 3.1.3.2.3.3 accept and the Planner 5 submit. The decentralized job manager 4 can be parallel make an offer for several jobs while posting other jobs is still pending. The jobs are only then binding when the corresponding terminal books.

As between the submission of the offer by the broker 6 and the booking by the respective terminal theoretically one any period of time can pass, it is possible that in the meantime already another terminal one Booking has placed. In this situation, the broker must 6 check if the submitted offer is still valid, if the Terminal now sends its booking. This arbitrary Overlaying requests and bookings requires that the terminal is waiting for a confirmation of its booking and if there is no confirmation, an alternative booking tried another job manager 4. Is also the replanning unsuccessful, because the situation in the elevator, for example has changed so that now insoluble conflicts between the already booked and the new passenger to book occur, the terminal receives a corresponding Feedback.

Figure 2 shows a pool of requested and offered Jobs Job1 to Job4 for a decentralized job manager 4. Each Terminal 1, 2 usually only has a specific Job Job X or Job Y, who wants to book it on a lift. It sends Therefore this job to all known Jobmanager 4 of the Group of elevators, of which it is the drive data knows if the associated elevator is both on and off Exit landing of the passenger. unnecessary Requests to elevators, which are not in principle for transport come into question are avoided.

The decentralized job manager 4 has two types of jobs: On the one hand, these are jobs, the jobs X, which have been requested and for which job manager 4 must calculate an offer, On the other hand, the jobs Y for which the job manager is 4 has already made an offer, but does not yet know whether the terminal will really book with him.

In the first shown here and shown in Figure 1 Embodiment is only a single elevator available. The elevator can also be part of an elevator group. The The invention is without limitation to such elevator groups applicable. Even with an elevator group ask the terminals 3.1,3.2,3.3 directly to the job managers 4 of the individual Lifts after a transport offer. The terminals 3.1.3.2.3.3 self-collect these offers, compare these and calculate the optimal booking of the Passenger. Each requested elevator counts independently of the other taking into account the current, lift-specific traffic situation its optimal Road sequence plan for serving the new passenger. The Offer of each requested elevator is sent to the terminal who chooses the best offer and the corresponding elevator with the transport of the passenger instructed. Job manager 4 confirms the booking the terminal from which the transport offer has been requested is, the booking becomes binding and becomes the passenger displayed on the terminal. If a job manager does not answer more, so the terminal responds to it and does not wait endless on the missing offer.

The operation of the extent described according to the invention destination call control according to FIG following on the example of a planning problem of a Elevator system with only a single lift with one door Cabin described, the one not shown here building served by stops on seven floors f1 to f7. The elevator car is currently in floor f4. One Passenger P1, waiting for floor f2 and wants to go to Floor f7, a second passenger P2 is already located in the cabin and would like to go from floor f1 to floor f5. It is the driving sequence of the cabin according to the invention by means of Planning system 3 to organize.

From the observer 10, the properties of the elevator, the means, the current operating state of the elevator detected and updated in the situation view. about Terminals 3.1.3.2.3.3 in conjunction with the Configuration Manager 11 will be the properties of Passengers P1, P2 and in particular the destination calls, the Passengers P1, P2 as input variables of the destination call control 1 forwarded to the broker 6, who in the Presenting situation representation of the planner 5, as in Figure 2 shown.

Thus, in any planning operation, e.g. by Registration of a destination call is started, which determined Operating state and the desired target state, ie the too reaching state change of the elevator in one for the Planning system understandable state description 14 declaratively assembled, which is shown in Figure 3.

The state description 14 shown here in FIG. 3 is in the Plandarstellungssprache PDDL after McDermott he al. 1998, expressed. The skilled person is also others Modeling languages known in terms of their To distinguish expressiveness, and which he to Description of the situation representation can use, without that changes the essence of the invention. However, that is When choosing a planning system, make sure that this powerful according to the modeling Planning algorithms provides.

In the state description 14 shown in FIG. 3, the planning system 3 is first informed of the registered passengers P1, P2 and the floors f1 to f7 of the building in an object declaration 15. For each object, a typed constant is introduced. For the elevator considered here, these are the waiting passenger P1, the passenger P2 already in the cabin, and all seven floors f1 to f7.
(: Objects
(p1 - passenger)
(p2 - passenger)
(f1, f2, f3, f4, f5, f6, f7 - floor))

(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).

From the configuration manager 11, the broker 6 receives the information regarding the topology of the building. This can be found as topology description 16 in the state description 14 again in the form of

(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 topology description 16, the (upper? Fi,? Fj) Specifications, respectively, that the floor fj above the Floor fi lies. The representation of the building topology is not mandatory. In simplification, in other versions of the procedure also on the explicit Topology description 16 of the building under the assumption be dispensed with, that from each floor of each other Floor can be served by the elevator.

The current transport order 17 with the destination calls of the passengers P1 and P2 consists of entry floors, origin, and destination floors, destin, as
(: init (origin p1 f2)
(origin p2 f1)
(destin p1 f7)
(destin p2 f5)
(boarded p2).

The transport order 17 contains a previously planned Sequence also the information, boarded P2, namely, that passenger P2 has already boarded and is in the Cabin is located. This information was provided by the observer 10 used in the description of the condition.

• 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.

In principle, each passenger P1, P2 assumes the three states during the sequence planning: waiting / waiting, traveling / boarded, served / served, which are defined as follows:

• Waiting / waiting: The passenger is waiting in front of the elevator door. Here the elevator has to hold first at the starting point, origin, of the passenger and only then at the destination floor specified by the passenger, destin.
• Traveling / boarded: The passenger is in the elevator car and is sent to his destination floor, destin,
  transported, which has not yet been approached, that has been served.
• Servant: The passenger has left the elevator car at his destination floor, destin. This transport order has been completed and the passenger has been served satisfactorily by the elevator. These three possible states can be expressed in the PDDL modeling language by means of the two commands -boarded? P- and -served? P-. The passenger P1 is waiting for an elevator car and is therefore registered neither as a boarded nor as a server.

The observer 10 sets the current position 18 of the elevator car as
(lift-at f4))
is expressed in the state description 14.

The goal 19 for the planning system 5 is formulated in the state description 14 as:
(: goal (forall (? p - passenger) (served? p)).

We are looking for the shortest sequence of stops, all Passengers P1, P2 operated in the state -served- transferred, which is reached when she is on her Destination store -destini.

In addition to the descriptions of the initial state and the target state of the planning problem by the state description 14, the planning system 3 is also given an operator description. In the exemplary embodiment illustrated here, a stop operator and an operator for ascending -up- and an operator for descending -down- for modeling the state transitions between the initial state and the destination state of the elevator are transferred in the operator description. As an alternative to these operators - stop, -up, -down-, the expert also knows other operators with which the desired change in the elevator state can be achieved. If necessary, this does not change the essence of the invention if the parameters are correspondingly defined. In PDDL syntax according to McDermott et al. In 1998 the following stop operator is available:
(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)))))

The uphill operator -up- appears as:
(: action up
: parameters (? f1 - floor? f2 - floor)
: precondition (and (lift-at? f1) (upper? f1? f2))
: effect (and (lift-at? f2) (not (lift-at? f1))))

The down-down operator is expressed as:
(: action down
: parameters (? f1 - floor? f2 - floor)
: precondition (and (lift-at? f1) (upper? f2? f1))
: effect (and (lift-at? f2) (not (lift-at? f1))))

The stop operator signals the control of the drive 9 the elevator that holds the cabin on a specific floor f1 to f7 has to stop. The stop operator is in here illustrated first embodiment defined that he includes the opening and closing of the doors. The Opening and closing of the car doors can also as separate additional basic instruction to the door manager 7 an elevator can be considered or it can be the stop operator be refined so that an elevator too the doors can open and close.

The up-and-down operators - down- give the control-technical instruction to the Drive control, the drive 9 in the corresponding To set the direction in motion. The chronological order in which the drive 9 is controlled by means of the operators, the taxi driver specifies 8.

A change in the passenger condition is basically only possible with a stop of the cabin. outgoing of rational behavior of the passengers, join in a scheduled stop the elevator car on a Floor all passengers on this floor - originally waiting to be transported to the cabin and All passengers leave the cabin when they are on their way Destination floor - arrives. The thereby occurred Change is here with the help of the observer 10 in the stop operator registered and thus during the sequence planning considered by the planning system 5. Like the operators -up-, -down-, then the stop operator becomes an instruction for the drive 9 effective when the in-effect coded Criteria are all met or have occurred. Will in the example described here in the stop operator? f = f5, selected, so P2 increases according to the state description 14 and of the behavioral model when, as in the stop operator as - effective- the operator instance stop (f5) described, -boarded p2 and -destin p2 f5- apply.

The extent either in the operator description or as Data of the state description 14 declared information are used to calculate the optimal driving sequence plan to the Planning system 5 passed.

Planning systems 5 are already known from other technical fields. In this embodiment, 1997 looking for a IPP planning system as et of Koehler al., Extending planning graphs to subset of ADL, published in Steel, S, Proceedings of the 4 ^th European Conference on Planning, 273-285 Springer, Volume 1348 of LNAI, available at http://www.informatik.uni-freiburg.de/~koehler/ipp.html, a valid sequence of STOP statements that the planning target 13 (: goal (forall (? P - passenger) (served? Other planning systems may be used, provided that they are able to collect and process the current situation representation in their entirety.

Basically, the planning system 5 selects when entering the 14 independently based on the over the Operator description provided operators Instances and also determines the order in determined travel sequence plan 20. The planning system 5 determines the parameters for the three operators -stop-, -up-, -down-, which cause a desired state change.

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

The result thereof, in this embodiment, is a planned trip sequence 20, the optimal schedule, shown in graphical form in FIG.

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

This calculated optimal plan 13 is sent to the broker 6 passed. The broker 6 checks the generated optimal Plan to see how the newly scheduled passenger P1 on the transport of the already booked passenger and informs the terminal about the transport offer.

In the embodiment described here is only one Destination call for planning. Consequently, one job is only for one job Offer to submit. Therefore, between the Quotation calculation by the decentralized job manager 4 and the booking through the respective terminal, no other jobs be booked through other terminals 3.1.3.2.3.3. Out For this reason, the reconfirmation of his Booking to the terminal, but the booking is immediate binding. The terminal now takes the ad on the Display before and the broker 6 sends the taxi driver 8 the current optimal driving sequence plan 20.

The taxi driver 8 drives this current driving sequence plan 20 from, i. he sends the appropriate commands in the form of respective operators to the drive 9 of the elevator and the Drive the door.

This sequence of operations 20 causes the elevator car in the Step 0 from the current floor f4 on which they are is the next stop on floor f5 -stop f5-drives. There, the elevator car stops according to step 1 stop f5- and the car door opens in a given time and closes so that the passenger exits P2 and thus served, served, is. In step 2, the elevator car moves down from f5 to f2 -down f5 f2- and stop in step 3 on floor f2 -stop f2-. There passenger P1 climbs. in the Step 4 the elevator moves upwards from floor f2 Floor f7 -up f2 f7- and stops in the last step 5 on Floor f7 -stop f7-. There can now also passenger P1 get out. Through this sequence 13 all passengers P1, P2 transferred to the state -served- and the Goal formulation 10 of the driving sequence planning is thus reached.

While the taxi driver 8 executes the optimal driving sequence plan 13, the observer 10 monitors the condition of the elevator installation and continuously updates the situation representation for the planner 5. In step 1, he therefore states that the elevator has stopped on the floor f5 and the doors have been opened correctly; he marks the passengers P2 as -served. At step 2, the observer 10 marks the passenger P1 waiting there for floor f2 as boarded. Finally, the elevator car stops on the floor f7 and after the doors have been opened correctly, the observer 10 also sets the passenger P1 in the situation description as served and the current position 9 of the elevator car in the status display 5 on floor f7.

This created driving sequence plan 20 will not now mandatory completely executed, but when state, or the characteristics of passengers and / or the facility change relevant before it is completely executed According to the invention, a next planning cycle is started and an optimal driving sequence plan for the new planning situation 20 created. There is therefore no plan modification.

Figure 5 shows schematically the structure and the basic structure a second embodiment of the inventive Destination call. The destination call controller 25 includes a central job manager 26 and two decentralized job managers, a configuration manager 29 and representative of all existing terminals a terminal 30, which via a Communication network 31 communicate with each other. The structure and function of decentralized job managers 27,28 correspond essentially to those of the decentralized one Job Manager 4 from the first embodiment.

The destination call control organizes here as so-called Group control the traffic of an elevator group with two Elevators A and B in a building with stops on seven floors. The planning task arises as follows:

The elevator car A momentarily moves upwards; she is currently on floor f2 and can be the floor f3 still reach. The elevator car B is currently up Floor f1. Elevator A transports a passenger P1 Access restriction on floors 3 and 4, the target Floor f7 is specified while elevator B is empty. In In this situation, a new passenger P2 appears, who as VIP be promoted in front of all other passengers got to. Passenger P2 has just got his transport order from Floor 3 to floor f7 delivered.

It is therefore an allocation of the passenger P2 on one of the two lifts A, B known in the example in such a way, that the passengers P1, P2 with as few stops be transported and the desired service requirements - VIP and access restrictions are fulfilled.

The central job manager 26 collects the requests of the Terminals together with the respectively recorded personal data from the configuration manager 29 as so-called jobs, here job 1 to job 4, in one Queue, as shown in Figure 6. He chooses the first job 1 out of the queue and sends it to the decentralized job manager 27,28 of each elevator. Everyone the decentralized job manager 27,28 of the lifts A, B determined independent of the other with the help of his planning system his best driving sequence solution based on the given Optimization criteria and sends them as an offer to the central job manager 26 back. The central job manager 26 Check all offers, choose from these the best offer and book the passenger on the elevator with the best Offer. The identification of the best elevator will follow sent a successful assignment to the terminal 30, on which the job was originally initiated. The Terminal 30 only functions as a display. The job 1 is done and will be canceled. The process again only picks up job 2, and so on, until all the jobs of the Warteschlage are processed.

Each decentralized job manager 27,28 of the draws A, B created for the job submitted as the current planning task registered data / information first one Situation presentation, which corresponds to the respective planning system 21 is handed over. The situation representation contains a State Description 32 and an operator description.

For elevator A, in an object declaration 33, the registered passengers P1, P2 and floors f1 to f7 of the Building known to the planning system. For each Object is introduced a typed constant. Moreover takes place in the object declaration 33 for each passenger P1, P2 an assignment to one or more service requests, such as. VIP, conflict, going_direct, etc ..

The service requirements are each within the framework of Passenger detection from the configuration manager 29 known and are provided by the central job manager 26 as part of a Jobs, or a request for quotation, to the decentralized Job Manager 27,28 of each elevator A, B forwarded. Certain service requirements for all or any selected passengers may vary depending on the condition the elevator system or the building also time of day be provided activated. Furthermore, by the Application of a planning system for driving sequence determination a flexible weighting of individual service requirements, in particular the VIP requirement, in Dependence of the traffic volume can be displayed.

• 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.

Here are the following service requirements:

• Classification of all passengers in two groups conflict_A and conflict_B, which may never meet in the elevator;
• Passengers of the type never_alone, for whom a companion in the form of a
• Passengers of the type attendant in the elevator during the ride must be present. It is not absolutely necessary that while driving the same companion always drives in the elevator, but this can also change;
• Passengers of type going_direct, who are transported to their destination without stopping;
• Passengers of type vip, who are transported in front of all other passengers;
• Passengers for whom an access restriction is formulated on certain floors;
• Passengers of the type going_up, which are transported exclusively upwards;
• Passenger of the type going_down, which are transported only downwards.

(P1 (either conflict_A never_alone))

(P2 (either conflict_B attendant))

A passenger P1, P2 can thus be the subject of a variety of service requirements; However, these should not contradict, so that the passenger can really be promoted. An elementary contradiction is for example two passengers P1, P2 is declared for the following typing:

(P1 (either conflict_A never_alone))

(P2 (either conflict_B attendant))

P1 can not drive alone in the elevator here and heard at the same time to the passenger group A. The only one to the system known possible companion P2 but belongs to Passenger group B, the passenger group A never in the elevator may meet. An accompaniment thus violates the Exclusion condition and P1 can only be promoted if the system becomes known another companion who is not to Group B belongs.

For elevator A, the object declaration 33 contains the already-traveling passenger P1, a normal passenger, the new passenger P2, a VIP, and all 7 floors f1 to f7.
(: Objects
(p1 - passenger)
(p2 - vip)
(f1, f2, f3, f4, f5, f6, f7 - floor))

Assuming that each other from each floor can be operated in this embodiment an explicit description of the building topology waived.

The current registered transfer order 34 of the passengers P1 and P2 appears as
(: init (origin p1 f1)
(origin p2 f3)
(destin p1 f7)
(destin p2 f7)
(boarded p1)

The transport order 34 is based on the standard assumption that passengers wait on the floor if there is no corresponding boarded information. True, this means that passenger P2 is waiting on the floor. The access restriction for passenger P1, presents itself as
(no-access p1 f3)
(no-access p1 f4)

The current position 35 of the elevator car 2 of the elevator A is as
(lift-at f2))
expressed in the state description 32. All listed facts are considered true, all others as wrong.

The goal 36 for the planning system is called
(: goal (forall (? p - passenger) (served? p))
formulated.

Wanted is the shortest sequence of stops, all Passengers P1, P2 transferred to the condition served, the exact then reached when on their destination floor, respectively Floor f7, got out.

Since in this embodiment only a minimal stop Sequence is to be determined, the planning system receives only a so-called stop operator 37, from which there is a construct a valid travel sequence plan. In Fig. 9 is an example of a stop operator 37 is shown. As before in the description of the state 32, here is the Modeling language PDDL according to McDermott et al. 1998 to Illustration. The stop operator 37 contains a Specifications 38 in which is described when a Stop an elevator A, B on a floor f1 to f7 is permissible. Here are the access restrictions - no-access - which is either concrete for a passenger or but is defined for a passenger group and one Function statement 39 is defined in which Floor f1 to f7 an elevator car at a permissible Stop and what effect this stop on the current state of the elevator installation 18 has. preconditions the function statement 39 make the Application-specific implementation of the desired service requirements The complex stop operator shown in FIG. 9 37 allows the planning system with all in the passenger and property declaration 33 introduced To handle service requirements.

For the planning example described here, only the in 9 underlined preconditions of the operator 32nd relevant to a stop on one of the conditions Floor f1 to f7 under the presence of VIPs and Formulate passengers with access restrictions.

The extent created for each elevator A so far Situation representation 32, is connected to the elevator A belonging planning system passed.

The suitable used according to the invention Planning systems work independently of the actual one Planning problem. Such planning systems are different technical areas already known.

Also in this second embodiment, each examined an IPP planning system as it is known from Koehler et al., 1997, Extending planning graphs to subset of ADL, published in Steel, Proceedings of the 4 ^th European Conference on Planning, pp 273-285 , Springer, Volume 1348 of LNAI and available at http://www.informatik.uni-freiburg.de/~koehler/ipp.html, a valid sequence of STOP instructions that meets planning goal 31. Other planning systems may be used as long as they are capable of capturing and processing the current situation representation as a whole.

When solving a concrete planning task, this selects Planning system to be used in the following sequence Operators of the operator description, here the stop operator 37. If service requirements, such as VIP, going_direct, etc., in the state description 32, so the planning system independently checks the corresponding Prerequisite of the function statement 39 of the operator 37. Missing one contained in operator 37 as a precondition Service request in the call-relevant State Description 32, then this will be superfluous Precondition of the operator 37 automatically ignored. One Example of a service request not considered here is the precondition -attendant-. Then determines the concrete values for operator parameters as well as a Arrangement sequence in which operators in the travel sequence plan occur. This order of arrangement specifies the Execution order of the operators in the drive sequence plan and so that the sequence of operations for the operation of the respective destination call.

For elevator A, the planning system can not find a solution: Passenger P2 should be transported immediately, i. the elevator A would have to hold in f3. However, P1 is in the elevator, who has no access to f3. A stop on f3 is therefore only possible after P1 has exited, i. the elevator A would first have to go to floor f7; this is not Allowed, since the VIP condition requires that VIP before all other passengers.

For elevator B (FIG. 8), the situation 42 can be solved by the planning system without any problem since elevator B does not know the passenger P1 at all because he is traveling in elevator A and only the new passenger P2 is notified. The object declaration 43 for elevator B to the planning system consequently also includes only the new passenger P2 typed by the service request VIP and all 7 floors f1 to f7.
(: Objects
(p2 - vip)
(f1, f2, f3, f4, f5, f6, f7 - floor))

Again, each other can be served from each floor become.

The current transport order 44 of the passenger P2 presents itself as
(: Init
(origin p2 f3)
(destin p2 f7).

The current position description 45 of the elevator car B is in the status description 42 as
(lift-at f1)
expressed.

In the elevator B, the target formulation 46 for the Planning system identical to that of the elevator A. Sie is combined with the object declaration 43 and the above described stop operator 37 as part of Situation representation 42 of the elevator B to the planning system to hand over. To plan the route of the elevator B is only the operator precondition: Stop on a floor below the presence of VIP, relevant because the 32 for elevator B only the service request Passing VIP to the planning system. The rest in the form of specifications 33 and preconditions of Function statement 39 of the STOP operator 37 provided Service requirements remain with this planning sequence disregarded and therefore without effect on the Travel sequence plan.

time step 1: (stop 3)

time step 2: (stop 7),

der eine minimale Stopfolge zur erfolgreichen Beförderung von Passagier P2 darstellt.Based on this input for elevator B, the planning system generates the following travel sequence plan

time step 1: (stop 3)

time step 2: (stop 7),

which represents a minimum stop sequence for the successful carriage of passenger P2.

Are the results of the sequence planning of lifts A, B arrived at the central job manager 26, then evaluated this is the two following offers of lifts A, B. Of the Elevator with the best offer is provided by the central job manager 26 selected. The best solution here is the only one possible Route sequence of the elevator B. As a result, the central bus Job Manager 26 Passenger P2 on the elevator B. Elevator B updated after receiving the booking also the Travel sequence plan; all other elevators continue to drive their previous plan.

Claims (12)

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.

Images