SOO HMIF RAS Software_Revised 7 May.pdf

HUMAN MACHINE INTEGRATED FORMATIONS (HMIF)

ROBOTIC AUTONOMOUS SYSTEM (RAS) SOFTWARE

STATEMENT OF OBJECTIVE

25 APR 2025

Version 1

1 HMIF Program Objective The Human-Machine Integrated Formation (HMIF) operational prototype aims to enhance lethality and survivability of maneuver formations by integrating best-in-class air and ground robotic and autonomous systems (RAS) software. The initial development phase, Increment 1 (Inc 1), will deliver two HMIF operational prototype formation sets (Armor and Infantry) for learning, iterative refinement and operational deployment of two U.S. Forces Command (FORSCOM) units.

1.1 Purpose

The purpose of activities described in this SOO are to design, develop, integrate, and deploy HMIF RAS Software for the HMIF operational prototype that enables seamless transition between the operation of air and ground robotic systems and interaction with formation mission command to enhance lethality and survivability of Army formations.

1.2 Scope

The Contractor shall deliver a modular, integrated software solution for HMIF Inc 1, consisting of the following core components:

• Command and Control (C2) Control Software: Develop software to command-and-control air and ground robotic systems, enabling teleoperation, autonomy handoff, and multi-platform management within a unified operator interface.

• Ground Autonomy Software: Deliver platform-hosted autonomy capabilities for assisted teleoperation, waypoint navigation, formation following, and obstacle avoidance, with scalable support for future autonomy levels.

• Assured Control and Safety Software: Integrate safety-critical software components (e.g., the Robotic Vehicle Management System (RVMS)) that provide safe-state monitoring, command validation, and system integrity checks for robotic platforms.

• Mission Command Interconnect Software: Provide interface software that enables interoperability with Army mission command systems, including Tactical Assault Kit (TAK), Mounted Mission Command, and Next Generation C2 (NGC2), using standards such as Cursor-on-Target (CoT), Variable Message Format (VMF), and MIL-STD-2525.

• Lead Software Integrator (LSWI): Act as the lead integrator responsible for developing the prototype specific software which integrates all required modules—government-furnished and vendor-developed—into a cohesive, mission-ready prototype HMIF RAS SW system.

The Government expects the HMIF RAS Software Prototype Developer to also serve as the Lead Prototype Software Integrator, and to organize and lead a team of best-in-class providers to deliver and integrate these components in alignment with the prototype HMIF RAS SW and the HMIF system-of-systems architecture.

*Edge Compute: The Government has already acquired Modular Mission Common Compute (M2C2) hardware through a separate contract with T2S; therefore, vendors shall not propose edge computing hardware as part of their solution.

1.2.1 HMIF Architecture

The prototype HMIF RAS SW system(s) will support the complete overall HMIF Architecture. HMIF is a system of systems (SoS) comprised of platforms, enablers, and payloads integrated in accordance with a common architecture and through a shared network that provides rapid capability extension, reuse, and reconfiguration.

• Platforms are vehicles—manned or unmanned—that serve as the foundation of the HMIF SoS and host both tightly integrated enablers and modular payloads.

Platforms may be ground or air based. In general, unmanned RAS will be operated through common controllers located either on manned platforms common to the formation HMIF is a part of, or as wearable capability on the dismounted warfighter.

• Enablers are physical and/or software sub-systems hosted on platforms that provide functions to a multiplicity of platform and payload components. Enablers represent shared services of which systems within the SoS may make use. Enablers may be local to a particular platform or may be delivered through the network connecting across multiple platforms

• Payloads are modular systems within the SoS that are hosted on platforms. HMIF adopts a concept of Modular Mission Payloads (MMPs) which are fully severable from their host platforms. MMPs interface with platforms through standardized physical and software interfaces. MMPs may be added to, and removed from, a platform to configure that platform for a specific capability set.

1.3 HMIF RAS Software Modular Components

The HMIF RAS software architecture (Figure 1) adopts a modular approach to all software components. The contractor shall develop the HMIF Ras software prototype components of control, ground, mobility, autonomy and assured control and safety; and integrate with the existing components of smart routing and other software services and applications. The RAS Software prototype consists of the following components:

• Control Software. HMIF Control Software is the core integration point for all RAS software functions. Control software connects to RAS components linked through wired and wireless networks and provides for the configuration, monitoring, and operation of the HMIF SoS. Control software resides on either the mounted or dismounted common controller within the HMIF network. Any platform or payload reachable through the HMIF network is controllable through any instance of the Control Software.

• Smart Routing Software. A secure (Controlled Unclassified Information (CUI)), resilient, and standards-compliant communication software and protocols to support continuous, low-latency data exchanges between controllers, RAS platforms and payloads, and mission command nodes.

• Ground Mobility Autonomy Software. A modular component hosted locally on key ground platforms withing the HMIF SoS that provides control inputs directly to the platform in supplement or replacement to direct operator input to allow for graduated levels of operator platform engagement while performing various mobility behaviors.

• Assured Control and Safety Software. An independent, safety certified robot vehicle management system software module that sits locally on a ground platform between the operator and/or autonomy software and the platform drive by wire capability. Software combines operator input signals with teleoperation and autonomy controller signals to provide assured control signals to vehicle mobility and lethality subsystems.

• Other Software Applications and Services. This represents the compute environment on HMIF robotic and control platforms used to host modular applications and services like data storage, logging, and shared tools across the system-of-systems. The M2C2 solution, provided by the T2S Solutions vendor, supplies the hardware and operating environment and should be treated as an open resource within the HMIF RAS software architecture. (See Figure 1)

Figure 1: HMIF RAS Software Context Diagram

1.4 Lead Software Integrator (LSWI)

The government is seeking a LSWI for the HMIF program, responsible for the development of prototype software components for control, autonomy and assured control and safety, and integration with government existing investments in HMIF software and hardware. Government recognizes that individual vendors have their areas of expertise and existing investment and that no one vendor represents the best in class across all the modular software components for HMIF. It is therefore expected that the Lead Software HMIF RAS prototype developer will organize with Industry to build a team of leading RAS software developers and integrators under a LSWI to meet the objectives of HMIF RAS Software and integrate with existing HMIF SoS architecture and solutions. Further, because of the central integration importance of the control software, the government intends that the LSWI shall also be the control software developer.

1.5 HMIF RAS Software Integration Standards and Interfaces

The integration standards and interfaces described below provide the architectural framework with which the HMIF RAS Software prototype must comply.

1.5.1 Uncrewed Vehicle Control (UVC) Architecture.

UVC is the US Army program of record providing the application framework for robotic command and control software development and its architecture supports safety critical software development as well as integration into mission command to conduct maneuver operations with RAS.

1.5.2 Interoperability Profile (IOP)

The HMIF RAS SW prototype must utilize a UVC IOPv7 compliant interface in which HMIF payloads have the ability to integrate to appropriate Unit of Portability (UoP) drivers for integration to a UVC defined interface.

1.5.3 Message Standards

The HMIF RAS SW prototype should comply with the following messaging standards for grounds assets - RAS-G IOP v7 (JAUS), and for air assets - RAS-A IOPv1.2. If contractor cannot comply with IOP then the contractor must develop their own interface adapter through which IOP compliance may be attained. Payload vendors have been directed to provide UoP compatible interface to RAS-A (all aircraft) and RAS-G (all ground systems) messaging standards. The contractor must implement the client-side interface to communicate with the payloads.

2 HMIF Software Component Performance Objectives In order to realize effective control of HMIF RAS platforms, the government seeks an integrated software solution which includes the following components with their associated performance objectives.

2.1 Control Software

Support modular reusability, compatibility with legacy systems, and future scalability.

Enable seamless control mode transitions, support unmanned aerial systems (UAS)/payload operations and allow RAS control handoffs across users. Must support platforms/payloads listed in Appendix A.

2.1.1 User Interface (UI) and Tools

The Control Software shall include a modular and intuitive UI with customizable overlays, prioritization tools (e.g., bandwidth indicators), and support for multiple simultaneous video streams. The user interface must conform to MIL-STD-1472H as design criteria for human factors. The prototype developer must propose UI wireframes early in the development cycle and iterate based on Soldier feedback. The HMIF RAS SW prototype Control Software must include the ability to manage multiple UAS and ground platforms simultaneously with minimal operator load. The control software will support the following UI tools, including but not limited to:

• Network ModRF Quality of Service Monitoring and Management

• Robot SA and video feed prioritization

• Autonomy Sensor Calibration Tools

• Weapon Calibration Tools

2.1.2 Mounted and Dismounted Controller

The HMI Formation will be controlled through a dismounted common controller (DCC) and mounted common control (MCC) solutions. The DCC will host control software on Android OS Android 14 (DCC). It is desired that the mounted common controller (MCC) software operates within an Ubuntu Pro 22.04 (MCC). The government desires a single managed software solution that can be compiled for either of the operating systems (OS) environments as appropriate.

2.1.3 Command and Control Functions

The HMIF RAS Control Software shall support the following command and control functions, including but not limited to:

• Assured Teleoperation. Ability to remotely operate the robot and associated payloads through the RVMS.

• Lethality control. Ability to remotely operate a weapon system that is mounted on the robotic platform.

• Common Operating Picture. Ability to communicate across the formation through battle space objects using MIL-STD-2525-D symbology, text reports, and whiteboard drawing abilities to be able to quickly draw on the HMIF common operating picture map.

• Mission Planning. Ability to populate—whether in real time or from pre-orchestrated mission plans—and to communicate across the formation on coordinated movements.

• Navigation. Ability to have a mapping platform that offers satellite imagery, topography maps, tactical maps and other mapping artifacts used for route planning and to populate blue force locations and battle space objects. This function will also have the ability to display the Military Grid Refence System and geographic coordinate system at a minimum.

• UAS Control. Ability to operate the UAS referenced in Appendix A. The expectation is that all available controls are presented in a manner matching each system’s native control software.

• Payloads. Ability to operate and/or control each payload as detailed through IOPv7 unless otherwise specified.

• Power. Ability to control platform power ON/OFF from the UI through the RVMS to the platforms.

2.1.4 Control Autonomy Functions

The control software shall support the following autonomy functions, including but not limited to:

• Route Planning. Create a route, edit the route, save the route, share the route to other controllers, and pause/execute the route. Ability to view the costmap around the vehicle.

• Formation Following. Ability to move a RAS in a defined formation without continuous supervision or operator input. A formation lead may be a control vehicle, another robot or a dismounted soldier.

• Assisted Teleoperation. Ability to remotely operate a RAS, with autonomy capabilities inserted by the RAS. This will aid the operator by using the various sensors on the platform to detect potential interaction with obstacles in the environment and either alert the operator or assist in control of the RAS to prevent collision. In this mode, the operator should have ultimate control of the robotic platform and be able to override any obstacle avoidance behaviors.

• Warnings and Alerts. Provide warning, caution and alert information for the RAS platform(s)

• Robot Situational Awareness. Provide multiple video streams for the RAS platform(s) and associated payloads to the user

• Health and Status. Provide health and status information to the user regarding the platforms and subsystems. May also include calibration of LIDAR or other sensors.

2.1.5 RAS Network Interface

The HMIF RAS control software module shall implement secure, resilient, and standards-compliant communication protocols to support continuous, low-latency data exchanges (e.g. UDP/TCP) between control nodes (e.g., DCC, MCC), RAS platforms, and mission command systems. The HMIF C2 software shall:

• Enable bidirectional C&T flows

• Support multicast/unicast

• Prioritize traffic (QoS tagging)

• Adapt to degraded conditions (mesh, LTE, SATCOM)

• Align with RMF and FIPS 140-3

• Enable remote diagnostics and log collection

2.2 Mission Command Software

The HMIF RAS SW prototype shall integrate ground mobility software as described in this section.

2.2.1 Mission Command Interfaces

The HMIF RAS software control module shall integrate with Mounted Mission Command in the mounted instantiation, TAK in the dismounted instantiation, and align with Next Generation C2 (NGC2). Implement and interoperate with Variable Message Format (VMF) MIL-STD-6017A, Cursor-on-Target (CoT) MIL-STD-6090, Symbology MIL-STD- 2525 and NGC2 APEX Application Programming Interface (API) for exchanges with current or future Force formations. It shall visualize Battle Space Objects (BSO), exchange and display CoT/PLI messages overlay and native M2C2 command application data following MIL-STD-2525-D symbology standard.

2.3 Ground Autonomous Mobility Software

