provisional acceptance test procedure - dkist

615 Epsilon Drive, Pittsburgh, PA, USA 15238

Phone: 412.967.7700 Fax: 412.967.7973

www.L-3Com.com/IOS

L-3 COMMUNICATIONS –IOS PROPRIETARY

L3 Communications, IOS reserves all rights in connection with this document and in the subject matter represented therein. The recipient

hereby acknowledges these rights and shall not, without permission in writing, disclose or divulge this document in whole or in part to third

parties or use it for any purpose other than that for which it was delivered to recipient.

WARNING: This technical data is controlled under the Export Administration Regulations (EAR) and may not be exported to a Foreign

Person, either in the U.S. or abroad, without proper authorization by the U.S. Department of Commerce.

DESTRUCTION NOTICE: Destroy by any method that will prevent disclosure of contents or reconstruction.

Registered by NQA to ISO 9001:2008

ATPr-32610 Initial Issue

ATST TEOA

Control System

ACCEPTANCE TEST PROCEDURE Part No (s). 302028

Serial Number: Rev B (v1.0.0)

Contract # ________________

Customer: AURA

November 2014

Approval Name Signature Date

Responsible Systems Engineer: Sandra Bader

Reviewer: Michael Bock

Project Engineer: Steve Mix

Quality Assurance: Sue Franciscus

Program Manager: Craig Peton

615 Epsilon Drive, Pittsburgh, PA, USA 15238

Phone: 412.967.7700 Fax: 412.967.7973

www.L-3Com.com/IOS

L-3 COMMUNICATIONS –IOS PROPRIETARY

L3 Communications, IOS reserves all rights in connection with this document and in the subject matter represented therein. The recipient

hereby acknowledges these rights and shall not, without permission in writing, disclose or divulge this document in whole or in part to third

parties or use it for any purpose other than that for which it was delivered to recipient.

WARNING: This technical data is controlled under the Export Administration Regulations (EAR) and may not be exported to a Foreign

Person, either in the U.S. or abroad, without proper authorization by the U.S. Department of Commerce.

DESTRUCTION NOTICE: Destroy by any method that will prevent disclosure of contents or reconstruction.

Registered by NQA to ISO 9001:2008

Revision Description Date Name Initials

--- TEOACS related requirements

testing

10/8/14 Michael Bock MB

ATPR-32610 TEOACS Test Procedure

This page is subject to the disclosure and distribution restrictions on the cover page.

3

Include a summary of the test results, conclusions, and recommendations. Comments

in this section should be limited to explanations or rationale as to why the TEOA has

not passed ATP and notes that do not directly address unusual anomalies that would

not impact ATP results.

ATPR: ___________ Pass/Fail

Test Engineer ___________________________ Date: __________ Quality Assurance ________________________ Date: __________ Customer________________________________ Date: __________



4

TABLE OF CONTENTS

1 SCOPE ..................................................................................................... 6

2 REFERENCE DOCUMENTS .................................................................... 7

2.1 AURA documents ...................................................................................................................... 7

2.2 L-3 Communications IOS Brashear Documents ..................................................................... 7

3 TEOACS ATP OVERVIEW....................................................................... 8

3.1 Acryonyms/Abbreviations ........................................................................................................ 8

3.2 Test setup .................................................................................................................................... 9

3.3 Configuration Log ................................................................................................................... 10

3.4 System Reset Script ................................................................................................................. 11

3.5 Golden standard output logs .................................................................................................. 12

3.6 Important Paths ....................................................................................................................... 12

3.7 Scripting Tool........................................................................................................................... 12

4 VERIFICATION PROCEDURES ............................................................ 13

4.1 High Level Requirments Verification .................................................................................... 13 4.1.1 Engineering User Interface ................................................................................................ 14 4.1.2 Lyot Stop Positioning ........................................................................................................ 16 4.1.3 Default State and Global Interlock .................................................................................... 18 4.1.4 Restart ................................................................................................................................ 21 4.1.5 Health ................................................................................................................................ 23 4.1.6 Logging.............................................................................................................................. 24 4.1.7 Availability ........................................................................................................................ 25 4.1.8 Data Persistence ................................................................................................................. 27 4.1.9 Diagnostic Features ........................................................................................................... 28

4.2 ICD 1.3-4.4 Verification Procedures ...................................................................................... 29 4.2.1 TEOACS Top Level Attributes ......................................................................................... 29 4.2.2 M2 Positioner Attributes ................................................................................................... 30 4.2.3 M2 Tip-Tilt Attributes ....................................................................................................... 31 4.2.4 Lyot Stop Attributes .......................................................................................................... 32 4.2.5 TEOACS Top Level Event Verification ............................................................................ 33 4.2.6 M2 Positioner Event Verification ...................................................................................... 34 4.2.7 M2 Tip-Tilt Event Verification ......................................................................................... 35 4.2.8 Lyot Stop Event Verification ............................................................................................. 36 4.2.9 Final Demand Math Passive .............................................................................................. 37 4.2.10 Final Demand Math Active ............................................................................................... 39 4.2.11 M2 Hexapod Passive AO Mode Behavior ......................................................................... 40 4.2.12 M2 Hexapod Active AO Mode Behavior .......................................................................... 42 4.2.13 M2 Hexapod Named Position and Limits behavior ........................................................... 43



5

4.2.14 M2 Tip-Tilt Passive and Active AO Mode Behavior ........................................................ 45 4.2.15 M2 Tip-Tilt Limb Tracking Mode Behavior ..................................................................... 46 4.2.16 M2 Tip-Tilt Named Position and Limits behavior ............................................................ 47 4.2.17 Lyot Stop Behavior ............................................................................................................ 48 4.2.18 Shutdown and Un-initialization ......................................................................................... 51 4.2.19 Engineering User Interface ................................................................................................ 54

4.3 ICD 1.3-2.3 WCCS Verification Procedures ......................................................................... 56 4.3.1 M2 Hexapod WCCS subscription...................................................................................... 57

4.4 ICD 1.3-2.5 Verification Procedures ...................................................................................... 59 4.4.1 Electronics Interface .......................................................................................................... 59 4.4.2 M2 Tip-Tilt Limb tracking Mode Enabled ........................................................................ 60 4.4.3 M2 Tip-Tilt Limb tracking Mode Disabled ....................................................................... 61

4.5 Inspections ................................................................................................................................ 62 4.5.1 Best Software Practices ..................................................................................................... 62 4.5.2 Secure communications ..................................................................................................... 64

5 CONCLUSION ........................................................................................ 65

5.1 Test Review .............................................................................................................................. 65

APPENDIX A. CONFIGURATION LOG FORM ......................................... 67

APPENDIX B. STARTING THE TEOACS ................................................. 69

Appendix B.1. TEOACS startup procedure .................................................................................. 69

Appendix B.2. TEOACS Manual Restart Procedure .................................................................... 70

Appendix B.3. TEOACS Software Restart Procedure .................................................................. 70

Appendix B.4. TEOACS Auto Restart Procedure ........................................................................ 71

Appendix B.5. TEOACS Equipment Startup/shutdown Procedure ............................................ 72 Appendix B.5.1. Equipment Startup .............................................................................................. 72 Appendix B.5.2. Equipment Shutdown .......................................................................................... 73

Appendix B.6. Containers................................................................................................................ 73

APPENDIX C. GOLDEN STANDARD OUTPUT LOGS............................. 74

Appendix C.1. Listing of Golden Std Logs ..................................................................................... 74



6

1 SCOPE

This document provides step by step procedures that verify the requirements

identified in SPEC-0008 related to TEOACS only. The PLC based TEOA-TMS

software is tested as part of ATPr-32576 Heat Stop Assembly and ATPr- 32575 M2

Assembly.



7

2 REFERENCE DOCUMENTS

2.1 AURA DOCUMENTS

SPEC-0001, Science Requirements Document,

SPEC-0005, Software Design Requirements,

SPEC-0012, ATST Glossary and Acronym List,

SPEC-0013, Software Concepts Definition,

SPEC-0019, Telescope Control System Specification,

SPEC-0021, Telescope Control System Design Document,

SPEC-0022, Common Services Framework Reference Manual,

SPEC-0008, Top End Optical Assembly Specification,

TN-0088, Base Software for Control Systems,

TN-0089, Java Engineering Screens User Manual

ICD 1.1-4.4, TMA to TCS

ICD 1.3-2.3, Top End Optical Assembly to Wavefront Correction Control System

ICD 1.3-2.5, Top-end Optical Assembly to Wavefront Correction Limb Tracker

ICD 1.3-4.4, Top End Optical Assembly to Telescope Control System

2.2 L-3 COMMUNICATIONS IOS BRASHEAR DOCUMENTS

SDD-32506, Software Design Document

302028, TEOA Controller Software (TEOACS) PN.

302029, TEOA PLC Software (TEOA-TMS) PN.

IOS-TEOA-AR-012, M2 Thermal Control Equipment & Component Discussion

IOS-TEOA-AR-013, M2 Thermal Control System

IOS-TEOA-AR-014, M2 +X Platform Equipment Thermal Control



8

3 TEOACS ATP OVERVIEW

The TEOA Control System (TEOACS) operates the hexapod, fast-tip tilt and lyot

stop mechanisms located at the TEOA. The Telescope Control System (TCS)

controls and monitors the TEOACS through the published interface (ICD-1.3/4.4).

The TEOACS acts as the interface and high-level control system between the

Telescope Control System (TCS) and the mechanical systems located at the Top End

Optical Assembly (TEOA). This test document covers all requirements that pertain

to the TEOACS.

3.1 ACRYONYMS/ABBREVIATIONS

Table 3.1-1 below shows a list of abbreviations/acronyms. For a more complete list

related to all of ATST see SPEC-0012.

Table 3.1-1 Table of abbreviations/acronyms

Abbreviation/Acronym Description

ATST Advanced Technology Solar Telescope

ASDT ATST Software Development Tree

API Application Programming Interface

AURA Association of Universities for Research in Astronomy

CM Container Manager

COTS Commercial Off the Shelf

CSF Common Services Framework

F-ATP Factory Acceptance Tests Plan

FCS Facilities Control system

FDR Final Design Review

FMS Facility Management System

FTT Fast Tip Tilt

GIS Global Interlock System

GUI Graphical User Interface

ICD Interface Control Document

JES Java Engineering Screens

JNI Java Native Interface

JVM Java Virtual machine

L3B L-3 IOS Brashear

LIT Linear Interpolative Table

LUT LookUp Table

M2 Mirror #2 (Secondary Mirror)

OCS Observatory Control System

PDR Preliminary Design Review

PI Physik Instrumente

PLC Proportional/Integral/Derivative control

SDD Software Design Description

SOW Statement of Work

TAB Technical Architecture Block

TCS Telescope Control System

