Attachment_0014_-_UGV_Interoperability_Profile_(IOP).pdf

Unclassified

UGV Interoperability Profile (IOP) Capabilities Plan

For Version 2

Robotic Systems, Joint Project Office (RS JPO)

SFAE-GCS-UGV MS 266

6501 East 11 Mile Road

Warren, MI 48397

*Note: Subsequent to the publishing of this document in December 2013, the RS JPO was disbanded and its portfolio of programs were merged into the Army Project Manager, Force Projection (PM FP) within the Program Executive Office for Combat Support and Combat Service Support (PEO CS&CSS). Each of the other IOP V2 documents therefore were published by PM FP.

December 2013

UNCLASSIFIED: Distribution Statement A. Approved for Public Release i

Table of Contents 1 Scope

1.1 Overview

1.2 Applicability

2 Capabilities Definition Process

2.1 Capability Plan Labeling

3 Capabilities

3.1 Interoperable Context

3.1.1 Non-Compliant Systems and Interfaces

4 Capabilities Plan Structure

4.1 Platform/Vehicle

4.1.1 Physical, and Electrical

4.1.2 Other Guidance: N/A

4.1.3 Data Port (IOP Capture: V2= I)

4.1.4 Tether (IOP Capture: V1 = I, V2= U)

4.1.5 NATO Receptacle (IOP Capture: V1 = I, V2 = U)

4.1.6 On-Vehicle E-Stop (IOP Capture: V1 = I, V2 = U)

4.1.7 Mission Payload Interface (IOP Capture: V0 = I, V2 = U)

4.2 Payloads

4.2.1 Physical, and Electrical Interfaces

4.2.2 General Payload

4.2.3 Sensor

4.2.4 Emitter

4.2.5 Actuator

4.3 Communications

4.3.1 Physical, Electrical (IOP Capture: V0 = I,V2 = U)

4.3.2 Non-Compliant Interface (IOP Capture: V1 = I, V2 = U)

4.3.3 Tether (IOP Capture: V2 = I)

4.3.4 Vehicle Network and Time Management (IOP Capture: V1=I, V2=U)

4.3.5 Radio Link (IOP Capture: V0 = I, V1 = U)

4.3.6 Radio Subsystem Interface (IOP Capture: V0 = I)

4.3.7 Radio Frequency Interference (RFI) Mitigation (IOP Capture: V0 = I)

4.3.8 Waveform Requirements (IOP Capture: V2 = I)

ii

4.3.9 Off-Board Network (IOP Capture: V2 = I)

4.4 Control

4.4.1 Physical and Electrical (IOP Capture: V1 = I)

4.4.2 Tether (IOP Capture: V1 = I)

4.4.3 External Communications Interface (IOP Capture: V0 = I, V1, V2 = U)

4.4.4 Software (IOP Capture: V0 = I, V2 = U)

4.4.5 HCI (IOP Capture: V0 = I, V2=U)

4.5 Logical Interoperable Capabilities (IOP Capture: V2 = I)

4.5.1 Non-compliant Logical Interfaces (IOP Capture: V2=I)

4.5.2 Actuator and Manipulator

4.5.3 Autonomy and Behaviors

4.5.4 Communications

4.5.5 Health

4.5.6 Navigation and Behaviors

4.5.7 Platform

4.5.8 Sensor and Emitter

5 Security and Information Assurance

5.1 Information Assurance (V2 = I)

5.2 Security(V2 = I)

5.2.1 Wired/Wireless Security (IOP Capture: V2 = U)

5.2.2 Render Useless (Zeroize) (IOP Capture: V2 = U)

5.2.3 Tamper Detection (anti-tamper capability) (V2 = U)

Appendix A:

1 Decomposing Desired Program Capabilities into Interoperability Concepts

2 Example Decompositions

2.1 Example 1: Teleoperation

2.2 Stair Climbing (use of flipper/stabilizer)

2.3 Dealing With Non-compliance

2.4 Extensions to Capabilities and Overlap

2.5 Performance Issues

1 Scope

1.1 Overview

Interoperability is integral to the success of missions using unmanned systems, and represents a long-term objective of the Robotics Systems Joint Project Office (RS JPO) and its stakeholders. RS JPO addresses requirements for sustainable, interoperable Unmanned Systems in the ground, air, and maritime domains through its Unmanned Ground Vehicle (UGV) Interoperability Profile (IOP) initiative with an end goal of:

• 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.

As robotic system payloads, sensors, operator controls, software, and computing devices are anticipated to evolve much faster than base platforms, enhanced modularity by means of standardize interoperable interfaces represents an opportunity to minimize future life cycle costs and adapt rapidly to changing threats or new available technologies.

The RS JPO IOP Capability Plan is a “living” document designed to address specific requirements and capabilities applicable to planned and emerging robotic systems that;

in coordination with the RS JPO User Community, and UGV IOP Interoperability IPT, align those capabilities to future IOP Versions that will in turn be aligned with robotic program acquisition initiatives.

The RS JPO IOP Capability Plan herein provides general guidance and clarification with respect to the set of interoperability capabilities clarifying, extending and/or adding to what was defined within the V0 UGV IOP and each subsequent UGV IOP release (i.e., V1, V2, etc.).

1.2 Applicability

