Search NASA⌕ Search

SEARCH · Search NASA

Results for “Flight Software Cassini”

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 37 records · Page 2
All sourcesNASA NTRSDOE OSTI
NASA NTRS2008

Cassini Attitude Control Operations Flight Rules and How They are Enforced

The Cassini spacecraft was launched on October 15, 1997 and arrived at Saturn on June 30, 2004. It has performed detailed observations and remote sensing of Saturn, its rings, and its satellites since that time. Cassini deployed the European-built Huygens probe which descended through the Titan atmosphere and landed on its surface on January 14, 2005. Operating the Cassini spacecraft is a complex scientific, engineering, and management job. In order to safely operate the spacecraft, a large number of flight rules were developed. These flight rules must be enforced throughout the lifetime of the Cassini spacecraft. Flight rules are defined as any operational limitation imposed by the spacecraft system design, hardware, and software, violation of which would result in spacecraft damage, loss of consumables, loss of mission objectives, loss and/or degradation of science, and less than optimal performance. Flight rules require clear description and rationale. Detailed automated methods have been developed to insure the spacecraft is continuously operated within these flight rules. An overview of all the flight rules allocated to the Cassini Attitude Control and Articulation Subsystem and how they are enforced is presented in this paper.

Burk, Thomas↗
NASA NTRS2013

Reducing Pointing Errors During Cassini Reaction Control System Orbit Trim Maneuvers

The effect of altering a gain parameter in the Cassini reaction control system (RCS) delta-V controller on the maneuver execution errors during orbit trim maneuvers (OTMs) is explored. Cassini consists of two reaction control thruster branches (A & B) each with eight thrusters. Currently, the B-branch is operational while the A-branch serves as a back-up. The four Z-thrusters control the X and Y-axes, while the four Y-thrusters control the Z-axis. During an OTM, the Z-thrusters fire to maintain the X and Y-axes pointing within an attitude control dead-zone (-10 to 10 milliradians). The errors do not remain at zero due to pointing error sources such as spacecraft center of mass offset from the geometric center of the Z-facing thrusters, and variability in the thruster forces due to the thruster hardware differences. The delta-V reaction control system (RCS) controller ensures that the attitude error remains within this dead-zone. Gain parameters within the RCS delta-V controller affect the maneuver execution errors. Different parameter values are used to explore effect on these errors. It is found that pointing error decreases and magnitude error increases rapidly for gain parameters 10 times greater than the current parameter values used in the flight software.

European Space Agency (ESA)↗
NASA NTRS2006

The Cassini-Huygens Sequence Development Process

Each phase of the sequence development process had to overcome many operational challenges due to the immense complexity of the spacecraft, tour design, pointing capabilities, flight rules and software development. This paper will address the specific challenges related to each of those complexities and the methods used to overcome them during operation.

science planning↗
NASA NTRS1994

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.↗
NASA NTRS2016

Enhancing the Cassini Mission Through FP Applications After Launch

Although rigorous pre-emptive measures are taken to preclude failures and anomalous conditions from occurring in JPL spacecraft missions prior to launch, unforeseeable problems can still surface after liftoff. In the case of the Cassini/Huygens Mission-to-Saturn spacecraft, several problems were observed post-launch: 1) immediately after takeoff, the collected engineering/science data stored on the Solid State Recorders (SSR) contained a significantly higher number of corrupted bits than was expected (considerably over spec) due to human error in the memory mapping of these devices, 2) numerous Solid State Power Switches (SSPS) sporadically tripped off throughout the mission due to cosmic ray bombardment from the unique space environment, and 3) false assumptions in the pressure regulator design in combination with missing heritage test data led to inaccurate design conclusions, causing the issuance of two waivers for the regulator to close properly (a potentially mission catastrophic single-point failure which occurred 24 days after launch) - amongst other problems. For Cassini, some of these anomalies led to arduous work-arounds or required continuous monitoring of telemetry variables by the ground-based Spacecraft Operations Flight Support (SOFS) team in order to detect and fix fault occurrences as they happened. Fortunately, sufficient funding and schedule margin allowed several Fault Protection (FP) solutions to be implemented into post-launch Flight Software (FSW) uploads to help resolve these issues autonomously, reducing SOFS ground support efforts while improving anomaly recovery time in order to preserve maximum science capture. This paper details the FP applications used to resolve the above issues as well as to optimize solutions for several other problems experienced by the Cassini spacecraft during its fight, in order to enhance the spacecraft's overall mission success throughout the 18 years of its 20 year expedition to and within the Saturnian system.

