Selection of the Ground Segment for the Next Generation Space Telescope (NGST) Flight Demonstrator (Nexus) Jonathan GaI-Edd National Aeronautics and Space Administration (NASA), Code 581 Goddard Space Flight Center (GSFC), Greenbelt, MD 20771 Fax." 301-286- 5719 Jonathan. S.Gal-Edd. 1@g._fc. nasa.gov Jane A. Steck National Aeronautics and Space Administration (NASA), Code 584 Goddard Space Flight Center (GSFC), Greenbelt, MD 20771 Fax." 301-286-1766 Jane.A.Steck. 1@gsfc. nasa.go v John C. isaacs, !ii Space Telescope Science Institute 3700 San Martin Drive, Baltimore, MD 21218 Fax: 410-338-1592 [email protected] Martin J. Bredeck National Science Foundation 4201 Wi&on Blvd, Room 455, Arlington, VA 22230 Fax: 703-292-9146 mbredeck@nsfgov Curtis Clyde Fatig Orbital Systems Corporation Code 440. 8/HST/Building 14 Fax: 301-286-03 71 Curtis. C.Fatig. 1@gsfc. nasa.gov Robert H. Zepp Computer Sciences Corporation 7515 Mission Drive, Lanham, AID 20706 Fax: 301-805-3 745 Robert. H.Zepp. 1@gsfc. nasa.gov NGST Selection of the Ground Segment for the Next Generation Space Telescope (NGST) Flight Demonstrator (Nexus) ABSTRACT. Nexus was a technology demonstrator project that was designed to bridge from the Hubble Space Telescope (HST) to its successor, the Next Generation Space Telescope (NGST). This paper focuses on the process used in designing the ground segment for Nexus and the lessons learned in its development. Ground station cost drivers were, (I) Contact time, (2) Cost of transporting data between the ground stations and control center, and (3) Cost savings via ground automation. We found that reducing the communication requirement in just the first 100 days could have reduced the total ground station cost by 40%. Contact time cost dwarfed the cost trade between automation development and off-shift operations personnel. Real-time Telemetry and Control (T&C) system analysis was divided into (1) Potential reuse of the Nexus real-time T&C system for NGST, (2) Feasibility of using a "Finite State-Based Modeling" product, and (3) Selecting a Commercial Off the Shelf (COTS) versus Government Off The Shelf (GOTS) products. We found that each of the products evaluated in detail (ASIST, EPOCH 2000, and ITOS) could adequately support basic mission requirements. Lessons learned were, (1) Include operations at the beginning of the mission, and (2) Develop an operations concept as soon as possible. Table of Contents 1. Overview: Nexus and NGST 2. Ground Station Costs 2.1. Contact Time and Associated Costs 2.1. I. Ground Stations: Commercial versus Government 2.2. Cost of Transporting Data Between the Ground Stations and Control Center 2.3. Cost Savings via Ground Automation 3. Selection of aReal-Time Telemetry and Command (T&C) System 3.1. Reuse of the Nexus real-time T&C system for NGST 3.2. Feasibility of Using a "Finite State-Based Modeling" Product 3.3. COTS versus GOTS Products 3.3.1. COTS versus GOTS Phase One Evaluation 3.3.2. COTS versus GOTS Phase Two Evaluation 3.4. Use of the Same Real-Time T&C System from Component Development through Operations 4. Development Facilities, Testing Labs and Simulations Support 5. Conclusions: Ground System Cost Factors I. Overview: Nexus and NGST The Next Generation Space Telescope (NGST) is a large aperture space telescope designated to succeed the Hubble Space Telescope (HST). NGST will continue the HST tradition of advancing breakthroughs in our understanding of the origins of the earliest stars, galaxies, and very elements that are the foundations of Life. We expect the costs for NGST to be reduced substantially from those for HST since NGST will not require Shuttle Mission servicing (it will maintain an orbit around L2, the second Lagrange point). Our goal for the NGST ground segment is to reduce the cost to between 50% and 75% compared to HST. A technology demonstrator project called Nexus was planned for 2005, and was to be a smaller scale telescope than NGST, designed to test telescope deployment and optical stability, the Wave Front Sensing and Control process, and sunshield thermal performance (see Figure 1). Goddard Space Flight Center (GSFC) and the Space Telescope Science Institute (STScI) were jointly developing the Nexus ground system. Due to a re-scope of NGST, Nexus was cancelled in December 2000. Many of the concepts and analyses from the Nexus effort are directly applicable to NGST. We are currently engaged in evaluation and recommendation of a real-time Telemetry and Command (T&C) system for the NGST ground system. This paper focuses on the process we used to select a real-time system for Nexus and the lessons learned indeveloping the Nexus ground system. Selection of the Ground Segment for the Next Generation Space Telescope (NGST) Flight Demonstrator (Nexus) Nexus is the Logical Step Between Technology Developments... •AMSD Cryo Mirrors .WFS&C .Deployment .Sunshield .Detectors •Industrial IR&D ...Government and Industry System Studies... .Designs .Metrology -Integration •Operations ,( ...Management and Process... _L "Cost .Schedule .Teaming ...and the Flight of NGST NASA concepts for Nexus and NGST _hown to _ame ,_cale Figure 1. Nexus Ground Technology and Spacecraft Components Link to NGST 2. Ground Station Costs NASA decided to move away from owning ground stations and toward using commercial centers. NASA did this hoping that commercial carriers would reduce the cost of ground stations. Overall, since NASA is currently not supplying the space-to-ground link infrastructure, it is no longer a low cost item for missions. NASA should consider supplying the space-to-ground link infrastructure to its own and other United States Government missions at no cost. It is our finding that the objectives of low cost missions that include ground segments cannot be met without this support. The ground station costs can be divided into three segments: • Contact time and associated costs • Cost of transporting data between the ground stations and control center • Cost savings via ground automation Selection of the Ground Segment for the Next Generation Space Telescope (NGST) Flight Demonstrator (Nexus) 2.1 Contact Time and Associated Costs In determining ground system costs driven by an initial operations concept, it came as a surprise to us that ground stations budgets dominated the concept, and even impacted spacecraft requirements. The operations contact scenarios (see Figure 2.) were the primary cost driver for the entire ground system. The large cost of the ground stations exceeded the combined cost of the real-time ground systems and support personnel. This was largely driven by requests for ground station support time that did not reduce risk but allowed personnel to observe spacecraft activities in real-time. This push was toward lower risk in spite of the low mission cost requirements. The Nexus Flight Software, typical of most spacecraft software, was designed to put the spacecraft in "safe" condition when an anomaly occurs. Real-time links maintained during critical activities allowed for quicker recovery from anomalies, but in almost all cases did not prevent the need for recovery. Ground stations support was narrowed to two organizations: • Deep Space Network (DSN-CSOC) 26-meter antenna • Universal Space Network (USN) 13-meter antenna Early in the Nexus design development, S-band forward transmissions to a low-gain, omni spacecraft antenna were found to be unsupportable from a 13-meter ground antenna. A larger, high-gain antenna was included on Nexus to enable coverage of the S-band forward RF link during normal operations. The S-band forward to the low-gain omni antenna was still needed due to high-gain antenna pointing uncertainty during contingency operations; hence, the larger DSN-CSOC antenna was then required for contingencies. The costs for more powerful S-band transponders, revised energy budgets, and other spacecraft design considerations limited the amount of cost savings that could be achieved on the ground. To allow for smaller antennas, the ground costs also placed data rate limitations on the payload. 2.1.1 Ground Stations: Commercial versus Government DSN-CSOC and USN were evaluated for Nexus. Other options and commercial providers were initially considered, but were discounted due to limited availability, limited resources, or excessive cost. DSN-CSOC costs were higher than the commercial network in all comparison cases. This can be attributed to the larger antennas used by DSN- CSOC, and the large number of users requesting these antenna services. While Nexus had only a contingency requirement for these large antennas, options for smaller antennas at a lower cost did not exist. The DSN-CSOC cost over the Nexus one-year mission life was 33% higher than the USN cost. USN was able to keep costs down by providing a smaller antenna and having the Nexus Project depend on DSN-CSOC for contingency operations. The overall cost for both systems could have been dramatically lowered by reducing the initial "24 hours/day, 7 days/week" communications requirement. In just the first 100 days, reducing the communication requirement to times of deployment, instrument calibration, and experimental data gathering could have reduced the total ground station cost for the entire mission by 40%. 2.2 Cost of Transporting Data between the Ground Stations and Control Center The ground network between the ground stations and the control center was another cost which was underestimated during the preliminary mission design phase. Further, the cost of the network between the various labs and spacecraft Integration & Test (l&T) facilities was not in any of the early budget calculations. In the NASA era of full cost accounting for all services, these network costs will "nickel & dime" a project to death. To reduce the transmission cost from the ground stations to the control center, the Nexus concept was to decode science data at the ground site before transmission to the control center. This reduced the total bandwidth needed. Selection of the Ground Segment for the Next Generation Space Telescope (NGST) Flight Demonstrator (Nexus) Also, the use of CCSDS virtual channel assignments allowed Nexus to only transmit critical data in real-time to the control center. Remaining data would be transmitted as bandwidth became available. One item still to be explored is to use the existing, open Internet to transmit non-critical data. Using the open lnternet has many advantages in trying to meet the low cost objectives. Encryption, digital signatures, and other data security measures can be used to protect proprietary data. 2.3 Cost Savings via Ground Automation A Nexus requirement for ground system automation did not result in significant savings. The broadly stated requirement was at odds with the objectives of low cost development and low cost operations. At the program level of Nexus, contact time cost dwarfed the cost trade between automation development and off-shift operations personnel. Automation to collect and store telemetry at the ground station would have been more cost effective than personnel reductions or unattended operations within the Nexus control center. Automation of the Nexus control center required a longer mission lifetime or cost sharing across multiple programs to be affordable. Shuttle Initial Release(cid:0)Burn Coast and Coast and Phase _ _ _ _ Emergency Nominal ions WSC WSC JPL DSN USN USN NISN-GSFC Control Center The same physical line isused to Nexus Flight communicate with the various Control Dynamics command and telemetry sites: Center Facility .ISC, tISC, DSN and I;SN Figure 2. Ground Station Support for Nexus Mission Phases Selection of the Ground Segment for the Next Generation Space Telescope (NGST) Flight Demonstrator (Nexus) 3. Selection of aReal-Time Telemetry and Command System A low cost, low risk ground system was needed to balance the costs and risks of the Nexus demonstration spacecraft. A real-time T&C processing component was central to the ground system design. This section provides details on the trade study we conducted to select an existing T&C component. The real-time T&C analysis was divided into three segments: • Reuse of the Nexus real-time T&C system for NGST • Feasibility of using a "Finite State-Based Modeling" product • Commercial Off the Shelf(COTS) versus Government Off The Shelf (GOTS) products 3.1 Reuse of the Nexus real-time T&C system for NGST We decided to select the Nexus real-time T&C system separately from the NGST ground system, even though some operational concepts were expected to carry over. The Nexus mission's one year duration is quite short when compared to 10-15 years for NGST. Selection of a ground system in 2001 for use in the 2009 NGST mission seemed premature. 3.2 Feasibility of Using a "Finite State-Based Modeling" Product As part of new technology research, and doing business in a new way, we proposed using a Finite State Modeling (FSM) system for Nexus. It was necessary to consider the advisability of switching basic operation paradigms from traditional telemetry to FSM. Initial findings indicated that higher costs would be incurred up front with lower maintenance and upgrade costs in the out-years. However, using a FSM system with the required up-front work during development and testing was a substantial undertaking and not cost-beneficial for a short mission. We found that GSFC had, on three previous occasions, attempted to use FSM as an add-on to operations and it never resulted in areduction in cost. 3.3 COTS versus GOTS Products A third early decision centered on the relative merits of COTS versus packaged GOTS T&C components. The spacecraft and flight software development groups at GSFC tasked with building the spacecraft were most familiar with locally developed GOTS T&C components, some of which were also available in COTS form. This familiarity was expected to translate directly into lower development costs due to process/tool reuse and lower spacecraft integration and test risks. A specific issue in the GOTS analysis was whether to select the HST Vision 2000 Command and Control System (CCS) solution as the T&C component. The STScI personnel we expected to operate Nexus already had operational familiarity with the CCS system. COTS solutions offered development independence from other GSFC missions, less development effort using a packaged product, and more operations features (particularly in the area of automation for lights-dim or lights-out operation). It soon became clear that the COTS versus GOTS issue was less important than the complexity and capability of the various candidate T&C components, and the relative development cost. These became the ultimate criteria for evaluation. 3.3.1 COTS versus GOTS Phase One Evaluation In Phase One of the process, we identified candidate products and evaluated them on key criteria related to capability, cost, performance, and risk. The evaluation data were collected through mission manager interviews with NASA/GSFC, JHU/APL, the USAF, and through COTS vendor interviews as well as COTS demonstrations at vendor sites. 6 Selection of the Ground Segment for the Next Generation Space Telescope (NGST) Flight Demonstrator (Nexus) The products selected for Phase One evaluation were: • Altairis MCS (FSM, COTS) Altair Aerospace Corporation • ASIST (GOTS) NASA/GSFC Code 584 • HST Vision 2000 CCS (GOTS) NASA/GSFC Code 442 • ECLIPSE (COTS) Raytheon Corporation • EPOCH 2000 (COTS) Integral Systems Incorporated • ITOS (GOTS) NASA/GSFC Code 584 • SCL (FSM, COTS) Interface and Control Systems Four of these products were eliminated here: two were based on FSM, and cost and complexity eliminated another two. ASIST, EPOCH 2000, and ITOS were selected for detailed evaluation in Phase Two. 3.3.2 COTS versus GOTS Phase Two Evaluation Experience gained during Phase One interviews was used to focus the baseline real-time T&C requirements and operations concept. In Phase Two evaluation, we sought answers to the following questions: l. Will each product, as delivered, meet basic mission requirements? These were the following: Provides necessary functional capabilities Supports Development, I&T and Operations mission phases Supports operational concepts including Shuttle launch, L2 orbit, and automation for lights-dim operations Supports desired PC-based H/W platform Compatible with planned DSN/USN Ground Station environment including CCSDS compliance Enables operator productivity with an intuitive, user-friendly interface and available tools Is mature; at least one previous mission Is stable, according to the experience of other users Is maintainable (based on open source or responsive vendor), has limited dependencies on other COTS, and has well-defined APIs for future expansion Is affordable incost/benefit terms, with an upper limit on cost 2. What isthe estimated cost and effort needed to modify each product to meet any of these requirements that itcurrently fails to meet? . What additional features does each product offer that might do any of the following? Increase ground system usability Decrease risk - Decrease cost Phase Two evaluation was performed using specific criteria to support the baseline mission in detail. Phase Two products were installed at GSFC for an extensive hands-on, side-by-side comparison. Each vendor provided integration support and responded to evaluator questions, and the results for each product were discussed with the vendor to minimize misunderstandings. We found that each of the products (ASIST, EPOCH 2000 and ITOS) could adequately support basic mission requirements. Each product required a minimal configuration effort and only a small enhancement effort to meet all of the baseline requirements. We were searching for real-time T&C components that supported Nexus "right out of the box," and found several to choose from. The development of the operations concept in parallel with the T&C component evaluation allowed us to focus on interfaces and broad capabilities. Side-by-side operation of the Selection of the Ground Segment for the Next Generation Space Telescope (NGST) Flight Demonstrator (Nexus) competing products allowed direct comparisons of capabilities despite their differing design approaches. Had we entered the evaluation and selection process with less flexibility, we would likely have required significant additional functionality in each product, resulting in higher software development costs. We would like to thank NASA Code 584 and Integral Systems Incorporated for their support of our side-by-side evaluation. 3.4 Use of the Same Real-Time T&C System from Component Development through Operations One of the cost-saving concepts for the Nexus ground system was to use the same real-time T&C system beginning with component development and continuing through flight operations. A similar approach has been used on the ACE, NEAR, and TIMED missions with encouraging success. With the use of the same T&C system, lifecycle operations costs can be reduced by combining I&T and flight operations team responsibilities into a single, integrated team. Common functions performed by this team include: • Developing and validating the databases of spacecraft telemetry and commands • Developing procedures to be used during the mission • Building display pages for the mission • Configuration Management of the various items • Training of the Flight and Experimenter teams Using a common database for a seamless transition from the start of flight software development through the end of the mission would provide additional cost-saving. Such a database would reduce system tool learning curves and eliminate the repetition of providing the end database product. For NGST, the common database approach would also provide additional benefits in support of multiple, geographically distributed institutions. Reuse of the real-time T&C system fit well in the Nexus mission schedule since the time planned for operations was relatively short. NGST will be a much longer mission than Nexus. The historic lifecycles of operating systems, computer hardware, and software are far shorter than the lifecycie of the NGST I&T and mission phases. Our challenge is to find components that can be translated easily so that NGST is not tied to using 1990 technology in 2010. 4. Development Facilities_ Testing Labs and Simulations Support The development and testing of the Nexus spacecraft required the coordinated efforts of a large number of engineers working in a number of facilities (see Figure 3). As the spacecraft schedule was developed, we were surprised to count 14 separate facilities that required a real-time T&C ground system. Additional integration and environmental test facilities were identified that required real-time T&C ground systems but could re-use systems which had already been procured for other facilities. This distributed approach to development and testing made the number of test facilities, and the resulting number of real-time T&C ground systems they required, an important cost issue. The overall cost to procure the real-time T&C ground systems was dominated by the number of facilities receiving such systems, rather than the relative cost of each instance of the three candidates. The total cost to procure the systems to support I&T was far larger than the cost to procure the systems to support flight operations. The proliferation of separate testing facilities confers some benefits in making the mission schedule less dependent on critical hardware or facilities. Additional facilities can also increase costs due to the need for additional simulations and test equipment and the potential for unnecessary test duplication. Fewer shared testing facilities would reduce ground system procurement costs. Shared testing facilities also have the potential to encourage increased collaboration among spacecraft developers. Selection of the Ground Segment for the Next Generation Space Telescope (NGST) Flight Demonstrator (Nexus) Another major cost issue for testing facilities is represented by the simulators needed to adequately test spacecraft components before launch. We found that the fidelity of simulators could be addressed in terms of cost versus simulator fidelity, but the tradeoffbetween simulator fidelity and program level risk was poorly understood. Spacecraft Component Ground S/W (Development, Qualification, and 1_ BothH/Wand migrate OTA Actuator i (D/Q) / PROP RF (D/Q) ' (D Q) (D/Q) _D/Q) I I Only Flight tt/W mt_qrate,_' 0.....-t ,.r) I _ Flight S/W (Development & Maintenance) --t I- (D&M) I I IPE FSW (D&M) C&DH FSW Integration &Testing (D&M) --+ j t ACS FSW (D&M) O&_ Shutae o&'r) t PSE FSW Both H/W and Ground S/W migrate Both H/W and S/W remain Figure 3. Distribution of Nexus Real-Time T&C System Hardware and Software 9 Selection of the Ground Segment for the Next Generation Space Telescope (NGST) Flight Demonstrator (Nexus) 5. Conclusions: Ground System Cost Factors Ground system operations should be considered a key component during mission development. The cost trades between spacecraft and ground components, which can decrease the total cost of the entire project, should be determined as early in the design phase as possible. Significant lessons learned regarding ground station costs are the following: • Ground station cost, contact schedule and length of contact are the most expensive elements in the ground segment. • Length of ground station contact time during the various mission phases should be defined as part of a risk assessment as well as cost. • Having an operation cost target in the beginning helped us with leverage over the other disciplines. For example, the use of the 13-meter antenna made the Command and Data Handling (C&DH) group focus on their downlink requirements • The operations scenario for the first 100 days of Nexus (deployment) differed from nominal operations. Deployment deserved more extensive analysis with regard to navigation and telescope instruments. An example is the Nexus telescope, nominally used to view dim objects, was required during deployment of the telescope mirrors to use bright stars for calibration and alignment. This raised competing telescope detector requirements. • The open lnternet should be considered for use in non-critical data delivery since higher rates drive up ground data line requirements. When data are downlinked during the weekend it is often acceptable to delay examination until Monday. Nexus required data delivery within 20 minutes of receipt on the ground. The true need of data delivery desires should be challenged to assure that real requirements are met. Desires that exceed requirements will drive ground network costs dramatically upward. Use of the same real-time T&C system to support component development through flight operations is desirable for a mission with a short Operations lifecycle such as Nexus. For the Nexus mission we found the following to be true: • Many real-time T&C systems available as COTS or GOTS can do the job (this ismore of a preference than a cost item) • Savings from the use of the same real-time T&C system for component development through flight operations can be overshadowed by the costs from the number of labs and facilities. 10