Attachment_0042_-__RAS-G_IOP_Control_Profile.pdf

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

Control Profile 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

1.1 Purpose

1.2 Intended Audience

1.3 Use of the Controls Interoperability Profile

1.3.1 Interoperability Attributes and Modifiers

1.4 Document Overview

2 Source Documents

2.1 Government Documents

3 Hardware Section

3.1 OCU Hardware Attribute

3.2 OCU Physical and Electrical Interface

3.2.1 Mounting Requirement

3.2.2 OCU Power Requirement

3.2.3 OCU Communications Requirement

3.2.4 Audio Interface Requirement

3.2.5 USB Requirement

3.2.6 Serial Interface Requirement

3.2.7 Video Interface Requirement

3.2.8 Ethernet Interface Requirement

3.2.9 Display Interface Requirement

3.2.10 Smart Card Reader Interface Requirement

3.3 OCU Size Categories

3.3.1 OCU Size Categories

4 Software Section

4.1 Core Software and Logical Attribute

4.1.1 HMI Requirements

4.1.2 Power Requirement

4.1.3 Authentication Requirement

4.1.4 Robotic Selection Requirement

4.1.5 Display Requirement

4.1.6 Speaker and Microphone Requirement

4.1.7 Hand Controller Requirement

4.1.8 Head Mounted Display Requirement

4.1.9 Date/Time Display Requirement

4.1.10 Asset Display Requirement

4.1.11 Payload Status Requirement

4.2 Global Attribute Section

4.2.1 Global Attribute

4.2.2 Pose And Attitude Attribute

4.2.3 Basic Global Position and Attitude Attribute

4.2.4 Power Plant Management Attribute

4.2.5 Preset Pose Attribute

4.2.6 Security Section

4.2.7 Obstacle Reporting Attribute

4.2.8 Software Version Reporting Attribute

4.3 Platform Attributes

4.3.1 Platform Management

4.3.2 Enhanced Access Control Attribute

4.4 Mobility Section

4.4.1 Mobility Attribute

4.4.2 Autonomy and Behaviors Attribute

4.4.3 Waypoint Navigation Attribute

4.4.4 Leader/Follower Attribute

4.5 Payload Control Section

4.5.1 Sensors Section

4.5.2 Emitters Section

4.5.3 Actuators Section

4.6 Communications Attributes

4.6.1 Communications Attribute

4.6.2 Communicator Attribute

5 Appendix A: Example Button Layout for Controlling a UGV using a Commercial Game Controller

6 Appendix B: Manipulator Operation from COTS Joystick

7 Appendix C: Control Standards

7.1 OCU Standards and Guidelines

7.1.1 OCU Physical Attributes

7.2 HMI Standards and Guidelines

7.2.1 General Purpose HMI Standards

7.2.2 Payload Control

7.2.3 Common Icons and Graphics

7.2.4 Input Device Mapping

7.3 Software Standards and Guidelines

1 Scope

1.1 Purpose

This document defines guidelines for the specification of interoperable controllers. The guidelines focus on interoperable concepts for both the hardware, and software. These guidelines are expressed in the form of Interoperability Attributes. Care is taken to avoid developing attributes that define implementation, but rather drive implementation such that interoperability can be met. Focus is placed on interfaces that enable required functionality or capabilities, rather than defining how to implement the required functionality or capability.

Robotic controllers are quite often referred to as Operational Control Units or OCU’s.

Throughout this document the term OCU will refer to the controller as whole, both its hardware and software guidelines. In addition, operators will interact with the controller or OCU through a Human Machine Interface (HMI). The HMI is sometimes also called a Warfighter Machine Interface (WMI), for the purposes of this document these terms are interchangeable.

Guidelines presented herein address attributes relevant to HMI capabilities such as screen layouts, user interface navigation, and common functions such as warnings, cautions, and alerts (WCA’s). They also address attributes relevant to software capabilities such as method(s) supporting update of software components, and interaction with payloads or other removable devices not currently supported by the controller software. Attributes relevant to OCU hardware such as interface devices are also addressed.

The Control Interoperability Profile (IOP) document, in conjunction with the Robotics and Autonomous Systems – Ground (RAS-G) IOP Overarching Profile, defines guidelines for the specification of message-passing interfaces and protocol behavior between UGV Platform payload(s) and OCU input/output devices, application environment and Human Machine Interface (HM) see Operator Control Unit Figure below. Wherever possible, existing standards will be used (Ex: Waypoint icon is provided in MIL STD 2525C). In some cases, existing standards may be used, but updated or expanded on to cover functionality that did not exist when the standard was created (Ex: traditional speedometer with autonomous navigation system max speed setting indicated).

Figure 1: Operator Control Unit (OCU)

1.2 Intended Audience

This document is intended for systems engineers and designers engaged in the development of unmanned ground vehicle systems. Specification guidelines presented in this document may be applied toward custom design.

1.3 Use of the Controls Interoperability Profile

The Control IOP provides a mechanism to specify control system requirements in a composable manner, using Interoperability Attributes. Interoperability attributes applicable to control can be identified and subsequently utilized to filter applicable requirements from the RAS-G IOP, supporting system design, development, conformance and validation testing, initial operational test and evaluation, and fielding.

As robotic system capabilities are constantly being created or improved, it is suggested that each acquisition program carefully define what aspects of control interoperability are required to meet current requirements and plan for future capability upgrades.

1.3.1 Interoperability Attributes and Modifiers

This document specifies Controls Interoperability Attributes. Interoperability Attributes profile the use of hardware, software, and HMI related capabilities for developing WMI and/or HMI and/or OCU and/or OCU software. Interoperability Attributes are organized into sets based on commonality, such as the Mobility Attribute group containing all attributes that profile mobility related capabilities and requirements.

