SEARCH · Engineering Papers
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.
This presentation describes the factors that have emerged in the evolved process of reengineering the unmanned spacecraft design process at the Jet Propulsion Laboratory in Pasadena, California. Topics discussed include: New facilities, new design factors, new system-level tools, complex performance objectives, changing behaviors, design integration, leadership styles, and optimization.
A world leader in space technology, JPL has over 30 years experience in developing spacecraft systems and managing deep space missions for NASA. Future scientific missions will require the rapid development of small, lightweight, high-technology, low-cost spacecraft. JPL is developing a method of meeting these requirements: a test facility specifically for supporting a rapid prototyping development environment that creates a virtual (simulated) spacecraft in which system-level evaluations of components can be carried out very early in the development cycle, long before an actual spacecraft is built.
This paper reports results of an investigation into the suitability of object-oriented models as an initial step in developing formal specifications. The requirements for two critical system-level software modules were used as target applications. It was found that creating object-oriented diagrams prior to formally specifying the requirements enhanced the accuracy of the initial formal specifications and reduced the effort required to produce them. However, the formal specifications incorporated some information not found in the object-oriented diagrams, such as higher-level strategy or goals of the software.
This paper describes the validation process for the Autonomous Science Agent, a software agent that is currently flying onboard NASA EO-1 spacecraft. The agent autonomously collects, analyzes, and reacts to onboard science data. The Autonomous Science Agent has been designed using a layered architectural approach with specific redundant safeguards to reduce the risk of an agent malfunction to the EO-1 spacecraft. This safe design has been thoroughly validated by informal validation methods supplemented by sub-system and system-level testing. This paper describes the analysis used to define agent safety, elements of the design that increase the safety of the agent, and the process used to validate agent safety.
This paper extends the investigation of angular orientation effects to the refrigeration performance of high frequency (-40 Hz) Stirling-type pulse tube cryocoolers typical of those used in long-life space applications. Strong orientation effects on the performance of such cryocoolers have recently been observed during system-level testing of both linear and U-tube type pulse tubes. To quantify the angular dependency effects, data have been gathered on both U-tube and linear type pulse tubes of two different manufacturers as a function of orientation angle, cold-tip temperature, and compressor stroke.
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.
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.
"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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.