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 379 records · Page 21
All sourcesNASA NTRSDOE OSTI
NASA NTRS1993

Long term trending of engineering data for the Hubble Space Telescope

A major goal in spacecraft engineering analysis is the detection of component failures before the fact. Trending is the process of monitoring subsystem states to discern unusual behaviors. This involves reducing vast amounts of data about a component or subsystem into a form that helps humans discern underlying patterns and correlations. A long term trending system has been developed for the Hubble Space Telescope. Besides processing the data for 988 distinct telemetry measurements each day, it produces plots of 477 important parameters for the entire 24 hours. Daily updates to the trend files also produce 339 thirty day trend plots each month. The total system combines command procedures to control the execution of the C-based data processing program, user-written FORTRAN routines, and commercial off-the-shelf plotting software. This paper includes a discussion the performance of the trending system and of its limitations.

Cox, Ross M.↗
NASA NTRS2019

ISS Science Payload Command & Data Handling

For decades, the International Space Station (ISS) has provided a distinctive platform in low Earth orbit for experimental research. In support of this platform is a family of avionics systems that enables reliable data distribution of the many science payloads installed, and future internal and external payloads. This poster provides an update to the ISS avionics hardware system architecture, including design change successes, test bed architecture, and performance upgrades in the operation of all ISS avionics. We conclude with an outlook on future avionics system enhancements required to support additional modules and payload expansions taking place on the ISS, and how these avionics systems translate to a lunar gateway.

1553↗
NASA NTRS1981

Automated Power Systems Management (APSM)

A breadboard power system incorporating autonomous functions of monitoring, fault detection and recovery, command and control was developed, tested and evaluated to demonstrate technology feasibility. Autonomous functions including switching of redundant power processing elements, individual load fault removal, and battery charge/discharge control were implemented by means of a distributed microcomputer system within the power subsystem. Three local microcomputers provide the monitoring, control and command function interfaces between the central power subsystem microcomputer and the power sources, power processing and power distribution elements. The central microcomputer is the interface between the local microcomputers and the spacecraft central computer or ground test equipment.

Bridgeforth, A. O.↗
NASA NTRS2010

Orbit Determination Toolbox

The Orbit Determination Toolbox is an orbit determination (OD) analysis tool based on MATLAB and Java that provides a flexible way to do early mission analysis. The toolbox is primarily intended for advanced mission analysis such as might be performed in concept exploration, proposal, early design phase, or rapid design center environments. The emphasis is on flexibility, but it has enough fidelity to produce credible results. Insight into all flight dynamics source code is provided. MATLAB is the primary user interface and is used for piecing together measurement and dynamic models. The Java Astrodynamics Toolbox is used as an engine for things that might be slow or inefficient in MATLAB, such as high-fidelity trajectory propagation, lunar and planetary ephemeris look-ups, precession, nutation, polar motion calculations, ephemeris file parsing, and the like. The primary analysis functions are sequential filter/smoother and batch least-squares commands that incorporate Monte-Carlo data simulation, linear covariance analysis, measurement processing, and plotting capabilities at the generic level. These functions have a user interface that is based on that of the MATLAB ODE suite. To perform a specific analysis, users write MATLAB functions that implement truth and design system models. The user provides his or her models as inputs to the filter commands. The software provides a capability to publish and subscribe to a software bus that is compliant with the NASA Goddard Mission Services Evolution Center (GMSEC) standards, to exchange data with other flight dynamics tools to simplify the flight dynamics design cycle. Using the publish and subscribe approach allows for analysts in a rapid design center environment to seamlessly incorporate changes in spacecraft and mission design into navigation analysis and vice versa.

Carpenter, James R.↗
NASA NTRS1994

Simplifying operations with an uplink/downlink integration toolkit