Controls Requirements are expressed in the following format: <V#>.<CTRL>.<Attribute Group>.<sequence number>. Sub-requirements are expressed by appending a <letter> to their respective requirement ID. Where # is the current version of the IOP and CTRL is the IOP document's abbreviation. The Attribute groups specified by this IOP document are the following:

Table 1: Interoperability Attribute Groupings

Interoperability Attribute Group

Description

HW This group contains hardware related Attributes. Aside from the physical HMI attributes, there are hardware guidelines for input, output, storage, display, power, size of OCU, etc..

HMI This group contains Attributes that specify guidelines for the HMI. Examples include input/output devices that the operator interacts with, as well as, style guidelines for iconography and control/status widgets.

BAS This group contains Attributes for conveying basic status information on the OCU.

MIS This group contains Attributes related to mission planning.

MOB This group contains Attributes related to mobility.

SEN This group contains Attributes related to environmental sensing and video.

EMIT This group contains Attributes related to emitters such as speakers, lights, and debris blowers.

ACT This group contains Attributes related to actuator control and status information.

POS This group contains Attributes related to robotic poses.

RAD This group contains Attributes related to configuration and use of a radio.

MAI This group contains Attributes related to software maintenance.

SEC This group contains Attributes related to security such as tamper detection and render useless capabilities.

Requirements and sub-requirements may also have a Selectable modifier attached to them in the form of [Selectable]. The selectable modifier signifies that the decision to support that requirement is the choice of the acquisition program/ instantiation. All other requirements are considered mandatory. Analogously, sub-requirements without a Selectable modifier are considered mandatory either if their requirement is mandatory or their requirement is Selectable and the instantiation chooses to support it.

1.3.1.1 Example Requirement

The following example illustrates a requirement that specifies the physical mounting of an OCU or peripherals onto an OCU. The requirement is selectable, so its inclusion is at the discretion of the acquisition program. If the program selects this requirement, then it must determine whether to select sub-requirements a and b.

ID Shall

V2.CTRL.HW.001

[Selectable]

If selected, mounting to and of an OCU shall conform to the following:

Table 2: V2.CTRL.HW.001

ID Description V2.CTRL.HW.001a [Selectable]

If selected, physical mounting of an OCU to a platform or other specified structure shall comply with Physical Mounting Requirements as specified in the most current RAS-G IOP Payloads Profile specification.

V2.CTRL.HW.001b [Selectable]

If selected, physical mounting of devices, displays, and accessories to an OCU shall comply with Physical Mounting Requirements as specified in the most current RAS-G IOP Payloads Profile specification.

1.4 Document Overview

This document provides the base concepts, architecture, and requirements supporting specification of Controls Interoperability. This IOP is tightly coupled with the RAS-G IOP Overarching Profile, RAS-G IOP SAE JAUS Profiling Rules, RAS-G IOP Payload Profile, and the RAS-G IOP Communications Profile.

2 Source Documents The following documents are part of this version of this specification to the extent specified.

2.1 Government Documents

Version Document V2 RAS-G IOP JAUS Profiling Rules V2 RAS-G IOP Custom Service Messages and Transports V2 RAS-G IOP Overarching Profile V2 RAS-G IOP Communications Profile

MIL-STD-

1472G

Military Standard, Human Engineering Design Criteria for Military Systems, Equipment, and Facilities.

MIL-STD-

2525C

Military Standard, Common Warfighting Symbology.

Additional documents, including non-government documents, referenced by the Controls Interoperability Profile are detailed in the Controls Standards Appendix.

3 Hardware Section This section is to be utilized as recommended guidance in the development and implementation of OCU hardware specifications for semi-autonomous control of optionally manned or unmanned ground vehicle systems. Physical and Electrical Interfaces describes common interfaces and selectable Interoperability Attribute specifications not specified by any of the other IOP profiling documents (i.e. IOP Payloads Profile, IOP Comms Profile, IOP Overarching Profile). Size Categories describes common OCU configurations. Use of this guidance will also serve to drive consistency across unmanned platform programs through common OCU hardware, peripheral interfaces and categorization of OCU sizes.

3.1 OCU Hardware Attribute

While the IOP typically doesn't include performance specifications, certain hardware capabilities naturally overlap with performance specifications. To the degree possible, the IOP endeavors to minimally specify performance metrics. Requirements such as sunlight-readability and man-portability, for instance, are inherent in the form factor of an OCU, which leads to their discussion along with OCU sizes.

The following attributes are mandatory.

Table 3- Mandatory Select = all

Attribute Description OCU Physical and Electrical Interface Physical Mounting on an OCU.

OCU Size Size of OCU hardware.

3.2 OCU Physical and Electrical Interface

Parent Attribute: OCU Hardware Attribute

The OCU is the interface through which a UGV is controlled. OCU physical and electrical interfaces enable basic controls such as buttons and joysticks for controlling the UGV, video and status display, communications, power for interfacing electronics, miscellaneous I/O and operation of control software.

OCU interoperability attributes described herein support specification of interfaces supporting attributes such as communications, control devices, video displays, miscellaneous I/O, and power as well as peripheral devices mounted to the OCU and mounting of the OCU itself to program specified structures.

3.2.1 Mounting Requirement

Attributes specifying physical mounting of an OCU and/or mounting of peripherals to an OCU are referenced in the most current RAS-G IOP Payloads Profile - Physical Mounting Requirements.

V2.CTRL.HW.001

[Selectable]

If selected, mounting to and of an OCU shall conform to the following:

Table 4: V2.CTRL.HW.001

