Engineering Papers⌕ Search

SEARCH · Engineering Papers

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 865 records · Page 48
All sourcesNASA NTRSDOE OSTI
NASA NTRS1991

Telecom 2-B and 2-C (TC2B and TC2C)

The DSN (Deep Space Network) mission support requirements for Telecom 2-B and 2-C (TC2B and TC2C) are summarized. These Telecom missions will provide high-speed data link applications, telephone, and television service between France and overseas territories as a follow-on to TC2A. Mission objectives are outlined and the DSN support requirements are defined through the presentation of tables and narratives describing the spacecraft flight profile; DSN support coverage; frequency assignments; support parameters for telemetry, command and support systems; and tracking support responsibility.

Dulac, J.↗
NASA NTRS1991

Ulysses

The DSN (Deep Space Network) mission support requirements for Ulysses are summarized. The primary goal of the Ulysses mission is to explore the Sun, its environment, and possible links between solar variability and terrestrial weather and climate. The Ulysses spacecraft will be injected into an interplanetary orbit toward Jupiter after which the spacecraft travels in a heliocentric, out-of-ecliptic orbit with high heliographic inclination. The Ulysses mission objectives are outlined and the DSN support requirements are defined through the presentation of tables and narratives describing the spacecraft flight profile; DSN support coverage; frequency assignments; support parameters for telemetry, command and support systems; and tracking support responsibility.

Meeks, W.↗
NASA NTRS1991

Upper Atmosphere Research Satellite (UARS): Emergency support

The DSN (Deep Space Network) mission support requirements for the Upper Atmospheric Research Satellite (UARS) are summarized. The UARS satellite will be placed into a circular orbit of 600 km and 57 deg inclination with a period of 97 minutes. The mission objectives are outlined and the DSN support requirements are defined through the presentation of tables and narratives describing the spacecraft flight profile; DSN support coverage; frequency assignments; support parameters for telemetry, command and support systems; and tracking support responsibility.

Osler, S.↗
NASA NTRS1991

Agreements/subagreements Applicable to Wallops, 12 Nov. 1991

The status of space science agreements are noted. A general overview of the Wallops Flight Facility (WFF) is given. The geography, history, and mission of the facility are briefly surveyed. Brief accounts are given of NASA earth science activities at the WFF, including atmospheric dynamics, atmospheric optics, ocean physics, microwave altimetry, ocean color research, wind-wave-current interaction, flight support activities, the Sounding Rocket Program, and the NASA Balloon Program. Also discussed are the WFF launch range, the research airport, aircraft airborne science, telemetry, data systems, communications, and command and control.

Source record↗
NASA NTRS1990

Computer based control of the Superfluid Helium On-Orbit Transfer Space Shuttle experiment

Ground software that is being developed for the control of the Superfluid Helium On-Orbit Transfer (SHOOT) project is discussed. Special attention is given to two software development projects for SHOOT support: (1) the SHOOT Command and Monitoring System, which will provide a real-time highly interactive interface for the SHOOT principal investigator to control the experiment and to analyze and display its telemetry; and (2) the SHOOT Aft Flight Deck Operating System, which is comprised of several monitoring programs to give the astronaut mission specialist on-orbit visibility into SHOOT systems, and an intelligent-rule-based system that will control a He transfer without ground intervention. Major accomplishments of the SHOOT project to date include two successful interface tests with the Goddard Space Flight Center developed breadboard electronics and prototype software.

Castellano, T. P.↗
NASA NTRS1999

IEEE 1393 Spaceborne Fiber Optic Data Bus: A Standard Approach to On-Board Payload Data Handling Networks for the AIAA Space Technology Conference and Exposition "Partnering in the 21th Century"

