Preliminary Report 

STATEMENT OF REQUIREMENTS FOR URBAN 

SEARCH AND RESCUE ROBOT PERFORMANCE 

STANDARDS

PRELIMINARY VERSION

MAY 13, 2005 

Department of Homeland Security 

Science and Technology Directorate 

and 

National Institute of Standards and Technology

1 
Preliminary Report 

The following authors contributed to this report: 

Elena Messina1

, Adam Jacoff1, Jean Scholtz1, Craig Schlenoff1, Hui-Min Huang1, Alan 

Lytle1

, John Blitch2

1 National Institute of Standards and Technology 2 Blitz Solutions Inc.

Acknowledgements 

The NIST team working toward developing standard test methods for urban search and

rescue robots would like to thank Dr. Parney Albright and Dr. Bert Coursey and their 

staff of the DHS for their guidance. We are very grateful to the Federal Emergency 

Management Agency (FEMA) Urban Search and Rescue (US&R) management team, 

especially Mr. Peter Smalley, for all their help in getting us started. Many thanks also to 

the FEMA Task Force members for their enthusiastic support and significant 

contributions in defining performance requirements for US&R robots. We would like to 

thank Mr. John Blitch for sharing his vast military and emergency response robotics work 

and experiences with the responders to expose them to the potential impact of this effort. 

We also gratefully acknowledge Dr. James Filliben of the NIST Statistical Engineering 

Division for all his hard work and insights into how to interpret the data that we collected. 

Disclaimer 

Certain commercial equipment, instruments, or materials are identified or displayed in

this document. Such identification does not imply recommendation or endorsement by 

the National Institute of Standards and Technology, nor does it imply that the products 

identified are necessarily the best available for the purpose. 

1 
Preliminary Report 

REPORT INTRODUCTION

This report documents an initial set of requirements for the performance of robots that can support urban 

search and rescue (US&R) roles and tasks. These requirements were captured during three workshops held

at NIST between November 2004 and February 2005, which included members from twenty FEMA Task 

Forces and the National Guard. This initial set of requirements will guide efforts to establish standard test 

methods for performance and use of US&R robots. As these efforts evolve, so will the set of working 

requirements. Updated versions of this report will be released periodically to document the process and

publicize proposed test methods. 

The structure of this document is as follows. Chapter 1 includes an introduction to the overall program, 

objectives, technical approach, and timeline for developing standard test methods based on captured

performance requirements. Chapter 2 describes the requirements definition process. In this chapter, we

present the methodology used to capture the initial set of requirements from the eventual users of US&R 

robots – the emergency responders – as well as the process used to determine the most widely applicable 

requirements. Chapter 3 lists candidate requirements to guide the first wave of test methods to be

developed and introduced into the standardization process. Chapter 4 discusses sample test methods to help

convey our approach. Chapter 5 discusses the next steps for the program. Chapters 6 and 7 discuss two 

associated efforts: classifications of robot capabilities and of building and collapse types. Chapter 8

introduces efforts to compile a compendium of robot capabilities, including the results of the standard 

performance tests developed under this program. The Appendices list additional reference information. 

Appendix A summarizes the participants in the workshops that defined the initial performance 

requirements. Appendix B contains the entire list of robot requirements resulting from the three workshops 

held with responders. Appendix C documents the emergency responders’ voting results for each 

requirement’s applicability to robot types and deployment scenarios generated to focus discussions. This

data was the basis for selecting the initial subset of requirements to begin the process of developing

standard test methods. Appendix D contains a two-part Glossary: US&R terminology and unmanned 

system terminology. These are included primarily to serve future expansions of this document.

2 
Preliminary Report 

TABLE OF CONTENTS

Report Introduction ...............................................................................................2

Table of Contents..................................................................................................3

Chapter 1...........................................................................................................4

Standard Test Methods for Performance and Use of Urban Search and Rescue 

Robots: Program Background...............................................................................4

Overall Process and Rationale ......................................................................................6

Chapter 2...........................................................................................................9

Performance Requirements Definition ..................................................................9

Performance Requirements Data ................................................................................14

Analysis of Requirements Data....................................................................................15

Chapter 3.........................................................................................................17

Candidate Wave 1 Requirements .......................................................................18

Chapter 4.........................................................................................................25

Test Methods ......................................................................................................25

Example Test Method: Real-Time Vision System Acuity.............................................25

Test Methods for Human-Systems interaction Requirements .....................................27

Chapter 5.........................................................................................................30

Next Steps ..........................................................................................................30

Chapter 6.........................................................................................................33

Robot and Capabilities Classification..................................................................33

Chapter 7.........................................................................................................37

Building and Collapse Types ..............................................................................37

Chapter 8.........................................................................................................39

Compendium of Robot Capabilities.....................................................................39

References .........................................................................................................42

Appendix A – Requirements Definition Workshop Participants...........................43

Appendix B – Complete Initial Requirements List ...............................................44

Appendix C: Total Number of Votes Received by each Requirement versus 

Robot/Deployment Category...............................................................................59

Appendix D - Glossary ........................................................................................71

3 
Preliminary Report 

Chapter 1 

STANDARD TEST METHODS FOR PERFORMANCE AND USE 

OF URBAN SEARCH AND RESCUE ROBOTS: PROGRAM

BACKGROUND

In an effort to accelerate the development and deployment of robotic tools for urban search and rescue 

(US&R) responders, the National Institute of Standards and Technology (NIST) has begun the process of

developing test methods for robotic technologies applied to US&R requirements. This effort will foster 

collaboration between US&R responders and technology developers to define performance metrics, 

generate standard test methods, and instrument test sites to capture robot performance in situationally

relevant environments. The results of these standard performance tests will be captured in a compendium of 

existing and developmental robots with classifications and descriptors to differentiate particular robotic 

capabilities. This along with ongoing efforts to categorize situational US&R constraints such as building 

collapse types or the presence of hazardous materials will help responders match particular robotic 

capabilities to response needs. In general, these efforts will enable responders to effectively use robotic 

tools to enhance their effectiveness while reducing risk to personnel during disasters. 

There are several possible ways to enhance the effectiveness of emergency responders through technology, 

but such solutions must be proven useful to the responder community prior to deployment in the field. 

Standardized test methods generated directly from responder requirements can ensure that applicable 

technologies are relatively easy to use, integrate efficiently into existing infrastructure, and provide 

demonstrable utility to response operations. Studies on ways to improve effectiveness of US&R and other 

responders have identified robots as potentially high-impact solutions. The Department of Homeland 

Security (DHS) Federal Emergency Management Agency (FEMA) and the National Institute of Justice 

(NIJ) co-sponsored an effort to identify and define functional requirements for new and/or improved

technologies that meet the needs of both US&R teams as well as law enforcement agencies. The report [1] 

listed high priority needs, which included:

“Reliable non-human, non-canine search and rescue systems - robust systems 

that combine enhanced canine/human search and rescue capabilities without

existing weaknesses (i.e., robots)”

Another noteworthy report sponsored by DHS and the National Memorial Institute for the Prevention of 

Terrorism, “Project Responder: National Technology Plan for Emergency Response to Catastrophic 

Terrorism” [2], makes several mentions of robots as potentially useful to responders; but states that the 

technology needs to be further developed. It notes that specific requirements must first be defined. For 

example: 

“Sensor suite for robotics is a question of requirements, packaging and cost, 

not engineering. Radar can be made to work with robotic arms, etc. 

Requirements need to be generated to match the responder mission (weight

constraints, power, endurance, standards, etc.).” 

“Development of requirements for applying the various sensor suites, 

platforms, robotics, batteries, etc. which already exist.” 

 

Standard test methods generated from explicit requirements for US&R robots, with objective performance 

metrics and repeatable performance testing, will accelerate the development and deployment of mobile 

4 
Preliminary Report 

robotic tools for US&R responders. Currently, no such standards or performance metrics exist, although

some guidelines for performance, capabilities, and human-system interactions have been identified [5,6]. 

In order to address this need, the DHS Science and Technology (S&T) Directorate initiated an effort in

fiscal year 2004 with NIST to develop comprehensive standards to support development, testing, and

certification of effective robotic technologies for US&R applications. These standards will address robot 

mobility, sensing, navigation, planning, integration into operational caches, and human system interaction.

Such standards will allow DHS to provide guidance to local, state, and federal homeland security 

organizations regarding the purchase, deployment, and use of robotic systems for US&R applications. 

The NIST team working toward developing these standard test methods is closely following the guidance 

provided by the above-mentioned studies. This effort builds on requirements voiced by US&R responders 

and focuses on fostering collaboration between the responders, robot vendors, and robot developers to

generate consensus standard tests for task-specific robot capabilities and interoperability of components. 

Furthermore, the effort includes the development and administration of technology readiness level (TRL) 

assessment exercises. These exercises will generate statistically significant performance data for 

developmental and fieldable robotic systems. 

In order to ensure the relevance and viability of robots to US&R, the program will follow a multi-year, 

iterative process, shown conceptually in Figure 1. The high-level effort areas and corresponding timeline 

are shown in Figure 2. To ensure that results are available as soon as possible, the effort is staged into two 

“waves,” with the highest priority requirements that appear to be technologically attainable targeted for 

deployment in the FY06-FY08 timeframe. A second wave will address the remaining requirements; adding

new requirements as necessary, while leveraging the standards process initiated in the first wave

he entire program is structured to ensure that the end-users’ needs are captured and addressed. There will 

hese 

measures 

Standards 

Development

Requirements

Development 

Performance &

Interface

Standards

Evaluation

Development

Validation of

Standards and

Evaluations

DEPLOYMENT

Figure 1: DHS US&R Robot Standards Process

T

be annual workshops to monitor progress as well as several events that allow responders to work with

emerging robotic equipment in realistic environments while helping to refine proposed test methods. T

events are shown on the timeline as technology readiness level (TRL) assessment exercises. The 

requirements defined by the responders will be the foundation for constructing robot performance

along with testing and evaluation (T&E) protocols that will provide reproducible methods for assessing and 

comparing the effectiveness of overall robotic systems and key components. Test sites will be developed 

that realistically evaluate these robot’s capabilities, along with supporting measurement infrastructure to 

facilitate characterization of the test sites and to capture robot performance during test administration.

5 
Preliminary Report 

Ultimately, the goal is to have one or more sites certified to perform this program’s standard test method

and provide ongoing robot performance testing. Initially, each site will focus on specific aspects of the 

overall robotic systems (mobility for example), to avoid issues of conformity between test sites. Finally,

recognition that these novel tools need to be integrated into existing responder operations, new standard

operating procedures may be developed, along with corresponding training and deployment plans. 

s 

in

VERALL ROCESS AND ATIONALE

his program will follow the same general approach used in the other DHS S&T standards development 

g 

d 

communication, and information. 

Wave 1 Wave 2

Requirements

Workshops

FY05 FY06 FY07 FY08 FY09 FY10

Certified

testing sites

Classifications:

Disaster Type, Building Collapse, 

Robot Capabilities

Performance Standards: Requirements, Test Methods, Standards

Final Versions

Of Classifications

To Guide

Performance

Standards and

Deployment of Robots

Operational Performance Standards

Interfaces

& test procedures

Test Sites: Calibration, Characterization,Instrumentation

Deployment: Operating Procedures, Training Guidelines

New Standard

Operating

Procedures

TRL, Operational Exercises

FY05 FY06 FY07 FY08 FY09 FY10

Program Outputs

Release Requirements

Workshops

Technology Events

Release Wave 1 Tests, Standards

Release Wave 2 Tests, Standards

Figure 2: Timeline for DHS US&R Robot Standards Program 

O P R

T

and implementation projects. For each component of US&R robots, guidelines for the performance 

requirements will be developed as a collaborative effort among users (subject matter experts), tool 

developers, and standards experts. Requirements and guidelines will be defined using information related

to the capabilities – and the limitations – of the components, and on the conditions in which the component

and system are expected to operate. The guidelines will be the foundation for constructing performance 

measures along with testing and evaluation protocols that will provide a reproducible method for assessin

and comparing the effectiveness of each system component and of the overall robotic system supporting

homeland security. Performance measures will encompass the following: basic functionality, adequacy an

appropriateness for the task, interoperability, efficiency, and sustainability. The components of the robot 

systems include platforms, sensors, operator interfaces, software, computational models and analyses,

6 
Preliminary Report 

A national measurements and standards infrastructure for US&R robot software, hardware, and processes 

at supports the homeland security user group will be established. The primary objective of this 

infrastructure for homeland security 

ardware, software and processes is the development of consensus performance standard test methods. This

US&R robots and related technologies. The 

ational measurements and standards infrastructure will ultimately include common guidelines for federal, 

ble 1. The high-level technical 

bjectives generated in response to the program needs are listed in this table. The technical objectives

e 

t

opment cycle includes the following phases: 

ed by NIST) 

pers, facilitated by NIST) 

opers, facilitated by NIST) 

able 1: Rationale for Technical Approach 

tion

th

infrastructure in its initial phase is the development of requirements, guidelines, performance metrics, test 

methods, certification, reassessment, and training procedures. 

One of the key parts of the national measurements and standards

h

project will leverage existing expertise by establishing a working relationship between these Standards 

Development Organizations (SDOs) and other federal agencies to develop consensus requirements and

performance standard test methods for US&R robot products and processes. Information available from

international efforts will also be evaluated for inclusion.

This process will build on existing approaches for testing

n

state and private sector test and evaluation laboratories for evaluating performance of US&R robot 

technologies against national consensus standards 

The overall technical rationale for this program is summarized in Ta

o

were mapped onto major tasks within the program. The focus of this report is on the early phases of th

program. An iterative development approach will be used to produce initial versions of performance 

metrics and standards as quickly as possible, and then refine them based on continuing input from the firs

responder community, researchers, and robot suppliers, and performance testing within representative 

environments. 

The standards devel

1) Requirements definition and prioritization (users, facilitat

2) Draft standard test methods and metrics (users and develo

3) Refinement and validation of test methods and metrics (users and devel

4) Standards publication and dissemination (by SDOs) 

T

Needs Solu

Characterizations of deployment - Id

environments and scenarios do not 

entify/generate a taxonomy of building collapses and 

scenarios (see Chapter 7)

exist 

disaster

- Define robot performance requirements according to 

disaster/building taxonomy

Mobile robot technologies (hardware 

nd software) need to be identified, 

wer, locomotion, operator

- 

ve

nce

n representative environments 

- 

luate the maturity of components and 

a

directed toward real-world 

scenarios, and proven through 

objective testing 

- Generate a taxonomy of robot technologies and 

capabilities (See Chapter 6)

- Define performance requirements for physical platform, 

sensors, communications, po

interface, and all other component technologies (See

Chapters 2 & 3) 

Develop standard performance metrics based on 

requirements abo

- Define test methodologies for evaluating performa

of above components i

(See Chapter 4) 

Apply technology readiness level (TRL) assessment 

techniques to eva

systems (see Chapter 5) 

7 
Preliminary Report 

- 

- r defined interfaces

Where relevant, define interface standards to develop

Define compliance tests fo

Robots need to be integrated as 

tools in the disaster response infrastructure, FEMA tools caches, and maintenance 

- 

communications) 

- efined interfaces 

infrastructure 

- Identify strategy for integration into response 

schedules 

Ensure that no conflicts with existing infrastructure 

