EP1276691A1

EP1276691A1 - Targeted call control for lifts

Info

Publication number: EP1276691A1
Application number: EP01914940A
Authority: EP
Inventors: Jana Koehler; Kilian Schuster
Original assignee: Inventio AG
Current assignee: Inventio AG
Priority date: 2000-03-29
Filing date: 2001-03-29
Publication date: 2003-01-22
Anticipated expiration: 2021-03-29
Also published as: DK1276691T3; AU4220801A; JP2003528785A; DE50107119D1; CN1420836A; HK1054364A1; EP1276691B1; US6793044B2; HK1054364B; WO2001072621A1; US20030085079A1; MXPA02009377A; ES2248295T3; ATE302158T1; BR0109529A; CN1220614C; AU2001242208B2

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

Destination call control for elevators

The invention relates to a destination call control for lifts according to the definition of the claims.

As is known, an elevator control serves to serve car calls on the different floors of a building. As commands, the drive of an elevator only knows the instructions - drive up -, - drive down -, - door open - and - door close -.

In larger buildings, a group of two to eight elevators is usually installed, from which the elevator must be selected that appears most suitable for a newly received car call from one floor, a so-called floor call. Usually this is the elevator that has the shortest route to this floor. However, if each elevator in the group has to serve other floor calls on this route beforehand, passengers will board on these floors, the destination of which will only be known when they have printed the corresponding car buttons. The assignment of a floor call to an elevator is therefore problematic since there is permanent uncertainty about the destinations to be reached.

Numerous attempts can therefore be observed in the elevator industry to skillfully "guess" the possible destination floors of passengers by using learning methods based on neural networks or genetic algorithms. However, the effect of such methods is very limited because only rough traffic patterns, such as Example the morning upward spike, with some Security are identifiable. But it remains unclear, for example, where a passenger might be heading if, for example, he calls an elevator on Monday morning at 10:37 a.m. on the 10th floor of an office tower.

Another approach to solving the control task consists in so-called destination call controls. In the case of a destination call control, the passengers enter their desired destination floor even before entering an elevator or elevator car, for example via a telephone-type keyboard, a so-called terminal. The boarding level for destination call control is known from the position of the terminal. After entering the destination floor, an allocation algorithm of the control determines the elevator of the elevator group that enables the fastest and most convenient transportation to the destination for the passenger. The terminal shows the elevator of the group of elevators to the passenger and the passenger can now calmly go to the appropriately marked elevator. If the elevator stops for boarding, the destination of the passenger is confirmed, for example, via a display device in the door frame. There are no buttons in the cabin itself for entering destinations. In this way, passengers with an identical transport destination can be grouped by using a destination call control and the transport performance of the elevator system can thereby be increased.

An example of such a destination call control known from EP 0 699 617 AI is also able to identify individual passengers. For each identified passenger, access to an information store provides additional information regarding Entry and exit position, its space requirements and any additional service requirements are taken into account when determining the optimal transport option.

These and other conventional destination call controls are based on a heuristic approximation algorithm based on allocation rules. This allocation algorithm is designed and programmed specifically for each requirement. In the event of a trip request, the destination call, the personal and system-related data recorded via a corresponding sensor system are forwarded to the allocation algorithm and run through the algorithm for determining the trip sequence.

If new additional trip requests occur during the execution of a trip sequence, the trip sequence already calculated is modified accordingly. However, only simple modifications can be carried out, which can lead to the fact that only an adapted and destination call-related no longer carries out the optimal travel sequence with regard to the changed conditions. This can result in long waiting and / or transport times for the passengers. Furthermore, in such a permanently programmed allocation algorithm, relationships between individual control options, so-called service requirements, cannot always be printed out logically and without gaps. In addition, the control software, which is created specifically for the calculation of the journey sequence, is considered to be restrictive and complex. A particular disadvantage is that an allocation algorithm that has already been created can only be added to different customer-specific ones with considerable effort Control needs can be adjusted. In practice, a new elevator-specific allocation algorithm has to be prepared and implemented as a whole in order to adapt to changing service requirements.

The invention is based on the object of specifying a destination call control for elevator systems which, in addition to an increase in the transport performance, is also constructed flexibly and robustly and in particular takes into account the individual and / or collective transport needs of passengers.

To achieve the object, the invention is provided by a method for planning the journey sequence with the features given in claim 1, which is characterized in particular in that a situation-based search method is provided for determining the optimal sequence of the journey. A device-based solution is given by a destination call control according to the definition of claim 6, which provides for an organization of the traffic volume using a so-called planning system.

According to the invention, instead of a previously used application-specific, permanently programmed control algorithm, a planning system known per se is provided. The planning system works according to a situation-based search method and determines the optimal route-specific route sequence based on the current operating state of the elevator system and the target state of the elevator system to be established.

The use of a situation-based search method according to the invention essentially offers the advantage that at Every relevant change in the current situation, such as, for example, when registering a new travel request, disruptions in the execution of a travel sequence or the like, in extreme cases a completely new current travel sequence is determined after each executed travel sequence step, and the elevator operator then executes this.