V2.CTRL.HW.001a [Selectable]

If selected, physical mounting of an OCU to a platform or other specified structure shall comply with Physical Mounting Requirements as specified in the most current RAS-G IOP Payloads Profile specification.

V2.CTRL.HW.001b [Selectable]

If selected, physical mounting of devices, displays, and accessories to an OCU shall comply with Physical Mounting Requirements as specified in the most current RAS-G IOP Payloads Profile specification.

3.2.2 OCU Power Requirement

OCU shall support external power interface. Selectable power attributes are specified herein. The IOP Payloads Profiling document specifies other power interfaces not specified here.

V2.CTRL.HW.002 The OCU shall provide power interfaces that comply with the

Electrical Power Requirements as specified in the most current UGV IOP Payloads Profile specification.

Table 5: V2.CTRL.HW.002

V2.CTRL.HW.002a [Selectable]

The OCU power connector should be environmentally sealed and include a tethered dust cap.

V2.CTRL.HW.002b [Selectable]

The OCU power should be through micro-USB interface. This is typically used for handheld devices such as smart phones and tablets.

3.2.3 OCU Communications Requirement

An OCU shall provide communication interface(s). Communication interface attribute(s) are specified herein.

V2.CTRL.HW.003 The OCU shall provide an electrical Interface between an OCU and Communication devices(s) per the following.

Table 6: V2.CTRL.HW.003

V2.CTRL.HW.003a The OCU shall provide an electrical Interface between an OCU and Communication devices(s) which will comply with interface requirements as specified in the most current RAS-G IOP Communication Profile specification.

3.2.4 Audio Interface Requirement

If selected, an OCU shall provide microphone input and speaker output interface(s).

Selectable audio interface attributes are specified herein.

V2.CTRL.HW.004

[Selectable]

If selected, the OCU shall provide one or more of the following standard audio jacks:

Table 7: V2.CTRL.HW.004

V2.CTRL.HW.004a [Selectable]

The OCU should provide a standard 2.5 mm miniature style TRS (tip, ring, sleeve) connector.

V2.CTRL.HW.004b [Selectable]

The OCU should provide a standard 3.5 mm miniature style TRS (tip, ring, sleeve) connector.

V2.CTRL.HW.004c [Selectable]

The OCU should provide a standard 2.5 mm miniature style TS (tip, sleeve (mono)) connector.

V2.CTRL.HW.004d [Selectable]

The OCU should provide a standard 3.5 mm miniature style TS (tip, sleeve (mono)) connector.

3.2.5 USB Requirement

An OCU shall provide USB interface connector(s) as defined by the Universal Serial Bus Specification, Revision 2.0.

V2.CTRL.HW.005 OCU shall provide one or more standard USB 2.0 connectors.

Table 8: V2.CTRL.HW.005

V2.CTRL.HW.005a [Selectable]

The OCU should provide a micro USB 2.0 connector. Note that Micro-OCU's may require this type of port as a power/re-charging port thus making this requirement [Mandatory].

V2.CTRL.HW.005b [Selectable]

OCU should provide a mini USB 2.0 connector. Note that Micro- OCU's may require this type of port as a power/re-charging port thus making this requirement [Mandatory].

3.2.6 Serial Interface Requirement

If selected, an OCU shall provide an external serial interface connector (separate from RAS-G IOP Communications Profile) as defined by EIA/TIA-232-F specification.

V2.CTRL.HW.006

[Selectable]

If selected, an OCU shall provide an external RS-232 serial connector.

3.2.7 Video Interface Requirement

Many unmanned vehicles have video sensors on them in order to support capabilities such as teleoperation, (semi-)autonomous behaviors, etc.. The following attribute lists the requirements for hardware support for video sensors.

V2.CTRL.HW.007

[Selectable]

If selected, the OCU shall provide one or more of the following external video interfaces:

Table 9: V2.CTRL.HW.007

V2.CTRL.HW.007a [Selectable]

If selected, an OCU shall provide one or more standard external HDMI video connector as defined by the Consumer Electronics Association CEA-861-E specification.

V2.CTRL.HW.007b [Selectable]

If selected, an OCU shall provide external mini HDMI video port.

V2.CTRL.HW.007c [Selectable]

If selected, an OCU shall provide one or more external DVI video connector as defined by the Consumer Electronics Association CEA-861-E specification.

V2.CTRL.HW.007d [Selectable]

If selected, an OCU shall provide one or more standard external VGA video connector.

V2.CTRL.HW.007e [Selectable]

If selected, the OCU shall provide dual HDMI/DVI/other display ports for use with a stereovision head mounted display.

3.2.8 Ethernet Interface Requirement

The use of Ethernet is further profiled in the IOP Communications document. The following are attributes specific to the OCU, that work in conjunction with what is specified in that document. Ethernet is specified in IEEE 802.3ab.

V2.CTRL.HW.008

[Selectable]

If selected, an OCU shall provide an external RJ-45 Ethernet jack connector.

Table 10: V2.CTRL.HW.008

V2.CTRL.HW.008a [Selectable]

If selected, an OCU shall provide an external RJ-45 Ethernet jack connector.

V2.CTRL.HW.008b [Selectable]

An OCU should provide 802.11 wireless Ethernet.

3.2.9 Display Interface Requirement

An OCU may provide a touch screen interface for different control functions. Please note that this is selectable based on program requirements.

V2.CTRL.HW.009 The OCU shall provide a display per the following:

Table 11: V2.CTRL.HW.009

V2.CTRL.HW.009a [Selectable]

If selected, an OCU shall provide a touch screen interface for different control functions.

V2.CTRL.HW.009b [Selectable]

The display screen on an OCU shall be sunlight readable.

