Kathryn Anne Weiss

Application of a Safety-Driven Design Methodology to an Outer Planet Exploration Mission

Traditional requirements specification and hazard analysis techniques have not kept pace with the increasing complexity and constraints of modern space systems development. These techniques are incomplete and often consider safety late in the development cycle when the most significant design decisions have already been made. The lack of an integrated approach to perform safety-driven system development from the beginning of the system lifecycle hinders the ability to create safe space systems on time and within budget. To address this need, the authors have created an integrated methodology for safety-driven system development that combines four state-of-the-art techniques: 1) intent specification, a framework for organizing system development and operational information in a hierarchical structure; 2) the STAMP model of accident causation, a system-theoretic framework upon which to base more powerful safety engineering techniques; 3) STAMP-based hazard analysis (STPA); and 4) state analysis, a model-based systems engineering approach. The iterative approach specified in the methodology employs state analysis in the modeling of system behavior. STPA is used to identify system hazards and the constraints that must be enforced to mitigate these hazards. Finally, intent specification is used to document traceability of behavioral requirements and subject them to formal analysis using the SpecTRM-RL software package. In this paper, the application of this methodology is demonstrated through the specification of a spacecraft high gain antenna pointing mechanism for a hypothetical outer planet exploration mission.

An analysis of causation in aerospace accidents

After a short description of common accident models and their limitations, a new model is used to evaluate the causal factors in a mission interruption of the SOHO (SOlar Heliospheric Observatory) spacecraft. The factors in this accident are similar to common factors found in other recent software related aerospace losses.

Making embedded software reuse practical and safe

Reuse of application software has been limited and sometimes has led to accidents. This paper suggests some requirements for successful and safe application software reuse and demonstrates them using a case study on a real spacecraft.

Engineering Spacecraft Mission Software using a Model-Based and Safety-Driven Design Methodology

This paper outlines an integrated approach to system, software, and safety engineering for today’s complex, safety-critical systems. Intent Specifications, component-based systems engineering, and a new hazard analysis technique based on the Systems Theoretic Accident Modeling and Process (STAMP) are all combined in a seamless, safety-driven design methodology. This integrated approach to system software development is demonstrated through an example application of the techniques on a low-Earth orbiting satellite. The results of performing the system modeling, hazard analyses, and model simulations of the spacecraft as a whole are also presented. Finally, the approach is compared to other, current model-based systems engineering and hazard analysis techniques.

Component-Based Systems Engineering for Autonomous Spacecraft

The development of modern spacecraft is a challenging endeavor, especially in light of the increasing complexity of today’s technology and new, ambitious mission goals. These challenges are exacerbated by the recent budget and personnel cutbacks at both NASA and its contractors. A new approach to spacecraft development that addresses many of the current issues facing the aerospace industry is described. The technique, called ComponentBased Systems Engineering, is built upon both the principles of systems engineering and the reusability characteristics of Component-Based Software Engineering. A systems engineering development environment is used, in which the artifacts of the requirements and specification portions of the component and subsystem development process are reused instead of the software. The development environment provides a common and formal means of communicating requirement specifications as well as preserving the part-in-whole context of various components and subsystems. An example is provided of ComponentBased Systems Engineering as applied to a series of autonomous spacecraft called SPHERES. Simulations of both one- and two-Sphere configurations are used to illustrate not only the usefulness and reusability of the technique but also the social benefits, such as knowledge capture, of Component-Based Systems Engineering.

Reusable software architectures for aerospace systems

Modern, complex control systems for specific application domains often display common system design architectures with similar subsystem functionality and interactions. The similarities between these subsystems in most spacecraft can be exploited to create a model‐driven system development environment and then transformed into software or hardware either manually or automatically. Modifications to software and hardware during operations can be similarly made in the same controlled way. The approach is illustrated using a spacecraft attitude determination and control subsystem, but applies equally to other types of aerospace systems.

Software System Safety

Publisher Summary This chapter describes the roots of the software safety problem, why they exist, and some approaches that can be used to mitigate them. Software is quickly becoming a major part of and a major concern in space applications. Whereas software always has played a role in the design and control of spacecraft, the functionality being assigned to software is quickly increasing; and conservative design, which minimizes the role and complexity of software components, is rapidly decreasing. The increasing number of incidents and losses related to software, despite great care in its development and testing, show the difficulty involved in spacecraft software engineering and the need for more attention and rigor. Spacecraft software can be treated from a safety perspective in the same way as the physical components, it is important to understand why software is such a special problem and needs additional attention. With the proliferation of software control of physical systems and system components, a different type of accident is taking on increasing importance. In these accidents, labeled system accidents, losses arise from dysfunctional interactions among system components in which no components have failed.

Supporting the development of new air traffic management software

One factor inhibiting adoption of new air traffic management systems is the inability to provide sufficient assurance for the safety-critical software components. This paper describes an approach to specifying and validating safety-critical systems called SpecTRM (specification tools and requirements methodology). An experimental demonstration of SpecTRM applied to the conflict alert/mode-C intruder (CA/MCI) function of the standard terminal automation replacement systems (STARS) is used as an example. Using SpecTRM to build a model of blackbox software functionality, such as CA/MCI, helps in validating system design early in the development process and in building safety into the design from the beginning. The use of SpecTRM informal and formal specifications/models to specify the system and software functions assists in eliminating inconsistencies and discrepancies common in plain-English documents. In addition, the specifications and models are executable and analyzable. Finally, the resulting specification provides documentation for reference during the maintenance phase of the software life cycle, including the design rationale and the design features related to safety.