The Capability Plan document was developed as a means to provide guidance with respect to definition of IOP release candidate (i.e., V1, V2, etc.) interoperable capabilities. Release candidate Capability Plan provides an overview of capability intent through narrative abstracts, recommends interoperability scope, and suggests associated limitations and constraints as applicable to the IOP release candidate (i.e., V1, V2, etc.) development effort. This document serves to provide guidance for Working Integrated Product Team (WIPT) organizations, responsible for identification, definition and development of an optimized path towards interoperability. This document does not define how things are to be done (e.g., design and implementation), rather, this document provides guidance as to how to scope interoperability. In addition, while this document will retain a level of traceability to predecessor release candidates (i.e., V0, V1, etc.) IOPs, that traceability will not necessarily be a one to one correlation between a defined capability and the manner in which it may be decomposed and subsequently specified by Working Integrated Product Team’s. It is impossible to list all desired capabilities for ground robotics; therefore, this document focuses on describing enabling capabilities. Enabling capabilities of which WIPT IOPs resolve to composable attributes.

For example, consider a requirement for a UGV to perform a stair climbing maneuver.

The example performance requirement calls for the ability to navigate the platform to/from a set of stairs, engage specialized hardware and actuators (i.e. stabilizers or “flippers”) and to receive feedback from the platform. Per IOP instantiation process, system performance requirements are decomposed to enabling capabilities such as physical, and electrical interfaces, logical interfaces, and controller side human-computer interaction requirements. Therefore, to define a platform stair climbing capability per the IOP, one would simply identify relevant top-level capabilities (i.e.

camera feed, mobility controls, etc.) listed throughout this document, and further refine capability-enabling attributes per WIPT IOPs (Overarching, Payloads, Communications, Controls, and JAUS Profiling).

2 Capabilities Definition Process Restating section 1.2 Applicability, the intent of the capabilities definition process is to identify key robotic capabilities and allocate them to IOP version releases (i.e. V0, V1, V2, etc.) synchronized with respect to source requirement needs and/or program acquisition schedules. V0 IOP addresses capabilities associated with currently fielded UGV Systems, as well as, capabilities to be fielded in the near future. V1 and out year IOPs integrate emerging capability requirements for future programs of record providing an opportunity to instantiate interoperable capabilities based on projected program acquisition funding and scheduling. This allows the ability to define interoperability mechanisms that can then be employed as part of the acquisition cycle.

V1 and out year capabilities, are identified by researching and compiling all emerging requirements available to the RS JPO. Candidate robotic capabilities are typically derived from program Capability Development Documents (CDDs) and Capability Production Documents (CPDs), Unmanned Systems Initial Capabilities Document, Robotics Roadmap, and UGV Campaign Plan interoperability objectives such as commonality, modularity, lowered life cycle costs, reduced logistics foot print, and most importantly, the ability to rapidly adapt systems in reaction to changing user requirements and technological advances. Identified robotic capability requirements are incorporated into version release candidate (V1, V2, etc.) Capabilities Plan, which is then, reviewed by WIPT leads and industry partners. Through a series of recurring meetings identified robotic capability requirements are solidified, to those that should be captured in current IOP instantiation. After capabilities are down selected, they are vetted amongst the User and Combat Developer Community. Feedback from the User and Combat Developer community is processed and incorporated into IOP release candidate capability narratives. The final step in the process is to deliver a finalized Capability Plan to all the Interoperability IPT team members, providing guidance to

WIPT working groups, resolving planned capabilities to composable attributes correlated their portion of the IOP.

2.1 Capability Plan Labeling

Each section and subsection includes in parentheses labeling as to when the capability or section description was introduced, or updated. This helps with determining changes from previous versions of the Capabilities Plan since it is a living document. The following abbreviations will be used throughout this document:

• I = Initial

• U = Updated

• Ongoing = Ongoing indicates that for each Version of the IOP documents, the respective WIPTs should add to this capability (example: pose/articulation may include new preset poses as various POR’s bring them to our attention).

3 Capabilities The capabilities defined herein are presented in accordance with the IOP Composability Taxonomy defined within the Overarching IOP. It should be noted that even though capabilities are specified as “common” to UGV system configurations, it is understood that not all capabilities will be available and in some cases; there may be variation in how the capability is defined and integrated. The goal of the IOP is to define an interoperable manner to address these capabilities across robotic systems, i.e. - to address the manner in which systems may choose to implement or not implement various capabilities (e.g., through interoperability attributes and/or metadata definition).

In addition, the goal is to also promote interoperability with external systems; e.g., controllers, to know what capabilities are available from/configured for a particular platform in compliance with the IOP. This is an overriding requirement to be addressed consistently throughout the IOP.

3.1 Interoperable Context

Interoperability is the ability of systems, modules and components to “communicate” data, information, material, and services and accept the same. Capabilities are “interoperable” as a function of “common/standardized,” physical, electrical, etc.

interfaces, logical (message and protocol) interfaces, and communication (transport) interface. Figure 1 below illustrates the primitive interoperability context.

Figure 1 IOP Primitive Context

RS JPO Interoperability Profiles are structured in such way as to allow flexible granularity when specifying and interoperable system. Figure 2 below illustrates an aggregation of integrated elements, interfaces, and potential interfaces as derived from IOP primitive interfaces (i.e., communications, logical, and physical).

Figure 2 IOP System Context

