title : salt commissioning and test · pdf filetitle : salt commissioning and test plan...

SALT Commissioning and Test Plan

Doc No. 1000BP0076 Issue Draft

1

APPROVAL SHEET

TITLE : SALT Commissioning and Test Plan

DOCUMENT NUMBER : 1000BP0076 ISSUE: 1

SYNOPSIS : This document defines the TCS builds, commissioningprocess and system testing for SALT.

KEYWORDS : Telescope Control System, Commissioning, Testing,Integration

PREPARED BY : Gerhard Swart

APPROVED : Gerhard SwartSALT Systems Engineer

Kobus MeiringSALT Project Manager Engineer

DATE : February 2003



2

This issue is only valid when the above signatures are present.Printed: 16/09/03 13:32



3

ACRONYMS AND ABBREVIATIONS

ATP Acceptance Test ProcedureATR Acceptance Test ReportBMS Building Management SystemCDR Critical Design ReviewCOTS Commercial off the shelfEDS Environmental Display SystemELS Event Logger SoftwareHET Hobby-Eberly TelescopeI/O Input/Output (Device)ICD Interface Control DossierMMI Man-Machine InterfaceMTBF Mean Time Between FailuresMTTR Mean Time to RepairOEM Original Equipment ManufacturerOPT Operational Planning ToolPC Personal ComputerPDR Preliminary Design ReviewPFIS Prime Focus Imaging SpectrographPI Principal Investigator (Astronomer)PIPT PI Planning ToolPLC Programmable-Logic ControllerSA SALT AstronomerSALT Southern African Large TelescopeSAMMI SA Machine InterfaceSDB Science DatabaseSDD Software Design DocumentSDP Software Development PlanSO SALT OperatorSOMMI SO Machine InterfaceSRS Software Requirement SpecificationSTARCAT Object CatalogueSW SoftwareTBC To Be ConfirmedTBD To Be DeterminedTCS Telescope Control SystemTCSS TCS ServerVI Virtual Instrument (Labview function)WEB SALT web-server



4

TABLE OF CONTENTS

1 Scope ..........................................................................................................52 Referenced Documents.............................................................................53 Commissioning principles ........................................................................53.1 Subsystem Commissioning ......................................................................................................53.1.1 Responsibilities...........................................................................................................................53.1.2 Acceptance Testing...................................................................................................................63.1.3 Documentation............................................................................................................................63.2 System Integration.......................................................................................................................63.2.1 Pre-requisites.............................................................................................................................63.2.2 Responsibilities...........................................................................................................................73.2.3 Acceptance Testing...................................................................................................................73.2.4 Documentation............................................................................................................................83.3 Regression testing ......................................................................................................................83.4 Integration log...............................................................................................................................8

4 Description of Commissioning Process ..................................................84.1 Schedule.........................................................................................................................................84.2 Phase 1: Basic SO functionality ................................................................................................104.3 Phase 2: Basic SA functionality ................................................................................................114.4 Phase 3: Basic PFIS functionality..............................................................................................114.5 Phase 4: Advanced functionality..............................................................................................11

5 Telescope Testing ...................................................................................126 Verification of Safety Requirements ......................................................137 Telescope Handover................................................................................138 Documentation.........................................................................................139 Configuration Control .............................................................................13



5

1 Scope

This document describes the proposed sequence of activities associated with the commissioning of theSouthern African Large Telescope (SALT).

The purpose of this plan is to co-ordinate the effort and the activities on site thus minimising thecommissioning time.

In summary, the following process is followed:• Each subsystem is commissioned on its own and tested for compliance with its appropriate

specification, prior to integration with the TCS.• The TCS, as recommended at the PDR, is commissioned in “Builds”, suited to the requirements of

integrating the particular subsystems that are present at any one time. A TCS build ATP precedesany integration of the TCS.

• The TCS build is integrated with the subsystem in Cape Town to the extent possible beforeattempting site commissioning.

• Integrating a build on site occurs by day, typically reverting to the previous build by evening, so thattelescope integration tests can proceed.

2 Referenced Documents

The following documents are referenced in this plan.

1000AS0007 SALT System Specification1000AA0030 SALT Safety Analysis1000AS0040 SALT Operational Requirement1000AR0077 SALT Test Cross-reference Matrix1000BS0010 SALT Software Standard1000AA0017 SALT Error Budget

3 Commissioning principles

3.1 Subsystem Commissioning

