Designation: F2541 – 06

Standard Guide for

Unmanned Undersea Vehicles (UUV) Autonomy and
Control1
This standard is issued under the fixed designation F2541; the number immediately following the designation indicates the year of
original adoption or, in the case of revision, the year of last revision. A number in parentheses indicates the year of last reapproval. A
superscript epsilon (´) indicates an editorial change since the last revision or reapproval.

INTRODUCTION

ASTM has prepared this series of standards to guide the development of autonomous unmanned
underwater vehicles (UUVs). The standards address the key capabilities that a UUV system must
possess in order to be considered autonomous and reconfigurable:
Autonomous—Capable of operating without operator input for extended periods of time. Implicit in
this description is the requirement that the UUV’s sortie accomplishes its assigned goal and makes the
appropriate rendezvous for a successful recovery.
Reconfigurable—Capable of operating with multiple payloads. The top level requirement is
established that the UUV systems will consist of
Payloads to complete specific system tasking such as environmental data collection, area
surveillance, mine hunting, mine countermeasures, intelligence/surveillance/reconnaissance (ISR), or
other scientific, military, or commercial objectives.
Vehicles that will transport the payloads to designated locations and be responsible for the
launch and recovery of the vehicle/payload combination.
While the payload will be specific to the objective, the vehicle is likely to be less so. Nevertheless,
commonality across all classes2 of UUV with respect to such features as planning, communications,
and post sortie analysis (PSA) is desirable. Commonality with regard to such features as launch and
recovery and a common control interface with the payload should be preserved within the UUV class.
In accordance with this philosophy, ASTM identifies four standards to address UUV development
and to promote compatibility and interoperability among UUVs:
F2541 Guide for UUV Autonomy and Control
WK11283 Guide for UUV Mission Payload Interface
F2594 Guide for UUV Communications
F2595 Guide for UUV Sensor Data Formats
The relationships among these standards are illustrated in Fig. 1. The first two standards address the
UUV autonomy, command and control, and the physical interface between the UUV and its payload.
The last two ASTM standards address the handling of the most valuable artifacts created by UUV
systems: the data. Since there are many possibilities for communications links to exchange data, it is
expected that the UUV procurement agency will provide specific guidance relative to these links and
the appropriate use of the UUV communications standard. In a similar manner, specific guidance is
expected for the appropriate use of the UUV data formats and data storage standard.
F2541–Standard Guide for UUV Autonomy and Control—The UUV autonomy and control guide
defines the characteristics of an autonomous UUV system. While much of this guide applies to the
vehicle and how the vehicle should perform in an autonomous state, the relationship of the payloads
within the UUV system is also characterized. A high level depiction of the functional subsystems
associated with a generic autonomous UUV system is presented. The important functional relationship
established in this guide is the payload’s subordinate role relative to the vehicle in terms of system
safety. The payload is responsible for its own internal safety, but the vehicle is responsible for the
safety of the vehicle-payload system. Terminology is defined to provide a common framework for the
discussion of autonomous systems. System behaviors and capabilities are identified that tend to make
a system independent of human operator input and provide varying levels of assurance that the UUV
will perform its assigned task and successfully complete recovery. A three-axis sliding scale is

Copyright © ASTM International, 100 Barr Harbor Drive, PO Box C700, West Conshohocken, PA 19428-2959, United States.

1
 F2541 – 06

FIG. 1 Notional System Interfaces and Governing Standards

presented to illustrate the system’s level of autonomy (LOA) in terms of situational awareness,
decision-making/planning/execution, and external interaction. The control interface (messages ex-
changed between the vehicle and the payload) is described and instantiations of this interface for the
various classes of UUV are presented in associated appendices.
WK11283–Standard Guide for UUV Mission Payload Interface—The UUV mission payload
interface guide is a physical and functional interface standard that guides:
The mechanical and electrical interface between the vehicle and the payload.
The functional relationship between the vehicle and the payload.
In-as-much-as a single physical interface standard cannot address all classes of UUVs, this guide
describes the physical interfaces in the body of the guide and provides a guide to the instantiation for
each of the classes. This guide reinforces the relationship between the vehicle and the payload and
confirms the permission-request responsibility of the payload and the permission-granted/denied
authority of the vehicle.
F2594–Standard Guide for UUV Communications—The UUV communications standard guides
the development of offboard communications between the UUV system and the authorized clients, that
is, those agents designated by the UUV operational authorities with responsibility for programming,
operating, or maintaining a UUV, or a combination thereof. An authorized client may also represent
an end user of UUV and payload mission data. Such a standard is required to provide for UUV
interoperability with multiple authorized agents and to provide the authorized agents with interoper-
ability with multiple UUVs (preferably across the different classes of UUVs). Optical, RF and acoustic
methods of communication are considered. While RF communication is a matured communications
mode and existing standards are referenced and adopted for offboard surface communication,
underwater acoustic communication (ACOMMS) is an evolving field and interoperability between the
different ACOMMS systems is also evolving. Typical ACOMMS systems and protocols are described
with typical applications related to bandwidth and range. General comments are provided for optical
communication as the use of this mode of communication may evolve in the future.

1
This guide is under the jurisdiction of ASTM Committee F41 on Unmanned Maritime Vehicle Systems (UMVS) and is the direct responsibility of Subcommittee F41.01
on Autonomy and Control.
Current edition approved Aug. 15, 2006. Published December 2006. DOI: 10.1520/F2541-06.
2
UUV Master Plan.

2
 F2541 – 06
F2595–Standard Guide for UUV Sensor Data Formats—The UUV sensor data formats guide
provides the UUV and payload designer with a series of commonly accepted data formats for
underwater sensors. These formats provide the opportunity for two-way interoperability. Their use
facilitates the UUV system’s ability to process historical environmental data for mission planning
purposes. Likewise, use of these formats facilitates the end users’ ability to catalog, analyze, and
produce recommendations based on current field data. Fig. 1 suggests that both vehicle-specific data
as well as payload sensor data should be stored in these data formats.

1. Scope Vehicles—outside of the generic function of the Vehicle

1.1 This guide covers the need for UUVs to operate autono-
mously, without constant human intervention, and with flex-
ibility based on their payloads and missions places unique
requirements on UUV developers. Because the UUV commu-
nity is expected to expand both its developer base and its user
base in the next several years, it recognizes that success relies
upon a well-written standard. The standard must encourage
compatibility and reconfigurability, provide a common lan-
guage to describe functional capabilities, and enable meaning-
ful quantitative performance evaluation.
1.2 The scope of this guide includes those characteristics in
a UUV system which, when implemented in a detailed design,
result in a UUV that is capable of operating for extended
periods of time without external intervention. Implicit in this
statement is the requirement that the UUV execute its desig-
nated sortie plan. Non-expendable UUVs must also return to a
rendezvous point for recovery. The top level concept of such an
autonomous system is presented in Fig. 3. The functional
relationships identified in this block diagram will be discussed
further in Section 4.
1.3 This guide contains a table of terminology so that
autonomy and control can be described within the context of a
common language, where all terms have consistent and clearly
defined meaning. As introduced in Fig. 3, this guide defines
high level functional capabilities of the autonomy controller,
the vehicle controller, and the payload controller. Correspond-
ingly high level interfaces are also defined.
1.4 Section 5 presents the capabilities that an autonomous
system is required to have. The table in this section concen-
trates on the functional capabilities of the total system, as
opposed to the capabilities of the component controllers. A
method for verification of the capability is also presented.
1.5 Section 6 presents a set of tables that index the system
autonomy capabilities according to three criteria: Situational
Awareness, Decision-making, Planning, and Control, and Ex-
ternal Interactions. Such a set of qualifiers determines a Level
of Autonomy (LOA) measurement for each of the three
criteria. No attempt is made to combine these disparate
measures into a single index.
1.6 The following are outside the scope of this guide and no
part of this guide should be construed to prescribe requirements
associated with these areas.
Payloads—outside of the generic functions of the Pay-
load controller and the top level interfaces, the design and
implementation of payload subsystems are not addressed in
this guide.
controller and the top level interfaces, the design and imple-
mentation of the vehicle subsystems are not addressed in this
guide.
Safety—this guide does not address safety concerns, if
any, associated with the use of the UUV system. It is the
responsibility of the system designer to establish appropriate
safety and health practices and determine the applicability of
the regulatory limitations prior to use.
Security—this guide does not address security concerns.
It is the responsibility of the program referencing this guide to
establish security mechanisms that are appropriate for the
intended use of the UUV system and the requirements of the
end-user of the system data.
1.7 These standards are intended to support the decision
process for the acquisition and development of non-specific
UUV systems. To the extent that UUV systems are specified,
procured, and developed under a modular open system design
approach, the autonomy standards presented herein will foster
interoperability and reusability within the UUV community.
1.8 This standard does not purport to address all of the
safety concerns, if any, associated with its use. It is the
responsibility of the user of this standard to establish appro-
priate safety and health practices and determine the applica-
bility of regulatory limitations prior to use.
2. Referenced Documents
2.1 ASTM Standards:3
F2594 Guide for Unmanned Undersea Vehicle (UUV)
Communications
F2595 Guide for Unmanned Undersea Vehicle (UUV) Sen-
sor Data Formats
WK11283 Guide for Unmanned Undersea Vehicle (UUV)
Mission Payload Interfaces
2.2 IEEE Standard:4
IEEE 1003.23 IEEE Guide for Developing User Open
System Environment (OSE) Profiles
2.3 NIST Document:5
NIST Special Publication 1011 Autonomy Levels for Un-
manned Systems (ALFUS) Framework, Volume I: Termi-
nology
3
For referenced ASTM standards, visit the ASTM website, www.astm.org, or
contact ASTM Customer Service at service@astm.org. For Annual Book of ASTM
Standards volume information, refer to the standard’s Document Summary page on
the ASTM website.
4
Available from Institute of Electrical and Electronics Engineers, Inc. (IEEE),
445 Hoes Ln., P.O. Box 1331, Piscataway, NJ 08854-1331, http://www.ieee.org.
5
Available from National Institute of Standards and Technology (NIST), 100
Bureau Dr., Stop 1070, Gaithersburg, MD 20899-1070, http://www.nist.gov.

3
 F2541 – 06

NOTE—Internal boundaries between autonomy, vehicle control, and safeties are fuzzy, and different systems will have slightly different boundaries.
FIG. 2 Autonomy and Control Module External Interfaces

FIG. 3 Functional Allocation of Major UUV Autonomy and Control Components

4
 F2541 – 06
