SEARCH · Search NASA

Results for “COMMAND”

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.

SourceResearch connectionFrom yearThrough year

Quote a phrase for an exact phrase match. Source license links do not imply unrestricted reuse.

At least 685 records · Page 38

All sources NASA NTRS DOE OSTI

NASA NTRS1999

Autonomous Onboard Science Image Analysis for Future Mars Rover Missions

To explore high priority landing sites and to prepare for eventual human exploration, future Mars missions will involve rovers capable of traversing tens of kilometers. However, the current process by which scientists interact with a rover does not scale to such distances. Specifically, numerous command cycles are required to complete even simple tasks, such as, pointing the spectrometer at a variety of nearby rocks. In addition, the time required by scientists to interpret image data before new commands can be given and the limited amount of data that can be downlinked during a given command cycle constrain rover mobility and achievement of science goals. Experience with rover tests on Earth supports these concerns. As a result, traverses to science sites as identified in orbital images would require numerous science command cycles over a period of many weeks, months or even years, perhaps exceeding rover design life and other constraints. Autonomous onboard science analysis can address these problems in two ways. First, it will allow the rover to transmit only "interesting" images, defined as those likely to have higher science content. Second, the rover will be able to anticipate future commands. For example, a rover might autonomously acquire and return spectra of "interesting" rocks along with a high resolution image of those rocks in addition to returning the context images in which they were detected. Such approaches, coupled with appropriate navigational software, help to address both the data volume and command cycle bottlenecks that limit both rover mobility and science yield. We are developing fast, autonomous algorithms to enable such intelligent on-board decision making by spacecraft. Autonomous algorithms developed to date have the ability to identify rocks and layers in a scene, locate the horizon, and compress multi-spectral image data. Output from these algorithms could be used to autonomously obtain rock spectra, determine which images should be transmitted to the ground, or to aid in image compression. We will discuss these and other algorithms and demonstrate their performance during a recent rover field test.

Gulick, V. C.↗

NASA NTRS1999

Autonomous Image Analysis for Future Mars Missions

To explore high priority landing sites and to prepare for eventual human exploration, future Mars missions will involve rovers capable of traversing tens of kilometers. However, the current process by which scientists interact with a rover does not scale to such distances. Specifically, numerous command cycles are required to complete even simple tasks, such as, pointing the spectrometer at a variety of nearby rocks. In addition, the time required by scientists to interpret image data before new commands can be given and the limited amount of data that can be downlinked during a given command cycle constrain rover mobility and achievement of science goals. Experience with rover tests on Earth supports these concerns. As a result, traverses to science sites as identified in orbital images would require numerous science command cycles over a period of many weeks, months or even years, perhaps exceeding rover design life and other constraints. Autonomous onboard science analysis can address these problems in two ways. First, it will allow the rover to preferentially transmit "interesting" images, defined as those likely to have higher science content. Second, the rover will be able to anticipate future commands. For example, a rover might autonomously acquire and return spectra of "interesting" rocks along with a high-resolution image of those rocks in addition to returning the context images in which they were detected. Such approaches, coupled with appropriate navigational software, help to address both the data volume and command cycle bottlenecks that limit both rover mobility and science yield. We are developing fast, autonomous algorithms to enable such intelligent on-board decision making by spacecraft. Autonomous algorithms developed to date have the ability to identify rocks and layers in a scene, locate the horizon, and compress multi-spectral image data. We are currently investigating the possibility of reconstructing a 3D surface from a sequence of images acquired by a robotic arm camera. This would then allow the return of a single completely in focus image constructed only from those portions of individual images that lie within the camera's depth of field. Output from these algorithms could be used to autonomously obtain rock spectra, determine which images should be transmitted to the ground, or to aid in image compression. We will discuss these algorithms and their performance during a recent rover field test.

Gulick, V. C.↗

NASA NTRS1999

Autonomous Science Analyses of Digital Images for Mars Sample Return and Beyond

