HMIF RAS SW Prototype RFSB QA Matrix.pdf

Question

Number

Question Response

You list Tomahawk Robotics as the Common Controller, but it is a custom built piece of hardware. Is there opportunity for a vendor to propose a different common controller, one which is a software stack on commodity

NIAP-approved Android phones and tablets?

HMIF is not seeking alternative common control solutions at this time. The existing hardware has been procured to maintain consistency across platforms for integration and evaluation purposes.

Are vendors allowed to team with multiple vendors non exclusively? And be on multiple pitch presentation teams?

Yes. Vendors may team with multiple partners and may participate in multiple solution briefs and pitch teams, as long as each submission meets the evaluation requirements independently.

We had heard from Army contacts that there might be an

Industry Day (or equivalent) scheduled in support of subject opportunity, but did not see any notification of such an event on the sam.gov website. Please confirm whether an Industry Day will be offered.

The referenced event is an architectural review with industry collaboration. The Government intends to share system architectural information with interested Vendors to collect feedback for market research. The Government intends to share relevant information from the event with

Vendors interested in the RFSB, potentially including answers to relevant questions received from Industry

Partners, or potential changes or clarifications to the requirement which arise during the event (if any).

Will solution briefs proposing to a subset of the scope items be acceptable?

The Government is interested in awarding to a team, led by a Lead Software Integrator (LSWI), capable of delivering a cohesive prototype that addresses all five software categories—or fewer, if a vendor’s solution only supports certain areas. All properly submitted solution briefs will be evaluated based on: (1) technical merit, feasibility, and relevance to the SOO; (2) the company’s approach or technology and its development schedule; and (3) the realism and affordability of the proposed ROM. Vendors with specialized capabilities are encouraged to team with others to present an integrated solution aligned with these evaluation criteria.

I was informed there is an industry day in Detroit next week to discuss the new RFSB for HMIF. Is it possible to make an exception to add me to the list of attendees?

The referenced event is an architectural review with industry collaboration. The Government intends to share system architectural information with interested Vendors to collect feedback for market research. The Government intends to share relevant information from the event with

Vendors interested in the RFSB, potentially including answers to relevant questions received from Industry

Partners, or potential changes or clarifications to the requirement which arise during the event (if any).

In section 1.2 (Scope) on page 2 of the Statement of

Objectives, under the Ground Autonomy Software bullet, there is mention of obstacle avoidance. Our question is does the Contractor need to also perform obstacle detection or can we assume that is handled elsewhere?

Yes, obstacle detection is inherently required to perform obstacle avoidance. While not explicitly stated in the SOO, detection is implied. Vendors may choose to explicitly address both detection and avoidance in their technical approach.

Technical data rights assertions may take more than one page, depending on the offeror and team. Will the

Government consider removing the page limit for this element of the response?

No. All required content, including technical data rights assertions, must be addressed within the 6-page limit.

Vendors may summarize key points and note that detailed data rights information can be provided upon request during follow-on phases.

Will the Government allow any font and font size in graphics provided they are legible?

Minimum 9 point font for graphics.

Human-Machine Integrated Formation (HMIF) Robotic Autonomous System (RAS) Software Request for Solutions Brief (RFSB)

Q&A

10 Is there an NTE for this effort? If so, please specify.

The Government encourages Respondents to provide the most competitive and realistic ROM they can provide for the solution they present, while gearing their solution to the

SOO. The Government is using this RFSB at least partially for market research and does not want to artificially direct

Vendors to a particular NTE.

Are vendors required to use WMI or are other UI/UXs acceptable?

No specific UI/UX framework is required. Vendors may propose any interface design that aligns with the SOO and supports operational effectiveness.

Are there specific terrain types or environmental conditions that autonomy must handle?

Yes. Autonomy solutions must be designed to operate in a wide range of terrain and environmental conditions, as

Army formations may be deployed globally under diverse and challenging scenarios.

13 Is ModRF an available GOTS option?

ModRF is an available GOTS option for use with the

Network.

Are there specific Army reference architectures beyond

GCIA?

Yes. Vendors should reference and align with UVC, IOP, and the Army Autonomy Architecture (Level 1 diagrams), in addition to GCIA where applicable.

Will the Government provide criteria for safety-critical designation?

Safety-critical designations should align with established

Department of Defense and Army standards, including DO-

178c, DO-254, MIL-STD-882E (System Safety) and AR

