Search NASA⌕ Search

SEARCH · Search NASA

Results for “Ground Systems”

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.

At least 235 records · Page 13
All sourcesNASA NTRSDOE OSTI
NASA NTRS2008

Moving Away from Ones and Zeros, Designing a Ground Data System Based on Higher Levels of Abstraction

Previous JPL ground systems have been designed with the Ground Data System (GDS) engineer in mind. The focus on these systems has been on packaging and delivery of low level information (frames, packets, telemetry values) to the end user. It was not that long ago when project teams would be huddled over a workstation, examining crude displays of telemetry bits organized in various ways, trying to determine the status of a spacecraft. Understanding the data often required additional levels of GDS expertise, or worse, transformation of the raw data into alternative formats followed by ingestion into other tools so that the data became meaningful. The primary focus was often to answer these types of questions: "Why did this particular frame fail Reed-Solomon decode? Why did this packet get marked as invalid? Why am I missing a block of telemetry from my query?" -- which are completely valid questions to ask from a GDS Engineer's point of view, and large families of tools have been designed to help answer these questions. But these are not the questions that most users care about - which are more like: "Why is the battery state of charge trending down? Show me a summary image report for the last traverse to the target. Show me a data accountability summary for the last DSN pass." Answers to these questions, which are what users are looking for, requires a higher level of abstraction and supporting tools than mining through ones and zeros. JPL has created a next generation capability called the Mission Data Processing and Control System (MPCS) which is designed to support this higher level of abstraction by providing customizable views of the ground system combining collections of lower level information into more meaningful ways. Instead of examining frames, packets, and individual telemetry data points -- MPCS is capable of providing comprehensive summary reports, product status, overall flight/ground event status, as well as payload health summaries. Based on these higher level views, end users can make tactical or strategic decisions, or drop into detailed analysis as needed. System designers need to continue building systems that support low level GDS troubleshooting - but the basic design of a GDS should be geared towards what end users actually need to see. This paper will describe the capabilities of MPCS that directly support these higher levels of abstraction, and which are being used today in missions such as the Mars Science Laboratory and other NASA missions.

MPCS↗
NASA NTRS1994

Customizing the JPL Multimission Ground Data System: Lessons learned

The Multimission Ground Data System (MGDS) at NASA's Jet Propulsion Laboratory has brought improvements and new technologies to mission operations. It was designed as a generic data system to meet the needs of multiple missions and avoid re-inventing capabilities for each new mission and thus reduce costs. It is based on adaptable tools that can be customized to support different missions and operations scenarios. The MGDS is based on a distributed client/server architecture, with powerful Unix workstations, incorporating standards and open system architectures. The distributed architecture allows remote operations and user science data exchange, while also providing capabilities for centralized ground system monitor and control. The MGDS has proved its capabilities in supporting multiple large-class missions simultaneously, including the Voyager, Galileo, Magellan, Ulysses, and Mars Observer missions. The Operations Engineering Lab (OEL) at JPL has been leading Customer Adaptation Training (CAT) teams for adapting and customizing MGDS for the various operations and engineering teams. These CAT teams have typically consisted of only a few engineers who are familiar with operations and with the MGDS software and architecture. Our experience has provided a unique opportunity to work directly with the spacecraft and instrument operations teams and understand their requirements and how the MGDS can be adapted and customized to minimize their operations costs. As part of this work, we have developed workstation configurations, automation tools, and integrated user interfaces at minimal cost that have significantly improved productivity. We have also proved that these customized data systems are most successful if they are focused on the people and the tasks they perform and if they are based upon user confidence in the development team resulting from daily interactions. This paper will describe lessons learned in adapting JPL's MGDS to fly the Voyager, Galileo, and Mars Observer missions. We will explain how powerful, existing ground data systems can be adapted and packaged in a cost effective way for operations of small and large planetary missions. We will also describe how the MGDS was adapted to support operations within the Galileo Spacecraft Testbed. The Galileo testbed provided a unique opportunity to adapt MGDS to support command and control operations for a small autonomous operations team of a handful of engineers flying the Galileo Spacecraft flight system model.