arises (e.g. 

- Define interface standards where appropriate 

Develop compliance tests for d

Robots need to be integrated into 

first responder operations 

ance 

edures 

- Based on disaster taxonomy and robot perform

definitions, develop new standard operating proc

- Provide training 

8 
Preliminary Report 

Chapter 2 

PERFORMANCE REQUIREMENTS DEFINITION

The process to define US&R robot performance requirements began by assembling a group of subject

matter experts, primarily FEMA Task Force leaders and specialists. Representatives from most FEMA 

Task Forces participated in some or all three workshops held to define initial performance requirements for 

the robots. Appendix A lists the participants. 

Urban search and rescue teams are comprised of a large number of individual specialists who perform

specific functions. The search and rescue operation itself is divided into several phases, which are roughly

sequential in order, although some may be carried out in parallel. Basic responsibilities during a rescue

effort were identified as reconnaissance, primary search, structural assessment, stabilization, medical, 

rescue, monitoring, hazardous materials, and others. During the course of the first workshop, the working 

group identified two particular roles, reconnaissance and primary search, as the two highest priorities for 

applying robots. 

To aid the process of defining requirements for US&R robots, different approaches were tried during the 

workshops. Initially, the responders defined several robot access categories to help focus the discussions: 

2 inch bore hole, 24 inch triangular hole, doorway, and aerial, shown in Figure 3. The first three are based

on current access methods used by responders. The aerial category was added since it seemed desirable for 

upper stories that are difficult to access otherwise. 

Figure 3: Initial access categories: 2 inch bore hole, 24 inch triangular hole, doorway, and aerial. 

The responders generated three scenarios to put the discussions into context, shown in Table 2. These

scenarios were used to facilitate discussions and are not meant to be comprehensive. The responders were 

asked to develop specific robot requirements for each scenario, metrics to measure performance, and 

associated objective/threshold values they expect would be useful for those environments. 

By the third workshop, a more detailed set of situations was needed to stimulate the responders to fully 

consider how the robots would be used in reality, and to make sure everyone was envisioning the same

thing. Thirteen robot categories developed during prior robotics programs at the Defense Advanced

Research Projects Agency (DARPA) and elsewhere were adopted to provide this focus. They are shown in 

Table 3. These are not necessarily meant to define specific robotic implementations desired for US&R, 

since it is premature to make these decisions. However, some of them may in fact provide reasonable 

approximations of robotic capabilities that will be identified by responders as “high priority” while being 

considered “fieldable” in the near term by developers. This combination of high priority and technical 

availability will be targeted for Wave 1 test methods.

9 
Preliminary Report 

Integrated product and process development (IPPD) methods and the Dynamic Insight

© software tool were 

used to capture and document the requirements defined by responders. Dynamic Insight captures customer 

requirements in detail, including descriptions, objective values and thresholds, and how the requirements 

will be measured for conformance. Candidate technologies (in our case, robotic systems from particular 

vendors) can later be evaluated with respect to the requirements and the results will be highlighted through 

radar charts. Sample forms used to illustrate the level of detail possible using IPPD are shown in Figure 4. 

Figure 5 shows samples of radar charts that would be used to measure how well a particular solution 

addresses the main requirements categories (spokes) as well as the risk that technology poses in addressing 

each category’s requirements. The risk is assessed by a panel of experts and developers who evaluate the 

maturity of the candidate technology among other criteria. 

Figure 4: Hierarchical requirements capture using IPPD methods. These images illustrate the level of detail in the 

requirements capture. For each individual requirement several data points are captured: descriptions, metrics,

priorities, performance objectives, acceptable thresholds, and desirability curves. Desirability curves capture the intent 

of the responders for the range between the threshold and the objective performance values for a given requirement.

10 Figure 5: Radar charts for candidate solutions are measured against required performance objectives and thresholds

to fill in major axes of chart. The risk associated with the technical solution, assessed by experts and developers, is 

the overlaid to show trade-offs of expected benefits versus risk. 
Preliminary Report 

Table 2: Scenarios 

11 
Preliminary Report 

Table 3: Potential Robot or Deployment Categories 

Robot Category Employment Role(s) Deployment Method(s) Tradeoffs 

1. 

Ground: Peek

Robots

Provide rapid audio 

visual situational 

awareness; provide 

rapid HAZMAT

detection; data logging

for subsequent team 

work

Tossed, chucked, thrown 

pneumatically, w/surgical tubing; 

marsupially deployed 

Trade mobility, 

duration, sensing for 

increased expendability

2. 

Ground: 

Collapsed 

Structure--

Stair/Floor 

climbing, map, 

spray, breach

Robots

Stairway & upper floor 

situational awareness; 

mitigation activities; 

stay behind monitoring

Backpacked; self driven; 

marsupially deployed 

Experience form factor

for increased mobility, 

sensing, manipulation; 

mapping variant; 

spraying variant; 

breaching variant 

3. 

Ground: Noncollapsed 

Structure--Wide 

area Survey 

Robot

Long range, human 

access stairway & 

upper floor situational 

awareness; 

contaminated area 

survey; site

assessment; victim 

identification; mitigation 

activities; stay behind 

monitoring 

Backpacked; self driven; 

marsupially deployed 

Experience form factor

for increased mobility, 

sensing, manipulation; 

mapping variant; 

spraying variant; 

breaching variant 

4. 

Ground: Wall 

Climbing Deliver 

Robots

Deliver Payloads to 

upper floors; provide 

expanded situational 

awareness when aerial 

platforms are 

unavailable or

untenable 

Placed; thrown 

pneumatically, w/surgical tubing; 

marsupially deployed 

Trade payload capacity 

for vertical mobility and 

stable perching 

5. 

Ground: 

Confined Space, 

Temporary 

Shore Robots 

Adaptive, temporary 

shoring; provide stay 

behind monitoring; 

victim triage & support Placed: lowered via tether 

Trade mobility and 

payload capacity for 

shoring capacity 

6. 

Ground: 

Confined Space 

Shape Shifters 

Search; provide stay 

behind monitoring Placed; lowered via tether 

Trade payload capacity 

for confined space 

access 

12 
Preliminary Report 

Robot Category Employment Role(s) Deployment Method(s) Tradeoffs 

7. 

Ground: 

Confined Space 

Retrieval Robots 

Retrieve objects from 

confined spaces; 

provide stay behind

monitoring Placed; lowered via tether 

Trade sensing capacity 

for manipulators, 

confined space access

8. 

Aerial:High 

Altitude Loiter 

Robots

Provide overhead 

perspective & sit. 

awareness; provide 

HAZMAT plume 

detection; provide 

communications 

repeater coverage 

Released: balloon or F/W; 

tethered LTAF (kite)

Trade penetration 

capacity for vertical 

perspective 

9. 

Aerial: Rooftop 

Payload Drop

Robots

Payload delivery to 

rooftops; provide 

overhead perspective; 

provide 

communications 

repeater coverage 

Launched F/W; tethered LTAF 

(kite)

Trade penetration 

capacity & loiter time 

for vertical drop 

10. 

Aerial: Ledge

Access Robot

Object retrieval from 

upper floors; crowd 

control with a

loudspeaker object 

attached, provide 

situational awareness 

Launched Vertical Take-off and 

Landing (VTOL); VTOL 

Trade simplicity, 

penetration capacity, 

loiter time for precise 

vertical drop 

11. 

Aquatic: Variable 

Depth Sub 

Robot

Structural inspection; 

leak 

localization/mitigation; 

object (body) recovery 

Dropped into water; lowered via 

tether 

Trade ground mobility 

for sub surface access 

& free swim capacity 

12. 

Aquatic: Bottom 

Crawler Robot 

Water traverse; rapid 

current station keeping; 

object recovery

Driven across water; lowered via 

tether 

Pursue amphibious 

mobility at cost of other 

performance

13. 

Aquatic: Swift 

Water Surface 

Swimmer 

Upstream access and 

station keeping; 

payload delivery; 

object recovery

Dropped into water; marsupially 

deployed

Pursue swift water 

capacity at cost of

other performance 

13 
Preliminary Report 

PERFORMANCE REQUIREMENTS DATA

The series of three requirements definition workshops produced a total of 103 requirements by the 

responders. The requirements fit into the major categories listed in Table 4. The individual requirements 

and a description of each are shown in Appendix B. 

Table 4: Main Requirement Categories 

Requirements Category

Number of 

Individual 

requirements Category Definition

Human-System Interaction 23 

Pertaining to the human interaction

and operator(s) control of the robot

Logistics 10

Related to the overall deployment

procedures and constraints in place

for disaster response 

Operating Environment 5 

Surroundings and conditions in

which the operator and robot will 

have to operate 

System

Overall physical unit comprising the

robot. This consists of the subcomponents below 

 - Chassis 4 

The main body of the robot, upon 

which additional components and

capabilities may be added. This is

the minimum set of capabilities 

(base platform). 

 - Communications 5 

Pertaining to the support for 

transmission of information to and

from the robot, including 

commands for motion or control of 

payload, sensors, or other 

components, as well as underlying

support for transmission of sensor 

and other data streams back to 

operator 

 - Mobility 12 

The ability of the robot to negotiate

and move around the environment

 - Payload 7 

Any additional hardware that the 

robot carries and may either deploy

or utilize in the course of the 

mission 

 - Power 5 

Energy source(s) for the chassis 

and all other components on board 

the robot 

 - Sensing 32 

Hardware and supporting software

which sense the environment

 

14 
Preliminary Report 

ANALYSIS OF REQUIREMENTS DATA

In order to identify the most widely applicable requirements for our Wave 1 emphasis, the responders were

asked to indicate in an electronic spreadsheet which requirements were applicable for each of the thirteen 

robot categories defined previously. Each Task Force was given a single spreadsheet (one vote) even if

there were more than one representative from that Task Force in attendance. A total of thirteen Task Forces 

participated in this particular exercise. 

The individual spreadsheets with the votes by each Task Force were collected into a single file, which was 

used as a starting point for statistical analyses. The initial summarization of the results was the totaling of

the number of votes each requirement got for a given robot category. This was done by counting the nonzero cells across all the task force spreadsheets for a given requirement/robot category pairing. So, for

example, the Human-System Interaction Requirement “Self Extraction” was deemed necessary by only 2 

Task Forces in “peek robot” whereas 11 Task Forces thought it was a necessity for a “non-collapsed

structure or wide area survey robot.” Not surprisingly, some requirements showed wide variability with

respect to the robot categories. The summary, which indicate the number of votes each requirement got for 

a given robot category, is shown in Appendix C. 

Four key measures were computed for each requirement. For each of the 103 requirements, the following 

were calculated looking across the votes by all 13 task forces: 

1. The average number of robot categories for which the requirement was considered applicable 

2. The median number of robot categories for which the requirement was considered applicable 

3. The maximum number of robot categories for which the requirement was considered applicable

4. The minimum number of robot categories for which the requirement was considered applicable

Two additional global measures were computed. The grand mean (average) of robot categories for all 

requirements was computed to be 8.105. The median number of robot categories to which each

requirement was voted applicable was 8.

An initial pass at filtering the data based on a joint criterion yielded the 21 most commonly applicable 

requirements. Let Y be the score, which is the number of robot categories that a requirement was voted as 

being applicable to. The four factors comprising the joint criterion are described below:

1. 

The average of the ith requirement Y is greater than or equal to the grand average for the total 

dataset. This means that a requirement must have been found applicable to at least 8.105 different 

robot categories. 

Yi ≥ Y 

2. Med(Yi) ≥ 10

The median for the ith requirement is at least in the double digits. This means that a requirement’s 

median number of robot categories to which it was voted applicable was more than 10. 

3. Min(Yi)≥ 8 

The minimum for the ith requirement is at least 8. This means that the minimum number of robot

categories that a requirement was found to be applicable to by any task force must be greater than

8. 

4. Max(Yi)≥ 12

The maximum for the ith requirement is at least 12. This means that the maximum number of

robot categories was found to be applicable to by any task force must be greater than 12. 

15 
Preliminary Report 

The requirements that met criteria 1 – 4 were selected as candidates for Wave 1 of the testing protocols and

standardization process. The number of requirements selected by this method was 21. The results are 

shown in Table 5 in the next Chapter.

The results of the analysis are shown graphically in the charts in Figures 6 and 7. The y axis represents the 

number of robots/situations to which the teams thought the particular requirement was pertinent. 

Figure 6: Analysis of Requirements Data. These plots show the four different parameters that 

were analyzed for the 103 requirements. The responders voted on the applicability of each 

requirement with respect to a robot/deployment category. For each requirement, the mean, 

median, minimum, and maximum score was computed. Score refers to the number of applicable 

robots/deployment categories for each requirement. 

16 
Preliminary Report 

Requirements (sorted and coded)

# Deployment Situations (or Rob

ot Categories) to 

which Req

uirement is Applicable 

Requirements (sorted and coded)

Figure 7: Combined measures of requirements' applicability to different types of robot/deployment 

categories. The top figure shows all 103 requirements ranked according to how well they meet the 

selection criteria; the bottom figure shows just the ones that best meet the criteria described in the 

text. 

17 
Preliminary Report 

CANDIDATE WAVE 1 REQUIREMENTS

This chapter lists the candidate Wave 1 requirements for which the first set of standard test methods will be

developed. These requirements are divided into two groups: Tier 1 is the set considered most widely

applicable by the voting task forces. Several 2nd Tier requirements are included in the initial Wave 1 

emphasis due to their similarity to 1st Tier requirements, allowing a single test for both. The Wave 1 

requirements are considered to be minimum competences for US&R robots. They are necessary, but not 

sufficient, for ensuring that the robots are useful and usable in the challenging application of urban search

and rescue. 

Table 5: Candidate Wave 1 Requirements 

All 1st Tier requirements (21) are included and marked with an asterisk and highlighted 

with red 

*

2nd Tier requirements (5), highlighted in yellow, are included due to their close 

connection with 1st Tier requirements, allowing inclusion in the same standard test 

methods. 

Number: 03

Type: CHASSIS

Sub-Type: ILLUMINATION

Requirement: ADJUSTABLE

Metric: YES/NO 

Description: This requirement captures the responders’ expectation to use video in confined

spaces and for short-range object identification, which can wash out from excessive illumination of the 

scene. 

Test Method: SEE REAL-TIME VISION SYSTEM ACUITY TEST 

Number: 06 *

Type: COMMUNICATIONS 

Sub-Type: N/A 

Requirement: RANGE – BEYOND LINE OF SIGHT

Metric: METERS 

Description: This requirement captures the responders’ expectation to project remote 

situational awareness into compromised or collapsed structures or to convey other types of information. 

They specifically noted that the robot should be able to ingress a specified number of meters into the worst

case collapse, which was further defined as a reinforced steel structure. This requirement also covers 

operations around corners of buildings and other locations beyond line of sight. The responders made no

distinction regarding tethered or wireless implementations to address this requirement. 

Test Method: SEE REAL-TIME VISION SYSTEM ACUITY TEST

Number: 07 *

Type: COMMUNICATIONS 

Sub-Type: N/A 

Requirement: SECURITY

18 
Preliminary Report 

Metric: SCALE 1-5 

1 = No security

3 = Command security only 

5 = Both data and command security

Description: This requirement captures the responders’ expectation to use this system in

sensitive public situations where maintaining control of remotes systems is imperative and limiting access 

to video images and other communications to authorized personnel is prudent. They added that the system

should be shielded from jamming interference and encrypted for security, but made no distinction regarding 

tethered or wireless implementations to address this requirement. 

Test Method: SEE REAL-TIME VISION SYSTEM ACUITY TEST

Number: 08

Type: COMMUNICATIONS

Sub-Type: N/A

Requirement: RANGE – LINE OF SIGHT

Metric: METERS 

Description: This requirement captures the responders’ expectation to project remote 

situational awareness or to convey other types of information down range within line of sight. The 

responders made no distinction regarding tethered or wireless implementations to address this requirement. 

Test Method: SEE REAL-TIME VISION SYSTEM ACUITY TEST 

Number: 11 *

Type: HUMAN-SYSTEM INTERACTION

Sub-Type: N/A

Requirement: INITIAL TRAINING

Metric: HOURS 

Description: This requirement captures the responders’ expectation to minimize the initial 

training necessary to become proficient in operation of the system. This training should include supporting 

material sufficient for training in the specified period and culminate in certification.

Test Method: SEE ACCEPTABLE USABILTY TEST 

Number: 12 *

Type: HUMAN-SYSTEM INTERACTION

Sub-Type: N/A

Requirement: PROFICIENCY EDUCATION

Metric: HOURS ANNUALLY 

Description: This requirement captures the responders’ expectation to minimize the annual 

proficiency training necessary to maintain certification.

Test Method: SEE ACCEPTABLE USABILTY TEST 

Number: 13 *

Type: HUMAN-SYSTEM INTERACTION

Sub-Type: N/A

Requirement: OPERATOR RATIO

Metric: NUMBER OF OPERATORS PER ROBOT 

Description: This requirement captures the responders’ expectation to minimize the number 

of operators necessary to operate any given system and perform the associated tasks effectively. 

Test Method: SEE ACCEPTABLE USABILTY TEST 

19 
Preliminary Report 

Number: 14 *

Type: HUMAN-SYSTEM INTERACTION

Sub-Type: N/A

Requirement: ACCEPTABLE USABILITY

Metric: EFFECTIVENESS (PERCENT); USER SATISFACTION (SCALE 1-5) 

Description: This requirement captures the responders’ expectation to operate any given 

system to perform the associated tasks effectively. The metric will measure the percent of timed tasks 

operators can successfully complete. This metric is discussed in greater detail in the Test Methods: 

Human-System Interaction section of this report. 

Test Method: SEE ACCEPTABLE USABILTY TEST 

Number: 26 *

Type: HUMAN-SYSTEM INTERACTION

Sub-Type: CONTEXT

Requirement: LIGHTING CONDITIONS

Metric: SCALE 1-5 

1 = Complete darkness 

3 = Daylight without direct glare 

5 = Direct glare on interface

Description: This requirement captures the responders’ expectation to view and use the

operator console in different lighting conditions. They noted that special emphasis should be placed on “no 

light” conditions and “direct glare” onto operator displays (from sunlight, helmet lights, etc.). 

Test Method: SEE ACCEPTABLE USABLITY TEST 

Number: 29

Type: HUMAN-SYSTEM INTERACTION

Sub-Type: CONTEXT

Requirement: PROTECTIVE CLOTHING

Metric: SCALE 1-5 

1 = No protection 

3 = Minimum protection (threshold) 

5 = Complete protection (objective) 

Description: This requirement captures the responders’ expectation to be operating the system

while wearing personal protective equipment such as gloves, helmet, eye protection, ear protection, etc. The 

operator should be able to maintain acceptable usability (discussed in greater detail in the Test Methods:

Human-System Interaction section of this report) of the system while wearing the stated level of personal 

protective equipment

Test Method: SEE ACCEPTABLE USABILTY TEST

Number: 30 *

Type: HUMAN-SYSTEM INTERACTION

Sub-Type: DISPLAY

Requirement: DASHBOARD

Metric: YES/NO ; EFFECTIVENESS (PERCENT) 

Description: This requirement captures the responders’ expectation to monitor general system

health and status (e.g. orientation, communication strength, power level, etc.). They identified two types of 

information: (A) Display of organic information: 1) system health status, i.e. power, motors, sensors, 

comms, etc.; 2) robot pose, i.e. absolute (x,y,z) or relative location from a start point; 3) constraints 

imposed by environment, i.e. inhibitors, manipulator problems, occluded or blocked sensors; (B) display of

20 
Preliminary Report 

external information: 1) Hazmat; 2) Temperature; 3 ) Other payload sensors. In addition to determining if 

the information is present, it is advisable to perform a series of empirical tests to determine if the 

operator(s) can accurately interpret the displayed information. 

Test Method: SEE DASHBOARD CHECKLIST; ACCEPTABLE USABILITY TEST 

Number: 34 *

Type: LOGISTICS

Sub-Type: CACHE PACKAGING

Requirement: WEIGHT

Metric: KILOGRAMS PER CONTAINER 

Description: This requirement captures the responders’ expectation to move and store all 

equipment using existing methods and tools. 

Test Method: TBD 

Number: 35 *

Type: LOGISTICS

Sub-Type: N/A

Requirement: MEAN TIME BEFORE FAILURE (MTBF)

Metric: OPERATING HOURS 

Description: This requirement captures the responders’ expectation to use all equipment for 

the entire duration of a deployment (10 days maximum). Failure means major repairs of integrated 

components that need to be addressed by the manufacturer or other technical expert. 

Test Method: TBD 

Number: 36 *

Type: LOGISTICS

Sub-Type: CACHE PACKAGING

Requirement: SETUP TIME

Metric: MINUTES 

Description: This requirement captures the responders’ expectation to move, unpack, and 

assemble all equipment to a ready state using existing methods and tools. The setup time is from on-site 

delivery to operation. 

Test Method: TBD 

Number: 38 *

Type: LOGISTICS

Sub-Type: CACHE PACKAGING

Requirement: VOLUME PER CONTAINER

Metric: SCALE 1-5 

1 = Pelican 1650 box

3 = Hardigg box checkable on commercial aircraft 

5 = Ropack model 4048, 4039 with drop door

Description: This requirement captures the responders’ expectation to move and store all 

equipment using existing methods and tools.

Test Method: TBD 

Number: 39 *

Type: LOGISTICS

21 
Preliminary Report 

Sub-Type: FIELD MAINTENANCE

Requirement: SPARES AND SUPPLIES

Metric: PERCENT OF ROBOT WEIGHT 

Description: This requirement captures the responders’ expectation to be self-sustaining for 

72 hours without re-supply from outside the base of operations. Field maintenance can be performed at the 

base of operations. 

Test Method: TBD 

Number: 40 *

Type: LOGISTICS

Sub-Type: FIELD MAINTENANCE

Requirement: DURATION

Metric: MINUTES 

Description: This requirement captures the responders’ expectation to minimize the amount 

of time required to perform routine maintenance operations in the field, potentially in-situ on a rubble pile

or other awkward location. 

Test Method: TBD 

Number: 41 *

Type: LOGISTICS

Sub-Type: FIELD MAINTENANCE

Requirement: TOOLS

Metric: SCALE 1-5 

1 = Requires special tools 

3 = Simple tools (e.g., screw driver) 

5 = No tools required

Description: This requirement captures the responders’ expectation to minimize the need for 

specialized tools to perform field maintenance at the base of operations. 

Test Method: TBD 

Number: 42 *

Type: LOGISTICS

Sub-Type: FIELD MAINTENANCE

Requirement: INTERVALS

Metric: SCALE 1-5 

1 = 12 hours 

3 = 24 hours 

4 = 72 hours 

5 = 10 days

Description: This requirement captures the responders’ expectation to minimize the mean

time between required field maintenance performed at the base of operations. 

Test Method: TBD 

Number: 56 *

Type: OPERATING ENVIRONMENT

Sub-Type: N/A

Requirement: WATER

22 
Preliminary Report 

Metric: SCALE 1-4 

1 = Not water resistant 

2 = Wash down 

3 = Submersible 

4 = Water resistant to 12 meters

Description: This requirement captures the responders’ expectation for the system to maintain

operations in wet environments. 

Test Method: TBD 

Number: 67 *

Type: POWER

Sub-Type: N/A

Requirement: WORKING TIME

Metric: SCALE 1-5 

1 = 1 hour

3 = 4 hours 

5 = 12 hours 

Description: This requirement captures the responders’ expectation to maintain operations

beyond basic mobility requirements within a given terrain type (see mobility requirements within terrain

types). The system must have sufficient power to operate for the specified number of hours, assuming one

power charge for one out and back mission. 

Test Method: TBD 

Number: 68 *

Type: POWER

Sub-Type: N/A

Requirement: SUSTAINMENT

