Figure 1. Peer-to-peer communication between software components. The addition of a new component can mean modification of all component interfaces
Operations systems for spacecraft missions have been expensive to implement because much of the software for such systems has been rewritten for each new mission. With the trend toward more complex spacecraft and more ambitious mission goals, the situation could worsen. At ESOC, the Advanced Systems and Technology Programme (ASTP) is funding a series of studies called the Advanced Technology Operations System (ATOS) studies. The aim is to develop the design basis for mission operations systems using advanced technologies such as knowledge-based systems (KBS).
In the first of these studies, ATOS-1, techniques for integrating heterogeneous advanced applications have been defined and prototyped. Such techniques enable the re-use of separately-developed applications and allow for the integration of large units of software. Software for spacecraft mission operations systems can be produced more cost effectively by making re-use and integration easier. Furthermore, these techniques can be of general application in the software industry.
This automation is achieved using computer software to perform certain actions and even to take (or propose) decisions, for example, in response to a failure. The technologies involved include knowledge-based systems (KBS) which 'reason' using an 'inference engine' to solve a problem on the basis of a set of formally expressed 'rules'.
This trend is also affecting spacecraft mission operations systems, particularly as spacecraft are becoming increasingly complex and mission goals are becoming more ambitious, thereby making the problems of planning and performance of mission operations more demanding. The advanced technology of KBS could help to solve some of these problems. Additionally, despite greater demands on such systems, economic conditions impose the need to reduce the rather high costs of implementing the operations systems for new missions. The reason for these high costs has been the need to develop substantial amounts of new software for each mission. Better re-use or adaption of existing systems and system components could therefore improve cost-effectiveness.
At ESA's Space Operations Centre, ESOC, KBS has been applied in a number of studies to specific areas of mission operations, producing a number of independent prototype KBSs. However, the various prototypes developed use different KBS tools and knowledge representations, which means that they could not easily be made to work together. This led to the need to find a solution to the integration problem without imposing a common knowledge representation on all applications. This became an important driver for ATOS-1, the first study in a series of Advanced Technology Operations System studies.
The integration problem for mission operations systems is part of a general problem in software development. The interface between software components, in particular, presents a major difficulty in the integration of complex systems.
The software integration problem
Large and complex software systems are becoming more common. Mission control systems are a good example of this. Other examples are multi-media applications, CAD (Computer Aided Design), CIM (Computer Integrated Manufacturing), telecommunica-tions, and process and environmental control systems.
There are two problems in the integration of software: the relative immaturity of software production and the problem of providing interfaces for software modules.
The 'software crisis'
Integration of computer hardware has evolved in a much better way than software integration has.
Some forty years ago, a computer was a monolithic structure of valves and other electrical components. Now, when computer manu-facturers design a new machine, they do not build a unique machine from the ground up using a collection of diodes, resistors and transistors. Rather, they assemble the machine from standard components whenever possible. They only design new components when doing so would, for example, give them a proprietary edge. Furthermore, the components are used to construct larger components. The package that results from such layered building is not a closed system. This is assisted by the existence of mature standards at each layer, allowing easy interchange of the components.
However, on the software side, there has not been a corresponding development. The step from assembly to procedural languages gave us a slight increase in the size of software components, i.e. a line of procedural code is the equivalent of several lines of assembly, but does not bring us much further than the diode/resistor/transistor level in terms of the hardware analogy. The advent of non-procedural languages such as Prolog and LISP was again an improvement, in certain ways, although its equivalence to procedural languages is hard to measure. The appearance of libraries or software modules also allowed for a higher level of integration, but nothing to rival the reusability of hardware components.The gap between the development of hardware and software is known as the 'software crisis'. It manifests itself in the difficulty of producing good 'industrial strength' (i.e. reliable) software, at least on a large scale.
Many new software engineering techniques have been heralded as the solution to the software crisis yet none of them have managed to solve the problem. At most, one is usually offered a better set of libraries with interfaces that are easier to use. However the problem of building a large system from many components where there may be a 'combinatorial explosion' of logical paths through the system and interfaces, remains the major obstacle.
The interface problem
All modern methods for breaking down complex software systems into a set of sub-problems (which are called modules, subject areas, work packages, etc.), use the 'divide and conquer' approach. Each of these sub-problems is then pursued as a separate development task.
At the end of the development, the sub-solutions must be integrated together to provide the overall solution (or the system). Integration involves communication between the sub-solutions and for that there must be an agreed interface. In practice, the agreement, implementation and testing of the interfaces is a tedious and often difficult task. Also, because they are peer-to-peer interfaces (Fig. 1), each interface may need to be modified every time a new functionality or sub-solution is added. The interfaces in a system can work against reusability of its components by being too numerous and complex.
The integration problem for mission operations systems As stated earlier, a spacecraft mission operations system is a good example of a complex system that has to be of 'industrial strength' for reasons of safety and reliability. A spacecraft mission operations system comprises the set of facilities needed to carry out all the mission operations. Mission operations can be split into three areas:
In general, each of these areas will be supported by independently developed software, possibly running on different platforms. Furthermore, these areas are linked together. For example, mission preparation produces the database for operations; mission planning produces the plan of operations to be executed by mission operations; and the progress of mission operations results in updates to the plan.
The trend towards greater automation in mission operations leads to the introduction of knowledge-based elements. The information to be shared then becomes more complex: instead of being tables, databases, or operating procedures, it becomes facts and rules.
There are a number of considerations with mission operations systems:
These problems demand solutions, particularly since budget restrictions no longer allow the luxury of reimplementing large parts of systems for new missions.
Figure 1. Peer-to-peer communication between software components. The addition of a new component can mean modification of all component interfaces
A combination of the following two approaches will aid in addressing those problems:
Generic systems and components
Generic systems have been used at ESOC for some twenty years in the area of spacecraft control. These have included the Multi-Satellite Support system and, in the 1980s, the first generation of the Spacecraft Control Operations System (SCOS-I). These were table-driven systems, providing the capability to adapt data structures and configurations to new missions. However, changing or adding functionality was always cumbersome.
In the current state-of-the-art, development of generic components or systems follows the object-oriented programming approach to the fullest extent. General classes of objects are defined. The properties of the general classes can then be 'inherited' by more specialised classes/objects adapted for the task at hand. These specialisations may override or add functionality to the parent class or classes. An important feature of this approach, in contrast with the older functional-based software engineering technology, is that the general classes are not modified and a developer wishing to reuse them does not need to understand their internal operations. Only the 'differences' from the general class are implemented in the specialised classes thus reducing the amount of coding. Furthermore, the benefit from the improvement of a class can be passed on to all specialisations of the class (by recompilation) without the need to modify the specialised classes.
The new generation of ESA Spacecraft Control Operations System (SCOS-II) uses the object-oriented technology. In SCOS-II, the basic functions of spacecraft control and monitoring are implemented as an object-oriented class library, from which mission systems can be built. Specialisation to meet mission needs can be provided using 'implementation by difference' based on the aforementioned inheritance property of object-oriented systems. In this way, SCOS-II will in due course provide a very useful set of reusable building blocks for mission control systems.
The generic approach works well in clearly understood and bounded application domains, such as spacecraft control. If it is extended to a large domain, such as the whole of mission operations, however, it breaks down, mainly because of the problem of developing and integrating large generic systems.
Federation
Although development from generic components is a very good approach, the resulting components (i.e. specialist applications) must eventually be integrated. This is not a straightforward task because of, among other reasons, the 'interface problem'.
There is no generic interface mechanism for software components, unlike for hardware components which have the Small Computer Systems Interface (SCSI), for example.
ATOS-1 uses a federation-enabling technology. It simplifies the 'interface problem' by adopting a client-server approach (Fig. 2) instead of a peer-to-peer approach. Each component (or client) has only to provide an interface to the ATOS-1 infrastructure (or server). In effect, this extends the object-oriented philosophy to the level of complete applications by providing a standard interface to them. A developer may use this interface without knowing any implementation details of the other, individual applications. This makes the possible size of software components much larger than that provided by any given set of libraries (libraries contain classes, sub-routines, etc., which are relatively small units of code).
From the point of view of mission operations, an ATOS-1 system may be seen as a group of applications, known as ATOS Application Modules or AAMs, that share information and communicate with each other to carry out the mission operations tasks. As shown in Figure 3, each AAM has its own knowledge base. The Mission Information Base (MIB) is the union of the knowledge bases of all the individual AAMs. The scope of the MIB is thus very broad and encompasses all available mission-related information, including design informa-tion, mission operations schedules, and docu-mentation.
The AAMs, which manage components of the MIB, may be physically distributed, may use different approaches to structuring knowledge (e.g. relational, object-oriented, or rule-based approaches) and may use different tools for storing and manipulating knowledge.
Figure 2. Client-server communication between software components. The addition of a new component means that only the interface with the new component must be provided.
ATOS-1 seeks to provide access to data belonging to applications written in different languages and using different storage techniques. To make this possible, the following are necessary:
An exchange of knowledge between two AAMs is illustrated in Figure 4. (This approach and the terms used are derived from the DARPA Knowledge Sharing Effort, funded by the Defence Advanced Research Projects Agency and carried out at Stanford University, USA.)
The ontology of shared knowledge AAMs must be able to share knowledge. For example, plans, the results of mission planning,are inputs into mission execution; and details of a detected anomaly are used for fault diagnosis. To share the knowledge, AAMs must have a common understanding of concepts and terms. This is provided by the ontology (Fig. 5).
The most basic use of the ontology is as a paper standard where the terms of the problem domain are defined. If there is a standard definition of the terms 'resource' , 'schedule' and 'activity' , AAMs designed to comply with the standard are guaranteed to use these terms in a common way.
In addition, an AAM's knowledge structures can be automatically derived from the ontology. The ontology is written in a formal language (rather than, for example, in English). It can therefore be translated into the particular computer-processable knowledge structures used by an AAM. This approach gives greater assurance that the AAM complies with the ontology and it can also reduce the effort required to develop the AAM.
Messages
AAMs communicate with each other via the ATOS infrastructure. Communication is performed through messages that are expressed in a high-level message language called Knowledge Query and Manipulation Language or KQML. The content of the KQML message can be in any language that the communicating AAMs understand but will usually be in the Knowledge Interchange Format (KIF). In general, a statement may have different meanings. For example, the statement 'Switch No.1 on' could be a question, 'Is Switch No. 1 on?' or an assertion, 'Switch No.1 is on'. KQML allows the distinction to be made by using the terms 'Query' and 'Assert' respectively. A knowledge interchange interface is added to the applications; it carries out conversion of information between the internal AAM knowledge representation and KIF.
The functions of the infrastructure
The ATOS infrastructure is the 'glue' that binds AAMs: it permits them to exchange knowledge.
The infrastructure 'facilitates' the integration of AAMs by:
Figure 3. The ATOS infrastructure and ATOS Application Modules (AAMs)
Figure 4. Knowledge sharing with ATOS-1: A concept or technical term, expressed in AAM 1's internal language, is translated into a common language (KIF) so that it can be understood by AAM 2
Figure 5. Ontology - an agreed meaning. When two people discuss an 'apple', each person can interpret theword in severalways. One person (on left) understands yellow apples and green apples, while the other person (on right) thinks of yellow apples, red apples and 'The Big Apple', i.e. New York City. The ontology defines the agreed understanding, and all users basing their interpretation on this ontology will understand that the common definition of 'apple' is 'yellow apple'
ATOS-1 is not just a paper study. From the outset, it was planned that prototypes would be developed to prove the feasibility of the concepts and the architecture. The prototypes fall into two categories:
ATOS-1 infrastructure
ATOS-1 is intended to run on a network of UNIX workstations where the infrastructure runs on a dedicated machine, as depicted in Figure 6. The database system, Oracle, is used to store the infrastructure information and the metabase. An object-oriented database could also be used for this. Lower-level communication is handled by a simple communications protocol.
Prototype AAMs
In 1992, ESOC undertook a project to determine the feasibility of a modelling approach to spacecraft control. Two contractors, ITV (Karlsruhe) and Siemens (Austria), developed the Automatic Mirror Furnace (AMF) Expert SYStem
(ESYS) for the AMF, the most complex payload on the Eureca satellite. AMFESYS maintains a model of the AMF, time-synchronised with the stream of spacecraft telemetry packets coming from the orbiting spacecraft. The model provides a consistent set of reference 'telemetry-parameter' values that are used to detect abnormal values in the real spacecraft telemetry. Divergence of the modelled state from the spacecraft state are corrected by a rule-based diagnosis module.
The prototype AAMs are derived directly from AMFESYS. It has three parts: a Modelling AAM, a Monitoring AAM and a Diagnostic AAM (Fig. 7). The Modelling AAM maintains a model of the AMF which the Monitoring AAM compares with telemetry from the spacecraft. If a significant discrepancy is detected, the Diagnostic AAM performs a rule-based diagnosis of the fault and then corrects the model.
Each of the three AAMs uses a different approach to structuring knowledge. C+ + , Common Lisp Object System (CLOS) and Kappa are used. They interact with each other via the ATOS infrastructure. The ontology defines the structure of the AMF.
Figure 7. Architecture of AMFESYS, a prototype with three AAMs built to demonstrate the viability of a modelling approach to spacecraft control
Object inter-operation technologies are currently the subject of much interest, again because of the potential they offer for software re-use and integration. The Common Object Request Broker Architecture (CORBA) is a widely adopted standard in this area and many implementations claim compliance with it. CORBA-compliant systems may be seen as having similar goals as ATOS-1, i.e. to allow multiple applications to share information.
CORBA records the interfaces of the different objects in its system but does not use these to perform content-based routing of messages as ATOS does because, in the classical object model, the identifier of the receiving object must be known before a message can be sent.
ATOS could make use of CORBA as a low-level communications system. This would then yield an Object Request Broker or ORB per machine, which would serve all of the AAMs on that machine. The ATOS infrastructure would run on a machine also accessible through an ORB (Fig. 8).
Figure 8. ATOS architecture based on Common Object Request Broker Architecture (CORBA)
On the other hand, CORBA does have features that are lacking in ATOS, such as transparent distribution of objects (across a network). It is also an emerging standard for object inter-operability. Combining CORBA and ATOS could be mutually beneficial. However, this would require significant work and, in view of the instability of CORBA (the specification itself is due for a major revision), it is not envisaged for the near-future.
A two-fold approach to the 'software crisis' as it affects the field of mission operations systems, is proposed:
Clearly, if the AAMs themselves are generic in their own domains, this combined approach has great power.
During the ATOS-1 project, prototypes of critical elements of the ATOS infrastructure were made. Prototypes of three AAMs have been developed to demonstrate the viability of a system constructed according to the ATOS philosophy. Furthermore, an Architectural Design Document for the full infrastructure has been written and formally reviewed.
The complementarity of the ATOS-1 integration approach with that of another standard, CORBA, has been discussed and the two approaches could be combined to exploit their individual strengths.
The work undertaken as part of the ATOS-1 study may have benefits not only in the space industry but in any application area where there is a need to integrate disparate software components in the building of complex or large systems. Such integration could allow greater re-use of complex components, leading to cost savings as well as more powerful and automated systems.
The ATOS-1 study will be completed in the fourth quarter of 1994. The next slice, ATOS-4 (also funded by ASTP), will begin at about the same time. In that study, an operations system will be developed using the ATOS-1 prototype infrastructure and the SCOS-II spacecraft control infrastructure. ATOS-4 will, in particular, seek to demonstrate the validity of using knowledge-based and other advanced technology in an operational environment.
This work was funded by ESA's Advanced Systems and Technology Programme (ASTP) which is managed by ESA's Directorate of Telecommunications. ASTP promotes the development of new technologies for the space domain, with the aim of helping European industry to develop marketable products based on these technologies. The ATOS-1 project was carried out by a consortium composed of Logica UK Limited, GMV (Spain) and SAS (Belgium).
ESA Bulletin Nr. 80.