Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “Ground Support 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 649 records · Page 36
All sourcesNASA NTRSDOE OSTI
NASA NTRS1994

ELISA, a demonstrator environment for information systems architecture design

This paper describes an approach of reusability of software engineering technology in the area of ground space system design. System engineers have lots of needs similar to software developers: sharing of a common data base, capitalization of knowledge, definition of a common design process, communication between different technical domains. Moreover system designers need to simulate dynamically their system as early as possible. Software development environments, methods and tools now become operational and widely used. Their architecture is based on a unique object base, a set of common management services and they host a family of tools for each life cycle activity. In late '92, CNES decided to develop a demonstrative software environment supporting some system activities. The design of ground space data processing systems was chosen as the application domain. ELISA (Integrated Software Environment for Architectures Specification) was specified as a 'demonstrator', i.e. a sufficient basis for demonstrations, evaluation and future operational enhancements. A process with three phases was implemented: system requirements definition, design of system architectures models, and selection of physical architectures. Each phase is composed of several activities that can be performed in parallel, with the provision of Commercial Off the Shelves Tools. ELISA has been delivered to CNES in January 94, currently used for demonstrations and evaluations on real projects (e.g. SPOT4 Satellite Control Center). It is on the way of new evolutions.

Panem, Chantal↗
NASA NTRS1990

The environmental control and life support system advanced automation project. Phase 1: Application evaluation

The Environmental Control and Life Support System (ECLSS) is a Freedom Station distributed system with inherent applicability to advanced automation primarily due to the comparatively large reaction times of its subsystem processes. This allows longer contemplation times in which to form a more intelligent control strategy and to detect or prevent faults. The objective of the ECLSS Advanced Automation Project is to reduce the flight and ground manpower needed to support the initial and evolutionary ECLS system. The approach is to search out and make apparent those processes in the baseline system which are in need of more automatic control and fault detection strategies, to influence the ECLSS design by suggesting software hooks and hardware scars which will allow easy adaptation to advanced algorithms, and to develop complex software prototypes which fit into the ECLSS software architecture and will be shown in an ECLSS hardware testbed to increase the autonomy of the system. Covered here are the preliminary investigation and evaluation process, aimed at searching the ECLSS for candidate functions for automation and providing a software hooks and hardware scars analysis. This analysis shows changes needed in the baselined system for easy accommodation of knowledge-based or other complex implementations which, when integrated in flight or ground sustaining engineering architectures, will produce a more autonomous and fault tolerant Environmental Control and Life Support System.

Dewberry, Brandon S.↗
NASA NTRS1988

Development of an integrated set of research facilities for the support of research flight test

The Ames-Dryden Flight Research Facility (DFRF) serves as the site for high-risk flight research on many one-of-a-kind test vehicles like the X-29A advanced technology demonstrator, F-16 advanced fighter technology integration (AFTI), AFTI F-111 mission adaptive wing, and F-18 high-alpha research vehicle (HARV). Ames-Dryden is on a section of the historic Muroc Range. The facility is oriented toward the testing of high-performance aircraft, as shown by its part in the development of the X-series aircraft. Given the cost of research flight tests and the complexity of today's systems-driven aircraft, an integrated set of ground support experimental facilities is a necessity. In support of the research flight test of highly advanced test beds, the DFRF is developing a network of facilities to expedite the acquisition and distribution of flight research data to the researcher. The network consists of an array of experimental ground-based facilities and systems as nodes and the necessary telecommunications paths to pass research data and information between these facilities. This paper presents the status of the current network, an overview of current developments, and a prospectus on future major enhancements.

Moore, Archie L.↗
NASA NTRS1988

Development of an integrated set of research facilities for the support of research flight test

The Ames-Dryden Flight Research Facility (DFRF) serves as the site for the conduct of high-risk flight research on many one-of-a-kind test vehicles like the X-29A advanced technology demonstrator, F-16 advanced fighter technology integration (AFTI), AFTI F-111 mission adaptive wing, and F-18 high-alpha research vehicle (HARV). Ames-Dryden is on a section of the historic Muroc Range. The facility is oriented toward the testing of high-performance aircraft, as shown by its part in the development of the X-series aircraft. Given the cost of research flight test and the complexity of today's systems-driven aircraft, an integrated set of ground support experimental facilities is a necessity. In support of the research flight test of highly advanced test beds, the DFRF is developing a network of facilities to expedite the acquisition and distribution of flight research data to the researcher. This network consists of an array of experimental ground-based facilities and systems as nodes and the necessary telecommunications paths to pass research data and information between these facilities. This paper presents a status of the current network, an overview of current developments, and a prospectus on future major enhancements.

Moore, Archie L.↗
NASA NTRS1987

