OPC Experiment 3.0 Interface Control Document v1.0 3.0 Overview.pdf · 0.1 8/28/05 Initial release...

THE JOINT

ARCHITECTUREFOR

UNMANNED SYSTEMS

OPC 3.0

Interface Control Document

Version 1.0

March 9, 2005

i

Document Change Log

Version Date Description 0.1 8/28/05 Initial release of OPC 2.75 ICD.

Based on OPC 2.5a ICD. Includes transport, world modeling, mission spooling, dynamic registration, and payload.

0.2 10/25/05 Updates to Transport (simplification and removal of all non-OPC related discussions), Dynamic Registration (addition of Core Message service), and World Modeling sub-documents (numerous changes. See WM Change Log in this document for details).

1.0 11/9/05 Update to Transport (clarification of JAUS01.0 as UDP header), World Modeling (addition of Detected Intruder feature class), Events (clarification that entire query message, including header, is used in Event Create). Addition of IP address assignment.

1

THE JOINTARCHITECTURE

FOR UNMANNED SYSTEMS

OPC 3.0

Experiment Overview

Version 1.0

November 9, 2004

2

Executive Summary The OCU & Payloads Committee (OPC) effort will provide Human Factors Engineering, Software Architecture Guidance, and evaluation of new message sets and underlying protocols to the JAUS/Common Architecture Community. This effort is being undertaken in compliance with direction received from the OSD JRP sponsor. The focus of the OPC is to expedite the production of cost effective interoperable robotic systems, payloads and user control interfaces. One approach being taken by the OPC is to perform a series of experiments to expedite the development of the recommendation to the JAUS WG and also to collect information on performance and effectiveness of current and recommended approaches. The first experiment occurred in December 2003 at SPAWAR Systems Center, San Diego, CA. The primary thrust of this experiment was to collect information on JAUS Level 1 compliance (Subsystem to Subsystem). The experiment was successful in establishing JAUS viability for the command and control of vehicles using the JAUS message set. The second experiment was conducted in August 2004 at Virginia International Raceway (VIR) and focused on payload interoperability. This experiment demonstrated payload interoperability among multiple participants, verifying JAUS Level 1 compliance for payload use, and JAUS Level 2 compliance (Node to Node) for a subset of payloads and participants. This experiment was successful in demonstrating the potential for payload interoperability via the JAUS message set. However, a number of lesson were learned which resulted in the core payload message set not being presented to the whole working group for adoption into the Reference Architecture. We hope to address some of these shortcomings in the OPC 3.0 series of experiments. The first experiment of this series was held in Chicago during the 2005 Q3 JAUS WG meeting. The OPC met for 4 days prior to the start of the meeting to conduct a simulation experiment to evaluate proposed transport, world modeling, mission planning, and payload message sets. This experiment was successful in demonstrating a coordinated perimeter surveillance scenario with multiple simulated vehicles, and also baseline interoperability for message passing using the proposed IP transport specification. This simulated experiment, “OPC 2.5”, sets the stage for the next experiment in this series, “OPC 2.75”. In OPC 2.75, we will demonstrate the same set of capabilities presented in OPC 2.5, but with live, rather than simulated vehicles. Scope The objective of the third experiment is to show advanced autonomy capability combined with Robot/OCU/Payload interoperability. This includes capabilities such as mission planning and execution, cohesive world model generation, and advanced payload interoperability. In addition, new infrastructure protocols such as the proposed IPv4 and LSS transport layers and dynamic registration will be evaluated. As the scope of this experiment is significantly larger than has been attempted in past experiments, the OPC committee has decided to mitigate risk by conducting a series of

3

experiments, starting with simulation and culminating in a capability demonstration to which outside observers will be invited. A rough schedule and scope of the chain of experiments is: OPC Date Scope 2.5a July ‘05 Simulated autonomy, including world modeling, mission

planning . 2.5b July ‘05 Simulated protocols, including IPv4 and LSS transport,

dynamic registration 2.75 Nov. ‘05 Live rehearsal for 3.0, including technologies of 2.5a and

2.5b (if successful) 3.0 Mar/Apr ‘06 Demonstration of successful capabilities shown in 2.75 This document deals with technologies to be demonstrated in OPC 2.75. Participants will provide a Man-Machine Interface (OCU), and/or a vehicle platform with a majority of the following capabilities: • Components which provide the following services: Primitive Driver, Global Pose

Sensor, Velocity State Sensor, Waypoint Driver. • A movable or fixed payload which is controlled via the Payload Interface message set • Environment data generation capability using World Model messages. If

environmental data generation capabilities are not available on a particular vehicle, simulated environmental data based on current vehicle location is acceptable.

• Ability to accept and/or generate Mission Spooler messages In addition, it is desirable to have at least one or more of following services: • Mission planning for automatic spooler message generation • World model knowledge store capability • World model viewing and display capability. All participants will comply with the detailed interface requirements as provided herein and in the JAUS Reference Architecture version 3.2. Results and Documentation As the primary impetus of this experiment is the development of standards to facilitate higher levels of autonomy and interoperability, the results shall include recommended modifications to the JAUS Document set. In addition, the planning and integration conducted in the process of preparing for the experiment shall be used to further report missing interoperability information. Each participating activity is requested to provide the following information:

• Vehicle Capabilities and Payload ICD • Entity Name (Government or Corporate Identifier) • Primary Contact and Contact Information • Detailed summary of Integration Period • Comments, Notes, Recommendations

4

Schedule The current schedule for planning, experimentation and reporting is: Oct 1: Vehicle and Payload Capabilities Due Nov 14-18 Experiment 2.75 (CONFIRMED DATE)

5

Technical Approach Introduction In this section, we present an overview of the technical approach used for OPC 2.75. Additional appendices are provided to expand upon the concepts presented here. Interface Requirements The basic interface requirement is JAUS Compliance. Compliance will be defined in accordance with the following Transport Layer protocols and user defined messages for the JAUS Reference Architecture. Network Based The communications infrastructure for the demonstration will be Ethernet (802.3) based over a wireless interface

JAUS communication will be accomplished using UDP (User Datagram Protocol) over Ethernet conforming to the Transport Specification presented in Section [REF]. IP Address Assignment The Multicast IP Address used for sending and receiving Dynamic Configuration heartbeats shall be 224.1.0.1. Use of the Multicast IP address is mandatory for all unsolicited Report Heartbeat Pulse messages. All Nodes and Subsystems shall broadcast a Report Heartbeat Pulse message at the rate of 1 Hz. Any other use of the Multicast IP address is discouraged. IP Addresses for subsystem level interfaces shall be: 192.168.128.XX, where the value of the last octet of the IP address is the Subsystem ID for Unmanned Systems and OCUs. OCUs shall have an even numbered ID and Unmanned Systems shall have an odd numbered ID.

Vehicle 1 Vehicle 2 Vehicle 3

6

IP Addresses for Nodes / Payloads shall be 192.168.192.YY, where YY is assigned such that 001-127 are reserved for native OCU/Vehicle nodes, and 128-254 will be assigned to the various payloads. Internet Protocol (IP) addresses for each participant are listed below: VT (Providing Wireless AP) Unmanned Systems / OCUs: 192.168.128.001 …. 192.168.128.009 Native Nodes: 192.168.192.001 …. 192.168.192.127 Payloads: 192.168.192.128 …. 192.168.192.135 AFRL Unmanned Systems / OCUs: 192.168.128.010 …. 192.168.128.019 Native Nodes: 192.168.192.001 …. 192.168.192.127 Payloads: 192.168.192.136 …. 192.168.192.140 AMRDEC Unmanned Systems / OCUs: 192.168.128.020 …. 192.168.128.029 Native Nodes: 192.168.192.001 …. 192.168.192.127 Payloads: 192.168.192.141 …. 192.168.192.145 API Unmanned Systems / OCUs: 192.168.128.030 …. 192.168.128.039 Native Nodes: 192.168.192.001 …. 192.168.192.127 Payloads: 192.168.192.146 …. 192.168.192.154 ASI Unmanned Systems / OCUs: 192.168.128.040 …. 192.168.128.049 Native Nodes: 192.168.192.001 …. 192.168.192.127 Payloads: 192.168.192.155 …. 192.168.192.160 Harris Unmanned Systems / OCUs: 192.168.128.050 …. 192.168.128.059 Native Nodes: 192.168.192.001 …. 192.168.192.127 Payloads: 192.168.192.161 …. 192.168.192.165 iRobot Unmanned Systems / OCUs: 192.168.128.060 …. 192.168.128.069 Native Nodes: 192.168.192.001 …. 192.168.192.127 Payloads: 192.168.192.166 …. 192.168.192.170 iRobot Unmanned Systems / OCUs: 192.168.128.070 …. 192.168.128.079 Native Nodes: 192.168.192.001 …. 192.168.192.127 Payloads: 192.168.192.171 …. 192.168.192.175

7

JADI Unmanned Systems / OCUs: 192.168.128.080 …. 192.168.128.089 Native Nodes: 192.168.192.001 …. 192.168.192.127 Payloads: 192.168.192.176 …. 192.168.192.180 NSWC-PC Unmanned Systems / OCUs: 192.168.128.090 …. 192.168.128.099 Native Nodes: 192.168.192.001 …. 192.168.192.127 Payloads: 192.168.192.181 …. 192.168.192.185 PEO-Soldier Unmanned Systems / OCUs: 192.168.128.100 …. 192.168.128.109 Native Nodes: 192.168.192.001 …. 192.168.192.127 Payloads: 192.168.192.186 …. 192.168.192.190 SPAWAR Unmanned Systems / OCUs: 192.168.128.110 …. 192.168.128.119 Native Nodes: 192.168.192.001 …. 192.168.192.127 Payloads: 192.168.192.191 …. 192.168.192.195 UF Unmanned Systems / OCUs: 192.168.128.120 …. 192.168.128.129 Native Nodes: 192.168.192.001 …. 192.168.192.127 Payloads: 192.168.192.196 …. 192.168.192.199 Network Infrastructure The host site will provide the Network Infrastructure. This network will consist of a hub with sufficient ports to enable access for all participant OCU computers, and wireless access points for vehicle use. It is up to the individual participants to provide their own wireless clients for on-vehicle use. OCU/System Commanders OCU/System Commanders shall have a pre-established authority/rank of 127. Component Control and Authority Prior to issuing and/or responding to a command, the appropriate JAUS control protocol must be performed. Request, Release, Confirm, and Reject Component Control messages shall be used. Additionally, the JAUS Authority protocols, Set, Query, and Report Component Authority shall be used.

8

Service Connections Service Connections shall be supported for the experiment, as described in The Service Connections and Event section. Note: For OPC 2.75, Service Connection messages shall be based on the message set in the current Reference Architecture. Dynamic Registration Dynamic Registration of Subsystems and Components will be required for the demonstration. No a priori knowledge of the other systems other than what is specified herein is required with the dynamic registration. . Dynamic Assignment The pursuit of a mechanism for the automated assignment of identifiers to JAUS entities is not a goal of the OPC for Experiment 2.75. JAUS IDs will be statically assigned and will take the form of <subsystem>.<node>.<component>.<instance> Capabilities Publication Component capabilities publication shall be addressed as described in the Dynamic Configuration section. Note – the semantic link between Component ID and capability/service has been removed. There is no longer any assumption of capability based on Component ID. The Component ID has been maintained for addressing purposes. The Report Capabilities message provides a method for a component to determine the services provided by another component. Currently, this list of possible services is identical to the previous list of Components. This includes Node level publication of Components and their services present within the Node and the supported Messages and associated Presence Vectors of these Components. Audio and Video All audio and video, if included in simulation scenario, will be in a digital format. The data will be sent over the network using JAUS RA 3.2. All video transmitted during the experiment must be MJPEG for compatibility. Service connections shall be used for video transmission. Multiple streams of the same video may be transmitted. Audio may be transmitted, but no interoperability is expected or required. Those systems using audio shall have the capability to stop audio transmission for network bandwidth control and measurement. Mobility Mobility control of all vehicles will make use Primitive Driver and Waypoint Driver capabilities. Vector Driver capabilities are also allowed for, if required by a particular simulation. For coordinated mission execution, simulations shall support a Waypoint Driver capability. Timing The following frequencies and Speeds shall be used for the OPC Experiment: Heartbeat 1Hz

9

Safety Timeout 5 Seconds on the Heartbeat

Subsystem shall send a Reject Component Control message to any controlling entity and enter a safe (standby) state.

Wrench 4 Hz Min to 15 Hz Max Watchdog All mechanical devices shall have control logic to safely

stop or enter a safe state/mode in the event of a loss of command and/or communications.

Emergency Conditions A Set Emergency Message received by any component shall be handled in a manner as to effectively place the receiving component and all subordinates in a safe state. The subordinate hierarchy shall be implemented such that:

• Any Subsystem Commander receiving an Emergency Message shall in turn forward that message to all Node Managers within the same Subsystem.

• Any Node Manager receiving an Emergency Message shall in turn forward that

message to all Components within the same Node.

• Any Component receiving an Emergency Message shall in turn forward that message to all Components currently under control of the receiving Component.

Human Machine Interface The HMI shall operate such that vehicle systems in the network are identifiable as independent JAUS Subsystems. The implications of this requirement are:

• Each Vehicle Subsystem will be selectable through any OCU.

• If a Vehicle component is currently under control of another OCU, the vehicle will respond to the request for control with a negative response.

• Vehicle Subsystems shall respond to query messages from any OCU.

• Vehicle Subsystems shall provide service connections for Position

information to any requesting Subsystem (OCU and/or Vehicle) if position information is available on and for that vehicle.

• Vehicle Subsystems shall accept mission spooler commands only from OCUs

which they are under the control of.

10

• Vehicle Subsystems shall provide World Model data to any OCU / viewer which requests it.

States and Modes The JAUS Component States and respective transitions will be used for component control. The following additional rules apply for all states with the exception of the Ready State:

• For UGVs, no motion of any kind shall occur. This includes wheels, tracks,,

masts, and pan/tilt units. • Fixed wing UAVs shall go into a stationkeeping mode. Rotorcraft shall go -

into hover mode. • USVs shall go into a station-keeping mode. • Active sensors shall not be used outside of the Ready State

Payload Interface Specification For OPC 2.75, the enhanced payload specification will be used. This specification is based on the message set used in OPC 2.0, rather than a complete re-working of the payload messages. Each participating organization shall provide a payload which complies to this specification. For the experiment, the necessary interoperability shall be the logical control of a payload from an operator interface.

11

Simulation Requirements

In this section, we discuss the overall scenario and the simulation capabilities required to execute it. Scenario Description The scenario for OPC 2.75 will be a perimeter surveillance exercise. Two vehicles with detection sensors will be used to patrol a defined perimeter. Each surveillance vehicle will have a detection payload, capable of identifying an intruder. This detection payload can be based on actual real time sensor information, or location-based. When an intruder is detected, a third vehicle is called to the intruder’s location. This third vehicle has a simulated payload weapon, such as a pan-tilt unit, which can be brought to bear on the intruder. The third vehicle uses world model information to collect the actual path points of the closest vehicle to the intruder, and follows that path exactly. The surveillance and response vehicles can be some combination of UGVs, USVs, and UAVs, depending upon the area to be monitored.

Intruder detected by vehicle 1

Location of vehicle 2 when vehicle 1 detects intruder

Response vehicle called to intruder location

Vehicle staging area

12

Scenario Architecture The diagram below shows major component architecture for this scenario

From this, we see the following:

1) There is a centralized mission spooler/planner which is responsible for task allocation via mission spooler messages. This can take the form of an explicit mission planner, or it can be a pre-recorded sequence of spooler messages which are fed to the vehicles

Mission Spooler World Model Knowledge Store

Waypoint Driver

Primitive Driver

Detection Payload

Waypoint Driver

Primitive Driver

Detection Payload

Waypoint Driver

Primitive Driver

Response Payload

Intruder Response Vehicle

Intruder Surveillance Vehicle #1

Intruder Surveillance Vehicle #2

13

2) Spooler messages, which for this scenario, will consist of waypoint and payload messages, will be directed to the appropriate component. This means that waypoint drivers should expect to support mission spooler messages for receiving multiple waypoints.

3) The world model knowledge store is the central repository of world information. This will consist of a terrain map (provided a-priori) along with information from the detection payloads, and information on vehicle track from each vehicle’s global pose sensor

4) The detection and response payloads provide the vehicles with access to the central world model knowledge store. The detection payloads will be responsible for adding the location of detected intruders into the knowledge store. They will also be responsible for adding their vehicle’s “bread crumbs” to the knowledge store. The response payload will receive the location of the detected intruder(s) from the knowledge store. The response vehicle will then follow the path of the vehicle that detected the intruder. This is the “bread crumb” information placed in the knowledge store by the detection payloads

5) A world model feature class dictionary is needed. This is given below. 6) Waypoint driver protocols need to be defined. This is given below. 7) To avoid time-synchronization issues, location based events will be used internal

to simulator operation. This means each simulated vehicle will be provided with the intruder location, along with a detection distance radius. When the vehicle is within the detection distance of the intruder, the detection payload should “detect” the intruder. This information is monitored by the system mission spooler to guide the response vehicle.

World Model Feature Class Dictionary The world model messages depend on a-priori agreed upon feature class definitions. The table below shows the feature class dictionary which will be used for OPC 2.5a. STATIC OBSTACLE Feature Classs (ID 0xF000)

Attribute Data Type: BYTE Attribute Value: 0 (Static)

VEHICLE TRACK Feature Class (ID 0xF001)

Attribute Data Type: BYTE Attribute Value: Equal to Vehicle Subsystem ID

INTRUDER Feature Class (ID 0xF002)

Attribute Data Type: UNSIGNED INTEGER Attribute Value: Detection Time

DETECTED INTRUDER Feature Class (ID 0xF003) Attribute Data Type: BYTE Attribute Value: 0 (Free Space), 255 (Obstacle). 1-254 (Reserved)

14

The STATIC OBSTACLE feature class is used to designate areas that are not driveable by the unmanned ground vehicle(s). For this experiment, the feature class attribute field will not be used, however this field must be included per the JAUS WM specification. Therefore the attribute data type shall be set to BYTE and the attribute value shall be set to zero. The VEHICLE TRACK feature class is used for the “bread crumbs” tracks for each unmanned system. All vehicle tracks will use the same feature class inside the world model store. The tracks for each subsystem will be differentiated by the attribute value. For this experiment, the vehicle track feature class attribute value shall be equal to the subsystem ID of the vehicle whose tracks are stored. This attribute data type for this value shall be an unsigned BYTE. The INTRUDER feature class is used to classify intruders. When an unmanned system detects an intruder, it will add the intruder to the world model store. Other unmanned systems will received this information from the world model through either a query or event notification. The attribute value for this feature class shall be equal to the time that the intruder was detected at the given location. The format for this time stamp shall be the same as the time stamp used in the JAUS Report Global Pose message. This format is shown below. The attribute data type shall be an UNSIGNED INTEGER.

Time Stamp Unsigned Integer

Bits 0-9: milliseconds, range 0...999 Bits 10-15: Seconds, range 0...59 Bits 16 – 21: Minutes, range 0...59 Bits 22-26: Hour (24 hour clock),

range 0..23 Bits 27-31: Day, range 1...31

