Attachment_0039_-_RAS-G_IOP_V2_-_JAUS_Profiling_Rules.pdf

Robotics and Autonomous Systems – Ground (RAS-G) Interoperability Profile (IOP)

JAUS Profiling Rules Version 2.0

Project Manager, Force Projection (PM FP)

SFAE-CSS-FP MS 401

6501 East 11 Mile Road

Warren, MI 48397

February 2016

Distribution A: Approved for Public Release

Contents 1 Scope

2 Source Documents

2.1 Government Documents

2.2 Non-Government Documents

3 Key Concepts and Information

3.1 Definitions

3.2 Key Concepts and Rules

3.2.1 Interoperability Attributes

3.2.2 Requirements

3.2.3 Parameters

3.2.4 Grouping Together Interoperability Attributes - the Node

3.2.5 Periodicity Requirements

3.2.6 JAUS Hierarchy Rules

3.2.7 Component Targets

4 Core Section

4.1 Core Software and Logical Attribute

4.2 Core JAUS Attribute

4.2.1 Component and Service Requirements

4.2.2 Core Services Basic Requirements

4.3 Access Control Attribute

4.3.1 Component and Service Requirements

4.3.2 Authority Code Organization Requirement

4.3.3 Default Authority Requirement

4.3.4 Access Control Timeout Requirement

4.3.5 Mutually Exclusive Access Control Requirement

4.4 ID Assignment and Propagation

4.4.1 ID Assignment and Propagation Attribute

4.4.2 Subsystem ID Assignment

4.4.3 Subsystem ID Propagation

4.4.4 Node ID Assignment

4.5 Transport Section

4.5.1 Transport Attribute

4.5.2 JUDP Attribute

4.5.3 JTCP Attribute

4.5.4 Custom Transport Attribute

4.6 Component Liveness Attribute

4.6.1 Component and Service Requirements

4.6.2 Liveness Requirement

5 Global Attribute Section

5.1 Global Attribute

5.2 Pose and Attitude Attributes

5.2.1 Pose And Attitude Attribute

5.2.2 Basic Global Position and Attitude Attribute

5.2.3 Basic Local Position and Attitude Attribute

5.2.4 Local Path Reporting Attribute

5.2.5 Global Path Reporting Attribute

5.3 Power Plant Management Attribute

5.3.1 Component and Service Requirements

5.3.2 Power Plant Management Requirement

5.4 Preset Pose Attribute

5.4.1 Component and Service Requirements

5.4.2 Preset Pose Requirement

5.5 Render Useless Attribute

5.5.1 Component and Service Requirements

5.5.2 Render Useless Requirement

5.6 Tamper Detection Attribute

5.6.1 Component and Service Requirements

5.6.2 Tamper Detection Requirement

5.7 Odometry Attribute

5.7.1 Component and Service Requirements

5.7.2 Odometry Requirement

5.8 Health Attribute

5.9 Health Reporter Attribute

5.9.1 Component and Service Requirements

5.9.2 Health Reporter Requirement

5.10 Filtered Action Attribute

5.10.1 Component and Service Requirements

5.10.2 Filtered Action Requirement

5.11 Obstacle Reporting Attribute

5.11.1 Component and Service Requirements

5.11.2 Obstacle Reporting Requirement

5.12 Physical Specification Attribute

5.12.1 Component and Service Requirements

5.13 Software Version Reporting Attribute

5.13.1 Component and Service Requirements

6 Platform Attributes

6.1 Platform Attribute

6.2 Platform Management Section

6.2.1 No Platform Manager Attribute

6.2.2 Platform Management Attribute

6.2.3 Advanced Platform Management Attribute

6.2.4 Digital Resource Discovery Attribute

6.2.5 Platform Mode Attribute

6.2.6 Platform State Attribute

6.3 Enhanced Access Control Attribute

6.3.1 Component and Service Requirements

6.3.2 Enhanced Access Control Requirement

6.4 Stability Control Attribute

6.4.1 Component and Service Requirements

6.4.2 Stability Control Requirement

6.5 Automated Behaviors

6.5.1 No Automated Behaviors Attribute

6.5.2 Basic Automated Behaviors Attribute

6.5.3 Advanced Automated Behaviors Attribute

7 Mobility Section

7.1 Mobility Attribute

7.1.1 Component and Service Requirements

7.1.2 Drive Timeout Requirement

7.1.3 Core Mobility Component

7.1.4 Emergency Stop Safety Requirement

7.2 Platform Specification Attribute

7.2.1 Component and Service Requirements

7.2.2 Platform Specification Requirement

7.3 Teleoperation Attribute

7.3.1 Teleoperation Requirement

7.4 Velocity State Driver Attribute

7.4.1 Component and Service Requirements

7.4.2 Velocity State Driver Requirement

7.5 Vector Driver Attribute

7.6 Local Vector Driver Attribute

7.6.1 Component and Service Requirements

7.7 Global Vector Driver Attribute

7.7.1 Component and Service Requirements

7.8 Ackerman Steering Attribute

7.8.1 Component and Service Requirements

7.8.2 Ackerman Steering Requirement

7.9 Skid Steer Attribute

7.9.1 Component and Service Requirements

7.9.2 Skid Steer Requirement

7.10 Gear Attribute

7.10.1 Component and Service Requirements

7.10.2 Gear Requirement

7.11 Stabilizer Attribute

7.11.1 Component and Service Requirements

7.11.2 Stabilizer Requirement

7.12 Remote Control Attribute

7.12.1 Component and Service Requirements

7.12.2 Remote Control Requirement

8 Autonomy and Behaviors Attributes

8.1 Autonomy and Behaviors Attribute

8.2 Basic Navigation

8.2.1 Waypoint Navigation Attribute

8.2.2 Global Basic Navigation Attribute