Murphy, Susan C.↗
NASA NTRS2010

MOS 2.0: The Next Generation in Mission Operations Systems

A Mission Operations System (MOS) or Ground System constitutes that portion of an overall space mission Enterprise that resides here on Earth. Over the past two decades, technological innovations in computing and software technologies have allowed an MOS to support ever more complex missions while consuming a decreasing fraction of Project development budgets. Despite (or perhaps, because of) such successes, it is routine to hear concerns about the cost of MOS development. At the same time, demand continues for Ground Systems which will plan more spacecraft activities with fewer commanding errors, provide scientists and engineers with more autonomous functionality, process and manage larger and more complex data more quickly, all while requiring fewer people to develop, deploy, operate and maintain them. One successful approach to such concerns over this period is a multimission approach, based on the reuse of portions (most often software) developed and used in previous missions. The Advanced Multi-Mission Operations System (AMMOS), developed for deep-space science missions, is one successful example of such an approach. Like many computing-intensive systems, it has grown up in a near-organic fashion from a relatively simple set of tools into a complexly interrelated set of capabilities. Such systems, like a city lacking any concept of urban planning, can and will grow in ways that are neither efficient nor particularly easy to sustain. To meet the growing demands and unyielding constraints placed on ground systems, a new approach is necessary. Under the aegis of a multi-year effort to revitalize the AMMOS's multimission operations capabilities, we are utilizing modern practices in systems architecting and model-based engineering to create the next step in Ground Systems: MOS 2.0. In this paper we outline our work (ongoing and planned) to architect and design a multimission MOS 2.0, describe our goals and measureable objectives, and discuss some of the benefits that this top-down, architectural approach holds for creating a more flexible and capable MOS for Missions while holding the line on cost.

ground systems↗
NASA NTRS1997

The SEL Adapts to Meet Changing Times

Since 1976, the Software Engineering Laboratory (SEL) has been dedicated to understanding and improving the way in which one NASA organization, the Flight Dynamics Division (FDD) at Goddard Space Flight Center, develops, maintains, and manages complex flight dynamics systems. It has done this by developing and refining a continual process improvement approach that allows an organization such as the FDD to fine-tune its process for its particular domain. Experimental software engineering and measurement play a significant role in this approach. The SEL is a partnership of NASA Goddard, its major software contractor, Computer Sciences Corporation (CSC), and the University of Maryland's (LTM) Department of Computer Science. The FDD primarily builds software systems that provide ground-based flight dynamics support for scientific satellites. They fall into two sets: ground systems and simulators. Ground systems are midsize systems that average around 250 thousand source lines of code (KSLOC). Ground system development projects typically last 1 - 2 years. Recent systems have been rehosted to workstations from IBM mainframes, and also contain significant new subsystems written in C and C++. The simulators are smaller systems averaging around 60 KSLOC that provide the test data for the ground systems. Simulator development lasts up to 1 year. Most of the simulators have been built in Ada on workstations. The SEL is responsible for the management and continual improvement of the software engineering processes used on these FDD projects.

Pajerski, Rose S.↗
NASA NTRS1982

Aircraft interrogation and display system: A ground support equipment for digital flight systems

A microprocessor-based general purpose ground support equipment for electronic systems was developed. The hardware and software are designed to permit diverse applications in support of aircraft flight systems and simulation facilities. The implementation of the hardware, the structure of the software, describes the application of the system to an ongoing research aircraft project are described.

Glover, R. D.↗
NASA NTRS2006

Zero to Integration in Eight Months, the Dawn Ground Data System Engineering Challange

