Roadmap and planned evolution

This section outlines the intended evolution of the CSP.LMC architecture. It is provided to give context on current design choices and to highlight areas that are expected to evolve in future iterations.

Component abstraction refactoring

The Component abstraction represents the architectural boundary between CSP.LMC devices and CSP subsystem TANGO devices (CBF, PSS, PST).

In the current implementation, the Component class plays multiple roles at once, including:

  • acting as a proxy for TANGO command execution;

  • caching the latest attribute values of the subsystem;

  • managing event subscriptions and callbacks;

  • handling connectivity, reconnection, and error conditions;

  • normalizing and forwarding events to the Event Manager.

While this approach has proven effective in practice, it has led to a Component implementation that combines several distinct responsibilities and has grown significantly in complexity over time.

The planned evolution aims to reduce coupling and clarify responsibilities by progressively separating these concerns into more focused abstractions.

Intended directions include:

  • isolating low-level TANGO connectivity and reconnection logic;

  • separating event subscription and forwarding from state caching;

  • clarifying the boundary between passive data access and active command execution;

  • simplifying the interaction between Components and higher-level monitoring and supervision layers.

This refactoring is expected to improve readability, testability, and long-term maintainability, while preserving the existing architectural role of Components as the interface between CSP.LMC and subsystem devices.

Event handling and supervision

Event ingestion and dispatch in CSP.LMC is centralized in the Event Manager, which collects asynchronous subsystem events, queues them, and forwards them to the appropriate consumers (models, supervisors, and attribute update logic).

In the current architecture, events delivered with invalid quality or missing values (for example during temporary disconnections, device restarts, or communication issues) are filtered and not forwarded to downstream consumers. This choice avoids propagating ambiguous or misleading information to aggregation and supervision logic.

Future evolutions are being evaluated to enrich this behaviour, while preserving the Event Manager’s role as a lightweight ingestion and dispatch layer and avoiding tight coupling with supervision logic.

One direction under investigation is to propagate higher-level event semantics through shared state, rather than through direct callbacks. In particular, information such as event validity, quality, or “last-seen” timestamps may be stored alongside subsystem state in the central snapshot used for evaluation.

Planned areas of investigation include:

  • representing invalid or missing subsystem updates as structured state metadata, rather than as raw events;

  • enabling the supervision layer and consistency policies to detect temporary loss of connectivity and subsystem restarts based on snapshot information;

  • improving the distinction between transient anomalies and persistent fault conditions during observation;

  • strengthening the interaction between event handling and observation supervision by sharing richer snapshot semantics, without introducing direct dependencies between the Event Manager and supervision layers.

These changes aim to improve diagnostic capabilities and observability, while maintaining a clear separation of responsibilities between event ingestion, state storage, supervision, and policy evaluation.