Search NASA⌕ Search

SEARCH · Search NASA

Results for “command process”

Search indexed NASA NTRS and DOE OSTI research on propulsion, heat transfer, battery materials and energy systems. Follow report and document links to the original sources.

Quote a phrase for an exact phrase match. Source license links do not imply unrestricted reuse.

At least 613 records · Page 34
All sourcesNASA NTRSDOE OSTI
NASA NTRS2004

Telescience Resource Kit Software Capabilities and Future Enhancements

The Telescience Resource Kit (TReK) is a suite of PC-based software applications that can be used to monitor and control a payload on board the International Space Station (ISS). This software provides a way for payload users to operate their payloads from their home sites. It can be used by an individual or a team of people. TReK provides both local ground support system services and an interface to utilize remote services provided by the Payload Operations Integration Center (POIC). by the POIC and to perform local data functions such as processing the data, storing it in local files, and forwarding it to other computer systems. TReK can also be used to build, send, and track payload commands. In addition to these features, work is in progress to add a new command management capability. This capability will provide a way to manage a multi- platform command environment that can include geographically distributed computers. This is intended to help those teams that need to manage a shared on-board resource such as a facility class payload. The environment can be configured such that one individual can manage all the command activities associated with that payload. This paper will provide a summary of existing TReK capabilities and a description of the new command management capability. For example, 7'ReK can be used to receive payload data distributed

Schneider, Michelle↗
NASA NTRS2008

An Improved Wavefront Control Algorithm for Large Space Telescopes

Wavefront sensing and control is required throughout the mission lifecycle of large space telescopes such as James Webb Space Telescope (JWST). When an optic of such a telescope is controlled with both surface-deforming and rigid-body actuators, the sensitivity-matrix obtained from the exit pupil wavefront vector divided by the corresponding actuator command value can sometimes become singular due to difference in actuator types and in actuator command values. In this paper, we propose a simple approach for preventing a sensitivity-matrix from singularity. We also introduce a new "minimum-wavefront and optimal control compensator". It uses an optimal control gain matrix obtained by feeding back the actuator commands along with the measured or estimated wavefront phase information to the estimator, thus eliminating the actuator modes that are not observable in the wavefront sensing process.

adaptive optics↗
NASA NTRS2008

Simulating Autonomous Telecommunication Networks for Space Exploration

Currently, most interplanetary telecommunication systems require human intervention for command and control. However, considering the range from near Earth to deep space missions, combined with the increase in the number of nodes and advancements in processing capabilities, the benefits from communication autonomy will be immense. Likewise, greater mission science autonomy brings the need for unscheduled, unpredictable communication and network routing. While the terrestrial Internet protocols are highly developed their suitability for space exploration has been questioned. JPL has developed the Multi-mission Advanced Communications Hybrid Environment for Test and Evaluation (MACHETE) tool to help characterize network designs and protocols. The results will allow future mission planners to better understand the trade offs of communication protocols. This paper discusses various issues with interplanetary network and simulation results of interplanetary networking protocols.

Segui, John S.↗
NASA NTRS1987

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↗
NASA NTRS1991

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.↗
NASA NTRS1991

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↗
NASA NTRS2000

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↗
NASA NTRS2011

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.↗
NASA NTRS2011

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↗
NASA NTRS2010

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.↗
NASA NTRS2012

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↗
NASA NTRS1990

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↗
NASA NTRS2022

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↗
NASA NTRS2022

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↗
NASA NTRS1993

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.↗
NASA NTRS1990

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.↗
NASA NTRS1990

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↗
NASA NTRS1996

Grant Proposal for the Continuation of the Voyager Interstellar Mission: LECP Investigation

