IOP V3 - Overarching March 2018.pdf

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

Overarching Profile Version 3.0

Project Manager, Force Projection (PM FP)

SFAE-CSS-FP MS 401

6501 East 11 Mile Road

Warren, MI 48397

March 2018

Distribution A: Approved for Public Release

Contents 1 Scope

1.1 Purpose

1.2 Document Structure & Overview

1.3 Discussion of Technical Topics

1.3.1 Interoperability Attributes

1.3.2 RAS-G Classes of Vehicles

1.3.3 Implementation of Standards

1.3.4 Control and Status Messages & JAUS Profiling

1.3.5 Custom Services, Messages, and Transports

1.3.6 Latency

1.3.7 Conformance Validation

2 Source Documents

2.1 Government Documents

2.2 Non-Government Documents

3 Architecture

3.1 System Context

3.2 Reference Architecture

3.2.1 Operator Control Unit (OCU)

3.2.2 Common Communications Link (CCL)

3.2.3 Unmanned Ground Vehicle (UGV)

3.2.4 External Command & Control (C2)

3.2.5 Other Unmanned Vehicles (UxVs)

3.3 UGV Logical Internal Architecture

4 IOP Usage Guide

4.1 Overview of IOP Usage Process

4.2 IOP Usage

4.2.1 Usage of Overarching IOP

4.2.2 Usage of Communications IOP

4.2.3 Usage of Payloads IOP

4.2.4 Usage of Appliqué IOP

4.2.5 Usage of Control IOP

4.2.6 Usage of JAUS Profiling Rules IOP

4.2.7 Usage of Custom Services, Messages & Transports IOP

4.3 Non-compliance

4.4 Deprecation

4.5 Integration with Other Standards Efforts

4.5.1 ROS-M

4.5.2 Logistics and SA

4.5.3 VICTORY

4.5.4 SAE

5 Appendix A – Acronyms and Abbreviations

6 Appendix B – Definitions

7 Appendix C – Compatibility with AEODRS

7.1 Payloads IOP Compatibility

7.1.1 Connectors

7.2 Video and Audio Streaming

7.3 Communications IOP Compatibility

7.4 JAUS Profiling Rules IOP Compatibility

7.4.1 Digital Video

7.4.2 Digital Audio

7.4.3 JAUS Logical ID Assignment

7.4.4 Transport

1 Scope

1.1 Purpose

The Department of Defense (DoD) has launched an initiative to identify and define interoperability standards to be organized and maintained within a Robotics and Autonomous Systems – Ground (RAS-G) Interoperability Profile (IOP). This IOP will be employed by Unmanned Ground Vehicle (UGV) acquisition managers in the acquisition of future Programs of Record, the upgrade of fielded systems, and the evaluation/acquisition of Commercial-Off-The-Shelf (COTS) products. Throughout this document, the terms RAS-G and UGV are used interchangeably.

A primary goal of this initiative is to leverage existing and emerging standards within the Unmanned Vehicle (UxV) community such as the Society of Automotive Engineers (SAE) AS-4 Joint Architecture for Unmanned Systems (JAUS) standard and the Army Unmanned Aircraft Systems (UAS) Project Office IOPs. The Advanced Explosive Ordnance Disposal Robotic System (AEODRS) Architecture Description Documents (which uses SAE AS-4) has been leveraged significantly. The end goals of this effort are:

– Facilitating interoperability among new UGV initiatives and legacy systems;

– Facilitating interoperability between controllers and UxV robotic system(s);

– Facilitating collaboration between UGV and UAS systems;

– Providing a path forward to standardized interoperable technology solutions

– Promoting payload and on-board subsystem modularity and commonality across the portfolio of UGV systems.

IOP Version 3.0 (V3) has been developed using a government/industry Working Integrated Product Team (WIPT) structure, and defines the interoperable interfaces and protocols necessary to enable interoperability and modularity to be introduced to the capabilities that have already been widely fielded. The exact set of capabilities addressed in IOP V3 is described in the RAS-G IOP V3 Capabilities Plan. The DoD intends to publish annual revisions to the IOP in order to expand and evolve its scope as necessary, based on the evolution of Warfighter capability requirements and technological advances.

1.2 Document Structure & Overview

This document provides the base concepts, architecture, requirements, and overview for the RAS-G IOP; and specifically addresses platform, payload, mobility, on-vehicle network, communication, and logical interoperability messaging requirements.

Additionally, this document introduces and presents the conformance and validation approach to be employed within the IOP. The complete set of documents that comprise the RAS-G IOP and their intended usage is presented below.

Figure 1: RAS-G IOP Documents

RAS-G IOP – Overarching Profile In addition to the topics specified above, this document also provides two separately published attachments that comprise the Overarching IOP V3. These attachments are described below:

– RAS-G IOP V3 – Capabilities Plan Defines capability requirements related to the employment and usage of UGVs to perform current and relevant near-term robotic missions, in turn scoping and bounding the content of the RAS-G IOP. This Capabilities Plan is based on a mission analysis that reviewed the usage of currently fielded and near term UGVs, and the capability requirements of a number of existing and emerging Programs of Record.

