Mount control system of the ASTRI SST-2M prototype for the Cherenkov Telescope Array

(1)

2016

Publication Year

2020-05-13T07:41:13Z

Acceptance in OA@INAF

Mount control system of the ASTRI SST-2M prototype for the Cherenkov

Telescope Array

Title

ANTOLINI, ELISA; TOSTI, Gino; Tanci, Claudio; Bagaglia, Marco; CANESTRARI,

Rodolfo; et al.

Authors

10.1117/12.2230898

DOI

http://hdl.handle.net/20.500.12386/24771

Handle

PROCEEDINGS OF SPIE

Series

9913

Number

(2)

PROCEEDINGS OF SPIE

SPIEDigitalLibrary.org/conference-proceedings-of-spie

Mount control system of the ASTRI

SST-2M prototype for the Cherenkov

Telescope Array

Antolini, Elisa, Tosti, Gino, Tanci, Claudio, Bagaglia,

Marco, Canestrari, Rodolfo, et al.

Elisa Antolini, Gino Tosti, Claudio Tanci, Marco Bagaglia, Rodolfo Canestrari,

Enrico Cascone, Giorgio Gambini, Giuliano Nucciarelli, Giovanni Pareschi,

Salvo Scuderi, Luca Stringhetti, Andrea Busatta, Stefano Giacomel,

Gianpietro Marchiori, Cristiana Manfrin, Enrico Marcuzzi, Daniele Di Michele,

Carlo Grigolon, Paolo Guarise, "Mount control system of the ASTRI SST-2M

prototype for the Cherenkov Telescope Array," Proc. SPIE 9913, Software and

Cyberinfrastructure for Astronomy IV, 99131J (8 August 2016); doi:

10.1117/12.2230898

Event: SPIE Astronomical Telescopes + Instrumentation, 2016, Edinburgh,

United Kingdom

(3)

Mount Control System of the ASTRI SST-2M prototype for the

Cherenkov Telescope Array

Elisa Antolini

1,2

, Gino Tosti

1,2

, Claudio Tanci

1,2

, Marco Bagaglia

1

, Rodolfo Canestrari

2

, Enrico

Cascone

7

, Giorgio Gambini

1

, Giuliano Nucciarelli

1

, Giovanni Pareschi

2

, Salvo Scuderi

8

,

Luca Stringhetti

2

for the ASTRI Collaboration

3

and the CTA Consortium

4

,

Andrea Busatta

5,6

_{, Stefano Giacomel}

5,6

_{, Gianpietro Marchiori}

5,6

_{, Cristiana Manfrin}

5,6

_{, Enrico}

Marcuzzi

5,6

,

Daniele Di Michele

9

, Carlo Grigolon

9

, Paolo Guarise

9

.

1

_{Department of Physics and Geology, University of Perugia – Via A. Pascoli 06123 Perugia (Pg)}

Italy

2

_{INAF-Osservatorio Astronomico di Brera – Via Bianchi, 46 23807 Merate (Lc) Italy}

3

