Practice Project for Systems Engineering - Part 0

A Prelude to the Mini-Series

The pages that follow are not a build log, at least not yet. They are, first and foremost, a structured exercise in applied systems engineering. Fresh from an intensive AIAA course on space-grade SE practice, I wanted a sandbox that was small enough to tackle after work yet rich enough to showcase every rung of the "V" model.

A 1/14-scale WLtoys buggy, a $10 ESP32 module, and the perennial headaches of RC racing (run-away cars, video lag) fit that bill perfectly.

V-model illustrating decomposition on the left and verification on the right
The V-model that underpins this system methodology. (Public-domain image, U.S. Government source via Wikimedia Commons.)


What the V-model actually shows

The V-model is a visual shorthand for disciplined, top-down system development followed by bottom-up proof. On the left-hand leg you start with fuzzy stakeholder pains, sharpen them into measurable system requirements, and then decompose those requirements through progressively finer architectural layers until you reach code or hardware drawings.

The bottom point (unit implementation) is where abstraction is lowest and component isolation is highest. The right-hand leg then climbs back upward, but in reverse order: unit tests prove each block, component integration proves every interface, and finally system‐level validation proves that the finished artefact solves the original pain.

Two principles make the diagram more than just a pretty shape:

  1. Bidirectional traceability - every artefact on the left must have a matching verification artefact on the right.
  2. Early test planning - you design test hooks at the same time you design functions, not as an after-thought.

Because of those principles, teams can localise defects, predict schedules, and justify design trade-offs with cold data instead of hope.

Part 1 captures the left-hand descent of the V-model. It frames the stakeholder pains, distils them into SMART requirements, and surveys the trade space, always with a kitchen-table verification plan in view. If you are new to SE, think of Part 1 as the theory section: why clarity of need, aggressive measurability, and early test hooks save months of rework down the line.

Part 2 pivots to design: a tri-view architecture (functional, physical, software) that shows, line-by-line, how each requirement is realised and how every design choice earns its keep. You will see control loops mapped to tasks, latency budgets split across hops, and even a "budget" analogue FPV link added when risk analysis exposed Wi-Fi's soft underbelly. In short, Part 2 is the climb up the right-hand side of the V, still on paper but already instrumented for proof.

Will there be a Part 3 with hardware photos and skid-marks on the parking lot? Not soon, I make no promise. Another project already competes for bench time. For now, treat this series as a reference walk-through.

© 2025 Victor Retamal - Project Notes.

Goodreads Twitter LinkedIn GitHub