NIST Special Publication 1011-I-2.0 

1 

 

Autonomy Levels for Unmanned Systems 

(ALFUS) Framework 

Volume I: Terminology 

 

Version 2.0 

Contributed by the Ad Hoc Autonomy Levels for Unmanned 

Systems Working Group Participants1

Edited by: Hui-Min Huang 

National Institute of Standards and Technology

October 2008

 

1

 See CONTRIBUTORS 
NIST Special Publication 1011-I-2.0 

1 

CONTENTS 

CONTENTS .................................................................................................................................... 1 

CONTRIBUTORS .......................................................................................................................... 4 

VERSION HISTORY ..................................................................................................................... 7 

EXECUTIVE SUMMARY, VERSION 2.0.................................................................................... 8 

EXECUTIVE SUMMARY, VERSION 1.1.................................................................................... 9 

1 INTRODUCTION ................................................................................................................ 11 

1.1 Current Practices.......................................................................................................... 12 

1.2 Scope............................................................................................................................ 14 

2 MULTI-DOMAIN TERMS AND DEFINITIONS .............................................................. 15 

Act .................................................................................................................................... 15 

Adapt to Conditions.......................................................................................................... 15

Assembly Point (AP)........................................................................................................ 15 

Autonomous ..................................................................................................................... 15 

Autonomy......................................................................................................................... 15 

Autonomy Levels for Unmanned Systems (ALFUS) Framework or ALFUS ................. 16 

Built-in Test...................................................................................................................... 16 

Contextual Autonomous Capability (CAC) Model for Unmanned Systems (UMS) ....... 16 

Collaboration or Cooperation........................................................................................... 17 

Control Method ................................................................................................................ 17 

Cooperation ...................................................................................................................... 17 

Coordination..................................................................................................................... 17 

Data Fusion ...................................................................................................................... 17 

Dynamic mission planning............................................................................................... 17 

E-Stop or Emergency Stop ............................................................................................... 17 

Environment ..................................................................................................................... 18 

Execute ............................................................................................................................. 18 

Executive/Summary Model for ALFUS........................................................................... 18 

Fault Tolerance................................................................................................................. 18 

Fully Autonomous............................................................................................................ 18 

Fusion or Information Fusion or Data Fusion .................................................................. 18 

Fusion Levels or Levels of Fusion ................................................................................... 18 

Goal .................................................................................................................................. 19 

Hazard Avoidance ............................................................................................................ 19 

Human/Operator Intervention .......................................................................................... 19 

Human Independence (HI) ............................................................................................... 19 

Human Robot Interaction/Interface (HRI) or Human Interaction, Operator Interaction.. 19 

Supervisor......................................................................................................................... 20 

Teammate/Wingman ........................................................................................................ 20 

Operator............................................................................................................................ 20 

Mechanic or Developer .................................................................................................... 20 

Bystander.......................................................................................................................... 20 

Human-Operated .............................................................................................................. 20 

Human-Assisted ............................................................................................................... 21

Human-Delegated............................................................................................................. 21 

Human-Supervised ........................................................................................................... 21 

Information Fusion........................................................................................................... 21

Intelligence in Unmanned Systems (UMSs) .................................................................... 21 
NIST Special Publication 1011-I-2.0 

2 

Interoperability ................................................................................................................. 21 

Leader Follower ............................................................................................................... 21 

Level................................................................................................................................. 21 

Level of Autonomy .......................................................................................................... 21 

Level of Control ............................................................................................................... 21 

Marker .............................................................................................................................. 21 

Method of Control............................................................................................................ 22

Mission ............................................................................................................................. 22 

Mission Module................................................................................................................ 22 

Mission Planning.............................................................................................................. 22 

Mobility............................................................................................................................ 22 

Mode................................................................................................................................. 22 

Mode of Operation for Unmanned Systems, Mode of Unmanned System Operations, or 

Unmanned System Operational Mode <A.8> ................................................................. 22 

Fully Autonomous............................................................................................................ 22 

Semi-Autonomous............................................................................................................ 23 

Teleoperation.................................................................................................................... 23 

Remote Control ................................................................................................................ 23 

Observation ...................................................................................................................... 23 

Obstacle............................................................................................................................ 23 

Operator Control Unit (OCU) .......................................................................................... 23 

Orientation6 ...................................................................................................................... 23 

Perception......................................................................................................................... 23 

Local perception............................................................................................................... 24 

Perception Levels or Levels of Perception [3] ................................................................. 24 

Point Man or Unmanned Point Man, Robotic Point Man ................................................ 24 

Prognostic Health Management ....................................................................................... 24 

Remotely Guided.............................................................................................................. 24

Robot ................................................................................................................................ 24 

Robotic Follower.............................................................................................................. 25 

Root Autonomous Capabilities (RAC)............................................................................. 25 

Self-Diagnosis .................................................................................................................. 25 

Self-Healing ..................................................................................................................... 25 

Semi-Autonomous............................................................................................................ 25 

Sense................................................................................................................................. 25 

Sensor............................................................................................................................... 25 

Sensor Fusion ................................................................................................................... 25 

Sensory Processing........................................................................................................... 26

Situational Awareness ...................................................................................................... 26 

Summary/Executive Model for Autonomy Levels........................................................... 26 

System of Systems or Team of Teams ............................................................................. 26 

Tactical Behavior ............................................................................................................. 26 

Task .................................................................................................................................. 26 

Skill .................................................................................................................................. 26 

Task Decomposition......................................................................................................... 27 

Teaming............................................................................................................................ 27 

Teleoperation. See Mode of UMS Operation - Associated terms. .................................. 27 

Telepresence..................................................................................................................... 27 

Terrain .............................................................................................................................. 27 

Terrain Visualization........................................................................................................ 27

Tether ............................................................................................................................... 28 
NIST Special Publication 1011-I-2.0 

3 

Threat Avoidance ............................................................................................................. 28

Unattended Ground Sensors (UGS) ................................................................................. 28 

Unattended System........................................................................................................... 28 

Unmanned System (UMS) ............................................................................................... 28 

Unmanned Wingman, Robotic Wingman ........................................................................ 29 

Waypoint .......................................................................................................................... 29 

World Model (WM) ......................................................................................................... 29 

World Modeling ............................................................................................................... 29

3 DEFENSE ORIENTED TERMS OR EXTENSIONS ......................................................... 30 

Classes of UGVs .............................................................................................................. 30

Common Operational Picture (COP)................................................................................ 30 

Cooperative Engagement ................................................................................................. 30 

Levels of Control (UMS). Levels of Control (UMS/Remotely Operated Systems)........ 30 

Point and Shoot ................................................................................................................ 31 

Obstacle............................................................................................................................ 31 

Scout................................................................................................................................. 31 

Sensor to Shooter.............................................................................................................. 31 

Tactical Behavior ............................................................................................................. 31 

Threat Levels.................................................................................................................... 31 

Unmanned Rear Guard or Robotic Rear Guard ............................................................... 31 

4 SEARCH AND RESCUE (SAR) ORIENTED TERMS OR EXTENSIONS...................... 33 

Advisory ........................................................................................................................... 33 

Cache................................................................................................................................ 33 

Collapse Hazard Zone ...................................................................................................... 33 

Designated Area ............................................................................................................... 33 

Mobilization Time Frame................................................................................................. 33 

Urban Search and Rescue (US&R, USAR)...................................................................... 33 

5 PROPOSED MANUFACTURING ORIENTED TERMS OR EXTENSIONS................... 34 

6 RATIONALES FOR TERM DEFINITIONS....................................................................... 35 

6.1 Executive Model for Autonomy Level ........................................................................ 35 

6.2 Unmanned System (UMS) ........................................................................................... 35 

6.3 Obstacle........................................................................................................................ 35 

6.4 World Model (WM)..................................................................................................... 35 

7 ACRONYMS........................................................................................................................ 36 

APPENDIX A ONGOING DISCUSSIONS OR UNRESOLVED ISSUES............................... 41 

REFERENCES.............................................................................................................................. 45 
NIST Special Publication 1011-I-2.0 

4 

CONTRIBUTORS 

The following lists practitioners who have been contributing to the Autonomy Levels for 

Unmanned Systems (ALFUS) effort through meeting discussions, document review, and email 

exchanges offering field experiences since the Workshop #1. Those who have been instrumental 

to particular aspects of the ALFUS Framework at various stages of the effort are recognized in 

Segment I of the list and the rest of the contributors are included in Segment II. 

We apologize if any contributors have been omitted from the list or misplaced between the two 

segments. Please inform us, so that we can update the list. Contractors are acknowledged with 

the organizations or programs that they support. As the development effort continues, the lists 

are anticipated to be reorganized per the evolution of the Framework. 

The funding sources are acknowledged at the end. 

SEGMENT I: 

Kerry Pavek 

L3 Communications 

U.S. TRADOC Command Capabilities Manager, Future Combat System (FCS) 

Robert Smith 

U.S. Air Force Research Laboratory 

Keith Arthur 

U.S. Army Aviation Applied Technology Directorate (AATD) 

Ray Higgins 

U.S. Army AATD 

Eric Hansen 

U.S. Navy 

Naval Surface Weapon Center 

Mark Ragon 

The Boeing Company 

U.S. Army FCS Lead System Integrator (LSI) System of Systems Engineering and 

Integration (SSEI) Integrated Product Team (IPT) 

Jeffery Jones 

Navigator Development Group 

U.S. Army FCS LSI SSEI IPT 

Robert Wade 

U.S. Army Aviation and Missile Research, Development and Engineering Center 
NIST Special Publication 1011-I-2.0 

5 

Woody English 

Devivo AST, Inc. 

Chair, SAE AS-4 Committee 

Brian Novak 

U.S. Army Tank-Automotive Command Research, Development and Engineering Center 

David Bruemmer 

U.S. Department of Energy 

Idaho National Laboratory (INL) 

Anthony Barbera 

U.S. DOC, NIST 

SEGMENT II: 

Adams, Curt—U.S. Army TACOM/ U.S. Army FCS 

Adams, Thomas— The Boeing Company, FCS LSI 

Altshuler, Thomas—Rockwell Scientific Company 

Anderson, Keith—U.S. OSD 

Antonishek, Brian—NIST 

Barnhill, Robert MAJ—U.S. Army 

Bergman, John—FCS Support 

Bishop, Charles—The Boeing Company, FCS LSI 

Brayman, Darryl—Air Force Research Laboratory 

Brendle, Bruce—U.S. Army TACOM 

Cagle-West, Marsha—U.S. Army AMRDEC SED 

Cerny, Jeffrey—U.S. Army AMRDEC-ASD 

Clough, Bruce—U.S. Air Force AFRL 

Connelly, Julianna—IDA 

Dzugan, Michael—U.S. Army CERDEC 

Ferlis, Robert—DOT FHWA 

Fleck, Dale—Lockheed Martin Company 

Gage, Douglas— DARPA/XPM Technologies 

Gage, Gerrie LTC—DARPA 

Hart, Jeremy--NASA 

Hill, Susan G.—U.S. Army ARL 

Hirtz, Julie—U.S. Army DCD 

