Search NASA⌕ Search

SEARCH · Search NASA

Results for “spacecraft commanding”

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 217 records · Page 12

Re-Engineering the Multimission Command System at the Jet Propulsion Laboratory

This paper will discuss the design and implementation of the command software, especially trade-offs and lessons learned from practical operational use in JPL's Advanced Multimission Operations System.The command system provides an advanced multimission environment for secure, concurrent commanding of multiple spacecraft. The lessons learned have resulted in a re-engineering of the command system, especially in its user interface and new automation capabilities. This paper will also discuss new development work including a multimission command database toolkit, a universal command translator for sequencing and real-time commands, and incorporation of telecommand capabilities for new missions.

re-engineering↗

Pointing compensation system for spacecraft instruments

A closed loop system reduces pointing errors in one or more spacecraft instruments. Associated with each instrument is a electronics package (3) for commanding motion in that instrument and a pointing control system (5) for imparting motion in that instrument in response to a command (4) from the commanding package (3). Spacecraft motion compensation logic (25) compensates for instrument pointing errors caused by instrument-motion-induced spacecraft motion. Any finite number of instruments can be so compensated, by providing each pointing control system (5) and each commanding package (3), for the instruments desired to be compensated, with a link to the spacecraft motion compensation logic (25). The spacecraft motion compensation logic (25) is an electronic manifestation of the algebraic negative of a model of the dynamics of motion of the spacecraft. An example of a suitable model, and computer-simulated results, are presented.

Plescia, Carl T.↗

Test Telemetry And Command System (TTACS)

The Jet Propulsion Laboratory has developed a multimission Test Telemetry and Command System (TTACS) which provides a multimission telemetry and command data system in a spacecraft test environment. TTACS reuses, in the spacecraft test environment, components of the same data system used for flight operations; no new software is developed for the spacecraft test environment. Additionally, the TTACS is transportable to any spacecraft test site, including the launch site. The TTACS is currently operational in the Galileo spacecraft testbed; it is also being provided to support the Cassini and Mars Surveyor Program projects. Minimal personnel data system training is required in the transition from pre-launch spacecraft test to post-launch flight operations since test personnel are already familiar with the data system's operation. Additionally, data system components, e.g. data display, can be reused to support spacecraft software development; and the same data system components will again be reused during the spacecraft integration and system test phases. TTACS usage also results in early availability of spacecraft data to data system development and, as a result, early data system development feedback to spacecraft system developers. The TTACS consists of a multimission spacecraft support equipment interface and components of the multimission telemetry and command software adapted for a specific project. The TTACS interfaces to the spacecraft, e.g., Command Data System (CDS), support equipment. The TTACS telemetry interface to the CDS support equipment performs serial (RS-422)-to-ethernet conversion at rates between 1 bps and 1 mbps, telemetry data blocking and header generation, guaranteed data transmission to the telemetry data system, and graphical downlink routing summary and control. The TTACS command interface to the CDS support equipment is nominally a command file transferred in non-real-time via ethernet. The CDS support equipment is responsible for metering the commands to the CDS; additionally for Galileo, TTACS includes a real-time-interface to the CDS support equipment. The TTACS provides the basic functionality of the multimission telemetry and command data system used during flight operations. TTACS telemetry capabilities include frame synchronization, Reed-Solomon decoding, packet extraction and channelization, and data storage/query. Multimission data display capabilities are also available. TTACS command capabilities include command generation verification, and storage.

Fogel, Alvin J.↗

Advanced Diagnostic System on Earth Observing One

In this infusion experiment, the Livingstone 2 (L2) model-based diagnosis engine, developed by the Computational Sciences division at NASA Ames Research Center, has been uploaded to the Earth Observing One (EO-1) satellite. L2 is integrated with the Autonomous Sciencecraft Experiment (ASE) which provides an on-board planning capability and a software bridge to the spacecraft's 1773 data bus. Using a model of the spacecraft subsystems, L2 predicts nominal state transitions initiated by control commands, monitors the spacecraft sensors, and, in the case of failure, isolates the fault based on the discrepant observations. Fault detection and isolation is done by determining a set of component modes, including most likely failures, which satisfy the current observations. All mode transitions and diagnoses are telemetered to the ground for analysis. The initial L2 model is scoped to EO-1's imaging instruments and solid state recorder. Diagnostic scenarios for EO-1's nominal imaging timeline are demonstrated by injecting simulated faults on-board the spacecraft. The solid state recorder stores the science images and also hosts: the experiment software. The main objective of the experiment is to mature the L2 technology to Technology Readiness Level (TRL) 7. Experiment results are presented, as well as a discussion of the challenging technical issues encountered. Future extensions may explore coordination with the planner, and model-based ground operations.

