Deep Dive — Mock Carousel Simulation API

The Challenge

Testing real automated parking carousels was costly and risky.
The old “simulator” skipped sensors and fault states → gave false confidence.
Needed something that captured hundreds of interconnected states.

My Approach (Iteration 1)

I started by treating the carousel as a living state machine, mapping every signal: inverter trips, drive status, pallet occupancy, door sensors. JSON dumps became my blueprint.

First iteration UML: detailed class model with PLC, sensors, doors, pallets, and JSON mapping — **First Iteration.** Exhaustive model that mirrored JSON structure one-to-one.

Modeled every component: PLC, sensors, pallets, doors, status objects.
Powerful, but too heavy — changes meant plumbing through layers.
Simulator reflected API fields more than real machine behavior.

The Refactor (Iteration 2)

After a few days, I stepped back and asked: what are the verbs and invariants?

Rotate to bay N.
Open door only if safe.
Reserve a pallet.
Fail closed on alarm.

Second iteration UML: simplified with PLC, Carousel, Door, Pallets — **Second Iteration.** Simplified: PLC orchestrates, Carousel owns motion & sensors, Door enforces interlocks, Pallets form a list.

Collapsed classes, tightened responsibilities.
Commands drove explicit state transitions → clearer, safer.
Edge cases became scenarios: inverter trip mid-rotation, door sensor mismatch, simultaneous entries.
Deterministic logs allowed easy replay and debugging.

The Reality We Simulated

Real automated parking carousel system — **The Target Reality.** Full-scale parking carousel — the system my simulation had to mirror safely in software.

Impact

Simulation “felt real” — trusted enough to run in CI pipelines.
Cycle times dropped dramatically.
New features prototyped without touching hardware.
Foundation for scaling to tandem carousels, gates, and future variations.