385-10 (The Army Safety Program). These references define safety-critical elements and provide criteria for hazard analysis, risk acceptance, and mitigation measures.

Vendors should apply these standards when identifying and addressing safety-critical functions—particularly for autonomous operations that require assured control without a dedicated safety observer or physical E-stop.

Will the Government specify required compliance documentation pertaining to GCIA, UVC, and other government reference architectures?

Yes. For GCIA, a compliance guide is available. HMIF INC

1 vendors will work with the Government Lead System

Integrator and participate in integration and evaluation activities at the Systems Integration Lab (SIL) at GVSC.

Does the Government have preferred containerization technology?

No. The Government does not have a preferred containerization technology. Vendors may propose technologies aligned with their DevSecOps pipeline and system requirements.

Will the Government specify expected virtual environment capabilities?

The Government does not currently prescribe specific virtual environment capabilities. If referring to development, test, or simulation environments, vendors should propose solutions that align with their software architecture and

DevSecOps practices. Clarification on intended use (e.g., development vs. simulation) is welcome.

Does the Government have a target percentage for code reuse?

No target percentage is specified at this time. Government

Furnished Equipment (GFE) software modules will be made available for use where applicable, and reuse is encouraged when it supports performance, integration, and schedule efficiency.

20 What is the required timeline to respond to cyber threats?

The timeline for responding to cyber incidents will follow

DoD and Army cybersecurity guidance, including AR 25-2 and CJCSM 6510.01. Incidents are categorized by severity

(e.g., CAT 1–5), with associated response times ranging from 15 minutes to 72 hours depending on criticality.

Will the Government provide a list of policies, workflows, and procedures for GDEV?

The Government will not provide detailed vendor workflows. However, contractors are expected to align with

HMIF software development, integration, and delivery standards, which will be coordinated through the

Government Lead Systems Integrator.

Does the Government have a preferred training delivery method?

If selected for award, Vendors are expected to coordinate with the HMIF Training Delivery Group to ensure training materials and delivery methods align with Army instructional standards, including digital products, artifacts, and lesson planning tools.

Are there any specific systems where the Government requires focused integration training?

No specific systems have been designated for focused integration training. Vendors should plan to address integration training comprehensively across all applicable platforms, payload, enablers, and components.

Does the Government have preferences or requirements for the live demonstration environment?

Release candidates will be tested live at the Systems

Integration Lab (SIL) and on relevant platforms. The

Government expects vendor support throughout these events, including during field-based testing and integration.

25 Does the Government have preferred support channels?

Could you please clarify what is meant by “preferred support channels”?

Does the Government have a preferred or required issue tracking system?

Yes. Vendors are expected to interface with the

Government’s issue tracking system, currently managed in

JIRA within the GDEV environment.

Is there a specific sustainability framework that the

Government prefers or requires?

No response to provide at this time

There seems to be a gap between the autonomous behaviors listed for ground autonomy in the software scope document (SOO HMIF RAS Software_25 April, p. 2, para

1.2) versus the Operational Vehicle Function-to-Task trace behaviors listed as “required” in the Mission Use-

Cases document (Appendix C. HMIF Inc1 User Stories, p.

1-20). Will there be an edit in scope to include more than mere autonomous mobility behaviors beyond assisted teleoperation, waypoint navigation, and formation following, i .e. behaviors that deliver the complex behaviors re: reconnaissance mission tasks like react-to-contact with an obstacle, detect and report enemy contact, transition to traveling/traveling overwatch?

The behaviors listed in the SOO (Section 1.2) represent the minimum required capabilities for the ground autonomy software in HMIF Increment 1. These were scoped to ensure a baseline level of autonomy maturity (TRL 7+) and near-term integration feasibility. However, this does not preclude vendors from proposing additional or more complex autonomous behaviors aligned with operational mission use cases, such as reconnaissance tasks (e.g., react-to-contact, enemy detection/reporting, overwatch transitions).

While the SOO does not currently specify all behaviors from Appendix C of the Mission Use Cases document, vendors are encouraged to demonstrate the technical maturity and operational value of any enhanced autonomy behaviors they propose. The Government remains open to expanding the prototype scope if such capabilities offer clear benefit and align with integration timelines and system maturity expectations.

Is the Government locked to their existing solutions or open to a cost-effective solution that sets the stage for scale?

