SKA LOGISTIC ENGINEERING MANAGEMENT PLAN

SKA LOGISTIC ENGINEERING MANAGEMENT PLAN Document number... WP2-005.010.030-MP-002 Revision... C Author... D Liebenberg Date... 2010-01-18 Status... Approved for release Name Designation Affiliation Date Signature Submitted by: Darrel Liebenberg Logistic Engineer NRF SA 2010-02-01 pp. Approved for release as part of SKA System CoDR documents: P.E. Dewdney Project Engineer SPDO 2010-02-01

DOCUMENT HISTORY Revision Date Of Issue Engineering Change Number Comments A 11 Nov 09-1st draft release for KC review B 15 Jan 10-1st draft release for SEDG review C 18 Jan 10 - Minor grammar changes for readability TBD Future Issue - Update as a result of System Engineering CoDR TBD Future Issue - Update for System Engineering SRR TBD Future Issue - Update as a result of System Engineering SRR TBD Future Issue - Update for Project Management PDR TBD Future Issue - Update as a result of Project Management PDR DOCUMENT SOFTWARE Package Version Filename Wordprocessor MsWord Word 2007 WP2-005.010.030-MP-002-C_LEMP COMPANY DETAILS Name Physical/Postal Address SKA Program Development Office Jodrell Bank Centre for Astrophysics Alan Turing Building The University of Manchester Oxford Road Manchester, UK M13 9PL Fax +44 (0)161 275 4049 Website www.skatelescope.org 2010-01-18 Page 2 of 49

TABLE OF CONTENTS 1 INTRODUCTION... 7 1.1 Background... 7 1.2 Why Logistical Engineering?... 7 1.3 Document Overview... 8 1.4 References... 9 1.4.1 Applicable Documents... 9 1.4.2 Reference Documents... 9 2 SKA SYSTEM DEFINITION... 10 2.1 SKA System Hierarchy... 10 2.2 General Background... 11 2.3 System Breakdown... 13 2.4 System Operational Factors... 13 2.4.1 Operational State 1 Operational... 14 2.4.2 Operational State 2 Pre-Operation Testing... 14 2.4.3 Operational State 3 Maintenance... 15 2.4.4 Operational State 4 Scheduled Maintenance... 15 2.4.5 Operational State 5 Upgrades... 15 2.4.6 SKA System Annual Operating Requirement (AOR)... 16 2.5 Level 7 System RAM Requirements... 16 2.5.1 Level 7 Critical RAM Requirements... 17 2.5.2 Level 7 Inherent RAM Requirements... 17 2.6 Level 6 Element RAM Requirements... 18 2.6.1 Level 6 Critical RAM Requirements... 18 2.6.2 Level 6 Inherent RAM Requirements... 18 3 SKA SYSTEM SUPPORT CONCEPT... 19 3.1 Manpower & Personnel... 20 3.1.1 Observers... 20 3.1.2 Operators... 20 3.1.3 Maintainers... 21 3.2 Maintenance... 22 3.2.1 Organisational Level (O-Level or OLM)... 22 3.2.2 Intermediate Level (I-Level or ILM)... 22 3.2.3 Deport Level (D-Level or DLM)... 22 3.2.4 Supplier Level (S-Level or SLM)... 23 3.3 Training... 23 3.3.1 Observer Training (Operation)... 23 3.3.2 Operator Training (Operation)... 24 3.3.3 Maintainer Training (Maintenance)... 24 3.4 Support Publications... 24 2010-01-18 Page 3 of 49

3.5 Supply Support... 25 3.5.1 O-Level Supply Support... 25 3.5.2 I-Level Supply Support... 25 3.5.3 D-Level Supply Support... 25 3.5.4 S-Level Supply Support... 25 3.6 Packaging, Handling, Storage And Transportation (PHS&T)... 26 3.7 Support & Test Equipment... 26 3.8 Support Facilities... 27 3.8.1 O-Level Facilities... 27 3.8.2 I-Level Facilities... 27 3.8.3 D-Level Facilities... 27 3.8.4 S-Level Facilities... 27 3.9 Support Data... 28 3.10 Product Supplier Support (PSS) Concept... 28 4 SUPPORT CONCEPT CHALLENGES & STRATEGIES... 29 5 SKA LOGISTIC ENGINEERING SCOPE OF WORK... 33 5.1 User System (L7) Logistic Engineering Scope of Work... 34 5.1.1 Logistic Engineering Planning... 34 5.1.2 Logistical Engineering Standards & Procedures... 34 5.1.3 Logistical Engineering Support Libraries... 34 5.1.4 Logistical Support Analysis Data Evaluation... 34 5.1.5 Logistical Support Analysis Data Integration... 34 5.1.6 Logistical Support Analysis Data Simulation & Modelling... 35 5.1.7 LSA Database to ILS Database Transition... 35 5.1.8 Logistical Support Management & RAM Measurement... 36 5.2 System (L6) and Lower Level Logistic Engineering Scope of Work... 37 5.2.1 Logistical Support Analysis... 38 5.2.1.1 Establish Product Breakdown Structure (PBS)... 38 5.2.1.2 Determine Reliability Figures... 39 5.2.1.3 Conduct Failure Modes, Effects and Criticality Analysis (FMECA)... 39 5.2.1.4 Identify Maintenance Tasks... 41 5.2.1.5 Conduct Detail Task and Resource Analysis... 41 5.2.1.6 Generate Consolidated LSA Report... 41 5.2.2 Design Influence... 42 5.2.2.1 Design Influence Process... 42 5.2.2.2 Logistic Factors... 42 5.2.3 Training & Publication Resource Establishment... 43 5.2.3.1 Training Development... 43 5.2.3.2 Publication Development... 44 5.2.4 Support Resource Establishment... 45 2010-01-18 Page 4 of 49

5.2.5 Logistical System Performance Verification... 45 6 EXPECTED TIMEFRAME... 46 6.1 Logistical Engineering Planning... 46 6.2 Logistical Engineering Standards & Procedures And Support Libraries... 46 6.3 Logistical Support Analysis & Design Influence... 46 6.4 Logistic Support Analysis Data Evaluation And Integration... 46 6.5 Logistic Support Analysis Data Simulation & Modelling... 46 6.6 Support Resource Establishment... 47 6.7 Logistical System Performance Verification... 47 6.8 LSA Database to ILS Database Transition... 47 6.9 Logistical Support Management & RAM Measurement... 47 APPENDICES Appendix A Expected Timeframe... 48 LIST OF TABLES Table 1 SKA System Hierarchy... 10 Table 2 - SKA System Annual Time vs Operational States... 16 Table 3 - SKA System Annual Operating Requirement... 16 Table 4 - SKA Level 6 Critical RAM Requirements... 18 Table 5 - SKA Level 6 Inherent RAM Requirements... 18 Table 6 - Support Concept Challenges & Strategies... 29 Table 7 Criticality Analysis Matrix... 40 LIST OF FIGURES Figure 1 SKA Concept... 11 Figure 2 South African Core Station and Outer Stations... 12 Figure 3 Australian Core Station and Outer Stations... 12 Figure 4 SKA System High Level Block Diagram... 13 Figure 5 SKA System Operational Model... 14 Figure 6 - SKA Logistic Engineering Scope of Work... 33 Figure 7 - LSA Database to ILS Database Transition... 35 Figure 8 - SKA RAM Performance Measurement... 36 Figure 9 - System (L6) To Sub-Assembly (L2) Logistic Engineering... 37 Figure 10 - Logistical Support Analysis Process... 38 Figure 11 - Training & Publication Resource Establishment Process... 43 Figure 12 - Support Resources Establishment Process... 45 Figure 13 - Logistical System Performance Verification Process... 45 2010-01-18 Page 5 of 49

