SEARCH · Engineering Papers

Results for “sequencing commanding operations”

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 127 records · Page 7

All sources NASA NTRS DOE OSTI

NASA NTRS1993

Toward an Autonomous Feature-based Pointing System for Planetary Missions

Although the analytical groundwork for understanding two-dimensional object images and various aspects of computer vision has been laid, we have not yet applied these concepts to automating the process of obtaining science images during space exploration missions. Our current approach in specifying pointing-command sequences relies heavily on target predicts, based on predicted target and spacecraft ephemerides, that propagate the target position as a function of time during pointing operations.

Computer↗

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 NTRS2014

Testing Mars Exploration Rover-Inspired Operational Strategies for Semi-Autonomous Rovers on the Moon Ii: the GeoHeuristic Operational Strategies Test in Alaska

We used MER-derived semi-autonomous rover science operations strategies to determine best practices suitable for remote semi-autonomous lunar rover geology. Two field teams studied two glacial moraines as analogs for potential ice-bearing lunar regolith. At each site a Rover Team commanded a human rover to execute observations based on common MER sequences; the resulting data were used to identify and characterize targets of interest. A Tiger Team followed the Rover Team using traditional terrestrial field methods, and the results of the two teams were compared. Narrowly defined goals that can be addressed using cm-scale or coarser resolution may be met sufficiently by the operational strategies adapted from MER survey mode. When reconnaissance is the primary goal, the strategies tested are necessary but not sufficient. Further, there may be a set of optimal observations for such narrowly defined, hypothesis-driven science goals, such that collecting further data would result in diminishing returns. We confirm results of previous tests that indicated systematic observations might improve efficiency during strategic planning, and improve science output during data analysis. This strategy does not markedly improve the rate at which a science team can ingest data to feed back into tactical decision-making. Other methods should be tested to separate the strategic and tactical processes, and to build in time for data analysis.

MER↗

NASA NTRS1994

A software architecture for automating operations processes

The Operations Engineering Lab (OEL) at JPL has developed a software architecture based on an integrated toolkit approach for simplifying and automating mission operations tasks. The toolkit approach is based on building adaptable, reusable graphical tools that are integrated through a combination of libraries, scripts, and system-level user interface shells. The graphical interface shells are designed to integrate and visually guide a user through the complex steps in an operations process. They provide a user with an integrated system-level picture of an overall process, defining the required inputs and possible output through interactive on-screen graphics. The OEL has developed the software for building these process-oriented graphical user interface (GUI) shells. The OEL Shell development system (OEL Shell) is an extension of JPL's Widget Creation Library (WCL). The OEL Shell system can be used to easily build user interfaces for running complex processes, applications with extensive command-line interfaces, and tool-integration tasks. The interface shells display a logical process flow using arrows and box graphics. They also allow a user to select which output products are desired and which input sources are needed, eliminating the need to know which program and its associated command-line parameters must be executed in each case. The shells have also proved valuable for use as operations training tools because of the OEL Shell hypertext help environment. The OEL toolkit approach is guided by several principles, including the use of ASCII text file interfaces with a multimission format, Perl scripts for mission-specific adaptation code, and programs that include a simple command-line interface for batch mode processing. Projects can adapt the interface shells by simple changes to the resources configuration file. This approach has allowed the development of sophisticated, automated software systems that are easy, cheap, and fast to build. This paper will discuss our toolkit approach and the OEL Shell interface builder in the context of a real operations process example. The paper will discuss the design and implementation of a Ulysses toolkit for generating the mission sequence of events. The Sequence of Events Generation (SEG) system provides an adaptable multimission toolkit for producing a time-ordered listing and timeline display of spacecraft commands, state changes, and required ground activities.

Miller, Kevin J.↗

NASA NTRS1994

Low Cost Uplink Concepts

In order to minimize the cost of developing sequences of commands for small, low cost missions, a cost effective set of uplink tools used in conjunction with an appropriate ground system architecture (including a multi-mission operations facility) must be utilized.

ground system architecture generic uplink process ↗

NASA NTRS2005

Mars Exploration Rover Entry, Descent, and Landing: A Thermal Perspective