_{http://www.brera.inaf.it/astri/}

4

_{http://www.cta-observatory.org}

5

_{EIE Group s.r.l. - Via Torino, 151/A, 30172 Venezia Italy}

6

_{EIE and Galbiati Groups}

7

_{INAF-Osservatorio Astronomico di Capodimonte – Salita Moiariello, 80131 Napoli Italy}

8

_{INAF-Osservatorio Astrofisico di Catania – Via S. Sofia 78, 95123 Catania Italy}

9

_{Beckhoff Automation Srl – Via L. Manara 2, 20812 Limbiate (MB) Italy}

ABSTRACT

The ASTRI SST-2M telescope is an end-to-end prototype proposed for the Small Size class of Telescopes (SST) of the future Cherenkov Telescope Array (CTA).

The prototype is installed in Italy at the INAF observing station located at Serra La Nave on Mount Etna (Sicily) and it was inaugurated on September 2014.

This paper presents the software and hardware architecture and development of the system dedicated to the control of the mount, health, safety and monitoring systems of the ASTRI SST-2M telescope prototype.

The Mount control system installed on the ASTRI SST-2M telescope prototype makes use of standard and widely-deployed industrial hardware and software. State of the art of the control and automation industries was selected in order to fulfill the Mount-related functional and safety requirements with assembly compactness, high reliability and reduced maintenance. The software package was implemented with the Beckhoff TwinCAT version 3 environment for the software Programmable Logical Controller (PLC), while the control electronics have been chosen in order to maximize the homogeneity and the real-time performance of the system.

The integration with the high-level controller (Telescope Control System) has been carried out by choosing the Open Platform Communications Unified Architecture (UA) protocol, supporting rich data model while offering compatibility with the PLC platform.

In this contribution we show how the ASTRI approach for the design and implementation of the Mount control system has made the ASTRI SST-2M prototype a stand-alone intelligent machine, able to fulfill requirements and easy to be integrated in an array configuration such as the future ASTRI mini-array proposed to be installed at the southern site of the Cherenkov Telescope Array (CTA).

CCC code: 0277-786X/16/$18 · doi: 10.1117/12.2230898

Proc. of SPIE Vol. 9913 99131J-1 Downloaded From: https://www.spiedigitallibrary.org/conference-proceedings-of-spie on 27 Apr 2020

(4)

M1 M2

PMC

1. INTRODUCTION

The ASTRI SST-2M is designed to be a stand-alone active telescope, in which all the components have to be managed by specific controllers in order to perform therequired functionalities.

As shown in Figure 1 the subsystems of the telescope for which a controller has been developed are:  The mechanical structure (including the kinematic chains and the drives).

 The optical assembly (M1 and M2).  The Cherenkov camera.

 The auxiliary instrumentation mounted on the structure of the telescope, dedicated to the absolute end-to-end calibration. This comprises the Pointing Monitoring Camera (PMC), the Sky Quality Meter, SQM and the complex multi-pixels photon detectors system UVscope/UVSiPM [4][5].

Figure 1. ASTRI SST-2M prototype is composed by a set of subsystems: the mechanical structure, the primary mirror (M1), the secondary mirror (M2), the Cherenkov camera and some auxiliary instrumentation such as the Pointing Monitor Camera (PMC).

The telescope controllers are responsible for controlling the pointing and tracking of the mount, the position, tilt and Active Mirror Control (AMC) [2] of the primary and secondary mirrors, the functionalities of the Camera [3] detection and for switching on-off all the subsystems.

As a result the ASTRI SST-2M is composed of a complex set of devices and the control systems are responsible for running them correctly executing commands received from the external controllers (Telescope Control System and Graphical User Interfaces), whose task is the coordination of the various subsystems.

The control hardware and electrical communication components are grouped following their functionality, and they are installed in two electronics cabinets, mounted on the telescope and held by the Azimuth Fork: the High Power Cabinet (HPC) contains the high voltage power supply for the servo drives and motors, while the low voltage (24 V) control electronics is installed in the Low Power Cabinet (LPC).

The Mount is the mechanical structure that supports the optical assembly, and is designed to allow for pointing and tracking of the telescope on the sky. The design of the Mount is based on the requirements summarized in Table 1, all compliant with the requirements of the CTA Small Sized Telescopes [1].

The ASTRI-SST-2M telescope adopts an altitude-azimuthal design permitting for the Azimuth a rotation range of ± 270°, starting from the East direction. The mirror dish is mounted on the azimuth fork, which allows rotation around the elevation axis from -1° to +90°.

In order to guarantee the maximum safeguard for the human operator during the maintenance and commissioning activities and for protecting the mechanical structure during the normal operation, a chain of interlock devices (drive limit switches, halt buttons and proximity switches) has been included in the design of the prototype. The security system, the safety procedure functionalities developed for ASTRI SST-2M meet the CTA requirements [1] and follow the international directive and norms related to safety (IEC 61800).

(5)

Description Value

AZ angular range with no limit switch intervention EL angular range with no limit switch intervention

Maximum AZ speed Maximum EL speed

Positioning accuracy of the main axes on all angular range Tracking accuracy of the main axes

±270 °

-1°upto90°

4.5 ° /sec 2 ° /sec <12 arcsec <6 arcmin

Table 1. Technical features of the Mount of ASTRI SST-2M prototype, based on the CTA requirements for SSTs [1].

From ASTRI point of view, the “Mount control” includes not only the control of the Mount structure, but also the controllers dedicated to the health and safety systems of the telescope.

In this framework, the control of the Mount devices is performed by two sets of dedicated electronics and software packages able to perform all the logical operations and to monitor and control the hardware:

 The Telescope Control Unit (TCU), running the Mount Control Software (MCS), provides for the control of the motion of the telescope. This includes the Azimuth and Elevation axes control, the pointing/tracking algorithms with the conversion of sky to axes coordinates and all the procedures needed for the maintenance, testing and calibration activities.

 The Telescope Health Control Unit (THCU), running the Telescope Health Monitoring Software (THMS), is in charge of the execution of safety procedures, handling I/O signals (e.g. interlocks and limit switches), health monitoring of the telescope and switching on/off the telescope components (e.g. camera, mirrors).

2. TECHNOLOGY OVERVIEW

2.1 General Considerations

To exploit all the features of the telescope structure, performance of the control system is a critical point to be considered. In particular the pointing and tracking performances depend on the choice of the drive system, on the control electronics, and on the software controllers, which have been selected taking into account the following considerations:

 Compactness: The selected PLCs, together with the related I/O modules of the Mount Control, are small, offering considerable space saving, and are fully integrated in the telescope, being contained in the two electronics cabinets attached to the telescope.

 Software dependability: the PLC is programmed in a set of domain-specific languages (standardized as IEC61131-3) which results in very efficient programming, while the PLC run-time system ensures reliable execution of the code in real-time.

 All-in-one solution: the PLC executes the control logic in real-time and offers the remaining CPU time to the operating system, the Human Machine Interface (HMI) application, and an OPC Unified Architecture (UA) [10] communication server.

 Extensive development environment: the development environment comprises a set of features able to facilitate the implementation of the code, the debugging and possibly HMI applications.

 Cost savings: the required manpower is considerably less compared to more traditional (simple PLC plus the related PC) approach if the PLCs selected come with an extensive development environment allowing the implementation and the debugging of the code in a very short time frame. Furthermore maintenance of the hardware and software platform is effectively outsourced to the PLC manufacturer.

Based on these features the so called PC-based control technology was selected for the ASTRI SST-2M Mount control system. This comprises Beckhoff [6] industrial PCs and software Programmable Logical Controllers (PLCs) using the TwinCAT 3 (TC3) environment as development platform.

(6)

The Ethernet Control Automation Technology (EtherCAT) is the protocol chosen for the internal communication between all the hardware devices of the Mount control system, for its very high real-time performances.

This solution offers good reliability, compactness and low maintenance for the electronics of control, ensuring high real-time performances and a simplified environment for the development of real-real-time control and safety applications.

2.2 Engineering development and Runtime environment platform

The TwinCAT 3 (TC3) environment is the implementation of the EtherCAT master that provides deterministic cyclic access to field inputs and outputs as well as to variables in the traditional IEC 61131-3 languages.

TC3 is a software system which provides a modular and flexible software framework of the automation field, making available important integrated motion functionalities, in order to reduce the engineering effort necessary to control the most complex machines: all the real-time components are encapsulated in modules which are managed by the run-time system .

This philosophy has been implemented both in the engineering (eXtended Automation Engineering (XAE)), providing an environment integrated as an extension of the common Microsoft Visual Studio software development environment, and into the runtime (eXtended Automation Runtime (XAR)).

For the ASTRI Mount control purpose the modules used were the PLC, the Numerical Control (NC) and the Safety. The PLC is a module that offers a series of PLCOpen functions for the motion control, based on IEC 61131-1 standard languages. It provides for a powerful development environment with reduced code size programs, with convenient editors and a fast, effective compiler, so that the development cycle for the creation even of large PLC programs of several megabytes can be short. The PLC is the main module through which all the functionalities of the Mount software package were implemented.

TwinCAT NC PTP (Numerical Control Point To Point) includes axis positioning software (set value generation, position control), an integrated software PLC with NC interface, an operating program for commissioning and an I/O connection to the axes through various fieldbuses. TwinCAT NC PTP replaces conventional positioning modules and NC controllers. The controllers that are emulated by the PC cyclically exchange data with drives and measuring systems via the fieldbus.

We used this TwinCAT module for the motion control of the Azimuth and Elevation axes in the MCS package.

The TwinCAT Safety PLC is a software-based safety controller. It enables an universal, scalable and simplified solution for safety technology. The TwinCAT Safety PLC supports all steps of safety related software development including design, implementation, verification and validation. The TwinCAT Safety PLC is approved for applications up to Safety Integrity Level 3 IEC 61508 or DIN EN ISO 13849-1.

The objects (modules) generated can exchange data with each other and call each other independently of the language they were written in. The TwinCAT System Manager has been integrated into the development environment. This way, only one software is required to configure, parameterise, program and to diagnose automation devices.

The TwinCAT 3 Runtime offers a real-time environment, where TwinCAT modules can be loaded, executed and administered. The individual modules do not need to be created with the same compiler and thus can be programmed independently and by different developers. The generated modules can be called cyclically from tasks or by other modules.

Among the features made available from the TC3 there is the support for high-level languages; in addition to the classic PLC Structured Text IEC 61131-3, such as C/C++ for real-time applications. This functionality has not been used for the Mount control of ASRTI SST-2M, but it is planned to be exploited for the tracking trajectory implementation of the future ASTRI SST-2M telescopes of the mini-array (see Section 4.2).

3. MOUNT CONTROL HARDWARE ARCHITECTURE

The Mount Control Hardware (MCH) assembly includes all the electronics and hardware parts needed to drive the telescope safely to any accessible sky position during the commissioning, testing, maintenance operation and observing phases.

All hardware devices for the control and management of the Mount are based onPLCs and have been carefullychosen in order to have high performance in a very compact assembly.

The main MCH components are:

 The Drive system, which is able to move physically the axes of the telescope.

(7)

 The TCU (Telescope Control Unit), which is in charge of the monitoring and control of the major servo systems (Elevation and Azimuth).

 The Safety PLC and THCU (Telescope Health Control Unit), which are in charge of the interlock chain management installed on the telescope and of the monitoring of the health of all the subsystems installed.  The Servo drives, which are the high-power electronics that deliver power to the motors.

The TCU and THCU are Beckhoffindustrial PCs mounted in the LPC cabinet that offer high reliability and reduced maintenance, while the Safety PLC electronics is integrated into the hardware configuration of the THCU, so it is considered as part of it.

The architecture of the MCH assembly and its physical interfaces are sketched in Figure 2.

The interfaces from the electrical point of view power the BeckhoffPCs directly by the 24V Power Distribution Unit (black solid lines), while the Safety PLC is powered by a specific Beckhoff module (EL9410).

The switches and emergency push buttons belonging to the interlocks chain are connected to the Safety PLC modules through a 24V power single cabling, while the telescope subsystems and the Stow Pin control devices are connected to the THCU via a double power cabling, in order to have two sets of signals, one for the monitoring and one for the control.

Figure 2. Mount Control Hardware architecture and connection paths. Read the text of this section for more information.

The three motors dedicated to the motion of the telescope (two for the Azimuth and one for Elevation axes) and powered by the 3-phase high voltage, are connected to the servo drives (black dotted lines), installed inside the HPC cabinet, while the two encoders are directly linked to the TCU (black dashed line). The Servo drives are connected also to the Safety system through a dedicated emergency cabling (red dotted double lines), which is in charge to disable the voltage to the motors when necessary, and thus stop them immediately (Safe Torque Off function, see Section 5.3).

Regarding the communication interfaces, the Beckhoff PCs are connected to the telescope internal network through a switch (green dashed dotted lines), and thus they are remotely accessible from the control room or externally by authorized users only. The telescope internal network is connected through a fibre optic bundle to the main ASTRI networking devices installed in the server/control room.

(8)

_ii

The Servo Drives are accessible directly to the TCU via the Ethernet Control Automation Technology (EtherCAT, blue dashed double dotted line) communication protocol, through a dedicated Ethernet cabling passing through the two cabinets.

3.1 The Drive System and Positioning Encoders

The ASTRI SST-2M drive components provide an independent motion control of the Azimuth and Elevation axes. The Azimuth axis motion is powered by two SEW [7] synchronous servomotors (see Figure 3 (a)) CM71S, located at 180° to each other. The two motors are coupled together in a master-slave configuration, controlled in differential torque mode in order to eliminate backlash and hence guarantee good motion accuracy under all operational conditions. The master motor is equipped with a brake and a back shaft.

(a) (b) Figure 3. Azimuth (a) and Elevation (b) servo motors.

The motion in the Elevation axis is possible with one SEW CM90L servomotor (see Figure 3 (b)) equipped with brake and hand release.

For ASTRI SST-2M the Azimuth position measurement includes a scale tape angle encoder (ERA7400C), with 90000 line counts on the strip, and four scanning heads ( ERA7480), provided by Heidenhain [8]. The scanning heads are displaced inside the base along a circle spaced of 90°. This configuration provides for an accuracy of ~2.4".

The Elevation positioning is performed by an Heidenhain RCN2580 absolute encoder, equipped with 16384 lines, yielding a resolution of ~2.5".

3.2 Telescope Control Unit

The Telescope Control Unit (TCU) is the computer which runs the software modules dedicated to the drive control of the axes, to the astrometric computation for the pointing/tracking procedure and to the procedure needed for the maintenance and testing activities of the telescope.

In order to have the necessary computational performance a 4-core Beckhoff Industrial PC C6930-0040 was chosen, completed with Windows 7 64 bit system. The 4-core system is composed of a 3rd Generation Intel Core i7 3610QE processor, together with 8GB Random Access Memory (RAM).

All the basic functionalities developed for the motion control of the telescope are physically managed by a series of Beckhoff modules (see Figure 4 (a)) connected to the TCU through an EtherCAT master coupler EK1100, which converts the passing telegrams from Ethernet 100BASE-TX to E-bus signal representation (EtherCAT).

The TCU Hardware architecture (outlined in Figure 5) comprizes two EL1808 Standard Input modules, dedicated to the management of an Handset pushbutton device (dedicated to the local motion control of the telescope axes) and to the monitoring of the Azimuth and Elevation proximity switches signals.

The EL5032 EnDat Encoder module is the physical interface for the absolute encoder of the Elevation axis, while the four EL5021 Sin/Cos Encoder devices manage the incremental encoder heads of the Azimuth axis. The Azimuth and Elevation synchronous Servo Motors are operated by three SEW MOVIAXIS (MXA) multi-axis servo drives, one for each motor, and the units are powered by one SEW (MXP) power supply module. The SEW modules are assembled together in an EtherCAT-based system bus configuration (see Figure 4 (b)) and are considered part of the TCU hardware

(9)

configuration, since each drive is connected directly to the TCU through the EtherCAT cable, and is seen as a module in the TC3 environment.

The physical interfaces between the devices involved in the configuration are all based on the EtherCAT protocol, this guarantees homogeneity and compatibility of real-time communication.

(a) (b)

Figure 4. (a) TCU Hardware Configuration: the TCU Industrial PC (left) is connected through the EtherCAT master coupler to the set of Beckhoff ‘modules which interface with the TCU-related hardware (right). (b) SEW Servo drives configuration: The power supply module (left) provides the high voltage to the three servo motors of the telescope (two for Azimuth and one for Elevation), which are operated by the related multi-axis servo drive.

Figure 5. TCU system hardware configuration. Read the text of this section for more information.

3.3 Telescope Health and Safety System

The Telescope Health Control Unit (THCU), shown in Figure 6 (a), is composed by a Beckhoff compact PC CX9020 with a Windows Embedded Compact 7 operating system and 1 GHz ARM CortexTM-A8 CPU. The THCU is the PC which runs the software dedicated to the monitoring and control (switch on/off) of the telescope subsystems (Camera,

(10)

Mirrors, etc.) and to the implementation of the interlocks logic chain, so it has to be the first unit to be powered on during the start up procedure of the telescope.

As for the TCU, the functionalities of the THCU are implemented through a series of Beckhoff modules (Figure 6 (a)). The hardware architecture, sketched in Figure 7, is composed of two 8-channel digital input terminals EL1808 to monitor the status of the telescope devices and three 8-channel digital output terminals EL2808 to power on/off the subsystems and to command the insertion and extraction of the Stow Pins.

The hardware configuration for the health of the telescope includes also the EL3403 module dedicated to the measurement of the consumption parameters of the 3-phase high voltage. In this way quantities such as the current, voltage and active power of each phase can be cyclically monitored and reported by the THCU.

The THCU is also in charge of managing the interlocks devices, through a series of dedicated modules (see Figure 7) compliant with the international standard for safety (IEC 61508 SIL 3).

(a) (b)

Figure 6. The THCU hardware configuration (a) is composed of a Beckhoff compact PC CX9020 (left) with the related digital I/O modules (right) and it comprises also the Safety PLC modules (b).

The Safety PLC (see Figure 6 (b)) is functionally part of the THCU and it consists of a Beckhoff Safe PLC (EL6900), one 4-digital output module (EL2904) and eight 4-digital input modules (EL1904). The physical architecture provides for switches and mushrooms to be connected to the Beckhoff input safe modules through a 24 V wiring system. The output terminals are directly linked to the servo drivers safety clamps in order to activate the required safety Safe Torque Off (STO) function based on the logical status detected from the devices.

(11)

Figure 7. THCU and Safety PLC hardware architecture including connections with telescope subdevices and interlocks chain. Read the text of this section for more information.

4. THE MOUNT CONTROL SOFTWARE DESIGN

In this section we present the architecture and implementation of the two software modules dedicated to the complete motion control, health and switch on/off of the telescope components and the interlocks chain management: the Mount Control Software (MCS) and the Telescope Health Monitoring Software (THMS), which compose the Mount Software (MS) package.

The design and implementation of each software module have been carried out starting from the related Use Cases definition, based on the operational procedures and user requirements described in [9].

The Mount Software Use Cases are sketched in Figure 8 and summarize all the functionalities that the user, defined here as an external controller, is able to invoke:

 Initialize the systems and bring them to their operative status;

 Perform the state transitions in order to bring the system into the required configuration;  Switching on-off of the devices inside the telescope and monitoring of their status;  Perform the motion of the telescope in position (ABSOLUTE) or velocity (JOG) control;  Park the telescope in safe position;

 Insert or extract the Stow Pins;

 Perform a diagnostic of the system if an anomaly occurs;  Perform a tracking or a pointing of a source.

(12)

USER -,C-MOVE ABSOLUTE> - MOVE JOG-, C PAIM ->CERROR INFO> CS ACTION

1

<GO ONLINE) <GOLOAOEO> MMCS GOSTANOGV S MOVE IN ABSOLUTE S MOVE IN JOG PARK TELESCOPE

C

FAILURE ONGNOSTCS USER

>c

zowN> THMS ACTION THCI

r

TeIescene Control Sy!

TCU

CiiKiliccimg Gl.

(a) (b) Figure 8. MCS (a) and THMS (b) use cases diagrams.

4.1 General Architecture and Communication Interfaces

The general architecture of the MS package is presented in Figure 9.

The MCS is the module hosted by the TCU and is dedicated to the monitor and control of telescope motion, which includes the axes control, the pointing-tracking algorithms and the conversion of sky coordinates to axes coordinates. Furthermore, this package implements the procedures needed for the maintenance, tests and calibration activities. The THMS runs on the THCU and it is the module in charge of supervising the status and of switching on/off all the telescope sub-devices (e.g. Camera, High Voltage, Motors, TCU). It handles interlocks and limit switches I/O signals and manages the logic chain of the safety procedures.

Although the MCS and the THMS are running on physically separated PCs and can be independently executed, they can exchange data in real-time over the telescope network, through the Publisher/Subscriber methods provided by Twin- CAT real-time network protocol. This is a very flexible and fast Ethernet-based mechanism of network variable sharing which facilitates the development of automation procedures distributed over several controllers.

Figure 9. Mount Software (MS) general architecture. The MCS and THMS are the packages running into the TCU and THCU PCs. They can share information thanks to the Publisher/Subscriber protocol, while they are accessible from the external controller (TCS) through the OPC UA protocol.

The MCS and THMS make available all the monitoring and control points through the OPC-UA [11] server.

The information is then used by the TCS high-level controller and by the Graphical User Interfaces (GUIs) either for normal operation activities or for maintenance, commissioning and testing purposes.

A detailed description of the TCS and GUIs can be found in [12] (these proceedings).

(13)

In order to expose the address space of the MCS and THMS PLCs, the TwinCAT OPC UA software package was installed in the TCU and THCU PCs. The OPC UA TwinCAT server automatically maps programs, function blocks and variables to their standard representation as defined by the OPC UA specifications [11].

This effectively converts each PLC with nearly no effort into an OPC UA server, offering standardized data access and secure communication, making available to the high-level controller a set of commands and monitoring variables as defined in specific Interface Control Documents (ICDs).

4.2 Mount Control Software

The MCS functionalities were implemented by three different PLC modules, each running as independent software PLC tasks in the TwinCAT real-time system, and one NC module for axes control (see Figure 10 (a)).

In this configuration each PLC task runs on a dedicated core of the TCU quad-core CPU:

 The Mount Axis Control (MAC) is the module in charge of setting up the control of the hardware (motors, encoders) for the axes motion and to manage the servo loops.

 The ASTRO module contains all the astrometric routines, developed using the PLC IEC 61131-3 ST language, and based on the USNO NOVAS C package [13]. ASTRO is able to perform the astrometric coordinate transformations required for pointing and tracking of the telescope.

 The Mount Control Software (MCS) is the master software module dedicated to the monitoring and control of all the main functionalities of the telescope including those need for maintenance, testing and calibration activities. It also provides the interface towards the external high-level controllers implementing an OPC UA server.

The TC3 environment allows us to define some Input/Output global variables in each PLC task in order to share them with other PLC tasks running on different CPU cores (see Figure 10 (b)). Using this mechanism the global output variables of MAC are linked to the specular global input variables defined in the MCS and vice versa. The same variable exchanging mechanism is used for the MCS-ASTRO interface. This method is very efficient and allows us to exchange real-time information to synchronize and coordinate the different operations delegated to the three modules during the execution of complex procedures related to the full control of the telescope mount.

The MAC provides all motor and encoder information to the MCS for the correct mechanical (e.g. motor temperature, torque, current) and motion (e.g. position, velocity, acceleration, deceleration, direction) operations of the telescope. On the other hand, the MCS sends the correct motion parameters for pointing or tracking of a target and all the commands needed for the correct operational behaviour of the motors, based on the specific application used (see Section 5.1 for more details).

It has to be noted that for the future ASTRI SST-2M telescopes of the mini-array [19], the astrometric routines executed now by ASTRO, will be performed by integrating the SOFA C library [18] directly into the MCS solution, thanks to the C/C++ module provided by TwinCAT 3.

This particular type of architecture has been chosen in order to optimize the utilization of computational resources of the TCU, distributing evenly the computational effort to sustain. That is the functionalities of the MCS package has been divided into three PLC which can be executed independently and simultaneously, allowing a significant increase of the real-time performance of the system with respect to execute all the package through only one PLC and core.

(14)

Search Solution Explorer (Ctrl +è) 1 Solution'TCU' (1 project) i TCU D al SYSTEM ® MOTION ® NC -Task 1 SAF a NC -Task 1 SVB Image Tables ® Objects Axes D a* Axis 1- Master D art EL Axis D art Axis 3 J PLC MAC MCS W] ASTRO ,; ASTRO Project 2 ASTRO Instance uO Devices

