← BACK

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
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
Second Iteration. Simplified: PLC orchestrates, Carousel owns motion & sensors, Door enforces interlocks.
  • 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
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.