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 703 records · Page 39

A natural language query system for Hubble Space Telescope proposal selection

The proposal selection process for the Hubble Space Telescope is assisted by a robust and easy to use query program (TACOS). The system parses an English subset language sentence regardless of the order of the keyword phases, allowing the user a greater flexibility than a standard command query language. Capabilities for macro and procedure definition are also integrated. The system was designed for flexibility in both use and maintenance. In addition, TACOS can be applied to any knowledge domain that can be expressed in terms of a single reaction. The system was implemented mostly in Common LISP. The TACOS design is described in detail, with particular attention given to the implementation methods of sentence processing.

Hornick, Thomas↗

Electron Mobility and Trapping in Ferrihydrite Nanoparticles

Iron is the most abundant transition metal in the Earth's crust, and naturally occurring iron oxide minerals play a commanding role in environmental redox reactions. Although iron oxide redox reactions are well studied, their precise mechanisms are not fully understood. Recent work has shown that these involve electron transfer pathways within the solid, suggesting that overall reaction rates could be dependent on electron mobility. Initial ultrafast spectroscopy studies of iron oxide nanoparticles sensitized by fluorescein derivatives supported a model for electron mobility based on polaronic hopping of electron charge carriers between iron sites, but the constitutive relationships between hopping mobilities and interfacial charge transfer processes has remained obscured. We developed a coarse-grained lattice Monte Carlo model to simulate the collective mobilities and lifetimes of these photoinjected electrons with respect to recombination with adsorbed dye molecules for the essential nanophase ferrihydrite, and tested predictions made by the simulations using pump-probe spectroscopy. We acquired optical transient absorption spectra as a function of particle size and under a variety of solution conditions, and used cryogenic transmission electron microscopy to determine the aggregation state of the nanoparticles. We observed biphasic electron recombination kinetics over timescales that spanned picoseconds to microseconds, the slower regime of which was fit with a stretched exponential decay function. The recombination rates were weakly affected by nanoparticle size and aggregation state, suspension pH, and the injection of multiple electrons per nanoparticle. We conclude that electron mobility indeed limits the rate of interfacial electron transfer in these systems with the slowest processes relating to escape from deep traps, the presence of which outweighs the influence of environmental factors such as pH-dependent surface charge.

77 NANOSCIENCE AND NANOTECHNOLOGY↗

A scripting interface for GSAS-II

The GSAS-II suite is a complete crystallographic analysis package for all types of X-ray and neutron diffraction data, suited for fitting models ranging from simple materials to proteins, and designed around an integrated graphical user interface. This article describes a new module within GSAS-II , GSASIIscript­able , which provides access to the GSAS-II data structures and an extensible mechanism to run a significant fraction of GSAS-II functionality, particularly for powder diffraction applications, from within Python scripts or directly from commands in a shell/batch script. In conclusion, this allows parallelization in a high-performance computing environment; near ideal speedup is seen with up to 240 simultaneous processes.

47 OTHER INSTRUMENTATION↗

Athena-I CUBIT Journal Files

The Monte Carlo N-Particle (MCNP)1 transport code version 6 (also known as MCNP6) has the capability for tracking particles on unstructured mesh (UM) geometry models embedded into con structive solid geometry (CSG) cells. This feature has been developed for performing calculations of complex geometry models because manually creating CSG models is a time-consuming and error prone process as the complexities of geometries increase. The UM capability was originally designed to work with UM models created with the Abaqus software and ASCII input files that it generates. The MCNP code version 6.0 and later can process UM models formatted as Abaqus input files. Starting with version 6.3, MCNP can also process HDF5 mesh input files. External codes must be used to generate Abaqus input files for MCNP UM calculations. CUBIT, the Sandia National Laboratory automated mesh generation toolkit, can generate a UM model formatted as an Abaqus input file. However, the Abaqus input files exported from CUBIT cannot be used for MCNP simulations because it lacks the proper syntax. A Python script was developed to convert an Abaqus file created by CUBIT to an Abaqus file format that MCNP can process. Creating UM models for complex geometries is not an easy task. The process of creating UM models in CUBIT for MCNP simulations is detailed in. CUBIT provides several user interface options including a graphical user interface (GUI) and a command line interface. A GUI provides an easy way to use CUBIT without learning the CUBIT command syntax. When using CUBIT with either interface option, command lines are written into an ASCII file known as a journal file; this journal file can be edited and archived so that it can be played back in CUBIT to automatically generate a UM model. This report describes the CUBIT journal files of the UM models developed for Athena-I. The Athena platform, an energy-tuning assembly, was developed to spectrally shape the National Ignition Facility (NIF) deuterium-tritium fusion neutron source to a thermonuclear (fusion) plus prompt fission neutron spectrum with capability to act as a short-pulse neutron source. MCNP6 was used for the Athena experiment design analysis.