D Device 1 (EtherCAT Automation Protocol) D Device 5 (EtherCAT) D ¡, Mappings TCU TCS (OPC UA) OUTPUT OUTPUT INPUT INPUT THCU (Ethernet) ASTRO (a) (b)

Figure 10. Mount Control Software TwinCAT project (a) and its general architecture (b). The MCS package is composed by three different PLCs that can be executed independently, while maintaining the possibility of sharing information.

4.3 Telescope Health Monitoring Software Design Description

The THMS architecture is sketched in Figure 11 (b), while the implemented TwinCAT project is presented in Figure 11 (a). One PLC task is able to manage all the monitoring (violet dotted arrows) and control (blue large dashed arrows) functionalities, while the Logic chain is implemented through the dedicated Safety PLC module provided by the TC3 solution (see Figure 11 (a)).

Both tasks run with the same execution cycle of 2 ms, and they are completely independent: the THMS runs in the TwinCAT runtime environment installed in the THCU PC, while the SAFETY logic runs into the Safe PLC Beckhoff module EL6900, which belongs to the hardware connected to the THCU.

The logical statuses of the telescope subsystems that do not make use of the Beckhoff TwinCAT environment (Camera, PMC, UVSIPM, UCVSCOPE) are acquired through the OPC UA communication protocols. Conversely the AMCU and TCU states, being managed by the PC running the TwinCAT real-time system, are collected by the THMS through the already mentioned Publisher/Subscriber mechanisms provided by Beckhoff.

