DOD initiated the SBIRS program to meet all military infrared surveillance requirements through a single, integrated system, and to provide better and timelier data to the Unified Combatant Commanders, U.S. deployed forces, U.S. military strategists, and U.S. allies. SBIRS is to replace the existing infrared system, the Defense Support Program, which has provided early missile warning information since the 1970s. The SBIRS program was originally conceived as having high- and low-orbiting space- based components and a ground segment for mission-data processing and control to improve current capabilities. In 2001, the SBIRS Low component was transferred from the Air Force to the Missile Defense Agency and renamed the Space Tracking and Surveillance System. The Air Force continued developing SBIRS High (herein referred to as “SBIRS”). It, along with its associated ground segment, is one of DOD’s highest priority space programs. The SBIRS program originally consisted of four satellites to operate in geosynchronous earth orbit (GEO), plus one spare, an infrared sensor placed on two host satellites in highly elliptical orbit (HEO)—known as “HEO sensors”—and a ground segment for mission-data processing and control. The SBIRS GEO satellite is designed to support two infrared sensors—a scanning sensor and a staring sensor. The first GEO satellite is commonly referred to as GEO 1. Figure 1 shows the GEO satellite that is to operate in space. As a result of past technical and program difficulties experienced during sensor and satellite development, the SBIRS program has encountered cost and schedule increases. These difficulties have led DOD to restructure the program multiple times, including revising program goals in 2002, 2004, and 2005. For example, in 2002, the program faced serious problems with software and hardware design progress and, in the Conference Report accompanying the National Defense Authorization Act for Fiscal Year 2002, conferees recommended cutting advance procurement funding due to concerns about program developments and the unclear status of the SBIRS program. At that time, the first satellite launch slipped from 2002 to 2006. In late 2005, SBIRS was restructured for a third time which stemmed from a 160 percent increase in estimated unit cost, triggering a fourth Nunn-McCurdy breach, which again postponed the delivery of promised capabilities to the warfighter. The flight system software is expected to control the GEO satellite’s mission critical functions and activities. Unlike other software programs that can be deferred and uploaded to the satellite after launch, the flight software cannot be deferred because it is critical to the satellite’s operation and function. The flight software is expected to operate, control, and monitor the GEO satellite’s health, status, and safety. Based on the original design, the flight software was to operate on two of four computer processors onboard the satellite and perform important functions and operations, such as telemetry, thermal control, power management, and fault detection activities. Figure 2 shows a simplified diagram of the original flight software design. In 1996, development of the flight software began as an independent research and development project by Lockheed Martin—referred to as reusable flight software (RFSW)—to be used for multifunctional “bus” purposes. In 2004, the RFSW was provided to the SBIRS program for development as the flight system software to operate, control, and monitor the GEO satellite’s health, status, and safety. At that time, the software needed to address 1261 requirements in order to satisfy the specific flight software system needs for the GEO satellite. From 2005 to 2006, the Air Force and Lockheed Martin conducted detailed requirements reviews that resulted in the delivery of flight software that was integrated into the satellite’s computers. In January 2007, the flight software underwent testing in a space representative environment called thermal vacuum testing and experienced a higher number of unexpected and unexplained failures. By April 2007, in additional tests, the number of problems escalated well beyond what was expected. At this time, Lockheed Martin notified DOD of the seriousness of the problem. From April 2007 to July 2007, the Air Force and Lockheed Martin analyzed the problems and developed two options: modify the existing software or redesign the software by simplifying the architecture, developing more software, and increasing the robustness of the fault management system. The Air Force chose to redesign the software architecture and began its work with Lockheed Martin on detailed software designs from September 2007 to December 2007. In March 2008, the new design underwent Incremental Design Review Block 1 and was approved by the program review board for the revised cost and schedule baseline. In April 2008, six independent review teams examined the Block 2 design during the Systems Engineering & Incremental Design Review and authorized the Air Force and Lockheed to proceed with formal software coding under the redesign. To mitigate the software problems, DOD has assessed various alternatives and developed an approach for implementing the software redesign effort and overseeing its development. DOD and the SBIRS contractor are taking steps to address problems, among others, with the original software architecture. DOD has redesigned the architecture, and is in the midst of developing additional software, and testing elements critical to the integration and test of systems. DOD has also undertaken several initiatives to improve its program oversight and to help it better manage the development, including addressing weaknesses in program management responsibility, accountability, and other areas. To address the software’s poor architectural design that ultimately resulted in the unexpected loss of telemetry and commanding for extended periods and unexpected hardware errors, a trade study was conducted by Lockheed Martin to examine options for redesign. Table 1 shows the trade study options considered, and recommendations made. As indicated in table 1, the trade study recommended a simplified architecture that places all the software applications on a single processor, processor “A”, rather than using distributed applications because it represents the best fit with system designs. Lockheed Martin officials stated that the simplified software architecture will address a number of areas that were problematic with the original design, such as the timing of stored programs that failed during thermal vacuum tests. Among other elements, the new design will involve the development of additional software that will also increase the robustness of the fault management system. Approved in April 2008, the new designs have undergone numerous reviews, the last of which was subjected to comprehensive and detailed examination involving six independent review teams. Teams comprised of personnel—from the Office of the Under Secretary of Defense for Acquisition, Technology, and Logistics; Aerospace Corporation, a federally funded research and development center (FFRDC); Lockheed Martin Corporate; Air Force Space and Missiles Systems Center Wing; and the Software Engineering Institute—evaluated the technical solutions, development approach, and readiness of the test facilities, among other elements. The objective of the design review was to authorize the start of formal software coding. For the incremental design review, independent review teams were provided detailed information about software issues on the original design, including the severity of the issues and the status of each. Other information included DOD’s approach in managing risk, resolution of critical issues, disposition of deficiency reports, requirements volatility, and integration with ground systems. Technical data included diagrams of the simplified architecture, operating system interface design, and lines of software code that would be impacted from earlier designs. Other information about the software included designs of subsystems, schematics, integration and delivery schedules, and productivity and sizing estimates. DOD is making progress to develop needed software and conduct tests of elements that are critical to the first satellite system, called GEO 1. For example, in June 2008, DOD held a design review on software for the fault management system that elicited concurrence from external stakeholders to proceed with coding activities. At the same time, they held a space technical interchange meeting that provided consensus on the methodology and a plan for complete space vehicle testing, including the flight software. In July 2008, Lockheed Martin delivered 63,000 of the projected 67,000 source lines of code for the space vehicle and ground software integration effort, including a database that provided data so that development efforts could continue on ground software and testing activities. According to Lockheed Martin, software development efforts followed a disciplined process, except in those cases where waivers were requested and granted by the software engineering process group. Figure 2 shows Lockheed Martin’s process for developing and qualifying flight software. DOD has taken steps to fund critical test bed resources that are needed to adequately test, model, analyze, and simulate software functions as a means to reduce integration and test risks, in response to lessons learned from the failed software that identified the need to add and upgrade their simulation and test bed resources. For example, an evaluation of the software problems found several contributory factors that prevented them from identifying the software problems earlier. These include: test beds that had matured in parallel with the flight software and hardware, making it difficult to distinguish between test bed and software issues; oversubscription of test beds and lack of simulation resources that precluded them from checking out high-risk areas (timing, and stored programs); and insufficient modeling of timing, and analysis of stored program implementation, which might have shed light earlier on lack of robustness. In May 2008, the additional test bed and simulator was brought online and is currently in use. DOD and Lockheed Martin have undertaken several initiatives to address areas of program risk, such as efforts to improve oversight of GEO 1 and flight software development. These include acting on recommendations made in an Independent Program Assessment (IPA) that was conducted to ensure the validity of the technical, cost, and schedule baselines. As part of the assessment, the IPA study assessed contractor performance, evaluated program risk areas, and made recommendations on where program improvements could be made. In November 2007, officials from the Air Force, Lockheed Martin, and Aerospace Corporation reported the IPA findings. Table 2 shows the IPA findings, recommendations, and status of implementation efforts.