Target Drone Requirements Checklist

A target drone is a measuring instrument that other systems are tested against. When its requirements are wrong, the cost lands on the test data: sorties that proved nothing, results nobody can defend, and a programme that paid for both the aircraft and the wasted range time. The failure mode is usually the same: the requirements document describes an airplane when it should describe a test.

This checklist runs in the order that prevents that. It stays at the level a procurement or test-and-evaluation team actually writes at; sensitive threat detail, where applicable, belongs in the appropriate controlled annex, while the main requirements still need the measurable observable characteristics, not the intelligence file.

Start with the test objective

Before any characteristic of the drone, write down what system is under test and what decision the test supports: development, acceptance, operator training. The decision determines the fidelity you must buy. A sortie supporting operator proficiency and a sortie generating data for a seeker development milestone are different purchases, even if one airframe could physically fly both. If the requirements cannot name the test decision, they will optimize for something else (usually unit price) and the data will show it.

Define the representation before the airframe

What must the system under test observe? Write it as observable characteristics: the speed-altitude corner the target must hold, the maneuverability it must sustain in the presentation window, and the signatures it must present, with augmentation (enhancers, pods, towed bodies) filling whatever the bare airframe cannot. The propulsion consequences of the speed-altitude corner are worked through in the turbojet-versus-piston comparison; the short version is that no amount of piston-engine economy substitutes for the closure rate your threat set demands.

Resist writing the requirement as "make it behave like threat X." Write what the test must measure, and let the representation be engineered to it.

Flight profile and endurance

Decompose the mission into segments (launch, climb, transit, presentation window, egress, recovery) and put numbers on each. The binding figure is usually time in the presentation window at the required conditions, not total endurance; a drone with two hours of fuel and four minutes on profile is a transit aircraft with a target problem. Note the throttle usage per segment as well, because it drives engine selection, spool-management and the fuel reserve.

Launch and recovery

Runway, rail or air-launch are three different logistics chains wrapped around three different aircraft. Air-launch buys basing flexibility and puts the whole flight at altitude; it also makes the separation event and the carrier interface first-class requirements. Recovery is the same kind of fork: expendable airframes simplify everything except the bill, while parachute recovery (land or water) buys reuse at the price of designing the recovery in from the first layout. The Orion-T1 is air-launched with parachute recovery, and its separation test was scripted before the airframe existed: released at 3 km and Mach 0.45, holding angle of attack within a degree and losing at most 16 feet against a declared allowance of 300.

Whatever you choose, write turnaround time between sorties into the requirement. It caps sorties per airframe per day, which sets fleet size, which sets cost.

Payload and scoring

Scoring and miss-distance instrumentation, augmentation devices, towed bodies, cameras: the payload list will change over the program's life, and that is the one certainty you can design for. Reserve volume, mass, power and data bandwidth for payloads not yet chosen. A target airframe frozen around its day-one fit will spend its life in modification programs.

Telemetry and tracking

The sortie only happened if the range saw it. Tracking coverage, telemetry bandwidth, onboard recording as backup, and time correlation between the target's data and the system under test's data all belong in the requirements, with the actual range infrastructure named, not assumed. Interoperability with the range you will really use beats theoretical performance at a range you will never visit.

Environment

Temperature and wind limits for launch and recovery, humidity and salt exposure if recovery is maritime, and the storage and transport environment between campaigns. The useful discipline here is tailoring rather than copying: MIL-STD-810 exists as a menu of environmental test methods to select from against your real life-cycle profile, not a list to impose wholesale. Declare the environments the fleet will actually meet and require demonstration against those.

Repeatability is a requirement

The value of a test series is comparability across sorties: the same profile, at the same speeds and altitudes, within declared tolerances, every time. Write the tolerances. "Flies the card to within a stated altitude and speed band" is a requirement; "accurate navigation" is a wish. This is also where throttle and transient behavior enter: a dash segment that arrives two seconds late on every run is at least consistently late, and consistency is what makes data comparable.

Attrition and fleet arithmetic

Targets are flown against, and some do not come back. That is the job. State an assumed loss rate per sortie honestly, then do the arithmetic that matters: cost per valid test point, not cost per flight hour and certainly not unit flyaway price. Fleet size falls out of sortie rate, turnaround and availability, minus expected losses. A cheaper expendable and a recoverable target with higher unit cost can legitimately trade places depending on that one calculation.

Logistics and footprint

Fuel type is a supply-chain decision before it is an engineering one: heavy fuels align with military logistics; gasoline aligns with small civilian strips. Crew size, support equipment, transport configuration and shelf state between campaigns all belong in the requirement set. A slightly less capable target that ships in a container and flies with three people will out-fly a better one that travels with an entourage.

Verify with scripted cards, written in advance

Acceptance should be a set of scripted test cards with expectations declared before the flight: measured value against declared expectation, card by card. The T1 program is the template: six 6-DoF tests (trim, launch separation, max level speed, climb, sustained turn, fuel and thrust anchors), each with an expectation written down first, six passes. Require that the simulated and flown acceptance programs share the same cards, so anomalies surface in simulation rather than at the range. The five-gate process shows where that flight-test discipline sits in a program.

The requirements worksheet

Work the table top to bottom and the viable design trade space narrows, which is the point. Requirements written in this order let a designer close a concept against them instead of guessing at them; the design-brief checklist covers that handoff from the propulsion side. What a resulting platform looks like in this class of work is described under target drone systems.

Next step: if your worksheet answers exist on paper, the requirements conversation is short: one line is enough to begin, and the design intake is where it starts.