2.4 STANAG Standard:6
NATO Standardization Agency (NSA), Standardisation
Agreement (STANAG), STANAG 4586 Edition 2, June
2004
3. Terminology
3.1 The term autonomy and its associated components often
have different interpretations. A first step in the standards
process is to converge on terminology. This terminology is
derived from the NIST Special Publication 1011. The NIST
work focused on generic unmanned systems (UMS) and this
guide is focused on unmanned underwater vehicles (UUV).
Incorporation of the NIST terminology is intended to take
advantage of the groundwork that has already been laid and
extend it to the underwater realm. See Table 1.
4. Functional Allocation
4.1 Functional Decomposition—Identified herein is a func-
tional breakdown of the UUV control system with an attempt
made to draw the interface lines between the functional
components that support maximum ability to have interchange-
able components. High level components:
Vehicle control
Payload control
Autonomous control
On-board safety systems
Communications
Details of each of these are provided below and tabulated in
Table 2.
4.2 Vehicle Control:
4.2.1 Responsibility:
4.2.1.1 Mobility, energy, and navigation subsystems.
4.2.1.2 Maneuvering vehicle as commanded.
4.2.1.3 Operating Subsystems Required for Unmanned Ve-
hicle Control—(1) sensors, ballast systems, propulsion, and
maneuvering subsystems, (2) homing and docking sensors, and
(3) navigation, guidance, and control.
4.2.1.4 Maintaining Vehicle Capabilities Database—
Estimated energy remaining, max/min speed, turn-rates, etc.
4.2.1.5 Monitoring and reporting vehicle/subsystem health
to interested parties.
4.2.1.6 Monitoring and reacting to vehicle subsystem haz-
ard conditions (for example, ground fault) or subsystem
casualties (for example, ballast pump failure).
4.3 Autonomous Control:
4.3.1 Responsibility:
4.3.1.1 Sortie Planning (see LOA)—a priori resource allo-
cation and activity planning, path planning, real-time contin-
gency, and real-time retasking.
4.3.1.2 Sortie Execution/Management (see LOA):
(1) Safe Vehicle Operation—(1) Enforcing sortie con-
straints (for example, operational envelope), (2) updating and
maintaining situational awareness databases, and (3) real-time
obstacle/terrain/contact avoidance.
(2) Resource Monitoring.
(3) Payload Employment.
6
Available from NATO Standardization Agency, North Atlantic Treaty Organi-
zation, 1110 Brussels, Belgium.
5
(4) Oversight and Reporting—Sortie summary file.
(5) Communications and GPS Scheduling.
4.3.1.3 Situation Awareness (see LOA)— Sensor fusion and
monitoring whether achieving sortie goals.
4.4 Payload Control:
4.4.1 Responsibility:
4.4.1.1 Operating Payloads as Directed—Ensuring appro-
priate configuration status.
4.4.1.2 Monitoring and reporting payload health.
4.4.1.3 Situation Awareness (see LOA)—Sensor processing
and sensor fusion.
4.4.1.4 Passing “smart” payload requests for consideration.
4.4.1.5 Safety of payload.
4.4.1.6 Controlling future payloads
4.5 Communications:
4.5.1 Responsibility:
4.5.1.1 Perform all off-board communications,
4.5.1.2 Operation of communications devices and link
maintenance,
4.5.1.3 Tactical message formatting,
4.5.1.4 Encryption/key handling, and
4.5.1.5 Maintain/report link performance estimates
4.6 Onboard Safety Systems:
4.6.1 Responsibility:
4.6.1.1 Hardware Depth Cutoffs—Prevent vehicle from
transiting beyond safe depth.
4.6.1.2 Leaks/Temp/Over/Undervoltage—Prevent cata-
strophic vehicle failure.
4.6.2 Watchdog Functions:
4.6.2.1 Monitor processor integrity and function
4.6.2.2 Monitor critical communication links for integrity
and activity
4.6.2.3 Monitor status and integrity of other critical vehicle
functions
4.7 Fig. 4 provides a high level depiction of a UUV’s
functional subsystems. Also included in this diagram are the
functional interfaces. Functional subsystems require a 1:1
mapping to a hardware subsystem. For example, many current
UUV systems include a single processor incorporating both
autonomous and vehicle control functionality.
4.8 Functional Interfaces—In the effort to standardize UUV
control systems, the high level interfaces between the func-
tional components need to be identified. Table 2 identifies
proposed high level interfaces.
4.8.1 Once the high level interface information can be
agreed upon, the next step down is to identify detailed interface
and message content.
5. UUV Capabilities
5.1 Autonomy and control are becoming ever more impor-
tant components of UUV functionality, and their impact is
expected to be significant in that they will enable many more
uses of UUVs. For autonomy and control to be successful in
their use, there are several high level capabilities that are
required to be standard across all UUVs. These high level
standard capabilities are provided in Table 3. Included in this
table are comments and methods for evaluating the standard.
These standards cover the following functional capabilities.
5.1.1 Re-configurability to support multiple missions.
 F2541 – 06
TABLE 1 Terminology
NOTE 1—Terms are listed in alphabetical order. Terms that have the same roots are grouped together and defined to facilitate consistent definitions.
These terms also appear according to their original alphabetical order without being redefined.
NOTE 2—Boldface is used to indicate the terms defined in this guide.
NOTE 3—Braces { } are used to indicate that the definition is adopted (that is, a direct cut-and-paste or close to it, from the cited reference.
NOTE 4—Brackets [ ] are used to relate the stated definitions to the cited reference(s).
NOTE 5—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)...

Term Definition
Action (A) The effector state of the “OODA Loop” (Observation, Orientation, Decision, Action) where the
Decision is implemented.
(B) A sequence of low-level commands.
(C) A closed-loop control rule composed of a set of sub-system commands (and/or other actions)
with appropriate feedback, designed to maintain and/or achieve specific conditions.
Anomaly Any unanticipated event that requires modification to UUV operations.
Authorized Client An agent designated by the chain of command with responsibility for programming, operating,
and/or maintaining a UUV.
An Authorized Client can be a collaborating partner or other source external to the UUV.
The UUV must be capable of recognizing an authorized client in order to accept input from this
source.
AutonomousA Self-governing {1}. Refers to the operation of an Unmanned Undersea Vehicle (UUV) in response
to its tasking from authorized clients. Factors describing such operation are defined by level of
autonomy
Autonomous Collaboration:B
The ability of a UUV to collaborate with one or more manned vehicles or UUVs without the need
for an external controlling element.
AutonomyA (A) The condition or quality of being self-governing {1}
(B) A UUV’s own ability of sensing, perceiving, analyzing, communicating, planning, decision-
making, and acting, to achieve its goals as assigned by its authorized client(s).
Associated terms:
Autonomy Level or Level of AutonomyA
Set(s) of orthogonal axes, identifying a UUV’s capability for performing autonomous missions. The
following axes are defined for Levels of Autonomy:
Levels of Situation Awareness. See Situation Awareness Levels.
Levels of Decision-making, Planning and Control. See Decision-making, Planning and
Control Levels.
Levels of External Interaction. See External Interaction Levels.
Levels of Collaboration. Collaboration Levels will be added in a future revision to this stan-
dard.
Additional factors, such as tasking complexity and environmental difficulty, affect the rating of the
difficulty of the task, sortie, or mission.
Behavior A series of actions or maneuvers a UUV can perform. Behaviors may be scripted into the sortie
plan or spawned as a response to events which occur during the Sortie.
Built-in TestB Equipment or software embedded in operational components or systems, as opposed to external
support units, which perform a test or sequence of test to verify mechanical or electrical continuity
of hardware, or the proper automatic sequencing data processing, and readout of hardware or
software systems.
Capabilities A description of what the UUV system, with its onboard systems, can do, that is, the immutable
physical and operational characteristics of a particular UUV operation. Capabilities can be defined
at the mission level, that is, what sensor/payload capabilities the UUV brings to bear on the tasks
at hand, or on the tactical level, such as speed, depth turn rate and endurance.
Classes of UUVs The UUV Master Plan postulates four classes of vehicles:
The Man-Portable class, which includes vehicles from about 25 to 100 pounds displacement, with
an endurance of 10 - 20 h. There is no specific hull shape for this class.
The Light Weight Vehicle (LWV) class, which is nominally 12.75 in. in diameter and displaces
about 500 lb. Payload increases six- to twelve-fold over the man-portable class and endurance is
doubled.
The Heavy Weight Vehicle (HWV) class, which is 21 in. in diameter, displaces about 3000 lb, and
provides another factor of two improvement in endurance capability. This class includes UUVs
compatible with torpedo tubes on submarines.
The Large Vehicle class will be approximately 10 long-tons displacement and compatible with
both surface ship (Littoral Combat Ship (LCS)) and submarine (SSNs with hangar or “plug,” and
SSGN) use.
Client. See Authorized Client

5.1.2 Flexibility via standard interfaces to facilitate inter- 5.1.3 Functionality to permit extended periods of unmoni-
connection with various vehicle, sensor, and payload modules. tored operation.

6
 F2541 – 06

TABLE 1 Continued
Term Definition
CollaborationA The process by which multiple manned or unmanned systems jointly work together by sharing
data, (such as coordinates of their maneuvers) and local Common Relevant Operational Picture
(CROP), or by acquiring intelligence to perform a mission synergistically, that is, perform better
than each could have alone.
Associated terms:
Collaboration Levels or Level of Collaboration—Levels to Be Defined in a future revision.
Teaming—To Be Defined.
Command (primitive) A low-level open-loop instruction initiating a sensor, actuator, or processing operation.
Common Relevant Operating Picture. A set of data defining the local environment in which the UUV is operating sufficient to allow col-
(CROP) laboration and/or control of the UUV through authorized clients. Examples of data in the CROP
include location of the UUV, threats, targets, and environmental data.
Concept of Operation (CONOPS). A Concept A document that identifies the operators, organizations, systems, or entities that are employed in
of Operations (CONOPS) the execution of an activity. In addition to identifying the actors, the CONOPS also specifies the
interactions between and among the actors.
Condition A description of the system’s configuration (or state) that may or may not represent reality.
Constraints A prescribed restriction on the set of valid system states. Constraints may apply (but are not lim-
ited) to internal vehicle resources (for example, battery capacity, CPU cycles), to vehicle position
and attitude (for example, vehicle is not allowed into certain unsafe zones), to time (for example,
overall mission time). Constraints may apply to actions, objectives, goals and the planning
function when calculating outputs.
Contingency An unintended condition that may be anticipated in the sortie Plan or the sortie Rules, or both.
Controlling ElementA An Authorized Client that has the ability to program or operate a UUV remotely.
Data Fusion See FusionB
Decision-making, Planning and Control The ability of a UUV to autonomously perform activity planning, execution and monitoring.
Associated Terms:
Decision-making, Planning and Control Levels or Levels of Decision-making Planning and
Control. One of the three orthogonal axes used to define Levels of Autonomy for a UUV. The fol-
lowing are the defined Levels of Decision-making Planning and Control:
Direct Control—Execution of externally defined commands. No decision-making within the sys-
tem.
Sequenced execution of actions—Execution of externally defined sequence of actions. Limited
decision-making within scope of defined actions (that is, to affect completion of the actions).
Adaptive execution of actions—Execution of externally defined actions. Closes loop on the
actions. Limited decision-making to reorder, insert and resume actions. “Adaptive” applies to ac-
tion reordering and insertion of conditional actions.
Objective achievement—Combine actions to achieve a single objective at a time.
Multiple Objective Achievement—Simplistic combining multiple objectives.
Joint Objective Achievement—Balance multiple objectives.
Dynamic mission planning. See mission planningA
Effetor Device that translates a commanded action into a physical action on the vehicle
EnvironmentA (A) Used as a general reference, environment includes the generic, natural conditions; for ex-
ample, weather, climate, ocean conditions, terrain, vegetation, etc.
(B) Constitutes spatial resources available to the UUV for execution of actions, or achievement of
objectives and goals.
(C) Provides the spatial dimensions of the UUV’s state space.
External Interaction The level of required interaction between a UUV and any authorized client(s) to achieve mission
goals.
Associated terms:
External Interaction Levels or Levels of External Interaction—One of the three orthogonal
axes used to define Levels of Autonomy for a UUV. The following are the defined Levels of Exter-
nal Interaction:
Tele-operationA—The client, using video feedback and/or other sensor feedback, directly con-
trols the UUV via a “continuous” communication method. The UUV takes no initiative.
Remote Control Operation—A client examines all actions before they are executed.
Semi-Autonomous Operation—The UUV requires client feedback to address anomalies
and/or predefined conditions.
Fully autonomous Operation—The UUV is expected to operate without client intervention
from the moment of launch until return, although tasking guidelines are likely to include the possi-
bility of in-course communication and intervention.
External InterventionA The ability for an authorized client to provide UUV direction in a normally fully autonomous be-
havior due to some extenuating circumstances. An unanticipated action or input by the authorized
client to exert control over the UUV.
Fault ToleranceA The ability of a system or component to continue normal operation despite the presence of hard-
ware or software faults {2}
Fully Autonomous See under Level of External InteractionA

