CA2403918C - Targeted call control for lifts - Google Patents

Abstract

The invention relates to a targeted call control system for the organisation of the logistics of lifts, which offers an improvement in the transport performance, is flexible and robustly constructed and, in particular, can take account of individual and/or collective passenger transport requirements. In order to determine the optimal journey sequence for servicing the registered targeted calls, a planning system is provided, which calculates the servicing of the targeted calls by means of a situation-based search method for a fixed, pre-defined optimisation criterium. With each relevant change in the instantaneous situation of the lift, a completely new schedule is determined, which the lift then carries out. Control technology service requirements can be adjusted to meet changing customer needs by the amount and/or the definition of the operators applied. The logistical control of any number of lifts with varying layouts, for example, a multi-decker group, is possible with a targeted control system arranged as a multi-agent system.

Description

Targeted Call Control For Lifts The invention relates to a destination call control for lifts according to the definitions of the patent claims.

In known manner a lift control serves the purpose of serving cage calls to the various storeys of the building. The drive of the lift knows as commands merely the instructions 'travel upwardly', 'travel downwardly', 'door open' and 'door close'.

In larger buildings usually a group of two to eight lifts is installed, from which it is now necessary to select that lift which appears the most suitable for a newly input cage call from a storey, a so-termed storey call. As a rule this is the lift which has the shortest travel path to this storey. If, however, each lift of the group has to serve, on this travel path, other storey calls beforehand, then passengers will board at the storeys, the destination of whom is known only when they have pressed the corresponding cage buttons. The allocation of a storey call to a lift thus becomes problematic, since permanent uncertainty about the destinations to be travelled to exists.

Accordingly, in the lift industry numerous experiments can be observed to skilfully 'guess' the possible destination storeys of the passengers by means of use of learning methods on the basis of neuronal networks or genetic algorithms. The effect of such a method is, however, very limited, because merely coarse traffic patterns, such as, for example, the morning upward peak, are identifiable with any certainty. However, it remains unclear what a passenger wants when, for example, he or she calls a lift on a Monday morning about 10.37 o'clock at the 10th storey of a high-rise office.

Another starting point for solution of the control problem consists of so-called destination call controls. With a destination call control the passengers, before boarding a lift or a lift cage, input their desired destination storey, for example by way of a keyboard similar to a telephone, i.e. a so-termed terminal. The boarding storey is known to the destination call control from the position of the terminal. After input of the destination storey, an allocation algorithm of the control ascertains that lift of the lift group which enables the quickest and most comfortable transport for the passenger to his or her destination. The terminal indicates to the passenger this lift of the group of lifts and the passenger can step into the correspondingly marked lift at his or her own pace. If the lift stops for boarding, then the }

destination of the passenger is confirmed, for example, by way of a display device in the door frame. In the cage itself, there are no longer present any knobs for input of destinations. In this manner, through use of a destination call control, passengers with an identical transport destination can be grouped and thereby the transport performance of the lift system increased.

An example, which is known from EP 0 699 617 Al, of such a destination call control is, in addition, in the position of identifying individual passengers. For each identified passenger additional data with respect to boarding position and disembarking position, the passenger space requirement and possible additional service requirements are taken into consideration, by access to a data memory, in the determination of the optimal transport possibility.

This and other conventional destination call controls are based on an intuitive approximation algorithm on the basis of allocation rules. This allocation algorithm is designed and programmed in each instance specifically to requirement. In the case of a journey request, i.e. the destination call, the data related to persons and the installation and detected by way of an appropriate sensor system are passed on to the allocation algorithm and run through the algorithm for determination of the journey sequence.

If new additional journey requests arise during execution of a journey sequence, then the already computed journey sequence is modified to that effect. In that case, however, only simple modifications can be undertaken, which can have the consequence that only a modified journey sequence which is related to destination call and which is no longer the optimal journey sequence with respect to the changed preconditions is executed. Long waiting times and/or transport times for the passengers can result therefrom.
Moreover, interrelationships of individual control options, so-termed service requirements, are not always expressed logically and in unbroken manner in such a fixedly programmed allocation algorithm. Moreover the control software created in requirement-specific form for computation of the journey sequence is regarded as detailed and complicated. It is disadvantageous, in particular, that a once-created allocation algorithm can be subsequently adapted to different customer-specific control requirements only with substantial cost. In practice, for adaptation to changed service requirements a new lift-specific allocation algorithm has to be prepared in each case and implemented in entirety.

l The invention has therefore the object of stating a destination call control for lift installations, which apart from increase in transport performance is also constructed to be flexible and robust and takes into consideration, in particular, individual and/or collective transport needs of passengers.

For fulfilment of this object the invention is given by a method for journey sequence planning with the features given in claim 1, which is characterised in particular by the fact that a situation-based search process for determining the optimal joumey sequence is provided. A solution in terms of device is given by a destination call control according to the definition of claim 6, which proposes an organisation of the traffic volume with use of a so-termed planning system.

According to the invention there is thus provided in place of a previously employed, use-specific fixedly programmed control algorithm, a planning system which is known per se.
The planning system operates according to a situation-based search process and determines, related to destination call and proceeding from the instantaneous operational state of the lift installation and the objective state to be produced of the lift installation, the situation-specific optimal journey sequence.

The use in accordance with the invention of a situation-based search process essentially offers the advantage that in the case of any relevant change in the instantaneous situation, for example on registration of a new journey request, disruptions in execution of a journey sequence, or the like, a completely new actual journey sequence is determined -in the extreme case after each executed joumey sequence step - and the lift drive then executes this.

With each registration of a relevant change, for example, in the case of each destination call, the instantaneous operational state and the desired objective operational state of the lift installation are declaratively combined on the basis of facts in a state description. This state change, which is illustrated in the state description and which is to be achieved, of the lift installation is passed on to the planning system in translated form as a part of a situation representation, which is described further below. The situation-based search process thus has, with each registered destination call, complete information with respect to the traffic state of the lift installation. It can accordingly compute the optimal serving of the destination call for a fixed, predefined optimisation criterion. This computation process . _ ; ... ._. :...:. , ,. ...

is so designed that in fact the optimum can be found on the basis of the given criterion under real-time requirements.