3.1.1 Responsibilities

Subsystem manager• Co-ordinate and arrange all tests• Make sure ATP tests all requirements in the following documents:

o System Spec where test is indicated as tested at a “subsystem” levelo Subsystem spec (excluding items that can only be tested at a SALT system level)o Software Standardo Safety Analysiso Optical Error Budgeto Electrical ICDo Data ICD

• Ensure that the required documentation exists, writing additional documentation if required• Make sure all contractual requirements (including documentation) are met prior to approving final

payment• Ensure that the appropriate SAAO people have received adequate training to perform preventative

maintenance on the subsystem



6

Safety Manager• Make sure ATP adequately tests preventive measures in Safety Analysis

Systems Engineer• Approve ATP documents prior to test• Approve completed tests• Approval of software source code and documentation

SAAO• Learn about the telescope• Provide technical support for small installations and tests• Maintain equipment that has been handed over by subcontractors

3.1.2 Acceptance Testing

• SE approve ATP document beforehand• Dry-run of ATP before final one• Configuration of system must be known/recorded (HW and SW)• Test witnessed by Subsystem Manager and SE where possible• SW/functional tests witnessed by member of TCS team• Test report completed by hand and filed

3.1.3 Documentation

Prior to test• Blank ATP document approved by SE• Subsystem documentation and Software Version definition• Completed LabVIEW Coding Standard checklists

After test• Completed ATP• List of failed tests requiring action (snag list)• List of concessions• Completed and signed Safety Certificate

Prior to final payment of contractor• As-built documentation• Operating Manual• Maintenance Manual• Software source code• Software documentation

3.2 System Integration

3.2.1 Pre-requisites

Prior to the start of integration with a subsystem, the ATP of that subsystem must have beencompleted and the result confirming that that subsystem is essentially complete.

The appropriate TCS Build ATP shall have been completed.



7

3.2.2 Responsibilities

Systems Engineer and Engineering Services team• Co-ordinate and arrange all system commissioning and tests• Perform data analysis and initiate subsystem changes to correct problems as appropriate• Make sure that the System ATP tests all requirements in the following documents:

o System Spec where test is indicated as tested at a “System” levelo Subsystem spec (items to be tested at a SALT system level)

• Ensure that the required subsystem documentation exists• Ensure that pre-requisites are met prior to starting integration

Subsystem Managers• Ensure that the Subsystems involved are functioning correctly• Provide commissioning assistance in operating and monitoring their subsystem• Correct subsystem problems or arrange that it is done• Provide general support for system tests

SALT Test Committee• Oversee and validate ATP document and result approval by Project Scientist• Witness system tests

Project Scientist• Approve System ATP document prior to test• Provide astronomer support for telescope operation and test analysis• Approve completed system ATP• Witness and support system tests

SALT Operator and Astronomer• Learn about the telescope• Operate the telescope to support commissioning• Provide feedback regarding telescope operation

SAAO• Learn about the telescope• Provide technical support for small installations and tests• Maintain equipment that has been handed over by subcontractors

Safety Manager• Make sure ATP adequately tests system-level preventive measures in Safety Analysis• Audit Safety Certificates• Issue System-level Safety Certificate

3.2.3 Acceptance Testing

• Project Scientist approve ATP document beforehand (may be in chapters)• Progressive ATP as subsystems are integrated with each other and the TCS• Configuration of system must be known/recorded (HW and SW)• Test witnessed by SE and Project Scientist where possible• Test report completed by hand and filed



8

3.2.4 Documentation

Prior to test• Blank ATP document approved by Project Scientist

After test• Completed ATP• List of failed tests requiring action (snag list)• List of concessions• Completed and signed Safety Certificate

Prior to final hand-over• Audit of subsystem as-built documentation• Operating Manual• Maintenance Manual• Audit of subsystem software source code• Audit of software documentation

3.3 Regression testing

If major modifications are made to subsystems during the commissioning process, these changes mayinvalidate previous test results. To ensure that results are valid, a certain amount of “regression testing”will have to be performed.

When minor changes have been made to software, and these are known not to effect performancecriteria, a “Limited Functional Test” can be performed prior to proceeding with the commissioningprocess. This test will typically involve starting up the item, running it using its local MMI and checking afew major functions.

When substantial changes have been made or when changes are expected to influence performance,it may be necessary to repeat parts or the whole ATP of that item.

3.4 Integration log

