attach0014.pdf

Unclassified

UGV Interoperability Profile (IOP) Capabilities Plan

For Version 1

Robotic Systems, Joint Project Office (RS JPO)

SFAE-GCS-UGV MS 266

6501 East 11 Mile Road

Warren, MI 48397

*Note: This document’s sole purpose is to scope & bound the capabilities to be addressed in Version 1 of the IOP.

March 2012 i

Table of Contents

1 Scope

1.1 Overview

1.2 Applicability

2 Capabilities Definition Process

3 Capabilities

3.1 Platform/Vehicle

3.1.1 Physical, Electrical, and Logical Interfaces

3.1.2 Basic platform

3.1.3 Basic Mobility

3.1.4 Basic Navigation

3.1.5 Leader-Follower

3.1.6 Advanced Navigation

3.1.7 Guarded Tele-Operation

3.1.8 Platform Security

3.2 Payloads

3.2.1 Sensor

3.2.2 Emitter

3.2.3 Actuator

3.2.4 General Payload

3.3 Communications

3.4 Control

3.4.1 Software

3.4.2 HCI

3.4.3 Command and Control (C2)

3.4.4 Mission Planning

3.4.5 Physical, Electrical and Logical Interfaces

Appendix A: Additional Topics………………………………………………………………..40

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 pay-loads, sensors, software, and computing devices are anticipated to evolve much faster than the base platforms, creating interoperable interfaces for enhanced modularity represents an opportunity to minimize future life cycle costs and adapt rapidly to changing threats or new available technologies.

The initial publication of RS JPO UGV IOP, Version 0 (V0), defines interoperable interfaces and protocols necessary to enable interoperability and modularity with respect to capabilities that have already been widely fielded. The exact set of capabilities addressed in IOP V0 is described in the UGV IOP V0 Capabilities Plan.

The RS JPO IOP Capability Plan, presented herein, is a “living” document designed to address specific requirements and capabilities applicable to planned and emerging robotic systems and will; 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.