The determined journey sequence plan is constructed by the planning system in such a manner that the desired state change can be achieved in execution of the journey sequence plan.

A lift installation with journey sequence planning in accordance with the invention consequently executes in each instance exclusively the journey sequence representing the optimum for the actual planning situation. The optimisation can in that case be carried out on the basis of entirely different criteria, wherein the objectives of optimisation result from increase in the performance of the lift, reduction in waiting times and/or serving times and journey times of the passengers or, however, improvement in a balanced journey management and the like.

The planning process is in advantageous manner limited in time in that computing performance and memory need are limited. The search process finds the optimal or approximately optimal joumey sequence within these restricted computing resources. So-termed 'anytime' algorithms for that purpose are known to the expert and can be used for such a search process.

According to an advantageous embodiment of the search process according to the invention the state description is passed on in translated form to the planning system preferably together with an operator description in the situation representation.

The operator description is communicated to the destination call control according to the invention at the time of configuration, preferably on installation of the system with the customer. It contains operators which specify elemental state transitions of the lift installation. The operators form, as elemental modules for the journey sequence solution to be constructed, the basis of the journey sequence plan to be determined. In the case of each destination call allocation or in the case of solution of a concrete planning task, the planning system selects the operators, which are to be used in the solution, from the operator description and determines concrete values for operator parameters as well as an arrangement sequence in which operators occur in the journey sequence plan.
This arrangement sequence specifies the execution sequence of the operators in the plan, thus the journey sequence.

By contrast to previous fixedly programmed allocation algorithms the planning system can be provided with any number of operators, including such which can serve service requirements not yet present on the side of the customer at the moment of installation. If these requirements arise at a later time, then it is merely necessary to communicate to the pianning system a corresponding situation representation in which these service requirements are formulated. The system can then immediately solve such tasks.
If service requirements arise for which no operators are provided, then the modularity of the operators in a planning system ensures that new operators can be added in or taken out in simple manner without the already present operators having to be influenced.
Lift installations can thus be adapted very simply and flexibly to changing customer needs with respect to traffic organisation by changing the number of operators available for control and also by the definition of the operators themselves.

In the case of control of a group of lifts by the destination call control according to the invention, consideration of the service requirements in continuous operation of the lift installation takes place without a separate reservation of a lift of the lift group having to be carried out for the passenger requiring the respective service. The lift control and the operators are matched to one another in such a manner that, in principle, any lift can at any time execute all special service requirements predetermined by way of the situation representation. If needed, the service requirement is quasi call-specifically integrated in the group operation.

The embedding of a planning system as core of the destination call control is possible in a central concept, a decentral concept or a combination of the central and decentral concept.

In the case of a construction of the destination call control with a so-termed central job manager this is a decision interface between the terminals and the individual job managers of the lifts. The terminals direct their transport enquiries to the central job manager. The job manager asks each of the job managers of the individual lifts for a transport offer for the respectively registered destination call, i.e. the so-termed job. It is in incumbent on the central job manager alone to manage all actual transport enquiries of passengers, i.e. the destination calls, and the booking of the transport requests, i.e. so-termed jobs, to the respectively selected lift. The terminals receive from the central job manager as a response the identification of the selected lift, which they thereupon display (for example 'A' or'B').

The communication between the terminals and the lifts is simple to organise, because all communication runs by way of a central control, i.e. the central job manager.
The organisation of the jobs takes place at a central job manager in a waiting queue, a so-termed 'first in, first out' data structure. This organisation is simple and secures a clear running sequence.

In the case of the central concept the terminals only have to process the destination call input of the passenger as well as the indication of the lift booked by the central job manager and require for this purpose only simple software. The use of simple and economic terminals makes this possible.

In the case of a decentral construction of the job manager, the terminals are connected by way of a capable communications network with the job managers of the individual lifts of a lift group. The terminals directly ask the job managers of the individual lifts for a transport offer for the respectively registered destination call. The terminals independently collect these offers, compare them and determine the optimal booking of the passenger.
In the case of a decentral job manager the organisation of the jobs takes place in parallel for several jobs, wherein a desired superimposition of enquiries and bookings is possible.

Further advantages of the decentral concept of the destination call control reside in the -by comparison with the central concept - faster reaction of the job manager to enquiries, an increased stability of the overall system due to the decentralisation and a simplified architecture of the job manager, since a separate central control does not have to be provided.

Insofar as the decentral embodiment is provided, the terminals are equipped with intelligent booking software. The communication between the terminals and the job managers of the individual lifts is preferably carried out by way of use of contract network protocols. The job managers of the individual lifts are themselves in a position to organise jobs in parallel and to correctly manage their status.

The central and decentral concept of the job manager can also be combined with one another in a destination call control. Any number of job managers, which control one or more lifts, can be present in a network.

According to a particularly preferred development of the invention the situation-based destination call control is represented as a multi-agent system, which realizes the entire controls of installation, wherein the planning system is an agent in this multi-agent system. The lift installation can comprise any number of lifts with any layout. Thus, several lifts can also co-operate with a different number of decks in one group, i.e. a so-termed heterogeneous multi-decker group.

The construction as a multi-agent system enables a modular implementation of the destination call control, in which individual components, i.e. the so-termed agents, for example planning system, doors, drive and taxi driver, can be exchanged as desired without the entire system having to be changed.

An event-controlled activation of the agents in a multi-agent system makes the system substantially more robust relative to occurring errors. If, for example, a shaft door at a storey breaks down due to a faulty contact, then either the job manager can cause an evacuation travel or, however, the taxi driver can initially allow the still-present plan to be executed. For further passenger enquiries, the fault can be communicated to the configuration manager which informs all relevant components of the system that temporarily this storey cannot be served by this lift. A failure of components does not signify immediate failure of the entire system as long as the safety of the passengers is guaranteed.

In a further aspect, the present invention provides a 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 arranged at storeys of the lift installation, characterised by the following method steps: (b) entry of destination calls in a situation representation for each lift, which situation representation defines the instantaneous operational state and the traffic situation of the lift, (c) calculation of an optimal journey sequence for each situation representation 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.

