telescope control system software test plan · telescope control system software test plan alan...

Project Documentation Document PROC-0026

Revision A

Telescope Control System Software Test Plan

Alan Greer & Chris Mayer Observatory Sciences Ltd

November 30, 2016

TCS Factory Acceptance Test Plan

PROC-0026 Revision A Page i

Revision Summary:

1. Date: 19th June 2012 Revision: Draft 1 Changes: Original version

2. Date: 21st December 2012 Revision: Draft 2 Changes: Updates

3. Date: 28th February 2013 Revision: Draft 3 Changes: Added new tests AT4.4-0008-03, AT4.4-0125-03, AT4.4-0125-04, AT4.4- 0110-13, AT4.4-0110-14, AT4.4-0215-02.

4. Date: 11th November 2016 Revision: Draft 4 Changes: Added new tests AT4.4-0190-01 to 09. Removed 405-03 to 405-06, these

are now amalgamated into 405-02. Added new tests AT4.4-0410-06 to AT4.4-410-09. Removed AT4.4-0165-15 and replaced with AT4.4-0165-16. Updated all script references. Added AT4.4-0190-10. Updated AT4.4-105-03 to match current implementation. Added AT4.4-145-04 to test switching scanning modes. Added AT4.4-0255_01 to test setting of aoModes.

5. Date: 30th November 2016

Revision: A Changes: Updated AT4.4-0008-3 to handle new PA&C and WCCS modes plus new

event and attribute names. Similar types of modifications to AT4.4-0200-01, AT4.4-0210-01, AT4.4-0415-01, AT4.4-0420-01, AT4.4-0425-01, AT4.4-0430-01 and AT4.4-0440-01. Updated AT4.4-0190-02, AT4.4-0190-04 and AT4.4-0190-06 to test clearing and absorbing offsets. Added new tests AT4.4-0190-11 and AT4.4-0190-12 to test rate offsets in HG and HPR coordinates. Added test AT4.4-0412 to check locking rotator demand to azimuth demand. Initial formal release.

TCS Factory Acceptance Test Schedule

TCS FAT Plan Revision B Page ii

Table of Contents 1. Introduction .......................................................................................................... 1

1.1 References ...................................................................................................................................... 1 1.2 Acronyms ....................................................................................................................................... 1

2. Acceptance Test Configuration .......................................................................... 2 3. Test Descriptions ................................................................................................. 3

3.1 General Requirements – Logging ................................................................................................... 3 3.2 General Requirements – Default State ........................................................................................... 6 3.3 General Requirements – Health .................................................................................................... 10 3.4 General Requirements – Availability ........................................................................................... 11 3.5 General Requirements – Persistence Of Data ............................................................................... 14 3.6 Pointing Requirements – Time ..................................................................................................... 15 3.7 Pointing Requirements – Solar Ephemeris ................................................................................... 17 3.8 Pointing Requirements – Ephemeris Prediction ........................................................................... 24 3.9 Pointing Requirements – Stellar Ephemeris ................................................................................. 37 3.10 Pointing Requirements – Planetary Ephemeris ......................................................................... 41 3.11 Pointing Requirements – Pointing ............................................................................................ 46 3.12 Pointing Requirements – Pointing Maps .................................................................................. 49 3.13 Pointing Requirements – Open-loop Pointing Offset ............................................................... 51 3.14 Pointing Requirements – Pointing Correction Mechanism ....................................................... 53 3.15 Pointing Requirements – Scanning ........................................................................................... 55 3.16 Pointing Requirements – Pointing Modes ................................................................................ 58 3.17 Pointing Requirements – Sky Coverage ................................................................................... 60 3.18 Pointing Requirements – Forbidden zone when Mirror Cover and Enclosure are open........... 61 3.19 Pointing Requirements – Zenith Blind Spot ............................................................................. 63 3.20 Pointing Requirements – Tracking ........................................................................................... 65 3.21 Pointing Requirements – Occulter ............................................................................................ 77 3.22 Pointing Requirements – Drift .................................................................................................. 78 3.23 Pointing Requirements – Target ............................................................................................... 79 3.24 Pointing Requirements – Offsets .............................................................................................. 88 3.25 Rate Offsets Requirements ....................................................................................................... 99 3.26 Wavefront Requirements – Wavefront Correction ................................................................. 110 3.27 Wavefront Requirements – WCCS Control of the Polarimetry Analysis and Calibration ..... 112 3.28 Wavefront Requirements – Wavefront Correction Offload .................................................... 113 3.29 Wavefront Requirements – Wavefront Correction Mode ....................................................... 115 3.30 Thermal Requirements – Weather Station .............................................................................. 117 3.31 Subsystem Requirements – Sequencing Subsystems ............................................................. 119 3.32 Subsystem Requirements – Enclosure .................................................................................... 125 3.33 Subsystem Requirements – Mount ......................................................................................... 127 3.34 Subsystem Requirements – M1 Mirror ................................................................................... 134 3.35 Subsystem Requirements – M2 Mirror and Top-End Assembly ............................................ 136 3.36 Subsystem Requirements – Feed Optics ................................................................................. 137 3.37 Subsystem Requirements – Wavefront ................................................................................... 138 3.38 Subsystem Requirements – Acquisition ................................................................................. 139 3.39 Subsystem Requirements – Polarimetry Analysis and Calibration ........................................ 140 3.40 Performance Requirements – Accept or Reject a Command in 0.1 Seconds ......................... 142 3.41 Performance Requirements – Boot Within 5 Minutes ............................................................ 143 3.42 Performance Requirements – Apply Offset Information Within 0.1 Seconds........................ 144 3.43 Interface Requirements – Sequencing .................................................................................... 145


PROC-0026 Revision A Page iii

3.44 Interface Requirements – Health ............................................................................................ 146 3.45 Interface Requirements – Alarms ........................................................................................... 147 3.46 Interface Requirements – Control of Telescope Motion ......................................................... 148 3.47 Interface Requirements – Telescope Information ................................................................... 149 3.48 Interface Requirements – OCS Interface ................................................................................ 151

4. Compliance MATRIX ........................................................................................ 164


PROC-0026 Revision A Page 1 of 164

1. INTRODUCTION

This document is the Test Plan for the specifications of the DKIST Telescope Control System (TCS). It is

an extension of the TCS Factory Acceptance Test Plan produced in conformance with the original

Statement of Work (SOW) and consists of two main parts

A description of the acceptance test configuration

A description of each test along with the specifications tested, the required setup and the inputs

and expected outputs

The compliance matrix is now presented in a separate document, see Ref [4].

The tests written for the TCS FAT ran under a custom test frame work that allowed the execution of

individual test scripts and but often required the user to monitor the output or verify status by inspection

of log files or engineering screens. The tests described in this document have been converted from that

original test environment to the Testing Automation Framework (TAF) so that they can be run each night

without user intervention for quality assurance purposes.

1.1 REFERENCES [1] Telescope Control System Statement of Work, Goodrich, B.

[2] TCS Software Design Description, SPEC-0021, Greer, A., Mayer, C., Terrett, D. &

Wallace, P.

[3] Observatory Control system to Telescope Control System ICD, ICD 4.2/4.4, Greer, A.,

Mayer, C. & Wampler, S.

[4] TCS_Compliance_Matrix.xlsx, Greer, A. & Mayer, C.

[5] Quality Assurance Software Test Plan, PROC-0015, Greer, A., Mayer, C.J. and

Yoshimura, A.

1.2 ACRONYMS

AT Acceptance Test

CSF Common Services Framework

FAT Factory Acceptance Tests

JES Java Engineering Screens

SDD Software Design Description

SOW Statement of Work

TAI International Atomic Time

TCS Telescope Control System



2. ACCEPTANCE TEST CONFIGURATION

The tests described in this document are designed to verify that the TCS meets the requirements in the

specification. For this reason no TCS subsystems will be used in the tests but instead the tests will be

conducted with the TCS supplied simulators so that it can be tested fully standalone. Integration testing

with the TCS subsystems will occur separately as subsystems become available.

The test configuration will consist of the following

Operating System – the operating system will be CentOS 7 running kernel version 3.10

Common Services – the Canary_10-1 release will be used

Java – Java version 1.8 as required by the use of Canary_10-1

The TCS release tagged as “Canary_10-1” in the DKIST CVS repository

The TCS 64 bit development machine known as “Carrington” or equivalent

It is not anticipated that any additional software libraries or modules outside of the specifications above

will be needed for the tests nor any additional hardware. In particular it is not expected that the TCS will

have access to high precision TAI time from the DKIST time system but will instead use its internal

clock.



3. TEST DESCRIPTIONS This section details each of the tests that will be performed, the specifications tested, any special setup

and the inputs and expected outputs.

As stated above, only special setup will be described for each test. To avoid repetition the default setup

for each test is the following

1. The Containers TCS1, TCS2, TCS3 and TCS.SIMS are all loaded

2. All controllers managed by those containers are loaded, initialized and started

3. The TCS JES engineering screens are loaded.

3.1 GENERAL REQUIREMENTS – LOGGING

3.1.1 Requirement “The TCS shall log pertinent data to the DKIST facility log mechanism. Pertinent data shall include but

not be limited to, state changes, configuration changes, errors, alarms and warnings and any other

information that may assist in reconstructing the operation of the TCS. The TCS logging level shall be

user selectable for the depth of information”

3.1.2 Setup Start the LogView CSF tool by issuing the command

LogView &

3.1.3 Tests

Test ID AT4.4-0004-01

Requirement 4.4-0004

Preconditions 1) Ensure the TCS application is in the loaded state.

Test Steps 1) Connect to the atst.tcs controller.

2) Set the “LIFECYCLE” debug level of the atst.tcs controller to 1.

3) Change the lifecycle state of the atst.tcs controller to initialized.

4) Monitor the log file produced for the TCS1 controller and look for the log

messages “Start of init” and “Dome with init”

5) Change the lifecycle state of the atst.tcs controller to running.


messages using the “Start of startup” and “Done with startup”

7) Change the lifecycle state of the atst.tcs controller to initialized.


messages “Start of shutdown” and “Done with shutdown”



9) Change the lifecycle state of the atst.tcs controller to loaded.


messages “Start of uninit” and “Done with uninit”

Pass Criteria 1) Verify that appropriate log messages have been generated for the atst.tcs

controller.

2) Verify the log messages have a mode of “debug”.

3) Verify the log messages have a category of “LIFECYCLE”.

Script AT4-4-0004-01_TAF.py

Notes

Test AT4.4-0004-02


Preconditions 1) Ensure the TCS application is in the loaded state.

2) Ensure the atst.tcs.mcs controller is not running.

Test Steps 1) Change the lifecycle state of the atst.tcs controller from loaded to initialized.


message “Failed to connect to atst.tcs.mcs”

Pass Criteria 1) Verify that warning log messages have been generated for the atst.tcs controller.

2) Verify the log messages have a mode of “warning”.

3) Verify the log messages have a category of “LIFECYCLE MGMT” or

“CONNECT”.

4) Verify the log messages are notifying an operator that connections to the

atst.tcs.mcs cannot be established.


Notes



Test AT4.4-0004-03


Preconditions 1) Ensure the TCS application is in the running state.

2) Ensure the MCS application or MCS simulator application is in the running

state.

3) Ensure the ECS application or ECS simulator application is in the running state.

Test Steps 1) Connect to the atst.tcs.tpk.pk controller.

2) Increase the debug logging of the controller for the categories “FLOW”,

“TIMER” and “VARIABLE”. Use the following commands as examples:

debug atst.tcs.tpk.pk 3 FLOW

debug atst.tcs.tpk.pk 3 TIMER

debug atst.tcs.tpk.pk 5 VARIABLE

3) Monitor the log file produced for the TCS2 controller and look for log

messages in the categories “FLOW”, “TIMER” and “VARIABLE”

Pass Criteria 1) As the debug levels are increased more log messages are generated for the

atst.tcs.tpk.pk controller.

2) The messages logged are relevant to the category under which they are logged.

3) If the debug levels are reset to 0 then no more debug messages are generated in

the controller.


Notes

Test AT4.4-0004-04



2) Ensure the MCS application or MCS simulator application is in the running

state.



3) Ensure the ECS application or ECS simulator application is in the running state.

Test Steps 1) Connect to the atst.tcs.tpk.sollib controller.

2) Increase the debug logging of the controller for the categories “FLOW”,

“TIMER” and “VARIABLE”. Use the following commands as examples:

debug atst.tcs.tpk.sollib 3 FLOW

debug atst.tcs.tpk.sollib 3 TIMER

debug atst.tcs.tpk.sollib 5 VARIABLE

3) Monitor the log file produced for the TCS2 controller and look for log

messages with the categories “FLOW”, “TIMER’ and “VARIABLE” from

atst.tcs.tpk.sollib

Pass Criteria 1) As the debug levels are increased more log messages are generated for the

atst.tcs.tpk.sollib controller.

2) The messages logged are relevant to the category under which they are logged.

3) If the debug levels are reset to 0 then no more debug messages are generated in

the controller.


Notes

3.2 GENERAL REQUIREMENTS – DEFAULT STATE

3.2.1 Requirement “The TCS shall have a defined default state for all operations and control loops that it controls, including

but not limited to, pointing and tracking, thermal control and wave front correction. Unless approved

otherwise by AURA, the default state of any TCS component or controller shall be an inert, non-moving,

non-powered condition. The TCS shall assume this state on an interlock condition, initialization

command, shutdown or when demanded through the software interface”

3.2.2 Setup No special setup is required for these tests

3.2.3 Tests

Test AT4.4-0005-01


Preconditions 1) Ensure the TCS is in the “loaded” state.



Test Steps 1) Attempt to submit a configuration with the attribute mode set to ‘off’.

2) Attempt to submit a configuration with the attribute mode set to ‘active’.

3) Attempt to submit a configuration with the attribute mode set to ‘tracking’.

Pass Criteria 1) Any configuration that is submitted is rejected with the response

“NOT_RUNNING”.

2) The TCS does not enter the “tracking” mode when the request is made.

3) The mount and enclosure positions do not alter when the tracking request is

made.

4) No TCS tracking demand stream events are posted whilst the TCS is in the

“loaded” state. Subscription to the events “atst.tcs.mcsTrajectory” and

“atst.tcs.ecsTrajectory” result in no receipts of events.


Notes

Test AT4.4-0005-02


Preconditions 1) Ensure the TCS is in the “loaded” state.

Test Steps 1) Change the lifecycle state of the atst.tcs controller from “loaded” to

“initialized”.

2) Attempt to submit a configuration with the attribute mode set to ‘off’.



Pass Criteria 1) Any configuration that is submitted is rejected with the message

“NOT_RUNNING”.



made.







Notes

Test AT4.4-0005-03


Preconditions 1) Ensure the TCS is in the “running” state.


2) Shut down the atst.tcs controller.




Pass Criteria 1) The initial configuration is accepted as the controller is running. The TCS is

placed into the ‘off’ mode.

2) Any configuration that is submitted after the atst.tcs controller is shutdown is

rejected with the message “NOT_RUNNING”.



made.


“initialized” state. Subscription to the events “atst.tcs.mcsTrajectory” and





Notes

Test AT4.4-0005-04




2) Shut down and uninit the atst.tcs controller.




Pass Criteria 1) The initial configuration is accepted as the controller is running. The TCS is

placed into the ‘off’ mode.

2) Any configuration that is submitted after the atst.tcs controller is shutdown and

uninitialized is rejected with the message “NOT_RUNNING”.



made.





Notes



3.3 GENERAL REQUIREMENTS – HEALTH

3.3.1 Requirement “The TCS shall be capable of determining its health and report that health through the Common Services

Framework health mechanism. The TCS shall be able to determine if it is performing within its

operational specifications, and return a result of good, ill or bad for TCS health states that are operational,

performing below specification, and not performing at all, respectively. The TCS health report shall

include information on the particular TCS systems that are performing below specification and the

possible reason for the poor health. The TCS shall determine and report the health at least every three

seconds.”

3.3.2 Setup

3.3.3 Tests

Test AT4.4-0007-01



2) Ensure the health of every TCS application controller is in the “Good” state.

Test Steps 1) Shutdown the atst.tcs.tpk.pk controller.

2) Wait for a few seconds.

3) Restart the atst.tcs.tpk.pk controller.

4) Shutdown the atst.tcs.tpk.sollib controller.


6) Restart the atst.tcs.tpk.sollib controller.

7) Shutdown the atst.tcs.seq controller.


9) Restart the atst.tcs.seq controller.

10) Shutdown the atst.tcs.tpk controller.

11) Wait a few seconds.

12) Restart the atst.tcs.tpk controller.

13) Shutdown the atst.tcs.time controller.




15) Restart the atst.tcs.time controller.

16) Shutdown the atst.tcs.time.iers controller.


18) Restart the atst.tcs.time.iers controller.

19) Shutdown the atst.tcs.environment controller.


21) Restart the atst.tcs.environment controller.

22) Shutdown the atst.tcs.guide controller.


24) Restart the atst.tcs.guide controller.

Pass Criteria 1) When each controller is shutdown the TCS overall health (atst.tcs) turns ill and

an appropriate message is generated explaining why the health is no longer

good.

2) A few seconds later the TCS overall health (atst.tcs) turns bad and an

appropriate message is displayed explaining why the health is no longer good.

3) When each controller is restarted the TCS overall health (atst.tcs) turns good

and any health messages are cleared.


Notes

3.4 GENERAL REQUIREMENTS – AVAILABILITY

3.4.1 Requirement “The TCS shall always be available to accept or reject commands. It shall not block any command

request while processing another command request.”

3.4.2 Setup



3.4.3 Tests

Test AT4.4-0008-01



2) Ensure the MCS simulated application is in the running state.

3) Ensure the ECS simulated application is in the running state.

Test Steps 1) Place the TCS into tracking mode.

2) Submit an AZEL target of 50 degrees Azimuth 45 degrees Elevation. Wait for

the TCS to report that the configuration has completed.

3) Submit an AZEL target of 100 degrees Azimuth 80 degrees Elevation. Start the

TCS tracking towards the target.

4) Before the TCS reaches the target select an AZEL target of 20 degrees Azimuth

20 degrees Elevation.

Pass Criteria 1) The TCS accepts the final target demand (step 4) as soon as it is requested.

2) The TCS does not reach the target demand of 100 degrees Azimuth 80 degrees

Elevation.

3) When the final target is requested the mount slows down, changes direction and

slews towards the final target position.

4) The TCS settles at the final target position of 20 degrees Azimuth 20 degrees

Elevation.


Notes

Test AT4.4-0008-02



2) Ensure the MCS simulated application is in the running state.

3) Ensure the ECS simulated application is in the running state.




2) Submit an AZEL target of 20 degrees Azimuth 20 degrees Elevation. Wait for

the TCS to report that the configuration has completed.

3) Submit an AZEL target of 100 degrees Azimuth 80 degrees Elevation. Start the

TCS tracking towards the target.

4) Before the TCS reaches the target submit a mode “off” to the TCS.

Pass Criteria 1) The TCS accepts the “off” mode configuration immediately.

2) The TCS does not reach the target demand of 100 degrees Azimuth 80 degrees

Elevation.

3) When the “off” mode is requested the mount slows down and stops.

4) The mount and enclosure modes are also set to “off”.


Notes

Test AT4.4-0008-03


Preconditions 1) Ensure the TCS application is in the running state

2) Ensure the MCS simulated application is shut down in the loaded state.

3) Ensure the ECS simulated application is shut down in the loaded state.

4) Ensure the PA&C is in the running state

5) Ensure the M1CS is in the running state

6) Ensure the WCCS is in the running state

7) Ensure the TEOACS is in the running state



8) Ensure the FOCS is in the running state

Test Steps 1) Read the current PA&C mode from the atst.tcs.pac.gos.status event attribute

cMode

2) If cMode is “active” then set the PA&C mode to “off” and if cMode is “off” set

the PA&C mode to “active”

3) Restore the original PA&C mode

4) Set the thermalMode to precondition

5) Set the thermalMode to active

6) Set the thermalMode to off

7) Set the aoMode to idle

Pass Criteria 1) The PA&C mode is set to “off” if “off” was demanded or the PA&C mode is

“active” if “active” was demanded

2) The PA&C mode is restored to its original state

3) The M1CS thermal mode is set to precondition

4) The M1CS thermal mode is set to active

5) The M1CS thermal mode is set to off

6) The WCCS mode is set to idle


Notes

3.5 GENERAL REQUIREMENTS – PERSISTENCE OF DATA

3.5.1 Requirement “Static information required by the TCS to operate shall be recoverable after a restart or a reboot. This

information may include, but is not limited to, pointing maps, zero points, ephemeris, and configuration

parameters. Dynamic information, such as current position and state, may be reset or recovered after

initialization.”

3.5.2 Setup



3.5.3 Tests

Test AT4.4-0010-01



2) Ensure the IERS parameters have not been updated for at least one day.

Test Steps 1) Record the current set of IERS data items.

