SAE AS 6062-2010 JAUS Mission Spooling Service Set《JAUS目标多任务缓冲处理服务集》.pdf

《SAE AS 6062-2010 JAUS Mission Spooling Service Set《JAUS目标多任务缓冲处理服务集》.pdf》由会员分享，可在线阅读，更多相关《SAE AS 6062-2010 JAUS Mission Spooling Service Set《JAUS目标多任务缓冲处理服务集》.pdf（71页珍藏版）》请在麦多课文档分享上搜索。

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 2015 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/AS6062 AEROSPACE STANDARD AS6062 Issued 2010-07 Reaffirmed 2015-04 JAUS Mission S

5、pooling Service Set RATIONALE AS6062 has been reaffirmed to comply with the SAE five-year review policy. INTRODUCTION The primary goal of the JAUS Mission Spooling Service Set is logical interoperability between communicating elements in an unmanned system. To this end, each service defines the mess

6、ages (vocabulary) and protocol (rules) for data exchange. This logical interoperability is independent of the physical transport, and it is expected that a Transport Standard, such as the JAUS Transport Specification AS5669A, is used in conjunction with this specification. Each service in the JAUS M

7、ission Spooling Service Set can be described using the JAUS Service Interface Definition Language JSIDL. JSIDL creates a formal schema based on Relax NG Compact rng that allows for validation of each service definition described herein. Although knowledge of JSIDL is not required to understand or im

8、plement this Specification, it is highly recommended for supporting context. For convenience, the JAUS Mission Spooling Service Set contains both a text based and XML based representation for each service. The AS6062 Standard does not replace the latest JAUS Reference Architecture Version 3.3 RA33P1

9、, RA33P2, RA33P3, but is a direct evolution of that work. This Standard has been carefully designed to allow for the simplest possible migration of RA 3.3 implementations to a services-based framework. Even though the notion of services has come to define formal interfaces between components, the me

10、ssage sets in those services trace back to similar messages in the Reference Architecture. This document uses a number of conventions to simplify the text. All names are given in Camel Case. Names start with upper case, while reference names start with a lower case. TABLE OF CONTENTS 1. SCOPE 4 1.1

11、Purpose . 4 1.2 JAUS Core Service Set . 4 1.3 Compliance . 4 1.4 Document Organization 4 2. REFERENCES 4 2.1 Applicable Documents 4 2.1.1 SAE Publications . 5 2.1.2 JAUS Technical References . 5 2.2 List of Acronyms 5 3. COMMON CONVENTIONS 6 3.1 Defining a Mission . 6 3.2 Synchronous and Asynchronou

12、s Execution . 7 4. SERVICE DEFINITIONS 8 4.1 Mission Spooler Service . 8 4.2 CommandClass. 17 4.2.1 ID 0E00h: SpoolMission 17 4.2.2 ID 0E01h: RunMission 19 4.2.3 ID 0E02h: AbortMission 19 4.2.4 ID 0E03h: PauseMission . 20 4.2.5 ID 0E04h: ResumeMission . 20 4.2.6 ID 0E05h: RemoveMessages . 21 4.2.7 I

13、D 0E06h: InsertMessages 22 4.2.8 ID 0E07h: RemoveMissionTask 23 4.2.9 ID 0E08h: InsertMissionTask 24 4.3 QueryClass . 26 4.3.1 ID 2E00h: QuerySpoolingPreferences 26 4.3.2 ID 2E01h: QueryMissionStatus . 26 4.3.3 ID 2E02h: QueryStoredMissions. 26 4.3.4 ID 2E03h: QueryMissionPlan 27 4.4 InformClass . 2

14、7 4.4.1 ID 4E00h: ReportSpoolingPreferences . 27 4.4.2 ID 4E01h: ReportMissionStatus 28 4.4.3 ID 4E02h: ReportStoredMissions . 28 4.4.4 ID 4E03h: ReportMissionPlan . 29 5. NOTES 30 APPENDIX A XML FOR SERVICE DEFINITIONS . 31 APPENDIX B XML FOR DECLARED TYPE SETS . 61 SAE INTERNATIONAL AS6062 2 OF 71

15、TABLE OF FIGURES FIGURE 1 NOTIONAL MISSION SPOOLER CONFIGURATION . 6 FIGURE 2 EXAMPLE MISSION STRUCTURE 6 FIGURE 3 EXAMPLE SYNCHRONOUS MISSION PLAN . 7 FIGURE 4 EXAMPLE ASYNCHRONOUS MISSION PLAN 7 FIGURE 5 MISSION SPOOLER SERVICE 8 FIGURE 6 MISSION SPOOLER SERVICE PROTOCOL BEHAVIOR FOR A SINGLE MISS

