SAE ARP 6128-2013 Unmanned Systems Terminology Based on the ALFUS Framework《基于自治水平无人系统(ALFUS)框架的无人系统术语》.pdf

《SAE ARP 6128-2013 Unmanned Systems Terminology Based on the ALFUS Framework《基于自治水平无人系统(ALFUS)框架的无人系统术语》.pdf》由会员分享，可在线阅读，更多相关《SAE ARP 6128-2013 Unmanned Systems Terminology Based on the ALFUS Framework《基于自治水平无人系统(ALFUS)框架的无人系统术语》.pdf（13页珍藏版）》请在麦多课文档分享上搜索。

1、_ SAE Technical Standards Board Rules provide that: “This report is published by SAE to advance the state of technical and engineering sciences. The use of this report is entirely voluntary, and its applicability and suitability for any particular use, including any patent infringement arising there

2、from, is the sole responsibility of the user.” SAE reviews each technical report at least every five years at which time it may be revised, reaffirmed, stabilized, or cancelled. SAE invites your written comments and suggestions. Copyright 2013 SAE International All rights reserved. No part of this p

3、ublication may be reproduced, stored in a retrieval system or transmitted, in any form or by any means, electronic, mechanical, photocopying, recording, or otherwise, without the prior written permission of SAE. TO PLACE A DOCUMENT ORDER: Tel: 877-606-7323 (inside USA and Canada) Tel: +1 724-776-497

4、0 (outside USA) Fax: 724-776-0790 Email: CustomerServicesae.org SAE WEB ADDRESS: http:/www.sae.org SAE values your input. To provide feedback on this Technical Report, please visit http:/www.sae.org/technical/standards/ARP6128 AEROSPACE RECOMMENDED PRACTICE ARP6128 Issued 2013-03 Unmanned Systems Te

5、rminology Based on the ALFUS Framework RATIONALE Common terminology is important to the user community as well as the standards committees to effectively communicate the technical issues and the application of other SAE AS-4 documents. TABLE OF CONTENTS 1. SCOPE 2 1.1 Purpose . 2 2. REFERENCES 2 2.1

6、 Applicable Documents 2 2.2 Related Publications . 3 2.3 Terminology/Definitions 3 3. NOTES 12 SAE ARP6128 Page 2 of 13 1. SCOPE This SAE Aerospace Recommended Practice (ARP) describes terminology specific to unmanned systems (UMSs) and definitions for those terms. It focuses only on terms used excl

7、usively for the development, testing, and other activities regarding UMSs. It further focuses on the autonomy and performance measures aspects of UMSs and is based on the participants earlier work, the Autonomy Levels for Unmanned Systems (ALFUS) Framework, published as NIST Special Publication 1011

8、-I-2.0 and NIST Special Publication 1011-II-1.0. This Practice also reflects the collaboration results with AIR5665. Terms that are used in the community but can be understood with common dictionary definitions are not included in this document. Further efforts to expand the scope of the terminology

9、 are being planned. 1.1 Purpose The purpose of this Aerospace Recommended Practice is to communicate to the unmanned systems community a common set of terminology and definitions that can be used as guidance for designing, developing, testing, or otherwise describing an unmanned system or any of its

10、 subsystems. 2. REFERENCES 2.1 Applicable Documents The following publications form a part of this document to the extent specified herein. The latest issue of SAE publications shall apply. The applicable issue of other publications shall be the issue in effect on the date of the purchase order. In

11、the event of conflict between the text of this document and references cited herein, the text of this document takes precedence. Nothing in this document, however, supersedes applicable laws and regulations unless a specific exemption has been obtained. 2.1.1 SAE Publications Available from SAE Inte

12、rnational, 400 Commonwealth Drive, Warrendale, PA 15096-0001, Tel: 877-606-7323 (inside USA and Canada) or 724-776-4970 (outside USA), www.sae.org. AIR5665 Architecture Framework for Unmanned Systems 2.1.2 NIST Publications Available from National Institute of Standards and Technology, 100 Bureau Dr