The DETECTED INTRUDER feature class is used to mark objects/intruders which are detected and validated. 0 indicates free space, and 255 indicates obstacle/intruder. Waypoint Driver Protocols The waypoint driver will be a key component of this simulation exercise, so it is important to have a consistent protocol implementation between organizations, so that mission planners / OCUs from one organization can command a waypoint driver on another organization. Therefore, we present the following set of guidelines regarding basic waypoint driver capabilities:

1) When in Standby mode, the WD shall not move the vehicle or try to achieve waypoints

2) When in Ready state, the WD shall navigate the vehicle to the next waypoint

15

3) The WD shall be capable of accepting a series of waypoints while in Standby or Ready (using the SetWaypoint command with incrementing Waypoint Number field or the SpoolMission command).

4) The WD shall receive at least one SetTravelSpeed command prior to beginning motion. The order of this command with respect to SetWaypoint messages is not specified.

5) The WD shall also be capable of operating in a mode where it is fed one waypoint at a time, with waypoint i+1 arriving as the vehicle nears or achieves waypoint i.

Simulator Roles Here, we present a list of “roles” that can be assumed. A “role” is defined as a simulated vehicle or OCU. For each role, we present a minimum set of required JAUS capabilities/components, along with message support. It is not expected, or required, that each organization implement all the roles listed below. It is perfectly acceptable for an organization to only implement one of the roles below, such as Intruder Surveillance Vehicle. Intruder Surveillance Vehicle An Intruder Surveillance Vehicle (ISV) should support the components listed below. Message support is assumed to include the following:

1) Core messages 2) Service Connection messages as defined in Section [RF] 3) Component-specific messages as defined in RA 3.2 4) Capabilities messages as defined in Section [REF]. 5) Individual World Model and Mission Spooling message as listed below and

defined in Section [REF]. Note, additional components are allowed, but not required. For example, a particular implementation may make use of a Vector Driver, which receives commands from a Waypoint Driver. This configuration does not change affect OCU<->Vehicle interaction. Primitive Driver No OPC 2.5a-specific support required Waypoint Driver

1) Should follow guidelines given in “Waypoint Driver Protocols” section 2) Should accept Mission Spooler messages which contain “Set Waypoint”

commands. This includes: • Code D010h: Spool Mission*

• Code D210h: Query Spooling Preference*

• Code D410h: Report Spooling Preference**

• Code D211h: Query Mission Status – will be received in the form of a Create Event Connection *

16

• Code D411h: Report Mission Status – will be sent in the form of as an Event Connection**

* Optional messages – if not supported, WD will receive 1 Set Waypoint command at a time

Global Pose Sensor

1) OPC 2.5a-specific capabilities for the Global Pose Sensor involve implementing World Model messages, to allow actual vehicle trajectory to be inserted into World Model Knowledge Store in a form which can be used by the Intruder Response Vehicle. This includes: • Code F220h: Query Vector Knowledge Store Objects • Code F221h: Query Vector Knowledge Store Feature Class Metadata • Code F222h: Query Vector Knowledge Store Bounds • Code F421h: Report Vector Knowledge Store Feature Class Metadata • Code F422h: Report Vector Knowledge Store Objects • Code F423h: Report Vector Knowledge Store Bounds

Velocity State Sensor No OPC 2.5a-specific additions are required for the Velocity State Sensor Intruder Detection Sensor The Intruder Detection Sensor (IDS) is a non-payload component which is responsible for detecting intruders. For simulation purposes, you will be provided with the GPS coordinates of the intruder. The IDS will provide information to the World Model Knowledge store in the form of a feature class ID which represents an intruder. Aside from the core messages, the IDS needs to support the following World Model messages:

• Code F220h: Query Vector Knowledge Store Objects • Code F221h: Query Vector Knowledge Store Feature Class Metadata • Code F222h: Query Vector Knowledge Store Bounds • Code F421h: Report Vector Knowledge Store Feature Class Metadata • Code F422h: Report Vector Knowledge Store Objects • Code F423h: Report Vector Knowledge Store Bounds

In addition, for simulation purposes, it must be capable of querying the Global Pose Sensor so that it can provide an intruder alert at the proper location. In addition, the IDS should support activation/deactivation. They payload will be activated by sending a “RESUME” message. It will be deactivated by sending a “STANDBY” message.

17

Intruder Response Vehicle An Intruder Response Vehicle (IRV) should support the components listed below. Message support is assumed to include the following:

1) Core messages 2) Service Connection messages as defined in Section [REF] 3) Component-specific messages as defined in RA 3.2 4) Capabilities messages as defined in Section [REF]. 5) Individual World Model and Mission Spooling message as listed below.

Note, additional components are allowed, but not required. For example, a particular implementation may make use of a Vector Driver, which receives commands from a Waypoint Driver. This configuration does not change affect OCU<->Vehicle interaction. Primitive Driver Same as ISV Waypoint Driver Same as ISV Global Pose Sensor Same as ISV Velocity State Sensor Same as ISV Intruder Response Payload The Intruder Response Payload (IRP) is a simulated weapons payload with a bore-sighted camera and weapon. For simulation purposes, you will be provided with the GPS coordinates of the intruder, along with example images of non-intruder and intruder views. The IRP will be used to exercise the new features of the Payload Message set. This includes additional support for images and image point selection, and HMI groupings. The IRP should provide, at a minimum, the following inputs and outputs: Inputs: Pan-Left Pan-Right Pan-Up Pan-Down Fire Image selection for panning control: This is used as an alternative to manual pan

buttons. When an image point is selected, the weapon shall virtually pan to that location. We do not expect an updated image based on this, since this is all done in simulation. However, the current weapon location (azimuth, elevation) should change.

Outputs: Camera image

18

Current weapon location, in terms of azimuth and elevation Ammo remaining: This should decrement each time “Fire” is pressed. The simulated IRP should be capable of querying the Global Pose Sensor, so that it displays the proper image given the a-prior assigned intruder location and current vehicle location. Operator Control Unit Aside from “normal” duties, the Operator Control Unit (OCU) will need to interact with the Mission Planner and World Model Knowledge Store. These interactions are defined here. Ideally, the OCU would be capable of generating a high level task description which is then sent to the Mission Spooler for execution. Since this capability is not yet present, or proposed, in JAUS, we will assume that the Mission Spooler component is hardcoded with the demo scenario (see below). Therefore, the only interaction with the Mission Spooler will be to send a Spool Mission message to activate the mission The OCU’s interaction with the World Model Knowledge Store will mainly involve querying the store for data, and displaying that data. World Model Knowledge Store The World Model Knowledge Store will be implemented as described in Section [REF]. Mission Planning This experiment will focus on mission coordination and execution through the use of the Mission Spooler (MS). Future experiments will include higher level Mission Planning components, and for this reason, the basic “mission plan” for the experiment will be scripted or canned. The Mission Spooler will begin by sending Spool Mission messages to the two Intruder Surveillance Vehicles. A higher level component (i.e. OCU or planner) will send a Vector Knowledge Store Event Notification Request to the World Model Knowledge Store, with parameters to request a notification if an Intruder feature ID is added to the Knowledge Store. Upon receipt of the Vector Knowledge Store Event Notification indicating an intruder has been detected, the higher level component will query the World Model Knowledge store for the path of the vehicle which detected the intruder. It will then send that path, via a Spool Mission message, to the Mission Spooler which will then spool the new mission to the Intruder Response Vehicle. The Intruder Response Vehicle then navigates to the intruder where the Intruder Response Payload is activated. The following message sequence example for mission coordination and execution shall be followed:

19

The following guidelines also apply to the message sequence diagram above:

1. If a component does not respond to the Query Spooling Preferences message, the Mission Spooler will default to sending that component one (1) message at a time (payload component in the example above does not respond to this message).

2. If a component does not support the Spool Mission message, the Mission Spooler will send the raw JAUS message to that component.

3. All components in the mission must support an Event Connection on Query Mission Status of type Message. The Report Mission Status with the Message Finished flag set tells the Mission Spooler to spool out another portion of the mission.

20

Detailed Message Requirements The JAUS Reference Architecture message set to be used in this experiment is summarized in the following tables. Further clarification of the following messages, specifically in relation to service connections includes:

Negative response to Service Connection Create will be considered appropriate for messages not providing changing data. The intent of the JAUS Service Connection is to enable periodic updates of status information without the requester polling the provider. Examples of this include position, vehicle status and sensor output.

In addition to the JAUS Reference Architecture version 3.2 message set identified, this experiment will include a number of experimental approaches as defined in Section [REF]s. The tables are not meant to specify the sequence of messages through the execution of the Subsystem, Node or Component. The left-most column indicates the stimulus or event for the subsequent response messages and actions. Events are system states, modes, conditions, and received messages. Non-message events are presented in boldface. Table entries highlighted in yellow indicate experimental messages.

21

Core Messages Messaging Requirements (All Components)

Event or Prompting Message Response Message Dest. Addr. Action (Side Effect) Set Component Authority Set command authority for the component. Query Component Authority Report Component Authority Source of Event Return current command authority. Shutdown Place into Shutdown state. Cease processing. Standby Place into Standby state. Resume Place into Ready state and initiate processing. Reset Reinitialize. Set Emergency Place into Emergency state. Clear Emergency Place into Standby state. Create Service Connection Confirm Service Connection Confirm Service Connection Activate Service Connection Suspend Service Connection Terminate Service Connection Request Component Control Confirm Component Control Release Component Control Reject Component Control Query Component Status Report Component Status Source of Event Return current state. Payload Component Messaging Requirements

Event or Prompting Message Response Message Dest. Addr. Action (Side Effect) Query Payload Interface Report Payload Interface Source of Event Query Payload Data Element Report Payload Data Element Source of Event Set Payload Data Element Perform action indicated in Prompt Payload Data Element Event Setup Register the Source for the Event Notification Event Trigger Payload Data Element Event Notification Registered Dest.

Visual Sensor Messaging Requirements

22

Event or Prompting Message Response Message Dest. Addr. Action (Side Effect) Query Camera Count Report Camera Count Return number of cameras. Select Camera Switch to the camera selected. See description

in appendix B. This is an Experimental Message.

Query Video Frame Report Video Frame Report video frame provides one video image. This is an Experimental Message.

Set Camera Pose Set pose. Query Camera Pose Report Camera Pose Return pose. Waypoint Driver Messaging Requirements

Event or Prompting Message Response Message Dest. Addr. Action (Side Effect) Resume N/A Vehicle begins waypoint driving Standby N/A Vehicles pauses waypoint driving Send Global Waypoint N/A Waypoint added Query Global Waypoint Report Global Waypoint Source of msg Spool Mission N/A Waypoint(s) added Query Spooling Preferences Report Spooling Preferences Source of msg Query Mission Status Report Mission Status Source of msg Used to indicate if waypoint achieved World Model Messaging Requirements

Event or Prompting Message Response Message Dest. Addr. Action (Side Effect) Create Vector Knowledge Store Objects Report Vector Knowledge Store Object(s)

Creation (if applicable – see message definition)

Source of msg

Query Vector Knowledge Store Objects Report Vector Knowledge Objects Source of msg

Query Vector Knowledge Store Feature Class Metadata

Report Vector Knowledge Store Feature Class Metadata

Source of msg

Query Vector Knowledge Store Bounds Report Vector Knowledge Store Bounds Source of msg

Vector Knowledge Store Event Notification Request

Vector Knowledge Store Event Notification Source of msg

Vector Knowledge Store Bounds Change Event Notification Request

Vector Knowledge Store Bounds Change Event Notification

Soruce of msg

2

Transport Interface



Version 1.4

October 25, 2004

3

JAUS Over IP: Interoperability Experiment 2.75

Interface Control Document (ICD) Kathy Wienhold, Parag Batavia Version 1.4 – October 25, 2005

1. Introduction The purpose of this document is to specify the Transport Layer format and associated protocols required to implement the proposed JAUS-over-IP transport standard for the 2.75 JAUS Interoperability Experiment. This document is divided into five sections: 1. Introduction – This section. 2. Network Environments – Describes the network topologies in which this specification is

intended to function. 3. JAUS-Over-IP: Describes the proposed JAUS-Over-IP standard.

3.1. Packet Format: Format of an individual UDP or TCP message. 3.2. Network Infrastructure: Describes how to set-up the network infrastructure/addressing. 3.3. Broadcast Implementation: Describes how the broadcast semantics on JAUS are

implemented in the transport layer. A. Appendices

A.1. Acronym Reference – Expands the various abbreviations used in this document to their full names.

A.2. Document Reference – Indicates where to find all documents, websites, etc. referred to in this document.

A.3. New Messages – Descriptions of any new messages required to implement the proposed formats/protocols.

A.4. Configuring Routing for iptables – Describes the procedures by which the iptables functionality is typically built and configured in Linux. This is a brief guide/overview for those who are less familiar with IP networking, and is intended to provide some basic advice/insight.

A.5. Example Code for Transport & Network Infrastructure – Describes reference code for an example implementation of the packet formats and network infrastructure required to implement this specification.

Where possible, this document will provide references, examples and pseudo-code in order to be as clear as possible. While the author has attempted to verify each such instance, there may of course be errors. The examples presented here are done using Linux. Users of Windows and other operating systems will have to go through some extra effort here – the author hopes that these examples will at least point the way. 2. Network Environments The proposed JAUS-Over-IP Transport standard is intended to function in the typical network topology depicted in Figure 1.

4

Figure 1: Typical Network Topology for JAUS-Over-IP Transport

Note that when the robot supports a payload network, it operates as a multi-homed host (that is, a computer with two, independent network interfaces). This network layout allows the robot itself to act as a firewall/proxy for the payloads behind it. This is the most typical design used for payload-bearing entities like robots. However, while the design above is the most common, there are two significant minority cases here that must also be accommodated. The first such case is a payload that provides a communications interface on the Subsystem Network. An example is depicted in Figure 2. Notice that in this case, it is “Payload 1” that is the multi-homed host, as it is this processor that has two, independent network interfaces and must act as a firewall/proxy for the rest of the subsystem. The developer of “Payload 1” must fulfill that constraint, in effect making the payload an IP router for the subnets on which it has network interfaces (assuming, of course, that these are IP-based networks to begin with). The second, alternative network environment we must consider is that of

Figure 2: Alternative Network Topology for

5

a robot and its payloads existing on a single network with a single COTS router providing the interface to the radio network. This type of network environment is depicted in Figure 3. Note that if one were to consider the “COTS Router with Radio Interface” to be just another payload, this case has the same topology as in Figure 2. The difference is that with a payload specifically designed to operate in a JAUS environment, the routing parameters required to efficiently implement the JAUS-over-IP standard are more likely to be accessible. With a COTS router, the developer is more likely to have to work with whatever functionality that router provides and adjust the network infrastructure accordingly.

A Final Note: To this point, none of the attributes of the Subsystem Network topology and/or infrastructure have been specified. The

JAUS-Over-IP transport imposes no requirements in this area. It is up to the System Designer to create

this infrastructure and to configure the elements within it correctly for that environment. Designers of robots, OCUs and payloads should keep this flexibility in IP addressing and infrastructure in mind, and provide convenient interfaces for modifying the parameters of the network environment, such as IP addresses and subnets, TTL values, name resolutions for hosts and services, etc. 3. JAUS-Over-IP The proposed standard for JAUS-Over-IP has three components: The first is the format of an individual data packet; the second is the network infrastructure required; the third is the means by which broadcast semantics are implemented on the subsystem and payload networks. Each of these is described in turn in the following subsections. 3.1 JAUS-Over-IP Packet Format The protocol stack for JAUS-Over-IP (UDP version) is identical to the protocol format used in prior OPC experiments. I.e., in a JUDP packet, the 16-byte JAUS application header is maintained, and is preceded by the text string “JAUS01.0”

Figure 3: Alternative Network Environment for JAUS-Over-IP

6

3.2 Network Infrastructure For purposes of the interoperability experiment, the Subsystem Network will be a single, flat IP subnet with static addressing. Subsystem Network Subnet: 192.168.128.0/24. Static addressing will be done at the interoperability experiment itself. The Payload Network will be whatever the host platform wants it to be – it is up to the designer of that platform to specify this network infrastructure – as long as it conforms to one of the three network topologies identified above. Note that OCUs may have “payload” networks as well as robots – for example, a robot’s payload may be paired with a specific controller on the OCU side of the communications link. This experiment allows for this kind of configuration, should it be desired. However, it is expected that payloads will typically be attached to robots, not OCUs. We recommend retaining the 192.168.192.0/24 subnet from the 2nd Interoperability Experiment, but this is not required. 3.3 Port-Based Routing The core transport-level change in OPC 2.75 is the addition of port-based routing to increase system efficiency and reduce message routing latency. To date, all JAUS-Over-IP routing has been done at the application level. An application, typically the Node Manager, is required to examine each packet and determine the IP address to forward the packet to. This was primarily due to the restriction that all JAUS traffic must travel over a single port – 3794. An alternative approach is to take advantage of built in IP routing capabilities present in all modern operating systems. In this approach, Node 1 (the “Primary Node”) continues to communicate over port 3794. Payload Nodes reside on an internal subnet (as has traditionally been the case), and also communicate over port 3794 on the payload network. In the “normal” application-based routing approach, a packet destined for a payload node would be forwarded to the payload node via the Primary Node manager. Therefore, each packet sourced from, or destined to, the payload node, would have to pass through the primary node manager. In the port-based routing approach, a table is created which maps port numbers on the subsystem network to IP address/3794 pairs on the payload network. This table can reside at the application level, or at the Operating System level. When it resides at the application level, there is no gain in routing efficiency, as each packet must still pass through the primary node manager. When OS-level port-forwarding is used, a packet destined to a payload node is not examined by the primary node manager application. Rather, it is forwarded by the operating system directly to the appropriate IP/Port on the payload network. The figure below illustrates the topology of a subsystem and payload network under this concept. For the developer who wishes to use OS-level port-forwarding, appendix A.4 shows how to use the Linux iptables functionality to provide port-forwarding capabilities. An alternative approach is to maintain the table at the application level. This requires the fewest changes to one’s software base, but does not result in any additional efficiency gains.

7

The one issue not addressed in the above scenario is how the port-forwarded payload is ever discovered by the OCU in the first place – i.e. how the discovery protocol boots up the transport infrastructure on the non-3794 ports, given the multicast protocol currently in place for discovery. For the OPC 2.75 experiment, the discovery of non-standard ports will not actually be implemented. Instead, an a priori mapping is specified, based upon Node numbers in the source ID fields of the JAUS messages: Node 1: Addressed at Port Number 3794. Node 2: Addressed at Port Number 10002. Node 3: Addressed at Port Number 10003. Node 4: Addressed at Port Number 10004. ….. Node Y: Addressed at Port Number 10000+Y. A. Appendices A.1: Acronym Reference The terms in this list are used in this document; the definitions are provided here.

1. JAUS: Joint Architecture for Unmanned Systems. 2. COTS: Commercial Off-The-Shelf. 3. OCU: Operator Control Unit. 4. TTL: Time-To-Live.

8

A.2 Document Reference The documents, websites, etc. listed here provide more detailed explanations and authoritative references for the information presented in this document.

1. iptables Tutorial: http://iptables-tutorial.frozentux.net/iptables-tutorial.html. 2. JAUS Working Group: http://www.jauswg.org.

