Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “control 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 1,513 records · Page 84
All sourcesNASA NTRSDOE OSTI
NASA NTRS1992

Spacelab, Spacehab, and Space Station Freedom payload interface projects

Contributions were made to several projects. Howard Nguyen was assisted in developing the Space Station RPS (Rack Power Supply). The RPS is a computer controlled power supply that helps test equipment used for experiments before the equipment is installed on Space Station Freedom. Ron Bennett of General Electric Government Services was assisted in the design and analysis of the Standard Interface Rack Controller hardware and software. An analysis was made of the GPIB (General Purpose Interface Bus), looking for any potential problems while transmitting data across the bus, such as the interaction of the bus controller with a data talker and its listeners. An analysis was made of GPIB bus communications in general, including any negative impact the bus may have on transmitting data back to Earth. A study was made of transmitting digital data back to Earth over a video channel. A report was written about the study and a revised version of the report will be submitted for publication. Work was started on the design of a PC/AT compatible circuit board that will combine digital data with a video signal. Another PC/AT compatible circuit board is being designed to recover the digital data from the video signal. A proposal was submitted to support the continued development of the interface boards after the author returns to Memphis State University in the fall. A study was also made of storing circuit board design software and data on the hard disk server of a LAN (Local Area Network) that connects several IBM style PCs. A report was written that makes several recommendations. A preliminary design review was started of the AIVS (Automatic Interface Verification System). The summer was over before any significant contribution could be made to this project.

Smith, Dean Lance↗
NASA NTRS2011

Software Architecture to Support the Evolution of the ISRU RESOLVE Engineering Breadboard Unit 2 (EBU2)

The In-Situ Resource Utilization (ISRU) Regolith & Environmental Science and Oxygen & Lunar Volatiles Extraction (RESOLVE) software provides operation of the physical plant from a remote location with a high-level interface that can access and control the data from external software applications of other subsystems. This software allows autonomous control over the entire system with manual computer control of individual system/process components. It gives non-programmer operators the capability to easily modify the high-level autonomous sequencing while the software is in operation, as well as the ability to modify the low-level, file-based sequences prior to the system operation. Local automated control in a distributed system is also enabled where component control is maintained during the loss of network connectivity with the remote workstation. This innovation also minimizes network traffic. The software architecture commands and controls the latest generation of RESOLVE processes used to obtain, process, and quantify lunar regolith. The system is grouped into six sub-processes: Drill, Crush, Reactor, Lunar Water Resource Demonstration (LWRD), Regolith Volatiles Characterization (RVC) (see example), and Regolith Oxygen Extraction (ROE). Some processes are independent, some are dependent on other processes, and some are independent but run concurrently with other processes. The first goal is to analyze the volatiles emanating from lunar regolith, such as water, carbon monoxide, carbon dioxide, ammonia, hydrogen, and others. This is done by heating the soil and analyzing and capturing the volatilized product. The second goal is to produce water by reducing the soil at high temperatures with hydrogen. This is done by raising the reactor temperature in the range of 800 to 900 C, causing the reaction to progress by adding hydrogen, and then capturing the water product in a desiccant bed. The software needs to run the entire unit and all sub-processes; however, throughout testing, many variables and parameters need to be changed as more is learned about the system operation. The Master Events Controller (MEC) is run on a standard laptop PC using Windows XP. This PC runs in parallel to another laptop that monitors the GC, and a third PC that monitors the drilling/ crushing operation. These three PCs interface to the process through a CompactRIO, OPC Servers, and modems.

Moss, Thomas↗
NASA NTRS1994

Laser velocimeter data acquisition system for the Langley 14- by 22-foot subsonic tunnel. Software reference guide version 3.3

The Laser Velocimeter Data Acquisition System (LVDAS) in the Langley 14- by 22-Foot Tunnel is controlled by a comprehensive software package. The software package was designed to control the data acquisition process during wind tunnel tests which employ a laser velocimeter measurement system. This report provides detailed explanations on how to configure and operate the LVDAS system to acquire laser velocimeter and static wind tunnel data.