8.2.3 Local Basic Navigation Attribute

8.2.4 Global Enhanced Navigation Attribute

8.2.5 Local Enhanced Navigation Attribute

8.3 Leader Follower

8.3.1 Leader/Follower Attribute

8.3.2 Leader Attribute

8.3.3 Follower Attribute

8.4 Retrotraverse Attribute

8.4.1 Component and Service Requirements

8.4.2 Retrotraverse Requirement

8.5 Guarded Teleop Attribute

8.5.1 Component and Service Requirements

8.5.2 Guarded Teleop Requirement

8.6 Lost Comms Management Attribute

8.6.1 Component and Service Requirements

8.6.2 Lost Comms Management Requirement

8.7 Global Path Segment Driver Attribute

8.7.1 Component and Service Requirements

8.8 Local Path Segment Driver Attribute

8.8.1 Component and Service Requirements

9 Payload Section

9.1 Sensor Section

9.1.1 Sensor Attribute

9.1.2 Video Attribute

9.1.3 Digital Video Attribute

9.1.4 Digital Video Pull Attribute

9.1.5 Digital Video Push Attribute

9.1.6 H264 Video Encoding Attribute

9.1.7 Analog Video Attribute

9.1.8 Pan Tilt Video Sensor Attribute

9.1.9 Still Image Attribute

9.1.10 Range Finder Attribute

9.1.11 Microphone Attribute

9.1.12 Microphone Pull Attribute

9.1.13 Microphone Push Attribute

9.1.14 Tire Pressure System Attribute

9.1.15 Acceleration State Sensor Attribute

9.1.16 Velocity State Sensor Attribute

9.1.17 Force/Torque Sensor Attribute

9.2 Emitters Section

9.2.1 Emitter Attribute

9.2.2 Illumination Attribute

9.2.3 Camera Lights Attribute

9.2.4 Speaker Attribute

9.2.5 Speaker Pull Attribute

9.2.6 Speaker Push Attribute

9.2.7 Debris Blower Attribute

9.3 Actuators Section

9.3.1 Actuator Attribute

9.3.2 Pan Tilt Manipulator Attribute

9.3.3 Basic Manipulator Attribute

9.3.4 Pan Tilt Actuator Attribute

9.3.5 Mast Actuator Attribute

9.3.6 Advanced Manipulator Attribute

9.3.7 Pan Tilt Manipulator Position Control Attribute

9.3.8 Pan Tilt Manipulator Velocity Control Attribute

9.3.9 Pan Tilt Manipulator Velocity Sensor Attribute

9.3.10 Pan Tilt Manipulator Position Sensor Attribute

9.3.11 Manipulator Joint Velocity Control Attribute

9.3.12 Manipulator Joint Position Control Attribute

9.3.13 Manipulator Joint Velocity Sensor Attribute

9.3.14 Manipulator Joint Position Sensor Attribute

9.3.15 Manipulator End Effector Velocity Control Attribute

9.3.16 Manipulator End Effector Velocity State Sensor Attribute

9.3.17 Manipulator Joint Force/Torque Sensor Attribute

9.3.18 Manipulator Joint Force/Torque Driver Attribute

9.3.19 Basic End Effector Attribute

9.3.20 Complex End Effector Attribute

9.3.21 Windshield Wiper Attribute

9.3.22 Door Lock System Attribute

9.3.23 Self-Collision Avoidance Attribute

9.3.24 Centralized Self-Collision Avoidance Attribute

9.3.25 Distributed Self-Collision Avoidance Attribute

9.3.26 Manipulator End Effector Force/Torque Sensor Attribute

10 Communications Attributes

10.1 Communications Attribute

10.2 Communicator Attribute

10.2.1 Component and Service Requirements

10.3 Channel Status Attribute

10.3.1 Component and Service Requirements

1 Scope This document is a normative attachment to the RAS-G Interoperability Profile (IOP) Overarching Profile and provides specific rules and requirements associated with the profiling of the SAE JAUS message set to achieve system level and platform level interoperability. SAE ARP6012, JAUS Compliance and Interoperability Policy, prescribes guidance and considerations for the profiling of the JAUS message set in order to achieve interoperability at various levels within a JAUS System. Specific recommendations include the specification of interoperability templates, specifying a common set of standards as well as interoperability profiles that specify additional constraints necessary to create interoperable systems. These constraints may be specified as options unique to each individual selected standard, such as service definitions, timing requirements, quality of service, communications protocols, etc.

This document identifies these additional profiling constraints with respect to the SAE JAUS messaging standards to meet the IOP defined levels of interoperability. As depicted below in JAUS Profiling/IOP Relationship, the JAUS profiling rules forms a direct relationship with the IOPs as well as the SAE JAUS standards.

Figure 1: JAUS Profiling/IOP Relationship

IOP requirements and capabilities (functionality sets) are defined within the other IOP documents. This JAUS Profiling Rules document then specifies additional information, as required to affect an interoperability contract between controller(s) and UGV(s).

Additional information (profiling constraints) addressed to meet IOP interoperability includes, but is not limited to:

1. Clarification of data consistency, as required, for specified messages (e.g., interpretation, constraints, precision, accuracy).

2. Specification of contracts for service/capability mapping (e.g., primitive, vector, velocity state, waypoint drivers).

3. Specification of watchdog/timeout conditions and contingencies; especially for safety critical functions (e.g., Heartbeats, Teleop, Video, Comms, Weapons Control, SL/V).

4. Specification of synchronous message rates.

2 Source Documents

2.1 Government Documents

Table 1: Government Documents

Version Document TR8350.2 Department of Defense World Geodetic System 1984, Its

Definition and Relationships with Local Geodetic Systems

EXT-AEODRS-

10-1785-JAUS

Advanced Explosive Ordinance Disposal Robotic System (AEODRS) JAUS Extension Services and Experimental Messages, version 1.4

