Search NASA⌕ Search

SEARCH · Search NASA

Results for “command process”

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 1,099 records · Page 61
All sourcesNASA NTRSDOE OSTI
NASA NTRS1986

Assessment of pilot workload - Converging measures from performance based, subjective and psychophysiological techniques

This study explores the relationship between the P300 component of the event-related brain potential (ERP) and the processing demands of a complex real-world task. Seven male volunteers enrolled in an Instrument Flight Rule (IFR) aviation course flew a series of missions in a single engine fixed-based simulator. In dual task conditions subjects were also required to discriminate between two tones differing in frequency. ERPs time-locked to the tones, subjective effort ratings and overt performance measures were collected during two 45 min flights differing in difficulty (manipulated by varying both atmospheric conditions and instrument reliability). The more difficult flight was associated with poorer performance, increased subjective effort ratings, and smaller secondary task P300s. Within each flight, P300 amplitude was negatively correlated with deviations from command headings indicating that P300 amplitude was a sensitive workload metric both between and within the flight missions.

Kramer, Arthur F.↗
NASA NTRS2005

STS-114: Discovery Launch Readiness Press Conference

Michael Griffin, NASA Administrator; Wayne Hale, Space Shuttle Deputy Program Manager; Mike Wetmore, Director of Shuttle Processing; and 1st Lieutenant Mindy Chavez, Launch Weather Officer-United States Air Force 45th Weather Squadron are in attendance for this STS-114 Discovery launch readiness press conference. The discussion begins with Wayne Hale bringing to the table a low level sensor device for everyone to view. He talks in detail about all of the extensive tests that were performed on these sensors and the completion of these ambient tests. Chavez presents her weather forecast for the launch day of July 26th 2005. Michael Griffin and Wayne Hale answer questions from the news media pertaining to the sensors and launch readiness. The video ends with footage of Pilot Jim Kelly and Commander Eileen Collins conducting test flights in a Shuttle Training Aircraft (STA) that simulates Space Shuttle landing.

Source record↗
NASA NTRS2011

Gas Dynamic Spray Technology Demonstration Project Management

The standard practice for protecting metallic substrates in atmospheric environments is the use of an applied coating system. Current coating systems used across AFSPC and NASA contain volatile organic compounds (VOCs) and hazardous air pollutants (HAPs). These coatings are sUbject to environmental regulations at the Federal and State levels that limit their usage. In addition, these coatings often cannot withstand the high temperatures and exhaust that may be experienced by Air Force Space Command (AFSPC) and NASA structures. In response to these concerns, AFSPC and NASA have approved the use of thermal spray coatings (TSCs). Thermal spray coatings are extremely durable and environmentally friendly coating alternatives, but utilize large cumbersome equipment for application that make the coatings difficult and time consuming to repair. Other concerns include difficulties coating complex geometries and the cost of equipment, training, and materials. Gas Dynamic Spray (GOS) technology (also known as Cold Spray) was evaluated as a smaller, more maneuverable repair method as well as for areas where thermal spray techniques are not as effective. The technology can result in reduced maintenance and thus reduced hazardous materials/wastes associated with current processes. Thermal spray and GOS coatings also have no VOCs and are environmentally preferable coatings. The primary objective of this effort was to demonstrate GDS technology as a repair method for TSCs. The aim was that successful completion of this project would result in approval of GDS technology as a repair method for TSCs at AFSPC and NASA installations to improve corrosion protection at critical systems, facilitate easier maintenance activity, extend maintenance cycles, eliminate flight hardware contamination, and reduce the amount of hazardous waste generated.

Lewis, Pattie↗
NASA NTRSDate not supplied

A Modern Load Relief Guidance Scheme for Space Launch Vehicles

