Review Center Comments Report
SKA Phase 1
Review: System requirements review 6C: Consortia comments
v. 1
Start Date:
10 July 2015
Number of Approvers:
End Date:
20 September 2015
Moderator(s):
Wallace Turner
Finished:
Not Finished:
1.3
SKA1-SET-17
System Requirements
1.3.1
SKA1-FLD-805
Introduction
1.3.1.1
SKA1-FLD-806
Purpose of the Document
0
0
Number of Reviewers:
28
Finished:
Not Finished:
3
25
This document serves as a vehicle to communicate the high-level quantitative and qualitative characteristics of the SKA Phase 1 Observatory in the form of formal
requirements that are to be allocated to each of its constituent elements.
New diagram to be inserted
Figure 1 SKA Phase 1 System Requirements Specification Context
Figure 1 provides an initial simplified context assumed for this document in relation to other SKA documentation. There may be changes to the figure as the system
engineering process progresses.
This figure should be studied carefully since the SKA development process may not be as expected. In particular, the root document is not the Level 0 requirements;
There are no security, intellectual property, or privacy considerations attached to the use or distribution of this document.
1.3.1.1.1
SKA1-FLD-807
Approach
This document will reside within a requirements capture tool (Jama Contour) and for each requirement statement will include relational links back to the following
source documents:
•
Baseline Design + SKA-BD-17-13a and SKA-BD-17-13c rebase-lining documents presented to the SKA board.
21/09/2015 7:42 am
Page
1 of 196
•
•
Science Priority Outcome
Operations Concept Guidance
This document is a living document that will converge on the requirements for the SKA1 system. The convergence process is an iterative one between the SKA Office
and the consortia involved with the Element design work.
At present, some requirement statements have no traceability link available back to higher level source documents. These will usually be identified as TBJ (to be
justified). However, if no link is identified then it is to be assumed that this is the case. If the requirement cannot be justified it will be removed.
Each requirement identified within this document will have a unique four digit identifier preceded by a short hand prefix of "SYS_REQ_". The identifier is a truncation of
the "SKA1-SYS_REQ_" that is generated be generated by the requirements capture tool. It provides a useful reference tag and indicates where in the system
hierarchy the requirement resides.
Each requirement will identify the type of verification method.
The status of each requirement will be identified.
The allocation of requirements to Elements is provided in Appendix C of this document
The latest issued document will take precedence over the contents of the requirements capture tool. However, an issued Level 1 Requirement document represents a
requirements capture tool baseline. The data-base baseline identifier will be referenced in the document history.
Amendments to the document will be via change control. If accepted, amendments will be via the requirements capture tool. Up issue of this document will require a
new baseline and export from the requirements tool and subsequent submission and approval via the Document Management System.
1.3.1.1.2
SKA1-FLD-808
Verb Convention
"Shall" is used whenever a statement expresses a convention that is binding. The verbs "should" and "may" express non-mandatory provisions. "Will" is used to
express a declaration of purpose on the part of the design activity.
1.3.1.1.3
SKA1-FLD-1529 For but not with
"For but not with" in a requirement denotes that provision is to be made for a sub-assembly in the design but that such a sub-assembly is not necessarily to be
delivered. An example would be mount positions for feeds at the focal plane of an antenna that are not necessarily all to be immediately filled with feeds.
1.3.1.1.4
SKA1-FLD-1582 Parent Requirements
Parent Requirements: The Parent Requirement field denotes the source of information providing justification. The allowed values or types of value are:
•
•
"Root": No further justification is considered to be necessary. Rarely used.
"Established Precedent": There is a known precedent such as an existing computing centre at a given location.
21/09/2015 7:42 am
Page
2 of 196
•
•
•
•
Other requirement: Another requirement acts as justification.
Baselined SKA document: for example ConOps or Baseline design.
SKA document in preparation
Publically available document with established naming conventions such as standard, academic papers, DOIs.
Within this definition, we will provide a parent requirement for all requirements.
Parent Comment General
Michael Rupen
1.3.1.2
Scope of the Document
SKA1-FLD-809
17 August 2015
Note that some requirements give no-longer-existing requirements as Parents. I
presume there is some easy way in JAMA to check for these but will comment
on such requirements where I see them.
The Square Kilometre Array Phase 1 (SKA1) Level 1 Requirements Specification ultimately aims to provide:
•
•
•
A complete set of traceable level 1 requirements for the SKA1 Observatory allocated to each Element at the next level down in the observatory hierarchy.
Identify the verification method for each requirement presented
Allocate each requirement to the appropriate Element in the next level of the Observatory hierarchy
1.3.1.2.1
SKA1-FLD-810
Identification
The SKA Observatory is assumed to include all of the associated equipment, facilities, material, software, hardware, policy, technical documentation, services, and
personnel required for its operation.
1.3.10
SKA1-FLD-1091 Internal Interfaces
Parent Comment General
Wallace Turner
10 July 2015
Parent Comment General
Wallace Turner
10 July 2015
1.3.10.1
Rev6 comment Gie Han Tan
Propose to remove this section on internal interfaces between elements. These
interfaces are defined by the Telescope architecture models.
Reply to Gie HanTan
Agree in principle that these are L2 interfaces and can be removed. However,
suggest keeping these at present
No further action
SKA1-FLD-1092 AIV
21/09/2015 7:42 am
Page
3 of 196
1.3.10.1.1
SKA1-FLD-1093 MeerKAT to SKA1_mid CSP interface
1.3.10.1.1.1
SKA1-SYS_REQ- MeerKAT to SKA1_mid CSP interface.
2410
MeerKAT to SKA1_mid CSP interface. The interface between MeerKAT and SKA1_mid CSP shall be compliant with SKA-TEL.AIV.SE-TEL.CSP.SE-ICD-001
Interface Control Document
1.3.10.1.2
SKA1-FLD-1095 MeerKAT to SKA1_Mid SADT
1.3.10.1.2.1
SKA1-SYS_REQ- MeerKAT to SKA1_mid SADT interface.
2412
MeerKAT to SKA1_mid SADT interface. The interface between MeerKAT and SKA1_mid SADT shall be compliant with SKA-TEL.AIV.SE-TEL.SADT.SE-ICD-001
Interface Control Document
1.3.10.1.3
SKA1-FLD-1097 MeerKAT to SKA1_Mid TM
1.3.10.1.3.1
SKA1-SYS_REQ- MeerKAT to SKA1_mid SADT interface.
2414
MeerKAT to SKA1_mid SADT interface. The interface between MeerKAT and SKA1_mid SADT shall be compliant with SKA-TEL.AIV.SE-TEL.TM.SE-ICD-001
Interface Control Document.
1.3.10.1.4
SKA1-FLD-1567 MeerKat to SKA1_INFRA
1.3.10.1.4.1
SKA1-SYS_REQ- MeerKAT to SKA1_INFRA
2775
MeerKAT to SKA1_INFRA interface. The interface between MeerKAT and SKA1_INFRA shall be compliant with SKA-TEL.AIV.SE-TEL.INFRA.SE-ICD-001 Interface
Control Document.
1.3.10.2
SKA1-FLD-1099 Central Signal Processor
1.3.10.2.1
SKA1-FLD-1100 CSP to Infra
1.3.10.2.1.1
SKA1-SYS_REQ- CSP to Infra interface.
2416
CSP to Infra interface. The interface between CSP and Infra shall be compliant with the SKA-TEL.CSP.SE-TEL.INFRA.SE-ICD-001 Interface Control Document.
21/09/2015 7:42 am
Page
4 of 196
1.3.10.2.2
SKA1-FLD-1537 CSP to SDP
1.3.10.2.2.1
SKA1-SYS_REQ- CSP to SDP Interface
2738
CSP to SDP interface. The interface between CSP and SDP shall be compliant with the SKA-TEL.SDP.SE-TEL.CSP.SE-ICD-001 Interface Control Document
1.3.10.3
SKA1-FLD-1102 Dish
1.3.10.3.1
SKA1-FLD-1103 Dish to CSP
1.3.10.3.1.1
SKA1-SYS_REQ- Dish to CSP interface.
2418
Dish to CSP interface. The interface between CSP and Dish shall be compliant with the SKA-TEL.DSH.SE-TEL.CSP.SE-ICD-001 Interface Control Document.
1.3.10.3.2
SKA1-FLD-1104 DSH to Infra
1.3.10.3.2.1
SKA1-SYS_REQ- Dish to Infra interface.
2419
Dish to Infra interface. The interface between Dish and Infra shall be compliant with the SKA-TEL.DSH.SE-TEL.INFRA.SE-ICD-001 Interface Control Document.
1.3.10.4
SKA1-FLD-1105 Low Frequency Aperture Array
1.3.10.4.1
SKA1-FLD-1106 LFAA to CSP
1.3.10.4.1.1
SKA1-SYS_REQ- LFAA to CSP interface.
2420
LFAA to CSP interface. The interface between LFAA and CSP shall be compliant with the SKA-TEL.LFAA.SE-TEL.CSP.SE-ICD-001 Interface Control Document.
1.3.10.4.2
SKA1-FLD-1107 LFAA to Infra
1.3.10.4.2.1
SKA1-SYS_REQ- LFAA to Infra interface.
2421
LFAA to Infra interface. The interface between LFAA and INFRA shall be compliant with the SKA-TEL.LFAA.SE-TEL.INFRA AUS.SE-ICD-001Interface Control
21/09/2015 7:42 am
Page
5 of 196
Document.
1.3.10.5
SKA1-FLD-1108 SADT
1.3.10.5.1
SKA1-FLD-1109 SADT to DSH
1.3.10.5.1.1
SKA1-SYS_REQ- SADT to DSH interface. SADT, DSH
2422
SADT to DSH interface. The interface between SADT and DSH shall be compliant with the SKA-TEL.SADT.SE-TEL.DSH.SE-ICD-001 Interface Control Document.
1.3.10.5.2
SKA1-FLD-1110 SADT to LFAA
1.3.10.5.2.1
SKA1-SYS_REQ- SADT to LFAA interface.
2423
SADT to LFAA interface. The interface between SADT and LFAA shall be compliant with the SKA-TEL.SADT.SE-TEL.LFAA.SE-ICD-001 Interface Control
Document.
21/09/2015 7:42 am
Page
6 of 196
1.3.10.5.3
SKA1-FLD-1111 SADT to CSP
1.3.10.5.3.1
SKA1-SYS_REQ- SADT to CSP interface.
2424
SADT to CSP interface. The interface between SADT and CSP shall be compliant with the SKA-TEL.SADT.SE-TEL.CSP.SE-ICD-001 Interface Control Document.
1.3.10.5.4
SKA1-FLD-1112 SADT to SDP
1.3.10.5.4.1
SKA1-SYS_REQ- SADT to SDP interface.
2425
SADT to SDP interface. The interface between SADT and SDP shall be compliant with the SKA-TEL.SADT.SE-TEL.SDP.SE-ICD-001 Interface Control Document.
1.3.10.5.5
SKA1-FLD-1113 SADT to Infra
1.3.10.5.5.1
SKA1-SYS_REQ- SADT to Infra interface.
2426
SADT to Infra interface. The interface between SADT and Infra shall be compliant with the SKA.TEL.SADT.SE-TEL.INFRA.SE-ICD-001 Interface Control Document.
1.3.10.6
SKA1-FLD-1114 Telescope Manager
1.3.10.6.1
SKA1-FLD-1115 TM to DISH
1.3.10.6.1.1
SKA1-SYS_REQ- TM to Dish interface.
2427
TM to Dish interface. The interface between TM and Dish shall be compliant with the SKA-TEL.TM.SE-TEL.DSH.SE-ICD-001. Interface Control Document.
1.3.10.6.2
SKA1-FLD-1116 TM to LFAA
1.3.10.6.2.1
SKA1-SYS_REQ- TM to LFAA interface.
2428
TM to LFAA interface. The interface between TM and LFAA shall be compliant with the SKA-TEL.TM.SE-TEL.LFAA.SE-ICD-001 Interface Control Document.
1.3.10.6.3
SKA1-FLD-1117 TM to SADT
21/09/2015 7:42 am
Page
7 of 196
1.3.10.6.3.1
SKA1-SYS_REQ- TM to SADT interface.
2429
TM to SADT interface. The interface between TM and SADT shall be compliant with the SKA-TEL.TM.SE-TEL.SADT.SE-ICD-001 Interface Control Document.
1.3.10.6.4
SKA1-FLD-1118 TM to CSP
1.3.10.6.4.1
SKA1-SYS_REQ- TM to CSP interface.
2430
TM to CSP interface. The interface between CSP and TM shall be compliant with the SKA-TEL.CSP.SE-TEL.TM.SE-ICD-001. Interface Control Document.
1.3.10.6.5
SKA1-FLD-1536 TM to INFRA
1.3.10.6.5.1
SKA1-SYS_REQ- TM to INFRA Interface
2737
TM to INFRA Interface. The interface between TM and INFRA shall be compliant with the SKA.TEL.TM.SE-TEL.INFRA.SE-ICD-001 Interface Control Document.
1.3.10.7
SKA1-FLD-1119 Science Data Processor
1.3.10.7.1
SKA1-FLD-1120 SDP to TM
1.3.10.7.1.1
SKA1-SYS_REQ- SDP to TM interface.
2431
SDP to TM interface. The interface between SDP and TM shall be compliant with the SKA-TEL.SDP.SE-TEL.TM.SE-ICD-001 Interface Control Document.
1.3.10.7.2
SKA1-FLD-1121 SDP to INFRA
1.3.10.7.2.1
SKA1-SYS_REQ- SDP to INFRA interface.
2432
SDP to INFRA interface. The interface between SDP and Infra shall be compliant with the SKA.TEL.SDP.SE-TEL.INFRA.SE-ICD-001 Interface Control Document.
1.3.11
SKA1-FLD-1152 RFI and EMC
Parent Comment General
21/09/2015 7:42 am
Shandip Abeywickrema
31 August 2015
General comment for this section - Note earlier comments on SKAO EMI/EMC
standard, comments from INAU to be provided on this document. We request
that the current CSIRO MRO site RFI standards be used as the basis until
agreement is reached on the SKA EMI/EMC standard.
Page
8 of 196
1.3.11.1
SKA1-FLD-1158 Electromagnetic Radiation
The levels and the verification procedures are described in the RFI/EMI Protection and Threshold Levels for the SKA document SKA-TEL-SKO-0000202-AG-RFI-ST01-SKA EMI & EMC Standards and Procedures [4]
Parent Comment General
Wallace Turner
10 July 2015
Parent Comment General
Wallace Turner
10 July 2015
Parent Comment General
Wallace Turner
10 July 2015
1.3.11.1.1
Rev 6 Comment Martin Austin
Note for the future: delete all historical process references.
Rev 6 comment Martin Austin
Also the document is now an Applicable Document
Reply to Martin's comments.
This was dealt with at revision 6A
No further action
SKA1-SYS_REQ- Electromagnetic Radiation
2462
Electromagnetic Radiation. Any component of the observatory shall not emit electromagnetic radiation, in any of the stated frequency intervals for broad band
and narrow band cases, that exceeds the SKA RFI/EMI Threshold Levels[4]
Parent Comment General
Wallace Turner
10 July 2015
Parent Comment General
Wallace Turner
10 July 2015
Parent Comment General
Wallace Turner
10 July 2015
Rev6 comment Martin Austin
Also the document is now an Applicable Document
Parent Comment General
Wallace Turner
10 July 2015
Reply to Martin.
This was dealt with at revision 6A
No further action
1.3.11.10
Rev 6 comment Gie Han Tan
Requirement can be simplified by just referring to SKA EMI/EMC Standard
Rev6 comment Martin Austin
Note for the future: delete all historical process references.
SKA1-FLD-1169 RFI excision
1.3.11.10.1
SKA1-SYS_REQ- RFI excision
2473
RFI excision. The SKA1 Telescopes shall automatically excise data that is corrupted by RFI.
Parent Comment General
Wallace Turner
10 July 2015
SDP comment
Excision of data automatically could lead to serious downstream issues. Flagging
should be considered safe, but excision must be left at the discretion of the user /
operator.
Parent Comment General
Wallace Turner
10 July 2015
SDP FG
Requirement was changed to be more restrictive. Need to find out what the
intent is. Since the requirement was made to be more restrictive, chance of
21/09/2015 7:42 am
Page
9 of 196
changing it is low.
Parent Comment General
Wallace Turner
10 July 2015
Reply to SDP
Tim Cornwell & Peter Dewdney agree that excision is not required
Action Delete requirement
Parent Comment General
Michael Rupen
1 September 2015
Key here is to define "excision". Probably best to say either flagged (i.e., not
used in the data products) or subtracted (i.e., the corruption is removed, allowing
the residual to be used in the data products).
1.3.11.11
SKA1-FLD-1170 RFI masking
1.3.11.11.1
SKA1-SYS_REQ- RFI masking
2474
RFI masking. The SKA1 Telescopes shall flag data according to a pre-selected RFI Mask.
Parent Comment General
Wallace Turner
10 July 2015
CSP comment
Publish RFI document and associated Level 1 ECP to address CSP concerns
on:
- Req 2474: Clarification of RFI masking.
This is also a potential infrastructure issue because of the shared room between
CSP and other equipment.
Parent Comment General
Wallace Turner
10 July 2015
CSP Michael Rupen comment
Changed priority from High to blank -- while flagging RFI is in general a big deal,
implementing a simple stable mask is not.
Parent Comment General
Wallace Turner
10 July 2015
CSP comment
2014-07-08 – TIM#3
Brent pointed out that this mask might be time-variable, e.g., flag this channel
every 10msec after some epoch. That would have a more severe impact on CSP
design work. Left priority as medium (blank) until and unless this is confirmed as
a possibility.
Parent Comment General
Wallace Turner
10 July 2015
CSP comment
2015-03-12 - Michael Rupen:
Assume masks can have start/stop times but are ON for the entire period thus
specified. I.e., no periodic flags.
Parent Comment General
Wallace Turner
10 July 2015
Reply to CSP
There is a signal chain and linearity document in progress. The potential
requirements from this will be included in the "missing requirements" rather than
this update
Action retain comment but no further action this update
21/09/2015 7:42 am
Page
10 of 196
1.3.11.2
SKA1-FLD-1159 Self-induced RFI
The levels and testing and acceptance procedures are described in the RFI/EMI Protection and Threshold Levels for the SKA document [4]
Parent Comment General
Wallace Turner
10 July 2015
Parent Comment General
Wallace Turner
10 July 2015
1.3.11.2.1
Rev 6 comment Gie Han Tan
Requirement can be simplified by just referring to SKA EMI/EMC Standard
Reply to Gie Han Tan
Jul 10, 2015, 8:03 AM Page 6 of 157
The reference [4] was added at Rev 6A.
No further action required
SKA1-SYS_REQ- Self-induced RFI
2463
Self-induced RFI. The SKA1 Telescope shall generate less self-induced RFI, within the Telescope's operating frequency bands, than the SKA RFI/EMI Protection
Levels, for both broad band and narrow band cases, as specified in the "RFI/EMI Protection and Threshold Levels for the SKA" document. The SKA RFI/EMI
Protection Levels are defined at the respective receiver input, and measured at the respective Telescope time series output.
Parent Comment General
Wallace Turner
10 July 2015
Parent Comment General
Wallace Turner
10 July 2015
Parent Comment General
Wallace Turner
10 July 2015
Rev 6 comment Gie Han Tan
Requirement can be simplified by just referring to SKA EMI/EMC Standard
Parent Comment General
Wallace Turner
10 July 2015
Reply to Gie Han Tan
The reference [4] was added at Rev 6A.
No examples provided as yet by AIV. Consequently, not enough information to
update requirement
No further action required
1.3.11.3
AIV comment
Note that it will not be possible to measure broad band self-generated RFI to the
levels contemplated in radio astonomy,
GHT
Please provide numerical example(s) to illustrate issue.
SKA1-FLD-1160 Electromagnetic Compatibility Standards
1.3.11.3.1
SKA1-SYS_REQ- Electromagnetic Compatibility Standards
2464
Electromagnetic Compatibility Standards. The SKA1 Telescopes shall be compliant with one or more of the following standards for emissions and one or more for
susceptibility/immunity:
*BS EN 61000-6-2. Electromagnetic compatibility (EMC). Generic standards. Immunity standard for industrial environments.
*BS EN 61000-6-4 AMD2. Electromagnetic compatibility (EMC). Part 6-4. Generic standards. Emission standard for industrial environments.
21/09/2015 7:42 am
Page
11 of 196
*BS CISPR 14-1. Electromagnetic compatibility. Requirements for household appliances, electric tools and similar apparatus. Part 1. Emission.
*MIL-STD-464C
Parent Comment General
Wallace Turner
10 July 2015
CSP comment
SKA1-SYS_REQ-2464: not sure the industrial standards are required, perhaps
the lighter scientific/light industrial versions will do. May depend on the local
laws.
Parent Comment General
Wallace Turner
10 July 2015
CSP comment
2014-07-25 -- Level 2 v.B2
The EN Standards quoted covers both industrial environments (EN 61000-6-2
and EN 61000-6-2) and the less onerous household environment (Cispr 14 -1 is
called up by the EN61000-6-3 which is for residential commercial and light
industrial environments -- if the authors do want to specify a house hold
emmisions Standard it should have been the generic one i.e. BS EN 61000-6-3).
To leave it up to the Elements to decide if they want to comply with industrial or
household Standards is strange.
Also to require compliance at Telescope Level to these Standards is ridiculous how will this be verified? This Level 1 Requirement certainly needs clarification.
1.3.11.4
SKA1-FLD-1161 Electricity network Electromagnetic Compatibility
The levels and verification procedures are described in the RFI/EMI Protection and Threshold Levels for the SKA document, which is part of the Level 1 Requirements,
to be published in its final form by T0+12 weeks.
Parent Comment General
Wallace Turner
10 July 2015
Parent Comment General
Wallace Turner
10 July 2015
1.3.11.4.1
Rev 6 comment Gie Han Tan
Requirement can be simplified by just referring to SKA EMI/EMC Standard
Reply to Gie Han Tan
Agree.
Action add reference [4] and remove "to be published in its final form by T0+12
weeks."
SKA1-SYS_REQ- Electricity network Electromagnetic Compatibility
2465
Electricity network Electromagnetic Compatibility. The SKA1 telescopes shall follow the code of practice for the application of Electromagnetic Compatibility
(EMC) standards and guidelines in electricity utility networks [4].
Parent Comment General
21/09/2015 7:42 am
Wallace Turner
10 July 2015
CSP comment GvdM
Clarification required
I check the new SKAO EMC document.
The new SKAO EMC document is titled "SKA EMI/EMC Standards and
Procedures SKA-TEL-SKO-0000202" and does not refer to electricity utility
networks - so if this is the standard we have to comply with then there seems to
be an error in the text. Assuming that compliance to the 202 document is in fact
what is required here (TBC by the Wallace), then this is a Level 1 requirement
Page
12 of 196
and an appropriate requirement for CSP needs to be derived by the SKAO and
allocated to CSP. The 202 only deals with electromagnetic emissions, which is
one half of Electromagnetic Compatibility (susceptibility being the other half for
which it is stated that another document will follow). So again the text of the
document is suspect. My reading of the document is that CSP equipment, being
"located in a shielded computer server type room", has to comply with "IEC EMC
Standards". So again if the standard referred to her is indeed the SKAO
document 202 then we should to link this requirement to our CSP Level 2
requirements 2464-01 "CSP Electromagnetic Compatibility: Immunity" and 246402 "CSP Electromagnetic Compatibility: Emissions".
However the SKAO document 202 seems to call for compliance to CISPR 22
Information technology Class B (the domestic limits) while our CSP requirements
2464 call for industrial limits (less onerous). This implies that we should update
our 2464 requirements (my fault originally - sorry). I have now updated this on
Rev D in Google Docs.
As for this Level 1 requirement SKA1-SYS_REQ-2465 - Wallace must confirm
what the text is trying to convey before we can address the Level 2 requirement.
1.3.11.5
SKA1-FLD-1162 EMC Compatibility Marking
1.3.11.5.1
SKA1-SYS_REQ- EMC compatibility marking.
2466
EMC compatibility marking. All "off-the-shelf" equipment shall possess as a minimum the host country EMC marking.
1.3.11.6
SKA1-FLD-1163 Electromagnetic Susceptibility
1.3.11.6.1
SKA1-SYS_REQ- Electromagnetic susceptibility.
2467
Electromagnetic susceptibility. The observatory shall not be susceptible to terrestrial electromagnetic radiation at any frequency that significantly interferes with its
normal operation.
Parent Comment General
Wallace Turner
10 July 2015
Rev 6 comment Gie Han Tan
Requirement can be simplified by just referring to SKA EMI/EMC Standard.
Parent Comment General
Wallace Turner
10 July 2015
Reply to Gie Han Tan
Agreed
Action: ammend wording to refence standad [4]
1.3.11.7
SKA1-FLD-1164 Receiver linearity - space borne RFI
The levels and testing and acceptance procedures are described in the Linearity SKA document, which is part of the Level 1 Requirements
Parent Comment General
21/09/2015 7:42 am
Wallace Turner
10 July 2015
Rev 6 Comment Gie Han Tan
Page
13 of 196
Parent Comment General
Wallace Turner
10 July 2015
Parent Comment General
Wallace Turner
10 July 2015
1.3.11.8
Requirement needs up date, this is not covered by the SKA EMI/EMC Standard.
Rev 6 comment Juande Santander-Vela
Plus, the reference to T0+12w, is it for Stage 1? Then it is clearly out of date,
and needs revision.
Reply
References linearity document
Action add reference [?]
SKA1-FLD-1165 Receiver linearity airborne RFI
The levels and testing and acceptance procedures are described in the SKA linearity document, which is part of the Level 1 Requirements
Parent Comment General
Wallace Turner
10 July 2015
Parent Comment General
Wallace Turner
10 July 2015
Rev 6 comment Gie Han Tan
Requirement needs up date, this is not covered by the SKA EMI/EMC Standard
Rev 6 comment Juande Santander-Vela
Plus, the reference to T0+12w, is it for Stage 1? Then it is clearly out of date,
and needs revision.
Parent Comment General
Wallace Turner
10 July 2015
References linearity document add ref [?]
1.3.11.9
SKA1-FLD-1168 RFI flagging
An RFI mask identifies individual frequency data to the resolution of one channel and time data to the integration unit that is likely to be corrupted by RFI
1.3.11.9.1
SKA1-SYS_REQ- RFI flagging
2472
RFI flagging. The SKA1 telescopes shall automatically flag frequency data with a resolution of one channel and time data to the resolution of the integration unit if the
data is corrupted by RFI.
1.3.12
SKA1-FLD-1124 Environmental, Safety and Occupational Health (ESOH)
1.3.12.1
SKA1-FLD-1179 Environmental Protection
NOTE: This section states requirements for the protection of the environment from the impacts of SKA activities and facilities. A separate section of requirements
provide details of the environmental conditions that could impact the SKA systems.
1.3.12.1.1
SKA1-SYS_REQ- Environmental legislation and regulations.
2484
Environmental legislation and regulations. The observatory shall be compliant with all local, State and national environmental protection legislation and regulations.
NOTE: Legislation takes precedence over project/contract documentation and requirements. Omission of a law from this requirement does not affect its enforceability.
21/09/2015 7:42 am
Page
14 of 196
Legislation is also subject to amendment and so the Environmental Laws identified during the Request for Information (copied below) may be modified by the Hosting
Agreements and subsequent Acts and Amendments.
Legislation and regulations identified during the response to Request for Information include:
South Africa:
National Environmental Management Act, 1998 ("NEMA");
National Water Act, 1998;
National Environmental Management: Air Quality Act, 2004;
National Environmental Management Waste Act, 2008;
National Environment Management: Biodiversity Act, 2004;
National Heritage Resources Act, 1999.*
Australia:
The Commonwealth Environment Protection and Biodiversity Conservation (EPBC) Act 1999.
The Western Australian Environmental Protection Act 1986
The Western Australian Land Administration Act 1997
In addition, approvals will be required under the Western Australia Mining Act 1978, Heritage of Western Australia Act 1990, the Western Australian Aboriginal
Heritage Act 1972 and the MRO Indigenous Land Use Agreement 2009.
* Other South African environmental statutes include the Environment Conservation Act, 1989, various air pollution statutes, the National Heritage Resources Act,
1999, the Hazardous Substances Act, 1973, the Health Act, 1977, the Nuclear Energy Act, 1999, the National Nuclear Regulatory Act, 1999, the National
Environmental Management: Protected Areas Act, 2003, the Fertilisers, Farm Feeds, Agricultural Remedies and Stock Remedies Act, 1947, the Marine Living
Resources Act, 1998, and the National Environmental Management: Integrated Coastal Management Act, 2008.
Parent Comment General
Wallace Turner
10 July 2015
CSP comment
Not sure that this is applicable on CSP. Will need to study the legislation for both
South Africa, Australia and the manufacturing countries.
This shotgun approach is totally unacceptable. The SKAO should trawl through
all the applicable legislation and derive requirements and allocate these to the
Elements as applicable. It is extremely short sighted and wasteful to expect from
each element to do such an analysis and derive the requirements.
SKAO to filter and flow applicable specifications to CSP and other elements.
We will assume solar radiation levels of the host countries.
Parent Comment General
Wallace Turner
10 July 2015
CSP comment
2014-07-08 – TIM#3
Still an issue. We must proceed with best practices, and document our approach
in the Level 2 requirements.
1.3.12.2
SKA1-FLD-1125 Safety
The safety priorities of the system shall be:
1.
protection of persons,
21/09/2015 7:42 am
Page
15 of 196
2.
3.
guarding the technical integrity of the observatory and other equipment potentially affected by the operation of the observatory, and
protection of scientific data, in this order.
SKA Observatory hazard analysis and safety practices will be governed by an order of precedence as follows:
1.
Design for Minimum Risk: The primary means for mitigation of risk shall be to eliminate the hazard through design.
2.
3.
Incorporate Safety Devices: Fixed, automatic or other protective devices shall be used in conjunction with the design features to attain an acceptable level of risk.
Provisions shall be made for periodic functional checks as applicable.
Provide Warning Devices: When neither design nor safety items can effectively eliminate or reduce hazards, devices shall be used to detect the condition, and to
produce an adequate warning to alert personnel of a hazard. Devices may include audible or visual alarms, permanent signs or movable placards.
Procedures and Training: Where it is impractical to substantially eliminate or reduce the hazard or where the condition of the hazard indicates additional emphasis,
special operating procedures and training shall be used.
1.3.12.2.1
SKA1-FLD-1614 Safe Design
1.3.12.2.1.1
SKA1-FLD-1608 Safety of equipment < 600V
1.3.12.2.1.1.1
SKA1-SYS_REQ- Safety of equipment with rated voltage not exceeding 600V
2820
Safety of equipment with rated voltage not exceeding 600V. Equipment shall comply with the safety requirements of BS EN IEC 60950. NOTE: This includes
electric shock, energy related hazards, fire, heat related hazards, mechanical hazards, radiation and chemical hazards.
1.3.12.2.1.2
SKA1-FLD-1126 Hazard analysis
1.3.12.2.1.2.1
SKA1-SYS_REQ- Design for hazard elimination.
2437
Hazard elimination. The System, while in any mode, shall present no hazard to neither the system equipment nor to operators or maintainers of the system
equipment with categorization exceeding the levels defined in the SKA Project Safety Management Plan [9]
Parent Comment General
21/09/2015 7:42 am
Wallace Turner
14 July 2015
Larry Heystek:
The "requirement" and title in "requirement description" do not match .
Page
16 of 196
General
Wallace Turner
Parent Comment Proposed Change Michael Rupen
1.3.12.2.1.3
14 July 2015
1 September 2015
Need to remove "Design for"
Too many negatives in here! Presumably this should be:
...shall present no hazard, either to the system equipment or to operators...
SKA1-FLD-1287 Hazard warning marking
1.3.12.2.1.3.1
SKA1-SYS_REQ- Hazard warning marking.
2579
Hazard warning marking. All items that present a potential hazard shall be labelled in accordance with BS EN ISO 7010.
21/09/2015 7:42 am
Page
17 of 196
1.3.12.2.1.3.2
SKA1-SYS_REQ- Marking of machinery - safety
2818
Marking of machinery - safety. In accordance with ISO 61310_2, machinery shall bear all markings which are necessary
– for its unambiguous identification;
– for its safe use;
and supplementary information shall be given, as appropriate:
– permanently on the machinery;
– in accompanying documents such as instruction handbooks;
– on the packaging
1.3.12.2.1.4
SKA1-FLD-1129 Fail-Safe Design
1.3.12.2.1.4.1
SKA1-SYS_REQ- Fail safe design.
2438
Fail safe design. Components and Equipment shall be designed to be locally fail-safe and not rely on external safety devices or measures to operate safely.
1.3.12.2.1.4.2
SKA1-SYS_REQ- Non-propagation of failures
2788
Non-propagation of failures. The equipment shall be designed such that hardware failures and software errors should not create a hazardous situation to interfacing
systems.
1.3.12.2.1.5
SKA1-FLD-1130 Emergency stop
Emergency stop buttons are to be provided as a backup for use in emergency only. They need to be robust, dependable and available at all positions where it might
be necessary to operate them.
As guidance BS EN 60204-1 standard defines the categories of operation and BS EN 60947-5-5 the characteristics of the emergency stop switches.
1.3.12.2.1.5.1
SKA1-SYS_REQ- Emergency stop.
2439
Emergency stop. The SKA1 Elements shall have emergency stop switches or brakes for all electro-mechanical or mechanical systems that have been identified by
safety analyses (required under SKA1-SYS_REQ-2435) to pose a hazard.
Parent Comment General
Wallace Turner
10 July 2015
CSP comment GvdM
Not applicable to CSP: CSP has no electro-mechanical or mechanical systems
Parent Comment General
Wallace Turner
10 July 2015
Reply to CSP
Agree
Action remove allocation to CSP
Also remove LFAA, SDP, SADT & TM based on the same rationale
1.3.12.2.1.5.2
SKA1-SYS_REQ- Location of Emergency stop
2733
21/09/2015 7:42 am
Page
18 of 196
Location of Emergency stop. Emergency stop switches shall be located in such a way to minimize the risk of injury. (Verified by Analysis as 'minimisation' is
unverifiable any other way.)
Parent Comment General
Wallace Turner
10 July 2015
TM comment
Please indicate what responsibility TM has in terms of this requirement: is
emergency stop switches for TM element only?
Parent Comment General
Wallace Turner
10 July 2015
JSV
My request for comments to TM:
As discussed in the PDR, TM responsibility for safety needs to be clearly
defined, and potentially restricted to monitoring. More definition will come as part
of the Operations Requirement Document. Any further insight on this
requirement from TM?
Parent Comment General
Wallace Turner
10 July 2015
TM Paul Swart
As per PDR panel recommendation suggestion:
INFRA shall implement emergency stop switches in CPF to remove electrical
power from all equipment installed in each room. (electrical shock hazard)
SKA1-Mid Dish shall implement a positioner inhibit switch (to inhibit movement of
the mounting) at the Dish installation (hazard of mounting hitting personnel or
assets who are within the swept volume of the Dish.)
SKA1-Mid Dish shall implement a switch to remove electrical power from the
Dish installation (electrical shock hazard).
TM shall provide a user interface to the operator to shut down the telescope (not
emergency stop).
Paul Swart (TM) response:
As per PDR panel recommendation suggestion:
INFRA shall implement emergency stop switches in CPF to remove electrical
power from all equipment installed in each room. (electrical shock hazard)
SKA1-Mid Dish shall implement a positioner inhibit switch (to inhibit movement of
the mounting) at the Dish installation (hazard of mounting hitting personnel or
assets who are within the swept volume of the Dish.)
SKA1-Mid Dish shall implement a switch to remove electrical power from the
Dish installation (electrical shock hazard).
TM shall provide a user interface to the operator to shut down the telescope (not
emergency stop).
Parent Comment General
Wallace Turner
10 July 2015
CSP comment GvdM
CSP has no electro-mechanical or mechanical systems and thus no emergency
stop switches
Parent Comment General
Wallace Turner
10 July 2015
Reply to TM
The same rationale as CSP:
TM has no electro-mechanical or mechanical systems and thus no emergency
stop switches
21/09/2015 7:42 am
Page
19 of 196
Also remove LFAA, SADT, TM and SDP based on the same rationale
1.3.12.2.2
SKA1-FLD-1137 Electrical safety
1.3.12.2.2.1
SKA1-SYS_REQ- Electrical safety
2446
Electrical safety. Electrical risks and hazards shall be controlled in accordance with local, State and national legislation and Codes of Practice.
NOTE: In South Africa, SANS 10142-1 and SANS 10142-2 shall apply.
NOTE: In Australia, in addition to legislation, the following Codes of Practice shall be applied:
AS/NZ 3000
Safe Work Australia 'Managing Electrical Risks at the Workplace';
Western Australia Director of Energy Safety 'Safe Low Voltage Work Practices by Electricians'
1.3.12.2.2.2
SKA1-FLD-1135 Safety grounding and bonding
1.3.12.2.2.2.1
SKA1-SYS_REQ- Safety grounding and bonding.
2444
Safety grounding and bonding. External conductive parts shall be grounded in compliance to:
South Africa:
National Building Regulations and Building Standards Act, 1977
Occupational Health and Safety act, 1993
SANS 10313
Australia:
AS/NZ 3000,
AS/NZ 1768
1.3.12.2.2.3
SKA1-FLD-1136 Electrical circuit interlocks
Guidance to safeguarding and complementary protective measures are provided in BS EN 12100-2 clause 5.
Monitoring of safety signals is available in BS EN ISO 13849-1.
21/09/2015 7:42 am
Page
20 of 196
1.3.12.2.2.3.1
SKA1-SYS_REQ- Electrical circuit interlocks.
2445
Electrical circuit interlocks. Electrical circuit inter-locks shall be provided to prevent personnel coming into contact with hazards that cannot otherwise be eliminated
from design.
1.3.12.2.3
SKA1-FLD-1174 Emergency Communications
1.3.12.2.3.1
SKA1-SYS_REQ- Emergency communication
2481
Emergency communication. The observatory shall provide an independent system to communicate with outside locations in emergencies.
Parent Comment General
Wallace Turner
10 July 2015
CSP comment GvdM
Obviously not applicable to CSP
Parent Comment General
Wallace Turner
10 July 2015
Reply CSP
Agreed
Action remove allocation to CSP
1.3.12.2.3.2
SKA1-FLD-1616 Safety preparation for construction and operations
1.3.12.2.3.2.1
SKA1-FLD-1145 Fire fighting equipment
1.3.12.2.3.2.1.1 SKA1-SYS_REQ- Fire fighting equipment.
2454
Fire fighting equipment. Fire fighting equipment shall be made available at all SKA premises and facilities.
Parent Comment General
Wallace Turner
10 July 2015
CSP comment GvdM
Fire protection provided by INFRA – N/A to CSP
Parent Comment General
Wallace Turner
10 July 2015
Reply to CSP
Agreed
Action Remove allocation to CSP
1.3.12.2.3.2.2
SKA1-FLD-1144 First aid stations
The location and capability for first aid stations is to be determined in association with the hazard analysis.
1.3.12.2.3.2.2.1 SKA1-SYS_REQ- First aid stations.
2453
First aid stations. First aid stations shall be provisioned.
21/09/2015 7:42 am
Page
21 of 196
1.3.12.3
SKA1-FLD-1151 Occupational Health
1.3.12.3.1
SKA1-SYS_REQ- Occupational health legislation and regulations.
2460
Occupational health legislation and regulations. The observatory shall comply with all applicable local, State and national occupational health regulations and
standards in force at the time. Regulations include, but are not limited to:
South Africa:
Occupational Health and Safety Act, 1993, and all its regulations.
Australia:
Commonwealth Occupational Health and Safety Act 1991;
OHS (Safety Arrangements) Regulations 1991;
OHS (Safety Standards) Regulations 1994;
OHS Codes of Practice 2008.
Western Australia:
Occupational Safety and Health Act 1984;
Harmonised OHS legislation (as enacted).
Parent Comment General
Wallace Turner
10 July 2015
CSP Comment
We have previously indicated that we do not believe that these Laws are
applicable to CSP. I have researched this a bit and here are my conclusions and
recommendations:
For South Africa:
I have looked at the MeerKat approach, which is the following:
"1. The Occupational Health and Safety Act, 1993, and all its regulations are
applicable at MeerKat telescope level (our Level 1).
2. The requirements from the OHS which are relevant to the system and its
components are not detailed in the Level 1 document. The range of subsystems
and components is too diverse, and the requirements extraction would not be
practical at this level. It is recommended that the applicable regulations be
derived for individual subsystems as part of the system architecture design and
allocation of requirements to subsystems."
This derivation and allocation of Level 2 requirements have not been done by the
SKA1 Level 1 Architecture Group.
The analysis performed by the MeerKat architecture group found that neither the
SA OHS Act or the OHS Regulations are directly applicable to the MeerKat CBF.
For Western Australia:
The Current legislation applicable in Western Australia is the Occupational
Safety and Health Act 1984; and
The Occupational Safety and Health Regulations 1996
HOWEVER a new bill "Work Health and Safety Bill 2014" has been published for
comment (comment period closed in Jan 2015) and is currently being reworked
to include the comments. This Bill will probably have been adopted when SKA1
21/09/2015 7:42 am
Page
22 of 196
construction starts.
Again derivation and allocation of Level 2 requirements should be done by the
Level 1 architecture group. It is recommended that someone from ASCAP (John
Bunton?) is asked to report on if they have identified any WA OHS requirements
as applicable to the ASKAP CSP (similar to the MeerKat Memo - see below). I
think that CSP need this information from Australia before we can say with
confidence that the OSH Laws are not applicable to the CSP.
The MeerKat team has published a Memo reporting the MeerKat safety analysis
results (M0000-0000V1-35 TM Revision 1MeerKAT Safety Analysis and
Requirements Allocation to Subsystems) which deals with the South African
OSH Act and Regulations and derives applicable requirements for all the
MeerKat Elements. This may be of interest to you.
Parent Comment General
1.3.12.3.2
Wallace Turner
10 July 2015
CSP comment Gottlieb van der Merwe
The Memo M0000-0000V1-35 TM Revision 1 deals with:
General requirements for safe design
Regulatory (safety) requirements – the SA OHS Act and Regulations
Requirements derived from the Safety Analysis
What is of interest in terms of “SKA1-SYS_REQ-2460 Occupational health
legislation and regulations” is item 2 above which is not directly addressed
Jul 10, 2015, 8:03 AM Page 19 of 157
in M0000-0000V1-03 R.
This Memo is more relevant to SKA1-SYS_REQ-2437 Design for hazard
elimination: Designs shall demonstrate the elimination, or mitigation to a risk
level practically achievable, of all hazards by means of a subsystem hazard
analysis (SSHA) report as described in EN 14738 and tailored by SKA Product
Assurance and Safety Plan SKA-OFF.PAQA-SKO-QP-001.
SKA1-FLD-1148 Illumination
1.3.12.3.2.1
SKA1-SYS_REQ- Illumination.
2457
Illumination. Personnel shall be provided with a working illumination level which is compliant with local and national regulations including the current issue of SANS
10114-1 in South Africa and the AS/NZS 1680 series in Australia.
Parent Comment General
Wallace Turner
10 July 2015
CSP comment GvdM
Workplace illumination provided by INFRA – N/A to CSP
Parent Comment General
Wallace Turner
10 July 2015
Reply to CSP:
Agreed remove allocations from CSP, SDP, LFAA,SADT, TM, DSH
1.3.12.3.3
SKA1-FLD-1149 Clean air
Dust is likely to be a principal but not limited to driver of this requirement. Where the air quality cannot be managed, protective masks may be required. This is covered
21/09/2015 7:42 am
Page
23 of 196
by the protective clothing requirement
1.3.12.3.3.1
SKA1-SYS_REQ- Clean air.
2458
Clean air. Personnel shall be provided with air quality at least compliant with the current issue of SANS 10400-O (South Africa - The application of National Building
Regulations Part O : Lighting and ventilation) and the AS 1668 series of codes (Australia - The use of mechanical ventilation and air conditioning in buildings).
1.3.12.3.4
SKA1-FLD-1433 Humidity
1.3.12.3.4.1
SKA1-SYS_REQ- Humidity
2649
Humidity. Working environments shall be designed, built and maintained to provide air quality that meets or exceeds the guidance provided in the Australian Code of
Practice for Managing the Work Environment and Facilities, National Code of Australia and AS 1668.
NOTE: Building humidity required for computing facilities is specified in Req 2367.
Parent Comment General
Shandip Abeywickrema
31 August 2015
Assume National Code of Australia should be Building Code of Australia?
1.3.13
SKA1-FLD-1153 Security
The SKA will be a very attractive target for criminals, including theft of infrastructure and cyber-attacks exploiting the HPC and networks. It will also be seen to be a
'soft' target with connections to the academic and research communities. The potential impacts include financial cost to replace equipment and to restore systems,
loss of observing opportunities (telescopes could be rendered useless for weeks or months) and loss of reputation for the SKA and the host nations. The threats will
exist from the outset and security will need to be established before physical installation starts (including security of information systems to deter Trojan horses from
being installed early in the development phase).
There is currently no ISO Standard for a Security Management System, although DPC: 13 / 30278101 DC included Draft BS ISO 34001 Security Management System
which forms the basis of the Security requirements. In addition, the UK Cabinet Office HMG Security Policy Framework (Version 11.0) has been used to derive
requirements.
The security risk management system shall include:
i. personnel security,
ii. physical security and counter terrorism, and
iii. security of information.
1.3.13.1
SKA1-FLD-1586 Security Management
1.3.13.1.1
SKA1-SYS_REQ- Security Management System
2791
Security Management System. The SKA shall provide a security management system that includes :
i. personnel security,
ii. physical security (asset)
21/09/2015 7:42 am
Page
24 of 196
iii. security of information
21/09/2015 7:42 am
Page
25 of 196
1.3.13.2
SKA1-FLD-1587 Physical security
SKA assets must be safeguarded against a range of physical threats, including crime (theft, criminal damage, assaults on staff etc.), natural hazards (e.g. flooding),
and security threats such as terrorism and exploitation by criminal and malicious groups (including hacktivists).
Physical security describes a range of controls that are intended to protect individuals from violence; prevent unauthorised access to sites and / and other valuable
assets; and reduce the risk a range of physical threats and mitigate their impact to a levels that is acceptable to the organisation. Security must be incorporated into
the initial stages of planning, selecting, designing or modifying any building or facility, using appropriate methodologies; putting in place integrated and proportionate
control measures to prevent, deter, detect and/or delay attempted "physical attacks", and to trigger an appropriate response.
Host Country security organisations will need to be consulted to determine the terrorism threat to the SKA (currently negligible but may
vary in time).
This section on physical security requirements will expand as the use cases are developed and the need for perimeter, interior and inter-site security is better
understood.
1.3.13.2.1
SKA1-FLD-1155 Equipment Security
1.3.13.2.1.1
SKA1-SYS_REQ- Equipment security
2478
Equipment security. The observatory shall provide a secure environment for equipment. This shall include protection of generators, fuel, solar cells and inter-station
assets such as copper cables.
1.3.13.3
SKA1-FLD-1588 Information security
The Information Security Management System will be based upon the ISO 27000 series, tailored for the SKA project. Information security is important to the SKA
project in order to protect: availability of telescopes being impacted by attacks and viruses; legal, regulatory and reputational damage should SKA systems be
exploited by criminal and malicious organisations; protection of IPR; and protection of personal and financial information stored on SKA business systems. Assets that
have vulnerabilities that are exploitable include hardware, software, network, personnel, site and organisation.
1.3.13.3.1
SKA1-FLD-1175 Accessibility
1.3.13.3.1.1
SKA1-SYS_REQ- Accessibility
2482
Accessibility. It shall be possible to control on a per user basis which SKA1 facilities and resources (both hardware and software) may be accessed by the user.
Parent Comment General
Wallace Turner
10 July 2015
SDP comment
Suggest specifying that single sign on at the system level is in place, otherwise
we may end up with a proliferation of hard to management authentication and
authorisation databases. In fact it may be best to split this into two
requirements - one that authenticates a users credentials, and the other that
21/09/2015 7:42 am
Page
26 of 196
Parent Comment General
Wallace Turner
10 July 2015
Parent Comment General
Michael Rupen
1 September 2015
1.3.13.3.2
grants authorisation based on those
credentials.
SDP FG:
Authenticating user credentials and granting authorisation can be specified at L2.
CSP: We assume access is controlled via INFRA and TM. Not clear whether
this should even be allocated to CSP.
SKA1-FLD-1156 Archive Security
1.3.13.3.2.1
SKA1-SYS_REQ- Archive security
2479
Archive security. The observatory shall provide a secure environment for all its data archives.
Parent Comment General
Wallace Turner
10 July 2015
CSP comment GvdM
Obviously not applicable to CSP
Parent Comment General
Wallace Turner
10 July 2015
Reply to CSP
Agreed.
Action remove CSP from allocation
1.3.14
SKA1-FLD-1176 System Environment
1.3.14.1
SKA1-FLD-1180 Non-weather protected locations - protection of equipment.
1.3.14.1.1
SKA1-SYS_REQ- Protection of equipment in stationary use at non-weather protected locations
2798
Protection of equipment in stationary use at non-weather protected locations. Equipment in stationary use at non-weather protected locations shall be
protected against environmental conditions 4K4H/ 4Z1/ 4Z5/ 4Z6/ 4B2/ 4C1/ 4S3/ 4M4 in accordance with BS EN IEC 60721-3-4.
NOTE: 4Z5 refers to the survival, non-operational mode. The equipment shall be able to operate normally for air movement up to 11 m/s
Parent Comment General
Wallace Turner
10 July 2015
Parent Comment General
Wallace Turner
10 July 2015
1.3.14.1.2
SKA1-FLD-1184 Allowable air temperature range
1.3.14.1.2.1
SKA1-SYS_REQ- Allowable air temperature range.
21/09/2015 7:42 am
CSP comment GvdM
CSP equipment located in weather protected locations.
Reply to CSP
Agreed but also SDP.
Action remove CSP and SDP from allocations
Page
27 of 196
2488
Allowable air temperature range. SKA1 equipment located at the dishes or aperture arrays or outside the central processing and operating facilities shall be able to
withstand (non-operating if necessary) an outside air temperature within the range of -15 ºC to +60 ºC.
Note this takes precedence over IEC 60721-3-4 4K4H of parent requirement.
1.3.14.1.3
SKA1-FLD-1185 Air temperature operation range
1.3.14.1.3.1
SKA1-SYS_REQ- Air temperature operation range.
2489
Air temperature operation range. SKA1 equipment located at the dishes or aperture arrays or outside the central processing and operating facilities shall be able to
operate within specification if the outside air temperature is within the range of -5 ºC to +50 ºC.
Note this takes precedence over IEC60721-3-4 4K4H
1.3.14.1.4
SKA1-FLD-1186 Wind velocities
1.3.14.1.4.1
SKA1-SYS_REQ- Wind velocities.
2490
Wind velocities. SKA1 equipment shall be able to survive wind velocities up to 160 km/hr, and shall operate within normal specification ranges for wind velocities up
to 40 km/hr.
Note: this takes precedence over IEC60721-3-4 4Z5
Parent Comment General
Wallace Turner
10 July 2015
Rev 6 comment Juande Santander-Vela
I would say that this should read "SKA1 equipment, once installed, shall…",
because guaranteeing wind survivability of internal equipment seems to onerous
Parent Comment General
Wallace Turner
10 July 2015
Reply to Juande:
Agreed. Also the requirement needs to reference wind velocity at 10metres
Action ammend requirement wording
Parent Comment General
Michael Rupen
1 September 2015
Should be some graceful degradation of pointing specs depending on wind
speed.
Should there be a spec on the maximum wind speed for observations by DISH,
beyond which the dishes can be stowed?
1.3.14.2
SKA1-FLD-1189 Weather protected locations - protection of equipment
Specify and control noise, illumination, humidity and temperature in areas where personnel are required to perform operating and maintenance functions.
1.3.14.2.1
SKA1-FLD-1627 Protection of equipment in non-weather protected locations
21/09/2015 7:42 am
Page
28 of 196
1.3.14.2.1.1
SKA1-SYS_REQ- Protection of equipment in weather-protected locations
2799
Protection of equipment in weather-protected locations. Equipment in stationary use at weather protected locations shall be protected against environmental
conditions 3K8H/ 3Z1/ 3Z11/ 3Z12/ 3B3/ 3C1R/ 3S3/ 3M4 in accordance with BS EN IEC 60721-3-3.
Parent Comment General
Wallace Turner
10 July 2015
CSP comment GvdM
As pointed out previously this Level 1 requirement is totally inappropriate for SKA
– more appropriate for equipment located in a space vehicle. CSP has used the
MeerKat screened room spec's derived from the CSP to INFRA ICD for
Temperature and Humidity only. There will be new temperature and Humidity
requirements added for CSP referring to the ICD in Rev D (refer to SKA1CSP_REQ-N0015-00, SKA1-CSP_REQ-N0016-00, SKA1-CSP_REQ-N0020-00
and SKA1-CSP_REQ-N0021-00). These requirements will be linked to 2799 as
well (done).
In summary – this requirement is applicable (once corrected) to INFRA and
INFRA derive the screened room environmental spec and include these in the
CSP to INFRA ICD from where these then enter the CSP Level 2 requirements.
1.3.14.2.2
SKA1-FLD-1197 Operating humidity
1.3.14.2.2.1
SKA1-SYS_REQ- Operating Humidity.
2500
Operating Humidity. The operating humidity shall be between 40% and 60%
1.3.14.2.3
SKA1-FLD-1198 Storage and transport humidity
1.3.14.2.3.1
SKA1-SYS_REQ- Storage and transport Humidity.
2501
Storage and transport Humidity. The storage and transport humidity shall be between 40% and 95%.
Parent Comment General
Michael Rupen
1 September 2015 Should there be a temperature range and/or non-condensation clause? Note
2502 relates only to operating equipment.
Seems odd that the rationale for 2500 says we want to avoid corrosion while
here we happily store hardware in a swamp...
1.3.14.2.4
SKA1-FLD-1199 Condensation
1.3.14.2.4.1
SKA1-SYS_REQ- Condensation.
2502
Condensation. Appropriate measures shall be taken to prevent the formation of condensation on operating electronic components.
21/09/2015 7:42 am
Page
29 of 196
Parent Comment General
1.3.14.2.5
Michael Rupen
1 September 2015
Should this be extended to stored equipment?
SKA1-FLD-1200 Pressure
1.3.14.2.5.1
SKA1-SYS_REQ- Pressure.
2503
Pressure. Components shipped by air shall be capable of surviving pressures down to 11 kPa (equivalent altitude ~ 50,000 feet).
1.3.14.2.6
SKA1-FLD-1201 Facilities and equipment intrusion
1.3.14.2.6.1
SKA1-SYS_REQ- Facilities and Equipment Intrusion.
2504
Facilities and Equipment Intrusion. Where appropriate, SKA1 equipment facilities shall be adequately protected against intrusion by insect and "larger" wandering
animals.
Parent Comment General
Wallace Turner
10 July 2015
SDP comment
"larger" needs to be clearly defined - snakes, kangaroos, elephants ?
Parent Comment General
Wallace Turner
10 July 2015
SDP FG
L2 requirements specific to SDP can be derived to constrain this requirement.
Parent Comment General
Wallace Turner
10 July 2015
Rev 6 comment Juande Santander-Vela
The definition of larger should be made. I guess we don't want animals the size
of meerkats in there, and possibly up to 1 metre long. Larger animals can be too
costly to avoid.
Conversely, if the intention of this requirement is to avoid any kind of animal
intrusion, the quotes should be removed.
Parent Comment General
Wallace Turner
10 July 2015
CSP comment GvdM
Facilities provided by INFRA – N/A to CSP
Parent Comment General
Wallace Turner
10 July 2015
Rev6A comment Juande Santander-Vela
This looks like a requirement for the Operational Requirement Document.
Consider removing it.
Parent Comment General
Wallace Turner
10 July 2015
Rev6A comment Mark Waterson
Also incomplete - smaller animals -and reptiles! are concerns
Parent Comment General
Wallace Turner
10 July 2015
Reply to CSP
Agreed that Infra provides protection for CSP and SDP
Action remove SDP and CSP from allocation
21/09/2015 7:42 am
Page
30 of 196
1.3.14.2.7
SKA1-FLD-1202 Sand and Dust
1.3.14.2.7.1
SKA1-SYS_REQ- Sand and Dust.
2505
Sand and Dust. SKA1 systems shall be adequately protected against sand and dust ingress.
1.3.14.2.8
SKA1-FLD-1203 Fungus
Parent Comment General
Wallace Turner
10 July 2015
Parent Comment General
Wallace Turner
10 July 2015
CSP comment GvdM
Fungus growth normally occurs within closed unventilated spaces with moisture
present and on certain types (not fungus resistant) materials. Cleanliness does
not really come into the picture. I would argue that these kind of conditions will
not occur in the CSP equipment as it is locate in the shielded CSP room and that
the requirement should not be applicable to CSP (or SDP or TM for that matter)
Reply to CSP
Agreed that this requirement is not applicable to equipment in environmentally
controlled rooms such as the CSP and SDP facilities.
Action: remove CSP and SDP from allocation
1.3.14.2.8.1
SKA1-SYS_REQ- Fungus.
2506
Fungus. Equipment shall be protected against fungus growth.
1.3.14.3
SKA1-FLD-1592 Storage of equipment
1.3.14.3.1
SKA1-SYS_REQ- Storage of equipment
2801
Storage of equipment. SKA equipment, while in its storage packaging, shall withstand, and shall operate to specification as defined herein after exposure to, the
storage environmental conditions as defined in “Class 1.1: Weather protected, partly temperature-controlled storage locations” of the ETSI EN 300 019-1-1 standard.
Parent Comment General
1.3.14.4
1.3.14.4.1
Michael Rupen
1 September 2015
Do we need a time limit here? Previously I think this was 10 years.
SKA1-FLD-1187 Seismicity
SKA1-SYS_REQ- Safety.
2491
Safety. SKA1 equipment and buildings shall be designed and built in compliance with national and State regulations including AS 1170.4 (Importance level 3, design
life 50 years) and SANS 10160-4 for earthquakes of magnitude up to Richter 3.8.
Parent Comment General
Wallace Turner
10 July 2015
CSP comment GvdM
21/09/2015 7:42 am
Page
31 of 196
The requirement in this form is applicable only to INFRA.
What is required here is that requirements are derived (by INFRA) defining the
shock and vibration environment which will exist inside the facility, and which the
CSP will have to withstand, during the specified earthquake.
Also, I am told, the earthquake severity is not sufficiently defined here – we also
need to specify the depth and distance from the epicentre.
1.3.14.4.2
SKA1-SYS_REQ- Seismic resilience
2650
Seismic resilience. SKA1 structures and equipment shall survive and be fully operational after a seismic event of magnitude up to Richter 3.8. Note: Seismic event
includes underground collapses in addition to earthquakes.
1.3.15
SKA1-FLD-1524 Availability Reliability and Maintainability
High availability of the telescopes to conduct science will be a key user requirement in measuring the success of the SKA. In turn, availability is dependent upon both
the reliability and maintainability of the telescopes. Both of these factors may have considerable impact on the whole life costs of the observatory. Therefore, although
the Level 0 requirements should be targeting availability, the Level 1 requirements will need to allocate reliability and maintainability constraints on the elements.
BS 5760-0:1986 defines the following terms:
Availability - the ability of an item (under combined aspects of its reliability, maintainability and maintenance support) to perform its required function at a stated instant
of time or over a stated period of time.
Reliability - the ability of an item to perform a required function under stated conditions for a stated period of time.
Maintainability - the ability of an item, under stated conditions of use, to be retained in, or restored to, a state in which it can perform its required functions, when
maintenance is performed under stated conditions and using prescribed procedures and resources
1.3.15.1
SKA1-FLD-1523 Availability Reliability and Maintenance Plan
The availability, reliability and maintenance plan for the SKA1 telescopes will be developed concurrently so as to fit within the allocated capital and operating
(maintenance) budgets. The plans and designs will be developed in accordance to:
•
•
SKA-TEL-SKO-0000103 - SKA Support Concept
SKA-TEL-SKO-0000104 - SKA Integrated Logistic Support Plan (ILSP).
1.3.15.2
SKA1-FLD-1206 Availability
The following applies to each of SKA1-low and SKA1-mid telescopes separately. In general available means that the telescope or a fraction thereof as defined below
is available to an operator to be scheduled for science or other operations.
Availability is defined as A=MTBF' / (MTBF' + MTTR'), where MTBF’ is the mean time between failures (based on the conditional probability of failure), given that
regular inspection or preventative maintenance is done, and MTTR' is the total time spent on these two activities plus any repair time.
•
Availability Fraction is defined as (N Ae) / (Nmax Ae_max), where N is the number of schedulable major modes and Ae is the effective area available; Nmax is
the number of major modes in the full set of defined modes; Ae_max is the maximum effective area of the telescope.
21/09/2015 7:42 am
Page
32 of 196
•
Major modes correspond to the main categories of observations that the telescope is designed to carry out. For each frequency band defined for the telescope
they are:
•
•
•
•
•
Spectral line observations.
Pulsar search observations.
Pulsar timing observations.
Continuum observations.
Transient detection.
The telescope system will have three availability states:
1.
Available: The availability fraction is 95%
2.
Degraded: The availability fraction is between 50 and 95%.
3.
Unavailable: The availability fraction is less than 50%.
In a running average over a year, the design requirement is:
◦
Unavailable for <5% of the time, corresponding to ~18 days per year.
◦
Degraded for <5% of the time, corresponding to ~18 days per year.
◦
Available >90% of the time, corresponding to ~329 days per year.
Natural disturbances of severity outside design boundaries are not counted against availability, unless the system does not behave according to design. The
availability state depends only on the telescope, itself.
The operational state of all sub-systems shall be defined as 'failed', 'degraded' or 'available'. It shall be possible to sense and log the operational state (failed,
degraded, or available) of every sub-system at the system level.
Parent Comment Issue
Michael Rupen
1 September 2015 Seems a fundamental flaw that availability is based solely on collecting area,
ignoring bandwidth and Tsys. I believe this should be tied more directly to the
scientific figures of merit (e.g., point-source sensitivity, survey speed, pulsar
search/timing speed) and potentially be defined differently for each observing
mode.
1.3.15.2.1
SKA1-FLD-1507 Telescope availability
Availability includes Available and Degraded availability states.
1.3.15.2.1.1
SKA1-SYS_REQ- Telescope availability
2716
Average annual availability. Each SKA1 telescope shall have an operational availability of 95%
21/09/2015 7:42 am
Page
33 of 196
1.3.15.3
SKA1-FLD-1212 Reliability
1.3.15.3.1
SKA1-FLD-1226 Fail safe provisions
1.3.15.3.1.1
SKA1-SYS_REQ- Fail safe provisions.
2525
Fail safe provisions. Designs shall implement fail-safe provisions to prevent secondary failures.
1.3.15.4
SKA1-FLD-1227 Maintainability
(Con Ops Section 5.1) There are SKA-specific factors beyond standard availability requirements that require particular attention and for which additional design effort
and capital expenditure is justified. These are needed mainly to keep human occupancy on the sites to a minimum, as well as to enhance maintenance efficiency:
•
•
•
Remote diagnostic and repair: In practice, this means that the monitor and control systems allow for a deep level of interrogation of sensor values and system
state.
Line-replaceable units: On-site repair will be particularly difficult and expensive at the remote sites. Systems should be designed to contain line replaceable units
where feasible.
Configuration Management System: Configuration management is a systems engineering process for managing the logistics of maintenance, tracking system
documentation, and supplying real-time information to inform the system model. For this to work properly the system model must be tailored to SKA
requirements.
Due to the geographically distributed nature of the SKA observatory there will be echelons or levels of maintenance for components of the observatory. Traditionally
these have included:
•
•
•
Site
Operations centre
Supplier
The maintenance functions for components at each level need to be defined along with their turnaround time (TAT) for repair.
The logistics pipeline time and Level of repair policies will be defined in an SKA1 Logistics Engineering Management Plan. This is assumed to include personnel
quantities and skills at each level of maintenance.
1.3.15.4.1
SKA1-FLD-1304 Design for maintainability
1.3.15.4.1.1
SKA1-FLD-1305 Modular packaging
21/09/2015 7:42 am
Page
34 of 196
1.3.15.4.1.1.1
SKA1-SYS_REQ- Modular packaging.
2594
Modular packaging. The packaging of components shall be modular to limit maintenance to the removal of one module.
Parent Comment General
Michael Rupen
1 September 2015 Parent requirement no longer exists
1.3.15.4.1.10
SKA1-FLD-1315 Module labelling
1.3.15.4.1.10.1
SKA1-SYS_REQ- Module labelling.
2604
Module labelling. Where possible, labelling of modules shall be on the top or adjacent in plain sight.
Parent Comment General
John Bunton
31 August 2015
Rack unit should have labelling on the item and in front. On top cannot be seen.
Parent Comment General
Michael Rupen
1 September 2015 Parent requirement 2802 no longer exists.
Parent Comment Proposed Change Michael Rupen
1 September 2015 Suggest:
Labeling of modules shall be in a conspicuous location, viewable when removed
or when installed in their intended operating environment.
1.3.15.4.1.11
SKA1-FLD-1316 Label robustness
1.3.15.4.1.11.1
SKA1-SYS_REQ- Label robustness.
2605
Label robustness. Labels shall be permanently affixed and unlikely to come off during maintenance or as a result of the environment.
Parent Comment General
Michael Rupen
1 September 2015 Parent requirement 2802 no longer exists.
1.3.15.4.1.12
SKA1-FLD-1317 Disposable item labelling
1.3.15.4.1.12.1
SKA1-SYS_REQ- Disposable LRU labelling.
2606
Disposable LRU labelling. Disposable line replaceable units should be labelled as such.
Parent Comment General
Michael Rupen
1 September 2015 Parent requirement 2802 no longer exists.
1.3.15.4.1.2
SKA1-FLD-1306 Maintenance Provisions
1.3.15.4.1.2.1
SKA1-SYS_REQ- Maintenance provisions.
2595
Maintenance provisions. Repairable items shall be designed to include maintenance provisions such as test points, accessibility, and plug-in components.
Parent Comment General
Michael Rupen
1 September 2015 Parent requirement no longer exists.
21/09/2015 7:42 am
Page
35 of 196
1.3.15.4.1.3
SKA1-FLD-1309 Module access
1.3.15.4.1.3.1
SKA1-SYS_REQ- Module access.
2598
Module access. Where applicable, access between modules shall be sufficient to facilitate hand grasping.
Parent Comment General
Wallace Turner
10 July 2015
Rev 6 comment Juande Santander-Vela
Similar to other requirements, it would be good to have a requirement for "Items
for which access between modules is insufficient to allow hand grasping shall be
declared".
Parent Comment General
Wallace Turner
10 July 2015
Reply to Juande
The declaration of modules with insufficient space to allow hand grasping is a
process and should be included in a process document/ SoW
No further action
Parent Comment Proposed Change John Bunton
31 August 2015
Parent Comment General
Michael Rupen
1.3.15.4.1.4
SKA1-FLD-1310 Component removal
1 September 2015
21/09/2015 7:42 am
A server rack unit can be classed as a module but when installed it cannot be
grasped by hand. Suggest that "a module can be manipulated so that there is
sufficient space to facilitate hand grasping" For the server the manipulation is
remove connectors, undo mounting bolts and slide out. It can now be grasped
by hand.
Parent requirement no longer exists.
Page
36 of 196
1.3.15.4.1.4.1
SKA1-SYS_REQ- Component removal.
2599
Component removal. Modules and components shall be mounted such that removal of any single item will not require the removal of other items (component
stacking to be avoided where possible)
Parent Comment General
Michael Rupen
1 September 2015 Parent requirement no longer exists.
1.3.15.4.1.5
SKA1-FLD-1311 Secure mounting of modules
1.3.15.4.1.5.1
SKA1-SYS_REQ- Secure mounting of modules.
2600
Secure mounting of modules. Modules shall be securely mounted (in compliance with the shock and vibration requirements) with the minimum number of fasteners.
Parent Comment General
Michael Rupen
1 September 2015 Parent requirement no longer exists.
1.3.15.4.1.6
SKA1-FLD-1312 Shock mounting provision
1.3.15.4.1.6.1
SKA1-SYS_REQ- Shock mounting provision.
2601
Shock mounting provision. Shock mounting provisions shall be made where applicable.
Parent Comment General
Michael Rupen
1 September 2015 Parent requirement no longer exists.
Parent Comment Proposed Change Michael Rupen
1 September 2015 "Where applicable" is too vague to be useful. Suggest replacing this with "where
feasible", which seems to meet the intent.
1.3.15.4.1.7
SKA1-FLD-1313 Mounting preclusion
1.3.15.4.1.7.1
SKA1-SYS_REQ- Mounting preclusion.
2602
Mounting preclusion. Provisions for the preclusion of mounting the wrong module shall be provided (key coding of connectors etc.).
Parent Comment Proposed Change John Bunton
31 August 2015
What about putting rack units in a rack. Suggest this be changed to include the
phrase "where there is the possibility of damage"
1.3.15.4.1.8
SKA1-FLD-1139 Stand-offs and handles
1.3.15.4.1.8.1
SKA1-SYS_REQ- Stand-off and handles.
2448
Stand-off and handles. Stand-offs and handles shall be used to protect system components from damage during shop maintenance.
Parent Comment General
Michael Rupen
1 September 2015 Parent requirement 2802 no longer exists.
Parent Comment Proposed Change Michael Rupen
21/09/2015 7:42 am
1 September 2015
Suggest changing "shop maintenance" to "out-of-system repair and
maintenance".
Page
37 of 196
1.3.15.4.1.9
SKA1-FLD-1314 Mounting guides
1.3.15.4.1.9.1
SKA1-SYS_REQ- Mounting guides.
2603
Mounting guides. Mounting guides and location pins shall be provided to facilitate module mounting.
Parent Comment General
Michael Rupen
1 September 2015 Parent requirement 2802 no longer exists.
1.3.16
SKA1-FLD-1204 Quality Factors Requirements
1.3.16.1
SKA1-FLD-1240 Testability
1.3.16.1.1
SKA1-FLD-1244 Test equipment reliability
1.3.16.1.1.1
SKA1-SYS_REQ- Test equipment reliability
2541
Test equipment reliability. Test equipment reliability shall be sufficient to meet the maintainability requirements.
Parent Comment General
Parent Comment Question
1.3.16.1.2
Michael Rupen
Michael Rupen
1 September 2015
1 September 2015
Parent requirement 2802 no longer exists.
Isn't this just an elaboration of the maintainability requirements? If so, why do we
need a separate requirement here?
SKA1-FLD-1246 Direct fault indicators
Direct fault indicators including fault lights audio warnings etc.
1.3.16.1.2.1
SKA1-SYS_REQ- Direct fault indicators
2543
Direct fault indicators Where possible, direct fault indicators shall be designed in to equipment.
Parent Comment General
Wallace Turner
10 July 2015
CSP comment
Clearer and more precise L1 requirement is needed to ensure consistency
across Elements. SKAO should clarify the maintenance concept.
SKAO to clarify requirement.
Parent Comment General
Wallace Turner
10 July 2015
Reply to CSP
There is now a logistics document set (logistics plan issue + 2 further documents
in preparation) that covers this issue.
No further action
Parent Comment General
21/09/2015 7:42 am
Michael Rupen
1 September 2015
Parent requirement no longer exists.
Page
38 of 196
1.3.16.1.3
SKA1-FLD-1247 Self-test
1.3.16.1.3.1
SKA1-SYS_REQ- Self-test.
2544
Self-test. Self-Test capability such that all faults can be identified down to LRU level shall be provided.
Parent Comment General
Michael Rupen
1 September 2015 Parent requirement no longer exists.
1.3.16.1.4
SKA1-FLD-1249 Continuous performance monitoring
1.3.16.1.4.1
SKA1-SYS_REQ- Continuous performance monitoring.
2546
Continuous performance monitoring. Where possible, the system shall be designed to provide continuous performance monitoring.
Parent Comment General
Michael Rupen
1 September 2015 Parent requirement no longer exists.
1.3.16.1.5
SKA1-FLD-1255 Malfunction detection
1.3.16.1.5.1
SKA1-SYS_REQ- Malfunction detection.
2552
Malfunction detection. All equipment malfunction shall be detected at the system level.
Parent Comment General
Wallace Turner
10 July 2015
Rev 6 comment Juande Santander-Vela
Does this mean that malfunctions need to be reported to the Telescope
Manager, and not hidden by items lower in the hierarchy? Perhaps it would be
better to make that explicit
Parent Comment General
Wallace Turner
10 July 2015
Rev6A comment Mark Waterson
well, this is actually a desirement.
Given the previous requirements for self test and continuous monitoring this
seems redundant.
I would advocate stating the requirement as detecting failure at subsystem and
transmitting to TM for evaluation/action.
Parent Comment General
Wallace Turner
10 July 2015
Parent Comment General
Michael Rupen
1 September 2015
1.3.17
SKA1-FLD-1270 Configuration Management
1.3.17.1
SKA1-FLD-1607 Product configuration information
21/09/2015 7:42 am
Reply to Juande & Mark
The detail you suggest is at a lower level than L1.
Perhaps a rewording along the lines of:
SKA1_Mid/ SKA1_Low monitoring shall detect at least x% of all equipment
malfuctions down to line replaceable unit level
Parent requirement no longer exists.
Page
39 of 196
Product configuration information comprises both product definition and product operational information. This typically includes requirements, specifications, design
drawings, parts lists, software documents and listings, models, test specifications, maintenance and operating handbooks.
Product configuration information should be relevant and traceable. Numbering conventions should be established that are unique and ensure proper control of
configuration items. These should take into consideration the existing numbering conventions of the organization and the change control information, such as revision
status.
1.3.17.1.1
SKA1-FLD-1271 Materials
Use is to be made of adequate and (ecological) allowed permissible materials, deviations to be approved by the consortia leads (or their nominated authority),
including management of applied materials.
The objectives are the following:
a) To ensure that all requirements of the program are met,
b) To verify the Materials, Parts and Processes activity of equipment suppliers,
c) To control and monitor the status of Materials, Parts and Processes in accordance with program milestones and regulations
Parent Comment General
Wallace Turner
10 July 2015
Rev 6 comment Juande Santander-Vela
The ecological label applied to a material does not a have a unique meaning.
Consider removing it, and changing the requirement to something like:
Use is to be made of adequate and permissible materials (including, where
possible, minimisation of environmental impact), deviations to be approved by
the consortia leads (or their nominated authority), including management of
applied materials.
My formulation still has the problem of not being uniquely identifiable, but I think
it better points in the desired direction.
1.3.17.1.2
SKA1-FLD-1280 Nameplates and Marking
Components, (sub) systems, instruments, equipment, and materials shall be marked for configuration control purposes and maintenance support purposes.
1.3.17.1.2.1
SKA1-FLD-1281 Serial numbers
1.3.17.1.2.1.1
SKA1-SYS_REQ- Serial number.
2573
Serial number. Each part shall be marked with a unique serial number in an easily visible location.
Parent Comment Proposed Change Michael Rupen
1 September 2015 Marking each part with a unique serial number is not feasible and the cost could
be astonomical. One only needs unique marking for items which will require
unique QA products (calibration certificates, Test Results, etc) during
21/09/2015 7:42 am
Page
40 of 196
manufacture and integration.
SKA should define a part/serial number standard or at least define the minimum
requirements for part identification systems to be used by
supplier/manufacturers.
Suggested change in wording:
Each manufactured item or assembly (LRU/SRU) used in the SKA1 telescopes,
requiring an Acceptance Test Procedure or needing individual characterisation,
calibration or setup, shall display a unique identification in accordance with TBD
(SKA standard or procedure), in an easily visible location.
1.3.17.1.2.2
SKA1-FLD-1283 Marking method
1.3.17.1.2.2.1
SKA1-SYS_REQ- Marking method.
2575
Marking method. Method of marking shall be compatible with the nature of the item, its environment and its use.
Parent Comment Issue
Michael Rupen
1 September 2015 This is not a verifiable requirement. Reference should be made here to an
international or a SKA Standard as the object of the action.
1.3.17.1.2.3
SKA1-FLD-1284 Electronically readable or scannable ID
21/09/2015 7:42 am
Page
41 of 196
1.3.17.1.2.3.1
SKA1-SYS_REQ- Electronically readable or scannable ID
2576
Electronically readable or scannable ID. Where possible line replaceable items shall be marked with an Electronically readable or scannable ID.
Parent Comment General
Wallace Turner
10 July 2015
CSP comment GvdM
Clarification required
It is not clear what is required here.
1. What is meant by ID - Part number and serial number?
2. Is the "ID" to be readable when the LRU is powered and connected in the
System?
3. Is the "ID" to be readable when the LRU is not powered and not connected in
the System (i.e. while in storage)?
4. Or both 2. and 3. above?
1.3.17.1.2.4
SKA1-FLD-1285 Packaging part number marking
1.3.17.1.2.4.1
SKA1-SYS_REQ- Package part number marking.
2577
Package part number marking. All packaging shall be marked with the part number of the contents.
1.3.17.1.2.5
SKA1-FLD-1286 Packaging serial number marking
1.3.17.1.2.5.1
SKA1-SYS_REQ- Package serial number marking.
2578
Package serial number marking. All packaging shall be marked with the serial number of the contents.
1.3.17.1.2.6
SKA1-FLD-1288 LRU electrostatic warnings
1.3.17.1.2.6.1
SKA1-SYS_REQ- LRU electrostatic warnings
2580
LRU electrostatic warnings All LRUs with electrostatic sensitive components shall be fitted with ESD warning labels.
1.3.17.1.2.7
SKA1-FLD-1291 Cable identification
1.3.17.1.2.7.1
SKA1-SYS_REQ- Cable identification.
2583
Cable identification. All cables ends shall carry a unique identifier.
1.3.17.1.2.8
SKA1-FLD-1292 Connector plates
21/09/2015 7:42 am
Page
42 of 196
1.3.17.1.2.8.1
SKA1-SYS_REQ- Connector plates. All connector plates shall carry identification labels for connectors
2584
Connector plates. All connector plates shall carry identification labels for connectors.
1.3.18
SKA1-FLD-1327 Verification Provisions
1.3.18.1
SKA1-FLD-1328 Methods
Demonstration (D): Operation of the system, subsystem or a part of the system that relies on observable, functional operation, not requiring use of instrumentation,
special test equipment or subsequent analysis.
Test (T): Operation of the system, subsystem or a part of the system using instrumentation or other special test equipment to collect data for later analysis.
Analysis (A): Processing of accumulated data obtained from other qualification methods. Examples are reduction interpolation or extrapolation of test results.
Inspection (I): Visual examination of system components, documentation, etc.
Special Verification Methods: Special verification methods for the system or subsystem, for example, special tools, techniques, procedures, facilities, acceptance
limits, use of standard samples, preproduction or periodic production samples, pilot models or pilot lots.
1.3.19
SKA1-FLD-1330 Appendix A: Requirements Traceability Matrices
This appendix contains tabularized requirements traceability to the source documentation and to the next lower tier documentation where known.
1.3.2
SKA1-FLD-811
References
1.3.2.1
SKA1-FLD-812
Applicable documents
In the event of conflict between the contents of the applicable documents and this SKA1 System Requirement Specification (SRS) document, the applicable
documents shall take precedence;
[1] SKA1 System Baseline Design SKA-TEL-SKO-DD-001 Rev 1
[2] Concept of Operations for the SKA Observatory SKA.TEL.SE.OPS-SKO-COO-001-0-A
21/09/2015 7:42 am
Page
43 of 196
[3] Operational Requirements Document (in preparation)
[4] SKA EMI/EMC standards SKA EMI/EMC Standards and Procedures SKA-TEL-SKO-0000202-AG-RFI-ST-01
[5] RFI Characterisation and SKA1 Signal Chain Design Consideration (in preparation)
[6] SKA1_Low Configuration Coordinates (in preparation)
[7] SKA1_Mid Configuration Coordinates (in preparation)
[8] SKA1 Rebaselining outcome summary (in preparation)
[9] SKA Project Safety Management Plan (in preparation)
Parent Comment General
Michael Rupen
17 August 2015
This is rather dangerous, as most of the designers I know do not look at the
parents for the requirements, but simply trust that the individual requirements are
correct. The L1s should be conceived of (at least) as "one-stop-shopping", and
presumed accurate for a given set of "parent" documents. The main consumers
of this document are the engineers designing the telescope; they have neither
the time nor the expertise needed to check whether the ADs have changed more
recently than the requirements, and if so, to figure out how the requirements
must be modified. Perhaps the current verbiage is purely legal and has to be in
as is, but if not, a more reasonable statement would be helpful. Perhaps
something along the lines of:
* These requirements represent the fundamental definition of the telescope as
given to the design teams.
* These requirements are based on the following REFERENCE documents with
the indicated versions. Updates to the documents indicated [i.e., the ones
currently called "Applicable"] should lead to a revision of these requirements.
A separate comment (but there seems no way to do that?): Is the goal
consistency with V2 of the Baseline Design, rather than the quoted v1? I.e.,
post-re-baselining. Similarly please check the Revisions of the other documents
to be sure they're accurate.
Parent Comment General
Shandip Abeywickrema
31 August 2015
INAU to provide comment on SKAO EMI/EMC document. We request further
discussions and that the current CSIRO Murchison Radio-astronomy
Observatory RFI standards are utilised until agreement on the SKAO EMI/EMC
document is reached.
Common comment for all requirements that reference the SKAO EMI/EMC
21/09/2015 7:42 am
Page
44 of 196
standard.
1.3.2.2
SKA1-FLD-813
Reference documents
The following documents are referenced in this document. In the event of conflict between the contents of the referenced documents and this document, this document
shall take precedence.
[10]SKA Memo 130: 'SKA Phase 1: Preliminary System Description', P.E. Dewdney et al, dated November 2010.
[11]Logistics Engineering and Management B.S. Blanchard Sixth Edition Prentice Hall
[12] Reliability-Centred Maintenance John Moubray Second Edition Butterworth-Heinemann
[13] Practical Reliability Engineering Patrick D.T. O'Connor Fourth Edition Wiley
[14] System Engineering Management B.S Blanchard Third Edition Wiley
[15] The Basics of FMEA R.E. McDermott, R.J. Mikulak
[16] M.R. Beauregard Second Edition CRC Press
[17] RFI Protection and Threshold Levels for the SKA SKA.TEL.OFF.PAQA.RFI-SK0-TN-001
[18] Rau, U., Bhatnagar, S., Voronkov, M.A., and Cornwell, T.J., "Advances in Calibration and Imaging Techniques in Radio Interferometry", Proc IEEEE, 97, 14721481, (2008)
[19] U. Rau and T. J. Cornwell, A multi-scale multi-frequency deconvolution algorithm for synthesis imaging in radio interferometry A&A 532, A71 (2011)
[20] S.J. Wijnholds, J.D. Bregman and A.van Ardenne, Calibratability and its impact on configuration design for LOFAR and SKA phased array radio telescopes, Radio
Science, vol. 46, No. RS0F07, 8 November 2011
[21] C.J. Lonsdale, D. Oberoi, A.J Coster and P.J Erickson, The Effects of Variable Ionospheric and Plasmaspheric Faraday Rotation on Low Frequency Radio Arrays,
Proceedings of the XXXth General Assembly and Scientific Symposium of the International Union of Radio Science (URSI GASS), Istanbul (Turkey), 13 - 20 August
2011
[22] A. Schutte SKA1 Power Budget SKA-SE-POW-TN-001 Rev2
[23] Configuration Management Plan (in preparation)
Parent Comment General
Michael Rupen
1.3.2.3
SKA1-FLD-814 Reference Standards
17 August 2015
I did not check whether each of these documents is in fact referred to in the text.
[24] IEEE Systems and Software engineering – System life cycle processes ISO/IEC 15288-2008
21/09/2015 7:42 am
Page
45 of 196
[25] IEEE Guide for Developing Systems Specifications IEEE Std 1233 1998 Edition
[26] MIL-HDBK-520A Specification Practices
[27] Occupational Health and Safety [OHS] Act, No. 181 1993 (General Machinery regulations 1988, Construction regulation 2003)
[28] National Environmental Management Act [NEMA] Act No. 107 1998
[29] Occupational Health and Safety (Commonwealth Employment) Act 1991
[30] Safety of machinery - Functional safety of safety-related electrical, electronic and programmable electronic control systems IEC 61508
[31] Safety of machinery. Electrical equipment of machines general requirements BS EN 60204-1
[32] Low voltage switchgear and controller gear BS EN 60947-5-5
[33] Safety of machinery. Safety-related parts of control systems general principles for design BS EN ISO 13849-1
[34] Generic Requirements for Network Equipment in the Outside Plant (OSP) GR-3108-Core Iss 3.
[35] Equipment Engineering Environmental conditions and environmental tests for telecommunications equipment Part 1-2: Classification of environmental conditions
Transportation ETS 300 019-1-2
1.3.20
SKA1-FLD-1331 Appendix B: Verification Matrices
This appendix contains tabularized verification method for every system or subsystem requirement.
1.3.21
SKA1-FLD-1332 Appendix C: Requirement Allocation Matrices
1.3.22
SKA1-FLD-1333 Appendix D: Power Budget Allocation
1.3.22.1
SKA1-FLD-1334 Power Budget allocation Africa
Values are to be informed in by the Power Allocation Process.
1.3.22.2
SKA1-FLD-1335 Power Budget Allocation Australia
Values are to be informed by the Power Allocation Process.
1.3.23
SKA1-FLD-1336 Appendix E: Availability, Reliability Maintainability Allocations
21/09/2015 7:42 am
Page
46 of 196
1.3.23.1
SKA1-FLD-1510 SKA1_low availability allocations
Figure 14 The availability block diagram for SKA1-low
Availability Requirements for Sub-systems of SKA1-low
Block
Availability Requirement
Notes
Available
Available or Degraded
SKA1-low Outer Station Array
> 0.9969
>0.9937
MTBF margin of 1.5
Signal Aggregation & Digitisation
Beamformers
"
"
"
AA Station Beamformers
"
"
"
DDBH
"
"
"
SKA1-low Inner Station Array
"
"
"
AA Station Beamformer Subsystem
"
"
Parent Comment General
21/09/2015 7:42 am
Wallace Turner
10 July 2015
Rev6A comment Wallace Turner
Section to be updated to reflect SKA-TEL-SKO-0000102 - SKA RAM Allocations
Page
47 of 196
Parent Comment General
1.3.23.2
John Bunton
31 August 2015
I don't see an allocation to the correlator. Would expect something more like
what is given for MID 1.2.23.2
SKA1-FLD-1511 SKA1_mid availability allocations
Figure 14 The availability block diagram for SKA1-Mid
Availability Requirements for Sub-systems of SKA1-mid
Block
Availability Requirement
Notes
Available
Available or Degraded
Front End Array
>0.9969
> 0.9937
MTBF margin of 1.5
Dish Array
"
"
"
Synchronisation Dist’n
"
"
"
Power Dist’n
"
"
"
21/09/2015 7:42 am
Page
48 of 196
DDBH
"
"
"
Correlator
>0.9969
"
"
Non-Imaging Processor
>0.90
>0.85
Lower requirement
CSP=>SDP
"
"
"
SDP
"
"
"
Telescope Manager
"
"
"
Site Facilities
"
"
"
Critical Off-site Facilities
"
"
"
1.3.24
SKA1-FLD-1337 Glossary
A selected glossary extracted from IEEE Std 1233:
baseline: A specification or system that has been formally reviewed and agreed upon, that thereafter serves as the basis for further development and can be changed
only through formal change control procedures. (IEEE Std 610.12-1990)
constraint: A statement that expresses measurable bounds for an element or function of the system. That is, a constraint is a factor that is imposed on the solution by
force or compulsion and may limit or modify the design changes.
derived requirement: A requirement deduced or inferred from the collection and organization of requirements into a particular system configuration and solution.
customer(s): The entity or entities for whom the requirements are to be satisfied in the system being defined and developed. This can be an end-user of the
completed system, an organization within the same company as the developing organization (e.g., System Management), a company or entity external to the
developing company, or some combination of all of these. This is the entity to which the system developer must provide proof that the system developed satisfies the
system requirements specified.
end user: The person or persons who will ultimately be using the system for its intended purpose.
environment: The circumstances, objects, and conditions that will influence the completed system; they include political, market, cultural, organizational, and physical
influences as well as standards and policies that govern what the system must do or how it must do it.
fidelity: the degree of exactness with which something is copied or reproduced.
function: A task, action, or activity that must be accomplished to achieve a desired outcome.
logical control and monitoring: the control and monitoring necessary for subarrays to operate. "Logical" is used to diferentiate from physical processing and
networking.
logical data flows: the data flows that are necessary for subarrays of the telescope to operate. "Logical" is used to diferentiate from physical processing and
21/09/2015 7:42 am
Page
49 of 196
networking.
model: A representation of a real world process, device, or concept.
prototype: An experimental model, either functional or non-functional, of the system or part of the system. A prototype is used to get feedback from users for
improving and specifying a complex human interface, for feasibility studies, or for identifying requirements.
Pulsar search:Pulsar Search is defined to mean the complete digital signal processing for detecting pulsars and non-imaging transients. This includes but is not be
limited to:
• Beam-forming of tied-array beams at specified sky locations over a specified continuous bandwidth.
• Channelization and temporal averaging of beamformed data to a specified number of channels and sampling interval.
• Averaging/correlating polarisation beams to form Stokes vectors.
• De-dispersion of beamformed data at specified dispersion measures, to produce de-dispersed time-series.
• Detection of individual pulses in the de-dispersed time-series.
• Detection of periodic signals in the de-dispersed time-series, including corrections for binary motion of pulsars over a specified range of accelerations.
• Selection of candidates.
• Output of Pulsar Candidates and Non-imaging Transient Candidates into the SKA archive.
raw requirement : An environmental or customer requirement that has not been analysed and formulated as a well-formed requirement.
representation: A likeness, picture, drawing, block diagram, description, or symbol that logically portrays a physical, operational, or conceptual image or situation.
requirement:
(A)A condition or capability needed by a user to solve a problem or achieve an objective.
(B)A condition or capability that must be met or possessed by a system or system component to satisfy a contract, standard, specification, or other formally imposed
document.
(C)A documented representation of a condition or capability as in definition (A) or (B). (IEEE Std 610.12-1990)
Scheduling block: Scheduling Blocks are the indivisible executable units of a project and contains all information necessary to execute a single observation. A
scheduling block may be stopped and cancelled but not paused and resumed.
Scheduling block boundaries :the temporal boundary between the end of the execution of a scheduling block, and the the start of execution of the next. Multiple
integrations/scans fall within a scheduling block.
Subarray:"Sub-arrays" implies that the collecting area is sub-divided and each part is scheduled independently. The definition includes the sub-division of any
resource in the system (correlator, NIP, beamformers, SDP, etc.). A non-astronomy sub-array may not need an entire system slice but this is not precluded.
Conversely, an astronomy sub-array requires end-to-end capability, full TM support, etc. (a full system "slice").
system: An interdependent group of people, objects, and procedures constituted to achieve defined objectives or some operational role by performing specified
functions. A complete system includes all of the associated equipment, facilities, material, computer programs, Firmware, technical documentation, services, and
personnel required for operations and support to the degree necessary for self-sufficient use in its intended environment.
21/09/2015 7:42 am
Page
50 of 196
System Requirement Specification (SyRS): A structured collection of information that embodies the requirements of the system.
testability: The degree to which a requirement is stated in terms that permit establishment of test criteria and performance of tests to determine whether those criteria
have been met. (IEEE Std 610.12-1990)
traceability: The degree to which a relationship can be established between two or more products of the development process, especially products having a
predecessor-successor or master-subordinate relationship to one another; e.g., the degree to which the requirements and design of a given system element
match.(IEEE Std 610.12-1990)
validation: The process of evaluating a system or component during or at the end of the development process to determine whether a system or component satisfies
specified requirements. (IEEE Std 610.12-1990)
verification: The process of evaluating a system or component to determine whether the system of a given development phase satisfies the conditions imposed at the
start of that phase. (IEEE Std 610.12-1990)
well-formed requirement: A statement of system functionality (a capability) that can be validated, and that must be met or possessed by a system to solve a
customer problem or to achieve a customer objective, and is qualified by measurable conditions and bounded by constraints.
Parent Comment General
Wallace Turner
10 July 2015
Parent Comment General
Wallace Turner
10 July 2015
Parent Comment General
Michael Rupen
1 September 2015
1.3.3
SKA1-FLD-1530 Observatory structure
1.3.3.1
SKA1-FLD-1617 Observatory functions
Rev 6 comment Juande Santander-Vela
Consider changing the definition of well-formed requirement to better align with
the new version of the SEMP, which indicates the attributes of a well-formed
requirement.
Reply to Juande
Tim Stevenson confirmed the definition is consistent with the SEMP
No further action required
Pulsar Search definition refers to "detecting...non-imaging transients."
Transients are astronomical (we hope ;) objects -- non-imaging characterizes the
method by which they are to be found by Pulsar Search, not the transients
themselves.
The Observatory functions have been described by the Board [1]. Here we show the allocation of these functions to the top level components of the adopted
Observatory model.
21/09/2015 7:42 am
Page
51 of 196
Parent Comment General
Parent Comment General
Michael Rupen
Paul Swart
1.3.3.2
Global Headquarters
SKA1-FLD-817
Figure 2 Observatory Functions
17 August 2015
The figure is cut off both here and in the PDF, so I can't really review it.
31 August 2015
Would like to see a description for each of these functions. because it is not clear
what exactly is meant with the function headings.
1.3.3.2.1
SKA1-SYS_REQ- Global Headquarters.
2113
Global Headquarters The SKA Global Headquarters (GHQ) will have overall responsibility for the SKA Observatory.
Parent Comment General
Wallace Turner
10 July 2015
Rev 6 comment Juande Santander-Vela
Perhaps a better understanding of what is the list of overall responsibilities would
be good, or indicate that these responsibilities are defined by the ConOps.
Parent Comment General
Wallace Turner
10 July 2015
This was considered for Rev6A but not implemented:
Demote from a requirement to a statement. Add ref [2] to statement.
Parent Comment General
1.3.3.3
SKA1-FLD-818
Paul Swart
Site location
31 August 2015
Agree with Wallace's comment to be specific about responsibilities for GHQ
Parent Comment General
21/09/2015 7:42 am
Paul Swart
31 August 2015
Agree with Wallace's comment to be specific about responsibilities for GHQ.
Page
52 of 196
1.3.3.3.1
SKA1-SYS_REQ- Site location.
2114
Site location. The SKA1 Antenna systems and digital signal chain shall be located within radio quiet zones provided by the Host Countries of South Africa and
Australia.
Parent Comment General
Wallace Turner
10 July 2015
Rev 6 comment Gie Han Tan
Description needs updating, not all of the digital signal chain will be within the
RQZs.
Parent Comment General
Wallace Turner
10 July 2015
Reply to Gie Han Tan
The requirement is lbased on the antenna systems and as such is largely
applicable. If SDP is to be excluded from this then perhaps the digital signal
processing chain could be qualified by "front-end" or "associated" ?
1.3.3.4
SKA1-FLD-815
Distribution and deployment
1.3.3.4.1
SKA1-FLD-1514 Australia
1.3.3.4.1.1
SKA1-FLD-826
SKA1_low array
1.3.3.4.1.1.1
SKA1-SYS_REQ- SKA1_low array.
2124
SKA1_low array. The SKA1_low array shall be located within the legal boundary of the Boolardy station.
Parent Comment General
Wallace Turner
10 July 2015
Rev 6 comment Juande Santander-Vela
Perhaps add a reference to the definition of the legal boundary? Could this be
the Hosting Agreement?
Parent Comment General
Wallace Turner
10 July 2015
Although useful context, referencing the legal aspects of the hosting agreement
is a distraction at L1. Suggest removing requirement status from the statement
and including ref [3]
1.3.3.4.1.2
SKA1-FLD-1504 SKA1_low central frequency reference
1.3.3.4.1.2.1
SKA1-SYS_REQ- SKA1_low central frequency reference
2713
SKA1_low central frequency reference. The SKA1_low central frequency reference shall be located in the SKA1_low Central Signal Processing facility
Parent Comment General
Wallace Turner
10 July 2015
Rev 6 comment Rodrigo Olguin
This shall not be allocated to CSP, as the location is the Central Processing
Facility (CPF-INFRA)
Parent Comment General
Wallace Turner
10 July 2015
Agree. Remove CSP from allocation
21/09/2015 7:42 am
Page
53 of 196
1.3.3.4.1.3
SKA1-FLD-1437 SKA1_low CSP Facility
1.3.3.4.1.3.1
SKA1-SYS_REQ- SKA1_low CSP facility
2654
SKA1_low CSP facility. The facility housing the station beamformers for the inner area of the SKA1_Low and the central signal processing for SKA1_Low shall be at
a distance of 2 km South West of the centre of the SKA1_Low array.
Parent Comment General
Wallace Turner
10 July 2015
Rev 6 comment Mark Waterson
It does need to exist, and should be near the core, but I would have thought that
this should be a limit and the direction is not a requirement - there is a tradeoff
between cost of added signal transport length and RFI shielding effectiveness - it
may be cheaper to build a better building closer. Or not. but we shouldn't guess.
It also will house a lot more than the station beamformers - station signal
processing would be more accurate
Parent Comment General
Wallace Turner
10 July 2015
Rev 6 comment Roshene McCool
I would maintain that the topology is required for those designs that have
geography and distance as a significant design driver.
It might not be an applicable L1 requirement , but if it is taken out the the
information should be held in an applicable document and have a project
configured status.
Parent Comment General
Wallace Turner
10 July 2015
Rev 6 comment Mark Waterson
No suggestion to remove this, and probably any change should be related to the
release of the configuration. this is not related to the RBS tranche, just noticed
on the way past.
Parent Comment General
Wallace Turner
10 July 2015
CSP comment GvdM
GvdM: Obviously not applicable to CSP
Parent Comment General
Wallace Turner
10 July 2015
Reply to CSP: Agreed. Action remove allocation to CSP
Parent Comment General
Wallace Turner
10 July 2015
Reply to Rosh and Mark
Noted and agreed this isn't L1. However, removing the requirement would be
problematic at present. Suggest keeping it
No further action required
Parent Comment General
1.3.3.4.1.4
SKA1-FLD-822
Shandip Abeywickrema
31 August 2015
Australian Science Operations Centre
1.3.3.4.1.4.1
Amend to suit new Low configuration.
SKA1-SYS_REQ- Australian Science Operations Centre
2120
21/09/2015 7:42 am
Page
54 of 196
Australian Science operations centre. The Australian Science Operations Centre shall be in Perth.
Parent Comment General
Michael Rupen
17 August 2015
Consider referring to some document which defines what the Science Ops
Centre is. Note that the role of the Science Processing Centre is at least partially
laid out within these requirements (e.g., SKA1-SYS_REQ-2821).
1.3.3.4.1.5
SKA1-FLD-823
Australian Engineering Operations Centre
1.3.3.4.1.5.1
SKA1-SYS_REQ- Australian Engineering Operations Centre
2121
Australian Engineering Operations Centre The Australian Engineering Operations Centre shall be in in Geraldton.
Parent Comment General
Michael Rupen
17 August 2015
Consider referencing a document which says what the Engineering Operations
Center is. Note that the role of the Science Processing Centre is at least partially
laid out within these requirements (e.g., SKA1-SYS_REQ-2821).
Parent Comment General
Shandip Abeywickrema
31 August 2015
To keep consistent with Req-2123 should that requirement not state that the
EOC shall make use of the floor space etc. of the existing MRO Support Facility?
1.3.3.4.1.6
SKA1-FLD-825 Australian Science Processing Centre
1.3.3.4.1.6.1
SKA1-SYS_REQ- Australian Science Processing Centre
2123
Australian Science processing centre The Australian Science Processing Centre shall make use of floor space, power, cooling, and other infrastructure at the
Pawsey centre in Perth.
Parent Comment General
Wallace Turner
10 July 2015
SDP comment:
This places certain constraints on the SDP design which may cause issues.
When dealing with such a large HPC system it would be wise to design the most
efficient and capable HPC system and then design the Data centre to fit
requirements, not the other way roundSDP comment:
This places certain constraints on the SDP design which may cause issues.
When dealing with such a large HPC system it would be wise to design the most
efficient and capable HPC system and then design the Data centre to fit
requirements, not the other way round
Parent Comment General
Wallace Turner
10 July 2015
Roshene's reply
Noted. No Action Taken: This is the Baseline Design. The Baseline has been
established in order to facilitate parallel development of SKA sub-system in a
consortia partitioned project. Engineering change requests are the recognised
project process to adjust the baseline once further design and engineering work
has been completed.
Parent Comment General
21/09/2015 7:42 am
Wallace Turner
10 July 2015
Roshene's reply
Noted. No Action Taken: This is the Baseline Design. The Baseline has been
established in order to facilitate parallel development of SKA sub-system in a
Page
55 of 196
consortia partitioned project. Engineering change requests are the recognised
project process to adjust the baseline once further design and engineering work
has been completed.
Parent Comment General
Wallace Turner
10 July 2015
JSV:
JSV:Proposed rewriting:
The SKA1-Low telescope shall make use of the Pawsey centre in Perth to host
the Australian Science Processing Centre, and make use of floor space, power,
cooling, and other infrastructure available.
Element allocation: SDP, TM, INFRA, SADT
With regards to SDP comments, this is a design constraints that comes from
reuse requirements, and is a proper L1 requirement. An ECP should only be
raised if downstream requirements cannot be met.
Parent Comment General
Wallace Turner
10 July 2015
Reply SDP and Juande
There seems to be some agreement between Juande and Ferdl that the
requirement/ constraint can remain in place and if there is an issue identified in
detailed SDP design an ECP can be raised.
Consequently comment considered resolved. No further action required
1.3.3.4.2
SKA1-FLD-1515 South Africa
1.3.3.4.2.1
SKA1-FLD-821
SKA1_mid array
1.3.3.4.2.1.1
SKA1-SYS_REQ- SKA_Mid array.
2119
SKA1_Mid array. The SKA1_Mid dish array shall be located in the Karoo Central Astronomy Advantage Area.
Parent Comment General
Wallace Turner
10 July 2015
Rev 6 comment Juande Santander-Vela
Why not a similar formulation to the SKA1-Low one (SKA1-SYS_REQ-2124)? Or
there is no difference between Karoo Central Astronomy Advantage Area
(KCAAA) and the "legal" one? In any case, and the same as for SKA1-Low, I
propose to add the corresponding document that defines the KCAAA
Parent Comment General
Wallace Turner
10 July 2015
Reply to Juande. Aspects relating to the time scales of potential land aquisition
for the Austrailian site led to the constraint of staying within the legal boundary of
Boolardy. Aspects relating to this are a distraction for L1 requirements. Suggest
Jul 10, 2015, 8:03 AM Page 74 of 157
removing requirement status and referencing the Operations Requirements
document [3]
Action: Remove requirement status and add ref to ref [3]
21/09/2015 7:42 am
Page
56 of 196
1.3.3.4.2.2
SKA1-FLD-1439 SKA1_mid CSP Facility
1.3.3.4.2.2.1
SKA1-SYS_REQ- SKA1_mid CSP facility
2656
SKA1_mid CSP facility. The CSP facility for SKA1_mid shall be located in the Karoo Array Processor Building.
Parent Comment General
Michael Rupen
17 August 2015
Strictly speaking this seems a requirement on SaDT and INFRA, not on CSP or
TM. The argument for the allocation to CSP is that having to fit in this building
may influence the design. I am not sure why TM should care where CSP lives.
1.3.3.4.2.3
SKA1-FLD-1505 SKA1_mid central frequency reference
1.3.3.4.2.3.1
SKA1-SYS_REQ- SKA1_mid central frequency reference
2714
SKA1_mid central frequency reference. The SKA1_mid central frequency reference shall be located in the SKA1_mid Central Signal Processing facility
Parent Comment General
Michael Rupen
17 August 2015
Again the allocations to CSP and TM seem odd.
1.3.3.4.2.4
SKA1-FLD-819 South African Science Operations Centre
1.3.3.4.2.4.1
SKA1-SYS_REQ- South African Science Operations Centre
2115
South African Science Operations. The South African Science Operations Centre shall be located in Cape Town.
Parent Comment General
Michael Rupen
17 August 2015
Should refer to some document describing the role of this facility. Currently the
requirements say nothing about what this is.
1.3.3.4.2.5
SKA1-FLD-820
South African Science Processing Centre
1.3.3.4.2.5.1
SKA1-SYS_REQ- South African Science Processing Centre
2118
South African Science Processing Centre The South African Science Processing centre shall be located in Cape Town
21/09/2015 7:42 am
Page
57 of 196
1.3.3.4.2.6
SKA1-FLD-1338 South African Engineering operations Centre
1.3.3.4.2.6.1
SKA1-SYS_REQ- South African Engineering Operations Centre
2116
South African Engineering Operations Centre. The South African Engineering Operations Centre shall be located at Klerefontein.
Parent Comment General
Michael Rupen
17 August 2015
Should refer to some document describing the role of this facility. Currently the
requirements say nothing about what this is.
1.3.4
SKA1-FLD-1622 Telescopes
1.3.4.1
SKA1-FLD-839
SKA1_Low
Parent Comment General
Wallace Turner
10 July 2015
Parent Comment General
Wallace Turner
10 July 2015
1.3.4.1.1
SKA1-FLD-840
SKA1_Low Configuration and Performance
1.3.4.1.1.1
SKA1-FLD-1459 Receptor type
Rev 6 comment Juande Santander-Vela
If SysML only considers one flow direction, monitoring and commanding should
be in different channels, so that the flow is clear. Also, the lines in cyan are not
clear what is their purpose, and should be labelled, or at least the input ports.
Reply to Juande
The SYSML diagram has been removed. Consequently, the comment is no
longer applicable
No further action required
1.3.4.1.1.1.1
SKA1-SYS_REQ- Receptor type
2671
Receptor type. The SKA1_Low shall utilise dual, orthogonal, polarization log-periodic antennas.
Parent Comment General
Wallace Turner
10 July 2015
Rev6 comment Mark Waterson
should read dual orthogonal linearly-polarized log-periodic dipole antennas - the
original wording is meaningless.
Parent Comment General
Wallace Turner
10 July 2015
Rev6 comment GieHan Tan
Original description would allow either linear or circular polarization. Not sure if
having linear polarization is a L1 requirement that can be traced back to L0
science requirements.
Parent Comment General
21/09/2015 7:42 am
Wallace Turner
10 July 2015
Reply to Mark and Gie Han
Agree to some level with Gie Han's and Mark's comments. Suggest specification
of polarisation type is left open at L1. I would suggest that the log-periodic is also
Page
58 of 196
too prescriptive a contraint for L1.
Action ammend wording to:
The SKA1_Low shall utilise dual orthoganally polarised dipole antenna elements
1.3.4.1.1.10
General
Michael Rupen
17 August 2015
SKA1-FLD-1604 SKA1_Low array sensitivity at 340MHz.
Should be "orthogonally" (only one "a"), and needs a period.
1.3.4.1.1.10.1
SKA1-SYS_REQ- SKA1_Low array sensitivity at 340MHz.
2815
SKA1_Low array sensitivity per polarization at 340 MHz. The SKA1_Low array shall have a sensitivity per polarization at zenith greater than 453 m^2/K at 340
MHz when assuming a sky noise temperature following the law 60.lambda^2.55
1.3.4.1.1.11
SKA1-FLD-1408 Sensitivity for off zenith angles
1.3.4.1.1.11.1
SKA1-SYS_REQ- Sensitivity for off zenith angles
2622
Sensitivity for off zenith angles. The SKA1_Low receptor has an off-zenith beam response defined by the receptor, a log-periodic dipole antenna, in the Baseline
Design.
Parent Comment General
Michael Rupen
1.3.4.1.1.12
SKA1_Low antennas per station
SKA1-FLD-846
17 August 2015
After carefully calling out the zenith requirements it seems odd to force reference
to the Baseline Design here.
1.3.4.1.1.12.1
SKA1-SYS_REQ- SKA1_Low antennas per station.
2139
SKA1_Low antennas per station. The SKA1_Low shall comprise of stations each containing 256 antennas.
Parent Comment General
Michael Rupen
17 August 2015
Poorly worded. Suggest "Each station of SKA1_Low shall consist of 256
antennas." Or "be formed from". In any event you can't "comprise of".
1.3.4.1.1.13
1.3.4.1.1.13.1
SKA1-FLD-847
SKA1_Low station diameter
SKA1-SYS_REQ- SKA1_Low station diameter.
2140
SKA1_Low station diameter. The station diameter will be 35 metres, which is consistent with being able to provide a single, circularly symmetric, beam of 5 degrees
at the half-power points at 100 MHz (centre of the EoR frequency range) while meeting the sensitivity requirements with 256 antennas per station evenly distributed in
21/09/2015 7:42 am
Page
59 of 196
an irregular-random configuration.
Parent Comment General
Michael Rupen
17 August 2015
This is a pretty folksy requirement! Seems like we're giving the rationale for the
requirement, in the text of that requirement -- shouldn't these be separated? Of
course I really like have rationales for all requirements, but I don't think they
belong in the requirement text.
We've just said that each station is made up of 256 antennas. Should this
requirement be that the maximum distance between any two antennas
contributing to a given station, be less than 35 meters?
1.3.4.1.1.14
SKA1-FLD-851
SKA1_Low number of stations
1.3.4.1.1.14.1
SKA1-SYS_REQ- SKA1_Low number of stations.
2142
SKA1_Low number of stations. The SKA1_Low shall comprise of 512 stations.
Parent Comment General
Michael Rupen
17 August 2015
1.3.4.1.1.15
SKA1-FLD-852
1.3.4.1.1.15.1
SKA1-SYS_REQ- SKA1_Low configuration
2143
The stations comprise the telescope. Should be, SKA1_Low shall be comprised
of 512 stations.
SKA1_Low configuration
SKA1_Low configuration. The SKA1_Low shall have a configuration as specified in SKA_Low Configuration Co-ordinates [7].
1.3.4.1.1.16
SKA1-FLD-1605 SKA1_Low maximum baseline length between stations
1.3.4.1.1.16.1
SKA1-SYS_REQ- SKA1_Low maximum baseline length between stations
2817
SKA1_Low maximum baseline length between stations. The maximum distance between station centres shall be approximately 80 km
Parent Comment General
Michael Rupen
17 August 2015
I dislike requirements which are partially contained in the label/header (i.e., the
boldface bit). Suggest "The maximum distance between station centres of
SKA1_Low shall be..."
A maximum distance should not be approximate. Make this 85km or whatever,
but make it definite!
21/09/2015 7:42 am
This should be allocated to CSP as well, since CSP has to know the maximum
Page
60 of 196
delay. The maximum baseline also influences the required update rate for delay
models and the like, so this might also be allocated to SDP and TM, depending
on how calibration is to be done. [Although it's hard for me to come up with a
scheme where SDP and TM don't care about this...]
1.3.4.1.1.17
SKA1-FLD-855
SKA1_Low Instantaneous Bandwidth
1.3.4.1.1.17.1
SKA1-SYS_REQ- Instantaneous bandwidth.
2147
Instantaneous bandwidth. The SKA1_Low shall be capable of simultaneously processing 300 MHz of bandwidth.
Parent Comment General
Michael Rupen
17 August 2015
Our requirements gurus tell me that "be capable of" shall not be used in
requirements-speak, and recommend "When in X Mode, SKA1_Low shall
process 300 MHz of bandwidth per polarization"...with the caveat that one must
also define "process" at some point.
1.3.4.1.1.18
SKA1-FLD-1435 SKA1_Low separation
1.3.4.1.1.18.1
SKA1-SYS_REQ- SKA1_Low separation
2652
SKA1_Low separation. The SKA1_Low core shall be located at a minimum distance of 10km from the ASKAP core.
Parent Comment General
Michael Rupen
17 August 2015
Are "the SKA1_Low core" and "the ASKAP core" defined unambiguously
somewhere? Where?
Even if they are, the requirement must presumably be something like "the
centres of the cores must be separated by at least" or "the minimum distance
between elements of the two cores shall be at least..."
1.3.4.1.1.19
SKA1-FLD-1462 Digitisation
1.3.4.1.1.19.1
SKA1-SYS_REQ- Digitisation
2674
Digitisation. Digitisation of SKA1_antenna (SKA1_Low only) signals shall be to at least 8 bits.
Parent Comment General
Michael Rupen
17 August 2015
1.
Wording is awkward. How about "The signals from the SKA1_Low stations
shall be digitized to at least 8 bits."
2.
Brings up the question of how these L1s related to the External ICDs.
3.
"At least 8 bits" is pretty hopeless for a design. The EICD specifies this as
simply 8 bits.
4.
This must also be allocated to CSP (which has to swallow these data), and
21/09/2015 7:42 am
Page
61 of 196
maybe to SaDT (which has to move the data around).
1.3.4.1.1.2
SKA1-FLD-1461 Array resolution
1.3.4.1.1.2.1
SKA1-SYS_REQ- Array resolution (core)
2673
Array resolution (core). The SKA1_Low shall have an array resolution of better than 5 arc minutes at 100 MHz (centre of the EoR frequency range).
Parent Comment General
Wallace Turner
10 July 2015
Rev6 comment Maco Caiazzo
is the SAK1_LOW array resolution impacted by RBS?
Parent Comment General
Wallace Turner
10 July 2015
Rev6 comment Evan Keane
This is not well written. Taking it to be just the core, you get lambda/D of <=5
arcmin for D>=2km. Is this then defining the minimum core size?
I guess "The SKA1_Low shall ..." should be changed to "The core of SKA1_Low
shall ..." to make sure it is clear that it is the core only you are speaking of. In
which case, in relation to Marco's question it should not change. Resolution of
the entire array depends on the maximum baseline length (which may or may not
be different due to RBS).
Parent Comment General
Wallace Turner
10 July 2015
Rev 6 comment Tyler Bourke
Agree with Evan the wording is not clear. We need a clear glossary on
terminology for LOW re core, station, inner core, etc etc. Probably this
requirement needs some discussion, as it is not clear what it is trying to achieve
Parent Comment General
Wallace Turner
10 July 2015
Rev6 comment Mark Waterson
And the statement is not realistic either, since it conflicts with the other
prescriptions on sensitivity ans distribution (...x% of stations within a radius of...),
and imaging for calibration requires the density to fall off with radius, so there is
no hard "edge" to define as the core.
The science needs some sensitivity at some resolution, which will drive the
density distribution - this is a requirement we need to sort out soon as it will drive
the configuration.
General
Michael Rupen
17 August 2015
I agree, this should be specified as sensitivity on different angular scales or
some such, which then drives the configuration. This should be a continuous
function really, with allowed error bars. Should also specify that this requirement
applies when all antennas are working, but that gets into the incorporation of
states and modes.
Another possible approach would be to specify the sensitivity or collecting area
within the region used for the formation of tied-array beams, which is specified in
other requirements in terms of a maximum baseline.
1.3.4.1.1.20
SKA1-FLD-1425 Clipping
21/09/2015 7:42 am
Page
62 of 196
Clipping occurs when the range of the input signal voltages to the ADC is larger than the ADC voltage range.
1.3.4.1.1.20.1
SKA1-SYS_REQ- Clipping
2639
Clipping. The amplitude dynamic range of the SKA1_Low ADC's shall be such that no clipping will occur for 95% of the time
Parent Comment General
Wallace Turner
10 July 2015
Parent Comment General
Wallace Turner
10 July 2015
21/09/2015 7:42 am
Rev 6 comment Juande Santander-Vela
Should not some allocation be done to TM to verify the clipping %? And I am not
sure of why there is also allocation to SADT.
Rev 6 comment Rodrigo Olguin
Maybe allocation to CSP
Page
63 of 196
1.3.4.1.1.20.1
SKA1-SYS_REQ- Clipping
2639
Clipping. The amplitude dynamic range of the SKA1_Low ADC's shall be such that no clipping will occur for 95% of the time
General
Grant Hampson
24 July 2015
The requirement clearly states ADC's - there is not one ADC in the CSP
consortium - so this is an impossible requirement for CSP. LFAA need to control
the station gains so as to ensure the ADC's are not clipping.
CSP comment GvdM
allocated to CSP, but considered to be not applicable to CSP
This is determined by the DISH digitiser design
Parent Comment General
Wallace Turner
10 July 2015
Parent Comment General
Wallace Turner
10 July 2015
Rev6A comment Mark Waterson
should not be limited to ADCs - the availability applies to the entire chain, not any
one element
Should reference the signal chain document.
Might actually be process, since there are linearity/distortion requirements (cf
SKA1-SYS_REQ-2653) which will be a more stringent limit.
Parent Comment General
Wallace Turner
10 July 2015
Several problems with this requirement. As Mark points out, it is not a level 1
requirement. It is also problematic with respect verification due to high
dependancy on RFI environment. The linearity document (in development) will
provide alternative requirements. Suggest this requirement is deleted
Action delete requirement
General
Michael Rupen
17 August 2015
Could re-word this as "Given the input RFI levels specified in BLAH, SKA1_Low
ADCs shall not clip any frequency more than XX% of the time."
Note that it is also interesting to know the timescale of the clipping...it matters
whether we clip for a continuous 5 minutes of the day, or 1 msec every second.
If we are really aiming to make these all "real" L1s, yes, this goes away. But
make sure you've captured it at L2...
1.3.4.1.1.21
SKA1-FLD-1426 Clipped data flagging
1.3.4.1.1.21.1
SKA1-SYS_REQ- Clipped data flagging
2640
Clipped data flagging.Clipped data shall be flagged accordingly within the data stream.
1.3.4.1.1.22
SKA1-FLD-1436 Linearity
1.3.4.1.1.22.1
SKA1-SYS_REQ- Linearity
21/09/2015 7:42 am
Page
64 of 196
2653
Linearity. At the finest frequency resolution in the processing chain, the level of spurious signals due to non-linearity shall be less than the noise level when no
external input signal is present.
Parent Comment General
Michael Rupen
17 August 2015
CSP PDR OAR as discussed in TIM4:
1- In referring to "the finest frequency resolution in the processing chain", this
requirement would seem to implicate CSP, which produces the narrowest
frequency channels in that chain; but this requirement is not allocated to CSP.
2- There is some disagreement in interpretation: is this "spurious signals
_produced when no external input signal is present_" should be less than the
noise level, or "spurious signals produced in the presence of external input
signals" should be less than the noise that is seen in the absence of such input
signals (or the resulting non-linearity)?
3- Similarly the use of "noise level" is ambiguous -- is this a requirement on the
instantaneous response, or the cumulative result of a long integration? CSP's
L2s (rev C) assumes a 1000-hour integration for instance, but this is far from
obvious.
4- No external inputs is ridiculous. Must be compared with white noise or
something similar.
Parent Comment General
Michael Rupen
17 August 2015
For reference the CSP L2 requirement is: The level of spurious products
generated by the CSP correlator, in the presence of signals representative of the
expected RFI environment, shall be at most at the level of the noise for a pure
uncorrelated white noise input, corresponding to the expected thermal noise
level for up to a 1000-hour integration time, over the entire correlated bandwidth.
CSP then goes on to specify precise test cases (individual and muiltiple tones
injected, which make up a large fraction of the total power), as this is otherwise
impossible to test.
1.3.4.1.1.23
SKA1-FLD-1610 Absolute flux scale
1.3.4.1.1.23.1
SKA1-SYS_REQ- Absolute flux scale
2824
Absolute flux scale: The absolute flux scale shall be accurate to 5%
Parent Comment General
Michael Rupen
17 August 2015
21/09/2015 7:42 am
1.
In the absence of a calibration scheme I do not know how this should be
allocated, or what it means for the elements. Put another way, there are
many ways for SKA1 to meet this requirement, but the basic approach must
Page
65 of 196
be chosen at the system level, and will then flow down into the various
elements. For instance, this could entail the use of switched noise diodes
(with implications for CSP), or opacity measurements, or fast
switching...you get the idea.
1.3.4.1.1.3
SKA1-FLD-841
2.
The allocation suggests this applies only to SKA1-Low, but the actual
requirement is completely general.
3.
Suggest making this "better than 5%" -- my corporate friends tell me that,
as written, a system accurate to 3% would not meet spec. Seems
ridiculous to me but I'll pass this up for you to decide...
Electromagnetic frequency range
Note the baseline design Rev1 states the upper operating frequency as both 300 and 350 MHz. An rfp clarification confirms the figure is 350 MHz. This is corrected in
the catch-all addendum to the baseline design.
Parent Comment General
Wallace Turner
10 July 2015
Parent Comment General
Wallace Turner
10 July 2015
Parent Comment General
Wallace Turner
10 July 2015
Rev6 comment Evan Keane
And specify the lower operating freq too.
Parent Comment General
Wallace Turner
10 July 2015
comment Maria Grazia Labate
Jul 10, 2015, 8:03 AM Page 81 of 157
It would be good to have "ska1_low" mentioned in this requirement
Parent Comment General
Wallace Turner
10 July 2015
Rev 6 comment Maria Grazia Labate
The mistake in the upper frequency in the baseline design had impact on another
mistake on the bandwidth, so please, insert in the clarification that also the
bandwidth is 300MHz (instead of 250MHz).
Parent Comment General
Wallace Turner
10 July 2015
Rev 6 comment Rodrigo Olguin
Allocate to LFAA
Parent Comment General
Wallace Turner
10 July 2015
Reply to all.
This is supportive text and not a requirement. Requirement 2134 captures the
frequency range and has the allocation to LFAA.
Action amment text to:
21/09/2015 7:42 am
Rev 6 comment Martin Austin
Suggest that we state simply what we want and do not record history. Does the
[AD] for the Baseline Design capture this addendum?
Rev 6 comment Maria Grazia Labate
This correction is only captured in our website, so it is good that is captured in an
official way...if not here anyway we need to insert some official corrction..not just
in the website
Page
66 of 196
Note the baseline design Rev1, for SKA1_Low, states the upper operating
frequency as both 300 and 350 MHz. An rfp clarification confirms the figures are
50 MHz to 350 MHz (i.e a bandwidth of 300MHz). This is corrected in the catchall addendum to the baseline design
1.3.4.1.1.3.1
SKA1-SYS_REQ- Electromagnetic frequency range.
2134
Electromagnetic frequency range. SKA1_Low shall be able to measure electromagnetic radiation in a frequency range from 50 MHz to 350 MHz.
Parent Comment General
Michael Rupen
17 August 2015
Presumably this should be something like "When in an Observing Mode other
than NULL, SKA1_Low shall measure EM radiation..." . Even that is a little odd,
since we don't say what "measure" means. Perhaps "produce astronomical data
for" or some such?
1.3.4.1.1.4
SKA1-FLD-1407 Spectral stability
1.3.4.1.1.4.1
SKA1-SYS_REQ- Spectral stability
2621
Spectral stability: The spectral stability, on a time scale of 600 sec.,of the station beam bandpass, post station calibration and RFI-mitigation, shall be within 1.3 %,
0.4 %, 0.6 % and 1.1 % at 50 MHz, 100 MHz, 160 MHz, and 220 MHz respectively compared to the full polarization, parameterized beam model.
Parent Comment General
Wallace Turner
10 July 2015
SDP comment
Is this post-calibration inside the SDP ? If not, then how is this related to SDP ? If
yes, how is the calibration error budget apportioned?
Parent Comment General
Wallace Turner
10 July 2015
Gie Han:
Under investigation. Calibration scheme needs to be established
first.
Parent Comment General
Wallace Turner
10 July 2015
SDP FG:
Needs further discussion with SKAO regarding calibration scheme and error
budgets.
Parent Comment General
Wallace Turner
10 July 2015
Marco:
the comment history seems to be inappropriate for he requirements.
Hereafter some CSP comments:
Allocation required at system level.
Suggest the CSP allocation could be ~1/10th of this, to require/encourage
reasonable very fine delay tracking precision.
SKAO to perform allocation.
Parent Comment General
Wallace Turner
10 July 2015
CSP Comment
To broad. For exammple a at the south pole and observing for 24 hours the
parallatic angle changes by 360deg. There are strategies available to use to
21/09/2015 7:42 am
Page
67 of 196
achieve what is needed for a survey with significantly less PAF rotation. For
example a square FOV fall back on itself after 90 deg and an hexagonal FoV
after 60 deg. Strategies where the filed of view is allowd to change every hour at
the south pole need only 15 degrees of rotation. Suggest: "SKA1_survey
derotation. SKA1_survey shall provide PAF rotation of 30 degres (TBC). A value
of 30degrees allows consideration of square PAFs as well as circular (EBRACE
is a square PAF). For large rotation the avialbe area is circular and for a square
PAF maximum area is halved. The 30degree value means SDP must handle a
change every 2 hours for polar observation.
General
Parent Comment General
Michael Rupen
Michael Rupen
17 August 2015
17 August 2015
I am confused by the reference to Survey -- am I missing something here?
1.
Must define "spectral stability" -- is this rms, or peak-to-peak variation, or
what?
2.
Additional requirements are needed on spectral stability over faster (maybe
also slower) timescales. Easy approach would be to change this to "time
scales of 600 sec or less".
3.
A % variation seems most applicable to the amplitude. How about the
phase? Is this to be taken as X% of +/- 180 degrees?
4.
Presumably one also wants the stability to be constrained at other
frequencies, not just the ones called out here. Perhaps re-phrase this as
"Peak-to-peak variations shall be within X% in amplitude and X2 degrees in
phase from 50 to 75 MHz; Y% and Y2 degrees from 75 to 130 MHz..." etc.
5.
I find this a little confusing, in that the spectral stability is compared to the
beam model. To me that says that if the beam model is changing in crazy
ways from second to second, we have to track those variations but we're
happy if we do. Is that correct?
Parent Comment General
Michael Rupen
17 August 2015
Of course this has to be allocated to the various elements at system level, which
is an L1 task. Ideally SKAO should identify all such "allocation" issues, ask each
element what seems reasonable, and keep an up-to-date spreadsheet of the
results, as is done for power, availability, and so forth.
1.3.4.1.1.5
SKA1-FLD-842
SKA1_Low array sensitivity at 50 MHz
1.3.4.1.1.5.1
SKA1-SYS_REQ- SKA1_Low array sensitivity at 50MHz.
2135
SKA1_Low array sensitivity at 50MHz. The SKA1_Low array shall have sensitivity per polarization at zenith greater than 72 m2K-1 at 50MHz when assuming a
sky noise temperature following the law 60.lamda2.55
Parent Comment General
21/09/2015 7:42 am
Michael Rupen
17 August 2015
For this and subsequent requirements: need another requirement to ensure the
Page
68 of 196
sensitivity is smoothly varying over the frequency ranges that are not explicitly
called out.
Why is the sensitivity split into separate requirements as a function of frequency,
while the spectral stability is not?
What are the units of the sky noise temperature we're supposed to assume? I
presume kelvins but it's sloppy not to say so. Similarly what are the units for
lambda in this expression?
Even more nit-picky, should consistently use either lamda or lambda. I've
usually seen the latter.
1.3.4.1.1.6
SKA1-FLD-843
SKA1_Low array sensitivity at 100 MHz
1.3.4.1.1.6.1
SKA1-SYS_REQ- SKA1_Low array sensitivity at 110MHz.
2136
SKA1_Low array sensitivity at 110MHz. The SKA1_Low array shall have a sensitivity per polarization at zenith greater than 380 m2K-1 at 100 MHz when assuming
a sky noise temperature following the law 60.lambda^2.55
1.3.4.1.1.7
SKA1-FLD-844
SKA1_Low array sensitivity at 160 MHz
1.3.4.1.1.7.1
SKA1-SYS_REQ- SKA1_Low array sensitivity at 160MHz.
2137
SKA1_Low array sensitivity at 160MHz. The SKA1_Low array shall have a sensitivity per polarization at zenith of greater than 535 m2K-1 at 160 MHz when
assuming a sky noise temperature following the law 60.lambda^2.55
1.3.4.1.1.8
SKA1-FLD-845
SKA1_Low array sensitivity at 220 MHz
1.3.4.1.1.8.1
SKA1-SYS_REQ- SKA1_Low array sensitivity at 220MHz.
2138
SKA1_Low array sensitivity at 220MHz. The SKA1_Low array shall have a sensitivity per polarization at zenith of greater than 530 m2K-1 at 220 MHz when
assuming a sky noise temperature following the law 60.lambda^2.55.
21/09/2015 7:42 am
Page
69 of 196
1.3.4.1.1.9
SKA1-FLD-1603 SKA1_Low array sensitivity at 280MHz.
1.3.4.1.1.9.1
SKA1-SYS_REQ- SKA1_Low array sensitivity at 280MHz.
2814
SKA1_Low array sensitivity per polarization at 280 MHz. The SKA1_Low array shall have a sensitivity per polarization at zenith greater than 500 m^2/K at 280
MHz when assuming a sky noise temperature following the law 60.lambda^2.55
1.3.4.1.2
SKA1-FLD-1406 SKA1_Low station beamforming
21/09/2015 7:42 am
Page
70 of 196
1.3.4.1.2.1
SKA1-FLD-1464 Dynamic range
1.3.4.1.2.1.1
SKA1-SYS_REQ- Dynamic range
2676
Dynamic range. The SKA1_Low beams shall have a dynamic range of better than 40 dB
Parent Comment General
Wallace Turner
10 July 2015
Parent Comment General
Wallace Turner
10 July 2015
Parent Comment General
Michael Rupen
17 August 2015
Rev6A comment Juande Santander-Vela
Should this Signal Chain performance document be an Applicable Document to
be added?
Rev6A comment
This requirement should specify whether the 40dB value is after final calibration
(vs at each/any stage), as well as that this is at the fine-channel bandwidth (and
what happens in zoom mode)
I think the signal chain does need to be added, and referenced in several other
requirements.
Must define "dynamic range" for a station beam. Is this the ratio of the peak
response to the rms of the distant sidelobes, or what? Note that experts
disagree even on the dynamic range of a simple image!
Please change this to "The SKA1_Low STATION beams shall..." There are a lot
of beams floating around for an interferometer (dirty beam, CLEAN beam, delay
beam, ...) and it's best to be very clear.
1.3.4.1.2.2
SKA1-FLD-854
SKA1_Low station beams
1.3.4.1.2.2.1
SKA1-SYS_REQ- SKA1_Low station beams.
2146
SKA1_Low station beams The antennas within each station shall be coherently beam-formed to provide one pair of station beams, one beam for each orthogonal
polarization, for primary science.
Parent Comment General
Michael Rupen
17 August 2015
What the heck is "primary science"??
Shouldn't this requirement be something like "SKA1_Low shall coherently form
one pair of orthogonally-polarized station beams from the antennas making up
each station" or some such?
Parent Comment General
21/09/2015 7:42 am
Michael Rupen
18 August 2015
This seems in conflict with 3039, which says we'll "process up to 8 independent
station beams". Also, while 3039 is very explicit about the bandwidth (BW *
Nbeams <= 300 MHz), 2146 does not give a required bandwidth. Perhaps it
Page
71 of 196
would be easiest simply to combine these two requirements, so that a single
beam is simply a special case of the general requirement.
1.3.4.1.2.3
SKA1-FLD-1576 Control of station beam properties
1.3.4.1.2.3.1
SKA1-SYS_REQ- Control of station beam properties
2779
Control of station beam properties: It shall be possible to control specific properties of the station beam by setting the station beam weights appropriately.
Parent Comment General
Wallace Turner
10 July 2015
Rev6A comment Juande Santander-Vela
Who is preparing this document? AG? In any case, this document should be
added to the Applicable Documents.
Parent Comment General
Wallace Turner
10 July 2015
Rev6A comment Mark Waterson
No idea which doc this would be- however this requirement is either not specific
enough (if the objective is an explicit, arbitrary control interface) or else is part of
process, since achieving any of the other beam-related performance
requirements requires control of station beam parameters.
Parent Comment General
Michael Rupen
17 August 2015
As Wallace says, this is a terrible requirement in its current form. The
requirement should be that one can flexibly set the weights of the antennas
going into each station beam, with a certain accuracy/granularity, on a certain
timescale (e.g., be able to change these every N seconds).
Parent Comment General
Michael Rupen
18 August 2015
Should be re-worded in light of the multiple-beam requirement (2146): "...to
control specific properties of EACH station beam INDEPENDENTLY...".
1.3.4.1.2.4
SKA1-FLD-1415 Station beam stability
1.3.4.1.2.4.1
SKA1-SYS_REQ- Station beam stability
2629
Station beam stability. The difference between the parameterized station beam model and the actual station beam shall remain smaller than 1.3 %, 0.4 %, 0.6 %
and 1.1 % relative to the main beam peak power, after calibration, at 50 MHz, 100 MHz, 160 MHZ and 220 MHz respectively
Parent Comment General
Wallace Turner
10 July 2015
Parent Comment General
Wallace Turner
10 July 2015
Parent Comment General
Wallace Turner
10 July 2015
21/09/2015 7:42 am
SDP comment
Given that this stability is defined over the calibration period, this would imply
that this requirement must be met without calibration and hence not involve the
SDP.
GHT
Under investigation.
SDP FG
Needs further discussion with SKAO regarding calibration scheme and error
budgets
Page
72 of 196
Parent Comment General
Parent Comment General
1.3.4.1.2.5
Michael Rupen
Michael Rupen
17 August 2015
18 August 2015
Need a requirement on the intervening frequencies -- suggest smaller than 1.3%
between 50 and 75 MHz, 0.4% between 75 amd 13- MHz, etc.
How is this difference to be calculated? Are we talking about the maximum
difference over the entire beam? If so perhaps make this "The maximum
difference at any point between..."; or maybe say "The maximum difference
anywhere on the sky..." or some such.
Should be re-worded in light of the multiple-beam requirement (2146): "For each
station beam, the difference between the parameterized model and the actual
station beam...". This may not strictly be necessary but it's a little clearer, which
seems a Good Thing.
SKA1-FLD-1420 Calibration update rate
1.3.4.1.2.5.1
SKA1-SYS_REQ- Calibration update rate
2634
Calibration update rate. Calibration measurements shall be necessary at a rate of no more than 10seconds.
Parent Comment General
Michael Rupen
18 August 2015
1.
10 seconds is not a rate. Should say "No calibration measurements shall
be necessary more often than once every 10 seconds" (or you could say no
faster than 0.1 Hz).
2.
As worded, this is a completely generic requirement, yet it lives under
"SKA1_Low station beamforming" in the document. Is the requirement
intended only to apply to calibration necessary for SKA1_Low station
beamforming? If so this should be made explicit; if not, the requirement
should be moved to another, more prominent section.
3.
4.
5.
6.
21/09/2015 7:42 am
Does this rule out (e.g.) a switched noise diode with a period shorter than
10 seconds?
Would be nice to know what a "calibration measurement" is in this context.
Does this really mean, metadata communicated between elements, or
some such?
This should presumably be allocated to all elements which make or receive
calibration measurements. If calibration measurements include
measurements of digital power (for re-quantization), state counts, noise
diode measurements, and the like, then CSP must be involved. If they
include noise tube or tone insertion, DSH is a player. SaDT of course has
to transmit the information so they may care as well. Etc.
I'd have to think a bit to see how fast-changing RFI might affect this. If data
valid counts, used for scaling the data, count as a calibration measurement,
this may be dicey.
Page
73 of 196
1.3.4.1.2.6
SKA1-FLD-1421 Real time calibration
1.3.4.1.2.6.1
SKA1-SYS_REQ- Real time calibration
2635
Real-time calibration. The LFAA reception system at station level shall provide on-line instrumental calibration functions with an update rate of 10 minutes
Parent Comment General
Wallace Turner
10 July 2015
Parent Comment General
Wallace Turner
10 July 2015
Parent Comment General
Michael Rupen
18 August 2015
Rev6 comment Roshene McCool
I do not understand what this means. The term LFAA reception system is
ambiguous it would be better to apply the requirement on a station granularity.
Can we clarify?
Rev6 comment Juande Santander-Vela
What kind of calibration can be performed by the LFAA itself without need of
SDP and TM? Or is this a requirement on calibration stability of certain parts of
the LFAA element?
1.
2.
1.3.4.1.2.7
SKA1-FLD-1422 Beam products
1.3.4.1.2.7.1
SKA1-SYS_REQ- Beam products
2636
10 minutes is not a rate. Should be "...functions updated at least every 10
minutes" or some such.
Again one has to define the terms used. "LFAA reception system" is not
obvious; "on-line instrumental calibration functions" is even worse. This
requirement is very difficult to understand -- basically you're relying on the
domain knowledge of the LFAA folks, which is fine, but then why do we
have requirements?
Beam products. The SKA1_Low shall be capable of outputting beam products as voltage time series.
Parent Comment General
Wallace Turner
10 July 2015
Parent Comment General
Wallace Turner
10 July 2015
Parent Comment General
Michael Rupen
18 August 2015
21/09/2015 7:42 am
Rev 6 comment Juande Santander-Vela
For this requirement to be useful, is there need to indicate the time resolution
required?
Reply to Juande
This, as it stands, is not a L1 requirement. However, a closely related
requirement is transient capture where the Low telescope will output voltage time
series data products.
Action delete requirement and deal with transient capture seperately.
What is a "beam product"??? Presumably this is actually the station beams
discussed in 2146, and the same name should be used: The SKA1_Low shall
produce station beams as voltage time series." This could also simply be
merged with 2146, which would be clearer I think.
Page
74 of 196
Requirements folks seem not to like "shall be capable of". Should ideally say
something like "When in XXX, YYY, or ZZZ observing mode, SKA1_Low shall..."
1.3.4.1.2.8
SKA1-FLD-1826 Multi-beam capability
1.3.4.1.2.8.1
SKA1-SYS_REQ- SKA1_Low Multiple beam capability
3039
SKA1_Low Multiple beam capability. The SKA1_Low telescope shall process up to 8 independent station beams constrained to a product of bandwidth and number
of beams that is less than or equal to 300MHz.
Parent Comment Proposed Change Ewan Barr
15 July 2015
General
Michael Rupen
18 August 2015
Parent Comment General
Michael Rupen
18 August 2015
1.3.4.1.2.8.2
SKA1_Low Multiple station-beam capability. The SKA1_Low telescope shall
process up to 8 independent station beams constrained to a product of
bandwidth and number of beams that is less than or equal to 300MHz.
Suggest retitling the requirements to specifically identify these beams as being
related to stations not to the full array. This pulls this requirement in line with
those that follow it.
Not sure I understand this suggestion...e.g., the title for the next requirement
(3040) is exactly parallel to the current title.
1.
3041 requires that one set the bandwidth independently for each beam; in
this case a restriction on the "product of BW and number of station beams"
makes no sense, because each station beam can have a different BW.
2.
Should be clear that this is 8 independent station beams per subarray.
3.
Consider grouping 3039, 3040, 3041: SKA1_Low shall process up to 8
independent station beams per subarray, each formed independently and
potentially pointing towards different locations, with the (contiguous)
bandwidth for each beam selectable independently, with some granularity,
such that the sum of bandwidths over all beams for a given subarray is at
most 300 MHz. The independence of bandwidth per beam shall allow
identical, overlapping or non-overlapping frequency coverage for each
station beam.
SKA1-SYS_REQ- SKA1_Low multiple beam steering
3040
SKA1_Low multiple station-beam steering. SKA1_Low, when forming multiple station-beams, shall steer them independently in both azimuth and elevation.
1.3.4.1.2.8.3
SKA1-SYS_REQ- SKA1_Low multiiple beam frequency channels
3041
21/09/2015 7:42 am
Page
75 of 196
SKA1_Low multiple beam frequency channels. SKA1_Low, when commanded, shall form multiple beams that have bandwidths independent of each other (where
independence allows identical, overlapping or non-overlapping)
Parent Comment Proposed Change Ewan Barr
15 July 2015
Parent Comment General
Michael Rupen
18 August 2015
1.3.4.1.3
SKA1-FLD-849
SKA1_Low Correlation
1.3.4.1.3.1
SKA1-FLD-1872 Auto-correlation spectra
1.3.4.1.3.1.1
SKA1-SYS_REQ- SKA1_Low Autocorrelation spectra
3035
SKA1_Low multiple station-beam frequency channels. SKA1_Low, when
commanded, shall form multiple station beams that have bandwidths
independent of each other (where independence allows identical, overlapping or
non-overlapping)
Note also a mistake "multiiple" in current title.
Somewhere we need to state the channelization required for each station beam.
In CSP we have an L2:
When processing multiple station beams in a subarray, the frequency coverage
of each station beam shall be contiguous. SKA1_Low shall provide the same
spectral resolution, spectral response, etc. as when operating with a single
station beam.
The intent is that the total number of spectral channels provided, summed over
all bands, is constant -- if you normally get 64k channels over 300 MHz, a station
beam with a 30 MHz band will get 64k/10 channels. Note also the requirement
here that the frequency range for a given station beam must be contiguous -- if
this is true, it should be stated explicitly in the requirement.
SKA1_Low Autocorrelation spectra. SKA1-Low, when commanded, shall generate autocorrelation spectra from any subset of individual stations within any given
subarray.
Parent Comment General
21/09/2015 7:42 am
Michael Rupen
18 August 2015
Need to specify the characteristics of the autocorrelation spectra. Suggested rewording:
For each subarray with Observing Mode other than IDLE, SKA1_Low shall
deliver full polarization autocorrelation spectra, with characteristics matching
those of the cross-correlation spectra, from any subset of individual stations
within that subarray.
This still needs some work -- intent is that the autos match the CURRENT crosscorr'ns in frequency coverage and channelization, i.e., you don't get to do autos
like wideband imaging mode while doing crosses in spectral zoom mode. Also
Page
76 of 196
we shouldn't have "etc." in a requirement ;)
Do we also need an explicit reference to multiple station beams here? I.e., "for
every station beam..." or some such? I've gone back and forth on that,
concluding that matching the cross-correlation spectra is sufficient.
1.3.4.1.3.1.2
SKA1-SYS_REQ- SKA1_Low autocorrelation calibration
3047
SKA1_Low autocorrelation calibration. The SKA1_Low shall use crosscorrelation spectra to calibrate autocorrelation spectra
Parent Comment General
1.3.4.1.3.1.3
Michael Rupen
18 August 2015
If auto-correlations are to be used scientifically, there should be many more
requirements here -- e.g., bandpass stability, ability to perform long integrations,
etc.
SKA1-SYS_REQ- SKA1_Low Continuum Imaging.
3037
SKA1_Low Continuum Imaging. SKA1_Low, when commanded, shall provide full Stokes polarisation products (I, Q, U, V) as part of Continuum Imaging.
Parent Comment General
Michael Rupen
18 August 2015
This should apply to ALL observing modes, not just Continuum Imaging (e.g.,
spectral line, zoom).
Parent Comment General
John Bunton
31 August 2015
Presume this is for the low images and data output to astronomers from SDP. Is
not a requirement on LOW.CBF which will generate x1x2*, y1y2*,x1y2* and
y1x2*
1.3.4.1.3.2
SKA1-FLD-856
SKA1_Low channelisation
1.3.4.1.3.2.1
SKA1-SYS_REQ- SKA1_Low channelisation transition band for adacent frequency channels.
2149
SKA1_Low channelisation transition band for adjacent frequency channels. SKA1_Low, in zoom mode, shall have a transition band for adjacent frequency
channels that is monotonically decreasing from -3 dB at the channel edge, to -60 dB at the next adjacent channel centre frequency.
Parent Comment Proposed Change Michael Rupen
1.3.4.1.3.2.2
18 August 2015
Remove reference to zoom mode -- this should apply to all modes.
SKA1-SYS_REQ- SKA1_Low channeliser maximum leakage for non-adjacent frequency channels
2810
SKA1_Low channeliser maximum leakage power for non-adjacent frequency channels. The maximum noise leakage power for SKA1_Low shall be less than
60dB for non-adjacent frequency channels.
Parent Comment General
21/09/2015 7:42 am
Wallace Turner
10 July 2015
SKA1_Mid maximum leakage power for non-adjacent frequency channels. The
SKA1_Mid, for each sub-array, shall have a maximum noise leakage power from
non-adjacent frequency channels better than -60 dB.
Page
77 of 196
And is now:
SKA1_Mid maximum leakage power for non-adjacent frequency channels. The
maximum noise leakage power for SKA1_Mid shall be less than 60 dB for nonadjacent zoom channels.
Losing the reference to sub-arrays is a Good Thing. But:
The rationale says this should apply to both zoom and non-zoom channels, but
“zoom” is in here explicitly!
“Less than 60dB” makes Brent think you don’t care about leakage unless you
amplify the leaking signal by more than 1e6 (!). “Better than -60dB” makes much
more sense, and is consistent with 2196.
Parent Comment General
Michael Rupen
18 August 2015
So I’m assuming you actuall want something like:
SKA1_Mid maximum leakage power for non-adjacent frequency channels. The
maximum noise leakage power for SKA1_Mid shall be better than -60 dB for
non-adjacent fine frequency channels.
Suggest:
For each subarray, SKA1_Low shall have a maximum noise leakage power from
non adjacent frequency channels better than -60 dB.
But this too has issues -- the CSP L2 comments are as follows:
1.
2.
3.
Parent Comment General
1.3.4.1.3.2.3
John Bunton
31 August 2015
This needs to be clarified if it is the leakage from each channel or the sum
of all. Break into two requirements? If sum of all then it needs to be a
different number. Should use white noise case? The spec point really
drives the noise floor up.
This may require an RFI inter-mod products requirement.
This should not be wrt "noise"...just leakage power. -60dB needs to be revisited with Peter's document.
Unclear at the moment. Is it that the channel response (non adjacent) is -60db,
which is easy to determine. This means all isolated interferers a reduced by
60dB
Or as Michael put in white noise measure power (P1). Null out channel and
adjacent channels and measure power (P2). Then P2/P1 is -60dB. This is much
more stringent, but still calculable from the channel response. But on average a
1,000 channel filterbank has a response that is 30dB better than case 1. For
cascaded filterbank how to allocate between LFAA and CSP.
SKA1-SYS_REQ- SKA1_Low channeliser frequency channel amplitude variation
2811
21/09/2015 7:42 am
Page
78 of 196
SKA1_Low frequency channel amplitude variation. While in zoom mode the total amplitude response variation as a function of frequency for SKA1_Low shall be
within + 0.01 dB of the nominal.
Parent Comment General
Michael Rupen
18 August 2015
1.
2.
3.
4.
5.
6.
7.
Parent Comment General
1.3.4.1.3.2.4
John Bunton
31 August 2015
I believe this should apply only to the visibility spectra, not to the beamformed channels.
Should specify "FINE frequency channels", as in the next requirement
(2812).
Should say this is post-calibration (right?).
Within CSP we are interpreting this as a requirement that the power
measured from a single tone should remain constant as the tone is swept
across spectral channels, even when the tone lies at a channel boundary.
Should this also be allocated to LFAA? ADCs and station beam forming
could potentially make this difficult.
Needs a system-level allocation.
"Nominal" is a bit vague...I was wondering whether this applied only at the
center of the beam, for instance, but that got me wondering whether
"nominal" meant "including expected off-axis problems due to changing
beam response with frequency, pointing errors, etc.". Would be nice to
clarify this...as it stands it sounds like a motherhood statement, leaving it to
the elements to do their best.
If this truly is just for zoom mode then can the 0.01dB be relative to "normal"
observing?
0.01dB is tough using the definition Michael is given.
I think what is "nominal" needs spelling out
SKA1-SYS_REQ- SKA1_Low fine frequency channel band edge
2812
SKA1_Low fine frequency channel band edge. The fine frequency channels for the SKA1_Low shall have a -3dB transition band amplitude at the channel band
edge.
Parent Comment General
Parent Comment General
Ewan Barr
Michael Rupen
15 July 2015
18 August 2015
Parent Comment General
John Bunton
31 August 2015
1.3.4.1.3.2.5
SKA1-FLD-1871 Full bandwidth resolution
1.3.4.1.3.2.5.1
The -3 dB here needs a tolerance. I think +-0.1 dB is the current L2 assumption.
Must define the channel band edge -- suggest:
The channel band edge is defined as the mid-point beween channel centre
frequencies.
Req-2811 means the tolerance is 0.01dB
SKA1-SYS_REQ- SKA1_Low spectral channels
2148
21/09/2015 7:42 am
Page
79 of 196
SKA1_Low spectral channels. The SKA1_Low shall provide up to 65,536 + 20% linearly spaced frequency channels across the available frequency range.
Parent Comment General
Wallace Turner
10 July 2015
Parent Comment General
Wallace Turner
10 July 2015
General
Michael Rupen
18 August 2015
CSP comment
Exact channelization requirement is very difficult to meet. Suggest leaving some
leeway in this. Also number of channels does not really capture the science -spectral resolution is the fundamental requirement. B2 wording from CSP is
currently: "CSP_Low shall produce linearly spaced channels, providing a spectral
channel resolution of 1 kHz +/-20% across the processed bandwidth."
Reply to comments
The requirement title and wording needs to change to bring this in line with L1.
This also includes a trade off space in frequency to allow over sampling earlier in
the frequency chain.
Action update requirement to:
Jul 10, 2015, 8:03 AM Page 88 of 157
When operating across the full instantaneous bandwidth, spectral data products
of the SKA1_Low telescope shall have a highest frequency resolution of between
3.6 kHz to 5.6 kHz configurable to lower frequency resolutions in powers of
two(need confirmation of the powers of 2)
Interesting change proposal...I don't think you need (or want) the business about
"When operating across the full instantaneous BW", since multiple station beams
makes that problematic. Maybe "when observing mode is Continuum or Spectral
Line" (have to check the TM doc to see how to exclude spectral zoom) "the
SKA1_Low telescope..."
Note that the proposed revision corresponds to 65,536+27%, -18% channels, so
it's not quite the same as the current one.
Parent Comment Proposed Change Michael Rupen
18 August 2015
Parent Comment General
31 August 2015
1.3.4.1.3.2.6
The parent requirement SYS_REQ-2727 is a little odd, if this means SKA1SYS_REQ-2127 -- that requirement talks about subarrays, not channelization.
SKA1-FLD-1825 Higher Spectral Resolution over limited bandwidth
21/09/2015 7:42 am
Michael Rupen
The introduction of some leeway into these exact numbers is most welcome, but
leads to the need for an additional requirement that the channelization and
frequency response of the telescope not change over time. This is remarkably
hard to state as a requirement -- so far the best I've got is:
SKA1_Low Channelization Stability. The spectral and temporal response of
the individual SKA1_Low spectral channels shall not change in any measurable
way unless explicitly commanded to do so.
The "explicitly commanded" part is needed for zoom mode of course, but also for
application of delay models and the like.
Page
80 of 196
1.3.4.1.3.2.6.1
SKA1-SYS_REQ- SKA1_Low zoom windows.
2975
SKA1_Low zoom windows. SKA1_Low, when commanded, shall provide up to four zoom windows, each with contiguous bandwidth selected from the following
values: 4MHz, 8MHz, 16 MHz or 32MHz
Parent Comment General
Michael Rupen
18 August 2015
CSP would like zoom windows to be in units of the LFAA coarse channelizer
(e.g., if 790 kHz coarse channels, approximate 4 MHz as 5*790 kHz= 3.950
MHz). CSP suggested wording for a combined 2975, 2976, 2977 requirement:
For each subarray in zoom mode, SKA1_Low shall produce correlated
visibilities and autocorrelations for all polarization products, for up to four zoom
windows, each with bandwidth selected independently from values within 10% of
4 MHz, 8 MHz, 16 MHz, and 32 MHz; each independently tuned, with frequency
granularity better than 1.1 MHz, such that the entire zoom window lies within
anywhere within the subarray's digitized observing band; and each with at least
16384 linearly spaced frequency channels fully covering the zoom window
bandwidth.
Parent Comment General
John Bunton
31 August 2015
Agree needs to be in terms of coarse channel. Then the "1MHz" data will be in
terms of coarse channels. Anything that crosses coarse channel boundries
really complicates the design.
1.3.4.1.3.2.6.2
SKA1-SYS_REQ- SKA1_Low zoom window centre frequency
2976
SKA1_Low zoom window centre frequency. In Imaging zoom mode, zoom windows for SKA1_Low shall have centre frequencies independently selectable from
each other with a step size of 1MHz such that the full window is contained within the available frequency band.
Parent Comment General
Michael Rupen
18 August 2015
See 2975.
1.
Parent Comment General
1.3.4.1.3.2.6.3
John Bunton
31 August 2015
CSP would like the tuning granularity to be in units of the coarse channel
BW, so suggest changing this to an upper limit on the acceptable
granularity --suggest <= 1.1 MHz.
2.
Need to state that zoom windows must lie entirely within the digitized band
(which may be different for every station beam).
Suggest the step size in equal the coarse channel separation currently 781kHz
for low
SKA1-SYS_REQ- SKA1_Low zoom window channels.
2977
SKA1_Low Zoom window channels. Each zoom window for SKA1_Low shall provide 16384 equally spaced frequency channels across that zoom window's
bandwidth
Parent Comment General
21/09/2015 7:42 am
Michael Rupen
18 August 2015
See 2975.
Page
81 of 196
Parent Comment General
1.3.4.1.3.2.6.4
John Bunton
31 August 2015
Exact channelization numbers are overly restrictive on the design -- suggest
making this "at least 16384 channels", or giving a range of number of channels
or channel spacing (cf. 2148).
Exact number too restrictive. IF low oversample at 32/27 we have 3456 "4MHz"
zoom channels per coarse and 17,280 in five coarse channels (3.9MHz). So at
least 16384 is a good start. The no of channel leeway should be the same as
"normal" mod +-20%
SKA1-SYS_REQ- SKA1_Low continuum in zoom mode.
2978
SKA1_Low continuum in zoom mode. SKA1_Low shall simultaneously generate a continuous continuum spectrum across the entire frequency band with an evenly
spaced frequency resolution of 1MHz
Parent Comment Proposed Change Michael Rupen
18 August 2015
Parent Comment General
31 August 2015
John Bunton
1.
Entire frequency band is not available when producing more than one
station beam.
2.
"Evenly spaced frequency resolution" stands in contrast to other
channelization requirements, which are phrased in terms of equally spaced
frequency channels (e.g., 2977). Is this difference significant? If so,
frequency resolution has to be defined (e.g., FWHM of frequency
response).
3.
Exactly 1 MHz is overly restrictive. Suggest +/-10% here.
This should only be for bandwidth not implementing zoom modes. In the worst
case 128MHz of zoom bands and 300MHz of 1MHz = 328MHz. LOW.CBF will
implement on the "unzoomed" bandwidth. 1MHz on the rest absolutely needs to
be done by SDP, ie SDP sums the data in zoom bands to "1MHz"
Also must have these as coarse channels (currently 781kHz for low (-22%)).
Implementing a "1MHz" across coarse channels really complicates the
processing especially as the amount in each adjacent coarse channel continually
changes.
1.3.4.1.3.2.6.5
Suggest the SDP processing load is not heavy for 1MHz continuum and they can
allow significant headroom.
SKA1-SYS_REQ- SKA1_Low zoom window noise leakage power
3048
SKA1_Low zoom window noise leakage power. The maximum noise leakage into SKA1_Low zoom window channels from other frequencies outside the
window shall be less than 60dB
Parent Comment General
John Bunton
31 August 2015
Comment as per "normal" mode
1.3.4.1.3.2.6.6 SKA1-SYS_REQ- SKA1_Low Overlapped window amplitude response
3049
21/09/2015 7:42 am
Page
82 of 196
SKA1_Low Overlapped window amplitude response. The amplitude response variation across the full concatenated bandwidth of overlapped zoom windows of
the same frequency resolution shall be within + 0.01 dB of the nominal.
Parent Comment General
Michael Rupen
18 August 2015
1.3.4.1.3.3
SKA1-FLD-1466 SKA1_Low Correlator signal to noise
1.3.4.1.3.3.1
SKA1-SYS_REQ- SKA1_Low correlation signal to noise
2678
See comments on 2811.
SKA1_Low correlatation signal to noise. SKA1_Low correlation shall not degrade the Signal to Noise ratio by more than 2 % compared to ideal analogue
correlation.
Parent Comment General
Michael Rupen
1.3.4.1.3.4
SKA1_Low correlator integration time
SKA1-FLD-858
31 August 2015
The purported parent SKA1-SYS_REQ-2127 discusses subarrays. Is
SYS_REQ-2127 something different?
The correlator dump time is derived from the level of acceptable image smearing. This is nominally identified as < 2% in the base line design. However this isn't
sufficient information as the field of view this is applicable to needs to be specified. The baseline designs a factor of 2 over and above the half power beam width
though this isn't explicitly stated.
The base line design suggests two separate ranges of baselines with associated dump rates. This is problematic for Imaging processing and not included in the SKA1
requirements
1.3.4.1.3.4.1
SKA1-SYS_REQ- SKA1_Low correlator Integration rate.
2150
SKA1_Low correlator Integration rate. The SKA1_Low correlator shall have visibility integration periods independently configurable for each subarray in the range
9s to 0.9s.
Parent Comment General
Wallace Turner
10 July 2015
Parent Comment General
Wallace Turner
10 July 2015
Parent Comment General
Wallace Turner
10 July 2015
Rev 6 comment Tyler Bourke
0.6s is already correct for 65 km baselines, the original numbers for 100 km may
be in error (Peter and I should check). So decreasing to 0.9s should not be
implemented just yet.
Parent Comment General
Wallace Turner
10 July 2015
Rev6 comment Wallace Turner
Reply to Tyler: In summary of our conversation, the updated integration rates are
21/09/2015 7:42 am
Rev6 comment Evan Keane
This makes sense for same sensitivity but maybe check with SDP?
Rev6 comment Marco Caiazzo
could you please call out the relationship with the time smearing.
Page
83 of 196
all right to publish for the rbs update. However the comment is to be retained so
that a more detailed analysis can be provided at a later date such hat ever one is
in agreement with with the assumptions.
It is also assumed that baseline averaging is not necessary with the reduced
channel count.
Parent Comment General
Wallace Turner
10 July 2015
Rev6 comment Mark Waterson
criteria for choosing (or not choosing) integration times need to be propagated
into the TM models too.
Parent Comment General
Wallace Turner
10 July 2015
Reply to comments
Suggest updating wording to:
The SKA1_Low telescope shall have a minimum visibility integration period of
0.9s individually configurable to longer periods in powers of two up to a factor of
16 for each sub-array.
General
Michael Rupen
18 August 2015
Suggest:
The minimum visibility integration period for each SKA1_Low subarray shall be
independently configurable, with allowed values of {1, 2, 4, 8, 16} times 0.9
seconds.
Personally I would make this any integer up to, say, 40 times 0.9 seconds. I see
no reason for powers-of-2 here, and note that EVLA observers frequently "tune"
their integration time to match expected weather conditions and data rate limits.
Note that, if we are not archiving visibilities, this is not really an L1 requirement -the integration time is purely an internal matter, set by requirements on fidelity
(which don't yet exist), astrometry (ditto), and the like.
Parent Comment General
1.3.4.1.4
John Bunton
31 August 2015
Would like to keep 9s as maximum
Suggest an integer N multiple of 0.9s where N is in the range 1 to 10 inclusive.
SKA1-FLD-1832 SKA1_Low Pulsar Search
21/09/2015 7:42 am
Page
84 of 196
1.3.4.1.4.1
SKA1-FLD-1840 Pulsar search processing bandwidth
1.3.4.1.4.1.1
SKA1-SYS_REQ- SKA1_Low Pulsar search bandwidth
2890
SKA1_Low Pulsar Search bandwidth. SKA1_Low, shall have a maximum Pulsar Search bandwidth of no less than 96 MHz.
Parent Comment Proposed Change Michael Rupen
18 August 2015
1.3.4.1.4.10
SKA1-FLD-1849 Pulsar search beamformer bandwidth
1.3.4.1.4.10.1
Eliminate the comma after "CSP_Low".
SKA1-SYS_REQ- SKA1_Low Pulsar search beams and bandwidth
2892
SKA1_Low Pulsar search beams and bandwidth. The SKA1_Low, when commanded, shall offset the centre frequency of the Pulsar Search of operator specified
beams by an operator specified multiple of the Pulsar Search bandwidth, provided that the entire frequency range lies within the current SKA1_Low band.
Parent Comment Proposed Change Michael Rupen
1.3.4.1.4.11
18 August 2015
Proposed re-wording:
SKA1_Low, when commanded by the operator, shall offset the center frequency
of the Pulsar Search for operator-specified beams by an operator-specified
multiple of the Pulsar Search bandwidth, provided that the entire frequency
range lies within the SKA1_Low digitized band.
Note "digitized band" -- current requirement has "current SKA1_Low band", but
there is only one such band, so I'm assuming we're considering multiple station
beams here.
SKA1-FLD-1850 Number of beams Pulsar survey
Parent Comment Question
Michael Rupen
18 August 2015
What is "pulsar survey"? Is this a mistake for "pulsar search"?
1.3.4.1.4.11.1
SKA1-SYS_REQ- Number of beams: SKA1_Low Pulsar Search
2894
Number of beams: SKA1_Low Pulsar search. SKA1_Low, shall concurrently perform the Pulsar Search on a total of up to 500 independently steerable beams
across all subarrays.
Parent Comment Proposed Change Michael Rupen
21/09/2015 7:42 am
18 August 2015
Poorly written. Suggest:
SKA1_Low shall concurrently perform the pulsar search function in a total of up
to 500 independently steerable beams, each of which may be assigned to any
subarray which is in the pulsar search mode.
Again we need some convention for "pulsar search function." We don't just say
"pulsar search" because we also search for transients, I assume. I wonder
whether we can move entirely to the use of modes -- when in pulsar search
mode SKA1_Low shall do XXX; when in pulsar search mode SKA1_Low shall
concurrrently search up to 500 beams...
Page
85 of 196
1.3.4.1.4.12
SKA1-FLD-1851 Beamformer S/N Pulsar survey
Parent Comment General
1.3.4.1.4.12.1
Michael Rupen
18 August 2015
What is "pulsar survey" (and why is it mixed case)? Should this be "pulsar
search"?
SKA1-SYS_REQ- SKA1_Low Beamformer S/N pulsar search
2896
SKA1_Low Beamformer S/N pulsar search. The SKA1_Low, when forming beams for the Pulsar Search, shall not degrade the signal-to-noise to less than 98%
when compared to an ideal analogue beam-former.
Parent Comment Proposed Change Michael Rupen
18 August 2015
I'd prefer "when forming pulsar search beams...".
If the 98% is intended to include coherence losses due to poor calibration and
SNR losses due to incorrect antenna weights, this should also be allocated to
TM and SDP. If this is not the intent, this requirement should be re-phrased:
The SKA1_Low, when forming pulsar search beams, shall not degrade the
signal-to-noise to less than 98% of that achievable by an ideal analogue beamformer, given the same digitized inputs and calibration.
Of course this would really be an L2 requirement.
Also in this case, where are the requirements on the accuracy of such
calibration/weighting?
1.3.4.1.4.13
SKA1-FLD-1852 Pulsar search output
1.3.4.1.4.13.1
SKA1-SYS_REQ- SKA1_Low Pulsar Search output
2898
SKA1_Low Pulsar search output. SKA1_Low, when performing the Pulsar Search, shall output Pulsar Candidates and Non-imaging Transient Candidates as
defined in TBD.
Parent Comment Proposed Change Michael Rupen
1.3.4.1.4.14
18 August 2015
Again we need some convention for "performing the Pulsar Search". How about
When in pulsar search mode, the SKA1_Low shall report...
(I also really hate to use "output" as a verb ;)
SKA1-FLD-1853 Pulsar search number of channels
Parent Comment Proposed Change Michael Rupen
21/09/2015 7:42 am
18 August 2015
Should be:
Pulsar search: number of channels
(note the colon)
Page
86 of 196
1.3.4.1.4.14.1
SKA1-SYS_REQ- SKA1_Low Pulsar Search number of channels
2916
SKA1_Low Pulsar search number of channels. SKA1_Low shall use 8192 channels for the Pulsar Search
Parent Comment Issue
Michael Rupen
18 August 2015
1.3.4.1.4.15
SKA1-FLD-1854 Pulsar search sampling interval
1.3.4.1.4.15.1
Surely this is not a requirement at Level 1!
SKA1-SYS_REQ- SKA1_Low Pulsar search sampling interval
2917
SKA1_Low Pulsar search sampling interval. SKA1_Low shall have a minimum sampling interval for the Pulsar Search of no greater than 100 microseconds.
Parent Comment Issue
Michael Rupen
18 August 2015
1.3.4.1.4.16
SKA1-FLD-1875 SKA1_Low Pulsar search configurability
1.3.4.1.4.16.1
SKA1-SYS_REQ- SKA1_Low Pulsar Search Configurability 1
2918
Another Level 3 requirement...
SKA1_Low Pulsar search configurations. SKA1_Low, when commanded, shall perform the Pulsar Search with a configurable sampling interval up to at least 4
times the minimum sampling interval.
Parent Comment General
Michael Rupen
18 August 2015
Strange to have "up to at least". CSP interpretation is that "Up to at least 4
times" means you have to be able to configure to n*the sampling interval, with
n={1,2,3,4}, and you *can* implement the capability of going to n=5 or higher, if
you feel like it.
Parent Comment Proposed Change Michael Rupen
18 August 2015
Suggest re-wording:
When in pulsar search mode, the SKA1_Low shall search for pulsar using a
configurable...
1.3.4.1.4.16.2
SKA1-SYS_REQ- SKA1_Low Pulsar Search Configurability 2
2919
SKA1_Low Pulsar search configurations. SKA1_Low, when commanded, shall perform the Pulsar Search with a configurable bandwidth down to 0.25 times the
minimum sampling interval.
Parent Comment General
21/09/2015 7:42 am
Wallace Turner
22 July 2015
Evan Keane/ Mike Keith
Cut and paste error requirement should read:
Page
87 of 196
SKA1_Low, when commanded, shall perform the Pulsar Search with a configurable
bandwidth down to 0.25 times the full SKA1-Low band.
Parent Comment Proposed Change Michael Rupen
18 August 2015
Should this be:
When in pulsar search mode, SKA1_Low shall perform the Pulsar Search with a
configurable bandwidth down to 0.25 times the inverse of the minimum sampling
interval.
Ah, I see Evan has weighed in. If his suggestion is adopted instead, it should
probably say "0.25 times the pulsar search bandwidth", since this is configurable.
Parent Comment Question
John Bunton
31 August 2015
how can a bandwidth (dimension s^-1) be 0.25 and time interval (dimension s)?
1.3.4.1.4.16.3
SKA1-SYS_REQ- SKA1_Low Pulsar Search Configurability 3
2920
SKA1_Low, when configuring the Pulsar Search, may restrict the choices of sampling rate, bandwidth, and their product, to be integer multiples of an internal
digitisation rate.
Parent Comment Issue
Michael Rupen
18 August 2015
This requirement as worded does not make sense -- only the sampling rate can
be a multiple of the internal digitization rate. What is intended here?
Parent Comment Question
Michael Rupen
18 August 2015
1.3.4.1.4.2
SKA1-FLD-1841 Dispersion Measure
1.3.4.1.4.2.1
SKA1-SYS_REQ- SKA1_Low Dispersion Measure
2942
Should this be allocated to TM as well, as they will do the restricting at the
observer level?
SKA1_Low Dispersion Measure. SKA1_Low, when performing the Pulsar Search, search for unaccelerated pulsars with dispersion measures from 0 to 3000 pc cm 3. SKA1_Low shall use sufficient dispersion measure trials such that the degradation in signal-to-noise ratio due to coarse sampling is no worse than 85% anywhere in
the dispersion measure range.
Parent Comment Proposed Change Michael Rupen
18 August 2015
1.3.4.1.4.3
SKA1-FLD-1842 Time Resolution
1.3.4.1.4.3.1
SKA1-SYS_REQ- SKA1_Low Pulsar Search time resolution
21/09/2015 7:42 am
Suggest slight re-wording:
When in pulsar search mode, SKA1_Low shall search each pulsar search beam
independently and concurrently for unaccelerated pulsars with trial dispersion
measures from 0 to 3000 pc cm -3...
Goal is to align with observing modes and to note the concurrency of multiple
pulsar search beams.
Page
88 of 196
2944
SKA1_Low Time resolution. SKA1_Low shall retain time resolution in the Pulsar Search such that any increase in sampling interval at high dispersion measure trials
does not degrade the signal-to-noise ratio below 95% compared to the maximum time resolution.
Parent Comment Proposed Change Michael Rupen
18 August 2015
1.3.4.1.4.4
SKA1-FLD-1843 Pulsar search observation time
1.3.4.1.4.4.1
SKA1-SYS_REQ- SKA1_Low Pulsar search observation time
2946
Suggest slight re-wording:
SKA1_Low shall retain time resolution in the Pulsar Search such that the signalto-noise ratio for all dispersion measure trials is not degraded below 95%,
compared to that obtainable with the highest possible time resolution for the
bandwidth being searched.
Also, boldface header of this requirement should be changed to SKA1_Low
Pulsar Search time resolution.
SKA1_Low Pulsar search observation time. SKA1_Low, when commanded, shall perform the Pulsar Search with an operator configured observation time between
180 and 1800 seconds. The SKA1_Low may restrict the choice of observing time to be fixed multiples of the sampling interval.
Parent Comment Proposed Change Michael Rupen
18 August 2015
Slight re-wording for subarrays and modes:
When commanded, SKA1_Low, for each subarray in pulsar search mode, shall
perform the Pulsar Search...
Parent Comment Question
18 August 2015
Does this imply a different observation time for each subarray? For each pulsar
search beam?
Michael Rupen
1.3.4.1.4.5
SKA1-FLD-1844 Single pulse searches
1.3.4.1.4.5.1
SKA1-SYS_REQ- SKA1_Low Single Pulse Searches
2948
SKA1_Low Dispersion Measure. SKA1_Low, when performing the Pulsar Search, search for individual pulses with dispersion measures from 0 to 3000 pc cm -3 and
with widths from 100 microseconds to 1 second. SKA1_Low shall use sufficient dispersion measure trials such that the degradation in signal-to-noise ratio due to
coarse sampling is no worse than 85% anywhere in the dispersion measure range. SKA1_Low shall obtain a signal-to-noise ratio for a pulse in a de-dispersed timeseries that is no worse than 85% compared to using a Gaussian matched filter of the correct width.
Parent Comment Proposed Change Michael Rupen
1.3.4.1.4.6
18 August 2015
Missing "shall":
CSP_Low, when performing the Pulsar Search, SHALL search...
SKA1-FLD-1845 Binary search
21/09/2015 7:42 am
Page
89 of 196
1.3.4.1.4.6.1
SKA1-SYS_REQ- SKA1_Low Binary Pulsar search
2936
SKA1_Low Binary Pulsar Search. SKA1_Low, when the observation duration is less than 600s, shall perform acceleration correction as part of the Pulsar Search,
over a configurable range of acceleration values from 0 to no less than 350 ms-2, for no fewer than 500 operator selected dispersion measure trials. SKA1_Low shall
use sufficient acceleration trials such that the degradation in signal-to-noise due to coarse sampling is no worse than 66% anywhere in the acceleration range. If
Fourier domain correction is used, the trials shall be defined over a range of Fourier drift that is equivalent to the acceleration search for a 500 Hz signal.
Parent Comment Proposed Change Michael Rupen
18 August 2015
Slight re-wording to mention independent pulsar search beams:
For each pulsar search beam, when the observation duration is less than 600s,
SKA1_Low shall perform acceleration correction...
1.3.4.1.4.7
SKA1-FLD-1846 Search and timing in subarrays
1.3.4.1.4.7.1
SKA1-SYS_REQ- SKA1_Low Pulsar search and timing within subarrays
2884
SKA1_Low Pulsar search and timing within subarrays. SKA1_Low, when commanded shall perform the Pulsar Search and Pulsar Timing for each subarray,
independently and concurrently
Parent Comment Proposed Change Michael Rupen
18 August 2015
1.3.4.1.4.8
SKA1-FLD-1847 Pulsar search array diameter
1.3.4.1.4.8.1
SKA1-SYS_REQ- SKA1_Low Pulsar search array diameter
2885
"...perform the Pulsar Search" should just be "...perform Pulsar Search".
SKA1_Low Pulsar search array diameter. Each SKA1_Low subarray, when performing the Pulsar Search, shall form Pulsar search beams using any or all stations
within that subarray, which are separated by up to 20,000 metres.
Parent Comment Proposed Change Michael Rupen
18 August 2015
Slight re-wording to account for observing mode, and to read more smoothly:
For each SKA1_Low subarray in pulsar search mode, SKA1_Low shall form
Pulsar search beams using any or all stations within that subarray, which are
separated by no more than 20,000 metres.
Parent Comment Question
18 August 2015
OK, I have to ask -- why is Pulsar capitalized sometimes, Pulsar Search other
times, and neither in yet other cases? I find random caps quite distracting -could we just switch to lower case, for words that do not have special meanings
for SKA?
1.3.4.1.4.9
Michael Rupen
SKA1-FLD-1848 Pulsar search beamformer centre frequency
1.3.4.1.4.9.1
SKA1-SYS_REQ- SKA1_Low Pulsar search frequency
21/09/2015 7:42 am
Page
90 of 196
2888
SKA1_Low Pulsar Search observing frequency SKA1_Low, when commanded, shall perform the Pulsar Search on an operator configured continuous bandwidth
located anywhere within the SKA1_Low band.
Parent Comment Proposed Change Michael Rupen
21/09/2015 7:42 am
18 August 2015
Suggested re-wording, to account for subarrays, reference modes, and refer to
the digitized rather than the full observing band (to account for multiple station
beams, if those allow pulsar observations):
For each subarray in pulsar search mode, SKA1_Low shall perform Pulsar
Search on a TM-configured contiguous bandwidth, located anywhere within the
SKA1_Low digitized band.
I would still rather say "search for pulsars" rather than "Pulsar Search"...maybe
we can come up with some better convention there?
Page
91 of 196
1.3.4.1.5
SKA1-FLD-1833 SKA1_Low Pulsar Timing
1.3.4.1.5.1
SKA1-FLD-1855 Pulsar timing subarray radius
Parent Comment General
1.3.4.1.5.1.1
Michael Rupen
18 August 2015
Note that the requirement is more nearly on the diameter than on the radius
(maximum separation).
SKA1-SYS_REQ- SKA1_Low Pulsar timing array radius
2922
SKA1_Low Pulsar timing array radius. Each SKA1_Low subarray shall form pulsar timing beams using any or all stations within that sub-array, which are separated
by at most 20,000 metres
Parent Comment Proposed Change Michael Rupen
18 August 2015
Parent Comment General
18 August 2015
Michael Rupen
1.3.4.1.5.10
SKA1-FLD-1866 Pulsar timing dispersion measure
1.3.4.1.5.10.1
SKA1-SYS_REQ- SKA1_Low Pulsar timing Dispersion Measure.
2958
Re-wording for modes:
For each SKA1_Low subarray in pulsar timing mode, CSP_Low shall form pulsar
timing beams using any or all stations within that subarray, which are separated
by no more than 20,000 metres.
Title does not match the requirement (radius vs. maximum separation).
SKA1_Low Pulsar timing Dispersion Measure. The SKA1_Low shall time Pulsars with dispersion measures between 0 to 3000 TBC pc cm
dispersive smearing is limited by the precision of the supplied dispersion measure.
Parent Comment Proposed Change Michael Rupen
18 August 2015
-3
such that residual
CSP has discusses saying:
For each pulsar timing beam, the CSP_Low shall time Pulsars with dispersion
measures between 0 to 3000 TBC pc cm -3 such that residual dispersive
smearing is less than 500 ns TBC or as limited by the precision of the supplied
dispersion measure.
I prefer the CSP wording, but the content question is whether we want the limit
on the best possible residual smearing ("less than 500 ns OR as limited by...").
1.3.4.1.5.11
SKA1-FLD-1867 Calibrated polarisation fidelity for Pulsars
1.3.4.1.5.11.1
SKA1-SYS_REQ- SKA1_Low Calibrated Polarisation Fidelity for Pulsars
2966
SKA1_Low Calibrated Polarisation Fidelity for Pulsars. The SKA1_Low telescope shall produce phase-resolved averages of the polarised flux from Pulsars with
21/09/2015 7:42 am
Page
92 of 196
calibrated polarisation fidelity of at least 40 dB.
Parent Comment Issue
Michael Rupen
18 August 2015
Very important and poorly worded.
1.
2.
As written, this applies to all pulsar observations: PSS, PST, and phase
binning (maybe even simple imaging observations).
40 dB is quite difficult, and has implications far beyond CSP. For instance,
we must provide and apply calibration information that allows this fidelity,
with implications for update rate, accuracy, etc., presumably to be allocated
to TM and SDP (and maybe LFAA). There are implications for our
understanding of the pol'n properties of the station beams as well.
3.
As written it is not clear whether we must simply be able to achieve this
fidelity, once every 50 years, under perfect conditions, with the gods
smiling; or whether this is meant to be an all-the-time thing. I assume the
latter is intended, but this has huge implications for the beamformer, if we
have to do per-station, per-beam corrections for PSS and PST, for tiedarray beams placed arbitrarily within the station beams (e.g., at the halfpower points). One could read this as restricting the placement of tiedarray beams to avoid pol'n errors due to pointing errors, poor knowledge of
the primary beam, etc. The preference of the PSS/PST guys at the
moment seems to be for the ability to achieve this accuracy for a few
beams near the center of the station beam, while relaxing the requirement
away from the station beam center.
4.
We really need fidelity requirements as a function of weather conditions
(wind, ionosphere, etc.), location within the primary beam, observing mode,
strength of the pulsar. and the like. I love having an actual fidelity
requirement (and want many more) but it needs some careful thought.
1.3.4.1.5.12
SKA1-FLD-1876 SKA1_Low cross polarisation purity (Pulsar timing)
1.3.4.1.5.12.1
SKA1-SYS_REQ- SKA1_Low Cross Polarisation Purity, Pulsar Timing
2964
SKA1_Low Cross Polarisation Purity, Pulsar timing. The SKA1_Low intrinsic cross polarisation ratio for Pulsar timing shall be at least 15 dB over the whole
observing bandwidth within the half power beam width
Parent Comment Question
Michael Rupen
18 August 2015
Do we know that this allows us to meet 2966?
Is the intrinsic cross-pol'n ratio really different for pulsar timing than for other
observing modes? How can that be?
21/09/2015 7:42 am
Page
93 of 196
Should I interpret this as meaning that we have to be able to place pulsar timing
beams anywhere within the half-power beam width? Must we achieve the pol'n
fidelity requirement (2966) for beams placed anywhere within that area?
Are we assured that the station beams are identical for every station? If not,
which HPBW is intended here?
I know SKA loves the intrinsic cross-pol'n ratio, but I don't think specifying this is
sufficient to be sure the desired pol'n properties are achieved.
1.3.4.1.5.13
SKA1-FLD-1877 SKA1_Low Pulsar timing resolution
1.3.4.1.5.13.1
SKA1-SYS_REQ- SKA1_Low Pulsar Timing Resolution
2962
SKA1_Low Pulsar Timing resolution. The timing resolution shall be better than 100 ns for SKA1_Low Pulsar timing.
Parent Comment General
Ewan Barr
17 July 2015
Parent Comment Proposed Change Michael Rupen
18 August 2015
Parent Comment Proposed Change John Bunton
31 August 2015
1.3.4.1.5.2
SKA1-FLD-1856 Pulsar timing observing band
1.3.4.1.5.2.1
SKA1-SYS_REQ- SKA1_Low Pulsar timing observing band
2924
This will be informed by a forthcoming SKA technical memo from the CSP.PST
and Pulsar SWG.
Pending Ewan's mystical memo, I propose re-wording this as:
The timing resolution of SKA1_Low in the pulsar timing mode shall be at least as
good as 100ns TBC or the theoretical limit imposed by the dispersion measure,
whichever is larger.
This at least avoids absurdities.
needs to allocated to LFAA as well. They do coarse channelisation which can
make this very difficult to achieve.
SKA1_Low Pulsar timing observing band. The SKA1_Low, when commanded, shall form beams for each of the Pulsar timing subarrays with a selectable observing
band for each subarray anywhere in the SKA1_Low band.
Parent Comment Proposed Change Michael Rupen
21/09/2015 7:42 am
18 August 2015
Re-word for modes:
For each SKA1_Low subarray in pulsar timing mode, the SKA1_Low shall form
beams with a selectable observing band for each subarray which may be placed
anywhere within the SKA1_Low band.
Do we need to allow for multiple station beams, each of which may only have
access to a fraction of the SKA1_Low band?
Page
94 of 196
Parent Comment General
Michael Rupen
Parent Comment Question
Michael Rupen
1.3.4.1.5.3
SKA1-FLD-1857 Pulsar timing bandwidth
1.3.4.1.5.3.1
18 August 2015
CSP would like this to be restricted to the placement of the coarse channels
provided by LFAA. If it's not, this requirement must also be allocated to LFAA.
18 August 2015
Should this also be allocated to TM? since they will be doing the commanding.
SKA1-SYS_REQ- SKA1_Low Pulsar timing bandwidth
2926
SKA1_Low Pulsar timing bandwidth. The SKA1_Low, when performing Pulsar timing, shall have a contiguous processing bandwidth up to the full bandwidth up to
the entire SKA1_Low band.
Parent Comment Proposed Change Michael Rupen
18 August 2015
Suggest:
For each subarray in pulsar timing mode, the SKA1_Low shall process a
contiguous bandwidth up to the full bandwidth of the entire SKA1_Low band.
Again, do we need to consider station beams with less BW available?
CSP would like the BW of each PST beam to be configurable only in steps
corresponding to the coarse channels provided by LFAA.
1.3.4.1.5.4
SKA1-FLD-1858 Pulsar timing number of beams
1.3.4.1.5.4.1
SKA1-SYS_REQ- SKA1_Low Number of Pulsar timing beams.
2928
SKA1_Low Number of Pulsar timing beams. The SKA1_Low, when commanded, shall form up to 16 dual polarisation beams in total across all Pulsar timing
subarrays.
Parent Comment General
Michael Rupen
Parent Comment Proposed Change Michael Rupen
18 August 2015
18 August 2015
Parent Comment Question
Michael Rupen
18 August 2015
1.3.4.1.5.5
SKA1-FLD-1859 Pulsar timing beamformer S/N performance
Should combine this with 2950.
Suggest:
When instructed, SKA1_Low shall form and process the data from up to 16 dual
polarisation beams in total, spread across any and all subarrays which are in
Pulsar Timing mode.
Note that some requirements say "When instructed" while others mention an
actor (generally the operator). Ideally we would agree on a common wording
throughout.
Should this also be allocated to TM?
1.3.4.1.5.5.1
SKA1-SYS_REQ- SKA1_Low Beamforming S/N ratio: Pulsar timing.
21/09/2015 7:42 am
Page
95 of 196
2930
SKA1_Low Beamforming S/N ratio: Pulsar timing. The SKA1_Low for Pulsar timing shall have a Signal to Noise ratio greater or equal to 98% TBC of an ideal
analogue beam former.
Parent Comment Proposed Change Michael Rupen
18 August 2015
See 2896. Comments repeated here (with slight tweaks) for ease.
I'd prefer "when forming pulsar timing beams...".
If the 98% is intended to include coherence losses due to poor calibration and
SNR losses due to incorrect antenna weights, this should also be allocated to
TM and SDP. If this is not the intent, this requirement should be re-phrased:
The SKA1_Low, when forming pulsar timing beams, shall not degrade the signalto-noise to less than 98% TBC of that achievable by an ideal analogue beamformer, given the same digitized inputs and calibration.
Of course this would really be an L2 requirement.
Also in this case, where are the requirements on the accuracy of such
calibration/weighting?
1.3.4.1.5.6
SKA1-FLD-1860 Pulsar timing subarray support
1.3.4.1.5.6.1
SKA1-SYS_REQ- SKA1_Low Pulsar timing subarray support
2950
SKA1_Low Pulsar timing subarray support. The SKA1_Low, when commanded, shall independently and concurrently process up to a maximum 16 Pulsar timing
beams allocated across instantiated subarrays.
Parent Comment Issue
Michael Rupen
18 August 2015
Parent Comment Question
Michael Rupen
18 August 2015
1.3.4.1.5.7
SKA1-FLD-1863 Pulsar timing observation time
1.3.4.1.5.7.1
Should be merged with 2928. (q.v. for comments).
Should this also be allocated to TM?
SKA1-SYS_REQ- SKA1_Low Pulsar timing observation time
2954
SKA1_Low Pulsar timing observation time. The observation duration for each SKA1-LOW Pulsar timing subarray shall be set independently with a value between 3
and 300 minutes with a granularity of TBD seconds.
Parent Comment Proposed Change Michael Rupen
1.3.4.1.5.8
18 August 2015
This should also be allocated to TM.
SKA1-FLD-1864 Pulsar timing time coding
1.3.4.1.5.8.1
SKA1-SYS_REQ- SKA1_Low Time coding
21/09/2015 7:42 am
Page
96 of 196
2956
SKA1_Low Time coding. Each data sample shall be traceable to a time code with an accuracy better than 10 ns over periods between 1 observation and 10 years
for each individual Pulsar timing observation within SKA1_Low.
Parent Comment Proposed Change Michael Rupen
18 August 2015
1.3.4.1.5.9
SKA1-FLD-1865 Multiple simultaneous timings
1.3.4.1.5.9.1
SKA1-SYS_REQ- SKA1_Low Timing Beams
2940
Suggest:
For each individual pulsar timing observation within a SKA1_Low subarray, each
data sample shall be traceable to a time stamp derived from a clock accurate to
10ns over periods between 1 observation and 10 years, referenced to a
common, consistent delay centre at or near the centre of the SKA1_Low array.
SKA1_Low Timing Beams. The SKA1_Low pulsar timing beamformer shall be capable of forming multiple tied array beams within the same subarray, with the same
sky coordinates.
Parent Comment Proposed Change Ewan Barr
General
Michael Rupen
Parent Comment Proposed Change John Bunton
17 July 2015
18 August 2015
31 August 2015
General
Michael Rupen
3 September 2015
General
Ewan Barr
4 September 2015
Parent Comment General
John Bunton
4 September 2015
Parent Comment General
John Bunton
4 September 2015
21/09/2015 7:42 am
Is it not clearer to specify all beams as having independent pointing positions.
SKA1_Low Timing Beams. The SKA1_Low pulsar timing beamformer shall be
capable of forming multiple tied array beams within the same subarray, with
independent sky coordinates.
I believe the idea here was to be sure that it was clear that we needed to be able
to put multiple tied-array beams right on top of each other. So we wanted a
direct statement that this was OK. We did argue over whether such a statement
was really necessary, but decided that it couldn't hurt and might help.
Is this requirement to get extra bandwidth with fewer beams.
If so can we just have
Half as many beams at twice the bandwidth and one third as many beams at
three time the bandwidth.
I believe the intent is also to allow some beams to be doubled up and others not
to be. So they want some beams of double/treble/whatever times the BW, and
others to have the "normal" BW. I would certainly push back if this extra
complexity is troublesome for your architecture.
No. This is about timing beams. There is no extra bandwidth to be had, as the
timing beams provide the full band. This sounds like a discussion that is related
to a different requirement.
I talked to Ben Stappers about this.
He was happy to have all beams with the same bandwidth.
What was not specified is whether the bandwidth is contiguous.
Sorry for the confusion. So why, within a single subarray, is there a need for
Page
97 of 196
General
Ewan Barr
4 September 2015
same two beams with the same sky coordinates.
The reasoning for Mid is clear, but for Low I am struggling to see why this is a
requirement on the beamformer. I can imagine a situation where you have
multiple pulsars in a globular cluster and you train multiple beams on it (from one
sub-array) to give you multiple streams that can be analysed in the pulsar timing
engine. However, even in this case the pulsar positions are not truly the same.
I think the intent of this requirement is ensure that we do not preclude having
multiple beams on the same sky position (essentially having to parts of the
beamformer behave identically). I can see a case, for instance, where we may
want to do two different projects looking at the same source (timing +
exoplanets, SETI, dynamic spectrum mode, etc.)
For Low, the correct way to implement this for timing would be to beamform on
one sky position, but send to multiple processing engines in the PST (maybe just
using a port replicator).
Parent Comment General
John Bunton
4 September 2015
General
Ewan Barr
4 September 2015
1.3.4.2
SKA1-FLD-861
Reflector Antennas
1.3.4.2.1
SKA1-FLD-862
Diameter
1.3.4.2.1.1
SKA1-SYS_REQ- Diameter.
2153
Can you identify the constraint that this requirement puts on your design. I would
have thought that the beamformer was sky position agnostic, so to speak.
There is no trouble meeting this requirement. Just give us identical phasing for
two beams and they are identical.
I think this may be a carry over from PSS where they do want multiple beams
with the same pointing (CSP think of it as a single beam with increased
bandwidth, but reduced numbers of beams)
I agree, this seems like a vestigial PSS limb. I see no need to drop this
requirement for Low timing as it is at least explicit about an aspect of the system
(even if that imposes little or no constraints on design).
Diameter. SKA1 dishes shall have a projected diameter of larger than 15m and smaller than 16.5m.
Parent Comment General
21/09/2015 7:42 am
Wallace Turner
10 July 2015
Rev 6 comment Roshene McCool
Is this an acceptable range at this stage in the project?
Page
98 of 196
Parent Comment General
Wallace Turner
10 July 2015
Reply to Roshene
The requirement provides a constraint on dish size whilst offering a trade off
space with respect the Tsys, aperature efficiency and collecting area.
No further action this document
Parent Comment Question
Michael Rupen
18 August 2015
Should this be allocated to SDP, CSP, and/or TM? Here are the arguments:
1.
2.
1.3.4.2.2
SKA1-FLD-864
1.3.4.2.2.1
SKA1-SYS_REQ- Aperture Efficiency.
2155
If the placement of tied-array beams is limited to some response point
within the primary beam, as seem likely (there is no current requirement),
CSP, TM, and SDP will need to know the dish diameter (at minimum) to
figure out residual delays and the required update rates for those.
SDP presumably has to know the dish diameter (at minimum) to figure out
the size of the data processing problem.
Aperture efficiency
Aperture Efficiency. Aperture efficiency shall be within +/- 5 % of:
•
•
•
•
•
60% at 350MHz with gradual degradation from 400 to 350 MHz
65% at 400MHz
78% from 600MHz to 8000MHz
70% from 8 to 15 GHz
65% from 15 to 20 GHz
Parent Comment General
Michael Rupen
18 August 2015
Need to extend this to cover 400-600 MHz (the only missing bit at the moment).
Odd to see this as a merely Useful requirement, with no corresponding Essential
requirement.
I don't understand why you want the aperture efficiency within 5% of these
values. Surely you want an aperture efficiency AT LEAST AS GOOD AS these
numbers -- would you really reject a telescope which had a flat 85% aperture
efficiency between 350 MHz and 20 GHz, just for that reason?
Parent Comment General
21/09/2015 7:42 am
adriaan peens-hough
24 August 2015
As an example of how this requirement can be clarified, the DSH spec at PDR
Page
99 of 196
interprets this as follows:
Over the full accessible elevation range, under precision and standard operating
conditions, Antenna efficiency shall be at least:
60% at any frequency from 350 MHz to 400 MHz
73% at any frequency from 400 to 8000 MHz
65% at any frequency from 8 to 15 GHz
60% at any frequency from 15 to 20 GHz
Antenna efficiency is the ratio of the maximum effective area to the physical
aperture area (these are terms defined in IEEE Std 145)
1.3.4.2.3
SKA1-FLD-867
Precision pointing repeatability
1.3.4.2.3.1
SKA1-SYS_REQ- Pointing repeatability.
2158
Pointing repeatability. The pointing repeatability shall be better than 10 arc seconds rms for winds < 7 m/s at night time.
Parent Comment General
Wallace Turner
10 July 2015
Rev6 comment Juande Santander-Vela
Consider renaming to "Precision pointing repeatability", or to "Pointing
repeatability - Low wind / nigh time", to homogenise the requirements.
Parent Comment General
Wallace Turner
10 July 2015
Reply to Juande:
Agree
Action: Rename requirement "preciison pointing repeatability"
Parent Comment Proposed Change Michael Rupen
18 August 2015
2158 refers to "winds < 7 m/s" while 2159 refers to "average winds < 7 m/s)" -- is
this difference significant?
Requirement should explicitly refer to SKA1-Mid dishes, or at least to SKA1-Mid:
SKA1-Mid precision pointing repeatability. Each SKA1-Mid dish shall achieve a
pointing repeatability better than 10 arc seconds rms (averaged over the
observable sky) for winds < 7 m/s at night time.
Note that one should mention how the rms is calculated -- I added one possibility
to the re-wording above. One might also want to give a timescale (i.e., is this for
observations on a single night, over a week, over a year?). The truly persnickety
will point out that you don't really mean nighttime, you mean when the dish has
cooled off, which is several hours after sunset.
If offset (referenced) pointing is to be used, there must be a requirement on such
referenced pointing -- see the EVLA Project Book for example requirements.
21/09/2015 7:42 am
In any case, there should be a requirement on the number and cadence of
Page
100 of 196
antenna moves etc., and on the settling time. The latter could be derived from
other requirements, with some pain, but the former are really system-level
considerations.
1.3.4.2.4
SKA1-FLD-868
Standard pointing repeatability
1.3.4.2.4.1
SKA1-SYS_REQ- Pointing repeatability - Low wind / day time
2159
Pointing repeatability. The pointing repeatability shall be better than 17 arc seconds rms for an average wind speed of < 7 m/s in the day time
Parent Comment Proposed Change Michael Rupen
18 August 2015
See comments on 2158.
1.3.4.2.5
SKA1-FLD-869
Degraded pointing repeatability
Parent Comment General
Wallace Turner
10 July 2015
Parent Comment General
Wallace Turner
10 July 2015
Rev6 comment Juande Santander-Vela
Consider renaming this section, or renaming the following requirement for
homogenisation.
Reply to Juande
Agree. Rename following requirement
No further action this item
1.3.4.2.5.1
SKA1-SYS_REQ- Pointing repeatability - Higher wind
2160
Pointing repeatability. The pointing repeatability shall be better than 180 arc seconds rms for an average wind speed between 7 and 20 m/s
Parent Comment General
Wallace Turner
10 July 2015
Rev6 comment Juande Santander-Vela
Consider renaming this requirement, or renaming the corresponding section for
homogenisation.
Parent Comment General
Wallace Turner
10 July 2015
Reply to Juande
Agree.
Action Rename requirement degraded pointing repeatability
Parent Comment General
Michael Rupen
18 August 2015
See comments on 2158.
Would be nice to have a requirement that the pointing gracefully degrades
depending on weather conditions, but this probably falls out naturally.
The pointing requirements should ideally be derived as they were for ALMA, via
a detailed analysis of scientific requirements in the context of the historical
weather data for the site, taking account e.g. of the likely distribution of scientific
pressure vs. frequency. This of course must all change now that Band 5 has
such high priority. Has such an analysis been done?
21/09/2015 7:42 am
Page
101 of 196
1.3.4.2.6
SKA1-FLD-871
Number of receivers
1.3.4.2.6.1
SKA1-SYS_REQ- Number of feeds.
2162
Number of feeds. There shall be space at the Gregorian focus of SKA1 dishes for five single pixel feeds (SPF) or three Phased Array Feeds (PAF)
Parent Comment Question
Michael Rupen
1.3.4.2.7
Polarisation purity
SKA1-FLD-874
18 August 2015
Doesn't the size of a PAF scale directly with the number of beams? If so, don't
we need a number for that here?
The polarisation purity of reflector antenna shall be expressed by using the intrinsic polarisation ratio (IXR). It will give coordinate system independent FoM of the polarisation purity
and quantify the polarimetric performances even after the calibration.
Parent Comment General
1.3.4.2.7.1
Michael Rupen
22 August 2015
I worry that the IXR as a measure of polarization performance is used almost
exclusively by the SKA, and many polarization experts seem unfamiliar with it or
skeptical of its utility. I also worry that while the IXR purports to measure the
best performance one might possibly hope for out of an instrument, that is not
the same as actually _achieving_ that performance, which at minimum requires a
well-thought-out widefield polarization calibration plan.
SKA1-SYS_REQ- SKA1_Mid Cross Polarisation Purity, Pulsar Timing
2165
SKA1_Mid Cross Polarisation Purity, Pulsar Timing. The SKA1_Mid intrinsic cross polarisation ratio for Pulsar timing shall be at least 15 dB over the whole
observing bandwidth within the half power beam width
Parent Comment General
Wallace Turner
10 July 2015
Parent Comment General
Wallace Turner
10 July 2015
Parent Comment General
Wallace Turner
10 July 2015
SDP FG:
Needs further discussion with SKAO regarding calibration scheme and error
budgets.
Parent Comment General
Ewan Barr
17 July 2015
Michael Rupen
18 August 2015
Based on discussions at the CSP Delta-PDR the working assumption here is that
this does not affect the SDP, only DSH and CSP.
This is complicated. The IXR is independent of calibration, and also sets only an
upper limit to the achieved pol'n fidelity. To achieve what the IXR in principle
allows places requirements on SDP and TM, which must provide the calibration
solutions CSP applies. But the IXR itself is I believe a requirement only on DSH.
General
21/09/2015 7:42 am
SDP comment
if the SDP is allocated to the requirement then mention of calibration must be
made.
GHT:
Under investigation
Page
102 of 196
Of course everyone else has to know what the delivered pol'n performance is,
because that folds into the system-level pol'n leakage budget. So far as I know
that budget has yet to be allocated.
Parent Comment General
Wallace Turner
22 July 2015
Miles Deegan:
General
Wallace Turner
22 July 2015
Agree there is a typo on the parent which should be ECP150004
Parent Comment Question
Michael Rupen
18 August 2015
Why is this specific to pulsar timing? And if it is, what are the requirements for
other types of observations? I suppose one could define IXR for the tied-array
beams (!) but I can't believe that's what's intended here.
Parent Comment General
Michael Rupen
18 August 2015
Do we know that this allows us to meet the pol'n fidelity requirement?
it looks like there might be a typo. SKA1-SYS_REQ-2165 – SKA1-MID cross
polarisation purity, pulsar timing - is shown as accepted and yet the parent
requirement is ECP150007 – weak lensing, grided visibilities - hasn’t been
accepted (and I’m not sure it addresses this requirement anyway).
Should I interpret this as meaning that we have to be able to place pulsar timing
beams anywhere within the half-power beam width? Must we achieve the pol'n
fidelity requirement for beams placed anywhere within that area?
I know SKA loves the intrinsic cross-pol'n ratio, but I don't think specifying this is
sufficient to be sure the desired pol'n properties are achieved.
1.3.4.2.8
SKA1-FLD-879
Elevation limit
1.3.4.2.8.1
SKA1-SYS_REQ- Elevation limit.
2170
Elevation limit. Reflector antennas shall be capable of operating at all elevations greater than 15 degrees
Parent Comment Proposed Change Michael Rupen
18 August 2015
Presumably this should be "SKA1_Mid reflector antennas..."
Why are they "reflector antennas" here but "dishes" in the azimuth requirement
(2171)?
Parent Comment Question
21/09/2015 7:42 am
Michael Rupen
18 August 2015
As usual I'm not sure whether allocations must be made to elements which have
to know this information in order to do their job. E.g., the elevation limit
determines the approximations that can be used in determining opacity, and for
atmospheric refraction. TM must also enforce these limits in software at some
level. Does this mean this requirement should also be allocated to TM and
maybe SDP?
Page
103 of 196
1.3.4.2.9
SKA1-FLD-880
Azimuth range
1.3.4.2.9.1
SKA1-SYS_REQ- Azimuth range.
2171
Azimuth range. The Dish shall have a continuous useable azimuth observation range from -270° to +270°, inclusive measured relative to true North defined as 0°
and with East defined as +90°
Parent Comment Proposed Change Michael Rupen
21/09/2015 7:42 am
18 August 2015
See comments on 2170.
Page
104 of 196
1.3.4.3
SKA1-FLD-882
SKA1_Mid
1.3.4.3.1
SKA1-FLD-1613 SKA1_Mid configuration and performance
1.3.4.3.1.1
SKA1-FLD-883
Inclusion of MeerKAT
1.3.4.3.1.1.1
SKA1-SYS_REQ- SKA1_Mid inclusion of MeerKAT
2833
SKA1_Mid inclusion of MeerKAT. The SKA1_Mid shall incorporate the 64 antennas in both monitor and control and data collection functions.
Parent Comment Proposed Change Michael Rupen
18 August 2015
Missing word -- should be:
The SKA1_Mid shall incorporate the 64 MeerKAT antennas in both monitor and
control and data collection functions.
1.3.4.3.1.1.2
SKA1-SYS_REQ- Monitor and control of MeerKAT
2173
MeerKAT array. The monitor and control functions of MeerKAT shall be made available to SKA1_Mid via a Foreign Telescope interface consisting of a Local Monitor
and Control system connected to the SKA1_Mid Telescope Manager.
1.3.4.3.1.2
SKA1-FLD-1611 Absolute flux scale
1.3.4.3.1.2.1
SKA1-SYS_REQ- Absolute flux scale (essential)
2825
Absolute flux scale: The absolute flux scale shall be accurate to 5% rms.
Parent Comment General
Michael Rupen
18 August 2015
21/09/2015 7:42 am
See comments on 2824, repeated here for easy reference:
1.
In the absence of a calibration scheme I do not know how this should be
allocated, or what it means for the elements. Put another way, there are
many ways for SKA1 to meet this requirement, but the basic approach must
be chosen at the system level, and will then flow down into the various
elements. For instance, this could entail the use of switched noise diodes
(with implications for CSP), or opacity measurements, or fast
switching...you get the idea.
2.
The allocation suggests this applies only to SKA1-Mid, but the actual
requirement is completely general.
3.
Suggest making this "better than 5%" -- my corporate friends tell me that,
as written, a system accurate to 3% would not meet spec. Seems
Page
105 of 196
Parent Comment Issue
Michael Rupen
18 August 2015
ridiculous to me but I'll pass this up for you to decide...
Since there's nowhere else to say this, I'll comment here that we could really use
some fidelity and accuracy requirements, for all observing modes, with various
conditions attached (weather, observing band, etc.).
We also really need a requirement on the relative (or internal) flux scale.
Absolute flux densities are great, but often it's even more important to be able to
measure relative flux densities even more accurately -- for variability studies
(including transient detection), spectral index work, combining observations
taken on different days, determining line/continuum ratios and line/line ratios,
etc. Note that we're speaking here of consistency over both time and frequency.
The same point can be made for other scientifically interesting quantities, like
source positions. Absolute astrometry is very important in many contexts, but is
also very hard; relative astrometry is much easier, but also allows important
science. If I can trust subtle changes in source positions over time I can
measure proper motions, which can be turned into distances, velocities, even the
detection of star spots or planets at high frequencies.
Parent Comment General
Michael Rupen
18 August 2015
The absolute (and relative) flux scale requirement should be a function of
observing frequency.
Parent Comment Question
Michael Rupen
18 August 2015
Should this also be allocated to TM? Achieving accurate flux densities places
requirements on the rate of calibration, for instance, and I suspect the SKAO has
the ALMA model in mind for scheduling -- i.e., TM rather than the observer will
have to pick calibrators and calibration sequences.
1.3.4.3.1.2.2
SKA1-SYS_REQ- Absolute flux scale (useful)
2826
Absolute flux scale: The absolute flux scale shall be accurate to 3% rms.
Parent Comment General
Michael Rupen
18 August 2015
See comments on 2825.
I do like having "essential" and "useful" requirements...
1.3.4.3.1.3
SKA1-FLD-884
SKA1_Mid configuration
1.3.4.3.1.3.1
SKA1-SYS_REQ- Combined SKA1_Mid configuration.
2174
Combined SKA1 Mid Configuration. The SKA1_Mid shall have the configuration defined in the SKA1_Mid Configuration Co-ordinates document [7]
Parent Comment Proposed Change Michael Rupen
21/09/2015 7:42 am
18 August 2015
For Low, the maximum baseline is called out as a separate requirement (2817).
Page
106 of 196
This is useful because that basic parameter sets things like the maximum delay
and delay rate. I suggest adding a requirement:
SKA1_Mid maximum baseline length between dishes. The maximum
distance between SKA1_Mid (including MeerKAT) dishes shall be at most
150km.
Alternatively, if this requirement is seen as redundant, 2817 should be removed,
and the general configuration requirements should also be allocated to CSP.
1.3.4.3.2
SKA1-FLD-1503 SKA1_Mid antenna
Parent Comment Issue
adriaan peens-hough
24 August 2015
Issue 1) Missing sensitivity requirements.
The original SKA1 System Baseline Design rev 1 (SKA-TEL-SKO-DD-001)
suggested the following:
SKA1_Mid array net sensitivity:
779 m2/K for SPF band 1
1309 m2/K for SPF band 2
1309 m2/K for SPF band 3
1190 m2/K for SPF band 4
994 m2/K for SPF band 5
These array sensitivities are based on the total collecting area, of the
SKA1 Mid Array (190 dishes), excluding the MeerKAT antennas.
SKA1 System Baseline Design rev 2 (SKA-TEL-SKO-0000002) brings the above in
line with the work that's been presented at DSH CoDR & PDR so that for band 1 (for
133 SKA1 Mid dishes, excluding MeerKAT antennas):
Sensitivity increases linearly from 272 m2/K @ 350 MHz to 545 m2/K @ 650 MHz
and stays constant at this level up to 1050 MHz.
1.3.4.3.2.1
SKA1-SYS_REQ- SKA1_Mid antenna
2712
SKA1_Mid antenna. The SKA1_Mid array shall consist of 133 antennas centred in the same location as the MeerKAT array
Parent Comment General
Michael Rupen
18 August 2015
Various requirements for Mid refer to dishes or to antennas. This should
probably be made consistent.
Parent Comment Issue
21/09/2015 7:42 am
adriaan peens-hough
24 August 2015
Issue 1) Missing sensitivity requirements.
The original SKA1 System Baseline Design rev 1 (SKA-TEL-SKO-DD-001)
suggested the following:
SKA1_Mid array net sensitivity:
779 m2/K for SPF band 1
1309 m2/K for SPF band 2
1309 m2/K for SPF band 3
1190 m2/K for SPF band 4
994 m2/K for SPF band 5
Page
107 of 196
These array sensitivities are based on the total collecting area, of the
SKA1 Mid Array (190 dishes), excluding the MeerKAT antennas.
SKA1 System Baseline Design rev 2 (SKA-TEL-SKO-0000002) brings the above in
line with the work that's been presented at DSH CoDR & PDR so that for band 1 (for
133 SKA1 Mid dishes, excluding MeerKAT antennas):
Sensitivity increases linearly from 272 m2/K @ 350 MHz to 545 m2/K @ 650 MHz
and stays constant at this level up to 1050 MHz.
1.3.4.3.3
SKA1-FLD-889
Antenna RF system
1.3.4.3.3.1
SKA1-SYS_REQ- Antenna RF system.
2179
Antenna RF system. The Dish Element shall make available only a single frequency band at any one time.
Parent Comment Proposed Change Michael Rupen
18 August 2015
1.3.4.3.3.10
SKA1-FLD-898
1.3.4.3.3.10.1
SKA1-SYS_REQ- RF system sampled bandwidth band 4
2188
I suggest:
Each dish of SKA1_Mid shall produce data from at most a single frequency band
at any one time.
Allocations should be added for TM and CSP. Maybe SDP also, if they process
data when subarrays are not being used for astronomy.
RF system sampled bandwidth band 4
RF system sampled bandwidth band 4 The instantaneous bandwidth for band 4 will be 2,380 MHz and shall be sampled at least 5.0 G samples per second for each
polarisation.
Parent Comment General
Michael Rupen
18 August 2015
1.3.4.3.3.11
SKA1-FLD-899
RF system sampled bandwidth band 5
1.3.4.3.3.11.1
SKA1-SYS_REQ- RF system sampled bandwidth band 5
2189
Specifying the sampling rate at this level seems odd, and specifying a lower limit
is not very useful.
RF system sampled bandwidth band 5 The SKA_Mid, for band 5, shall digitise two separate 2.5 GHz bands for each polarisation.
1.3.4.3.3.12
SKA1-FLD-900
21/09/2015 7:42 am
RF digitisation
Page
108 of 196
1.3.4.3.3.12.1
SKA1-SYS_REQ- RF digitisation
2190
RF digitisation. Digitisation for each polarisation shall be:
•
band 1 8 bits
•
band 2 8 bits
•
band 3 6 bits
•
band 4 at least 4 bits
•
band 5 at least 2 streams of 3 bits
Parent Comment Issue
adriaan peens-hough
24 August 2015
Issue 1) The band 5 prescription is not compatible with the 98% correlation
efficiency seemingly prescribed by SKA1-SYS_REQ-2679.
Issue 2) "Digitisation" is ambiguous on two counts:
A) Does this constrain the quantization of the analogue signal, or the word length
of the samples that are transmitted to CSP? The latter is currently constrained in
the CSP-DSH ICD, which is appropriate.
B) If this constrains the quantization scheme, then it should be worded interms of
Effective Number of Bits (rather than "available number of bits"). The DSH
requirements take the latter interpretation, and uses the definition "Effective
Number of Bitsis the number of bits that an ideal Analogue-to-Digital
Converter provides between full scale input and the input-referred noise
floor, excluding harmonic distortion & spurs."
1.3.4.3.3.2
SKA1-FLD-890
RF system frequency range band 1
1.3.4.3.3.2.1
SKA1-SYS_REQ- RF system frequency range band 1
2180
RF system frequency range band 1 The array of SKA1_Mid dishes, when the band 1 capability is selected, shall operate over a frequency range from 0.35 to 1.050
GHz for each polarisation.
Parent Comment Proposed Change Michael Rupen
18 August 2015
Should also be allocated to CSP.
1.3.4.3.3.3
SKA1-FLD-891
RF system frequency range band 2
1.3.4.3.3.3.1
SKA1-SYS_REQ- RF system frequency range band 2
2181
RF system frequency range band 2. The SKA1_Mid dishes, when the band 2 capability is selected, shall operate over a frequency range from 0.95 to 1.76 GHz for
each polarisation.
Parent Comment Proposed Change Michael Rupen
18 August 2015
Should also be allocated to CSP.
1.3.4.3.3.4
SKA1-FLD-892 RF system frequency range band 3
21/09/2015 7:42 am
Page
109 of 196
1.3.4.3.3.4.1
SKA1-SYS_REQ- RF system frequency range band 3
2182
RF system frequency range band 3. The SKA1_Mid dishes, when the band 3 capability is selected, shall operate over a frequency range from 1.65 to 3.05 GHz for
each polarisation
Parent Comment General
1.3.4.3.3.5
SKA1-FLD-893
1.3.4.3.3.5.1
Michael Rupen
18 August 2015
RF system frequency range band 4
Should also be allocated to CSP.
SKA1-SYS_REQ- RF system frequency range band 4
2183
RF system frequency range band 4. The SKA1_Mid dishes, when the band 4 capability is selected, shall operate over a frequency range from 2.80 to 5.18 GHz for
each polarisation
Parent Comment Proposed Change Michael Rupen
18 August 2015
1.3.4.3.3.6
SKA1-FLD-894 RF system frequency range band 5
Should also be allocated to CSP.
1.3.4.3.3.6.1
SKA1-SYS_REQ- RF system frequency range band 5
2184
RF system frequency range band 5. The SKA1_Mid dishes, when the band 5 capability is selected, shall operate over a frequency range from 4.6 to 13.8 GHz for
each polarisation.
Parent Comment Proposed Change Michael Rupen
18 August 2015
Should also be allocated to CSP.
1.3.4.3.3.7
SKA1-FLD-895 RF system sampled bandwidth band 1
1.3.4.3.3.7.1
SKA1-SYS_REQ- RF system sampled bandwidth band 1
2185
RF system sampled bandwidth band 1. The instantaneous bandwidth for band 1 will be 700MHz and shall be sampled to at least 2.0 G samples per second for
each polarisation.
Parent Comment General
Michael Rupen
18 August 2015
Specifying the sampling rate at this level seems odd, and specifying a lower limit
is not very useful.
General
adriaan peens-hough
24 August 2015
I agree this is somewhat clumsy, but we seem to have consensus on how this
has been translated into the DSH requirements.
Note that SYS_REQ-2185 – 2189 touch on three related but different aspects:
21/09/2015 7:42 am
Page
110 of 196
firstly it prescribes that the entire specified bandwidth must be sampled
instantaneously; secondly that all signals across the specified band must be
unambiguously represented in the output and thirdly and somewhat indirectly this
also places constraints on the data rates rates going out of the dish. Data rates
are constrained in the CSP-DSH ICD, so that's OKA. Details of the internal
sampling constraints are derived as part of the DSH detail design to meet these
requirements as well as technology constraints.
1.3.4.3.3.8
SKA1-FLD-896
RF system sampled bandwidth band 2
1.3.4.3.3.8.1
SKA1-SYS_REQ- RF system sampled bandwidth band 2
2186
RF system sampled bandwidth band 2. The instantaneous bandwidth for band 2 will be 810 MHz and shall be sampled to at least 2.0 G sample per second for each
polarisation.
Parent Comment General
Michael Rupen
18 August 2015
Specifying the sampling rate at this level seems odd, and specifying a lower limit
is not very useful.
1.3.4.3.3.9
SKA1-FLD-897 RF system sampled bandwidth band 3
21/09/2015 7:42 am
Page
111 of 196
1.3.4.3.3.9.1
SKA1-SYS_REQ- RF system sampled bandwidth band 3
2187
RF system sampled bandwidth band 3 The instantaneous bandwidth for band 3 will be 1,403 MHz and shall be sampled to at least 5.0 G samples per second for
each polarisation
Parent Comment General
Michael Rupen
18 August 2015
1.3.4.3.4
SKA1-FLD-905
SKA1_Mid Correlation
1.3.4.3.4.1
SKA1-FLD-1823 Auto-correlation spectra
1.3.4.3.4.1.1
SKA1-SYS_REQ- SKA1_Mid autocorrelation spectra
3036
Specifying the sampling rate at this level seems odd, and specifying a lower limit
is not very useful.
SKA1_Mid autocorrelation spectra. SKA1-Mid, when commanded, shall generate autocorrelation spectra from any or all antennas within a subarray.
Parent Comment Proposed Change Michael Rupen
18 August 2015
A slight modification of the comments on 3035:
Need to specify the characteristics of the autocorrelation spectra. Suggested rewording:
For each subarray with Observing Mode other than IDLE, SKA1_Mid shall
deliver full polarization autocorrelation spectra, with characteristics matching
those of the cross-correlation spectra, from any subset of individual antennas
within that subarray.
This still needs some work -- intent is that the autos match the CURRENT crosscorr'ns in frequency coverage and channelization, i.e., you don't get to do autos
like wideband imaging mode while doing crosses in spectral zoom mode. Also
we shouldn't have "etc." in a requirement ;)
1.3.4.3.4.1.2
SKA1-SYS_REQ- SKA1_Mid autocorrelation calibration
3046
SKA1_Mid autocorrelation calibration. The SKA1_Mid shall use crosscorrelation spectra to calibrate autocorrelation spectra
Parent Comment Issue
1.3.4.3.4.1.3
Michael Rupen
18 August 2015
As 3047:
If auto-correlations are to be used scientifically, there should be many more
requirements here -- e.g., bandpass stability, ability to perform long integrations,
etc.
SKA1-SYS_REQ- SKA1_Mid Continuum Imaging
3038
21/09/2015 7:42 am
Page
112 of 196
SKA1_Mid Continuum Imaging. The SKA1_Mid, when commanded, shall provide full Stokes polarisation products (I, Q, U, V) as part of Continuum Imaging.
Parent Comment Proposed Change Michael Rupen
18 August 2015
This should apply to ALL observing modes, not just Continuum Imaging (e.g.,
spectral line, zoom).
1.3.4.3.4.2
SKA1-FLD-1341 SKA1_Mid spectral resolution
1.3.4.3.4.2.1
SKA1-SYS_REQ- SKA1_Mid transition band for adjacent frequency channels
2196
SKA1_Mid transition band for adjacent channels. The SKA1_Mid shall have a transition band for adjacent frequency channels that is monotonically decreasing
from -3 dB at the channel edge, to -60 dB at the next adjacent channel centre frequency.
Parent Comment General
Wallace Turner
10 July 2015
CSP comment
This needs to be clarified if it is each or sum of all. Break into two requirements?
If sum of all then it needs to be a different number. Should use white noise case?
The spec point really drives the noise floor up.
This may need an RFI inter-mod products requirement.
This should not be wrt "noise"...just leakage. -60dB needs to be revisited with
Peter's document.
CSP Michael Rupen comment
Changed priority from blank to High -- need to understand RFI environment and
its implications as soon as possible.
Parent Comment General
Wallace Turner
10 July 2015
Parent Comment General
Wallace Turner
10 July 2015
Reply to CSP:
Suggest the requirement and title is ammended to:
SKA1_Low maximum leakage power between adacent frequency channels
When operating across the full instantaneous bandwidth, spectral data products
at the finest resolution of the SKA1_Low shall have a transition band for adjacent
frequency channels that is monotonically decreasing from -3 dB at the channel
edge, to -60 dB at the next adjacent channel centre frequency
General
Michael Rupen
18 August 2015
Why not leave out "When operation across the full instantaneous BW"? This
should apply to spectral zoom mode as well. Can we say "FINE frequency
channels" throughout, to avoid confusion?
Note requirement here should be on SKA1_Mid.
I believe this is a requirement only for visibility spectra (incl. auto-correlations),
not on tied-array beams.
1.3.4.3.4.2.2
SKA1-SYS_REQ- SKA1_Mid maximum leakage power for non-adjacent frequency channels
2803
21/09/2015 7:42 am
Page
113 of 196
SKA1_Mid maximum leakage power for non-adjacent frequency channels. The maximum noise leakage power for SKA1_Mid shall be less than 60 dB for nonadjacent zoom channels.
Parent Comment General
Wallace Turner
10 July 2015
Michael Rupen:
SKA1_Mid maximum leakage power for non-adjacent frequency channels. The
SKA1_Mid, for each sub-array, shall have a maximum noise leakage power from
non-adjacent frequency channels better than -60 dB.
And is now:
SKA1_Mid maximum leakage power for non-adjacent frequency channels. The
maximum noise leakage power for SKA1_Mid shall be less than 60 dB for nonadjacent zoom channels.
Losing the reference to sub-arrays is a Good Thing. But:
The rationale says this should apply to both zoom and non-zoom channels, but
“zoom” is in here explicitly!
“Less than 60dB” makes Brent think you don’t care about leakage unless you
amplify the leaking signal by more than 1e6 (!). “Better than -60dB” makes much
more sense, and is consistent with 2196.
So I’m assuming you actuall want something like:
SKA1_Mid maximum leakage power for non-adjacent frequency channels. The
maximum noise leakage power for SKA1_Mid shall be better than -60 dB for
non-adjacent fine frequency channels.
Parent Comment Proposed Change Michael Rupen
18 August 2015
Suggest:
For each subarray, SKA1_Mid shall have a maximum noise leakage power from
non adjacent frequency channels better than -60 dB.
But this too has issues -- the CSP L2 comments are as follows:
1.
2.
3.
1.3.4.3.4.2.3
This needs to be clarified if it is the leakage from each channel or the sum
of all. Break into two requirements? If sum of all then it needs to be a
different number. Should use white noise case? The spec point really
drives the noise floor up.
This may require an RFI inter-mod products requirement.
This should not be wrt "noise"...just leakage power. -60dB needs to be revisited with Peter's document.
SKA1-SYS_REQ- SKA1_Mid fine frequency channel amplitude variation
21/09/2015 7:42 am
Page
114 of 196
2805
SKA1_Mid fine frequency channel amplitude variation. For SKA1_Mid, the total amplitude response variation across frequency channels shall be within + 0.01 dB.
Parent Comment General
Michael Rupen
18 August 2015
See 2811 comments, reproduced here for ease of referece:
1.
2.
3.
4.
5.
6.
7.
1.3.4.3.4.2.4
I believe this should apply only to the visibility spectra, not to the beamformed channels.
Should specify "FINE frequency channels", as in the next requirement
(2804).
Should say this is post-calibration (right?).
Within CSP we are interpreting this as a requirement that the power
measured from a single tone should remain constant as the tone is swept
across spectral channels, even when the tone lies at a channel boundary.
Should this also be allocated to DSH? ADCs could potentially make this
difficult.
Needs a system-level allocation.
"Nominal" is a bit vague...I was wondering whether this applied only at the
center of the beam, for instance, but that got me wondering whether
"nominal" meant "including expected off-axis problems due to changing
beam response with frequency, pointing errors, etc.". Would be nice to
clarify this...as it stands it sounds like a motherhood statement, leaving it to
the elements to do their best.
SKA1-SYS_REQ- SKA1_Mid fine frequency channel band edge
2804
SKA1_Mid fine frequency channel band edge. The fine frequency channels for the SKA1_Mid shall have a -3dB transition band amplitude at the channel band
edge.
Parent Comment Proposed Change Michael Rupen
18 August 2015
See 2812 comments:
Must define the channel band edge -- suggest:
The channel band edge is defined as the mid-point beween channel centre
frequencies.
Ewan suggests a tolerance on -3 dB of +/- 0.01 dB.
1.3.4.3.4.2.5
SKA1-FLD-1870 Full bandwidth resolution
1.3.4.3.4.2.5.1
SKA1-SYS_REQ- SKA1_Mid spectral channels
21/09/2015 7:42 am
Page
115 of 196
2195
SKA1_Mid spectral channels. The SKA1_Mid shall provide up to 65,536 + 20% linearly spaced spectral channels across the sampled bandwidth of each band.
Parent Comment General
Wallace Turner
10 July 2015
Parent Comment General
Wallace Turner
10 July 2015
Parent Comment General
Wallace Turner
10 July 2015
CSP Michael Rupen
Note Brent's re-wording in Level 2 requirements, which should probably lead to
an ECP for Level 1. Key point is to specify an acceptable range of channel width
(preferably in frequency, e.g., kHz, but velocity [km/s] also OK), independently
for each band.
Changed priority from High to blank -- we can and must proceed with reasonable
L2 requirements without knowing the answer here.
Parent Comment General
Wallace Turner
10 July 2015
CSP comment
"Change verification method from ""Test"" to ""Demonstration"".
Justifcation: Don’t need any dedicated test instrumentation for verification,
adhere to verification method definitions in L1 Requirements document.
Parent Comment General
Wallace Turner
10 July 2015
CSP comment
Suggest to further clarify the requirement definition by using the following
Jul 10, 2015, 8:03 AM Page 99 of 157
description:
SKA1_Mid channelisation. The SKA1_Mid channelisation for each sub array
shall provide up to 256, 000 linearly spaced frequency channels across the total
sampled bandwidth of each band. For Band 5 the total sampled bandwidth is 5
GHz (2 * 2.5 GHz)."
Parent Comment General
Wallace Turner
10 July 2015
CSP comment TIM#3
Wallace: Switch to some flexibility on channels (of order 10%) is OK. TBC but
proceed with this until and unless officially denied.
Exact numbers are an issue throughout, and should be given some leeway
unless those numbers are absolute requirements.
Changed priority to Low -- this does not seem to be controversial.
21/09/2015 7:42 am
CSP comment
CSP requests that the SKAO produce an ECP which is consistent with the CSP
omnibus signal chain comment in Jama (i.e. regarding BW delivered to the CSP,
range of required spectral channel widths etc). In addition, any consideration for
zoom modes should be addressed.
For each band the bandwidth, number of channels and the frequency resolution
have to be specified in a clear, correct and concise manner.
CSP TIM#2
See also TIM#2 comment on Action 18 (dated 2014-05-02).
Page
116 of 196
Parent Comment General
Wallace Turner
10 July 2015
MC
form telescope prospective the number of channels is meant to be user/scientist
consumable. Each telescope has to be able to provide spectral line and
continuum mode and thus the number of channel may be user selectable from
few up to the maximum.
In this regards a possible requirement improvement is to specify the granularity
of the number of channel or the channel width as user configurable parameter.
The root cause of the CSP comment seems to be a lack of "budget allocation"
between CSP and SDP. A possible work around might be a comment on the
requirements clarifying the overall spectral line and continuum observation mode
strategy.
Parent Comment General
Wallace Turner
10 July 2015
AIV comment
Suggest to further clarify the requirement definition by using the following
description:
SKA1_Mid channelisation. The SKA1_Mid channelisation for each sub array
shall provide up to 256, 000 linearly spaced frequency channels across the total
sampled bandwidth of each band. For Band 5 the total sampled bandwidth is 5
GHz (2 * 2.5 GHz).
Parent Comment General
Wallace Turner
10 July 2015
Reply to comments
The requirement title and wording needs to change to bring this in line with L1.
This also includes a trade off space in frequency to allow over sampling earlier in
the frequency chain.
Action update requirement to:
When operating across the full instantaneous bandwidth, spectral data products
of the SKA1_Low telescope shall have a highest frequency resolution of between
3.6 kHz to 5.6 kHz configurable to lower frequency resolutions in powers of
two(need to confirm powers of 2)
General
Michael Rupen
18 August 2015
Looks like this was copied over from Low -- the Mid channels at the upper
frequencies would be much wider. Is this comment still active?
Parent Comment Proposed Change Michael Rupen
18 August 2015
The introduction of some leeway into these exact numbers is most welcome, but
leads to the need for an additional requirement that the channelization and
frequency response of the telescope not change over time. This is remarkably
hard to state as a requirement -- so far the best I've got is:
SKA1_Mid Channelization Stability. The spectral and temporal response of the
individual SKA1_Mid spectral channels shall not change in any measurable way
unless explicitly commanded to do so.
The "explicitly commanded" part is needed for zoom mode of course, but also for
application of delay models and the like.
1.3.4.3.4.2.6
SKA1-FLD-1822 Higher spectral resolution over limited bandwidth
21/09/2015 7:42 am
Page
117 of 196
1.3.4.3.4.2.6.1
SKA1-SYS_REQ- SKA1_Mid zoom windows.
2968
SKA1_Mid zoom windows. SKA1_Mid, when commanded, shall provide up to four zoom windows each with continuous bandwidth selected from within 10% one of
the following values: 4MHz, 8MHz, 16 MHz, 32MHz 64MHz, 128MHz and 256MHz.
Parent Comment Proposed Change Michael Rupen
18 August 2015
CSP suggested wording:
SKA1_Mid, for each subarray in zoom mode, shall provide up to four zoom
windows, each with bandwidth selected independently from values within 10% of
4 MHz, 8 MHz, 16 MHz, 32 MHz, 64 MHz, 128 MHz, and 256 MHz.
Note suggested "slop" in BW -- we want these to be multiples of the coarse
channels.
Parent Comment Issue
4 September 2015
The widest bandwidths may not be possible without major expense and/or risk,
especially for the most challenging observing bands (esp. Band 5). Bands 1 and
2 are easier but may still be difficult. Suggest splitting this requirement by band,
and specifying (or having a joint scientific/designer discussion of) what is really
required, and what might realistically be done. At this stage in the design we
need a much closer connection between scientists and designers -- 10%
changes in the design may give the astronomers 90% of what they want, but it's
almost impossible to make those trade-offs when communication is solely
through the requirements.
1.3.4.3.4.2.6.2
Michael Rupen
SKA1-SYS_REQ- SKA1_Mid zoom window centre frequency.
2969
SKA1_Mid zoom window centre frequency. Zoom windows for SKA1_Mid shall have centre frequencies independently selectable from each other with a step size
within 10% of 1MHz such that the full window is contained within the available frequency band
Parent Comment Proposed Change Michael Rupen
1.3.4.3.4.2.6.3
18 August 2015
Should be "...contained within the available digitized frequency band", since we
don't get the entirety of Band 5.
SKA1-SYS_REQ- SKA1_Mid zoom window channels.
2970
SKA1_Mid zoom window channels. Zoom windows for SKA1_Mid shall each provide 16384 equally spaced frequency channels across each of the zoom windows.
Parent Comment Proposed Change Michael Rupen
1.3.4.3.4.2.6.4
18 August 2015
Exact channelization numbers are overly restrictive on the design -- suggest
making this "at least 16384 channels", or giving a range of number of channels
or channel spacing (cf. 2148).
SKA1-SYS_REQ- SKA1_Mid continuum with zoom windows.
2971
SKA1_Mid continuum with zoom window. When generating zoom windows, SKA1_Mid shall simultaneously generate a continuous continuum spectrum across the
digitisaed frequency band(s) with an evenly spaced frequency resolution of 1MHz within a tolerance of 10%.
21/09/2015 7:42 am
Page
118 of 196
Parent Comment General
1.3.4.3.4.2.6.5
Michael Rupen
18 August 2015
1.
2.
"digitaesed" is mis-spelled
"Evenly spaced frequency resolution" stands in contrast to other
channelization requirements, which are phrased in terms of equally spaced
frequency channels (e.g., 2977). Is this difference significant? If so,
frequency resolution has to be defined (e.g., FWHM of frequency
response).
Brent says "may need more wiggle room for Band 5 -- would prefer 0.5 MHz to
few-ish MHz for the continuum resolution."
SKA1-SYS_REQ- SKA1_Mid zoom window noise leakage power.
3050
SKA1_Mid zoom window noise leakage power. The maximum noise leakage into SKA1_Mid zoom window channels from other frequencies outside the
window shall be less than 60dB
1.3.4.3.4.2.6.6
SKA1-SYS_REQ- SKA1_Mid Overlapped window amplitude response.
3051
SKA1_Mid Overlapped window amplitude response. The amplitude response variation across the full concatenated bandwidth of overlapped zoom windows of
the same frequency resolution shall be within + 0.01 dB from the nominal.
Parent Comment General
Michael Rupen
18 August 2015
1.3.4.3.4.3
SKA1-FLD-1467 SKA1_Mid correlation signal to noise
See comments on 2811.
1.3.4.3.4.3.1
SKA1-SYS_REQ- SKA1_Mid correlation signal to noise
2679
SKA1_Mid correlation signal to noise. The SKA1_Mid correlation, for the same subarray, shall not degrade the Signal to Noise ratio by more than 2% compared to
ideal analogue correlation.
Parent Comment General
adriaan peens-hough
24 August 2015
Refer to the issue raised against SKA1-SYS_REQ-2190
1.3.4.3.4.4
SKA1-FLD-1343 SKA1_Mid correlation integration time
The base line design suggests two separate ranges of baselines with associated dump rates. This is problematic for Imaging processing and not included in the SKA1
requirements
1.3.4.3.4.4.1
SKA1-SYS_REQ- SKA1_Mid correlation integration period.
2197
SKA1_Mid correlation integration period. The SKA1_Mid shall have independently configurable visibility integration period from a maximum integration time
of 1.4s to a minimum of 0.14s for each subarray.
Parent Comment General
Wallace Turner
10 July 2015
Parent Comment General
21/09/2015 7:42 am
Wallace Turner
10 July 2015
Rev6 comment Tyler Bourke
My notes suggest the correct value for 150 km is 0.10 s.
Rev6 comment Wallace Turner
Page
119 of 196
Reply to Tyler: In summary of our conversation, the updated integration rates are
all right to publish for the rbs update. However the comment is to be retained so
that a more detailed analysis can be provided at a later date such hat ever one is
in agreement with with the assumptions.
It is also assumed that baseline averaging is not necessary with the reduced
channel count.
Parent Comment General
Wallace Turner
10 July 2015
Reply to Tyler,
Design space to allow
The SKA1_Mid telescope shall have a minimum visibility integration period of
0.14s individually configurable to longer periods in powers of two up to a factor of
16 for each sub-array.
General
Michael Rupen
18 August 2015
Suggest:
The minimum visibility integration period for each SKA1_Mid subarray shall be
independently configurable, with allowed values of {1, 2, 4, 8, 16} times 0.14
seconds.
Personally I would make this any integer up to, say, 40 times 0.14 seconds. I see
no reason for powers-of-2 here, and note that EVLA observers frequently "tune"
their integration time to match expected weather conditions and data rate limits.
Note that, if we are not archiving visibilities, this is not really an L1 requirement -the integration time is purely an internal matter, set by requirements on fidelity
(which don't yet exist), astrometry (ditto), and the like.
1.3.4.3.4.5
SKA1-FLD-1398 SKA1_Mid correlator Pulsar binning
1.3.4.3.4.5.1
SKA1-SYS_REQ- SKA1_Mid Pulsar phase binning
2616
SKA1_Mid Pulsar phase binning.The SKA1_Mid, for each subarray, shall allow for pulse phase-resolved observations supporting the product of the number of
phase bins, channel and polarisation products up to 262,144 (e.g. 4 x 65,536).
1.3.4.3.4.5.2
SKA1-SYS_REQ- SKA1_Mid Pulsar phase bin width
2830
SKA1_Mid Pulsar phase bin width. The SKA1_Mid shall be capable of providing pulsar phase bin widths with a time resolution of better than 10us.
1.3.4.3.4.5.3
SKA1-SYS_REQ- SKA1_Mid Pulsar phase bin synchronisation
2831
SKA1_Mid Pulsar phase bin synchronisation. The SKA1_Mid shall be capable of synchronising phase bins to the ephemeris to limit drift to less than 10% of the
selected bin width within the selected correlator integration period.
21/09/2015 7:42 am
Page
120 of 196
1.3.4.3.4.5.4
SKA1-SYS_REQ- SKA1_Mid Phase bin averaging time
2835
SKA1_Mid Phase bin averaging time. The SKA1_Mid phase bin averaging time shall be constrained to limit the output data rate to at most the single bin
configuration output data rate.
1.3.4.3.4.6
SKA1-FLD-1560 Inclusion of MeerKAT into SKA1_Mid Correlator
1.3.4.3.4.6.1
SKA1-SYS_REQ- Inclusion of MeerKAT into SKA1_Mid correlator
2740
Inclusion of MeerKAT into SKA1_Mid correlator. The SKA1_Mid correlator shall be capable of forming real time cross correlation products from all antenna within
the SKA1_Mid combined array including MeerKAT antennas.
1.3.4.3.5
SKA1-FLD-1478 SKA1_Mid VLBI
The VLBI community indicate there should be at least 4 beams generated for VLBI usage: one for target and three for calibrators to establish calibration plane.
1.3.4.3.5.1
SKA1-SYS_REQ- SKA1_Mid VLBI beam number
2689
SKA1_Mid VLBI beam number. SKA1_Mid shall be capable of producing up to four VLBI beams
Title should be "SKA1_Mid VLBI number of beams".
Parent Comment Proposed Change Michael Rupen
18 August 2015
Suggest re-wording for subarrays:
SKA1_Mid VLBI number of beams. Upon command, SKA1_Mid shall produce
a total of up to four VLBI beams distributed across up to four subarrays which
are in VLBI mode.
Parent Comment Proposed Change Michael Rupen
18 August 2015
Should combine with 2853 (q.v.)
1.3.4.3.5.10
SKA1-SYS_REQ- SKA1_Mid VLBI relative sensitivity and coherence losses
2851
SKA1_Mid VLBI relative sensitivity and coherence losses. The SKA1_Mid beamformer shall be able to weight the antenna inputs into the tied-array sums based
on relative sensitivity and coherence losses.
Parent Comment Question
Michael Rupen
18 August 2015
Title makes it appear this applies only to VLBI beams, while requirement text
suggests this applies to all tied-array beams. Which is it?
1.3.4.3.5.11
SKA1-SYS_REQ- SKA1_Mid VLBI configurability
2852
21/09/2015 7:42 am
Page
121 of 196
SKA1_Mid VLBI configurability. SKA1_Mid shall be able to change the pointing, centre frequency, and bandwidth of the individual tied-array beams within a single
observing schedule.
Parent Comment Question
Michael Rupen
18 August 2015
Title makes it appear this applies only to VLBI beams, while requirement text
suggests this applies to all tied-array beams. Which is it?
1.3.4.3.5.12
SKA1-SYS_REQ- SKA1_Mid VLBI configurability
2853
SKA1_Mid VLBI configurability. SKA1_Mid shall be capable of selecting, through configuration, 1, 2, 3, or 4 separate VLBI specific beams, each with independently
selectable centre frequency, bandwidth, frequency resolution and pointing.
Parent Comment General
Wallace Turner
10 July 2015
Rev6A comment Mark Waterson
if this is not intended to mean that the reconfiguration for all beams occurs
simultaneously, it needs to specify the differential latency between any
reconfigurations
Parent Comment General
Wallace Turner
10 July 2015
Reply
Whether simultaneous or not is a design decision and as such is not
L1.However, suggest requirement is reworded:
SKA1_Mid shall reconfigure the centre frequency, frequency band, and
bandwidth for each tied-array beam, in less than 30 seconds.
General
Michael Rupen
18 August 2015
Isn't this 2854? We still need 2853, a requirement saying that the centre freq.
etc. are independently selectable for each of the four VLB beams.
Should combine with 2689 (q.v.).
Parent Comment Proposed Change Michael Rupen
18 August 2015
1.3.4.3.5.13
SKA1-SYS_REQ- SKA1_Mid VLBI configurability
2854
SKA1_Mid VLBI configurability. SKA1_Mid shall be capable of reconfiguring the centre frequency, frequency band, and bandwidth for each tied-array beam, in less
than 30 seconds.
1.3.4.3.5.14
SKA1-SYS_REQ- SKA1_Mid VLBI spectral resolution
2855
SKA1_Mid VLBI spectral resolution. SKA1_Mid shall be able to generate VLBI beams with a spectral resolutions different from the spectral resolution used for
imaging within the same VLBI subarray
1.3.4.3.5.15
SKA1-SYS_REQ- SKA1_Mid VLBI channel width
2856
SKA1_Mid VLBI channel width. SKA1_Mid shall be able to generate VLBI beam data with a selectable channel width of: 512MHz, 256 MHz, 128MHz, 64MHz,
32MHz, 16MHz, 4MHz or 1MHz.
1.3.4.3.5.16
SKA1-SYS_REQ- SKA1_Mid VLBI imaging and beamforming
2857
SKA1_Mid VLBI imaging and beamforming SKA1_Mid shall be able to simultaneously generate imaging data using all antennas in a VLBI subarray, as well as
generating the VLBI beams.
Parent Comment Proposed Change Michael Rupen
18 August 2015
Need details on the imaging data available when doing VLBI. Here is one
option:
21/09/2015 7:42 am
Page
122 of 196
For each subarray in VLBI observing mode, SKA1_Mid shall simultaneously
generate both VLBI beams and imaging data. This imaging data shall include all
polarization products and all baselines (and autocorrelations) for all antennas in
that subarray, with a spectral resolution no worse than 1 MHz, covering at least
the larger of 100 MHz or the frequency range(s) covered by all VLBI beam(s)
associated with the subarray.
1.3.4.3.5.17
SKA1-SYS_REQ- SKA1_Mid VLBI spectral line and time domain observation
2859
SKA1_Mid VLBI spectral line and time domain observation SKA1_Mid shall be able to generate VLBI beams optimised for either spectral line observations (to
mitigate spectral leakage) or time domain observations (to mitigate time smearing)
Parent Comment Question
Michael Rupen
18 August 2015
This should be made quantitative -- what are the actual requirements on spectral
leakage and time smearing, in these two cases?
Of course we also need such requirements for the regular visibility data.
1.3.4.3.5.18
SKA1-SYS_REQ- SKA1_Mid VLBI beams and subarrays
2860
SKA1_Mid VLBI beams and subarrays. SKA1_Mid shall be able to allocate individual VLBI beams to different subarrays.
1.3.4.3.5.19
SKA1-SYS_REQ- SKA1_Mid VLBI array diameter
2861
SKA1_Mid VLBI array diameter. SKA1_Mid shall be able to generate VLBI beams from subarrays with receptors separated by up to 20km.
Parent Comment Proposed Change Michael Rupen
18 August 2015
Suggest:
For each subarray in VLBI mode, SKA1_Mid shall form VLBI beams from a
selectable subset of any or all receptors within that subarray which are separated
by at most 20km.
1.3.4.3.5.2
SKA1-SYS_REQ- SKA1_Mid VLBI array diameter
2759
SKA1_Mid VLBI array diameter. SKA1_Mid shall be able to generate VLBI beams from subarrays with receptors separated by up to 100km.
Parent Comment Proposed Change Michael Rupen
18 August 2015
Suggest:
For each subarray in VLBI observing mode, SKA1_Mid shall form VLBI beams
from any and all receptors within the subarray which are separated by no more
than 100 km.
1.3.4.3.5.3
SKA1-SYS_REQ- SKA1_Mid VLBI centre frequency
2760
SKA1_Mid VLBI centre frequency. SKA1_Mid shall be able to form a VLBI beam with a 0.01MHz step selectable centre frequency within the boundaries of the
defined frequency bands for SKA1_Mid.
Parent Comment Proposed Change Michael Rupen
18 August 2015
Refine to ensure VLB band is entirely within the digitised band (for Band 5):
For each subarray in VLBI mode, the SKA1_Mid shall form VLBI beams with a
21/09/2015 7:42 am
Page
123 of 196
centre frequency which can be tuned to an accuracy of 0.01 MHz or better, such
that the processed VLBI beam bandwidth falls entirely within the digitised
band(s).
1.3.4.3.5.4
SKA1-SYS_REQ- SKA1_Mid VLBI beam bandwidth
2761
SKA1_Mid VLBI beam bandwidth. SKA1_Mid VLBI beamforming shall have a contiguous processing bandwidth up to the full bandwidth of the selected band
Parent Comment Question
Michael Rupen
18 August 2015
Presumably this should be limited to a single 2.5 GHz "chunk" for Band 5?
1.3.4.3.5.5
SKA1-SYS_REQ- SKA1_Mid VLBI beamformer S/N performance
2762
SKA1_Mid VLBI beamformer S/N performance. SKA1_Mid VLBI beamforming shall have the Signal to Noise ratio by more than 98% compared to an ideal
analogue beam former.
Parent Comment Proposed Change Michael Rupen
18 August 2015
If the 98% is intended to include coherence losses due to poor calibration and
SNR losses due to incorrect antenna weights, this should also be allocated to
TM and SDP. If this is not the intent, this requirement should be re-phrased:
The SKA1_Mid, when forming VLBI beams, shall not degrade the signal-to-noise
to less than 98% of that achievable by an ideal analogue beam-former, given the
same digitized inputs and calibration.
Of course this would really be an L2 requirement.
Also in this case, where are the requirements on the accuracy of such
calibration/weighting?
1.3.4.3.5.6
SKA1-SYS_REQ- SKA1_Mid VLBI store the time-dependent antenna weights
2847
SKA1_Mid VLBI store the time-dependent antenna weights. SKA1_Mid shall be able to store the time-dependent antenna weights used for each tied-array beam
sum
1.3.4.3.5.7
SKA1-SYS_REQ- SKA1_Mid VLBI timestamp accuracy
2848
SKA1_Mid VLBI timestamp accuracy. SKA1_Mid shall be able to generate data from the VLBI beams with samples traceable to a timestamp with an accuracy of 1 n
sec or better.
1.3.4.3.5.8
SKA1-SYS_REQ- SKA1_Mid VLBI beams sampling rate
2849
SKA1_Mid VLBI beams sampling rate. SKA1_Mid shall be able to output VLBI beams with a sampling rate selectable between Nyquist and oversampled rates for
the selected bandwidth.
Parent Comment Proposed Change Michael Rupen
18 August 2015
Need some idea of what oversampled rates are required. Suggest:
In VLBI mode, SKA1_Mid shall produce VLBI beams with a sampling rate
selectable between Nyquist and at least factor 2 oversampled rates for the
selected bandwidth.
1.3.4.3.5.9
SKA1-SYS_REQ- SKA1_Mid VLBI beamforming
2850
21/09/2015 7:42 am
Page
124 of 196
SKA1_Mid VLBI beamforming. SKA1_Mid shall be able to allocate antennas to be included in, or excluded from, individual tied-array beams.
Parent Comment Proposed Change Michael Rupen
18 August 2015
Suggest:
For each subarray in VLBI mode, SKA1_Mid shall be able to allocate antennas
to be included in, or excluded from, individual tied-array VLBI beams.
1.3.4.3.6
SKA1-FLD-907 SKA1_Mid Pulsar Search
1.3.4.3.6.1
SKA1-FLD-1559 Pulsar search processing bandwidth
1.3.4.3.6.1.1
SKA1-SYS_REQ- SKA1_Mid Pulsar search bandwidth
2767
SKA1_Mid Pulsar Search bandwidth. SKA1_Mid, shall have a maximum Pulsar Search bandwidth of no less than 300 MHz.
Parent Comment Proposed Change Michael Rupen
18 August 2015
1.3.4.3.6.10
SKA1-FLD-1544 Pulsar search beams and bandwidth
1.3.4.3.6.10.1
Eliminate the comma after "CSP_MId".
SKA1-SYS_REQ- SKA1_Mid Pulsar search beams and bandwidth
2756
SKA1_Mid Pulsar search beams and bandwidth. The SKA1_Mid, when commanded, shall offset the centre frequency of the Pulsar Search of operator specified
beams by an operator specified multiple of the Pulsar Search bandwidth, provided that the entire frequency range lies within the current subarray band.
Parent Comment Proposed Change Michael Rupen
18 August 2015
1.3.4.3.6.11
SKA1-FLD-1349 Number of beams: Pulsar survey
1.3.4.3.6.11.1
SKA1-SYS_REQ- Number of beams: SKA1_Mid Pulsar Search
2203
See 2755 comments.
Number of beams: SKA1_Mid Pulsar search. SKA1_Mid, shall concurrently perform the Pulsar Search on a total of up to 1500 independently steerable beams
across all subarrays.
Parent Comment Proposed Change Michael Rupen
21/09/2015 7:42 am
18 August 2015
How about:
SKA1_Mid shall concurrently perform the Pulsar Search on a total of up to 1500
independently steerable beams, each of which may be assigned to any subarray
which is in the pulsar search mode.
Page
125 of 196
1.3.4.3.6.12
SKA1-FLD-1351 Beam-former S/N: Pulsar survey
The signal to noise, S/N, performance includes all losses including but limited to coherence, quantisation, scalloping but not RFI
Parent Comment Question
Michael Rupen
18 August 2015
What is "pulsar survey"? Should this be "pulsar search"?
"Including but limited to" is odd -- is this "including but NOT limited to", or what?
1.3.4.3.6.12.1
SKA1-SYS_REQ- SKA1_Mid Beamforming S/N pulsar search
2205
SKA1_Mid Beamformer S/N pulsar search. The SKA1_Mid, when forming beams for the Pulsar Search, shall not degrade the signal-to-noise to less than 98% when
compared to an ideal analogue beam-former.
Parent Comment Proposed Change Michael Rupen
18 August 2015
1.3.4.3.6.13
SKA1-FLD-1546 Pulsar search beamformer output
1.3.4.3.6.13.1
SKA1-SYS_REQ- SKA1_Mid Pulsar Search output.
2897
f the 98% is intended to include coherence losses due to poor calibration and
SNR losses due to incorrect antenna weights, this should also be allocated to
TM and SDP. If this is not the intent, this requirement should be re-phrased:
The SKA1_Mid, when forming pulsar search beams, shall not degrade the
signal-to-noise to less than 98% of that achievable by an ideal analogue beamformer, given the same digitized inputs and calibration.
Of course this would really be an L2 requirement.
Also in this case, where are the requirements on the accuracy of such
calibration/weighting?
SKA1_Mid Pulsar search output. SKA1_Mid, when performing the Pulsar Search, shall output Pulsar Candidates and Non-imaging Transient Candidates as defined
in TBD.
Parent Comment Proposed Change Michael Rupen
18 August 2015
1.3.4.3.6.14
SKA1-FLD-1547 Pulsar search number of channels
1.3.4.3.6.14.1
SKA1-SYS_REQ- SKA1_Mid Pulsar Search number of channels
2754
Again we need some convention for "performing the Pulsar Search". How about
When in pulsar search mode, the SKA1_Low shall report...
(I also really hate to use "output" as a verb ;)
SKA1_Mid Pulsar search number of channels. SKA1_Mid shall use 4096 frequency channels for the Pulsar Search
Parent Comment Question
Michael Rupen
18 August 2015
1.3.4.3.6.15
SKA1-FLD-1873 SKA1_Mid Pulsar search sampling interval
21/09/2015 7:42 am
Is this really a requirement at Level 1?
Page
126 of 196
1.3.4.3.6.15.1
SKA1-SYS_REQ- SKA1_Mid Pulsar search sampling interval
2900
SKA1_Mid Pulsar search sampling interval. SKA1_Mid shall have a minimum sampling interval for the Pulsar Search of no greater than 64 microseconds.
1.3.4.3.6.16
SKA1-FLD-1874 SKA1_Mid Pulsar search configurability
1.3.4.3.6.16.1
SKA1-SYS_REQ- SKA1_Mid Pulsar Search Configurability 1
2901
SKA1_Mid Pulsar search configurations. SKA1_Mid, when commanded, shall perform the Pulsar Search with a configurable sampling interval up to at least 4 times
the minimum sampling interval.
Parent Comment Proposed Change Michael Rupen
18 August 2015
Suggest re-wording:
When in pulsar search mode, the SKA1_Mid shall search for pulsars using a
configurable...
Parent Comment General
18 August 2015
Strange to have "up to at least". CSP interpretation is that "Up to at least 4
times" means you have to be able to configure to n*the sampling interval, with
n={1,2,3,4}, and you *can* implement the capability of going to n=5 or higher, if
you feel like it.
1.3.4.3.6.16.2
Michael Rupen
SKA1-SYS_REQ- SKA1_Mid Pulsar Search Configurability 2
2902
SKA1_Mid Pulsar search configurations. SKA1_Mid, when commanded, shall perform the Pulsar Search with a configurable bandwidth down to 0.25 times the
minimum sampling interval.
Parent Comment General
Wallace Turner
22 July 2015
Evan Keane/ Mike Keith:
Cut and paste error in the requirement wording
SKA1_Mid, when commanded, shall perform the Pulsar Search with a configurable
bandwidth down to 0.25 times the maximum SKA1-Mid pulsar search bandwidth.
21/09/2015 7:42 am
Page
127 of 196
Parent Comment Proposed Change Michael Rupen
18 August 2015
Should this be:
When in pulsar search mode, SKA1_Mid shall perform the Pulsar Search with a
configurable bandwidth down to 0.25 times the inverse of the minimum sampling
interval.
Ah, I see Evan has weighed in. If his suggestion is adopted instead, it should
probably say "0.25 times the pulsar search bandwidth", since this is configurable.
1.3.4.3.6.16.3
SKA1-SYS_REQ- SKA1_Mid Pulsar Search Configurability 3
2903
SKA1_Mid, when configuring the Pulsar Search, may restrict the choices of sampling rate, bandwidth, and their product, to be integer multiples of an internal
digitisation rate.
Parent Comment Question
Michael Rupen
18 August 2015
This requirement as worded does not make sense -- only the sampling rate can
be a multiple of the internal digitization rate. What is intended here?
Parent Comment Question
Michael Rupen
18 August 2015
Should this be allocated to TM as well, as they will do the restricting at the
observer level
1.3.4.3.6.2
SKA1-FLD-1358 Dispersion measure
1.3.4.3.6.2.1
SKA1-SYS_REQ- SKA1_Mid Dispersion Measure
2212
SKA1_Mid Dispersion Measure. SKA1_Mid, when performing the Pulsar Search, search for unaccelerated pulsars with dispersion measures from 0 to 3000 pc cm-3.
SKA1_Mid shall use sufficient dispersion measure trials such that the degradation in signal-to-noise ratio due to coarse sampling is no worse than 85% anywhere in
the dispersion measure range.
Parent Comment Proposed Change Michael Rupen
1.3.4.3.6.3
SKA1-FLD-1362 Time resolution
1.3.4.3.6.3.1
18 August 2015
Need "shall" before "...search for...".
SKA1-SYS_REQ- SKA1_Mid Pulsar Search time resolution
2216
SKA1_Mid Time resolution. The SKA1_Mid shall retain time resolution in the Pulsar Search such that any increase in sampling interval at high dispersion measure
trials does not degrade the signal-to-noise ratio below 95% compared to the maximum time resolution.
Parent Comment General
Wallace Turner
10 July 2015
Parent Comment General
Wallace Turner
10 July 2015
Parent Comment Proposed Change Michael Rupen
21/09/2015 7:42 am
18 August 2015
Rev6A comment Juande Santander-Vela
Should 800 us be 819.2 us? Or it is the 50 μs that should be 48.82 μs?
Reply to Juande,
This comment is no longer applicable as the requirement is updated as part of
ECP150004
No further action
Suggest slight re-wording:
SKA1_Mid shall retain time resolution in the Pulsar Search such that the signalPage
128 of 196
to-noise ratio for all dispersion measure trials is not degraded below 95%,
compared to that obtainable with the highest possible time resolution for the
bandwidth being searched.
Also, boldface header of this requirement should be changed to SKA1_Mid
Pulsar Search time resolution.
1.3.4.3.6.4
SKA1-FLD-1364 Pulsar search observation time
1.3.4.3.6.4.1
SKA1-SYS_REQ- SKA1_Mid Pulsar search observation time
2218
SKA1_Mid Pulsar search observation time. SKA1_Mid, when commanded, shall perform the Pulsar Search with an operator configured observation time between
180 and 1800 seconds. The SKA1_Mid may restrict the choice of observing time to be fixed multiples of the sampling interval.
Parent Comment Proposed Change Michael Rupen
Parent Comment General
Alan Bridger
18 August 2015
27 August 2015
1.3.4.3.6.5
SKA1-FLD-1365 Single pulse searches
1.3.4.3.6.5.1
SKA1-SYS_REQ- SKA1_Mid Single pulse searches
2219
Change lead-in to "When in pulsar search mode, a SKA1_Mid subarray shall..."
The phrase "operator configured observation time" implies the operator entering
said time. Is this really what is intended?
SKA1_Mid Single pulse searches. SKA1_Mid, when performing the Pulsar Search, search for individual pulses with dispersion measures from 0 to 3000 pc cm -3
and with widths from 100 microseconds to 1 second. SKA1_Mid shall use sufficient dispersion measure trials such that the degradation in signal-to-noise ration due to
coarse sampling is no worse than 85% anywhere in the dispersion measure range. SKA1_Mid shall obtain a signal-to-noise ratio for a pulse in a dedispersed timeseries that is no worse than 85% compared to using a Gaussian matched filter of the correct width.
Parent Comment Proposed Change Michael Rupen
18 August 2015
Missing "shall":
CSP_Mid, when performing the Pulsar Search, SHALL search..
While we're at it, it would be nice to update this to refer to the observing mode:
Each SKA1_Mid subarray in pulsar search mode shall search...
1.3.4.3.6.6
SKA1-FLD-1366 Binary search
1.3.4.3.6.6.1
SKA1-SYS_REQ- SKA1_Mid Binary Pulsar search
2220
SKA1_Mid Binary Pulsar Search. SKA1_Mid, when the observation duration is less than 600s, shall perform acceleration correction as part of the Pulsar Search,
over a configurable range of acceleration values from 0 to no less than 350 ms-2 , for no fewer than 500 operator selected dispersion measure trials. SKA1_Mid shall
use sufficient acceleration trials such that the degradation in signal-to-noise due to coarse sampling is no worse than 66% anywhere in the acceleration range. If
21/09/2015 7:42 am
Page
129 of 196
Fourier domain correction is used, the trials shall be defined over a range of Fourier drift that is equivalent to the acceleration search for a 500 Hz signal.
Parent Comment Proposed Change Michael Rupen
18 August 2015
Suggest:
For each Pulsar Search beam, when the observation duration is less than 600s,
SKA1_Mid shall..
or:
For each subarray in pulsar search mode, when the observation duration...
1.3.4.3.6.7
SKA1-FLD-1542 Pulsar search and timing within subarrays
1.3.4.3.6.7.1
SKA1-SYS_REQ- SKA1_Mid Pulsar search and timing within subarrays
2751
SKA1_Mid Pulsar search and timing within subarrays. Each SKA1_Mid subarray, when commanded shall perform the Pulsar Search and Pulsar Timing,
independently and concurrently.
Parent Comment General
Ewan Barr
17 July 2015
1.3.4.3.6.8
SKA1-FLD-1348 Pulsar search array diameter
1.3.4.3.6.8.1
This is superceded by 2959
SKA1-SYS_REQ- SKA1_Mid Pulsar search array diameter
2202
SKA1_Mid Pulsar search array diameter. Each SKA1_Mid subarray, when performing the Pulsar Search, shall form beams using any and all constituent antennas,
whose maximum separations are up to 20,000 metres.
Parent Comment Proposed Change Michael Rupen
18 August 2015
1.3.4.3.6.9
SKA1-FLD-1543 Pulsar search frequency
1.3.4.3.6.9.1
SKA1-SYS_REQ- SKA1_Mid Pulsar search frequency
2755
Alternative wording:
For each subarray in pulsar search mode, SKA1_Mid shall form pulsar search
beams using any and all antennas within that subarray, whose maximum
separations are at most 20 km.
SKA1_Mid Pulsar Search observing frequency. SKA1_Mid, when commanded, shall perform the Pulsar Search on an operator configured continuous bandwidth
located anywhere within the current subarray band.
Parent Comment Proposed Change Michael Rupen
1.3.4.3.7
SKA1-FLD-908
21/09/2015 7:42 am
18 August 2015
Should this be, within the digitized band? Presumably we require that the tiedarray bands lie within the sampled band transmitted from the dish.
SKA1_Mid Pulsar Timing
Page
130 of 196
1.3.4.3.7.1
SKA1-FLD-1352 Pulsar timing array radius
Parent Comment Proposed Change Michael Rupen
1.3.4.3.7.1.1
18 August 2015
Should be "CSP_Mid pulsar timing subarray diameter" -- the requirement is more
nearly on the diameter than on the radius (maximum separation)
SKA1-SYS_REQ- SKA1_Mid Pulsar timing array radius
2206
SKA1_Mid Pulsar timing array radius. Each SKA1_Mid subarray shall form Pulsar timing beams using any or all antennas within that sub-array, which are
separated by at most 20,000 metres
Parent Comment General
Michael Rupen
18 August 2015
Note that the requirement is more nearly on the diameter than on the radius
(maximum separation) -- change the header maybe?
Parent Comment Proposed Change Michael Rupen
18 August 2015
Re-wording for modes:
For each SKA1_Mid subarray in pulsar timing mode, SKA1_Mid shall form pulsar
timing beams using any or all stations within that subarray, which are separated
by at most 20km.
1.3.4.3.7.10
SKA1-FLD-1556 Time coding
1.3.4.3.7.10.1
SKA1-SYS_REQ- SKA1_Mid Time coding
2764
SKA1_Mid Time coding. Each data sample shall be traceable to a time code with an accuracy better than 10 ns over a period of 1 observation to 10 years for each
individual Pulsar timing observation within SKA1_Mid.
Parent Comment General
21/09/2015 7:42 am
Michael Rupen
22 August 2015
Is there a similar (presumably less rigorous) requirement for the visibilities? for
pulsar search? for VLBI?
Page
131 of 196
1.3.4.3.7.11
SKA1-FLD-1376 Multiple simultaneous timings
1.3.4.3.7.11.1
SKA1-SYS_REQ- SKA1_Mid Timing Beams
2939
SKA1_Mid Timing Beams. The SKA1_Mid pulsar timing beamformer shall be capable of forming multiple tied array beams within the same subarray, with the same
sky coordinates.
Parent Comment General
General
Ewan Barr
17 July 2015
Michael Rupen
22 August 2015
1.3.4.3.7.12
SKA1-FLD-1377 Dispersion Measure
1.3.4.3.7.12.1
SKA1-SYS_REQ- SKA1_Mid Pulsar timing Dispersion Measure.
2231
Again as with the corresponding Low requirement I would change "the same" to
"independent"
See comment on corresponding Low requirement.
SKA1_Mid Pulsar timing Dispersion Measure. The SKA1_Mid shall time Pulsars with dispersion measures between 0 to 3000 pc cm-3 such that residual dispersive
smearing is limited by the precision of the supplied dispersion measure.
Parent Comment General
General
Ewan Barr
17 July 2015
Technically speaking, this requirement is untestable. If someone provides a DM
with a precision that implies a smearing less than the Nyquist rate of an
SKA1_Mid coarse channel then we cannot verify this requirement.
Michael Rupen
22 August 2015
Isn't this requirement actually *unachievable*, rather than "merely" untestable?
Both for the reason you cite, and because precision is not the same as accuracy,
and is limited by the observer typing in numbers, rather than by whether those
numbers are actually significant.
Good catch, Ewan!
General
Ewan Barr
25 August 2015
I think my point was that it is impossible to prove that it has not been achieved
and is therefore meaningless. This should be changed to simply state that it will
be accurate down to the Nyqvist rate of a given channelisation. The wording for
this should come out of the ongoing tech/science memo.
1.3.4.3.7.13
SKA1-FLD-1838 Calibrated Polarisation Fidelity for Pulsars
1.3.4.3.7.13.1
SKA1-SYS_REQ- SKA1_Mid Calibrated Polarisation Fidelity for Pulsars
2965
21/09/2015 7:42 am
Page
132 of 196
SKA1_Mid Calibrated Polarisation Fidelity for Pulsars. The SKA1_Mid telescope shall produce phase-resolved averages of the polarised flux from Pulsars with
calibrated polarisation fidelity of at least 40 dB.
Parent Comment Issue
Michael Rupen
22 August 2015
As for 2966, this requirement is very important but rather poorly worded.
1.
2.
As written, this applies to all pulsar observations: PSS, PST, and phase
binning (maybe even simple imaging observations).
40 dB is quite difficult, and has implications far beyond CSP. For instance,
we must provide and apply calibration information that allows this fidelity,
with implications for update rate, accuracy, etc., presumably to be allocated
to TM and SDP (and maybe LFAA). There are implications for our
understanding of the pol'n properties of the station beams as well.
3.
As written it is not clear whether we must simply be able to achieve this
fidelity, once every 50 years, under perfect conditions, with the gods
smiling; or whether this is meant to be an all-the-time thing. I assume the
latter is intended, but this has huge implications for the beamformer, if we
have to do per-station, per-beam corrections for PSS and PST, for tiedarray beams placed arbitrarily within the station beams (e.g., at the halfpower points). One could read this as restricting the placement of tiedarray beams to avoid pol'n errors due to pointing errors, poor knowledge of
the primary beam, etc. The preference of the PSS/PST guys at the
moment seems to be for the ability to achieve this accuracy for a few
beams near the center of the station beam, while relaxing the requirement
away from the station beam center.
4.
We really need fidelity requirements as a function of weather conditions
(wind, ionosphere, etc.), observing band, location within the primary beam,
observing mode, strength of the pulsar. and the like. I love having an
actual fidelity requirement (and want many more) but it needs some careful
thought.
1.3.4.3.7.14
SKA1-FLD-1879 SKA1_Mid cross polarisation purity (Pulsar timing)
1.3.4.3.7.14.1
SKA1-SYS_REQ- SKA1_Mid Cross Polarisation Purity, Pulsar Timing
2963
SKA1_Mid Cross Polarisation Purity, Pulsar Timing. The SKA1_Mid intrinsic cross polarisation ratio for Pulsar timing shall be at least 15 dB over the whole
observing bandwidth within the half power beam width
Parent Comment General
Michael Rupen
22 August 2015
Do we know that this allows us to meet the pol'n fidelity requirement?
Should I interpret this as meaning that we have to be able to place pulsar timing
21/09/2015 7:42 am
Page
133 of 196
beams anywhere within the half-power beam width? Must we achieve the pol'n
fidelity requirement for beams placed anywhere within that area?
I know SKA loves the intrinsic cross-pol'n ratio, but I don't think specifying this is
sufficient to be sure the desired pol'n properties are achieved.
1.3.4.3.7.15
SKA1-FLD-1878 SKA1_Mid Pulsar timing resolution
1.3.4.3.7.15.1
SKA1-SYS_REQ- SKA1_Mid Pulsar Timing Resolution
2961
SKA1_Mid Pulsar Timing resolution. The timing resolution shall be better than 100 ns for SKA1_Mid Pulsar timing.
Parent Comment Proposed Change Michael Rupen
22 August 2015
1.3.4.3.7.2
SKA1-FLD-1548 Pulsar timing observing band
1.3.4.3.7.2.1
SKA1-SYS_REQ- SKA1_Mid Pulsar timing observing band
2757
In some cases this is simply not possible. How about:
The timing resolution of SKA1_Mid in the Pulsar timing mode shall be at least as
good as 100ns or the theoretical limit imposed by the dispersion measure,
whichever is larger.
SKA1_Mid Pulsar timing observing band. The SKA1_Mid, when commanded, shall form beams for each of the Pulsar timing subarrays with a selectable Pulsar
timing band for each subarray in the range from the lowest through to the highest frequency of that subarray's observing band.
Parent Comment Proposed Change Michael Rupen
18 August 2015
Re-word for modes:
For each SKA1_Mid subarray in pulsar timing mode, the SKA1_Mid shall form
beams with a selectable observing band for each subarray which may be placed
anywhere within the SKA1_Mid digitized band(s).
Parent Comment Question
Michael Rupen
1.3.4.3.7.3
SKA1-FLD-1549 Pulsar timing bandwidth
18 August 2015
Should this also be allocated to TM? since they will be doing the commanding
1.3.4.3.7.3.1
SKA1-SYS_REQ- SKA1_Mid Pulsar timing bandwidth
2758
SKA1_Mid Pulsar timing bandwidth. The SKA1_Mid when performing Pulsar timing, shall have a contiguous processing bandwidth up to the full bandwidth of the
selected band up to a bandwidth of 2.5 GHz.
Parent Comment Proposed Change Michael Rupen
18 August 2015
1.3.4.3.7.4
SKA1-FLD-1353 Pulsar timing number of beams
21/09/2015 7:42 am
Change first bit to"
For each subarray in pulsar timing mode, the SKA1_Mid shall have...
Page
134 of 196
1.3.4.3.7.4.1
SKA1-SYS_REQ- SKA1_Mid Number of Pulsar timing beams
2207
SKA1_Mid Number of Pulsar timing beams. The SKA1_Mid, when commanded, shall be capable of forming up to 16 dual polarisation beams in total across all
Pulsar timing subarrays.
Parent Comment Proposed Change Michael Rupen
18 August 2015
Parent Comment Proposed Change Michael Rupen
18 August 2015
Suggest:
When instructed, SKA1_Mid shall form and process the data from up to 16 dual
polarisation beams in total, spread across any and all subarrays which are in
Pulsar Timing mode.
Should combine with 2763.
1.3.4.3.7.5
SKA1-FLD-1354 Beamformer S/N performance: Pulsar timing
1.3.4.3.7.5.1
SKA1-SYS_REQ- SKA1_Mid Beamforming S/N ratio: Pulsar timing.
2208
SKA1_Mid Beamforming S/N ratio: Pulsar timing. The SKA1_Mid for Pulsar timing shall have a Signal to Noise ratio greater or equal to 98% of an ideal analogue
beam former.
Parent Comment General
Michael Rupen
22 August 2015
If the 98% is intended to include coherence losses due to poor calibration and
SNR losses due to incorrect antenna weights, this should be made explicit, and
also be allocated to TM and SDP.
If this is not the intent, this requirement should be re-phrased:
The SKA1_Mid, when forming pulsar timing beams, shall not degrade the signalto-noise to less than 98% of that achievable by an ideal analogue beam-former,
given the same digitized inputs and calibration.
Of course this would really be an L2 requirement.
Also in this case, where are the requirements on the accuracy of such
calibration/weighting?
1.3.4.3.7.6
SKA1-FLD-1555 Pulsar timing subarray support
1.3.4.3.7.6.1
SKA1-SYS_REQ- SKA1_Mid Pulsar timing subarray support
2763
SKA1_Mid Pulsar timing subarray support. The SKA1_Mid, when commanded, shall independently and concurrently process up to a maximum of 16 Pulsar timing
beams allocated across instantiated subarrays.
Parent Comment Proposed Change Michael Rupen
21/09/2015 7:42 am
18 August 2015
Should combine with 2207.
Page
135 of 196
1.3.4.3.7.7
SKA1-FLD-1558 Pulsar timing processing bandwidth
1.3.4.3.7.7.1
SKA1-SYS_REQ- SKA1_Mid Pulsar timing processing bandwidth.
2768
SKA1_Mid Pulsar timing processing bandwidth. The SKA1_Mid, when performing Pulsar timing, shall have a contiguous processing bandwidth up to the full
bandwidth of the selected band limited to a maximum of 2.5 GHz for each timing subarray.
Parent Comment General
Michael Rupen
22 August 2015
1.3.4.3.7.8
SKA1-FLD-1370 Frequency agility
1.3.4.3.7.8.1
SKA1-SYS_REQ- SKA1_Mid Pulsar timing frequency agility.
2224
Should re-phrase for subarrays and modes: Each SKA1_Mid subarray which is
in pulsar timing mode shall perform pulsar timing using...
SKA1_Mid Pulsar timing frequency agility. The SKA1_Mid, when commanded, shall change from observing in any frequency band, to observing in any other
frequency band in less than or equal to 30 seconds, for Pulsar timing observations.
Parent Comment Issue
Michael Rupen
22 August 2015
I do not understand why this requirement applies only to pulsar timing
observations -- do we not want the same band-changing flexibility in ALL
modes? Note that there are no such requirements currently.
I would change this to avoid the reference to pulsar timing and just say
"SKA1_Mid frequency agility." And then move this out of this section.
Parent Comment Proposed Change Michael Rupen
22 August 2015
Change wording for subarrays:
Each SKA1_Mid subarray which is not in NULL mode shall when commanded
change from observing...
Parent Comment Issue
22 August 2015
This needs allocation to elements at the system level. E.g., how long does TM
have to forward the instruction, and how much time do TM and CSP get to switch
bands?
Michael Rupen
1.3.4.3.7.9
SKA1-FLD-1557 Pulsar timing observation time
1.3.4.3.7.9.1
SKA1-SYS_REQ- SKA1_Mid Pulsar timing observation time
2766
SKA1_Mid Pulsar timing observation time. The observation duration for each SKA1-MID Pulsar timing subarray shall be set independently with a value configurable
21/09/2015 7:42 am
Page
136 of 196
between 3 and 300 minutes with a granularity of TBD seconds
Parent Comment General
Ewan Barr
17 July 2015
Parent Comment General
Michael Rupen
22 August 2015
Where does this lower 3 minute requirement come from? Theoretically the actual
pulsar timing instrument may want to only do 10 second observations for test
purposes. Should this just be split out at the L3 level?
Is this intended to rule out a mode where pulsar timing is limited by SNR rather
than duration?
Also, one can imagine crowded fields (globular clusters, galactic center) where
there are more than 16 pulsars in the primary beam. The requirement as written
does not seem to allow an approach where one observes a list of pulsars within
the primary beam, automatically moving from one to the next when the desired
timing accuracy is achieved.
Perhaps Ewan and/or Willem can comment on these possible use cases.
Parent Comment General
Ewan Barr
25 August 2015
Given that this is specifying the obs time for a sub-array and not a beam, I
assume that we can expand this at the L2 and L3 level to allow for shorter
observations as long as they don't involve a sub-array reconfiguration. This
would cover globular clusters for instance.
I can imagine a mode where we have a dense field (particularly the case with the
wide beams at the bottom of band1) where we want to quickly scan through all
the pulsars and when we find that one is scintillating up we observe that one for
an extended period. It is far more efficient in this case to be able to do 30 second
(for example) observations than 3 minute observations. Here we are only talking
about switching targets here within a pointing of a given sub-array.
Alternatively we may want a mode where we have a small sub-array (4 or less
dishes) that roves the sky looking for scintillating sources which it then relays to
a bigger sub-array. This would also benefit from the efficiency of shorter
observations. Here we are talking about having a fixed sub-array configuration
but being able to repoint on intervals shorter than 3 minutes.
1.3.5
SKA1-FLD-1624 Observing
21/09/2015 7:42 am
Page
137 of 196
1.3.5.1
SKA1-FLD-828
Operational Modes
1.3.5.1.1
SKA1-FLD-1450 Normal observing
1.3.5.1.1.1
SKA1-FLD-833
1.3.5.1.1.1.1
SKA1-SYS_REQ- Continuum and spectral line imaging mode.
2128
Continuum and Spectral Imaging Mode
Continuum and spectral line imaging mode. Both SKA1 telescopes shall be capable of operating in a Continuum and Spectral-line imaging mode concurrently.
Parent Comment Proposed Change Michael Rupen
22 August 2015
Re-word for subarrays and mode definitions:
Concurrent continuum and spectral imaging modes. Each SKA1 subarray shall
when commanded operate simultaneously in continuum imaging mode and
spectral imaging mode.
Parent Comment General
John Bunton
31 August 2015
Michael Rupen
3 September 2015
This seems redundant. We have a requirement for zoom modes and another for
1MHz across the band while in zoom.
After talking with Wallace I believe the problem lies in the definition of "modes."
The continuum and spectral line imaging modes in the L1s apparently were
originally intended to refer simply to processing (SDP) options -- for continuum
imaging you get a continuum image plus spectral shape information, while for
spectral line you get an image cube (one image per channel), possibly with
continuum subtracted. Turning on zoom windows then changes the data passed
to SDP but is independent of the continuum and spectral imaging modes.
General
This has NOT yet made it into Sonja's Modes & States document, and of course
_that_ document has yet to be folded in to the L1s. I've started the conversation
going with Sonja but it would be really nice to get that document agreed upon,
and then go through the L1s throroughly to be sure they're consistent
throughout.
1.3.5.1.1.2
SKA1-FLD-1836 Pulsar Search and Timing Mode
1.3.5.1.1.2.1
SKA1-SYS_REQ- SKA1_MID Commensal Observing Modes.
2959
SKA1_MID Commensal Observing Modes. The SKA1_MID telescope, when commanded, shall operate commensally for Pulsar timing, Pulsar search (both
periodicity and single pulse search) and continuum imaging, within the same subarray
21/09/2015 7:42 am
Page
138 of 196
Parent Comment Proposed Change Michael Rupen
1.3.5.1.1.2.2
22 August 2015
This should also include spectral imaging mode. Propose:
Each SKA1_Mid subarray, when commanded, shall operate simultaneously in
the Pulsar timing, Pulsar search, and continuum and spectral imaging modes,
within the same subarray.
I believe other requirements already ensure that pulsar search will include single
pulses.
SKA1-SYS_REQ- SKA1_Low Commensal Observing Modes.
2960
SKA1_Low Commensal Observing Modes. The SKA1_Low telescope, when commanded, shall operate commensally for Pulsar timing, Pulsar search (both
periodicity and single pulse search) and continuum imaging, within the same subarray.
Parent Comment General
1.3.5.1.1.3
SKA1-FLD-838
Michael Rupen
Mode transition
22 August 2015
See 2959 comment.
Requirement will enable the ability of the system to observe targets of opportunity.
Parent Comment General
Michael Rupen
22 August 2015
I am not clear on why this requirement is primarily driving by ToOs. Surely we
want to move from one observing block to the next, or to change "modes" within
an observing block, regardless of whether those blocks are ToOs or not But
maybe I am getting confused by the mode confusion (see comments on the
actual requirement).
1.3.5.1.1.3.1
SKA1-SYS_REQ- Mode transition
2133
Mode transition. The switching time between telescope operating modes shall take less than 30 seconds (not including antenna slewing time)
Parent Comment Issue
Michael Rupen
22 August 2015
Needs system-level allocation.
Parent Comment Issue
Michael Rupen
22 August 2015
Needs to be re-written based on current mode definitions. I am not even sure
what is intended by "operating mode" (maybe this is observing mode??) though
as a general rule I like the idea of having a requirement on the time required to
switch *each* (or all) of the modes. Please clarify!
1.3.5.1.2
SKA1-FLD-1451 Observations on a fixed schedule
1.3.5.1.2.1
SKA1-FLD-1470 Specific epoch observations
1.3.5.1.2.1.1
SKA1-SYS_REQ- Specific epoch observations
2681
21/09/2015 7:42 am
Page
139 of 196
Specific epoch observations. The observatory shall have the capability of scheduling observations at a specific epoch.
1.3.5.1.3
SKA1-FLD-1457 Sub arrays
1.3.5.1.3.1
SKA1-FLD-832
1.3.5.1.3.1.1
SKA1-SYS_REQ- Subarraying.
2127
Subarraying
Subarraying. Both of the SKA1 telescopes shall perform observations independently with one to sixteen subarrays (i.e. collecting area is split and allocated to
separate, concurrently observing programmes) and a seventeenth subarray for maintenance
Parent Comment General
Wallace Turner
10 July 2015
Parent Comment General
Wallace Turner
10 July 2015
Parent Comment General
Wallace Turner
10 July 2015
CSP comment
Need guidance on whether CSP can assume a minimum number of antennas
per sub-array, in particular for MID because of the different bandwidths and
number of bits available at different bands. CSP (MID) would like sub-array
granularity to be modulo 4. This should be included in the note to be published
(c.f., Action #2).
SKAO to publish note that better defines sub-arrays, including minimum number
of receivers and modify requirements.
Parent Comment General
Wallace Turner
10 July 2015
CSP comment TIM#2
Sub-array ECP coming. Once receptor can't be in more than one sub-array.
Parent Comment General
Wallace Turner
10 July 2015
CSP comment Michael Rupen
2014-05-31 -- Michael R's visit to SKAO
4-antenna granularity: SKAO would like both options to be presented, with a
21/09/2015 7:42 am
SDP comment
With these requirements [L1RS]
specifies that certain functions shall be
performed using sub-arrays.
Require a more precise definition of what
constitutes a sub-array, and what rules may be
needed to constrain their operation.
WT:
Jul 10, 2015, 8:03 AM Page 115 of 157
ECP for the clarification of sub-arrays in place. Updated and new requirements
have been generated as part of Rev6B ECP150002.
No further action required
Page
140 of 196
rough cost estimate for each. In this case that presumably means we should
present our preferred option (4-ant granularity) as the default, but document this
as an assumption and lay out the gross implications (including cost) if that is not
acceptable.
Parent Comment General
Wallace Turner
10 July 2015
CSP comment
2014-07-08 – TIM#3
Wallace: 4-ant granularity is OK (TBC when ECP is approved).
John B: For Redback approach, N-8 Is magical. E.g. if I have a 100-antenna
correlator, 100 antennas in one sub-array is ok, as are (1) two 50-antenna subarrays, and (2) one 92- and one 8-antenna sub-array. One 96- and one 4antenna sub-arrays would not be allowed. Is this ok?
Wallace: OK (TBC when ECP is approved).
Changed priority to Low, given Wallace's comment.
Parent Comment General
Wallace Turner
10 July 2015
Reply,
Sub array clarification provided by ECP15003
No further action required
Parent Comment General
Michael Rupen
22 August 2015
Seems odd to have a single, separate subarray for maintenance. I would think
"maintenance" would be an (overriding) mode, usable in any subarray, and
allowing a natural way for subarrays to be allocated if desired to multiple
engineering groups simultaneously. This depends of course on exactly how
subarrays are to be used, and whether test/commissioning is considered
maintenance. In general it would seem useful sometimes to correlate data from
a "maintenance" subarray. But perhaps the SKAO is thinking differently.
The "special" maintenance mode that occurs to me is one where people are
working on an antenna and not correlating that antenna with any other; several
such antennas might be worked on independently, at the same time. If this
requires being in a subarray (in other telescopes that term is reserved for true
"arrays", where the constituents are observing in tandem and being correlated) I
would rather define a special version where the constituents are explicitly
independent of one another.
1.3.5.1.3.1.2
SKA1-FLD-1868 Subarraying SKA1_Low
1.3.5.1.3.1.2.1
SKA1-SYS_REQ- SKA1_Low subarray support
2773
SKA1_Low correlation subarray support. The SKA1_Low, when commanded, shall concurrently correlate station beams within a configurable set of one to sixteen
subarrays.
21/09/2015 7:42 am
Page
141 of 196
1.3.5.1.3.1.2.10 SKA1-SYS_REQ- SKA1_Low Maintenance subarray
3002
SKA1_Low Maintenance subarray. The SKA1_Low shall have a Maintenance/ administration sub-array of which any station may be allocated.
Parent Comment Proposed Change Michael Rupen
22 August 2015
Perhaps:
SKA1_Low shall support a maintenance/administration subarray, to which any
station may be allocated.
Parent Comment General
31 August 2015
Presumably and station in maintenance will not contribute to correlation of PSS
and PST beams. Roughly equivalent to flagging all data from a station in
maintenance.
John Bunton
1.3.5.1.3.1.2.11 SKA1-SYS_REQ- SKA1_Low subarray RFI flagging
3004
SKA1_Low subarray RFI flagging. The SKA1_Low, when performing observations, shall have the same RFI flagging control parameters for all stations within a
given subarray.
Parent Comment Issue
Michael Rupen
22 August 2015
We certainly want to allow different RFI flagging parameters based on (e.g.)
station location, Tsys, etc. Wiggle at the moment is to interpret RFI flagging
_control_ parameters as simply specifying e.g. the flagging algorithm. But this is
ambiguous at the moment and I'm not sure how to re-word to avoid that.
Parent Comment Proposed Change Michael Rupen
22 August 2015
Again don't forgot IDLE mode:
For subarrays with Observing Mode other than IDLE, SKA1_Low shall have the
same RFI flagging control parameters for all stations within a given subarray.
1.3.5.1.3.1.2.12 SKA1-SYS_REQ- SKA1_Low subarray pointings
3008
SKA1_Low subarray pointings. Each SKA1_Low subarray beam shall be individually and independently pointed.
Parent Comment Proposed Change Michael Rupen
22 August 2015
Should we say "station beam" here to avoid confusion? So "the station beams
for each subarray shall be..."
1.3.5.1.3.1.2.13 SKA1-SYS_REQ- SKA1_Low subarray frequency resolution
3010
SKA1_Low subarray frequency resolution. The frequency resolution for each SKA1_Low subarray shall be independently selectable.
Parent Comment General
Michael Rupen
22 August 2015
1.3.5.1.3.1.2.14 SKA1-SYS_REQ- SKA1_Low subarray bandwidth
21/09/2015 7:42 am
Not sure what this means. We already have independent observing modes, so
you can zoom in one and not in the other, or do continuum in one and not the
other. What "frequency resolution" are we thinking of here?
Page
142 of 196
3012
SKA1_Low subarray bandwidth The bandwidth for each SKA1_Low subarray shall be individually configurable.
Parent Comment General
General
John Bunton
Michael Rupen
31 August 2015
1 September 2015
Is this need. The intention is to do full bandwidth on all sub arrays.
Perhaps this refers to the non-imaging processing? But I agree it should be
made explicit -- currently this is just confusing.
1.3.5.1.3.1.2.15 SKA1-SYS_REQ- SKA1_Low subarray visibility time resolution
3014
SKA1_Low subarray visibility time resolution. The visibility time resolution for each SKA1_Low subarray shall be individually and independently configurable.
1.3.5.1.3.1.2.16 SKA1-SYS_REQ- SKA1_Low subarray logical conrol and monitoring
3016
SKA1_Low subarray logical control and monitoring. For each instantiated subarray, SKA1_Low, shall provide independent logical control and monitoring
Parent Comment General
John Bunton
31 August 2015
Not possible in practice. We can just make it appear as if it is independent. The
important word here is "logical"
1.3.5.1.3.1.2.17 SKA1-SYS_REQ- SKA1_Low subarray logical data flows
3018
SKA1_Low subarray logical data flows. For each instantiated subarray, the SKA1_Low shall provide independent logical data flows with associated meta-data.
1.3.5.1.3.1.2.18 SKA1-SYS_REQ- SKA1_Low subarray scheduling block set-up time
3020
SKA1_Low subarray scheduling block set-up time. The time from selecting a schedule block to all components an SKA1_Low subarray being configured shall be
less than 30 seconds
Parent Comment General
Michael Rupen
31 August 2015
Needs system-level allocation.
1.3.5.1.3.1.2.19 SKA1-SYS_REQ- SKA1_Low simultaneous scheduling blocks
3025
SKA1_Low simultaneous scheduling blocks. The SKA1_Low shall constrain the maximum number of simultaneous scheduling blocks across all instantiated
subarrays to 16 in total.
Parent Comment General
21/09/2015 7:42 am
Alan Bridger
27 August 2015
Given that there is already a requirement stating the maximum number of
subarrays is this really a L1 requirement? In my view it unnecessarily constrains
the design. For instance our present design supports commensal observing by
having two Scheduling Blocks running on a single subarray, one controlling the
observing, the second "hitch-hiking" and only configuring systems for commensal
processing. Thus it is possible for 16 subarrays to support at least 32 SBs (one
normal, one, or even more, commensal on each). This requirement would
Page
143 of 196
prevent that.
General
General
Parent Comment General
General
21/09/2015 7:42 am
Michael Rupen
31 August 2015
Hard to know, without a real definition of a scheduling block, and a full ConOps
(or is it OpsCon now?) document. I'd been assuming that an SB would control
all aspects of a given subarray, including commensal hitch-hiking.
Note that some commensal observations go beyond simple processing, for
instance in defining the location and tuning of tied-array beams when the
"primary" observer (if there is such a thing) is just doing, say, continuum imaging.
Michael - there is a description of TM's view of an SB in the TM (especially
OBSMGT) PDR documents. But your assumption is correct *except* that we are
designing such that commensal observing would be a different, separate, SB.
This is primarily because it could (usually would) be from a different project. We
considered alternatives but this seemed simplest. Thank you for the input
regarding tied-array beams. This should not be a problem for our design, but it is
good to understand this. We do already consider CSP as well as SDP as part of
"processing" from our perspective.
Alan Bridger
1 September 2015
Michael Rupen
31 August 2015
Why is this allocated to CSP? or LFAA etc. It's not obvious that anyone but TM
need know about Scheduling Blocks. A document describing their use would be
very helpful...
Alan Bridger
1 September 2015
Perhaps I should produce a memo on "Scheduling Blocks". Actually there
remain many questions, especially with respect to SDP use, so this would be a
useful exercise. In response to whether or not other systems need to know
about them: SDP and CSP will need to connect the data they are processing to
the project it is for. This does not directly mean they need to know about SBs,
but they will know of an identifier that can be linked back to the relevant SB. It is
not obvious to me that LFAA and SADT need to know this.
Page
144 of 196
1.3.5.1.3.1.2.2
SKA1-SYS_REQ- SKA1_Low subarray set up time
2986
SKA1_Low subarray set up time. SKA1_Low, when commanded, shall re-configure subarrays within 30s between consecutive configurations.
Parent Comment Issue
Michael Rupen
22 August 2015
Requires system-level allocation to the elements.
1.3.5.1.3.1.2.20 SKA1-SYS_REQ- SKA1_Low subarray scheduling block allocation
3027
SKA1_Low subarray scheduling block allocation. The SKA1_Low shall allocate a scheduling block to only one subarray at any one time
Parent Comment General
Michael Rupen
31 August 2015
Again we need a full description of Scheduling Blocks and their use. Naively
only TM need be aware of these.
1.3.5.1.3.1.2.21 SKA1-SYS_REQ- SKA1_Low subarray independence of scheduling block
3029
SKA1_Low subarray independence of scheduling block. The SKA1_Low shall instantiate subarrays independent of the existence of a scheduling block
1.3.5.1.3.1.2.3
SKA1-SYS_REQ- SKA1_Low subarray membership
2988
SKA1_Low subarray membership. Any one station shall only form part of a single subarray.
Parent Comment Proposed Change Michael Rupen
1.3.5.1.3.1.2.4
22 August 2015
Perhaps:
Each SKA1_Low station shall belong to at most one subarray at any given time.
SKA1-SYS_REQ- SKA1_Low subarray granularity
2990
SKA1_Low subarray granularity. SKA1-Low subarrays shall be composed of stations and can be configured to contain any number of stations between a single
station and all the stations. Stations can be added in increments of 1 station.
Parent Comment General
1.3.5.1.3.1.2.5
Michael Rupen
22 August 2015
CSP_Mid now allows one-station granularity, as one of the positive results of rebaselining.
SKA1-SYS_REQ- SKA1_Low subarray independence
2992
SKA1_Low subarray independence. The SKA1_Low, shall allow any individual subarray to be used independently from any other subarray.
Parent Comment Proposed Change Michael Rupen
21/09/2015 7:42 am
22 August 2015
This could be made stronger -- something like:
Unless explicitly stated otherwise, SKA1_Low shall accept and execute
commands for, and process data from, each subarray completely independently
of and concurrently with all others.
A more explicit statement has proven useful in CSP, where dependences keep
creeping into the design. The "unless" part is needed to point to the tied-array
Page
145 of 196
beam constraints, which require that subarrays know about each other.
1.3.5.1.3.1.2.6
SKA1-SYS_REQ- SKA1_Low subarray configuration
2994
SKA1_Low subarray configuration. Stations in the same subarray shall be configured identically when performing observations.
Parent Comment General
Michael Rupen
22 August 2015
1.
2.
1.3.5.1.3.1.2.7
Surely this is not true for subarrays with observing mode set to IDLE, or for
the maintenance subarray if there's really only one.
"Configured" is a little vague. We must allow for per-station (per-antenna
even) calibration, and some calibration schemes may have stations doing
slightly different things at a given time. Worth pondering a bit anyhow.
SKA1-SYS_REQ- SKA1_Low subarray tied-array beam station exclusion
2996
SKA1_Low subarray tied-array beam station exclusion. The SKA1_Low shall assign dynamic weights to stations within a subarray contributing to tied-array beams
including the ability to exclude individual stations.
Parent Comment Issue
1.3.5.1.3.1.2.8
Michael Rupen
22 August 2015
Sometime we need a spec on the accuracy of these weights, followed by
system-level discussion of how to achieve this accuracy. Note this may be
different for the search and the timing beams.
SKA1-SYS_REQ- SKA1_Low subarray station allocation
2998
SKA1_Low subarray station allocation. The SKA1_Low, when performing observations, shall allocate stations to subarrays at scheduling block boundaries only.
Parent Comment Proposed Change Michael Rupen
1.3.5.1.3.1.2.9
22 August 2015
Re-word to account for IDLE mode:
SKA1_Low shall allow changes of station-to-subarray allocations only (1) for
sub-arrays with Observing Mode IDLE; and (2) for sub-arrays which are not
IDLE, at scheduling block boundaries.
SKA1-SYS_REQ- SKA1_Low subarray station failure flagging
3000
SKA1_Low subarray station failure flagging. The SKA1_Low, when performing observations and when stations fail, shall flag the data from those stations within
TBD and not remove faulty dishes from the subarray within scheduling block boundaries
Parent Comment Proposed Change Michael Rupen
22 August 2015
"Dishes" should not occur in a Low requirement :)
Again re-word to allow for Mode IDLE:
SKA1_Low, for subarrays with Observing Mode not set to IDLE, shall apply flags
to data from any station which fails within a scheduling block boundary, whilst
retaining that station's subarray membership until it is removed at a scheduling
21/09/2015 7:42 am
Page
146 of 196
block boundary.
Parent Comment Issue
Michael Rupen
22 August 2015
1.3.5.1.3.1.3
SKA1-FLD-1869 Subarraying SKA1_Mid
1.3.5.1.3.1.3.1
SKA1-SYS_REQ- SKA1_Mid correlation subarray support
2774
Need a system-level allocation of who determines that a station has failed.
SKA1_Mid correlation subarray support. The SKA1_Mid, when commanded, shall concurrently correlate all dish signals within each of a configurable set of one to
sixteen subarrays.
1.3.5.1.3.1.3.10 SKA1-SYS_REQ- SKA1_Mid Maintenance subarray.
3003
SKA1_Mid Maintenance subarray. The SKA1_Mid shall have a Maintenance/ administration sub-array of which any antenna may be allocated.
Parent Comment Proposed Change Michael Rupen
31 August 2015
Parent Comment Issue
31 August 2015
Michael Rupen
Perhaps:
SKA1_Mid shall support a maintenance/administration subarray, to which any
dish may be allocated.
Many requirements simply refer to "subarrays" without distinguishing
maintenance from other subarrays. Should really go through all subarray
requirements with this in mind -- I have not had time to do so alas.
1.3.5.1.3.1.3.11 SKA1-SYS_REQ- SKA1_Mid subarray RFI flagging.
3005
SKA1_Mid subarray RFI flagging. The SKA1_Mid, when performing observations, shall have the same RFI flagging control parameters for all dishes within a given
subarray.
Parent Comment Issue
Michael Rupen
31 August 2015
Parent Comment Proposed Change Michael Rupen
31 August 2015
We certainly want to allow different RFI flagging parameters based on (e.g.)
antenna location, Tsys, etc. One could interpret "RFI flagging _control_
parameters" as simply specifying e.g. the flagging algorithm. But this is
ambiguous at the moment and I'm not sure how to re-word to avoid that.
Again don't forgot IDLE mode:
For subarrays with Observing Mode other than IDLE, SKA1_Mid shall have the
same RFI flagging control parameters for all dishes within a given subarray.
This doesn't necessarily account for the Maintenance subarray however...
1.3.5.1.3.1.3.12 SKA1-SYS_REQ- SKA1_Mid subarray frequency bands.
3007
21/09/2015 7:42 am
Page
147 of 196
SKA1_Mid subarray frequency bands. The frequency band for each MID Telescope subarray shall be independently selectable.
Parent Comment General
Michael Rupen
31 August 2015
Parent Comment General
Michael Rupen
31 August 2015
"MID Telescope" seems an odd wording -- usually this has been simply
"SKA1_Mid". Is there some meaning to the difference here?
Consider combining with 3010, 3012, 3014.
1.3.5.1.3.1.3.13 SKA1-SYS_REQ- SKA1_Mid subarray pointings.
3009
SKA1_Mid subarray pointings. The beam for each SKA1_Mid subarray shall be individually and independently pointed.
Parent Comment Proposed Change Michael Rupen
31 August 2015
There are many "beams" in radio interferometry -- primary beams, tied-array
beams, dirty beams, CLEAN beams, delay beams...on and on. The other
problem is that you don't "point" a subarray -- you point a _dish_. I don't have
the perfect wording but maybe something like:
The dish pointing for each SKA1_Mid subarray shall be commanded individually
and independently.
1.3.5.1.3.1.3.14 SKA1-SYS_REQ- SKA1_Mid subarray frequency resolution.
3011
SKA1_Mid subarray frequency resolution. The frequency resolution for each SKA1_Mid subarray shall be independently selectable.
Parent Comment Question
Michael Rupen
31 August 2015
This is a very odd requirement.
1.
The fine frequency channels are defined elsewhere, and there is only one
option (64k +/- x channels) for "standard" continuum and spectral line
observations, while zoom modes are defined in much more detail in other
requirements.
2.
What does this mean for the tied-array data?
Is the intent that the observing mode can be set independently for each subarray
maybe?
1.3.5.1.3.1.3.15 SKA1-SYS_REQ- SKA1_Mid subarray bandwidth
3013
SKA1_Mid subarray bandwidth The bandwidth for each SKA1_Mid subarray shall be individually configurable.
Parent Comment Proposed Change Michael Rupen
21/09/2015 7:42 am
31 August 2015
What bandwidth are we talking about here? The total digitized bandwidth, the
bandwidth of the tied-array beams, something else? All of the above? Perhaps
one could put a bunch of these requirements together:
In CSP_MId, observational characteristics shall be independently settable for
each subarray without restricting such choices for other subarrays. (Examples of
observational characteristics: dish pointing, frequency band, frequency tuning,
Page
148 of 196
tied-array beam parameters, mode(s), processing parameters.)
1.3.5.1.3.1.3.16 SKA1-SYS_REQ- SKA1_Mid subarray visibility time resolution.
3015
SKA1_Mid subarray visibility time resolution. The visibility time resolution for each SKA1_Mid subarray shall be individually and independently configurable.
Parent Comment General
Michael Rupen
31 August 2015
See 3013 comment.
1.3.5.1.3.1.3.17 SKA1-SYS_REQ- SKA1_Mid subarray logical conrol and monitoring.
3017
SKA1_Mid subarray logical control and monitoring. For each instantiated subarray, SKA1_Mid, shall provide independent logical control and monitoring.
1.3.5.1.3.1.3.18 SKA1-SYS_REQ- SKA1_Mid subarray logical data flows.
3019
SKA1_Mid subarray logical data flows. For each instantiated subarray, the SKA1_Mid shall provide independent logical data flows with associated meta-data.
Parent Comment General
Michael Rupen
31 August 2015
Need to define what it means for CSP to instantiate a subarray. One
interpretation: set aside the resources reserved for that subarray. But this needs
discussion.
1.3.5.1.3.1.3.19 SKA1-SYS_REQ- SKA1_Mid subarray scheduling block set-up time.
3021
SKA1_Mid subarray scheduling block set-up time. The time from selecting a schedule block to all components an SKA1_Mid subarray being configured shall be
less than 30 seconds
Parent Comment Issue
Michael Rupen
31 August 2015
1.3.5.1.3.1.3.2 SKA1-SYS_REQ- SKA1_Mid subarray set up time
2987
Needs system-level allocation.
SKA1_Mid subarray set up time. The SKA1_Mid, when commanded, shall re-configure subarrays within 30s between consecutive configurations.
Parent Comment General
Michael Rupen
31 August 2015
1.3.5.1.3.1.3.20 SKA1-SYS_REQ- SKA1_Mid simultaneous scheduling blocks.
3026
Needs system-level allocation.
SKA1_Mid simultaneous scheduling blocks. The SKA1_Mid shall constrain the maximum number of simultaneous scheduling blocks across all instantiated
subarrays to 16 in total.
Parent Comment General
Alan Bridger
27 August 2015
See comment on SKA1-SYS_REQ-3025. Is this requirement needed?
1.3.5.1.3.1.3.21 SKA1-SYS_REQ- SKA1_Mid subarray scheduling block allocation.
3028
SKA1_Mid subarray scheduling block allocation. The SKA1_Mid shall allocate a scheduling block to only one subarray at any one time
21/09/2015 7:42 am
Page
149 of 196
1.3.5.1.3.1.3.22 SKA1-SYS_REQ- SKA1_Mid subarray independence of scheduling block.
3030
SKA1_Mid subarray independence of scheduling block. The SKA1_Mid shall instantiate subarrays independent of the existence of a scheduling block
Parent Comment General
1.3.5.1.3.1.3.3
Michael Rupen
31 August 2015
Need to define what it means for CSP to instantiate a subarray. One
interpretation: set aside the resources reserved for that subarray. But this needs
discussion.
SKA1-SYS_REQ- SKA1_Mid subarray membership
2989
SKA1_Mid subarray membership. Any one dish shall only form part of a single subarray.
Parent Comment Proposed Change Michael Rupen
1.3.5.1.3.1.3.4
31 August 2015
Poorly worded -- could read this to mean that you can't have subarrays
consisting of a single dish, or that subarrays are defined by more than the dishes
which are members. Suggest:
Each dish may belong to at most one SKA_Mid subarray.
SKA1-SYS_REQ- SKA1_Mid subarray granularity
2991
SKA1_Mid subarray granularity. SKA1-MID subarrays shall be composed of dishes and can be configured to contain a single dish or can include any or all of the
SKA1 and MeerKAT dishes. Dishes can be added at increments of 1.
1.3.5.1.3.1.3.5
SKA1-SYS_REQ- SKA1_Mid subarray independence.
2993
SKA1_Mid subarray independence. The SKA1_Mid, shall allow any individual subarray to be used independently from any other subarray.
Parent Comment Proposed Change Michael Rupen
1.3.5.1.3.1.3.6
31 August 2015
As written this is unclear, or in conflict with other requirements (e.g., restricting
the number of tied-array beams across all subarrays). If the intent is that
subarrays be fully independent insofar as possible -- completely independent
observing modes, frequency bands, pointings, scheduling, etc., with no
interactions -- perhaps something more detailed would be preferable:
Unless explicitly stated otherwise, SKA1_Mid shall accept and execute
commands for, and process data from, each subarray independently of and
concurrently with all others.
SKA1-SYS_REQ- SKA1_Mid subarray configuration.
2995
SKA1_Mid subarray configuration. Dishes in the same subarray shall be configured identically.
Parent Comment Issue
21/09/2015 7:42 am
Michael Rupen
31 August 2015
1.
Surely this is not true for subarrays with observing mode set to IDLE, or for
Page
150 of 196
2.
1.3.5.1.3.1.3.7
the maintenance subarray if there's really only one.
"Configured" is a little vague. We must allow for per-dish calibration, and
some calibration schemes may have dishes doing slightly different things at
the same time (e.g., in some schemes for noise diode switching, or for
holography). RFI flagging parameters may be set differently, to allow for
differences in dish location and sensitivity. Other examples may be
evolved.
SKA1-SYS_REQ- SKA1_Mid subarray tied-array beam dish exclusion
2997
SKA1_Mid subarray tied-array beam dish exclusion. SKA1_Mid shall assign dynamic weights to dishes within a subarray contributing to tied-array beams including
the ability to exclude individual dishes
Parent Comment Issue
1.3.5.1.3.1.3.8
Michael Rupen
31 August 2015
Sometime we need a spec on the accuracy of these weights, followed by
system-level discussion of how to achieve this accuracy. Note this may be
different for the search and the timing beams
SKA1-SYS_REQ- SKA1_Mid subarray dish allocation.
2999
SKA1_Mid subarray dish allocation. The SKA1_Mid, when performing observations, shall allocate dishes to subarrays at scheduling block boundaries only.
Parent Comment Proposed Change Michael Rupen
1.3.5.1.3.1.3.9
31 August 2015
Re-word to account for IDLE mode:
SKA1_Mid shall allow changes of dish-to-subarray allocations only (1) for
subarrays with Observing Mode IDLE; and (2) for subarrays which are not IDLE,
at scheduling block boundaries.
SKA1-SYS_REQ- SKA1_Mid subarray dish failure flagging.
3001
SKA1_Mid subarray dish failure flagging. The SKA1_Mid, when performing observations and when dishes fail, shall flag the data from those dishes within TBD and
not remove faulty dishes from the subarray within scheduling block boundaries
Parent Comment Proposed Change Michael Rupen
31 August 2015
Again re-word to allow for Mode IDLE:
SKA1_Mid, for subarrays with Observing Mode not set to IDLE, shall apply flags
to data from any dishwhich fails within a scheduling block boundary, whilst
retaining that dish's subarray membership until it is removed at a scheduling
block boundary.
Parent Comment Issue
1.3.5.2
SKA1-FLD-961
Michael Rupen
Telescope Manager
1.3.5.2.1
General
SKA1-FLD-962
21/09/2015 7:42 am
31 August 2015
Need a system-level allocation of who determines that a station has failed.
Page
151 of 196
21/09/2015 7:42 am
Page
152 of 196
1.3.5.2.1.1
SKA1-FLD-971
Scheduled Maintenance Logs
1.3.5.2.1.1.1
SKA1-SYS_REQ- Scheduled maintenance logs.
2278
Scheduled maintenance logs. A maintenance database shall be established that logs all the scheduled maintenance and unexpected repairs.
1.3.5.2.1.2
SKA1-FLD-972
System error logs
1.3.5.2.1.2.1
SKA1-SYS_REQ- System error logs.
2279
System error logs. A failure database shall be established, which logs the errors of the system and its subsystems, including the corrective actions taken.
1.3.5.2.1.3
SKA1-FLD-973
System status
1.3.5.2.1.3.1
SKA1-SYS_REQ- System status.
2280
System status. The system shall extract information about the current condition of the system from the science and calibration data streams, and log this information
along with other relevant system and environmental status information. Based on this information, it shall be possible to monitor, save, and analyse the technical
performance of the system.
Parent Comment General
Wallace Turner
10 July 2015
SDP comment
This is a compound requirement with missing information. We have tried to split
up the requirement and added TBDs where info is missing. System Status. The
system shall extract information (details TBD) about the current condition of the
system from the science and calibration data streams,
and log (details TBD) this information along with other relevant (TBD) system
and environmental status information.
New requirement from splitting up: Based on the information
logged in SYS_REQ-2280, it shall be possible to monitor,
save, and analyse the technical performance of the system.
Possible additional requirement: The information logged in
SYS_REQ-2280 shall have the following data retention policy: TBD Additional
information that may be needed:
Who needs this information and for what purposes. This requirement has been
assigned to all the elements, so will there be one central log or database (who is
responsible in that case?) or will the logging be distributed (who is then
responsible for logging what info?).
Parent Comment General
Wallace Turner
10 July 2015
SDP FG
Jul 10, 2015, 8:03 AM Page 117 of 157
Vague requirement, thus I suggest to derive L2 & L3 requirements and make
21/09/2015 7:42 am
Page
153 of 196
assumptions where necessary at L2
level (also recorded in SE tool). These assumptions and L2 requirements will
then be submitted to SKAO for acceptance. If they are not accepted, then raise
ECP.Vague requirement, thus I suggest to derive L2 & L3 requirements and
make assumptions where necessary at L2
level (also recorded in SE tool). These assumptions and L2 requirements will
then be submitted to SKAO for acceptance. If they are not accepted, then raise
ECP.
Parent Comment General
Wallace Turner
10 July 2015
TM comment
Clarification: At any time, the real status of the system, as extracted by the
science and
calibration data streams, should be compared with the expected status of the
system, as
derived from the trend analysis performed on the basis of the maintenance,
failures and
repair databases as in SYS_REQ-2278 and SYS_REQ-2279. The goal is to
continuously
improve the trend analysis performance and to increase the reliability of the
system. Is
this what this requirement achieves?
Clarification: Requirement is too generic. It should be expanded, for instance,
into the
following group of requirements:
- System hardware and software monitoring requirements
- System performance requirements (e.g. in terms of data distribution and
archiving rates,
processing speed,etc)
- System availability requirements (e.g. system active 24 hours per day,
maximum outage
periods, maximum recovery time,etc)
Ideally a performance evaluation centre within one of the sites should be
established to
perform trend analysis over defined periods of time.
- System reliability requirements (e.g. MTTF for HW and SW, mean time to
restart/recover
from HW/SW failures, etc
Note SDP have raised a comment on the same requirement which also has a
seperate ticket
Parent Comment General
Wallace Turner
10 July 2015
TM Paul Swart
From the calibration strategy, can SKAO identify which information can be
Jul 10, 2015, 8:03 AM Page 118 of 157
21/09/2015 7:42 am
Page
154 of 196
extracted about the current condition of the system from the science and
calibration data streams?
JSV: I guess this is a question for Tim Cornwell on whether there will be coarser
grained Q&A parameters extracted as calibration products.
Additional input from Paul Swart (TM):
Suggest rewording the requirement to: "The Telescope shall allow…"
I don't find it particularly helpful.
Parent Comment General
Michael Rupen
1.3.5.2.1.4
Central location for data bases
SKA1-FLD-975
31 August 2015
Like everyone else CSP finds this rather vague, but is proceeding to derive Level
2s which can be vetted by the office to see whether they are what is desired.
Would be nice to have a document discussing how this is supposed to work at
the system level, so we can be sure each of the elements has the same
understanding of what is supposed to be done.
The telescope must control the information used by Elements.
Parent Comment General
Wallace Turner
10 July 2015
Parent Comment General
Wallace Turner
10 July 2015
Parent Comment General
Wallace Turner
10 July 2015
Rev6A comment Mark Waterson
the "telescope" can't control anything - the office or the project may take that
authority
Rev6A comment Mark Waterson
the "telescope" can't control anything - the office or the project may take that
authority
Reply
Agree with Mark
Action: remove narative text
1.3.5.2.1.4.1
SKA1-SYS_REQ- Central location for data bases.
2282
Central location for data bases. External sources of information used by the Elements shall be cached by Telescope Manager. No sources other than those cached
by TM shall be used.
Parent Comment General
Wallace Turner
10 July 2015
SDP comment
This is not clear enough and in some way goes against the distributed nature of
the TM design. Some of this information will require very short and low latency
response,
very high transaction rates or both. In addition quite some of this information is
completely irrelevant to any other
subsystem and in particular to the TM. I think this should be
relaxed to state that those information should be managed and handled in a
consistent way and made available through
LMC interfaces. This would allow us to keep such nformation local to a LMC
instance, while still providing access to them. This could make the interface
21/09/2015 7:42 am
Page
155 of 196
Parent Comment General
Wallace Turner
10 July 2015
1.3.5.2.1.5
SKA1-FLD-978
Latency of TOO scheduling block initiation
1.3.5.2.1.5.1
SKA1-SYS_REQ- Latency of TOO scheduling block initiation.
2285
between SDP
and MGR very complex depending on how far we take this requirement. The
intention to centralise telescope state and
configuration is good, we do however need to make
this a more explicit requirement in order to provide sufficient bounding. Ideally
this requirement should provide a list of databases and sources of information
Jul 10, 2015, 8:03 AM Page 119 of 157
that will be held by TM and used by other elements.
SDP FG:
Discussion with TM and SKAO about this Req
is needed. Need to have visibility of requirements
derived by TM from this requirement and needs to
be controlled by the ICD.
Latency of TOO scheduling block initiation. Scheduling intervention on TOO triggers shall be initiated within 1s of receiving the trigger.
Parent Comment General
Wallace Turner
10 July 2015
Parent Comment General
Wallace Turner
10 July 2015
Parent Comment General
Wallace Turner
10 July 2015
Rev6A comment Mark Waterson
Actually should define the latency of any action, also depends on the latency of
reconfiguration, which is separately defined on one of the pulsar search
requirements
Parent Comment General
Wallace Turner
10 July 2015
Reply to GvdM
Agreed
Action: remove CSP from allocation
Reply to Juande
Agree with Juande the parent requirement 2283 is deleted at Rev 6A need new
parent
Reply to Mark: Noted
No further action required
21/09/2015 7:42 am
CSP comment GvdM
As written this is a TM responsibility – CSP will only receive the result of
intervention in terms of commands from TM.
Rev6A comment Juande Santander-Vela
It looks like the parent requirement does not exist. I have marked this as an issue
outside of the review, so that @Wallace don't have to save it for later, is already
done.
Page
156 of 196
Parent Comment General
Michael Rupen
31 August 2015
This should only be allocated to CSP if we are supposed to respond to a trigger
without waiting for TM to command us. This may be the case if internal triggers
are implemented (cf. the transient buffer ECP). But if so, we need a LOT more
details, and the 1second figure is unlikely to be relevant.
Maybe change this to refer to _external_ triggers, and add separate
requirements on internal ones?
1.3.5.2.10
SKA1-FLD-970
Data bases
1.3.5.2.10.1
SKA1-FLD-1006 Access to historical data
1.3.5.2.10.1.1
SKA1-SYS_REQ- Access to historical data.
2313
Access to historical data. All current and historic Site monitor data shall be as examinable as that from any telescope component.
Parent Comment Question
Michael Rupen
31 August 2015
Doesn't seem like much of a requirement, if we don't also define what's required
for data "from any telescope component." Am I missing something here?
1.3.5.2.10.2
SKA1-FLD-1007 Total Electron Content
1.3.5.2.10.2.1
SKA1-SYS_REQ- Total electron content.
2314
Total electron content. The SKA Phase 1 TM shall retrieve, persist and publish data on Total Electron Content (TEC) from dual frequency GPS as part of the
Telescope Model.
Parent Comment General
Wallace Turner
10 July 2015
Rev6 comment Roshene McCool
There is a possibility this might be implemented by SADT who own the central
GPS receivers. Consider allocations
Parent Comment General
Wallace Turner
10 July 2015
Reply
Action add SADT to allocations
Parent Comment Question
Michael Rupen
1.3.5.2.10.3
SKA1-FLD-1008 Ionospheric Activity
1.3.5.2.10.3.1
31 August 2015
What does "persist" mean here? Should this be "store" perhaps?
SKA1-SYS_REQ- Ionospheric activity.
2315
Ionospheric activity. There shall be timely access to information from other relevant sources e.g. IPS concerning unusual ionospheric activity or alerts.
Parent Comment General
Wallace Turner
10 July 2015
TM comment
Clarification: Is the intention of this requirement that the TM shall automatically,
periodically retrieve; persist (cache) and electronically publish information from
21/09/2015 7:42 am
Page
157 of 196
Parent Comment Proposed Change Michael Rupen
1.3.5.2.10.4
SKA1-FLD-1009 Weather Station
31 August 2015
SKA1-SYS_REQ- Weather station.
2316
Weather station. There shall be a data base for site weather station data.
Parent Comment Proposed Change Michael Rupen
31 August 2015
1.3.5.2.10.5
SKA1-FLD-1010 Satellites
ionospheric models to other elements?
Change: Define acronym IPS - Ionospheric Prediction Service in list of
acronyms.
Clarification: Who will determine these sources of information? Will this be
needed for
dynamic scheduling?
Clarification: Do ionospheric models include space-weather and solar relevant
activity?
Should this be changed to something like "TM shall provide timely access..."?
1.3.5.2.10.4.1
Suggest "TM shall maintain a data base..."
1.3.5.2.10.5.1
SKA1-SYS_REQ- Satellites.
2317
Satellites. There shall be a database of relevant satellite trajectories, including orbit information, emission characteristics and owner.
Parent Comment Proposed Change Michael Rupen
31 August 2015
Suggest "TM shall maintain a data base..."
1.3.5.2.10.6
SKA1-FLD-1011 Commercial flights
1.3.5.2.10.6.1
SKA1-SYS_REQ- Commercial flights.
2318
Commercial flights. There shall be a data base of commercial flights in the neighbourhood of the site.
Parent Comment Proposed Change Michael Rupen
31 August 2015
Suggest "TM shall maintain a data base..."
1.3.5.2.10.7
SKA1-FLD-1532 RFI
1.3.5.2.10.7.1
SKA1-SYS_REQ- RFI database
2734
RFI database. There shall be a database holding information about RFI.
Parent Comment Proposed Change Michael Rupen
31 August 2015
Suggest "TM shall maintain a data base..."
21/09/2015 7:42 am
Obviously this needs a bit more definition! Perhaps add "including RFI
frequency, strength, and occupancy as a function of date and time of day,
incorporating both SKA1 observational (astronomical) data and on-site RFI
monitors."
Page
158 of 196
1.3.5.2.2
SKA1-FLD-963
21/09/2015 7:42 am
Proposal submission
Page
159 of 196
1.3.5.2.2.1
SKA1-FLD-982
Proposal submission
1.3.5.2.2.1.1
SKA1-SYS_REQ- Proposal management tool
2723
Proposal submission tool.There shall be a tool to facilitate the assessment, review and ranking of proposals, guided by official SKA Policies.
1.3.5.2.3
SKA1-FLD-1432 Tool for proposal submission
1.3.5.2.3.1
SKA1-SYS_REQ- Tool for proposal submission
2647
Tool for proposal submission. There shall be a tool, either web or client, for the construction and submission of proposals, as necessary facilitating access to
relevant sources of information such as Telescope characteristics, previous observations, SIMBAD, templates.
1.3.5.2.4
SKA1-FLD-964
Telescope Scheduling
Scheduling Blocks are the indivisible executable units of a project and contain all the information necessary to execute a single observation, including configuration,
and scripts to be executed.
1.3.5.2.4.1
SKA1-FLD-984
Semester Queue (of duration related to the proposal cycle)
1.3.5.2.4.1.1
SKA1-SYS_REQ- Semester queue.
2291
Semester queue. A Semester Queue (SQ) shall be constructed by Operations following acceptance of proposals.
Parent Comment General
Alan Bridger
27 August 2015
I would prefer the term "Long Term Plan", or even "Cycle Plan". "Semester"
carries an implication of specific periods (6 months, depending on your culture).
Parent Comment General
General
21/09/2015 7:42 am
Michael Rupen
31 August 2015
Alan Bridger
1 September 2015
Is this the actual schedule for the telescope for a whole cycle? Or just a notional
list of what we think will be observed, given the TAC results? I would like to be
sure we retain flexibility to respond to observing conditions, triggered
observations, and the like.
Our plan is currently to produce a schedule for the whole cycle, but this does
depend on the Operational requirements, which we still await. We could also
produce a coarser notional list showing RA and other resource pressures. Or
both. Either way this long term plan is not cast in stone. Indeed I should add that
the aim of the long term plan is to assess feasibility to schedule the chosen
projects, not to hardwire the whole cycle. There is a short term plan (days?) to
be observed, and that itself is flexible and would change according to TOO
observations and/or environmental/system conditions. The long term plan is then
subject to periodic updates.
Page
160 of 196
1.3.5.2.4.2
SKA1-FLD-985
Operations responsible for Short Term Schedule
1.3.5.2.4.2.1
SKA1-SYS_REQ- Operations construction of scheduling blocks
2292
Operations: Operations shall be responsible for constructing an executable schedule and Scheduling Blocks and submitting for execution.
1.3.5.2.4.3
SKA1-FLD-986
Short term schedule construction tool
1.3.5.2.4.3.1
SKA1-SYS_REQ- Short term schedule construction tool.
2293
Short term schedule construction tool. There shall be an interactive tool to aid the proposer in constructing Scheduling Blocks and an executable schedule.
Parent Comment General
Wallace Turner
10 July 2015
TM comment
With these requirements [L1RS] specifies that certain functions shall be
performed using
Scheduling Blocks.
Clarification: End user may wish to decide ordering. What is the definition of
“short term”
here? Time based? Or some other definition (e.g. related Sbs).
The implied functional requirement seems to be missing; "aid the proposer " is
very vague.
Parent Comment General
Wallace Turner
10 July 2015
TM Feedback: This seems to contradict requirement SKA1-SYS_REQ-2292.
That requirement states that Operations will construct the executable schedule
and Scheduling Blocks, and on the other hand this requirement asks for an
interactive tool for _Proposers_ to construct Scheduling Blocks. We will discuss
this with Gary Davis, but I see two kinds of solutions: either the Proposer
constructs a high-level view of the schedule, and the final Scheduling Blocks are
still to be written by Operations, or both Operations and Proposers can build
Scheduling Blocks, but they will need to be vetted by Operations.
General
Wallace Turner
10 July 2015
I agree this needs to be reworded as I don't think the proposer is defining the
final scheduling block but providing input to its creation. I also think the term
scheduling block needs to be defined as the term is also used for the equivalent
of a "scan" in VLA terminology.
General
Wallace Turner
10 July 2015
Yes, we need better definition of Scheduling Blocks. However, the current
assumption within TM is that SBs will be super-sets of scans, similarly to ALMA.
Parent Comment General
Alan Bridger
28 August 2015
For complete requirements I would suggest that indeed discussions with Gary
are required to establish the Operational requirements - does the proposer
prepare SBs for Operations to validate, or does Operations construct them? Or
some mix. ALMA has the aim of the proposer preparing SBs, but in the short
term (as the observatory learns how to operate, making SB construction an
21/09/2015 7:42 am
Page
161 of 196
expert task) it started with regional support staff creating SBs.
At the moment one approach for the L1 requirements would be to remove
identification of the user and establish that a tool shall be provided to allow the
construction of Scheduling Blocks for a project, the plan of execution of them
within a project and the detailed schedule (sequence) of operations within a
Scheduling Block.
There is also a possible confusion over the meaning of the term "schedule". It
needs disambiguation. One form the is schedule (or plan) of Scheduling Blocks
to be executed, another is the schedule (sequence) of detailed operations within
a Scheduling Block. In my statement here I suggest possible alternative terms in
parentheses.
1.3.5.2.4.4
SKA1-FLD-1431 API for construction of schedule
1.3.5.2.4.4.1
SKA1-SYS_REQ- API for construction of schedule
2646
API for construction of schedule. There shall be an API or APIs for the construction of scheduling blocks from Python and Java.
Parent Comment General
Wallace Turner
10 July 2015
Parent Comment General
Wallace Turner
10 July 2015
Parent Comment General
Wallace Turner
10 July 2015
TM comment
Change: Requirement is unclear. To clarify, express the requirement in terms of:
- who is (or what is the observatory role of) the user of the API
- what observatory function(s) "creating schedule blocks" is part of
Change: Replace "..from Python..." with "...that supports Python..."
Parent Comment General
Wallace Turner
10 July 2015
JSV
Note SDP have raised a comment on the same requirement which also has a
seperate ticket
Parent Comment General
Wallace Turner
10 July 2015
JSV
I suggest that we rewrite this requirement as:
21/09/2015 7:42 am
SDP comment
Explicit language specification should not be the domain of L1. Providing
examples or categories of language support is the most that should be specified.
SDP FG:
Unless L2 & L3 requirements show that this L1 req is a problem, I suggest we
ignore it.
Page
162 of 196
There shall be an API or APIs accessible for implementing scheduling blocks
An additional requirement on languages for the observatory could probably come
as part of the Operations Requirements Document.
Parent Comment General
Wallace Turner
1.3.5.2.4.5
Simulated execution of scheduling blocks.
SKA1-FLD-987
10 July 2015
Reply
Suggest (needs further work)
There shall be an API or APIs accessible for implementing scheduling blocks
that supports Python and Java
1.3.5.2.4.5.1
SKA1-SYS_REQ- Simulated execution of scheduling blocks.
2294
Simulated execution of scheduling blocks. The scheduling tool shall offer the option to simulate execution of Scheduling Blocks in order to verify correctness and
scientific performance at some limited level of accuracy.
Parent Comment Issue
Michael Rupen
31 August 2015
Might be a good idea to require that one be able to run the simulator at arbitrary
times (i.e., one can lie about the current LST), and that the simulator run much
faster than real time (i.e., need not wait for the actual duration of a scan before
moving to the next). This sounds silly but both of these precepts were violated
by the ALMA simulator, leading to some painful moments in commissioning.
1.3.5.2.4.6
SKA1-FLD-1533 Operator control
1.3.5.2.4.6.1
SKA1-SYS_REQ- Operator control
2735
Operator control. It shall be possible for the operator to take manual control of the telescope.
Parent Comment Proposed Change Michael Rupen
31 August 2015
Possibly this should be "of any or all subarrays, or of the full telescope"?
1.3.5.2.5
SKA1-FLD-965
Response to internal detections of transients
1.3.5.2.5.1
SKA1-FLD-989
Responses to transients
1.3.5.2.5.1.1
SKA1-SYS_REQ- Responses to transients
2296
Responses to transients Responses shall be one of the following (a) invoking a special mode on the telescope of origin, (b) issuing a VOEvent, (c) issuing a TOO
announcement to SKA Telescopes, (d) no action.
Parent Comment General
Parent Comment Issue
21/09/2015 7:42 am
John Bunton
Michael Rupen
31 August 2015
31 August 2015
VOE and TOO are acronyms that should be spelt out
Page
163 of 196
1.
2.
3.
4.
1.3.5.2.5.2
SKA1-FLD-990
Use of "mode" here is a little dangerous, since modes are now being fully
enumerated and defined. One response for instance might simply be to
extend the current observations on the target field, or to add a cadenced
set of observations to the scheduling queue -- are these "special modes"?
What is a "transient" here? Does this mean (a) an internally-generated
trigger; (b) something detected by pulsar search; (c) any astronomical
transient source; (d) something else?
If there is any kind of pre-approved real-time response, which many
astronomers want, the response to very fast transients like FRBs, cosmic
ray showers, and the like, need not and really should not go through TM at
all. The obvious allocation for such events would be to CSP and SDP.
Interpretation of requirements should not rest on the headings for the
sections in which they reside...
Observing mode latency
1.3.5.2.5.2.1
SKA1-SYS_REQ- Observing mode latency
2297
Observing mode latency The maximum allowed latency between event and detection shall be allowed to be Observing Mode dependent.
Parent Comment General
Wallace Turner
10 July 2015
TM comment
Change: Observing Modes should be defined.
Change: The latencies for each Observing Mode should be defined.
Change: There should be allocation of latency to elements and for modes that
are refered
to in this requirement.
TM cannot use this requirement because it does not put any constraint on the
TM.
Parent Comment Issue
Michael Rupen
31 August 2015
Please define "event" and "detection", in a way which does not require detailed
knowledge of the immediate context of the requirement. My _guess_ here is that
"event" means "a fast astronomical transient event" (with "fast" meaning "faster
than an integration time as seen by SDP"), while "detection" means "reporting to
TM" or "notification to a system which has to react" (e.g., the transient buffer).
How this depends on Observing Mode as currently defined is not clear to me.
1.3.5.2.5.3
SKA1-FLD-991
1.3.5.2.5.3.1
SKA1-SYS_REQ- Rules for issuing VOEvents
2298
21/09/2015 7:42 am
Rules for issuing VOEvents.
Page
164 of 196
Rules for issuing VOEvents Proposals to search for transients shall include rules for issuing VOEvents.
Parent Comment General
Michael Rupen
31 August 2015
Should be "transient sources" or some such.
1.3.5.2.5.4
SKA1-FLD-992 Latency of initiating response
1.3.5.2.5.4.1
SKA1-SYS_REQ- Latency of initiating a response.
2299
Latency of initiating a response. Response to an event shall be initiated within 1 second of notification.
Parent Comment General
Michael Rupen
31 August 2015
Again, what is "notification"? Does this apply to external or internal triggers? As
written I would guess "both" but 1 second seems a very arbitrary choice.
1.3.5.2.6
SKA1-FLD-966
21/09/2015 7:42 am
Response to external detections of transients
Page
165 of 196
1.3.5.2.6.1
SKA1-FLD-994
VOEvent issue latency
1.3.5.2.6.1.1
SKA1-SYS_REQ- VOEvent issue latency.
2301
VOEvent issue latency. A qualifying VOEvent shall lead to initiation of a response by the Telescope Manager within 1 second.
Parent Comment General
Wallace Turner
10 July 2015
Rev6A comment Mark Waterson
Clarify - is this in addition to the execution for a response? what are the limits?
1.3.5.2.7
SKA1-FLD-967 Telescope model
The telescope model is shared across the entire Telescope. It describes the telescope via:
•
•
•
•
Structural and behavioural models
Specific equations, such as geodetic, geometric, antennas, pointing
Configuration parameters such as frequency setups, pointing, sky direction,
Labelling information such as names and ids
Parent Comment General
1.3.5.2.7.1
Wallace Turner
10 July 2015
TM comment
This requirement needs to be replaced with requirements that specify the
intended
functions.
SKA1-FLD-1429 Telescope Model
1.3.5.2.7.1.1
SKA1-SYS_REQ- Telescope Model
2645
Telescope model. A dynamic computational model of the Telescope shall be used to answer all queries about the state of the Telescope. The telescope model shall
consist of configuration information, numerical models, empirical parameters, and conventions.
Parent Comment Issue
Michael Rupen
31 August 2015
As written it sounds like TM is not allowed to query actual hardware to find out
the state of the Telescope. Think about re-wording this to say that the Telescope
Model should be based on current reality...i.e., it should be *accurate* as well as
complete!
Also, is this Telescope Model archived? Again as written the requirement says
that this Model "shall be used to answer all queries about the state of the
Telescope", not only now, but in the past.
1.3.5.2.7.2
SKA1-FLD-995
21/09/2015 7:42 am
Single geodetic model
Page
166 of 196
1.3.5.2.7.2.1
SKA1-SYS_REQ- Single geodetic model (Telescopes).
2302
Single geodetic model (Telescopes). There shall be a single geodetic model for all telescopes, published as part of the Telescope Model.
1.3.5.2.7.3
SKA1-FLD-996
Single geometric model
1.3.5.2.7.3.1
SKA1-SYS_REQ- Single geometric model.
2303
Single geometric model. There shall be a single geometric model for all receptor types, published by TM.
1.3.5.2.7.4
SKA1-FLD-997
Dish pointing model
1.3.5.2.7.4.1
SKA1-SYS_REQ- Dish pointing model.
2304
Dish pointing model. The dish receptor system shall include a model for pointing including structural model, thermal model, reference pointing model, and refraction
model, published by TM.
1.3.5.2.7.5
SKA1-FLD-998
AA element and station beam model
1.3.5.2.7.5.1
SKA1-SYS_REQ- AA element and station beam model.
2305
AA element and station beam model. The AA receptor system shall include a model for element and station beams as a function of azimuth and zenith angle,
frequency, and polarisation, published by TM.
1.3.5.2.8
SKA1-FLD-968
Forensic analysis of telescope behaviour
1.3.5.2.8.1
SKA1-FLD-999
Forensic tool for telescope behaviour
This will draw upon the monitor data archive, the System Configuration database, Alarm Log, Calibration data, and other related sources of information.
Parent Comment General
21/09/2015 7:42 am
Wallace Turner
10 July 2015
TM comment
Change: Observing Modes should be defined.
Change: The latencies for each Observing Mode should be defined.
Change: There should be allocation of latency to elements and for modes that
are refered
to in this requirement.
TM cannot use this requirement because it does not put any constraint on the
Page
167 of 196
TM.
JSV
My comment to TM:
This requirement shall be informed by the Operations Requirements Document,
but also from the FMEA/FMECA analysis that TM needs to perform. Any further
insight on this requirement from TM?
Parent Comment General
Wallace Turner
10 July 2015
Parent Comment General
Wallace Turner
10 July 2015
TM Paul Swart
TM scope is to perform FMEA for TM only, not for Telescope. We are looking
into TM support for diagnostics. See Google doc (WIP)
https://docs.google.com/a/ska.ac.za/document/d/12xeNglJ4IZImVDKNFf3xWXpo
TySJQ33-Ptdf2FufQfw/edit?usp=sharing
Parent Comment General
Wallace Turner
10 July 2015
JSV
The intention from the panel was that FMEA analysis needed to be performed in
order to be able to inform TM support for diagnostics. This should be discussed
with Gary Davis and Corrie Taljaard.
1.3.5.2.8.1.1
SKA1-SYS_REQ- Forensic tool for telescope behaviour
2306
Forensic tool for telescope behaviour There shall be an interactive forensic tool for evaluating and understanding the state and behaviour of the system at any one
time.
1.3.5.2.8.2
SKA1-FLD-1000 Interfaces
1.3.5.2.8.2.1
SKA1-SYS_REQ- Interfaces.
2307
Interfaces. The interactive forensic tool shall have an Internet interface with availability on a range of platforms including desktop and mobile devices.
1.3.5.2.8.3
SKA1-FLD-1001 Replay of sequences
1.3.5.2.8.3.1
SKA1-SYS_REQ- Replay of sequences.
2308
Replay of sequences. The interactive forensic tool shall allow replay of selected sequences.
1.3.5.2.9
SKA1-FLD-969
1.3.5.2.9.1
SKA1-FLD-1002 Active alarms
21/09/2015 7:42 am
Alarms
Page
168 of 196
1.3.5.2.9.1.1
SKA1-SYS_REQ- Active alarms.
2309
Active alarms. Alarm notification shall be active (via SMS, email, etc.) rather than passive (requiring an Operator query)
1.3.5.2.9.2
SKA1-FLD-1003 Alarm filtering
1.3.5.2.9.2.1
SKA1-SYS_REQ- Alarm filtering.
2310
Alarm filtering. It shall be possible to filter alarms individually or by group.
1.3.5.2.9.3
SKA1-FLD-1005 Alarm latency
1.3.5.2.9.3.1
SKA1-SYS_REQ- Alarm latency.
2312
Alarm latency. Latency from event to alarm shall be no more than 5 seconds.
Parent Comment General
Michael Rupen
31 August 2015
Needs a system-level allocation to the elements.
Need a list of events and alarms for this to be meaningful.
1.3.5.3
SKA1-FLD-1012 Science Data processor
1.3.5.3.1
SKA1-FLD-1526 Calibration and imaging formalism
1.3.5.3.1.1
SKA1-SYS_REQ- Calibration and Imaging formalism
2729
Calibration and imaging formalism. The Calibration and Imaging formalism shall be based upon the Rau framework [18].
Parent Comment General
21/09/2015 7:42 am
Wallace Turner
10 July 2015
SDP comment:
First, we object to the term ‘The Rau framework’. Second, why is a specific
framework mentioned as Level 1 requirement? Any framework that is able to
meet the requirements should be ok.
Page
169 of 196
Parent Comment General
Wallace Turner
10 July 2015
SDP FG:
Is this a major issue? If not then I recommend
Jul 10, 2015, 8:03 AM Page 130 of 157
to revisit this issue when L2 & L3 requirements are defined.
Parent Comment General
Wallace Turner
10 July 2015
Reply to SDP SDP/FG
As per FG's suggestion, keep requirement at present and raise an ECP is
necessary
No further action required
1.3.5.3.2
SKA1-FLD-1013 Calibration model
1.3.5.3.2.1
SKA1-FLD-1014 Closed loop calibration
1.3.5.3.2.1.1
SKA1-SYS_REQ- Closed loop calibration.
2319
Closed loop calibration. The telescope calibration shall be solved by comparison of observed with GSM predictions with a time scale appropriate to the component
and physical effect being calibrated and fed back to the telescope.
Parent Comment Issue
Michael Rupen
31 August 2015
GSM is defined in the glossary at the front as "Global System for Mobile
Communications." I suspect you actually intend "Global Sky Model", so
something needs to change...
Parent Comment Proposed Change Michael Rupen
31 August 2015
"...comparison of observed with..." -- observed *what*? Visibilities? Power
levels?
As written this seems to exclude calibration by means of noise diodes (which I'm
told we'll have), a priori knowledge (e.g., of digital effects), and anything not
embedded in a sky model. This is overly restrictive -- how about "Telescope
calibration shall include..." or "shall be based in part on...".
Do we need to state that this is to be done in real time?
1.3.5.3.3
SKA1-FLD-1017 Imaging model
21/09/2015 7:42 am
Page
170 of 196
1.3.5.3.3.1
SKA1-FLD-1018 Global Sky Model
1.3.5.3.3.1.1
SKA1-SYS_REQ- Global sky model.
2322
Global sky model. Calibration and continuum subtraction shall use a Local Sky Model, derived from a Global Sky Model or previous Local Sky Model.
Parent Comment General
Wallace Turner
10 July 2015
SDP comment
This needs to be a little more specific. For calibration perhaps: "self-calibration
shall be initialised from previous
observations by SKA or other telescopes". Continuum subtraction and further
calibration will be more likely to use an iterative LSM.
Parent Comment General
Wallace Turner
10 July 2015
SDP FG
Needs further discussion with SKAO regarding calibration scheme and error
budgets.
1.3.5.3.3.2
SKA1-FLD-1020 Multi-frequency synthesis imaging
1.3.5.3.3.2.1
SKA1-SYS_REQ- Multi-frequency synthesis imaging.
2324
Multi-frequency synthesis imaging. All imaging shall construct and make use of frequency dependent image models over the entire observed bandwidth.
Parent Comment Proposed Change Ferdl Graser
31 August 2015
"All imaging" is too strong a statement - MFS is not appropriate for imaging
spectral line or polarised sources (especially with Rotation Measure work). It
is also (we hope) not required for the fast imaging pipeline where we
currently do not plan to do any deconvolution.
Additionally, this requirement could be read as implying that MFS needs to
work across the whole band simultaneously - e.g. from 50MHz up to
350MHz. To do this we would need to match pixels on the sky, meaning 7x
more pixels on a side then the natural resolution and FoV would give. This is
costly (about 5-10 times more FLOPS overall). Please consider whether we
can use sub-bands for this, and include an additional requirement specifying
the required fractional bandwidth for a sub-band.
1.3.5.3.3.3
SKA1-FLD-1021 Deconvolution of single channels
1.3.5.3.3.3.1
SKA1-SYS_REQ- Scale sensitive deconvolution
2325
21/09/2015 7:42 am
Page
171 of 196
Deconvolution of single channels Scale sensitive two-dimensional (i.e. on the tangent plane) deconvolution shall be available.
Parent Comment Issue
Michael Rupen
31 August 2015
Title refers to single channels while actual requirement does not. This is bad
practice...the two should match, and the interpretation of the actual requirement
text should not require knowledge of the title.
Parent Comment General
Michael Rupen
31 August 2015
This seems an L2 rather than an L1 requirement -- presumably the L1 is that the
data product includes information on a variety of spatial scales, with a defined
fidelity and dynamic range, and it is up to SDP to decide how best to meet that
requirement.
1.3.5.3.3.4
SKA1-FLD-1024 Solution for pointing errors
Pointing self-calibration has been demonstrated on EVLA data.
1.3.5.3.3.4.1
SKA1-SYS_REQ- Solution for pointing errors.
2328
Solution for pointing errors. It shall be possible to solve for and correct time- and station-dependent pointing errors with accuracy and timescale limited by signal to
noise ratio.
Parent Comment Issue
Michael Rupen
31 August 2015
This implies that the only limit on such corrections is SNR, which seems quite an
assumption -- there may for instance be degeneracies between these and other
types of corrections, or even in the pointing corrections themselves.
As written there is no requirement that the SKA telescope solve for any of this -a mere theoretical demonstration would suffice. Re-phrase to require the actual
existence of such a solver within SKA1.
The input data and SNR here are not defined. I could imagine saying "OK, we'll
do this with an optical telescope attached to each dish with a specified offset."
Isn't the L1 really that we achieve a given pointing accuracy, before and after
correcting the pointing errors in this way and that, and under various observing
conditions?
Is this meant to be a real-time correction (feedback loop), or are we just talking
about the image plane? If the latter, doesn't this fall out of requirements on the
dynamic range, fidelity, etc. of the images? Again I would argue this is not an L1
requirement.
1.3.5.3.3.5
SKA1-FLD-1026 Peeling
Peeling is defined as the solution for and subtraction of both source model and calibration parameters for a relatively compact source.
1.3.5.3.3.5.1
SKA1-SYS_REQ- Peeling.
2330
21/09/2015 7:42 am
Page
172 of 196
Peeling. Peeling of bright sources (strength limited by signal to noise ratio) from the visibility data shall be possible.
Parent Comment Issue
Michael Rupen
31 August 2015
Once again what is important is the quality of the data products, NOT the
method(s) used to achieve that quality. These are lovely L2s but don't belong
among the top-level telescope requirements.
1.3.5.3.4
SKA1-FLD-1016 Direction dependent effects
1.3.5.3.4.1
SKA1-SYS_REQ- Direction dependent effects.
2321
Direction dependent effects. Self-calibration and image reconstruction algorithms shall be capable of dealing with direction dependent effects.
Parent Comment Issue
Michael Rupen
31 August 2015
See above comments. This isn't an L1, and if it were, it's not actually a
requirement. I can "deal with" direction-dependent effect by acknowledging or
ignoring them, or just flagging out parts of the image where they're important. It's
the required quality and coverage of the data products that gives this
"requirement" teeth.
1.3.5.3.4.2
SKA1-SYS_REQ- Aperture Array DDE
2724
Aperture Array DDE. There shall be a direction dependent model for the aperture array primary beam to be used in calibration and imaging.
Parent Comment General
Michael Rupen
31 August 2015
Need a requirement on the accuracy of this model, which makes me wonder
whether this doesn't really belong in an ICD rather than in the L1s.
1.3.5.3.4.3
SKA1-SYS_REQ- Dish DDE
2727
Dish DDE. There shall be a direction dependent model for the dish primary beam to be used in calibration and imaging.
Parent Comment General
Michael Rupen
31 August 2015
Why is this not also allocated to DISH?
1.3.5.3.4.4
SKA1-SYS_REQ- Faraday Rotation DDE
2725
Faraday rotation DDE. There shall be a direction dependent Faraday Rotation model for use in calibration and imaging.
Parent Comment General
Michael Rupen
1 September 2015 Again, it might be more appropriate to specify the polarization fidelity/purity.
1.3.5.3.5
SKA1-FLD-1029 Image processing model
1.3.5.3.5.1
SKA1-FLD-1030 Continuum source finding
1.3.5.3.5.1.1
SKA1-SYS_REQ- Continuum source finding.
2333
Continuum source finding. Where appropriate, continuum source finding shall be conducted on images generated by the Continuum Imaging pipeline. Polarization
shall be fitted if available.
21/09/2015 7:42 am
Page
173 of 196
Parent Comment General
Michael Rupen
1 September 2015
"Where appropriate" -- should this be "when commanded"?
Why would polarization not be available? Other requirements specify that we
always collect full pol'n data.
1.3.5.3.5.2
SKA1-FLD-1031 Spectral line source finding
1.3.5.3.5.2.1
SKA1-SYS_REQ- Spectral line source finding.
2334
Spectral line source finding. Where appropriate, spectral line source finding shall be conducted on image cube generated by the Spectral Line pipeline.
Parent Comment General
Michael Rupen
1 September 2015 Again, "where appropriate" should presumably be "when so commanded",
unless "appropriate" is defined somewhere.
1.3.5.3.5.3
SKA1-FLD-1032 Stacking
1.3.5.3.5.3.1
SKA1-SYS_REQ- Stacking.
2335
Stacking. Where appropriate, spectral line stacking shall be conducted on image cubes generated by the pipelines using a priori known source lists.
Parent Comment General
Wallace Turner
10 July 2015
Rev6 comment James Green
Sorry not RBS related but spotted this: Not sure that 'spectral line stacking' is
appropriate here, should probably be just 'stacking', as this applies to continuum
as well
Parent Comment General
Wallace Turner
10 July 2015
Rev6 comment Mark Waterson
Maybe should be a bit more specific about defining "stacking" anyway?
Parent Comment General
Wallace Turner
10 July 2015
Reply to James:
Action remove "spectral line" from requirement
Parent Comment General
Michael Rupen
1 September 2015
"Spectral line stacking" often refers to stacking multiple spectral lines on a given
location to increase the likelihood of a detection (mostly for radio recombination
lines). This should be done but does not seem to be what's intended here.
I think what is meant here is something like:
When so instructed, signals shall be added at the location of a user-supplied list
of locations, to allow a statistical detection even when sources cannot be
detected individually.
1.3.5.3.6
SKA1-FLD-1033 Pipelines
21/09/2015 7:42 am
Page
174 of 196
1.3.5.3.6.1
SKA1-FLD-1034 Standard pipeline products
1.3.5.3.6.1.1
SKA1-SYS_REQ- Standard pipeline products.
2336
Standard pipeline products. All pipelines shall include as data products the pipeline processing log, and Quality Assessment log.
Parent Comment General
Wallace Turner
10 July 2015
SDP comment
These data products need to be defined. I suggest a data dictionary is included
somewhere in the requirements that can be referred to throughout this section
for data products.
Parent Comment General
Wallace Turner
10 July 2015
SDP FG:
Data products can be defined in L2 & L3 requirements. If SKAO does not accept
our L2 requirements, then we can do an ECP.
1.3.5.3.6.10
SKA1-FLD-1044 Slow transient data products
1.3.5.3.6.10.1
SKA1-SYS_REQ- Slow transient data products.
2346
Slow transient data products. The data products shall include a catalogue of found sources, a sensitivity image, and representative PSF image.
Parent Comment Proposed Change Ferdl Graser
31 August 2015
Please revisit this and justify why we need to save IMAGES for the fast
imaging work - our anticipated output is a time-series catalogue of the flux
densities of sources found to be varying (with associated uncertainty limits).
Whilst a sensitivity image might be nice to have to put upper limits on fluxes
of objects that are subsequently bright enough to detect, the additional data
rate into the archive will be large. Same goes for PSF image.
General
1.3.5.3.6.11
1.3.5.3.6.11.1
Michael Rupen
1 September 2015
A compromise might be the min/max of the sensitivity image (per timescale of
transient), along with some simple statistics (mean, mode, median, and
histogram of pixels), together with values at some specified coordinates (to allow
a user-specified list of "important locations").
SKA1-FLD-1045 Automated Quality Assessment
SKA1-SYS_REQ- Automated Quality Assessment.
2347
Automated Quality Assessment. All pipelines shall perform standardised, automated Quality Assessment of Images along the axes of astrometry, photometry,
radiometry, polarimetry, and spectrometry.
Parent Comment General
Wallace Turner
10 July 2015
TM comment
It is not clear where boundaries of responsibility between TM and SDP lie for
these
requirements.
21/09/2015 7:42 am
Page
175 of 196
Also, add a requirement for telescopes to visually indicate data quality to the
operator,
and allocate this to either TM or SDP.
1.3.5.3.6.11.2
SKA1-SYS_REQ- Performance assessment
2742
Performance assessment: Performance assessment shall be based on multi-valued functions of an observed Image and optionally a template Image.
Parent Comment General
Wallace Turner
10 July 2015
TM comment
It is not clear where boundaries of responsibility between TM and SDP lie for
these
requirements.
Also, add a requirement for telescopes to visually indicate data quality to the
operator,
Jul 10, 2015, 8:03 AM Page 135 of 157
and allocate this to either TM or SDP.
1.3.5.3.6.11.3
SKA1-SYS_REQ- Performance goals
2743
Performance Goals: Performance goals shall be based on multi-valued functions of an observed Image and optionally a template Image.
1.3.5.3.6.11.4
SKA1-SYS_REQ- Quality assessment
2744
Quality assessment: Quality assessment shall be based on the comparison of a Performance Assessment and a Performance Goal.
Parent Comment General
Wallace Turner
10 July 2015
TM comment
It is not clear where boundaries of responsibility between TM and SDP lie for
these
requirements.
Also, add a requirement for telescopes to visually indicate data quality to the
operator,
and allocate this to either TM or SDP.
Parent Comment General
Wallace Turner
10 July 2015
TM comment
It is not clear where boundaries of responsibility between TM and SDP lie for
these
requirements.
Also, add a requirement for telescopes to visually indicate data quality to the
operator,
and allocate this to either TM or SDP.
21/09/2015 7:42 am
Page
176 of 196
1.3.5.3.6.11.5
SKA1-SYS_REQ- Astrometry performance metric
2745
Astrometric performance metric: The Astrometric performance metric (APM) shall measure deviation (rms, average offset, and med) of source positions from known
standards.
Parent Comment General
Wallace Turner
10 July 2015
TM comment
It is not clear where boundaries of responsibility between TM and SDP lie for
these
requirements.
Also, add a requirement for telescopes to visually indicate data quality to the
operator,
and allocate this to either TM or SDP.
1.3.5.3.6.11.6
SKA1-SYS_REQ- Photometric performance metric
2746
Photometric performance metric: The Photometric performance metric (PPM) shall measure deviation (rms, average offset, and med) of source fluxes from known
standards.
Parent Comment General
Wallace Turner
10 July 2015
TM comment
It is not clear where boundaries of responsibility between TM and SDP lie for
these
requirements.
Also, add a requirement for telescopes to visually indicate data quality to the
operator,
and allocate this to either TM or SDP.
1.3.5.3.6.11.7
SKA1-SYS_REQ- Radiometric performance metric
2747
Radiometric performance metric: The Radiometric performance metric (RPM) shall measure noise fluctuations (rms, average offset, and med) in an Image.
Parent Comment General
Wallace Turner
10 July 2015
TM comment
It is not clear where boundaries of responsibility between TM and SDP lie for
these
requirements.
Also, add a requirement for telescopes to visually indicate data quality to the
operator,
and allocate this to either TM or SDP.
1.3.5.3.6.11.8
SKA1-SYS_REQ- Polarimetric performance metric
2748
Polarimetric performance metric: The Polarimetric performance metric (OPM) shall measure deviation (rms, average offset, and med) of source polarisations
(polarisation degree and angle) from known standards.
21/09/2015 7:42 am
Page
177 of 196
Parent Comment General
Wallace Turner
10 July 2015
TM comment
It is not clear where boundaries of responsibility between TM and SDP lie for
these
requirements.
Also, add a requirement for telescopes to visually indicate data quality to the
operator,
and allocate this to either TM or SDP.
1.3.5.3.6.11.9
SKA1-SYS_REQ- Spectrometric performance metric
2749
Spectrometric performance metric: The Spectrometric performance metric (SPM) shall measure deviation (rms, average offset, and med) of source spectral lines
from known standards.
Parent Comment General
Wallace Turner
10 July 2015
TM comment
It is not clear where boundaries of responsibility between TM and SDP lie for
these
requirements.
Also, add a requirement for telescopes to visually indicate data quality to the
operator,
and allocate this to either TM or SDP.
1.3.5.3.6.2
SKA1-FLD-1036 Calibration pipeline
1.3.5.3.6.2.1
SKA1-SYS_REQ- Calibration pipeline.
2338
Calibration pipeline. There shall be a Calibration pipeline that derives current telescope parameters using a recent observation and a Global Sky Model, either a
known GSM or the most recent GSM.
Parent Comment General
Michael Rupen
1 September 2015 GSM is defined differently in the glossary at the front of this document.
1.3.5.3.6.3
SKA1-FLD-1037 Continuum imaging pipeline
1.3.5.3.6.3.1
SKA1-SYS_REQ- Continuum imaging pipeline.
2339
Continuum imaging pipeline. There shall be a Continuum Imaging pipeline that shall have the goal of constructing noise-limited wide-band images for observations
up to 1000h integration time. Polarisation shall be available if requested or necessary for calibration or quality assurance.
1.3.5.3.6.4
SKA1-FLD-1038 Continuum imaging data products
1.3.5.3.6.4.1
SKA1-SYS_REQ- Continuum imaging data products.
2340
Continuum imaging data products. The Data Products shall include the first n moment images for multi-frequency synthesis, corresponding residual images (if
deconvolved), sensitivity image and representative PSF image, where n is set by signal to noise ratio.
21/09/2015 7:42 am
Page
178 of 196
1.3.5.3.6.5
SKA1-FLD-1039 Spectral line emission pipeline
1.3.5.3.6.5.1
SKA1-SYS_REQ- Spectral line emission pipeline.
2341
Spectral line emission pipeline. There shall be a Spectral Line Emission pipeline that is optimised for constructing noise-limited (up to 1000h integration) channel
cubes of spectral line emission either with continuum emission remaining or with continuum emission removed.
Parent Comment General
Wallace Turner
10 July 2015
SDP comment
I think the intent of the requirement is fine, but the wording is open to much
interpretation, and in particular makes a
verification requirement difficult to construct. I would prefer to remove the word
"optimised" and replace it with some hard specification with a tolerance. In reality
we will have
some uncertainty with regard to the noise floor, and cannot verify beyond this.
How about we reword as follows "...pipeline that constructs noise-limited (+/TBD % for up to 1000h integration) channel cubes..."
Parent Comment General
Wallace Turner
10 July 2015
SDP FG:
Tollerance, etc. can be defined in the L2 requirement. If SKAO does not accept
these L2 requirement, we can then
raise an ECP.
General
1.3.5.3.6.6
Michael Rupen
1 September 2015
I am uncomfortable with having all data product requirements embedded in L2
requirements, which are less broadly reviewed than the L1s. This is a general
comment applicable to many of the L1s.
SKA1-FLD-1040 Spectral line emission data products
1.3.5.3.6.6.1
SKA1-SYS_REQ- Spectral line emission data products.
2342
Spectral line emission data products. The data products shall include spectral line cube image, continuum model images, sensitivity image, and representative
point spread function.
Parent Comment General
Michael Rupen
1 September 2015 I suggest the L1s define at least a subset of data products for each observing
mode. That would go some way towards ensuring full coverage and some level
of review.
1.3.5.3.6.7
SKA1-FLD-1041 Spectral line absorption pipeline
1.3.5.3.6.7.1
SKA1-SYS_REQ- Spectral line absorption pipeline.
2343
Spectral line absorption pipeline. There shall be a Spectral Line Absorption pipeline that is optimised for constructing noise-limited channel cubes of spectral line
absorption with continuum sources removed.
21/09/2015 7:42 am
Page
179 of 196
1.3.5.3.6.8
SKA1-FLD-1042 Spectral line absorption data products
1.3.5.3.6.8.1
SKA1-SYS_REQ- Spectral line absorption data products.
2344
Spectral line absorption data products. The data products shall include spectral line cube image, continuum model images, sensitivity image, and representative
point spread function.
1.3.5.3.6.9
SKA1-FLD-1043 Slow transient pipeline
1.3.5.3.6.9.1
SKA1-SYS_REQ- Slow transient pipeline.
2345
Slow transient pipeline. There shall be a Slow Transient imaging pipeline that shall be capable of constructing a continuum image after a GSM has been subtracted
for every correlator integration time or slower, searching for transient sources, and producing a time-ordered catalogue.
Parent Comment General
Michael Rupen
1 September 2015 Presumably this is "a time-ordered catalogue of transient source candidates."
1.3.5.3.7
SKA1-FLD-1046 Data Products
1.3.5.3.7.1
SKA1-FLD-1609 Archive
1.3.5.3.7.1.1
SKA1-SYS_REQ- Science data archives
2821
Archive. There shall be an archive for each telescope, located in the Science Processing Centre, for storing selected science data products for subsequent access by
users according to science data access policy.
1.3.5.3.7.2
SKA1-FLD-1047 Role of science processing centres
1.3.5.3.7.2.1
SKA1-SYS_REQ- Role of science processing centres.
2348
Role of science processing centres. The science-processing centre will convert the output data from the CSP into science data products to be stored in the science
data archive.
Parent Comment General
Wallace Turner
10 July 2015
SDP FG:
Tollerance, etc. can be defined in the L2 requirement. If SKAO does not accept
these L2 requirement, we can then
raise an ECP.
1.3.5.3.7.3
SKA1-FLD-1049 Mirror sites
21/09/2015 7:42 am
Page
180 of 196
Parent Comment General
Wallace Turner
10 July 2015
Parent Comment General
Wallace Turner
10 July 2015
Rev6A comment Juande Santander-Vela
This looks like a requirement for the Operational Requirement Document.
Consider removing it.
Reply to Juande.
Disagree
No further action
1.3.5.3.7.3.1
SKA1-SYS_REQ- Mirror sites.
2350
Mirror sites. All data within Science Archives shall have a secondary copy located offsite in a secure location.
Parent Comment General
Wallace Turner
10 July 2015
Rev6A comment Juande Santander-Vela
This looks like a requirement for the Operational Requirement Document.
Consider removing it.
Parent Comment General
Wallace Turner
10 July 2015
Reply to Juande.
Disagree
No further action
1.3.5.3.7.4
SKA1-FLD-1051 Web interface
1.3.5.3.7.4.1
SKA1-SYS_REQ- Web interface.
2352
Web interface. The science data archives shall be accessible from the internet via a standardised web interface.
1.3.5.3.7.5
SKA1-FLD-1052 VO interface
1.3.5.3.7.5.1
SKA1-SYS_REQ- Virtual Observatory interface.
2353
Virtual Observatory interface. The science data archives shall be accessible via a set of recommended IVOA services chosen to allow access to all approved data
products.
1.3.5.3.7.6
SKA1-FLD-1053 Archive API
1.3.5.3.7.6.1
SKA1-SYS_REQ- Archive API.
2354
Archive API. The science data archives shall publish a user accessible, open API in a small number of complementary languages such as Python, C++, and Java.
1.3.5.3.7.7
SKA1-FLD-1056 QA annotation
21/09/2015 7:42 am
Page
181 of 196
1.3.5.3.7.7.1
SKA1-SYS_REQ- QA annotation.
2357
QA annotation. The telescope shall facilitate the addition of QA annotations by Users.
Parent Comment General
Wallace Turner
10 July 2015
Rev6 comment Juande Santender-Vela
Propose that TM is also allowed to provide QA annotations via the Proposal
Submission.
Parent Comment General
Wallace Turner
10 July 2015
Reply
Assume comment is resolved by adding TM to allocations
1.3.5.3.7.8
SKA1-FLD-1065 Distribution of data products
1.3.5.3.7.8.1
SKA1-SYS_REQ- Distribution of data products.
2366
Distribution of data products. As limited by resource constraints, it will be possible to deliver science data products to approved off-site facilities, which may be
globally distributed.
1.3.5.3.7.9
SKA1-FLD-1538 Levels of access
Parent Comment General
Ferdl Graser
31 August 2015
Requirements SKA1-SYS_REQ-2688 was removed with the
comment "Authority definition - remove". Don't know how to interpret this
since other requirements on commensal observing still exists and therefore
dropping access control to those products seems odd.
1.3.5.3.7.9.1
SKA1-SYS_REQ- Levels of access to the archive
2739
Levels of access. Access to the archive shall be either anonymous with correspondingly limited capabilities or via SKA authentication and authorisation.
1.3.5.3.8
SKA1-FLD-1440 Early Science
1.3.5.3.8.1
SKA1-FLD-1441 Processing
1.3.5.3.8.1.1
SKA1-SYS_REQ- Processing capability
2657
Processing capability. SDP processing per telescope at Early Science shall support processing rates 10% of that required for Full Observing (decimation being in
any or all of time, frequency, field of view)
1.3.6
SKA1-FLD-1831 Glass box calibration
21/09/2015 7:42 am
Page
182 of 196
1.3.6.1
SKA1-FLD-1880 SKA1_Low Glass box calibration
1.3.6.1.1
SKA1-SYS_REQ- SKA1_Low Glass Box Calibration
3033
Glass box calibration. The SKA1_Low, when commanded, shall reconstruct applied calibration correction parameters up to a time resolution of the data cadence.
1.3.6.1.2
SKA1-SYS_REQ- SKA1_Low Glass Box Calibration
3042
SKA1_Low Glass Box Calibration. The SKA1_Low shall apply calibration correction parameters in a manner that they can by reconstructed.
1.3.6.1.3
SKA1-SYS_REQ- SKA1_Low Glass Box Calibration
3043
SKA1_Low Glass Box Calibration. The SKA1_Mid shall store necessary information for TBD duration such that calibration correction parameters can be
reconstructed.
1.3.6.2
SKA1-FLD-1881 SKA1_Mid Glass box calibration
1.3.6.2.1
SKA1-SYS_REQ- SKA1_Mid Glass Box Calibration
3045
SKA1_Mid Glass Box Calibration. The SKA1_Mid shall store necessary information for TBD duration such that calibration correction parameters can be
reconstructed.
1.3.6.2.2
SKA1-SYS_REQ- SKA1_Mid Glass Box Calibration
3044
The SKA1_Mid shall apply calibration correction parameters in a manner that they can by reconstructed.
1.3.6.2.3
SKA1-SYS_REQ- SKA1_Mid Glass Box Calibration
3034
Glass box calibration. The SKA1_Mid, when commanded, shall reconstruct applied calibration correction parameters up to a time resolution of the data cadence.
1.3.7
SKA1-FLD-948
21/09/2015 7:42 am
Synchronisation and Timing
Page
183 of 196
1.3.7.1
SKA1-FLD-949
Synchronisation
1.3.7.1.1
SKA1-FLD-950
Coherence losses: 1s
1.3.7.1.1.1
SKA1-SYS_REQ- Coherence losses: 1s
2268
Coherence losses 1s. The SKA frequency reference system shall provide a 2% maximum coherence loss, equivalent to 0.2 radians, within a maximum integration
period of 1s.
1.3.7.1.2
SKA1-FLD-1482 Coherence loss : 1 min.
1.3.7.1.2.1
SKA1-SYS_REQ- Coherence loss: 1min
2692
Coherence loss 1min. The SKA frequency reference system shall provide a 2% maximum coherence loss, equivalent to 0.2 radians, within a maximum solution
interval for in-beam calibration of 1 minute.
Parent Comment General
1.3.7.1.3
Wallace Turner
10 July 2015
Rev6 comment Juande Santender-Vela
Is it normal that the coherence loss in 1 minute is the same as for one integration
period?
SKA1-FLD-1483 Frequency reference linear phase drift
1.3.7.1.3.1
SKA1-SYS_REQ- Frequency reference phase drift
2693
Frequency reference phase drift. The SKA Frequency Reference System shall have a phase drift of less than 1 radian, over calibration intervals of up to 10 minutes,
when using out of beam calibration sources.
Parent Comment General
Wallace Turner
1.3.7.1.4
Pulse per Second precision
SKA1-FLD-951
10 July 2015
Rev6 comment Juande Santender-Vela
Are there requirements for phase drift of on-beam calibration sources?
1.3.7.1.4.1
SKA1-SYS_REQ- Pulse per second precision
2269
Pulse per Second precision. The SKA synchronisation and timing system shall provide a 1 pps heartbeat signal, precise to the sampling clock (the pulse-to-pulse
scatter is less than one sampling time), derived from the distributed frequency reference.
1.3.7.1.5
SKA1-FLD-1485 Pulse per second phase relative to UTC
21/09/2015 7:42 am
Page
184 of 196
1.3.7.1.5.1
SKA1-SYS_REQ- Pulse per second phase relative to UTC
2695
Pulse per second phase relative to UTC. The SKA synchronisation and timing system shall provide a 1PPS heartbeat signal with phase relative to UTC that over a
10 minute calibration interval shall survive synchronisation loss.
1.3.7.2
SKA1-FLD-956
Timing
1.3.7.2.1
SKA1-FLD-957
UTC accuracy
1.3.7.2.1.1
SKA1-SYS_REQ- UTC accuracy.
2274
UTC accuracy. The SKA1 timescale shall be connected to UTC with an accuracy of 10 ns, on a timescale of 10 years.
Parent Comment Question
Michael Rupen
1 September 2015 Should this be, "on timescales up to at least 10 years"? Some of the pulsar
requirements were changed to require consistency on all timescales from an
observation up to 10 years; just wondered whether this should be similar.
1.3.7.2.2
SKA1-FLD-958
Central frequency reference
1.3.7.2.2.1
SKA1-SYS_REQ- Central frequency reference
2275
Central frequency reference. In order to avoid large offsets, the central frequency reference shall be steered to UTC to within at least 1 microsecond, with a
frequency drift of less than 10 ns/day.
1.3.7.2.3
SKA1-FLD-959
SKA1 UTC offsets
1.3.7.2.3.1
SKA1-SYS_REQ- SKA1 UTC offsets
2276
SKA1 UTC offsets. The solution period for the calculation of offsets between SKA1 timescale and UTC shall be less than 1 day
1.3.8
SKA1-FLD-1066 Infrastructure
1.3.8.1
SKA1-FLD-1070 Site Monitoring
21/09/2015 7:42 am
Page
185 of 196
1.3.8.1.1
SKA1-SYS_REQ- Weather Monitoring.
2370
Weather Monitoring. Weather monitoring stations (2 No at each core and 2 No within each spiral arm) shall be provided as part of the infrastructure - wind,
temperature and humidity.
Parent Comment General
Wallace Turner
10 July 2015
Rev6 comment Martin Austin
While probably a separate ECP, if LOW no longer has spiral arms then this
needs to be revised to include, say 2 weather stations in LOW outside of the
LOW core.
Parent Comment General
Wallace Turner
10 July 2015
Reply to Martin
Noted
No further action
21/09/2015 7:42 am
Page
186 of 196
1.3.8.1.1
SKA1-SYS_REQ- Weather Monitoring.
2370
Weather Monitoring. Weather monitoring stations (2 No at each core and 2 No within each spiral arm) shall be provided as part of the infrastructure - wind,
temperature and humidity.
General
Shandip Abeywickrema
31 August 2015
Wallace, is there an ECP in the system currently to change this requirement to
suit the new configuration?
Parent Comment Question
Michael Rupen
1 September 2015 What does "2 No" mean??
1.3.8.1.2
SKA1-SYS_REQ- Visual monitoring.
2371
Visual monitoring. The infrastructure shall provide day and night time capability for the operator(s) to visually monitor all antennas: for Dish antennas this shall be at
every dish, for LFAA this shall be located at each station and also around the perimeter of the core area. Monitoring to deliver images at least one per minute for
purposes of security and general telescope visual monitoring and shall be able to detect personnel at each dish and within each LFAA station.
Parent Comment General
Wallace Turner
10 July 2015
Parent Comment General
Wallace Turner
10 July 2015
Parent Comment General
Wallace Turner
10 July 2015
JSV
My comment to TM:
Assessment of visual monitoring to be made as part of the Operations
Requirement Document. Any further insight on this requirement from TM?
Parent Comment General
Wallace Turner
10 July 2015
TM Paul Swart
From discussions with INFRA-SA: Change allocation to INFRA only: INFRA (SA
and AUS) to implement total solution for visual monitoring (scene surveillance,
distribution of images, pan/tilt/zoom control). Rationale for this is that it is likely to
be COTS solution, and vendors can supply total solution, which means its easier
for a single consortium to specify/design/procure than splitting it down the middle
between 2 consortia (INFRA and TM).
TM shall monitor the visual monitoring system which is part of INFRA, via one of
the interfaces between TM and INFRA.
TM possibly will display images that are streamed by the visual monitoring
system.
Parent Comment General
Shandip Abeywickrema
31 August 2015
I understand that there is an ECP in the system to amend this requirement. With
regards the comments from TM regarding allocation, we have not been party to
these discussions, hence can not advise whether the comments are correct or
otherwise. We will discuss with TM in due course.
21/09/2015 7:42 am
TM comment
It is important to know what TM's responsibility is with regards to visual
monitoring.
JSV
My comment to TM: Assessment of visual monitoring to be made as part of the
Operations Requirement Document. Any further insight on this requirement from
TM?
Page
187 of 196
Parent Comment General
Wallace Turner
14 September 2015 The recommendation from the ECP-150008 :
Description:
SKA1-SYS_REQ_2371: Delete existing text and replace with: "Visual monitoring.
Existing visual monitoring systems currently serving the precursor telescopes
shall be retained, upgraded to meet SKA RFI/EMC requirements and
incorporated into the SKA [Any additional visual monitoring equipment TBC]."
NB. This is the purpose of this ECP - to justify any additional visual monitoring
requirements.
SKA1-SYS_REQ-2400: Extend text to read "Communication. All vehicles used
on site shall be equipped with long range emergency communication and GPS
repeater location devices."
Reason:
The Parent Requirement is derived from Health and Safety legislative
requirements. Being able to see operations maintenance/inspection staff at dish
or station locations throughout the SKA by cameras is deemed to be a possible
solution. However areas of travel between such locations would not be covered
by such camera solutions and a combination of GPS based location systems
and emergency radio systems would therefore also be required (similar to that
operating on ASKAP). It is probably more practical and cost effective to meet the
Parent Requirement through systems similar to that at ASKAP both at a
dish/station location and between such locations. The INFRA consortia
combined cost estimate (pre-RBS) for the visual monitoring solutions was circa
Euro 5.4 million including contingency, OHP & P&G's. A net saving of circa E 4 5m could therefore be delivered.
Affected Items:
L1 Requirements:
SKA1-SYS_REQ_2371
SKA1-SYS_REQ-2400
Implementation Reason:
Visual camera solutions have been proposed within both INFRA PDR
submissions (see 2 No attached documents) but all have significant risk
associated with regard to EMC. No further potentially abortive work should be
completed by INFRA consortia except where related to rendering existing visual
monitoring systems compliant and developing only new solutions where these
can be justified. The change should be implemented via ECP early in Stage 2.
21/09/2015 7:42 am
Page
188 of 196
Both INFRA consortia have been requested to provide further supporting
information for ECP Phase 2.
INFRA SA extract Chapter 10: An alternative (Item 3 in Table 3) is to remove the
requirement for visual monitoring from the Level 1 Baseline Requirement and
have no cameras installed (due to the RFI risk). The higher level requirement for
visual monitoring should be investigated as part of the Concept of Operations
and alternative options to cameras should be investigated.
Table 3: Alternative for Visual Monitoring
Item No. of cameras core+spirals
Recommendation
Impact / Risk
1 C79 + S90
Meets L1; does not meet RFI reqs; Large cost
Not recommended
2 C8 + S27
Does not meet L1; does not meet RFI reqs; reduced cost
Not recommended
3
C1 (re
‐use MeerKATcam era
on Losberg with Zoom) + S0 Does not meet L1; meets RFI reqs; small
cost. Recommended
INFRA AUS extract Section 4.9 (part): This [PDR] proposal still required a large
number of cameras - a total of 472 fixed f.o.v. units and 6 PZT units. INAU felt
that this met the baseline requirement and thus was the starting point.
As a further cost saving, and subject to a detailed Stage 2 analysis, we offer a
reduction in the
number of cameras. This would be:
- reduce number of Survey antennas monitored with cameras from 93 to a
selected 12 antennas, appropriately selected to monitor key antennas in core, at
ends of arms, near roads or other key points;
- reduce the number of Low cameras from 44 to 16 on the spiral arm stations
This total reduction of 352 cameras is shown in the Cost Options section of the
Costing report.
Further optimisation of camera numbers and locations is likely during Stage 2
based on final array
configuration, etc.
21/09/2015 7:42 am
Page
189 of 196
Phase 2 Recommendation attached:
It is recommended that the replacement L1 requirements herein limiting visual
monitoring cameras to those for site(s) security purposes only are approved by
the Phase 3 CCB for Phase 6 Implementation.
Proposed replacement L1 requirement SKA1-SYS_REQ-2371 - Visual
monitoring. 24 hour (day and night time) capability shall be provided for
telescope operator(s) to visually monitor security access points [TBD] to each
site and also selected [TBD - see attached document] other locations.
This recommendation is based on the following:
•
•
•
•
21/09/2015 7:42 am
SKAO meeting held 31 Aug 2015 to confirm approach to camera scope.
Agreed that M. AUSTIN/P.DEWDNEY to consult at Host Country Site
Issues meetings on camera requirements for access purposes to the
central site area of each telescope only. No other cameras required. INAU
and INSA consulted by email with their suggested requirements. These are
recorded in the attached email strings (attached to Phase 2 Form) and
summarised as follows:
INAU: Visual (Security) monitoring (post RBS): Fixed fov cameras are
proposed for: - The primary SKA1-Low site entrance gate (2 No cameras) The compound gate at the SKA1-Low CPF (1 No camera) - The power
station connect location (1 No camera) - The accommodation facility (1 No
camera) Total 5 No cameras with the requisite power and data network
connections. However flexibility on camera numbers required possibly to
include for after rain storms to help decide on whether staff vehicular
access is safe.
INSA: - 1 No new camera (with power and fibre) at each of the 3 No Boom
Gates - Existing cameras (Total 3 No.) which will be handed over as
existing MeerKAT assets – they will need to meet SKA EMC requirements:
Losberg Hill (1 No) and two cameras currently being installed in the
MeerKAT core area. - No (Nil) cameras at the 2 No manned gates closer to
the core area. - No (Nil) cameras at the KAPB complex (National Key Point)
security point. Total 3 No new cameras with the requisite power and data
network connections. Small Solar and Vox V-sat for all 3 No Boom gates
seems to be the best idea to pursue.
For both Sites: All cameras will need to be compliant with SKA EMC
requirements. Agreed that with regard to Control Plans - follow though only
on red items seems a pragmatic approach for RFI and cameras in
particular. Where the images go will be in accordance with the SKAO
Operations Plan. The precise number of cameras required at each site to
be determined in Phase 6.
Page
190 of 196
1.3.8.1.3
SKA1-SYS_REQ- RFI Monitoring
2730
RFI Monitoring. The SKA1_Mid and SKA1_Low shall be monitored for RFI in accordance with RFI standards document [4]
Parent Comment General
Michael Rupen
1 September 2015
Does this refer to the data produced by the telescopes, or the telescope sites, or
some combination of both? I'd argue for the latter but it could be spelled out in
more detail.
This should also be stored in a data base but I think that's covered elsewhere.
1.3.8.2
SKA1-FLD-1071 Tropospheric Monitoring
1.3.8.2.1
SKA1-SYS_REQ- Tropospheric Monitoring.
2372
Tropospheric Monitoring. Existing Tropospheric monitoring stations shall be expanded as part of the SKA1 infrastructure to provide at least 3 No sensor units in
each of the Australia and South Africa locations.
Parent Comment Question
Michael Rupen
1 September 2015 What is a "No sensor unit"?
1.3.8.3
SKA1-FLD-1072 Power
1.3.8.3.1
SKA1-SYS_REQ- Low RFI power delivery.
2373
Low RFI power delivery. The power delivery infrastructure shall comply with the SKA1 RFI levels documentation.
Parent Comment General
Wallace Turner
10 July 2015
SDP comment
"any component of the observatory" is too broad,
SDP components could exceed the RFI threshold
levels significantly without affecting observations in
any way - either due to room shielding if on site
or due to physical location if offsite."any component of the observatory" is too
broad,
SDP components could exceed the RFI threshold
levels significantly without affecting observations in
any way - either due to room shielding if on site
or due to physical location if offsite.
Parent Comment General
Wallace Turner
10 July 2015
SDP FG
Need to investigate if the "SKA RFI/EMI
Threshold Levels[4]" are site specific. Since the
SDP facility will not be on site, this requirement may
not apply to SDP.
21/09/2015 7:42 am
Page
191 of 196
Parent Comment General
Wallace Turner
10 July 2015
CSP comment
The TBD value is the shielding to be provided by the infrastructure (Faraday
cage). As a practical value for the maximum allowable emission, the standard
emission norm for information technology equipment (EN55022) could be used.
Relates to req. 2466.
Parent Comment General
Wallace Turner
10 July 2015
CSP comment
Brent: As CSP electronics will be entirely contained in screened rooms, work
needs to be done to translate the L1 requirement to a requirement actually
imposed on electronics, and that they (individual LRUs) must be tested to and
meet in a standardized/controlled measurment setup (e.g. such as FCC or VDE
open-field 3 m test). A good starting point is FCC/VDE Class A radiated and
conducted emissions...then design the screened room, along with analysis, such
that RFI showing up at receptors are within prescribed limits.
Parent Comment General
Wallace Turner
10 July 2015
CSP comment
CSP will propose Level 2 requirements and work with INFRA.
Parent Comment General
Shandip Abeywickrema
31 August 2015
Note earlier comments on SKAO EMI/EMC standard, comments from INAU to be
provided on this document.
1.3.8.4
SKA1-FLD-1073 Access
1.3.8.4.1
SKA1-SYS_REQ- Site Access.
2374
Site Access. Roads and track-ways (including drainage) for the safe, secure and economic construction and operation of the SKA1 shall be provided.
1.3.8.4.2
SKA1-SYS_REQ- Air-strip.
2375
Air-strip. There shall be access to an air strip on site.
1.3.8.5
SKA1-FLD-1074 Water and Sanitation
1.3.8.5.1
SKA1-SYS_REQ- Construction.
2376
Construction. Potable and non-potable water shall be available at SKA1 construction camps including foundation concrete plants.
Parent Comment General
Shandip Abeywickrema
31 August 2015
Dish foundations not applicable to INAU.
1.3.8.5.2
SKA1-SYS_REQ- Steady state.
2377
21/09/2015 7:42 am
Page
192 of 196
Steady state. Sufficient water shall be continually available at SKA1 facilities in support of equipment cooling for each telescope.
1.3.8.5.3
SKA1-SYS_REQ- Standards and Regulations.
2378
Standards and Regulations. The delivery and disposal of water and all construction activity shall be compliant with local and national standards and regulations.
1.3.8.6
SKA1-FLD-1075 Buildings
1.3.8.6.1
SKA1-SYS_REQ- Central Processing Facility RFI shielding.
2382
Central Processing Facility RFI shielding. Each Central Processing Facility shall provide RFI shielding greater than that derived from zoning specifications given in
the SKA RFI levels documentation [4]
Parent Comment General
1.3.8.6.2
Shandip Abeywickrema
31 August 2015
Note earlier comments on SKAO EMI/EMC standard, comments from INAU to be
provided on this document. We request that the current CSIRO MRO site RFI
standards be used as the basis until agreement is reached on the SKA EMI/EMC
standard.
SKA1-SYS_REQ- Central Processing Facility RFI penetrations.
2383
Central Processing Facility RFI penetrations. The Central Processing Facility shall provide penetrations for signal and power cables entering the facility and also for
all other penetrations compliant with SKA-TEL-SKO-0000202-AG-RFI-ST-01-SKA EMI & EMC Standards and Procedures [4].
Parent Comment General
Shandip Abeywickrema
31 August 2015
1.3.8.7
SKA1-FLD-1079 Antenna earthing and bonding
1.3.8.7.1
SKA1-SYS_REQ- Antenna earthing.
2397
Note earlier comments on SKAO EMI/EMC standard, comments from INAU to be
provided on this document. We request that the current CSIRO MRO site RFI
standards be used as the basis until agreement is reached on the SKA EMI/EMC
standard.
Dish Antenna earthing. For lightning protection of each dish antenna the earthing system shall conform to the requirements of IEC 62305 and also to national
standards SANS 10142 and 10313. National standards shall take precedence.
Parent Comment General
Wallace Turner
10 July 2015
Parent Comment General
Wallace Turner
10 July 2015
21/09/2015 7:42 am
Rev6 comment Gie Han Tan
This requirement can likely be simplified by just referring to IEC 62305. SANS
standards seem to reference IEC 62305. Requirement should also apply to
SKA1_Low.
Rev6 comment Juande Santander-Vela
Is it clear that this requirement only pertains to the Dishes, and not to the LFAA
antennas?
Page
193 of 196
Parent Comment General
Wallace Turner
10 July 2015
Reply to Juande:
Action remove dish specific wording
Reply to Gie Han Tan
Agreed that the SANS standards do not need to be referenced
Action reduce requirement to reference IEC 62305 only
Parent Comment General
Shandip Abeywickrema
1.3.8.8
SKA1-FLD-1080 Telephone network
31 August 2015
No longer applicable to INAU.
1.3.8.8.1
SKA1-SYS_REQ- Telephone Network.
2398
Telephone Network. All populated facilities shall provide connectivity to the public telephone network.
1.3.9
SKA1-FLD-1083 External Interfaces
1.3.9.1
SKA1-FLD-1085 Power
1.3.9.1.1
SKA1-FLD-1087 Site steady state power budget Africa
1.3.9.1.1.1
SKA1-SYS_REQ- Site steady state power budget Africa.
2402
Site steady state power budget Africa. The total steady state power budget for the African site shall be within the limits specified in SKA Power Budget SKA-SEPOW-TN-001 [22].
1.3.9.1.2
SKA1-FLD-1089 Site steady state power budget Australia
21/09/2015 7:42 am
Page
194 of 196
1.3.9.1.2.1
SKA1-SYS_REQ- Site steady state power budget Australia.
2404
Site steady state power budget Australia. The total steady state power budget for the Australian site shall be within the limits specified in SKA Power Budget SKASE-POW-TN-001 [22].
1.3.9.2
SKA1-FLD-1395 Time Reference
1.3.9.2.1
SKA1-SYS_REQ- Time Reference
2769
Time Reference: SKA1 shall use a time reference derived from Global Positioning System (GPS).
Parent Comment General
Gottlieb van der Merwe
24 July 2015
What is the relationship between this time reference, the SKA1 timescale of
SKA1-SYS_REQ-2274 and the Central frequency reference of SKA1SYS_REQ-2275?
1.3.9.3
SKA1-FLD-1655 VLBI
1.3.9.3.1
SKA1-SYS_REQ- VLBI data sources
2838
VLBI data sources. The SKA1_Mid telescope shall be a data source for VLBI data acquisition system. The interface between the SAK1_Mid telescope and the
external VLBI data acquisition system shall be compliant with the ICD SKA-TEL-SKO-0000116
Parent Comment General
Wallace Turner
10 July 2015
Parent Comment General
Wallace Turner
10 July 2015
Rev6 comments Gie Han Tan
Instead of making reference to a SKA ICD suggest to refer to VLBI standards as
maintained by Haystack, see http://www.vlbi.org/index.html
Reply to Gie Han Tan
The reference indicated was investigated as part of the VLBI clarification ECP
and the review panel thought an ICD was necessary in the context of the SKA
No further action
1.3.9.3.2
SKA1-SYS_REQ- Provision of equipment for recording
2839
Provision of equipment for recording. Provision of equipment for recording or capturing VLBI data is outside the scope of SKA1
Parent Comment Question
Michael Rupen
1 September 2015 Is the difference in wording between this and the next requirement (2840)
significant? (outside the scope of SKA1 vs outside the scope of supply of the
SKA1 project). If not it would be nice to unify the two.
1.3.9.3.3
SKA1-SYS_REQ- VLBI equipment and eVLBI connectivity
2840
VLBI equipment and eVLBI connectivity. VLBI equipment and eVLBI connectivity beyond the interface boundary described in the ICD SKA-TEL-SKO-0000116 is
outside the scope of supply of the SKA1 project.
21/09/2015 7:42 am
Page
195 of 196
Parent Comment General
1.3.9.3.4
Michael Rupen
1 September 2015
See comment on 2839.
SKA1-SYS_REQ- Infrastructure for VLBI equipment:
2841
Infrastructure for VLBI equipment. The following infrastructure shall be provided to allow eventual outfitting of SKA1_Mid with VLBI equipment:
1.
2.
3.
4.
5.
Adequate access for the potential fitment of VLBI equipment
Equipment space
Power
Cooling
Cable trays
1.3.9.3.5
SKA1-SYS_REQ- Provision for VLBI terminal
2842
Provision for VLBI terminal. Provision for VLBI terminals or equivalent equipment shall be made in the Science Processing Centres for the associated telescopes.
1.3.9.3.6
SKA1-SYS_REQ- Compatibility with existing VLBI terminal
2843
Compatibility with existing VLBI terminal. SKA1 shall be able to output VLBI beam data with each individual stream limited to 512 MHz of signal bandwidth to
ensure compatibility with existing VLBI terminal capability
1.3.9.3.7
SKA1-SYS_REQ- VLBI Processing
2844
VLBI Processing. VLBI processing, with the exception of beam-forming and SKA1 imaging in support of VLBI. is outside the scope of the SKA1
1.3.9.3.8
SKA1-SYS_REQ- VLBI beam output data
2845
VLBI beam output data. SKA1 shall be able to produce VLBI beam output data with either dual or single polarization
1.3.9.3.9
SKA1-SYS_REQ- Word length of VLBI beam output data
2846
Word length of VLBI beam output data. SKA1 shall be able to output VLBI beam data with configurable word formats, the allowed values being 2, 4, 8, and 16-bit
integer.
Parent Comment General
Wallace Turner
10 July 2015
Rev6 comment GieHan Tan
Refer to VLBI standards as maintained by Haystack, see
http://www.vlbi.org/index.html
Parent Comment General
Wallace Turner
10 July 2015
Reply to Gie Han Tan
The reference indicated was investigated as part of the VLBI clarification ECP
and the review panel thought an ICD was necessary in the context of the SKA
No further action
21/09/2015 7:42 am
Page
196 of 196