Engineering Papers⌕ Search

SEARCH · Engineering Papers

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 667 records · Page 37

Timeliner: Automating Procedures on the ISS

Timeliner has been developed as a tool to automate procedural tasks. These tasks may be sequential tasks that would typically be performed by a human operator, or precisely ordered sequencing tasks that allow autonomous execution of a control process. The Timeliner system includes elements for compiling and executing sequences that are defined in the Timeliner language. The Timeliner language was specifically designed to allow easy definition of scripts that provide sequencing and control of complex systems. The execution environment provides real-time monitoring and control based on the commands and conditions defined in the Timeliner language. The Timeliner sequence control may be preprogrammed, compiled from Timeliner "scripts," or it may consist of real-time, interactive inputs from system operators. In general, the Timeliner system lowers the workload for mission or process control operations. In a mission environment, scripts can be used to automate spacecraft operations including autonomous or interactive vehicle control, performance of preflight and post-flight subsystem checkouts, or handling of failure detection and recovery. Timeliner may also be used for mission payload operations, such as stepping through pre-defined procedures of a scientific experiment.

Brown, Robert↗

Planar slicing for nonextrusion AM processes

Extrusion-based AM processes, including material extrusion and directed energy deposition, construct objects by continuously depositing a relatively small amount of molten feedstock to a specific location. Nonextrusion AM processes, on the other hand, tend to form each layer by linearly or areally projecting either energy onto a vat of photocurable liquid or a binding agent into a bed of loose powder. Such systems vary significantly from extrusion-based AM processes but do share similarities. The general approach to path planning is the same, but nonextrusion processes typically favor the use of bitmap representations, instead of polygons, for pathing computation and do not use a g-code file to command the printer. In this chapter, a high-level discussion of these differences will be covered.

Macdonald, Eric↗

Machine Learning Automation Pipeline

Machine Learning Automation Pipeline (MLAP) is a package to perform machine learning (ML) analysis in a step by step manner, starting with data extraction until analysis and prediction. The scripts provide the users option to chose an action such as "Extract", "Prep", and "Train" and numerous cases can be launched with just a single command. The inputs for each case are provided using a JSON file. The simulation results of several cases can be assessed using an automated process and analyzed for various metrics pertinent to ML analysis.

Jha, Pankaj↗

Development of preliminary design concept for a multifunction display and control system for the Orbiter crew station. Task 4: Design concept recommendation

Application of multifunction display and control systems to the NASA Orbiter spacecraft offers the potential for reducing crew workload and improving the presentation of system status and operational data to the crew. A design concept is presented for the application of a multifunction display and control system (MFDCS) to the Orbital Maneuvering System and Electrical Power Distribution and Control System on the Orbiter spacecraft. The MFDCS would provide the capability for automation of procedures, fault prioritization and software reconfiguration of the MFDCS data base. The MFDCS would operate as a stand-alone processor to minimize the impact on the current Orbiter software. Supervisory crew command of all current functions would be retained through the use of several operating modes in the system. Both the design concept and the processes followed in defining the concept are described.

Spiger, R. J.↗

An expert system that performs a satellite station keepimg maneuver

The development and characteristics of a prototype expert system, Expert System for Satellite Orbit Control (ESSOC), capable of providing real-time spacecraft system analysis and command generation for a geostationary satellite are described. The ESSOC recommends appropriate commands that reflect both the changing spacecraft condition and previous procedural action. An internal knowledge base stores satellite status information and is updated with processed spacecraft telemetry. Procedural structure data are encoded in production rules. Structural methods of knowledge acquisition and the design and performance-enhancing techniques that enable ESSOC to operate in real time are also considered.

Linesbrowning, M. Kate↗

Improved "Smart" Robot Hand

Improved version of developmental "smart" robot hand equipped with bidirectional, wide-band optical-fiber link for transmission of digitized strain-gauge force- and torque-sensor signals from hand and for transmission of command signals to motor drive unit on hand. Collection of sensor data speeded hundredfold. Higher data-collection speed makes possible to perform advanced processing of sensor data in host processor.

Szakaly, Zoltan F.↗

Raster Metafile And Raster Metafile Translator Programs

Raster Metafile (RM) computer program is generic raster-image-format program, and Raster Metafile Translator (RMT) program is assortment of software tools for processing images prepared in this format. Processing includes reading, writing, and displaying RM images. Such other image-manipulation features as minimal compositing operator and resizing option available under RMT command structure. RMT written in FORTRAN 77 and C language.