Jumper, Judith K.↗
NASA NTRS2016

Open Source Next Generation Visualization Software for Interplanetary Missions

Mission control is evolving quickly, driven by the requirements of new missions, and enabled by modern computing capabilities. Distributed operations, access to data anywhere, data visualization for spacecraft analysis that spans multiple data sources, flexible reconfiguration to support multiple missions, and operator use cases, are driving the need for new capabilities. NASA's Advanced Multi-Mission Operations System (AMMOS), Ames Research Center (ARC) and the Jet Propulsion Laboratory (JPL) are collaborating to build a new generation of mission operations software for visualization, to enable mission control anywhere, on the desktop, tablet and phone. The software is built on an open source platform that is open for contributions (http://nasa.github.io/openmct).

software engineering↗
DOE OSTI2018

A new fuel modeling capability, CTFFuel, with a case study on the fuel thermal conductivity degradation

Here, a new fuel modeling capability, CTFFuel, is developed from the subchannel code, CTF. This code is a standalone interface to the CTF fuel rod models, allowing for fuel rod simulations to be run independently from the fluid. This paper provides an overview of the code with a case study on the thermal conductivity degradation of LWR fuels to demonstrate its capabilities. The modeling of fuel thermal conductivity degradation in the code is improved through the addition of new modeling options to account for the irradiation effects via globally defined parameters. After the initial implementation, a variety of order-of-accuracy tests and code comparisons are performed to test software quality. A controlled analysis is allowed by CTFFuel to verify the numerical scheme of CTF’s conduction solution and to benchmark its fuel temperature predictions against FRAPCON-4.0’s. Overall, the software quality and verification procedure ensures that the new model is coded correctly, that it properly interacts with the rest of the code.

11 NUCLEAR FUEL CYCLE AND FUEL MATERIALS↗
NASA NTRS1976

Space shuttle orbital maneuvering system failure detection and identification software requirements (uncontrolled)

Candidate designs and their software implementation are presented for the Orbital Maneuvering System (OMS) Failure Detection and Identification (FDI) algorithms in the Redundance Management (RM) module of the Space Shuttle Guidance, Navigation, and Control (GN&C) software. The OMS engine FDI algorithm monitors OMS engine thrust performance, and the OMS actuator FDI algorithm monitors OMS gimbal actuator performance. The software functional requirements of the algorithms are described along with the objective of each algorithm. A list of the assumptions which have governed its design, input/output requirements, a functional description of the algorithm (including a functional block diagram), and input interface requirements are given. The HAL (the language of the space shuttle flight computer) software formulation of the algorithms is considered including structured flowcharts of the procedures, estimates of flight computer core storage and CPU time, and processing requirements. A glossary of the symbols used to define the software requirements and formulations is included.

Damario, L. A.↗
NASA NTRS2010

Closed-Loop Simulation Study of the Ares I Upper Stage Thrust Vector Control Subsystem for Nominal and Failure Scenarios

As a replacement to the current Shuttle, the Ares I rocket and Orion crew module are currently under development by the National Aeronautics and Space Administration (NASA). This new launch vehicle is segmented into major elements, one of which is the Upper Stage (US). The US is further broken down into subsystems, one of which is the Thrust Vector Control (TVC) subsystem which gimbals the US rocket nozzle. Nominal and off-nominal simulations for the US TVC subsystem are needed in order to support the development of software used for control systems and diagnostics. In addition, a clear and complete understanding of the effect of off-nominal conditions on the vehicle flight dynamics is desired. To achieve these goals, a simulation of the US TVC subsystem combined with the Ares I vehicle as developed. This closed-loop dynamic model was created using Matlab s Simulink and a modified version of a vehicle simulation, MAVERIC, which is currently used in the Ares I project and was developed by the Marshall Space Flight Center (MSFC). For this report, the effects on the flight trajectory of the Ares I vehicle are investigated after failures are injected into the US TVC subsystem. The comparisons of the off-nominal conditions observed in the US TVC subsystem with those of the Ares I vehicle flight dynamics are of particular interest.

