SEARCH · Engineering Papers

Results for “system-level”

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.

SourceResearch connectionFrom yearThrough year

Quote a phrase for an exact phrase match. Source license links do not imply unrestricted reuse.

At least 235 records · Page 13

All sources NASA NTRS DOE OSTI

NASA NTRS2005

Mars Exploration Rover Entry, Descent, and Landing: A Thermal Perspective

Perhaps the most challenging mission phase for the Mars Exploration Rovers was the Entry, Descent, and Landing (EDL). During this phase, the entry vehicle attached to its cruise stage was transformed into a stowed tetrahedral Lander that was surrounded by inflated airbags through a series of complex events. There was only one opportunity to successfully execute an automated command sequence without any possible ground intervention. The success of EDL was reliant upon the system thermal design: 1) to thermally condition EDL hardware from cruise storage temperatures to operating temperature ranges; 2) to maintain the Rover electronics within operating temperature ranges without the benefit of the cruise single phase cooling loop, which had been evacuated in preparation for EDL; and 3) to maintain the cruise stage propulsion components for the critical turn to entry attitude. Since the EDL architecture was inherited from Mars Pathfinder (MPF), the initial EDL thermal design would be inherited from MPF. However, hardware and implementation differences from MPF ultimately changed the MPF inheritance approach for the EDL thermal design. With the lack of full inheritance, the verification and validation of the EDL thermal design took on increased significance. This paper will summarize the verification and validation approach for the EDL thermal design along with applicable system level thermal testing results as well as appropriate thermal analyses. In addition, the lessons learned during the system-level testing will be discussed. Finally, the in-flight EDL experiences of both MER-A and -B missions (Spirit and Opportunity, respectively) will be presented, demonstrated how lessons learned from Spirit were applied to Opportunity.

thermal↗

NASA NTRS2001

Architectures and Evaluation for Adjustable Control Autonomy for Space-Based Life Support Systems

In the past five years, a number of automation applications for control of crew life support systems have been developed and evaluated in the Adjustable Autonomy Testbed at NASA's Johnson Space Center. This paper surveys progress on an adjustable autonomous control architecture for situations where software and human operators work together to manage anomalies and other system problems. When problems occur, the level of control autonomy can be adjusted, so that operators and software agents can work together on diagnosis and recovery. In 1997 adjustable autonomy software was developed to manage gas transfer and storage in a closed life support test. Four crewmembers lived and worked in a chamber for 91 days, with both air and water recycling. CO2 was converted to O2 by gas processing systems and wheat crops. With the automation software, significantly fewer hours were spent monitoring operations. System-level validation testing of the software by interactive hybrid simulation revealed problems both in software requirements and implementation. Since that time, we have been developing multi-agent approaches for automation software and human operators, to cooperatively control systems and manage problems. Each new capability has been tested and demonstrated in realistic dynamic anomaly scenarios, using the hybrid simulation tool.

Malin, Jane T.↗

NASA NTRS2006

Automated Synthesis of Architecture of Avionic Systems

The Architecture Synthesis Tool (AST) is software that automatically synthesizes software and hardware architectures of avionic systems. The AST is expected to be most helpful during initial formulation of an avionic-system design, when system requirements change frequently and manual modification of architecture is time-consuming and susceptible to error. The AST comprises two parts: (1) an architecture generator, which utilizes a genetic algorithm to create a multitude of architectures; and (2) a functionality evaluator, which analyzes the architectures for viability, rejecting most of the non-viable ones. The functionality evaluator generates and uses a viability tree a hierarchy representing functions and components that perform the functions such that the system as a whole performs system-level functions representing the requirements for the system as specified by a user. Architectures that survive the functionality evaluator are further evaluated by the selection process of the genetic algorithm. Architectures found to be most promising to satisfy the user s requirements and to perform optimally are selected as parents to the next generation of architectures. The foregoing process is iterated as many times as the user desires. The final output is one or a few viable architectures that satisfy the user s requirements.

