MID.CSP LMC Documentation
MID.CSP LMC Documentation
The top-level software components provided by Mid.CSP LMC API are:
Mid.CSP Alarm Handler
Mid.CSP Logger
Mid.CSP TANGO Facility Database
VCC Capability (receptors)
Components listed above are implemented as TANGO devices, i.e. classes that implement standard TANGO API. The CSP.LMC TANGO devices are based on the standard SKA1 TANGO Element Devices provided via the SKA Base Classes.
Mid.CSP LMC Controller
Mid.CSP Controller is the top‐level TANGO Device and the primary point of contact for monitor and control of the Mid.CSP Sub-syste.
The Mid.CSP Controller represents Mid.CSP Sub-system as a unit for control and monitoring for general operations.
Mid.CSP Controller main roles are:
To be the central control node for Mid.CSP. The Controller provides a single point of access for control of the Mid.CSP as a whole, this includes provision for housekeeping and supervisory commands including: power‐up, power‐down, power management, restart (re‐initialize), support for firmware and software upgrades, etc.
To provide rolled‐up reporting for the overall Mid.CSP status. Mid.CSP Controller monitors and intelligently rolls‐up status reported by Mid.CSP equipment, sub‐arrays and capabilities and maintains a standard set of states and modes, as defined in the document “SKA1 Control System Guidelines”. State transitions are reported using standard TANGO mechanism.
To implement a set of attributes that represent the status and configuration of the Mid.CSP as a whole and, where required, report availability, status and configuration of the Mid.CSP equipment, components and capabilities (in the form of lists or tables or JSON string).
To maintains the pool of resources (VCCs, FSPs, Search/Timing/VLBI beams), keep track of allocation to sub‐arrays and provide reports on resource availability, allocation, and more.
Mid.CSP Controller implementation is based on (derived from) the standard SKA1 TANGO Device Controller; Mid.CSP Controller implements the standard TANGO API, aligned with the document “SKA1 Control System Guidelines”.
The interface is between a TANGO client and a TANGO Device. The TANGO Device exposes attributes and commands to clients.
The roles of the interfacing systems are:
TANGO Clients: Mid.TMC sub-system TANGO client(s).
TANGO Device: Mid.CSP sub-system implements Mid.CSP Controller.
The clients use requests to obtain read and/or write access to TANGO device attributes, and to invoke TANGO device commands.
Mid.CSP Controller TANGO Device name
The Mid.CSP Controller TANGO Device name is defined in the document “SKA1 TANGO Naming Conventions”:
mid-csp/control/0
Mid.CSP Controller TANGO Device Properties
The Mid.CSP Controller device has a standard set of properties inherited from the SKA Controller TANGO Device and a number of specific properties documented in the Controller API section.
Mid.CSP Controller TANGO Device States and Modes
Mid.CSP Controller implements the standard set of state and mode attributes defined by the SKA Control Model.
Mid.CSP Controller reports on behalf of the Mid.CSP Sub-system – unless explicitly stated otherwise, the state and mode attributes implemented by the Mid.CSP Controller represent the status of the Mid.CSP as a whole, not the status of the Mid.CSP Controller itself.
Mid.CSP Controller operational state
The Mid.CSP Controller supports the following sub-set of the TANGO Device states:
UNKNOWN: Mid.CSP is unresponsive, e.g. due to communication loss. This state cannot be reported by CSP itself.
OFF: power is disconnected. This state cannot be reported by CSP itself
INIT: Initialization of the monitor and control network,equipment and functionality is being performed. During initialization commands that request state transition to OFF (power-down) or re‐start initialization are accepted.
DISABLE: Mid.CSP is administratively disabled, either by setting adminMode=OFFLINE or NOT-FITTED. Basic monitor and control functionality is available but signal processing functionality and related commands are not available. All sub‐arrays are empty (OFF) and IDLE; all resources (receptors, tide‐array beams) are placed in the pool of unused resources.)
STANDBY: Low‐power state, Mid.CSP uses < 5% of nominal power. Basic monitor and control functionality is available, including the commands to request state transition to ON, OFF, DISABLE, or INIT. Signal processing functionality and related commands are not available. All sub‐arrays are empty (OFF) and IDLE; all resources (receptors, tide‐array beams) are placed in the pool of unused resources.).
ON: At least a minimum of CSP signal processing capability is available; at least one receptor and one sub‐array can be used for observing (either for scientific observations or for testing andmaintenance). Mid.CSP is in normal operational state, all commands, including commands to increase/decrease functional availability and power consumption are available.
ALARM: Quality Factor for at least one attribute crossed the ALARM threshold. Part of Mid.CSP functionality may be unavailable.
FAULT: Unrecoverable fault has been detected, Mid.CSP is not available for use at all, maintainer/operator intervention is required in order to return to ON, STANDBY, or DISABLE. Depending on the extent of failure commands restart and init, as well as status reporting may be available.
Mid.CSP Controller TANGO Device Commands
Mid.CSP Controller implements the standard set of commands as specified in:
Standard set of TANGO Device commands as defined in TANGO User Manual
Standard set of SKA TANGO Device commands
Command specific to Mid.CSP Controller as described in API section.
Mid.CSP makes provision for TM to request state transitions for individual sub‐systems and/or Capabilities.
Mid.CSP Controller TANGO Device Attributes
Mid.CSP Controller implements the standard set of attributes as specified in:
Standard set of TANGO Device attributes as defined in TANGO User Manual
The standard set of SKA TANGO Device attributes as defined for the SKA Controller TANGO Device.
Attributes to Mid.CSP Controller as described in API section.
The Mid.CSP Controller maintains the ‘pool of resources’ and is able to provide information regarding sub‐array membership, status and usage.
Mid.CSP LMC Capabilities
The Mid CSP.LMC Capabilities provide a layer of abstraction to allow the TM to set, control and monitor signal processing, and other sub-system functions, without being aware of the details of the Mid CSP implementation.
Each Mid CSP.LMC Capability represents a subset of the Mid.CSP functionality and uses a subset of the Mid.CSP hardware and software resources.
VCCs (Very Coarse Channelizer): 197
FSPs (Frequency Slice Processor): 27
PSS (Pulsar Search Beams): 1500.
PST (Pulsar Timing Beams): 16
The Capabilities implemented by the Mid.CSP can be classified in two groups, as follows:
The Capabilities inherent to the sub-arrays or other Capabilities; such Capabilities are created during initialization and are permanently assigned to a particular sub-array or Capability. A Capability can be enabled/disabled, but cannot be removed and/or assigned to another subarray.
The Capabilities that are function of resources: these are created during initialization and assigned to a pool of unused resources. Individual instances of these resources may be assigned to subarrays, as commanded by the TM. In some cases the same instance may be used in a shared manner by more than one subarray.
Each Mid.CSP Subarray has the following inherent Capabilities that correspond to Processing Modes, and are configured via scan configuration:
Correlation,
PSS,
PST,
VLBI (beamforming and correlation in support of VLBI), and
Transient Data Capture.
The Capabilities listed above are configured and controlled via a subarray; when a subarray does not perform correlation, its Capability Correlation is OFF; the same applies for all Processing Modes.
The top-level Mid.CSP Capabilities associated to schedulable resources are reported in the table below:
Capability Name |
Resources |
Notes |
Frequency Observing Band |
197 VCCs (Very Coarse Channeliser) |
Support frequency bands:
|
FSP Processing Modes |
27 FSPs (Frequency Slice Processor) These resources are shareable among the subarrays |
Supported processing modes:
|
PSS Processing Mode |
1500 Search Beams |
Collects the HW, SW and processing modes of PSS: beams: This capability is a func of the following resources:
|
PST Processing Mode |
16 Timing Beams |
Collects the HW, SW and processing modes of PST: beams: This capability is a func of the following resources:
|
The previous list does not include VLBI. VLBI beamforming is configured per subarray per FSP, any further beam processing is performed by non-SKA1 equipment; there are no VLBI related Mid.CSP resources that have to be managed, other than the FSPs.
Mid.CSP LMC Subarray
The Mid.CSP Sub-array TANGO Device class is required as a common interface feature, as described in the document “SKA1 Control System Guidelines”.
Its purpose is to provide a point of access for configuration, execution and monitoring of signal processing functionality for each sub‐array independently.
Overview of the functionality
Add/release resources (receptors, beams) to/from the sub‐array. TM accesses directly the Mid.CSP Sub-array in order to add/release resources to/from sub‐arrays. The TM requests are validated by the Mid.CSP sub-array relying on the information maintained by the Mid.CSP Controller and Capability.
Set the frequency Band.
Configure the sub‐array Processing Modes using command Configure(). This includes configuration of the Capabilities used by the sub‐array.
Start/stop scan execution.
Set ‘engineering’ parameters for the sub‐arrays and Capabilities.
Receptors assignment
The assignment of receptors to a MID sub-array is performed in advance of a scan configuration.
Up to 197 receptors can be assigned to one sub-array.
Receptors assignment to a sub-array is exclusive: one receptor can be assigned only to one sub-array.
During assignment, the Mid.CSP sub-array performs both formal and more deep checks.
Formal control: - The assigned receptor list is empty. In this case, a warning is logged. - The receptor names are compliant to ADR-32. In this case, a warning is logged for each receptor not compliant and the receptor is excluded from the assigned list. - The assigned receptor list contains duplicated receptors. In this case, the duplicated receptor is removed from the list and a warning is logged.
Deep control: - The requested receptors are in the list of the deployed ones. - the requested receptors are already associated to another sub-array. In this case a warning message is logged.
In order for a Mid.CSP sub-array to accept a scan configuration, at least one receptor must be assigned to the sub-array.
Tied-array beams
Depending on the selected processing mode, Search Beams, Timing Beams and Vlbi Beams must be assigned to a MID sub-array in advance of a scan.
TM may specify the number of beams to be used or, alternatively, identify the Capability instances to be used via their TANGO Fully Qualified Domain Name (FQDN).
Scan configuration
TM provides a complete scan configuration to a sub-array via an ASCII JSON encoded string.
When a complete and coherent scan configuration is received and the sub-array configuration (or re-configuration) completed, the sub-array it’s ready to observe.
Once configured, Mid.CSP keeps the sub‐array and scan configuration until one of the following occurs:
Mid.CSP receives a command to release resources (receptors, FSPs, Search Beams and/or Timing Beams) used by the sub‐array.
Mid.CSP receives a command to transition to low‐power state (state=STANDBY); in which case the active scans end and resources are released.
Mid.CSP receives a command to shut‐down (OFF)
Mid.CSP monitor and control function fails so that the configuration is lost.
Inherent Capabilities
The following inherent Capabilities that correspond to Processing Modes, and are configured via scan configuration:
Correlation
PSS
PST
VLBI (beamforming and correlation in support of VLBI)
Transient Data Capture.
When a sub‐array does not perform correlation, its Capability Correlation is OFF; the same applies for all Processing Modes.
Control and Monitoring
Each Mid.CSP Sub-array maintains and report the status and state transitions for the Mid.CSP sub-array as a whole and for the individual assigned resources.
In addition to pre-configured status reporting, a Mid.CSP Sub-array makes provision for the TM and any authorized client, to obtain the value of any sub-array attribute.
Mid.CSP Sub-array TANGO Device name
The Mid.CSP Sub-array TANGO Device name is defined in the document “SKA1 TANGO Naming Conventions”:
mid-csp/subarray/XY
where XY is a two digit number in range [01,..,16].
Mid.CSP Sub-array operational state
Mid.CSP Sub-array intelligently rolls‐up the operational state of all components used by the sub‐array and reports the overall operational state for the sub‐array.
The Mid.CSP Sub-array supports the following sub-set of the TANGO Device states:
UNKNOWN: Mid.CSP sub-array is unresponsive, e.g. due to communication loss.
OFF: The sub-array is not enabled to perform signal processing. The sub‐array is ‘empty’.
INIT: Initialization of the monitor and control network,equipment and functionality is being performed.
DISABLE: Mid.CSP sub-array is administratively disabled, basic monitor and control functionality is available but signal processing functionality is not available.
ON: The sub-array is enabled to perform signal processing. The sub‐array observing state is EMPTY if receptors have not been assigned to the sub‐array, yet.
ALARM: Quality Factor for at least one attribute crossed the ALARM threshold. Part of functionality may be unavailable.
FAULT: Unrecoverable fault has been detected. The sub‐array is not available for use and maintainer/operator intervention might be required.
Mid.CSP Sub-array observing state
The sub‐array Observing State indicates status related to scan configuration and execution.
The Mid.CSP Sub-array observing state adheres to the State Machine defined by ADR-8.
Mid.CSP Sub-array TANGO Device Commands
Mid.CSP Sub-array implements the standard set of commands as specified in:
Standard set of TANGO Device commands as defined in TANGO User Manual
Standard set of SKA TANGO Device commands
Command specific to Mid.CSP Sub-array as described in API section.
Mid.CSP makes provision for TM to request state transitions for individual sub‐systems and/or Capabilities.
Mid.CSP Sub-array TANGO Device Attributes
Mid.CSP Sub-array implements the standard set of attributes as specified in:
Standard set of TANGO Device attributes as defined in TANGO User Manual
The standard set of SKA TANGO Device attributes as defined for the SKA Sub-array TANGO Device.
Attributes to Mid.CSP Sub-array as described in API section.
Virtually all parameters provided in scan configuration are exposed as attributes either by Mid.CSP Sub-array or by individual Capabilities.
Mid CSP.LMC Architecture
The architecture of the CSP.LMC software is the same for Low and Mid Telescope. Please refer to common documentation.
Project’s API
Below are presented the API for Classes specialized for Mid Telescope.
All the functionalities common to Mid and Low Telescope are developed in the project ska-csp-lmc-common
Mid.CSP LMC Devices API
Mid.CSP LMC modules API
Mid CSP Tango Clients Examples
In the following sections some itango interface examples are provided, to be easily applied to a generic python client.
Basic assumptions for each example are:
the system has been fresh initialized
the only CSP sub-system deployed is the CBF
CBF supports up to 4 VCCs and 4 FSPs
All TANGO operations (read/write/command_inout) are always successfully. No check on the results is done in the following examples.
To control CSP with itango, a proxy to CSP Controller and Subarrays has to be created:
csp_ctrl = tango.DeviceProxy('mid-csp/control/0')
csp_sub1 = tango.DeviceProxy('mid-csp/subarray/01')
csp_sub2 = tango.DeviceProxy('mid-csp/subarray/02')
csp_sub3 = tango.DeviceProxy('mid-csp/subarray/03')
It is possible also to create proxies to CBF controller and subarrays, in order to check their states and mode after a command is issued:
cbf_ctrl = tango.DeviceProxy('mid_csp_cbf/sub_elt/controller')
cbf_sub1 = tango.DeviceProxy('mid_csp_cbf/sub_elt/subarray_01')
cbf_sub2 = tango.DeviceProxy('mid_csp_cbf/sub_elt/subarray_02')
cbf_sub3 = tango.DeviceProxy('mid_csp_cbf/sub_elt/subarray_03')
Please note that all commands on subarray follow the ObsState state model defined in ADR-8. A CSP.LMC Subarray doesn’t allow commands from observing states other than those specified in this model.
After the deployment, all the Mid CSP.LMC devices are in following conditions: - state DISABLE. - healthState UNKNOWN - adminMode OFFLINE - obstState EMPTY (subarrays)
From now on, all the examples refers to these proxy objects. For Subarray commands, the proxy to subarray 1 will be used.
Mid CSP.LMC start communication
The Mid CSP.LMC Devices adminMode is a memorized attribute. That means that it is stored in the TANGO DB and its value is written to the devices just after the initialization. If the adminMode is MAINTENANCE(2)/ONLINE(3) the connection between Mid CSP.LMC Devices and the subsystem starts immediately. Otherwise, to start the communication use the following command:
csp_ctrl.adminMode = 2 #set to MAINTENANCE
or
- ::
csp_ctrl.adminMode = 3 #set to ONLINE
Mid CSP.LMC Controller forwards the adminMode value to its Subarrays and subordinated systems devices. The new states are the following for all the devices:
- state OFF
- healthState OK
- adminMode MAINTENANCE(2)/ONLINE(3)
- obstState EMPTY (subarrays)
Power-on (off/standby) the Mid.CSP
To power on the Mid.CSP devices, issue the command:
csp_ctrl.On([]) # empty list: power on all the available sub-systems (CBF, PSS, PST)
or
csp_ctrl.On(['mid_csp_cbf/sub_elt/controller', ]) # power-on only the specified sub-systems
The command returns immediately the following list:
- ::
[array([2], dtype=int32), [‘1679401117.9451234_224758016395799_On’]]
- Where:
2 is the command status (2 means QUEUED)
‘1679401117.9451234_224758016395799_On’ is a unique id assigned to the command. It can be used to track the execution status of the command
It is possible to read the command result state using:
cmd_result = csp_ctrl.commandResult
cmd_result is a Tuple of two strings:
the first element is the name of last executed CSP task
the second one is the result code: allowed values for the result code are defined in SKA Base Classes module ska_tango_base.commands
Possible results for the current example are:
(‘on’, ‘0’) # On task completed successfully
(‘on’, ‘1’) # On task started
(‘on’, ‘3’) # On task completed with failure
Some of the long running command attributes can also be accessed. Long running command result can be read using:
long_running_command_result = csp_ctrl.longRunningCommandResult
long_running_command_result is a Tuple of a string and a list:
the first element is a command id assigned when command is invoked
the second element is a list of result code (matching the value in command result attribute described above) and result message
Possible results:
(‘1684312814.139426_265125881596693_On’, ‘[0, “on completed 1/1”]’) # On task completed successfully on one devices
(‘1684312814.139426_265125881596693_Configure’, ‘[0, “configure completed on components 2/2”]’) # Configure task completed successfully on two devices
(‘1684312814.139426_265125881596693_Off’, ‘[3, “off completed 1/1”]’) # Off task completed with failure on one device
It is also possible to access long running command status at the various stages of command execution. This attribute can be read using:
long_running_command_status = csp_ctrl.longRunningCommandStatus
long_running_command_status is a Tuple of pairs of strings. In each pair the elements represent the following:
the first element is a command id assigned when command is invoked
the second element is the task status: allowed values for the task status are defined in SKA Base Classes module ska_tango_base.executor
Possible results:
(‘1684312814.139426_265125881596693_On’, ‘QUEUED’)
(‘1684312814.139426_265125881596693_On’, ‘IN_PROGRESS’)
(‘1684312814.139426_265125881596693_On’, ‘COMPLETED’)
(‘1684312814.139426_265125881596693_On’, ‘ABORTED’)
(‘1684312814.139426_265125881596693_On’, ‘FAILED’)
(‘1684312814.139426_265125881596693_On’, ‘REJECTED’)
Note that there can be more than one pair of command id and task status in the attribute, if there are more commands invoked.
The command On invoked on the Mid.CSP Controller is forwarded to the Mid CBF sub-system Controller and to all the Mid.CSP Subarrays. This can be checked by the state of all controllers and subarrays:
csp_ctrl.state() -> ON
csp_sub1.state() -> ON
csp_sub2.state() -> ON
csp_sub3.state() -> ON
cbf_ctrl.state() -> ON
cbf_sub1.state() -> ON
cbf_sub2.state() -> ON
cbf_sub3.state() -> ON
The same logic and syntax apply also for Off and Standby commands.
Assign resources to a Mid CSP.LMC Subarray
To assign resources to a subarray both the subarray and controller devices must be in ON operational state. To move the system in such a state, please follow the previous example. Please note that right now only the receptor ids SKA001, SKA022, SKA103, SKA104 can be assigned to a subarray.
The following JSON string can be used to assign receptors to the Mid CSP.LMC:
json_string = '{"subarray_id": 1,"dish":{ "receptor_ids":["SKA001", "SKA022"]}}'
On successfully assignment, the receptors SKA001 and SKA022 are affiliated to subarray 1.
Invoke the AssignResources command on Mid.CSP Subarray 1:
csp_sub1.assignresources(json_string)
If command is successful, the command result will report:
csp_sub1.commandResult -> ('assignresources', '0')
csp_sub1.commandResultName -> 'assignresources'
csp_sub1.commandResultCode -> '0'
The receptors assigned to Mid.CSP Subarray 1 are:
csp_sub1.assignedReceptors -> ("SKA001", "SKA022")
Information about resources availability are provided by the Mid.CSP Controller.
To get the list of all the receptors:
csp_ctrl.receptorsList -> ("SKA001", "SKA022", "SKA103", "SKA104")
To get the list of the available receptors:
csp_ctrl.unassignedReceptorIDs -> ("SKA103", "SKA104")
To get the affiliation of the receptors to the subarrays:
csp_ctrl.receptorMembership -> [1, 1, 0, 0]
After resource allocation the Mid CSP.LMC and Mid CBF Subarray obsState attribute value changes from EMPTY to IDLE. To check the observing state of the devices:
csp_sub1.obsstate -> IDLE
cbf_sub1.obsstate -> IDLE
Configure, issue and end a scan
After a Subarray has resources assigned, it is possible to configure it and then start a scan.
The json_string to be used for configure and scan can be found here.
They have to be assigned to a variable and sent as command input as showed above for assignresources.
First of all, Configure command has to be issued:
csp_sub1.configure(json_string_configure)
The observimg state will be in CONFIGURING during the execution. After that, if the command is successful:
csp_sub1.commandResult -> ('configure', '0')
csp_sub1.obsstate -> READY
cbf_sub1.obsstate -> READY
The subarray in READY observing state can be re-configured with a new configuration that overwrites the previous one.
When the subarray is READY, a scan can be started, issuing the Scan command:
csp_sub1.scan(json_string_scan)
If the command is successful:
csp_sub1.commandResult -> ('scan', '1')
csp_sub1.obsstate -> SCANNING
cbf_sub1.obsstate -> SCANNING
Note that the result code associated to the Scan command will remain ‘1’ for all the duration of the scanning process. In fact, according to ADR-8 a scan can be interrupted by the EndScan or the Abort command. The Abort command has to be intended as an emergency call that interrupts abruptly the scan process. On the other side, the EndScan first ensures that all the processes are correctly managed.
To end a scan, just issue:
csp_sub1.endscan()
After EndScan is successful, the subarray obsState is READY, and another scan can be issued with the same configuration.
On the other side, if the scan is aborted, the obsState will go (after a short time in ABORTING) to ABORTED state To perform a new scanning, the subarray observation should be restarted (via the ObsReset command) and a new configuration need to be sent (ADR-8)
The sequence of operation is:
csp_sub1.abort()
csp_sub1.commandResult -> ('abort', '1')
csp_sub1.obsstate -> ABORTING
csp_sub1.commandResult -> ('abort', '0')
csp_sub1.obsstate -> ABORTED
csp_sub1.obsreset()
csp_sub1.commandResult -> ('obsreset', '1')
csp_sub1.obsstate -> RESETTING
csp_sub1.commandResult -> ('obsreset', '0')
csp_sub1.obsstate -> IDLE
Go To Idle and Release Resources
The resources of a subarray can only be released when its obsState is IDLE. When the subarray is in READY (as happens after the end of a scan) it must first be sent to IDLE with the command:
csp_sub1.gotoidle()
Upon successful completion of the command, the obsState will be IDLE and the resources can be partially or totally removed from the subarray.
To partially remove some of the allocated resources, a json string, like the one used for assign resources (see above) should be sent. This string must specify the receptors to be removed.
Following the previous example, to remove the receptor 1 from the list of the assigned receptors to the Mid CSP.LMC Subarray 1:
json_string = '{"subarray_id": 1,"dish":{ "receptor_ids":["SKA001"]}}
csp_sub1.ReleaseResources(json_string)
On command success, the subarray will have only receptor 2 assigned to it, and its obsState will stay in IDLE. The released receptor (1) will now appear in the pool of the Mid CSP.LMC available resources. This can be verified, accessing the proper attributes of the Mid CSP.LMC Subarray and Controller devices:
csp_sub1.commandResult -> ('releaseresources', '0')
csp_sub1.obsstate -> IDLE
csp_sub1.assignedReceptors -> ["SKA022"]
csp_ctrl.receptorsList -> ["SKA001", "SKA022", "SKA103", "SKA104"]
csp_ctrl.unassignedReceptorIDs -> ["SKA001", "SKA103", "SKA104"]
csp_ctrl.receptorMembership -> [0, 1, 0, 0]
Otherwise, if all resources are meant to be removed, this can be done with the ReleaseAllResouces command:
csp_sub1.ReleaseAllResources()
On command success, the subarray will be EMPTY again:
csp_sub1.commandResult -> ('releaseallresources', '0')
csp_sub1.obsstate -> EMPTY
csp_sub1.assignedReceptors -> []
csp_ctrl.unassignedReceptorIDs -> ["SKA001", "SKA022", "SKA103", "SKA104"]
csp_ctrl.receptorMembership -> [0, 0, 0, 0]
Recover a MID CSP>LMC observing TANGO Device from a FAULT obsState: Restart
If something goes wrong with the observation, the obsState of the Mid CSP.LMC Subarray could transition to FAULT. Note that this condition differs from the one where the State of a TANGO Device is in FAULT (see below). To recover from this situation, issue the Restart command. This command will release also all the resources, bringing the subarray into an EMPTY obsState.
The sequence of operations and responses is:
csp_sub1.obsState -> FAULT
csp_sub1.Restart()
csp_sub1.commandResult -> ('restart', '1')
csp_sub1.obsState -> RESTARTING
csp_sub1.commandResult -> ('restart', '0')
csp_sub1.obsState -> EMPTY
Recover a Mid CSP.LMC TANGO Device from a FAULT State: Reset
When an internal error occours in the Mid CSP.LMC Subarray or in the Controller, the operational state (State) of the device can transition to FAULT. To recover from this condition, the Reset command needs to be issued. Successufull execution of this command will return the device in its initial state, that is OFF/EMPTY for Subarray and STANDBY for the Controller.
Turning OFF a Subarray
The Off command disables any signal processing capability of a subarray and all its allocated resources are also released. As for the ADR-8, this command can be issued fron any observing state.
Depending on the current observing state of the Mid CSP.LMC Subarray, the Off command can be replaced by a sequence of commands that properly bring the device in the desired final state. An approach that works for nearly all the observing states is the following one, where the Off command is replaced by the following commands, executed one after the other: - Abort: transition the subarray from the current observing state to ABORTED. This command can be issued from all the observing states except: EMPTY and FAULT. In these cases, this step is skipped and the first command invoked must be Restart. - Restart: transition the subarray from ABORTED to EMPTY/ON - Off: transition the subarray from ON to OFF.
For further details of the intermediate commands, see examples above.
Connect to the FSP Processing Modes Capability Device
- To connect to the capability device::
fsp_cap_proxy = tango.DeviceProxy(‘mid-csp/capability-fsp/0’) fsp_cap_proxy.state() = DevState.ON
After Controller power-up:
fsp_cap_proxy.fspAvailable = [1,2,3,4]
- After configuring Mid CSP Subarray 1 for correlation using FSP1 and FSP2::
fsp_cap.fspCorrelation = [1] fsp_cap.fspFunctionMode = [‘CORR’, ‘CORR’, ‘IDLE’, ‘IDLE’] fsp_cap.Available = 2
Json Command Input Templates
The following templates can be used as input for the specific command. They are those used in Mid CSP.LMC integration tests.
Assign Resources
{
"subarray_id": 1,
"dish":{
"receptor_ids":["SKA001", "SKA022", "SKA103", "SKA104"]
},
"pss":{
"beams_id":[1,2,3]
},
"pst":{
"beams_id":[1, 2]
}
}
Configure
{
"interface": "https://schema.skao.int/ska-csp-configure/2.0",
"subarray": {
"subarray_name": "science period 23"
},
"common": {
"config_id": "sbi-mvp01-20200325-00001-science_A",
"frequency_band": "1",
"subarray_id": 1
},
"cbf": {
"delay_model_subscription_point": "ska_mid/tm_leaf_node/csp_subarray_01/delayModel",
"fsp": [
{
"fsp_id": 1,
"function_mode": "CORR",
"frequency_slice_id": 1,
"integration_factor": 1,
"zoom_factor": 0,
"channel_averaging_map": [
[0, 2],
[744, 0]
],
"channel_offset": 0,
"output_link_map": [
[0, 0],
[200, 1]
]
},
{
"fsp_id": 2,
"function_mode": "CORR",
"frequency_slice_id": 2,
"integration_factor": 1,
"zoom_factor": 1,
"zoom_window_tuning": 650000,
"channel_averaging_map": [
[0, 2],
[744, 0]
],
"channel_offset": 744,
"output_link_map": [
[0, 4],
[200, 5]
],
"output_host": [
[0, "192.168.1.1"]
],
"output_port": [
[0, 9744, 1]
]
}
],
"vlbi": {}
},
"pss": {
"pss_beams": [
{
"pss_beam": 1
},
{
"pss_beam": 2
}
]
},
"pst": {},
"pointing": {
"target": {
"system": "ICRS",
"target_name": "Polaris Australis",
"ra": "21:08:47.92",
"dec": "-88:57:22.9"
}
}
}
Scan
{
"interface": "https://schema.skao.int/ska-csp-scan/2.2",
"scan_id": 11
}