HANGS Questions and Answers-26 Jan 2026.pdf

QUESTION ANSWER

Could you please advise if there is a desired page limit?

There is no page limit for the Enhanced White Paper (EWP). This was changed to 25 pages in REWP Revision 1.

Can you please confirm the due date?

The HANGS Request for Enhanced White Papers (REWP) is an open announcement with no due date. The Government will review and evaluate white papers as they are received. The HANGS REWP will be open for one year from date of post on SAM.gov, after which mission needs will be re-assessed and the REWP may be terminated or extended. This announcement may close at any time without further notice. The due date changed to 31 Jan 2026 in REWP Revision 2.

Will whitepapers be evaluated and awarded on a rolling basis, with potential acquisition decisions before May 2026

Yes, all eligible EWPs will be evaluated on a rolling basis. Each solution in response to this REWP is likely to be unique, so it is the Government's intent to evaluate each EWP submission as they are received. If an EWP is selected, a full proposal may be requested based on the merit of the EWP solution offered, without regard to other submissions.

Is there an estimated timeline for requesting the full proposal following a whitepaper being selected?

There is no set timeline, but we anticipate that if an EWP is selected, the Government would likely request a proposal within a couple weeks of EWP selection, and then we would provide up to 30 days for the offeror to submit proposal.

Are you looking for a full delivered system to do your signature research or are you looking to build your own system using off-the-shelf cameras/sensors?

We plan to procure Commerical Off the Shelf (COTS) camera systems that we may design into a projection system that we design/build.

Does this REWP require M-Code for GNSS receiver technologies (Technology Area #2)?

It may include those options. Offeror will need to have capability to procure/develop to that requirement if government asks.

Confirm whether this initiative represents a new undertaking, or is there an incumbent currently delivering these services? If an incumbent exists, may we request the relevant details of their contract, including the contract number?

There are other contract vehicles currently being used to fund similar test technologies. In addition, there are multiple similar hardware-in-the-loop (HITL) development activities to support customers at this government organization.

This specific contract will fulfill several HITL capabilities funded through Air Force Test Center (AFTC) Investment & Modernization (I&M) and the Test Resource Management Center's (TRMC), Central Test and Evaluation Investment Program (CTEIP) to address test gaps. However, there are other investment avenues, possibly by customers, that will utilize this contract vehicle if able.

What is the anticipated award value?

The anticipated award value is unknown at this time. There is an $80M ceiling associated with this opportunity.

In areas like Technology Area #1 (Scene Generation), is there any assumption that the prototypes developed will have compatibility / be expected to support legacy GWEF scene generation tools such as FLITES?

Short answer is, YES, we expect compatibility with legacy Guided Weapons Evaluation Facility (GWEF) scene generation tools such as Foundational Logistics Information Technology Enterprise System (FLITES).

More detailed response:

1.) FLITES is an Application Programming Interface (API) real-time scene generation software application. It is not legacy; and it is one of the few authoritative software applications for Electro-Optical/Infra-Red (EO/IR) real-time scene generation used by most service test organizations throughout the government (the Army uses JSIG and the Navy may use another; but all services HEAVILY utilize FLITES).

2.) Since FLITES is a software application, the real question should be: is it assumed that tech-nology area #1 (scene generation) be backwards compatible with current and legacy scene rendering protocols and scene gen interfaces (HDMI, Fiber Optic, etc)? We believe the answer is still Yes; although we don’t have information on hand to provide those types of interfaces and protocols. They can be provided upon request.

Is there a need for real flight test instrumentation hardware for the simulated tests that you plan to perform?

No, not for this opportunity; out of scope.

Is the intention of the HANGS to generate a simulated telemetry stream of flight test data?

No, not for this opportunity; out of scope.

HANGS Questions & Answers 26 Jan 2026

Do you want an evaluation of LAWS (lethal autonomous weapons system) benchmark performance as output (similar to the DARPA ASIMOV project), OR just simple positional logging as output and you'll decide on evaluation yourself with your in-house benchmarks?

No, this project focusses on the synthetic scene environment simulation technologies. We don’t specify any specific use-cases, specific UUT sensors, or program; the intent is to keep the capability open, modular and scalar to integrate many variable UUT sensor systems. We plan to mold and develop onto this topic’s simulation technologies depending on future customer demand. We have an organic simulation architecture within our organization that was build to develop and change configuration depending on customer use-cases. The goal is to interface the topic’s technology to our organic simulation architecture. We also have an array of in-house analysis and data acquisition tools. We typically utilize existing tools or develop our own tools for ability to change and augment when necessary, but we also utilize COTS/GOTS when, after cost benefit analysis is evaluated, it is applicable and if it adds value to customer use-case and test goals.

