Mission Operations Control Center - Implementation Documentation¶

Author:	Mario Tambos

Introduction ¶

The present document means to laid the foundations for building all the MOCC‘s software. In doing so this document will specify how the subsystems and components defined in [1] are to be implemented.

This document is meant primarily for software developers. ERAS’s contributors wanting to write code for the MOCC should first read [1]. The contributor should then read this document, to familiarize him/her-self with the general implementation rules of the MOCC, and finally the document corresponding to the subsystem he/she wants to contribute for, if available.

If a detail is left out of this document, the reader should check the subsystem documents. Failing that, those details are left to interpretation.

Reference Documents ¶

[1] ++ Mission Operations Control Center - High Level Design Documentation

[2] ++ C3 Prototype document v.4

[3] ++ Software Engineering Practices Guidelines for the ERAS Project

[4] ++ Dachstein 2012 Mission Report

[5] ++ Morocco MARS2013 Mission Report

[6] ++ V-ERAS Project Description (2014 Release)

[7] ++ V-ERAS-14 Mission Report

[8] ++ TANGO Controls

[9] ++ EUROPA framework

[10] ++ PANIC - The Package for Alarms and Notification of Incidents from Controls

[11] ++ ERAS’ Tango Devices’ JSON Interface Definition

Glossary ¶

AI: Artificial Intelligence
ERAS: European Mars Analog Station
EVA: Extra-Vehicular Activity
GUI: Graphic User Interface
IMS: Italian Mars Society
MARS: Mission Asset and Resource Simulation
MOCC: Mission Operations Control Center
NDDL: New Domain Description Language
PANIC: Package for Alarms and Notification of Incidents from Controls
TBC: To Be confirmed
TBD: To Be Defined

Overview ¶

Section 1 deals with the choice of communication channels. Sections 2, 3, 4 and 5 explain implementation restrictions and considerations of the Planning, Operations, Configurations, Telemetry and Commands subsystems, respectively. Section 6. covers the validation and verification procedures. Finally, Section 7. deals with miscellaneous factors that need to be addressed or acknowledged when implementing the MOCC.

General considerations ¶

As with any other part of the ERAS project, the guidelines in [3] must be followed. If the need for non-Python code arises, the coding style recommended for the language should be used instead of PEP8.

1. Communication channels ¶

As explained in [3], the communication between the MOCC‘s components is done via TANGO (see [8]). All communication should be done though the TANGO bus. In no scenario should a component communicate outside the bus, with the only exceptions being components that act as a proxy to external services (databases, hardware sensors, external data providers, etc.); in these cases the communication between the proxy and the external service should fulfill the external service’s requirements.

In the case of databases, if the data store in the database can be accessed through a TANGO device server, direct access to the database should be avoided.

Unless otherwise specified, all components should be implemented as TANGO device servers.

2. Planning Subsystem ¶

The framework chosen to implement planning related tasks is EUROPA (see [4]). Among other things, this means that templates, instantiations as well as macros should be created using EUROPA’s NDDL and stored using EUROPA’s Plan Database, and that the AI assistants and UI s should be developed using EUROPA’s API.

The Mission Asset and Resource Simulation (MARS) (see [9], Section 7.5) should be also taken into account, specially when developing EVA-related planning agents. In cases where EUROPA and MARS conflict, EUROPA takes precedence.

The components in this Subsystem should present an abstraction layer over EUROPA’s and MARS’s APIs. Direct access from other Subsystems to said APIs should be avoided.

3. Operations Subsystem ¶

3.1. Execution Component ¶

The Execution component of this subsystem should use EUROPA’s API to execute the plans defined in the Planning Subsystem. However, no component from the Operations Subsystem should get the plans using EUROPA’s API directly, but through the Planning Subsystem’s components instead. This is done to maintain a clear separation between planning and execution/control, and to facilitate an eventual replacement of EUROPA, if necesary in the future.

3.2. Control Component ¶

The Control component should be able to understand NDDL, since the plan step’s expected outcomes will be defined in that language. This component should get the telemetry readings through the Telemetry Subsystem’s Internal Delivery component(s), and not through accessing the telemetry storage nor the sensors directly. Since the underlying framework is TANGO, this should involve making a request to the TANGO device server in charge of managing the sensor of interest.

3.3. AI assistants ¶

At the time of this writing, two types of AI assistants are foreseen:

Anomaly Detectors: these assistants analyze telemetry from all sensors involved in a plan instance, in search for deviations that could compromise the plan. The method of analysis is sensor-dependant, but all anomaly detectors should use a uniform interface to provide their analysis. This means defining an appropriate “Alarm” data structure. The use of PANIC (see [10]) is advised whenever possible.
Corrective Measures Assistants: these assistants help correct deviations in the plans. They should make use of the tools offered by EUROPA. No other requirements apply at the time.

3.5. User Interfaces ¶