Hodge, Kelley A. MAJ—U.S. Army 

Huang, Peter—U.S. DOT FHWA 

Juberts, Maris—NIST (retired) 

Kania, Robert—U.S. Army TACOM 

Klarquist, William —Perceptek Robotics Company, FCS Support 

Knichel, David— U.S. Army DCD 

Kotora, Jeffrey—OSD Support (L3) 

Laflamme, Mark—U.S. Army 

Maijala, Brian K—U.S. Army 

Mamplata, Caesar G.—U.S. Navy NAVAIR 

Mayhew, Gregory—Boeing Company, FCS LSI 

McWilliams, George—Southwest Research Institute 

Melick, Peter—U.S. Army 
NIST Special Publication 1011-I-2.0 

6 

Moorthy, Jay—U.S. Army AATD 

Nardi, Gregory J—U.S. Army UAMBL 

Nielson, Curtis—U.S. INL 

Overstreet, Dennis—DARPA Support (SRS Tech) 

Pena, Richard—FCS Support 

Peot, Mark—Rockwell Scientific Company 

Pusey, Jason—U.S. Army 

Rolader, G.—SAIC Company, FCS LSI 

Rovegno, John COL—U.S. Army 

Rodgers, Dan—GDRS Company (FCS) 

Schipani, Salvatore—NIST 

Scholtz, Jean—NIST (retired) 

Schultz, Alan C.—U.S. Navy NRL 

Scott, Harry—NIST 

Shoemaker, Charles— U.S. Army ARL 

Sparrow, David—IDA 

Steinberg, Marc—U.S. Navy ONR 

Swan, Stephen—DOD Support 

Tasker, Chirag R.— SAIC Company, FCS LSI 

Walther, Robert—USSOCOM 

Wavering, Albert—NIST 

Weber, Thomas— U.S. DOE 

Wit, Jeffrey— U.S. Air Force AFRL Support 

Funding support for the ALFUS effort has been provided by: 

U. S. Department of Commerce 

 National Institute of Standards and Technology 

 Division Chief: Mr. Albert Wavering 

 Acting Division Chief: Ms. Elena Messina 

Department of Homeland Security 

Science and Technology Directorate 

Standards Executive 

Sponsor: Dr. Bert Coursey 

The U.S. Army Research Laboratory, under the sponsorship of Charles Shoemaker (retired) and 

Dr. Jon Bornstein, provided partial funding support at the early stage of the effort. 
NIST Special Publication 1011-I-2.0 

7 

VERSION HISTORY 

• Version 2.0—Added terms, updated definitions, added new domains—Search and Rescue 

and Manufacturing, added new sections on current robotic terminology standards and 

rationales for certain term definitions. 

• Version 1.2—Updates on terms 

• Version 1.1—Document title changed from “Terminology for Specifying the Autonomy 

Levels for Unmanned Systems” to “Autonomy Levels for Unmanned Systems (ALFUS) 

Framework, Volume I: Terminology,” September 2004. 

• Version 1.0—Published in January 2004. 

• Draft Version 1.0—Accommodated comments raised in the Workshop #3, distributed on 

December 11, 2003. 

• Draft Version 0.9—Distributed to members and user community on October 25, 2003, 

redistributed on November 10, 2003. 

• Draft Version 0.7—Distributed to members and user community for feedback at the end of 

September 2003. 

• Draft Version 0—Presented and discussed in Workshop #2, September 11, 2003. 
NIST Special Publication 1011-I-2.0 

8 

EXECUTIVE SUMMARY, VERSION 2.0 

This document, Version 2.0 of the Autonomy Levels for Unmanned Systems (ALFUS) 

Terminology, is based on Version 1.1, published as NIST Special Publication 1011. As stated in 

the inaugural Workshop, the ALFUS Framework, of which the Terminology is a part, is evolving 

as the Unmanned Systems (UMS) technology advances. Version 2.0 essentially covers the 

results of the ALFUS effort up to the end of 2007. 

The main objective for this document, as stated in Version 1.1, is to identify and define terms to 

support the UMS community, particularly from the perspectives of characterizing the autonomy 

and measuring the autonomous capability of the UMS. Common definitions and terminology 

facilitates communication and reduces confusion in the UMS community. Version 1.1 has been 

significantly referenced or adopted in several other UMS standards, proving that ALFUS is 

achieving this objective. Section 1 provides more detailed descriptions in this regard. 

As such, a significant portion of the terms and the format of the documentation remain the same. 

The main advances in Version 2.0 are: 

1. Addition of new terms. 

2. Revision of definitions for some of the existing terms. 

3. Expansion of Domain Specific Terms section to include multiple Domains, namely, 

Defense, Urban Search and Rescue, and Manufacturing. 

4. Addition of a description of current practices in the area of UMS related terminology. 

One of the main objectives of ALFUS, as laid out by the original participants, is to provide 

common definitions and terminology to facilitate communication of autonomy in the UMS 

community. Version 1.1 has been significantly referenced or adopted in several other UMS 

standards, proving that ALFUS is achieving this objective. Section 1 provides more detailed 

descriptions in this regard. 

Please address feedback to: 

Hui-Min Huang 

National Institute of Standards & Technology 

Bldg. 220 Rm. B124 

100 Bureau Drive, Stop 8230 

Gaithersburg, MD 20899-8230 

Tel: 301 975-3427 

Fax: 301 990-9688 

Email: hui-min.huang@nist.gov 

The web site for the ALFUS effort is: http://www.isd.mel.nist.gov/projects/autonomy_levels/.
NIST Special Publication 1011-I-2.0 

9 

EXECUTIVE SUMMARY, VERSION 1.1 

This document, produced by the Ad Hoc Autonomy Levels for Unmanned Systems (ALFUS) 

Working Group (WG), defines and collects the terminology to support the Group’s main 

objective, the definitions of the unmanned system (UMS) autonomy and the metrics for 

measuring the autonomy. 

The WG was sponsored by NIST and with participation from UMS professionals from 

Government agencies and their supporting contractors2

 on a voluntary basis. The WG output is 

based on Group consensus. In its first workshop, held on July 18, 2003, the Group decided to 

launch an effort to produce a framework for autonomy definitions and metrics. In the second 

workshop, held in September 2003, it was decided that the first volume of the ALFUS framework 

would be terminology. Also decided was that the first version of the framework should focus on 

supporting the U.S. Army Future Combat Systems (FCS) program. FCS was selected as the first 

program that this WG effort collaborate with because, at that time, the program involved the 

largest U.S. Department of Defense (DOD) collection of robotic systems anticipated to develop 

increasing levels of autonomy. Also, the program was at a stage of systems engineering requiring 

the same types of autonomy definitions as the ALFUS group was addressing. 

The objective of this terminology effort is to, through a group effort, identify, develop, and 

document the terms and their definitions so that the results can serve as a common reference for 

the community. As such, consistency with the general dictionary definitions is assumed. 

However, for certain terms, we modified the dictionary definitions to better suit the UMS 

community needs. For some other terms, we repeated the dictionary definitions for referencing 

purposes. 

The overarching guidelines for this terminology effort are: 

• Leverage existing work and adopt existing definitions that are publicly available and 

accepted. This would expedite the WG’s effort in proceeding with its core objective, the 

autonomy level framework. The references are listed at the end of this document. 

Modifications to the existing definitions may be necessary3

 to fit the objectives of this 

working group. 

• Consider the cultural factor, for example, how people are using the terms, to ensure a 

seamless transition of the outcome to the users. 

• Consolidate similar terms and resolve conflicting ones. 

• Some terms may have generic and widely applicable definitions but are further defined 

for specific domains. We may provide both their generic definitions, in the MULTIDOMAIN TERMS AND DEFINITIONS section, and their extensions in the 

DEFENSE ORIENTED TERMS OR EXTENSIONS and/or SEARCH AND 

RESCUE (SAR) ORIENTED TERMS OR EXTENSIONS sections. It is 

perceivable that additional sections may be created in future versions to accommodate 

additional domains. There are also terms that are only applicable to specific domains. 

 

2

 The WG is now open to all the interested professionals. 3

 There are several cases when the definitions contributed by our WG members are similar to those given in 

the existing references. The descriptions from the existing references were typically adopted as the basis 

but enhanced by contributions from the WG members. 
NIST Special Publication 1011-I-2.0 

10 

They are defined, accordingly, in the respective sections. Note that the applicability of 

the terms could change over time as particular terms may get accepted in more domains 

while some other terms may become less relevant over time. 

• Some of terms are commonly referenced by the acronyms. Those acronyms are a part of 

this Terminology. Acronyms are collected in a separate section in this document. 

Iterations with the WG participants and user communities have been continuing. Version 1 of 

this document was published in January 2004 to support FCS. This version, Version 2 is planned 

to be published in late 2008. 

Since the WG has adopted a spiral development approach, this document is fully anticipated to 

evolve alongside the ALFUS framework itself. Readers and user communities have been, and are 

continuously encouraged to provide feedback. 

The web site for the ALFUS effort is: http://www.isd.mel.nist.gov/projects/autonomy_levels/.

Please address feedback to: 

Hui-Min Huang 

National Institute of Standards & Technology 

Bldg. 220 Rm. B124 

100 Bureau Drive, Stop 8230 

Gaithersburg, MD 20899-8230 

Tel: 301 975-3427 

Fax: 301 990-9688 

Email: hui-min.huang@nist.gov 
NIST Special Publication 1011-I-2.0 

11 

1 INTRODUCTION 

Unmanned systems (UMS) have been fielded in several domains in the recent past, ranging from 

battlefields to Mars and mostly sponsored by the U.S. Government. As the number of programs 

for developing UMS accelerates, there is a growing need for characterizing the autonomy of these 

systems. Individual government agencies have begun these efforts. The Department of Defense 

Joint Program Office, the Air Force Research Laboratory, the U.S. Army Science Board, the 

Army Maneuver Support Center, and National Institute of Standards and Technology have 

described levels of autonomy for various programs [2, 28, 29, 30, 31]. NASA has embarked 

upon a project on defining levels of autonomy for a human space flight vehicle [32]. It is 

beneficial that these and other agencies leverage each other’s efforts to aim at a consistent 

approach. 

This incentive gives rise to the Federal Agencies4 Ad Hoc Autonomy Levels for Unmanned 

Systems (ALFUS) Working Group. In its first workshop, held on July 18, 2003 at NIST, the 

Group determined that its objectives were to define metrics for autonomy and to develop a 

framework for autonomy levels for unmanned systems (ALFUS). A committee, composed of six 

participants and representing different application domains, was formed and charged to draft the 

framework. The Group also determined that a beginning step would be to identify and define a 

set of terms that may be needed to support the unmanned systems community, to serve as Volume 

I of the ALFUS framework, and to facilitate the Framework development effort. 

The terms should be categorized into a set that is generic and applicable to unmanned vehicles of 

various domains and a number of additional sets that are domain specific. The domain-specific 

terms can be instantiations of or extensions from the generic terms. The workshop participants 

identified the terms based on these premises. 

This document defines terms from the perspective of UMS. Therefore, some of the definitions 