Metric: SCALE 1-5 

1 = 12 hours 

3 = 24 hours 

4 = 72 hours 

5 = 10 days 

Description: This requirement captures the responders’ expectation to maintain operations in 

the field before re-supply of power is needed. The system must have sufficient power to operate for the 

specified number of hours/days before needing re-supply from the base of operations. 

Test Method: TBD 

Number: 69 *

Type: POWER

Sub-Type: N/A

Requirement: RUNTIME INDICATOR

Metric: YES/NO 

Description: This requirement captures the responders’ expectation to manage power 

resources to effectively plan mission durations, points of no return, and other important power 

considerations. The operator display must inform the operator of the remaining power level as a percentage

of total runtime. 

Test Method: TBD 

Number: 96

23 
Preliminary Report 

Type: SENSING

Sub-Type: REAL-TIME COLOR VIDEO 

Requirement: SYSTEM ACUITY - NEAR

Metric: MILLIMETERS 

Description: This requirement captures the responders’ expectation to use video for key tasks 

such as maneuvering (hence the real-time emphasis), object identification (hence the color emphasis), and 

detailed inspection (hence the emphasis on short-range system acuity). The responders noted the need to

consider the entire system, including possible communications signal degradation and display quality, when

testing this capability. They also noted that this requirement is closely tied to the need for adjustable 

illumination to avoid washing out the image of close objects. The responders made no distinction

regarding tethered or wireless implementations to address this requirement. 

Test Method: SEE REAL-TIME VISION SYSTEM ACUITY TEST 

Number: 99 *

Type: SENSING

Sub-Type: REAL-TIME COLOR VIDEO

Requirement: SYSTEM ACUITY - FAR

Metric: METERS 

Description: This requirement captures the responders’ expectation to use video for key tasks 

such as maneuvering (hence the real-time emphasis), object identification (hence the color emphasis), and 

path planning (hence the emphasis on long-range system acuity). The responders noted the need to

consider the entire system, including possible communications signal degradation and display quality, when

testing this capability. They also noted that the limiting case for long-range system acuity is probably 

assessment of structural integrity of buildings. This requires identifying and measuring cracks in walls, 

inspecting the tops/bottoms of load bearing columns, and generally assessing the squareness of walls, 

ceilings, and floors. The responders made no distinction regarding tethered or wireless implementations to

address this requirement. 

Test Method: SEE REAL-TIME VISION SYSTEM ACUITY TEST 

Number: 101

Type: SENSING

Sub-Type: REAL-TIME COLOR VIDEO

Requirement: FIELD OF VIEW

Metric: DEGREES 

Description: This requirement captures the responders’ expectation to use real-time video for 

a variety of tasks. The responders noted that this requirement is closely tied to requirements addressing

independent pan/tilt capabilities. 

Test Method: SEE REAL-TIME VISION SYSTEM ACUITY TEST 

24 
Preliminary Report 

Chapter 4 

TEST METHODS

The principal output of this program will be standard tests methods and metrics for the various performance 

requirements and characteristics defined by the responders. Test methods that are accepted by all interested 

parties: end users (responders), manufacturers, developers, and standards organizations will ensure that 

there are reproducible, meaningful evaluations of how to measure the performance and characteristics of 

robots. The iterative review process of the requirements, metrics, and testing methods is designed to

produce measurements of capabilities that are pre-requisites to fieldable robots. The test methods should be

objective, clearly defined, and reproducible by any developer to support tangible goals for system

capabilities. This set of rigorous test methods will enable robot and component developers to exercise their 

systems in their own locations in order to attain the required performance. The standard tests will be hosted

by certified sites, each hosting a particular set of tests to avoid issues regarding correlation of tests 

conducted at parallel sites. 

A test method will be developed for each of the performance requirements listed in Chapter 3. The test

methods will be designed by NIST, in consultation with responders, developers, and technical experts. In 

this section, we provide some details on possible performance tests. The first example can be designed and 

executed so as to evaluate multiple performance requirements simultaneously. The sections that follow 

provide more details on the Human-System Interaction aspects, which form a large percentage of the Wave

1 requirements. 

EXAMPLE TEST METHOD: REAL-TIME VISION SYSTEM ACUITY 

This example test method (Figure 8) and associated results reporting sheet (Figure 9) show one way to test

the performance of the robot’s vision system. The test could address requirements listed in Table 6 from

the 1st and 2nd Tier. The test outlined is a timed test to read the eye-charts T1, T2 then T3 in sequence from

a variety of distances and robot orientations to measure the operator’s ability to remotely direct and redirect perception. Charts T1 and T2 in the far field represent the top and bottom of a load bearing column, 

for example, identified by structural engineers as of particular interest in the far field (note: structural 

engineers will likely provide the stressing cases for visual acuity requirements). The test includes data 

captures from a variety of distances from the far field charts to determine the system’s maximum acuity; 

several robot orientations to differentiate articulated pan/tilt systems from fixed cameras; and far to near 

focus changes that also require variable illumination when tested in the dark. The test would also be

conducted using both wired and wireless communication modes (radio noise can devastate image 

resolution). The goal of this test method is to isolate easy to measure metrics: time to perform all three 

readings and average acuity across a variety of relevant situations. This allows direct comparison of

performance capabilities without necessarily stating what level of performance is acceptable for a given 

implementation, user, or role. 

Table 6: Requirements Addressed by Example Test Method 

3. Chassis Illumination Adjustable 

6. Communications Range: Beyond Line of Sight 

7. Communications Security

8. Communications Range: Line of Sight 

96. Sensing Real-Time Video Real time remote video system (near) 

99. Sensing Real-Time Video Real time remote video system (far) 

101. Sensing Real-Time Video Field of View 

25 
Preliminary Report 

Figure 8: Set Up for Test 

Figure 9: Test Results Report Sheet 

26 
Preliminary Report 

TEST METHODS FOR HUMAN-SYSTEMS INTERACTION 

REQUIREMENTS

For the first wave of requirements there are basically two types of human-systems interaction requirements: 

those that must be empirically validated in user testing, and those that can be verified using a simple

checklist. In addition, several of the human-system interaction requirements can be considered as 

conditions that must be included in the empirical tests. Table 7 below lists the candidate requirements for 

wave 1 and specifies the type of evaluation for each. A more complete discussion of each follows. 

Table 7: Human-System Interaction Requirements Evaluation Types 

Human- Systems 

Interaction Requirement 

Type of evaluation Comment 

11. Initial training Check list 

User testing

Evaluation Condition

We can check that initial training is 

provided but the adequacy of training 

should be established empirically. 

Acceptable usability should be initially 

evaluated after operators have been

given the specified amount of training. 

12. Proficiency education Check list 

User testing

Evaluation Condition

Proficiency education can also be

checked for existence but the 

effectiveness should also be evaluated. 

Periodically, operators should be given 

additional training and should then be

retested to ascertain if they achieve 

acceptable usability with the robot. 

13. Operator ratio User testing The acceptable usability evaluations 

should be conducted initially with the 

specified number of operators. The 

specified number of operators/robot 

should be a design criterion for 

developers 

14. Acceptable usability User testing Operators of the correct demographics 

who have had the required amount of

training will be given a set of tasks to

perform with the robot. The efficiency, 

effectiveness, and user satisfaction of 

each task will be assessed. 

30. Dashboard Check list 

User testing

The information requirements specified

can be checked for presence in the UI. 

However, the presentation of those 

elements will influence the acceptable 

usability performance. Therefore it is 

recommended that empirical evaluations 

be performed to test the accuracy of 

interpretations by operator(s). 

27 
Preliminary Report 

EXAMPLE TEST METHOD: ACCEPTABLE USABILITY

Acceptable Usability evaluations can be used to test all five human-system interaction requirements for 

Wave 1. Acceptable usability evaluations will use the Common Industry Reporting Format (CIF), ANSI 

NCITS 354-2001 standard. The CIF can be written as a requirement and each vendor can use the CIF to

document the acceptable usability evaluations that have been done. 

The CIF specifies the number of users, the demographics of the users (which will include the amount of 

training the users have been given), the tasks that have been tested, and the various contexts that have been 

used for evaluation. The results of the evaluation are summarized as: 

• Effectiveness (the number of tasks each user was able to perform without help) 

• Efficiency (the time for the user to perform tasks) 

• User satisfaction (users’ ratings according to a standardized satisfaction questionnaire) 

Specifications for acceptable usability evaluation for DHS US&R would include the following contexts: 

Users: while the overall number of subjects should be significant (8 or greater), the evaluation should be

conducted using the specified ratio of operators to robots. If the ratio desired is 1 operator for 1 robot, then 

all tasks should be tested using only 1 operator. If the ratio desired is 2 operators for 1 robot, then 8 pairs 

of operators should be used in the evaluation. 

Initial Training: In addition, the operators should be initially given the specified amount of training. 

Additional demographics will be supplied as the requirements for these are elicited. 

Proficiency Education: Operators should also be given the desired annual training and then tested to ensure

that they can perform the specified tasks with the prescribed acceptable usability measures. 

Context: Lighting and protective clothing become contexts in which the various tasks should be tested. 

For each task defined, the tests should be performed in the three lighting conditions: no light; direct light

without glare; and direct glare on interface. All operators should wear the specified protective clothing

(none, minimum, or full protective gear) during tests. 

Tasks: TBD. The specific tasks for the various scenarios and the types of robots used will need to be

defined by the responders and developers. 

Metrics: TBD. The CIF specifies effectiveness, efficiency, and user satisfaction. We suggest that for the 

robot tasks, effectiveness measures be redefined as consisting of several components: accuracy, collisions 

with avoidable obstacles, and collisions with unavoidable obstacles. The weights of these different

components will vary depending on the primitive task. For example, the task of navigating the robot to a

certain point in a subsurface void, the accuracy would be determined by how close to the desired location 

the operator was able to navigate the robot. The number of collisions with objects will be recorded, as will 

the number of times the robot becomes incapacitated. If the task involves navigation between uncollapsed

buildings, the number of collisions may become less important. However, if the task involves navigation 

within a collapsed building, the collisions could become extremely important. Efficiency, or time to

complete the task, is of interest in both cases. However, it is important for us to know whether the time for

the task was because the robot was stuck on obstacles while navigating or whether the operator was 

navigating extremely slowly due to limited remote situational awareness. 

In addition, collecting the operator’s perceived workload using the NASA Task Load Index (TLX) for each

task tested is very important [7]. In operational scenarios, the operators will be required to perform other 

ongoing tasks, such as communicating with various specialists on the team, and as the operating conditions 

will be extremely stressful, it is important the human-robot interaction not produce an excessive workload. 

28 
Preliminary Report 

While much refinement is needed specify tasks and measures, the following is an example of our approach: 

1. Navigating to a specific point or location in all terrains 

a. Workload (NASA TLX)

b. Time

c. Number of Collisions 

d. Number of times got stuck 

e. Success – how close to the point of location 

2. Reporting locations

a. Workload (NASA TLX)

b. Accuracy 

3. Tracking coverage 

a. Workload (NASA TLX)

b. Accuracy 

4. Operating sensors (cameras, hazmat, etc.) 

a. Workload (NASA TLX)

b. Time

c. Effectiveness 

5. Recognizing robot health (dashboard) 

a. Workload (NASA TLX)

b. Time

c. Accuracy 

EXAMPLE TEST METHOD: CHECKLISTS 

Some responder requirements will be easier to measure than others. The responders defined several 

requirements with “yes/no” metrics based on expectations of inclusion within the overall system (i.e. #03 

Chassis : Illumination : Adjustable). They also defined metrics based on conformity to specific operational