This proposal documents the plans of the Low Energy Charged Particle (LECP) investigation team for participation in NASA's Voyager Interstellar Mission (VIM) as the Voyager 1 and 2 spacecraft explore the outer reaches of the heliosphere and search for the termination shock and the heliopause. The proposal covers the four year period from 1 January 1997 to 31 December 2000. The LECP instruments on Voyager 1 and 2 measure in situ intensities of charged particles with energies from about 30 keV to 100 MeV for ions, and about 20 keV to greater than 10 MeV for electrons. The instruments provide detailed spectral, angular, and compositional information about the particles. Composition is available for greater than 200 keV/nuc using multi-parameter measurements. Angular information is obtained by a mechanically scanned platform that rotates at various commanded rates. Measurements of low energy ion and electron intensities versus time and spatial location within the heliosphere contain an abundance of information regarding various transport and acceleration processes on both local (approx. 1 hr, approx. 0.01 AU) and global (approx. 11 yrs, approx. 100 AU) scales. The LECP instruments provide unique observations of such dynamical processes, and we anticipate that it will return critical information regarding the boundaries of the heliosphere. Several recent and exciting discoveries based on LECP measurements emphasize the important role that low energy charged particle distributions play in physical processes in the interplanetary medium. Yet, at the same time, these discoveries also underscore the fact that our understanding of processes in the outer heliosphere is, in most cases, incomplete, and in others, only rudimentary at best. Among the discoveries referred to above are the following: (1) Shocks: Examination of greater than 30 keV ion intensities have revealed: (a) a total absence of acceleration beyond only -100-200 keV at a strong transient shock in May 1991 at 35 AU, despite an enhanced level of seed particles; (b) a large transient shock in September 1991 of global scale, with intensities of shock-accelerated ions greater than or equal to 30 keV to approx. 30 MeV showing complex, highly energy-dependent spatial evolution, and small-scale (approx. few gyroradii), often anisotropic, micro-structures; (c) recurrent intensity increases in greater than or equal to 30 keV to -few MeV ions, with structures that, in some cases, show no correlation with the associated corotating shock. (2) Superthermal ion pressure: A global merged interaction region with a leading shock, downstream of which the superthermal ion (greater than or equal to 30 keV to approx. 4 MeV) pressure is comparable to that of the thermal plasma, and the total particle pressure yields a plasma beta of order unity. (3) Pickup ions: Measurements of the C/O ratio within transient structures at 35-45 AU showing the first clear evidence that transient shocks can pre-accelerate interstellar pickup ions from approx. 1 keV/nuc to at least 1 MeV/nuc. (4) Seed particles: Injection of ions for acceleration to high energies at the termination shock is unlikely to be a problem, since interplanetary transient and recurrent shocks are continually accelerating ions, of solar wind or interstellar origin, to highly superthermal energies. (5) Precursor electrons: Ambient solar electrons (greater than or equal to few tens of keV) that exist in the outer heliosphere ca form a broad precursor, several days wide, that is upstream of the termination shock and potentially observable a few months prior to the shock crossing. (6) Solar wind velocity at Voyager 1: We can use LECP ion data to obtain the solar wind velocity at Voyager 1, enabling us to provide critical measurement of the plasma flow as we approach and encounter the termination shock and other regions (necessary due to the partial failure of the Voyager 1 PLS experiment). The work of the LECP investigator team during the VIM will include: (1) Continuing operations with regard to the receipt, processing, verification, cataloging, display, and distribution of the data from the LECP instruments on Voyager 1 and 2, (2) Monitoring the health and performance of the LECP instruments, and evaluating and characterizing the response of the LECP instruments to various energetic particle and plasma environments, (3) Participating in, and supporting Voyager Project planning exercises and other coordinated activities relevant to exploration of the outer heliosphere, (4) Developing analysis techniques and operational procedures suitable for searching for and characterizing the boundaries and unique regions of the outher heliosphere, (5) Continuing the preparation of data sets appropriate for submission to the National Space Sciences Data Center (NSSDC) and, where appropriate, the Planetary Data System (PDS), (6) Maintaining direct Web access to online LECP data through the JHU/APL Voyager LECP home page, (7) Performing scientific evaluations of the Voyager 1 and 2 LECP data sets in conjunction with other data sets and other investigators, with particular focus on the outer regions of the heliosphere, and (8) Publishing the results of these evaluations in the scientific literature and presenting the results in scientific conferences.

Krimigis, Stamatios M.↗