might not be as generic as applicable to domains beyond the UMS domain. Some definitions 

may include descriptions on how particular communities might use the terms. 

It may be inevitable for certain acronyms, or even terms, to be used for different purposes by 

different communities. For example, ERT refers to Emergency Response Team in the DHS 

US&R robotics domain, but is also used to refer to Evidence Recovery Team by FBI. In a 

situation like this, we either list both or select a definition that may be used by a wider audience. 

In the case of ERT, we regard emergency responses as concerning a much larger citizen 

population than evidence recovery. 

Version 0 of the document was presented and discussed in the Second workshop, held on July 18, 

2003 at Baltimore-Washington Airport. Additional terms were identified and were assigned to 

the participants for definitions. All of the contributions have been incorporated. Numerous 

further iterations have been conducted with the working group participants and user communities. 

Version 1.0 of this document was published in January 2004 to support FCS. 

The terms and definitions are organized into the following sections: 

Section 2: Multi-Domain Terms and Definitions 

Section 3: Defense Oriented Terms or Extensions 

 

4

 Including supporting contractors. 
NIST Special Publication 1011-I-2.0 

12 

Section 4: Urban Search and Rescue (US&R) Oriented Terms or Extensions 

Section 5: Proposed Manufacturing Oriented Terms or Extensions 

Section 6: Rationales for Term Definitions

Section 7: Acronyms

Note that the later sections on domain oriented terms are equally important parts of the 

Terminology. Some of the acronyms in that section are also a part of the Terminology. It is 

possible that, upon further investigation or iterations, some of the terms currently identified as 

generic might be reassigned to the domain specific sections, or vice versa. Some other terms 

might even be considered beyond the scope of the autonomy level definitions at later stages and 

removed. The applicability of the terms could change over time as some terms may gain wider 

acceptance while some other terms may become less relevant over time. Additional terms will be 

included as part of the on-going WG efforts. Additional sections may also be added to 

accommodate additional application domains. 

We plan to continue updating this document and addressing these issues in the future versions. 

The style and structural guidelines for this document are: 

1. Terms are defined in alphabetical order. Terms that share the same roots are grouped 

together to facilitate consistent definitions. In these situations, a root term is defined, 

followed by a collection of associated terms. We also list these associated terms according to 

their original alphabetical order, but only provide pointers to where they are defined. 

2. Boldface is used to indicate the terms defined in this document. 

3. We differentiate the following types of references: 

• braces, { }, to indicate that the definition is adopted from the cited reference, 

• brackets, [ ], to relate the stated definitions to the cited reference(s), 

• footnotes to point to extensions in domain specific sections given in later in the 

document. 

• angular brackets, < >, to point to section 6 RATIONALES FOR TERM 

DEFINITIONS or APPENDIX A ONGOING DISCUSSIONS OR 

UNRESOLVED ISSUES. 

Note that some DOD documents that serve as references are only cited by particular numbers. 

Readers are to use the contact information as stated in the Executive Summary for specific 

document titles. 

4. Multiple definitions, obtained either from multiple references or through members consensus, 

may be given to a term when necessary. They are indicated with (A), (B), (C) ... . 

Since the WG has adopted a spiral development approach, this document is fully 

anticipated to evolve, in line with the ALFUS Framework. 

1.1 Current Practices 

There are some UMS terminology publications that have limited scopes and other 

standards or practices with terminology relevant to UMS. These are listed below. The 

first three either adopted or referenced this document to a significant extent. 
NIST Special Publication 1011-I-2.0 

13 

ASTM E 2521 – 07a, 

Standard Terminology for Urban Search and Rescue Robotic Operation 

ASTM F2395-05, 

Standard Terminology for Unmanned Aircraft Systems 

ASTM F 2541 – 06, 

Standard Guide for Unmanned Undersea Vehicles (UUV) Autonomy and Control 

ASTM E 2544 

Standard Terminology for Three-Dimensional (3-D) Imaging Systems 

R-103-2004 

AIAA Recommended Practice: Terminology for Unmanned Aerial Vehicles and Remotely 

Operated Aircraft 

AIAA S-066, 

Standard Vocabulary for Space Automation and Robotics (1995) 

ISO’s robotic terminology standards focus on industrial robotics. ISO TC 184/SC 2 has the 

following standards: 

ISO 14539:2000

Manipulating industrial robots -- Object handling with grasp-type grippers -- Vocabulary and 

presentation of characteristics 

ISO 9787:1999

Manipulating industrial robots -- Coordinate systems and motion nomenclatures 

ISO 9946:1999

Manipulating industrial robots -- Presentation of characteristics 

ISO 11593:1996

Manipulating industrial robots -- Automatic end effector exchange systems -- Vocabulary and 

presentation of characteristics 

ISO 8373:1994 

Manipulating industrial robots - Vocabulary 

Note: An amendment ISO 8373:1994/Amd 1:1996 and a Corrigendum ISO 8373/Cor.1:1996 

followed. 

ISO TC 184/SC 2 also has a list of other robotic standards [39, 40, 41, 42, 43, 44, 45] which 

might be of interest to some readers. 

IEEE has the following standard which provides a very limited amount of terms in robotics: 

IEEE 100-2000 

The Authoritative Dictionary of IEEE Standards Terms (Seventh Edition, 2000) 
NIST Special Publication 1011-I-2.0 

14 

1.2 Scope

This document covers engineering UMS and robots that operate in physical environments, but 

including simulation. 

The document covers terms that facilitate the autonomy characterization. Additional robotic 

terms can be found in other publications, including the NIST 4D/RCS reference architecture [3]. 

This document does not address the UMS terms from the perspectives of taxonomy or ontology, 

although this document does provide a basis for them and future versions of this document may 

cover them. 
NIST Special Publication 1011-I-2.0 

15 

2 MULTI-DOMAIN TERMS AND DEFINITIONS 

Act 

See Execute. 

Adapt to Conditions 

A UMS experiencing changes in the operational or environmental conditions that prevent it 

from continuing w its original mission will react within the confines of its 

capabilities. Adaptation may involve onboard replanning for alternatives. Applicable 

capabilities such as hover or stop may be performed until further instructed by operator or 

superior. System constraints or mission requirements may also mandate that the unmanned 

system continue to perform the mission in a degraded condition. 

This term can be extended for Adapt to Failures, Adapt to Terrain, Adapt to Errors, 

etc. 

Assembly Point (AP) 

Location or facility where participating members initially report after receiving activation 

orders from the sponsoring organization [36]. 

Autonomous 

Operations of a UMS wherein the UMS receives its mission from either the operator who is 

off the UMS or another system that the UMS interacts with and accomplishes that mission

with or without further human-robot interaction (HRI). 

Associated terms: 

Fully autonomous 

See Mode of UMS Operation - Associated terms. 

Semi-autonomous 

See Mode of UMS Operation - Associated terms. 

Autonomy5 

A UMS’s own ability of integrated sensing, perceiving, analyzing, communicating, planning, 

decision-making, and acting/executing <A.4>, to achieve its goals as assigned by its human 

operator(s) through designed Human-Robot Interface (HRI) or by another system that the 

UMS communicates with. UMS’s Autonomy is characterized into levels from the 

perspective of Human Independence (HI), the inverse of HRI. Autonomy is further 

characterized in terms of Contextual Autonomous Capability (CAC). 

 

5 Houghton Mifflin Company, The American Heritage Dictionary: “Autonomy: the condition or quality of being self 

governing”
NIST Special Publication 1011-I-2.0 

16 

Associated terms: 

Root Autonomous Capabilities (RAC) 

The collective sensing, perceiving, analyzing, communicating, planning, decisionmaking, and acting/executing capabilities as specified in the Autonomy definition. 

Autonomy Levels for Unmanned Systems (ALFUS) Framework or ALFUS 

The overall structure for ALFUS, including the Terms and Definitions, the Metric Model, the 

Executive model, and the associated autonomy evaluation guidelines and processes, with the 

Contextual Autonomous Capability (CAC) model as a central concept. 

Associated terms: 

ALFUS Levels 

A general term referring to the Framework levels, namely Level of Autonomy (LOA) or 

levels of Human Independence (HI), levels of Mission Complexity (MC), levels of 

Environmental Complexity (EC), or other types of indices that are derived within 

ALFUS <6.1>. These levels provide high level, summary perspectives of autonomy and 

complement the detailed, metric perspectives. 

Executive/Summary Model for ALFUS 

Equivalent to ALFUS Levels <6.1>. 

Level of Autonomy (LOA) or Autonomy Level 

A set of progressive indices, represented by alphanumeric characters, used to identify a 

UMS’s capability of performing assigned autonomous missions independent of HRI. 

Equivalent to the HI aspect of the Executive/Summary Model for ALFUS.

Built-in Test 

Equipment or software embedded in the operational components or systems, as opposed to 

external support units, which perform a test or sequence of tests to verify mechanical or 

electrical continuity of hardware, or the proper automatic sequencing, data processing, and 

readout of hardware or software systems. 

Contextual Autonomous Capability (CAC) Model for Unmanned Systems (UMS) 

A UMS’s CAC is characterized by the missions that the system is capable of performing, 

the environments within which the missions are performed, and human independence that 

can be allowed in the performance of the missions. 

Each of the aspects, or axes, namely, mission complexity (MC), environmental 

complexity (EC), and human independence (HI) is further attributed with a set of 

metrics, or capabilities in the complementary perspective, to facilitate the specification, 

analysis, evaluation, and measurement of the CAC of particular UMSs. 
NIST Special Publication 1011-I-2.0 

17 

This CAC model facilitates the characterization of UMSs from the perspectives of 

requirements, capability, and levels of difficulty, complexity, or sophistication. The 

model also provides ways to characterize UMS’s autonomous operating modes. The 

three axes can also be applied independently to assess the levels of MC, EC, and 

autonomy for a UMS. 

Collaboration or Cooperation 

The process by which multiple manned and/or unmanned systems perform a common 

mission or task synergistically by sharing data, such as coordinates of their maneuver(s) and 

local Common Relative Operational Picture (CROP) and/or by controlling actions together 

<A.1>. 

Associated term:

Coordination 

The ability for UMS’s or manned systems to work together harmoniously. Common 

data such as mission or task plans, coordinates of maneuver(s), local CROP, etc., can be 

shared. A superior can coordinate the task execution of the subordinates to accomplish 

the missions [3]. Two unrelated UMSs can coordinate to negotiate crossing a narrow 

bridge. 

Control Method 

See Method of Control

Cooperation 

See Collaboration. 

Coordination 

See Collaboration - Associated term.

Data Fusion 

See Fusion. 

Dynamic mission planning. 

See mission planning. 

E-Stop or Emergency Stop 

A control action commanded by an operator that removes power to all the moving functions 

and to any other function that, by design, may cause safety hazards. The procedure of the EStop is executed immediately once the command is received. The execution cannot be 

altered and overrides all the other UMS controls. A reset by the operator is required for 

further operations of an E-Stop’ped UMS. E-Stop may not be applicable to all UMSs at all 

times. For example, a UAV may employ an E-stop function only when the UAV is on the 

