CAOS (Crew Activities Organizer System)
CAOS (Crew Activities Organizer System)
Customer ESA/EAC (European Space Agency / European Astronaut Center)
Contractual conditions 1993-1999 Subcontracted by Datamat (main contractor)
Objectives Adaptation of the ATD system as an on-boad support tool for the astronauts.
Development Status
  • Prototype flew on-board the Mir Space Station during the Euromir-95 mission. Tested as an experimental software.

1. Introduction

1.1. Project Definition

This article describes an information management system developed by the European Astronaut Centre (ESA/EAC) to organize, maintain and read complex sets of data related to the astronauts’ activities.

Such system has been developed under a project named ATD (Astronauts Training Database), which together with its spin-off CAOS (Crew Activities Organizer System), adapted to be used during EUROMIR 95, will be presented in detail here.

The nature of the activities performed by the astronauts (training, operations, public relations, general support, etc.) and the diversity of institutions involved in their organization (EAC, RSA, NASA, etc.) require a flexible infrastructure that allows for future evolution while maintaining the integrity and accessibility of existing data.

The different users (astronauts, planners, etc.) and contexts of usage (training, mission planning, operations, etc.) also demand flexibility in the possible perspectives on a common set of data.

1.2. Project History

In the Summer of 1992, the project began in EAC with the development of a first database prototype (PDA) to manage information related with the Basic Training of the astronaut candidates. It was based on an ORACLE database, maintained through an interface designed with SQL-Forms and a graphical timeline developed with Visual Basic. After the experience acquired with this first prototype, the limitations of a textual interface and the rigidness of the database structure determined a major redesign, placing a strong interest in the development of graphical user interfaces.

ATD was also used for the planning and reporting of the training for EUROMIR 94 and EUROMIR 95. The aim of the ATD design was to have enough flexibility to be used in other contexts than training. The opportunity to participate in programs such as BEDREST and CUS’94 during its development also helped in testing and refining the usage of ATD in operational contexts.

Inspired by the need expressed by the astronauts participating in EUROMIR 95 to have a tool for organizing the daily activities onboard, an ad-hoc adaptation of ATD was made during the few months prior to the flight, focusing on the requirements put forth by the astronauts. This developmental effort resulted a spin-off of ATD called CAOS, which is currently onboard of the Mir performing its designed functions.

Figure 1. Project History


More indirectly, CAOS also inherits some design elements from SPET, a software toolkit developed to support the execution of experimental tasks during the simulation campaigns EXEMSI and HUBES.

2. Conceptual Framework

2.1. Basic Concepts

  • The System is structured around the key concept of the Activity to which all other information is related. In a training context, it may correspond with the lectures; in an operational phase, with the tasks.

Figure 2. Main Entities and Relations

  • The Classes are abstract categories that permit to classify the activities, persons or resources according to certain criteria (may be different for each catalog). In a training context, they may be blocks, courses, etc., in an operational phase the different experiments, systems, etc.

Figure 3. Classification categories

  • Sessions are the actual occurrence of the activities, being allocated in a certain time and place.
  • Persons and other Resources may be assigned to the different activity sessions.
  • Additional information may be attached to any of the previous entities (such as person Addresses, resource Documentation, task Procedures, etc.).

3. Program Usage


3.1. Context

The system intends to be a common tool (or even an environment) that could be used by all the people involved in the organization and development of a complex space mission, from the initial organization, to the training, until its operational phase and beyond.

This is based in the fact that despite each person may have a partial view and control on the information that flows along the mission development, there is a common and unique background of information which appropriate distribution and management may have a direct impact on the results of the mission.

Since it may be difficult (if not impossible) to divide persons, roles and functions in closed sets, this common environment should provide enough flexibility to the users to take advantage of the advanced information technologies already available.

The ways in which each user may use the different modules provided by the system and navigate dynamically among them may depend on the specific context of usage and his personal preferences.