The Operations Engineering Lab (OEL) at JPL has developed a simple, generic toolkit to integrate the uplink/downlink processes, (often called closing the loop), in JPL's Multimission Ground Data System. This toolkit provides capabilities for integrating telemetry verification points with predicted spacecraft commands and ground events in the Mission Sequence Of Events (SOE) document. In the JPL ground data system, the uplink processing functions and the downlink processing functions are separate subsystems that are not well integrated because of the nature of planetary missions with large one-way light times for spacecraft-to-ground communication. Our new closed-loop monitoring tool allows an analyst or mission controller to view and save uplink commands and ground events with their corresponding downlinked telemetry values regardless of the delay in downlink telemetry and without requiring real-time intervention by the user. An SOE document is a time-ordered list of all the planned ground and spacecraft events, including all commands, sequence loads, ground events, significant mission activities, spacecraft status, and resource allocations. The SOE document is generated by expansion and integration of spacecraft sequence files, ground station allocations, navigation files, and other ground event files. This SOE generation process has been automated within the OEL and includes a graphical, object-oriented SOE editor and real-time viewing tool running under X/Motif. The SOE toolkit was used as the framework for the integrated implementation. The SOE is used by flight engineers to coordinate their operations tasks, serving as a predict data set in ground operations and mission control. The closed-loop SOE toolkit allows simple, automated integration of predicted uplink events with correlated telemetry points in a single SOE document for on-screen viewing and archiving. It automatically interfaces with existing real-time or non real-time sources of information, to display actual values from the telemetry data stream. This toolkit was designed to greatly simplify the user's ability to access and view telemetry data, and also provide a means to view this data in the context of the commands and ground events that are used to interpret it. A closed-loop system can prove especially useful in small missions with limited resources requiring automated monitoring tools. This paper will discuss the toolkit implementation, including design trade-offs and future plans for enhancing the automated capabilities.

Murphy, Susan C.↗
NASA NTRS2006

Spitzer Space Telescope Sequencing Operations Software, Strategies, and Lessons Learned

The Space Infrared Telescope Facility (SIRTF) was launched in August, 2003, and renamed to the Spitzer Space Telescope in 2004. Two years of observing the universe in the wavelength range from 3 to 180 microns has yielded enormous scientific discoveries. Since this magnificent observatory has a limited lifetime, maximizing science viewing efficiency (ie, maximizing time spent executing activities directly related to science observations) was the key operational objective. The strategy employed for maximizing science viewing efficiency was to optimize spacecraft flexibility, adaptability, and use of observation time. The selected approach involved implementation of a multi-engine sequencing architecture coupled with nondeterministic spacecraft and science execution times. This approach, though effective, added much complexity to uplink operations and sequence development. The Jet Propulsion Laboratory (JPL) manages Spitzer s operations. As part of the uplink process, Spitzer s Mission Sequence Team (MST) was tasked with processing observatory inputs from the Spitzer Science Center (SSC) into efficiently integrated, constraint-checked, and modeled review and command products which accommodated the complexity of non-deterministic spacecraft and science event executions without increasing operations costs. The MST developed processes, scripts, and participated in the adaptation of multi-mission core software to enable rapid processing of complex sequences. The MST was also tasked with developing a Downlink Keyword File (DKF) which could instruct Deep Space Network (DSN) stations on how and when to configure themselves to receive Spitzer science data. As MST and uplink operations developed, important lessons were learned that should be applied to future missions, especially those missions which employ command-intensive operations via a multi-engine sequence architecture.

missions operations↗
NASA NTRS2011

Space Shuttle Day-of-Launch Trajectory Design Operations

A top priority of any launch vehicle is to insert as much mass into the desired orbit as possible. This requirement must be traded against vehicle capability in terms of dynamic control, thermal constraints, and structural margins. The vehicle is certified to specific structural limits which will yield certain performance characteristics of mass to orbit. Some limits cannot be certified generically and must be checked with each mission design. The most sensitive limits require an assessment on the day-of-launch. To further minimize vehicle loads while maximizing vehicle performance, a day-of-launch trajectory can be designed. This design is optimized according to that day s wind and atmospheric conditions, which increase the probability of launch. The day-of-launch trajectory design and verification process is critical to the vehicle s safety. The Day-Of-Launch I-Load Update (DOLILU) is the process by which the National Aeronautics and Space Administration's (NASA) Space Shuttle Program tailors the vehicle steering commands to fit that day s environmental conditions and then rigorously verifies the integrated vehicle trajectory s loads, controls, and performance. This process has been successfully used for almost twenty years and shares many of the same elements with other launch vehicles that execute a day-of-launch trajectory design or day-of-launch trajectory verification. Weather balloon data is gathered at the launch site and transmitted to the Johnson Space Center s Mission Control. The vehicle s first stage trajectory is then adjusted to the measured wind and atmosphere data. The resultant trajectory must satisfy loads and controls constraints. Additionally, these assessments statistically protect for non-observed dispersions. One such dispersion is the change in the wind from the last measured balloon to launch time. This process is started in the hours before launch and is repeated several times as the launch count proceeds. Should the trajectory design not meet all constraint criteria, Shuttle would be No-Go for launch. This Shuttle methodology is very similar to other unmanned launch vehicles. By extension, this method would likely be employed for any future NASA launch vehicle. This paper will review the Shuttle s day-of-launch trajectory optimization and verification operations as an example of a more generic application of day-of-launch design and validation. With Shuttle s retirement, it is fitting to document the current state of this critical process and capture lessons learned to benefit current and future launch vehicle endeavors.