– RAS-G IOP – SAE JAUS Profiling Rules

Specifies the manner in which the SAE AS-4 JAUS standards have been profiled, to include clarification or additional content to define interoperability between controllers and UGVs as well as intra-UGV (platform/subsystem) interoperability.

– RAS-G IOP – Custom Services, Messages and Transports Specifies additional, custom SAE AS-4 JAUS messages and transport protocols required to support the scope of the RAS-G IOP. Although titled "custom", these messages are published and standardized within the RAS-G IOP community with the end goal of transitioning to the SAE AS-4 JAUS standard(s) or other standards bodies for official adoption.

RAS-G IOP – Control Profile This document specifies the Operator Control Unit (OCU) logical architecture, standards, Human-Machine Interface (HMI) requirements, and conformance approach to include host application user interface requirements, such as mission planning and command and control. Although OCU concepts and high level architecture are touched upon in the Overarching Profile, the Control Profile provides the more detailed requirements to specify how interoperability is to be achieved for conformant controllers.

RAS-G IOP – Payloads Profile This document specifies the payload classification, standards, requirements, and conformance approach. Although these concepts are touched upon in the Overarching Profile, the Payloads Profile provides the more detailed requirements to specify the interoperability requirements for payloads with respect to the UGV platform.

RAS-G IOP – Communications Profile This document specifies the communications standards, requirements, and conformance approach. Although these concepts are touched upon in the Overarching Profile, the Communications Profile provides the more detailed requirements to specify interoperability requirements for communications between and among controllers and UGVs.

RAS-G IOP - Applique Profile This document (new as of IOP V2) specifies the appliqué systems classification, standards, requirements, and conformance approach. Although these concepts are touched upon in the Overarching Profile, the Applique Profile provides the more detailed requirements to specify the interoperability requirements for appliqué systems with respect to the unmanned ground systems, controllers, and base manned vehicle systems.

1.3 Discussion of Technical Topics

1.3.1 Interoperability Attributes

The RAS-G IOP has been designed to support interoperability on a variety of missions and objectives, vehicle classes/types, controller classes/types, payload classes/types, physical/software architectures, and interaction with external systems (e.g., networks, C2). Since every interoperability requirement will not be applicable to every system, the IOP provides a mechanism to independently specify these requirements in a composable, hierarchical manner, using Interoperability Attributes. In this way, Interoperability Attributes applicable to the specification and design of a system 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.

Throughout the RAS-G IOP, the term "Interoperability Attributes" has been designated to identify these composable, hierarchical capabilities, which may be specified in the application of the RAS-G IOP to a system acquisition activity. System requirements specified in the RAS-G IOP are tagged, accordingly, with Interoperability Attribute designations. The manner in which the attribute is to be interpreted is also specified within the RAS-G IOP. It is acknowledged that UGV requirements will vary based upon capability, mission, and other acquisition requirements. For this reason, the Interoperability Attributes defined within this IOP specify the robotic system capabilities in a granular fashion, from the most simple to the most complex.

The Project Management (PM) office has the responsibility for identifying the Interoperability Attributes applicable to each acquisition program. The prime systems developer has the responsibility for implementing the RAS-G IOP in accordance with the specified Interoperability Attributes, and the conformance and validation tester has the responsibility for developing and executing conformance tests, based on those Interoperability Attributes.

Figure 2: Mission/RAS-G IOP Flowdown

As shown in Figure 2: Mission/RAS-G IOP Flowdown above, the RAS-G Vx Capability Plan document identifies specific capabilities and functionality that are within scope of the current Version level of the IOP effort. These requirements flow directly or indirectly to individual IOPs where additional levels of detail are derived to support the IOP objectives. These are then further decomposed within the JAUS Profiling Rules document to define specific interface requirements (e.g., synchronous message rates) and behavior required to implement the defined Capability Plan requirement(s).

Requirements from all of these levels, in addition to requirements cited within the contract performance specification, are flowed to the conformance and test activity to support a given system/subsystem test and validation activity. For each individual acquisition program, the Project Manager (PM) representatives will review the IOP package and select which Interoperability Attribute values will apply, based on system requirements. The requirements associated with those Interoperability Attributes will then become part of the contractual requirements for that program.

1.3.1.1 Interoperability Attribute Reference Groups

Many of the capabilities defined by these attributes are further refined or extended using related groups of more specialized attributes, referred to as attribute reference groups.

These groups may be optional or required, and are either selectable independently, as a group, or in a mutually exclusively manner. The following table lists the different combinations and the related implications for each grouping type:

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, as 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.

Table 1: Attribute Reference Group Selection Types

The following example comes from the Transport Attribute, which is the capability that defines the transport layer used for delivering IOP-specified JAUS messages. Since any number of transports can be used in a system, but at least one must be implemented, the group is mandatory and the members of the group are independently selectable.

At least one of the following attributes must be chosen.

Attribute Description

JUDP

Attribute