16、ION 11 TABLE OF TABLES TABLE 1 MISSION SPOOLER SERVICE VOCABULARY 9 TABLE 2 MISSION SPOOLER SERVICE INTERNAL EVENTS SET . 10 TABLE 3 COMMAND LIST SERVICE TRANSITION TABLE 12 TABLE 4 MISSION SPOOLER ENTRY/EXIT ACTIONS TABLE . 14 TABLE 5 MISSION SPOOLER SERVICE CONDITIONS TABLE . 15 TABLE 6 MISSION SP

17、OOLER SERVICE TRANSITION ACTIONS 16 TABLE 7 SPOOL MISSION MESSAGE ENCODING 18 TABLE 8 RUN MISSION MESSAGE ENCODING . 19 TABLE 9 ABORT MISSION MESSAGE ENCODING 19 TABLE 10 PAUSE MISSION MESSAGE ENCODING 20 TABLE 11 RESUME MISSION MESSAGE ENCODING . 20 TABLE 12 REMOVE MESSAGES MESSAGE ENCODING 21 TABL

18、E 13 INSERT MESSAGES MESSAGE ENCODING 22 TABLE 14 REMOVE MISSION TASK EXAMPLES . 23 TABLE 15 REMOVE MISSION TASK MESSAGE ENCODING 23 TABLE 16 INSERT MISSION TASK EXAMPLES 24 TABLE 17 INSERT MISSION TASK MESSAGE ENCODING . 25 TABLE 18 QUERY SPOOLING PREFERENCES MESSAGE ENCODING 26 TABLE 19 QUERY MISS

19、ION STATUS MESSAGE ENCODING 26 TABLE 20 QUERY STORED MISSIONS MESSAGE ENCODING . 26 TABLE 21 QUERY MISSION PLAN MESSAGE ENCODING . 27 TABLE 22 REPORT SPOOLING PREFERENCES MESSAGE ENCODING 27 TABLE 23 REPORT MISSION STATUS MESSAGE ENCODING 28 TABLE 24 REPORT STORED MISSIONS MESSAGE ENCODING . 28 TABL

20、E 25 REPORT MISSION PLAN MESSAGE ENCODING . 29 SAE INTERNATIONAL AS6062 3 OF 711. SCOPE This document defines a set of standard application layer interfaces called JAUS Mission Spooling Services. JAUS Services provide the means for software entities in an unmanned system or system of unmanned system

21、s to communicate and coordinate their activities. The Mission Spooling Services represent the platform-independent capabilities commonly found across all domains and types of unmanned systems. At present, 1 service is defined in this document (more services are planned for future versions of this do

22、cument): Mission Spooler: Stores mission plans, coordinates mission plans, and parcels out elements of the mission plan for execution The Mission Spooler service is described by a JAUS Service Definition (JSD) which specifies the message set and protocol required for compliance. The JSD is fully com

23、pliant with the JAUS Service Interface Definition Language JSIDL. 1.1 Purpose The purpose of this document is to facilitate interoperation of unmanned vehicle systems, subsystems, and payloads by standardization of the message set and associated protocol with regard to the planning and execution of

24、missions, tasks and activities. 1.2 JAUS Core Service Set The JAUS Service Definitions defined herein make use of the inheritance functionality provided by JSIDL to incorporate capabilities as specified by the JAUS Core Service Set (AS5710). These documents must be used together to define a complete

25、 service. It is important to note that details related to Message Serialization and Understanding Protocol Descriptions can be found in the JAUS Core Service Set document, and are not repeated here. 1.3 Compliance The JAUS Mission Spooling Service Set must support compliance assessment. To do so, th

26、is specification must be sufficiently precise to enable the “compliant”/”not compliant” distinction to be made independently of the underlying transport mechanism. It is important to note that implementations are considered compliant to individual Service Definitions within this Specification; it is

27、 not necessary that a single entity realize each Service to be considered compliant. 1.4 Document Organization The layout of this document is as follows. Section 2 lists external references and acronyms used throughout the specification. Section 3 describes common conventions used in the service des

28、cription. Section 4 specifies the JAUS Service Definition for each of the Mission Spooling service, with particular emphasis on the description, assumptions, message set, and protocol behavior. Section 5 describes the message encoding for each message set. Finally, Appendices A and B contain the com

29、plete JSIDL representation for each service and their associated message set. 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 sh

30、all be the issue in effect on the date of the purchase order. In 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

31、has been obtained. SAE INTERNATIONAL AS6062 4 OF 712.1.1 SAE Publications Available from SAE International, 400 Commonwealth Drive, Warrendale, PA 15096-0001, Tel: 877-606-7323 (inside USA and Canada) or 724-776-4970 (outside USA), Web address: www.sae.org AIR5665 Architecture Framework for Unmanned

32、 Systems AS5669 JAUS Transport Specification AS5684 JAUS Service Interface Definition Language AS5710 JAUS Core Service Set AS6009 JAUS Mobility Service Set 2.1.2 JAUS Technical References RA33P1 JAUS Reference Architecture Specification, Volume II, Part 1, Architecture Framework, Version 3.3, June

