Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “hardware and software”

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 757 records · Page 42

NASA's Moon to Mars Autonomous Habitat Status

NASA is developing a strategy for sending humans to the Mars vicinity, known broadly as the Moon to Mars (M2M) Campaign. A critical part of this campaign is the development of in-space and surface habitation systems capable of substantially extending human presence beyond Low Earth Orbit (LEO). Mars missions feature an in-space transit habitat capable of supporting crews of four on ~850-1200-day missions, including transit to and from Mars and time in Mars orbit. Surface and transit habitats are complex elements which must keep crewmembers healthy and productive in deep-space environments with limited resources, long rescue times in contingency situations, and communication delays; all within constrained mass, volume, and power budgets. These habitats provide crew both living and workspace as well as most of the resources needed to support crew life. For deep space habitats, automation needs to be employed due to latency and for significant amounts of time when the habitats are uncrewed. Automation of systems is possible in space applications, but there are limitations. Outside of the Earth’s (or any) magnetosphere, radiation environments are harsh to both the physical hardware and the software components. Radiation (charged particles and ionizing electromagnetic waves) degrades and damages the hardware and causes single event upsets (SEUs) in software. If the hardware is damaged, data can be lost, or control actions not made. For software, SEUs cause algorithms to result in different solutions, or incorrect commands to be sent out. This means that algorithms and hardware used for deep space systems are different than what is used on Earth. Radiation-tolerant hardware is generations behind the current state-of-the-art hardware. Recent NASA missions, such as James Webb Space Telescope, continue to rely on older technologies such as the RAD750 processor, and the most advanced processors are still single core and less than 1.5 GHz. There have been attempts to use higher performance processors, but these often take multiple mitigation steps to handle the radiation environments, which limits the processing power and/or throughput. Current techniques for radiation mitigation have been redundancies, voting, physical separation of hardware, encasing materials, under-clocking hardware, and more. Some radiation mitigation techniques do provide benefits such as having a redundant system to improve the probability that a system will be available when needed. Autonomous software systems will have fewer interactions with humans on deep space missions and therefore need to be able to handle more off-nominal conditions. Microgravity also complicates the autonomous aspects of the mission because autonomous systems are usually built from known deterministic states, but microgravity causes physical objects to shift and move changing the location an autonomous system placed the object. Not only does the software need to be reliable and deterministic, losing resources due to a software error is not only costly but detrimental to reputation. The combination of having lower performance hardware and having to be able to verify and deterministically run software and an ever-changing environment makes deep space autonomous systems more complicated. Multiple gaps have been identified including verification of autonomous software algorithms (including artificial intelligence and machine learning), higher performance processors (graphics and general purpose), high speed networks (onboard and transmissions), memory, power distribution, data security, and variations from these. These gaps need to be closed for more advanced systems to be deployed and reduce the size, weight, and power impacts on the habitats.

Scott B. Tashakkor↗

Modular Subsurface Sensors and Integrated Software for Advanced Subsurface Characterization and Monitoring using Unoccupied Vehicles

The advent and subsequent proliferation of autonomous airborne, waterborne, and groundbased vehicles (i.e., “drones”) promises to broadly transform the geosciences and associated industries, including fossil energy exploration and development, mineral resource exploration and development, water-resource management, and environmental remediation. For geophysical characterization and monitoring, the prospect of programming highly repeatable and low-cost drone missions for subsurface imaging will allow for deployments in hazardous and previously inaccessible areas. Coupled with autonomous workflows for data processing, management, and visualization, drone-based geophysical characterization and monitoring will enable unprecedented, real-time insight into diverse subsurface properties and processes of scientific and engineering importance. Toward this end, the objectives of this Lab Directed Research and Development (LDRD) project were to develop new (1) instrumentation for dronebased electromagnetic induction (EMI) geophysical imaging, including separated transmitter and receivers and associated electronics, (2) software for real-time data telemetry, processing, management, and visualization. Although EMI has been previously deployed using unoccupied aerial systems (UASs), these applications failed to capitalize on the game-changing capabilities of drone platforms. Whereas drone-based data acquisition allows for collection of rich, three-dimensional (3D) multi-offset/multi-angle configurations between transmitters and receivers, past efforts have relied on conventional instrumentation that was designed for ground-based data collection with the transmitter and a single receiver housed in the same unit; nor did these previous applications demonstrate real-time delivery of results to support rapid management decisions in the field. In this 1-year project, we (1) designed and constructed new lightweight independent transmitter and receiver antenna platforms that communicate with a laptop computer; (2) developed software to control data acquisition, manage/transfer data, and visualize data as its collected; and (3) demonstrated the operation of the new hardware and software systems in a ground-based field test. Our work entails major technological advances for EMI and established a foundation on which to build a new drone-based, real-time geophysical EMI imaging capability to support diverse challenges facing the nation.