7
 F2541 – 06

TABLE 1 Continued
Term Definition
Fusion Also referred to as Information Fusion or Data Fusion.B
(A) The combining or blending of relevant data and information from single or multiple sources
(sensors, logistics, etc.) into representational formats that are appropriate to support the interpreta-
tion of the data and information and to support system goals like recognition, tracking situation as-
sessment, sensor management, or system control. Involves the process of acquisition, filtering,
correlation, integration, comparison, evaluation and related activities to ensure proper correlations
of data or information exist and reason out the significance of those correlations [2, 3]. The pro-
cesses can be performed with a combination of human analysis/judgment and system processing.
(B) Information processing that deals with the association, correlation, and combination of data
and information from single and multiple sources to achieve refined position and identity estima-
tion, complete and timely assessments of situations and threats, and their significance in the con-
text of mission operation. The process is characterized by continuous refinement of its estimates
and assessments, and by evaluation of the need for additional sources, or modification of the pro-
cess itself, to achieve improved result [3].
Geodetic Capability The ability of a UUV to determine its location absolutely, rather than relative to a local datum
GoalA A desired outcome that is not directly expressible in terms of objectives
Hazard AvoidanceA Similar to obstacle avoidance except that the subjects are not limited to physical objects but also
include adversarial situations, as either assessed by the UUV’s perception functions or provided
through the Human Robotic Interactions, that are to be avoided.
Information Fusion See FusionB
A
Markers (physical or electronic) A visual or electronic (for example, reflecting or acoustic) aid used to label a designated point for
such tactical purposes as route following, determination of bearings, courses, or location, and key
items or points of interest, including minefield markers and area NBC decontamination markers.
Methods of Control.B (A) The interface, either software or hardware, such as a joystick, waypoint selection via a map
interface, natural language, etc., that authorized clients use to control a UUV.
(B) The system used for communications with the UUV, for example, acoustic communications
link, RF link, umbilical during pre-launch and post-sortie servicing.
MissionA (A) The highest-level tasking assigned to the UUV-capable operating unit {4}.
(B) One or more sorties coordinated to accomplish a tactical goal.
Mission Planning See PlanA
Mission Orders See Orders
MobilityA The capability of a UUV to move from place to place, under its own power while under any Level
of External Interaction defined herein.
Object Awareness (A) The ability of a UUV to extract information on objects in the environment from onboard sensor
data.
(B) The ability of a UUV to catalog and react to objects in the environment based on off board
sensor data. This may be specified per sensor and extended to Levels of Situation Awareness.
Objective A result to be achieved and/or maintained via actions by utilizing system resources while adher-
ing to a set of system constraints.
ObservationA (A) The information collection state of the “OODA Loop” (Observation, Orientation, Decision, Ac-
tion).
(B) Measurement of the environment by sensors that produce signals that can be analyzed.
ObstacleA (A) Any physical entity that opposes or deters passage or progress, or impedes mobility in any
other way [5].
(B) Any obstruction designed or employed to disrupt, fix, turn, or block the movement of an oppos-
ing force, and to impose additional losses in personnel, time, and equipment on the opposing
force. Obstacles can be natural, manmade, or a combination of both. [6] They can be positive,
negative (for example, ditches), or groupings (for example, areas with high security alert) and can
be moving or still.
Obstacle AvoidanceA Similar to hazard avoidance except that the subjects are limited to physical objects and exclude
adversarial situations, as either assessed by the UUV’s perception functions or provided through
the Human Robotic Interactions.
Operator Control Unit (OCU)A 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 UUVs {7}.
Orders A set of goals and constraints providing input for the planning and execution of a Mission or
Sortie.
Associated Terms:
Mission Orders—Orders specified at the Mission level including limitations, Rules of Engage-
ment, keep out zones, and other restrictions. Requires human interaction to specify Mission
tasking in the context of Mission Orders.
Sortie Orders—Orders specified for a single Sortie. Sortie Orders may be defined through an
authorized client.

8
 F2541 – 06

TABLE 1 Continued
Term Definition
OrientationA (A) The state in the OODA loop (Observation, Orientation, Decision, Action) that involves analysis
and prediction and generates information to support decision making state.
(B) Rotation displacement between two coordinate frames of reference.
PerceptionA A UUV’s capability of sensing and building an internal model of the environment within which it is
operating, and assigning 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 knowledge [2].
Plan A plan is a set of tasks. At the highest level (mission plans vs. sortie plans) it can be more ab-
stract, while at the lowest level an execution plan is a set of messages to be sent to effector sub-
systems or payloads. A Plan can be created pre-launch and in-stride.
Associated Terms:
Mission Plan—The output of Mission Planning including an allocation of resources (UUVs),
their tasking (via Sortie Orders), and criteria to which mission performance can be measured.
Sortie Plan— The output of Sortie Planning is a set of vehicle behaviors that will be executed
absent an external intervention. Sortie Plans may include provision for the use of contingency
rules to specify the appropriate response to system.
Planning Function A mechanism by which goals, constraints, capabilities, and environmental data are processed to
create a plan to include tactical goals, a route (general or specific), command structure, coordina-
tion, and timing. Plans can be generated either in advance by authorized clients or in real-time
by the onboard software systems by or external control.
Associated Terms:
Dynamic Planning or Replanning— The onboard capability of the UUV system to adjust its
route, order of tasking or other features of its Sortie Plan in response to events which occur dur-
ing the sortie.
Platform Independence (A) Independence from computing hardware and operating system.
(B) Independence from a given vehicle configuration.
Priority A relative ranking assigned to a series of goals showing preferential treatment of the individual
goal in terms of time sequence and application of resources.
Prognostic Health ManagementA Ability to use sensors and models of systems to autonomously anticipate and respond to environ-
mental and system changes and monitor the operational and maintenance characteristics of the
system or systems under consideration [8].
Remote Control See under Levels of External Interaction.A
Resources All quantifiable system elements that may be utilized by the UUV during operation. Example re-
sources include: energy/batteries, time, communications bandwidth, CPU cycles, plans, etc.
Result One or more conditions satisfied or not satisfied over a span of time.
Rules Parameterization of the UUV response to a specific situation.
A
Self-Healing Automated or semi-automated capability of system repair, covering the infrastructure, hardware,
and software aspects [6].
Self-DiagnosisA Ability to adequately take measurement information from sensors, validate the data, and communi-
cate the processes and results to other intelligent device {2}.
Semi-autonomous See under Levels of External InteractionA
A
Sensor Equipment that detects, measures, and/or records physical phenomena, and indicates objects and
activities by means of energy or particles emitted, reflected, or modified by the objects and activi-
ties. [2, 9]
Sensor FusionA A process in which data, generated by multiple sensor sources, is correlated to create information
and knowledge. Sensor information, when fused, may yield immediately actionable combat infor-
mation and/or intelligence. The capabilities are of four essential types: Detection, Classification,
Recognition, and Identification [5].
Sensory ProcessingA Computing processes that operate on either direct sensor signals or on low level sensory signa-
tures to detect, measure, and classify entities and events and derive useful information at proper
resolutions and at levels of abstractions, about the world. Sensory processes can be organized
hierarchically with proper relative spatial and temporal resolutions and organized horizontally with
assigned but coordinated focuses [2].

5.1.4 Modular structure to minimize test and retest as
capabilities are added, expanded, or modified.
5.1.5 Sufficient throughput to assure tactical value.
5.1.6 Robust control to handle unforeseen situations.
5.1.7 Varying Levels of Autonomy—Autonomy and control
must support interactions between vehicles having different
levels of autonomy. Not all missions require the same degree of
autonomy. This may occur within a vehicle class, but among
different vehicles of the same class or it may occur among
different vehicle classes. For short range, non-complex mis-
sions, autonomy could be limited to autonomous attitude
control with a communication link to a human operator. On
longer, complex missions, the autonomy function may be
required to supplant the human operator. In such cases, the
UUV may need to return to a specified location at a pre-
determined time after having accomplished multiple tasks with

9
 F2541 – 06

TABLE 1 Continued
Term Definition
Situational AwarenessA The perception of elements in the environment within a volume of time and space, the comprehen-
sion of their meaning, and the in some cases the projection of their status in the future.
Associated Terms:
Levels of Situation Awareness or Situation Awareness Levels. One of the three orthogonal
axes used to define Levels of Autonomy for a UUV. The following are the defined Levels of Situa-
tion Awareness:
Raw—Unprocessed data as collected from sensors.
Semi-Processed—Data in initial semi-processed from from sensors.
Feature—Filtered, normalized, characterized.
Aggregate—Aggregated over time, space, and/or feature characteristics, multiple modalities
(multiple sensors).
Interpreted—Compared against some knowledge database (correlates feature set to a specific
real-world entity) or feature database (pattern of data indicates real-world entity) to surmise entity
characteristics from the physical measurements.
Inferred—Correlated to a knowledge base of situational or behavioral characteristics.
Intent—Correlated to a knowledge base of known patterns of operation including recognizing
plans and objectives, recognizing and/or predicting intent.
Sortie The operation of a single UUV directed at attempting to accomplish one or more goals during a
single run or exercise.
Sortie Orders See Orders
Sortie Plan See under Plan
TaskA A named activity performed to achieve or maintain a goal. Mission and Sortie Plans are typically
represented with tasks. Task performance may further result in sub tasking. Tasks may be as-
signed to operational units via task commands [2].
Task DecompositionA 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 effi-
ciency, and management effectiveness [2].
TeamingA (A) The linking together of platforms, forces, or systems to complete a mission or task collectively.
The process may be characterized by distributed operations and coordinated maneuvers. High pri-
ority coordination issues for underwater vehicles, whether manned or unmanned, include:
a. Prevention of mutual physical interference, that is, collision,
b. Prevention of mutual acoustic interference, and
c. Prevention of casualties from friendly fire in the case of armed operations. Planned or ad hoc
teaming of underwater vehicles is likely to require synchronization and adaptation of plans. The
UUV should be capable of being re-tasked to participate in the current overall goal and to assume
its position in the organizational structure. The UUV should also be capable of communicating its
intentions, goals, present state in the accomplishment of these goals, intended next action, and
current problem areas.
(B) A method of operation where a system uses the combined sensing, information exchange,
decision-making, acting capabilities of humans and robots to carry out missions within the planned
scope.
Teleoperation See under Levels of External Interaction.B
A
Telepresence The capability of a UUV to provide the human operator with some amount of sensory feedback
similar to that which the operator would receive if he were in the vehicle {2}.
TerrainA The physical features of the ground surface, to include the subsurface. These physical features
include both natural (for example, mounds) and man-made (for example, pipelines) features. Major
terrain types are delineated based upon local relief, or changes in elevation, and include: flat to
rolling, hilly and mountainous. Complex terrain includes any characteristics or combination of char-
acteristics that make mobility difficult. Mobility classes are also used to describe the trafficability of
the terrain. The terrain should also be rated as to its trafficability by class of vehicle. This is espe-
cially relevant to the use of different classes of UUVs.
Terrain VisualizationA A component of undersea visualizations that provides a detailed understanding of the background
upon which UUV operations are displayed. Terrain visualization provides common terrain back-
ground for all users and all applications. Additionally, terrain visualization allows interactive plan-
ning and mission rehearsal. Terrain visualization includes both natural and man-made features to
include impacts of terrain on vehicle speed, maintenance, and maneuverability. Terrain visualiza-
tion includes the subordinate elements of data acquisition, analysis, database management, dis-
play, and dissemination. Derived from [10].
TetherA A physical communications cable or medium that provides connectivity between an unmanned
system and its controlling element that restricts the range of operation to the length of the physi-
cal medium [2].
Threat AvoidanceA Ability to detect threats. The continual process of compiling and examining all available information
concerning threats in order to avoid encounter.
Threat LevelsA The relative ability of an enemy, or potential enemy, to jeopardize the UUV’s ability to complete its
mission. The levels are defined as:
low—the UUV’s mission success is limited
medium—the UUV’s mission success is neutralized, or
high—the UUV’s mission is precluded or the UUV is destroyed