73 NUCLEAR PHYSICS AND RADIATION PHYSICS↗

International Solar Terrestrial Physics (ISTP) geotail mission

The Geotail spacecraft will be provided by the Institute of Space and Astronautical Science (ISAS) and will provide a Delta Launch Vehicle, tracking support by the Deep Space Network (DSN), and data processing support by GSFC. In exchange, ISAS will reserve part of the payload for NASA instruments together with a certain number of investigators from the United States. As the solar wind flows toward the Earth, some of the energy is modified by the Earth's magnetosphere, ionosphere, and upper atmosphere. This interaction causes the flow to be altered, creating a plasmasphere, plasma sheet, and ring currents in the Earth's Geomagnetic Tail region. The result is a series of distinct regions which affect processes on the Earth. By traversing the tail region to a variety of depths, Geotail will be able to determine the size, position, and other properties of these regions. When correlated with information obtained from the other ISAS spacecraft, Geotail data should help to provide a more complete understanding of how the solar processes affect the Earth's environment. The flight profile is given, and information is presented in tabular form on the following topics: DSN support, frequency assignments, telemetry, command, and tracking support responsibility.

Sanford, R.↗

Sensor-knowledge-command fusion paradigm for man/machine systems

Sensing-knowledge-command (SKC) fusion is presented as a fundamental paradigm of implementing cooperative control for an advanced man-machine system. SKC fusion operates on the 'SKC fusion network,' which represents the connection between sensor data to commands through knowledge. Sensing, knowledge, and command of a human and a machine are tapped into the network to provide inputs, or stimuli, to the network. Such stimuli automatically invoke an SKC fusion process and generate a fused output for cooperative control. Once invoked by stimuli, the SKC fusion process forces the network to converge to a new equilibrium state through the network dynamics composed of data fusion, feature transformation, and constraint propagation. The SKC fusion process thus integrates redundant information, maintains network consistency, identifies faulty data and concepts, and specifies those concepts to be strengthened through sensor planning.

Lee, Sukhan↗

Operations and Range Technology Development

The Operations and Range Technology Project is responsible for the development of key technologies as part of the KSC Spaceport Technology Center Initiative to substantially reduce vehicle launch and processing operations costs and improve the systems safety and reliability. The topics include: 1) Spaceport Technology Areas; 2) Umbilical Systems Development; 3) Automated Payload Handling Systems; 4) Command, Control and Monitor Systems; 5) Intelligent Synthesis Environment; 6) Low TRL Development; 7) Second Generation Project Organization; and 8) ASTP (3rd Generation) Project Organization. This paper is presented in viewgraph form.

Taylor, Dave↗

The New Web-Based Hera Data Processing System at the HEASARC

The HEASARC at NASA/GSFC has provide an on-line astronomical data processing system called Hera for several years. Hera provides a complete data processing environment, including installed software packages, local data storage, and the CPU resources needed to process the user's data. The original design of Hera, however, has 2 requirements that has limited it's usefulness for some users, namely, that 1) the user must download and install a small helper program on their own computer before using Hera, and 2) Hera requires that several computer ports/sockets be allowed to communicate through any local firewalls on the users machine. Both of these restrictions can be problematic for some users, therefore we are now migrating Hera into a purely Web based environment which only requires a standard Web browser. The first release of Web Hera is now publicly available at http://heasarc.gsfc.nasa.gov/webheara/. It currently provides a standard graphical interface for running hundreds of different data processing programs that are available in the HEASARC's ftools software package. Over the next year we to add more features to Web Hera, including an interactive command line interface, and more display and line capabilities.