TEOA Top End Optical Assembly

TEOACS Top End Optical Assembly Control System

TEOA-TMS Top End Optical Assembly Thermal Management System

TMA Telescope Mount Assembly

MCS Mount Control System

UML Unified Modeling Language

WCCS Wavefront Conditioning Control System

WFC Wavefront Control – Adaptive Optics



9

3.2 TEST SETUP

The test setup for the TEOACS testing is based on the TEOA block diagram seen in

Figure 3.2-1 below.

Figure 3.2-1 ATST/TEOACS block diagram

Each ATST subsystem block in Figure 3.2-1 above relating to the TEOACS that is

grey is not available in its true form at the L3 TEOACS testing area. A suitable

simulation of those components has been made to connect to the real TEOACS

system.

The test setup used throughout this ATP can be seen below in Figure 3.2-2.



10

Figure 3.2-2 Test Setup for TEOACS testing

3.3 CONFIGURATION LOG

Use the configuration log to log the software version number, build date and active

log file after restarting the TEOACS software for any tests. In addition to restarts an

entry in the configuration log shall be made at the beginning of execution of the first

test performed in this procedure, at each major break such as lunch and at the end of

testing. However, an entry does NOT need to be made for each test performed as

long as that test did not precede, follow or include a restart of the TEOACS software.

The configuration log form can be seen in Appendix A. Print out as many blank

copies as needed for the testing at hand. The log will form part of the test record at

the completion of the testing. The procedure for making an entry in the log is seen in

the enumerated steps below.

1. Enter the date and time of log entry in the “Date/Time” column of the

configuration log.

2. From the Testharness command prompt execute the “showMC.th” script by

entering

“run showMC.th”.

3. From the output visible in the currently active log window that resulted from

the script run in the previous step record the software version and build date in

the “Version” and “Build Date” columns of the configuration log

respectively.

4. From the Testharness command prompt execute the “displayLogFilename.th”

script by entering

“run displayLogFilename.th”.

Physik Instrumente

M-850 Hexapod

Controller

Physik Instrumente

E-712/711 Digital

Piezo Controller

Lyot Stop actuator

and position sensors

TEOA Client

CSF SERVER

CSF

Equipment

Legend

Hardware

HW Connection

Test Network

Acromag 983EN

Digital I/O Ethernet

Module

Hexapod Hardware Fast Tip-tilt Stage



11

5. From the output visible in the Testharness command window that resulted

from the script run in the previous step record the currently active log

filename in the “Log File” column of the configuration log.

6. Write any comments that are pertinent to the configuration log entry. One

useful thing to put in the comments is a list of test sections performed while

the entry was valid.

3.4 SYSTEM RESET SCRIPT

The system reset script (‘systemReset.th’) is seen below in Figure 3.4-1. Use it to

reset the system to a known state. This script is called out by various procedures

throughout the rest of this docment.

Figure 3.4-1 Listing of the system reset script



12

3.5 GOLDEN STANDARD OUTPUT LOGS

Select tests use a process of comparing the current test log with an existing log

showing the agreed upon behavior. Please see Appendix C for more information.

3.6 IMPORTANT PATHS

In the ATST development tree these are important paths relevant to TEOACS.

Table 3.6-1 Table of TEOACS related paths

Linux Environment Variable Path and Description

$ATST On some systems “/opt/atst”. This is configurable system to system.

$ATSTDEV $ATST/src/java/atst

$TEOACS $ATSTDEV/teoacs

$TSCREENS $ATST/resources/screens/teoacs

3.7 SCRIPTING TOOL

Testharness is a command line application that is designed to work with all aspects of

the CSF environment. Testharness is the tool used in the procedures in this document

to run test scripts.

One important limitation of Testharness is the behavior of the default listener. One

can add events to listen to and quiet the listener when one is done. However, you

cannot remove an event to be listened to. This additive only behavior means that it

may be difficult to observe the fields of interest in an event of interest during a given

test because the previous test needed the default listener for a different event.

Therefore, it is recommended that any test requiring the Testharness default listener

should restart the Testharness.

Testharness is customized for TEOACS on the CSF server dunn so that the default

‘macros.th’ script is run at the start and subsequently calls the ‘startupTeoa.th’ script.

This script in turn calls a number of sub-scripts. The most important work done by

the ‘startupTeoa.th’ script is bring all the TEOACS controllers from the ‘Loaded’

lifecycle state, through the ‘Initialized’ lifecycle state to the ‘Running’ lifecycle state.

If Testharness is restarted after the TEOACS controllers have achieved the ‘Running’

lifecycle state the work done by ‘startupTeoa.th’ should not interfere with the current

state of the controllers. The requests to go through the lifecycle state transitions listed

above will be ignored.

To read more about Testharness see the ‘Tools.pdf’ document that comes with every

ASDT located in the path ‘$ATST/doc/guides’.

The



13

4 VERIFICATION PROCEDURES

The sub-sections below contain the test procedures necessary to verify compliance with requirements in force for the TEOA contract. The

sections are divided into four major categories: high level requirements, ICD 1.3-4.4 TEOACS to TCS, ICD 1.3- 2.3 WCCS to TEOACS and

ICD 1.3-2.5 WFCLT to TEAOCS. The high level requirements section goal is to verify all the requirements related to the TEOACS in

SPEC-0008. The ICD sections deal with specific behavior called out in each of the ICDs. Note all mentions of the ‘system reset script’ in the

procedures below refer to section 3.4 System Reset Script.

4.1 HIGH LEVEL REQUIRMENTS VERIFICATION

The test procedures below are bound to requirements seen in SPEC-0008.

Requirement 1.3.3-0005

The TEOACS and TEOA-TMS shall comprise the software, firmware, and control systems required to operate the TEOA and meet all

specifications and interface requirements. It shall include all computing hardware necessary to perform the required operations. The

TEOACS shall control the operation of the M2 Mirror Position System, the M2 Fast Tip and Tilt System, and the Lyot Stop Assembly. The

TEOA-TMS shall control the M2 Thermal Controller, and the Heat Stop Assembly.

Verification Procedure:

Review all subsequent sections in the ATP to verify that all TEOACS requirements are met.

_____________________ Pass/Fail

Responsible Engineer____________________ Date____________________

Customer______________________________ Date____________________



14

4.1.1 Engineering User Interface


The TEOA shall supply an engineering user interface that implements all functional operations of the TEOA as defined by the interfaces to the TCS and

WCCS (ICD-1.3/4.4 and ICD-1.3/2.3) and shall be useful for actual operations within the ATST. The engineering user interface shall reside on a separate

computer from the TEOACS and use the Common Services Framework to communicate with the TEOACS.


The TEOACS shall use Coordinated Universal Time (UTC) in all displays and status.


This test shows that the Engineering user interface is present and functional by issuing some basic commands. It also demonstrates that the

TEOACS uses UTC time in all displays and status. Note that this test only demonstrates compliance with a portion of 1.3.3-0310. A more

rigorous test on the Engineering User Interface is done as part of section 4.2.19. The client and server machines are off network and therefore

have no NTP server connected. Therefore, the UTC time will only be approximate.

Figure 4.1-1 Load Table button



15

Step Action System Response

1. If the system is not up and running, start up the system using the

startup procedure located in section Appendix B.1.

TEOACS computers start up.

2. Reset the System Configuration per the system reset script . System Reet Configuration.

3. Navigate to the ‘M2 Hexapod’ tab on the TEOACS Engineering

GUI.

NONE

4. Click the ‘Load Table’ button underneath the ‘Clear’ button

(see Figure 4.1-1).

A dialog box titled ‘Open’ is presented to the user.

5. Choose the ‘EngGui411’ table file from the $TSCREENS

directory.

GUI displays the contents of the ‘EngGui411’ configuration inside the

configuration widget on the M2 Hexapod tab.

6. Observe the time and date on the engineering GUI. Time and date are formatted in the following manner:

‘YYYY-MM-DD hh:mm:ss GMT’.

7. Verify that the time agrees within a few minutes of current UTC