The Spaceborne Fiber Optic Data Bus (SFODB) is the next generation in on-board data handling networks. It will do for high speed payloads what SAE 1773 has done for on-board command and telemetry systems. That is, it will significantly reduce the cost of payload development, integration and test through interface standardization. As defined in IEEE 1393, SFODB is a 1 Gb/s, fiber optic network specifically designed to support the real-time, on-board data handling requirements of remote sensing spacecraft. The network is highly reliable, fault tolerant, and capable of withstanding the rigors of launch and the harsh space environment. SFODB achieves this operational and environmental performance while maintaining the small size, light weight, and low power necessary for spaceborne applications. SFODB was developed jointly by DoD and NASA GSFC to meet the on-board data handling needs of Remote Sensing satellites. This jointly funded project produced a complete set of flight transmitters, receivers and protocol ASICS; a complete Development & Evaluation System; and, the IEEE 1393 standard.

Andrucyk, Dennis J.↗
NASA NTRS2001

Space Internet-Embedded Web Technologies Demonstration

The NASA Glenn Research Center recently demonstrated the ability to securely command and control space-based assets by using the Internet and standard Internet Protocols (IP). This is a significant accomplishment because future NASA missions will benefit by using Internet standards-based protocols. The benefits include reduced mission costs and increased mission efficiency. The Internet-Based Space Command and Control System Architecture demonstrated at the NASA Inspection 2000 event proved that this communications architecture is viable for future NASA missions.

Foltz, David A.↗
NASA NTRS2002

STS-109 Flight Day 2 Highlights

Footage shows the cargo bay of the Columbia Orbiter, including the rigid array carrier, the solar arrays to be installed on the Hubble Space Telescope, and the robotic arm. Close-up shots show several components of the flight support system. STS-109 Commander Scott Altman, Payload Commander John Grunsfeld, and Mission Specialist Nancy Currie are seen on the flight deck, and they answer questions about the stabilization of the freon flow, details of the upcoming rendezvous and capture of the Hubble Space Telescope, the scheduled spacewalks, and the social dynamics of the flight crew.

Source record↗
NASA NTRS2003

A Little Goes a Long Way

We were a team of five engineers responsible for the command and data systems used during experiment integration and testing of Spacelab payloads. For the most part, we performed component level testing for the experiments, the first phase of testing for Spacelab Program payloads. In the beginning, the members of my team didn't know what to think of me, but as time went by they realized that I was sincere. A relationship of trust developed. Since then, we've all moved on to other projects, but every now and then we run into each other and the bond that we have is still strong. Every good manager wants to do well by the people working on a project. One way to achieve this is simple: Pay attention to the environment in which your employees work. People warn you not to get mired in the details; they say you might miss the big picture. But sometimes it's the details that give you a better view of what the big picture is all about.

Jenkins, Kimberly R.↗
NASA NTRS2004

Radical is Temporary

I suspect that even if Ken had stayed on, we would have evolved to the state we're in right now. In terms of the nature of the work that we're doing, we've gone from development to maintenance, and so the project team needed to evolve to reflect that change. The analogy I use to describe Hubble is a data factory, and we provide the factory controller. The telescope takes in light and produces pictures, and we're the ones sending all of the control signals and monitoring the temperature, power, and voltages in the factory to make sure the production line is doing its job and that it's not reaching some sort of a stress point. That's basically it. We maintain the Hubble command and control system. I think we're still putting out a good quality product. We still meet our schedule and cost milestones. Every time we make a change to the ground system, we run a suite of tests to make sure that the system still runs as expected, and that it correctly controls the spacecraft. Other than that, provided the interfaces are controlled, everything is okay.

Barrett, Larry↗
NASA NTRS2006

Entertainment and Pacification System For Car Seat

An entertainment and pacification system for use with a child car seat has speakers mounted in the child car seat with a plurality of audio sources and an anti-noise audio system coupled to the child car seat. A controllable switching system provides for, at any given time, the selective activation of i) one of the audio sources such that the audio signal generated thereby is coupled to one or more of the speakers, and ii) the anti-noise audio system such that an ambient-noise-canceling audio signal generated thereby is coupled to one or more of the speakers. The controllable switching system can receive commands generated at one of first controls located at the child car seat and second controls located remotely with respect to the child car seat with commands generated by the second controls overriding commands generated by the first controls.

