Attachment 01 Draft SOO - HMIF Network - 05Aug24.docx

CUI

CUI

Statement of Objectives Human Machine Integrated Formation (HMIF) Mission Network Integration

1) Background The Army has designated a U.S. Army’s Rapid Capabilities and Critical Technologies Office (RCCTO) and Army Futures Command (AFC) team to identify and prototype integrated solutions for ground robotics systems in order to develop and manage a Human Machine Integrated Formations (HMIF) architecture that will guide emerging Robotics and Autonomous Systems (RAS) capabilities. The operational prototype of the robotic systems will support analysis, test, and evaluations using Soldier touch points that will leverage Warfighter feedback with the systems to enable lessons learned and drive system improvements as components of the System of Systems (SoS) informing and/or transitioning to their respective Programs of Record (POR).

Figure 1: HMIF System Overview The HMIF system overview in Figure 1 illustrates the SoS relationship between platforms (robots and their control vehicles), their integrated modular mission payloads (MMP) and supporting enablers - network being the primary - to inform, move, and fight the HMIF capability. The RCCTO and AFC plan to deliver an adaptive, robust, and resilient HMIF network to improve connectivity between control vehicle and robot, MMPs and Formation battlefield systems adjacent to the HMIF network.

The HMIF network enables communication of safety-critical and operational mission messages within a common logical/functional network construct. Portions of the HMIF network make use of redundant and/or complementary transport mechanisms to provide an end-to-end set of resilient network pathways between a multiplicity of robotic systems and controllers. Beyond the transport of data, the HMIF network also includes the enabling service infrastructure that supports the development of extensible software defined capabilities at the application layer hosted on Modular Mission Common Compute (M2C2).

The HMIF network splits functionally into a safety critical control segment and a mission segment as shown in Figure 2. The HMIF Safety Critical Control segment of the network supports time sensitive safety assured traffic necessary for closed loop mobility and lethality control of platforms and payloads – and will be implemented by the Government Lead System Integrator (GLSI). The HMIF Mission segment of the network provides for an extensible software defined capability to include hosting non-safety critical payload functionality, interconnection with external mission networks, administrative/maintenance/configuration tool hosting, and reference data storage. Additionally, this network segment includes a M2C2 mission application/service computing environment to host mission services for HMIF internal and the wider external, formation subscribers, as well as an extensible application hosting environment.

Key:

MC = Mission Control M2C2 = An extensible computing element - hosting services and applications in support of the mission network segment RVMS = An independent safety monitor incorporated on HMIF robotic platforms

Figure 2: Overview of the two logical HMIF network segments on a generic platform During the preliminary design phase, both an armor and infantry formation will be addressed. For each of these formations, a similar HMIF Mission network segment solution will be integrated on key platforms of the HMIF operational prototype (i.e. primary infantry robotic platform; primary armor robotic platform; control vehicle for the armor robotic platform).

2) Project Description This effort to build out the capabilities of the HMIF Mission network segment will leverage the development of prior tactical mission computing environments and services conducted by both the RCCTO and U.S. Army Combat Capabilities Development Command (DEVCOM) as well as other organizations across the Department of Defense (DoD) Enterprise. It will take derived operational specifications and evaluation criteria from HMIF architectural requirements to design and develop selected candidate devices as operational prototypes to integrate with existing manned and unmanned Army ground vehicles. This effort will result in an extensible edge compute environment (M2C2), to include a collection of platform specific services hosted within the operating environment of M2C2 (mission services), connected through a high-performance on-platform network segment to other platform embedded capabilities that allows for the rapid implementation and integration of new HMIF capabilities within that operating environment.

3) Government Objective and Approach The overall HMIF network is comprised of a Safety Critical Control network segment (i.e. the bottom portion of Figure 2 shaded in blue) and a HMIF Mission network segment (i.e. the top portion of Figure 2 shaded yellow). The HMIF Mission network segment comprises the design scope of this effort; elements of the Safety Critical Control Network are to be considered out of scope, excepting those detailed in section 3.1 Key Features. Key design details for the Safety Critical Control Network may be provided as GFI as required.