47 OTHER INSTRUMENTATION↗

The role of simulation in the development and flight test of the HiMAT vehicle

Real time simulations have been essential in the flight test program of the highly maneuverable aircraft technology (HiMAT) remotely piloted research vehicle at NASA Ames Research Center's Dryden Flight Research Facility. The HiMAT project makes extensive use of simulations in design, development, and qualification for flight, pilot training, and flight planning. Four distinct simulations, each with varying amounts of hardware in the loop, were developed for the HiMAT project. The use of simulations in detecting anomalous behavior of the flight software and hardware at the various stages of development, verification, and validation has been the key to flight qualification of the HiMAT vehicle.

Evans, M. B.↗

Software Productivity of Field Experiments Using the Mobile Agents Open Architecture with Workflow Interoperability

We analyzed a series of ten systematically developed surface exploration systems that integrated a variety of hardware and software components. Design, development, and testing data suggest that incremental buildup of an exploration system for long-duration capabilities is facilitated by an open architecture with appropriate-level APIs, specifically designed to facilitate integration of new components. This improves software productivity by reducing changes required for reconfiguring an existing system.

Clancey, William J.↗

Determination of Barometric Altimeter Errors for the Orion Exploration Flight Test-1 Entry

The EFT-1 mission is the unmanned flight test for the upcoming Multi-Purpose Crew Vehicle (MPCV). During entry, the EFT-1 vehicle will trigger several Landing and Recovery System (LRS) events, such as parachute deployment, based on onboard altitude information. The primary altitude source is the filtered navigation solution updated with GPS measurement data. The vehicle also has three barometric altimeters that will be used to measure atmospheric pressure during entry. In the event that GPS data is not available during entry, the altitude derived from the barometric altimeter pressure will be used to trigger chute deployment for the drogues and main parachutes. Therefore it is important to understand the impact of error sources on the pressure measured by the barometric altimeters and on the altitude derived from that pressure. There are four primary error sources impacting the sensed pressure: sensor errors, Analog to Digital conversion errors, aerodynamic errors, and atmosphere modeling errors. This last error source is induced by the conversion from pressure to altitude in the vehicle flight software, which requires an atmosphere model such as the US Standard 1976 Atmosphere model. There are several secondary error sources as well, such as waves, tides, and latencies in data transmission. Typically, for error budget calculations it is assumed that all error sources are independent, normally distributed variables. Thus, the initial approach to developing the EFT-1 barometric altimeter altitude error budget was to create an itemized error budget under these assumptions. This budget was to be verified by simulation using high fidelity models of the vehicle hardware and software. The simulation barometric altimeter model includes hardware error sources and a data-driven model of the aerodynamic errors expected to impact the pressure in the midbay compartment in which the sensors are located. The aerodynamic model includes the pressure difference between the midbay compartment and the free stream pressure as a function of altitude, oscillations in sensed pressure due to wake effects, and an acoustics model capturing fluctuations in pressure due to motion of the passive vents separating the barometric altimeters from the outside of the vehicle.

Brown, Denise L.↗

Implementing a Hardware Testbed Using 3-Level ANPC Software Defined Inverters for Fault Analysis of a Transmission Network

In this paper, we propose the implementation of a hardware testbed using 3-level active neutral point clamped (ANPC) software-defined inverters for fault analysis. A test case transmission network equipped with two grid forming (GFM) inverters and four resistive loads is considered in this research. Firstly, grid forming control laws including PI feedback control and droop control are implemented to operate the inverters in parallel. Then, we implement a fault ride-through (FRT) logic and perform a simulation of the test system by applying a three-phase fault. Simulation results show the effectiveness of the fault recovery algorithm upon clearance of the fault. Finally, a 3-level ANPC software-defined inverter is programmed with required control laws and characterized through various lab experiments.