ground. Explicitly designed procedures are to be executed, instead, upon the occurrence of 

in-flight emergency situations. <A.9>, [46]. 
NIST Special Publication 1011-I-2.0 

18 

Environment 

The surroundings of a UMS. The environment can be aerial, ground, or maritime. It includes 

generic and natural features, conditions, or entities such as weather, climate, ocean, terrain, and 

vegetation as well as man-made objects such as buildings, buoys, and vehicles. It can be static or 

dynamic, can be further attributed in terms of its complexity, and can be described as 

friendly/hostile/benign, safe/dangerous, easy/difficult, etc. The significant aspects of the 

environment are those that the UMS and the operator are interested in or aware of. 

Execute 

To Act. To carry out a plan, a task command, or another instruction [3]. 

Executive/Summary Model for ALFUS 

See Autonomy Levels for Unmanned Systems (ALFUS) Framework or ALFUS - 

Associated terms. 

Fault Tolerance 

The ability of a system or component to continue normal operation despite the presence of 

hardware or software faults {14}. 

Fully Autonomous 

See Mode of UMS Operation- Associated terms.

Fusion or Information Fusion or Data Fusion

Information processing that deals with the acquisition, filtering, correlation, comparison, 

association, and combination/integration of data and information from single and multiple 

sources to support UMS objectives of recognition, tracking, situation assessment, sensor 

management, system control, identity estimation, as well as complete and timely assessments 

of situations and threats and their significance in the context of mission operation. The 

processes can involve UMS onboard computing resources, externally provided information, 

and human input. The process is characterized by continuous refinement of its estimates and 

assessments, and by the evaluation of the need for additional sources, or modification of the 

process itself, to achieve improved results [7, 8, 13]. 

Fusion Levels or Levels of Fusion 

Each of the following six levels of fusion progressively adds meaning at higher levels of 

abstraction and involves more analysis [5, 9]: 

• Level 0 - organize. This is the initial processing accomplished at or near the sensor that 

organizes the collected data into a usable form for the system or person who will receive 

it. 

• Level 1 - identify/correlate. This level takes new input and normalizes its data; correlates 

it into an existing entity database, and updates that database. Level 1 Fusion tells you 

what is there and can result in actionable information. 

• Level 2 - aggregate/resolve. This level aggregates the individual entities or elements, 

analyzes those aggregations, and resolves conflicts. This level captures or derives events 

or actions from the information and interprets them in context with other information. 

Level 2 Fusion tells you how they are working together and what they are doing. 
NIST Special Publication 1011-I-2.0 

19 

• Level 3 - interpret/determine/predict. Interprets enemy events and actions, determines 

enemy objectives and how enemy elements operate, and predicts enemy future actions 

and their effects on friendly forces. This is a threat refinement process that projects 

current situations (friendly and enemy) into the future. Level 3 Fusion tells you what it 

means and how it affects your plans. 

• Level 4 - assess. This level consists of assessing the entire process and related activities 

to improve the timeliness, relevance, and accuracy of information and/or intelligence. It 

reviews the performance of sensors and collectors, as well as analysts, information 

management systems, and staffs involved in the fusion process. This process tells you 

what you need to do to improve the products from Fusion Levels 0-3. 

• Level 5 - visualize. This process connects the user to the rest of the fusion process so that 

the user can visualize the fusion products and generate feedback/control to 

enhance/improve these products. 

Goal 

(A) A result or state to be achieved or maintained [3]. 

(B) The purpose toward which an endeavor is directed {37}. 

Hazard Avoidance 

UMS’s function of avoiding any physical objects or other adversarial situations, as either 

assessed by the UMS’s perception functions or provided through the HRI, that may oppose 

or deter passage or progress, impede the UMS’s mobility in any other way, or cause any form 

of harm. 

Human/Operator Intervention 

The need for Human Interaction in a normally fully autonomous behavior due to some 

extenuating circumstances. An unanticipated action or input by a human required to 

complete a task. 

Human Independence (HI) 

Complementary to HRI, a situation in which a UMS is performing a mission without HRI. It 

is one aspect of the three-aspect ALFUS Metric Model. 

Human Robot Interaction/Interface (HRI) or Human Interaction, Operator 

Interaction 

(A) The activity by which human operators engage with UMSs to achieve the mission 

goals. 

(B) The architecture for interaction between the robot and the human. It includes the 

specification of the interaction language: what tasks the user can ask of the robot and the 

corresponding actions, what tasks the robot can ask of the user and the corresponding actions. 

It is independent of a particular display or interaction modality. It is the planned and 

anticipated interactions between the robot and the user. 

(C) The physical realization of the method of Human Robot Interaction or Intervention.

The following are the different roles of interaction possible for the human in HRI. Note that 

one person could possibly assume a number of roles or numerous people could take 
NIST Special Publication 1011-I-2.0 

20 

individual roles or even share roles. The user interface should be based on the types of roles 

the user will assume. In addition to specific information needed for each role, the user will 

need some awareness of other roles simultaneously interacting with the robot. 

Supervisor 

The supervisor monitors one or more robots with respect to progress on the mission, can 

task the robot(s) at the mission level, monitors mission progress, provides mission level 

directions, coordinates missions, and can assign an operator to assist a robot if needed. 

A commander would be an example of a person who performs the supervisor-only role. 

Teammate/Wingman

This is considered to be a human team member. UMS and its teammate each performs 

part of the overall mission and coordinate when needed. The teammate may command 

the UMS at the levels of detail of tasks or task plans. 

Operator

This is the role assumed by the person performing remote control or teleoperation, 

semi-autonomous operations, or other man-in-the-loop types of operations. The 

operator input is expected at certain states during normal operations. During error 

conditions, the operator determines the problem that a robot is experiencing in interacting 

with the physical world, interacts with the robot to solve this if possible and returns 

control to the supervisor with an outcome, successful or not. If the operator cannot 

overcome the problem, it may be necessary to pass the robot control to the mechanic. 

Mechanic or Developer 

This role determines the problem with the hardware or software that the robot is having, 

solves this if possible, may interact with the robot to test out the proposed solution, and 

returns control of the robot to the supervisor with a determination. 

Bystander

The role coexists in the same environment as the UMS but with an unknown intent. The 

bystander role could be neutral, friendly, or adversarial, or include various combinations. 

The bystander and the UMS need to build some expectation of what the counterpart will 

do in order to react accordingly. For example, the driver, a bystander, of a car may have 

to interact at a four way stop with a UMS. They both need some indication as to whether 

the other vehicle knows the rules of the road. 

Pedestrians and traffic police would be examples of bystanders who would have limited 

interaction with autonomous driving vehicles. The UMS needs to be able to protect itself 

from possible harm from adversarial bystander. 

The following list the associated terms with HRI: 

Human-Operated 

The type of HRI that refers to remote control or teleoperation. 
NIST Special Publication 1011-I-2.0 

21 

Human-Assisted 

The type of HRI that that refers to situations during which human interactions are needed 

at the level of detail of task plans, i.e., during the execution of a task. 

Human-Delegated 

The type of HRI that refers to situations during which human interactions are mainly at 

the task level. 

Human-Supervised 

The type of HRI that refers to situations during which humans play the monitoring role 

and human interactions are mainly at the mission level. 

Information Fusion 

See Fusion. 

Intelligence in Unmanned Systems (UMSs)

Possession of and the ability to exercise CAC in the UMS.

Interoperability

The ability of software or hardware systems or components to operate together successfully 

with minimal effort by end user. Further attributed with functional, behavioral, lifecycle, and 

architectural scopes, and, therefore, can be delineated in terms of control and can be 

categorized into levels, types, or degrees in application programs. Facilitated by common or 

standard interfaces [12, 24].

Leader Follower 

See Robotic Follower – Associated term. 

Level 

Relative position or rank on a scale. 

Level of Autonomy 

See Autonomy Levels for Unmanned Systems (ALFUS) Framework - Associated 

terms. 

Level of Control 

See Section 3, Levels of Control (UMS). Levels of Control (UMS/Remotely Operated 

Systems).

Marker 

An aid used to mark a designated point for such operational purposes as route following, 

determination of bearings, courses, or location, and identification of key items or points of 

interest, including landmine markers and area Chemical, Biological, Radiological, or Nuclear 

(CBRN) decontamination markers. Traffic signs and signals are additional examples of 

Markers. The aid can be visual, electronic, or of other types. 
NIST Special Publication 1011-I-2.0 

22 

Metric 

An identified characteristic used to measure a particular attribute of a subject, such as how a 

defined goal fits a user’s needs and whether the system generates required results; a metric 

can be subjective or objective. 

Method of Control 

The interface, either software or hardware, such as a joystick, waypoint selection via a map 

interface, natural language, hand signals, etc., that operators use to control a UMS.

Mission 

The highest-level task assigned to a UMS {3}. 

Mission Module 

A self-contained subsystem installed on a UMS that enables the UMS to perform designed 

missions. It can be easily installed and replaced by another type of mission module [2]. 

Mission Planning 

The process of generating tactical goals, a route (general or specific), commanding structure, 

coordination, and timing for a UMS or a team of UMSs. The mission plans can be generated 

either in advance or in real-time. They can be generated by operators on OCUs or by the 

onboard software systems in either centralized or distributed ways. The term dynamic 

mission planning [2, 3] can also be used to refer to onboard, real-time mission planning.

Mobility 

The capability of a UMS to move from place to place, under its own power and under any 

mode or method of control. The characteristics of Mobility include the UMS’s speed, 

targeted location, and fuel availability [2]. Refueling could be performed either as a part of 

the HRI or autonomously by a fuel management autonomy task at a higher level. 

Mode 

A particular form or manner. 

Mode of Operation for Unmanned Systems, Mode of Unmanned System Operations, 

or Unmanned System Operational Mode <A.8> 

Human operator’s ability to interact with a UMS to perform the operator assigned missions. 

The following are the defined modes: fully autonomous, semi-autonomous, teleoperation, 

and remote control. 

Associated terms: 

Fully Autonomous 

A mode of UMS operation wherein the UMS accomplishes its assigned mission, within 

a defined scope, without human intervention while adapting to operational and 

environmental conditions.
NIST Special Publication 1011-I-2.0 

23 

Semi-Autonomous 

A mode of UMS operation wherein the human operator and/or the UMS plan(s) and 

conduct(s) a mission and requires various levels of HRI [2] <A.3>. The UMS is capable 

of autonomous operation in between the human interactions. 

Teleoperation 

A mode of UMS operation wherein the human operator, using sensory feedback, either 

directly controls the actuators or assigns incremental goals on a continuous basis, from a 

location off the UMS [2]. 

Remote Control 

A mode of UMS operation wherein the human operator controls the UMS on a 

continuous basis, from a location off the UMS via only her/his direct observation {2}. In 

this mode, the UMS takes no initiative and relies on continuous or nearly continuous 

input from the human operator.

Observation6 

Detection or measurement of the environment and production of analyzable information. 

Obstacle7 

Any physical entity, physical phenomenon, or marked physical area that opposes or deters 

passage or progress, or impedes mobility of a UMS in any way <6.3>. 