fault protection↗
NASA NTRS1994

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

The Operations Engineering Lab (OEL) at JPL has developed the multimission command system as part of JPL's Advanced Multimission Operations System. The command system provides an advanced multimission environment for secure, concurrent commanding of multiple spacecraft. The command functions include real-time command generation, command translation and radiation, status reporting, some remote control of Deep Space Network antenna functions, and command file management. The mission-independent architecture has allowed easy adaptation to new flight projects and the system currently supports all JPL planetary missions (Voyager, Galileo, Magellan, Ulysses, Mars Pathfinder, and CASSINI). This paper will discuss the design and implementation of the command software, especially trade-offs and lessons learned from practical operational use. The lessons learned have resulted in a re-engineering of the command system, especially in its user interface and new automation capabilities. The redesign has allowed streamlining of command operations with significant improvements in productivity and ease of use. In addition, the new system has provided a command capability that works equally well for real-time operations and within a spacecraft testbed. 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.

Alexander, Scott↗
NASA NTRS2008

Cassini Information Management System in Distributed Operations Collaboration and Cassini Science Planning

Launched on October 15, 1997, the Cassini-Huygens spacecraft began its ambitious journey to the Saturnian system with a complex suite of 12 scientific instruments, and another 6 instruments aboard the European Space Agencies Huygens Probe. Over the next 6 1/2 years, Cassini would continue its relatively simplistic cruise phase operations, flying past Venus, Earth, and Jupiter. However, following Saturn Orbit Insertion (SOI), Cassini would become involved in a complex series of tasks that required detailed resource management, distributed operations collaboration, and a data base for capturing science objectives. Collectively, these needs were met through a web-based software tool designed to help with the Cassini uplink process and ultimately used to generate more robust sequences for spacecraft operations. In 2001, in conjunction with the Southwest Research Institute (SwRI) and later Venustar Software and Engineering Inc., the Cassini Information Management System (CIMS) was released which enabled the Cassini spacecraft and science planning teams to perform complex information management and team collaboration between scientists and engineers in 17 countries. Originally tailored to help manage the science planning uplink process, CIMS has been actively evolving since its inception to meet the changing and growing needs of the Cassini uplink team and effectively reduce mission risk through a series of resource management validation algorithms. These algorithms have been implemented in the web-based software tool to identify potential sequence conflicts early in the science planning process. CIMS mitigates these sequence conflicts through identification of timing incongruities, pointing inconsistencies, flight rule violations, data volume issues, and by assisting in Deep Space Network (DSN) coverage analysis. In preparation for extended mission operations, CIMS has also evolved further to assist in the planning and coordination of the dual playback redundancy of highvalue data from targets such as Titan and Enceladus. This paper will outline the critical role that CIMS has played for Cassini in the distributed ops paradigm throughout operations. This paper will also examine the evolution that CIMS has undergone in the face of new science discoveries and fluctuating operational needs. And finally, this paper will conclude with theoretical adaptation of CIMS for other projects and the potential savings in cost and risk reduction that could potentially be tapped into by future missions.

Equils, Douglas J.↗
NASA NTRS2010

A Flight-Calibrated Methodology for Determination of Cassini Thruster On-Times for Reaction Wheel Biases

This paper describes a methodology for accurate and flight-calibrated determination of the on-times of the Cassini spacecraft Reaction Control System (RCS) thrusters, without any form of dynamic simulation, for the reaction wheel biases. The hydrazine usage and the delta V vector in body frame are also computed from the respective thruster on-times. The Cassini spacecraft, the largest and most complex interplanetary spacecraft ever built, continues to undertake ambitious and unique scientific observations of planet Saturn, Titan, Enceladus, and other moons of Saturn. In order to maintain a stable attitude during the course of its mission, this three-axis stabilized spacecraft uses two different control systems: the RCS and the reaction wheel assembly control system. The RCS is used to execute a commanded spacecraft slew, to maintain three-axis attitude control, control spacecraft's attitude while performing science observations with coarse pointing requirements, e.g. during targeted low-altitude Titan and Enceladus flybys, bias the momentum of reaction wheels, and to perform RCS-based orbit trim maneuvers. The use of RCS often imparts undesired delta V on the spacecraft. The Cassini navigation team requires accurate predictions of the delta V in spacecraft coordinates and inertial frame resulting from slews using RCS thrusters and more importantly from reaction wheel bias events. It is crucial for the Cassini spacecraft attitude control and navigation teams to be able to, quickly but accurately, predict the hydrazine usage and delta V for various reaction wheel bias events without actually having to spend time and resources simulating the event in flight software-based dynamic simulation or hardware-in-the-loop simulation environments. The methodology described in this paper, and the ground software developed thereof, are designed to provide just that. This methodology assumes a priori knowledge of thrust magnitudes and thruster pulse rise and tail-off time constants for eight individual attitude control thrusters, the spacecraft's wet mass and its center of mass location, and a few other key parameters.