Chicatelli, Amy↗
NASA NTRS2006

Intersection Monitor for Traffic-Light-Preemption System

The figure shows an intersection monitor that is a key subsystem of an emergency traffic-light-preemption system that could be any of the systems described in the three immediately preceding articles and in Systems Would Preempt Traffic Lights for Emergency Vehicles (NPO-30573), NASA Tech Briefs, Vol. 28, No. 10 (October 2004), page 36. This unit is so named because it is installed at an intersection, where it monitors the phases (in the sense of timing) of the traffic lights. The mode of operation of this monitor is independent of the type of traffic-light-controller hardware or software in use at the intersection. Moreover, the design of the monitor is such that (1) the monitor does not, by itself, affect the operation of the traffic- light controller and (2) in the event of a failure of the monitor, the trafficlight controller continues to function normally (albeit without preemption). The monitor is installed in series with the traffic-light controller at an intersection. The control signals of interest are monitored by use of high-impedance taps on affected control lines. These taps are fully isolated and further protected by high-voltage diodes that prevent any voltages or short circuits that arise within the monitor from affecting the controller. The signals from the taps are processed digitally and cleaned up by use of high-speed logic gates, and the resulting data are passed on to other parts of the traffic-light-preemption intersection subsystem. The data are compared continuously with data from vehicles and used to calculate timing for reliable preemption of the traffic lights. The pedestrian crossing at the intersection is also monitored, and pedestrians are warned not to cross during preemption.

Bachelder, Aaron↗
DOE OSTI2020

Future Vision for Autonomous Ocean Observations

Autonomous platforms already make observations over a wide range of temporal and spatial scales, measuring salinity, temperature, nitrate, pressure, oxygen, biomass; and many other parameters. However, the observations are not comprehensive. Future autonomous systems need to be more affordable, more modular, more capable and easier to operate. Creative new types of platforms and new compact, low power, calibrated and stable sensors are under development to expand autonomous observations. Communications and recharging need bandwidth and power which can be supplied by standardized docking stations. In situ power generation will also extend endurance for many types of autonomous platforms, particularly autonomous surface vehicles. Standardized communications will improve ease of use, interoperability, and enable coordinated behaviors. Improved autonomy and communications will enable adaptive networks of autonomous platforms. Improvements in autonomy will have three aspects: hardware, control, and operations. As sensors and platforms have more onboard processing capability and energy capacity, more measurements become possible. Control systems and software will have the capability to address more complex states and sophisticated reactions to sensor inputs, which allows the platform to handle a wider variety of circumstances without direct operator control. Operational autonomy is increased by reducing operating costs. To maximize the potential of autonomous observations new standards and best practices are needed. In some applications, focus on common platforms and volume purchases could lead to significant cost reductions. Cost reductions could enable order-of-magnitude increases in platform operations and increase sampling resolution for a given level of investment. Energy harvesting technologies should be integral to the system design, for sensors, platforms, vehicles, and docking stations. Connections are needed between the marine energy and ocean observing communities to coordinate among funding sources, researchers, and end users. Regional teams should work with global organizations such as IOC/GOOS in governance development. International networks such as EGO for the emerging glider operations should also provide a forum for addressing governance. Networks of multiple vehicles can improve operational efficiencies and transform operational patterns. There is a need to develop operational architectures at regional and global scales to provide a backbone for active networking of autonomous platforms.

47 OTHER INSTRUMENTATION↗
NASA NTRS1986

Real-time simulator for helicopter rotor wind-tunnel operations

