Robert D. Rasmussen

Engineering Complex Embedded Systems with State Analysis and the Mission Data System

It has become clear that spacecraft system complexity is reaching a threshold where customary methods of control are no longer affordable or sufficiently reliable. At the heart of this problem are the conventional approaches to systems and software engineering based on subsystem-level functional decomposition, which fail to scale in the tangled web of interactions typically encountered in complex spacecraft designs. Furthermore, there is a fundamental gap between the requirements on software specified by systems engineers and the implementation of these requirements by software engineers. Software engineers must perform the translation of requirements into software code, hoping to accurately capture the systems engineers understanding of the system behavior, which is not always explicitly specified. This gap opens up the possibility for misinterpretation of the systems engineer s intent, potentially leading to software errors. This problem is addressed by a systems engineering methodology called State Analysis, which provides a process for capturing system and software requirements in the form of explicit models. This paper describes how requirements for complex aerospace systems can be developed using State Analysis and how these requirements inform the design of the system software, using representative spacecraft examples.

Stability of stochastic composite systems

In a recent paper [15] results for the asymptotic stability and exponential stability (with probability one) of a class of continuous parameter stochastic composite systems, with disturbances confined to the sub-system structure, were established. In this short paper these results are extended to allow stability analysis of systems for which stochastic disturbances may not only enter into the subsystem structure but also into the interconnecting structure of composite systems. As in previous related results, the objective is to analyze composite systems in terms of their lower order subsystems and in terms of their interconnecting structure.

A Constraint Monitor Algorithm for the Cassini Spacecraft

The Cassini spacecraft is commanded to turn from one point in space to another by commanding attitude, rate, and acceleration profiles, which the Attitude Controller is required to execute faithfully. Thc Constraint Monitor algorithm performs appropriate checks to ensure the legality and the realizability of the instantaneous attitude, rate, and acceleration commands. When the command is found to be unrealizable because of hardware limitations or itlegal because it may enter a constraint space, Constraint Monitor modifies it appropriately such that the legality of the command is maintained. In doing so it ensures that the rate and acceleration are not outside the capabilities of the attitude control hardware and that certain sensitive spacecraft boresights are protected from exposure to bright objects. The Cassini spacecraft, scheduled for launch in October 1997, will arrive at Saturn in 2004. On its way to Saturn, it will fly by Venus, Earth, and Jupiter to pick up the needed gravity assists. The spacecraft will be carrying a probe intended for delivery into the Titan atmosphere. The probe entry into the Titan atmosphere will occur about four months after Saturn arrival. Tltc spacecraft will conduct a tour of the Saturnian system for approximately four years. Several close flybys of Titan and Saturns icy satellites are planned. The nominal mission will conclude in the year 2008. Cassini science objectives include investigation of Saturns atmospheric composition, winds and temperature, configuration and dynamics of the magnetosphere, structure and composition of the rings, characterization of the icy satellites, and Titans atmospheric constituent abundance. The rack mapper will perform surface imaging and altimetry during each Titan flyby. Cassini was originally onc of the two spacecraft of Mariner Mark 11 series intended for multi-mission purpose: the CRAF (Comet Rendezvous and Asteroid Flyby) and Cassini. The CRAF mission was to follow a comet ,artd conduct scientific investigations for 120 days and Iatcr flyby an asteroid. NASA budget constraints ncccssitzzted the cancellation of CRAF and dcscoping of Cassini spacecraft. Both the high and low precision scan platforms and their structural booms were deleted, m was the turn table which carried a fields and particles experiment. The spacecraft basebody zmurncd the role of the observation platform and the entire spacecraft now had to turn in order to do earth pointing, star tracking, and remote science pointing. This makes the detection and avoidance of spacecraft attitude constraints ever more difficult since movement of one boresight requires turning …

Behavioral model pointing on Cassini using target vectors

The pointing control functions of the Cassini spacecraft attitude and articulation control subsystem have been designed to enhance operability by establishing a behavioral model at the command interface that raises pointing operations to a more intuitive level. The control system tracks this model to closely achieve the commanded behavior. Versatility is achieved by composing the behavioral model of independently commandable, interacting modules. Each directs activities directly related to a particular pointing issue, such as observation goals, instrument characteristics, attitude constraints, and navigation. A key feature of this design is the use of propagated vectors that precisely describe the motion of targets. Our design has enabled a new, more streamlined approach to mission operations whereby the many science and engineering activities sharing this system can be given direct control over pointing activities. This is possible because the behavioral model is easy to replicate in distributed ground software, it includes enforcement of constraints, and the maintenance of its components can be performed independently.

Application of state analysis and goal-based operations to a MER mission scenario

†‡ § ** State Ana lysis is a model -based systems engineering methodology employing a rigorous discovery process which articulates operations concepts and operability needs as an integrated part of system design. The process produces requirements on system and software desi gn in the form of explicit models which describe the system behavior in terms of state variables and the re lationships among them 1 . By applying State Analysis to an actual MER flight mission scenario, this study addresses the specific real world challenge s of complex space operations and explores technologies that can be brought to bear on future missions. The paper first describes the tools currently used on a daily basis for MER operations planning and provides an in -depth description of the planning pr ocess, in the context of a Martian day’s worth of rover engineering activities, resource modeling, flight rules, science observations, and more. It then describes how State Analysis allows for the specification of a corresponding goal -based sequence that accomplishes the same objectives, with several important additional bene fits.

Achieving control and interoperability through unified model-based systems and software engineering

*† ‡ Control and interoperation of complex systems is one of the most difficult challenges facing NASA’s Exploration Systems Mission Directorate. An integrated but diverse array of vehicles, habitats, and supporting facilities, evolving over the long course of the enterprise, must perform ever more complex tasks while moving steadily away from the sphere of ground support and intervention. Interoperability needs will grow to unprecedented levels as systems become more dependent on one another than on support from home. Accomplishing this with consistent safety and reliability calls for a long-term strategy. This paper describes the control challenge faced by future exploration systems and outlines a realistic approach to solving it, based upon a unified, principled architectural approach to both software and systems engineering. It concludes by suggesting the steps necessary to put this capability in place for exploration systems.