Each time a relevant change is registered, for example each time a destination call is made, the current operating state and the desired target operating state of the elevator installation are declaratively summarized on the basis of facts in a state description. This change in state of the elevator system, which is to be achieved and is shown in the state description, is sent to the planning system in a translated form as part of a situation description, which is described further below. The situation-based search method thus has complete information about the traffic status of the elevator system for each registered destination call. It can therefore calculate the optimal operation of the target call for a fixed, predefined optimization criterion. This calculation process is designed in such a way that the optimum can actually be found on the basis of the given criterion under real-time requirements.

The route plan determined is constructed by the planning system in such a way that the desired change in state can be achieved when the route plan is executed.

An elevator system with a sequence planning according to the invention consequently exclusively executes the sequence representing the optimum for the current planning situation. The optimization can be based on that completely different criteria take place, the objectives of the optimization resulting from the increase in the performance of the elevator, the reduction in the waiting and / or operating and travel times of the passengers or the improvement of a balanced travel management and the like.

The planning process is advantageously limited in time by the fact that computing power and memory requirements are limited. The search procedure finds the optimal or approximately optimal travel sequence within these restricted computing resources. So-called anytime algorithms are known to the person skilled in the art, which can be used for such a search method.

According to an advantageous embodiment of the search method according to the invention, the status description is preferably forwarded to the planning system together with an operator description m of the situation representation m translated form.

The operator description is communicated to the destination call controller according to the invention at the configuration time, preferably when the system is installed at the customer. It contains operators who specify the elementary state transitions of the elevator system. As elementary building blocks for the route sequence solution to be constructed, the operators form the basis of the route sequence plan determined. For each destination call assignment or when a specific planning task is solved, the planning system selects the operators to be used in the solution from the operator description, determines specific values for operator parameters and a sequence of orders in which operators appear in the route plan. This Arrangement order specifies the

Execution order of the operators in the plan, that is, the travel order.

In contrast to previously programmed allocation algorithms, the planning system can be provided with any number of operators, especially those that can serve service requirements that the customer does not yet have at the time of installation. If these requirements occur at a later point in time, the planning system merely has to be informed of a corresponding situation description in which these service requirements have been formulated. The system can then immediately solve such tasks. If service requirements arise for which no operators are provided, the modularity of the operators ensures that a planning system can be added in a very simple manner, so that new operators can be added or removed without affecting the existing operators. Elevator systems can be easily and flexibly adapted to changing customer needs with regard to the traffic organization by changing the amount of operators available for the control, as well as by defining the operators themselves.

When controlling a group of elevators with the destination call control according to the invention, the service requirements are taken into account during the ongoing operation of the elevator system without a separate reservation of an elevator of the elevator group for the passenger requesting the respective service. The elevator control and the operators are coordinated with one another in such a way that basically every elevator can carry out all special service requirements specified via the situation display at any time. If required, the service request is virtually integrated into the group operation in a call-specific manner.

A planning system can be embedded as the core of the destination call control either in a central concept or in a decentralized concept or a combination of the central and the decentralized concept.

When the destination call control is set up with a so-called central job manager, this is the crucial switching point between the terminals and the individual job managers of the lifts. The terminals direct their transport requests to the central job manager. The job manager asks each of the job managers of the individual lifts for a transport offer for the registered destination call, the so-called job. The central job manager alone is responsible for managing all current passenger transport inquiries, the destination calls, and booking the transport orders, so-called jobs, on the elevator selected in each case. In response, the central job manager receives the identifier of the selected elevator, which they then display (e.g. "A" or "B").

Communication between the terminals and the elevators is easy to organize because all communication is carried out via a central office, the central job manager. A central job manager organizes the jobs in a queue, a so-called "first m-first out" data structure. This organization is simple and ensures a clear processing sequence. With the central concept, the terminals only have to process the destination call inputs of the passenger and the display of the elevator booked by the central job manager and only need simple software. Which enables the use of simple and inexpensive terminals.

With a decentralized structure of the job manager, terminals are connected to the job managers of the individual elevators in an elevator group via a powerful communication network. The terminals inquire directly with the job managers of the individual elevators for a transport offer for the registered destination call. The terminals independently collect these offers, compare them and determine the optimal booking for the passenger. In the case of a decentralized job manager, the jobs are organized in parallel for several jobs, whereby any overlay of requests and bookings is possible.

Other advantages of the decentralized concept of destination call control lie in the fact that the job managers react faster to queries compared to the central concept, increased stability of the overall system due to decentralization and a simplified architecture of the job managers, since no separate center has to be provided.

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

The central and decentralized concept of the job manager can also be combined with one another in a destination call control. There can be any number of job managers in a network who control one or more elevators.

According to a particularly preferred development of the invention, the situation-based destination call control is shown as a multi-agent system that realizes the overall control of the system, the planning system being an agent in this multi-agent system. The elevator installation can comprise any number of elevators with any layout. This means that several elevators with a different number of decks can work together in a group, a so-called heterogeneous multi-deck group.

