Why elevator design tests state machines in LLD - Why This Architecture

Problem Statement

Elevator systems often fail when unexpected sequences of button presses or sensor inputs cause the elevator to behave erratically or get stuck. Without a clear model of states and transitions, it is hard to predict or test all possible behaviors, leading to safety risks and poor user experience.

Solution

Modeling the elevator as a state machine breaks down its behavior into clear states (like moving up, moving down, idle, door open) and defines allowed transitions triggered by events (like button press or arrival at a floor). Testing this state machine ensures all transitions work correctly and unexpected states are avoided.

Architecture

Idle

→Moving Up

↓

Door Open

This diagram shows the elevator states and how button presses or floor arrivals cause transitions between Idle, Moving Up, Moving Down, and Door Open states.

Trade-offs

✓ Pros

→

Provides a clear, testable model of elevator behavior.

→

Helps catch edge cases and invalid transitions early.

→

Improves safety by preventing undefined states.

→

Simplifies debugging by tracing state transitions.

✗ Cons

→

Requires upfront design effort to define all states and transitions.

→

Can become complex if too many states or events exist.

→

May need updates if elevator features change.

Use when designing any system with distinct modes and event-driven transitions, especially for safety-critical or user-interactive systems like elevators.

Avoid if the system is extremely simple with no complex state changes or if the overhead of modeling states outweighs benefits, such as a single-button device with no modes.

Real World Examples

Otis Elevator Company

Uses state machines to model elevator control logic ensuring safe door operations and movement sequencing.

Thyssenkrupp

Implements state machine testing in their elevator software to handle complex scenarios like emergency stops and priority overrides.

Schindler Group

Employs state machine models to simulate and verify elevator behavior before deployment to reduce field failures.

Code Example

The before code uses simple flags and conditions without clear states, which can lead to inconsistent behavior. The after code defines explicit states and transitions, making the elevator's behavior predictable and easier to test.

LLD

### Before: No state machine, simple conditional logic
class Elevator:
    def __init__(self):
        self.floor = 0
        self.moving = False
        self.direction = None

    def press_button(self, target_floor):
        if target_floor > self.floor:
            self.direction = 'up'
            self.moving = True
        elif target_floor < self.floor:
            self.direction = 'down'
            self.moving = True
        else:
            self.moving = False

    def arrive_floor(self, floor):
        self.floor = floor
        self.moving = False
        self.direction = None


### After: Using state machine
from enum import Enum, auto

class State(Enum):
    IDLE = auto()
    MOVING_UP = auto()
    MOVING_DOWN = auto()
    DOOR_OPEN = auto()

class Elevator:
    def __init__(self):
        self.state = State.IDLE
        self.floor = 0

    def press_button(self, target_floor):
        if self.state == State.IDLE:
            if target_floor > self.floor:
                self.state = State.MOVING_UP
            elif target_floor < self.floor:
                self.state = State.MOVING_DOWN

    def arrive_floor(self, floor):
        self.floor = floor
        if self.state in (State.MOVING_UP, State.MOVING_DOWN):
            self.state = State.DOOR_OPEN

    def close_door(self):
        if self.state == State.DOOR_OPEN:
            self.state = State.IDLE

Alternatives

Event-driven programming without explicit state machines

Handles events directly without modeling states explicitly, relying on conditional logic.

Use when: Choose when system states are simple and event handling logic is straightforward without complex transitions.

Rule-based systems

Uses rules to trigger actions based on conditions rather than explicit states and transitions.

Use when: Choose when behavior depends on many independent conditions rather than sequential states.

Summary

Elevator failures often come from unclear or untested sequences of states and events.

Modeling elevators as state machines clarifies behavior and enables thorough testing of all transitions.

State machines improve safety, predictability, and maintainability of elevator control software.

Practice

1. Why is elevator design often used to test state machines in system design?

easy

A. Because elevators have clear states and transitions that model real-world behavior

B. Because elevators require complex database management

C. Because elevators use machine learning algorithms

D. Because elevators operate without any state changes

Solution

1. Step 1: Understand elevator operation basics

   Elevators move between floors and have states like moving up, moving down, idle, door open, and door closed.

2. Step 2: Connect elevator states to state machine concept

   State machines model systems with defined states and transitions, matching elevator behavior perfectly.

3. Final Answer:

   Because elevators have clear states and transitions that model real-world behavior -> Option A

4. Quick Check:

   Elevator states = clear states and transitions [OK]

Hint: Elevators have clear states and transitions [OK]