ADD-AEODRS-

10-0802-CA

Advanced Explosive Ordinance Disposal Robotic System (AEODRS) Architecture Description Document, version 1.4

2.2 Non-Government Documents

Table 2: Non-Government Documents

Document

ID

Document Name

AIR5665A AE Aerospace Information Report, Architecture Framework for Unmanned Systems (AFUS), April 2009.

ARP6012 SAE Aerospace Recommended Practice, JAUS Compliance and Interoperability Policy, April 2009.

AS5669A SAE Aerospace Standard, JAUS/SDP Transport Specification, February 2009.

AS5684B SAE Aerospace Standard, JAUS Service Interface Definition Language Rev. B, August 2015.

AS5710A SAE Aerospace Standard, JAUS Core Service Set Revision A, August 2010.

AS6009 SAE Aerospace Standard, JAUS Mobility Service Set, April 2009.

AS6057A SAE Aerospace Standard, JAUS Manipulator Service Set Revision A, June 2014.

AS6060 SAE Aerospace Standard, JAUS Environment Sensing Service Set.

AS6091 SAE Aerospace Standard, JAUS UGV Service Set

3 Key Concepts and Information This section provides information on key document concepts, how to use this document to describe interoperability requirements, definitions, and other information.

3.1 Definitions

Table 3: Definitions

Term Definition Capability A capability is a single operationally relevant function - for example, teleoperation would be a capability that provides the function of allowing a user to drive a vehicle non-line of sight using a camera.

In this document, a Capability is generally associated one on one with an Interoperability Attribute.

Complex Payload

A complex payload is a payload that aggregates multiple capabilities. The definition of logical payload in this document extends from the Payload IOP document to define a complex payload as either a physical or logical aggregation. A complex payload shall always be represented by a JAUS node.

IP Address Assignment List

The IP Address Assignment List is a list of IP addresses with associated JAUS IDs that are located at those IP addresses. For example, an IP Address Assignment List might have three IP addresses, with one JAUS ID associated with IP address #1, 2 JAUS IDs associated with IP address #2, and 1 JAUS ID associated with IP address #3. The IP Address Assignment List is used by Transport Layer Routing elements to properly route messages and other communications to the correct transport layer endpoint given a logical JAUS ID.

JAUS

Component

A JAUS component is a logical grouping of JAUS Services. Each component aggregates services to provide a single operationally relevant capability. The component offers a service interface to other consuming components to use. For example, teleoperation could be a component that aggregates a primitive driver service and some sensor services to provide teleoperation capabilities to a robotic controller.

JAUS Node A JAUS Node is logical grouping of JAUS Components within a JAUS Subsystem. Within this IOP, nodes are specified to aggregate related capabilities. This aggregation may be either logical (i.e. any capability that affects platform motion is aggregated under the Mobility node) or physical (i.e. a manipulator payload with two cameras and a sensor on it are considered a node).

JAUS Service JAUS services represent the lowest level of the topology. For the purposes of this IOP, services provide an abstraction to hardware or software algorithms that reside on the platform. Services may by internalized within a component or may be provided via an interface that is consumed by components.

JAUS

Subsystem

A JAUS subsystem is an independent and distinct unit within a system. Subsystems include robotic controllers, robotic platforms, and video terminals connected and communicating via a specified set of interoperability attributes. A subsystem contains one or more JAUS Nodes.

JAUS System A JAUS system is the top level element within the topology and can encompasses all interoperable elements (robotic controllers and robotic platforms). The system contains multiple subsystems.

Transport Layer Routing Element

A Transport Layer Routing element is an element responsible for routing JAUS messages to the proper endpoint(s) on the transport layer, given a logical JAUS ID. Historically, the term "Node Manager" has often been used for the element providing this capability.

3.2 Key Concepts and Rules

3.2.1 Interoperability Attributes

Interoperability Attributes are the primary organizational structure of this document. An Interoperability Attribute is a single operationally relevant function - for example, teleoperation would be a capability that provides the function of allowing a user to drive a vehicle non-line of sight using a camera. Interoperability Attributes may have one or more groups of child attributes, called attribute reference groups. Child attributes from each group are added based on their modifiers, which could require all, any, or just one attribute to be selected from the group.

An attribute reference group that an Interoperability Attribute references may have one of three selection types associated with it: all, any, or one. These selection types specify how attributes from the attribute reference group are selected. Definitions for the selection types are:

Table 4: Attribute Reference Group Selection Types

Optional Selection Type

Description

True All Either all attributes or no attributes from the attribute reference group MUST be selected. These attributes are linked together.

False All All attributes from the attribute reference group MUST be selected. These are mandatory attributes.

True Any As many of the attributes as desired (including none) from the attribute reference group may be selected. These are optional attributes.

False Any At least one of the attributes from the attribute reference group MUST be selected. These attributes are each optional, so long as one is selected.

True One No more than one attribute from the attribute reference group can be selected. These are mutually exclusive, though not required, attributes.

False One One and ONLY one attribute from the attribute reference group MUST be selected. These are mutually exclusive attributes where a choice is required.

3.2.2 Requirements

Most attributes will have one or more requirements (the primary exception is attributes that group other attributes together). A Requirement provides specific details of what must be done to successfully implement an Interoperability Attribute. In this document, there are two types of requirements - a JAUS requirement, and an identified requirement. A JAUS requirement is only found in this document and defines required JAUS services, messages interpretations, and other JAUS-specific items. The other type of requirement is an identified requirement, which contains a single "shall" statement that specifies what must be done to comply with an Interoperability Attribute.

3.2.3 Parameters