Specifies that messages shall be transported using the JAUS over UDP as defined in AS5669A JAUS/SDP Transport Specification. JUDP defines JAUS over User Datagram Protocol, which is a simple connectionless protocol with lower latency than TCP but without guaranteed delivery.

JTCP

Attribute

Specifies that messages shall be transported using the JAUS over TCP as defined in AS5669A JAUS/SDP Transport Specification. JTCP defines JAUS over Transmission Control Protocol, which is a connection oriented protocol that provides reliable delivery, but with higher latency than UDP.

Custom Transport Attribute

Specifies that a custom transport defined in the Custom Services, Messages, and Transports IOP document shall be used.

Table 2: Mandatory, Select = any

1.3.2 RAS-G Classes of Vehicles

The RAS-G IOP is targeted toward a limited set of UGV classes. These class definitions were defined by the Joint Ground Robotics Integration Team (JGRIT). In the future, the JGRIT may define additional categories (e.g., small, micro, nano), with each category having multiple variants with roles defined by modular mission payloads mounted on a common platform. The current classification is as follows:

RAS-G Class of Vehicles (CoV).Army RAS-G CoV are categorized according to transportability within the four following classes:

• Warfighter Transportable CoV is the UGV class small enough for Warfighters to carry for extended periods. Within this class are the Single Warfighter and Crew Served Robotic systems.

• Vehicle Transportable CoV is larger than Warfighter Transportable CoV and must be transported by another system, such as in a truck, on a trailer, or towed to its mission location.

• Self Transportable CoV is the UGV class large enough to transport itself and required payloads for extended periods.

• Appliqué System is an add-on standard robotics conversion appliqué kit, that will enable a manned vehicle to operated unmanned at the commander’s discretion. The appliqué system equipped vehicle is a scalable UGV with controls from manual operation to fully autonomous while maintaining its transportability as an unmanned vehicle the same as it did as a manned vehicle.

Given that RAS-G classes will impact the usage and application of the RAS-G IOP, “UGV Class” has been adopted as an Interoperability Attribute. The applicability of this attribute will be defined within relevant sections of the RAS-G IOP as it is employed.

Currently there are no specific requirements for any one CoV except for appliqué systems.

1.3.3 Implementation of Standards

The RAS-G IOP defines standards as well as guidance with respect to implementation in order to promote interoperability as required by the acquisition program managers.

Standards requirements are identified in a variety of areas, including electrical, mechanical, video, audio, communications, and messaging. However, due to the broad scope and expected operational usage of UGVs, not all standards will be applicable to every system.

Acquisition programs requiring conformance to this IOP will specify their interoperability requirements such that system developers can identify and conform to the applicable sections of the IOP.

System developers shall adhere to the standards and guidance as mandated within their procurement contracts relating to this IOP. Robotic system end items shall be tested and validated in accordance with the conformance and validation clauses contained within this overarching profile, as well as those contained in applicable companion IOP documents.

1.3.4 Control and Status Messages & JAUS Profiling

To the degree possible, the RAS-G IOP utilizes the SAE AS-4 JAUS standards to define the interfaces between the OCU and the UGV as well as among on-board UGV subsystems. The RAS-G IOP SAE AS-4 JAUS Profiling Rules document provides guidance with respect to the profiling of the JAUS standard, in order to define the manner in which interfaces are applied/interpreted as a means of limiting ambiguity and maximizing interoperability among disparate vendors.

1.3.5 Custom Services, Messages, and Transports

A set of “custom” RAS-G IOP services has been defined to provide mission capabilities scoped within the RAS-G IOP domain that are either not currently available in the SAE JAUS standards or require SAE JAUS extension by the SAE AS-4 Committee. These messages are documented in the RAS-G IOP Custom Services, Messages, and Transports document. To the extent possible, Custom Services, Messages, and Transports will be avoided, and when deemed necessary will be taken to the SAE JAUS committee for consideration of inclusion in a future public release. If/when Custom

Services, Messages, and Transports have been accepted and published within the applicable SAE AS-4 JAUS standards, they will be removed from the RAS-G IOP Custom Services, Messages, and Transports document.

1.3.6 Latency

Latency requirements govern the overall system performance and can be defined at various levels. For example, the control of a UGV manipulator can be measured from input on the OCU to the commanded movement of the manipulator or at various points along the thread to include OCU to comms link transmission, comms link transmission to comms link reception, comms link reception to manipulator. In general latency will be a factor of the operational mission/mission parameters and will not necessarily be applicable to every UGV system in the same regard. For this reason, latency requirements will be identified within specific Program of Record (POR) acquisition documentation.

1.3.7 Conformance Validation

The Tank-Automotive Research, Development & Engineering Center (TARDEC) has developed an IOP Conformance Validation Lab. Vendors shall provide system overview, functional breakdown and detailed/component description of their UGV. The government will generate a test plan that will identify the IOP attributes to be tested. The IOP attributes define features or are combined together to identify features. Features may be described as distinguishing characteristics of a software component or system.

The test plan will be provided to the contractor for concurrence or modifications if needed. TARDEC will generate a conformance report within one month of the end of conformance lab validation.

1.3.7.1 Software Conformance Validation