Pence, W.↗

An Analysis of Database Replication Technologies with Regard to Deep Space Network Application Requirements

The Deep Space Network (DSN) has three communication facilities which handle telemetry, commands, and other data relating to spacecraft missions. The network requires these three sites to share data with each other and with the Jet Propulsion Laboratory for processing and distribution. Many database management systems have replication capabilities built in, which means that data updates made at one location will be automatically propagated to other locations. This project examines multiple replication solutions, looking for stability, automation, flexibility, performance, and cost. After comparing these features, Oracle Streams is chosen for closer analysis. Two Streams environments are configured - one with a Master/Slave architecture, in which a single server is the source for all data updates, and the second with a Multi-Master architecture, in which updates originating from any of the servers will be propagated to all of the others. These environments are tested for data type support, conflict resolution, performance, changes to the data structure, and behavior during and after network or server outages. Through this experimentation, it is determined which requirements of the DSN can be met by Oracle Streams and which cannot.

Oracle Database File System↗

MaROS Strategic Relay Planning and Coordination Interfaces

The Mars Relay Operations Service (MaROS) is designed to provide planning and analysis tools in support of ongoing Mars Network relay operations. Strategic relay planning requires coordination between lander and orbiter mission ground data system (GDS) teams to schedule and execute relay communications passes. MaROS centralizes this process, correlating all data relevant to relay coordination to provide a cohesive picture of the relay state. Service users interact with the system through thin-layer command line and web user interface client applications. Users provide and utilize data such as lander view periods of orbiters, Deep Space Network (DSN) antenna tracks, and reports of relay pass performance. Users upload and download relevant relay data via formally defined and documented file structures including some described in Extensible Markup Language (XML). Clients interface with the system via an http-based Representational State Transfer (ReST) pattern using Javascript Object Notation (JSON) formats. This paper will provide a general overview of the service architecture and detail the software interfaces and considerations for interface design.

Allard, Daniel A.↗

Mass Analyzers Facilitate Research on Addiction

The famous go/no go command for Space Shuttle launches comes from a place called the Firing Room. Located at Kennedy Space Center in the Launch Control Center (LCC), there are actually four Firing Rooms that take up most of the third floor of the LCC. These rooms comprise the nerve center for Space Shuttle launch and processing. Test engineers in the Firing Rooms operate the Launch Processing System (LPS), which is a highly automated, computer-controlled system for assembly, checkout, and launch of the Space Shuttle. LPS monitors thousands of measurements on the Space Shuttle and its ground support equipment, compares them to predefined tolerance levels, and then displays values that are out of tolerance. Firing Room operators view the data and send commands about everything from propellant levels inside the external tank to temperatures inside the crew compartment. In many cases, LPS will automatically react to abnormal conditions and perform related functions without test engineer intervention; however, firing room engineers continue to look at each and every happening to ensure a safe launch. Some of the systems monitored during launch operations include electrical, cooling, communications, and computers. One of the thousands of measurements derived from these systems is the amount of hydrogen and oxygen inside the shuttle during launch.

Source record↗

Control of multiple resonant power processors in a multi-source system

Analysis and test results show that phasor-regulated, Mapham-derived resonant inverters can be paralleled to provide standardizing interfaces for multiple sources on a utility-type, aerospace power distribution bus. The basic sources do not require matching in any way, and may have grossly different characteristics. Fully stable system architectures with multiple sources, parallel/redundant distribution buses, and a wide variety of loads can be easily constructed and controlled. The commands and parameters available for system control allow for tight tolerance bus voltage control, and absolute power-sharing control from the various sources over the full range of possible source and load variations. That level of control enables simplified load power processing hardware and the distribution of losses to optimally load the source thermal control system. Positive control of all system performance and allocation of losses are not required by all missions or vehicles, and overall vehicle considerations do not always require the loads on vehicle energy sources and thermal control systems to be balanced. In those cases, power system control can be simplified, and a hierarchical set of defaults can be substituted for computer-generated or supervisory input commands to allow for stable, fully autonomous system operation.