Parameters are items found under Interoperability Attributes or Requirements that must have a value assigned to them. Typically, default or recommended values will be provided. Parameters are intended to be used to add additional detail required by certain Interoperability Attributes and Requirements, such as specifying how long before a drive timeout occurs. When referenced in text descriptions, parameters are marked in this document by a preceding "[Parameter]" statement, followed by the parameter name. For example, "[Parameter] Drive Timeout" defines a parameter called Drive Timeout. All Interoperability Attributes and Requirements that have parameters will have a sub-section that lists all parameters, their default value, and a description of the parameter.

3.2.4 Grouping Together Interoperability Attributes - the Node One or more Interoperability Attributes may be grouped together using the concept of a Node. A Node defines a group of one or more related Interoperability Attributes. The relation may be physical (i.e. a payload that physically groups together multiple cameras, sensors, and a manipulator) or logical (i.e. a grouping of all functionality related to platform mobility). A Node requires only a unique name and the Interoperability Attributes that define it, but other information like a unique JAUS Node ID could also be specified. By default, there are two Capabilities that shall be defined whenever this document is used to define UGV requirements:

1. Platform Node - Groups all platform components together, such as basic platform management, platform lights, and any other platform specific capabilities. In this document, a component target of "platform_manager" indicates a component on the Platform Node. The JAUS Node ID of the Platform Node is typically 1.

2. Mobility Node - Groups all mobility components together, including the Core Mobility Component, which provides low-level access to a platform's mobility capabilities. Any capabilities specifically related to the mobility of the platform should be added to the "Mobility" Node.

3.2.5 Periodicity Requirements

Many JAUS Requirements will list periodicity requirements. These are usually a minimum rate at which a command must be sent or at which a report must be provided.

Periodicity requirements also include what messages for a given service must be published (periodic and on-change events). Any message (i.e. reporting global pose) for which a periodic event is required will provide a required or suggested rate, and any message that has periodic event specified (rate is in Hz) shall also support on-change events.

3.2.6 JAUS Hierarchy Rules

The rules for defining a JAUS Hierarchy using this document are defined in the mandatory JAUS Hierarchy Rules attribute.

3.2.6.1 JAUS Hierarchy Rules Attribute

Parent Attribute: Core Software and Logical Attribute

A JAUS hierarchy consists of four levels – JAUS Subsystems, JAUS Nodes, JAUS Components, and JAUS Services. These levels are defined in the definitions table at the beginning of this section. There are three simple rules that provide the only JAUS hierarchy requirements of this document – all other details are left to the requirements derived using this document, or to the implementation.

3.2.6.1.1 JAUS Hierarchy Rules Requirement

V2.JAUS-

A JAUS Subsystem shall be defined for any grouping of Nodes. This JAUS Subsystem is typically a robotic system or OCU.

V2.JAUS-

For every Node defined (i.e. a payload), there shall be a single associated JAUS Node.

For every Interoperability Attribute grouped into a Node, a single JAUS Component will be added to the JAUS Node defined by the Requirements Node. A single JAUS Component may be used by multiple Interoperability Attributes as long as there is no conflict between the attributes. For example, the Teleoperation and Remote Control Interoperability Attributes are both required to add their JAUS Services to the same Core Mobility Component. Conflicts can be generated either by trying to duplicate JAUS capabilities (i.e. two different Local Waypoint navigation behaviors can’t be added to the same JAUS Component since they use the exact same services) or based on system requirements (i.e.

if separate, independent control of an end effector and manipulator arm is required, then they must reside on different components).

3.2.7 Component Targets

Version 2 of the JAUS Profiling Rules IOP introduces the concept of component targets.

These targets show up in the "Component" column of the tables found under Component and Service Requirements. Component targets define where a specific service is expected to be found. There are 5 component targets: any, all, unique, if_inherited, and named.

When using the JAUS Profiling Rules to develop requirements, you may want to provide more specific component targets for certain services (even going as far as specifying the component IDs), but you should never relax the requirements provided in this document (i.e. changing a target of "all" to "any" or ignoring the "platform_manager" target).

3.2.7.1 any The "any" component target indicates that a service could appear on any JAUS Component, but it is required to occur on AT LEAST one JAUS Component. The "any" target is the default target if the "Component" column is left blank. An example of an "any" target service would be GlobalPoseSensor, which could occur anywhere but would be expected somewhere if global pose is a requirement.

3.2.7.2 all The "all" component target indicates that a service MUST be found on all JAUS Components. If the service is not found (or fails a test) on a single component, then the attribute requirements has not been met and compliance to that attribute is not achieved.

3.2.7.3 unique The "unique" component target indicates that a service MUST occur on one and only one JAUS Component. This designation is often used for services that would cause issues if they occurred more than once, like Digital Resource Discovery.

3.2.7.4 if_inherited The "in_inherited" target indicates that a service must be on a JAUS Component if some other service on that component inherits it. These target is typically used with core services like Access Control and Management.

3.2.7.5 Named Target

A named target is a specific name (also referred to as an alias) like "platform_manager" that specifies the component or components on which a service is expected to reside.

There are two rules regarding named component targets:

1. The name may apply to one or more JAUS Components on the same JAUS Node. For example, the "platform_manager" target may apply to multiple JAUS Components on the Platform Node. A future revision of this document may add a way to specify an alias can apply to more than one node.

2. A JAUS Service that has a named component target is expected to occur on one and only one of the JAUS Components to which the alias specified by the component target applies. A future revision of this document may add a way to specify other types of multiplicity.

4 Core Section This section contains core attributes for the JAUS Profiling Rules IOP.

4.1 Core Software and Logical Attribute

The Core Software and Logical Attributes are attributes that represent broad categories of system capabilities.

The following attributes are mandatory.

Table 5- Mandatory Select = all

Attribute Description Core JAUS Attribute

Mandatory attribute that must be selected for every system that defines requirements using Interoperability Attributes.

JAUS Hierarchy Rules Attribute