7a In a still further aspect, the present invention provides a destination call control for a lift installation for determining the journey sequence of one or more lifts of the lift installation with registration devices at storeys of the lift installation for registration of destination calls, characterised in that a processing unit is provided, which has for each lift a situation representation and a planner, which situation representation defines the instantaneous operational state and the traffic situation of the lift and which planner calculates an optimal journey sequence for each situation representation with consideration of a preselected optimisation criterion such as minimal waiting times and/or operating times and/or travel times of the passengers.

In a further aspect, the present invention provides a method for journey sequence planning of a lift installation, which comprises at least two lifts, consisting of: (a) registration of destination calls by a sensor system arranged at storeys of the lift installation, characterised by the following method steps: (b) entry of destination calls in a situation representation for each lift, which situation representation defines the instantaneous operational state and the traffic situation of the lift, (c) calculation of an optimal journey sequence for each situation representation with consideration of a preselected optimisation criterion comprising at least one of minimal waiting times, operating times, and 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.

In a still further aspect, the present invention provides a destination call control for a lift installation for determining the journey sequence of at least two lifts of the lift installation with registration devices at storeys of the lift installation for registration of destination calls, characterised in that a processing unit is provided, which has for each lift a situation representation and a planner, which situation representation defines the instantaneous operational state and the traffic situation of the lift and which planner calculates an optimal journey sequence for each situation representation with consideration of a preselected optimisation criterion comprising at least one of minimal waiting times, operating times, and travel times of the passengers.

7b Embodiments of the invention in which the destination call control is constructed as a multi-agent system for organisation of the traffic of a lift installation are illustrated in the drawing and explained in more detail in the following, in which:

Fig. 1 shows, schematically, the construction of a first embodiment of the destination call control with a decentral job manager for the control of an individual lift;

Fig. 2 shows a schematic illustration of the organisation of a pool of requested and offered jobs in a destination call control with a decentral job manager for control of a group of lifts;

Fig. 3 shows an instantaneous state description according to the first embodiment;

Fig. 4 shows a graphical illustration of the determined journey sequence plan according to the first embodiment;

Fig. 5 shows, schematically, the construction of a second embodiment of the destination call control with a central job manager as an interface between terminals and the individual lifts;

Fig. 6 shows, in a biock-circuit diagram, the organisation of the jobs in a waiting queue at a central job manager;

Fig. 7 shows an instantaneous state description of the lift A of the second embodiment;

Fig. 8 shows an instantaneous state description of the lift B of the second embodiment; and Fig. 9 shows the construction of an operator with a stop instruction, as used in the second embodiment.

Figure 1 shows schematically the construction of a destination call control 1 according to the invention with situation-induced journey sequence planning of the traffic volume of an individual lift. The destination call control is constructed as a multi-agent system. The basis of the multi-agent system is a capable communications network 2, by way of which three devices, which are distributed in the building, for destination call input, so-termed terminals 3.1, 3.2, 3.3, are connected with a decentral job manager 4.

In ideal manner, an architecture for spontaneous networking is selected as the communications network 2. In this embodiment an ad-hoc network, which is known per se, with the designation IRON is provided. IRON assists spontaneous networking and is thus a decisive precondition for a configuration-free control.

Known examples for architectures for spontaneous networking are 'Jini', 'Universal Plug and Play' and 'Bluetooth'. In such a communications network 2 apparatus capable of networking, so-termed agents, log-on and interact without need for a configuration or an administration. The integration of all these apparatus and the services implemented thereat run fully automatically. The most important methods of such a communications network 2 are 'register', 'lookup' and 'notify'.

- Through 'registration', the individual apparatus log-on in the network and make their services known.
- Through 'lookup', one apparatus can find another apparatus or a required service.
- Through 'notification', one apparatus can log-on at another for information about the entry of specific events.

In a lift group, terminals, drives, cage doors, central job managers and/or decentral job managers log-on as apparatus capable of networking.

- Terminals log-on in the network with their storey position and x,y-co-ordinates in the network and inform themselves about all job managers present.
- Drives represent the physical components of the lift control. They make information available about which storey they can travel to, how many shaft doors are located at a storey and at which side these are positioned. In addition, information can be subscribed to at the drive with regard to specific events such as change of the selector and change of the state (for example, travelling, arriving, stationary).
- Cage doors log-on with information about the drive to which they belong, the deck at which they are disposed and the side at which they open. By way of this information the job manager immediately finds out how many decks a lift has and how many doors per deck are present.
- Job managers log-on in the network with information about which drives they represent; a single one in the strictly decentral concept or all those present in the strictly central concept.

In principle any number of components can log-on in the network. The traditional group concept of lifts is thus superfluous and, in particular, any number of lifts with quite different layouts can be present in one group.

If, for example, eleven drives log-on, of which three have only one door, four each have three doors on two decks and four each have six doors uniformly distributed on three decks, then there is present an example of a so-termed heterogeneous multi-decker group consisting of - three single-deckers with only one door - four double-deckers, wherein one deck is equipped with one door and the other decks with two doors - four triple-deckers, in which each deck has two doors.

The job manager of each individual lift is in a position of recognising, and correctly processing in the control, the number of decks and doors of its associated drive. This comprises in particular:

- The planning system plans, in the case of a multi-decker, the boarding and alighting of the passengers by way of all decks which are present.
- The taxi driver of the job manager transmits at a stop the door opening commands to all doors which open at storeys at which passengers wish to board or alight.

In the case of the IRON communications network 2 used here, agents can mutually inform about changes and prepare and integrate data in the own operating logic. An agent can find out, via broadcast, which other agents have logged-on in the network and transmit communications to other agents. Moreover, an agent can subscribe to data at another agent.

The individual components of this multi-agent system - the so-termed agents -are, apart from the above-mentioned terminals, the job manager 4 which integrates all components necessary for the logical and physical control of a lift. These are here a planning system or planner 5, a broker 6, a door manager 7, a taxi driver 8, the drive 9 of the lift and an observer 10.

The terminals 3.1, 3.2., 3.3 are equipped with intelligent booking software and directly ask each job manager 4 for a transport offer for the respectively registered destination call.
The communication between terminals and job managers 4 is carried out by means of contract network protocols. Each of the terminals 3.1, 3.2, 3.3 is equipped with a device for identification of passengers, to which a configuration manager 11 belongs.

