615 Epsilon Drive, Pittsburgh, PA, USA 15238 Phone: 412.967.7700 Fax: 412.967.7973 www.L-3Com.com/IOS L-3 COMMUNICATIONS –IOS PROPRIETARY L3 Communications, IOS reserves all rights in connection with this document and in the subject matter represented therein. The recipient hereby acknowledges these rights and shall not, without permission in writing, disclose or divulge this document in whole or in part to third parties or use it for any purpose other than that for which it was delivered to recipient. WARNING: This technical data is controlled under the Export Administration Regulations (EAR) and may not be exported to a Foreign Person, either in the U.S. or abroad, without proper authorization by the U.S. Department of Commerce. DESTRUCTION NOTICE: Destroy by any method that will prevent disclosure of contents or reconstruction. Registered by NQA to ISO 9001:2008 ATPr-32610 Initial Issue ATST TEOA Control System ACCEPTANCE TEST PROCEDURE Part No (s). 302028 Serial Number: Rev B (v1.0.0) Contract # ________________ Customer: AURA November 2014 Approval Name Signature Date Responsible Systems Engineer: Sandra Bader Reviewer: Michael Bock Project Engineer: Steve Mix Quality Assurance: Sue Franciscus Program Manager: Craig Peton
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
615 Epsilon Drive, Pittsburgh, PA, USA 15238
Phone: 412.967.7700 Fax: 412.967.7973
www.L-3Com.com/IOS
L-3 COMMUNICATIONS –IOS PROPRIETARY
L3 Communications, IOS reserves all rights in connection with this document and in the subject matter represented therein. The recipient
hereby acknowledges these rights and shall not, without permission in writing, disclose or divulge this document in whole or in part to third
parties or use it for any purpose other than that for which it was delivered to recipient.
WARNING: This technical data is controlled under the Export Administration Regulations (EAR) and may not be exported to a Foreign
Person, either in the U.S. or abroad, without proper authorization by the U.S. Department of Commerce.
DESTRUCTION NOTICE: Destroy by any method that will prevent disclosure of contents or reconstruction.
Registered by NQA to ISO 9001:2008
ATPr-32610 Initial Issue
ATST TEOA
Control System
ACCEPTANCE TEST PROCEDURE Part No (s). 302028
Serial Number: Rev B (v1.0.0)
Contract # ________________
Customer: AURA
November 2014
Approval Name Signature Date
Responsible Systems Engineer: Sandra Bader
Reviewer: Michael Bock
Project Engineer: Steve Mix
Quality Assurance: Sue Franciscus
Program Manager: Craig Peton
615 Epsilon Drive, Pittsburgh, PA, USA 15238
Phone: 412.967.7700 Fax: 412.967.7973
www.L-3Com.com/IOS
L-3 COMMUNICATIONS –IOS PROPRIETARY
L3 Communications, IOS reserves all rights in connection with this document and in the subject matter represented therein. The recipient
hereby acknowledges these rights and shall not, without permission in writing, disclose or divulge this document in whole or in part to third
parties or use it for any purpose other than that for which it was delivered to recipient.
WARNING: This technical data is controlled under the Export Administration Regulations (EAR) and may not be exported to a Foreign
Person, either in the U.S. or abroad, without proper authorization by the U.S. Department of Commerce.
DESTRUCTION NOTICE: Destroy by any method that will prevent disclosure of contents or reconstruction.
Registered by NQA to ISO 9001:2008
Revision Description Date Name Initials
--- TEOACS related requirements
testing
10/8/14 Michael Bock MB
ATPR-32610 TEOACS Test Procedure
This page is subject to the disclosure and distribution restrictions on the cover page.
3
Include a summary of the test results, conclusions, and recommendations. Comments
in this section should be limited to explanations or rationale as to why the TEOA has
not passed ATP and notes that do not directly address unusual anomalies that would
This page is subject to the disclosure and distribution restrictions on the cover page.
14
4.1.1 Engineering User Interface
Requirement 1.3.3-0310
The TEOA shall supply an engineering user interface that implements all functional operations of the TEOA as defined by the interfaces to the TCS and
WCCS (ICD-1.3/4.4 and ICD-1.3/2.3) and shall be useful for actual operations within the ATST. The engineering user interface shall reside on a separate
computer from the TEOACS and use the Common Services Framework to communicate with the TEOACS.
Requirement 1.3.3-0315
The TEOACS shall use Coordinated Universal Time (UTC) in all displays and status.
Verification Procedure:
This test shows that the Engineering user interface is present and functional by issuing some basic commands. It also demonstrates that the
TEOACS uses UTC time in all displays and status. Note that this test only demonstrates compliance with a portion of 1.3.3-0310. A more
rigorous test on the Engineering User Interface is done as part of section 4.2.19. The client and server machines are off network and therefore
have no NTP server connected. Therefore, the UTC time will only be approximate.
Figure 4.1-1 Load Table button
ATPR-32610 TEOACS Test Procedure
This page is subject to the disclosure and distribution restrictions on the cover page.
15
Step Action System Response
1. If the system is not up and running, start up the system using the
startup procedure located in section Appendix B.1.
TEOACS computers start up.
2. Reset the System Configuration per the system reset script . System Reet Configuration.
3. Navigate to the ‘M2 Hexapod’ tab on the TEOACS Engineering
GUI.
NONE
4. Click the ‘Load Table’ button underneath the ‘Clear’ button
(see Figure 4.1-1).
A dialog box titled ‘Open’ is presented to the user.
5. Choose the ‘EngGui411’ table file from the $TSCREENS
directory.
GUI displays the contents of the ‘EngGui411’ configuration inside the
configuration widget on the M2 Hexapod tab.
6. Observe the time and date on the engineering GUI. Time and date are formatted in the following manner:
‘YYYY-MM-DD hh:mm:ss GMT’.
7. Verify that the time agrees within a few minutes of current UTC
time. Use an agreed upon means for verification (for instance
using htttp://time.is/UTC)
N/A
8. Satisfies restart requirement 1.3.3-0020. No system restart should have resulted from executing this test.
This page is subject to the disclosure and distribution restrictions on the cover page.
16
4.1.2 Lyot Stop Positioning
Requirement 1.3.2.6-0020
The Lyot Stop shall be remotely deployable into position, corresponding to the position of the pupil in M2 space, controlled by the TEOACS on command
of the TCS.
Requirement 1.3.3.3-0220
The TEOACS shall move the Lyot stop between its defined positions. The motion shall be at the command of the TCS or the engineering user interface. The
TEOACS shall monitor the deployment of the Lyot stop and report any changes in status.
Verification Procedure:
This test shows that the lyot stop is able to move and when moved all of its position indicators are consistent. Restart the Testharness tool
(see section 3.7 for default listener discussion).
Step Action System Response
1. Reset the System Configuration per the system reset script. System Reset Configuration.
2. Using the TEOACS Engineering GUI navigate to the “Lyot
Stop” tab.
The GUI displays the “Lyot Stop” tab.
3. Toggle power off using the TEOACS Engineering GUI
configuration called ‘lyotPowerOff’ (located in $TSCREENS)
as accessed via the configuration widget on the Lyot Stop tab.
The Lyot stop software controller transitions from the power ‘on’ state to the
power ‘off’ state.
4. Run the ‘listenLyotStatus.th’ Testharness script. The Testharness application begins to display the atst.tcs.teoacs.lyot.cStatus
event.
5. Select the load table button on the configuration widget and
choose the “lyotPowerOn” file from the $TSCREENS directory
(see Table 3.6-1). Click the “Open” button on the dialog and
then click “Submit” on theconfiguration widget.
The lyot stop software controller issues the appropriate hardware specific
messages related to the ‘power’ attribute. The ‘Current Power’ indicator on the
screen will change from ‘off’ to ‘on’. The ‘Current Position’ indicator will
transition from ‘out’ to ‘in_transit’ and then back to ‘out’. The lyot stop should
NOT move.
6. Verify that all indicators of lyot stop position monitored via the
‘listenLyotStatus.th’ script and the GUI (including the pressure
sensor information) are consistent with the ‘out’ position and
power ‘on’ condition..
The status observed in the Testharness window shows data consistent with the
’out’ position and power ‘on’ condition for all indicators.
ATPR-32610 TEOACS Test Procedure
This page is subject to the disclosure and distribution restrictions on the cover page.
17
Step Action System Response
7. From the ‘Lyot Stop’ tab on the TEOACS Engineering GUI
select the load table button on the configuration widget and
choose the “lyotConfigPwr_on_Pos_in” file from the
$TSCREENS directory. Click the “Open” button on the dialog
and then click “Submit” on the configuration widget.
The ‘Current Position’ indicator will transition from ‘out’ to ‘in_transit’ and
then to ‘in’’. The lyot stop should move.
8. Verify that all indicators of lyot stop position monitored via the
‘listenLyotStatus.th’ script and the GUI (including the pressure
sensor information) are consistent with the ‘in’ position.
The status observed in the Testharness window shows data consistent with the
‘in’ position and power ‘on’ condition for all indicators.
9. Quiet the default listener with the ‘deflis – q’ command. The Testharness application stops displaying the atst.tcs.teoacs.lyot.cStatus
event.
10. Satisfies restart requirement 1.3.3-0020. No system restart should have resulted from executing this test.
This page is subject to the disclosure and distribution restrictions on the cover page.
18
4.1.3 Default State and Global Interlock
Requirement 1.3.3-0015
The TEOACS shall have a defined default state for all TEOA hardware and equipment that it controls. Equipment shall be in this state during an interlock
condition, after power-up and software initialization, or when demanded through the software interface. The default state of any TEOA equipment shall be
an inert, non-moving, non-powered condition.
Requirement 1.3.3-0320
The TEOACS shall detect and respond to a global interlock signal. Upon receiving the GIS signal the TEOACS shall stop all ongoing actions in the
TEOA, reject all queued and incoming configurations, disable all controlled mechanisms, and move to the defined default state.
The TEOACS shall not be required participate in any safety-critical operations to ensure the safety of the equipment or personnel. All safety-related
activities shall be the sole responsibility of the GIS.
Verification Procedure:
This test verifies the default state for the software can be achieved by the three different means shown in the requirement. Note: none of the
‘power’ attributes associated with the TEOACS controllers correspond to real power to the equipment since hardware for toggling power is
not available to the TEOACS. Therefore, the ‘power’attributes have been mapped to software enables instead. The default state is defined as
the following:
TEOA Manager:
AO Mode is OFF
Hexapod and FTT:
Mode and AO Mode is OFF
State is “parked”.
Power is “off”
ATPR-32610 TEOACS Test Procedure
This page is subject to the disclosure and distribution restrictions on the cover page.
19
FTT only
LimbTracking Mode is OFF
Lyot Stop:
State is “off”
Power is “off”
This test will use a combination of the engineering gui and test scripts. This test will cover all three ways of entering the default state. That is
either by an interlock condition, startup of the software or through a submission of aoMode of OFF. The L-3 event simulator will be used to
generate the interlock condition.
Step Action System Response
1. Reset the System Configuration per the system reset script. System Reset Configuration.
2. Verify that the AO mode to PASSIVE . TEOACS reports AO Mode ‘passive’ via ‘Mode’ drop down selector in lower
right of GUI screen, the ‘Ao Mode M2Pos’ field on the ‘M2 Hexapod’ tab of
the GUI screen and the ‘Ao Mode M2TT’ field on the ‘M2FTT’ tab of the GUI
screen
3. Assert an interlock condition in the TEOACS by using the
“raiseInterlock.th” script.
All TEOACS controllers show an interlock condition. Interlock related health
status should be reported by all controllers on the bash shell and the GUI.
4. Verify all sub-controllers have reached the defined Default state
by using the ‘showM2.th’, ‘showMC.th’, ‘showMT.th’ and
‘showLyotStop.th’ scripts.
Output is displayed on the screen corresponding to each script.
5. Compare the output from the scripts that show up on the screen
to the defined default states shown in the Overview section of
this test (before this table).
NONE.
6. Send a configuration down to each sub controller and verify that
the configuration is rejected by the TEOACS.
All TEOACS sub controllersrejects the incoming configuration while
interlocked.
7. Lift the interlock condition from the TEOACS by using the
“lowerInterlock.th” test script.
All TEOACS controllers leave the interlocked condition. Interlock related
health status
8. Repeat steps 2 – 7 except for step 2 choose AO mode ACTIVE
instead of PASSIVE.
System response same as steps 2 – 6 with the exception that the TEOACS will
report AO Mode ‘active’ for step 2.
ATPR-32610 TEOACS Test Procedure
This page is subject to the disclosure and distribution restrictions on the cover page.
20
Step Action System Response
9. Repeat steps 2 – 7 except for step 2 choose AO mode PASSIVE
and have an active and long running configuration being
processed when starting step 3 with a queued configuration
ready just behind it..
The TEOACS rejects the queued configuration while interlocked.
10. Shutdown the TEOACS by following the shutdown only
instructions in Appendix B.2 TEOACS Manual Restart
Procedure. Turn off both CSF client and server. Note: the test
operator can use an ssh window from the CSF server to
accomplish this.
The TEOACS controllers transition through the lifecycle states to finally reach
the “unloaded” state. Note: when using Canary 7-2 release of the CSF the the
container manager will hang when issuing a ContainerManger start or stop
command.
11. Once shut down wait 10 seconds and then restart both CSF
client (‘teoaClient’ and server) and log in.
The CSF client ‘teoaClient’ and CSF server ‘dunn’ goes through the boot up
process. Login credentials are supplied to each machine to start them.
12. Restart the TEOACS software (should be automatic at startup
save for any startup bugs that may be present in CSF) and
launch Testharness (see Appendix B.1 TEOACS startup
procedure) for more details. Ensure that all teoacs sub-
controllers enter the defined default state.
The TEOACS software is restarted and lifecycle state ‘Loaded’ is achieved.
Upon launch of ‘Testharness’ the TEOACS controllers should achive Lifecycle
state ‘running’ with each controller in the defined default state.
13. Verify all sub-controllers have reached the defined Default state
by using the ‘showM2.th’, ‘showMC.th’, ‘showMT.th’ and
‘showLyotStop.th’ scripts.
Output is displayed on the screen corresponding to each script.
14. Compare the output from the scripts that show up on the screen
to the defined default states shown in the Overview section of
this test (before this table).
NONE
15. Reset the System Configuration per the system reset script. System shows Reset Configuration (see section 3.4).
16. Verify that the AO mode to PASSIVE . TEOACS reports AO Mode ‘passive’ via ‘Mode’ drop down selector in lower
right of GUI screen, the ‘Ao Mode M2Pos’ field on the ‘M2 Hexapod’ tab of
the GUI screen and the ‘Ao Mode M2TT’ field on the ‘M2FTT’ tab of the GUI
screen
17. Set the AO mode to OFF by using the ‘Mode’ drop down
selector and choosing the ‘off’ option.
TEOACS reports AO Mode ‘off’. All TEOACS controllers achieve the Default
state.
18. Verify all sub-controllers have reached the defined Default state
by using the ‘showM2.th’, ‘showMC.th’, and ‘showMT.th’
scripts.
Output is displayed on the screen corresponding to each script. The lyot stop
does not have behavior linked to ao Mode therefore lyot stop may not be in the
default state.
ATPR-32610 TEOACS Test Procedure
This page is subject to the disclosure and distribution restrictions on the cover page.
21
Step Action System Response
19. Compare the output from the scripts that show up on the screen
to the defined default states shown in the Overview section of
this test (before this table).
NONE.
20. Satisfies restart requirement 1.3.3-0020. TEOACS controllers were only shut down on command during this procedure.
Shutdown and/or start up was successful (save the ContainerManager hanging
This page is subject to the disclosure and distribution restrictions on the cover page.
23
4.1.5 Health
Requirement 1.3.3-0025
The TEOACS shall be able to determine whether the current state of the TEOA is within operational specifications. The TEOACS shall have defined health
categories that are tied to the ATST Health Service. These health categories shall be checked at regular intervals that will be determined based on the
overall needs of the system. The TEAOCS shall test that all equipment is operating within specification as required by the current conditions and state of
the TEOA. The TEOACS shall report with specificity any problems with its equipment and systems that cause degraded performance or non-performance.
Requirement 1.3.3-0205
It shall report and log errors and faults when operational performance is not achieved.
Verification Procedure:
Verify the TEOACS health system is active and working as designed by using a combination of test scripts, engineering GUI and real faults.
1. Use the ‘injectFault_m2pos.th’ script to inject a fault into the m2pos controller.
2. Observe on the engineering GUI or test log the health status changing for the m2pos controller.
3. Use the ‘showFaultTable_m2pos.th’ script to show the entire fault table for the m2pos controller. Observe fault information showing
up in the log.
4. Use the ‘showFault_m2pos.th’ script to show the fault status for the particular fault injected.
5. Use the ‘healTestFault_m2pos.th’ script to heal the injected fault.
6. Repeat the steps above with scripts named *_m2tt.th, *_lyot.th and *_mc.
7. Demonstrate the communications down health category for all controllers for real by pulling the associated Ethernet cable for each of
the three sub-controllers (m2pos, lyot and m2tt). Note: a restart may be required after this step as m2pos and m2tt controllers only
have a limited amount of time where they can recover from a comms down fault.
_____________________ Pass/Fail
ATPR-32610 TEOACS Test Procedure
This page is subject to the disclosure and distribution restrictions on the cover page.
This page is subject to the disclosure and distribution restrictions on the cover page.
27
4.1.8 Data Persistence
Requirement 1.3.3-0040
Static information required by the TEOACS to operate shall be recoverable after a restart or reboot. This information may include, but is not limited to:
zero points, lookup tables, and configuration parameters. Dynamic information, such as current position and state, may be reset or recovered after
initialization. Static information shall be stored through the ATST Property Service or parameter set database.
Verification Procedure:
Verify the data persistence requirement above by using the procedure below which involves a shutdown/restart cyle of the teoacs.
1. View the existing log in an editor of your choice and observe the very start of the log where the system was initially started. In that
area of the log is a list of properties for each controller as they are during startup.
2. Copy the section of interest with the properties under review to a temporary file.
3. Cause the m2pos controller to move and change it’s position.
4. Restart the TEOACS system and observe the startup area in the log after loading the new log in the editor of your choice.
5. Go to passive mode by selecting ‘passive’ from the combo box in the lower right hand corner of the GUI labled ‘Mode’ and verify the
teoacs goes to the last position recorded prior to shutdown.
This page is subject to the disclosure and distribution restrictions on the cover page.
28
4.1.9 Diagnostic Features
Requirement 1.3.3-0045
The TEOACS and TEOA-TMS shall monitor all aspects of the TEOA to ensure proper operation. In the event of a system malfunction, the TEOACS and
TEOA-TMS shall provide sufficient information to allow the telescope operator to diagnose the problem. The TEOACS and TEOA-TMS shall have
diagnostic instrumentation to include but not be limited to the following:
• Safety – Any problem with the Heat Stop Assembly that could in any way threaten the security or safety of the telescope or personnel shall be provided by a fail-safe communications link
to the GIS.
• Health – The functions of the Heat Stop Assembly shall be monitored during telescope operation by the TEOA-TMS and any malfunction communicated to the FMS. This shall include
output of thermal sensors and operation of any heat exchangers.
• Status – TEOA CS system status information pertinent to the scientific observations related to the TEOACS shall be recorded as defined by the ATST Header service. This information
shall include the M2 Mirror position as reported by the hexapod controller. However, TEOA thermal information such as ambient air-to-M2 Mirror optical surface temperature difference
gathered by the TEOA-TMS and shall be sent to FMS according to TEOA to FMS ICD.
Verification Procedure:
Verify the Diagnostic features as pertaining to the TEOACS with the procedure below. The health and safety portion of the requirement
above is covered in another ATP.
1. Verify that the M2 mirror positions are available via a “get operation” which is used in conjunction with the ATST header service.
The TEOACS engineering GUI uses “get” operations for displaying these data items. This is done via the ‘headerGet.th’ script.
2. Go into edit mode on the TEOA engineering GUI and show the linkage of the m2 position data items to the m2pos csf controller. This
linkage should reveal those relevant GUI elements to be doing a “get” operation at a specified frequency.
This section describes those attributes that the TCS will send to the top-level controller that involve the M2 positioner controller (atst.tcs.teoacs.m2pos).
Verification Procedure:
This test shows the TEOACS m2 positioner controller software contains the required attributes specified by ICD 1.3-4.4 by viewing those
attributes in the property database and displaying those attributes in the currently active log.
Step Action System Response
1. Open the PropertyEditor tool on the CSF server ATST PropertyEditor opens.
2. Compare the table seen in section 4.9 in ICD 1.3-4.4 to the
attributes for the controller called ‘atst.tcs.teoacs.m2pos’.
Ensure the attributes seen in the PropertyEditor window contain
the attributes listed in section 4.9 (Note: attributes seen in the
PropertyEditor should contain at least those listed in ICD but
may contain more).
NONE
3. Ensure that the TEOACS software is in Lifecycle state running.
If the TEOACS needs to be restarted do so at this time.
Lifecycle state = RUNNING
4. Run the “showM2Att.th” Testharness script The TEOACS logs all the properties for this controller to the active log file.
5. Review the currently active log for those attributes in section
4.9 of ICD 1.3-4.4. Ensure the attributes logged contain the
attributes listed in section 4.9.
NONE
ATPR-32610 TEOACS Test Procedure
This page is subject to the disclosure and distribution restrictions on the cover page.
31
Step Action System Response
6. Satisfies restart requirement 1.3.3-0020. No restart was necessary beyond a restart that may have been necessary due to
This section describes those attributes that the TCS will send to the top-level controller that involve the M2 tip-tilt controller (atst.tcs.teoacs.m2tt). The
attributes that can be set on this controller are given in the table below and the table in section 4.9 (note this controller has the M2 positioner attributes as
a subset of it’s own).
Verification Procedure:
This test shows the TEOACS m2 tip-tilt controller software contains the required attributes specified by ICD 1.3-4.4 by viewing those
attributes in the property database and displaying those attributes in the currently active log.
Step Action System Response
1. Open the PropertyEditor tool on the CSF server ATST PropertyEditor opens.
2. Compare tables seen in section 4.9 and 4.10 in ICD 1.3-4.4 to
the attributes for the controller called ‘atst.tcs.teoacs.m2tt’.
Ensure the attributes seen in the PropertyEditor window contain
the attributes listed in sections 4.9 and 4.10.
NONE
3. Ensure that the TEOACS software is in Lifecycle state running.
If the TEOACS needs to be restarted do so at this time.
Lifecycle state = RUNNING
4. Run the “showMTAtt.th” Testharness script The TEOACS logs all the properties for this controller to the active log file.
ATPR-32610 TEOACS Test Procedure
This page is subject to the disclosure and distribution restrictions on the cover page.
32
Step Action System Response
5. Review the currently active log for those attributes in sections
4.9 and 4.10 of ICD 1.3-4.4. Ensure the attributes logged
contain the attributes listed in sections 4.9 and 4.10.
NONE
6. Satisfies restart requirement 1.3.3-0020. No restart was necessary beyond a restart that may have been necessary due to
This section describes those attributes that the TCS will send to the top-level controller that involve the Lyot stop controller (atst.tcs.teoacs.lyot).
Verification Procedure:
This test shows the TEOACS lyot stop controller software contains the required attributes specified by ICD 1.3-4.4 by viewing those
attributes in the property database and displaying those attributes in the currently active log.
Step Action System Response
1. Open the PropertyEditor tool on the CSF server ATST PropertyEditor opens.
2. Compare the table in section 4.11 in ICD 1.3-4.4 to the
attributes for the controller called ‘atst.tcs.teoacs.lyot’. Ensure
the attributes seen in the PropertyEditor window contain the
attributes listed in section 4.11.
NONE
3. Ensure that the TEOACS software is in Lifecycle state running.
If the TEOACS needs to be restarted do so at this time.
Lifecycle state = RUNNING
ATPR-32610 TEOACS Test Procedure
This page is subject to the disclosure and distribution restrictions on the cover page.
33
Step Action System Response
4. Run the “showLyotAtt.th” Testharness script The TEOACS logs all the properties for this controller to the active log file.
5. Review the currently active log for those attributes section 4.11
of ICD 1.3-4.4. Ensure the attributes logged contain the
attributes listed in section 4.11.
NONE
6. Satisfies restart requirement 1.3.3-0020. No restart was necessary beyond a restart that may have been necessary due to
The TEOACS shall monitor the position of the M2 mirror in all six axes to within the specified tolerance. It shall report those positional values in a timely
manner through its event system. It shall monitor and report all aspects of M2 positioning operation, including, but not limited to, limit switches, and
power.
ICD Paragraph # 4.12.2
This event reports the current status of the M2 position controller. The event is generated at a rate of 1 Hz and includes all listed attributes. The generated
rate may be adjusted with the atst.tcs.teoacs.m2pos.statusRate attribute.
Verification Procedure:
This test will show that the m2 positioner event will have the required attributes from the ICD and is transmitted at the required rate. The
PropertyEditor will be used to compare the 1/post:interval value for this controller to the rate in the table in section 4.12 of ICD 1.3-4.4. A
test script named ‘listen_m2pos.th’ will activate a listening function for the event in question. A few event messages will print to the screen
and then the listening function will cease. Then the test conductor will compare attributes from the ICD to the printed messages on the
screen. The time between messages will be determined from the printout to verify rate. Subsequently, an action will take place that will
cause portions of the event data to change. The listening function will be repeated and the test conductor will demonstrate that the content of
the event has changed in a meaningful way.
ATPR-32610 TEOACS Test Procedure
This page is subject to the disclosure and distribution restrictions on the cover page.
The TEOACS shall control the M2 position in fast tip and tilt. It shall operate the M2 fast tip-tilt system within the required performance specifications of
that component.
The TEOACS shall monitor the position of the M2 fast tip-tilt system in both axes to within the specified tolerance. It shall report those positional values in
a timely manner through its event system. It shall monitor and report all aspects of M2 tip-tilt operation, including, but not limited to, limit switches,
power, and actuator voltages and currents. It shall report and log errors and faults when operational performance is not achieved.
ICD Paragraph # 4.12.3
This event reports the current status of the M2 tip-tilt controller. The event is generated at a rate of 1 Hz and includes all listed attributes for the M2
positioner event table and the table below.
Verification Procedure:
Note: we cannot monitor actuator voltages and currents of the M2 Tip-tilt. Awaiting wording change on this specification.
This test will show that the m2tt event will have the required attributes from the ICD and is transmitted at the required rate. The
PropertyEditor will be used to compare the 1/post:interval value for this controller to the rate in the table in section 4.12 of ICD 1.3-4.4. A
test script named ‘listen_m2tt.th’ will activate a listening function for the event in question. A few event messages will print to the screen and
ATPR-32610 TEOACS Test Procedure
This page is subject to the disclosure and distribution restrictions on the cover page.
36
then the listening function will cease. Then the test conductor will compare attributes from the ICD to the printed messages on the screen.
The time between messages will be determined from the printout to verify rate. Subsequently, an action will take place that will cause
portions of the event data to change. The listening function will be repeated and the test conductor will demonstrate that the content of the
The TEOACS shall move the Lyot stop between its defined positions. The motion shall be at the command of the TCS or the engineering user interface. The
TEOACS shall monitor the deployment of the Lyot stop and report any changes in status.
ICD Paragraph # 4.12.4
This event reports the current status of the Lyot stop. It contains the current state of the power and the current position of the stop. Valid positions are in,
out, and in_transit. It reported at 0.01 Hz.
Verification Procedure:
This test will show that the lyot stop event will have the required attributes from the ICD and is transmitted at the required rate. The
PropertyEditor will be used to compare the 1/post:interval value for this controller to the rate in the table in section 4.12 of ICD 1.3-4.4. A
test script named “listen_lyot.th” will activate a listening function for the event in question. A few event messages will print to the screen and
ATPR-32610 TEOACS Test Procedure
This page is subject to the disclosure and distribution restrictions on the cover page.
37
then the listening function will cease. Then the test conductor will compare attributes from the ICD to the printed messages on the screen.
The time between messages will be determined from the printout to verify rate. Subsequently, an action will take place that will cause
portions of the event data to change. The listening function will be repeated and the test conductor will demonstrate that the content of the
This attribute selects when to store the current M2 positioner offsets as the current zero position. It may only be accepted when the current mode of the M2
positioner is active. When selected, the status flag isZpoint is set.
ICD Paragraph # 4.9.6 clearZpoint
This attribute selects when to remove the current M2 positioner zero position offsets. When selected, the status flag isZpoint is cleared.
Design Verification (ICD Assumption based on customer agreement)
The final demand position calculation shall be as follows in AO mode active and AO mode passive:
The TEOACS is operated through a number of modes. These are used to control the basic operations of the camera. The available modes and their
descriptions are as follows:
passive—The M2 positioner and M2 tip-tilt systems are powered on (enabled) and operating. Changes to the M2 positioner and M2 tip-tilt (when not in
limb tracking mode) positions shall be performed through the enabled look-up tables. For example, if all lookup tables are enabled, the M2 positioner
and M2 tip-tilt shall be commanded to a position that is the sum of the demand offsets, current static lookup table error and the current records keyed from
the temperature, azimuth and altitude look-up tables.
Verification Procedure:
ATPR-32610 TEOACS Test Procedure
This page is subject to the disclosure and distribution restrictions on the cover page.
41
Verify the passive ao mode behavior with the procedure below:
1. Start the test in aoMode passive with all lookup table flags on the TEOA engineering GUI set to the ‘off’ position and the demand
position and offset for x, y, z, tip, tilt and rot set to zero. Use the ‘configPosZero’ configuration from the TEOA Engineering GUI to
zero out the *.pos values.
2. Use the ‘getLutTempError.th’ script to observe the currently keyed record out of the temperature lookup table. Compare this data to
what is currently on the TEOA Engineering GUI for the temperature lookup table record.
3. Set the lookup table flag for temperature from the ‘off’ position to the ‘on’ position on the TEOA engineering GUI .
4. Observe the ‘Current Pos’ fields for x, y, z, tip, tilt and rot on the TEOA engineering GUI change to match the values observed in step
2 above.
5. Use the ‘setLutTempError.th’ script to change the teoa ambient environment temperature. Edit the script so that the temperature
changes from the existing temperature.
6. Use the ‘getLutTempError.th’ script to observe the currently keyed record out of the temperature lookup table. Compare this data to
what is currently on the TEOA Engineering GUI for the temperature lookup table record.
7. Verify that the keyed record has changed from that seen in step 2.
8. Verify that the hexapod has moved to the positions that would be seen in step 6.
9. Repeat steps 1 - 8 using the scripts for static, azimuth, altitude lookup tables. In step 5 and 6 use the appropriate key associated with
the lut under test. For the static look up table skip step 5, 6 and 7. For step 8 the position to validate is that from step 4.
Script names:
‘getLut*Error.th’ where * = one of ‘Az’, ‘Alt’ or ‘Static’
‘setLut*Error.th’ where * = one of ‘Az’, ‘Alt’ or ‘Static’
10. Set all look up table flags to the ‘on’ position on the TEOA Engineering GUI with the offset values set to zero for all axes.
11. Verify that the current position observed on the GUI is the sum of the look up table values observed using the script.
12. Disable all lookup tables.
ATPR-32610 TEOACS Test Procedure
This page is subject to the disclosure and distribution restrictions on the cover page.
The TEOACS is operated through a number of modes. These are used to control the basic operations of the camera. The available modes and their
descriptions are as follows:
active— The M2 positioner and M2 tip-tilt systems are powered on and operating. Changes to the M2 positioner positions are being performed through a
combination of the enabled look-up tables and input from the WCCS. For example, if all look-up tables are enabled, the M2 positioner shall be
commanded to a position that is the sum of the calculation that is done in passive mode with the latest WCCS information. The M2 tip-tilt always ignores
WCCS information. The M2 tip-tilt does have the capability to receive input from the WFCLT. If that is the intent the M2 tip-tilt must be put into Limb
Tracking Mode.
Verification Procedure:
Verify the active ao mode behavior with the procedure below: Note: transition to passive and back to active mode when necessary. Use the
‘repeatAoZeroActive.th’ script to aid in the test where appropriate.
1. Perform the same test as in 4.2.11 M2 Hexapod Passive AO Mode Behavior steps 1 - 9 with the active mode version of the scripts.
Script names:
‘getLut*ErrorActive.th’ where * = one of ‘Az’, ‘Alt’ or ‘Static’.
‘setLut*ErrorActive.th’ where * = one of ‘Az’, ‘Alt’ or ‘Static’.
2. With all lookup tables toggled off via the TEOA Engineering GUI verify that the hexapod follows wccs trajectory.
3. Toggle all the lookup table flags to ‘on’ using the TEOA Engineering GUI and verify that the hexapod follows wccs trajectory.
ATPR-32610 TEOACS Test Procedure
This page is subject to the disclosure and distribution restrictions on the cover page.
This section describes those attributes that the TCS will send to the top-level controller that involve the Lyot stop controller (atst.tcs.teoacs.lyot).
ICD Paragraph # 4.12.4
This event reports the current status of the Lyot stop. It contains the current state of the power and the current position of the stop. Valid
positions are in, out, and between.
Name Type Units Comment
power boolean off | on The statused enabled or disabled state as read from the hardware.
NOT the commanded power state.
cPos string choice Current position in, out, and in_transit
inAirPressSw boolean false | true Air pressure associated with the in position
outAirPressSw boolean false | true Air pressure associated with the out position
ATPR-32610 TEOACS Test Procedure
This page is subject to the disclosure and distribution restrictions on the cover page.
49
inPosition string false | true false when cPos is in_transit or reading of cPos related digital IO
lines are in conflict with the relevant air pressure switches.
Verification Procedure: Verify that the information in the lyot stop cStatus event corresponds to what was asked for in the position.
1. With the power attribute (‘lyotPowerCfg’ from GUI) on the lyot stop controller pull the Ethernet cable connecting the acromag 983
EN controller out of the Ethernet switch. Note: Ethernet cable only to be pulled for about 5 seconds. Also note that the cable needs to
be pulled so that only communications with the lyot stop are affected.
2. Verify that a communications down fault is seen.
3. Re-apply the Ethernet cable (should be about 5 seconds after it was originally pulled).
4. If the communications down fault does not heal on its own toggle the power attribute off and back on again.
5. With the power attribute set to on monitor the lyot stop cStatus event with the ‘listenLyotStatus.th’ test script.
6. With the lyot stop power on send the lyot stop to the ‘in’ position from the ‘out’ position using the pos attribute in a valid
configuration using either the test script or the gui (‘lyotConfig1’). If necessary toggle to the ‘out’ position first using ‘lyotConfig2’
configuration from the TEOA Engineering GUI.
7. Verify that all the information in the lyot stop cStatus event is consistent with the position of ‘in’ for the lyot stop after motion stops.
8. Perform steps 6 - 1 again but this time for the case of movement to the ‘out’ position from the ‘in’ position by using ‘lyotConfig2’
configuration from the TEOA Engineering GUI.
9. Stop the listener for the lyot stop cStatus event by using the ‘deflis –q’ command at the Testharness command line.
_____________________ Pass/Fail
ATPR-32610 TEOACS Test Procedure
This page is subject to the disclosure and distribution restrictions on the cover page.
The TEOA shall supply an engineering user interface that implements all functional operations of the TEOA as defined by the interfaces to the TCS and
WCCS (ICD-1.3/4.4 and ICD-1.3/2.3) and shall be useful for actual operations within the ATST. The engineering user interface shall reside on a separate
computer from the TEOACS and use the Common Services Framework to communicate with the TEOACS.
Verification Procedure:
ATPR-32610 TEOACS Test Procedure
This page is subject to the disclosure and distribution restrictions on the cover page.
55
Verify that the Engineering user interface satisfies the Engineering user Interface requirement above by demonstrating related functionality by
operating the user interface from the CSF server ‘dunn’. This is accomplished by performing test procedures in other sections of this
document as called out in the table below.
Step Action System Response
1. Verify that the TEOA Engineering GUI used in all the
subsections listed below is located on the CSF server dunn and
is being executed from there.
The TEOA Engineering GUI is being executed from the CSF server ‘dunn’ and
not the CSF client ‘teoaClient’.
2. Section 4.1.1 Engineering User Interface GUI portions of test executed successfully
3. Section 4.1.2 Lyot Stop Positioning GUI portions of test executed successfully
4. Section 4.1.5 Health GUI portions of test executed successfully
5. Section 4.1.6 Logging GUI portions of test executed successfully
6. Section 4.1.9 Diagnostic Features GUI portions of test executed successfully
7. Sections 4.2.1 - 4.2.4 Attributes related tests GUI has access to all ICD attributes available on each controller.
8. Section 4.2.11 M2 Hexapod Passive AO Mode Behavior GUI portions of test executed successfully
9. Section 4.2.12 M2 Hexapod Active AO Mode Behavior GUI portions of test executed successfully
10. Section 4.2.13 M2 Hexapod Named Position and Limits
behavior
GUI portions of test executed successfully
11. Section 4.2.17 Lyot Stop Behavior GUI portions of test executed successfully
12. Section 4.4.2 M2 Tip-Tilt Limb tracking Mode Enabled GUI portions of test executed successfully
13. Section 4.4.3 M2 Tip-Tilt Limb tracking Mode Disabled GUI portions of test executed successfully
14. Satisfies restart requirement 1.3.3-0020. No system restart should have resulted from executing this test