Would this evaluation software be valuable to your use-case at this point in time?

Possibly, depending on the use case, but not specifically for this project topic.

Concerning your preferred hardware communication protocol Peripheral Component Interconnect Express (PCIe) over fiber, would our prototype suffice to use just UART at the beginning stage of this project, or is PCIe needed to consider our proposal?

The technology developed for scene generation will be required to accept video from independent COTS/GOTS items without developing unique interfaces.

Therefore, standard interfaces are preferred to prevent more development.

Could you also elaborate on the sensor protocol for injecting emulated raw data directly into the LAWS sensors?

If generally speaking of UUT sensor systems, the answer is that that it will vary and a possible interface will be necessary depending on which program we are testing. MOSA/WOSA/SOSA, may help standardize this in the future.

Lastly, it seems like we assume the LAWS will have GNS and when jammed GNS, then the LAWS will transition to another sensor. Thus the LAWS may experience chattering from state transitions. Would you value judgement of this transition state performance with a metric?

The UUT sensor “may” have a GNSS receiver, but not necessarily; it depends on the customer and UUT sensor for which we are testing for. However, if the UUT has an GNSS/INS system, we expect the capability to provide jamming environment. If the system transitions to another navigation input due to a degraded GNSS environment, we expect that the UUT will handle the transition to the other navigation system. Our internal host simulation architecture will handle the communication and synchronization with the varying scene environments (ie. GNSS and visible target/background scene; or GNSS and celestial tracker).

Should the solution for Technology Area #3 (Datalink and radio communication emulation/simulation) account for injecting digitally, in RF probes, or over-the-air?

Yes, assume that technology area #3 will focus on digital inject either using: 1) If simulating a messaging simulator that will be injected onto the bus of the GNS UUT, a transport layer of 1553 or TCPIP or 2) If simulator includes generating RF using a TxRx radio UUT to/from another TxRx radio UUT, RF injection will be used but not free-space radiated (only via RF cables).

Technology Area #2: Midcourse and navigation environment emulation/simulation - Can you provide what the current equipment and environment is for PNT/AltPNT simulation?

Current PNT simulation environment includes GNSS real-time wavefront simulators that can provide multiple element output ports, ingest multiple TSPI files for individual platforms, provide extensive jammed environment (spoofing and CW), provide encoded signal sets such as Y-code & M-code, and provide multiple simultaneous constellations and signal sets. This is for traditional GNSS receivers that employ either FRPA or CRPA systems. Other navigation capabilities utilize celestial and terrain mapping that use EO-IR or SAR sensors.

There are other novel AltPNT technologies, but not certain whether they are directly employed by weapon systems.

Technology Area #3: Datalink and radio communication emulation/simulation - Are you able to specify which frequencies, bandwidths, and modulation are of interest?

No; expect new frequencies, bandwidths, and modulation requirements as we get them which may be after this contract is awarded.

- Are there any anticipated conops? E.g., platforms, antennas, anticipated ranges, and velocities.

The weapon platforms may receive the signal from any number of TxRx platforms. Cannot get into detail here. But BLOS is a factor and high velocities is a factor.

- Can you elaborate on what countermeasure effects might be of interest?

Jamming? Nuclear effects? Others?

Common and novel radio jamming techniques; no nuclear effects.

- Are you looking for hardware emulation, software emulation, or some combination of both?

Both. Need a message generation emulator that can a.) transport behind the bus of the weapons system OR be TxRX via radio (of which we have not identified yet) to/from another TxRX radio; a channel emulator in between will need to augment the RF with respect to environmental effects.

Is there going to be a request for proposal/request for quote after the solicitation?

If a successful white paper has been selected, the Government will request a proposal from the selected vendor(s). When a proposal is requested from the Government, we will provide the evaluation methods to the selected vendor(s).

(see REWP pgs 9 & 14)

Should we disclose partners/subcontractors in the whitepaper? Yes Can a vendor get provided a tour of the GWEF facility? Will this be a conflict of interest or an equal opportunity issue?

To be determined.

What is the evaluation methods of the proposals? Are we going to make awards directly off this REWP?

Awards will not be made directly off of the REWP. If a successful white paper has been selected, the Government will request a proposal from the selected vendor(s). When a proposal is requested from the Government, we will provide the evaluation methods to the selected vendor(s).

Will the Government consider Controlled Unclassified Information (CUI) in the Enhanced White Paper response and if yes, will the Government provide a secure upload link for us to upload our submission?

Do not mark as CUI. Your company can mark it as sensitive/proprietary;