The Government is open to innovative and cost-effective software solutions within the defined scope. However, we are not seeking changes to the existing hardware or

Government Furnished Equipment (GFE) list. Proposed solutions should be compatible with the current architecture and integration framework defined in the SOO and associated reference documents.

Will the specifications be provided on the M2C2 hardware that is being required?

Yes. The Government will provide the necessary M2C2 hardware specifications to support software integration and compatibility planning. Please see Appendix D

Where does the Control Software fall within the HMIF architecture? The Control Software is not shown in the SW architecture diagram (Figure 1 of SOO).

The Control Software resides within the Robotic Controller box, which is represented on the left-hand side of the UVC box in the software architecture diagram.

Could you help us understand the rationale for requiring

Ground Mobility Autonomy Software providers to use specific compute hardware, given that the detailed hardware specifications haven’t been shared yet?

The required compute hardware has already been procured under a separate Government effort. Hardware specifications will be shared to support software integration.

33 Why is LSWI required to be the Control Software supplier?

The Government envisions the LSWI as the central integration lead responsible for aligning all HMIF RAS software components into a cohesive, mission-ready system. Due to the foundational role of the Control

Software in coordinating autonomy, safety, and platform behaviors, the Government expects that the LSWI will also lead development of this component to ensure system coherence, integration integrity, and clear accountability.

Additionally, the Control Software is critical for interfacing with mission command systems to enable a seamless common operating picture and effective command and control of HMIF RAS capabilities. That said, the LSWI is expected to build and manage a team of best-in-class software providers for the other modular components (e.g., autonomy, assured control/safety), recognizing that no single vendor is likely to excel in all domains.

The schedule provided in Section 5 does not align with the dates provided in Appendix B. Primarily with the Delta delivery after MVP. Which dates should we adhere to for scheduling?

There are two typographical errors in Appendix B. Both

Release 1.5 and Delta should reflect a delivery date of

March 2027, not 2026. Once corrected, Appendix B will align with the schedule outlined in Section 5.

How does the Government prefer photos be incorporated to show we meet the not to exceed 6 page requirement?

Should reference photos be included via an appendix, or incorporated throughout as typical in white paper submission? We do not want to risk being disqualified on page limit.

Yes, photos and reference graphics may be included in an appendix. As stated in the RFSB, images and graphic representations do not count against the 6-page limit, provided they are used appropriately and the core content fits within the required format.

If we only need 1/2 page for a section that is outlined for 1 full page (i.e., Data Rights), can we use that 1/2 page towards another section (i.e., Tech Response)?

No, please stick to the outline that is provided in the RFSB

Can the RFSB be submitted in PowerPoint Format? What does the Government prefer?

No, solution briefs must be submitted in PDF format, derived from a Word document or similar. PowerPoint submissions will not be accepted.

Can the government share more details on the specifications of “autonomy processor w/GPU “so we can determine if adequate to run our team’s software?

Yes. Hardware specifications for the autonomy processor w/GPU will be provided to support vendor assessment and software compatibility. Reference Appendix E

If the computing power of the “autonomy processor w/GPU” is not sufficient to run our team’s ground autonomy software, will the government allow for the contractor to provide additional compute to power the ground autonomy software?

The Government is open to the inclusion of contractor-provided compute solutions if the existing autonomy processor is insufficient to support proposed ground autonomy software. Any additional compute requirements will be evaluated based on technical merit, integration feasibility, and cost/schedule impacts, and should be clearly outlined in the proposed solution and supporting

SOW.

What is the current cost to the government for the compute that will be used in HMIF Increment-1 (both M2C2 and the autonomy processor w/GPU)?

The Government does not intend to release specific cost information for the compute elements (e.g., M2C2 and the autonomy processor w/GPU) at this stage. These components are provided as Government Furnished

Equipment (GFE) under separate contracts, and associated costs are not directly applicable to this solicitation.

Can you please provide more details on the characteristics of the common controller? What operator input modalities does it include? For example, does it include a touch screen for the operator to use to issue commands to the unmanned vehicle?

The common controller features a combination of touchscreen and physical input controls. It includes both hardware-based controls with dedicated functions and software-configurable interfaces to support a range of operator input modalities for commanding unmanned systems.

Can the Government provide more details on the open interface, performance, and results of the Forterra RR-N-

140V1 device?

The Government can provide publicly available information regarding the Forterra RR-N-140V1 device. If additional technical detail is required to support integration efforts, the requestor may be required to execute a Non-