Within the HMIF Mission network segment is an extensible computing resource – M2C2, an operating environment for M2C2 aligned with the FACE/GCIA standard, a collection of platform specific network services within the M2C2 operating environment, and the communications infrastructure required to provide for data sharing between M2C2, the HMIF robotic non safety critical payloads, as well as a co-located mission command system.

The resources available within the HMIF Mission network segment are intended to support both current mission application requirements as well as projected future processing and computing requirements for future software defined capabilities. Figure 2 depicts the integration approach for M2C2 on both the control vehicle and robotic platforms. This diagram further illustrates the subsystems hosted on both a generic control vehicle and a generic robotic platform connected by wireless transport components. Note that at the level displayed, specifics, quantities and design of the platforms, payloads, and wireless transport are intentionally not defined, as these systems may change within the HMIF SoS and are not encompassed in this effort.

The M2C2 is an extensible computing resource (with both hardware and software components). The M2C2 provides a secure and network integrated location to host mission applications and services for HMIF and connection to the formation. Basic functionality includes but is not limited to: a messaging interface between HMIF WMI and MMC, application hosting for payload service software (to include payload service software instantiated as a WMI asset controller), hosting for HMIF diagnostic/maintenance/configuration software, a system data logger service, a security service, a video transcoding and dissemination service for further distribution of any of the payload or platform video streams , and a DDS service implemented to utilize TSN for network transport.

Aligning with Modular Open Systems Approach (MOSA) principles, the M2C2 is logically and functionally separate from robotic control computing and can be extended, upgraded or replaced as technological needs evolve. It will be configured with a Future Airborne Capability Environment (FACE) and/or Ground Combat Systems (GCS) Common Infrastructure Architecture (GCIA) aligned operating environment.

Figure 3: HMIF Network Context Diagram with M2C2 The solutions are envisioned to be embodied as network infrastructure capable of data, power and physical integration with manned and/or robotic vehicles designed to enhance existing capability without limitation to operational envelopes. M2C2 solutions may require 1) CPU, GPU, Switching, and Storage resources, 2) a secure enclosure which interfaces with the host vehicle and provides environmental protection for the M2C2, and 3) a software environment that will allow for the integration of 3rd Party and Government Furnished Software as well as provide a base set of data centered services suitable for managing the HMIF Mission Network as well as distributing data between connected components. HMIF Mission Network solutions will adopt MOSA in their embodiments: M2C2 will implement modularity and extensibility of compute at either the card level within a multi-card enclosure or as individual LRUs connected by the 10G ethernet transport solution.

Respondents will include Government Purpose Data Rights documentation of all mechanical, electrical and data interfaces necessary to integrate the system. Software necessary for the HMIF Mission Network solution will also be modular – capable of being installed and run within the delivered M2C2 compute environment. Additionally, all software will also be delivered with unlimited government purpose rights.

All HMIF Mission Network hardware and software interfaces will comply with the selected RAS-G IOP v7 and Institute for Electrical and Electronic Engineers (IEEE) 802.1 Time Sensitive Networking (TSN) standards to provide for deterministic transport of high priority data and video. Solutions will meet or surpass Government Cyber Security requirements and provide the Cyber Security applications listed in Section 3.1, while conforming to MOSA standards. Solutions will be required to meet all environmental and Shock/Vibration specifications for the host platform. The operating environment should be assumed to provide limited airflow for convective cooling, and the solution will be demonstrated to meet reliability requirements under the full range of environmental conditions indicated in ATPD-2404 and ATPD-2407, Section 5.1. The use of proprietary hardware or software interfaces are prohibited unless unlimited government usage rights are furnished.

3.1 Key Features

This effort will focus primarily on the development of a deployable and sustainable operational prototype that implements the capabilities identified herein. The entire system of systems shall provide the environmental protection necessary for all hardware devices and interconnects to survive the nominal environment of the host platform that the base station is mounted upon in order to meet capability requirements and integrate into existing Army autonomous and/or manned vehicles. The modular components of the systems are as follows:

1) M2C2 Hardware

i. M2C2 Chassis

i. The M2C2 chassis is a modular, ruggedized housing for mission computing hardware.

ii. The chassis will adopt MOSA principles that collectively provide the M2C2 capability.

1. May be instantiated as a card-based system within a single chassis capable of expansion. Or,

2. May be an extensible collection of individually packaged components.

iii. External data and power interfaces will follow RAS-G IOP v7 (draft).

iv. The chassis must be durable and protected to withstand diverse environmental conditions of weather and rough terrain.

ii. M2C2 Processor Hardware

i. The M2C2 solution shall be GCIA compliant.

ii. All hardware components will be compliant with the following TSN standards, at a minimum:

1. IEEE 802.1AS-Rev (Timing and Synchronization)

2. IEEE 802.1Qbv (Traffic scheduling)

3. IEEE 802.1Qcc (Stream reservation)

iii. The processing solution will include both a general-purpose CPU solution as well as a high-performance GPU solution. Note that these may be considered separate modular components.

iii. M2C2 Hardware Interfaces

i. The M2C2 will use connectors that comply with the RAS-G IOP v7 standard.

ii. The M2C2 will support a minimum of one 10G ethernet connection.

2) M2C2 Operating Environment

i. Operating System

i. Standardized Interface Compliance: Operating System adheres to FACE standards by providing a set of standardized software interfaces that promote interoperability and portability across different platforms, facilitating easier integration of both hardware and software components within military systems.

ii. Modular Software Architecture: Operating System utilizes a modular design that allows for the independent deployment, upgrade, or replacement of software components without impacting other parts of the system, aligning with FACE objectives to reduce lifecycle costs and enhance system adaptability.

iii. Enhanced Security Features: Operating System implements robust security protocols that comply with FACE security requirements, ensuring that the operating system can defend against evolving cyber threats while maintaining the integrity and confidentiality of mission-critical data.

iv. Linux operating system compliant with GCIA.

ii. Software Environment

i. Cross-Platform Interoperability: Ensures software compatibility across different ground robotic platforms, adhering to FACE and MOSA standards. This promotes a unified operating environment that facilitates seamless communication and data exchange among diverse military assets in compliance with RAS-G IOP v7.

ii. Scalable and Flexible Architecture: Supports a scalable and flexible software architecture that accommodates easy expansion and customization. This modularity enables the integration of new capabilities and technologies without disrupting existing functionalities, upholding the principles of both FACE and MOSA.

iii. DEVSECOPS: Employs agile software development practices that facilitate continuous integration and deployment cycles, crucial for the rapid iteration and deployment of software updates across diverse platforms, including ground robotic systems. This approach ensures compliance with FACE and MOSA standards while improving responsiveness to operational needs and technological advancements.

iii. Cybersecurity Applications

i. Centralized auditing and accountability

1. Audit collection and review

ii. Centralized access control

1. User and system/component access authorizations

iii. Centralized system monitoring

1. IDS/PS

2. HBSS/AESS

iv. DDS over TSN

i. Facilitates the integration of platform legacy devices which utilize Object Management Group (OMG) Data Distribution Service (DDS) infrastructure onto the TSN-enabled network while ensuring that data delivery objectives are met.

v. VMF/JVM Message Parsing Service

i. A messaging service will be provided to connect and share specific messages between WMI and MMC.

3) M2C2 Services & Applications to Host (Government Furnished):

i. Tactical Assault Kit (TAK) Gateway Services

i. The TAK server is intended to support message passing between WMI and TAK to support a common operating picture

ii. Payloads services

i. Ability to host payload specific software for further processing of payload data before dissemination across the HMIF network.

iii. Data Logging (i.e. ADMAS)

i. A system data logger service will be provided on M2C2.

iv. Training and Reference Data

i. M2C2 will host government provided training application

