A Component and Connector View of Taranta Suite¶
Introduction¶
‘Taranta Suite’ is the name given to a collection of software that will be used to design and build simple engineering web-based user interfaces for the SKA. These will allow the state of the software and hardware devices that make up the telescope to be viewed, and let the user send them commands.
The purpose of this document is to present a ‘component and connector’ view of the Taranta Suite, showing its various parts and how they interact with each other and the outside world to deliver the required performance. The intended audience is anyone unfamiliar with the system who would like a rough but accurate outline of its shape and how it works. In particular, it may be useful to engineers joining the SKA software effort.
Taranta Suite Component and Connection Diagram¶
Taranta Suite Component Table¶
Component | Multiplicity | Description |
traefik | 1 | Variously described as an ‘ingress controller’, ‘reverse proxy’ or ‘router’. By parsing the structure of the address, it routes https traffic from the internet to the appropriate client in the Taranta Suite. |
Taranta | 1 | A React-based web app supplying pages for creation and editing of dashboard UIs that display/interact with devices in an attached TANGO control system. Pages are implemented in javascript and typescript. |
dashboards | 0 to many. | A ‘dashboard’ is a user interface giving access to devices in the TANGO control system. A user can create multiple dashboards for different purposes, and is able to name and share them with other users of the system. ‘dashboards’ is the component serving the database repository for dashboards that have been created. |
auth | 1 | Authentication server for validating users. Once authenticated a user token is shared with the other Taranta components, allowing them access. In particular, a token is shared with ‘mongodb’, allowing dashboards created by the user to be stored there. |
mongodb | 1 | The database used by the ‘dashboards’ component to store the collection of dashboards associated with a particular user. Each dashboard is stored as a JSON document. |
tangogql | 1 to many, each attached to a different TANGO control system. | This is a TANGO client connected to a particular TANGO control system, specified by the TANGO_HOST:port passed to it at startup. The component services https GraphQL queries to the attached TANGO system, finding and returning the values of the requested attributes etc. In principle, multiple ‘tangogql’ servers could be present, addressed through ‘traefik’ by the TANGO system name - ‘testdb’ in the example diagram. |
TANGO control system | 1 per TANGO system. | This is the public point of contact between the outside world and a TANGO system. This name may be an alias for the term ‘database server’, which is given in general TANGO docs to a component that seems to perform the same service. The TANGO control system and associated database are used by devices and clients to connect to the TANGO software bus for that system. Thereafter communication between TANGO components is direct, over the ‘software bus’. |
TANGO database | 1 per TANGO system. | The database used by the TANGO c.s. to store configuration information for devices and clients. This is used to set up the network initially and to connect components. tangogql queries the database to gather information about the system. |
TANGO software bus | 1 per TANGO system. | The virtual ‘bus’ used for communication between devices and clients belonging to a TANGO system. |
Tango devices | 1 to many. | Tango is the underlying control network for the SKA telescope, The critical hardware and software components of the telescope will be represented at some level by tango ‘devices’. |
Taranta Suite Connection Table¶
Connection | Component 1 | Component 2 | Description |
https | Web browser or traefik | traefik Taranta auth dashboards tangogql | HyperText Transfer Protocol Secure. Communication between browsers and web app components. Different flavours of message are detected by ‘traefik’ and routed to the appropriate web app. |
dashboards | dashboards | mongodb | SQL descriptions of dashboards. |
user token | auth | mongodb | User token from ‘auth’ component, authorising them to store data in mongodb. |
TANGO config | TANGO control system | TANGO device or TANGO client (tangogql) | Configuration messages between TANGO control system, clients and devices. |
TANGO data | TANGO device | TANGO client (tangogql) | Direct communication between components on the TANGO software bus. This takes the form of setting and querying attributes of the device or issuing commands. Devices can also issue Events (for instance when an attribute value changes). Tango devices can subscribe to the types of events they are interested in and will receive published events when they occur. |
TANGO database | TANGO control system | database | Data on the configuration of a TANGO system. |
Notes¶
TANGO¶
Tango is a control system that provides a unified interface to all equipment, hiding network details and location.
The building block of a Tango network is the device, a software object that can represent any type of hardware or software. All devices present a uniform interface of commands, attributes, properties and state.
The ‘identity’ of each Tango system is given by its central database and associated ‘database server’ (aka in the SKA as ‘TANGO control system’), which stores configuration data for device startup and acts as a name server for dynamic network addresses. The machine on which the database server is running is called the ‘Tango Host’. A client process or device wanting to join the TANGO system contacts the database server and is put into direct contact with the target.
Docker¶
The components shown above are built as docker images. Each of the Taranta Suite components shown is represented by a single image within the Nexus repository and has its own project in GitLab.
At the moment a combination of Make file commands and docker-compose scripts are used to instantiate the components as docker containers and to set up the port linkages between them as shown in the figure. It is likely that docker-compose will be superseded by a kubernetes based architecture (as is used in the integration environment), but the component relationships will remain the same.