Defines the rules for translating attribute requirements from this IOP into a JAUS Subsystem, Node, Component hierarchy.

Any number of the following attributes can be chosen.

Table 6- Optional Select = any

Global Attribute Global Interoperability Attributes do not tightly fit into a single attribute group or are likely to be used in conjunction with many different Interoperability Attributes

Platform Attribute Platform-centric attributes that provide platform level capabilities such as discovery, engine status information, health information, etc.

Mobility Attribute The Mobility Interoperability Attribute defines attributes related to platform mobility, such as driving.

Autonomy and Behaviors Attribute

Provide higher level navigation capabilities and support for other behaviors that take place absent complete operator control.

Sensor Attribute UGVs have payloads which can collect data from the surrounding environment. In addition UGVs have sensors that collect data from the robot in order to report back to the operator health and other status information.

Emitter Attribute UGVs have payloads which can affect their surrounding environment at a distance. These include Lights, Speakers, Laser Target Designators, and Weapons.

Actuator Attribute Actuator payloads provide mechanical means of manipulation.

Communications Attribute

Communications Interoperability Attributes define capabilities to deal with communications off-board the platform.

4.2 Core JAUS Attribute

The Core JAUS Attributes are mandatory attributes that must be specified for every system that defines requirements using Interoperability Attributes. Core JAUS Attributes are unique in that they are the only attributes that do not define a single specific capability, but instead define required capabilities that apply to all other Interoperability Attributes.

Table 7- Mandatory Select = all

Access Control Attribute

Specifies how authority is used to control access to services that accept commands, like mobility and manipulator services.

Component Liveness Attribute

Specifies that a Liveness service shall be provided by each component (allows liveness/connectivity checks to be performed).

ID Assignment and Propagation Attribute

Defines basic concepts used in assignment of JAUS Subsystems (Platform / OCU) and Nodes (payloads). Parent of all Subsystem and Node ID Assignment and Propagation attributes.

Transport Attribute Specifies the type of transport layer(s) used to transport JAUS messages.

4.2.1 Component and Service Requirements

Table 8- Component and Service Requirements for Core JAUS Attribute

Service Component Reference urn:jaus:jss:core:Transport, 1.1 if_inherited AS5710A JAUS Core

Service Set urn:jaus:jss:core:Events, 1.1 if_inherited AS5710A JAUS Core

Service Set urn:jaus:jss:core:AccessControl, 1.1 if_inherited AS5710A JAUS Core

Service Set urn:jaus:jss:core:Management, 1.1 if_inherited AS5710A JAUS Core

Service Set urn:jaus:jss:core:ListManager, 1.1 if_inherited AS5710A JAUS Core

Service Set

4.2.2 Core Services Basic Requirements

Core services shall be provided by every JAUS Component. Based on the inheritance defined in the appropriate SAE JAUS document for every service on that JAUS Component, at least one and as many as all of the core service profiled in this requirement will be provided. The commonly required core services that are profiled here or separately are:

• Transport - The Transport service must be implemented by every JAUS component. It defines the interface between the JAUS Component and the transport layer that is responsible for getting messages to and from that JAUS Component.

• Events - The Events service provides a mechanism to create and manage events on a JAUS component. Events include periodic notifications (i.e. a regular global pose update) and on-change events (i.e. notification only when a specific value changes). JAUS Events approximates a publish-subscribe mechanism for exchanging information.

• Access Control - The Access Control service manages who has permission to access the command interface (i.e. moving a vehicle using a wrench effort) of a JAUS Component. Access Control requirements are detailed in Access Control Interoperability Attribute.

• Management - The Management service manages the lifecycle of a JAUS Component. It is primarily used to ensure that JAUS services that impact movement of something and have safety implications (i.e. mobility and manipulator drivers) will only respond to commands when in the ready management state.

• List Manager - The List Manager service provides the ability to create, modify, and use lists for dependent JAUS services that need lists, such as the Global Waypoint List Driver service.

4.2.2.1 Notes and Interpretations

4.2.2.1.1 Events

4.2.2.1.2 Supported Events

A CreateEvent message is sent to the Events service on a JAUS component when attempting to create a periodic or on-change event. There are three possible responses the Events service will provide: the event request was accepted at the requested rate, the event request was accepted but at a different rate, or the event request was rejected. One should not assume that any particular event for a particular JAUS message will be supported by a particular JAUS component implementation unless an event is explicitly required by the Periodicity section of a given Interoperability Attribute.

Requirements for events that must be supported and the rates at which they must be supported, other than those explicitly defined within this document, must be defined separate from the requirements of this document.

4.3 Access Control Attribute

The Access Control Interoperability Attribute profiles the way to manage access to JAUS Components using the JAUS urn:jaus:jss:core:AccessControl service.

4.3.1 Component and Service Requirements

Table 9- Component and Service Requirements for Access Control Attribute urn:jaus:jss:core:AccessControl, 1.1 if_inherited AS5710A JAUS Core

Service Set

4.3.2 Authority Code Organization Requirement

Although JAUS defines a range of authority codes, there are no recommended practices for using them. The following table defines authority code ranges and their roles and description.

Table 10: Authority Code Roles and Descriptions

Role Authority Code Range

Description

OWNER 255 "root" user concept, analogous to the root user of an OS.

SAFETY_CRITICAL 240-254 A role reserved for safety critical components that cannot have their control usurped. Will often be an on-board process like stability control of self-collision avoidance, but could also be an off-board client, even the

OCU.

PRIMARY_OPERATOR 205-239 Only client role with mobility control.

Can control/monitor any Component on the platform. A client is defined as any client that is not on-board the a robotic platform itself, and will typically be something like the Operator Control Unit (OCU) that an operator is using.