V2.CTRL.HW.009c [Selectable]

The display screen on the OCU shall have a backlit display capability.

3.2.10 Smart Card Reader Interface Requirement

V2.CTRL.HW.010

[Selectable]

If selected, an OCU shall provide a smart card reader interface (smart card could be integrated into the keyboard on larger OCU types).

3.3 OCU Size Categories

An OCU is an aggregation of integrated attributes (i.e., HMI, Software, devices, and interfaces). This section provides for specification of common OCU configurations as a function of size category.

3.3.1 OCU Size Categories

Parent Attribute: OCU Hardware Attribute

Each OCU size category (i.e., micro, small, medium, etc.) is referenced by a unique sub-requirement defined below. Although the size sub-requirements are themselves mutually exclusive, a program could require more than one size OCU to be profiled.

Multiple profiles for differing sized OCU's can be built but each requires separate specifications for its size. Detailed below are typical requirements that are associated with each OCU size category. A minimum resolution of 800 x 480 is required for each of these.

3.3.1.1 Micro OCU

A micro OCU is a handheld device (approximately cell phone size) including external connections and accessories. It should possess the following attributes at a minimum.

Table 12: Micro OCU Description

Attribute Description Related Requirements Man Portable Yes Man Portable Requirement Stationary Or Dynamic Environment

Dynamic

Display Size Range 3 inches minimum USB Port(s) 1 mini USB (minimum) USB Requirement Sunlight Readable Yes Sunlight Readable

Requirement Backlit Yes Backlit Requirement External Connections Charging port, headphones, 3.5 mm jack, Head Mounted Display (possible)

OCU Power Requirement

3.5 mm TS Connector Requirement HDMI Video Port Requirement

Video/Picture Storage Yes GPS Yes Hard Buttons 3 minimum (with one hard power button)

Joystick Capability Touch Screen Selectable Touch Screen

Requirement RS 232 Serial Interface No Serial Interface

Requirement Volume Control Yes Contrast Adjustment Yes Backlit Display

Requirement Brightness Adjustment Yes Backlit Display

Requirement

3.3.1.2 Small OCU

A Small OCU is approximately laptop size, including external connections and accessories. It should be man portable by one person. It should possess the following attributes at a minimum.

Table 13: Small OCU Description

Attribute Description Related Requirements Man Portable Yes Man Portable Requirement Stationary Or Dynamic Environment

Dynamic

Display Size Range 6 inches minimum USB Port(s) 2 USB 2.0 minimum USB Requirement

Sunlight Readable Yes Sunlight Readable Requirement

Backlit Yes Backlit Requirement External Connections Headphones, 3.5 mm jack, VGA, DVI, charging port, Ethernet connection, coax cable

OCU Power Requirement

3.5 mm TS Connector Requirement VGA Requirement DVI Requirement Ethernet Requirement

Video/Picture Storage Yes GPS Yes Hard Buttons 6 minimum Joystick Capability Yes Touch Screen Selectable Touch Screen Requirement RS 232 Serial Interface Yes Serial Interface Requirement Volume Control Yes Contrast Adjustment Yes Backlit Display Requirement Brightness Adjustment Yes Backlit Display Requirement

3.3.1.3 Medium OCU

A Medium OCU is approximately computer desktop size, including external connections and accessories. It should be man portable by no more than 4 people. It should possess the following attributes at a minimum.

Table 14: Medium OCU Description

Attribute Description Related Requirements Man Portable Yes Man Portable Requirement Stationary Or Dynamic Environment

Dynamic

Display Size Range 6 inches minimum USB Port(s) 2 USB 2.0 minimum USB Requirement

Sunlight Readable No Sunlight Readable Requirement

Backlit No Backlit Requirement External Connections Coax cable Video/Picture Storage Yes GPS No Hard Buttons 6 minimum Joystick Capability Touch Screen Selectable Touch Screen Requirement RS 232 Serial Interface Yes Serial Interface Requirement Volume Control Yes Contrast Adjustment Yes Backlit Display Requirement

Brightness Adjustment Yes Backlit Display Requirement

3.3.1.4 Vehicle Embedded OCU

A Vehicle Platform Embedded OCU is a vehicle mounted crew station not expected to be removed from a manned vehicle platform, including external connections and accessories. It should possess the following attributes at a minimum.

Table 15: Vehicle Embedded OCU Description

Attribute Description Related Requirements Man Portable No Man Portable Requirement Stationary Or Dynamic Environment

Dynamic

Display Size Range 8 inches minimum USB Port(s) 2 USB 2.0 minimum USB Requirement

Sunlight Readable No Sunlight Readable Requirement

Backlit No Backlit Requirement External Connections Coax cable Video/Picture Storage Yes GPS No Hard Buttons 6 minimum Joystick Capability Touch Screen Selectable Touch Screen Requirement RS 232 Serial Interface Yes Serial Interface Requirement Volume Control Yes Contrast Adjustment Yes Backlit Display Requirement Brightness Adjustment Yes Backlit Display Requirement

3.3.1.5 Stationary OCU

A Stationary OCU is a stationary command and control center, which is not located within a vehicle platform, but is located in its own facility space, either outside in the environment or inside a building. It would be a coordinated multiple person effort to move this type of command and control center. It should possess the following attributes at a minimum.

Table 16: Stationary OCU Description

Attribute Description Related Requirements Man Portable No Man Portable Requirement Stationary Or Dynamic Environment

Stationary

Display Size Range 8 inches minimum USB Port(s) 2 USB 2.0 minimum USB Requirement

Sunlight Readable No Sunlight Readable Requirement