The power on-off states of all the devices are read by the Input/Output Beckhoff modules (see Section 3.4) connected to the THCU. These modules are mapped into the TwinCAT system variables and made available to the PLC tasks running on the THCU. The THMS then links these system variables to Boolean variables that are used internally. The same happens for the switch on/off commands.

The THMS is also able to collect all the failure events coming from the subdevices (red narrow dashed arrow) of the telescope.

The status, alarm and errors coming from all the telescope devices are made available to the external controller through the THMS OPC-UA server. In this way the telescope can be seen by the external controllers as a single unit concerning health monitoring, diagnostics and the start-up or shut-down procedures.

(15)

G7 Solution THCU SAFETY (2 projects) D J TEST -POWER THCU SAFETY

j

SYSTEM License D Real -Time D E Tasks LRoutes TcCOM Objects ® MOTION J PLC J THCU variables_maps THCU variables_maps Project THCU variables_maps Instance

SAFETY

®ASTRI SAFETY

® ASTRI SAFETY Project T Target System TwinSafeGroupl p Alias Devices TwinSaferouplsal ASTRI_SAFETY Instance C ++ A 111110 Devices Device 1(EtberCAT) High Voltage Ml M2 Data Logger Thermal Control Drives Voltage

Telescope Control System

Control(On/Off)