33、22, 2007 RA33P2 JAUS Reference Architecture Specification, Volume II, Part 2, Message Definition, Version 3.3, June 22, 2007 RA33P3 JAUS Reference Architecture Specification, Volume II, Part 3, Message Set, Version 3.3, June 22, 2007 2.2 List of Acronyms ANSI American National Standards Institute ID

34、 Identifier API Application Programming Interface ASCII American Standard Code for Information Interchange BLOB Binary Large Object DOM Document Object Model IEEE Institute of Electrical and Electronics Engineers JAUS Joint Architecture for Unmanned Systems JSD JAUS Service Definition JSIDL JAUS Ser

35、vice (Interface) Definition Language NIST National Institute of Standards and Technology RA (JAUS) Reference Architecture SMC State Machine Compiler UML Unified Modeling Language URL Uniform Resource Locator SAE INTERNATIONAL AS6062 5 OF 71Mission Spooler Primitive Manipulator Waypoint Driver URN Un

36、iform Resource Name URI Uniform Resource Identifier UUID Universally Unique Identifier XML Extensible Markup Language 3. COMMON CONVENTIONS 3.1 Defining a Mission The Mission Spooler Service acts as an intermediary between a high-level planner (human or machine) and other SAE JAUS Services. The miss

37、ion spooler may reside on-board the planner, the platform/payload, or a different subsystem altogether. Notional data flow is shown in 0. FIGURE 1 - NOTIONAL MISSION SPOOLER CONFIGURATION The Mission Spooler represents a mission plan as one or more tasks. A task, in turn, is composed of SAE JAUS mes

38、sages. Alternatively, a task may be composed of one or more subtasks for an arbitrarily deep level of nesting. This results in an N-ary tree, which allows for parallel, sequential, iterative, and coordinated missions. The fundamental actions of any mission plan are based in SAE JAUS messages support

39、ed by the underlying services. For example, the Global Path Segment Driver Service specified by the JAUS Mobility Service Set AS6009 defines the Set Global Path Segment message for driving along a specified route. In this section, it is important to note that the mission actions are generalizations

40、of behaviors offered by SAE JAUS services and are not new messages introduced by the Mission Spooler service. For instance, the Set Global Path Segment message of the PathSegmentDriver service has been called Drive Path Segment in subsequent examples. Mission A: Task 1: Drive Path Segment (1) Drive

41、Path Segment (2) Drive Path Segment (3) Drive Path Segment (4) END Task 2: Move Manipulator (1) Move Manipulator (2) END FIGURE 2 - EXAMPLE MISSION STRUCTURE M1 M2 PS1 PS2 PS3 PS4 Mission A Task 2 Task 1 SAE INTERNATIONAL AS6062 6 OF 71In the example mission above Task 1 and Task 2 are performed in

42、parallel such that the unmanned system drives path segments 1 thru 4 while the manipulator performs manipulator actions 1 and 2. 3.2 Synchronous and Asynchronous Execution Synchronous actions are actions that must be performed strictly sequentially. In the mission spooler, strict sequential executio

43、n of actions is enforced by using blocking actions. Actions are made into blocking actions simply by setting a blocking flag for the action. When a blocking action is present in a mission, the action must be executed to successful completion (or unsuccessful termination) before subsequent actions in

44、 the mission can be executed. In contrast, asynchronous actions can be executed in parallel, or independent of other actions. Asynchronous execution is enforced by using non-blocking actions, or by separating actions into groups of missions that can be executed concurrently. The examples below, desc

45、ribe synchronous and asynchronous execution. Assume that an unmanned system needs to traverse through two ordered path segments before it performs its first task with a manipulator. The manipulator task must be performed while the unmanned system is stationary. Once the manipulator task is completed

46、, the unmanned system must traverse a third path segment. Only after completing the third path segment, it must perform a second task with a manipulator, change its camera pose and begin traversal of a fourth path segment. The actions that follow the traversal of the third path segment are not causa

47、lly or temporally related to each other. That is, they may be performed in any order. The mission for such a scenario is shown in Figure 3 below. The first four actions are flagged as blocking actions, implying synchronous execution. The last three actions are not flagged as blocking actions and the

48、refore can be executed in any order (or asynchronously). FIGURE 3 - EXAMPLE SYNCHRONOUS MISSION PLAN Figure 4 illustrates an example of two sets of actions that can be performed concurrently. All the actions in Mission A can be executed in parallel with all the actions in Mission B. In addition to t

49、his, the first two actions of Mission B can also be executed asynchronously since they are non-blocking actions, FIGURE 4 - EXAMPLE ASYNCHRONOUS MISSION PLAN Mission A: Drive Path Segment (1) (blocking) Drive Path Segment (2) (blocking) Drive Path Segment (3) (blocking) Drive Path Segment (4) (blocking) END Mission B: Move Manipulator (1) Change Camera Pose (1) END Drive Path Segment (1) (blocking) Drive Path Segm