2) Force an update of the IERS parameters (submit a configuration with the

“iersUpdate” attribute).

3) Record the new set of IERS data items.

4) Shutdown the TCS application completely (unload containers) and then reload

the application.

Pass Criteria 1) Once the TCS is reloaded the IERS data items are restored from the latest set of

values (the set recorded from test step 3).


Notes

Step 1 recorded values:

Step 3 recorded values:

3.6 POINTING REQUIREMENTS – TIME

3.6.1 Requirement “The TCS shall use International Atomic Time (TAI) in all calculations. It shall use TAI in all pointing

data distributed to its subsystems.

The TCS shall provide Coordinated Universal Time (UTC) in all displays and status events.”

3.6.2 Setup

UT1 – UTC (s)

xpm (arcsec)

ypm (arcsec)

Last Updated

UT1 – UTC (s)

xpm (arcsec)

ypm (arcsec)

Last Updated



3.6.3 Tests

Test AT4.4-0100-01



Test Steps 1) Subscribe to the event channel “atst.tcs.mcsTrajectory”.

2) Record the time data from one event. The UTC (GMT) entry is called

“__.timestamp” and the TAI entry is called “atst.tcs.mcsTrajectory.tRef”. Only

the first element of the TAI entry is useful.

3) The “atst.tcs.mcsTrajectory.tRef” time value is in MJD format. Convert this to

the same format as the “__.timestamp” entry.

Pass Criteria 1) Both timestamps (UTC and TAI) are present in each event.

2) Once converted to the same format, the TAI timestamp is offset from the UTC

timestamp by the current number of leap seconds. The value may not be exact

as the UTC timestamp of the event was not generated at the same instant the

demand stream was calculated.


Notes

Test AT4.4-0100-02



Test Steps 1) Subscribe to the event channel “atst.tcs.ecsTrajectory”.

2) Record the time data from one event. The UTC (GMT) entry is called

“__.timestamp” and the TAI entry is called “atst.tcs.ecsTrajectory.tRef”. Only

the first element of the TAI entry is useful.

3) The “atst.tcs.ecsTrajectory.tRef” time value is in MJD format. Convert this to

the same format as the “__.timestamp” entry.

Pass Criteria 1) Both timestamps (UTC and TAI) are present in each event.

2) Once converted to the same format, the TAI timestamp is offset from the UTC

timestamp by the current number of leap seconds. The value may not be exact



as the UTC timestamp of the event was not generated at the same instant the

demand stream was calculated.


Notes

Test AT4.4-0100-03



Test Steps 1) Subscribe in turn to each of the following events:

“atst.tcs.cPos”

“atst.tcs.cStatus”

“atst.tcs.mcstrajectory”

“atst.tcs.ecsTrajectory”

“atst.tcs.pk.agvt.WcsContent”

“atst.tcs.pac.gosTrajectory”

“atst.tcs.timesToLimits”

Pass Criteria 1) Each event posted on any of the event channels contains a data item called

“__.timestamp”.

2) Each “__.timestamp” data item contains the GMT (UTC) time at which the

event was posted.


Notes

3.7 POINTING REQUIREMENTS – SOLAR EPHEMERIS

3.7.1 Requirement “The TCS shall calculate the current solar ephemeris, including but not limited to, local apparent sidereal

time, position and rate of motion of the solar disk, the solar rotational axis, and the differential rotation

rates for solar latitudes. The ephemeris data shall have a better accuracy and precision than that required

for pointing and tracking of the telescope mount.”



3.7.2 Setup

3.7.3 Tests

Test AT4.4-0105-01


Preconditions 1) Ensure the TCS is executing in “test” mode (atst.tcs.tpk.pk and atst.tcs.tpk.sollib

controllers).

Test Steps 1) Freeze the time on the TCS and set it to 1st January 2012.

2) Set a helioprojective target of (0.0, 0.0).

3) Execute the solar loops.

4) Record the RA and Dec mount demands and the corresponding differential track

rates.

5) Repeat steps 1 – 4 for the following times:

31st January 2012

1st March 2012

31st March 2012

30th April 2012

30th May 2012

29th June 2012

29th July 2012

28th August 2012

27th September 2012

27th October 2012

26th November 2012

26th December 2012



Pass Criteria 1) The recorded values for RA, Dec, dRA and dDec are within the required

accuracy as defined for pointing and tracking the telescope mount. The table

below presents the values obtained from the JPL ephemeris:

Date RA (degs) Dec (degs) dRA (“/hr) dDec (“/hr)

1st Jan 2012 280.8324550 -23.0645750 150.4330 11.76226

31st Jan 2012 312.9514051 -17.6050692 144.5731 41.50995

1st March 2012 342.2876519 -7.5140899 137.2980 57.14155

31st March 2012 9.8180466 4.2272213 134.2754 57.98435

30th April 2012 37.6472205 14.8303015 136.3084 45.64716

30th May 2012 67.2920069 21.7960194 140.1836 21.75907

29th June 2012 98.3447992 23.2144766 140.8086 -8.57563

29th July 2012 128.6696055 18.6982296 136.8977 -35.8800

28th August 2012 156.9307603 9.6395844 132.8314 -53.1393

27th September 2012 183.9395139 -1.7071068 133.0919 -58.3422

27th October 2012 211.7283843 -12.8437878 138.8807 -50.3950

26th November 2012 242.1459817 -20.9716380 147.1317 -27.8449

26th December 2012 275.0294548 -23.3569716 150.6781 5.67114


Notes Recorded data:



Date RA (degs) Dec (degs) dRA (“/hr) dDec (“/hr)

1st Jan 2012

31st Jan 2012

1st March 2012

31st March 2012

30th April 2012

30th May 2012

29th June 2012

29th July 2012

28th August 2012

27th September 2012

27th October 2012

26th November 2012

26th December 2012

Test AT4.4-0105-02



controllers).

Test Steps 1) Freeze the time on the TCS and set it to 1st January 2012.

2) Set a helioprojective target of (0.0, 0.0).

3) Execute the solar loops.

4) Record the L0, B0 and P values (located on the TCS Engineering main screen

“Solar Disk” tab).

5) Repeat steps 1 – 4 for the following dates:

1st February 2012



1st March 2012

1st April 2012

1st May 2012

1st June 2012

1st July 2012

1st August 2012

1st September 2012

1st October 2012

1st November 2012

1st December 2012

Pass Criteria 1) The recorded values for L0, B0 and P are in agreement with those values from

the Astronomical Almanac, as shown in the table below. It is known that the

values of L0 disagree with the Almanac due to the neglect of light travel time in

Carrington Ephemerides.

Date P (degs) B (degs) L (degs)

1st Jan 2012 2.34 -2.95 117.72

1st February 2012 -11.92 -5.98 69.52

1st March 2012 -21.61 -7.22 47.63

1st April 2012 -26.17 -6.53 359.00

1st May 2012 -24.07 -4.14 322.86

1st June 2012 -15.29 -0.63 272.86

1st July 2012 -2.53 2.90 235.77

1st August 2012 10.95 5.80 185.59

1st September 2012 21.14 7.20 135.84

1st October 2012 25.98 6.71 99.78

1st November 2012 24.43 4.35 50.87

1st December 2012 15.96 0.85 15.40





Date P (degs) B (degs) L (degs)

1st Jan 2012

1st February 2012

1st March 2012

1st April 2012

1st May 2012

1st June 2012

1st July 2012

1st August 2012

1st September 2012

1st October 2012

1st November 2012

1st December 2012

Test AT4.4-0105-03



controllers).

Test Steps 1) Switch the solar differential rotation mode to “none”.

2) Freeze the date and time and set them to 9/10/2012 14:00:00.

3) Select a heliographic target position of 0.0, 45.0.

4) Reset the date and time to 1 hour in the future and run the solar loops.

5) Record the heliographic demand position (obtained from the TCS Engineering

main screen “Data” tab).

6) Switch the solar differential rotation mode to “standard”.



7) Freeze the date and time and reset them to the same as in step 2.

8) Reset the heliographic target position to that defined in step 3.



main screen, “Data” tab).

11) Switch the solar differential tracking mode to “custom” and set the solar

differential rotation coefficients as follows:

ω1 = -1.8

ω2 = 0.2

12) Freeze the date and time and reset them to the same as in step 2.

13) Reset the heliographic target position to that defined in step 3.



main screen, “Data” tab).

Pass Criteria 1) Verify the Carrington heliographic position value recorded in step 5 has shifted

by the amount expected for the standard model i.e. to the demand heliographic

position -0.059102, 45.0.

2) Verify the heliographic position value recorded in step 10 has an additional

adjustment calculated using the standard solar differential rotation model

coefficients. Value = 359.95833, 45.0.

3) Verify the heliographic position value recorded in step 15 has an additional

adjustment calculated using the custom solar differential rotation model

coefficients defined in step 11. Value = 359.96458, 45.0.


Notes

Recorded heliographic values:

No rotation: Θ Φ

Standard rotation: Θ Φ

Custom rotation: Θ Φ



3.8 POINTING REQUIREMENTS – EPHEMERIS PREDICTION

3.8.1 Requirement “The TCS shall provide a stand-alone CSF service to perform solar, planetary and stellar ephemeris

calculations on demand for requested epochs.

The service shall calculate on demand the solar ephemerides and telescope positions for requested epochs

or conditions. In particular, the service shall be capable of calculating time and location for any date of

the following: sunrise, sunset, 10 degrees elevation both after sunrise and before sunset, local noon, zenith

blind spot entrance and exit. The service shall calculate the values for any date between years 2000 and

2100.”

3.8.2 Setup

3.8.3 Tests

Test AT4.4-0110-01


Preconditions 1) Ensure the ATST Oracle screen is open.

Test Steps 1) Right click on the “TCS.EPHEM” container lifecycle widget and select

“Deploy”.

2) Once the container has deployed right click on the “TCS.EPHEM” container

lifecycle widget and select “Start”.

3) After the “atst.tcs.ephem” controller has been loaded right click on the

“atst.tcs.ephem” controller lifecycle widget and select “Initialize”.

4) Right click on the “atst.tcs.ephem” controller lifecycle widget and select

“Startup”.

5) In the “Oracle (Retrieve Data)” widget click on the “Get” button.

Pass Criteria 1) Verify the Oracle service container and controller start. Both lifecycle widgets

turn green.

2) Verify that when the “Get” button is clicked the data is retrieved from the



Oracle. The table of data is populated with values and the small solar schematic

image is updated with lines of heliographic longitude and latitude.

Script N/A

Notes

Test AT4.4-0110-02


Preconditions 1) Ensure the “atst.tcs.ephem” controller is in the “running” state.

Test Steps 1) From a terminal execute the test script to compare the differences of P, B0, L0

and diameter generated by the Oracle with those from the Astronomical

Almanac. It is known that the values of L0 disagree with the Almanac due to

the neglect of light travel time in Carrington Ephemerides.

Pass Criteria 1) Verify the following output from the test script: [ajg@osllx10 test]$ RunScript < Ephem_Test_001.py

Using jython as interpreter.

----------------------------------------

Terminate each fragment with EOF.

(EOF with empty fragment ends program)

----------------------------------------

--> Running: #!/usr/bin/env python

MJD P (deg) B (deg) L (deg) Diameter (")

Calc Expected Calc Expected Calc Expected Calc Expected

55928.0 1.86 1.86 -3.06 -3.06 104.63 104.55 1951.92 1951.86

55959.0 -12.33 -12.33 -6.05 -6.05 56.43 56.35 1947.84 1947.78

55988.0 -21.86 -21.86 -7.23 -7.23 34.54 34.46 1936.59 1936.52

56019.0 -26.20 -26.20 -6.47 -6.47 345.88 345.81 1920.22 1920.14

56049.0 -23.88 -23.88 -4.04 -4.04 309.72 309.65 1904.47 1904.40

56080.0 -14.92 -14.92 -0.51 -0.51 259.70 259.62 1892.54 1892.46

56110.0 -2.07 -2.07 3.01 3.01 222.61 222.54 1887.91 1887.84

56141.0 11.35 11.35 5.88 5.87 172.44 172.36 1891.37 1891.30

56172.0 21.39 21.39 7.21 7.21 122.71 122.63 1902.39 1902.32

56202.0 26.04 26.04 6.66 6.66 86.66 86.59 1917.75 1917.70

56233.0 24.26 24.26 4.25 4.25 37.76 37.69 1934.43 1934.38

56263.0 15.57 15.57 0.72 0.72 2.29 2.22 1946.86 1946.80

Time offset (s) implied by longitude shift -490.68 +/- 18.65

Script Ephem_Test_001_TAF.py

Notes



Test AT4.4-0110-03



Test Steps 1) From a terminal execute the test script to compare the sun rise and sun set times

as calculated by the Oracle with those published and interpolated from the

Astronomical Almanac. The times are compared over a range of dates and a

printout of the differences is displayed. Note that for comparison with the

Almanac values the test first sets the height above sea-level to 0.0 and then

restores the original value at the end. Note also that the raw Almanac values

prior to interpolation are only accurate to +/- 30s

Pass Criteria 1) Verify the following output from the test script:

[ajg@osllx10 test]$ RunScript < Ephem_Test_002.py


----------------------------------------



----------------------------------------


Date Sunrise Sunset

Oracle Almanac O-A (s) Oracle Almanac O-A (s)

Jan. 3 07:02:06 07:02:33 -26 17:56:55 17:56:52 2

Jan. 15 07:04:05 07:04:21 -16 18:04:49 18:04:54 -5

Feb. 4 07:00:30 07:00:47 -17 18:17:33 18:17:16 17

Feb. 16 06:54:28 06:54:34 -5 18:23:56 18:23:32 23

Mar. 3 06:43:05 06:43:03 2 18:30:42 18:30:47 -5

Mar. 15 06:32:55 06:32:49 5 18:34:44 18:35:00 -16

Apr. 4 06:15:08 06:15:10 -2 18:40:41 18:40:34 7

Apr. 16 06:05:06 06:05:03 3 18:44:24 18:44:47 -23

May 2 05:53:57 05:53:48 8 18:50:07 18:50:14 -7

May 14 05:47:57 05:47:42 14 18:54:58 18:55:21 -22

Jun. 3 05:43:31 05:43:32 -1 19:03:14 19:03:37 -23

Jun. 15 05:44:10 05:43:38 31 19:07:14 19:07:41 -27

Jul. 1 05:48:05 05:47:45 20 19:09:56 19:10:30 -34

Aug. 2 06:00:03 06:00:00 2 19:02:08 19:01:56 11

Sep. 3 06:09:36 06:09:39 -2 18:38:16 18:38:11 5

Oct. 1 06:16:16 06:16:17 -1 18:12:14 18:12:22 -7

Nov. 2 06:28:11 06:28:10 1 17:48:44 17:48:53 -8

Dec. 4 06:47:22 06:47:40 -17 17:43:40 17:43:43 -2


Notes



Test AT4.4-0110-04


Preconditions 1) Ensure the “atst.tcs.ephem” controller is in the “uninitialized” state.

2) Ensure the containers TCS1 and TCS2 are not deployed

Test Steps 1) From a terminal execute the test script to compare the topocentric RA and Dec

values generated by the Oracle with those from the JPL ephemeris. The table

shows the JPL values for RA and Dec and the differential track rates. The

differences with each value calculated by the Oracle is then displayed in the

columns headed “O-J”. Units are provided in each column header.




----------------------------------------



----------------------------------------


JPL airless Apparent ("/hr) ("/hr) O-J(") O-J(") O-

J("/hr) O-J("/hr)

Date RA Dec dRA dDec dRA dDec ddRA

ddDec

Jan. 1 18 43 19.79 -23 03 52.470 150.4330 11.7623 -0.259 0.049 -0.000

-0.000

Jan. 31 20 51 48.34 -17 36 18.249 144.5731 41.5100 -0.258 0.041 0.000

-0.000

Mar. 1 22 49 9.04 -07 30 50.724 137.2980 57.1416 -0.250 0.027 0.000

0.000

Mar. 31 00 39 16.33 04 13 37.997 134.2754 57.9844 -0.244 0.004 0.000

0.000

Apr. 30 02 30 35.33 14 49 49.085 136.3084 45.6472 -0.242 -0.022 0.000

0.000

May 30 04 29 10.08 21 47 45.670 140.1836 21.7591 -0.250 -0.042 0.000

0.000

Jun. 29 06 33 22.75 23 12 52.116 140.8086 -8.5756 -0.259 -0.049 -0.000

0.000

Jul. 29 08 34 40.71 18 41 53.627 136.8977 -35.8800 -0.261 -0.041 -0.000

0.000

Aug. 28 10 27 43.38 09 38 22.504 132.8314 -53.1393 -0.253 -0.027 -0.000

0.000

Sep. 27 12 15 45.48 -01 42 25.584 133.0919 -58.3422 -0.247 -0.003 -0.000

0.000

Oct. 27 14 06 54.81 -12 50 37.636 138.8807 -50.3950 -0.248 0.023 -0.000

0.000

Nov. 26 16 08 35.04 -20 58 17.897 147.1317 -27.8449 -0.254 0.041 -0.000

-0.000

Dec. 26 18 20 7.07 -23 21 25.098 150.6781 5.6711 -0.262 0.046 -0.000

-0.000 Script Ephem_Test_003_TAF.py



Notes These data were generated with the following values in the constants database

latitude,"N 20 42 25.5","Latitude of ATST"

longitude,"W 156 15 27.4","Longitude of ATST"

height,3055,"Elevation of ATST"

It is important that the containers TCS1 and TCS2 are not deployed whilst this test is run

or else different values of "delat", "delut", "xpm" and "ypm" may be retrieved from the

controller's cache's.

Test AT4.4-0110-05


Preconditions 1) Ensure the “atst.tcs.ephem” controller is in the “un-initialized” state.

2) Ensure the containers TCS1 and TCS2 are not deployed

Test Steps 1) From a terminal execute the test script to compare the topocentric Ra and Dec

values generated by the Oracle with those form the JPL ephemeris. The

difference with the previous test is that the Ra and Dec values are retrieved from

attributes that always refer to the center of the sun. The table shows the JPL

values for Ra and Dec and the differential track rates. The differences with each

value calculated by the Oracle is then displayed in the columns headed “O-J”.

Units are provided in each column header. This should give identical results as

the previous test.




----------------------------------------



----------------------------------------


JPL airless Apparent ("/hr) ("/hr) O-J(") O-J(") O-

J("/hr) O-J("/hr)


ddDec

Jan. 1 18 43 19.79 -23 03 52.470 150.4330 11.7623 -0.259 0.049 -0.000

-0.000

Jan. 31 20 51 48.34 -17 36 18.249 144.5731 41.5100 -0.258 0.041 0.000

-0.000

Mar. 1 22 49 9.04 -07 30 50.724 137.2980 57.1416 -0.250 0.027 0.000

0.000

Mar. 31 00 39 16.33 04 13 37.997 134.2754 57.9844 -0.244 0.004 0.000

0.000

Apr. 30 02 30 35.33 14 49 49.085 136.3084 45.6472 -0.242 -0.022 0.000

0.000

May 30 04 29 10.08 21 47 45.670 140.1836 21.7591 -0.250 -0.042 0.000

0.000

Jun. 29 06 33 22.75 23 12 52.116 140.8086 -8.5756 -0.259 -0.049 -0.000

0.000

Jul. 29 08 34 40.71 18 41 53.627 136.8977 -35.8800 -0.261 -0.041 -0.000

0.000

Aug. 28 10 27 43.38 09 38 22.504 132.8314 -53.1393 -0.253 -0.027 -0.000

0.000

Sep. 27 12 15 45.48 -01 42 25.584 133.0919 -58.3422 -0.247 -0.003 -0.000



0.000

Oct. 27 14 06 54.81 -12 50 37.636 138.8807 -50.3950 -0.248 0.023 -0.000

0.000

Nov. 26 16 08 35.04 -20 58 17.897 147.1317 -27.8449 -0.254 0.041 -0.000

-0.000

Dec. 26 18 20 7.07 -23 21 25.098 150.6781 5.6711 -0.262 0.046 -0.000

-0.000









Test AT4.4-0110-06



Test Steps 1) From a terminal execute the test script to compare the ICRS Ra and Dec values

generated by the Oracle with those from the JPL ephemeris. The table shows

the JPL values for Ra and Dec and the differential track rates. The differences

with each value calculated by the Oracle is then displayed in the columns

headed “O-J”. Units are provided in each column header.




----------------------------------------



----------------------------------------


JPL J2000 ("/hr) ("/hr) O-J(") O-J(") O-

J("/hr) O-J("/hr)


ddDec

Jan. 1 18 42 36.465 -23 04 40.00 150.4330 11.7623 0.430 0.029 -0.015

-0.000

Jan. 31 20 51 7.671 -17 39 4.23 144.5731 41.5100 0.357 0.095 -0.037

-0.000

Mar. 1 22 48 31.208 -07 34 42.28 137.2980 57.1416 0.211 0.085 -0.020