A.3 New JAUS Messages None. A.4 Using iptables in Linux The purpose of this section is to briefly describe the process by which the iptables facility is enabled and configured in Linux. The iptables functionality comes as a standard part of the more recent 2.4 Linux kernels, as well as in the 2.6 kernel line. The instructions in this section are written based on the 2.4.24 Linux kernel, but should be valid for most such cases. Most of the information in this section is gleaned from the “iptables Tutorial”, referenced in Section A.2. A.4.1 Configuring the Linux Kernel The iptables functionality must be built into your Linux kernel in order for it to function. This is done by turning on the following options in the Linux kernel configuration:

• CONFIG_PACKET [required] • CONFIG_NETFILTER [required] • CONFIG_IP_NF_CONNTRACK [required] • CONFIG_IP_NF_IPTABLES [required] • CONFIG_IP_NF_NAT [required] • CONFIG_IP_NF_FILTER [required] • CONFIG_IP_NF_MATCH_STATE [required] • CONFIG_IP_NF_TARGET_MASQUERADE [required] • CONFIG_IP_NF_MATCH_LIMIT [optional – useful against DOS attacks, and so

generally good hygiene to include this] • CONFIG_IP_NF_FTP [optional – useful if you’re going to want to have ftp connections

passed through the NAT service] • CONFIG_IP_NF_TARGET_LOG [optional – useful for debugging]

For more detail on what these options actually do, see the “iptables Tutorial” reference listed in Section A.2 above, in Section 2.2 of the referenced document. If you have a previously built kernel, you can determine if these options were selected by looking at the /usr/src/linux/.config file to see if they have a “y” or “m” value assigned to them. If you’ve never worked with building a Linux kernel, please talk to whoever did the original build of your kernel for help (there’s just too much variability in kernel functionality to lay out all the possible considerations here).

9

A.4.2 Building iptables Once the kernel has been configured, you need to build and/or install the iptables package. This provides the utilities needed to manipulate this functionality. You may be fortunate and have a Linux distribution that provides an already-built iptables package – for instance, the RedHat distributions do so. If you already have the iptables package, then just install it. If you do not already have this source code, it can be downloaded from http://www.netfilter.org. The “iptables Tutorial” has information about patching more exotic options into the kernel – you probably want to ignore this, and just build the tools, by doing make KERNEL_DIR=/usr/src/linux make install KERNEL_DIR=/usr/src/linux The value for the KERNEL_DIR variable should point to wherever the source tree is for your Linux kernel. A.4.3 Booting-Up iptables If you are running an older Linux distribution (say, RedHat 7.1), you will need to turn off the ipchains functionality before turning on iptables. If you are using the standard kind of Sys5 init procedure in your OS, this will probably require executing commands that look something like this: chkconfig --level 0123456 ipchains off service ipchains stop To turn on the iptables functionality: chkconfig --level 235 iptables on service iptables start If you get errors about “device or resource busy” in the init_module call when trying to start the iptables service (or if the service doesn’t start at all), you should unload the ipchains kernel module (assuming that your kernel has it compiled in as a module, as most kernels that have ipchains do): rmmod ipchains ldconfig modprobe ip_tables Then restart the iptables service. You can tell if the service is running by typing service iptables status It should print out “Table” entries for “filter”, “nat”, and “mangle” with 2-3 “Chain” entries under each. Lastly, you must set the flag in the Linux kernel that enables ip-forwarding functionality: echo 1 > /proc/sys/net/ipv4/ip_forward And you can make sure that the flag is set via: cat /proc/sys/net/ipv4/ip_forward This should return a zero if ip-forwarding functionality is off, and a one if ip-forwarding functionality is on. Note that you will have to do this every time you boot-up your system.

10

A.4.4 Configuring Routing for iptables Now that the iptables functionality is up and running, it is time to configure its routing tables to implement the NAT (Network Address Translation) required to support payload networks. For purposes of this explanation we assume that the payload subnet for the interoperability experiment will be 192.168.192.0/24. This is a typical, “Class C” private subnet, and is in keeping with the IP address assignments from the 2nd Interoperability Experiment. In this example, we will assume that the payload has been assigned IP address 192.168.192.101 and that it provides the following services:

• JAUS: Port 3794 • JAUS: Port 12345

To expose these services to the outside world, the following iptables commands would be used: iptables –t nat –A PREROUTING –i eth0 –p tcp --dport 10001 –j DNAT –-to 192.168.192.101:3794 iptables –t nat –A PREROUTING –i eth0 –p udp --dport 10001 –j DNAT –-to 192.168.192.101:3794 iptables –t nat –A PREROUTING –i eth0 –p tcp --dport 10002 –j DNAT –-to 192.168.192.101:12345 iptables –t nat –A PREROUTING –i eth0 –p udp --dport 10002 –j DNAT –-to 192.168.192.101:12345 iptables –t nat –A POSTROUTING –o eth1 –j MASQUERADE iptables –t nat –A POSTROUTING –o eth0 –j MASQUERADE These commands assume that “eth0” is the network interface on the Subsystem Network. The first four of the above commands rewrite incoming TCP & UDP packets on the “eth0” interface for port numbers 10001 and 10002, forwarding them on to IP address 192.168.192.101, ports 3794 and 12345 respectively. The last two of the above commands cause the source address in packets to be rewritten so that:

• The packets headed onto the payload network from the subnet network look like they’re coming from the iptables host platform – in this case, 192.168.192.24.

• The packets headed onto the subnet network from the payload network look like they’re coming from the iptables host platform – in this case 192.168.128.18 (assuming that we’re following the example laid out below).

These commands are needed because they allow the source address in the IP headers to function as the return routing for any reply. Jeff Wit provides an alternative means of exercising port-based routing, without the necessity of rewriting the source address inbound (or the return destination address outbound): iptables –t nat –A PREROUTING –d 192.168.128.10 –p udp –-dport 10001 –j DNAT –-to-destination 192.168.192.254:3794 iptables –t nat –A POSTROUTING –s 192.168.192.254 –p udp -–sport 3794 –j SNAT -–to-source 192.168.128.10:10001

11

The purpose of the first command is to rewrite the destination address on packets coming in from the subsystem interface, forcing them to be routed to the appropriate payload IP address and port number. The purpose of the second command is to rewrite the source address on packets coming in from the payload interface, forcing them to identify their source as the robot’s port-forwarding interface. If you wish to test this basic functionality (of either variety presented above), you may obtain three test platforms and configure their networks as indicated in the figure below, with Test

Platform #2 running

iptables. [Note that you will

probably have to turn off the

ipchains functionality on Test Platforms #1 & #3 as well

in order to get them to accept incoming connections.] Once you have confirmed basic network connectivity among the platforms on each subnet, execute the above commands on Test Platform #2, then compile and execute the following code listed in Appendix A.6.1 on the indicated platforms. A.5 Example Code for Transport & Network Infrastructure Code provided in accompanying archive files. Code is available from the author upon request.

Figure A.1: Example iptables Test Bed



Dynamic Configuration

Control Document

Version 1.2 September 27, 2005

3

INTRODUCTION............................................................................................................. 4

DYNAMIC CONFIGURATION..................................................................................... 4

DISCOVERY......................................................................................................................... 4 CODE D2A4H: QUERY IDENTIFICATION............................................................................... 6 CODE D4A5H: REPORT IDENTIFICATION ............................................................................. 6 CODE D2A6H: QUERY CONFIGURATION.............................................................................. 8 CODE D4A6H: REPORT CONFIGURATION ............................................................................ 8 IDENTIFIER ASSIGNMENT................................................................................................... 9 CAPABILITY PUBLICATION ................................................................................................ 9 CODE D2A7H: QUERY SERVICES......................................................................................... 9 CODE D4A7H: REPORT SERVICES...................................................................................... 10

4

Introduction JAUS defines a system in terms of subsystems, nodes, and components. The

component provides a specific capability and is the main building block of the

system. A node is defined to be a set of related components, and a subsystem is

defined to be a set of related nodes. During system operation, components work

together for the purpose of achieving a common goal. Before a component can make

use of any other components’ capabilities, it must be able to uniquely identify each

component along with its specific capabilities. This information can be set up

statically before the system is started, or it can be set up dynamically after the system

is started. Dynamic Configuration is a process defined in this document that provides

a mechanism for setting up a JAUS system, or part of a JAUS system, when needed

rather than in advance.

Dynamic Configuration The dynamic configuration process can be broken down into the following:

discovery, identifier allocation, and capability publication. Discovery is the process

of determining the existence of other components, nodes, and subsystems within the

system. Identifier allocation is the process of assigning unique identifiers for each

component, node, and subsystem within the system. And, capability publication is

the process of conveying a component’s capability to any other component within the

system.

Discovery The process of discovery is conducted at both the node level and the subsystem level.

At the node level, a Report Heartbeat Pulse message must be sent to all nodes within

the subsystem. This message must be persistent at a 1 Hz rate from all nodes within

the subsystem. The JAUS destination identifier must be set to X:255:1:1, where X is

the subsystem identifier. The JAUS source identifier of the Report Heartbeat Pulse

message must be set to the component’s identifier that is capable of responding to the

messages Query Identification and Query Configuration at the node level. (Note that

this is different from previous experiments where the source identifier was specified

to be X:1:32:1, i.e., the subsystem commander) When a Report Heartbeat Pulse

message is received by another node within the subsystem, the receiving node may

query for the node’s identification and configuration information. Figure 1 shows a

5

typical flow of messages for discovering the configuration of a new node, where

nodes A, B, and C are all on the same subsystem. Note that in order to keep the

configuration up to date, a Create Event message can be used with the Report

Configuration message. This is in contrast to the prior approach of using specific

Configuration Event Setup and Notify messages.

The subsystem level discovery is very similar to the node level discovery. A Report

Heartbeat Pulse message must be sent to all nodes within the system, again at a 1Hz

rate. The JAUS destination identifier must be set to 255:255:1:1, and the JAUS

source identifier must be set to the component’s identifier that is capable of

responding to the messages Query Identification and Query Configuration at the

subsystem level. (Note that this is different from previous experiments where the

source was specified to be X:Y:35:1, i.e., the communicator) When a Report

Heartbeat Pulse message is received by a node from a different subsystem, the

receiving node may query for the subsystem’s identification and configuration

information. Figure 1 can be used again to show the typical flow of messages for

discovering the configuration of a new subsystem and keeping it current, where nodes

A, B, and C are all on different subsystems. Note again that in order to keep the

configuration up to date, a Create Event message can be used with the Report

Configuration message.

6

Report Heartbeat Pulse

Query Identification

Report Identification



Persistent 1 Hz

Create Event

Confirm Event

Query Configuration

Report Configuration

Node A Node B Node C

Figure 1. Configuration Discovery Message Flow

Code D2A4h: Query Identification This message shall request the identification summary of a Subsystem, Node, or

Component.

Field # Name Type Units Interpretation

1 Query Type Byte N/A

0: Reserved 1: System Identification 2: SS Identification 3: Node Identification 4: Component Identification

5 – 255: Reserved

Code D4A5h: Report Identification This message shall provide the requesting component an identification summary of

the Subsystem, Node, or Component.

7


1 Query Type Byte N/A

ed to mark the type of identification being returned. Should correspond to it’s respective Query.

Reserved System Identification SS Identification Node Identification Component Identification 5 – 255: Reserved

2 Authority Byte N/A Lowest level of authority required to gain control of Subsystem, Node, or Component Capabilities

3 Type Unsigned Short N/A

This field identifies the particular Unmanned Vehicle Type, Node Type or Component Type. The following values apply: 00000 = Reserved 10001 = Vehicle TBD 10002 = Vehicle TBD … 20000 = Reserved 20001 = OCU TBD 20002 = OCU TBD … 30000 = Reserved 30001 = Other Subsystem TBD 30002 = Other Subsystem TBD … 40000 = Reserved 40001 = Node TBD 40002 = Node TBD … 50000 = Reserved 50001 = Payload TBD 50002 = Payload TBD … 60000– 65535 Reserved

4 Identification Byte N/A Human-recognizable name of the Subsystem, Node or Component. This shall be a null terminated ASCII string.

8

Code D2A6h: Query Configuration This message shall request the configuration summary of a subsystem or node. For

example, to get the complete configuration of a subsystem, field 1 shall be set to 2.


1 Query Field Byte N/A

0: Reserved 1: Reserved 2: Subsystem Configuration 3: Node Configuration 4 – 255: Reserved

Code D4A6h: Report Configuration This message shall provide the receiving component a table of all existing

components located on the source’s subsystem or node depending on the value of

field 1 of the Query Configuration message.


1 Node Count Byte N/A # of Nodes reported. For a single Node Report this field shall be 1.

2 NodeID1 Byte N/A

Node ID of first node in table. For single Node or Component reporting this field shall contain the Node ID as specified in the Destination Address of the Query Configuration message

3 Comp Count 1 Byte N/A # of Comps reported for NodeID1

4 CompID1 Byte N/A

Comp ID of first Component reported. For Single Component reporting this field shall contain the Component ID as specified in the Destination Address of the Query Configuration message and shall be the only Component reported

5 InstID1 Byte N/A Inst ID of first Component reported.

…

CompIDi Byte N/A Comp ID of ith comp on first node in table

InstIDi Byte N/A Inst ID of ith comp on first node in table

NodeID2 Byte N/A Node ID of second node in table

Comp Count 2 Byte N/A # of Comps on second node in table

CompID1 Byte N/A Comp ID of first comp on second node in table

InstID1 Byte N/A Inst ID of first comp on second node in table

9

…

CompIDj Byte N/A Comp ID of jth comp on second node in table

InstIDj Byte N/A Inst ID of jth comp on second node in table

…

NodeIDn Byte N/A Node ID of the nth node in table

Comp Count n Byte N/A # of Comp on nth node in table

CompID1 Byte N/A Comp ID of first comp on nth node in table

InstID1 Byte N/A Inst ID of first comp on nth node in table

…

CompIDk Byte N/A Comp ID of kth comp on nth node in table

InstIDk Byte N/A Inst ID of kth comp on nth node in table

Identifier Assignment Identifier assignment is currently not addressed in this document. Therefore, all

identifiers must be statically assigned at this time.

Capability Publication Capability publication takes place at the component level. A component’s capability

is defined by the service it provides and the specifics about the input and output

messages required to support the service. Note that a component must still provide at

least one service, but it is no longer constrained to only one service. This effectively

ends the semantic link between Component ID and function. As a bridge, for

OPC 2.75, we are using an enumerated list of “Services”, which are currently

mapped to the list of Component IDs. The motivation for doing this is to further

disambiguate addressing and functionality. For now, we are not addressing the

issues of protocols in Capabiliity Publication. However, it is expected that

Services will provide a list of supported (or required) protocols for their use.

Code D2A7h: Query Services This message shall request the summary of a component’s registered services. The

query shall only be used to specify a single Component report. Instances of the

Query Services message shall be valid only if the Instance ID in the Destination

Address is not 0 or 255. This differs from the other Dynamic Registration messages,

as the replies to Query Services shall only come from the component level.

10

Code D4A7h: Report Services This message shall provide the receiving component a summary of all services

provided by a component. Note from Table A that service type 0 is reserved for

core message support. This is needed since a component is now able to support

multiple services and the core messages are directed to the component as a

whole. For example, the command RESUME will put a component in the Ready

State and therefore all services the component supports will be ready. Note that

this also means that taking control of a component takes control of all the

services provided by the component. Each service includes the messages accepted

as input and those provided as outputs. The command codes and presence vectors for

these messages shall be listed.


1 Service count Byte N/A # of services supported by the component

2 Service (1)

Unsigned Short N/A Service Type (See Service Type Table)

3 Input Message Count

Byte N/A # of input messages used to support service (1)

4 Input Message (1)

Unsigned Short N/A Command Code for Supported Message

5 Presence Vector (1)

Unsigned Integer N/A

Presence Vector for Command Code in previous field. This field, and all subsequent Presence Vector fields, shall always be 32 bits. For Presence Vectors smaller than 32 bits, the representative data shall be inserted with matching bit significance.

…

Input Message (i)


Presence Vector (i)

Unsigned Integer N/A See Interpretation for Field #5

11

Output Message Count

Byte N/A # of output messages used to support service (1)

Output Message(1)


Presence Vector (1)


…

Output Message (j)


Presence Vector (j)


…

Service (n)

Unsigned Short N/A Service Type (See Service Type Table)

Input Message Count

Byte N/A # of input messages used to support service (n)

Input Message (1)


Presence Vector (1)


…

Input Message (k)


Presence Vector (k)


Output Message Count

Byte N/A # of output messages used to support service (n)

12

Output Message1


Presence Vector


…

Output Message (l)


Presence Vector (l)


Table A. Service Types

Service Description Type

Core Message Support 0

Subsystem Commander 32

Primitive Driver 33

Global Vector Driver 34

Communicator 35

36

Visual Sensor 37

Global Pose Sensor 38

39

System Commander 40

Local Pose Sensor 41

Velocity State Sensor 42

Reflexive Driver 43

13

Local Vector Driver 44

Global Waypoint Driver 45

Local Waypoint Driver 46

Global Path Segment Driver 47

Local Path Segment Driver 48

Primitive Manipulator 49

Range Sensor 50

Manipulator Joint Position Sensor 51

Manipulator Joint Velocity Sensor 52

Manipulator Joint Force/Torque Sensor 53

Manipulator Joint Positions Driver 54

Manipulator End-Effector Pose Driver 55

Manipulator Joint Velocities Driver 56

Manipulator End-Effector Velocity State Driver 57

Manipulator Joint Move Driver 58

Manipulator End-Effector Discrete Pose Driver 59

Draft v 1.8 Page 2 of 148 07-27-05



Events and Service Connections

Version 1.8

September 10, 2004

Draft v 1.8 Page 3 of 148 07-27-05

Proposal for Events and Service Connections Teresa Nieten, Intelligent Innovations, Inc. Sarah Gray, Autonomous Solutions, Inc.

1. Introduction Last year Kathy Wienhold spent a great deal of effort creating a workable solution to Service Connections. This draft builds on that work, expanding it to encompass both service connections and events. To this end, command service connections are history, and service connections (and non-periodic events) are created using a Query message. First we must look at how information flows in a typical unmanned (or any command and control) system. Setting aside commands and initial handshaking, there are several ways to ask for and receive data.

1. On-demand – I want this information, and I want it right now. This is handled in JAUS by a Query/Report message pair. The entity that needs the data sends a Query to the entity that can provide it, who then responds with the corresponding Report message. This document does not cover on-demand Q/R messages, as they are already handled and extensively used.

2. On change – I only want to know when something happens. This is what most people would define a JAUS event to be. The entity that needs the data sends an event setup Query to the entity providing the service, who in turn responds with a Report message when the trigger conditions are met.

3. Periodic – I want this information on a regular basis. JAUS currently defines this type of data flow to be Service Connections. The entity that needs the data sends a service connection Query to the entity providing the service, along with a requested rate. The provider then sends the data at a set rate (not necessarily the requested rate) in a non-queuing manner.

This message set combines “On Change” and “Periodic” exchanges into the general category of Events. This allows any query/report pair to be used for events. It also requires that any new events be structured as query/report pairs. This message set goes through normal communication channels for Event Management. The subsequent generation of events should follow established protocol – Periodic Events have a fundamental set of rules that must still be followed (see Reference Architecture Volume II, Part 2, Version 3.2 section 3.6 for these rules). Note that ACK/NAK should be permitted for Event Management messages.