Hayden, Sandra C.↗

The Next Generation of Ground Operations Command and Control; Scripting in C no. and Visual Basic

Scripting languages have become a common method for implementing command and control solutions in space ground operations. The Systems Test and Operations Language (STOL), the Huntsville Operations Support Center (HOSC) Scripting Language Processor (SLP), and the Spacecraft Control Language (SCL) offer script-commands that wrap tedious operations tasks into single calls. Since script-commands are interpreted, they also offer a certain amount of hands-on control that is highly valued in space ground operations. Although compiled programs seem to be unsuited for interactive user control and are more complex to develop, Marshall Space flight Center (MSFC) has developed a product called the Enhanced and Redesign Scripting (ERS) that makes use of the graphical and logical richness of a programming language while offering the hands-on and ease of control of a scripting language. ERS is currently used by the International Space Station (ISS) Payload Operations Integration Center (POIC) Cadre team members. ERS integrates spacecraft command mnemonics, telemetry measurements, and command and telemetry control procedures into a standard programming language, while making use of Microsoft's Visual Studio for developing Visual Basic (VB) or C# ground operations procedures. ERS also allows for script-style user control during procedure execution using a robust graphical user input and output feature. The availability of VB and C# programmers, and the richness of the languages and their development environment, has allowed ERS to lower our "script" development time and maintenance costs at the Marshall POIC.

Ritter, George↗

Atmosphere Explorer control system software (version 1.0)

The basic design is described of the Atmosphere Explorer Control System (AECS) software used in the testing, integration, and flight contol of the AE spacecraft and experiments. The software performs several vital functions, such as issuing commands to the spacecraft and experiments, receiving and processing telemetry data, and allowing for extensive data processing by experiment analysis programs. The major processing sections are: executive control section, telemetry decommutation section, command generation section, and utility section.

Villasenor, A.↗

Human Flight to Lunar and Beyond - Re-Learning Operations Paradigms

For the first time since the Apollo era, NASA is planning on sending astronauts on flights beyond Low-Earth Orbit (LEO). The Human Space Flight (HSF) program started with a successful initial flight in Earth orbit, in December 2014. The program will continue with two Exploration Missions (EM) to Lunar orbit: EM-1 will be unmanned and EM-2, carrying astronauts, will follow. NASA established a multi-center team to address the communications, and related navigation, needs. This paper will focus on the lessons learned in the team, planning for the missions' parts that are beyond Earth orbit. Many of these lessons had to be re-learned, as the HSF program after operated for many years in Earth orbit. Fortunately, the experience base from tracking robotic missions in deep space by the Deep Space Network (DSN) and close interaction with the HSF community to understand the unique needs (e.g. 2-way voice) resulted in a ConOps that leverages of both the deep space robotic and the Human LEO experiences. Several examples will be used to highlight the unique operational needs for HSF missions beyond Earth Orbit, including: - Navigation. At LEO, HSF missions can rely on Global Positioning System (GPS) devices for orbit determination. For Lunar-and-beyond HSF missions, techniques such as precision 2-way and 3-way Doppler and ranging, Delta-Difference-of-range, and eventually on-board navigation will be used. - Impact of latency - the delay associated with Round-Trip-Light-Time (RTLT). Imagine trying to have a 2-way discussion (audio or video) with an astronaut, with a 2-3 sec delay inserted (for Lunar distances) or 20 minutes delay (for Mars distances). - Balanced communications link. For robotic missions, there has been a heavy emphasis on the downlink data rates, bringing back science data from the instruments on-board the spacecraft. Uplink data rates were of secondary importance, used to send commands to the spacecraft. The ratio of downlink-to-uplink data rates was often 10:1 or more. For HSF, rates for uplink and downlink, at least for high-quality video, need to be similar.