The IOP System Context diagram, Figure 2, depicts two elements interfacing with the IOP System Context rather than encapsulated by it. This Capabilities Plan defines the subject elements (External C2 and UxV) as non-compliant. Meaning, subject element “interfaces” are not compliant with IOP defined interfaces. Therefore, interface with an IOP context is accommodated through use of an interface device, adapter or bridge.

This version of the Capabilities Plan formalizes the method for handling those systems that do not comply with all of the requirements of the Interoperability profile.

3.1.1 Non-Compliant Systems and Interfaces

Any capability, system, module or payload that is not by design and implementation an integral, organic or embedded capability with respect to its host platform is considered to be non-compliant. For example, an aggregation of sensors and computational capabilities designed to be host-agnostic that includes well-defined, though not IOP-standardized, interfaces would be considered a non-compliant system.

The IOP Overarching Profile Document describes how non-compliance is dealt with.

The Capabilities Plan may point to one or more enabling capabilities and/or standards for inclusion into the IOP. It is recommended that the WIPTs review the section in the UGV IOP Overarching Profile document about how to deal with non-compliance and handle the capabilities listed within this document in that fashion.

3.1.2 Performace and the IOP

The IOP typically does not concern itself with performance issues. The exception to this is when performance issues would directly affect the ability to interoperate successfully.

Examples include, but are not limited to: control latency, feedback latency, bandwidth, etc.. WRT interoperability, the IOP will address performance issues with minimum or maximum threshold requirements only. For instance, if teleoperation can only successfully be accomplished up to some maximum latency between the controller and the platform, that maximum is what will be listed. The POR may improve upon that number but will not be allowed to exceed it.

Throughout this document, embedded in their respective sections, relevant performance issues may be addressed.

4 Capabilities Plan Structure As discussed in section 1, the initial instantiation of RS JPO UGV IOP, V0, supported specification of interoperable and modular capabilities primarily for fielded UGV systems. The structure of the Capabilities Plan mirrored that of the typical architecture of fielded UGV systems wherein functional elements were categorized and allocated to top-level sections of the Capabilities plan (i.e., Platform, Payloads, Communications, and Controls (Operator Interface)).

Version 1 instantiation retained all V0 content but also incorporated identified capabilities for emerging programs such as for example, payloads that are “interchangeable” within a Family of Systems (FoS) yet logically “interoperable” with other platforms and controllers. Version 1 also addressed initial capability requirements for appliqué configurations wherein OEM (original equipment manufacturer) platforms and recapitalized assets are to be augmented with various levels of unmanned capabilities, capabilities of which are required to be incompliance with RS JPO IOPs.

In an effort to improve capability planning and program instantiation processes the Version 2, IOP Capabilities Plan, has been restructured. The most notable change is the addition of a separate Interoperable Capabilities (logical – messages and protocol) section. Platform, Payloads, Communications, and Controls have been re-factored;

most notable modification is the addition of an explicit Physical and Electrical sub section. Where applicable, the physical and electrical may be included in a separate section, for example physical and electrical requirements that only effect the controller may be listed within the Controls sub section of this document.

The capability definitions herein serve to provide guidance for specification of Interoperable system(s) at multiple levels, within varying systems configurations.

Described capability definitions; however, are NOT inclusive or exact. The definitions are specified to relay intent with the understanding that WIPTs may need to extend, or modify the definitions. The limitations and constraints provide somewhat loose boundaries, but in general are specified to limit unnecessary effort, to over specify capabilities, with respect to their interoperability implementation.

4.1 Platform/Vehicle

Platform/vehicle is an aggregation of inherent functions such as platform mechanical structure (chassis), power generation (internal combustion engine, fuel cell, batteries), drive system (wheels, tracks), suspension system (springs, dampers, torsion bars, air bags), maneuvering system (rack and pinion, Ackerman, hydrostatic), electrical system (power bus, lights, batteries, capacitors), braking system, hydraulic system, air system, cooling system, heating system, computation system (engine control unit, suspension control unit, mobility control unit, power management), sensor system (engine, suspension, mobility, power), and on-board data bus/network/communication system(s), as well as, mission specific functional capabilities such as mobility (remote control, tele-operation), computation (waypoint navigation, sensor fusion), payloads (sensors, emitters, actuators), communications (data link, antennas) and miscellaneous peripherals (switches, audio devices).

The Platform/Vehicle section will concentrate on physical and electrical interfaces specific to the platform.

4.1.1 Physical, and Electrical

This section supports definition of platform/vehicle physical and electrical interfaces in support of the specification of system/subsystem and mission payload interoperability.

This will include specification of physical connectors, mounting or otherwise which will be driven by the Payloads WIPT. These capabilities may also be driven by design and development capability requirements. That is, a semi-permanent solution may be proposed by the IOP for the purposes of design and development which is later superseded by a permanent solution. Physical and electrical interfaces shall be based on current published standards. Physical and electrical interfaces shall be consistent with UGV Class of Vehicles (CoV) interface requirements and specifications. In most cases, the platform connectors should be specified with mil-spec standard ruggedized connectors.

Electrical connectors will be driven by the Communications WIPT as communications interfaces are specified. Electrical connectors will be driven by the Payloads and Communications WIPT, whichever is appropriate and working in conjunction with each other when appropriate, as power, control, and communications interfaces are specified.