Operator Control Unit (OCU) 

Also referred to as operator control interface (OCI) or human interaction control unit. 

The computer(s), accessories, and data link equipment that an operator uses to control, 

communicate with, receive data and information from, and plan missions for one or more 

UMSs {2}. 

Orientation6 

Analysis and comprehension of observed data and generation of prediction and other 

information to support decision-making process. 

Perception 

A UMS’s capability to sense and build an internal model of the environment within which it 

is operating, and to assign entities, events, and situations perceived in the environment to 

classes. The classification (or recognition) process involves comparing what it observed with 

the system’s a priori knowledge8

 [3]. 

Associated term: 

 

6

 A stage in the OODA loop (Observation, Orientation, Decision, Action), conceived by Col. John R. Boyd 

in the 1970s as an air-to-air combat strategy for military fighter pilots. 

7

 See section 3 for Defense extension. 

8

 Similar to the combination of Observation and Orientation as used in ACL. 
NIST Special Publication 1011-I-2.0 

24 

Local perception 

When the perception process has occurred locally onboard the UMS and is regarding the 

UMS’s local environment and within the UMS’s mission context. 

Perception Levels or Levels of Perception [3] 

The progressive results of sensory information after multiple levels of sensory processing: 

• Level 1 – point or pixel, a point of concern that has physical properties which, in turns, 

can quantitatively be either measured with the systems’ sensor(s) in a one-to-one 

correspondence or computed over time and space. 

• Level 2 – line or list. Formed by groupings of sets of points according to certain criteria, 

such as continuity in position and direction over space and/or time. 

• Level 3 – surface or boundary. Formed by groupings of sets of contiguous lines or lists 

according to certain criteria, such as continuity in orientation or curvature over space 

and/or time. 

• Level 4 – object. Formed by groupings of sets of contiguous surfaces and boundaries 

according to certain criteria, such as rigid body mechanics, over space and/or time. 

• Level 5 – unit of objects. Formed by groupings of sets of objects according to certain 

criteria, such as density, distribution, and relative positions, motions, and interactions, 

over space and/or time. 

Point Man or Unmanned Point Man, Robotic Point Man 

(A) A human (soldier in the military domain) assigned some distance ahead of a patrol as a 

lookout. 

(B) The capability of a UMS to perform tasks analogous to a human point man. 

Prognostic Health Management 

System using artificial intelligence or other intelligent algorithms and a combination of 

sensors and models of systems to autonomously react to environmental changes and monitor 

the operational and maintenance characteristics of the system(s) under consideration [16]. 

Remote Control 

See Mode of UMS Operation - Associated terms. 

Remotely Guided 

See Remote Control. 

Robot9 

A powered physical system designed to be able to control its sensing and action for the 

purpose of accomplishing assigned tasks in the physical environment. A robot includes its 

associated HRI [4] <6.2>. 

 

9 See section 6.2 for rationale.
NIST Special Publication 1011-I-2.0 

25 

Robotic Follower 

The capability of a UGV to traverse a safe, tactically relevant route previously traversed by 

another vehicle (leader) <A.5>. The follower vehicle traverses the route automatically (i.e., 

under computer control using onboard sensors) with potentially significant physical or 

temporal separation from the leader. This capability takes advantage of human sensing and 

reasoning in the lead vehicle to reduce the perception and intelligence requirements for the 

follower vehicle. The follower vehicle may incorporate some limited perceptual capabilities 

to detect and avoid new obstacles that appear after the lead vehicle has passed {10}. 

Associated term: 

Leader Follower 

The UGV team that operates as described in Robotic Follower. 

Root Autonomous Capabilities (RAC) 

See Autonomy - Associated terms.

Self-Diagnosis 

Ability to adequately take measurement information from sensors, validate the data, and 

communicate the processes and results to other devices {18}. 

Self-Healing 

Automated or semi-automated capability of system repair, covering the infrastructure, 

hardware, and software aspects [17]. 

Semi-Autonomous 

See Mode of UMS Operation - Associated terms.

Sense 

Use of a sensor to acquire information about an object or a physical phenomenon. 

Sensor 

Equipment that detects, measures, and/or records signals, stimuli, or any other physical 

phenomena by means of energy or particles emitted, reflected, or modified by certain objects 

and activities [19].

Sensor Fusion 

(A) Same as fusion except limiting data source to sensors. 

(B) A process in which data, generated by multiple sensory sources, is integrated and/or 

correlated to create information, knowledge, and/or intelligence that may be displayed for 

user or be actionable to accomplish the tasks. The fusion capabilities include Detection, 

Classification, Recognition, and Identification [9]. 
NIST Special Publication 1011-I-2.0 

26 

Sensory Processing 

Function or set of UMS software processes that operate on sensor signals to compute the 

characteristics of the world, to detect, identify, and classify entities, events, and situations, 

and to derive other useful information about the world. These processes can be hierarchically 

laid out to produce a series of intermediate outputs with different levels of abstraction and 

different spatial and temporal resolutions. The output of one process provides input for the 

process’s adjacent, downstream process. Sensory Processing can also include processes that 

are horizontally laid out with assigned focuses. All the intermediate output may be useful to 

the UMS operations [3]. 

The following are ways to organize the progressive sensory processes, to perceive the 

resulting information, and to structure the knowledge and intelligence: 

• Levels of Fusion - see Fusion Levels

• Levels of Perception see Perception Levels

Situational Awareness 

The perception of UMSs in the environment within a desirable volume of time and space, the 

comprehension of perceived situations, and the projection of the UMSs’ status in the future. 

In generic terms, the three levels of situational awareness are level 1 - perception, level 2 - 

comprehension, and level 3 - projection. There is both individual and group or team 

situational awareness [25]. 

Summary/Executive Model for Autonomy Levels 

See Autonomy - Associated terms. 

System of Systems or Team of Teams

Grouping(s) of unmanned and/or manned systems or teams for a particular mission where a 

team or system is a collection of organized vehicles performing the particular tasks or 

subtasks. 

Tactical Behavior 

The limited, near-term planning, maneuvers, and reactive procedures and actions used to 

adapt the execution of higher level, long term mission goals to both the corresponding 

environmental and the operational conditions. 

See section 3 DEFENSE ORIENTED TERMS OR EXTENSIONS. 

Task 

A named activity performed to achieve or maintain a goal. Mission plans are typically 

represented by tasks. Task performance may, further, result in subtasking. Tasks may be 

assigned to operational units via task commands [3]. 

Associated Term: 

Skill 

The lowest level task. 
NIST Special Publication 1011-I-2.0 

27 

Task Decomposition 

A method for analyzing missions and tasks and decomposing them into hierarchical subtask 

structures according to the criteria of command/authority chain, control stability, 

computational efficiency, and management effectiveness [3]. 

Teaming 

(A) The linking together of platforms, forces, or systems to complete a mission or task

collectively that would be more difficult to do if the units acted separately. The process is 

characterized by distributed operations and quick maneuvers, which demands rapid 

synchronization, swift adaptation of plans and control measures, flexible groupings of 

distributed staff elements, and direct exchanges between commanders across hierarchies. For 

example, manned and unmanned platforms can be teamed to emphasize their complementary 

strengths. The unmanned systems have the further requirements of being able to easily and 

quickly communicate their intentions, goals, present state in the accomplishment of these 

goals, intended next action, and current problem areas. Additionally, they have to be retasked easily to participate in the current overall goal and to fit into their new position in the 

organizational structure. The above is critical if they are to perform effectively in team 

activities [19]. 

(B) A method of operation where a system uses the combined sensing, information exchange, 

decision-making, and acting capabilities of humans and robots function together to carry out 

missions within the planned scope. 

In the situations of manned – unmanned Teaming, air-to-ground teaming means that the 

manned system is in the air with UMS on the ground. Similarly, there could be air-to-air, 

ground-to-ground, and ground-to-air types of teaming. 

Teleoperation. See Mode of UMS Operation - Associated terms.

Telepresence 

The capability of a UMS to provide the human operator with some amount of sensory 

feedback similar to that which the operator would receive if she/he were in the vehicle {2}. 

Terrain 

The physical features of the ground surface, including both natural features, such as valleys 

and hills and manmade features, such as roads and fences. Includes subsurface, such as 

tunnels, underground structures, and the bottom of the streams. Major terrain types are 

delineated based upon local relief, or changes in elevation, and include: flat, rolling, hilly, and 

mountainous. Additional characteristics include: hydrologic features, such as swamps; 

vegetation characteristics, such as forests; and cultural features, such as cities. The 

trafficability of the terrain is classified as: unrestricted, restricted, and severely restricted 

[26, 38]. 

Terrain Visualization 

A component of battlefield visualization that provides a detailed understanding of the 

background upon which enemy and friendly forces and actions are displayed. Terrain 

visualization provides common terrain background for all users and all applications. 
NIST Special Publication 1011-I-2.0 

28 

Additionally, terrain visualization allows interactive planning and mission rehearsal. Terrain 

visualization includes both natural and man-made features to include impacts of terrain on 

vehicle speed, maintenance, river-crossing operations, cross-country trafficability, and 

maneuverability. Terrain visualization includes the subordinate elements of data acquisition, 

analysis, database management, display, and dissemination. Derived from [22, 27]. 

Tether 

A physical communications cable, fiber optic or other that connects a UMS and its OCU and 

restricts the range of operation of the UMS to the length of the cable. Some tethers include 

power [2]. 

Threat Avoidance 

Ability to detect/degrade/defeat threats. The continual process of compiling and examining 

all available information concerning threats in order to avoid encounter <6.3>. 

Unattended Ground Sensors (UGS) 

Small, low cost, robust sensors, capable of operating in the field for extended periods of time 

(30 days or more). They consist of modular groups of sensors utilizing configurable ground 

sensing technologies, such as seismic, magnetic, infrared, acoustic, radio frequency, and 

Chemical, Biological, Radiological, Nuclear, or Explosive (CBRNE) detection, and other 

advanced sensing capabilities. UGSs may self-organize into a networked sensor array 

(sensor web) by locating the most efficient gateways for transmission of information. The 

resulting network may be self-healing, able to quickly bypass a neutralized gateway and 

locate a functional one within the sensor web. 

Unattended System 

Any manned/unmanned, mobile/stationary, or active/passive system, with or without power 

that is designed to not be watched, or lacks accompaniment by a guard, escort, or caretaker. 

Unmanned System (UMS) 

A powered physical system, with no human operator aboard the principal components, 

which acts in the physical world to accomplish assigned tasks. It may be mobile or 

stationary. It can include any and all associated supporting components such as OCUs. 

Examples include unmanned ground vehicles (UGV), unmanned aerial vehicles/systems 

(UAV/UAS), unmanned maritime vehicles (UMV)--unmanned underwater vehicles 

(UUV) or unmanned water surface borne vehicles (USV)--unattended munitions (UM), 

and unattended ground sensors (UGS). Missiles, rockets, and their submunitions, and 

artillery are not considered the principal components of UMSs [2] <6.2>. 

Associated Term: 

Logical UMS (LUMS)