Launch vehicle load relief algorithms are concerned with realizing a reduction of transient bending moments near maximum dynamic pressure. Traditional approaches to load relief typically use inner-loop acceleration feedback to reduce the wind-induced angle of attack. When implemented in the inner loop, load relief bandwidth is necessarily limited by the achievable stability margins, and when acceleration feedback is employed, by the uncertainty associated with structural modes that couple with the body-mounted accelerometer. The structure of inner loop load relief increases the dimensionality of the flight control gain and filter optimization problem. Most importantly, classical load relief laws do not take advantage of high-rate and high-accuracy GPS-aided inertial velocity data that is readily available from modern strap down IMUs. In this paper, a novel load relief guidance scheme is described that uses direct angle-of-attack feedback in a clever mechanization. The steering commands are determined by examining the wind-perturbed dynamics of a launch vehicle with respect to a gravity turn ascent trajectory. An angle of attack estimate is derived from GPS-aided inertial data and pre-launch range wind measurements, and it is shown that a reduction worst-case rigid-body loads can be realized without requiring air data. The algorithm also includes a high-rate navigation data preprocessing scheme that operates directly on the IMU delta-theta and delta-velocity measurements in order to produce a filtered acceleration estimate at the vehicle center of mass. The outer-loop guidance scheme simplifies the design process for the classical inner-loop autopilot. Algorithm performance is demonstrated using Monte Carlo analysis of a representative liquid booster in a production high fidelity launch vehicle simulation.

NESC↗
NASA NTRS1999

Non-Invasive Assessment of Susceptibility to Ventricular Arrhythmias During Simulated Microgravity

The Cardiovascular Alterations Team is currently conducting studies to determine what alterations in hemodynamic regulation result from sixteen days of simulated microgravity exposure in normal human subjects. In this project we make additional measurements on these same study subjects in order to determine whether there is an increase in susceptibility to ventricular arrhythmias resulting from simulated microgravity exposure. Numerous anecdotal and documented reports from the past 30 years suggest that the incidence of ventricular arrhythmias among astronauts is increased during space flight. For example, documented runs of ventricular tachycardia have been recorded from crew members of Skylab and Mir, there was much attention given by the lay press to Mir Commander Vasily Tslbliyev's complaints of heart rhythm irregularities in July of 1997, and cardiovascular mechanisms may have been causal in the recent death of an experimental primate shortly after return from space. In 1986, a Mir cosmonaut, Alexander Laveikin, was brought home and replaced with an alternate cosmonaut as a result of cardiac dysrhythmias that began during extravehicular activity. Furthermore, at a joint NASA/NSBRI workshop held in January 1998, cardiac arrhythmias were identified as the highest priority cardiovascular risk to a human Mars mission. Despite the evidence for the risk of a potentially lethal arrhythmia resulting from microgravity exposure, the effects of space flight and the associated physiologic stresses on cardiac conduction processes are not known, and an increase in cardiac susceptibility to arrhythmias has never been quantified. In this project, we are determining whether simulated space flight increases the risk of developing life-threatening heart rhythm disturbances such as sustained ventricular tachycardia (defined as ventricular tachycardia lasting at least 30 seconds or resulting in hemodynamic collapse) and ventricular fibrillation. We are obtaining measures of cardiac susceptibility to ventricular arrhythmias in subjects exposed to simulated space flight in the Human Studies Core protocol being conducted by the Cardiovascular Alterations Team, which involves sixteen days .of bed rest. In particular, we are applying a powerful new non-invasive technology, developed in Professor Cohen's laboratory at MIT for the quantitative assessment of the risk of life-threatening ventricular arrhythmias. This technology involves the measurement of microvolt levels of T wave alternans (TWA) during exercise stress, and was recently granted approval by the Food and Drug Administration to be used for the clinical evaluation of patients suspected to be at risk of ventricular arrhythmias. In addition, we are obtaining 24 hour Holter monitoring (to detect non-sustained ventricular tachycardia and to assess heart rate variability). We are also conducting protocols to obtain these same measures on a monthly basis for up to four months in subjects in the Bone Demineralization/calcium Metaboloism Team's long term bed rest study.