3.2. Users

  • The Catalog Author (training administrator or mission manager) is responsible to organize and maintain the structured set of tasks. The Catalog Browser is the tool that permits to do this independently on their further planning and implementation. The Entity Editor permits to edit in detail the information about them.
  • The Planner will be in charge of scheduling the tasks’ sessions, assigning the people or resources involved in it. This can be done graphically with the Timeline Chart, where the tasks organized with the Catalog Browser can be easily dropped.
  • The Subject of the schedule can go directly to the Timeline to see the set of tasks that he or his group may have assigned for a certain period of time, and from it he can display additional information attached to it or report any data collected during its implementation.
  • The Report Author may need to use any of the mentioned program modules to update or verify information before producing the reports. This can be done using an existing layout or creating a new one.

3.3. Flow of Information

In a Training Context, the training administrator can first organize the courses and lessons that compose the Training Catalog. The coordinators can schedule then the sessions and assign to them the attendants (trainees, instructors, etc.) and resources, produce the timeline and reports to be distributed, and, after the training sessions are completed, report the actual implementation and generate the final report.

Figure 4. Usage in a Training Context

In an Operational Context, the planner maintains the daily schedule to be uploaded to the astronaut, who can use update it to know which sessions to perform, to access related information (such as procedures or reference documentation), and be able to report the actual actions.

Figure 5. Usage in an Operational Context

The previous distinction among different user categories does not imply that they need to be different persons. In some cases, the same user may play alternative or simultaneously more than one function or even all of them.

4. Program Architecture

4.1. General Interface Guidelines

The system is composed by a set of tools which may be used independently or interrelated, depending on the logical context of the operations that the user may need to perform: the Catalog Browser provides a structured view on the classification o tasks, the Timeline shows the temporal sequence of sessions assigned to each crew member, the Entity Editor describes each item contained in the database, etc.

A consistent User Interface aspect and functionality, together with some advanced features (contextual help, tool bar, pop-up menus, drag-and-drop, etc.) tries to be intuitive enough to be used without a long training, and flexible to adapt to the needs and preferences of each user.

Figure 6. Program Modules

4.2. Timeline Chart

The Timeline Chart is a graphical interface that shows the temporal flow of tasks assigned to one or more persons or resources.

In the authoring mode, it permits to maintain the schedule by adding, changing or deleting sessions (belonging to the categories of tasks organized by mean of the Catalog Browser), assigning or de-assigning persons (with different roles) or resources.

Can be used as a high level front-end to link detailed information pertinent to the performance of each session (remarks, reference documentation, procedures) or to report any information collected during its completion. This makes it specially useful to the crew member when performing the scheduled sessions, since with a simple click of the mouse he can access to such information or report on their performance.

Several parameters that define the contents and aspect of the Timeline Chart can be configured by the user and stored in files, so that different stored Timeline Configurations may be loaded quickly.

4.3. Catalog Browser

The Catalog Browser permits to consult or maintain and organize a hierarchical index of the database contents according to criteria that may be specific to each Catalog.

A Catalog is a collection of data related with a certain context (v.g., a mission). The higher components of the Catalog are the abstract categories (Classes) that provide the hierarchical organization in which tasks, people and resources may be classified (v.g.: a mission may be composed of System, Experimental and General tasks, and the experiments may be grouped by families).

The Catalog permits to see and maintain the relations among the different elements contained within it (v.g.: experiment investigators and tools, task coordinators, participants in the sessions, etc.). It provides a global overview on logically related data, as the Timeline shows the temporal relations.

It may be also used as a persistent menu where objects may be picked to be assigned to and from other modules (v.g., dragging a task from the Catalog on the Timeline creates a new session).

4.4. Entity Editor

The Entity Editor is a flexible form that permits to inspect in detail the information about concrete items contained in the Catalog. It provides a common interface to edit the data of persons, resources, tasks, experiments, etc., adapting itself to the structure of each type of entity.

It incorporates an advanced feature (the Dictionary of Attributes) that permits the final user to create new fields (even for just a few records) during the execution of the program without requiring the change of the database structure or the redesign of the User Interface.

It shows also the links between the inspected item and any other type of entities, permitting a quick navigation (hypertextually) among all kind of information contained within the database. It can be called from the Catalog Browser, the Timeline or from the Entity Form itself. More than one Entity Editor window may be open at any time, permitting to inspect more than one item simultaneously.

4.5. Statistical Report

The Statistical Report provides a global overview on the performance of the activities in relation with the initial plan. It can show the percentage of completeness for each task, and the accumulated for each experiment.

4.6. Import/Export