time. Use an agreed upon means for verification (for instance

using htttp://time.is/UTC)

N/A

8. Satisfies restart requirement 1.3.3-0020. No system restart should have resulted from executing this test.

_____________________ Pass/Fail


Customer______________________________ Date____________________



16

4.1.2 Lyot Stop Positioning

Requirement 1.3.2.6-0020

The Lyot Stop shall be remotely deployable into position, corresponding to the position of the pupil in M2 space, controlled by the TEOACS on command

of the TCS.

Requirement 1.3.3.3-0220

The TEOACS shall move the Lyot stop between its defined positions. The motion shall be at the command of the TCS or the engineering user interface. The

TEOACS shall monitor the deployment of the Lyot stop and report any changes in status.


This test shows that the lyot stop is able to move and when moved all of its position indicators are consistent. Restart the Testharness tool

(see section 3.7 for default listener discussion).


1. Reset the System Configuration per the system reset script. System Reset Configuration.

2. Using the TEOACS Engineering GUI navigate to the “Lyot

Stop” tab.

The GUI displays the “Lyot Stop” tab.

3. Toggle power off using the TEOACS Engineering GUI

configuration called ‘lyotPowerOff’ (located in $TSCREENS)

as accessed via the configuration widget on the Lyot Stop tab.

The Lyot stop software controller transitions from the power ‘on’ state to the

power ‘off’ state.

4. Run the ‘listenLyotStatus.th’ Testharness script. The Testharness application begins to display the atst.tcs.teoacs.lyot.cStatus

event.

5. Select the load table button on the configuration widget and

choose the “lyotPowerOn” file from the $TSCREENS directory

(see Table 3.6-1). Click the “Open” button on the dialog and

then click “Submit” on theconfiguration widget.

The lyot stop software controller issues the appropriate hardware specific

messages related to the ‘power’ attribute. The ‘Current Power’ indicator on the

screen will change from ‘off’ to ‘on’. The ‘Current Position’ indicator will

transition from ‘out’ to ‘in_transit’ and then back to ‘out’. The lyot stop should

NOT move.

6. Verify that all indicators of lyot stop position monitored via the

‘listenLyotStatus.th’ script and the GUI (including the pressure

sensor information) are consistent with the ‘out’ position and

power ‘on’ condition..

The status observed in the Testharness window shows data consistent with the

’out’ position and power ‘on’ condition for all indicators.



17


7. From the ‘Lyot Stop’ tab on the TEOACS Engineering GUI

select the load table button on the configuration widget and

choose the “lyotConfigPwr_on_Pos_in” file from the

$TSCREENS directory. Click the “Open” button on the dialog

and then click “Submit” on the configuration widget.

The ‘Current Position’ indicator will transition from ‘out’ to ‘in_transit’ and

then to ‘in’’. The lyot stop should move.

8. Verify that all indicators of lyot stop position monitored via the

‘listenLyotStatus.th’ script and the GUI (including the pressure

sensor information) are consistent with the ‘in’ position.

The status observed in the Testharness window shows data consistent with the

‘in’ position and power ‘on’ condition for all indicators.

9. Quiet the default listener with the ‘deflis – q’ command. The Testharness application stops displaying the atst.tcs.teoacs.lyot.cStatus

event.

10. Satisfies restart requirement 1.3.3-0020. No system restart should have resulted from executing this test.

_____________________ Pass/Fail


Customer______________________________ Date____________________



18

4.1.3 Default State and Global Interlock


The TEOACS shall have a defined default state for all TEOA hardware and equipment that it controls. Equipment shall be in this state during an interlock

condition, after power-up and software initialization, or when demanded through the software interface. The default state of any TEOA equipment shall be

an inert, non-moving, non-powered condition.


The TEOACS shall detect and respond to a global interlock signal. Upon receiving the GIS signal the TEOACS shall stop all ongoing actions in the

TEOA, reject all queued and incoming configurations, disable all controlled mechanisms, and move to the defined default state.

The TEOACS shall not be required participate in any safety-critical operations to ensure the safety of the equipment or personnel. All safety-related

activities shall be the sole responsibility of the GIS.


This test verifies the default state for the software can be achieved by the three different means shown in the requirement. Note: none of the

‘power’ attributes associated with the TEOACS controllers correspond to real power to the equipment since hardware for toggling power is

not available to the TEOACS. Therefore, the ‘power’attributes have been mapped to software enables instead. The default state is defined as

the following:

TEOA Manager:

AO Mode is OFF

Hexapod and FTT:

Mode and AO Mode is OFF

State is “parked”.

Power is “off”



19

FTT only

LimbTracking Mode is OFF

Lyot Stop:

State is “off”

Power is “off”

This test will use a combination of the engineering gui and test scripts. This test will cover all three ways of entering the default state. That is

either by an interlock condition, startup of the software or through a submission of aoMode of OFF. The L-3 event simulator will be used to

generate the interlock condition.


1. Reset the System Configuration per the system reset script. System Reset Configuration.

2. Verify that the AO mode to PASSIVE . TEOACS reports AO Mode ‘passive’ via ‘Mode’ drop down selector in lower

right of GUI screen, the ‘Ao Mode M2Pos’ field on the ‘M2 Hexapod’ tab of

the GUI screen and the ‘Ao Mode M2TT’ field on the ‘M2FTT’ tab of the GUI

screen

3. Assert an interlock condition in the TEOACS by using the

“raiseInterlock.th” script.

All TEOACS controllers show an interlock condition. Interlock related health

status should be reported by all controllers on the bash shell and the GUI.

4. Verify all sub-controllers have reached the defined Default state

by using the ‘showM2.th’, ‘showMC.th’, ‘showMT.th’ and

‘showLyotStop.th’ scripts.

Output is displayed on the screen corresponding to each script.

5. Compare the output from the scripts that show up on the screen

to the defined default states shown in the Overview section of

this test (before this table).

NONE.

6. Send a configuration down to each sub controller and verify that

the configuration is rejected by the TEOACS.

All TEOACS sub controllersrejects the incoming configuration while

interlocked.

7. Lift the interlock condition from the TEOACS by using the

“lowerInterlock.th” test script.

All TEOACS controllers leave the interlocked condition. Interlock related

health status

8. Repeat steps 2 – 7 except for step 2 choose AO mode ACTIVE

instead of PASSIVE.

System response same as steps 2 – 6 with the exception that the TEOACS will

report AO Mode ‘active’ for step 2.



20


9. Repeat steps 2 – 7 except for step 2 choose AO mode PASSIVE

and have an active and long running configuration being

processed when starting step 3 with a queued configuration

ready just behind it..

The TEOACS rejects the queued configuration while interlocked.

10. Shutdown the TEOACS by following the shutdown only

instructions in Appendix B.2 TEOACS Manual Restart

Procedure. Turn off both CSF client and server. Note: the test

operator can use an ssh window from the CSF server to

accomplish this.

The TEOACS controllers transition through the lifecycle states to finally reach

the “unloaded” state. Note: when using Canary 7-2 release of the CSF the the

container manager will hang when issuing a ContainerManger start or stop

command.

11. Once shut down wait 10 seconds and then restart both CSF

client (‘teoaClient’ and server) and log in.

The CSF client ‘teoaClient’ and CSF server ‘dunn’ goes through the boot up

process. Login credentials are supplied to each machine to start them.

12. Restart the TEOACS software (should be automatic at startup

save for any startup bugs that may be present in CSF) and

launch Testharness (see Appendix B.1 TEOACS startup

procedure) for more details. Ensure that all teoacs sub-

controllers enter the defined default state.

The TEOACS software is restarted and lifecycle state ‘Loaded’ is achieved.

Upon launch of ‘Testharness’ the TEOACS controllers should achive Lifecycle

state ‘running’ with each controller in the defined default state.


by using the ‘showM2.th’, ‘showMC.th’, ‘showMT.th’ and

‘showLyotStop.th’ scripts.

Output is displayed on the screen corresponding to each script.




NONE

15. Reset the System Configuration per the system reset script. System shows Reset Configuration (see section 3.4).

16. Verify that the AO mode to PASSIVE . TEOACS reports AO Mode ‘passive’ via ‘Mode’ drop down selector in lower

right of GUI screen, the ‘Ao Mode M2Pos’ field on the ‘M2 Hexapod’ tab of

the GUI screen and the ‘Ao Mode M2TT’ field on the ‘M2FTT’ tab of the GUI

screen

17. Set the AO mode to OFF by using the ‘Mode’ drop down

selector and choosing the ‘off’ option.

TEOACS reports AO Mode ‘off’. All TEOACS controllers achieve the Default

state.


by using the ‘showM2.th’, ‘showMC.th’, and ‘showMT.th’

scripts.

Output is displayed on the screen corresponding to each script. The lyot stop

does not have behavior linked to ao Mode therefore lyot stop may not be in the

default state.



21





NONE.

20. Satisfies restart requirement 1.3.3-0020. TEOACS controllers were only shut down on command during this procedure.

Shutdown and/or start up was successful (save the ContainerManager hanging

bug found in Canary 7-2/7-1).

_____________________ Pass/Fail


Customer______________________________ Date____________________

4.1.4 Restart


The TEOACS shall perform all requests sent through its interface without need of reboot or re-initialization, unless the request demands such an

operation.


This test will be broken up into two major sub headings: requests that do NOT demand a restart and requests that DO require a restart. For

requests that do NOT demand a restart the test conductor will perform all the other tests in this document. At the end of every test where a

restart is not expected the test conductor will validate that no restart was necessary beyond those restarts that may be specified during the

course of the test. Each relevant test section will have a “Satisfies restart requirement 1.3.3-0020” check mark at the end.

For the requests that DO require a restart the test conductor will demonstrate that for each example the software handles the case gracefully

and places log messages in the log database that a restart is required.



22

_____________________ Pass/Fail


Customer______________________________ Date____________________



23

4.1.5 Health


The TEOACS shall be able to determine whether the current state of the TEOA is within operational specifications. The TEOACS shall have defined health

categories that are tied to the ATST Health Service. These health categories shall be checked at regular intervals that will be determined based on the

overall needs of the system. The TEAOCS shall test that all equipment is operating within specification as required by the current conditions and state of

the TEOA. The TEOACS shall report with specificity any problems with its equipment and systems that cause degraded performance or non-performance.


It shall report and log errors and faults when operational performance is not achieved.


Verify the TEOACS health system is active and working as designed by using a combination of test scripts, engineering GUI and real faults.

1. Use the ‘injectFault_m2pos.th’ script to inject a fault into the m2pos controller.

2. Observe on the engineering GUI or test log the health status changing for the m2pos controller.

3. Use the ‘showFaultTable_m2pos.th’ script to show the entire fault table for the m2pos controller. Observe fault information showing

up in the log.

4. Use the ‘showFault_m2pos.th’ script to show the fault status for the particular fault injected.

5. Use the ‘healTestFault_m2pos.th’ script to heal the injected fault.

6. Repeat the steps above with scripts named *_m2tt.th, *_lyot.th and *_mc.

7. Demonstrate the communications down health category for all controllers for real by pulling the associated Ethernet cable for each of

the three sub-controllers (m2pos, lyot and m2tt). Note: a restart may be required after this step as m2pos and m2tt controllers only

have a limited amount of time where they can recover from a comms down fault.

_____________________ Pass/Fail



24


Customer______________________________ Date____________________

4.1.6 Logging


The TEOACS shall log pertinent data to the ATST facility log mechanism. Pertinent data shall include state changes, configuration changes, errors,

alarms and warnings, and any other information that may assist in reconstructing the operation of the TEOACS and TEOA Assemblies. The TEOACS

logging level shall be user selectable for the depth of information, per the ATST logging facility definitions of logging levels.


Verify TEOACS logging capability by using test scripts and the engineering GUI.

1. Reset the system to a known state using the ‘systemReset.th’ script.

2. View the log information displayed in the steps below via the active tail session. If the tail session has been closed then use the script

named ‘tailLog.th’ to reopen.

3. Use the ‘toggleLogLevel_m2pos.th’ and individual Testharness commands (log command) to toggle logging levels and show

changing amount of logging activity into the log for the TEOA.SIM container (see Appendix B.6 Containers)

4. Using the logging widget on the TEOA engineering GUI filter the logs bases on level and category.

5. Repeat the steps above using the ‘toggleLogLevel_*.th’ scripts where * is either mc, lyot or m2tt.

_____________________ Pass/Fail


Customer______________________________ Date____________________



25

4.1.7 Availability


The TEOACS shall always be available to accept or reject commands. The TEOACS shall not block any command request while processing another

command request.


Verify the availability requirement above by using the procedure below which tests two general cases: simultaneous accepted submissions

and simultaneous accepted/rejected submission pairs. The first will be a case of simultaneous accepted submissions to two different sub-

controllers. The second will be simultaneous submissions to two different sub-controllers. One submission will be accepted while the other

will be rejected. Note that TEOACS sub-controllers (workers_ are allowed to only perform one action at a time while the manager top level

controller must be available to support simultaneous actions.


2. Open the property editor and verify that the number of simultaneous actions (*.csf:numThreads property) for the management

controller (atst.tcs.teoacs) is set to a number greater than 1 (5 – 10 is the recommended range).

3. Open the property editor and verify that the maximum number of simultaneous actions (*.csf:maxThreads property) for the

management controller (atst.tcs.teoacs) is set to a number greater than 1 (5 – 10 is the recommended range) and is greater than the

*.csf.numThreads property checked in the last step.

4. Run the ‘availabilityAccepted_mc.th’ script to test simultaneous accepted submissions.


6. Run the ‘availabilityRejected_mc.th’ script to test simultaneous accepted/rejected submission pairs.



26

_____________________ Pass/Fail


Customer______________________________ Date____________________



27

4.1.8 Data Persistence


Static information required by the TEOACS to operate shall be recoverable after a restart or reboot. This information may include, but is not limited to:

zero points, lookup tables, and configuration parameters. Dynamic information, such as current position and state, may be reset or recovered after

initialization. Static information shall be stored through the ATST Property Service or parameter set database.


Verify the data persistence requirement above by using the procedure below which involves a shutdown/restart cyle of the teoacs.

1. View the existing log in an editor of your choice and observe the very start of the log where the system was initially started. In that

area of the log is a list of properties for each controller as they are during startup.

2. Copy the section of interest with the properties under review to a temporary file.

3. Cause the m2pos controller to move and change it’s position.

4. Restart the TEOACS system and observe the startup area in the log after loading the new log in the editor of your choice.

5. Go to passive mode by selecting ‘passive’ from the combo box in the lower right hand corner of the GUI labled ‘Mode’ and verify the

teoacs goes to the last position recorded prior to shutdown.

_____________________ Pass/Fail


Customer______________________________ Date____________________



28

4.1.9 Diagnostic Features


The TEOACS and TEOA-TMS shall monitor all aspects of the TEOA to ensure proper operation. In the event of a system malfunction, the TEOACS and

TEOA-TMS shall provide sufficient information to allow the telescope operator to diagnose the problem. The TEOACS and TEOA-TMS shall have

diagnostic instrumentation to include but not be limited to the following:

• Safety – Any problem with the Heat Stop Assembly that could in any way threaten the security or safety of the telescope or personnel shall be provided by a fail-safe communications link

to the GIS.

• Health – The functions of the Heat Stop Assembly shall be monitored during telescope operation by the TEOA-TMS and any malfunction communicated to the FMS. This shall include

output of thermal sensors and operation of any heat exchangers.

• Status – TEOA CS system status information pertinent to the scientific observations related to the TEOACS shall be recorded as defined by the ATST Header service. This information

shall include the M2 Mirror position as reported by the hexapod controller. However, TEOA thermal information such as ambient air-to-M2 Mirror optical surface temperature difference

gathered by the TEOA-TMS and shall be sent to FMS according to TEOA to FMS ICD.


Verify the Diagnostic features as pertaining to the TEOACS with the procedure below. The health and safety portion of the requirement

above is covered in another ATP.

1. Verify that the M2 mirror positions are available via a “get operation” which is used in conjunction with the ATST header service.

The TEOACS engineering GUI uses “get” operations for displaying these data items. This is done via the ‘headerGet.th’ script.

2. Go into edit mode on the TEOA engineering GUI and show the linkage of the m2 position data items to the m2pos csf controller. This

linkage should reveal those relevant GUI elements to be doing a “get” operation at a specified frequency.

_____________________ Pass/Fail


Customer______________________________ Date____________________



29

4.2 ICD 1.3-4.4 VERIFICATION PROCEDURES

This section mainly deals with requirement 1.3.3-0300


The TEOACS shall provide an interface to the Telescope Control System (TCS) as defined by ICD-1.3/4.4. The TEOACS is a subsystem of the TCS, and as

such, obeys and performs all commands issued from the TCS.

4.2.1 TEOACS Top Level Attributes

ICD Paragraph # 4.8

This section describes those attributes that the TCS can send to the top level TEOACS controller that are intended for the top-level controller only.


This test shows the TEOACS top level controller software contains the required attributes specified by ICD 1.3-4.4 by viewing those

attributes in the property database and displaying those attributes in the currently active log.


1. Open the PropertyEditor tool on the CSF server ATST PropertyEditor opens

2. Compare the table seen in section 4.8 in ICD 1.3-4.4 to the

attributes for the controller called ‘atst.tcs.teoacs’. Ensure the

attributes seen in the PropertyEditor window contain the

attributes listed in section 4.8 (Note: attributes seen in the

PropertyEditor should contain at least those listed in ICD but

may contain more).

NONE

3. Ensure that the TEOACS software is in Lifecycle state running.

If the TEOACS needs to be restarted do so at this time.

Lifecycle state = RUNNING

4. Run the “showMCAtt.th” Testharness script The TEOACS logs all the properties for this controller to the active log file.

5. Review the currently active log for those attributes in section

4.9 of ICD 1.3-4.4. Ensure the attributes logged contain the

attributes listed in section 4.8.

NONE

6. Satisfies restart requirement 1.3.3-0020. No restart was necessary beyond a restart that may have been necessary due to

starting conditions.



30

_____________________ Pass/Fail


Customer______________________________ Date____________________

4.2.2 M2 Positioner Attributes

ICD Paragraph # 4.9

This section describes those attributes that the TCS will send to the top-level controller that involve the M2 positioner controller (atst.tcs.teoacs.m2pos).


This test shows the TEOACS m2 positioner controller software contains the required attributes specified by ICD 1.3-4.4 by viewing those



1. Open the PropertyEditor tool on the CSF server ATST PropertyEditor opens.

2. Compare the table seen in section 4.9 in ICD 1.3-4.4 to the

attributes for the controller called ‘atst.tcs.teoacs.m2pos’.

Ensure the attributes seen in the PropertyEditor window contain

the attributes listed in section 4.9 (Note: attributes seen in the

PropertyEditor should contain at least those listed in ICD but

may contain more).

NONE




4. Run the “showM2Att.th” Testharness script The TEOACS logs all the properties for this controller to the active log file.

5. Review the currently active log for those attributes in section

4.9 of ICD 1.3-4.4. Ensure the attributes logged contain the


NONE



31



starting conditions

_____________________ Pass/Fail


Customer______________________________ Date____________________

4.2.3 M2 Tip-Tilt Attributes

ICD Paragraph # 4.9 and 4.10

This section describes those attributes that the TCS will send to the top-level controller that involve the M2 tip-tilt controller (atst.tcs.teoacs.m2tt). The

attributes that can be set on this controller are given in the table below and the table in section 4.9 (note this controller has the M2 positioner attributes as

a subset of it’s own).


This test shows the TEOACS m2 tip-tilt controller software contains the required attributes specified by ICD 1.3-4.4 by viewing those




2. Compare tables seen in section 4.9 and 4.10 in ICD 1.3-4.4 to

the attributes for the controller called ‘atst.tcs.teoacs.m2tt’.

Ensure the attributes seen in the PropertyEditor window contain

the attributes listed in sections 4.9 and 4.10.

NONE




4. Run the “showMTAtt.th” Testharness script The TEOACS logs all the properties for this controller to the active log file.



32


5. Review the currently active log for those attributes in sections

4.9 and 4.10 of ICD 1.3-4.4. Ensure the attributes logged

contain the attributes listed in sections 4.9 and 4.10.

NONE


starting conditions

_____________________ Pass/Fail


Customer______________________________ Date____________________

4.2.4 Lyot Stop Attributes

ICD Paragraph # 4.11

This section describes those attributes that the TCS will send to the top-level controller that involve the Lyot stop controller (atst.tcs.teoacs.lyot).


This test shows the TEOACS lyot stop controller software contains the required attributes specified by ICD 1.3-4.4 by viewing those




2. Compare the table in section 4.11 in ICD 1.3-4.4 to the

attributes for the controller called ‘atst.tcs.teoacs.lyot’. Ensure

the attributes seen in the PropertyEditor window contain the


NONE






33


4. Run the “showLyotAtt.th” Testharness script The TEOACS logs all the properties for this controller to the active log file.

5. Review the currently active log for those attributes section 4.11

of ICD 1.3-4.4. Ensure the attributes logged contain the


NONE


starting conditions.

_____________________ Pass/Fail


Customer______________________________ Date____________________

4.2.5 TEOACS Top Level Event Verification

ICD Paragraph # 4.12.1

This event reports the current status of the TEOA controller. The event is generated at a rate of 0.1 Hz and includes all listed attributes.


This test will show that the top level event will have the required attributes from the ICD and is transmitted at the required rate. The

PropertyEditor will be used to compare the 1/post:interval value for this controller to the rate in the table in section 4.12 of ICD 1.3-4.4. A

test script named ‘listen_mc.th’ will activate a listening function for the event in question. A few event messages will print to the screen and

then the listening function will cease. Then the test conductor will compare attributes from the ICD to the printed messages on the screen.

The time between messages will be determined from the printout to verify rate. Subsequently, an action will take place that will cause

portions of the event data to change. The listening function will be repeated and the test conductor will demonstrate that the content of the

event has changed in a meaningful way.



34

Insert Test Data in Appendix.

Rate = __________ Hz _____________________ Pass/Fail


Customer______________________________ Date____________________

4.2.6 M2 Positioner Event Verification


The TEOACS shall monitor the position of the M2 mirror in all six axes to within the specified tolerance. It shall report those positional values in a timely

manner through its event system. It shall monitor and report all aspects of M2 positioning operation, including, but not limited to, limit switches, and

power.


This event reports the current status of the M2 position controller. The event is generated at a rate of 1 Hz and includes all listed attributes. The generated

rate may be adjusted with the atst.tcs.teoacs.m2pos.statusRate attribute.


This test will show that the m2 positioner event will have the required attributes from the ICD and is transmitted at the required rate. The


test script named ‘listen_m2pos.th’ will activate a listening function for the event in question. A few event messages will print to the screen

and then the listening function will cease. Then the test conductor will compare attributes from the ICD to the printed messages on the

screen. The time between messages will be determined from the printout to verify rate. Subsequently, an action will take place that will

cause portions of the event data to change. The listening function will be repeated and the test conductor will demonstrate that the content of

the event has changed in a meaningful way.



35


Rate = __________ Hz _____________________ Pass/Fail


Customer______________________________ Date____________________

4.2.7 M2 Tip-Tilt Event Verification


The TEOACS shall control the M2 position in fast tip and tilt. It shall operate the M2 fast tip-tilt system within the required performance specifications of

that component.

The TEOACS shall monitor the position of the M2 fast tip-tilt system in both axes to within the specified tolerance. It shall report those positional values in

a timely manner through its event system. It shall monitor and report all aspects of M2 tip-tilt operation, including, but not limited to, limit switches,

power, and actuator voltages and currents. It shall report and log errors and faults when operational performance is not achieved.


This event reports the current status of the M2 tip-tilt controller. The event is generated at a rate of 1 Hz and includes all listed attributes for the M2

positioner event table and the table below.


Note: we cannot monitor actuator voltages and currents of the M2 Tip-tilt. Awaiting wording change on this specification.

This test will show that the m2tt event will have the required attributes from the ICD and is transmitted at the required rate. The


test script named ‘listen_m2tt.th’ will activate a listening function for the event in question. A few event messages will print to the screen and



36






Rate = __________ Hz _____________________ Pass/Fail


Customer______________________________ Date____________________

4.2.8 Lyot Stop Event Verification


The TEOACS shall move the Lyot stop between its defined positions. The motion shall be at the command of the TCS or the engineering user interface. The

TEOACS shall monitor the deployment of the Lyot stop and report any changes in status.


This event reports the current status of the Lyot stop. It contains the current state of the power and the current position of the stop. Valid positions are in,

out, and in_transit. It reported at 0.01 Hz.


This test will show that the lyot stop event will have the required attributes from the ICD and is transmitted at the required rate. The


test script named “listen_lyot.th” will activate a listening function for the event in question. A few event messages will print to the screen and



37






Rate = __________ Hz _____________________ Pass/Fail


Customer______________________________ Date____________________

4.2.9 Final Demand Math Passive

Design Verification (ICD Assumption based on customer agreement)

The final demand position calculation shall be as follows in AO mode active and AO mode passive:

finalDemandPos = initialDemandPosition + demandPosition + accum

In passive AO mode the *.opos attributes are the data source on the accum term and shall behave as the equation below shows


Verify that the final demand math in passive is correct by using the debug printing for the math that was placed in the code. Use the test

script named ‘finalDemand_m2pos.th’ to toggle the debug logger level which will enable logging that proves the final demand math.



38

1. Set the AO mode to passive via the TEOACS Engineering GUI.

2. Start with all luts off, send down *.pos values with *.opos all set to zero using the configuration named ‘configPosZero’. Observe

final demand math by toggling on and off the appropriate debug level related to final demand log printing using the

‘finalDemand_m2pos.th’ script.

3. Turn on luts one at a time and observe debug printing for math after each successive lut that is enabled.

4. Disable all luts. Send down successive *.opos configurations using ‘configOffsetPosAll’ configuration from the TEOACS

Engineering GUI while monitoring debug math logs between each successive *.opos configuration sent down.

5. Verify that the *.opos accumulation is working as desired by analyzing the logs.

6. Turn on one of the luts while the *.opos attributes are non zero. Verify that the final demand calculation makes sense with *.opos

attributes non-zero and one lut active.

7. After *.opos accumulation verified zero out *.opos accumulator by sending down aoZero attribute. View debug printing for math by

toggling the appropriate debug level for confirmation that accumulator was zeroed.

8. Verify that the wccs event data is ignored while in this mode by looking at the value of the accumulator and comparing to the current

wccs information shown by the TEOACS Engineering GUI.

9. Send down another *.opos configuration using the ‘configOffsetPosAll’ configuration from the TEOACS Engineering GUI.

10. Verify the setZpoint and clearZpoint behavior (the value in the accumulator should be shifted to the zero offset and then cleared) by

sending the ‘setZpointConfigPassive’ and ‘clearZpointConfigPassive’ configurations from the configuration widget on the M2

Hexapod tab. To see the zero offset use the ‘showM2.th’ script.

11. Zero out the *.opos accumulator by sending down the aoZero attribute.

_____________________ Pass/Fail



39


Customer______________________________ Date____________________

4.2.10 Final Demand Math Active

ICD Paragraph # 4.9.5 setZpoint

This attribute selects when to store the current M2 positioner offsets as the current zero position. It may only be accepted when the current mode of the M2

positioner is active. When selected, the status flag isZpoint is set.

ICD Paragraph # 4.9.6 clearZpoint

This attribute selects when to remove the current M2 positioner zero position offsets. When selected, the status flag isZpoint is cleared.

Design Verification (ICD Assumption based on customer agreement)

The final demand position calculation shall be as follows in AO mode active and AO mode passive:

finalDemandPos = initialDemandPosition + demandPosition + accum

In active AO mode the wccs corrections data is the data source on the accum term and shall behave as the equation below shows


The procedure below uses the same general procedure as seen in 4.2.9 to observe the final demand position math for active AO mode. Toggle

into and out of aoMode passive as necessary. Note: the WCCS information does not accumulate on the GUI like the *.opos information.

This is due to the fact that the GUI is listening straight to the WCCS event rather than the m2pos controller to show WCCS info.

1. Start with all luts off. Zero out the wccs data coming from the event simulator by using the ‘setESWccsZero.th’ script. Observe

final demand math by toggling on and off the appropriate debug level related to final demand log printing using the

‘finalDemand_m2pos.th’ script (note not the ‘active’version of this script).

2. Turn on luts one at a time and observe debug printing for math after each successive lut that is enabled.



40

3. Disable all luts. Using the simulated WCCS event successive wccs event data to have non zero values while monitoring debug math

logs between using the ‘setESWccs.th’ script.

4. Verify that the wccs accumulation is working as desired by analyzing the logs.

5. After wccs accumulation verified zero out wccs accumulator by sending down aoZero attribute in a configuration using the

‘finalDemand_m2pos_active_aoZero.th’ script which will also show the debug printing for the final demand math. Note: because of

asynchronous timing between debug logs it may be that you have to try this a couple times. It may help to zero out the wccs event

data prior to this step using ‘setESWccsZero.th’ if you are having trouble.

6. Repeat steps 3-5 but instead of aoZero attribute coming from a configuration, have the aoZero attribute be triggered from the WCCS

event. Use the ‘finalDemand_m2pos_active_w_aoZero.th’ script instead of the ‘finalDemand_m2pos_active_aoZero.th’ in step 5.

7. Verify the setZpoint and clearZpoint behavior by executing the ‘finalDemand_m2pos_active_zpoint.th’.

_____________________ Pass/Fail


Customer______________________________ Date____________________

4.2.11 M2 Hexapod Passive AO Mode Behavior


The TEOACS is operated through a number of modes. These are used to control the basic operations of the camera. The available modes and their

descriptions are as follows:

passive—The M2 positioner and M2 tip-tilt systems are powered on (enabled) and operating. Changes to the M2 positioner and M2 tip-tilt (when not in

limb tracking mode) positions shall be performed through the enabled look-up tables. For example, if all lookup tables are enabled, the M2 positioner

and M2 tip-tilt shall be commanded to a position that is the sum of the demand offsets, current static lookup table error and the current records keyed from

the temperature, azimuth and altitude look-up tables.




41

Verify the passive ao mode behavior with the procedure below:

1. Start the test in aoMode passive with all lookup table flags on the TEOA engineering GUI set to the ‘off’ position and the demand

position and offset for x, y, z, tip, tilt and rot set to zero. Use the ‘configPosZero’ configuration from the TEOA Engineering GUI to

zero out the *.pos values.

2. Use the ‘getLutTempError.th’ script to observe the currently keyed record out of the temperature lookup table. Compare this data to

what is currently on the TEOA Engineering GUI for the temperature lookup table record.

3. Set the lookup table flag for temperature from the ‘off’ position to the ‘on’ position on the TEOA engineering GUI .

4. Observe the ‘Current Pos’ fields for x, y, z, tip, tilt and rot on the TEOA engineering GUI change to match the values observed in step

2 above.

5. Use the ‘setLutTempError.th’ script to change the teoa ambient environment temperature. Edit the script so that the temperature

changes from the existing temperature.

6. Use the ‘getLutTempError.th’ script to observe the currently keyed record out of the temperature lookup table. Compare this data to

what is currently on the TEOA Engineering GUI for the temperature lookup table record.

7. Verify that the keyed record has changed from that seen in step 2.

8. Verify that the hexapod has moved to the positions that would be seen in step 6.

9. Repeat steps 1 - 8 using the scripts for static, azimuth, altitude lookup tables. In step 5 and 6 use the appropriate key associated with

the lut under test. For the static look up table skip step 5, 6 and 7. For step 8 the position to validate is that from step 4.

Script names:

‘getLut*Error.th’ where * = one of ‘Az’, ‘Alt’ or ‘Static’

‘setLut*Error.th’ where * = one of ‘Az’, ‘Alt’ or ‘Static’

10. Set all look up table flags to the ‘on’ position on the TEOA Engineering GUI with the offset values set to zero for all axes.

11. Verify that the current position observed on the GUI is the sum of the look up table values observed using the script.

12. Disable all lookup tables.



42

_____________________ Pass/Fail


Customer______________________________ Date____________________

4.2.12 M2 Hexapod Active AO Mode Behavior


The TEOACS is operated through a number of modes. These are used to control the basic operations of the camera. The available modes and their

descriptions are as follows:

active— The M2 positioner and M2 tip-tilt systems are powered on and operating. Changes to the M2 positioner positions are being performed through a

combination of the enabled look-up tables and input from the WCCS. For example, if all look-up tables are enabled, the M2 positioner shall be

commanded to a position that is the sum of the calculation that is done in passive mode with the latest WCCS information. The M2 tip-tilt always ignores

WCCS information. The M2 tip-tilt does have the capability to receive input from the WFCLT. If that is the intent the M2 tip-tilt must be put into Limb

Tracking Mode.


Verify the active ao mode behavior with the procedure below: Note: transition to passive and back to active mode when necessary. Use the

‘repeatAoZeroActive.th’ script to aid in the test where appropriate.

1. Perform the same test as in 4.2.11 M2 Hexapod Passive AO Mode Behavior steps 1 - 9 with the active mode version of the scripts.

Script names:

‘getLut*ErrorActive.th’ where * = one of ‘Az’, ‘Alt’ or ‘Static’.

‘setLut*ErrorActive.th’ where * = one of ‘Az’, ‘Alt’ or ‘Static’.

2. With all lookup tables toggled off via the TEOA Engineering GUI verify that the hexapod follows wccs trajectory.

3. Toggle all the lookup table flags to ‘on’ using the TEOA Engineering GUI and verify that the hexapod follows wccs trajectory.



43

_____________________ Pass/Fail


Customer______________________________ Date____________________

4.2.13 M2 Hexapod Named Position and Limits behavior

ICD Paragraph # 4.7

The choices for named positions shall be limited to the following values: index, stow, limitLoLo, limitLo, limitHi, and limitHiHi.

ICD Paragraph # 4.7

The following limit positions shall be defined for all axes:

• limitLoLo — electronic lower end-of-travel limit switch.

• limitLo — software lower limit switch.

• limitHi — software upper limit switch.

• limitHiHi — electronic upper end-of-travel limit switch


The following attributes are posted in the event

Name Type Units Comment

x:limit string choice Limit switch: none, home, lo, lolo, hi, hihi

y:limit string choice Limit switch: none, home, lo, lolo, hi, hihi

z:limit string choice Limit switch: none, home, lo, lolo, hi, hihi

tip:limit string choice Limit switch: none, home, lo, lolo, hi, hihi

tilt:limit string choice Limit switch: none, home, lo, lolo, hi, hihi

rot:limit string choice Limit switch: none, home, lo, lolo, hi, hihi




44

Verify the limit behavior of the M2 hexapod by following the procedure below:

1. Verify that configurations with the *.pos attributes above the limits are rejected.

2. Verify that passive mode behavior that may autonomously put the hexapod over a positional limit is accounted for by either clamping

the hexapod at software limitLo or limitHi values or tripping an unachievable move fault.

a. For clamping behavior:

i. Use the ‘submitPosClampM2.th’ script to set one axis to near the mechanical limit. .

ii. Turn on the azimuth lut via the TEOA Engineering GUI.

iii. Load the latest log in an editor and search for the word “clamp” from the bottom of the file.

b. For unachievable move fault behavior:

i. Execute the ‘almostUnachievableM2.th’ script.

ii. Set the azimuth coming from the simulated azimuth event to be 1.20 deg using the ‘setLutAzError.th’ script.

iii. Turn on the az lut via the TEOA Engineering GUI.

iv. Set the azimuth coming from the simulated azimuth event to be 20.0 deg using the ‘setLutAzError.th’ script.

v. Watch the health degrade on the TEOA Engineering GUI.

vi. Review the active log for indication that it was the unachievable move fault that tripped.

3. Verify that active mode behavior that may autonomously put the hexapod over a positional limit is accounted for by clamping the

hexapod at software limitLo or limitHi values.

a. First clear any faults from the previous step by turning off the luts and issuing a ‘configPosZero’ configuration from the GUI.

b. Use the ‘setESWccsLimit.th’ script to set up the wccs event

c. Transition to aoMode = active.

d. To see clamping in the log use the ‘finalDemand_m2.th’ script.



45

4. Verify that the unachievable move fault is tripped appropriately when the system attempts to go past a limit.

a. Use the ‘setESWccs.th’ script and do not send aoZero. Wait until the fault is tripped.

5. Verify that the limits attributes for each axis are set appropriately when at a limit. Values should be one of none, home, lo, lolo, hi and

hihi.

6. Verify that the hexapod can be commanded to all valid named Position values by using the m2pos.namedPos attribute (governs all

axes at once). Submit the ‘stowGlobalNamedPos’, ‘indexAll’, ‘limitHiGlobalNamedPos’, ‘limitHiHiGlobalNamedPos’,

‘limitLoGlobalNamedPos’ and ‘limitLoLoGlobalNamedPos’ configurations from the M2 Hexapod tab of the TEOA Engineering GUI

to accomplish this task.

a. Use the ‘getM2Limit.th’ script to verify that the m2pos controller has reached the limit after each one of these configurations.

_____________________ Pass/Fail


Customer______________________________ Date____________________

4.2.14 M2 Tip-Tilt Passive and Active AO Mode Behavior


Therefore, there is no material difference between passive and active aoMode for the M2 tip-tilt controller.


Verify the ao mode passive and active behavior of the m2tt controller with the procedure below: Use the ‘setESWccsZero.th’ script to

suppress WCCS behavior on the hexapod to minimize logs coming from the hexapod during this test.

1. With Limb Tracking mode disabled demonstrate passive mode behavior with the ‘configM2TTPosPassive’ configuration as sent from

the M2TT tab of the TEOA Engineering GUI.

2. Send the ‘configM2TTPosZero’ configuration from the TEOA Engineering GUI to zero out the *.pos attributes on the m2tt controller.



46

3. With limb tracking mode disabled demonstrate active mode behavior with ‘configM2TTPosActive’ configuration as sent from the

M2TT tab of the TEOA Engineering GUI.. The configuration should only differ in the aoMode attribute setting.

4. Verify the resulting behavior is identical with both configurations by observing the result of movement on the TEOA Engineering

GUI.

_____________________ Pass/Fail


Customer______________________________ Date____________________

4.2.15 M2 Tip-Tilt Limb Tracking Mode Behavior


The significant difference between the M2 tip-tilt controller and the M2 positioner controller is the addition of the ltMode attribute…


Verify the limbtracking mode attribute.

1. Verify the presence of the limb tracking mode attribute ‘limbTrackingMode’ as specified in the ICD by reviewing the active log and

property database. For actual limb tracking mode behavior tests see sections 4.4.2 and 4.4.3 for more notes.

_____________________ Pass/Fail


Customer______________________________ Date____________________



47

4.2.16 M2 Tip-Tilt Named Position and Limits behavior

ICD Paragraph # 4.7

The choices for named positions shall be limited to the following values: index, stow, limitLoLo, limitLo, limitHi, and limitHiHi.

ICD Paragraph # 4.7

The following limit positions shall be defined for all axes:

• limitLoLo — electronic lower end-of-travel limit switch.

• limitLo — software lower limit switch.

• limitHi — software upper limit switch.

• limitHiHi — electronic upper end-of-travel limit switch

ICD Paragraph # 4.12.2 as applied to the M2TT (see ICD Paragraph 4.12.3)

The following attributes are posted in the event


x:limit string choice Limit switch: none, home, lo, lolo, hi, hihi

y:limit string choice Limit switch: none, home, lo, lolo, hi, hihi

z:limit string choice Limit switch: none, home, lo, lolo, hi, hihi

tip:limit string choice Limit switch: none, home, lo, lolo, hi, hihi

tilt:limit string choice Limit switch: none, home, lo, lolo, hi, hihi

rot:limit string choice Limit switch: none, home, lo, lolo, hi, hihi


Verify the limit behavior of the M2TT by following the procedure below:

1. Verify that configurations with the *.pos attributes above the limits are rejected by using the ‘submitPosPositiveAboveLimit’ and

‘submitPosNegativeAboveLimit’ scripts.

2. Turn on the static lut when at the limitLo positon.



48

3. Verify that active mode behavior that may autonomously put the ftt over a positional limit is accounted for by clamping the hexapod at

software limitLo or limitHi values.

4. Verify that the limits attributes for each axis are set appropriately when at a limit by using the ‘getMTLimit.th’ script. Values should

be one of none, home, lo, lolo, hi and hihi.

5. Verify that the tip-tilt hexapod can be commanded to all valid named Position values by using the m2pos.namedPos attribute (governs

all axes at once). Submit the ‘limitHiGlobalNamedPos_m2tt’, ‘limitHiHiGlobalNamedPos_m2tt’, ‘limitLoGlobalNamedPos_m2tt’

and ‘limitLoLoGlobalNamedPos_m2tt’ configurations from the M2 Hexapod tab of the TEOA Engineering GUI to accomplish this

task.

_____________________ Pass/Fail


Customer______________________________ Date____________________

4.2.17 Lyot Stop Behavior


This section describes those attributes that the TCS will send to the top-level controller that involve the Lyot stop controller (atst.tcs.teoacs.lyot).


This event reports the current status of the Lyot stop. It contains the current state of the power and the current position of the stop. Valid

positions are in, out, and between.


power boolean off | on The statused enabled or disabled state as read from the hardware.

NOT the commanded power state.

cPos string choice Current position in, out, and in_transit

inAirPressSw boolean false | true Air pressure associated with the in position

outAirPressSw boolean false | true Air pressure associated with the out position



49

inPosition string false | true false when cPos is in_transit or reading of cPos related digital IO

lines are in conflict with the relevant air pressure switches.

Verification Procedure: Verify that the information in the lyot stop cStatus event corresponds to what was asked for in the position.

1. With the power attribute (‘lyotPowerCfg’ from GUI) on the lyot stop controller pull the Ethernet cable connecting the acromag 983

EN controller out of the Ethernet switch. Note: Ethernet cable only to be pulled for about 5 seconds. Also note that the cable needs to

be pulled so that only communications with the lyot stop are affected.

2. Verify that a communications down fault is seen.

3. Re-apply the Ethernet cable (should be about 5 seconds after it was originally pulled).

4. If the communications down fault does not heal on its own toggle the power attribute off and back on again.

5. With the power attribute set to on monitor the lyot stop cStatus event with the ‘listenLyotStatus.th’ test script.

6. With the lyot stop power on send the lyot stop to the ‘in’ position from the ‘out’ position using the pos attribute in a valid

configuration using either the test script or the gui (‘lyotConfig1’). If necessary toggle to the ‘out’ position first using ‘lyotConfig2’

configuration from the TEOA Engineering GUI.

7. Verify that all the information in the lyot stop cStatus event is consistent with the position of ‘in’ for the lyot stop after motion stops.

8. Perform steps 6 - 1 again but this time for the case of movement to the ‘out’ position from the ‘in’ position by using ‘lyotConfig2’

configuration from the TEOA Engineering GUI.

9. Stop the listener for the lyot stop cStatus event by using the ‘deflis –q’ command at the Testharness command line.

_____________________ Pass/Fail



50


Customer______________________________ Date____________________



51

4.2.18 Shutdown and Un-initialization


The following actions shall be undertaken in response to a shutdown command:

• turn off and clear any fast tip/tilt corrections;

• turn off and clear any quasi-static alignment corrections;

• Set all user offsets dx, dy etc. to zero; and

• park/halt the positioning and tip/tilt systems.


This test shows that the TEOACS satisfies the required shutdown behavior by shutting down the system and observing printouts from the log.

The preconditions for this test are that the system has been started and is in the ‘running’ lifecycle state.

This test covers two general test cases: shutting down from aoMode passive and shutting down from aoMode active. The starting point for

this test assumes that the TEOACS is on and active.

Test Case 1:

aoMode = passive

Hexapod position = (1, 2, 3, 50, 50, 60)

FTT position = (0, 0, 0, 4, 5, 0)

State for atst.tcs.teoacs.m2pos controller is ‘sip’

State for atst.tcs.teoacs.m2tt controller is ‘sip’

State for atst.tcs.teoacs.lyot controller is ‘stowed’

Test Case 2:

aoMode = active

m2pos: WCCS info is 0 for all axes.



52

m2pos: All luts ON

FTT position = (0, 0, 0, 4, 5, 0)

State for atst.tcs.teoacs.m2pos controller is ’FOLLOWING’ or ‘HUNTING’

State for atst.tcs.teoacs.m2tt controller is ‘SIP’, ‘MOVING’, ’FOLLOWING’ or ‘HUNTING’

State for atst.tcs.teoacs.lyot controller is ‘DEPLOYED’

Test Case 3:

aoMode = off

Hexapod position = (0, 1, 2, 3, 50, 50, 60)

FTT position = (0, 0, 0, 4, 5, 0)

State for atst.tcs.teoacs.m2pos controller is ‘parked’

State for atst.tcs.teoacs.m2tt controller is ‘parked’

State for atst.tcs.teoacs.lyot controller is ‘off’


1. Verify health of all controllers is ‘good’. Execute the

‘atpShutdown_TestCase1.th’ script.

The TEOACS is put into a state consistent with Test Case 1 above.

2. Run the ‘shutdown.th’ script. The TEOACS goes through the shutdown sequence from the state established

during test case 1. The controllers that comprise the TEOACS are shutdown

and uninitialized.

The TEOACS controllers are unloaded

3. Diff the relevant output from the current test log with the golden

std log for this test (see Appendix C.1 Listing of Golden Std

Logs).

The diff of the current test log and golden std output log should yield no

significant differences in the relevant shutdown section of the log (copy it to

$TEOACS/doc/logsUnderTest and then run the ‘launchAtp*Meld’ script where

* is 1, 2 or 3)



53


4. Start up the TEOACS by issuing the ‘ContainerManager start’

command at a ‘teoaClient’ terminal or just run Testharness in

the next step and the ‘ContainerManager start’ command will be

executed automatically.

All TEOACS controllers reach the ‘Loaded’ lifecycle state (or further if

automatic container starting is active in the startup script.)

5. Start the Testharness on the CSF server which will

automatically call the ‘startupTeoa.th’ script.

TEOACS controllers transition from lifecycle state ‘Loaded’ through ‘Init’ and

into the ‘Running’ lifecycle state






and uninitialized. However, they remain loaded.

The TEOACS controllers are unloaded



Logs).




* is 1, 2 or 3)