The structure as a multi-agent system enables a modular implementation of the destination call control in which individual components, the so-called agents, e.g. Planning system, doors, drive, taxi driver can be exchanged as required without having to change the overall system.

An event-controlled activation of the agents in a multi-agent system makes the control much more robust against occurring errors. If, for example, a shaft door on one floor fails due to a faulty contact, the job manager can either arrange an evacuation trip or have the taxi driver first carry out the plan that still exists. For further passenger inquiries, the error can be the Configuration manager will be informed, who informs all affected components of the system that this floor can temporarily not be served by this elevator. A failure of components does not mean the immediate failure of the overall system as long as the safety of the passengers is guaranteed.

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

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

Fig.l, schematically 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 shows a current status description according to the first exemplary embodiment;

4 shows a graphical representation of the determined route plan according to the first embodiment; 5 shows schematically the structure of a second exemplary embodiment of the destination call control with a central job manager as a switching point between terminals and the individual elevators; 6, in a block diagram, the organization of the jobs in a queue at a central job manager; 7 shows a current description of the state of elevator A from the second exemplary embodiment; 8 shows a current description of the state of elevator B from the second exemplary embodiment;

Fig. 9, the structure of an operator with a stop instruction, as used in the second exemplary embodiment.

FIG. 1 schematically shows the structure of a destination call controller 1 according to the invention with situation-dependent route sequence planning of the traffic volume of a single elevator. The destination call control is constructed as a multi-agent system. The basis of the multi-agent system is a powerful communication network 2, via which three facilities for destination call inputs, so-called terminals 3.1, 3.2.3.3, distributed in the building are connected to a decentralized job manager 4.

Ideally, an architecture for spontaneous networking is chosen as communication network 2. In this embodiment, an ad hoc network known per se, called IRON, is provided. IRON supports spontaneous networking and is therefore a crucial prerequisite for configuration-free control.

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

• By registering, the individual devices log on to the network and advertise their services.

• Lookup enables a device to find another device or a required service.

• Notification allows one device to contact another for notification of the occurrence of certain

Register events.

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

• Terminals log on to the network with their floor position and XY coordinate and find out about all existing job managers. • Drives represent the physical component of the elevator control. They provide information on which floors they can approach, how many shaft doors are on one floor and on which side they are positioned. Furthermore, the drive can be subscribed to the notification of certain events, such as changing the selector, changing the status (e.g. moving, arriving, stationary).

• Cabments report with information about which drive they belong to, on which deck they are and on which side they open. With this information, the job manager immediately finds out how many Decks have an elevator and how many doors there are on each deck.

• Job managers log on to the network with the information about which drives they represent - one in the strictly decentralized concept or all of the existing ones in the strictly centralized concept.

In principle, any number of components can log on to the network. The traditional group concept of elevators is therefore superfluous and in particular, any number of elevators with a very different layout can be present in a group.

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

• 3 single decks with only one door

• 4 double decks, one deck with one door and the other deck with 2 doors

• 4 triple decks, where each deck has 2 doors.

The job manager of each of the individual lifts is able to recognize the number of decks and doors of its assigned drive and to process them correctly in the control system. This includes in particular:

• the planning system plans for a multi-decker to get passengers on and off over all existing decks, • The job manager's taxi driver sends the door opening commands to all doors that open to floors on which passengers want to get on or off.

In the IRON communication network 2 used here, agents can inform each other about changes and prepare information and integrate it into their own flow logic. An agent can use broadcast to find out which other agents have logged on to the network and send messages to other agents. An agent can also subscribe to information from another agent.

The individual components of this multi-agent system, the so-called agents, are, in addition to the terminals mentioned above, the job manager 4, which integrates all the components which are necessary for the logical and physical control of an elevator. Here are a planning system or planner 5 5, a broker 6, a tower 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 equipped with intelligent booking software and ask the job manager 4 directly for a transport offer for the registered destination call. Communication between terminals and job managers 4 takes place using contract network protocols. Each of the terminals 3.1,3.2,3.3 is equipped with a device for identifying passengers, to which a configuration manager 11 belongs.

The configuration manager 11 contains the current building layout, such as the number of floors, access zones, subdivision of passengers, passenger groups, access rights, service requirements, etc. and Passenger information stored in a retrievable manner. When registering a destination call, each terminal can query passenger data from the configuration manager 11 and forward it to the broker 6. For example, each terminal can check whether the currently registered passenger has access to the desired destination floor. If the check is successful, the terminal asks the job manager 4 of the elevator for its transport offer.

The planner 5 plans for himself the optimal operation of the new passenger, taking into account the current elevator-specific traffic situation, and in doing so creates an optimal plan, which is then passed on to the broker 6 for controlling the drive 9 of the elevator, which is described further below. The starting point for the planner 5 is a current situation representation at any time, in which the broker 6 enters new passengers, while the observer removes 10 passengers.