LIST OF ABREVIATIONS AA Aperture Array MTTR Mean Time To Repair A c Critical Availability MTTR c Critical MTTR A i Inherent Availability MTTR i Inherent MTTR AOR Annual Operating Requirement nfp nth Framework Programme Assy Assembly OEM Original Equipment Manufacturer BOM Bill Of Material O-Level Organisational Level c Critical OLM Organisational Level Maintenance CA Criticality Analysis OTLR Operator Task List Report CDR Critical Design Review PBS Physical Breakdown Structure CoDR Concept Design Review PDR Preliminary Design Review DEF-STAN Defense Standard PHS&T Packaging, Handling, Storage and Transportation D-Level Deport Level PPPM Preparation, Preservation, Packing and Marking DLM Depot Level Maintenance PPPR Personnel Performance Profile Report EU European PrepSKA Preparatory phase for the SKA FAT Factory Acceptance Tests PSS Product Supplier Support FMEA Failure Modes and Effects Analysis PSU Power Supply Unit FMECA Failure Modes, Effects and Criticality Analysis RAM Reliability, Availability, Maintainability FRACAS Failure Reporting and Corrective Action System Rel c Critical Reliability GHz Giga Hertz Rel i Inherent Reliability HQ Head Quarters RF Radio Frequency Hrs Hours RFI Radio Frequency Interference i Inherent S&TE Support and Test Equipment I-Level Intermediate Level SAT Site Acceptance Test ILM Intermediate Level Maintenance SEDG System Engineering Design Group ILOR Intended Learning Outcomes Report SEMP System Engineering Management Plan ILS Integrated Logistic Support SKA Square Kilometre Array Km Kilometer SKADS SKA Design Studies LEMP Logistic Engineering Management Plan S-Level Supplier Level LNA Low Noise Amplifier SLM Supplier Level Maintenance LOFAR Low Frequency Array SPDO SKA Program Development Office LRU Line Replaceable Unit SRU Shop Replaceable Unit LSA Logistic Support Analysis STaN Signal Transport & Networks MHz Mega Hertz TRR Test Readiness Review MIL-STD Military Standard TSR Training Survey Report MSCDR Media Selection & Curriculum Development Report TTLR Technical Task List Report MSP Maintenance & Support Plan USA United States of America MTBCF Mean Time Between Critical Failures VOIP Voice Over Internet Protocol MTBF Mean Time Between Failures 2010-01-18 Page 6 of 49

1 INTRODUCTION 1.1 BACKGROUND This initial Logistical Engineering Management Plan (LEMP) was created as a result of Reference Document [4]. It intends to; 1. Contribute towards the coherent big picture of the SKA System and identify challenges and strategies from a support point of view. 2. Provide guidance to future Logistical activities. Subsequent to the CoDR, this initial LEMP shall have various updates as information becomes available until it is finalised by the Project Management PDR. 1.2 WHY LOGISTICAL ENGINEERING? Logistic Support & Resources (Maintenance, Spare Parts, Training, etc.) are expenses associated with a System over its useful life. the biggest In order to moderate such expenses, the goals of the Logistic Engineering effort are to; 1. Have the Logistical Support considerations influence the design where possible. 2. Identify and develop Logistical Support Requirements that are related to the system and are supportive of readiness objectives of the system. 3. Acquire the necessary Logistical Resources. 4. Provide the required Logistical Support at the minimum cost. Thus in summary; Design for Support, Design the Support, & Support the Design What is of importance is that all Logistical Development efforts are aligned and are executed to the same requirements and standards to allow support optimisation at system level. Thus it is imperative that a Logistical Engineering Management Plan (LEMP) be generated defining the Logistical Support Concept and providing guidance on the Logistical Engineering tasks to be executed, to realise an optimal Support System. Please note that this LEMP only addresses Logistic Support issues and not System Engineering issues such as system/product enhancements to hardware or software. Further, it does not address Management issues, which although important,fall outside the scope of this document. 2010-01-18 Page 7 of 49

1.3 DOCUMENT OVERVIEW This document aims to answer the following questions; 1. What must be supported? Section 1 - Introduction. This section describes the background of the document and provides a brief statement why Logistical Engineering is required and identifies referenced documents. Section 2 - SKA System Definition. This section provides a high level description of the SKA System in terms of its initial hierarchy, physical breakdown and expected operation and Reliability, Availability & Maintainability factors (RAM). 2. How could the SKA system be supported? Section 3 - SKA System Support Concept. This section describes the expected Support Concepts in terms of ten Logistic Elements. Section 4 - SKA System Support Concept Challenges & Strategies. This section identifies Challenges & Strategies of the Support Concepts. 3. How would the Support be developed? Section 5 SKA Logistical Engineering Scope of Work. This section describes the tasks to be executed to realise the Support Concept in order to support the SKA System as installed. 4. What is the timeframe? Section 6 - Expected Timeframe. This section provides a high level estimation for Logistical Engineering tasks in relation to System Engineering s view of Project Phases and Reviews. 2010-01-18 Page 8 of 49

1.4 REFERENCES 1.4.1 Applicable Documents The following documents are applicable to the extent stated herein. In the event of conflict between the contents of the applicable documents and this document, the applicable documents shall take precedence. [1] System Engineering Management Plan K Cloete, WP2-005.010.030-MP-001, Rev C, 14 Apr 09. [2] PREPSKA System Level Work Breakdown Structure K Cloete, WP2-005.010.010-WBS-001, Rev A, 10 Aug 09. [3] The SKA Design Reference Mission SKA Science Working Group, Rev 0.4. [4] Scope of SKA System CoDR K Cloete, WP-005.020.010-R-001, Rev B, 23 Jun 09. 1.4.2 Reference Documents The following documents are referenced in this document. In the event of conflict between the contents of the referenced documents and this document, this document shall take precedence: [5] Memo 102, Lessons Learned From Other Large Scientific Facilities SKA Operations Working Group, Jun 08. [6] Memo 84, Report of the SKA Operations Working Group K. Kellermann et al, Oct 06. [7] DOD Requirements For A Logistic Support Analysis Record MIL-STD-1388-2B [8] Procedures for performing a Failure Mode, Effects and Criticality Analysis MIL-STD-1629A 2010-01-18 Page 9 of 49

2 SKA SYSTEM DEFINITION 2.1 SKA SYSTEM HIERARCHY As per Reference Document [1], the SKA project will be divided into several levels (layers). Within each of the levels there are various building blocks and each of these are linked to higher and lower level building blocks. For example; the eventual SKA User System (level 7) consists of the telescope, people and facility systems at level 6. In turn the telescope will consist of the Signal Transport and Networks (STaN), dish array, outlying stations, sparse aperture array, dense aperture array, power, and site infrastructure elements at level 5. The hierarchy is a first step in the establishment of the system view of the project and is intended to provide a clear and coherent view on the scope and composition of each of the building blocks and of the system as a whole. The hierarchy will also facilitate better communication and understanding and aligns terminology throughout. It provides a clear view of where requirements for each of the blocks originate and how the flow down of the process will be achieved. Table 1 SKA System Hierarchy Level Description Definition 7 SKA User System Consisting of three Level 6 Systems 6 Telescope System People System Facility System 5 Elements 4 Sub-Systems 3 Assemblies 2 Sub-Assemblies 1 Components Consisting of Elements such as Dish Array, Sparse AA Array, Dense AA Array, Computing & Software, STaN, Power and Infrastructure Managers, Scientists, Engineers, Observers, Operators, Maintainers Core Site, Central Site, Off Site & Regional Systems Elements are integrated Sub-Systems, examples are; Dish Array, Sparse AA Array, Dense AA Array, Computing & Software, STaN, Power and Infrastructure, Core Site, Central Site, Off Site & Regional Systems. Subsystems are integrated Assemblies and are complex and mostly large, examples are; Receptors, Corrrelators, Support Centres, Visitor Centres, Operations Centres & Engineering Centres. Assemblies are integrated Sub-Assemblies, examples are; Dish Assy, Feed Assy, Beam Former Assy, Foundation Assy and Office Assy. Sub-Assemblies are integrated Components, examples are; Cryo Assy, Receiver Assy & LNA Assy and are typically a Line Replaceable Unit (LRU) Individual parts that make up Sub-Assemblies. These will typically be Shop Replaceable Units (SRU), examples are PSU s, Couplers, Motors etc. 0 Parts Examples are; Transformers, Bearings, Connectors etc. 2010-01-18 Page 10 of 49

2.2 GENERAL BACKGROUND The SKA will be a revolutionary radio telescope. As the SKA will open new windows to the Universe, discoveries of many new phenomena can be expected. Based on what today s scientists can imagine as transformational science in astrophysics and fundamental physics, five projects have been identified by the radio astronomy community as being the key science drivers for the SKA: Cradle of Life discoveries, Probing the Dark Ages, The origin and evolution of Cosmic Magnetism, Strong field tests of gravity using pulsars and black holes, and Galaxy evolution, cosmology and dark energy. The SKA will be an international aperture synthesis radio telescope, consisting of a large number of receptors with a total collecting area of around one square kilometre. The signals will be digitally combined to simulate a telescope having a diameter of several 1000 km. Within the current concept the SKA receptors will consist of a combination of dishes with wide band single pixel feeds, dishes with phased array feeds, dense aperture arrays and sparse aperture arrays combined in three different cores as shown in Figure 1. Figure 1 SKA Concept 2010-01-18 Page 11 of 49