Draft v 1.8 Page 4 of 148 07-27-05

Code F0A1h: Create Event This message is used to set up an event. Required fields are 1, 2, 3, and 121. Field 1

provides a mapping of which optional fields are included. Field 2 contains the JAUS

Command Code of the included Query message, so the recipient knows how to

interpret the message. Field 3 is the Event Type, which allows the requester to

specify the type of event – Periodic specifies that the event is a service connection

request and should not be queued, in which case field 11 (Requested periodic rate)

must be included. Event type of Every Change specifies that the corresponding

Report message should be sent every time the data associated with that message

changes, subject to the optional boundary conditions. Event type of First Change

specifies that the Report message should be sent only the first time the data associated

with that message changes, subject to the optional boundary conditions. Event type

of First Change In and Out of Boundary specifies that the Report message should be

sent the first time the data associated with that messages changes, subject to the

boundary conditions, and again when the boundary conditions are no longer satisfied

(as an exit report). Event type of Periodic without Replacement specifies that the

report should be generated at the given periodic rate, but should be treated as a

regular message and not subject to existing service connection replacement rules.

Fields 4 through 9 are semantically linked. If none of these fields are specified and

the Event Type is Every Change, then any and all changes to that message should

trigger the event. If Field 4 is included, Fields 5 and 6, as well as either Field 7

and/or Field 8, or Field 9 should also be included.

Field 4 allows the requester to specify triggering conditions for events. An event

could be triggered when a condition is:

1This ordering breaks previously established rule that all required fields be first (RA section 3.7.6); if

memory serves, this rule was deemed unnecessary and slated for removal during the August 2004 JAUS working group meeting in Pittsburgh.

Draft v 1.8 Page 5 of 148 07-27-05

Exactly met, most likely used for discrete fields, such as Status or waypoint

number;

value = trigger condition

Not met, often used for discrete fields like Status

value != trigger condition

Between two values (such as a payload arm position)

trigger low <= value <= trigger high

trigger low < value < trigger high

Outside of two values (such as a temperature reading being too high or too low),

value <= trigger low OR value >= trigger high

value < trigger low OR value > trigger high

Above a given value (a temperature is too high, speed is too fast, notification

when a robot has come up to speed)

value > trigger condition

value >= trigger condition

Below a given value (low fuel or battery).

value < trigger condition

value <= trigger condition

Used in conjunction with “Periodic” event type, a service connection is activated

when the trigger condition is met and suspended when it is not met. Used in

conjunction with the event type “Every Change” an event will be triggered when that

triggering condition is met, and every value that meets that triggering criteria should

cause an event notification to occur. Used with “First Change” event type, an event

would be triggered once per trigger event – that is, if the watched value crosses the

Draft v 1.8 Page 6 of 148 07-27-05

trigger boundary, it triggers an event, then does not trigger another event until the

value goes back outside the triggering boundary and back in.2

Field 6 specifies the field number of the field in the report message that corresponds

to the boundary condition and Field 5 specifies its data type. It should be included if

and only if a boundary condition is specified (field 4). Field 7 should be used to

specify the lower boundary value for Inside, Outside, and Low Boundary Types.

Field 8 should be used to specify the upper boundary value for Inside, Outside, and

High Boundary Types. Field 9 should be used if and only if the Event Boundary type

is Equal.

Field 10 is used for throttling updates in periodic messages. If a Service Connection

is created for position, and the vehicle is sitting still, it allows the requester to tell the

provider to throttle-back the flow during that time. If the Requested Update Rate

(field 11) is 5 and the Requested Minimum Update Rate (field 10) is 1, the events will

be generated at a rate of 5 HZ if it is changing, but only 1 HZ when the content of the

message (i.e., position) is not changing. Field 11, as specified earlier, is the requested

rate for service connections.

Field 12 contains the Query message that is to specify the contents of the Report.

2This assumes that if the requester wants to know when the trigger condition ceases, a separate “first

change” event will be issued with the opposite trigger. Could add a field for exit from trigger condition if the need is there.

Draft v 1.8 Page 7 of 148 07-27-05

Table 1CreateEvent

Field # Name Type Units Interpretation 1 Presence Vector byte N/A See mapping table below

2 Message Code Unsigned

short integer

N/A

Message code of the Query message that the receiving component will use to generate a responding Report for this message stream.

3 Event Type byte N/A

Type of event, enumeration: 0: Periodic (SC) 1: Every Change 2: First Change 3: First change in and out of boundary 4: Periodic w/o replacement

4 Event Boundary byte N/A

Boundary condition on event trigger, enumeration: 0: Equal 1: Not Equal 2: Inside Inclusive 3: Inside Exclusive 4: Outside Inclusive 5: Outside Exclusive 6: Greater than or Equal 7: Strictly Greater than 8: Less than or Equal 9: Strictly Less than

5 Limit Data Field Type byte N/A

Enumeration 0: byte 1: Short Integer 2: Integer 3: Long Integer 4: Unsigned Short Integer 5: Unsigned Integer 6: Unsigned Long Integer 7: Float 8: Long Float 9: RGB (3 Bytes) 10 – 255: Reserved

6 Limit Data Field byte N/A Field from Report message to base trigger limit on

Draft v 1.8 Page 8 of 148 07-27-05


7 Lower Limit varies (see field 5) varies

Lower limit for trigger condition, used for Inside, Outside, and Low Event Boundary Types

8 Upper Limit varies (see field 5) varies

Upper limit for trigger condition, used for Inside, Outside, and High Event Boundary Types

9 State varies (see field 5) varies

Trigger value used for Equal Event Boundary Type. Typically used for discrete-type events.

10 Requested

Minimum Periodic Rate

Unsigned short Integer

Hertz

For Periodic events, used to throttle messages if the value is not changing. Desired update rate: Scaled Integer Lower Limit: 0 Upper Limit: 1092

11 Requested

Periodic Update Rate

Unsigned Short Integer

Hertz

Desired update rate: Scaled Integer Lower Limit: 0 Upper Limit: 1092

12 Query Message JAUS Message N/A

The JAUS Query message to be used by the receiving component to generate the Report message(s).

Vector to Data Field Mapping for Above Command Vector Bit 7 6 5 4 3 2 1 0 Data Field 11 10 9 8 7 6 5 4

“R” indicates that the bit is reserved.

Code F009h: Confirm Event Confirm Service Connection -> Confirm Event. Add 1 byte presence vector for rate since some events will not have rates.

Table 2ConfirmEvent

Draft v 1.8 Page 9 of 148 07-27-05


2 Command Code unsigned short N/A Command code of the message to

be sent in this event 3 Event ID byte N/A The specific event

4 Confirmed


unsigned short Hertz

Scaled Integer: Lower Limit = 0 Upper Limit = 1092

5 Response Code byte N/A

Enumeration: 0 = successful 1 = Periodic events not supported 2= Change-based events not supported 4 = Connection Refused 5 = Invalid event setup 6 = Message not supported

Vector to Data Field Mapping for Above Command Vector Bit 7 6 5 4 3 2 1 0 Data Field R R R R R R R 4

Code F0A2h: Update Event Update Event – This would allow the requester to request a rate or threshold change. The format would be the same as the Create Event, only with the addition of Event ID (formerly Instance ID) field to specify the given event. To preserve the message format and presence vector, the EventID is proposed to be added at the end of the message.

Draft v 1.8 Page 10 of 148 07-27-05



short integer

N/A

Message code of the Query message that the receiving component will use to generate a responding Report for this message stream.


Type of event, enumeration: 0: Periodic (SC) 1: Every Change 2: First Change 3: First change in and out of boundary 4: Periodic w/o replacement

4 Event Boundary byte N/A

Boundary condition on event trigger, enumeration: 0: Equal 1: Not Equal 2: Inside Inclusive 3: Inside Exclusive 4: Outside Inclusive 5: Outside Exclusive 6: Greater than or Equal 7: Strictly Greater than 8: Less than or Equal 9: Strictly Less than

5 Limit Data Field Type byte N/A

Enumeration 0: byte 1: Short Integer 2: Integer 3: Long Integer 4: Unsigned Short Integer 5: Unsigned Integer 6: Unsigned Long Integer 7: Float 8: Long Float 9: RGB (3 Bytes) 10 – 255: Reserved

6 Limit Data Field byte N/A Field from Report message to base trigger limit on

Draft v 1.8 Page 11 of 148 07-27-05


7 Lower Limit varies (see field 5) varies

Lower limit for trigger condition, used for Inside, Outside, and Low Event Boundary Types

8 Upper Limit varies (see field 5) varies

Upper limit for trigger condition, used for Inside, Outside, and High Event Boundary Types

9 State varies (see field 5) varies

Trigger value used for Equal Event Boundary Type. Typically used for discrete-type events.

10 Requested

Minimum Periodic Rate

Unsigned short Integer

Hertz

For Periodic events, used to throttle messages if the value is not changing. Desired update rate: Scaled Integer Lower Limit: 0 Upper Limit: 1092

11 Requested



Hertz

Desired update rate: Scaled Integer Lower Limit: 0 Upper Limit: 1092

12 Event ID byte N/A Unique Identifier to of existing event to update

13 Query Message JAUS

Message (bytes)

N/A

The JAUS Query message to be used by the receiving component to generate the Report message(s).

Vector to Data Field Mapping for Above Command Vector Bit 7 6 5 4 3 2 1 0 Data Field R R R R R R R 4 Code F00Bh: Cancel Event Cancel Event – This message allows the requester to cancel/request deletion of the specified event.

Draft v 1.8 Page 12 of 148 07-27-05

Table 3Cancel Event


1 Command Code unsigned short N/A Command code of the message to

be stopped

2 Event ID byte N/A Unique ID of the event to be removed

Code F2A1h: Query Event Query Events – Used to request detail on all/given events:

Field 2 indicates the message code in question. If left out, all message codes should be returned. Field 3 indicates the event type to report on. If left out, all event types should be considered. Field 4 Indicates a specific event ID. If left out, all event Ids should be considered.

Table 4Query Event



short integer

N/A Message code of the Query message that the receiving component is inquiring about


Type of event, enumeration: 0: Periodic 1: Every Change 2: First Change

4 Event ID byte N/A Event ID returned by Confirm Event for details on specific event.

Vector to Data Field Mapping for Above Command Vector Bit 7 6 5 4 3 2 1 0 Data Field R R R R R 4 3 2

“R” indicates that the bit is reserved.

Code F4A1h: Report Event Report Events

Same format as Update Event, used to reply to Query Events message to give the detail on which events are currently in use by the provider (as defined by the query message).

Draft v 1.8 Page 13 of 148 07-27-05

Other issues Replace all references to “Service Connections” with “Periodic Events.”

Suspend Event – stop sending but do not remove. Do we want this?

Service Connection infrastructure

SC bit in header -> move to Event Bit, add periodic bit (for OPC, use existing SC bit)

THE JOINT

ARCHITECTUREFOR

UNMANNED SYSTEMS

Payload Interface

Version 0.1

August 29, 2004

DRAFT 6/28/2006

i

Document Change Log

Version Date Description 0.1 8/29/05 Initial separate of payload interface

content from JAUS OPC ICD document. No other changes.

DRAFT 6/28/2006

ii

DOCUMENT CHANGE LOG .....................................................................................I

INTRODUCTION................................................................................................................... 1 MESSAGE SPECIFICATIONS ................................................................................................ 1 CODE D201H: QUERY PAYLOAD INTERFACE MESSAGE................................................... 2 CODE D401H: REPORT PAYLOAD INTERFACE MESSAGE................................................. 2 CODE D202H: QUERY PAYLOAD DATA ELEMENT............................................................ 5 CODE D402H: REPORT PAYLOAD DATA ELEMENT .......................................................... 6 CODE D001H: SET PAYLOAD DATA ELEMENT.................................................................. 6 CODE D601H: PAYLOAD DATA ELEMENT EVENT SETUP ................................................. 7 CODE D801H: PAYLOAD DATA ELEMENT EVENT NOTIFICATION ................................... 8 TYPE CODE TABLE ....................................................................................................... 9 HMI ENUMERATION TABLE .................................................................................... 10 UNITS TABLE................................................................................................................ 12

DRAFT 6/28/2006

Appendix C Page 1

Introduction The Operator Control Unit and Payloads Committee (OPC) of the Joint Architecture for Unmanned Systems (JAUS) Working Group is planning for a Payload Interoperability Experiment in August 2004. This experiment will require basic communication of payload capabilities between the Subsystem on which the Payload is mounted and the Operator Control Unit. The focus of this interface is to establish a minimal set of messages to support this interoperability. Other ongoing efforts to aid in interoperability, specifically Dynamic Registration and Configuration, are assumed to exist. During planning sessions conducted by the OPC, discussions about the Common Sensor Interface document, prepared by the Sensors Subcommittee of the RA, concluded that a simplified version of the interface would suffice for the experiment. Payloads must provide description text, JAUS components and messages provided/supported, and payload specifics as outlined below. The Dynamic Registration and Configuration messages currently under development must deal with the JAUS Component and Message interfaces required to support Payloads. A payload component ID as well as the message IDs included in this interface will support the publication of a payload interface. These messages are to be used only subsequent to the Dynamic Registration and Configuration process. Message Specifications Interface Requirements for the payload interface are summarized as: Command and Control Data Element

• Identifier: What does the Value Control (Text) • Type Code: Type code in TYPE CODE TABLE. Defines

the number of Bytes for this Data Element and the Data Type • Units: Units as defined in UNITS TABLE defines the indicated measure. • Range: Minimum, Median, and Maximum for Analog data Elements

Information Data Element

• Identifier: What does the Data Represent (Text) • Type Code: See Type code in Common Sensor Interface, defines

Bytes per Data Element and Data Type • Units: SI Base Units as defined in Common Sensor Interface • Range: Minimum, Median, and Maximum for non-discrete data Elements

One or more Presentation Elements must exist for any given payload for the experiment. The following graphic simplifies the payload interface showing a sensor and an output screen.

DRAFT 6/28/2006

Appendix C Page 2

The message set presented herein includes payload interface specifications and command and control messaging including a mechanism for event notification. The messages in the following table are detailed followed by some simple examples of their utility.

Message Summary Input Messages Output Messages Query Payload Interface Report Payload Interface Query Payload Data Element Report Payload Data Element Set Payload Data Element Payload Data Element Event Setup Payload Data Element Event Notification All payload messages defined herein shall have the JAUS User-Defined bit set in the header. Code D201h: Query Payload Interface Message No message data beyond header. Query Payload Interface must be responded to with either

NAK implies that the component/node is not a payload but is a Component/Node with standard JAUS message capabilities. We need to address PAYLOAD IDs in Dynamic Registration and Configuration to better define this behavior. Or Code D401h: Report Payload Interface Message

Code D401h: Report Payload Interface Message The Report Payload Interface Message is used to publish the command and informational data elements, their respective types, units and ranges to the using component(s). The total number of interface elements is determined by adding the first two fields. All payloads must have at least one Informational interface.

OCU

www.Chem-Sniff.com X

ppm: 230Sample: 12896Alarm: 350ppm

ppm: 230 Sample: 12896 Alarm: 350ppm

www.Chem-Sniff.com X

ppm: 230Sample: 12896Alarm: 350ppm

ppm: 230 Sample: 12896 Alarm: 350ppm

Command and Control

Presentation

DRAFT 6/28/2006

Appendix C Page 3


1 Presence Vector Byte N/A See mapping table below

2 Number Command Interfaces (N)

Byte Integer

The number (N) of unique command and control data elements supported by the Payload.

3 Number Information Interfaces (M)

Byte Integer The number (M) of unique information data elements supported by the Payload.

4 Identifier Command 1 String N/A

NULL-Terminated Identification of the Command Interface

5 Type Code Command 1 Byte N/A See Type Code Table

6 Units Command 1 Byte N/A See Units Table

7 Blocking Flag Byte N/A Bit Field 0: Blocking (Active High) 1-7: Reserved

8 Minimum Command 1

See Note *

Defined by Units Minimum Acceptable Value

9 Default Command 1

See Note *

Defined by Units Default Value

10 Maximum Command 1

See Note *

Defined by Units Maximum Acceptable Value

11 Enumerations Length

Unsigned Short Bytes

Number of Bytes in the Enumerations Command field. This number includes the terminating Null character, the comma delimiters and the spaces.

12 Enumerations Command 1 String N/A See “Enumeration Discussion”

Below.

13 HMI Recommendation Byte N/A See HMI Enumeration Table

14 HMI Recommended Position X

Unsigned Short Pixels

15 HMI Recommended Position Y


16 HMI Recommended Width


17 HMI Unsigned Pixels

DRAFT 6/28/2006

Appendix C Page 4

Recommended Height

Short

.

.

. Repeat fields 4 through 17

14N+4 Identifier Info 1 String N/A NULL-Terminated Identification of the Information Interface

14N+5 Command Interface Association

Byte N/A

Number of the Command Interface that this Information Interface is associated with. If there is no association, this value shall be set to zero.

14N + 6 Type Code Info 1 Byte N/A See Type Code Table 14N + 7 Units Info 1 Byte N/A See Units Table

14N + 8 Minimum Info 1 See Note *

Defined by Units Minimum Acceptable Value

14N + 9 Default Info 1 See Note *

Defined by Units Default Value

14N + 10 Maximum Info 1 See Note *

Defined by Units Maximum Acceptable Value

14N + 11 Enumerations Length

Unsigned Short Bytes

Number of Bytes in the Enumerations Command field. This number includes the terminating Null character, the comma delimiters and the spaces.

14N + 12 Enumerations Info 1 String N/A See “Enumeration Discussion”

Below.

14N + 13 HMI Recommendation Byte N/A See HMI Enumeration Table

14N+14 HMI Recommended Position X


14N+15 HMI Recommended Position Y


14N+16 HMI Recommended Width


14N+17 HMI Recommended Height


DRAFT 6/28/2006

Appendix C Page 5

.

.

. Repeat fields 14N+4 through 14N+17

Vector to Data Field Mapping for Above Command

Vector Bit 7 6 5 4 3 2 1 0 Data Field R R R 17 16 15 14 13

(“R” indicates that the bit is reserved.) Note *: The preceding Type Code field defines the Type with the exception of Scaled types when the type of this field is float. The values of the Minimum, and Maximum fields specify the range of the Scaled type. The type of the Default value is also a float in this message. Additionally, when the preceding Type Code field is 19, a length and string type, the Minimum, Default, and Maximum fields shall be assigned type byte. Enumerations allow sensor data formats that categorize their input, or detect states, or have some other discrete nature. The implementation is an Unsigned Short Integer, which is used as an index into the Text Array defined in the Enumerations field. Booleans are a specialization of Enumerations that only have two values – True and False. The implementation is a Byte with 0 = False, 1 = True, 2-255 = Reserved. Enumeration Discussion: The Enumerations value is a comma delimited, NULL terminated string of enumeration descriptions. The Enumerations Length field shall be 0 if there are no enumerations for that particular interface. When the Enumerations Length is 0, the Enumerations field does not exist. The enumerations are string representations of sequential numeric values from 1 up to 255. The intent of this type of data is to provide an obvious mapping between the numeric values and the human readable value. When a payload receives a query for a data element (Query Payload Data Element) that maps to an enumeration, the response (Report Payload Data Element) value field will contain a numeric value. The user (component that initially performed the query) will use the value as in index into the list of string representations. Code D202h: Query Payload Data Element Querying of a payload data element must specify the specific information interface number as reported in the Report Payload Interface Message. Querying of command and control data elements is not supported. The Information Interface Number is the unique identifier derived from the placement of the interface in the Report Payload Interface message. The Information Interface Number starts at 1 for the first published informational interface. Field # Name Type Units Interpretation

