REQUIREMENTS DOCUMENT FOR SKA SIGNAL PROCESSING

REQUIREMENTS DOCUMENT FOR SKA SIGNAL PROCESSING Document number... WP2 040.030.011 TD 001 Revision... 1 Author... W.Turner Date... 2011 03 30 Status... Approved for release Name Designation Affiliation Date Signature Additional Authors Submitted by: W. Turner Signal Processing Domain Specialist SPDO 2011 03 26 Approved by: T.Stevenson System Engineer SPDO 2011 03 29

DOCUMENT HISTORY Revision Date Of Issue Engineering Change Number Comments A First draft release for internal review B C D 30 th March 2011 Updated to reflect comments from T.Stevenson 1 30 th March 2011 First Issue DOCUMENT SOFTWARE Package Version Filename Wordprocessor MsWord Word 2007 07 WP2 040.030.000.SRS 001 1_SKASPReqSpec Block diagrams Other ORGANISATION DETAILS Name Physical/Postal Address SKA Program Development Office Jodrell Bank Centre for Astrophysics Alan Turing Building The University of Manchester Oxford Road Manchester, UK M13 9PL Fax. +44 (0)161 275 4049 Website www.skatelescope.org 2011 03 30 Page 2 of 96

TABLE OF CONTENTS 1 INTRODUCTION... 8 1.1 Purpose of the document... 8 2 REFERENCES... 9 3 REQUIREMENT STRUCTURE OVERVIEW... 10 3.1 Requirement ID... 11 3.2 Requirement Description... 11 3.3 Verification Method... 12 3.4 Priority... 12 3.5 Status... 13 3.6 Phase... 13 3.7 Originator... 13 3.8 Date... 13 3.9 Rationale and Assumptions... 13 4 SIGNAL PROCESSING REQUIREMENTS HIERACHY... 14 4.1 Definition Phase... 14 4.2 Signal Processing Element... 15 4.2.1 General Description... 15 4.2.2 External Interfaces... 16 4.2.2.1 Environment... 16 4.2.2.2 Simulator... 16 4.2.2.3 Receptors... 16 4.2.2.4 RFI Database... 16 4.2.2.5 VLBI... 16 4.2.2.6 Power... 17 4.2.2.7 Cooling... 17 4.2.2.8 External Transient Triggers... 17 4.2.2.9 Time Reference... 17 4.2.2.10 Science Computing... 17 4.2.2.11 Monitoring and Control... 17 5 SIGNAL PROCESSING ELEMENT REQUIREMENTS... 18 5.1.1 Pulsar Search... 18 5.1.2 Pulsar Timing... 19 5.1.3 Instantaneous Bandwidth... 20 5.1.4 Number, width and placement of station output bands... 22 2011 03 30 Page 3 of 96

5.1.5 Spectral Resolution... 22 5.1.6 Channelisation... 23 5.2 SKA 1 Sensitivity and Survey requirements... 25 5.2.1 Survey speed... 25 5.2.2 Survey On Sky time... 25 5.2.3 Deep Field Integration Time... 25 5.3 Baseline requirements... 25 5.4 Temporal characteristics... 26 5.4.1 Central Beamformer Main beam stability... 26 5.4.2 Spatial side lobe stability... 26 5.4.3 Beam switching agility... 26 5.4.4 Frequency switching agility... 27 5.5 Polarisation characteristics... 28 5.6 RFI avoidance... 29 5.7 Imaging characteristics... 30 5.7.1 Instantaneous field of view... 30 5.7.2 Pointing accuracy... 31 5.8 Monitoring and Control (M&C) Function... 31 5.8.1 Top level requirements... 31 5.8.2 Control requirements... 38 5.8.3 Monitoring requirements... 40 5.9 Data Acquisition Characteristics... 42 5.10 Observational Modes... 42 5.10.1 Top level modes... 42 6 OPERATIONAL REQUIREMENTS... 44 6.1 General... 44 6.2 Routine operations... 45 6.3 Start up and shutdown... 45 6.4 Failure management... 49 6.4.1 General... 49 6.4.2 Detection and reporting... 52 6.4.3 Diagnosis and recovery... 53 6.4.4 Lifetime... 56 6.5 Maintenance... 57 6.6 Disposal phase... 63 7 DESIGN CONSTRAINTS... 63 7.1 Environmental Requirements... 63 7.1.1 General... 63 7.1.2 Site and infrastructure requirements... 63 7.1.3 Contamination... 65 7.1.4 Radio Frequency Interference... 66 7.1.5 Electro Magnetic Compatibility... 66 7.1.6 Self generated RFI environment... 67 2011 03 30 Page 4 of 96

7.1.7 Lightning... 68 7.1.8 Grounding... 68 7.1.9 Corrosion... 69 7.1.10 Seismicity... 70 7.1.11 Other Aspects... 70 7.2 Engineering Design Constraints... 71 7.2.1 General... 71 7.2.2 Size and weight... 71 7.2.3 Materials and Processes... 72 7.2.4 Marking... 74 7.2.5 Power and other utilities... 77 7.3 Quality Factors Requirements... 77 7.3.1 General... 78 7.3.2 Workmanship... 78 7.3.3 System Safety... 80 7.3.4 Security... 81 7.3.5 Reliability... 81 7.3.6 Maintainability... 81 7.3.7 Flexibility and upgradability... 82 7.3.8 Accessibility and testability... 83 7.3.9 Transportability and storage... 83 7.3.10 Life... 85 8 INTERFACE REQUIREMENTS... 85 8.1 External Interfaces... 85 8.1.1 Power... 85 8.1.2 Cooling... 87 8.1.3 Time Reference... 88 8.1.4 Science and Computing... 89 8.1.5 Monitoring and Control... 90 8.1.6 Maintainer... 91 8.1.7 Engineer... 91 8.1.8 Environment... 91 8.1.9 Simulator... 91 8.1.10 Sparse AA... 92 8.1.11 Dish... 92 8.2 Internal Interfaces... 92 8.2.1 Power... 92 8.3 Synchronization... 93 9 SUPPORT REQUIREMENTS... 93 9.1 Maintenance... 93 9.2 Logistics... 93 10 EXTENSIBILITY REQUIREMENTS... 94 2011 03 30 Page 5 of 96

