LDCM Ground System. Network Lesson Learned

This slide presentation reviews the Landsat Data Continuity Mission (LDCM) and the lessons learned in implementing the network that was assembled to allow for the acquisition, archiving and distribution of the data from the Landsat mission. The objective of the LDCM is to continue the acquisition, archiving, and distribution of moderate-resolution multispectral imagery affording global, synoptic, and repetitive coverage of the earth's land surface at a scale where natural and human-induced changes can be detected, differentiated, characterized, and monitored over time. It includes a review of the ground network, including a block diagram of the ground network elements (GNE) and a review of the RF design and testing. Also included is a listing of the lessons learned

James Webb Space Telescope XML Database: From the Beginning to Today

The James Webb Space Telescope (JWST) Project has been defining, developing, and exercising the use of a common eXtensible Markup Language (XML) for the command and telemetry (C&T) database structure. JWST is the first large NASA space mission to use XML for databases. The JWST project started developing the concepts for the C&T database in 2002. The database will need to last at least 20 years since it will be used beginning with flight software development, continuing through Observatory integration and test (I&T) and through operations. Also, a database tool kit has been provided to the 18 various flight software development laboratories located in the United States, Europe, and Canada that allows the local users to create their own databases. Recently the JWST Project has been working with the Jet Propulsion Laboratory (JPL) and Object Management Group (OMG) XML Telemetry and Command Exchange (XTCE) personnel to provide all the information needed by JWST and JPL for exchanging database information using a XML standard structure. The lack of standardization requires custom ingest scripts for each ground system segment, increasing the cost of the total system. Providing a non-proprietary standard of the telemetry and command database definition formation will allow dissimilar systems to communicate without the need for expensive mission specific database tools and testing of the systems after the database translation. The various ground system components that would benefit from a standardized database are the telemetry and command systems, archives, simulators, and trending tools. JWST has exchanged the XML database with the Eclipse, EPOCH, ASIST ground systems, Portable spacecraft simulator (PSS), a front-end system, and Integrated Trending and Plotting System (ITPS) successfully. This paper will discuss how JWST decided to use XML, the barriers to a new concept, experiences utilizing the XML structure, exchanging databases with other users, and issues that have been experienced in creating databases for the C&T system

The OSIRIS-Rex Asteroid Sample Return: Mission Operations Design

The OSIRIS-REx mission employs a methodical, phased approach to ensure success in meeting the missions science requirements. OSIRIS-REx launches in September 2016, with a backup launch period occurring one year later. Sampling occurs in 2019. The departure burn from Bennu occurs in March 2021. On September 24, 2023, the SRC lands at the Utah Test and Training Range (UTTR). Stardust heritage procedures are followed to transport the SRC to Johnson Space Center, where the samples are removed and delivered to the OSIRIS-REx curation facility. After a six-month preliminary examination period the mission will produce a catalog of the returned sample, allowing the worldwide community to request samples for detailed analysis.Traveling and returning a sample from an Asteroid that has not been explored before requires unique operations consideration. The Design Reference Mission (DRM) ties together space craft, instrument and operations scenarios. The project implemented lessons learned from other small body missions: APLNEAR, JPLDAWN and ESARosetta. The key lesson learned was expected the unexpected and implement planning tools early in the lifecycle. In preparation to PDR, the project changed the asteroid arrival date, to arrive one year earlier and provided additional time margin. STK is used for Mission Design and STKScheduler for instrument coverage analysis

The Earth Based Ground Stations Element of the Lunar Program

The Lunar Architecture Team (LAT) is responsible for developing a concept for building and supporting a lunar outpost with several exploration capabilities such as rovers, colonization, and observatories. The lunar outpost is planned to be located at the Moon's South Pole. The LAT Communications and Navigation Team (C&N) is responsible for defining the network infrastructure to support the lunar outpost. The following elements are needed to support lunar outpost activities: A Lunar surface network based on industry standard wireless 802.xx protocols, relay satellites positioned 180 degrees apart to provide South Pole coverage for the half of the lunar 28-day orbit that is obscured from Earth view, earth-based ground stations deployed at geographical locations 120 degrees apart. This paper will focus on the Earth ground stations of the lunar architecture. Two types of ground station networks are discussed. One provides Direct to Earth (DTE) support to lunar users using Kaband 23/26Giga-Hertz (GHz) communication frequencies. The second supports the Lunar Relay Satellite (LRS) that will be using Ka-band 40/37GHz (Q-band). This paper will discuss strategies to provide a robust operational network in support of various lunar missions and trades of building new antennas at non-NASA facilities, to improve coverage and provide site diversification for handling rain attenuation