Mildice, James↗

Making or Breaking a Rover: System Engineering Parameters On-Board the Mars 2020 Perseverance Rover

On February 18, 2021, Perseverance, NASA’s Jet Propulsion Laboratory’s (JPL’s) Mars 2020 Rover, successfully landed on Mars with all systems nominal, despite the risk surrounding the over 200,000 internal flight parameters that had to be properly configured. The Perseverance team defines these parameters as software variables that are configurable, commandable and retrievable from Earth. In 2015, the Mars 2020 project leaders focused on improving systems engineering of parameters based on their experiences from parameter management on previous Mars rovers (Curiosity, Opportunity, Spirit, and Pathfinder) and parameter failures of past missions, such as the mission-ending parameter of the Mars Climate Orbiter. The new rigorous development process allowed for efficient certification and effective implementation of the parameters, allowing the rover to approach and land on the red planet (the most challenging phase of the mission) with zero parameter issues. Although successful, the Perseverance team learned many lessons for how to better manage parameters for the continued surface operations of the Mars 2020 mission and future missions. This paper will discuss eight parameter-management topics for the Perseverance Mission. The first is parameter definition: how we define parameters on our mission, where they are physically located on the vehicle, and why we have so many of them. The second topic is the updated parameter flight software module from Curiosity, including details on the 99% reduction in parameter commands, new bulk configuration capabilities, and improved parameter traceability. The third topic is parameter selection for different mission phases; this includes improving and tweaking our preferred parameter settings until they become certification candidates and managing parameter configurations based on test venue throughout the mission life cycle. The fourth topic is our flight certification process; this includes certification of flight values for four different epochs in the mission: Launch, Entry Decent and Landing (EDL) - 6days, Landing + 5 Sols (Martian Days, still on Cruise Flight Software), and once are on Surface Flight Software (FSW). The fifth topic covers in-flight command implementation, along with details on testing, validation, and verification of those commands. In the sixth section, we will explain our use of open-source management tools, including how we used GitHub for version control and management approvals. The seventh topic will describe the ground tools used in operations, including capabilities of the in-house built tool called Parasol. The eighth and final topic will dig into lessons learned for improving parameter management in the future of this mission and others.

Roth, Brian↗

Making or Breaking a Rover- Systems Engineering Parameters On-Board the Mars 2020 Perseverance Rover

On February 18, 2021, Perseverance, NASA’s Jet Propulsion Laboratory’s (JPL’s) Mars 2020 Rover, successfully landed on Mars with all systems nominal, despite the risk surrounding the over 200,000 internal flight parameters that had to be properly configured. The Perseverance team defines these parameters as software variables that are configurable, commandable and retrievable from Earth. In 2015, the Mars 2020 project leaders focused on improving systems engineering of parameters based on their experiences from parameter management on previous Mars rovers (Curiosity, Opportunity, Spirit, and Pathfinder) and parameter failures of past missions, such as the mission-ending parameter of the Mars Climate Orbiter. The new rigorous development process allowed for efficient certification and effective implementation of the parameters, allowing the rover to approach and land on the red planet (the most challenging phase of the mission) with zero parameter issues. Although successful, the Perseverance team learned many lessons for how to better manage parameters for the continued surface operations of the Mars 2020 mission and future missions. This paper will discuss eight parameter-management topics for the Perseverance Mission. The first is parameter definition: how we define parameters on our mission, where they are physically located on the vehicle, and why we have so many of them. The second topic is the updated parameter flight software module from Curiosity, including details on the 99% reduction in parameter commands, new bulk configuration capabilities, and improved parameter traceability. The third topic is parameter selection for different mission phases; this includes improving and tweaking our preferred parameter settings until they become certification candidates and managing parameter configurations based on test venue throughout the mission life cycle. The fourth topic is our flight certification process; this includes certification of flight values for four different epochs in the mission: Launch, Entry Decent and Landing (EDL) - 6days, Landing + 5 Sols (Martian Days, still on Cruise Flight Software), and once are on Surface Flight Software (FSW). The fifth topic covers in-flight command implementation, along with details on testing, validation, and verification of those commands. In the sixth section, we will explain our use of open-source management tools, including how we used GitHub for version control and management approvals. The seventh topic will describe the ground tools used in operations, including capabilities of the in-house built tool called Parasol. The eighth and final topic will dig into lessons learned for improving parameter management in the future of this mission and others.

