Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “Ground System”

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 469 records · Page 26
All sourcesNASA NTRSDOE OSTI
NASA NTRS1943

NACA Radio Ground-Speed System for Aircraft, Special Report

A method that utilizes the Doppler effect on radio signals for determining the speed of an airplane and the distance traveled by the airplane has been developed and found to operate satisfactorily. In this method, called the NACA radio ground-speed system, standard readily available radio equipment is used almost exclusively and extreme frequency stability of the transmitters is not necessary. No complicated equipment need be carried in the airplane, as the standard radio transmitter is usually adequate. Actual flight tests were made in which the method was used and the results were consistent with calibrated air speed indications and stop-watch measurements. Inasmuch as the fundamental accuracy of the radio method is far better than either of the checking systems used, no check was made on the limitations of the accuracy.

Hastings, Charles E.↗
NASA NTRS1994

Mission Operations Centers (MOCs): Integrating key spacecraft ground data system components

In an environment characterized by decreasing budgets, limited system development time, and user needs for increased capabilities, the Mission Operations Division (MOD) at the National Aeronautics and Space Administration Goddard Space Flight Center initiated a new, cost-effective concept in developing its spacecraft ground data systems: the Mission Operations Center (MOC). In the MOC approach, key components are integrated into a comprehensive and cohesive spacecraft planning, monitoring, command, and control system with a single, state-of-the-art graphical user interface. The MOD is currently implementing MOC's, which feature a common, reusable, and extendable system architecture, to support the X-Ray Timing Explorer (XTE), Tropical Rainfall Measuring Mission (TRMM), and Advanced Composition Explorer (ACE) missions. As a result of the MOC approach, mission operations are integrated, and users can, with a single system, perform real-time health and safety monitoring, real-time command and control, real-time attitude processing, real-time and predictive graphical spacecraft monitoring, trend analysis, mission planning and scheduling, command generation and management, network scheduling, guide star selection, and (using an expert system) spacecraft monitoring and fault isolation. The MOD is also implementing its test and training simulators under the new MOC management structure. This paper describes the MOC concept, the management approaches used in developing MOC systems, the technologies employed and the development process improvement initiatives applied in implementing MOC systems, and the expected benefits to both the user and the mission project in using the MOC approach.

Harbaugh, Randy↗
NASA NTRS2008

Navigation Ground Data System Engineering for the Cassini/Huygens Mission

The launch of the Cassini/Huygens mission on October 15, 1997, began a seven year journey across the solar system that culminated in the entry of the spacecraft into Saturnian orbit on June 30, 2004. Cassini/Huygens Spacecraft Navigation is the result of a complex interplay between several teams within the Cassini Project, performed on the Ground Data System. The work of Spacecraft Navigation involves rigorous requirements for accuracy and completeness carried out often under uncompromising critical time pressures. To support the Navigation function, a fault-tolerant, high-reliability/high-availability computational environment was necessary to support data processing. Configuration Management (CM) was integrated with fault tolerant design and security engineering, according to the cornerstone principles of Confidentiality, Integrity, and Availability. Integrated with this approach are security benchmarks and validation to meet strict confidence levels. In addition, similar approaches to CM were applied in consideration of the staffing and training of the system administration team supporting this effort. As a result, the current configuration of this computational environment incorporates a secure, modular system, that provides for almost no downtime during tour operations.

Beswick, R. M.↗
NASA NTRS2017

Development of Telecommunications Systems and Ground Support for EM-1 Interplanetary Cubesats Missions: Lunar IceCube and LunaH-Map

CubeSats are now providing an innovative way to explore space: they can be built by smaller teams in academic environments, and they generally require smaller budget than traditional missions. For this reason, a new trend has emerged in the last five years: interplanetary CubeSats. Interplanetary CubeSats take advantage of the CubeSat paradigm and of the availability of commercial components developed for Low Earth Orbit (LEO) missions, but they are specifically designed to explore deep space. As a result, interplanetary CubeSats are essentially very different from Low Earth Orbit CubeSats in at least three technological areas: propulsion, radiation tolerance and telecommunication. This paper is focused on telecommunication issues for interplanetary CubeSats which face harsher environments, longer path distances and have more navigation needs than the LEO CubeSats. For this reason, the design of telecommunication systems for interplanetary missions is extremely challenging and significant development is currently ongoing in the areas of radio design, antenna design and the design of ground support architectures. This presentation focuses on the design of the telecommunication and ground support systems for two of the interplanetary CubeSats missions that will be launched on NASA’s Space Launch System (SLS) Exploration Mission-1 (EM-1): Lunar IceCube and LunaH-Map. Given the commonalities between these missions, an effort is underway at JPL to develop a common set of telecommunication hardware systems to fit the envelope of the two missions’ goals. Additionally, Lunar IceCube and LunaH-Map will also share the use of the Deep Space Network antennas and of the Morehead State University 21 m station, which is currently being upgraded especially for this purpose. This presentation will provide a quick overview of the missions (including goals and telecommunication requirements) and it will also focus on the development of the telecommunication systems design with a particular focus on the current upgrades planned to the Morehead State University ground station.