To adequately explore high priority landing sites, scientists require rovers with greater mobility. Therefore, future Mars missions will involve rovers capable of traversing tens of kilometers (vs. tens of meters traversed by Mars Pathfinder's Sojourner). However, the current process by which scientists interact with a rover does not scale to such distances. A single science objective is achieved through many iterations of a basic command cycle: (1) all data must be transmitted to Earth and analyzed; (2) from this data, new targets are selected and the necessary information from the appropriate instruments are requested; (3) new commands are then uplinked and executed by the spacecraft and (4) the resulting data are returned to Earth, starting the process again. Experience with rover tests on Earth shows that this time intensive process cannot be substantially shortened given the limited data downlink bandwidth and command cycle opportunities of real missions. Sending complete multicolor panoramas at several waypoints, for example, is out of the question for a single downlink opportunity. As a result, long traverses requiring many science command cycles would likely require many weeks, months or even years, perhaps exceeding rover design life or other constraints. Autonomous onboard science analyses can address these problems in two ways. First, it will allow the rover to transmit only "interesting" images, defined as those likely to have higher science content. Second, the rover will be able to anticipate future commands, for example acquiring and returning spectra of "interesting" rocks along with the images in which they were detected. Such approaches, coupled with appropriate navigational software, address both the data volume and command cycle bottlenecks that limit both rover mobility and science yield. We are developing algorithms to enable such intelligent decision making by autonomous spacecraft. Reflecting the ultimate level of ability we aim for, this program has been dubbed the "Grad Student on Mars Project". We envision, for example, an appropriately intelligent Athena-like rover at the Pathfinder landing site might be able to traverse over the ridge towards "Twin Peaks" to obtain better information on the stratigraphy of these "streamlined islands" or of the size, composition and morphology of boulders located on them. Along the traverse, the intelligent rover would collect and analyze images and obtain spectra of geologically interesting features or regions. The intelligent rover might also traverse further up Arcs Vallis, and find additional paleoflood stage indicators such as slackwater deposits. Recognizing additional regions where boulders are imbricated, noting changes in their size, distribution, morphology, composition and the associated changes in channel geometry would yield important information on the outflow channel's paleoflood history, Representative images and associated supporting data from these locations could be downlinked to Earth along with the data requested by scientists from the previous uplink opportunity. Our initial work has focused on recognizing geologically interesting portions of images. Here we summarize some of the algorithms to date.

Gulick, V. C.↗

NASA NTRS2001

Apollo 10 - 11

This video gives overviews of the Apollo 10 and Apollo 11 missions to the moon, including footage from the launches and landings of the Command Module Columbia, which is used for both flights. The Apollo 10 crewmembers, Commander Thomas Stafford, Command Module Pilot John Young, and Lunar Module Pilot Eugene Cernan, are seen as they suit-up in preparation for launch and then as they experiment with the microgravity environment on their way to the moon. The moon's surface is seen in detail as the Command Module orbits at an altitude of 69 miles. The Apollo 11 crewmembers, Commander Neil Armstrong, Command Module Pilot Michael Collins, and Lunar Module Pilot Buzz Aldrin, are seen during various training activities, including simulated lunar gravity training, practicing collecting lunar material, and using the moonquake detector. Footage shows the approach and landing of the Lunar Module Eagle on the moon. Armstrong and Aldrin descend to the moon's surface, collect a sample of lunar dust, and erect the American flag. Eagle's liftoff from the moon is seen.

Source record↗

NASA NTRS2002

Autonomous Reconfigurable Control Allocation (ARCA) for Reusable Launch Vehicles

The role of control allocation (CA) in modern aerospace vehicles is to compute a command vector delta(sub c) is a member of IR(sup n(sub a)) that corresponding to commanded or desired body-frame torques (moments) tou(sub c) = [L M N](sup T) to the vehicle, compensating for and/or responding to inaccuracies in off-line nominal control allocation calculations, actuator failures and/or degradations (reduced effectiveness), or actuator limitations (rate/position saturation). The command vector delta(sub c) may govern the behavior of, e.g., acrosurfaces, reaction thrusters, engine gimbals and/or thrust vectoring. Typically, the individual moments generated in response to each of the n(sub a) commands does not lie strictly in the roll, pitch, or yaw axes, and so a common practice is to group or gang actuators so that a one-to-one mapping from torque commands tau(sub c) actuator commands delta(sub c) may be achieved in an off-line computed CA function.

Hodel, A. S.↗

NASA NTRS2006

Architecture for Control of the K9 Rover

Software featuring a multilevel architecture is used to control the hardware on the K9 Rover, which is a mobile robot used in research on robots for scientific exploration and autonomous operation in general. The software consists of five types of modules: Device Drivers - These modules, at the lowest level of the architecture, directly control motors, cameras, data buses, and other hardware devices. Resource Managers - Each of these modules controls several device drivers. Resource managers can be commanded by either a remote operator or the pilot or conditional-executive modules described below. Behaviors and Data Processors - These modules perform computations for such functions as planning paths, avoiding obstacles, visual tracking, and stereoscopy. These modules can be commanded only by the pilot. Pilot - The pilot receives a possibly complex command from the remote operator or the conditional executive, then decomposes the command into (1) more-specific commands to the resource managers and (2) requests for information from the behaviors and data processors. Conditional Executive - This highest-level module interprets a command plan sent by the remote operator, determines whether resources required for execution of the plan are available, monitors execution, and, if necessary, selects an alternate branch of the plan.

Bresina, John L.↗

NASA NTRS2010

Configurable Multi-Purpose Processor

Advancements in technology have allowed the miniaturization of systems used in aerospace vehicles. This technology is driven by the need for next-generation systems that provide reliable, responsive, and cost-effective range operations while providing increased capabilities such as simultaneous mission support, increased launch trajectories, improved launch, and landing opportunities, etc. Leveraging the newest technologies, the command and telemetry processor (CTP) concept provides for a compact, flexible, and integrated solution for flight command and telemetry systems and range systems. The CTP is a relatively small circuit board that serves as a processing platform for high dynamic, high vibration environments. The CTP can be reconfigured and reprogrammed, allowing it to be adapted for many different applications. The design is centered around a configurable field-programmable gate array (FPGA) device that contains numerous logic cells that can be used to implement traditional integrated circuits. The FPGA contains two PowerPC processors running the Vx-Works real-time operating system and are used to execute software programs specific to each application. The CTP was designed and developed specifically to provide telemetry functions; namely, the command processing, telemetry processing, and GPS metric tracking of a flight vehicle. However, it can be used as a general-purpose processor board to perform numerous functions implemented in either hardware or software using the FPGA s processors and/or logic cells. Functionally, the CTP was designed for range safety applications where it would ultimately become part of a vehicle s flight termination system. Consequently, the major functions of the CTP are to perform the forward link command processing, GPS metric tracking, return link telemetry data processing, error detection and correction, data encryption/ decryption, and initiate flight termination action commands. Also, the CTP had to be designed to survive and operate in a launch environment. Additionally, the CTP was designed to interface with the WFF (Wallops Flight Facility) custom-designed transceiver board which is used in the Low Cost TDRSS Transceiver (LCT2) also developed by WFF. The LCT2 s transceiver board demodulates commands received from the ground via the forward link and sends them to the CTP, where they are processed. The CTP inputs and processes data from the inertial measurement unit (IMU) and the GPS receiver board, generates status data, and then sends the data to the transceiver board where it is modulated and sent to the ground via the return link. Overall, the CTP has combined processing with the ability to interface to a GPS receiver, an IMU, and a pulse code modulation (PCM) communication link, while providing the capability to support common interfaces including Ethernet and serial interfaces boarding a relatively small-sized, lightweight package.

Valencia, J. Emilio↗

NASA NTRS2011

Enhanced Correlation of SMART Active Flap Rotor Loads

This is a follow-on study to a 2010 correlation effort. Measured data from the SMART rotor test in the NASA Ames 40- by 80- Foot Wind Tunnel are compared with CAMRAD II calculations. As background, during the wind tunnel test, unexpectedly high inboard loads were encountered, and it was hypothesized at that time that due to changes in the flexbeams over the years, the flexbeam properties used in the analysis needed updating. Boeing Mesa, recently updated these properties. This correlation study uses the updated flexbeam properties. Compared to earlier studies, the following two enhancements are implemented: i) the inboard loads (pitchcase and flexbeam loads) correlation is included for the first time (reliable prediction of the inboard loads is a prerequisite for any future anticipated flight-testing); ii) the number of blade modes is increased to better capture the flap dynamics and the pitchcase-flexbeam dynamics. Also, aerodynamically, both the rolled-up wake model and the more complex, multiple trailer wake model are used, with the latter slightly improving the blade chordwise moment correlation. This sensitivity to the wake model indicates that CFD is needed. Three high-speed experimental cases, one uncontrolled free flap case and two commanded flap cases, are considered. The two commanded flap cases include a 2o flap deflection at 5P case and a 0o flap deflection case. For the free flap case, selected modifications to the HH-06 section flap airfoil pitching moment table are implemented. For the commanded 2o flap case, the experimental flap variation is approximately matched by increasing the analytical flap hinge stiffness. This increased flap hinge stiffness is retained for the commanded 0o flap case also, which is treated as a free flap case, but with larger flap hinge stiffness. The change in the mid-span and outboard loads correlation due to the updating of the flexbeam properties is not significant. Increasing the number of blade modes results in an effective, commanded flap hinge stiffness of 4X baseline, not 3X as reported earlier. The inboard loads correlation is reasonable, but needs further study. Overall, the free flap case correlation is reasonable, thus confirming the basic correctness of the current semi-empirical modifications; the correlation for the commanded 2o flap at 5P case and the 0o flap case is also reasonable.

