Inactive

1. Description 1.1. THIS IS A REQUEST FOR INFORMATION (RFI) ONLY. This RFI is issued solely for information and planning purposes - it does not constitute a Request for Proposal (RFP) or a promise to ... 1. Description 1.1. THIS IS A REQUEST FOR INFORMATION (RFI) ONLY. This RFI is issued solely for information and planning purposes - it does not constitute a Request for Proposal (RFP) or a promise to issue an RFP in the future. This request for information does not commit the Government to contract for any supply or service whatsoever. Further, USSF is not at this time seeking proposals and will not accept unsolicited proposals. Responders are advised that the U.S. Government will not pay for any information or administrative costs incurred in response to this RFI; all costs associated with responding to this RFI will be solely at the interested party's expense. Not responding to this RFI does not preclude participation in any future RFP, if any is issued. This RFI is available on the System for Award Management (SAM.gov) website at https://sam.gov/SAM/. It is the responsibility of the potential responders to monitor this site for additional information pertaining to this RFI. 1.2. The Space Systems Center Production Corp Engineering (SSC/PCE) is seeking information on how an interested contractor could provide simulation capability that models the unmodified binary of spacecraft systems (bus and payloads). Classification Code: A- Research and Development 2. Background 2.1. Testing of a physical spacecraft and its specialized and expensive hardware is cumbersome and is limited by the availability of physical spacecraft simulators. The evolution of digital twining of embedded electronics, using technologies like instruction set simulators, has enabled the ability to produce bit and cycle accurate software only versions of complex spacecraft, see link in section 7 for an example. A fully software based simulation can be scalable and accessible from anywhere. Leveraging containerization and/or virtualization, the software-only test tools and testbed would be located within a digital engineering ecosystem, like Cloud One, or Platform One, to make the software simulators accessible to Department of Defense (DoD) cybersecurity penetration testers. These advanced testing techniques will enable experiments and research enabling more secure solutions on-board along with monitoring capabilities. Refer to the notional diagram of simulation setup, in Figure 1 (Attachment). 3. Requested Information 3.1. Describe modeling capability to design behavioral fidelity to operational spacecraft hardware such that data busses (e.g. I2C, SPI, MIL-STD-1553, SpaceWire) connect devices to flight computer in a software only simulation. 3.2. Describe how your simulator would emulate the space system command/control architecture including the ground and its avionics flight hardware in order to provide a realistic software-only environment (“virtual flatsat”) that is capable of executing the unmodified operational flight software that is utilized during normal on-orbit operations while receiving input from simulated ground system. 3.3. Describe your simulator’s ability to leverage instruction set simulation for enabling standard x86-64 CPUs (on premise and/or cloud) to execute the embedded spacecraft binary of the target mission system/s. 3.4. Explain whether your simulator will rely on contractor technical data versus use of modular open system architecture, which reuses existing system models. 3.5. Explain whether the simulation can be driven by a control interface that enables configuration of entire simulation as well as interaction with system under test. 3.6. Describe the simulator’s ability to be paused and resumed at desired checkpoints. 3.7. Describe how the simulation would be integrated with debuggers to enable real time debugging during execution of flight software. 3.8. Describe how the simulation element(s) that are part of the model will be equivalent (binary compatible) to those used on the real system. All data buses, memory types and sizes, I/O ports, clocks, and other supporting devices need to be equivalent to the flight data systems hardware. 3.9. Describe how the physical host systems that execute the models have sufficient hardware resources to execute the models cycle in [1x] real time. 3.10. To the extent possible, provide a non-binding planning estimate for non-recurring expense in the creation of (referencing figure 1) Main On-Board Processor, Peripherals, Virtual Backplane/Middleware, and expected integration cost, along with annual cost profile that shows development through sustainment. Also, provide an estimation of schedule. 4. Response 4.1. 4.1 All interested, capable, and responsible sources are requested to respond to this RFI with a white paper, using their preferred style, in either Word or PDF format. While this RFI is not limited to any specific business size, responses from small and small disadvantaged businesses are encouraged. 4.2. White papers are due no later than 1700 PDT, 30 days after release of this RFI. Responses shall be limited to 10 pages responding to the topics in Section 3 above, and submitted via e-mail only to daniel.hilger@spaceforce.mil and brandon.villalpando@spaceforce.mil. All submissions become Government property and will not be returned. 4.3. Proprietary information, if any, should be minimized and MUST BE CLEARLY MARKED. To aid the Government, please segregate proprietary information. If any responder does not currently have a Proprietary Data Protection Agreement (PDPA) that would permit the government or the SSC support contractors listed below to review and evaluate white papers submitted in response to this RFI, the responder is requested to sign PDPAs for this purpose. Any Controlled Unclassified Information (CUI) must be properly marked. The following is a list of support contractors who may participate in reviewing the responses: -The Aerospace Corporation -MITRE Corporation -SAIC 4.4. Classified delivery must be arranged in advance. Do not submit classified information to the Government point of contact emails provided above. Responses at classification levels above DoD SECRET are discouraged but may be considered. Classified responses must include identification of their source of classification guidance. 4.5. Section 1 of the white paper shall provide administrative information, and shall include the following: a. Name, mailing address, phone number, fax number (if applicable), and e-mail of designated point of contact. b. A brief (2 pages maximum in addition to the 10-page limit discussed in 4.2 above) description of the responding company's location(s), products, and relevant previous experience. c. A statement that the responder will allow the Government to release its proprietary data to some or all of the Government support contractors specified above for purposes of evaluating the response. d. Identify your organization's business type inclusive of any and all socio-economic status (e.g., 8(a) certified program participant, small disadvantaged, veteran-owned, service-disabled veteran owned, HUB Zone or women-owned); a business concern submitting a response is categorized as a small business if it has $30.0 million or less in average annual receipts. 5. Industry Discussions 5.1. SSC representatives may or may not choose to discuss white papers with responders. Such discussions would only be intended to get further clarification of potential capabilities, designs, and risks. 6. Questions 6.1. Questions regarding this announcement shall be submitted in writing by email to the Contracting Officer, Daniel Hilger at daniel.hilger@spaceforce.mil and to the Contracting Specialist, Brandon Villalpando at brandon.villalpando@spaceforce.mil. Verbal questions will NOT be accepted. The government reserves the right to post all questions and its answers to SAM.gov, so questions should NOT contain proprietary or classified information. 7. Attachments/Links Attachment: Figure 1 – Notional Simulation Setup https://www.nasa.gov/centers/ivv/dynamic_analysis_enabling_tech.html