The Dawn Project has presented the Ground Data System (GDS) with technical challenges driven by cost and schedule constraints commonly associated with National Aeronautics and Space Administration (NASA) Discovery Projects. The Dawn mission consists of a new and exciting Deep Space partnership among: the Jet Propulsion Laboratory (JPL), responsible for project management and flight operations; Orbital Sciences Corporation (OSC), spacecraft builder and responsible for flight system test and integration; and the University of California, at Los Angeles (UCLA), responsible for science planning and operations. As a cost-capped mission, one of Dawn s implementation strategies is to leverage from both flight and ground heritage. OSC's ground data system is used for flight system test and integration as part of the flight heritage strategy. Mission operations, however, are to be conducted with JPL s ground system. The system engineering challenge of dealing with two heterogeneous ground systems emerged immediately. During the first technical interchange meeting between the JPL s GDS Team and OSC's Flight Software Team, August 2003, the need to integrate the ground system with the flight software was brought to the table. This need was driven by the project s commitment to enable instrument engineering model integration in a spacecraft simulator environment, for both demonstration and risk mitigation purposes, by April 2004. This paper will describe the system engineering approach that was undertaken by JPL's GDS Team in order to meet the technical challenge within a non-negotiable eight-month schedule. Key to the success was adherence to an overall systems engineering process and fundamental systems engineering practices: decomposition of the project request into manageable requirements; definition of a structured yet flexible development process; integration of multiple ground disciplines and experts into a focused team effort; in-process risk management; and aggregation of the intermediate products to an integrated final product. In addition, this paper will highlight the role of lessons learned from the integration experience. The lessons learned from an early GDS deployment have served as the foundation for the design and implementation of the Dawn Ground Data System.

systems engineering↗
NASA NTRS2006

Zero to Integration in Eight Months, the Dawn Ground Data System Engineering Challenge

The Dawn Project has presented the Ground Data System (GDS) with technical challenges driven by cost and schedule constraints commonly associated with National Aeronautics and Space Administration (NASA) Discovery Projects. The Dawn mission consists of a new and exciting Deep Space partnership among: the Jet Propulsion Laboratory (JPL), manages the project and is responsible for flight operation; Orbital Sciences Corporation (OSC), is the spacecraft builder and is responsible for flight system test and integration; and the University of California, at Los Angeles (UCLA), is responsible for science planning and operations. As a cost-capped mission, one of Dawn's implementation strategies is to leverage from both flight and ground heritage. OSC's ground data system is used for flight system test and integration as part of the flight heritage strategy. Mission operations, however, are to be conducted with JPL's ground system. The system engineering challenge of dealing with two heterogeneous ground systems emerged immediately. During the first technical interchange meeting between the JPL's GDS Team and OSC's Flight Software Team, August 2003, the need to integrate the ground system with the flight software was brought to the table. This need was driven by the project's commitment to enable instrument engineering model integration in a spacecraft simulator environment, for both demonstration and risk mitigation purposes, by April 2004. This paper will describe the system engineering approach that was undertaken by JPL's GDS Team in order to meet the technical challenge within a non-negotiable eight-month schedule. Key to the success was adherence to fundamental systems engineering practices: decomposition of the project request into manageable requirements; integration of multiple ground disciplines and experts into a focused team effort; definition of a structured yet flexible development process; definition of an in-process risk reduction plan; and aggregation of the intermediate products to an integrated final product. In addition, this paper will highlight the role of lessons learned from the integration experience. The lessons learned from an early GDS deployment have served as the foundation for the design and implementation of the Dawn Ground Data System.

Ground Data System (GDS)↗
NASA NTRS1987

Design and initial application of the extended aircraft interrogation and display system: Multiprocessing ground support equipment for digital flight systems

A pipelined, multiprocessor, general-purpose ground support equipment for digital flight systems has been developed and placed in service at the NASA Ames Research Center's Dryden Flight Research Facility. The design is an outgrowth of the earlier aircraft interrogation and display system (AIDS) used in support of several research projects to provide engineering-units display of internal control system parameters during development and qualification testing activities. The new system, incorporating multiple 16-bit processors, is called extended AIDS (XAIDS) and is now supporting the X-29A forward-swept-wing aircraft project. This report describes the design and mechanization of XAIDS and shows the steps whereby a typical user may take advantage of its high throughput and flexible features.

Glover, Richard D.↗
NASA NTRS2006