Kenny, Ted↗

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↗

Message Mode Operations for Spacecraft: A Proposal for Operating Spacecraft During Cruise and Mitigating the Network Loading Crunch

The NASA Deep Space Network (DSN) is a world-class spacecraft tracking facility with stations located in Spain, Australia and USA, servicing Deep Space Missions of many space agencies. The current system of scheduling spacecraft during cruise for multiple 8 hour tracking sessions per week currently leads to an overcommitted DSN. Studies indicate that future projected mission demands upon the Network will only make the loading problem worse. Therefore, a more efficient scheduling of DSN resources is necessary in order to support the additional network loading envisioned in the next few years: The number of missions is projected to increase from 25 in 1998 to 34 by 2001. In fact given the challenge of the NASA administrator, Dan Goldin, of launching 12 spacecraft per year, the DSN would be tracking approximately 90 spacecraft by 2010. Currently a large amount of antenna time and network resources are subscribed by a project in order to have their mission supported during the cruise phase. The recently completed Mars Pathfinder mission was tracked 3 times a week (8 hours/day) during the majority of its cruise to Mars. This paper proposes an innovative approach called Message Mode Operations (MMO) for mitigating the Network loading problem while continuing to meet the tracking, reporting, time management, and scheduling requirements of these missions during Cruise while occupying very short tracking times. MMO satisfies these requirements by providing the following services: Spacecraft Health and Welfare Monitoring Service Command Delivery Service Adaptive Spacecraft Scheduling Service Orbit Determination Service Time Calibration Service Utilizing more efficient engineering telemetry summarization and filtering techniques on-board the spacecraft and collapsing the navigation requirements for Doppler and Range into shorter tracks, we believe spacecraft can be adequately serviced using short 10 to 30 minute tracking sessions. This claim assumes that certain changes would have to he made in the way the Network traditionally services missions in Cruise. Furthermore, limiting spacecraft to short sessions will free up larger blocks of time in the tracking schedule to help accommodate future tracking demands soon to be placed upon the Network. This paper describes the key characteristics and benefits of MMO, the operational scenarios for its use, the required changes to the ground system in order to make this approach feasible and the results of two simulations: 1) to determine the effects of MMO on projected mission loading on the DSN and, 2) to determine the effect MMO has on spacecraft orbit determination.

Greenberg, Ed↗

Autonomy Architectures for a Constellation of Spacecraft

Until the past few years, missions typically involved fairly large expensive spacecraft. Such missions have primarily favored using older proven technologies over more recently developed ones, and humans controlled spacecraft by manually generating detailed command sequences with low-level tools and then transmitting the sequences for subsequent execution on a spacecraft controller. This approach toward controlling a spacecraft has worked spectacularly on previous missions, but it has limitations deriving from communications restrictions - scheduling time to communicate with a particular spacecraft involves competing with other projects due to the limited number of deep space network antennae. This implies that a spacecraft can spend a long time just waiting whenever a command sequence fails. This is one reason why the New Millennium program has an objective to migrate parts of mission control tasks onboard a spacecraft to reduce wait time by making spacecraft more robust. The migrated software is called a "remote agent" and has 4 components: a mission manager to generate the high level goals, a planner/scheduler to turn goals into activities while reasoning about future expected situations, an executive/diagnostics engine to initiate and maintain activities while interpreting sensed events by reasoning about past and present situations, and a conventional real-time subsystem to interface with the spacecraft to implement an activity's primitive actions. In addition to needing remote planning and execution for isolated spacecraft, a trend toward multiple-spacecraft missions points to the need for remote distributed planning and execution. The past few years have seen missions with growing numbers of probes. Pathfinder has its rover (Sojourner), Cassini has its lander (Huygens), and the New Millenium Deep Space 3 (DS3) proposal involves a constellation of 3 spacecraft for interferometric mapping. This trend is expected to continue to progressively larger fleets. For example, one mission proposed to succeed DS3 would have 18 spacecraft flying in formation in order to detect earth-sized planets orbiting other stars. A proposed magnetospheric constellation would involve 5 to 500 spacecraft in Earth orbit to measure global phenomena within the magnetosphere. This work describes and compares three autonomy architectures for a system that continuously plans to control a fleet of spacecraft using collective mission goals instead of goals or command sequences for each spacecraft. A fleet of self-commanding spacecraft would autonomously coordinate itself to satisfy high level science and engineering goals in a changing partially-understood environment making feasible the operation of tens or even a hundred spacecraft (such as for interferometry or plasma physics missions). The easiest way to adapt autonomous spacecraft research to controlling constellations involves treating the constellation as a single spacecraft. Here one spacecraft directly controls the others as if they were connected. The controlling "master" spacecraft performs all autonomy reasoning, and the slaves only have real-time subsystems to execute the master's commands and transmit local telemetry/observations. The executive/diagnostics module starts actions and the master's real-time subsystem controls the action either locally or remotely through a slave. While the master/slave approach benefits from conceptual simplicity, it relies on an assumption that the master spacecraft's executive can continuously monitor the slaves' real-time subsystems, and this relies on high-bandwidth highly-reliable communications. Since unintended results occur fairly rarely, one way to relax the bandwidth requirements involves only monitoring unexpected events in spacecraft. Unfortunately, this disables the ability to monitor for unexpected events between spacecraft and leads to a host of coordination problems among the slaves. Also, failures in the communications system can result in losing slaves. The other two architectures improve robustness while reducing communications by progressively distributing more of the other three remote agent components across the constellation. In a teamwork architecture, all spacecraft have executives and real-time subsystems - only the leader has the planner/scheduler and mission manager. Finally, distributing all remote agent components leads to a peer-to-peer approach toward constellation control.