Two radio-quiet sites for the core stations have been selected: a. South Africa (with outer stations in Namibia, Botswana, Mozambique, Kenya, Ghana, Madagascar and Mauritius) Figure 2 South African Core Station and Outer Stations b. Western Australia (with outer stations across Australia and in New Zealand) Figure 3 Australian Core Station and Outer Stations The decision on the site is planned for 2011/2012. 2010-01-18 Page 12 of 49

2.3 SYSTEM BREAKDOWN [To be refined with the next iteration of the LEMP] 2.4 SYSTEM OPERATIONAL FACTORS 1 Figure 4 SKA System High Level Block Diagram Reference Document [5] states the following; Balance between operations and maintenance: Efficient 24/7 operation of the SKA will require a careful balance between maintenance time and observing time. Well run radio telescopes, generally are able to use about 70 percent of the time for productive scientific observations, but technical personnel will use all the time that they can get for development, testing and maintenance of both hardware and software. Based on the above, the following Operational usage model is suggested; Maintenance and Upgrades are inherently part of any complex system and indeed part of the Telescope s operation. Of course maintenance and upgrades must allow for maximum science output by ensuring minimum downtime. The relationship between operations and maintenance and upgrades can be summarised as follows; 1 To be refined with the next iteration of the LEMP 2010-01-18 Page 13 of 49

Operational Capability WP2-005.010.030-MP-002 Ops State 1 Operational Duration 7 Days Ops State 2 Pre-Operation Test Critical Failure Immediate Response Non-Critical Failure Interval ±8 Days Ops State 3 Maintenance Duration 1 Day Interval 5 Weeks Ops State 4 Scheduled Maintenance Duration 3 Days Interval 24 Weeks Ops State 5 Upgrades Duration 3 Weeks Operational States 2.4.1 Operational State 1 Operational Figure 5 SKA System Operational Model The SKA System is fully operational and available for scientific/engineering observations for a period of 7 days or 168hrs. During Operational State 1 the highest RFI Control Levels shall be maintained. 2.4.2 Operational State 2 Pre-Operation Testing Before operations commence, a standard set of Pre-Operation Testing & Calibration will be performed to ensure System readiness. During this operational state the most stringent RFI Levels shall be maintained. 2010-01-18 Page 14 of 49

2.4.3 Operational State 3 Maintenance In the case of a critical failure, i.e. required observations are no longer possible; a corrective maintenance state will be implemented immediately to restore the System. In the case of a non-critical failure, i.e. required observations are possible but with degraded performance, a corrective maintenance state will be implemented upon completion of the Operational State 1 to restore the System. In this state minor Scheduled Maintenance can also be executed. During this Operational State the most stringent RFI Levels shall be maintained as far as possible. Operational State 2 could occur every 8th day and should not exceed 1 day and includes preops testing. 2.4.4 Operational State 4 Scheduled Maintenance In this state major Scheduled Maintenance activities are executed and the SKA System is operational for scientific/engineering observations but with degraded performance. In this state Corrective Maintenance could also be executed and site-visits could be allowed. During this Operational State the most stringent RFI Levels shall be maintained as far as possible. Operational State 4 could occur every 5th week and should not exceed 3 days and includes pre-ops testing. 2.4.5 Operational State 5 Upgrades In this state planned upgrades to hardware/software are executed and the SKA System is operational for scientific/engineering observations but with degraded performance. In this state Corrective & Scheduled Maintenance could also be executed and site-visits could be allowed. During this Operational State the most stringent RFI Levels shall be maintained as far as possible. Operational State 5 could occur every 24th week and should not exceed 3 weeks and includes pre-ops testing. 2010-01-18 Page 15 of 49

2.4.6 SKA System Annual Operating Requirement (AOR) 2 From the Operational States described above, the following are determined; Table 2 - SKA System Annual Time vs Operational States State Days Hrs % of Year Operational State 1. Green, fully operational 262 6,288 72% Operational State 2 and 3. Yellow, semi-operational 36 864 10% Operational State 4 and 5. Red, not operational 66 1,584 18% 365 8,736 100% The AOR for the SKA System is the combined hours for Operational States 1 and 2 and is; 2.5 LEVEL 7 SYSTEM RAM REQUIREMENTS 3 Table 3 - SKA System Annual Operating Requirement Days Hours % of Year AOR 298 7,152 82% In order to identify and develop 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 achieved by means of Reliability, Availability & Maintainability (RAM) expectations. It originates from the very top level (L7) and is fed down to lower levels. Reliability is a subjective 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 vderive 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). 2 Numbers in Tables 2 and 3 are proposals and need revision and refinement moving forward 3 Numbers in this section are proposals and need revision and refinement moving forward 2010-01-18 Page 16 of 49

From the Operational Cycles in section 2.4 above, the following Reliability, Availability & Maintainability (RAM) requirements are determined for the SKA System; 2.5.1 Level 7 Critical RAM Requirements Critical RAM Requirements are determined to have a measure of availability as a result of Critical Failures. Mean Time between Critical Failure (MTBCF) A typical mission is one Operational State 1 cycle, i.e. 168hrs. During this period, it is assumed that 5% probability for a Critical Failure is acceptable and a 95% Critical Reliability is therefore applicable. This translates to a MTBCF of 3,275hrs. Mean Time to Repair (MTTR) As the Maintainers are not on site, it is estimated that excluding travelling time to the site, a MTTR of <6hrs is applicable for Maintenance. Critical Availability (A c ) Utilising the MTBCF and MTTR figures above, the A c is calculated at 99.8%. 2.5.2 Level 7 Inherent RAM Requirements Inherent RAM Requirements are determined to have a measure of availability as a result of Non-Critical Failures. From the Critical RAM Requirements in section 2.5.1, the following Inherent RAM requirements are determined for the SKA System; Inherent Availability (A i ) During the operational state, it is assumed that a 3% probability of not being ready for operations is acceptable and a 97% A i is therefore applicable. Mean Time between Failure (MTBF) Utilising A i and MTTR above the MTBF is calculated at 194hrs. Inherent Reliability Utilising the Mission Time and MTBF above the Inherent Mission Reliability is calculated at 42.06%. 2010-01-18 Page 17 of 49

2.6 LEVEL 6 ELEMENT RAM REQUIREMENTS 4 To allocate RAM requirements from Level 7 to Level 6, the failure contributions of the telescope system and the facility system need to be estimated. It is estimated that the telescope system will contribute 75% of all failures and the facility system will contribute 25%. This estimation is based on the complexity and large scale development of the telescope system and the off-the-shelf approach for the facility system with little or no product development. 2.6.1 Level 6 Critical RAM Requirements Utilising the L7 Critical RAM figures in section 2.5.1 and failure contributions above, the following is calculated; Table 4 - SKA Level 6 Critical RAM Requirements Mission Time 168 Critical RAM Allocation Rel c MTBCF MTTR c A c SKA System 100% 95.00% 3,275 6.00 99.82% Telescope System 75% 96.23% 4,367 6.00 99.86% Facility System 25% 98.73% 13,101 6.00 99.95% This implies that for the telescope system there is a 4% probability that maintainers will need to visit the site to restore a critical failure and for the facility system the probability is 1%. 2.6.2 Level 6 Inherent RAM Requirements Utilising the L7 Inherent RAM Figures in section 2.5.2 and failure contributions above, the following is calculated; Table 5 - SKA Level 6 Inherent RAM Requirements Mission Time 168 Inherent RAM Allocation Rel i MTBF MTTR i A i SKA System 100% 42.06% 194 6.00 97.00% Telescope System 75% 52.23% 259 6.00 97.73% Facility System 25% 80.53% 776 6.00 99.23% This implies that for the telescope system there is a 48% probability that maintainers will need to visit the site to restore a Non-Critical Failure and for the facility system the probability is 19%. 4 Numbers in this section are proposals and need revision and refinement moving forward 2010-01-18 Page 18 of 49