Transforming Our SMEX Organization by Way of Innovation, Standardization, and Automation

NASA's Small Explorer (SMEX) Flight Operations Team (FOT) is currently tackling the challenge of supporting ground operations for several satellites that have surpassed their designed lifetime and have a dwindling budget. At Goddard Space Flight Center (GSFC), these missions are presently being reengineered into a fleet-oriented ground system. When complete, this ground system will provide command and control of four SMEX missions, and will demonstrate fleet automation and control concepts as a pathfinder for additional mission integrations. A goal of this reengineering effort is to demonstrate new ground-system technologies that show promise of supporting longer mission lifecycles and simplifying component integration. In pursuit of this goal, the SMEX organization has had to examine standardization, innovation, and automation. A core technology being demonstrated in this effort is the GSFC Mission Services Evolution Center (GMSEC) architecture. The GMSEC architecture focuses on providing standard interfaces for ground system applications to promote application interoperability. Building around commercial Message Oriented Middleware and providing a common messaging standard allows GMSEC to provide the capabilities necessary to support integration of new software components into existing missions and increase the level of interaction within the system. For SMS, GMSEC has become the technology platform to transform flight operations with the innovation and automation necessary to reduce operational costs. The automation technologies supported in SMEX are built upon capabilities provided by the GMSEC architecture that allows the FOT to further reduce the involvement of the console, operator. Initially, SMEX is automating only routine operations, such as safety and health monitoring, basic commanding, and system recovery. The operational concepts being developed here will reduce the need for staffed passes and are a necessity for future fleet management. As this project continues to evolve, additional innovations beyond GMSEC and automation have, and will continue to be developed. The team developed techniques for migrating ground systems of existing on-orbit assets. The tools necessary to monitor and control software failures were integrated and tailored for operational environments. All this was done with a focus of extending fleet operations to mission beyond SMU. The result of this work is the foundation for a broader fleet-capable ground system that will include several missions supported by the Space Science Mission Operations Project.

Madden, Maureen↗
NASA NTRS1974

Space shuttle/food system study. Volume 2, Appendix G: Ground support system analysis. Appendix H: Galley functional details analysis

The capabilities for preflight feeding of flight personnel and the supply and control of the space shuttle flight food system were investigated to determine ground support requirements; and the functional details of an onboard food system galley are shown in photographic mockups. The elements which were identified as necessary to the efficient accomplishment of ground support functions include the following: (1) administration; (2) dietetics; (3) analytical laboratories; (4) flight food warehouse; (5) stowage module assembly area; (6) launch site module storage area; (7) alert crew restaurant and disperse crew galleys; (8) ground food warehouse; (9) manufacturing facilities; (10) transport; and (11) computer support. Each element is discussed according to the design criteria of minimum cost, maximum flexibility, reliability, and efficiency consistent with space shuttle requirements. The galley mockup overview illustrates the initial operation configuration, food stowage locations, meal assembly and serving trays, meal preparation configuration, serving, trash management, and the logistics of handling and cleanup equipment.

Source record↗
NASA NTRS2006

Telemetry Metrics: Monitoring Data Quality in the Spacecraft Ground Data System

During the launch of Mars Odyssey, ground data system (GDS) engineers experienced a glitch in the ground data system that caused us to re-evaluate how we looked at spacecraft telemetry, particularly during the spacecraft development period and for critical spacecraft events in flight. Spacecraft telemetry told the subsystem and instrument engineers about the health and status of the spacecraft, but there was surprisingly little information about how well the ground data system was doing in getting information from the spacecraft to the engineers.The problem for the Mars Odyssey launch was with a single channel not updating as often as expected. Spacecraft engineers considered calling off the Launch but eventually decided that this particular channel did not provide information that was crucial for launch. It was only after the post launch acquisition of the Odyssey signal that ground data system engineers heard there had been a concern about the channel....

Mars↗
NASA NTRS1994

International Space Station Alpha user payload operations concept