1 Number Byte Integer The number (M) of information

DRAFT 6/28/2006

Appendix C Page 6

Information Interfaces

data elements being requested by the Payload controller.

2 Information Interface Number Byte Integer

The number of the information data element as reported in the Report Payload Interface.

…

M+1 Information Interface Number Byte Integer


Code D402h: Report Payload Data Element The Report Payload Data Element message is used as a response to the Query Payload Data Element message. NOTE: This message cannot presently be supported via Service Connection as the Create Service Connection message will not allow the required parameter specified within the Query Payload Data Element message. The Information Interface Number is the unique identifier derived from the placement of the interface in the Report Payload Interface message. The Information Interface Number starts at 1 for the first published informational interface. Field # Name Type Units Interpretation

1 Number Information Interfaces

Byte Integer The number (M) of information data elements being reported by the Payload.



3 Value Defined by Type Code

Defined by Units Current/Reported Value

…

2M Information Interface Number Byte Integer


2M+1 Value Defined by Type Code


Code D001h: Set Payload Data Element The Set Payload Data Element message allows the using component to set command and control interface fields published by the Report Payload Message Interface message. The Command Interface Number is the unique identifier derived from the placement of the

DRAFT 6/28/2006

Appendix C Page 7

interface in the Report Payload Interface message. The Command Interface Number starts at 1 for the first published interface. Field # Name Type Units Interpretation

1 Number of Command Interfaces

Byte Integer

The number (M) of the command and control data elements to be commanded in this message.

2 Command Interface Number Byte Integer

The number of the command and control data element as reported in the Report Payload Interface.



…

2M Command Interface Number Byte Integer

The number of the command and control data element as reported in the Report Payload Interface.

2M+1 Value Defined by Type Code


Code D601h: Payload Data Element Event Setup The Payload Data Element Event Setup message provides a mechanism to automatically report an interface value between the High Value and the Low Value. The Information Interface Number is the unique identifier derived from the placement of the interface in the Report Payload Interface message. The Information Interface Number starts at 1 for the first published informational interface. For any value Low Value <= Actual Value <= High Value, the Notification is requested. For discrete states and/or enumerations, a single value may be entered in the High Value field. Event Setup only applies to information data elements within a payload interface. Field # Name Type Units Interpretation

1 Notification Type Byte N/A

Description of Change 1 – Always Notify 2 – Notify on Boundary

DRAFT 6/28/2006

Appendix C Page 8

3 – Terminate Notifications 4 to 255 – Reserved


The number the information data element as reported in the Report Payload Interface.

3 High Value Defined by Type Code

Defined by Units

Highest numerical value at which Notification is Requested.

4 Low Value Defined by Type Code

Defined by Units

Lowest numerical value at which Notification is Requested.

Code D801h: Payload Data Element Event Notification The Payload Data Element Event Notification message is used to automate the response requested by the Payload Data Element Event Setup message. Field # Name Type Units Interpretation


The number the information data element as reported in the Report Payload Interface.


Defined by Units

Current/Reported Value that triggered the Event Notification

DRAFT 6/28/2006

Appendix C Page 9

TYPE CODE TABLE

Enumeration Type Definition 0 Reserved 1 Short Integer (2 bytes) 2 Integer (4 bytes)