10
 F2541 – 06

TABLE 1 Continued
Term Definition
Unattended SystemA 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 An electro-mechanical system, with no human operator aboard, that is able to exert its power to
perform designed sorties and accomplish goals. May be mobile or stationary. Includes categories
of unmanned ground vehicles (UGV), unmanned aerial vehicles (UAV), unmanned underwater ve-
hicles (UUV), unmanned surface vehicles (USV), unattended munitions (UM), and unattended
ground sensors (UGS). Missiles, rockets, and their submunitions, and artillery are not considered
unmanned systems {2}.
Unmanned Undersea Vehicle (UUV) A self-propelled submersible whose operation is either fully autonomous or under minimal super-
visory control and is untethered with the possible exception of data links, such as acoustics, RF, or
fiber optic.
Utility The intrinsic value of completing a goal. Utility is usually driven by the value to a particular client,
such as the end-user of the mission data.
WaypointA An intermediate location through which a UUV must pass, within a given tolerance, en route to a
given goal location {2}.
World ModelA A UUV’s internal representation of the world. The world model may include models of portions of
the environment, as well as models of objects and agents, and a system model that includes the
intelligent unmanned system itself. {2}.
Associated term:
World ModelingB— The process of constructing and maintaining a world model.

A
Denotes from NIST terminology document with proposed minor change.
B
Denotes from NIST document without change, except to substitute UUV for UMS.

only high level mission instructions in an area with incomplete
environmental data. This may occur among different vehicles
of the same class or among different vehicle classes.
5.1.8 Collaboration—Multi-UUV collaboration should in-
crease the likelihood of achieving mission objectives of the
system over and above that achievable by a base capability of
UUVs acting independently. In this case, “independently”
refers to a vehicle acting without any collaboration (for
example, communication, coordination, or sharing of informa-
tion) with other vehicles. The future of autonomy will doubt-
lessly require autonomy to support interactions among ve-
hicles. Whether among similar vehicles with different
capabilities (for example, all the same class but each with a
different payload), or among different vehicle classes (large
vehicles interacting with smaller vehicles having different
endurance and payload capabilities), the vehicle team should
be able to behave autonomously in concert.
5.1.9 Platform Independence—The physical configuration
of a UUV should not drive the autonomy module and vice
versa. It is desirable to have core autonomy software that can
be ported to any vehicle class. Then, specifics for that vehicle
can augment that autonomy core. The result is an autonomy
capability that is platform or vehicle independent.
5.2 Specific Standards—The standards in this section are
directed at mission level autonomy and control. This is a list of
complex vehicle behaviors that will provide an increased
probability of sortie success for UUVs operating without
benefit of human input or decision-making. While these
behaviors are focused on fully autonomous operation, their use
is not precluded in the semi-autonomous, tele-operated, and
remote controlled modes of operation. In the fully autonomous
mode of operation, they are directed at improving probability
of success. In the other modes of operation, they may be used
to minimize operator loading or operator training requirements.
6. Levels of Autonomy
6.1 This section defines characteristics of autonomous sys-
tems that can be used to clarify acquisitions. This follows the
suggestion of the Naval Studies Board panel in their 2005
report Autonomous Vehicles in Support of Naval Operations
(15).There are three axes that cover the scope of intelligent
autonomy software required to accomplish naval missions. The
three axes are: (1) situation awareness, (2) decision-making,
planning, and control, and (3) external interaction. Levels are
defined for each of the three axes independently. The intent of
this definition is to allow an acquirer to specify required
autonomy levels for a system by specifying a level for each of
the three axes. For instance, the acquisition office may specify
that the system shall operate at situational awareness level 5,
decision-making, planning, and control level 3, and external
interaction level 4 for a given mission and environment.
Appendix X1 provides detail on the derivation of the levels of
autonomy and provides tables that may be used to specify
levels. Tables 4-6 provide a definition of these levels and
examples of how these levels apply to vehicle capabilities.
Several areas that interact with the levels of autonomy are
briefly described.
6.2 System Capabilities—An acquisition will explicitly
specify functional capabilities of a UUV. These functional
capabilities are independent from the levels of autonomy. A
specific functional capability is not required to attain a certain
level on any of the three axes. The reason is that for a specific
UUV, a particular functional capability (1) may not be needed,
or (2) may only need a minimal implementation to satisfy its
mission. Neither of these cases affect the level of autonomy of
the UUV. For example, a highly sophisticated UUV may be
searching a hull for anomalies. It may not have any functional
capability to know its geodetic location. If geodetic location
was required to meet a certain autonomy level of situational

11

Commands/Status
Functional
from AC
Interface
to Functional Component
VC-Mobility/Maneuver Maneuver modeling: launch,
home/dock, CSD, Waypoint
CSD command
Waypoint Command
Activity Command
Enable/disable or set parameters
of low-level obstacle avoidance
VC-Energy (none)
VC-Navigation Enable/Disable DVL Acoustics
Command GPS Fix
Safety (none)
MCM Payload Activate/deactivate sonar
(continuous sweep);
Set swath params (or select
parameter set index)
Activate/deactivate alternate
sensor
Specific plans from payload
controller
ISR Payload Raise or stow mast
Point sensor and collect
Select parameter set
Specific plans from payload
controller
FLS Activate/deactivate sonar
Set swath params (or select
parameter set)
Generic Sensor Activate/deactivate
Set parameters (or select
parameter set)
ACOMM Enable (allow)/disable outgoing
ACOMM
Enable/disable incoming ACOMM
Select ACOMM mode (for
example, speed)
RF COMM Enable (allow)/disable outgoing
LOS or BLOS
Enable/disable incoming LOS or
BLOS
Raise or stow mast
Network of LAN COM (none)
(wires to host)
C2-AC Plan execution status
Log data (as requested)
Autonomy control state (for
example, transiting, searching,
investigating)
F2541 – 06
TABLE 2 High Level UUV Interfaces
Component State/Information from
functional component to AC
Current mode
Launch status
Homing/docking status
Waypoint distance-to-go
Activity time to complete
Status—operating nominally
Status—component health or
faults
Parameters—cell voltages, other
Batteries aboard; which are being
used
Status—Operating nominally
Status—component health or
faults
Mode of operation (INS, etc.)
Safety system operating?
SLS status (healthy, active, faults) Contact report
SLS mode
Alternate Sensor/Health mode
Mast height Mat pointing status - Contact Reports
reference
Health, readiness, and parameter
set for each collection mode
FLS status (healthy? active?)
FLS mode
Status—health, faults, active
Mode
Present and healthy?
Is link enabled?
Time since activated
Recent interactions with peer(s)
Present and healthy?
Is link enabled?
If enabled, what connection types
are active?
How long since active?
Recent peer(s)
Is link enabled?
How long since active?
Recent peer(s)
Sortie (high level or detailed)
Sortie Objectives
Sortie Constraints
Sortie retasking update
Internal Vehicle State and
External Vehicle Information Functional Component
from vehicle Capability Parameters
to AC
(none) Speed & turn rate limits (surface)
Speed & turn rate limits
(submerged)
Depth limits
Depth rate limits
Distance & time to surface/
submerge
Power consumption versus speed
Energy remaining Model of Consumption
Energy drain rate
Global position Model of GPS-update uncertainty
Angles, Rates, Velocities Model of submerged dead
Uncertainty in navigation estimate reckoning uncertainty
Model of surface dead reckoning
uncertainty
Safety limit settings Safety limits (that is, thresholds
for Safety system to seize control)
Geometric swath description
Bathymetry update SLS sensing performance
Request to manuever Alternate sensing performance
Delay to raise/stow mast
Request to manuever Sensor performance
Sonar contact report Geometric swath description
Bathymetry update Model of sensor performance
Contact report Model of sensor performance
Environmental update
Message content Available ACOMM modes
Model of typical BW & latency
Message content Model(s) of typical BW & latency
LOS-relay parameters (range,
elevation range)
SATCOM parameters
Message content Model of typical BW & latency
Bathymetry data
Map data
Environmental setup (SVP, …)
Avoidance zones

awareness, then the UUV would never satisfy that level to satisfy specified autonomy levels. However, autonomy
regardless of its sophistication. levels do not imply a UUV system architecture and design.
6.3 System Architecture and Design—A UUV system archi- This means that developers are not constrained in how they
tecture and design will be developed for a particular program design their system to satisfy the required levels of autonomy.

12
 F2541 – 06