10.1 Extension interfaces... 94 10.2 Extension performance... 95 11 QUALITY ASSURANCE PROVISIONS... 95 11.1 System Qualification testing... 95 11.2 Test Methods... 96 LIST OF FIGURES Figure 1 Requirement Context... 10 Figure 2 Requirement Structure... 11 Figure 3 Requirements Hierarchy... 14 Figure 4 Signal Processing Context Diagram... 15 No table of figures entries found. LIST OF TABLES 2011 03 30 Page 6 of 96

LIST OF ABBREVIATIONS AA... Aperture Array Ant.... Antenna CoDR... Conceptual Design Review DRM... Design Reference Mission EoR... Epoch of Reionisation EX... Example FLOPS... Floating Point Operations per second FoV... Field of View LNA... Low Noise Amplifier Ny... Nyquist OH... Over Head OTPF... Observing Time Performance Factor Ov... Over sampling PAF... Phased Array Feed PrepSKA... Preparatory Phase for the SKA RFI... Radio Frequency Interference rms... root mean square SEFD...System Equivalent Flux Density SKA... Square Kilometre Array SKADS... SKA Design Studies SPDO... SKA Program Development Office SSFoM... Survey Speed Figure of Merit TBD... To be decided Wrt... with respect to 2011 03 30 Page 7 of 96

1 Introduction WP2 040.030.011 TD 001 The aim of this document is to present the requirement breakdown of the Signal Processing aspects of the SKA telescope for Phase 1 with extensibility to Phase 2 of the project. This is document is part of a series generated in support of the Signal Processing CoDR which includes the following: Signal Processing High Level Description Technology Roadmap Design Concept Descriptions Signal Processing Requirements Signal Processing Costs Signal Processing Risk Register Signal Processing Strategy to Proceed to the Next Phase Strategy to Proceed to the next phase Software Firmware Strategy The focus of this Requirements document is providing an initial step towards providing a complete set of traceable Element level requirements and their associated attributes. To achieve this, the initial System level requirements are flowed down and complemented with additional Signal Processing specific requirements. This document provides a strategy for the presentation of requirements and associated attributes that is intended to create unambiguous requirements with an expectation that the requirements will eventually be imported into a requirements management tool. Further work is required to refine the requirements and this will be the objective for the SRS review 1.1 Purpose of the document The purposes of this document are as follows: Provide a high level guiding statement as to the purpose of the SKA Signal Processing Identify the Stakeholders associated with the Signal Processing aspects of the SKA State the Mandated Constraints Identify naming conventions for the requirements Provide an overview of the requirement structure and life cycle. To present the Signal Processing Element and Subsystem requirements Identify attributes associated with requirements Provide a traceability matrix to identify the parent requirement within the system hierarchy 2011 03 30 Page 8 of 96

2 References [1] SKA Science Case [2] The Square Kilometre Array Design Reference Mission: SKA mid and SKA Lo v 0.4 [3] Science Operations Plan [4] System Interfaces [5] Environmental requirements (natural and induced) [6] SKA strategies and philosophies [7] Risk Register [8] Requirements Traceability [9] Logistic Engineering Management Plan (LEMP) [10] Risk Management Plan (RMP) [11] Document Handling Procedure [12] Project Dictionary [13] Strategy to proceed to the next phase [14] WP3 SKA array configuration report [15] WP3 SKA site RFI environment report [16] WP3 Troposphere measurement campaign report [17] SKA Science Technology Trade off Process (WP2 005.010.030 MP 004) [18] A. Faulkner, et al., Aperture Arrays for the SKA: the SKADS White Paper, January 2010. [19] E. de Lera Acedo et al., System Noise Analysis of an Ultra Wide Band Aperture Array: SKADS Memo T28. [20] SKA Monitoring and Control Strategy WP2 005.065.000 R 001 Issue Draft E [21] The Square Kilometre Array, Peter E. Dewdney, Peter J. Hall, Richard T. Schilizzi, and T. Joseph L. W. Lazio, Proceedings of the IEEE Vol. 97,No. 8, August 2009 [22] Thompson, A. R., Moran, J. M., and Swenson, G. W. Interferometry and Aperture Synthesis in Radio Astronomy (second edition), Wiley, 1986. [23] System Engineering Management Plan (SEMP) WP2 005.010.030 MP 001Reference 3 [24] SKA System Requirement Specification (SRS) [25] SKA IP Policy Document [26] International Technology Roadmap for Semiconductors (ITRS), available at www.itrs.net. 2011 03 30 Page 9 of 96

3 Requirement Structure Overview Stakeholder Plays a role in Is ownned by Priority Scenario Goal Has importance Occurs in satisfies Interface Connects to Measurement Verifies Requirement Is justified by Rationale Definition Defines a term in Has sub-type Function Quality Constraint Figure 1 Requirement Context Figure 1 provides a context of the requirements that is applicable within all layers of the system hierarchy. The interconnecting lines define the association between the blocks in the diagram. For example there are three sub types of requirement: Functional: A functional requirement is to define what is to be done Quality: A quality requirement is to change the way something is done. Quality requirements include: safety, security, reliability, performance, maintainability, and environment. Constraint: Constraints are restrictions or limitations on possible solutions. For the SKA the most Each of these requirements is to satisfy a goal owned by a particular stakeholder that plays a role in a role in a scenario of the system. Scenarios are associated with the modes and configurations of the system and define the dynamic behaviour. This document includes Use Cases to provide a path to discovering associated requirements. 2011 03 30 Page 10 of 96