Chau, Savio↗

NASA NTRS2005

Diagnosis and Prognosis of Weapon Systems

The Prognostics Framework is a set of software tools with an open architecture that affords a capability to integrate various prognostic software mechanisms and to provide information for operational and battlefield decision-making and logistical planning pertaining to weapon systems. The Prognostics NASA Tech Briefs, February 2005 17 Framework is also a system-level health -management software system that (1) receives data from performance- monitoring and built-in-test sensors and from other prognostic software and (2) processes the received data to derive a diagnosis and a prognosis for a weapon system. This software relates the diagnostic and prognostic information to the overall health of the system, to the ability of the system to perform specific missions, and to needed maintenance actions and maintenance resources. In the development of the Prognostics Framework, effort was focused primarily on extending previously developed model-based diagnostic-reasoning software to add prognostic reasoning capabilities, including capabilities to perform statistical analyses and to utilize information pertaining to deterioration of parts, failure modes, time sensitivity of measured values, mission criticality, historical data, and trends in measurement data. As thus extended, the software offers an overall health-monitoring capability.

Nolan, Mary↗

NASA NTRS2004

Activity-Centric Approach to Distributed Programming

The first phase of an effort to develop a NASA version of the Cybele software system has been completed. To give meaning to even a highly abbreviated summary of the modifications to be embodied in the NASA version, it is necessary to present the following background information on Cybele: Cybele is a proprietary software infrastructure for use by programmers in developing agent-based application programs [complex application programs that contain autonomous, interacting components (agents)]. Cybele provides support for event handling from multiple sources, multithreading, concurrency control, migration, and load balancing. A Cybele agent follows a programming paradigm, called activity-centric programming, that enables an abstraction over system-level thread mechanisms. Activity centric programming relieves application programmers of the complex tasks of thread management, concurrency control, and event management. In order to provide such functionality, activity-centric programming demands support of other layers of software. This concludes the background information. In the first phase of the present development, a new architecture for Cybele was defined. In this architecture, Cybele follows a modular service-based approach to coupling of the programming and service layers of software architecture. In a service-based approach, the functionalities supported by activity-centric programming are apportioned, according to their characteristics, among several groups called services. A well-defined interface among all such services serves as a path that facilitates the maintenance and enhancement of such services without adverse effect on the whole software framework. The activity-centric application-program interface (API) is part of a kernel. The kernel API calls the services by use of their published interface. This approach makes it possible for any application code written exclusively under the API to be portable for any configuration of Cybele.

Levy, Renato↗

NASA NTRS1998

Theoretical Accuracy for ESTL Bit Error Rate Tests

"Bit error rate" [BER] for the purposes of this paper is the fraction of binary bits which are inverted by passage through a communication system. BER can be measured for a block of sample bits by comparing a received block with the transmitted block and counting the erroneous bits. Bit Error Rate [BER] tests are the most common type of test used by the ESTL for evaluating system-level performance. The resolution of the test is obvious: the measurement cannot be resolved more finely than 1/N, the number of bits tested. The tolerance is not. This paper examines the measurement accuracy of the bit error rate test. It is intended that this information will be useful in analyzing data taken in the ESTL. This paper is divided into four sections and follows a logically ordered presentation, with results developed before they are evaluated. However, first-time readers will derive the greatest benefit from this paper by skipping the lengthy section devoted to analysis, and treating it as reference material. The analysis performed in this paper is based on a Probability Density Function [PDF] which is developed with greater detail in a past paper, Theoretical Accuracy for ESTL Probability of Acquisition Tests, EV4-98-609.

Lansdowne, Chatwin↗

NASA NTRS2000

Processing CCD Images to Detect Transits of Earth-Sized Planets: Maximizing Sensitivity While Achieving Reasonable Downlink Requirements