Kottapalli, Sesi↗

NASA NTRS2005

FastScript3D - A Companion to Java 3D

FastScript3D is a computer program, written in the Java 3D(TM) programming language, that establishes an alternative language that helps users who lack expertise in Java 3D to use Java 3D for constructing three-dimensional (3D)-appearing graphics. The FastScript3D language provides a set of simple, intuitive, one-line text-string commands for creating, controlling, and animating 3D models. The first word in a string is the name of a command; the rest of the string contains the data arguments for the command. The commands can also be used as an aid to learning Java 3D. Developers can extend the language by adding custom text-string commands. The commands can define new 3D objects or load representations of 3D objects from files in formats compatible with such other software systems as X3D. The text strings can be easily integrated into other languages. FastScript3D facilitates communication between scripting languages [which enable programming of hyper-text markup language (HTML) documents to interact with users] and Java 3D. The FastScript3D language can be extended and customized on both the scripting side and the Java 3D side.

Koenig, Patti↗

NASA NTRS2012

Automated Sequence Processor: Something Old, Something New

High productivity required for operations teams to meet schedules Risk must be minimized. Scripting used to automate processes. Scripts perform essential operations functions. Automated Sequence Processor (ASP) was a grass-roots task built to automate the command uplink process System engineering task for ASP revitalization organized. ASP is a set of approximately 200 scripts written in Perl, C Shell, AWK and other scripting languages.. ASP processes/checks/packages non-interactive commands automatically.. Non-interactive commands are guaranteed to be safe and have been checked by hardware or software simulators.. ASP checks that commands are non-interactive.. ASP processes the commands through a command. simulator and then packages them if there are no errors.. ASP must be active 24 hours/day, 7 days/week..

