What is Constellation?#

Constellation is a flexible, network-distributed control and data acquisition framework that provides a reliable, maintainable, and easy-to-use system that eases the implementation of new instruments.

It is built atop established open-source libraries for network communication (ZMQ) and data serialization (MsgPack), which provide a robust foundation and significantly reduce the required development effort. Unlike similar frameworks, Constellation does not rely on a central control server but is designed as a decentralized network whose components operate autonomously. The well-documented and clear interface for instrument control enables rapid integration of new devices and allows scientists to connect new instruments with minimal added effort and with the choice between an implementation in C++ or Python. The framework is designed with flexibility in mind and targets applications ranging from laboratory test stands up to small and mid-sized experiments with several dozens of connected instruments and large data volumes.

Naming Things#

In software, naming things is a notoriously difficult task as names both need to be “speaking” (describe what they refer to and what it does) and easy to remember (and type).

The name Constellation is borrowed from space flight, where satellite constellations operate with relatively large autonomy, transmitting data between them, and communicating with a ground control center which issues commands and polices the entire system. Consequently, vocabulary from space flight appears at different places in the framework and helps in clarifying functionality and intention. Examples are satellite, payload, safe mode, orbit or launch.

Other vocabulary used throughout the framework and this manual originate from commonly used terms of data acquisition systems in nuclear and particle physics:

  • A run designates a self-contained measurement or series of measurements. In Constellation, this corresponds to one transition of the finite state machine into the RUN state and out of it.

  • A trigger is an often hardware-based signal generated by a configurable logic from input measurements. It is used to rapidly decide whether to store a corresponding fraction of data or discard it. In particle physics a trigger signal could e.g. be generated from a coincidence of two devices measuring the passage of a particle.

  • A notoriously difficult term is event. In particle physics it is often used to describe the entirety of data belonging to a physical measurement such as the passage of a particle. Sometimes however it is also used when referring to the smallest portion of data produced by a given device. Constellation tries to avoid this term as much as possible, referring to messages when communication between nodes is concerned, and data records for any instrument data.

Any node in a Constellation network has a well-defined canonical name, consisting if its type and a user-specified name, separated by a dot, and a group name. These parameters are used to discover other nodes, and to communicate with them. These names are interpreted case-insensitively.

Components#

The Constellation framework knows three different types of components, namely satellites, controllers and listeners. Each of them has a different purpose and partakes in different communications.

Satellites#

These are the main constituents of a Constellation. They implement the code controlling an attached instrument, realizing data receivers, and any other component that should follow the Constellation operation synchronously. At the core of a satellite is its FSM which governs the state of the satellite and the attached instrument. Satellites are partaking in all Constellation communication protocols: They react to commands from controllers, listen to other satellites’ heartbeat messages, distribute log messages and telemetry data and transmit their recorded instrument data. A detailed description of the satellite is provided in the Concepts section.

Controllers#

This component represents the main user interface to a Constellation. Controllers can send commands to satellites via the control protocol, parse and interpret configuration files, and display the current state of the entire system. Graphical or command-line user interfaces typically are implemented as controller-type components, providing the possibility for both direct human interaction and scripted procedures.

Controllers are stateless, i.e. they are not a satellite of the Constellation. The main advantage of this approach is that multiple control interfaces can be active simultaneously, and that they can be closed and reopened by the operator, or even crash, without affecting the operation of the Constellation. The functionality of the controller in Constellation is described in detail in this chapter.

Listeners#

As the name suggests, components of this type only listen to communications of other components, typically via the monitoring protocol, and are entirely passive otherwise. Consequently, listeners are stateless and the Constellation is not affected by them appearing or disappearing during operations.

A typical example for a listener component is a log message interface which subscribes to logging information from satellites in the Constellation and displays them to the operator. The two use cases for a listener, logging and telemetry, are described separately in the logging chapter and telemetry chapter.