Broker 6 communicates with the three terminals 3.1,3.2,3.3 via a two-stage contract network protocol. He accepts the inputs from the terminals 3.1,3.2,3.3, enters them in the situation display of the planner 5, checks the generated optimal plan for how the newly scheduled passenger affects the transport of the passengers already booked and communicates the transport offer to the terminal With. If no plan could be found because the problem cannot be solved for this elevator, for example due to unsolvable conflicts between the passenger groups, the broker 6 also informs the corresponding terminal about this. If the passenger is booked, the broker 6 sends the taxi driver 8 the current route plan. The terminal now makes the display on the display. The observer 10 monitors the state of the elevator system and tracks the situation for the planner 5. If he determines that the elevator has stopped on one floor and the doors have been opened correctly, all passengers are marked as -served- for whom - boarded- applies and whose destination corresponds to this floor. Passengers who are still waiting there are marked -boarded- as they get on when the elevator arrives. The observer 10 has no knowledge of the plan or the activities of the taxi driver 8, but is based solely on the information he has subscribed to in the drive 9 and in the door manager 7. This is a prerequisite to ensure that even when a special operation occurs, such as triggering the fire control, which takes control of the drive 9 and interrupts the normal operation of the taxi driver, the situation is correctly displayed in accordance with the changes in status that actually occur.

The taxi driver 8 follows his current plan, ie he sends the corresponding commands to the drive 9 of the elevator and the drives of the doors. He knows from his current plan where the elevator should stop next according to plan and how long the doors have to be opened so that all passengers have enough time to get on and off. How many passengers change state at a stop has already been determined by planner 5. If the taxi driver 8 no longer has a plan, he releases the elevator so that it can be parked. In any situation, the taxi driver 8 can exchange his current schedule for the current plan sent to him by the broker 6. How this change is done depends on it from which version the taxi driver 8 is in. For example, once a stop operation from the old plan has begun must be ended before the taxi driver 8 can make the first stop from the new plan.

The drive 9 executes the travel and stop commands that it receives from the taxi driver 8, and it also learns the travel times of the elevator between the individual floors. It provides planner 5 with the travel times table for optimization and also reports where the elevator is currently located and in which direction it is traveling or whether it is currently stopping.

The tower manager 7 manages all the doors of the elevator and monitors that the doors open and close correctly. Doors can be present on different sides of a cabin. He also determines the door opening and closing times and notifies the planner 5 to optimize the operating times of the passengers.

Each of the components is implemented as an independent agent, which performs actions independently when certain events occur. In particular, a wide variety of events can overlap. For example, broker 6 can simultaneously receive requests from various terminals 3.1, 3, 2, 3 and 3 and present them to planner 5. The decentralized job manager 4 can submit an offer in parallel for several jobs while the booking of other jobs is still pending. The jobs only become binding when the corresponding terminal books. Since, in theory, an arbitrarily long period of time may pass between the submission of the offer by broker 6 and the booking by the respective terminal, it is possible that another terminal has already placed a booking in the meantime. In this situation, the broker 6 must check whether the submitted offer is still valid if the terminal now sends its booking. This arbitrary overlay of inquiries and bookings requires that the terminal wait for a confirmation of its booking and, if no confirmation is given, try an alternative booking with another job manager 4. If the rescheduling is also unsuccessful because, for example, the situation in the elevator has changed in such a way that there are now unsolvable conflicts between the passengers who have already been booked and those who are to be newly booked, the terminal receives the appropriate feedback.

FIG. 2 shows a pool of requested and offered jobs Jobl to Job4 with a decentralized job manager 4. As a rule, each terminal 1, 2 has only one specific job Job X or Job Y, which it wants to book on an elevator. It therefore sends this job to all job managers 4 of the group of elevators known to it, from whom it knows from the drive data whether the associated elevator can serve both the boarding and alighting floors of the passenger. This avoids unnecessary inquiries to lifts that are in principle out of the question for transport.

There are two types of jobs at the decentralized job manager 4: On the one hand, there are jobs, the jobs X that have been requested and for which the job manager 4 has to calculate an offer; on the other hand, there are jobs Y for which the job manager 4 has already submitted an offer but does not yet know whether the terminal will actually book with him.

In the first exemplary embodiment shown here and shown in FIG. 1, only a single elevator is present. The elevator can also be part of an elevator group. The invention can be applied without restriction to such elevator groups. In the case of an elevator group, too, the terminals 3.1, 3.2.3.3.3 request the job managers 4 of the individual elevators for a transport offer. Terminals 3.1,3.2,3.3 independently collect these offers, compare them and calculate the optimal booking for the passenger. Each elevator requested calculates its optimal route plan for serving the new passenger independently of the others, taking into account the current elevator-specific traffic situation. The offer of each requested elevator is sent back to the terminal, which selects the best offer and commissions the corresponding elevator to transport the passenger. If the job manager 4 confirms the booking to the terminal from which the transport offer has been requested, the booking becomes binding and is displayed to the passenger on the terminal. If a job manager no longer reports, the terminal also responds and does not wait endlessly for the missing offer.