4.1.1.1 Non-Compliant Interface (IOP Capture: V1 = I V2 = U)

Description: Provides the capability to interface physically and electrically with a non-compliant sub-system.

Defines attributes and guidance on developing physical and electrical interface adaptors between non-compliant and compliant portions of the system.

Defines how/when a physical or electrical interface may be considered for adoption into the IOP.

Limitations and Constraints: Introduced in V2 is the concept of evaluating how a non-compliant system could be bridged to the compliant portion of the system and profiling new attributes and guidance on how that should be accomplished. As well, guidance on how/when adoption of a standard should be determined.

Other Guidance: N/A

4.1.2 Other Guidance: N/A

4.1.3 Data Port (IOP Capture: V2= I)

Description: Data port provides maintenance level interface with platform/vehicle inherent functions and integrated mission capabilities. Supports system upgrade, diagnostics and like maintenance requirements.

Defines physical interfaces (e.g. connectors) Defines electrical interfaces (e.g. power, connectors.)

Limitations and Constraints: Capability is a fixed maintenance port, limited to field support and maintenance purposes. Capability desired is described as a dedicated USB port. As well, the WIPT should look into a means of disabling the on-vehicle data port for when the vehicle is in the field (i.e. locked cover) to prevent enemy tampering.

Other Guidance: Physical and electrical interfaces shall be based on current published standards and/or best industry standards.

4.1.4 Tether (IOP Capture: V1 = I, V2= U)

Description: Tether interface providing hardwired (i.e., fiber-optic cable, twisted wire, etc.) robotic platform/operator control unit (OCU) communications capability. Tether is a fixed communications interface facilitating command, control, and feedback of platform inherent and integrated mission capabilities.

Defines physical interfaces (e.g. mounting, brackets, connectors) Defines electrical interfaces (e.g. power, connectors.)

Limitations and Constraints: Defines interfaces for platform mounted capability.

Other Guidance: Physical and electrical interfaces shall be based on current published standards and/or best industry standards.

4.1.5 NATO Receptacle (IOP Capture: V1 = I, V2 = U)

Description: NATO Power Port Slave Receptacle provides 24 – 28 V DC slave power capability.

Profiles NATO receptacle physical and electrical interface.

Limitations and Constraints: Version 1 defines requirements supporting integration of standard NATO Receptacle with a platform. Future versions will address NATO Receptacle power requirements as a function of evolving platform/vehicle power capabilities.

Other Guidance: IOP attributes must reference and comply with MIL-C-62122(B), NATO STANAG 4074, SN-215 (NATO Plug) specifications and standards. NATO receptacles typically require a high-output alternator providing up to 4 kW of off-board power for other military equipment and can be used to jump-start other military vehicles if needed. Relevant IOP documents should reference the standard.

4.1.6 On-Vehicle E-Stop (IOP Capture: V1 = I, V2 = U)

Description: On-vehicle emergency stop (E-Stop) capability. Vehicle mounted manually operated emergency stop provides a mechanism to halt operation of a robot platform, and any associated actuators that could be potentially dangerous (i.e.

manipulator arm, end-effector, flippers) during manual operation (i.e., manual driving station or a fiber optic tether linked).

Defines physical interfaces (e.g. mounting, brackets, connectors) Defines electrical interfaces (e.g. power, connectors.)

Limitations and Constraints: Defines interfaces for platform mounted capability. This could also define the standard “look and feel” for the engagement mechanism (i.e. “red button, labeled ‘E-stop’”). As well, the WIPT should look into a means of disabling the on-vehicle E-stop for when the vehicle is in the field (i.e. locked cover; detachable switch) to prevent enemy tampering.

Other Guidance: Physical and electrical interfaces shall be based on current published standards and/or best industry standards.

4.1.7 Mission Payload Interface (IOP Capture: V0 = I, V2 = U) Description: Provides means to specify interoperable common/standard physical (e.g.

mounting rails, brackets, screws/bolts, thread sizes, etc.) and electrical (e.g. connectors, power rails, etc.) interfaces.

Defines physical interfaces (e.g. mounting, brackets, connectors) Defines electrical interfaces (e.g. power, connectors.)

Limitations and Constraints: Defines requirements associated with the physical and electrical interface of payload(s), or other sub-systems to the UGV platform. Mission payloads identified as non-compliant can interface with IOP complaint capabilities, through specification of an interface device adaptor or bridge which will be very important to applique type systems where the payload’s are already fielded and integrated in with the delivered vehicle.

Other Guidance: IOP compliant mission payload interfaces shall be based on current published standards and/or CoV payload interface requirements and specifications. See non-compliant section for payload with proprietary/non-interoperable interfaces.

Integration within the context of IOP “interoperability,” requires specification on an interface/device/adaptor or bridge. See non-compliant section.

4.2 Payloads

Payload is a physical device that interfaces to the robot using interoperable physical, power, and/or data interfaces, and is modular based on mission needs. A payload can be similar in nature to other devices that are integrated on a robotic vehicle, but a payload is not required for native UGV capabilities. Payload(s) themselves are treated by the IOP as black boxes in that the IOP does not specifically mandate internal standards, computing platforms, operating systems, or other integral components. This section identifies interoperability requirements with respect to standards and interfaces that are common across all payloads divided into four subsections, General, Sensor, Emitter, and Actuator. Sensor, Emitters, and Actuators follow payload definitions, extracted from SAE AIR5665A. The General section captures payloads that do not clearly correlate with SAE AIR5665A groupings. When this occurs, the primary function of the payload will be considered, and will be identified by the RS JPO. (Example: While a laser range finder does emit electro-magnetic energy, the primary function is to sense distance.)