All TEOACS controllers reach the ‘Loaded’ lifecycle state










and uninitialized.

The TEOACS controllers are unloaded.



54




Logs).




* is 1, 2 or 3)





All TEOACS controllers reach the ‘Loaded’ lifecycle state





16. Verify health of all controllers is ‘good’. N/A

17. Satisfies restart requirement 1.3.3-0020. TEOACS controllers were only shut down on command during this procedure.

Shutdown and/or start up was successful (save the ContainerManager hanging

bug found in Canary 7-2/7-1).

_____________________ Pass/Fail


Customer______________________________ Date____________________

4.2.19 Engineering User Interface


The TEOA shall supply an engineering user interface that implements all functional operations of the TEOA as defined by the interfaces to the TCS and

WCCS (ICD-1.3/4.4 and ICD-1.3/2.3) and shall be useful for actual operations within the ATST. The engineering user interface shall reside on a separate

computer from the TEOACS and use the Common Services Framework to communicate with the TEOACS.




55

Verify that the Engineering user interface satisfies the Engineering user Interface requirement above by demonstrating related functionality by

operating the user interface from the CSF server ‘dunn’. This is accomplished by performing test procedures in other sections of this

document as called out in the table below.


1. Verify that the TEOA Engineering GUI used in all the

subsections listed below is located on the CSF server dunn and