bdd [block] system [Requirement definitions] «block» Requirement «block» Requirement ID «block» Verification Method «block» Status «block» Owner «block» Originator «block» Traceability Links «block» Requirement Description «block» Priority «block» Phase «block» Rationale «block» Date «block» User Type «block» Result Type «block» Object «block» Qualifier Figure 2 Requirement Structure As detailed in Figure 2 a requirement comprises of more information the just the requirement description. This information in effect forms attributes for the requirement. 3.1 Requirement ID The Requirement ID provides a unique identifier for each individual requirement. The Requirement ID takes the form: <string>_req_xxxx The sting provides a unique descriptor identifying the item within the systems hierarchy that the requirement set is applicable to xxxx is a four digit decimal number uniquely identifying the requirement within the requirement set. For example: SYS_REQ_0010 identifies the first requirement at the systems level. 3.2 Requirement Description The requirement description has to be clear, concise and verifiable: The requirement should be a single active sentence as short as possible. The requirement should focus on naming a single desired result Every requirement should be verifiable Requirements should avoid conjunctions such as: and, or, with and also as these tend to wrap multiple requirements into one which is not desirable. 2011 03 30 Page 11 of 96

Requirements should not specify the design envelope. The anatomy of the requirement should contain: User type: Result Type: Object: Qualifier: A noun identifying the beneficiary of the requirement A verb identifying the action of the requirement The object that the verb is applicable to Adverbal phrase identifying the desirable result of the action An example: The call centre operator shall be able to view details of the protected household within two seconds of issuing the query User type: Result Type: Object: Qualifier: The call centre operator shall be able to view details of the protected household within two seconds of issuing the query 3.3 Verification Method As stated in the requirement description, all requirements are to be verifiable. The method of verification is to be attached as an attribute to the requirement. The method of verification should be one of the following: Inspection Test Demonstration Analysis Simulation 3.4 Priority The priority of the requirement is to be attached as an attribute to the requirement. The priority should be identified by one of the following: Essential Useful Interesting 2011 03 30 Page 12 of 96

Luxury 3.5 Status Requirements are not static statements but have a life cycle. The status within the life cycle should be identified by one of the following: Reviewed Accepted Rejected To be modified 3.6 Phase Whether the requirement is applicable to Phase 1 or phase 2 of the SKA should be identified by an attribute associated with the requirement: Phase 1 Phase 2 3.7 Originator The originator of the requirement should be attached as an attribute. 3.8 Date The date that the requirement was created should be attached as an attribute. 3.9 Rationale and Assumptions Making assumptions explicit and connecting them to an argued rationale enables decisions to be revisited without starting all over again. An understanding of rationale enables accurate prioritisation and is an aid to preventing essential requirements from being deleted. 2011 03 30 Page 13 of 96

4 Signal Processing Requirements Hierachy WP2 040.030.011 TD 001 The requirements for signal processing form part of the overall system hierarchy as illustrated in Figure 3. SKA User User Requirement Feedback Program Engineering Installation & Validation Operations Support Telescope System System Requirement System Architectural Design Feedback Product Engineering Installation & Verification Integrated System Element Element Requirement Partition Element Architectural Design Feedback Product Engineering Installation & Verification Integrated Element Sub-system Sub-system Requirement Partition Sub-System Architectural Design Feedback Product Engineering Installation & Verification Integrated Sub-System Assembly Sub-Assembly Assembly Requirement Sub- Assembly Requirement Partition Partition Assembly Architectural Design Feedback Sub-Assy Architectural Design Product Engineering Product Engineering Installation & Verification Installation & Verification Integrated Assembly Integrated Sub- Assembly Component Component Specification Component Design Build & Test Components Part Part Specification Figure 3 Requirements Hierarchy Each level in the hierarchy has its own set of requirements which are derived from the next hierarchical level above. There is also a feedback path via the architectural design process to inform the requirements at the higher level whether there are any issues. The flow down and feedback is an on going process iterating towards a stable and eventually base lined requirement set. The initial requirements for the concept phase of Signal Processing element level is the scope of this document. It identifies the subset of concept phase system requirements that are applicable to signal processing and presents additional requirements where there are gaps. This process forms part of an iterative feedback path to the system level. CoDR in the definition phase where activities will refine these requirements so that they can be utilised by each of the Signal Processing Sub Systems 4.1 Definition Phase The aim of the definition phase is primarily to perform requirements analysis and validation to ensure that the complete set of requirements is understood and is present. Gaps will be identified 2011 03 30 Page 14 of 96

and actions to address these shortcomings will be initiated. The result of these activities will be captured in the relevant Requirement Specifications to be reviewed at the conclusion of this phase. Architectural design activities will also be initiated with the aim of producing a first draft design document at the end of the phase. Interfaces will be refined and finalised as far as possible (especially functional interfaces). This phase will be concluded by the (Sub) System Requirements Review (SRR). 4.2 Signal Processing Element 4.2.1 General Description bdd [package] Context [Signal processing context] Simulator 0..* Environment Engineer Maintainer Monitoring & Control Operator 0..* Receptors Digitised RF + RFI «System» Signal Processing Scientist Processed Data Science Computing RFI Database 0..* 1..* VLBI Power Cooling External Transient Triggers Time Reference Figure 4 Signal Processing Context Diagram The aim of Figure 4is to identify the complete set of external and user systems that interface to the Signal Processing domain. External systems are treated as black boxes and are represented by a 3 D box in the diagram. User systems provide a mechanism for user interaction and typically include keyboards displays etc. The User System is also presented as a 3 D box in the diagram but is in association with a stick man symbol representing the actor. The lines connecting blocks within the diagram represent associations between the blocks. Within the Figure 4 context, these associations are largely based on flows between the blocks. Flows are not limited to data exchange but can include physical entities such as fluids or electrical current. The flows don t have to be atomic: for example the receptors provide a flow of digitised RF data combined with RFI Data. 2011 03 30 Page 15 of 96