0.000

Mar. 31 00 38 38.732 04 09 38.45 134.2754 57.9844 0.049 0.019 0.012

0.000

Apr. 30 02 29 55.066 14 46 37.05 136.3084 45.6472 -0.111 -0.039 0.034

0.000

May 30 04 28 26.135 21 46 13.91 140.1836 21.7591 -0.253 -0.039 0.025

0.000

Jun. 29 06 32 37.585 23 13 32.28 140.8086 -8.5756 -0.316 0.016 -0.012

0.000

Jul. 29 08 33 57.896 18 44 33.36 136.8977 -35.8800 -0.271 0.068 -0.036

0.000

Aug. 28 10 27 3.619 09 42 15.85 132.8314 -53.1393 -0.152 0.061 -0.026



0.000

Sep. 27 12 15 6.605 -01 38 13.42 133.0919 -58.3422 -0.004 0.004 0.004

0.000

Oct. 27 14 06 13.744 -12 47 3.83 138.8807 -50.3950 0.166 -0.057 0.033

0.000

Nov. 26 16 07 49.987 -20 56 23.00 147.1317 -27.8449 0.341 -0.060 0.031

-0.000

Dec. 26 18 19 20.157 -23 21 53.23 150.6781 5.6711 0.435 0.014 -0.009

-0.000


Notes

Test AT4.4-0110-07



Test Steps 1) From a terminal execute the test script to predict the time at which the sun

reaches a range of angles (sunrise and sunset) for June 1st 2012.




----------------------------------------



----------------------------------------


Original values of sunrise and sunset elevation angles (degs)

Sunrise = 10.0 Sunset = 10.0

Predictions are for June 1 2012

Elevation limit (degs) Sunrise Sunset

0.0 05:35:18 19:10:50

0.5 05:37:59 19:08:08

1.0 05:40:40 19:05:27

1.5 05:43:21 19:02:47

2.0 05:46:01 19:00:06

2.5 05:48:41 18:57:26

3.0 05:51:21 18:54:46

3.5 05:54:00 18:52:06

4.0 05:56:05 18:50:01

4.5 05:58:27 18:47:40

5.0 06:00:48 18:45:18

5.5 06:03:09 18:42:57

6.0 06:05:29 18:40:37

6.5 06:07:50 18:38:16

7.0 06:10:09 18:35:56



7.5 06:12:29 18:33:37

8.0 06:14:48 18:31:18

8.5 06:17:07 18:28:59

9.0 06:19:26 18:26:40

9.5 06:21:44 18:24:21

10.0 06:24:02 18:22:03

10.5 06:26:20 18:19:45

11.0 06:28:38 18:17:27

11.5 06:30:55 18:15:10

12.0 06:33:13 18:12:52

12.5 06:35:30 18:10:35

13.0 06:37:47 18:08:18

13.5 06:40:03 18:06:01

14.0 06:42:20 18:03:45

14.5 06:44:36 18:01:28

15.0 06:46:52 17:59:12


Notes

Test AT4.4-0110-08



2) Ensure that the containers TCS1 and TCS2 are not deployed

Test Steps 1) From a terminal execute the test script to compare the values of the local noon

calculated by the Oracle with those calculated using the NOAA “New” solar

calculator. A table of differences is presented for the first of each month.




----------------------------------------



----------------------------------------


Comparison of local noon as computed by ephemeris service with

values from NOAA "new" solar calculator

Date Local Noon (NOAA) Local Noon N-E (s)

Jan. 1 12 28 33.0 12:28:32 0.04

Feb. 1 12 38 37.0 12:38:35 1.79

Mar. 1 12 37 12.0 12:37:10 1.01

Apr. 1 12 28 38.0 12:28:38 -0.41



May 1 12 22 2.0 12:22:01 0.56

Jun. 1 12 23 0.0 12:22:59 0.35

Jul. 1 12 29 3.0 12:29:03 -0.54

Aug. 1 12 31 18.0 12:31:18 -0.04

Sep. 1 12 24 46.0 12:24:44 1.27

Oct. 1 12 14 26.0 12:14:24 1.43

Nov. 1 12 08 34.0 12:08:35 -1.96

Dec. 1 12 14 24.0 12:14:22 1.09









Test AT4.4-0110-09



Test Steps 1) From a terminal execute the test script to compare the astronomical twilight start

and end times generated by the Oracle with those obtained from the

Astronomical Almanac. The table shows the two sets of times and also shows

the difference between them in seconds.




----------------------------------------



----------------------------------------


Date Twilight start Twilight end

Oracle Almanac O-A (s) Oracle Almanac O-A (s)

Jan. 3 05:43:22 05:43:07 14 19:15:38 19:15:25 12

Feb. 4 05:44:48 05:44:28 19 19:33:14 19:33:35 -20

Mar. 3 05:29:32 05:29:37 -5 19:44:18 19:44:13 4

Apr. 4 05:00:31 05:00:40 -8 19:55:25 19:55:10 14

May 2 04:35:19 04:35:04 15 20:08:55 20:08:57 -1

Jun. 3 04:19:46 04:19:35 10 20:27:04 20:27:34 -30

Jul. 1 04:23:42 04:23:44 -1 20:34:15 20:34:25 -10

Aug. 2 04:40:08 04:39:25 43 20:21:52 20:22:27 -34

Sep. 3 04:53:52 04:54:09 -16 19:55:10 19:53:34 96

Oct. 1 05:02:47 05:02:51 -4 19:25:40 19:25:48 -8

Nov. 2 05:12:53 05:12:44 8 19:04:03 19:04:19 -15

Dec. 4 05:28:53 05:29:10 -16 19:02:09 19:02:12 -2




Notes The original data from the Almanac from which the data displayed here is interpolated is

only given to the nearest minute of time.

Test AT4.4-0110-10



Test Steps 1) From a terminal execute the test script to compute for each day what time a

solar target will enter and leave the zenith blind spot. The dates and times are

only printed if the blind spot is entered. The test is run for the year 2012.




----------------------------------------



----------------------------------------


Date Enter blind spot Leave blind spot Local noon

May 20 12:21:29 12:21:43 12:21:36

May 21 12:19:58 12:23:23 12:21:41

May 22 12:19:40 12:23:51 12:21:45

May 23 12:19:44 12:23:57 12:21:51

May 24 12:20:07 12:23:46 12:21:57

May 25 12:21:01 12:23:05 12:22:03

Jul. 16 12:30:22 12:31:59 12:31:10

Jul. 17 12:29:30 12:33:00 12:31:15

Jul. 18 12:29:14 12:33:25 12:31:20

Jul. 19 12:29:16 12:33:30 12:31:23

Jul. 20 12:29:38 12:33:15 12:31:27

Jul. 21 12:30:40 12:32:17 12:31:29


Notes The dates here bridge a leap second on June 30th. The data is generated using the IERS

data for May 23rd



Test AT4.4-0110-11




Test Steps 1) From a terminal execute the test script to compute the effect of changing the

zenith blind spot radius between 2.0 and 0.1 degrees for the solar center on May

23rd 2012. The table shows the values calculated at 0.1 degree intervals.




----------------------------------------



----------------------------------------


Radius (deg) Enter blind spot Leave blind spot

0.1 12:21:36 12:22:06

0.2 12:21:04 12:22:38

0.3 12:20:36 12:23:05

0.4 12:20:10 12:23:31

0.5 12:19:44 12:23:57

0.6 12:19:18 12:24:23

0.7 12:18:52 12:24:49

0.8 12:18:26 12:25:15

0.9 12:18:01 12:25:41

1.0 12:17:35 12:26:06

1.1 12:17:09 12:26:32

1.2 12:16:43 12:26:58

1.3 12:16:18 12:27:24

1.4 12:15:52 12:27:49

1.5 12:15:26 12:28:15

1.6 12:15:00 12:28:41

1.7 12:14:35 12:29:06

1.8 12:14:09 12:29:32

1.9 12:13:43 12:29:58

2.0 12:13:18 12:30:23


Notes

Test AT4.4-0110-12






Test Steps 1) From a terminal execute the test script to compute the effect on the entry and

exit times from the zenith blind spot as the target is varied from -1.0 to +1.0 in

helioprojective coordinates (where 1.0 is equal to the solar radius). The date is

set to May 23rd 2012. The tables shows the helioprojective coordinates in

arcseconds and the entry and exit times.




----------------------------------------



----------------------------------------


HP coords Enter blind spot Leave blind spot

-947.6, 0.0 12:20:54 12:24:56

-852.9, 0.0 12:20:46 12:24:51

-758.1, 0.0 12:20:39 12:24:45

-663.4, 0.0 12:20:32 12:24:39

-568.6, 0.0 12:20:25 12:24:33

-473.8, 0.0 12:20:18 12:24:27

-379.1, 0.0 12:20:11 12:24:21

-284.3, 0.0 12:20:04 12:24:15

-189.5, 0.0 12:19:58 12:24:09

-94.8, 0.0 12:19:51 12:24:03

0.0, 0.0 12:19:44 12:23:57

94.8, 0.0 12:19:37 12:23:51

189.5, 0.0 12:19:31 12:23:45

284.3, 0.0 12:19:24 12:23:39

379.1, 0.0 12:19:17 12:23:33

473.8, 0.0 12:19:11 12:23:26

568.6, 0.0 12:19:04 12:23:20

663.4, 0.0 12:18:58 12:23:14

758.1, 0.0 12:18:51 12:23:08

852.9, 0.0 12:18:45 12:23:01

947.6, 0.0 12:18:38 12:22:55


Notes

Test AT4.4-0110-13





Test Steps 1) From a terminal execute the test script to generate the predicted positions of the

planets on a certain data and compare them with the values predicted by the JPL

Horizons service




----------------------------------------



----------------------------------------


Computation of body positions on November 24 2012

and comparison with JPL values from the same time.

Body RA (degs) O-J (") Dec (degs) O-J (")

mercury 227.13661 -0.279 -15.42324 0.057

venus 210.82925 -0.187 -10.65129 0.039

mars 275.74183 -0.371 -24.46864 -0.031

jupiter 71.17233 0.295 21.49019 0.008

saturn 214.29690 -0.137 -11.34319 0.031

uranus 4.67226 -0.058 1.22640 -0.096

neptune 332.69753 -0.076 -11.90349 -0.095

pluto 278.53463 -0.416 -19.79045 0.119


Notes

Test AT4.4-0110-14



Test Steps 1) From a terminal execute the test script to generate the predicted positions of the

planets, minor bodies and comets on a certain data and compare them with the

values predicted by the JPL Horizons service






----------------------------------------



----------------------------------------


Computation of body positions for objects using elements

and comparison with JPL values for the same time.

Body RA (degs) O-J (") Dec (degs) O-J (")

Mars 284.11613 -0.017 -23.96484 -0.001

Mars 290.81206 -0.015 -23.23522 0.007

Vesta 76.33935 0.030 17.77548 -0.015

Halley 129.14329 0.014 0.84156 -0.019

Hale-Bopp 357.20485 -0.046 -86.27886 -0.001


Notes

3.9 POINTING REQUIREMENTS – STELLAR EPHEMERIS

3.9.1 Requirement “The TCS shall calculate the current ephemeris for any input stellar coordinate. The ephemeris data shall

contain the information necessary to point the telescope mount assembly at the object to the precision and

accuracy of the telescope as found in SPEC-0011 Req. 1.1-0170. The TCS shall provide an input

mechanism to accept stellar coordinates in Right Ascension, declination and epoch.”

3.9.2 Setup

3.9.3 Tests

Test AT4.4-0120-01



Test Steps 1) Submit a valid target RA and Dec with a coordinate system of “FK5” to the

atst.tcs controller

2) Monitor the current target position and the atst.tcs.tpk.sollib controller mode.

Pass Criteria 1) Verify the coordinate system is set to the same that was requested for the target.

2) Verify the target position coordinates are in RA and Dec and they match what

was requested for the target.



3) Verify the solar library mode is set to inactive.


Notes

Test AT4.4-0120-02


Preconditions 1) Configure the TCS to emulate Gemini North by loading the property file

gemini_north_tcs

2) Ensure the TCS is executing in “test” mode (atst.tcs.tpk.pk and atst.tcs.tpk.sollib

controllers).

Test Steps 1) Freeze the time on the TCS and set it to 20th November 2012 15:13:30.000

2) Submit a target to the atst.tcs controller with the following parameters:

Cosys: FK5

Ra: 07 00 00.000

Dec: +30 00 00.000

3) Execute the pointing kernel loops.

4) Record the Azimuth and Altitude mount demands for the target.

5) Repeat steps 1 – 4 for the following times and targets

22nd November 2012 13:00:30.000 RA 7 Dec 30



22nd November 2012 13:41 16.000 RA 10 Dec -10



Pass Criteria 1) The recorded values for Azimuth and Altitude are within the required accuracy

as defined for pointing and tracking the telescope mount. The table below

presents the values obtained from the Gemini North telescope

Date Azimuth (degs) Altitude (degs)

20 Nov.2012 15:30:30.000 297.5597255690 63.0779953899

22 Nov. 2012 13:00:30.000 17.3404004589 79.4424023824

22 Nov. 2012 09:57:50.000 67.0822893124 44.4989979378

22 Nov. 2012 13:19:48.000 187.1093158395 80.1772904227

22 Nov 2012 13:41:16:000 124.9521045417 41.9417015101



Date Azimuth (degs) Altitude (degs)

20 Nov.2012 15:30:30.000

22 Nov. 2012 13:00:30.000

22 Nov. 2012 09:57:50.000

22 Nov. 2012 13:19:48.000

22 Nov 2012 13:41:16:000

Test AT4.4-0120-03


Preconditions 1) Set the coude angle to 30.0 degrees

2) Shutdown the TCS and then restart it configured as demo by loading the file

demo_tcs

3) Ensure the TCS is executing in “test” mode (atst.tcs.tpk.pk and atst.tcs.tpk.sollib

controllers).



Test Steps 6) Freeze the time on the TCS and set it to 27th July 2012 15:26:00.000

7) Submit a target to the atst.tcs controller with the following parameters:

Cosys: FK4

Ra: 01 23 45.600

Dec: +19 00 00.000

8) Execute the pointing kernel loops.

9) Record the Azimuth and Altitude mount demands for the target.

10) Repeat steps 6 – 9 after setting guiding corrections ga = 0.0, gb = 22.0 arcsecs

11) Repeat steps 6 – 10 after setting simple target offsets of dRA = 1.0 and dDec =

60.0 arcsecs

12) Repeat steps 6 – 11 after setting base pointing origins of 180.0, -150.0 and

pointing origin offsets of -1.0, -2.0

Pass Criteria 4) The recorded values for Azimuth and Altitude are within the required accuracy

as defined for pointing and tracking the telescope mount. The table below

presents the values obtained from the demo program

Azimuth (degs) Altitude (degs) Rotator (degs)

170.5830547924 89.2695074351 269.2851144086

170.5830548004 89.2633966196 269.2790003340

170.0494514762 89.2794200693 269.2936335799

161.5140869784 89.2923532621 269.3779071033



Azimuth (degs) Altitude (degs) Rotator (degs)



3.10 POINTING REQUIREMENTS – PLANETARY EPHEMERIS

3.10.1 Requirement “The TCS shall calculate the current ephemeris for any planet or major solar system body up to the year

2100. The ephemeris data shall contain the information necessary to point the telescope mount assembly

at the object to the precision and accuracy of the telescope as found in SPEC-0011 Req. 1.1-0170. The

TCS shall provide an input mechanism to accept both the IAU name of the body and the orbital

parameters of the body.”

3.10.2 Setup

3.10.3 Tests

Test AT4.4-0125-01


Preconditions 1) Ensure the TCS is running and operating in "test" mode

Test Steps 1) Set the time to 24th November 2012 00:00 UTC

2) Set the atst.tcs.planet attribute to "mercury"

3) Execute the pointing loops

4) Record the topocentric RA and Dec demands

5) Repeat steps 1 - 4 for Venus, Mars, Jupiter, Saturn, Uranus, Neptune, Pluto

Pass Criteria 1) Compare the demanded positions and track rates with the following data from

the JPL Horizons service

Planet RA (degs) Dec (degs)

Mercury 227.13669 -15.42326

Venus 210.82930 -10.65130

Mars 275.74193 -24.46863

Jupiter 71.17225 21.49019

Saturn 214.29694 -11.34320

Uranus 4.67228 1.22643

Neptune 332.69755 -11.90346

Pluto 278.53475 -19.79048




Notes

Test AT4.4-0125-02


Preconditions 1) Ensure the TCS is running and operating in "test" mode.

2) Ensure horizon checking is turned off.

Test Steps 1) Set the time to 4th December 2012 00:00 UTC.

2) Set the orbital element attributes as follows (these are the elements for Mars):

atst.tcs.elementsForm Major planets

atst.tcs.elementsType JPL

atst.tcs.elementsEpoch 56265.0

atst.tcs.elementsInclination 1.848697552627321

elementsANode 49.52480350039695

atst.tcs.elementsPerihelion 286.5374227009734

atst.tcs.elementsAorQ 1.523643578157665

atst.tcs.elementsEccentricity 0.09329598879980641

atst.tcs.elementsAorL 333.0805938015026

atst.tcs.elementsDailyMotion 0.5240576507483696

3) Execute the pointing loops.

4) Record the topocentric RA and Dec demands.

5) Set the time to 12th December 2012 00:00 UTC.

6) Set the orbital element attributes as follows (these are the elements for Mars):

atst.tcs.elementsForm Major planets















10) Set the orbital element attributes as follows (these are the elements for Vesta):

atst.tcs.elementsForm Minor planets













14) Set the orbital element attributes as follows (these are the elements for Halley):

atst.tcs.elementsForm Comets













18) Set the orbital element attributes as follows (these are the elements for Hale-

Bopp):



atst.tcs.elementsForm Comets












Pass Criteria 1) Compare the demanded positions and track rates with the following data from

the JPL Horizons service

Test Step RA (degs) Dec (degs)

Step 2 284.11613 -23.96484

290.81206 Step 6 290.81206 -23.23522

Step 10 76.33934 17.77548

Step 14 129.14329 0.84157

Step 18 357.20486 -86.27886


Notes

Test AT4.4-0125-03



Test Steps 1) Set the time to 5th June 2012 22:00 UTC

2) Set the atst.tcs.planet attribute to "venus"





5) Set the target frame to HP and the coordinates to 0.0, 0.0


7) Record the topocentric RA and Dec of the solar center along with the solar

diameter

8) Compute the tangent plane separation of the center of Venus and the center of

the solar disk in arcsecs and in units of solar radii

9) Repeat the above at half hour intervals until 6th June 2012 05:00 UTC

10) Calculate the times of ingress, egress and maximum transit

Pass Criteria 1) The time of ingress is close to 22:18:57 UTC

2) The time of greatest transit is close to 01:26:20 UTC

3) The separation at greatest transit is 554.4 arcsecs

4) The time of egress is close to 04:35:38 UTC


Notes 1. The script will fail if any computed position is different from the JPL

predictions by more than 0.5 arcsecs

2. Most published transit times are for an observer at the geocenter whereas the

times calculated here are for an observer at the ATST on Haleakela

3. The comparison times here are taken from those published by F. Espenak for

Honolulu in "The 2012 Transit of Venus" and so will not agree exactly with the

numbers calculated by the script

Test AT4.4-0125-04



Test Steps 1) Set the time to 11th November 2019 12:00 UTC

2) Set the atst.tcs.planet attribute to "mercury"





5) Set the target frame to HP and the coordinates to 0.0, 0.0


7) Record the topocentric RA and Dec of the solar center along with the solar

diameter

8) Compute the tangent plane separation of the center of Mercury and the center of

the solar disk in arcsecs and in units of solar radii

9) Repeat the above at half hour intervals until 11th November 2019 18:30 UTC

10) Calculate the times of ingress, egress and maximum transit

Pass Criteria 1) The time of ingress is close to 12:36 UTC

2) The time of greatest transit is close to 15:20 UTC

3) The separation at greatest transit is 75.9 arcsecs

4) The time of egress is close to 18:03 UTC


Notes 1. The script will fail if any computed position is different from the JPL

predictions by more than 0.5 arcsecs

2. The published transit times are for an observer at the geocenter whereas the

times calculated here are for an observer at the ATST on Haleakela

3. The comparison times here are taken from those published by F. Espenak on

eclipse.gsfc.nasa.gov/transit/catalog/MercuryCatalog.html

4. The transit will only be visible above the lower elevation limit of 7 degrees for

the last 53 minutes i.e. from 17:10 UTC

3.11 POINTING REQUIREMENTS – POINTING

3.11.1 Requirement “The TCS shall provide pointing information to the telescope altitude, azimuth and coudé rotator

controllers at a rate of at least 20 Hz and within the accuracy and precision requirements for these

systems. All pointing information shall be corrected for repeatable errors due to flexure, temperature,

atmosphere, and wavelength.

