M8-T18: Deployment and operational limitations

Learning objectives

After this lesson, you should be able to:

• Derive operating limits from verification results, including margins.
• State limitations in a form usable by operators: conditions, values, rationale and the consequence of exceeding them.
• Monitor limit conditions in operation and respond when they are approached.
• Extend the envelope through new evidence rather than by argument.

Conceptual explanation

Established The idea that operation is limited to a verified envelope is basic safety-engineering practice. Regulatory approvals and operating categories for UAVs depend on the jurisdiction; this lesson addresses the engineering side and does not replace regulatory compliance.

For a GNSS-denied navigation system the dimensions of the envelope usually include:

Each limit comes with a rationale (evidence reference), a monitoring method (how the operator or the system knows the condition holds: a checklist, a sensor reading, a geofence), and a consequence of exceeding it (abort, hold, land, or waiver required).

Engineering intuition

The limitations list is the system’s resume stated honestly: what it can do, under which conditions, and on whose evidence. Flights beyond it are experiments, to be treated as test flights with test cards. A good limitation is specific (“wind ≤ 8 m/s measured at 10 m, 10-minute mean”) and testable by the operator in the field, not vague (“moderate wind”).

Extension of the envelope is an engineering activity with a cost. Want to fly at 6 m/s instead of 4? That is a new test point (build-up, FMEA review, a new verification set, acceptance), not a decision made on the spot. The limitation document makes the gap visible, which is why it is useful to management as well as to operators.

Mathematical formulation

Given the verified conditions, a limit is the verified extreme backed off by a margin that reflects the uncertainty and the consequence. For a quantity with the highest verified value $v_{\text{ver}}$ and a limit set at $v_{\text{lim}}=v_{\text{ver}}(1-m)$ (for example $m=0.2$), the margin is explicit. For the speed limit the stopping-distance constraint gives an independent bound from the clear distance $d_{\text{clear}}$ (see the flight test lesson):

Combinations of conditions are riskier than any single one: tested at 4 m/s in daylight and at 2 m/s in dim light does not verify 4 m/s in dim light. Treat the verified envelope as a union of tested cells in the space of conditions, not as a box around their extremes: the point is inside the envelope only if a passing test covered a cell that contains it (or a neighbouring one with a sound argument for extrapolation). The fraction of the intended operating space covered is a useful metric: covered cells divided by total cells.

$v_{\text{ver}}$

highest verified value of the quantity.

$m$

margin fraction.

$v_{\text{stop}}$

speed limit from the stopping-distance constraint.

$d_{\text{clear}}$

available clear distance.

Architecture and data flow

Verification results (cells of tested conditions with verdicts, from the acceptance evaluation) → envelope builder → limits table with rationale and monitoring method → operations manual and pre-flight checklist → pre-flight go/no-go (conditions measured: wind, light, site, battery, configuration manifest) → in-flight monitors (geofence, speed limit, VO health, battery) → post-flight record of conditions flown, which feeds the envelope coverage. Requests to extend limits trigger a test plan.

Real-world UAV applications

• Briefing operators for a GNSS-denied inspection campaign.
• Writing the limitations section of a delivery report.
• Deciding which tests to run to extend the envelope.
• Setting automated limits (speed, geofence) from the envelope.

Implementation example

This runs as shown. An envelope builder: verification cells in a space of conditions (speed, lighting, scene type) with verdicts; a go/no-go function that allows a flight only if the planned conditions fall in a passing cell (with margin on speed), and a coverage metric. Values are illustrative.

import itertools
speeds = [2.0, 4.0, 6.0]; lights = ['bright', 'dim']; scenes = ['textured', 'sparse']
verdict = {(2.0, 'bright', 'textured'): 'pass', (4.0, 'bright', 'textured'): 'pass', (2.0, 'dim', 'textured'): 'pass', (4.0, 'dim', 'textured'): 'fail',
           (2.0, 'bright', 'sparse'): 'pass', (4.0, 'bright', 'sparse'): 'not tested', (6.0, 'bright', 'textured'): 'not tested'}
cells = list(itertools.product(speeds, lights, scenes)); tested = [c for c in cells if c in verdict]; passed = [c for c in cells if verdict.get(c) == 'pass']
print(f"cells: {len(cells)}, tested {len(tested)}, passed {len(passed)}; coverage of the intended space by passing evidence: {len(passed) / len(cells):.0%}")
M = 0.2
def go_nogo(speed, light, scene):
    # allowed only if some passing cell has speed >= planned speed / (1 - margin) in the same light and scene
    ok = [c for c in passed if c[1] == light and c[2] == scene and c[0] * (1 - M) >= speed]
    return ('GO', f"covered by passing cell at {max(ok)[0]} m/s") if ok else ('NO-GO', 'no passing evidence covers these conditions with margin')
for plan in [(3.0, 'bright', 'textured'), (3.5, 'bright', 'textured'), (3.0, 'dim', 'textured'), (1.5, 'dim', 'textured'), (1.5, 'bright', 'sparse'), (3.0, 'bright', 'sparse')]:
    print(plan, go_nogo(*plan))
assert go_nogo(3.0, 'bright', 'textured')[0] == 'GO' and go_nogo(3.5, 'bright', 'textured')[0] == 'NO-GO' and go_nogo(3.0, 'dim', 'textured')[0] == 'NO-GO' and go_nogo(1.5, 'bright', 'sparse')[0] == 'GO'
# speed limit from the stopping distance
Td, Ta, ab, margin, clear = 0.5, 1.0, 3.0, 1.0, 12.0
a, b, c = 1 / (2 * ab), Td + Ta, margin - clear; v_stop = (-b + (b * b - 4 * a * c) ** 0.5) / (2 * a)
print(f"stopping-distance bound for {clear} m clear distance: {v_stop:.2f} m/s")
assert abs(v_stop * (Td + Ta) + v_stop ** 2 / (2 * ab) + margin - clear) < 1e-9 and 4.5 < v_stop < 5.0
untested = [c for c in cells if c not in verdict]; print("envelope extension needs tests at:", untested[:4], "...")

Common engineering mistakes

Failure modes

Debugging approach

1. Check every limit for evidence, a monitor and a consequence.
2. Plot the tested cells and the planned operating space to find gaps.
3. Record flown conditions and compare with the envelope after each campaign.
4. Review the envelope whenever the baseline changes.

Practical exercises

1. Write the limits table for your capstone: eight limits with rationale, monitoring and consequence.
2. Compute the speed limit for 8 m clear distance, $T_{d}=0.4\,\mathrm{s}$, $T_{a}=1.2\,\mathrm{s}$, $a_{b}=4\,\mathrm{m}/\mathrm{s}^{2}$, margin 1 m.
3. Extend the example with a wind dimension and mark which new cells need tests.
4. Write the go/no-go checklist from the limits.

Interview questions

Write an answer in your own words, then reveal the model answer. Nothing is sent anywhere.

References and further reading

Primary papers, official documentation and standards. Each claim above that is specific to a tool or version points here.

• NASA Systems Engineering Handbook (NASA/SP-2007-6105), operations and limitations
• EASA: Operating a drone (EU rules; check the rules that apply where you fly)
• PX4: Safety configuration (geofence, limits)

What’s next