While conformance validation of a program's software attempts to locate and correct any problems in that software, it is not economically feasible or practical to plan to test until all defects have been revealed. This is a goal that we can never be sure we have reached. Because of budgets, scheduling, and customer deadlines, specific conditions must be outlined to allow managers to decide when Conformance Validation is considered to be complete.

Software reliability testing includes feature testing, load testing, and regression testing.

1.3.7.1.1 Feature Testing

Feature testing checks the features identified in the test plan and shall be executed using the Conformance Validation Tool (CVT) in the following steps:

• Each IOP Attribute that is needed to define a feature is executed once with the result recorded.

• Each Attribute and Feature is checked for its proper execution.

• Upon successful Feature testing, the CVT will be setup to rerun the Feature tests a minimum of five (5) times with all data recorded. This can be setup to run overnight.

• In addition, ordering of specific Feature tests will be changed, where applicable.

A minimum of five different order sets of Feature tests will be run with all data recorded. This can be setup to run overnight.

• Any unexpected results will be identified and the code fixed if applicable.

• Repaired code will then go through regression testing.

1.3.7.1.2 Load Testing

Load Testing shall follow Feature Testing and is conducted to check the performance of the software under different work load conditions.

• The CVT will be setup to rerun the Feature tests a minimum of five (5) times with all data recorded. During each test run additional random data will be sent along the transport mechanism. This can be setup to run overnight.

• Any unexpected results will be identified and the code fixed if applicable.

• Repaired code will then go through regression testing.

1.3.7.1.3 Regression Testing

Regression testing is used to check if any new bugs have been introduced through previous bug fixes. Regression testing shall be conducted after every change or update in the software features. This testing is periodic, depending on the length and features of the software. Any suspected potential impacts to code shall then go back to feature testing at least for that section of the code.

1.3.7.2 Power Conformance Validation

Power conformance validation can be done per subsystem and is based on system performance needs. Validation will consist of peak testing for 2.5 seconds and sustained testing for 5.0 seconds. The examples below are not intended to be specific recommendations as each system will be unique. Rather they are intended to represent relevant examples.

The mobility system shall not have a sustained current higher than 0.25 A (calculated as RMS current over 5.0 s sliding window) at 24 VDC.

This means that the mobility system cannot draw more than 6 watts measured as RMS (Root Mean Square) over 5 seconds.

The mobility system shall not have a peak current higher than 1 A maintained for more than 2.5 s at 24 VDC.

This means that the mobility system cannot draw more than 24 watts measured as RMS (Root Mean Square) over 2.5 seconds

2 Source Documents The following documents are referenced within this IOP and shall be used to implement the requirements contained within the IOP.

2.1 Government Documents

Version Document 1011-I- 2.0

NIST Special Publication, Autonomy Levels for Unmanned Systems (ALFUS) Framework Volume I: Terminology, Version 2.0, October 2008.

2.2 Non-Government Documents

Version Document AIR5665A SAE Aerospace Information Report, Architecture Framework for

Unmanned Systems (AFUS), April 2009.

ARP 6012 SAE Aerospace Recommended Practice, JAUS Compliance and

Interoperability Policy, April 2009.

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

AS5684 SAE Aerospace Standard, JAUS Service Interface Definition

Language, December 2008.

AS5710A SAE Aerospace Standard, JAUS Core Service Set, October 2009.

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

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

AS6040 SAE Aerospace Standard, JAUS HMI Service Set.

AS6060 SAE Aerospace Standard, JAUS Environment Sensing Service Set.

AS6091 SAE Aerospace Standard, JAUS UGV Service Set

IEEE 802.3-

Standards for Ethernet based LANs

3 Architecture

3.1 System Context

From a system perspective, the RAS-G IOP is defined to address interoperability at multiple levels within varying systems configurations. The context diagram, presented in Figure 3: RAS-G IOP Context below, depicts this concept by showing the UGV and a controller interfacing to external UxV and external command & control (C2)/battle command systems. This concept can be instantiated in a number of ways from a basic OCU/UGV configuration to more complex configurations ( i.e., an OCU controlling multiple UGVs with UAV feeds and/or a communication relay/extension). Interoperability can be applied to various aspects of these configurations as required by the system product manager, to include:

– OCU/UxV(s) – radio/data interfaces

– Intra-OCU – between and among OCU hardware and software elements

– Intra-UGV – between and among UGV subsystems/payloads and platform

– OCU/UGV to External C2 Systems – exchange of command and control, battlespace, and audio/video information.

For the purposes of IOP V3, only the circled portion of this architecture is within scope.

This includes the hardware and software interfaces to define interoperability and modularity between a platform and an OCU, between a platform and its payloads, between a radio and a platform or OCU, and between an OCU and its human operator.

Figure 3: RAS-G IOP Context

3.2 Reference Architecture