Distributed operating system for NASA ground stations

NASA ground stations are characterized by ever changing support requirements, so application software is developed and modified on a continuing basis. A distributed operating system was designed to optimize the generation and maintenance of those applications. Unusual features include automatic program generation from detailed design graphs, on-line software modification in the testing phase, and the incorporation of a relational database within a real-time, distributed system.

Doyle, John F.↗
NASA NTRS1962

COMMUNICATIONS SATELLITES

Major communications satellite systems and evaluation of problems encountered in their establishment

SATELLITE GROUND SUPPORT NETWORK↗
NASA NTRS1985

Data Requirement (DR) MA-03: Payload missions integration

Project management and payload integration requirements definition activities are reported. Mission peculiar equipment; systems integration; ground operations analysis and requirement definition; safety and quality assurance; and support systems development are examined for payloads planned for the following missions: EOM-1; SL-2; Sl-3 Astro-1; MSL-2; EASE/ACCESS; MPESS; and the middeck ADSF flight.

Source record↗
NASA NTRS2016

The IOAG Recommendations on Spacecraft Emergency Cross Support

In 2014, the Inter-agency Operations Advisory Group (IOAG) chartered a multi-agency team effort to study how to best handle spacecraft emergency as part of cross support among network assets. The original intent is to put in place for the first time a process and guidelines to make emergency support as part of a permanent cross-support capability between space agencies. From the perspective of space communications service providers, a few key issues, common to all agencies, concerning the Spacecraft Emergency Cross Support (SECS) have been explored. They are: context of emergency support, provision of emergency support under a cross-support agreement, provision of emergency support with no cross-support agreement, legal and liability issues, response time, support priority, services provided, sustaining emergency support capabilities, and charge for the support. The positions of the various participating agencies with respect to these issues have been collected, analyzed, and finally harmonized to form the recommended IOAG positions. A central challenge most communications service providers are facing is that since the spacecraft emergency is an unplanned critical event, it typically requires fast response to the emergency call, hence lacking an international standard process for the operational interfaces seems to exacerbate the difficulty in providing SECS. For reducing the response time, i.e. from the time of accepting a request for SECS to the readiness for support, it is recommended that a “cross-support emergency system” be established by IOAG member agencies. Along with it, the IOAG core services, just-in-time ground communications line, cross support service management (CSSM), and standard operations procedures (SOP) for operational interfaces form the basic foundation of the “cross support emergency system”. Of the above, new to the cross support conducted thus far in the IOAG community is the concept of the SOP specifically for the interfaces between the service provider and service user during the SECS. Use cases, salient features, and definition of the key operational activities/tasks relevant to the interfaces are addressed by the effort. Underpinning such a system is the availability of the RF license granted by the local authority, at national and/or regional level, for a given ground station to communicate with and track the spacecraft in emergency mode at the uplink and downlink frequencies assigned to that spacecraft. That means it is critical for the IOAG member agencies to obtain a priori all-band licenses (for the entire X-band or S-band) for some, if not all, of their ground stations that are most capable of or likely to provide SECS. It is also recommended that certain prior arrangements be made with the relevant local licensing authorities for a process that will allow expedited authorization to transmit/receive signals to/from the declared spacecraft over the declared ground stations specifically and solely for the emergency case. Our analysis of the SECS has also uncovered a few fundamental programmatic issues. Recognizing any IOAG positions reached on these issues do not necessarily lead to any binding authority, it is recommended that they, along with those key attributes of the cross support emergency system, be explicitly stated as multi-agency guidelines to guide the implementation and provision of the SECS. The paper will present the results of the working group on Spacecraft Emergency Cross Support and, in particular, its findings, products and recommendations. It will also identify the next steps of this work that may include the production of some international standards as an extension of this work, or the process to make this emergency system usable by other spacecraft operators beyond the space agencies.

Tai, Wallace S.↗
NASA NTRS2016

The IOAG Recommendations on Spacecraft Emergency Cross Support

