Distributed Live, Virtual, and Constructive Integration Architecture

for Information (RFI) Distributed LVC Integration and Cross-Facility Connectivity Architecture 96th Test Systems Squadron (96 TSSQ) 1. The 96th Test Systems Squadron (96 TSSQ) is seeking industry feedback and technical insight to support the development of a distributed Live–Virtual–Constructive (LVC) integration and cross-facility connectivity architecture for use across the Eglin Gulf Test and Training Range (EGTTR). The Government is exploring approaches to enable secure, synchronized, and scalable data exchange between geographically separated test nodes supporting advanced weapons test activities. This announcement serves as a REQUEST FOR INFORMATION(RFI) only for the purpose of market research in accordance with Revolutionary Federal Acquisition Regulation (FAR) Overhaul part 10. This RFI is issued for planning purposes only and is not a Request for Proposal (RFP), an Invitation for Bid (IFB), or an obligation on the part of the U.S. Government to acquire any products or services. In accordance with (IAW) Revolutionary FAR Overhaul 15.101(c)(2), responses to this RFI are not offers and cannot be accepted by the Government to form a binding contract. The Government will not reimburse respondents for any costs associated with the prepa-ration or submission of the information requested. All costs associated with responding to this RFI will be solely at the responding party’s expense. Not responding to this RFI does not preclude participation in any future RFP, if issued. The Government reserves the right to reject or disregard, in whole or in part, any contractor’s input resulting from this RFI. This RFI does not constitute a solicitation for the proposals or the authority to enter into negotiations to award a contract. The information provided may be used by the Government in developing and acquisition strategy, a statement of work (SOW), statement of

objectives (SOO), or performance specifications. Any proprietary information or technology should be clearly marked. 2.

Background and Statement of the Need Current test and simulation activities across EGTTR rely on isolated, facility-specific configurations with limited interoperability. The Government seeks to establish a unified, secure, 1 and scalable architecture that enables: ˆ Distributed LVC connectivity across multiple test nodes ˆ Time-synchronized data distribution and event coordination ˆ Multi-domain access control and controlled data release ˆ Configuration management and version control across facilities ˆ Monitoring, logging, and health management of distributed links ˆ Interoperability with existing modeling, simulation, and test systems Industry input is requested to refine architectural options, identify technical risks, and assess potential solution pathways. 3. Information Requested 3.1 Technical Approach ˆ Proposed architecture for distributed LVC integration ˆ Methods for deterministic timing and synchronization ˆ Data distribution mechanisms for state vectors, metadata, and timing signals ˆ Approaches for multi-domain access control and cross-domain data handling ˆ Strategies for configuration management and version control ˆ Integration with existing test and simulation systems 3.2 Demonstrated Capability and Past Performance Respondents shall provide: ˆ Verifiable past performance relevant to distributed test or LVC environments ˆ Evidence of technical maturity (fielded systems, prototypes, accredited components) ˆ

Objective performance metrics (latency, throughput, synchronization accuracy) ˆ Deployment history and operational context ˆ Points of contact who can validate claims 2 3.3 Minimum Technical Maturity (TRL Requirement) ˆ Threshold: TRL 7—System prototype demonstrated in an operational environment ˆ

Objective: TRL 8 — Actual system completed and qualified 3.4 Vendor Qualifications Respondents shall describe: ˆ Corporate experience with distributed test or LVC systems ˆ Technical staff qualifications ˆ Cybersecurity maturity and cross-domain experience ˆ Experience supporting multi-domain or multi-node architectures 3.5 Risks, Dependencies, and Assumptions ˆ Technical risks and mitigation strategies ˆ Dependencies across distributed test nodes ˆ Cybersecurity considerations across levels 3.6 Rough Order of Magnitude (ROM) ˆ Cost bands for prototype, integration, and sustainment ˆ Schedule assumptions for phased capability delivery 4. Response Structure 4.1 Required Core Response (10 pages maximum) 1. Executive Summary (1 page) 2. Technical Approach (5 pages) 3.

Requirements Traceability Matrix (2 pages) 4. Risks and Assumptions (1 page) 5. ROM Cost and Schedule (1 page) 3 4.2 Optional