Search NASA⌕ Search

SEARCH · Search NASA

Results for “COMMAND SYSTEM”

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 433 records · Page 24
All sourcesNASA NTRSDOE OSTI
NASA NTRS1985

Total energy based flight control system

An integrated aircraft longitudinal flight control system uses a generalized thrust and elevator command computation (38), which accepts flight path angle, longitudinal acceleration command signals, along with associated feedback signals, to form energy rate error (20) and energy rate distribution error (18) signals. The engine thrust command is developed (22) as a function of the energy rate distribution error and the elevator position command is developed (26) as a function of the energy distribution error. For any vertical flight path and speed mode the outerloop errors are normalized (30, 34) to produce flight path angle and longitudinal acceleration commands. The system provides decoupled flight path and speed control for all control modes previously provided by the longitudinal autopilot, autothrottle and flight management systems.

Lambregts, Antonius A.↗
NASA NTRS2010

CHeCS Commanding Hardware

This slide presentation reviews the Crew Health Care System (CHeCS) commanding hardware. It includes information on the hardware status, commanding plan, and command training status with specific information the EV-CPDS 2 and 3, TEPC, MEC, and T2

Moore, Jamie↗
NASA NTRS2007

Hybrid Automated Diagnosis of Discrete/Continuous Systems

A recently conceived method of automated diagnosis of a complex electromechanical system affords a complete set of capabilities for hybrid diagnosis in the case in which the state of the electromechanical system is characterized by both continuous and discrete values (as represented by analog and digital signals, respectively). The method is an integration of two complementary diagnostic systems: (1) beacon-based exception analysis for multi-missions (BEAM), which is primarily useful in the continuous domain and easily performs diagnoses in the presence of transients; and (2) Livingstone, which is primarily useful in the discrete domain and is typically restricted to quasi-steady conditions. BEAM has been described in several prior NASA Tech Briefs articles: "Software for Autonomous Diagnosis of Complex Systems" (NPO-20803), Vol. 26, No. 3 (March 2002), page 33; "Beacon-Based Exception Analysis for Multimissions" (NPO-20827), Vol. 26, No. 9 (September 2002), page 32; "Wavelet-Based Real-Time Diagnosis of Complex Systems" (NPO-20830), Vol. 27, No. 1 (January 2003), page 67; and "Integrated Formulation of Beacon-Based Exception Analysis for Multimissions" (NPO-21126), Vol. 27, No. 3 (March 2003), page 74. Briefly, BEAM is a complete data-analysis method, implemented in software, for real-time or off-line detection and characterization of faults. The basic premise of BEAM is to characterize a system from all available observations and train the characterization with respect to normal phases of operation. The observations are primarily continuous in nature. BEAM isolates anomalies by analyzing the deviations from nominal for each phase of operation. Livingstone is a model-based reasoner that uses a model of a system, controller commands, and sensor observations to track the system s state, and detect and diagnose faults. Livingstone models a system within the discrete domain. Therefore, continuous sensor readings, as well as time, must be discretized. To reason about continuous systems, Livingstone uses monitors that discretize the sensor readings using trending and thresholding techniques. In development of the a hybrid method, BEAM results were sent to Livingstone to serve as an independent source of evidence that is in addition to the evidence gathered by Livingstone standard monitors. The figure depicts the flow of data in an early version of a hybrid system dedicated to diagnosing a simulated electromechanical system. In effect, BEAM served as a "smart" monitor for Livingstone. BEAM read the simulation data, processed the data to form observations, and stored the observations in a file. A monitor stub synchronized the events recorded by BEAM with the output of the Livingstone standard monitors according to time tags. This information was fed to a real-time interface, which buffered and fed the information to Livingstone, and requested diagnoses at the appropriate times. In a test, the hybrid system was found to correctly identify a failed component in an electromechanical system for which neither BEAM nor Livingstone alone yielded the correct diagnosis.

Park, Han↗
NASA NTRS1997

Mobile range control center/range safety command destruct and real-time instantaneous impact prediction system