The architecture presented in Figure 4: RAS-G IOP Reference Architecture below builds upon the system context and defines key integrated elements of the UGV and OCU along with internal and external interfaces. These elements are defined in this IOP in a generic (abstract) manner and may be realized within a system in a variety of ways. For example, although all UGVs will have a conceptual platform controller to provide platform and mobility processing, the platform controller may be realized as a single computer, a single line replaceable unit (LRU) with multiple computers or a set of LRUs with distributed processing and internal interfaces. The terms defined and presented in the architecture diagram are defined to provide a consistent terminology and point of reference for utilization throughout this IOP.

Figure 4: RAS-G IOP Reference Architecture

As depicted in the figure, systems within the reference architecture are comprised of integrated elements, interfaces, and potential interfaces. An integrated element is an element that will exist (at least conceptually) within the specified system; an interface defines an inter or intra system linkage between integrated elements; and a potential interface is an interface that may or may not exist depending upon the required functionality as specified by a system’s Interoperability Attributes.

3.2.1 Operator Control Unit (OCU)

The OCU system of the reference architecture provides the human operator a capability to issue commands to and receive input back from one or more UGVs. Specific OCU-level requirements are included within the Control IOP.

The Input and Output Device element(s) are generic and could be adapted to describe a traditional controller implemented with joysticks, keyboard, mechanical switches, and a display, or other types of controllers such as those implemented with a glove, video game controller, monocle, voice, smart phone, or tactile belt.

3.2.2 Common Communications Link (CCL)

The Common Communications Link (CCL) element is an abstraction of the networking and/or point-to-point communications solution required for command and control of UGVs. It provides the OCU with the ability to transmit and receive data to/from a UGV, external C2 System, and/or another UxV.

While it is not within the scope of IOP V3 to define all CCL requirements, it does represent the "core" set of requirements necessary to define interoperable behaviors for near-term UGV radios. A future Version of the IOP will include enhanced definition of how the CCL must operate in the long term.

3.2.3 Unmanned Ground Vehicle (UGV)

The UGV system of the reference architecture consists of a Platform Controller element integrated with zero or more Payload elements, and interfaced externally to an OCU and/or UxV and External C2 Systems via a CCL element. The Platform Controller element is conceptually responsible for providing platform management (e.g., system diagnostic monitoring, system safety, BIT/FIT) and mobility. The Platform Controller element receives data and provides status through the CCL element. The Payload element(s), if present, may be communicated with external consumers via an external connection through the CCL or may be integrated directly to the Platform Controller element. An example of a Payload element with a direct connection to the CCL might be an SAE AS-4 JAUS compliant payload that can be discovered and communicated to directly by an OCU. An example of a Payload element with a connection to the Platform Controller element might be a payload with an SAE AS-4 JAUS interface resident on the Platform Controller where commands to the SAE AS-4 JAUS interface are translated to the payload in a non-SAE AS-4 JAUS format. In addition, an SAE AS-4 JAUS compliant payload capable of interfacing directly to an OCU may still have an interface to the Platform Controller in order to provide subsystem status and to register for platform data (e.g., navigation, state/mode). The Power element provides power to all UGV integrated components.

3.2.4 External Command & Control (C2)

While outside the scope of IOP V3, the External C2 system of the reference architecture provides for the interfacing of an OCU and/or UGV with an external system, such as a battle command system. Sharing of payload data into external ground or air based systems or networks will be addressed in a future version of this IOP.

3.2.5 Other Unmanned Vehicles (UxVs)

While not explicitly within the scope of IOP V3, the UxV system of the reference architecture provides for the coordinated interaction of an UxV system with the OCU and/or UGV. UxV in this context represents a generic unmanned system to include another UGV, a UAV, or an unattended sensor. While many UGV/UxV capabilities can be achieved by utilizing a combination of IOP V3 requirements and requirements of existing UxV standards, explicit interface requirements for communicating with UxVs outside of the ground domain will be addressed in a future version of this IOP. Some possible specific capabilities to be addressed in future near-term IOP versions are provided in Figure 5: Example Possible Capabilities with other UxV for Future IOP Versions below in order to generate feedback and encourage IOP contributors to begin thinking through the various interface considerations.

Figure 5: Example Possible Capabilities with other UxV for Future IOP Versions

3.3 UGV Logical Internal Architecture

In addition to the reference and system architecture, the RAS-G IOP applies to the logical internal architectures for both the OCU and the UGV, specifying the general hardware and software interfaces relevant to interoperability within the OCU and UGV systems. The term logical refers to the fact that these elements may be implemented in varying physical configurations and that the physical configuration is not specifically relevant to the manner in which these elements interface with one another within the system. An example UGV logical internal architecture is presented in Figure 6: Example UGV Logical Internal Architecture below.

Figure 6: Example UGV Logical Internal Architecture

The solid elements depicted in the figure represent elements that are always present within the UGV system. The dashed elements represent potential elements that may be present within the UGV system. Similarly the solid lines between elements represent defined element interfaces while dashed lines represent potential element interfaces.

Within the RAS-G IOP, potential element/interface requirements are subset via Interoperability Attributes to provide for the specification of a basic UGV configuration that can be augmented to accommodate specific interoperability requirements related to the interface with external system(s). A brief description of the controller elements is presented in the following paragraphs.