The HMIF RAS SW prototype shall integrate ground mobility software as described in this section.

2.3.1 Mobility Autonomy Objectives

The objectives of the autonomy system for the HMIF are to:

1. Allow remote operation of the ground robotic platform with and without autonomy Level B-E (see Figure 2) assistance in avoiding obstacles (both objects and terrain)

2. Reduce the cognitive load on the operator through autonomy levels C/D functions with the ability to grow to autonomy Level E. Reducing the cognitive load of the operator will allow the operator to multi-task, performing other necessary functions including controlling other on-platform payloads or allow one operator to control multiple robotic platforms.

2.3.2 Mobility Autonomy Levels

Figure 2: HMIF Levels of Autonomy

2.3.3 Ground Autonomous Mobility Functions

Below is a summary of the typical automated mobility functions that would meet the objectives of the HMIF program. While this defines typical functions, it is not intended to limit industry solutions and functions.

• Unassisted Teleoperation (Level A): Provides the operator to control and drive the robotic platform remotely via an assured video solution. This mode will not provide any assist or obstacles avoidance features and will depend on the operator to assess and take action on all obstacles (objects, humans, and terrain).

• Assisted Teleoperation (Level B): Assisted teleoperation is an extended form of teleoperation where the robotic platform begins to insert autonomy capabilities. The goal is to aid the operator teleoperating the platform by using the various sensors on the platform to detect potential obstacles in the environment, including object, humans, and terrain (drop/fall), and either inform the operator or assist in control and prevent the collision. In this type of operation, the operator should have ultimate control of the robotic platform and be able to override any obstacle avoidance.

• Defined Destination (Level C,D,E): The system shall be capable of navigating to an operator defined location. This location will be communicated via GPS coordinates or one of many other formats. The location is just a definition of a point in space that the autonomy software can interpret and understand relative to the vehicle’s own position in space. The supported formats and accuracy of each type of waypoint will vary greatly depending on the Position Navigation and Timing (PNT) system that is being used on the vehicle. The operator may define other key parameters for the mission including: max speed, loss communications action, destination and path deviation thresholds.

• Formation Following (Level C,D,E): This feature provides the capability to move the robotic platform in a define formation without continuous supervision or control from the operator. This could be used for administrative move, movement to FLOT or in a “follow me” movement. The formation lead could be the control vehicle, another robotic platform or a dismounted solider. The system should be capable of moving in user defined formations (offset, position) and be adaptable to the lead vehicle’s/soldier’s movements or changes in the environment (obstacles).

In all levels of autonomy, the operator should have the ability to override the system and take over control, moving to a Teleop mode. This transition needs to be accomplished without interruption of the vehicle’s operation or require stop or reset of the system.

2.3.4 Autonomy Software Development Priorities:

The HMIF RAS Autonomy Software development priorities are:

1. Teleoperation - Assisted

2. Formation Following – “follow me” feature for administrative moves

3. Uninterrupted transition from an autonomous mode (formation following or defined destination) to teleop when the operator takes control

4. Defined destination - route definition can be operator controlled using intermediate waypoints

5. Operation in defined destination and formation following at a Level C and D Autonomy level. The level of autonomy, or operator engagement required, will depend on the accepted level of risk for the given mission

6. Advanced formation following control with formation control and dynamic formation abort procedures

7. Defined destination with navigation using a priori maps or self-generated maps requiring less operator path planning with waypoints

8. Mission intent autonomy, enabling one operator to control multiple robotic platforms

2.4 Assured Control and Safety Software

The prototype must be developed to provide the following functions and integrate with existing government hardware and software. The HMIF architecture segments safety critical control functionality from general purpose control functionality. The safety critical functionality is allocated to two general components: a small embedded safety processor that is hosted within the controller and, when in operation, is paired to a companion unit on the other end of the network link on a platform, and a more capable system – the RVMS that is located on the robotic platform and sits between the drive-by-wire system on the platform and automated or manual control functionality.

2.4.1 Robot Vehicle Management System (RVMS):

RVMS is local hardware and software to the robotic platform designed to provide the equivalent of Automotive Safety Integrity Level (ASIL) Level D safety integrity (developed in accordance with Level Of Rigor (LOR) 1, etc.). RVMS capabilities include:

• Monitoring the local state of the platform