Perhaps the most challenging mission phase for the Mars Exploration Rovers was the Entry, Descent, and Landing (EDL). During this phase, the entry vehicle attached to its cruise stage was transformed into a stowed tetrahedral Lander that was surrounded by inflated airbags through a series of complex events. There was only one opportunity to successfully execute an automated command sequence without any possible ground intervention. The success of EDL was reliant upon the system thermal design: 1) to thermally condition EDL hardware from cruise storage temperatures to operating temperature ranges; 2) to maintain the Rover electronics within operating temperature ranges without the benefit of the cruise single phase cooling loop, which had been evacuated in preparation for EDL; and 3) to maintain the cruise stage propulsion components for the critical turn to entry attitude. Since the EDL architecture was inherited from Mars Pathfinder (MPF), the initial EDL thermal design would be inherited from MPF. However, hardware and implementation differences from MPF ultimately changed the MPF inheritance approach for the EDL thermal design. With the lack of full inheritance, the verification and validation of the EDL thermal design took on increased significance. This paper will summarize the verification and validation approach for the EDL thermal design along with applicable system level thermal testing results as well as appropriate thermal analyses. In addition, the lessons learned during the system-level testing will be discussed. Finally, the in-flight EDL experiences of both MER-A and -B missions (Spirit and Opportunity, respectively) will be presented, demonstrated how lessons learned from Spirit were applied to Opportunity.

thermal↗

NASA NTRS2004

End-to-End Commitment

The end-to-end test would verify the complex sequence of events from lander separation to landing. Due to the large distances involved and the significant delay time in sending a command and receiving verification, the lander needed to operate autonomously after it separated from the orbiter. It had to sense conditions, make decisions, and act accordingly. We were flying into a relatively unknown set of conditions-a Martian atmosphere of unknown pressure, density, and consistency to land on a surface of unknown altitude, and one which had an unknown bearing strength.

Newcomb, John↗

NASA NTRS2012

Modular, Autonomous Command and Data Handling Software with Built-In Simulation and Test

The spacecraft system that plays the greatest role throughout the program lifecycle is the Command and Data Handling System (C&DH), along with the associated algorithms and software. The C&DH takes on this role as cost driver because it is the brains of the spacecraft and is the element of the system that is primarily responsible for the integration and interoperability of all spacecraft subsystems. During design and development, many activities associated with mission design, system engineering, and subsystem development result in products that are directly supported by the C&DH, such as interfaces, algorithms, flight software (FSW), and parameter sets. A modular system architecture has been developed that provides a means for rapid spacecraft assembly, test, and integration. This modular C&DH software architecture, which can be targeted and adapted to a wide variety of spacecraft architectures, payloads, and mission requirements, eliminates the current practice of rewriting the spacecraft software and test environment for every mission. This software allows missionspecific software and algorithms to be rapidly integrated and tested, significantly decreasing time involved in the software development cycle. Additionally, the FSW includes an Onboard Dynamic Simulation System (ODySSy) that allows the C&DH software to support rapid integration and test. With this solution, the C&DH software capabilities will encompass all phases of the spacecraft lifecycle. ODySSy is an on-board simulation capability built directly into the FSW that provides dynamic built-in test capabilities as soon as the FSW image is loaded onto the processor. It includes a six-degrees- of-freedom, high-fidelity simulation that allows complete closed-loop and hardware-in-the-loop testing of a spacecraft in a ground processing environment without any additional external stimuli. ODySSy can intercept and modify sensor inputs using mathematical sensor models, and can intercept and respond to actuator commands. ODySSy integration is unique in that it allows testing of actual mission sequences on the flight vehicle while the spacecraft is in various stages of assembly, test, and launch operations all without any external support equipment or simulators. The ODySSy component of the FSW significantly decreases the time required for integration and test by providing an automated, standardized, and modular approach to integrated avionics and component interface and functional verification. ODySSy further provides the capability for on-orbit support in the form of autonomous mission planning and fault protection.

Cuseo, John↗

NASA NTRS1975

Digital computer control of a 30-cm mercury ion thruster

The major objective was to define the exact role of an onboard spacecraft computer in the control of ion thrusters. An initial computer control system with accurate high speed capability was designed, programmed, and tested with the computer as the sole control element for an operating ion thruster. The command functions and a code format for a spacecraft digital control system were established. A second computer control system was constructed to operate with these functions and format. A throttle program sequence was established and tested. A two thruster array was tested with these computer control systems and the results reported.

Low, C. A., Jr.↗

NASA NTRS1975

Digital computer control of a 30 cm mercury ion thruster

The major objective of this program was to define the exact role of an on-board spacecraft computer in the control of ion thrusters. An initial computer control system with accurate high speed capability was designed, programmed, and tested with the computer as the sole control element for an operating ion thruster. The command functions and a code format for a spacecraft digital control system were established. A second computer control system was constructed to operate with these functions and format. A throttle program sequence was established and tested. A two thruster array was tested with these computer control systems and the results reported.

Low, C. A., Jr.↗

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 NTRS2011

Updates on HRF Payloads Operations in Columbus ATCS