The TCS shall provide pointing information for the following Telescope Mount Assembly (TMA)

controllers:

The TMA azimuth: The pointing information for the TMA azimuth positions shall be given in

degrees from true North, with negative values indicating positions counter-clockwise as viewed

from above.



The TMA altitude: The pointing information for the TMA altitude shall be given in degrees from

the horizon, with values greater than 90 degrees indicating motion beyond the zenith.

The TMA coudé rotator: The pointing information for the TMA coudé rotator shall be given in

degrees from true North, with negative values indicating positions counter-clockwise as viewed

from above.

The PA&C Gregorian focus: The pointing information for the Gregorian focus shall be given in

degrees from the TMA structure North.

The Prime focus: The pointing information for the prime focus shall be given in degrees from the

TMA structure North.”

3.11.2 Setup

3.11.3 Tests

Test AT4.4-0130-01



Test Steps 1) Subscribe to the event channel “atst.tcs.mcsTrajectory”.

2) Record the events for a period of 30 seconds.

Pass Criteria 1) Verify the event contains coefficients for the azimuth position demands. The

data item is called “atst.tcs.mcsTrajectory.azCoeff”.

2) Verify the event contains coefficients for the altitude position demands. The

data item is called “atst.tcs.mcsTrajectory.altCoeff”.

3) Verify the event contains coefficients for the coudé rotator position demands.

The data item is called “atst.tcs.mcsTrajectory.coudeCoeff”.

4) Verify the events are received at a rate of 20Hz.


Notes

Test AT4.4-0130-02



Test Steps 1) Subscribe to the event channel “atst.tcs.ecsTrajectory”.




Pass Criteria 1) Verify the event contains coefficients for the carousel position demands. The

data item is called “atst.tcs.ecsTrajectory.azCoeff”.

2) Verify the event contains coefficients for the shutter position demands. The

data item is called “atst.tcs.ecsTrajectory.altCoeff”.



Notes

Test AT4.4-0130-03



Test Steps 1) Subscribe to the event channel “atst.tcs.pac.gosTrajectory”.


Pass Criteria 1) Verify the event contains coefficients for the helioprojective radial radius

position demands. The data item is called

“atst.tcs.pac.gosTrajectory.hprRadius”.

2) Verify the event contains coefficients for the helioprojective radial angle

position demands. The data item is called

“atst.tcs.pac.gosTrajectory.hprAngle”.



Notes



3.12 POINTING REQUIREMENTS – POINTING MAPS

3.12.1 Requirement “The TCS shall provide a tool for creating pointing maps. This tool shall include features for target

acquisition, data collection, pointing map calculation, pointing map storage and retrieval. The pointing

map shall contain error information for altitude, azimuth and rotator.

The TCS shall perform pointing map operations on demand on night time point sources.

The TCS shall utilize a pointing map that covers the sky area the ATST telescope can see, per SPEC-

0011, Requirement 1.1-0140. This pointing map shall contain errors for the altitude, azimuth and coudé

rotator. The map shall have a sufficient sample interval to provide the required open-loop pointing

accuracy and precision.”

3.12.2 Setup

3.12.3 Tests

Test AT4.4-0135-01


Preconditions 1) The TCS is in the “tracking” mode.

Test Steps 1) From the TCS Engineering main screen click on the “Pointing Tests” button

(located at bottom left hand side of the screen).

Pass Criteria 1) The Pointing Tests screen opens.

2) The screen contains a display of available target sources (note it may take a

short while for the sources to be registered by the display) shown as white boxes

on the blue background.

3) The current mount position is displayed as a black circle. The numerical value

is displayed at the bottom of the screen.

4) The screen contains a widget that displays source information. Clicking on one

of the sources populates the table with data.

5) The screen contains a widget that allows a new pointing test to be started and a

data point to be logged to the current test.

6) The screen displays the current pointing test data filename and the number of

data items logged in the current pointing test.

Script N/A



Notes

Test AT4.4-0135-02


Preconditions 1) The previous test has been completed.

2) The Pointing Tests screen is open.

Test Steps 1) In the “Pointing Test” widget click on the “New” button.

2) Make a note of the filename in the current pointing test filename widget.

3) Click on one of the sources.

4) Click on the submit button.

5) Wait for the mount to move over the source and the for configuration to

complete.

6) In the “Pointing Test” widget click on the “Log” button.

7) Repeat steps 3 to 6 at least 10 times for a range of different targets.

8) Run TPOINT to analyze the data

Pass Criteria 1) When the “New” button is clicked the pointing test filename updates with a new

file.

2) When a source is selected it turns orange and the data is populated in the target

table.

3) When a source is submitted it turns red. The mount slews towards the source.

Once the source has been reached the mount stops slewing and tracks.

4) When the “Log” button is clicked the number of positions logged increases by

one. A row of information is appended to the end of the file. The file can be

opened and read by any ASCII editor.

5) Confirm that the fitted values of the pointing coefficients generated by TPOINT

match the values in the TCS property file



Script N/A

Notes

3.13 POINTING REQUIREMENTS – OPEN-LOOP POINTING OFFSET

3.13.1 Requirement “The TCS shall provide an interface to allow an external system to apply an offset to the telescope

pointing. The input offset shall be used by the TCS as an additional open-loop corrective error.

The ATST telescope may have additional recurring errors from sources not capable of being sampled

during the pointing maps. Such errors may be from thermal gradients placed on the various telescope

mechanical structures and thermal offsets between nighttime pointing maps and daytime operations.”

3.13.2 Setup

3.13.3 Tests

Test AT4.4-0137-01



Test Steps 1) Submit a target to the atst.tcs controller with a frame of “AZEL”, an azimuth

value of 10.0 and an elevation value of 20.0.

2) Record the current target azimuth and elevation and the current mount azimuth

and altitude values.

3) Submit a collimation correction of 1.0 arcseconds in azimuth as a handset value

five times.



5) Clear the applied collimation corrections.

6) Submit a collimation correction of -1.0 arcseconds in azimuth as a handset value

five times.






9) Submit a collimation correction of 1.0 arcseconds in elevation as a handset

value five times.




12) Submit a collimation correction of -1.0 arcseconds in elevation as a handset

value five times.




Pass Criteria 1) Compare the values recorded in step 4 with those recorded in step 2. The target

azimuth and elevation values should be unchanged. The current mount altitude

value should be unchanged. The current mount azimuth value should be 5.3

arcseconds greater in step 4 than it was in step 2 (5.3 arcseconds = 5.0 arcsecond

offset / cosine(20.0°) ).

2) Verify the collimation correction (ca) has a handset value of 5.0 arcseconds and

a total value of 5.0 arcseconds. This can be checked using the collimation table

present on the TCS Engineering main screen, “Data” tab.

3) Compare the values recorded in step 7 with those recorded in step 2. The target

azimuth and elevation values should be unchanged. The current mount altitude

value should be unchanged. The current mount azimuth value should be 5.3

arcseconds less in step 7 than it was in step 2 (5.3 arcseconds = 5.0 arcsecond

offset / cosine(20.0°) ).

4) Verify the collimation correction (ca) has a handset value of -5.0 arcseconds and

a total value of -5.0 arcseconds. This can be checked using the collimation table


5) Compare the values recorded in step 10 with those recorded in step 2. The

target azimuth and elevation values should be unchanged. The current mount

azimuth value should be unchanged. The current mount altitude value should be

5.0 arcseconds greater in step 10 than it was in step 2.

6) Verify the collimation correction (ce) has a handset value of 5.0 arcseconds and

a total value of 5.0 arcseconds. This can be checked using the collimation table




7) Compare the values recorded in step 13 with those recorded in step 2. The

target azimuth and elevation values should be unchanged. The current mount

azimuth value should be unchanged. The current mount altitude value should be

5.0 arcseconds less in step 13 than it was in step 2.

8) Verify the collimation correction (ce) has a handset value of -5.0 arcseconds and

a total value of -5.0 arcseconds. This can be checked using the collimation table



Notes

3.14 POINTING REQUIREMENTS – POINTING CORRECTION MECHANISM

3.14.1 Requirement “The TCS shall provide a mechanism to correct the open-loop pointing error of the telescope. This

mechanism shall be capable of running under command from the operator or OCS at any time.

The preferred mechanism for correcting pointing errors is to position the telescope at three or more

locations on the solar limb, manually adjust the position at each position, and then calculate the positional

error based upon these inputs.”

3.14.2 Setup

3.14.3 Tests

Test AT4.4-0140-01



2) Ensure the TCS.SIMS container is in the “running” state and ensure the MCS

and ECS simulators are in the “running” state.

3) Ensure the TCS3 container is in the “running” state and the atst.tcs.tpk.tpoint

controller is in the “running” state.

Test Steps 1) Open the pointing tests JES screen by clicking on the “Pointing Tests” button on

the TCS main engineering screen.

2) Place the TCS into the “tracking” state.



3) On the pointing tests screen click on the “New” button and record the current

pointing test filename.

4) Position the telescope at a location on the solar limb by selecting the appropriate

solar target. Wait for the telescope to reach the steady state tracking position.

5) Open the adjustments screen by clicking on the “Adjustments” button on the

pointing tests JES screen and perform any necessary corrections to align the

telescope correctly.

6) Once aligned, click on the “Log” button to log the point to the file.

7) Repeat steps 4, 5 and 6 for the desired number of points (possibly four, one for

each limb).

8) Click on the session fit tab on the pointing tests screen and select the file from

the drop down box.

9) Click on the “Session Fit” button to begin a session fit.

10) Once the fit has completed and the fitted data values appeared click on the

“Use” button to replace the current model values with the fitted values.

11) Click on the “Revert” button to return to the original model values.

Pass Criteria 1) The TCS records positions in a data file that can be used to carry out a session

fit.

2) The TCS can perform a session fit whilst running without the need to execute

any external applications.

3) The session data is displayed in the session data table. Individual values can be

de-selected from the data set and the fit carried out again.

4) The fitted data is displayed for the operator to check before accepting the

session data values.

5) The current model values can be replaced by the fitted data values without

shutting down the TCS application.

6) The original model values can be restored over the top of the fitted data values

without shutting down the TCS application.




Notes

3.15 POINTING REQUIREMENTS – SCANNING

3.15.1 Requirement “The TCS shall perform scanning motions under command from the OCS. Scanning motions shall be

motions about any or all of the telescope axes (altitude, azimuth and coudé rotator); they shall either be

stepped or continuous motions, and shall be in any of the supported TCS coordinate systems. The TCS

shall support box, spiral, boustrophedon, and random scan patterns. The TCS shall support optional

attributes for step size, velocity, starting location, number of steps and rows, and maximum range of

travel.

The TCS shall support random scan patterns by moving continuously and randomly within a defined area

of the solar disk. The random scan pattern shall blur the final image enough to support the need for a flat

field of view for the wavefront correction system. The random scan pattern shall run at configurable rates

up to 30 arc-seconds per second and at configurable areas up to 200 arc –seconds.”

3.15.2 Setup These tests need to track the center of the solar disk. They will fail if the Sun is below the lower elevation

limit of the telescope at the time the test is executed.

3.15.3 Tests

Test AT4.4-0145-01


Preconditions 1) Ensure the TCS is tracking a cartesian helioprojective target.

Test Steps 1) Submit a configuration to the atst.tcs controller with an attribute scanType set to

“spiral”.

2) After a period of time submit a configuration to the controller with an attribute

scanType set to “none”.

Pass Criteria 1) The mount starts to move in a spiral (in a cartesian helioprojective frame)

relative to the starting cartesian helioprojective point.

2) The scan mode is set to “spiral”.

3) On the “Scanning” tab graph two sets of points are plotted. The red set of points

are the demand points and are in the shape of a spiral. The green points trace

out the red points as the mount follows the spiral.



4) Once the scan mode is set to “none” the TCS returns to tracking the previous

target.


Notes

Test AT4.4-0145-02




“random”.


scanType set to “none”

Pass Criteria 1) The mount starts to move in a random manner.

2) Although the mount movement is random it is constrained to within the random

box defined (defaults to 200).

3) The scan mode is set to “random”.


are the demand points. The green points trace out the red points as the mount

follows the random motion path.


target.


Notes



Test AT4.4-0145-03




“raster” and an attribute scanParams set to “HP”, ”0”, ”0”, ”10”, ”5”, ”VT”, ”2”,

”30”, ”0”, ”true”, ”nearest”.



Pass Criteria 1) The mount starts to move in a raster as defined by the parameters in step 1. A

full definition of the parameters can be found in the operations manual for the

TCS.

2) The scan mode is set to “raster”.


are the demand points. The green points trace out the red points as the mount

follows the motion path.


target.


Notes

Test AT4.4-0145-04




“random”


scanType set to “spiral”




scanType set to “raster”



Pass Criteria 1) The mount starts to move in a random pattern.

2) The mount starts to move in a spiral pattern

3) The mount starts to move in a raster pattern


target.


Notes The test verifies that it is possible to switch directly between any of the scanning modes

without interruption

3.16 POINTING REQUIREMENTS – POINTING MODES

3.16.1 Requirement “The TCS shall control the telescope pointing through one of the following ‘modes’. The TCS shall use

these modes to control and coordinate the pointing loops in the TCS and the telescope subsystems,

sending the resulting position demands to the mount and enclosure control systems.

In open-loop mode, the TCS shall perform blind pointing and tracking for a demanded position based

solely upon the generated ephemeris and any known recurrent error (i.e., position offset in each axis,

bearing runout, current temperature, etc.). In closed-loop mode, the TCS shall receive guide information

and use this information, along with any recurrent error, to generate pointing demands for the mount and

enclosure.

Pointing errors from the Acquisition Control System indicate the discrepancy between the pointing map

value and the actual value of the position error. An object tracked by the ACS has an absolute position

that is used as the reference position for the telescope coordinate system. A pointing error indicates that

the TCS pointing map has a discrepancy between the calculated recurrent error and the actual observed

error.

Pointing errors from the Wavefront Correction Control System indicate the amount of drift or bias the

WCCS has accumulated in correcting for image motion. An object tracked by the WCCS may not have a

fixed position in the telescope coordinate system. Consequently, a pointing error indicates that the TCS

absolute position may have drifted and should be updated.

Raw: Position is calculated using ephemeris only. No pointing map is used.



Open-loop: Position is calculated using ephemeris and recurrent error information. No guide

signal is used.

o Offset: An offset can be applied to correct for systematic errors detected and applied by

an external system.

Closed-loop: Position is calculated using ephemeris, pointing map, recurrent error information,

and guide signal(s). The following guide sources may be used (in any combination);

o Guider: Guide signal comes from an external source that generates errors based upon the

absolute position of the source. The format of the guide signal is defined by the interface

between the TCS and the Acquisition Control System.

o Adaptive Optics: Positional error signal comes from the WCCS. The format of the guide

signal is defined by the interface between the TCS and the Wavefront Correction Control

System.

Closed-loop guiding from the guider gives an absolute position reference signal in that the error delivered

to the TCS comes from a source with a known position in the sky (e.g., a star or the limb of the sun).

This source may originate from either the Acquisition Control System (i.e., a solar limb finder algorithm)

or from a stellar source detected by the context viewer. The TCS shall use this type of guide signal to

adjust the relative offset of the pointing model.

These modes shall be selectable by the observer or operator.”

3.16.2 Setup

3.16.3 Tests

Test AT4.4-0150-01


Preconditions None

Test Steps 1) Stop the TCS application (if it is running).

2) Set the selected pointing model property to “raw”.

3) Restart the TCS application and verify the standard pointing terms are all zero.

4) Stop the TCS application.

5) Set the selected pointing model property to “test”.

6) Add a new property “model:test:names” set to “IA,IE,CA”.

7) Add a new property “model:test:values” set to “1.0,2.5,4.25”.

8) Restart the TCS application and verify the standard pointing terms are set to the

values set in the “model:test:values” property.

9) Stop the TCS application.



10) Set the selected pointing model property to “std”.

11) Restart the TCS application.

Pass Criteria 1) After each restart the TCS uses the pointing model specified by the selected

model property.

2) The values of the individual pointing terms are the same as those defined in the

properties for the relevant pointing model.

3) No errors occur when the TCS is shutdown, the pointing model changed and

then the TCS restarted.


Notes

3.17 POINTING REQUIREMENTS – SKY COVERAGE

3.17.1 Requirement “The TCS shall be able to point to all areas of the sky accessible by the Telescope Mount Assembly, per

SPEC-0011, Requirement 1.1-0140. The pointing accuracy shall be consistent with the current operating

mode in all areas except the zenith blind spot and the lower elevation angles used only for maintenance.”

3.17.2 Setup

3.17.3 Tests

Test AT4.4-0155-01


Preconditions 1) The TCS application is running.

2) The horizonChecking attribute has been set to “off” in the TCS.

3) The mode of the TCS has been set to “off”.

Test Steps 1) Using a grid of points in RA and Dec, issue FK5 targets covering the whole sky.

2) Verify the targets are all accepted and the TCS updates the target position.

Pass Criteria 1) As the TCS horizon checking has been turned off, all targets should be accepted

within the range RA 0.0 to 24.0 and Dec -90.0 to +90.0. There should be no



rejections.

2) After each target verify the TCS target position has updated to the latest demand

irrespective of where on the sky that target is.


Notes

3.18 POINTING REQUIREMENTS – FORBIDDEN ZONE WHEN MIRROR COVER AND ENCLOSURE ARE

OPEN

3.18.1 Requirement “Notwithstanding the requirements of 4.4-0155, the TCS shall not point the telescope and enclosure

within an area between 24 arcmins and 25 degrees from the sun center whilst the sun is above the horizon

and the enclosure and M1 cover are open. When the sun is below the horizon or if either the enclosure or

M1 mirror cover is closed the TCS shall be able to point the telescope within this area. Commands issued

to the TCS that would point the telescope within this area, or that would cause the telescope to cross

through this area, shall be rejected. Trajectories that would cross this area shall be modified to not enter

the area and the TCS shall issue an alarm showing that the tracking performance is not valid. Commands

to the TCS that would open both the M12 mirror cover and the enclosure cover while the telescope is

within this area shall be rejected.”

3.18.2 Tests

Test AT4.4-0157-01





Test Steps 1) Check the mirror and enclosure covers and if they are not closed then close

them

2) Check the sun is above the lower elevation limit and if so slew to the solar

center and then open both the mirror and enclosure covers

3) Issue a command to send the telescope to helioprojective x = 1.55 R, y = 0.0

4) Read the current RA and Declination and then issue a command to slew to an

FK5 position different by 1 degree in declination

5) Read the current RA and Declination and then issue a command to slew the

telescope to an FK5 position 26 degrees away

6) Issue a command to point the telescope at HP x = 0, y= 0. The issue an offset to



HP x = 1.45 R, y = 0

7) Issue a command to point the telescope at HP x = 0, y= 0. The issue an offset to

HP x = 1.55 R, y = 0

8) Close the mirror cover. Issue a command to point the telescope at HP x = 2.0R,

y= 0.

9) Issue a command to open the mirror cover

10) Issue a command to close the enclosure cover. Issue a command to open the

mirror cover

11) Issue a command to open the enclosure cover

12) Slew to a target outside the forbidden zone. Open the mirror and enclosure

covers

13) Select a target outside but on the other side of the forbidden zone

14) Select targets outside the forbidden zone but on the same side as the current

target

Pass Criteria 1) .Confirm that both mirror and enclosure covers are closed.

2) Confirm that the telescope slews to point to the solar center and that both mirror

covers can be opened

3) Confirm that the command to point the telescope to the helioprojective position

inside the forbidden zone is rejected with a message that the sun is above the

horizon and the mirror and enclosure cover are open.

4) Confirm that the command to point the telescope to the FK5 position inside the

forbidden zone is rejected with a message that the sun is above the horizon and

the mirror and enclosure cover are open.

5) Confirm that the command to point the telescope to the FK5 position outside the

forbidden zone but requiring a slew through the forbidden zone to get there is

rejected with a message that the sun is above the horizon and the mirror and

enclosure covers are open.

6) Confirm that the offset from a point within the inner allowed zone to another

point within the inner allowed zone is accepted..

7) Confirm that the offset that would take the pointing target from a position within

the inner allowed zone to a position inside the forbidden zone is rejected.

8) Confirm that with the mirror cover closed it is now possible to point to a target



within the forbidden zone.

9) Confirm that attempting to open the mirror cover with the sun above the horizon

and the enclosure open is rejected.

10) Confirm that once the enclosure cover is closed the mirror cover can be opened

whilst pointing in the forbidden zone.

11) Confirm that attempting to open the enclosure cover with the sun above the

horizon and the mirror cover open is rejected.

12) Confirm that the telescope slews outside the forbidden zone and once there both

mirror and enclosure cover can be opened.

13) Confirm that attempts to slew from a position outside the forbidden zone to

another point outside the forbidden zone but that would require passing through

the forbidden zone to get from one position to the other is rejected.

14) Confirm that slewing from one position outside the forbidden zone to another