ONBOARD_MOBILITY_DEVICE 155-204 Only onboard controller role with mobility control. Can control/monitor any Component on the platform. An onboard controller is defined as any process or capability on-board a platform (as opposed to an OCU that is typically off-board). An example is an autonomy process taking control of lower level services to do more advanced navigation.

OPERATOR 75-124 Client role that can control/monitor any Component on the platform except those contained under the Mobility Node.

ONBOARD_DEVICE 25-74 Onboard controller role that can control/monitor any Component on the platform except those defined under the Mobility Node.

MONITOR 0 Can only monitor Components.

Authority codes in a higher authority code range can pre-empt those in a lower authority code range. Clients with authority of 0 cannot take control of a component because the minimum default authority is 1.The Owner Preemption Figure shows a sequence diagram that illustrates the owner pre-emption use cases.

Figure 2: Owner Pre-emption Use Case

4.3.3 Default Authority Requirement

Default authority is the default authority assigned to a JAUS Component for the purposes of taking control of it using Access Control. The authority level of a client requesting control of an Access Controlled JAUS Component must be greater than or equal to the default authority in order for the requesting client to get control of the JAUS Component, regardless of the authority level of the current controller. The following rules apply to the default authority level of JAUS Components within this IOP:

• The default authority of any Access Controlled JAUS Component on the Mobility Node shall be at least 125. This allows the ONBOARD_MOBILITY_DEVICE role and above to take control of platform mobility, while preventing roles with lesser authority from doing so.

• The default authority of any Safety Critical JAUS Component shall be at least

240. This prevents any clients that do not have the SAFETY_CRITICAL role from taking control.

• The default authority of any Access Controlled JAUS Component besides those on the Mobility Node shall be at least 1. This prevents the MONITOR role from controlling any device, while allowing the higher roles to take control.

The default authority of any Access Controlled JAUS Component on the Mobility Node shall be at least 125.

The default authority of any Access Controlled JAUS Component besides those on the Mobility Node shall be at least 1. This means that a client with authority of 0 shall not be able to take control of any component.

4.3.4 Access Control Timeout Requirement

The access control timeout feature of the urn:jaus:jss:core:AccessControl service as defined in AS5710A JAUS Core Service Set is used for maintaining liveness of control.

This liveness differs from the connection liveness offered by the Liveness service and instead provides a way for the server to detect the presence of the client. As stated in the description of the access control service, a timeout is set that corresponds to the rate at which a controlling client component must periodically request control of a server component, releasing control if the timeout is exceeded. The access control timeout is specified using the parameter Access Control Timeout.

4.3.4.1 Parameter Listing

Table 11- Parameter Listing for Access Control Timeout Requirement

Parameter Name Default Value

Allowed Values

Description

Access Control Timeout Parameter seconds

<Range> 0..65535 seconds

The rate in Seconds at which a controlling client component must periodically request control.

4.3.5 Mutually Exclusive Access Control Requirement

This document currently defines Interoperability Attributes for several different JAUS Components where each JAUS Components' services may want control of low level hardware controllers (i.e. platform motor drivers, manipulator joint motors, etc). A platform that has multiple JAUS components accessing low level hardware could have one of two things happen: either a single client could send messages to more than one JAUS Component, or two clients could send messages to two separate JAUS Components. In either case, how the platform responds is unknown. This problem is solved by the following requirement:

There shall be a single ("singleton") JAUS Component that contains all possible services for controlling the low level hardware functionality of a device. This shall be the only JAUS Component whose services access the low level functionality of the device.

This singleton JAUS Component is composed by specifying which Interoperability Attributes are used for control of the device - any duplicated services shall be presented as a single service. For example, when doing mobility control of a platform, if a singleton Core Mobility Component is composed of the RC and Teleop, it will look like the figure below.

Figure 3: Example of Singleton Core Mobility Component with the RC and Teleop attribute specified.

There shall be a single ("singleton") JAUS Component that contains all possible services for controlling the low level hardware functionality of a device. This shall be the only JAUS Component whose services access the low level functionality of the device.

4.4 ID Assignment and Propagation

4.4.1 ID Assignment and Propagation Attribute

The following definitions apply for subsystem ID assignment and propagation:

1. Basic Platform Management Component - A JAUS Component that resides on the Platform Manager Node that is responsible for ID Assignment and Propagation.

2. Type 1 Endpoint (Basic Platform Manager component waiting for its Subsystem ID to be assigned) - This endpoint is a JAUS component endpoint that has an unknown JAUS Subsystem ID that needs to be assigned at the System level (i.e. a platform and operator control unit pair). A type 1 endpoint must have a known node ID (for example, the Platform Manager node may have a pre-assigned Node ID of 1). Any message sent to a Type 1 Endpoint (i.e. a response to a query from a Type 1 Endpoint source) shall be broadcast to all JAUS Subsystems (65535.255.255). A Type 1 Endpoint shall use the JAUS logical address 0.[Node ID].[Component ID].

3. Type 2 Endpoint (Payload or other Node without an assigned subsystem ID) - This endpoint is a JAUS component on a Node (a single component on the JAUS node should manage the ID assignment responsibility for all components on that node) that has an unknown JAUS Subsystem ID that needs to be assigned at the JAUS Subsystem (platform) level. Any message sent to a Type 2 Endpoint (i.e. a response to a query from a Type 2 Endpoint source) shall be broadcast to all JAUS Components on all JAUS Nodes of the JAUS Subsystem that the Type 2 Endpoint is located on ([Subsystem ID].255.255). If the subsystem ID is unknown, a value of 0 shall be used for the subsystem ID, and the broadcast shall use the platform multicast address. A Type 2 Endpoint shall have JAUS logical address 0.[Node ID].[Component ID].