FIG. 4 UUV Functional Subsystems and Interfaces
6.4 Operator/External Interaction—The external interac-
tion level of autonomy indicates the “required” level of
external interaction. An operator may still interact with a
highly autonomous UUV to override functions at any level of
control. Conversely, on a highly autonomous UUV, there will
be low-level control functions that do not make sense for an
operator to directly manipulate. The UUV may be required to
switch between different levels of autonomy based on opera-
tional need. These are all system design issues and do not affect
the specified level of autonomy.
6.5 Sensor Input—The quality of the sensors is independent
from the level of autonomy designed into the system. If a more
accurate sensor is employed, resulting in improved system
performance, it does not imply that the UUV has transitioned
to a higher level of situational awareness autonomy. The level
of autonomy has not changed since no software enhancement
has been made. There simply exists better data from which
situational awareness gives better results.
6.6 Application of Autonomy Levels—A consideration when
applying autonomy levels to a specific program’s UUV archi-
tecture is designation of how these levels are satisfied. This
guide makes no attempt to designate how the satisfaction of
13
these autonomy levels takes place. They apply to the UUV as
a whole system. As an example, in one UUV architectural
design, there could be an “autonomy controller” and all levels
are satisfied there. Another UUV architectural design may have
a “vehicle controller” that has some lower-level autonomy built
in (for example, waypoint traversal). It is recommended that
users of this guide allow system designers to determine how
the levels of autonomy are satisfied so as not to artificially
constrain the design process.
6.7 System Performance—The levels of autonomy do not
imply a level of system performance. A high level of autonomy
does not imply a high level of mission success in a specific
environment. A system specification must have applicable
performance specifications defined explicitly in addition to
levels of autonomy. For example, a UUV may require an 80 %
success level for a selected mission given a certain environ-
ment. This explicit requirement must be stated in addition to
defining levels of autonomy for a UUV acquisition. In satis-
fying a performance requirement for a UUV, the designed
system could require a combination of high quality sensors, a
medium level of decision-making, planning and execution
autonomy, and a high level of human interaction. There is no
 F2541 – 06
TABLE 3 Specific Standards

Qualification Method
Standard Comment
to Verify Compliance
Performance Standards of Autonomous Systems—Capabilities listed below are typical UUV performance standards associated with extended operation without
human intervention. Depending on how many of these standards a UUV incorporates and how well the standards are implemented (in both hardware and software),
the UUV will be said to have a higher level of autonomy.

1 An autonomous system shall provide an off-board The mission planning function combines mission Verified by reading valid and invalid configuration
mission planning capability. The mission planning objectives, operating constraints, and files and performing appropriate actions for each.
capability shall have the following characteristics: environmental data to produce a plan to use UUVs Ability to schedule pre-scripted, time-tagged
It shall be capable of recognizing an authorized in the execution of a mission. events via input file. Development of control
client. At the higher levels, the plan may allocate language for event types.
It shall accept input from authorized clients and objectives to subordinate UUV operating groups.
reject input from other sources. At the lower levels, the plan may consist of a
It shall validate input data and present results to series of UUV sortie plans that can be downloaded
the authorized client for adjudication. to a UUV for execution.
2 An autonomous system shall be capable of a sortie Sortie plans provide the outline of the tasks to be Definition of a minimum set of default parameters
planning function. This function shall generate, accomplished by the UUV. The tasks and the required to be executed while vehicle is lacking
verify, and store sortie plans under the auspices of sequence of the tasks are selected ahead of time current specific instruction from the external agent.
an authorized client. using the best information available. Through
operator intervention or through dynamic onboard
planning, the sortie plan may be modified based on
sensed environmental or tactical data.
Examples of sortie plan tasks include the
following:
Point to point transit paths, waypoints, dearch
area(s), keep-out area(s), communications
schedule, sensor deployment plan, navigation aids
(on/off codes, interrogation, reference location,
etc.), depth control law (constant depth or constant
altitude), rendezvous point
3 An autonomous system shall have sortie plans that This includes generating a multi-objective plan with
shall be capable of addressing more than one the capability to prioritize and re-order the
objective, consistent with the specified payload. objectives.
4 An autonomous system shall be able to simulate a At a minimum, the simulation should exercise the
sortie plan and provide the authorized client with intended path. If the capability is provided and the
simulation results to show that the plan authorized client desires, faults may be injected
accomplishes the intended goal. into the simulation as a means to check and refine
the robustness of the plan.
5 An autonomous system shall be capable of Subsystem-level response may include switching to
monitoring subsystem performance and effecting alternate equipment.
change either at the subsystem level or the system System-level response may include:
level to address performance degradation. Aborting the sortie and returning to rendezvous,
or
Switching to an alternate sortie plan, or
Dynamically replanning the sortie to bypass the
need for the degraded subsystem.
6 An autonomous system shall generate and The autonomous system shall continuously Definition of a minimum set of default parameters
maintain a safe, valid plan to execute at all times. evaluate the execution status of the sortie plan. required to be executed while vehicle is lacking
The autonomous system shall be aware of the current specific instruction from the external agent.
environmental and tactical situations and be
capable of mitigating or eliminating adverse
conditions.
7 An autonomous system shall accept vehicle safety Examples of vehicle safety data include specific Verify appropriate input files accepted and acted
data from an authorized client. vehicle limitations, “keep out zones,” rules of on.
engagement, or contingency rules for fault
management.
8 An autonomous system shall have the ability to This could be as simple as an input file or perhaps Verified by reading configuration file of sensor/
determine which sensors/payloads are available to a “device recognition” capability similar to that payload loadouts
the vehicle, and the ability to use the appropriate currently available on commercial USB devices.
interface.
9 An autonomous system should provide a capability The capability for collaboration assumes the use of Definition of a minimum dataset required for
for collaborating with multiple systems pre-planned communications devices, protocols, collaboration.
(autonomous and manned). and schedules. The collaboration may be part of
the sortie plan or may be an ad hoc activity
resulting from dynamic re-planning.
10 An autonomous system shall be capable of At a minimum, the autonomous system shall be Use of permissions based o/s scripts and input
accepting constraints on the scope of its able to switch between the autonomous modes of files
replanning/decision making authority.. operation (fully autonomous, semi-autonomous,
tele-operated, and remote control).

14
 F2541 – 06

TABLE 3 Continued
Qualification Method
Standard Comment
to Verify Compliance

Design Standards of Autonomous Systems—Design features listed below represent the preferred method of incorporating autonomous standards into a UUV. A UUV
design that follows these standards will be considered modular, interoperable, and characterized as an open architecture.

11 Autonomous systems shall provide standard Examples: Payload services, vehicle services, Adherence to known standard protocols (POSIX,
interfaces that accommodate various systems and autopilot, and subsystems with various operating IP, etc.)
services. systems and languages
12 Autonomous systems shall be modular in design. Support decoupled autonomous control, separate Abstraction of Autonomy processing. Use of
autonomy from vehicle and payload functions, published APIs.
operate components on separate processors,
support inter-changeability of components.
13 Autonomous systems shall be platform This implies both vehicle platform and computer Written in POSIX compliant language or operating
independent. hardware independence, system/hardware independent (for example, JAVA),
or adopting design features, such as middleware
layers.

implied direct correlation between autonomy level and system
performance. An acquirer may explicitly specify that a certain
level of performance by met for a specified level of autonomy.
6.8 Collaboration—Some autonomy scales have included
collaborative systems as a higher level of autonomy within the
rating system. In those systems, a higher LOA indicates
collaboration. In this guide, collaboration is accommodated by
applying the LOAs to either an individual UUV or to a
system-of-systems. The system-of-systems could be a group of
homogeneous UUVs. For example, an individual unit in a team
might have a decision-making, planning, and execution LOA
of three, whereas the team of UUVs jointly would have an
LOA of four. This indicates that the group works more
autonomously than an individual UUV. This system-of-systems
for a given application may be a group of homogeneous UUVs
or a group of heterogeneous vehicles (including UUVs and
surface craft) that cooperate as a collaborative group.
7. Command Descriptions and Interfaces
NOTE 1—Future revisions of this guide will be updated to include
details related to the following subsections.
7.1 Internal Interfaces.
7.2 External (Payload) Interfaces—This interface section
will be aligned with WK11283.
7.2.1 Command and Control—Modes and states.
7.2.2 Data Interface.
7.3 Low Level Commands:
7.3.1 It may be possible to capture the functionality or
language that all UUV autonomy and control systems under-
stand by providing a set of low-level commands or modes.
These common capabilities may include course, speed, depth,
heading, and so forth, so that all autonomy and control systems
can operate on this command set.
7.3.2 This guide will provide such a set of low-level
commands.
7.3.3 In order to define the relationship between autonomy
and the sensing and control systems onboard a UUV, a standard
terminology for the meaning of sensed values and vehicle
control commands is needed. The purpose of defining these
commands is to allow providers of autonomy systems and
modules to describe in a precise and implementation-
independent fashion what those software modules do. This
section begins with a set of definitions of command qualifiers
that are used in subsequent command definitions. The second
set of definitions is for quantities that can be sensed by a UUV.
The final set of definitions describes a command set that can be
executed by a UUV.
7.3.4 It is not the intent of the guide to require every UUV
to provide all of the data or command functions defined in this
section. The objective of this list is to create as complete a list
as possible of the data and command functions that may be
available across a fleet of heterogeneous UUVs. The list is
intended to itemize those data and functions that can be
interpreted as atomic from the point of view of the autonomy
subsystem or module. The term atomic is used here to indicate
that these data and commands are provided by the UUV system
as values that can be accessed directly or as commands that can
be issued by the autonomy module. It is recognized that the
quantitative accuracy of the incoming data and the tracking
errors associated with the execution of commands will affect
the performance of the autonomy module. Standardizing the
specification of these errors will be addressed in future versions
of the standard.
7.4 Tables 7-11 list accepted command and data qualifiers
and define the set of acceptable units. It is expected that this list
will grow and change as necessary to support emerging
functionality. All qualifiers, data, and command definitions are
assumed to be case insensitive. The qualifiers in Table 7 define
a set of units that are equivalent to Boolean variables;
additional terminology is introduced that is appropriate for
different contexts.
7.4.1 The qualifiers in Table 8 define a set of qualifiers that
are used to define the interpretation values having units of time.
7.4.2 The qualifiers in Table 9 define qualifiers associated
with linear distance and angular measure. Also included in this
table are qualifiers associated with time derivatives of linear
and angular measure. This table defines distinct qualifiers for
velocity measured in knots and it can be argued that the use of

15
 F2541 – 06
TABLE 4 Situational Awareness Levels of Autonomy
Requirement Examples
Level Description
Statement Mobility (FLS) MCM SIGINT Electro-Optical SVP Battery
0 Raw:Unprocessed The system shall Complex (element Complex (element Complex (element Pixel values Voltages Voltages
data as collected use raw sensor data) data) data)
from sensors data.
1 Semi-Processed: The system shall Beamforming Beamforming Beamforming Streaming, JPEG, Temperature, Voltages
generate semi- Images Images Images MPEG, NITF Salinity Current
processed sensor Temperatures
data.
2 Feature: Filtered, The system shall Detections Detections PW, PRI, DOA Features Velocity Cell Status
normalized, generate feature (doppler, signal (doppler, signal Edges, corners,
characterized. data. strength, pos) strength, pos) color patches,
Bottom features Bottom features reflectance
(terrain changes, (terrain changes, patches, motion
outcroppings) outcroppings)
3 Aggregate: The system shall Range, extent, Mine-like object Emitter type Ship hull matches SVP Battery Status
Aggregated over aggregate data bearing Range and bearing ship 1 matches
time, space, and/or over time, space, ship 2 visually
feature and/or recognized motion
characteristics, characteristics, of objects
multiple modalities and/or multiple
(multiple sensors). modalities.
Data at this level
could be used in a
predictive sense Track data
for planning (at
time “t” a track
would be at
position “p”).
4 Interpreted: The system shall Obstacles Mine-type Emitter in targeting Fishing vessel Swath estimate Planned versus
Compared against determine entity Map data mode Destroyer of actual energy
some knowledge characteristics by Specific emitter ID specific class available
database comparing data Cluttered loading
(correlates feature with one or more dock or ship deck
set to a specific knowledge or
real-world entity) or feature databases.
feature database
(pattern of data
indicates real-world Fishing vessel
entity) to surmise Destroyer of specific class
entity Classification
characteristics from
the physical
measurements
5 Inferred:Correlated The system shall Trapped in a box Densities, Enemy Radar Ship loading Not achieving
to a knowledge discern entity canyon Clear Q-Route GPS jamming activity desired coverage
base of situational situational or Fishing group
or behavioral behavioral Military group
characteristics characteristics by
Recognize lawn mower search
comparing data
Fishing group
with one or more
Military group
knowledge bases.
Changed contact behavior indicates it has detected you
6 Intent: Correlated The system shall Analyze Obscured loading NA NA
to a knowledge discern entity intent deployment pattern implies hostile
base of known based on one or to anticipate other intent
patterns of more knowledge mine placement or
operation including bases about known possible clear
recognizing plans patterns of space
and objectives, operation.
Recognize mine clearing activity
recognizing and/or
Recognize acting as decoys
predicting intent.
Intent based on jamming density
Maneuvers indicate hostile intent
Pattern of comms intercepts indicate hostile intent
Maneuver prediction based on perceived tactics