however, only the Government is responsible for marking CUI. If a company would like to send via DoDSAFE they are allowed to; however, the documents that are sent must not be locked and also must be allowed to be reviewed by the proper review personnel (technical and contracting team). Additionally, the submitted whitepaper must still meet the submission standards in the request for enhanced white papers.

Could you confirm if we are eligible for an award on this topic prior to receiving an FCL, or do you have a recommendation for how to engage in this opportunity prior to receiving an FCL?

No FCL is required to receive an award.

Regarding HWIL under tests – is this Hardware represented by passive only sensors or there would be active (e.g. emitting RF) sensors?

No, for the RF specifically, technology #1 may include a requirement for components/sub-systems/systems enabling the capability for return signature scenes from a scanned/transmitted RF UUT signal.

Are there priorities in implementing all spectra as listed in the solicitation (including, for example, Ku band) or only selected bands can be implanted?

The goal is to have ability to address any of the spectra for which a program office has as a requirement to address new and advanced future systems. Since our test organization doesn’t know the type of UUT sensor or GNC that may be presented to us for test, the purpose of this OTA is to have a vehicle at our disposal to address any of these technologies (UV, Vis, SWIR, MWIR, LWIR, L, S, C, X, Ku, K, Ka, W). It is not expected that Offerors for this OTA will have a direct solution for all possible spectra, but having initial approaches, options, and possible partnerships with vendors with various spectral strengths will better prepare our organization to execute development and testing with agility.

Would AF provide thermal/other signatures during the development (post award phase)?

This OTA does not expect Offerors be responsible for target/background scene modeling to include thermal signatures.

What is the recommended/acceptable development timeframe?

This is not a simple objective parameter to provide. The timeframe depends on what technology areas the Offeror is proposing, how many of the Offeror proposed technology areas are required to be addressed, and how sophisticated of a solution is required for addressing the UUT/Sensor/GNC presented to the Government by a stakeholder/customer/program. The Offeror should propose an attainable schedule for the technology solutions they can provide in development and/or reach-out.

Would it be acceptable if the unlimited data rights were allowed for any data generated by the software, but keep the software itself under SBIR data rights?

The answer is somewhat nebulous and depends on how locked-down the software will be and more context on what tasks the software completes.

Certainly, the Government would accept an EWP providing this detail along with their solution to the topic that provides more insight to its function. Our Government test organization is postured and relevant only if we can adapt to mission and unit under test (UUT) changes for different weapon’s programs and over their individual lifecycles. To provide best value to the Government, we must be able to do this with agility and in a cost-effective manner. Certain software that is locked down to the point of not allowing a cost effective or agile approach to new development is not desired. Data rights can be negotiated/discussed with the Government during the proposal phase.

Would an acceptable compromise be giving the government unlimited access to executables and any data formed from the executable, but maintain the source code under SBIR data rights?

As stated in the previous question, it depends on how much it would lock-down government agility to modernize and develop onto. Certainly, we would accept an EWP providing this detail along with their solution to the topic that provides more insight to the Government.

How much does keeping some aspect of the solution under SBIR data rights (i.e. not providing total unlimited rights to the government) impact the solution rating?

At this early stage, the evaluation is more high-level. A proposal can be rated "acceptable" based on its overall approach and understanding of the requirements, even if there are some weaknesses, such as data rights limitations.

If a vendor's EWP is selected to advance to the full proposal stage, data rights become a more critical evaluation point. The government will assess how any restrictions might impact their ability to evolve and modernize the technology in the future, including potential cost implications.

Data rights can be negotiated/discussed with the Government during the proposal phase.

Is there any verbiage that you can recommend for us to use in our white paper to better align our software data rights concerns with the Government’s needs?

No. While the government cannot provide specific verbiage for your white paper, the most effective approach is to be direct and transparent. The 'right' wording is entirely context-dependent, as our evaluation focuses on how your specific data rights assertions would impact our ability to develop, modernize, and optimize the solution in the future.

A white paper may address the following points to demonstrate a clear understanding of the government's long-term needs:

- Define the Boundaries: Explicitly state what specific data or software components fall under your restricted rights.

- Provide the Justification: Briefly explain why retaining these rights is necessary to protect your commercial interests.

- Address Government Needs: Most importantly, describe how the government can still successfully operate, maintain, integrate, and modernize the capability despite these restrictions.

Is there a specific contract type that will be awarded for this effort (ie CPFF, FFP, etc)?

The agreement may be fixed-price, cost-reimbursable, or a hybrid of both.

Does the cover sheet count toward the overall page count? Yes, it does include the cover page.

Can you confirm that the due date is 31 Jan 2026? Yes, the due date is 31 Jan 2026.