13、ive, Stop 1070, Gaithersburg, MD 20899-1070, Tel: 301-975-6478, www.nist.gov. NIST Special Publication 1011-I-2.0 Autonomy Levels for Unmanned Systems (ALFUS) Framework Volume I: Terminology, Version 2.0 NIST Special Publication 1011-II-1.0 Autonomy Levels for Unmanned Systems (ALFUS) Framework Volu

14、me II: Framework Models, Version 1.0 SAE ARP6128 Page 3 of 13 2.2 Related Publications The following publications are provided for information purposes only and are not a required part of this SAE Aerospace Technical Report. 2.2.1 ASTM Publications Available from ASTM International, 100 Barr Harbor

15、Drive, P.O. Box C700, West Conshohocken, PA 19428-2959, Tel: 610-832-9585, www.astm.org. ASTM E2521 Standard Terminology for Urban Search and Rescue Robotic Operations ASTM F2541 Standard Guide for Unmanned Undersea Vehicles (UUV) Autonomy and Control ASTM F2395 Standard Terminology for Unmanned Air

16、 Vehicle Systems 2.3 Terminology/Definitions See Appendix A for references. 2.3.1 ACTUATOR A motor or mechanism capable of controlled prismatic (linear) or revolute (angular) motion. 2.3.2 AGENT An entity that can act on behalf of another entity. 2.3.3 AUTONOMOUS Operations of an unmanned system (UM

17、S) wherein the UMS receives its mission from the human or agent 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 2. Fin

18、er-grained autonomy level designations can also be applied to the tasks, lower in scope than mission. 2.3.3.1 Associated Terms Fully Autonomous - See under MODE OF UNMANNED SYSTEM OPERATIONS. Semi-Autonomous - See under MODE OF UNMANNED SYSTEM OPERATIONS. Autonomous Collaboration - The ability of a

19、UMS to collaborate with one or more manned vehicles or UMS without the need for an external controlling element. 2.3.4 AUTONOMOUS COLLABORATION See under Autonomous. 2.3.5 AUTONOMY a. The condition or quality of being self-governing 1. b. A UMSs own ability of sensing, perceiving, analyzing, communi

20、cating, planning, decision-making, and acting, to achieve its goals as assigned by its human operator(s) through designed human robot interface. Autonomy is characterized into levels by factors including mission complexity, environmental difficulty, and level of HRI to accomplish the missions. SAE A

21、RP6128 Page 4 of 13 2.3.5.1 Associated Terms Autonomy Level or Level of Autonomy - Set(s) of progressive indices, typically given in numbers, identifying a UMSs capability for performing autonomous missions. Two types of metrics are used, Detailed Model for Autonomy Levels and Summary Model for Auto

22、nomy Levels. 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 UMSs level of autonomy. This model corresponds to the Summary Model

23、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 UMSs Detailed Model for Autonomy Levels. 2.3.6 AUTONOMY LEVEL OR LEVEL OF AUTONOMY See under Autonomy. 2.3.7 AUTONO

24、MY LEVELS FOR UNMANNED SYSTEMS (ALFUS) A framework within which UMS autonomy can be characterized, identified, or evaluated with respect to the context. ALFUS is metrics based and provides a common vernacular to facilitate autonomous capability articulation. 2.3.8 BYSTANDER See under HUMAN ROBOT INT

25、ERACTION. 2.3.9 COLLABORATION or COOPERATION Multiple agents working together to achieve a common goal. 2.3.10 CONTEXTUAL AUTONOMY OR CONTEXTUAL AUTONOMOUS CAPABILITY (CAC) MODEL FOR UNMANNED SYSTEMS (UMS) A UMSs Contextual Autonomy or CAC is characterized by the missions that the system is capable

26、of performing, the environments within which the missions are performed, and human independence that can be allowed in the performance of the missions. Each of the aspects, or axes, namely, mission complexity (MC), environmental complexity (EC), and human independence (HI) is further attributed with

27、 a set of metrics, or capabilities in the complementary perspective, to facilitate the specification, analysis, evaluation, and measurement of the CAC of particular UMSs. This CAC model facilitates the characterization of UMSs from the perspectives of requirements, capability, and levels of difficul

28、ty, complexity, or sophistication. The model also provides ways to characterize UMSs autonomous operating modes. The three axes can also be applied independently to assess the levels of MC, EC, and autonomy for a UMS. 2.3.11 CONTROL The ability to compensate for differences between actual and intend