3 SKA SYSTEM SUPPORT CONCEPT In order to allow the development of Logistical Support Resources, an initial view of how the system will be supported must be devised and is referred to as the Support Concept. The SKA System Support Concept is described below in terms of ten logistic elements considered to be important. The Support Concept originates with people involved with the Operation and Support of the SKA System and is discussed under the heading of Manpower & Personnel, see section 3.1. Where these people will be utilised and what they will do are discussed under the heading of Maintenance, see section 3.2. In order to execute Operations & Maintenance, people must receive specific training for the SKA System and this is discussed under the heading of Training, see section 3.3. For training to be effected, source information is required and mainly comes from Operation & Maintenance Manuals. This is discussed under the heading of Support Publications, see section 3.4. For trained people to execute maintenance they require spare parts and consumables. This is discussed under the heading of Supply Support see section 3.5. Spare parts are kept in storage, exchanged with faulty parts and transported between maintenance levels, and need to be protected against any damage that could occur. Special procedures need to be developed for this and are discussed under the heading of Packaging, Handling, Storage & Transportation, see section 3.6. Support & test equipment will be required to find faults in the system, and in order to replace faulty parts, and this is discussed under the heading of Support Equipment see section 3.7. The faulty part could be repaired at various maintenance levels and for such repairs special facilities could be required. This is discussed under the heading of Support Facilities, see section 3.8. In order to manage and control support activities, Logistical Data is required and is discussed under the heading of Support Data, see section 3.9. It is highly likely that telescope equipment could be in service and warranty periods for such equipment to have expired before the Support System is in place. An interim solution is thus required whereby equipment suppliers are required to support their products for extended periods and this concept is discussed under the heading of Product Supplier Support, see section 3.10. 2010-01-18 Page 19 of 49

3.1 MANPOWER & PERSONNEL 5 The Manpower & Personnel Concept is to have the correct people at the correct place with suitable skills to perform specific tasks for Operation and Maintenance. The identification of Personnel shall serve as an input to the Logistical Support Analysis (LSA) process. The following could be applicable; 3.1.1 Observers The Observer is normally an Astronomer or an Engineer who wants to do a specific science experiment or some engineering observation. The Observer is also the end-user of the Task Data Product produced by the SKA System. The Observer is highly skilled and will have received SKA Telescope Observer Training, and is concerned with the science experiments or engineering observations. The Observer is not at all involved with the maintenance of the SKA System. An Observer (astronomer/engineer) selects what observation task has to be performed and defines the Task Parameters and produces a Task Instruction Set. Once the Observer is satisfied that the task is properly defined, he/she hands the task instruction set to the Operator, requesting the execution of the task. During task execution, the Observer may monitor the system health status, though this is normally the duty of the Operator. During commissioning and performance operations, it is possible that the Observer will be located on-site, or at the SKA HQ off-site. During science operations or engineering operations, the Observer will be located at the SKA HQ off-site or equally likely at another location globally. 3.1.2 Operators The Operator is normally a Staff Astronomer or an Engineer that controls the SKA Telescope during science experiments or engineering experiments. The Operator is highly skilled and will have received SKA Telescope Operator Training, and is concerned with controlling the SKA Telescope and could possibly be involved in O-Level maintenance of the SKA Telescope. 5 This section will be updated once the Science Operations Plan is available. 2010-01-18 Page 20 of 49

An Operator (staff astronomer or engineer) schedules and executes the tasks requested by one or more Observers. The Operator carries out the task by executing the Task Instruction Set and monitoring the signal, system and health state displays. Upon completion of the task, the Operator sends a Task Data Product to the Observer. During commissioning and performance operations, it is possible that the Operator will be located on-site, or at the SKA HQ off-site. During science operations, the Operator will be located at the SKA HQ off-site. 3.1.3 Maintainers The Maintainer is a technical person that is skilled and qualified prior to receiving SKA Telescope Technical Training and is responsible for Corrective and Preventive Maintenance and for the telescope. The Maintainer is also involved during telescope task execution. The maintainer monitors the system health displays regularly during task execution and could, when required, take manual control of resources for the purposes of testing and diagnosis. (This authorisation needs to be delegated by the operator). During commissioning and performance operations, it is possible that the maintainers will be located on-site, or at the SKA HQ off-site. During science operations, the maintainers will be located at the SKA HQ off-site. Skill areas applicable are: 1. Electronic (RF) 2. Electronic (Digital & Software Systems) 3. Mechanical 4. Air Conditioning & Cooling 5. Electrical (Low & Medium Voltage) 2010-01-18 Page 21 of 49

3.2 MAINTENANCE The Maintenance Concept is to restore a failure as close to the SKA system as possible, i.e. replacement of Line Replaceable Units (LRU s) or Shop Replaceable Units (SRU s) rather than repair equipment in-situ. An LRU is item that can be replaced directly and which does not require a special workshop to be replaced. An SRU is an item that is replaced in an LRU and requires a technically equipped workshop. Restoring a failure must be as fast as possible to limit down-time within RFI constraints and policies. In addition, the Maintenance Concept shall be as independent as possible from reliance on outside maintenance organisations to ensure competency of organisational personnel. All Maintenance tasks shall be defined by a Logistical Support Analysis (LSA) process, see section 5.2.1. The following Maintenance Levels could be applicable; 3.2.1 Organisational Level (O-Level or OLM) O-Level Maintenance will be executed at two locations; On-site for the SKA Telescope System (possibly more than one location) and at the SKA HQ off-site for Control, Monitoring & Computing equipment, see Figure 4 on page 13. Corrective Maintenance at O-Level is accomplished by the removal and replacement of the Line Replaceable Units (LRUs) from the installed SKA System equipment. Preventive Maintenance at O-Level is accomplished by executing the maintenance on the SKA System equipment. 3.2.2 Intermediate Level (I-Level or ILM) I-Level Maintenance will be executed at the Maintenance Centre at the SKA HQ off-site. Corrective Maintenance at I-Level is executed on equipment removed at O-Level, and is accomplished by the removal and replacement of LRUs and Shop Replaceable Units (SRUs), as applicable. Preventive Maintenance at I-Level is accomplished by executing the complex maintenance program on equipment removed at O-Level.. 3.2.3 Deport Level (D-Level or DLM) D-Level Maintenance will be executed at the SKA HQ off-site, or at other dedicated D-Level Repair Facilities. Personnel from this level could also provide assistance to OLM and ILM activities when required. Corrective Maintenance at D-Level is executed on LRUs/SRUs from O & I-Levels, and is accomplished by the removal and replacement of components/software as applicable. 2010-01-18 Page 22 of 49

Preventive Maintenance at D-Level is accomplished by executing the specialist maintenance on equipment removed at O-Level, and not in the capability of I-Level. 3.2.4 Supplier Level (S-Level or SLM) S-Level Maintenance will be executed by Original Equipment Manufacturers (OEM) at approved supplier facilities, and can be anywhere in the world. Personnel from this level could also provide assistance to OLM, ILM and DLM activities when and where required. Corrective Maintenance at S-Level is executed on LRUs/SRUs from D-Level, and is accomplished by the removal and replacement of components/software as applicable. Preventive Maintenance at S-Level is accomplished by executing the specialist maintenance on equipment removed at O-Level (if applicable). 3.3 TRAINING The Training Concept is to equip personnel with sufficient skills to perform specific tasks for Operation and Maintenance. Training Development shall be based on international best practice and shall provide certified training courses and materials to allow training of future personnel, and to ensure continuity of maintenance capability. The Training Concept has two major components, i.e. Operator training, and Maintainer training, and shall be underpinned by LSA data. Training Development shall be executed in two phases; Training Assessment and Training Materials. During Training Assessment, the training environment, personnel and competency scope shall be evaluated to determine learning outcomes and to propose the most suitable training methodology and assessment. Training Materials shall be generated based on the Training Assessment Phase and shall consist of Learner and Facilitator resources to ensure successful training activities. The following Training Elements could be applicable; 3.3.1 Observer Training (Operation) Observer Training shall cover the requirements for: SKA System capabilities and limitations Selection of observation tasks Defining observation task parameters Producing a task instruction set Interaction with various displays 2010-01-18 Page 23 of 49

3.3.2 Operator Training (Operation) Operator Training shall cover the requirements for: SKA System capabilities and limitations Scheduling observations Executing task instruction sets Interaction with various displays Corrective and preventive maintenance 3.3.3 Maintainer Training (Maintenance) Maintainer Training shall cover the requirements for: SKA System capabilities and limitations Telescope System technical information System diagnosis and fault finding Corrective and preventive maintenance Resource information Support data requirements 3.4 SUPPORT PUBLICATIONS The Support Publication Concept is to provide sufficient and correct up to date information for personnel to perform specific tasks for operation and maintenance, and to complement training efforts. It shall be based on international best practice. The Publication Package will be developed for the operators and maintainers. The standard and media shall be selected during the training assessment process prior to the generation of publications. Operator publications will provide suitable information for the Observer and Operator to understand the SKA Telescope and to effectively execute defined tasks, and shall have its origin from Operator Interface Control Documents and LSA Data where applicable. Maintainer publications will provide suitable information for the maintainer to (a) understand the SKA System (b)effectively execute maintenance tasks and (c) allow the maintainer to effectively use the support system for the SKA System, and shall have its origin from LSA Data 2010-01-18 Page 24 of 49