RS JPO IOP Capability Plan iterations provide 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 details with respect to IOP release candidate (i.e., V1, V2, etc.) interoperability attributes derived from source capability requirements. Release candidate Capability Plan provides an overview of capability intent through narrative abstracts, defines top-level interoperability scope, and discusses associated limitations and constraints as applicable to the IOP release candidate (i.e., V1, V2, etc.) development effort. This document serves to provide guidance to the Working Integrated Product Team (WIPT) organizations participating in the IOP release candidate (i.e., V1, V2, etc.) development in identifying and defining an optimized path towards interoperability. This document does not define how things are to be done (implementation of requirements to interoperability standards or messages). In addition, while this document will retain a level of traceability to the V1 release candidate (i.e., V1, V2, 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 its parts.

2 Capabilities Definition Process The intent of the capabilities definition process is to identify, specify, and define key robotic capabilities and assign them in an aligned sequential fashion to IOP version releases (i.e. V0, V1, V2, V3) with respect to a determined acquisition need date.

Initially this was very difficult to do given the fact that V0 capabilities spanned a set of capabilities that have already been fielded, as well as, a set of capabilities that will be fielded in the near future. Currently for V1 capabilities, emerging requirements for future programs of record have been captured. This gave an opportunity to define capabilities based on projected acquisition funding and scheduling for those programs. With this method, the capabilities identified in this plan should be able to be defined in advance of projected acquisition initiatives. This allows the ability to define interoperability mechanisms that can then be employed as part of the acquisition cycle.

With respect to V1, capabilities have been identified by researching and compiling all emerging requirements that were available within the RS JPO. The requirements were obtained from the programs latest Capability Development Documents (CDDs) and Capability Production Documents (CPDs). From the interoperability applicable requirements that were extracted from the capability documents, a capabilities list was generated. In several recurring meetings, WIPT leads and industry partners reviewed the requirements and solidified those that should be captured in V1. After the capabilities were chosen, they were vetted among the User and Combat Developer Community. Once the feedback was implemented from the User and Combat Developer community, narratives for the capabilities were written. In writing the narratives, the IOP capabilities definition process provisions for decomposition of capabilities to interoperability attributes with respect to future programs of record and/or emerging requirements therein supporting Unmanned Systems Initial Capabilities Document, the Robotics Roadmap and the UGV Campaign Plan IOP 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. The capabilities plan was then sent to all the Interoperability IPT team members so they could provide any suggestions. The final step in the process was to deliver the finalized capability plan to all the Interoperability IPT team members, so that the WIPT working groups could use them to populate their portion of the IOP

Appendix A of this document serves as examples of how program specific capabilities are decomposed into capabilities that enable interoperability, and their mapping to the V1 Capabilities Plan.

2.1 Non-Compliant Systems and Interfaces

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. 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 anon-compliant system. This Capabilities Plan additionally defines non-compliant interfaces as those interfaces outside the scope or domain of the published Interoperability Profiles. For example, a UAS video feed or logistics database interface would be considered non-compliant interfaces under the V1

IOP.

3 Capabilities The capabilities defined below are presented in accordance with the IOP Composability taxonomy defined within the Overarching IOP. It should be noted that even though these capabilities are specified as “common” by nature of the V1 definition, it is understood that not all capabilities will be available within every robotic system and in some cases; there may be some variation in how the capability is defined/provided.

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 provide ways for 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, the manner of which is not explicitly defined as a capability within this plan.

In addition, the definitions below serve as guidelines and are 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.

3.1 Platform/Vehicle (IOP Capture: V0 = Initial, V1 = Update)

Common to all robotic systems is the platform/vehicle, an aggregation of inherent and mission specific capabilities. Inherent functional capabilities generally consist of a 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 communication system (intra platform, inter platform). Mission Specific functional capabilities generally consist of payloads (sensors, emitters, actuators), computation (waypoint navigation, sensor fusion), communications (data link, antennas) and miscellaneous peripherals (switches, audio devices).

Platform/vehicle inherent and mission specific capabilities are functionally and logically interconnected as function of defined interoperability attributes. For example, platform/vehicle chassis interoperability attributes define physical interface requirements (i.e., drive system, batteries, electrical system, computation system, communication system, payloads, etc.); define electrical interface requirements (i.e., power bus, lights, computation system, power generation, mobility system, payloads, etc.); and define logical interface requirements (i.e., communications, computation, sensors, mobility, payloads, etc.)

Platform/vehicle capabilities discussed in this section are segregated into two sections, basic and advanced. Basic capabilities are essentially inherent and mission specific capabilities common to most robot applications such as basic mobility control, waypoint navigation, and manipulator control. Basic capability interoperability attributes have been captured in the Version 0 IOP documentation release. Advanced capabilities refine VO basic capabilities and capture emerging and or developing capabilities such as advanced command and control, advanced navigation, sensing payloads, and platform/vehicle health reporting.

3.1.1 Physical, Electrical, and Logical Interfaces

(IOP Capture: V0 = Initial, V1 = Update)

Platform/vehicle systems/subsystem and mission specific plug and play modularity, interchangeability and interoperability capabilities

3.1.1.1 Tether (IOP Capture: V1 = Initial)

Description: Non-radio frequency or “hardwired” operator/robotic system command and control capability. Tether provides robotic platform/operator control unit (OCU) non-radio frequency (i.e., fiber-optic cable, twisted wire, etc.) communications capability.

Tether communications allow for manual driving of the robot platform as well as platform tether mode supported command, control and monitoring capabilities when transmission of RF signals is not desired and/or non-supported. Note that “tether” referred to here is a fixed communications device implying command, control, and feedback regardless of how it is designed or of any other physical capabilities it may have that are not IOP related.

Defines non-radio frequency or “hardwired” physical mounting, electrical interfaces.

Defines logical communication for control, states and modes.

Limitations and Constraints: Version 1 supports basic mobility command and control, payload command and control, hardwired emergency stop and platform control states and modes feedback.

Other Guidance: Physical and electrical interfaces, communication medium and logical transport mechanism interoperability requirements shall be based on current published standards.

3.1.1.2 NATO Receptacle (IOP Capture: V1 = Initial)

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

Defines NATO receptacle to platform/vehicle physical mount and electrical interfaces.

Limitations and Constraints: Version 1 defines requirements supporting integration of standard NATO Receptacle with a platform/vehicle irrespective of NATO Receptacle external /off-board power capabilities. 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.

3.1.1.3 Non-Compliant Payload Channel (IOP Capture: V1 = Initial)

Description: Non-compliant payloads are an aggregation of capabilities (i.e., sensor(s), emitters, effectors, manipulators, etc.) designed to address a functional objective (i.e., obstacle detection and avoidance, explosive hazard detection and marking, etc.) that provide their own logical communication (channel) interface protocol, processing core, power and/or provide external power interface.

A non-compliant payload channel provides a mechanism through which mission package(s) can be installed on a host platform and interface with the communication system(s) provided by the host platform. The channel allows the payload to communicate using its own logical interface protocol allowing for discovery of capabilities, configuration if supported and applicable and status monitoring.

Platform/vehicle logical communications feed via RF link from a non-compliant payload package.

Defines logical communication of capabilities.

Defines logical communication for configuration.

Defines logical communication of status.

Defines logical communication of non-compliant payload specific data.

Limitations and Constraints: N/A

Other Guidance: Evaluate, if available, non- compliant payload package interface standards, specifications and Interface Control Document (ICD) documentation.

3.1.1.4 Vehicle Network (IOP Capture: V1 = Initial)

Description: Platform/vehicle “on-board/native” network (i.e., CAN (asynchronous serial bus), LIN/SAE J2602 (universal asynchronous network), FlexRay (time-deterministic communications protocol with a dual channel network), etc.)

communications capability.

Defines logical communication interfaces.

Limitations and Constraints: N/A

Other Guidance: Evaluate commercial and mil spec on-board vehicle network technologies. Evaluate on-board vehicle industry best practices, standards and specifications.

3.1.1.5 On-Vehicle E-Stop (IOP Capture: V1 = Initial)

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 on-vehicle emergency stop physical, electrical interfaces.

Defines logical communication of status.

Limitations and Constraints: N/A

Other Guidance: Evaluate unmanned system E-Stop operational and integration best practices.

3.1.1.6 Mission Payload Mounting (IOP Capture: V0 = Initial, V1=updated)

Description: Physical mounting and mount points for payloads, both compliant or non-compliant. Standard physical connectors, i.e. standard screws/bolts, thread sizes, etc.

In addition, standard connections for power, and other electrical interfaces (i.e.

comms/logical). Non-compliant mounting options may include adaptors/brackets for both physical and electrical mounting.

Defines mounting physical interfaces and adaptors.

Defines electrical interfaces and adaptors.

Other Guidance: N/A

3.1.2 Basic platform (IOP Capture: V0 = Initial, V1 = Update)

Basic platform defines capabilities associated with the physical infrastructure that contains and supports various robotic system subsystems. The capability requirements in the basic platform are the most basic requirements for a robotic system to function.

3.1.2.1 Battery Status (IOP Capture: V0 = Initial, V1 = Update)

Description: Platform/vehicle battery/power status (i.e., charge level, terminal voltage, opens, shorts, load allocation, run-time estimation, surge events, power remaining, low power, alarms, etc.) configuration, monitoring and communication capability.

Defines sensor(s) physical, electrical interfaces.

Defines logical communication of capabilities.

Defines logical communications for configuration.

Defines logical communication of status.

Defines logical communication of data reports.

Limitations and Constraints: Version 0 addressed reporting platform battery charge level. Version 1 extends basic battery status to include query/response of battery/power remaining and low power alerts as well as platform specific detailed reports. Methods of determining power draw are not relevant to the IOP profile, however logical communication of power draw and/or time remaining should be determined.

Other Guidance: N/A

3.1.2.2 Usage (IOP Capture: V0 = Initial)

Description: Provides the ability to record or track the usage associated with the robotic platform. The usage will likely be stated as a distance traveled and hours of operation of the system (one set for the platform, and one set for the OCU). Much like an odometer, this should not be reset, however a single use “trip meter” may be included if it is deemed necessary. This should not be confused with “usage” as defined with respect to JAUS.

Limitations and Constraints: Basic functionality in IOP V0 should allow for usage times or distances to be recorded / reported. There is no expectation that the basic data will be used for advanced features, such as prognostics at this time.

Other Guidance: JAUS messages may need to be recommended.

3.1.2.3 Engine Data (IOP Capture: V0 = Initial, V1 = Update)

Description: Platform/vehicle power source (e.g., engine power plant, fuel cell, etc.)

configuration, status and monitoring (e.g., fuel level(s), oil level, pressure, temperature, hydraulic level, pressure, temperature, coolant level, temperature, air intake temperature, pressure, humidity, exhaust temperature, charging system voltage, amperage, etc.) status and alerts (e.g., low fuel, oil, coolant, hydraulic level(s), pressure, etc.) communication capability.

Defines sensor(s) physical, electrical interfaces.

Defines logical communication of capabilities.

Defines logical communications for configuration.

Defines logical communication of status.

Defines logical communication of data reports.

Limitations and Constraints: Version 0 addressed reporting basic engine data.

Version 1 extends basic engine data to include alerts. Version 1 extends basic engine data to include query/response of fuel remaining; low fuel alerts, battery/power remaining and low power alerts as well as other platform specific detailed reports.

Other Guidance: N/A

3.1.2.4 Platform Mode (IOP Capture: V0 = Initial, V1 = Update)

Description: Platform/vehicle system/subsystem, payload, non-embedded operational mode query (i.e., supported modes), configuration, command (i.e., operational mode state transitions, reset, etc.) and reporting (i.e., mode state, mode warning and alerts, etc.) capability.

Defines logical communication of capabilities.

Defines logical communication for configuration.

Defines logical communication of status.

Defines logical communication for command and control.

Limitations and Constraints: Version 0 addresses basic set of platform modes common to most robotic systems (e.g., startup, operational, shutdown). Version 1 and future versions address advanced modes such as maintenance, standby, timed shutdown, anti-tamper, render useless, emergency, system abort etc.. Some modes are not selectable (i.e. emergency and system abort). Non-selectable modes are modes for which the operator may or may not be able to recover the platform from.

Other Guidance: Platform mode describes the current operational state of the robotic system. This may include startup, shutdown, standby, ready, in use/busy, emergency, system abort and reset. It may also include modes as determined by the WIPT membership. The platform mode is different than the drive mode, in that all drive modes could go into a startup or standby mode, or be reset. The most basic set of platform modes should map to most/all robotic systems even if they do not specifically report a platform status (e.g., startup, operational, shutdown). Additional modes such as maintenance, standby, timed shutdown, anti-tamper, render useless are envisioned for future robotic systems, but are not at this time considered part of the basic capability.

JAUS messages may need to be recommended. WIPTs may want to consider, but not necessarily define, future state/mode requirements when deriving this capability as a means of defining a platform mode element that can be scaled to meet future capability requirements.

3.1.2.5 Position/Attitude (IOP Capture: V0 = Initial)

Description: Provides a standard mechanism to report the position/attitude of the robotic platform. For the basic platform, this is envisioned to be a geo-referenced location on the earth; a heading (referenced from the front center of the vehicle); and an indication of the pitch and roll. It is recommended that the system report based on a local reference frame, as well as a global reference frame, such as the WGS84 standard. The WIPTs may determine other standards for position and attitude.

Limitations and Constraints: The location and attitude (heading, pitch, roll, etc…) include only a simple data point. Later versions can include more advanced information as required. This capability should be defined to allow for systems to partially conform in accordance with their ability (e.g., report location and heading only in the absence of an internal navigation package).

Other Guidance: JAUS messages may need to be recommended. Additional standards will need to be identified to accurately describe the data point.

3.1.2.6 Subsystem Configuration (IOP Capture: V0 = Initial, V1 = Update)

Description: Platform/vehicle integrated system(s)/sub-system(s), payload(s) and non-embedded payload(s) and communications identification (i.e., report the presence and type of capabilities functional/operational modes), configuration, and control (i.e., enable/disable integrated subsystems, enable integrated subsystems reset, etc.)

capabilities.

Defines logical communication of capabilities.

Defines logical communication for configuration.

Defines logical communication of status.

Defines logical communication for control.

Limitations and Constraints: Version 0 defines basic capability providing platform system/subsystem and integrated payloads configuration and operational state. Version 1 extends subject capability to include integrated subsystem reset capability.

Other Guidance: This is a high level capability that provides information to the operator regarding the system/subsystem level configuration of the robotic platforms and its integrated payloads. Examples include statements identifying the ability to move, use cameras, or the type of payloads. The level to which the robotic system reports this information will be largely a function of the program/system design, but conceptually this capability will scale to support more advanced capabilities associated with future revisions (e.g., calibration, power management, system aborts, system reset, etc.).

3.1.2.7 Subsystem Health (IOP Capture: V0 = Initial, V1 = Update)

Description: Query, configuration, command and report of operator initiated and/or automated BIT, diagnostics, fault/failures, basic health, and platform specific health capability.

Defines logical communication of capabilities.

Defines logical communication for configuration.

Defines logical communication of status.

Defines logical communication for query and of status/report.

Defines logical communication of subsystem specific health.

Limitations and Constraints: Version 0 health monitoring addresses basic information and is not intended to provide in depth diagnosis/fault reporting. Version 1 addresses commanded and automated BIT testing as well as platform/vehicle specific system reports. Version 1 is a first step towards health management, as well as, health reporting that can be used to interface to external logistics systems.

Other Guidance: Future version address advanced messages describing the exact failure, nature of the failure, diagnostics and prognostics as well as system specifications outside of the current interoperability profile(s).

3.1.2.8 Pose/Articulation (IOP Capture: V0 = Initial)

Description: Specifies a set of pre-programmed poses that a robotic platform may utilize. Not all systems will utilize all poses, but a base set of poses can be developed for use with an interoperable controller. Examples could include “stow”, “deploy”, and “drive”.

Limitations and Constraints: Some systems may have many poses, while others may have few or no poses. For this capability only basic poses should be considered. In subsequent versions, the ability of the system to send possible pose descriptions to the operator may be considered. This capability may be limited by the payloads placed on the system, and may be limited in functionality for IOP V0. The WIPT and user community will decide on these poses.

Other Guidance: JAUS messages may need to be recommended.

3.1.2.9 E-Stop, or Emergency Stop (IOP Capture: V0 = Initial)

Description: The robotic system should be able to receive an emergency stop message, which places the robot into a safe state (this state will likely need to be considered in the definition of the platform mode).

Limitations and Constraints: The E-stop should be able to place the robotic system into a safe state; however, it is understood that the term “safe” may be interpreted differently in accordance with the robotic system design (for example, this could be interpreted as a complete shutdown for some systems, while for other systems a less harsh interpretation may be considered). In addition, certain systems may have overriding “stop” or “E-stop” actions defined as part of their system design and/or performance spec. For this capability, the WIPTs will attempt to best define an E-Stop capability and resultant action that can be best adapted given these ambiguities.

Subsequent versions may attempt to provide more specific actions or progressive capabilities associated with this requirement.

Other Guidance: JAUS messages may need to be recommended.

3.1.2.10 Heartbeat (Liveness) (IOP Capture: V0 = Initial)

Description: Specifies the provision of a simple heartbeat mechanism to detect the introduction, removal or failure of communications. This is often used to provide awareness and reaction to a loss or intermittency of communications.

Limitations and Constraints: At a minimum, a high level duplex heartbeat between the robotic platform and its controller(s) is deemed to be sufficient to support the basic capability.

Other Guidance: Current JAUS capabilities are intended to map to/provide this functionality.

3.1.2.11 Reporting

(IOP Capture: V1 = Initial)

Description:

Reporting is a means of aggregating information and data from various sub-systems into a format that can used within the system or externally. One such example is aggregation of health information used in conjunction with an uplink to a logistics database.

Defines logical communication of capabilities.

Defines logical communication for configuration.

Defines logical communication of status.

Defines logical communication for query and of status/report.

Limitations and Constraints: This capability should a generic means of configuring reports for a particular sub-system(s). A means of tagging the reports for search and retrieval should also be considered.

3.1.3 Basic Mobility (IOP Capture: V0 = Initial, V1 = Update)

Common platform/vehicle basic mobility (e.g., drive mode, basic navigation, drive sensor, etc.) command, control, drive sensor video, and status communication capabilities.

3.1.3.1 Drive Mode (IOP Capture: V0 = Initial, V1 = Update)

Description: Specifies a set of modes used to position the platform utilizing the integrated mobility system such that the system can be commended to and/or report its driving mode. At a minimum, the following driving modes are considered applicable:

Remote Control (RC) Provides the ability to move/drive the platform with eyes on the robotic system

Teleoperation (Teleop) Provides the ability to move/drive the platform through a dedicated sensor(s).

Basic Navigation (BN) Provides the ability to move/drive the platform via a defined set of points specified by an external source.

Leader/Follower (L/F) Provides the ability to move/drive the platform in relation to an external source (e.g., vehicle or dismounted soldier). In this mode the robotic platform may be designated as either a leader or a follower.

Convoy (CV) Leader/Follower supplemental capability. This capability provides for configuration of convoys consisting of different type vehicles (i.e., purpose built unmanned platforms, appliqué kit equipped tactical vehicles such as HMMWV, FMTV, M915A3, etc.). Provides the ability to move/drive Leader or Follower or both as a function of trailing (follower) vehicle characteristics.

For example, assuming a FMTV is configured as lead vehicle and a M915A3 tractor-trailer as a follower, capability provides ability to compensate for the wide turn radius of the M915A3.

Limitations and Constraints: Some of the driving modes (e.g., basic navigation) may require an autonomy package integrated to the platform vehicle control system. This version is not concerned with defining those internal interfaces at this time or further subsetting capabilities into mobility payload packages. It is; however, likely that these interfaces (and potentially additional subsetting) will be defined in subsequent revisions.

The degree to which mobility modes may affect, limit, or relate to the platform mode should be considered in the detailed definition of this capability. In addition, the successful transition into some driving modes may be dependent upon the availability and status of a related subsystem (for example, selection and enabling of a driving sensor – from the point of view of the robotic platform – may be required prior to successful transition to and/or execution of teleop driving, where this would not be the case for other driving modes). Handling of emergency or system abort modes, where the platforms mobility could be compromised or restricted, should be taken into account.

Other Guidance: Current JAUS capabilities are intended to map to/provide this functionality. In some cases, additional JAUS messages may need to be recommended.

3.1.3.2 Gear (IOP Capture: V0 = Initial)

Description: Conceptually specifies the manner in which the robotic platform can be commanded to and will report its method of movement (e.g., forward, reverse, pivot)

Limitations and Constraints: The manner in which this capability is implemented will be determined by the WIPTs as systems vary with respect to the implementation of this capability. The term conceptual is used in the description as a specific drive select function may not be required (e.g., utilization of +/- values could determine direction vs.

a separate mode variable). The main requirement is to consistently map the required behavior. This capability is applicable to the RC and Teleop drive modes.

Other Guidance: Current JAUS capabilities are intended to map to/provide this functionality.

3.1.3.3 Speed/Acceleration

Description: Specifies the manner in and the degree to which the robotic platform will move and report its movement as commanded/queried by an external source. This will also allow control of speed and acceleration, as defined by the speed and acceleration limits.

Limitations and Constraints: It is envisioned that for the basic platform there will be one method defined and associated with this capability. The capability to set is applicable to the RC and Teleop drive modes.

Other Guidance: Current JAUS capabilities are intended to map to/provide this functionality.

3.1.3.4 Speed/Acceleration Limits (IOP Capture: V0 = Initial)

Description: Specifies the limits associated with the movement of the robotic platform.

These are intended to be reported only and not set by an external source, as these limits are platform constraints and not user settable.

Limitations and Constraints: There may be an association of these limits in relation to the commanded speed and acceleration. If so, the WIPTs will need to define those relationships. This capability to set is applicable to the RC and Teleop drive modes.

Other Guidance: Additional JAUS messages may need to be recommended.

3.1.3.5 Steering

Description: Specifies the manner in and the degree to which the robotic platform will turn and report its turning as commanded/queried by an external source.

Limitations and Constraints: It is envisioned that for the basic platform there will be one method defined and associated with this capability. This capability is applicable to the RC and Teleop drive modes.

Other Guidance: Current JAUS capabilities are intended to map to/provide this functionality.

3.1.3.6 Brake (IOP Capture: V0 = Initial)

Description: Conceptually specifies the manner in which the vehicle will slow or decelerate. This capability is stated to be conceptual due to the fact that braking may be defined as the absence of acceleration vs. a specific independent function in accordance with the system design.

Limitations and Constraints: Regardless of the presence or absence of a physical brake(s), this capability shall be implemented consistently. This capability is applicable to the RC and Teleop drive modes.

Other Guidance: Current JAUS capabilities are intended to map to/provide this functionality.

3.1.3.7 Drive Sensor Registration (IOP Capture: V0 = Initial)

Description: Provides the capability to identify and report a sensor as applicable to driving. Some platforms may have one (or none) driving sensor however other platforms may have multiple sensors specifically located (e.g., front, rear side) to be associated with teleoperation of the robotic platform.

Limitations and Constraints: Conceptually this capability provides an external source with information related to the availability of sensors best suited to remotely operate the platform. It may be the case that a robotic platform has only one sensor (associated with multiple tasks) or does not define a driving sensor and would need to accommodate this capability in the best manner possible. This capability is applicable to all driving modes with the exception of RC.

Other Guidance: Additional JAUS messages may need to be recommended.

3.1.3.8 Drive Sensor Selection (IOP Capture: V0 = Initial)

Description: Provides the capability to select and view sensor video associated with driving the robotic platform.

Limitations and Constraints: From the point of view of the robotic platform driving sensor(s) can be selected and enabled/disabled by an external source and there is no intent to limit the ability to send multiple or multiplexed video from several sources for display. In addition, the selection of the source is not explicitly intended to enable video transmission; however, that collective capability may be implemented within an external control system. This capability is applicable to all driving modes with the exception of

RC.

Other Guidance: Additional JAUS messages may need to be recommended.

3.1.3.9 Drive Timeout (IOP Capture: V0 = Initial)

Description: Provides a capability to monitor control messages from an external source to the robotic platform at a determined frequency to ensure that a loss of commanded input along the control chain does not result in unintended consequences or safety issues. Conceptually, this is a watchdog function to prevent stale data in the control chain from commanding the system.

Limitations and Constraints: This capability is addressed within the robotic platform (perhaps at multiple levels depending upon the control logic), but also needs to be considered external to the platform as well (for example, within a controller, multiple processes might be used to read handle data, process control input, and command vehicle movement). This capability is applicable to the RC and Teleop driving modes.

3.1.4 Basic Navigation (IOP Capture: V1 = Initial)

Description: Platform/vehicle basic navigation configuration, command, control and report communication capabilities.

3.1.4.1 Create Waypoint/Waypoint List (IOP Capture: V0 = Initial)

Description: Provides a capability to define a waypoint and an associated list of waypoints that can be utilized for simple navigation of the robotic platform along a path.

Limitations and Constraints: This capability is intended to provide a simple navigation mechanism. The waypoint is intended to represent a geo-location and may define some simple level of tolerance with respect to signifying the capture of the waypoint itself and desired speed between path segments. Actions at waypoints, waypoint time constraints (e.g., arrival and departure), plan volatility, plan validation, multi-plan definition/selection, and waypoint corridors are deferred to subsequent versions. Plan volatility and the ability to define multiple plans are not explicitly addressed, but if addressed by the WIPTs must be done so in a manner that keeps the functionality applicable across the set of systems that provide basic waypoint navigation. This capability is applicable to the BN driving mode.

3.1.4.2 Insert/Delete Waypoint (IOP Capture: V0 = Initial)

Description: Provides the capability to insert or delete a waypoint from a waypoint plan.

Limitations and Constraints: It is presumed that waypoint insertion and deletion would only occur with respect to a non-executing plan. This capability is applicable to the BN driving mode.

Other Guidance: Current JAUS capabilities are intended to map to/provide this functionality.

3.1.4.3 Load Waypoint Plan (IOP Capture: V0 = Initial)

Description: Provides the capability to load a defined waypoint plan for processing (execution) by the robotic platform.

Limitations and Constraints: While there is no requirement to explicitly validate waypoint plans, this capability may take simple checks into account prior to signifying the readiness to execute a specified plan. This capability is applicable to the BN driving mode.

Other Guidance: Current JAUS capabilities are intended to map to/provide this functionality. Also, for V0, the utilization of JAUS may nullify the need for an explicit “load” function. WIPTs are allowed to implement this and other waypoint functions in a “conceptual” manner. However, future planning requirements may require more separation between creation and loading with respect to waypoint (mobility) plans, as these plans may be more integrated/related to other capabilities within higher level mission plans (e.g. ISR).

3.1.4.4 Execute Waypoint Plan (IOP Capture: V0 = Initial)

Description: Provides the capability to initiate execution of a loaded waypoint plan.

Once the plan is executing, there are various events that can happen that may affect the plan execution state (e.g., intervention required). These conditions need to be considered in the definition of the functionality.

Limitations and Constraints: State machine logic associated with the load, execute, pause, and resume process will need to be defined by the WIPT. In addition, the relationship of the plan execution state to the driving mode state will also need to be addressed/defined by the WIPT (e.g., selecting the teleop driving mode while the plan is currently executing). This capability is applicable to the BN driving mode.

Other Guidance: Current JAUS capabilities are intended to map to/provide this functionality.

3.1.4.5 Waypoint Plan Status (IOP Capture: V0 = Initial)

Description: Provides the capability to report the status of the plan execution state machine to an external source. Plan status will also provide an indication and distance to the current target waypoint.

Limitations and Constraints: This capability will be largely tied to the waypoint plan execution state machine model. This capability is applicable to the BN driving mode.

Other Guidance: Current JAUS capabilities are intended to map to/provide this functionality.

3.1.4.6 Suspend/Resume Waypoint Plan (IOP Capture: V0 = Initial)

Description: Provides the capability to pause and re-initiate execution of a currently loaded/executing waypoint plan.

Limitations and Constraints: Similarly to plan execution, the relationship of the plan execution state and the driving mode state will need to be addressed/defined by the WIPT. In addition, the ability to reload or re-execute a plan while in a paused state will also need to be considered. This capability is applicable to the BN driving mode.

3.1.5 Leader-Follower (IOP Capture: V0 = Initial, V1 = Update)

Leader follower capability specifies the protocol, both through standard communications channels and operating procedures, for one or more vehicle systems to follow another vehicle system or other designated leader (soldier, other operator define entity). The capability includes initial configuration and identification of leaders and followers, configuration of convoys consisting of different type vehicles (i.e., purpose built unmanned platforms, appliqué kit equipped tactical vehicles such as HMMWV, FMTV, M915A3, etc.), formation attributes for the execution of a following mission, status communications providing position information, warnings and alerts, and recovery procedures for loss of leader/follower contact.

3.1.5.1 Leader/Follower Mode (IOP Capture: V0 = Initial, V1 = Update)

Description: Leader/Follower Mode capability specifies communication protocol(s) allowing for leader configuration (i.e., robotic platform, non-robotic platform, soldier, etc.); follower mode configuration (i.e., 1 – n followers); report of vehicle mobility characteristics (convoy), reporting of follow simple position data; and application defined GPS denied environment configuration, command, control and reporting.

Defines logical communication for designation of leader.

Defines logical communication for designation of leader vehicle type.

Defines logical communication for configuration of number of followers.

Defines logical communication for configuration of follower(s) vehicle type(s).

Defines logical communication of vehicle mobility characteristics (convoy) data.

Defines logical communication of simple position data.

Defines logical communication of GPS denied data.

Defines logical communication of command and control.

Limitations and Constraints: Version 1 adds configuration and operation of multiple followers, operator designation of a leader other that self and a leader other than a robotic platform; also, version 1 supports operation in GPS denied environment capability.

Other Guidance: Provides the ability to specify the robotic platform leader/follower mode within a leader/follower configuration. For this basic capability, the robotic platform will simply be designated as a “Leader” or a “Follower.” The intent of the leader capability requirement is to provide a simple position designation to a set of external followers and support operation in a GPS denied environment. The intent of the follower capability is to monitor a simple position report from a designated follower and follow the position in accordance with a defined set of attributes and/or operate in a GPS denied environment. Similar to basic navigation, leader/follower capability will execute in accordance with a set of defined states/state transitions. The dependencies of these states along with the platform mode and other executing mobility state machines will need to be considered. An example is specifying that the robot is to be a leader and then providing and executing a waypoint plan. This capability is applicable to the L/F driving mode. Additional JAUS messages may need to be recommended. There are multiple ways to accomplish this task, which will need to be identified and evaluated.

3.1.5.2 Formation Attributes (IOP Capture: V0 = Initial, V1 = Update)

Description: Formation Attributes capability specifies communication protocol(s) allowing for configuration and report of formation execution attributes such min/max following distance, vehicle mobility characteristics (convoy), leader position/offset, lead vehicle designation, timeout behaviors, broadcast/multicast group, and position update frequency, and configuration and report of precision “footstep” following mode and associated data.

Defines logical communication of formation configuration.

Defines logical communication for configuration of vehicle mobility characteristics.

Defines logical communication for configuration of precision follow mode.

Defines logical communication for command and control.

Defines logical communication of status

Limitations and Constraints: Version 0 addresses basic formation interoperability characteristics. Version 1 addresses multi-vehicle formations and precision follow mode.

Other Guidance: Formation configuration and precision following mode is platform sub-system capability dependant.

3.1.5.3 Execute Formation (IOP Capture: V0 = Initial)

Description: Provides the capability to initiate execution of configured leader/follower formation. Once the formation is executing, there are various events that can happen that may affect the plan execution state (e.g., loss of communications). These conditions need to be considered in the definition of the functionality.

Limitations and Constraints: State machine logic associated with the leader/follower execution will need to be defined by the WIPT. In addition, the relationship of the leader/follower execution state to the driving mode state will also need to be addressed/defined by the WIPT (e.g., selecting the teleop driving mode while a formation is currently executing). This capability is applicable to the L/F driving mode.

Other Guidance: Additional JAUS messages may need to be recommended.

3.1.5.4 Following Status (IOP Capture: V0 = Initial)

Description: Provides the capability to report the status of the leader/follower execution state to an external source. Although this will be defined by the WIPTs, this may include a confirmation that the follower is the correct range.

Limitations and Constraints: This capability will be largely tied to the leader/follower execution state machine model. This capability is applicable to the L/F driving mode.

Other Guidance: Additional JAUS messages may need to be recommended.

3.1.5.5 Suspend/Resume Waypoint Leader/Follower

(IOP Capture: V0 = Initial)

Description: Provides the capability to pause and re-initiate execution of a defined leader/follower mode of operation.

Limitations and Constraints: Similarly to leader/follower execution, the relationship of the leader/follower execution state and the driving mode state will need to be addressed/defined by the WIPT. This capability is applicable to the L/F driving mode.

3.1.6 Advanced Navigation (IOP Capture: V1 = Initial)

Description: Platform/vehicle advanced navigation (i.e., retro traverse, precision position, obstacle detection, obstacle avoidance, etc.) configuration, command, control, and status reporting capability.

3.1.6.1 Retro Traverse (IOP Capture: V1 = Initial)

Description: Retro traverse capability provides a configuration protocol for reestablishment of communications and/or recovery of the remote asset. This configuration defines the conditions under which the robot determines that a retro traverse maneuver is necessary and the procedures for executing retro traverse. The conditions may include situations where communications are lost or broken (high error rate), where no communications have been received for a predetermined (long) period of time, or simply that the vehicle has reached the "turn-around" point in a mission. The procedures for executing retro-traverse include precision of following, speed, warnings and alerts, use of RF communications restrictions, etc.

Defines logical communication of capabilities.

Defines logical communication for configuration Defines logical communication of status.

Defines logical communication of platform position reports.

Defines logical communication of retro-traverse action.

Defines logical communications for…