SEARCH · Search NASA
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.
The arduous task of tracking multiple flight software images, across redundant on-board processors, recorders and across time, has been automated and systematized via the use of a unified Flight Software Memory Tracker (FMT) Tool.
The Cassini AACS object-oriented Flight Software is depicted in increasing levels of detail using a Context Diagram, Architecture Diagrams, an Object Diagram for each object, and a Statechart for each object. The detail contained in the diagrams is enhanced and refined during the Requirements and Design Phases of both Subsystem and Software Development. Examples of all the diagrams as well as the criteria for object selection, the advantages of statecharts, and the ease of modifying the design to accommodate changes in scope are described.
The Cassini Attitude and Articulation Control Subsystem (AACS) is responsible for determining and controlling the spacecraft attitude including instrument pointing, antenna pointing, and thrust vector pointing during velocity change maneuvers. The 12 year mission life, long round-trip light time, and extended periods of coast without continuous ground control drive the AACS flight software design in the directions of autonomy, fault tolerance, and modularity to accommodate planned upgrades in flight. The Cassini AACS Flight Software is depicted in increasing levels of detail using a Context Diagram, Architecture Diagrams (i.e., Dependency Diagrams), an Object Diagram for each object, and a Statechart (i.e., State Transition Diagram) for each object. The detail contained in the diagrams is enhanced and refined during the Requirements and Design Phases of both Subsystem and Software Development. Examples of all the diagrams as well as the criteria for object selection, the advantages of statecharts, and the ease of modifying the design to accommodate changes in scope are described.
The Cassini Attitude and Articulation Control Subsystem (AACS) Flight Software (FSW) has achieved its intended design goals by successfully guiding and controlling the Cassini-Huygens planetary mission to Saturn and its moons. This paper describes an overview of AACS FSW details from early design, development, implementation, and test to its fruition of operating and maintaining spacecraft control over an eleven year prime mission. Starting from phases of FSW development, topics expand to FSW development methodology, achievements utilizing in-flight autonomy, and summarize lessons learned during flight operations which can be useful to FSW in current and future spacecraft missions.
As the first spacecraft to achieve orbit at Saturn in 2004, Cassini has collected science data throughout its four-year prime mission (2004-08), and has since been approved for a first and second extended missions through September 2017. Cassini is a three-axis stabilized spacecraft. It uses reaction wheels to achieve high level of spacecraft pointing stability that is needed during imaging operations of several science instruments. The Cassini flight software makes in-flight estimates of reaction wheel bearing drag torque and made them available to the mission operations team. These telemetry data are being trended for the purpose of monitoring the long-term health of the reaction wheel bearings. Anomalous drag torque signatures observed over the past 15 years are described in this paper. One of these anomalous drag conditions is bearing cage instability that appeared (and disappeared) spontaneously and unpredictably. Cage instability is an uncontrolled vibratory motion of the bearing cage that can produce high-impact forces internal to the bearing that will cause intermittent and erratic torque transients. Characteristics of the observed cage instabilities and other drag torque "spikes" are described in this paper. In day-to-day operations, the reaction wheels' rates must be neither too high nor too low. To protect against operating the wheels in any undesirable conditions (such as prolonged low spin rate operations), a ground software tool named Reaction Wheel Bias Optimization Tool (RBOT) was developed for the management of the wheels. Disciplined and long-term use of this ground software has led to significant reduction in the daily consumption rate of the wheels' low spin rate dwell time. Flight experience on the use of this ground software tool as well as other lessons learned on the management of Cassini reaction wheels is given in this paper.
Cassini uses reaction wheels to achieve the spacecraft pointing stability that is needed during imaging operations of several science instruments. The Cassini flight software makes inflight estimates of reaction wheel bearing drag torque and the reaction wheel controller uses these estimates to achieve a high level of spacecraft pointing stability. However, the Cassini drag torque estimator was designed to accurately track the bearing drag torque only in the steady state. When the physical drag torque changes abruptly (for example, during a reaction wheel spin rate reversal or when wheel bearings experienced drag spikes), the drag estimator will not be able to track the physical drag closely. This will lead to a degradation in the spacecraft pointing stability performance. For Cassini, this was not a problem because of the significant performance margin in pointing stability. However, for missions that have very challenging pointing stability requirements and that must perform well in the presence of frequent wheel rate reversals, alternative drag-compensating control schemes must be considered. To this end, alternative drag torque compensating control schemes (such as the adaptive model reference control scheme) are briefly reviewed in this paper. Selected design features used in these friction compensation schemes may be incorporated in reaction wheel controller design to improve the robustness of spacecraft pointing stability performance with regard to a wide range of reaction wheel drag torque anomalous behavior.
The Cassini spacecraft was launched on 15 October 1997 on a Titan IV-B launch vehicle. The spacecraft is comprised of various subsystems, including the Attitude and Articulation Control Subsystem (AACS). The AACS Flight Software (FSW) and its development has been an ongoing effort, from the design, development and finally operations. As planned, major modifications to certain FSW functions were designed, tested, verified and uploaded during the cruise phase of the mission. Each flight software upload involved extensive verification testing. A standardized FSW testing methodology was used to verify the integrity of the flight software. This paper summarizes the flight software testing methodology used for verifying FSW from pre-launch through the prime mission, with an emphasis on flight experience testing during the first 2.5 years of the prime mission (July 2004 through January 2007).
The software engineering design of the Flight Software Memory Tracker (FMT) Tool is discussed in this paper. FMT is a ground analysis software set, consisting of utilities and procedures, designed to track the flight software, i.e., images of memory load and updatable parameters of the computers on-board Cassini spacecraft. FMT is implemented in Java.
Explore the source record for details and available documents.
Extended bright bodies in the Saturn environment such as Saturn's rings, the planet itself, and Saturn's satellites near the Cassini spacecraft may interfere with the star tracker's ability to find stars. These interferences can create faulty spacecraft attitude knowledge, which would decrease the pointing accuracy or even trip a fault protection response on board the spacecraft. The effects of the extended bright body interference were observed in December of 2000 when Cassini flew by Jupiter. Based on this flight experience and expected star tracker behavior at Saturn, the Cassini AACS operations team defined flight rules to suspend the star tracker during predicted interference windows. The flight rules are also implemented in the existing ground software called Kinematic Predictor Tool to create star identification suspend commands to be uplinked to the spacecraft for future predicted interferences. This paper discusses the details of how extended bright bodies impact Cassini's acquisition of attitude knowledge, how the observed data helped the ground engineers in developing flight rules, and how automated methods are used in the flight and ground software to ensure the spacecraft is continuously operated within these flight rules. This paper also discusses how these established procedures will continue to be used to overcome new bright body challenges that Cassini will encounter during its dips inside the rings of Saturn for its final orbits of a remarkable 20-year mission at Saturn.
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. In the event safe mode interrupts normal orbital operations, Cassini has flight software fault protection algorithms to detect, isolate, and recover to a thermally safe and commandable attitude and then wait for further instructions from the ground. But the Saturn environment is complex, and safety hazards change depending on where Cassini is in its orbital trajectory around Saturn. Selecting an appropriate safe mode attitude that insures safe operation in the Saturn environment, including keeping the star tracker field of view clear of bright bodies, while maintaining a quiescent, commandable attitude, is a significant challenge. This paper discusses the Cassini safe table management strategy and the key criteria that must be considered, especially during low altitude flybys of Titan, in deciding what spacecraft attitude should be used in the event of safe mode.
No abstract available
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.
Simulation environments have been an integral part of Cassini's heritage. From the time of flight software development and testing to the beginning of the spacecraft's extended mission operations, both softsim and hardware-in-the-loop testbeds have played vital roles in verifying and validating key mission events. Satellite flybys and mission-critical events have established the need to model Titan's atmospheric torque, Enceladus' plume density, and other key parametric spacecraft environments. This paper will focus on enhancements to Cassini's Flight Software Development System (FSDS) and Integrated Test Laboratory (ITL) to model key event attributes which establish valid test environments and ensure safe spacecraft operability. Comparisons between simulated to in-flight data are presented which substantiate model validity.
A method was developed for measuring the atmospheric density of Titan, the largest moon of Saturn, to create an accurate density profile as a function of altitude. This will allow mission planners to select safe flyby altitudes, and for navigation engineers to accurately predict the delta-v associated with those flybys. The spacecraft angular rate vector profile as a function of time is collected via telemetry from the onboard attitude estimator once every 2 seconds. The telemetry for thruster times, as a function of time, for eight Reaction Control System (RCS) thrusters is gathered, once a second, from the Propulsion Manager algorithm of the Cassini onboard attitude-control flight software. Using these data, the ground software computes the angular momentum vector profile and the per-axis external torque as a function of time imparted from the spacecraft only due to the atmospheric drag. The software can then determine the Titan atmospheric density profile as a function of time and altitude with the known values of spacecraft center of mass, the Titan-relative range and velocity data, the projected area, and the aerocenter, along with the estimated drag coefficient in a free molecular flow field.
Operating spacecraft is a never-ending challenge and the risk of human error is ever- present. Many missions have been significantly affected by human error on the part of ground controllers. The Cassini mission at Saturn has not been immune to human error, but Cassini operations engineers use tools and follow processes that find and correct most human errors before they reach the spacecraft. What is needed are skilled engineers with good technical knowledge, good interpersonal communications, quality ground software, regular peer reviews, up-to-date procedures, as well as careful attention to detail and the discipline to test and verify all commands that will be sent to the spacecraft. Two areas of special concern are changes to flight software and response to in-flight anomalies. The Cassini team has a lot of practical experience in all these areas and they have found that well-trained engineers with good tools who follow clear procedures can catch most errors before they get into command sequences to be sent to the spacecraft. Finally, having a robust and fault-tolerant spacecraft that allows ground controllers excellent visibility of its condition is the most important way to ensure human error does not compromise the mission.
"Support imaging" is imagery requested by other Cassini science teams to aid in the interpretation of their data. The generation of the spacecraft command sequences for these images is performed by the Cassini Instrument Operations Team. The process initially established for doing this was very labor-intensive, tedious and prone to human error. Team management recognized this process as one that could easily benefit from automation. Team members were tasked to document the existing manual process, develop a plan and strategy to automate the process, implement the plan and strategy, test and validate the new automated process, and deliver the new software tools and documentation to Flight Operations for use during the Cassini extended mission. In addition to the goals of higher efficiency and lower risk in the processing of support imaging requests, an effort was made to maximize adaptability of the process to accommodate uplink procedure changes and the potential addition of new capabilities outside the scope of the initial effort.
Three questions to which software developers want accurate, precise answers are "How can the software system fail?", "mat bad things will happen if the software fails?t', and "How many failures will the software experience?". Numerous techniques have been devised to answer these questions; three of the best known are: 1) Software Fault Tree Analysis (SFTA) 2) Software Failure Modes, Effects, and Criticality Analysis (SFMECA 3) Software Fault/Failure Modeling. SFTA and SFMECA have been successfully used to analyze the flight software for a number of robotic planetary exploration missions, including Galileo, Cassini, and Deep Space 1. Given the increasing interest in reusing software components from mission to mission, one of us has developed techniques for reusing the corresponding portions of the SFTA and SFMECA, reducing the effort required to conduct these analyses. SFTA has also been shown to be effective in analyzing the security aspects of software systems; intrusion mechanisms and effects can easily be modeled using these techniques. The Bi- Directional Safety Analysis (BDSA) method combines a forward search (similar to SFMECA) from potential failure modes to their effects, with a backward search (similar to SFTA) from feasible hazards to the contributing causes of each hazard. BDSA offers an efficient way to identify latent failures. Recent work has extended BDSA to product-line applications such as flight-instrumentation displays and developed tool support for the reuse of the failure-analysis artifacts within a product line. BDSA has also been streamlined to support those projects having tight cost and/or schedule constraints for their failure analysis efforts. We discuss lessons learned from practice, describe available tools, and identi@ some future directions for the topic. A substantial amount of research has been devoted to estimating the number of failures that a software system will experience during test and operations, as well as the number of faults that have been inserted into that system during its development. One of us has found that the amount of structural change to a system during its development is strongly related to the number of faults inserted into it. Using techniques requiring no additional effort on the part of the development organization, the required measurements of structural evolution can be easily obtained from a development effort's configuration management system and readily transformed into an estimate of fault content. So far, structure-fault relationships have been identified for source code; current work seeks to examine artifacts available earlier in the lifecycle to determine if similar relationships between structure and fault content can be found. In particular, relationships between requirements change requests and the number of faults inserted into the implemented system would provide a significant improvement in our ability to control software quality during the early development phases.