A logbook per subsystem and for the integrated system will be kept of all tests performed and changesimplemented to support diagnosis of problems. This will refer to specific Build information, softwareversions, Problems Reports and Change Reports associate with the work done every day. All personsinvolved will be required to use these books. Copies of these books will be made at regular intervals forbackup purposes.

3.5 Fault Reporting and Corrective Action System

A computer database with web-based forms will be used to record failure information, track theresolution of changes and log corrective actions.

4 Description of Commissioning Process

4.1 Schedule

A preliminary commissioning schedule is shown in Figures 1 and 2. It has been based on the projectmilestones, as listed in Appendix A.



9

Figure 1: Commissioning part 1



10

Figure 2: Commissioning part 2

4.2 Phase 1: Basic SO functionality

The basic functionality to point the telescope and get light to the focal plane using SOMMI. SALTICAMwill be in its VI mode for phase 1. The optical and physical integration of the subsystems precede theactivities identified below.

Build Description Integrated Functionality Main items involved1.1 Integrated SDC Low-level SOMMI dome control,

low-level SOMMI structurecontrol

SOMMI, TCSS core, SDC



11

control1.2 Integrated PMAS -basic Previous plus preliminary

information to MACS for controlSOMMI, TCSS core, MACS,SAMS, SPS, CCAS

1.3 Integrated BMS Previous plus low-level airconand louver control, e-stopmonitoring, interlock panelmonitoring, weather

SOMMI, TCSS core, BMS, EDS

1.4 Integrated PMAS Previous plus low-level controlof mirror functions, includingmirror alignment

SOMMI, TCSS core, MACS, SPS,SAMS, CCAS

1.5 Integrated Tracker Previous plus low-level controlof the Tracker pointing andtracking (not guidance)

SOMMI, TCSS core, TC

1.6 Pointing - basic Previous plus the addition ofTracker trajectory (to lowaccuracy)

SOMMI, TCSS all, SDC, TC

1.7 Integrated Payload Previous plus low-level controlof the Payload and enabling ofguidance

SOMMI, TCSS, TC, TPC, SCAM

4.3 Phase 2: Basic SA functionality

The basic functionality to acquire an image of a planned object, using SALTICAM and SAMMI.

Build Description Integrated Functionality Main items involved2.1 Integrated SAMMI/OPT Get object info from SDB,

schedule observation, send infoto SOMMI, acquire object,display object

SDB, OPT, SAMMI, TCSS, TC,TPC, SCAM

2.2 Integrate SALTICAM data Previous plus use SALTICAM init ACSI mode to obtain imagesand store them correctly

SAMMI, SCAM, TPC

2.3 Integrate basic PIPT Previous plus basic PI planningtools for SALTICAM

SAMMI, OPT, SDB, PIPT, TCSS,SCAM

4.4 Phase 3: Basic PFIS functionality

This is preliminary information that will be expanded after the PFIS CDR. The physical integration of PFISwith the Tracker and Payload will precede the activities below.

Build Description Integrated Functionality Main items involved3.1 Integrate PFIS/TCS Allow information exchange

between TCSS and PFIS to theextent required for PFIS toperform a basic observation.

SAMMI, TCSS, PCON, PDET

3.2 Integrate PIPT for PFIS Previous plus basic PI planningtools for PFIS

SAMMI, OPT, SDB, PIPT, TCSS,PCON, PDET

4.5 Phase 4: Advanced functionality

This is essentially to achieve full functionality defined in the SALT specification, including accuratepointing, observation scheduling, full use of SALTICAM and PFIS (basic modes), diagnostic tools (EventLogger). The following provisional builds have been defined:



12

Build Description Integrated Functionality Main items involved4.1 Calibrated Geometric

PointingCo-ordinated movement to initialgeometric pointing accuracy(value TBD)

TCSS, TPC, SCAM, SDC, TC

4.2 Astrometric Pointingverified

Can point to initial astrometricaccuracy (value TBD)

TCSS

4.3 Event Logger Integrated Event logger can record datafrom all subsystem

ELS, TCSS

4.4 Event logger alarms Event logger set up to recordspecific alarm events

ELS, TCSS

4.5 SALITCAM observing PI can plan a SALTICAMobservation, SA can schedule itand SO can observe it

PIPT, OPT, TCSS, SAMMI,SOMMI, SDB, SCAM

4.6 SDB stores data SALTICAM data can be sent toSDB and stored in a retrievablefashion with the correctheaders

