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 289 records · Page 16

All sources NASA NTRS DOE OSTI

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 NTRS2010

The DESDynI Synthetic Aperture Radar Array-Fed Reflector Antenna

DESDynI is a mission being developed by NASA with radar and lidar instruments for Earth-orbit remote sensing. This paper focuses on the design of a largeaperture antenna for the radar instrument. The antenna comprises a deployable reflector antenna and an active switched array of patch elements fed by transmit/ receive modules. The antenna and radar architecture facilitates a new mode of synthetic aperture radar imaging called 'SweepSAR'. A system-level description of the antenna is provided, along with predictions of antenna performance.

Chamberlain, Neil↗

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 NTRS2009

Modeling of Lunar Dust Contamination Due to Plume Impingement

During the Apollo missions it became apparent that lunar dust was a significant hazard. Problems included: surface obscuration during landing sequence; abrasion damage to gouge faces and helmet visors; mechanism clogging; development of space suit pressurization leaks; loss of radiator heat rejection capabilities to the point where vulnerable equipment exceeded maximum survival temperature ratings; temporary vision and respiratory problems within the Apollo Lunar Module (LM). NASA Constellation Program features many system-level components, including the Altair Lunar Lander. Altair to endure longer periods at lunar surface conditions: Apollo LM, about three days; Altair, over seven months. Program managers interested in plume-generated dust transport onto thermal control surface radiators of the first Altair created by its own landing operations.

Woronowicz, Michael↗

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 NTRS2008

Terrestrial Planet Finder Interferometer : TPF-I Technology Milestone #2 Report : formation control performance demonstration

This document reports the achievement of Terrestrial Planet Finder Interferometer (TPF-I) Technology Milestone #2, a ground-based, system-level demonstration of twospacecraft formation synchronized rotation. We review the milestone specification from the Milestone White Paper (May 25, 2007), summarize the experiments performed in the Formation Control Testbed (FCT), detail the procedures and nalysis of the resulting data, and describe and present the data itself.

Lawson, Peter R.↗

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↗