Earth Mean Equatorial↗
NASA NTRS2002

The Cassini/Huygens Mission to Saturn and Titan

The Cassini/Huygens mission is a joint endeavor between NASA, the EuropeanSpace Agency, and the Italian Space Agency to send a spacecraft to perform an extensive exploration of the Saturnian system, including an atmospheric probe to go to the surface of Titan. The spacecraft was launched on October 15, 1997, and now has completed five years of its nearly seven year journey to Saturn. The cruise period has been a relatively passive time for the spacecraft, but an intensely busy one for the flight team. There is now less than two years to go until arrival at Saturn, and a significant portion of the effort deliberately planned for the post-launch period remains to be completed. Ground activities include the development of flight software, ground software, and science observation plans in order to be prepared to operate the mission after arrival at Saturn. This paper provides an update to the mission status and progress over the past year.

Cassini Huygens Saturn Titan↗
NASA NTRS1999

A Flight/Ground/Test Event Logging Facility

The onboard control software for spacecraft such as Mars Pathfinder and Cassini is composed of many subsystems including executive control, navigation, attitude control, imaging, data management, and telecommunications. The software in all of these subsystems needs to be instrumented for several purposes: to report required telemetry data, to report warning and error events, to verify internal behavior during system testing, and to provide ground operators with detailed data when investigating in-flight anomalies. Events can range in importance from purely informational events to major errors. It is desirable to provide a uniform mechanism for reporting such events and controlling their subsequent processing. Since radiation-hardened flight processors are several years behind the speed and memory of their commercial cousins, and since most subsystems require real-time control, and since downlink rates to earth can be very low from deep space, there are limits to how much of the data can be saved and transmitted. Some kinds of events are more important than others and should therefore be preferentially retained when memory is low. Some faults can cause an event to recur at a high rate, but this must not be allowed to consume the memory pool. Some event occurrences may be of low importance when reported but suddenly become more important when a subsequent error event gets reported. Some events may be so low-level that they need not be saved and reported unless specifically requested by ground operators.

Dvorak, Daniel↗
NASA NTRS2000

The Cassini/Huyegens Mission to Saturn and Titan

This paper summarizes the principal accomplishments of the Cassini/Huygens mission over the past year, which include a complete reload of the flight software on the spacecraft, including that of most of the orbiter science instruments, the final definition of the exact orbital tour to be flown at Saturn, and considerable progress in designing the sequence of science observations to be made in the tour.

Cassini Huygens Saturn Titan↗
NASA NTRS2010

A Flight-Calibrated Methodology for Determination of Cassini Thruster On-Times for Reaction Wheel Biases

The Cassini spacecraft, the largest and most complex interplanetary spacecraft ever built, continues to undertake unique scientific observations of planet Saturn, Titan, Enceladus, and other moons of the ring world. In order to maintain a stable attitude during the course of its mission, this three-axis stabilized spacecraft uses two different control systems: the Reaction Control System (or RCS) and the Reaction Wheel Assembly (RWA) control system. In the course of its mission, Cassini performs numerous reaction wheel momentum biases (or unloads) using its reaction control thrusters. The use of the RCS thrusters often imparts undesired velocity changes (delta Vs) on the spacecraft and it is crucial for Cassini navigation and attitude control teams to be able to, quickly but accurately, predict the hydrazine usage and delta V vector in Earth Mean Equatorial (J2000) inertial coordinates for reaction wheel bias events, without actually having to spend time and resources simulating the event in a dynamic or hardware-in-the-loop simulation environments. The flight-calibrated methodology described in this paper, and the ground software developed thereof, are designed to provide the RCS thruster on-times, with acceptable accuracy and without any form of dynamic simulation, for reaction wheel biases, along with the hydrazine usage and the delta V in EME-2000 inertial frame.

