Proceedings of the AUVSI's Unmanned Systems North America 2005, June 2005, Baltimore, MD.
A Framework For Autonomy Levels For Unmanned Systems
(ALFUS)
Hui-Min Huang i, Kerry Pavek ii, Brian Novak iii, James Albus i, Elena Messina i 1Introduction
京东京豆
Rapid evolution of mobile robotic technology is witnesd by the fact that unmanned
vehicles have begun to be fielded in many problem areas ranging from homeland curity and battlefield support to Mars exploration. Military and civilian agencies continue to
expand the roles that unmanned systems (UMS) may rve. As government agencies
continue to specify UMS capabilities for future applications, there are increasing
demands for a facilitating common framework. The demands include a common
terminology for characterizing the UMS requirements and standard metrics for evaluating the autonomous capability of the UMS. Individual government agencies have begun the efforts toward buil
ding facilitating frameworks. The Department of Defen Joint
Program Office (JPO), the U.S. Army Maneuver Support Center, and the National
Institute of Standards and Technology (NIST) have, in parate but related efforts,
described levels of robotic behaviors for the Army Future Combat Systems (FCS)
program [1, 2, 3]. The Air Force Rearch Laboratory (AFRL) has established an
Autonomous Control Levels (ACL) [4] scale. The Army Science Board has described a
t of levels of autonomous behavior [5]. Central to the efforts is the concept of
autonomy levels for the UMS. It is extremely beneficial that the and other agencies
leverage each other’s efforts and aim at a government and industry-wide consistent and
standard approach.
Recognizing the benefits and the needs, in July 2003 an initiative was launched to
asmble key reprentative practitioners from U.S. Departments of Commerce (DoC),
Defen (DoD), Energy (DoE), and Transportation (DoT) (and their supporting
contractors). This group asmbled at NIST and formed the Autonomy Levels For
Unmanned Systems(ALFUS) Ad Hoc Work Group to address the autonomy issue.
2Requirement Analysis
As the technological frontier for unmanned systems has expanded, the potential
applications for their u have also expanded. The technological and application
expansions have complicated the urs’iv problem in articulating both the potential for,
and requirements associated with, the u of UMS. A common means by which to
articulate both capabilities and requirements is esntial to the ability of the ur
i National Institute of Standards and Technology, Gaithersburg, Maryland 20899-8230 { hui-min.huang, james.albus,
ii Titan Corporation, U.S. Army Unit of Action Mounted Battle Laboratory, Contractor; phone: 502-624-8783;
Kerry.Pavek@knox.army.mil.
iii Army Tank-Automotive Rearch, Development & Engineering Center (TARDEC); Phone: 586-574-5913;
NovakB@tacom.army.mil.
iv The term ur is ud in a broad n, covering operators, their supervisors, the UMS acquirers, etc.
community to adequately express its needs, and allows for the establishment of a “language” that is understood by all facets of the acquisition community.
The expansion in capabilities (and therefore potential operational application) from simple tele-opera
ted systems that perform a specific task within a well defined environment to more complex, autonomous or mi-autonomous systems that perform multiple tasks in complex environments has evolved veral means by which disparate “Ur communities” articulate their needs. The DoD “Joint Ur” community has struggled for years to find a common method of articulating its requirements given the wide range of operational and organizational contexts across the rvices. The disparate missions and u of UMS within other government agencies (DoT, DoE, DoC, NASA, etc.) have also complicated intelligent comparison of and dialog about UMS capabilities. To best capitalize on limited funding, cross-fertilization of ideas, experiences and technology among cross-agency efforts is en as esntial and would be enhanced by a common baline for discussion.
The Ur community, therefore, has articulated two major thrusts/needs:
• A common vernacular that could be ud to articulate capabilities (common t of definitions). This facilitates comparisons between systems/capabilities,
and allows for disparate organizations to intelligently discuss issues
surrounding the u of Unmanned Systems capabilities within their
operational constructs.
• A means by which to articulate the amount of autonomy required/expected from an Unmanned System. This would facilitate interactions between the
Urs, Rearch and Development agencies, and Materiel Developers.
The variety of autonomous systems currently envisioned for u by government and non-government entities makes a common t of terminology and definitions paramount. It also provides a challenge to the determination of the proper metrics to apply so that the definitions and metrics can be universally utilized in all the UMS vehicle domains: aerial (UAV), ground (UGV), underwater (UUV), surface (USV), etc. The end result of the creation of a common vernacular would be to enhance the common understanding of terms which would, in turn, be a key enabler for intelligent dialog and collaboration amongst disparate organizations.
In terms of defining autonomy, the Ur community es two levels of need. At an executive level, there is a need to provide a means by which to easily articulate requirements. This would provide a means of common communication between the Ur and Material Developer in expressing requirements, but would also provide an easy to understand method of explaining autonomy requirements to decision makers. At a more technical level, the Ur community es a need for a t
ool by which interactions between the Ur, Material Developer, Industry, and the Test Community can be made easier. This tool could then be ud to articulate system-specific, specification-level detail and provide a framework for the testing/verification of autonomy.
The combination of common terms and definitions and a means to define autonomy are en as key enablers for the interaction and cooperation amongst Urs and Developers of UMS. This has the potential of increasing the ability of disparate organizations (across the government and industry) to interact and collaborate in the development of UMS technologies facilitating cost savings and knowledge sharing.
3Work Group Objectives, Plan, and Approach
The overall objectives for the work group are to produce:
•Standard terms and definitions to facilitate characterizing the levels of autonomy for unmanned systems.
•Metrics, methods, and process for evaluating and measuring the autonomy of unmanned systems.
The development plan for the Group contains the following phas:
沙家浜景区•Pha 1, Development of Framework Content
Develop the core technical content of the ALFUS framework. This effort will be an iterative process between a top-down approach for constructing the generic
framework and a bottom-up approach for evaluating the framework concepts
through u-ca experiments with lected application programs.
•Pha 2, Enhancement and Evolution of the Framework
o Investigate and develop testing and validation plans and methods. Generalize the framework further by experiments in additional domains.
o Revi and upgrade the framework bad on ur feedback. Expand metrics as testing and measurement technologies advance. For example, continued
rearch efforts may produce measurement methods for certain metrics that
are currently hard to measure, such as workload for a robotic operator.
•Pha 3, Expansion. Investigate expansion of the ALFUS framework to a generic performance metrics framework for unmanned systems (“PerMFUS”).
The planned migration path of the work group effort is:
•Start as a government only ur effort.
•Include the contractors for the lected u ca programs once the critical elements of the Framework have been established, during Pha 1.
•Open to industry, during Pha 2.
•Migrate to a U.S. or international standards development organization (SDO), during Pha 2.
4Participation
The government organizations and programs that are reprented in the ALFUS work group include:
DoD:
•Aviation Applied Technology Directorate (AATD)* v
•Air Force Rearch Laboratory (AFRL)
v Asterisks denote U.S. Army.
•Aviation and Missile Rearch, Development and Engineering Center (AMRDEC)*
•Army Rearch Laboratory (ARL)*
•Communication-Electronics Rearch Development & Engineering Center (CERDEC)*
•Defen Advanced Rearch Projects Agency (DARPA)
•Maneuver Support Center (MANCEN)*
•Naval Air System Command Naval Air System Command (NAVAIR)
•Naval Sea System Command (NAVSEA)
•Naval Rearch Laboratory (NRL)
一吃东西就拉肚子是什么原因
•The Office of the Secretary of Defen/ Joint Project Office (OSD/JPO)
•Tank-Automotive Rearch, Development & Engineering Center (TARDEC)* •Training and Doctrine Command (TRADOC) Systems Manager Future Combat System (TSM FCS)*
•TRADOC Unit of Action Maneuver Battlelab (UAMBL)*
DoC – National Institute of Standards and Technology (NIST)
DoE – Headquarter (HQ), Idaho National Engineering and Environmental Lab (INEEL) DoT – Federal Highway Administration (FHWA)
怎样提高情商The work group has identified FCS as its first u ca. Therefore, the FCS Lead System Integrator (LSI), namely, the Boeing and SAIC companies and their subcontractors are also reprented in the work group.
Each of the entities has identified a need for autonomy level definitions.
5ALFUS Framework
Nine workshops have been conducted, so far, in an effort to develop the ALFUS framework. The accomplishments include:
5.1Formulated the ALFUS Framework
We envision that a generic autonomy level framework should include:
• A t of terms and definitions for UMS that facilitates communications on the UMS autonomy requirements and capabilities.
• A Detailed Model for the autonomy levels that includes ts of identified metrics ud for evaluating the autonomy levels for UMSs.
• A Summary (or Executive) Model that defines an autonomy scale from zero or one through ten. This scale can be ud for describing the UMS autonomy levels at a high level of abstraction.
We further envision that this generic framework is to be instantiated for various UMS programs specific ALFUS models. The resulting ALFUS framework [6] is illustrated in Figure 1.
申请书格式模板Generic ALFUS
Framework
Program Specific ALFUS Frameworks
Figure 1: ALFUS Framework
5.2 Established the metrics ts for the Detailed Model
Mission Complexity
*EMI
decoy
Figure 2: ALFUS Detailed Model
The ALFUS framework Detailed Model contains the following defining concepts:
• UMS autonomy concerns multiple technical areas. Task complexity and
adaptability to environment are among the key aspects.
• The nature of UMSs’ collaboration with human operators, such as the levels
of involvement and types of interaction is important to the autonomy
capability.
• Performance factors, such as mission success rate, respon time, precision,
resolution, and allowed latencies affect a UMS’s autonomy levels [7].
The ALFUS Detailed Model is shown in Figure 2. In this three-axis model, the
autonomy level is determined by the complexity of the missions that a UMS is able to perform, the degrees of difficulty of the environments within which the UMS can perform the missions, and the levels of operator interaction that are required to
perform the missions. Note that we ud curved lines to connect the three scores for
each of the illustrated vehicles to indicate that urs might u some complex algorithms, as oppod straightforward, weighted-average ones, to determine the vehicles’ resulting autonomy levels. The curve lines also imply that they may be
busy的最高级
ud to define maximum capabilities, i.e., the UMSs can perform at any combination
of complexity/difficulty/independence that lies on or below the surfaces.
Mission complexity could be measured with the metrics of: levels of subtasking, decision making, and collaboration, knowledge and perception requirements,
planning and execution performance, etc. Human independence level (HI) can be measured with the metrics of: interaction time and frequencies, operator workload,
skill levels, robotic initiation, etc. Environmental difficulty can be measured through obstacle size, density, and motion, terrain types, urban traffic characteristics, ability to recognize friends/foe/bystanders, etc. Work is underway to define measuring scales
for the metrics. Priorities will be t to include the metrics in various versions of the framework.
5.3Established a process model for ALFUS
Figure 3 depicts how the autonomy levels for a UMS can be evaluated in the ALFUS framework. We outline the process as the following:
大学生生活规划
•An identified mission is decompod, via an adopted method, to generate a task structure covering from the mission to the lowest level skills. This is shown on
the top of Figure 3, from left to right. An earlier paper describes some of the
current concepts [8]. The NIST 4D/RCS [9] architecture may provide a viable
method. However, modifications might be needed to suit the purpos of
autonomy level analysis.
•The decompod subtasks or skills should be assigned relative weights (labeled as “task weight” in the Figure) in terms of their criticality to the performance of the
parent tasks or missions.
•The metrics should be reviewed and relative weights (labeled as “metric weight”
in the Figure) should be assigned bad on the particular focus or requirements that the applying program has established. Non-applicable metrics are weighted
zero.
奥地利蒂罗尔•As shown in the MC row in the Figure, tasks and skills are evaluated and scored against each of the metrics. A composite score for each task is obtained through a weighted average (or a different integration method if the ur prefers) of all the
individual metric scores. The “task/skill complexity” box depicts the result.
Note that “additional constraints,” such as inter-metric dependence, could
conceivably affect the metric scores. This issue will be further developed in the
future.
•Composite scores for the higher-level tasks or missions can be obtained similarly through the weighted averages of the subtask scores, as the corresponding boxes
in the Figure depict.
•The UMS autonomy levels can be determined by the vehicle’s overall mission scores.
