Scheduled scan

A scheduled scan is a Scan command that has been accepted before the actual scan execution is expected to start.

Unlike a legacy scan, a scheduled scan does not necessarily drive the CSP Subarray to SCANNING immediately after the Scan command completes. The scan command can complete while the CSP Subarray is still READY and the actual scan remains pending until its scheduled start time.

This introduces two different lifecycles:

• the long-running command lifecycle of the Scan command;

• the observation lifecycle of the actual scan execution.

The command lifecycle ends when the controlled subsystems acknowledge the Scan command and the command completion path finishes. The observation lifecycle ends only when the scheduled scan has actually run, or when it is explicitly terminated or cancelled.

The devices expected to participate in the scheduled scan are the planned scan devices stored in the Scan command context. They are derived from the effective configured device set described in Configured devices for scan.

Pending scheduled scan

A scheduled scan is pending when the Scan command has been accepted and completed, but the actual scan has not yet entered SCANNING.

During this phase, the CSP Subarray can remain in READY. This is expected behaviour and must not be interpreted as a failure to start scanning. The accepted scan schedule and the scan command semantics are preserved in the retained scan context so that the observation supervisor can later interpret the transition to SCANNING as the expected effect of the scheduled scan.

The pending phase can be summarised as follows:

Scheduled Scan command accepted
    -> Scan CommandContext created
    -> schedule stored in the context
    -> context registered as active

Scheduled Scan command completed
    -> command outcome stored in the context
    -> context removed from active command registry
    -> context retained as retained_scan_context

Scan is pending
    -> CSP Subarray may still be READY
    -> retained_scan_context preserves the scheduled scan semantics

Scheduled scan starts
    -> controlled devices move towards SCANNING
    -> retained_scan_context used by the scan consistency policy

Observation consistency

The scan consistency policy uses the retained scan context to evaluate scheduled scan transitions.

While the scheduled scan is pending, the CSP Subarray may remain in READY. When the controlled devices start the scan, the policy can use the retained context to identify the transition towards SCANNING as expected. The context also identifies the devices that are expected to participate in the scan, so the policy does not need to infer the scan target set again from the raw device state distribution.

The scheduled scan lifecycle is complete when the scan has entered SCANNING and the controlled devices subsequently settle out of SCANNING. At that point, the retained scan context can be cleared.

Scan allowance

A new Scan request must be rejected when a previous scheduled scan is still pending.

Accepting another Scan request while a scheduled scan is pending would risk replacing or invalidating the retained context required to complete the previous scheduled scan consistently. For this reason, the scan allowance check rejects a new scan request when a retained scheduled scan context is still pending.

This guarantees that there is only one active or pending scan lifecycle associated with the CSP Subarray at a time.

Scheduled scan consistency policy

Scheduled scan consistency is evaluated as a specialization of the standard CSP observation consistency policy.

The scheduled scan policy does not replace the base policy. It relies on the base policy to define the default CSP Subarray behaviour, including how observation state inconsistencies are detected, represented, and resolved. The scheduled scan logic only adds the extra command-aware rules required to interpret a scan that has been accepted but has not yet started.

This is important because scheduled scans introduce an additional phase that does not exist for legacy scans. After the Scan command has completed, the CSP Subarray can legitimately remain in READY while the scan is pending. This state distribution must not be interpreted as an inconsistency only because the Scan command has already completed.

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 its start time;

• 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 CSP observation consistency rules apply.

The relationship can be summarised as follows:

Base CSP observation consistency policy
    -> defines the default CSP Subarray behaviour
    -> detects and handles generic observation inconsistencies

Scheduled scan policy
    -> reuses the base policy behaviour
    -> adds scheduled-scan-specific interpretation
    -> preserves READY while the scan is pending
    -> preserves SCANNING while the scheduled scan is running
    -> releases control when the scheduled scan lifecycle is complete

This ensures that scheduled scan support does not introduce a separate and incompatible consistency model. It extends the existing CSP consistency policy only for the parts of the observation lifecycle that require scheduled scan-specific semantics.