Overview

This section introduces the observation supervision mechanism used in CSP.LMC to ensure the consistency of observing states across subsystems in a distributed and asynchronous environment.

In CSP.LMC, multiple subsystems independently report their observing states. These updates may arrive at different times, with different frequencies, and may temporarily diverge during legitimate transitions. Reacting directly to every individual update would lead to unstable state propagation, false fault detection, and poor overall observability.

The observation supervisor addresses this problem by introducing a controlled mediation layer between raw subsystem events and the final observing state exposed by the CSP device. It coordinates when state evaluations occur and ensures that decisions are taken only when the system view is sufficiently stable, or when a bounded latency is reached.

This section describes the role of the Supervisor, the actors involved in the decision process, and the motivation for introducing a debounced and policy-driven evaluation layer.

Main actors

The supervision architecture is built around a small set of clearly separated roles.

Subsystems: Individual CSP subsystems (CBF, PSS, PST, etc.) emit observing state updates independently, reflecting their local state and internal transitions.
Event aggregation: Subsystem updates are collected and normalized by an event management layer, which acts as the entry point for observing -related changes. This layer is responsible only for ingesting events and forwarding them to the supervision logic (see event manager).
State storage: A centralized, thread-safe store maintains the latest known observing state for each subsystem. This store represents the current system snapshot and provides a consistent view for evaluation purposes.
Observation supervisor: The supervisor orchestrates evaluation timing and decision making. It buffers incoming updates, applies stability and latency constraints, and triggers evaluations only when appropriate.
Consistency policy: The policy encapsulates domain-specific rules that determine whether the observed combination of subsystem states is valid, inconsistent, or faulty for the current operational context.
Observing state model: The model is the single authority responsible for applying the final observing state, handling precedence, de-duplication, and publication to the external interface.

High-level behavior

At a conceptual level, the supervision process follows these steps:

Subsystems emit observing state updates asynchronously.
Updates are collected and stored as the latest known subsystem states.
The supervisor waits for either state stability or a maximum latency threshold before evaluating.
A consistency policy evaluates the overall system state using a coherent snapshot of all subsystems.
Based on the evaluation outcome, the final observing state is applied or a fault condition is raised.

Critical conditions (such as FAULT or ABORTED states) bypass stability delays to ensure timely reactions.

Why supervision is needed

In CSP.LMC, no single subsystem has a complete view of the system observing state. Each component reports only its local state, based on its own internal lifecycle and timing.

The primary role of the supervision layer is to collect, correlate, and evaluate these independent subsystem reports in order to construct a coherent, system-level view of the ongoing observation.

In a distributed system, subsystem events are inherently asynchronous and may arrive at different times, with different frequencies, and in different orders. Evaluating observing state directly on individual updates would therefore lead to:

transient and oscillating states during normal transitions,
decisions based on partial or inconsistent information,
difficulty distinguishing real faults from short-lived anomalies,
noisy and unreliable state publication.

The supervision layer addresses these challenges by introducing:

a single coordination point for subsystem state correlation,
temporal decoupling between events and decisions,
evaluation based on coherent system snapshots,
explicit handling of consistency and fault semantics,
clear separation between event ingestion, policy logic, and state publication.

Together, these components provide a robust and extensible framework for observing state management in the presence of asynchronous and distributed subsystem behavior.

The following diagram illustrates the high-level interaction between subsystem events, supervision logic, and observation state publication.

Subsystems (CBF / PST / PSS)
        |
        v
  EventManager
        |
        v
    StateStore  ---- snapshot ----+
                                  |
                                  v
                        ObservationSupervisor
                                  |
                          Consistency Policy
                                  |
                          ObsStateModel
                                  |
                        Published ObsState