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 595 records · Page 33

A MOS for all seasons

From a systems perspective, this paper examines the challenges of a single system to support multiple JPL space exploration missions and the need for unitary responsibility for the system. The focus is a Mission Operations System (MOS), which is effectively a mission management organization with direct authority over data system operations, command sequencing, flight operations control, data management, trajectory determination, telemetry and data acquisition, and spacecraft analysis. Stratagems for training and the approach to processes, procedures, and interfaces to facilitate the transition from the present situation to a truly multimission operational environment are developed. The outcome is a paradigm for a MOS that is achievable, that can effectively support multiple projects, and that can take advantage of technological changes without perturbing the entire system.

Bryant, Larry↗

STS-26/Discovery Preparations for Launch

This NASA Kennedy Space Center two-part video release is comprised of footage covering STS-26 launch preparations from the arrival of the Tracking and Data Relay Satellite (TDRS) at the Orbiter Processing Facility (OPF) to the lift and mate of the external tanks. The STS-26 flight crew include: Frederick H. (Rick) Hauck, mission commander; Richard O. Covey, pilot; John M. (Mike) Lounge, mission specialist; David C. Hilmers, mission specialist; and George D. (Pinky) Nelson, mission specialist. The primary payload of STS-26 is the TDRS while the secondary payloads include the Physical Vapor Transport of Organic Solids (PVTOS); Protein Crystal Growth (PCG); Infrared Communications Flight Experiment (IRCFE); Aggregation of Red Blood Cells (ARC); Isoelectric Focusing Experiment (IFE); Mesoscale Lightning Experiment (MLE); Phase Partitioning Experiment (PPE); Earth-Limb Radiance Experiment (ELRAD); Automated Directional Solidification Furnace (ADSF) and two Shuttle Student Involvement Program (SSIP) experiments. Launch preparation footage includes flight crew arrival at KSC, rollout of Discovery to Pad B, OV-103 Discovery power-up, main engine unpacking and installation, solid rocket boosters' arrival prep and stacking, and aft skirt to aft segment mating.

Source record↗

Monitoring system and methods for a distributed and recoverable digital control system

A monitoring system and methods are provided for a distributed and recoverable digital control system. The monitoring system generally comprises two independent monitoring planes within the control system. The first monitoring plane is internal to the computing units in the control system, and the second monitoring plane is external to the computing units. The internal first monitoring plane includes two in-line monitors. The first internal monitor is a self-checking, lock-step-processing monitor with integrated rapid recovery capability. The second internal monitor includes one or more reasonableness monitors, which compare actual effector position with commanded effector position. The external second monitor plane includes two monitors. The first external monitor includes a pre-recovery computing monitor, and the second external monitor includes a post recovery computing monitor. Various methods for implementing the monitoring functions are also disclosed.

Stange, Kent↗

Attitude Design for the LADEE Mission

The Lunar Atmosphere and Dust Environment Explorer (LADEE) satellite successfully completed its 148-day science investigation in a low-altitude, near-equatorial lunar orbit on April 18, 2014. The LADEE spacecraft was built, managed and operated by NASA's Ames Research Center (ARC). The Mission Operations Center (MOC) was located at Ames and was responsible for activity planning, command sequencing, trajectory and attitude design, orbit determination, and spacecraft operations. The Science Operations Center (SOC) was located at Goddard Space Flight Center and was responsible for science planning, data archiving and distribution. This paper details attitude design and operations support for the LADEE mission. LADEE's attitude design was shaped by a wide range of instrument pointing requirements that necessitated regular excursions from the baseline one revolution per orbit "Ram" attitude. Such attitude excursions were constrained by a number of flight rules levied to protect instruments from the Sun, avoid geometries that would result in simultaneous occlusion of LADEE's two star tracker heads, and maintain the spacecraft within its thermal and power operating limits. To satisfy LADEE's many attitude requirements and constraints, a set of rules and conventions was adopted to manage the complexity of this design challenge and facilitate the automation of ground software that generated pointing commands spanning multiple days of operations at a time. The resulting LADEE Flight Dynamics System (FDS) that was developed used Visual Basic scripts that generated instructions to AGI's Satellite Tool Kit (STK) in order to derive quaternion commands at regular intervals that satisfied LADEE's pointing requirements. These scripts relied heavily on the powerful "align and constrain" capability of STK's attitude module to construct LADEE's attitude profiles and the slews to get there. A description of the scripts and the attitude modeling they embodied is provided. One particular challenge analysts faced was in the design of LADEE maneuver attitudes. A flight rule requiring pre-maneuver verification of in-flight maneuver conditions by ground operators prior to burn execution resulted in the need to accommodate long periods in the maneuver attitude. This in turn complicated efforts to satisfy star tracker interference and communication constraints in lunar orbit. In response to this challenge, a graphical method was developed and used to survey candidate rotation angles about the thrust vector. This survey method is described and an example of its use on a particular LADEE maneuver is discussed. Finally, the software and methodology used to satisfy LADEE's attitude requirements are also discussed in the context of LADEE's overall activity planning effort. In particular, the way in which strategic schedules of instrument and engineering activities were translated into actual attitude profiles at the tactical level, then converted into precise quaternion commands to achieve those pointing goals is explained. In order to reduce the risk of time-consuming re-planning efforts, this process included the generation of long-term projections of constraint violation predictions for individual attitude profiles that could be used to establish keep-out time-frames for particular attitude profiles. The challenges experienced and overall efficacy of both the overall LADEE ground system and the attitude components of the Flight Dynamics System in meeting LADEE's varied pointing requirements are discussed.