3.5 SUPPLY SUPPORT The Supply Support Concept is to provide the right spare/consumable is at the right place at the right time. The Supply Support Element for the SKA System shall be sufficient to support the SKA System for one year based on the Annual Operating Requirement (AOR). The range, quantity and location of spares & consumables shall have its origin from LSA data and simulation/modelling. LRUs/SRUs shall be packaged, handled, stored and transported as described in the PHS&T concept. Replenishment of LRU s and SRU s shall be based on an exchange principle, i.e. a serviceable item shall be provided on the receipt of an unserviceable item. The following Supply Support Levels could be applicable; 3.5.1 O-Level Supply Support O-Level Supply Support shall provide LRUs that have a high probability of failure or are identified as critical items, as well as required consumables. All items defined as spares at O-Level shall be interchangeable with installed items with no calibration, tuning or alignment. 3.5.2 I-Level Supply Support I-Level Supply Support shall provide LRUs that have a lower probability of failure and selected SRUs, as well as required Consumables. I-Level Supply Support shall also provide a replenishing function for O-Level. All items defined as spares at I-Level shall be interchangeable with installed items with a minimum of tuning, calibration, aligning or other actions. Where alignment, calibration or tuning is required, a deterministic procedure for such actions shall be contained in the support publications. 3.5.3 D-Level Supply Support D-Level Supply Support shall provide long-lead LRUs, SRUs and components. D-Level Supply Support shall also provide a replenishing function for I-Level. 3.5.4 S-Level Supply Support S-Level Supply Support shall provide selected critical components only. 2010-01-18 Page 25 of 49

3.6 PACKAGING, HANDLING, STORAGE AND TRANSPORTATION (PHS&T) WP2-005.010.030-MP-002 The PHS&T Concept is to ensure sufficient protection for spare items against damage during handling and transportation activities. Packaging for LRUs/SRUs shall be in accordance with the Preparation, Preservation, Packaging and Marking (PPPM) principles and shall be contained in the maintainer publications. Special Handling instructions for the handling of delicate equipment are undesirable and shall not be acceptable; unless it is proved that no alternative handling methods are feasible. Storage areas at the various maintenance levels shall allow sufficient protection for packaged LRUs/SRUs and allow ease of maintenance during storage. All LRUs/SRUs shall be able to be transported by road, air, rail or sea, in adverse weather conditions, without incurring any damage when handled in the normal robust ways of these transport modes. 3.7 SUPPORT & TEST EQUIPMENT The Support & Test Equipment Concept is to provide the right piece of Support & Test Equipment (S&TE) at the right place at the right time. Requirements for S&TE to be supplied at the various maintenance levels are to be determined and driven by the outputs of the LSA process and simulation/modelling. Duplication of S&TE at various maintenance levels shall be minimised although some duplication may be unavoidable. Standardisation of S&TE at various maintenance levels shall be optimised. Test Jigs identical to those used during development shall be utilised as far as possible. 2010-01-18 Page 26 of 49

3.8 SUPPORT FACILITIES The Support Facilities Concept is to have sufficient facilities available to execute identified tasks for Operation and Maintenance at various levels of maintenance. Detailed requirements for facilities at all levels of maintenance shall be identified by the LSA process and simulation/modelling. Storage facilities at all levels of maintenance will be available for spares, S&TE and Publications. The following Support Facilities could be applicable; 3.8.1 O-Level Facilities Maintenance Facilities at O-Level shall be the installed equipment as it is not foreseen that workshops are required at this Maintenance Level. Storage Facilities for O-Level Spares and ST&TE and Publications will be required. 3.8.2 I-Level Facilities Workshop facilities shall be available at SKA HQ off-site to execute I-Level Maintenance. Storage facilities will be available for I-Level Spares, S&TE and Publications at the SKA HQ offsite. 3.8.3 D-Level Facilities Workshop facilities shall be available at the D-Level to execute D-Level maintenance. Storage facilities will be available for D-Level Spares, S&TE and Publications at the SKA HQ offsite. 3.8.4 S-Level Facilities It is expected that the S-Level Facilities would be sufficient as is, as most of the equipment will be manufactured at S-Level. 2010-01-18 Page 27 of 49

3.9 SUPPORT DATA The Support Data Concept is to ensure that; LSA data is uniformly prepared across all hierarchy levels of the SKA System to allow logistical integration, simulation, modelling and optimisation. Maintenance Management data is uniformly prepared and managed across all hierarchy levels of the SKA System to ensure efficient Support Management of the SKA System. A Failure, Reporting & Corrective Action System (FRACAS) is implemented to measure the predicted Logistic and RAM performance of the SKA System and to correct deficiencies, see section 5.1.8 and Figure 8. Logistic Standards and Processes will be identified at the highest hierarchy level for implementation from the lowest level as applicable. LSA Data will be integrated from the lowest to the highest hierarchy level to have a singular definition of the required Support System. 3.10 PRODUCT SUPPLIER SUPPORT (PSS) CONCEPT The Product Supplier Support (PSS) Concept is to ensure that Engineering and Maintenance Support from Suppliers are available when and where required. After the warranty period for a LRU s have expired, additional engineering/maintenance support would be required in support of the SKA System, until such time as the Logistic Support is available. 2010-01-18 Page 28 of 49

4 SUPPORT CONCEPT CHALLENGES & STRATEGIES Table 6 - Support Concept Challenges & Strategies Support Concept Challenges Strategies Manpower & Personnel High attrition rate of Personnel due to remote areas. Unwillingness of Personnel to be stationed in a remote area. Different pre-requisite qualification standards of Personnel. Observers may feel uneasy to have Observer Training before utilising the capabilities of the SKA Telescope Operators may have a perception that they have no career path or opportunities to grow. Maintainers may have a perception that they have no career path or opportunities to grow. Unsafe or tedious travelling for Maintainer to and from site. Resignations are unavoidable, and it is therefore important that the Training Packages are re-usable and can be used at short notice and are kept up to date with the System Configuration. Succession Planning for personnel must be planned and conducted to reduce recruitment time. Young Maintainers may not want to be cut-off from city life for long periods. Older Maintainers may be willing to be stationed in remote areas. A solution may be to have older, experienced and willing Maintainers stationed at remote sites with younger Maintainers on a temporary posting of 2 to 3 months at a time with financial incentives. This could result in a central pool of Maintainers posted out to remote stations on a regular basis and Maintainers would then only be in a remote area 2 to 4 Months of a year and not the full year. Establish Personnel Profiles and Pre-requisite experience during Training Development and recruit accordingly. It should not be the task of SKA to provide pre-requisite qualifications of Personnel but rather improving existing qualifications with SKA specific Training. The Observer Training Package may initially be an informal session or Information set available via the web. Establish career planning as part of recruitment policies. Establish career planning as part of recruitment policies. Maybe establish ranks such as Maintainer, Senior Maintainer, Chief Maintainer, Principle Maintainer etc. Involve Maintainers in the design & construction as early as possible. Encourage Maintainers to get cross-skilled qualifications. Make travelling as easy as possible (e.g. air ferry)and thus improving a positive attitude. 2010-01-18 Page 29 of 49

Maintenance Support Concept Challenges Increased self generated RFI due to Maintenance O-Level Maintenance may not always be capable of repairing low failure rate equipment (i.e. Dish). I-Level Personnel might be disappointed in the restore by replacement rather than restore by repair concept. D-Level Personnel might feel isolated from where the action is on-site S-Level Personnel specifically involved with SKA might be re-allocated to other projects within a company after SKA has been put into Operation. RFI awareness and reduction to be part of Training Support & Test Equipment to be RFI friendly Strategies Scheduled Maintenance to be done in System States where reduced RFI control levels are applicable It is impossible to carry all possible spares for all failure possibilities, but in such cases, S-Level support would be required to provide Personnel and Spares to repair such an item on-site. This would be a fact of life due to the cost involved to establish advanced workshops and spares at ILM. It should be cheaper to have SRU s at ILM than a vast range of components and S&TE. This decision will be based on the LSA Data simulations and modelling task. Devise regular inspection visits to on-site installations To counter this drain of knowledge, implement the PSS Concept to retain valuable knowledge. Recruit D-Level Personnel from S-Level to have the knowledge for SKA. Training Training Products outdated due to continuous System changes Different Training Development Standards Support Publications Support Publications outdated due to continuous System changes Different Publication Development Standards Logistic Engineering to be part of Engineering Changes and integrated with a proper Configuration Management System which controls all attributes of all systems/products. Establish best practise from accredited Training Professionals prior to Development. Training & Publication Development to be executed as one task Logistic Engineering to be part of Engineering Changes and integrated with a proper Configuration Management System which controls all attributes of all systems/products. Interactive Electronic Technical Manuals should shorten update time of Publications but could introduce RFI issues. Implement full document control and electronic distribution system. Establish best practise from accredited Training & Publication Professionals prior to Development Training & Publication Development to be executed as one task 2010-01-18 Page 30 of 49