Backlit No Backlit Requirement External Connections Video/Picture Storage Yes GPS No Hard Buttons 6 minimum Joystick Capability Touch Screen Yes Touch Screen Requirement RS 232 Serial Interface Yes Serial Interface Requirement Volume Control Yes Contrast Adjustment Yes Backlit Display Requirement Brightness Adjustment Yes Backlit Display Requirement

3.3.1.6 OCU Size Requirement

V2.CTRL.HW.011 The OCU shall fall into a size category of one of the following sizes

(multiple size formats may be specified - each profiled separately):

Table 17: V2.CTRL.HW.011

V2.CTRL.HW.011a [Selectable]

If selected, the OCU shall specify a micro OCU: handheld device (approximately cell phone size).

V2.CTRL.HW.011b [Selectable]

If selected, the OCU shall specify a small OCU: approximately laptop size.

V2.CTRL.HW.011c [Selectable]

If selected, the OCU shall specify a medium OCU: approximately computer desktop size.

V2.CTRL.HW.011d [Selectable]

If selected, the OCU shall specify Vehicle Platform Embedded OCU: vehicle mounted crew station not expected to be removed from a manned vehicle platform.

V2.CTRL.HW.011e [Selectable]

If selected, the OCU shall specify Stationary OCU: stationary command and control center, which is not located within a vehicle platform, but is located in its own facility space, either outside in the environment or inside a building.

3.3.1.7 Man Portable Requirement

Man-portability is described in the Joint Publication 1-02, Department of Defense Dictionary of Military and Associated Terms as the following:

“Capable of being carried by one man. Specifically, the term may be used to qualify: 1.

Items designed to be carried as an integral part of individual, crew served, or team equipment of the dismounted soldier in conjunction with assigned duties. Upper weight limit: approximately 14 kilograms (31 pounds.) 2. In land warfare, equipment which can be carried by one man over long distance without serious degradation of the performance of normal duties.”

Additionally, the Controls IOP defers to the requirements, unless otherwise specified, listed in Mil-std 1472g.

V2.CTRL.HW.012 [Selectable] The OCU shall be man portable per the following.

Table 18: V2.CTRL.HW.012

V2.CTRL.HW.012a

The OCU shall be man portable.

4 Software Section This section is to be utilized as guidance to aid system developers in the development and implementation of control and display systems for ground vehicle systems, providing a framework allowing system developers to effectively locate controls and information/status elements that are common across most unmanned vehicle platforms for specific functionality. The Material Developer will specify specific ID(s) for each piece of functionality that a given system requires. The ID(s) are selected based on the specific mission requirements for that system. For, example the Sensors Section lists a wide variety of sensors that may not all be required to accomplish the mission requirements for that specific system. The Material Developer will select the particular ID(s) that align to the mission requirements for that specific system. Use of this guidance will also serve to drive consistency across unmanned platform programs through common placement, accessibility and graphic/control design (when applicable).

This guidance does not preclude controller developers from using novel and innovative control techniques to meet overall system requirements.

4.1 Core Software and Logical Attribute

To the degree possible, and in accordance with the RAS-G IOP Overarching Profile, this IOP uses the SAE AS-4 Joint Architecture for Unmanned Systems (JAUS) standards to define the control and status messages transmitted between an Operator Control Unit (OCU) and the UGV, its subsystems and payloads. The RAS-G IOP SAE JAUS Profiling Rules document provides guidance with respect to the profiling of the JAUS standard to describe the core software requirements of a JAUS system, which the OCU is, and to define the manner in which JAUS messages are applied/interpreted as a means of limiting ambiguity and maximizing interoperability among disparate vendors.

As applicable, other standards are specified. For example, the Common CBRN Sensor Interface (CCSI) is called out for Chemical, Biological, Radiologic and Nuclear sensor interfaces.

Mapping from the OCU's HMI controls to the appropriate logical interface is not always a one-to-one correspondence. It is not the intent of this document to provide details on how this is accomplished except in cases where the mapping would not be "obvious."

4.1.1 HMI Requirements

The function tables provided in this section serve as guidelines for the implementation of common control capabilities and information/status elements of unmanned ground systems. Each function table consists of a group of related Controls IOP requirements.

While an extensive set of capabilities are referenced in the tables, it is intended for a system designer to select only the requirements that are relevant to their system. Cells in the tables associated with this document that are blank will be left to the discretion of the implementer. (Note that tables will be periodically updated and updates will be released as needed) The guidelines manifest themselves in the form of requirements associated with each control type and status element. These requirements include an ID, a brief description of the function/task, a Control vs Status determination, access level determination, and the presentation of a common widget/icon/graphic (when applicable). They are further described below.

ID

Presents the ID of the requirements, and any/all sub-requirements. See the Interoperability Attributes And Modifiers Section for a detailed description of the format of the requirement/sub-requirement IDs.

Function/task

Presents a brief description of the task or function associated with the ID (e.g. "select asset gear" and "switch between local and Zulu time display").

Control/Status

HMI elements can be classified into two main categories: control(C) or status(S).

Controls enable functionality and statuses provide information and feedback.

Levels of Information Accessibility

Specifying levels of information accessibility will allow a system designer to quickly identify where a control or function should be placed within the hardware and/or navigation scheme of the OCU human machine interface (HMI). This effort will not specify the exact location of the function or control within the interface but rather provide guidance on what common controls and status should be present within each layer of the navigation scheme. If a given attribute is associated with multiple levels of accessibility it will be up to the acquisition program to determine how that attribute will be placed within the HW/SW interface. Should this document specify a lower level of access than desired, the control may be promoted to meet the programs needs (i.e.

SW2 is specified and SW1 is desired; the control can be placed at SW1).

Table 19: Levels of Information Accessibility