4.2.1 Physical, and Electrical Interfaces

This section defines electrical, physical, and power interfaces supporting specification of payload interoperability (i.e., payload modularity, plug and play payloads, etc.).

4.2.1.1 Non-Compliant Payload Interface (IOP Capture: V2 = I) Description: Non-compliant payloads publish their own proprietary, non-interoperable interfaces interchangeable payloads, etc.) Capabilities specific to FoS, Recapitalized/retrofit and/or OEM programs determined non-compliant, may be specified as “interoperable” through implementation of an interface device, bridge or adaptor.

The RS JPO IOP non-compliant payload interface provides one or more mechanisms through which an interface/bridge/adaptor can be specified enabling a transparent “interoperable” interface between a non-compliant payload and IOP complaint capabilities.

Defines physical interface device/adapter or bridge.

Defines electrical interface device/adapter or bridge.

Limitations and Constraints: V2 should provide guidance on how adoption of a non-compliant standard might occur, OR alternatively provide attributes and guidance on how the physical and electrical interfaces may be adapted/bridged between the non-compliant and compliant sides of the system..

Other Guidance: Evaluate, if available, interface device/adapter or bridge best practices, standards, specifications and derive an IOP to non-complaint Interface Configuration Document (ICD) template. Specifying subject interface method provides a means to bring FoS, Recapitalized/retrofitted platforms and/or OEM “interchangeable” payloads into IOP “interoperability” compliance. Specifying a non-complaint interface shall be on a per-program basis.

4.2.2 General Payload

This section addresses interface attributes for payloads that do not clearly map to categories (i.e., sensor, emitter and actuator) and/or emerging payload capabilities. As well as capability interface with platform data bus enabling command, control, status and data exchange interoperability.

4.2.2.1 Weapon Engagement & Control (IOP Capture: V2 = I)

Description: Provides the ability to connect to and control a weapons system.

Defines physical interfaces (e.g. mounting, brackets, connectors) Defines electrical interfaces (e.g. power, connectors.)

Defines Capability physical and electrical interfaces to/with platform data bus and/or communication system.

Limitations and Constraints: Addresses physical and electrical interface requirements for weapons control and engagement. Address any physical or electrical interfaces needed for safety concerns.

Other Guidance: Coordinate with Communications WIPT with respect to platform data bus, network and/or communication system interfaces. Also for V2, this capability may be considered a research phase gathering information on the relevant interfaces that are currently fielded, and investigating new approaches. Consequent to that a brief synopsis by the WIPT may be delivered with its results to OVA.

4.2.2.2 Power Profiles (IOP Capture: V0 = I, V2 = U)

Description: Provides standard power profiles that a platform can have. Also provides for power distribution.

Defines physical interfaces (e.g. mounting, brackets, connectors) Defines electrical interfaces (e.g. power, connectors.)

Defines power profile (i.e. supply voltage, current, etc.)

Limitations and Constraints: V0 established a number of power profiles. Through feedback, we have learned that for some types of payloads the power profile is inadequate and therefore will not work in all cases. Power profiles for applique type systems, as well as, standalone platforms should be considered. Power profiles for micro UGV’s will not be examined, as they are typically very specialized to the individual platform.

4.2.2.3 Payload Render Useless (IOP Capture: V2 = I)

Description: Provides the ability to engage a render useless function on an attached payload.

Defines physical interfaces (e.g. mounting, brackets, connectors) Defines electrical interfaces (e.g. power, connectors.)

Defines Capability physical and electrical interfaces to/with platform data bus and/or communication system.

Limitations and Constraints: V1 introduced logical and HMI interfaces for engaging a render useless function on a platform. This capability is intended to examine if the solution presented in V1 is sufficient for emerging and legacy payloads, and present a solution.

Other Guidance: The IOP should include guidance on how a legacy payload without a render useless function, could be integrated “safely” WRT IA on a platform.

4.2.3 Sensor

The sensor section is used to describe interoperable interfaces for devices that sense conditions, both on and off the platform.

4.2.3.1 Drive Vision (IOP Capture: V0 = I, V2 = U)

Description: Drive vision describes motion imagery necessary to drive a robotic platform in teleop mode. This section provides the capability to interface drive vision payloads onto robotic systems. It describes the capability interface with platform data bus and/or communication device enabling command, control, status and data exchange interoperability.

Defines physical interfaces (e.g. mounting, brackets, connectors) Defines electrical interfaces (e.g. power, connectors.)

Defines Capability physical and electrical interfaces to/with platform data bus and/or communication system.

Limitations and Constraints: Addresses physical and electrical interface requirements per current IOP instantiation. Up until V2, drive vision was an integral part of the robotic platform. Introduced in V2 is augmentation of a vehicle (i.e. applique) type systems, and drive vision solutions for said types of vehicles should be looked into, and determine if V1 of the IOP meets those needs or additional attributes need to be profiled for electrical, physical, and power interfaces.

Other Guidance: Coordinate with Communications WIPT with respect to platform data bus, network and/or communication system interfaces.