Cohen, Richard J.↗
NASA NTRS2018

Aladyn - Adaptive Neural Network Molecular Dynamics Simulation Code: Computational Materials Mini-Application

This report provides an overview and commands description of the Computational Materials mini-application, Aladyn. Aladyn is a simple molecular dynamics code written in FORTRAN 2008, which is designed to demonstrate the use of adaptive neural networks (ANNs) in atomistic simulations. The role of ANNs is to reproduce the very complex energy landscape resulting from the atomic interactions in materials with the accuracy of quantum mechanics-based energy calculations. The ANN is trained on a large set of atomic structures calculated using the density functional theory (DFT) method. The Aladyn code is being released to serve as a training testbed for students and professors in academia to explore possible optimization algorithms for parallel computing on multicore central processing unit (CPU) computers or computers utilizing many core architectures based on graphic processing units (GPUs). The effort is related to the High Performance Computing Incubator (HPCI) project at NASA Langley Research Center.

Yamakov, Vesselin I.↗
NASA NTRS1972

Electron-proton spectrometer: Summary for critical design review

The electron-proton spectrometer (EPS) is mounted external to the Skylab module complex on the command service module. It is designed to make a 2 pi omni-directional measurement of electrons and protons which result from solar flares or enhancement of the radiation belts. The EPS data will provide accurate radiation dose information so that uncertain Relative biological effectiveness factors are eliminated by measuring the external particle spectra. Astronaut radiation safety, therefore, can be ensured, as the EPS data can be used to correct or qualify radiation dose measurements recorded by other radiation measuring instrumentation within the Skylab module complex. The EPS has the capability of measuring and extremely wide dynamic radiation dose rate range, approaching 10 to the 7th power. Simultaneously the EPS has the capability to process data from extremely high radiation fields such as might be encountered in the wake of an intense solar flare.

Source record↗
NASA NTRS2019

Seeker 1.0: Prototype Robotic Free Flying Inspector Mission Overview

Seeker 1.0 is a prototype free flying robot that will one day be capable of inspecting human-rated spacecraft. Building off previous free flyer experience, this technology will eventually improve safety of human spacecraft by offering a variety of inspection capabilities for both routine and emergency scenarios providing increased capability and safety over current inspection methods. Seeker 1.0 is capable of 6 degree of freedom flight via a cold gas propulsion system and can operate up to 1 hour via a semi-autonomous guidance, navigation, and control system. The prototype spacecraft is capable of capturing still images at a variety of resolutions up to 13 MP. The initial test flight utilizes a command and data relay box called Kenobi. Kenobi is a derivative of the Seeker design and will communicate between Cygnus and Seeker and store data for post-mission downlink. Seeker and Kenobi have launched inside a NanoRacks External CubeSat Deployer (NRCSD-E) attached to the NG-11 Cygnus ISS resupply vehicle and will operate after Cygnus departs ISS and moves to a safe altitude. Operations will last approximately 30 minutes and will consist of basic vehicle maneuvers while capturing high-resolution still images. With any remaining time and propellant, Seeker will demonstrate additional safety capabilities and maneuvers required for operations around a crewed spacecraft. The Seeker project utilized the Class IE process that allows for streamlined flight hardware development and increased mission risk tolerance.

Spacecraft Inspection↗
NASA NTRS1988

Utilities for master source code distribution: MAX and Friends

MAX is a program for the manipulation of FORTRAN master source code (MSC). This is a technique by which one maintains one and only one master copy of a FORTRAN program under a program developing system, which for MAX is assumed to be VAX/VMS. The master copy is not intended to be directly compiled. Instead it must be pre-processed by MAX to produce compilable instances. These instances may correspond to different code versions (for example, double precision versus single precision), different machines (for example, IBM, CDC, Cray) or different operating systems (i.e., VAX/VMS versus VAX/UNIX). The advantage os using a master source is more pronounced in complex application programs that are developed and maintained over many years and are to be transported and executed on several computer environments. The version lag problem that plagues many such programs is avoided by this approach. MAX is complemented by several auxiliary programs that perform nonessential functions. The ensemble is collectively known as MAX and Friends. All of these programs, including MAX, are executed as foreign VAX/VMS commands and can easily be hidden in customized VMS command procedures.

