Deep dive ⑦ · Make it fly
The digital thread ends in code that runs on the aircraft. The QX-250's software is a PX4 + companion-computer stack where the RFLP functions each get a home, the reliability requirements become running code, not a note in a report, and a simulation-first path lets the vehicle fly — and survive injected faults — before any hardware.
The core decision
A UAV needs software, but the hard, safety-critical part — the 400 Hz attitude loop, sensor fusion, motor mixing, failsafes — is a solved problem. The QX-250 builds on PX4 and spends its effort on the layer that is actually unique to this aircraft: mission behaviour and redundancy management. Three layers, and only the top one is really yours to write.
Mission logic, the redundancy supervisor, payload/telemetry. Runs on a Linux SBC (Jetson / Pi), talks to the flight controller over MAVLink. Python + MAVSDK now, ROS 2 later.
PX4 on a Pixhawk-class board: EKF2 fusion, attitude/rate loops, motor mixer, failsafe state machine. You configure it and add at most one control module — you don't rewrite it.
The logical blocks: 4× motor+ESC, dual battery, ELRS RX, VTX, LED/buzzer. The physical "P" and the "L" of the RFLP model.
Rule of thumb. If code must hit a hard real-time deadline it lives in PX4 and you touch it as little as possible. If it's a decision — what to do, when, how to react to a failure — it lives on the companion computer where it's easy to write, test and change.
The allocation
This is the point of the thread: the nine Functionality items in Teamcenter each map to a place in software, so the chain runs requirement → function → logical block → software component → test. The striking result — about six of the nine leaf functions are satisfied by configuring PX4 (you write parameters and tests, not control code). The genuinely custom software is small and high-value.
Generate/Deliver Thrust (mixer + DShot), Stabilize & Control (F7 — EKF2 + rate loops), Navigate / Hold Position, Communicate / Command Link (MAVLink + ELRS), Manage Power, Situational Signaling (LED/buzzer). Configuration + test, not new code.
Mission / autonomy logic on the companion computer, and the derived Manage Redundancy function — the supervisor that makes REL-008 / REL-009 real. Optionally one generated PX4 module for a model-based F7 control law.
The star component
The MADe fault-tree drove three requirements a diagram can't satisfy — only code can. REL-003 loss-of-thrust budget → REL-008 dual battery → REL-009 redundant flight control. The dual battery and dual FC are logical blocks; the switching decision is software — and it's the most safety-relevant code on the aircraft.
PX4 reads both packs (dual battery_status). The companion power monitor watches BT1 + BT2; on a pack fault it confirms the healthy pack carries load and re-runs the endurance estimate. Failsafe thresholds are versioned PX4 parameters.
Dual autopilots: one active, one hot standby. A redundancy supervisor monitors heartbeat and estimator health of the active FC and executes failover on loss. That failover logic, its detection threshold and its timing are REL-009 — and are exactly what you fault-inject in SITL.
Why "do I need software?" is a hard yes. The redundancy requirements are unfulfillable as hardware alone. Two batteries and two flight controllers are parts; deciding when to switch is code. That makes the redundancy supervisor the single most defensible piece of the whole program.
Fly it in simulation first
The vehicle flies in Gazebo SITL before any hardware. Every step is free and repeatable, and the redundancy demonstration produces a timestamped evidence artifact — a real test result, not an assertion.
PX4 SITL + a MAVSDK script: takeoff, waypoint, return, land.
Airframe config from the Amesim 6-DOF + NX mass numbers.
Inject a battery / FC fault; the supervisor reacts and logs it.
The Phase-3 harness injects real PX4 failures (MAV_CMD_INJECT_FAILURE), watches the supervisor react, and measures inject → reaction latency — the number to hold against the REL-003 timing budget. A sample evidence line:
[ 15.312s] INJECT SENSOR_GPS OFF (active-FC estimator degraded — REL-009 proxy)
[ 15.984s] REACT REL-009 proxy tripped → commanding RTL
[ 15.984s] DETECTION LATENCY: 672 ms (inject → supervisor reaction)
A dynamics finding the software has to answer
The Amesim 6-DOF study measured this airframe's attitude as lightly damped — released from 15° of roll it first crosses zero at ~0.86 s then rings down (ζ ≈ 0.15). That is a direct input to the software layer: the QX-250 wants more attitude-rate damping, so the PX4 gains ship with that caution baked in and first flight ends with a commander autotune pass cross-checked against the Amesim step response. Physics of the plant, informing the tune of the controller — the loop the digital thread is meant to close.
Lifecycle
Not needed for first flight. Polarion is the software-side counterpart to Teamcenter: it owns software requirements, test cases and the requirement→code→test coverage matrix. It earns its place at the software-qualification gate, where REL-009 can be traced from the MADe fault-tree number all the way to a passing SITL fault-injection test. Before that, a Git repo and a requirements sheet are faster. Stand it up when there are real software requirements to trace and coverage to prove — then back-link it to the 56 requirements already in Teamcenter.
System + hardware requirements, functions, BOM. Already built — 56 requirements, 42 derive links.
Software requirements, work items, test cases, coverage matrix. Introduced at the qualification gate.
Fault-injection logs + PX4 .ulog become the test results the coverage matrix points at.
Where this flows from — and to. The functions and redundancy come straight from the RFLP model and the MADe reliability decision; the control tune answers the Amesim 6-DOF dynamics; and the software-qualification evidence is what a Polarion ALM layer will eventually manage. The thread runs from failure physics all the way to code on the aircraft.