4.2.3.2 Motion Imagery (IOP Capture: V0 = I, V2 = U)

Description: Non-driving motion imaging system payload. This section provides the capability to interface motion imagery payloads onto robotic systems. It describes the capability interface with platform data bus and/or communication device enabling command, control, status and data exchange interoperability.

Defines physical interfaces (e.g. mounting, brackets, connectors) Defines electrical interfaces (e.g. power, connectors.)

Defines Capability physical and electrical interfaces to/with platform data bus and/or communication system.

Limitations and Constraints: Physical and electrical minimal interface requirements per current IOP instantiation. For V2, a review of V0/V1 capabilities is to be accomplished and determined if they are sufficient or more is needed.

Other Guidance: Coordinate with Communications WIPT with respect to platform data bus, network and/or communication system interfaces.

4.2.3.3 Still Imagery (IOP Capture: V0 = I, V2 = U)

Description: The robot may need to take still imagery at times. This section provides the capability to interface still imagery payload to robotic systems. Describes capability interface with platform data bus and/or communication device enabling command, control, status and data exchange interoperability.

Defines physical interfaces (e.g. mounting, brackets, connectors) Defines electrical interfaces (e.g. power, connectors.)

Defines Capability physical and electrical interfaces to/with platform data bus and/or communication system.

Limitations and Constraints: Physical and electrical minimal interface requirements per current IOP instantiation. For V2, a review of V0/V1 capabilities is to be accomplished and determined if they are sufficient or more is needed.

Other Guidance: Coordinate with Communications WIPT with respect to platform data bus, network and/or communication system interfaces.

4.2.3.4 CBRN (IOP Capture: V0 = I, V2=U)

Description: Provides the capability to interface Chemical, Biological, Radiology and Nuclear (CBRN) detection sensors to robotic systems. Describes capability interface with platform data bus enabling command, control, status and data exchange interoperability.

Defines physical interfaces (e.g. mounting, brackets, connectors) Defines electrical interfaces (e.g. power, connectors.)

Defines Capability physical and electrical interfaces to/with platform data bus and/or communication system.

Limitations and Constraints: For V2, a review of the CCSI standard and its electrical, physical, and power interfaces is needed to see if the IOP should continue to use the CCSI standard as one of its IOP compliant interfaces. Additional profiling may be necessary (similar to how JAUS profiling is accomplished).

Other Guidance: Joint Program Executive Office for Chemical Biological Defense (JPEO-CBD) has developed a standard for sensor physical, electrical interfaces, power requirements, component interconnections, power and external connectors for CBRN sensors. Suggest referencing most current standard and interface documentation in conjunction with specification of an interface device, adapter.

4.2.3.5 Explosive Detection (IOP Capture: V0 = I)

Description: Provides the capability to interface chemical explosive detection sensor to robotic systems. Describes capability interface with platform data bus enabling command, control, status and data exchange interoperability.

Defines physical interfaces (e.g. mounting, brackets, connectors) Defines electrical interfaces (e.g. power, connectors.)

Defines Capability physical and electrical interfaces to/with platform data bus and/or communication system.

Limitations and Constraints: Physical and electrical minimal interface requirements per current IOP instantiation.

Other Guidance: Data bus interface in coordination with Communications WIPT as well as non-compliant considerations with respect to FoS, and OEM proprietary physical, electrical and data bus implementations. Consult current IOP instantiation capability analysis for guidance with respect updated and or emerging capability interface requirements such as the P/E interfaces.

4.2.3.6 Radar (IOP Capture: V2 = I)

Description: Provides the capability to interface a radar sensor system to robotic systems. Describes capability interface with platform data bus enabling command, control, status and data exchange interoperability.

Defines physical interfaces (e.g. mounting, brackets, connectors) Defines electrical interfaces (e.g. power, connectors.)

Defines Capability physical and electrical interfaces to/with platform data bus and/or communication system.

Limitations and Constraints: Physical and electrical minimal interface requirements per current IOP instantiation. As there are multiple types of radar a subset of radars should be looked at to determine the best means of incorporating the physical and electrical interfaces into the IOP. Ground Penetrating Radar shall be one of the types of radar researched.

Other Guidance: Data bus interface in coordination with Communications WIPT as well as non-compliant considerations with respect to FoS, and OEM proprietary physical, electrical and data bus implementations.

4.2.3.7 Microphone (IOP Capture: V0 = I, V2=U)

Description: Provides the capability to interface microphone sensors to robotic systems. Describes capability interface with platform audio system enabling command, control interoperability.

Defines physical interfaces (e.g. mounting, brackets, connectors) Defines electrical interfaces (e.g. power, connectors.)

Defines Capability physical and electrical interfaces to/with platform data bus and/or communication system.

Limitations and Constraints: Physical and electrical minimal interface requirements per current IOP instantiation. For V2, a review of V0/V1 capabilities is to be accomplished and determined if they are sufficient or more is needed.

Other Guidance: Evaluate industry standard audio system interface requirements.

4.2.3.8 Range Finder (IOP Capture: V0 = I)