Roth, Brian↗

Model Driven Deception for Defense of Operational Technology Environments

Due to the strong integration of real-world physics, OT deception platforms must operate differently than traditional IT deceptions. For instance, turning off a valve will be detected downstream by other sensors because the flow will reduce and stop. Additionally, controllers and applications leverage data from sensors to send control commands to each other. A believable deception must be integrated with the system to project the effects of events. An attack will likely attempt to control the physical process in a negative manner. To make the attacker believe they are achieving their objective, it must predict the effects of these actions, to a reasonable degree. Our approach to simulating a model to generate realistic decoy behavior is explored including description of two approaches: a physics model-based approach and a data driven approach. The performance of two machine learning techniques are investigated in their ability to learn a good enough model of the physics of the system.

97 MATHEMATICS AND COMPUTING↗

Automated system for analyzing the activity of individual neurons

This paper presents a signal processing system that: (1) provides an efficient and reliable instrument for investigating the activity of neuronal assemblies in the brain; and (2) demonstrates the feasibility of generating the command signals of prostheses using the activity of relevant neurons in disabled subjects. The system operates online, in a fully automated manner and can recognize the transient waveforms of several neurons in extracellular neurophysiological recordings. Optimal algorithms for detection, classification, and resolution of overlapping waveforms are developed and evaluated. Full automation is made possible by an algorithm that can set appropriate decision thresholds and an algorithm that can generate templates on-line. The system is implemented with a fast IBM PC compatible processor board that allows on-line operation.

Bankman, Isaac N.↗

CLIPS enhanced with objects, backward chaining and explanation facilities

In this project we extend C Language Production System (CLIPS), an existing Expert System shell, by creating three new options. Specifically, first we create a compatible with CLIPS environment that allows for defining objects and object hierarchies, second we provide means to implement backward chaining in a pure forward chaining environment, and finally we give some simple explanation facilities for the derivations the system has made. Objects and object hierarchies are extended so that facts can be automatically inferred, and placed in the fact base. Backward chaining is implemented by creating run time data structures which hold the derivation process allowing for a depth first search. The backward chaining mechanism works not only with ground facts, but also creates bindings for every query that involves variables, and returns the truth value of such a query as well as the relevant variable bindings. Finally, the WHY and HOW explanation facilities allow for a complete examination of the derivation process, the rules triggered, and the bindings created. The entire system is integrated with the original CLIPS code, and all of its routines can be invoked as CLIPS commands.

Aldrobi, M.↗

Embedding CLIPS in a database-oriented diagnostic system

This paper describes the integration of C Language Production Systems (CLIPS) into a powerful portable maintenance aid (PMA) system used for flightline diagnostics. The current diagnostic target of the system is the Garrett GTCP85-180L, a gas turbine engine used as an Auxiliary Power Unit (APU) on some C-130 military transport aircraft. This project is a database oriented approach to a generic diagnostic system. CLIPS is used for 'many-to-many' pattern matching within the diagnostics process. Patterns are stored in database format, and CLIPS code is generated by a 'compilation' process on the database. Multiple CLIPS rule sets and working memories (in sequence) are supported and communication between the rule sets is achieved via the export and import commands. Work is continuing on using CLIPS in other portions of the diagnostic system and in re-implementing the diagnostic system in the Ada language.

Conway, Tim↗