The NASA developed Human Research Facility 1 (HRF1) and Human Research Facility (HRF2) experiment racks have been operating in the European Space Agency (ESA) Columbus module of the International Space Station (ISS) since Summer 2008. The two racks are of the same design. Since the start of operations, unexpected pressure spikes were observed in the Columbus module's thermal-hydraulic system during the racks activation sequence. The root cause of these spikes was identified in the activation command sequence in the Rack Interface Controller (RIC), which controls the flow of thermal-hydraulic system fluid through the rack. A new Common RIC Software (CRS) release fixed the bug and was uploaded on both racks in late 2009. This paper gives a short introduction to the topic, describes the Columbus module countermeasures to mitigate the spikes, describes the ground validation test of the new software, and describes the flight checks performed before and after the final upload. Finally, the new on-orbit test designed to further simplify the racks hydraulic management is presented.

DePalo, Savino↗

NASA NTRS2009

Testing Flight Systems with Machine Executable Scripts

The MSAP project at JPL has been testing spacecraft avionics and flight software since 2005, in part using computer executable scripts. The scripts are document files of a common word processor and comply with the format of a traditional, formal test procedure common at JPL. These procedures use keywords to issue commands and evaluate responses, mimicking a human test operator. In effect, script lines are inserted into a normal procedure. Even though the executable structure of the procedures is limited to linear sequences of fairly simple operations, we have found significant value in certain test regimes given the repeatability, ease of execution, and readily understandable intent of these procedures.

Gibbs, Don↗

NASA NTRS1993

The Mars Observer Camera ground data system

The Mars Observer Camera (MOC), launched on board the Mars Observer spacecraft in September 1992, is to be operated by a small team using large amounts of computer assistance. Here, we describe the architecture of the MOC Ground Data System, which is capable of taking imaging requests, generating imaging command sequences, receiving the acquired images, archiving them, and delivering them in several processed forms to the MOC user community, all with the need for only a limited amount of human interaction.

Caplinger, Michael↗

NASA NTRS2007

Challenges of the Cassini Test Bed Simulating the Saturnian Environment

The Cassini-Huygens mission is a joint NASA and European Space Agency (ESA) mission to collect scientific data of the Saturnian system and is managed by the Jet Propulsion Laboratory (JPL). After having arrived in Saturn orbit and releasing the ESA's Huygens probe for a highly successful descent and landing mission on Saturn's moon Titan, the Cassini orbiter continues on its tour of Saturn, its satellites, and the Saturnian environment. JPL's Cassini Integrated Test laboratory (ITL) is a dedicated high fidelity test bed that verifies and validates command sequences and flight software before upload to the Cassini spacecraft. The ITL provides artificial stimuli that allow a highly accurate hardware-in-the-loop test bed model that tests the operation of the Cassini spacecraft on the ground. This enables accurate prediction and recreation of mission events and flight software and hardware behavior. As we discovered more about the Saturnian environment, a combination of creative test methods and simulation changes were necessary to simulate the harmful effect that the optical and physical environment has on the pointing performance of Cassini. This paper presents the challenges experienced and overcome in that endeavor to simulate and test the post Saturn Orbit Insertion (SOI) and Probe Relay tour phase of the Cassini mission.

Titan atmospheric drag↗

NASA NTRS2007

Mission Operations of the Mars Exploration Rovers

A document describes a system of processes involved in planning, commanding, and monitoring operations of the rovers Spirit and Opportunity of the Mars Exploration Rover mission. The system is designed to minimize command turnaround time, given that inherent uncertainties in terrain conditions and in successful completion of planned landed spacecraft motions preclude planning of some spacecraft activities until the results of prior activities are known by the ground-based operations team. The processes are partitioned into those (designated as tactical) that must be tied to the Martian clock and those (designated strategic) that can, without loss, be completed in a more leisurely fashion. The tactical processes include assessment of downlinked data, refinement and validation of activity plans, sequencing of commands, and integration and validation of sequences. Strategic processes include communications planning and generation of long-term activity plans. The primary benefit of this partition is to enable the tactical portion of the team to focus solely on tasks that contribute directly to meeting the deadlines for commanding the rover s each sol (1 sol = 1 Martian day) - achieving a turnaround time of 18 hours or less, while facilitating strategic team interactions with other organizations that do not work on a Mars time schedule.

Bass, Deborah↗

NASA NTRS1981

Solid rocket booster thrust vector control V-2 off-nominal testing

The results of the V-2 off nominal test sequence performed on the space shuttle solid rocket booster thrust vector control (SRB TVC) system are reported. The TVC subsystem was subjected to 19 off nominal test conditions. The test sequence consisted of: 8 burp starts, 30 hot firings, 14 GN2 spin tests, and 3 servicing passive system tests. It is concluded that the TVC subsystem operated nominally in response to the given commands and test conditions. Test objectives, detail results, and data are included.

Pagan, B.↗

NASA NTRS2000

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↗