ii. M2C2 will host operation and maintenance reference manuals for HMIF

4) General Payloads Integration Support

i. All Payloads to be integrated into the HMIF Mission Network will be reviewed for conformance with RAS-G IOP v7.

ii. Software interfaces will be provided within M2C2 for the integration of payloads which are not fully compliant with RAS-G IOP v7.

5) Video Server

i. The vendor will provide a videos transcoding, compression, and distribution service for sharing HMIF video across the formation.

6) Data Storage

i. The M2C2 will provide for sufficient data storage capability to act as a system data logger for a 7-day time period.

7) Optional: Smart Routing Solution

i. (Optional) Review of Wireless Smart Routing solution

i. The vendor will perform a review of the government’s Wireless Smart Routing solution, consisting of both hardware (tactical radios, antennas, cables, router) and software (network analysis and adaptive routing), to identify concerns and provide recommendations.

ii. (Optional) Alternative Wireless Smart Routing solution proposal

i. The vendor will provide an alternative Smart Routing solution with detailed specifications and performance data.

iii. (Optional) Network Management System

i. The vendor will develop a software solution which provides the capability to initialize and dynamically modify configurable parameters of the tactical radios utilized in the government’s Wireless Smart Routing solution.

8) Optional: Wireless Network Multiple Layered Communications Package (MLCP) - Hardware Procurement

i. (Optional) Review of Wireless Network MLCP Hardware

i. The vendor will perform a review of the Government’s Wireless Network MLCP hardware (tactical radios, antennas, cables, routers) to identify any concerns and provide any recommendations. The intent of the MLCP is to provide multiple transport solutions that provide high throughput line of sight, non-line-of-sight, beyond-line-of-sight, spread spectrum and anti-jam/low probability of interception/low probability of detection features over transport layers.

ii. (Optional) Procurement of the Necessary Hardware to fulfill the Government Furnished Information provided for the design of the Wireless Network MLCP

i. The vendor, upon agreed negotiation with the Government on the GFI, will procure the necessary Wireless Network MLCP hardware (tactical radios, antennas, cables, routers) to fulfill quantities for up to 19 ground platforms.

9) HMIF Mission Network Integration

i. The Offeror will be responsible for the integration of the HW being requested in Item #1, the M2C2 software in Item #2, and services and applications in item #3.

ii. The Offeror will work in coordination with the Government to provide an overall HMIF Mission Network solution for the robotic formations based on their M2C2 solution.

3.2 Scope

Develop a HMIF Mission Network Operational Prototype with the projected program phases identified below to achieve the components of capability identified above. The contractors are encouraged to submit alternative phases that will help to streamline and expedite overall program schedule and costs.

3.21 Preliminary Design

Selected respondent(s) will develop an initial design for HMIF Mission Network and will present the design and integration plan as part of a preliminary design review (PDR). The PDR will be accompanied by a Demonstration 1 event in which the initial design is made available for test and review. The preliminary design is anticipated to be approximately Technology Readiness Level (TRL) 6 or higher and will demonstrate the capability for continued efforts to meet all requirements of the program. The PDR will represent the first gating activity for continued efforts.

Tasks in this period may include:

· Kickoff Meeting

· PDR

· Demonstration 1 (TRL 6 on relevant platform(s) in relevant environments)

Deliverables for this period may include:

· Kickoff meeting slides

· PDR design documentation and report

· Demonstration 1 report

3.22 Design Refinement

The selected respondent(s) will refine the HMIF Mission Network design during this period. Further refinement will mature the design for a critical design review (CDR) and accompanying Demonstration 2 event, where the HMIF Mission Network will be fully integrated with the host vehicle platform, at approximately TRL 7. The CDR will represent the second gating activity for continued efforts. It is anticipated that prototypes delivered for this phase will be retained by the US Government for testing and/or other integration activities.

Tasks in this period may include:

· Integration Plan

· CDR

· Demonstration 2 (TRL 7)

Deliverable for this period may include:

· CDR design documentation and report

· Demonstration 2 report