The possibility to export and import the data contained in the database (for instance, the sessions scheduled for a given day), enable the program to be used by the on-ground planning team to maintain the daily plan of activities and to upload it to be imported in the on-board system to be used by the crew members.

4.7. Reports

The Reports can be generated from off-the-shelf tools (such as MS-Access or Crystal Reports) that may be linked directly with the database. In this way, the creation of new report formats can be maintained independently of the other modules, and tailored to specific needs of individual or groups of users.

5. Database Architecture

The database has been designed intending to increase its flexibility (in order to extend to incorporate new sets of data with different structure and architectural demands) and portability (being ORACLE the original platform, it can migrate to MS-Access or any other ODBC compliant DBMS).

Its design permits to use it in a multi-user environment (client/server), or as a dedicated "portable" database (eventually, the development of advanced features to synchronize multiple instances of the database should improve its distribution).

For each main entity (persons, resources, classes, tasks, sessions, etc.) there is a dedicated table.

The links among entities are maintained in auxiliar tables, depending on the logical relations.

A special database technique has been developed for this project, permitting the virtual extensibility of the structure of any entity. At any time, by mean of the Dictionary the user can create of new fields (Attributes) where to store data attached to a given item, isolating the change in such a way that it does not imply the alteration of the tables structure and it is restricted to only a subset of the table’s records.

The table of Classes contains a recursive relation with itself that permits to maintain within it the hierarchical tree without limit in levels.

6. Methodology

6.1. Design

One of the main goals aimed during the design of the database structure and the different user interfaces has been to achieve a high level of Flexibility and Abstraction.

Both characteristics should ensure that the database will be able to incorporate heterogeneous sets of data and the different users find appropriate perspectives to operate on them, minimizing the need of complex administration and maintenance.

The design of the whole system is based on a cognitive analysis. Considering that the conceptual elements underlying the specific terminology used in the context of space related projects and their intrinsic relations are not different that the general psychological structures characteristic of the human beings, the system intends to be able to contain and represent them without constraining to a specialized context.

The adequate adaptation of such a general tool to a specific user and functionality is responsibility of a user interface which layout and usage is dynamically determined by the role of the user, the nature of the tasks that he has to perform with it, and his personal preferences.

6.2. Implementation

When applying the described design to the specific application (initially to support the astronauts’ training administration, and later the planning and performance of mission operations), it was necessary to find a compromise between a highly abstract and incomplete model to a specific context.

The limitation in time and resources, and the expectations of frequent changes in the requirements, imposed an implementation strategy based on a Continuous Prototyping methodology. The software was completely developed on the site (EAC) and with a close integration of the users in the development process (providing requirements and feedback in real time).

Following an evolutionary strategy, the system was designed modularly, isolating functional blocks that could be delivered while new extensions were under development. Many areas are still open to grow, such as the possibility to integrate an expert system to detect conflicts and advise alternatives, the improvement of the communications architecture to extend the functionality available for remote users, etc. In some cases, this may be achievable by integrating commercial packages that may offer these services.

7. Conclusions

The experience gained during the development and usage of ATD and CAOS, and the demand already existing to use it for different purposes than its initial goal, demonstrate that the idea to establish a information infrastructure that can offer common services and flexible interfaces to a community working on complementary aspects is valid and very much needed in complex organizations such as the ESA.

Future versions of the system should develop more certain aspects related with its integration in a more efficient communications infrastructure to optimize its simultaneous usage by a heterogeneous and disperse community of users. For instance, the recent expansion of Internet and the World Wide Web open interesting opportunities for the publication of reports (Web Pages could replace printed reports and distribution by faxes), query of the database in real time and distributed maintenance (using interactive forms).

Sample Screens

Fig. 1: Timeline Chart
This tool shows the schedule of activities to be
performe by a group of individuals during a
certain period of time (typically one week).
It permits also to add new activities, and to
modify the schedule in an interactive way.

Fig. 2:  Catalog Browser
This tool offers a global overview of the
experiments and tasks to be performed
during the mission, allowing the crew
member to enter data at any level during
the different phases of the work.

Fig. 3: Session Editor
This form is used to edit all the information
about a given session of an activity, including
scheduling data (time, location, assignments),
additional task description, and to enter reports
on the activity inmplenetation.

Tags: ESA

Return to the index