The mode of operation of the destination call control according to the invention described so far, according to FIG. 1, is described below using the example of a planning problem of an elevator system with only a single elevator with a single-door car, which serves a building (not shown here) with stops on seven floors fl to f7. The elevator car is currently on floor f4. On Passenger P1, waiting for floor f2 and liked floor f7, a second passenger P2 is already in the cabin and liked from floor fl ms floor f5. According to the invention, the travel sequence of the cabin is to be organized using planning system 3.

The properties of the elevator, that is to say the current operating state of the elevator, are recorded by the observer 10 and updated in the situation display. The properties of the passengers Pl, P2 and in particular the destination calls, the passengers Pl, P2, as input variables of the destination call control 1, are forwarded to the broker 6 via terminals 3.1, 3, 2, 3, 3 m in connection with the configuration manager 11 entered, as shown m Figure 2.

In this way, with every planning process, e.g. is started by registering a target call, the determined operating state and the desired target state, that is to say the change in state of the elevator to be achieved, of a state description 14 understandable for the planning system, which is shown in FIG. 3.

The state description 14 shown here in FIG. 3 is in the PDDL layout display language according to McDermott er al. 1998, printed out. The person skilled in the art is also aware of other modeling languages which differ in terms of their expressiveness and which he can use to describe the situation without changing the essence of the invention. However, when choosing a planning system, make sure that This provides powerful planning algorithms according to the modeling.

In the status description 14 shown in FIG. 3, the planning system 3 of an object declaration 15 is first made aware of the registered passengers P1, P2 and the floors fl to f7 of the building. A typed constant is introduced for each object. For the elevator considered here, these are the waiting passenger P1, the passenger P2 already in the cabin and all seven floors fl to f7.