Automated↗

NASA NTRS2007

Improve Problem Solving Skills through Adapting Programming Tools

There are numerous ways for engineers and students to become better problem-solvers. The use of command line and visual programming tools can help to model a problem and formulate a solution through visualization. The analysis of problem attributes and constraints provide insight into the scope and complexity of the problem. The visualization aspect of the problem-solving approach tends to make students and engineers more systematic in their thought process and help them catch errors before proceeding too far in the wrong direction. The problem-solver identifies and defines important terms, variables, rules, and procedures required for solving a problem. Every step required to construct the problem solution can be defined in program commands that produce intermediate output. This paper advocates improved problem solving skills through using a programming tool. MatLab created by MathWorks, is an interactive numerical computing environment and programming language. It is a matrix-based system that easily lends itself to matrix manipulation, and plotting of functions and data. MatLab can be used as an interactive command line or a sequence of commands that can be saved in a file as a script or named functions. Prior programming experience is not required to use MatLab commands. The GNU Octave, part of the GNU project, a free computer program for performing numerical computations, is comparable to MatLab. MatLab visual and command programming are presented here.

Shaykhian, Linda H.↗

NASA NTRS2015

[Determine and Implement Updates to Be Made to MODEAR (Mission Operations Data Enterprise Architecture Repository)]