Common Mistakes:

• Thinking elevators don't have states
• Confusing state machines with databases
• Assuming elevators use AI for basic movement

2. Which of the following correctly represents a state transition in an elevator state machine?

easy

A. Idle -> Door Open -> Moving Up

B. Idle -> Moving Up -> Door Open

C. Door Open -> Moving Down -> Door Closed

D. Moving Up -> Door Closed -> Idle

Solution

1. Step 1: Identify valid elevator state order

   An elevator usually goes from Idle to Moving Up, then Door Open when it reaches the floor.

2. Step 2: Check each option's sequence

   Idle -> Moving Up -> Door Open correctly shows Idle -> Moving Up -> Door Open, a valid transition sequence.

3. Final Answer:

   <code>Idle -> Moving Up -> Door Open</code> -> Option B

4. Quick Check:

   Idle to Moving Up to Door Open = valid transition [OK]

Hint: Elevator moves before doors open [OK]

Common Mistakes:

• Opening doors before moving
• Closing doors while idle
• Skipping moving state

3. Given this simplified elevator state machine code snippet, what is the final state after these events: callElevator(), arriveFloor(), openDoor()?

states = ['Idle', 'Moving', 'DoorOpen']
current_state = 'Idle'

def callElevator():
    global current_state
    if current_state == 'Idle':
        current_state = 'Moving'

def arriveFloor():
    global current_state
    if current_state == 'Moving':
        current_state = 'DoorOpen'

def openDoor():
    global current_state
    if current_state == 'DoorOpen':
        current_state = 'Idle'

medium

A. Idle

B. Moving

C. DoorOpen

D. Error

Solution

1. Step 1: Trace callElevator()

   Starting at 'Idle', callElevator() changes state to 'Moving'.

2. Step 2: Trace arriveFloor() and openDoor()

   arriveFloor() changes 'Moving' to 'DoorOpen', then openDoor() changes 'DoorOpen' back to 'Idle'.

3. Final Answer:

   Idle -> Option A

4. Quick Check:

   Idle after all events = Idle [OK]

Hint: Follow state changes step-by-step [OK]

Common Mistakes:

• Skipping openDoor() effect
• Assuming state stays at DoorOpen
• Confusing event order

4. In this elevator state machine code, what is the bug causing the elevator to never open doors?

current_state = 'Idle'

def callElevator():
    global current_state
    if current_state == 'Idle':
        current_state = 'Moving'

def arriveFloor():
    global current_state
    if current_state == 'Moving':
        current_state = 'Idle'  # Bug here

def openDoor():
    global current_state
    if current_state == 'DoorOpen':
        current_state = 'Idle'

medium

A. current_state is not initialized

B. callElevator() does not change state

C. openDoor() changes state incorrectly

D. arriveFloor() sets state to 'Idle' instead of 'DoorOpen'

Solution

1. Step 1: Analyze arriveFloor() function

   arriveFloor() changes 'Moving' state directly to 'Idle', skipping 'DoorOpen'.

2. Step 2: Understand effect on door opening

   Since state never becomes 'DoorOpen', openDoor() condition never triggers, so doors never open.

3. Final Answer:

   arriveFloor() sets state to 'Idle' instead of 'DoorOpen' -> Option D

4. Quick Check:

   arriveFloor() wrong state change = no door open [OK]

Hint: Check if all states are reachable in transitions [OK]

Common Mistakes:

• Ignoring wrong state assignment
• Assuming callElevator() is faulty
• Overlooking openDoor() condition

5. You are designing an elevator system with multiple elevators and floors. Why is modeling the system as a state machine important for safety and scalability?

hard

A. It eliminates the need for sensors and hardware checks

B. It allows elevators to learn user preferences automatically

C. It ensures predictable behavior and clear transitions, preventing unsafe states

D. It reduces the number of elevators needed by half

Solution

1. Step 1: Understand state machine benefits in complex systems

   State machines define clear states and transitions, making system behavior predictable and easier to manage.

2. Step 2: Connect predictability to safety and scalability

   Predictable transitions prevent unsafe states like doors opening while moving, and help scale by managing multiple elevators consistently.

3. Final Answer:

   It ensures predictable behavior and clear transitions, preventing unsafe states -> Option C

4. Quick Check:

   Predictable states = safety and scalability [OK]

Hint: Predictable states prevent unsafe elevator behavior [OK]

Common Mistakes:

• Confusing state machines with AI
• Ignoring safety in design
• Assuming hardware replaces software logic