Randall, Donald P.↗

X-Ray Spectroscopy of Optically Bright Planets using the Chandra Observatory

Since its launch in July 1999, Chandra's Advanced CCD Imaging Spectrometer (ACIS) has observed several planets (Venus, Mars, Jupiter and Saturn) and 6 comets. At 0.5 arc-second spatial resolution, ACIS detects individual x-ray photons with good quantum efficiency (25% at 0.6 KeV) and energy resolution (20% FWHM at 0.6 KeV). However, the ACIS CCDs are also sensitive to optical and near-infrared light, which is absorbed by optical blocking filters (OBFs) that eliminate optical contamination from all but the brightest extended sources, e.g., planets. .Jupiter at opposition subseconds approx.45 arc-seconds (90 CCD pixels.) Since Chandra is incapable of tracking a moving target, the planet takes 10 - 20 kiloseconds to move across the most sensitive ACIS CCD, after which the observatory must be re-pointed. Meanwhile, the OBF covering that CCD adds an opt,ical signal equivalent to approx.110 eV to each pixel that lies within thc outline of the Jovian disk. This has three consequences: (1) the observatory must be pointed away from Jupiter while CCD bias maps are constructed; (2) most x-rays from within the optical image will be misidentified as charged-particle background and ignored; and (3) those x-rays that are reported will bc assigned anomalously high energies. The same also applies to thc other planets, but is less serious since they are either dimmer at optical wavelengths, or they show less apparent motion across the sky, permitting reduced CCD exposure times: the optical contamination from Saturn acids approx.15 eV per pixel, and from Mars and Venus approx.31 eV. After analyzing a series of short .Jupiter observations in December 2000, ACIS parameters were optimized for the February 2003 opposition. CCD bias maps were constructed while Chandra pointed away from Jupiter, and the subsequent observations employed on-board software to ignore any pixel that contained less charge than that expected from optical leakage. In addition, ACIS was commanded to report 5 x 5 arrays of pixel values surrounding each x-ray event, and the outlying values were employed during ground processing to correct for the optical contamination.

Ford, P. G.↗

Wireless Sensor Node for Autonomous Monitoring and Alerts in Remote Environments

A method, apparatus, system, and computer program products provides personal alert and tracking capabilities using one or more nodes. Each node includes radio transceiver chips operating at different frequency ranges, a power amplifier, sensors, a display, and embedded software. The chips enable the node to operate as either a mobile sensor node or a relay base station node while providing a long distance relay link between nodes. The power amplifier enables a line-of-sight communication between the one or more nodes. The sensors provide a GPS signal, temperature, and accelerometer information (used to trigger an alert condition). The embedded software captures and processes the sensor information, provides a multi-hop packet routing protocol to relay the sensor information to and receive alert information from a command center, and to display the alert information on the display.

Monacos, Steve P.↗

LADEE Simulation for Mission Operations

The Lunar Atmosphere Dust Environment Explorer (LADEE) model-based spacecraft simulator has been discussed previously at the Workshop on Spacecraft Flight Software including the verification and validation of the flight software, hardware integration of payloads, and multi-domain simulation. In addition to flight software development and testing the LADEE simulator was used by Mission Operations to develop and test spacecraft command scripts, train operators during mission simulations, verification of all tactical command sequence files uploaded to spacecraft during flight.This presentation will discuss the experience of the LADEE operations team using the spacecraft simulator including implementation, processes and lessons learned. We will also discuss a specific instance where the simulator was used in operations to debug and design a software fix for a spacecraft anomaly experienced with the star tracker.

Operations↗

Simple, Scalable, Script-Based Science Processor (S4P)