We have performed end-to-end laboratory and numerical simulations to demonstrate the capability of differential photometry under realistic operating conditions to detect transits of Earth-sized planets orbiting solar-like stars. Data acquisition and processing were conducted using the same methods planned for the proposed Kepler Mission. These included performing aperture photometry on large-format CCD images of an artificial star fields obtained without a shutter at a readout rate of 1 megapixel/sec, detecting and removing cosmic rays from individual exposures and making the necessary corrections for nonlinearity and shutterless operation in the absence of darks. We will discuss the image processing tasks performed `on-board' the simulated spacecraft, which yielded raw photometry and ancillary data used to monitor and correct for systematic effects, and the data processing and analysis tasks conducted to obtain lightcurves from the raw data and characterize the detectability of transits. The laboratory results are discussed along with the results of a numerical simulation carried out in parallel with the laboratory simulation. These two simulations demonstrate that a system-level differential photometric precision of 10-5 on five- hour intervals can be achieved under realistic conditions.

Earth-size planets↗

NASA NTRS2004

Modeling the TPF interferometer

The Terrestrial Planet Finder interferometer design concepts are large and complex systems that must operate in environments that are impractical to reproduce in preflight testing. The structurally-connected design is 36 meters long - longer than all but one thermal vacuum chamber in existence. The formation flying design will be comprised of up to five separate spacecraft, each with a sunshield over 15 meters on a side, and is designed to operate with formation sizes spanning over 100 meters to very close formations. System-level verification of the performance of the designs will need to rely on analytical modeling. The effort to model the many physical aspects of the designs under study is under way*. This paper describes the program of modeling for the TPF-I concepts. The program includes a number of types of models, such as the standard stand-alone optics, thermal, and structural models, as well as an end-to-end performance model of the project system called the Observatory Simulation. Aspects of each model are discussed including the purpose, methods of implementation (software applications), and approaches to validation. Program-level considerations (such as model-to-model integration and configuration management) are also discussed. Given that there are at least seven different organizations contributing to model developments and more than twenty separate models, these are special challenges.

Henry, Curt↗

NASA NTRS1999

The 13th Technology of Deep Space One

On October 24th, 1998, the Deep Space One (DS-1) spacecraft launched aboard a Delta II rocket as the first step towards the bold task of testing and validating 12 new technologies for future missions. This launch also represented yet another thrilling event; namely, the successful test and validation of a 13th heretofore undisclosed technology: model-base-code-generation of the spacecraft's system-level fault-protection (FP) software from behavioral state diagrams and structural models.

model-based-code-generation↗

NASA NTRS1997

Infusion of Autonomy Technology into Space Missions: DS1 Lessons Learned

The impact of infusing breakthrough autonomy technology into a flight project was a big surprise. Valuable technical and cultural lessons, many of general applicability when intorducing system-level autonomy, have been learned by infusing the Remote Agent (RA) into NASA's Deep Space 1 (DS1) Spacecraft.

Autonomy↗

NASA NTRS1994

Experience Report: Using Formal Methods for Requirements Analysis of Critical Spacecraft Software

Formal specification and analysis of requirements continues to gain support as a method for producing more reliable software. However, the introduction of formal methods to a large software project is difficult, due in part to the unfamiliarity of the specification languages and the lack of graphics. This paper reports results of an investigation into the effectiveness of formal methods as an aid to the requirements analysis of critical, system-level fault-protection software on a spacecraft currently under development. Our experience indicates that formal specification and analysis can enhance the accuracy of the requirements and add assurance prior to design development in this domain.

Formal↗

NASA NTRS1993

Recent Progress in Deep Space Optical Communications

Progress in the NASA-funded optical communications program at the Jet Propulsion Laboratory (JPL) is decribed. This decription includes a system-level breadboard for an optical communications flight package, the planning for the Earth-reception facilities, and the results of a recent optical communications experiment to deep space with the Galileo spacecraft.

Voyager↗

NASA NTRSDate not supplied

Artemis I Orion ESM Propulsion System Engine Performance

NASA's Orion spacecraft transports humans and cargo into cislunar space for the Artemis program. The European Service Module (ESM), supplied by ESA and its European industry partners, provides Orion with power and in-space propulsion. The Orion-ESM propulsion system is a bipropellant hypergolic propulsion system using monomethyl hydrazine (MMH) and nitrogen tetroxide (MON-3). Primary translational propulsion is provided by the Orbital Maneuvering System Engine(OMS-E), with backup translational propulsion provided by eight Auxiliary thrusters (AUX). Attitude control and small translational maneuvers are provided by twenty four Reaction Control System (RCS) engines. The 2022 Artemis I mission was the first integrated flight test of the Orion-ESM spacecraft and its propulsion system. The OMS-E used on Artemis I was a refurbished Space Shuttle OMS-E that previously flew on nineteen missions ranging f rom STS-41G in 1984 to STS-112 in 2002. The Auxiliary engines are modified Aerojet Rocketdyne R4D-11 engines produced specifically for the Orion program. The RCS engines are Ariane Group engines originally used for the Automated Transfer Vehicle (ATV) program. This paper will discuss the unique operational requirements for each engine on Orion and the development and qualification effort sat both the engine and system-level that were completed to enable a successful Artemis I mission. Next the paper will evaluate the in-f light performance of the engines during the Artemis I mission showing nominal performance as expected. Additionally, comparisons to models will be presented showing very good correlation. Finally, the paper will address the plan for the engines on future Orion missions and the evolution of the system operation.

liquid propulsion systems↗

NASA NTRS2026

Spacecraft Disposal Rosetta Stone: Parametric Tool for Orbital Lifetime, Disposal, and Cost Assessment

This Technical Memorandum documents a simplified, parametric method for evaluating spacecraft orbital lifetime, disposal compliance, and disposal-related cost impacts during early mission formulation and preliminary design. The method captures the dominant drivers of orbital decay—effective ballistic coefficient, operating altitude, and solar-cycle variability—using conservative bounding assumptions. Solar maximum conditions are used to bound achievable mission lifetime, while solar minimum conditions are used to bound disposal timelines and compliance with orbital debris requirements. A single tabulated dataset provides orbital lifetime under both solar-cycle extremes together with representative disposal ΔV required to ensure compliant disposal, enabling rapid assessment of disposal feasibility, cost sensitivity, and system-level impacts prior to committing to higher-fidelity analyses.

Orbital debris mitigation↗

NASA NTRSDate not supplied

Performance of a Regenerative Fuel Cell System for the Lunar Surface

Regenerative fuel cells (RFCs) are an attractive energy storage solution for lunar missions as a technology capable of providing a higher specific energy (i.e., W∙h/kg) than state-of-the-art packaged Li-ion battery systems. An RFC consists of the (1 & 2) electrochemical stacks (chemical to electrical energy conversion to supply electricity to an external load, i.e. the fuel cell reaction, and electrical to chemical energy conversion of supplied electrical power to dissociate water into hydrogen and oxygen gases, i.e. water electrolysis), (3) fluidic conditioning, (4) reactant storage, (5) avionics, (6) power management and distribution (PMAD), and (7) thermal management. NASA’s Glenn Research Center has designed, assembled, and tested a breadboard RFC sys-tem capable of operating autonomously for multiple simulated lunar day/night cycles in a laboratory environment. The system is comprised of a non-flow through proton exchange membrane (PEM) fuel cell stack and a liquid-anode feed PEM electrolyzer (EZ) stack designed to electrochemically compress the reactants at balanced pressures up to 12.4 MPa (1800 psia). The fluidic conditioning, avionics, PMAD, and thermal management sub-systems are largely comprised of commercial-off-the-shelf components for this system-level development effort. The hardware is controlled by a CubeSat space processor running an operational program based on core flight architecture that can control the RFC hardware autonomously through a state machine with fault monitoring. The testing results highlighted here were completed with the system in an open-loop configuration such that reactants generated through water electrolysis were vented while gas cylinders supplied fuel cell operation. The breadboard operated autonomously, but there were five unplanned transitions to a safe state that required a manual restart after reviewing the data, determining a root cause, and implementing a solution. Four of the transitions were caused by the thermal management subsystem and the fifth was caused by a water management control issue in the EZ sub-system. The RFC system operated for over 550 hours with the final cycle being slightly abbreviated due to reasons unrelated to system performance.

Kerrigan Cain↗

NASA NTRSDate not supplied

Performance of a Regenerative Fuel Cell System for the Lunar Surface

Kerrigan Cain↗

NASA NTRS2026

Development of the Orion Life-Support Integration Facility (OLIF)

Testing the life support hardware of a vehicle that is going to take humans beyond low-Earth orbit (LEO) in conditions similar to space is crucial. The Orion Life-Support Integration Facility (OLIF) at NASA Johnson Space Center (JSC) was designed and built to test the Orion vehicle’s hardware and software as integrated systems to provide a complete Environmental Control and Life Support System (ECLSS) system-level qualification. The existing 11 Foot human rated vacuum chamber has been adapted to accommodate and integrate various qualification and flight like components of the Orion vehicle’s Air Revitalization System (ARS), Pressure Control System (PCS), Active Thermal Control System (ATCS) and the Orion Crew Survival System Suits (OCSS). The ultimate goal was to create an analog testbed that could safely support up to four test subjects in open “shirt-sleeve” or closed suit loop configurations and simulate Orion Cabin conditions. This integrated hardware/software ARS and PCS will help identify any technical issues that should be addressed prior to the Artemis-2 mission. This paper will discuss the history of Orion ECLSS hardware development testing in the 11 Foot Chamber, the challenge of integrating flight hardware and software control systems, and the capabilities that make it a unique, world class facility for NASA. It will provide an overview of past and future testing, and the lessons learned along the way.

Peter A Masi↗

NASA NTRS2026

Gateway Element and Payload Materials Outgassing Analyses: HALO, HERMES, and ERSA

Gateway was intended to be humanity’s first space station around the Moon, but its development has been paused as the National Aeronautics and Space Administration (NASA) shifts focus to achieving the United States’ National Space Policy goals. Instead of an orbiting lunar outpost, NASA will now pursue the development of a lunar surface base to support a sustained human presence on the Moon. Before the program’s pause, Gateway’s Induced Environments team worked to ensure payloads and elements (i.e., modules) complied with induced environment requirements. Methods developed and insights gained from this work will have applicability to NASA’s Moon Base and the potential repurposing of Gateway elements and payloads, as well as to induced environments modeling for future space stations. The Gateway program’s induced environment included molecular contamination, electric thruster plume sputter and redeposition, and lunar dust transfer from the Human Landing System (HLS). Primary sources of external molecular contamination included materials outgassing, chemical thruster plume contamination, and vacuum venting. The focus of this paper will be on element- and payload-level materials outgassing analyses performed for Gateway Configuration 1, extending the previously-developed framework for Gateway system-level external molecular contamination modeling. Gateway Configuration 1 consisted of the Power and Propulsion Element (PPE) and the Habitation and Logistics Outpost (HALO). It also included payloads like the European Radiation Sensor Array (ERSA) attached to PPE and the Heliophysics Environmental and Radiation Measurement Experiment Suite (HERMES) attached to HALO. The element- and payload-level analyses to be introduced in this paper for HALO, HERMES, and ERSA enabled high-fidelity descriptions of Gateway’s external molecular contamination environment. Approaches to geometric modeling, meshing, outgassing rate assignment, molecular transport modeling, and analysis methodology will be presented. Element and payload contaminant deposition onto sensitive Gateway receiver surfaces will be summarized and results compared to induced environment requirements. While these results incorporate refinements made over the course of the program, they were not intended to be final. Therefore, modeling assumptions and inputs, potential improvements, and lessons-learned will be documented to inform future work on Moon Base, repurposed elements and payloads, and other space stations.

Gateway↗