3-level ANPC inverter↗

Shuttle Avionics Integration Laboratory

The SAIL (Shuttle Avionics Integration Laboratory) has been established to provide direct in-line support to the space shuttle program. The SAIL provides a central facility where the avionics and related flight hardware, flight software, and flight procedures will be brought together for integration and verification testing. The basic approach is to utilize qualifiable avionics flight hardware to the greatest extent possible. Where this is not feasible, flight hardware simulators are developed that provide the electrical/electronic termination, stimulation, and signal interface to the flight hardware that it would actually encounter in the shuttle vehicle. This paper discusses the existing laboratory configuration supporting the approach and landing test phase of the shuttle program, the operational experience gained to date, and the design of the laboratory elements to support the orbital flight test phase.

Chambers, T. V.↗

The M68HC11 gripper controller software

This thesis discusses the development of firmware for the 68HC11 gripper controller. A general description of the software and hardware interfaces is given. The C library interface for the gripper is then described and followed by a detailed discussion of the software architecture of the firmware. A procedure to assemble and download 68HC11 programs is presented in the form of a tutorial. The tools used to implement this environment are then described. Finally, the implementation of the configuration management scheme used to manage all CIRSSE software is presented.

Tsai, Jodi Wei-Duk↗

PI in the sky: The astronaut science advisor on SLS-2

The Astronaut Science Advisor (ASA, also known as Principal-Investigator-in-a-Box) is an advanced engineering effort to apply expert systems technology to experiment monitoring and control. Its goal is to increase the scientific value of information returned from experiments on manned space missions. The first in-space test of the system will be in conjunction with Professor Larry Young's (MIT) vestibulo-ocular 'Rotating Dome' experiment on the Spacelab Life Sciences 2 mission (STS-58) in the Fall of 1993. In a cost-saving effort, off-the-shelf equipment was employed wherever possible. Several modifications were necessary in order to make the system flight-worthy. The software consists of three interlocking modules. A real-time data acquisition system digitizes and stores all experiment data and then characterizes the signals in symbolic form; a rule-based expert system uses the symbolic signal characteristics to make decisions concerning the experiment; and a highly graphic user interface requiring a minimum of user intervention presents information to the astronaut operator. Much has been learned about the design of software and user interfaces for interactive computing in space. In addition, we gained a great deal of knowledge about building relatively inexpensive hardware and software for use in space. New technologies are being assessed to make the system a much more powerful ally in future scientific research in space and on the ground.

Hazelton, Lyman R.↗

Simulation of MC-1 Engine on Real-Time Station

The MC-1 rocket engine is a new, 60,000-pound-thrust engine designed to boost small spacecraft carrying payloads weighing up to 500 pounds. The engine was designed in-house at NASA's Marshall Space Flight Center (MSFC) in Huntsville, Alabama, and built by SUMMA Technology, Inc. A vital part of the success of the engine development was the verification of the Propulsion System Controller (PSC) used to control the MC-1 engine during development testing at test facilities in Mississippi and California. The MC-1 engine simulation software was developed on the Applied Dynamics, Inc.'s Real-Time Station (RTS) computer system (ESL) to verify the PSC's hardware and software performance in the Marshall Avionics System Testbed's (MAST) Engine Simulation Lab at the MSFC. The engine model includes the simulation of pressure transducers, thermocouple sensors and valve-positions.

Ly, William↗

Actions, Observations, and Decision-Making: Biologically Inspired Strategies for Autonomous Aerial Vehicles

This paper details the development and demonstration of an autonomous aerial vehicle embodying search and find mission planning and execution srrategies inspired by foraging behaviors found in biology. It begins by describing key characteristics required by an aeria! explorer to support science and planetary exploration goals, and illustrates these through a hypothetical mission profile. It next outlines a conceptual bio- inspired search and find autonomy architecture that implements observations, decisions, and actions through an "ecology" of producer, consumer, and decomposer agents. Moving from concepts to development activities, it then presents the results of mission representative UAV aerial surveys at a Mars analog site. It next describes hardware and software enhancements made to a commercial small fixed-wing UAV system, which inc!nde a ncw dpvelopnent architecture that also provides hardware in the loop simulation capability. After presenting the results of simulated and actual flights of bioinspired flight algorithms, it concludes with a discussion of future development to include an expansion of system capabilities and field science support.

