CSP.LMC architectural overview

The CSP.LMC architecture is shared between the CSP.LMC Controller and the CSP.LMC Subarray devices. Both play a coordinating role and interact with the same set of CSP subsystems, while operating at different scopes.

At a high level:

  • the CSP.LMC Controller coordinates global CSP behaviour and resource availability;

  • each CSP.LMC Subarray coordinates a subset of resources during an observation.

Both the Controller and the Subarray communicate with the same three CSP subsystems: CBF, PSS, and PST. In addition, the Controller interacts with CSP.LMC Subarrays and the Capabilities device manager to report and coordinate resource-related information.

In the figure below, the command-and-control view of the CSP Controller is shown. The CSP.LMC Subarray architecture follows the same structure, with subsystem controllers replaced by subsystem subarrays, and without interactions with other CSP.LMC subarrays.

../_images/ControllerDiagram.jpg

Further diagrams and a more detailed description of the CSP.LMC components can be found in the following sections.

Interaction with CSP subsystems

The main CSP operations are executed by the subordinate subsystems (CBF, PSS, PST). Interactions between CSP.LMC devices and subsystem TANGO devices are mediated through a dedicated Python abstraction, referred to as a Component.

This abstraction layer decouples CSP.LMC device logic from direct TANGO interactions and acts as the architectural boundary between CSP.LMC and the underlying subsystem devices, providing a uniform interface for:

  • command execution,

  • attribute access,

  • event subscription,

  • basic connectivity and error handling.

This approach improves modularity and allows monitoring, supervision, and command execution logic to evolve independently from the underlying TANGO communication details.

State management

Starting from version 0.11.0, CSP.LMC no longer relies on the ska-tango-base state machine. Instead, CSP.LMC implements dedicated state models for:

  • operational state,

  • observing state,

  • health state.

This change enables finer control over aggregation rules, supervision logic, and fault semantics, which are specific to CSP operational requirements and are described in the following sections.