(A) A software or otherwise conceptual model of a UMS, as in simulation or in other 

design or analysis tools. 

(B) Inherently non-physical, i.e., software entities that either operate as independent 

entities and interact with their associated UMSs or are integral parts of a UMS in an 
NIST Special Publication 1011-I-2.0 

29 

inclusive context. Includes high-level computer control and management software 

systems that command and coordinate the low-level UMSs, for example, a shop floor 

control node in a flexible manufacturing system. 

Unmanned Wingman, Robotic Wingman

(A) A UMS subordinate to and in support of the designated team leader [13]. 

(B) The wingman concept assists the leader in the command and control of the system. 

During operations, the robotic wingman orients itself on the section leader and, in the absence 

of orders, moves, stops, and shoots when his leader does. Anytime the wingman of a section 

is engaged or begins an engagement, the section leader supports the wingman’s effort {23}. 

Waypoint 

An intermediate location through which a UMS must pass, within a given tolerance, en route 

to a given goal location {2}. 

World Model (WM) 

The subject system’s internal representation of the portions of the environment that the 

system is aware of or that are of interest to the system and the operator from the goal 

perspective. The WM includes models for the system itself and entities in the environment, 

such as maps, images, situations, relationships, task knowledge, and other categories of 

knowledge. The WM may be static or dynamic, may be complete or incomplete but its 

contents are associated with various levels of confidence, may be related to and interact with 

each other in certain ways, and may contain certain attributes to either positively or 

negatively affect the system tasks. At lower LOAs, the UMS’s operations are enabled 

to lesser extents by the UMS’s WM and to greater extents by the operator’s [3]. 

Associated term: 

World Modeling

Function or process of constructing and maintaining a world model, using a series of 

software processes that can be hierarchically laid out to produce a series of intermediate 

outputs with different levels of abstraction and different spatial and temporal resolutions. 

The output of one process provides input for the process’s adjacent, downstream process. 

World Modeling can also include processes that are horizontally laid out with assigned 

focuses. All the intermediate output may be useful to the UMS operations [3]. 
NIST Special Publication 1011-I-2.0 

30 

3 DEFENSE ORIENTED TERMS OR EXTENSIONS 

Classes of UGVs

The DOD Joint Robotics Program (JRP) postulates several classes of UGVs, based on weight 

{2}, <A.2>: 

• Micro: < 8 pounds (3.6 kg)10

• Miniature: 8 lb to 30 lb (3.6 kg to 13.6 kg) 

• Small (light): 31 lb to 400 lb (14.1 kg to 181.8 kg) 

• Small (medium): 401 lb to 2 500 lb (182.3 kg to 1136.4 kg) 

• Small (heavy): 2 501 to 20 000 lb (1136.8 kg to 9090.9 kg) 

• Medium: 20 001 to 30 000 lb (9091.4 kg to 13636.4 kg) 

• Large: >30 000 lb (13636.4 kg) 

Common Operational Picture (COP) 

A single identical display of relevant information shared by more than one command; to 

facilitate collaborative planning and assist all echelons to achieve situational awareness [13]. 

Cooperative Engagement 

A method of engagement for destroying enemy forces, employing sensors and shooters not 

resident on the same platform [25]. 

Levels of Control (UMS). Levels of Control (UMS/Remotely Operated Systems) 

Control of UMS or remotely operated systems is the authority granted to an entity (operator) 

to exercise commands to such a system, its subsystems, and subordinate systems to 

accomplish a given mission. Although based on the Tactical Control System (TCS) ORD, 

which defines UAV control levels, and the Levels of Interoperability within NATO 

Standardization Agreement (STANAG) 4586 (UAV Control), it is broadened to address all 

UMS and the Remote operations of Manned Ground Vehicles (MGV). These authorities will 

be assigned in five levels: 

(a) Level One is the indirect receipt and direct retransmission of imagery and/or data from a 

remote system. 

(b) Level Two is the receipt of imagery and/or data directly from the UMS/remotely 

operated system and the functionality of previous level. 

(c) Level Three is the control of the UMS/remotely operated system's mission equipment 

packages, sensors or payloads and the functionality of previous levels. 

(d) Level Four is full functionality and control of the UMS/remotely operated system, 

including mobility and the functionality of previous levels, less program specific special 

authorization, such as safety and security related (e.g. Launch and recovery of UMS where 

special training or equipment is required). 

 

10 NIST endorses SI units. However, since the definition is adopted, in its entirety, from the cited 

reference, the usage of British units is retained. 
NIST Special Publication 1011-I-2.0 

31 

(e) Level Five is all inclusive, full functionality and control of an UMS from start through 

completion (including launch and recovery).

Note: The delineation of a given level of control does not preclude the withholding of certain 

elements of that level for safety, procedural or training purposes. 

Point and Shoot 

A subset of cooperative engagement that allows a soldier or platform to designate a target 

for lethal engagement by another platform. The information is immediately displayed on the 

COP. Point and Shoot implies the immediacy of effects and generally occurs within the same 

echelon. 

Obstacle 

Any obstruction designed or employed to disrupt, fix, turn, or block the movement of an 

opposing force, and to impose additional losses in personnel, time, and equipment on the 

opposing force [13]. 

Scout 

Also referred to as unmanned scout or robotic scout: 

1. A person, aircraft, or ship sent out to obtain information, especially in preparation for 

military action {13}. 

2. The capability of an unmanned system to perform tasks analogous to a human scout. 

Sensor to Shooter 

(A) The information link from a target acquisition capability to the weapons platform(s) that 

engage(s) the target [19]. 

(B) Movement of appropriately formatted information from the reconnaissance platform to 

the attacking weapon system [21]. 

Tactical Behavior 

The limited, near-term planning, maneuvers, and reactive procedures and actions used to 

adapt the execution of higher level, long term mission goals to the corresponding 

environment and the force situation while providing own unit (single or multiple elements) 

security and concealing mission intent from opposing forces. 

Threat Levels 

The relative ability of an enemy, or potential enemy, to limit, neutralize, or destroy the 

effectiveness of the current or projected mission, organization, or equipment. 

Unmanned Rear Guard or Robotic Rear Guard 

(A) The rearmost elements, humans or UMSs, of an advancing or a withdrawing force. It has 

the following functions: to protect the rear of a column from hostile forces; during the 

withdrawal, to delay the enemy; during the advance, to keep supply routes open. 
NIST Special Publication 1011-I-2.0 

32 

(B) Security detachment that a moving ground force details to the rear to keep it informed 

and covered {13}. 
NIST Special Publication 1011-I-2.0 

33 

4 SEARCH AND RESCUE (SAR) ORIENTED TERMS OR EXTENSIONS 

Advisory 

(A) Formal notification by DHS/FEMA to all task forces that an event is imminent or has 

occurred but does not require action at this time [36]. 

(B) Lowest level of notification, used to provide information only. An advisory is issued 

when conditions have the potential to develop into a disaster. No action is expected of the 

task force. Advisories provide a means for sharing information concerning incidents, events, 

or response activities being conducted by other Federal departments and agencies that may or 

may not result in broader Federal support [33].

Cache 

An approved complement of tools, equipment, and supplies stored in a designated location, 

available for emergency use [36]. 

Collapse Hazard Zone 

The area established by the Government responding team for the purpose of controlling all 

access to the immediate area of a collapse or a suspected collapse [36]. 

Designated Area 

The area identified in the major disaster declaration which is eligible to receive disaster 

assistance in accordance with the provisions of Public Law 93-288. Also referred to as the 

affected area [33].

Mobilization Time Frame 

The time in which a task force is expected to assemble at the point of departure (POD). Six 

hours is the identified time frame [33].

Urban Search and Rescue (US&R, USAR) 

(A) The strategy, tactics, and operations for locating, providing medical treatment to, and 

extricating entrapped victims of structural collapses or any other types of disasters [33]. 

(B) A FEMA task force equipped with necessary tools and equipment and the required skills 

and techniques for the search, rescue, and medical care of victims of structural collapse [34].
NIST Special Publication 1011-I-2.0 

34 

5 PROPOSED MANUFACTURING ORIENTED TERMS OR EXTENSIONS 

It is anticipated that the generic aspects of the ALFUS Framework would be applicable to the 

manufacturing area. Given the size, rich history, and ongoing research and development efforts 

of the manufacturing industry, there is an abundant amount of vocabulary that is either existent or 

evolving. Examples include Agile Manufacturing, Computer-Aided Manufacturing 

(CAM), and Autonomously Guided Vehicles (AGVs). Nevertheless, there are terms that 

can be explored from the UMS perspective as the industry is more and more moving toward 

autonomous operations and intelligent manufacturing for improved safety and productivity. 

Terms that might correspond to industrial practices include Unmanned Manufacturing 

System (UMMS), Unmanned Flexible Manufacturing System (UFMS), and 

Unmanned Workstation (UWS). Practitioners are using the term Next Generation 

Robots, although with different meanings such as higher payloads or inherent safety design. 

Dynamic Perception is required for Autonomous Parts Assembly on the shop floor. 

These conceptual systems are anticipated to involve the same ALFUS issues in 

mission/operational complexity, environment complexity, and human independence and should 

be worthy of further exploration within the ALFUS framework. 
NIST Special Publication 1011-I-2.0 

35 

6 RATIONALES FOR TERM DEFINITIONS 

6.1 Executive Model for Autonomy Level 

It is not defined as linear from one level to the next. In ALFUS, the summaries of the metrics 

dictate these levels. However, the scales for the metrics are not necessarily linear. A 

suggested guideline could be that, at low levels where technology is ready, the sizes of the 

requirements/functionality gaps between the consecutive levels should be reasonably close. 

However, significant leaps could show at high levels where technologies are not ready. The 

scale can be 0 through 10, 1 through 10, or other ranges. A higher level may or may not 

include the requirements and the functionality of the lower levels. 

6.2 Unmanned System (UMS) 

a. UMS to differentiate from robot in that UMS is not required to have moving components. 

b. powered physical system to exclude passive mechanisms; system can cover any physical 

configuration. A UMS can be an individual UGV as well as a team of vehicles and 

supporting components; however, for the definition of robot, “to be able to control” 

implies powered; 

c. assigned tasks to exclude undesirable or uncontrollable behaviors; 

d. physical environments to exclude a desktop computer running software that is irrelevant 

to UMS operations; 

e. may be mobile or stationary; 

f. currently, commonly seen groupings for robots include service robots—helping human 

tasks at home or work, industrial robots—for manufacturing, military robots, etc. As 

robots are continuously to be applied to new types of tasks, this grouping method could 

change. 

6.3 Obstacle 

Obstacles can be natural, manmade, or a combination of both [13]. They can be positive, 

negative (e.g., ditches), or groupings (e.g., an occupied city), can be moving or still, and can 

have various types of intentions, such as adversarial (enemy force), natural hazard (a hungry 

bear, a tornado), or benign (tree). Except for the benign type, obstacles and threats are 

equivalent. 

6.4 World Model (WM) 

WM is referenced per UMS entity, be it a system, subsystem, or component. An operator 

could be a part of a system in this regard. A remote control only UMS may have no WM