XTCE and XML Database Evolution and Lessons from JWST, LandSat, and Constellation

The database organizations within three different NASA projects have advanced current practices by creating database synergy between the various spacecraft life cycle stakeholders and educating users in the benefits of the Consultative Committee for Space Data Systems (CCSDS) XML Telemetry and Command Exchange (XTCE) format. The combination of XML for managing program data and CCSDS XTCE for exchange is a robust approach that will meet all user requirements using Standards and Non proprietary tools. COTS tools for XTCEKML are very wide and varied. To combine together various low cost and free tools can be more expensive in the long run than choosing a more expensive COTS tool that meets all the needs. This was especially important when deploying in 32 remote sites with no need for licenses. A common mission XTCEKML format between dissimilar systems is possible and is not difficult. Command XMLKTCE is more complex than telemetry and the use of XTCEKML metadata to describe pages and scripts is needed due to the proprietary nature of most current ground systems. Other mission and science products such as spacecraft loads, science image catalogs, and mission operation procedures can all be described with XML as well to increase there flexibility as systems evolve and change. Figure 10 is an example of a spacecraft table load. The word is out and the XTCE community is growing, The f ~ sXt TCE user group was held in October and in addition to ESAESOC, SC02000, and CNES identified several systems based on XTCE. The second XTCE user group is scheduled for March 10, 2008 with LDMC and others joining. As the experience with XTCE grows and the user community receives the promised benefits of using XTCE and XML the interest is growing fast

Standardization of XML Database Exchanges and the James Webb Space Telescope Experience

Personnel from the National Aeronautics and Space Administration (NASA) James Webb Space Telescope (JWST) Project have been working with various standard communities such the Object Management Group (OMG) and the Consultative Committee for Space Data Systems (CCSDS) to assist in the definition of a common extensible Markup Language (XML) for database exchange format. The CCSDS and OMG standards are intended for the exchange of core command and telemetry information, not for all database information needed to exercise a NASA space mission. The mission-specific database, containing all the information needed for a space mission, is translated from/to the standard using a translator. The standard is meant to provide a system that encompasses 90% of the information needed for command and telemetry processing. This paper will discuss standardization of the XML database exchange format, tools used, and the JWST experience, as well as future work with XML standard groups both commercial and government

James Webb Space Telescope - L2 Communications for Science Data Processing

JWST is the first NASA mission at the second Lagrange point (L2) to identify the need for data rates higher than 10 megabits per second (Mbps). JWST will produce approximately 235 Gigabits of science data every day that will be downlinked to the Deep Space Network (DSN). To get the data rates desired required moving away from X-band frequencies to Ka-band frequencies. To accomplish this transition, the DSN is upgrading its infrastructure. This new range of frequencies are becoming the new standard for high data rate science missions at L2. With the new frequency range, the issues of alternatives antenna deployment, off nominal scenarios, NASA implementation of the Ka-band 26 GHz, and navigation requirements will be discussed in this paper. JWST is also using Consultative Committee for Space Data Systems (CCSDS) standard process for reliable file transfer using CCSDS File Delivery Protocol (CFDP). For JWST the use of the CFDP protocol provides level zero processing at the DSN site. This paper will address NASA implementations of Ground Stations in support of Ka-band 26 GHz and lesson learned from implementing a file base (CFDP) protocol operational system

James Webb Space Telescope - Applying Lessons Learned to I&T