The actual building layout, such as, for example, the number of storeys, access zones, division of the passengers into passenger groups, access authorisations, service requirements, etc., and passenger data are stored in the configuration manager 11 to be capable of calling up. On registration of a destination call, each terminal can call up passenger data from the configuration manager 11 and pass the data on to the broker 6.
Thus, each terminai can, for example, check whether the registered passenger has access permission for the desired destination storey. If the check is successful, then the terminal asks the job manager 4 of the lift for its transport offer.

The planner 5 itself plans the optimal serving of the new passenger with consideration of the actual, lift-specific traffic situation and in that case produces an optimal plan which is then passed on to the broker 6, which is described further below, for control of the drive 9 of the lift. The starting point for the planner 5 is a situation representation which is actual at each point in time at which the broker 6 records new passengers, whereas the observer removes conveyed passengers.

The broker 6 communicates with the three terminals 3.1, 3.2, 3.3 by way of a two-stage contract network protocol. It receives the inputs of the terminals 3.1, 3.2, 3.3, records them in the situation representation of the planner 5, checks the generated optimal plan with respect to the effect of the newly included passenger on the transport of the already booked passengers and communicates the transport offer to the terminal. If no plan could be found because, for example, the problem cannot be solved due to insoluble conflicts between the passenger groups for this lift, then the broker 6 also informs the . . _ , : :. . , .... .
. .. . .. _.: . .:.,_. .:._ :..

corresponding terminal about that fact. If the passenger is booked then the broker 6 sends to the taxi driver 8 the actual journey sequence plan. The terminal now carries out the indication on the display.

The observer 10 monitors the state of the lift installation and updates the situation representation for the planner 5. If it thus establishes that the lift has stopped at a storey and the doors were correctly opened, then all passengers are flagged as -served- for whom -boarded- applies and the destination of whom corresponds with the storey.
Passengers still waiting there are flagged as -boarded-, since they board when the lift has arrived at them. The observer 10 in that case has no knowledge of the plan or the activities of the taxi driver 8, but is supported solely on the information to which it has subscribed at the drive 9 and at the door manager 7. This is a precondition also for the occurrence of a special operation such as, for example, triggering of the control in the case of fire, which control takes over controlling by way of the drive 9 and interrupts the taxi driver normal operation in order to ensure that the situation representation is correctly updated in correspondence with the actually occurring changes in state.

The taxi driver goes over its respective actual plan, i.e. it transmits the corresponding commands to the drive 9 of the lift and the drives of the doors. It knows from its actual plan where the lift is to next stop in accordance with schedule and how long the doors have to be open so that all passengers have sufficient time for boarding and alighting.
How many passengers change state at a stop was already determined by the planner 5. If the taxi driver 8 no longer has a plan, then it releases the lift so that this can be parked. In any situation the taxi driver 8 can exchange its actual travel plan for the actual plan sent thereto by the broker 6. How this change takes place depends on in which implementation state the taxi driver is disposed. Thus, for example, it is necessary that a stop process, once begun, of the old plan must firstly be concluded before the taxi driver 8 can travel to the first stop of the new plan.

The drive 9 executes the travel and stop commands which it obtains from the taxi driver 8 and, in addition, it learns the travel times of the lift between the individual storeys. It ' makes the travel timetable available to the planner 5 for the optimisation and also reports where the lift is actually disposed and in which direction it travels or whether it has just stopped.

The door manager 7 manages all doors of the lift and monitors whether the doors correctly open and close. In that case, doors can be present on different sides of the cage. It also determines the door opening and closing times of the doors and communicates them to the planner 5 for optimisation of the serving times of the passengers.

Each of the components is implemented as an independent agent which executes independent actions in the case of occurrence of specific events. In particular, the most diverse events can thereby be superimposed. Thus, for example, the broker can simultaneously receive the enquiries of different terminals 3.1, 3.2, 3.3 and submit them to the planner 5. The decentral job manager can make parallel delivery of an offer for several jobs whilst the booking of other jobs is still outstanding. The jobs are obligatory only when the corresponding terminal books.

Since between the delivery of the offer by the broker 6 and the booking by the respective terminal a time period of any length can in theory pass, it is possible that in the interim another terminal has already placed a booking. In this situation the broker 6 must check whether the delivered offer is still valid when the terminal now sends its booking. This random superimposition of enquiries and bookings makes it necessary for the terminal to wait for an acknowledgement of its booking and, in the case of absence of an acknowledgement, to seek an altemative booking at another job manager 4. If the replanning is also unsuccessful because the situation in the lift has, for example, changed in such a manner that irresolvable conflicts between the already booked passenger and the new passenger to be booked now arise, then the terminal receives a corresponding feedback.

Figure 2 shows a pool of requested and offered jobs Job 1 to Job 4 at a decentral job manager 4. Each terminal 1,2 usually has only one concrete job Job X or Job Y
which it wishes to book at a lift. It accordingly sends this job to all job managers 4, which are known to it, of the group of lifts of which it knows from the drive data whether the associated lift can serve not only the boarding storey but also the alighting storey, of the passenger. Unnecessary requests to lifts which do not, in principle, come into question for the transport, are thus avoided.

Two kinds of jobs are present at the decentral job manager 4: these are, on the one hand, jobs, i.e. the Jobs X, which were requested and for which the job manager 4 has to compute an offer, and on the other hand Jobs Y for which the job manager 4 has already delivered an offer, but does not yet know whether the terminal is actually booked with it.

In the case of the first embodiment illustrated here and shown in Figure 1 only a single lift is present. The lift can, however, also be part of a lift group. The invention is usable, without restriction, for such lift groups. In the case of a lift group, also, the terminals 3.1, 3.2, 3.3 directly ask the job managers 4 of the individual lifts for a transport offer. The terminals 3.1, 3.2, 3.3 independently collect these offers, compare them and compute the optimal booking of the passenger. Each lift subject of an enquiry computes independently of the others and with consideration of the actual lift-specific traffic situation its optimal journey sequence plan for serving the new passenger. The offer of each lift subject of an enquiry is sent back to the terminal, which selects the best offer and commissions the corresponding lift with the transport of the passenger. If the job manager 4 confirms the booking relative to the terminal from which the transport offer had been requested, then the booking is obligatory and is indicated to the passenger at the terminal.
If a job manager no longer reports, then the terminal also reacts thereto and does not wait endlessly for the lacking offer.