Elrod, Susan Vinz↗
NASA NTRS2009

Aquarius Digital Processing Unit

Three documents provide information on a digital processing unit (DPU) for the planned Aquarius mission, in which a radiometer aboard a spacecraft orbiting Earth is to measure radiometric temperatures from which data on sea-surface salinity are to be deduced. The DPU is the interface between the radiometer and an instrument-command-and-data system aboard the spacecraft. The DPU cycles the radiometer through a programmable sequence of states, collects and processes all radiometric data, and collects all housekeeping data pertaining to operation of the radiometer. The documents summarize the DPU design, with emphasis on innovative aspects that include mainly the following: a) In the radiometer and the DPU, conversion from analog voltages to digital data is effected by means of asynchronous voltage-to-frequency converters in combination with a frequency-measurement scheme implemented in field-programmable gate arrays (FPGAs). b) A scheme to compensate for aging and changes in the temperature of the DPU in order to provide an overall temperature-measurement accuracy within 0.01 K includes a high-precision, inexpensive DC temperature measurement scheme and a drift-compensation scheme that was used on the Cassini radar system. c) An interface among multiple FPGAs in the DPU guarantees setup and hold times.

Forgione, Joshua↗
NASA NTRS2007

WMAP C&DH Software

The command-and-data-handling (C&DH) software of the Wilkinson Microwave Anisotropy Probe (WMAP) spacecraft functions as the sole interface between (1) the spacecraft and its instrument subsystem and (2) ground operations equipment. This software includes a command-decoding and -distribution system, a telemetry/data-handling system, and a data-storage-and-playback system. This software performs onboard processing of attitude sensor data and generates commands for attitude-control actuators in a closed-loop fashion. It also processes stored commands and monitors health and safety functions for the spacecraft and its instrument subsystems. The basic functionality of this software is the same of that of the older C&DH software of the Rossi X-Ray Timing Explorer (RXTE) spacecraft, the main difference being the addition of the attitude-control functionality. Previously, the C&DH and attitude-control computations were performed by different processors because a single RXTE processor did not have enough processing power. The WMAP spacecraft includes a more-powerful processor capable of performing both computations.

Cudmore, Alan↗
NASA NTRS2010

KSC Technical Capabilities Website

This document is the website pages that review the technical capabilities that the Kennedy Space Center (KSC) has for partnership opportunities. The purpose of this information is to make prospective customers aware of the capabilities and provide an opportunity to form relationships with the experts at KSC. The technical capabilities fall into these areas: (1) Ground Operations and Processing Services, (2) Design and Analysis Solutions, (3) Command and Control Systems / Services, (4) Materials and Processes, (5) Research and Technology Development and (6) Laboratories, Shops and Test Facilities.

Nufer, Brian↗
NASA NTRS2012

Simpler ISS Flight Control Communications and Log Keeping via Social Tools and Techniques

The heart of flight operations control involves a) communicating effectively in real time with other controllers in the room and/or in remote locations and b) tracking significant events, decisions, and rationale to support the next set of decisions, provide a thorough shift handover, and troubleshoot/improve operations. International Space Station (ISS) flight controllers speak with each other via multiple voice circuits or loops, each with a particular purpose and constituency. Controllers monitor and/or respond to several loops concurrently. The primary tracking tools are console logs, typically kept by a single operator and not visible to others in real-time. Information from telemetry, commanding, and planning systems also plays into decision-making. Email is very secondary/tertiary due to timing and archival considerations. Voice communications and log entries supporting ISS operations have increased by orders of magnitude because the number of control centers, flight crew, and payload operations have grown. This paper explores three developmental ground system concepts under development at Johnson Space Center s (JSC) Mission Control Center Houston (MCC-H) and Marshall Space Flight Center s (MSFC) Payload Operations Integration Center (POIC). These concepts could reduce ISS control center voice traffic and console logging yet increase the efficiency and effectiveness of both. The goal of this paper is to kindle further discussion, exploration, and tool development.

Scott, David W.↗
NASA NTRS2013