OS (Element) – The OS represents the controller operating system. In general, requirements related to the operating system will not be addressed within this IOP and will instead be defined via acquisition requirements or design decisions.

OS Interface Services (Potential Element) – The OS interface services specify inter-process communication (IPC) mechanisms required to implement interoperability interfaces between software (application) elements. This could be an interface between the controller application and an external system(s), the controller application and a vendor plug-in, and/or an interface utilized by the JAUS system to provide an underlying transport.

A/V Codec (Potential Element) – The A/V Codec represents the element within the system that decodes/encodes digital audio and video data streams. The codec formats required within the system will largely be dependent upon the requirements associated with specific payloads and/or the communications data link.

JAUS/Custom Message Interface (Element) – The JAUS/Custom message interface represents the element responsible for interfacing with the application to encode, marshal, transmit and receive, unmarshal, and decode JAUS messages between the controller and the robotic system(s). This element may be incorporated with or separate from the application software component.

UGV Application (Element) – The UGV application specifies the element responsible for the logical execution of the UGV system. In general requirements related to the application will not be addressed within this IOP and will instead be defined via acquisition requirements or design decisions.

Platform Controller (Element) – The platform controller specifies the element responsible for hosting and execution of the UGV application. This element may be realized in a variety of ways from a small micro-controller up to a multi-LRU configuration in accordance with the platform size and mission capabilities/requirement(s). In general internal requirements related to the platform controller will not be addressed within this IOP and will instead be defined via acquisition requirements or design decisions. External and interfacing requirements associated with the platform controller will be defined and presented within this IOP.

CCL (Element) – The CCL represents the communications data link between the controller and the robotic system. The requirements governing this interface are specified within the RAS-G IOP Communications Profile.

Payload(s) (Potential Element) – The Payload element specifies the element responsible for conducting mission specific functions/capabilities alone or in concert with other payloads and/or the UGV platform. This element may be realized in a variety of ways and configurations in accordance with the platform size and mission capabilities/requirement(s). Internal requirements related payloads will not be addressed within this IOP and will instead be defined via acquisition requirements or design decisions. Payload interfaces to/from the platform (e.g., electrical, mechanical), as well as interfaces between the payload and external systems (e.g., data formats, message protocols) are defined within the RAS-G IOP Payload Profile.

4 IOP Usage Guide

4.1 Overview of IOP Usage Process

This set of IOPs will be used by both the Project Manager (PM) community and the vendor community. For convenience, individuals within the Materiel Developer (the PM) will be referred to as “MATDEV”. Private industry (or academia) developers of systems, payloads, radios, technologies, or systems engineering/integration expertise will be referred to as “vendors”.

For a given UGV acquisition program, the process begins with the MATDEV reviewing the operational requirements as articulated by the User community. These will typically be articulated in the form of a Capabilities Development Document (CDD) or Capabilities Production Document (CPD), and written by a Combat Developer, such as the Army’s Training & Doctrine Command (TRADOC), or the USMC’s Marine Corps Combat Development Command (MCCDC).

The MATDEV will then use systems engineering processes to transform these operational requirements into performance requirements. During this process, the MATDEV will conduct a formal review of the IOP documentation and select the attributes defined within the set of IOPs corresponding to the capabilities of the system.

Many Interoperability Attributes will have one or more associated requirements, which will be inserted into the PM’s contractual requirements for the program’s Request for Proposal (RFP). Selection of the appropriate Interoperability Attributes will often require the MATDEV to conduct formal trade studies to inform the decision. There are also a number of Mandatory Interoperability Attributes across all of the IOP documents, whose requirements will be imposed on all systems. These Mandatory Interoperability Attributes are further described within this document, the JAUS Profiling Rules document, and the Communications, Control, and Payloads IOP documents.

The vendors within the competition space will then implement the requirements that have been selected based on the Interoperability Attributes, in accordance with the IOPs, and particularly in accordance with the JAUS Profiling Rules IOP and the Custom Services, Messages & Transports document.

An example of this process would be that the MATDEV receives a new requirement for a system that has Leader / Follower capabilities, as well as requirements for sensing Chemical, Biological, Radiological, Nuclear (CBRN) threats. In this case, the MATDEV will know that in addition to specifying the Mobility Interoperability Attribute with its associated "Core Mobility", "Drive Timeout", and "Emergency Stop Safety" requirements, they will also know that they must select, at a minimum, the Leader/Follower Interoperability Attribute. Similarly, the MATDEV will also know that it must also specify the CBRN Sensor Attribute, in addition to other common payload requirements. The requirements associated with each of these attributes would then become requirements imposed on the vendor to be compliant with the performance and/or product specifications.

4.2 IOP Usage

For the MATDEV, the IOPs will be used as part of the requirements decomposition & allocation process prior to release of RFPs. It should be noted that the interface requirements in the IOPs represent a “product level specification”, as opposed to the typical “performance level specification” that PMs are typically responsible for. This has been done intentionally in order to provide sustained interoperability and modularity of systems throughout their full lifecycles. MATDEVs will build program-specific interoperability requirements into their RFPs prior to being released, based on this IOP.