Support Concept Challenges One volume of Technical Publications for the SKA System might be too large for effective use. Supply Support Spare Items in storage may be of outdated configuration due to continuous System changes Spare Items may require Scheduled Maintenance during storage. Vast range and quantity of Spare Items distributed globally. Strategies Establish best practise from accredited Training & Publication Professionals prior to Development. This will ensure the optimal distribution of Technical information for ease of use. Logistic Engineering to be part of Engineering Changes and integrated with a proper Configuration Management System which controls all attributes of all systems/products. Maintenance during storage to be addressed with PHS&T Development This is unavoidable but Spare scaling will be done with Logistic Engineering Development to reduce such occurrences. Acquired spares will go obsolete at some stage. Packaging, Handling, Storage And Transportation (PHS&T) With the Spare Scaling effort, identify items that could go obsolete and make a decision regarding procurement. Not robust enough for regional & international Transportation. Support & Test Equipment Vast range and quantity of Support Equipment distributed globally. Test Equipment out-of-calibration High tech and expensive S&TE damaged by improper use. Support Facilities Establish technical requirements for all specifications and test packaged spare items to requirements to ensure survival. This is unavoidable but Support Equipment scaling will be done with Logistic Engineering Development to reduce such occurrences. Establish a Support Management System to manage Logistic Activities during Operational Phase. This should include a system covering traceable calibration via standards to nationally accredited sources. Maintainer Training to address this as well as sending relevant Maintainers for Training at suppliers of high cost S&TE. Currently none identified Support Data LSA Data not developed to a uniform approach Use an international, affordable LSA tool that will ensure a common approach and execution to allow ease of evaluation, integration and modelling. 2010-01-18 Page 31 of 49

Support Concept Challenges Simulation and Modelling does not satisfy all requirements. The FRACAS not easy to use and Maintainers do not provide vital Support Data. Product Supplier Support (PSS) Concept Supplier Engineers committed to other projects and not readily available for SKA System problems Strategies Use an international, affordable, and upgradeable, simulation tool that will ensure international recognised modelling standards. Use an international, affordable FRACAS tool that will ensure international recognised modelling standards. Make it a required and audited procedure to use the FRACAS which will be essential to project lessons learned. This will be a reality. Keep Supplier Engineers current with the System via PSS contracts by Engineering Studies and regular site visits for example. 2010-01-18 Page 32 of 49

5 SKA LOGISTIC ENGINEERING SCOPE OF WORK WP2-005.010.030-MP-002 Based on the System Definition in section 2 and the expected Support Concept in section 3, the SKA Logistic Engineering effort to establish a Support System consists of two main efforts; 1. User System (Level 7) Logistic Engineering Effort; providing direction and guidance to the lowest hierarchy level, evaluating and integrating LSA Data and the eventual Logistic Support Management of the SKA System, see section 5.1. 2. System (level 6) and Lower Level Logistic Engineering Effort; providing LSA data from the lowest to the highest hierarchy level and Acquiring & Establishing of a Support System, see section 5.2. Log Eng Planning Log Eng Standards & Procedures Log Eng Support Libraries SKA User System Level 7 Logistic Support Management & RAM Performance Measurement LSA Data Evaluation LSA Data Integration Logistic Data Simulation & Modeling LSA Database to ILS Database Transition Logistic Support Analysis Data Logistic Support Resource Establishment & Verification SKA System Level 6 and lower SKA Development Phase SKA Operational Phase Figure 6 - SKA Logistic Engineering Scope of Work The User System (Level 7) Logistical Engineering Efforts are mainly direction giving and evaluation, integration and modelling tasks, and once the Support System is established, management of the Support System. The Lower level Logistical Engineering Efforts are mainly analysis, establishment of a Support System and eventually utilising the Support System to effectively support the SKA System over its useful life. An alternative view could be that an experienced group from Level 7 executes the work with inputs from lower levels. This will ensure a common approach to Logistical development without introducing a new engineering discipline in mainly academic institutions. 2010-01-18 Page 33 of 49

5.1 USER SYSTEM (L7) LOGISTIC ENGINEERING SCOPE OF WORK 5.1.1 Logistic Engineering Planning Planning at this level shall be by means of a Logistical Engineering Management Plan (LEMP) which is this document and provides the lower Levels with; 1. Intended Operational Cycles. 2. Annual Operating Requirements (AOR). 3. Reliability, Availability & Maintainability (RAM) Requirements 4. The anticipated Support Concept. 5. Logistic Engineering effort definition. 5.1.2 Logistical Engineering Standards & Procedures The total Logistical Engineering effort would be futile if not executed to one standard process and would result in a chaotic and very expensive Support System. To prevent this, Logistical Engineering Standards & Procedures must be provided from Level 7 downwards to ensure that a coherent Logistical Engineering approach and focus be created early in the project. Such Standards & Procedures should be based on international well known/proven methods such as MIL-STD-1388-2B, DEF-STAN-60, MIL-STD-1629A and so not re-invent the wheel. 5.1.3 Logistical Engineering Support Libraries As many engineering activities will be conducted in parallel, at various levels of the project, spread across the globe at many contributing institutions and companies, Support libraries are required to provide standardised information across all levels. This is especially critical when considering the Support Elements discussed in 3. This will ensure that an item of Support is the same and standardised across the SKA User System. 5.1.4 Logistical Support Analysis Data Evaluation LSA Data from lower levels must be evaluated and corrected to ensure consistency between many contributing institutions and companies. LSA Data must be correct as per 5.1.2 and 5.1.3 before LSA Data Integration can be attempted. 5.1.5 Logistical Support Analysis Data Integration Once all the lower level LSA Data have been verified to conform to the requirements of 5.1.2 and 5.1.3, the Data can be integrated into a single LSA Database to provide a total Support Requirement view of the SKA User System and to allow simulation and modelling. 2010-01-18 Page 34 of 49

5.1.6 Logistical Support Analysis Data Simulation & Modelling The Integrated LSA Data will be subjected to Logistic Simulation Models to model the following: Operational Deployment Failure Rates and Repair Times Support System Cost of the Support Resources Optimization of the Support Concept Once the Optimised Support System has been identified, the establishment of the SKA System Support Resources can be activated. 5.1.7 LSA Database to ILS Database Transition At this stage of Logistical Development, a consolidated and optimised LSA Database will exist defining what is required in terms of Support, as well as fully developed and verified Support Resources. The LSA Database must therefore be updated to an Integrated Logistic Support (ILS) Database to include as built information of the Support Resources to allow efficient Support Management. Personnel Allocation Manpower Levels Maintenance Planning Maintenance Plan Training Requirement Training Package Data Task Data Support Publication Data LSA Database Spare Recommendation Supply Support Data ILS Database PHS&T Requirement PPPM Data S&TE Recommendation S&TE Data Facility Recommendation Facility Data LSA Data Resource Development ILS Data Figure 7 - LSA Database to ILS Database Transition 2010-01-18 Page 35 of 49

5.1.8 Logistical Support Management & RAM Measurement Once the SKA Support System has been established and verified, a Maintenance & Support Plan (MSP) will be developed to provide the Operational SKA Support Managers with a comprehensive management tool to control the support by providing them with the necessary information and guide-lines for planning and control purposes. In addition the MSP will provide Maintainers at all Maintenance Levels with a Support Procedure for the execution of their duties. In order to ensure that the RAM requirements are maintained, a RAM performance Measurement system should be employed to identify Equipment RAM issues and/or shortcomings in the Support System for correction. This should be based on a Failure Reporting and Corrective Action System (FRACAS) comparing predicted RAM data with measured RAM data. LSA Data Resources Training Packages Publication Packages SKA System SKA System in Operation Measure Operational Time Record Failures Record Repairs Compare Measured RAM to Predicted RAM Record Log Delays Identify Drivers Figure 8 - SKA RAM Performance Measurement Decide on and Implement Actions Plans 2010-01-18 Page 36 of 49