point outside the forbidden zone is accepted provided the slew does not take it

through the forbidden zone


Notes

3.19 POINTING REQUIREMENTS – ZENITH BLIND SPOT

3.19.1 Requirement “The zenith blind spot is defined as the area on the sky at zenith where the telescope mount assembly

cannot meet the velocity and acceleration performance specifications defined in SPEC-0011,

Requirements 1.1-0150 and 1.1-0160.

The TCS shall be able to track through the zenith blind spot. Some degradation of pointing performance

is allowed, but the performance shall be restored upon exiting the blind spot.

The TCS shall report regularly the distance and time until the zenith blind spot is reached. The TCS shall

generate a CSF alarm while the telescope is in the zenith blind spot.”

3.19.2 Setup

3.19.3 Tests

Test AT4.4-0160-01







Test Steps 1) Record the values of atst.tcs.tpk.pk.tlatm and atst.tcs.tpk.pk.last. These can be

read from the atst.tcs.tpk.pk controller by performing a get on that controller.

2) Add 0.35 degrees to the value recorded for tlatm. This will become the target

declination demand.

3) Convert the value of last (which is in radians) to hours and add 7 minutes to the

value. This will become the target right ascension demand.

4) Place the TCS into “tracking” mode.

5) Submit an FK5 target with RA and Dec values calculated from steps 1 – 3. This

will place the telescope tracking a position just prior to entering the zenith blind

spot.

6) Open the ATST alarm handling system to monitor alarms generated, or

subscribe to the "__alarm" event channel.

7) Allow the TCS to track through the zenith blind spot.

Pass Criteria 1) When the target is first set it should place the TCS approximately 5 or 6 minutes

away from the zenith blind spot. The limits table at the bottom left hand side of

the TCS main engineering JES screen reflects this with the message:

“Time to zenith blind spot: 6 minutes”.

2) As the TCS tracks towards the zenith blind spot the time to zenith blind spot

reduces until it reaches “< 1 minute”.

3) As the TCS enters the zenith blind spot the times to limit message changes to:

“Time to target exiting zenith blind spot: 2 minutes”.

4) As the TCS enters the zenith blind spot the limit message “Target inside zenith

blind spot” is displayed.

5) As the TCS enters the zenith blind spot an alarm is raised by the atst.tcs.tpk.pk

controller. The alarm reads “Target inside zenith blind spot”.

6) Whilst the TCS is tracking through the zenith blind spot the MCS and ECS

might not be able to track within performance specifications. If this happens

then the mount and enclosure azimuth position boxes will turn yellow on the

TCS main engineering JES screen.



7) As the TCS exits the zenith blind spot the limit message is cleared. The time to

limits message changes to show the time to minimum elevation limit (as that is

the next limit that is encountered).


Notes

3.20 POINTING REQUIREMENTS – TRACKING

3.20.1 Requirement “The TCS shall track a position in one of the following coordinate systems:

Topocentric: The TCS shall accept an altitude/azimuth target position and remain at that position.

Sidereal: The TCS shall be capable of tracking a sidereal object (i.e., a star), given the sidereal

position and epoch.

Planetary: The TCS shall be capable of tracking a planetary object given the ecliptic position or

name of the major planetary body.

Heliocentric: The TCS shall be capable of tracking at a heliocentric rate.

Heliographic: The TCS shall be capable of tracking at a heliographic rate. The heliographic

pointing accuracy shall be consistent with the solar rotation model.

All input positions shall be in the coordinate frame of the selected coordinate system. The tracking

system shall be user selectable. An option to disable tracking shall also be provided.

The TCS shall provide simultaneous status information on the current telescope, enclosure, and coudé

rotator positions in the topocentric, sidereal, and currently selected coordinate systems.”

3.20.2 Setup

3.20.3 Tests

Test AT4.4-0165-01






2) Submit a configuration with an AZEL target (frame set to AZEL).

Pass Criteria 1) The COSYS value of the TCS (displayed on the TCS main engineering JES

screen) is “AZEL”.



2) The TCS slews to the target Az El position.

3) Once the TCS has reached the target position the current mount and enclosure

positions are constant (within time and position tolerance).

4) Note the actual azimuth and altitude demands to the mount and enclosure may

differ slightly from the chosen target, due to imperfections in the structure

which are eliminated by the pointing model.


Notes

Test AT4.4-0165-02






2) Open the target control screen by clicking on the “Target Control” button on the


3) In the “Set Up Target” widget set the coordinate system to FK4 and enter a valid

target RA and Dec value.


screen) is “FK4”.

2) The TCS slews to the target RA Dec position.


positions continue to track the demand positions and the text boxes turn green

representing an in-position (within time and position tolerance) status.


Notes



Test AT4.4-0165-03








3) In the “Set Up Target” widget set the coordinate system to FK5 and enter a valid

target RA and Dec value.








Notes

Test AT4.4-0165-04










3) In the “Set Up Target” widget set the coordinate system to ICRS and enter a

valid target RA and Dec value.








Notes

Test AT4.4-0165-05








3) In the “Set Up Target” widget set the coordinate system to APPT and enter a



screen) is “APPT”.








Notes

Test AT4.4-0165-06








3) In the “Set Up Target” widget set the coordinate system to GAPPT and enter a



screen) is “GAPPT”.






Notes

Test AT4.4-0165-07








2) In the “Control” tab on the TCS main engineering JES screen, select the

“Cartesian Heliocentric” option from the drop down menu in the “Solar Target”

widget.

3) Enter a valid x, y, z value for the solar target and submit the configuration.


screen) is “HC”.

2) The target position on the TCS main engineering JES screen updates to show

three coordinates (X, Y, Z).

3) In the “Data” tab of the TCS main engineering JES screen the Solar Frame is

“HC” and the Solar Library Mode is “active”.

4) The TCS slews to the target X, Y, Z position.





Notes

Test AT4.4-0165-08






2) In the “Control” tab on the TCS main engineering JES screen, select the “Polar

Heliographic” option from the drop down menu in the “Solar Target” widget.



3) Enter a valid polar heliographic value for the solar target and submit the

configuration.


screen) is “HG”.


the coordinates Theta and Phi.


“HG” and the Solar Library Mode is “active”.

4) The TCS slews to the target Theta, Phi position.





Notes

Test AT4.4-0165-09






2) In the “Control” tab on the TCS main engineering JES screen, select the

“Cartesian Helioprojective” option from the drop down menu in the “Solar

Target” widget.

3) Enter a valid cartesian helioprojective value for the solar target and submit the

configuration.


screen) is “HP”.




the coordinates X and Y (arcseconds).


“HP” and the Solar Library Mode is “active”.

4) The TCS slews to the target X, Y position.





Notes

Test AT4.4-0165-10



2) Ensure the TCS.SIMS container is in the “running” state and ensure the MCS,

ECS and WCCS simulators are in the “running” state.


2) In the “Control” tab on the TCS main engineering JES screen, select the “Radial

Helioprojective” option from the drop down menu in the “Solar Target” widget.

3) Enter a valid radial helioprojective value for the solar target and submit the

configuration.


screen) is “HPR”.


the coordinates Rho and Psi.


“HPR” and the Solar Library Mode is “active”.

4) The TCS slews to the target Rho, Psi position.







Notes

Test AT4.4-0165-11





Test Steps 1) Place the TCS into tracking mode with a helioprojective target of 0.0, 0.0

2) Subscribe to the event atst.tcs.tpk.pk.data and log data for 5 minutes on the

demanded azimuth, elevation and rotator

3) Plot the data after subtracting a best fit polynomial

Pass Criteria 1) The TCS enters tracking mode with a helioprojective target of 0.0, 0.0

2) The attributes demands:tai, demands:azimuth, demands:elevation and

demands:rotator are logged to a file

3) The plots of demanded positions are smooth with no large glitches


Notes Currently the inspection of the plots is a visual process

Test AT4.4-0165-12







Test Steps 1) Place the TCS into tracking mode and track an FK5 target with an RA 1 hour

greater than the current LAST and a declination of 30 degrees




Pass Criteria 1) The TCS enters tracking mode with an FK5 target set to the demanded RA and

Dec.

2) The attributes demands:tai, demands:azimuth, demands:elevation and

demands:rotator are logged to a file

3) The plots of demanded positions are smooth with no large glitches



Test AT4.4-0165-13





Test Steps 4) Place the TCS into tracking mode with a helioprojective target of 0.0, 0.0




Pass Criteria 1) The TCS enters tracking mode with a helioprojective target of 0.0, 0.0

2) The attributes target:tai_MJD, target:azimuth_DEG, target:elevation_DEG and

target:rotator_DEG are logged to a file



3) The plots of target positions are smooth with no large glitches



Test AT4.4-0165-14





Test Steps 1) Place the TCS into tracking mode with a FK5 target with an RA 1 hour greater

than the current LAST and a declination of 30 degrees




Pass Criteria 1) The TCS enters tracking mode with an FK5 target set to the demanded RA and

Dec.

2) The attributes target:tai_MJD, target:azimuth_DEG, target:elevation_DEG and

target:rotator_DEG are logged to a file

3) The plots of target positions are smooth with no large glitches



Test AT4.4-0165-16







Test Steps 1) Place the TCS into tracking mode and set a heliocentric Thompson target of 0.0,

0.0, 1.0

2) Set a heliocentric Thompson target of 0.0, 0.6, 0.8



5) Set a heliocentric Thompson target of 0.1, 0.2, -1.3


screen) is “HCT”.




“HCT” and the Solar Library Mode is “active”.






Notes

Test AT4.4-0165-17





Test Steps 1) Place the TCS into tracking mode and set a heliographic target with l = L0, B=

B0 and R = 1.2




screen) is “HG”.










Notes

3.21 POINTING REQUIREMENTS – OCCULTER

3.21.1 Requirement “The TCS shall provide to the PA&C tracking information to be used to position occulters at the

Gregorian and prime foci. The tracking information shall be sufficient to allow the PA&C to determine

the position of occulters in translation and rotation in order to block the solar limb.”

3.21.2 Setup

3.21.3 Tests

Test AT4.4-0170-01



2) Ensure horizon checking has been turned off.

Test Steps 1) Listen to the event “atst.tcs.pac.gosTrajectory” and verify it is posted by the

TCS at a rate of 20 Hz.

2) Look at the structure of the event and verify that it contains the values “.tRef”,

“occulterCoeff”, “hprRadius”, “hprAngle”, “timestamp” and “trackId”.

3) Set target positions on the solar limb and verify that at these target positions the

“hprRadius” is set to 0.0 and the “hprAngle” is offset from the coude HP angle

by 90.0.



Pass Criteria 1) The “atst.tcs.pac.gosTrajectory” event is posted at a rate of 20 Hz.

2) The event contains attributes as defined by the TCS to OCS ICD.

3) The “hprRadius” value is in arcseconds from the solar limb and the “hprAngle”

is degrees of the tangent to the limb at the current target position.


Notes

3.22 POINTING REQUIREMENTS – DRIFT

3.22.1 Requirement “The TCS shall accept optional drift rates in the current coordinate system and apply those rates to the

current position of the telescope, enclosure, and coudé rotator. Drift rates shall not exceed the maximum

tracking velocity for any telescope axis.

Drift rates are defined as an added velocity in the tracking coordinate system that allows the telescope to

follow an object that is not stationary in the tracking coordinate system.”

3.22.2 Setup

3.22.3 Tests

Test AT4.4-0175-01






2) Submit a target to the TCS. It is easier to monitor the target change if the target

submitted consists of integer parameters.

3) Wait for the TCS to slew to the target and enter the tracking steady state.

4) Submit a differential track rate of 1 second per second of drift in RA. Submit a

value of 0 arcseconds per second for drift in Dec. Leave the Reference Epoch

blank (which defaults to an epoch of the current time).

5) Monitor the target and current positions for 30 seconds.



6) After verifying the drift rates clear them back to 0 and verify the target returns

to its original position.

7) Repeat steps 4, 5 and 6 for drifts of -1 second per second in RA, +1 arcseconds

per second in Dec and -1 arcseconds per second in Dec.

Pass Criteria 1) Once the drift rates have been submitted the Target RA or Dec value starts to

increase or decrease at a value consistent with that demanded (1 second per

second for RA or 1 arcsecond per second for Dec).

2) The current position stays aligned with the changing target position,

demonstrating that the TCS is still tracking within specification.

3) The mount and enclosure position boxes stay green while the drift rates are

applied, demonstrating that the axes do not drop out of position.

4) When the drift rates are set back to zero the telescope slews back to the original

position.


Notes

3.23 POINTING REQUIREMENTS – TARGET

3.23.1 Requirement “The TCS shall accept a target position in any of the tracking coordinate (requirement 4.4-0165 herein)

systems. The TCS shall point the telescope to the target position and track it in the requested coordinate

system.

The TCS shall have defined fixed positions for various engineering positions, including the parked

position and the service positions of the telescope, as defined in the TCS to TMA interface (ICD 1.1/4.4).

These fixed positions shall be reconfigurable.”

3.23.2 Setup

3.23.3 Tests

Test AT4.4-0180-01








2) Submit an AZEL target.

Pass Criteria 1) The coordinate system value of the TCS is “AZEL”.

2) The TCS slews to the target Az El position.


positions are constant and in-position (within time and position tolerance).

4) Note the actual azimuth and altitude demands to the mount and enclosure may

differ slightly from the chosen target, due to imperfections in the structure

which are eliminated by the pointing model.


Notes

Test AT4.4-0180-02






2) Submit a valid FK4 target with RA and Dec value.

Pass Criteria 1) The coordinate system value of the TCS is “FK4”.

2) The TCS slews to the target RA, Dec position.


positions continue to track the demand positions and are in-position (within time

and position tolerance).




Notes

Test AT4.4-0180-03






2) Submit a valid FK5 target with RA and Dec value.

Pass Criteria 1) The coordinate system of the TCS is “FK5”.






Notes

Test AT4.4-0180-04






2) Submit a valid ICRS target with RA and Dec value.



Pass Criteria 1) The coordinate system value of the TCS is “FK5”.






Notes

Test AT4.4-0180-05






2) Submit a valid APPT target with RA and Dec value.

Pass Criteria 1) The coordinate system value of the TCS is “APPT”.






Notes

Test AT4.4-0180-06








2) Submit a valid GAPPT target with RA and Dec value.

Pass Criteria 1) The coordinate system value of the TCS is “GAPPT”.






Notes

Test AT4.4-0180-07






2) Submit a valid HC target with x, y, z values for the solar target.

Pass Criteria 1) The coordinate system value of the TCS is “HC”.




“HC” and the Solar Library Mode is “active”.








Notes

Test AT4.4-0180-08






2) Submit a valid polar heliographic solar target.

Pass Criteria 1) The coordinate system value of the TCS is “HG”.


the coordinates Theta and Phi.


“HG” and the Solar Library Mode is “active”.

4) The TCS slews to the target Theta, Phi position.





Notes

Test AT4.4-0180-09








2) Submit a valid cartesian helioprojective solar target.

Pass Criteria 1) The coordinate system value of the TCS is “HP”.


the coordinates X and Y (arcseconds).


“HP” and the Solar Library Mode is “active”.

4) The TCS slews to the target X, Y position.





Notes

Test AT4.4-0180-10






2) Submit a valid radial helioprojective solar target.

Pass Criteria 1) The coordinate system value of the TCS is “HPR”.




the coordinates Rho and Psi.


“HPR” and the Solar Library Mode is “active”.

4) The TCS slews to the target Rho, Psi position.





Notes

Test AT4.4-0180-11






2) Submit a configuration to the TCS with the attribute atst.tcs.namedPos =

“stow”.

Pass Criteria 1) The TCS drops out of tracking mode and the MCS and ECS simulators are

driven to their stow positions.

2) The stow positions for the MCS and ECS simulators are defined in properties

available for those controllers. Changing the property value and re-running the

test will result in the MCS and ECS driving to the new values.


Notes



Test AT4.4-0180-12






2) Submit a configuration to the TCS with the attribute atst.tcs.namedPos =

“index”.

Pass Criteria 1) The TCS drops out of tracking mode and the MCS simulator is driven to its

index position. This may involve re-aligning the axes to their reference marks.


Notes

Test AT4.4-0180-13






2) Submit a HCT target with x = 0,0, y = 0.0 and z = 1.0

3) Submit an HCT target with x = 0.0, y =0.0 and z = -1.0

Pass Criteria 1) The coordinate system value of the TCS is “HCT”.












Notes

3.24 POINTING REQUIREMENTS – OFFSETS

3.24.1 Requirement “The TCS shall accept and display offsets from a nominal input target position in any of the above

coordinate systems. The TCS shall provide offset capability for the TMA altitude, azimuth, and coudé

rotator.

The TCS shall not allow individual offset requests that exceed 1 degree.”

3.24.2 Setup For the offsets that involve an HP target it is necessary to ensure the Sun is above the horizon. The tests

will fail if this criterion is not met.

3.24.3 Tests

Test AT4.4-0185-01






2) In the “Control” tab on the TCS main engineering JES screen, click on the

“Target Control” button to open the Target Control JES screen.

3) In the “Set Up Target” widget on the Target Control JES screen enter a valid

target and submit the configuration. It will be easier to verify the offsets if the

target parameters chosen are integer values.



“Offsets” button to open the Offsets JES screen.



6) In the “Target Offsets” tab select an offset type of simple and a size of “1.0”

seconds.

7) Click on the right or left arrows to apply offsets in the RA frame.

8) Monitor the target, current positions and the offsets table (“Data” tab) on the


9) After verifying the offsets in RA set them back to 0 by clicking on the “X”

button on the Offsets JES screen.

Pass Criteria 1) If the right arrow is clicked then the RA offset is increased by 1 second (15

arcseconds). This can be verified by looking at the target and current position

and the offsets table. The target RA will increase by 1 second. The handset

entry in the offsets table increases by 15 arcseconds.

2) The MCS and ECS may briefly drop out of position but then move back into

position.

3) If the left arrow is clicked then the RA offset is decreased by 1 second (15

arcseconds). This can be verified by looking at the target and current position

and the offsets table. The target RA will decrease by 1 second. The handset

entry in the offsets table decreases by 15 arcseconds.


position.

5) When the “X” button is clicked the target RA returns to its original value. The

handset entry in the offsets table is reset to 0.


Notes

Test AT4.4-0185-02
















6) In the “Target Offsets” tab select an offset type of simple and a size of “1.0”

arcseconds.

7) Click on the up or down arrows to apply offsets in the Dec frame.



9) After verifying the offsets in Dec set them back to 0 by clicking on the “X”


Pass Criteria 1) If the up arrow is clicked then the Dec offset is increased by 1 arcseconds. This

can be verified by looking at the target and current position and the offsets table.

The target Dec will increase by 1 arcsecond. The handset entry in the offsets

table increases by 1 arcseconds.


position.

3) If the down arrow is clicked then the Dec offset is decreased by 1 arcsecond.

This can be verified by looking at the target and current position and the offsets

table. The target Dec will decrease by 1 arcsecond. The handset entry in the

offsets table decreases by 1 arcsecond.


position.

5) When the “X” button is clicked the target Dec returns to its original value. The





Notes

Test AT4.4-0185-03








3) In the “Set Up Target” widget on the Target Control JES screen enter a valid HP






6) In the “Target Offsets” tab select an offset type of solar.

7) Enter offset values into the manual offset text boxes and submit the offsets by

clicking on the tick button.



9) After verifying the offsets set them back to 0 by clicking on the “X” button on

the Offsets JES screen in the “Manual” area.

Pass Criteria 1) The HPX offset is altered by the amount set in the text box. This can be verified

by looking at the target and current position and the offsets table. The target

HPX will increase by the same amount. The manual entry in the offsets table

increases by the same amount also.


position.



3) The HPY offset is altered by the amount set in the HPY text box. This can be

verified by looking at the target and current position and the offsets table. The

target HPY will increase by the same amount. The manual entry in the offsets

table increases by the same amount also.


position.

5) When the “X” button is clicked the target HPX and HPY return to their original

values. The handset entry for HPX and HPY in the offsets table is reset to 0.


Notes

Test AT4.4-0185-04














6) In the “Target Offsets” tab select an offset type of tplane and a size of “1.0”

arcseconds.

7) Click on the right or left arrows to apply offsets in the RA frame.





9) After verifying the offsets in RA set them back to 0 by clicking on the “X”


Pass Criteria 1) If the right arrow is clicked then the RA offset is increased by 1 tangent plane

arcsecond (divided by cosine of the Dec). This can be verified by looking at the

target and current position and the offsets table. The target RA will increase by

the offset divided by 15 seconds. The handset entry in the offsets table

increases by 1 tangent plane arcsecond (divided by cosine of the Dec).


position.

3) If the left arrow is clicked then the RA offset is decreased by 1 tangent plane

arcsecond (divided by cosine of the Dec). This can be verified by looking at the

target and current position and the offsets table. The target RA will decrease by

the offset divided by 15 seconds. The handset entry in the offsets table

