MCCS Allocation, Configuration and Scan Control
Purpose
MCCS must configure its components (in the end, the SPS physical devices) to perform a specific observation. Observation is specified in terms of independent subarrays. Each subarray is a logical virtual instument, which can perform observations independently of other subarrays.
The telescope manager (TM) has a fixed number of available subarrays. It assigns scans to subarrays, then asks the MccsController to allocate the necesary resources, and to assign these resources to the relevant MCCS devices.
The TM then configures the MccsSubarray (together with other subarray elements in other subsystems) for a specific observation. The MccsSubarray is responsible for orchestrating the configuration process, down to the hardware devices.
The actual observation is started using a Scan command, once the subarray has been correctly configured. Repeated Scan commands can be issued using the same configuration, or the subarray can be reconfigured between scans using the same allocated resources. Scans may be composed to execute more complex observations. Examples of single scans are:
A single point in a mosaic,
Multiple points using different simultaneous beams
A single line of a raster scan
The coordinate system can be altaz, sidereal, or centered on a particular solar system body (including body ephemeris). Definition of the usable coordinate systems is in progress. A tentative, generic format is adopted here, but it is likely to change in the future following ADR-63.
Allocate command
An observation is defined by a set of subarray beams. Resources are also allocated to subarray beams. Beams are conceptually independent, with the main difference between subarrays and subarray beams being that a subarray is synchronous: subarray beams in the same subarray are allocated, deallocated, configured and started at the same time.
Subarray beams are assigned by the TM, as they must correspond among different subsystems. Subarray beams are numbered (1-based) inside each subarray, different subarrays may have a subarray beam with the same ID. Each subarray beam is allocated:
a number of SPS channels (a total bandwidth)
a set of apertures, defined by a station and a substation ID. Station is statically assigned, the substation identifies the possibility of defining a different station footprint, but does not assign actual weights. Apertures are identified by a string of the form “APx.y” with x the station ID and y a unique substation ID.
The MccsController manages all resources in the MCCS system, especially hardware resources in the Tile Processing Modules. As these resources are identical for all TPMs in a station, these are managed inside a StationProxy device inside the controller. For each aperture the MccsController allocates:
a StationBeam device from a common pool
from the relevant StationProxy (note: this does not involve the actual MccsStation):
a HardwareBeam
the appropriate number of channel blocks. Each channel block corresponds to 8 SPS channels. Blocks are rounded up as needed.
If multiple apertures are using a station, a separate set of resources (hardware beam channel blocks) is allocated. When all resources are correctly allocated, MccsController issues a set of AllocateResources commands to the MccsSubarray device, and to the SubarrayBeam and StationBeam devices. The MccsStation is not involved in the allocation process.
The sequence diagram for the Allocate command is shown below.
![@startuml
participant Controller
participant StationProxy
participant ControllerResourceManager
participant Subarray
participant SubarrayBeam
participant StationBeam
hnote over Subarray: EMPTY
hnote over SubarrayBeam: EMPTY
hnote over StationBeam: EMPTY
== Collect subarray beam resources ==
loop stations
Controller->StationProxy: release_from_subarray(subarray_trl)
end
loop subarray_beams
loop apertures
Controller -> StationProxy: allocate(channels)
loop channel_blocks
StationProxy -> StationProxy: get_free_resources(channels)
end
StationProxy -[#red]-> Controller: channel_ids
StationProxy -[#red]> StationProxy: get_free_resources(station_beam)
StationProxy -[#red]-> Controller: station_beam_id
Controller -> ControllerResourceManager: get_free_resources(aperture)
ControllerResourceManager --> Controller: station_beam_trl
end
== Assign allocated resources ==
Controller -> Subarray: AssignResources()
loop subarray_beam_ids
Controller -> SubarrayBeam: AssignResources()
loop apertures
Controller->StationBeam: AssignResources()
hnote over StationBeam: IDLE
StationBeam --> SubarrayBeam: ObsState.IDLE
end
hnote over SubarrayBeam: IDLE
Subarray <-- SubarrayBeam: ObsState.IDLE
end
hnote over Subarray: IDLE
@enduml](../_images/plantuml-4e894a840748dff578636f413d01fcd21bc92925.svg)
Configure command
Configuration is managed by a MccsSubarray device. Configuration is defined in terms of subarray beams, too. Each subarray beam configuration includes:
a set of logical bands. Each logical band is defined by a start channel and a number of channels. Total number of channels must fit in the allocated channels (channel blocks) for the subarray beam.
a set of apertures. The Subarray device maintains a dictionary to map aperture ID to station IDs. For each aperture a weighting key reference string is used to select a station weighting function and/or a subaperture from a database. By default, all antennas in the station are uniformly weighted
pointing update rate. The time interval after which the pointing algorithm will recalculate delays and delay rates
pointing direction. Format for pointing specification is defined in ADR-63, as a field structure. The same information, with a slightly different syntax, is specified by the deprecated sky_coordinates structure, which will be discontinued in the future. It includes a reference frame ID (a string in a limited set of possible coordinate systems), two coordinates, and optionally two rates and a reference time (start time for applying the rate).
Configuration sequence is shown here:
![@startuml
participant TelescopeManager as TM
participant MccsSubarray as Subarray
participant MccsSubarrayBeam as SubarrayBeam
participant StationBeam
participant MccsStation
participant ApertureDB
participant StationCalibrator as Calibration
participant SpsStation
participant MccsTile
hnote over Subarray: IDLE
hnote over SubarrayBeam: IDLE
hnote over StationBeam: IDLE
TM -> Subarray: Configure()
activate Subarray
loop station
Subarray->MccsStation: DeallocateSubarray(subarray_id)
end
loop SubarrayBeam
Subarray -> SubarrayBeam: Configure()
loop StationBeam
SubarrayBeam->StationBeam: Configure()
StationBeam->ApertureDB: get_weights(weighting_key_ref)
ApertureDB-->StationBeam: weights, phase_centre
StationBeam->MccsStation: ConfigureChannels()
StationBeam->MccsStation: LoadBeamWeights(weights)
StationBeam->MccsStation: TrackObject()
MccsStation->MccsStation: add_pointing_request()
end
hnote over StationBeam: READY
hnote over SubarrayBeam: READY
SubarrayBeam->Subarray: change_state_callback()
end
loop station
Subarray->MccsStation: ApplyConfiguration()
activate MccsStation
MccsStation->SpsStation: SetBeamformerTable()
loop tiles
SpsStation->MccsTile: SetBeamformerTable()
end
note over MccsStation: LoadCalibrationCoefficients
loop frequency channels
MccsStation->Calibration: get_calibration(freq, cal_id)
Calibration-->MccsStation: calibration_coefficients
end
loop channel blocks
MccsStation->SpsStation: LoadCalibrationCoefficientsForChannels()
loop tiles
SpsStation->MccsTile: LoadCalibrationCoefficientsForChannels()
end
end
note over MccsStation: ApplyCalibration
MccsStation->SpsStation: SwitchCalibrationBank()
loop tiles
SpsStation->MccsTile: SwitchCalibrationBank()
end
note over MccsStation: (Not implemented ADR-111): start_beamformer
MccsStation--[#blue]> SpsStation: StartBeamformer()
loop tiles
SpsStation--[#blue]> MccsTile: StartBeamformer()
end
deactivate MccsStation
deactivate Subarray
end
hnote over Subarray: READY
@enduml](../_images/plantuml-daabb68eb0051027f035b5b0b97109916b69bbc4.svg)
Configuration is performed in 4 steps:
All Stations serving the Subarray are deconfigured. Information related to this subarray is cleared, so the MccsStation can merge together the information from different StationBeams
For each aperture, the configuration for the associated StationBeam is assembled. The StationBeam is identified by the ApertureId, using a dictionary.
The configuration is transmitted to the StationBeams, which translate it to commands for the Station. Station merges this information in tables for beamformer configuration and aperture weights.
the Stations are commanded to apply the assembled configuration
StationBeam unpacks the configuration structure to:
build a beamformer table. It computes the starting channel for each required channel block, and the total number of channels used by the configuration. The table is then forwarded to the MccsStation
save the pointing specification in a structure used by the pointing task. This task wil translate the pointing to delays and delay rates for each individual antenna. Station source tracking is started.
translate the aperture identifier to a set of antenna weights. Currently only uniform weighting is supported.
The MccsStation assembles the beamformer table entries from each StationBeam into a single beamformer configuration table. StationBeams for a station may belong to different subarrays. When the subarray beams have all completed their configuration, the Subarray instructs individual MccsStation to update the assembled information to the SpsStation. This happens in three steps:
The beamformer table is transmitted to the SpsStation, which will program the hardware TPMs.
LoadCalibrationCoefficients is invoked. Calibration coefficients are computed for each frequency channel, merged with the aperture weights, and sent to the SpsStation. Calibration is managed by the StationCalibrator device.
ApplyCalibration is invoked. This switches the calibration bank in the hardware TPMs.
(when earlyBeamformerStart is set): the beamformer is started for the affected channels
The beamformer is started at end of configuration following ADR-111 behavior. This guarantees that the CBF receives a stream of beamformed packets before the scan is started. The old behavior (beamformer started by the Scan command) is controlled using the earlyBeamformerStart attribute.
Scan and EndScan command
The Scan command initiates a scan. This places the Subarray and other ObsScan devices in SCANNING mode. The only behavioral change is that the packets sent to CBF have a scan_id field set to a nonzero value.
The Scan command can be terminated in three modes:
by an explicit EndScan command;
specifying the duration parameter in the Scan json structure;
by an Abort command.
The first two modes are functionally equivalent. The Scan command starts a thread, which waits for a scan_stop_event, with a timeout equal to the duration (if specified). The EndScan command just generates the event. When the event is received, or has timed out, the thread completes the scan, resets to zero the scan_id, and places the subarray in READY mode. To distinguish between the two scan termination conditions, the thread logs a different info message in the two cases.
The sequence diagram for the Scan command is the following.
The Abort command generates a special event, which gracefully terminates the thread, and then puts the subarray device in ABORTED mode, clearing the resources used in the involved stations. Depending on the command used to exit the ABORTED state, the subarray can return to IDLE or EMPTY states.
