COBRA_DANE_ADPE_Rehost_VAX-_RFI_- V6(final).docx

Space Systems Command (SSC)/ECQC

REQUEST FOR INFORMATION (RFI)

COBRA DANE ADPE Re-Host

FA8723-22-R0002

This RFI is for market research purposes only and should not be construed as a commitment by the United States Space Force to issue a solicitation or ultimately award a contract. Neither unsolicited proposals nor any other kinds of offers will be considered in response to this RFI.

The Government does not intend to award a contract based on this RFI or to otherwise pay for the information. Companies responding to this RFI are advised that participation does not ensure involvement in future solicitations or contract awards. The Government will not reimburse any company or individual for any expenses associated with preparation or participation in this RFI. Respondents are solely responsible for all expenses associated with responding to this RFI. Information Sought SSC/ECQC, formerly AFLCMC/HBQC, is planning to replace the aging mission computer architecture of the AN/FPS-108 COBRA DANE (CD) radar system to include computer hardware, mission software, and its peripherals (i.e., line printers).

This RFI is requesting information from interested small and large businesses on approaches and options towards resolving the technical challenges posed by the replacement of aging Digital Equipment Corporation (DEC) Virtual Address eXtension (VAX) computers and their peripherals. The information provided will be used by the Government to help define the acquisition strategy to modernize the Automated Data Processing Equipment (ADPE). Companies should not solely rely on the exact technical accuracy of the information presented herein to develop formal production responses. The data are provided as a general reference only.

Background CD is a 40-year-old large, ground-based phased-array radar system located on the northwest corner of Eareckson Air Station on Shemya Island, AK. The system supports two critical Air Force missions: Missile Defense (MD) and Space Domain Awareness (SDA). The system was fielded in 1976 by Raytheon Equipment Division Laboratories (EDL). In 1993, Raytheon EDL completed a major system modernization program that replaced the original Cyber mission computers, peripherals and radar displays, all operational software, and several unsupportable radar hardware subsystems.

Most of the radar front end was retained. Missile Defense mission capabilities were added by the CD Upgrade program under Presidential Directive between 2001-2004, leading to the nation’s first United States Strategic Command (USSTRATCOM)-certified Ground-based Midcourse Defense (GMD) radar. This mission was implemented largely as a software modification. None of the system hardware was changed, but a new communications processor was added to enable CD to respond to sensor tasking from, and report threat missile data to the Ground-based Mid-course Defense Fire Control (GFC) component for target engagement support.

The Site’s geographic location described presents very unique logistics and communications challenges. Eareckson AS is supported by military-controlled/contracted air and barge support with daily, weather driven impacts. The electronic communications to/from the island are extremely limited for both voice, data, and classification. The communication systems are managed for mission support and system support by the Site O&M contractor.

COBRA DANE ADPE Overview The CD ADPE system consists of several components including the radar, the Mission Computer (MC), Workstations, Communications Systems, and Support Equipment. The CD Signal Processor and Radar Controller (SPARC) serves as the interface between the VAX MC and the radar hardware. The VAX MC system (generally defined in Fig 1) consists of two redundant VAX mainframes deployed in a cluster configuration with a third VAX, five VAX 4000 workstations, five VT1200 dumb terminals and three VT-520’s to interface with the mission computers. The mainframes share external disk storage, line printers and network equipment (switches, hubs, routers). Each workstation has a monitor, a VAX keyboard, and a VAX three-button mouse.

Figure 1. VAX Interfaces

The primary and secondary MCs are DEC VAX 6640-equivalent mainframe computers (upgraded aftermarket from 6520) using Virtual Memory System (VMS) 5.5-2 Operating System (OS), selected more than 25 years ago. An HSJ-50 disk array storage system phased out the original 9-track tape drives for mission data recording and supports both disk and Digital Linear Tape (DLT) tape recording. Much of the computer equipment and peripherals have been out of production for more than two decades and are becoming increasingly difficult to maintain. Attempts to update the OS have been hampered by the unsupportable middleware products: Universal Network Architecture System (UNAS) and Shared Ada Memory Resource Executive (SAMREX). The UNAS and SAMREX programs are middleware products which provide inter-process communication and messaging essential for the existing mission software to operate. The UNAS source code was located and obtained from the original developer in 2016 but the level of integrity and support of the code are uncertain.

The MC is connected to other CD components and elements through several internal and external interfaces:

· The Signal Processor and Radar Controller (SPARC) connection currently uses a DEC DRB-32 parallel bus interface.