4. Type 3 Endpoint (Payload or other Node without an assigned Node ID) - This endpoint has an unknown JAUS Node ID that needs to be assigned at the JAUS Subsystem (platform) level. Any message sent to a Type 3 Endpoint shall be broadcast to all JAUS Component on all JAUS Nodes of the JAUS Subsystem that the Type 3 Endpoint is located on (broadcast address [Subsystem ID].255.255). A Type 3 Endpoint shall have a JAUS logical address of [Subsystem ID].255.[Component ID] or [Subsystem ID].0.[Component ID]. A Type 3 Endpoint may also be a Type 2 Endpoint.

Table 12- Mandatory Select = all

Subsystem ID Assignment Attribute

Specifies how JAUS Subsystems within a JAUS system are assigned a subsystem ID.

Node ID Assignment Attribute

Specifies how JAUS Nodes within a JAUS subsystem are assigned a node ID.

Table 13- Optional Select = any

Subsystem ID Propagation Attribute

Specifies how a Subsystem ID is propagated to JAUS Nodes (payloads).

4.4.2 Subsystem ID Assignment

4.4.2.1 Subsystem ID Assignment Attribute

Parent Attribute: ID Assignment and Propagation Attribute

The Subsystem ID Assignment Interoperability Attribute specifies attributes that define methods for assigning unique JAUS IDs to JAUS subsystems. JAUS messages are routed from source to destination by a JAUS ID embedded in the JAUS message header. The JAUS ID is composed of three ID fields: The Subsystem ID field, the Node ID field, and the Component ID field.

The following attributes are mutually exclusive, exactly one must be chosen.

Table 14- Mandatory Select = one

Static Subsystem ID Assignment Attribute

Defines static assignment of JAUS Subsystem IDs. Static assignment implies a predetermined set of JAUS Subsystem IDs are assigned for each JAUS Subsystem.

Centralized Subsystem ID Assignment Attribute

Defines a centralized approach to acquiring JAUS Subsystem IDs. In this approach, a central server provides unique IDs to all JAUS Subsystems that submit a request for an ID.

4.4.2.2 Static Subsystem Assignment Attribute

Parent Attribute: Subsystem ID Assignment Attribute

If the Static Subsystem ID Attribute is specified, the assignment of unique JAUS subsystem identifiers shall be done at set-up / configuration time. The exact way in which this is done is not specified by this IOP document, but typical methods include through a configuration file or other field-modifiable approach. If the Static Subsystem ID Assignment Attribute is selected, a method for ensuring the assignment and maintenance of unique JAUS identifiers must be used.

4.4.2.2.1 Static Subsystem ID Assignment Requirement

V2.JAUS-

If the Static Subsystem ID Attribute is specified, the assignment of unique JAUS subsystem identifiers shall be done at set-up / configuration time.

4.4.2.3 Centralized Subsystem Assignment Attribute

Parent Attribute: Subsystem ID Assignment Attribute

If the Centralized Subsystem ID Assignment Attribute is specified, the assignment of unique JAUS subsystem identifiers shall be done using a run-time centralized approach for ID assignment. The Centralized Subsystem ID Assignment Attribute for JAUS Subsystem ID assignment is only valid if the Platform Management Interoperability Attribute is specified, and the JUDP Attribute child of the Transport Interoperability Attribute is selected (even if only selected for this purpose). This centralized approach is described below:

4.4.2.3.1 Procedure

4.4.2.3.1.1 How the Subsystem Acquires its JAUS Subsystem ID

1. A single Subsystem ID Server shall be provided on the network that contains the

SubsystemIDAllocator JAUS Service and responds to RequestSubsystemID messages. Any implementation of this attribute must have a way to guarantee that there is only one SubystemIDAllocator service (defined in the Custom Services, Messages, and Transports IOP Document) that will respond to

RequestSubsystemID messages, or that there is a way to coordinate between multiple SubsystemIDAllocator services such that uniquely assigned JAUS Subsystem IDs are guaranteed this document does not specify how this is accomplished.

2. Upon startup, a JAUS Subsystem (i.e. a robot or OCU) broadcasts to all subsystems (65535.255.255), through the Basic Platform Manager JAUS Component, a RequestSubsystemID message containing a unique identifier for the platform (MAC Address). The Basic Platform Manager JAUS Component shall register as a Type 1 Endpoint with the Transport Layer Routing Element, indicating it wants to receive all broadcasted messages. For UDP multicast, the internal (on the robot) multicast address shall be tried before sending over the external multicast address (sent to all subsystems).

3. Upon receiving the RequestSubsystemID message, the SubsystemIDAllocator Service responds via broadcast (65535.255.255) with a unique Subsystem ID associated with the unique identifier provided in the RequestSubsystemID message. Node ID and Component ID are the values for the source of the RequestSubsystemID message.

4. The Basic Platform Manager JAUS Component that sent the original RequestSubsystemID message receives the GrantSubsystemID message, verifies that the unique identifier in the message matches the unique identifier that it sent, and then sets its JAUS Subsystem ID to the ID provided in the GrantSubsystemID message.

5. Broadcasts performed to 0.255.255 are limited to the bounds of the platform (i.e.

there is only one possible Discovery service that will respond). The specific details of this broadcast at the Transport Layer level are left to the implementation.

6. Once the Basic Platform Manager JAUS Component obtains the JAUS Subsystem ID for the platform, it shall begin broadcasting an unsolicited Report Heartbeat Pulse message (JAUS message ID 0x4202) to all JAUS Components on the platform using the [Subsystem ID].255.255 broadcast address. The unsolicited Report Heartbeat Pulse message shall NOT be broadcasted until the Basic Platform Manager JAUS Component has a JAUS Subsystem ID.

Table 15- Mandatory Select = all

Subsystem ID Propagation Attribute

Defines a dynamic method for propagating the Subsystem ID from a Platform to its payloads and other attached JAUS Nodes. This attribute is mandatory Centralized Subsystem ID Assignment is performed because the JAUS Subsystem ID is not known a-priori.