For the MATDEV, the Overarching IOP, Payloads IOP, Communications IOP, and Control IOP are of primary interest, since those contain definitions of the Interoperability Attributes, and the applicable requirements for each.

For vendors who are marketing products, this IOP should be used as a guide for what to expect in future RFPs. This package of documents describes the hardware and software interfaces that the DoD would like to see in products that vendors may be developing. For vendors who are awarded RFPs in future programs, these documents represent the technical requirements that will be imposed to promote interoperability.

For industry, the JAUS Profiling Rules document is of primary interest, as it contains the product level specifications that can be implemented to build interoperable systems.

4.2.1 Usage of Overarching IOP

The Overarching IOP will support the MATDEV and industry to serve as a description of the intent of the full IOP package, to describe its usage, to define overarching requirements for all systems, to point to applicable sections in the other IOPs, and to define Interoperability Attributes that may be selected by the MATDEV to impose interoperability requirements into acquisition contracts.

4.2.2 Usage of Communications IOP

The Communications IOP will be used by the MATDEV and industry to define communications and radio related requirements for a CCL, to point to applicable sections in the other IOPs, and to define communications related Interoperability Attributes that may be selected by the MATDEV to impose interoperability requirements into acquisition contracts.

V3.OVA- UGV platforms shall implement the communications data link interface in

1 accordance with the RAS-G IOP Communications Profile and any required (specified) Interoperability Attributes.

4.2.3 Usage of Payloads IOP

The Payloads IOP will be used by the MATDEV and industry to define payload related requirements for both payloads themselves and UGV platforms, to point to applicable sections in the other IOPs, and to define payload related Interoperability Attributes that may be selected by the MATDEV to impose interoperability requirements into acquisition contracts.

V3.OVA-

Payloads shall be implemented in accordance with the RAS-G IOP Payloads Profile and any required (specified) Interoperability Attributes.

4.2.4 Usage of Appliqué IOP

The Appliqué IOP will be used by the MATDEV and industry to define appliqué related requirements for unmanned appliqué kits.

V3.OVA-

Appliqué shall be implemented in accordance with the RAS-G IOP Appliqué Profile and any required (specified) Interoperability Attributes.

4.2.5 Usage of Control IOP

The Control IOP will be used by the MATDEV and industry to define desired common qualities of controllers. It is acknowledged that there are a variety of types of controllers that make sense for different missions, and the technology related to controllers is evolving rapidly, particularly based on advancements being made in the mobile/smart-phone and gaming markets. The current Control IOP V3 contains desired guidelines for user interfaces for conventional controllers, but does not mandate explicit requirements.

Controllers must be capable of communicating JAUS-based messages as defined in this IOP package, and must interface with the CCL as defined in the Communications IOP. The primary intent of the Control IOP is to promote an interoperable Human Machine Interface (HMI), which means that the relationship between the controller and the human operator must be modular based on minimized training for operation among different systems. If controllers can support the JAUS-based messages described in this IOP package, then interoperable messages will become the interface between the controller and the UGV platform.

For example, if a controller operator presses a keypad arrow to turn right, then an interpretable message command will be received and understood by the UGV platform.

If another controller utilizes a joystick to turn right, then the UGV platform should receive a message similar as that sent from the first controller. User input to turn right on a smartphone type accelerometer device, a speech-based device, a motion-recognition device, or other innovative controller technology should all result in a similar functionality, interpretable JAUS-based message being received by the UGV platform.

V3.OVA-

Controller requirements shall be implemented in accordance with the RAS- G IOP Control Profile.

V3.OVA-

All IOP compliant controllers will be capable of communicating with platforms using the JAUS-based message set contained within the other IOP documents. The Control IOP serves to provide additional guidance as to the design of controllers.

4.2.6 Usage of JAUS Profiling Rules IOP

The JAUS Profiling Rules IOP will be used primarily by industry to define the services needed for complying with the requirements defined within the other IOPs. It provides the product-level JAUS-based message implementation guidance, and reference to the appropriate SAE AS-4 JAUS documents. Additionally, the JAUS Profiling Rules IOP will be used by the MATDEV in developing System Integration Labs (SILs) for verifying that the IOPs achieve the desired outcomes, as well as assessing the compliance of vendor products to the IOPs.

V3.OVA-

JAUS Profiling Rules shall be implemented in accordance with the RAS-G IOP JAUS Profile and any required (specified) Interoperability Attributes.

4.2.7 Usage of Custom Services, Messages & Transports IOP

The Custom Services, Messages & Transports document will be used to define JAUS-based services that are not currently defined in any existing SAE AS-4 JAUS approved document. Currently in V3, the Custom Services, Messages & Transports document contains JAUS-based guidance for the following Custom Services:

Service IOP V0 IOP V1 IOP V2 IOP V3 Leader Management

Introduced Maintained Maintained Updated

Leader Follower Driver

Introduced Maintained Maintained Updated

Communicator Introduced Updated Updated Maintained Platform Mode Introduced Updated Maintained Maintained Health Monitor Service

Introduced Replaced by AEODRS v1.2 Health Monitor Service

Maintained Maintained

