Embed Size (px)
Citation preview
Name Designation Affiliation Date Signature
Submitted by:
K. Cloete System Engineer SPDO 2010-02-11
Co Authors and contributors: N. Roddis, D. Hall, B. Adams, G. Hovey, D. Liebenberg, J. Jonas
Approved for release as part of SKA System CoDR documents:
P. Dewdney Project Engineer SPDO 2010-02-11
STRATEGIES AND PHILOSOPHIES
Document number .................................................................. WP2-005.010.030-TR-001
Revision ........................................................................................................................... E
Author ......................................................................................................... K. Cloete et al
Date ................................................................................................................. 2010-02-11
Status ............................................................................................... Approved for release
WP2-005.010.030-TR-001 Revision : E
2010-02-11 Page 2 of 48
DOCUMENT HISTORY
Revision Date Of Issue Engineering Change
Number
Comments
A 2010-01-29 - First draft release for internal review
B 2010-02-05 - Updated and sections added
C 2010-02-08 - Updated with comments received on Rev B, sections added.
D 2010-02-10 - Added sections on Interface Management, Standardisation,
Health and Safety, Software Engineering. Incorporated RMc
comments on Rev C.
E 2010-02-11 - Incorporated DH and DL comments. Approved for release
for system CoDR.
DOCUMENT SOFTWARE
Package Version Filename
Wordprocessor MsWord Word 2007 WP2-005.010.030-TR-001-E_Strategies
ORGANISATION DETAILS
Name SKA Program Development Office
Physical/Postal
Address
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
WP2-005.010.030-TR-001 Revision : E
2010-02-11 Page 3 of 48
TABLE OF CONTENTS
1 INTRODUCTION ............................................................................................. 8
2 REFERENCES ................................................................................................ 9
3 COST ....................................................................................................... 11
3.1 Introduction .......................................................................................................................... 11
3.2 Current Situation ................................................................................................................... 11
3.3 Characteristics of a Credible Cost Estimate .......................................................................... 11
3.4 Basis of Estimate ................................................................................................................... 12
3.5 Way Forward ......................................................................................................................... 14
4 POWER .................................................................................................... 15
4.1 Introduction .......................................................................................................................... 15
4.2 Current Situation ................................................................................................................... 15
4.3 The Challenge ........................................................................................................................ 16
4.4 Way Forward ......................................................................................................................... 17
5 ELECTROMAGNETIC COMPATIBILITY (EMC) ....................................................... 18
5.1 Introduction .......................................................................................................................... 18
5.2 Terminology .......................................................................................................................... 18
5.3 Standards and specifications ................................................................................................ 18
5.4 EMC zones and SKA array configuration ............................................................................... 19
5.5 Design of SKA hardware ........................................................................................................ 20
5.6 Commercial off the shelf (COTS) hardware .......................................................................... 20
5.7 Support equipment and services .......................................................................................... 20
5.8 Measurement ........................................................................................................................ 20
5.8.1 Approvals testing .......................................................................................................... 21
5.8.2 Conducted emissions .................................................................................................... 21
5.8.3 Radiated emissions ....................................................................................................... 21
5.8.4 Site RFI measurement ................................................................................................... 21
5.8.4.1 2005 Campaign ......................................................................................................... 21
5.8.4.2 Preparatory phase ..................................................................................................... 21
5.8.4.3 SKA construction phase ............................................................................................ 21
5.8.4.4 Long term operation ................................................................................................. 22
5.9 RFI Mitigation ........................................................................................................................ 22
5.10 EMC Costing .......................................................................................................................... 22
5.11 Way forward ......................................................................................................................... 22
6 SOFTWARE ENGINEERING .............................................................................. 23
6.1 Introduction .......................................................................................................................... 23
6.2 Current Situation ................................................................................................................... 24
6.3 Way Forward ......................................................................................................................... 24
WP2-005.010.030-TR-001 Revision : E
2010-02-11 Page 4 of 48
7 COOLING AND TEMPERATURE STABILISATION ..................................................... 24
7.1 Introduction .......................................................................................................................... 24
7.2 Why is it Important ............................................................................................................... 25
7.3 Way Forward ......................................................................................................................... 25
8 RELIABILITY, AVAILABILITY, MAINTAINABILITY (RAM) ......................................... 27
8.1 Introduction .......................................................................................................................... 27
8.2 Way Forward ......................................................................................................................... 27
9 STANDARDS AND STANDARDISATION ............................................................... 28
9.1 What is Standardisation ........................................................................................................ 28
9.2 Why is it Important ............................................................................................................... 28
9.3 Way Forward ......................................................................................................................... 29
10 UNITS OF MEASURE .................................................................................. 29
11 QUALITY ................................................................................................ 31
11.1 Introduction .......................................................................................................................... 31
11.2 Current Situation ................................................................................................................... 31
11.3 Way Forward ......................................................................................................................... 32
12 HEALTH AND SAFETY ................................................................................. 33
13 OBSOLESCENCE ........................................................................................ 34
13.1 Obsolescence definition ........................................................................................................ 34
13.2 Why is it Important for the SKA ............................................................................................ 34
13.3 Way Forward ......................................................................................................................... 34
14 HUMAN FACTORS ENGINEERING .................................................................. 35
14.1 Introduction .......................................................................................................................... 35
14.2 Why is it Important for the SKA? .......................................................................................... 36
14.3 Way Forward ......................................................................................................................... 37
15 TESTABILITY AND FAULT DIAGNOSIS REQUIREMENTS ......................................... 38
15.1 Motivation ............................................................................................................................. 38
15.2 Overall Testability Principles and Requirements .................................................................. 38
15.3 Testability Requirements ...................................................................................................... 39
15.3.1 Controllability ................................................................................................................ 39
15.3.2 Observability ................................................................................................................. 39
15.3.3 Granularity .................................................................................................................... 39
15.3.4 Fault Model ................................................................................................................... 39
15.3.5 Fault Coverage .............................................................................................................. 39
15.3.6 Hierarchical and Modular Testing ................................................................................. 39
15.3.7 Functional Testing ......................................................................................................... 39
15.3.8 Interconnect and Interface Testability Requirements .................................................. 39
15.3.9 Testability Design Requirements .................................................................................. 40
WP2-005.010.030-TR-001 Revision : E
2010-02-11 Page 5 of 48
15.3.9.1 Design Test and Verification Plans ........................................................................ 40
15.3.9.2 Manufacturing Test Plan ....................................................................................... 40
15.3.9.3 Factory Acceptance Test (FAT) Plan ...................................................................... 40
15.3.9.4 Site Acceptance Test (SAT) Plan ............................................................................ 40
15.3.9.5 In-Service Test Plan ............................................................................................... 40
15.3.9.6 Service and Repair Test Plan ................................................................................. 40
15.4 Definitions ............................................................................................................................. 40
16 CONFIGURATION AND CHANGE MANAGEMENT ................................................ 42
16.1 What is Configuration Management? ................................................................................... 42
16.2 Why is it Important ............................................................................................................... 43
16.3 Way Forward ......................................................................................................................... 43
17 DATA PACKS ........................................................................................... 45
17.1 What are Data Packs? ........................................................................................................... 45
17.2 Way Forward ......................................................................................................................... 45
18 INTERFACE MANAGEMENT ......................................................................... 46
18.1 Introduction .......................................................................................................................... 46
18.2 Current Situation ................................................................................................................... 46
18.3 Way Forward ......................................................................................................................... 47
19 ACKNOWLEDGEMENTS .............................................................................. 48
LIST OF FIGURES
Figure 1: A best practice cost estimating process................................................................................. 14
Figure 2: Software risk characteristics. ................................................................................................. 24
Figure 3: Level 5 functions and functional interfaces. .......................................................................... 47
WP2-005.010.030-TR-001 Revision : E
2010-02-11 Page 6 of 48
LIST OF ABBREVIATIONS
ALMA ............................. Atacama Large Millimetre Array
BECL ............................. Basis of Estimate Confidence Level
CDR ............................... Critical Design Review
CI ................................... Configuration Item
CMS .............................. Configuration Management System
COAR ............................ Consolidated Observation Action Register
CoDR ............................. Concept Design Review
COTS ............................ Commercial Off The Shelf
DRM .............................. Design Reference Mission
EMC .............................. Electromagnetic Compatibility
EMI ................................ Electromagnetic Interference
FAT ................................ Factory Acceptance Test
FCA ............................... Functional Configuration Audit
FMECA .......................... Failure Modes, Effects and Critically Analysis
HFE ............................... Human Factors Engineering
HPC ............................... High Performance Computing
IEC ................................ International Electrotechnical Commission
IEEE .............................. Institute of Electrical and Electronics Engineers
ITU ................................. International Telecommunications Union
ICD ................................ Interface Control Document
INCOSE......................... International Council on Systems Engineering
ISO ................................ International Standards Organisation
LEMP ............................. Logistic Engineering Management Plan
MIL-STD ........................ Military Standard
MTBF ............................. Mean Time Between Failures
MTTR ............................ Mean Time To Repair
OAR ............................... Observation Action Register
OEM .............................. Original Equipment Manufacturer
OICD ............................. Operator Interface Control Document
PCA ............................... Physical Configuration Audit
PDR ............................... Preliminary Design Review
PEMP ............................ Power Engineering Management Plan
PITF ............................... Power Investigation Task Force
PPR ............................... Pre-production Review
PrepSKA........................ Preparatory phase for the SKA
RAM .............................. Reliability, Availability and Maintainability
WP2-005.010.030-TR-001 Revision : E
2010-02-11 Page 7 of 48
RAS ............................... Radio Astronomy Service
RFI ................................. Radio Frequency Interference
RQZ ............................... Radio Quiet Zones
SAT ............................... Site Acceptance Test
SEMP ............................ System Engineering Management Plan
SI ................................... Système International d'unités
SKA ............................... Square Kilometre Array
SKADS .......................... SKA Design Studies
SPDO ............................ SKA Program Development Office
SRR ............................... (Sub)System Requirements Review
SSEC ............................. SKA Science and Engineering Committee
STaN ............................. Signal Transport and Networks
TRR ............................... Test Readiness Review
WBS .............................. Work Breakdown Structure
WP ................................. PrepSKA Work package
WP2-005.010.030-TR-001 Revision : E
2010-02-11 Page 8 of 48
1 Introduction
The purpose of this document is to address and set out high level strategies for various important
aspects within the Square Kilometre Array project.
For each of the aspects a way forward is being proposed. Although they are primarily aimed at the
Preparatory Phase of the SKA (PrepSKA) of the project some of them do attempt to look beyond the
PrepSKA phase.
Each strategy also sets out guidelines of the work and aspects to take into consideration within the
various domains and lower levels of the project.
WP2-005.010.030-TR-001 Revision : E
2010-02-11 Page 9 of 48
2 References
[1] Schilizzi R. T., et al.: ‘Memo 100 – Preliminary Specifications for the Square Kilometre Array’,
dated 2007-12-00.
[2] Alexander P., et al., ‘SKADS Memo T4, SKADS Benchmark Scenario Design and Costing’,
http:/www.skads-eu.org/PDF/SKADS_Benchmark_Scenario_D+C_v1.0.pdf; 2007-03-09.
[3] Bolton R., et al.: “SKA Memo 111, SKADS Benchmark Scenario Design and Costing – 2”;
http://www.skatelescope.org/PDF/memos/111_Memo_Bolton.pdf; uploaded 2009-07-24
but based on work completed 2008-10.
[4] Cordes J., et al., ‘The Square Kilometre Array, Project Description for Astro2010, Response to
Program Prioritization Panels, 1 April 2009’, http://www.nrao.edu/A2010/rfi/SKA.pdf ; 2009-
04-01.
[5] The SKADS Teams, ‘Aperture Arrays for the SKA: the SKADS White Paper’, To be published.
[6] United States General Accountability Office (GAO), ‘GAO Cost Estimating and Assessment
Guide – Best Practices for Developing and Managing Capital Program Costs’, GAO-09-3SP,
2009-03-00.
[7] K. Cloete, ‘Strategy to Proceed to the Next Phase’, document WP2-005.010.030-PLA-001,
Revision D, dated 2010-02-08.
[8] Notes from Power Investigation Task Force (PITF) Meeting 1, Cape Town, 17 February 2009,
http://www.skatelescope.org/pages/PITF_meeting_17Feb2009/hall_meeting_notes.pdf
[9] SKA Memo 73, ‘Spectrum Protection Criteria for the Square Kilometre Array, SKA Task Force
on Regulatory Issues’, November 2005
[10] R. P. Millenaar, A-J Boonstra, ‘The Radio Frequency Interference environment at candidate
SKA sites’ , document WP3-010.020.000-R-001, Rev 1.2, dated 2101-02-05.
[11] Protection criteria used for radio astronomical measurements, ITU-R Recommendation
RA769-2, 2003
[12] Wikipedia - http://en.wikipedia.org/wiki/Standardization
[13] D. Liebenberg, ‘SKA Logistic Engineering Management Plan (LEMP)’, document
WP2-005.010.030-MP-002, Rev C, dated 2010-01-18.
[14] K Cloete, ‘System Engineering Management Plan’, document number WP2-005.010.030-MP-
001, Revision E dated 2010-02-02.
[15] K. Cloete, ‘Risk Management Plan’, document MGT-040.040.000-MP-001, Rev 1, dated
2009-08-03.
[16] K. Cloete, ‘PREPSKA Documentation Standards, Handling and Control’, document number
MGT-040.010.010-MP-001, Rev C, dated 2009-04-02.
[17] Wikipedia – Human Factors (http://en.wikipedia.org/wiki/Human_factors)
[18] INCOSE Publications, ‘Systems Engineering Handbook – A guide for system life cycle processes
and activities’, V3.1 dated August 2007.
[19] “IEEE Std 1149.1 (JTAG) Testability Primer”,
http://focus.ti.com/lit/an/ssya002c/ssya002c.pdf,
[20] SSYA002C, Texas Instruments Semiconductor Group, 1997
[21] “IEEE Std 829-1998: IEEE Standard for Software Test Documentation”, ISBN 0-7381-1443-X,
1998
[22] Wikipedia - http://en.wikipedia.org/wiki/Configuration_management
[23] P. Dewdney et al, ‘High-Level SKA System Description’, document WP2-005.030.010-TD-001
WP2-005.010.030-TR-001 Revision : E
2010-02-11 Page 10 of 48
[24] D. Hall, “PrepSKA WP2.6 Strategy for Development of – and Cost Estimation for – Software
and Computing Architectures” draft revision B dated 2010-02-05
[25] D. Hall, “PrepSKA Cost Estimation Practices” draft version E dated 2010-01-20
WP2-005.010.030-TR-001 Revision : E
2010-02-11 Page 11 of 48
3 Cost
3.1 Introduction
In support of the primary objective of PrepSKA it is important that a coherent and credible strategy
for obtaining and refining of the cost of the Square Kilometre Array (SKA) be established. This
document will set out the guidelines for this strategy and propose a process whereby the costs can
be obtained and managed.
3.2 Current Situation
Various cost estimates of the SKA have been published throughout the past few years (see for
example [1], [2] and [3]) with the most recent the Astro 2010 estimate [4] and that of the SKA Design
Studies (SKADS) [5]. However, due to varying assumptions and implementations coupled with
significant unknowns and exclusions and in some cases the lack of traceability and supporting
documentation, it is difficult to compare these estimates of cost or make significant conclusions or
deductions. One of the primary roles of the SKA Program Development Office for PrepSKA WP2
funded work in this area will therefore be to establish a framework and strategy to ensure that
consistent costing information is gathered and that the accuracy of the estimates of all of the costs
required to deliver the performance specifications defined in the SKA Design Reference Mission,
which in turn have been derived from SKA science goals, be refined as the project moves forward.
The majority of the previous cost estimations have been done using the SKACost software tool that
has been in development over the past few years. The tool has been expanded and enhanced
continuously and is capable of capturing and handling quite complex designs (see for example the
recent SKADS whitepaper [5]. Work has also being done quite recently to compare the results of the
tool with the actual results achieved during the design and construction of a small array. However,
within the context of the SKA the current focus is not on the tool itself but on laying the foundation
and providing the guiding principles for the costing exercise. The utilisation of the tool within the
WP2 costing context still needs to be confirmed but it is foreseen that the tool will be a significant
part of the toolsets to be used during this process.
3.3 Characteristics of a Credible Cost Estimate
As indicated in [6] the characteristics of a credible estimate of costs are:
a) Identification of tasks and traceability
b) Broad participation
c) Valid source data
d) Work breakdown structure
e) Communication of uncertainties
f) Allowing for exogenous economic impacts
WP2-005.010.030-TR-001 Revision : E
2010-02-11 Page 12 of 48
g) Excluded costs
h) Independent review
i) Revision of estimates
During the cost estimation to be performed in WP2 all attempts will be made to produce an
estimate that will adhere to these characteristics [25].
3.4 Basis of Estimate
Regardless of the level of detail required during the costing exercise, supporting documentation will
not only provide a clear and complete understanding of how the cost estimate was derived, it will
form the basis on which the confidence in the number that has been produced will rely. At the
outset of the project and mainly due to uncertainties and unknowns, this confidence level might be
quite low. As the project moves forward the aim should be to refine and improve the level as well as
the confidence of the costing.
In this regard any cost estimate to be included as part of the WP2 cost estimate will have an
associated Basis of Estimate Confidence Level (BECL) rating attached to it. This rating will rely heavily
on the supporting information and documentation underpinning the particular cost. The typical level
of the supporting documents and the system engineering phase during this level should be achieved
are shown in the table below.
BECL Description Typical Documentary Evidence Typical Phase and
Artefacts
BECL5 Lowest BECL rating
Costs based on anecdotal evidence and best guess scenarios
Undeveloped specifications and technology under design
Expert opinion or vendor target prices
Description of scaling laws used in estimates
Concept Definition
Concept Design Review (CoDR)
BECL4 Technical specifications in rough draft stage
Costs either anecdotal or best guess
Physical quantities are reasonably well known
All aspects speculative but at a mature stage of discussion within the group
Schedules, contracts, risk plans all in progress
Relationships with potential suppliers under development
Vendor written estimates or quotes requested without competitive tender
Description of scaling laws used in estimates
Sub-System Definition
System Requirements Review (SRR)
WP2-005.010.030-TR-001 Revision : E
2010-02-11 Page 13 of 48
BECL Description Typical Documentary Evidence Typical Phase and
Artefacts
BECL3 Technical specifications under peer review
Costs obtained from reliable sources and reiterated several times
Physical quantities are known to high degree
Designs finalised and agreement reached on implementation modes
Costs and methodologies accepted throughout the group
Risk mitigation plans are documented
Quotes requested without competitive tender, catalogue prices or historical prices from previous projects
Description of scaling laws used in estimates
Preliminary Design
Preliminary Design Review (PDR)
BECL2 Technical specifications finalised
Delivery schedule is finalised
Physical quantities are finalised
Contractual arrangements being concluded
Change management procedures are in place for variations
Integration into system known, documented and costed
Associated labour costs known
Logistics of supply and delivery known and costed
Costs corroborated by at least one other peer in the group
Risk mitigation plans are being followed
Quotes for supply under competitive tender
The use of scaling laws to estimate costs is not acceptable at this stage
Detailed Design
Critical Design Review (CDR)
BECL1 Most accurate BECL rating
Corroborative evidence from actual costs incurred elsewhere, e.g. from precursor projects
Supply contract firm
Change control is under close management
Labour rates firm for at least 12 months
Schedules and risks are quantified
Continuous improvement of estimating data and the estimating process
Actual costs are being tracked against budget estimates
Earned Value Management systems in place
Tooling and early fabrication
Production Readiness Review (PR)
BECL will typically have to be allocated to each element of the work breakdown structure and the
rating will be allocated in consultation with SPDO Domain Specialists and Engineers.
When scaling has been used a description of the scaling and justification of its use should be
included in the accompanying documentation and clearly be identified in the BECL rating (by the
addition of a suffix “(F)” to the BECL rating, for example BECL5 (F)).
The accuracy of a PrepSKA WP2 estimate of costs for a particular item will be dependent upon both
the estimate of cost per item and the number of items required. The BECL rating will also therefore
depend upon the maturity of the designs for the overall system and sub-systems.
WP2-005.010.030-TR-001 Revision : E
2010-02-11 Page 14 of 48
As the project progresses, design reviews will be undertaken in order to review SKA plans. As these
reviews are passed, the confidence in the design should improve and the risks associated with
estimated quantities should diminish, as will the BECL numerical rating.
3.5 Way Forward
A best practice cost estimating process, as defined in [6] is shown in Figure 1. It is not proposed that
all these elements and steps of the cost estimating process be followed within WP2 but rather to
tailor this process to the level and resources available within WP2.
1 2 3 4 5
6 7
8 9 10 11 12
Figure 1: A best practice cost estimating process.
As indicated in [7] the level and the scope of the cost estimate to be produced within WP2 still has to
be formalised. The costs of the full SKA will also be closely linked to work and outputs being
produced in the other work packages. Until such time the following way forward is proposed to
bring more formalism and coherency to the WP2 cost estimating process:
1) The SPDO project director, project engineer and project manager to formalise scope, extent and
level of accuracy of costing to be obtained within WP2,
2) With this deliverable as the end goal the SPDO project manager will develop and formalise the
process and steps to be followed to ensure that aim will be met,
3) Once finalised the process and steps will be communicated, with the support of the domain
specialists, to the rest of the community. The domain specialists will support the community in
their efforts to implement the process and to deliver the required information, data and
documents.
4) The SPDO project manager to establish the tools and mechanisms to capture, analyse and report
the cost estimate
5) SPDO domain specialists to familiarise themselves with the SKA costing tool and the existing
design blocks,
WP2-005.010.030-TR-001 Revision : E
2010-02-11 Page 15 of 48
6) The integration and use of the SKA cost tool within this context to be formalised,
7) Regular update of the cost estimate and confidence level.
4 Power
4.1 Introduction
The distributed power supply for the envisaged load of the SKA will be large, complicated and
expensive. Failure to address and focus on power issues from very early on in the project will most
probably result in power consumption and its related establishment and operational costs,
becoming the major inhibitor on the scope, size and extent of the SKA. A carefully constructed and
well executed power engineering plan will therefore be critical to whether the SKA will actually be
the ground-breaking instrument it is setting out to be.
4.2 Current Situation
That power delivery to, and the lifetime power consumption of, the SKA will be a major challenge.
This has been recognised by the project and led to the establishment of the Power Investigation Task
Force (PITF) in 2009. Its current terms of reference are identified as: [8]
• Work with the SPDO and others to determine representative power demand figures for
various SKA implementation scenarios, including profiles for demand evolution
• Investigate technological and operations strategies for reducing SKA power demand, and
liaise with the SPDO and others in ensuring these options are included in the SKA system
design process
• Investigate in broad terms the power options - including renewable options - that might be
feasible at candidate central and remote sites
• Investigate the cost of power provision to the SKA for various supply and demand scenarios,
and set out representative cost contributions to the SKA total cost of ownership
• Investigate the scientific and operational consequences of capping the SKA power demand
at various levels over the instrument’s development and operations phases
• Investigate key international power system expertise likely to be available to the SKA
project, and compile a list of interested regional companies or other bodies
• Describe innovative power solutions already being trialled within Pathfinders or Design
Studies.
• Provide a summary of PITF findings to relevant PrepSKA work packages
WP2-005.010.030-TR-001 Revision : E
2010-02-11 Page 16 of 48
PITF activities:
• Continue to stress to all SKA stakeholders the importance of total cost of ownership
optimisations
• Help the SPDO formulate the brief for the Work Package 3 (WP3) infrastructure consultants
• Ensure that Pathfinder power issues are well communicated to the SPDO, especially in terms
of the input to the WP2 system design
• Develop a lexicon to allow SKA operational requirements ( including power supply reliability
needs) to be discussed with power system experts and power providers
• Promote discussion with the SKA science and engineering community of the effect of
representative energy caps on SKA science capability at given epochs
• Provide an informal forum to allow pathfinder teams and others to share experiences and
insights
The PITF conducted two major meetings during the past year and various presentations and reports
are available. The focus of these gatherings has, to a large extent, been focussed on power delivery
to site. During the PITF meeting in October 2009 several industry representatives also made
presentations and Parsons Brinckerhoff prepared and presented a report titled “Review of
Generation Technologies, Trends and Costs”. Due to all the uncertainties in the project, the report
dealt with general issues with regards to the supply and cost of power and did not focus on the SKA
specifically. The intention is to redirect the focus of these kinds of studies as more information and
data for the SKA becomes available.
Apart from the PITF activities several other estimations of SKA power consumption requirements
have been made, with the latest being the Astro 2010 submission [4] and the SKADS whitepaper [5].
In general these estimates are fairly coarse and are based on a variety of assumptions.
Current planning within the project includes the future contracting of a consultant under the
auspices of WP3 to estimate the costs of power delivery options for both sites.
4.3 The Challenge
The SKA power challenge is multidimensional and will require coherent efforts on many fronts
before a clear view on the overall power requirements will be possible. Aspects to be addressed
during the next phases of the project will include:
1) Power delivery options to the core site.
2) Power delivery options to the intermediate region.
3) Power delivery options to the remote stations.
4) Backup power requirements.
5) Uninterrupted power requirements.
WP2-005.010.030-TR-001 Revision : E
2010-02-11 Page 17 of 48
6) Power reticulation on the core, intermediate and remote sites.
7) The influence on the design of the power delivery and reticulation systems due to stringent
EMC requirements as well as monitoring and control, health and safety and support aspects.
8) The size and location of facilities and buildings.
9) The accuracy of power consumption estimations of the various pieces of equipment.
10) The efficiency of cooling, heating and other temperature stabilisation equipment.
11) Loss in efficiencies due to several power conversions per chain.
12) The focus of designers to drive down the power consumption of their equipment.
13) Measurement of the power consumed by the current precursor and pathfinder equipment.
14) The identification and management of gaps.
15) Resources to carry out all the work including the management of the effort, the gathering
and consolidation of information and data, the designs down to the level required to
accomplish the fully costed system design goal of WP2.
4.4 Way Forward
From the previous paragraphs it is clear that the power challenge will require a major and coherent
effort within the SKA community. The following short term activities are therefore proposed:
1) Re-evaluation of the PITF terms of reference and interaction with the SPDO to ensure that the
two entities work in a coherent and integrated manner.
2) Confirmation of the division of work between the PITF, WP2 and WP3 to ensure that all bases
are covered. Gaps will be highlighted and actions put into place to address them.
3) The development of a Power Engineering Management Plan (PEMP) to guide all the activities
and efforts in the SKA.
4) The consolidation of all the work with regards to consumption estimates and options for delivery
done thus far.
5) Consolidation of the work, results and lessons learnt within the precursor, pathfinders and
design study projects.
6) The establishment of a power audit group whose exclusive task it will be to focus on power
aspects during the various design reviews at system and element levels of the project.
7) The evaluation of the availability of power engineers and other skilled resources to assist and
contribute to the SKA effort.
8) Confirmation to the Domain Specialists conducting their concept design reviews during the
remainder of this year that it will be expected that they put forward first order power
WP2-005.010.030-TR-001 Revision : E
2010-02-11 Page 18 of 48
consumption estimates and a coherent plan and strategy on how the power issues within the
domain will be dealt with.
9) Due to the scope and diversity of the power system, consideration should also be given to
structure it as a separate domain within WP2.
Longer term planning will be done once these activities have been completed and the PEMP has
been finalised. The initiation of these activities will be the responsibility of the WP2 project manager.
5 Electromagnetic Compatibility (EMC)
5.1 Introduction
The SKA, as a system, will potentially be very vulnerable to its electromagnetic environment, owing
to its extreme sensitivity; hence the decision to build the system in a remote desert environment
with very low population density. Its complexity, coupled with its reliance on high speed digital
electronics, also make it a potential source of electromagnetic disturbance, both to itself and to
nearby radio astronomical experiments. Therefore procedures must be put in place to ensure that
the SKA design and implementation are such that there is electromagnetic compatibility within the
project and with its surroundings.
A distinction must therefore be made between self generated interference and the external Radio
Frequency Interference (RFI) environment. The activities addressed in this chapter of the document
relate to the identification and mitigation of self generated RFI through design and testing. The
mitigation at each step within the signal chain will be addressed will be addressed in the various
domains of the project.
5.2 Terminology
Electromagnetic Compatibility (EMC) is defined as the ability of an equipment or system to
function satisfactorily in its electromagnetic environment without introducing intolerable
electromagnetic disturbances to anything in that environment.
Electromagnetic Interference (EMI) is an unwanted signal from an external source of
electromagnetic disturbance, it may be conducted, e.g. via power lines, or radiated.
Radio Frequency Interference (RFI) is radiated EMI.
5.3 Standards and specifications
There is a vast array of industry standards relating to EMC. Some of the standards bodies are listed
below.
CENELEC: European Committee for Electrotechnical Standardization
CISPR: The International Special Committee on Radio Interference
WP2-005.010.030-TR-001 Revision : E
2010-02-11 Page 19 of 48
ETSI: The European Telecommunications Standards Institute
AS/NZS: Australian/New Zealand Standards
CSA: Canadian Standards Association
EN: European Standards
IEEE Standards
ISO: International Organization for Standardization
MIL-standards
SAE International: formerly the Society of Automotive Engineers
SANS : South African Standards NRS 083-2 and SANS 61000-5-2
ITU-R RA769-2 - International Telecommunications Union
Whilst the specifications provided by these bodies are unlikely to be sufficiently stringent to meet
the requirements of a sensitive radio astronomy array, and the requirements of a radio astronomy
radio quiet zone (see [9] and [10]), they nevertheless give valuable insight into the likely
performance of commercial off the shelf (COTS) hardware and other on-site equipment. They may
also provide useful information, such as best design practice to achieve low emitted EMI, or low
susceptibility to EMI. A thorough review of existing EMC standards is thus an important part of the
overall SKA EMC strategy.
The International Telecommunications Union (ITU) has published a number of ‘Recommendations’
for the levels of tolerable RFI for the radio astronomy service (RAS), most importantly ITU-R RA769-2
(see [11]), which should form the basis of RFI specifications for the SKA, as part of the overall EMC
specifications. This specification will be the primary reference for EMC matters.
5.4 EMC zones and SKA array configuration
During the planning of the SKA array configuration and site layout various EMC zones will be defined,
based on the Radio Quiet Zones (RQZ) specifications given in Memo 73. These will relate to the
susceptibility of equipment within each zone to EMI, and to its potential for causing EMI. For
example dense aperture array tiles would be in a zone of high susceptibility, but low potential for
causing EMI. Beam-former hardware would be in a zone with high EMI causing potential, but low
susceptibility. Culprits and victims of EMI need to be identified within these zones and methods of
dealing with them developed and put into practice.
The SKA configuration could have a major effect on EMC. For example, the separation distances of
antennas will significantly affect the potential levels of interference between them. Location of
outlying antenna stations, and their proximity to dwellings, roads, power lines etc., will be another
important criterion. These aspects are being addressed as part of WP3.
WP2-005.010.030-TR-001 Revision : E
2010-02-11 Page 20 of 48
5.5 Design of SKA hardware
All hardware designed specifically for use in the SKA will be designed to meet the requirements of
the SKA EMC Plan which will identify the zonal requirements. As discussed above there will be two
factors.
1. SKA hardware shall not cause harmful EMI to the SKA itself, or to any other experiment.
2. SKA hardware shall be designed to be tolerant to the levels of EMI that are to be expected or
cannot be avoided, such as RFI from aircraft and satellites.
5.6 Commercial off the shelf (COTS) hardware
Exactly the same principles will apply to COTS hardware as apply to hardware designed specifically
for the SKA.
1. SKA hardware shall not cause harmful EMI to the SKA itself, or to any other experiment.
2. SKA hardware shall be designed, as far as possible, to be tolerant to EMI.
In purchasing COTS hardware there may be limited, or no, influence over the design, so the
emphasis here will be on selection of appropriate hardware, and on using that hardware in a way
that meets the EMC requirements. For example some COTS hardware is likely to need additional
screening and filtering in order to make it compliant.
5.7 Support equipment and services
In addition to the hardware that forms the SKA Telescope there will be a wide range of support
equipment and services associated with the construction and operation of the telescope. The SKA
EMC Plan will specify EMC requirements for all equipment and services that have the potential to
cause EMI to the SKA or other experiments. Some aspects to be considered are as follows. Different
criteria exist for construction and operation phases of the telescope.
Specification of maximum tolerable RFI levels from equipment (e.g. vehicles)
Specification of RFI screening for buildings
Specification of conducted EMI limits for buildings
Policies for constructors (e.g. working times, proximity to antennas in use)
5.8 Measurement
A comprehensive measurement scheme will be vital to ensure that the SKA performance is not
compromised by EMI, and that the SKA does not compromise the performance of other radio
astronomy experiments.
WP2-005.010.030-TR-001 Revision : E
2010-02-11 Page 21 of 48
A strategy of starting EMI measurements at as low a level as possible and as early as possible will be
followed. This will ensure that equipment does not arrive on site and resulting in having to use the
telescope itself as an RFI measuring instrument.
5.8.1 Approvals testing
Any item that consumes electrical power is a potential source of EMI, so all such items must be
tested to ensure that they meet the requirements of the SKA EMC Plan. In some instances it may be
decided that 100 % testing of a particular type of item is necessary, for example where that item is
located adjacent to an antenna element. In other cases it may be possible to type-test items and
approve their design.
5.8.2 Conducted emissions
Industry standard test methods exist to determine conducted emissions from equipment. It will be
necessary to study these methods to determine those most appropriate for the SKA, and to extend
them in frequency and sensitivity where necessary.
5.8.3 Radiated emissions
Industry standard test methods for radiated emissions (RFI) will not meet the requirements of the
SKA, except for equipment housed in well-screened enclosures remote from the antennas. Special
purpose test facilities, using receivers with sensitivities comparable with the SKA receivers, will need
to be produced in order to test SKA hardware. The establishment of these facilities will only be
possible during the later phases of the project and closer to the eventual roll out of Phase 1 on site.
5.8.4 Site RFI measurement
5.8.4.1 2005 Campaign
As part of a preliminary site characterisation campaign during 2005, measurements were conducted
at both the Australian and South African sites. The results of these measurements are summarised in
[4]. Follow on measurements will be conducted during this year (2010) as part of PrepSKA WP3.
5.8.4.2 Preparatory phase
Simultaneous test campaigns are already under way in Australasia and Southern Africa. These are
aimed at characterising the two core sites and a selection of remote station sites. The
measurements are expected to be completed by the end of 2010. After that period the two sets of
portable measurement equipment will be available to perform extended duration site
measurements, and to do dedicated searches for RFI. The equipment can be used later in the
project, and to test the EMI status of ancillary equipment such as power supplies etc.
5.8.4.3 SKA construction phase
Great vigilance will be necessary during the SKA construction phase, in order that observations can
be made with the growing SKA, and that other radio astronomy experiments are not compromised
WP2-005.010.030-TR-001 Revision : E
2010-02-11 Page 22 of 48
by EMI from the SKA construction. Specialist staff (“EMC Police”) will be needed, equipped to carry
out all necessary measurements and advise on solution to problems.
5.8.4.4 Long term operation
After completion of the SKA there will still be a need to maintain vigilance concerning EMC. This will
require permanent staff suitably equipped to investigate and solve EMC problems as they arise.
“Suitably equipped” may mean the establishment of a measurement facility for SKA purposes. Part
of their task will be to continuously monitor RFI at the SKA sites.
5.9 RFI Mitigation
The ambitious and demanding aim of the SKA EMC Plan will be to avoid RFI/EMI. In the first instance
the choice of sites for the receptors will be made with this as a high ranking criterion. Design and
selection of hardware that does not generate harmful RFI, and has minimal susceptibility to RFI, are
the other major requirements of the strategy. Failure to address these requirements fully will result
in a need for expensive remedial work.
Even when all the steps described above have been taken, there will still be residual levels of RFI
that have to be accommodated by the SKA systems. One example of this is RFI from satellites.
Various RFI mitigation strategies are possible, and these must be identified in the SKA RFI Mitigation
Plan, developed. RFI mitigation can be undertaken at various points in the system as follows.
1. In the environment (RQZ, regulatory measures and law-making)
2. At the receptor
3. In the analogue section of the receiver
4. At the station or beamforming stage
5. Mitigation integrated in correlator
6. Post correlation
7. Post imaging
5.10 EMC Costing
A mechanism for the establishment of the cost of EMI and RFI mitigation will need to be created by
the EMC manager. Continual trade-offs between the cost of RFI mitigation measures and the
specified limits will have to be made to find the optimal balance.
5.11 Way forward
An EMC manager will be appointed to co-ordinate the EMC activities relating to the SKA project.
He/she will be responsible for the following.
Investigation of existing standards and descriptions of best practice, from industry and the
radio astronomy community
WP2-005.010.030-TR-001 Revision : E
2010-02-11 Page 23 of 48
Ensuring that EMC requirements are drawn-up for all aspects of the project
Communication of those requirements to all who design and/or purchase equipment for use
in the SKA
Assessment of Commercial Off The Shelf (COTS) hardware that is proposed for the SKA
Development of test systems to determine the emissions from hardware at levels down to
the expected noise floor of the SKA
Development of the SKA EMC Plan that includes all of the specifications and strategies for
ensuring that the specifications are met
Ensuring that the EMC Plan ties in with the existing Systems Engineering approach to the
outputs of PrepSKA, and that EMC activities are aligned with the scheduled milestones and
deliverables.
It is not proposed that a dedicated EMC manager be appointed during PrepSKA but that the role be
allocated to the SPDO system engineer. During the post PrepSKA phases a dedicated manager will be
required.
An EMC Group will be established during PrepSKA, and this will continue its work into the SKA
implementation phase. The work of this group will be overseen by the EMC manager, and will
include specification of standards and measurement protocols, i.e. what measurements are to be
done at which level and how these will build into the complete system. The EMC manager should be
appointed as soon as possible after the system Concept Design Review (CoDR), and the EMC group,
which would include an RFI Mitigation Advisor, should be in place by the time the last of the CoDR’s
for the various elements of the system have been completed.
6 Software Engineering
6.1 Introduction
Large scale software projects and developments are, by themselves, very challenging. Add to this the
complexity of distributed teams, varying approaches to software development and testing,
utilisation of different development environments and tools, unclear and far from stable
requirements and the possible integration of existing software and one can imagine the challenge
that the SKA software is facing.
As depicted in the diagram below, the combination of all these influences and factors contribute to
an increase in the risk and will therefore need well thought through strategies and plans to
successfully mitigate these risks.
WP2-005.010.030-TR-001 Revision : E
2010-02-11 Page 24 of 48
Figure 2: Software risk characteristics.
6.2 Current Situation
Due to various characteristics of funding agency objectives and the radio astronomy community’s
aspiration for collaboration and inclusivity among contributors to PrepSKA, the software and
computing work package within WP2 has a work breakdown with resources located among
approximately 20 participating mostly academic institutions distributed across the globe. Of these
institutions, five have been identified as lead institutions.
6.3 Way Forward
As already indicated in Section 5.3.2.2 of the SEMP [14], the development of software during the
project will need careful consideration. In this regard, the SPDO software and computing domain
specialist has prepared a Software Development/Engineering Plan for software and computing
aspects in PrepSKA [24]. Within the very near future additional plans will be prepared that address
software development during subsequent phases of the project. Aspects addressed will include the
development strategy across the phases, the documentation to be developed, coding, testing,
quality, tools, standardisation, control and the roll out.
7 Cooling and Temperature Stabilisation
7.1 Introduction
A radio telescope requires the deployment of a wide range of cooling and temperature stabilisation
technologies in diverse environments and systems in order to achieve high-performance and reliable
operation of the facility.
Software development for HPC science
Software development for well structured stable requirements
One central team
Globally distributed
teams
WP2-005.010.030-TR-001 Revision : E
2010-02-11 Page 25 of 48
7.2 Why is it Important
In general the Karoo and Western Australia are hot and hostile environments in which to operate
sophisticated facilities that require controlled temperature environments. It is likely that the capital
and operational expenditure on cooling and other temperature stabilisation technologies will be a
major cost for the SKA itself. The largest part of the operational costs for these technologies will be
the power they consume. With the SKA already facing a major power challenge even small savings
within individual items will go a long way when the items are scaled up to SKA requirements. It is
therefore important to investigate and consider as wide as possible range of cooling/heating/
temperature stabilisation technologies when designing equipment for the SKA.
7.3 Way Forward
Because cooling systems are always associated with a wide range of subsystems and facilities,
cooling is by necessity a cross-cutting technology. Heat generation and cooling is also a multi
layered challenge and in many cases the heat generated by one piece of equipment has to be
removed by another piece of equipment. In addition the cooling and temperature stabilisation
technologies that will be available to the SKA will be wide ranging and will vary from small (such as
micro-coolers) to very substantial pieces of equipment (such as facility air conditioning units).
Wherever possible and desirable the cooling needs of various elements and subsystems should
therefore be amalgamated to avoid the proliferation of a large number of small systems, to benefit
from the economy of scale, and to simplify operations and maintenance. Cooling and RFI are closely
linked in that cooling systems are potentially sources of RFI, and the requirement of RFI shielding of
heat-generating subsystems provides challenges for cooling system implementation.
It is proposed that any implementation or design must follow the following general principles:
The cooling systems must intrinsically generate minimal RFI, and be easy to shield if they
contain unavoidable RFI emitters.
Cooling systems must not compromise the RFI integrity of any component or subsystem
being cooled.
All cooling system components must have high reliability, and be easy to maintain a remote
desert.
The cooling system must run at high efficiency to ensure minimum operating costs.
Information on technologies that might be applicable to the SKA should be gathered and shared
between designers. Any new or innovative cooling or temperature stabilisation technology should
also be made visible to the wider community.
Technologies to be considered include:
1) Gifford-McMahon (GM) cryogenic refrigerators
2) Stirling cycle cryogenic refrigerators
WP2-005.010.030-TR-001 Revision : E
2010-02-11 Page 26 of 48
3) Peltier thermo-electric coolers
4) Micro coolers
5) Heat pipes
6) Chiller refrigeration units (liquid)
7) Heat exchangers
8) Heat storage and recovery systems
9) Ground thermal exchangers
10) Heaters
11) Standard Ventilation
12) Ventilation with heat capacitance
13) Passive cooling with conductive walls
Apart from these technologies the lessons learnt and technologies used in sectors outside radio
astronomy such as large IT centres and mobile phone stations in hostile environments will be
investigated.
Potential concepts and solutions will be reviewed during each of the design reviews. Aspects to be
discussed during the reviews will include the technology options that were investigated, the
solutions that are being considered, the estimated power it will consume, the thermal modelling
work that has been done to support the design and the impact on scaling the proposed solution to
full SKA level. The first round of discussions will be conducted during the upcoming concept design
reviews of the various elements.
On the system level the SPDO will attempt to consolidate work done and results obtained within the
project as well as studies and results that have been obtained from projects outside the SKA. The
SPDO will also ensure that a full life cycle system view be brought to the eventual design and
selection of technologies and solutions.
In addition the SPDO system engineer will ensure that the multilayered aspects of cooling are
addressed from a system perspective to ensure that (as mentioned above) requirements are
amalgamated to avoid the proliferation of a large number of small systems, to benefit from the
economy of scale, and to simplify operations and maintenance.
WP2-005.010.030-TR-001 Revision : E
2010-02-11 Page 27 of 48
8 Reliability, Availability, Maintainability (RAM)
8.1 Introduction
In order to identify and develop the optimum range and quantity of logistic support resources, and
to have the logistic support considerations influence the design, a measure of the operational
performance for the system is required.
This is documented in Reliability, Availability & Maintainability (RAM) expectations which originates
from the top hierarchical levels1 of the project (typically the level 7 User System) and is fed down to
lower levels.
Reliability is a measure of a system’s ability to avoid failure. Low reliability could result in impaired or
lost performance, compromised safety and the need for maintenance. The most convenient
measure of reliability is the Mean Time between Failures (MTBF) and as an average it is easier to
derive than a probability and is useful for calculations.
Maintainability is the probability that a system, as a result of failure, will be restored within a given
period of time, exclusive of logistic or administrative delays. The most convenient measure of
maintainability is the Mean Time to Repair (MTTR) and as an average it is easier to derive than a
probability and is useful for calculations.
Availability is the probability that a system is operating satisfactorily at any point in time under
stated conditions. It is a measure of how often an item fails (Reliability) and how quickly it can be
restored to operation (Maintainability).
8.2 Way Forward
A two pass approach to the RAM and the failure modes, effects and critically analysis (FMECA)2
processes is proposed. To be able to complete and cost the system design by the end of PrepSKA,
first high level estimates will be used from the top and from the bottom to do a first pass of the
process. The bottom numbers will be obtained during, for example, the various CoDRs to be
performed over the next year. These high level numbers and resultant design will be reviewed at the
system PDR at the end of PrepSKA. The process will have to be repeated as the information and data
from the top and the bottom are refined during the post PrepSKA phases.
For PrepSKA the process will therefore be:
1) Confirm the operational cycles of the system as detailed in the Logistic Engineering Management
Plan (LEMP) Section 2.4 in order to derive user system (level 7) RAM figures.
2) Confirm the failure contributions of the system (level 6) entities in order to derive system RAM
figures.
1 For more information on hierarchical levels refer to [14]
2 For more information on these processes refer to [13]
WP2-005.010.030-TR-001 Revision : E
2010-02-11 Page 28 of 48
3) Use derived figures as input to the top level specifications as values to be allocated to the lower
levels (top down allocation).
4) From the lower levels, utilise RAM estimates provided during, for example, the relevant element
and subsystem concept design reviews, to derive higher level RAM estimates (bottoms up
estimation)
5) Identify the RAM drivers by comparing top down allocations with bottoms up estimates and
identify action plans to mitigate non compliances where required.
6) Use high level RAM figures as an input to the FMECA and task analysis efforts to determine first
order of magnitude logistic support resources.
7) Use the high level FMECA to determine the requirements (such as redundancy) on the system.
9 Standards and Standardisation
9.1 What is Standardisation
Standardisation is the process of developing and agreeing upon technical standards. A standard is a
document that establishes uniform engineering or technical specifications, criteria, methods,
processes, or practices. Some standards are mandatory while others are voluntary. Voluntary
standards are available if one chooses to use them. Some are de facto standards, meaning a norm or
requirement which has an informal but dominant status. Some standards are de jure, meaning
formal legal requirements. Formal standards organizations, such as the International Organization
for Standardization (ISO) or the American National Standards Institute, are independent of the
manufacturers of the goods for which they publish standards [12].
It entails the development and implementation of concepts, doctrines, procedures and designs to
achieve and maintain the required levels of compatibility, interchangeability or commonality in the
operational, procedural, material, technical and administrative fields to attain interoperability.
9.2 Why is it Important
A few examples of the benefits of using standards and standardisation within the SKA project are:
1) The quality of the deliverables across the board is of a high standard,
2) Parts used in different places and different equipment are the same,
3) Tests are performed against internationally recognised standards and are repeatable,
4) Best practices based on years of experience are being followed in a coherent manner and across
borders and different organisations.
The benefits of standardisation are undisputable, however, caution should be exercised when
invoking a standard because it will undoubtedly have an impact on time and effort with the direct
related increase in resources and costs.
WP2-005.010.030-TR-001 Revision : E
2010-02-11 Page 29 of 48
9.3 Way Forward
It is proposed that the PrepSKA phase of the project be utilised to investigate the utilisation of
international standards and their applicability to the SKA. Examples are:
ISO software development standards (ISO/IEC 15288)
Risk management (IEEE 1540)
Quality management (ISO 9001)
Logistics and support (DEF_STD_060, MIL-STD-1388-2B, MIL-STD-1629A).
Health and Safety (MIL-STD-882D, IEC 62061, IEC 61511)
Electronic publications (AECMA 1000D)
Obsolescence (BS EN 62402:2007)
Electromagnetic Compatibility (MIL-STD-461-E, ITU-R RA769-2, NRS 083-2, SANS 61000-5-2)
Configuration Management (ISO 10007:2003)
Environmental testing (IEC 60529, MIL-STD-810,
If found to be applicable and required, the standards will be introduced and made applicable to the
project.
This work shall be undertaken by the SPDO system engineer and first guidance on this matter shall
be presented by no later than the system requirements review.
10 Units of Measure
To ensure compatibility of work carried out around the world it is important to standardise on the
units of measure that will be used within the SKA. It is therefore proposed that the SKA adopt the
same standards as adopted within the ALMA project3. The text below has, to a large extent, been
adopted from this ALMA specification.
SKA Units of Measure
The SKA shall adopt and use the International System of Units (also known as the ‘metric’ or Système
International d'unités, SI).
Specific requirements are:
1) Drawings
3 ALMA Policy document on the use of metric and SI units, document ALMA-80.00.00.00-004-A-SPE, Version A,
dated 2005-04-20.
WP2-005.010.030-TR-001 Revision : E
2010-02-11 Page 30 of 48
All drawings shall quote only SI units except as indicated in points 4 and 5.
2) Computer Aided Design files
Computer aided design files shall use the unit mm (millimetre) for dimensions.
Computer aided design files for concrete structures might use cm (centimetre) for
dimensions.
3) Custom designed components
Only SI units shall be used.
Only interfaces to imperial Commercial Off The Shelf items shall use imperial sizes.
4) Commercial Off The Shelf (COTS) components
COTS items using the imperial system units can be used, only if:
The COTS item is only available in imperial units and there is no equivalent in
SI units,
The COTS item is available in imperial and SI units with a comparable
performance but the costs for the COTS item in SI units are considerable
higher or the lead time is much longer.
A list with all COTS items in imperial units is to be kept by each organisation. Once the SKA
organisation has been established and the project is moving onto the post-PrepSKA phases,
this information shall also be centralised within the system engineering group.
5) Raw material
Raw material in imperial dimensions can be used if not available in SI units.
6) Software code
Only SI units will be used in software codes.
7) Indicators
Only SI units shall be used for indicators. Exceptions are possible if approved.
8) Labelling
A label shall be posted where possible on any equipment if imperial units are used.
9) Interface Control Documents
Any non-compliant item shall be clearly identified especially during the development of
interface control documents and drawings.
WP2-005.010.030-TR-001 Revision : E
2010-02-11 Page 31 of 48
11 Quality
11.1 Introduction
Quality touches each and every aspect of the project ranging from the selection of components,
writing of documents, reviews, acceptance events, audits, inspections, recording and traceability of
supporting information and data, etc...
Definitions for quality management range from the traditional ‘Quality management is an
organisation-wide approach to understanding precisely what customers need and consistently
delivering accurate solutions within budget, on time and with the minimum loss to society’ to the
philosophy of total quality management ‘that seeks to integrate all organizational functions
(marketing, finance, design, engineering, and production, customer service, etc.) to focus on meeting
customer needs and organizational objectives’.
Bringing and establishing this kind of focus on quality to an organisation is a challenge all by itself
and when the ‘organisation’ consists out of many organisations and institutions, all with their own
view and focus on quality, the challenge to achieve a coherent quality strategy and adherence to
processes and procedures becomes even more daunting and this is, of course, the situation the SKA
project finds itself in at the moment. However, in order for work package 2 (WP2) to deliver the fully
costed Phase 1 system design to such a level that the project can seamlessly move forward into the
Detailed Design and Tooling phase, the adherence to and delivery of high quality work will be
essential. To achieve this goal WP2 will largely rely on the establishment, adoption and adherence to
processes.
11.2 Current Situation
The quality objectives for WP2 are to:
Produce the deliverables that meet the Framework 7 revised Description Of Work
objectives,
Produce deliverables that are compliant with applicable contract and project requirements,
Empower personnel to take responsibility for the quality of their products and services,
Prevent and resolve problems by implementing effective work processes,
Promote continuous improvement in work processes to improve quality, timeliness, and
cost-effectiveness, and to
Improve the effectiveness of the processes and their supporting tools, techniques,
standards, and procedures.
To achieve a high level of quality ISO 9001:2008(E), ‘Quality management systems – Requirements’
lists the following general requirements for a quality system:
WP2-005.010.030-TR-001 Revision : E
2010-02-11 Page 32 of 48
The organisation shall establish, document, implement and maintain a quality management
system and continually improve its effectiveness in accordance with the requirements of this
International Standard. The organisation shall
a) determine the processes needed for the quality management system and their application
throughout the organisation,
b) determine the sequence and interaction of these processes,
c) determine criteria and methods needed to ensure that both the operation and control of
these processes are effective,
d) ensure the availability of resources and information necessary to support the operation
and monitoring of these processes,
e) monitor, measure where applicable, and analyse these processes, and
f) implement actions necessary to achieve planned results and continual improvement of
these processes.
It is thus clear that the objectives and the ISO general requirements are closely aligned and towards
this end several processes have already been developed and publicised. Examples of these processes
are:
1) The system engineering process as described in the System Engineering Management Plan [14],
2) The risk management process as described in the Risk Management Plan [15],
3) The documentation handling and control procedure [16],
4) The document review process (to be developed),
5) The configuration and change management process as described in Section 16 of this document.
However, although these processes and procedures have been proposed they are by no means a
complete set and to a certain extent have not been fully rolled out and/or adopted within WP2 yet.
11.3 Way Forward
It is not being proposed that a fully fledged ISO 9001 quality system approach be adopted during the
PrepSKA phase of the project. However, it is clear that as the project moves forward and the SKA
organisation grow, the focus on quality assurance will have to be increased to the extent that a fully
staffed and independent quality assurance division/group forms part of the organisation.
Accreditation against ISO 9001 will also have to be considered at some stage during the early post-
PrepSKA phases.
For the PrepSKA phase the following actions are proposed:
WP2-005.010.030-TR-001 Revision : E
2010-02-11 Page 33 of 48
1) That the Quality Assurance Plan as identified in section 6.11 of [14] be developed as soon as
possible after the system CoDR to provide guidance to all the WP2 participants on all the
matters related to quality,
2) That the processes and procedures already developed be evaluated against the WP2 quality
objectives for completeness and the identification of gaps,
3) That processes and procedures be developed for the gaps that were identified,
4) That these processes be reviewed, be agreed to and eventually be accepted and adopted
within all the organisations and institutions within WP2.
The primary responsibility for quality will reside in the WP2 Domain Specialists, the Liaison Engineers
of the lead institutions and the project managers and system/project engineers of the verification
programs. The adoption and roll out of the processes and procedures and therefore the
achievement and maintenance of high quality outputs and contributions will heavily depend on their
guidance and leadership in this regard.
12 Health and Safety
Health and safety is quite a wide ranging discipline and cuts across many aspects. It is enforced by
legislation and many standards and guidelines have been developed to aid in the guidance,
establishment of requirements and testing of these requirements.
From the SKA perspective it will be important to address the health and safety requirements from
early on to ensure their influence on the design. To initiate this process it is proposed that a Health
and Safety Plan be developed. This document will set out the path for the development and
introduction of health and safety aspects into the SKA. It will also provide guidance on the
development of additional documents and procedures such as the identification of hazards and
identification and mitigation of safety risks. Guidance on the investigation and incorporation of
health and safety matters due to the fact that the SKA will most probably be deployed across local
and international borders will also be provided in the plan.
It is not foreseen that a dedicated resource responsible for safety be appointed during the PrepSKA
phase of the project. However, it may prove to be necessary to establish and allocate resources to a
dedicated safety division within the larger SKA organisation.
For the development of the plan and guidelines already existing radio astronomy documentation
such as those from ALMA should be studied and utilised.
The impact on safety aspects due to the location of the site will also have to be investigated.
The actions in this regard will be initiated by the SPDO project manager with the aim to have high
level plan and guidance on how to proceed with the roll out of safety, including the possible
adoption of standards, by the end of 2010.
WP2-005.010.030-TR-001 Revision : E
2010-02-11 Page 34 of 48
13 Obsolescence
13.1 Obsolescence definition
For the purposes of this document, obsolescence is defined as 1) the impending loss of production of
an item, or support services being no longer available from the Original Equipment Manufacturer
(OEM) or supplier, and 2) the loss, or impending loss, of the manufacturers or suppliers of items, or
shortages of raw materials. The term is also applied to the equipment within a system being made
redundant due to its incompatibility with other sub-systems that have been upgraded / replaced
making them obsolete. Functional obsolescence occurs when equipment no longer operates as it
was originally intended due to wear and tear to a degree where repair makes no sense.
For the purposes of this document, obsolete is defined as being no longer produced or supported by
the OEM or supplier.
13.2 Why is it Important for the SKA
All tangible products are subject to life cycles, so suppliers eventually stop supporting them. Even
software products can be subject to “deprecation” when vendors or development communities no
longer support features prior to removing them from updated versions of code [refer
http://en.wikipedia.org/wiki/Deprecation ]. For systems to be designed and developed over years
and subsequently to be deployed and operated for many more years, product obsolescence and
software deprecation must be addressed. Components and items can become obsolete even before
production stages are being reached. Obsolescence can therefore severely impact the supportability
and life cycle costs of systems.
This will hold true for the SKA. During the Preparatory Phase, which is several years in duration, one
of the main aims will be to develop, build and test prototypes within various domains. The intention
is then to use the results and preliminary designs as input to the Detailed Design phase, during which
time the designs will be refined and preliminary production units developed. This will take another
few years and some components evaluated and used during the Preparatory Phase will be obsolete
by the time detailed designs are carried out.
The challenge does not only apply to the development phases. Once the equipment has been rolled
out on site it has to be supported. Equipment will fail and spares and consumables will be needed. In
the event that (for example) inadequate provision has been made for spares (or critical
components), failures will lead to equipment being not reparable which will most probably force a
re-design, re-production, refitting and retesting of the particular equipment: a process that might be
expensive.
13.3 Way Forward
In many cases companies handle obsolescence in two stages4: Obsolescence Forecasting, and
Obsolescence Management. Obsolescence Forecasting is the predictive/tracking of parts that
4 Obsolescence Management: The need for a proactive, concurrent approach by NR Shekar.
WP2-005.010.030-TR-001 Revision : E
2010-02-11 Page 35 of 48
determines their manufacturing status and market availability. Obsolescence Management is a
mitigation process for handling the outcomes from the forecasting.
During the PrepSKA phase it is therefore proposed that obsolescence be tracked and managed by
the various organisations developing and testing prototypes and that possible obsolescence risks be
made visible as and when they occur.
For those prototypes aimed at completing their preliminary design phase by the end of PrepSKA it
will be very important to review obsolescence risks during each of the design reviews. This is
especially true for the Preliminary Design Review (PDR). Accurate identification and knowledge of
obsolescence risks will enable the SKA organisation to engage with industry in this regard and ensure
that the correct mitigation strategies be identified and implemented from early on in the next phase.
As the project moves into these post PrepSKA phases the identification and management of
obsolescence will become more important and will have to be managed more formally. It is
proposed that the SKA organisation develop and implement an obsolescence management plan in
conjunction with the industries that are involved in the SKA at that stage5. These plans will need to
include strategies for handling the two phases of production that are anticipated for the SKA.
Contracts will be issued for Phase 1 production with the intention that similar, or identical,
production units will later be required in Phase 2. In addition, these plans should alert SKA
procurement personnel to the practice within industry of “built in obsolescence”, more common in
consumer goods, but occasionally found in COTS electronics.
At the time a technology decision is taken for the SKA, due diligence to the matter of obsolescence
should have taken place, resulting in a documented approach to the risk of unforeseen
obsolescence, and a clear plan for predictable obsolescence including upgrade paths to the point of
replacement. The objective of Obsolescence Management is to ensure that obsolescence is
managed as an integral part of design, development, production and in-service support in order to
minimise the financial and availability impact throughout the product lifecycle.
14 Human Factors Engineering
14.1 Introduction
Human Factors Engineering (HFE) is widely used within sectors such as transportation, marine,
health, military and energy. The general aim of HFE is to ensure that a human’s capabilities meet the
demands and expectations being placed on him/her by the job that he/she is performing. The more
formal definition of Human Factors Engineering, as put forward in [17] is:
The discipline of applying what is known about human capabilities and limitations to the
design of products, processes, systems, and work environments. It can be applied to the
design of all systems having a human interface, including hardware and software. Its
5 A standard that may be consulted in this regard is: Obsolescence management. Application guide, document
BS EN 62402:2007.
WP2-005.010.030-TR-001 Revision : E
2010-02-11 Page 36 of 48
application to system design improves ease of use, system performance and reliability, and
user satisfaction, while reducing operational errors, operator stress, training requirements,
user fatigue, and product liability. HFE is distinctive in being the only discipline that relates
humans to technology.
Human factors engineering focuses on how people interact with tasks, machines (or
computers), and the environment with the consideration that humans have limitations and
capabilities. Human factors engineers evaluate "Human to Human," "Human to Group,"
"Human to Organisational," and "Human to Machine (Computers)" interactions to better
understand these interactions and to develop a framework for evaluation.
Human Factors engineering activities include:
1) Usability assurance
2) Determination of desired user profiles
3) Development of user documentation
4) Development of training programs.
HFE is therefore closely related to logistical aspects such as the development of training modules
and user documentation and the development of human machine interface (HMI) software.
14.2 Why is it Important for the SKA?
Being such a large and distributed instrument, the SKA will undoubtedly place high demands on, for
example, its operators and maintainers in terms of information loads. Although not as safety critical
as transport sector operators making mistakes, overloaded personnel within the SKA environment
will make mistakes which may lead to compromising the health and safety of others. These kinds of
situations will have to be avoided by considering human factors during the design of equipment and
HMIs.
HFE can also be applied in a wider context such as the design and layout of operator centres, human
accessible and work spaces, visitor centres etc.
There is a large body of human-machine interface design literature [see for example the Human-
Computer Interaction Bibliography at http://www.hcibib.org/ ], which has at its heart three main
goals6:
Effectiveness – helping users achieve their intentions
Efficiency – reducing the time taken and the incidence of user errors
Satisfaction – offering an enjoyable experience to users
6 ISO Standard 9241-110 ergonomics of human-system interaction – Part 110: Dialogue principles
WP2-005.010.030-TR-001 Revision : E
2010-02-11 Page 37 of 48
The benefits of considering human factors integration [that is, engineering the usability of the
human-machine interface] are realised through:
Increased availability
Reduced training requirements
Reduced operating costs by minimising human error and operator-related accidents
14.3 Way Forward
It is not foreseen that HFE will play a significant role in early stages of PrepSKA. However, during this
period the time must be utilised to understand the role of HFE better and to plan the extent and
depth that HFE will be utilised on the SKA project.
HFE will most definitely play a role during the subsequent phases of the project when, for example,
operator interfaces, maintainer interfaces and operator centres are being designed and developed.
The following should be investigated and considered for application within the design processes for
PrepSKA WP2:
Purchase of consulting services from a company that has experience in usability engineering
Reference to, adoption of, and testing against generic guidelines, such as
Usability style guides7
Usability heuristics and principles8 9 10
Usability texts11 12 13
Usability patterns14
7 Benson et al.: Gnome Human Interface Guidelines 2.0” Gnome Usability Project; 2004
8 Neilsen J., Mack R.: (eds.): “Usability Inspection Methods”; John Wiley & Sons, New York; 1994
9 Tognazzini B.: “First Principles of Interaction Design”; http://www.asktog.com/basics/firstPrinciples.html
accessed 2010-01-29
10 Schneiderman B.: “Designing the User Interface: Strategies for Effective Human-Computer Interaction”;
Addison-Wesley, Reading, MA; 1998
11 Brown, C.: “Human-Computer Interface Design Guidelines”; Ablex Publishing, New Jersey; 1989
12 Mayhew, D.: “Software User Interface Design”; Prentice Hall, New Jersey; 1992
13 Smith, S., Mosier, J.: “Guidelines for Designing User Interface Software”; The MITRE Corporation; 1986
14 Mahemoff, M, Hussey, A.: “Patterns for Designing Safety-Critical Interactive Systems”; Technical Report No.
99-23 Software Verification Research Centre; 1999
WP2-005.010.030-TR-001 Revision : E
2010-02-11 Page 38 of 48
International standards for user interfaces such as ISO 9241-110
Reference to, adoption of, and testing against guidelines focused on HMI for safety aspects:
Leveson’s guidelines for HMI for safety15
Guidelines for safety-critical industries16
15 Testability and Fault Diagnosis Requirements
15.1 Motivation
The SKA is a large complex system. Besides the huge number of components, it will consist of a
diverse set of electronic, mechanical, and software systems that must operate in concert.
Additionally, it will be built incrementally over a prolonged period, thus new equipment must
integrate smoothly with existing equipment. Because of its cost the system must have a high
availability, as the cost of down time will be high. In a system as large as the SKA mean times
between failures need to be long, however, failures will be common with such a large system, so the
mean time to repair must be short, especially for critical failures which impact the system
significantly.
Testing will play a key role in ensuring the SKA operates as effectively as possible. Testability is a
measure of how well a test exposes a fault (fault detection), and how well it can be isolated (or
diagnosed). To be effective both detection and diagnosis have to be addressed early in the design of
the SKA. Test requirements need to be clear and test plans need to address all aspects of the system,
from low-level components to high-level sub-system throughout their life-cycle (development,
manufacturing, in-service, and service and repair phases). These testability requirements are
outlined in the remainder of this section.
15.2 Overall Testability Principles and Requirements
Testability requirements need to be considered for all modules17 used in the system. To be
effective, tests needs to be both controllable and observable. That is a test needs to be able to
affect a specific part, or node, in a module and the result should be directly observable so either
correct operation of the node under test can be readily established, or a fault can be readily isolated
and diagnosed. Where feasible, test infrastructure should be built into modules. Such “built in test”
capabilities permits stand-alone testing and in-system testing. Test sets should be thorough and
15
Leveson, N.: Safeware: “System Safety and Computers”, Addison-Wesley; 1995
16 O’Hara et al.: “NUREG-0700 Human-System Interface Design Review Guidelines, Rev 2”; US Nuclear
Regulatory Commission; 2002
17 Module here is used very generally. A module may be mechanical, electronic, or software. It may be an IC, a
board, an assembly or sub-system, an antenna drive, or software module or program.
WP2-005.010.030-TR-001 Revision : E
2010-02-11 Page 39 of 48
exercise all aspects of the module so that a maximum number of possible faults can be detected and
exposed, and correct operation determined with high confidence.
15.3 Testability Requirements
15.3.1 Controllability
A test stimulus should affect a specific node or aspect of a module as directly as is practical.
Dependency on other functions should be minimized, so that a fault can be attributed to a node as
directly as possible.
15.3.2 Observability
The node under test should observed as directly as practical, so that a fault can be attributed to a
node as directly as possible.
15.3.3 Granularity
Testing principles and requirements need to be considered and integrated consistently with all levels
of the system hierarchy (ie units, modules, boards, sub-assemblies, sub-systems and system.)
15.3.4 Fault Model
To the extent practical, a fault model of a module should be developed so that the model can be
used to determine fault behaviours.
15.3.5 Fault Coverage
Test sequences should have a high fault grade and exercise all aspects of a module so that a high
percentage of faults will be detected and correct operation established with high confidence and a
minimum of false positives.
15.3.6 Hierarchical and Modular Testing
Test sequences should be constructed to verify operation of system modules and sub-modules in a
hierarchical way. Tests should be modular so that they independently stimulate a particular
component, or node, in a module. Test results should be observable so that faults can be isolated to
a specific device, module, assembly, or sub-system.
15.3.7 Functional Testing
Test sequences should be developed to fully exercise the functional capabilities of the module so its
correct operation can be established.
15.3.8 Interconnect and Interface Testability Requirements
Interconnect and interfaces should be testable to facilitate manufacturing test and fault diagnosis at
module boundaries. Digital modules should conform to JTAG boundary scan standards.
WP2-005.010.030-TR-001 Revision : E
2010-02-11 Page 40 of 48
15.3.9 Testability Design Requirements
Testability requirements shall be addressed in all SKA development phases and included in concept,
preliminary and detailed design reports. The following sub-sections outlines specific requirements.
15.3.9.1 Design Test and Verification Plans
Design documents should include test plans that verify a design that meets SKA performance
requirements and specifications. Designs relying on undocumented capabilities of a component
must develop specific test plans or measures to verify the capability of the component.
15.3.9.2 Manufacturing Test Plan
Design documents should include test plans that verify correct manufacturing and assembly of
modules. The plans should minimally test interfaces and interconnects and, where practical, test
modules for overall functionality.
15.3.9.3 Factory Acceptance Test (FAT) Plan
Design documents should include test plans that verify correct assembly of modules into a sub-
system, or system. The plans should include tests that thoroughly test functionality over the entire
performance specification.
15.3.9.4 Site Acceptance Test (SAT) Plan
Design documents should include test plans to verify the correct operation of a sub-system, or
system at the SKA site. The plans should include tests that thoroughly examine functionality as well
as interconnects and interfaces relied on by other components in the SKA system. The plans should
also take into account the SKA site integration, test and repair facilities and its requirements.
15.3.9.5 In-Service Test Plan
Design documents should include test plans used to verify correctness of a sub-system, while it is
operating or as part of the SKA system. The plans should include tests that thoroughly test
functionality, as well as, interconnect and interfaces relied on by other components in the SKA
system. Diagnosis requirements should also be addressed so that mean time to repair and
operational requirements can be met.
15.3.9.6 Service and Repair Test Plan
Design documents should include test plans used to identify and diagnose faults in a module, as well
as test procedures for calibration. The plans should include tests that also thoroughly test
functionality as well as interconnects and interfaces relied on by other components in the SKA
system.
15.4 Definitions
a) Boundary Scan: Test interconnect and input and output interfaces
WP2-005.010.030-TR-001 Revision : E
2010-02-11 Page 41 of 48
b) Built in Self-Test: Ability of a device to apply test stimulus, observe a fault and determine if it
is working correctly.
c) Controlablity: Ability to set an internal node within a device to a known value.
d) Design Test and Verification: Tests used to verify the design meets requirements and
specifications.
e) Diagnosis: The process of isolating a fault to a device or node.
f) Engineering Test Requirements: Tests used to verify the design meets requirements and
specifications.
g) Factory Acceptance Test Requirements: Tests used to verify a module is fully functional and
ready integration with other equipment (nominally at the site).
h) Fault: Improper operation of a device
i) Fault Grade: Percentage of faults that will be detected by a test or test sequence.
j) Fault Model: A model of device that can be used to determine fault behaviours.
k) Field Service Test Requirements: Tests required to diagnose and isolate a fault, within mean
time to repair requirements.
l) Functional Test: Verify correct operation of a device.
m) Granularity: Level of test. Chip, board, crate, rack, sub-system, system test.
n) In-Service Test: Tests required to verify correct operation of a module in the SKA system.
o) Manufacturing Test: Testing performed to verify correct manufacturing (inter-connect)
p) Manufacturing Test Requirements: Tests required to verify correct manufacturing assembly,
primarily inter-connects.
q) Modular Testing: Ability to independently stimulate and observe test results so that faults
can be isolated to a specific device, module, assembly, or sub-system.
r) Module: Used here as a general term for a testable mechanical, electronic, or software
entity. It may be an IC, a board, an assembly or sub-system, or a antenna drive, or software
module or program.
s) Observability: Ability to observe the effect of stimulus on a node. The node is directly
observable if the stimulus affects the node and the results are observable in a one to one
manner.
t) Parametric Test: A test that exercises a device over its performance range (voltage, current
and speed).
WP2-005.010.030-TR-001 Revision : E
2010-02-11 Page 42 of 48
u) Service and Repair Test: Tests used to determine a module is functional, as well as, aid in
fault diagnosis and calibration. Module should be capable of running in a stand-alone mode
(e.g. in the on-site integration, test and repair facility) with a test fixture so that it can be
operated independently of other system modules.
v) Site Acceptance Test: Tests used to verify a module is fully functional and ready integration
with other equipment (nominally at the site).
w) SKA site integration, test and repair facility: Facility with appropriate test fixtures to ensure a
module is fully functional and will inter-operate with other system modules. The facility also
has equipment for repair and maintenance of modules.
x) Testability: Ability to stimulate and exercise a device over its specification.
y) Test Grading: The process of fault simulating a test to determine its effectiveness at
detecting a fault.
z) Undetectable Fault: A fault that cannot be detected by a test, likely because the node is
uncontrollable, or unobservable.
aa) Unpredictable fault: A fault that causes a node to be indeterminate, thereby making
detection probabilistic.
bb) Verification [18]: System verification addresses whether the system, its elements, and its
interfaces satisfy their requirements. Verification ensures the conformance to those
requirements; in other words that “you built it right.”
cc) Validation [18]: System validation confirms that the system, as built (or as it will be built),
satisfies the stakeholders’ stated needs. Validation ensures the requirements and the system
implementation provide the right solution to the customer’s problem. In other words, “you
built the right thing.”
16 Configuration and Change Management
16.1 What is Configuration Management?
Configuration Management was first developed by the United States Department of Defence in the
1950s as a technical management discipline and is a field of management that focuses on
establishing and maintaining consistency of a product's functional and physical attributes. This is of
critical importance for “as-built” definition and for support functions over the life of a complex
system [22].
It is the process of creating and maintaining an up-to-date record of all the components of the
system, including related documentation and has four elements:
1) Configuration Identification
a) It is the process of identifying the attributes that define every aspect of a configuration item.
WP2-005.010.030-TR-001 Revision : E
2010-02-11 Page 43 of 48
b) A configuration item is a product (hardware and/or software) that has an end-user purpose.
c) These attributes are recorded in configuration documentation and base lined.
d) Base lining an attribute forces formal configuration change control processes to be effected
in the event that these attributes are changed.
2) Configuration Change Control (or Change Management)
a) Is a set of processes and approval stages required to change a configuration item's attributes
and to re-baseline them.
3) Configuration Status Accounting
a) Is the ability to record and report on the configuration baselines associated with each
configuration item at any moment of time.
4) Configuration Verification and Auditing
a) Audits are broken into functional and physical configuration audits.
b) They occur either at delivery or at the moment of effecting the change.
c) A functional configuration audit ensures that functional and performance attributes of a
configuration item are achieved.
d) A physical configuration audit ensures that a configuration item is installed in accordance
with the requirements of its detailed design documentation.
16.2 Why is it Important
During the life cycle of a project many artefacts are created and will eventually have to be operated
and supported. These artefacts include documents, drawings, software, mechanical equipment,
electronic equipment, data, PC boards, facilities, and many more. For a large, complex and
distributed project such as the SKA the challenge to keep control of the status and changes to all of
these artefacts as the project moves through its various life cycle phases is quite daunting.
Configuration management forms the backbone of the process to establish and maintain this
control.
Its purpose is to show what makes up the system and illustrate the physical locations and links
between each item, known as configuration items (CI). The extra value provided is the rich source of
support information it provides consistently to all interested parties.
Further guidance can be found in Section 6.8 of [14].
16.3 Way Forward
It is important to plan at what level of the organisation Configuration Management System (CMS) is
to be applied, i.e. only for a specific project, all projects or the whole organisation (as shown
WP2-005.010.030-TR-001 Revision : E
2010-02-11 Page 44 of 48
schematically below). Within the SKA context the various work packages can be viewed as the
projects depicted in the schematic.
Company
Corporate
GovernanceProjects
Policies Strategy HR Marketing Proj 1 Proj 2 Proj n
HardwareSystem
EngineeringSupport
Assembly
A
Assembly
B
Assembly
C
LRU 1 LRU 2 LRU 3
Component 1 Component 2 Component 3 Component 4
PDR
CDR
Specifications
The roll out and inclusion of all the work packages in the configuration management system will
have to be investigated. Until such time the efforts will focus on WP2.
As part of configuration management the following will be addressed:
Item Numbering Philosophy
o It is important to decide on an item numbering scheme and apply it consistently. It
must be as short as possible to allow sufficient unique identification. In this regard a
guideline has already been developed and presented as part of the system CoDR.
Document Type Philosophy
o It is important to decide on a document type scheme and apply it consistently. In
this regard a guideline has already been developed and presented as part of the
system CoDR.
Change Procedure
o It is important to decide on a change management process and apply it consistently.
This procedure will be developed by the SPDO system engineering within the very
short term.
Configuration Management System (CMS) Tools
o It is proposed that an interim CMS tool/database be utilised to provide the very
basic functionality up to the end of PrepSKA, where after a more formal CMS tool
WP2-005.010.030-TR-001 Revision : E
2010-02-11 Page 45 of 48
and database must be considered to achieve the goals of configuration
management. This system will be set up and be maintained by the SPDO.
Roll out and utilisation
o For configuration management to succeed it will require buy in and disciplined
contributions from each and every individual/organisation within WP2. A single
point of contact which will be responsible for administering the CMS within the
SPDO will be identified and communicated.
17 Data Packs
17.1 What are Data Packs?
Data Packs can be defined as the set of data (drawings, procedures, structures) of a
System/Element/Subsystem/Assembly/Sub-assembly/Component/Part that describes how the item
was designed, manufactured, qualified, tested and allows for ease of maintenance by personnel not
involved in the development of the subject. Not only are data packs crucial to provide data for new
personnel assigned to the project to understand the attributes of a subject, it must reflect the
physical and functional configuration of the particular item at any point in time. For example, it
should be possible to transfer a production data pack from one manufacturer to the next and enable
the new manufacturer to build and test exactly the same item as before. This is, of course, very
difficult to achieve and the work and time to be spent on data packs should not be underestimated.
To ensure integrity and real time up to date information of the data pack for use by all, configuration
management principles must be applied constantly and consistently.
Data packs typically consist of the following data;
1) Design Data; Specifications, Architecture Description Documents, Interface definitions,
Qualification Procedures and Results, Acceptance Test Procedures and Results.
2) Manufacturing Data; Identification of items grouped to provide Physical Breakdown Structures,
Assembly Drawings, Manufacturing Drawings, Parts Lists, Data Sheets for procured items,
Supplier Data, Responsibilities etc.
3) Support Data; Technical Manuals, Training Courses, Support Management Procedures/Plans,
etc.
17.2 Way Forward
From the CoDR to the end of PrepSKA, the following should be applicable
1) Establish the Interim Configuration System (as described in Section 16)
2) Develop System Structures
WP2-005.010.030-TR-001 Revision : E
2010-02-11 Page 46 of 48
a) Develop SKA structures top down in accordance with the system hierarchy from level 7 to
level 4.
b) Develop the level 3 structures where available for review at the PDR.
3) Link developed data to system structures
a) Link design data to applicable structures/items
b) Where available, link manufacturing data to items.
18 Interface Management
18.1 Introduction
Within a system context even the smallest or what would appear to be the most irrelevant piece of
equipment will have interfaces which, if not managed, may result in rework and may even have an
impact on system performance as a whole. Identification and management of interfaces from early
on in the SKA project will therefore be one of the primary focus areas within the system engineering
effort.
Interfaces come in many forms and shapes and include electrical (power), signal (data) and
mechanical interfaces. For each of these interfaces documentation will eventually be developed
describing the interface in enough detail to ensure that all the parties utilising the interface have a
clear understanding of the interface and can implement and test the interface without actual
integration of the items.
Well written and managed interface documentation will prevent expensive reworks and will support
quick and effective integration of items.
18.2 Current Situation
The high level functional interfaces have been identified and described in [23]. As an example the
level 5 functional interfaces are shown in the diagram below.
Note that to clearly distinguish between interfaces they have been numbered, that interfaces are
unidirectional or bidirectional and that there are more than one stakeholder in each interface.
Expanding the context another level down will result in a significant increase in the number of
interfaces to be managed. For a system as complex as the SKA the number of interfaces will most
probably run into the tens of thousands.
WP2-005.010.030-TR-001 Revision : E
2010-02-11 Page 47 of 48
Reception
Monitoring
&
Controling
Signal
Processing
(SP)
Networking
Software &
Computing
(S&C)
Sync
&
Timing
Power
Generation
Cooling
E.1 RF Signal
E.11 Weather
E.4 Timing
Reference
E.9 Cooling
E.12 Power
E.7 Processed
Data
E.2 RFI
I.1.8 Receptor
Environment I.1.13 Receptor
Network Interfaces
I.1.10 Receptor
cooling
I.1.12 Receptor
Power
I.2.10 SP cooling I.2.8 SP Environment
I.2.12 SP Power
I.2.13 SP Network
Interfaces
I.3.13 S&C Network
Interfaces
I.5.13 M & C Network
Interfaces
I.3.8 S&C
Environment
I.3.10 S&C
Cooling
I.4.8 S&T
Environment
I.4.12 S&T Power
I.3.12 S&C Power
I.4.10 S&T
Cooling
I.6.13 Power
M&C
Interfaces
I.7.13 Cooling
M&C
Interfaces
I.5.12 M&C
Power
I.5.10 M&C
Cooling
I.5.8 M&C
Environment
I.6.8 Power
EnvironmentI.6.10 Power Cooling
I.7.8 Cooling
Environment
I.7.12 Cooling Power
I.1.10 tho’ I.8.10
Cooling
I.1.12 thro’ I.8.12
Power
F.1
F.2
F.3
F.4
F.5
F.6
F.7
F.8
E.3 Control
E.6 Monitoring
I.4.13 S&T Network
InterfacesI.8.10 Network
Cooling
I.8.12 Network Power
I.8.8 Network
Environment
Figure 3: Level 5 functions and functional interfaces.
18.3 Way Forward
The high level functional interfaces have been identified and will be used as the starting point for
management of interfaces. It is not foreseen that the interfaces will be specified in depth but high
level description will have to be developed to ensure that all stakeholders understand the function
and intention of the interface. To facilitate this process each interface will be allocated a number
and an owner. The owner is not a person but rather a function or a piece of equipment. Attached to
this function or equipment there will inevitably be a person that will take the responsibility for the
development of the interface in consultation with the other stakeholders. The owner will be
responsible to:
1) Identify the stakeholders
2) Identify the function and purpose of the interface
3) Develop the interface description
4) Get agreement from the stakeholders on the interface definition.
No clear rule exists for the identification of the owner. It can be as a result of contractual
boundaries, it can be voluntary, it can be an entity that wants to specify/describe a required service
or it can be the entity that provides the service. For example, a piece of RF equipment that needs to
WP2-005.010.030-TR-001 Revision : E
2010-02-11 Page 48 of 48
be cooled can specify the characteristics of the coolant to be delivered. On the other hand the
supplier of the coolant can specify what the characteristics of the coolant is which will imply that the
RF designer will have to adapt and lay out the RF equipment to utilise the service being supplied.
Therefore, as a general rule it can be stated that if there are no limitations to the service, the owner
of the interface is the entity that requires a service. However, if the service to be delivered has
limitations the owner will be the service provider. In the SKA context there will, of course, be a
mixture of these situations and the owners will have to be identified using good judgement and
common sense.
The interface management of the interfaces at the level indicated in the diagram above will typically
lie with the SPDO system engineer. The interfaces one level down will be the responsibility of the
domain specialists and other verification program system/project engineers.
During the PrepSKA phase the SPDO will be responsible to manage and maintain an interface
register in which information such as the interface number, the owner, the stakeholders, the
location current interface description document and other configuration management information
will be recorded.
As the project moves forward the interface detail will increase until such time that the interface
descriptions are very detailed containing information such as connector details, pin layouts, wiring
diagrams, data structures etc. Along with these changes in interface detail the management of the
interfaces will also have to become more formal with the utilisation of engineering change
proposals.
The golden rule of interface management is that no interface will be changed without the knowledge
and agreement of ALL the stakeholders of the interface. It will not only be the responsibility of the
owner to obtain the agreement but to ensure that all stakeholders are involved and are aware of
changes to the interfaces.
19 Acknowledgements
Various people contributed to the writing and/or provided supporting material. They are:
Billy Adams (SPDO) (Sections 4, 5, 7, 11)
Duncan Hall (SPDO) (Sections 3, 6, 7, 14)
Neil Roddis (SPDO) (Section 5)
Gary Hovey (DRAO) (Section 15)
D. Liebenberg (NRF) (Sections 8, 9, 16, 17, 18)
J. Jonas (NRF) (Section 7) Also a word of thanks to all the reviewers.
----------0-----------
