OBJECT-ORIENTED DESIGN FOR AUTHORING AND EXECUTING SPACECRAFT OPERATING PROCEDURES

Tim Grant, Ivo van Dreumel, Eelco Lammers, Thijs Ott de Vries, Rudi Potze#

# was with Computer Resources International A/S.

Origin/Nieuwegein B.V.
P. O. Box 1444
NL-3430 BK Nieuwegein
The Netherlands
tel: +31 30 608 88 88
fax: +31 30 606 05 77
email: Tim.Grant@nlnwgfsc.origin.nl

ABSTRACT

The purpose of the paper is to present a generic, pattern-based, object-oriented design supporting the complete procedure life-cycle. The development of a generic design is significant in that it enables re-use across a wide range of systems and applications (with attendant cost and time savings) and the development of COTS products. The generic design distills a decade of experience in designing and integrating software for the end-to-end support of the authoring and execution of spacecraft operating procedures. Applications cover crew and automated procedures for payloads and subsystems, and for in-orbit and ground operations. Manned and remote-sensing missions are emphasised. Experience also includes unmanned, ground-based, and non-space missions.

INTRODUCTION

This paper presents a generic object-oriented design supporting the complete procedure life-cycle, including authoring/generation, storage, verification and validation, selection and retrieval, instantiation, resource allocation, execution, and post-use evaluation. The design is based on patterns. User-interface and functionality issues are separated. The development of a generic design is significant in that it enables re-use across a wide range of systems and applications (with attendant cost and time savings), and the development of COTS products.

The knowledge embodied in the generic design is distilled from a decade of experience in designing and integrating software for the end-to-end support of the authoring and execution of spacecraft operating procedures. Applications cover crew and automated procedures for payloads and subsystems, and for in-orbit and ground operations. Manned and remote-sensing missions are emphasised. Experience also includes unmanned, ground-based, and non-space missions. Systems have been implemented using Oracle, Lisp, Smalltalk, C++, Ada, MS-Word, and HTML with Booch, OOSE, OMT, Coad and Yourdon OOA, and HOOD methods.

There are three main approaches to operating a complex system. In the command-based approach, there is a set of commands that can be issued to the complex system, and the operator is responsible for selecting, instantiating and despatching the correct command. In the procedure-based approach, there is a set of prepared command-sequences that can be issued, and the operator is responsible for selecting, instantiating and despatching the correct command-sequence. In the goal-oriented approach, there is a set of goal-states that the system can be instructed to achieve, and the operator is responsible for selecting, instantiating and despatching the correct goal-state. This paper is concerned with the procedure-based approach. The authoring and execution of procedures will be collectively known as procedure management. The individual commands embedded in the procedure will be known as steps. Procedures may also be known as action-sequences, scripts, or recipes. Commands may also be known as actions, activities, telecommands, or (as in the International Space Station) SWOPs, (FL)APs, and entries.

The procedure-based approach has the advantage that the procedures can be tested before execution, giving a measure of certainty about the safety of the complex system. This is particularly important for rare but life- or mission-critical situations. In addition, the workload on the operator is reduced, because (the majority of) the procedures can be prepared in advance and re-used for similar situations. Procedures can also be used to improve coordination between multiple operators or actors with the minimum of communication.

There are six chapters. Chapter 2 summarises related project experience. Chapter 3 lists trade-offs in procedure management. Chapter 4 presents the generic design, identifying the key patterns to be found in it. Chapter 5 outlines experience in adapting it for specific projects. Chapter 6 identifies possible future enhancements.

RELATED PROJECT EXPERIENCE

Origin (known as Buro voor Systeemontwikkeling (BSO) until 2 May 1996) has been working on European space projects since 1980. In 1986, Origin began work under national funding on an expert system to support operators of the METEOSAT weather satellite in diagnosing faults in the on-board radiometer. Known as MERADEXP, the expert system was operationalised for ESOC in 1987 (Jongert, 1988). Having diagnosed a fault, MERADEXP prescribed the fault recovery procedure.

Recognising the limitations of the "canned text" form in which the recovery procedures were presented, in 1987 Origin began a nationally-funded study known as "PROcedures Knowledge BASE" (PROKBASE) to identify suitable representations for procedures. Three prototypes (in Oracle, Lisp and Smalltalk) were developed successfully (Grant, 1988). A fourth prototype was developed later to support mixed-initiative procedure authoring by graphical means.