The mode of operation of the destination call control according to the invention as described so far is, according to Figure 1, described in the following by way of the example of a planning problem of a lift installation with only a single lift with a single-door cage, which services a building (not illustrated here) with stopping points at seven storeys f1 to f7. The lift cage stands, at the moment, at storey M. A passenger P1 waits at storey f2 and wants to go to storey f7 and a further passenger P2 is already in the cage and wants to go from storey f1 to storey f5. The journey sequence of the cage is to be organised in accordance with the invention by means of planning system 3.

The characteristics of the lift, i.e. the instantaneous operational state of the lift, are detected and actualised in the situation representation by the observer 10.
The characteristics of the passengers P1, P2 and particularly the destination calls of the passengers P1, P2 are passed on by way of terminals 3.1, 3.2, 3.3, in conjunction with the configuration manager 11, as input magnitudes of the destination call control 1 to the broker 6, which records them in the situation representation of the planner 5, as shown in Fig. 2.

Thus, in each planning process, which is started, for example, by registration of a destination call, the determined operational state and the desired objective state, thus the change in state of the lift to be achieved, are declaratively combined in a state description 14 comprehensible for the planning system 3, which is illustrated in Figure 3.

The state description 14 depicted here in Figure 3 is expressed in the plan representational language PDDL according to McDermott et al., 1998. There are known to the expert also other modelling languages which differ with respect to their expressive power and which the expert can use for description of the situation representation without thereby changing the core of the invention. However, in selection of a planning system attention is to be given to the fact that this makes available planning algorithms of appropriate power for the modelling.

The reported passengers P1, P2 and the storeys f1 to f7 of the building are initially made known to the planning system 3 in an object declaration 15 in the state description 14 illustrated in Figure 3. A typified constant is imported for each object. For the lift 2 under consideration here, these are the waiting passenger P1, the passenger P2 already in the cage and all seven storeys f1 to f7.

(:objects (p1 - passenger) (p2 - passenger) (f1, f2, f3, f4, f5, f6, f7 - floor)) The broker 6 obtains details with respect to the topology of the building from the configuration manager 11. This is to be found as a topology description 16 in the state representation 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 the topology description 16 the (upper ?fi, ?fj) prescriptions establish in each instance that the storey fj lies above the storey fi. The representation of the building topology is not absolutely necessary. In a simplification, the explicit topological description 16 of the building can be dispensed with in other embodiments of the method subject to the assumption that from each storey every other storey can be served by the lift.

The actual transport request 17 with the destination calls of the passengers P1 and P2 consisting of boarding storeys, i.e. 'origin', and destination storey, i.e.
'destin', is represented as (:init (origin p1 f2) (origin p2 f1) (destin p1 f7) (destin p2 f5) (boarded p2).

The transport request 17 additionally contains, from a joumey sequence planned earlier, the information 'boarded p2', namely that passenger P2 has already boarded and is in the cage. This information was inserted into the state description by the observer 10.
Fundamentally, within the scope of the joumey sequence planning each passenger P1, P2 occupies the three states: 'waiting', 'boarded' and 'served', which are defined as follows:

- waiting: the passenger waits in front of the lift door. Here the lift is initially to stop at the starting location, i.e. 'origin', of the passenger and only thereafter at the destination storey, i.e. 'destin', indicated by the passenger.
- boarded: the passenger is located in the lift cage and is transported to his or her destination storey, i.e. 'destin', which has not been travelled to previously, i.e.
served.
- served: the passenger has left the lift cage at his or her destination storey, i.e.
'destin'. This transport request is concluded and the passenger was satisfactorily served by the lift.

' ' _ _._. .... __ These three possible states can be expressed by means of the two commands -boarded ?p- and -served ?p- in the PDDL modelling language. The passenger P1 waits for a lift cage and accordingly is registered neither as -boarded- nor as -served-.

The observer 10 sets the actual position 18 of the lift cage, which is expressed in the state representation 14 as (lift-at f4)).

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

The shortest sequence of stops which transfers all passengers P1, P2 into the state of -served- is now sought, this being achieved precisely when the passengers have alighted at their destination storey -destin-.

Apart from the descriptions of the initial state and the objective state of the planning problem by the state description 14, there is transferred to the planning system 3 also an operator description 12. In the embodiment illustrated here, a stop operator as well as an operator for upward travel -up- and an operator for downward travel -down- are transferred for the modelling of the state transitions between initial state and objective state. As an alternative to these operators -stop-, -up- and -down-, the expert also knows other operators by which the desired change in the lift state can be achieved. In a given case and with appropriate definition of the parameters, the core of the invention is not thereby changed. In PDDL syntax according to McDermott et al., 1998, the following stop operator is here available:

(define (domain miconic) (:requirements :adl) (types passenger - object) floor - object) (:predicates (origin ?person - passenger ?floor - floor) ....,:. ..:.:, .:.. _.. ...: . ... .._ . . _ .. .: ._:..:. -...''.'.:-."."_....: _... ~.: . _. C... . . }~_ .. . . . .. ..!f.. ..
. .. _ . . _ . _ _ . . . . . .. . . ..= . .. ~='. . .. . . .

IP 1310 PCT I$
(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 operator for the upward travel is represented as:
(: action up parameters (?fl - floor ?f2 - floor) precondition (and (lift-at ?f1) (upper ?f1 f2)) effect (and (lift-at ?f2) (not (lift-at ?fl)))) The operator for the downward travel is expressed as:
(: action down parameters (?f1 - floor ?f2 - floor) precondition (and (lift-at ?f1) (upper ?f1 f2)) effect (and (lift-at ?f2) (not (lift-at ?fl)))) The stop operator signals to the control of the drive 9 of the lift that the cage has to stop at a specific storey f1 to R. The stop operator is so defined in the example of embodiment illustrated here that it includes the opening and closing of the doors. The opening and closing of the cage doors can, however, also be considered as a separate additional basic instruction to the door manager 7 of a lift 2 or the stop operator can be refined to the effect that a lift can also open and close the doors.

The operators for upward travel -up- and downward travel -down- give the instructions in terms of control technology to the drive control to set the drive 9 into operation in the appropriate direction. The taxi driver 8 presets the sequence in time in which the drive 9 is controlled by means of the operators.

A change in the passenger state is possible basically exclusively at a stop of the cage.
Proceeding from rational behaviour of the passengers, in the case of a scheduled stop of the lift cage at a storey all passengers who wait at this storey -origin- in order to be transported in the cage get on board and all passengers leave the cage when this stops at their destination storey -destin-. The thereby occurring change is here registered in the stop operator with the help of the observer 10 and thereby taken into consideration in the journey sequence pianning of the planning system 5. Like the operators -up-and -down-, the stop operator is then also effective as an instruction for the drive 9 if the criteria coded in -effect- are all fulfilled or entered. If, in the example described here, ?f = f5 is selected in the stop operator, then P2 disembarks in correspondence with the state description 14 and the behaviour model when -boarded p2- and -destin p2 f5- apply as described in the stop operator as -effect- of the operator instance stop(f5).

The data to that extent declared either in the operator description or as data of the state description 14 are passed on to the planning system 5 for computation of the optimal journey sequence plan.

Planning systems 5 are already known from other technical fields. In this example an IPP
planning system 3, as appears from Koehler et al., 1997, 'Extending planning graphs to an ADL subset', in Steel, S, Proceedings of the 4th European Conference on Planning, pp.
273-285, Springer, Vol. 1348 of LNAI, available under http://www.informatik.uni-freiburg.de/-koehter/ipp.html, searches for an applicable sequence of STOP
instructions which fulfills the planning objective 13 (:goal(forall (?p - passenger) (served ?p)). Other planning systems can also be used insofar as these are in the position of generally detecting and processing the instantaneous situation representation.

In principle, the planning system 5 independently selects, in the case of input of the state description 14, instances on the basis of the operators made available by way of the operator description and also determines the sequence in the ascertained journey sequence plan 20. The planning system 5 determines each time the parameters for the three operators -stop-, -up- and -down-, which produce a desired change in state.

The result thereof is, in this embodiment, a planned journey sequence, i.e.
the optimal plan, which is represented in graphical form in Fig. 3.

Time step 0: up f4 f5 Time step 1: stop f5 Time step 2: down f5 f2 Time step 3: stop f2 Time step 4: upf2f7 Time step 5: stop f7 This computed optimal plan 13 is passed on to the broker 6. The broker 6 thereupon checks the generated optimal plan, how the newly planned-in passenger P1 has an effect on the transport of the already booked passenger, and communicates the transport offer to the terminal.

In the embodiment described here only a destination call is present for the planning.
Consequently, an offer is to be delivered only for one job. Accordingly, no other jobs are booked by other terminals 3.1, 3.2, 3.3 between the offer computation by the decentral job manager 4 and the booking by the respective terminal. For this reason the acknowledgement of its booking at the terminal is redundant, but the booking is immediately obligatory. The terminal now undertakes the indication on the display and the broker transmits to the taxi driver 8 the actual optimal joumey sequence plan 20.

The taxi driver 8 goes over this actual joumey sequence plan 20, i.e. it transmits the corresponding command in the form of respective operators to the drive 9 of the lift and to the drive of the doors.

This journey sequence plan 20 has the effect that the lift cage in step 0 travels from the actual storey f4 at which it is disposed to the next stop at storey f5, -stop f5-. There the lift cage stops according to step 1 -stop f5- and the cage door opens at the predetermined time, so that the passenger P2 alights and is thus served, 'served'. In step 2, the lift cage travels downwards from f5 to f2 -down f5 f2- and stops in step 3 at storey f2 -stop f2-.

There passenger P1 boards. In step 4 the lift travels upwards from storey f2 to f7 -up f2 f7- and stops in the last step 5 at storey f7 -stop M. There also passenger P1 can now alight. Through this journey sequence 13 all passengers P1, P2 are transferred into the state -served- and the objective formulation 10 of the journey sequence plan is thus achieved.

Whilst the taxi driver 8 executes the optimal journey sequence plan 13, the observer 10 monitors the state of the lift installation and continuously updates the situation representation for the planner 5. In step 1 it thus establishes that the lift has stopped at the storey f5 and the doors were opened correctly; it flags the passenger P2 as -served-.
In step 2 the observer 10 flags the passenger P1, who waits at the storey f2, as -boarded-.
Subsequently, the lift cage stops at the storey f7 and, after the doors have been correctly opened, the observer 10 also sets the passenger P1 in the situation description as 'served' and the actual position 9 of the lift cage in the state representation 5 at storey f7.

This generated journey sequence plan 20 does not, however, necessarily have to be fully executed, but if the state or the characteristics of passengers and/or the installation change in relevant manner before it is completely executed, according to the invention a next planning cycle is started and an optimal journey sequence plan 20 for the new planning situation is created. No plan modification therefore takes place.

Figure 5 shows schematically the structure and basic build-up of a second embodiment of the destination call control according to the invention. The destination call control 25 comprises a central job manager 26 and two decentral job managers, a configuration manager 29 as well as a terminal 30 representative of all terminals present, these components being interconnected by way of a communications device 31. The build-up and function of the decentral job managers 27, 28 substantially correspond with those of the decentral job manager 4 of the first embodiment.

The destination call control is here organised as a so-termed group control of the traffic of a lift group with two lifts A and B in a building with stopping points at seven storeys. The planning task in that case is represented as follows:

The lift cage A travels, at that moment, upwardly; it is disposed at that instant at storey f2 and can still reach the storey f3. The lift cage B stands at that instant at the storey f1. Lift A transports a passenger P1 who has access restriction to storeys 3 and 4 and who has indicated storey f7 as the destination, whereas lift B is empty. In this situation a new passenger P2 appears who, as a VIP, has to be conveyed as a matter of priority before all other passengers. Passenger P2 has just delivered his or her request for transport from storey 3 to storey f7.

An allocation of the passenger P2 to one of the two lifts A, B known in the example is thus undertaken in the manner that the passengers P1, P2 are conveyed with the least possible stops and that the desired service requirements 'VIP' and 'access restriction' are fulfilled.
The central control manager 26 collects the requests of the terminals together with the respectively detected person-related data from the configuration manager 29 as so-termed jobs, here Job 1 to Job 4, in a waiting queue, as illustrated in Figure 6. It selects the first Job 1 from the queue and transmits this to the decentral job managers 27, 28 of the individual lifts. Each of the decentral job managers 27, 28 of the lifts A, B
ascertains, independently of the others and with the help of its planning system, its best joumey sequence solution on the basis of the predetermined optimisation criterion and sends this as an offer back to the central job manager 26. The central job manager 26 checks all offers, selects from these the best offer and books the passenger on the lift with the best offer. The identification of the best lift is transmitted, after a successful allocation, to the terminal 30 at which the job was originally initiated. The terminal 30 thus merely functions as a display. The Job 1 is thus dealt with and is cancelled. The process is repeated only with the Job 2, etc., until all jobs of the waiting queue have been worked through.

Each decentral job manager 27, 28 of the lifts A, B initially creates, for the registered data information communicated as a job for the actual planning task, a situation representation which is transferred to the respective planning system 21. The situation representation contains a state description 32 and an operator description.

For the lift A, in an object declaration 33 the reported passengers P1, P2 and the storeys f1 to f7 of the building are made known to the planning system. A typified constant is introduced for each object. Moreover, an association with one or more service requirements, such as, for example, 'VIP', 'conflict', 'going_direct', etc., is carried out in an object declaration 33 for each passenger P1, P2 The service requirements are known in each case within the scope of the passenger recognition from the configuration manager 29 and passed on from the central job manager 26 as part of a job, or an offer enquiry, to the decentral job managers 27, 28 of the individual lifts A, B. Specific service requirements for all or any selected passengers can be provided to be activatable in dependence on the state of the lift installation or the building or even in dependence on the time of day. In addition, through the use of a planning system for the journey sequence determination there can be represented a flexible weighting of the individual service requirements, especially the VIP
requirement, in dependence on traffic volume.

Here the following service requirements are provided:

- Division of all passengers into two groups 'conflict A' and 'conflict_B', who may never go into the lift;
- Passengers of the type 'never_alone', for whom a companion in the form of a - passenger of the type 'attendant' must be present in the lift during the joumey. In that case it is not absolutely necessary that always the same companion travels in the lift during the journey, but this can also change;
- Passengers of the type 'going_direct', who are conveyed to their destination without an intermediate stop;
- Passengers of the type 'vip', who are conveyed as a matter of priority before all other passengers;
- Passengers for whom an access restriction to specific storeys is formulated;
- Passengers of the type 'going_up', who are transported exclusively upwards;
- Passengers of the type 'going_down', which are transported exclusively downwards.

A passenger P1, P2 can thus quite readily be the subject of a number of service requirements; however, these should not conflict, so that the passenger can also be efficiently conveyed. Two passengers P1, P2, for example, are an elemental conflict, for which the following typification is declared:

(P1 (either conflict A never alone)) (P2 (either conflict_B attendant)) . _ .:, . . .. .. . . . .. . . ._ . . .. . ._. .. .. ,.. _ . _ _. x . -._ P1 here may not travel solely in the lift and belongs at the same time to the passenger group A. The single possible companion P2 known to the system belongs, however, to the passenger group B; the passenger group A may never go into the lift. An accompanying thus infringes the exclusion condition and P1 can only be conveyed when another companion, who does not belong to the group B, becomes known to the system.

For lift A the object declaration 33 contains the already travelling passenger P1, i.e. a normal passenger, the new passenger P2, i.e. a VIP, and all seven storeys f1 to R.
(:objects (p1 - passenger) (p2 - vip) (fl, f2, f3, f4, f5, f6, f7 - floor)) In this embodiment an express description of the building topology is dispensed with on the assumption that from each storey each other storey can be served.

The actually registered transport request 34 of the passengers P1 and P2 is represented as (:init (origin p1 f1) (origin p2 f3) (destin p1 f7) (destin p2 f7) (boarded p1) Fundamental to the transport request 34 is the standard assumption that passengers wait at the storey when no corresponding 'boarded' information is present.
Precisely, this signifies here that passenger P2 waits at the storey. The access restriction for passenger P1 is represented therein as (no-access p1 f3) (no-access p1 f4) The actual position 35 of the lift cage 2 of the lift A is expressed as . ... .. .

(lift-at f2)) in the state description 32. All expressed facts are weighted as true and all others as false.
The objective 36 for the planning system is formulated as (:goal (forall (?p - passenger) (served ?p)).

The shortest sequence of stops which transfers all passengers P1, P2 into the state of 'served' is sought, which is achieved precisely when they have disembarked at their destination storey or storey R.

Since in this embodiment only a minimal stop sequence is to be determined, the planning system also receives only one so-termed stop operator 37, from which the system can construct a valid journey sequence plan. In Fig. 9 there is illustrated an example of a stop operator 32. The modelling language PDDL according to McDermott et al., 1998, here too serves for pictorialisation as before in the state description 32. The stop operator 37 contains a prescriptive description 38 in which it is described when a stop of a lift A, B at a storey f1 to f7 is permissible. Here the access restriction -no-access- which in that case is defined concretely either for a passenger or, however, for a passenger group, and a function instruction 39 in which it is established at which storey f1 to f7 a lift cage shall stop at a permissible stop and what effect this stop has on the actual state of the lift installation 18. Preconditions of the function instruction 39 in that case represent the user-specific conversion of the desired service requirements. The complex stop operator shown in Figure 9 makes it possible to bypass the planning system 21 by all service requirements imported into the passenger and object deciaration 33.

For the planning example described here, only the preconditions, which are underlined in Fig. 5, of the operator 32 are relevant, which preconditions formulate the conditions at a stop at a storey f1 to f7 in the presence of VIPs and passengers with access restriction.
The instantaneous situation representation 32 created to that extent for each lift A is passed on to the planning system belonging to the lift A.

. ..... . ,. . . . , ._ ,,:. .:. . _. . . _ -. ..
.. . . ,.. .._ -.: . _... .. ., ... .-.: r..,.. .: _ ..:.:,:.. ... :::. ,:.._ ,.::...,:..., .

.

The suitable planning systems used in accordance with the invention operate independently of the actual planning problem. Such planning systems are already known from other technical fields.

In this second embodiment, too, an IPP planning system, as known from Koehler et al., 1997, Extending planning graphs to an ADL subset, appearing in Steel, Proceedings of the 4th European Conference on Planning, pp. 273-285, Springer, Vol. 1348 of LNAI, and available under http://www.informatik.uni-freiburQ.de/-koehler/ipp.html, seeks a valid sequence of STOP instructions which fulfill the planning objective 31. Other planning systems can also be used insofar as these are in a position of detecting and processing the instantaneous situation representation in its entirety.

In solving a concrete planning task, the planning system selects the operators, which are to be used in the journey sequence plan, of the operator description 23, here the stop operator 37. If service requirements, such as, for example, 'VIP', 'going_direct', etc., occur in the state description 32, then the planning system independently checks the corresponding preconditions of the function instruction 39 of the operator 37.
If a service requirement contained in the operator 37 as a precondition is absent in the call-relevant state description 32, then this is automatically disregarded as a superfluous precondition of the operator 37. An example of a service requirement not taken into consideration here is the precondition -attendant-. Concrete values for operator parameters as well as an arrangement sequence in which operators occur in the journey sequence plan are then determined. This arrangement sequence specifies the execution sequence of the operators in the joumey sequence and thus the joumey sequence for serving the respective destination call.

The planning system cannot find a solution for lift A: passenger P2 shall be immediately conveyed, i.e. the lift A has to stop at f3. However, P1 is in the lift and has no access to M.
A stop at f3 is thus possible only after P1 has disembarked, i.e. the lift A
must first travel to storey f7; this in turn is not allowed, since the VIP condition requires VIPs to be conveyed ahead of all other passengers.

The situation 42 can be solved by the planning system for the lift B (Figure 8) without problems, since lift B does not know the passenger P1 at all, because he or she is in fact underway in the lift A and only the new passenger P2 is reported. The object declaration 43 for lift B at the planning system consequently contains also only the new passenger P2, who is typified by the service requirement VIP, and all seven storeys f1 to f7.

(:objects (p2 - vip) (f1, f2, f3, f4, f5, f6, f7 - floor)) Moreover, from each storey each other storey can be served.

The actual transport request 44 of the passenger P2 is represented as (:init (origin p2 f3) (destin p2 f7).

The actual position description 45 of the lift cage B is expressed in the state description 42 as (lift-at f1).

In the case of the lift B, the objective formulation 46 for the planning system is identical with that of the lift A. It is transferred to the planning system together with the object declaration 43 and the above-described stop operator 37 as part of the situation representation 42 of the lift B. For planning of the journey sequence of the lift B, only the operator precondition 'stop at a storey in the presence of VIP' is relevant, because the state description 32 for lift B also transfers to the planning system only the service requirement VIP. All remaining service requirements provided in the form of prescriptions 33 and preconditions of the function instruction 39 of the STOP operator 37 remain unconsidered in this planning sequence and accordingly without effect on the joumey sequence plan 24.

The planning system 21 generates, starting from this input, the following joumey sequence plan for lift B:

time step 1: (stop 3) a ._. .::. :..'. ':_ . ,.....:.... ...: ":.:_.. .... . :4; ... . .. ..' -:: ..-.'.r :: ,-.:a-: ...-:. t.. . .. ' '-_.'..i:~i! ._..J'.+A -Y}.y .,:;. ',. "
- .:..' :,.v .. . .:.. .:- . . y;:.=.. ' '. . .. . .. _ ., j time step 2: (stop 7), which represents a minimum stop sequence for successful conveying of the passenger P2.

If the results of the joumey sequence plan of the lifts A, B are entered at the central job manager 26, this then weights the two joumey sequence offers of the lifts A, B. The lift with the best offer is selected by the central job manager 26. The best solution is here the single possible journey sequence plan of the lift B. Consequently the central job manager books the passenger P2 on the lift B. Lift B also actualises the joumey sequence plan after receipt of the booking; all other lifts carry on travelling in accordance with their previous plan.

Claims (12)

The embodiments of the invention in which an exclusive property or privilege is claimed are defined as follows:

1. Method for journey sequence planning of a lift installation, which comprises at least two lifts, consisting of:
(a) registration of destination calls by a sensor system arranged at storeys of the lift installation, characterised by the following method steps:
(b) entry of destination calls in a situation representation for each lift, which situation representation defines the instantaneous operational state and the traffic situation of the lift, (c) calculation of an optimal journey sequence for each situation representation with consideration of a preselected optimisation criterion comprising at least one of minimal waiting times, operating times, and 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, that each lift has a job manager, which job managers are asked, for each registered destination call, by the central job manager for a transport offer, that transport offers corresponding with the requests are communicated by these job managers to the central job manager and that a journey sequence optimal with respect to the optimisation criterion is booked by the central job manager 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, which job managers are, for each registered destination call, asked for a transport offer, that transport offers corresponding with the request are made by the job managers 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 any one of claims 1 to 3, characterised in that destination calls are registered at registration devices of the storey and that a lift corresponding with a booked journey sequence is indicated at the registration device which has registered the destination call.

5. Method according to any one of claims 1 to 4, characterised in that the situation representation contains operators which specify elemental state transitions 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 at least two lifts of the lift installation with registration devices at storeys of the lift installation for registration of destination calls, characterised in that a processing unit is provided, which has for each lift a situation representation and a planner, which situation representation defines the instantaneous operational state and the traffic situation of the lift and which planner calculates an optimal journey sequence for each situation representation with consideration of a preselected optimisation criterion comprising at least one of minimal waiting times, operating times, and 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 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 is provided, which receives all registered destination calls by way of communications network from the registration devices, that each lift comprises a job manager, that the central job manager asks, for each registered destination call, these job managers by way of the communications network for a transport offer, that these job managers communicate transport offers, which correspond with the request, to the central job manager by way of the communications network and that the central job manager 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, that a registration device asks, for each registered destination call, these job managers by way of a communications network for a transport offer, that these job managers communicate transport offers, which correspond with the request, by way of the communications network to the requesting registration device and that this registration device 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 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 any one of claims 7 to 11.