The mobile range control center/range safety command destruct and real time instantaneous impact prediction system (MRCCS), designed for launching sounding rockets and expendable launch vehicles, is described. The MRCCS provides mission control and range safety support for remote launch sites and is equipped with telemetry and radar data acquisition systems, real time data computation systems, range safety display systems, and command destruct transmitters.

Hudson, Sandra Merritt↗
NASA NTRS1998

Satellite Telemetry and Command using Big LEO Mobile Telecommunications Systems

Various issues associated with satellite telemetry and command using Big LEO mobile telecommunications systems are presented in viewgraph form. Specific topics include: 1) Commercial Satellite system overviews: Globalstar, ICO, and Iridium; 2) System capabilities and cost reduction; 3) Satellite constellations and contact limitations; 4) Capabilities of Globalstar, ICO and Iridium with emphasis on Globalstar; and 5) Flight transceiver issues and security.

Huegel, Fred↗
NASA NTRS1981

Mission operations computing systems evolution

As part of its preparation for the operational Shuttle era, the Goddard Space Flight Center (GSFC) is currently replacing most of the mission operations computing complexes that have supported near-earth space missions since the late 1960's. Major associated systems include the Metric Data Facility (MDF) which preprocesses, stores, and forwards all near-earth satellite tracking data; the Orbit Computation System (OCS) which determines related production orbit and attitude information; the Flight Dynamics System (FDS) which formulates spacecraft attitude and orbit maneuvers; and the Command Management System (CMS) which handles mission planning, scheduling, and command generation and integration. Management issues and experiences for the resultant replacement process are driven by a wide range of possible future mission requirements, flight-critical system aspects, complex internal system interfaces, extensive existing applications software, and phasing to optimize systems evolution.

Kurzhals, P. R.↗
NASA NTRS1989

Preshaping command inputs to reduce telerobotic system oscillations

The results of using a new technique for shaping inputs to a model of the space shuttle Remote Manipulator System (RMS) are presented. The shapes inputs move the system to the same location that was originally commanded, however, the oscillations of the machine are considerably reduced. An overview of the new shaping method is presented. A description of RMS model is provided. The problem of slow joint servo rates on the RMS is accommodated with an extension of the shaping method. The results and sample data are also presented for both joint and three-dimensional cartesian motions. The results demonstrate that the new shaping method performs well on large, telerobotic systems which exhibit significant structural vibration. The new method is shown to also result in considerable energy savings during operations of the RMS manipulator.

Singer, Neil C.↗
NASA NTRS1992

Verifying command sequences for satellite systems

We present a formal basis for the design of a Checker used in validating safe schedules and in selecting error recovery schedules for satellite control systems. This design includes a high-level specification of Checker behavior and properties (called flight rules) of safe schedules. Specifications are written in Timed Linear Logic (TLL). Validation of schedules is performed in terms of real-time telemetry and deduction system proof rules. Telemetry (state information for satellite subsystems) serves as input to the Checker. Detection of violation of a flight rule by the Checker results in the selection of a contingency plan (error recovery schedule). The Checker is illustrated in terms of the TOPEX/Poseidon Oceanographic Satellite System.

Peters, James F., III↗
NASA NTRS1996

SAM-FS: LSC's New Solaris-Based Storage Management Product

SAM-FS is a full featured hierarchical storage management (HSM) device that operates as a file system on Solaris-based machines. The SAM-FS file system provides the user with all of the standard UNIX system utilities and calls, and adds some new commands, i.e. archive, release, stage, sls, sfind, and a family of maintenance commands. The system also offers enhancements such as high performance virtual disk read and write, control of the disk through an extent array, and the ability to dynamically allocate block size. SAM-FS provides 'archive sets' which are groupings of data to be copied to secondary storage. In practice, as soon as a file is written to disk, SAM-FS will make copies onto secondary media. SAM-FS is a scalable storage management system. The system can manage millions of files per system, though this is limited today by the speed of UNIX and its utilities. In the future, a new search algorithm will be implemented that will remove logical and performance restrictions on the number of files managed.

Angell, Kent↗
NASA NTRS2012

Integrated Laser Characterization, Data Acquisition, and Command and Control Test System