Disclosure Agreement (NDA) prior to receiving export-controlled or proprietary data.

Will the government consider proposals that include other

PNT capabilities in addition to integrating the Forterra RR-

N-140V1 device?

Yes, the Government is open to solutions that include alternative or supplemental Position, Navigation, and

Timing (PNT) capabilities, provided they do not disrupt planned integration of the RR-N-140V1 device. All such solutions will be evaluated for technical merit, feasibility, and potential cost/schedule impact.

Are respondents required to adhere to the exact page outline described in the “Solution Brief Guidelines”?

No, please stick to the outline that is provided in the RFSB

If selected for the oral presentation/pitch, will companies be permitted to include short videos showing evidence of their technology’s current maturity in the presentation materials?

Yes, vendors may include short videos in their oral presentations to demonstrate technology maturity, provided the content is relevant and supports the proposed solution. Video length, or technical difficulty playing them will not provide a basis for extending any Vendor's oral presentation/pitch time.

Are there any other formatting requirements for the solution brief, such as font type, font size, or margin settings, beyond the 6-page limit and 10 MB PDF constraint?

No, please stick to the outline that is provided in the RFSB.

Font no smaller than 9

Does RCCTO have a preferred format or structure for the pitch session on 27 May 2025, such as slide count, presentation length, or specific topics to emphasize?

Detailed guidance regarding the pitch session format, duration, and focus areas will be provided to vendors selected for oral presentations.

What is the relative weighting or prioritization of the evaluation criteria (e.g., technical merit, schedule feasibility, cost affordability, teaming strength) for the solution brief and pitch session?

The government will evaluate the solution briefs based on the criteria outlined in the RFSB.The Criteria will be viewed holistically when determining whether a Solution Brief presents an acceptable solution, or once evaluated acceptable, whether the Government will select it for presentation. However, a determination of unacceptability with a single criteria, or multiple criteria, may render a solution unacceptable.

Are there specific software components (e.g., C2, ground autonomy, assured control/safety, mission command interconnect) that RCCTO prioritizes for the initial prototype, or are all equally weighted?

The Government will evaluation/view software solutions holistically. Inability to meet minimum requirements will likely impact the overall rating of any particular solution.

Can RCCTO provide guidance on the level of detail expected for the Rough Order of Magnitude (ROM) cost estimate in the solution brief, such as a detailed breakdown versus a high-level range?

Vendors should provide a high-level ROM that reflects the overall scope and complexity of their proposed solution. A detailed cost breakdown is not required at this stage, but the ROM should be sufficient to support preliminary

Government planning and evaluation of feasibility. For the pitch presentation phase, the Offeror should provide a breakout of the estimated costs associated with the tasks and methods planned to achieve the proposed technical approach.

Are there restrictions on the number or type of teaming partners, or specific expectations for non-traditional defense contractors in the teaming arrangement?

There are no restrictions on the number or type of teaming partners. The Government encourages teams that bring the best combination of technical capability and value, including participation from non-traditional defense contractors when appropriate. However, RCCTO strongly urges Teams to be able to meet the requirements of 10

USC 4022(d)(1)(A) or (B), or to be prepared to offer an aggressive and beneficial cost-share under 10 USC

4022(d)(1)(C), as the Government does not currently anticipate 10 USC 4022(d)(1)(D) being available as a method to meet statutory requirements.

Can RCCTO provide additional details on the expected scope of Continuous Soldier Evaluations (CSE) during the

4-month period of performance, including frequency and format of Soldier feedback sessions?

The period of performance is not 4 months. The

Government is looking to receive the first software drops between 4-6 months. CSE dates are not locked in yet, but more details will be provided to those vendors who are down selected for pitch day.

The 1.5 Delta release says 04 March 2026, yet the 1.0

MVP release in October 2026. Is this supposed to be

2027?

Yes, this is a typographical error. The correct date for the

1.5 Delta release is March 2027, not 2026.

What are the specifications of the edge compute M2C2 hardware procured through T2S?

Yes, the Government will provide specifications for the

M2C2 hardware to support software compatibility and integration planning. Please see appendix D

May the government provide any details on the expected compute profile of the prototype HMIF RAS software to ensure offerors are providing a solution in line with SWaP constraints?

Yes, the Government can provide compute profile information to support alignment with Size, Weight, and