Description: Laser range finders (LRF) (aka Light Detection and Ranging (LIDAR) or Laser Detection and Ranging (LADAR) sensors) are a combination emitter and sensor but their primary function is to “sense” distance to objects. Some LRF are used in target acquisition to determine distance to targets, but there are also scanning laser range finders that are used in robotics to develop three dimensional map of surroundings for autonomous path following and obstacle detection. Further, this capability can also be deployed in detecting Nuclear Biological and Chemical (NBC) particle clouds. Section provides the capability to interface electronic range finder payloads to robotic systems Describes capability interface with platform data bus enabling command, control, status and data exchange interoperability.

Defines physical interfaces (e.g. mounting, brackets, connectors) Defines electrical interfaces (e.g. power, connectors.)

Defines Capability physical and electrical interfaces to/with platform data bus and/or communication system.

Limitations and Constraints: Physical and electrical minimal interface requirements per current IOP instantiation.

Other Guidance: Data bus interface in coordination with Communications WIPT as well as non-compliant considerations with respect to FoS, and OEM proprietary physical, electrical and data bus implementations.

4.2.3.9 Thermal (IOP Capture: V0 = I)

Description: Thermal sensors are used for the sensing of heat changes. Provides the capability to interface thermal sensors to robotic systems. Describes capability interface with platform data bus enabling command, control, status and data exchange interoperability.

Defines physical interfaces (e.g. mounting, brackets, connectors) Defines electrical interfaces (e.g. power, connectors.)

Defines Capability physical and electrical interfaces to/with platform data bus and/or communication system.

Limitations and Constraints: Physical and electrical minimal interface requirements per current IOP instantiation.

Other Guidance: Data bus interface in coordination with Communications WIPT as well as non-compliant considerations with respect to FoS, and OEM proprietary physical, electrical and data bus implementations..

4.2.3.10 Force Sensing Device (IOP Capture: V1 = I, V2=U)

Description: Sensor that specifically measures force. Provides the capability to interface Force Sensing sensors to robotic systems. Describes capability interface with platform data bus enabling command, control, status and data exchange interoperability.

Defines physical interfaces (e.g. mounting, brackets, connectors) Defines electrical interfaces (e.g. power, connectors.)

Defines Capability physical and electrical interfaces to/with platform data bus and/or communication system.

Limitations and Constraints: Physical and electrical minimal interface requirements per current IOP instantiation. For V2, multiple use cases of force sensors either applied as feedback in a control loop, or for investigation and report to the operator, shall be considered and what is in place in V0/V1 will be evaluated to determine if it is sufficient.

Other Guidance: Data bus interface in coordination with Communications WIPT as well as non-compliant considerations with respect to FoS, and OEM proprietary physical, electrical and data bus implementations. Consult current IOP instantiation capability analysis for guidance with respect updated and or emerging capability interface requirements such as the P/E interfaces.

4.2.4 Emitter

The emitter section is used to describe devices that emit or release material or energy into the platform surroundings.

4.2.4.1 Lights (IOP Capture: V0 = I, V2 = U)

Description: Provides the capability to interface lights to robotic systems. Describes platform data bus interface enabling light control system interoperability.

Defines physical interfaces (e.g. mounting, brackets, connectors) Defines electrical interfaces (e.g. power, connectors.)

Defines Capability physical and electrical interfaces to/with platform data bus and/or communication system.

Limitations and Constraints: Physical and electrical minimal interface requirements per current IOP instantiation.

Other Guidance: Data bus interface in coordination with Communications WIPT.

4.2.4.2 Speaker (IOP Capture: V0 = I)

Description: Provides the capability to interface speakers to robotic systems.

Describes capability interface with platform audio system enabling command, control interoperability.

Defines physical interfaces (e.g. mounting, brackets, connectors) Defines electrical interfaces (e.g. power, connectors.)

Defines Capability physical and electrical interfaces to/with platform data bus and/or communication system.

Limitations and Constraints: Physical and electrical minimal interface requirements per current IOP instantiation.

Other Guidance: Evaluate industry standard audio system interface requirements.

4.2.5 Actuator

Actuators can be considered very similar in that they are a collection of various components with various degrees of freedom. An actuator could be as simple as controlling translations and rotations. However, in some cases, there may be important features the user or robot may need to be aware of. As a result, specific actuators are described and included.

4.2.5.1 Basic Arm (IOP Capture: V0 = I)

Description: Provides the capability to interface a basic arm manipulator on robotic systems. Describes capability interface with platform data bus enabling command, control and status interoperability.

Defines physical interfaces (e.g. mounting, brackets, connectors) Defines electrical interfaces (e.g. power, connectors.)

Defines Capability physical and electrical interfaces to/with platform data bus and/or communication system.

Limitations and Constraints: Physical and electrical minimal interface requirements per current IOP instantiation.

Other Guidance: ISO 8373 should be considered. Data bus interface in coordination with Communications WIPT as well as non-compliant considerations with respect to FoS, and OEM proprietary data bus implementations.

4.2.5.2 Telescoping (Mast) (IOP Capture: V0 = I)

Description: Provides the capability to interface telescoping mast to robotic systems.

Describes capability interface with platform data bus enabling command, control and status interoperability.

Defines physical interfaces (e.g. mounting, brackets, connectors) Defines electrical interfaces (e.g. power, connectors.)

Defines Capability physical and electrical interfaces to/with platform data bus and/or communication system.

Limitations and Constraints: Physical and electrical minimal interface requirements per current IOP instantiation.