• Monitoring all commands (from whatever source) that may affect the state of the platform

• Error checking between the commanded and delivered state

• Health checking of components

• Transition into and out of known safe state

The government requires unlimited rights to RVMS and has made an initial investment in the creation of this capability that would be provided to the LSWI as a starting point for further enhancement.

2.4.2 Assured Video

The HMIF RAS SW prototype shall utilize a low latency method to select and display video in their control software.

2.5 Other Software Applications and Services

The government has previously selected T2S Solutions to provide development and integration within the M2C2 environment various mission applications. For this component of the SOO, the HMIF RAS SW prototype developer is to work with the government’s previously selected performer.

3 Performance Requirements The contractor shall fulfill the following performance requirements when developing HMIF RAS Software.

3.1 Software Development

The Contractor shall perform software development using Agile methodologies and deliver all work products within the Government-furnished GDev DevSecOps environment. All development activities shall comply with GDev policies, workflows, and configuration management procedures.

3.2 HMIF Inc 1 User Story

The HMIF RAS LSWI shall consider the example HMIF Inc 1 User Story for the RAS Infantry Platoon reconnaissance and security operations, provided in Appendix C, to support software development performance.

3.3 Performance Metrics

Software must provide full operational control of designated platforms and payloads, including lethality, autonomy, and safety features.

3.4 Government Lead System Integrator Collaboration

The contractor shall support the Government Lead Systems Integrator (GLSI) during the integration, validation, and verification of the HMIF RAS Software. The contractor shall release software in accordance with the capabilities, functions, and release cadence as described in Appendix B.

4 Security The HMIF Operational Prototype project and associated HMIF RAS software is at the CUI level of security.

The contractor shall manage RMF and tasks to ATO compliance for HMIF RAS software. The software shall be fully operational and tested on a Cyber Hardened Operating System (OS); Android 14 OS for dismounted common controller (DCC) and Ubuntu Pro 22.04 – Ver 2, Rel 3 Linux OS for the mounted common controller (MCC) and platform compute resources. With each software release the Contractor must run and provide Fortify Scans/results on all software being delivered with all CAT 1s and CAT 2s remediated. CAT 3s shall be addressed in a POAM and Risk Mitigation Plan.

5 Project Timeline and Milestones The HMIF Inc 1 project timeline shown in Figure 3 provides an overview of the SoS integration and testing schedule with supporting software development release candidate drops and milestones. The current prioritized list and description of the software development drops is in Appendix B. The contractor shall consider the prioritization and timeline for software development and integration.

Figure 3:HMIF Project Timeline

6 Government Purpose Rights (GPR) The Contractor shall provide Government Purpose Rights for all technical data and software (APIs, SDKs, models, documentation, and training materials) developed under this effort. Contractor will provide assertion rights for any previously developed software components. These rights allow the Government to use, modify, reproduce, release, perform, display, or disclose the technical data or software within the Government without restriction and to authorize its use by contractors supporting Government activities. The contractor shall ensure that all deliverables are marked appropriately to reflect GPR and provide full access and use for sustainment, testing, integration and future development activities.

7 Training The contractor shall provide training for operators and/or engineers providing hands on experience with the developed technologies to ensure that the end-users can effectively operate and maintain the capability. Key components of the training shall include overview of the software’s purpose, capability and intended use along with an explanation of how the software integrates with existing systems and/or equipment. The contractor shall perform a live demonstration of the software in action to show its features and functionality. The contractor shall develop user manuals, quick reference sheet, explanation of how to access support resources and/or updates as well as guidance on identifying and reporting issues to the contractor and/or support team.

8 Sustainment The contractor shall develop a sustainable and adaptable proptotype. The contractor shall also provide control software sustainment services during the prototype project, including delivery of source code, documentation, and configuration files to designated government repositories. Required documentation includes UI wireframes, Interface Control Document (ICD), Software Architecture Document (SAD), test plans/results, and an install/configuration guide. The contractor must also provide a known bug list and a comprehensive training plan outlining software usage and support. All deliverables shall align with the Government’s Software Integration Schedule and enable independent installation, testing, and maintenance.

9 Place of Performance Contractor location (primary), with support required at:

• Detroit Arsenal, MI

• Aberdeen Proving Ground, MD

