The NRT software stack includes 3 main layers. The upper level is known as SODC (Science Operations Data Centre). This layer is the user facing part of the stack. The lower part is referred to as the TLS (Telescope Level Systems). This is the part of the software stack that controls the telescope – for example controlling pointing and tracking etc.
SODC
The main role of the SODC is to allow scientists to submit observation requests. This happens through a ‘call for proposals’ and submissions are made through the NRT phase 1 system. After the proposal is accepted by a panel, the user can then provide all information required for the telescope to perform the observation. This system is called Phase 2.
The SODC also allows users to review the observation data once it has been taken by the telescope. This includes automated pipelines to process the raw data for each of the available instruments.
Additionally, the SODC allows NRT staff to monitor key systems on the telescope and perform some basic control of key systems to aid remote maintenance.
RCS
The RCS takes the role of the duty astronomer in a traditional telescope and its key role is scientific decision making.. However, in the case of the NRT, as a robotic, autonomous telescope these tasks are handled within the RCS which is software unique to the NRT and includes the intelligent scheduler which prioritises the list of potential targets based on the current conditions. This decision-making happens in real-time so the telescope can respond to alerts and triggers of ‘target of opportunity’ events.
The RCS communicates directly with the TLS to instruct the telescope what to observe and when to start/stop observing runs, for example at sunrise or sunset.
TLS
The final software layer is the Telescope Level Systems (TLS). This software is the link between the low-level hardware and the RCS. The TLS encompasses everything that directly controls hardware within the observatory and therefore handles the control of slewing, pointing, segmented mirror alignment, dome control and instrument interfacing. It contains the observing engine which allows targets requested by the RCS to be captured. The TLS is based on the GranTeCan control system (GCS). Use of the GCS as part of the NRT software stack allows ready-made functionality for key telescope behaviours including segmented mirror alignment. A major challenge for the software team is to ensure the TLS can be run autonomously like the Liverpool Telescope.
Another key benefit of the GCS is that devices can communicate with a wide variety of other systems and field buses. This means that both instruments and control hardware can be controlled directly without incorporating low-level control within the TLS.
Hardware control
The low-level control architecture is a distributed industrial network to ensure robust and reliable control and communication between the various systems. This is achieved by using industrial Beckhoff PLCs and an Ethercat data bus for real-time operation.
The Ethercat data bus is used to link all pieces of PLC hardware together, this dramatically cuts down on the number of control cables going through rotators and cable wraps and increases reliability with a ring topology giving cable redundancy. The PLCs are controlled by a Kubernetes Cluster using the OPCUA protocol. Telescope functional safety will be tightly integrated with Beckhoff Twinsafe allowing complete telemetry all the way up the software stack. This approach has been proven with the fold mirror mechanism prototyping described which has provided a framework for the other low-level control systems to follow so development can continue independently at the various partners without requiring the full system to be present.
There are several main systems requiring hardware control, in particular telescope moving parts;
