- 1 - Introduction
- 1.1 - Architecture
- 1.2 - TMC Functionality
- 2 - Prerequisites
- 3 - Installing, configuring and running the ska-tmc-sdpleafnodes (non-containerised environment)
- 3.1 - Installing Dependencies
- 4 - Testing
- 4.1 - Unit Testing
- 4.2 - Integration Testing
- 4.3 - Manual Testing
- 5 - Formatting & Linting
- 6 - Documentation
This is the repository for the TMC evolutionary prototype. Ska-tmc-sdpleafnodes aims to realize TMC SdpLeafNodes Monitoring and Control functionality, and utilizes the platform, tools and technology specified for the SKA construction.
The ska-tmc-sdpleafnodes utilizes the base classes created in-line with the SKA Control System Guidelines and Tango coding standards. Developed in Python 3.7 (PyTango 9.3.3), it is a single repository which releases a single package called ska-tmc-sdpleafnodes. ska-tmc-sdpleafnodes contains two sub packages - SdpMasterLeafNode and SdpSubarrayLeafNode. CentralNode device is implementated in a separate gitlab repository which is available at https://gitlab.com/ska-telescope/ska-tmc-centralnode . SubarrayNode device is implemented in a separate gitlab repository which is available at https://gitlab.com/ska-telescope/ska-tmc-subarraynode . SKA-TMC-SDPLEAFNODES addresses the following architectural aspects and functionality:
-
Use of LMC base classes for development of TMC SDP Leaf nodes.
-
Hierarchy of control nodes for Mid and Low- Central Node, Subarray Node, Leaf Node
-
Interface between the Dish Leaf Node and Dish(Master simulator)
-
Interface between the CSP Leaf Node and CSP (CSP Master and Csp Subarray devices)
-
Interface between the SDP Leaf Node and SDP (SDP Master and SDP Subarray devices)
-
Interface between the MCCS Leaf Node and MCCS (MCCS Master and MCCS Subarray devices)
-
Integration of KATPoint library (1.0a1) for pointing and delay calculation for CSP Leaf Nodes.
-
Use of SKA Logger as the logging solution
-
Use of HDB++ Archiver as the archiving solution
-
Source tracking for TMC-Mid
-
Adopted ADR-8 observation state machine
- Monitoring and control functionality with hierarchy of nodes
- Automatic control actions on Alerts using Elettra Alarm Handler
- Simulator for DishMaster
- Allocation and Deallocation of receptors to a Subarray
- Commands and Events propagation
- TANGO group commands
- Conversion of Ra-Dec to Az-El coordinates using KATPoint for TMC-Mid
- Calculate Az-El periodically in Dish Leaf Node and implement tracking functionality in the Dish simulator
- Interface between the TMC and CSP:
- Implementation of CSP Master Leaf Node and CSP Subarray Leaf Node
- Monitor/subscribe CSP Master and CSP Subarray attributes from CSP Master Leaf Node and CSP Subarray Leaf Node respectively
- Use of CSP Master health to calculate overall Telescope Health (in Central Node Mid)
- Use of CSP Subarray health to calculate Subarray Node health state
- StartUpTelescope command on Central Node to change CSP Master device and CSP Subarray device state to ON
- Configure the CSP for a simple scan
- Publish Delay coefficients at regular time interval (every 10 seconds) on CSP Subarray Leaf Node per Subarray
- Interface between the TMC and SDP:
- Implementation of SDP Master Leaf Node and SDP Subarray Leaf Node
- Monitor/subscribe SDP Master and SDP Subarray attributes from SDP Master Leaf Node and SDP Subarray Leaf Node respectively
- Use of SDP Master health to calculate overall Telescope Health (in Central Node Mid)
- Use of SDP Subarray health to calculate Subarray Node health state
- StartUpTelescope command on Central Node to change SDP Master device and SDP Subarray device state to ON
- Configure the SDP for a simple scan
- Interface between the TMC and MCCS:
- Implementation of MCCS Master Leaf Node and MCCS Subarray Leaf Node
- Monitor/subscribe MCCS Master and MCCS Subarray attributes from MCCS Master Leaf Node and MCCS Subarray Leaf Node respectively
- Use of MCCS Master health to calculate overall Telescope Health (in Central Node Low)
- Use of MCCS Subarray health to calculate Subarray Node health state
- StartUpTelescope command on Central Node Low to change MCCS Master device state to ON
- AssignResources command on Central Node Low to change MCCS Subarray device state to ON and allocates resources to MCCS Subarray through MCCS Master
- Configure the MCCS for a simple scan
- TMC commands/functionality to execute entire obsevation cycle
- Telescope Startup
- AssignResources command to allocate resources to the SubarrayNode
- Execute Configure command for a Subarray
- Execute Scan and End the Scan
- End command on SubarrayNode to end the scheduling block
- ReleaseResources commands to deallocate resources from the SubarrayNode
- Telescope Standby
- Configure and execute multiple scans for TMC-Mid
- Implement the observation state model and state transitions as per ADR-8.
- Calculate Geometric delay values (in seconds) per antenna on CSP Subarray Leaf Node
- Convert delay values (in seconds) to 5th order polynomial coefficients for TMC-Mid
- Abort an ongoing operation, and Restart the control nodes, catch exceptions in the AssignResource workflow, log the exception details and raise them to the calling components for TMC-Mid.
- Implementation of obsReset functinality (as per ADR-8) in which resource allocation in Subarray is retained and only the scan configuration parameters are cleared for TMC-Mid.
- Update the JSON strings (command inputs and attributes) in the TMC as per ADR-35
NOTE: Refer to the Demo link provided in the Documentation section for more details.
- Linux/Ubuntu (18.04 LTS)
- Python 3.7
- python3-pip
- Tango (9.3.4-rc2)
- PyTango (9.3.3)
- [ska-tango-base (0.11.3)] (LMC Base classes for SKA)
- ska-ser-logging
- ska-tmc-cdm
- telescope-model
- KATPoint
- pytest
- pytest-cov
- pytest-json-report
- pycodestyle
- pylint
- Docker (for running the ska-tmc in a containerised environment)
- Kubernetes (K8s)/Minikube
- tango-simlib
- poetry (1.1.13)
Since the SKA-TMC-SDPLEAFNODES is developed using LMC Base and SKA-TMC_Common classes, we need to install them prior to running ska-tmc-sdpleafnodes.
Use following commmand to install all necessary dependencies on your virtual environment: poetry install
As depicted above, the higher level of TMC SDP leaf nodes are dependent on lower level devices in normal operation.
However for better testability, the unit testing is carried out by mocking the dependent devices.
This enables us to test each of the nodes independently without setting up the entire hierarchy of control nodes.
In order to execute the entire suit of test cases in the repository, a command in makefile is implemented.
The command to run the unit tests in python virtual environment is: make python-test
\
Note: This section will soon be updated.
Integration Testing is performed on SKA Integration on K8S environment. For this testing TMC-SDPLEAFNODES image is required to
build locally or need to be available on Nexus repository.
All the Dependent Nodes are mocked in our kubernetes cluster, while integration testing.
The command to run the Integration tests is: make k8s-test
\
The SKA-TMC-SDPLEAFNODES can be deployed in the development environment. The TMC-SDPLEAFNODES needs to be deployed in kubernetes environment. The deployment consists of real TMC SDP leaf nodes and mocked dependent nodes(SDP).
Following are the system requirements to deploy the TMC-SDPLEAFNODES:
Requirement | Minimum | Recommended |
---|---|---|
CPU cores | 4 | 8 |
RAM | 8 GB | 16 GB |
Storage | 64 GB | 100 GB |
This section is TBD:
Deploy the TMC-SDPLEAFNODES using make k8s-install-chart
command.
The make k8s-watch
command can be used to monitor the pods to ensure all required pods are up and running.
The command make k8s-uninstall-chart
deletes the deployment from kubernetes cluster.
The command make k8s-clean
performs cleanup like deleting the kubernetes namespace. This is optional.
Pylint, code analysis tool used for the linting in the SKA-TMC-SDPLEAFNODES. Configuration for linting is provided in .pylintrc file. For the code analysis of entire TMC-SDPLEAFNODES, a command in the makefile is implemented.
The command used for formatting is: make python-format
The command used for linting is: make python-lint
After completion of linting job, linting.xml file is generated, which is used in generation of lint errors, lint failures and lint tests gitlab badges.