Health Reporter Introduced Replaced by AEODRS v1.2 Health Reporter Service

Maintained Maintained

Digital Stream Discovery

Introduced Deprecated & Replaced by Digital Resource Discovery

Maintained Maintained

Preset Pose Introduced Updated Maintained Maintained Platform State Introduced Maintained Maintained Digital Resource Introduced Maintained Maintained

Discovery Enhanced Access Control

Introduced Maintained Maintained

Handoff Controller Introduced Maintained Maintained Retrotraverse Introduced Maintained Maintained Comms Lost Policy Manager

Introduced Maintained Maintained

Guarded Teleoperation Policy Manager

Introduced Maintained Deprecated, Replaced by Intelligent Vehicle Policy Manager

Render Useless Introduced Updated Updated Tamper Detection Introduced Maintained Maintained SubsystemID Allocator

Introduced Maintained Maintained

NodeID Allocator Introduced Maintained Maintained Digital Audio Introduced Maintained Maintained Digital Audio Annunciator

Introduced Maintained Maintained

Path Reporter Introduced Maintained Stability Control Introduced Deprecated, Replaced by Intelligent Vehicle Policy Manager

Wiper Introduced Maintained Debris Blower Introduced Maintained Platform Door Introduced Maintained Manipulator End- Effector Force/Torque Sensor

Introduced Maintained

Force Torque Sensor

Introduced Maintained

CostMap2D Introduced Maintained Physical Specification

Introduced Deprecated, Replaced by Component Physical Properties

Self-Collision Avoidance Policy Manager

Introduced Maintained

Filter Mapper Introduced Maintained Tire Pressure Introduced Maintained Extended Primitive Manipulator

Introduced Maintained

Extended Primitive Pan/Tilt

Introduced Maintained

Enhanced Waypoint Navigation (Local)

Introduced Maintained

Enhanced Waypoint Navigation (Global)

Introduced Maintained

Software Version Reporting

Introduced Maintained

H264 Video Encoding

Introduced Updated

Acoustic Sensor Introduced Component Physical Properties

Introduced

Mount Site Properties

Introduced

Convoy Introduced Data Logging Introduced General Sensor Introduced Intelligent Vehicle Policy Manager

Introduced

Loading Specifications

Introduced

Magnetic Sensor Introduced Military Illumination Introduced Pass-through Message

Introduced

Seismic Sensor Introduced Unsolicited Broadcast Control Available

Introduced

Table 3: Summary of IOP Custom Services

Currently there are no defined custom transports in this document.

Whenever possible, it is the intent of the DoD for each of the custom services, messages, and transports defined in this package to be recommended for adoption by the SAE AS-4 JAUS Committee, and published in an approved SAE document. Once the services, messages, or transports are approved in a published SAE document, this IOP package will be modified to reference the new published document instead of the Custom Services, Messages & Transports document (and they will be removed from the subject document as well).

Custom (or “private”) messages provide a mechanism to specify necessary command, control, and status messages that have not been defined within the specified SAE AS-4 JAUS standards. For the RAS-G IOP, all custom messages approved for use are defined within the RAS-G IOP Custom Services, Messages and Transports. Custom messages are controlled within the RAS-G IOP activity and it is the intent of the DoD to seek standardization of these custom messages within the applicable SAE AS-4 JAUS committees and seek wide adoption within the Army robotic ground vehicle community.

The RAS-G IOP will specify the use of SAE AS-4 JAUS messages to achieve interoperability and only employ custom messages when no JAUS message will suffice.

Custom messages will be published and distributed to the stakeholder community without proprietary markings.

V3.OVA-

Custom command, control and status messages shall be implemented in accordance with the RAS-G IOP Custom Services, Messages and Transports.

4.3 Non-compliance

In the event that a program of record specifies the incorporation of a technology that currently does not meet one or more of the physical, electrical, or logical requirements specified within the IOP profiles for the capabilities/attributes it utilizes, it will be deemed "non-compliant". Methods of dealing with non-compliance (when specifically allowed for a given program) are intended to allow non-compliant technology to operate with the IOP Profiles and consist of the following options:

1. “Adoption” of a new physical, electrical or logical interface into the appropriate IOP profiles(s), and subsequent creation of new IOP attributes to profile the interface.

2. “Wrapping” or “Adapting” the physical, electrical or software interfaces. Examples include:

a. A physical adaptor such as a bracket that could bridge between the physical hardware requirements of the IOP and a new technology

b. A 7 to 5 pin converter (adaptor)

c. A software wrapper that would act as a “bridge software component” between two differing message sets (i.e., STANAG 4586 to JAUS)

Although non-compliance should be avoided, the DoD recognizes that the constraints of an individual program may require a temporary non-compliant step (this may be considered on a case-by-case basis). In all cases, over time, non-compliant technology should migrate to full compliance through the mechanisms the DoD uses to expand the IOP Profiles or this technology, if viable, should be added to future versions of the IOP.

Note that certain capabilities within the IOP may not work well with a mixture of compliant and non-compliant elements within the robotic sub-system. One such example is the Render Useless capability.