Description
Introduction:
Sources within UBC have recently put out to contract, the design and installation of a ten-storey duplex Elevator system for a new high technology science block that it is intending to build in June 2021.
However, following recent complaints about the inefficiency of other elevator systems within the University it has been unanimously decided that each of the companies putting forward a proposal for their new elevator system, should first supply a simulation model which accurately reflects the algorithms used by each company to dispatch elevators to deal with passenger requests. The various simulation models are to be judged by an independent expert, to arrive at the most effective design.
For the purposes of this assignment, you are an employee of one of the companies involved in demonstrating your design, the dubiously named ‘Freefall’ Elevator Company of Toronto. You have been asked by your manager to design a simulation model of such a duplex elevator incorporating the dispatcher algorithm used in your real elevator, so that it can be presented for evaluation. As is typical in such circumstances, only a brief specification of the model is available, so you will have to use some imagination in implementing it. The following description of the model is available.
Model Specification: Part A (worth 80%)
(1) A double elevator system, responding to requests made either from within the elevator, or from requests made outside the elevator for transportation of passengers both up/down and to the specified/destination floors. Fault simulation must be implemented, with particular attention then being placed on the effective use of the other elevators.
(2) The simulation model should at all times, inform the person running the simulation of its actions, so that an effective comparison can be made. The simulation output is to take place via the computer display window and should show the following information relating to each elevator: Direction (up/down), General Status (in/out of service etc), Door Status (open/closed) and Current Floor Number.
(3) The time taken to travel between floors, open and close doors etc. should be reasonably accurately modelled, but scaled down to run faster (but not too fast) as this is a simulation.
(4) The elevator and its floor numbers should be shown graphically on the display screen, using two animated vertical columns, showing the position and status of both elevators as they move between floors.
(5) All simulation inputs are to be entered via the computer keyboard, and the following key codes have been negotiated by all parties concerned
Requesting Transport once inside the elevator:
Requesting elevator movement from INSIDE the elevator involves entering a two character keyboard sequence. It should NOT be necessary to press the return key at any point in the simulation. Investigate functions like getch() in Visual C++ to help with this.
The first character can be a ‘1’, or ‘2’, to designate a command directed to elevator 1 or 2 respectively, followed by a second character in the range ‘0-9’ to indicate which floor the elevator is being directed to travel to. This simulates a passenger pressing one of the 10 floor destination buttons located inside the elevator. Therefore a passenger stepping into elevator 1 and wishing to travel to floor 3 would be simulated by entering the characters ‘1’ then ‘3’.
Requesting an elevator while stood outside on a given floor:
A passenger requesting to go UP or DOWN whilst stood OUTSIDE the elevator on a given floor will be simulated by entering two character commands such as ‘u0’,’u8’ and ‘d1’,’d9’, where the letters ‘u’ and ‘d’ refer to a request by the passenger to go UP or DOWN respectively. The subsequent single digit number tells the simulation which floor the request is being made from, not which floor the person wishes to be subsequently transported to. Obviously the passenger cannot direct an UP or DOWN request to a specific elevator, that decision will be left to your dispatcher algorithm which should attempt to send the elevator that is most likely to pick up the passenger in the shortest time, perhaps when passing that floor on its way to somewhere else. Once inside the elevator, the passenger may then direct the elevator to a specific floor by entering a INSIDE command such as ‘12’ etc.
Simulating Elevator Faults and Halting the System:
Faults are to be generated by pressing +1 or -1, +2 or -2. The minus sign ‘–’ informs the simulator that a fault has occurred with that numbered elevator and that it is effectively out of action. The plus sign ‘+’ indicates that the fault has been cleared and operation can resume with that elevator. Each elevator should freeze its actions immediately upon receipt of a simulated fault condition, and should ignore subsequent commands except a command to end the simulation, or clear the fault.
There is NO need to transfer outstanding floor requests for an elevator to another one when a fault develops with it. Similarly, when the fault is cleared, the elevator should wait for new commands and NOT try to service any pending requests it had before the fault developed.
The simulation may be terminated at any time by entering the two character sequence ‘ee’. All elevators are then to return to the ground floor, open their doors and stop. No further commands should be accepted during this time and the simulation will then stop.
The Architecture:
Your Instructor will give you the final architecture for this assignment (Part A). It is this model which you MUST attempt to implement. Any other model is invalid and will NOT be marked. The reason for this strict rule is that variations of this model are given out to CPEN 333 students from time to time and each is different to others.
The programs are to be written in C++, to run under the Win32 Operating system and should be demonstrated working on the systems currently in the lab (or your own laptop).
As with all real-time, safety critical systems, marks will be awarded for completeness, reliability and fault-tolerance. You will also be marked on the quality of your elevator dispatch algorithm. A better algorithm will attract more marks. Better in this sense means an algorithm that makes the most efficient use of the elevators, i.e. how long does your algorithm keep a passenger waiting, does your algorithm send the closest elevator etc.
You will be asked to demonstrate your elevator software to your Instructor/TA, it will be assumed during this demonstration that the elevator is real, and has been installed, ready for public use.
Any faults in the software such as a sending an elevator to the 23rd floor, failing to open the doors when arriving at a floor, or even forgetting to stop at a floor, will be marked down. This emphasises the need to get it right, and the problems in drawing up a complete specification for the problem. It also highlights the difficulties involved in completely testing an asynchronous real-time system.
Additional marks will be awarded for what the assessor considers to be bells and whistles features, such as the clever use of say colour graphics (see online notes on cursor control under Win32 and colour in the rt.h/rt.cpp files), clever dispatcher algorithm, or any other innovative feature you can come up with that are relevant to the elevator simulation, such as more than 2 elevators. Some bells and whistles features will obviously attract more marks than others, colour for example is not too difficult, while clever algorithms to deal with more than 2 elevators are more interesting and worth more marks.
For those of you not too confident with your C++ programming ability, you might want to start of by implementing a very simple dispatcher algorithm, for example, all up requests entered at the simulation could be sent to elevator 1, down requests to elevator 2 etc. Of course this is not very efficient, but it will allow you to demonstrate a working elevator which is critical to the demonstration phase of the assignment. If you have nothing to show, it’s very difficult to award it a fair mark. If you get this simple elevator dispatching algorithm to work and you have time, you could always modify it to make a better one (which would hopefully get more marks), but make sure you save the old working version. You would not believe now many students change something critical 10 mins before the demo and end up with something that does not work and no fall back situation!!!!
The same goes for backing up your work. YOU are responsible for this, please do not come to the day of the demo and tell me your laptop has crashed and you have lost all your work. You have an obligation to safeguard your work. I’ll say no more.
Part B (Worth 20%) – Adding Dynamic Passengers
You should also see an architecture for Part B from your instructor. This one allows for the dynamic creation of passengers as active objects. They are created at random with objectives in mind, e.g. they are designed to stand outside the elevator on say floor 2 and make an UP request, before travelling to say floor 5 and getting off (these are just example, you can play around with floor numbers and up/down requests at run time using some random number generator).
To enable this feature, you should press the character sequence “d+” and to end it the sequence “d-“. You can still enter new requests at the keyboard etc as in Part A