The James Webb Space Telescope (JWST) is part of a new generation of spacecraft acquiring large data volumes from remote regions in space. To support a mission such as the JWST, it is imperative that lessons learned from the development of previous missions such as the Hubble Space Telescope and the Earth Observing System mission set be applied throughout the development and operational lifecycles. One example of a key lesson that should be applied is that core components, such as the command and telemetry system and the project database, should be developed early, used throughout development and testing, and evolved into the operational system. The purpose of applying lessons learned is to reap benefits in programmatic or technical parameters such as risk reduction, end product quality, cost efficiency, and schedule optimization. In the cited example, the early development and use of the operational command and telemetry system as well as the establishment of the intended operational database will allow these components to be used by the developers of various spacecraft components such that development, testing, and operations will all use the same core components. This will reduce risk through the elimination of transitions between development and operational components and improve end product quality by extending the verification of those components through continual use. This paper will discuss key lessons learned that have been or are being applied to the JWST Ground Segment integration and test program

James Webb Space Telescope Ka-Band Trade

In August 2003 James Webb Space Telescope (JWST) had its Initial Review Confirmation Assessment Briefing with NASA HQ management. This is a major milestone as the project was approved to proceed from Phase A to B, and NASA will commit funds for the project towards meeting its science goals from the Earth-Sun s Lagrange 2 (L2) environment. At this briefing, the Project was asked, "to take another look" into using, the JPL s Deep Space Network (DSN) as the provider of ground stations and evaluate other ground station options. The current operations concept assumes S-band and X-band communications with a daily &hour contact using the DSN with the goal of transmitting over 250 Gigabit (Gb) of data to the ground. The Project has initiated a trade study to look at this activity, and we would like to share the result of the trade in the conference. Early concept trades tends to focus on the "normal" operation mode of supporting telemetry (science and engineering), command and radio metrics. Entering the design phase, we find that we have the unique ranging requirement for our L2 orbit using alternating ground stations located in different hemispheres. The trade must also address emergency operations (which are covered when using the DSN). This paper describes the issues confronting this Project and how the DSN and the JWST Project are working together to find an optimized approach for meeting these issues. We believe this trade is of major interest for future Code S and other L2 missions in that JWST will set the standard

Evolution of the Lunar Network

The National Aeronautics and Space Administration (NASA) is planning to upgrade its network Infrastructure to support missions for the 21st century. The first step is to increase the data rate provided to science missions to at least the 100 megabits per second (Mbps) range. This is under way, using Ka-band 26 Gigahertz (GHz), erecting an 18-meter antenna for the Lunar Reconnaissance Orbiter (LRO), and the planned upgrade of the Deep Space Network (DSN) 34-meter network to support the James Webb Space Telescope (JWST). The next step is the support of manned missions to the Moon and beyond. Establishing an outpost with several activities such as rovers, colonization, and observatories, is better achieved by using a network configuration rather than the current method of point-to-point communication. Another challenge associated with the Moon is communication coverage with the Earth. The Moon's South Pole, targeted for human habitat and exploration, is obscured from Earth view for half of the 28-day lunar cycle and requires the use of lunar relay satellites to provide coverage when there is no direct view of the Earth. The future NASA and Constellation network architecture is described in the Space Communications Architecture Working Group (SCAWG) Report. The Space Communications and Navigation (SCAN) Constellation Integration Project (SCIP) is responsible for coordinating Constellation requirements and has assigned the responsibility for implementing these requirements to the existing NASA communication providers: DSN, Space Network (SN), Ground Network (GN) and the NASA Integrated Services Network (NISN). The SCAWG Report provides a future architecture but does not provide implementation details. The architecture calls for a Netcentric system, using hundreds of 12-meter antennas, a ground antenna array, and a relay network around the Moon. The report did not use cost as a variable in determining the feasibility of this approach. As part of the SCIP Mission Concept Review and the second iteration of the Lunar Architecture Team (LAT), the focus is on cost, as well as communication coverage using operational scenarios. This approach maximizes use of existing assets and adds capability in small increments. This paper addresses architecture decisions such as the Radio Frequency (RF) signal and network (Netcentric) decisions that need to be made and the difficulty of implementing them into the existing Space Network and DSN. It discusses the evolution of the lunar system and describes its components: Tracking and Data Relay Satellite System (TDRSS), Earth-based ground stations, Lunar Relay, and surface systems