Pisanich, Greg↗

MARVEL Instrumentation, Control, and Software Considerations

This paper details the various I&C considerations and design decisions made throughout the MARVEL (Micro-reactor Applications Research Validation and Evaluation) project, including sensor and actuator selection, safety-related functionality, digital control hardware and software, and testing methodologies. Key challenges such as managing radiation, temperature, and space constraints are discussed, along with the trade-offs between using standard equipment and custom solutions. The successful integration of off-the-shelf components, the emphasis on minimizing safety-related instrumentation, and the lessons learned from prototyping and testing are highlighted. The authors aim to provide insights that can benefit future micro-reactor designs and emphasize the importance of real-world testing in advancing reactor technology.

46 - INSTRUMENTATION RELATED TO NUCLEAR SCIENCE AN↗

TMS communications software. Volume 1: Computer interfaces

A prototype bus communications system, which is being used to support the Trend Monitoring System (TMS) as well as for evaluation of the bus concept is considered. Hardware and software interfaces to the MODCOMP and NOVA minicomputers are included. The system software required to drive the interfaces in each TMS computer is described. Documentation of other software for bus statistics monitoring and for transferring files across the bus is also included.

Brown, J. S.↗

Feasibility study of the solar scientific instruments for Spacelab/Orbiter

The feasibility and economics of mounting and operating a set of solar scientific instruments in the backup Skylab Apollo Telescope Mount (ATM) hardware was evaluated. The instruments used as the study test payload and integrated into the ATM were: the Solar EUV Telescope/Spectrometer; the Solar Active Region Observing Telescope; and the Lyman Alpha White Light Coronagraph. The backup ATM hardware consists of a central cruciform structure, called the "SPAR', a "Sun End Canister' and a "Multiple Docking Adapter End Canister'. Basically, the ATM hardware and software provides a structural interface for the instruments; a closely controlled thermal environment; and a very accurate attitude and pointing control capability. The hardware is an identical set to the hardware that flow on Skylab.

Leritz, J.↗

Medical Signal-Conditioning and Data-Interface System

A general-purpose portable, wearable electronic signal-conditioning and data-interface system is being developed for medical applications. The system can acquire multiple physiological signals (e.g., electrocardiographic, electroencephalographic, and electromyographic signals) from sensors on the wearer s body, digitize those signals that are received in analog form, preprocess the resulting data, and transmit the data to one or more remote location(s) via a radiocommunication link and/or the Internet. The system includes a computer running data-object-oriented software that can be programmed to configure the system to accept almost any analog or digital input signals from medical devices. The computing hardware and software implement a general-purpose data-routing-and-encapsulation architecture that supports tagging of input data and routing the data in a standardized way through the Internet and other modern packet-switching networks to one or more computer(s) for review by physicians. The architecture supports multiple-site buffering of data for redundancy and reliability, and supports both real-time and slower-than-real-time collection, routing, and viewing of signal data. Routing and viewing stations support insertion of automated analysis routines to aid in encoding, analysis, viewing, and diagnosis.

Braun, Jeffrey↗

Space Telecommunications Radio System (STRS) Compliance Testing

The Space Telecommunications Radio System (STRS) defines an open architecture for software defined radios. This document describes the testing methodology to aid in determining the degree of compliance to the STRS architecture. Non-compliances are reported to the software and hardware developers as well as the NASA project manager so that any non-compliances may be fixed or waivers issued. Since the software developers may be divided into those that provide the operating environment including the operating system and STRS infrastructure (OE) and those that supply the waveform applications, the tests are divided accordingly. The static tests are also divided by the availability of an automated tool that determines whether the source code and configuration files contain the appropriate items. Thus, there are six separate step-by-step test procedures described as well as the corresponding requirements that they test. The six types of STRS compliance tests are: STRS application automated testing, STRS infrastructure automated testing, STRS infrastructure testing by compiling WFCCN with the infrastructure, STRS configuration file testing, STRS application manual code testing, and STRS infrastructure manual code testing. Examples of the input and output of the scripts are shown in the appendices as well as more specific information about what to configure and test in WFCCN for non-compliance. In addition, each STRS requirement is listed and the type of testing briefly described. Attached is also a set of guidelines on what to look for in addition to the requirements to aid in the document review process.

