# Modeling the elevator as a finite state machine

This is my first post here. Nice to meet you all!

I've read a related question here and am still having issues.

There is a building consisting of 7 storeys (indexed 0-6). Design a system that controls the elevator in this building.

Design details:

1. There are navigation buttons in each floor (up / down).

2. Inside the elevator there are buttons to select the destination. (For simplicity, can I assume that only one destination can be selected)

3. Seven segment displays indicate the position of the lift. These are present in each floor and inside the elevator.

4. There are LEDs to indicate the direction of movement of the elevator in each floor. (arrows, I presume?)

5. There are buttons inside the elevator to control the fan and lights. (Fans and lights are OFF by default . They turn on automatically if the lift is in motion).

What I've done so far :

System #1: Controlling the seven segment display

Let the elevator be in floor 'x'. For the destination selection (say y) from inside the elevator, we use an encoder to obtain the destination floor in binary. We then pass it on to the controller which compares x and y and decides the direction of movement. As it moves, keep updating x and send it to the seven segment displays in each floor and inside the elevator.

System #2: Fans and lights. Default state : OFF. If the destination is selected, turn ON. Switch ON/OFF as per the passenger's choice.

System #3: The movement control unit (This is where I'm having issues):

Since we are modelling the elevator as a finite state machine, I have the following states.

1. Rest: (RST)

2. Moving up (UP)

3. Moving down (DOWN)

The following changes cause state transitions:

1.The elevator is called from one of the floors.

2.The destination has been reached.

3.The destination has been selected.

Case #1: The destination has been selected (y). If y > x (current floor) then UP. else if y

Case #2: The elevator is moving from say, the 3rd floor to the 6th floor. Someone at the 4th floor wants to go down. At the 5th floor, someone wants to go up. The obvious solution, halt at floor 5. go to floor 6 and then go to the 4th floor.

Issue #1: How do I handle the priorities ?

Issue #2: How do I store the information ? (I'm aware of flip-flops and related memory elements. Not sure about the finer implementation details)

Issue #3: How do I encode the states and create the state transition table ? (I'm not able to visualize it.)

PS: Since the question was worded ambiguously, I think it is safe to make some assumptions to simplify the problem.

Help would be greatly appreciated. Thanks in advance.

EDIT 1: For the movement control unit, there are 19 inputs (1 each from floors 0 & 6, 2 each from floors 1-5, 7 from inside the elevator) and 1 output signal to the motor (UP, DOWN).

• This will be a whole lot simpler if you make the states of your FSM the position of the elevator, rather than its velocity. Add a flip-flop to keep track of the direction of the last movement. Commented Nov 14, 2015 at 13:53
• Thanks for your reply. I did think of that. This assignment requires me to draw a state diagram though. I'm not sure how I'd be able to draw the diagram which handles interrupts (halts at intermediate floors). Won't this scheme make the task humongous? Commented Nov 14, 2015 at 14:00
• No, not especially. With 7 floors, you basically need 12 states: From the bottommost and topmost floors, there is only one state each, because there's only one direction you can go from there. For each of the intermediate floors, there are two states, based on how you got there. When you're going down, you prioritize requests from floors below the current position over requests from above. When you're going up, you reverse the priorities. Commented Nov 14, 2015 at 14:06
• This may also be a use case for a hierarchical state machine, as in stackoverflow.com/questions/32612604/substatemachine/… One approach would be to make the current floor the main state, and the current direction (Up, Down, None, door handling) the inner state (You need to be able to stay where you are!). To reduce code duplication I'd handle the inner state in a procedure (possibly a different procedure for the top and bottom floors).
– user16324
Commented Nov 14, 2015 at 14:13
• @DaveTweed, Got that. The thing is, I'm not sure how to capture that information in the state diagram i.e. depicting the state transitions. Commented Nov 14, 2015 at 14:17

Obviously there are many many ways to design this, here is one possible approach.

For any design, the signals are no less critical than the control logic in the design process. For example, there are opposite suggestions of assigning states to represent the position (which floor) of the elevator and of not assigning. My take is, there should be signals telling where the elevator is anyway, so might as well define the signals to indicate the position. It seems that should be the simpler and more robust way.

So now the elevator movement state machine would probably have at least the following state: idle, up, down, stop. The input signals would be at least the current position and current destination. The current position is the signal that is build into the elevator mechanism, as discussed in the previous paragraph. By saying that current destination is an (internal) input signal is yet another design choice -- to partition the control logic. For more realistic modeling, additional states of elevator movement, such as decelerating, accelerating, door opening ... , could be added here.

To generate the current destination (signal), it could be something comprehensive based on some kind of queuing mechanism. Or it could be a much simpler state machine driven by some priority choices with no queuing. The priority choice of keep going in one direction until there is no more pending request in that direction (as suggested by supercat) can be one of the key choice. In my mind, this machine would have 7 states, one for each possible destination floor, plus a few more. Among the inputs to this would be the request signals from the buttons.

The request signals for the buttons are probably going to be generated by simple state machines. 19 state machines for the 19 inputs as you mentioned in EDIT 1. The state machines for buttons inside elevator would be somewhat like: When Idle if button pressed go to Request; When Request if Stop && Current_position==Button_location goto Idle. The directional buttons on each floor would be slightly more complicated.

I would suggest that the elevator has 12 states which combine position and direction. An elevator should continue in its present direction if any destination or call buttons are pushed between its present location and the end of travel. It should reverse direction if no buttons are pushed between its present location and the end of travel, but some buttons are pushed elsewhere.

If e.g. the elevator was just delivered someone to the sixth floor from below, no seventh-floor buttons are pushed, but the "up" buttons are pushed on the third and fifth floors, the elevator should start down. It should not stop on the fifth floor because it's going down and that's an "up" button, but should continue past that floor because there's another button below. Once it reaches the third floor, there will no longer be any buttons between it and the end of travel, but there will be buttons pushed elsewhere, so it should reverse direction. At that point, it will be on the third floor heading up, so it should respond to the third-floor call.

• I'm planning on using a 2-bit register to store the request floor . Let's say the lift is moving from floor 1 to floor 5. If there's a UP request at floor 3, the lift will halt. The value of REQUEST in the register is overwritten. How does the lift then remember to go to floor 5? Or, Is there something I'm overlooking ? Commented Nov 14, 2015 at 15:01
• *3- bit register. Commented Nov 14, 2015 at 15:31
• @user37420: You should have three bits for each floor except the top and bottom, which have two. One bit for the in-elevator button, and one for each floor-call button. You could if desired eliminate the in-elevator button bits if pushing the buttons sets the appropriate call-button bits, but having extra bits for the buttons would make things simpler and allow lights to work more intuitively. Commented Nov 14, 2015 at 15:55
• Sorry to bother you, but I still don't understand why this solves the problem of storing a list of requests. Commented Nov 14, 2015 at 16:36
• @user37420: One doesn't need a list of requests; instead, for each button one keeps a bit saying "is there a request pending for this button". For each floor, it's easy to compute a function "Are any buttons pending on or above this floor" [or together the "on or above" from the floor above with the buttons on the current floor] and likewise for "Are any buttons pending on or below this floor". There's no need to keep track of the sequence in which buttons are requested, and with one elevator prioritization is simple. Go up until there's nothing to do further up, then down until there's... Commented Nov 14, 2015 at 17:54