1_ _

Monitoring Monitoring Control(On/Off) Monitoring Errors

Interlocks ChainLogic

Camera TCU AMCU PMC UVSIPM UVSCOPE (a) (b)

Figure 11. Telescope Health Monitoring Software (THMS) TwinCAT project (a) and its general architecture (b).The THMS is one PLC that is able to monitor and control the status of each device of the telescope.

4.4 MCS and THMS states and modes

Every SW component of the telescope package is developed using the state machine approach: any telescope device is conceived as an abstract machine that can be in one of a finite number of states.

A state machine is a well-known paradigm for developing programs, having activities, states and transitions that allow us to build a program workflow in an event-driven manner.

The operational modes of the MCS, which is the opportune combination of the states defined for MAC, ASTRO and MCS modules, are described in Table 2, while the states of the THMS modules are summarised in Table 3.

The passage from one state to another activates automatically the execution of a defined number of operations leading the systems from one well defined configuration to another. As an example, the permitted state machine transitions of the MCS package are sketched in Figure 12.

Table 2. Operational states description of the MCS package.

MCS STATES DESCRIPTION

OFF MCS is not running. This state does not result in a notification to the high level controllers.

LOADED MCS is running.

STANDBY PLC Communication with hardware controllers is established. Motors are still off and movement of the axes is not permitted. The telescope is in parking position and the stow pins are engaged.

ONLINE(IDLE) The telescope is ready for operation. The PLC control is enabled, the motors are powered on and the stow pins are completely extracted.

ONLINE (SLEW) The telescope is moving towards a target and the position loop is closed.

ONLINE (TRACK) The telescope continues to move at the sidereal rate in order to follow the target.