Felippa, Carlos A.↗
NASA NTRS1990

Functional description of a command and control language tutor

The status of an ongoing project to explore the application of Intelligent Tutoring System (ITS) technology to NASA command and control languages is described. The primary objective of the current phase of the project is to develop a user interface for an ITS to assist NASA control center personnel in learning Systems Test and Operations Language (STOL). Although this ITS will be developed for Gamma Ray Observatory operators, it will be designed with sufficient flexibility so that its modules may serve as an ITS for other control languages such as the User Interface Language (UIL). The focus of this phase is to develop at least one other form of STOL representation to complement the operational STOL interface. Such an alternative representation would be adaptively employed during the tutoring session to facilitate the learning process. This is a key feature of this ITS which distinguishes it from a simulator that is only capable of representing the operational environment.

Elke, David R.↗
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↗
NASA NTRS2008

Distributing Data to Hand-Held Devices in a Wireless Network

ADROIT is a developmental computer program for real-time distribution of complex data streams for display on Web-enabled, portable terminals held by members of an operational team of a spacecraft-command-and-control center who may be located away from the center. Examples of such terminals include personal data assistants, laptop computers, and cellular telephones. ADROIT would make it unnecessary to equip each terminal with platform- specific software for access to the data streams or with software that implements the information-sharing protocol used to deliver telemetry data to clients in the center. ADROIT is a combination of middleware plus software specific to the center. (Middleware enables one application program to communicate with another by performing such functions as conversion, translation, consolidation, and/or integration.) ADROIT translates a data stream (voice, video, or alphanumerical data) from the center into Extensible Markup Language, effectuates a subscription process to determine who gets what data when, and presents the data to each user in real time. Thus, ADROIT is expected to enable distribution of operations and to reduce the cost of operations by reducing the number of persons required to be in the center.

Hodges, Mark↗
DOE OSTI2025

ELM model simulations of Plum Island Ecosystems LTER low marsh site 2018-2020

Model simulations using the Department of Energy's Energy Exascale Earth System Model (E3SM) land model (ELM) with improved capabilities to represent vegetation response to salinity and inundation. The simulations were conducted for a tidal salt marsh at Plum Island Ecosystems Long Term Ecological Research (LTER) site near Rowley, Massachusetts, USA; the site is a low marsh dominated by Spartina alterniflora. The model was forced with site-specific meteorology, salinity and tidal cycles from 2018-2020. Four sets of model simulations are included and described below:1. Parameterization of the salinity response function. These simulations tested different combinations of values for optimal salinity and salinity tolerance.2. Model evaluation. This comparison conducted simulations using the default model, the salinity function only, the submergence function only, and both the salinity and submergence functions. 3. Salinity scenarios. These simulations used the 2018 salinity input data varied by -5 to +10 ppt salinity.4. Water level scenarios. These simulations used the tide height varied by -10 to +50 cm. These simulations were used to demonstrate how the salinity and submergence functions better represent carbon uptake by tidal salt marshes.The data package includes netCDF files used as forcing files for tide height and salinity, one for each year 2018-2020 at observed salinity concentrations, and an additional three forcing files in which salinity concentrations were varied 5 ppt lower, 5 ppt higher, and 10 ppt higher than the measured 2018 time series. Also included are python scripts for creating forcing files, plain text parameter and command files for running simulations, model outputs in netCDF format, and python scripts for visualizing outputs. Code for the modified E3SM model is archived in Sulman et al 2023 at doi:10.15485/1991625. More detail about files is provided in the README.md file.