but the operator does. The vehicle’s WM and the operator’s might not always be consistent. 

LOAs and the degrees of complexity of the WM may or may not correlate. 
NIST Special Publication 1011-I-2.0 

36 

7 ACRONYMS 

Acronym Meaning Reference 

4D/RCS 

NIST 4D/Real-time Control 

System Reference Model 

Architecture 

http://www.isd.mel.nist.gov/projects/rcs/ 

AATD Aviation Applied Technology 

Directorate, U.S. Army 

ACL Autonomous Control Levels 

ACTD Advanced Concept Technology 

Demonstration 

AFRL Air Force Research Laboratory http://www.afrl.af.mil/ 

ALFUS Autonomy Levels for Unmanned 

Systems 

AMRDEC 

(Army) Aviation and Missile 

Research, Development and 

Engineering Center 

http://www.redstone.army.mil/amrdec/ 

ARL Army Research Laboratory http://www.arl.mil/main/Main/default.cfm 

ATD Advanced Technology 

Demonstrator

ATR Automatic Target Recognition 

BG Behavior Generation http://www.isd.mel.nist.gov/projects/rcs/ 

C3 Command, Control, and 

Communications 

C4ISR 

Command, Control, 

Communications, Computers, 

Intelligence, Surveillance, and 

Reconnaissance 

http://www.fas.org/irp/doddir/dod/c4isr/es.htm 

CAC Contextual Autonomous 

Capability 

CBRNE 

Chemical, Biological, 

Radiological, Nuclear, and 

Explosive

CCI Command and Control Interface STANAG 4586 

CERDEC 

Communication-Electronics 

Research Development & 

Engineering Center 

CAT Crew integration & Automation 

Testbed 

http://www.tacom.army.mil/tardec/ 

COP Common Operational Picture 
NIST Special Publication 1011-I-2.0 

37 

CROP Common Relative Operational 

Picture 

DARPA Defense Advanced Research 

Projects Agency 

http://www.darpa.mil/ 

DCD (Army) Directorate for Combat 

Development 

DHS Department of Homeland Security 

DLI Data Link Interface STANAG 4586 

DoC Department of Commerce 

DOD Department of Defense 

DoE Department of Energy 

DoT Department of Transportation 

EmCon Emission Condition 

EOB Electronic Order of Battle 

EOD Explosive Ordnance Disposal 

ERT Emergency Response Team 

FEMA US&R-2-FG “Urban Search and Rescue 

Response System Field Operations Guide,” Latest 

Version (September 2003 or later)

ERT Evidence Response Team http://www.fbi.gov/hq/lab/ert/ertmain.htm 

FCS Future Combat Systems http://www.boeing.com/fcs 

FHWA (DOT) Federal Highway 

Administration 

FM Field Manual (US Army) 

FOUO For official use only 

FWV Fixed Wing Vehicle 

GCS Ground Control Station STANAG 4586 

HCI Human-Computer Interface 

HMI Human-Machine Interface 

HMMWV High Mobility Multipurpose 

Wheeled Vehicle 

HRI Human-Robot Interface/Interaction 

h hour 

ICAO International Civil Aviation 

Organization 

IED Improvised Explosive Devices 

INL Idaho National Laboratory http://www.inel.gov/ 

IPT Integrated Product (Project) Team 
NIST Special Publication 1011-I-2.0 

38 

ISD NIST Intelligent Systems Division http://www.isd.mel.nist.gov/ 

ISR Intelligence Surveillance, and 

Reconnaissance 

JAUS Joint Architecture for Unmanned 

Systems 

http://www.jauswg.org 

JPO Joint Project Office http://www.redstone.army.mil/ugvsjpo/ 

JRP Joint Robotics Program 

JTA Joint Technical Architecture http://www-jta.itsi.disa.mil/ 

JTA-A Joint Technical Architecture - 

Army 

LADAR Laser detection and ranging 

LOS Line of Sight 

LSI Lead Systems Integrator http://www.boeing.com/fcs 

m meter http://physics.nist.gov/cuu/Units/ 

MANCEN Maneuver Support Center 

METT-TC Mission, enemy, terrain, time - 

troops, civilians 

min minute 

MOE Measure of Effectiveness

ms millisecond 

NAVAIR Naval Air System Command 

NAVSEA Naval Sea System Command 

NBC Nuclear, Biological, and Chemical 

NIST National Institute of Standards and 

Technology 

http://www.nist.gov/ 

NLOS Non-Line of Sight 

NRL Naval Research Laboratory http://www.nrl.navy.mil/ 

OODA Observation, Orientation, 

Decision, Action 

OPSEC Operations Security 

ORD Operational Requirement 

Document 

OSD The Office of the Secretary of 

Defense 

PCD Procurement Control Drawing essentially a specification 

POD Point of Departure 
NIST Special Publication 1011-I-2.0 

39 

RAC Root Autonomous Capability 

ROE Rules of Engagement 

RSTA Reconnaissance, Surveillance, and 

Target Acquisition 

RDECOM (Army) Research, Development, 

and Engineering Command 

s second 

SA Situational Awareness 

SDO Standards Development 

Organization 

SED Software Engineering Directorate http://www.redstone.army.mil/amrdec/directorat

es/sed/index.htm#main 

SI International System of Units http://physics.nist.gov/cuu/Units/ 

SoS System of Systems

SP Sensory Processing http://www.isd.mel.nist.gov/projects/rcs/ 

SSEI System of Systems Engineering 

and Integration

STANAG NATO Standardization Agreement 

T&E Test and Evaluation

TACOM U.S. Army Tank-Automotive and 

Armaments Command 

http://www.tacom.army.mil/ 

TARDEC 

U.S. Army Tank Automotive 

Research, Development and 

Engineering Center 

http://www.tacom.army.mil/tardec/ 

TCS Tactical Control System 

TLX Task Load Index NASA 

TRADOC U.S. Army Training and 

Doctrine Command

TRL Technology Ready Level NASA 

TSM TRADOC Systems Manager 

TTP Tactics, Techniques and 

Procedures. 

UAMBL Unit of Action Maneuver Battlelab 

UARV Unmanned Armed Reconnaissance 

Vehicle 

UAS Unmanned Aircraft Systems 

UAV Unmanned Aerial Vehicle 
NIST Special Publication 1011-I-2.0 

40 

UCAR Unmanned Combat Armed 

Rotorcraft 

http://www.boeing.com/defensespace/military/unmanned/ucar.html 

UCAV Unmanned Combat Air Vehicle http://www.darpa.mil/ucav/index.htm

UGS Unattended Ground Sensors 

UGV Unmanned Ground Vehicle 

UML Unified Modeling Language 

UMS Unmanned System 

US&R, 

USAR Urban Search And Rescue 

USV Unmanned Surface Vehicles 

UUV Unmanned Undersea Vehicles http://www.onr.navy.mil/fncs/auto_ops/default.a

sp 

UVA Unmanned Vehicle Architecture 

UXO Unexploded Ordnance 

VJ Value Judgment http://www.isd.mel.nist.gov/projects/rcs/ 

VRA Vehicle Electronics (Vetronics) 

Reference Architecture 

WM World Model or World Modeling http://www.isd.mel.nist.gov/projects/rcs/ 

WSTAWG Weapon System Technical 

Architecture Working Group 

http://wstawg.army.mil/ 

XUV eXperimental Unmanned Vehicles 

Additional acronyms can be found in http://www.dacs.dtic.mil/topics/acronym/acronyms.shtml. 
NIST Special Publication 1011-I-2.0 

41 

APPENDIX A ONGOING DISCUSSIONS OR UNRESOLVED ISSUES

A.1. Another school of thought argues that, relatively, coordination involves low-level 

interactions, including inform each other’s tasks and avoid conflict. On the other hand, 

cooperation may require, in addition, for the UMSs to work toward a common goal. 

Collaboration may require the highest level of interaction, including intellectual efforts. In 

other words, Cooperation may occur at the task level and Collaboration at the mission

level. However, the majority of the comments within the group favor not distinguishing 

Cooperation and Collaboration.

A.2. Other forums may have looked at other class criteria, loosely based on how much damage 

they could do if they run amok (such as kinetic energy for UAVs). It depends on the 

purposes of the class definitions (the aforementioned one for safety concerns). 

A.3. Subdivisions of Semi-Autonomous – By Exception and Semi-Autonomous – By 

Permission were proposed. While there might have been too much detail in terms of 

categorizing modes of control, these could be very useful in categorizing HRI effects on the 

autonomy levels. 

A.4. In the definition for Autonomy, a suggestion is to define “sensing, perceiving, analyzing, 

communicating, planning, decision-making, and acting/executing” as autonomy enabling 

functions. 

A.5. Robotic Follower: The current implementations focus on the soldier, as opposed to 

another UMS, to be the lead to provide the intelligence to develop the safe and tactically 

relevant path for the UMS to follow. This reduces the sensing, processing, and reasoning 

requirements for the unmanned follower vehicle. Since a soldier has developed the path, it 

should be valid. The only obstacles that the UMS are susceptible to are those that appear 

after the lead vehicle has passed, in which case the follower vehicle has some limited obstacle 

detection and avoidance capabilities. The key is to have the follower traverse the exact same 

path (within a very small lateral deviation) as the lead vehicle. 

As an example, consider open and rolling terrain with tall grass and some trees. A manned 

vehicle is able to maneuver through the terrain relatively easily at tactical cross-country 

speeds. A UMS without a path sees the tall grass and trees as obstacles. It can be traversed, 

but at a much slower speed than a manned vehicle because it cannot easily determine that this 

is a type of obstacle it can drive through. But now given the proven path of the lead vehicle 

and other information (such as speed), the UMS has confidence that the terrain is traversable 

and can exploit this knowledge to increase its speed. This is the concept behind the robotic 

follower, using human intelligence to provide a safe path to increase performance. 

A.6. Should review and possibly include the terms used in the 10 levels in the Army Science 

Board Ad Hoc Study. 

A.7. Mobility class (see environment) needs to be defined? 

A.8. Should Scripted Operation, Automation be defined as another mode of UMS 

operation? Defined as: 
NIST Special Publication 1011-I-2.0 

42 

The machine executes a preloaded or preprogrammed sequence of actions. Does not adapt to 

changes. May have sensors or interlocks for safety reasons. Is not considered a mode of 

UMS operations. 

A.9. E-Stop:

There are different philosophies on how much concern the safety issue should be given with the 

command, i.e., to fully stop immediately, or to stop as safely as possible. Not applicable to UAV, 

which may employ a variety of emergency routines. There may also be no universal definition on 

whether to shut off power to the entire UMS. In factory robots, power is shut off to the drive 

train and the robots are equipped with mechanical interlocks to hold the links and the grippers in 

position. For vehicles, breaks may be actively held in a disengaged position, or else power may 

need to be provided for braking and/or steering if safety is a significant factor. Should the power 

be shut off once the UMS completely stops? Would different types of brakes, antilock or not, 

require different power levels for best E-Stop performance? 

E-Stop performance may be unique in different situations, for example, UMS traversing in 

