STELLA Control System (SCS)

The STELLA control system is a generic software package capable of controlling any telescope capable of autonomous observing, thus making it what is in general astronomical terms called a robotic telescope. It is writtn in 100% Java and currently prepared to be published under the Apache 2.0 licence. A few copyright issues on a few classes have yet to be resolved, but many parts are already royalty free.

Generic?

We consider SCS generic, because its design was not lead to make it applicable for a certain telescope, but to drive an optical telescope that is able to commence different observations, as we planned from the start on to have a spectroscopic and an imaging telescope under a single operating system. We started considering different subunits that may constitute a telescope and how they should communicate amongst each other. This is shown in the figure below. Zooming into the tasks of the central node, the SCS, is shown in the figure next to it.

stella-network.png

General layout of a hierarchial network of components in a robotic telescope. Commands are mainly routed through the central node, though direct peer-to-peer communication is allowed (see the direct connection between adapter and telescope, symbolizing an autoguider). Errors are always routed through the central node. The weather conditions are routed through to the central node to allow proper action for protecting the instrument. Note that for fail-safety reasons, systems are to be preferred where protection of the instrument can commence at any time, regardless of the state the system is in.

scs_color.png

Inside SCS: The scheduler pick a single target out of a pool of possible objects. This is passed to the sequencer, which loads an observing workflow as a template out of another collection. The sequencer combines data from the target definition with the workflow template to yield an executable flow of commands. These are passed in proper timing to the sub-system handlers that communicate to outside devices via TCP/IP.

So, what has to be done in order to use SCS on a robotic telescope (this can of course only be a very crude outline)? First, identify which subsystems you may want to serve. This will be a telescope and a detector, at minimum. If you have a device handling acquisition and proper guiding, you will have something like an adapter; if your instrumentation either has an independent focus or requires some special calibration procedures you will have something loosely termed spectrograph in the figures. If your building control is capable of serving commands, add it too (a dome will most likely have to follow the telescope pointing, whilst a roll-off roof might be designed to work fully autonomous, only slaved to a weather station. Then, identify which commands your subunits are capable of receiving. Note that sometimes it may be appropriate to combine some aspects belonging to the instrument, like a filter wheel, with the detector. This again depends on your actual setup. Then, very thoroughly go through the individual steps and their proper dependency amongst each other to create a valid observing sequence. Code this into an XML-formatted template. If commands are missing, create them as new command classes. Now you are almost done. Describe your targets (default as an XML-formatted file) with proper references such that the sequencer can fill in the required information. Add constraints and scheduling rules to your target definition to allow the scheduler (it uses a dispatcher schema) to pick the targets when appropriate.

Last update: 23. August 2021