MAINTENANCE The user has full manual control of the system and can make several changes. It is possible to operate any single MCS functionality independently.

CALIBRATION The system is configured and the pointing model is calculated.

FAULT A major failure that prevents safe use of the system has occurred. The system is not operable.

(16)

THMS STATES DESCRIPTION

OFF The THMS is not running. This state does not result in a notification to the high level controllers. Telescope subdevices are switched off.

LOADED The THMS is running.

STANDBY All the monitoring variables related to the health of the telescope are available.

ONLINE The THMS is ready to be operative, and all its functionalities are available.

MAINTENANCE It is possible to access the system and perform an update of the software. In this status all the other components of the telescope are switched-off.

FAULT A major failure of the THMS system has occurred. The telescope is not operable.

The MCS and THMS transitions can be triggered from the external controllers through a series of well defined commands, summarized in Figure 13, while the MAC and ASTRO transitions can be internally triggered only by the MCS module.

Figure 12. MAC State Machine. Each box defines a state of the controller while each arrow defines the transition permitted between the states.

Those commands are implemented at higher level in the TCS and can be also issued via the GUI packages. Every time a command is sent to the MCS or THMS, a specific procedure is activated and in several cases triggers a state transition also on the MAC and ASTRO modules. The global change of state occurs only if the activities coded in the procedure are all successfully concluded.

The MCS has three operation modes (mutually exclusives): LOCAL, REMOTE and MANUAL.

In the LOCAL mode all the functionalities of the telescope can be commanded using the Engineering GUI, while in the REMOTE mode the MCS receives commands from the TCS. In this case two sub-modes are available for slewing and tracking activities:

 Target mode, where the TCS provides to the MCS only the target parameters and the trajectory is generated

inside the telescope by the ASTRO module.

 Trajectory mode, where the TCS provides to the MCS the full trajectory of the target and ASTRO is

completely by-passed.

In the MANUAL mode the telescope can be only moved through a dedicated Handset pushbutton device available locally, close to the telescope area. MANUAL mode is generally activated by expert people authorized to carry out commissioning and electrical and mechanical maintenance activities. In this case the motion capabilities are limited to movements at a fixed low velocity on both axes.

Table 3. Operational states description of the THMS package.

(17)

COMMAND WARM START WARM STOP INIT START -UP MAINT POINT TRACK CALIB EXIT -FAULT RESTART REINIT STOP -TRACK STOP -POINT OFFLINE STOP

LOADED STANDBY ONLINE

IDLE

ONLINE

SLEW

ONLINE TRACKING

MAINTENANCE CALIBRATION FAUL

t

Figure 13. TCS commands for MCS and THMS state transitions. Every time a command is sent to the MCS or THMS one or an opportune combination of state transitions are triggered.

The THMS allows the user two access modes: Remote, when the THMS is commanded and monitored by the TCS, and Local when it is controlled by using the GUI.

Given its role of supervisor and entry point for the telescope start-up and shut-down operations, the THCU is the only device in the telescope that has to be always on and its software controller, the THMS must be in its operational status: the THMS is fully operative when it is triggered to be in ONLINE status, where the health status of the telescope and all the functionalities are available, all the monitoring variables are updated and the system can receive the commands defined.

5. THE MOUNT SOFTWARE FUNCTIONALITIES

The MCS and THMS functionalities were implemented using the PLC Structured Text (ST, IEC 61131-3) language in the Beckhoff TC3 environment. The main building blocks of the software modules are the Function Blocks (FBs). An FB is a Program Organization Unit (POU) that can describe the function between input and output variables providing one or more values during the processing of a PLC program. The values of the output variables and the necessary internal variables shall persist from one PLC execution cycle to the next.

Depending on their complexity, each functionality of the MCS and THMS was implemented through one or more Function Blocks.

Each FB is in charge of the execution of a simple set of logical steps and the suitable combination of the FBs provides all the necessary actions to perform for the desired functionality. This kind of design allows the programmer to make available the different features, calling up the related FBs, only when the system is in a specific status: Figure 14 shows, as an example, part of the implementation of the ONLINE status of the MCS module.

In this way all the steps and procedures defined are very well controlled and the accidental execution of a functionality is avoided.

(18)

(* //////////////////////////////////////// / / / / / / / / / / / / / / / / / / / / / / // / / / / /// *)

// ONLINE //

(* //////////////////////////////////////// / / / / / / / / / / / / / / / / / / / / / / // / / / / /// *)

TCU Online Idle

MCS STATES. STATUS TOO States. TCO Online Idle;

//////////////////////////////////////// / / / / / / / / / / / / / / / / / / / / / / / // / / / ///

// SUN AVOIDANCE WINDOW //

//////////////////////////////////////// / / / / / / / / / / / / / / / / / / / / / / / // / / / ///

SunAvoidancewindowManager();

fa

SunAvoidanceWindow

J FB SunAvoidanceWindow (FB)

//////////////////////////////////////// / / / / / / / / / / / / / / / / / / / / / / / // / / / ///

// TRACKING AND POINTING //

//////////////////////////////////////// / / / / / / / / / / / / / / / / / / / / / / / // / / / /// TrackingPointingManager ( ) ; li7 Tracking

FB AstroConfigPar (FB) L1] FB_AstroSetPointPlannerGino (FB) 4] FB_ManageTracking (FB) //////////////////////////////////////// / / / / / / / / / / / / / / / / / / / / / / / // / / / /// // ENCODER INITIALIZATION /7 //////////////////////////////////////// / / / / / / / / / / / / / / / / / / / / / / / // / / / /// AZEnclnitialization(); Endnit iilj FB_NitAzEncoder (FB) (* ** *** * ** ** Go to STANDBY * * *** * ** * ** t) OnlineStandby(); (* ** * * ** * *** _{Go to CALIBRATION} * * ** * * * ** ** *) OnlineCalibo ; (* * * * * * * * * ** Go to Maintenance * * * * * * * * * ** *) GoMaintenance();

Figure 14. ONLINE status of the MCS master PLC. All the functionalities defined for this status are available by calling the execution of the related FBs.

5.1 MCS functionalities

The main functionalities developed for the MCS package are briefly described below. A more detailed description is available in [14]. Those functionalities are the most important for the scientific operation of the telescope, and they are based on a series of FBs involving ASTRO, MAC and MCS modules.

Pointing and Tracking

From the MCS point of view a source is pointed when the axes of the telescope have reached the position of the target on sky with an accuracy of 0.0015° (5.4 arcsec) in encoder reading. The telescope is in the tracking state when it is continuously moving at the sidereal rate in order to follow the trajectory of the source on the sky preserving the pointing resolution in encoder reading.