(: objects

(pl - passenger) (p2 - passenger)

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

The broker 6 receives the information regarding the topology of the building from the configuration manager 11. This can be found again as a topology description 16 in the status description 14 in the form of

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

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

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

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

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

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

In the topology description 16, the (upper '' fi ^ fj) specifications stipulate that the floor f is above the floor fi. The representation of the building topology is not mandatory. To simplify matters, other implementations of the method can also dispense with the explicit topology description 16 of the building, on the assumption that every floor can be served by the elevator from every floor.

The current transport order 17 with the destination calls of

Passengers Pl and P2 are made up of entry floors, oπgm, and destination floors, dest

(: with (origm pl f2)

(origm p2 fl)

(destm pl f7)

(destm p2 f5) (boarded p2).

The transport order 17 also contains the information, boarded P2, from a previously planned travel sequence, namely that passenger P2 has already boarded and is in the cabin. This information was used by the observer 10 in the state description.

Basically, every passenger P1, P2 takes three states as part of the route planning: waiting / waitmg, driving / boarded, serviced / served, which are defined here as follows:

• Waiting / waitmg: The passenger is waiting in front of the

Elevator stubbornness. Here the elevator first arrives at the point of departure, origm, of the passenger and only then at that of

To hold the specified destination floor, destm. • Moving / boarded: The passenger is in the

Elevator car and is transported to its destination floor, destin, which has not yet been reached, i.e. has been served.

• Served / served: The passenger has left the elevator car at his destination floor, destin. This transport order has been completed and the passenger was served satisfactorily by the elevator.

These three possible states can be expressed using the two commands -boarded? P- and -served? P- in the PDDL modeling language. The passenger P1 is waiting for an elevator car and is therefore neither registered as -boarded- nor as -served-.

The observer 10 sets the current position 18 of the elevator car, which as

(lift-at f4))

is printed out in the condition description 14.

The goal 19 for the planning system 5 is formulated in the status description 14 as:

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

We are now looking for the shortest sequence of stops that transfers all passengers P1, P2 to the “served” state, which is reached when they have disembarked on their destination floor. In addition to the descriptions of the initial state and the target state of the planning problem by means of the state description 14, an operator description is also transferred to the planning system 3. In the exemplary embodiment shown here, a stop operator and an operator for upward movement -up- and an operator for downward movement -down- for modeling the state transitions between the initial state and the target state of the elevator are transferred in the operator description. As an alternative to these operators - stop-, -up-, -down-, the person skilled in the art is also familiar with other operators with which the desired change in the elevator state can be achieved. If necessary, the nature of the invention does not change if the parameters are defined accordingly. In PDDL syntax according to McDermott et al. In 1998 the following stop operator is available:

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

(: predicates

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

(: action stop

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

? P)

(destination? p? f))

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

The operator for upward travel -up- is represented as:

(: action up

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

The downward-travel operator is printed out as:

(: action down

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

The stop operator signals to the control of the drive 9 of the elevator that the car has to stop on a certain floor fl to f7. In the first exemplary embodiment shown here, the stop operator is defined so that it also includes opening and closing the doors. The opening and closing of the car doors can also be taken into account as separate additional basic instructions to the tower manager 7 of an elevator, or the stop operator can be refined so that the elevator can also open and close the doors. The operators for upward travel - up and downward travel - give the control-related instructions to the drive control to start the drive 9 m in the corresponding direction. The taxi driver 8 specifies the time sequence in which the drive 9 is controlled by the operators.

A change in the passenger status is only possible when the cabin is stopped. Based on the rational behavior of the passengers, if the elevator car stops on one floor according to plan, all passengers who - on the original floor - are waiting to be transported on this floor and all passengers leave the cabin when they are on their destination floor - stops. The change that occurs as a result is registered here with the aid of the observer 10 in the stop operator and is therefore taken into account by the planning system 5 in the planning of the journey sequence. Like the operators -up-, -down-, the stop operator also becomes effective as an instruction for the drive 9 when the criteria coded in -effect are all met or have occurred. If? F = f5 is selected in the stop operator in the example described here, P2 will exit in accordance with status description 14 and the behavior model if, as described in the stop operator as - effect- the operator instance stop (f5) is boarded p2- and -destin p2 f5- apply.

The information declared either in the operator description or as data in the status description 14 is forwarded to the planning system 5 for calculating the optimal travel sequence plan. Planning systems 5 are already known from other technical fields. In this exemplary embodiment, an IPP planning system is sought, as it is from Koehler et al., 1997, Extendmg plannmg graphs to an ADL subset, published in Steel, S, Proceedmgs of the 4 ^th European Conference on Plannmg, 273-285 Springer, volume 1348 of LNAI, available at http: // www. Computer science. uni-freiburg. de / ~ koehler / ιpp. html, a valid sequence of STOP instructions, which fulfills the planning goal 13 (: goal (forall (? p - passenger) (served? p)). Other planning systems can also be used, as long as they are able to present the current situation to be recorded and processed as a whole.

In principle, the planning system 5, when entering the status description 14, independently selects instances on the basis of the operators provided via the operator description and also determines the sequence in the determined route plan 20. The planning system 5 determines the parameters for the three operators -stop-, - up-, -down-, which cause a desired change of state.

The result of this in this exemplary embodiment is a planned travel sequence 20, the optimal plan, which is shown in graphical form in FIG. 3.

Time step 0 up f4 f5

Time step 4 up f2 f7

Time step 5 stop f7 This calculated optimal plan 13 is passed on to the broker 6. The broker 6 then checks the generated optimal plan as to how the newly scheduled passenger P1 affects the transport of the already booked passenger and notifies the terminal of the transport offer.

In the exemplary embodiment described here, there is only one destination call for planning. As a result, only one job has to be submitted. Therefore, no other jobs can be booked by other terminals 3.1,3.2,3.3 between the offer calculation by the decentralized job manager 4 and the booking by the respective terminal. For this reason, the confirmation of his booking to the terminal is not applicable, but the booking is immediately binding. The terminal now makes the display and the broker 6 sends the taxi driver 8 the current optimal route plan 20.

The taxi driver 8 follows this current route plan 20, i.e. it sends the corresponding commands in the form of the respective operators to the drive 9 of the elevator and the drive of the door.

This travel sequence plan 20 causes the elevator car in step 0 to travel from the current floor f4 on which it is located to the next stop on floor f5 -stop f5-. The elevator car stops there according to step 1 -stop f5- and the cabin door opens and closes in the specified time, so that passenger P2 gets out and is served. In step 2 the elevator car moves down from f5 to f2 -down f5 f2- and stops in step 3 on floor f2 -stop f2-. There passenger Pl gets on. In step 4, the elevator travels upwards from floor f2 Floor f7 -up f2 f7- and stop in the last step 5 on floor f7 -stop f7-. Passenger PI can now also get out there. Through this travel sequence 13, all passengers P1, P2 are brought into the -served state and the destination formulation 10 of the travel sequence planning is thus achieved.

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

This generated route plan 20 is now not necessarily fully executed, but if the state or the properties of passengers and / or the system change relevantly before it is completely executed, according to the invention, a next planning cycle is started and an optimal one for the new planning situation Route plan 20 created. There is therefore no plan modification.

FIG. 5 schematically shows the structure and the basic structure of a second exemplary embodiment of the destination call control according to the invention. The destination call controller 25 includes one central job manager 26 and two decentralized job managers, a configuration manager 29 and representative of all existing terminals em terminal 30, which are connected to each other via a communication network 31. The structure and function of the decentralized job managers 27, 28 essentially correspond to those of the decentralized job manager 4 from the first exemplary embodiment.

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

The elevator car A is currently going up; it is currently on floor f2 and can still reach floor f3. The elevator car B is currently on floor f1. Elevator A transports a passenger P1 with access restrictions to floors 3 and 4, who has specified floor f7 as the destination, while elevator B is empty. In this situation, a new passenger P2 appears who, as a VIP, must be given priority over all other passengers. Passenger P2 has just submitted his transport order from floor 3 to floor f7.

Allocation of the passenger P2 to one of the two elevators A, B known in the example is to be carried out in such a way that the passengers P1, P2 are requested with as few stops as possible and the desired service requirements - VIP and access restrictions - are met.

The central job manager 26 collects the inquiries from the terminals together with the respectively recorded ones Personal data from the configuration manager 29 as so-called jobs, here job 1 to job 4, in a queue, as shown in FIG. 6. He selects the first job 1 from the queue and sends it to the decentralized job managers 27, 28 of the individual elevators. Each of the decentralized job managers 27, 28 of the elevators A, B independently of the other uses its planning system to determine its best route solution based on the specified optimization criterion and sends it back to the central job manager 26 as an offer. The central job manager 26 checks all offers, selects the best offer from them and books the passenger onto the elevator with the best offer. After a successful assignment, the identification of the best elevator is sent to the terminal 30 on which the job was originally initiated. Terminal 30 thus only functions as a display. Job 1 is now done and will be deleted. The process is only repeated with job 2 etc. until all jobs in the queue have been processed.

Each decentralized job manager 27, 28 of the elevator A, B first creates a situation representation for the registered data / information transmitted as a job for the current planning task, which is then transferred to the respective planning system 21. The situation representation contains a status description 32 and an operator description.

For elevator A, the reported passengers P1, P2 and floors fl to f7 of the building are made known to the planning system in an object declaration 33. A typed constant is introduced for each object. In addition, object declaration 33 is carried out for each passenger P1, P2 an assignment to one or more service requirements, such as VIP, conflict, gomg_dιrect, etc.

The service requirements are known in the context of passenger identification from the configuration manager 29 and are forwarded by the central job manager 26 to the decentralized job managers 27, 28 of the individual elevators A, B as part of a job or an offer request. Certain service requirements for all or any selected passengers can also be activated depending on the time of day, depending on the state of the elevator system or the building. Furthermore, a flexible weighting of the individual service requirements, in particular the VIP requirement, can be represented depending on the traffic volume by using a planning system for determining the route.

The following service requirements are provided here:

• All passengers are divided into two groups conflιct_A and conflιct_B, which must never meet in the elevator;

• Passengers of type never_alone, for the companion in the form of a

• Attendant-type passengers must be present in the elevator during the journey. It is not absolutely necessary that the same attendant always travels in the elevator during the journey, but this can also change;

• Passengers of the type gomg_dιrect who are transported to their destination without a stopover;

• vip-type passengers who are given priority over all other passengers; • Passengers for whom an access restriction is formulated on certain floors;

• gomg_up passengers who are only transported upwards; • Passengers of the type gomg_down, which are only transported downwards.

A passenger P1, P2 can therefore be the subject of a large number of service requirements; however, these should not contradict each other so that the passenger can really be challenged. An elementary contradiction is, for example, two passengers P1, P2 for which the following typing is declared:

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

Pl is not allowed to drive everything in the elevator and at the same time belongs to passenger group A. However, the only possible companion P2 known to the system belongs to passenger group B, which passenger group A may never meet in the elevator. An escort violates the exclusion condition and PI can only be requested if the system e becomes known to other escorts who do not belong to group B.

For elevator A, object declaration 33 contains the passenger P1, e who is already traveling, the normal passenger, the new passenger P2, a VIP, and all 7 floors fl to 7.

(: objects

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

Assuming that every other floor can be served from this floor, this exemplary embodiment does not explicitly describe the building topology.

The current registered transport order 34 of the passengers

Pl and P2 is represented as

(: with (origm pl fl)

(origm p2 f3)

(destin pl f7)

(destin p2 f7) (boarded pl)

The transport order 34 is based on the standard assumption that passengers wait on the floor if there is no corresponding boarded information. This means that passenger P2 is waiting on the floor. The access restriction for passenger Pl is shown as

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

The current position 35 of the elevator car 2 of the elevator A is as

(lift-at f2)) m printed in the condition description 32. All the facts listed are considered true, all others as false.

The goal 36 for the planning system is called

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

formulated.

We are looking for the shortest sequence of stops, which transfers all passengers Pl, P2 m to the served state, which is achieved exactly when they have exited on their destination floor, floor f7.

Since only a minimal stop sequence can be determined in this exemplary embodiment, the planning system also receives only a so-called stop operator 37, from which it can construct a valid route sequence plan. 9 shows an example of a stop operator 37. As before with the description of the condition 32, the modeling language PDDL according to McDermott et al. 1998 for illustration. The stop operator 37 contains a specification description 38 m which describes when a stop of an elevator A, B on a floor fl to f7 is permitted. Here these are the access restrictions - no-access - which are either defined specifically for a passenger or for a group of passengers and a 39 m functional instruction that specifies on which floor fl to f7 an elevator cable should stop at an admissible stop and what effect this stop has the current state of the elevator system 18. Preconditions of the functional instructions 39 are the application-specific implementation of the desired service requirements. The complex stop operator 37 shown in FIG. 9 enables the planning system to deal with all service requirements introduced in the passenger and object declaration 33.

For the planning example described here, only the preconditions of the operator 32 underlined in FIG. 9 are relevant, which formulate the conditions for a stop on a floor fl to f7 in the presence of VIPs and passengers with access restrictions.

The current situation illustration 32 created for each elevator A is forwarded to the planning system belonging to the elevator A.

The suitable used according to the invention

Planning systems work independently of the actual one

Planning problem. Such planning systems are already known from other technical fields.

In this second exemplary embodiment, too, an IPP planning system, as is known from Koehler et al., 1997, Extending planning graphs to an ADL subset, appeared in Steel, Proceedings of the 4 ^th European Conference on Planning, pp. 273-285 , Springer, Volume 1348 of LNAI and at http: // www. Computer science. uni-freiburg. de / ~ koehler / lpp. html is available, a valid sequence of STOP instructions, which fulfills the planning goal 31. Other planning systems can also be used, provided that they are able to record and process the current situation as a whole. When solving a specific planning task, the planning system selects the operators of the operator description to be used in the route plan, here the stop operator 37. If service requirements, such as VIP, going_direct, etc., occur in the status description 32, the planning system checks automatically the corresponding precondition of the functional instruction 39 of the operator 37. If a service request contained in the operator 37 as a precondition is missing in the call-relevant status description 32, then this superfluous precondition of the operator 37 is automatically ignored. The example of a service requirement not considered here is the precondition -attendant-. This then determines the specific values for operator parameters as well as an order in which operators appear in the route plan. This sequence of orders specifies the order of execution of the operators in the route plan and thus the route for operating the respective destination call.

The planning system cannot find a solution for elevator A: passenger P2 should be asked for immediately, i.e. elevator A had to hold m f3. However, Pl is in the elevator, which has no access to f3. A stop at f3 is therefore only possible after Pl has exited, i.e. elevator A had to move to floor f7 first; again, this is not permitted because the VIP condition requires VIP to be promoted in front of all other passengers.

For elevator B (FIG. 8), situation 42 can be solved easily by the planning system, since elevator B does not even know passenger P1 because he is traveling in elevator A and only receives the new passenger P2. Ob ect declaration 43 for elevator B to the planning system consequently only includes the new passenger P2, who is typified by the VIP service request, and all 7 floors fl to f7.

(: Objects

(p2 - vip)

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

Again, every other floor can be operated.

The current transport order 44 of the passenger P2 is shown as

(: Ιnιt

(origm p2 f3) (destin p2 f7).

The current position description 45 of the elevator car B is in the status description 42 as

(lift-at fl)

printed out.

In elevator B, the target formulation 46 for the planning system is identical to that of elevator A. It is transferred to the planning system together with the object declaration 43 and the stop operator 37 described above as part of the situation representation 42 of the elevator B. Only the operator precondition is relevant for planning the travel sequence of elevator B: stop on one floor in the presence of VIP, because the Description of condition 32 for elevator B only transfers the service request VIP to the planning system. All other service requirements provided in the form of specifications 33 and preconditions of the functional instructions 39 of the STOP operator 37 are not taken into account in this planning sequence and therefore have no effect on the trip sequence plan.

Based on this input for elevator B, the planning system generates the following route plan

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

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

If the results of the route sequence planning of the elevators A, B have been received by the central job manager 26, then the latter evaluates the two route sequence offers of the elevators A, B. The best job lift is selected by central job manager 26. The best solution here is the only possible route sequence plan for elevator B. Consequently, central job manager 26 books passenger P2 onto elevator B. Elevator B also updates the route sequence map after receipt of the booking; all other lifts continue to operate according to their previous plan.

Claims

claims

1. Procedure for the planning of the journey sequence of an elevator installation, in which a sensor system detects

Driving inquiries an optimal driving sequence is determined with respect to a predefinable optimization criterion, characterized in that a situation-based search method is provided for determining the optimal driving sequence, which determines a current driving sequence for each relevant change in a planning situation.

2. The method according to claim 1, characterized in that with each relevant change one

Planning situation Planning-relevant recorded personal and system-specific current data are summarized in a form that is understandable for the search procedure in a situation representation.

3. The method according to claim 1 or 2, characterized in that m the situation representation of the current operating state of the elevator system and the target state of the elevator system to be produced as well as em or more elementary state transitions of the elevator system are forwarded to the search method.

4. The method according to claim 3, characterized in that planning-relevant, recorded personal and system-specific data are summarized in a form that is understandable for the search method in a situation representation, wherein the operators have a modular structure and contain control instructions regarding service requirements.

5. The method according to claim 4, characterized in that in an elevator group several service requests are served simultaneously by several elevators of the elevator group.

6. destination call control for elevators for determining the travel sequence of one or more elevator cabins of an elevator installation with at least one call registration device for recording travel requests, a processing unit for determining an optimal travel sequence with respect to a given optimization criterion for registered travel requests, characterized in that a planning system is provided as the processing unit, which determines the optimal route-specific route sequence.

7. destination call control according to claim 6, characterized in that the planning system is part of a multi-agent system, the Rufregistreirirππungung via em

Communication network is effectively connected to the planning system.

8. Elevator system consisting of at least one elevator with a deck and at least one elevator with two

Decks and a destination call control according to claim 6.