Power (SWaP) requirements and ensure integration feasibility. Please reference Appendix E

May the government disclose an NTE funding amount to aid in ensuring offerors present executable capability offerings and to aid in planning teaming arrangements?

The Government encourages Respondents to provide the most competitive and realistic ROM they can provide for the solution they present, while gearing their solution to the

SOO. The Government is using this RFSB at least partially for market research and does not want to artificially direct

Vendors to a particular NTE.

Does the government expect all control software to be authored by one vendor, who will also be the LSWI? Or is the expectation that the LSWI should support the integration of software from multiple vendors depending on the platforms and payloads included on the HMIF network, allowing for control from a unified UI?

The Government does not require that all control software be authored by a single vendor. The expectation is that the

Lead Software Integrator (LSWI) will be responsible for developing the core control software and ensuring its integration with other modular components—some of which may be provided by other vendors or as Government

Furnished Equipment (GFE). The LSWI must be capable of integrating software from multiple sources into a unified control solution that supports interoperability, a cohesive user interface, and compatibility across the HMIF network.

How do the Control Software “Control Autonomy

Functions”, like assisted teleoperation, compare with the requirements for Ground Autonomous Mobility Software, one of which is also assisted teleoperations? Which autonomy functions are meant to be handled by the

Control Software components?

CS will provide direct interface with mobility and lethality controls, allowing the operator to remotely operate systems. Additionally, CS software will allow engage/disengage various autonomy functions that the autonomy software will directly control. Ground Autonomy

Mobility Software (GAMS) will in general be handled independently to control a RAS with either no or minimal operator intervention. Assisted Teleop is a particular state where the control signals are mixed--likely onboard the

RAS--between input from the CS and GAMS. This is envisioned as operator-controlled motion with supporting inputs from GAMS. This would be analogous to automatic emergency braking or lane-keeping software in commercial cars.

Will the LSWI selected through this solicitation continue to be the LSWI for future HMIF efforts?

There is no guarantee that the LSWI selected under this solicitation will be retained for future HMIF increments.

Future efforts will be competed or awarded based on evolving program needs and acquisition strategy.

What are offerors expected to provide related to Assured

Control and Safety Software other than a low latency video selection and display capability (2.4.2)?

Offerors are expected to provide real-time control inputs necessary to operate the mobility and lethality functions of the platform. In addition to low-latency video support, they must interface with Government Furnished Equipment

(GFE) Assured Control and Safety Software as defined in the architecture. Alternatively, offerors may develop software components that run on existing GFE hardware, provided they meet the required safety and control standards. This requirement is in addition to the capability described in Section 2.4.2.

What is the role of Control Software UI relative to Mounted

Mission Command and TAK? Is the goal for Mounted

Mission Command and TAK to remain the central UI for mounted and dismounted instantiations and the Control

Software will push data to each of those UIs? Or will the

Control Software UI aggregate across dismounted and mounted UIs and message types, and act as a single, unifying COP? Who is meant to use the Control Software

UI, and how will they use it?

Control software performs robotic control whereas

TAK/MMC is for tactical C2. TAK/MMC does not need to be the target UI.

May the government elaborate on whether there is a preference between starting by leveraging a single autonomy vendor or stack to address the priorities listed under Ground Autonomous Mobility Functions, or multiple vendors (or stacks) whose autonomy solutions can be switched between?

The Government does not express a preference for a single autonomy vendor or stack. Offerors may propose either a unified solution or a modular approach involving multiple vendors or autonomy stacks, provided the overall integration is managed effectively. The Lead Software

Integrator (LSWI) is expected to organize and lead a team of best-in-class providers and ensure all autonomy components are interoperable and aligned with the HMIF architecture.

Is the Army interested in awarding one software provider to deliver all the components in each of the five categories?

or one provider to deliver everything? For example, will one provider be selected to do "Command and Control"? Is there room for providers to provide technical solutions that are one small piece of each category?

The Government is interested in awarding to a team, led by a Lead Software Integrator (LSWI), capable of delivering a cohesive prototype that addresses all five software categories—or fewer, if a vendor’s solution only supports certain areas. All properly submitted solution briefs will be evaluated based on: (1) technical merit, feasibility, and relevance to the SOO; (2) the company’s approach or technology and its development schedule; and (3) the realism and affordability of the proposed ROM. Vendors with specialized capabilities are encouraged to team with others to present an integrated solution aligned with these evaluation criteria.