Babuscia, Alessandra↗
NASA NTRS2014

Automating the SMAP Ground Data System to Support Lights-Out Operations

The Soil Moisture Active Passive (SMAP) Mission is a first tier mission in NASA's Earth Science Decadal Survey. SMAP will provide a global mapping of soil moisture and its freeze/thaw states. This mapping will be used to enhance the understanding of processes that link the terrestrial water, energy, and carbon cycles, and to enhance weather and forecast capabilities. NASA's Jet Propulsion Laboratory has been selected as the lead center for the development and operation of SMAP. The Jet Propulsion Laboratory (JPL) has an extensive history of successful deep space exploration. JPL missions have typically been large scale Class A missions with significant budget and staffing. SMAP represents a new area of JPL focus towards low cost Earth science missions. Success in this new area requires changes to the way that JPL has traditionally provided the Mission Operations System (MOS)/Ground Data System (GDS) functions. The operation of SMAP requires more routine operations activities and support for higher data rates and data volumes than have been achieved in the past. These activities must be addressed by a reduced operations team and support staff. To meet this challenge, the SMAP ground data system provides automation that will perform unattended operations, including automated commanding of the SMAP spacecraft.

GDS↗
NASA NTRS1995

The Adaptation of Industrial Protocols for a Space Messaging Service

A standard data system interface for space data systems will have a major impact on the cost of building spacecraft and the ground systems built to support their operation. Properly designed, a standard interface will provide a 'plug-and-play' environment for the construction of spacecraft and ground systems. Using the standard, commercial vendors of spacecraft devices, spacecraft instrumentation and ground support systems could build and market products that would be installed without the traditional software development effort.

Industrial Protocols↗
NASA NTRS2011

Evaluating Cloud Computing in the Proposed NASA DESDynI Ground Data System

The proposed NASA Deformation, Ecosystem Structure and Dynamics of Ice (DESDynI) mission would be a first-of-breed endeavor that would fundamentally change the paradigm by which Earth Science data systems at NASA are built. DESDynI is evaluating a distributed architecture where expert science nodes around the country all engage in some form of mission processing and data archiving. This is compared to the traditional NASA Earth Science missions where the science processing is typically centralized. What's more, DESDynI is poised to profoundly increase the amount of data collection and processing well into the 5 terabyte/day and tens of thousands of job range, both of which comprise a tremendous challenge to DESDynI's proposed distributed data system architecture. In this paper, we report on a set of architectural trade studies and benchmarks meant to inform the DESDynI mission and the broader community of the impacts of these unprecedented requirements. In particular, we evaluate the benefits of cloud computing and its integration with our existing NASA ground data system software called Apache Object Oriented Data Technology (OODT). The preliminary conclusions of our study suggest that the use of the cloud and OODT together synergistically form an effective, efficient and extensible combination that could meet the challenges of NASA science missions requiring DESDynI-like data collection and processing volumes at reduced costs.

Benchmark↗
NASA NTRS1992

ANOPP/VMS HSCT ground contour system

This viewgraph shows the integration of the Visual Motion Simulator with ANOPP. ANOPP is an acronym for the Aircraft NOise Prediction Program. It is a computer code consisting of dedicated noise prediction modules for jet, propeller, and rotor powered aircraft along with flight support and noise propagation modules, all executed under the control of an executive system. The Visual Motion Simulator (VMS) is a ground based motion simulator with six degrees of freedom. The transport-type cockpit is equipped with conventional flight and engine-thrust controls and with flight instrument displays. Control forces on the wheel, column, and rudder pedals are provided by a hydraulic system coupled with an analog computer. The simulator provides variable-feel characteristics of stiffness, damping, coulomb friction, breakout forces, and inertia. The VMS provides a wide range of realistic flight trajectories necessary for computing accurate ground contours. The NASA VMS will be discussed in detail later in this presentation. An equally important part of the system for both ANOPP and VMS is the engine performance. This will also be discussed in the presentation.