· The GMD System is connected via the Battle Management Command, Control and Communications (BMC3) Communication Processor Equipment (BCPE) through a 10 Base-T Commercial Off-The-Shelf (COTS) Ethernet interface.

· The Time Standard Unit (TSU) connection is over a RS-232 interface via the SPARC using an SIMPACT RTC01 real-time clock.

· Space Domain communications are provided via a direct connection from the VAX over a very low speed RS-232 connection.

The operational mission software suite consists of six (6) Computer Software Configuration Items (CSCIs), five (CSCI 1-4, 6) of which run on the VAX mainframes and are written in the Ada83 programming language. These CSCIs provide real-time, non-real-time, and diagnostic support capabilities to the system. The general software relationships are depicted in Figure 2. There are approximately 280k Ada83 source lines of code (SLOC). Nearly all code resides on the VAX mainframe, while a small portion of operator display software is hosted on the VT4000 workstations and the CSCI-5 code hosted in the Receiver Exciter component.

· CSCI-1 Operating System Augmentation (OSA): Augments the capabilities of the DEC VAX operating system and provides the principal interface to the VMS environment.

· CSCI-2 Mission Software (MSN): Provides the real-time and non-real-time software required for mission operations. Includes user interfaces, communications methods, and critical radar functions.

· CSCI-3 Simulation Software (SIM): Provides methods for testing the mission software and portions of the signal processing pipeline by injecting simulated targets into various data feeds.

· CSCI-4 Operational Support Software (OSS): Provides post-mission processing tools.

· CSCI-5 Receiver Exciter Software (RXS): Resides on the REX hardware and controls the generation of desired waveforms.

· CSCI-6 Radar Diagnostics Services (RDS): Provides capabilities to detect and isolate failed components within the radar subsystem as well as assist in system performance assessment.

Figure 2. Relationship between CSCIs

Additional software components include the following:

· DEC Command Language (DCL) scripts: Multiple system functional and maintenance tools are written as scripts.

· Programmer’s Hierarchical Interactive Graphics System (PHIGS): PHIGS is based on the DEC Windows Toolkit (DWT) and User Interface Language (UIL). DEC Windows is based on X Windows 11.

· VAX MACRO Assembly: Original SAMREX atomic procedures and routines are written in this language.

The BCPE provides the interface between the CD system computer and the external users where mission control directives are received, and CD output data is transmitted. It is connected to the existing VAX via a dedicated Ethernet Local Area Network. The BCPE is currently not part of the projected effort.

Interfacing to the Mission Computer is the hardware-based SPARC. The SPARC was also installed during the 1990-1993 modernization effort. The SPARC interfaces with the Receiver-Exciter (REX) to perform the Signal Processing (SP) function of the mission system. It also performs a radar controller link between the signal processor and the mission computer. In addition, the RC is the link between other radar hardware subsystems (Receiver-Exciter, Beam Steering Unit (BSU), and Transmitter) and the mission computer, with time-phased instructions generated by the MC. Both the SPARC and the REX are being replaced under a separate effort and are not the subject of this RFI. The replacement effort will initiate the modernization of the interfaces between the new, software-based signal processing components and the MC.

The ADPE suite (VAX and related storage and display peripherals) is overtaxed to the point that it hampers software modifications. This often requires compromises to be made in algorithm complexity due to the limited remaining computational resource margin, and the aging computer suite is now limiting the effectiveness of fielded software solutions.

Several options have been considered to date in replacing the aging ADPE VAX. The government is seeking industry ideas that both support long term modernization yet deliver incremental operational capability within tight fiscal constraints. Concepts that may support this approach range from VAX emulation on a modern x86 platform, modular separation of software by function to full system containerization in a modern DevSecOps environment. The critical element is that any approach needs to be broken into affordable, incremental, and severable operational end-states. The desired first end-state is to cost-effectively migrate the mission functionality of the COBRA DANE system onto modern cybersecurity compliant computers, while accounting for all middleware software and operational mission functionality. The final end-state system should be fully converted to a modern programming language with modern interfaces. Each severable end-state needs to be an independent, operationally tested, and deployable system.

Response Information All interested parties are invited to submit their response to this RFI. Please limit your response to the request above to no more than 10 pages in a PDF or MS Office Word 2010 compatible format with 12-point Times New Roman font. The information received will be handled as competition sensitive and will assist in formulating an acquisition strategy decision. If there are any questions for the Government, please provide them at the end of your response within the 10-page limit; use caution in this area as the questions received and Government responses may be made public for information parity. Responses are due no later than 30 business days after RFI posting.