different measuring systems is redundant. The intent of the 7.4.3 The qualifiers in Table 10 define qualifiers associated
guide is to force the adoption of a specific set of units but with mass. The table recognizes a quirk associated with the use
enumerate the set of equivalent alternatives and the notation to of the English system in that mass is usually specified in units
be used. that are actually force. It may be necessary for a future standard

16

TABLE 5 Decision-making, Planning, and Control Levels of Autonomy
Level Description
0 Direct Control—Execution of
externally defined commands.
No decision-making within
the system.
1 Sequenced execution of
actions—Execution of
externally defined sequence
of actions. Limited decision
making within scope of
defined actions (that is, to
affect completion of the
actions).
2 Adaptive execution of
actions—Execution of
externally defined actions.
Closes loop on the actions.
Limited decision making to
reorder, insert and resume
actions.
“Adaptive” applies to action
reordering and insertion of
conditional actions.
3 Objective achievement—
Combine actions to achieve a
single objective at a time
Requirement Statement
The system shall directly
execute external commands
without deviation.
The system shall tailor
execution of externally
defined actions to effect their
completion.
The system shall execute
externally defined actions,
with the ability to interrupt
execution of these actions to
satisfy predefined constraints.
The system may not have an
understanding of the impact
of the interruption.
The system shall dynamically
plan and execute a set of
actions to achieve an
objective.
F2541 – 06
Examples
System is driven by client that receives tasking. Client (not system) closes the loop on all
commands.
Descriptions:
Script-based control with aborts.
Closes the loop on results of actions to an extent (for example, pursues waypoint till close
enough). Having completed the action, the system switches to next waypoint.
Continues or aborts external commands to honor time and safety constraints.
Plan and execute commands to execute an action.
System may not always be able to sense achievements of its actions (for example, turned
power on but may not have a sensor for that, may just finish based on a timer).
Actions are not combined actions or hierarchies of actions. Does not close the loop on a
group of actions with a joint condition on them that adjusts multiple actions.
Examples:
Bottom following. Following list of waypoints.
Abort (for example, abort because payloads aren’t talking or because insufficient visibility
(for example, fog prevents EO/IR sensing). Not able to ‘abort the task’ because system
doesn’t represent “the task.”
Descriptions:
Manage a set of actions (can be a sequence or reorderable set of actions, plus a set of
conditional actions to be inserted as needed).
Closes the loop on each action’s accomplishment individually (for example, got close
enough to waypoint to decide transit leg is completed) but doesn’t have a metric for
quality of results (for example, doesn’t respond to data holidays in sensed data).
Recognize need to suspend the action that is being executed to issue a conditional action
(for example, suspend bottom following to do obstacle avoidance). Hold one action in
abeyance while doing another. Automatic action re-ordering depends on situation
(environment or self) such as insufficient visibility, incorrect position (and another action
could be performed at this location).
Actions are not combined actions or hierarchies of actions. Does not close the loop on a
group of actions with a joint condition on them that adjusts multiple actions.
Examples:
Contingency-based execution.
Actions could include transit, loiter, get GPS fix, steer to track, achieve waypoint on time.
Insertion of conditional actions is based on the sensed situation (world and self). For
example, if nav error grows too high, insert “get GPS fix”.
More complex safety systems (for example, stay within safe depth envelope while
executing task, which might mean it can’t complete the task (for example, has to abort)).
Reset subsystem(s) to overcome lack of communication.
Slow UUV’s speed to avoid moving obstacle passing by.
Descriptions:
Select and schedule a set of actions to close the loop on the Figure of Merit (FOM) for
the set of actions. (“Objective” is a function of FOM on the set of actions.) For example,
recognizes gap in data due to some interruption and goes back to get the missed data, or
ensures execution proceeds so as to not miss data. Reorder actions as needed in stride.
Execute one action at a time.
Recognize the impact on objective of switching between two actions. For example, detect
missing survey data (because interrupted survey to avoid an obstacle) and make up for it
later.
Adjust switching between actions so as to ensure achieving the objective. Detect and
repair to achieve objective. For example, recognize gap in data (maybe due to power
outage), so go back to get the missed data.
Client can give system a list of objectives with simple completion conditions (for example,
time, place, target density), but system only switches objectives when it completes one
objective and moves on to the next. One objective can be aborted without aborting all
remaining objectives (for example, due to failure of a necessary sensor).
At all ‘objective’ levels: objectives input could be incompletely specified and system can
act/interact to complete the specification.
A level 3 system could generate inputs for a level 1 or 2 system, and can do the action
management itself.
Examples:
Objectives: Survey region. Collect shoreline data. Improving nav estimate (vs just action
of getting GPS fix).
Example actions include transit, get GPS fix, take second look for higher fidelity.
Survey – requires transit to area, path planning en route, series of steer to waypoints
Collect shoreline data – transit to area standoff, surface, stay on location to collect
imagery in direction of shore, take GPS of opportunity
Do obstacle avoidance in such a way as to continue successfully sensing.
Cllear mines from region (find them, classify them, id them, finally get rid of them). At level
3, these could be sequential objectives.
Make an explicitly straightline approach during transit to allow a particular kind of sensing
while transiting.
17

TABLE 5
Level Description Requirement Statement
4 Multiple Objective The system shall dynamically
Achievement—Simplistic plan and execute actions to
combining of multiple achieve a sequence of
objectives objectives.
5 Joint Objective The system shall plan and
Achievement execute actions to achieve
—Balance multiple multiple objectives
objectives. simultaneously.
to address this discrepancy in that depending on the application
(for example, specifying commands to a variable-ballast sys-
tem) the interpretation may be latitude or location dependent.
7.4.4 The command qualifiers in Table 11 define qualifiers
associated with data specified relative to other data or relative
to some standard reference.
7.4.5 This concludes the definitions of qualifiers for data
and commands.
7.5 The next set of tables (Tables 12 and 13) define sensor
data which includes data required for vehicle operation, as well
as data associated with payload. Table 12 defines data associ-
ated with vehicle navigation and motion sensing. Table 13
defines a preliminary set of environmental data that can be
sensed. The data defined in the table includes only point
measurements, future drafts of the guide should include stan-
dard definitions for data associated with linear, area, and
volumetric data.
7.6 Tables 14-21 define sets of atomic commands for UUVs
broken down by category. A particular UUV will respond to a
subset of these commands based on its configuration. The
guide does not require that a UUV be capable of implementing
all capabilities defined in the guide. Some commands associ-
ated with specific devices will also have corresponding data
definitions that can be sensed. For example, Table 14 lists
atomic commands to the masts, but could also be a part of the
data definition, defining the current state of the masts. No
measure of the quality or accuracy of the response of a
F2541 – 06
Continued
Examples
Descriptions:
System executes one objective at a time, reordering or switching back and forth between
them using client-provided criteria (such as priority, function of estimated energy to
achieve, etc). System closes the loop on the objective being executed (as at level 3).
Objectives could include ‘targets of opportunity’ (do x if see y close enough to UUV at
cost less than N).
At level 4, these objectives could be switched between in-stride, and the system could run
out of time or energy before finishing if there were enough MLOs.
At all ‘objective’ levels: objectives input could be incompletely specified and system can
act/interact to complete the specification.
Examples:
Package delivery (objective 1) and bottom mapping (objective 2): system could sequence
or abandon objective 2 to accomplish objective 1.
Mine survey and chase sub contact (if discovered) – would give up survey to chase
submarine contact.
Clear mines from region (find them, classify them, id them, finally get rid of them).
Descriptions:
Combine actions to simultaneously make progress on multiple objectives. Dynamic
resource allocation and activity scheduling to maximize value: system determines during
execution whether it’s working the right objective now. Reasons about value of continuing
on with current objectives vs switching to others. System closes the loop on cross-
objective FOM.
Differentiators: flexibility, simultaneity, robustness in the face of uncertainty.
At all ‘objective’ levels: objectives input could be incompletely specified and system can
act/interact to complete the specification.
Examples:
“These are three possible landing zones; survey them to identify the least dangerous”
(could treat as 3 objectives).
Package delivery (obj 1) and bottom mapping (obj 2): tune the fidelity of 2 to allow 1 on
time.
Mine survey and chase sub contact if discovered – choose new survey area for during
chase.
Search for mines and stay in contact with other UUVs that are mapping.
Clear mines from region (find them, classify them, id them, finally get rid of them). At level
5, these objectives could be simultaneously achieved.
particular UUV to atomic commands is included now, but
needs to be included in future versions. For example, a measure
of the heading or depth accuracy which a particular UUV can
achieve, both from the perspective of the accuracy of the
sensors and the steady state errors of its control system, should
be quantified and included in the standard terminology.
7.6.1 Table 15 lists commands associated with speed con-
trol. Speed may be controlled either by specifying a turn count
or speed that is related to turn count, relative to the water
column, or relative to the bottom. Most of the variables defined
in the following tables occur in pairs since each basic com-
mand also has a command that corresponds to a change in the
command setting.
7.6.2 Table 16 contains heading commands which may be
issued to an UUV. The HeadingRateCmd is used to command
the UUV to achieve the desired heading rate without regard to
the actual heading. HeadingCmd is used to command the UUV
to achieve the commanded heading angle without exceeding
the commanded heading rate. DirectHeadingCMD is different
from HeadingCmd in that it uses the commanded heading rate
magnitude as an upper limit, but picks the sign to achieve the
commanded heading with the shortest possible travel.
7.6.3 Table 17 contains commands which affect the pitch/
depth axis of the UUV. PitchRateCmd commands the pitch rate
of the UUV without regard to the pitch angle. PitchCmd
requires the UUV to achieve the commanded pitch angle
without exceeding the commanded pitch rate. DepthCMD/
18

TABLE 6 External Interaction Levels of AutonomyA
Level Description
0 Tele-Operation: the client, using video
feedback and/or other sensor feedback,
directly controls the UUV via a “continuous”
communication method. The UUV takes no
initiative.
1 Remote Control Operation: the client
provides control frequently but not constantly,
assigning incremental goals (for example,
waypoints in mobility situations) that the
system executes autonomously. The system
manages itself while waiting for external input
(for example, station-keep while waiting for
next goal). The UUV takes no initiative other
than the ability to abort if the situation
warrants (for example, lost communications).
2 Semi-Autonomous Operation: the system
operates from a list of a priori actions it
chooses from (and parameterizes) to
accomplish tasking from the client. Tasking is
comprised of sortie subtasks, and can permit
autonomous operation (without client
interruption or through communication
outages) over long times and distances in
dynamic environments. The client monitors
progress and may override commands, alter
parameters or redirect actions.
3 Fully autonomous Operation: the UUV is
expected to operate without client intervention performing a complete sortie from tasking
from the moment of launch until return,
although tasking guidelines are likely to
include the possibility of in-course
communication and intervention.
F2541 – 06
Requirement Statement
System sensor, payload, maneuvering, and
other system controls shall be performed
through direct, continuous, external
interactive control.
The UUV shall be capable of independently
performing individual system-level functions
commanded through frequent external
interactive control.
The UUV shall be capable of independently
performing sortie subtasks over an extended
time period (minutes to hours) in a dynamic
environment without external intervention.
The system shall be capable of independently
guidelines.
Examples
In support of a Harbor Defense mission, the client (operator)
controls the relative position of the UUV to the underhull of a
ship entering a harbor to examine for attached explosives.
UUV relative positioning is based on sensory data made
available to the operator (for example, via fiber).
The UUV is performing an MCM mission receiving waypoint
lists from an external operator for survey legs. Along the way,
sonar range is determined to be significantly different from
pre-planned and the UUV reports this information. The
external operator downloads updated survey legs via available
communications path (for example, acoustic, RF)
The UUV is preloaded with a set of actions (for example,
waypoints and default sensor plans). During operation, the
UUV identifies a potentially high priority target and reports the
contact. It goes into a standoff mode until further direction is
received. The external operator re-tasks the system to acquire
more accurate and detailed information on the selected
contact. Upon completion of tasking, it returns to a rendezvous
for recovery and upload of the collected data.
The UUV is pre-loaded with tasking and reports minelike
objects. Onboard autonomy may automatically schedule and
execute “2nd looks” (with same or alternate sensor) of
possible minelike objects or abandon search of an area due to
excessive mine densities.

A
A client can be a human or an external source that gives direction and receives status. The levels refer only to “required” interaction. An operator may
“optionally”interact with an autonomous UUV at any lower level of control as required by the mission.

TABLE 7 Command and Data Qualifiers Equivalent to Logic TABLE 9 Command and Data Qualifiers Associated with Linear
TRUE Port and Angular Measurement and Their Time Derivatives
FALSE Starboard Position Velocity Accleration
ON Both
OFF Degrees DegPerSec DegPerSec2
UP Radians RadPerSec RadPerSec2
DOWN Meters MPS MPS2
Feet Fps Fps2
Yards Yps Yps2
Km Kps Kps2
TABLE 8 Command and Data Qualifiers Associated with Time Nm Kt,Knots G
Seconds
Minutes
Hours TABLE 10 Command and Data Qualifiers Associated with Weight
UTC, UTCTIME and Mass
HMS
Kg Lb
Kilo Lbs
Kgs Pound
AltitudeCMD requires the UUV to achieve the commanded Kilos Pounds
depth/altitude without exceeding the commanded pitch angle
and pitch rate values.
7.6.4 Table 18 contains commands which affect the roll of
the UUV. RollRateCmd commands the roll rate of the UUV 7.6.6 Table 20 lists atomic wait commands. It is possible to
without regard to the roll angle. RollCmd requires the UUV to replace the entire table with a single WaitFor <event> entry
achieve the commanded roll angle without exceeding the where, <event> could be used to represent events such as
commanded roll rate. UserInput or conditional statements such as Depth = 10 meters,
7.6.5 Table 19 lists commands appropriate for a UUV with or MastState = DOWN.
ballast tanks. The command Add corresponds to vehicle that 7.6.7 The Device/Sensor commands listed in Table 21 are
has a single tank. AddFwd and AddAft are appropriate for a included here as a prototype and must be extended with a more
vehicle equipped with a pair of tanks. The table also defines complete list of commands and parameters for a broader range
commands that correspond to operating modes for the VBS and of typical UUV sensors. The string enumerated settings is used
its associated control system. to indicate other commanded settings for the particular device,

19
 F2541 – 06
TABLE 11 Command and Data Qualifiers Describing Relative TABLE 14 Mast Commands
Quantities Mast UP | DOWN
Percent FwdMast UP | DOWN
dB AftMast UP | DOWN
Decibels

TABLE 15 Speed Commands

TABLE 12 Navigation Data RPMCmd rpm
Latitude Angle Units (WGS84) SpeedCmd speed units
Longitude Angle Units (WGS84) Equivalent to RPM in that an advance ratio
X (range/grid location) Linear Units (possibly variable) is used to determine RPM.
Position in a rectilinear coordinate SpeedOverGround speed units
Y (range/grid location) frame. Geodetic location, orientation, Speed relative to the Earth’s surface.
and projection of reference to be SpeedThroughWater speed units
Z (range/grid location)
specified. Z may equate to depth. Speed relative to a layer in the water column.
Depth Linear Units ChangeRPMCmd rpm
Depth referenced to mean surface ChangeSpeedCmd speed units
height; value corrected for wave ChangeSpeedOverGround speed units
motion ChangeSpeedThroughWater speed units
Height Linear Units
Distance above reference plane; either
(WGS 84 or MSL).
Altitude Linear Units TABLE 16 Heading Commands
Distance above sea floor. HeadingRateCmd angular rate units
Roll Angle Units HeadingCmd angular rate units (optional)
Pitch Orientation relative to (true) NED angle units
Heading frame (WGS84/SNAME).A DirectHeadingCmd angular rate units (optional)
RangeHeading Angle Units angle units
Course relative to range frame. ChangeHeadingRate angular rate units
MagneticHeading Angle Units ChangeHeading angular rate units (optional)
Course relative to magnetic N. angle units
U Linear Rate Units DirectRudderCmd angle units
V Velocity of UUV relative to water
W column (SNAME).
VNorth Linear Rate Units
Veast Velocity of UUV-fixed NED Frame TABLE 17 Pitch/Depth Commands
VDown (WGS84).
PitchRateCmd angular rate units
P Angular Rate Units
PitchCmd angular rate units (optional)
Q Velocity of UUV relative to water
angle units
R column (SNAME).
DepthCmd angular rate units (optional)
RollRate Angular Rate Units
angle units (optional)
PitchRate Time derivative of attitude relative to
depth units
HeadingRate (true) NED frame (WGS84/SNAME).
AltitudeCmd angular rate units (optional)
Udot Linear Acceleration Units
angle units (optional)
Vdot Acceleration of UUV relative to water
depth units
Wdot column (SNAME).
ChangePitchRate angular rate units
Pdot Angular Acceleration Units
ChangePitch angular rate units (optional)
Qdot Acceleration of UUV relative to water
angle units
Rdot column (SNAME).
ChangeDepth angular rate units (optional)
Ax Linear Acceleration Units
angle units (optional)
Az Sensed absolute acceleration of UUV.
depth units
Ay
ChangeAltitude angular rate units (optional)
A
(SNAME) Society of Naval Architects and Marine Engineers Technical and angle units (optional)
Research Bulletin 1-5, 1952. Document defines a standard for describing the depth units
dynamics of a body moving in a fluid. DirectElevatorCmd angle units

TABLE 13 Environmental Data

NOTE—To be completed in future revisions. 8. Metrics

Salinity
Conductivity
NOTE 2—To be refined in future revisions of this guide. May be
Pressure combined with Section 5.
Turbidity 8.1 Evaluation of UUV automation must be via an estab-
Temperature
Density lished set of metrics. Consideration is required to develop or
identify appropriate metrics that will not become obsolete with
system upgrades or functional improvements and which will
embrace expansion and improvements. Metric definitions must
such as for example, PINGON, or RECORDON for the be applicable to vehicle modules and payload interfaces
side-scan sonar. The string parameter settings is used to (payload metrics will be specific to the payload), and must be
indicate values of parameters for that specific device which able to accommodate multi-vehicle interactions. Inherent in
may be set during the course of the mission, for example, this is the need for a mission analysis capability, where the
PINGRATE = XX for the side-scan sonar. mission is assessed based on appropriate mission-level metrics.

20
 F2541 – 06
TABLE 18 Roll Commands TABLE 21 Device/Sensor Commands
RollRateCmd angular rate units CTDCommand ON | OFF| other enumerated settings
RollCmd angular rate units (optional) parameter settings
angle units SSSCommand ON | OFF| other enumerated settings
ChangeRollRate angular rate units parameter settings
ChangeRoll angular rate units
angle units
DirectAileronCmd angle units
Based on these needs, a preliminary set of metrics has been
identified for UUV autonomy. This section presents these
TABLE 19 Buoyancy System Commands metrics.
Add weight units 8.2 Metrics to assess UUV autonomy span a large range of
AddFwd weight units capabilities. They extend from system and sortie metrics to
AddAft weight units
Blow Pump tanks to a known reference condition. component-level metrics and include single UUV operations,
Trim Control ballast to minimize drag multiple UUV operation, and to some extent operator interac-
Hover depth units tions. One underlying assumption is the signal processing and
interpretation of sensor data (for example, raw sonar or RF
data) is conducted within a separate module or payload and
TABLE 20 Wait Commands
time lags associated with this processing are not incorporated
WaitTime time units in the metrics.
WaitPitch Depth|Altitude|Angle|Rate +units
WaitHeading Depth|Altitude|Angle|Rate +units
WaitFor event 9. Keywords
9.1 autonomous vehicle; autonomy; control architecture;
unmanned undersea vehicle

APPENDIXES

(Nonmandatory Information)

X1. TAXONOMY

X1.1 A taxonomy that aligns UUV autonomy and control

functionality with the UUV autonomy and control terminology
is provided in Table X1.1.

21
 F2541 – 06
TABLE X1.1 Taxonomy for UUV Autonomy and Control
Concept of Operation Decisionmaking, Planning Common Relevant Prognostic Health
Collaboration Autonomy
(CONOPS) and Control Operating Picture Management
Unattended System Planning Function Platform Independence Fusion Built-in Test Autonomous
Team of Teams or Plan Teaming Sensor Self-Diagnosis Semi-Autonomous
Systems of Systems
Unmanned System (UMS) Dynamic mission planning Cooperation Sensor Fusion Fault Tolerance Fully autonomous
Unmanned Undersea Mission Coordination Sensory Processing Self-Healing Behavior
Vehicle
Mission Planning Controlling Element Data Fusion Capabilities
Mission Orders Operator Control Unit Information Fusion Rules
Methods of Control Orders World Model
Teleoperation Remote Control Waypoint
Telepresence Geodetic Capability
Tether Mobility
External Interaction Orientation
External Intervention Client
Goal Authorized Client
Utility Environment
Priority Terrain
Constraints Terrain Visualization
Markers (physical/ Obstacle
electronic)
Contingency Observation
Sortie Object Awareness
Sortie Plan Perception
Sortie Orders Hazard Avoidance
Tactical Behavior Situational Awareness
Task Threat Levels
Task Decomposition Threat Avoidance

X2. LEVELS OF AUTONOMY BACKGROUND

X2.1 The levels of autonomy for a UUV are determined by
the level of self-governing related to its mission complexity,
environmental difficulty, and level of external input required to
accomplish its goals. Defining levels of autonomy in a useful
form is a difficult task. To define it across a broad range of
unmanned vehicle environments increases this difficulty. Dif-
ferent organizations have defined levels of autonomy in various
domains and mission areas. These include:
X2.1.1 Army Future Combat Systems (FCS) levels of
autonomy (16)
X2.1.2 NASA Smart levels of autonomy (Proud) (17)
X2.1.3 Army Science Board levels of autonomy (11)
X2.1.4 Uninhabited Combat Air Vehicle levels of au-
tonomy7
X2.1.5 Autonomous Control Level Chart (Clough-Air
Force Research Lab) (12)
X2.1.6 FLOAAT Level of Automation and Autonomy
Scales (18)
X2.2 Each application domain provides specificity to the
level of autonomy definitions. These definitions are not fully
applicable to the UUV domain because of this tailoring. Other
7
From NSB document.

TABLE X2.1 Levels of Autonomy

Mission
<mission definition>
<mission definition>
<mission definition>
Decision-making,
Situational Awareness External Interaction
Environment Planning and Execution
Level of Autonomy Level of Autonomy
Level of Autonomy
<environment definition> 3 3 2
<environment definition> 5 3 4
<environment definition> 5 5 4

22
 F2541 – 06
organizations have defined autonomy from a more general
perspective. These include:
X2.2.1 Sheridan’s scale of degrees of automation (19)
X2.2.2 NIST Autonomy Levels for Unmanned Systems
(ALFUS)(13)
X2.3 This guide limits the definition of the levels of
autonomy to the scope of UUVs, enabling a more precise and
useful definition. The goal is to provide terminology and
meaning that can be applied in specification and acquisition of
a UUV system or a system-of-systems (team of UUVs).
X2.4 Determination of Autonomy Level Axes:
X2.4.1 One of the difficulties when attempting to define the
levels of autonomy for a domain is to define the category to
which the levels apply. Some attempts have used Boyd’s
OODA loop as the categories to which autonomy levels apply.
Others have broken autonomy into two fundamental arenas: (1)
situational awareness including observation and perception,
and (2) decision-making including the capability to plan and
act. Still others have focused more on the level of human
interaction (Sheridan). Each of these approaches has chosen
the degrees of freedom to which autonomy levels apply.
X2.4.2 There are several degrees of freedom that were
considered in the derivation of the levels of autonomy. These
degrees of freedom include mission complexity, operational
environment, complexity of reasoning, amount of required
external control, and functional capability complexity. If a
single monolithic scale to represent LOA is chosen, there will
be ambiguity related to these categories. For example, an
earthworm is highly autonomous but does not require complex
reasoning and does not make complex decisions. Alternatively,
a UUV with a high level of autonomy in situational awareness
(one that perhaps has complex algorithms for object identifi-
cation) may be required to have all target identification
decisions confirmed by an operator. This gives it a low level of
operator autonomy but a higher level of situational awareness
autonomy.
X2.4.3 To capture these degrees of freedom, three primary
axes are defined: (1) situational awareness level of autonomy,
(2) decision-making, planning and execution level of au-
tonomy, and (3) external interaction level of autonomy. The
first two are neither fully dependent nor fully independent of
each other. In general, a higher autonomy level in situational
awareness will correspond to a higher level of autonomy in
decision-making, planning and execution. However, this is not
necessarily so. For example, in an ISR scenario, the situational
awareness could include a high level of autonomy to perform
data capture, interpretation, and transmission where the
decision-making, planning and execution might be at a lower
level of autonomy to simply follow a set of waypoints and
active sensors at specified times.
23
X2.4.4 The third axis is less dependent on the other two. It
defines the level of required interaction with an external
source. This external source would normally be an external
operator but could also be an external system that controls the
UUV or could represent interactions in a multi-vehicle system-
of-systems. This axis represents the “required” level of inter-
action. The external interface level of autonomy should not
limit an external operator from “optionally” overriding vehicle
control or directly accessing low-level capabilities. The level
of autonomy only means that it is not required. So, there could
be many optional external operator controls provided on a
UUV that has a high level of autonomy. The external interac-
tion level of autonomy simply specifies the level at which the
UUV “can” operate independently unless directed otherwise.
The level of autonomy does not limit the amount of “non-
required” operator interaction.
X2.4.5 These axes sufficiently cover three of the degrees of
freedom described earlier, but do not cover the complexity of
the mission or of the environment. The environment is not
included in the levels of autonomy because the specific
environment in which a vehicle is placed does not affect its
designed level of autonomy. It may not perform as well in a
particularly difficult environment, but this does not change the
system’s level of autonomy. The mission complexity is cap-
tured partially in the decision-making, planning and execution
level of autonomy in that it can solve certain problems by
design. However, the real-time specification of specific mission
constraints for a given problem does not affect the designed
system level-of-autonomy.
X2.4.6 In order to capture the mission and environment
considerations, the three axes should be specified in terms of
the mission and environment. For example, in a difficult
environment with complex mission tasking, the levels of
autonomy across the three axes may differ from those in a less
complex environment and with a simpler mission assignment.
The levels of autonomy should be specified as shown in Table
X2.1.
X2.4.7 It is recommended that specification for varying
missions and environments be minimized to limit proliferation
of the levels.
X2.4.8 It is recommended that system specification should
not impose levels of autonomy to specific architectural ele-
ments (subsystems or components). For example, it would be
better to specify an overall level of situational awareness level
of autonomy on a UUV rather than to a specific subsystems of
the UUV such as to an “autonomy control subsystem” or a
“payload.” Imposing where autonomy occurs could constrain
the system design and could be a cost driver. An example of
this is the use of a UUV as a “truck” to carry payloads that
perform the primary mission function. If high levels of
autonomy are specified for the “truck” part of the vehicle, it
may drive the design and result in a higher cost.
 F2541 – 06
REFERENCES

(1) The American Heritage Dictionary, Houghton Mifflin Company.
(2) TRADOC Pam 525-3-90, UA O& O Plan, “Objective Force Maneuver
Units of Action”, derived from JP 1-02, Ft Huachuca White Paper,
Fusion (13 January 03 (and previous versions), and Senior Leader’s
Meeting (ICT#4, with the Combined Arm’s Center’s “10 Big Ideas.”
(3) Joint Directors of Laboratories (JDL), Technology Panel on C3
(TPC3), Data Fusion SubPanel (DFSP).
(4) Albus, J., et al., 4D/RCS Reference Model Architecture, NISTIR 6910,
National Institute of Standards and Technology, Gaithersburg, MD,
August 2003. http://www.isd.mel.nist.gov/projects/rcs/.
(5) Webster’s II New Riverside University Dictionary, Houghton Mifflin
Co., 1988.
(6) Doshofy, Eric M., et al, Towards Architecture-based Self-Healing
Systems, Institute for Software Research, WOSS (Workshop On
Self-healing Systems) 2002, Nov 18-19, 2002, Charleston, SC.
(7) 2003 JRP Master Plan. http://www.jointrobotics.com/activities_new/
FY2003%20Joint%20Robotics%20Master%20Plan.pdfhttp://
www.jointrobotics.com/activities_new/
FY2003%20Joint%20Robotics%20Master%20Plan.pdf.
(8) FMECA Project Website: About the Project, www.fpni.net, Fluid
Power Net International, 1998.
(9) Webster’s New World Dictionary, Third College Edition.
(10) TRADOC Pamphlet 525-41, Topographic Support for Terrain Visu-
alization and TRADOC Pamphlet 525-70, Battlefield Visualization
Concept.
(11) Army Science Board, Ad Hoc Study on Human Robot Interface
Issues, Arlington, VA, 2002.
(12) Clough, B., “Metrics, Schmetrics! How do you Track a UAV’s
Autonomy?,” Proceedings of AIAA 1st Technical Conference and
Workshop on Unmanned Aerospace Vehicles, 2000.
(13) Huang, H. M., Messina, E., and Albus, J., Toward a Generic Model
for Autonomy Levels for Unmanned Systems (ALFUS), Gaithersburg,
MD, 2004.
(14) Intelligent Sensor, www.allboutmems.com/glossary, All About
MEMS (MicroElectroMechanical Systems), 2002.
(15) National Research Counsel, Autonomous Vehicles in Support of
Naval Operations, The National Academies Press, Washington, DC,
2005.
(16) O’Donell, W., Future Combat Review Presentation, LOCATION
TBD, 2003.
(17) Proud, R. W., Hart, J. J., and Mrozinski, R. B., Methods for
Determining the Level of Autonomy to Design into Human Space-
flight Vehicle: A Function Specific Approach, Houston, TX, DATE-
TBD.
(18) Proud, R. W., and Hart, J. J., FLOAAT, A Tool for Determining
Levels of Autonomy and Automation, Appleid to Human-Rated Space
Systems, Houston, TX, 2005.
(19) Sheridan, T. B., Telerobotics, Automation, and Human Supervisory
Control, The MIT Press, 1992.

RELATED MATERIAL

Blasch, E., and Plano, S., “JDL Level 5 Fusion Model: User Refinement
Issues and Applications in Group Tracking,” SPIE Vol 4729, Aero-
sense, 2002, pp. 270-279.
Institute of Electrical and Electronics Engineers, IEEE Standard Com-
puter Dictionary: A Compilation of IEEE Standard Computer Glossa-
ries, New York, NY, 1990.
Joint Publication 1-02, “DOD Dictionary of Military and Associated
Terms,” http://www.dtic.mil/doctrine/jel/doddict/.
Objective Force Fusion White paper dated 14 March 2003.
Sander, W. A., “Information Fusion,” International Military and Defense
Encyclopedia, Dupuy, T. N., et al, eds., Vol 3, G-L, Brassey’s, Inc.,
1993, pp.1259-1265.

ASTM International takes no position respecting the validity of any patent rights asserted in connection with any item mentioned
in this standard. Users of this standard are expressly advised that determination of the validity of any such patent rights, and the risk
of infringement of such rights, are entirely their own responsibility.

This standard is subject to revision at any time by the responsible technical committee and must be reviewed every five years and
if not revised, either reapproved or withdrawn. Your comments are invited either for revision of this standard or for additional standards
and should be addressed to ASTM International Headquarters. Your comments will receive careful consideration at a meeting of the
responsible technical committee, which you may attend. If you feel that your comments have not received a fair hearing you should
make your views known to the ASTM Committee on Standards, at the address shown below.

This standard is copyrighted by ASTM International, 100 Barr Harbor Drive, PO Box C700, West Conshohocken, PA 19428-2959,
United States. Individual reprints (single or multiple copies) of this standard may be obtained by contacting ASTM at the above
address or at 610-832-9585 (phone), 610-832-9555 (fax), or service@astm.org (e-mail); or through the ASTM website
(www.astm.org). Permission rights to photocopy the standard may also be secured from the ASTM website (www.astm.org/
COPYRIGHT/).

24