In 2014, the Inter-agency Operations Advisory Group (IOAG) chartered a multi-agency team effort to study how to best handle spacecraft emergency as part of cross support among network assets. The original intent is to put in place for the first time a process and guidelines to make emergency support as part of a permanent cross-support capability between space agencies. From the perspective of space communications service providers, a few key issues, common to all agencies, concerning the Spacecraft Emergency Cross Support (SECS) have been explored. They are: context of emergency support, provision of emergency support under a cross-support agreement, provision of emergency support with no cross-support agreement, legal and liability issues, response time, support priority, services provided, sustaining emergency support capabilities, and charge for the support. The positions of the various participating agencies with respect to these issues have been collected, analyzed, and finally harmonized to form the recommended IOAG positions. A central challenge most communications service providers are facing is that since the spacecraft emergency is an unplanned critical event, it typically requires fast response to the emergency call, hence lacking an international standard process for the operational interfaces seems to exacerbate the difficulty in providing SECS. For reducing the response time, i.e. from the time of accepting a request for SECS to the readiness for support, it is recommended that a “cross-support emergency system” be established by IOAG member agencies. Along with it, the IOAG core services, just-in-time ground communications line, cross support service management (CSSM), and standard operations procedures (SOP) for operational interfaces form the basic foundation of the “cross support emergency system”. Of the above, new to the cross support conducted thus far in the IOAG community is the concept of the SOP specifically for the interfaces between the service provider and service user during the SECS. Use cases, salient features, and definition of the key operational activities/tasks relevant to the interfaces are addressed by the effort. Underpinning such a system is the availability of the RF license granted by the local authority, at national and/or regional level, for a given ground station to communicate with and track the spacecraft in emergency mode at the uplink and downlink frequencies assigned to that spacecraft. That means it is critical for the IOAG member agencies to obtain a priori all-band licenses (for the entire X-band or S-band) for some, if not all, of their ground stations that are most capable of or likely to provide SECS. It is also recommended that certain prior arrangements be made with the relevant local licensing authorities for a process that will allow expedited authorization to transmit/receive signals to/from the declared spacecraft over the declared ground stations specifically and solely for the emergency case. Our analysis of the SECS has also uncovered a few fundamental programmatic issues. Recognizing any IOAG positions reached on these issues do not necessarily lead to any binding authority, it is recommended that they, along with those key attributes of the cross support emergency system, be explicitly stated as multi-agency guidelines to guide the implementation and provision of the SECS. The paper will present the results of the working group on Spacecraft Emergency Cross Support and, in particular, its findings, products and recommendations. It will also identify the next steps of this work that may include the production of some international standards as an extension of this work, or the process to make this emergency system usable by other spacecraft operators beyond the space agencies.

Tai, Wallace S.↗
NASA NTRS1984

Interplanetary navigation - An overview

The major elements of the Voyager navigational system are described, within the context of a general review of current interplanetary navigational techniques and equipment. The data processing components of the Voyager navigational system are described, including the ground-based computational facilities and software, and the different support functions. A block diagram of the ground based data processing system is presented. The development of VLBI techniques for a high-precision quasi-relative navigational system to be incorporated into the navigational payload of the Galileo satellite in 1986 is also discussed.

Jordan, J. F.↗
NASA NTRS2020

Medical Data Architecture Platform and Recommended Requirements for a Medical Data System for Exploration Missions

The Medical Data Architecture (MDA) project supports the Exploration Medical Capability (ExMC) risk to minimize or reduce the risk of adverse health outcomes and decrements in performance due to in-flight medical capabilities on human exploration missions. To mitigate this risk, the ExMC MDA project addresses the technical limitations identified in ExMC Gap Med 07: We do not have the capability to comprehensively process medically- relevant information to support medical operations during exploration missions. This gap identifies that the current in-flight medical data management includes a combination of data collection and distribution methods that are minimally integrated with on-board medical devices and systems. Furthermore, there are a variety of data sources and methods of data collection. For an exploration mission, the seamless management of such data will enable a more medically autonomous crew than the current paradigm of medical data management on the International Space Station. ExMC has recognized that in order to make informed decisions about a medical data architecture framework, current methods for medical data management must not only be understood, but an architecture must also be identified that provides the crew with actionable insight to medical conditions. This medical data architecture will provide the necessary functionality to address the challenges of executing a self-contained medical system that approaches crew health care delivery without assistance from ground support. Hence, the products derived from the third MDA prototype development will directly inform exploration medical system requirements for Level of Care IV in Gateway missions. In fiscal year 2019, the MDA project developed Test Bed 3, the third iteration in a series of prototypes, that featured integrations with cognition tool data, ultrasound image analytics and core Flight Software (cFS). Maintaining a layered architecture design, the framework implemented a plug-in, modular approach in the integration of these external data sources. An early version of MDA Test Bed 3 software was deployed and operated in a simulated analog environment that was part of the Next Space Technologies for Exploration Partnerships (NextSTEP) Gateway tests of multiple habitat prototypes. In addition, the MDA team participated in the Gateway Test and Verification Demonstration, where the MDA cFS applications was integrated with Gateway-in-a-Box software to send and receive medically relevant data over a simulated vehicle network. This software demonstration was given to ExMC and Gateway Program stakeholders at the NASA Johnson Space Center Integrated Power, Avionics and Software (iPAS) facility. Also, the integrated prototypes served as a vehicle to provide Level 5 requirements for the Crew Health and Performance Habitat Data System for Gateway Missions (Medical Level of Care IV). In the upcoming fiscal year, the MDA project will continue to provide systems engineering and vertical prototypes to refine requirements for medical Level of Care IV and inform requirements for Level of Care V.

