Event manager
The Event Manager is the CSP.LMC component responsible for collecting asynchronous subsystem events and dispatching them in a controlled and thread-safe way to the parts of the device that need to react.
In a CSP deployment, multiple subsystems (e.g. CBF, PSS, PST, Resource Manager) emit attribute events independently. These notifications can be bursty, arrive out of order, or include transient invalid samples. The Event Manager provides a single ingestion point that decouples event reception from event handling, ensuring that device logic is not executed directly in the TANGO event callback context.
Role in the monitoring architecture
At a high level, the Event Manager:
subscribes to selected attributes on subordinate subsystem components;
receives events asynchronously and enqueues them for processing;
processes events in a dedicated worker thread;
forwards normalized updates to the appropriate consumers, such as:
device-level models (e.g. operational state and health aggregation),
the health supervision layer (for healthState/healthInfo supervision),
the observation supervision layer (for observing-state supervision),
generic attribute update logic for non-modelled attributes.
This separation provides predictable execution flow, avoids blocking TANGO threads, and allows monitoring logic to remain responsive under high event rates.
Event ingestion and dispatch
Events are received through TANGO subscriptions and inserted into an internal queue. Processing happens independently in a worker thread that consumes queued events and dispatches them to the relevant evaluation logic.
This design has two benefits:
Concurrency safety: subsystem events do not execute device logic in the callback thread, reducing the risk of deadlocks and long callback chains.
Back-pressure and control: the queue provides a bounded buffer and a single place where the system can manage bursts and prioritize controlled processing.
Handling of invalid and unsupported events
Subsystem events may occasionally be delivered with invalid quality or missing values, for example during communication interruptions, reconnections, or device restarts.
At present, such events are filtered by the Event Manager and are not forwarded to downstream consumers. This is a deliberate design choice, aimed at preventing ambiguous or incomplete information from propagating into monitoring, aggregation, or supervision logic.
Future extensions are being evaluated to handle invalid events in a more structured way. In particular, these events may be surfaced to the observation supervision layer to:
detect temporary loss of connectivity,
identify subsystem restarts or recovery phases,
distinguish transient communication issues from persistent failures.
By centralizing event ingestion, the Event Manager provides a natural integration point for this kind of enhanced monitoring, without impacting the existing supervision and aggregation logic.
Interaction with observation supervision
Observing-state events are forwarded to the observation supervision layer. The supervisor and its state store provide the coherent snapshot and debounced evaluation required to publish stable observing-state information.
In this architecture, the Event Manager is responsible for event collection and dispatch, while the supervisor is responsible for coherent evaluation and controlled publication.
Queue management and flushing
The Event Manager supports explicit queue flushing as a safety mechanism to reduce stale event buildup during command execution or rapid state changes.
Flushing processes a limited number of queued events in a controlled critical section, ensuring that the queue can be drained without losing thread safety guarantees.
Summary
The Event Manager acts as the event ingestion and dispatch layer for CSP.LMC devices. By decoupling TANGO callbacks from device logic and centralizing event processing in a worker thread, it provides a robust foundation for higher-level monitoring components, including health and state aggregation and observation supervision.