decreases by 1 tangent plane arcsecond (divided by cosine of the Dec).


position.

5) When the “X” button is clicked the target RA and Dec return to their original

values. The handset entry for RA and Dec in the offsets table is reset to 0.


Notes

Test AT4.4-0185-05
















6) In the “Target Offsets” tab select an offset type of tplane and a size of “1.0”

arcseconds.

7) Click on the up or down arrows to apply offsets in the Dec frame.



9) After verifying the offsets in Dec set them back to 0 by clicking on the “X”


Pass Criteria 1) If the up arrow is clicked then the Dec offset is increased by 1 arcseconds. This

can be verified by looking at the target and current position and the offsets table.

The target Dec will increase by 1 arcsecond. The handset entry in the offsets

table increases by 1 arcseconds.


position.

3) If the down arrow is clicked then the Dec offset is decreased by 1 arcsecond.

This can be verified by looking at the target and current position and the offsets

table. The target Dec will decrease by 1 arcsecond. The handset entry in the

offsets table decreases by 1 arcsecond.


position.

5) When the “X” button is clicked the target Dec returns to its original value. The


Script None

Notes

Test AT4.4-0185-06
















6) In the “Target Offsets” tab select an offset type of tplane.







Pass Criteria 1) The RA offset is altered by the amount set in the RA text box (divided by cosine

of the Dec). This can be verified by looking at the target and current position

and the offsets table. The target RA will increase by the same amount. The

manual entry in the offsets table increases by the same amount also.


position.

3) The Dec offset is altered by the amount set in the Dec text box. This can be

verified by looking at the target and current position and the offsets table. The

target Dec will increase by the same amount. The manual entry in the offsets

table increases by the same amount also.


position.

5) When the “X” button is clicked the target RA and Dec return to their original



values. The handset entry for RA and Dec in the offsets table is reset to 0.

Script None

Notes

Test AT4.4-0185-07






2) In the “Control” tab on the TCS main engineering JES screen, select a

“Cartesian Helioprojective” target and set the x, y target demand to (0, 0).

3) Submit the configuration.




6) In the “Target Offsets” tab select an offset type of solar and a size of “1.0”

arcseconds.

7) Click on the right or left arrows to apply offsets in the cartesian helioprojective

frame, x direction.

8) Monitor the target, current positions and the helioprojective offsets table

(“Data” tab) on the TCS main engineering JES screen.

9) After verifying the offsets in cartesian helioprojective x set them back to 0 by

clicking on the “X” button on the Offsets JES screen.

Pass Criteria 1) If the right arrow is clicked then the cartesian helioprojective x offset is

increased by 1 arcsecond. This can be verified by looking at the target and

current position and the offsets table. The target x will increase by 1 arcsecond.

The handset entry in the helioprojective offsets table increases by 1 arcsecond.


position.



3) If the left arrow is clicked then the cartesian helioprojective x offset is decreased

by 1 arcsecond. This can be verified by looking at the target and current

position and the offsets table. The target x will decrease by 1 arcsecond. The

handset entry in the helioprojective offsets table decreases by 1 arcsecond.


position.

5) When the “X” button is clicked the target cartesian helioprojective x returns to

its original value. The handset entry in the offsets table is reset to 0.


Notes

Test AT4.4-0185-08












6) In the “Target Offsets” tab select an offset type of solar and a size of “1.0”

arcseconds.

7) Click on the up or down arrows to apply offsets in the cartesian helioprojective

frame, y direction.





9) After verifying the offsets in cartesian helioprojective y set them back to 0 by

clicking on the “X” button on the Offsets JES screen.

Pass Criteria 1) If the up arrow is clicked then the cartesian helioprojective y offset is increased

by 1 arcsecond. This can be verified by looking at the target and current

position and the offsets table. The target y will increase by 1 arcsecond. The

handset entry in the helioprojective offsets table increases by 1 arcsecond.


position.

3) If the down arrow is clicked then the cartesian helioprojective y offset is

decreased by 1 arcsecond. This can be verified by looking at the target and

current position and the offsets table. The target y will decrease by 1 arcsecond.

The handset entry in the helioprojective offsets table decreases by 1 arcsecond.


position.

5) When the “X” button is clicked the target cartesian helioprojective y returns to

its original value. The handset entry in the offsets table is reset to 0.


Notes

Test AT4.4-0185-09














6) In the “Target Offsets” tab select an offset type of solar.







Pass Criteria 1) The cartesian helioprojective x offset is altered by the amount set in the x text

box. This can be verified by looking at the target and current position and the

offsets table. The target cartesian helioprojective x will increase by the same

amount. The manual entry in the helioprojective offsets table increases by the

same amount also.


position.

3) The cartesian helioprojective y offset is altered by the amount set in the y text

box. This can be verified by looking at the target and current position and the

offsets table. The target cartesian helioprojective y will increase by the same

amount. The manual entry in the helioprojective offsets table increases by the

same amount also.


position.

5) When the “X” button is clicked the target cartesian helioprojective x and y

return to their original values. The manual entry for x and y in the

helioprojective offsets table is reset to 0.


Notes

3.25 RATE OFFSETS REQUIREMENTS

3.25.1 Requirement The TCS shall accept and display rate offsets from a nominal input target position in any of the required

tracking coordinate systems (see specification 4.4-0165). The TCS shall provide offset capability for the



TMA altitude, azimuth, and coudé rotator. When commanded through the TCS interface, the TCS shall

begin moving at a fixed rate in one axis of the requested coordinate system. When commanded again, the

TCS shall cease moving at the fixed rate in that axis. The altitude, azimuth, and coudé rotator shall

operate independently and simultaneously. Each axis of the requested coordinate system shall operate

independently and simultaneously.

The rate of motion shall be selectable through one of three fixed values. The fixed values shall be

parameters in the TCS parameter database. The rate of motion shall change when commanded through the

TCS interface, even during an ongoing rate offset.

3.25.2 Tests

Test AT4.4-0190-01





Test Steps 1) Fetch and save the current constant track rates

2) Set the current constant track rates to 0.0

3) Restore the previously saved constant track rates

Pass Criteria 1) Confirm that the constant track rates have all been set to 0.0

2) Confirm that the constant track rates have all been restored to their previous

values


Notes

Test AT4.4-0190-02





Test Steps 1) Set a helioprojective target of 0.0, 0.0 and set the mode to tracking



2) Apply constant track rate 1 to the helioprojective x

3) Read current position, wait 30 seconds and then read current position again

4) Stop constant track rate 1 for helioprojective x

5) Reset the target to helioprojective 0.0, 0.0 by clearing offsets

6) Apply the negative of constant track rate 1 to helioprojective x


8) Repeat steps 2 to 7 for helioprojective y

9) After applying an offset, absorb it and then attempt to clear it

Pass Criteria 1) Confirm the target has been set to helioprojective 0.0, 0.0 and that the telescope

is tracking

2) Confirm for each axis and track rate that

a. The demanded constant track rate is as requested

b. The change in position over 30 seconds is consistent with the demanded

track rate

3) Confirm that after absorbing an offset the total demanded position does not

change and that once absorbed clearing the offset has no affect.


Notes

Test AT4.4-0190-03








2) Apply constant track rate 2 to the helioprojective x and the negative of constant

track rate 3 to helioprojective y


4) Stop constant track rates 1 for both axes

5) Wait for 20 seconds

6) Reset the helioprojective target to 0,0, 0.0


is tracking

2) Confirm the demanded and measured track rates are equal to rate 2 for the x

axis and –rate 3 for the y axis

3) Confirm that the position is held constant at the current position once the stop

command is received.


Notes

Test AT4.4-0190-04





Test Steps 1) Set a FK5 target with an RA equal to the current LAST and a declination of 30

and set the mode to tracking

2) Apply constant track rate 1 to RA


4) Stop constant track rate 1 for RA

5) Reset the target by clearing the offset



6) Apply the negative of constant track rate 1 to RA


8) Repeat steps 2 to 7 for declination


Pass Criteria 1) Confirm the target has been set to the demanded RA and Declination and that

the telescope is tracking




track rate


change and that once absorbed clearing the offset has no affect


Notes

Test AT4.4-0190-05





Test Steps 1) Set an FK5 target with an RA equal to the current LAST and a Declination of 30

and set the mode to tracking

2) Apply constant track rate 2 to RA and the negative of constant track rate 3 to

Declination






6) Reset the target

Pass Criteria 1) Confirm the target has been set and that the telescope is tracking

2) Confirm the demanded and measured track rates are equal to rate 2 for the RA

axis and –rate 3 for the Declination axis




Notes

Test AT4.4-0190-06





Test Steps 1) Set an AZEL target of 10.0, 30.0 and set the mode to tracking

2) Apply constant track rate 1 to azimuth


4) Stop constant track rate 1 for azimuth


6) Apply the negative of constant track rate 1 to altitude


8) Repeat steps 2 to 7 for altitude


Pass Criteria 1) Confirm the target has been set to the demanded azimuth and altitude and that







track rate




Notes

Test AT4.4-0190-07






2) Apply constant track rate 2 to azimuth and the negative of constant track rate 3

to altitude




6) Reset the target

Pass Criteria 1) Confirm the target has been set and that the telescope is tracking

2) Confirm the demanded and measured track rates are equal to rate 2 for the

azimuth axis and –rate 3 for the altitude axis






Notes

Test AT4.4-0190-08






2) Set the rotator frame to AZEL with a position angle of -90.0

3) Apply constant track rate 1 to the rotator

4) Read current position of the rotator , wait 30 seconds and then read current

position again

5) Stop constant track rate 1 for the rotator

6) Reset the coude position angle to -90.0

7) Apply the negative of constant track rate 1 to the rotator


Pass Criteria 1) Confirm the target has been set to the demanded azimuth and altitude and that


2) For the rotator axis confirm



track rate


Notes



Test AT4.4-0190-09





Test Steps 1) Send a configuration with trackRateDirection set to “stop”

2) Send a configuration with trackRateDirection set to “positive”

3) Send a configuration with trackRateDirection set to “positive” and a

trackRateIndex of 1

4) Send a configuration with trackRateDirection set to “negative” and a

trackRateAxis of 0

Pass Criteria 1) Confirm that each configuration is rejected as invalid with an appropriate error

message


Notes

Test AT4.4-0190-10






2) Set the rotator tracking frame to HP and the position angle to 0.0

3) Set a constant tracking rate using rate1 for the rotator in a positive direction

4) Read current rotator position, wait 30 seconds and then read current rotator

position again

5) Stop constant track rate 1 for the rotator



6) Reset the rotator position angle to 0.0

7) Apply the negative of constant track rate 1 to the rotator

8) Read current rotator position, wait 30 seconds and then read current position

again

9) Stop the constant track rate for the rotator


is tracking

2) Confirm that



track rate


Notes This test was written as a result of the bug reported in ATCS-111

Test AT4.4-0190-11





Test Steps 1) Set a HPR target of 1.0, 0.0 and set the mode to tracking

2) Apply constant track rate 1 to the helioprojective radial angle


4) Stop constant track rate 1 for helioprojective radial angle


6) Apply the negative of constant track rate 1 to the helioprojective radial angle




8) Repeat steps 2 to 7 for radius


Pass Criteria 1) Confirm the target has been set to the demanded helioprojective radial

coordinates and that the telescope is tracking




track rate




Notes

Test AT4.4-0190-12





Test Steps 1) Set a HG target of 0.0, L0 and set the mode to tracking

2) Apply constant track rate 1 to the heliographic latitude


4) Stop constant track rate 1 for heliographic latitude


6) Apply the negative of constant track rate 1 to the heliographic latitude




8) Repeat steps 2 to 7 for heliographic longitude


Pass Criteria 1) Confirm the target has been set to the demanded heliographic coordinates and

that the telescope is tracking




track rate




Notes

3.26 WAVEFRONT REQUIREMENTS – WAVEFRONT CORRECTION

3.26.1 Requirement

“The TCS shall control the wavefront correction strategy for the telescope under direction from the

OCS and/or operator. The TCS shall respond to one of the three possible wavefront correction modes

by sending the appropriate commands to the telescope subsystems. It shall monitor the behaviour of

the telescope subsystems to assure that the appropriate wavefront correction mode is operational.

Wavefront information is sent from the WCCS to the pertinent telescope subsystems: the M1 Control

System, M2 Control System, and Feed Optics Control System. Each of these recipient subsystems

can either use internal lookup tables to perform their corrections (open-loop wavefront correction) or

use the wavefront information sent by the WCCS (closed-loop wavefront control). Additionally, the

WCCS can determine either active or active-plus-adaptive optics corrections. It is the responsibility

of the operator or observer to select the appropriate mode. It is the responsibility of the TCS to

propagate the selected mode to the telescope subsystems. It is the responsibility of the WCCS to

generate the appropriate corrections based upon the selected mode and send those corrections to the

telescope subsystems.

A wavefront correction mode sent by the TCS shall be one of the following:



Open loop: The M1CS, M2CS, and FOCS will use their internal lookup tables to perform the

optical corrections. The WCCS does not transmit wavefront correction information to these systems.

Closed loop active optics: The M1CS, M2CS, and FOCS will receive and use optics

corrections from the WCCS. The WCCS will perform only active optics and quasi-static alignment corrections.

Closed loop adaptive optics: The M1CS, M2CS, and FOCS will receive and use optics

corrections from the WCCS. The WCCS will perform high order corrections through its

internal components (e.g., the deformable mirror and fast tip-tilt mirror(s)).”

3.26.2 Setup

3.26.3 Tests

Test AT4.4-0200-01

Requirement 4.4-0200-01

Preconditions 1) Ensure the TCS is in the "running" state

2) Ensure the WCCS is in the "running" state

3) Ensure the FOCS is in the "running" state

4) Ensure the TEOACS is in the "running" state

5) Ensure the PAC is in the "running" state

6) Ensure the M1CS is in the “running” state

Test Steps 1) Set the TCS aoMode to "idle"

2) Set the TCS aoMode to "limbTracking"

3) Set the TCS aoMode to "calibrate"

4) Set the TCS aoMode to "off"

5) Set the TCS aoMode to a closed loop mode i.e. “diffractionLimited”

6) Set the TCS aoMode to an open loop mode i.e. “idle”

Pass Criteria 1) Confirm that the WCCS mode changes to "idle" after step 1

2) Confirm that the WCCS mode changes to "limbTracking" after step 2

3) Confirm that the WCCS mode changes to "calibrate" after step 3

4) Confirm that the WCCS mode changes to "off" and the FOCS, M1CS and



TEOACS modes change to "off" after step 4

5) Confirm that the WCCS mode changes to "diffractionLimited" and the FOCS,

M1CS and TEOACS modes change to "active" after step 5

6) Confirm that the WCCS mode changes to "idle" and the FOCS, M1CS and

TEOACS modes change to "passive" after step 6


Notes The requirement that led to this test has largely been superseded by requirement 4.4-

0225. There are no longer explicit open and closed loop operating modes but rather

these are implied by the mode sent to the WCCS.

3.27 WAVEFRONT REQUIREMENTS – WCCS CONTROL OF THE POLARIMETRY ANALYSIS AND

CALIBRATION

3.27.1 Requirement

“The TCS shall provide the capability for the Wavefront Correction Control System to control

directly the actions of the Polarimetry Analysis and Calibration system. The TCS shall notify both

the WCCS and the PA&C when this capability is in effect and when normal control of both systems

has resumed.

To allow this activity, the TCS shall prevent further external actions from occurring on other systems

until either the Wavefront Correction Control System completes its actions on the Polarimetry

Analysis and Calibration system or the operator cancels the ongoing WCCS action. Further external

actions include commanded operations such as telescope offsets, scans, new target position, new

wavefront modes, etc. The TCS shall continue to track on the current position during this period.”

3.27.2 Setup

3.27.3 Tests

Test AT4.4-0210-01

Requirement 4.4-0210-01


2) Ensure the WCCS is in the "running" state

3) Ensure the FOCS is in the "running" state

4) Ensure the TEOACS is in the "running" state



5) Ensure the PAC is in the "running" state

6) Ensure the TMA is in the "running" state

7) Ensure the ECS is in the "running" state

Test Steps 1) Set and track a target

2) Set the TCS aoMode to “calibrate"

3) Attempt to set a new target position

4) Attempt to set a target offset

5) Set the TCS aoMode to "idle"

6) Now attempt to set a new target

Pass Criteria 1) Confirm that the target is set and the telescope starts tracking

2) Confirm that the WCCS mode changes to “calibrate" after step 2

3) Confirm that the new target position is rejected with a message that the WCCS

has control of the telescope at step 3

4) Confirm that the offset is rejected with a message that the WCCS is in charge of

the telescope at step 4

5) Confirm that the WCCS mode changes to "idle" and the FOCS, M1CS and

TEOACS modes change to "passive" after step 5

6) Confirm that the new target position is now accepted by the TCS


Notes

3.28 WAVEFRONT REQUIREMENTS – WAVEFRONT CORRECTION OFFLOAD



3.28.1 Requirement

“The TCS shall receive from the Wavefront Correction Control System an offload for the MCS of

any built-up tip-tilt bias in the WCCS. The TCS shall apply this offload as a positional error coming

from the AO, per the closed loop pointing requirements of Requirement 4.4-0150. Offloads shall

occur at rates of no more than 1 Hz.

Tip-tilt mirrors in the wavefront correction system may accumulate positional bias as they perform

their corrections. It is useful to offload this bias to the telescope pointing to recover some of the

dynamic range of the mirror. The TCS shall accept the WCCS offload and apply it to the pointing

correction for the Telescope Mount Assembly and MCS as described in Req. 4.4-0150. From the

TCS point-of-view, this offload is indistinguishable from a guider correction signal.”

3.28.2 Setup

3.28.3 Tests

Test AT4.4-0215-01





Test Steps 1) Slew to and track a suitable target

2) Clear any guide corrections and configure the TCS to have a guide gain of 1.0

3) Instruct the TCS to guide

4) Monitor both the guide corrections as sent out by the ACS and the guide

offloads as being applied by the TCS to the mount

5) Turn guiding off and clear any accumulated guide corrections

Pass Criteria 1) At step 4 ensure that the integrated guide signal from the ACS is equal to the

guide offload applied to the mount


Notes



Test AT4.4-0215-02





Test Steps 1) Slew to and track a suitable target

2) Clear any offset corrections and configure the TCS to have a guide gain of 1.0

3) Instruct the TCS to guide

4) Post relative offset corrections of 0.5 and 1.0 arcsecs

5) Monitor both the offset corrections as sent out by the WCCS and the offsets

applied by the TCS target

6) Turn guiding off and clear any accumulated guide corrections

Pass Criteria 1) At step 5 ensure that the total offset corrections from the WCCS are equal to the

offset applied to the TCS target


Notes

3.29 WAVEFRONT REQUIREMENTS – WAVEFRONT CORRECTION MODE

3.29.1 Requirement The TCS shall accept a WCCS mode attribute and use the value of the attribute to set the corresponding

AO modes for the FOCS, TEOACS, and M1CS. For the WCCS mode value of “off”, "idle", and “limb

tracking” the FOCS, TEOACS, and M1CS AO modes shall be set to "passive." For all other values of the

WCCS mode, the FOCS, TEOACS, and M1CS AO mode shall be set to "active." The TCS shall reject a

command if the WCCS mode attribute is sent with any FOCS, TEOACS, or M1CS AO mode attribute.

WFC mode AO modes M2 FTT mode / input source

off passive off / teoa

idle passive off / teoa

calibrate active on / wfc

diffraction limited active off / teoa

seeing limited on-disk active off / teoa

seeing limited coronal active off / teoa

limb tracking passive on / wfc



The TCS shall provide the current state of the WCCS mode attribute in its status event.

3.29.2 Tests

Test AT4.4-0225-01



2) Ensure the WCCS is in the “running” state

3) Ensure the FOCS is in the “running” state

4) Ensure the TEOACS is in the “running” state

5) Ensure the M1CS is in the “running” state

Test Steps 1) Submit a configuration containing a WCCS mode and an M1CS mode

2) Submit a configuration containing a WCCS mode and an FOCS mode

3) Submit a configuration containing a WCCS mode and a TEOACS mode

4) Monitor the event atst.tcs.cStatus

5) Submit a configuration with the WCCS mode set to calibrate

6) Submit a configuration with the WCCS mode set to diffractionLimited

7) Submit a configuration with the WCCS mode set to seeingLimitedOnDisk

8) Submit a configuration with the WCCS mode set to seeingLimitedCoronal

9) Submit a configuration with the WCCS mode set to idle

10) Submit a configuration with the WCCS mode set to off

Pass Criteria 1) The configuration is rejected with a message that it is not permitted to set a

WCCS mode and subsystem mode in the same configuration

2) The configuration is rejected with a message that it is not permitted to set a


3) The configuration is rejected with a message that it is not permitted to set a


4) The event contains the attribute called cAoMode



5) The configuration is accepted and the subsystems are set to the states described

in the table above