My main project was to determine and implement updates to be made to MODEAR (Mission Operations Data Enterprise Architecture Repository) process definitions to be used for CST-100 (Crew Space Transportation-100) related missions. Emphasis was placed on the scheduling aspect of the processes. In addition, I was to complete other tasks as given. Some of the additional tasks were: to create pass-through command look-up tables for the flight controllers, finish one of the MDT (Mission Operations Directorate Display Tool) displays, gather data on what is included in the CST-100 public data, develop a VBA (Visual Basic for Applications) script to create a csv (Comma-Separated Values) file with specific information from spreadsheets containing command data, create a command script for the November MCC-ASIL (Mission Control Center-Avionics System Integration Laboratory) testing, and take notes for one of the TCVB (Terminal Configured Vehicle B-737) meetings. In order to make progress in my main project I scheduled meetings with the appropriate subject matter experts, prepared material for the meetings, and assisted in the discussions in order to understand the process or processes at hand. After such discussions I made updates to various MODEAR processes and process graphics. These meetings have resulted in significant updates to the processes that were discussed. In addition, the discussions have helped the departments responsible for these processes better understand the work ahead and provided material to help document how their products are created. I completed my other tasks utilizing resources available to me and, when necessary, consulting with the subject matter experts. Outputs resulting from my other tasks were: two completed and one partially completed pass through command look-up tables for the fight controllers, significant updates to one of the MDT displays, a spreadsheet containing data on what is included in the CST-100 public data, a tool to create a csv file with specific information from spreadsheets containing command data, a command script for the November MCC-ASIL testing which resulted in a successful test day identifying several potential issues, and notes from one of the TCVB meetings that was used to keep the teams up to date on what was discussed and decided. I have learned a great deal working at NASA these last four months. I was able to meet and work with amazing individuals, further develop my technical knowledge, expand my knowledge base regarding human spaceflight, and contribute to the CST-100 missions. My work at NASA has strengthened my desire to continue my education in order to make further contributions to the field, and has given me the opportunity to see the advantages of a career at NASA.

Fanourakis, Sofia↗

NASA NTRS1972

Apollo 16 Press Kit

The Apollo 16 spacecraft is scheduled for launch on Apr. 16, 1972 from Complex 39A at the Kennedy Space Center, Florida by the Saturn V launch vehicle. Crewmen are mission commander John W. Young, command module pilot Thomas K. Mattingly II and lunar module pilot Charles M. Duke Jr. Objectives of the mission, to last up to 12 days, as outlined by NASA: to perform selenological inspection, survey and sampling of materials in a preselected region of Descartes using a lunar roving' vehicle; deploy and activate Apollo surface experiments; develop man's capability to work in the lunar environment; obtain photographs of candidate exploration sites; and toconduct inflight experiments and photographic tasks in lunar orbit. Following launch, the spacecraft will reach Earth Parking Orbit and remain in orbit for about two and one-half revolutions prior to Translunar Injection. Next, the Command and Service Module docks with the Lunar Module and the spacecraft "coasts" to the moon. In orbit around the moon, the Command and Service Module/Lunar Module combination will descend to within 50,000 feet of the lunar surface before undocking. The Lunar Module will continue to descend while the Command and Service Module returns to an orbit approximately 60 miles high. Stay time on the lunar surface is scheduled for approximately 73 hours. The ascent stage of the Lunar Module then lifts the astronauts back into lunar orbit where they will dock with the Command/Service Module. The Lunar Module is jettisoned and Transearth Injection follows. Just prior to reentry into the earth's atmosphere, the Service Module is jettisoned, and the astronauts in the Command Module splashdown in the Pacific Ocean. The target point for end-of-mission splashdown is at 05 degrees 0 minutes north latitude and 158 degrees 40 minutes west longitude or approximately 985 nautical miles south of Honolulu, Hawaii. Splashdown is scheduled for Apr. 28, 1972 at 10:30 a.m. Hawaiian Standard Time (2:30 p.m. CST). Recovery forces for Apollo 16, stationed in both the Atlantic and Pacific Oceans, will consist of three ships, nine aircraft and nearly 1,700 personnel. CTF-130 (Manned Spacecraft Recovery Force, Pacific) forces will be stationed south of Hawaii. Three ships, eight helicopters and three Air Force HC-130H aircraft, and nearly 1,100 personnel, will take part. Task Force 140 (Manned Spacecraft Recovery Force, Atlantic), comprising one ship, six HC-130H aircraft, three helicopters and approximately 300 personnel, will be positioned for possible launch abort operations. Two ships in the Atlantic will also be used for acoustical testing. Other forces, primarily aircraft and personnel of the Air Force Aerospace Rescue and Recovery Service will be on alert around the world for contingency recovery support.

Source record↗

NASA NTRS2016

Pattern Recognition Control Design