ice/rain/snow or going up/down a hill. These should be specified in the applications.

A.10. Addition thoughts on Levels of Control 

The American Heritage Dictionary [37] defines Control as: 

• to exercise authority or dominating influence over; direct; regulate; 

• authority or ability to regulate, direct, or dominate. 

 In the area of UMS, Control is defined for the following two perspectives11: 

1. authority given to an outside entity, typically operator [35], to exercise commands to the 

UMS 

2. authority given to a UMS, including any capability built in the UMS to act on the 

environment 

The control can be assigned in terms of levels. The levels can signify and can be differentiated 

by the following factors: 

A. Commanding or organizational level. For example, platoon control is at a higher control 

level than vehicle control; vehicle control is higher than mobility functional control. 

B. Portion/extent of a full control loop to which the control is granted. Examples for a full 

control loop are an Observe, Orient, Decide, and Act (OODA) loop or complete 4D/RCS 

node function including sensory processing, world modeling, value judgment, and behavioral 

generation. The control of only the sensing function is at a lower level than a full control 

loop for mobility tasks. 

C. Degree of complexity of the control function. 

D. Special concerns over such factors as safety, regulations, or equipment requirements. For 

example, special equipment and software may be required to perform the takeoff and landing 

operations of UAVs. This may warrant an elevated control level to conduct those operations. 

The following is a series of reference control levels, from low to high: 

 

11 In addition, authority may be given to system developers or maintainers of a UMS to modify, 

reconfigure, or upgrade of a UMS, either software or hardware. However, this perspective is beyond the 

scope of this Control Level definition. 
NIST Special Publication 1011-I-2.0 

43 

1. for the UMS to receive authorized data only 

2. for the UMS to receive and retransmit authorized data to authorized receivers 

3. for the UMS to receive and retransmit all data to authorized receivers 

4. for the UMS to exercise full control loop on authorized functions of the UMS 

5. for the UMS to exercise full control loop on all functions of the UMS 

6. for the system of systems to exercise full control loop on all functions 

The reference control levels can be further divided, combined, or repeated depending on their 

complexities. For example, # 4 and #5 could be combined for a single-function vehicle. The 

reference control levels can be applied to UMSs with any configuration. For example, #5 may be 

applied to a vehicle and #6 to a section. In this case, there might be a need to insert additional 

intermediate levels between the two levels to account for the partial functional authorization 

situations similar to those defined in #1 through #4. 

Levels of Control do not necessarily directly correspond to Levels of Autonomy. 

The reference control levels are used to define Level of Control for both perspectives of Control: 

Level of Control (1), Level of Operator Control, Level of Operator Authority 

Control of a UMS or a remotely operated system is defined as the authority granted to an entity 

(operator) to exercise commands to the UMS or remotely operated system, its subsystems and/or 

subordinate systems to accomplish a given mission. The authority includes the accessibility to 

the required equipment and software. These authorities are assigned in five levels: 

(a) Level One is the indirect receipt and direct retransmission of imagery and/or other sensory 

data from a UMS/remotely operated system. 

(b) Level Two is the receipt of imagery and/or other sensory data directly from the 

UMS/remotely operated system and the functionality of the previous level. 

(c) Level Three is the control of the UMS/remotely operated system's mission equipment 

packages, sensors or payloads and the functionality of the previous levels. 

(d) Level Four is the full functionality and control of the UMS/remotely operated system, 

including mobility, less takeoff and landing for UAV, and the functionality of the previous levels. 

(e) Level Five is the full functionality and control of a UAV from takeoff to landing. 

Rationale: Although based on the Tactical Control System (TCS) ORD which defines UAV 

control levels, the definition is broadened to address all UMS and the remote operations of MGV. 

At Level Two, “direct” covers the reception of the UMS data through a relay device that has 

direct line-of-sight with the UMS. Level Five is for UAV only due to the fact that special 

concerns, equipment, software, or otherwise are required to perform the takeoff and landing 

operations. Refer also to NATO STANAG 4586 for the correspondences to the definitions of 

Levels of Interoperability. 

Level of Control (2), Level of Systems Control, Hierarchical Systems Control Level 

Is defined by either the hierarchical commanding levels or the logical control structure inside of a 

UMS: 

Level One: Servo control or actuator control 

Level Two: Primitive control or dynamic control 

Level Three: UMS single-functional task control or elementary move control [3] 

Level Four: UMS multi-functional task control or UMS control 
NIST Special Publication 1011-I-2.0 

44 

Level Five: UMS collaborative task control 

Level Six: UMS collaborative mission control 

There could be multiple levels of UMS collaborative task control depending the unmanned 

system of systems structure and, in such cases, UMS collaborative mission control will be higher 

than Level Six. 

Rationale: This corresponds to the 4D/RCS levels, but only addresses autonomy indirectly. 
NIST Special Publication 1011-I-2.0 

45 

REFERENCES 

Note that some DOD documents that serve as references are only cited by particular 

numbers. Readers may contact the author—see the Executive Summary—for specific 

document titles. 

1. Autonomy Levels for Unmanned Systems (ALFUS) Framework Volume I: Terminology, 

Version 1.1, NIST Special Publication 1011, Gaithersburg, Maryland, September 2004. 

2. U.S. DOD OUSD (AT&L) defense Systems/Land Warfare and Munitions, FY2005 Joint 

Robotics Program Master Plan. http://www.jointrobotics.com/. 

3. Albus, J. et al., 4D/RCS Reference Model Architecture, NISTIR 6910, National Institute 

of Standards and Technology, Gaithersburg, Maryland, August 2003. 

http://www.isd.mel.nist.gov/projects/rcs/. 

4. http://www.csgnetwork.com/glossary.html. 

5. Blasch, E and Plano, S., “JDL Level 5 fusion model: user refinement issues and 

applications in group tracking,” SPIE Vol 4729, Aerosense, 2002, pp. 270-279. 

6. U.S. DOD Document #1. 

7. W.A.Sander. Information Fusion. In International Military and Defense Encyclopedia, 

T.N.Dupuy, et al., eds, Vol.3, G-L, pp.1259-1265. Brassey's, Inc., 1993. 

8. Joint Directors of Laboratories (JDL), Technology Panel on C3 (TPC3), Data Fusion 

SubPanel (DFSP). 

9. U.S. DOD Document #2. 

10. U.S. DOD Document #3. 

11. Paraphrased from “Technology Development for Army Unmanned Ground Vehicles”, 

pp. 25-26, Board on Army Science and Technology, The National Academy of Sciences, 

2002. 

12. IEEE 100-2000, The Authoritative Dictionary of IEEE Standards Terms (Seventh 

Edition, 2000) 

13. Joint Publication 1-02, "DOD Dictionary of Military and Associated Terms," 

http://www.dtic.mil/doctrine/jel/doddict/index.html. 

14. Institute of Electrical and Electronics Engineers. IEEE Standard Computer Dictionary: A 

Compilation of IEEE Standard Computer Glossaries. New York, NY: 1990. 

15. Automatic Test Equipment, www.pmforum.org/library/glossary, Wideman Comparative 

Glossary of Project Management Terms v2.1, May 2001. 

16. FMECA Project Website: About the Project, www.fpni.net, Fluid Power Net 

International, 1998. 

17. Towards Architecture-based Self-Healing Systems, Eric M. Doshofy et al, Institute for 

Software Research, WOSS (Workshop On Self-healing Systems) '02, Nov 18-19, 2002, 

Charleston, SC. 

18. Intelligent Sensor, www.allboutmems.com/glossary, All About MEMS 

(MicroElectroMechanical Systems), 2002. 

19. U.S. DOD Document #4.

20. Webster’s New World Dictionary, Third College Edition. 

21. Organizational Concepts for the Sensor-to-Shooter World The Impact of Real-Time 

Information on Airpower Targeting, WILLIAM G. CHAPMAN, Major, USAF School of 

Advanced Airpower Studies. 

22. U.S. DOD Document #9. 

23. U.S. DOD Document #5. 

24. U.S. DOD Document #6.

25. U.S. DOD Document #7. 
NIST Special Publication 1011-I-2.0 

46 

26. U.S. DOD Document #8.

27. U.S. DOD Document #10. 

28. Bruce T. Clough, “Metrics, Schmetrics! How The Heck Do You Determine A UAV’s 

Autonomy Anyway?” Proceedings of the Performance Metrics for Intelligent Systems 

Workshop, Gaithersburg, Maryland, 2002. 

29. Army Science Board, Ad Hoc Study on Human Robot Interface Issues, Arlington, 

Virginia, 2002. 

30. Knichel, David, Position Presentation for the Maneuver Support Center, Directorate of 

Combat Development, U.S. Army, the First Federal Agencies Ad Hoc Working Group 

Meeting for the Definition of the Autonomy Levels for Unmanned Systems, 

Gaithersburg, MD, July, 18, 2003. 

31. James Albus, Position Presentation for National Institute of Standards and Technology, 

Intelligent Systems Division, the First Federal Agencies Ad Hoc Working Group Meeting 

for the Definition of the Autonomy Levels for Unmanned Systems, Gaithersburg, MD, 

July, 18, 2003. 

32. Ryan W. Proud, et al., “Methods for Determining the Level of Autonomy to Design into 

a Human Spaceflight Vehicle: A Function Specific Approach,” 2003 PerMIS Workshop, 

Gaithersburg, MD, September 2003. 

33. FEMA 9356.1-PR “Urban Search and Rescue Response System In Federal Disaster 

Operations: Operations Manual” January 2000. 

34. DHS SAFECOM Program PSWC&I Statement of Requirements Version 1.0, March 10, 

2004. 

35. Scholtz, J.C., Theory and Evaluation of Human-Robot Interaction, Proceedings of the 

Hawaii International Conference on System Science (HICSS), Waikoloa, Hawaiian 6-9, 

2003. 

36. FEMA US&R-2-FG “Urban Search and Rescue Response System Field Operations 

Guide” September 2003. 

37. The American Heritage Dictionary, Second College Edition, Houghton Mifflin Company, 

Boston, MA, 1982. 

38. U.S. DOD Document #11. 

39. ISO 10218-1:2006, Robots for industrial environments -- Safety requirements -- Part 1: 

Robot, with Corrigendum ISO 10218-1:2006/Cor 1:2007

40. ISO 9283:1998, Manipulating industrial robots -- Performance criteria and related test 

methods 

41. ISO 9506-1, Industrial automation systems - Manufacturing message specification - Part 

1: Service definition (2003) 

42. ISO 9506-2, Industrial automation systems - Manufacturing message specification - Part 

2: Protocol specification (2003) 

43. ISO 9409-1;1996, Manipulating industrial robots -- Mechanical Interfaces – Part 1; Plates 

44. ISO 9409-2;1996, Manipulating industrial robots -- Mechanical Interfaces – Part 2; 

Shafts 

45. ISO/TR 13309:1995, Manipulating industrial robots -- Informative guide on test 

equipment and metrology methods of operation for robot performance evaluation in 

accordance with ISO 9283 

46. ANSI/RIA R15.06-1999, American National Standard for Industrial Robots and Robot 

Systems – Safety Requirements