Information Description Criteria

Level

OCU

Hardware Device

HW,

HW-

covered

Implementation would occur on a hardware input/output device.

This includes buttons, switches, lights, etc located on the OCU enclosure, including the screen bezel, as well as joysticks, gamepads, trackball, keyboard, etc. that may be attached to the OCU with a cable or mounted to the OCU enclosure.

A set of recommended joystick and gamepad input device mappings will also be provided as part of this effort; see Appendix A and Appendix B.

HW-covered is a switch or button with a protective cover to reduce the likelihood of accidental activation.

1. Mission Critical -immediate access is critical to mission success and/or crew safety

2. Frequency of Use -function is frequently used, must always be accessible to maintain reasonable crew performance

3. Sequence of Use -function is a required action/step in a mission critical or frequent task

4. Necessary for hardware use (example: OCU power button)

Software Level P - Persistent Status & Navigation

SWP Persistent area(s) within the interface containing critical status/alert information and controls such as those for basic navigation. The size and arrangement of persistent area(s) are dependent on display size and desired content. The persistent area(s) are always present in the same location no matter where the user has navigated to in the interface.

Software Level 1 - First Level

SW1 Implementation would occur one level in from any other part of the HMI, i.e., controls, status, imagery, etc. at this level would always be accessible from high level basic navigation buttons (1-2 button presses, mouse overs for status items, or user commands to get to function depending on navigation scheme). Ex: Teleop functionality on a screen accessible from basic navigation buttons

Software Level 2 - Second Level+

SW2 Functionality would be accessible from within software level 1. This would require 3+ button presses or user commands from anywhere else in navigation scheme to get to functionality. Ex: a menu or on a �child� screen to the �parent� main control screen

1. not frequently used

2. not critical to mission capability

Any number of the following attributes can be chosen.

Table 20- 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.1.2 Power Requirement

Power control functions for an OCU are very similar to those of a computer. Some functions are accessible at multiple levels i.e. hardware and through the software interface.

V2.CTRL.HMI.001 The OCU and/or HMI shall provide the capability for controlling the power function of the OCU per the following:

Table 21: V2.CTRL.HMI.001

ID Function/Task Control

(C) or Status (S)

Access Level

Common Widget or Icon/Graphic

V2.CTRL.HMI.001a The HMI shall have a hardware control for powering on and off.

C HW

V2.CTRL.HMI.001b [Selectable]

If selected, the HMI shall provide a control capability to activate/deactivate a power save function.

C HW,

SW1

Icons

V2.CTRL.HMI.001c

If selected, the HMI shall provide a status capability to view indication that power save is active.

S SW1 Icons

Statuses

V2.CTRL.HMI.001d

If selected, the HMI shall provide a soft control should be implemented for powering off.

C SW2 Icons

4.1.3 Authentication Requirement

Authentication for a controller can be done at multiple levels. After booting a controller, the operating system should prompt a user for their authentication. It is left to the acquisition program as to whether or not this authentication is carried through to the authentication of the operator gaining control of the robot. Otherwise authentication may be required at the level of the controller�s software, and again at the level of gaining control of a robot. Other authentication topics, such as authenticating a request for a control within the system (e.g. render useless) are discussed elsewhere in this document.

In addition to prompting the user for their credentials, the acquisition program may require the use of a smart card reader for authentication. If this requirement is chosen a means of logging in without a smart card is recommended as an alternative login.

V2.CTRL.HMI.002 The HMI shall provide the capability to login and control the WMI per the following:

Table 22: V2.CTRL.HMI.002

(C) or

Access Level

Common Widget or

Status (S) Icon/Graphic V2.CTRL.HMI.002a The HMI shall have a means for a user to login and be authenticated as a trusted user.

C SW1

V2.CTRL.HMI.002b [Selectable]

If selected, the HMI shall have a control capability to start the HMI software.

C SW2

V2.CTRL.HMI.002c [Selectable]

If selected, the HMI shall have a control capability to shut down the HMI software.

C SW2

V2.CTRL.HMI.002d [Selectable]

If selected, the HMI shall make use of smart card reader for authentication.

C HW

V2.CTRL.HMI.002e [Selectable]

If selected, the HMI shall have a control capability to log out of the HMI software.

C SW1 Icons

4.1.4 Robotic Selection Requirement

Robotic Selection can be done numerous ways. This IOP document will not require an implementation but rather suggest guidelines. Robotic Selection should at a minimum be able to present the operator with the available assets within range of the controller, and display information available from queries sent to those platforms. Selection of an asset can be aided by search functions and filters on said information, if desired.

Example information to display to the operator when querying the available assets includes, but is not limited to:

Table 23: Example Platform Information for Display when Selecting a Robotic Asset

Status Information

Description

Location Location of the platform Range Calculated distance to the platform Signal Strength Strength of signal between OCU and platform Operators logged in

Current operators logged into the asset, and their roles (based on IOP JAUS profiling)

Unit type i.e. 'talon', 'packbot', etc.

Platform Designation

"name" given to platform

Platform Mode The operational mode the platform is currently in.

Health Status The overall health of the platform Platform Capabilities

Behaviors (e.g. autonomous functions) and capabilities (e.g. stair climbing, manipulator arm, sensor types, etc.)

V2.CTRL.HMI.003 The HMI shall provide a means of detection, selection, and reporting on robotic assets per the following:

Table 24: V2.CTRL.HMI.003

(C) or Status (S)

Access Level

Common Widget or Icon/Graphic

V2.CTRL.HMI.003a The HMI shall have a control capability to display available, controllable assets within range.

V2.CTRL.HMI.003b The HMI shall have a control capability to select a robotic asset to request control of (i.e.

login).