in the table above


in the table above


in the table above


in the table above


in the table above


Notes

3.30 THERMAL REQUIREMENTS – WEATHER STATION

3.30.1 Requirement

“The TCS shall monitor the ATST weather reporting station and provide data from this station

through CSF event to other telescope systems. The data may be requested by systems such as the

operator’s display, ICS, or a telescope subsystem. Weather data shall include temperature, dew point,

wind direction and speed, radiance, and atmospheric pressure. Additional data may include an all-sky

camera, SDIMM, and SHABAR.”

N.B. This original requirement was withdrawn but the TCS still monitors the weather station.

3.30.2 Setup

3.30.3 Tests

Test AT4.4-0310-01



7) Ensure the weather controller mode of the TCS is set to “automatic”.

Test Steps 11) Post weather server events on the channel “atst.ws.envrionment”. The events

should contain known values of “airtemp:value”, “pressure:value” and



“humidity:value”.

12) Verify the event is received by the TCS.

13) Verify the values set in the TCS weather controller are those posted in the

events.

14) Verify the health of the weather controller is set to “good”.

15) Stop posting the weather server events for more than 10 seconds.

16) Verify the health of the weather controller is set to “ill” with an appropriate

reason explaining why the controller is ill.

Pass Criteria 11) The weather controller receives the weather server events.

12) The data contained within the events is updated and reflected by the TCS.

13) The health of the weather controller remains good whilst the events are received

by the TCS.

14) After a period of 10 seconds without events the TCS sets its health to “ill” and

provides an appropriate message explaining the health.


Notes

Test AT4.4-0310-02



2) Ensure the weather controller mode of the TCS is set to “automatic”.

Test Steps 1) Change the weather controller mode to “manual”.

2) Verify the health of the weather controller turns “ill” with an appropriate

message.

3) Verify the values of airtemp, pressure and humidity are unchanged once the

mode has been changed.



4) Submit a configuration with new values for the airtemp, pressure and humidity.

5) Verify the values of airtemp, pressure and humidity are updated to match the

submitted values and verify the origin of the values is set as “manual”.

Pass Criteria 1) When the mode of the weather controller is changed to manual the health is set

to “ill” with an appropriate message explaining why the health is “ill”.

2) When the mode of the weather controller is changed to manual the values of

airtemp, pressure and humidity remain unchanged.

3) When a configuration containing new manual attributes for airtemp, pressure

and humidity is submitted the values are updated and so are the source entries.


Notes

3.31 SUBSYSTEM REQUIREMENTS – SEQUENCING SUBSYSTEMS

3.31.1 Requirement

“The TCS shall control the sequencing of commands sent to the subsystems. All commands sent to

the TCS will contain no knowledge of the specific subsystem, its sequencing requirements, or its

current state.

The TCS shall monitor and maintain the software connection with the subsystems. The TCS shall

reconnect with subsystems if they are rebooted or otherwise lose their connection. The TCS shall

generate an alarm if it cannot connect to a subsystem and shall generate log messages on any

connection failure and reconnect.”

3.31.2 Setup

3.31.3 Tests

Test AT4.4-0400-01




ECS, M1CS, ACS, FOCS, PAC, TEOACS and WCCS simulators are in the

“running” state.

Test Steps 1) Shutdown and drop the MCS simulator.



2) Reload and restart the MCS simulator.

3) Shutdown and drop the ECS simulator.

4) Reload and restart the ECS simulator.

5) Shutdown and drop the M1CS simulator.

6) Reload and restart the M1CS simulator.

7) Shutdown and drop the ACS simulator.

8) Reload and restart the ACS simulator.

9) Shutdown and drop the FOCS simulator.

10) Reload and restart the FOCS simulator.

11) Shutdown and drop the PAC simulator.

12) Reload and restart the PAC simulator.

13) Shutdown and drop the TEOACS simulator.

14) Reload and restart the TEOACS simulator.

15) Shutdown and drop the WCCS simulator.

16) Reload and restart the WCCS simulator.

Pass Criteria 1) When the MCS simulator is shut down the TCS generates an alarm to notify that

the connection to the MCS has been lost.

2) When the MCS simulator is shut down the TCS logs a messages to record that

the connection to the MCS has been lost.

3) Whilst the MCS is shutdown the TCS will display the state, in position state and

mode of the MCS as “Unavailable”.

4) When the MCS is restarted the TCS logs a message to record that the connection

to the MCS has been re-established.

5) When the MCS is restarted the TCS reconnects to the MCS. This can be

verified by checking the TCS display for the state, in position state and mode of

the MCS, which will not read “Unavailable”.



6) When the ECS simulator is shut down the TCS generates an alarm to notify that

the connection to the ECS has been lost.

7) When the ECS simulator is shut down the TCS logs a messages to record that

the connection to the ECS has been lost.

8) Whilst the ECS is shutdown the TCS will display the state, in position state and

mode of the ECS as “Unavailable”.

9) When the ECS is restarted the TCS logs a message to record that the connection

to the ECS has been re-established.

10) When the ECS is restarted the TCS reconnects to the ECS. This can be verified

by checking the TCS display for the state, in position state and mode of the

ECS, which will not read “Unavailable”.

11) When the M1CS simulator is shut down the TCS generates an alarm to notify

that the connection to the M1CS has been lost.

12) When the M1CS simulator is shut down the TCS logs a messages to record that

the connection to the M1CS has been lost.

13) Whilst the M1CS is shutdown the TCS will display the state, in position state

and mode of the M1CS as “Unavailable”.

14) When the M1CS is restarted the TCS logs a message to record that the

connection to the M1CS has been re-established.

15) When the M1CS is restarted the TCS reconnects to the M1CS. This can be


the M1CS, which will not read “Unavailable”.

16) When the ACS simulator is shut down the TCS generates an alarm to notify that

the connection to the ACS has been lost.

17) When the ACS simulator is shut down the TCS logs a messages to record that

the connection to the ACS has been lost.

18) Whilst the ACS is shutdown the TCS will display the state, in position state and

mode of the ACS as “Unavailable”.

19) When the ACS is restarted the TCS logs a message to record that the connection

to the ACS has been re-established.

20) When the ACS is restarted the TCS reconnects to the ACS. This can be verified


ACS, which will not read “Unavailable”.



21) When the FOCS simulator is shut down the TCS generates an alarm to notify

that the connection to the FOCS has been lost.

22) When the FOCS simulator is shut down the TCS logs a messages to record that

the connection to the FOCS has been lost.

23) Whilst the FOCS is shutdown the TCS will display the state, in position state

and mode of the FOCS as “Unavailable”.

24) When the FOCS is restarted the TCS logs a message to record that the

connection to the FOCS has been re-established.

25) When the FOCS is restarted the TCS reconnects to the FOCS. This can be


the FOCS, which will not read “Unavailable”.

26) When the PAC simulator is shut down the TCS generates an alarm to notify that

the connection to the PAC has been lost.

27) When the PAC simulator is shut down the TCS logs a messages to record that

the connection to the PAC has been lost.

28) Whilst the PAC is shutdown the TCS will display the state, in position state and

mode of the PAC as “Unavailable”.

29) When the PAC is restarted the TCS logs a message to record that the connection

to the PAC has been re-established.

30) When the PAC is restarted the TCS reconnects to the PAC. This can be verified


PAC, which will not read “Unavailable”.

31) When the TEOACS simulator is shut down the TCS generates an alarm to notify

that the connection to the TEOACS has been lost.

32) When the TEOACS simulator is shut down the TCS logs a messages to record

that the connection to the TEOACS has been lost.

33) Whilst the TEOACS is shutdown the TCS will display the state, in position state

and mode of the TEOACS as “Unavailable”.

34) When the TEOACS is restarted the TCS logs a message to record that the

connection to the TEOACS has been re-established.

35) When the TEOACS is restarted the TCS reconnects to the TEOACS. This can

be verified by checking the TCS display for the state, in position state and mode

of the TEOACS, which will not read “Unavailable”.



36) When the WCCS simulator is shut down the TCS generates an alarm to notify

that the connection to the WCCS has been lost.

37) When the WCCS simulator is shut down the TCS logs a messages to record that

the connection to the WCCS has been lost.

38) Whilst the WCCS is shutdown the TCS will display the state, in position state

and mode of the WCCS as “Unavailable”.

39) When the WCCS is restarted the TCS logs a message to record that the

connection to the WCCS has been re-established.

40) When the WCCS is restarted the TCS reconnects to the WCCS. This can be


the WCCS, which will not read “Unavailable”.


Notes

Test AT4.4-0400-02





3) Ensure the mode of the TCS and simulators is “off”.

Test Steps 1) Submit a configuration that contains only one attribute to the TCS:

“atst.tcs.mode = active”

2) Monitor the mode of the TCS and the mode of all subsystems.

Pass Criteria 1) When the configuration is submitted the mode of the TCS transitions to

“active”.

2) The mode of the MCS and ECS simulators transition to “active”, reflecting the

fact that the TCS has propagated the mode attribute to these subsystems

irrespective of their state or sequencing requirements.




Notes

Test AT4.4-0400-03





3) Ensure the mode of the TCS and simulators is not “off”.


“atst.tcs.mode = off”


Pass Criteria 1) When the configuration is submitted the mode of the TCS transitions to “off”.

2) The mode of the MCS and ECS simulators transition to “off”, reflecting the fact

that the TCS has propagated the mode attribute to these subsystems irrespective

of their state or sequencing requirements.


Notes

Test AT4.4-0400-04





3) Ensure the mode of the TCS and simulators is “off”.




“atst.tcs.mode = tracking”


Pass Criteria 1) When the configuration is submitted the mode of the TCS transitions to

“tracking”.

2) The mode of the MCS and ECS simulators transition to “tracking”, reflecting

the fact that the TCS has propagated the mode attribute to these subsystems

irrespective of their state or sequencing requirements.


Notes

3.32 SUBSYSTEM REQUIREMENTS – ENCLOSURE

3.32.1 Requirement

“The TCS shall control the Enclosure Control System as defined in the TCS-to-ECS Interface

Control Document. The TCS shall give the ECS a continuous stream of azimuth and altitude data,

corrected for dome center or opening alignment errors, sufficient to keep the dome position always

within tolerance. The TCS shall read all enclosure status information, including, but not limited to,

azimuth position and rate, shutter position and rate, cable or utility wraps, door and equipment

sensors. The TCS shall not control engineering equipment associated with the enclosure such as

cranes, doors, and lifts. The TCS shall not control the thermal systems of the enclosure.”

3.32.2 Setup

3.32.3 Tests

Test AT4.4-0405-01





Test Steps 1) Open the EventView application.

2) Subscribe to the “atst.tcs.ecsTrajectory” event channel.

3) Shutdown the “atst.tcs” controller (place it into the “initialized” state).



4) Restart the “atst.tcs” controller (place it into the “running” state).

Pass Criteria 1) When the subscription to the “atst.tcs.ecsTrajectory” is made events are

recorded at a rate of 20Hz.

2) The events continue to be sent at 20Hz and only stop when the TCS is taken out

of the “running” state.

3) When the TCS is put back into the “running” state the events start again at

20Hz.

4) The structure of the event is exactly the same as that defined in the document

ICD 4.4-5.6 TCS to ECS, section 4.15.1.


Notes

Test AT4.4-0405-02





3) Ensure the mode of the TCS, MCS and ECS is “off”.

Test Steps 1) Connect to the ECS and set the debug level of the ECS to 2.

2) Change the TCS mode to “tracking”.

3) Set a named position of “stow”

4) Set a named position of “index”

5) Change the TCS mode to “tracking”

6) Change the mode of the TCS to “off”

7) Set the debug level of the ECS back to 2



Pass Criteria 1) The debug level of the ECS changes to 2

2) The TCS, MCS and ECS modes transition to “tracking”

3) The ECS transitions to “stow” and that this is reflected in the container log

4) The ECS takes no action when the TCS is sent an “index” as it has no indexing

capability

5) The ECS transitions back to tracking

6) The ECS transitions to off

7) The debug level of the ECS changes to 0


Notes

3.33 SUBSYSTEM REQUIREMENTS – MOUNT

3.33.1 Requirement

“The TCS shall control the Mount Control System as defined in the TCS-to-TMA Interface Control

Document. The TCS shall provide the MCS a continuous stream of position and rate data, including

the azimuth and altitude axes of the mount assembly, and the coudé rotator. The TCS shall set the

position of the drive motors, brakes, and locking pins. The TCS shall read all MCS status

information, including, but not limited to, azimuth and altitude position and rate, coudé rotator

position and rate, cable wrap position, thermal control systems, drive status, and limit switches.”

3.33.2 Tests

Test AT4.4-0410-01






2) Subscribe to the “atst.tcs.mcsTrajectory” event channel.

3) Shutdown the “atst.tcs” controller (place it into the “initialized” state).



4) Restart the “atst.tcs” controller (place it into the “running” state).

Pass Criteria 1) When the subscription to the “atst.tcs.mcsTrajectory” is made events are

recorded at a rate of 20Hz.

2) The events continue to be sent at 20Hz and only stop when the TCS is taken out

of the “running” state.

3) When the TCS is put back into the “running” state the events start again at

20Hz.

4) The structure of the event is exactly the same as that defined in the document

ICD 1.1-4.4 TMA to TCS, section 4.15.1.


Notes

Test AT4.4-0410-02





Test Steps 1) Set the mode of the TCS, MCS and ECS to “off”

2) Set the MCS_CONF debug level of the MCS to 1.

3) Change the TCS mode to “tracking”.

4) Monitor the TCS.SIMS log file.

Pass Criteria 1) The TCS, MCS and ECS modes transition to “tracking”.

2) The TCS submits a configuration containing the mode attribute and the trackId

attribute to the MCS as defined in the document ICD 1.1-4.4 TMA to TCS,

section 4.8.1 and 4.8.2. This can be verified by checking the debug log

messages in the TCS.SIMS log.




Notes

Test AT4.4-0410-03





3) Ensure the mode of the TCS, MCS and ECS is “tracking”.

Test Steps 1) Open a terminal and start the Testharness.

2) In the test harness type “debug atst.tcs.mcs 2 null” to set the debug level of the

MCS to 2.

3) From the TCS main engineering JES screen, request the TCS to “STOW”.


Pass Criteria 1) The TCS, MCS and ECS modes transition to “active”.

2) The TCS submits a configuration containing the mode attribute (set to active)

and the namedPos attribute (set to stow) to the MCS as defined in the document

ICD 1.1-4.4 TMA to TCS, section 4.8.1 and 4.8.3. This can be verified by

checking the debug log messages in the TCS.SIMS log.


Notes

Test AT4.4-0410-04










MCS to 2.

3) From the TCS main engineering JES screen, request the TCS to “INDEX”.


Pass Criteria 1) The TCS, MCS and ECS modes transition to “active”.

2) The TCS submits a configuration containing the mode attribute (set to active)

and the namedPos attribute (set to index) to the MCS as defined in the document

ICD 1.1-4.4 TMA to TCS, section 4.8.1 and 4.8.3. This can be verified by

checking the debug log messages in the TCS.SIMS log.


Notes

Test AT4.4-0410-05








MCS to 2.

3) From the TCS main engineering JES screen, change the TCS mode to “off”.


Pass Criteria 1) The TCS, MCS and ECS modes transition to “off”.



2) The TCS submits a configuration containing the mode attribute (set to off) to the

ECS as defined in the document ICD 1.1-4.4 TMA to TCS, section 4.8.1. This

can be verified by checking the debug log messages in the TCS.SIMS log.


Notes

Test AT4.4-0410-06





Test Steps 1) Slew to the solar center by issuing a target of 0.0, 0.0 in a helioprojective frame

2) Subscribe to the MCS trajectory stream and log the raw coefficient data as well

as the differences between what is calculated from the current coefficient set and

the next coefficient set for a period of 600s

Pass Criteria 1) The mode changes to tracking and the telescope slews to track the solar center

2) Inspect plots of the differences of any unexpected jumps.


Notes

Test AT4.4-0410-07





Test Steps 1) Slew to an FK5 target that will transit in about 300s at an elevation of 45



degrees and an azimuth of 180

2) Subscribe to the MCS trajectory stream and log the raw coefficient data as well

as the differences between what is calculated from the current coefficient set and

the next coefficient set for a period of 600s

Pass Criteria 1) The mode changes to tracking and the telescope slews to track the target



Notes The default setup for this test is as described above but the test can generate track

profiles for a number of different targets

1) Profile 1 – a target that will shortly rise above the lower elevation limit

2) Profile 2a – a target transiting at an elevation of 45 degrees through azimuth 0

3) Profile 2b – a target transiting at an elevation of 45 degrees through azimuth 180

4) Profile 2c – a target transiting at an elevation of 45 degrees through azimuth 0

from negative to positive

5) Profile 3a – a target transiting through azimuth 0 at the edge of the blind spot

6) Profile 3b – a target transiting through azimuth 180 at the edge of the blind spot

7) Profile 3c – a target passing through the blind spot

8) Profile 7a – a target transiting at 85 degrees through azimuth 0

9) Profile 7b – a target transiting at 85 degrees through azimuth 180

10) Profile 8a – a target passing through azimuth velocity 0 with altitude around 21

11) Profile 8b – a target passing through azimuth velocity 0 with altitude around 24

12) Profile 8c – a target passing through azimuth velocity 0 with altitude around 34

13) Profile 8d – a target passing through azimuth velocity 0 with altitude around 50

Test AT4.4-0410-08






2) Subscribe to the sollib data event and log the topocentric position demands as

well as the differences between what is calculated from one set of demands and

the next set and the for a period of 600s






Notes

Test AT4.4-0410-09






2) Subscribe to the tpk.pk data event and log the topocentric position and

differential track rate demands as well as the differences between what is

calculated from one set of demands and the next set and the for a period of 600s




Notes

3.33.3 Requirement – Specific coude platform rotation

For certain polarization calibration measurements it is required that the coude table position is

maintained at a fixed offset relative to the azimuth position.

In addition to the coude modes that maintain a fixed alignment relative to the sun and a fixed

alignment relative to the local horizon, the TCS shall implement a mode that maintains a fixed

relationship between the telescope azimuth and the coude table position.

Test AT4.4-0412-01


Preconditions 1) Ensure the TCS, MCS and ECS are in the “running” state.

Test Steps 1) Slew to an FK5 target at the current RA and Dec.



2) Set an ipaFrame of AZ and a position angle of 0.0 degrees.

3) Set a position angle of 10.0 degrees.

Pass Criteria 1) Verify that after step 2 the azimuth and rotator demands are equal to within 0.1

degrees

2) Verify that after step 3 the rotator demand is 10.0 degress greater than the

azimuth plu or minus 0.1 degrees.


Notes

3.34 SUBSYSTEM REQUIREMENTS – M1 MIRROR

3.34.1 Requirement

“The TCS shall control the M1 Mirror Control System (M1CS) as defined in the TCS-to-M1

Assembly Interface Control Document.

The TCS shall perform the following operations on the M1CS:

Select the wavefront correction mode;

Monitor the status and health;

Send the current mount position, temperature, and other values needed for determining the

open-loop mirror figure error; and

Select the thermal cooling mode;”

3.34.2 Setup

3.34.3 Tests

Test AT4.4-0415-01



2) Ensure the TCS.SIMS container is in the “running” state and ensure all

simulators are in the “running” state.

Test Steps 1) Submit a configuration with the attribute thermalMode="precondition" and

verify the configuration is accepted. Verify the mode of the M1CS is set to

"precondition".

2) Submit a configuration with the attribute thermalMode="ondisk" and verify the

configuration is accepted. Verify the mode of the M1CS is set to "ondisk".



3) Submit a configuration with the attribute thermalMode="off" and verify the

configuration is accepted. Verify the mode of the M1CS is set to "off".

Pass Criteria 1) The configuration is accepted and completes. The event

atst.tcs.m1cs.thermal.cStatus contains the cThermalMode attribute set to

"precondition".

2) The configuration is accepted and completes. The event

atst.tcs.m1cs.thermal.cStatus contains the cThermalMode attribute set to

"ondisk".

3) The configuration is accepted and completes. The event

atst.tcs.m1cs.thermal.cStatus contains the cThermalMode attribute set to "off".


Notes

Test AT4.4-0415-02





Test Steps 1) Submit a configuration with the attribute aoMode="idle" and verify the

configuration is accepted. Verify the mode of the M1CS is set to "passive".

2) Submit a configuration with the attribute aoMode="diffractionLimited" and

verify the configuration is accepted. Verify the mode of the M1CS is set to

"active".

3) Submit a configuration with the attribute aoMode="off" and verify the

configuration is accepted. Verify the mode of the M1CS is set to "off" or

“passive”

Pass Criteria 1) The configuration is accepted and completes. The event atst.tcs.m1cs.cStatus

contains the mode attribute set to "passive".

2) The configuration is accepted and completes. The event atst.tcs.m1cs.cStatus

contains the mode attribute set to "active".