Rawls, John, Jr.↗
NASA NTRS1983

Upper Atmosphere Research Satellite (UARS) trade analysis

The Upper Atmosphere Research Satellite (UARS) which will collect data pertinent to the Earth's upper atmosphere is described. The collected data will be sent to the central data handling facility (CDHF) via the UARS ground system and the data will be processed and distributed to the remote analysis computer systems (RACS). An overview of the UARS ground system is presented. Three configurations were developed for the CDHF-RACS system. The CDHF configurations are discussed. The IBM CDHF configuration, the UNIVAC CDHF configuration and the vax cluster CDHF configuration are presented. The RACS configurations, the IBM RACS configurations, UNIVAC RACS and VAX RACS are detailed. Due to the large on-line data estimate to approximately 100 GB, a mass storage system is considered essential to the UARS CDHF. Mass storage systems were analyzed and the Braegan ATL, the RCA optical disk, the IBM 3850 and the MASSTOR M860 are discussed. It is determined that the type of mass storage system most suitable to UARS is the automated tape/cartridge device. Two devices of this type, the IBM 3850 and the MASSTOR MSS are analyzed and the applicable tape/cartridge device is incorporated into the three CDHF-RACS configurations.

Fox, M. M.↗
NASA NTRS2005

Increasing the Automation and Autonomy for Spacecraft Operations with Criteria Action Table

The Criteria Action Table (CAT) is an automation tool developed for monitoring real time system messages for specific events and processes in order to take user defined actions based on a set of user-defined rules. CAT was developed by Lockheed Martin Space Operations as a part of a larger NASA effort at the Goddard Space Flight Center (GSFC) to create a component-based, middleware-based, and standard-based general purpose ground system architecture referred as GMSEC - the GSFC Mission Services Evolution Center. CAT has been integrated into the upgraded ground systems for Tropical Rainfall Measuring Mission (TRMM) and Small Explorer (SMEX) satellites and it plays the central role in their automation effort to reduce the cost and increase the reliability for spacecraft operations. The GMSEC architecture provides a standard communication interface and protocol for components to publish/describe messages to an information bus. It also provides a standard message definition so components can send and receive messages to the bus interface rather than each other, thus reducing the component-to-component coupling, interface, protocols, and link (socket) management. With the GMSEC architecture, components can publish standard event messages to the bus for all nominal, significant, and surprising events in regard to satellite, celestial, ground system, or any other activity. In addition to sending standard event messages, each GMSEC compliant component is required to accept and process GMSEC directive request messages.

Li, Zhen-Ping↗
NASA NTRSDate not supplied

MOC Automation with GMSEC and the Generic Extendable Message Utility (GEMU)

Automation has become critical for ground systems, improving efficiency and reliability while reducing costs across mission operations. The Goddard Mission Services Evolution Center (GMSEC) software suite has played a significant role in enabling this automation, leveraging its publish/subscribe paradigm through a message bus architecture to facilitate seamless communication and data flow. Historically, the GMSEC suite, through components like Criteria Action Table (CAT) has been pivotal in automating ground system capabilities. However, as technology advances, limitations in automation with CAT have emerged, creating an opportunity to enhance ground system automation through the introduction of GEMU. This new GMSEC component brings new capabilities and addresses specific automation constraints that CAT could not overcome, allowing for more sophisticated, flexible, and efficient message processing. GEMU, at its core, is designed to accelerate the development of custom GMSEC-compliant applications. It enables users to construct automated message processing pipelines quickly, supporting both drag-and-drop web-based configuration and scripting through a simple domain-specific language. This advancement not only simplifies the process but also reduces the time needed for implementing automated solutions. This presentation will outline GEMU’s potential value in improving mission operations automation. It will highlight the benefits of transitioning from CAT to GEMU and offer insights into how GEMU can drive operational efficiencies. We will also provide an overview of the automation capabilities of GEMU and its potential impact on mission operations centers (MOCs).

GMSEC↗
NASA NTRS1991

ALLY: An operator's associate for satellite ground control systems

