A reduced-order VTOL model originally implemented as a Simulink demonstration was ported to the modern HJ reachability toolchain (helperOC on top of the level-set library) to compute backward reachable sets for transition-mode safety analysis. The deliverable is a recipe for taking a legacy Simulink stability study and turning it into a state-space envelope statement: "for any initial state in this set, no admissible disturbance can drive the vehicle outside the operating envelope inside the prediction horizon."
A planar longitudinal VTOL with state x = (u, w, q, θ) (forward and vertical body velocities, pitch rate, pitch angle) and input u_c = (T, δ_e) (thrust, elevator). The transition-mode dynamics linearise locally around a hover-to-cruise schedule:
ẋ = A(α) x + B(α) u_c + D d
α ∈ [α_hover, α_cruise]
d ∈ W
u_c ∈ U
α follows the hover-to-cruise transition schedule, d is a bounded gust disturbance, u_c respects thrust and elevator limits. Operating envelope: O = { x : φ_min ≤ θ ≤ φ_max, u ≥ u_min } (avoid stall at low forward speed and avoid pitch-up beyond stability margin).
Compute the set of initial states from which the controller can keep the VTOL inside O for the full prediction horizon, against the worst-case admissible disturbance. The HJI value function:
∂V/∂t + min_{u_c ∈ U} max_{d ∈ W} ⟨f(x, u_c, d), ∇V⟩ = 0
V(x, T) = L(x)
L(x) is the signed distance to the envelope boundary ∂O.
The zero-superlevel set { x : V(x, 0) ≥ 0 } is the safe BRS: any state in it admits a control schedule that keeps x(t) ∈ O for all t ∈ [0, T], regardless of the gust profile in W. helperOC handles the min-max Hamiltonian directly; the Simulink-only legacy version could only check stability locally, not envelope-wide.
Closed-loop transition between hover and forward flight under HJR-derived envelope constraints. The first clip is a baseline trajectory inside the BRS; the second crosses the BRS boundary at a heavily disturbed initial condition and triggers the safety override.
Baseline transition (x(0) ∈ BRS)
Disturbed transition · safety override active
The legacy Simulink workflow could verify a single nominal trajectory was stable. The HJR port answers a strictly stronger question: which set of initial conditions admit any safe trajectory under any admissible disturbance? That is the difference between "this controller doesn't fall over on the demo" and "this controller has a certified envelope of operation," which is the language that flight-test engineers use when they write release-to-flight cases.