4.4.2.3.2 Component and Service Requirements

Table 16- Component and Service Requirements for Centralized Subsystem Assignment Attribute urn:jaus:jss:exp:aeodrs:SubsystemIDAllocator , 1.4 unique Custom Services, Messages, and Transports urn:jaus:jss:iop:UnsolicitedHeartbeat, 1.1 platform_ma nager

Custom Services, Messages, and Transports

4.4.2.3.3 Centralized Subsystem ID Assignment Requirement

V2.JAUS-

There shall be a server component somewhere within the JAUS system that guarantees unique JAUS Subsystem ID assignment. This does not necessarily need to reside on the robotic system, and will often run on something like an OCU.

The Basic Platform Manager JAUS Component shall act as a client to the SubsystemIDAllocator Service, and shall execute the procedure specified in "How the Subsystem Acquires its JAUS Subsystem ID" procedure to obtain its Subsystem ID.

The Basic Platform Manager JAUS Component shall broadcast an unsolicited ReportHeartbeatPulse message to all JAUS Nodes and Components on the platform using the broadcast address [SubsystemID].255.255 ONLY AFTER it has obtained a Subsystem ID. If the platform Subsystem ID is reset to an unassigned value for any reason at any point, the Basic Platform Manager JAUS Component shall STOP broadcasting the message. The unsolicited heartbeat pulse is implemented in accordance with the urn:jaus:jss:iop:UnsolicitedHeartbeat service specified in Custom Services, Messages, and Transports.

ONLY the component specified by the "platform_manager" target (the Basic Platform Manager JAUS Component) shall implement the urn:jaus:jss:iop:UnsolicitedHeartbeat service. No other component on the JAUS Subsystem, including payloads that may be plugged into a JAUS Subsystem, shall broadcast an unsolicited heartbeat pulse message.

4.4.2.3.3.1 Notes and Interpretations

4.4.2.3.3.1.1 Subsystem ID Allocator

Table 17- Message Interpretations for Subsystem ID Allocator

Message(s) Concept Interpretations

ID DB01:

RequestSubsystemID

ID FB01:

GrantSubsystemID

MACaddr field

The MACaddr field specifies the MAC address of the requestor - this may be any MAC address unique to the requesting platform.

4.4.2.3.3.1.2 Unsolicited Heartbeat

The Unsolicited Heartbeat service does not send its unsolicited Report Heartbeat Pulse message unless it has a fully known JAUS ID, including the Subsystem ID and Node ID.

4.4.2.3.4 Parameter Listing

Table 18- Parameter Listing for Centralized Subsystem Assignment Attribute

Parameter Name

Default Value

Valid Values

Description

Unsolicited Heartbeat Pulse Rate

1 Hertz <Range> 0..65535 Hertz

Rate in Hz at which the Basic Platform Manager Component broadcasts its unsolicited ReportHeartbeatPulse message. To prevent systems that use this message as an indicator for lost connectivity, this rate should be significantly faster than the rate defined by 1 / Platform Manager Timeout defined in this document. Choosing this rate should consider variance caused by CPU loads, network traffic and latency, and other factors.

4.4.3 Subsystem ID Propagation

4.4.3.1 Subsystem ID Propagation Attribute

If the Subsystem ID Propagation Attribute is selected, the JAUS Subsystem ID of a platform is propagated dynamically to the payloads connected to that platform.

Dynamic JAUS Subsystem ID propagation is required when a payload does not know the Subsystem ID of the platform it is being plugged into a-priori. There are two methods a payload can use to obtain its JAUS Subsystem ID – using the unsolicited ReportHeartbeatPulse message from the Basic Platform Manager Component (recommended) or broadcasting a JAUS Subsystem level message (like QueryIdentification) that the Platform Manager will respond to with a JAUS Subsystem level broadcast of its own.

4.4.3.1.1 Procedure

There are two methods that an individual JAUS Components on a JAUS Subsystem may use to dynamically obtain its Subsystem ID. The first is to look for the unsolicited

ReportHeartbeatPulse message from the Basic Platform Manager Component, and use the source JAUS Subsystem ID from the ReportHeartbeatPulse message (recommended), or the individual JAUS Components may logically broadcast, at the JAUS Subsystem level, a message to which the Basic Platform Manager Component will respond, like QueryIdentification.

4.4.3.1.1.1 Method 1: Using the Unsolicited Report Heartbeat Pulse Message to Obtain a JAUS Subsystem ID

Note: This is the recommended method to use as there is a requirement that only the Basic Platform Manager component may send the unsolicited ReportHeartbeatPulse message. Using the second method could theoretically yield more than one response, even if unlikely. A single JAUS Component on a JAUS Node may be used to set the Subsystem ID for all components on that node.

1. A newly attached component (i.e. on a payload node, etc.) that does not yet have a JAUS Subsystem ID registers with its Transport Layer Routing Element as a Type 2 Endpoint.

2. The newly attached component looks for a ReportHeartbeatPulse message broadcast at the Subsystem level ([SubsystemID].255.255) using the JAUS Subsystem multicast address.

3. The newly attached component uses the JAUS Subsystem ID provided in the source of the ReportHeartbeatPulse message as its JAUS Subsystem ID, so long as that Subsystem ID is not 0 or 65535 (wildcard). If a wildcard Subsystem ID is received, the component shall continue steps 2-3 until a non-wildcard Subsystem ID is received.

4.4.3.1.1.2 Method 2: Using a Response from the Basic Platform Manager Component to a Message Sent by the Newly Attached JAUS Component

1. A newly attached component (i.e. on a payload node, etc.) that does not yet have a JAUS Subsystem ID registers with its Transport Layer Routing Element as a Type 2 Endpoint.

2. The…