The key characteristics of an intelligent advisory system is explored. A central feature is that human-machine cooperation should be based on a metaphor of human-to-human cooperation. ALLY, a computer-based operator's associate which is based on a preliminary theory of human-to-human cooperation, is discussed. ALLY assists the operator in carrying out the supervisory control functions for a simulated NASA ground control system. Experimental evaluation of ALLY indicates that operators using ALLY performed at least as well as they did when using a human associate and in some cases even better.

Bushman, J. B.↗
NASA NTRS2004

Transitioning to Intel-based Linux Servers in the Payload Operations Integration Center

The MSFC Payload Operations Integration Center (POIC) is the focal point for International Space Station (ISS) payload operations. The POIC contains the facilities, hardware, software and communication interface necessary to support payload operations. ISS ground system support for processing and display of real-time spacecraft and telemetry and command data has been operational for several years. The hardware components were reaching end of life and vendor costs were increasing while ISS budgets were becoming severely constrained. Therefore it has been necessary to migrate the Unix portions of our ground systems to commodity priced Intel-based Linux servers. hardware architecture including networks, data storage, and highly available resources. This paper will concentrate on the Linux migration implementation for the software portion of our ground system. The migration began with 3.5 million lines of code running on Unix platforms with separate servers for telemetry, command, Payload information management systems, web, system control, remote server interface and databases. The Intel-based system is scheduled to be available for initial operational use by August 2004 The overall migration to Intel-based Linux servers in the control center involves changes to the This paper will address the Linux migration study approach including the proof of concept, criticality of customer buy-in and importance of beginning with POSlX compliant code. It will focus on the development approach explaining the software lifecycle. Other aspects of development will be covered including phased implementation, interim milestones and metrics measurements and reporting mechanisms. This paper will also address the testing approach covering all levels of testing including development, development integration, IV&V, user beta testing and acceptance testing. Test results including performance numbers compared with Unix servers will be included. need for a smooth transition while maintaining real-time support. An important aspect of the paper will involve challenges and lessons learned. product compatibility, implications of phasing decisions and tracking of dependencies, particularly non- software dependencies. The paper will also discuss scheduling challenges providing real-time flight support during the migration and the requirement to incorporate in the migration changes being made simultaneously for flight support. This paper will also address the deployment approach including user involvement in testing and the , This includes COTS product compatibility, implications of phasing decisions and tracking of dependencies, particularly non- software dependencies. The paper will also discuss scheduling challenges providing real-time flight support during the migration and the requirement to incorporate in the migration changes being made simultaneously for flight support.

Guillebeau, P. L.↗
NASA NTRS1994

Designing an autonomous environment for mission critical operation of the EUVE satellite

Since the launch of NASA's Extreme Ultraviolet Explorer (EUVE) satellite in 1992, there has only been a handful of occurrences that have warranted manual intervention in the EUVE Science Operations Center (ESOC). So, in an effort to reduce costs, the current environment is being redesigned to utilize a combination of off-the-shelf packages and recently developed artificial intelligence (AI) software to automate the monitoring of the science payload and ground systems. The successful implementation of systemic automation would allow the ESOC to evolve from a seven day/week, three shift operation, to a seven day/week one shift operation. First, it was necessary to identify all areas considered mission critical. These were defined as follows: (1) The telemetry stream must be monitored autonomously and anomalies identified. (2) Duty personnel must be automatically paged and informed of the occurrence of an anomaly. (3) The 'basic' state of the ground system must be assessed. (4) Monitors should check that the systems and processes needed to continue in a 'healthy' operational mode are working at all times. (5) Network loads should be monitored to ensure that they stay within established limits. (6) Connectivity to Goddard Space Flight Center (GSFC) systems should be monitored as well, not just for connectivity of the network itself but also for the ability to transfer files. (7) All necessary peripheral devices should be monitored. This would include the disks, routers, tape drives, printers, tape carousel, and power supplies. (8) System daemons such as the archival daemon, the Sybase server, the payload monitoring software, and any other necessary processes should be monitored to ensure that they are operational. (9) The monitoring system needs to be redundant so that the failure of a single machine will not paralyze the monitors. (10) Notification should be done by means of looking though a table of the pager numbers for current 'on call' personnel. The software should be capable of dialing out to notify, sending email, and producing error logs. (11) The system should have knowledge of when real-time passes and tape recorder dumps will occur and should know that these passes and data transmissions are successful. Once the design criteria were established, the design team split into two groups: one that addressed the tracking, commanding, and health and safety of the science payload and another group that addressed the ground systems and communications aspects of the overall system.

Abedini, Annadiana↗