Satellite-based laser technology has been developed for topographical measurements of the Earth and of other planets. Lasers for such missions must be highly efficient and stable over long periods in the temperature variations of orbit. In this innovation, LabVIEW is used on an Apple Macintosh to acquire and analyze images of the laser beam as it exits the laser cavity to evaluate the laser s performance over time, and to monitor and control the environmental conditions under which the laser is tested. One computer attached to multiple cameras and instruments running LabVIEW-based software replaces a conglomeration of computers and software packages, saving hours in maintenance and data analysis, and making very longterm tests possible. This all-in-one system was written primarily using LabVIEW for Mac OS X, which allows the combining of data from multiple RS-232, USB, and Ethernet instruments for comprehensive laser analysis and control. The system acquires data from CCDs (charge coupled devices), power meters, thermistors, and oscilloscopes over a controllable period of time. This data is saved to an html file that can be accessed later from a variety of data analysis programs. Also, through the LabVIEW interface, engineers can easily control laser input parameters such as current, pulse width, chiller temperature, and repetition rates. All of these parameters can be adapted and cycled over a period of time.

Stysley, Paul↗
NASA NTRS1996

Re-Engineering of the Hubble Space Telescope (HST) to Reduce Operational Costs

Satellite telemetry processing onboard the Hubble Space Telescope (HST) is carried out using dedicated software and hardware. The current ground system is expensive to operate and maintain. The mandate to reduce satellite ground system operations and maintenance costs by the year 2000 led NASA to upgrade the command and control systems in order to improve the data processing capabilities, reduce operator experience levels and increase system standardization. As a result, a command and control system product development team was formed to redesign and develop the HST ground system. The command and control system ground system development consists of six elements. The results of the prototyping phase carried out for the following of these elements are presented: the front end processor; middleware, and the graphical user interface.

Garvis, Michael↗
NASA NTRS2017

Launch Control System Software Development System Automation Testing

The Spaceport Command and Control System (SCCS) is the National Aeronautics and Space Administration's (NASA) launch control system for the Orion capsule and Space Launch System, the next generation manned rocket currently in development. This system requires high quality testing that will measure and test the capabilities of the system. For the past two years, the Exploration and Operations Division at Kennedy Space Center (KSC) has assigned a group including interns and full-time engineers to develop automated tests to save the project time and money. The team worked on automating the testing process for the SCCS GUI that would use streamed simulated data from the testing servers to produce data, plots, statuses, etc. to the GUI. The software used to develop automated tests included an automated testing framework and an automation library. The automated testing framework has a tabular-style syntax, which means the functionality of a line of code must have the appropriate number of tabs for the line to function as intended. The header section contains either paths to custom resources or the names of libraries being used. The automation library contains functionality to automate anything that appears on a desired screen with the use of image recognition software to detect and control GUI components. The data section contains any data values strictly created for the current testing file. The body section holds the tests that are being run. The function section can include any number of functions that may be used by the current testing file or any other file that resources it. The resources and body section are required for all test files; the data and function sections can be left empty if the data values and functions being used are from a resourced library or another file. To help equip the automation team with better tools, the Project Lead of the Automated Testing Team, Jason Kapusta, assigned the task to install and train an optical character recognition (OCR) tool to Brandon Echols, a fellow intern, and I. The purpose of the OCR tool is to analyze an image and find the coordinates of any group of text. Some issues that arose while installing the OCR tool included the absence of certain libraries needed to train the tool and an outdated software version. We eventually resolved the issues and successfully installed the OCR tool. Training the tool required many images and different fonts and sizes, but in the end the tool learned to accurately decipher the text in the images and their coordinates. The OCR tool produced a file that contained significant metadata for each section of text, but only the text and coordinates of the text was required for our purpose. The team made a script to parse the information we wanted from the OCR file to a different file that would be used by automation functions within the automated framework. Since a majority of development and testing for the automated test cases for the GUI in question has been done using live simulated data on the workstations at the Launch Control Center (LCC), a large amount of progress has been made. As of this writing, about 60% of all of automated testing has been implemented. Additionally, the OCR tool will help make our automated tests more robust due to the tool's text recognition being highly scalable to different text fonts and text sizes. Soon we will have the whole test system automated, allowing for more full-time engineers working on development projects.

Automation↗