Barrett, Anthony↗

ULSGEN (Uplink Summary Generator)

Uplink is an important part of spacecraft operations. Ensuring the accuracy of uplink content is essential to mission success. Before commands are radiated to the spacecraft, the command and sequence must be reviewed and verified by various teams. In most cases, this process requires collecting the command data, reviewing the data during a command conference meeting, and providing physical signatures by designated members of various teams to signify approval of the data. If commands or sequences are disapproved for some reason, the whole process must be restarted. Recording data and decision history is important for traceability reasons. Given that many steps and people are involved in this process, an easily accessible software tool for managing the process is vital to reducing human error which could result in uplinking incorrect data to the spacecraft. An uplink summary generator called ULSGEN was developed to assist this uplink content approval process. ULSGEN generates a web-based summary of uplink file content and provides an online review process. Spacecraft operations personnel view this summary as a final check before actual radiation of the uplink data. .

Wang, Y.-F.↗

Standardization and economics of nuclear spacecraft: Executive summary

Feasibility and cost benefits of nuclear-powered standardized spacecraft were investigated. The study indicates that two shuttle-launched nuclear-powered spacecraft should be able to serve the majority of unmanned NASA missions anticipated for the 1980's. The standard spacecraft include structure, thermal control, power, attitude control, some propulsion capability and tracking, telemetry, and command subsystems. One spacecraft design, powered by the radioisotope thermoelectric generator, can serve missions requiring up to 450 watts. The other spacecraft design, powered by similar nuclear heat sources in a Brayton-cycle generator, can serve missions requiring up to 2200 watts. Design concepts and trade-offs are discussed. The conceptual designs selected are presented and successfully tested against a variety of missions. The thermal design is such that both spacecraft are capable of operating in any earth orbit and any orientation without modification.

Source record↗

Algorithm Optimally Allocates Actuation of a Spacecraft

A report presents an algorithm that solves the following problem: Allocate the force and/or torque to be exerted by each thruster and reaction-wheel assembly on a spacecraft for best performance, defined as minimizing the error between (1) the total force and torque commanded by the spacecraft control system and (2) the total of forces and torques actually exerted by all the thrusters and reaction wheels. The algorithm incorporates the matrix vector relationship between (1) the total applied force and torque and (2) the individual actuator force and torque values. It takes account of such constraints as lower and upper limits on the force or torque that can be applied by a given actuator. The algorithm divides the aforementioned problem into two optimization problems that it solves sequentially. These problems are of a type, known in the art as semi-definite programming problems, that involve linear matrix inequalities. The algorithm incorporates, as sub-algorithms, prior algorithms that solve such optimization problems very efficiently. The algorithm affords the additional advantage that the solution requires the minimum rate of consumption of fuel for the given best performance.