is being executed from there.

The TEOA Engineering GUI is being executed from the CSF server ‘dunn’ and

not the CSF client ‘teoaClient’.

2. Section 4.1.1 Engineering User Interface GUI portions of test executed successfully

3. Section 4.1.2 Lyot Stop Positioning GUI portions of test executed successfully

4. Section 4.1.5 Health GUI portions of test executed successfully

5. Section 4.1.6 Logging GUI portions of test executed successfully

6. Section 4.1.9 Diagnostic Features GUI portions of test executed successfully

7. Sections 4.2.1 - 4.2.4 Attributes related tests GUI has access to all ICD attributes available on each controller.

8. Section 4.2.11 M2 Hexapod Passive AO Mode Behavior GUI portions of test executed successfully

9. Section 4.2.12 M2 Hexapod Active AO Mode Behavior GUI portions of test executed successfully

10. Section 4.2.13 M2 Hexapod Named Position and Limits

behavior

GUI portions of test executed successfully

11. Section 4.2.17 Lyot Stop Behavior GUI portions of test executed successfully

12. Section 4.4.2 M2 Tip-Tilt Limb tracking Mode Enabled GUI portions of test executed successfully

13. Section 4.4.3 M2 Tip-Tilt Limb tracking Mode Disabled GUI portions of test executed successfully