Handler, Louis M.↗

A software system for emission spectrometry

A computer system was developed for an emission spectrometry facility consisting of a direct current (DC) argon arc spectrograph optically coupled to an inductively coupled plasma multichannel spectrometer. Custom hardware and software were designed to control analytical functions and perform data acquisition. The software system was designed to make operation of the facility simple for routine operation and flexible for research and development. Special software was written to collect data under controlled conditions to characterize and monitor system response. One sequence collects intensity versus time data on all channels and displays the data graphically. These profiles are useful in studying the effects of operating parameters on measurement precision. Another special sequence performs calibration using a spline curve fit procedure. Routines were also written to measure dark currents and signals from a standard tungsten halogen lamp mounted in place of the DC arc. For quality control purposes, histories of these values are kept and monitored for excess scatter or drift.

Auping, J. V.↗

The Development of Two Science Investigator-led Processing Systems (SIPS) for NASA's Earth Observation System (EOS)

In 2001, NASA Goddard Space Flight Center's Laboratory for Terrestrial Physics started the construction of a science Investigator-led Processing System (SIPS) for processing data from the Ozone Monitoring Instrument (OMI) which will launch on the Aura platform in mid 2004. The Ozone Monitoring Instrument (OMI) is a contribution of the Netherlands Agency for Aerospace Programs (NIVR) in collaboration with the Finnish Meteorological Institute (FMI) to the Earth Observing System (EOS) Aura mission. It will continue the Total Ozone Monitoring System (TOMS) record for total ozone and other atmospheric parameters related to ozone chemistry and climate. OMI measurements will be highly synergistic with the other instruments on the EOS Aura platform. The LTP previously developed the Moderate Resolution Imaging Spectrometer (MODIS) Data Processing System (MODAPS), which has been in full operations since the launches of the Terra and Aqua spacecrafts in December, 1999 and May, 2002 respectively. During that time, it has continually evolved to better support the needs of the MODIS team. We now run multiple instances of the system managing faster than real time reprocessings of the data as well as continuing forward processing. The new OMI Data Processing System (OMIDAPS) was adapted from the MODAPS. It will ingest raw data from the satellite ground station and process it to produce calibrated, geolocated higher level data products. These data products will be transmitted to the Goddard Distributed Active Archive Center (GDAAC) instance of the Earth Observing System (EOS) Data and Information System (EOSDIS) for long term archive and distribution to the public. The OMIDAPS will also provide data distribution to the OMI Science Team for quality assessment, algorithm improvement, calibration, etc. We have taken advantage of lessons learned from the MODIS experience and software already developed for MODIS. We made some changes in the hardware system organization, database and software to adapt the system for OMI. We replaced the fundamental database system, Sybase, with an Open Source RDBMS called PostgreSQL, and based the entire OMIDAPS on a cluster of Linux based commodity computers rather than the large SGI servers that MODAPS uses. Rather than relying on a central I/O server host, the new system distributes its data archive among multiple server hosts in the cluster. OMI is also customizing the graphical user interfaces and reporting structure to more closely meet the needs of the OMI Science Team. Prior to 2003, simulated OMI data and the science algorithms were not ready for production testing. We initially constructed a prototype system and tested using a 25 year dataset of Total Ozone Mapping Spectrometer (TOMS) and Solar Backscatter Ultraviolet Instrument (SBUV) data. This prototype system provided a platform to support the adaptation of the algorithms for OMI, and provided reprocessing of the historical data aiding in its analysis. In a recent reanalysis of the TOMS data, the OMIDAPS processed 108,000 full orbits of data through 4 processing steps per orbit, producing about 800,000 files (400 GiB) of level 2 and greater data files. More recently we have installed two instances of the OMIDAPS for integration and testing of OM1 science processes as they get delivered from the Science Team. A Test instance of the OMIDAPS has also supported a series of "Interface Confidence Tests" (ICTs) and End-to-End Ground System tests to ensure the launch readiness of the system. This paper will discuss the high-level hardware, software, and database organization of the OMIDAPS and how it builds on the MODAPS heritage system. It will also provide an overview of the testing and implementation of the production OMIDAPS.

Tilmes, Curt↗