requirements (i.e. #38 Logistics : Cache Packaging : Volume per Container), which are tied to numeric 

scales with model numbers of shipping containers, for example. Both of these types of requirements can be 

verified with a simple checklist. The responders also defined slightly more complicated checklist metrics 

for requirements such as #29 Human-System Interaction : Display : Dashboard as part of the operator 

control unit, although this requirement did not rise to the top level of consensus requirements targeted for 

Wave 1. For this type of requirement, a checklist can still be used to determine if the required information

is present in the operator control unit. For example, this checklist will include items such as: 

1. System health status: power remaining, motors, sensors, communications, etc. 

2. Robot pose: absolute measures or relative measures from the starting point 

3. Display of external information: temperature, hazmat information, other payload sensors 

Final checklists of this sort will be compiled based on more detailed discussions of the specific 

requirements. Meanwhile, several acceptable usability tasks will also be defined to determine if the 

presentation of this information is easily accessible by the operator (s). 

29 
Preliminary Report 

Chapter 5 

NEXT STEPS

DEVELOPMENT AND STANDARDIZATION OF TEST METHODS

The proposed Wave 1 requirements will be further detailed after receiving input at the initial public forum

(held May 13th, 2005 at NIST). In fiscal year 2005, either a single standards development organization 

(SDO) or a joint SDO team will be identified to host the US&R robot performance standards. The Wave 1 

requirements will have corresponding testing methods developed in the coming year. The human-system

interaction requirements team will conduct regional workshops with technical search specialists who have 

been designated as likely candidates for operating the robots. These workshops will be used to develop the 

primitive tasks to be used in the acceptable usability test method. The remainder of the requirements will 

have accompanying test methods by the end of the program. 

The set of requirements will also be examined to determine if other requirements for performance and

human-system interaction have been covered (Drury et al [5], and The Center for Robot Assisted Rescue 

[6]). Any additional guidelines will be considered for inclusion in the next wave. In addition, as 

responders consider the possible concepts of operations that will be used with robot assisted search and 

rescue, additional human-system interaction requirements may emerge. 

As indicated in the timeline diagram (Figure 2), this program will take an iterative development approach to 

ensure that the performance requirements are appropriate and that the vendor and technology communities 

are able to interact with the end users on a frequent basis. These events will also present opportunities to

dry-run testing protocols to an audience of responders and technologists. Comments from these 

communities can help refine and strengthen the tests. The events will also serve to provide feedback on a 

frequent basis to the technology developers, who will be able to see how their systems perform against the 

emerging performance standards. Events similar in flavor have been held by other organizations, such as

the National Aeronautics and Space Administration’s Disaster Assistance and Rescue Team (NASA 

DART) and the Center for Robot-Assisted Search and Rescue. For instance, in May 2004, NASA DART 

organized a “Technologist meets Responders” workshop at their Collapsed Structure Rescue Training 

Facility. At this workshop, responders had the opportunity to exercise various new technologies relevant to

search and rescue, including robots. In the evaluations by responders, robotic devices were considered at

best a 3 (out of 10) in overall utility during emergency response, except in certain specialized cases, 

however the potential utility was considered to be “very high” (probably a 10). However, they stated that 

much work is needed, particularly in the areas of mobility (traversing difficult terrain), maintaining

communications and power links, and improving the usability of human interfaces [16]. 

The first of these events under this standardization program is being planned for August 2005, possibly in

conjunction with a FEMA Task Force Leader’s meeting. Candidate test methods for a subset of the Wave 1 

requirements will be demonstrated and evaluated. Vendors and technologists are encouraged to bring their 

robots or components to demonstrate and to run through the prototype tests. In February 2006, a workshop

will be held in conjunction with the American Nuclear Society International Joint Topical Meeting: Sharing

Solutions for Emergencies and Hazardous Environments 

(http://www.2006sharingsolutions.com/workshopD.shtml). This workshop will provide opportunities to

share progress in the standard test methods development process and exchange ideas amongst the 

stakeholder communities. In August 2006, a joint Performance Metrics for Intelligent Systems and IEEE 

Safety, Security, and Rescue Robotics conference will be held at NIST. This will be another opportunity 

30 
Preliminary Report 

for evaluation of test methods and robots by vendors, technologists, responders, and standards committee 

members.

The somewhat informal tests that will occur on a regular basis in the early part of the program will be

expanded into technology readiness level evaluation exercises. As the technologies comprising the US&R 

robotic systems evolve, it will be possible to conduct more rigorous tests under realistic scenario-driven 

exercises involving responders. These tests will expose any gaps in the existing performance requirements 

and testing protocols and help refine existing requirements and tests prior to submitting them to the 

standards process. 

Technology Readiness Levels (TRLs) are a systematic metric and associated measurement system that 

supports both the assessment of the maturity of a particular technology and the consistent comparison of 

maturity between different types of technology. First developed by NASA [3], this 9-level scale defines 

broad categories of deployment readiness of technologies, components, subsystems, or systems. The

Department of Defense has been using TRL terminology and methodology for various programs. Their

version of the scale is shown in Table 8. DHS will work with NIST to devise TRL assessment exercises for 

US&R robots in order to measure the maturity of component technologies (such as particular sensors) as 

well as overall robotic systems. TRL assessment exercises will provide essential evaluations of

performance for US&R robots, providing statistically significant performance data for developmental and

fielded systems. NIST is at the forefront of TRL evaluation of robotic systems, having designed and 

administered TRL exercises for the Army Research Laboratory to evaluate the maturity of the autonomous

navigation system for the Demo III eXperimental Unmanned Vehicle (XUV), an unmanned scout

vehicle[4]. For this assessment, NIST conducted 650 discrete missions, covering over 500 km of

autonomous driving in arid, vegetated, and urban terrains. NIST plans to leverage this experience and

apply relevant techniques and methods to US&R robot evaluations. 

In the coming years, one or more testing and evaluation sites will be selected and certified by NIST as 

being able to carry out the test methods developed within this program. The test site(s) will conduct any 

official testing and evaluation of robots for urban search and rescue. 

Additional efforts will support and complement development of standard test methods for robots. These 

efforts involve classification of the robot capabilities, along with classification of buildings, collapses, and

disaster types. Since robotics itself is a multidisciplinary and evolving field, classifications serve to

organize the knowledge about the technologies involved. A classification approach to the types of 

buildings and collapses may help develop guidelines for the application of robotic technologies to particular 

situations. More information on the robot and building/collapse classifications can be found in Chapters 6

and 7. A compendium of robot capabilities is also being developed by a third party. The compendium will 

list vendor-provided specifications in addition to the certified performance results captured using the 

standard test methods developed under this program.

Table 8 - Technology Readiness Level Descriptions 

1. Basic principles observed and reported Lowest level of technology readiness. Scientific 

research begins with to be translated into applied

research and development. Example might include 

paper studies of a technology's basic properties. 

2. Technology concept and/or application 

formulated 

Invention begins. Once basic principles are 

observed, practical applications can be invented. 

The application is speculative and there is no proof 

or detailed analysis to support the assumption.

Examples are still limited to paper studies. 

3. Analytical and experimental critical function 

and/or characteristic 

Active research and development is initiated. This 

includes analytical studies and laboratory studies to

31 
Preliminary Report 

physically validate analytical predictions of separate 

elements of the technology. Examples include 

components not yet integrated or representative. 

4. Component and/or breadboard validation in

laboratory environment 

Basic technological components are integrated to 

establish that the pieces will work together. This is 

relatively "low fidelity" compared to the eventual 

system. Examples include integration of 'ad hoc'

hardware in a laboratory. 

5. Component and/or breadboard validation in

relevant environment

Fidelity of breadboard technology increases 

significantly. The basic technological components 

are integrated with reasonably realistic supporting

elements so that the technology can be tested in a 

simulated environment. Examples include 'high 

fidelity' laboratory integration of components. 

6. System/subsystem model or prototype 

demonstration in a relevant environment

Representative model or prototype system, which is

well beyond the breadboard tested for TRL 5, is 

tested in a relevant environment. Represents a major 

step up in a technology's demonstrated readiness. 

Examples include testing a prototype in a high 

fidelity laboratory environment or in simulated

operational environment.

7. System prototype demonstration in a operational

environment

Prototype near or at planned operational system. 

Represents a major step up from TRL 6, requiring

the demonstration of an actual system prototype in

an operational environment, such as in an aircraft, 

vehicle or space. Examples include testing the 

prototype in a test bed aircraft. 

8. Actual system completed and 'flight qualified' 

through test and demonstration

Technology has been proven to work in its final

form and under expected conditions. In almost all

cases, this TRL represents the end of true system

development. Examples include developmental test

and evaluation of the system in its intended weapon

system to determine if it meets design specs. 

9. Actual system 'flight proven' through successful

mission operations 

Actual application of the technology in its final 

form and under mission conditions, such as those

encountered in operational test and evaluation. In

almost all cases, this is the end of the last "bug

fixing" aspects of true system development.

Examples include using the system under 

operational mission conditions. 

32 
Preliminary Report 

Chapter 6 

ROBOT AND CAPABILITIES CLASSIFICATION

Given the new and evolving nature of robotics applied to challenging environments such as collapsed

buildings, a means of organizing knowledge about the diverse population of robots and their components

and capabilities may help users and developers better understand what is available and where there are 

gaps. To this end, this program encompasses efforts that will create classification structures (taxonomies) 

for robots and their capabilities, as well as for buildings and collapse or disaster types. The building

classification work is described in Chapter 7. The robot capabilities classification is being addressed 

through the use of ontologies. Whereas the robot and capabilities classification effort will be defining the 

data structures to capture the pertinent characteristics of robots, a complementary effort described in

Chapter 8, will populate these structures with data about robots which are currently available. This data will 

not only include the physical characteristics of the robots, but will also include the results of standard 

performance test. This "compendium" will be available in database format.

The goal of this Robot Ontology effort is to develop, and begin to populate, a neutral knowledge

representation (the data structures) capturing relevant information about robots and their capabilities to

assist in the development, testing, and certification of effective technologies for sensing, mobility, 

navigation, planning, integration and operator interaction within search and rescue robot systems. This

knowledge representation must be flexible enough to adapt as the robot requirements evolve. As such, we 

have chosen to use an ontological approach to representing these requirements. 

In this context, an ontology can be thought of as a knowledge representation approach that represents key 

concepts, their properties, their relationships, and their rules and constraints. Whereas taxonomies usually 

provide only a set of vocabulary and a single type of relationship between terms (usually a parent/child type

of relationship), an ontology provides a much richer set of relationship and allows for constraints and rules 

to govern those relationships. In general, ontologies make all pertinent knowledge about a domain explicit 

and are represented in a computer-interpretable fashion that allows software to reason over that knowledge

to infer addition information.

By taking an ontological approach, we provide for: 

• Less ambiguity in term usage and understanding 

• Explicit representation of all knowledge, without hidden assumptions

• Conformance to commonly-used standards 

• Availability of the knowledge source to other arenas outside of urban search and rescue

• Availability of a wide variety of tools (reasoning engines, consistency checkers, etc.) 

The benefits of having a robot ontology are numerous. In addition to providing the data structures to

represent the robot requirements, the robot ontology can allow for:

• The selection of equipment and agents for rescue operations

• Assistance in the exchange of information across US&R teams 

• The ability to find the available resources that address a need

• The identification of gaps in functionality that can drive research efforts

The Robot Ontology is based on a number of existing technologies. They are: 

• OWL (Web Ontology Language) – OWL is a World Wide Web Consortium (W3C) recommendation 

(as of February 10, 2004). It defines terms commonly used in creating a model of an object or process, 

including classes/subclasses, properties/subproperties, property restrictions, and instances. [11]

33 
Preliminary Report 

• OWL-S (Web Ontology Language – Services) – OWL-S is an OWL-based web service ontology, 

which describes the properties and capabilities of services in an unambiguous, computer-interpretable 

form. It was developed by the DARPA Agent Markup Language (DAML) Program. OWL-S is an

upper ontology intended to be extended to meet specific applications. [14]

• Protégé – Protégé is an open source ontology editor developed at Stanford University. It supports class 

and property definitions and relationships, property restrictions, instance generation, and queries. 

Protégé accommodates plug-ins, which are actively being developed for areas such as visualization and 

reasoning. [13]

In addition, a number of existing knowledge representations have been found through a literature survey 

that will be / have been leveraged in the development of the Robot Ontology. These include: 

• Efforts to determine the information requirements for a US&R ontology performed at the University 

of Electro-Communications in Tokyo, Japan [10]

• Efforts to develop a Mobile Robot Knowledge Base at SPAWAR [12]

• Efforts at the Center for Robot Assisted Search and Rescue (CRASAR) in the development of

taxonomies for robot failures [9] and issues pertaining to social interactions between robots and 

humans [8] 

An initial structure for the Robot Ontology has been developed. This initial structure can be broken down

into the follow primary categories of knowledge: 

• Structural Characteristics – describes the physical and structural aspects of a robot 

• Functional Capabilities – describes the behavioral features of the robot 

• Operational Considerations – describes the interactions of the robot with the human and the 

interoperability with other robots 

Examples of knowledge captured in the structural characteristics category include (but are not limited to): 

• Size 

• Weight 

• Tethering 

• Power Source 

• Locomotion Mechanism (wheeled, walking, crawling, jumping, flying, etc.)

• Sensors (e.g., camera, FLIR, LADAR, SONAR, GPS, Audio, Temperature Sensor) 

• Processors 

Examples of knowledge captured in the functional capabilities category include (but are not limited to): 

• Locomotion Capabilities (e.g., max. speed, max. step climbing, max. slope climbing, etc.) 

• Sensory Capabilities (e.g., min. visibility level, map building capability, self-localization, system

health, etc.) 

• Operational Capabilities (e.g., working time, setup time, max. force available to push, MTBF, MTBM, 

required tools for maintenance, run time indicator, sustainment (spares and supplies), etc.) 

• Weather Resistance (e.g., max. operating temp, max. submergability level, etc.) 

• Degree of Autonomy (e.g., joint level dependency, drive level dependency, navigation level

dependency, etc.) 

• Rubble Compatibility (e.g., ability to historically operate well in certain terrains) 

• Communications (e.g., communication media, communication channel frequency, content standards, 

information content, communication locking, communication encryption)

34 
Preliminary Report 

Figure 10: The Robot Ontology

Examples of knowledge captured in the operational considerations category include (but are not limited to): 

• Human-System Interaction (operator ratio, initial training, proficiency education, acceptable usability, 

auto-notification, display type, packaging size) 

• Intra-Group Interaction (i.e., interaction with other similar robots) 

• Inter-Group Interaction (i.e., interaction with other 3rd party robots or computers) 

Based on the technologies described earlier and based on the categories and requirements discussed above, 

we have developed an initial version of a Robot Ontology. Figure 10 shows a screenshots of the ontology

(represented in Protégé) with associated explanation. 

The column on the left shows the classes that are represented in the ontology. The box on the right (with the 

blue boxes on left) shows the attributes that are associated with the highlighted class (Robot). In the 

ontology, the robot is the highest-level concept. A mobile robot is defined as a mechanism with locomotion

and sensing capability which a human user may interact with from a remote location. These robots have

attributes such as hasCommunication Capability, hasHumanFactorsCapabilities, 

hasLocomotionCapabilities, etc. Each one of these attributes point to classes with more specific 

information. As an example, Figure 11 shows a screenshot of the attributes associated with 

hasOperationalCapabilities. 

 

35 
Preliminary Report 

Figure 11: Operational Capability Attributes 

To date, the Robot Ontology contains 230 classes, 245 attributes (properties), and 180 instances. As the

project progresses, it is expected that the ontology will grow considerably. 

Future work will focus on: 

• Continue to specialize the robot ontology structure to provide greater level of detail 

• Explore other standards efforts and existing ontologies that can be leveraged 

o Sensors 

o Power Source 

o Materials 

o Environment

• Continue to incorporate the requirements from the requirements workshops into the robot ontology

structure 

• Explore the use of reasoning engines to suggest robots for different situations

• As requirements for the building and collapse types become available, start building a building and

collapse type ontology. 

36 
Preliminary Report 

Chapter 7 

BUILDING AND COLLAPSE TYPES

As an integral effort to define test methods for urban search and rescue robotics, a description and 

classification of potential operating environments is required. To that end, the Building and Fire Research

Laboratory (BFRL) at NIST will be developing a structural collapse taxonomy (an orderly classification). 

The 2005 calendar year effort will focus on developing a framework for integrating building classification,

disaster type, and collapse type to provide general descriptions of probable operating environments. 

Existing sources of building classifications and how they relate to collapse, such as the ASCE/FEMA 310 –

Handbook for the Seismic Evaluation of Buildings (Pre-standard) are being studied [15]. The publication 

defines 15 base model building types with subcategories resulting in 23 separate building descriptions, 

which could serve as a baseline for the collapse/disaster type taxonomy. Discussions are being held with

participants from the National Construction Safety Team (NCST) to discuss building classifications and

collapse categories. Information reviewed during assessments of building collapses by NCST includes

Type of Construction (e.g., wood, masonry, steel, concrete), Type of Structure (e.g., moment frame), 

Height, and Type of Collapse (e.g., partial, total, progressive). 

Initial discussions with responders regarding collapse categories yielded additional information. For their 

purposes (victim identification and recovery) the use of the structure and time of day (i.e. school / night)

were more important data than specific construction types. 

Experiments using laser scanning and range image analysis will also be performed to characterize rubble 

type. The first site to be analyzed will be the rubble pile at the Montgomery County MD Fire Rescue

Training Academy. Figures 12, 13, and 14 show images of the rubble at the site, as well as preliminary 

data collection using a high-resolution, three-dimensional scanner. This work is initially being done on the 

exterior of rubble piles, but will be extended to interior void characterization where possible. 

Figure 12: Montgomery County Fire Rescue Training Facility Rubble Pile 

37 
Preliminary Report 

Point Cloud Detail (False 

color – Range) 

LADAR Scan with Point Cloud 

photo overlay

Digital 

Figure 13: Data Collection Process. This set of images show the overhead views of the rubble pile, 

the data capture rig, and a resulting point cloud captured by the three-dimensional scanner. 

38 Figure 14: Multiple 3D Scans Registered Together. These two images were produced by registering multiple 

point clouds collected around the rubble pile
Preliminary Report 

39 

Chapter 8 

COMPENDIUM OF ROBOT CAPABILITIES

Perhaps the most compelling advantage to be exploited by the application of mobile robot technologies to 

the US&R response challenge lies in their inherent freedom of design. While the rigors of military combat 

and typical Department of Defense (DoD) operating environments tend to focus requirements and military 

prototype designs into a relatively narrow field of candidates, the wide-ranging nature of DHS 

responsibility dictates otherwise. 

Consider the case of a highly capable reconnaissance robot that loudly announces its location with a 

significant audio/visual or electro-magnetic (EM) signature, and is so light-skinned that a BB gun or .22 

caliber bullet would put it out of action immediately. In spite of its superior mobility, sensing, or 

manipulative potential, it will probably fall far below a tactical military procurement cut line because its 

logistical burden and employment disadvantages far outweigh its operational value as a reconnaissance 

asset. 

Domestic response organizations, however, do not share the military’s need to maintain a stealthy, bulletproof profile. In fact many of them may try to actually advertise their location and attract attention as a 

means promote face-to-face coordination and more effective communication between first responders and 

other emergency support entities. Thus the typically restrictive performance features that are viewed as 

detriments for defense applications may actually be perceived as operational advantages for domestic 

response purposes. 

In considering the utility of mobile robots to support assessment and mitigation activities associated with 

both natural disaster and man made crises, it is clear that a much wider variety of environmental conditions 

and employment roles exists for response robots than for their military cousins. Consequently the set of 

design requirements for response robots will need to be significantly relaxed in value and expanded in type 

if we are to effectively exploit mechanical design freedom and extract maximum potential from this 

exciting technology area. 

As requirements are relaxed, innovation and creative thought can be increased to address the expanded set 

of challenges associated with extreme conditions and adaptive tasks required of response robots operating 

in unstructured and dynamically shifting scenarios. In fact, a plethora of mobile robot prototypes have 

recently emerged from the aftermath of 09/11, presenting a wide range of response to both the government 

and commercial sector outside the DoD. (see Figure 15 ) 
Preliminary Report 

Figure 15: Collage of Potential Response Robot Candidates 

It should be noted that while the focus of this effort remains oriented on the urban environment, this focus 

is not intended to be exclusionary – especially since the role of FEMA’s US&R task force program is 

expected to continue to evolve as they are increasingly called upon to support a broad range of emergent

missions with a more rural flavor as seen during the search for Challenger astronaut remains, the 2004 

hurricane season, etc. 

In recognition of this evolutionary nature, and the corresponding expansion in mobile robot platforms with

response potential, NIST, under funding from the DHS S&T Directorate, has commissioned Blitz Solutions 

Inc. (BSI) to establish a Compendium of Response Robotics (CoRR). This database product will serve as 

an impartial, comprehensive shopping list and reporting mechanism by which both government and

commercial response entities can analyze the return on investment associated with purchasing and/or

leasing robotic platform(s) for application to any particular role or task that they have in mind. 

The first generation of the CoRR will include basic characteristics (dimensions, weight, shape, etc.) and unvalidated performance data (speed, duration, sensor resolution, etc.) claimed by each robot supplier. (See

Figure 16 for an unverified example of what a page from the CoRR might look like. NOTE: THIS DATA 

IS FOR EXAMPLE ONLY! IT DOES NOT REFLECT ACTUAL DATA OR EVALUATION STATUS!

The second generation CoRR will incorporate candidate and eventual standard test results conducted and

validated by certified test sites. The goal is a Consumers’ Report concept of actual performance based on

similar test methods. The third and subsequent generations of the CoRR will implement a number of 

improvement and extensions commensurate with the evolution of the response robotics field. 

40 
Preliminary Report 

Aurora 

Automatika, Inc. 

137 Delta Dr. 

Pittsburgh, PA 15238

412.968.1022 

www.automatika.com

EXAMPLE ONLY! 

THIS DOES NOT REFLECT 

ACTUAL DATA OR EVALUATION 

STATUS!

Model: Aurora Speed: max 1.6 m/sec 

Manufacturer: Automatika Locomotion: Steerable monotread 

Common Name(s): “caterpillar”, 

“worm”

Power: Li-ion rechargeable 

battery pack

Produced: Prototype (2002) Battery Life: 4-8 hrs 

Computing: PC-104, Intel P3

Length 24” Communication: Wireless RS144/enet

Width 6” Cameras: 2 front & 2 rear

Height 4” Sensors: video, audio, pitch, 

roll, heading

Base Weight 20 lbs OCU: Mini console 

Waterproof: Submersible Behaviors: Self-righting

Options: semi-autonomous operation, 2 additional bays and expansion ports, 

top mounted “cargo bed” for marsupial deployment

EXAMPLE ONLY! THIS DOES NOT REFLECT ACTUAL DATA OR EVALUATION STATUS!

NOTES: While currently existing only as a prototype, the Aurora demonstrates confined space climbing ability and a 

sealed enclosure. However, as with many of the platforms in this class, this variant’s inability to carry substantial 

cargo or deploy a manipulator currently limits the Aurora to primarily exploratory and sensor-emplacement roles. 

With wireless control, invertible operations, and extremely compact size, the Aurora is intended for confined space 

exploration and refuge detection but would benefit from the addition of more powerful lights.

Figure 16: Example of Compendium Entry 

41 
Preliminary Report 

42 

REFERENCES

1. Urban Search and Rescue Technology Needs Identification of Needs, DHS/FEMA and National 

Institute of Justice Report, June 2004. 

2. Project Responder: National Technology Plan for Emergency Response to Catastrophic Terrorism, 

National Memorial Institute for the Prevention of Terrorism and the United States Department of 

Homeland Security Report, April 2004. 

3. Mankins, J., “Technology Readiness Levels: A White Paper,” NASA Office of Space Access and 

Technology, April 6, 1995. http://www.hq.nasa.gov/office/codeq/trl/trl.pdf

4. Army Research Laboratory Technology Readiness Levels Testing for Autonomous Mobility Report 

5. Drury, J., Hestand, D., Yanco, H., and Scholtz, J., Design Guidelines for Improved Human-Robot 

Interaction, Proceedings of CHI2004, Poster Presentation, Vienna, April 2004. 

6. Center for Robot Assisted Search and Rescue, http://crasar.csee.usf.edu/rescuerobots/robots.htm, 

accessed May 6, 2005. 

7. NASA Task Load Index (TLX), Human Performance Research Group, NASA Ames Research Center, 

Moffett field, California, v.1.0. 

8. Burke, J., Murphy, R., Rogers, E., Lumelsky, V., and Scholtz, J., "Final Report for the DARPA/NSF 

Interdisciplinary Study on Human-Robot Interaction," IEEE Transactions on Systems, Man, and 

Cybernetics - Part C: Applications and Reviews, Vol. 34, No. 2, 2004. 

9. Carlson, J., Murphy, R., and Nelson, A., "Follow-Up Analysis of Mobile Robot Failures," CRASAR 

Technical Report - TR2004-10, 2004. 

10. Chatterjee, R. and Matsuno, F., "Robot Description Ontology and Disaster Scene Description 

Ontology: Analysis of Necessity and Scope in Rescue Infrastructure Context," To be published in the 

Proceedings of the IEEE Int. Workshop on Safety, Security, and Rescue Robotics, 2005. 

11. Harmelen, F. and McGuiness, D., "OWL Web Ontology Language Overview," W3C web site: 

http://www.w3.org/TR/2004/REC-owl-features-20040210/, 2004. 

12. Joint Robotics Program, "Mobile Robots Knowledge Base," http://robot.spawar.navy.mil, 2005. 

13. Stanford Medical Informatics, "The Protege Homepage," http://protege.stanford.edu/, 2005. 

14. The OWL Services Coalition, "OWL-S 1.0 Release," http://www.daml.org/services/owl-s/1.0/owls.pdf, 2003. 

15. FEMA 310, Handbook for Seismic Evaluation of Buildings—A Prestandard (American Society of 

Civil Engineers, 1998). 

16. http://dart2.arc.nasa.gov/Exercises/TMR2004/technology.html#robotics 
Preliminary Report 

43 

APPENDIX A – REQUIREMENTS DEFINITION WORKSHOP 

PARTICIPANTS

Attended Attended Attended 

Organization Workshop I Workshop II Workshop III 

AZ-TF1 Lloyd Randall Lloyd Randall 

CA-TF1 Tom Haus Tom Haus Tom Haus 

CA-TF2 Rory Rehbeck Rory Rehbeck 

Bill Monahan Bill Monahan Bill Monahan 

Harold 

Schapelhouman 

Harold 

Schapelhouman 

CA-TF3 

Roger Miller Roger Miller Roger Miller 

CA-TF6 David Lesh David Lesh 

CA-TF7 Ford Davies 

CA-TF8 Richard Leap Richard Leap Richard Leap 

IN-TF1 Sam Stover Sam Stover 

Bradford Stocks 

Bruce Naslund Bruce Naslund Bruce Naslund 

MA-TF1 

Alan Fisher* 

MD-TF1 Michael Steed Michael Steed Michael Steed 

MO-TF1 Lee Turner 

NE-TF1 Michael Conditt Michael Conditt Michael Conditt 

 Vance Behrens 

NY-TF1 George Hough George Hough George Hough 

Randy Miller Randy Miller 

OH-TF1 Kevin Clemens Kevin Clemens Kevin Clemens 

PA-TF1 Martyn Nevil Martyn Nevil 

TN-TF1 Anthony Fisher Anthony Fisher 

TX-TF1 Robert McKee Billy Parker Billy Parker 

UT-TF1 Trevor Tallon 

Jens Lund 

VA-TF1 Tom Griffin Mark Lucas 

VA-TF2 Mark Hundley Mark Hundley Mark Hundley 

Jim Ingledue Jim Ingledue 

FEMA US&R 

Technical Working 

Group 

Dave Hammond*

National Guard Michael Benzick Michael Benzick 

* participated via teleconference
Preliminary Report 

APPENDIX B – COMPLETE INITIAL REQUIREMENTS LIST

The following table lists all of the requirements captured during the course of three workshops held with FEMA Task Force members. 

standardization are starred. Red font for a requirement number indicates the Tier 1 list, which met the criteria described in Chapter 2. 

number indicates the Tier 2, which were elevated to Wave 1 based on other rationales. 

Requirement 

Number 

(starred 

ones are 

Wave 1 

candidates) 

Type Sub_Type Requirement How Measured D

1 Chassis Tether point 1=Yes, 0=No Hard point 2 Chassis System Component Interoperability 1=Yes, 0=No

Interope

requirem

Capabilitie

payload, 

* 3 Chassis Illumination Adjustable 1=Yes, 0=No

4 Chassis Structural Shoring 1=Yes, 0=No Typically p5 Communications Expandable Bandwidth # Additional data streams 

Will suppo

compone

transmission 

componen

44 
Preliminary Report 

Requirement 

Number 

(starred 

ones are 

Wave 1 

candidates) 

Type Sub_Type Requirement How Measured D

* 6 Communications Range Beyond Line Of Sight Meters 

Must be a

number o

collapse. W

s

* 7 Communications Security Scale 1 - 5 

System must 

interferenc

defined: 1=N

dat

* 8 Communications Range Line of Sight Meters 

9 Communications Data Logging Status and Notes 1=Yes, 0=No Ability to p

10 Human-System Interaction Portability kg Assu

* 11 Human-System Interaction Initial Training Hours Leads to 

supporting m

within 

* 12 Human-System Interaction Proficiency education Hours annually Structured 

45 
Preliminary Report 

Requirement 

Number 

(starred 

ones are 

Wave 1 

candidates) 

Type Sub_Type Requirement How Measured D

* 13 Human-System Interaction Operator ratio Number of operators * 14 Human-System Interaction Acceptable Usability Effectiveness (percent) Percent o

succ

15 Human-System Interaction Assistive Unattended sampling 1=Yes, 0=No Ability to 

sampli

16 Human-System Interaction Assistive Auto Notification 1=Yes, 0=No System 

conditions 

17 Human-System Interaction Assistive Path Tracing 1=Yes, 0=No

Repetitive 

defined path 

operator def

the op

18 Human-System Interaction Assistive Auto Station Keeping # of Axis Maintain

orientation

d

19 Human-System Interaction Assistive Emergency stop 1=Yes, 0=No Imme

commun

20 Human-System Interaction Assistive: Mobility Reacquire communications 1=Yes, 0=No

46 
Preliminary Report 

Requirement 

Number 

(starred 

ones are 

Wave 1 

candidates) 

Type Sub_Type Requirement How Measured D

21 Human-System Interaction Assistive: Mobility Self Extraction 1=Yes, 0=No Extraction m

regain o

22 Human-System Interaction Assistive: Victim Indicators Probability of Detection Percent Must be ab23 Human-System Interaction Context Remote information sharing Meters Real time24 Human-System Interaction Context Operator disengagement 1=Yes, 0=No Ability to 25 Human-System Interaction Context Co-located information sharing 1=Yes, 0=No

* 26 Human-System Interaction Context Lighting Conditions Scale 1 - 5 

Must be able 

different lig

emphasis 

Scale define

3=Daylight w

gla

271 Human-System Interaction Context Mobility Scale 1 -5 Scale; 1=Sy

operation; 

can't be use

1 Note that numbering is discontinuous due to preservation of legacy requirements information 

47 
Preliminary Report 

Requirement 

Number 

(starred 

ones are 

Wave 1 

candidates) 

Type Sub_Type Requirement How Measured D

can be use

* 29 Human-System Interaction Context Protective Clothing Scale 1 - 5 

Scale: 1=N

protection 

protection (O

acc

* 30 Human-System Interaction Display Dashboard 1=Yes, 0=No

General ch

status. (e.g. o

signal streng

o

Organic: 1

sensor. Co

reception. 2

(x,y,z) or 

inhibitors, 

sensin

Externa

31 Human-System Interaction Display Mission data Integration 1=Yes, 0=No Include32 Human-System Interaction Interaction Component controls 1=Yes, 0=No To in33 Human-System Interaction Interaction Adjustable noise filtering 1=Yes, 0=No

48 
Preliminary Report 

Requirement 

Number 

(starred 

ones are 

Wave 1 

candidates) 

Type Sub_Type Requirement How Measured D

* 34 Logistics Cache Packaging Weight kg * 35 Logistics MTBF Hours

Mean Time 

integrated co

requ

* 36 Logistics Cache Packaging Setup Time Minutes Time from on

37 Logistics Shock resistance Pass Drop/Vibration Tests Organic chas

compon

directional 

* 38 Logistics Cache Packaging Volume Scale 1 - 5 

Scale defin

3=Hard

commercial 

4048, 

* 39 Logistics Field Maintenance Spares and Supplies Percent of robot weight Field mainte

Self-sustainin

* 40 Logistics Field Maintenance Duration Minutes

Field mainte

Amount of 

routine main

49 
Preliminary Report 

Requirement 

Number 

(starred 

ones are 

Wave 1 

candidates) 

Type Sub_Type Requirement How Measured D

* 41 Logistics Field Maintenance Tools Scale 1 -5 

Field mainte

Scale Defined

3=Simple to

N

42 Logistics Field Maintenance Intervals Scale 1 - 5 

Mean time b

pe

Scale defined

4=72 

43 Mobility Aerial Area of coverage sq m/hr Reconnais44 Mobility Aerial Station keeping # of Axis 

Maintain

orientation

d

45 Mobility Locomotion Sustained speed-Soft km/hr 46 Mobility Locomotion Sustained speed-Obstacles km/hr 47 Mobility Locomotion Sustained speed-Firm km/hr 

50 
Preliminary Report 

Requirement 

Number 

(starred 

ones are 

Wave 1 

candidates) 

Type Sub_Type Requirement How Measured D

48 Mobility Locomotion Endurance-Firm Hours Enduranc49 Mobility Locomotion Endurance-Soft Hours Enduranc50 Mobility Locomotion Endurance-Obstacles Hours Enduranc51 Mobility Mobility Tumble recovery within Terrain Type Scale 1 - 5 Scale defined

5=Invertibl

52 Mobility Water Bottom crawler 1=Yes, 0=No53 Mobility Water Surface swimmer 1=Yes, 0=No54 Mobility Water Underwater swimmer 1=Yes, 0=No N55 Operating Environment Explosive Environments 1=Yes, 0=No Meet or ex

Gr

51 
Preliminary Report 

Requirement 

Number 

(starred 

ones are 

Wave 1 

candidates) 

Type Sub_Type Requirement How Measured D

56 Operating Environment Max Temperature Degrees C 58 Operating Environment Water Scale 1 - 4 Scale: 1=No

down; 3=

resis

58 Operating Environment Min Temperature Degrees C 59 Payload Manipulation Ability to open doors 1=Yes, 0=No Internal, ext

knob

60 Payload Manipulation Sensor manipulation 1=Yes, 0=No Include61 Payload Manipulation Spray 1=Yes, 0=No Deconta62 Payload Manipulation Max Reach mm 63 Payload Emplacement 1=Yes, 0=No Ve

52 
Preliminary Report 

Requirement 

Number 

(starred 

ones are 

Wave 1 

candidates) 

Type Sub_Type Requirement How Measured D

64 Payload Delivery kg at max reach 65 Payload Retrieval mm Picking up fo

not co

66 Power Dwell Time Scale 1 - 5 Amount of 

acti

* 67 Power Working Time Scale 1 - 5 

System wor

requireme

terrain. Mus

operate for s

Assumes on

an

Scale d

ho

* 68 Power Sustainment Hours

Amount of tim

operate in 

Scale defined

4=72 

* 69 Power Runtime Indicator 1=Yes, 0=No Must be a

remaining 

53 
Preliminary Report 

Requirement 

Number 

(starred 

ones are 

Wave 1 

candidates) 

Type Sub_Type Requirement How Measured D

70 Power Voltage compatibility with cache 1=Yes, 0=No Must be a

sou

71 Sensing Remote temperature 1=Yes, 0=No Ability to che

bef

72 Sensing Audio 2-way Scale 1 - 5 

Scale defined

all the time

5=Dir

73 Sensing Hazmat Hazard Detection Scale 1 - 5 

Scale:1=ph + 

2=+WMD an

and TIC cla

WMD and T

and TIC samp

must mee

documented 

74 Sensing Internal Orientation reporting # of Axes 75 Sensing Location Absolute Scale 1 - 5 

Reporting loc

reference 

1=Topol

3=1+Mappin

plans; 5

54 
Preliminary Report 

Requirement 

Number 

(starred 

ones are 

Wave 1 

candidates) 

Type Sub_Type Requirement How Measured D

76 Sensing Location Relative Location accuracy (CEP)

Reporting po

point. Relat

known start

the op

77 Sensing Location Absolute accuracy Meters 78 Sensing Mapping Operator annotations 1=Yes, 0=No Ability to ove

mark locatio

79 Sensing Mapping Equipment set up time Minutes 

Assumes sys

to site. As

Externa

80 Sensing Mapping Spatial Modeling 1=Yes, 0=No Spatial mo81 Sensing Mapping Waypoint annotation Scale 1 - 5 

Ability to ove

mark locatio

Scale Defin

and automa

82 Sensing 

Passive Data

Logging 

Offboard 

Location 1=Yes, 0=No

83 Sensing 

Passive Data

Logging 

Offboard 

Hazmat 1=Yes, 0=No

55 
Preliminary Report 

Requirement 

Number 

(starred 

ones are 

Wave 1 

candidates) 

Type Sub_Type Requirement How Measured D

84 Sensing 

Passive Data

Logging 

Offboard 

Victim Indicators 1=Yes, 0=No

85 Sensing 

Passive Data

Logging 

Offboard 

System Health 1=Yes, 0=No

86 Sensing 

Passive Data

Logging 

Onboard 

Location 1=Yes, 0=No

87 Sensing 

Passive Data

Logging 

Onboard 

Victim Indicators 1=Yes, 0=No

88 Sensing 

Passive Data

Logging 

Onboard 

Hazmat 1=Yes, 0=No

89 Sensing 

Passive Data

Logging 

Offboard 

Visual 1=Yes, 0=No

89 Sensing 

Passive Data

Logging 

Onboard 

Visual 1=Yes, 0=No

90 Sensing 

Passive Data

Logging 

Onboard 

System Health 1=Yes, 0=No

56 
Preliminary Report 

Requirement 

Number 

(starred 

ones are 

Wave 1 

candidates) 

Type Sub_Type Requirement How Measured D

91 Sensing Structural Void Detection 1=Yes, 0=No Detecting bu92 Sensing Structural Range Finder 1=Yes, 0=No Distance 93 Sensing Victim IndicatorsThermal Imaging Scale 1 - 5 

Scale de

3=Military spe

US&R need

94 Sensing Victim IndicatorsSeismic 1=Yes, 0=No

Meet or ex

detection ca

95 Sensing Video Pan Degrees Indepen

* 96 Sensing Video Real time remote video system (Near) Range (mm)

97 Sensing Video Pan/Tilt rate Degrees/sec 98 Sensing Video Pan/Tilt orientation 1=Yes, 0=No Pan/Tilt 

57 
Preliminary Report 

Requirement 

Number 

(starred 

ones are 

Wave 1 

candidates) 

Type Sub_Type Requirement How Measured D

* 99 Sensing Video Real time remote video system (Far) Range (meters) 

Resolution o

using visual a

Limiting cas

structural inte

should be 

Operator mu

entir

100 Sensing Video Tilt Degrees Indepen

* 101 Sensing Video Field of View Degrees With macro 

image, ant

102 Logistics Cache packaging Transportation Restrictions 1=Yes, 0=No Confor

transp

103 Operating Environment Electrified Environment 1=Yes, 0=No Concern is 

source and 

58 
Preliminary Report 

APPENDIX C: TOTAL NUMBER OF VOTES RECEIVED BY EACH REQUIRE

ROBOT/DEPLOYMENT CATEGORY

The table below captures the number of votes for each requirement versus the robot or deployment category. The requirements do not eAppendix B, as some categories were added after the voting was completed. For each requirement, Task Forces voted whether it was applicable to each given robot/deployment category. For example, the “Chassi(number 1) was voted applicable to Robot/deployment category 1 by eight Task Forces, and to Robot/deployment category 2 by thirtee

Robot/Deployment Categories (See Table 3 

Type Sub-Type Requirement Description 1 2 3 4 5 6 7 8 9 1

1. Chassis Tether point

Hard point on chassis allows vertical insertion. 8 13 11 9 11 13 10 6 9 

1. Chassis 

System ComponentInteroperability 

Interoperability of taskbased requirements beyond Minimum Capabilities. Includes all chassis, payload, and operator interface components. 9 12 12 6 10 10 8 11 13 

2. Chassis Illumination Adjustable 12 13 12 9 10 12 10 9 8 3. Chassis Structural Shoring 

Typically providing vertical support. 1 5 4 1 10 3 2 0 0 0 

4. Communications

ExpandableBandwidth 

Will support additional operational components without loss of data transmission rate sufficient to allow eachcomponent to perform its function. 7 12 12 9 10 11 9 10 11 

59 
Preliminary Report 

Robot/Deployment Categories (See Table 3 

Type Sub-Type Requirement Description 1 2 3 4 5 6 7 8 9 1

5. Communications Range Beyond Line Of Sight

Must be able to ingress specified number of feetin worst-case collapse. Worst case is a reinforced steel structure. 13 13 13 9 11 13 10 10 12 

6. Communications Security

System must be shielded from jamming interference andencrypted. Scale defined: 1=None,3=Command; 5=Bothdata and command. 10 13 13 10 10 13 10 12 13 

7. Communications Range Line of Sight 10 11 10 9 8 11 8 11 11 8. Communications Data Logging Status and Notes 

Ability to pick up and leave notes. 6 11 12 6 5 10 7 8 9 

9. Human-System

Interaction Portability Assumes 1 piece robot 13 11 9 8 9 11 8 9 12 

10. Human-System

Interaction Initial Training Leads to certification. 13 13 13 10 11 13 10 12 13 

11. Human-System

Interaction Proficiency education Structured environment. 11 13 13 10 11 13 10 12 13 

12. Human-System

Interaction Operator ratio Per robot 11 13 13 10 11 13 10 12 13 

13. Human-System

Interaction ** Acceptable Usability

Percent of tasks users can complete. 10 13 13 10 11 13 10 12 13 

14. Human-System

Interaction Assistive Unattended sampling

Ability to set an interval between sampling during dwell time. 8 9 10 10 8 9 10 12 12 

60 
Preliminary Report 

Robot/Deployment Categories (See Table 3 

Type Sub-Type Requirement Description 1 2 3 4 5 6 7 8 9 1

15. Human-System

Interaction Assistive Auto Notification

System notifies operator when conditions arisethat need attention. 13 12 13 10 10 12 10 11 12 

16. Human-System

Interaction Assistive Path Tracing 

Repetitive traversing anoperator-defined path in relative meters from anoperator defined path.True 3D. Within theoperating environment. 3 10 10 6 8 9 9 9 8 

17. Human-System

Interaction Assistive Auto Station Keeping

Maintaining Pose (position plus orientation) relative to an operator defined target. 7 9 9 10 10 8 8 9 9 

18. Human-System

Interaction Assistive Emergency stop

Immediately upon loss ofcomms or on operator command. 8 9 13 7 8 9 8 8 8 

19. Human-System

Interaction

Assistive: Mobility Reacquire comms 10 12 12 6 9 12 10 12 12 

20. Human-System

Interaction

Assistive: Mobility Self Extraction

Extraction means autonomous ability to regain operational availability. 2 10 11 8 8 10 10 5 5 

21. Human-System

Interaction

Assistive: Victim Indicators

Probability ofDetection 

Must be able to detectlive victims. 7 11 9 6 7 10 6 6 6 

22. Human-System

Interaction Context

Remote informationsharing 

Real time, withpersonnel not colocated. 8 9 11 6 7 9 7 10 10 

23. Human-System

Interaction Context

Operator disengagement

Ability to break tether to system. 6 12 11 9 10 11 9 6 7 

24. Human-System

Interaction Context

Co-located information sharing 5 10 11 7 7 11 7 10 9 

61 
Preliminary Report 

Robot/Deployment Categories (See Table 3 

Type Sub-Type Requirement Description 1 2 3 4 5 6 7 8 9 1

25. Human-System

Interaction Context Lighting Conditions 

Special emphasis on no light and glare. 12 12 13 10 11 13 9 11 10 

26. Human-System

Interaction Context Mobility

Scale; 1=Stationary;3=Can't run system while moving; 5=Run system while moving.Moving is assumed to be on foot. 13 12 12 8 11 13 9 12 12 

27. Human-System

Interaction Context Mobility 

Scale Defined:1=Wearable; 3=1+operate while moving;5=1+2+hands free 13 12 12 8 10 12 9 12 12 

28. Human-System

Interaction Context Protective Clothing

Scale: 1=No protection;3=Minimum protection (threshold); 5=Completeprotection (Objective) while maintaining acceptable usability 11 12 11 8 11 12 9 11 11 

29. Human-System

Interaction Display Dashboard 

General chassis system health and status. (e.g.orientation, comm strength, power level). Two types ofinformation: I. Organic:1) Health--power, motor, sensor. Comm--radio transmission, reception.2) Pose--location;absolute (x,y,z) or relative. 3) Constraint--inhibitors, manipulator problems, sensingoccluded, blocked. II. External: 1) 12 12 13 10 10 13 9 12 12 

62 
Preliminary Report 

Robot/Deployment Categories (See Table 3 

Type Sub-Type Requirement Description 1 2 3 4 5 6 7 8 9 1

30. Human-System

Interaction Display

Mission data Integration 

Includes all add-on sensors. 7 11 13 9 9 12 8 12 12 

31. Human-System

Interaction Interaction Component controls To include diagnostics. 7 13 12 9 10 12 9 12 12 

32. Human-System

Interaction Interaction

Adjustable noisefiltering 5 12 9 6 5 9 5 4 6 

33. Logistics 

Cache packaging--Weight Per container 12 13 11 8 10 13 9 10 12 

34. Logistics MTBF Operating hours. 11 12 13 10 11 13 9 12 12 35. Logistics 

Cache packaging--Setup Time 

Time from on-sitedelivery to operation. 12 12 13 8 11 13 10 12 12 

36. Logistics Shock resistance 

Organic chassis without mission specificcomponents. Organic includes directional audio, position sensors. 13 12 13 9 11 13 10 8 11 

37. Logistics 

Cache packaging--Volume

Scale defined: 1=Pelican 1650 box; 3=Hardigg box checkable on commercial aircraft; 5=Ropack model 4048,4039 with drop door 11 12 11 9 10 13 10 10 12 

38. Logistics 

Field Maintenance Spares and Supplies

Self sustaining for 72 hours. 11 12 12 10 10 13 10 12 12 

39. Logistics 

Field Maintenance Duration 10 11 12 9 10 12 9 12 12 

63 
Preliminary Report 

Robot/Deployment Categories (See Table 3 

Type Sub-Type Requirement Description 1 2 3 4 5 6 7 8 9 1

40. Logistics 

Field Maintenance Tools 

Scale Defined:1=Requires special tools, 3=Simple tools (e.g., screw driver), 5=No tools required 12 11 13 10 10 12 9 12 12 

41. Logistics 

Field Maintenance Intervals 

Mean time betweenroutine maintenance. 10 11 13 9 10 12 9 12 12 

42. Mobility Aerial Area of coverage Recon and Surveillance. 8 8 8 6 7 6 6 12 11 43. Mobility Aerial Station keeping 

Maintaining Pose (position plus orientation) relative to an operator defined target. 5 6 8 7 5 6 6 12 11 

44. Mobility Locomotion Sustained speed-Soft 6 11 12 7 8 12 9 2 3 45. Mobility Locomotion 

Sustained speedObstacles 4 10 10 7 9 12 9 2 3 

46. Mobility Locomotion 

Sustained speedFirm 7 11 12 7 9 12 9 2 3 

47. Mobility Locomotion Endurance-Firm 

Endurance at a sustained speed. 5 12 13 7 10 11 9 2 3 

48. Mobility Locomotion Endurance-Soft

Endurance at a sustained speed. 4 12 13 8 10 11 9 2 3 

49. Mobility Locomotion Endurance-Obstacles

Endurance at a sustained speed. 4 12 11 9 9 11 9 2 3 

50. Mobility Mobility

Tumble recoverywithin Terrain Type 

Scale defined: 1=None;3=Self righting;5=Invertible continuous operations 11 12 10 8 10 13 9 3 5 

64 
Preliminary Report 

Robot/Deployment Categories (See Table 3 

Type Sub-Type Requirement Description 1 2 3 4 5 6 7 8 9 1

51. Mobility Water Bottom crawler 4 5 4 0 5 5 4 1 0 0 52. Mobility Water Surface swimmer 0 0 0 0 0 0 0 0 0 0 53. Mobility Water Underwater swimmer Not on bottom. 0 0 0 0 0 0 0 0 0 0 54. Operating 

Environment

Explosive Environments

Meet or exceeds Class I, Division I, Groups A, B,C, D. 11 11 11 10 11 11 10 8 9 

55. Operating 

Environment Max Temperature 11 12 13 9 11 13 10 11 12 

56. Operating 

Environment Water 

Scale: 1=Not water resistant; 2=Wash down; 3=Submersible; 4=Water resistant to 12 meters. 11 12 13 8 11 13 10 10 11 

57. Operating 

Environment Min Temperature 10 9 12 9 10 10 9 11 11 

58. Payload Manipulation Ability to open doors 

Internal, external, varietyof standard knobs and push doors. 0 10 9 1 3 2 4 0 0 

59. Payload Manipulation Sensor manipulation

Includes reach and dexterity components. 0 9 13 1 6 6 7 2 0 

60. Payload Manipulation Spray Decon, marking, etc. 0 10 10 1 4 5 7 1 0 61. Payload Manipulation Max Reach 0 8 9 4 5 2 6 3 0 62. Payload Emplacement Vertical, horizontal 2 9 11 6 9 7 8 5 9 

65 
Preliminary Report 

Robot/Deployment Categories (See Table 3 

Type Sub-Type Requirement Description 1 2 3 4 5 6 7 8 9 1

63. Payload Delivery 2 11 12 5 8 9 9 7 10 64. Payload Retrieval 

Picking up foreign objects at max reach notconfigured for a robot. 0 11 11 3 6 5 8 4 1 

65. Power Dwell Time

Amount of time system can remain active butstationary. 10 11 11 9 11 11 10 10 11 

66. Power Working Time 

Must have sufficientpower to operate for specified number ofhours. Assumes one power charge. One outand back mission. 12 12 13 9 11 13 10 12 13 

67. Power Sustainment

Amount of time system must be able to operate in field before re-supply is needed. 10 12 12 9 11 13 10 12 12 

68. Power Runtime Indicator 

Must be able to inform operator of remaining power level (percent). 11 12 13 10 11 13 10 12 12 

69. Power 

Voltage compatibility with cache 

Must be adaptable toother power sources inthe cache. 5 6 7 5 8 8 7 4 5 

70. Sensing Remote temperature

Ability to checktemperature of surfaces before taking action 7 9 12 8 10 11 8 9 10 

71. Sensing Audio 2-way 

Scale defined:1=Volume control. Listen all the time, push to talk; 3=Stereo; 5=Directional indication. 10 12 13 8 11 13 9 4 8 

66 
Preliminary Report 

Robot/Deployment Categories (See Table 3 

Type Sub-Type Requirement Description 1 2 3 4 5 6 7 8 9 1

72. Sensing Hazmat Hazard Detection 

Scale:1=ph + O2, LEL,CO, H2s, RAD;2=+WMD and TIC detection;3=+WMD and TIC classification; 4=+Tentative WMD and TIC identification;5=+WMD and TIC sampling. Detection capabilities must meetcurrent capabilities as documented in industry standards. No latency 11 13 13 9 10 12 8 11 10 

73. Sensing Internal Orientation reporting 6 13 12 7 9 10 9 12 12 74. Sensing Location Absolute 

Reporting location onavailable maps or reference points. Scale defined: 1=Topologicalfrom start point;3=1+Mapping onto tolocal facility floor plans; 5=(1-4)+3D GIS map 8 9 11 6 8 10 8 9 9 

75. Sensing Location Relative

Reporting point locationrelative to start point. Relative meters means from a known starting point. True 3D. Withinthe operating environment. 9 10 13 6 10 11 9 11 10 

76. Sensing Location Absolute accuracy 5 8 7 4 6 7 6 8 9 

67 
Preliminary Report 

Robot/Deployment Categories (See Table 3 

Type Sub-Type Requirement Description 1 2 3 4 5 6 7 8 9 1

77. Sensing Mapping Operator annotations

Ability to overlay operator waypoints tomark locations or features of interest. 6 12 12 7 11 11 9 8 9 

78. Sensing Mapping 

Equipment set up time

Assumes system has been transported to site.Assume 0,0,0 start point.External tracking equipment. 8 12 11 8 9 11 9 11 11 

79. Sensing Mapping Spatial Modeling 

Spatial modeling oftraversed path. 5 11 9 4 5 9 8 8 10 

80. Sensing Mapping Waypoint annotation

Ability to overlay operator waypoints tomark locations or features of interest. Scale Defined:1=Manual;3=Manual and automatic; 5=Fully automatic and integrated. 5 10 11 6 9 11 8 10 11 

81. Sensing 

Passive DataLoggingOffboard Location 12 12 12 8 10 11 9 12 13 

82. Sensing 

Passive DataLoggingOffboard Hazmat 10 12 12 9 10 11 7 12 13 

83. Sensing 

Passive DataLoggingOffboard Victim Indicators 9 11 11 8 10 12 7 11 12 

84. Sensing 

Passive DataLoggingOffboard System Health 10 12 12 9 11 12 7 12 13 

68 
Preliminary Report 

Robot/Deployment Categories (See Table 3 

Type Sub-Type Requirement Description 1 2 3 4 5 6 7 8 9 1

85. Sensing 

Passive DataLoggingOnboard Location 6 9 12 6 8 10 6 7 8 

86. Sensing 

Passive DataLoggingOnboard Victim Indicators 5 8 11 5 7 8 5 6 5 

87. Sensing 

Passive DataLoggingOnboard Hazmat 7 10 12 6 6 8 5 7 5 

88. Sensing 

Passive DataLoggingOnboard Visual 7 8 11 5 7 8 4 7 6 

89. Sensing 

Passive data LoggingOnboard System Health 7 10 12 7 6 8 5 7 6 

90. Sensing Structural Void Detection 

Detecting but notnecessarily enteringvoids. 3 11 7 5 9 9 5 1 2 

91. Sensing Structural Range Finder 

Distance to target. Accuracy: +-resolution. 2 13 10 5 8 9 8 8 7 

92. Sensing 

Victim Indicators Thermal Imaging 

Scale defined:1=Industry spec;3=Military spec; 5=Particularly useful for US&R needs such as structural, leak detection, fire. 4 11 12 6 8 8 5 7 6 

93. Sensing 

Victim Indicators Seismic 

Meet or exceed currentDelsar life detection capabilities for both Hzand db. 4 10 7 6 4 6 4 0 2 

94. Sensing Video Pan 

Independent of robotmobility. 7 13 13 8 8 11 8 10 10 

69 
Preliminary Report 

Robot/Deployment Categories (See Table 3 

Type Sub-Type Requirement Description 1 2 3 4 5 6 7 8 9 1

95. Sensing Video 

Real time remotevideo system (Near) 9 13 12 10 9 12 8 9 8 

96. Sensing Video Pan/Tilt rate 5 11 10 6 8 11 7 7 7 97. Sensing Video Pan/Tilt orientation 

Pan/Tilt orientation indicator. 7 13 13 6 8 11 7 9 9 

98. Sensing Video 

Real time remotevideo system (Far) 

Resolution of the image will be tested using visual acuity tests atgiven range. 11 13 13 9 9 12 8 12 11 

99. Sensing Video Tilt 

Independent of robotmobility. 7 13 13 6 8 11 7 8 8 

100. Sensing Video Field of View

With macro capability. Maintain clear image,anti fog, low lightcapability 11 11 11 10 9 10 8 10 9 

70 
Preliminary Report 

APPENDIX D - GLOSSARY

The Glossary included herein contains terminology from two different domains that are relevant to the US&R Robot

Standards Program: Urban Search and Rescue and Unmanned Systems, which are listed in the following two

sections, respectively. 

URBAN SEARCH AND RESCUE TERMS AND DEFINITIONS 

The following sources were used to obtain the terms and abbreviations. The source document for each is noted.

[1] FEMA US&R-2-FG “Urban Search and Rescue Response System Field Operations Guide” September 

2003. 

[2] FEMA 9356.1-PR “Urban Search and Rescue Response System In Federal Disaster Operations: 

Operations Manual” January 2000. 

[3] FEMA Emergency Support Function #9 Urban Search and Rescue Annex

[4] DHS SAFECOM Program PSWC&I Statement of Requirements Version 1.0, March 10, 2004

Access control: Both the public safety users as well as the public safety user's device(s) must be authenticated 

before they are given access to network resources. [4]

ACN: Automatic Call Notification [4]

ACS: American College of Surgeons [4]

Activation: Formal request from DHS/FEMA to a TF via the Point of Contact, that an event has occurred or is 

projected to occur, that requires mobilization and response for a mission. [1]

Advisory: Formal notification by DHS/FEMA to all TFs that an event is imminent or has occurred but does not

require action at this time. [1] Lowest level of notification, used to provide information only. An advisory is issued

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

provide a means for sharing information concerning incidents, events, or response activities being conducted by

other Federal departments and agencies that may or may not result in broader Federal support. [2]

Aerial Port of Debarkation: Arrival airfield in or near the area affected by the disaster or emergency. In the

National US&R Response System, also known as the Point of Arrival. [3]

Aerial Port of Embarkation: Departure airfield in the vicinity of a US&R task force’s home base. In the National 

US&R Response System, also known as the Point of Departure. [3]

Affected Area: The area identified in the major disaster declaration which is eligible to receive disaster assistance

in accordance with the provisions of Public Law 93-288. Also referred to as the designated area. [2]

71 
Preliminary Report 

After-Action Debriefing Form: Used by the TF managers at the conclusion of a mission to collect and categorize 

appropriate information. [1] 

After-Action Meeting: A formal meeting of the TF personnel assigned to a mission after return from the field. [1]

After-Action Report: Documentation of TF actions and other pertinent information. [1]

Air Mobility Command (AMC): DoD command headquarters at Scott Air Force Base in Illinois. The AMC is the 

Air Force airlift component responsible for securing transport for task forces and movement to the affected area. [2]

AirLift Control Element (ALCE) : DoD unit that provides command and control for all aircraft loading 

operations. The ALCE interfaces between the task force and the air base to load all task force cache items on the 

aircraft. The ALCE also facilitates training and other coordination activities during non-emergency times. An ALCE 

is part of an AirLift Control Squadron (ALCS). [2]

Alert: Formal notification by DHS/FEMA to identified TFs that a disaster is imminent or has occurred that may 

result in activation. [1] 

Assembly Point (AP): Location or facility where TF members initially report after receiving activation orders from

the sponsoring organization. [1]

ATF: Bureau of Alcohol, Tobacco and Firearms [4]

Attack detection and prevention: The communications networks must be resistant to jamming; they must be 

capable of passive/active attack monitoring and defense deployment; they must be able to geo-locate the source of 

an attack; and, they must be capable of monitoring of all functional aspects by authorized users/devices [4]

Authorization: Once a user has been granted access to the system, the services and information that the user has 

access to will be determined by that users' authorization level. [4]

AVL: Automatic Vehicle Location [4]

Base of Operations: TF base camp used to facilitate mission activities. [1]

Base Support Installation: Any military installation of any service or agency designated by the Department of 

Defense to provide civil authorities with specified, integrated support of disaster operations. The installation is 

normally located outside, but within relative proximity to, the disaster area. [3]

Cache: A DHS/FEMA-approved complement of tools, equipment, and supplies stored in a designated location,

available for emergency use. [1]

CAD-Computer Aided Dispatch [4]

Catastrophic Disaster Response Group (CDRG): Representatives from Federal agencies that have FRP 

responsibilities. The CDRG's primary role is that of a centralized, coordinating entity available at the call of the 

Chairperson. Its members have timely access to the policy makers in their respective parent organizations to

facilitate decisions on problem and policy issues. [2]

CBR&E-Chemical, Biological, Radiological, and Explosive [4]

CERT-Community Emergency Response Teams: Trained civilian volunteer auxiliary responders that assist victims 

and provide support for professional responders during a major disaster. [4]

Civilian advisory support: Subject matter experts that will be made available by FEMA to provide technical

advice to US&R components during mission operations. [2]

72 
Preliminary Report 

Clear text: An ICS term for use of plain language for radio communications. [2]

Collapse hazard zone: The area established by the TF for the purpose of controlling all access to the immediate 

area of the collapse. [1]

Commander-In-Chief. Transportation Command (CINCTRANS) : DoD command responsible for air 

transportation. Also refer to USTRANSCOM. [2]

Continental United States Army (CONUSA): DoD geographic division of the United States into two areas to

facilitate the management of Army assets. The two CONUSAs report to CINCFOR (Commander-In-Chief, Forces 

Command). [2] 

Data security: The communication networks must not allow unauthorized interception of communications or

information; they must not allow communications replay attacks; and, they must have non-repudiation capabilities to

ensure evidence in the event of a dispute. [4]

Day-to-day: Routine or day-to-day operations fit a general normal structure for the public safety personnel and

should not tax their ability to deal with communications processes and procedures. Many of these operations may be

strictly within the discipline or agency with no communications interoperability requirements with other disciplines 

or agencies at all. However, as described in the PSWAC Final Report, day-to-day operations can include the need 

for city law enforcement personnel to communicate with their county law enforcement personnel and vice versa. 

The ability to communicate minimizes the need for dispatcher-to-dispatcher interaction in the exchange of 

information among units in the field. Day-to-day operations can also include task force operations to carry out a

specific mission, such as a DUI (Driving Under the Influence) stake-out, where the communications are within the 

agency and do not require interoperability with other agencies. Also on a day-to-day basis, an agency (such as one 

fire district) can provide mutual aid to another agency (a second fire district) while the first agency covers an 

emergency. This form of mutual aid is different than the mutual aid interoperability discussed below. [4]

Defense Coordinating Officer (DCO): Federal official located at the DFO reporting to the FCO who facilitates 

State requests for DoD personnel and supplies through the ESF representatives. The DCO send all requests to

DOMS for execution. [2]

Demobilization: The process used to plan for and implement the return of TFs to their original Point of Departure. 

[1]

Department of Defense (DoD): A branch of the Federal government which is a support agency to ESF #9 - Urban 

Search and Rescue. [2]

Department of Homeland Security (DHS): The executive department of the United States [whose] primary 

responsibility is to: (a) prevent terrorism; (b) reduce the vulnerability of the United States to terrorism; (c) minimize 

the damage, and assist in the recovery, from terrorist attacks that do occur within the United States; (d) carry out all 

functions of entities transferred to the Department, including by acting as a focal point regarding natural and

manmade crises and emergency planning; (e) ensure that the functions of the agencies and subdivisions within the 

Department that are not related directly to securing the homeland are not diminished or neglected except by a

specific explicit Act of Congress; (f) ensure that the overall economic security of the United States is not diminished 

by efforts, activities, and programs aimed at securing the homeland; and (g) monitor connections between illegal 

drug trafficking and terrorism, coordinate efforts to sever such connections, and otherwise contribute to efforts to

interdict illegal drug trafficking. [1]

Department of Transportation (DOT): Federal department which is a support agency to ESF #9. DOT will 

provide information on the condition of airfields and ground transportation routes. DoD, as a supporting agency, will 

also provide transportation support. [2]

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

assistance in accordance with the provisions of Public Law 93-288. Also referred to as the affected area. [2]

73 
Preliminary Report 

DFFP-Department of Forestry and Fire Protection [4]

Directorate of Military Support (DOMS): DoD directorate located in the Pentagon that is the executing agent for 

the FRP. [2]

Disaster Field Office (DFO): The temporary office established in or near the designated disaster area from which 

the Federal Coordinating Officer and staff, the Emergency Response Team, the State Coordinating Officer and staff 

(when possible), and regional response organizations coordinate response activities. [1]

Disaster Medical Assistance Team (DMAT): The basic deployable unit of the National Disaster Medical System, 

which is administered by the Department of Health and Human Services. Staffed with physicians, nurses, other

health care professionals, and support staff, DMAT capabilities include triage and stabilization of patients at a 

disaster site and provision of austere medical services at transfer points during transport to definitive medical care 

locations. [3]

DMAT-Disaster Medical Assistance Teams: A mobile medical field unit staffed and equipped to treat large numbers 

of injured. [4]

DOT - Department of Transportation [4]

Emergency Response Team (ERT): The interagency group assembled to assist the assigned FCO in carrying out 

his/her disaster response coordination responsibilities. The ERT coordinates the overall Federal disaster response 

reporting on the conduct of specific operations, exchanging information, and resolving issues related to ESFs and

other response requirements. ERT members respond and meet as requested by the FCO. [1]

Emergency Response Team, Advance Element (ERT-A): An advance element of the ERT dispatched by the 

affected FEMA region to join State emergency management personnel to coordinate Federal assistance. [2]

Emergency signaling: Signals produced by aerosol horns on the US&R work site to address evacuation of the area, 

cease operations, or quiet the area, and resume operations. Refer to Appendix I – Task Force Communications 

Procedures. [2]

Emergency signaling: Signals produced by warning devices on the US&R work site to address evacuation of the 

area, cease operations or quiet the area, and resume operations. [1]

Emergency Support Function (ESF): A functional area of response activity established to facilitate the delivery 

of Federal assistance required during the immediate response phase of a disaster to save lives, protect property and

public health, and to maintain public safety. ESFs represent those types of Federal assistance which the State will 

most likely need because of the overwhelming impact of a catastrophic or significant disaster on its own resources

and response capabilities, or because of the specialized or unique nature of the assistance required. ESF missions are 

designed to supplement State and local response efforts. [1]

Emergency Support Team (EST): The Emergency Support Team (EST) is organized, using Incident Command 

System (ICS) functional groupings of management, operations, logistics, information and planning, and 

administration/finance, for the activation of the EST, of Federal resources, and mission assignments. The EST 

coordinates requests for additional resources and receives situation reports. [1]

EMT-P-Emergency Medical Technician-Paramedic [4]

Engagement/disengagement: Procedures followed by a TF when beginning or ending operations at a specific 

work site or assigned area. [1]

EOC-Emergency Operations Center [4]

Equipment Cache List: The FEMA approved list of equipment that a task force is required to possess for 

operations. The list represents the maximum equipment that should be carried by a task force. [2]

74 
Preliminary Report 

ERT ESF #9 Leader: The position on the ERT that assumes management and coordination of ESF #9 resources 

when the RST transfers all US&R responsibilities to the ERT and when the IST is operational in the field. The ERT 

ESF #9 Leader coordinates all US&R activities with the State, the Emergency Services Branch Chief, the IST ESF 

#9 Assistant, and the EST ESF #9 Leader. [1]

ESF #9 Assistant: The position located with the IST that provides management oversight to the IST. The ESF #9

Assistant coordinates with the EST and ERT ESF #9 cells, the IST Leader, Task Force Leaders, local and State 

incident management personnel, and supporting ESFs. [1]

ESF #9 cell (at the DFO): DHS/FEMA representatives at the DFO who coordinate State requests for US&R 

resources. [1]

ESF #9 Group (at the DFO): FEMA representatives at the DFO who coordinate State requests for US&R assets.

These individuals coordinate with a State US&R counterpart who is also located at the DFO. The ESF #9 Group 

sends requests to the IST who directs the task forces to incident locations. [2]

ESF #9 Leader: The individual at DHS/FEMA Headquarters responsible for assessing requests for US&R TFs. [1]

ESF #9 Program Officer: The individual at FEMA Headquarters responsible for assessing requests for the US&R 

task forces. The ESF #9 Program Officer coordinates closely with the DOMS and the Public Health Service to

ensure that task forces are deployed in a timely manner. [2]

ESF #9: National US&R Response System [1]

ESF #9: US&R emergency support function responsible for locating, extricating, and providing initial medical 

treatment to disaster victims and to conduct other life-saving operations. [2]

EST ESF #9 Leader: The individual at working at the EST responsible for assessing requests for US&R Task

Forces, alerting, activating and deploying ESF #9 resources when approved and overseeing ESF #9 mission

assignments, staffing, information and planning, and demobilization activities. [1]

Expendable property: The term used to identify items such as small hand tools, gloves, saw blades, batteries, etc., 

that may normally be consumed or expended during the course of a mission. [2]

Extended Area Network (EAN): Jurisdiction Area Networks that are linked with county, regional, state, and

national systems or extended area networks (EAN). [4]

FBI-Federal Bureau of Investigation [4]

Federal Coordinating Officer (FCO): The senior Federal official appointed to coordinate the overall response and 

recovery activities. The FCO represents the President for the purpose of coordinating the administration of Federal 

relief activities in the designated area. [2]

Federal Coordinating Officer (FCO): The senior official in charge at the DFO who manages all Federal response 

activities. [1]

Federal Emergency Management Agency (FEMA): Agency with primary responsibility for ESF #9 (Urban

Search and Rescue.) [1]

Federal Response Plan (FRP): The Federal Government's plan of action to assist affected States and local 

jurisdictions after a major disaster or emergency. [1] 

FEMA Regional Action Officer: The individual, operating out of a FEMA regional office, who routinely 

coordinates with the respective States within the region for US&R program activities and during times of mission

deployment. [2]

75 
Preliminary Report 

FEMA-Federal Emergency Management Agency [4]

Field Operations Guide (FOG): A pocketsize document that is carried in the field by US&R personnel. The FOG

provides instant access to reference material such as operational checklists, functional procedures, emergency 

directives, etc. [2]

General Services Administration (GSA): The Federal agency responsible to FEMA for providing on-site support

to the US&R task forces for supplies needed after the initial 72 hours of operation. [2]

GPS-Global Positioning System [4]

HAZMAT - Hazardous Materials [4]

HIPAA-Health Insurance Portability and Accountability Act [4]

IAFIS-Integrated Automated Fingerprint Identification System [4]

IC - Incident Command or Incident Commander [4]

ICS Form 205: Radio Communications Plan form for use during mission operations. [2]

IDENT-Immigration and Customs Enforcement Automated Biometric Identification System [4]

Incident Action Plan (IAP): A document developed by the ICS management team that identifies all incident

objectives, strategies and tactics, and assigns responsibilities. [1]

Incident Area Network (IAN): An incident area network (IAN) is a network created for a specific incident. This

network is temporary in nature. [4]

Incident Command Post (ICP): The location where the local jurisdiction's primary command functions are 

executed. [1]

Incident command structure: The communications systems must support the agency's incident command policies. 

[4]

Incident Command System (ICS): Common organizational structure with capability of managing the assigned 

resources in an effective manner. See NIIMS. [2]

Incident Commander (IC): The local jurisdiction's person responsible for the management of all incident

operations. [1]

Incident Daily Briefing Form: A form for conducting planning sessions and briefings during the course of a 

mission. [1]

Incident stress management: A process for allowing personnel to air their feelings and defuse emotions related to

stressful or traumatic disaster-related incidents. [2]

Incident Support Team — Advance Element (IST-A): An advance element of the IST, utilized to conduct needs 

assessments, provide technical advice and assistance to State and local government emergency managers, and 

prepare for incoming US&R task force and IST resources. The IST-A reports to the IST Commander. [3]

Incident Support Team (IST): The IST provides a group of highly qualified specialists readily available for rapid 

assembly and deployment to a disaster area. The IST furnishes Federal, State, and local officials with technical 

assistance in acquiring and using US&R resources. It provides advice, Incident Command assistance, management, 

and coordination of US&R Task Forces, and US&R logistics support. [1]

76 
Preliminary Report 

information on the real-time status of emergency medical personnel, resources, hospitals, and patients that is

accessible by command personnel, authorized responders, health care facilities, and so on. [4] 

Initial Task Force (TF) Briefing Form: A form used by the TFL and management staff during the activation 

phase of the response. The form highlights pertinent information about the event. [2]

Initial TF Briefing Form: A form developed for use during the activation phase of the response. [1]

Interactive data communications: These communications will provide practitioners with maps, floor plans, video

scenes, etc., during an emergency. In the context of the type of communications, interactive means that there is a 

query made and a response provided. The query and response need not be initiated by a practitioner and can include 

automated queries/responses. Commanders, supervisors, medical staff, etc., can make more intelligent decisions 

more efficiently with data from field personnel. Similarly, personnel entering a burning building armed with

information about the building, such as contents, locations of stairwells, hallways, etc., can also perform their duties 

better. [4]

Interactive voice communications: Communications between public safety practitioners and their supervisors, 

dispatchers, members of the task force, etc., that require immediate and high quality response, with much higher 

performance demands than those required by commercial users of wireless communications. Commands, 

instructions, advice, and information are exchanged that often result in life and health situations for public safety 

practitioners, as well as for the public. [4]

International Search and Rescue Advisory Group (INSARAG): A group of international Search and Rescue

(SAR) specialists formed for the purpose of advising the United Nations Department of Humanitarian Affairs on the 

development of standards that will be adopted and used by all international US&R task forces. [2]

IR-Infrared [4]

IST-Incident Support Team: Provides support to US&R teams with tasking, material, and coordination. US&R

teams are task forces equipped with the necessary tools and equipment and the required skills and techniques for the 

search, rescue, and medical care of victims of structural collapse. [4]

ITS-Intelligent Transportation System [4]

JABS-Joint Automated Booking System [4]

JIC-Joint Information Center [4]

Joint Information Center (JIC) : The physical location where Public Information Officers collocate and form the 

core of the Joint Information System. [1]

Joint Information System (JIS): The system designed to facilitate the exchange of information. The JIS creates a 

linkage among all PIOs on the Federal, State, and local levels and with the private sector, news media, and other key 

offices. [2]

Jurisdiction Area Network (JAN): The JAN is the main communications network for first responders. It is 

responsible for all non-IAN voice and data traffic. It handles any IAN traffic that needs access to the general 

network, as well as providing the connectivity to the EAN. [4]

LAN-local area network [4]

Lessons learned: Critique information captured from past experiences, documented, and distributed in an effort to

improve program operations. [2]

Load master: Individual responsible for all matters associated with preparing the TF equipment, supplies, and

personnel during the palletizing, loading, in-flight logistics, and down-loading of the aircraft. [1]

77 
Preliminary Report 

Local Emergency Operations Center (EOC): Each local jurisdiction will usually have an EOC to coordinate 

response to and support of moderate to large-scale incidents. Initial damage and needs assessment information is 

consolidated at this point to determine response needs and State and Federal asset requirements. Authority for the 

management of a disaster rests with the local officials and/or Incident Leader of the affected jurisdictions. State and 

Federal response is in support of local requests once local resources and capabilities are overwhelmed. [1]

Local jurisdiction: The affected locality/government that has the mandated responsibility for managing the disaster

within its borders or boundaries. [1]

MCC - Mobile Commander Center [4]

MCT-Mobile Computing Terminal [4]

Medical Team Fact Sheet: An informational sheet outlining the capabilities and requirements of the TF Medical 

Team. [1]

Memorandum of Agreement (MOA): Tripartite written agreement between FEMA, the sponsoring organization

for the US&R task force of the National US&R Response System, and the State of the sponsoring organization. The 

MOA outlines responsibilities of each signatory in the event of an activation of the National US&R Response 

System. The MOA serves as the basis for reimbursement of task force operational expenditures during activation. 

[3]

Memorandum of Understanding (MOU): Written agreements developed on site between the IST and

jurisdictional incident management personnel to ensure a complete understanding of the scope, nature and

requirements of the ESF #9 assignment. [1]

Mobilization Center: A temporary facility used to receive process and support resources/TFs during the 

mobilization and demobilization phases of a mission. [1]

Mobilization time frame: The time in which a task force is expected to assemble at the POD. Six hours is the 

identified time frame. [2]

Mobilization: The process used by all organizations, Federal, State, and local, for activating, assembling, and 

transporting resources requested. [2]

Movement Coordination Center (MCC): A group of representatives of Federal agencies (ESF #4, DOT, DoD, 

and FEMA) within the EST Operations Section that coordinates the movement of Federal resources. [2]

MSO-Mobile Switching Office [4]

Multicast: Occurs when one device sends data across the network to multiple devices; however, depending on the 

multicast protocol, only nodes that are on the path from the originating device to the receiving device receive and 

forward the data. [4]

Mutual aid: This mode describes those major events with large numbers of agencies involved, including agencies

from remote locations. Their communications are not usually well planned or rehearsed. The communications must

allow the individual agencies carry out their missions at the event, but follow the command and control structure 

appropriate to coordinate the many agencies involved with the event. [4]

National Disaster Medical System (NDMS): A system under the auspices of NDMS used during natural disasters

or emergencies. [1]

National Emergency Coordination Center (NECC): FEMA's office which provides notification to FEMA

Headquarters and regional responders of implementation of the plan and performs situation monitoring, alerting, and 

activation. [2]

78 
Preliminary Report 

National Interagency Incident Management System (NIIMS): An incident management system which consists

of five major subsystems. A total systems approach total risk incident management. The subsystems are the ICS, 

Training, Qualifications and Certification, Supporting Technologies, and Publication Management. See ICS. [2]

National Urban Search and Rescue Response System: The task forces, ISTs, and other personnel and technical

teams which respond to disasters under the direction of FEMA as Emergency Support Function #9. [2]

NAWAS-National Warning System [4]

NCIC-National Crime Information Center [4]

NIMS-National Incident Management System [4]

NIRSC-National Incident Radio Support Cache [4]

Non-expendable property: The term used to denote expensive, accountable items such as generators, radios, 

power tools, technical equipment, etc. [2]

Non-interactive data communications: A one-way stream of data, such as the monitoring of firefighter biometrics 

and location, which greatly increases the safety of the practitioners. This form of communications also makes the 

command and control requirements easier when the commander is aware of the condition and location of the onscene personnel. [4]

Non-interactive voice communications: These communications occur when a dispatcher or supervisor alerts 

members of a group about emergency situations and/or to share information. In many cases, the non-interactive 

voice communications have the same mission-critical needs as the interactive service. [4]

NPSTC-National Public Safety Telecommunications Council [4]

OEM-Office of Emergency Management [4]

Office of U.S. Foreign Disaster Assistance (OFDA): The Federal agency responsible for assisting FEMA in

requesting international assistance of US&R task forces through the United Nations Department of Humanitarian

Affairs. [2]

On site: Term used to refer to the operational area where a task force is assigned. [2]

Operating Site: The location of a structural collapse where US&R operations are being conducted. [3]

Operational checklist: A chronological listing of considerations and/or tasks that the identified user should address

when carrying out mission assignments. [1]

Operational period: The time interval scheduled for execution of a given set of US&R actions. [1]

Operational procedures: Documents developed to address strategies and tactics that a TF may be required to

address and execute during a mission response. [1]

Operational work area: The area established by the TF for controlling all activities in the immediate area of the 

work site. [1]

Operations Chief: The position in the Incident Command System that is responsible for managing the overall

incident tactical operations and to whom the US&R TFs directly or indirectly report. [1]

79 
Preliminary Report 

Operations Manual: A document in the FEMA National US&R Response System series that describes the 

operational processes used by task forces. The document draws from the FRP and includes standard operating 

procedures. [2]

Patient Care Form (PCF): A form used during the mission to document medical information relating to a victim

who receive treatment by the task force Medical Team. [2]

Personal Area Network (PAN): A first responder is equipped with wireless devices used to monitor the first 

responder's physical location, pulse rate, breathing rate, oxygen tank status, as well as devices for hazardous gases 

detection and voice communications. The devices are all linked wirelessly on a personal area network (PAN) 

controlled by the first responder's communications device. [4]

Personal property: The term used to denote items that are taken on a mission by task force personnel not provided

by the sponsoring organization. [2]

PIO - Public Information Officer [4]

Point of Arrival (POA): The location where responding resources arrive, prior to being transported to a 

mobilization center or assigned to an affected local jurisdiction. [1]

Point of Contact (POC): Designated official at the Federal, State, and local levels who have the primary 

responsibility for notification, activation, and acceptance reply for mobilization of task forces. [2]

Point of Departure (POD): Designated location where a TF reports for transport to an incident. [1]

Post-mission critique: A meeting of the task force personnel assigned to a mission and occurs within days after the 

return home. The critique provides the opportunity for individuals to share experiences and discuss lessons learned.

Information from the After-Action Debriefing Form may be used in the post-mission critique. [2]

Primary agency: The Federal agency assigned principal responsibility to manage specific ESFs. Primary agencies 

are designated on the basis of their having the most authority, resources, capabilities, or expertise relative to

accomplishment of the specific ESF. [2]

Privacy: The communications systems must allow only intended and authorized recipients to hear/see/read/modify 

information as well as follow national and state policies (e.g., Health Insurance Portability and Accountability ActHIPAA). [4]

Property accountability system: A plan for tracking and managing task force tools, equipment, and supplies 

during all phases of a mission. [2]

PSAP-Public Safety Answering Point: The answering center for 9-1-1 calls. [4]

PSCD-Public Safety Communications Devices: A term developed for the public safety operational scenarios, the 

PSCD is a portable (handheld or wearable) wireless communications device. [4]

PSTN-Public Switched Telephone Network: The public telephone system. [4]

PSWAC-Public Safety Wireless Advisory Committee [4]

Public Information Officer (PIO): An individual assigned responsibility for collecting and disseminating

information related to an incident. The PIO coordinates all media activities associated with the incident. [2]

RACES: Radio Amateur Civil Emergency Service [4]

80 
Preliminary Report 

Regional Operations Center (ROC): Serves as the initial POC for the affected State, other Federal agencies, and 

EST. The ROC ceases to be a coordinating center once the DFO is established. The ROC is located at the FEMA

regional office responsible for the affected State or at a location identified by the FEMA regional staff. [2]

Regional Support Team (RST): Entity that serves as the initial point of contact for the affected State(s), other 

Federal agencies, and the Emergency Support Team. The RST ceases to be a coordinating center once the DFO is 

established. [1]

Responder Information Sheet: A form to list all necessary information on task force personnel. [2]

Reverse 9-1-1: REVERSE 911 ® is a Microsoft Windows ® -based program that uses a patented combination of 

database and GIS technologies that can target a precise geographic area and saturate it with thousands of calls per 

hour. The software can also create a list of individuals with common characteristics (such as a Neighborhood Crime 

Watch group or emergency personnel) and contact them rapidly whenever necessary. [4]

Safety Officer: an individual assigned the primary responsibility of safety compliance. [1]

Search assessment marking: A distinct marking system used by task force personnel that denotes information

relating to the location of victims. It is used in conjunction with the structural/hazard evaluation marking system. [2]

Self-sufficiency: The capability of a task force to operate in a totally independent fashion. The FEMA standard for 

self-sufficient capability is for 72 hours. [2]

Site rehabilitation: Returning a building or grounds to the original condition prior to task force operations. [2]

SNS: Strategic National Stockpiles [4]

Sponsoring Organization: the entity responsible for developing and managing all aspects of a TF. [1]

Staging Area: A designated area or facility where incoming resources report to and receive their tactical 

assignments and situation briefings by the local jurisdiction. [1]

State Coordinating Officer (SCO): The person appointed by the Governor of the affected State to coordinate State 

and local response efforts with those of the Federal government. [2]

Support agency: A Federal department designated to assist a primary agency. [2]

System administration of users: The communications systems must allow authorized system administrators as well 

as incident and branch commanders to establish user profiles for network access and usage, depending upon the role 

that the public safety user is asked to satisfy during an incident. [4]

System to Locate Survivors (STOLS): An acoustic listening device used by specially trained personnel from the 

U.S. Army Corps of Engineers for the location of victims trapped in collapsed structures. [3]

Task Force Control Center (TFCC): Central control point within the task force Base of Operations used as a 

focal point by the task force for maintaining communications with elements of the task force. [2]

Task force: A tactical component of the FRP under ESF #9 - Urban Search and Rescue, composed of 62 persons 

(refer to the FEMA US&R Task Force Description Manual). [2]

T-Card System: A resource tracking system using different color cards displayed in a folder or hanging rack. [2]

Temporary network: JANs and EANs are networks that exist at all times whereas the IANs are created on 

temporary basis to serve a particular purpose, such as an incident and then are dissolved. The nature of the IAN is

such that it may not reach all areas of an incident. In such cases, the user would either connect to the JAN, or create 

a temporary network to extend the IAN to the area not covered. [4]

81 
Preliminary Report 

TF Base of Operations Locations Checklist: A form to assist task force personnel when selecting a location for 

set up of their BoO. [2]

TF Command Post (TFCP) : Central control point within the TF BoO. [1]

TF Fact Sheet: summarizes the composition, capabilities and limitations, and support requirements of a US&R TF. 

[1]

TF Medical Team Fact Sheet: A form that summarizes the capabilities of the task force Medical Team. This form

can be used when briefing the local officials. [2]

TF Operations Report: A form for documenting events during the execution of rescue operations. [1]

TF: Task force. [2]

TFL's Mission Assignment Checklist: A form for use by the TFL that identifies important information during the 

initial briefing provided by the local Incident Commander. [2]

Time-Phased Force Deployment Data (TPFDD): An electronic file that describes the task force in terms of 

number of personnel and equipment in weights and cubic feet. [2]

U.S. Forest Service (USFS): Federal agency that can be tasked by GSA to set up and operate mobilization centers.

As a support agency to ESF #9, the USFS may also provide available aircraft, personnel, and equipment. [2]

U.S. Public Health Service (USPHS): An agency within the Department of Health and Human Services. [2]

U.S. Transportation Command (USTRANSCOM): DoD command which coordinates the movement of air 

assets for moving task forces. [2]

United Nation’s Office for the Coordination of Humanitarian Affairs (OCHA): Entity located in Geneva, 

Switzerland tasked with the overall responsibility for disseminating information and coordination of international 

disaster relief activities. [2]

Urban Search and Rescue (US&R): The term used to define the strategy, tactics, and operations for locating, 

providing medical treatment, and extrication of entrapped victims. [2]

US&R TF Fact Sheet: A form that summarizes the composition, capabilities and limitations, and support 

requirements of a FEMA US&R task force. Used by the TFL when briefing local officials. [2]

US&R-Urban Search and Rescue: A task force equipped with necessary tools and equipment and the required

skills and techniques for the search, rescue, and medical care of victims of structural collapse. [4]

USAR: The term used to identify the United States Army Reserve. [2]

User identification and location: The communications systems must provide user identification to others during

communications and when required, must provide user geo-location information to incident commanders and other

authorized resources. [4]

User/User group: Public safety personnel and resources that are recognized by the system to share communications 

and information. This implies that traffic related to this user group only traverses the portion of the network

necessary to reach all members of particular user group. Each user group can be a permanent unit or a temporary

unit created by an authorized user for a particular task. [4] 

82 
Preliminary Report 

UNMANNED SYSTEMS GENERIC TERMS AND DEFINITIONS

Adapted from NIST Special Publication 1011 “Autonomy Levels for Unmanned Systems (ALFUS) Framework” 

Note: The ALFUS Framework definitions were developed primarily for describing military unmanned systems 

(UMS). Definitions solely applicable to military systems have been deleted. The original ALFUS definitions

contain numerous citations for reference works and explanatory notes. These have not been reproduced. Instead an

‘*’ at the end of the definition indicates further references and notes contained in the original document. The

interested reader is referred to the original document. 

Adapt to Failures and Operational Conditions: An unmanned system experiencing either system failures or

operational conditions that prevent it from continuing its optimal mission profile will react within the confines of its 

capabilities. Adaptation with respect to capabilities includes hover, orbit, stop, and station keeping. This adaptation 

is performed by the system until the condition is cleared or by the operator. System requirements may mandate that 

the unmanned system continue to perform the mission in a degraded mode. 

Autonomous: Operations of an unmanned system (UMS) wherein the UMS receives its mission from the human 

and accomplishes that mission with or without further human-robot interaction (HRI). The level of HRI, along

with other factors such as mission complexity, and environmental difficulty, determine the level of autonomy for 

the UMS. Finer-grained autonomy level designations can also be applied to the tasks, lower in scope than mission. 

* 

Associated terms:

Fully autonomous: See under Mode of Operation. 

Semi-autonomous: See under Mode of Operation. 

Autonomous Collaboration: The ability of a UMS to collaborate with one or more manned vehicles or UMS 

without the need for an external controlling element. 

Autonomy: (A) The condition or quality of being self-governing. (B) A UMS’s own ability of sensing, perceiving, 

analyzing, communicating, planning, decision-making, and acting, to achieve its goals as assigned by its human 

operator(s) through designed HRI. Autonomy is characterized into levels by factors including mission complexity, 

environmental difficulty, and level of HRI to accomplish the 

missions. *

Associated terms:

Autonomy Level or Level of Autonomy: Set(s) of progressive indices, typically given in numbers,

identifying a UMS’s capability for performing autonomous missions. Two types of metrics are used, 

Detailed Model for Autonomy Levels and Summary Model for Autonomy Levels. 

Autonomy Levels for Unmanned Systems (ALFUS): A general term referring to the autonomy level 

framework, models, and the level numbers. 

Detailed Model for Autonomy Levels: A comprehensive set of metrics that represent multiple aspects of 

concerns, including mission complexity, environmental difficulty, and level of HRI that, in combination,

indicate a UMS’s level of autonomy. This model corresponds to the Summary Model for Autonomy

Levels. 

Summary Model for Autonomy Levels: A set of linear scales, 0 through 10 or 1 through 10, indicating 

the level of autonomy of a UMS. This model is derived from the UMS’s Detailed Model for Autonomy

Levels. 

83 
Preliminary Report 

Built-in Test: Equipment or software embedded in operational components or systems, as opposed to external

support units, which perform a test or sequence of tests to verify mechanical or electrical continuity of hardware, or 

the proper automatic sequencing, data processing, and readout of hardware or software systems. 

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

• Micro: < 8 pounds5 

• Miniature: 8-30 pounds 

• Small (light): 31-400 pounds 

• Small (medium): 401-2,500 pounds 

• Small (heavy): 2,501-20,000 pounds

• Medium: 20,001-30,000 pounds 

• Large: >30,000 pounds. 

Cognizance Levels or Levels of Cognizance: The levels of what a UMS can know or understand based on its

sensory processing capability: 

• Level 1 – data, or observed data. In initially processed forms after measured by sensors. 

• Level 2 – information. Further processed, refined and structured data that is human understandable. 

• Level 3 – intelligence, knowledge, combat and actionable information. Further processed for particular 

mission needs. Directly linked to tactical behaviors. 

Collaboration or Cooperation: The process by which multiple manned or unmanned systems jointly work 

together by sharing data, such as coordinates of their maneuver(s) and local Common Relative Operational Picture 

(CROP), or by acquiring intelligence to perform a mission synergistically, i.e., perform better than each could have

alone. * 

Associated term: 

Coordination: The ability for UMS’s or manned systems to work together harmoniously through common

data such as mission or task plans, coordinates of maneuver(s), local CROP, etc. A common way is for a 

superior to coordinate the task execution of the subordinates to accomplish the missions. *

Control Level or Level of Control. * 

Controlling Element: The part of a UMS that provides a method for a human to control it remotely. 

Cooperation: See Collaboration. 

Coordination: See under Collaboration. 

Data Fusion: See Fusion. 

Detailed Model for Autonomy Levels: See under Autonomy. 

Dynamic mission planning: See mission planning.

Environment: Used as a general reference, environment includes the generic, natural conditions; e.g., weather, 

climate, ocean conditions, terrain, vegetation, etc. Modified environment can refer to specific induced environments; 

e.g., dirty battlefield environment, nuclear-chemical biological environment, etc. Environment includes those 

conditions observed by the system during operational use, standby, maintenance, transportation, and storage. 

Mission environment includes threat situation or Electronic Order of Battle (EOB), Rules of Engagement (ROE), 

Emission Condition (EmCon), etc. 

84 
Preliminary Report 

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

hardware or software faults. *

Fully autonomous: See under Mode of Operation. 

Fusion: Also referred to as Information Fusion or Data Fusion. (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 interpretation of the data and information and to support system goals like recognition, 

tracking, situation assessment, 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 draws out the significance of those correlations. The processes 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 estimation, complete and timely assessments of situations and threats, and their 

significance in the context 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 process itself, 

to achieve improved results. * 

Fusion Levels or Levels of Fusion: Each of the six levels of fusion adds progressively greater meaning and 

involves more analysis: *

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

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

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

existing entity database, and updates that database. Level 1 Fusion tells you what is there and can 

result in actionable information.

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

aggregations, and resolves conflicts. This level captures or derives events or actions from the 

information and interprets them in context with other information. Level 2 Fusion tells you how

they are working together and what they are doing. 

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

and how enemy elements operate, and predicts enemy future actions and their effects on friendly

forces. This is a threat refinement process that projects current situation (friendly and enemy) into

the future. Level 3 Fusion tells you what it means and how it affects your plans. 

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

timeliness, relevance and accuracy of information and/or intelligence. It reviews the performance 

of sensors and collectors, as well as analysts, information management systems, and staffs 

involved in the fusion process. This process tells you what you need to do to improve the products 

from fusion level 0-3. 

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

visualize the fusion products and generate feedback/control to enhance/improve these products. 

Goal: A result (or state) to be achieved or maintained. *

Hazard Avoidance: Similar to obstacle avoidance except that the subjects are not limited to physical objects but 

also include adversarial situations, as either assessed by the UMS’s perception functions or provided through the 

HRI, that are to be avoided.

Human/Operator Intervention: The need for HRI in a normally fully autonomous behavior due to some

extenuating circumstances. An unanticipated action or input by the user to help complete a task. 

Human robot coordination: See coordination. 

Human Robot Interaction/Interface (HRI): Also referred to as human interaction or operator interaction. (A)

The activity by which human operators engage with UMSs to achieve the mission goals. (B) The architecture for 

interaction between the robot and the human. It includes the specification of the interaction language: what tasks the 

85 
Preliminary Report 

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

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

anticipated interactions between the robot and the user. (C) Human Robot Interface is further used to reference the 

physical realization of the method of Human Robot Interaction or Intervention. The following are the different 

roles of interaction possible for the human in HRI. Note that one person could possibly assume a number of roles or

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

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

awareness of other roles simultaneously interacting with the robot. 

Supervisor: the supervisor monitors one or more robots with respect to progress on the mission, can task 

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

missions, and can assign an operator to assist a robot if needed. A commander would be an example of a

person who performs the supervisor-only role. 

Teammate/Wingman: this is considered to be a human team member. UMS and its teammate each 

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

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

Operator: the role assumed by the person performing remote control or teleoperation, semiautonomous operations, or other man-in-the-loop types of operations. The operator input is expected at

certain states during normal operations. During error conditions, the operator determines the problem that a 

robot is experiencing in interacting with the physical world, interacts with the robot to solve this if possible 

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

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

Mechanic or Developer: determines the problem with the hardware or software that the robot is having, 

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

the robot to the supervisor with a determination. 

Bystander: coexists in the same environment as the UMS but with an unknown role. The bystander role 

could be neutral, friendly, or adversarial, or include various combinations. The bystander and the UMS 

need to build up some expectation of what the counterpart will do in order to react accordingly. For 

example, the driver, a bystander, of a car may have to interact at a four way stop with a UMS. They both

need some indication as to whether the other vehicle knows the rules of the road. Pedestrians and traffic 

police would be examples of bystanders who would have limited interaction with autonomous driving 

vehicles. UMS needs to be able to protect itself from possible harm from adversarial bystander. 

Human Operated: The type of HRI that refers to remote control or teleoperation. 

Human Assisted: The type of HRI that that refers to situations during which human interactions are needed at the

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

Human Delegated: The type of HRI that refers to situations during which human interactions are mainly at the 

task level. 

Human Supervised: The type of HRI that refers to situations during which humans play the monitoring role and

human interactions are mainly at the mission level. 

Information Fusion: See Fusion.

Leader Follower: See Robotic Follower. 

Markers (physical or electronic) : A visual or electronic aid used to mark a designated point for such tactical 

purposes as route following, determination of bearings, courses, or location, and key items or points of interest, 

including landmine markers, minefields markers, and area NBC decontamination markers. Traffic signs and signals 

are additional examples of Markers. 

86 
Preliminary Report 

Methods of Control: The interface, either software or hardware, such as a joystick, waypoint selection via a map 

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

Mission: The highest-level task assigned to the UMS. * 

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

missions. It can be easily installed and replaced by another type of mission module. * 

Mission Planning: The process to generate tactical goals, a route (general or specific), commanding structure, 

coordination, and timing for one or teams of UMSs. The mission plans can be generated either in advance by

operators on an OCU or in real-time by the onboard, distributed software systems. The latter case is also referred to

as dynamic mission planning. * 

Mobility: The capability of a UMS to move from place to place, with its own power and while under any mode or 

method of control. Characteristics: the UMS’s speed, location, and fuel availability. Refueling could be performed

either as a part of the HRI or autonomously by a fuel management autonomy task at a higher level. * 

Mode of Operation or Operational Mode: Human operator’s ability to interact with a UMS to perform the 

operator assigned missions. The following are the defined modes of operation: fully autonomous, semiautonomous, teleoperation, and remote control. *

Associated terms:

Fully autonomous: A mode of operation of an UMS wherein the UMS is expected to accomplish its 

mission, within a defined scope, without human intervention. Note that a team of UMSs may be fully 

autonomous while the individual team members may not be due to the needs to coordinate during the 

execution of team missions. 

Semi-autonomous: A mode of operation of a UMS wherein the human operator and/or the UMS plan(s) 

and conduct(s) a mission and requires various levels of HRI. * 

Teleoperation: A mode of operation of a UMS wherein the human operator, using video feedback and/or

other sensory feedback, either directly controls the actuators or assigns incremental goals, waypoints in 

mobility situations, on a continuous basis, from off the vehicle and via a tethered or radio linked control

device. In this mode, the UMS may take limited initiative in reaching the assigned incremental goals. * 

Remote control: A mode of operation of a UMS wherein the human operator, without benefit of video or

other sensory feedback, directly controls the actuators of the UMS on a continuous basis, from off the 

vehicle and via a tethered or radio linked control device using visual line-of-sight cues. In this mode, the 

UMS takes no initiative and relies on continuous or nearly continuous input from the user. *

Observation: (A) The information collection stage of the "OODA Loop" (Observation, Orientation,

Decision, Action); (B) Measurement of the environment by sensors that produce signals that can be analyzed. * 

Obstacle: (A) Any physical entity that opposes or deters passage or progress, or impedes mobility in any other way. 

(B) Any obstruction designed or employed to disrupt, fix, turn, or block the movement of an opposing force, and to

impose additional losses in personnel, time, and equipment on the opposing force. Obstacles can be natural, 

manmade, or a combination of both. They can be positive, negative (e.g., ditches), or groupings (e.g., areas with 

high security alert) and can be moving or still. *

Operational Mode: See Mode of Operation. 

Operator Control Unit (OCU): Also referred to as operator control interface (OCI) or human interaction 

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

with, receive data and information from, and plan missions for one or more UMSs. * 

87 
Preliminary Report 

Orientation: (A) The stage in the OODA loop (Observation, Orientation, Decision, Action) that involves analysis 

and prediction and generates information to support decision making stage (B) Rotational displacement between two 

coordinate frames of reference. 

Perception: A UMS’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. *

Associated term: 

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

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

Perception Levels or Levels of Perception. The progressive results of sensory information after the data have gone 

through multiple levels of sensory processing: *

• Level 1 – point or pixel. A point of concern has physical properties that, quantitatively, can be either 

measured with the systems’ sensor(s) in a one-to-one correspondence or computed over time and 

space. 

• Level 2 – line or list. Groupings of sets of points according to certain criteria, such as continuity in 

position and direction, over space and/or time. 

• Level 3 – surface or boundary. Groupings of sets of contiguous lines or lists according to certain criteria, 

such as continuity in orientation or curvature, over space and/or time. 

• Level 4 – object. Groupings of sets of contiguous surfaces and boundaries according to certain criteria, 

such as rigid body mechanics, over space and/or time. 

• Level 5 – unit of objects. Groupings of sets of objects according to certain criteria, such as density, 

distribution, and relative positions, motions, and interactions, over space and/or time. 

Prognostic Health Management: System using artificial intelligence or other intelligent algorithms and a 

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

operational and maintenance characteristics of the system or systems under consideration. * 

Remote Control: See under Mode of Operation. 

Remotely Guided: An unmanned system requiring continuous input for mission performance is considered

remotely guided. The control input may originate from any source outside of the unmanned system itself. This mode

includes remote control and teleoperation. 

Robot/Robotic: An electro-mechanical system that can react to sensory input and carry out predetermined 

missions. A robot is typically equipped with one or more tools or certain capabilities, including knowledge so that it 

can perform desired functions and/or react to different situations that it may encounter [4].

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

hardware, and software aspects. * 

Self-Diagnosis: Ability to adequately take measurement information from sensors, validate the data, and

communicate the processes and results to other intelligent devices. *

Semi-Autonomous: See under Mode of Operation. 

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 activities. *

Sensor Fusion: (A) same as fusion except limiting data source to sensors. (B) A process in which data, generated 

by multiple sensory sources, is correlated to create information and knowledge. Sensor information, when fused,

88 
Preliminary Report 

may yield immediately actionable combat information and/or intelligence. The capabilities are of four essential 

types: Detection, Classification, Recognition, and Identification. *

Sensory Processing: Computing processes that operate on either direct sensor signals or on low level sensory 

signatures 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. There 

are several ways to organize the progressive sensory processes, to perceive the resulting information, and to 

structure the knowledge and intelligence: 

• Levels of Fusion: See Fusion Levels. 

• Levels of Perception: See Perception Levels. 

• Levels of Cognizance: See Cognizance Levels. 

Situational Awareness: The perception of elements in the environment within a volume of time and space, the 

comprehension of their meaning, and the projection of their status in the future. In generic terms the three levels of

situational awareness are level 1, perception, level 2, comprehension, and level 3, projection. There is both 

individual and group or team situational awareness. * 

Summary Model for Autonomy Levels: See under Autonomy. 

Task: A named activity performed to achieve or maintain a goal. Mission plans are typically represented with

tasks. Task performance may, further, result in subtasking. Tasks may be assigned to operational units via task

commands [3]. 

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

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

management effectiveness. * 

Teleoperation: See under Mode of Operation. 

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

similar to that which the operator would receive if he were in the vehicle. *

Terrain: The physical features of the ground surface, to include the subsurface. These physical features include 

both natural (e.g., hills) and manmade (e.g., pipelines) features. Major terrain types are delineated based upon local 

relief, or changes in elevation, and include: flat to rolling, hilly and mountainous. Other important characteristics 

used to describe the terrain include: hydrologic features (e.g., swamps), vegetation characteristics (e.g., forests) and

cultural features (e.g., cities). Complex terrain includes any characteristics or combination of characteristics that 

make military action 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 especially relevant to the use of different classes 

of UGVs. The three mobility classes are: unrestricted, restricted, and severely restricted. *

Terrain Visualization: A component of battlefield visualization that provides a detailed understanding of the 

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

common terrain background for all users and all applications. Additionally, terrain visualization allows interactive 

planning and mission rehearsal. Terrain visualization includes both natural and man-made features to include

impacts of terrain on vehicle speed, maintenance, river-crossing operations, cross-country trafficability, and

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

management, display and dissemination. Derived from [27]. 

Tether: 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 physical medium. * 

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

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

89 
Preliminary Report 

Unmanned System (UMS): A electro-mechanical system, with no human operator aboard, that is able to exert its 

power to perform designed missions. May be mobile or stationary. Includes categories of unmanned ground vehicles 

(UGV), unmanned aerial vehicles (UAV), unmanned underwater vehicles (UUV), unmanned surface vehicles 

(USV), unattended munitions (UM), and unattended ground sensors (UGS). *

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

goal location. * 

World Model: A UMS’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. {3}. 

Associated term: 

World Modeling: The process of constructing and maintaining a world model. 

Unattended ground sensors (UGS): Small, low cost, robust sensors, capable of operating in the field for extended

periods of time (30 days or more). They will consist of modular groups of sensors utilizing tailorable ground sensing 

technologies, such as seismic, magnetic, infrared, acoustic, radio frequency, and CBRN detection, and other 

advanced sensing capabilities. UGSs self-organize into a networked sensor array (sensor web) by locating the most 

efficient gateways for transmission of information. They are also self-healing, able to quickly bypass a neutralized

gateway and locate a functional one within the sensor web. * 

90