The generation of the trajectory during the tracking or pointing activities is performed by the ASTRO routine. As soon as the MCS module received the target parameters it passes those data to the ASTRO module, which through all the necessary astrometric routines, provides the real-time trajectory to MCS in Elevation and Azimuth coordinates every 100 ms. The master controller, through a specific set of routines, passes the trajectory to the MAC, which is responsible of the correct execution of the axe motion commanded by MCS and generated by ASTRO.

Parking Procedure

The Parking procedure consists in moving the telescope to a safe fixed position with automatic stow-pin insertion (Elevation axis points to the horizon and the Azimuth axis faces North).

(19)

When the procedure is triggered the axes of the telescope move toward the safe position with a constant velocity of 1.5°/s along the Elevation axis and 2 °/s along the Azimuth one. As soon as the Proximity limit switches are reached the axes slow down to 0.1°/s. The complete stop of each axis happens when the Stow limit switches are engaged. Only when both axes are stopped, meaning that the parking position has been reached, MCS commands to the THCU to insert the Stow Pins.

Security Functions

Despite the physical limits of the motion are protected by the appropriate safety devices and logic, the MCS provides two

Slow Down functions, one for each axis. This functions are always monitoring the motion of each axis and command the

controller to slow down to a lower velocity of 0.1°/s whenever the proximity switches, related to one of the direction of each axis, are engaged. An option of automatically stopping the axis before the Operational limit switch related to that direction is engaged is also available (SW SS1 function). In this case the motion is only possible in the opposite direction and the user can remove the axis from that limit position.

If the telescope needs to be moved during daytime, for maintenance or commissioning purposes, in order to avoid Sun damage a Sun Avoidance Window function has been developed. This feature ensures that the motion of the telescope is limited within an area where the mirrors can not focus the direct sunlight.

Motion Management

MCS provides for two motion modes (available in ONLINE and MAINTENANCE states):

 ABSOLUTE mode: setting this mode the operator must provide the target position and the velocity, acceleration and deceleration parameters needed to generate the trajectory to be followed to reach the target position. When the telescope is at the desired position the motion is automatically stopped.

 JOG mode: setting this mode the operator must provide the velocity, acceleration, deceleration and motion direction. The axes move along the selected direction with the desired velocity until a STOP command is issued.

Monitoring, Commands and Set Variables

The MCS interface with the external controllers consists of a series of monitoring and control points. These set of read-write variables are reachable from the higher controllers through the OPC UA client-server protocol, that allows the complete usage of the MCS package form the user/engineer. The complete list of the variables is reported in the MCS ICD.

Error Management

MCS provide for an efficient failure handling system, which comprises the following tasks:

 Records of anomalous events (Alarm, Error and Warning), with the related code and timestamp.  Provide external controllers with access to error information.

 Real-time recovery, reset and clearance of the failures.

5.2 THMS functionalities

The THMS implements the following functionalities:  Monitoring the status of the interlock chain devices;

 Monitoring the operational modes and powered status (on-off) of the devices inside the telescope;

 Monitoring the power consumption of the Motors (Currents, Voltages, Powers of the 3-phase power supply);  Monitoring the status of the EtherCAT communication and operational status of the interface modules

belonging to the THCU hardware configuration;

 Handling of commands for the THMS state transitions and switching on-off the telescope devices;  Override of the Safety functionalities (see subsection below);

 Alert the operator if an emergency device is active and inhibition of the power to the motors (e.g. limit switch intervention or cabinets/base doors opening);

 Elevation and Azimuth Stow Pin insertion and extraction;

(20)

$

l

State: 041 AndOut safeTof FBTOfl Toile TOF

$

safeAnd FBAnd3 0 Andinl 0x01

!14

AndOut & AZSTOIN EM_STOP1 0 Andin2 gAndin3 i Delay Time (s) 0.1 State: 0x01 0 Andin4 EN EN STOP2 STOP3 e Andins ® Andlnó Andin7 Andin8 State:

I- Error Management.

A complete list of the variables defined and their functional descriptions is reported in the THMS ICD.

5.3 Interlock Chain Logic

The interlock devices dedicated to the safety system of the telescope are linked to the THCU through dedicated Beckhoff Input modules (see Section 3.4). Those devices can be mapped into the TC3 system variables in order to develop the Safety functionalities. Each channel of the Input modules is then associated to a Boolean variable whose status reproduces the electrical signal provided by the physical device. If the physical switch is not engaged the electrical circuit is closed and the status of the associated variable is TRUE, on the contrary if the device is engaged the circuit is opened and the variable value is FALSE.

The SAFETY module of the TC3 uses these Boolean variables to implement the logic chain shown in Figure 15, needed to provide the Safe Torque Off (STO, IEC 61800) signal to the servo drives of the telescope motors. The STO function is the most common and basic servo drive-integrated safety function. It ensures that the drive will not operate the motor while one or more of the interlock devices are engaged [15].

The Output module (EL2904) of the safety chain delivers a signal to the Input ports of the Azimuth and Elevation servo drives. This module is able to deliver or not deliver a 24 Volt signal to each servo drive, based on the Safety logic. For example if one of the limit switches is engaged, or one of the telescope doors is opened (Cabinet or Base) or an emergency button is pushed, the Safety module immediately stops the delivery of the 24 Volt signal to the drives inhibiting their operation.

This means that, if the telescope was moving the motors are immediately stopped and the motion is inhibited.

As soon as the emergency situation is recovered by the user (no automatic exit strategy from an emergency situation can be implemented) the Safety PLC restores the 24 V delivery to the servo drives and the telescope can restart operations. For security reasons whenever a STO function is activated the THMS is able to switch off the high voltage to the motors and to disable the servo drives.

Figure 15. Example of the interlock logic chain implementation managed by the Safety PLC performing the STO function. Each logic module can have one or more inputs which status corresponds to the physical signal of the interlocks (e.g. the Switch for the base of the door (DOORBASE)) and returns in output the suitable logical combination of these signals, based on the logical operator selected (e.g. SafeOR , SafeAND).

6. CONCLUSIONS

The ASTRI SST-2M prototype is mainly a technological demonstrator and its particular design represents a novelty in the world of Very High Energy Astrophysics: it is a dual mirror Schwarszchild-Couder (SC) telescope [4][20], based on highly aspherical optics, composed of one primary (M1) and one secondary (M2) mirror, capable to collect the Cherenkov light. This innovative optical design solution allows us to have a wide field of view (> 9.5°) with the use of a

(21)