Development of the first of four versions of the Cabin Atmospheric Pressurisation Subsystem Expert System (CAPS ES) began in the same year. Originally known as the "N2O2 Expert System", CAPS ES was designed to support the on-board operation by astronauts of life-critical systems (Ockels, 1992). Fault Detection, Isolation and Recovery (FDIR) and procedure execution functionalities were integrated, with Space Shuttle ECLSS malfunction procedures being the illustrative application. User-interface issues were found to be as important as the internal representations (Kooter, van Dreumel and Grant, 1993). CAPS ES is installed in ESTEC's Crew Work Station Test-Bed (CWS-TB).

In parallel, Origin developed the Crew Portable Computer (Crew PC) Mark II, also for ESTEC's CWS-TB, but applied to payloads. Crew PC Mark II incorporated the Crew Procedure Execution System (CPES), developed for ESTEC by Computer Resources International A/S (CRI). CPES was integrated with the Origin-developed multimedia documentation and telesupport facilities to enable group-working between astronauts on-board and the PI on the ground. The on-board and ground-based Crew PCs communicated using the CCSDS packetised telemetry and telecommanding (TM/TC) protocols. Based on the Crew PC Mark II, Origin developed the Crew Support Computer (CSC) for flight on EuroMIR'94 and EuroMIR'95. In the CSC, the CPES was replaced by the DLR-developed OPIS.

Based on the subsystem application embodied in CAPS ES and the payload application in Crew PC Mark II and CSC, Origin was given a contract by ESTEC to develop the Advanced Crew Terminal (ACT). ACT is a generic framework and family of products covering the in-orbit and ground-based applications of terminals, during both the mission preparation and the mission operations phases. Of the many generic ACT services, two are of particular relevance to this paper. The Procedure Authoring Service (PAS) provides the off-line, preparation-phase facilities for authoring procedures. The Procedure Execution Service (PES) provides the on-line, operations-phase facilities for executing procedures, both in-orbit and on-ground. Under subcontract to Origin, CRI has developed implementations of the PAS (in MS-Word) and of the PES (in C++), with the procedures being represented in HTML for transmission over the World Wide Web (WWW). ACT is not required to be space-qualified and makes the maximum use of Commercial Off-The-Shelf (COTS) products. Accordingly, the ACT demonstrators are based on PCs running Windows 3.x. ACT is described in more detail in (Gale, 1966).

Origin is contracted to MMS to develop the HCI software for the International Space Station (ISS) Russian segment's Data Management System (DMS-R). This includes the Crew Procedure Language Interpreter (CPLI), which must execute procedures written in the ISS-standard Automated Crew Procedure (ACP) language. The CPLI is being developed in HOOD and Ada83 for running under Unix, because the entire DMS-R system must be space-qualified. There is no procedure authoring part in Origin's contract.

Another relevant is Origin's development under national funding of the Earth Monitoring Work Station (EMWS), based on a PC running Windows NT and interfaced to the WWW. The EMWS subsystems include a Recipe Editor and a Recipe Despatcher. The Recipe Editor is intended to be used by a meteorologist to develop recipes for processing remote sensing data. The Recipe Despatcher executes these recipes. As in ACT, procedures are represented using HTML.

TRADE-OFFS IN PROCEDURE MANAGEMENT

There are several ways in which procedures can be classified. They can be classified according to the situation in which they are used, giving routine (nominal) and contingency (non-nominal, anomaly) procedures. Analysis shows that routine procedures are almost invariably time-triggered, and contingency procedures are event- or state-triggered. They can classified according to the type of complex (sub)system to be commanded. For example, in spacecraft operations this gives a classification into crew and automated procedures. However, closer analysis shows that each procedure-step can be issued to a different subsystem, enabling hybrid procedures to be constructed which support the cooperative working of man and machine.

A procedure management system divides into two parts: a procedure authoring subsystem and a procedure execution subsystem. The authoring subsystem is an off-line system that supports the manual or automatic generation of procedures, followed by their testing, approval, and archiving. The execution subsystem is an on-line system that supports the selection, retrieval, instantiation, execution, execution monitoring, and execution recording of procedures. In manned spacecraft applications, the execution subsystem would also be installed on-board. It is foreseeable that, in the longer term, an authoring subsystem installation could also be provided on-board.