The development and deployment of data processing systems to process Earth Observing System (EOS) data has proven to be costly and prone to technical and schedule risk. Integration of science algorithms into a robust operational system has been difficult. The core processing system, based on commercial tools, has demonstrated limitations at the rates needed to produce the several terabytes per day for EOS, primarily due to job management overhead. This has motivated an evolution in the EOS Data Information System toward a more distributed one incorporating Science Investigator-led Processing Systems (SIPS). As part of this evolution, the Goddard Earth Sciences Distributed Active Archive Center (GES DAAC) has developed a simplified processing system to accommodate the increased load expected with the advent of reprocessing and launch of a second satellite. This system, the Simple, Scalable, Script-based Science Processor (S42) may also serve as a resource for future SIPS. The current EOSDIS Core System was designed to be general, resulting in a large, complex mix of commercial and custom software. In contrast, many simpler systems, such as the EROS Data Center AVHRR IKM system, rely on a simple directory structure to drive processing, with directories representing different stages of production. The system passes input data to a directory, and the output data is placed in a "downstream" directory. The GES DAAC's Simple Scalable Script-based Science Processing System is based on the latter concept, but with modifications to allow varied science algorithms and improve portability. It uses a factory assembly-line paradigm: when work orders arrive at a station, an executable is run, and output work orders are sent to downstream stations. The stations are implemented as UNIX directories, while work orders are simple ASCII files. The core S4P infrastructure consists of a Perl program called stationmaster, which detects newly arrived work orders and forks a job to run the appropriate executable (registered in a configuration file for that station). Although S4P is written in Perl, the executables associated with a station can be any program that can be run from the command line, i.e., non-interactively. An S4P instance is typically monitored using a simple Graphical User Interface. However, the reliance of S4P on UNIX files and directories also allows visibility into the state of stations and jobs using standard operating system commands, permitting remote monitor/control over low-bandwidth connections. S4P is being used as the foundation for several small- to medium-size systems for data mining, on-demand subsetting, processing of direct broadcast Moderate Resolution Imaging Spectroradiometer (MODIS) data, and Quick-Response MODIS processing. It has also been used to implement a large-scale system to process MODIS Level 1 and Level 2 Standard Products, which will ultimately process close to 2 TB/day.

Lynnes, Christopher↗

Integrating a local database into the StarView distributed user interface

A distributed user interface to the Space Telescope Data Archive and Distribution Service (DADS) known as StarView is being developed. The DADS architecture consists of the data archive as well as a relational database catalog describing the archive. StarView is a client/server system in which the user interface is the front-end client to the DADS catalog and archive servers. Users query the DADS catalog from the StarView interface. Query commands are transmitted via a network and evaluated by the database. The results are returned via the network and are displayed on StarView forms. Based on the results, users decide which data sets to retrieve from the DADS archive. Archive requests are packaged by StarView and sent to DADS, which returns the requested data sets to the users. The advantages of distributed client/server user interfaces over traditional one-machine systems are well known. Since users run software on machines separate from the database, the overall client response time is much faster. Also, since the server is free to process only database requests, the database response time is much faster. Disadvantages inherent in this architecture are slow overall database access time due to the network delays, lack of a 'get previous row' command, and that refinements of a previously issued query must be submitted to the database server, even though the domain of values have already been returned by the previous query. This architecture also does not allow users to cross correlate DADS catalog data with other catalogs. Clearly, a distributed user interface would be more powerful if it overcame these disadvantages. A local database is being integrated into StarView to overcome these disadvantages. When a query is made through a StarView form, which is often composed of fields from multiple tables, it is translated to an SQL query and issued to the DADS catalog. At the same time, a local database table is created to contain the resulting rows of the query. The returned rows are displayed on the form as well as inserted into the local database table. Identical results are produced by reissuing the query to either the DADS catalog or to the local table. Relational databases do not provide a 'get previous row' function because of the inherent complexity of retrieving previous rows of multiple-table joins. However, since this function is easily implemented on a single table, StarView uses the local table to retrieve the previous row. Also, StarView issues subsequent query refinements to the local table instead of the DADS catalog, eliminating the network transmission overhead. Finally, other catalogs can be imported into the local database for cross correlation with local tables. Overall, it is believe that this is a more powerful architecture for distributed, database user interfaces.

Silberberg, D. P.↗

Improve Problem Solving Skills through Adapting Programming Tools

There are numerous ways for engineers and students to become better problem-solvers. The use of command line and visual programming tools can help to model a problem and formulate a solution through visualization. The analysis of problem attributes and constraints provide insight into the scope and complexity of the problem. The visualization aspect of the problem-solving approach tends to make students and engineers more systematic in their thought process and help them catch errors before proceeding too far in the wrong direction. The problem-solver identifies and defines important terms, variables, rules, and procedures required for solving a problem. Every step required to construct the problem solution can be defined in program commands that produce intermediate output. This paper advocates improved problem solving skills through using a programming tool. MatLab created by MathWorks, is an interactive numerical computing environment and programming language. It is a matrix-based system that easily lends itself to matrix manipulation, and plotting of functions and data. MatLab can be used as an interactive command line or a sequence of commands that can be saved in a file as a script or named functions. Prior programming experience is not required to use MatLab commands. The GNU Octave, part of the GNU project, a free computer program for performing numerical computations, is comparable to MatLab. MatLab visual and command programming are presented here.

