Details
-
Architectural Decision
-
Resolution: Done
-
None
-
None
Description
Why now? Required for SDP to be able to allocate ingest as envisaged for multi-scan observations, see SS-37
Scope: SDP, CSP, TM
Quality: Performance/Latency, Modifiability
Currently CSP is expected to produce a link map at some point after configuration, which should then presumably be used by SDP to decide how to deploy receive and configure the network.
This is a mismatch with SDP's architecture - processing will be deployed per scheduling block, which happens on coarser time scales than CSP configurations (which happen per scan). So the way this information is currently conveyed it would in most cases be way too late for SDP to do anything with it.
And even if it did - this would presumably suggest that SDP waits with its configuration until this has been received via TANGO attribute update, making (re-)configuration slower and more brittle overall.
Attachments
Issue Links
- relates to
-
- decided
-
SS-37 Enable multi-scan capability in the MVP, including reconfigurations
-
- Done
-
-
-
- Done
-
-
SP-689 Receive workflows implement Scan / Configure logic
-
- Discarded
-
-
- decided
- mentioned in
-
Page Loading...
-
-
-
-
-
-
- mentioned on
- Wiki Page
-