14. Satisfies restart requirement 1.3.3-0020. No system restart should have resulted from executing this test

_____________________ Pass/Fail


Customer______________________________ Date____________________



56

4.3 ICD 1.3-2.3 WCCS VERIFICATION PROCEDURES

This section mainly deals with requirement 1.3.3-0225 and 1.3.3-0305.


The TEOACS shall receive and act upon slowly varying error corrections from the Wavefront Correction Control System by adjusting the M2 six-axis

positioning system.


The TEOACS shall provide an interface to the Wavefront Correction Control System (WCCS) as defined by ICD-1.3/2.3. The TEOACS receives correction

information for the M2 mirror position from the WCCS and shall act upon such information to meet its performance specifications.


The TEOACS shall update the M2 six-axis position system at the rate specified in ICD 1.3/2.3 in active AO mode. In AO mode passive the TEOACS shall

update the M2 six-axis position system when the calculated position error is greater than the minimum resolvable movement or when a new configuration

is sent down with positional information. The response and settling time for the six-axis positioning system shall be consistent with the performance

requirements for the six-axis positioning system.



57

4.3.1 M2 Hexapod WCCS subscription


The WCCS generates a stream of events through the ATST Common Services Framework for the TEOACS that contain the necessary corrections for the

M2 Positioning System.

