[go: up one dir, main page]
More Web Proxy on the site http://driver.im/

EP1276691B1 - Zielrufsteuerung für aufzüge - Google Patents

Zielrufsteuerung für aufzüge Download PDF

Info

Publication number
EP1276691B1
EP1276691B1 EP01914940A EP01914940A EP1276691B1 EP 1276691 B1 EP1276691 B1 EP 1276691B1 EP 01914940 A EP01914940 A EP 01914940A EP 01914940 A EP01914940 A EP 01914940A EP 1276691 B1 EP1276691 B1 EP 1276691B1
Authority
EP
European Patent Office
Prior art keywords
lift
elevator
destination call
job
registered
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Revoked
Application number
EP01914940A
Other languages
English (en)
French (fr)
Other versions
EP1276691A1 (de
Inventor
Jana Koehler
Kilian Schuster
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Inventio AG
Original Assignee
Inventio AG
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Family has litigation
First worldwide family litigation filed litigation Critical https://patents.darts-ip.com/?family=26070754&utm_source=google_patent&utm_medium=platform_link&utm_campaign=public_patent_search&patent=EP1276691(B1) "Global patent litigation dataset” by Darts-ip is licensed under a Creative Commons Attribution 4.0 International License.
Application filed by Inventio AG filed Critical Inventio AG
Priority to EP01914940A priority Critical patent/EP1276691B1/de
Publication of EP1276691A1 publication Critical patent/EP1276691A1/de
Application granted granted Critical
Publication of EP1276691B1 publication Critical patent/EP1276691B1/de
Anticipated expiration legal-status Critical
Revoked legal-status Critical Current

Links

Images

Classifications

    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B66—HOISTING; LIFTING; HAULING
    • B66B—ELEVATORS; ESCALATORS OR MOVING WALKWAYS
    • B66B1/00—Control systems of elevators in general
    • B66B1/02—Control systems without regulation, i.e. without retroactive action
    • B66B1/06—Control systems without regulation, i.e. without retroactive action electric
    • B66B1/14—Control systems without regulation, i.e. without retroactive action electric with devices, e.g. push-buttons, for indirect control of movements
    • B66B1/18—Control systems without regulation, i.e. without retroactive action electric with devices, e.g. push-buttons, for indirect control of movements with means for storing pulses controlling the movements of several cars or cages

Definitions

  • the invention relates to a destination call control for elevators as defined in the claims.
  • an elevator control is used to Cabin calls on the different floors of a building to use.
  • the drive of an elevator knows as commands just the instructions - drive up -, - drive to below -, - door open - and - door closed -.
  • a Destination call control give the passengers already before the Entering an elevator, or an elevator car her desired destination floor, for example via a telephone-like keyboard, a so-called terminal. Out the position of the terminal is the access floor for the Destination call control known. After entering the Destination floor, determines an allocation algorithm of Control the elevator of the elevator group, which for the passenger the fastest and most comfortable transport his goal. The terminal shows the passenger this elevator the group of elevators and the passenger can now rest in the appropriate marked elevator issued. If the elevator stops to get in, the destination will be of the passenger, for example via a display device confirmed in the door frame. In the cabin itself are no Buttons for entering targets more available. To this Way, by using a destination call control Passengers with identical transport destination are grouped and thereby increases the transport capacity of the elevator system become.
  • An example known from EP 0 699 617 A1 Destination call control is also capable of individual Identify passengers. For each identified Passengers are granted access to one Information store additional information regarding Entry and exit position, its space requirements and possibly additional service requirements, in which Determination of the optimal transport option considered.
  • the invention is based on the object Specify destination call control for elevator systems, which are next to an increase in transport performance also flexible and is robust and in particular individual and / or collective transport needs of passengers considered.
  • the invention is given by a Method for sequence planning with the in claim 1 given characteristics, which in particular thereby that is a situation-based Search method for determining the optimal driving sequence is provided.
  • a device-based solution is through a destination call control according to the definition of claim 6 given, which is an organization of traffic using a so-called planning system.
  • the planning system works according to one situation-based search method and determined destination call based on the current operating state of Elevator installation and the target state to be produced Elevator installation the situation-specific optimum driving sequence.
  • the inventive application of a situation-based Search method essentially offers the advantage that at any relevant change in the current situation, such as upon registration of a new trip request, errors in Execution of a sequence or the like, in extreme cases after each running sequence a completely new one current driving sequence is determined, and the elevator drive then do this.
  • each of the current operating status and the desired Target operating state of the elevator system on the basis of Facts in a state description declarative summarized.
  • This in the description of the condition shown to be reached state change of Elevator system is in translated form as part of a Situation diagram, which is described below, the Planning system forwarded.
  • the determined driving sequence plan is determined by the planning system designed so that the desired state change in Execution of the driving sequence plan can be achieved.
  • each invention leads exclusively for the current planning situation represents the optimum Drive sequence.
  • the optimization can be based on that very different criteria, whereby the Objectives of optimization from increasing the performance of the Elevator, reducing the waiting and / or operating and Travel times of the passengers or the improvement of a balanced ride management and the like.
  • the planning process advantageously takes time thereby limiting that computing power and memory requirements are limited.
  • the search method finds the optimal or nearly optimal driving sequence.
  • the expert is for it so-called anytime algorithms known for such Search method can be used.
  • the state description is preferred together with an operator description in the Presentation of the situation in translated form to the planning system fed.
  • the operator description becomes the configuration time, preferably when installing the system at the customer communicated the inventive destination call control.
  • she contains operators, which elementary state transitions of Specify lift system.
  • the operators form as Elementary building blocks for the to be constructed Road trip solution the basis of the determined Driving sequence plan.
  • the planning system chooses the Operators to be used in the solution Operators description off, determines concrete values for Operator parameter as well as an arrangement order in which Operators occur in the driving sequence plan. These Order of arrangement specifies the Execution order of the operators in the plan, that is, the Ride a row.
  • the embedding of a planning system as the core of Destination call control is either in a central concept or in a decentralized concept or a combination of centralized and decentralized concept possible.
  • the communication between the terminals and the elevators is easy to organize because all communication via a central office, the central job manager, runs.
  • the Jobs are organized by a central job manager in a queue, a so-called “first in-first out "data structure. This organization is simple and ensures a clear processing order.
  • the terminals have only the Destination call input of the passenger and the display of the central Jobmanager booked elevator to process and All you need is a simple software. What the use simpler and cheaper terminals.
  • the Terminals equipped with intelligent booking software.
  • the communication between the terminals and the job managers the individual elevators are preferably made use of of contract network protocols.
  • the job manager of the individual Elevators themselves are able to parallel jobs organize and manage their status correctly.
  • the central and decentralized concept of the job manager can also combined with each other in a destination call control become. Any number of job managers can work in a network present, which control one or more elevators.
  • the elevator can be a any number of elevators with any layout include. So can several elevators with one different number of decks in a group, one so-called heterogeneous multidecker group, work together.
  • the structure as a multi-agent system enables a modular Implementation of destination call control, in which individual Components, the so-called agents, e.g. Planning system, doors, drive, taxi driver arbitrary can be exchanged without affecting the overall system must be changed.
  • agents e.g. Planning system, doors, drive, taxi driver arbitrary
  • An event-driven activation of the agents in one Multi-agent system makes the control much more robust against occurring errors. For example, one falls Landing door on a floor due to a faulty Contact, the job manager can either Arrange evacuation drive or the taxi driver first have the plan still running. For further passenger requests may be the error Configuration Manager will be notified, all affected components of the system informed that this Floor of this elevator temporarily unattended can be. Failure of components does not mean that immediate failure of the overall system, as long as the Safety of passengers is ensured.
  • Figure 1 shows schematically the structure of a inventive destination call control 1 with situational sequence planning of the traffic volume a single lift.
  • the destination call control is as a multi-agent system built up. Basis of the multi-agent system makes a powerful communication network 2, over which three distributed in the building facilities for Destination call input, so-called terminals 3.1,3.2,3.3, with a decentralized job manager 4.
  • a communication network 2 is a Architecture chosen for spontaneous networking. At this Execution is a well-known ad-hoc network with the Designation IRON provided. IRON supports a spontaneous Networking and is therefore a crucial requirement for a configuration control.
  • any number of components can be in the network Sign in.
  • the traditional group concept of elevators is thus superfluous and in particular can be in a group any number of elevators with whole different layout be present.
  • Agents can inform each other about changes and prepare information and your own flow logic integrate.
  • An agent can find out via broadcast which other agents have logged into the network as well Send messages to other agents. Furthermore, a Subscribe agent information to another agent.
  • the individual components of this multi-agent system is next to the terminals mentioned above the job manager 4, which has all the components necessary for the logical and physical control of an elevator are necessary integrated.
  • a planning system or planner 5 5 a broker 6, a door manager 7, a taxi driver 8, the Drive 9 of the elevator and an observer 10.
  • the terminals 3.1.3.2.3.3 are more intelligent Equipped booking software and ask directly at Job Manager 4 for a transport offer for each registered destination call.
  • the communication between Terminals and job managers 4 takes place by means of Contract network protocols.
  • Each of the terminals is 3.1.3.2.3.3 with a device for the identification of passengers equipped to which a configuration manager 11 belongs.
  • each terminal can Interrogate passenger data from configuration manager 11 and on forward the broker 6. So every terminal can be used for Example check whether the currently registered passenger has a Has access permission to the desired destination floor. Is the Checking successfully, the terminal asks the job manager 4 of the elevator after his transport offer.
  • the planner 5 plans the optimal operation of the new one Passengers taking into account the current, lift-specific traffic situation and generates one optimal plan, which then to control the drive. 9 the elevator is passed on to broker 6, which continues is described below. Starting point for the planner 5 is an always present situation representation, in the broker enters 6 new passengers during the Observer removed 10 passengers carried.
  • the broker 6 communicates over a two-stage Contract network protocol with the three terminals 3.1.3.2.3.3. He accepts the entries of the terminals 3.1.3.2.3.3, carries she in the situation representation of the planner 5, checks The generated optimal plan then, how the new scheduled passenger on the transport already booked passengers affects and tells the terminal that Transport offer with. No plan could be found because the problem for example due to insoluble Conflicts between the passenger groups for this elevator insoluble, so informed the broker 6 the corresponding Terminal also above. If the passenger is booked, send the broker 6 the taxi driver 8 the current driving sequence plan. The terminal will now display on the display.
  • the observer 10 monitors the condition of the elevator installation and follows up the situation representation for the planner 5. Thus, if he finds that the elevator has stopped on one floor and the doors have been opened correctly, then all passengers are marked as " served ", to whom boarded is valid and whose destination corresponds to this floor. Passengers waiting there will be marked -boarded as they board when the elevator arrives.
  • the observer 10 has no knowledge of the plan or activities of the taxi driver 8, but relies solely on the information he has subscribed to the drive 9 and the door manager 7. This is a prerequisite in order to ensure that the situation representation is tracked correctly according to the actually occurring state changes even when a special operation, such as triggering the fire control, which takes over the control of the drive 9 and interrupts the taxi driver normal operation.
  • the taxi driver 8 moves his current plan, i.e. he sends the appropriate commands to the drive 9 the elevator and the drives of the doors. He knows from his current plan, where the elevator next scheduled to keep should and how long the doors need to be opened so that all passengers have enough time to get in and out. How many passengers at a stop change state, was already determined by the planner 5. Does that have Taxi driver 8 no plan, so he releases the elevator, so that it can be parked. In any Situation allows the taxi driver 8 his current timetable against the current plan sent to him by broker 6 will, replace. How this change takes place depends on it in which execution state the taxi driver 8 located. For example, a once started Stop process from the old plan has to be finished first, before the taxi driver 8 the first stop from the new plan can start.
  • the drive 9 executes the drive and stop commands that he From the taxi driver 8 receives, he also learns the travel times the elevator between each floor. Created the time table to the optimizer 5 for the optimization Available and also reports where the elevator is currently located and in which direction he drives or whether he is straight stops.
  • the door manager 7 manages all the doors of the elevator and monitors that the doors open and close correctly. It can doors on different sides of a cabin to be available. He also determines the door opening and Close the doors and tell the planner 5 for the doors Optimizing the service times of passengers with.
  • Each of the components is as an independent agent implemented when certain events occur independently carries out actions. In particular, can thereby superimposing various events. So can to Example of the broker 6 at the same time the inquiries various terminals 3.1.3.2.3.3 accept and the Planner 5 submit.
  • the decentralized job manager 4 can be parallel make an offer for several jobs while posting other jobs is still pending. The jobs are only then binding when the corresponding terminal books.
  • Figure 2 shows a pool of requested and offered Jobs Job1 to Job4 for a decentralized job manager 4.
  • Each Terminal 1, 2 usually only has a specific Job Job X or Job Y, who wants to book it on a lift. It sends Therefore this job to all known Jobmanager 4 of the Group of elevators, of which it is the drive data knows if the associated elevator is both on and off Exit landing of the passenger. unnecessary Requests to elevators, which are not in principle for transport come into question are avoided.
  • the decentralized job manager 4 has two types of jobs: On the one hand, these are jobs, the jobs X, which have been requested and for which job manager 4 must calculate an offer, On the other hand, the jobs Y for which the job manager is 4 has already made an offer, but does not yet know whether the terminal will really book with him.
  • Embodiment is only a single elevator available.
  • the elevator can also be part of an elevator group.
  • the invention is without limitation to such elevator groups applicable.
  • Even with an elevator group ask the terminals 3.1,3.2,3.3 directly to the job managers 4 of the individual Lifts after a transport offer.
  • the terminals 3.1.3.2.3.3 self-collect these offers, compare these and calculate the optimal booking of the Passenger.
  • Each requested elevator counts independently of the other taking into account the current, lift-specific traffic situation its optimal Road sequence plan for serving the new passenger.
  • the Offer of each requested elevator is sent to the terminal who chooses the best offer and the corresponding elevator with the transport of the passenger instructed.
  • Job manager 4 confirms the booking the terminal from which the transport offer has been requested is, the booking becomes binding and becomes the passenger displayed on the terminal. If a job manager does not answer more, so the terminal responds to it and does not wait endless on the missing offer.
  • Terminals 3.1.3.2.3.3 in conjunction with the Configuration Manager 11 will be the properties of Passengers P1, P2 and in particular the destination calls, the Passengers P1, P2 as input variables of the destination call control 1 forwarded to the broker 6, who in the Presenting situation representation of the planner 5, as in Figure 2 shown.
  • any planning operation e.g. by Registration of a destination call is started, which determined Operating state and the desired target state, ie the too reaching state change of the elevator in one for the Planning system understandable state description 14 declaratively assembled, which is shown in Figure 3.
  • the state description 14 shown here in FIG. 3 is in the Plandar einstician PDDL after McDermott he al. 1998, expressed.
  • the skilled person is also others Modeling languages known in terms of their To distinguish expressiveness, and which he to Description of the situation representation can use, without that changes the essence of the invention. However, that is When choosing a planning system, make sure that this powerful according to the modeling Planning algorithms provides.
  • the planning system 3 is first informed of the registered passengers P1, P2 and the floors f1 to f7 of the building in an object declaration 15. For each object, a typed constant is introduced. For the elevator considered here, these are the waiting passenger P1, the passenger P2 already in the cabin, and all seven floors f1 to f7. (: Objects (p1 - passenger) (p2 - passenger) (f1, f2, f3, f4, f5, f6, f7 - floor))
  • topology description 16 the (upper? Fi,? Fj) Specifications, respectively, that the floor fj above the Floor fi lies.
  • the representation of the building topology is not mandatory.
  • other versions of the procedure also on the explicit Topology description 16 of the building under the assumption be dispensed with that from each floor of each other Floor can be served by the elevator.
  • the current transport order 17 with the destination calls of the passengers P1 and P2 consists of entry floors, origin, and destination floors, destin, as (: init (origin p1 f2) (origin p2 f1) (destin p1 f7) (destin p2 f5) (boarded p2).
  • the transport order 17 contains a previously planned Sequence also the information, boarded P2, namely, that passenger P2 has already boarded and is in the Cabin is located. This information was provided by the observer 10 used in the description of the condition.
  • the observer 10 sets the current position 18 of the elevator car as (lift-at f4)) is expressed in the state description 14.
  • the goal 19 for the planning system 5 is formulated in the state description 14 as: (: goal (forall (? p - passenger) (served? p)).
  • the planning system 3 is also given an operator description.
  • a stop operator and an operator for ascending -up- and an operator for descending -down- for modeling the state transitions between the initial state and the destination state of the elevator are transferred in the operator description.
  • the expert also knows other operators with which the desired change in the elevator state can be achieved. If necessary, this does not change the essence of the invention if the parameters are correspondingly defined.
  • PDDL syntax according to McDermott et al.
  • the uphill operator -up- appears as: (: action up : parameters (? f1 - floor? f2 - floor) : precondition (and (lift-at? f1) (upper? f1? f2)) : effect (and (lift-at? f2) (not (lift-at? f1)))))
  • the down-down operator is expressed as: (: action down : parameters (? f1 - floor? f2 - floor) : precondition (and (lift-at? f1) (upper? f2? f1)) : effect (and (lift-at? f2) (not (lift-at? f1)))))
  • the stop operator signals the control of the drive 9 the elevator that holds the cabin on a specific floor f1 to f7 has to stop.
  • the stop operator is in here illustrated first embodiment defined that he includes the opening and closing of the doors.
  • the Opening and closing of the car doors can also as separate additional basic instruction to the door manager 7 an elevator can be considered or it can be the stop operator be refined so that an elevator too the doors can open and close.
  • the up-and-down operators - down- give the control-technical instruction to the Drive control, the drive 9 in the corresponding To set the direction in motion.
  • a change in the passenger condition is basically only possible with a stop of the cabin. outgoing of rational behavior of the passengers, join in a scheduled stop the elevator car on a Floor all passengers on this floor - originally waiting to be transported to the cabin and All passengers leave the cabin when they are on their way Destination floor - arrives.
  • the thereby occurred Change is here with the help of the observer 10 in the stop operator registered and thus during the sequence planning considered by the planning system 5.
  • the stop operator becomes an instruction for the drive 9 effective when the in-effect coded Criteria are all met or have occurred. Will in the example described here in the stop operator?
  • P2 increases according to the state description 14 and of the behavioral model when, as in the stop operator as - effective- the operator instance stop (f5) described, -boarded p2 and -destin p2 f5- apply.
  • Planning systems 5 are already known from other technical fields.
  • the planning system 5 selects when entering the 14 independently based on the over the Operator description provided operators Instances and also determines the order in determined travel sequence plan 20.
  • the planning system 5 determines the parameters for the three operators -stop-, -up-, -down-, which cause a desired state change.
  • This calculated optimal plan 13 is sent to the broker 6 passed.
  • the broker 6 checks the generated optimal Plan to see how the newly scheduled passenger P1 on the transport of the already booked passenger and informs the terminal about the transport offer.
  • the taxi driver 8 drives this current driving sequence plan 20 from, i. he sends the appropriate commands in the form of respective operators to the drive 9 of the elevator and the Drive the door.
  • This sequence of operations 20 causes the elevator car in the Step 0 from the current floor f4 on which they are is the next stop on floor f5 -stop f5-drives. There, the elevator car stops according to step 1 stop f5- and the car door opens in a given time and closes so that the passenger exits P2 and thus served, served, is.
  • step 2 the elevator car moves down from f5 to f2 -down f5 f2- and stop in step 3 on floor f2 -stop f2-.
  • There passenger P1 climbs.
  • the Step 4 the elevator moves upwards from floor f2 Floor f7 -up f2 f7- and stops in the last step 5 on Floor f7 -stop f7-.
  • This sequence 13 all passengers P1, P2 transferred to the state -served- and the Goal formulation 10 of the driving sequence planning is thus reached.
  • the observer 10 monitors the condition of the elevator installation and continuously updates the situation representation for the planner 5. In step 1, he therefore states that the elevator has stopped on the floor f5 and the doors have been opened correctly; he marks the passengers P2 as -served. At step 2, the observer 10 marks the passenger P1 waiting there for floor f2 as boarded. Finally, the elevator car stops on the floor f7 and after the doors have been opened correctly, the observer 10 also sets the passenger P1 in the situation description as served and the current position 9 of the elevator car in the status display 5 on floor f7.
  • This created driving sequence plan 20 will not now mandatory completely executed, but when state, or the characteristics of passengers and / or the facility change relevant before it is completely executed According to the invention, a next planning cycle is started and an optimal driving sequence plan for the new planning situation 20 created. There is therefore no plan modification.
  • FIG. 5 shows schematically the structure and the basic structure a second embodiment of the inventive Destination call.
  • the destination call controller 25 includes a central job manager 26 and two decentralized job managers, a configuration manager 29 and representative of all existing terminals a terminal 30, which via a Communication network 31 communicate with each other.
  • the structure and function of decentralized job managers 27,28 correspond essentially to those of the decentralized one Job Manager 4 from the first embodiment.
  • the destination call control organizes here as so-called Group control the traffic of an elevator group with two Elevators A and B in a building with stops on seven floors.
  • the planning task arises as follows:
  • the elevator car A momentarily moves upwards; she is currently on floor f2 and can be the floor f3 still reach.
  • the elevator car B is currently up Floor f1. Elevator A transports a passenger P1 Access restriction on floors 3 and 4, the target Floor f7 is specified while elevator B is empty. In In this situation, a new passenger P2 appears, who as VIP be promoted in front of all other passengers got to. Passenger P2 has just got his transport order from Floor 3 to floor f7 delivered.
  • the central job manager 26 collects the requests of the Terminals together with the respectively recorded personal data from the configuration manager 29 as so-called jobs, here job 1 to job 4, in one Queue, as shown in Figure 6. He chooses the first job 1 out of the queue and sends it to the decentralized job manager 27,28 of each elevator. Everyone the decentralized job manager 27,28 of the lifts A, B determined independent of the other with the help of his planning system his best driving sequence solution based on the given Optimization criteria and sends them as an offer to the central job manager 26 back. The central job manager 26 Check all offers, choose from these the best offer and book the passenger on the elevator with the best Offer. The identification of the best elevator will follow sent a successful assignment to the terminal 30, on which the job was originally initiated. The Terminal 30 only functions as a display. The job 1 is done and will be canceled. The process again only picks up job 2, and so on, until all the jobs of the Warteschlage are processed.
  • the situation representation contains a State Description 32 and an operator description.
  • the service requirements are each within the framework of Passenger detection from the configuration manager 29 known and are provided by the central job manager 26 as part of a Jobs, or a request for quotation, to the decentralized Job Manager 27,28 of each elevator A, B forwarded.
  • Certain service requirements for all or any selected passengers may vary depending on the condition the elevator system or the building also time of day be provided activated.
  • a flexible weighting of individual service requirements, in particular the VIP requirement, in Dependence of the traffic volume can be displayed.
  • P1 can not drive alone in the elevator here and heard at the same time to the passenger group A.
  • the object declaration 33 contains the already-traveling passenger P1, a normal passenger, the new passenger P2, a VIP, and all 7 floors f1 to f7. (: Objects (p1 - passenger) (p2 - vip) (f1, f2, f3, f4, f5, f6, f7 - floor))
  • the current registered transfer order 34 of the passengers P1 and P2 appears as (: init (origin p1 f1) (origin p2 f3) (destin p1 f7) (destin p2 f7) (boarded p1)
  • the transport order 34 is based on the standard assumption that passengers wait on the floor if there is no corresponding boarded information. True, this means that passenger P2 is waiting on the floor.
  • the access restriction for passenger P1 presents itself as (no-access p1 f3) (no-access p1 f4)
  • the current position 35 of the elevator car 2 of the elevator A is as (lift-at f2)) expressed in the state description 32. All listed facts are considered true, all others as wrong.
  • the goal 36 for the planning system is called (: goal (forall (? p - passenger) (served? p)) formulated.
  • the planning system receives only a so-called stop operator 37, from which there is a construct a valid travel sequence plan.
  • Fig. 9 is an example of a stop operator 37 is shown.
  • the stop operator 37 contains a Specifications 38 in which is described when a Stop an elevator A, B on a floor f1 to f7 is permissible.
  • Planning systems work independently of the actual one Planning problem.
  • Such planning systems are different technical areas already known.
  • Other planning systems may be used as long as they are capable of capturing and processing the current situation representation as a whole.
  • this selects Planning system to be used in the following sequence Operators of the operator description, here the stop operator 37. If service requirements, such as VIP, going_direct, etc., in the state description 32, so the planning system independently checks the corresponding Prerequisite of the function statement 39 of the operator 37. Missing one contained in operator 37 as a precondition Service request in the call-relevant State Description 32, then this will be superfluous Precondition of the operator 37 automatically ignored.
  • One Example of a service request not considered here is the precondition -attendant-. Then determines the concrete values for operator parameters as well as a Arrangement sequence in which operators in the travel sequence plan occur. This order of arrangement specifies the Execution order of the operators in the drive sequence plan and so that the sequence of operations for the operation of the respective destination call.
  • the situation 42 can be solved by the planning system without any problem since elevator B does not know the passenger P1 at all because he is traveling in elevator A and only the new passenger P2 is notified.
  • the object declaration 43 for elevator B to the planning system consequently also includes only the new passenger P2 typed by the service request VIP and all 7 floors f1 to f7. (: Objects (p2 - vip) (f1, f2, f3, f4, f5, f6, f7 - floor))
  • the current transport order 44 of the passenger P2 presents itself as (: Init (origin p2 f3) (destin p2 f7).
  • the current position description 45 of the elevator car B is in the status description 42 as (lift-at f1) expressed.
  • the target formulation 46 for the Planning system identical to that of the elevator A. Sie is combined with the object declaration 43 and the above described stop operator 37 as part of Situation representation 42 of the elevator B to the planning system to hand over.
  • To plan the route of the elevator B is only the operator precondition: Stop on a floor below the presence of VIP, relevant because the 32 for elevator B only the service request Passing VIP to the planning system.
  • the rest in the form of specifications 33 and preconditions of Function statement 39 of the STOP operator 37 provided Service requirements remain with this planning sequence disregarded and therefore without effect on the Travel sequence plan.

Landscapes

  • Engineering & Computer Science (AREA)
  • Automation & Control Theory (AREA)
  • Elevator Control (AREA)
  • Telephonic Communication Services (AREA)
  • Exchange Systems With Centralized Control (AREA)
  • Indicating And Signalling Devices For Elevators (AREA)
  • Pinball Game Machines (AREA)
  • Maintenance And Inspection Apparatuses For Elevators (AREA)
  • Valve-Gear Or Valve Arrangements (AREA)
  • Unwinding Webs (AREA)
  • Cephalosporin Compounds (AREA)

Description

Die Erfindung betrifft eine Zielrufsteuerung für Aufzüge nach Definition der Patentansprüche.
Bekannter Weise dient eine Aufzugssteuerung dazu, Kabinenrufe auf den verschiedenen Stockwerken eines Gebäudes zu bedienen. Der Antrieb eines Aufzugs kennt als Kommandos lediglich die Anweisungen - Fahrt nach oben - , - Fahrt nach unten - , - Tür auf - und - Tür zu -.
In grösseren Gebäuden ist meist eine Gruppe von zwei bis acht Aufzügen installiert, von denen nun derjenige Aufzug ausgewählt werden muss, der für einen neu eingegangenen Kabinenruf von einem Stockwerk aus, einem sogenannten Stockwerkruf, am geeignetsten erscheint. In der Regel ist dies der Aufzug, der den kürzesten Anfahrtsweg zu diesem Stockwerk hat. Hat nun aber jeder Aufzug der Gruppe auf diesem Anfahrtsweg vorher noch andere Stockwerkrufe zu bedienen, so werden auf diesen Stockwerken Passagiere zusteigen, deren Ziel erst bekannt wird, wenn sie die entsprechenden Kabinenknöpfe gedrückt haben. Die Zuweisung eines Stockwerkrufs auf einen Aufzug gestaltet sich damit problematisch, da permanent Unsicherheit über die anzufahrenden Ziele besteht.
In der Aufzugsindustrie können deshalb zahlreiche Versuche beobachtet werden, mittels des Einsatzes von Lernverfahren auf der Basis neuronaler Netze oder genetischer Algorithmen die möglichen Zielstockwerke der Passagiere geschickt zu "erraten". Solche Beispiele werden in GB 2311148 und in JP 02052875 beschrieben. Die Wirkung solcher Verfahren ist jedoch sehr beschränkt, weil lediglich grobe Verkehrsmuster, wie zum Beispiel die morgendliche Aufwärtsspitze, mit einiger Sicherheit identifizierbar sind. Aber unklar bleibt etwa, wohin ein Passagier möchte, wenn er beispielsweise an einem Montagmorgen um 10.37 Uhr im 10. Stock eines Bürohochhauses einen Aufzug ruft.
Ein anderer Ansatz zur Lösung der Steuerungsaufgabe besteht in sogenannten Zielrufsteuerungen. Bei einer Zielrufsteuerung geben die Passagiere bereits vor dem Betreten eines Aufzugs, bzw. einer Aufzugskabine ihr gewünschtes Zielstockwerk zum Beispiel über eine telefonähnliche Tastatur, ein sogenanntes Terminal, ein. Aus der Position des Terminals ist das Zustiegsstockwerk für die Zielrufsteuerung bekannt. Nach der Eingabe des Zielstockwerks, ermittelt ein Zuteilalgorithmus der Steuerung denjenigen Aufzug der Aufzugsgruppe, welcher für den Passagier den schnellsten und bequemsten Transport zu seinem Ziel ermöglicht. Das Terminal zeigt dem Passagier diesen Aufzug der Gruppe von Aufzügen an und der Passagier kann sich jetzt in Ruhe zum entsprechend markierten Aufzug begeben. Hält der Aufzug zum Einsteigen, so wird das Ziel des Passagiers beispielsweise über eine Anzeigeeinrichtung im Türrahmen bestätigt. In der Kabine selbst sind keine Knöpfe zum Eingeben von Zielen mehr vorhanden. Auf diese Weise können durch Verwendung einer Zielrufsteuerung Passagiere mit identischem Transportziel gruppiert werden und dadurch die Transportleistung des Aufzugsystems erhöht werden.
Ein aus der EP 0 699 617 A1 bekanntes Beispiel einer solchen Zielrufsteuerung ist darüberhinaus in der Lage, einzelne Passagiere zu identifizieren. Für jeden identifizierten Passagier werden durch den Zugriff auf einen Informationsspeicher zusätzliche Informationen hinsichtlich Ein- und Ausstiegsposition, seines Platzbedarfs und eventuell zusätzlicher Service-Anforderungen, bei der Ermittlung der optimalen Transportmöglichkeit berücksichtigt.
Diese und andere herkömmliche Zielrufsteuerungen basieren auf einem heuristischen Approximierungsalgorithmus auf der Basis von Zuteilungsregeln. Dieser Zuteilungsalgorithmus ist jeweils anforderungsspezifisch entworfen und programmiert. Bei einer Fahrtanfrage, dem Zielruf, werden die über eine entsprechende Sensorik erfassten personen- und anlagenbezogenen Daten an den Zuteilungsalgorithmus weitergeleitet und durchlaufen den Algorithmus zur Bestimmung der Fahrtfolge.
Treten während der Ausführung einer Fahrtfolge neue zusätzliche Fahrtanfragen auf, so wird die bereits berechnete Fahrtfolge dahingehend modifiziert. Dabei können aber nur einfache Modifikationen vorgenommen werden, was dazu führen kann, dass nur eine angepasste und zielrufbezogen nicht mehr die im Hinblick auf die geänderten Voraussetzungen optimale Fahrtfolge ausgeführt wird. Hieraus können lange Warte- und/ oder Transportzeiten für die Passagiere entstehen. Weiters sind in einem solchen festprogrammierten Zuteilungsalgorithmus Zusammenhänge einzelner Steuerungsoptionen, sogenannte Service-Anforderungen, nicht immer logisch und lückenlos auszudrücken. Zudem wird die zur Berechnung der Fahrtfolge anforderungsspezifisch erstellte Steuerungs-soft-ware als einengend und aufwendig erachtet. Nachteilig ist insbesondere, dass ein einmal erstellter Zuteilungsalgorithmus nachträglich nur unter erheblichem Aufwand an unterschiedliche kundenspezifische Steuerungsbedürfnisse angepasst werden kann. Praktisch ist zur Anpassung an veränderte Service-Anforderungen jeweils ein neuer aufzugsspezifischer Zuteilungsalgorithmus anzufertigen und gesamthaft zu implementieren.
Der Erfindung liegt die Aufgabe zugrunde, eine Zielrufsteuerung für Aufzugsanlagen anzugeben, die neben einer Steigerung der Transportleistung auch flexibel und robust aufgebaut ist und insbesondere individuelle und/ oder kollektive Transportbedürfnisse von Passagieren berücksichtigt.
Zur Lösung der Aufgabe ist die Erfindung gegeben durch ein Verfahren zur Fahrtfolgeplanung mit den im Patentanspruch 1 gegebenen Merkmalen, welches insbesondere dadurch gekennzeichnet ist, dass ein situationsbasiertes Suchverfahren zur Ermittlung der optimalen Fahrtfolge vorgesehen ist. Eine vorrichtungsmässige Lösung ist durch eine Zielrufsteuerung nach Definition des Patentanspruchs 6 gegeben, welche eine Organisation des Verkehrsaufkommens unter Verwendung eines sogenannten Planungssystem vorsieht.
Erfindungsgemäss ist also an Stelle eines bisher verwendeten anwendungsspezifisch fest programmierten Steuerungsalgorithmus ein an sich bekanntes Planungssystem vorgesehen. Das Planungssystem arbeitet nach einem situationsbasierten Suchverfahren und ermittelt zielrufbezogen ausgehend vom momentanen Betriebszustand der Aufzugsanlage und dem herzustellenden Zielzustand der Aufzugsanlage die situationsspezifisch optimale Fahrtfolge.
Die erfindungsgemässe Anwendung eines situationsbasierten Suchverfahrens bietet im wesentlichen den Vorteil, dass bei jeder relevanten Änderung der momentanen Situation, wie z.B. bei Registrierung einer neuen Fahrtanfrage, Störungen bei Ausführung einer Fahrtfolge oder dergleichen, im Extremfall nach jedem ausgeführten Fahrtfolgeschritt eine völlig neue aktuelle Fahrtfolge bestimmt wird, und der Aufzugsantrieb diese dann ausführt.
Bei jeder Registrierung einer relevanten Änderung, beispielsweise bei jedem Zielruf, werden jeweils der momentane Betriebszustand und der gewünschte Zielbetriebszustand der Aufzugsanlage auf der Basis von Fakten in einer Zustandsbeschreibung deklarativ zusammengefasst. Diese in der Zustandsbeschreibung dargestellte zu erreichende Zustandsänderung der Aufzugsanlage wird in übersetzter Form als Teil einer Situationsdarstellung, die weiter unten beschrieben ist, dem Planungssystem zugeleitet. Damit hat das situationsbasierte Suchverfahren bei jedem registrierten Zielruf die vollständige Information über den Verkehrszustand der Aufzugsanlage. Es kann deshalb für ein fixes, vordefiniertes Optimierungskriterium die optimale Bedienung des Zielrufs berechnen. Dieser Berechnungsprozess ist so gestaltet, dass tatsächlich das Optimum auf Basis des gegebenen Kriteriums unter Realzeit Anforderungen gefunden werden kann.
Der ermittelte Fahrtfolgeplan wird durch das Planungssystem derart konstruiert, dass die gewünschte Zustandsänderung bei Ausführung des Fahrtfolgeplans erreicht werden kann.
Eine Aufzugsanlage mit einer Fahrtfolgeplanung gemäss der Erfindung führt folglich jeweils ausschliesslich die für die aktuelle Planungssituation das Optimum darstellende Fahrtfolge aus. Die Optimierung kann dabei auf der Basis ganz unterschiedlicher Kriterien erfolgen, wobei sich die Ziele der Optimierung aus der Steigerung der Leistung des Aufzugs, der Reduzierung der Warte- und/ oder Bedien- und Fahrtzeiten der Passagiere oder aber der Verbesserung eines ausgewogenen Fahrtmanagements und dergleichen ergeben.
Der Planungsvorgang wird vorteilhafter Weise zeitlich dadurch begrenzt, dass Rechenleistung und Speicherbedarf beschränkt sind. Innerhalb dieser beschränkten Rechenressourcen findet das Suchverfahren die optimale bzw. annähernd optimale Fahrtfolge. Dem Fachmann sind dafür sogenannte Anytime-Algorithmen bekannt, die für ein solches Suchverfahren zur Anwendung kommen können.
Gemäss einer vorteilhaften Ausführung des erfindungsgemässen Suchverfahrens wird die Zustandsbeschreibung vorzugsweise zusammen mit einer Operatorenbeschreibung in der Situationsdarstellung in übersetzter Form dem Planungssystem zugeleitet.
Die Operatorenbeschreibung wird zur Konfigurationszeit, vorzugsweise bei der Installierung des Systems beim Kunden der erfindungsgemässen Zielrufsteuerung mitgeteilt. Sie enthält Operatoren, welche elementare Zustandsübergänge der Aufzugsanlage spezifizieren. Die Operatoren bilden als Elementarbausteine für die zu konstruierende Fahrtfolgelösung die Grundlage des ermittelten Fahrtfolgeplans. Bei jeder Zielrufzuteilung bzw. beim Lösen einer konkreten Planungsaufgabe wählt das Planungssystem die in der Lösung zu verwendenden Operatoren aus der Operatorenbschreibung aus, bestimmt konkrete Werte für Operatorparameter sowie eine Anordnungsreihenfolge, in der Operatoren im Fahrtfolgeplan auftreten. Diese Anordnungsreihenfolge spezifiziert die Ausführungsreihenfolge der Operatoren im Plan, sprich, die Fahrtfolge.
Im Unterschied zu bisher fest programmierten Zuteilungsalgorithmen kann das Planungssystem mit einer beliebigen Menge von Operatoren versehen werden, speziell auch solchen, die Service-Anforderungen bedienen können, die kundenseitig zum Installationszeitpunkt noch nicht vorhanden sind. Treten diese Anforderungen zu einem späteren Zeitpunkt auf, so muss dem Planungssystem lediglich eine entsprechende Situationsdarstellung mitgeteilt werden, in dem diese Service-Anforderungen formuliert sind. Das System kann dann solche Aufgaben sofort lösen. Treten Service-Anforderungen auf, für die keine Operatoren vorgesehen sind, so sichert die Modularität der Operatoren in einem Planungssystem, dass auf sehr einfache Weise neue Operatoren hinzugefügt oder weggenommen werden können, ohne dass die bereits vorhandenen Operatoren davon beeinflusst werden. Aufzugsanlagen können damit durch das Verändern der Operatormenge, die für die Steuerung zur Verfügung stehen, wie auch durch die Definition der Operatoren selbst, sehr einfach und flexibel an sich ändernde Kundenbedürfnisse im Hinblick auf die Verkehrsorganisation angepasst werden.
Bei der Steuerung einer Gruppe von Aufzügen mit der erfindungsgemässen Zielrufsteuerung erfolgt die Berücksichtigung der Service-Anforderungen im laufenden Betrieb der Aufzuganlage ohne dass eine separate Reservierung eines Aufzugs der Aufzugsgruppe für den den jeweiligen Service anfordernden Passagier erfolgen muss. Die Aufzugsteuerung und die Operatoren sind in einer Weise aufeinander abgestimmt, dass grundsätzlich jeder Aufzug jederzeit alle über die Situationsdarstellung vorgegebenen speziellen Service-Anforderungen ausführen kann. Bei Bedarf wird die Service-Anforderung quasi in den Gruppenbetrieb rufspezifisch integriert.
Die Einbettung eines Planungssystems als Kern der Zielrufsteuerung ist entweder in einem zentralen Konzept oder in einem dezentralen Konzept oder einer Kombination des zentralen und das dezentralen Konzepts möglich.
Bei einem Aufbau der Zielrufsteuerung mit einem sogenannten zentralen Jobmanager ist dieser entscheidende Schaltstelle zwischen den Terminals und den einzelnen Jobmanagern der Aufzüge. Die Terminals richten ihre Transportanfragen an den zentralen Jobmanager. Der Jobmanager fragt bei jedem der Jobmanager der einzelnen Aufzüge nach einem Transportangebot für den jeweils registrierten Zielruf, den sogenannten Job, an. Dem zentralen Jobmanager allein obliegen die Verwaltung aller aktuellen Transportanfragen von Passagieren, der Zielrufe, und die Buchung der Transportaufträge, sogenannte Jobs, auf den jeweils ausgewählten Aufzug. Vom zentralen Jobmanager erhalten die Terminals als Antwort die Kennung des ausgewählten Aufzugs, die sie daraufhin anzeigen (z.B. "A" oder "B").
Die Kommunikation zwischen den Terminals und den Aufzügen ist einfach zu organisieren, weil sämtliche Kommunikation über eine Zentrale, den zentralen Jobmanager, läuft. Die Organisation der Jobs erfolgt bei einem zentralen Jobmanager in einer Warteschlange, einer sogenannten "first in-first out" Datenstruktur. Diese Organisation ist einfach und sichert eine eindeutige Abarbeitungsreihenfolge.
Bei dem zentralen Konzept haben die Terminals lediglich die Zielrufeingabe des Passagiers sowie die Anzeige des vom zentralen Jobmanager gebuchten Aufzugs zu verarbeiten und benötigen dazu nur eine simple Software. Was die Verwendung einfacher und kostengünstiger Terminals ermöglicht.
Bei einem dezentralen Aufbau des Jobmanagers, stehen Terminals über ein leistungsfähiges Kommunikationsnetzwerk mit den Jobmanagern der einzelnen Aufzüge einer Aufzugsgruppe in Verbindung. Die Terminals fragen direkt bei den Jobmanagern der einzelnen Aufzüge nach einem Transportangebot für den jeweils registrierten Zielruf an. Die Terminals sammeln selbständig diese Angebote ein, vergleichen diese und ermitteln die optimale Buchung des Passagiers. Bei einem dezentralen Jobmanager erfolgt die Organisation der Jobs parallel für mehrere Jobs, wobei eine beliebige Überlagerung von Anfragen und Buchungen möglich ist.
Weitere Vorteile des dezentralen Konzepts der Zielrufsteuerung liegen in der im Vergleich zum zentralen Konzept schnelleren Reaktion der Jobmanager auf Anfragen, einer erhöhten Stabilität des Gesamtsystems durch die Dezentralisierung sowie einer vereinfachten Architektur der Jobmanager, da keine separate Zentrale vorgesehen werden muss.
Sofern die dezentrale Ausgestaltung vorgesehen ist, sind die Terminals mit intelligenter Buchungssoftware ausgestattet. Die Kommunikation zwischen den Terminals und den Jobmanagern der einzelnen Aufzüge erfolgt vorzugsweise über Verwendung von Kontraktnetzprotokollen. Die Jobmanager der einzelnen Aufzüge selbst sind in der Lage, Jobs parallel zu organisieren und ihren Status korrekt zu verwalten.
Das zentrale und dezentrale Konzept des Jobmanagers können auch miteinander in einer Zielrufsteuerung kombiniert werden. In einem Netz können beliebig viele Jobmanager vorliegen, die einen oder mehrere Aufzüge steuern.
Gemäss einer besonders bevorzugten Weiterbildung der Erfindung ist die situationsbasierte Zielrufsteuerung als Multi-Angentensystem dargestellt, das die Gesamtsteuerung der Anlage realisiert, wobei das Planungssystem ein Agent in diesem Multi-Angentensystem ist. Die Aufzugsanlage kann eine beliebige Anzahl von Aufzügen mit beliebigem Layout umfassen. So können auch mehrere Aufzüge mit einer unterschiedlichen Anzahl von Decks in einer Gruppe, eine sogenannte heterogene Multidecker Gruppe, zusammenarbeiten.
Der Aufbau als Multi-Agentensystem ermöglicht eine modulare Implementierung der Zielrufsteuerung, in der einzelne Komponenten, die sogenannnten Agenten, wie z.B. Planungssystem, Türen, Antrieb, Taxifahrer beliebig ausgetauscht werden können, ohne dass das Gesamtsystem geändert werden muss.
Eine ereignisgesteuerte Aktivierung der Agenten in einem Multi-Agentensystem macht die Steuerung wesentlich robuster gegenüber auftretenden Fehlern. Fällt zum Beispiel eine Schachttür auf einem Stockwerk aufgrund eines fehlerhaften Kontakts aus, so kann der Jobmanager entweder eine Evakuierungsfahrt veranlassen oder aber den Taxifahrer zunächst den noch vorhandenen Plan ausführen lassen. Für weitere Passagieranfragen kann der Fehler dem Konfigurationsmanager mitgeteilt werden, der alle betroffenen Komponenten des Systems informiert, dass dieses Stockwerk von diesem Aufzug vorübergehend nicht bedient werden kann. Ein Ausfall von Komponenten bedeutet nicht den sofortigen Ausfall des Gesamtsystems, so lange die Sicherheit der Passagiere gewährleistet ist.
Weitere vorteilhafte Ausgestaltungen der Erfindung sind in unabhängigen Ansprüchen enthalten.
Ausführungsbeispiele der Erfindung, bei denen die Zielrufsteuerung als Multi-Agentensystem zur Oganisation des Verkehrs einer Aufzugsanlage ausgebildet ist, sind in der Zeichnung dargestellt und nachfolgend ausführlich beschrieben. Es zeigt:
  • Fig.1, schematisch den Aufbau eines ersten Ausführungsbeispiels der Zielrufsteuerung mit einem dezentralen Jobmananger für die Steuerung eines einzelnen Aufzugs;
  • Fig.2, eine schematische Darstellung der Organisation eines Pools von angefragten und offerierten Jobs bei einer Zielrufsteuerung mit einem dezentralen Jobmananger für die Steuerung einer Gruppe von Aufzügen;
  • Fig.3, eine momentane Zustandsbeschreibung gemäss dem ersten Ausführungsbeispiels;
  • Fig.4, eine graphische Darstellung des ermittelten Fahrtfolgeplan gemäss dem ersten Ausführungsbeispiel;
  • Fig.5, schematisch den Aufbau eines zweiten Ausführungsbeispiels der Zielrufsteuerung mit zentralem Jobmananger als Schaltstelle zwischen Terminals und den einzelnen Aufzügen;
  • Fig.6, in einem Blockschaltbild die Organisation der Jobs in einer Warteschlage bei einem zentralen Jobmanager;
  • Fig.7, eine momentane Zustandsbeschreibung des Aufzugs A aus dem zweiten Ausführungsbeispiel;
  • Fig.8, eine momentane Zustandsbeschreibung des Aufzugs B aus dem zweiten Ausführungsbeispiel;
  • Fig.9, den Aufbau eines Operators mit Stop-Anweisung, wie er im zweiten Ausführungsbeispiel zur Anwendung kommt.
    • Figur 1 zeigt schematisch den Aufbau einer erfindungsgemässen Zielrufsteuerung 1 mit situationsbedingter Fahrtfolgeplanung des Verkehrsaufkommens eines einzelnen Aufzugs. Die Zielrufsteuerung ist als Multi-Agentensystem aufgebaut. Grundlage des Multi-Agentensystems bildet ein leistungsfähiges Kommunikationsneztwerk 2, über welches drei im Gebäude verteilte Einrichtungen zur Zielrufeingabe, sogenannte Terminals 3.1,3.2,3.3, mit einem dezentralen Jobmanager 4 in Verbindung stehen.
    Idealerweise, wird als Kommunikationsneztwerk 2 eine Architektur zur spontanen Vernetzung gewählt. Bei dieser Ausführung ist ein an sich bekanntes Ad-hoc Netzwerk mit der Bezeichnung IRON vorgesehen. IRON unterstützt eine spontane Vernetzung und ist somit eine entscheidende Voraussetzung für eine konfigurierungsfeie Steuerung.
    Bekannte Beispiele für Architekturen zur spontanen Vernetzung sind Jini, Universal Plug and Play oder Bluetooth. In solch einem Kommunikationsneztwerk 2 können sich netzwerkfähige Geräte, sogenannten Agenten, anmelden und miteinander agieren, ohne dass eine Konfiguration oder Administration nötig ist. Die Integration aller dieser Geräte und der darauf implementierten Dienste läuft vollautomatisch ab. Die wichtigsten Methoden eines solchen Kommunikationsnetzwerks 2 sind - register - , - lookup - und - notify -.
    • Durch Registration melden sich die einzelnen Geräte im Netz an und machen ihre Dienste bekannt.
    • Durch Lookup kann ein Gerät ein anderes Gerät oder einen benötigten Dienst finden.
    • Durch Notification kann sich ein Gerät bei einem anderen für die Benachrichtigung über das Eintreten bestimmter Ereignisse anmelden.
    In einer Aufzugsgruppe melden sich vorzugsweise Terminals, Antriebe, Kabinentüren, zentrale Jobmanager und/ oder dezentrale Jobmanager als netzwerkfähige Geräte an.
    • Terminals melden sich mit ihrer Stockwerksposition und XY-Koordinate im Netz an und informieren sich über alle vorhandenen Jobmanager.
    • Antriebe repräsentieren die physische Komponente der Aufzugssteuerung. Sie stellen die Information zur Verfügung, welche Stockwerke sie anfahren können, wieviele Schachttüren sich auf einem Stockwerk befinden und auf welcher Seite diese positioniert sind. Desweiteren kann beim Antrieb die Benachrichtigung bestimmter Ereignisse wie Wechsel des Selektors, Wechsel des Zustands (z.B. fahrend, ankommend, stillstehend) abonniert werden.
    • Kabinentüren melden sich mit Information darüber zu welchem Antrieb sie gehören, auf welchem Deck sie sich befinden und auf welcher Seite sie öffnen. Durch diese Information findet der Jobmanager sofort heraus, wieviele Decks ein Aufzug hat und wieviele Türen pro Deck vorhanden sind.
    • Jobmanager melden sich im Netz mit der Information an, welche Antriebe sie vertreten - einen einzelnen im strikt dezentralen Konzept oder alle vorhandenen beim strikt zentralen Konzept.
    Prinzipiell können sich im Netz beliebig viele Komponenten anmelden. Das traditionelle Gruppenkonzept von Aufzügen ist damit überflüssig und insbesondere können in einer Gruppe eine beliebige Anzahl von Aufzügen mit ganz unterschiedlichem Layout vorhanden sein.
    Melden sich zum Beispiel elf Antriebe, von denen drei nur eine Tür haben, vier jeweils drei Türen auf zwei Decks und vier jeweils sechs Türen gleichverteilt auf drei Decks, so liegt ein Beispiel einer sogenannten heterogene Multideckergruppe vor, bestehend aus
    • 3 Singledeckern mit nur einer Tür
    • 4 Doppeldeckern, wobei ein Deck mit einer Tür und das andere Deck mit 2 Türen ausgestattet ist
    • 4 Tripledeckern, bei denen jedes Deck 2 Türen hat.
    Der Jobmanager jedes der einzelnen Aufzüge ist in der Lage, die Anzahl der Decks und Türen seines zugeordneten Antriebs zu erkennen und in der Steuerung korrekt zu verarbeiten. Dies beinhaltet insbesondere:
    • das Planungssystem plant bei einem Multidecker das Ein- und Aussteigen der Passagiere über alle vorhandenen Decks,
    • der Taxifahrer des Jobmanagers sendet bei einem Stop die Türöffnungskommandos an alle Türen, die zu Stockwerken öffnen, auf denen Passagiere ein- oder aussteigen wollen.
    Bei dem hier verwendeten IRON-Kommunikationsneztwerk 2 können sich Agenten gegenseitig über Änderungen informieren und Informationen aufbereiten und in die eigene Ablauflogik integrieren. Ein Agent kann via Broadcast herausfinden, welche anderen Agenten sich im Netz angemeldet haben sowie Nachrichten an andere Agenten versenden. Ferner kann ein Agent Informationen bei einem anderen Agenten abonnieren.
    Die einzelnen Komponenten dieses Multi-Agentensystems, die sogenannten Agenten, ist neben den oben erwähnten Terminals der Jobmanager 4, der alle Komponenten, die für die logische und physische Steuerung eines Aufzugs notwendig sind integriert. Dies sind hier, ein Planungssystem oder Planer 5 5, ein Broker 6, ein Türmanager 7, ein Taxifahrer 8, der Antrieb 9 des Aufzugs und ein Beobachter 10.
    Die Terminals 3.1,3.2,3.3 sind mit intelligenter Buchungssoftware ausgestattet und fragen direkt beim Jobmanager 4 nach einem Transportangebot für den jeweils registrierten Zielruf an. Die Kommunikation zwischen Terminals und Jobmanagern 4 erfolgt mittels Kontraktnetzprotokollen. Jedes der Terminals 3.1,3.2,3.3 ist mit einer Einrichtung zur Identifizierung von Passagieren ausgestattet, zu der ein Konfigurationsmanager 11 gehört.
    Im Konfigurationsmanager 11 sind das aktuelle Gebäudelayout, wie zum Beispiel die Anzahl der Stockwerke, Zutrittszonen, Unterteilung der Passagiere in Passagiergruppen, Zutrittsrechte, Service Anforderungen, usw. und Passagierinformationen abrufbar gespeichert. Bei der Registrierung eines Zielrufes, kann jedes Terminal Passagierdaten vom Konfigurationsmanager 11 abfragen und an den Broker 6 weiterleiten. So kann jedes Terminal zum Beispiel prüfen, ob der aktuell registrierte Passagier eine Zutrittserlaubnis zum gewünschten Zielstockwerk hat. Ist die Prüfung erfolgreich, so fragt das Terminal den Jobmanager 4 des Aufzugs nach seinem Transportangebot an.
    Der Planer 5 plant für sich die optimale Bedienung des neuen Passagiers unter Berücksichtigung der aktuellen, aufzugspezifischen Verkehrssituation und erzeugt dabei einen optimalen Plan, welcher dann zur Steuerung des Antriebs 9 des Aufzugs an den Broker 6 weitergegeben wird, was weiter unten beschrieben ist. Ausgangspunkt für den Planer 5 ist eine zu jedem Zeitpunkt aktuelle Situationsdarstellung, in die der Broker 6 neue Passagiere einträgt, während der Beobachter 10 beförderte Passagiere entfernt.
    Der Broker 6 kommuniziert über ein zweistufiges Kontraktnetzprotokoll mit den drei Terminals 3.1,3.2,3.3. Er nimmt die Eingaben der Terminals 3.1,3.2,3.3 entgegen, trägt sie in die Situationsdarstellung des Planers 5 ein, prüft den generierten optimalen Plan daraufhin, wie sich der neu eingeplante Passagier auf den Transport der bereits gebuchten Passagiere auswirkt und teilt dem Terminal das Transportangebot mit. Konnte kein Plan gefunden werden, weil das Problem beispielsweise aufgrund von unlösbaren Konflikten zwischen den Passagiergruppen für diesen Aufzug unlösbar ist, so informiert der Broker 6 das entsprechende Terminal auch darüber. Ist der Passagier gebucht, so sendet der Broker 6 dem Taxifahrer 8 den aktuellen Fahrtfolgeplan. Das Terminal nimmt nun die Anzeige auf dem Display vor.
    Der Beobachter 10 überwacht den Zustand der Aufzugsanlage und führt die Situationsdarstellung für den Planer 5 nach. Stellt er also fest, dass der Aufzug auf einem Stockwerk gehalten hat und die Türen korrekt geöffnet wurden, so werden alle Passagiere als -served- markiert, für die-boarded- gilt und deren Ziel diesem Stockwerk entspricht. Passagiere, die dort noch warten, werden als -boarded- markiert, da sie zusteigen, wenn der Aufzug bei ihnen angekommen ist. Der Beobachter 10 hat dabei keine Kenntnis des Plans oder der Aktivitäten des Taxifahrers 8, sondern stützt sich allein auf die Information, die er beim Antrieb 9 und beim Türmanager 7 abonniert hat. Dies ist eine Voraussetzung um auch beim Auftreten eines Sonderbetriebs, wie z.B. dem Auslösen der Brandfallsteuerung, die die Kontrolle über den Antrieb 9 übernimmt und den Taxifahrer-Normalbetrieb unterbricht, sicherzustellen, dass die Situationsdarstellung entsprechend der tatsächlich auftretenden Zustandsänderungen korrekt nachgeführt wird.
    Der Taxifahrer 8 fährt seinen jeweils aktuellen Plan ab, d.h. er sendet die entsprechenden Kommandos an den Antrieb 9 des Aufzugs und die Antriebe der Türen. Er weiss aus seinem aktuellen Plan, wo der Aufzug als nächstes planmässig halten soll und wie lange die Türen geöffnet werden müssen, damit alle Passagiere genug Zeit zum Ein- und Aussteigen haben. Wieviele Passagiere an einem Stop den Zustand wechseln, wurde bereits durch den Planer 5 bestimmt. Hat der Taxifahrer 8 keinen Plan mehr, so gibt er den Aufzug frei, damit dieser geparkt werden kann. In jeder beliebigen Situation kann der Taxifahrer 8 seinen aktuellen Fahrplan gegen den aktuellen Plan, der ihm vom Broker 6 geschickt wird, auswechseln. Wie dieses Wechseln erfolgt, hängt davon ab, in welchem Ausführungszustand sich der Taxifahrer 8 befindet. So gilt zum Beispiel, dass ein einmal begonnener Stopvorgang aus dem alten Plan erst beendet werden muss, bevor der Taxifahrer 8 den ersten Stop aus dem neuen Plan anfahren kann.
    Der Antrieb 9 führt die Fahr- und Stop-Kommandos aus, die er vom Taxifahrer 8 erhält, ausserdem lernt er die Fahrzeiten des Aufzugs zwischen den einzelnen Stockwerken. Er stellt die Fahrzeitentabelle dem Planer 5 für die Optimierung zur Verfügung und meldet auch, wo der Aufzug sich aktuell befindet und in welche Richtung er fährt oder ob er gerade anhält.
    Der Türmanager 7 verwaltet alle Türen des Aufzugs und überwacht, dass die Türen korrekt öffnen und schliessen. Dabei können auf verschiedenen Seiten einer Kabine Türen vorhanden sein. Er bestimmt auch die Türöffnungs- und Schliesszeiten der Türen und teilt sie dem Planer 5 für die Optimierung der Bedienzeiten der Passagiere mit.
    Jede der Komponenten ist als selbständiger Agent implementiert, der beim Auftreten bestimmter Ereignisse selbständig Handlungen ausführt. Insbesondere können sich dadurch verschiedenste Ereignisse überlagern. So kann zum Beispiel der Broker 6 gleichzeitig die Anfragen verschiedener Terminals 3.1,3.2,3.3 entgegennehmen und dem Planer 5 vorlegen. Der dezentrale Jobmanager 4 kann parallel für mehrere Jobs ein Angebot abgeben, während die Buchung anderer Jobs noch aussteht. Die Jobs werden erst dann verbindlich, wenn das entsprechende Terminal bucht.
    Da zwischen der Abgabe des Angebots durch den Broker 6 und der Buchung durch das jeweilige Terminal theoretisch eine beliebig lange Zeitspanne vergehen kann, ist es möglich, dass zwischenzeitlich bereits ein anderes Terminal eine Buchung platziert hat. In dieser Situation muss der Broker 6 prüfen, ob das abgegebene Angebot noch gültig ist, wenn das Terminal jetzt seine Buchung schickt. Diese beliebige Überlagerung von Anfragen und Buchungen erfordert es, dass das Terminal auf eine Rückbestätigung seiner Buchung wartet und bei fehlender Bestätigung eine alternative Buchung bei einem anderen Jobmanager 4 versucht. Ist auch die Neuplanung erfolglos, weil sich die Situation im Aufzug zum Beispiel derart geändert hat, dass jetzt unlösbare Konflikte zwischen den bereits gebuchten und dem neu zu buchenden Passagier auftreten, so erhält das Terminal eine entsprechende Rückmeldung.
    Figur 2 zeigt einen Pool von angefragten und offerierten Jobs Job1 bis Job4 bei einem dezentralen Jobmanager 4. Jedes Terminal 1, 2 hat in der Regel nur einen konkreten Job Job X bzw Job Y, den es auf einen Aufzug buchen will. Es sendet diesen Job deshalb an alle ihm bekannten Jobmanager 4 der Gruppe von Aufzügen, von denen es aus den Antriebsdaten weiss, ob der dazugehörige Aufzug sowohl Ein- als auch Ausstiegsstockwerk des Passagiers bedienen kann. Unnötige Anfragen an Aufzüge, die für den Transport prinzipiell nicht in Frage kommen, werden damit vermieden.
    Am dezentralen Jobmanager 4 liegen zwei Arten von Jobs vor: Einerseits sind dies Jobs, die Jobs X, die angefragt wurden und für die der Jobmanager 4 ein Angebot berechnen muss, andererseits sind die Jobs Y, für die der Jobmanager 4 bereits ein Angebot abgegeben hat, aber noch nicht weiss, ob das Terminal wirklich bei ihm buchen wird.
    Bei dem hier dargestellten und in Figur 1 gezeigten ersten Ausführungsbeispiel ist nur ein einzelner Aufzug vorhanden. Der Aufzug kann aber auch Teil einer Aufzugsgruppe sein. Die Erfindung ist ohne Einschränkung auf solche Aufzugsgruppen anwendbar. Auch bei einer Aufzugsgruppe fragen die Terminals 3.1,3.2,3.3 direkt bei den Jobmanagern 4 der einzelnen Aufzüge nach einem Transportangebot an. Die Terminals 3.1,3.2,3.3 sammeln selbständig diese Angebote ein, vergleichen diese und berechnen die optimale Buchung des Passagiers. Jeder angefragte Aufzug rechnet unabhängig von den anderen unter Berücksichtigung der aktuellen, aufzugspezifischen Verkehrssituation seinen optimalen Fahrtfolgeplan zur Bedienung des neuen Passagiers aus. Das Angebot jedes angefragten Aufzugs wird an das Terminal zurückgesandt, das das beste Angebot auswählt und den entsprechenden Aufzug mit dem Transport des Passagiers beauftragt. Bestätigt der Jobmanager 4 die Buchung gegenüber dem Terminal von dem das Transportangebot angefragt worden ist, so wird die Buchung verbindlich und wird dem Passagier auf dem Terminal angezeigt. Meldet sich ein Jobmanager nicht mehr, so reagiert das Terminal auch darauf und wartet nicht endlos auf das fehlende Angebot.
    Die Arbeitsweise der insoweit beschriebenen erfindungsgemässen Zielrufsteuerung gemäss Figur 1 ist nachfolgend am Beispiel eines Planungsproblems einer Aufzugsanlage mit nur einem einzelnen Aufzug mit eintüriger Kabine beschrieben, der ein hier nicht dargestelltes Gebäude mit Haltestellen auf sieben Stockwerken f1 bis f7 bedient. Die Aufzugkabine steht momentan in Stockwerk f4. Ein Passagier P1, wartet auf Stockwerk f2 und möchte ins Stockwerk f7, ein zweiter Passagier P2 befindet sich bereits in der Kabine und möchte von Stockwerk f1 ins Stockwerk f5. Es ist die Fahrtfolge der Kabine erfindungsgemäss mittels Planungssystem 3 zu organisieren.
    Vom Beobachter 10 werden die Eigenschaften des Aufzugs, das heisst, der momentane Betriebszustand des Aufzugs erfasst und in der Situationsdarstellung aktualisiert. Über Terminals 3.1,3.2,3.3 in Verbindung mit dem Konfigurationsmanager 11 werden die Eigenschaften der Passagiere P1, P2 und insbesondere die Zielrufe, der Passagiere P1, P2 als Eingangsgrössen der Zielrufsteuerung 1 an den Broker 6 weitergeleitet, der sie in die Situationsdarstellung des Planers 5 einträgt, wie in Figur 2 gezeigt.
    So werden bei jedem Planungsvorgang, der z.B. durch Registrierung eines Zielrufs gestartet wird, der ermittelte Betriebszustand und der gewünschte Zielzustand, also die zu erreichende Zustandsänderung des Aufzugs in einer für das Planungssystem verständlichen Zustandsbeschreibung 14 deklarativ zusammengestellt, die in Figur 3 dargestellt ist.
    Die hier in Figur 3 abgebildete Zustandsbeschreibung 14 ist in der Plandarstellungssprache PDDL nach McDermott er al. 1998, ausgedrückt. Dem Fachmann sind auch andere Modellierungssprachen bekannt, die sich hinsichtlich ihrer Ausdrucksmächtigkeit unterscheiden, und die er zur Beschreibung der Situationdarstellung verwenden kann, ohne dass damit das Wesen der Erfindung ändert. Allerdings ist bei der Wahl eines Planungssystems darauf zu achten, dass dieses der Modellierung entsprechend mächtige Planungsalgorithmen zur Verfügung stellt.
    In der in Figur 3 dargestellten Zustandsbeschreibung 14 werden dem Planungssystem 3 in einer Objektdeklaration 15 zunächst die gemeldeten Passagiere P1, P2 und die Stockwerke f1 bis f7 des Gebäudes bekannt gemacht. Für jedes Objekt wird eine typisierte Konstante eingeführt. Für den hier betrachteten Aufzug sind dies der wartende Passagier P1, der sich bereits in der Kabine befindende Passagier P2 und alle sieben Stockwerke f1 bis f7.
    (:objects
    (p1   - passenger)
    (p2   - passenger)
    (f1, f2, f3, f4, f5, f6, f7   - floor))
    Aus dem Konfigurationsmanager 11 erhält der Broker 6 die Angaben hinsichtlich der Topologie des Gebäudes. Diese findet sich als Topologiebeschreibung 16 in der Zustandsbeschreibung 14 wieder in Form von
  • (upper f1 f2)   (upper f1 f3)   (upper f1 f4)
  • (upper f1 f5)   (upper f1 f6)   (upper f1 f7)
  • (upper f2 f3)   (upper f2 f4)   (upper f2 f5)
  • (upper f2 f6)   (upper f2 f7)   (upper f3 f4)
  • (upper f3 f5)   (upper f3 f6)   (upper f3 f7)
  • (upper f4 f5)   (upper f4 f6)   (upper f4 f7)
  • (upper f5 f6)   (upper f5 f7)   (upper f6 f7).
    • In der Topologiebeschreibung 16 legen die (upper ?fi,?fj) Vorgaben jeweils fest, dass das Stockwerk fj oberhalb des Stockwerks fi liegt. Die Darstellung der Gebäudetopologie ist nicht zwingend erforderlich. In Vereinfachung kann in anderen Ausführungen des Verfahrens auch auf die explizite Topologiebeschreibung 16 des Gebäudes unter der Annahme verzichtet werden, dass von jedem Stockwerk aus jedes andere Stockwerk durch den Aufzug bedient werden kann.
    Der aktuelle Transportauftrag 17 mit den Zielrufen der Passagiere P1 und P2 stellt sich aus Einstiegsstockwerken, origin, und Zielstockwerken , destin, dar als
    (:init (origin p1 f2)
    (origin p2 f1)
    (destin p1 f7)
    (destin p2 f5)
    (boarded p2) .
    Der Transportauftrag 17 enthält aus einer früher geplanten Fahrtfolge ausserdem die Information, boarded P2, nämlich, dass Passagier P2 bereits eingestiegen ist und sich in der Kabine befindet. Diese Information wurde vom Beobachter 10 in die Zustandsbeschreibung eingesetzt.
    Grundsätzlich nimmt jeder Passagier P1,P2 im Rahmen der Fahrtfolgeplanung die drei Zustände: wartend/waiting, fahrend/boarded, bedient/served ein, die hier folgendermassen definiert sind:
    • Wartend/ waiting: Der Passagier wartet vor der Aufzugstür. Hier hat der Aufzug zuerst am Ausgangsort, origin, des Passagiers und erst danach an dem vom Passagier angegebenen Zielstockwerk, destin, zu halten.
    • Fahrend/ boarded: Der Passagier befindet sich in der Aufzugskabine und wird zu seinem Zielstockwerk, destin,
      transportiert, welches bisher noch nicht angefahren, d.h. bedient worden ist.
    • Bedient/ served: Der Passagier hat die Aufzugskabine an seinem Zielstockwerk, destin, verlassen. Dieser Transportauftrag ist erledigt und der Passagier wurde zufriedenstellend vom Aufzug bedient. Diese drei möglichen Zustände lassen sich mittels der beiden Befehle -boarded ?p- und -served ?p- in der PDDL-Modellierungssprache ausdrücken. Der Passagier P1 wartet auf eine Aufzugkabine und ist deshalb weder als -boarded- noch als -served- registriert.
    Der Beobachter 10 setzt die aktuelle Position 18 der Aufzugskabine, die als
    (lift-at f4))
    in der Zustandsbeschreibung 14 ausgedrückt ist.
    Das Ziel 19 für das Planungssystem 5 wird in der Zustandsbeschreibung 14 formuliert als:
    (: goal (forall (?p - passenger) (served ?p)).
    Gesucht ist nun die kürzeste Folge von Stops, die alle Passagiere P1,P2 in den Zustand bedient -served- überführt, die genau dann erreicht ist, wenn sie auf ihrem Zielstockwerk -destin- ausgestiegen sind.
    Neben den Beschreibungen des Ausgangszustands und des Zielzustands des Planungsproblems durch die Zustandsbeschreibung 14, wird dem Planungssystem 3 auch eine Operatorenbeschreibung übergeben. Im hier dargestellten Ausführungsbeispiel werden in der Operatorenbeschreibung ein Stop-Operator sowie ein Operator zum Aufwärtsfahren -up- und ein Operator zum Abwärtsfahren -down- zur Modellierung der Zustandsübergänge zwischen Ausgangszustand und Zielzustand des Aufzugs übergeben. Alternativ zu diesen Operatoren - stop-, -up-, -down-, kennt der Fachmann auch andere Operatoren, mit denen sich die gewünschte Änderung des Aufzugszustands erreichen lässt. Gegebenenfalls ändert sich dadurch bei entsprechender Definition der Parameter das Wesen der Erfindung nicht. In PDDL-Syntax gemäss McDermott et al. 1998 steht hier folgender Stop Operator zur Verfügung:
    (define (domain miconic)
    (:requirements :adl)
       (:types passenger - object
          floor - object)
    (:predicates
    (origin ?person - passenger ?floor - floor)
    (destination ?person - passenger ?floor - floor)
    (boarded ?person - passenger)
    (served ?person - passenger)
    (lift-at ?floor - floor))
    (:action stop
       :parameters (?f - floor)
       :precondition (and (lift-at ?f))
    :effect (and (forall (?p - passenger) (when (and (boarded ?p)
       (destination ?p ?f))
       (and (not (boarded ?p)) (served ?p))))
       (forall (?p - passenger) (when (and (origin ?p ?f) (not
       (served ?p))) (boarded ?p)))))
    Der Operator zum Aufwärtsfahren -up- stellt sich dar als:
    (:action up
       :parameters (?f1 - floor ?f2 - floor)
       :precondition (and (lift-at ?f1) (upper ?f1 ?f2))
       :effect (and (lift-at ?f2) (not (lift-at ?f1))))
    Der Operator zum Abwärtsfahren -down- ist ausgedrückt als:
    (:action down
       :parameters (?f1 - floor ?f2 - floor)
       :precondition (and (lift-at ?f1) (upper ?f2 ?f1))
       :effect (and (lift-at ?f2) (not (lift-at ?f1))))
    Der stop-Operator signalisiert der Steuerung des Antriebs 9 des Aufzugs, dass die Kabine auf einem bestimmten Stockwerk f1 bis f7 anzuhalten hat. Der stop-Operator ist im hier dargestellten ersten Ausführungsbeispiel so definiert, dass er das Öffnen und Schliessen der Türen mit beinhaltet. Das Öffnen und Schliessen der Kabinentüren kann aber auch als separate zusätzliche Grundanweisung an den Türmanager 7 eines Aufzugs berücksichtigt werden oder es kann der stop-Operator dahingehend verfeinert werden, dass ein Aufzug auch die Türen öffnen und schliessen kann.
    Die Operatoren zum Aufwärtsfahren -up- und Abwärtsfahren - down- geben die steuerungstechnische Anweisung an die Antriebssteuerung, den Antrieb 9 in die entsprechende Richtung in Gang zu setzen. Die zeitliche Abfolge, in der die der Antrieb 9 mittels den Operatoren angesteuert wird, gibt der Taxifahrer 8 vor.
    Eine Veränderung des Passagierzustands ist grundsätzlich ausschliesslich bei einem Stop der Kabine möglich. Ausgehend von rationalem Verhalten der Passagiere, begeben sich bei einem planmässigen Stop der Aufzugskabine auf einem Stockwerk alle Passagiere, welche auf diesem Stockwerk - origin- warten, um transportiert zu werden in die Kabine und alle Passagiere verlassen die Kabine, wenn diese auf ihrem Zielstockwerk -destin- anhält. Die dadurch eingetretene Veränderung wird hier mit Hilfe des Beobachters 10 im Stop-Operator registriert und dadurch bei der Fahrtfolgeplanung vom Planungssystem 5 berücksichtigt. Wie die Operatoren -up-, -down-, so wird auch der stop-Operator dann als Anweisung für den Antrieb 9 wirksam, wenn die in -effect- kodierten Kriterien alle erfüllt bzw. eingetreten sind. Wird in dem hier beschriebenen Beispiel im stop-Operator ?f=f5, gewählt, so steigt P2 entsprechend der Zustandsbeschreibung 14 und des Verhaltensmodells aus, wenn, wie im Stop-Operator als - effekt- der Operatorinstanz stop(f5) beschrieben, -boarded p2- und -destin p2 f5- gelten.
    Die insoweit entweder in der Operatorenbeschreibung oder als Daten der Zustandsbeschreibung 14 deklarierten Informationen werden zur Berechnung des optimalen Fahrtfolgeplans an das Planungssystem 5 weitergegeben.
    Planungssysteme 5 sind aus anderen technischen Gebieten bereits bekannt. In diesem Ausführungsbeispiel sucht ein IPP Planungssystem, wie es aus Koehler et al., 1997, Extending planning graphs to an ADL subset, erschienen in Steel, S, Proceedings of the 4th European Conference on Planning, 273-285 Springer, Band 1348 of LNAI, verfügbar unter http://www.informatik.uni-freiburg.de/~koehler/ipp.html, eine gültige Folge von STOP Anweisungen, welche das PlanungsZiel 13 (:goal(forall (?p - passenger) (served ?p)) erfüllt. Es können auch andere Planungssysteme verwendet werden, sofern diese in der Lage sind, die momentane Situationsdarstellung gesamthaft zu erfassen und zu verarbeiten.
    Grundsätzlich wählt das Planungssystem 5 bei Eingabe der Zustandsbeschreibung 14 selbständig auf Basis der über die Operatorenbeschreibung zur Verfügung gestellten Operatoren Instanzen aus und bestimmt auch noch die Reihenfolge im ermittelten Fahrtfolgeplan 20. Das Planungssystem 5 bestimmt jeweils die Parameter für die drei Operatoren -stop-, -up-, -down-, die eine gewünschte Zustandsänderung bewirken.
    Das Ergebnis davon ist bei diesem Ausführungsbeipiel eine geplante Fahrtfolge 20, der optimale Plan, der in graphischer Form in Fig. 3 dargestellt ist.
  • Time step 0: up f4 f5
  • Time step 1: stop f5
  • Iime step 2: down f5 f2
  • Time step 3: stop f2
  • Time step 4: up f2 f7
  • Time step 5: stop f7
    • Dieser berechnete optimale Plan 13 wird an den Broker 6 weitergegeben. Der Broker 6 prüft den generierten optimalen Plan daraufhin, wie sich der neu eingeplante Passagier P1 auf den Transport des bereits gebuchten Passagiers auswirkt und teilt dem Terminal das Transportangebot mit.
    Bei dem hier beschriebenen Ausführungsbeispiel liegt nur ein Zielruf zur Planung vor. Folglich ist nur für einen Job ein Angebot abzugeben. Deshalb können zwischen der Angebotsberechnung durch den dezentralen Jobmanager 4 und der Buchung durch das jeweilige Terminal, keine anderen Jobs durch andere Terminals 3.1,3.2,3.3 gebucht werden. Aus diesem Grund entfällt auch die Rückbestätigung seiner Buchung an das Terminal, sondern ist die Buchung sofort verbindlich. Das Terminal nimmt nun die Anzeige auf dem Display vor und der Broker 6 sendet dem Taxifahrer 8 den aktuellen optimalen Fahrtfolgeplan 20.
    Der Taxifahrer 8 fährt diesen aktuellen Fahrtfolgeplan 20 ab, d.h. er sendet die entsprechenden Kommandos in Form der jeweiligen Operatoren an den Antrieb 9 des Aufzugs und den Antrieb der Türe.
    Dieser Fahrtfolgeplan 20 bewirkt, dass die Aufzugskabine im Schritt 0 vom aktuellen Stockwerk f4 auf dem sie sich befindet, zum nächsten Halt auf Stockwerk f5 -stop f5-fährt. Dort hält die Aufzugskabine gemäss Schritt 1 -stop f5- an und die Kabinentüre in vorgegebener Zeit öffnet und schliesst, so dass der Passagier P2 aussteigt und damit bedient, served, ist. Im Schritt 2 fährt die Aufzugskabine abwärts von f5 nach f2 -down f5 f2- und hält im Schritt 3 auf Stockwerk f2 -stop f2-. Dort steigt Passagier P1 zu. Im Schritt 4 fährt der Aufzug aufwärts von Stockwerk f2 nach Stockwerk f7 -up f2 f7- und hält im letzten Schritt 5 auf Stockwerk f7 -stop f7-. Dort kann nun auch Passagier P1 aussteigen. Durch diese Fahrtfolge 13 werden alle Passagiere P1,P2 in den Zustand -served- überführt und die Zielformulierung 10 der Fahrtfolgenplanung ist damit erreicht.
    Während der Taxifahrer 8 den optimalen Fahrtfolgenplan 13 ausführt, überwacht der Beobachter 10 den Zustand der Aufzugsanlage und führt die Situationsdarstellung für den Planer 5 laufend nach. Im Schritt 1 stellt er also fest, dass der Aufzug auf dem Stockwerk f5 angehalten hat und die Türen korrekt geöffnet wurden; er markiert den Passagiere P2 als -served-. Bei Schritt 2 markiert der Beobachter 10 den Passagier P1, der dort auf Stockwerk f2 wartet, als-boarded-. Schliesslich hält die Aufzugskabine auf dem Stockwerk f7 und nachdem die Türen korrekt geöffnet worden sind, setzt der Beobachter 10 auch den Passagier P1 in der Situationsbeschreibung als served und die aktuelle Postion 9 der Aufzugskabine in der Zustandsdarstellung 5 auf Stockwerk f7.
    Dieser erzeugte Fahrtfolgeplan 20 wird nun aber nicht zwingend vollständig ausgeführt, sondern wenn sich Zustand, bzw. die Eigenschaften, von Passagieren und/oder der Anlage relevant ändern bevor er komplett ausgeführt ist, wird erfindungsgemäss ein nächster Planungszyklus gestartet und ein für die neue Planungssituation optimaler Fahrtfolgeplan 20 erstellt. Es erfolgt daher keine Planmodifikation.
    Figur 5 zeigt schematisch die Struktur und den Grundaufbau eines zweiten Ausführungsbeispiels der erfindungsgemässen Zielrufsteuerung. Die Zielrufsteuerung 25 umfasst einen zentralen Jobmanager 26 und zwei dezentrale Jobmanager, einen Konfigurationsmanager 29 sowie stellvertretend für alle vorhandenen Terminals ein Terminal 30, welche über ein Kommunikationsnetzwerk 31 miteinander in Verbindung stehen. Der Aufbau und die Funktion der dezentralen Jobmanagern 27,28 entsprechen im wesentlichen denjenigen des dezentalen Jobmanagers 4 aus dem ersten Ausführungsbeispiels.
    Die Zielrufsteuerung organisiert hier als sogenannte Gruppensteuerung den Verkehr einer Aufzugsgruppe mit zwei Aufzügen A und B in einem Gebäude mit Haltestellen auf sieben Stockwerken. Die Planungsaufgabe stellt sich dabei wie folgt dar:
    Die Aufzugskabine A fährt momentan nach oben; sie befindet sich momentan auf Stockwerk f2 und kann das Stockwerk f3 noch erreichen. Die Aufzugskabine B steht momentan auf Stockwerk f1. Aufzug A transportiert einen Passagier P1 mit Zutrittsbeschränkung auf Stockwerk 3 und 4, der als Ziel Stockwerk f7 angegeben hat, während Aufzug B leer ist. In dieser Situation erscheint ein neuer Passagier P2, der als VIP vorrangig vor allen anderen Passagieren befördert werden muss. Passagier P2 hat gerade seinen Transportauftrag von Stockwerk 3 nach Stockwerk f7 abgegeben.
    Es ist also eine Zuteilung des Passagiers P2 auf einen der beiden im Beispiel bekannten Aufzüge A,B derart vorzunehmen, dass die Passagiere P1,P2 mit möglichst wenigen Stops befördert werden und die gewünschte Service-Anforderungen - VIP - und - Zutrittsbeschränkung - erfüllt sind.
    Der zentrale Jobmanager 26 sammelt die Anfragen der Terminals zusammen mit den jeweils erfassten personenbezogenen Daten aus dem Konfigurationsmanager 29 als sogenannte Jobs, hier Job 1 bis Job 4, in einer Warteschlange, wie in Figur 6 dargestellt. Er wählt den ersten Job 1 aus der Schlange aus und sendet diesen an die dezentralen Jobmanager 27,28 der einzelnen Aufzüge. Jeder der dezentralen Jobmanager 27,28 der Aufzüge A,B ermittelt unabhängig von dem anderen mit Hilfe seines Planungssystems seine beste Fahrtfolgenlösung auf der Basis des vorgegebenen Optimierungskriteriums und sendet diese als Angebot an den zentralen Jobmanager 26 zurück. Der zentrale Jobmanager 26 prüft alle Angebote, wählt aus diesen das beste Angebot aus und bucht den Passagier auf den Aufzug mit dem besten Angebot. Die Identifikation des besten Aufzugs wird nach einer erfolgreichen Zuweisung an das Terminal 30 gesendet, auf dem der Job ursprünglich initiert worden ist. Das Terminal 30 fungiert damit lediglich als Display. Der Job 1 ist damit erledigt und wird gestrichen. Der Vorgang wieder holt sich nur mit dem Job 2 usw., bis alle Jobs der Warteschlage abgearbeitet sind.
    Jeder dezentrale Jobmanager 27,28 der Aufzüg A,B erstellt für die als Job zur aktuellen Planungsaufgabe übermittelten registrierten Daten/ Informationen zunächst eine Situationsdarstellung, die an das jeweilige Planungssystem 21 übergeben wird. Die Situationsdarstellung enthält eine Zustandsbeschreibung 32 und eine Operatorbeschreibung.
    Für Aufzug A werden in einer Objektdeklaration 33 die gemeldeten Passagiere P1,P2 und die Stockwerke f1 bis f7 des Gebäudes dem Planungssystem bekannt gemacht. Für jedes Objekt wird eine typisierte Konstante eingeführt. Ausserdem erfolgt in der Objektdeklaration 33 für jeden Passagier P1,P2 eine Zuordnung zu einer oder mehreren Service-Anforderungen, wie z.B. VIP, conflict, going_direct, usw..
    Die Service-Anforderungen sind jeweils im Rahmen der Passagiererkennung aus dem Konfigurationsmanager 29 bekannt und werden von dem zentralen Jobmanager 26 als Teils eines Jobs, bzw. einer Angebotsanfrage, an die dezentralen Jobmanager 27,28 der einzelnen Aufzüge A,B weitergeleitet. Bestimmte Service-Anforderungen für alle oder beliebig ausgewählte Passagiere können in Abhängigkeit vom Zustand der Aufzugsanlage oder des Gebäudes auch tageszeitabhängig aktivierbar vorgesehen werden. Ferner ist durch die Anwendung eines Planungssystems zur Fahrtfolgebestimmung eine flexible Gewichtung der einzelnen Service-Anforderungen, insbesondere der VIP-Anforderung, in Abhängigkeit des Verkehrsaufkommens darstellbar.
    Hier sind folgende Service-Anforderungen vorgesehen:
    • Einteilung aller Passagiere in zwei Gruppen conflict_A und conflict_B, die sich im Aufzug nie begegnen dürfen;
    • Passagiere vom Typ never_alone, für die ein Begleiter in Form eines
    • Passagiers vom Typ attendant im Aufzug während der Fahrt anwesend sein muss. Dabei ist es nicht zwingend erforderlich, dass während der Fahrt immer derselbe Begleiter im Aufzug fährt, sondern dieser kann auch wechseln;
    • Passagiere vom Typ going_direct, die ohne Zwischenstop zu ihrem Ziel befördert werden;
    • Passagiere vom Typ vip, die vorrangig vor allen anderen Passagieren befördert werden;
    • Passagiere, für die eine Zutrittsbeschränkung auf bestimmten Stockwerken formuliert ist;
    • Passagiere vom Typ going_up, die ausschliesslich aufwärts transportiert werden;
    • Passagier vom Typ going_down, die ausschliesslich abwärts transportiert werden.
    Ein Passagier P1,P2 kann damit durchaus Gegenstand einer Vielzahl von Service-Anforderungen sein; allerdings sollten sich diese nicht widersprechen, damit der Passagier auch wirklich befördert werden kann. Ein elementarer Widerspruch sind zum Beispiel zwei Passagiere P1, P2 für die folgende Typisierung deklariert ist:
  • (P1 (either conflict_A never_alone))
  • (P2 (either conflict_B attendant))
    • P1 darf hier nicht allein im Aufzug fahren und gehört gleichzeitig zur Passagiergruppe A. Der einzige dem System bekannte mögliche Begleiter P2 gehört aber zur Passagiergruppe B, die Passagiergruppe A nie im Aufzug treffen darf. Eine Begleitung verletzt also die Ausschlussbedingung und P1 kann erst befördert werden, wenn dem System ein anderer Begleiter bekannt wird, der nicht zur Gruppe B gehört.
    Für Aufzug A enthält die Objektdeklaration 33 den bereits fahrende Passagier P1, ein normaler Passagier, den neuen Passagier P2, ein VIP, sowie alle 7 Stockwerke f1 bis f7.
    (:objects
    (p1   - passenger )
    (p2   - vip )
    (f1, f2, f3, f4, f5, f6, f7   - floor ))
    Unter der Annahme, dass von jedem Stockwerk aus jedes andere bedient werden kann, wird bei diesem Ausführungsbeispiel auf eine ausdrückliche Beschreibung der Gebäudetopologie verzichtet.
    Der aktuelle registrierte Transportauftrag 34 der Passagiere P1 und P2 stellt sich dar als
    (:init (origin p1 f1)
    (origin p2 f3)
    (destin p1 f7)
    (destin p2 f7)
    (boarded p1)
    Dem Transportauftrag 34 liegt die Standardannahme zugrunde, dass Passagiere auf dem Stockwerk warten, wenn keine entsprechende boarded-Information vorliegt. Zutreffend bedeutet dies hier, dass Passagier P2 auf dem Stockwerk wartet. Die Zutrittsbeschränkung für Passagier P1, stellt sich darin dar als
    (no-access p1 f3)
    (no-access p1 f4)
    Die aktuelle Position 35 der Aufzugskabine 2 des Aufzugs A ist als
    (lift-at f2))
    in der Zustandsbeschreibung 32 ausgedrückt. Es werden alle aufgeführten Fakten als wahr, alle anderen als falsch gewertet.
    Das Ziel 36 für das Planungssystem wird als
    (:goal (forall (?p - passenger) (served ?p))
    formuliert.
    Gesucht ist die kürzeste Folge von Stops, die alle Passagiere P1, P2 in den Zustand served überführt, der genau dann erreicht ist, wenn sie auf ihrem Zielstockwerk, jeweils Stockwerk f7, ausgestiegen sind.
    Da in diesem Ausführungsbeispiel nur eine minimale Stop Folge zu ermitteln ist, erhält das Planungssystem auch nur einen sogenannten Stop-Operator 37, aus dem es einen gültigen Fahrtfolgeplan konstruieren kann. In Fig. 9 ist ein Beispiel eines Stop-Operator 37 dargestellt. Wie zuvor bei der Zustandsbeschreibung 32, dient auch hier die Modellierungsprache PDDL nach McDermott et al. 1998 zur Veranschaulichung. Der Stop-Operator 37 enthält, eine Vorgabenbeschreibung 38 in der beschrieben ist, wann ein Stop eines Aufzugs A,B auf einem Stockwerk f1 bis f7 zulässig ist. Hier sind dies die Zutrittsbeschränkung - no-access -, welche entweder konkret für einen Passagier oder aber für eine Passagiergruppe definiert wird und eine Funktionsanweisung 39 in der festgelegt ist, auf welchem Stockwerk f1 bis f7 eine Aufzugskabine bei einem zulässigen Stop halten soll und welche Auswirkung dieser Halt auf den aktuellen Zustand der Aufzugsanlage 18 hat. Vorbedingungen der Funktionsanweisung 39 stellen dabei die anwendungsspezifische Umsetzung der gewünschten Service-Anforderungen dar. Der in Figur 9 gezeigte komplexe Stop-Operator 37 ermöglicht es dem Planungssystem mit allen in der Passagier- und Objektdeklaration 33 eingeführten Service-Anforderungen umzugehen.
    Für das hier beschriebene Planungsbeispiel sind nur die in Fig. 9 unterstrichenen Vorbedingungen des Operators 32 relevant, die die Bedingungen an einen Stop auf einem Stockwerk f1 bis f7 unter der Anwesenheit von VIPs und Passagieren mit Zutrittsbeschränkung formulieren.
    Die insoweit für jeden Aufzug A erstellte momentane Situationsdarstellung 32, wird an das zu dem Aufzug A gehörende Planungssystem weitergegeben.
    Die gemäss der Erfindung verwendeten geeigneten Planungssysteme arbeiten unabhängig vom eigentlichen Planungsproblem. Solche Planungssysteme sind aus anderen technischen Gebieten bereits bekannt.
    Auch in diesem zweiten Ausführungsbeispiel sucht jeweils ein IPP Planungssystem, wie es bekannt ist aus Koehler et al., 1997, Extending planning graphs to an ADL subset, erschienen in Steel, Proceedings of the 4th European Conference on Planning, S. 273-285, Springer, Band 1348 of LNAI und unter http://www.informatik.uni-freiburg.de/~koehler/ipp.html verfügbar ist, eine gültige Folge von STOP Anweisungen, welche das Planungsziel 31 erfüllt. Es können auch andere Planungssysteme verwendet werden, sofern diese in der Lage sind, die momentane Situationsdarstellung gesamthaft zu erfassen und zu verarbeiten.
    Beim Lösen einer konkreten Planungsaufgabe wählt das Planungssystem die in dem Fahrtfolgeplan zu verwendenden Operatoren der Operatorbeschreibung aus, hier den Stop-Operator 37. Treten Service-Anforderungen , wie z.B. VIP, going_direct, etc., in der Zustandsbeschreibung 32 auf, so überprüft das Planungssystem selbständig die entsprechende Vorbedingung der Funktionsanweisung 39 des Operators 37. Fehlt eine im Operator 37 als Vorbedingung enthaltene Service-Anforderung in der rufrelevanten Zustandsbeschreibung 32, so wird diese dann überflüssige Vorbedingung des Operators 37 automatisch ignoriert. Ein Beispiel einer hier nicht berücksichtigten Service-Anforderungen ist die Vorbedingung -attendant-. Dann bestimmt das konkrete Werte für Operatorparameter sowie eine Anordnungsreihenfolge, in der Operatoren im Fahrtfolgeplan auftreten. Diese Anordnungsreihenfolge spezifiziert die Ausführungsreihenfolge der Operatoren im Fahrtfolgeplan und damit die Fahrtfolge zur Bedienung des jeweiligen Zielrufs.
    Für Aufzug A kann das Planungssystem keine Lösung finden: Passagier P2 soll sofort befördert werden, d.h. der Aufzug A müsste in f3 halten. Allerdings befindet sich P1 im Aufzug, der auf f3 keinen Zutritt hat. Ein Halt auf f3 ist also erst möglich nachdem P1 ausgestiegen ist, d.h. der Aufzug A müsste zuerst Stockwerk f7 anfahren; dies ist wiederum nicht gestattet, da die VIP Bedingung erfordert, dass VIP vor allen anderen Passagieren befördert werden.
    Für Aufzug B (Figur 8) ist die Situation 42 durch das Planungssystem problemlos lösbar, da Aufzug B den Passagier P1 gar nicht kennt, weil dieser ja im Aufzug A unterwegs ist und nur den neuen Passagier P2 gemeldet bekommt. Die Objektdeklaration 43 für Aufzug B an das Planungssystem beinhaltet folglich auch nur den neuen Passagier P2, der durch die Service-Anforderung VIP typisiert ist sowie alle 7 Stockwerke f1 bis f7.
    (:objects
    (p2   - vip)
    (f1,f2,f3,f4,f5,f6,f7   - floor ))
    Wiederum kann von jedem Stockwerk aus jedes andere bedient werden.
    Der aktuelle Transportauftrag 44 des Passagiers P2 stellt sich dar als
    (:init
    (origin p2 f3)
    (destin p2 f7).
    Die aktuelle Positionsbeschreibung 45 der Aufzugskabine B ist in der Zustandsbeschreibung 42 als
    (lift-at f1)
    ausgedrückt.
    Bei dem Aufzug B ist die Zielformulierung 46 für das Planungssystem identisch mit derjenigen des Aufzugs A. Sie wird zusammen mit der Objektdeklaration 43 und dem oben beschriebenen Stop Operator 37 als Teil der Situationsdarstellung 42 des Aufzugs B an das Planungssystem übergeben. Zur Planung der Fahrtfolge des Aufzugs B ist nur die Operator-Vorbedingung: Stop auf einem Stockwerk unter der Anwesenheit von VIP, relevant, weil die Zustandsbeschreibung 32 für Aufzug B auch nur die Service-Anforderung VIP an das Planungssystem übergibt. Alle übrigen in Form von Vorgaben 33 und Vorbedingungen der Funktionsanweisung 39 des STOP-Operators 37 vorgesehenen Service-Anforderungen bleiben bei dieser Planungssequenz unberücksichtigt und deshalb ohne Wirkung auf den Fahrtfolgeplan.
    Das Planungssystem generiert ausgehend von diesem input für Aufzug B folgenden Fahrtfolgeplan
  • time step 1: (stop 3)
  • time step 2: (stop 7),
    • der eine minimale Stopfolge zur erfolgreichen Beförderung von Passagier P2 darstellt.
    Sind die Ergebnisse der Fahrtfolgeplanung der Aufzüge A,B beim zentralen Jobmanager 26 eingetroffen, dann bewertet dieser die beiden Fahrtfolgeangebote der Aufzüge A,B. Der Aufzug mit dem besten Angebot wird vom zentralen Jobmanager 26 ausgewählt. Die beste Lösung ist hier der einzig mögliche Fahrtfolgeplan des Aufzugs B. Folglich bucht der zentrale Jobmanager 26 den Passagier P2 auf den Aufzug B. Aufzug B aktualisiert nach Erhalt der Buchung auch den Fahrtfolgeplan; alle anderen Aufzüge fahren weiterhin nach ihrem bisherigen Plan.

    Claims (12)

    1. Verfahren zur Fahrtfolgeplanung einer Aufzugsanlage, die mindestens einen Aufzug umfasst, bestehend aus:
      a. dem Registrieren von Zielrufen durch eine an Stockwerken der Aufzugsanlage angeordnete Sensorik (3.1,3.2,3.3),
      gekennzeichnet durch die folgende Verfahrenschritte:
      b. Eintragen von Zielrufen in eine Situationsdarstellung (12) für jeden Aufzug, welche Situationsdarstellung (12) den momentanen Betriebszustand (18) und die Verkehrssituation (15,17) des Aufzugs definiert,
      c. Berechnen einer optimale Fahrtfolge für jede Situationsdarstellung (12) unter Berücksichtigung eines vorgewählten Optimierungskriteriums wie minimale Warte- und/oder Bedien- und/oder Fahrtzeiten der Passagiere, und
      d. Buchen des Aufzugs, der der besten der jeweiligen optimalen Fahrtfolge entspricht, um den Zielruf zu erfüllen.
    2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass Zielrufe in einer Aufzugsanlage mit mehreren Aufzügen registriert werden,
      dass diese registrierten Zielrufe an einen zentralen Jobmanager (26) übermittelt werden,
      dass jeder Aufzug einen Jobmanager (27,28) aufweist, welche vom zentralen Jobmanager (26) für jeden registrierten Zielruf um ein Transportangebot angefragt werden,
      dass von diesen Jobmanagern (27,28) der Anfrage entsprechende Transportangebote an den zentralen Jobmanager (26) übermittelt werden, und
      dass vom zentralen Jobmanager (26) aus den übermittelten Transportangeboten für einen registrierten Zielruf eine bezüglich des Optimierungskriteriums optimale Fahrtfolge gebucht wird.
    3. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass Zielrufe in einer Aufzugsanlage mit mehreren Aufzügen registriert werden,
      dass jeder Aufzug einen Jobmanager (4) aufweist, welche Jobmanager (4) für jeden registrierten Zielruf um ein Transportangebot angefragt werden,
      dass von den Jobmanagern (4) der Anfrage entsprechende Transportangebote gemacht werden, und
      dass aus diesen Transportangeboten für einen registrierten Zielruf eine bezüglich des Optimierungskriteriums optimale Fahrtfolge gebucht wird.
    4. Verfahren nach einem der Ansprüche 1 bis 3, dadurch gekennzeichnet, dass Zielrufe an Registriereinrichtungen (3.1,3.2,3.3) der Stockwerke registriert werden, und
      dass ein Aufzug, welcher einer gebuchten Fahrtfolge entspricht, an der Registriereinrichtung (3.1,3.2,3.3) angezeigt wird, welche den Zielruf registriert hat.
    5. Verfahren nach einem der Ansprüche 1 bis 4, dadurch gekennzeichnet, dass die Situationsdarstellung Operatoren enthält, welche elementaren Zustandsübergänge (16) der Aufzugsanlage spezifizieren,
      dass zu verwendende Operatoren bezüglich des Optimierungskriteriums auswählt werden,
      dass für diese Operatoren konkrete Werte für Operatorenparameter bestimmt werden, und
      dass eine Anordnungsreihenfolge, in der diese Operatoren in der Fahrtfolgeplanung auftreten, bestimmt wird.
    6. Verfahren nach Anspruch 5, dadurch gekennzeichnet, dass Operatoren ausgewählt werden, welche steuerungstechnische Anweisungen bezüglich Service-Anforderungen beinhalten.
    7. Zielrufsteuerung für eine Aufzugsanlage zur Bestimmung der Fahrtfolge einer oder mehrerer Aufzüge der Aufzugsanlage mit Registriereinrichtungen (3.1,3.2,3.3) an Stockwerken der Aufzugsanlage zum Registrieren von Zielrufen,
      dadurch gekennzeichnet, dass
      eine Verarbeitungseinheit (4) vorgesehen ist, die für jeden Aufzug eine Situationsdarstellung (12) und einen Planer (5) umfasst, welche Situationsdarstellung (12) den momentanen Betriebszustand (18) und die Verkehrssituation (15,17) des Aufzugs definiert, und welcher Planer (5) eine optimale Fahrtfolge für jede Situationsdarstellung (12) berechnet unter Berücksichtigung eines vorgewählten Optimierungskriteriums wie minimale Warte- und/oder Bedien- und/oder Fahrtzeiten der Passagiere.
    8. Zielrufsteuerung nach Anspruch 7, dadurch gekennzeichnet, dass die Situationsdarstellung Parametern über den aktuellen Betriebszustand der Aufzugsanlage und den herzustellenden Zielzustand der Aufzugsanlage enthält, und
      dass die Situationsdarstellung Parametern enthält, welche elementaren Zustandsübergänge (16) der Aufzugsanlage spezifizieren.
    9. Zielrufsteuerung nach Anspruch 7 oder 8, dadurch gekennzeichnet, dass die Aufzugsanlage mehrere Aufzüge aufweist,
      dass ein zentraler Jobmanager (26) vorgesehen ist, welcher über ein Kommunikationsnetzwerk von den Registriereinrichtungen (3.1,3.2.3.3) alle registrierten Zielrufe empfängt,
      dass jeder Aufzug einen Jobmanager (27,28) aufweist,
      dass der zentrale Jobmanager (26) diese Jobmanager (27,28) über das über das Kommunikationsnetzwerk (2) für jeden registrierten Zielruf um ein Transportangebot anfragt,
      dass diese Jobmanagern (27,28) der Anfrage entsprechende Transportangebote über das Kommunikationsnetzwerk (2) an den zentralen Jobmanager (27,28) übermitteln, und
      dass der zentrale Jobmanager (26) für einen registrierten Zielruf aus den übermittelten Transportangeboten einer bezüglich des Optimierungskriteriums optimalen Fahrtfolge bucht.
    10. Zielrufsteuerung nach Anspruch 7 oder 8, dadurch gekennzeichnet, dass die Aufzugsanlage mehrere Aufzüge aufweist,
      dass jeder Aufzug einen Jobmanager (4) aufweist,
      dass eine Registriereinrichtung (3.1,3.2,3.3) diese Jobmanager (4) über ein Kommunikationsnetzwerk (2) für jeden registrierten Zielruf um ein Transportangebot anfragt,
      dass diese Jobmanager (4) der Anfrage entsprechende Transportangebote über das Kommunikationsnetzwerk (2) an die anfragende Registriereinrichtung (3.1,3.2,3.3) übermitteln, und
      dass diese Registriereinrichtung (3.1,3.2,3.3) für den registrierten Zielruf aus diesen Transportangeboten einer bezüglich des Optimierungskriteriums optimalen Fahrtfolge bucht.
    11. Zielrufsteuerung nach Anspruch 9 oder 10, dadurch gekennzeichnet, dass eine Registriereinrichtung (3.1,3.2,3.3) welche einen Zielruf registriert hat, den Aufzug anzeigt, welcher einem gebuchten Fahrtfolge entspricht.
    12. Aufzugsanlage bestehend aus mindestens einem Aufzug mit einem Deck und mindestens einem Aufzug mit zwei Decks und einer Zielrufsteuerung nach einem der Ansprüche 7 bis 11.
    EP01914940A 2000-03-29 2001-03-29 Zielrufsteuerung für aufzüge Revoked EP1276691B1 (de)

    Priority Applications (1)

    Application Number Priority Date Filing Date Title
    EP01914940A EP1276691B1 (de) 2000-03-29 2001-03-29 Zielrufsteuerung für aufzüge

    Applications Claiming Priority (6)

    Application Number Priority Date Filing Date Title
    EP00106768 2000-03-29
    EP00106767 2000-03-29
    EP00106767 2000-03-29
    EP00106768 2000-03-29
    PCT/CH2001/000205 WO2001072621A1 (de) 2000-03-29 2001-03-29 Zielrufsteuerung für aufzüge
    EP01914940A EP1276691B1 (de) 2000-03-29 2001-03-29 Zielrufsteuerung für aufzüge

    Publications (2)

    Publication Number Publication Date
    EP1276691A1 EP1276691A1 (de) 2003-01-22
    EP1276691B1 true EP1276691B1 (de) 2005-08-17

    Family

    ID=26070754

    Family Applications (1)

    Application Number Title Priority Date Filing Date
    EP01914940A Revoked EP1276691B1 (de) 2000-03-29 2001-03-29 Zielrufsteuerung für aufzüge

    Country Status (13)

    Country Link
    US (1) US6793044B2 (de)
    EP (1) EP1276691B1 (de)
    JP (1) JP2003528785A (de)
    CN (1) CN1220614C (de)
    AT (1) ATE302158T1 (de)
    AU (2) AU4220801A (de)
    BR (1) BR0109529A (de)
    DE (1) DE50107119D1 (de)
    DK (1) DK1276691T3 (de)
    ES (1) ES2248295T3 (de)
    HK (1) HK1054364B (de)
    MX (1) MXPA02009377A (de)
    WO (1) WO2001072621A1 (de)

    Cited By (8)

    * Cited by examiner, † Cited by third party
    Publication number Priority date Publication date Assignee Title
    DE102006046062A1 (de) 2006-09-27 2008-04-03 Deutsches Zentrum für Luft- und Raumfahrt e.V. Verfahren zum Steuern eines Aufzug- oder ähnlichen Beförderungssystems
    EP3015412A1 (de) 2014-11-03 2016-05-04 K. A. Schmersal Holding GmbH & Co. KG Bedienung eines aufzugs mittels touchscreen
    EP2346766B1 (de) 2008-10-24 2016-12-28 Kone Corporation Aufzugsystem
    WO2019120899A1 (de) 2017-12-21 2019-06-27 Inventio Ag Verfahren und aufzugsteuerung zum steuern einer aufzuggruppe mit einer mehrzahl von aufzügen basierend auf zielrufen
    WO2020161069A1 (de) 2019-02-08 2020-08-13 Inventio Ag Aufzugsanlage mit aufzugsbedieneinrichtungen für passagiere mit körperlichen einschränkungen
    WO2022043371A1 (de) 2020-08-31 2022-03-03 Inventio Ag Aufzugsanlage mit aufzugsbedieneinrichtungen für passagiere mit eingeschränkter mobilität
    DE102022110202A1 (de) 2022-04-27 2023-11-02 Tk Elevator Innovation And Operations Gmbh Aufzugsystem und Verfahren zum Betreiben eines Aufzugsystems
    DE102022110209A1 (de) 2022-04-27 2023-11-02 Tk Elevator Innovation And Operations Gmbh Verfahren zum Betreiben einer Aufzuganlage

    Families Citing this family (26)

    * Cited by examiner, † Cited by third party
    Publication number Priority date Publication date Assignee Title
    JP4960585B2 (ja) 2003-10-10 2012-06-27 インベンテイオ・アクテイエンゲゼルシヤフト エレベータ装置の制御方法およびエレベータ装置
    TW594510B (en) * 2003-11-05 2004-06-21 Ind Tech Res Inst Method and system of automatic service composition
    FI115297B (fi) * 2004-01-26 2005-04-15 Kone Corp Hissijärjestely
    FI117091B (fi) * 2005-03-15 2006-06-15 Kone Corp Menetelmä kuljetusjärjestelmän hallitsemiseksi
    FI118381B (fi) 2006-06-19 2007-10-31 Kone Corp Hissijärjestelmä
    JP4388546B2 (ja) * 2006-12-28 2009-12-24 株式会社日立製作所 エレベータ群管理システムおよびそのサービスエレベータ案内表示方法
    US8151943B2 (en) * 2007-08-21 2012-04-10 De Groot Pieter J Method of controlling intelligent destination elevators with selected operation modes
    FI119686B (fi) * 2007-10-11 2009-02-13 Kone Corp Hissijärjestelmä
    CN101980942B (zh) * 2008-03-31 2014-06-04 奥蒂斯电梯公司 电梯轿厢分配控制策略
    WO2009141900A1 (ja) * 2008-05-21 2009-11-26 三菱電機株式会社 エレベータ群管理システム
    AU2009276023B2 (en) 2008-07-31 2016-06-09 Inventio Ag Method for controlling an elevator system with consideration for disabled persons and privileged users
    JP2013510060A (ja) 2009-11-10 2013-03-21 オーチス エレベータ カンパニー 分散型配車を行うエレベータシステム
    CN102666336B (zh) * 2009-12-11 2014-10-15 三菱电机株式会社 电梯系统
    WO2012032649A1 (ja) 2010-09-10 2012-03-15 三菱電機株式会社 エレベータの運転装置
    CN103466398B (zh) * 2013-09-25 2015-04-22 苏州爱立方服饰有限公司 一种基于遗传算法-神经网络算法的电梯对重调节方法
    CN103601046B (zh) * 2013-11-28 2016-09-21 深圳市捷顺科技实业股份有限公司 一种电梯控制方法及系统
    EP3002242A1 (de) 2014-09-30 2016-04-06 Inventio AG Steuerungsverfahren für ein Aufzugssystem mit einzeln angetriebenen Kabinen und geschlossener Fahrbahn
    CN107000963A (zh) 2014-11-13 2017-08-01 奥的斯电梯公司 电梯控制系统覆盖系统
    US20180099839A1 (en) * 2016-10-07 2018-04-12 Otis Elevator Company Elevator call system with mobile device
    US10486938B2 (en) 2016-10-28 2019-11-26 Otis Elevator Company Elevator service request using user device
    WO2019116515A1 (ja) * 2017-12-14 2019-06-20 三菱電機株式会社 検索システム及び監視システム
    CN112672967B (zh) * 2018-09-26 2023-04-28 三菱电机楼宇解决方案株式会社 电梯系统以及便携式终端
    CN109809262B (zh) * 2019-02-18 2021-10-22 南京亿数信息科技有限公司 一种电梯权限安全控制系统
    US11305964B2 (en) 2020-07-15 2022-04-19 Leandre Adifon Systems and methods for operation of elevators and other devices
    US20220073316A1 (en) 2020-07-15 2022-03-10 Leandre Adifon Systems and methods for operation of elevators and other devices
    CN115744921B (zh) * 2022-11-22 2024-01-09 安徽科昂纳米科技有限公司 一种基于甲基硅酸钠与硅酸钠混合硅源的二氧化硅气凝胶及其制备方法

    Family Cites Families (10)

    * Cited by examiner, † Cited by third party
    Publication number Priority date Publication date Assignee Title
    KR100202716B1 (ko) * 1996-12-17 1999-06-15 이종수 엘리베이터의 신호 전송장치
    JPH0252875A (ja) * 1988-08-16 1990-02-22 Mitsubishi Electric Corp エレベーターの自動学習群管理装置
    JPH07110748B2 (ja) * 1989-06-14 1995-11-29 株式会社日立製作所 エレベータの群管理制御装置
    JP2608970B2 (ja) * 1990-06-15 1997-05-14 三菱電機株式会社 エレベータの群管理装置
    JP2846102B2 (ja) * 1990-11-05 1999-01-13 株式会社日立製作所 群管理エレベーターシステム
    US5767461A (en) * 1995-02-16 1998-06-16 Fujitec Co., Ltd. Elevator group supervisory control system
    GB2311148B (en) * 1996-03-12 1998-03-11 Hitachi Ltd Elevator control system
    FI111929B (fi) * 1997-01-23 2003-10-15 Kone Corp Hissiryhmän ohjaus
    JP4494696B2 (ja) * 1999-10-21 2010-06-30 三菱電機株式会社 エレベーター群管理装置
    JP4870863B2 (ja) * 2000-04-28 2012-02-08 三菱電機株式会社 エレベータ群最適管理方法、及び最適管理システム

    Cited By (11)

    * Cited by examiner, † Cited by third party
    Publication number Priority date Publication date Assignee Title
    DE102006046062A1 (de) 2006-09-27 2008-04-03 Deutsches Zentrum für Luft- und Raumfahrt e.V. Verfahren zum Steuern eines Aufzug- oder ähnlichen Beförderungssystems
    DE102006046062B4 (de) 2006-09-27 2018-09-06 Deutsches Zentrum für Luft- und Raumfahrt e.V. Verfahren zum Steuern eines Aufzug- oder ähnlichen Beförderungssystems
    EP2346766B1 (de) 2008-10-24 2016-12-28 Kone Corporation Aufzugsystem
    EP2346766B2 (de) † 2008-10-24 2024-06-19 Kone Corporation Aufzugsystem
    EP3015412A1 (de) 2014-11-03 2016-05-04 K. A. Schmersal Holding GmbH & Co. KG Bedienung eines aufzugs mittels touchscreen
    DE102014115999A1 (de) 2014-11-03 2016-05-04 K.A. Schmersal Gmbh & Co. Kg Bedienung eines Aufzugs mittels Touchscreen
    WO2019120899A1 (de) 2017-12-21 2019-06-27 Inventio Ag Verfahren und aufzugsteuerung zum steuern einer aufzuggruppe mit einer mehrzahl von aufzügen basierend auf zielrufen
    WO2020161069A1 (de) 2019-02-08 2020-08-13 Inventio Ag Aufzugsanlage mit aufzugsbedieneinrichtungen für passagiere mit körperlichen einschränkungen
    WO2022043371A1 (de) 2020-08-31 2022-03-03 Inventio Ag Aufzugsanlage mit aufzugsbedieneinrichtungen für passagiere mit eingeschränkter mobilität
    DE102022110202A1 (de) 2022-04-27 2023-11-02 Tk Elevator Innovation And Operations Gmbh Aufzugsystem und Verfahren zum Betreiben eines Aufzugsystems
    DE102022110209A1 (de) 2022-04-27 2023-11-02 Tk Elevator Innovation And Operations Gmbh Verfahren zum Betreiben einer Aufzuganlage

    Also Published As

    Publication number Publication date
    US6793044B2 (en) 2004-09-21
    HK1054364A1 (en) 2003-11-28
    JP2003528785A (ja) 2003-09-30
    BR0109529A (pt) 2003-06-10
    ATE302158T1 (de) 2005-09-15
    AU2001242208B2 (en) 2006-02-16
    AU4220801A (en) 2001-10-08
    ES2248295T3 (es) 2006-03-16
    US20030085079A1 (en) 2003-05-08
    HK1054364B (zh) 2005-11-25
    EP1276691A1 (de) 2003-01-22
    CN1420836A (zh) 2003-05-28
    WO2001072621A1 (de) 2001-10-04
    MXPA02009377A (es) 2003-02-12
    CN1220614C (zh) 2005-09-28
    DK1276691T3 (da) 2005-12-19
    DE50107119D1 (de) 2005-09-22

    Similar Documents

    Publication Publication Date Title
    EP1276691B1 (de) Zielrufsteuerung für aufzüge
    DE69802876T2 (de) Passagier-reisezeit optimierendes steuerverfahren für aufzugsgruppen aus doppeldeck-aufzügen
    DE69308639T2 (de) Zyklisch veränderliche Aufzugsgruppe
    EP0312730B1 (de) Gruppensteuerung für Aufzüge mit lastabhängiger Steuerung der Kabinen
    DE69632750T2 (de) Verfahren und Vorrichtung zur Aufzugsgruppensteuerung
    DE60308837T2 (de) Verfahren zur zuteilung von benutzern in einer aufzugsgruppe
    EP1319625B1 (de) Vorrichtung und Verfahren zur Modernisierung einer Aufzugsanlage
    DE60032605T2 (de) Verfahren zum Verarbeiten automatischer Aufzugrufe zu vorbestimmten Zielen
    EP0356731B1 (de) Gruppensteuerung mit Sofortzuteilung von Zielrufen
    DE69714347T2 (de) Aufzugssystem mit Gruppensteuerung
    EP0440967B1 (de) Gruppensteuerung für Aufzüge mit vom Rufeingabeort auf einem Stockwerk abhängiger Sofortzuteilung von Zielrufen
    DE69511587T2 (de) Zuteilung einer Wechselaufzugskabine zu mehreren Gruppen
    DE3611173C2 (de) Fahrstuhlanlage mit mehreren Doppelabteil-Kabinen
    DE102014220966A1 (de) Verfahren zum Betreiben einer Transportanlage sowie entsprechende Transportanlage
    DE69323923T2 (de) Verfahren zur Steuerung einer Aufzugsgruppe
    DE69208427T2 (de) Aufzugssystem mit dynamischer Sektorzuteilung
    EP0246395A1 (de) Gruppensteuerung für Aufzüge
    EP0365782B1 (de) Verfahren und Einrichtung zur Gruppensteuerung von Aufzügen mit Doppelkabinen
    WO2016135090A1 (de) Verfahren zum betreiben eines aufzugsystems mit mehreren schächten und mehreren kabinen
    EP1319624A1 (de) Einrichtung und Verfahren zur Modernisierung einer Aufzugsanlage
    DE2459887A1 (de) Steuervorrichtung fuer aufzuege
    EP0459169B1 (de) Gruppensteuerung für Aufzüge mit Doppelkabinen mit Sofortzuteilung von Zielrufen
    DE69517366T2 (de) Wartezeitanzeige für einen Aufzug
    DE69419891T2 (de) Intelligent verteilte Steuerung für Aufzüge
    DE69509264T2 (de) Durchführung von Zwischenstockwerkrufen mit einer Wechselaufzugskabine

    Legal Events

    Date Code Title Description
    PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

    Free format text: ORIGINAL CODE: 0009012

    17P Request for examination filed

    Effective date: 20020919

    AK Designated contracting states

    Kind code of ref document: A1

    Designated state(s): AT BE CH CY DE DK ES FI FR GB GR IE IT LI LU MC NL PT SE TR

    AX Request for extension of the european patent

    Free format text: AL;LT;LV;MK;RO;SI

    17Q First examination report despatched

    Effective date: 20030310

    GRAP Despatch of communication of intention to grant a patent

    Free format text: ORIGINAL CODE: EPIDOSNIGR1

    GRAS Grant fee paid

    Free format text: ORIGINAL CODE: EPIDOSNIGR3

    GRAA (expected) grant

    Free format text: ORIGINAL CODE: 0009210

    AK Designated contracting states

    Kind code of ref document: B1

    Designated state(s): AT BE CH CY DE DK ES FI FR GB GR IE IT LI LU MC NL PT SE TR

    REG Reference to a national code

    Ref country code: GB

    Ref legal event code: FG4D

    Free format text: NOT ENGLISH

    REG Reference to a national code

    Ref country code: CH

    Ref legal event code: EP

    REG Reference to a national code

    Ref country code: IE

    Ref legal event code: FG4D

    Free format text: LANGUAGE OF EP DOCUMENT: GERMAN

    REF Corresponds to:

    Ref document number: 50107119

    Country of ref document: DE

    Date of ref document: 20050922

    Kind code of ref document: P

    GBT Gb: translation of ep patent filed (gb section 77(6)(a)/1977)

    Effective date: 20050919

    PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

    Ref country code: GR

    Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

    Effective date: 20051117

    REG Reference to a national code

    Ref country code: HK

    Ref legal event code: GR

    Ref document number: 1054364

    Country of ref document: HK

    REG Reference to a national code

    Ref country code: SE

    Ref legal event code: TRGR

    REG Reference to a national code

    Ref country code: DK

    Ref legal event code: T3

    PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

    Ref country code: PT

    Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

    Effective date: 20060117

    REG Reference to a national code

    Ref country code: ES

    Ref legal event code: FG2A

    Ref document number: 2248295

    Country of ref document: ES

    Kind code of ref document: T3

    PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

    Ref country code: LU

    Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

    Effective date: 20060331

    ET Fr: translation filed
    PLBI Opposition filed

    Free format text: ORIGINAL CODE: 0009260

    PLAX Notice of opposition and request to file observation + time limit sent

    Free format text: ORIGINAL CODE: EPIDOSNOBS2

    26 Opposition filed

    Opponent name: OTIS ELEVATOR COMPANY

    Effective date: 20060517

    NLR1 Nl: opposition has been filed with the epo

    Opponent name: OTIS ELEVATOR COMPANY

    PLAF Information modified related to communication of a notice of opposition and request to file observations + time limit

    Free format text: ORIGINAL CODE: EPIDOSCOBS2

    PLBB Reply of patent proprietor to notice(s) of opposition received

    Free format text: ORIGINAL CODE: EPIDOSNOBS3

    PLAB Opposition data, opponent's data or that of the opponent's representative modified

    Free format text: ORIGINAL CODE: 0009299OPPO

    R26 Opposition filed (corrected)

    Opponent name: OTIS ELEVATOR COMPANY

    Effective date: 20060517

    NLR1 Nl: opposition has been filed with the epo

    Opponent name: OTIS ELEVATOR COMPANY

    PLAB Opposition data, opponent's data or that of the opponent's representative modified

    Free format text: ORIGINAL CODE: 0009299OPPO

    PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

    Ref country code: CY

    Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

    Effective date: 20050817

    PGFP Annual fee paid to national office [announced via postgrant information from national office to epo]

    Ref country code: IE

    Payment date: 20110328

    Year of fee payment: 11

    Ref country code: DK

    Payment date: 20110315

    Year of fee payment: 11

    Ref country code: MC

    Payment date: 20110314

    Year of fee payment: 11

    PGFP Annual fee paid to national office [announced via postgrant information from national office to epo]

    Ref country code: FR

    Payment date: 20110404

    Year of fee payment: 11

    Ref country code: NL

    Payment date: 20110316

    Year of fee payment: 11

    Ref country code: SE

    Payment date: 20110314

    Year of fee payment: 11

    Ref country code: AT

    Payment date: 20110314

    Year of fee payment: 11

    Ref country code: FI

    Payment date: 20110314

    Year of fee payment: 11

    Ref country code: TR

    Payment date: 20110304

    Year of fee payment: 11

    PGFP Annual fee paid to national office [announced via postgrant information from national office to epo]

    Ref country code: GB

    Payment date: 20110321

    Year of fee payment: 11

    Ref country code: CH

    Payment date: 20110610

    Year of fee payment: 11

    Ref country code: DE

    Payment date: 20110325

    Year of fee payment: 11

    Ref country code: BE

    Payment date: 20110311

    Year of fee payment: 11

    Ref country code: ES

    Payment date: 20110325

    Year of fee payment: 11

    PGFP Annual fee paid to national office [announced via postgrant information from national office to epo]

    Ref country code: IT

    Payment date: 20110328

    Year of fee payment: 11

    REG Reference to a national code

    Ref country code: DE

    Ref legal event code: R103

    Ref document number: 50107119

    Country of ref document: DE

    Ref country code: DE

    Ref legal event code: R064

    Ref document number: 50107119

    Country of ref document: DE

    RDAF Communication despatched that patent is revoked

    Free format text: ORIGINAL CODE: EPIDOSNREV1

    RDAG Patent revoked

    Free format text: ORIGINAL CODE: 0009271

    STAA Information on the status of an ep patent application or granted ep patent

    Free format text: STATUS: PATENT REVOKED

    REG Reference to a national code

    Ref country code: CH

    Ref legal event code: PL

    27W Patent revoked

    Effective date: 20111213

    GBPR Gb: patent revoked under art. 102 of the ep convention designating the uk as contracting state

    Effective date: 20111213

    PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

    Ref country code: LI

    Free format text: LAPSE BECAUSE OF THE APPLICANT RENOUNCES

    Effective date: 20050817

    Ref country code: CH

    Free format text: LAPSE BECAUSE OF THE APPLICANT RENOUNCES

    Effective date: 20050817

    REG Reference to a national code

    Ref country code: DE

    Ref legal event code: R107

    Ref document number: 50107119

    Country of ref document: DE

    Effective date: 20121108

    REG Reference to a national code

    Ref country code: SE

    Ref legal event code: ECNC

    REG Reference to a national code

    Ref country code: AT

    Ref legal event code: MA03

    Ref document number: 302158

    Country of ref document: AT

    Kind code of ref document: T

    Effective date: 20111213

    REG Reference to a national code

    Ref country code: SE

    Ref legal event code: ECNC

    REG Reference to a national code

    Ref country code: DE

    Ref legal event code: R096

    Ref document number: 50107119

    Country of ref document: DE