Unmanned systems are classified by where they operate, how they move, how people control them, what tasks they perform, and which technical or regulatory scheme applies. These dimensions overlap: an autonomous underwater survey vehicle is simultaneously underwater, untethered, mission-programmed, and equipped for surveying. A useful classification keeps those attributes separate instead of treating one label as a complete description of capability.
For an engineer or operator, the purpose is practical. A category should help identify the equipment, interfaces, human responsibilities, and operating limits that must be checked before a system can perform a task.
On This Page
- Start with the operating domain and system boundary
- Describe control and autonomy for the actual task
- Connect the classification to the system architecture
- Keep size classes and operating categories tied to their authority
- Use failure modes and tradeoffs to distinguish similar systems
- Write a classification that someone can use
Start with the operating domain and system boundary
The familiar air, ground, surface-water, and underwater families describe the vehicle's operating domain. The broader system includes supporting equipment. NIST's ALFUS terminology, Volume I, version 2.0 allows both mobile and stationary unmanned systems and includes associated support components, such as operator control units. It does not make autonomy a prerequisite for being unmanned.
The following map is a practical overview of those families, with representative applications rather than guaranteed capabilities.
| Operating domain | Common name | What the label identifies | Representative application |
|---|---|---|---|
| Air | Unmanned aerial vehicle (UAV); unmanned aircraft system (UAS) | Aircraft, or aircraft and supporting system | Aerial observation and mapping |
| Ground | Unmanned ground vehicle (UGV) | A vehicle operating on land | Remote inspection in hazardous environments |
| Water surface | Uncrewed or unmanned surface vessel/vehicle (USV) | A vessel operating at the surface | Seafloor mapping and environmental sampling |
| Underwater | Unmanned underwater vehicle (UUV), with AUV and ROV terminology used for different operating arrangements | A vehicle operating below the surface | Submerged surveys, object identification, and inspection |
Source basis: NIST ALFUS terminology for domain families; the NOAA and NIST application references below. The table is an editorial cross-domain map, not a certification scheme.
Do not classify a system solely by its payload's target. A surface vessel mapping the seabed remains a USV. An aircraft observing a road remains an air system. For a vehicle that changes domains, describe each operating mode and its transition limits.
Underwater terminology demonstrates why domain alone is insufficient. NOAA distinguishes AUVs from ROVs by their operating arrangement: an autonomous underwater vehicle conducts a programmed survey without a connecting cable, while a remotely operated vehicle receives operator commands through cables from a ship. ROVs can carry cameras, sonar, and manipulators; AUV survey data can be retrieved after the mission. Both are unoccupied underwater vehicles, but their supervision and data paths differ.
Describe control and autonomy for the actual task
“Unmanned” identifies the absence of an onboard operator in the relevant system boundary. It does not tell the reader which decisions software makes. Useful descriptions name the functions under machine control and the functions retained by people.
For example, distinguish an operator continuously directing movement from software maintaining attitude, following a route, or selecting a route around an obstruction. Those functions can coexist. A vehicle may follow a route automatically while a person interprets its camera feed and decides whether an inspection is complete.
NIST's ALFUS Volume II, version 1.0 characterizes autonomy using mission complexity, environmental complexity, and human independence. This historical technical framework makes context explicit; it is not a universal operating approval or an interchangeable industry-wide numbered scale.
A hypothetical warehouse robot illustrates the distinction. Navigating a mapped aisle with controlled access is a different task from negotiating an unfamiliar aisle containing moving people and unexpected obstructions. Calling both tasks “autonomous navigation” leaves the consequential difference unstated. Ask what the system perceives, which decisions it can make, and when it needs intervention.
For any claimed autonomy level, request the named scheme and version, task, permitted environment, operator role, and demonstrated limits. A number without that context cannot support a meaningful comparison.
Connect the classification to the system architecture
A working classification should describe the path from mission input to physical action and useful output. The following questions expose that path without assuming that every platform uses the same hardware.
- Mission input: Who supplies the route, target, sampling plan, or movement command?
- Sensing and estimation: Which measurements establish position, motion, and relevant surroundings?
- Control and actuation: Which controller converts the desired movement into motor, steering, or other actuator commands?
- Mission output: Does the system deliver imagery, measurements, transported material, or physical manipulation?
- Human interface: What status reaches the operator, and how can control be transferred or the task interrupted?
The PX4 v1.16 system architecture provides a concrete aircraft example. Its flight controller runs estimators and controllers, receives sensor data, and commands motor controllers. Telemetry connects the aircraft to ground-station software. An optional companion computer supports more demanding functions, including computer vision, through a serial or IP connection that commonly carries MAVLink messages.
This division matters when interpreting a claim such as “autonomous aircraft.” It could depend on an additional computer, sensor package, and configured communication path. The airframe name alone does not establish that configuration.
At an integration handoff, identify the actual messages and responsibilities on each connection. For example, ask whether an external computer supplies a desired position or direct actuator commands, how stale commands are detected, and which component retains authority when communication stops. A shared connector or protocol name does not answer those questions.
In this feedback loop, a desired movement is compared with an estimated state, and the controller changes actuator commands to reduce the difference. Sensor measurements then update the estimate. If an inspection camera supplies mission imagery but does not feed navigation, losing that camera can invalidate the inspection while leaving vehicle control available. Establish which role each sensor actually serves before assigning a failure consequence.
The system boundary can also span several vehicles. NOAA's USV overview describes surface vessels supporting underwater vehicles with navigation, instructions, and communication, and sometimes docking or recharge services. Classify the surface and underwater platforms separately, then identify their shared mission and dependencies. Removing the support vessel could remove a necessary navigation or communication service even when the underwater vehicle itself remains functional.
Keep size classes and operating categories tied to their authority
Terms such as “small,” “Class 2,” or “Group 3” need a named source. An organizational equipment group, a product class, an autonomy level, and an operating category can use similar-looking labels while answering different questions.
Two civil aviation examples show the distinction:
- In the United States, the FAA's Part 107 overview concerns small unmanned aircraft weighing less than 55 pounds. That mass boundary belongs to a particular regulatory context; it is not a cross-domain definition of a small robot or a measure of autonomy.
- In the European framework, EASA describes open, specific, and certified categories for civil drone operations according to risk. These classify the operation. The C0–C6 class identification labels concern aircraft product requirements under Regulation (EU) 2019/945. A product class and an operating category are different entries in a system description.
For a military, standards-body, or supplier classification, retain the issuing organization, document version, measured quantity, units, and boundary conditions. Do not translate a group number into another scheme without an explicit mapping. Neither a physical category nor an autonomy claim establishes permission to conduct a particular operation.
Use failure modes and tradeoffs to distinguish similar systems
Two systems in the same domain can need different recovery arrangements. The distinctions below are questions to resolve for a proposed configuration, not claims that every member of a category behaves identically.
Communication and navigation failures
Separate loss of command input, loss of the operator's display, and loss of a usable position estimate. They remove different capabilities. An operator may still see video after navigation becomes unreliable, or onboard navigation may continue after the ground link disappears.
The PX4 v1.16 failsafe guide documents distinct battery, manual-control-loss, data-link-loss, and position-loss handling. The response depends on configuration and available estimates. Even “hold” differs by vehicle form: a multicopter can hover, whereas a fixed-wing aircraft circles. Consequently, a requirement to stop and wait needs a platform-specific interpretation.
Record the trigger, resulting mode, operator indication, and recovery procedure. “Returns home on failure” is too broad when the failed function may be needed to navigate home.
Mobility, sensing, and endurance
Physical configuration describes how a vehicle produces and controls movement. In air systems, distinguish rotor-supported hover from wing-supported forward flight, and identify designs that transition between them. Vertical takeoff and landing (VTOL) describes a capability; it does not, by itself, describe the complete propulsion system, energy source, or cruise mode.
NASA's Greased Lightning technology description illustrates a design combining vertical flight with an efficient wing-borne cruise configuration. Its proposed hybrid electric arrangement uses engines and alternators to supply electric propulsion, with batteries supporting the power demand of hover and vertical flight. This is a documented design example, not evidence that every hybrid aircraft achieves the same endurance.
The distinction changes a mission comparison. A task requiring prolonged observation from one position makes hover capability relevant. A task covering separated survey areas also needs an account of travel between them. Ask how much of the proposed mission uses each flight mode and whether the quoted endurance includes takeoff, transitions, payload operation, and recovery. Comparing a cruise-only figure with a complete hover mission would conceal the controlling difference.
For ground systems, wheels, tracks, or another mobility arrangement identify design choices; they do not prove success on a particular stair, gap, slope, or surface. NIST's response-robot performance program evaluates capabilities through separate tasks, including mobility, dexterity, sensing, endurance, and radio communication. Its ground tests include terrain and confined-obstacle conditions.
That separation helps an evaluator avoid inferring inspection capability from driving capability. A robot could reach a location yet lack the visual detail or manipulator access needed to finish the job. Compare demonstrated task performance in relevant conditions, alongside the category label.
Underwater, the autonomy and propulsion descriptions also need separating. NOAA's AUV explainer describes both powered propulsion and gliders that exploit changes in buoyancy and gravity to reduce propulsion demand. Lower propulsion demand can favor sustained sampling, but a mission requiring precise movement or position holding needs a separately demonstrated capability. Match the movement and sampling pattern to the mission before comparing endurance figures; the AUV label does not resolve that tradeoff.
NOAA's ocean-glider explanation makes the mechanism concrete. In its illustrated Slocum design, a pump changes buoyancy, causing the vehicle to descend or ascend. The wings generate lift as water flows past, producing forward movement during that vertical travel. A sequence of dives and climbs can therefore collect measurements through the water column along a route.
For a survey specification, distinguish that moving vertical profile from a requirement to remain at one depth and location. Also name the measurements required: temperature and salinity observations, acoustic detections, and imagery are different outputs even when collected by vehicles in the same family. The platform classification narrows the candidate architecture; the required output and sampling pattern determine whether that architecture suits the task.
Write a classification that someone can use
Consider a hypothetical requirement to map a sheltered lake using an unoccupied survey vessel. A useful initial description would contain these fields:
| Classification field | Hypothetical description | What still needs confirmation |
|---|---|---|
| Domain and form | Surface-water survey vessel | Draft, launch arrangements, and permitted water conditions |
| Control | Programmed survey lines with remote supervision | Operator responsibilities, intervention path, and obstacle response |
| Mission and payload | Collect georeferenced depth measurements | Sensor installation, timing, positioning, and output requirements |
| Support architecture | Shore control station and radio link | Coverage and behavior beyond reliable coverage |
| Failure behavior | Defined responses required for link, navigation, and energy faults | Exact triggers, recovery modes, and demonstrations |
| Applicable scheme | Jurisdiction and operating requirements to be identified | Relevant authority and requirements for this location |
This is a specification example, not a description of a tested vessel. Its value is that it separates facts about the platform from questions about the mission.
For an existing system, replace those open questions with documented configuration details and relevant results. Keep the domain, physical arrangement, control responsibilities, mission, limits, and applicable classification authority together. That produces a description another engineer or operator can assess without guessing what “unmanned” or “autonomous” was intended to promise.
Sources
- NIST ALFUS Volume I, terminology version 2.0: technical terminology for system boundaries and domain families.
- NIST ALFUS Volume II, framework models version 1.0: historical framework connecting autonomy to mission, environment, and human involvement.
- NOAA: AUV and ROV differences: government explanation of tethering, control, and underwater applications.
- NOAA: Uncrewed surface vessels: surface-vessel configurations, missions, and support for underwater systems.
- NOAA: What is an AUV?: underwater vehicle propulsion and survey functions.
- PX4 v1.16 system architecture: implementation documentation for controllers, sensors, computers, and connections.
- PX4 v1.16 failsafe configuration: implementation-specific fault triggers and recovery modes.
- NIST: Performance of emergency response robots: task-based evaluation of ground, aerial, and aquatic systems.
- FAA: Small UAS regulations overview: U.S. Part 107 mass scope.
- EASA: Operating a drone: risk-based civil drone operation categories.
- EASA: C0–C6 class identification labels: aircraft product classes and their regulatory basis.
- NASA: Greased Lightning VTOL technology: design example separating vertical flight, wing-borne cruise, and hybrid electric propulsion.
- NOAA: What is an ocean glider?: buoyancy-driven movement, wing lift, and water-column sensing.
Last checked: September 6, 2026.