5.2 SYSTEM (L6) AND LOWER LEVEL LOGISTIC ENGINEERING SCOPE OF WORK The Logistic Engineering Process can be illustrated as follows; SKA Development Phase Design Data Hardware Data Supplier Data OEM Data Design Influence Support Concept Common Resources Logistic Support Analysis Training & Publication Establishment Support Resource Establishment Logistic System performance verification Maintenance & Support SKA Operational Phase RAM Performance Improvements Operational Cycles RAM Requirements AOR Requirements Data Requirements Figure 9 - System (L6) To Sub-Assembly (L2) Logistic Engineering The Logistical Support Analysis (LSA) requires defined inputs before it can commence; 1. System/Equipment data to define what will be analysed. (Design Data) 2. An expected Support Concept to define how the System could be supported. 3. A definition of how the System is expected to be operated. 4. The required Reliability, Availability & Maintainability (RAM) requirements. 5. The LSA Data requirements to allow simulation and modelling of the Support System. The output of the LSA is a consolidated definition of the Support System requirements to allow the establishment of the Support System. See section 5.2.1. During the LSA Process, Technical and Logistic issues will be uncovered and will serve as an input to the design effort to ensure a supportable System. See section 5.2.2. Training, Publication and other Support Resources are acquired and verified for optimal performance before the System is actively supported in the Operational Phase. See sections 5.2.3, 5.2.4 & 5.2.5. In a complex system there are always improvements to be implemented to the System and/or the Support System and is only identifiable over time. 2010-01-18 Page 37 of 49

5.2.1 Logistical Support Analysis The LSA is an organised and systematic analytical process conducted on an iterative basis in order to determine the logistic support requirements and facilitate the development of these support requirements. Design Data Hardware Data Supplier Data OEM Data Operational Cycles RAM Requirements AOR Requirements Data Requirements Criticality Definition Establish PBS Determine Reliability Figures Conduct FMECA Support Concept Common Resources Identify Corrective Tasks Identify Preventive Tasks Reliability Data Conduct Detail Task & Resource Analysis Maintainability Data RAM Data Repair Data Generate LSA Report Failure Data Calculate RAM Figures Equipment Data Establish Support System The LSA Process is further detailed below; Figure 10 - Logistical Support Analysis Process 5.2.1.1 Establish Product Breakdown Structure (PBS) The purpose of the PBS is to assist with identifying the physical location of items within the SKA System. The PBS is utilised to establish a hardware configuration structure (Equipment Data) for the SKA System to accurately define the hardware as input to the Reliability Analysis. The PBS will be updated throughout the LSA process to accommodate new information and analysis needs. Inputs to this task are System Engineering Design inputs, Bill-of-Materials (BOM) and associated assembly drawings for Sub-Assemblies up to Elements and Original Equipment Manufacturer (OEM) part numbers, description and company details for specific components. 2010-01-18 Page 38 of 49

PBS data will be reviewed and updated accordingly in the LSA Database and this data will be formally documented and reviewed in the LSA Report. 5.2.1.2 Determine Reliability Figures An iterative RAM Analysis process will be followed for the SKA System to ensure the best possible estimates of the MTBF values to determine the Reliability Data of the system as an input to the FMECA Process. At this stage of the LSA only the Reliability can be calculated as the System structure is known and reliability estimations can be calculated from the lowest level up to the SKA System level. As no Task Analysis has been done at this stage, the Maintainability figures will be predicted to provide an initial view of the expected RAM performance of the SKA System. As the FMECA follows the Reliability determination, the Mean Time Between Critical Failures (MTBCF) can only be determined upon completion of the FMECA process where critical failures are identified. The final RAM data will be reviewed and updated accordingly in the LSA Database and this data will be formally documented and reviewed in the LSA Report. 5.2.1.3 Conduct Failure Modes, Effects and Criticality Analysis (FMECA) An FMECA will be conducted to determine the failure characteristics (Failure Data) of the SKA System as an input to Task Analysis and shall form the basis of Fault Finding Tables in Support Publications. The FMECA process shall consist of two components, i.e. Failure Modes and Effects Analysis (FMEA) and Criticality Analysis (CA). The FMEA will be conducted based on MIL-STD-1629A Referenced Document [8]. The Typical operational cycle (see section 2.4) shall be utilised as the expected operating time for the FMEA. All failure modes identified by the FMEA will be subjected to a Criticality Analysis (CA) utilising severity and probability classifications, resulting in a classification of failures according to Unacceptable, Acceptable, to be Reviewed and Acceptable Failures. Probability Classifications for failures will be determined from the expected Reliability and the Mission Time as follows; Probability Code A - Frequent. A High probability (20% to 100%) of the failure mode occurring during a mission. Probability Code B - Reasonably Probable. A Modest probability (10% to 20%) of the failure mode occurring during a mission. Probability Code C - Occasional. A Reasonable probability (1% to 10%) of the failure mode occurring during a mission. 2010-01-18 Page 39 of 49

Probability WP2-005.010.030-MP-002 Probability Code D - Remote. A Slight probability (0.1% to 1%) of the failure mode occurring during a mission. Probability Code E - Extremely Unlikely. Essentially No probability (Less than 0.1%) of the failure mode occurring during a mission. Severity Classifications for failures will be determined from the following; Category 1 - Catastrophic. A failure which may cause death or system loss. Category 2 - Critical. A failure which may cause severe injury, major property damage, or major system damage which will result in mission loss. Category 3 - Marginal. A failure which may cause minor injury, minor property damage, or minor system damage which will result in delay or loss of availability or mission degradation. Category 4 - Minor. A failure not serious enough to cause injury, property damage, or system damage, but which will result in unscheduled maintenance or repair. Criticality Classification of failures will be determined from the following; Table 7 Criticality Analysis Matrix A Frequent 4A Acceptable with Review 3A Unacceptable 2A Unacceptable 1A Unacceptable B Reasonably Probable 4B Acceptable with Review 3B Undesirable 2B Unacceptable 1B Unacceptable C Occasional 4C Acceptable 3C Undesirable 2C Undesirable 1C Unacceptable D Remote 4D Acceptable 3D Acceptable with Review 2D Undesirable 1D Undesirable E Extremely Unlikely 4E Acceptable 3E Acceptable with Review 2E Acceptable with Review 1E Acceptable with Review 4 Minor 3 Marginal 2 Critical 1 Catastrophic Severity FMECA data will be reviewed and updated accordingly in the LSA Database and this data will be formally documented and reviewed in the LSA Report. 2010-01-18 Page 40 of 49

5.2.1.4 Identify Maintenance Tasks Maintenance tasks are assigned to the various levels of support by evaluating the inherent maintenance characteristics of the system design (complexity) and the Support Concept. Corrective tasks will be identified by linking a maintenance task to each of the failure modes identified in the FMECA, in order to restore the lost/degraded functionality. Preventive tasks will be identified by linking a maintenance task(s) to failure modes identified in the FMECA, where failures can be prevented by scheduled maintenance actions. Identified tasks will be mapped against the PBS to provide a Maintenance Matrix. The Maintenance Matrix will be reviewed and updated accordingly in the LSA Database and this data will be formally documented and reviewed in the LSA Report. 5.2.1.5 Conduct Detail Task and Resource Analysis The tasks identified will be analysed in detail in terms of sub tasks, sub task times and resources and re-evaluated in terms of Criticality Classification, Complexity and the Support Concept. The required skills, manpower, tools, parts, support and test equipment and facilities will be identified and allocated to the respective subtasks. This step provides the basis for Supply Support, Training, Publications, S&TE and Facility developments. Task Analysis data will be reviewed and updated accordingly in the LSA Database and this data will be formally documented and reviewed in the LSA Report. 5.2.1.6 Generate Consolidated LSA Report The LSA Report provides a consolidated definition of the System s Equipment Data, RAM Data, Failure Data and Repair Data. The LSA Reports and Databases shall serve as an input to Level 7 LSA Data evaluation, integration and modelling. 2010-01-18 Page 41 of 49