smaller and lighter camera based on Silicon Photo Multipliers (SiPMs) technology (pixels size ~3-6 mm) in substitution to the classical Photo Multiplier Tubes (PMTs ~ 25 mm) in use on current Imaging Air Cherenkov Telescopes (IACTs). Anyhow the combination of these two innovative systems poses more stringent requirements on the pointing and tracking accuracy than in other existing IACTs, assigning a fundamental role to the hardware and software components of the control systems dedicated to the management of the Mount.

In order to fulfill the desired requirements regarding the needed performance, assembly compactness, high reliability and reduced maintenance, the state of the art of the control and automation technology currently available was selected. The proposed technological solutions, design and architecture made it possible to develop all the features of the Mount telescope through software PLCs, making ASTRI one of the very few examples where all the main functionalities of the telescope, including the generation of the tracking trajectory of a target, are managed entirely using such technology. The physical interfaces between the devices involved in the Mount configuration are all based on the EtherCAT protocol, which guarantees homogeneity and compatibility of real-time communication.

The engineering efforts necessary to control the drive, health and security systems were significantly reduced, thanks to the TwinCAT 3 philosophy making available an innovative software architecture, based on a modular control software for the PLC and Safety application development. In TC3 the individual functions, assemblies or machine units are regarded as modules, which could be used to encapsulate the functionality of these objects, which increases the reuse, extension and maintainability of control code.

The hardware design, the state machine approach, the SW architecture defined and the Function Blocks usage for the THMS and MCS modules implementation, made it possible to develop a robust and efficient package, which satisfies the defined requirements while optimizing the utilization of computational resources distributing evenly the computational effort.

Indeed the Mount Software PLC package, thanks to its architecture and development platform tools, can be easily integrated into the higher-level controllers, the Telescope Control System (TCS) or the GUIs, in a consistent, future-proof and straight-forward way. In this context the OPC Unified Architecture (UA) plays an important role, because it supports a rich data model and because client and server implementations are available for many platforms, including PLCs.

The PC-Based technology selected for the PLCs control, together with the OPC UA communication protocol, makes it possible to provide a "one-channel" control of the telescope. That is every device inside the telescope is managed independently by the related controllers which are OPC UA or Beckhoff compatible. In this way all the variables dedicated to the management of each sub-device (monitor and control points and failure events handling) could in principle converge to one supervisor (maybe the THCU). It thus becomes the unique device which interfaces with the external controllers, allowing to streamline the definition of the interfaces between the low and high level controllers, while the access to the single device is still maintained. In this way the telescope could become a unique black box machine in which all the devices can be completely transparent for the normal operation purpose, while allowing the external access to each device for engineering needs (maintenance, testing and calibration activities).

In summary the technical solutions and design adopted for the hardware and software components of the Mount controllers ensure the homogeneity of the system together with high real-time performances and an easy integration with the external controllers.

This choice was made in order to make the ASTRI SST-2M telescope an efficient and stand-alone machine, easy to be integrated in an array configuration.

Moreover the Mount Software control of the ASTRI SST-2M has served as prototype for the future Mount Control System of the ASTRI mini-array telescopes proposed to be installed at the CTA southern site.

Furthermore, the technology selected for the ASTRI Mount control and safety systems allowed us to test a lot of functionalities developed by the companies chosen and used for the first time in this kind of application. It means that the ASTRI project has represented an important test bench also for the automation industries such as Beckhoff and SEW.

ACKNOWLEDGMENTS

This work is supported by the Italian Ministry of Education, University, and Research (MIUR) with funds specially assigned to the Italian National Institute of Astrophysics (INAF) for the Cherenkov Telescope Array (CTA), and by the Italian Ministry of Economic Development (MISE) within the "Astronomia Industriale" program. We acknowledge support from the Brazilian Funding Agency FAPESP (Grant 2013/10559-5) and from the South African Department of

(22)

Science and Technology through Funding Agreement 0227/2014 for the South African Gamma-Ray Astronomy Programme. We gratefully acknowledge support from the agencies and organizations listed under Funding Agencies at

this website: http://www.cta-observatory.org/. This paper has gone through internal review by the CTA Consortium.

REFERENCES

[1] “SST Requirements MAN-PO/120808 Version 3.03” (2015).

https://portal.cta-observatory.org/Bodies/ProjectOffice/Requirements/SiteAssets/SitePages/Requirements/

[2]Gardiol, D. et al, “Active optic system of the ASTRI SST-2M prototype for the Cherenkov Telescope Array”, Proc. SPIE 915103 (2014).

[3] Catalano, O. et al, “The ASTRI SST-2M Prototype: Camera and Electronics”, ICRC (2013)

.

[4] Maccarone, M.C. et al., NIM-A 659, 1, 569 (2011). [5] Sottile G., et al.,, arXiv:1305.2699 (2013).

[6] https://www.beckhoff.com/ [7] http://www.seweurodrive.com/ [8] http://www.heidenhain.com/

[9] “The ASTRI SST-2M Prototype: Overview of the Operational Procedures”, ASTRI-PRO-IASFPA-1000-008 (2015). [10] https://opcfoundation.org/about/opc-technologies/opc-ua/

[11] “OPC Foundation and PLCopen, OPC UA Information Model for IEC 61131-3”, v1.00 (2010).

[12] Tanci C, . et al, “Software design and code generation for the engineering graphical user interface of the ASTRI SST-2M prototype for the Cherenkov Telescope Array”, SPIE Proc 9913-138 (2016).

[13] http://aa.usno.navy.mil/software/novas/novas_c/novasc_info.php

[14] Antolini E., PhD Thesis, “ASTRI SST-2M Mount Control Software and Safety System” (2015). [15] https://webstore.iec.ch/publication/22929

[16] Pessemier, W., et al.,”Design and First Commissioning Results of PLC-based Control Systems at the Mercator Telescope.”, SPIE Proc. 8451 2V, Bellingham (2012).

[17] Kiekebusch, Mario J. et al., “Math Works Simulink and C++ integration with the new VLT PLC based standard development platform for instrument control systems.”, SPIE Proc 9152-84 (2014).

[18] http://www.iausofa.org/current_C.html#Downloads

[19] Pareschi, G. et al, “The ASTRI prototype ans mini-array: telescopes precursors for the Cherenkov Telescope Array (CTA)”, SPIE Proc. 9906-223 (2016).

[20] Canestrari, R. et al, “The ASTRI SST-2M prototype for the Cherenkov Telescope Array: manufacturing of the structure and the mirrors”, SPIE Proc. 91450 (2014).