Reaction Control System↗
NASA NTRS2003

The Cassini/Huygens mission to Saturn

This paper provides an overview of the mission but focuses primarily on the activities over the past year in preparation for Saturn arrival and beginning the scientific observations to be made in orbit. Details are provided on the completion, validation, and uplink of new on-board flight software, development and testing of the sequences to be used for orbit insertion and relay of the data stream from the Huygens probe as it descends through the atmosphere of Titan, and design and preparation of the science sequences to be performed by the orbiter.

Huygens↗
NASA NTRS2004

Science Opportunity Analyzer (SOA): Science Planning Made Simple

.For the first time at JPL, the Cassini mission to Saturn is using distributed science operations for developing their experiments. Remote scientists needed the ability to: a) Identify observation opportunities; b) Create accurate, detailed designs for their observations; c) Verify that their designs meet their objectives; d) Check their observations against project flight rules and constraints; e) Communicate their observations to other scientists. Many existing tools provide one or more of these functions, but Science Opportunity Analyzer (SOA) has been built to unify these tasks into a single application. Accurate: Utilizes JPL Navigation and Ancillary Information Facility (NAIF) SPICE* software tool kit - Provides high fidelity modeling. - Facilitates rapid adaptation to other flight projects. Portable: Available in Unix, Windows and Linux. Adaptable: Designed to be a multi-mission tool so it can be readily adapted to other flight projects. Implemented in Java, Java 3D and other innovative technologies. Conclusion: SOA is easy to use. It only requires 6 simple steps. SOA's ability to show the same accurate information in multiple ways (multiple visualization formats, data plots, listings and file output) is essential to meet the needs of a diverse, distributed science operations environment.

observation planning operations↗
NASA NTRS2002

Science opportunity analyzer - a multi-mission tool for planning

For many years the diverse scientific community that supports JPL's wide variety ofinterplanetary space missions has needed a tool in order to plan and develop their experiments. The tool needs to be easily adapted to various mission types and portable to the user community. The Science Opportunity Analyzer, SOA, now in its third year of development, is intended to meet this need. SOA is a java-based application that is designed to enable scientists to identify and analyze opportunities for science observations from spacecraft. It differs from other planning tools in that it does not require an in-depth knowledge of the spacecraft command system or operation modes to begin high level planning. Users can, however, develop increasingly detailed levels of design. SOA consists of six major functions: Opportunity Search, Visualization, Observation Design, Constraint Checking, Data Output and Communications. Opportunity Search is a GUI driven interface to existing search engines that can be used to identify times when a spacecraft is in a specific geometrical relationship with other bodies in the solar system. This function can be used for advanced mission planning as well as for making last minute adjustments to mission sequences in response to trajectory modifications. Visualization is a key aspect of SOA. The user can view observation opportunities in either a 3D representation or as a 2D map projection. The user is given extensive flexibility to customize what is displayed in the view. Observation Design allows the user to orient the spacecraft and visualize the projection of the instrument field of view for that orientation using the same views as Opportunity Search. Constraint Checking is provided to validate various geometrical and physical aspects of an observation design. The user has the ability to easily create custom rules or to use official project-generated flight rules. This capability may also allow scientists to easily impact the cost to science if flight rule changes occur. Data Output generates information based on the spacecraft's trajectory, opportunity search results or based on a created observation. The data can be viewed either in tabular format or as a graph. Finally, SOA is unique in that it is designed to be able to communicate with a variety of existing planning and sequencing tools. From the very beginning SOA was designed with the user in mind. Extensive surveys of the potential user community were conducted in order to develop the software requirements. Throughout the development period, close ties have been maintained with the science community to insure that the tool maintains its user focus. Although development is still in its early stages, SOA is already developing a user community on the Cassini project, which is depending on this tool for their science planning. There are other tools at JPL that do various pieces of what SOA can do; however, there is no other tool which combines all these functions and presents them to the user in such a convenient, cohesive, and easy to use fashion.

SOA science planning mission operations sequence s↗