There are various issues and trade-offs in designing and implementing procedure management systems:

There are also various options in dividing the responsibility between the operator and the procedure execution part of the procedure management system, as follows:

There are also software engineering issues:

GENERIC DESIGN AND KEY PATTERNS

The philosophy underlying the development of a generic design was as follows:

The generic design was documented using the Coad and Yourdon OOA notation (Coad and Yourdon, 1991) in the OOTher shareware tool. The static object model, comprising object-classes and attributes, is complete. Key groups of object-classes include:

The main methods have been identified, but (at the time of writing) the dynamic model is incomplete. Our experience with OO methods shows that it would be particularly beneficial to supplement the object model represented using the Coad and Yourdon OOA notation with use-cases and object-interaction diagrams, i.e. notations borrowed from Jacobson's Objectory method. The OOTher tool supports the two methods in such a combination.

Design patterns were identified from the generic design post-hoc. The following main patterns have been identified:

ADAPTATION FOR SPECIFIC PROJECTS

The generic design has been central to CRI's implementation of the ACT's PAS and PES. Adaptations have included fusing the Step and Action object-classes, reducing the subclass hierarchy under Action, and addition of a structured-text user interface for PES based on the lessons learned from CPES and OPIS. Implementation of PAS and PES was found to be facilitated by the existence of the generic design.

By contrast, the generic design has not been so central to Origin's development of the CPLI for DMS-R. Reasons included:

Nevertheless, the generic design was used in CPLI development as a cross-check on the outputs from YACC and LEX.

POSSIBLE FUTURE ENHANCEMENTS

The static object model embodied in the generic design has been proven by its use in implementing ACT's PAS and PES. It needs to be supplemented by completing the dynamic object model, preferably using use-cases and object-interaction diagrams. If desired, the generic design could be readily transferred to a closely-related OOA/D method, such as OMT, or to another tool, such as Teamwork or Paradigm Plus.

At a software engineering level, the generic design could be enhanced to model the user-interface, database, and control components of procedure management systems. At the application level, it would be particularly interesting to extend the generic design to incorporate the capability for generating procedures automatically from system design information (e.g. output from CADCAM), as envisaged in (Grant, 1992). The Planning Operator Induction algorithm (Grant, 1996), coupled with an AI-based plan generation algorithm, would be a candidate for this purpose.

REFERENCES

Coad, P., and Yourdon, E. (1991). Object-Oriented Analysis. Second edition, Yourdon Press Computing Series, Englewood Cliffs, NJ, USA.

Coad, P., North, D., and Mayfield, M. (1995). Object Models: Strategies, Patterns and Applications. Yourdon Press Computing Series, Englewood Cliffs, NJ, USA, ISBN 0-13-108614-6.

Grant, T. J. (1988). An Algorithm for Obtaining Action Sequences from a Procedures Knowledge Base. Proceedings, European Conference on Artificial Intelligence, Munich, Germany.

Grant, T. J. (1992). Integrating Payload Design, Planning and Control in the Dutch Utilisation Centre. Proceedings, 2nd International Symposium on Ground Data Systems for Space Mission Operations (SpaceOps'92), Pasadena, CA, USA, 16-20 November 1992, JPL Publication 93-5, 237-242.

Grant, T. J. (1996). Inductive Learning of Knowledge-Based Planning Operators. PhD thesis, Department of Computer Science, University of Limburg, Maastricht, The Netherlands.

Jongert, J. (1988). Operationalising an Expert System for Satellite Control. Proceedings, Workshop on Artificial Intelligence Applications on Space Projects, ESTEC, Noordwijk, The Netherlands, 15-17 November 1988.

Kooter, B. M., van Dreumel, I., and Grant, T. J. (1993). Graphical User Interfaces for On-Board Subsystem Operations: Lessons learned from the CAPS Expert System. Proceedings, 3rd European In-Orbit Operations Technology Symposium, ESTEC, Noordwijk, The Netherlands, 22-24 June 1993, ESA WPP-059, 229-248.

Ockels, W. J. (1992). A New Approach to Spacecraft Crew System Operations. ESA Journal, 16, 233-236.