3) The configuration is accepted and completes. The event atst.tcs.m1cs.cStatus

contains the mode attribute set to "off" or “passive”.


Notes

3.35 SUBSYSTEM REQUIREMENTS – M2 MIRROR AND TOP-END ASSEMBLY

3.35.1 Requirement

“The TCS shall control the Top End Assembly Control System (TEOACS) as defined in the TCS-to-

TEAO Interface Control Document. The TEAOCS includes the M2 Mirror, the heat stop, and the

Lyot stop.

The TCS shall perform the following operations on the TEOACS:

Select the wavefront correction mode for the M2 tip-tilt-focus;


Select the thermal cooling mode; and

Select the Lyot stop position;”

3.35.2 Setup

3.35.3 Tests

Test AT4.4-0420-01






configuration is accepted. Verify the mode of the TEOACS is set to "passive".


verify the configuration is accepted. Verify the mode of the TEOACS is set to

"active".


configuration is accepted. Verify the mode of the TEOACS is set to "off".



Pass Criteria 1) The configuration is accepted and completes. The event atst.tcs.teoacs.cStatus

contains the aoMode attribute set to "passive".

2) The configuration is accepted and completes. The event atst.tcs.teoacs.cStatus

contains the aoMode attribute set to "active".

3) The configuration is accepted and completes. The event atst.tcs.teoacs.cStatus

contains the aoMode attribute set to "off".


Notes

3.36 SUBSYSTEM REQUIREMENTS – FEED OPTICS

3.36.1 Requirement

“The TCS shall control the Feed Optics Control System (FOCS) as defined in the TCS-to-Feed

Optics Assemblies Interface Control Document.

The TCS shall perform the following operations on the FOCS:

Select the wavefront correction mode for M3 and M6; and

Monitor the status and health;”

3.36.2 Setup

3.36.3 Tests

Test AT4.4-0425-01






configuration is accepted. Verify the mode of the FOCS is set to "passive".


verify the configuration is accepted. Verify the mode of the FOCS is set to

"active".


configuration is accepted. Verify the mode of the FOCS is set to "off" or



“passive”.

Pass Criteria 1) The configuration is accepted and completes. The event atst.tcs.focs.cStatus


2) The configuration is accepted and completes. The event atst.tcs.focs.cStatus


3) The configuration is accepted and completes. The event atst.tcs.focs.cStatus

contains the mode attribute set to "off" or “passive”.


Notes

3.37 SUBSYSTEM REQUIREMENTS – WAVEFRONT

3.37.1 Requirement

“The TCS shall manage the Wavefront Correction Control System as defined in the TCS-to-WCCS

Interface Control Document.

The TCS shall perform the following operations on the WCCS:

Select the wavefront correction mode for the AO/aO systems;


Select the output storage type of the context viewer(s); and

Select the calibration mode for control of the PA&C;”

3.37.2 Setup

3.37.3 Tests

Test AT4.4-0430-01






configuration is accepted. Verify the mode of the WCCS is set to "idle".




verify the configuration is accepted. Verify the mode of the WCCS is set to

"diffractionLimited".


configuration is accepted. Verify the mode of the WCCS is set to "off".

4) Submit a configuration with the attribute aoMode="calibrate" and verify the

configuration is accepted. Verify the mode of the WCCS is set to "calibrate".

5) Submit a configuration with the attribute aoMode="limbTracking" and verify

the configuration is accepted. Verify the mode of the WCCS is set to

"limbTracking".

6) Submit a configuration with the attribute aoMode="idle" and verify the

configuration is accepted. Verify the mode of the WCCS is set to "idle".

Pass Criteria 1) The configuration is accepted and completes. The event atst.tcs.wccs.cStatus

contains the cMode attribute set to "idle".

2) The configuration is accepted and completes. The event atst.tcs.wccs.cStatus

contains the cMode attribute set to "diffractionLimited".


contains the cMode attribute set to "off".


contains the cMode attribute set to "calibrate".


contains the cMode attribute set to "limbTracking".


contains the cMode attribute set to "idle".


Notes

3.38 SUBSYSTEM REQUIREMENTS – ACQUISITION

3.38.1 Requirement

“The TCS shall control the Acquisition Control System as defined in the TCS-to-ACS Interface

Control Document.

The TCS shall perform the following operations on the WCCS:




Select the output storage type of the acquisition camera(s);

Set the filter; and

Set the region of interest;”

3.38.2 Setup

3.38.3 Tests

Test AT4.4-0435-01





Test Steps 1) Submit a configuration with the attribute acs.mode="passive" and verify the

configuration is accepted. Verify the mode of the ACS is set to "passive".

2) Submit a configuration with the attribute acs.mode="active" and verify the

configuration is accepted. Verify the mode of the ACS is set to "active".

3) Submit a configuration with the attribute acs.mode="off" and verify the

configuration is accepted. Verify the mode of the ACS is set to "off".

Pass Criteria 1) The configuration is accepted and completes. The event atst.tcs.acs.cStatus


2) The configuration is accepted and completes. The event atst.tcs.acs.cStatus


3) The configuration is accepted and completes. The event atst.tcs.acs.cStatus

contains the mode attribute set to "off".


Notes

3.39 SUBSYSTEM REQUIREMENTS – POLARIMETRY ANALYSIS AND CALIBRATION

3.39.1 Requirement

“The TCS shall control the Polarimetry Analysis and Calibration System (PA&C) as defined in the

TCS-to-PA&C Interface Control Document. The TCS shall control the position of the various optical

elements in the PA&C.



The TCS shall send through the interface the current rate and start time of the ATST synchronization

system. These values are delivered to the TCS through the OCS-to-TCS interface and are used to

synchronize the PA&C spinning modulators with the cameras located in the instrument systems.

The TCS shall send through the interface a trajectory stream defining the position of the occulters

located at the Gregorian and prime foci.

The TCS shall perform the following operations on the PA&C:


Select the calibration mode for control by the WCCS;

Select the observing or calibration configuration;

Set the polarizer rotation rate and zero point; and

Send a trajectory stream for the occulter(s);”

3.39.2 Setup

3.39.3 Tests

Test AT4.4-0440-01





Test Steps 1) Submit a configuration with the attribute obsMode="active" and verify the

configuration is accepted. Verify the mode of the PAC is set to "active".

2) Submit a configuration with the attribute obsMode="off" and verify the

configuration is accepted. Verify the mode of the PAC is set to "off".

Pass Criteria 1) The configuration is accepted and completes. The event atst.tcs.pac.gos.status

contains the cMode attribute set to "active".

2) The configuration is accepted and completes. The event atst.tcs.pac.gos.status

contains the cMode attribute set to "off".


Notes

Test AT4.4-0440-02





Test Steps 1) Listen to the event “atst.tcs.pac.gosTrajectory” and verify it is posted by the

TCS at a rate of 20 Hz.

2) Look at the structure of the event and verify that it contains the values “tRef”,

“occulterCoeff”, “hprRadius”, “hprAngle”, “timestamp” and “trackId”.

Pass Criteria 1) The “atst.tcs.pac.gosTrajectory” event is posted at a rate of 20 Hz.

2) The event contains attributes as defined by the TCS to OCS ICD.

Script AT4-4-0440-02.py

Notes

3.40 PERFORMANCE REQUIREMENTS – ACCEPT OR REJECT A COMMAND IN 0.1 SECONDS

3.40.1 Requirement

“The TCS shall accept or reject a command given on its public interface within 0.1 seconds.”

3.40.2 Setup

3.40.3 Tests

Test AT4.4-0500-01



Test Steps 1) Submit a configuration to the TCS that will fail (issue a mode = undefined

attribute).

2) Record the time taken for the rejection message to be returned from the TCS.

3) Submit a configuration to the TCS that will be accepted (issue a mode = off

attribute).

4) Record the time taken for the accepted message to be returned from the TCS.

Pass Criteria 1) The time taken for the TCS to reject the first configuration is less than 0.1

seconds.

2) The response from the TCS verifies the first configuration has been rejected.



3) The time taken for the TCS to accept the second configuration is less than 0.1

seconds.

4) The response from the TCS verifies the second configuration has been accepted.


Notes

3.41 PERFORMANCE REQUIREMENTS – BOOT WITHIN 5 MINUTES

3.41.1 Requirement

“The TCS shall be operational and ready to receive and act upon commands within 5 minutes of a

cold, power-off start of its hardware.”

3.41.2 Setup

3.41.3 Tests

Test AT4.4-0505


Preconditions 1) The TCS machine is powered off.

Test Steps 1) Make a note of the start time.

2) Switch on power to the TCS machine.

3) Once the TCS machine has booted, login to the machine as the TCS user.

4) Open a terminal and start the ice services.

5) From the terminal start the JES application.

6) Open the TCS Engineering main screen.

7) From the TCS Engineering main screen deploy and start the containers TCS1

and TCS2.

8) Once the two containers are running, init and start the atst.tcs controller.

9) Make a note of the finish time.



Pass Criteria 1) The difference between the start time and the finish time is less than 5 minutes.

Script None

Notes

3.42 PERFORMANCE REQUIREMENTS – APPLY OFFSET INFORMATION WITHIN 0.1 SECONDS

“The TCS shall apply any external offsets or adjustments within 0.1 seconds. The offset information

may come from a hand paddle, guider, AO system, or instrument. The offset shall be applied to the

TCS pointing model.”

3.42.1 Setup

3.42.2 Tests

Test AT4.4-0510.





Test Steps 1) Enter and slew to a new target

2) Set the debug level to 1 for the "TIMER" category

3) Apply a target offset

4) Set the debug level to 0 for the "TIMER" category

Pass Criteria 1) Examine the log entries for the "TIMER" category and compute the time

difference between the entry "Offset received" and the entry "Offsets processed"

2) Check that the time difference is less than 0.1s


Start time:

Finish time:



Notes Currently the time elapsed between these two entries shows a large scatter up to about

0.3s. A more detailed look at the log messages shows that up to 0.27s can elapse

between the calls to doSubmit and doCanRun. This indicates that most of the delay is

outside the control of the TCS. This needs to be further verified.

3.43 INTERFACE REQUIREMENTS – SEQUENCING

3.43.1 Requirement

“The TCS shall be responsible for maintaining any sequence or order of command execution for

commands sent by the principal systems. Commands from the OCS shall be executed in the order

they are received or, if given with associated start times, in the order of the start times. All valid

commands shall be queued by the TCS for execution.”

3.43.2 Setup

3.43.3 Tests

Test AT4.4-0630-01





3) Ensure the TCS, MCS and ECS are in the “off” mode.

Test Steps 1) Set the debug level of the TCS, MCS and ECS to 2.

2) Record the start time of the test.

3) Submit a configuration with a start time of 5 minutes into the future to the TCS

with the attribute mode = tracking.

4) Wait for 1 minute.

5) Submit a configuration with a start time of 2 minutes into the future to the TCS

with the attribute mode = off.

6) Wait for 1 minute.

7) Submit a configuration for instant execution to the TCS with the attribute mode

= active.



8) Throughout the test monitor the mode of the TCS, MCS and ECS.

Pass Criteria 1) The order of submission was tracking, off, active.

2) The mode of the TCS changed from off to active, back to off and then finally to

tracking, verifying that the two initial configurations were in fact not executed

until the scheduled time.

3) The mode of the MCS and ECS followed that of the TCS, verifying that when

the scheduled configurations were executed the TCS correctly submitted

additional configurations to the subsystems.


Notes

3.44 INTERFACE REQUIREMENTS – HEALTH

3.44.1 Requirement

“The TCS shall broadcast its health on a regular basis. The TCS shall use the CSF health mechanism

defined in SPEC-0022-1.”

3.44.2 Setup

3.44.3 Tests

Test AT4.4-0635


Preconditions

Test Steps 1) See tests AT4-4-0007-01 and AT4-4-0310-01

Pass Criteria

Script AT4-4-0007-01_TAF.py, AT4-4-0310-01_TAF.py



Notes

3.45 INTERFACE REQUIREMENTS – ALARMS

3.45.1 Requirement

“The TCS shall generate alarms for any errors or problems it detects that require operator notification

or intervention. Alarms shall be generated for loss of control or contact with its subsystems, entry

into the zenith blind spot or any mechanism end-of-travel.”

3.45.2 Setup

3.45.3 Tests

Test AT4.4-0640-01





Test Steps 1) Open the EventView application and subscribe to the “__alarm” event.

2) Select a target for the TCS that will track through the zenith blind spot and turn

on tracking.

3) Wait for the target to track through the zenith blind spot.

4) Turn off tracking.

5) Shutdown, un-initialize and unload each of the simulators in turn.

Pass Criteria 1) As the TCS tracks into the zenith blind spot and alarm is raised to notify that

this has occurred. The alarm appears on the EventView application.

2) As each of the simulators is unloaded the TCS will raise an alarm to notify that

the connection has been lost, and another to notify that the connection cannot be

re-established. Each of these alarms appears on the EventView application.




Notes

3.46 INTERFACE REQUIREMENTS – CONTROL OF TELESCOPE MOTION

3.46.1 Requirement

“The TCS shall provide an interface to allow other principal systems to adjust the position of the

telescope. This adjustment may be in the form of an offset, track rate change, or predefined motion

pattern (scan, box, etc.).”

3.46.2 Setup

3.46.3 Tests

Test AT4.4-0645-01





Test Steps 1) Slew and track a target

2) Apply a simple offset

3) Clear the offset and apply a differential track rate

4) Resend the target demand

Pass Criteria 1) Confirm that the offset is applied at step 2

2) Confirm that at step 3 the offset is cleared and the TCS demand coordinates

increase in line with the applied differential track rates

3) Confirm that at step 4 the original target is tracked and the differential track

rates are cleared




Notes For the scanning part of this requirement see AT4-4-0145-01, AT4-4-0145-02 and AT4-

4-0145-03

3.47 INTERFACE REQUIREMENTS – TELESCOPE INFORMATION

3.47.1 Requirement

“The TCS shall provide an interface to publish all appropriate telescope status information (i.e.,

position, rate, time, state, etc.). Appropriate information shall include all status, log, and alarm events

specified by all interface control documents to the TCS.”

3.47.2 Setup

3.47.3 Tests

Test AT4.4-0650-01






2) Subscribe to the “atst.tcs.cStatus” event.

Pass Criteria 1) A new event is received at a rate of 1 Hz.

2) The data contained within the event matches the format as specified in the

document ICD 4.2-4.4 OCS to TCS, section 4.5.1.


Notes

Test AT4.4-0650-02








2) Subscribe to the “atst.tcs.cPos” event.





Notes

Test AT4.4-0650-03






2) Subscribe to the “atst.tcs.timesToLimits” event.





Notes



3.48 INTERFACE REQUIREMENTS – OCS INTERFACE

3.48.1 Requirement

“The TCS shall obey the OCS-to-TCS interface defined by both principal systems. This interface is

to be written by AURA with input from the TCS contractor.”

3.48.2 Setup

3.48.3 Tests

Test AT4.4-0655-01





3) Ensure that horizon checking is turned off on the TCS.

Test Steps 1) Create a configuration that contains the following attributes. Ensure the

attributes have valid values as defined in the document ICD 4.2-4.4 OCS to

TCS, section 4.4.2:

atst.tcs.frame

atst.tcs.target

atst.tcs.targetName

atst.tcs.equinox

atst.tcs.properMotion

atst.tcs.epoch

atst.tcs.parallax

atst.tcs.rv

atst.tcs.wavelength

2) Submit the configuration to the atst.tcs controller.

Pass Criteria 1) The configuration is accepted by the TCS (atst.tcs controller).

2) The TCS target demand position is updated to reflect the attributes submitted in

the configuration.


Notes

Test AT4.4-0655-02









TCS, section 4.4.2:

atst.tcs.targetOffset

atst.tcs.targetOffsetType

atst.tcs.targetOffsetIndex




the configuration.


Notes

Test AT4.4-0655-03







TCS, section 4.4.2:

atst.tcs.absorbTargetOffsets






the configuration.


Notes

Test AT4.4-0655-04





3) Ensure some offsets have been applied to the current target prior to this test.



TCS, section 4.4.2:

atst.tcs.clearTargetOffsets

atst.tcs.clearTargetOffsets



2) The TCS target offset is cleared and the demand position is updated to reflect

the attributes submitted in the configuration.


Notes

Test AT4.4-0655-05







3) Ensure the TCS is tracking a valid (non-solar) target.



TCS, section 4.4.2:

atst.tcs.trackRate

atst.tcs.trackRateT0




the configuration (a differential track rate is introduced).


Notes

Test AT4.4-0655-06





3) Ensure the TCS is tracking a valid solar target in a heliographic coordinate

frame.



TCS, section 4.4.2:

atst.tcs.solarDiffRotate

atst.tcs.solarDiffRotParams




the configuration (a solar heliographic differential track rate is introduced).




Notes

Test AT4.4-0655-07





3) Ensure the TCS is tracking a valid solar target.



TCS, section 4.4.2:

atst.tcs.ecsTargetName



2) The ECS target demand stream is updated to reflect the attributes submitted in

the configuration.


Notes

Test AT4.4-0655-08





3) Ensure the TCS is tracking a valid solar target.



4) Ensure the ECS is not locked to the MCS position.



TCS, section 4.4.2:

atst.tcs.ecsTarget


Pass Criteria 1) The configuration is accepted by the TCS (atst.tcs.controller).

2) The ECS tracks the new ECS target, it does not follow the same demand stream

as the MCS.


Notes

Test AT4.4-0655-09





3) Ensure the TCS is tracking a valid target.



TCS, section 4.4.2:

atst.tcs.instOrigin


Pass Criteria 1) The configuration is accepted by the TCS.

2) The instrument pointing origin is updated to reflect the values submitted within

the configuration.




Notes

Test AT4.4-0655-10








TCS, section 4.4.2:

atst.tcs.instOriginOffsetIndex

atst.tcs.instOriginOffset



2) The instrument pointing origin offset is updated to reflect the values submitted

within the configuration.


Notes

Test AT4.4-0655-11








4) Ensure an instrument pointing origin offset has been added.



TCS, section 4.4.2:

atst.tcs.absorbInstOrigin



2) The instrument pointing origin offset is absorbed into the instrument pointing

origin base position.


Notes

Test AT4.4-0655-12






4) Ensure an instrument pointing origin offset has been added.



TCS, section 4.4.2:

atst.tcs.clearInstOrigin



2) The instrument pointing origin offset is cleared.




Notes

Test AT4.4-0655-13








TCS, section 4.4.2:

atst.tcs.ipa

atst.tcs.ipaFrame



2) The instrument position angle is updated to reflect the values submitted within

the configuration.


Notes

Test AT4.4-0655-14










TCS, section 4.4.2:

atst.tcs.iaa



2) The instrument alignment angle is updated to reflect the values submitted within

the configuration.


Notes

Test AT4.4-0655-15







TCS, section 4.4.2:

atst.tcs.horizonChecking



2) Horizon checking is turned on or off reflecting the value submitted within the

configuration.


Notes



Test AT4.4-0655-16







TCS, section 4.4.2:

atst.tcs.wrap



2) The azimuth axis is wrapped or unwrapped (if mechanically possible) according

to the value submitted within the configuration.


Notes

Test AT4.4-0655-17




3) Ensure the TCS is tracking a solar target in a cartesian helioprojective frame.



TCS, section 4.4.4:

atst.tcs.scanType

atst.tcs.scanParms



2) The chosen scan is started (or stopped). The parameters of the scan are set



reflecting the values submitted within the configuration.


Notes

Test AT4.4-0655-18







TCS, section 4.4.5:

atst.tcs.iersUpdate



2) The IERS controller updates its parameters by connecting to the external

website and downloading the required information.


Notes

Test AT4.4-0655-19









TCS, section 4.4.5:

atst.tcs.wsMode

atst.tcs.wsTemperature

atst.tcs.wsPressure

atst.tcs.wsHumidity



2) The weather controller’s mode is updated to that supplied in the submitted

configuration and if set to “manual” mode then the weather data values are set to

those contained within the submitted configuration.


Notes

3.48.4 Requirement

“The TCS shall respond to a global interlock signal by placing itself and its subsystems in a safe

state. The safe state shall prevent the TCS from moving any mechanisms or equipment while the

interlock condition exists. The TCS shall reject commands while the global interlock signal is active”

3.48.5 Setup

3.48.6 Tests

Test AT4.4-1300-01





Test Steps 1) Set a target and track it

2) Issue a global interlock

3) Issue a command to offset the telescope

4) Clear the global interlock

5) Issue a configuration to restart tracking



Pass Criteria 1) At step 2 confirm that both the TMA and ECS switch to mode = off

2) Confirm that the offset command is rejected

3) At step 5 after the interlock is cleared confirm that the TCS re-accepts

command s and starts tracking as requested.


Notes

4. COMPLIANCE MATRIX

The compliance matrix for the TCS is now provided in a separate document (Ref [4]).

telescope control system software test plan · telescope control system software test plan alan...

Documents