The multiplicity of an item is provided at the ends of the association lines. For example there are zero to any number of External Transient Triggers or Simulators and 1 to any number of Time References. Where a multiplicity isn t provided it is to be assumed to be unity. 4.2.2 External Interfaces 4.2.2.1 Environment Overall environmental conditions for the telescope including temperature, humidity, shock, vibration, particle and wildlife ingress. The strategy for this is addressed in the Environmental Requirements (Natural and Induced) document [5] The signal processing will be housed in a temperature and humidity controlled environments that are readily accessible to maintenance. 4.2.2.2 Simulator Is the simulator inside the Signal Processing boundary? 4.2.2.3 Receptors The RF signal is the wanted signal from the astronomical source being observed. The Design Reference Mission [2] defines the performance envelope for the telescope. RF Interference represents any external contaminating RF signal. This is site dependent and is detailed in WP3 SKA site RFI environment report [15]. 4.2.2.4 RFI Database The RFI data base will contain data on known RFI sources and detail their frequency and position characteristics as a function of time. Information from the data base is utilised by the Signal Processing to flag data streams that could potentially be contaminated with RFI. 4.2.2.5 VLBI The VLBI Data Interface Specification Release 1.0 ratified 26 th June 2009 specifies the standardized transport independent VLBI data interchange format that is suitable for all types of VLBI data transfer, including real time and near real time e VLBI well as disk file storage. http://www.vlbi.org/vsi/docs/vdif%20specification%20release%201.0%20ratified.pdf The complementary physical interface specification is currently being written. Although the VDIF specification makes no mention of data transport protocol, it has been developed with an awareness of expected methods of data transport, including network transport using various standard protocols, as well as physical or electronic transport of standard disk files. 2011 03 30 Page 16 of 96