LADEE↗

A Flight Rule Checker for the LADEE Lunar Spacecraft

As part of the design of a space mission, an important part is the design of so-called flight rules. Flight rules express constraints on various parts and processes of the mission, that if followed, will reduce the risk of failure. One such set of flight rules constrain the format of command sequences regularly (e.g. daily) sent to the spacecraft to con-trol its next near term behavior. We present a high-level view of the automated flight rule checker FRC for checking command sequences sent to NASA’s LADEE Lunar mission spacecraft, used throughout its entire mission. A command sequence is in this case essentially a program (a sequence of commands) with no loops or conditionals, and it can there-fore be verified with a trace analysis tool. FRC is implemented using the TraceContract runtime verification tool, an internal Scala DSL for checking event sequences against “formal specifications”. The paper illustrates this untraditional use of runtime verification in a real con-text, with strong demands on the expressiveness and flexibility of the specification language, illustrating the advantages of an internal DSL.

LADEE↗

A Flight Rule Checker for the LADEE Lunar Spacecraft

As part of the design of a space mission, an important part is the design of so-called flight rules. Flight rules express constraints on various parts and processes of the mission, that if followed, will reduce the risk of failure. One such set of flight rules constrain the format of command sequences regularly (e.g. daily) sent to the spacecraft to con- trol its next near term behavior. We present a high-level view of the automated flight rule checker Frc for checking command sequences sent to NASA’s LADEE Lunar mission spacecraft, used throughout its entire mission. A command sequence is in this case essentially a program (a sequence of commands) with no loops or conditionals, and it can there- fore be verified with a trace analysis tool. Frc is implemented using the TraceContract runtime verification tool, an internal Scala DSL for checking event sequences against “formal specifications”. The paper illustrates this untraditional use of runtime verification in a real con- text, with strong demands on the expressiveness and flexibility of the specification language, illustrating the advantages of an internal DSL.

Kurklu, Elif↗

The MERiT Onboard the CeREs: A Novel Instrument to Study Energetic Particles in the Earth's Radiation Belts

The Miniaturized Electron pRoton Telescope, MERiT, is a low‐mass, low‐power, compact instrument using an innovative combination of particle detectors, sensor electronics, and onboard processing. MERiT is flying on the Compact Radiation belt Explorer, CeREs, a 3U CubeSat launched into a low earth orbit of 500‐km altitude and inclination of 85° on 16 December 2018. The primary and secondary science goals of CeREs are to investigate electron microbursts and to study solar particles. MERiT comprises a stack of solid state detectors (SSD) behind space facing avalanche photo diodes (APDs) surrounded by W‐Al shielding to reduce side‐penetrating particle background. The APD‐SSD combination enables measurement of electrons from 5 to 200 keV and 1 to 8 MeV; protons from 200–400 keV and 7–100 MeV in differential channels with energy resolution ΔE/E≈30% for both electrons and protons. MERiT measures microbursts with a high time resolution ranging from 4 to 16 ms and solar particles with a cadence of 1 s. MERiT energy channels and cadences are software configurable via algorithms and lookup tables residing on a field‐programmable gate array. The lookup tables can be changed via ground commands. MERiT geometry factor is 31 sq.cm‐sr and optimized to measure microbursts with the instrument viewing the local zenith in orbit. MERiT enables investigation of dynamical processes of radiation belt electron energization and loss, solar electron and proton transport, and their access to the Earth's polar caps. We describe the MERiT sensor design, calibration, operational modes, data products, and science goals.

Kanekal, S. G.↗

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↗

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