The UI s in the Operations Subsystem should be organized hierarchically in a tree, as shown in Figure 1. Each node in the tree should be a UI widget, which performs the following functions:

Gathers data from a data source.
Shows a user-defined representation of the data gathered.
Provides user-defined aggregations of the data gathered, which can function as a data source.
Shows a user-defined representation of the aggregations defined.

Figure 1. The Operations UIs hierarchy¶

The aggregations are functions over one or all data sources queried by a node. So, if a UI-node Z gathers data from data sources A, B and C, possible aggregation functions could be, for instance:

Maximum over the last 30 seconds of A.
Average over the last hour of B.
Instantaneous minimum of A and C.
Average over the last 45 minutes of the cross-entropy of B and C.

In the tree, the leaves should gather data exclusively from telemetry sources and AI assistants, whereas inner nodes should gather data preferentially from lower tree nodes and AI assistants. The idea is to build abstraction layers to facilitate control and decision making by the Operation Subsystem’s users by giving enough information while avoiding cluttering. This way, the users in charge of physical devices can see a detailed view of their devices, users in charge of groups of devices can see the status of the whole group, the the person in charge of the whole mission can see the global status.

4. Configurations Subsystem ¶

4.1. Devices ¶

Based on the services provided by TANGO, the Devices component should extend TANGO’s capabilities by offering an interface to find devices based on certain criteria, e.g.:

Devices able to go outside.
Devices able to load cargo.
Devices able to measure radiation.
Etc.

Beyond the information about a device already provided by TANGO (type and name of variables, signature of commands), in the case of devices that offer JSON-encoded variables and/or commands (see [11]), this component should also make available the schemas of said variables and commands.

NOTE: This last part could be implemented by requiring all ERAS' TANGO
devices to implement a commands that provides the schema information, as
suggested in [11].

4.2. Crew ¶

Similarly to the Devices component, this component should offer information about the crew members physical well as mental characteristics, e.g.:

Personal information: name, nationality, place of origin, etc.
Biomedical statistics: age, weight, medical conditions, etc.
Areas of expertise: mechanical engineering, geology, medicine, etc.
Psychological characteristics: leadership, patience, stress tolerance, etc.

4.3. Macros ¶

Combining TANGO and EUROPA, this component should offer a repository for macros. A user should be able to retrieve the list of macros that involve a certain device or crew member. A user should also be able to obtain the list of devices and crew members involved in a certain macro.

To facilitate the process of macro building, a UI should be developed.

5. Telemetry and Commands Subsystems ¶

5.1. Telemetry Subsystem ¶

The Telemetry Subsystem consists of three components – Acquisition, Storage and Delivery – in charge of reading telemetry from sensors, storing it in a database and making it available to whoever needs it. In particular, the delivery can be in real-time, in the case when the Subsystem delivers telemetry as it is obtained; or historic, in the case when previously obtained and stored telemetry is needed.

There are two types of subcomponents in each the Acquisition and Delivery components. The first is the acquisition from and delivery to internal services, i.e., services that are part of ERAS, which occurs using the TANGO bus.

The second is the acquisition from and delivery to external services, i.e., databases, hardware, third-party services, etc., which occurs using whatever media the external services in question require. However, when the information from the external service is requested by another Subsystem, the request is processed through the TANGO bus, by developing a proxy (a TANGO device server) for the external service needed.

Finally, the Storage component should provide an interface for saving telemetry to a database, as well as retrieving it. Storage requests for this component should not be directly made from outside the Telemetry Subsystem. One possibility to achieve this is to implement it as a software library. However, retrieval request should be accepted from outside sources, though the TANGO bus.

5.2. Commands Subsystem ¶

This Subsystem is very similar to the Telemetry Subsystem. The difference lies in principle in the information flow; whereas the Telemetry Subsystems mainly gathers information from external services (sensors) and delivers it to internal services (chiefly the Operations Subsystem), the Commands Subsystem gathers information only from the Operations Subsystem, and delivers it to internal as well as external services (actuators, crew members, etc.).

5.3. Implementation ¶

Figure 2 shows a diagram of the internal structure of a TANGO device server that is able to gather and provide telemetry, as well as accepting and delivering commands. Any devices involved in operations should follow this structure.

MOCC/docs/images/MOCC_Telemetry-Commands_Implementation.png

Figure 2. Telemetry and Commands? Modules Implementation¶

All commands received should be both stored in the Commands Database and delivered to the appropriate external recipient (if needed).

Telemetry should be gathered at the instant the request is received, if the request is for instant telemetry, or retrieved from the Telemetry Database or TANGO attribute history buffer (whatever option is most appropriate).

6. Validation and Verification Procedures ¶

TBD

7. Special Considerations ¶

To avoid work duplication, a spreadsheet matching components to actual software modules should be written and linked to this document. The spreadsheet should also indicate whether a component is completely implemented, and if not, what is missing.