Harrington, Brian E.↗
NASA NTRS1981

Integrated command, control, communications and computation system functional architecture

The functional architecture for an integrated command, control, communications, and computation system applicable to the command and control portion of the NASA End-to-End Data. System is described including the downlink data processing and analysis functions required to support the uplink processes. The functional architecture is composed of four elements: (1) the functional hierarchy which provides the decomposition and allocation of the command and control functions to the system elements; (2) the key system features which summarize the major system capabilities; (3) the operational activity threads which illustrate the interrelationahip between the system elements; and (4) the interfaces which illustrate those elements that originate or generate data and those elements that use the data. The interfaces also provide a description of the data and the data utilization and access techniques.

Cooley, C. G.↗
DOE OSTI2022

Ontology Development Kit: a toolkit for building, maintaining and standardizing biomedical ontologies

Similar to managing software packages, managing the ontology life cycle involves multiple complex workflows such as preparing releases, continuous quality control checking and dependency management. To manage these processes, a diverse set of tools is required, from command-line utilities to powerful ontology-engineering environmentsr. Particularly in the biomedical domain, which has developed a set of highly diverse yet inter-dependent ontologies, standardizing release practices and metadata and establishing shared quality standards are crucial to enable interoperability. The Ontology Development Kit (ODK) provides a set of standardized, customizable and automatically executable workflows, and packages all required tooling in a single Docker image. In this paper, we provide an overview of how the ODK works, show how it is used in practice and describe how we envision it driving standardization efforts in our community.

96 KNOWLEDGE MANAGEMENT AND PRESERVATION↗
NASA NTRS1972

Observations and impressions from lunar orbit

On Apollo 16, the command module pilot made observations of particular surface features and processes to complement photographic and other remotely sensed data. Emphasis was placed on geological problems that required the extreme dynamic range and color sensitivities of the human eye; repetitive observations of varying sun angles and viewing directions; and, in some cases, on-the-scene interpretations. Visual observations and impressions recorded during the mission verified the effectiveness of the hardware and techniques used. The orbiting observer functioned both as a sensor, in otherwise inaccessible areas such as earthshine and shadows, and as a designator of potentially significant data that were acquired on the photographic record.

Mattingly, T. K.↗
NASA NTRS1981

On-line structural parameter identification

Algorithms are presented for on-line parameter identification of structural dynamic systems. As an example, they are used to calculate the parameters of a modal model of a flexible beam. The algorithms are tested using hardware consisting of a 12 ft. beam with four voice coil actuators and nine noncontacting displacement sensors. They are programmed in a CDC Cyber 175 digital computer which provides input command signals for the actuators, reads the sensor data, and processes the algorithm to calculate consistent estimates of the modal parameters of the beam. Experimental results are compared with those of simulation analysis.

Thau, F. E.↗
NASA NTRS1990

BUBBLES: an Automated Decision Support System for Final Approach Controllers

With the assumptions that an explicit schedule exists for landings (and takeoffs) at each runway, that each aircraft has declared an IAS for final approach and will be obligated to fly it as accurately as possible, and that there is a continuous estimate of average windspeed on approach, the objective was to provide automated cues to assist controllers in the spacing of landing aircraft. The cues have two characteristics. First, they are adaptive to estimation errors in position and speed by the radar tracking process and piloting errors in the execution of turns and commanded speed reductions. Second, the cues are responsive to the desires of the human controller. Several diagrams are used to help explain the system.

