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 length of the Voyager mission and the communication delay caused by the distances involved made fault protection a necessary part of the Voyager Attitude and Articulation Control Subsystem (AACS) design. An overview of the Voyager attitude control fault protection is given and flight experiences relating to fault protection are provided.
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 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).
A sophisticated interplanetary spacecraft, Cassini/Huygens was launched on October 15, 1997. Since achieving orbit at Saturn in 2004, Cassini has collected science data throughout its four-year prime mission (2004–08), and has since been approved for first and second extended missions through September 2017. The Cassini Attitude and Articulation Control Subsystem (AACS) is perhaps the spacecraft subsystem that must satisfy the most mission and science pointing requirements. Since launch, the performance of the Cassini AACS design has been superb. All key mission and science requirements are met with significant margins. An overview of the flight performance of the Cassini attitude control system as well as AACS mission operation-centric lessons learned, from launch to 2017, are described by topics. Many of these lessons learned should be applicable to the safe operations of other interplanetary missions. Processes taken by the AACS operation team to guard against “human” errors are also outlined in this paper.
The Cassini-Huygens mission ended on September 15, 2017, after nearly two decades in ight. The well-designed Cassini spacecraft had robust hardware that permitted two extended missions, lasting nine years longer than the expected prime mission. At the end of the mission, the Attitude and Articulation Control Subsystem (AACS) was using two pieces of redundant back-up of hardware, one reaction wheel and the hydrazine thruster branch, due to hardware anomalies earlier in the mission. The back-up hardware performed nominally through the rest of mission. The prime reaction wheels at the end of the mission had reached more than 130% of the consumable limit for number of revolutions. No thruster on either thruster branch accumulated more than 45% of the consumable limits. The inertial reference unit slightly exceeded the pre-launch requirements on bias error, but as the software continuously estimated this value in ight, the attitude estimation was not adversely a ected. The star trackers performed nominally, and though there was a spacecraft anomaly in 1998 related to the star trackers, the origin was not in hardware itself. The Sun sensors and accelerometer both performed as expected and met all requirements throughout the mission. Ultimately, the lifetime of the Cassini spacecraft was not limited by hardware performance. Planetary protection requirements necessitated the end of the mission as the spacecraft's propellant reserves depleted, and Cassini plunged into Saturn's atmosphere with a healthy attitude control system.
A type of facility required to integrate and test a complex autonomous spacecraft subsystem is presented, using the attitude and articulation control subsystem (AACS) of Project Galileo as an example. The equipment created for testing the AACS at both the subsystem and spacecraft system levels is described, including a description of the support equipment (SE) architecture in its two main configurations, closed loop simulation techniques, the user interface to the SE, and plans for the use of the facility beyond the test period. This system is capable of providing a flight-like functional environment through the use of accurate real-time models and carefully chosen points of interaction, and flexible control capability and high visibility to the test operator.
In current spacecraft design, a trend can be observed to achieve greater fault tolerance through the application of on-board software dedicated to detecting and isolating failures. Whether fault tolerance through software can meet the desired objectives depends on very careful consideration and control of the system in which the software is imbedded. The considered investigation has the objective to provide some of the insight needed for the required analysis of the system. A description is given of the techniques which have been developed in this connection during the development of the Voyager spacecraft. The Voyager Galileo Attitude and Articulation Control Subsystem (AACS) fault tolerant design is discussed to emphasize basic lessons learned from this experience. The central driver of hardware redundancy implementation on Voyager was known as the 'single point failure criterion'.
The conduction of the Project Galileo Orbiter, with 18 microcomputers and the equivalent of 360K 8-bit bytes of memory contained within two major engineering subsystems and eight science instruments, requires that the key onboard computer system resources be managed in a very rigorous manner. Attention is given to the rationale behind the project policy, the development stage, the preliminary design stage, the design/implementation stage, and the optimization or 'scrubbing' stage. The implementation of the policy is discussed, taking into account the development of the Attitude and Articulation Control Subsystem (AACS) and the Command and Data Subsystem (CDS), the reporting of margin status, and the response to allocation oversubscription.
The ongoing design and implementation of the Project Galileo Attitude and Articulation Control Subsystem (AACS) flight software is outlined, as well as the more important problems that were experienced in the development of this software. The important characteristics of the Galileo spacecraft are described, as are the major requirements driving the software design. The important features of the design are stated and discussed, and a modes and tasks transition diagram is presented. The AACS software implementation is covered, and the algorithms active in each task are shown. Finally, some of the design and management techniques used in the course of the software development are discussed.
The two Voyager spacecraft were launched in the summer of 1977, flew past Jupiter in 1979, and reached Saturn in 1980 and 1981. The Voyager Attitude and Articulation Control Subsystem (AACS) controls the positioning of a scan platform on which scientific instruments are mounted. On August 26, 1981, it was discovered that the azimuth axis of the scan platform of Voyager 2 had not completed the commanded slew. The profile of the failed slew command resembled a similar scan failure on Voyager 1 on February 23, 1979. In that case, contamination of the output gear mesh in the azimuth actuator was identified as the most probable cause of the failure. The problem was solved by cycling the azimuth actuator until the contaminant broke down and smooth operation was restored. A similar treatment applied to the Voyager 2 problem failed. Details of the Voyager 2 anomaly investigation are discussed.
In order to ensure the reliable operation of the Attitude and Articulation Control Subsystem (AACS) which will guide the Galileo spacecraft on its two and one-half year journey to Jupiter, the AACS is being rigorously tested. The primary objectives of the test program are the verification of the AACS's form, fit, and function, especially with regard to subsystem external interfaces and the functional operation of the flight software. Attention is presently given to the Galileo Closed Loop Test System, which simulates the dynamic and 'visual' flight environment for AACS components in the laboratory.
Some of the engineering problems encountered during the post-launch phase of interplanetary space missions are described, with emphasis given to the Voyager missions. The major in-flight modifications in Voyager spacecraft's operational capability with respect to communications, payload, and navigation systems are discussed. Attention is given to the instances of 'failure workaround' including: recovery from a failed receiver, recovery from a seized scan platform actuator, and modifications to the Attitude Articulation and Control Subsystem (AACS) software during the Saturn encounter. A detailed line drawing of the Voyager spacecraft is provided.
This paper discusses the fault protection tesing of the Attitude and Articulation Control Subsystem (AACS) of the Galileo spacecraft. The need for an autonomous fault protection system on an interplanetary spacecraft is discussed. Galileo requirements for the detection and response of specific hardware failures is discussed along with the fault protection software design and implementation. The test beds and test methods used for fault protection testing are described. The paper concludes with a presentation of the results of this testing with an emphasis on requirement and design changes that were made as a result of these tests.
In the spring of 1989, the Magellan spacecraft will embark on a two-year mission to map the surface of the planet Venus. Guiding it there will be the Attitude and Articulation Control Subsystem (AACS). To ensure reliable operations the AACS is being put through a rigorous test program at Martin Marietta Denver Aerospace. Before Magellan ever leaves the Space Shuttle bay from which it is to be launched, its components will have flown a simulated spaceflight in a ground-based lab. The primary objectives of the test program are to verify form, fit, and function of the AACS, particularly subsystem external interfaces and functional operation of the flight software. This paper discusses the Magellan Closed Loop Test Systems which makes realistic tests possible by simulating the dynamic and 'visual' flight environment for AACS components in the lab.
The combination of a sun sensor called a sun gate (SG) and a digital programmable signal processor on the Galileo spacecraft attitude and articulation control subsystem (AACS) will orient the rotation axis of the spacecraft toward the sun to satisfy a new requirement imposed by the new spacecraft trajectory. The combination will continuously monitor the pointing direction of the rotation axis, and any off-sun excursions of more than a preset threshold will be detected, triggering appropriate actions by the flight software to prevent off-sun cone angles of more than 14 deg. The design of the SG is described in detail, its principle of operation is given, and the flight software processing of the SG output is discussed.
Mission operations for the Mars Observer (MO) Project at the Jet Propulsion Laboratory were supported by a variety of ground data processing software and analysis tools. Some of these tools were generic to multimission spacecraft mission operations, some were specific to the MO spacecraft, and others were custom tailored to the operation and control of the Attitude and Articulation Control Subsystem (AACS). The focus of this paper is on the data analysis tools for the AACS. Four different categories of analysis tools are presented; with details offered for specific tools. Valuable experience was gained from the use of these tools and through their development. These tools formed the backbone and enhanced the efficiency of the AACS Unit in the Mission Operations Spacecraft Team. These same tools, and extensions thereof, have been adopted by the Galileo mission operations, and are being designed into Cassini and other future spacecraft mission operations.
From the Martin Marietta Astronautics Group base in Denver, Colorado, spacecraft engineers have been operating the Magellan spacecraft for the past three and one half years, along with the Jet Propulsion Laboratory, for NASA. The spacecraft team in Denver is responsible for the health of the vehicle, from command generation to evaluation of engineering telemetry. Operation of the spacecraft's Attitude and Articulation Control Subsystem (AACS) has specifically posed several in-flight challenges. This system must provide accurate pointing of the spacecraft throughout each 3.2 hour orbit which typically consists of 5 - 9 discrete maneuvers. Preparation of bi-weekly command sequences, monitoring execution, and trending of subsystem performance is of paramount importance, but in-flight anomalies have also demanded the attention of AACS engineers. Anomalies are often very interesting and challenging aspects of a project, and the Magellan mission was no exception. From the first unsuccessful attempts to perform a starscan, to spacecraft safing events, much has been experienced to add to the `lessons learned' from this mission. Many of Magellan's in-flight experiences, anomalies, and their resolutions are highlighted in this paper.
This paper will present a description of the simulation system and the innovations that were incorporated.