If true, the aoZero flagTEOA to WCCS indicates that all accumulated WCCS offsets should be zeroed before applying the position offsets

contained within the event.


Verify the aoZero flag behavior on the controller and the

1. Transition to aoMode ‘active’.

2. Verify each data item in the WCCS event is taken out of the event and consumed by the M2 Hexapod controller by toggling on the

relevant log messages with ‘toggleWCCSLogging.th’while observing the current position on the GUI (note the system will be in

aoMode passive after this script is run).

3. Transition to aoMode ‘active’.

4. After an amount of time left up to the discretion of the lead software engineer, zero out the WCCS trajectory information in two ways:

a. Via the WCCS event itself which has an aoZero variable using the ‘toggleWCCSLogging_aoZero.th’ script while observing

the current position on the GUI(note the system will be in aoMode passive after this script is run).

b. Via a ‘submit’ to the m2pos controller containing the aoZero attribute via the engineering GUI. Start the

‘toggleWCCSLogging.th’ script and then issue the configuration named ‘aoZeroActiveConfig’ from the GUI.

5. Repeat step 4 with all lookup tables on.

_____________________ Pass/Fail


Customer______________________________ Date____________________



58



59

4.4 ICD 1.3-2.5 VERIFICATION PROCEDURES

This section mainly deals with requirement 1.3.3-0225 and 1.3.3-0307


The TEOACS shall provide an interface to the Wavefront Correction AO Limb Tracker System as defined by ICD-1.3/2.1. The TEOACS receives

correction information for the M2 fast tip-tilt from the WFC AO Limb Tracker via a direct connection and shall act upon such information to meet its

performance specifications.

Note: ICD-1.3-2.1 has been renamed to ICD-1.3-2.5.


The TEOACS shall receive and act upon rapidly varying tip and tilt error corrections from the Wavefront Correction AO Limb Tracker System by

adjusting the M2 two-axis fast tip-tilt system.

4.4.1 Electronics Interface

ICD Paragraph # 3.3

The TEOA’s Fast Tip-Tilt stage controller shall include a Physik Instrumente (PI) E-711.IP Parallel Input/Output Interface (PIO) Module. This PIO

Module shall be the interface to the WFC Limb Tracker. The standard PI cable and connector shall be used.


This test shows that the TEOA’s fast tip-tilt stage controller has the required hardware to implement a connection to the WFC Limb Tracker.

1. Inspect the hardware in front of AURA representatives and verify the presence of an E-711 PIO interface.

_____________________ Pass/Fail


Customer______________________________ Date____________________



60

4.4.2 M2 Tip-Tilt Limb tracking Mode Enabled

ICD Paragraph # 1.0

When the ATST is operating in Limb Tracking mode, the TEOACS will place the M2 Fast Tip-Tilt controller in Open Loop mode and enable the M2 Fast

Tip-Tilt System interface to the WFC HOAO Limb Tracker. In this mode, the Limb Tracker will provide 16 bit integer X and Y positions to the M2 Fast

Tip-Tilt controller. The TEOACS will not send commands to the M2 Fast Tip-Tilt in Limb Tracking mode.


Verify limb tracking mode behavior given the limitation that no hardware is present to communicate with the FTT via the PIO interface. The

assumption at the start of this test is that limb tracking mode is off for the m2tt controller.

1. Transition to aoMode ‘passive’.

2. Turn on limb tracking mode logging output via the ‘limbTrackingLoggingEnable.th’ script.

3. Toggle from limb tracking mode ‘off’ to limb tracking mode ‘on’ on the M2FTT tab of the TEOA Engineering GUI.

4. Analyze the current log output for validation of limb tracking mode on using an editor or an existing tail session.

5. Use the ‘showMT.th’ script to show top level information about the m2tt controller. Verify that the information shown in the existing

log as a result of the ‘showMT.th’ script validates that the E712 controller is now in pio mode.

6. Show that configurations with *.pos variables in them are rejected in limb tracking mode by sending down ‘configM2TTPosPassive’.

_____________________ Pass/Fail


Customer______________________________ Date____________________



61

4.4.3 M2 Tip-Tilt Limb tracking Mode Disabled

ICD Paragraph # 1.0

When the ATST in not operating in Limb Tracking mode, the TEOACS will disable the M2 Fast Tip-Tilt System interface to the WFC HOAO Limb Tracker.

In this case the TEOACS will have complete control of the M2 Fast Tip-Tilt System.


Verify limb tracking mode behavior given the limitation that no hardware is present to communicate with the FTT via the PIO interface.

Note: Approximate test procedure. This may be a repeat of the testing performed as part of section 4.2.15. Determine which place this test

should really go.

1. Change m2tt controller to Limb Tracking mode ‘on’ via the TEOA Engineering GUI if the system is not already in Limb Tracking

mode.

2. Turn on limb tracking mode logging output via the ‘limbTrackingLoggingEnable.th’ script.

3. Toggle from limb tracking mode ‘on’ to limb tracking mode ‘off’ on the M2FTT tab of the TEOA Engineering GUI.

4. Analyze the current log output for validation of limb tracking mode on using an editor or an existing tail session.

5. Demonstrate that the TEOACS has full control of the tip-tilt stage by issuing configurations to the m2tt controller which should make

the stage move.

6. Turn off limb tracking mode output via the ‘limbTrackingLoggingDisable.th’ script.

_____________________ Pass/Fail


Customer______________________________ Date____________________



62

4.5 INSPECTIONS

This section mainly deals with requirements that are marked as tests but are more like inspections. They are made into tests by making a

formal record of the inspection via the written procedures.

4.5.1 Best Software Practices


The TEOACS shall conform to the ATST software requirements. Under these requirements the TEOACS shall:

Use the ATST Common Services Framework for all communications, commands, events, logging, archiving, and database functions.

Use the ATST Common Services Framework to build Controllers for the top-level TEOA controller. A controller is defined within the ATST

Common Services Framework description in SPEC-0022.

Use software libraries approved by ATST for the implementation of the TEOACS.

Deliver documented source code, compiled object code, associated libraries, build and release code development environments, test software and

fixtures, and any other materials necessary to edit, build, compile, link, load, run, test, and debug the TEOACS. Deliver a user’s manual for the

TEOACS.

Use a source code repository for all developed TEOACS software, and make the repository available to AURA during construction.


Verify that the TEOACS uses the ATST Common Services Framework for all communications, commands, events, logging, archiving, and

database functions. _____________________ Pass/Fail

Verify that the TEOACS uses the ATST Common Services Framework to build the TEOA controller.

_____________________ Pass/Fail

Verify that the TEOACS uses software libraries approved by ATST. _____________________ Pass/Fail

Verify that the source code, compile object code, and libraries have been delivered to ATST

Verify delivery of the user manual for TEOAS _____________________ Pass/Fail

Verify use of the source code repository _____________________ Pass/Fail



63


Customer______________________________ Date____________________



64

4.5.2 Secure communications


The TEOACS shall presume all communications to it are secure. No protection devices shall be implemented by the TEOACS or the operating

system under the TEOACS (e.g., encryption, firewall, passwords). All security shall be provided by the ATST.


Verify the secure communications requirement with the procedure below:

1. Verify firewall on the client machine is disabled by going to ‘System/Administration/Firewall’ within the CENTOS operating

system’s GNOME interface.

_____________________ Pass/Fail


Customer______________________________ Date____________________



65

5 CONCLUSION

5.1 TEST REVIEW

Please enter the starting and ending CSF version in the spaces below:

Starting CSF version: __________________________________

Ending CSFversion: __________________________________

Please review the configuration log pages and enter the relevant data below.

Starting TEOACS version and build date: __________________________________

Ending TEOACS version and build date: __________________________________

If starting and ending TEOACS versions or starting and ending CSF versions are not identical explain

reason and sign and date:

_____________________________________________________________________

_____________________________________________________________________

_____________________________________________________________________

Notes about versions:

_____________________________________________________________________

_____________________________________________________________________

L-3 Communications QA ________________________________ Date ____________

L-3 Representative ________________________________ Date ____________

Customer Representative ________________________________ Date ____________



66

Please review all tests and ensure they were complete then sign and date below.

Responsible Engineer ________________________________ Date ____________

L-3 Communications QA ________________________________ Date ____________

L-3 Representative ________________________________ Date ____________

Customer Representative ________________________________ Date ____________



67

Appendix A. Configuration Log Form

The configuration log form can be seen on the next page.



68

Configuration Log

Date/Time Version1 Build Date1 Log File2 Comments

1 Use showMC.th script.

2 Use ‘displayLogFilename.th’ script.



69

Appendix B. Starting the TEOACS

In order to start the TEOACS from a cold start follow the procedure outlined in

section Appendix B.1.

Appendix B.1. TEOACS startup procedure

Follow this procedure to bring up the TEOACS. This procedure assumes

‘teoaClient’ and ‘dunn’ are off. Note: an NFS share is setup between ‘teoaClient’

and ‘dunn’ where the share is automatically mounted on ‘dunn’. The order the

machines are started in is important since ‘dunn’ will hang on startup when it is not

turned on second.

1. Follow the procedure in Appendix B.5.1 Equipment Startup.

2. Turn on the ‘teoaClient’ machine.

3. While ‘teoaClient’ is booting turn on the CSF server ‘dunn’.

4. Run the ‘teoaJES’ script from a terminal window on ‘dunn’ (it is on the

PATH). This starts the TEOA Engineering GUI.

5. Once ‘dunn’ is completely booted log into the ‘mbock’ account on CSF

server ‘dunn’.

6. Edit macros.th on ‘dunn’ located in ‘$ATST/resources/Testharness’ so

that it is put in the configuration for TEOA testing (see Figure B.4-3).

7. Depending on the test being performed the ‘teoaClient’ machine may or

may not have the ‘ContainerManager’ started automatically on boot up. If

automatic startup of ‘ContainerManager’ has been defeated ssh to

‘teoaClient’ from ‘dunn’ and type ‘ContainerManager start’ at a

terminal window. This will start the default container called ‘TEOA.SIM’

and place all releated components into the loaded lifecycle state.

Note: the bash script ‘startTeoaContainer.sh’ starts the ‘TEOA.SIM’

container and is designed to be called from the ‘startupTeoa.th’ script

which is called on the startup of ‘Testharness’. Therefore, the

‘TEOA.SIM’ container can be started either manually starting an ssh session

to ‘teoaClient’ as this step says or it can be automated out of the startup

of the ‘Testharness’.

8. Verify that there were no errors in the Container Manager starting. The

container manager terminal output should look like this if successful:

[mbock@teoaClient connections]$ ContainerManager start

STARTED TEOA.SIM

9. Now that the ‘TEOA.SIM’ container is started the controllers under that

container should all be in the ‘loaded’ lifecycle state. Depending on the

test a further step can be taken to transition this container’s entire

controller set into the ‘running’ state. To do that automatically just type

‘Testharness’ from any terminal on ‘dunn’. The starting of the

Testharness tool has been automated on ‘dunn’ so that all controllers in



70

container ‘TEOA.SIM’ are automatically transitioned from ‘loaded’ through

‘init’ to ‘running’ lifecycle state.

Appendix B.2. TEOACS Manual Restart Procedure

Follow this procedure to manually restart the TEOACS. Note this procedure covers

the CSF client and server computers only during test. It does not include a restart of

the PI motion controllers for the FTT and Hexapod.

1. Run the ‘shutdown.th’ script. The TEOACS controllers will be shutdown,

uninitialized and unloaded. The TEOA.SIM container on ‘teoaClient’

is stopped by the script.

Note: formerly to Shut down the TEOACS software one had to issue a

‘ContainerManager stop’ command at a ‘teoaClient’ terminal.

[mbock@teoaClient connections]$ ContainerManager stop

STOPPED TEOA.SIM

Now the same command yields this response after shutdown.th is

executed:


ERROR Container 'TEOA.SIM' is not running

2. Close all windows on ‘dunn’.

3. If monitor and keyboard are hooked up to ‘teoaClient’ then start an ssh

session from ‘dunn’ to ‘teoaClient’. Issue a ‘sudo poweroff’

command from the terminal. If there is a monitor and keyboard hooked up

to ‘teoaClient’, navigate to the ‘shutdown’ screen on ‘teoaClient’ by

going to the gnome menu ‘System’ and select ‘Shut Down…’ after step 4

below. [Note: an NFS share is shared between ‘teoaClient’ and server it is

best to shutdown ‘dunn’ first before ‘teoaClient’. Howerver, you can use

this ssh trick and do step 4 below very quickly to avoid ‘dunn’ hanging on

shutdown]

4. Navigate to the ‘shutdown’ screen by going to the gnome menu ‘System’

and select ‘Shut Down…’.

5. After both client and server are off wait 10 seconds for any transients in

the system to be gone.

6. Start up ‘teoaClient’ and ‘dunn’ using Appendix B.1 TEOACS startup

procedure .

Appendix B.3. TEOACS Software Restart Procedure

1. Run the ‘shutdown.th’ script. The TEOACS controllers will be shutdown,

uninitialized and unloaded. The TEOA.SIM container on ‘teoaClient’

is stopped by the script.

Note: formerly to Shut down the TEOACS software one had to issue a

‘ContainerManager stop’ command at a ‘teoaClient’ terminal.



71


STOPPED TEOA.SIM

Now the same command yields this response after shutdown:


ERROR TEOA.SIM

2. Restart the test harness on from a ‘teoaClient’ terminal.

Appendix B.4. TEOACS Auto Restart Procedure

The auto restart procedure is enabled by editing the rc.local file located in the

‘/etc/rc.d’ directory so that the ‘teoaRestart’ script is started when the ‘teoaClient’

machine boots up.

The ‘rc.local’ file is seen in below (in this listing the ‘teoaRestart’ script is

commented out.

Figure B.4-1 rc.local listing

Figure B.4-2 teoaRestart script listing

The procedure for enabling the auto restart of the teoaClient is below:



72

1. Navigate to the ‘/etc/rc.d’ directory.

2. Open ‘rc.local’ in a text editor with root privileges.

3. Uncomment the line

“/bin/su –command “/etc/init.d/teoaRestart’ – mbock

The macros.th script that is used by Testharness on startup is seen below in Figure

B.4-3.

Figure B.4-3 macros.th script listing

Note that the macros.th script seen in Figure B.4-3 above is used by both the Transfer

optics program and TEOA. For TEOA testing the appropriate lines need to be

uncommented under the section “#For teoa testing” and the the lines under the line

“#For fotcs testing” need to be commented.

Appendix B.5. TEOACS Equipment Startup/shutdown Procedure

Follow these procedures to manually startup and shutdown the equipment that the

TEOACS talks to.

Appendix B.5.1. Equipment Startup

This is the equipment startup procedure for TEOACS.

1. Turn on the FTT power supply (part no: M_850k249).

2. Turn on the E-712 FTT controller.

3. Turn on the hexapod controller (M_850k248)

4. Turn on the lyot stop air pressure.

5. Turn on the control rack where the lyot stop controller resides.



73

Appendix B.5.2. Equipment Shutdown

This is the equipment shutdown procedure for TEOACS.

1. Turn off the E-712 FTT controller.

2. Turn off the FTT power supply (part no: M_850k249).

3. Turn off the hexapod controller (M_850k248)

4. Turn off the lyot stop air pressure.

5. Turn off the control rack where the lyot stop controller resides.

Appendix B.6. Containers

The container that is being run throughout this ATP is called TEOA.SIM. The .SIM

portion of the name comes from the fact that the event simulator is run to simulate

events we are required to subscribe to. The event simulator will not be needed in the

production environment. At that point the container name should be changed to

something like TEOA.PRO.



74

Appendix C. Golden standard output logs

Golden standard output logs have been captured for select test procedures seen in the

main part of this document

Appendix C.1. Listing of Golden Std Logs

The location of these golden standard logs in Perforce and their corresponding test

section can be seen below in Table C.1-1. .

Table C.1-1 List of captions

Test section Golden Std Log location

4.2.18 Shutdown and Un-initialization //depot/doc/goldenStdLogs/atpShutdown_TestCase1.log



It is important to obtain the golden standard logs listed in Table C.1-1 using the

Perforce label corresponding to the release under test. Note: these logs will typically

be obtained through a dry run of this procedure.