Chi, Zhizang↗
NASA NTRS1991

Network interface unit design options performance analysis

An analysis is presented of three design options for the Space Station Freedom (SSF) onboard Data Management System (DMS) Network Interface Unit (NIU). The NIU provides the interface from the Fiber Distributed Data Interface (FDDI) local area network (LAN) to the DMS processing elements. The FDDI LAN provides the primary means for command and control and low and medium rate telemetry data transfers on board the SSF. The results of this analysis provide the basis for the implementation of the NIU.

Miller, Frank W.↗
NASA NTRS1992

Design and performance comparison of fuzzy logic based tracking controllers

Several camera tracking controllers based on fuzzy logic principles have been designed and tested in software simulation in the software technology branch at the Johnson Space Center. The fuzzy logic based controllers utilize range measurement and pixel positions from the image as input parameters and provide pan and tilt gimble rate commands as output. Two designs of the rulebase and tuning process applied to the membership functions are discussed in light of optimizing performance. Seven test cases have been designed to test the performance of the controllers for proximity operations where approaches like v-bar, fly-around and station keeping are performed. The controllers are compared in terms of responsiveness, and ability to maintain the object in the field-of-view of the camera. Advantages of the fuzzy logic approach with respect to the conventional approach have been discussed in terms of simplicity and robustness.

Lea, Robert N.↗
NASA NTRS2003

The X-38 Spacecraft Fault-Tolerant Avionics System

In 1995 NASA began an experimental program to develop a reusable crew return vehicle (CRV) for the International Space Station. The purpose of the CRV was threefold: (i) to bring home an injured or ill crewmember; (ii) to bring home the entire crew if the Shuttle fleet was grounded; and (iii) to evacuate the crew in the case of an imminent Station threat (i.e., fire, decompression, etc). Built at the Johnson Space Center, were two approach and landing prototypes and one spacecraft demonstrator (called V201). A series of increasingly complex ground subsystem tests were completed, and eight successful high-altitude drop tests were achieved to prove the design concept. In this program, an unprecedented amount of commercial-off-the-shelf technology was utilized in this first crewed spacecraft NASA has built since the Shuttle program. Unfortunately, in 2002 the program was canceled due to changing Agency priorities. The vehicle was 80% complete and the program was shut down in such a manner as to preserve design, development, test and engineering data. This paper describes the X-38 V201 fault-tolerant avionics system. Based on Draper Laboratory's Byzantine-resilient fault-tolerant parallel processing system and their "network element" hardware, each flight computer exchanges information on a strict timescale to process input data, compare results, and issue voted vehicle output commands. Major accomplishments achieved in this development include: (i) a space qualified two-fault tolerant design using mostly COTS (hardware and operating system); (ii) a single event upset tolerant network element board, (iii) on-the-fly recovery of a failed processor; (iv) use of synched cache; (v) realignment of memory to bring back a failed channel; (vi) flight code automatically generated from the master measurement list; and (vii) built in-house by a team of civil servants and support contractors. This paper will present an overview of the avionics system and the hardware implementation, as well as the system software and vehicle command & telemetry functions. Potential improvements and lessons learned on this program are also discussed.

Kouba,Coy↗
NASA NTRS2004

Framework for Development of Object-Oriented Software

The Real-Time Control (RTC) Application Framework is a high-level software framework written in C++ that supports the rapid design and implementation of object-oriented application programs. This framework provides built-in functionality that solves common software development problems within distributed client-server, multi-threaded, and embedded programming environments. When using the RTC Framework to develop software for a specific domain, designers and implementers can focus entirely on the details of the domain-specific software rather than on creating custom solutions, utilities, and frameworks for the complexities of the programming environment. The RTC Framework was originally developed as part of a Space Shuttle Launch Processing System (LPS) replacement project called Checkout and Launch Control System (CLCS). As a result of the framework s development, CLCS software development time was reduced by 66 percent. The framework is generic enough for developing applications outside of the launch-processing system domain. Other applicable high-level domains include command and control systems and simulation/ training systems.

Perez-Poveda, Gus↗