Multiple views of ground data system
Explore the source record for details and available documents.
SEARCH · Search NASA
Search indexed NASA NTRS and DOE OSTI research on propulsion, heat transfer, battery materials and energy systems. Follow report and document links to the original sources.
Quote a phrase for an exact phrase match. Source license links do not imply unrestricted reuse.
Explore the source record for details and available documents.
NASA's SPICE ancillary informaton system is used by engineers and scientists to capture and access a variety of engineering and other ancillary information throughout the mission lifecycle.
The Mission data Processing and Control Subsystem (MPCS) is being developed as a multi-mission Ground Data System with the Mars Science Laboratory (MSL) as the first fully supported mission. MPCS is a fully featured, Java-based Ground Data System (GDS) for telecommand and telemetry processing based on Configuration-Driven Development (CDD). The eXtensible Markup Language (XML) is the ideal language for CDD because it is easily readable and editable by all levels of users and is also backed by a World Wide Web Consortium (W3C) standard and numerous powerful processing tools that make it uniquely flexible. The CDD approach adopted by MPCS minimizes changes to compiled code by using XML to create a series of configuration files that provide both coarse and fine grained control over all aspects of GDS operation.
Common practice in the development of simulation systems is meeting all user requirements within a single instantiation. The Joint Polar Satellite System (JPSS) presents a unique challenge to establish a simulation environment that meets the needs of a diverse user community while also spanning a multi-mission environment over decades of operation. In response, the JPSS Flight Vehicle Test Suite (FVTS) is architected with an extensible infrastructure that supports the operation of multiple observatory simulations for a single mission and multiple mission within a common system perimeter. For the JPSS-1 satellite, multiple fidelity flight observatory simulations are necessary to support the distinct user communities consisting of the Common Ground System development team, the Common Ground System Integration & Test team, and the Mission Rehearsal Team/Mission Operations Team. These key requirements present several challenges to FVTS development. First, the FVTS must ensure all critical user requirements are satisfied by at least one fidelity instance of the observatory simulation. Second, the FVTS must allow for tailoring of the system instances to function in diverse operational environments from the High-security operations environment at NOAA Satellite Operations Facility (NSOF) to the ground system factory floor. Finally, the FVTS must provide the ability to execute sustaining engineering activities on a subset of the system without impacting system availability to parallel users. The FVTS approach of allowing for multiple fidelity copies of observatory simulations represents a unique concept in simulator capability development and corresponds to the JPSS Ground System goals of establishing a capability that is flexible, extensible, and adaptable.
NASA and its industry and international partners are embarking on a bold and inspiring development effort to design and build an exploration class space system. The space system is made up of the Orion system, the Space Launch System (SLS) and the Ground Systems Development and Operations (GSDO) system. All are highly coupled together and dependent on each other for the combined safety of the space system. A key area of system safety focus needs to be in the ground and flight application software system (GFAS). In the development, certification and operations of GFAS, there are a series of safety characteristics that define the approach to ensure mission success. This paper will explore and examine the safety characteristics of the GFAS development. The GFAS system integrates the flight software packages of the Orion and SLS with the ground systems and launch countdown sequencers through the 'agile' software development process. A unique approach is needed to develop the GFAS project capabilities within this agile process. NASA has defined the software development process through a set of standards. The standards were written during the infancy of the so-called industry 'agile development' movement and must be tailored to adapt to the highly integrated environment of human exploration systems. Safety of the space systems and the eventual crew on board is paramount during the preparation of the exploration flight systems. A series of software safety characteristics have been incorporated into the development and certification efforts to ensure readiness for use and compatibility with the space systems. Three underlining factors in the exploration architecture require the GFAS system to be unique in its approach to ensure safety for the space systems, both the flight as well as the ground systems. The first are the missions themselves, which are exploration in nature, and go far beyond the comfort of low Earth orbit operations. The second is the current exploration system will launch only one mission per year even less during its developmental phases. Finally, the third is the partnered approach through the use of many different prime contractors, including commercial and international partners, to design and build the exploration systems. These three factors make the challenges to meet the mission preparations and the safety expectations extremely difficult to implement. As NASA leads a team of partners in the exploration beyond earth's influence, it is a safety imperative that the application software used to test, checkout, prepare and launch the exploration systems put safety of the hardware and mission first. Software safety characteristics are built into the design and development process to enable the human rated systems to begin their missions safely and successfully. Exploration missions beyond Earth are inherently risky, however, with solid safety approaches in both hardware and software, the boldness of these missions can be realized for all on the home planet.
Missions have been proposed that will use multiple spacecraft to perform scientific or commercial tasks. Indeed, in the commercial world, some spacecraft constellations already exist. Aside from the technical challenges of constructing and flying these missions, there is also the financial challenge presented by the tradition model of the flight operations team (FOT) when it is applied to a constellation mission. Proposed constellation missions range in size from three spacecraft to more than 50. If the current ratio of three-to-five FOT personnel per spacecraft is maintained, the size of the FOT becomes cost prohibitive. The Advanced Architectures and Automation Branch at the Goddard Space Flight Center (GSFC Code 588) saw the potential to reduce the cost of these missions by creating new user interfaces to the ground system health-and-safety data. The goal is to enable a smaller FOT to remain aware and responsive to the increased amount of ground system information in a multi-spacecraft environment. Rather than abandon the tried and true, these interfaces were developed to run alongside existing ground system software to provide additional support to the FOT. These new user interfaces have been combined in a tool called REACH. REACH-the Real-time Evaluation and Analysis of Consolidated Health-is a software product that uses advanced visualization techniques to make spacecraft anomalies easy to spot, no matter how many spacecraft are in the constellation. REACH reads a real-time stream of data from the ground system and displays it to the FOT such that anomalies are easy to pick out and investigate. Data visualization has been used in ground system operations for many years. To provide a unique visualization tool, we developed a unique source of data to visualize: the REACH Health Model Engine. The Health Model Engine is rule-based software that receives real-time telemetry information and outputs "health" information related to the subsystems and spacecraft that the telemetry belong to. The Health Engine can run out-of-the-box or can be tailored with a scripting language. Out of the box, it uses limit violations to determine the health of subsystems and spacecraft; when tailored, it determines health using equations combining the values and limits of any telemetry in the spacecraft. The REACH visualizations then "roll up" the information from the Health Engine into high level, summary displays. These summary visualizations can be "zoomed" into for increasing levels of detail. Currently REACH is installed in the Small Explorer (SMEX) lab at GSFC, and is monitoring three of their five spacecraft. We are scheduled to install REACH in the Mid-sized Explorer (MIDEX) lab, which will allow us to monitor up to six more spacecraft. The process of installing and using our "research" software in an operational environment has provided many insights into which parts of REACH are a step forward and which of our ideas are missteps. Our paper explores both the new concepts in spacecraft health-and-safety visualization, the difficulties of such systems in the operational environment, and the cost and safety issues of multi-spacecraft missions.
The SMM attitude ground support system (AGSS) supports the acquisition of spacecraft roll attitude reference, performs the in-flight calibration of the attitude sensor complement, supports onboard control autonomy via onboard computer data base updates, and monitors onboard computer (OBC) performance. Initial roll attitude acquisition is accomplished by obtaining a coarse 3 axis attitude estimate from magnetometer and Sun sensor data and subsequently refining it by processing data from the fixed head star trackers. In-flight calibration of the attitude sensor complement is achieved by processing data from a series of slew maneuvers designed to maximize the observability and accuracy of the appropriate alignments and biases. To ensure autonomy of spacecraft operation, the AGSS selects guide stars and computes sensor occultation information for uplink to the OBC. The onboard attitude control performance is monitored on the ground through periodic attitude determination and processing of OBC data in downlink telemetry. In general, the control performance has met mission requirements. However, software and hardware problems have resulted in sporadic attitude reference losses.
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.
Handbook for contamination control of aerospace ground fluid systems and portable equipment
Development of unified test equipment concept for space shuttle ground support system
This paper discusses an exploration of approaches to providing ground data system support by NASA/Goddard Space Flight Center for scientific missions. Two architecture concepts are identified to provide full support using a mission specific instantiation concept, with distributed client-server architecture. The alternatives are assessed for impact to operations, and for hardware and software sizing. Evaluation benefits and risks is also provided.
The Mission Design and Navigation (MDNAV) Section at the Jet Propulsion Laboratory (JPL) supports many deep space and earth orbiting missions from formulation to end of mission operations. The requirements of these missions are met with a multimission approach to MDNAV ground data system (GDS) infrastructure capable of being shared and allocated in a seamless and consistent manner across missions. The MDNAV computing infrastructure consists of compute clusters, network attached storage, mission support area facilities, and desktop hardware. The multimission architecture allows these assets, and even personnel, to be leveraged effectively across the project lifecycle and across multiple missions simultaneously. It provides a more robust and capable infrastructure to each mission than might be possible if each constructed its own. It also enables a consistent interface and environment within which teams can conduct all mission analysis and navigation functions including: trajectory design; ephemeris generation; orbit determination; maneuver design; and entry, descent, and landing analysis. The savings of these efficiencies more than offset the costs of increased complexity and other challenges that had to be addressed: configuration management, scheduling conflicts, and competition for resources. This paper examines the benefits of the multimission MDNAV ground data system infrastructure, focusing on the hardware and software architecture. The result is an efficient, robust, scalable MDNAV ground data system capable of supporting more than a dozen active missions at once.
Space Telescope can generate multidimensional image data, very similar in nature to data produced with microdensitometers. An overview is presented of the ST science ground system between carrying out the observations and the interactive analysis of preprocessed data. The ground system elements used in data archival and retrieval are described and operational procedures are discussed. Emphasis is given to aspects of the ground system that are relevant to the science user and to general principles of system software development in a production environment. While the system being developed uses relatively conservative concepts for the launch baseline, concepts were developed to enhance the ground system. This includes networking, remote access, and the utilization of alternate data storage technologies.
This paper presents one JPL systems engineer's approach to describing a complex, multi-mission Ground Data System (GDS) using multiple, concurrent architectural views.
A set of considerations that are pertinent to future international cooperation in the area of synthetic aperture radar (SAR) ground data systems are presented. The considerations are as follows: (1) success of future spaceborne SAR missions will require multi-agency and/or multi-national collaboration; (2) ground processing is typically performed by each agency for their user base; (3) international standards are required to achieve a uniform data product independent of the processing center; (4) to reduce the aggregate cost of the ground data systems, collaboration is required in design and development; (5) effective utilization of the data by an international user community; (6) commercialization of data products; and (7) security of data systems.
A test technique was developed to assess various grounding system concepts used for mobile facilities. The test technique involves applying a high current pulse to the grounding system with the proper waveshape and magnitude to simulate a lightning return stroke. Of concern were the step voltages present along the ground near the point of lightning strike. Step voltage is equated to how fast the current pulse is dissipated by the grounding system. The applied current pulse was produced by a high current capacitor bank with a total energy content of 80 kilojoules. A series of pulse tests were performed on two types of mobile facility grounding systems. One system consisted of an array of four 10 foot copper clad steel ground rods connected by 1/0 gauge wire. The other system was an array of 10 inch long tapered ground rods, strung on stainless steel cable. The focus here is on the pulse test technique used and its relevance to actual lightning strike conditions.
Airbreathing/Rocket combined-cycle, and specifically rocket-based combined- cycle (RBCC), propulsion systems, typically employ an internal engine flow-path installed primary rocket subsystem. To achieve acceptably short mixing lengths in effecting the "air augmentation" process, a large rocket-exhaust/air interfacial mixing surface is needed. This leads, in some engine design concepts, to a "cluster" of small rocket units, suitably arrayed in the flowpath. To support an early (1964) subscale ground-test of a specific RBCC concept, such a 12-rocket cluster was developed by NASA's Marshall Space Flight Center (MSFC). The small primary rockets used in the cluster assembly were modified versions of an existing small kerosene/oxygen water-cooled rocket engine unit routinely tested at MSFC. Following individual thrust-chamber tests and overall subsystem qualification testing, the cluster assembly was installed at the U. S. Air Force's Arnold Engineering Development Center (AEDC) for RBCC systems testing. (The results of the special air-augmented rocket testing are not covered here.) While this project was eventually successfully completed, a number of hardware integration problems were met, leading to catastrophic thrust chamber failures. The principal "lessons learned" in conducting this early primary rocket subsystem experimental effort are documented here as a basic knowledge-base contribution for the benefit of today's RBCC research and development community.
This paper presents basic network control concepts for the Advanced Communications Technology Satellite (ACTS) System. Two experimental systems, called the low-burst-rate and high-burst-rate systems, along with ACTS ground system features, are described. The network control issues addressed include frame structures, acquisition and synchronization procedures, coordinated station burst-time plan and satellite-time plan changes, on-board clock control based on ground drift measurements, rain fade control by means of adaptive forward-error-correction (FEC) coding and transmit power augmentation, and reassignment of channel capacities on demand. The NASA ground system, which includes a primary station, diversity station, and master control station, is also described.