Actions

V2.CTRL.HMI.003c The HMI shall have the capability to display to the operator the results from robotic asset once control is requested.

S SW2 Icons

V2.CTRL.HMI.003d The HMI shall have the the operator an indication that communication with the selected asset has been established.

V2.CTRL.HMI.003e The HMI shall have the the operator the current asset control modes for each asset, including self (Ex: mobility control, payload control, monitors).

V2.CTRL.HMI.003f The HMI shall have a select/request unmanned vehicle control mode(s) (Ex:

mobility control, payload control, monitor (default)).

C SW1

V2.CTRL.HMI.003g The HMI shall have a logout (terminate comms) of an asset.

V2.CTRL.HMI.003h The HMI shall have the the operator a logout confirmation (indication that communication with asset has been terminated).

V2.CTRL.HMI.003i The HMI shall have the the operator that a robotic vehicle is powered up.

4.1.5 Display Requirement

V2.CTRL.HMI.006 The HMI shall have the capability to control the display per the following:

Table 25: V2.CTRL.HMI.006

(C) or Status (S)

Access Level

Common Widget or Icon/Graphic

V2.CTRL.HMI.006a The HMI shall have a means to turn display/backlight power on/off (quick access for visual signature control).

C HW,

SWP

V2.CTRL.HMI.006b If selected, the HMI shall have a control capability to adjust brightness of the display.

C HW,

SW2

V2.CTRL.HMI.006c If selected, the HMI shall have a control capability to adjust the contrast of the display .

C HW,

4.1.6 Speaker and Microphone Requirement

V2.CTRL.HMI.007 If selected, the HMI shall have the ability to control speaker

[Selectable] and microphone interfaces via the following controls and status:

Table 26: V2.CTRL.HMI.007

(C) or Status (S)

Access Level

Common Widget or Icon/Graphic

V2.CTRL.HMI.007a [Selectable]

If selected, the HMI shall have a control capability to adjust the OCU speaker volume (0 to 100%).

C HW,

V2.CTRL.HMI.007b

If selected, the HMI shall have a control capability to mute/unmute the OCU speaker/microphone (quick access for audio signature control).

C HW,

V2.CTRL.HMI.007c

If selected, the HMI shall have the capability to display to the operator an indication that the

OCU

speaker/microphone is muted.

4.1.7 Hand Controller Requirement

V2.CTRL.HMI.008

[Selectable]

If selected the HMI shall provide the capability to monitor the hand-controller (i.e. joystick, game controller, other) per the

Table 27: V2.CTRL.HMI.008

(C) or Status (S)

Access Level

Common Widget or Icon/Graphic

V2.CTRL.HMI.008a [Selectable]

If selected, the HMI shall provide the capability to display to the operator an indicator that the

S SWP Icons hand controller is disengaged (WCA implication).

V2.CTRL.HMI.008b

If selected, the HMI shall provide the capability to display to the operator an indicator that the hand controller is not working properly (WCA implication). Note this may be an OS specific (i.e. driver not working properly) task.

4.1.8 Head Mounted Display Requirement

V2.CTRL.HMI.010

[Selectable]

If selected, the HMI shall provide the capability to communicate, control and receive status from a head mounted display per the following:

Table 28: V2.CTRL.HMI.010

(C) or Status (S)

Access Level

Common Widget or Icon/Graphic

V2.CTRL.HMI.010a The HMI shall have the capability to adjust the frames per second streaming to the device.

Note that this capability may overlap with the camera's capability of controlling the frames per second.

C SW1

V2.CTRL.HMI.010b The HMI shall have the capability to display to the operator frames per second indicator streaming to the device.

Note that this capability may overlap with the camera's capability of displaying the frames per second.

S SW1

V2.CTRL.HMI.010c If selected, the HMI shall C HW, Icons

[Selectable] provide the capability to set the sensor vision (color, polarity, etc.).

Note that this capability may overlap with the camera's capability of controlling the sensor vision (color, polarity, etc.).

V2.CTRL.HMI.010d

If selected, the HMI shall provide the capability to display to the operator the current sensor vision (color, polarity, etc.).

Note that this capability may overlap with the camera's capability of displaying the current sensor vision (color, polarity, etc.).

V2.CTRL.HMI.010e

If selected, the HMI shall provide the capability to select a region of interest within the video stream to present to the user.

C SW2

V2.CTRL.HMI.010f [Selectable]

If selected, the HMI shall provide the capability to adjust the gain. Note that this capability may overlap with the camera's capability of adjusting the gain.

C SW2

V2.CTRL.HMI.010g [Selectable]

If selected, the HMI shall provide the capability to display to the operator the current gain. Note that this capability may overlap with the camera's capability of adjusting the gain.

S SW1

V2.CTRL.HMI.010h [Selectable]

If selected, the HMI shall provide the capability to adjust the resolution of the video being streamed to the device.

Note that this capability

C SW2

may overlap with the camera's capability of adjust the camera's current resolution.

V2.CTRL.HMI.010i [Selectable]

If selected, the HMI shall provide the capability to display to the operator the current resolution being streamed to the device. Note that this capability may overlap with the camera's capability of displaying the current resolution.

S SW1

4.1.9 Date/Time Display Requirement

V2.CTRL.BAS.001

[Selectable]

If selected, the HMI shall provide the capability to control the displayed date and time per the following:

Table 29: V2.CTRL.BAS.001

(C) or Status (S)

Access Level

Common Widget or Icon/Graphic

V2.CTRL.BAS.001a [Selectable]

If selected, the HMI shall provide the capability to display to the operator date and time in Date- Time-Group(DTG) format for either or both local and Zulu times.