10 Appendices A HMIF Inc 1 Platform, Payloads and Enablers B Software Integration Schedule C HMIF Inc1 User Stories – PowerPoint Attachment.

Appendix A HMIF INC 1 Platform, Payloads and Enablers

• SB600: AeroVironment, SB600 Block 1 Inert

• SRR: Red Cat Holdings, Teal 2

• MRR: Anduril Industries, Ghost X

• TeUAS: DPI UAV Systems, Lantern

• CROWS: Kongsberg Defense and Aerospace

• Mast: Fireco, MecMast

• EO/IR Camera Gimbal M364c: Teledyne FLIR

• Mounted Mission Common Compute (M2C2): T2S Solutions, Systel Kite Strike II

• Dismounted Common Controller (DCC): AeroVironment

• CsUAS-EW: BlueHalo, Titan 4 and Titan-SV MPV3

• SOM: L3 Harris, Smoke Obscuration Module

• XM Mutt: General Dynamics Land Systems

• M3B1: Textron Defense

• Control Vehicle Armor – AMPV: Ground Vehicle Systems Center

• Control Vehicle Infantry – ISV: Ground Vehicle Systems Center

• RVMS: NAI SIU34

• Autonomy Processor w/GPU: OnTime Networks DS CM-6221F11-COMe-MIL-

SS09AXBR0-95-96

• LiDARS: Ouster OS0-REV7-128 and OS1-REV7-128

• Stereo Cameras: Carnegie Robotics S30

• PNT: Forterra RR-N-140V1

Appendix B HMIF RAS Software Integration Schedule

Functionality is inclusive of but may not be limited to the functions described below.

Functionality is binned according to the final drop it is needed by and prioritized to accomplish the minim viable product. All functionality is desired prior to shakeout testing. The 1.0 MVP and 1.5 Delta drops are intentionally left without functions allocated to them, as new feature development should be concluded prior to entering

ATEC.

Release 2 (02 Oct 2025)

• Perform RAS-G IOP Discovery

• Robotic Control Teleoperation

• Robotic Lost Communications Behaviors (stop/continue mission / rally point)

• Assured Teleoperation

• System Enable/Disable

• Assured Video

• Assured Lethality

• Fire Weapon on Threat

• Operational Mode Switching

• Payload Safe State

• Control M3

• Control XM

• Operational Mobility Video

Code Lock (08 Jan 2026)

• Robotic 360 Video Display to User

• Video Management

• Weapon Video Control

• Select Weapon/ Ammo

• Shared Digital Markup of Battlespace

• Slew Weapon to Threat (Slew to Cue)

• Weapon Calibration Tools

• Handoff Robotic Asset

• Handoff Payload Control

• Control CsUAS

• Control SOM

• Control MAST

• Mast identify Key information within direct fire range

• Mast- Video Controls (zoom, overlays ect)

• Mast- Scan Environment Using Sensor

• Control TeUAS

• TeUAS - identify Key information within direct fire range

• TeUAS - Video Controls (zoom, overlays ect)

• Control SRR

• SRR – Video Controls (zoom, overlays ect)

0.9 Release (10 April 2026)

• Control MRR

• MRR – Video Controls (zoom, overlays ect)

• Control SB600

• Receive and Display PLT Element Locations

• Identify Locations

• Maps

• Acquire Threat and Verify Location

• Promote Threat to BSO

• Select/Adjust and Transmit Navigation Waypoints

• Create/Update BSO on COP

• Display Mission Graphics

• Transmit Location

• Show Relative Positions of Elements on Map

• Allow Operators to Populate Data Through Echelon (MCC/TAK/NGC2)

• Robotic Control Waypoint Navigation (off road)

• Robotic Control On-Road Navigation

• Autonomously Sense Environment (Lidar)

• Convoy

• Guarded Teleoperation

• Input and Send Digital Reports

• Power Up/Down Sequences

• Network Configuration Tools

• Autonomy Sensor Calibration Tools

1.0 MVP (01 Oct 2027)

1.5 Delta (04 March 2027)

Appendix C HMIF Inc 1 User Story

See Attachment on SAM.GOV

Appendix D M2C2 Hardware Specification

Appendix E GPU and SWAP Specifications

2.5 Other Software Applications and Services