Developing a Model Component

The Spaceport Command and Control System (SCCS) Simulation Computer Software Configuration Item (CSCI) is responsible for providing simulations to support test and verification of SCCS hardware and software. The Universal Coolant Transporter System (UCTS) was a Space Shuttle Orbiter support piece of the Ground Servicing Equipment (GSE). The initial purpose of the UCTS was to provide two support services to the Space Shuttle Orbiter immediately after landing at the Shuttle Landing Facility. The UCTS is designed with the capability of servicing future space vehicles; including all Space Station Requirements necessary for the MPLM Modules. The Simulation uses GSE Models to stand in for the actual systems to support testing of SCCS systems during their development. As an intern at Kennedy Space Center (KSC), my assignment was to develop a model component for the UCTS. I was given a fluid component (dryer) to model in Simulink. I completed training for UNIX and Simulink. The dryer is a Catch All replaceable core type filter-dryer. The filter-dryer provides maximum protection for the thermostatic expansion valve and solenoid valve from dirt that may be in the system. The filter-dryer also protects the valves from freezing up. I researched fluid dynamics to understand the function of my component. The filter-dryer was modeled by determining affects it has on the pressure and velocity of the system. I used Bernoulli's Equation to calculate the pressure and velocity differential through the dryer. I created my filter-dryer model in Simulink and wrote the test script to test the component. I completed component testing and captured test data. The finalized model was sent for peer review for any improvements. I participated in Simulation meetings and was involved in the subsystem design process and team collaborations. I gained valuable work experience and insight into a career path as an engineer.

Fields, Christina M.↗
NASA NTRS2013

Developing a Model Component

The Spaceport Command and Control System (SCCS) Simulation Computer Software Configuration Item (CSCI) is,. responsible for providing simulations to support test and verification of SCCS hardware and software. The Universal Coolant Transporter System (UCTS) is a Space Shuttle Orbiter support piece of the Ground Servicing Equipment (GSE). The purpose of the UCTS is to provide two support services to the Space Shuttle Orbiter immediately after landing at the Shuttle Landing Facility. The Simulation uses GSE Models to stand in for the actual systems to support testing of SCCS systems s:luring their development. As an intern at KSC, my assignment was to develop a model component for the UCTS. I was given a fluid component (drier) to model in Matlab. The drier was a Catch All replaceable core type filter-drier. The filter-drier provides maximum protection for the thermostatic expansion valve and solenoid valve from dirt that may be in the system. The filter-drier also protects the valves from freezing up. I researched fluid dynamics to understand the function of my component. I completed training for UNIX and Simulink to help aid in my assignment. The filter-drier was modeled by determining affects it has on the pressure, velocity and temperature of the system. I used Bernoulli's Equation to calculate the pressure and velocity differential through the dryer. I created my model filter-drier in Simulink and wrote the test script to test the component. I completed component testing and captured test data. The finalized model was sent for peer review for any improvements.

Fields, Christina M.↗
NASA NTRS2013

Creating and Testing Simulation Software

The goal of this project is to learn about the software development process, specifically the process to test and fix components of the software. The paper will cover the techniques of testing code, and the benefits of using one style of testing over another. It will also discuss the overall software design and development lifecycle, and how code testing plays an integral role in it. Coding is notorious for always needing to be debugged due to coding errors or faulty program design. Writing tests either before or during program creation that cover all aspects of the code provide a relatively easy way to locate and fix errors, which will in turn decrease the necessity to fix a program after it is released for common use. The backdrop for this paper is the Spaceport Command and Control System (SCCS) Simulation Computer Software Configuration Item (CSCI), a project whose goal is to simulate a launch using simulated models of the ground systems and the connections between them and the control room. The simulations will be used for training and to ensure that all possible outcomes and complications are prepared for before the actual launch day. The code being tested is the Programmable Logic Controller Interface (PLCIF) code, the component responsible for transferring the information from the models to the model Programmable Logic Controllers (PLCs), basic computers that are used for very simple tasks.

Heinich, Christina M.↗