International Space Station Alpha (ISSA) will accommodate a variety of user payloads investigating diverse scientific and technology disciplines on behalf of five international partners: Canada, Europe, Japan, Russia, and the United States. A combination of crew, automated systems, and ground operations teams will control payload operations that require complementary on-board and ground systems. This paper presents the current planning for the ISSA U.S. user payload operations concept and the functional architecture supporting the concept. It describes various NASA payload operations facilities, their interfaces, user facility flight support, the payload planning system, the onboard and ground data management system, and payload operations crew and ground personnel training. This paper summarizes the payload operations infrastructure and architecture developed at the Marshall Space Flight Center (MSFC) to prepare and conduct ISSA on-orbit payload operations from the Payload Operations Integration Center (POIC), and from various user operations locations. The authors pay particular attention to user data management, which includes interfaces with both the onboard data management system and the ground data system. Discussion covers the functional disciplines that define and support POIC payload operations: Planning, Operations Control, Data Management, and Training. The paper describes potential interfaces between users and the POIC disciplines, from the U.S. user perspective.

Schlagheck, Ronald A.↗
NASA NTRS1974

Simulation of 4D RNAV in the terminal area

A terminal area control concept based on 4D RNAV (3D plus time) has been developed to take full advantage of STOL aircrafts' unique performance capabilities. The 4D RNAV concept involves an airborne system, a ground system and a protocol for information exchange between aircraft and ground. The function of the airborne system is to synthesize the curved three dimensional (3D) flight path, to predict and control the landing time (4D) and to generate flight director or autopilot commands. The airborne system assumes the ground system will specify the 3D path and assign a conflict-free landing time. A real time simulation of this concept has been developed to evaluate its effectiveness for terminal areas control of STOL aicraft. Key elements of the simulation are a computer graphics traffic display, a scheduling display and a keyboard language for issuing controller commands to simulated aircraft. Initial results and planned experiments are described.

Tobias, L.↗
NASA NTRS2021

On-demand Command and Control of ASTERIA with Cloud-based Ground Station Services

ASTERIA (Arcsecond Space Telescope Enabling Research in Astrophysics) was a 6-unit CubeSat technology demonstration mission that deployed from the International Space Station on November 20th, 2017. After successfully completing its 90-day primary mission that demonstrated arcsecond-level line-of-sight pointing and focal plane thermal stability for exoplanet detection, it entered an extended mission performing onboard software demonstrations to mature technology both in space and on the ground. One of the technologies was a completely cloud-based ground system leveraging Amazon Web Services (AWS) Ground Station service.Announced in December 2018 and launched in May 2019, AWS Ground Station is a fully managed ground station service that aims to reduce the overhead associated with developing and maintaining ground system infrastructure throughout the mission lifecycle. AWS Ground Station makes available the suite of features required for any ground system in support of low-Earth orbit (LEO) and medium-Earth Orbit (MEO) satellite operations on-demand and without setting up or maintaining long-term contracts. Charges are incurred on a per-minute basis for antenna usage during scheduled tracks. Support is available for S-band uplink and downlink, along with X-band narrowband and wideband downlink. Missions that use the service may reserve tracks with any licensed AWS Ground Station antennas located across each service region and have direct access to any AWS services in support of mission operations.The cloud-based architecture built around the AWS Ground Station service greatly enhanced ASTERIA mission operations by enabling end-to-end pass automation, on-demand contact scheduling and contingency planning, along with more efficient data downlink through station availability and station-to-station handovers. It incorporated open-source software, particularly NASA's AMMOS Instrument Toolkit (AIT) and Open Mission Control Technologies (OpenMCT), along with the AWS application programming interfaces (API) to the Ground Station, Elastic Compute Cloud (EC2) and Simple Storage Service (S3) services. After showcasing operability in August 2019, the team continued using and improving this novel ground system architecture until the end of mission in December 2019. This paper describes the cloud-based ground system, how it was designed, tested, and evaluated with an in-orbit spacecraft, the operational capabilities that it enabled, along with lessons learned and recommendations for future missions.

Fesq, Lorraine↗