· One or more prototype HMIF Mission Network solutions for government evaluation. Prototypes provided during this phase are preferentially made available to the wider government development team for other integration activities.

3.23 Operational Prototype Production

During the final phase of the program, the offeror(s) will finalize the design, including documentation of all interfaces, and will produce operational prototypes. A set of first-article systems will be demonstrated to be fully operational in “field” conditions. This phase will conclude with delivery of operational prototype systems.

Tasks in this period may include:

· Operational Readiness Review

· Demonstration 3 (TRL 8)

Deliverables for this period may include:

· Design documentation and report

· Interface Control Documents (ICDs)

· Technical Data Package (TDP)

· CAD models (mechanical and electrical)

· SysML models

· Demonstration 3 report

· Operational prototype systems – QTY 30

3.24 Test and Demonstrations

Interim test events are anticipated throughout the development process, with advancement of the system TRL evident at each demonstration.

Notional TRL for demonstrations is as follows:

· Demonstration 1: TRL 6

· Demonstration 2: TRL 7

· Demonstration 3: TRL 8 Demonstrations will be conducted at locations identified by the government and are anticipated to include relevant vehicle platforms and end-users.

3.3 Data Deliverables:

The Contractor may be required to deliver the following data deliverables, at a minimum. Contractor is encouraged to add other deliverables that support the proposed solution during the proposed PoP:

1. Kick-Off Meeting/System Requirements Review

2. Monthly Status Reports (MSRs)

3. Integration Plan

4. Test Plans for Performance Validation, both laboratory and field tests

5. Test Reports for Performance Validation, both laboratory and field tests

6. Preliminary Design Review (PDR)

7. Critical Design Review (CDR)

8. Technical Exchange Meetings & Reports

9. Demonstration and/or Soldier Touch Point (STP) Reports following each event

10. Interface Control Documents (ICD)

11. Technical Data Package (TDP)

12. Software Documentation

13. System Training Package/User Training Manuals, both hardware & software

14. Software Requirements Specification (SRS)

15. Final Closeout Review Meeting & Report

3.4 Environmental and Safety

The components of the solution developed shall be of safe design and shall not interfere with vehicle operations. It is anticipated that individual vehicle PMs will approve integration into their relevant vehicles. It is anticipated that ATEC will conduct a system safety review.

3.9 GFP/GFE/GFI (Government Furnished Property, Government Furnished Equipment, Government Furnished Information) GFE may include access to Army remotely controlled autonomous and/or manned vehicles for testing during system development and at demonstration events. Access to C5ISR HMIF Network SIL and GVSC SoS SIL.

GFI may include design details (diagrams, component technical data, interfaces) for the Safety Critical Command Network

3.10 Period of Performance (PoP) and Exit TRL

The PoP of the HMIF Network solution is anticipated to be approximately 27 months from contract award. The program anticipates an additional 2 years of support and spares as the SoS undergoes operational testing. Specifics of schedule may vary with offeror proposal.

Expected TRL at the completion of the HMIF Network solution will be TRL 8 or higher.

4.0 Referenced Documents

Please see the below table for specifications, standards, and handbooks referenced for the generation of the HMIF architecture.

DoD Zero Trust Strategy, DoD Zero Trust Capability Execution Roadmap (COA 1), DoD Zero Trust Overlays

CUI

CUI

image1.png image2.svg Command Vehicle Modular Mission Common Compute Switch Robot SRR BLOS Modular Mission Common Compute Switch UAS Dismount Controller Other Radios Gateway MMC ITN BLOS HMI WAN Multi - Channel HMI Platform Network Specialty Link HMI WAN Single Channel Bridge Legacy Radio Radio Radios image3.png image4.svg HMIF Wireless Transport, MC Wireless Transport M2C2 General Payloads SW Interface to other MC Networks Safety Critical Control Network Mission Network Networked Control (Safety- Critical) Capabilities RVMS Lethality Maneuver Wired - to - wireless routing Networked Mission Capabilities image5.png