Base observation consistency policy

The base observation consistency policy defines the generic CSP.LMC rules used to evaluate whether the aggregated CSP Subarray ObsState is consistent with the current subsystem states and with the command currently being supervised.

The base policy is not specific to scanning. It provides the common behaviour used by the observation supervisor to detect, classify, and handle inconsistent observation state distributions across all observation states.

Scan-specific policies build on top of this base behaviour. They do not replace the base policy; they extend it only where scan-specific semantics are required.

Policy inputs

The base policy is evaluated using a consistent snapshot of the supervision state. The inputs normally include:

  • the candidate aggregated CSP Subarray ObsState;

  • the previous or currently published CSP Subarray ObsState;

  • the subsystem ObsState snapshot;

  • the active command context, when available;

  • the command semantics stored in the command context;

  • the active observing modes;

  • policy configuration parameters, such as thresholds and hard-fault behaviour.

The command context is optional from a structural point of view, but it becomes semantically important whenever the consistency decision depends on the command that is currently running or whose effects are still being observed.

Generic behaviour

The base policy defines the default behaviour for CSP observation consistency.

During each evaluation cycle, the policy determines whether the candidate aggregated state can be applied directly, whether the system should wait for a more conclusive state distribution, whether subsystem information should be refreshed and re-evaluated, or whether the inconsistency must be treated as a fault.

The base policy is responsible for:

  • detecting inconsistent subsystem state distributions;

  • distinguishing transient transitions from stable inconsistencies;

  • applying configured thresholds when required;

  • producing diagnostic information;

  • selecting the policy action to be executed by the observation supervisor.

This behaviour is shared by specialised policies. A specialised policy should reuse the base consistency behaviour and override only the parts of the decision that require domain-specific semantics.

Policy decision

The result of a consistency evaluation is a policy decision.

A decision contains:

  • the final CSP Subarray ObsState to apply, when applicable;

  • the selected policy action;

  • whether the inconsistency is a hard fault;

  • a diagnostic message;

  • a severity level.

The policy action makes the control-flow intent explicit. The supervisor does not infer the next action only from severity or from the final state.

Policy actions

The base policy can return the following actions.

APPLY

The final observation state can be applied to the CSP Subarray observation model. Diagnostic attributes are updated accordingly, and the evaluation cycle completes successfully.

WAIT

No final state is applied yet. The state distribution is not considered conclusive, and the supervisor keeps the evaluation cycle pending so that the generic supervision loop can trigger a new evaluation later.

FAULT

The inconsistency is non-recoverable. The supervisor transitions the CSP Subarray into FAULT and reports the associated diagnostic information.

REFRESH_AND_REEVALUATE

No final state is applied yet. The supervisor refreshes subsystem information and performs a new policy evaluation using the refreshed snapshot. This action is used when the current state is not conclusive, but an additional refresh may provide enough information to reach a final decision.

Severity levels

The base policy classifies inconsistencies using severity levels.

LOW

The inconsistency is recoverable, transient, or diagnostic only. If the selected action is APPLY, the final state can still be applied.

MEDIUM

The inconsistency represents a degraded but potentially valid condition. The selected action determines whether the degraded state can be applied immediately or whether the evaluation should remain pending.

HIGH

The inconsistency is considered non-recoverable and normally results in a FAULT action.

Severity describes the impact of the inconsistency. It does not by itself define the control flow. The control flow is defined by the selected policy action.

Interaction with the observation supervisor

The CspObservationSupervisor applies the policy decision to the CSP Subarray observation model.

For each evaluation cycle, the supervisor:

  • takes an atomic snapshot of subsystem ObsState values from the state store;

  • computes the candidate aggregated ObsState through the observation model;

  • selects the active command context, when available;

  • evaluates the consistency policy;

  • updates diagnostic attributes;

  • executes the returned policy action;

  • returns an evaluation outcome to the generic supervision loop.

The supervisor is responsible for applying the decision. The policy is responsible for classifying the state distribution and expressing the intended action.

Consistency faults

If the policy returns a FAULT action, the supervisor latches the CSP Subarray into FAULT with cause CONSISTENCY.

This condition is reported through the scan or observation consistency diagnostic attributes, depending on the policy being evaluated.

A consistency fault is cleared only when the inconsistency is no longer present and the current fault cause is CONSISTENCY.

Relationship with specialised policies

Specialised policies reuse the base consistency policy to preserve the default CSP.LMC observation behaviour.

For example, the scan consistency policy uses the base policy to preserve the standard inconsistency handling model, but adds scan-specific rules for SCANNING. The scheduled scan policy further specialises scan handling to support the pending phase between Scan command completion and actual scan execution.

This layered model avoids introducing separate and incompatible consistency models for different observation phases.