Other Guidance: ISO 8373 should be considered. Data bus interface in coordination with Communications WIPT as well as non-compliant considerations with respect to FoS, and OEM proprietary data bus implementations.

4.2.5.3 Pan/Tilt (IOP Capture: V0 = Initial)

Description: Provides the capability to interface pan/tilt payload to robotic systems.

Describes capability interface with platform data bus enabling command, control and status interoperability.

Defines physical interfaces (e.g. mounting, brackets, connectors) Defines electrical interfaces (e.g. power, connectors.)

Defines Capability physical and electrical interfaces to/with platform data bus and/or communication system.

Limitations and Constraints: Physical and electrical minimal interface requirements per current IOP instantiation.

Other Guidance: ISO 8373 should be considered. Data bus interface in coordination with Communications WIPT as well as non-compliant considerations with respect to FoS, and OEM proprietary data bus implementations.

4.2.5.4 End Effectors (IOP Capture: V0 = I)

Description: Provides the capability to interface end effectors payload to robotic systems. Describes capability interface with platform data bus enabling command, control and status interoperability. The end effectors are the end-of-arm tooling on a robot. As other payloads can be attached to the end of an arm, such as a sensor or emitter, the end effector payload is defined as an actuator based system, like a gripper or cutter.

Defines physical interfaces (e.g. mounting, brackets, connectors) Defines electrical interfaces (e.g. power, connectors.)

Defines Capability physical and electrical interfaces to/with platform data bus and/or communication system.

Limitations and Constraints: Physical and electrical minimal interface requirements per current IOP instantiation.

Other Guidance: ISO 8373 should be considered. Data bus interface in coordination with Communications WIPT as well as non-compliant considerations with respect to FoS, and OEM proprietary data bus implementations.

4.2.5.5 Hydraulic Actuators (IOP Capture: V2 = I)

Description: Provides the capability to mount and interface with a hydraulic actuator (cylinder/other) for power transfer applications.

Defines physical interfaces (e.g. mounting, brackets, connectors)

Limitations and Constraints: Capability is described as needing quick disconnect connectors for hydraulic lines presumably for a payload that utilizes hydraulics but does not have its own hydraulic plant.

Other Guidance: N/A

4.2.5.6 Air Actuators (IOP Capture: V2 = I)

Description: Provides the capability to mount and interface with a air actuator (cylinder/turbine/other) for power transfer applications.

Defines physical interfaces (e.g. mounting, brackets, connectors)

Limitations and Constraints: Capability is described as needing quick disconnect connectors for air lines presumably for a payload that utilizes air (i.e. air spade) but not have its own air source. Also for larger vehicles this could relate to connections on air lines between towing and towed platforms.

4.3 Communications

The communication IOP capabilities are focused on the interoperability of the communications system as interfaced to the robotic platform and to the controller system. The main intent is to focus the communications profile to support the set of currently fielded systems (platforms and controllers) and to consider the radio as a black box plug-in to both the robotic platform and the controller systems. As the Army community defines requirements for large scale network integration of robotic platforms and controllers, the communications profile capabilities will evolve. The communications WIPT may consider the establishment of working groups in this area as well as in areas dealing with mesh technologies, encryption, quality of service, etc., to contemplate paths forward as well as standardization and interoperability approaches related to these topics in preparation for these requirements.

4.3.1 Physical, Electrical (IOP Capture: V0 = I,V2 = U)

This section defines interfaces supporting specification of communication system interoperability (i.e., radio system, platform data bus, platform network, external communication interface, etc.)

Defines physical interfaces (e.g. mounting, brackets, connectors) Defines electrical interfaces (e.g. power, connectors.)

Limitations and Constraints: Section supports definition physical and electrical interfaces enabling specification of communication capability interfaces. Defines requirements associated with the physical and electrical connectors employed to integrate communication capabilities.

Other Guidance: Physical and electrical interfaces shall be based on current published standards. WIPT should coordinate with Platform and Payloads with respect to platform networks/data bus interfaces. WIPT should coordinate with Overarching with respect to non-IOP communications (e.g., Unmanned Air Vehicle (UAV), Unmanned Ground Sensors (UGS), etc.)

4.3.2 Non-Compliant Interface (IOP Capture: V1 = I, V2 = U)

Description: The ability to receive and display video feeds from sources outside of the robotic system (i.e. controllers and platforms) is important for situational awareness.

Examples of non-compliant video sources include, but are not limited to, UAS imagery, and remote video terminals. UAS interoperability is specified in the STANAG 4586 standard. WRT to the UGV IOP, the UAS IOP is currently non-compliant, and this capability is specifically aimed at bridging the two IOP’s.

The RS JPO IOP non-compliant communication interface provides mechanism through which an interface/bridge/adaptor can be specified enabling a transparent “interoperable” interface between a non-compliant communications system and IOP complaint system and/or interoperable capabilities.

Profiles the best means of interoperability between the UAS and UGV domains.

Limitations and Constraints: For the purposes of V1, the ability to receive non-compliant video feeds are constrained by the network protocols defined in V0 and updated in V1. Identification of standards, protocols, and minimum radio specifications for bandwidth/data rates/etc. may be investigated. For Version 2, consider a framework for bridging the capabilities of the two domains.

Other Guidance: Recommend developing a matrix/table of common Non-compliant communication systems. Include references to specification, requirements, supported waveforms/frequencies and security considerations.

4…