Approaches need to focus on the delivery of requirements in a fiscally responsive, severable, phased approach that considers the Fundamental and Additional requirements listed below:

Ensure the response includes capabilities for access and storage of classified information. The Fundamental requirements are:

· Preservation of the overall mission capabilities of the existing system

· Minimization of operational system downtime during computer modernization and testing

· Facilitate exploitation of new capabilities inherent with new technologies

· Facilitate Cybersecurity compliance and updates Additional requirements being considered for the replacement elements are:

· Enable greater flexibility for future s/w upgrades

· Improve operator mission data situational awareness (e.g., modern displays, improved human-machine interfaces)

· Facilitate development of enhanced system diagnostics to minimize operational downtime for preventive maintenance.

· Enhance system operations with increased resiliency to improve mission performance

· Deliver a new, off-line software development facility that supports extension to include hardware interface emulation

· Provide foundation for implementation of modern communication protocols such as TCP-IP, JSON, and XML for external interfaces.

The Fundamental requirements are considered the foundation of the mission system and must be included in the first phase of your approach. Additional requirements may be addressed in the first or multiple, subsequent phases.

The government does prefer that the severable nature of each phase is segregated into functional components that could deliver an operationally tested capability. Any approaches submitted containing Company proprietary approaches and/or information, please ensure they are properly marked. In addition to the general approach requested above, the Government is seeking industry feedback on the questions located at the end of the document.

Responses shall be emailed to, and all questions addressed to: Ms. Keri Sampson, Contracting Officer, Email: keri.sampson@us.af.mil

COBRA DANE RADAR SYSTEM MARKET RESEARCH

Reference Number: FA8723-22-R0002

*Please note: The only authorized Point of Contact for this requirement is:

Ms. Keri Sampson, Contracting Officer at keri.sampson@us.af.mil

Contractor Business Name:

Address:

Phone:

Primary Point of Contact:

Email:

Cage Code – Size:

NAICS Code(s):

Please provide answers to all of the questions below. Limit responses to the yes/no questions to the table. Numbered questions continue responses on additional pages within the page limit as needed. Past Performance will be requested by the government as needed

A. TECHNICAL SKILLS – All responses should be given as they relate to the requirements described below supporting the technical project description provided.

Information submitted by the respondents to this RFI is strictly voluntary. The Government will use this information as part of our on-going market research. If there any paragraphs in the RFI that are unclear, if so please identify and clearly state the ambiguity.

1. Please provide your recommendations, with rationale, for the acquisition approach to this effort. Include suggestions for contract type, and available contract vehicles (e.g., IDIQ)

2. Please provide the methods and any experience you have for code engineering or replacement for legacy software of this nature. Additionally, list any experience with automated software engineering, security engineering and coding tools, and how they fit in your processes from code assessment through test.

3. Please detail any specific experience with ADA83 Software code conversions (from ADA83 to a modern programming language in a modern computing environment). If not experience with ADA conversions, detail any experience with legacy code migrations

4. Please describe your experience migrating legacy hardware (e.g., VAX) to modern hardware platform to include use of emulation or cloud-native computing foundation technologies.

5. Please provide any VAX-proprietary interface or VAX VMS Operating System experience you have and the context of the experience.

6. Please detail any experience reverse engineering inter-process communications (to include library dependencies, HW signals, in-memory data stores, Network-based messages, files, etc.).

7. Please provide any experience you have with detailed timing interfaces – specifically high-precision HW and SW timers – and detail the nature of any timing assessments performed in support of new development or integration activities.

8. What testing strategy and/or methods would you employ to mitigate the impact to mission downtime?

9. What testing strategy and/or methods would you employ to verify the VAX suite and internal and external interfaces to mitigate the impact to mission downtime?

10. Please define what specific technical information you require to support a response to a formal solicitation for this work.

11. Please provide any project risks you foresee in the development, execution, test, and deployment of this work.

12. Please provide a segmented ROM for your approach(s). Each segment will focus on each severable, operationally tested, and deployed phase. Request that the fundamental segment be categorized by the following areas: design, development, test and operational delivery and include a high-level schedule for this segment. Each segment beyond the fundamental that delivers Additional requirements will include cost and schedule adjustments for the added capability.

13. Would you submit an Offer as a Prime or Subcontractor? Do you have an existing teaming arrangement(s)?

Microsoft_Visio_Drawing.vsdx image2.png image1.emf