5.2.2 Design Influence 5.2.2.1 Design Influence Process Design Influence shall be executed in each of the LSA tasks and shall be by recording observations and recommendations. These observations and recommendations shall be evaluated by the Design Teams for possible changes to the System Designs and/or changes to the Support System. 5.2.2.2 Logistic Factors The following Logistic factors could be applicable to Design Influencing during the LSA Process: 1. Physical Breakdown Structure (PBS) Material choice to reduce corrosion risks Standardisation of components and OEM s 2. Reliability and Maintainability figures Reliability improvements, i.e. redundancy, item type etc. Maintainability improvements, i.e. accessibility, ease of removal, ease of testing etc. 3. Failure Modes, Effects and Criticality Analysis (FMECA) Reliability improvements, i.e. redundancy, item type etc. Compensating provisions Failure detection Single point failures and unacceptable failures Critical failures 4. Task Identification Support Concept updates Combining Preventive Maintenance tasks Maintainability improvements, i.e. accessibility, ease of removal, ease of testing etc. 5. Detail Task and Resource Analysis Support Concept updates Maintainability improvements, i.e. accessibility, ease of removal, ease of testing etc. Standardisation of support resources 2010-01-18 Page 42 of 49

5.2.3 Training & Publication Resource Establishment Figure 11 provides an overview of a typical Training & Publication Resource Development Process, based on the best principles of learning development. Training & Publication are normally developed in two main streams, i.e. Operating and Technical. Support Concept Personnel Def Develop Training Survey Report (TSR) Technical Tasks from LSA Report Develop Personnel Performance Profile Report (PPPR) Develop Technical Task List Report (TTLR) Develop Operator Task List Report (OTLR) Observer Tasks Operator Tasks Develop Intended Learning Outcomes Report (ILOR) Develop Intended Learning Outcomes Report (ILOR) Develop Media Selection & Curriculum Dev Report (MSCDR) Develop Media Selection & Curriculum Dev Report (MSCDR) Develop Technical Training Curriculum Develop Technical Publication Specification Develop Operator Training Curriculum Develop Operator Publication Specification Develop Technical Learner Modules Develop Technical Support Publications Develop Operator Learner Modules Develop Operator Support Publications Develop Technical Learner Guides Develop Technical Facilitator Guides Other Support Resources Develop Operator Learner Guides Develop Operator Facilitator Guides Develop Technical Assessment Guides Present Technical Training Develop Operator Assessment Guides Present Operator Training 5.2.3.1 Training Development Figure 11 - Training & Publication Resource Establishment Process In order to understand the Training Environment, the Support Concept and Personnel information is used to generate a Training Survey Report (TSR) and to evaluate the existing training facilities and equipment where applicable. To have a concise understanding of the Personnel involved in the Operation and Maintenance, a Personnel Performance Profile Report (PPPR) is generated to understand what skills and previous qualifications are required and to provide detail of the existing skills/qualifications and possible new requirements. Utilising the TSR and PPPR, Operator tasks are analysed to compile an Operator Task List Report (OTLR) to provide detail of the new skills/training requirements. 2010-01-18 Page 43 of 49

Utilising the TSR and PPPR, Maintainer tasks from the LSA are analysed to compile a Technical Task List Report (TTLR) to provide detail of the new skills/training requirements. Utilising the OTLR and TTLR information from previous training development tasks, an Intended Learning Outcomes Report (ILOR) is generated for both the Operator and Maintainer to clearly define training objectives. The next step is to define the most suitable training medium and environment to satisfy the Intended Learning Outcome. This is documented and reviewed in a Media Selection & Curriculum Development Report (MSCDR). Training Curricula are developed in order to clearly define Learner and Facilitator requirements and how the Training will be assessed for correctness and applicability. These requirements are documented and reviewed in an Operator Training Curriculum and in a Maintainer Training Curriculum. Utilising the Training Curriculum as an input, the Training Package is developed for the Learners and Facilitators for both the Operator and Maintainer Training Courses and consist of; Learner Modules. Learner Guides. Facilitator Guides. Assessment Guides. 5.2.3.2 Publication Development Based on the Media Selection & Curriculum Development Report (MSCDR), the Support Publication Package will be defined for the Operators and Maintainers. This effort shall be documented and reviewed in a Technical Publication Specification and in an Operating Publication Specification. The Publication Package will be developed for the Operators and Maintainers based on the Publication Specifications. This effort shall be documented and reviewed in Technical Support Publications and in Operating Support Publications. 2010-01-18 Page 44 of 49

5.2.4 Support Resource Establishment Figure 12 provides an overview of a typical Support Resources Development Process. Resource Requirement from LSA Report Procure/Manufacture Spares & Consumables Deliver to required Site [Spares & Consumables] Warranty and Support Contracts in place Procure/Manufacture Tools and S&TE Deliver to required Site [Tools and S&TE] Warranty and Calibration in place Establish/Update Facilities Warranty and Support Contracts in place Figure 12 - Support Resources Establishment Process 5.2.5 Logistical System Performance Verification Figure 13 provides an overview of a typical Logistical System Performance Verification process and is conducted as part of the Assessment of the Training Courses. Resources Training Packages Publication Packages Training Courses Training Assessments Updated Resources SKA System Updated Training Packages Updated Publication Packages Figure 13 - Logistical System Performance Verification Process 2010-01-18 Page 45 of 49

6 EXPECTED TIMEFRAME It is a requirement to have the SKA Support System in place and ready when Phase 2 Testing, Verification & Commissioning commences. This will allow for a period of ± 1.5 years under Operational conditions to fine tune the Support System prior to the SKA Science Operations. The expected Timeframe is contained in Appendix A and is briefly discussed below; 6.1 LOGISTICAL ENGINEERING PLANNING The initial LEMP is planned for review at the System Engineering CoDR. Further refinements and updates shall continue until the Project Management PDR is complete and the Project Plan & Schedule are established at ± the end of 2011. 6.2 LOGISTICAL ENGINEERING STANDARDS & PROCEDURES AND SUPPORT LIBRARIES LSA work cannot commence until the System Design has completed its CDR and lower designs are sufficiently defined for LSA activities. This allows a period of ± 2 years for Logistic Engineering Standards & Procedures and Logistic Engineering Support Libraries to be finalised. It is estimated that the Logistical Engineering Standards & Procedures could be complete for review at the System Engineering PDR at ± the end of 2012. It is estimated that the Logistical Engineering Support Libraries could be complete for review at the System Engineering CDR at ± the end of 2013. 6.3 LOGISTICAL SUPPORT ANALYSIS & DESIGN INFLUENCE LSA is the largest task to be executed and can only commence when the System Design has completed its CDR and lower designs are sufficiently defined for LSA activities. During the LSA Process Design Influencing would also occur. The LSA would logically only be completed after Factory Acceptance Tests (FAT) and changes as a result of FATs are known. It is estimated that the LSA will be completed towards ± the end of 2017. 6.4 LOGISTIC SUPPORT ANALYSIS DATA EVALUATION AND INTEGRATION The expected large amount of LSA data should be Verified and Integrated by the System Engineering TRR by ± early 2018. 6.5 LOGISTIC SUPPORT ANALYSIS DATA SIMULATION & MODELLING LSA Data Simulation & Modelling should be complete towards ± the end of 2018. 2010-01-18 Page 46 of 49

6.6 SUPPORT RESOURCE ESTABLISHMENT It is estimated that the establishment of Support Resources would be complete by mid 2020. From this point in time there is approximately one year left for Logistical System Performance Verification and tasks before the Support System is required to be ready for Operational use. 6.7 LOGISTICAL SYSTEM PERFORMANCE VERIFICATION It is estimated that the Logistical System Performance Verification could be complete at ± the end of 2020. 6.8 LSA DATABASE TO ILS DATABASE TRANSITION It is estimated that the LSA database to ILS database transition task could be complete by ± mid 2021 and the Support System is ready for Operational use when the System Engineering Verification & Commissioning commences. 6.9 LOGISTICAL SUPPORT MANAGEMENT & RAM MEASUREMENT From mid 2021 to the end of 2022, there is a period of ±1.5 years where the SKA System is still under Project control before handover to Operations. During this period the Maintenance & Support Plan (MSP) and the Failure Reporting and Corrective Action System (FRACAS) will be established so that the Support System together with the SKA System are handed over to Operations. From Site Acceptance Test (SAT) Operational Support would be active for the life span of the SKA System. 2010-01-18 Page 47 of 49

Appendix A Expected Timeframe 2010-01-18 Page 48 of 49

Log Eng Planning Log Eng Standards & Procedures Log Eng Support Libraries Logistic Support Analysis Data LSA Data Evaluation LSA Data Integration Logistic Data Simulation & Modeling Logistic Support Resource Establishment Logistic Support Resource Verification LSA Database to ILS Database Transition Logistic Support Management Design for Support RAM Performance Measurement Design the Support Support the Design 2010-01-18 Page 49 of 49