V2.CTRL.BAS.001b

If selected, the HMI shall have a control capability to switch between local and Zulu time display.

C SW2

4.1.10 Asset Display Requirement

V2.CTRL.BAS.002 The HMI shall have the capability of displaying basic asset status

Table 30: V2.CTRL.BAS.002

ID Function/Task Control Access Common

(C) or Status (S)

Level Widget or Icon/Graphic

V2.CTRL.BAS.002a The HMI shall have the capability to display indication of (selected) asset of interest on all relevant screens.

S SWP

V2.CTRL.BAS.002b The HMI shall have the capability to display to the operator an asset's location/coordinates.

V2.CTRL.BAS.002c The HMI shall have the the operator the asset's heading (compass tape, digital) .

V2.CTRL.BAS.002d

If selected, the HMI shall have the capability to display to the operator a unique identifier/call sign for each asset.

S SW1

V2.CTRL.BAS.002e [Selectable]

If selected, the HMI shall have the capability to display to the operator a current pitch/roll/attitude indicator (WCA

V2.CTRL.BAS.002f

If selected, the HMI shall have the capability to display to the operator the direction and distance from the OCU to the asset.

S SW1

4.1.11 Payload Status Requirement

V2.CTRL.BAS.008

[Selectable]

If selected, the HMI shall provide the capability to command, control and receive feedback from a payload per the

Table 31: V2.CTRL.BAS.008

(C) or Status (S)

Access Level

Common

Icon/Graphic

V2.CTRL.BAS.008a

If selected, the HMI shall provide the capability to display to the operator an indication of a system/subsystem/paylo ad functional status (WCA implication).

S SW2

4.2 Global Attribute Section

Global Interoperability Attributes are attributes that do not fall into any other specific category.

4.2.1 Global Attribute

Parent Attribute: Core Software and Logical Attribute

Table 32- Optional Select = any

Pose And Attitude Attribute Adds ability to view/ report the pose and attitude of a platform. Many other capabilities are built upon this information.

Power Plant Management Attribute

Provides the ability to get information from and manage a power plant, which may be batteries, a gasoline engine, a diesel engine, or a hydraulic system.

Preset Pose Attribute Provides the ability to get information on available preset poses that a platform or payload has, and to command that platform or payload to go to one of those preset poses (i.e. a "Stow" pose for storing a system).

Render Useless Attribute Defines the capability to render a platform, payload, or other device useless.

Tamper Detection Attribute Defines the capability to report on when tampering has occurred.

Obstacle Reporting Attribute Provides a way to report obstacles, hazardous terrain, and no-go zones using an overhead 2D cost map.

SoftwareVersionReportingAttribute Provides the ability for a JAUS component to describe the software packages, shared libraries, scripts, etc. installed on it.

4.2.2 Pose And Attitude Attribute

Parent Attribute: Global Attribute

The Pose And Attitude Attribute provides the capability to view/ report the pose and attitude of a platform. Many other capabilities are built upon this information.

Table 33- Optional Select = any

Basic Global Position and Attitude Attribute

Defines the capability to report Basic Global Position and Attitude.

4.2.2.1 Asset Location Display Requirement

V2.CTRL.BAS.003

[Selectable]

If selected, the HMI shall have the capability to control and display location/coordinate information per the following:

Table 34: V2.CTRL.BAS.003

(C) or Status (S)

Access Level

Common Widget or Icon/Graphic

V2.CTRL.BAS.003a [Selectable]

If selected, the HMI shall have the capability to display to the operator the OCU location/coordinates (longitude, latitude, altitude).

V2.CTRL.BAS.003b

If selected, the HMI shall have a control capability to display to the operator coordinates in multiple formats (longitude/latitude/altitud e, MGRS, UTM, other).

C SW2

V2.CTRL.BAS.003c [Selectable]

If selected, the HMI shall have a control capability to adjust the number of coordinate digits displayed.

4.2.3 Basic Global Position and Attitude Attribute

Parent Attribute: Pose And Attitude Attribute

4.2.3.1 GPS Requirement

V2.CTRL.BAS.006

[Selectable]

If selected, the HMI shall command, control and receive feedback from a GPS per the following:

Table 35: V2.CTRL.BAS.006

(C) or Status (S)

Access Level

Common Widget or Icon/Graphic

V2.CTRL.BAS.006a [Selectable]

If selected, the HMI shall provide the capability to display to the operator the current OCU GPS status/strength.

4.2.3.2 Parameter Listing

Table 36- Parameter Listing for Basic Global Position and Attitude Attribute

Parameter Name

Default Value

Allowed Values

Description

Report Rate Parameter

1 <Range> 0..65535

The report rate parameter defines the minimum rate at which the Global Pose Sensor must be able to send Report Global Pose messages, either through a periodic Event (urn:jaus:jss:core:events) or by responding to regularly sent QueryGlobalPose messages. This parameter should be defined to allow for safe operation of the platform.

4.2.4 Power Plant Management Attribute

The Power Plant Management Interoperability Attribute provides a way to query status of and control power plants. Four types of power plants are supported: batteries, diesel engine, gasoline engine, and hydraulic system. For each of these four types, the capabilities can be reported and the configuration (how the power plant is currently configured) can be reported and changed.

4.2.4.1 Battery Status Requirement

V2.CTRL.BAS.004 The HMI shall have the capability to display to the operator both asset and HMI battery status per the following: (note that additional batteries such as a separate one for the radio would also fall under this category)

Table 37: V2.CTRL.BAS.004

(C) or Status (S)

Access Level

Common Widget or Icon/Graphic

V2.CTRL.BAS.004a The HMI shall indicate to the operator when battery charging is occurring and…