SCAM, SDB

4.7 PI gets data PI can get data from SDB PIPT, SDB, WEB4.8 All SALTICAM functions Remaining first-light functions

/modes (if any) for SALTICAMintegrated

PIPT, OPT, TCSS, SAMMI,SOMMI, SDB, SCAM

4.9 PFIS observing PI can plan a PFIS observation,SA can schedule it, SO canobserve it, data goes to SDBand PI can retrieve it

PDET, PCON, PIPT, OPT, TCSS,SAMMI, SOMMI, SDB

4.10 All PFIS first light functions Remaining (available) first-lightfunctions/modes (if any) forPFIS integrated

PDET, PCON, PIPT, OPT, TCSS,SAMMI, SOMMI, SDB

NOTE: The completion of the PFIS integration will depend on many factors not accounted for. When detailedplanning has been done in this regard, these builds will be re-defined as appropriate.

5 Telescope Testing

The system-level testing that is planned is summarised in document number 1000AR0077 SALT System TestCross-reference Matrix. This document provides traceability between the requirements of the SALT SystemSpecification and the various Test Procedures making up the System ATP. The cross-reference matrix isalso used to summarise the results of the testing.

The following separate tests are envisaged. Paragraph references refer to the SALT System Specification.a. Interface Tests: Check and update interfaces against the ICD where it makes sense to do sob. Image Quality Tests: Para 5.3.1.1 and error budget. This will take each item of the error

budget and indicate in which test that item will be verified or will describe the test and providespace for results and PASS/FAIL recording. This will be linked to an "As-tested" error budgetthat will add up the numbers to prove compliance to the system-level figure.

c. Design Verification: This will cover all the items that will not be tested but that can beverified by reviewing the design in detail (e.g. f-ratio, pupil size, location, CCAS position,telescope axis system, general design guidelines, materials)

d. Basic Functionality and Operational Performance Test: The demonstration of specificfunctionality called for (e.g. capability to acquire an object para. 5.3.1.4.1, align a mirror para5.3.1.7.1) Demonstration of telescope operation complying with requirements (e.g. FirstAcquisition time para. 5.3.1.4.2, MMI suitability, manual operation, training, manuals,Interchangeability, safety tests)



13

e. Technical performance tests: Verification of quantifiable performance not covered in othertests (e.g. Tracking range 5.3.1.5.4, Acquisition range, light throughput 5.3.1.8, )

f. Pointing and Tracking tests: Verification of Open loop Tracking, Tracking rates, Acquisitionaccuracy

g. Thermal tests: Maximum surface temperatures, air temperatureh. Environmental requirements: Some testing and analysis to show compliance with this

requirement para. 5.3.3., 5.3i. Availability tests: Records of failures and associated analysis to show compliance with

availability requirementsj. Quality Inspection: Compliance to workmanship standards, Safety Act, para 5.5 (design and

construction constraints)k. Safety compliance (will be updated version of present Safety Analysis document)l. Audit reports: checks on software and design documentation

6 Verification of Safety Requirements

Safety will be verified in the System ATP, based on the SALT Safety Analysis document.

7 Telescope Handover

Handover will be progressive, as parts of the telescope are completed. There will be two levels ofhandover:

a. Preliminary handover: When a part of the telescope has been commissioned and is essentiallycomplete, the appropriate maintenance person would not only take control of that equipment andperform all scheduled maintenance, but would also be the “first line of defence” for call-outs whensomething goes wrong. The SALT team and sub-contractors would provide back-up only.

b. Final handover: When that telescope part has been fully integrated and no further changes to thatitem a expected, then it can be handed over to the maintenance team. At this point the maintenanceteam (SAAO) fully accept responsibility for the item. Documentation and training need to be in placebefore this can occur.

A record will be kept of equipment handed over to prevent misunderstanding in this regard.

8 Documentation

All design, construction, test and operational documentation is filed in the SALT filing system and/or has anelectronic copy in the Configured document archive. The “Configured Document Database” provides anindex for this documentation.

9 Configuration Control

It is important not to lose control of changes during the commissioning process and to know which specificversion of the system was tested in a particular test. It is also important to ensure that the documentation isupdated to reflect such changes as they may influence the maintenance and operation of the telescope. Tothis end, a formal Change Control Procedure will be implemented once a subsystem has been integratedwith the TCS.



14

Appendix A: Project Milestones