54 ENVIRONMENTAL SCIENCES↗
NASA NTRS1989

Flight software development for the isothermal dendritic growth experiment

The Isothermal Dendritic Growth Experiment (IDGE) is a microgravity materials science experiment scheduled to fly in the cargo bay of the shuttle on the United States Microgravity Payload (USMP) carrier. The experiment will be operated by real-time control software which will not only monitor and control onboard experiment hardware, but will also communicate, via downlink data and uplink commands, with the Payload Operations Control Center (POCC) at NASA George C. Marshall Space Flight Center (MSFC). The software development approach being used to implement this system began with software functional requirements specification. This was accomplished using the Yourdon/DeMarco methodology as supplemented by the Ward/Mellor real-time extensions. The requirements specification in combination with software prototyping was then used to generate a detailed design consisting of structure charts, module prologues, and Program Design Language (PDL) specifications. This detailed design will next be used to code the software, followed finally by testing against the functional requirements. The result will be a modular real-time control software system with traceability through every phase of the development process.

Levinson, Laurie H.↗
NASA NTRS1990

Flight software development for the isothermal dendritic growth experiment

The Isothermal Dendritic Growth Experiment (IDGE) is a microgravity materials science experiment scheduled to fly in the cargo bay of the shuttle on the United States Microgravity Payload (USMP) carrier. The experiment will be operated by real-time control software which will not only monitor and control onboard experiment hardware, but will also communicate, via downlink data and unlink commands, with the Payload Operations Control Center (POCC) at NASA George C. Marshall Space Flight Center (MSFC). The software development approach being used to implement this system began with software functional requirements specification. This was accomplished using the Yourdon/DeMarco methodology as supplemented by the Ward/Mellor real-time extensions. The requirements specification in combination with software prototyping was then used to generate a detailed design consisting of structure charts, module prologues, and Program Design Language (PDL) specifications. This detailed design will next be used to code the software, followed finally by testing against the functional requirements. The result will be a modular real-time control software system with traceability through every phase of the development process.

Levinson, Laurie H.↗
NASA NTRS2007

Hydra Rendezvous and Docking Sensor

The U.S. technology to support a CEV AR&D activity is mature and was developed by NASA and supporting industry during an extensive research and development program conducted during the 1990's and early 2000 time frame at the Marshall Space Flight Center. Development and demonstration of a rendezvous/docking sensor was identified early in the AR&D Program as the critical enabling technology that allows automated proxin~ity operations and docking. A first generation rendezvous/docking sensor, the Video Guidance Sensor (VGS) was developed and successfully flown on STS 87 and again on STS 95, proving the concept of a video-based sensor. Advances in both video and signal processing technologies and the lessons learned from the two successful flight experiments provided a baseline for the development of a new generation of video based rendezvous/docking sensor. The Advanced Video Guidance Sensor (AVGS) has greatly increased performance and additional capability for longer-range operation. A Demonstration Automatic Rendezvous Technology (DART) flight experiment was flown in April 2005 using AVGS as the primary proximity operations sensor. Because of the absence of a docking mechanism on the target satellite, this mission did not demonstrate the ability of the sensor to co~ltrold ocking. Mission results indicate that the rendezvous sensor operated successfully in "spot mode" (2 km acquisition of the target, bearing data only) but was never commanded to "acquire and track" the docking target. Parts obsolescence issues prevent the construction of current design AVGS units to support the NASA Exploration initiative. This flight proven AR&D technology is being modularized and upgraded with additional capabilities through the Hydra project at the Marshall Space Flight Center. Hydra brings a unique engineering approach and sensor architecture to the table, to solve the continuing issues of parts obsolescence and multiple sensor integration. This paper presents an approach to sensor hardware trades, to address the needs of future vehicles that may rendezvous and dock with the International Space Station (ISS). It will also discuss approaches for upgrading AVGS to address parts obsolescence, and concepts for modularizing the sensor to provide configuration flexibility for multiple vehicle applications. Options for complementary sensors to be integrated into the multi-head Hydra system will also be presented. Complementary sensor options include ULTOR, a digital image correlator system that could provide relative six-degree-of-freedom information independently from AVGS, and time-of-flight sensors, which determine the range between vehicles by timing pulses that travel from the sensor to the target and back. Common targets and integrated targets, suitable for use with the multi-sensor options in Hydra, will also be addressed.