Motaghedi, Shi↗

Telemetry and command standards

The first phase of the international Consultative Committee for Space Data Systems (CCSDS) efforts toward the definition of standards for space telemetry, spacecraft tracking, and command functions has established a set of standard space communications techniques capable of satisfying almost the entire spectrum of space mission user requirements. This was achieved by focusing on the distinctive problems associated with the space/ground data link, and developing the infrastructural system designated the 'Open Systems Interconnection'. The intrinsically international coordination by CCSDS of development efforts ensures highly flexible mutual support activities by the various national space agencies.

Hooke, Adrian J.↗

Move to Talk, Talk to Move: Tightly Integrated Communication and Control for Coordinated Swarms of Small Spacecraft

The Move to Talk, Talk to Move: Tightly Integrated Communication and Control for Coordinated Swarms of Small Spacecraft project will build on existing research on collaborative autonomy of multi-agent systems and design techniques that will enable coordinated communication and control of spacecraft. The success of many space exploration and science missions hinges on real-time monitoring of time-varying and/or geographically distributed phenomena. This monitoring can be achieved using a swarm of small spacecraft, which collect data about the environment and share information within the swarm of spacecraft. Current space exploration missions typically issue commands to control each spacecraft individually from Earth, and the data gathered by each spacecraft is also transmitted to Earth separately via X-band communication over the Deep Space Network (DSN). This approach is expensive, slow, and unreliable. Many coordinated tasks amongst a swarm of autonomous agents (or, specifically, small spacecraft) rely on communication. Existing control, estimation, and decision algorithms often assume that mostly reliable communications are available; however, this is often not the case in actual environments and thus is a barrier to operating swarms of small spacecraft.

Qi Han↗

STEREO Superior Solar Conjunction Mission Phase

With its long duration and high gain antenna (HGA) feed thermal constraint; the NASA Solar-TErestrial RElations Observatory (STEREO) solar conjunction mission phase is quite unique to deep space operations. Originally designed for a two year heliocentric orbit mission to primarily study coronal mass ejection propagation, after 8 years of continuous science data collection, the twin STEREO observatories entered the solar conjunction mission phase, for which they were not designed. Nine months before entering conjunction, an unforeseen thermal constraint threatened to stop daily communications and science data collection for 15months. With a 3.5 month long communication blackout from the superior solar conjunction, without ground commands, each observatory will reset every 3 days, resulting in 35 system resets at an Earth range of 2 AU. As the observatories will be conjoined for the first time in 8 years, a unique opportunity for calibrating the same instruments on identical spacecraft will occur. As each observatory has lost redundancy, and with only a limited fidelity hardware simulator, how can the new observatory configuration be adequately and safely tested on each spacecraft? Without ground commands, how would a 3-axis stabilized spacecraft safely manage the ever accumulating system momentum without using propellant for thrusters? Could science data still be collected for the duration of the solar conjunction mission phase? Would the observatories survive? In its second extended mission, operational resources were limited at best. This paper discusses the solutions to the STEREO superior solar conjunction operational challenges, science data impact, testing, mission operations, results, and lessons learned while implementing.

STEREO↗

Testing of Environmental Satellite Bus-Instrument Interfaces Using Engineering Models

This paper discusses the formulation and execution of a laboratory test of the electrical interfaces between multiple atmospheric science instruments and the spacecraft bus that carries them. The testing, performed in 2002, used engineering models of the instruments that will be flown on the Aura s p a c m and of the Aura spacecraft bus electronics. Aura is one of NASA's Earth Observing System @OS) Program missions managed by the Goddard Space Flight Center. The test was designed to evaluate the complex interfaces in the spacecraft and instrument command and data handling (C&DH) subsystems prior to integration of the complete flight instruments on the spacecraft. A problem discovered during (and not before) the flight hardware integration phase can cause significant cost and schedule impacts. The testing successfully surfaced problems and led to their resolution before the full-up integration phase, saving significant cost and schedule time. This approach could be used on future environmental satellite programs involving multiple, complex scientific instruments being integrated onto a bus.

Gagnier, Don↗