Shaykhian, Linda H.↗

Distributed microprocessors in a tactical universal modem

The distributed microprocessor system associated with a wideband signal conversion unit (WBSCU) is described. Multiple embedded 8086 and 2901 microprocessors, supported by dedicated hardware modules, perform the required real time operations for both transmit and receive functions. Commands from a host computer determine the configuration of the WBSCU via the IEEE 488 bus. Each of the four WBSCU channels is assigned to process a specified IF waveform; each channel configures its own resources and, in some cases, borrows resources from other channels. The processed waveform data is communicated from individual channels to redundant global memories. Data flow between the user community and global memories occurs via redundant 1553 buses through intelligent Bus Interface Units. Each WBSCU channel contains one 2901 bit slice machine and one 8086 microprocessor. The 2901 provides high speed processing capability for the most time critical operations. The 8086 is used for lower speed processing tasks where its high level language capability can be better exploited. Each 8086 has a global bus for wideband interprocessor communication, and a local bus for 8086/2901, master/slave communication. Software architecture consists of a control and communications structure governing mode dependent signal processing tasks.

Gray, D. M.↗

DEVS-based intelligent control of space adapted fluid mixing

The development is described of event-based intelligent control system for a space-adapted mixing process by employing the DEVS (Discrete Event System Specification) formalism. In this control paradigm, the controller expects to receive confirming sensor responses to its control commands within definite time windows determined by its DEVS model of the system under control. The DEVS-based intelligent control paradigm was applied in a space-adapted mixing system capable of supporting the laboratory automation aboard a Space Station.

Chi, Sung-Do↗

Analyzing MER Uplink Reports

The MER project includes two rovers working simultaneously on opposite sides of Mars each receiving commands only once a day. Creating this uplink is critical, since a failed uplink means a lost day and a waste of money. Examining the process of creating this uplink, I tracked the use of the system developed for requesting observations as well as the development, from stage to stage, in forming an activity plan. I found the system for requesting observations was commonly misused, if used at all. There are half a dozen reports to document the creation of the uplink plan and often there are discrepancies among them. Despite this, the uplink process worked very well and MER has been one of the most successful missions for NASA in recent memory. Still it is clear there is room for improvement.

Savin, Stephen C.↗

Integrated Systems Health Management for Space Exploration

Integrated Systems Health Management (ISHM) is a system engineering discipline that addresses the design, development, operation, and lifecycle management of components, subsystems, vehicles, and other operational systems with the purpose of maintaining nominal system behavior and function and assuring mission safety and effectiveness under off-nominal conditions. NASA missions are often conducted in extreme, unfamiliar environments of space, using unique experimental spacecraft. In these environments, off-nominal conditions can develop with the potential to rapidly escalate into mission- or life-threatening situations. Further, the high visibility of NASA missions means they are always characterized by extraordinary attention to safety. ISHM is a critical element of risk mitigation, mission safety, and mission assurance for exploration. ISHM enables: In-space maintenance and repair; a) Autonomous (and automated) launch abort and crew escape capability; b) Efficient testing and checkout of ground and flight systems; c) Monitoring and trending of ground and flight system operations and performance; d) Enhanced situational awareness and control for ground personnel and crew; e) Vehicle autonomy (self-sufficiency) in responding to off-nominal conditions during long-duration and distant exploration missions; f) In-space maintenance and repair; and g) Efficient ground processing of reusable systems. ISHM concepts and technologies may be applied to any complex engineered system such as transportation systems, orbital or planetary habitats, observatories, command and control systems, life support systems, safety-critical software, and even the health of flight crews. As an overarching design and operational principle implemented at the system-of-systems level, ISHM holds substantial promise in terms of affordability, safety, reliability, and effectiveness of space exploration missions.

Uckun, Serdar↗

Simplifying Operations with an Uplink/Downlink Integration Toolkit

The Operations Engineering Lab (OEL) at JPL has developed a simple, generic toolkit to integrate the uplink/downlink processes (often called closing the loop) in JPL's Multimission Ground Data System. This toolkit provides capabilities for integrating telemetry verification points with predicted spacecraft commands and ground events in the Mission Sequence of Events (SOE) document. This toolkit is designed to greatly simplify the user's ability to access and view telemetry data, and also provide a means to view this data in a context of the commands and ground events that are used to interpret it. This paper will discuss the toolkit implementation, including design trade-offs and future for enhancing the automated capabilities.

ground↗