Roe, Fred↗
NASA NTRS2008

Facilitating Analysis of Multiple Partial Data Streams

Robotic Operations Automation: Mechanisms, Imaging, Navigation report Generation (ROAMING) is a set of computer programs that facilitates and accelerates both tactical and strategic analysis of time-sampled data especially the disparate and often incomplete streams of Mars Explorer Rover (MER) telemetry data described in the immediately preceding article. As used here, tactical refers to the activities over a relatively short time (one Martian day in the original MER application) and strategic refers to a longer time (the entire multi-year MER missions in the original application). Prior to installation, ROAMING must be configured with the types of data of interest, and parsers must be modified to understand the format of the input data (many example parsers are provided, including for general CSV files). Thereafter, new data from multiple disparate sources are automatically resampled into a single common annotated spreadsheet stored in a readable space-separated format, and these data can be processed or plotted at any time scale. Such processing or plotting makes it possible to study not only the details of a particular activity spanning only a few seconds, but also longer-term trends. ROAMING makes it possible to generate mission-wide plots of multiple engineering quantities [e.g., vehicle tilt as in Figure 1(a), motor current, numbers of images] that, heretofore could be found only in thousands of separate files. ROAMING also supports automatic annotation of both images and graphs. In the MER application, labels given to terrain features by rover scientists and engineers are automatically plotted in all received images based on their associated camera models (see Figure 2), times measured in seconds are mapped to Mars local time, and command names or arbitrary time-labeled events can be used to label engineering plots, as in Figure 1(b).

Maimone, Mark W.↗
NASA NTRS2011

MicroShell Minimalist Shell for Xilinx Microprocessors

MicroShell is a lightweight shell environment for engineers and software developers working with embedded microprocessors in Xilinx FPGAs. (MicroShell has also been successfully ported to run on ARM Cortex-M1 microprocessors in Actel ProASIC3 FPGAs, but without project-integration support.) Micro Shell decreases the time spent performing initial tests of field-programmable gate array (FPGA) designs, simplifies running customizable one-time-only experiments, and provides a familiar-feeling command-line interface. The program comes with a collection of useful functions and enables the designer to add an unlimited number of custom commands, which are callable from the command-line. The commands are parameterizable (using the C-based command-line parameter idiom), so the designer can use one function to exercise hardware with different values. Also, since many hardware peripherals instantiated in FPGAs have reasonably simple register-mapped I/O interfaces, the engineer can edit and view hardware parameter settings at any time without stopping the processor. MicroShell comes with a set of support scripts that interface seamlessly with Xilinx's EDK tool. Adding an instance of MicroShell to a project is as simple as marking a check box in a library configuration dialog box and specifying a software project directory. The support scripts then examine the hardware design, build design-specific functions, conditionally include processor-specific functions, and complete the compilation process. For code-size constrained designs, most of the stock functionality can be excluded from the compiled library. When all of the configurable options are removed from the binary, MicroShell has an unoptimized memory footprint of about 4.8 kB and a size-optimized footprint of about 2.3 kB. Since MicroShell allows unfettered access to all processor-accessible memory locations, it is possible to perform live patching on a running system. This can be useful, for instance, if a bug is discovered in a routine but the system cannot be rebooted: Shell allows a skilled operator to directly edit the binary executable in memory. With some forethought, MicroShell code can be located in a different memory location from custom code, permitting the custom functionality to be overwritten at any time without stopping the controlling shell.

Werne, Thomas A.↗