This paper describes the elements and operation of a simulator that is being used to train operators of the Rotor Test Apparatus (RTA) in the large-scale 40- by 80-Foot Wind Tunnel at Ames Research Center. The simulator, named TUTOR (for Tunnel Utilization Trainer with Operating Rotor) duplicates the controls of the rotor and its dynamic behavior, as well as the wind-tunnel controls. The simulation software uses a preexisting blade-element model of a four-bladed rotor with flapping and lead-lag degrees of freedom. Equations were developed for all hardware and controls of the RTA and of the wind tunnel that are normally required to perform a wind-tunnel test of a helicopter rotor. The simulator hardware consists of consoles designed to have the same appearance and functions as those in the control room of the 40- by 80-Foot Wind Tunnel, allowing input from three operators who normally establish the required operating conditions during a test run. Normal operating procedures can be practiced, as well as simulated emergencies such as rotor power failure.

Talbot, P. D.↗
NASA NTRS1988

The role of software engineering in the space station program

Software engineering applications snapshots within the Space Station Freedom Program; software engineering and Ada training; software reuse; hierarchial command and control; program characteristics; integrated, international environments; software production, integration, and management; and integrated simulation environment are outlined in viewgraph format.

Hall, Dana↗
NASA NTRS1995

Averting Denver Airports on a Chip

As a result of recent advances in software engineering capabilities, we are now in a more stable environment. De-facto hardware and software standards are emerging. Work on software architecture and design patterns signals a consensus on the importance of early system-level design decisions, and agreements on the uses of certain paradigmatic software structures. We now routinely build systems that would have been risky or infeasible a few years ago. Unfortunately, technological developments threaten to destabilize software design again. Systems designed around novel computing and peripheral devices will spark ambitious new projects that will stress current software design and engineering capabilities. Micro-electro-mechanical systems (MEMS) and related technologies provide the physical basis for new systems with the potential to produce this kind of destabilizing effect. One important response to anticipated software engineering and design difficulties is carefully directed engineering-scientific research. Two specific problems meriting substantial research attention are: A lack of sufficient means to build software systems by generating, extending, specializing, and integrating large-scale reusable components; and a lack of adequate computational and analytic tools to extend and aid engineers in maintaining intellectual control over complex software designs.

Sullivan, Kevin J.↗
NASA NTRS2017

Segmented Aperture Interferometric Nulling Testbed (SAINT) II: Component Systems Update

"This work presents updates to the coronagraph and telescope components of the Segmented Aperture Interfer-ometric Nulling Testbed (SAINT). The project pairs an actively-controlled macro-scale segmented mirror withthe Visible Nulling Coronagraph (VNC) towards demonstrating capabilities for the future space observatoriesneeded to directly detect and characterize a significant sample of Earth-sized worlds around nearby stars inthe quest for identifying those which may be habitable and possibly harbor life. Efforts to improve the VNCwavefront control optics and mechanisms towards repeating narrowband results are described. A narrative isprovided for the design of new optical components aimed at enabling broadband performance. Initial work withthe hardware and software interface for controlling the segmented telescope mirror is also presented."

high-contrast imaging↗
NASA NTRS1973

Titan 3E/Centaur D-1T Systems Summary

A systems and operational summary of the Titan 3E/Centaur D-1T program is presented which describes vehicle assembly facilities, launch facilities, and management responsibilities, and also provides detailed information on the following separate systems: (1) mechanical systems, including structural components, insulation, propulsion units, reaction control, thrust vector control, hydraulic systems, and pneumatic equipment; (2) astrionics systems, such as instrumentation and telemetry, navigation and guidance, C-Band tracking system, and range safety command system; (3) digital computer unit software; (4) flight control systems; (5) electrical/electronic systems; and (6) ground support equipment, including checkout equipment.

Source record↗
NASA NTRS1992

The VLBA correlator: Real-time in the distributed era

