Presentation is loading. Please wait.

Presentation is loading. Please wait.

SDP Interface Identification

Similar presentations


Presentation on theme: "SDP Interface Identification"— Presentation transcript:

1 SDP Interface Identification
Simon Ratcliffe, Paul Alexander, Bojan Nicolic and Chris Broekma

2 Interfaces Physical / Mechanical Power Data Transport
Telescope Manager Central Signal Processor User Supplied Equipment Human-Machine Interface Performance Aspects

3 Physical / Mechanical Location (on/off site) of SDP may differ between Australia and SA. SDP itself may be physically split along functional lines. Provision of racks could be complicated by heterogeneous design with wide variety of requirements (e.g. extra depth, water cooling, etc...) Perhaps an ITT across CSP, SDP and TM could like at something like Open Compute and see how this could meet the requirements. Deployment model will be essential to mesh with the early science / commissioning program.

4 Power Obviously an important criteria – presumably the interface driven from the system level and so SDP will be provided with a power budget ? Decisions around power provision, e.g. DC vs AC will probably need to be ITT driven. This decision must be made as early as possible. Power availability and cost curves should be included in the interface to allow energy efficient scheduling. Remote power switching required to the rack level at the very least.

5 Data Transport Current understanding that intra-SDP communications will be handled by SDP, but all external interfaces (CSP, TM, etc..) provided by SaDT. Common protocol for bulk exchange (CSP internal, CSP → SDP, SDP → external) would be highly beneficial. Energy considerations for bulk data are of prime importance, particularly on the receiving end. Suggest SDP lead (or co-lead) of ITT on this topic.

6 Telescope Manager Likely to be most complex interface involving SDP.
Control and Monitoring will be via single SDP proxy that provides a somewhat “black box” view of the SDP. Should provide a rich enough interface to allow scheduling and resource management. Meta-data interface likely to be separate

7 Telescope Manager Most critical aspect relates to metadata:
Some metadata is time critical e.g. antenna activity sensors. Different observations require different pre-defined sets of sensors. In general, any piece of metadata should be obtainable from TM. Operations concept is important – we may have to provide ILS interfaces directly to the end user, rather than via TM. SDP also needs to provide a variety of meta information back to TM such as calibrator catalogues, pointing model parameters etc...

8 Central Signal Processor
Primary concern is data rate and when we can put specifications to this. Boundary is extremely fluid, and depends on physical implementation (e.g. software correlator) and functional allocation. Most of the ingest functions (spectral/temporal averaging, data corrections, format conversions, gain calibration etc...) could be performed on either side of the boundary. One possibility is to simplify the CSP->SDP interface at the expense of increased data rate i.e. provide more flexibility in the SDP rather than CSP. Timing and synchronisation: Slaved to time information encoded in CSP data and TM metadata.

9 User Supplied Equipment
Not mentioned in baseline design. Should consider catering for this eventuality, particularly from the flexibility it brings. SDP could provided packaged data stream with raw data, meta data and calibration information.

10 Human-Machine Interface
We will have a number of user facing interfaces, including those for expert users of the system. Will we have common User Interface guidelines to control aspects such as look and feel, authentication and authorisation, interface technologies etc... Does SDP provide interfaces to realtime data quality metrics, or simply pass these to TM ?

11 Performance Aspects Many of the SDP performance requirements will be impacted by upstream components. Need to ensure that the allocation of the system error budget is done in an holistic fashion. Interfaces that specify or constrain such performance parameters need to be closely monitored.

12 Major Questions to Answer
Functional allocation boundaries between various subsystems, particularly SDP ↔ CSP and SDP ↔ TM. Phase 1 constraints: Power Physical Space Integration of precursor technology Location of SDP (baseline design calls for entire SDP to be located in Cape Town & Perth) Role of ITTs and how they will be formed.

13 Interfaces Summary Function TM SaDT CSP Infrastructure SDP → Users
Ingest (bulk) Physical Logical Ingest (meta) M&C Data Transport (site → off-site) (site → world) Power Cooling Thermal Presentation Layer Logical ? Logical?


Download ppt "SDP Interface Identification"

Similar presentations


Ads by Google