4.2.2.6 Power External power to the system is dealt with in the Power section of the Strategies and Philosophies document [6]. 4.2.2.7 Cooling The strategy for dealing with cooling for the SKA telescope is detailed in the Cooling section of the Strategies and Philosophies document [6]. 4.2.2.8 External Transient Triggers The SKA telescope is to provide the facility for receiving external transient triggers. The interface is to utilise the SkyAlert service (http://www.skyalert.org/ ) (TBC) which collects and distributes astronomical events in near real time and distributes the resultant data in accordance to the provisional standard VOevent (http://www.ivoa.net/documents/rec/voe/voevent 20061101.html ). The transient events include supernovae, gamma ray bursts, micro lensing. 4.2.2.9 Time Reference It is anticipated that this will be satellite GPS and is detailed in the Timing and Synchronisation section of the SKA Strategies and Philosophies document [6]. 4.2.2.10 Science Computing An Interface Control Document is required to define the interface between Signal Processing and Science Computing. This will comprise of: Data Exchange Specification Physical Interface document 4.2.2.11 Monitoring and Control Monitoring includes output from the telescope to the operator. This will provide information on the health status and the configuration of the telescope and is detailed in the Monitoring and Control Strategies and Philosophies document [22]. External operator control of the telescope is detailed in the Science Operations Plan [3] and the Monitoring and Control Strategies and Philosophies document [22]. 2011 03 30 Page 17 of 96

5 Signal Processing Element Requirements 5.1.1 Pulsar Search SP_REQ_0010 The signal processing shall be capable of performing an all sky survey within two years. SYS_REQ_1420 Analysis SP_REQ_0020 The pulsar search shall have a time resolution of 50μs or less SYS_REQ_1620 Test SP_REQ_0030 Spectral Resolution The pulsar search shall have a frequency resolution of 20 khz SYS_REQ_TBD Test This is the reciprocal of the time resolution. Currently no parent requirement SP_REQ_0040 The pulsar search shall be capable of compensating for time delays due to the intergalactic medium for dispersion measures up to 2400 cm 3 pc TBC SYS_REQ_1620 SYS_REQ_TBD Test Derived from 3 GHz, instantaneous bandwidth and time resolution. SP_REQ_0050 The pulsar search shall be capable of detecting ms pulsars to an equivalent luminosity of 0.1 mjy kpc 2 at 1.4 GHz TBC SYS_REQ_TBD Test The luminosity for this requirement is taken from the DRM. However the frequency at which it is applicable is assumed to be 1.4 GHz. 2011 03 30 Page 18 of 96

SP_REQ_0060 The pulsar search shall be capable of detecting binary pulsar with linear acceleration range of +/ 100 ms 2 TBC SYS_REQ_TBD Test Non parent requirement SP_REQ_0070 The pulsar search processing chain shall have a signal to noise better than TBD db SYS_REQ_TBD Analysis No parent requirement 5.1.2 Pulsar Timing SP_REQ_0080 The signal processing for pulsar timing shall have a time resolution of 100ns or less SYS_REQ_1620 Test SYS_REQ_1620 should specify 100ns not 100μs SP_REQ_0090 The pulsar timing processing chain shall have a signal to noise better than TBD db SYS_REQ_TBD Analysis SP_REQ_0100 The pulsar timing processing chain shall be capable of switching the observation frequency in less than 10 minutes SYS_REQ_1670 Test No parent requirement 2011 03 30 Page 19 of 96

SP_REQ_0110 Pulsar pulse arrival times shall be measured to an absolute time accurate to TBD SYS_REQ_TBD Test No parent requirement SP_REQ_0120 Signal processing shall have the capability of storing pulsar pulse profile templates SYS_REQ_TBD Test No parent requirement SP_REQ_0130 The signal processing shall provide the capability of timing TBD pulsars simultaneously in real time SYS_REQ_TBD Test No parent requirement 5.1.3 Instantaneous Bandwidth SP_REQ_0140 Signal Processing shall be capable of real time correlation processing for an instantaneous bandwidth, of 500 MHz for the range 70 MHz 600 MHz (TBV) SYS_REQ_1120 Test 2011 03 30 Page 20 of 96

SP_REQ_0150 Signal Processing shall be capable of real time Non Imaging processing for an instantaneous bandwidth, of 500 MHz for the range 70 MHz 600 MHz (TBV) SYS_REQ_1120 Test SP_REQ_0160 SP shall be capable of real time correlation processing for an instantaneous bandwidth, of 1 GHz for the range 600 MHz 3 1 GHz (TBV) SYS_REQ_1120 Test SP_REQ_0170 Signal Processing shall be capable of real time Non Imaging processing for an instantaneous bandwidth, of 1 GHz for the range 600 MHz 3 GHz (TBV) SYS_REQ_1120 Test SP_REQ_0180 The signal processing shall be capable of correlation processing for an instantaneous band anywhere within the operating frequency band. SYS_REQ_1130 Test SP_REQ_0190 Band selection resolution. The resolution with which the 500 MHz and 1 GHz bands can be selected shall be TBD or less. SYS_REQ_1140 Test 1 Note that the Phase 1 System requirements specify 10 GHz which is incorrect 2011 03 30 Page 21 of 96

5.1.4 Number, width and placement of station output bands SP_REQ_0200 Sub band bandwidth. The bandwidth after station level beamforming shall be less than TBD Hz. SYS_REQ_1160 Test The sub band bandwidth has differing requirements for imaging and non imaging processing. Nonimaging sub band width shouldn t be finer than the reciprocal of the required time resolution. SP_REQ_0210 DSP signal processing capacity. The digital processing capacity shall be sufficient to process all sub bands for all beams and polarizations. SYS_REQ_1170 Test However, the number of sub bands needs to be determined by the requirements of the processing. Consequently, this is a circular requirement? SP_REQ_0220 Beam sub band and channel phase relations. The phase relations between the sub bands and channels within a beam shall be known to such a precision that wider bands and corresponding time series can be reconstructed from sub bands and/or channels. SYS_REQ_1180 Test 5.1.5 2 Spectral Resolution SP_REQ_0230 Spectral resolution. SKA1 shall offer a spectral resolution in each polarization for image processing of < 200 Hz in the band 70 to 240 MHz SYS_REQ_1210 Test 2 The daughter requirements in this section have been specifically identified against imaging or nonimaging frequency resolution rather than the general case identified in the parent 2011 03 30 Page 22 of 96

SP_REQ_0240 Spectral resolution. SKA1 shall offer a spectral resolution in each polarization for image processing of < 10kHz in the band 400MHz to 3 GHz SYS_REQ_1210 Test This requirement follows directly from the radial resolution science imaging requirement. For reference, assuming the concordance cosmology, at these redshifts, the co moving length is given by 1.7 Mpc (ν/100 khz). Therefore, to match the angular resolution a frequency resolution of about 100 khz is required. SP_REQ_0250 Sub band and channel phase relations. The signal processing performed on each sub band shall leave the relative phases of subbands and spectral channels intact or predictable. SYS_REQ_1220 Test 5.1.6 3 Channelisation SP_REQ_0260 Stop band ripple. Channelisation shall have stop band ripple < 61 db in the band 70MHz to 240 MHz TBC SYS_REQ_1230 Test SP_REQ_0270 Stop band ripple. Channelisation shall have stop band ripple < 61 db in the band 200 MHz to 1.4 GHz SYS_REQ_1230 Test 3 This has assumed that the ripple introduced by multiband filtering is below the dynamic range of the whole system. In reality, the requirement will not be this severe 2011 03 30 Page 23 of 96

SP_REQ_0280 Stop band ripple. Channelisation shall have stop band ripple < TBD db in the band 1.4 GHz to 3GHz SYS_REQ_1230 Test SP_REQ_0290 Pass band ripple. Channelisation shall have pass band ripple < TBD db in the band 70MHz to 240 MHz SYS_REQ_1230 Test SP_REQ_0300 Pass band ripple. Channelisation shall have pass band ripple < TBD db in the band 200 MHz to 1.4 GHz SYS_REQ_1230 Test SP_REQ_0310 Pass band ripple. Channelisation shall have pass band ripple < TBD db in the band 1.4 GHz to 3 GHz SYS_REQ_1230 Test SP_REQ_0320 Channel overlap. Individual channels generated by channelization shall not have components of > TBD db in adjacent frequency channels SYS_REQ_1230 Test 2011 03 30 Page 24 of 96

5.2 SKA 1 Sensitivity and Survey requirements 5.2.1 Survey speed Ident Requirement Applicability Parent Verification Survey speed. The SKA 1 survey speed requirement is: SYS_REQ_14 10 ~10 7 m 4 K 2 deg 2 for the frequency range 200MHz to 1.4 GHz Mandatory >10 7 m 4 K 2 deg 2 Mandatory 5.2.2 Survey On Sky time Ident Requirement Applicability Parent Verification The SKA Phase 1 shall be designed so that a major survey can be completed in 2 years of on sky observation time. SYS_REQ_14 20 Analysis 5.2.3 Deep Field Integration Time Ident Requirement Applicability Parent Verification The SKA Phase 1 shall be designed so that a deep field can be completed in 1000 hr of integration time. Mandatory SYS_REQ_14 30 Analysis 5.3 Baseline requirements SP_REQ_0360 Delay compensation The signal processing shall compensate for signal transmission delays from receptors to signal processing facility with a resolution of one time sample SYS_REQ_1510 Test 2011 03 30 Page 25 of 96

SP_REQ_0370 Baseline. The signal processing shall provide correlation for baselines up to and including 200 km SYS_REQ_1510 Test 5.4 Temporal characteristics 5.4.1 Central Beamformer Main beam stability SP_REQ_0380 Main beam stability. The magnitude and phase variations of any SKA 1 compound beam over a 12 hours period at any point of its half power contour shall be less than 1% (TBC) relative to the beam peak. SYS_REQ_1610 Test 5.4.2 Spatial side lobe stability SP_REQ_0390 Spatial side lobe stability. Spatial side lobes should be stable to within TBD. TBD Test 5.4.3 Beam switching agility SP_REQ_0400 Beam former weight update rate. Changing the beam pointing shall be possible every 60 seconds (TBC) in the case of scheduled switching sequences. SYS_REQ_1640 Test 2011 03 30 Page 26 of 96

SP_REQ_0410 Beam former weight ad hoc update response time. Changing the beam former weights shall be possible within 60 seconds in case of changes due to manual interaction or changes in schedule. SYS_REQ_1650 Test SP_REQ_0420 Beam switching downtime flagging. Observation data (specify: both uv(w) data and tied array beams) acquired during a change of beam direction shall be flagged. SYS_REQ_1660 Test 5.4.4 Frequency switching agility SP_REQ_0440 Switching between observation frequencies. The signal processing shall be able to switch between observing frequencies within 10 minutes or less SYS_REQ_1670 Test SP_REQ_0450 Integration buffers. All associated signal processing data buffers shall be reset to default values for changes in observation frequency SYS_REQ_1670 Test 2011 03 30 Page 27 of 96

SP_REQ_0460 Observation frequency meta data. The signal processing shall provide meta data in association with data products including observation frequency. SYS_REQ_1670 Test 5.5 Polarisation characteristics SP_REQ_0470 Beam polarisation stability. The polarization properties of the beams shall be stable enough to allow their calibration to better than 0.5% (TBC) SYS_REQ_1710 Test It is envisioned that most of the factors affecting the polarisation stability are in the analogue and digitisation domains. However signal processing needs to ensure polarisation channel pairs are tightly coupled with respect to delay compensation, beamformer coefficients, data truncation etc. to ensure that no systematic errors are introduced SP_REQ_0480 Beam polarisation stability. External calibration measurements shall be necessary at a rate of no more than once per hour (TBC). SYS_REQ_1710 Test SP_REQ_0490 Stokes parameters. SKA1 shall provide visibility data in all four Stokes parameters. SYS_REQ_1730 Test 2011 03 30 Page 28 of 96

SP_REQ_0500 Instrumental polarisation The polarisation introduced by the instrument, after calibration, shall be less than 0.5% of the total intensity. (TBC) SYS_REQ_1740 Test 5.6 RFI avoidance SP_REQ_0510 The signal processing shall utilise information from an RFI data base to flag potentially contaminated frequency channels SYS_REQ_1810 SP_REQ_0520 Integrated auto correlation products shall be generated on all channelized data streams SYS_REQ_1810 SP_REQ_0530 The signal processing shall provide RFI threshold detection on integrated auto correlation products for all channelized data SYS_REQ_1810 SP_REQ_0540 The signal processing shall provide RFI threshold detection on integrated auto correlation products SYS_REQ_1810 2011 03 30 Page 29 of 96

SP_REQ_0550 It shall be possible to set the RFI detection threshold on all channelized data channels SYS_REQ_1810 SP_REQ_0560 Off stream processing for the calculation of RFI detection thresholds shall be provided by the signal processing SYS_REQ_1810 SP_REQ_0570 The SKA1 shall have limited (TBD) susceptibility to bursty/spiky RFI (for pulsars, transients) SYS_REQ_1810 SP_REQ_0580 Historic, time stamped threshold detections shall be made available for potential inclusion in the RFI database SYS_REQ_1810 To be expanded 5.7 Imaging characteristics 5.7.1 Instantaneous field of view SP_REQ_0600 The Sparse AA correlator shall be capable of simultaneously processing signals in real time for a field of view greater than 5 degrees. SYS_REQ_1910 2011 03 30 Page 30 of 96

SP_REQ_0610 The signal processing shall make all cross correlation products available to the Science computing SYS_REQ_1920 5.7.2 Pointing accuracy The mechanical and electronic pointing accuracy requirements of the dishes and the AAs are listed below. SP_REQ_0620 Beam forming coefficient. The coefficients used for the generation of beams in the central beamformer shall have a data width of TBD bits SYS_REQ_1950 SYS_REQ_1960 SYS_REQ_1970 SYS_REQ_1980 SP_REQ_0630 Beam forming coefficient. The coefficients used for the generation of Dish beams in the central beamformer shall be updated every TBD minutes SYS_REQ_1950 SYS_REQ_1960 SYS_REQ_1970 SYS_REQ_1980 5.8 Monitoring and Control (M&C) Function Monitoring and Control is a central system responsible for acquiring monitoring data and for control of the SKA1 systems. It has a level of autonomy and its sub systems are distributed to local areas. 5.8.1 Top level requirements SP_REQ_0640 M&C. Signal Processing shall provide monitoring and control functionality SYS_REQ_2110 2011 03 30 Page 31 of 96

SP_REQ_0650 M&C. It shall be possible to electronically read each signal processing Line Replaceable Unit s, serial number through the SKA1 M&C system WP2 040.030.011 TD 001 SYS_REQ_2110 SP_REQ_0660 M&C. It shall be possible to electronically read each signal processing Line Replaceable Unit s location through the SKA1 M&C system SYS_REQ_2110 SP_REQ_0670 M&C. Where applicable, it shall be possible to electronically read each signal processing Line Replaceable Unit s firmware version through the SKA1 M&C system SYS_REQ_2110 SP_REQ_0680 M&C. Where applicable, it shall be possible to electronically read each signal processing Line Replaceable Unit s Operation System type through the SKA1 M&C system SYS_REQ_2110 SP_REQ_0690 M&C. Where applicable, it shall be possible to electronically read each signal processing Line Replaceable Unit s Operation System version through the SKA1 M&C system SYS_REQ_2110 2011 03 30 Page 32 of 96

SP_REQ_0700 M&C. Where applicable, it shall be possible to electronically read each signal processing Line Replaceable Unit s Memory Usage through the SKA1 M&C system SYS_REQ_2110 SP_REQ_0710 M&C. Where applicable, it shall be possible to electronically read each signal processing Line Replaceable Unit s percentage processing usage through the SKA1 M&C system SYS_REQ_2110 SP_REQ_0720 M&C. Where applicable, it shall be possible to electronically read each signal processing Line Replaceable Unit s operating voltages through the SKA1 M&C system SYS_REQ_2110 SP_REQ_0730 M&C. Where applicable, it shall be possible to electronically read each signal processing Line Replaceable Unit s thermal dissipation through the SKA1 M&C system SYS_REQ_2110 SP_REQ_0740 M&C. Where applicable, it shall be possible to electronically read each signal processing Line Replaceable Unit s temperature through the SKA1 M&C system SYS_REQ_2110 2011 03 30 Page 33 of 96

SP_REQ_0750 M&C. Historic signal processing M&C system data shall be stored local to the signal processing SYS_REQ_2110 SP_REQ_0760 M&C. Historic signal processing data shall be made available to the main M&C on request SYS_REQ_2110 SP_REQ_0770 M&C. It shall be possible to set thresholds on monitored parameters SYS_REQ_2110 SP_REQ_0780 M&C. If monitored parameter thresholds are traversed in either direction the signal processing system shall inform the SKA1 M&C system. SYS_REQ_2110 SP_REQ_0790 M&C. Signal Processing Monitor and control computer nodes shall utilise DHCP to obtain their address SYS_REQ_2110 SP_REQ_0800 M&C. Signal Processing Monitor and control computer nodes shall utilise DNS to obtain their name SYS_REQ_2110 2011 03 30 Page 34 of 96

SP_REQ_0810 M&C. Signal Processing Monitor and control computer nodes shall time stamp all M&C messages SYS_REQ_2110 SP_REQ_0820 M&C. Time stamps for Signal Processing Monitor and Control messages shall be accurate to TBD ms SYS_REQ_2110 SP_REQ_0830 M&C. All monitor and control computer nodes shall be password protected SYS_REQ_2110 SP_REQ_0840 M&C. All passwords on monitor and control computer nodes shall be encrypted SYS_REQ_2110 SP_REQ_0850 M&C purpose. The monitoring and control function shall ensure that all parts of the system work together coherently. All control functions, except certain local maintenance functions, are part of the M&C system. SYS_REQ_2120 SP_REQ_0860 M&C. All signal processing equipment shall implement Power on Self Test, POST SYS_REQ_2130 2011 03 30 Page 35 of 96

SP_REQ_0870 M&C. All signal processing equipment shall implement Built in Self Test, BIT SYS_REQ_2130 SP_REQ_0880 M&C. POST results from individual LRUs shall be made available to the SKA1 M&C on request SYS_REQ_2130 This is not always the case for COTs computing nodes that often provide POST indications through LED flash sequences or audible beeps. SP_REQ_0890 M&C. BIT results from individual LRUs shall be made available to the SKA1 M&C on request SYS_REQ_2130 SP_REQ_0900 M&C autonomy. The monitoring and control function shall take autonomous action to ameliorate failures where possible and support a fail safe philosophy. SYS_REQ_2140 SP_REQ_0910 M&C transparency The M&C shall provide a hierarchical and redundant syslog SYS_REQ_2160 2011 03 30 Page 36 of 96

SP_REQ_0920 M&C remote operation. The monitoring and control function shall be designed to operate the instrument fully remotely. SYS_REQ_2190 SP_REQ_0930 M&C communication nodes. The signal processing monitoring and control shall use a separate physical interface from the main application communication. SYS_REQ_2190 SP_REQ_0940 M&C performance monitoring. The monitoring and control function shall provide TBD performance monitoring data to users. SYS_REQ_2210 SP_REQ_0950 M&C monitoring data. All SKA1 subsystems shall provide monitoring data to the monitoring and control function (for performance monitoring and closed loop control functions) SYS_REQ_2220 SP_REQ_0960 M&C logging. The monitoring and control function shall provide for a long term logging sub function with workflow support for the Operational Team and with sufficient information to relate system events to artefacts in the data. SYS_REQ_2230 2011 03 30 Page 37 of 96

SP_REQ_0970 M&C observation interrupts. It shall be possible to abort an observation if monitor parameters exceed user specified limits (including RFI mitigation performance indication parameters). SYS_REQ_2240 SP_REQ_0980 M&C calibration information. Individual element calibration information shall be available to the measurement function. SYS_REQ_2250 The requirements on the M&C function related to Health and Safety still needs to be analysed, verified and added. 5.8.2 Control requirements Requirements regarding control of the instrument (configuration of beam forming, correlation etc) SP_REQ_0990 Control system. Control information for the signal processing shall be received over the SKA1 M&C network SYS_REQ_2310 SP_REQ_1000 Control synchronisation. Control changes received by the Signal processing shall take in account latencies due to processing and communication pipelines before being applied SYS_REQ_2310 2011 03 30 Page 38 of 96

SP_REQ_1010 Control handshake. The signal processing shall provide acknowledgement to received control messages SYS_REQ_2310 SP_REQ_1020 Control handshake. The signal processing shall provide acknowledgement that control updates have been successfully acted on SYS_REQ_2310 SP_REQ_1030 Control system autonomy. The control system shall be capable of autonomously calculating system settings in response to changes in instrument status, environment or measurement results. SYS_REQ_2320 SP_REQ_1040 System settings activation. It shall be possible to activate the calculated system settings automatically SYS_REQ_2330 SP_REQ_1050 System settings activation. It shall be possible to activate the calculated system settings after explicit confirmation by the operator (manual control). SYS_REQ_2330 2011 03 30 Page 39 of 96

SP_REQ_1060 System setting activation autonomy. It shall be possible to specify when settings should be activated automatically and when they need to be confirmed by the operator. SYS_REQ_2340 SP_REQ_1070 Schedule update. It shall be possible to receive and accept updated schedules before the end time of the currently active schedule has expired. SYS_REQ_2350 5.8.3 Monitoring requirements Requirements regarding monitoring the status of the instrument (configuration and health) SP_REQ_1080 Monitoring data consolidation. Signal processing shall hierarchically consolidate monitoring information to produce high level monitoring information from low level monitoring information. SYS_REQ_2410 SP_REQ_1090 Monitoring data consolidation. It shall be possible for the SKA1 M&C to access individual layers within the consolidated monitoring hierarchy SYS_REQ_2410 2011 03 30 Page 40 of 96

SP_REQ_1100 Subsystem M&C action reports. Subsystems shall report completion of actions to M&C SYS_REQ_2420 SP_REQ_1110 M&C summary reports. It shall be possible for all user roles (specification of these roles TBD) to produce summarized historical monitoring information. SYS_REQ_2430 SP_REQ_1120 Control data augmentation. The results of control actions shall be verified with measurements made expressly for the purpose. SYS_REQ_2440 SP_REQ_1130 If the normal measurement sequence does not provide for control verification in a timely fashion, such measurements shall be made out of sequence. SYS_REQ_2440 SP_REQ_1140 Monitoring information consolidation. It shall be possible to consolidate monitoring information both on the physical instrument status and on designated logical concepts like observation, correlator. SYS_REQ_2450 2011 03 30 Page 41 of 96

SP_REQ_1150 Monitoring information consolidation. The signal processing shall have procedures to ensure log files do not fill disk partitions. SYS_REQ_2450 5.9 Data Acquisition Characteristics This section describes the functions in the acquisition and initial processing path. This includes the definition of observation modes (synthesis imaging, tied array, fly s eye, pulsar detection) and of intermediate and final data products. Also the functional and performance requirements for RFI mitigation, the data transport network and some derived performance parameters for data handling are listed here. To be expanded. 5.10 Observational Modes This section identifies the top level observational modes. 5.10.1 Top level modes SP_REQ_1160 Synthesis imaging mode. SKA1 shall provide a synthesis imaging mode where compound beams are correlated to form visibilities SYS_REQ_2710 SP_REQ_1170 Visibilities. The signal processing shall be able to handle the full data stream from the dishes in synthesis imaging mode. SYS_REQ_2720 2011 03 30 Page 42 of 96

SP_REQ_1171 Visibilities. The signal processing shall be able to handle the full data stream from the Sparse AAs in synthesis imaging mode. SYS_REQ_2720 SP_REQ_1180 Tied array mode. The signal processing shall provide a tied array mode where the signals from all receptors are transformed back into time series for pulsar processing. SYS_REQ_2730 SP_REQ_1190 Fly s eye mode. The signal processing shall provide a fly s eye mode (TBC). SYS_REQ_2740 SP_REQ_1191 Fly s eye mode. In fly s eye mode Autocorrelations of all single dishes are recorded. SYS_REQ_2740 Each dish is tracking a different position on the sky. This doesn t appear to be a phase 1 requirement. SP_REQ_1192 Fly s eye mode. In fly s eye mode Autocorrelations of all aperture (sub)arrays are recorded. SYS_REQ_2740 Each sub array is tracking a different position on the sky. This doesn t appear to be a phase 1 requirement. 2011 03 30 Page 43 of 96

SP_REQ_1200 Aggregate mode. SKA1 shall provide an aggregate mode in which bandwidth is exchanged for spatial coverage in the correlator. SYS_REQ_2750 Is this a phase 1 requirement? SP_REQ_1210 Real time calibration. SKA1 shall provide instrumental real time calibration functions in all observational modes. SYS_REQ_2760 6 Operational Requirements 6.1 General This section states general operational requirements. SP_REQ_1220 Up time. The signal shall have an availability of TBD. SYS_REQ_3110 SP_REQ_1230 Remote M&C from sites. It shall be possible for the operator to control and monitor the SKA1 instrument from the SKA station sites and core site. SYS_REQ_3130 2011 03 30 Page 44 of 96

SP_REQ_1240 Physical access security. The system shall provide security to prevent unauthorized physical access to facilities and resources. SYS_REQ_3140 To be added: security measures for other aspects such as network access, server access, encryption of M&C messages. 6.2 Routine operations This section gives system level requirements for the routine operations of SKA 1. SP_REQ_1250 Reconfiguration time. Under normal operation, econfiguration of SKA1 from one observational mode to another shall not take longer than 5 minutes (TBC) SYS_REQ_3150 6.3 Start up and shutdown This section gives system level requirements for SKA 1 start up and shutdown, including check out at initialization. SP_REQ_1260 Full remote control. It shall be possible to control all SKA1 functions from the operational centre, without requiring physical access to the instrument, including start up and shut down. SYS_REQ_3160 2011 03 30 Page 45 of 96

SP_REQ_1270 Full remote control. It shall be possible to control signal processing functions from the operational centre. SYS_REQ_3160 SP_REQ_1280 Full remote control. It shall be possible to control signal processing start up from the operational centre. SYS_REQ_3160 SP_REQ_1290 Full remote control. It shall be possible to control signal processing shut down from the operational centre. SYS_REQ_3160 SP_REQ_1300 Full remote control. It shall be possible to power cycle individual signal processing equipment from the operational centre. SYS_REQ_3160 SP_REQ_1310 Start up sequence. The start up of Signal Processing functions shall follow a pre defined sequence SYS_REQ_3170 2011 03 30 Page 46 of 96

SP_REQ_1320 Start up sequence. The hot start (restart) of Signal Processing functions shall be less than 10 minutes SYS_REQ_3170 SP_REQ_1330 Start up sequence. The cold start of Signal Processing functions shall be less than 24 hours SYS_REQ_3170 To be added: definition of hot and cold start. SP_REQ_1340 Shut down sequence. The shutdown of SKA1 shall follow a pre defined sequence SYS_REQ_3190 SP_REQ_1350 Shut down sequence. The shutdown of SKA1 shall be less than TBD minutes. SKA1 shall also have an emergency shut down for wind (stowing dishes), lightning, and electric power anomalies. SYS_REQ_3190 SP_REQ_1360 Shut down sequence. The signal processing shall also have a procedure for emergency shut down. SYS_REQ_3190 2011 03 30 Page 47 of 96

SP_REQ_1370 Shut down sequence. The signal processing shall provide battery backup to allow sufficient time for orderly shutdown of operating systems. SYS_REQ_3190 SP_REQ_1380 Shut down sequence. The signal processing shall have a procedure for rebuilding disks due to uncontrolled shutdown SYS_REQ_3190 SP_REQ_1390 Start up and shut down dependencies. Any dependencies in the start up and shutdown sequences shall be automatically verified (so they do not depend on operator intervention). SYS_REQ_3220 SP_REQ_1400 Subsystem shut down. The shutdown of pre defined parts of the SKA1 system shall have no (TBC) impact on SKA1 operations after appropriate recalibration performed automatically. SYS_REQ_3230 SP_REQ_1410 The signal processing M&C system shall report subsystem health status SYS_REQ_3240 2011 03 30 Page 48 of 96

SP_REQ_1420 The signal processing LRUs shall provide LED health status indicators SYS_REQ_3240 SP_REQ_1430 Power on Self Test shall not take longer to complete than 5 minutes SYS_REQ_3250 SP_REQ_1440 The signal processing shall recover from a hot swap within TBD minutes. SYS_REQ_TBD SP_REQ_1450 Hot swap of a LRUs shall not disrupt the signal processing beyond the unit and its immediate neighbours SYS_REQ_TBD 6.4 Failure management 4 6.4.1 General General requirements regarding failure management SP_REQ_1460 Personnel safety. As far as possible, no single failure in the SKA1 shall lead to personnel safety hazards. SYS_REQ_3310 4 Section still to be aligned with Logistic Engineering Management Plan. 2011 03 30 Page 49 of 96