The correlator is the signal processing engine of the Very Long Baseline Array (VLBA). Radio signals are recorded on special wideband (128 Mb/s) digital recorders at the 10 telescopes, with sampling times controlled by hydrogen maser clocks. The magnetic tapes are shipped to the Array Operations Center in Socorro, New Mexico, where they are played back simultaneously into the correlator. Real-time software and firmware controls the playback drives to achieve synchronization, compute models of the wavefront delay, control the numerous modules of the correlator, and record FITS files of the fringe visibilities at the back-end of the correlator. In addition to the more than 3000 custom VLSI chips which handle the massive data flow of the signal processing, the correlator contains a total of more than 100 programmable computers, 8-, 16- and 32-bit CPUs. Code is downloaded into front-end CPU's dependent on operating mode. Low-level code is assembly language, high-level code is C running under a RT OS. We use VxWorks on Motorola MVME147 CPU's. Code development is on a complex of SPARC workstations connected to the RT CPU's by Ethernet. The overall management of the correlation process is dependent on a database management system. We use Ingres running on a Sparcstation-2. We transfer logging information from the database of the VLBA Monitor and Control System to our database using Ingres/NET. Job scripts are computed and are transferred to the real-time computers using NFS, and correlation job execution logs and status flow back by the route. Operator status and control displays use windows on workstations, interfaced to the real-time processes by network protocols. The extensive network protocol support provided by VxWorks is invaluable. The VLBA Correlator's dependence on network protocols is an example of the radical transformation of the real-time world over the past five years. Real-time is becoming more like conventional computing. Paradoxically, 'conventional' computing is also adopting practices from the real-time world: semaphores, shared memory, light-weight threads, and concurrency. This appears to be a convergence of thinking.

Wells, D. C.↗
NASA NTRS2003

Multiple Autonomous Discrete Event Controllers for Constellations

The Multiple Autonomous Discrete Event Controllers for Constellations (MADECC) project is an effort within the National Aeronautics and Space Administration Goddard Space Flight Center's (NASA/GSFC) Information Systems Division to develop autonomous positioning and attitude control for constellation satellites. It will be accomplished using traditional control theory and advanced coordination algorithms developed by the Johns Hopkins University Applied Physics Laboratory (JHU/APL). This capability will be demonstrated in the discrete event control test-bed located at JHU/APL. This project will be modeled for the Leonardo constellation mission, but is intended to be adaptable to any constellation mission. To develop a common software architecture. the controllers will only model very high-level responses. For instance, after determining that a maneuver must be made. the MADECC system will output B (Delta)V (velocity change) value. Lower level systems must then decide which thrusters to fire and for how long to achieve that (Delta)V.

Esposito, Timothy C.↗
DOE OSTI2013

Performing Probabilistic Risk Assessment Through RAVEN

The Reactor Analysis and Virtual control ENviroment (RAVEN) code is a software tool that acts as the control logic driver and post-processing engine for the newly developed Thermal-Hydraulic code RELAP-7. RAVEN is now a multi-purpose Probabilistic Risk Assessment (PRA) software framework that allows dispatching different functionalities: Derive and actuate the control logic required to simulate the plant control system and operator actions (guided procedures), allowing on-line monitoring/controlling in the Phase Space Perform both Monte-Carlo sampling of random distributed events and Dynamic Event Tree based analysis Facilitate the input/output handling through a Graphical User Interface (GUI) and a post-processing data mining module

99 GENERAL AND MISCELLANEOUS↗
NASA NTRS2011

FPA Depot - Web Application

Lines of code (LOC) analysis is one of the methods used to measure programmer productivity and estimate schedules of programming projects. The Launch Control System (LCS) had previously used this method to estimate the amount of work and to plan development efforts. The disadvantage of using LOC as a measure of effort is that one can only measure 30% to 35% of the total effort of software projects involves coding [8]. In the application, instead of using the LOC we are using function point for a better estimation of hours in each software to develop. Because of these disadvantages, Jamie Szafran of the System Software Branch of Control And Data Systems (NE-C3) at Kennedy Space Canter developed a web application called Function Point Analysis (FPA) Depot. The objective of this web application is that the LCS software architecture team can use the data to more accurately estimate the effort required to implement customer requirements. This paper describes the evolution of the domain model used for function point analysis as project managers continually strive to generate more accurate estimates.

Avila, Edwin M. Martinez↗