29、ed or desired states. 2.3.12 CONTROLLING ELEMENT The part of a UMS that provides a method for a human or agent to control it remotely. 2.3.13 COOPERATION See COLLABORATION. SAE ARP6128 Page 5 of 13 2.3.14 COORDINATION Effort made to guide or, in another way, facilitate multiple participant activitie

30、s to achieve defined purposes. Respective participant activities might be generated for the reason to harmonize with each others or one anothers to be able to achieve the defined purposes. Such defined purposes can be mutually agreed upon among the participants or be authorized by a separate entity.

31、 2.3.15 DETAILED MODEL FOR AUTONOMY LEVELS See under Autonomy. 2.3.16 DEVELOPER OR MECHANIC See under HUMAN ROBOT INTERACTION (HRI). 2.3.17 DYNAMIC MISSION PLANNING See Mission Planning. 2.3.18 E-STOP OR EMERGENCY STOP A control action commanded by an operator that removes power to all the moving fu

32、nctions and to any other function that, by design, may cause safety hazards. The procedure of the E-Stop is executed immediately once the command is received. The execution cannot be altered and overrides all the other UMS controls. A reset by the operator is required for further operations of an E-

33、Stopped UMS. E-Stop may not be applicable to all UMSs at all times. For example, a UAV may employ an E-stop function only when the UAV is on the ground. Explicitly designed procedures are to be executed, instead, upon the occurrence of in-flight emergency situations 10. 2.3.19 END EFFECTOR The last

34、link of a manipulator, often modular to accept various tools or instruments. 2.3.20 ENVELOPE A set of propulsion, pose, and kinematic limits within which mobility meets a set of specified criteria. 2.3.21 FEATURE CLASS A classification assigned to geographic features; a means of differentiating type

35、s of data within a world model knowledge store. 2.3.22 FULLY AUTONOMOUS See under MODE OF UNMANNED SYSTEM OPERATIONS. 2.3.23 GEOREFERENCED INFORMATION The coordinates of the origin of an object with respect to a world coordinate system. 2.3.24 HARDPOINT A location on a platform that is capable of ca

36、rrying external stores. 2.3.25 HAZARD A real or potential condition that could lead to unplanned, adverse events resulting in death, injury, occupational illness, damage to or loss of equipment or property, or damage to the environment 13. SAE ARP6128 Page 6 of 13 2.3.26 HOST PLATFORM A system that

37、serves a place of residence for hardware- and software-based system functions. 2.3.27 HUMAN ASSISTED Planned or unplanned human interaction for the performance of a system function. 2.3.28 HUMAN DELEGATED A system function assigned to or intended to be performed by a human. 2.3.29 HUMAN INDEPENDENCE

38、 (HI) A situation in which a UMS is performing mission or task activities without HRI. HI is complementary to HRI and is one aspect of the three-aspect ALFUS Metric Model. 2.3.30 HUMAN OPERATED The type of HRI that refers to remote control or teleoperation. 2.3.31 HUMAN/OPERATOR INTERVENTION The hum

39、an / operator decision and action to assume a task previously assigned to be autonomous or to another human. 2.3.32 HUMAN ROBOT INTERACTION (HRI) Also referred to as human interaction or operator interaction. a. The activity by which human operators engage with UMSs. It is independent of a particula

40、r display or interaction modality. b. The architecture for interaction between the robot and the human. It includes the specification of the interaction language: what tasks the user can ask of the robot and the corresponding actions, what tasks the robot can ask of the user and the corresponding ac

41、tions. It is independent of a particular display or interaction modality. It is the planned and anticipated interactions between the robot and the user. 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

42、 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. Super

43、visor - 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

44、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.

45、 SAE ARP6128 Page 7 of 13 Operator - The role assumed by the person performing remote control or teleoperation, semi-autonomous operations, or other man-in-the-loop types of operations. The operator input is expected at certain states during normal operations. During error conditions, the operator d

46、etermines 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 co

47、ntrol 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 - C

48、oexists 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,

49、 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. 2.3.33 HUMAN ROBOT INTERFACE Physi