3 Long Integer (8 bytes) 4 Byte (1 byte) 5 Unsigned Short (2 bytes) 6 Unsigned Integer (4 bytes) 7 Unsigned Long (8 bytes) 8 Float (4 bytes) 9 Long Float (8 bytes) 10 Scaled Unsigned Byte (1 byte) 11 Scaled Signed Short Integer (2 bytes) 12 Scaled Unsigned Short Integer (2 bytes) 13 Scaled Signed Integer (4 bytes) 14 Scaled Unsigned Integer (4 bytes) 15 Scaled Signed Long Integer (8 bytes) (not used in

experiment #2) 16 Scaled Unsigned Long Integer (8 bytes) (not used in

experiment #2) 17 Enumeration (2 bytes) 18 Boolean (1 byte) 19 Length (unsigned short) followed by Null Terminated

ASCII String 20 Unsigned Byte 2-Tuple (2 Bytes) 21 Unsigned Short 2-Tuple (4 Bytes) 22 Unsigned Integer 2-Tuple (8 Bytes) 23-255 Reserved

DRAFT 6/28/2006

Appendix C Page 10

HMI ENUMERATION TABLE The HMI Recommendation Field in the Report Payload Interface message serves only as a recommendation for the display output associated with that particular data or control element. For the experiment, only a subset of the list has been identified within the participant submitted Interface Control Documents.

Enum HMI Widget

Type Description

0 Reserved Reserved 1 Alpha-list Allows a user to select from a list of words, with the ability to

narrow the search list by typing in a few characters of the desired word.

2 Button This creates a button widget

3 Button-box This creates a multiple button widget

4 Calendar Creates a little simple calendar widget 5 Canvas Canvas widgets implement structured graphics 6 Dialog Prompts the user with a message, and the user can pick an

answer from the buttons provided 7 Gauge 8 Graph A graphing widget 9 Histogram Creates a histogram. (vertical or horizontal) 10 Item List Creates a pop up field that allows the user to select one of

several choices in a small field. Very useful for things like days of the week or month names.

11 Label Displays messages in a pop up box, or the label can be considered part of the screen.

12 Marquee Displays a message in a scrolling marquee 13 Matrix Creates a complex matrix with lots of options. 14 Menu Creates a pull-down menu interface 15 Multiple Line

Entry A multiple line entry field. Very useful for long fields. (like a description field)

16 Point 2-D Two-dimensional point coordinates are displayed with a text entry for each of their component values.

17 Point 3-D Three-dimensional point coordinates are displayed with a text entry for each of their component values.

18 Push Button 19 Radio List Creates a radio button list. 20 Scale Creates a numeric scale. Used for allowing a user to pick a

numeric value and restrict them to a range of values 21 Scrolling List Creates a scrolling list/menu list 22 Scrolling

Window Creates a scrolling log file viewer. Can add information into the window while its running. A good widget for displaying the progress of something. (akin to a console window)

23 Selection List Creates a multiple option selection list

DRAFT 6/28/2006

Appendix C Page 11

24 Slider Akin to the scale widget, this widget provides a visual slide bar to represent the numeric value

25 Spin Box Numeric variables are usually displayed with a simple text entry widget.

26 Toggle Button

Toggle buttons are used to represent Boolean variables, which can have the value of either "true" or "false"

27 Viewer This is a file/information viewer. Very useful when you need to display loads of information.

28 Joystick 29 Image This HMI interface allows an entire GUI or portions of a GUI

to be sent to the OCU as an image. Clicks on the image are reported to the payload as points with coordinates of X and Y. These coordinates shall be reported using one of the 2-tuple data types defined in the TYPE CODE TABLE.

30 TBD 31 –255 Reserved

DRAFT 6/28/2006

Appendix C Page 12

UNITS TABLE Enum Quantity Name Symbol 0 Unit less/dimensionless Place holder N/A 1 Length Meter m 2 Mass Kilogram kg 3 Time Second s 4 Electric current Ampere A 5 Thermodynamic temperature Kelvin K 6 Amount of substance Mole mol 7 Luminous Intensity Candela cd 8 Area Square meter m2 9 Volume Cubic meter m3 10 Speed, Velocity Meter per second m/s 11 Acceleration Meter per second squared m/s2 12 Wave Number Reciprocal meter m-1 13 Mass Density Kilogram per cubic meter kg/m3 14 Specific Volume Cubic meter per kilogram m3/kg 15 Current density Ampere per square meter A/m2 16 Magnetic field strength Ampere per meter A/m 17 Amount-of-substance

Concentration Mole per cubic meter mol/m3

18 Luminance Candela per square meter cd/m2 19 Plane Angle Radian rad 20 Solid Angle Steradian sr 21 Frequency Hertz Hz 22 Force Newton N 23 Pressure, stress Pascal Pa 24 Energy, work, quantity of heat Joule J 25 Power, radiant flux Watt W 26 Electric charge, quantity of

electricity Coulomb C

27 Electric potential difference, electromotive force

Volt V

28 Capacitance Farad F 29 Electric resistance Ohm W 30 Electric conductance Siemens S 31 Magnetic Flux Weber Wb 32 Magnetic Flux Density Tesla T 33 Inductance Henry H 34 Celsius Temperature Degree Celsius C 35 Luminous Flux Lumen lm 36 Illuminance Lux lx 37 Activity (of a radionuclide) Becquerel Bq

DRAFT 6/28/2006

Appendix C Page 13

38 Absorbed dose, Specific Energy (imparted), Kerma

Gray Gy

39 Dose equivalent (d) Sievert Sv 40 Catalytic activity Katal kat 41 Dynamic viscosity Pascal second Pa.s 42 Moment of force Newton meter N.m 43 Surface tension Newton per meter N/m 44 Angular velocity Radian per second rad/s 45 Angular acceleration Radian per second squared rad/s2 46 Heat flux density, irradiance Watt per square meter W/m2 47 Heat capacity, entropy Joule per Kelvin J/K 48 Specific heat capacity, specific

entropy Joule per kilogram Kelvin J/(kg.K)

49 Specific energy Joule per kilogram J/kg 50 Thermal conductivity Watt per meter Kelvin W/(m.K) 51 Energy density Joule per cubic meter J/m3 52 Electric field strength Volt per meter V/m 53 Electric charge density Coulomb per cubic meter C/m3 54 Electric flux density Coulomb per square meter C/m2 55 Permittivity Farad per meter F/m 56 Permeability Henry per meter H/m 57 Molar energy Joule per mole J/mol 58 Molar entropy, molar heat

capacity Joule per mole Kelvin J/(mol.K)

59 Exposure (x-rays) Coulomb per kilogram C/kg 60 Absorbed Dose Rate Gray per second Gy/s 61 Radiant Intensity Watt per Steradian W/sr 62 Radiance Watt per square meter

Steradian W/(m2.sr)

63 Catalytic (activity) Concentration

Katal per cubic meter kat/m3

127 Percent 128 Decimal Degrees 129 130 Pixels

DRAFT 6/28/2006

Appendix D Page 1



Version 1.5.1

Carl P. Evans III, Chair JAUS World Model Subcommittee

Applied Perception, Inc.

[email protected]

October 24, 2005

Reference Architecture Proposed Addendum

World Model Knowledge Store

Components

ii

Document Change Log

Version Date Description 1.1 04/18/2005 Added support for querying multiple feature classes in the

Code F220h: Query Vector Knowledge Store Objects message

1.2 07/08/2005 Added a field (Number of Points for Object x) to the Code F020h: Create Vector Knowledge Store Objects message for each vector object. This field specifies the number of points (vertices) that make up the vector object.

In the Code F020h: Create Vector Knowledge Store Objects message, the feature class ID is now followed by the feature class attribute for that feature class. In the previous message, all feature classes were listed followed by all feature class attributes.

Added two fields to the Code F020h: Create Vector Knowledge Store Objects message for the pth object. These fields specify the latitude and longitude of the first point of the vector object.

Added two fields to the Code F220h: Query Vector Knowledge Store Objects message. These fields (the feature class attribute data type and the feature class attribute value) allow the scope of a query to be limited to specific values within a feature class.

Removed all Event Notification related messages. This functionality will be provided by the methods developed by Nieten and Gray in “Proposal for Events and Service Connections.” The messages removed are:

• Code F600h: Raster Knowledge Store Event Notification Request

• Code F601h: Raster Knowledge Store Bounds Change Event Notification Request

• Code F800h: Raster Knowledge Store Event Notification (Cell Update)

• Code F801h: Raster Knowledge Store Event Notification (Grid Update)

• Code F802h: Raster Knowledge Store Bounds Change Event Notification

• Code F620h: Vector Knowledge Store Event Notification Request

• Code F621h: Vector Knowledge Store Bounds Change Event Notification Request

• Code F820h: Vector Knowledge Store Event Notification

• Code F821h: Vector Knowledge Store Bounds Change Event Notification

Document Change Log (Continued) 1.3 07/15/2005 The Code F220h: Query Vector Knowledge Store Objects

iii

message, to allow a feature class attribute data type and value to be associated with each feature class attribute value. Before there query supported multiple feature classes, but only one attribute data type and value.

In the Code F220h: Query Vector Knowledge Store Objects message, the “Number of Region Points” field has been moved to be directly before the vertices that make up the query region. This was done to make it more consistent with the Code F020h: Create Vector Knowledge Store Objects and Code F422h: Report Vector Knowledge Store Objects messages.

1.4 09/01/2005 In the Code F220h: Query Vector Knowledge Store Objects message, “Object 1” was removed from fields 7, 8, 9, 4+3n, 5+3n, and 6+3n. In fields 7 and 4+3n. The interpretation of this field was changed so that 65,535 is no longer reserved. The value corresponds to all feature classes within the knowledge store.

Throughout the document, the data type used for describing feature classes was changed from “Short Integer” to “Unsigned Short Integer.”

In the Code F423h: Report Vector Knowledge Store Bounds message, two fields were added to the beginning of the message. Field one is now the Local Request ID. This field corresponds to the Local Request ID field in the Code F222h: Query Vector Knowledge Store Bounds message. Field two is the Feature Class ID for which the bounds (message fields 3 through 6) are valid. In each of the name fields, “Point” was changed to “Bound.”

1.5 10/03/2005 In the Code F404h: Report Raster Knowledge Store Bounds message, two fields were added to the beginning of the message. Field one is now the Local Request ID. This field corresponds to the Local Request ID field in the Code F202h: Query Raster Knowledge Store Bounds message. Field two is the Feature Class ID for which the bounds (message fields 3 through 6) are valid. In each of the name fields, “Point” was changed to “Bound.”

The Code F422h: Report Vector Knowledge Store Objects message was modified to allow multiple feature classes to be associated with a single object. This message is now more inline with the Code F020h: Create Vector Knowledge Store Objects message.

Added Table of Contents Fixed Table Splitting for All Multi-page messages Corrected a number of grammatical and typographical errors The Code F022h: Delete Vector Knowledge Store Objects

was update to match the format of the Code F220h: Query Vector Knowledge Store Objects message

Document Change Log (Continued) Added Support for Object IDs to the following vector

iv

knowledge store messages: • Code F022h: Delete Vector Knowledge Store

Objects • Code F220h: Query Vector Knowledge Store

Objects • Code F420h: Report Vector Knowledge Store

Object(s) Creation • Code F422h: Report Vector Knowledge Store

Objects

vi

Document To-Do List

Version Date Description 1.5 10/03/2005 Move component IDs and message command codes out of

the user-defined range. Make sure the command codes follow the JAUS convention (e.g., a 0xF420 Report message corresponds to a 0xF220 Query message).

Clarify when fields are logically ANDed or ORed Write new descriptions for the following messages:

• Code F022h: Delete Vector Knowledge Store Objects

• Code F220h: Query Vector Knowledge Store Objects

• Code F422h: Report Vector Knowledge Store Objects

Add 3D support The Raster Knowledge Store messages need a lot of work!!!

viii

Definition of World Model (as adopted by the JAUS World Model Subcommittee)

“The world model is the intelligent system’s best estimate of the state of the world. The world model includes a database of knowledge about the world, plus a database management system that stores and retrieves information. The world model also contains a simulation capability that generates expectations and predictions. The world model provides answers to requests about the present, past, and probable future states of the world. The world model provides this information service to the behavior generation system element in order to make intelligent plans and behavioral choices. It provides information to the sensory processing system element to perform correlation, model matching, and model-based recognition of states, objects, and events. It provides information to the value judgment system element to compute values such as cost, benefit, risk, uncertainty, importance, and attractiveness. The world model is kept up to date by the sensory processing system element.”3

3 Meystel, Alexander M. , and James S. Albus, Intelligent Systems: Architecture, Design, and Control.

New York: John Wiley & Sons, 2002.

x

Table of Contents

DOCUMENT CHANGE LOG ................................................................................................. II

DOCUMENT TO-DO LIST.....................................................................................................VI

DEFINITION OF WORLD MODEL...................................................................................VIII

1.0 WORLD MODEL COMPONENTS ................................................................................... 1

1.1 OBSERVATIONS AND RECOMMENDATIONS FROM LITERATURE REVIEW 1

1.2 WORLD MODEL TERMS ................................................................................................... 3

1.3 JAUS CORE MESSAGES AND COMPONENT STATES............................................. 3

xi

1.4 WORLD MODEL RASTER KNOWLEDGE STORE (COMPONENT ID 30)............ 5

CODE F000H: CREATE RASTER KNOWLEDGE STORE OBJECT.................................................. 7 CODE F001H: SET RASTER KNOWLEDGE STORE FEATURE CLASS METADATA..................... 9 CODE F002H: MODIFY RASTER KNOWLEDGE STORE OBJECT (CELL UPDATE) ..................... 9 CODE F003H: MODIFY RASTER KNOWLEDGE STORE OBJECT (GRID UPDATE)................... 12 CODE F004H: DELETE RASTER KNOWLEDGE STORE OBJECTS .............................................. 14 CODE F200H: QUERY RASTER KNOWLEDGE STORE OBJECTS ............................................... 14 CODE F201H: QUERY RASTER KNOWLEDGE STORE FEATURE CLASS METADATA ............. 16 CODE F202H: QUERY RASTER KNOWLEDGE STORE BOUNDS ............................................... 16 CODE F005H: TERMINATE RASTER KNOWLEDGE STORE DATA TRANSFER ........................ 17 CODE F400H: REPORT RASTER KNOWLEDGE STORE OBJECT CREATION MESSAGE .......... 18 CODE F401H: REPORT RASTER KNOWLEDGE STORE FEATURE CLASS METADATA ........... 18 CODE F402H: REPORT RASTER KNOWLEDGE STORE OBJECTS (CELL UPDATE) .................. 19 CODE F403H: REPORT RASTER KNOWLEDGE STORE OBJECTS (GRID UPDATE) ................. 21 CODE F404H: REPORT RASTER KNOWLEDGE STORE BOUNDS.............................................. 23 CODE F405H: REPORT RASTER KNOWLEDGE STORE DATA TRANSFER TERMINATION..... 24

1.5 WORLD MODEL VECTOR KNOWLEDGE STORE (COMPONENT ID 31)......... 25

CODE F020H: CREATE VECTOR KNOWLEDGE STORE OBJECTS ............................................. 27 CODE F021H: SET VECTOR KNOWLEDGE STORE FEATURE CLASS METADATA .................. 32 CODE F022H: DELETE VECTOR KNOWLEDGE STORE OBJECTS ............................................. 32 CODE F220H: QUERY VECTOR KNOWLEDGE STORE OBJECTS............................................... 35 CODE F221H: QUERY VECTOR KNOWLEDGE STORE FEATURE CLASS METADATA ............ 38 CODE F222H: QUERY VECTOR KNOWLEDGE STORE BOUNDS............................................... 38 CODE F023H: TERMINATE VECTOR KNOWLEDGE STORE DATA TRANSFER ....................... 39 CODE F420H: REPORT VECTOR KNOWLEDGE STORE OBJECT(S) CREATION....................... 40 CODE F421H: REPORT VECTOR KNOWLEDGE STORE FEATURE CLASS METADATA........... 40 CODE F422H: REPORT VECTOR KNOWLEDGE STORE OBJECTS............................................. 41 CODE F423H: REPORT VECTOR KNOWLEDGE STORE BOUNDS............................................. 45 CODE F424H: REPORT VECTOR KNOWLEDGE STORE DATA TRANSFER TERMINATION.... 46

1

1.0 World Model Components As with most JAUS components, the JAUS World Model components have their roots in the JAUS Domain Model (DM). The JAUS DM includes the World Model as one of three classes of components that fall within the Battlemap Knowledge Store. The World Model components are simply described as components that “… maintain all mapping data.” Because the JAUS DM provides a vague definition of the World Model, the newly developed components will be based on the definition of the world model established by Mystel and Albus (see page iii). This document presents an initial draft JAUS message set that will allow JAUS-based unmanned systems to share many types of geospatial data. Over time the world modeling class of components will grow to support more of the functionality described by Mystel and Albus. The mission of the JAUS World Model subcommittee is to develop a common method for sharing geospatial data. The primary purpose for this development is to support mission planning and other future high level tasks within the JAUS framework. The first components to be addressed by the JAUS World Model subcommittee are the world model knowledge stores. These world model knowledge stores are to be the central geospatial data repository for a JAUS component, node, subsystem, or system. They provide only geospatial data storage and access methods; no processing or higher level functionality shall be provided by the knowledge stores. They are the most primitive world modeling components and form the foundation for all future world model components. Within this context, these world model knowledge stores are envisioned as location independent, modular JAUS components. Therefore, it is possible to have multiple subsystems accumulating data in a global world model knowledge store or to have individual subsystems accumulate data in their own world model knowledge stores and then have synchronization of those stores. This proposed JAUS World Model Knowledge Store standard does not impose constraints on the methods used for modeling data internal to the unmanned system, but on how the data are formatted and presented to other JAUS components that use or store geospatial data. This message set is developed to be as flexible as reasonably possible within JAUS. It provides a method for sharing the data at the most primitive levels with minimal complexity. This is very important since past experiments with JAUS interoperability have shown that as component interfaces become more complex, it becomes increasingly difficult to achieve true interoperability. 1.1 Observations and Recommendations from Literature Review A review of world modeling methods used by both the unmanned systems and geographic information systems (GIS) communities showed that there is a considerable amount of commonality between the types of data that are available in a priori data stores and the types of data that may be accumulated in real-time. The main two classes of data types are raster and vector data. Raster data may consist of elevation, geo-

2

referenced orthoimages, density maps, occupancy grids, traversability grids, etc. Vector data may consist of digital road maps, polygon maps, etc. By enforcing some constraints, it is possible to distill these data into a common format that may be used by unmanned systems community. That is the goal of this proposed addendum. In completing this initial specification, a number of key observations were made about the current methods for accessing and sharing real time and a priori geospatial data. These are that:

• The level of complexity of modeling methods designed for a priori data sharing (such as SDTS and GML) is well beyond what is necessary for JAUS based unmanned systems.

• There are a number of different projections that may be used to transform data from geodetic coordinates to a two or two and a half dimensional surface. It is very important that the same projections are used on each end of the data transfer.

• Current world modeling methods are, at their core, based on either raster or vector primitives. For real-time world modeling on unmanned vehicles, raster methods are used most often. Both vector and raster modeling methods are commonly used in a priori data stores.

• Most a priori data stores include metadata which have extra information about the stored data.

Therefore it is recommended that at a minimum the initial JAUS World Model standard should:

• Provide the ability for JAUS based subsystems, nodes, and/or components to

share geospatial data with minimal complexity. • Allow developers some degree of flexibility within the constraints of the

standard. • Specify reference ellipsoids, map projections, and datums to be used within the

knowledge stores. • Allow for use and transfer of a priori and real-time raster and vector data. • Provide a mechanism to allow distinguishing between different types of

geospatial data. • Provide a means for saving and sharing information about the geospatial data

within the knowledge store. • Meet the standard JAUS requirements for definition of new components.

It is very important that geospatial data transferred from different systems use the same map projections, ellipsoidal Earth model, and datums. For global coordinates, JAUS specifies that all systems will use the World Geodetic System 1984 (WGS84). For this proposed addendum, the map projection shall be the Universal Transverse Mercator Projection. Vertical measurements will be based on the vertical datum as established by the ellipsoidal model of the Earth. Since most of the systems will be operating in the United States, the horizontal with be the North American Datum as established in 1983 (NAD83).

3

1.2 World Model Terms In this section, a number of terms specific to JAUS World Modeling are introduced. Feature Class. A feature class represents a categorization of types of geospatial data. For example, occupancy, free space, objects, roads, terrain, building, ortho-images, etc. all represent distinct feature classes. It may be more intuitive to consider these feature classes as different layers of geospatial data within the knowledge store. Predefined feature classes will eventually be established in the interest of interoperability. Since it is not possible to define all types of feature classes a priori, a sizeable amount of space will be set aside for user defined feature classes. While this does have an adverse effect on interoperability, this is mitigated by having system developers provide each other with a data dictionary when they wish to interoperate. The data dictionary is simple a description of which types of data correspond to a feature class identifier. Even with the predefined feature classes, when testing interoperability system developers must establish the data types that they are using within the knowledge store. It is possible that this exchange could be handled during the discovery process provided in the forthcoming JAUS dynamic configuration and registration extensions. Feature Class Metadata. The world model knowledge store framework provides for storage and transfer of feature class metadata. In this context, metadata is simply text that provides general information at about the data within a particular feature class. At the present time, there is no requirement for metadata format. Local Request ID (LRID). The local request identifier (LRID) is a single-byte numerical identifier attached to certain classes of messages originating outside of the world model knowledge store. This feature allows synchronization of messages and their associated response. This is important because even though requests to the knowledge store may be synchronized, there is no guarantee that the responses will be synchronized. By attaching the LRID, the requesting component will be able to internally synchronize any asynchronous responses. Metadata. See Feature Class Metadata. UTM. Universal Transverse Mercator projection, the proposed JAUS World Model standard for defining Cartesian coordinates. WGS84. World Geodetic System 1984, the JAUS adopted standard for defining global coordinates. 1.3 JAUS Core Messages and Component States While the JAUS RA does require that the core input/output message sets be accepted by all components, there is no requirement that components have an action associated with each input message. Because the expected behavior of components while in each state is somewhat ambiguous, they will be defined for the world model knowledge stores.

4

The world model knowledge stores should have an appropriate response to the following messages:

• Code 0002h: Shutdown • Code 0003h: Standby • Code 0004h: Resume • Code 0005h: Reset • Code 0009h: Confirm Service Connection • Code 000Ah: Activate Service Connection • Code 000Bh: Suspend Service Connection • Code 000Ch: Terminate Service Connection • Code 2002h: Query Component Status • Code 4002h: Report Component Status

The Code 0002h: Shutdown message shall cause the receiving knowledge store to immediately terminate all data transfer upon receipt. If the knowledge store is responding to a query, it shall immediately terminate the flow of data and transmit the Code F405h: Report Raster Knowledge Store Data Transfer Termination or the Code F424h: Report Vector Knowledge Store Data Transfer Termination message to the component whose query response was interrupted and to any components with outstanding requests. Upon termination of all data transfer, the world model shall execute its specific shutdown routine and then halt. It shall no longer respond to any data requests and shall require a “hard reset” in order to resume normal operation. The Code 0003h: Standby message shall cause the receiving knowledge store to respond as if it had received the Code 0002h: Shutdown message. The exception is that the knowledge store shall not halt. It shall respond only to the Code 0004h: Resume and Code 0005: Reset messages. Upon resumption to the ready state, the knowledge store shall resume normal operations. It shall not resume any suspended query responses. The Code 0005h: Reset message shall cause the receiving knowledge store to immediately terminate the transfer and processing of any data. The knowledge store shall transmit to all components with outstanding requests or data transfers the Code F405h: Report Raster Knowledge Store Data Transfer Termination or the Code F424h: Report Vector Knowledge Store Data Transfer Termination message. The knowledge store shall them immediately restart and return to the ready state. Terminated data transfers shall not resume. The Codes 0009h: Confirm Service Connection, 000Ah: Activate Service Connection, 000Bh: Suspend Service Connection, 000Ch: Terminate Service Connection, 2002h: Query Component Status and 4002h: Report Component Status messages shall operate as normal.

5

1.4 World Model Raster Knowledge Store (Component ID 30) Function: The function of the World Model Raster Knowledge Store (WMRKS) component is to provide a central repository for system-, subsystem-, node-, and/or component-level raster formatted geospatial data. Inputs:

• The core input message set • Code F000h: Create Raster Knowledge Store Object • Code F001h: Set Raster Knowledge Store Feature Class Metadata • Code F002h: Modify Raster Knowledge Store Object (Cell Update) • Code F003h: Modify Raster Knowledge Store Object (Grid Update) • Code F004h: Delete Raster Knowledge Store Objects • Code F200h: Query Raster Knowledge Store Objects • Code F201h: Query Raster Knowledge Store Feature Class Metadata • Code F202h: Query Raster Knowledge Store Bounds • Code F005h: Terminate Raster Knowledge Store Data Transfer

Outputs:

• The core output message set • Code F400h: Report Raster Knowledge Store Object Creation • Code F401h: Report Raster Knowledge Store Feature Class Metadata • Code F402h: Report Raster Knowledge Store Objects (Cell Update) • Code F403h: Report Raster Knowledge Store Objects (Grid Update) • Code F404h: Report Raster Knowledge Store Bounds • Code F405h: Report Raster Knowledge Store Data Transfer Termination

Description: The World Model Raster Knowledge Store provides a method for storing and sharing raster formatted geospatial data within a JAUS system. Many unmanned systems with perception capabilities use some variant of the local occupancy grid for their internal world model. This local occupancy grid is typically implemented as a tessellated grid where each cell value represents the likelihood of the area covered by the cell is being occupied by an obstacle (or, conversely, of it not occupied by an obstacle). The World Model Raster Knowledge Store is a generalization of such an occupancy grid. This knowledge store is able to support most types of raster data including binary, grey scale, and RGB images; digital elevation model (DEM) data; occupancy and traversability grids; etc. The data within a raster knowledge store shall always maintain a north-east orientation. Raster data in the knowledge store shall be geo-referenced by defining their origin as a single point described by the intersection of a line of latitude and a line of longitude (WGS84). The grid parameters also include the number of rows and columns and the

6

grid resolution. While a grid cell is specified as a point, that point covers an area equal to the grid resolution squared. A Cartesian coordinate system is established at the geo-referenced point. The Cartesian coordinates of the grid cells are derived from the Universal Transverse Mercator (UTM) projection. The grid cells may also be referenced by their row and column offset from the origin point. Figure 1 shows the format of a layer of raster data.

Figure 1 – Raster Object

7

Raster Knowledge Store Input Message Set

Code F000h: Create Raster Knowledge Store Object The Code F000h: Create Raster Knowledge Store Object message is used to create and initialize a layer of feature class data within the raster knowledge store. In order for data to be added to the feature class, the feature class layer must first be created. The origin of the raster grid must be geo-referenced by specifying its origin in fields 4 and 5 as a point of latitude and longitude. Extents of the layer must also be specified as a number of rows and columns in fields 7 and 8. Both the data types that describe the number of rows and columns and the cell attribute type are variable and must also be specified in fields 6 and 11, respectively. The grid cell resolution is also specified in field 9. Because this message is used to create a feature class layer, the feature class must be specified using field 10. This message has a single optional field (field 11). Inclusion of this optional field is determined from the state of bit zero in the message presence vector. If the bit zero is set, then the value in field 12 shall be used to initialize all cells within the feature class. When the feature class layer is initialized using this message, the data are filled in the grid on a row by row basis starting at the southern most row and moving north. It is filled beginning at the southwestern most point moving east. Field # Name Type Units Interpretation 1 Presence

Vector Unsigned Short Integer

N/A See mapping table below

2 Message Properties

Byte N/A Bit Field 0: Request confirmation of object creation 1 – 7: Reserved

3 Local Request ID

Byte N/A Request identifier to be used when returning confirmation to requesting component

4 Origin Latitude (WGS84)

Integer Degrees Scaled Integer Lower Limit = -90 Upper Limit = 90

8

Code F000h: Create Raster Knowledge Store Object message (Continued) 5 Origin

Longitude (WGS84)


6 Raster Data Row and Column Data Type

Byte N/A Enumeration 0: Byte 1: Reserved 2: Reserved 3: Reserved 4: Unsigned Short Integer 5: Unsigned Integer 6: Unsigned Long Integer 7 – 255: Reserved

7 Raster Grid Update Rows

Varies (See field 6)

Grid Cells

8 Raster Grid Update Columns


Grid Cells

9 Cell Resolution

Float Meters

10 Feature Class


N/A Enumeration 0 … 65,534 - See Feature Class Table 65,535 - Reserved

11 Raster Cell Data Type

Byte

N/A Enumeration 0: Byte 1: Short Integer 2: Integer 3: Long Integer 4: Unsigned Short Integer 5: Unsigned Integer 6: Unsigned Long Integer 7: Float 8: Long Float 9: RGB (3 Bytes) 10 – 255: Reserved

12 Initial Value for Raster Grid Cells

Varies (see field 11)

N/A

9


Vector Bit 7 6 5 4 3 2 1 0 Data Field R R R R R R R 12

(“R” indicates that the bit is reserved.) Code F001h: Set Raster Knowledge Store Feature Class Metadata The Code F001h: Set Raster Knowledge Store Feature Class Metadata message allows the creation, modification, or erasure of feature class metadata. The format of these metadata is not specified. It is left to the system designer to develop a convention for doing this. Initially these data are to be used by the human operators. In the future a schema may be defined so as to provide a standard metadata format that may be parsed and the data used by unmanned systems. Field # Name Type Units Interpretation 1 Metadata

Options Byte N/A Enumeration

0: Append 1: Prepend 2: Overwrite 3 – 254: Reserved 255: Erase All

2 Feature Class


N/A Enumeration 0 … 65,534 - See Feature Class Table 65,535 – Reserved

3 Number of String Characters


N/A 0 … 65,535 This field should be equal to zero only when Field 1 is equal to 255 (Erase All)

4 Metadata String N/A Variable length string Code F002h: Modify Raster Knowledge Store Object (Cell Update) The Code F002h: Modify Raster Knowledge Store Object (Cell Update) message is used to change data within a raster knowledge store feature class layer. This message can only be used on a layer that has been created within the raster knowledge store. This method is specified as a cell update version because it allows modification of the raster grid on a cell by cell basis.

10

The origin of the raster grid cell updates must be geo-referenced by specifying their origin in fields 2 and 3 as a point of latitude and longitude. Both the data types that describe the update row and column and cell attribute are variable and must also be specified in fields 4 and 7, respectively. The grid cell update resolution is also specified in field 5. Because this message is used to modify a feature class layer, the feature class must be specified using field 6. The data type for the field that specifies the number of cell updates included in the message (field 9) is also variable and is defined in field 8. Each cell update is a three-tuple representing the cell update’s row, column, and update attribute value. This message has no optional fields. Field # Name Type Units Interpretation 1 Local

Request ID Byte N/A Request identifier to be used

when returning confirmation to requesting component



3 Origin Longitude (WGS84)



Byte N/A Enumeration 0: Byte 1: Short Integer 2: Integer 3: Long Integer 4: Unsigned Short Integer 5: Unsigned Integer 6: Unsigned Long Integer 7 – 255: Reserved

5 Cell Resolution

Float Meters

6 Feature Class



11

Code F002h: Modify Raster Knowledge Store Object message (Continued) 7 Raster Cell

Data Type Byte N/A Enumeration

0: Byte 1: Short Integer 2: Integer 3: Long Integer 4: Unsigned Short Integer 5: Unsigned Integer 6: Unsigned Long Integer 7: Float 8: Long Float 9: RGB (3 Bytes) 10 – 255: Reserved

8 Data Type for Number of Cell Updates


9 Number of Cell Updates


N/A

10 Raster Cell Update 1 Row


N/A

11 Raster Cell Update 1 Col


N/A

12 Raster Cell Update 1 Data


Varies with Feature Class

… … … 3n + 7 Raster Cell

Update n Row


N/A

3n + 8 Raster Cell Update n Col


N/A

12

Code F002h: Modify Raster Knowledge Store Object message (Continued) 3n + 9 Raster Cell

Update n Data



Code F003h: Modify Raster Knowledge Store Object (Grid Update) The Code F003h: Modify Raster Knowledge Store Object (Grid Update) message is similar to the Code F002h: Modify Raster Knowledge Store Object (Cell Update) message in that it permits change of grid cell values. It differs from that method in that rather than transmitting single cell updates, an entire rectangular patch of cells is updated. As the number of cells that need to be modified increases, this method becomes more efficient than the cell update method. The origin of the raster grid update must be geo-referenced by specifying its origin in fields 2 and 3 as a point of latitude and longitude. Both the data types that describe the update row and column and cell attribute are variable and must also be specified in fields 4 and 9, respectively. Fields 5 and 6 specify the number of rows and columns of raster grid updates being transmitted. The grid cell update resolution is also specified in field 7. Because this message is used to modify a feature class layer, the feature class must be specified in field 8. This message has no optional fields. Field # Name Type Units Interpretation 1 Local


when returning confirmation to requesting component





13

Code F003h: Modify Raster Knowledge Store Object message (Continued) 4 Raster Data

Row and Column Data Type




Grid Cells



Grid Cells

7 Cell Resolution

Float Meters

8 Feature Class




Byte N/A Enumeration 0: Byte 1: Short Integer 2: Integer 3: Long Integer 4: Unsigned Short Integer 5: Unsigned Integer 6: Unsigned Long Integer 7: Float 8: Long Float 9: RGB (3 Bytes) 10 – 255: Reserved

10 Raster Cell Update 1


N/A



N/A

… 9 + n Raster Cell

Update n Varies (see field 9)

N/A

10 + n Raster Cell n+1


N/A

14

Code F004h: Delete Raster Knowledge Store Objects The Code F004h: Delete Raster Knowledge Store Object message is used to free all resources allocated to a feature class layer within the raster knowledge store. In order to resume accumulation of data within the deleted feature class, the feature class layer must be recreated using the Create Raster Knowledge Store Object message. The message allows a single feature class or all feature classes to be deleted in one message. Field # Name Type Units Interpretation 1 Presence

Vector Byte N/A See mapping table below

2 Local Request ID


3 Number of Feature Classes


N/A

4 Feature Class 1


N/A Enumeration 0 … 65,534 – See Feature Class Table 65,535 – ALL

… … … … … 3 + n Feature

Class n Unsigned Short Integer

N/A Enumeration 0 … 65,534 – See Feature Class Table 65,535: Reserved

Code F200h: Query Raster Knowledge Store Objects The Code F200h: Query Raster Knowledge Store Objects message provides access to data within the raster knowledge store. Field 1 of this message is the message presence vector. The optional fields in this message are fields 4, 5, and 6. Field 2 is the Query Response Properties bit field. When bit zero is set, the response to the query should only include the number of records that would be returned. When bit one is set, the query response shall be the Code F402h: Report Raster Knowledge Store Objects (Cell Update) message. Otherwise, the Code F403h: Report Raster Knowledge Store Objects (Grid Update) message shall be sent. Field 3 is the message Local Request Identifier. This field allows synchronization of message responses.

15

Field 4 is the Raster Query Resolution. This field allows the querying component to specify the cell resolution to be used in the response to the query. If this resolution does not match the native resolution of the queried knowledge store, then the knowledge store should either sub-sample or interpolate the data to obtain the desired resolution. This field is optional. Field 5 specifies a specific feature class to be queried. This field is optional. If a feature class is not specified, then the query should be done on all feature classes within the knowledge store. Fields 6 through 9 specify two points of latitude and longitude that limit the range of the query. These fields are optional. If presence vector bit two is set, then fields 6 through 9 shall all be included. Otherwise, they should not. Field # Name Type Units Interpretation 1 Presence


2 Query Response Properties

Byte N/A Bit Field 0: Only return number of responses that would be transmitted 1: Return cell update 3 tuples or raster scan (active low) 2 – 7: Reserved

3 Local Request ID

Byte N/A Request identifier to be used when returning data to requesting component

4 Raster Query Resolution

Float Meters

5 Feature Class


N/A Enumeration 0 … 65,534 - See Feature Class Table 65,535 – All Feature Classes

6 Query Region Point 1 Latitude (WGS84)


7 Query Region Point 1 Longitude (WGS84)


16

Code F200h: Query Raster Knowledge Store Objects message (Continued) 8 Query

Region Point 2 Latitude (WGS84)


9 Query Region Point 2 Longitude (WGS84)



Vector Bit 7 6 5 4 3 2 1 0 Data Field R R R R R 6 5 4

(“R” indicates that the bit is reserved.) Code F201h: Query Raster Knowledge Store Feature Class Metadata The Code F201h: Query Raster Knowledge Store Feature Class Metadata message shall cause the Raster Knowledge Store to reply to the requestor with the Code F402h: Report Raster Knowledge Store Feature Class Metadata message with the requested data. There is a single field associated with this message. This field specifies the feature class metadata to return in the reply. There is also an option to return metadata for all feature classes present in the queried raster knowledge store. Field # Name Type Units Interpretation 1 Feature

Class Unsigned Short Integer

N/A Enumeration 0 … 65,534 - See Feature Class Table 65,535 – All

Code F202h: Query Raster Knowledge Store Bounds The Code F202h: Query Raster Knowledge Store Bounds message is used to request the spatial extents of a single feature class or of all feature classes within a raster knowledge store. The knowledge store shall respond with the Code F404h: Report Raster

17

Knowledge Store Bounds message with the requested data. The bounds are represented by two points the represent the rectangular region that just covers all of the data within the feature class layer or layers. Field # Name Type Units Interpretation 1 Local


when returning data to requesting component

2 Feature Class



Code F005h: Terminate Raster Knowledge Store Data Transfer This Code F005h: Terminate Raster Knowledge Store Data Transfer message is a command class message that shall cause the raster knowledge store to immediately terminate the transfer of all current and outstanding data destined to the requesting component. Upon termination, the raster knowledge store shall send the requestor the Code F405h: Report Raster Knowledge Store Data Transfer Termination message.

18

Raster Knowledge Store Output Message Set

Code F400h: Report Raster Knowledge Store Object Creation Message The Code F400h: Report Raster Knowledge Store Object Creation message is used to confirm creation of raster objects in the raster knowledge store. This message is sent only when an object creation message is requested by setting bit zero in the Code F000h: Create Raster Knowledge Store Object message. If this bit is set, this message will be transmitted and the local object identifier (field 1) is set to the value sent with the Code F000h: Create Raster Knowledge Store Raster Object message. Field # Name Type Units Interpretation 1 Local

Request ID Byte N/A Local request identifier sent by

creating component Code F401h: Report Raster Knowledge Store Feature Class Metadata The Code F401h: Report Raster Knowledge Store Feature Class Metadata message allows access to feature class metadata stored within raster knowledge store. It is transferred in response to the Code F201h: Query Raster Knowledge Store Feature Class Metadata message. If the query message requests all feature classes, a separate message shall be sent for each feature class. These metadata are entered using the Code F001h: Set Raster Knowledge Store Feature Class Metadata message. Field # Name Type Units Interpretation 1 Feature


N/A Enumeration 0 … 65,535 - See Feature Class Table



N/A 0 … 65,535

3 Metadata String

N/A Variable length string

19

Code F402h: Report Raster Knowledge Store Objects (Cell Update) The Code F402h: Report Raster Knowledge Store Objects (Cell Update) message is sent in direct response to a Code F200h: Query Raster Knowledge Store Objects message if and only if bit two of the bit field in message field two is set. Otherwise, the Code F403h: Report Raster Knowledge Store Objects (Grid Update) message is transmitted. If bit one of field two of the Code F200h: Query Raster Knowledge Store Objects message is set, then only the first two fields of this message shall be transmitted. Field 1 of this message is Local Request Identifier sent with the query that initiated this report message. Field 2 notifies the receiving component of the number of records included in the report message. Fields 3 and 4 establish the geodetic origin (latitude and longitude) of the cell updates included in the message. Both the data types that describe the update row and column and cell attribute are variable and are specified in fields 5 and 8, respectively. Field 6 is the resolution of the raster grid updates reported in the message. Field 7 is the feature class that raster data are assigned to. There are no optional fields in this message. Field # Name Type Units Interpretation 1 Local

Request ID

Byte N/A Request identifier sent with initial request

2 Number of Responses


N/A 0 … 65,535 Number of Responses Included on this Report Message





20

Code F402h: Report Raster Knowledge Store Objects message (Continued) 5 Raster Data

Row and Column Data Type


6 Cell Resolution

Float Meters

7 Feature Class





9 Data Type for Number of Cell Updates


10 Number of Cell Updates


N/A

21

Code F402h: Report Raster Knowledge Store Objects message (Continued) 11 Raster Cell

Update 1 Row


N/A

12 Raster Cell Update 1 Col


N/A

13 Raster Cell Update 1 Data



… … … 3n + 8 Raster Cell

Update n Row


N/A

3n + 9 Raster Cell Update n Col


N/A

3n + 10 Raster Cell Update n Data



Code F403h: Report Raster Knowledge Store Objects (Grid Update) The Code F403h: Report Raster Knowledge Store Objects (Grid Update) message is sent in direct response to a Code F200h: Query Raster Knowledge Store Objects message if and only if bit two of the bit field in message field two is clear. Otherwise, the Code F402h: Report Raster Knowledge Store Objects (Cell Update) message is transmitted. If bit one of field two of the Code F200h: Query Raster Knowledge Store Objects message is set, then only the first two fields of this message shall be transmitted. Field 1 of this message is Local Request Identifier sent with the query that initiated this report message. Field 2 notifies the receiving component of the number of records included in the report message. Fields 3 and 4 establish the geodetic origin (latitude and longitude) of the cell updates included in the message. Both the data types that describe the update row and column and cell attribute are variable and are specified in fields 5 and 10, respectively.

22

Fields 6 and 7 represent the number of rows and columns of grid update cells. Field 8 is the resolution of the raster grid updates reported in the message. Field 9 is the feature class that raster data are assigned to. There are no optional fields in this message. Field # Name Type Units Interpretation 1 Local

Request ID Byte N/A Request identifier sent with

initial request

2 Number of Responses


N/A 0 … 65,535 Number of Responses Included on this Report Message









Grid Cells



Grid Cells

8 Cell Resolution

Float Meters

9 Feature Class



23

Code F403h: Report Raster Knowledge Store Objects message (Continued) 10 Raster Cell

Data Type Byte N/A Enumeration

0: Byte 1: Short Integer 2: Integer 3: Long Integer 4: Unsigned Short Integer 5: Unsigned Integer 6: Unsigned Long Integer 7: Float 8: Long Float 9: RGB (3 Bytes) 10 – 255: Reserved



N/A



N/A

… 10 + n Raster Cell

Update n Varies (see field 10)

N/A

11 + n Raster Cell n+1


N/A

Code F404h: Report Raster Knowledge Store Bounds The Code F404h: Report Raster Knowledge Store message format is shown below. This message reports the Raster Knowledge Store bounds as a response to the Query Knowledge Store Bounds message. In this message, the raster knowledge store returns the two geographic points that represent the extents of the data within a feature class layer or all feature class layers. Field # Name Type Units Interpretation 1 Local

Request ID Byte N/A Request identifier sent in

query message 2 Feature



3 Southwest Bound Latitude (WGS84)


24

Code F404h: Report Raster Knowledge Store Bounds message (Continued) 4 Southwest

Bound Longitude (WGS84)


5 Northeast Bound Latitude (WGS84)


6 Northeast Bound Longitude (WGS84)


Code F405h: Report Raster Knowledge Store Data Transfer Termination The Code F405h: Report Raster Knowledge Store Data Transfer Termination message notifies other JAUS components that data that were being transferred or were going to be transferred to them has been stopped. This message is sent in response to the Code F005h: Terminate Raster Knowledge Store Data Transfer message. It is also sent whenever data transfer is interrupted due to a change in the component state.

25

1.5 World Model Vector Knowledge Store (Component ID 31) Function: The function of the World Model Vector Knowledge Store (WMVKS) component is to provide a central repository for system-, subsystem-, node-, and/or component-level vector-formatted geospatial data. Inputs:

• The core input message set • Code F020h: Create Vector Knowledge Store Objects • Code F021h: Set Vector Knowledge Store Feature Class Metadata • Code F022h: Delete Vector Knowledge Store Objects • Code F220h: Query Vector Knowledge Store Objects • Code F221h: Query Vector Knowledge Store Feature Class Metadata • Code F222h: Query Vector Knowledge Store Bounds • Code F023h: Terminate Vector Knowledge Store Data Transfer

Outputs:

• The core output message set • Code F420h: Report Vector Knowledge Store Object(s) Creation • Code F421h: Report Vector Knowledge Store Feature Class Metadata • Code F422h: Report Vector Knowledge Store Objects • Code F423h: Report Vector Knowledge Store Bounds • Code F424h: Report Vector Knowledge Store Data Transfer Termination

Description: Storing and sharing of vector formatted geospatial data is supported by the World Model Vector Knowledge Store. The primary benefit of this world modeling method is that vector data typically require significantly less bandwidth to transmit as compared to raster data. For the vector knowledge store, objects are represented as points, lines and polylines, and polygons. The coordinates of these points are defined by a point of latitude and longitude (WGS84). Polylines and polygons may consist of up to 65535 vertices. Figure 2 shows the format of these vector objects. Rather than assigning these points Cartesian coordinates with respect to an arbitrarily chosen datum, all points are expressed as points of latitude and longitude. The vector objects on the right side of the figure have a region buffer parameter. The region buffer is defined as an offset distance in meters. The buffer parameter establishes a radial region around each vector object vertex and connects the radial regions of two or more radial regions by drawing lines at their tangents. The area within these radial regions and tangent lines are considered to be within the vector object’s buffer zone. This buffer feature allows a region to be established in proximity to the vector objects.

26

For example, United States Geological Survey (USGS) digital line graph (DLG) road data is presented in vector form representing the center-line of such roads. It may be useful to search for objects within an area along a particular route defined in the digital line graph data. For simple cases, it may be possible to generate a polygonal representation of the area around the road. Establishing this polygon will require transmitting the coordinates of each of its vertices. As the problem scales up, this method becomes very inefficient. A better solution to this problem would be to determine the route using the DLG data and assign a region buffer to each line segment.

Figure 2 – Vector Objects

27

Vector Knowledge Store Input Message Set

Code F020h: Create Vector Knowledge Store Objects The Code F020h: Create Vector Knowledge Store Objects message is used to add objects to the Vector Knowledge Store. This message allows multiple vector objects to be created using a single message. Field 1 of this message is the presence vector. When multiple objects are created using the same message, the presence vector shall apply to all objects. Field 2 of this message is the creation message properties. If bit zero is set, then the knowledge store shall return the Code F420h: Report Vector Knowledge Store Object(s) Creation message with the local request identifier specified in Field 3. Field 4 indicates the number of vector objects included in the message. Fields 5 is the beginning of the definition of a single vector object. The vector object is defined by its type (point, line, or polygon); the number of feature classes that it is assigned to; an attribute for each feature class; and the global coordinates of each of the vertices for the object. These fields are repeated for each object created using this message. Again, the presence vector applies to each vector object. Field # Name Type Units Interpretation 1 Presence

Vector

Byte N/A See mapping table below

2 Message Properties

Byte N/A Bit Field 0: Request confirmation of object creation 1 – 7: Reserved

3 Local Request ID


4 Number of Objects


0, reserved 1 … 65,535

28

Code F020h: Create Vector Knowledge Store Objects message (Continued) 5 Object 1

Type Byte N/A Enumeration

0: Point 1: Line 2: Polygon 3 – 255: Reserved

6 Object 1 Buffer

Float Meters

7 Object 1 Number of Feature Classes

Byte N/A

8 Object 1 Feature Class 1



9 Object 1 Feature Class 1 Attribute Data Type


10 Object 1 Feature Class Attribute 1



… … … … … … … … … … … … … … … 5+3m Object 1

Feature Class m



29

Code F020h: Create Vector Knowledge Store Objects message (Continued) 6+3m Object 1

Feature Class m Attribute Data Type


7+3m Object 1 Feature Class Attribute m

Varies (see previous field)


8+3m Number of Points for Object 1


N/A

9+3m Object 1 Point 1 Latitude (WGS84)


10+3m Object 1 Point 1 Longitude (WGS84)


… … … … … … … … 7+3m+2n Object 1

Point n Latitude (WGS84)


8+3m+2n Object 1 Point n Longitude (WGS84)


30

Code F020h: Create Vector Knowledge Store Objects message (Continued) Object p

Type Byte N/A Enumeration

0: Point 1: Line 2: Polygon 3 – 255: Reserved

Object p Buffer

Float Meters

Object p Number of Feature Classes

Byte N/A

Object p Feature Class 1



Object p Feature Class 1 Attribute Data Type


Object p Feature Class Attribute 1



… … … … … … … … … … … … … … … Object p

Feature Class m



31

Code F020h: Create Vector Knowledge Store Objects message (Continued) Object p

Feature Class m Attribute Data Type


Object p Feature Class Attribute m



Number of Points for Object p


N/A

Object p Point 1 Latitude (WGS84)


Object p Point 1 Longitude (WGS84)


… … … … … … … … Object p

Point r Latitude (WGS84)


Object p Point r Longitude (WGS84)


32

Vector to Data Field Mapping for Above Command Vector Bit 7 6 5 4 3 2 1 0 Data Field R R R R R R R 6

(“R” indicates that the bit is reserved.) Code F021h: Set Vector Knowledge Store Feature Class Metadata The Code F021h: Set Vector Knowledge Store Feature Class Metadata message allows the creation, modification, or deletion of feature class metadata. The format of these metadata is not specified. It is left to the system designer to develop a convention for doing this. Initially these data are to be used by the human operators. In the future a convention may be established in this document. Field # Name Type Units Interpretation 1 Metadata

Options Byte N/A Enumeration

0: Append 1: Prepend 2: Overwrite 3 – 254: Reserved 255: Erase All

2 Feature Class





N/A 0 … 65,535 This field should be equal to zero only when Field 1 is equal to 255 (Erase All)

4 Feature Class Metadata

String N/A Variable length string

Code F022h: Delete Vector Knowledge Store Objects The Code F022h: Delete Vector Knowledge Store Objects message allows the removal of objects from the vector knowledge store. This message allows multiple vector objects to be deleted using a single message. Field # Name Type Units Interpretation 1 Presence


33

Code F022h: Delete Vector Knowledge Store Objects message (Continued) 2 Local



3 Number of Object IDs (p)


N/A

4 Object ID 1 Unsigned Integer

N/A

… … … … … 3+p Object ID p Unsigned

Integer

N/A

4+p Region Type

Byte N/A Enumeration 0: Point 1: Line 2: Polygon 3 – 255: Reserved

5+p Region Buffer

Float Meters

6+p Number of Feature Classes (n)

Byte N/A

7+p Feature Class 1



8+p Feature Class 1 Attribute Data Type


34

Code F022h: Delete Vector Knowledge Store Objects message (Continued) 9+p Feature

Class Attribute 1



… … … … … … … … … … … … 7+p+3n Feature



8+p+3n Feature Class n Attribute Data Type


9+p+3n Feature Class Attribute n



10+p+3n Number of Region Points (m)


N/A 0, reserved 1 … 65,535

11+p+3n Deletion Region Point 1 Latitude (WGS84)


12+p+3n Deletion Region Point 1 Longitude (WGS84)


35

Code F022h: Delete Vector Knowledge Store Objects message (Continued) … … … … … … … … Deletion

Region Point m Latitude (WGS84)


Deletion Region Point m Longitude (WGS84)



Vector Bit 7 6 5 4 3 2 1 0 Data Field R 10+p+3n 8+3n 7+p 6+p 5+p 4+p 3

(“R” indicates that the bit is reserved.)

Code F220h: Query Vector Knowledge Store Objects The Code F220h: Query Vector Knowledge Store Objects message allows the access to objects within the vector knowledge store. Field # Name Type Units Interpretation 1 Presence

Vector

Byte N/A See mapping table below

2 Presence Vector

Byte N/A Query Response Presence Vector. See Code F4220h: Report Vector Knowledge Store Objects message for Presence Vector format.

3 Local Request ID

Byte N/A Request identifier to be used when returning data to requesting component

36

Code F220h: Query Vector Knowledge Store Objects message (Continued) 4 Number of

Object IDs (p)


N/A


N/A


Integer

N/A

5+p Region Type


6+p Region Buffer

Float Meters

7+p Number of Feature Classes (n)

Byte N/A

8+p Feature Class 1



9+p Feature Class 1 Attribute Data Type


10+p Feature Class Attribute 1



37

Code F220h: Query Vector Knowledge Store Objects message (Continued) … … … … … … … … … … … … 8+p+3n Feature



9+p+3n Feature Class n Attribute Data Type


10+p+3n Feature Class Attribute n



11+p+3n Number of Region Points (m)


N/A 0, reserved 1 … 65,535

12+p+3n Query Region Point 1 Latitude (WGS84)


13+p+3n Query Region Point 1 Longitude (WGS84)


… … … … … … … …

38

Code F220h: Query Vector Knowledge Store Objects message (Continued) Query

Region Point m Latitude (WGS84)


Query Region Point m Longitude (WGS84)



Vector Bit 7 6 5 4 3 2 1 0 Data Field R 11+p+3n 9+3n 8+p 7+p 6+p 5+p 4

(“R” indicates that the bit is reserved.) Code F221h: Query Vector Knowledge Store Feature Class Metadata The Code F221h: Query Vector Knowledge Store Feature Class Metadata message shall cause the Vector Knowledge Store to reply to the requestor with the Code F421h: Report Vector Knowledge Store Feature Class Metadata message with the requested data. There is a single field associated with this message. This field specifies the feature class metadata to return in the reply. There is also an option to return metadata for all feature classes present in the queried vector knowledge store. Field # Name Type Units Interpretation 1 Feature



Code F222h: Query Vector Knowledge Store Bounds The Code F222h: Query Vector Knowledge Store Bounds message is used to request the spatial extents of a single feature class or of all feature classes within a vector knowledge store. The knowledge store shall respond with the Code F423h: Report Vector Knowledge Store Bounds message. The bounds are represented by two points the

39

represent the rectangular region that just covers all of the data within the feature class layer or layers. Field # Name Type Units Interpretation 1 Local



2 Feature Class



Code F023h: Terminate Vector Knowledge Store Data Transfer This Code F023h: Terminate Vector Knowledge Store Data Transfer message is a command class message that shall cause the vector knowledge store to immediately terminate the transfer of all current and outstanding data destined to the requesting component. Upon termination, the vector knowledge store shall send the requestor the Code F424h: Report Vector Knowledge Store Data Transfer Termination message.

40

Vector Knowledge Store Output Message Set

Code F420h: Report Vector Knowledge Store Object(s) Creation The Code F420h: Report Vector Knowledge Store Object Creation message is used to confirm creation of objects in the vector knowledge store. This message is sent only when an object creation message is requested by setting bit zero in the Code F020h: Create Vector Knowledge Store Object message. If this bit is set, this message will be transmitted and the local object identifier (field 1) is set to the value sent with the Code F020h: Create Vector Knowledge Store Object message. Field # Name Type Units Interpretation 1 Local

Request ID Byte N/A Local request identifier sent by

creating component 2 Number of

Object IDs (p)


N/A


0x00000000 Invalid Object ID This value is used to inform the remote component that, for some reason, the corresponding object could not be created.


Integer 0x00000000 Invalid Object ID

This value is used to inform the remote component that, for some reason, the corresponding object could not be created.

Code F421h: Report Vector Knowledge Store Feature Class Metadata The Code F421h: Report Vector Knowledge Store Feature Class Metadata message allows access to feature class metadata stored within the vector knowledge store. It is transferred in response to the Code F221h: Query Vector Knowledge Store Feature Class Metadata message. If the query message requests all feature classes, a separate message shall be sent for each feature class. These metadata are entered using the Code F021h: Set Vector Knowledge Store Feature Class Metadata message.

41

Field # Name Type Units Interpretation 1 Feature


N/A Enumeration 0 … 65,535 See Feature Class Table



N/A 0 … 65,535

3 Feature Class Metadata

String N/A Variable length string

Code F422h: Report Vector Knowledge Store Objects The Code F422h: Report Vector Knowledge Store Objects message is sent in direct response to a Code F220h: Query Vector Knowledge Store Objects message. Field # Name Type Units Interpretation 1 Presence

Vector Byte N/A Bit Field

Bit 0: Data are included after field 3. This is based on the presence vector received in the Code F220h: Query Vector Knowledge Store Objects Message. If data are present after field 3, this bit should be set. Bits 1-7: Reserved

2 Local Request ID

Byte N/A Request identifier sent in query message

3 Number of Objects


N/A 0 … 65,535 Number of Objects in Response to Query Message

4 Object 1 ID Unsigned Integer

N/A 0x00000000 – Reserved

5 Object 1 Type


6 Object 1 Buffer

Float Meters

42

Code F422h: Report Vector Knowledge Store Objects message (Continued) 7 Object 1

Number of Feature Classes

Byte N/A

8 Object 1 Feature Class 1



9 Object 1 Feature Class 1 Attribute Data Type


10 Object 1 Feature Class Attribute 1



… … … … … … … … … … … … … … … Object 1

Feature Class m



Object 1 Feature Class m Attribute Data Type


43

Code F422h: Report Vector Knowledge Store Objects message (Continued) Object 1

Feature Class Attribute m



Number of Points for Object 1


N/A

Object 1 Point 1 Latitude (WGS84)


Object 1 Point 1 Longitude (WGS84)


… … … … … … … … Object 1

Point n Latitude (WGS84)


Object 1 Point n Longitude (WGS84)


Object p ID Unsigned Integer

N/A 0x00000000 – Reserved

Object p Type


Object p Buffer

Float Meters

Object p Number of Feature Classes

Byte N/A

44

Code F422h: Report Vector Knowledge Store Objects message (Continued) Object p

Feature Class 1



Object p Feature Class 1 Attribute Data Type


Object p Feature Class Attribute 1



… … … … … … … … … … … … … … … Object p

Feature Class m



Object p Feature Class m Attribute Data Type


Object p Feature Class Attribute m



45

Code F422h: Report Vector Knowledge Store Objects message (Continued) Number of

Points for Object p


N/A

Object p Point 1 Latitude (WGS84)


Object p Point 1 Longitude (WGS84)


… … … … … … … … Object p

Point r Latitude (WGS84)


Object p Point r Longitude (WGS84)


Code F423h: Report Vector Knowledge Store Bounds The Code F423h: Report Vector Knowledge Store Bounds message format is shown below. This message reports the bounds as a response to the Query Vector Knowledge Store Bounds message. In this message, the knowledge store returns the two geographic points that represent the extents of the data within a feature class layer or all feature class layers. Field # Name Type Units Interpretation 1 Local

Request ID

Byte N/A Request identifier sent in query message

2 Feature Class



46

Code F423h: Report Vector Knowledge Store Bounds message (Continued) 3 Southwest

Bound Latitude (WGS84)


4 Southwest Bound Longitude (WGS84)


5 Northeast Bound Latitude (WGS84)


6 Northeast Bound Longitude (WGS84)


Code F424h: Report Vector Knowledge Store Data Transfer Termination The Code F424h: Report Vector Knowledge Store Data Transfer Termination message notifies other JAUS components that data that were being transferred or were going to be transferred to them has been stopped. This message is sent in response to the Code F025h: Terminate Vector Knowledge Store Data Transfer message. It is also sent whenever data transfer is interrupted due to a change in the component state.

Mission Planning Subcommittee / Task Group Mission Planning Components Document DRAFT

2



Mission Spooler Interface

Version 0.5

September 10, 2004


3

REVISION HISTORY

REV Description of Change Author Date Draft 1 First Draft

Draft 2

“Node” changed to “Task” Rewording of the Unique ID paragraph in the Mission

Spooler Description section Spool Mission message field 5 and 6 type change Rewording in message explanations for clarification

Draft 3

Added Mission Name field to Spool Mission message Added Time to the Spool Type enumeration in the Report

Spooling Preferences message Added Messaging Guidelines section to the Mission Spooler

component Removed Event Setup / Notification messages Added Query / Report Mission Status message

Sarah Gray 23 March 2005

Draft 4 Removed anything that was not message specific and implied implementation Sarah 28 April 2005

Draft 5

Changes from OPC 2.5: Remove Mission Name field from Spool Mission message Add a Unique ID field before each JAUS message instead of

using the JAUS header sequence number for the unique ID Changed Child Task ID field from Byte to Unsigned Short in

Spool Mission message Changed Mission ID field in messages from Byte to

Unsigned Short Updated Field numbers in all messages Moved Number of Messages field in Spool Mission message Added the Append Flag field to the Spool Mission message

Sarah 25 August 2005

Mission Planning Components Mission Planner (Component ID X)

Function: Inputs / Outputs:

• The core message set Description:

Mission Spooler (Component ID 36) Function:


4

The Mission Spooler provides a central location for mission plans during execution. It is responsible for parceling out elements of the mission plan for execution by machine primitives.

Inputs / Outputs:

• The core input message set

• Code D010h: Spool Mission*

• Code D011h: Abort Mission

• Code D012h: Pause Mission

• Code D013h: Resume Mission

• Code D014h: Remove Messages

• Code D015h: Replace Messages

• Code D210h: Query Spooling Preference*

• Code D410h: Report Spooling Preference**

• Code D211h: Query Mission Status*

• Code D411h: Report Mission Status** * New input message for any component that may be involved in a mission plan (i.e. path segment driver, waypoint driver, vector driver, payload component, primitive manipulator, etc.) * New output message for any component that may be involved in a mission plan

Description:

The Mission Spooler is responsible for spooling mission plans. A mission is a set of JAUS commands to be performed by one or more unmanned subsystems. The mission structure is an N-ary tree, which allows for parallel, sequential, iterative, conditional, and coordinated mission plans. Each mission has a unique ID allowing for multiple mission plans. A mission plan is made up of tasks, which contain JAUS messages, and/or children tasks. An example mission plan and corresponding mission structure follows:

Mission Plan 0: Task Plan 1: Vehicle 1 Waypoint 1 Path Segment 1*

Path Segment 2* Task Plan 2: Vehicle 2 Waypoint 1

Path Segment 1* Vehicle 3 Waypoint 1 Path Segment 1* Path Segment 2*

*A waypoint, in this example, is broken down into path segments by a higher level component (i.e. mission planner)

T0 # Messages = 0 # Children = 2


Set Path Segment 1 Set Path Segment 2


Set Path Segment 1


Set Path Segment 1 Set Path Segment 2


5

The mission plan above involves 3 vehicles. Vehicle 1 is performing its task in parallel to Vehicle 2 and Vehicle 3 performing their tasks sequentially.

A JAUS message within a mission plan can be blocking. The Mission Spooler shall not spool messages beyond a blocking JAUS message until it has been completed and a Mission Status message with the Message Finished status is received for that message. Payload commands are a good example of where blocking messages may be used. Some payloads can only perform their functions (e.g. soil sampling, video image) when the unmanned platform is stationary while other payloads can perform their functions (e.g. start mine flail) while in motion. The blocking flag ensures that no other messages are spooled until the blocking message is complete.


6

Example configurations of the Mission Spooler follow:

Example 1

Example 2

Subsystem 1: Operator Control Unit (OCU) Mission Planner (MP) Mission Spooler (MS) Subsystem 2: Mission Spooler (MS) Visual Sensor (VS) Path Segment Driver (PSD) Subsystem 3: Waypoint Driver (WD)

The Mission Spooler on Subsystem 1 is coordinating multiple mission plans for two unmanned systems. In the case of Subsystem 2, it sends the mission plan on to the Mission Spooler located on that subsystem which then parcels the plan elements out to the correct component. Subsystem 3 does not have a Mission Spooler available, so Subsystem 1’s Mission Spooler parcels the plan elements out to the correct components on Subsystem 3.

Primitive Manipulator

Spool Mission

Planner

Mission Spooler

Spool Mission Event setups/notifications

Waypoint Driver

Subsystem 1

OCU

MP

MS

Subsystem 3

WD

Subsystem 2

VS

PSD MS


7

Messaging Guidelines:

The following guidelines shall be followed: • The Mission Spooler shall not spool messages beyond a blocking message

until a Report Mission Status message for Message Finished is received for the blocking message.

Guidelines for unsupported Mission Spooler messages:

• If a component does not respond to the Query Spooling Preferences message, the Mission Spooler shall default to sending a Spool Mission message with 1 message at a time to the component.

• If a component does not support the Spool Mission message, the Mission Spooler shall default to sending the raw JAUS message to the component, 1 message at a time.


8

Message Definitions Code D010h: Spool Mission

The Spool Mission message is used to send complex missions to lower level

components (Mission Spoolers, Drivers, etc.). The amount of data in one Spool

Mission message is determined by the receiving component’s spooling preferences.

If a component can handle ten (10) JAUS messages at a time, then the spooling

component shall send a Spool Mission message with no more than ten (10) messages.

Spool Mission messages to lower level components (i.e. drivers) shall only contain

JAUS messages that are specifically addressed to that lower level component. Hence,

a Spool Mission message to a lower level component is reduced to a “list” of JAUS

commands addressed to that component.

The Mission ID field shall be a unique ID to allow for spooling and manipulating

multiple missions at a time.

The Append Flag field indicates if the mission is a new mission that shall replace the

existing mission or if the mission shall be appended to the existing mission.

The remaining fields define the mission plan, where the mission plan structure is an

N-ary tree. The Child Index field shall aide in parsing the N-ary tree. It is the byte

index into this message where that child’s information begins. A Child Task’s

information begins where its Task ID is defined.

Field # Name Type Units Interpretation 1 Mission ID Unsigned

Short N/A Unique Mission ID

2 Append Flag Byte N/A 0 = Replace current mission with new mission 1 = Append new mission to current mission

3 Task (1) ID Unsigned Short

N/A Unique Task ID

4 Number of Children

Unsigned Short

N/A Number of children tasks for Task (1)

4+n Child (1) Index Unsigned Integer

N/A The byte index into this message that Task (1)’s Child (1) begins (used for parsing)

…


9

5+n Number of Messages

Unsigned Short

N/A Number of messages in Task (1)

3+n+3m UID Unsigned Short

N/A Unique identifier for each JAUS message.

4+n+3m JAUS Message JAUS Message

N/A JAUS message (including the 16 byte message header) to be spooled. If Task (1) does not have any messages, this field does not exist

5+n+3m Blocking Byte N/A Indicates whether the above message is blocking. If Task (1) does not have any messages, this field does not exist. 0 = non-blocking 1 = blocking 2 – 255 Reserved

… 6+n+3m Child Task (1)

ID Unsigned

Short N/A Unique Child Task (1) ID (Field

4+n Child (1) Index contains the byte index to this field)

7+n+3m Child Task (1) Number of Children

Unsigned Short

N/A Number of children tasks for Task (1) Child Task (1)

8+n+3m Child of Child Task (1) Index

Unsigned Integer

N/A The byte index into this message that Task (1)’s Child Task (1) begins (used for parsing)

… Recursive tree for N Child Tasks

Code D011h: Abort Mission

Receipt of the Abort Mission message tells the component to abort, or delete, the mission with Mission ID.


Short N/A Unique mission ID

Code D012h: Pause Mission

Receipt of the Pause Mission message tells the component to pause the mission with Mission ID.




10

Code D013h: Resume Mission

Receipt of the Resume Mission message tells the component to resume the mission

with Mission ID.



Code D014h: Remove Messages

The Remove Messages message allows a component to remove any number of

messages from an existing mission with Mission ID. The message(s) to be removed

are referenced by their Unique ID. All JAUS messages with the corresponding UIDs

in the mission shall be removed. If a message to be removed no longer exists in the

mission, no action occurs as this indicates that the JAUS message has already been

removed from the mission.


Short N/A Unique ID of the mission the

message to be removed is part of

1+n UID Unsigned Short

NA Unique ID of the message to be removed

…

Code D015h: Replace Messages

The Replace Messages message allows a component to replace any number of

messages from the mission with Mission ID with new messages. The messages to be

removed are referenced by their Unique ID. If a message to be removed no longer

exists in the mission, this indicates that the JAUS message has already been removed

from the mission and no action shall be taken to remove the message. The

replacement messages shall be inserted into the mission at the location of the

removed messages.




11

2 Remove Number

Unsigned Short

NA The number of messages to remove

2+n UID Unsigned Short

N/A Unique ID of the message to be replaced

… 3+n Replace

Number Unsigned

Short N/A The number of messages to insert

1+n+3m UID Unsigned Short

N/A Unique ID of the message to be replaced

2+n+3m JAUS Message

JAUS Message

N/A Message to insert

3+n+3m Blocking Byte N/A 0 = non-blocking 1 = blocking 2 – 255 Reserved

…

Code D210h: Query Spooling Preference

The spooling component shall send a Query Spooling Preference message to every component utilized in a mission plan that is ready to be spooled. Spooling preferences indicate how components want the commands spooled to them. The receiving component shall respond with a Report Spooling Preference message.

Code D410h: Report Spooling Preference

A Report Spooling Preference message is sent in response to a Query Spooling Preference message. This message indicates how components want commands to be spooled to them. A discrete number of commands, a desired distance worth of commands, or a specified time worth of commands can be spooled. If the Spool Type is set to Count, then the data field indicates how many commands to send in each Spool Mission message. If the Spool Type is set to Distance, then the data field indicates how many meters worth of commands to send in each Spool Mission message. If the commands in the mission are Set Path Segment messages, the distance of each path segment is summed up until the distance is obtained and the corresponding Set Path Segment commands are spooled. If the Spool Type is set to Time, then the data field indicates how many seconds worth of commands to send in each Spool Mission message. A Minimum and Maximum spooling preference can be defined by all components. A minimum spool of 2 and a maximum of 10 requires the Mission Spooler to make sure a component always knows about the next 2 JAUS messages in a mission, but not to exceed the next 10 JAUS messages.

Field # Name Type Units Interpretation 1 Spool Type Byte N/A 0 = Count

1 = Distance 2 = Time 3 – 255 Reserved


12

2 Minimum Integer N/A if Spool Type

= 0

Meters if Spool Type

= 1

Seconds if Spool Type

= 2

If spool type is 0, this value shall indicate how many messages a component prefers. If spool type is 1, this value shall indicate the distance in meters a component prefers. Scaled Integer Lower Limit = 0 Upper Limit = 35,000 If spool type is 2, this value shall indicate the time in seconds a component prefers. Scaled Integer Lower Limit = 0 Upper Limit = 10,000

3 Maximum Integer See Field 2 Units

See Field 2 Interpretation

Code D211h: Query Mission Status

Receipt of the Query Mission Status message shall result in the receiving component

responding with the Report Mission Status message. The Query Type can be

Mission, Task, or Message. The ID field allows a component to query the status of a

specific Mission, Task, or Message. An ID field of 0 indicates the current Mission(s),

Task(s), or Message(s)

Field # Name Type Units Interpretation 1 Type Byte N/A 0 = Mission

1 = Task 2 = Message 3 – 255 Reserved

2 ID Unsigned Short

N/A Unique ID of the Mission, Task, or Message. ID = 0 indicates the current Mission(s), Task(s), or Message(s)

Code D411h: Report Mission Status

The Report Mission Status message is sent in response to the Query Mission Status

message to inform the recipient of the status of a Mission, Task, or Message within a

Mission.


13

The Type field indicates whether the status refers to a Mission, Task, or Message.

The following fields indicate the specific Mission, Task, or Message the status refers

to.

Field # Name Type Units Interpretation 1 Type Byte N/A 0 = Mission

1 = Task 2 = Message 3 – 255 Reserved

2 Status Byte N/A 0 = Spooling 1 = Paused 2 = Aborted 3 = Finished 4 – 255 Reserved

3 Secondary Status Byte N/A 0 = Non-Error condition 1 = Lost component control 2 = Tolerance not met 3 – 255 Reserved

4 Mission ID Unsigned Short

N/A Unique Mission ID

5 Task ID Unsigned Short

N/A Unique Task ID (If Type = 0, Task ID = 0)

6 Message Sequence Number

Unsigned Short

N/A Sequence number of the message finished (If Type = 0 or 1, Message Sequence = 0)


14

Message Sequence Diagrams

Spool Mission message using the Append Flag = False (“sliding window” method)


15

Spool Mission message using the Append Flag = True

OPC Experiment 3.0 Interface Control Document v1.0 3.0 Overview.pdf · 0.1 8/28/05 Initial release...

Documents

Transcript of OPC Experiment 3.0 Interface Control Document v1.0 3.0 Overview.pdf · 0.1 8/28/05 Initial release...