Spacecraft control algorithms must know the expected spacecraft response to any command to the available control effectors, such as reaction thrusters or torque devices. Spacecraft control system design approaches have traditionally relied on the estimated vehicle mass properties to determine the desired force and moment, as well as knowledge of the effector performance to efficiently control the spacecraft. A pattern recognition approach can be used to investigate the relationship between the control effector commands and the spacecraft responses. Instead of supplying the approximated vehicle properties and the effector performance characteristics, a database of information relating the effector commands and the desired vehicle response can be used for closed-loop control. A Monte Carlo simulation data set of the spacecraft dynamic response to effector commands can be analyzed to establish the influence a command has on the behavior of the spacecraft. A tool developed at NASA Johnson Space Center (Ref. 1) to analyze flight dynamics Monte Carlo data sets through pattern recognition methods can be used to perform this analysis. Once a comprehensive data set relating spacecraft responses with commands is established, it can be used in place of traditional control laws and gains set. This pattern recognition approach can be compared with traditional control algorithms to determine the potential benefits and uses.

Gambone, Elisabeth↗

NASA NTRS2018

Pattern Recognition Control Design

Spacecraft control algorithms must know the expected vehicle response to any command to the available control effectors, such as reaction thrusters or torque devices. Spacecraft control system design approaches have traditionally relied on the estimated vehicle mass properties to determine the desired force and moment, as well as knowledge of the effector performance to efficiently control the spacecraft. A pattern recognition approach was used to investigate the relationship between the control effector commands and spacecraft responses. Instead of supplying the approximated vehicle properties and the thruster performance characteristics, a database of information relating the thruster ring commands and the desired vehicle response was used for closed-loop control. A Monte Carlo simulation data set of the spacecraft dynamic response to effector commands was analyzed to establish the influence a command has on the behavior of the spacecraft. A tool developed at NASA Johnson Space Center to analyze flight dynamics Monte Carlo data sets through pattern recognition methods was used to perform this analysis. Once a comprehensive data set relating spacecraft responses with commands was established, it was used in place of traditional control methods and gains set. This pattern recognition approach was compared with traditional control algorithms to determine the potential benefits and uses.

Gambone, Elisabeth A.↗

NASA NTRS2022

Characterization of Response Times based on Voice Communication and Traffic Surveillance Data

A barrier to the integration of remotely piloted aircraft operations in the U.S. National Airspace System is the latency of voice communications between the air traffic controller and the remote pilot, and the latency of communication between the aircraft and the remote pilot. The latency can be substantial especially when satellite-based beyond-radio-line-of-sight communication and relay through the aircraft are employed. This study uses voice recordings of controller-pilot communications and aircraft track data to establish a baseline of pilot readback latencies and maneuver detection delays in the current piloted operations. A machine learning pipeline was developed to parse the contents of the air traffic control clearances including the callsigns using natural language processing. After manually validating the results obtained using the pipeline, the average pilot readback latency was found to be about 0.6 seconds. The average latency between the end of maneuver (inferred from track data), initiated by the pilot in response to the clearance, and the end of clearance was found to be about 176 seconds for altitude change commands, 69 seconds for heading change commands, and 182 seconds for speed change commands. The average latency between the beginning of maneuver and the end of clearance was found to be about 17 seconds for altitude change commands, 17seconds for heading change commands, and 25 seconds for speed change commands.

controller-pilot communication, communication late↗

NASA NTRS2022

Characterization of Response Times Based on Voice Communication and Traffic Surveillance Data

controller-pilot communication↗

NASA NTRS2011

Project Report: Automatic Sequence Processor Software Analysis

The Mission Planning and Sequencing (MPS) element of Multi-Mission Ground System and Services (MGSS) provides space missions with multi-purpose software to plan spacecraft activities, sequence spacecraft commands, and then integrate these products and execute them on spacecraft. Jet Propulsion Laboratory (JPL) is currently is flying many missions. The processes for building, integrating, and testing the multi-mission uplink software need to be improved to meet the needs of the missions and the operations teams that command the spacecraft. The Multi-Mission Sequencing Team is responsible for collecting and processing the observations, experiments and engineering activities that are to be performed on a selected spacecraft. The collection of these activities is called a sequence and ultimately a sequence becomes a sequence of spacecraft commands. The operations teams check the sequence to make sure that no constraints are violated. The workflow process involves sending a program start command, which activates the Automatic Sequence Processor (ASP). The ASP is currently a file-based system that is comprised of scripts written in perl, c-shell and awk. Once this start process is complete, the system checks for errors and aborts if there are any; otherwise the system converts the commands to binary, and then sends the resultant information to be radiated to the spacecraft.

sequencing↗