Design Elevator System

1. Requirements & Assumptions

Functional Requirements

• The elevator system manages multiple elevator cars across a building with $N$ floors.
• Supports two types of request panels:
  • Internal Panel (Inside car): Allows passengers to select target destination floors.
  • External Panel (On floors): Allows passengers to request an elevator going Up or Down.
• Elevators maintain states: Moving Up, Moving Down, Idle, DoorOpen.
• The controller routes requests to elevator cars using a dispatch algorithm (e.g., SCAN/LOOK algorithm).
• Supports safety overrides like emergency stop and door obstruction detection.

Non-Functional Requirements

• Throughput & Efficiency: The dispatch algorithm must minimize average passenger wait times and energy consumption.
• Concurrency: The system must handle concurrent floor button presses from different floors.

Assumptions

• All elevator cars have the same weight capacity limit.
• All floors can be accessed by all elevator cars.

2. Entities, Responsibilities & Relationships

• ElevatorController (Singleton): Manages requests, tracks elevator states, and routes passenger calls to the optimal car.
• ElevatorCar: Tracks its current floor, direction, and handles movement and door states.
• InternalButtonPanel / ExternalButtonPanel: Capture user inputs and route requests to the controller.
• Request: Models destination requests (origin floor, target floor, direction).
• Dispatcher (Strategy Pattern): Abstract interface for selecting the best elevator car for an external request.

3. Diagrams

UML Class Diagram

Sequence Diagram: Dispatching a Car

4. Design Decisions

• Dual request queues (LOOK algorithm): Each ElevatorCar maintains two sorted request queues (an upRequests min-heap and a downRequests max-heap). This allows the car to continue moving in its current direction until all requests in that direction are satisfied, preventing directional oscillation.
• Strategy Pattern for Dispatching: We decoupled the car selection logic into a Dispatcher interface, allowing us to swap the dispatch algorithm (e.g. from LOOK to Zone Dispatching) easily.

5. Step-by-Step Implementation

1. Define enums for Direction (UP, DOWN, IDLE) and DoorState (OPEN, CLOSED).
2. Implement ElevatorCar with separate queues for UP and DOWN directions.
3. Create the Dispatcher interface.
4. Implement LookDispatcher to select the closest car moving in the requested direction.
5. Implement ElevatorController to manage the cars and coordinate requests.

6. Complete Code

7. Test Cases & Verification

• Test Case 1: Standard Dispatch: Request an elevator going UP at floor 3. Verify that the closest idle car is selected and starts moving up.
• Test Case 2: Multi-floor Stopping: Request floor stops at 3, 5, and 7 while the car is moving up. Verify that the car stops at each floor sequentially, opening its doors, and continues moving up.

8. Scalability & SOLID Improvements

• SOLID - Open/Closed Principle: The Dispatcher strategy allows us to change dispatch algorithms (e.g. from Closest Car to Zone-based Dispatching) without modifying the ElevatorController or ElevatorCar classes.
• Thread-Safe Car Queues: Using synchronized methods or mutexes within ElevatorCar ensures that concurrent requests from the internal panel and external floor panels do not corrupt the request queues.

9. Production Considerations

• Real-Time Hardware Interfacing: The step() loop should be tied to physical motor sensors. Using an event-driven framework (like RxJava or native event loops) allows the controller to listen to floor arrival interrupts.
• Weight Load Sensors: Elevator cars have weight limit sensors. If a car detects it is full, it should tell the controller to bypass external floor calls and route directly to its internal destinations, preventing passenger overload.

10. Next Lesson Preview

In the next case study, we will design a Ticket Booking System (like BookMyShow). We will study screen layouts, show timings, and concurrency locks to prevent double-booking of seats!