Scheduled scan policy

Purpose

The scheduled scan policy extends the scan consistency policy to support scans that are accepted before their actual execution starts.

It does not replace the scan policy or the base observation consistency policy. The base policy defines the generic CSP.LMC inconsistency handling model. The scan policy specialises that model for SCANNING. The scheduled scan policy adds the rules required to interpret the pending phase of a scheduled scan.

This keeps scheduled scan handling aligned with the standard CSP.LMC consistency model.

Pending phase

A scheduled scan introduces a pending phase between Scan command completion and actual scan execution.

During this phase:

  • the Scan command has been accepted;

  • the command may have completed;

  • the active command context may already have been removed;

  • the CSP Subarray may still be READY;

  • the actual scan has not yet entered SCANNING.

This state distribution is expected when a retained scheduled scan context is available. It must not be interpreted as an inconsistency only because the Scan command has completed.

Policy behaviour

The scheduled scan policy uses the retained scan context to distinguish between:

  • the default CSP consistency behaviour defined by the base policy;

  • a pending scheduled scan that is expected to keep the CSP Subarray in READY until the scheduled execution phase;

  • a scheduled scan that has started and is expected to drive the selected devices towards SCANNING;

  • a scheduled scan that has completed and is expected to settle out of SCANNING.

When no retained scheduled scan context is available, or when the current state distribution is not part of the scheduled scan lifecycle, the standard base and scan policy behaviour applies.

Relationship with retained scan context

The retained scan context is required because the Scan command can complete before the scheduled scan starts.

The scheduled scan policy consumes the retained context to preserve the command semantics after the active command context has been removed. The retained context identifies the accepted scan, the selected devices, and the schedule associated with the command.

Without this retained context, the policy would not be able to distinguish a valid pending scheduled scan from an unexpected failure to enter SCANNING.

Lifecycle completion

The retained scan context is preserved for the whole effective scan lifecycle.

For a scheduled scan, the Scan command can complete while the CSP Subarray is still READY and the scan is pending. The retained context must therefore survive command completion and remain available until the scheduled scan has actually run.

The cleanup condition is based on an observed transition out of SCANNING: the retained scan context is cleared when the previously published observation state was SCANNING and the newly evaluated observation state is no longer SCANNING.

The lifecycle can be summarised as follows:

Scheduled Scan command completed
    -> retained_scan_context preserved

Scheduled scan pending
    -> CSP Subarray may remain READY
    -> retained_scan_context preserved

Scheduled scan running
    -> CSP Subarray is SCANNING
    -> retained_scan_context preserved

Scheduled scan exits SCANNING
    -> CSP Subarray transitions to a state different from SCANNING
    -> retained_scan_context cleared

This ensures that the retained scan context remains available for all policy evaluations that belong to the scheduled scan lifecycle, including the pending phase, the transition into SCANNING, and the running scan phase.

A terminating command such as EndScan or Abort can also clear the retained context when it completes successfully and invalidates the running or pending scan lifecycle.

Summary

The scheduled scan policy is an extension of the existing consistency model.

The relationship can be summarised as follows:

Base observation consistency policy
    -> generic CSP.LMC inconsistency handling

Scan consistency policy
    -> scan-specific handling while the subarray is scanning

Scheduled scan policy
    -> pending-phase handling for accepted scheduled scans
    -> preservation of READY before the scan starts
    -> preservation of SCANNING while the scheduled scan is running
    -> release when the scheduled scan lifecycle completes

Scheduled scan support therefore does not introduce a separate consistency model. It adds scheduled-scan-specific semantics to the existing base and scan policy behaviour.