Krihak, M.↗
NASA NTRS2020

Medical Data Architecture Platform and Recommended Requirements for A Medical Data System for Exploration Missions

Minimize or reduce the risk of adverse health outcomes and decrements in performance due to in-flight medical capabilities on human exploration missions. To mitigate this risk, the ExMC MDA project addresses the technical limitations identified in ExMC Gap Med 07: We do not have the capability to comprehensively process medically relevant information to support medical operations during exploration missions. This gap identifies that the current in-flight medical data management includes a combination of data collection and distribution methods that are minimally integrated with on-board medical devices and systems. Furthermore, there are a variety of data sources and methods of data collection. For an exploration mission, the seamless management of such data will enable a more medically autonomous crew than the current paradigm of medical data management on the International Space Station. ExMC has recognized that in order to make informed decisions about a medical data architecture framework, current methods for medical data management must not only be understood, but an architecture must also be identified that provides the crew with actionable insight to medical conditions. This medical data architecture will provide the necessary functionality to address the challenges of executing a self-contained medical system that approaches crew health care delivery without assistance from ground support. Hence, the products derived from the third MDA prototype development will directly inform exploration medical system requirements for Level of Care IV in Gateway missions.In fiscal year 2019, the MDA project developed Test Bed 3, the third iteration in a series of prototypes, that featured integrations with cognition tool data, ultrasound image analytics and core Flight Software (cFS). Maintaining a layered architecture design, the framework implemented a plug-in, modular approach in the integration of these external data sources. An early version of MDA Test Bed 3 software was deployed and operated in a simulated analog environment that was part of the Next Space Technologies for Exploration Partnerships (NextSTEP) Gateway tests of multiple habitat prototypes. In addition, the MDA team participated in the Gateway Test and Verification Demonstration, where the MDA cFS applications was integrated with Gateway-in-a-Box software to send and receive medically relevant data over a simulated vehicle network. This software demonstration was given to ExMC and Gateway Program stakeholders at the NASA Johnson Space Center Integrated Power, Avionics and Software (iPAS) facility. Also, the integrated prototypes served as a vehicle to provide Level 5 requirements for the Crew Health and Performance Habitat Data System for Gateway Missions (Medical Level of Care IV). In the upcoming fiscal year, the MDA project will continue to provide systems engineering and vertical prototypes to refine requirements for medical Level of Care IV and inform requirements for Level of Care V.

Krihak, M.↗
NASA NTRS1992

The environmental control and life-support system for a lunar base: What drives its design

The purpose of this paper is to identify and briefly discuss some of the ground rules and mission scenario details that become drivers of the environmental control and life support (ECLS) system design and of the logistics related to the design. This paper is written for mission planners and non-ECLS system engineers to inform them of the details that will be important to the ECLS engineer when the design phase is reached. In addition, examples illustrate the impact of some selected mission characteristics on the logistics associated with ECLS systems. The last section of this paper focuses on the ECLS system technology development sequence and highlights specific portions that need emphasis.

Hypes, Warren D.↗
NASA NTRS1987

Microgravity research applications of interferometry to heat and mass transfer

Major space flight experiments which have used interferometric measurement as a major support system are described together with similar ground-based research. Space experiments include those flown on Spacelab 3 ad on the D-1 mission. Included in the ground-based experiments are aircraft studies, Spacelab 3 data reduction and evaluation, and supportive laboratory hardware development. It is shown that optical measurement techniques are crucial to microgravity research.

Owen, Robert B.↗
NASA NTRS2015

Environmentally-Preferable Launch Coatings

The Ground Systems Development and Operations (GSDO) Program at NASA Kennedy Space Center (KSC), Florida, has the primary objective of modernizing and transforming the launch and range complex at KSC to benefit current and future NASA programs along with other emerging users. Described as the launch support and infrastructure modernization program in the NASA Authorization Act of 2010, the GSDO Program will develop and implement shared infrastructure and process improvements to provide more flexible, affordable, and responsive capabilities to a multi-user community. In support of NASA and the GSDO Program, the objective of this project is to determine the feasibility of environmentally friendly corrosion protecting coatings for launch facilities and ground support equipment (GSE). The focus of the project is corrosion resistance and survivability with the goal to reduce the amount of maintenance required to preserve the performance of launch facilities while reducing mission risk. The project compares coating performance of the selected alternatives to existing coating systems or standards.

ground support equipment↗